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 <[email protected]> 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 <[email protected]> wrote: >>>> >>>> On Fri, Feb 5, 2010 at 21:01, David Jencks <[email protected]> >>>> 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
