3 Replies Latest reply on Apr 11, 2013 2:48 AM by Daniel Straub

    JBDC-persistence and usage of third libraries

    Daniel Straub Newbie

      We're faced with the same problem like here:  http://fusesource.com/issues/browse/ENTESB-685

      We solved this problem by coping the required libraries in the deployment folder :

       

      deploy/

      ├── README

      ├── commons-dbcp-1.4.jar

      └── ojdbc-11.2.0.2.0.jar

       

       

      What are the implications for product support by using this approach ?

       

      A better solution (for an enterprise system) should be to provide the missing connection pool library in the system folder and use this as a (optional) import to the org.apache.activemq.activemq-osgi bundle.

      So that the customer has to add only not public libraries like database drivers.

       

      (At the moment this forum feels like a one-way street )

        • 1. Re: JBDC-persistence and usage of third libraries
          Dave Stanley Newbie

          Hi Daniel,

          Commons-dbcp is included in the distro. You should be able to do:

           

          >osgi:install -s mvn:org.apache.servicemix.bundles/org.apache.servicemix.bundles.commons-dbcp/1.2.2_7

           

          Then install the ojdbc-11.2.0.2.0.jar as before.

           

          Regards

          /Dave

          • 2. Re: JBDC-persistence and usage of third libraries
            Daniel Straub Newbie

            Hi Dave

            thanks for your response !

             

            But that's not correct in case of the  jboss-a-mq-6.0.0.redhat-015 distro.

             

            Try a "find system -name "*commons*" in the distro.

             

            Here an tcpdump during the "osgi:install ..."

             

            21:34:52.945406 IP 192.168.1.10.50412 > gs1.wpc.v3cdn.net.http: Flags [P.], seq 1751479979:1751480318, ack 419579680, win 16384, length 339

            E..{us@.@......

            D."....Phev...G P.@.S...GET /maven2/org/apache/servicemix/bundles/org.apache.servicemix.bundles.commons-dbcp/1.2.2_7/org.apache.servicemix.bundles.commons-dbcp-1.2.2_7.jar HTTP/1.1

            Cache-Control: no-cache

            Pragma: no-cache

            User-Agent: Java/1.6.0_43

            Host: repo1.maven.org

            Accept: text/html, image/gif, image/jpeg, *; q=.2, */*; q=.2

            Connection: keep-alive

             

            As you can see, commons-dbcp is loaded from repo1.maven.org.

            Ok, we can configure the maven urls in etc/org.ops4j.pax.url.mvn.cfg to use an inside maven repo (nexus) and after that, this the jar is cached in data/cache, so the maven-repo access is required only once etc.

             

            Addendum:

            commons-dbcp is part of JBoss-Fuse (jboss-fuse-full-6.0.0.redhat-015.zip - I'm also a little bit "confused" about the distros ... ).

            In this version, your solution works - and we can add commons-dbcb as startup-bundle, so the osgi:install isn't required.

            • 3. Re: JBDC-persistence and usage of third libraries
              Daniel Straub Newbie

              At last we came up with this solution:

              • copying system/org/apache/servicemix/bundles/org.apache.servicemix.bundles.commons-dbcp from a jboss fuse installation to jboss a-mq
              • modifing the activemq-feature in system/org/apache/activemq/activemq-karaf/5.8.0.redhat-60015/activemq-karaf-5.8.0.redhat-60015-features.xml:

               

                  <feature name="activemq" description="ActiveMQ broker libraries" version="5.8.0.redhat-60015" resolver="(obr)" start-level="50">

                    <feature>jetty</feature>

                     ...

                    <bundle dependency="true">mvn:org.apache.servicemix.bundles/org.apache.servicemix.bundles.commons-dbcp/1.4_3</bundle>

                  </feature>

               

              It would be good if this or another solution is included in the final JBoss A-MQ version.
              In our production environment, we install server/software as RPM via Redhat/JBoss channels and want to change/add as less as possible.