[webbeans-dev] @New
by Pete Muir
Since the change in the spec defining that there is a new bean for
every bean, we lost the language that disallows:
@New @SomeOtherBinding Foo foo;
AFAICT it still makes sense to disallow this. So, should that language
be there?
We also lost the language that disallows specific declaration of a
Bean as having @New as a binding type.
--
Pete Muir
http://www.seamframework.org
http://in.relation.to/Bloggers/Pete
16 years, 10 months
[webbeans-dev] wb-ri-int & idea
by Ales Justin
WRT webbeans-ri-trunk
My IntelliJ IDEA outlook looks broken.
Looking at the WebBeansBootstrapDeployer it cannot link to parts of
JBoss Deployers,
although they are in the Libraries.
Anyone using IDEA and seeing the same problems after re-running "mvn
idea:idea"?
btw: Pete, why is deployers module depending on ejb module (in pom.xml)?
deployer shouldn't depend on anything, as it runtime delegates things.
16 years, 10 months
[webbeans-dev] jdk6 features creeping in
by Ales Justin
[INFO]
------------------------------------------------------------------------
[ERROR] BUILD FAILURE
[INFO]
------------------------------------------------------------------------
[INFO] Compilation failure
C:\projects\web-beans\ri\tests\src\test\java\org\jboss\webbeans\test\unit\xml\javaeepkg\foo\Order.java:[14,17]
cannot find symbol
symbol : class CommonDataSource
location: package javax.sql
C:\projects\web-beans\ri\tests\src\test\java\org\jboss\webbeans\test\unit\xml\javaeepkg\foo\Order.java:[31,44]
cannot find symbol
symbol : class CommonDataSource
location: class org.jboss.webbeans.test.unit.xml.javaeepkg.foo.Order
C:\projects\web-beans\ri\tests\src\test\java\org\jboss\jsr299\tck\tests\implementation\enterprise\lifecycle\EnterpriseBeanLifecycleTest.java:[64,33]
cannot find symbol
symbol : constructor HashSet(java.util.List<java.lang.Class>)
location: class java.util.HashSet<java.lang.Class<?>>
16 years, 10 months
[webbeans-dev] Context.get with mismatched scopes
by David Allen
Hi Gavin,
I was just writing some tests and realized the spec in section 8.1 does
not clearly state what happens if I use a context from one scope and a
bean from a different scope. Should this be a runtime exception?
Example:
@Dependent
public class MyBean {}
...
Bean myBean = manager.resolveByType(MyBean.class).iterator().next();
MyBean myBeanInstance =
manager.getContext(SessionScoped.class).get(myBean);
-------------
David Allen
david.allen(a)acm.org
16 years, 10 months
[webbeans-dev] Request, Conversation and Session Scopes in Web Beans SE
by Peter Royle
Hi,
As mentioned previously, I've been doing some experimenting with using
the above contexts in Web Beans within the Java SE environment. Here are
some patches, diffed from the root webbeans directory, which will add
support for these contexts to the Web Beans SE Module project, plus
modify the Swing SE Numberguess example to use these scopes.
The key points are:
NUMBERGUESS
- A Session is pretty much the whole lifespan of the application, since
it's single-user.
- A Conversation is a single instance of the game, until it is either
won or lost.
- A Request is a single button click, and is mostly present to support
Conversations using the existing paradigms.
- The Game class is now Conversation scoped. No restart() necessary, the
NumberGuessFrame simply ends the current conversation when the game is
over and starts a new one.
- This allows the @Random number to be injected directly into Game for
each fresh conversation (rather than injecting the generator and hanging
on to it)
- NumberGuessFrame injects the current conversation and conversation
manager, as well as the JavaSELifecycle, all of which it uses to manage
the various contexts (Request, Session and Conversation)
- You can see these contexts being started and stopped during the
start(), guessButtonActionPerformed() and replayButtonActionPerformed()
methods.
WEB BEANS SE MODULE
- JavaSELifecycle added to help client apps and frameworks manage
lifecycle in SE. This would eventually end up in the SPI perhaps, or as
a better abstraction of an existing SPI interface.
- JavaSEConversationManager is copied from ServletConversationManager
and much of the common code should probably be pushed into an abstract
class.
- WebBeansBootstrap now registers everything except
ServletConversationManager and HttpSessionManager when in SE mode. It
also registers the new JavaSEConversationManager.
I would like to clean up the syntax for starting requests because it's
obviously pretty ugly and verbose right now. Maybe some kind of
annotation and interceptor pair perhaps? And possibly some
Swing-specific helpers to make it easy to attach the Request context to
a button click? Making this sort of stuff more transparent is my next
goal.
Let me know what you think, anyone. Cheers.
Pete.
16 years, 10 months
