activemq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <david_jen...@yahoo.com>
Subject Re: amq 5.4 and osgi/blueprint
Date Sat, 06 Feb 2010 16:01:56 GMT

On Feb 6, 2010, at 2:54 AM, Hiram Chirino wrote:

> On Sat, Feb 6, 2010 at 5:17 AM, Guillaume Nodet <gnodet@gmail.com>  
> wrote:
>> On Fri, Feb 5, 2010 at 21:01, David Jencks <david_jencks@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/


Mime
View raw message