June 2010 - jboss-dev-forums - Jboss List Archives

Re: [jboss-dev-forums] [jBPM Development] - JBPM-2694 and JBPM-2798

by Maciej Swiderski

Maciej Swiderski [http://community.jboss.org/people/swiderski.maciej] replied to the discussion "JBPM-2694 and JBPM-2798" To view the discussion, visit: http://community.jboss.org/message/547724#547724 -------------------------------------------------------------- Hi HuiSheng, great job, this is what I was talking about. Solution and implementation is perfect in my opinion. If no one has any objections I would suggest to have it incorporated with 4.4 release. Cheers, Maciej -------------------------------------------------------------- Reply to this message by going to Community [http://community.jboss.org/message/547724#547724] Start a new discussion in jBPM Development at Community [http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]

16 years, 1 month

1
0
0 / 0

Re: [jboss-dev-forums] [jBPM Development] - JBPM-2820 and JBPM-2702

by Maciej Swiderski

Maciej Swiderski [http://community.jboss.org/people/swiderski.maciej] replied to the discussion "JBPM-2820 and JBPM-2702" To view the discussion, visit: http://community.jboss.org/message/547723#547723 -------------------------------------------------------------- Looks good to me. -------------------------------------------------------------- Reply to this message by going to Community [http://community.jboss.org/message/547723#547723] Start a new discussion in jBPM Development at Community [http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]

16 years, 1 month

1
0
0 / 0

Re: [jboss-dev-forums] [jBPM Development] - Trunk build failure

by Maciej Swiderski

Maciej Swiderski [http://community.jboss.org/people/swiderski.maciej] replied to the discussion "Trunk build failure" To view the discussion, visit: http://community.jboss.org/message/547722#547722 -------------------------------------------------------------- No worries, just wanted to notify others. Thanks for quick response. -------------------------------------------------------------- Reply to this message by going to Community [http://community.jboss.org/message/547722#547722] Start a new discussion in jBPM Development at Community [http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]

16 years, 1 month

1
0
0 / 0

Re: [jboss-dev-forums] [JBoss Web Development] - Annotation processing in war files too aggressive?

by jaikiran pai

jaikiran pai [http://community.jboss.org/people/jaikiran] replied to the discussion "Annotation processing in war files too aggressive?" To view the discussion, visit: http://community.jboss.org/message/547702#547702 -------------------------------------------------------------- This affects some of the TCK6 tests too. -------------------------------------------------------------- Reply to this message by going to Community [http://community.jboss.org/message/547702#547702] Start a new discussion in JBoss Web Development at Community [http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]

16 years, 1 month

1
0
0 / 0

[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...]

16 years, 1 month

1
0
0 / 0

Re: [jboss-dev-forums] [jBPM Development] - Trunk build failure

by Alejandro Guizar

Alejandro Guizar [http://community.jboss.org/people/alex.guizar%40jboss.com] replied to the discussion "Trunk build failure" To view the discussion, visit: http://community.jboss.org/message/547679#547679 -------------------------------------------------------------- Yeah I mistakenly left those MySQL statements behind when I diagnosed problems specific to that database. I've removed them already. Excuse the mess. -------------------------------------------------------------- Reply to this message by going to Community [http://community.jboss.org/message/547679#547679] Start a new discussion in jBPM Development at Community [http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]

16 years, 1 month

1
0
0 / 0

Re: [jboss-dev-forums] [jBPM Development] - JBPM-2694 and JBPM-2798

by HuiSheng Xu

HuiSheng Xu [http://community.jboss.org/people/rebody] replied to the discussion "JBPM-2694 and JBPM-2798" To view the discussion, visit: http://community.jboss.org/message/547672#547672 -------------------------------------------------------------- Hi Maciej, I attached a new patch, and allow user set property or auto detect these properties from hibernate configuration. https://jira.jboss.org/browse/JBPM-2694 https://jira.jboss.org/browse/JBPM-2694 https://jira.jboss.org/secure/attachment/12334685/JBPM-2694-2010-05-30.patch JBPM-2694-2010-05-30.patch -------------------------------------------------------------- Reply to this message by going to Community [http://community.jboss.org/message/547672#547672] Start a new discussion in jBPM Development at Community [http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]

16 years, 1 month

1
0
0 / 0

Re: [jboss-dev-forums] [jBPM Development] - JBPM-2820 and JBPM-2702

by HuiSheng Xu

HuiSheng Xu [http://community.jboss.org/people/rebody] replied to the discussion "JBPM-2820 and JBPM-2702" To view the discussion, visit: http://community.jboss.org/message/547670#547670 -------------------------------------------------------------- Hi Maciej, I attached a new patch to prevent executing composeIds() twice in createExecution(). All of testcase could pass. If you have time, please have a look at it. The key is we have to generate dbid, parent id, then we could save the execution. And the code for generating dbid is only exists in the save() method. setParent() mehod is only exists in the addExecution() method. So this time, I execution setParent() by hand before save(). I think this could be solve this problem. -------------------------------------------------------------- Reply to this message by going to Community [http://community.jboss.org/message/547670#547670] Start a new discussion in jBPM Development at Community [http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]

16 years, 1 month

1
0
0 / 0

[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...]

16 years, 1 month

1
0
0 / 0

[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...]

16 years, 1 month

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-dev-forums June 2010