[#NEWTON-368] NPE running peaberry Newton example

newton

NPE running peaberry Newton example

Created: 23/Jul/09 02:15 PM Updated: 16/Sep/09 04:41 PM

Component/s:

None

Affects Version/s:

1.4

Fix Version/s:

None

File Attachments:	1. ComponentImpl.java.patch (0.7 kb) 2. newton_peaberry_log.txt (19 kb) 3. paul_peaberry.zip (1.08 Mb) 4. paul_peaberry_example.zip (33 kb) 5. peaberry-newton-example.zip (1.15 Mb)
Environment:	Mac OS X 10.5.7 PowerPC

Description

« Hide

I can't reproduce it, any hint from the stacktrace?

Cross-posted from the peaberry issue (http://code.google.com/p/peaberry/issues/detail?id=34)

The example revised for Newton 1.4.0.41 fails for me on Mac OS X 10.5.7 PowerPC with the following in the
distributed case:

> cds publish remote examples/peaberry/xml/publish-peaberry-1.1.1.xml peaberry-1.1.1
> installer install examples/peaberry/xml/peaberrychaincli.composite
> installer install examples/peaberry/xml/remote-link-a.composite
> Exception in thread "Thread-46" java.lang.NullPointerException
at
org.cauldron.newton.component.impl.ComponentImpl$ComponentServiceAvailabilityListener.serviceAvailable(
ComponentImpl.java:223)
at
org.cauldron.newton.implementation.bundle.BundleImplementation.notifyAvailablityListeners(BundleImpleme
ntation.java:234)
at
org.cauldron.newton.implementation.bundle.BundleImplementation.access$300(BundleImplementation.java:4
5)
at
org.cauldron.newton.implementation.bundle.BundleImplementation$UpdateQueueProcessor.serviceAdded(Bun
dleImplementation.java:353)
at
org.cauldron.newton.implementation.bundle.BundleImplementation$UpdateQueueProcessor.run(BundleImple
mentation.java:321)
at java.lang.Thread.run(Thread.java:613)

In looking at ComponentImpl's ComponentServiceAvailabilityListener's serviceAvailable() method, I see that it
expects the service name to exist in a map from the name to a target. So apparently either not all services
have targets, in which case the serviceAvailable() method is naïve and needs to conditionalize the
manipulation of the target, or there is a bug elsewhere (perhaps in the example's configuration, even?) that
prevents the service's target from being mapped.

Please let me know if there is any additional color that I can provide on this issue.

All

Comments

Change History

Sort Order:

Ascending order - Click to sort in descending order

[ Permlink | « Hide ]

Gustavo Morozowski - 23/Jul/09 02:21 PM

extract to newton root dir, instructions in examples/peaberry/README

[ Permlink | « Hide ]

David Savage - 23/Jul/09 02:22 PM

The following patch gives a better error message - basically the implementation is notifying newton of a service that it does not expect.

I believe you need to set the <service name="foo"> tags inside the <component>

Can you point me at the source for this example and I'll see if I can track it down

[ Permlink | « Hide ]

David Savage - 23/Jul/09 02:23 PM

cross posted, ok will look at zip thx

[ Permlink | « Hide ]

David Savage - 23/Jul/09 02:54 PM

Ok so I can't reproduce this with the latest head, so it suggests the peaberry code is ok...perhaps there's a patch that needs to be pulled across to the 1.4 release branch...

[ Permlink | « Hide ]

David Savage - 23/Jul/09 03:27 PM

Ok so I can't repeat this on the 1.4 release branch either? At one stage I wondered if it was due to not running:

ant -f examples/peaberry/build.xml use.distributed.chain

prior to running the remote demo (note this a stupid part of the chainlink demo it is completely unnecessary to rebuild a composite to change it's interface).

But if I cludge my build and switch back to local I get the following error, which is similar...but not quite...hmmm

$ ant -f build/dist/examples/peaberry/build.xml use.local.chain
$ ant -f build/dist/examples/peaberry/build.xml clean.examples install.examples
$ build/dist/bin/container -Dorg.ops4j.peaberry.filter.native=true -- -fabricName=TEST
> exec etc/scripts/single-jvm-dist-infra
events now being logged to var/global-event.log
> cds scan remote examples/peaberry/lib
> cds scan remote examples/chainlink/build/lib
> cds publish remote examples/peaberry/xml/publish-peaberry-1.1.1.xml peaberry-1.1.1
> installer install examples/peaberry/xml/peaberrychaincli.composite
Invalid composite peaberrychaincli-a: Reference interface not set
> installer install examples/peaberry/xml/remote-link-a.composite
Invalid composite remote-link-a: Reference interface not set

[ Permlink | « Hide ]

Paul Snively - 24/Jul/09 06:25 PM

Here's the log of my session(s) in using the Peaberry example in a distributed setting. Please let me know if there's anything else I can do to help. Thanks!

[ Permlink | « Hide ]

Paul Snively - 02/Aug/09 04:08 PM

Does anyone have any more thoughts on this issue? It's unfortunately a showstopper for me in exploring Newton further.

[ Permlink | « Hide ]

David Savage - 03/Aug/09 10:56 AM

Hi Paul,

Sorry I missed your first comment on this issue, I can't see anything obvious from the log you posted. Could you attach a zip containing your peaberry build and I'll try it out here. I've tried to reproduce this error using 1.4 and the peaberry-newton-example.zip Gustavo attached but with no success (or rather I've reproduced the steps with no failure).

Regards,

Dave

[ Permlink | « Hide ]

Paul Snively - 03/Aug/09 07:12 PM

Here are my Peaberry-1.1.1 and Peaberry Example archives. Simply unzip both into the root of a newton-1.4.0.41 directory to recreate my setup. Thanks for your time; I didn't mean to sound intemperate in my last comment. :-)

[ Permlink | « Hide ]

David Savage - 04/Aug/09 10:38 AM

Hi no problem, a blocker is a blocker...

But I've just run this with newton-1.4.0.41 and the two files paul_peaberry.zip and paul_peaberry_example.zip installed with no problems. Here's the steps I took:

# cd /opt
# wget http://newton.codecauldron.org/dist/1.4.0/newton-1.4.0.41.zip
# md5 newton-1.4.0.41.zip
MD5 (newton-1.4.0.41.zip) = 1b76b5895b8afe4d31872e6439114064
# unzip newton-1.4.0.41.zip
# export NEWTON_HOME=/opt/newton-1.4.0.41
# cd $NEWTON_HOME
# unzip ~/downloads/paul_peaberry.zip
# unzip ~/downloads/paul_peaberry_example.zip
# cd examples/peaberry
# ant prepare.examples
# ant clean.examples install.examples
# cd ../..
# bin/container -Dorg.ops4j.peaberry.filter.native=true -- -fabricName=TEST
> exec etc/scripts/single-jvm-dist-infra
events now being logged to var/global-event.log
> cds scan remote examples/peaberry/lib
> cds scan remote examples/chainlink/build/lib
> cds publish remote examples/peaberry/xml/publish-peaberry-1.1.1.xml peaberry-1.1.1
> installer install examples/peaberry/xml/peaberrychaincli.composite
> installer install examples/peaberry/xml/remote-link-a.composite
> peaberrychain chain
chain: cli->{Remote-Link-A} [end of chain]

If your still having problems, you could try doing the following before the ant prepare.examples phase? (this shouldn't be necessary but just in case).

rm -rf ~/.m2/repository/org/cauldron/*

Regards,

Dave

[ Permlink | « Hide ]

Paul Snively - 04/Aug/09 10:06 PM

Thanks for the feedback, Dave!

Unfortunately, this still fails for me. :-(

I wonder: is there any reason why using a case-insensitive filesystem (HFS+ on Mac OS X) could affect this? I'm trying to imagine what could be different about our environments. Also, my Java version is:

java version "1.5.0_19"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_19-b02-304)
Java HotSpot(TM) Client VM (build 1.5.0_19-137, mixed mode, sharing)

[ Permlink | « Hide ]

Paul Snively - 16/Sep/09 04:41 PM

It may be worth pointing out that I cannot reproduce this issue on a MacBook Pro running Mac OS X 10.6.1 and Java version:

java version "1.6.0_15"
Java(TM) SE Runtime Environment (build 1.6.0_15-b03-219)
Java HotSpot(TM) 64-Bit Server VM (build 14.1-b02-90, mixed mode)