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 Wed, 10 Feb 2010 07:51:41 GMT
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 <david_jencks@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  
>>>> <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/
>>>
>>
>>
>
>
>
> -- 
> Cheers,
> Guillaume Nodet
> ------------------------
> Blog: http://gnodet.blogspot.com/
> ------------------------
> Open Source SOA
> http://fusesource.com


Mime
View raw message