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

[Pete Muir]

As Dan mentioned, we spent a couple of hours on this at our face-to-face meeting in Antwerp. I've commented inline with my thoughts. I have another email with the actual meeting notes.

I also think we need to get this info onto a wiki page asap, and also prioritize stuff a bit, so that volunteers know which things would be best to pick up...

On 20 Nov 2009, at 19:35, 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

These are primarily the things which support "other environments" like Servlet or Java SE, as there is no bootstrap SPI. Though things that want to reuse the conversation impl *outside JSF* from Weld also fall into this category :-/

> * Portable extensions (PEs) with the Weld brand
> * Portable extensions (PEs) with the Seam brand

I like this :-)

> 
> 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

UE.

> (2) weld-servlet and weld-tomcat

UE. NB We need to do a bit of simplification here. When we started, we had to package weld as an application library, but we also need to access Tomcat APIs (which are hidden from the war classloader) to perform servlet injection. Now that we can support Weld as a shared library, we can probably merge these code bases. I'll also try to chat to Remy or another Tomcat dev to figure out if there is a better way to achieve this...

> (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.)

Agreed :-)

> 
> (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.

Great! We also discussed this at the meeting, so see that email.

Norman is going to take the lead on this.

> 
> (3) A spring-int module.

Marius volunteered to take the lead on this months ago :-)

> 
> (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

This should be possible from what I know of JBoss Transactions

>   * support for the same things with a Hibernate Transaction
> 
> I have already done a rough impl of the first part.

All sounds good.

We didn't discuss this one in depth, and we do need a lead for it.

> 
> (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.

Likewise, we need a lead for this :-)

> 
> (6) a seam-web module with:
> 
>   * injection of FacesContext
>   * injection of servlet contexts
> 
> These are both easy.

Looks like this has already started :-)

> 
> (7) a seam-jms module with:
> 
>   * injection of all the various JMS objects for a resource of type
> Topic or Queue

Shane was happy to take a lead on this, but if we can find a volunteer that would definitely be good!

> 
> Is there anything I'm missing?