Hi! I honestly think this turns into the wrong direction.
aOWB is not _only_ targeted for EE6 Application Servers, but mainly for the WebProfile amongst others (including SE!). We did a really good job in providing a system which came with almost no dependencies in it's core. Our plugins more and more got moved from the the original meaning of providing integration with a certain spec API (e.g. JPA, JMS, JSF) into a landfill of 'similar business areas'. I think this is the wrong way and we should aim for a much clearer separation of integrating different (unrelated) specs. Other projects do also support e.g. the new JSR-303 spec but do not force the user to import a validation-api.jar. It originally was a 3 layered design 1. layer: the core 2. layer: the plugins for each additional spec 3. layer: the SPI implementations to fill the plugins (and core technologies) with actual life and adopt them to different implementations By moving ALL SPI (the ones from core PLUS the ones from the plugins) into the SPI module, we lost parts of our modularity. Because the SPI interfaces have dependency to EL, Validator, etc. Do you see what I mean? LieGrue, strub --- Gurkan Erdogdu <[email protected]> schrieb am Fr, 19.2.2010: > Von: Gurkan Erdogdu <[email protected]> > Betreff: Re: resource injection capabilities got removed as a plugin? > An: [email protected] > Datum: Freitag, 19. Februar, 2010 13:07 Uhr > One thing I forget that we may add > more configuration options besides > openwebbeans.properties. For example using system > properties, program > arguments , and some programmatic access etc. > > 2010/2/19 Gurkan Erdogdu <[email protected]> > > > Hi; > > > > Every framework has a some sorts of configuration to > use :). OWB is > > targeted for Java EE 6 servers that provides all > Java EE defined > > requirements that one of is that injecting Java EE > resources into managed > > beans. Therefore our SPI is provided to container > vendors implementing Java > > EE 6 servers that want to use our OWB core. If anyone > wants to use OWB core > > in its environment, he has to provide its own SPI > implementations. > > > > Plugins are much more coarse grained than SPIs > and they are totally > > different usage then SPIs. For example, we mainly use > plugins for > > supporting some technologies that may not be included > in lightweight > > containers for example, Tomcat, Jetty etc. In other > words,they are mainly > > implemented for extending the OWB core. They may not > be related with Java EE > > Requirements or TCK etc. On the other hand, SPIs are > required by Java > > EE/JSR-299 specifications. Every container vendor must > provide those > > services. > > > > Currently we have three plugins > > > > 1* JMS Plugin --> For JMS support > > 2* EJB PLugin --> For embedded OpenEJB in Tomcat > support > > 3* JSF PLugin --> JSF support on > conversations.(Maybe this may not be a > > plugin) > > > > SPIs are different from plugins. OWB core requires to > use SPI > > implementation to do its job but it is not dependent > on any plugin. > > Therefore, we provide Default Services. > > > > For resource injections, OWB requires to use "Resource > Injection Service" > > for Java EE requirements. Lastly, OWB is part of the > Java EE 6. Please do > > not swallow this. > > > > For configuration issues, as I said in the beginning > every framework/server > > has some own configuration files. It provides default > configurations as > > builtin. If user do not happy with defaults, it has to > write its own and > > obey the rules of the OWB. > > > > > > >>>Otoh our plugin mechanism is pretty old, > and possibly can get replaced > > via the standard extension mechanisms? wdyt? > > I do not support to change it. As I said, plugins are > mainly used for > > extending the OWB core. For example, if we wish to > write something that is > > not necessary to implement regarding to Java > EE/JSR-299 we could write > > plugin for it and anyone use it with dropping it into > classpath. > > > > 2010/2/19 Mark Struberg <[email protected]> > > > > Hi! > >> > >> I know it doesn't make that much difference from a > technical perspective, > >> but having > >> > >> > >> > org.apache.webbeans.spi.ResourceInjectionService=org.apache.webbeans.se.DefaultResourceInjectionService > >> > >> as a default means that the simple dropping your > plugin in the classpath > >> and all 'just works' (tm) doesn't work anymore. > >> > >> instead each user has to manually create an > openwebbeans.properties file > >> and maintain all changes we run through. > >> > >> Think this is not really an increase of > user-friendlyness. > >> > >> Otoh our plugin mechanism is pretty old, and > possibly can get replaced via > >> the standard extension mechanisms? wdyt? > >> > >> LieGrue, > >> strub > >> > >> > __________________________________________________ > >> Do You Yahoo!? > >> Sie sind Spam leid? Yahoo! Mail verfügt über > einen herausragenden Schutz > >> gegen Massenmails. > >> http://mail.yahoo.com > >> > > > > > > > > -- > > Gurkan Erdogdu > > http://gurkanerdogdu.blogspot.com > > > > > > -- > Gurkan Erdogdu > http://gurkanerdogdu.blogspot.com > __________________________________________________ Do You Yahoo!? Sie sind Spam leid? Yahoo! Mail verfügt über einen herausragenden Schutz gegen Massenmails. http://mail.yahoo.com
