Announcement Announcement Module
Collapse

Spring Dynamic Modules forum decommissioned in favor of Eclipse Gemini Blueprint

With the official first release of Eclipse Gemini Blueprint shipped, the migration of the Spring Dynamic Modules code base to the Eclipse Foundation, as part of the Gemini project, has been completed.

As such, this forum has been decommissioned in favour of the Eclipse Gemini forums.
See more
See less
Unable to use jetty with spring-dm 1.1.1 Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • Unable to use jetty with spring-dm 1.1.1

    Hi,

    I'm trying run an osgi integration (extending AbstractConfigurableBundleCreatorTests) that use a Jetty web server.

    The following bundles are supposed to be started by my test:
    com.springsource.org.mortbay.jetty.server;6.1.9
    com.springsource.org.mortbay.util;6.1.9
    org.springframework.osgi.jetty.web.extender.fragme nt.osgi;1.0.0
    org.springframework.bundle.osgi.web.extender;1.1.1
    org.springframework.bundle.osgi.web;1.1.1
    ...
    But when my test runs, I get the following exception:
    Code:
    16:49:32,361  INFO WarLoaderListener - Starting [org.springframework.osgi.web.extender] bundle v.[1.1.1.A]
    16:49:32,361  INFO WarListenerConfiguration - No custom extender configuration detected; using defaults...
    16:49:32,361 ERROR NodesManagerServiceIntegrationTest - cannot start bundle [Spring DM Web Extender (org.springframework.osgi.web.extender)|file:/C:/svn/griffin/core-platform/logical-master/integration-tests/./target/it-dependencies/org.springframework.osgi.web.extender-1.1.1.A.jar]
    org.osgi.framework.BundleException: Exception in org.springframework.osgi.web.extender.internal.activator.WarLoaderListener.start() of bundle org.springframework.osgi.web.extender.
            at org.eclipse.osgi.framework.internal.core.BundleContextImpl.startActivator(BundleContextImpl.java:1018)
            at org.eclipse.osgi.framework.internal.core.BundleContextImpl.start(BundleContextImpl.java:974)
            at org.eclipse.osgi.framework.internal.core.BundleHost.startWorker(BundleHost.java:346)
            at org.eclipse.osgi.framework.internal.core.AbstractBundle.start(AbstractBundle.java:260)
            at org.eclipse.osgi.framework.internal.core.AbstractBundle.start(AbstractBundle.java:252)
            at org.springframework.osgi.test.AbstractOsgiTests.startBundle(AbstractOsgiTests.java:341)
            at org.springframework.osgi.test.AbstractOsgiTests.startup(AbstractOsgiTests.java:258)
            at org.springframework.osgi.test.AbstractOsgiTests.prepareTestExecution(AbstractOsgiTests.java:374)
            at org.springframework.osgi.test.AbstractOsgiTests.runBare(AbstractOsgiTests.java:203)
            at org.springframework.osgi.test.AbstractOsgiTests$1.protect(AbstractOsgiTests.java:184)
            at junit.framework.TestResult.runProtected(TestResult.java:124)
            at org.springframework.osgi.test.AbstractOsgiTests.run(AbstractOsgiTests.java:181)
            at junit.framework.TestSuite.runTest(TestSuite.java:230)
            at junit.framework.TestSuite.run(TestSuite.java:225)
            at org.junit.internal.runners.JUnit38ClassRunner.run(JUnit38ClassRunner.java:81)
            at org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:62)
            at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTestSet(AbstractDirectoryTestSuite.java:140)
            at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(AbstractDirectoryTestSuite.java:165)
            at org.apache.maven.surefire.Surefire.run(Surefire.java:107)
            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.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:289)
            at org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:993)
    Caused by: java.lang.NoClassDefFoundError: org/apache/catalina/Loader
            at org.springframework.osgi.web.extender.internal.activator.WarListenerConfiguration.createDefaultWarDeployer(WarListenerConfiguration.java:188)
            at org.springframework.osgi.web.extender.internal.activator.WarListenerConfiguration.<init>(WarListenerConfiguration.java:102)
            at org.springframework.osgi.web.extender.internal.activator.WarLoaderListener.start(WarLoaderListener.java:339)
            at org.eclipse.osgi.framework.internal.core.BundleContextImpl$2.run(BundleContextImpl.java:999)
            at java.security.AccessController.doPrivileged(Native Method)
            at org.eclipse.osgi.framework.internal.core.BundleContextImpl.startActivator(BundleContextImpl.java:993)
            ... 24 more
    Caused by: java.lang.ClassNotFoundException: org.apache.catalina.Loader
            at org.eclipse.osgi.framework.internal.core.BundleLoader.findClassInternal(BundleLoader.java:434)
            at org.eclipse.osgi.framework.internal.core.BundleLoader.findClass(BundleLoader.java:369)
            at org.eclipse.osgi.framework.internal.core.BundleLoader.findClass(BundleLoader.java:357)
            at org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader.loadClass(DefaultClassLoader.java:83)
            at java.lang.ClassLoader.loadClass(ClassLoader.java:251)
            at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319)
            ... 30 more
    It looks like the fragment bundle that configure the web extender (to use the JettyWarDeployer) is not attached to the web-extender when the activator of the web-extender is called...

    I take a look to find how bundles are started by the org.springframework.osgi.test.AbstractOsgiTests and I find that the bundles are started by calling bundle.start()... This means that the bundles are started with the activation policy equal to eager activation. I am not familiar with the activation policies but from what I understand the bundle activator of the fragment-host will always be called before the fragment bundle could be attached to the host. Is it correct?

    Do you know how I can avoid this error?

  • #2
    You can take a look at the integration tests inside Spring DM but as long as the fragment is present and resolved, things should work out just fine. In general, as a precaution, you can deploy the fragment before the host.
    What version of Equinox are you using?

    Comment


    • #3
      OK I found my error...

      I took my spring and spring-dm bundles from the SpringSource Enterprise Bundle Repository. I just realized that the symbolic names of those bundles are different from those included in the official distributions of spring and spring-dm. That's why the jetty.web.extender.fragment.osgi was unable to attach to the web-extender bundle... My apologies for the stupid question...

      But does anyone know why the bundles coming from the SpringSource Enterprise Bundle Repository are different from those coming from the official distribution? If the jars are already OSGI compatible bundles, why they are modified when distributed in the enterprise bundle repository?

      Comment


      • #4
        Sorry for the inconvenience - I had no idea about this problem. The artifacts in BRITS are slightly different in terms of manifest information since they are used by the dm Server which uses a slightly different process of producing the manifests and since we discovered some subtle problems between the two, the artifacts in BRITS were created.
        On the good side, for 1.2.x we're working on integrating the process so there will be only one artifact per release.

        Comment


        • #5
          maven central repo spring bundles

          Originally posted by Costin Leau View Post
          Sorry for the inconvenience - I had no idea about this problem. The artifacts in BRITS are slightly different in terms of manifest information since they are used by the dm Server which uses a slightly different process of producing the manifests and since we discovered some subtle problems between the two, the artifacts in BRITS were created.
          On the good side, for 1.2.x we're working on integrating the process so there will be only one artifact per release.
          The bundle from maven central repo also says "org.springframework.bundle.osgi.web.extender" instead of "org.springframework.osgi.web.extender" as looked up by the jetty fragment.

          Code:
          osgi> ss
          
          Framework is launched.
          
          id      State       Bundle
          0       ACTIVE      org.eclipse.osgi_3.4.2.R34x_v20080826-1230
          1       ACTIVE      org.eclipse.osgi.util_3.1.300.v20080303
          2       ACTIVE      org.eclipse.osgi.services_3.1.200.v20070605
          3       ACTIVE      com.soluvas.example.cxf-osgi-sample_1.0.0.SNAPSHOT
          4       ACTIVE      org.ops4j.pax.logging.pax-logging-api_1.1.1
          5       ACTIVE      com.springsource.org.aopalliance_1.0.0
          6       ACTIVE      org.springframework.bundle.spring.core_2.5.5
          7       ACTIVE      org.springframework.bundle.spring.beans_2.5.5
          8       ACTIVE      org.springframework.bundle.spring.context_2.5.5
          9       ACTIVE      org.springframework.bundle.spring.aop_2.5.5
          10      ACTIVE      org.springframework.bundle.spring.web_2.5.5
          11      ACTIVE      org.springframework.bundle.osgi.core_1.1.2
          12      ACTIVE      org.springframework.bundle.osgi.io_1.1.2
          13      ACTIVE      org.springframework.bundle.osgi.extender_1.1.2
          14      ACTIVE      org.springframework.bundle.osgi.extensions.annotations_1.1.2
          15      ACTIVE      org.springframework.bundle.osgi.web_1.1.2
          16      ACTIVE      org.springframework.bundle.osgi.web.extender_1.1.2
          17      ACTIVE      org.mortbay.jetty.util_6.1.14
          18      ACTIVE      org.mortbay.jetty.server_6.1.14
          19      ACTIVE      org.springframework.osgi.servlet-api.osgi_2.5.0.SNAPSHOT
          20      ACTIVE      org.springframework.osgi.jetty.start.osgi_1.0.0
          21      INSTALLED   org.springframework.osgi.jetty.web.extender.fragment.osgi_1.0.1
          Above test case available from:

          https://scm.ops4j.org/repos/ops4j/la...le/spring-osgi

          Comment


          • #6
            You are using the wrong web extender/Spring DM versions. As of Spring DM 1.2.0 M2, the bundle symbolic names have been changed and thus the jetty web fragment had to be updated (version 1.0.1).
            If you are using Spring DM 1.1.2, you'll have to use jetty web fragment version 1.0.0.

            Comment

            Working...
            X