You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@camel.apache.org by "Freeman Fang (JIRA)" <ji...@apache.org> on 2011/08/05 09:27:27 UTC
[jira] [Commented] (CAMEL-4308) commons-dbcp bundle used in camel
feature.xml doesn't allow dynamic imports
[ https://issues.apache.org/jira/browse/CAMEL-4308?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13079810#comment-13079810 ]
Freeman Fang commented on CAMEL-4308:
-------------------------------------
I noticed that camel now use commons-dbcp 1.3 but in servicemix we have wrapped commons-dbcp 1.2.2 and 1.4, so I create SMX4-892[1] and will add commons-dbcp 1.3 bundle in servicemix firstly.
[1]https://issues.apache.org/jira/browse/SMX4-892
Freeman
> commons-dbcp bundle used in camel feature.xml doesn't allow dynamic imports
> ---------------------------------------------------------------------------
>
> Key: CAMEL-4308
> URL: https://issues.apache.org/jira/browse/CAMEL-4308
> Project: Camel
> Issue Type: Improvement
> Reporter: Freeman Fang
>
> currently the commons-dbcp bundle used in camel feature.xml doesn't allow dynamic imports, it will cause exception like
> org.apache.commons.dbcp.SQLNestedException: Cannot load JDBC driver class 'oracle.jdbc.driver.OracleDriver'
> as
> JDBC driver class not found actually is a common issue in OSGi container, this problem generally from a bundle(let's say it bundle A, commons-dbcp in this case) using some code like classForName(jdbc_driver_classname) to init a jdbc driver class, this is a big problem in OSGi world, as if BundleA not import package for jdbc_driver_classname, we'll see the problem. However BundleA actually can't know about package name for jdbc_driver_classname beforehand, as the jdbc_driver_classname generally is passed in through configuration during runtime, it can't be determined during build time, so we can't add correct package import when we generate bundle A.
> The general solution is
> 1. add dynamic import for bundle A(commons-dbcp)
> or
> 2. create JDBC driver as a fragment bundle, and attach it to bundle A(bundle A is host bundle now), so that all resource from fragment bundle is available for the host bundle.
> Solution 1 left less effort for end user and n servicemix wrapped commons-dbcp bundle we already have dynamic-import header and I think camel features should use the servicemix wrapped commons-dbcp bundle as well.
> I will append a patch soon.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [jira] [Commented] (CAMEL-4308) commons-dbcp bundle used in camel
feature.xml doesn't allow dynamic imports
Posted by Claus Ibsen <cl...@gmail.com>.
On Sat, Aug 6, 2011 at 12:15 PM, Freeman Fang <fr...@gmail.com> wrote:
> Hi Claus,
>
> commons-dbcp may not be used directly by camel components.
> But as datasource like org.apache.commons.dbcp.BasicDataSource is popularly
> used by specifying DAO when use database related camel features such as
> camel-jpa, so I'm not sure simply remove commons-dbcp bundle from camel
> features.xml is a good idea.
>
Frankly I dont like installing bundles and whatnot that the end user
may not need / want to use.
Maybe a JDBC connection pooling feature is missing in karaf (or
servicemix), by which features can refer to and leverage.
And having shell support for the connection pooling so you can get
utilization details, and likewise JMX support and whatnot.
But that is a different problem. I am okay for upgrading the DBCP in
the camel features files.
> Best Regards
> Freeman
> On 2011-8-6, at 下午5:12, Claus Ibsen wrote:
>
>> On Sat, Aug 6, 2011 at 3:31 AM, Freeman Fang <fr...@gmail.com>
>> wrote:
>>>
>>> Hi Christian,
>>>
>>> Yeah, If camel team agree to upgrade to commons-dbcp 1.4 then we can use
>>> SMX
>>> wrapped commons-dbcp 1.4 bundle directly.
>>>
>>> If there's no other objection I'll append a patch which upgrade to
>>> commons-dbcp 1.4 also.
>>
>> The commons-dbcp is not used by any of the camel components in non osgi
>> mode.
>>
>> So its something somebody added in the features file. Its not required
>> by Camel or by the 3rd party components.
>> I wonder if we can just remove it?
>>
>> In the features file its listed in
>> - camel-bam
>> - camel-ibatis
>> - camel-jpa
>> - camel-mybatis
>> - camel-quartz
>>
>>
>>>
>>> Best Regards
>>> Freeman
>>> On 2011-8-6, at 上午12:50, Christian Müller wrote:
>>>
>>>> I wonder is there a reason not to upgrade Camel to use commons-dbcp 1.4
>>>> when
>>>> SMX already use this version?
>>>>
>>>> Best,
>>>> Christian
>>>>
>>>> On Fri, Aug 5, 2011 at 9:27 AM, Freeman Fang (JIRA) <ji...@apache.org>
>>>> wrote:
>>>>
>>>>>
>>>>> [
>>>>>
>>>>>
>>>>> https://issues.apache.org/jira/browse/CAMEL-4308?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13079810#comment-13079810]
>>>>>
>>>>> Freeman Fang commented on CAMEL-4308:
>>>>> -------------------------------------
>>>>>
>>>>> I noticed that camel now use commons-dbcp 1.3 but in servicemix we have
>>>>> wrapped commons-dbcp 1.2.2 and 1.4, so I create SMX4-892[1] and will
>>>>> add
>>>>> commons-dbcp 1.3 bundle in servicemix firstly.
>>>>>
>>>>> [1]https://issues.apache.org/jira/browse/SMX4-892
>>>>>
>>>>> Freeman
>>>>>
>>>>>> commons-dbcp bundle used in camel feature.xml doesn't allow dynamic
>>>>>
>>>>> imports
>>>>>>
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------------
>>>>>>
>>>>>> Key: CAMEL-4308
>>>>>> URL: https://issues.apache.org/jira/browse/CAMEL-4308
>>>>>> Project: Camel
>>>>>> Issue Type: Improvement
>>>>>> Reporter: Freeman Fang
>>>>>>
>>>>>> currently the commons-dbcp bundle used in camel feature.xml doesn't
>>>>>> allow
>>>>>
>>>>> dynamic imports, it will cause exception like
>>>>>>
>>>>>> org.apache.commons.dbcp.SQLNestedException: Cannot load JDBC driver
>>>>>> class
>>>>>
>>>>> 'oracle.jdbc.driver.OracleDriver'
>>>>>>
>>>>>> as
>>>>>> JDBC driver class not found actually is a common issue in OSGi
>>>>>> container,
>>>>>
>>>>> this problem generally from a bundle(let's say it bundle A,
>>>>> commons-dbcp
>>>>> in
>>>>> this case) using some code like classForName(jdbc_driver_classname) to
>>>>> init
>>>>> a jdbc driver class, this is a big problem in OSGi world, as if BundleA
>>>>> not
>>>>> import package for jdbc_driver_classname, we'll see the problem.
>>>>> However
>>>>> BundleA actually can't know about package name for
>>>>> jdbc_driver_classname
>>>>> beforehand, as the jdbc_driver_classname generally is passed in through
>>>>> configuration during runtime, it can't be determined during build time,
>>>>> so
>>>>> we can't add correct package import when we generate bundle A.
>>>>>>
>>>>>> The general solution is
>>>>>> 1. add dynamic import for bundle A(commons-dbcp)
>>>>>> or
>>>>>> 2. create JDBC driver as a fragment bundle, and attach it to bundle
>>>>>
>>>>> A(bundle A is host bundle now), so that all resource from fragment
>>>>> bundle
>>>>> is
>>>>> available for the host bundle.
>>>>>>
>>>>>> Solution 1 left less effort for end user and n servicemix wrapped
>>>>>
>>>>> commons-dbcp bundle we already have dynamic-import header and I think
>>>>> camel
>>>>> features should use the servicemix wrapped commons-dbcp bundle as
>>>>> well.
>>>>>>
>>>>>> I will append a patch soon.
>>>>>
>>>>> --
>>>>> This message is automatically generated by JIRA.
>>>>> For more information on JIRA, see:
>>>>> http://www.atlassian.com/software/jira
>>>>>
>>>>>
>>>>>
>>>
>>> ---------------------------------------------
>>> Freeman Fang
>>>
>>> FuseSource
>>> Email:ffang@fusesource.com
>>> Web: fusesource.com
>>> Twitter: freemanfang
>>> Blog: http://freemanfang.blogspot.com
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>
>>
>>
>> --
>> Claus Ibsen
>> -----------------
>> FuseSource
>> Email: cibsen@fusesource.com
>> Web: http://fusesource.com
>> Twitter: davsclaus, fusenews
>> Blog: http://davsclaus.blogspot.com/
>> Author of Camel in Action: http://www.manning.com/ibsen/
>
> ---------------------------------------------
> Freeman Fang
>
> FuseSource
> Email:ffang@fusesource.com
> Web: fusesource.com
> Twitter: freemanfang
> Blog: http://freemanfang.blogspot.com
>
>
>
>
>
>
>
>
>
>
--
Claus Ibsen
-----------------
FuseSource
Email: cibsen@fusesource.com
Web: http://fusesource.com
Twitter: davsclaus, fusenews
Blog: http://davsclaus.blogspot.com/
Author of Camel in Action: http://www.manning.com/ibsen/
Re: [jira] [Commented] (CAMEL-4308) commons-dbcp bundle used in camel feature.xml doesn't allow dynamic imports
Posted by Freeman Fang <fr...@gmail.com>.
Hi Claus,
commons-dbcp may not be used directly by camel components.
But as datasource like org.apache.commons.dbcp.BasicDataSource is
popularly used by specifying DAO when use database related camel
features such as camel-jpa, so I'm not sure simply remove commons-dbcp
bundle from camel features.xml is a good idea.
Best Regards
Freeman
On 2011-8-6, at 下午5:12, Claus Ibsen wrote:
> On Sat, Aug 6, 2011 at 3:31 AM, Freeman Fang
> <fr...@gmail.com> wrote:
>> Hi Christian,
>>
>> Yeah, If camel team agree to upgrade to commons-dbcp 1.4 then we
>> can use SMX
>> wrapped commons-dbcp 1.4 bundle directly.
>>
>> If there's no other objection I'll append a patch which upgrade to
>> commons-dbcp 1.4 also.
>
> The commons-dbcp is not used by any of the camel components in non
> osgi mode.
>
> So its something somebody added in the features file. Its not required
> by Camel or by the 3rd party components.
> I wonder if we can just remove it?
>
> In the features file its listed in
> - camel-bam
> - camel-ibatis
> - camel-jpa
> - camel-mybatis
> - camel-quartz
>
>
>>
>> Best Regards
>> Freeman
>> On 2011-8-6, at 上午12:50, Christian Müller wrote:
>>
>>> I wonder is there a reason not to upgrade Camel to use commons-
>>> dbcp 1.4
>>> when
>>> SMX already use this version?
>>>
>>> Best,
>>> Christian
>>>
>>> On Fri, Aug 5, 2011 at 9:27 AM, Freeman Fang (JIRA)
>>> <ji...@apache.org>
>>> wrote:
>>>
>>>>
>>>> [
>>>>
>>>> https://issues.apache.org/jira/browse/CAMEL-4308?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13079810
>>>> #comment-13079810]
>>>>
>>>> Freeman Fang commented on CAMEL-4308:
>>>> -------------------------------------
>>>>
>>>> I noticed that camel now use commons-dbcp 1.3 but in servicemix
>>>> we have
>>>> wrapped commons-dbcp 1.2.2 and 1.4, so I create SMX4-892[1] and
>>>> will add
>>>> commons-dbcp 1.3 bundle in servicemix firstly.
>>>>
>>>> [1]https://issues.apache.org/jira/browse/SMX4-892
>>>>
>>>> Freeman
>>>>
>>>>> commons-dbcp bundle used in camel feature.xml doesn't allow
>>>>> dynamic
>>>>
>>>> imports
>>>>>
>>>>
>>>> ---------------------------------------------------------------------------
>>>>>
>>>>> Key: CAMEL-4308
>>>>> URL: https://issues.apache.org/jira/browse/
>>>>> CAMEL-4308
>>>>> Project: Camel
>>>>> Issue Type: Improvement
>>>>> Reporter: Freeman Fang
>>>>>
>>>>> currently the commons-dbcp bundle used in camel feature.xml
>>>>> doesn't
>>>>> allow
>>>>
>>>> dynamic imports, it will cause exception like
>>>>>
>>>>> org.apache.commons.dbcp.SQLNestedException: Cannot load JDBC
>>>>> driver
>>>>> class
>>>>
>>>> 'oracle.jdbc.driver.OracleDriver'
>>>>>
>>>>> as
>>>>> JDBC driver class not found actually is a common issue in OSGi
>>>>> container,
>>>>
>>>> this problem generally from a bundle(let's say it bundle A,
>>>> commons-dbcp
>>>> in
>>>> this case) using some code like
>>>> classForName(jdbc_driver_classname) to
>>>> init
>>>> a jdbc driver class, this is a big problem in OSGi world, as if
>>>> BundleA
>>>> not
>>>> import package for jdbc_driver_classname, we'll see the problem.
>>>> However
>>>> BundleA actually can't know about package name for
>>>> jdbc_driver_classname
>>>> beforehand, as the jdbc_driver_classname generally is passed in
>>>> through
>>>> configuration during runtime, it can't be determined during build
>>>> time,
>>>> so
>>>> we can't add correct package import when we generate bundle A.
>>>>>
>>>>> The general solution is
>>>>> 1. add dynamic import for bundle A(commons-dbcp)
>>>>> or
>>>>> 2. create JDBC driver as a fragment bundle, and attach it to
>>>>> bundle
>>>>
>>>> A(bundle A is host bundle now), so that all resource from
>>>> fragment bundle
>>>> is
>>>> available for the host bundle.
>>>>>
>>>>> Solution 1 left less effort for end user and n servicemix wrapped
>>>>
>>>> commons-dbcp bundle we already have dynamic-import header and I
>>>> think
>>>> camel
>>>> features should use the servicemix wrapped commons-dbcp bundle
>>>> as well.
>>>>>
>>>>> I will append a patch soon.
>>>>
>>>> --
>>>> This message is automatically generated by JIRA.
>>>> For more information on JIRA, see: http://www.atlassian.com/software/jira
>>>>
>>>>
>>>>
>>
>> ---------------------------------------------
>> Freeman Fang
>>
>> FuseSource
>> Email:ffang@fusesource.com
>> Web: fusesource.com
>> Twitter: freemanfang
>> Blog: http://freemanfang.blogspot.com
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>
>
>
> --
> Claus Ibsen
> -----------------
> FuseSource
> Email: cibsen@fusesource.com
> Web: http://fusesource.com
> Twitter: davsclaus, fusenews
> Blog: http://davsclaus.blogspot.com/
> Author of Camel in Action: http://www.manning.com/ibsen/
---------------------------------------------
Freeman Fang
FuseSource
Email:ffang@fusesource.com
Web: fusesource.com
Twitter: freemanfang
Blog: http://freemanfang.blogspot.com
Re: [jira] [Commented] (CAMEL-4308) commons-dbcp bundle used in camel
feature.xml doesn't allow dynamic imports
Posted by Claus Ibsen <cl...@gmail.com>.
On Sat, Aug 6, 2011 at 3:31 AM, Freeman Fang <fr...@gmail.com> wrote:
> Hi Christian,
>
> Yeah, If camel team agree to upgrade to commons-dbcp 1.4 then we can use SMX
> wrapped commons-dbcp 1.4 bundle directly.
>
> If there's no other objection I'll append a patch which upgrade to
> commons-dbcp 1.4 also.
The commons-dbcp is not used by any of the camel components in non osgi mode.
So its something somebody added in the features file. Its not required
by Camel or by the 3rd party components.
I wonder if we can just remove it?
In the features file its listed in
- camel-bam
- camel-ibatis
- camel-jpa
- camel-mybatis
- camel-quartz
>
> Best Regards
> Freeman
> On 2011-8-6, at 上午12:50, Christian Müller wrote:
>
>> I wonder is there a reason not to upgrade Camel to use commons-dbcp 1.4
>> when
>> SMX already use this version?
>>
>> Best,
>> Christian
>>
>> On Fri, Aug 5, 2011 at 9:27 AM, Freeman Fang (JIRA) <ji...@apache.org>
>> wrote:
>>
>>>
>>> [
>>>
>>> https://issues.apache.org/jira/browse/CAMEL-4308?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13079810#comment-13079810]
>>>
>>> Freeman Fang commented on CAMEL-4308:
>>> -------------------------------------
>>>
>>> I noticed that camel now use commons-dbcp 1.3 but in servicemix we have
>>> wrapped commons-dbcp 1.2.2 and 1.4, so I create SMX4-892[1] and will add
>>> commons-dbcp 1.3 bundle in servicemix firstly.
>>>
>>> [1]https://issues.apache.org/jira/browse/SMX4-892
>>>
>>> Freeman
>>>
>>>> commons-dbcp bundle used in camel feature.xml doesn't allow dynamic
>>>
>>> imports
>>>>
>>>
>>> ---------------------------------------------------------------------------
>>>>
>>>> Key: CAMEL-4308
>>>> URL: https://issues.apache.org/jira/browse/CAMEL-4308
>>>> Project: Camel
>>>> Issue Type: Improvement
>>>> Reporter: Freeman Fang
>>>>
>>>> currently the commons-dbcp bundle used in camel feature.xml doesn't
>>>> allow
>>>
>>> dynamic imports, it will cause exception like
>>>>
>>>> org.apache.commons.dbcp.SQLNestedException: Cannot load JDBC driver
>>>> class
>>>
>>> 'oracle.jdbc.driver.OracleDriver'
>>>>
>>>> as
>>>> JDBC driver class not found actually is a common issue in OSGi
>>>> container,
>>>
>>> this problem generally from a bundle(let's say it bundle A, commons-dbcp
>>> in
>>> this case) using some code like classForName(jdbc_driver_classname) to
>>> init
>>> a jdbc driver class, this is a big problem in OSGi world, as if BundleA
>>> not
>>> import package for jdbc_driver_classname, we'll see the problem. However
>>> BundleA actually can't know about package name for jdbc_driver_classname
>>> beforehand, as the jdbc_driver_classname generally is passed in through
>>> configuration during runtime, it can't be determined during build time,
>>> so
>>> we can't add correct package import when we generate bundle A.
>>>>
>>>> The general solution is
>>>> 1. add dynamic import for bundle A(commons-dbcp)
>>>> or
>>>> 2. create JDBC driver as a fragment bundle, and attach it to bundle
>>>
>>> A(bundle A is host bundle now), so that all resource from fragment bundle
>>> is
>>> available for the host bundle.
>>>>
>>>> Solution 1 left less effort for end user and n servicemix wrapped
>>>
>>> commons-dbcp bundle we already have dynamic-import header and I think
>>> camel
>>> features should use the servicemix wrapped commons-dbcp bundle as well.
>>>>
>>>> I will append a patch soon.
>>>
>>> --
>>> This message is automatically generated by JIRA.
>>> For more information on JIRA, see: http://www.atlassian.com/software/jira
>>>
>>>
>>>
>
> ---------------------------------------------
> Freeman Fang
>
> FuseSource
> Email:ffang@fusesource.com
> Web: fusesource.com
> Twitter: freemanfang
> Blog: http://freemanfang.blogspot.com
>
>
>
>
>
>
>
>
>
>
--
Claus Ibsen
-----------------
FuseSource
Email: cibsen@fusesource.com
Web: http://fusesource.com
Twitter: davsclaus, fusenews
Blog: http://davsclaus.blogspot.com/
Author of Camel in Action: http://www.manning.com/ibsen/
Re: [jira] [Commented] (CAMEL-4308) commons-dbcp bundle used in camel feature.xml doesn't allow dynamic imports
Posted by Freeman Fang <fr...@gmail.com>.
Hi Christian,
Yeah, If camel team agree to upgrade to commons-dbcp 1.4 then we can
use SMX wrapped commons-dbcp 1.4 bundle directly.
If there's no other objection I'll append a patch which upgrade to
commons-dbcp 1.4 also.
Best Regards
Freeman
On 2011-8-6, at 上午12:50, Christian Müller wrote:
> I wonder is there a reason not to upgrade Camel to use commons-dbcp
> 1.4 when
> SMX already use this version?
>
> Best,
> Christian
>
> On Fri, Aug 5, 2011 at 9:27 AM, Freeman Fang (JIRA)
> <ji...@apache.org> wrote:
>
>>
>> [
>> https://issues.apache.org/jira/browse/CAMEL-4308?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13079810
>> #comment-13079810]
>>
>> Freeman Fang commented on CAMEL-4308:
>> -------------------------------------
>>
>> I noticed that camel now use commons-dbcp 1.3 but in servicemix we
>> have
>> wrapped commons-dbcp 1.2.2 and 1.4, so I create SMX4-892[1] and
>> will add
>> commons-dbcp 1.3 bundle in servicemix firstly.
>>
>> [1]https://issues.apache.org/jira/browse/SMX4-892
>>
>> Freeman
>>
>>> commons-dbcp bundle used in camel feature.xml doesn't allow dynamic
>> imports
>>>
>> ---------------------------------------------------------------------------
>>>
>>> Key: CAMEL-4308
>>> URL: https://issues.apache.org/jira/browse/CAMEL-4308
>>> Project: Camel
>>> Issue Type: Improvement
>>> Reporter: Freeman Fang
>>>
>>> currently the commons-dbcp bundle used in camel feature.xml
>>> doesn't allow
>> dynamic imports, it will cause exception like
>>> org.apache.commons.dbcp.SQLNestedException: Cannot load JDBC
>>> driver class
>> 'oracle.jdbc.driver.OracleDriver'
>>> as
>>> JDBC driver class not found actually is a common issue in OSGi
>>> container,
>> this problem generally from a bundle(let's say it bundle A, commons-
>> dbcp in
>> this case) using some code like classForName(jdbc_driver_classname)
>> to init
>> a jdbc driver class, this is a big problem in OSGi world, as if
>> BundleA not
>> import package for jdbc_driver_classname, we'll see the problem.
>> However
>> BundleA actually can't know about package name for
>> jdbc_driver_classname
>> beforehand, as the jdbc_driver_classname generally is passed in
>> through
>> configuration during runtime, it can't be determined during build
>> time, so
>> we can't add correct package import when we generate bundle A.
>>> The general solution is
>>> 1. add dynamic import for bundle A(commons-dbcp)
>>> or
>>> 2. create JDBC driver as a fragment bundle, and attach it to bundle
>> A(bundle A is host bundle now), so that all resource from fragment
>> bundle is
>> available for the host bundle.
>>> Solution 1 left less effort for end user and n servicemix wrapped
>> commons-dbcp bundle we already have dynamic-import header and I
>> think camel
>> features should use the servicemix wrapped commons-dbcp bundle as
>> well.
>>> I will append a patch soon.
>>
>> --
>> This message is automatically generated by JIRA.
>> For more information on JIRA, see: http://www.atlassian.com/software/jira
>>
>>
>>
---------------------------------------------
Freeman Fang
FuseSource
Email:ffang@fusesource.com
Web: fusesource.com
Twitter: freemanfang
Blog: http://freemanfang.blogspot.com
Re: [jira] [Commented] (CAMEL-4308) commons-dbcp bundle used in camel
feature.xml doesn't allow dynamic imports
Posted by Christian Müller <ch...@gmail.com>.
I wonder is there a reason not to upgrade Camel to use commons-dbcp 1.4 when
SMX already use this version?
Best,
Christian
On Fri, Aug 5, 2011 at 9:27 AM, Freeman Fang (JIRA) <ji...@apache.org> wrote:
>
> [
> https://issues.apache.org/jira/browse/CAMEL-4308?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13079810#comment-13079810]
>
> Freeman Fang commented on CAMEL-4308:
> -------------------------------------
>
> I noticed that camel now use commons-dbcp 1.3 but in servicemix we have
> wrapped commons-dbcp 1.2.2 and 1.4, so I create SMX4-892[1] and will add
> commons-dbcp 1.3 bundle in servicemix firstly.
>
> [1]https://issues.apache.org/jira/browse/SMX4-892
>
> Freeman
>
> > commons-dbcp bundle used in camel feature.xml doesn't allow dynamic
> imports
> >
> ---------------------------------------------------------------------------
> >
> > Key: CAMEL-4308
> > URL: https://issues.apache.org/jira/browse/CAMEL-4308
> > Project: Camel
> > Issue Type: Improvement
> > Reporter: Freeman Fang
> >
> > currently the commons-dbcp bundle used in camel feature.xml doesn't allow
> dynamic imports, it will cause exception like
> > org.apache.commons.dbcp.SQLNestedException: Cannot load JDBC driver class
> 'oracle.jdbc.driver.OracleDriver'
> > as
> > JDBC driver class not found actually is a common issue in OSGi container,
> this problem generally from a bundle(let's say it bundle A, commons-dbcp in
> this case) using some code like classForName(jdbc_driver_classname) to init
> a jdbc driver class, this is a big problem in OSGi world, as if BundleA not
> import package for jdbc_driver_classname, we'll see the problem. However
> BundleA actually can't know about package name for jdbc_driver_classname
> beforehand, as the jdbc_driver_classname generally is passed in through
> configuration during runtime, it can't be determined during build time, so
> we can't add correct package import when we generate bundle A.
> > The general solution is
> > 1. add dynamic import for bundle A(commons-dbcp)
> > or
> > 2. create JDBC driver as a fragment bundle, and attach it to bundle
> A(bundle A is host bundle now), so that all resource from fragment bundle is
> available for the host bundle.
> > Solution 1 left less effort for end user and n servicemix wrapped
> commons-dbcp bundle we already have dynamic-import header and I think camel
> features should use the servicemix wrapped commons-dbcp bundle as well.
> > I will append a patch soon.
>
> --
> This message is automatically generated by JIRA.
> For more information on JIRA, see: http://www.atlassian.com/software/jira
>
>
>