Re: [DISCUSS] Spring - CDI Integration in DeltaSpike
I still am a participant on this thread, but doing more reading than writing as of late :) So, yes, I've been strapped for time with the job and the transition, but I'd be happy to help out with this at the end of the week or early next. With my CLA on file, and the code being granted already, I'm not sure what else needs to be done. I'm happy for the code to live in DeltaSpike, fwiw. On 2013-02-18, at 6:50 PM, Matt Benson gudnabr...@gmail.com wrote: Seems Marius's prior participation on this thread was via a gmail address. With him no longer at Red Hat we definitely want to make sure we take the necessary precautions wrt IP. Matt On Mon, Feb 18, 2013 at 5:31 PM, Jason Porter lightguard...@gmail.comwrote: I'm pretty sure we've granted Seam Spring to Apache. I'll need to check to see if Marius has subscribed to this list on a personal email as he has embarked on a new adventure outside of Red Hat. On Mon, Feb 18, 2013 at 4:27 PM, Matt Benson gudnabr...@gmail.com wrote: Let me refine my plan to say that it would be *best* if Marius does the commit since AIUI this is mostly code he personally authored, but as long as RH intends for Seam-Spring to be donated to Apache deltaspike, probably no irreparable *harm* would be caused by another Red Hatter pulling the trigger. Matt On Mon, Feb 18, 2013 at 5:25 PM, Matt Benson gudnabr...@gmail.com wrote: I think this received enough +1 votes (I'll add mine now) to proceed. If a Red Hatter (Marius?) would do the simplest repackaging possible and commit that then others could join in the quest to modularize the hell out of it. :) Presumably we'd do this on a branch until considered baked enough to merge to master. Let's go! Matt On Mon, Oct 15, 2012 at 10:55 AM, Arne Limburg arne.limb...@openknowledge.de wrote: Hi, Some ideas from my side, too ([1] and [2]). Unfortunately it is in german. But everyone of you can read the code. We used an advanced version of that code to build a Spring-CDI-Bridge in a large project. Unfortunately meanwhile the project is completely migrated to CDI and the code is lost in subversion. Will see, if I find the final version and can donate it. Cheers, Arne [1] http://www.openknowledge.de/blog/article/integration-von-spring-in-cdi-uebe r-eine-cdi-extension-erster-teil.html http://www.openknowledge.de/blog/article/integration-von-spring-in-cdi-ueber-eine-cdi-extension-erster-teil.html [2] http://www.openknowledge.de/blog/article/integration-von-spring-in-cdi-uebe r-eine-cdi-extension-zweiter-teil.html http://www.openknowledge.de/blog/article/integration-von-spring-in-cdi-ueber-eine-cdi-extension-zweiter-teil.html Am 15.10.12 17:16 schrieb Jason Porter unter lightguard...@gmail.com: You have my +1 Marius. If we can rouse the CDISource guys (mostly Rick) they may have some ideas as well. On Mon, Oct 15, 2012 at 1:53 AM, Antoine Sabot-Durand anto...@sabot-durand.net wrote: +1 it would definitively improve Java EE and CDI adoption. Antoine SABOT-DURAND Le 15 oct. 2012 à 09:41, Romain Manni-Bucau rmannibu...@gmail.com a écrit : +1 (since DS manages spring context lifecycle) *Romain Manni-Bucau* *Twitter: @rmannibucau https://twitter.com/rmannibucau* *Blog: **http://rmannibucau.wordpress.com/* http://rmannibucau.wordpress.com/ *LinkedIn: **http://fr.linkedin.com/in/rmannibucau* *Github: https://github.com/rmannibucau* 2012/10/15 Mark Struberg strub...@yahoo.de great stuff, +1! Just to help me understand a bit better. This module will cover a Spring-CDI bridge, so you boot Spring and a CDI container and route the beans between both of them, right? Just for getting the whole picture: Another way is to just interpret the spring beans.xml and serve it all purely with CDI. Of course this will pretty surely not be possible to implement 100% compatible thus I'm not sure if it's worth implementing at all. I guess this is _not_ covered in your proposal, right? Imo this is perfectly fine, I just mention it for clarity. LieGrue, strub - Original Message - From: Marius Bogoevici marius.bogoev...@gmail.com To: deltaspike-dev@incubator.apache.org Cc: Sent: Monday, October 15, 2012 8:33 AM Subject: [DISCUSS] Spring - CDI Integration in DeltaSpike Hello all, Please check [1] before you answer. I'd like to propose the addition of a new module for integrating Spring with CDI. We have discussed this on the e-mail list but let me provide a quick rationale for it. - it eases adoption of CDI and, by extension, Java EE, in environments with a significant existing Spring codebase; - it provides a general solution for Spring/Java EE integration; - it provides users with more options in choosing the best components for their application, knowing that they are not locked in either of the paradigms (e.g. a user can integrate a project
[DISCUSS] Spring - CDI Integration in DeltaSpike
Hello all, Please check [1] before you answer. I'd like to propose the addition of a new module for integrating Spring with CDI. We have discussed this on the e-mail list but let me provide a quick rationale for it. - it eases adoption of CDI and, by extension, Java EE, in environments with a significant existing Spring codebase; - it provides a general solution for Spring/Java EE integration; - it provides users with more options in choosing the best components for their application, knowing that they are not locked in either of the paradigms (e.g. a user can integrate a project with a strong CDI-based programming API with something like Spring Batch or Spring Integration); Features (proposed) - a) bidirectional injection of beans (Spring into CDI and vice-versa); b) bridging EntityTransaction support between DeltaSpike and Spring; c) integrating the CDI event model with Spring (the best approach in my opinion being Spring Integraton rather than the core) d) integration with other Spring portfolio projects wherever possible; For version 0.4 a minimal goal would be a), followed by b) if possible. General approach (covers a)) = For 0.4. my intent, by and large, is to follow the approaches of the Seam 3 Spring module (including a code migration), making improvements on its design wherever possible. I intend to create individual JIRAs for a more detailed discussion, but here's the outline: The general principle is that each side (Spring, CDI) should not know about the existence of the other. Spring beans should be used as CDI beans transparently and vice-versa. So where do beans come from? Spring beans are exposed through a /resource producer pattern//./ @Produces @SpringBean Foo bar; Will produce a CDI bean of the type Foo acquired from the Spring context Details: http://docs.jboss.org/seam/3/spring/latest/reference/en-US/html/spring-usage.html#d0e92 What Spring context? -- For flexibility reasons, we do not assume where the Spring context is coming from. Therefore, we allow different mechanisms for accessing a Spring context. In fact, multiple contexts can be used for import. a) parent web context [3] @Produces @Web @SpringContext ApplicationContext applicationContext; b) Configuration-file based application context [4] @Produces @Configuration(classpath*:META-INF/spring/context.xml) @SpringContext ApplicationContext applicationContext; (TBD: issues like auto-import and auto-vetoing, as well as sensible defaults) The Spring bean producer can reference a specific context (see documentation for details) Note: When we get to the JIRAs we can consider alternative designs - e.g. grouping all producers for a particular context in a single bean and making that bean the Spring context reference marker. Note #2: In regards to the CDISource implementation: I am happy with reusing some of the stuff there, but I have a hard time looking at the code, it's never been released (as in a Maven release), lacks documentation, and reverse engineering is hard. So if someone that is familiar with the code and finds something particularly apt for reuse, and it's also OK from an Apache code policy point of view, we should incorporate anything that helps. What I am not particularly happy with is the approach of annotating CDI injection points with the @Spring marker, which I believe violates separation of concerns - I consider production or auto-registration a better approach (CDI targets should not know about the provenience of the bean). CDI into Spring integration [5] === Conversely, CDI beans can be injected into Spring applications. To that end, we will provide a namespace (and possibly a JavaConfig configuration mechanism) Structure == The integration can be split into multiple modules, one for each features above. a) can be split into two different modules too. Roadmap == I think that the first vote would be for the inclusion of the module (or modules), followed by discussion of the JIRAs. [1] http://markmail.org/message/7yefspfuvtz4jvmp [2] https://cwiki.apache.org/DeltaSpike/spring-cdi-integration.html [3] http://docs.jboss.org/seam/3/spring/latest/reference/en-US/html/spring-usage.html#d0e92 [4] http://docs.jboss.org/seam/3/spring/latest/reference/en-US/html/spring-usage.html#d0e92 [5] http://docs.oracle.com/javaee/6/api/javax/enterprise/inject/spi/BeanManager.html
Re: [DISCUSS] Spring - CDI Integration in DeltaSpike
Sent from my iPhone On 2012-10-15, at 3:35, Mark Struberg strub...@yahoo.de wrote: great stuff, +1! Just to help me understand a bit better. This module will cover a Spring-CDI bridge, so you boot Spring and a CDI container and route the beans between both of them, right? Yes, except that we would also support the case where the context is bootstrapped via a ContextLoaderListener, to allow easier integration with existing Spring MVC applications. Just for getting the whole picture: Another way is to just interpret the spring beans.xml and serve it all purely with CDI. Of course this will pretty surely not be possible to implement 100% compatible thus I'm not sure if it's worth implementing at all. No, it would be disastrous. We wouldn't be able to support namespaces, JavaConfig and such, including auxiliary frameworks of the Spring portfolio. I guess this is _not_ covered in your proposal, right? Imo this is perfectly fine, I just mention it for clarity. LieGrue, strub - Original Message - From: Marius Bogoevici marius.bogoev...@gmail.com To: deltaspike-dev@incubator.apache.org Cc: Sent: Monday, October 15, 2012 8:33 AM Subject: [DISCUSS] Spring - CDI Integration in DeltaSpike Hello all, Please check [1] before you answer. I'd like to propose the addition of a new module for integrating Spring with CDI. We have discussed this on the e-mail list but let me provide a quick rationale for it. - it eases adoption of CDI and, by extension, Java EE, in environments with a significant existing Spring codebase; - it provides a general solution for Spring/Java EE integration; - it provides users with more options in choosing the best components for their application, knowing that they are not locked in either of the paradigms (e.g. a user can integrate a project with a strong CDI-based programming API with something like Spring Batch or Spring Integration); Features (proposed) - a) bidirectional injection of beans (Spring into CDI and vice-versa); b) bridging EntityTransaction support between DeltaSpike and Spring; c) integrating the CDI event model with Spring (the best approach in my opinion being Spring Integraton rather than the core) d) integration with other Spring portfolio projects wherever possible; For version 0.4 a minimal goal would be a), followed by b) if possible. General approach (covers a)) = For 0.4. my intent, by and large, is to follow the approaches of the Seam 3 Spring module (including a code migration), making improvements on its design wherever possible. I intend to create individual JIRAs for a more detailed discussion, but here's the outline: The general principle is that each side (Spring, CDI) should not know about the existence of the other. Spring beans should be used as CDI beans transparently and vice-versa. So where do beans come from? Spring beans are exposed through a /resource producer pattern//./ @Produces @SpringBean Foo bar; Will produce a CDI bean of the type Foo acquired from the Spring context Details: http://docs.jboss.org/seam/3/spring/latest/reference/en-US/html/spring-usage.html#d0e92 What Spring context? -- For flexibility reasons, we do not assume where the Spring context is coming from. Therefore, we allow different mechanisms for accessing a Spring context. In fact, multiple contexts can be used for import. a) parent web context [3] @Produces @Web @SpringContext ApplicationContext applicationContext; b) Configuration-file based application context [4] @Produces @Configuration(classpath*:META-INF/spring/context.xml) @SpringContext ApplicationContext applicationContext; (TBD: issues like auto-import and auto-vetoing, as well as sensible defaults) The Spring bean producer can reference a specific context (see documentation for details) Note: When we get to the JIRAs we can consider alternative designs - e.g. grouping all producers for a particular context in a single bean and making that bean the Spring context reference marker. Note #2: In regards to the CDISource implementation: I am happy with reusing some of the stuff there, but I have a hard time looking at the code, it's never been released (as in a Maven release), lacks documentation, and reverse engineering is hard. So if someone that is familiar with the code and finds something particularly apt for reuse, and it's also OK from an Apache code policy point of view, we should incorporate anything that helps. What I am not particularly happy with is the approach of annotating CDI injection points with the @Spring marker, which I believe violates separation of concerns - I consider production or auto-registration a better approach (CDI targets should not know about the provenience of the bean). CDI into Spring
Re: [DISCUSS] Spring - CDI Integration in DeltaSpike
Sent from my iPhone On 2012-10-15, at 11:16, Jason Porter lightguard...@gmail.com wrote: You have my +1 Marius. If we can rouse the CDISource guys (mostly Rick) they may have some ideas as well. I talked to Rick at Java One and he said that he'll try. On Mon, Oct 15, 2012 at 1:53 AM, Antoine Sabot-Durand anto...@sabot-durand.net wrote: +1 it would definitively improve Java EE and CDI adoption. Antoine SABOT-DURAND Le 15 oct. 2012 à 09:41, Romain Manni-Bucau rmannibu...@gmail.com a écrit : +1 (since DS manages spring context lifecycle) *Romain Manni-Bucau* *Twitter: @rmannibucau https://twitter.com/rmannibucau* *Blog: **http://rmannibucau.wordpress.com/* http://rmannibucau.wordpress.com/ *LinkedIn: **http://fr.linkedin.com/in/rmannibucau* *Github: https://github.com/rmannibucau* 2012/10/15 Mark Struberg strub...@yahoo.de great stuff, +1! Just to help me understand a bit better. This module will cover a Spring-CDI bridge, so you boot Spring and a CDI container and route the beans between both of them, right? Just for getting the whole picture: Another way is to just interpret the spring beans.xml and serve it all purely with CDI. Of course this will pretty surely not be possible to implement 100% compatible thus I'm not sure if it's worth implementing at all. I guess this is _not_ covered in your proposal, right? Imo this is perfectly fine, I just mention it for clarity. LieGrue, strub - Original Message - From: Marius Bogoevici marius.bogoev...@gmail.com To: deltaspike-dev@incubator.apache.org Cc: Sent: Monday, October 15, 2012 8:33 AM Subject: [DISCUSS] Spring - CDI Integration in DeltaSpike Hello all, Please check [1] before you answer. I'd like to propose the addition of a new module for integrating Spring with CDI. We have discussed this on the e-mail list but let me provide a quick rationale for it. - it eases adoption of CDI and, by extension, Java EE, in environments with a significant existing Spring codebase; - it provides a general solution for Spring/Java EE integration; - it provides users with more options in choosing the best components for their application, knowing that they are not locked in either of the paradigms (e.g. a user can integrate a project with a strong CDI-based programming API with something like Spring Batch or Spring Integration); Features (proposed) - a) bidirectional injection of beans (Spring into CDI and vice-versa); b) bridging EntityTransaction support between DeltaSpike and Spring; c) integrating the CDI event model with Spring (the best approach in my opinion being Spring Integraton rather than the core) d) integration with other Spring portfolio projects wherever possible; For version 0.4 a minimal goal would be a), followed by b) if possible. General approach (covers a)) = For 0.4. my intent, by and large, is to follow the approaches of the Seam 3 Spring module (including a code migration), making improvements on its design wherever possible. I intend to create individual JIRAs for a more detailed discussion, but here's the outline: The general principle is that each side (Spring, CDI) should not know about the existence of the other. Spring beans should be used as CDI beans transparently and vice-versa. So where do beans come from? Spring beans are exposed through a /resource producer pattern//./ @Produces @SpringBean Foo bar; Will produce a CDI bean of the type Foo acquired from the Spring context Details: http://docs.jboss.org/seam/3/spring/latest/reference/en-US/html/spring-usage.html#d0e92 What Spring context? -- For flexibility reasons, we do not assume where the Spring context is coming from. Therefore, we allow different mechanisms for accessing a Spring context. In fact, multiple contexts can be used for import. a) parent web context [3] @Produces @Web @SpringContext ApplicationContext applicationContext; b) Configuration-file based application context [4] @Produces @Configuration(classpath*:META-INF/spring/context.xml) @SpringContext ApplicationContext applicationContext; (TBD: issues like auto-import and auto-vetoing, as well as sensible defaults) The Spring bean producer can reference a specific context (see documentation for details) Note: When we get to the JIRAs we can consider alternative designs - e.g. grouping all producers for a particular context in a single bean and making that bean the Spring context reference marker. Note #2: In regards to the CDISource implementation: I am happy with reusing some of the stuff there, but I have a hard time looking at the code, it's never been released (as in a Maven release), lacks documentation, and reverse engineering is hard. So if someone that is familiar with the code and finds something particularly apt for reuse
Re: [DISCUSS] Spring - CDI Integration in DeltaSpike
Thanks Arne, that looks useful! :) (I can read German ;)) Sent from my iPhone On 2012-10-15, at 11:55, Arne Limburg arne.limb...@openknowledge.de wrote: Hi, Some ideas from my side, too ([1] and [2]). Unfortunately it is in german. But everyone of you can read the code. We used an advanced version of that code to build a Spring-CDI-Bridge in a large project. Unfortunately meanwhile the project is completely migrated to CDI and the code is lost in subversion. Will see, if I find the final version and can donate it. Cheers, Arne [1] http://www.openknowledge.de/blog/article/integration-von-spring-in-cdi-uebe r-eine-cdi-extension-erster-teil.html [2] http://www.openknowledge.de/blog/article/integration-von-spring-in-cdi-uebe r-eine-cdi-extension-zweiter-teil.html Am 15.10.12 17:16 schrieb Jason Porter unter lightguard...@gmail.com: You have my +1 Marius. If we can rouse the CDISource guys (mostly Rick) they may have some ideas as well. On Mon, Oct 15, 2012 at 1:53 AM, Antoine Sabot-Durand anto...@sabot-durand.net wrote: +1 it would definitively improve Java EE and CDI adoption. Antoine SABOT-DURAND Le 15 oct. 2012 à 09:41, Romain Manni-Bucau rmannibu...@gmail.com a écrit : +1 (since DS manages spring context lifecycle) *Romain Manni-Bucau* *Twitter: @rmannibucau https://twitter.com/rmannibucau* *Blog: **http://rmannibucau.wordpress.com/* http://rmannibucau.wordpress.com/ *LinkedIn: **http://fr.linkedin.com/in/rmannibucau* *Github: https://github.com/rmannibucau* 2012/10/15 Mark Struberg strub...@yahoo.de great stuff, +1! Just to help me understand a bit better. This module will cover a Spring-CDI bridge, so you boot Spring and a CDI container and route the beans between both of them, right? Just for getting the whole picture: Another way is to just interpret the spring beans.xml and serve it all purely with CDI. Of course this will pretty surely not be possible to implement 100% compatible thus I'm not sure if it's worth implementing at all. I guess this is _not_ covered in your proposal, right? Imo this is perfectly fine, I just mention it for clarity. LieGrue, strub - Original Message - From: Marius Bogoevici marius.bogoev...@gmail.com To: deltaspike-dev@incubator.apache.org Cc: Sent: Monday, October 15, 2012 8:33 AM Subject: [DISCUSS] Spring - CDI Integration in DeltaSpike Hello all, Please check [1] before you answer. I'd like to propose the addition of a new module for integrating Spring with CDI. We have discussed this on the e-mail list but let me provide a quick rationale for it. - it eases adoption of CDI and, by extension, Java EE, in environments with a significant existing Spring codebase; - it provides a general solution for Spring/Java EE integration; - it provides users with more options in choosing the best components for their application, knowing that they are not locked in either of the paradigms (e.g. a user can integrate a project with a strong CDI-based programming API with something like Spring Batch or Spring Integration); Features (proposed) - a) bidirectional injection of beans (Spring into CDI and vice-versa); b) bridging EntityTransaction support between DeltaSpike and Spring; c) integrating the CDI event model with Spring (the best approach in my opinion being Spring Integraton rather than the core) d) integration with other Spring portfolio projects wherever possible; For version 0.4 a minimal goal would be a), followed by b) if possible. General approach (covers a)) = For 0.4. my intent, by and large, is to follow the approaches of the Seam 3 Spring module (including a code migration), making improvements on its design wherever possible. I intend to create individual JIRAs for a more detailed discussion, but here's the outline: The general principle is that each side (Spring, CDI) should not know about the existence of the other. Spring beans should be used as CDI beans transparently and vice-versa. So where do beans come from? Spring beans are exposed through a /resource producer pattern//./ @Produces @SpringBean Foo bar; Will produce a CDI bean of the type Foo acquired from the Spring context Details: http://docs.jboss.org/seam/3/spring/latest/reference/en-US/html/spring-us age.html#d0e92 What Spring context? -- For flexibility reasons, we do not assume where the Spring context is coming from. Therefore, we allow different mechanisms for accessing a Spring context. In fact, multiple contexts can be used for import. a) parent web context [3] @Produces @Web @SpringContext ApplicationContext applicationContext; b) Configuration-file based application context [4] @Produces @Configuration(classpath*:META-INF/spring/context.xml) @SpringContext ApplicationContext
Re: XML Config
Generally speaking, I think it would be good to have a mechanism for configuring beans that does not require re-compilation - may be of limited use in greenfield applications, but above all with brownfield/legacy code. In fairness, for the latter one could use producers and such, but it may still be a PITA in some cases. Now, the key here IMO would be to have a scriptable (no recompilation) and toolable DSL outside the annotation system. It so happens that of all the options, XML is IMO the most common and better understood by the average developer. If we manage to define a proper intermediate model for this mechanism, then there could be plenty of other options (yaml, or even Groovy or Ruby if one so wishes) to add on later. On 2012-09-10 3:50 AM, Romain Manni-Bucau wrote: what does bring xml? i think that's the point if it is only to get a format with hierarchy you can use yaml for instance *Romain Manni-Bucau* *Twitter: @rmannibucau* *Blog: http://rmannibucau.wordpress.com* 2012/9/10 Bernard Łabno s4...@pjwstk.edu.pl If you find elegant way to do everything that can be currently done then it's cool not to use XML, but if we won't be able to i.e. configure bean properties between compilation and deployment then it will be great disappointment. 2012/9/10 Charles Moulliard ch0...@gmail.com I would prefer that we avoid to use XML. Otherwise, end users will be confused about what a CDI / CDI Extension should looks like and why we are moving one step down to do what Spring / Xbean are doing. On Fri, Sep 7, 2012 at 11:31 PM, Romain Manni-Bucau rmannibu...@gmail.comwrote: Why i would like to use files (i find xml too verbose) is for constants (uri for instance) or alternative/interceptor (as mentionned) Today i find other use case the translation of bad design ...just my opinion maybe Le 7 sept. 2012 23:01, Jason Porter lightguard...@gmail.com a écrit : Mark, Pete and I discussed a little bit about the XML config (from Solder) on IRC today. We quickly decided that we needed to move over to the mailing list for more input, and to make things official. As things currently exist in the Solder XML Config, it's probably not portable and would really need some of the changes in CDI 1.1 to work properly. We also discussed throwing out the idea of completely configuring beans via XML and using the XML config for other tasks such as applying interceptors and the like via regex or similar ideas, in other words having it being a subset of what currently exists today. What is in Solder is very similar to configuring beans via XML in Spring, and we feel that paradigm has sailed. I'm starting this thread to get some other ideas about what we should do for XML config and also see what people think. -- Jason Porter http://lightguard-jp.blogspot.com http://twitter.com/lightguardjp Software Engineer Open Source Advocate Author of Seam Catch - Next Generation Java Exception Handling PGP key id: 926CCFF5 PGP key available at: keyserver.net, pgp.mit.edu -- Charles Moulliard Apache Committer / Sr. Pr. Consultant at FuseSource.com Twitter : @cmoulliard Blog : http://cmoulliard.blogspot.com
Re: [DISCUSS] roadmap for deltaspike-0.4-incubating
All, Sorry for the late reply, but I was on vacation so I just got to catch up with some of my emails. Indeed, I would very much like us to include Spring/CDI integration in v0.4. and, of course, start working on it some time in September (along with anyone who is interested to contribute to it - I think that Arne would be interested in that as well). To that end, I plan to start a separate discussion on the features this week and hopefully we can gather all the ideas we have (based on Seam3, CDISource, whatnot and new and better ideas) and turn that into a good solution. Cheers, Marius On 2012-08-29 12:24 PM, Jason Porter wrote: Hey all, I'm back now :) Yes, I believe it's all imported now. Other things we've talked about in the past for v0.4 is Spring, I know Marius is anxious to get working on that one. The Seam XML config I would like to do, but it seems like there's some discussion going on in the CDI spec that relates to XML config. If we think we can go forward with it as it currently stands we're good. On Mon, Aug 27, 2012 at 7:01 AM, Pete Muir pm...@redhat.com wrote: IIRC Jason imported it all. On 25 Aug 2012, at 12:08, Mark Struberg wrote: btw, Pete, Jason, Shane what is with the rest of the BeanBuilder stuff? Did we import that already? Like to work on it? LieGrue, strub - Original Message - From: Thomas Hug thomas@ctp-consulting.com To: deltaspike-dev@incubator.apache.org deltaspike-dev@incubator.apache.org Cc: Sent: Saturday, August 25, 2012 12:07 PM Subject: RE: [DISCUSS] roadmap for deltaspike-0.4-incubating Yep, already on the list - so far mainly in reading mode :-) Given that this would not interfere with any planned JPA module cleanups I'd look forward starting with porting CDI Query over to DS. Capacity is limited for the next month but I can allocate more after JavaOne. Some stuff that could be done before: - Porting the Solder ServiceHandler - Porting the Solder Property Utils Also there are some features which are not yet ready for prime time, I guess we could start with a limited feature set going through a review / polish. Cheers, Tom -Original Message- From: Pete Muir [mailto:pm...@redhat.com] Sent: Freitag, 24. August 2012 15:22 To: deltaspike-dev@incubator.apache.org Subject: Re: [DISCUSS] roadmap for deltaspike-0.4-incubating On 24 Aug 2012, at 12:52, Mehdi Heidarzadeh wrote: Seam Application Framework Or something similar / simple to use and understand. http://docs.jboss.org/seam/2.2.2.Final/reference/en-US/html/framework. htmlBestregards, I think we have something similar to this already developed by Thomas Hughttps://plus.google.com/100910414952656230590which is named cdi-query. Thomas has already announcedhttp://apache-deltaspike-incubator-discussions.2316169.n4.na bble.com/Porting-the-CDI-Query-extension-project-to-DeltaSpike-td43299 22.htmlthat wants to port it to DS. We can ask him to attend in this thread too. Take a look at this : http://ctpconsulting.github.com/query/1.0.0.Alpha4/index.html And his blog post here : http://ctpjava.blogspot.com/ I think Jason has used cdi-query and can talk about it better. Jason WDYT? Jason in on vacation atm, and is only periodically checking email. I can pretend to be a poor clone of him ;-) Yes, we really like cdi-query, and think it's a great successor to the Seam Application Framework. I think Thomas is on this list? If so, we would definitely support him moving it to Deltaspike, modulo the usual review and improvement work :-) HTH
Re: XML Config
Spring supports it, but in practice you'd want to stay away from it. I thought more along the lines of a script that is interpreted at startup. On 2012-09-10 10:15 AM, Mark Struberg wrote: hmm 'scriptable' imo implies that it can be changed at runtime. But that's by design not possible with CDI. Spring supports this, we do not. Otoh this allows us to be much faster in all 'static' use cases. LieGrue, strub - Original Message - From: Marius Bogoevici marius.bogoev...@gmail.com To: deltaspike-dev@incubator.apache.org Cc: Romain Manni-Bucau rmannibu...@gmail.com Sent: Monday, September 10, 2012 3:20 PM Subject: Re: XML Config G enerally speaking, I think it would be good to have a mechanism for configuring beans that does not require re-compilation - may be of limited use in greenfield applications, but above all with brownfield/legacy code. In fairness, for the latter one could use producers and such, but it may still be a PITA in some cases. Now, the key here IMO would be to have a scriptable (no recompilation) and toolable DSL outside the annotation system. It so happens that of all the options, XML is IMO the most common and better understood by the average developer. If we manage to define a proper intermediate model for this mechanism, then there could be plenty of other options (yaml, or even Groovy or Ruby if one so wishes) to add on later. On 2012-09-10 3:50 AM, Romain Manni-Bucau wrote: what does bring xml? i think that's the point if it is only to get a format with hierarchy you can use yaml for instance *Romain Manni-Bucau* *Twitter: @rmannibucau* *Blog: http://rmannibucau.wordpress.com* 2012/9/10 Bernard Łabno s4...@pjwstk.edu.pl If you find elegant way to do everything that can be currently done then it's cool not to use XML, but if we won't be able to i.e. configure bean properties between compilation and deployment then it will be great disappointment. 2012/9/10 Charles Moulliard ch0...@gmail.com I would prefer that we avoid to use XML. Otherwise, end users will be confused about what a CDI / CDI Extension should looks like and why we are moving one step down to do what Spring / Xbean are doing. On Fri, Sep 7, 2012 at 11:31 PM, Romain Manni-Bucau rmannibu...@gmail.comwrote: Why i would like to use files (i find xml too verbose) is for constants (uri for instance) or alternative/interceptor (as mentionned) Today i find other use case the translation of bad design ...just my opinion maybe Le 7 sept. 2012 23:01, Jason Porter lightguard...@gmail.com a écrit : Mark, Pete and I discussed a little bit about the XML config (from Solder) on IRC today. We quickly decided that we needed to move over to the mailing list for more input, and to make things official. As things currently exist in the Solder XML Config, it's probably not portable and would really need some of the changes in CDI 1.1 to work properly. We also discussed throwing out the idea of completely configuring beans via XML and using the XML config for other tasks such as applying interceptors and the like via regex or similar ideas, in other words having it being a subset of what currently exists today. What is in Solder is very similar to configuring beans via XML in Spring, and we feel that paradigm has sailed. I'm starting this thread to get some other ideas about what we should do for XML config and also see what people think. -- Jason Porter http://lightguard-jp.blogspot.com http://twitter.com/lightguardjp Software Engineer Open Source Advocate Author of Seam Catch - Next Generation Java Exception Handling PGP key id: 926CCFF5 PGP key available at: keyserver.net, pgp.mit.edu -- Charles Moulliard Apache Committer / Sr. Pr. Consultant at FuseSource.com Twitter : @cmoulliard Blog : http://cmoulliard.blogspot.com
Re: XML Config
On 2012-09-10 8:25 AM, Pete Muir wrote: This is what I would use non-compiled resources for as well. If I needed to CDI-enable some code without using annotations, I would use the portable extension API directly. Yes and no. In my opinion this is generic enough to warrant a configurable implementation, rather than producing a code template that would be copied and pasted around. I understand that all of us can master the fine points of writing an extension, but a configurable solution may be easier for the average developer. On 7 Sep 2012, at 22:31, Romain Manni-Bucau wrote: Why i would like to use files (i find xml too verbose) is for constants (uri for instance) or alternative/interceptor (as mentionned) Today i find other use case the translation of bad design ...just my opinion maybe Le 7 sept. 2012 23:01, Jason Porter lightguard...@gmail.com a écrit : Mark, Pete and I discussed a little bit about the XML config (from Solder) on IRC today. We quickly decided that we needed to move over to the mailing list for more input, and to make things official. As things currently exist in the Solder XML Config, it's probably not portable and would really need some of the changes in CDI 1.1 to work properly. We also discussed throwing out the idea of completely configuring beans via XML and using the XML config for other tasks such as applying interceptors and the like via regex or similar ideas, in other words having it being a subset of what currently exists today. What is in Solder is very similar to configuring beans via XML in Spring, and we feel that paradigm has sailed. I'm starting this thread to get some other ideas about what we should do for XML config and also see what people think. -- Jason Porter http://lightguard-jp.blogspot.com http://twitter.com/lightguardjp Software Engineer Open Source Advocate Author of Seam Catch - Next Generation Java Exception Handling PGP key id: 926CCFF5 PGP key available at: keyserver.net, pgp.mit.edu
Re: IDM impl feedback
4b looks a good way to go for me as well. On 2012-07-27 9:44 AM, Cody Lerum wrote: +1 4b On Jul 26, 2012 4:41 PM, Mark Struberg strub...@yahoo.de wrote: Oki, here we go. We had a quick chat about where we basically stand today. This is not intended to be a a 'what shall be' but more a 'what do we have' + 'what do we really need' email. 1.) What we have today: I've looked at the Security module and what I understand it's pretty powerful and complex. There are aprox. 30++ Interfaces which are very flexible but also very hard to get right. Having lots of flexibility also makes it easy to do things wrong as user. E.g. IdentityManager which allows to create users. The RoleQuery and the whole Role management is pretty complete from the API level but I've never seen it used in such detail in any application yet. Most times there is an additional mapping role - rights. And the right is what gets used in the application (e.g. in rendered= ). 2.) What is available in projects: In my last 10 projects we never had the choice to define our own login logic. Some customers had radius, others authenticated against SAP or kerberos. Then there are some LDAP and we even have a single sign on based on Smalltalk. And there is absolutely no way to get rid of those! Most of the time you cannot even create your own users... Of course there is the need for a simple html based user login for _some_ applications. But this is most times only needed for green-field projects. Whenever you do projects for a bigger company you most likely will find some well established SSO in place. 3.) what is needed in those projects: I did quite some integration already in the past and the only thing which we did really need was 3.a.) to express some interrest: current user likes to do actionX This can be done via a @Secured interceptor, via @ViewConfig, via @PageBean etc - might get provided by DS. 3.b.) to evaluate the is the current user allowed to do actionX Like with JAAS Voters this can be done via a simple Interface which returns a boolean. This is really similar to what Seam2 had and also what CODI did. All the evaluation and binding to an existing authorisation and authentication can be done in this AccessVoter/checkPermission. - we might provide the Interfaces in DS. The impl is _always_ up to the user. 4.) what are our options: 4.a.) fully implement our own security manager. This will surely still take some time as this is a complex topic! Many of the interfaces are ok but there is not yet an impl behind it. My personal estimation is that we now hit the 15% line, and a few people already spent a good amount of power for it. So this will not be finished for the next 5 months I fear. 4.b) implement a simple Voter + @Secured and let the user deal with the rest. In both Seam2 and CODI this turned out to not only be extremely flexible, but it is also rather easy to integrate [1]. We could also provide an additional module which contains a composite component with login userId + pwd fields + a simple backend for it. But just as a small additional module which might optionally be used for easier integration into JSF apps if there is not yet an existing SSO implementation. LieGrue, strub [1] https://github.com/struberg/lightweightEE/blob/master/gui/src/main/java/de/jaxenter/eesummit/caroline/gui/security/AdminAccessVoter.java#L36 - Original Message - From: Jason Porter lightguard...@gmail.com To: deltaspike-dev@incubator.apache.org Cc: Sent: Thursday, July 26, 2012 9:03 PM Subject: IDM impl feedback T he implementation that's in HEAD right now is incomplete. There are many methods which are basic IDE generated stubs in multiple classes. I'll hold off on any feedback until it's complete. -- Jason Porter http://lightguard-jp.blogspot.com http://twitter.com/lightguardjp Software Engineer Open Source Advocate Author of Seam Catch - Next Generation Java Exception Handling PGP key id: 926CCFF5 PGP key available at: keyserver.net, pgp.mit.edu
[DISCUSS] deltaspike-spring in v0.4 ?
All, I know that it is a final the final stretch for 0.3 so all the energy is flowing in that direction, however, as a 0.4 release is brewing, I think it is a good moment to discuss whether a Spring bridge should be included in the 0.4 release. I believe that such a module should be included now, based on the fact that Java EE 6 is gaining momentum, and a number of developers I recently encountered have asked about ways to reuse their existing Spring codebase with the newly available features in Java EE 6. It is possible to direct people to Seam Spring and such, however it is clear from the start that those libraries will need to be replaced soon. So, I'd like to start a more in-depth discussion about features and design. An early glimpse is on the wiki page https://cwiki.apache.org/DeltaSpike/spring-cdi-integration.html, but that is mostly providing a frame of refernence. I plan to start the discussion over the weekend, or as early as possible next week, but IMO for it to make sense the first step is clarifying that such a module could potentially be included on the 0.4 roadmap (knowing that the roadmap for 0.4 is yet to be defined). As I said, from my point of view this is a critically important item, and can be addressed now, given how the general-purpose facilities of DeltaSpike are in place. WDYT? Cheers, Marius
Re: v0.4-incubating adding Seam Config (xml config)
+1 On 12-07-06 3:50 PM, Jason Porter wrote: It's been a 10 on our list for awhile but we haven't done it yet. Thoughts on adding it to v0.4? It would be a straight port from what we have in Seam 3 with package name changes. It's currently the only implementation in existence (that we know of) of the older xml config that was to be part of spec but was later pulled.
Re: [seam-dev] Sandbox for DeltaSpike
+1 We have taught ourselves to write self-explanatory code, and that is starting to show ;) Sent from my iPhone On 2012-06-29, at 3:22 PM, Lincoln Baxter, III lincolnbax...@gmail.com wrote: I see nothing wrong with a sandbox, particularly since I think sometimes seeing code is a better way to make spark discussion than trying to discuss everything up front. In order to facilitate contribution and individual communication styles, and to promote more contributions in general, I think this is a good step. On Fri, Jun 29, 2012 at 2:02 PM, Marius Bogoevici marius.bogoev...@gmail.com wrote: I think it is a good idea. Discussions can and should take place, but IMO an opend sandbox would be a good place to stage code for new features without endangering the stability of the whole project. On 12-06-26 3:39 PM, Jason Porter wrote: Hey everyone! I wanted to bring up the idea of having a sandbox to add bits and other non-core extensions. We have a great bunch of people from the Seam development group looking to add their extensions, but they're either not on the roadmap for DS, or are very far down. I suggest we setup a sandbox on github people can write to, or at least do pull requests to so we can get some of these modules and other ideas in and pull them into core as we get there. We can also use this as a vetting ground for new ideas and other things which may not exactly fit into core, like the forge extension. To do this we need to 1. Setup the repo somewhere 2. Seed it with a basic structure (pom.xml, contribution instructions, etc) 3. Get some CI setup somewhere (we could leverage OpenShift for this if needed) What does everyone else think? I've cc'd the Seam Development list here hoping to get some feedback from them as well and hopefully rekindle some of the fire we had there. ___ seam-dev mailing list seam-...@lists.jboss.org https://lists.jboss.org/mailman/listinfo/seam-dev -- Lincoln Baxter, III http://ocpsoft.org Simpler is better. ___ seam-dev mailing list seam-...@lists.jboss.org https://lists.jboss.org/mailman/listinfo/seam-dev
Re: Sandbox for DeltaSpike
I think it is a good idea. Discussions can and should take place, but IMO an opend sandbox would be a good place to stage code for new features without endangering the stability of the whole project. On 12-06-26 3:39 PM, Jason Porter wrote: Hey everyone! I wanted to bring up the idea of having a sandbox to add bits and other non-core extensions. We have a great bunch of people from the Seam development group looking to add their extensions, but they're either not on the roadmap for DS, or are very far down. I suggest we setup a sandbox on github people can write to, or at least do pull requests to so we can get some of these modules and other ideas in and pull them into core as we get there. We can also use this as a vetting ground for new ideas and other things which may not exactly fit into core, like the forge extension. To do this we need to 1. Setup the repo somewhere 2. Seed it with a basic structure (pom.xml, contribution instructions, etc) 3. Get some CI setup somewhere (we could leverage OpenShift for this if needed) What does everyone else think? I've cc'd the Seam Development list here hoping to get some feedback from them as well and hopefully rekindle some of the fire we had there.
Re: [DISCUSS] Roadmap for 0.3-incubating ?
It may be late, so sorry for noticing this right now, but: - would you think that there is room to include Spring integration? Or, in the least, open the discussion about it? On 2012-04-22, at 11:08 AM, Mark Struberg wrote: Hi folks! What features do we like to get into deltaspike-0.3-incubating? * security * i18n I'd say we can also start with JPA support already, wdyt? LieGrue, strub
Re: Spring/CDI integration
Alan, Re: Seam-Spring On 12-03-18 3:04 PM, Alan D. Cabrera wrote: I'm struggling to get this working for my WAR. I was hoping for an out of the box example but can't seem to find one. You can find a simple example here https://github.com/mbogoevici/Seam-Spring-Basic-Example Would you mind following up on https://community.jboss.org/en/seam?view=discussions or in the project JIRA: https://issues.jboss.org/browse/SEAMSPRING with the issues that you are encountering? Additional docs are at http://docs.jboss.org/seam/3/spring/latest/reference/en-US/html/ As Mark and Gerhard has mentioned already, the intent is to move/merge this into a DeltaSpike module, but until that happens, hopefully this will get you started. Regards, Alan Good luck, Marius
Re: [DISCUSS] modules and basic tasks for deltaspike v0.2
On 2012-01-27, at 3:55 AM, Gerhard Petracek wrote: hi @ all, (i planned to send this mail after starting the release procedure for v0.1. however, the review phase for v0.1 is going to end soon and we have seen several other discussions already.) imo with v0.2 we should start working on multiple modules in parallel. e.g.: - security (that's also one of the few parts of myfaces codi-core we haven't discussed so far) - jpa - (core - further features, refactorings, ...) imo: since we agreed on release early and often, it should be enough for the next ~6 weeks. furthermore, we can check the legal aspects concerning the upcoming donations before starting technical discussions about those modules/features (e.g. the spring-cdi integration module). From a legal standpoint, the Seam 3 Spring module is pretty much ok. regards, gerhard
Re: IP discussion
On 2012-01-15, at 1:02 PM, Antoine Sabot-Durand wrote: Hi Matt, On Sun, Jan 15, 2012 at 10:28 AM, Antoine Sabot-Durand anto...@sabot-durand.net wrote: what about individuals like me ? Or about IP of code coming from other project ? In Seam social, I get lots of services API binding from Spring Social (an ASL2 license project). I there any issue about that ? All code must be expressly licensed by its rightful owner to be included in the ASF repo. For code you write yourself, you simply license it under your filed ICLA. Anything else needs a software grant OR a CLA of some sort and the intent that the contribution be covered under that CLA. The second sentence above is why a simple handshake agreement from Red Hat is enough for me--their corporate CLA is already on file. I lost sight of that fact momentarily when I sent my last message on this thread. But back to the idea of code that comes, e.g., from SpringSource, yes, we must obtain express license to the code itself, particularly when it would take the form of an entire class. Depending on a compatibly-licensed third-party binary is of course no problem whatever. Sorry, but I'm really puzzled about this IP issue. My understanding is that ASL2 is useless. Springsource put their code under ASL2, I used some of their code in respect of the license (keeping names of original authors) but I still need to ask an authorization. So the original license has no value. Unless Apache needs that Springsource ASL2 licensing has to be violated by removing names of original authors, in this case I understand the need of authorization but I'm still puzzled that Apache don't recognize ASL2 value or needs to bypass it to use code under its own license. Could you get me out this kafka-ish point of view :-) ? Yeah, I could benefit from some clarification here as well. Reading Matt's response I understand that this is not an ASL2 issue, but rather an ASF policy issue (ASL2 would require listing Spring social original authors, but that cannot be done without their express permission). Or? Thanks all for the constructive discussion, Matt regards, Antoine SABOT-DURAND Le 15 janv. 2012 à 16:59, Mark Struberg a écrit : Hi! Thanks Matt for bringing this up! This is definitely something we must do before thinking about a -incubating-0.1 release. Btw, I'll now rename the version to reflect the incubation status . Mark Little from JBoss was the manager at RedHat/JBoss who was involved in preparing the incubator proposal. But Shane and Jason for sure know whom to ping. LieGrue, strub - Original Message - From: Shane Bryzak sbry...@gmail.com To: deltaspike-dev@incubator.apache.org Cc: gudnabr...@gmail.com Sent: Sunday, January 15, 2012 2:28 PM Subject: Re: IP discussion We'd need to follow this up with Red Hat legal, to confirm what we need to do. On Sun, Jan 15, 2012 at 6:24 AM, Jason Porter lightguard...@gmail.comwrote: Would someone like myself or Shane work or do we need someone higher up in the organization or a lawyer to sign off on it?
Re: [DISCUSS] [DELTASPIKE-8] @Veto
On 2011-12-28, at 10:05 AM, Mark Struberg wrote:
Actually this is the most common case _why_ one likes to veto a bean. Because
if you create a producer method for a MyBean, then you'll get an
AmbiguousResolutionException otherwise.
Well, I would say that domain entities may be an even more common use case, but
I see where you're coming from.
The spec conform easy way would be to simply use
@Typed()
public class MyBean {}
While this usage is allowed by the spec, I'm not particularly fond of it. The
net result is to create a managed bean which is neither usable, nor (at least
in my case) easy on the eyes. It's more like a hack or a gotcha.
to disable the bean. Imo we should just spread the word about @Typed()
instead of introducing a new annotation. I did just like @Veto for making it
easier for Seam3 users to move over to DeltaSpike. If we change the name,
then I see no reason to implement such a thing ourself at all!
If anything, I think that @Typed should be more restrictive and require at
least one type (cannot find a justification for creating a bean with no actual
types, even if optimization would skip over it). However, that is a discussion
for a different place :).
@Veto or any of its aliases, serves a different purpose: it precludes the class
from being treated as a managed bean altogether. Plus, @Typed is absolutely
awkward to use on a package.
I like @Veto over @Exclude, but I got converted to the the avoiding the
technicalities doctrine, so I suggested @Unmanaged (or even @NotManaged, or
anything that refers to class as a managed bean in the spirit of 3.1.1).
Overall, I think that @Unmanaged is a better fit, for the reasons I explained
previously. I think that renaming is not such a big issue, in the light of a
DeltaSpike migration.
LieGrue,
strub
- Original Message -
From: Marius Bogoevici marius.bogoev...@gmail.com
To: deltaspike-dev@incubator.apache.org
Cc:
Sent: Wednesday, December 28, 2011 3:56 PM
Subject: Re: [DISCUSS] [DELTASPIKE-8] @Veto
John,
The specification has the notion of a class being a managed bean, as laid
out in
chapter 3 of the spec.
Using @Unmanaged would complement the content of section 3.1.1: Which Java
classes are managed beans?, by adding another case when a class is not a
managed bean. Sure, producers can be used for creating beans of this type,
but
that is a different mechanism altogether.
On 2011-12-27, at 7:34 PM, John D. Ament wrote:
Unmanaged sounds a little confusing. this simply represents the default
implementation of the bean, correct? so an app developer can create a
manual producer... right?
On Tue, Dec 27, 2011 at 7:24 PM, Gerhard Petracek
gerhard.petra...@gmail.com wrote:
+1 for @Unmanaged
(+1 for @Exclude if it's the only alternative we can agree on)
regards,
gerhard
2011/12/28 Marius Bogoevici marius.bogoev...@gmail.com
As if we didn't have enough alternatives, here's another
one that popped
up while discussing with Gerhard the relative merits of @Veto and
@Exclude:
@Unmanaged
I think that this solves a few problems that we currently have:
a) @Veto is technically accurate, but not intuitive (and requires
an
understanding of class processing, which is not a user concern)
b) @Exclude is intuitive when considered in the context of scanning
but
it's a bit unclear on a larger scale - 'what exactly is
this class
excluded
from?' - the
c) the annotation must be applicable to packages
IMO, @Unmanaged describes best what happens to the class: it will
*not*
generate a managed bean automatically. It is very similar to
@NoBean
early
suggested by Gerhard, but works on packages too, and it describes a
quality
of the annotated item, in the same way as @Transient stands for
not
serialized.
On 2011-12-27, at 5:43 PM, Marius Bogoevici wrote:
+1 @Veto
-1 @Exclude
@Veto has a very narrow meaning, and hints to
ProcessAnnotatedType.veto(), which is precisely what happens to
such
annotated types. I have mixed feelings about @Exclude - I'd
rather not
introduce a new term, especially one that does not immediately make
you
think of CDI processing.
On 2011-12-26, at 6:41 PM, Gerhard Petracek wrote:
it looks like @Exclude is the alternative which would work
for several
of
us.
- we have to choose between @Exclude and @Vote
+1 for @Exclude
regards,
gerhard
2011/12/26 Jakob Korherr jakob.korh...@gmail.com
+1 to @Veto and @Exclude
Also I agree with Pete's comments about the other
suggestions.
Regards,
Jakob
2011/12/24 Pete Muir pm...@redhat.com:
We chose @Veto originally, as it didn't deviate
from the spec's
veto()
method, so should be less of a learning curve. I
don't like
@Deactivate as
it makes it sound like you have to activate other
beans. @Ignore is
too
overloaded a term for me to be comfortable with it
(@IgnoreWarnings). I
like
Re: account request for initial committers
marius On 2011-12-22, at 3:43 PM, Ken Finnigan wrote: kenfinnigan Thanks Ken Sent from my iPhone On Dec 22, 2011, at 14:16, Gerhard Petracek gerhard.petra...@gmail.com wrote: hi @ all initial committers, if you are listed at the initial committer section of [1] (and you aren't an apache committer already), please reply with your preferred apache-id (without special characters). regards, gerhard [1] http://wiki.apache.org/incubator/DeltaSpikeProposal
Re: intermediate vcs
marius On 2011-12-15, at 4:52 AM, Gerhard Petracek wrote: hi @ all, since we have started several discussions, it makes sense to prototype some parts immediately. mark and i suggest to start at [1] while the infra team is preparing our repository, ldap group,... if you would like to join, send your user-name and you will be added. regards, gerhard [1] http://goo.gl/HmNBV
