Ales Justin [http://community.jboss.org/people/alesj] created the discussion "Re: Weld-OSGi integration in AS7" To view the discussion, visit: http://community.jboss.org/message/605188#605188 -------------------------------------------------------------- Meaning it would need to get a hold of existing app. server' OSGi service registry and vice-versa. -------------------------------------------------------------- Reply to this message by going to Community [http://community.jboss.org/message/605188#605188] Start a new discussion in JBoss AS7 Development at Community [http://community.jboss.org/choose-container!input.jspa?contentType=1&...]

David Bosschaert [http://community.jboss.org/people/bosschaert] created the discussion "Re: Weld-OSGi integration in AS7" To view the discussion, visit: http://community.jboss.org/message/605391#605391 -------------------------------------------------------------- Thanks all for the responses. One hand I like the idea of not introducing any new Annotations and to simply do the injection based on type as CDI already does. Yes, the OSGi Service Registry might get full of CDI beans but I don't really see the problem with that. Service Lookups are generally based on type which means that all the services you're not interested in are ignored anyway. One the other hand, if you're injecting purely on type then you're certainly losing out on some of the OSGi service lookup features, for example filtering - which I think the weld-osgi project currenly also supports via an annotation. Maybe we can combine these two to offer the best of both worlds? Let's say we have the system enabled to provide a unified CDI/OSGi service registry view. (BTW re configuration we could look at OSGi Config Admin - AS7 has that built in). With no other qualifiers this would mean that @Inject's can be satisfied by any CDI bean or OSGi Service that matches the interface. The service should be proxied so that if it is replaced the client can continue to use the same proxy. Also all of the CDI beans would be available in the OSGi Service Registry. If the CDI client wants to put additional requirements on the OSGi Service (and is therefore aware of the OSGi integration) it can express this via additional @Filter or @OSGiService annotations. This would possibly include things like timeouts, dynamic flags etc. On the OSGi Service Consumer side. The consumer can narrow down the set of possibilities by using an ordinary filter. This could look up a CDI service by name (we'd have to come up with a service property to convey the name for a named bean) or additional properties (we might consider an annotation to add OSGi service properties to a CDI bean). So all in all, this would +allow+ for a relatively simple cross OSGi/CDI case to work without any special annotations, but it would give people the option to deviate/fine-tune is so needed... Thoughts? -------------------------------------------------------------- Reply to this message by going to Community [http://community.jboss.org/message/605391#605391] Start a new discussion in JBoss AS7 Development at Community [http://community.jboss.org/choose-container!input.jspa?contentType=1&...]

Sahoo Sahoo [http://community.jboss.org/people/sahoo] created the discussion "Re: Weld-OSGi integration in AS7" To view the discussion, visit: http://community.jboss.org/message/605501#605501 -------------------------------------------------------------- Yes, we add glassfish osgi-cdi portable extension to every CDI module's deployment classpath. A qualifier makes it more typesafe. More over, there is a departure from CDI model as some have already pointed out in this discussion thread, so we feel having an extra qualifier to indicate a dependency on a bean actually realized via an OSGi service makes more sense. -------------------------------------------------------------- Reply to this message by going to Community [http://community.jboss.org/message/605501#605501] Start a new discussion in JBoss AS7 Development at Community [http://community.jboss.org/choose-container!input.jspa?contentType=1&...]