[webbeans-dev] jsr299-utils
David Allen
drallendc at gmail.com
Mon May 25 11:18:41 EDT 2009
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).
>
> (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.
>
> (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.
>
> 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
More information about the weld-dev
mailing list