You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@activemq.apache.org by David Jencks <da...@yahoo.com> on 2010/02/05 21:01:07 UTC
amq 5.4 and osgi/blueprint
For the geronimo 3 amq integration I've been working on getting amq
5.4 to run in de-springified osgi/buleprint using the xbean-blueprint
NamespaceHandler I ported. I think I have at least a basic broker
starting up.
I'd like to make a few changes so this will work better:
1. Several classes use what I think are obsolete spring-isms namely
implementing the spring interfaces InitializingBean, DisposableBean,
and FactoryBean to tell spring stuff. IIUC a more up-to-date
technique is to set this in the xml or, using xbean, using InitMethod
and destroyMethod annotations. For the classes that are otherwise not
spring-dependent I'd like to switch to the xbean annotations. The
classes involved are:
activemq-pool/src/main/java/org/apache/activemq/pool/
PooledConnectionFactoryBean.java
activemq-camel/src/main/java/org/apache/activemq/camel/component/
CamelEndpointLoader.java
activemq-core/src/main/java/org/apache/activemq/spring/
ActiveMQConnectionFactory.java
activemq-core/src/main/java/org/apache/activemq/spring/
SpringSslContext.java
activemq-core/src/main/java/org/apache/activemq/spring/
ActiveMQXAConnectionFactory.java (has other spring-isms)
activemq-core/src/main/java/org/apache/activemq/broker/util/
LoggingBrokerPlugin.java
activemq-core/src/main/java/org/apache/activemq/broker/util/
CommandAgent.java
activemq-core/src/main/java/org/apache/activemq/filter/
DestinationMapEntry.java
In addition, I need to expose
activemq-core/src/main/java/org/apache/activemq/broker/
BrokerService.java
to xbean.
2. To allow other bundles to interact with amq in osgi, it looks like
org.apache.activemq.util.osgi.Activator needs to be run. One
possibility would be to just install it as the bundle activator for
activemq-core, this is what I've tried and appears to work OK. If
this doesn't seem like a good idea to everyone I think I can just
install it as a blueprint bean in a geronimo bundle.
Comments?
thanks
david jencks
Re: amq 5.4 and osgi/blueprint
Posted by David Jencks <da...@yahoo.com>.
I can't think of any potential problems either, so I gave it back its
default constructor and made it the Bundle-Activator for activemq-core.
many thanks
david jencks
On Feb 9, 2010, at 12:25 PM, Guillaume Nodet wrote:
> I think it would make sense to make the Activator class the real osgi
> activator for activemq-core.
> I don't really see why we would not do that, given it's the only way
> to use additional transports or other extensions afaik.
>
> On Tue, Feb 9, 2010 at 21:05, David Jencks <da...@yahoo.com>
> wrote:
>> See AMQ-2601, rev 908182.
>>
>> Plain spring recognizes the common annotations @PostConstruct and
>> @PreDeploy.
>> xbean-spring recognizes the xbean javadoc annotations InitMethod and
>> DestroyMethod
>> xbean-blueprint now recognizes both.
>>
>> I did some testing to check xbean-spring still works but it wasn't
>> very
>> thorough so if anyone sees a problem please speak up right away.
>>
>> Also, I added a constructor to the Activator class so it can be
>> used as a
>> blueprint bean, and this seems to work just as well as it being an
>> actual
>> BundleActivator.
>>
>> thanks
>> david jencks
>>
>> On Feb 6, 2010, at 8:01 AM, David Jencks wrote:
>>
>>>
>>> On Feb 6, 2010, at 2:54 AM, Hiram Chirino wrote:
>>>
>>>> On Sat, Feb 6, 2010 at 5:17 AM, Guillaume Nodet
>>>> <gn...@gmail.com> wrote:
>>>>>
>>>>> On Fri, Feb 5, 2010 at 21:01, David Jencks
>>>>> <da...@yahoo.com>
>>>>> wrote:
>>>>>>
>>>>>> For the geronimo 3 amq integration I've been working on getting
>>>>>> amq 5.4
>>>>>> to
>>>>>> run in de-springified osgi/buleprint using the xbean-blueprint
>>>>>> NamespaceHandler I ported. I think I have at least a basic
>>>>>> broker
>>>>>> starting
>>>>>> up.
>>>>>>
>>>>>> I'd like to make a few changes so this will work better:
>>>>>>
>>>>>> 1. Several classes use what I think are obsolete spring-isms
>>>>>> namely
>>>>>> implementing the spring interfaces InitializingBean,
>>>>>> DisposableBean,
>>>>>> and
>>>>>> FactoryBean to tell spring stuff. IIUC a more up-to-date
>>>>>> technique is
>>>>>> to
>>>>>> set this in the xml or, using xbean, using InitMethod and
>>>>>> destroyMethod
>>>>>> annotations. For the classes that are otherwise not spring-
>>>>>> dependent
>>>>>> I'd
>>>>>> like to switch to the xbean annotations. The classes involved
>>>>>> are:
>>>>>>
>>>>>>
>>>>>> activemq-pool/src/main/java/org/apache/activemq/pool/
>>>>>> PooledConnectionFactoryBean.java
>>>>>>
>>>>>> activemq-camel/src/main/java/org/apache/activemq/camel/
>>>>>> component/CamelEndpointLoader.java
>>>>>>
>>>>>> activemq-core/src/main/java/org/apache/activemq/spring/
>>>>>> ActiveMQConnectionFactory.java
>>>>>>
>>>>>> activemq-core/src/main/java/org/apache/activemq/spring/
>>>>>> SpringSslContext.java
>>>>>>
>>>>>> activemq-core/src/main/java/org/apache/activemq/spring/
>>>>>> ActiveMQXAConnectionFactory.java
>>>>>> (has other spring-isms)
>>>>>>
>>>>>> activemq-core/src/main/java/org/apache/activemq/broker/util/
>>>>>> LoggingBrokerPlugin.java
>>>>>>
>>>>>> activemq-core/src/main/java/org/apache/activemq/broker/util/
>>>>>> CommandAgent.java
>>>>>>
>>>>>> activemq-core/src/main/java/org/apache/activemq/filter/
>>>>>> DestinationMapEntry.java
>>>>>>
>>>>>
>>>>> I guess we should also annotate those methods with
>>>>> @PostConstruct and
>>>>> @PreDestroy annotation.
>>>
>>> Are these spring annotations? I'd rather not insert yet more
>>> spring-isms
>>> if not really necessary.
>>>
>>>>> I guess I'm slightly worried that our users configurations will
>>>>> jsut
>>>>> stop working or behave badly without
>>>>> much warning about it. Can xbean or spring automatically detect
>>>>> such
>>>>> annotations and do the necessary
>>>>> processing ?
>>>>>
>>>>> But I'm ok with the principle.
>>>>
>>>> Yeah i worry about that too.. Another approach could be to take the
>>>> class thats using spring interfaces.. lets call it X. (1) rename
>>>> it to
>>>> Y. (2) remove the interfaces from Y. Sub class Y and call it X
>>>> and
>>>> add the interfaces back in.
>>>>
>>>> That way you get a new Y class which is free from the spring
>>>> dependency yet you still have the original X class with the same
>>>> interface definition so that we can maintain a high degree of
>>>> backward
>>>> compatibility.
>>>
>>> That's certainly a possibility. However, these xbean psuedo-
>>> annotations
>>> work with xbean-spring as well as xbean-blueprint so the only
>>> people who
>>> would see a behavior change would be those who are not using xbean
>>> xml. Is
>>> this a large enough audience to keep happy to make this additional
>>> complexity worthwhile? If the @PostConstruct and @PreDestroy
>>> annotations
>>> are the even more up to data spring-ism would using those be
>>> adequate?
>>>
>>>>
>>>>>
>>>>>>
>>>>>> In addition, I need to expose
>>>>>>
>>>>>> activemq-core/src/main/java/org/apache/activemq/broker/
>>>>>> BrokerService.java
>>>>>> to xbean.
>>>>>>
>>>>>> 2. To allow other bundles to interact with amq in osgi, it
>>>>>> looks like
>>>>>> org.apache.activemq.util.osgi.Activator needs to be run. One
>>>>>> possibility
>>>>>> would be to just install it as the bundle activator for
>>>>>> activemq-core,
>>>>>> this
>>>>>> is what I've tried and appears to work OK. If this doesn't
>>>>>> seem like a
>>>>>> good
>>>>>> idea to everyone I think I can just install it as a blueprint
>>>>>> bean in a
>>>>>> geronimo bundle.
>>>>>
>>>>> What would the activator do ?
>>>
>>> The activator is already there. I'm not sure exactly what it
>>> does, but it
>>> appears to result in connector objects being created using classes
>>> consistent with the broker.
>>>>>
>>>>> A few I was thinking about for a better activemq / osgi
>>>>> integration are:
>>>>> * make sure we use version ranges everywhere and define which
>>>>> range we
>>>>> want to
>>>>> use for our activemq imports (in camel, we use [2.1,2.2) range
>>>>> for camel imports and [2,3)
>>>>> for other imports
>>>
>>> this seems pretty doable...
>>>>>
>>>>> * rework the discovery mechanism for transports and such so that
>>>>> it's more OSGI friendly
>>>
>>> I haven't thought about this yet.
>>>>>
>>>>> I guess those are quite independant on the blueprint stuff you're
>>>>> working on.
>>>
>>> I think so.
>>>
>>> thanks
>>> david jencks
>>>
>>>>>
>>>>>> Comments?
>>>>>>
>>>>>> thanks
>>>>>> david jencks
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Cheers,
>>>>> Guillaume Nodet
>>>>> ------------------------
>>>>> Blog: http://gnodet.blogspot.com/
>>>>> ------------------------
>>>>> Open Source SOA
>>>>> http://fusesource.com
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Regards,
>>>> Hiram
>>>>
>>>> Blog: http://hiramchirino.com
>>>>
>>>> Open Source SOA
>>>> http://fusesource.com/
>>>
>>
>>
>
>
>
> --
> Cheers,
> Guillaume Nodet
> ------------------------
> Blog: http://gnodet.blogspot.com/
> ------------------------
> Open Source SOA
> http://fusesource.com
Re: amq 5.4 and osgi/blueprint
Posted by Guillaume Nodet <gn...@gmail.com>.
I think it would make sense to make the Activator class the real osgi
activator for activemq-core.
I don't really see why we would not do that, given it's the only way
to use additional transports or other extensions afaik.
On Tue, Feb 9, 2010 at 21:05, David Jencks <da...@yahoo.com> wrote:
> See AMQ-2601, rev 908182.
>
> Plain spring recognizes the common annotations @PostConstruct and
> @PreDeploy.
> xbean-spring recognizes the xbean javadoc annotations InitMethod and
> DestroyMethod
> xbean-blueprint now recognizes both.
>
> I did some testing to check xbean-spring still works but it wasn't very
> thorough so if anyone sees a problem please speak up right away.
>
> Also, I added a constructor to the Activator class so it can be used as a
> blueprint bean, and this seems to work just as well as it being an actual
> BundleActivator.
>
> thanks
> david jencks
>
> On Feb 6, 2010, at 8:01 AM, David Jencks wrote:
>
>>
>> On Feb 6, 2010, at 2:54 AM, Hiram Chirino wrote:
>>
>>> On Sat, Feb 6, 2010 at 5:17 AM, Guillaume Nodet <gn...@gmail.com> wrote:
>>>>
>>>> On Fri, Feb 5, 2010 at 21:01, David Jencks <da...@yahoo.com>
>>>> wrote:
>>>>>
>>>>> For the geronimo 3 amq integration I've been working on getting amq 5.4
>>>>> to
>>>>> run in de-springified osgi/buleprint using the xbean-blueprint
>>>>> NamespaceHandler I ported. I think I have at least a basic broker
>>>>> starting
>>>>> up.
>>>>>
>>>>> I'd like to make a few changes so this will work better:
>>>>>
>>>>> 1. Several classes use what I think are obsolete spring-isms namely
>>>>> implementing the spring interfaces InitializingBean, DisposableBean,
>>>>> and
>>>>> FactoryBean to tell spring stuff. IIUC a more up-to-date technique is
>>>>> to
>>>>> set this in the xml or, using xbean, using InitMethod and destroyMethod
>>>>> annotations. For the classes that are otherwise not spring-dependent
>>>>> I'd
>>>>> like to switch to the xbean annotations. The classes involved are:
>>>>>
>>>>>
>>>>> activemq-pool/src/main/java/org/apache/activemq/pool/PooledConnectionFactoryBean.java
>>>>>
>>>>> activemq-camel/src/main/java/org/apache/activemq/camel/component/CamelEndpointLoader.java
>>>>>
>>>>> activemq-core/src/main/java/org/apache/activemq/spring/ActiveMQConnectionFactory.java
>>>>>
>>>>> activemq-core/src/main/java/org/apache/activemq/spring/SpringSslContext.java
>>>>>
>>>>> activemq-core/src/main/java/org/apache/activemq/spring/ActiveMQXAConnectionFactory.java
>>>>> (has other spring-isms)
>>>>>
>>>>> activemq-core/src/main/java/org/apache/activemq/broker/util/LoggingBrokerPlugin.java
>>>>>
>>>>> activemq-core/src/main/java/org/apache/activemq/broker/util/CommandAgent.java
>>>>>
>>>>> activemq-core/src/main/java/org/apache/activemq/filter/DestinationMapEntry.java
>>>>>
>>>>
>>>> I guess we should also annotate those methods with @PostConstruct and
>>>> @PreDestroy annotation.
>>
>> Are these spring annotations? I'd rather not insert yet more spring-isms
>> if not really necessary.
>>
>>>> I guess I'm slightly worried that our users configurations will jsut
>>>> stop working or behave badly without
>>>> much warning about it. Can xbean or spring automatically detect such
>>>> annotations and do the necessary
>>>> processing ?
>>>>
>>>> But I'm ok with the principle.
>>>
>>> Yeah i worry about that too.. Another approach could be to take the
>>> class thats using spring interfaces.. lets call it X. (1) rename it to
>>> Y. (2) remove the interfaces from Y. Sub class Y and call it X and
>>> add the interfaces back in.
>>>
>>> That way you get a new Y class which is free from the spring
>>> dependency yet you still have the original X class with the same
>>> interface definition so that we can maintain a high degree of backward
>>> compatibility.
>>
>> That's certainly a possibility. However, these xbean psuedo-annotations
>> work with xbean-spring as well as xbean-blueprint so the only people who
>> would see a behavior change would be those who are not using xbean xml. Is
>> this a large enough audience to keep happy to make this additional
>> complexity worthwhile? If the @PostConstruct and @PreDestroy annotations
>> are the even more up to data spring-ism would using those be adequate?
>>
>>>
>>>>
>>>>>
>>>>> In addition, I need to expose
>>>>>
>>>>> activemq-core/src/main/java/org/apache/activemq/broker/BrokerService.java
>>>>> to xbean.
>>>>>
>>>>> 2. To allow other bundles to interact with amq in osgi, it looks like
>>>>> org.apache.activemq.util.osgi.Activator needs to be run. One
>>>>> possibility
>>>>> would be to just install it as the bundle activator for activemq-core,
>>>>> this
>>>>> is what I've tried and appears to work OK. If this doesn't seem like a
>>>>> good
>>>>> idea to everyone I think I can just install it as a blueprint bean in a
>>>>> geronimo bundle.
>>>>
>>>> What would the activator do ?
>>
>> The activator is already there. I'm not sure exactly what it does, but it
>> appears to result in connector objects being created using classes
>> consistent with the broker.
>>>>
>>>> A few I was thinking about for a better activemq / osgi integration are:
>>>> * make sure we use version ranges everywhere and define which range we
>>>> want to
>>>> use for our activemq imports (in camel, we use [2.1,2.2) range
>>>> for camel imports and [2,3)
>>>> for other imports
>>
>> this seems pretty doable...
>>>>
>>>> * rework the discovery mechanism for transports and such so that
>>>> it's more OSGI friendly
>>
>> I haven't thought about this yet.
>>>>
>>>> I guess those are quite independant on the blueprint stuff you're
>>>> working on.
>>
>> I think so.
>>
>> thanks
>> david jencks
>>
>>>>
>>>>> Comments?
>>>>>
>>>>> thanks
>>>>> david jencks
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Cheers,
>>>> Guillaume Nodet
>>>> ------------------------
>>>> Blog: http://gnodet.blogspot.com/
>>>> ------------------------
>>>> Open Source SOA
>>>> http://fusesource.com
>>>>
>>>
>>>
>>>
>>> --
>>> Regards,
>>> Hiram
>>>
>>> Blog: http://hiramchirino.com
>>>
>>> Open Source SOA
>>> http://fusesource.com/
>>
>
>
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com
Re: amq 5.4 and osgi/blueprint
Posted by David Jencks <da...@yahoo.com>.
See AMQ-2601, rev 908182.
Plain spring recognizes the common annotations @PostConstruct and
@PreDeploy.
xbean-spring recognizes the xbean javadoc annotations InitMethod and
DestroyMethod
xbean-blueprint now recognizes both.
I did some testing to check xbean-spring still works but it wasn't
very thorough so if anyone sees a problem please speak up right away.
Also, I added a constructor to the Activator class so it can be used
as a blueprint bean, and this seems to work just as well as it being
an actual BundleActivator.
thanks
david jencks
On Feb 6, 2010, at 8:01 AM, David Jencks wrote:
>
> On Feb 6, 2010, at 2:54 AM, Hiram Chirino wrote:
>
>> On Sat, Feb 6, 2010 at 5:17 AM, Guillaume Nodet <gn...@gmail.com>
>> wrote:
>>> On Fri, Feb 5, 2010 at 21:01, David Jencks
>>> <da...@yahoo.com> wrote:
>>>> For the geronimo 3 amq integration I've been working on getting
>>>> amq 5.4 to
>>>> run in de-springified osgi/buleprint using the xbean-blueprint
>>>> NamespaceHandler I ported. I think I have at least a basic
>>>> broker starting
>>>> up.
>>>>
>>>> I'd like to make a few changes so this will work better:
>>>>
>>>> 1. Several classes use what I think are obsolete spring-isms namely
>>>> implementing the spring interfaces InitializingBean,
>>>> DisposableBean, and
>>>> FactoryBean to tell spring stuff. IIUC a more up-to-date
>>>> technique is to
>>>> set this in the xml or, using xbean, using InitMethod and
>>>> destroyMethod
>>>> annotations. For the classes that are otherwise not spring-
>>>> dependent I'd
>>>> like to switch to the xbean annotations. The classes involved are:
>>>>
>>>> activemq-pool/src/main/java/org/apache/activemq/pool/
>>>> PooledConnectionFactoryBean.java
>>>> activemq-camel/src/main/java/org/apache/activemq/camel/component/
>>>> CamelEndpointLoader.java
>>>> activemq-core/src/main/java/org/apache/activemq/spring/
>>>> ActiveMQConnectionFactory.java
>>>> activemq-core/src/main/java/org/apache/activemq/spring/
>>>> SpringSslContext.java
>>>> activemq-core/src/main/java/org/apache/activemq/spring/
>>>> ActiveMQXAConnectionFactory.java
>>>> (has other spring-isms)
>>>> activemq-core/src/main/java/org/apache/activemq/broker/util/
>>>> LoggingBrokerPlugin.java
>>>> activemq-core/src/main/java/org/apache/activemq/broker/util/
>>>> CommandAgent.java
>>>> activemq-core/src/main/java/org/apache/activemq/filter/
>>>> DestinationMapEntry.java
>>>>
>>>
>>> I guess we should also annotate those methods with @PostConstruct
>>> and
>>> @PreDestroy annotation.
>
> Are these spring annotations? I'd rather not insert yet more spring-
> isms if not really necessary.
>
>>> I guess I'm slightly worried that our users configurations will jsut
>>> stop working or behave badly without
>>> much warning about it. Can xbean or spring automatically detect
>>> such
>>> annotations and do the necessary
>>> processing ?
>>>
>>> But I'm ok with the principle.
>>
>> Yeah i worry about that too.. Another approach could be to take the
>> class thats using spring interfaces.. lets call it X. (1) rename it
>> to
>> Y. (2) remove the interfaces from Y. Sub class Y and call it X and
>> add the interfaces back in.
>>
>> That way you get a new Y class which is free from the spring
>> dependency yet you still have the original X class with the same
>> interface definition so that we can maintain a high degree of
>> backward
>> compatibility.
>
> That's certainly a possibility. However, these xbean psuedo-
> annotations work with xbean-spring as well as xbean-blueprint so the
> only people who would see a behavior change would be those who are
> not using xbean xml. Is this a large enough audience to keep happy
> to make this additional complexity worthwhile? If the
> @PostConstruct and @PreDestroy annotations are the even more up to
> data spring-ism would using those be adequate?
>
>>
>>>
>>>>
>>>> In addition, I need to expose
>>>> activemq-core/src/main/java/org/apache/activemq/broker/
>>>> BrokerService.java
>>>> to xbean.
>>>>
>>>> 2. To allow other bundles to interact with amq in osgi, it looks
>>>> like
>>>> org.apache.activemq.util.osgi.Activator needs to be run. One
>>>> possibility
>>>> would be to just install it as the bundle activator for activemq-
>>>> core, this
>>>> is what I've tried and appears to work OK. If this doesn't seem
>>>> like a good
>>>> idea to everyone I think I can just install it as a blueprint
>>>> bean in a
>>>> geronimo bundle.
>>>
>>> What would the activator do ?
>
> The activator is already there. I'm not sure exactly what it does,
> but it appears to result in connector objects being created using
> classes consistent with the broker.
>>>
>>> A few I was thinking about for a better activemq / osgi
>>> integration are:
>>> * make sure we use version ranges everywhere and define which
>>> range we want to
>>> use for our activemq imports (in camel, we use [2.1,2.2) range
>>> for camel imports and [2,3)
>>> for other imports
>
> this seems pretty doable...
>>> * rework the discovery mechanism for transports and such so that
>>> it's more OSGI friendly
>
> I haven't thought about this yet.
>>> I guess those are quite independant on the blueprint stuff you're
>>> working on.
>
> I think so.
>
> thanks
> david jencks
>
>>>
>>>> Comments?
>>>>
>>>> thanks
>>>> david jencks
>>>>
>>>>
>>>
>>>
>>>
>>> --
>>> Cheers,
>>> Guillaume Nodet
>>> ------------------------
>>> Blog: http://gnodet.blogspot.com/
>>> ------------------------
>>> Open Source SOA
>>> http://fusesource.com
>>>
>>
>>
>>
>> --
>> Regards,
>> Hiram
>>
>> Blog: http://hiramchirino.com
>>
>> Open Source SOA
>> http://fusesource.com/
>
Re: amq 5.4 and osgi/blueprint
Posted by David Jencks <da...@yahoo.com>.
On Feb 6, 2010, at 2:54 AM, Hiram Chirino wrote:
> On Sat, Feb 6, 2010 at 5:17 AM, Guillaume Nodet <gn...@gmail.com>
> wrote:
>> On Fri, Feb 5, 2010 at 21:01, David Jencks <da...@yahoo.com>
>> wrote:
>>> For the geronimo 3 amq integration I've been working on getting
>>> amq 5.4 to
>>> run in de-springified osgi/buleprint using the xbean-blueprint
>>> NamespaceHandler I ported. I think I have at least a basic broker
>>> starting
>>> up.
>>>
>>> I'd like to make a few changes so this will work better:
>>>
>>> 1. Several classes use what I think are obsolete spring-isms namely
>>> implementing the spring interfaces InitializingBean,
>>> DisposableBean, and
>>> FactoryBean to tell spring stuff. IIUC a more up-to-date
>>> technique is to
>>> set this in the xml or, using xbean, using InitMethod and
>>> destroyMethod
>>> annotations. For the classes that are otherwise not spring-
>>> dependent I'd
>>> like to switch to the xbean annotations. The classes involved are:
>>>
>>> activemq-pool/src/main/java/org/apache/activemq/pool/
>>> PooledConnectionFactoryBean.java
>>> activemq-camel/src/main/java/org/apache/activemq/camel/component/
>>> CamelEndpointLoader.java
>>> activemq-core/src/main/java/org/apache/activemq/spring/
>>> ActiveMQConnectionFactory.java
>>> activemq-core/src/main/java/org/apache/activemq/spring/
>>> SpringSslContext.java
>>> activemq-core/src/main/java/org/apache/activemq/spring/
>>> ActiveMQXAConnectionFactory.java
>>> (has other spring-isms)
>>> activemq-core/src/main/java/org/apache/activemq/broker/util/
>>> LoggingBrokerPlugin.java
>>> activemq-core/src/main/java/org/apache/activemq/broker/util/
>>> CommandAgent.java
>>> activemq-core/src/main/java/org/apache/activemq/filter/
>>> DestinationMapEntry.java
>>>
>>
>> I guess we should also annotate those methods with @PostConstruct and
>> @PreDestroy annotation.
Are these spring annotations? I'd rather not insert yet more spring-
isms if not really necessary.
>> I guess I'm slightly worried that our users configurations will jsut
>> stop working or behave badly without
>> much warning about it. Can xbean or spring automatically detect such
>> annotations and do the necessary
>> processing ?
>>
>> But I'm ok with the principle.
>
> Yeah i worry about that too.. Another approach could be to take the
> class thats using spring interfaces.. lets call it X. (1) rename it to
> Y. (2) remove the interfaces from Y. Sub class Y and call it X and
> add the interfaces back in.
>
> That way you get a new Y class which is free from the spring
> dependency yet you still have the original X class with the same
> interface definition so that we can maintain a high degree of backward
> compatibility.
That's certainly a possibility. However, these xbean psuedo-
annotations work with xbean-spring as well as xbean-blueprint so the
only people who would see a behavior change would be those who are not
using xbean xml. Is this a large enough audience to keep happy to
make this additional complexity worthwhile? If the @PostConstruct and
@PreDestroy annotations are the even more up to data spring-ism would
using those be adequate?
>
>>
>>>
>>> In addition, I need to expose
>>> activemq-core/src/main/java/org/apache/activemq/broker/
>>> BrokerService.java
>>> to xbean.
>>>
>>> 2. To allow other bundles to interact with amq in osgi, it looks
>>> like
>>> org.apache.activemq.util.osgi.Activator needs to be run. One
>>> possibility
>>> would be to just install it as the bundle activator for activemq-
>>> core, this
>>> is what I've tried and appears to work OK. If this doesn't seem
>>> like a good
>>> idea to everyone I think I can just install it as a blueprint bean
>>> in a
>>> geronimo bundle.
>>
>> What would the activator do ?
The activator is already there. I'm not sure exactly what it does,
but it appears to result in connector objects being created using
classes consistent with the broker.
>>
>> A few I was thinking about for a better activemq / osgi integration
>> are:
>> * make sure we use version ranges everywhere and define which
>> range we want to
>> use for our activemq imports (in camel, we use [2.1,2.2) range
>> for camel imports and [2,3)
>> for other imports
this seems pretty doable...
>> * rework the discovery mechanism for transports and such so that
>> it's more OSGI friendly
I haven't thought about this yet.
>> I guess those are quite independant on the blueprint stuff you're
>> working on.
I think so.
thanks
david jencks
>>
>>> Comments?
>>>
>>> thanks
>>> david jencks
>>>
>>>
>>
>>
>>
>> --
>> Cheers,
>> Guillaume Nodet
>> ------------------------
>> Blog: http://gnodet.blogspot.com/
>> ------------------------
>> Open Source SOA
>> http://fusesource.com
>>
>
>
>
> --
> Regards,
> Hiram
>
> Blog: http://hiramchirino.com
>
> Open Source SOA
> http://fusesource.com/
Re: amq 5.4 and osgi/blueprint
Posted by Hiram Chirino <hi...@hiramchirino.com>.
On Sat, Feb 6, 2010 at 5:17 AM, Guillaume Nodet <gn...@gmail.com> wrote:
> On Fri, Feb 5, 2010 at 21:01, David Jencks <da...@yahoo.com> wrote:
>> For the geronimo 3 amq integration I've been working on getting amq 5.4 to
>> run in de-springified osgi/buleprint using the xbean-blueprint
>> NamespaceHandler I ported. I think I have at least a basic broker starting
>> up.
>>
>> I'd like to make a few changes so this will work better:
>>
>> 1. Several classes use what I think are obsolete spring-isms namely
>> implementing the spring interfaces InitializingBean, DisposableBean, and
>> FactoryBean to tell spring stuff. IIUC a more up-to-date technique is to
>> set this in the xml or, using xbean, using InitMethod and destroyMethod
>> annotations. For the classes that are otherwise not spring-dependent I'd
>> like to switch to the xbean annotations. The classes involved are:
>>
>> activemq-pool/src/main/java/org/apache/activemq/pool/PooledConnectionFactoryBean.java
>> activemq-camel/src/main/java/org/apache/activemq/camel/component/CamelEndpointLoader.java
>> activemq-core/src/main/java/org/apache/activemq/spring/ActiveMQConnectionFactory.java
>> activemq-core/src/main/java/org/apache/activemq/spring/SpringSslContext.java
>> activemq-core/src/main/java/org/apache/activemq/spring/ActiveMQXAConnectionFactory.java
>> (has other spring-isms)
>> activemq-core/src/main/java/org/apache/activemq/broker/util/LoggingBrokerPlugin.java
>> activemq-core/src/main/java/org/apache/activemq/broker/util/CommandAgent.java
>> activemq-core/src/main/java/org/apache/activemq/filter/DestinationMapEntry.java
>>
>
> I guess we should also annotate those methods with @PostConstruct and
> @PreDestroy annotation.
> I guess I'm slightly worried that our users configurations will jsut
> stop working or behave badly without
> much warning about it. Can xbean or spring automatically detect such
> annotations and do the necessary
> processing ?
>
> But I'm ok with the principle.
Yeah i worry about that too.. Another approach could be to take the
class thats using spring interfaces.. lets call it X. (1) rename it to
Y. (2) remove the interfaces from Y. Sub class Y and call it X and
add the interfaces back in.
That way you get a new Y class which is free from the spring
dependency yet you still have the original X class with the same
interface definition so that we can maintain a high degree of backward
compatibility.
>
>>
>> In addition, I need to expose
>> activemq-core/src/main/java/org/apache/activemq/broker/BrokerService.java
>> to xbean.
>>
>> 2. To allow other bundles to interact with amq in osgi, it looks like
>> org.apache.activemq.util.osgi.Activator needs to be run. One possibility
>> would be to just install it as the bundle activator for activemq-core, this
>> is what I've tried and appears to work OK. If this doesn't seem like a good
>> idea to everyone I think I can just install it as a blueprint bean in a
>> geronimo bundle.
>
> What would the activator do ?
>
> A few I was thinking about for a better activemq / osgi integration are:
> * make sure we use version ranges everywhere and define which range we want to
> use for our activemq imports (in camel, we use [2.1,2.2) range
> for camel imports and [2,3)
> for other imports
> * rework the discovery mechanism for transports and such so that
> it's more OSGI friendly
> I guess those are quite independant on the blueprint stuff you're working on.
>
>> Comments?
>>
>> thanks
>> david jencks
>>
>>
>
>
>
> --
> Cheers,
> Guillaume Nodet
> ------------------------
> Blog: http://gnodet.blogspot.com/
> ------------------------
> Open Source SOA
> http://fusesource.com
>
--
Regards,
Hiram
Blog: http://hiramchirino.com
Open Source SOA
http://fusesource.com/
Re: amq 5.4 and osgi/blueprint
Posted by Guillaume Nodet <gn...@gmail.com>.
On Fri, Feb 5, 2010 at 21:01, David Jencks <da...@yahoo.com> wrote:
> For the geronimo 3 amq integration I've been working on getting amq 5.4 to
> run in de-springified osgi/buleprint using the xbean-blueprint
> NamespaceHandler I ported. I think I have at least a basic broker starting
> up.
>
> I'd like to make a few changes so this will work better:
>
> 1. Several classes use what I think are obsolete spring-isms namely
> implementing the spring interfaces InitializingBean, DisposableBean, and
> FactoryBean to tell spring stuff. IIUC a more up-to-date technique is to
> set this in the xml or, using xbean, using InitMethod and destroyMethod
> annotations. For the classes that are otherwise not spring-dependent I'd
> like to switch to the xbean annotations. The classes involved are:
>
> activemq-pool/src/main/java/org/apache/activemq/pool/PooledConnectionFactoryBean.java
> activemq-camel/src/main/java/org/apache/activemq/camel/component/CamelEndpointLoader.java
> activemq-core/src/main/java/org/apache/activemq/spring/ActiveMQConnectionFactory.java
> activemq-core/src/main/java/org/apache/activemq/spring/SpringSslContext.java
> activemq-core/src/main/java/org/apache/activemq/spring/ActiveMQXAConnectionFactory.java
> (has other spring-isms)
> activemq-core/src/main/java/org/apache/activemq/broker/util/LoggingBrokerPlugin.java
> activemq-core/src/main/java/org/apache/activemq/broker/util/CommandAgent.java
> activemq-core/src/main/java/org/apache/activemq/filter/DestinationMapEntry.java
>
I guess we should also annotate those methods with @PostConstruct and
@PreDestroy annotation.
I guess I'm slightly worried that our users configurations will jsut
stop working or behave badly without
much warning about it. Can xbean or spring automatically detect such
annotations and do the necessary
processing ?
But I'm ok with the principle.
>
> In addition, I need to expose
> activemq-core/src/main/java/org/apache/activemq/broker/BrokerService.java
> to xbean.
>
> 2. To allow other bundles to interact with amq in osgi, it looks like
> org.apache.activemq.util.osgi.Activator needs to be run. One possibility
> would be to just install it as the bundle activator for activemq-core, this
> is what I've tried and appears to work OK. If this doesn't seem like a good
> idea to everyone I think I can just install it as a blueprint bean in a
> geronimo bundle.
What would the activator do ?
A few I was thinking about for a better activemq / osgi integration are:
* make sure we use version ranges everywhere and define which range we want to
use for our activemq imports (in camel, we use [2.1,2.2) range
for camel imports and [2,3)
for other imports
* rework the discovery mechanism for transports and such so that
it's more OSGI friendly
I guess those are quite independant on the blueprint stuff you're working on.
> Comments?
>
> thanks
> david jencks
>
>
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com