[seam-dev] Next steps

Stuart Douglas stuart at baileyroberts.com.au
Sat Nov 21 19:36:20 EST 2009


I think there are two parts to it: a library that provides concrete implementations of all the interfaces in the SPI to make it easy for portable extensions to register new bean types,qualifiers etc, and the XML parser that pulls the data out of the xml. The concrete library will probably be useful for any extension that is registering new bean types, and should make it easier to support different xml formats. 

I have been playing around with the first bit this weekend, and I have created a helper class that can generate AnnotationLiteral<T> at runtime (using javassist), which will be necessary for qualifiers that are specified via xml. I will try and get on IRC a bit in the next few days, to talk about this more.

Stuart
________________________________________
From: Gavin King [gavin.king at gmail.com]
Sent: Sunday, 22 November 2009 7:22 AM
To: Stuart Douglas
Cc: seam-dev at lists.jboss.org
Subject: Re: [seam-dev] Next steps

Actually, it might not be so difficult. I already have to write some
helper classes to make it easier to wrap an AnnotatedType and
add/override annotations. Once we have that, it would not be too hard
to write up a bit of very generic code that parses an XML source of
annotations. and adds them to my AnnotatedTypeHelper. All we really
need to be able to support is the following:


   <myns:MyClass>
      <ClassLevelAnnotation/>
      <AnotherClassLevelAnnotation>
         <annotationMember>value</annotationMember>
      </AnotherClassLevelAnnotation>

      <ConstructorParameterType>
         </ParameterLevelAnnotation/>
      </ConstructorParameterType>

      <FieldLevelAnnotation>
         <myns:myField>
            <FieldType>
               <AnotherFieldLevelAnnotation/>
            </FieldType>
         </myns:myField>
      </FieldLevelAnnotation>

      <MethodLevelAnnotation>
         <myns:myMethod>
            <ParameterType/>
         </myns:myMethod>
      </MethodLevelAnnotation>

      <myns:myOtherMethod>
         <ParameterLevelAnnotation>
            <ParameterType/>
         </ParameterLevelAnnotation>
         <AnotherParameterType>
            <AnotherParameterLevelAnnotation/>
         </AnotherParameterType>
      </myns:myOtherMethod>

   </myns:MyClass>

The stuff in the 299 draft had a few more exotic things, but this
alone is a great start. This generic syntax is enough to be able to
write:


   <myns:CheckPaymentProcessor>
      <SessionScoped/>
      <myns:PayBy>
         <value>CHECK</value>
      </myns:PayBy>

      <Inject>
         <myns:service>
            <RemotePaymentProcessor>
              <myns:PayBy>
                 <value>CHECK</value>
              </myns:PayBy>
            </RemotePaymentProcessor>
         </myns:service>
      </Inject>

      <myns:onPaymentProcessed>
         <Observes>
            <Payment>
               <DoneProcessing/>
            </Payment>
         </Observes>
      </myns:onPaymentProcessed>

      <PostConstruct>
         <myns:init/>
      </PostConstruct>

   </myns:MyClass>


Producer method and fields are a bit trickier, since you need a
combination of method-level annotations, but I'm sure I'll figure
something out. At worst, we can simply special-case the <Produces/>
element.

On Sat, Nov 21, 2009 at 1:40 PM, Gavin King <gavin.king at gmail.com> wrote:
> 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 at 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 at lists.jboss.org [seam-dev-bounces at lists.jboss.org] On Behalf Of denis.forveille at gmail.com [denis.forveille at gmail.com]
>> Sent: Saturday, 21 November 2009 6:15 AM
>> To: seam-dev at 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 at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/seam-dev
>>
>> _______________________________________________
>> seam-dev mailing list
>> seam-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/seam-dev
>>
>
>
>
> --
> Gavin King
> gavin.king at gmail.com
> http://in.relation.to/Bloggers/Gavin
> http://hibernate.org
> http://seamframework.org
>



--
Gavin King
gavin.king at gmail.com
http://in.relation.to/Bloggers/Gavin
http://hibernate.org
http://seamframework.org



More information about the seam-dev mailing list