[webbeans-dev] removeObserver type
by Clint Popetz
Hi,
The spec defines BeanManager.removeObserver to have a wildcard type:
public void removeObserver(Observer<?> observer);
and says "The container must stop sending event notifications to the
deregistered observer." Does that sentence, taken with the wildcard type,
imply that the observer should be removed for all events for which it is
registered? Currently ManagerImpl implements storage of observers as a map
from EventType -> Observer, which means removal of an observer without
knowing its event type would be linear in # observers, unless I change the
implementation.
Thanks,
-Clint
--
Clint Popetz
http://42lines.net
Scalable Web Application Development
15 years, 6 months
[webbeans-dev] Updating the RI to the PFD draft
by Pete Muir
Over the next week - which is the ETA Shane has given for updating the
audit document (which maps spec assertions to an id which are in turn
mapped to a test) - the RI will be siginifcantly out of sync with the
TCK. Please try to keep all tests passing in the TCK, but if the test
won't pass (e.g. it is out of date) then mark the test as ri-broken,
and we will do a pass over all of these once the TCK is back in sync.
So, in summary, try as hard as possible to keep the RI passing the TCK
before checkin, but if you can't, then that is ok.
15 years, 6 months
[webbeans-dev] Session-scoped beans and clustering
by Gavin King
So, yesterday I was thinking about the problem of session/conversation
context passivation and clustering.
Currently there is no notion of a "unique id" of a Bean object, which
the container would need in order to identify the session attribute
holding the Bean object.
In a pure-local execution model this is no big deal, since you can
just generate one the first time you see a Bean. However, in a
clustered environment it becomes an issue, especially when we have
custom Beans provided by portable extensions.
I don't see a better solution than introducing a new interface with a
getId() method:
interface PassivationCapable<X> extends Bean<X> {
String getId();
}
Instances of Bean could optionally implement PassivationCapable.
We would also need to add a method to BeanManager:
interface BeanManager {
PassivationCapable<?> getPassivationCapableBean(String id);
}
WDYT?
--
Gavin King
gavin.king(a)gmail.com
http://in.relation.to/Bloggers/Gavin
http://hibernate.org
http://seamframework.org
15 years, 6 months
Re: [webbeans-dev] jsr299-utils
by Matt Drees
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> 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> 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
>>
>
>
15 years, 6 months
Re: [webbeans-dev] Session-scoped beans and clustering
by Matt Drees
On Tue, May 26, 2009 at 8:46 PM, Gavin King <gavin.king(a)gmail.com> wrote:
> On Tue, May 26, 2009 at 5:43 PM, Matt Drees <matt.drees(a)gmail.com> wrote:
>
> > Why doesn't BeanIdentifier#toString() work for that? Or why can't the
> > context implement its own BeanIdentifier -> httpsession attribute
> mapping?
>
> If we're just going to call toString() on the thing, what is the point
> of BeanIdentifier?
I imagine some custom contexts don't need to be String based. A
Map<BeanIdentifier, Object> is potentially faster than a Map<String,
Object>, and (IMO) it makes for prettier code. I suppose the latter is my
primary motivation.
Maybe I've just been burned too many times by String being used
inappropriately.
>
>
>
>
> --
> Gavin King
> gavin.king(a)gmail.com
> http://in.relation.to/Bloggers/Gavin
> http://hibernate.org
> http://seamframework.org
>
15 years, 6 months
[webbeans-dev] Fwd: PFD submission June 8
by Gavin King
---------- Forwarded message ----------
From: Gavin King <gavin.king(a)gmail.com>
Date: Tue, May 26, 2009 at 5:45 PM
Subject: PFD submission June 8
To: Java Community Process JSR #299 Expert List <JSR-299-EG(a)jcp.org>
Folks, I want to submit the PFD on June 8.
I think the latest drafts of the spec are *much* better and have
addressed the criticisms of the public draft. Plus, we're running out
of time for this to make it into EE 6 and the RI team really need a
stable draft to work from or they're never going to be able to get the
TCK done in time.
So I want to close out the current discussions, and submit a spec that
is very close to the one attached (which contains some chapter
renaming requested by Oracle, and improvements to chapter preambles).
If anyone has changes they need to go into the PFD, please speak up now!
(Note that we will get the chance to correct any errors that the we or
the RI team find for the final draft, and we also might need to make
minor changes once we see the final managed bean and interceptors
specs.)
Thanks,
Gavin
--
Gavin King
gavin.king(a)gmail.com
http://in.relation.to/Bloggers/Gavin
http://hibernate.org
http://seamframework.org
--
Gavin King
gavin.king(a)gmail.com
http://in.relation.to/Bloggers/Gavin
http://hibernate.org
http://seamframework.org
15 years, 6 months
AW: [webbeans-dev] Towards CR1
by Mark Struberg
short question:
> * removing interceptor language from spec
Hmm without interceptors, how should we handle @Transactional and stuff? Having interceptors in the standard is pretty convenient.
LieGrue,
strub
--- Pete Muir <pmuir(a)bleepbleep.org.uk> schrieb am Do, 21.5.2009:
> Von: Pete Muir <pmuir(a)bleepbleep.org.uk>
> Betreff: [webbeans-dev] Towards CR1
> An: webbeans-dev(a)lists.jboss.org
> CC: ee6jboss(a)sun.com, roger.kitain(a)sun.com
> Datum: Donnerstag, 21. Mai 2009, 19:36
> All,
>
> As you've seen, Gavin is approaching publishing the PFD of
> 299; before the final draft can be submitted, we need to
> complete both the RI and TCK. We're under quite a tight
> schedule - we have around 6 weeks.
>
> 1) Shane will update the TCK audit (which maps the spec to
> the tests) to the current draft. Hopefully we will start to
> see this coming through early next week. Once this is done,
> we'll have a better idea of how much work there is to do.
>
> 2) David will take the lead on updating tests to the new
> TCK, with Shane working to help him. The order in which the
> tests are done should be same as for the RI
>
> 3) We'll do the major work on the RI in this priority
> order:
> - New SPI
> - New bootstrap
> - decorators
> - New resource handling stuff
> - minor fixes and changes as a result of
> the new spec language
>
> If you want to take on any of the above, please shout now!
>
> We still need clarification from Gavin/EG on:
>
> * removing interceptor language from spec
> * exactly how this inter-relates with the managed bean
> spec
> * exactly how we proceed when the RI supports a particular
> function which requires container integration, and no one
> container supports all integration points.
>
> I don't plan any interim releases between now and CR1, as
> releases take time, and we are under a tight schedule. These
> changes don't generally impact the core functionality
> (except around bootstrap), so I am confident that we don't
> need another beta.
>
> I do plan a reasonably long series of CRs to ensure that
> the codebase is stable, I don't have a firm date for the
> release yet. Once we enter the CR series, the 299 API and
> the Web Beans API/SPI cannot change.
>
> Thanks for all your hard work so far - getting to CR1 is a
> major milestone!
>
> Pete
> _______________________________________________
> webbeans-dev mailing list
> webbeans-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/webbeans-dev
>
15 years, 6 months
