[webbeans-dev] jsr299-utils

Pete Muir pmuir at redhat.com
Tue May 26 08:13:46 EDT 2009 

On 25 May 2009, at 16:18, David Allen wrote:

> On Sun, 2009-05-24 at 10:21 -0500, Clint Popetz wrote:
>> Great, I'll get started on it Tuesday.
>>
>> I haven't done work on the core before, only on extensions, and I
>> haven't dealt with the TCK at all.  So I have a few questions with
>> regard to the webbeans development process:
>>
>> (1) I'm going to start by focusing on javax.enterprise.inject.spi.
>> This means some pretty heavy refactoring, including repackaging
>> javax.inject.* and changing Bean and Decorator to be interfaces,  
>> which
>> is going to ripple through the whole source base.  Is it preferred
>> that this is committed in small chunks, even if that means the
>> resulting source base is not buildable in between commits, or  
>> should I
>> commit them in the smallest chunks that allows the core to build,
>> which in this case might be rather large?
>
> In general, it is best to pick a small part of functionality to add,
> write the tests, complete the implementation, and check that in.
>
> In this case, the moving of existing interfaces (and
> renamings/extraction) has wide-spread implications.  If you do not  
> mind,
> I am going to complete that part today.  So by Tuesday, you should be
> able to work on the SPI itself and add the new functionality without
> having to worry about breaking things other than the RI and perhaps  
> any
> extensions that might already be dependent on the RI (there  
> shouldn't be
> any yet that I know of).

Agreed, someone (David has volunteered I think) should do a full  
update to the jsr299-api, rather than it being done piecemeal.

>
>
>>
>> (2) Is it acceptable to cause test failures in webbeans-core-test
>> during the early stages of this work, or should I be fixing all tests
>> as I go.
>
> Usually not a good idea to break tests.  The tests are always a good  
> way
> to make sure your implementation is sound and that you did not break  
> any
> existing functionality.  These tests do depend a bit more on the RI,  
> but
> if you use an IDE that can help with the refactoring between RI and  
> the
> JSR-299 API, problems should be minimal.
>
>>
>> (3) Given that the work involves repackaging/renaming, a lot of  
>> things
>> are going to break in dependent modules.  Should I be
>> checking/building/testing these other modules, and in particular the
>> webbeans extensions, as I'm making these changes, or can they be
>> corrected at a later date?
>
> I think it might be OK to work on webbeans extensions afterwards.   
> As I
> stated above, though, I should have all the repackaging/renaming done,
> and the rest of the work should just be "new" SPI interfaces extracted
> from the RI.  That should not have any impact on dependent modules.   
> We
> do not usually write code in other modules dependent directly on the  
> RI.
>
>>
>> (4) What is the timetable for reaching the next release milestone  
>> with
>> these changes, i.e. will the next webbeans release target this draft
>> of the spec, and if so, what is its target date?  Is there an  
>> internal
>> stabilization/qa process on that release?
>
> Yes, the next release needs to target the latest version of the spec.
> This needs to be done before the end of June, but Pete should have a
> more exact date for you.

As David says, by the end of June, but really ASAP.

>
>
>>
>> (5) With regard to the TCK, should I be adding TCK tests as I'm
>> implementing the SPI?  If so, does the TCK target a specific revision
>> of the spec?  (It's not clear to me if the spec itself is even
>> versioned during the draft process.)  For example, right now the
>> contents of tck-audit.xml and many of the @SpecAssertions don't match
>> the current spec, as it just came out.    So is it ok to add tests to
>> tck-impl that target things in the new spec (for example, 11.2 to  
>> test
>> the BeanManager SPI), given that these new @SpecAssertions will
>> overlap with existing assertions for similar numbers in the older
>> spec, and given that the audit tool will report garbage for the new
>> assertions?
>
> Another team member is working on tck-audit.xml and should be done  
> soon.
> I would not write any new TCK tests right now without knowing what the
> assertion numbers are going to be.  Check back later after you have  
> more
> of the SPI done and the TCK is more in-line with the current spec.

Shane has started on this, and we should see the updates starting to  
come. Shane, can you let the list know as you go?

>
>
>>
>> Thanks,
>> -Clint
>>
>> On Sun, May 24, 2009 at 7:21 AM, David Allen <drallendc at gmail.com>
>> wrote:
>>        On Sat, 2009-05-23 at 16:51 -0500, Clint Popetz wrote:
>>> I'm happy to start work on it, but I don't want to step on
>>        someone
>>> else's work.  Has any work on the SPI changes been
>>        allocated?
>>>
>>
>>        As of Thursday evening, nobody claimed the SPI changes yet, so
>>        I think
>>        it would be OK for you to do that, if you are still
>>        interested.
>>
>>
>>> -Clint
>>>
>>> On Sat, May 23, 2009 at 12:32 PM, Gavin King
>>        <gavin.king at gmail.com> wrote:
>>>> We need an impl of the SPI as soon as possible, since we
>>        need to know
>>>> if there's any bugs in it :-)
>>>>
>>>> On Sat, May 23, 2009 at 5:07 AM, Clint Popetz
>>        <cpopetz at gmail.com> wrote:
>>>>> Matt,
>>>>>
>>>>> Thanks, 11.4 in the spec
>>        (BeanManager.createInjectionTarget and
>>>>> InjectionTarget.inject) is exactly what I need.
>>>>>
>>>>> So, who's implementing that, and what's the time frame
>>        for it?   I can
>>>>> do that, if no one's scheduled it do it.
>>>>>
>>>>> -Clint
>>>>>
>>>>> On Fri, May 22, 2009 at 11:03 PM, Matt Drees
>>        <matt.drees at gmail.com> wrote:
>>>>>> Oops, meant to send that to the list, not just Clint.
>>>>>> Sorry for the dup, Clint.
>>>>>>
>>>>>> -Matt
>>>>>>
>>>>>> On Fri, May 22, 2009 at 11:58 PM, Matt Drees
>>        <matt.drees at gmail.com> wrote:
>>>>>>>
>>>>>>> Before you go too far down this road, you might want to
>>        get a new draft of
>>>>>>> the spec from Gavin.  Recently an SPI was added
>>        specifically for injection
>>>>>>> into third-party objects, so I don't think the project
>>        you're proposing
>>>>>>> needs to exist.
>>>>>>>
>>>>>>> -Matt
>>>>>>>
>>>>>>>
>>>>>>> On Fri, May 22, 2009 at 6:34 PM, Clint Popetz
>>        <cpopetz at gmail.com> wrote:
>>>>>>>>
>>>>>>>> I'm investigating how to best move non-contextual
>>        injection into a
>>>>>>>> webbeans extension that's jsr299-impl independent.
>>         While I could
>>>>>>>> rewrite a stripped down version of the reflection
>>        scanning/caching
>>>>>>>> code that is already used by the existing
>>        webbeans-specific
>>>>>>>> non-contextual-injector, but it wouldn't be as
>>        performant or compliant
>>>>>>>> as the code that's already in the core, and I'm
>>        wondering if it's
>>>>>>>> reasonable to try to break out this chunk of the core
>>        into a library
>>>>>>>> which my extension (and possibly others in
>>        webbeans-extensions) uses.
>>>>>>>>
>>>>>>>> These would be some coherent self-contained subset of
>>>>>>>> org.jboss.webbeans.{injection, introspector,
>>        introspector.jlr,bean,
>>>>>>>> metadata, util}.  I think of this as the part of the
>>        core that
>>>>>>>> examines classes and builds a metamodel about the
>>        beans they
>>>>>>>> represent, and knows how to inject them, but doesn't
>>        deal with
>>>>>>>> contexts, bootstrapping, and the zillion other things
>>        the core does.
>>>>>>>> I think it could probably be made
>>        implementation-independent based on
>>>>>>>> the jsr299-api.  It would have to be made independent
>>        of ManagerImpl,
>>>>>>>> mainly.
>>>>>>>>
>>>>>>>> It couldn't live in webbeans-extensions obviously,
>>        since the core
>>>>>>>> would depend upon it.   But if it lived in
>>        webbeans-model, then
>>>>>>>> webbeans-core could depend on it, as could
>>        jsr299-utils.
>>>>>>>>
>>>>>>>> Thoughts?   This is not terribly well investigated
>>        yet, so those with
>>>>>>>> more experience with the source base, feel free to
>>        wave me off.  I
>>>>>>>> just hate duplicating code.
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> -Clint
>>>>>>>>
>>>>>>>> --
>>>>>>>> Clint Popetz
>>>>>>>> http://42lines.net
>>>>>>>> Scalable Web Application Development
>>>>>>>> _______________________________________________
>>>>>>>> webbeans-dev mailing list
>>>>>>>> webbeans-dev at lists.jboss.org
>>>>>>>> https://lists.jboss.org/mailman/listinfo/webbeans-dev
>>>>>>>
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> webbeans-dev mailing list
>>>>>> webbeans-dev at lists.jboss.org
>>>>>> https://lists.jboss.org/mailman/listinfo/webbeans-dev
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Clint Popetz
>>>>> http://42lines.net
>>>>> Scalable Web Application Development
>>>>>
>>>>> _______________________________________________
>>>>> webbeans-dev mailing list
>>>>> webbeans-dev at lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/webbeans-dev
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Gavin King
>>>> gavin.king at gmail.com
>>>> http://in.relation.to/Bloggers/Gavin
>>>> http://hibernate.org
>>>> http://seamframework.org
>>>>
>>>
>>>
>>>
>>        --
>>
>>        David Allen <drallendc at gmail.com>
>>
>>
>>
>>
>>
>> -- 
>> Clint Popetz
>> http://42lines.net
>> Scalable Web Application Development
>> _______________________________________________
>> webbeans-dev mailing list
>> webbeans-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/webbeans-dev
>
> _______________________________________________
> webbeans-dev mailing list
> webbeans-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/webbeans-dev

More information about the weld-dev mailing list