Announcement Announcement Module
No announcement yet.
Getting Apache CXF Up and running Page Title Module
Move Remove Collapse
Conversation Detail Module
  • Filter
  • Time
  • Show
Clear All
new posts

  • Getting Apache CXF Up and running


    first of all a little warning, I'm only a couple fo days into Spring DM (but know Spring/OSGI pretty well). Anyway, I need to get CXF upand running or more precisely an implementation of JSR311 (JAX-RS). I am assuming that I can get CXF running in DM (it works fine standalone).

    So I have spent some time today finding all the right bundles (not exactly the easiest thing in the world...).

    I now seem to have all of the right bundles etc, but have run into an issue. If I put the cxf-2.2.1.jar in the repository/bundles/usr directory with all of it's dependencies, I get an exception (see below).

    If I put the cxf jar in the 'pickup' directory it all loads w/o error.

    Unfortunately, I don't see the bundles in the 'pickup' area from STS so I can't specify the cxf bundle as a depenency, hence it won't resolve the CXF bean namespace.

    Any suggestions? Is the below issue a bug? I can zip up the jars if that would help.

    C:\springsource-dm-server-2.0.0.M2>bin\startup.bat -clean
    Launch failed: caught exception.
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Nativ e Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(Native MethodAccessorImpl.
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(De legatingMethodAcces
    at java.lang.reflect.Method.invoke(
    at com.springsource.server.launch.harness.LaunchHarne ss.main(LaunchHarne
    Caused by: org.osgi.framework.BundleException: Exception in com.springsource.ker
    nel.repository.internal.RepositoryActivator.start( ) of bundle com.springsource.k
    at org.eclipse.osgi.framework.internal.core.BundleCon textImpl.startActiv
    at org.eclipse.osgi.framework.internal.core.BundleCon textImpl.start(Bund
    at org.eclipse.osgi.framework.internal.core.BundleHos t.startWorker(Bundl
    at org.eclipse.osgi.framework.internal.core.AbstractB undle.start(Abstrac
    at org.eclipse.osgi.framework.internal.core.AbstractB undle.start(Abstrac
    at stallAndStartBundle
    at art(FrameworkBuilde
    at com.springsource.osgi.launcher.Launcher.main(Launc
    ... 5 more
    Caused by: com.springsource.repository.RepositoryCreationExce ption: Failed persi
    st depository for repository 'bundles-subsystems'
    at com.springsource.repository.internal.ExternalStora geRepository.<init>
    at com.springsource.repository.internal.StandardRepos itoryFactory.create
    at com.springsource.repository.internal.StandardRepos itoryFactory.create
    at com.springsource.kernel.repository.internal.Reposi toryActivator.creat
    eAndPublishBundleRepository(RepositoryActivator.ja va:116)
    at com.springsource.kernel.repository.internal.Reposi toryActivator.start
    at org.eclipse.osgi.framework.internal.core.BundleCon textImpl$
    at Method)
    at org.eclipse.osgi.framework.internal.core.BundleCon textImpl.startActiv
    ... 12 more
    Caused by: com.springsource.repository.internal.IndexFormatEx ception: Failed to
    convert to supplied artifacts into binary form
    at com.springsource.repository.internal.ArtifactDescr iptorSerializer.toB
    at com.springsource.repository.internal.SerializingAr tifactDescriptorPer
    at com.springsource.repository.internal.StandardArtif actDescriptorDeposi
    tory.persist(StandardArtifactDescriptorDepository. java:154)
    at com.springsource.repository.internal.ExternalStora geRepository.<init>
    ... 19 more
    Caused by: encoded string too long: 93274 bytes
    at .java:347)
    at .java:306)
    at com.springsource.repository.internal.ArtifactDescr iptorSerializer.wri
    at com.springsource.repository.internal.ArtifactDescr iptorSerializer.wri
    at com.springsource.repository.internal.ArtifactDescr iptorSerializer.toB
    ... 22 more

  • #2

    This would certainly appear to be a bug. Can you open a JIRA please? It'd be great if you could zip up the JARs and attach them to the JIRA, 10MB attachment limit permitting. Hopefully just the JARs that you've added will weigh in at less than 10MB...

    There's one thing that's slightly confusing to me at the moment. You added the bundles to repository/bundles/usr, and yet, looking at the stack trace, it's the subsystem's repository that had a problem. A recursive directory listing for the contents of all the directories referenced in repository.config should help to get to the bottom of this; it'd be great if you could include that in the JIRA too.



    • #3

      I am seeing the exact same problem with cxf-bundle version 2.1.4.


      That is, the bundle needs to be placed within the pickup directory to get resolved without error. Has a JIRA issue been created for this already?

      regards, Peter


      • #4
        Peter, no I don't believe so. Please feel free to open one, and we'll take a look.


        • #5


          • #6
            Thanks, Peter.


            • #7
              I finally managed to get CXF up and running in the DM server. However, to work around I had to use a different CXF bundle:


              This bundle can be placed in the bundle repository without the server blowing up at startup. However, I noticed a strange behavior inside Eclipse/STS. I get an error in my bundle project manifest when I attempt to import a package from the CXF bundle. It appears to be the case that the STS tooling does not detect the CXF bundle in the repository (it is not listed in the Repository tab in the server) even though the CXF bundle is loaded into the server's (OSGi) runtime. Running the "ss" command from the server console shows:

              104 ACTIVE org.apache.cxf.bundle-minimal_2.2.1

              Smells like a bug. Should I file another JIRA?

              best regards, Peter


              • #8
                Thanks for letting us know that the minimal CXF bundle works. My guess would be that it has a smaller Export-Package header, so it doesn't exceed the 64KB limit.

                Apologies for the problem you've now found in Eclipse. There's a known problem with the tools running against dm Server 2.0: DependencyLocator, which is used by the dm Server tools when it's populating a project's classpath based on its manifest, is a little out of step with the new repository support. The issue's on my task-list for the current sprint so it shouldn't be too long till it's fixed.