Content-Type: text/plain; charset=ISO-8859-1; format=flowed
I saw the max maven version constraint was added to the new parent POM.
Can we make it a min version only constraint like it used to be?
I think it'll be more convenient for causal contributers if they don't
have to maintain a legacy maven version just to build our project.
Some interceptors classes in the TCK test suites implement @PreDestroy methods. AFAIK, interceptors specification says that methods with @PreDestroy in interceptor class must take InvocationContext parameter. But in TCK, those methods do not take InvocationContext parameter
@PreDestroy public void destroy()
destroyed = true;
Is it correct?
Great work on this, Peter, it's really nice.
I think we should let you specify an event type to raise:
or, perhaps, an event qualifier to be applied to the ContainerInitialized event:
that way, you have a mechanism for choosing between "main methods".
Alternatively, we could use something EL-ish to specify a method to call:
Hrm, perhaps that's the best option. Maybe my idea of using an event
wasn't so great after all.
A minor detail but do you think it would be handy if Weld would
support some kind of module info metadata that could be displayed on
bootstrap? It could be handy to see which modules
are present and have been picked up correctly... Something in the line
of a <module-info>Weld-Excel 3.0.1</module> in beans.xml so that a
list of enabled modules and extensions could be listed
when the container boots. It could even be extended to cover possible
Just a quick note for anyone looking to use the upcoming JBossAS
6.0.0.M1 in Embeddable fashion, we're nearing the first release of
EmbeddedAS 1.0.0-alpha-1. If you'd like to kick the tires a bit before
lockdown, it's last call. :)
I'll continue to provide EmbeddedAS releases against the most recent AS
release as needed.
Documentation lives here, with links to use cases at the bottom
(configuring Maven, doing proper ClassLoading, and starting the server)
Andrew Lee Rubinger
Sr. Software Engineer
JBoss by Red Hat
Great. Okay, just so that I am explaining this right in my talk, if
@Resource and family are on an EJB the EJB container does the injection, but
if the are on a managed bean (i.e., simple bean) then CDI does the
injection. Is that correct?
- Dan Allen
Sent from my Android-powered phone:
An open platform for carriers, consumers
On Nov 30, 2009 6:38 AM, "Pete Muir" <pmuir(a)redhat.com> wrote:
It does :-)
We even have a test!
On 27 Nov 2009, at 15:01, Gavin King wrote: > Pete, does this work in, say,
Tomcat: > > @Resour...
Jason Porter pointed out that 12.3 says:
"The container determines which alternatives, interceptors and decorators are enabled, according to the rules defined in Sec- tion 5.1.2, “Enabled and disabled beans”, Section 9.4, “Interceptor enablement and ordering” and Section 8.2, “Decorator enablement and ordering”, taking into account any >>><enable><<<<, <interceptors> and <decorators> declarations in the beans.xml files, and registers the Bean and ObserverMethod objects:"
Elsewhere the spec still talks about <alternatives>, so I think this is a typo in the spec?
I think we should try and follow the Java EE models as closely as
possible for this stuff. We should simply try and make the Java EE
code work outside EE 6.
(1) use a resource declaration with @PersistenceContext(unitName=....)
to define a managed persistence context
(2) use JBoss Transactions to manage transactions in a servlet engine
- so instead of having a special tx manager for JDBC, it is just JTA
Or is the 10meg download for JBoss Transactions just no good?