It's *definitely* something we want, but it's quite a lot of work to
implement everything that was defined in the older versions of 299
(and some of that should change slightly, given the slightly different
injection syntax that we now use).
If you want to take on this job, that's great, go for it!
But I want us to focus initially on lower-hanging fruit. Stuff that
adds a lot of value w/o having to write a lot of code :-)
On Sat, Nov 21, 2009 at 1:18 AM, Stuart Douglas
<stuart(a)baileyroberts.com.au> wrote:
What about the XML configuration extension? I would be willing to
have a got at this if no one else is going to do it.
Stuart
________________________________________
From: seam-dev-bounces(a)lists.jboss.org [seam-dev-bounces(a)lists.jboss.org] On Behalf Of
denis.forveille(a)gmail.com [denis.forveille(a)gmail.com]
Sent: Saturday, 21 November 2009 6:15 AM
To: seam-dev(a)lists.jboss.org
Subject: Re: [seam-dev] Next steps
- What about a portal/portlet/portlet-bridge integration module?
On 11/20/2009 01:35 PM, 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?
>
>
>
_______________________________________________
seam-dev mailing list
seam-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/seam-dev
_______________________________________________
seam-dev mailing list
seam-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/seam-dev
--
Gavin King
gavin.king(a)gmail.com
http://in.relation.to/Bloggers/Gavin
http://hibernate.org
http://seamframework.org