HI Bartek,
Thanks for the reply! You were correct. Some of the bundles (it depends) did
not start when the test began!
I was relying on the ServiceTracker.waitforService as follows:
BundleContext bc = b.getBundleContext();
String bsn = b.getSymbolicName();
ServiceTracker st = new ServiceTracker(bc, sclass, null);
st.open();
// Object bac = st.waitForService(DEFAULT_TIMEOUT);
Object bac = st.waitForService(120000);
The call returns with null immediately! Looks like its a bug with Equinox.
Tried to test the same with Felix, but for some reason Felix is choking.
Going to post a separate thread for that one
Thanks
Matt
On Mon, Apr 25, 2011 at 4:35 PM, Bartosz Kowalewski <
[email protected]> wrote:
> ... and as far as I know Pax Exam (at least 1.x) only provides means
> to wait for the system bundle startup. If your testcase has some
> prerequisites that need to be met before test logic is run (i.e. you
> need some bundles to be started, services to be registered, Spring
> contexts to be created, Camel components to be detected and so on and
> so forth), you need to code these checks by yourself.
>
> Bartek
>
> 2011/4/25 Mark Nuttall <[email protected]>:
> > Hi Matt,
> >> With in PaxExam how do I control the creation/start order of bundles?
> > It's pretty much a given in OSGi that cannot rely on or control bundle
> start
> > ordering. It's an asynchronous environment, and application code needs to
> > written so as to cope with that. This is why Valentin wrote,
> > "To work around that I would suggest waiting for one of the services that
> > the JNDI bundle installs for
> > example org.osgi.service.jndi.JNDIContextManager or
> > org.osgi.service.jndi.JNDIProviderAdmin at the start of the test (via
> > getOsgiService or otherwise). This resolves the problem for me."
> > Your code will both work, and be more robust if you change it to wait for
> > JNDI to start, rather than attempt to enforce start ordering.
> > Regards,
> > Mark
> > On 21 April 2011 18:09, Matt Madhavan <[email protected]> wrote:
> >>
> >> Hi Valentine,
> >> Thanks for the reply! Hi Andreas feel free to chime in as well!
> >> With in PaxExam how do I control the creation/start order of bundles?
> >> For instance inside the configuration method:
> >> @org.ops4j.pax.exam.junit.Configuration
> >> public static Option[] configuration() {
> >> Option[] options = options(
> >> bootDelegationPackages("javax.transaction",
> >> "javax.transaction.*"),
> >> // Log
> >> mavenBundle("org.ops4j.pax.logging", "pax-logging-api"),
> >> mavenBundle("org.ops4j.pax.logging", "pax-logging-service"),
> >> mavenBundle("org.eclipse.equinox", "cm"),
> >> mavenBundle("org.eclipse.osgi", "services"),
> >> mavenBundle("org.ops4j.pax.web", "pax-web-extender-war"),
> >> mavenBundle("org.ops4j.pax.web", "pax-web-jetty-bundle"),
> >> mavenBundle("org.ops4j.pax.web", "pax-web-jsp"),
> >> mavenBundle("org.apache.derby", "derby"),
> >> mavenBundle("org.apache.geronimo.specs",
> >> "geronimo-jpa_2.0_spec"),
> >> Is there any way to specify the start order of the bundles? Or have some
> >> specified bundles start only after certain bundles start?
> >>
> >> Thanks
> >> Matt
> >> On Wed, Apr 20, 2011 at 7:48 AM, Valentin Mahrwald
> >> <[email protected]> wrote:
> >>>
> >>> Hi Matt,
> >>> thanks for the code I have finally figured it out. What happens is that
> >>> the test bundle runs before most of the framework is properly started.
> In
> >>> particular, your test code executes before the JNDI activator had
> chance to
> >>> install the InitialContextFactoryBuilder.
> >>> That is not a bug though just an unfortunate and confusing consequence
> of
> >>> the dynamics.
> >>> To work around that I would suggest waiting for one of the services
> that
> >>> the JNDI bundle installs for
> >>> example org.osgi.service.jndi.JNDIContextManager
> >>> or org.osgi.service.jndi.JNDIProviderAdmin at the start of the test
> (via
> >>> getOsgiService or otherwise). This resolves the problem for me.
> >>> Hope this helps,
> >>> Valentin
> >>>
> >>> On 19 Apr 2011, at 23:14, Matt Madhavan wrote:
> >>>
> >>> Hi Valentin,
> >>> I'm attaching my Itest java source code. Please take a look at it and
> let
> >>> me know. If you want I can send you the whole project, next time
> >>> Thanks
> >>> Matt
> >>>
> >>> On Tue, Apr 19, 2011 at 12:44 PM, Valentin Mahrwald
> >>> <[email protected]> wrote:
> >>>>
> >>>> Hi Matt,
> >>>> it is hard to say what is going wrong, from the stack trace though I
> can
> >>>> say that the OSGiInitialContextFactoryBuilder the root to all OSGi
> >>>> integration is not installed. That means either
> >>>> a) the JNDI activator (org.apache.aries.jndi.startup.Activator) did
> not
> >>>> run
> >>>> b) It failed to set itself as the InitialContextFactoryBuilder. In
> that
> >>>> case there should be a "Cannot set the InitialContextFactoryBuilder
> ..."
> >>>> info message in the itest logs somewhere.
> >>>> I suspect that a) is the more likely case, in which case something
> went
> >>>> wrong. Could you post your exact configuration settings - best with
> specific
> >>>> maven versions - so I can try to reproduce the problem?
> >>>> Regards,
> >>>> Valentin
> >>>>
> >>>> On 18 Apr 2011, at 21:28, Matt Madhavan wrote:
> >>>>
> >>>> Hello Valentin,
> >>>> I have all the bundles you have mentioned. Its still not starting :(
> Any
> >>>> more ideas?
> >>>> Thanks
> >>>> Matt
> >>>>
> >>>> On Mon, Apr 18, 2011 at 2:31 PM, Valentin Mahrwald
> >>>> <[email protected]> wrote:
> >>>>>
> >>>>> Hi Matt,
> >>>>> the stack trace looks like in the ITest there is no Aries JNDI
> provider
> >>>>> (either because it is not installed or has failed to start).
> >>>>> In the blog tests there is:
> >>>>> mavenBundle("org.apache.aries.jndi",
> >>>>> "org.apache.aries.jndi" )
> >>>>> Plus at least the following dependencies I believe:
> >>>>> mavenBundle("org.apache.aries.proxy",
> >>>>> "org.apache.aries.proxy"),
> >>>>> mavenBundle("org.apache.aries", "org.apache.aries.util"
> ),
> >>>>> mavenBundle("org.ops4j.pax.logging", "pax-logging-api"),
> >>>>> mavenBundle("org.ops4j.pax.logging",
> >>>>> "pax-logging-service"),
> >>>>> mavenBundle("asm", "asm-all" )
> >>>>> If you have those already in the setup, then I would assume that the
> >>>>> JNDI bundle has not started correctly :(
> >>>>> Regards,
> >>>>> Valentin
> >>>>> On 18 Apr 2011, at 20:22, Matt Madhavan wrote:
> >>>>>
> >>>>> Hello,
> >>>>> I have a service defined as follows:
> >>>>> <bean id="persistenceImpl"
> >>>>>
> >>>>>
> class="com.hcsc.itf.osgi.samples.bp_sdm_jpa.jpa.BlogPersistenceServiceImpl">
> >>>>> <tx:transaction method="*" value="Required" />
> >>>>> <jpa:context property="entityManager" unitname="blogExample" />
> >>>>> </bean>
> >>>>> <service id="blogJPAPersistenceService" ref="persistenceImpl"
> >>>>>
> >>>>>
> interface="com.hcsc.itf.osgi.samples.bp_sdm_jpa.api.persistence.BlogPersistenceService">
> >>>>> <service-properties>
> >>>>> <entry key="osgi.jndi.service.name"
> >>>>> value="persistence/bpJPAPersistenceService"/>
> >>>>> </service-properties>
> >>>>> </service>
> >>>>> When I do Integration test (I'm using PAX-Exam/Pax_runner(1.5.0) with
> >>>>> Equinox) I can look up the Service as follows with no problem.
> >>>>> @Test public void testPeristence() throws Exception {
> >>>>> BlogPersistenceService jpaService = getOsgiService(
> >>>>> BlogPersistenceService.class,
> >>>>> "osgi.jndi.service.name=persistence/bpJPAPersistenceService",
> 10000);
> >>>>> But I wanted to,look up the same service as a raw JNDI Look up as
> >>>>> follows:
> >>>>> @Test public void testPeristence() throws Exception { InitialContext
> ic
> >>>>> = new InitialContext(); BlogPersistenceService jpaService =
> >>>>> (BlogPersistenceService) ic.lookup("osgi:service/" +
> >>>>>
> "com.hcsc.itf.osgi.samples.bp_sdm_jpa.api.persistence.BlogPersistenceService");
> >>>>>
> >>>>>
> >>>>> I'm getting the following Exception. (Please note that I'm in essence
> >>>>> doing the same thing as Apache Aries Blog sample!)
> >>>>> javax.naming.NoInitialContextException: Need to specify class name in
> >>>>> environment or system property, or as an applet parameter, or in an
> >>>>> application resource file: java.naming.factory.initial
> >>>>> at
> >>>>>
> javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:645)
> >>>>> at
> >>>>>
> javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java:288)
> >>>>> at
> >>>>>
> javax.naming.InitialContext.getURLOrDefaultInitCtx(InitialContext.java:325)
> >>>>> at javax.naming.InitialContext.lookup(InitialContext.java:392)
> >>>>> at
> >>>>>
> com.hcsc.itf.osgi.samples.bp_sdm_jpa.itests.jpa.BpJpaJndiLookUpITest.testPeristence(BpJpaJndiLookUpITest.java:41)
> >>>>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> >>>>> at
> >>>>>
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> >>>>> at
> >>>>>
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> >>>>> at java.lang.reflect.Method.invoke(Method.java:597)
> >>>>> at
> >>>>>
> org.ops4j.pax.exam.junit.extender.impl.internal.CallableTestMethodImpl.injectContextAndInvoke(CallableTestMethodImpl.java:143)
> >>>>> at
> >>>>>
> org.ops4j.pax.exam.junit.extender.impl.internal.CallableTestMethodImpl.call(CallableTestMethodImpl.java:105)
> >>>>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> >>>>> at
> >>>>>
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> >>>>> at
> >>>>>
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> >>>>> at java.lang.reflect.Method.invoke(Method.java:597)
> >>>>> at
> >>>>>
> org.ops4j.pax.exam.rbc.internal.RemoteBundleContextImpl.remoteCall(RemoteBundleContextImpl.java:80)
> >>>>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> >>>>> at
> >>>>>
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> >>>>> at
> >>>>>
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> >>>>> at java.lang.reflect.Method.invoke(Method.java:597)
> >>>>> at
> sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:305)
> >>>>> at sun.rmi.transport.Transport$1.run(Transport.java:159)
> >>>>> at java.security.AccessController.doPrivileged(Native Method)
> >>>>> at sun.rmi.transport.Transport.serviceCall(Transport.java:155)
> >>>>> at
> >>>>>
> sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:535)
> >>>>> at
> >>>>>
> sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(TCPTransport.java:790)
> >>>>> at
> >>>>>
> sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:649)
> >>>>> at
> >>>>>
> java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
> >>>>> at
> >>>>>
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
> >>>>> at java.lang.Thread.run(Thread.java:662)
> >>>>> I'm kind of lost! I'm doing the exact thing as done in the Aries Blog
> >>>>> sample! Any ideas please?
> >>>>> Thanks
> >>>>> Matt
> >>>>>
> >>>>>
> >>>>>
> >>>>
> >>>>
> >>>
> >>> <BpJpaJndiLookUpITest.java>
> >>
> >
> >
>
