[webbeans-dev] Copyright headers
by Pete Muir
Hi all,
We have been informed that the standard copyright headers which we
apply to source files are in error. They currently read "Copyright
<Year>, Red Hat Middleware LLC," when in fact they should read
"Copyright <Year>, Red Hat, Inc. and/or its
affiliates,". Please change your templates going forward; there is no
need to retroactively apply this change immediately. In the not-to-
distant future I will run a tool over all files in the Web Beans
project to update them.
I've also updated the website and the docs.
Pete
16 years, 7 months
[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?
16 years, 7 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-----
16 years, 7 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.
16 years, 7 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
16 years, 7 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)
16 years, 7 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
16 years, 7 months
