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 Tue, 09 Feb 2010 20:05:26 GMT
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 <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