WELD-862 and Seam Cron
by Peter Royle
Hi,
I'm aiming to make a release of Seam Cron available within the next two weeks. Currently there is an outstanding issue (https://issues.jboss.org/browse/WELD-862) which prevents Cron from running properly with Weld. I have been able to carry on developing Cron by testing it against OpenWebBeans, but obviously if we are to release a Seam module it should work against Weld.
It would be nice if WELD-862 could be fixed as soon a possible so that all future versions will work well with Cron.
But more importantly I also probably need to do something special in Cron so that it will work with the version of Weld already deployed in JBoss AS and Glassfish, which will contain the bug. The workaround mentioned in the bug report is to deep copy the InvocationContext. I attempted to do this by serialising and unserialising the InvocationContext but couldn't due to UnserializableExceptions. Does anyone have any advice for me about how I might be able to work around this bug to support existing versions of Weld?
Cheers,
Pete R
8 months, 3 weeks
Adding Classes at Run-time
by Jason Lee
I have an odd question. I have a situation where I'm manually opening a
JAR and adding its classes to the ClassLoader. What I'd like to be able
to do is have Weld scan these classes for any relevant annotations and
take the proper actions, just as if the JARs were in the classpath when
the application started. I've been staring at the JavaDocs (build
locally, btw, as I can't find them on the web :| ) but I don't see any
way to request that Weld inspect a given class. Is it there and I'm
missing it? Am I going to have cobble together that functionality? Am
I asking for something that can't be done (right now)? Any nudges in
the right direction would be much appreciated. :)
--
Jason Lee, SCJP
President, Oklahoma City Java Users Group
Senior Java Developer, Sun Microsystems
http://blogs.steeplesoft.com
14 years, 4 months
Weld Tests
by Stuart Douglas
Hi Guys,
I have just gone through and converted to arquillian the last of the jboss test harness tests in the weld distribution. Unfortunately it is not possible to move all the tests across, as some tests have a dependency on the embedded weld container, which is not available in the incontainer profile (as the AS7 container is used instead).
With this is mind, I would like to make some changes to the test suite setup:
- rename tests-arquillian -> testsuite/integration
- rename tests -> testsuire/unit
- Get an alpha release of the 1.1 TCK and setup weld so it can be run against both 1.1 and 1.0
Aslo, is there any reason why we can't merge the porting package into the TCK runner?
Stuart
15 years
CDI TCK code style changes
by Martin Kouba
Hi,
from now on also CDI TCK will follow the JBoss community code style like
Weld, Seam 3, AS7 and most other JBoss projects.
The eclipse formatter config can be found in the ide-configs folder. For
IDEA users the code style is basically the same as the default IDEA
style (4 space tabs, braces on same line).
If anyone encounters any problem, please let me know.
Martin
--
Martin Kouba
JBoss Quality Assurance Engineer
E-mail: mkouba(a)redhat.com
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic
15 years
Weld Code Style Changes
by Stuart Douglas
Hi Guys,
>From now on weld will be following the JBoss community code style, bringing it in line with AS7, Seam 3 and most other JBoss projects. I have also setup the checkstyle plugin to make sure these coding conventions are followed.
The eclipse formatter config can be found in the ide-configs folder. For IDEA users the code style is basically the same as the default IDEA style (4 space tabs, braces on same line).
Any questions or problems let me know.
Stuart
15 years
cdi/weld/seam - testing failed deployments in arquillian
by Martin Kouba
Hi,
recently during CDI TCK arquillian migration (1.1 branch) we had to
replace test harness @ExpectedDeploymentException in tests expecting
deployment failure.
So currently in TCK we use @ShouldThrowException(Exception.class) on
arquillian deployment method. Indeed testing generic Exception is not
the best solution but in fact right now we cannot test exact deployment
causewhile there are no standardized CDI deployment-relatedexceptions
(in CDI 1.1 there will be - see CDI-118 Standardize deployment-related
exception classes). Also note that "Adding this annotation will force
@{@link Deployment} to be testable = false which will force @{@link
RunAsClient}".
The other possibility is to use something like Assert.fail("Deployment
should have failed...") or assert false in test method. Seam
Compatibility and Weld use this approach.
The question is whether to standardize this among all cdi/weld/seam
tests. I think we should use the arquillian way (@ShouldThrowException)
while its more obvious that we expect deployment failure and use
relevant expected exceptions as soon as CDI 1.1 arrives.
WDYT?
M
--
Martin Kouba
JBoss Quality Assurance Engineer
E-mail: mkouba(a)redhat.com
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic
15 years
