[seam-dev] [weld-dev] Next steps

[Gavin King]

That actually looks very cool. I did not know about it. Very much in  
the spirit of CDI. I don't see any reason not to include this in the  
first raft of releases.

Sent from my iPhone

On Nov 20, 2009, at 5:27 PM, Peter Royle  
<howardmoon at screamingcoder.com> wrote:

> There's also the Scheduling extension which currently lives in the  
> seam modules sandbox. I guess it's a Seam PE as it drags in other  
> dependencies (ie Quartz), but it does work with plain Weld (well, at  
> least in SE). For details and an example that's not in the JBoss  
> repos: http://screamingcoder.com/life/2009/07/23/scheduling-in-web-beans-and-jsr-299-apps/
>
> Pete R
>
> On 21/11/2009, at 4:35 AM, Gavin King wrote:
>
>> So, folks, I want us to get a plan together for the first raft of CDI
>> extensions. I think there's three kinds of "things" we will be  
>> working
>> on:
>>
>> * Unportable extensions (UEs), that integrate with proprietary SPIs  
>> in Weld
>> * Portable extensions (PEs) with the Weld brand
>> * Portable extensions (PEs) with the Seam brand
>>
>> I imagine that we will distribute UEs along with Weld and cover them
>> in the Weld documentation. Hopefully there will not be too many of
>> these.
>>
>> Weld PEs are going to be things that:
>>
>>  * are general purpose,
>>  * are simple, and
>>  * don't pull in extra dependencies.
>>
>> Things which don't fit this description get the Seam brand.
>>
>> We already have:
>>
>> (1) weld-se
>> (2) weld-servlet and weld-tomcat
>> (3) weld-wicket
>>
>> These are all UEs, I suppose. Or are some of them PEs?
>>
>> So here's the things that I would like to see us release soon:
>>
>> (1) A weld-ext module with:
>>
>>  * logger injection,
>>  * @Exact,
>>  * @Introduces,
>>  * abstract producer methods,
>>  * beans declared at constructor level, and
>>  * @Named packages.
>>
>> These are all very easy to implement except @Introduces, which
>> requires a little javassist magic.
>>
>> (I would just package weld-logger in here, I don't see why it needs  
>> to
>> be in its own module.)
>>
>> (2) A seam2-int module with:
>>
>>  * use of @Inject to inject of Seam2 beans into CDI beans (i.e. Weld
>> delegates bean instantiation to Seam when there is a @Name)
>>  * (hopefully) support for @Inject in Seam2 beans, if this is not
>> too hard to implement
>>
>> I have already done a rough impl of the first part.
>>
>> (3) A spring-int module.
>>
>> (4) a seam-transactions module with:
>>
>>  * support for declarative JPA EntityTransaction management
>>  * support for injection of the EntityTransaction
>>  * (hopefully) support for the same things with a UserTransaction
>> provided by JBoss Transactions
>>  * support for the same things with a Hibernate Transaction
>>
>> I have already done a rough impl of the first part.
>>
>> (5) a seam-persistence module with:
>>
>>  * support for injection of JPA EntityManagers with various scopes
>>  * (hopefully) support for injection of Hibernate Sessions with  
>> various scopes
>>
>> I have already done a rough impl of the first part.
>>
>> (6) a seam-web module with:
>>
>>  * injection of FacesContext
>>  * injection of servlet contexts
>>
>> These are both easy.
>>
>> (7) a seam-jms module with:
>>
>>  * injection of all the various JMS objects for a resource of type
>> Topic or Queue
>>
>> Is there anything I'm missing?
>>
>>
>> -- 
>> Gavin King
>> gavin.king at gmail.com
>> http://in.relation.to/Bloggers/Gavin
>> http://hibernate.org
>> http://seamframework.org
>> _______________________________________________
>> weld-dev mailing list
>> weld-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/weld-dev
>