Somewhere in the back of my brain, I remember that
public void dingsBums(InvocationContext ivc) throws Exception;
MUST declare the 'throws Exception', otherwise it's illegal.
Am I right, or is my brain tricking me?
If the Exception is mandatory, the TCK needs to be changed:
(and maybe others)
txs and LieGrue,
Do You Yahoo!?
Sie sind Spam leid? Yahoo! Mail verfügt über einen herausragenden Schutz gegen Massenmails.
I've started crafting this from list discussions http://www.seamframework.org/Documentation/Seam3DesignOverview
If you are leading a module, please review and edit the documents to provide a nice elevator pitch for the module :-)
Some of the text is *very* rough right now, but I think it starts to provide some structure - I will continue working on this tomorrow.
I've been playing with weld-test, and it'd be neat if a test could specify
which Extensions it'd like to use (in an annotation or via dsl-ish config).
But it seems WeldBootstrap is directly using a DefaultServiceLoader to find
So, could this be abstracted into an ExtensionLoaderService interface /
DefaultServiceExtensionLoaderService impl? Then tests could set up their
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