[JBoss Web Development] - Annotation processing in war files too aggressive?
by jaikiran pai
jaikiran pai [http://community.jboss.org/people/jaikiran] created the discussion
"Annotation processing in war files too aggressive?"
To view the discussion, visit: http://community.jboss.org/message/547701#547701
--------------------------------------------------------------
I have got a simple war file which contains an EJB3 bean (testing against AS trunk). The bean looks like this:
@Stateless
public class SimpleSLSB extends SimpleBase
{
...
The SimpleBase class (from which this bean extends) looks like:
public class SimpleBase
{
@Resource
private EJBContext ejbContext;
So this base class is just a POJO with @Resource injection for EJBContext. During deployment of this .war on AS trunk, the web application deployer incorrectly starts processing this SimpleBase class and throws this exception:
14:32:31,422 ERROR [StandardContext] Context [/myapp] startup failed due to previous errors: java.lang.RuntimeException: mapped-name is required for org.myapp.ejb3.impl.SimpleBase/ejbContext of deployment myapp.war
at org.jboss.web.tomcat.service.injection.WebResourceHandler.loadXmlResourceEnvRefs(WebResourceHandler.java:287) [:6.0.0-SNAPSHOT]
at org.jboss.web.tomcat.service.injection.WebResourceHandler.loadXml(WebResourceHandler.java:325) [:6.0.0-SNAPSHOT]
at org.jboss.web.tomcat.service.TomcatInjectionContainer.processMetadata(TomcatInjectionContainer.java:593) [:6.0.0-SNAPSHOT]
at org.jboss.web.tomcat.service.WebCtxLoader.start(WebCtxLoader.java:157) [:6.0.0-SNAPSHOT]
at org.apache.catalina.core.StandardContext.start(StandardContext.java:3737) [:]
at org.jboss.web.tomcat.service.deployers.TomcatDeployment.performDeployInternal(TomcatDeployment.java:309) [:6.0.0-SNAPSHOT]
at org.jboss.web.tomcat.service.deployers.TomcatDeployment.performDeploy(TomcatDeployment.java:144) [:6.0.0-SNAPSHOT]
at org.jboss.web.deployers.AbstractWarDeployment.start(AbstractWarDeployment.java:461) [:6.0.0-SNAPSHOT]
at org.jboss.web.deployers.WebModule.startModule(WebModule.java:116) [:6.0.0-SNAPSHOT]
at org.jboss.web.deployers.WebModule.start(WebModule.java:95) [:6.0.0-SNAPSHOT]
The real issue here is that the WarAnnotationDeployer picks up this SimpleBase class for annotation processing and creates metadata for @Resource and adds it to the WebAppMetaData (resourceEnvRefGroups).
Shouldn't the annotation deployer just pick up servlets (and maybe some additional classes for Servlet 3.0 spec?) for annotation processing? IMO, the SimpleBase class should have been completely skipped from annotation processing in the WarAnnotationDeployer.
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/547701#547701]
Start a new discussion in JBoss Web Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
14 years, 3 months
[Javassist Development] - Problem with CodeIterator.newOffset()
by Alasdair Mackintosh
Alasdair Mackintosh [http://community.jboss.org/people/alasdair] created the discussion
"Problem with CodeIterator.newOffset()"
To view the discussion, visit: http://community.jboss.org/message/547652#547652
--------------------------------------------------------------
I've been having some problems with Javassist which I think I've finally narrowed down to the way that "goto" offsets are updated when you insert new bytecode. It looks as though newOffset is not correctly handling the case when you insert new opcodes at a location which already contains a "goto" opcode.
private static int newOffset(int i, int offset, int where,
int gapLength, boolean exclusive) {
int target = i + offset;
if (i < where) {
if (where < target || (exclusive && where == target))
offset += gapLength;
}
else if (i == where) {
if (target < where && exclusive)
offset -= gapLength;
else if (where < target && !exclusive)
offset += gapLength;
}
else
if (target < where || (!exclusive && where == target))
offset -= gapLength;
return offset;
}
And I think the middle clause should look like this:
else if (i == where) {
if (target < where)
offset -= gapLength;
}
If you insert new bytecode at a location containing a goto (so that the goto opcode is about to be moved forward by n bytes) then you need to modify the offset if it's negative, but keep it the same if it's already positive.
I've made this change and re-run the tests, which all pass, but I wanted to check to see if this fix looks reasonable.
I don't have a simple test case that shows the problem. I found this when I tried to run my testing framework ThreadWeaver ( http://code.google.com/p/thread-weaver/ http://code.google.com/p/thread-weaver/) with the latest version of Javassist. The problem can be demonstrated by building ThreadWeaver and running the unit tests.
If you want a simpler test case let me know. I think THreadWeaver triggered this because it uses Javassist to insert lots of small code snippets into the instrumented bytecode.
Alasdair
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/547652#547652]
Start a new discussion in Javassist Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
14 years, 3 months
[Javassist Development] - Problem in CodeIterator.newOffset()
by Alasdair Mackintosh
Alasdair Mackintosh [http://community.jboss.org/people/alasdair] created the discussion
"Problem in CodeIterator.newOffset()"
To view the discussion, visit: http://community.jboss.org/message/547651#547651
--------------------------------------------------------------
I've been having some problems with Javassist which I think I've finally narrowed down to the way that
"goto" offsets are updated when you insert new bytecode. It looks as though newOffset is not correctly
handling the case when you insert new opcodes at a location which already contains a "goto" opcode.
The code for newOffset() looks like this:
private static int newOffset(int i, int offset, int where,
int gapLength, boolean exclusive) {
int target = i + offset;
if (i < where) {
if (where < target || (exclusive && where == target))
offset += gapLength;
}
else if (i == where) {
if (target < where && exclusive)
offset -= gapLength;
else if (where < target && !exclusive)
offset += gapLength;
}
else
if (target < where || (!exclusive && where == target))
offset -= gapLength;
return offset;
}
And I think the middle clause should look like this:
else if (i == where) {
if (target < where)
offset -= gapLength;
}
If you insert new bytecode at a location containing a goto (so that the goto opcode is about to be moved forward by n bytes) then you need to modify the offset if it's negative, but keep it the same if it's already positive.
I've made this change and re-run the tests, which all pass, but I wanted to check to see if this fix looks reasonable.
I don't have a simple test case that shows the problem. I found this when I tried to run my testing framework ThreadWeaver ( http://code.google.com/p/thread-weaver/ http://code.google.com/p/thread-weaver/) with the latest version of Javassist. The problem can be demonstrated by building ThreadWeaver and running the unit tests.
If yuo want a simpler test case let me know. I think THreadWeaver triggered this because it uses Javassist to insert lots of small code snippets into the instrumented bytecode.
Alasdair
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/547651#547651]
Start a new discussion in Javassist Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
14 years, 3 months