Hi Harald, thanks for the input, I somehow have the feeling this would be a great FAQ for the CDI project :D
regards, Achim 2012/8/21 Harald Wellmann <[email protected]>: > See my comments inline. > >> 2012/8/20 Charles Moulliard <[email protected]>: >>> >>> - Is the goal of pax-cdi to become the reference implementation of OSGI >>> CDI >>> (http://blog.osgi.org/2012/05/osgicdi-integration-rfp-available-for.html) >>> as mentioned on pax-cdi home page? > > > Quoting from http://team.ops4j.org/wiki/display/PAXCDI/Pax+CDI: > > "Pax CDI shall evolve into an implementation of this forthcoming standard." > > Pax CDI is certainly not "the reference implementation", since a) the > referenced standard does not yet exist, and b) it's up to the OSGi Alliance > to nominate a reference implementation for a new standard. I don't think > projects proclaim *themselves* to be a RI ;-) > > >>> - As there is already an Apache project called Deltaspike to support CDI >>> injection in non J2EE environment, pax-cdi could benefit of using Apache >>> DeltaSpike to run weld, openwebbbeans, openeejb top of karaf ? > > > DeltaSpike supports all sorts of things, but OSGi is not yet one of them. > DeltaSpike does not even release OSGi artifacts. (See > https://issues.apache.org/jira/browse/DELTASPIKE-210) > > I don't see OpenEJB and Karaf in the picture. Pax CDI shall support any ASL > compatible JSR-299 implementation in any OSGi R4.3 framework. > > AFAIK, "non-J2EE" in DeltaSpike is currently mainly Java SE. OSGi is a > different story and requires a totally different approach to class loading. > > EJB support is not yet on the agenda for Pax CDI. Integration with Pax Web > is currently in progress, and the next big thing after that will be > @PersistenceContext support in combination with Pax JDBC and Pax JPA. > >>> - Is the goal of pax-cdi to be a facade, proxy top of existing CDI >>> containers (weld, ...) ? > > > Yes, of course. There are no plans to create a self-contained CDI > implementation. Pax CDI creates adapters to embed CDI implementations into > OSGi systems. > > At the moment, Pax CDI is mainly focused on OpenWebBeans, given that Weld > does not yet have an official release addressing the container singleton > issue in an OSGi-compatible way. > > See http://permalink.gmane.org/gmane.comp.java.ops4j.general/13897. > > A good deal of Weld support is already implemented, but we can't release > that as long as we depend on Weld snapshots. > >>> - How this integration will be achieved with Karaf (one CDI global >>> container or each bundle deployed on karaf will act as a light CDI >>> container (like we do with Spring - ApplicationContext) ? > > > Each bean bundle has its own CDI container. This is already implicit in RFP > 146: > > CDI023 – All the inter-bundle interaction between CDI beans MUST go through > the OSGi Service Registry. > > Best regards, > Harald > > > _______________________________________________ > general mailing list > [email protected] > http://lists.ops4j.org/mailman/listinfo/general -- Apache Karaf <http://karaf.apache.org/> Committer & PMC OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/> Committer & Project Lead OPS4J Pax for Vaadin <http://team.ops4j.org/wiki/display/PAXVAADIN/Home> Commiter & Project Lead blog <http://notizblog.nierbeck.de/> _______________________________________________ general mailing list [email protected] http://lists.ops4j.org/mailman/listinfo/general
