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(a)gmail.com&gt; 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(a)gmail.com&gt; 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(a)gmail.com&gt; 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(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/webbeans-dev >> > > > _______________________________________________ > webbeans-dev mailing list > webbeans-dev(a)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(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/webbeans-dev

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?

-Clint On Sat, May 23, 2009 at 12:32 PM, Gavin King <gavin.king(a)gmail.com&gt; 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(a)gmail.com&gt; 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(a)gmail.com&gt; 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(a)gmail.com&gt; 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(a)gmail.com&gt; 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(a)lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/webbeans-dev >>>> >>> >>> >>> _______________________________________________ >>> webbeans-dev mailing list >>> webbeans-dev(a)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(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/webbeans-dev >> > > > > -- > Gavin King > gavin.king(a)gmail.com > http://in.relation.to/Bloggers/Gavin > http://hibernate.org > http://seamframework.org >

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?

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

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

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

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

Thanks, -Clint On Sun, May 24, 2009 at 7:21 AM, David Allen <drallendc(a)gmail.com&gt; 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(a)gmail.com&gt; 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(a)gmail.com&gt; 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(a)gmail.com&gt; 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(a)gmail.com&gt; 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(a)gmail.com&gt; 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(a)lists.jboss.org > >>>>> https://lists.jboss.org/mailman/listinfo/webbeans-dev > >>>> > >>> > >>> > >>> _______________________________________________ > >>> webbeans-dev mailing list > >>> webbeans-dev(a)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(a)lists.jboss.org > >> https://lists.jboss.org/mailman/listinfo/webbeans-dev > >> > > > > > > > > -- > > Gavin King > > gavin.king(a)gmail.com > > http://in.relation.to/Bloggers/Gavin > > http://hibernate.org > > http://seamframework.org > > > > > -- David Allen <drallendc(a)gmail.com&gt; -- Clint Popetz http://42lines.net Scalable Web Application Development _______________________________________________ webbeans-dev mailing list webbeans-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/webbeans-dev

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(a)gmail.com&gt; > 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(a)gmail.com&gt; 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(a)gmail.com&gt; 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(a)gmail.com&gt; 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(a)gmail.com&gt; 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(a)gmail.com&gt; 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(a)lists.jboss.org >>>>>>> https://lists.jboss.org/mailman/listinfo/webbeans-dev >>>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> webbeans-dev mailing list >>>>> webbeans-dev(a)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(a)lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/webbeans-dev >>>> >>> >>> >>> >>> -- >>> Gavin King >>> gavin.king(a)gmail.com >>> http://in.relation.to/Bloggers/Gavin >>> http://hibernate.org >>> http://seamframework.org >>> >> >> >> > -- > > David Allen <drallendc(a)gmail.com&gt; > > > > > > -- > Clint Popetz > http://42lines.net > Scalable Web Application Development > _______________________________________________ > webbeans-dev mailing list > webbeans-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/webbeans-dev _______________________________________________ webbeans-dev mailing list webbeans-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/webbeans-dev

On Tue, 2009-05-26 at 13:13 +0100, Pete Muir wrote: > 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? Most of the heavy refactoring is now done w.r.t. the JSR-299 API. The following items still need to be addressed and will be as quickly as possible: 1. BeanManager should no longer have getInstanceByType() or getInstanceByName(), rather the newer getReference(Bean<?>...) type of methods. If that is correct, this refactoring requires more manual programming on the TCK...it is not something that Eclipse can do automatically due to the new signatures and objects required. 2. The @Fires annotation has not been removed yet either. This too requires more manual work on the TCK and any other projects that might have used it. I will start work on this next. 3. There are still some exceptions in JSR-299 API that are no longer in the spec. These need to be removed, but in each case, a replacement exception is needed. Since this might affect quite a few classes, it would be good to get this done ASAP, but I am not really certain what to replace the exceptions with. I probably need to see each case and look it up in the new specifications. That should hopefully be all of it. Everything else should be new in the SPI and thus would not impact existing TCK tests or extensions, etc. If it looks like something has been overlooked, please let me know. If the impact is large scale, I still have all the projects setup for quick refactoring in Eclipse. If the impact is small, then Clint can easily make the change too while doing the SPI. > > > > 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. > > >