BTW, what exactly are the implications of adopting this rule for the SPI?
Do we still need to pass some sort Module object around, or can the
container figure it out based upon the Class objects?
Does the container just call theClass.getClassLoader() and then cast
it to some internal ClassLoader subclass to determine exactly where
the class came from?
We need to figure out how this works so I can update the SPI.
On Wed, May 20, 2009 at 9:37 PM, Gavin King <gavin.king(a)gmail.com> wrote:
> Folks, I spent a bunch of time with Bill Shannon and Roberto today.
> The results of these discussion were:
> Inter-module dependencies
> We shouldn't introduce any special module-level dependency mechanism
> or module-private dependencies (such as my proposal for @Exported
> beans). We should wait for the Java Module System for that kind of
> Instead we'll say that an injection point of a class X can resolve to
> a bean Y only when the Java EE spec requires that the bean class Y is
> visible to X (section 8.3 of the spec). So, for example, a bean in
> ejb-jar A is not available for injection into a bean in another
> ejb-jar B unless A declares a dependency to B in manifest.mf.
> This solution isn't quite as powerful as module-private dependencies,
> but it solves the cases I raised earlier today, and we'll get
> something more powerful when the Java Module System arrives.
is rather large, but it wasn't possible to make it smaller and still
commit without breaking tests. It consists of:
* Make the BeanManager interface match the spec. Since this was
rather large and involved a lot of changes, I went ahead and reorder
the methods to match the order that they are specified in JSR-299, so
that it's easier to track changes in the spec.
* Introduce new classes that the above signatures use, e.g.
* Make ManagerImpl implement the parts of the above changes
necessary to allow the rest of the source base to compile.
* Create a bridge in the tck-impl to implement removed calls in the
old SPI which the tck uses heavily and which weren't easily
refactorable as direct calls to the new SPI methods, for instance
getInstanceByType and getInstanceByName
* Make the tck use that bridge, and also use new signatures for
things that were easier to refactor, like addObserver and
* Make the bootstrap fire the new bootstrap events,
Before/AfterBeanDiscovery and AfterDeploymentValidation.
* Create implementations of those events, which I've placed in the
bootstrap package but which arguably could go in the events package
* Make the tests for those events work, because they are now
interfaces rather than binding annotations, and because their
semantics have changed. (BeforeBeanDiscovery was previously fired
_after_ beans were registered, but I have changed it to fire before,
which I think is correct.) Though this is not a complete coverage of
those events in the spec. For example, there is a requirement that
the validation phase collect all exceptions reported via observers
through AfterDeploymentValidation.addDeploymentProblem and report them
all after all observers have run.
* Add the javax.el api dependency to the api pom, since BeanManager
I have no tck failures out-of-container, and I have a few (less than
ten) sporadic failures in-container that I'm trying to nail down, but
I wanted to get the above changes in so that Pete would have the
annotated* classes in the api package to implement, and because I'm
tired of merging conflicts with all these changes :)
Let me know if there are issues I should resolve. Otherwise I'm going
to fix the above failures and then continue implementing the new
methods in ManagerImpl, in particular createInjectionTarget(), which I
need to make the wicket integration portable.
This is my first commit of any size to the core and the tck, so if I
have screwed up please let me know and I'll correct it promptly.
Scalable Web Application Development
I'm just full of them, it seems.
I'm able to get the tck runner to connect to jboss 5.1, but it gets
ClassNotFoundErrors for all the webbeans classes when running tests.
If I run ant in webbeans-build-aggregator/jboss-as, it installs an
artifact from repository.jboss.org, because it's resolving
which is obviously not what I want. Should I be building my owner
version of webbeans-jboss-int-deployer locally to avoid this?
I've tried running the tck from within eclipse by following the instructions
but I'm having no luck; it can't find an implementation of
StandaloneContainers, although I've manually added the runner to the
tck-impl project's dependencies.
Before I dive deeper, are those directions up to date? Is anyone running
the tck from within eclipse? If so, are you generating projects with
eclipse:eclipse or with m2eclipse?
Scalable Web Application Development
How much control do we have over filter ordering in the new servlet
spec? now that web.xml fragments can be packaged into modules? Is it
possible to define a total ordering?
On Sun, May 31, 2009 at 1:49 PM, Michael Youngstrom <youngm(a)gmail.com> wrote:
> The after filter solution still isn't going to make everyone happy
> either. For example, if someone wants to provide some solution that
> hides the conversation in the JSF view state then this would not work
> for them either.
> If you want to keep it simple then just define the Conversation as
> being available for the whole request using a request parameter for
> propagation. We could still add to this default conversation
> implementation the Extension event. And this would be the definition
> of the default provided @ConversationScoped Context. If JSF or Wicket
> wishes to manage the conversation id in a completely different way
> then let them provide their own Context implementation for
> @ConversationScoped. :)
> So rather than catering to Wicket or JSF let's just cater to the
> servlet spec and let frameworks create their own ConversationContext
> if they want more control over Conversation propagation.
> On Sun, May 31, 2009 at 1:40 PM, Gavin King <gavin.king(a)gmail.com> wrote:
>> 2009/5/30 Michael Youngstrom <youngm(a)gmail.com>:
>>> I'm not really happy with this solution. Over the last couple of
>>> hours I've really grown to like the power of a more servlet general
>>> conversation available to the full request. If a developer doesn't
>>> care about using a request parameter they shouldn't have to live with
>>> the post Filter restriction.
>> I'm also finding this idea to be pretty seductive.
>>> Isn't there some way we can make the conversation context more
>>> pluggable/extensible itself? WebBeans could ship with a general
>>> friendly request parameter based conversation propagation mechanism
>>> and other frameworks like Wicket could replace or extend the provided
>>> Conversation Manager to better fit their propagation requirements
>>> along with the potential limitations?
>> In this release I don't want to do something extremely complex here.
>> If there is a simple solution that covers the major integration
>> usecases that we can think of, fine, let's go with it. But if not, I
>> would rather defer it.
>> Gavin King