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

  • Getting Apache CXF Up and running

    Hi,

    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.
    Steve


    C:\springsource-dm-server-2.0.0.M2>bin\startup.bat -clean
    Launch failed: caught exception.
    java.lang.reflect.InvocationTargetException
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Nativ e Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(Native MethodAccessorImpl.
    java:39)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(De legatingMethodAcces
    sorImpl.java:25)
    at java.lang.reflect.Method.invoke(Method.java:597)
    at com.springsource.server.launch.harness.LaunchHarne ss.main(LaunchHarne
    ss.java:63)
    Caused by: org.osgi.framework.BundleException: Exception in com.springsource.ker
    nel.repository.internal.RepositoryActivator.start( ) of bundle com.springsource.k
    ernel.repository.
    at org.eclipse.osgi.framework.internal.core.BundleCon textImpl.startActiv
    ator(BundleContextImpl.java:830)
    at org.eclipse.osgi.framework.internal.core.BundleCon textImpl.start(Bund
    leContextImpl.java:779)
    at org.eclipse.osgi.framework.internal.core.BundleHos t.startWorker(Bundl
    eHost.java:352)
    at org.eclipse.osgi.framework.internal.core.AbstractB undle.start(Abstrac
    tBundle.java:280)
    at org.eclipse.osgi.framework.internal.core.AbstractB undle.start(Abstrac
    tBundle.java:272)
    at com.springsource.osgi.launcher.FrameworkBuilder.in stallAndStartBundle
    s(FrameworkBuilder.java:177)
    at com.springsource.osgi.launcher.FrameworkBuilder.st art(FrameworkBuilde
    r.java:160)
    at com.springsource.osgi.launcher.Launcher.main(Launc her.java:45)
    ... 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>
    (ExternalStorageRepository.java:76)
    at com.springsource.repository.internal.StandardRepos itoryFactory.create
    Repository(StandardRepositoryFactory.java:75)
    at com.springsource.repository.internal.StandardRepos itoryFactory.create
    Repository(StandardRepositoryFactory.java:55)
    at com.springsource.kernel.repository.internal.Reposi toryActivator.creat
    eAndPublishBundleRepository(RepositoryActivator.ja va:116)
    at com.springsource.kernel.repository.internal.Reposi toryActivator.start
    (RepositoryActivator.java:70)
    at org.eclipse.osgi.framework.internal.core.BundleCon textImpl$1.run(Bund
    leContextImpl.java:807)
    at java.security.AccessController.doPrivileged(Native Method)
    at org.eclipse.osgi.framework.internal.core.BundleCon textImpl.startActiv
    ator(BundleContextImpl.java:798)
    ... 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
    inaryForm(ArtifactDescriptorSerializer.java:79)
    at com.springsource.repository.internal.SerializingAr tifactDescriptorPer
    sister.persistArtifactDescriptors(SerializingArtif actDescriptorPersister.java:68
    )
    at com.springsource.repository.internal.StandardArtif actDescriptorDeposi
    tory.persist(StandardArtifactDescriptorDepository. java:154)
    at com.springsource.repository.internal.ExternalStora geRepository.<init>
    (ExternalStorageRepository.java:74)
    ... 19 more
    Caused by: java.io.UTFDataFormatException: encoded string too long: 93274 bytes
    at java.io.DataOutputStream.writeUTF(DataOutputStream .java:347)
    at java.io.DataOutputStream.writeUTF(DataOutputStream .java:306)
    at com.springsource.repository.internal.ArtifactDescr iptorSerializer.wri
    teAttribute(ArtifactDescriptorSerializer.java:141)
    at com.springsource.repository.internal.ArtifactDescr iptorSerializer.wri
    teArtefact(ArtifactDescriptorSerializer.java:128)
    at com.springsource.repository.internal.ArtifactDescr iptorSerializer.toB
    inaryForm(ArtifactDescriptorSerializer.java:74)
    ... 22 more

  • #2
    Steve,

    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.

    Thanks,
    Andy

    Comment


    • #3
      Hello,

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


      <dependency>
      <groupId>org.apache.cxf</groupId>
      <artifactId>cxf-bundle</artifactId>
      <version>2.1.4</version>
      </dependency>


      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

      Comment


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

        Comment


        • #5
          https://issuetracker.springsource.com/browse/DMS-808

          Comment


          • #6
            Thanks, Peter.

            Comment


            • #7
              I finally managed to get CXF up and running in the DM server. However, to work around https://issuetracker.springsource.com/browse/DMS-808 I had to use a different CXF bundle:


              <dependency>
              <groupId>org.apache.cxf</groupId>
              <artifactId>cxf-bundle-minimal</artifactId>
              <version>2.2.1</version>
              </dependency>


              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

              Comment


              • #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: https://issuetracker.springsource.com/browse/DMS-771. 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.

                Comment

                Working...
                X