[webbeans-dev] capturing module context in the SPI
by Kenneth Saks
I'd like to follow-up on the module context SPI discussion from the
July 31st con call. There are a number of SPI methods that will be
ambiguous w.r.t. module in the presence of an .ear with multiple 299-
enabled modules.
For example, EjbServices.resolveEjb(InjectionPoint injectionPoint) and
JpaServices.resolvePersistenceContext(String unitName). These are
both cases where the container side needs additional module context
but there are probably equivalent cases for the webbeans side of the
contracts.
One way to solve this is to move the services registrations to the
BeanDeploymentArchive level instead of on Bootstrap, since there is
only one instance of Bootstrap for the entire .ear. Thoughts?
15 years, 4 months
[webbeans-dev] Who is sending viruses to this list?
by Benjamin Graf
-----BEGIN PGP SIGNED MESSAGE-----
Hash: RIPEMD160
Hi all together,
I just received a malware containing email from the webbeans-dev list
([webbeans-dev] Message could not be delivered).
I would recommend to check your PCs immediately if your owning a M$
OS! :-)
Kind regards
Benjamin
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.12 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEAREDAAYFAkp9KIkACgkQ+oSgMM7Y9KvRwgCghHmiYwcUMO8ewkYps4/7qNve
7toAoNTBWkERqED1tP7eshQuEBJk1GP5
=wvfZ
-----END PGP SIGNATURE-----
15 years, 4 months
[webbeans-dev] Message could not be delivered
by Returned mail
The message was not delivered due to the following reason:
Your message was not delivered because the destination computer was
unreachable within the allowed queue period. The amount of time
a message is queued before it is returned depends on local configura-
tion parameters.
Most likely there is a network problem that prevented delivery, but
it is also possible that the computer is turned off, or does not
have a mail system running right now.
Your message was not delivered within 6 days:
Mail server 55.84.159.83 is not responding.
The following recipients did not receive this message:
<webbeans-dev(a)lists.jboss.org>
Please reply to postmaster(a)lists.jboss.org
if you feel this message to be in error.
15 years, 4 months
[webbeans-dev] event type with type variable
by Dan Allen
In several places, the specification reiterates that an event type may not
contain a type variable. However, it appears that this restriction is only
enforced at runtime when the event object is passed to either Event#fire()
or BeanManager#fireEvent() method. I would suggest that an validation check
be added so that the container detects an illegal Event definition at
deployment type. Here's an example of an illegal definition (from my
understanding):
public class VoterRegistration<T> { ... }
@Any Event<VoterRegistration<Democrat>> democratRegisteredEvent;
-Dan
--
Dan Allen
Senior Software Engineer, Red Hat | Author of Seam in Action
Registered Linux User #231597
http://mojavelinux.com
http://mojavelinux.com/seaminaction
http://in.relation.to/Bloggers/Dan
15 years, 4 months
[webbeans-dev] How does JSF deal with managed beans when Web Beans/299 is present?
by Pete Muir
Hi
I realized we have a potential conflict between JSF and 299 to do with
EE defined managed beans, which we need to address. Imagine the
following scenario: A managed bean is defined using @ManagedBean in a
war in which both JSF and Web Beans is enabled. In this case both JSF
and Web Beans will attempt to manage the bean, however according to
the latest note sent by Roberto Chinnici to the EE expert group, if
299 is present, 299 should manage the bean. We need to address how to
deal with this for both Web Beans and Mojarra.
Some points to consider:
* 90% of the time there is no problem, the Web Beans ELResolver is
installed before the JSF ManagedBeanELResolver. However the corner
case of an eager instantiated, application scoped managed bean with a
post construct lifecycle callback will cause us a problem. There may
also be other corner cases we haven't considered. For this reason, I
think we should consider being able to explicitly disable JSF managed
beans
* this doesn't affect other specs which may use managed beans as much,
(a) as Mojarra works in other containers than GlassFish, such as
Tomcat, where Web Beans may not be present
(b) 299 specifically states that JSF should use an ELResolver as
it's integration point (other specs integration point is programatic
and so can use an SPI if or similar - Ken's suggestion from our latest
meeting for those who were there)
* Mojarra will need to continue to provide xml-defined managed beans
when Web Beans/299 is present.
My suggested solution is to simply have a switch in Mojarra we can use
to "turn off" annotation-defined managed beans support (either
automatic via detection of WEB-INF/beans.xml or manual via web.xml or
programatically).
Pete
On 31 Jul 2009, at 20:11, Barbara Louis wrote:
> - How we deal with jsf managed beans when 299 is present?
> - 299 requires managed beans
> - JSF RI will need to make the change - the ques to ask is: should
> jsf manage the managed beans or should I let the EE container to
> manage it for me?
> - Pete will send an email on webbeans dev mailing list on this topic
> and include Mojarra mailing list (webtier(a)glassfish.dev.java.net)
15 years, 4 months
[webbeans-dev] Generic classes as bean types allowed?
by Mark Struberg
Hi!
I have the following situation:
public class MyClass<T> {
...
}
and like to inject a specialised instance of this class:
public class MyOtherBean {
private MyClass<Integer> myIntCls;
}
>From reading the spec (2.2.1), I was not sure if this is allowed. It would make sense, since we can nail down the exact implementation at the injection point. Otoh the classpath scanning part will get trickier.
LieGrue,
strub
15 years, 4 months
[webbeans-dev] Webbeans Junit Runner
by Aslak Knutsen
Hi,
I've written a Junit Runner for Webbeans support in TestCases. The following
features are supported:
- TestCase class field injection
- TestMethod arg injection
- Producers / Observers in the TestCase seems to work without any extras..
- 'Should' run in any EE/Servlet/SE enviroment (Only SE tested at the
moment)
The Runner tries to locate the appropriate BeanManager based on the
following rules in order:
- Lookup "java:comp/BeanManager" via JNDI -> EE enviroment
- If success use that BeanManager.
- Call CurrentManager.rootManager() -> Servlet enviroment / Previously
initiated SE enviroment
- If success use that BeanManager.
- Load class "org.jboss.webbeans.environment.se.StartMain" -> SE enviroment
- If success, initialize the enviroment using StartMain.main(new String[0])
and use CurrentManager.rootManager().
Overrides the default Junit TestMethod validation with a new set of rules:
- validatePublicVoid (default validatePublicVoidNoArgs)
- validateBindingTypeParameters (only arguments annotated with a BindingType
allowed)
Overrides the createTest method to inject TestCase fields:
pesudo: for each Field "annotated with a BindingType" set getInstanceByType
Overrides methodInvoker to inject TestMethod args:
pesudo: for each Arg getInstanceByType
Annotate the TestCase with @RunWith(Webbeans.class) and one should be good
to go..
If interested, the code with TestCase example can be found at:
http://pastebin.com/m66ad1894
--
--
Aslak Knutsen; +47 952 38 791; fax +47 22 33 60 24
Kongens gate 14; Boks 805 Sentrum, 0104 Oslo;
http://www.conduct.no; mailto:aslak@conduct.no
Conduct AS - Professional Open Source Services
- Red Hat/JBoss Premier System Integrator
- Pentaho Preferred Integration Partner
- Atlassian Technology Partner
15 years, 4 months
