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
10 years, 10 months
CDI TCK 1.0.2
by Pete Muir
Team
I'm about to release CDI TCK 1.0.2.CR1 - please hold of any commits until it is published
Pete
12 years, 10 months
Tests failures
by Pete Muir
All
I've worked through the incontainer test failures we were seeing with Weld, and I am now down to these locally:
testSerializeSFSB(org.jboss.jsr299.tck.tests.implementation.enterprise.lifecycle.EnterpriseBeanLifecycleTest)
testPassivationOfPersistenceContext(org.jboss.jsr299.tck.tests.implementation.simple.resource.persistenceContext.PersistenceContextInjectionTest)
testPassivationOfPersistenceUnit(org.jboss.jsr299.tck.tests.implementation.simple.resource.persistenceContext.PersistenceContextInjectionTest)
All of which are related to serialization of proxies. David is going to take a look on Sunday at these.
If you see other failures locally, please investigate or discuss :-)
Pete
12 years, 10 months
interceptors expected to be implemented via proxying or via subclassing?
by Mark Struberg
Hi!
There is a subtle difference between implementing interceptors via proxy or via subclasses.
I have the following service which imports data from a legacy system into my db. Since commits are very performance intense, they should get imported in packages of 100. So I'll get 100 'Employees' from my legacy system and then call a @Transactional method to store them in my own database.
public void ImportService() {
public void importEmployee() {
List<LegacyEmployee> les;
while ((les = getNext100EmployeesFromLegacy()) != nul) {
importLegacyEmployees(le);
}
}
@Transactional
protected importLegacyEmployees(List<LegacyEmployee> les) {
for (LegacyEmployee le: les) {
employeeService.store(le);
}
}
}
This would actually _not_ work when using proxies for the interceptor handling, because calling a method on an own class doesn't invoke the proxyhandler.
So is this expected to work?
I remember that the old spec explicitly says that we need to use subclassing, but cannot find this paragraph anymore. So what does the spec require us to do? And what is Weld going to do?
txs and LieGrue,
strub
12 years, 10 months
Weld Extensions Alpha2 available
by Pete Muir
All,
I have published the next release of Weld Extensions. It consists of a tidied up API, a long with a number of improvements:
* Determine if an interceptor is enabled
* Ability to load plug in new resource loaders (e.g. Servlet)
* Much tidier package structure
* rationalization of annotated type builders
Stuart has also made some improvements, which I'll let him outline.
I don't intend to push this release extensively, as the documentation is still (very) poor - but I wanted to get this out so that it can be used by modules depending on it. We'll get the javadoc fixed and alpha3 out soon.
Pete
12 years, 10 months
star spec lead nominations
by Dan Allen
All of us share a passion for JSR-299 and the change it brought to Java EE
6. If you are interested in showing your appreciation, perhaps you would be
willing to nominate Gavin as a star spec lead for working in a transparent
and collaborative way to create this standard. This specification is
especially unique because Gavin and the JSR-299 EG selected the use of the
Apache License for both the implementation and the TCK, a clear commitment
to openness.
Details here: http://community.jboss.org/wiki/2010StarSpecLeadNominations
While you are thinking about it, I encourage you to consider nominating
Emmanuel Bernard for JSR-303 (Bean Validation) as well. Emmanuel worked
entirely in the open (forums, spec draft, blogs) and also selected the ASL
for the implementation and TCK.
I believe that both Gavin and Emmanuel are very deserving of this award and
I certainly hope that they are recognized for their leadership.
Cheers,
-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://www.google.com/profiles/dan.j.allen
12 years, 10 months
How to obtain logger in an interceptor?
by Marcin Zajączkowski
Hi,
I am working on a Perf4j [1] integration with CDI/Weld (sister project
to Seam-Perf4j [2] which offers integration with Seam 2.2.x). Perf4j
heavy uses logger for its performance statistics.
I would like to ask is there an unified way in CDI to obtain a logger in
an interceptor?
In Seam 2.2.x I could get logger with:
org.jboss.seam.log.Logging.getLog(loggerName)
With Weld I don't want to get Weld logger directly - I would like to be
compatible with other CDI implementations as well.
I have seen Weld's extension for logging, but it's rather for injection
logger into "normal" beans, not to obtain it explicitly in an
interceptor (it's a producer which calls LoggerFactory.getLogger() from
slf4j which I can do directly).
Is it possible to get logger proper for CDI implementation in context
which my code is running? Or the best solution would be to use slf4j
logger with hope it is already using there?
[1] - http://perf4j.codehaus.org/
[2] - http://seam-perf4j.sourceforge.net/
Thanks for your comments
Marcin
12 years, 10 months
Latest released TCK excludes
by Pete Muir
TCK team,
As you know, part of the maintenance of the TCK is to fix incorrect tests in the 1.0 branch. In addition to fixing the tests for the next release, we need to keep a list of current excludes that someone should use when using the last TCK release that reflects the issues reported. As part of checking each test challenge I will maintain this file https://svn.jboss.org/repos/weld/cdi-tck/branches/1.0/impl/src/main/resou... which contains the exclude list. We will reset this file back to empty at TCK release time.
When you fix a test, please locate the exclude in this file and verify that it is correct!
Thanks,
Pete
12 years, 10 months
