[webbeans-dev] Fwd: Draft
by Gavin King
Guys, please take notice of this draft:
* Clint, I made some changes to the SPI, hope it's not too disruptive!
* Pete, check the stuff about dependent objects, please, I want to
know that it's not still broken
---------- Forwarded message ----------
From: Gavin King <gavin.king(a)gmail.com>
Date: Tue, May 26, 2009 at 11:28 AM
Subject: Draft
To: Java Community Process JSR #299 Expert List <JSR-299-EG(a)jcp.org>
OK, I did some work over the long weekend:
Extension SPI
+++++++++++
Now has a more consistently layered architecture, and accommodates
session beans properly. This involved:
* splitting Producer out of InjectionTarget and adding Listener
* adding SessionBean and BeanClass (containing common operations of
SessionBean and ManagedBean)
* adding setInjectionTarget() / setProducer() / setListener() on XxxxxBeans
* adding getXxxxBean() to ProcessXxxxxBean()
I think this is a big improvement, even though it involves a couple of
extra interfaces, but see for yourself :-)
Dependent object destruction
++++++++++++++++++++++
I've also included my proposal for fixing dependent object
destruction. The proposed changes are in the following sections:
* 5.5.2,
* 6.1 - 6.2
* 6.4.1-6.4.3
This is a significant change to SPIs (6.1-6.2) and a slight change to
user-visible behavior (5.5.2), so *please* review this thoroughly. I
do not enjoy making a change like this so late in the process.
Conversation exceptions
+++++++++++++++++++
I've added NonexistentConversationException and
BusyConversationException in 6.7.4. Please review.
@Observes
+++++++++
Finally, I've rolled in the proposed changes to @Observes. Please
check that you're OK with this.
--
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, 7 months
[webbeans-dev] getEnabledDeploymentTypes signature
by Clint Popetz
Hi,
Is there any reason BeanManager.getEnabledDeploymentTypes shouldn't be:
public List<Class<? extends Annotation>> getEnabledDeploymentTypes()
rather than
public List<Class<?>> getEnabledDeploymentTypes()
The existing ManagerImpl stores that list with the former type, and
Bean<T> assumes that as well:
Class<? extends Annotation> getDeploymentType();
-Clint
--
Clint Popetz
http://42lines.net
Scalable Web Application Development
15 years, 7 months
[webbeans-dev] Differences between PRD2 and JSR-299-20090519
by Shane Bryzak
For anyone that's interested, I've highlighted the sections of the
20090519 release of the spec where the contents differ from PRD2. This
annotated document will be used as the base for updates to the
tck-audit.xml file in the 299 TCK.
15 years, 7 months
[webbeans-dev] CreationalContext.destroyDependents()
by Gavin King
Folks, I think we should add a new method to CreationalContext, to
allow for easier and efficient implementation of custom Context
objects.
public interface CreationalContext<T> {
public void push(T incompleteInstance);
public void destroy();
}
The destroy() method would destroy any dependent objects of the
instance that was created in that CreationalContext.
The custom Context would be responsible for maintaining the list of
CreationalContexts internally, and calling destroy() on each of them
when the context is destroyed. This would allow the container to
optimize out any map lookups, etc.
WDYT?
--
Gavin King
gavin.king(a)gmail.com
http://in.relation.to/Bloggers/Gavin
http://hibernate.org
http://seamframework.org
15 years, 7 months
[webbeans-dev] Revisions to the SPI
by Gavin King
I've finished updating the SPI to reflect some of the things we've
been discussing:
* Extensions are now injectable 11.5
* there are now subclasses of ProcessBean for different kinds of beans 11.5.7
* addBean() and addObserver() now fire events 11.2.7, 11.2.8
* I have clarified assignability for parameterized event types 11.3.1
* Event.removeObserver() 10.4.1
* Observer.notify() now returns boolean 10.2
>From my point of view, I would now be happy to submit the PFD, since
my list of critical issues is now exhausted.
So now's the time to:
* review the spec for errors!
* speak up if you have issues that have not been addressed!
--
Gavin King
gavin.king(a)gmail.com
http://in.relation.to/Bloggers/Gavin
http://hibernate.org
http://seamframework.org
15 years, 7 months
[webbeans-dev] jsr299-utils
by Clint Popetz
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
15 years, 7 months
[webbeans-dev] Towards CR1
by Pete Muir
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
15 years, 7 months
