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
2 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
13 years, 10 months
@Alternative VS multiproject
by Geoffrey De Smet
One promise of @Alternative beans is to make it easier to mock out
things during testing.
In practice there are some problems to make that a reality.
For example, suppose we have this:
- foo-database-layer.jar
-- org/.../ProductionDatabaseSetup.class
--- Description: connects to the database on localhost (which is only
there on production).
-- org/.../TestDatabaseSetup.class
--- @Alternative
--- extends ProductionDatabaseSetup
--- Description: connects to an in-memory database and inserts testdata
in it.
- CustomerDAO
-- @Inject DatabaseSetup databaseSetup;
-- META-INF/beans.xml
--- Filled with other stuff
- foo-server.war
-- WEB-INF/lib/foo-database-layer.jar
-- WEB-INF/beans.xml
--- Filled with other stuff
Now, during the integrations tests of foo-server.war, we want to
replace ProductionDatabaseSetup with TestDatabaseSetup.
How?
1) Add a WEB-INF/beans-test.xml (just like logback-test.xml and logback.xml)
=> Does not work. It's ignored.
2) Change WEB-INF/beans.xml for the tests only.
Duplicate everything from the original.
Add declaration: <alternative>...TestDatabaseSetup</alternative>
=> Does not work. CustomerDAO still gets ProductionDatabaseSetup instead
of TestDatabaseSetup.
3) Change WEB-INF/lib/foo-database-layer.jar!META-INF/beans.xml for the
tests only.
Duplicate everything from the original.
Add declaration: <alternative>...TestDatabaseSetup</alternative>
=> Lots of code and tests are slow because of all the zipping and unzipping.
--
With kind regards,
Geoffrey De Smet
14 years, 4 months
