August 2012 - jboss-jira - Jboss List Archives

[JBoss JIRA] (AS7-5260) Synthetic method passed in InvocationContext

by Thomas Woelfle (JIRA)

Thomas Woelfle created AS7-5260: ----------------------------------- Summary: Synthetic method passed in InvocationContext Key: AS7-5260 URL: https://issues.jboss.org/browse/AS7-5260 Project: Application Server 7 Issue Type: Bug Affects Versions: 7.2.0.Alpha1 Reporter: Thomas Woelfle We have a JEE interceptor that validates method calls using the MethodValidator from the hibernate-validator package. We are running into problems when generic methods on stateless session beans are called that have been overwritten in a subclass. The problem is that the InvocationContext passed into our interceptor references the synthetic bridge method generated by the compiler instead of the correct overwritten method. Synthetic methods are ignored by hibernate-validator (see BeanMetaDataImpl.initMethodConstraints). This results in a NullPointerException when hibernate-validator tries to validate the given synthetic bridge method. Code example: public interface CrudService<D extends PersistentElement> { D elementById(long id); } @Local public interface AccountService extends CrudService<Account> { ... some additional methods } public class AbstractCrudServiceImpl<D extends PersistentElement> implements CrudService<D> { public D elementById(long id) { ... do something } } @Stateless public class AccountServiceImpl extends AbstractCrudServiceImpl<Account> implements AccountService { @Override public Account elementById(long id) { ... a specialized implementation } } public class SomeOtherSessionBean { @Inject private AccountService accountService; public void doSomething() { accountService.elementById(1); } } In the example code above 'SomeOtherSessionBean.doSomething()' calls the method 'elementById'. In that case the InvocationContext passed into our interceptor references the synthetic bridge method with the signature 'PersistentElement AccountServiceImpl.elementById(long)' instead of the concrete method 'Account AccountServiceImpl.elementById(long)'. This seems to be a bug, isn't it? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 10 months

4
6
0 / 0

[JBoss JIRA] (AS7-4602) Remaining Weld references after WAR undeployement

by Stuart Douglas (JIRA)

[ https://issues.jboss.org/browse/AS7-4602?page=com.atlassian.jira.plugin.s... ] Stuart Douglas resolved AS7-4602. --------------------------------- Resolution: Out of Date This JSF issue has since been fixed > Remaining Weld references after WAR undeployement > ------------------------------------------------- > > Key: AS7-4602 > URL: https://issues.jboss.org/browse/AS7-4602 > Project: Application Server 7 > Issue Type: Bug > Components: CDI / Weld > Environment: JBoss AS 7.1.1.Final, JProfiler > Reporter: Tomas Remes > Assignee: Stuart Douglas > Attachments: weld-deployment-test.jps > > > I am not sure that this can be considered as issue, but when you run JBoss AS in JProfiler and try to deploy and undeploy simple Weld Web application (for example numberguess), you can find some referenced Weld classes in JProfiler even after performing GC. For example WeldBootstrap class, which has incoming references in following order: > {noformat} > ... -> org.jboss.msc.service.ServiceControllerImpl -> org.jboss.msc.value.ImmediateValue -> org.jboss.as.weld.service.WeldService -> org.jboss.as.weld.WeldContainer -> org.jboss.weld.bootstrap.WeldBootstrap > {noformat} > JProfiler snapshot is in attachement. In JProfiler you can filter org.jboss.weld.bootstrap classes and by right clicking you can show selection in Heap Walker, where you can also find references graph or tree. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 10 months

1
0
0 / 0

[JBoss JIRA] (AS7-5316) Weld 1.1.9.Final

by Stuart Douglas (JIRA)

Stuart Douglas created AS7-5316: ----------------------------------- Summary: Weld 1.1.9.Final Key: AS7-5316 URL: https://issues.jboss.org/browse/AS7-5316 Project: Application Server 7 Issue Type: Component Upgrade Components: CDI / Weld Reporter: Stuart Douglas Assignee: Stuart Douglas Fix For: 7.1.3.Final (EAP), 7.2.0.Alpha1 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 10 months

1
1
0 / 0

[JBoss JIRA] (AS7-5212) JRE-provided services are not available to deployments

by James Livingston (JIRA)

James Livingston created AS7-5212: ------------------------------------- Summary: JRE-provided services are not available to deployments Key: AS7-5212 URL: https://issues.jboss.org/browse/AS7-5212 Project: Application Server 7 Issue Type: Bug Components: Class Loading Affects Versions: 7.1.2.Final (EAP) Reporter: James Livingston Assignee: David Lloyd JBoss Modules does not currently support exporting META-INF/services from a system dependency as it does for module dependencies. As a result, any services provided by the JRE cannot be seen from other modules. This results in deployments not being able to use javax.print.PrintServiceLookup and other API, since they will not find any implementations. The modules/sun/jdk/main/service-loader-resources/ exists purely to work around this problem. It is not the best solution since the contents are JRE-specific. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 10 months

4
6
0 / 0

[JBoss JIRA] (AS7-5265) Create EJB Timer quickstart - @Timeout and @Schedule.

by Ondrej Zizka (JIRA)

Ondrej Zizka created AS7-5265: --------------------------------- Summary: Create EJB Timer quickstart - @Timeout and @Schedule. Key: AS7-5265 URL: https://issues.jboss.org/browse/AS7-5265 Project: Application Server 7 Issue Type: Feature Request Reporter: Ondrej Zizka Assignee: Ondrej Zizka Priority: Minor -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 10 months

1
2
0 / 0

[JBoss JIRA] (JBCLUSTER-33) Farm deploy of large EAR doesn't replicate to other cluster node

by Scott Marlow (JIRA)

[ https://issues.jboss.org/browse/JBCLUSTER-33?page=com.atlassian.jira.plug... ] Scott Marlow reassigned JBCLUSTER-33: ------------------------------------- Assignee: Scott Marlow (was: Scott Marlow (Novell)) > Farm deploy of large EAR doesn't replicate to other cluster node > ---------------------------------------------------------------- > > Key: JBCLUSTER-33 > URL: https://issues.jboss.org/browse/JBCLUSTER-33 > Project: JBoss Clustering > Issue Type: Bug > Security Level: Public(Everyone can see) > Environment: JBoss AS 4.01SP1 + 4.0.1, Suse Linux > Reporter: Scott Marlow (Novell) > Assignee: Scott Marlow > Priority: Minor > Fix For: Q2Y5 > > Attachments: FarmMemberService.zip > > Time Spent: 4 hours > Remaining Estimate: 0 minutes > > I setup a two node JBoss cluster (either same machine or two different machines) and copy a large ear (22,725,139 byte file) into the farm deploy folder. The file doesn't replicate to the other server instance farm folder. I have seen an outOfMemory exception occur but increasing Java memory makes that go away, however, the EAR still doesn't replicate to the other node. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JBCLUSTER-33) Farm deploy of large EAR doesn't replicate to other cluster node

by Scott Marlow (JIRA)

[ https://issues.jboss.org/browse/JBCLUSTER-33?page=com.atlassian.jira.plug... ] Scott Marlow closed JBCLUSTER-33. --------------------------------- > Farm deploy of large EAR doesn't replicate to other cluster node > ---------------------------------------------------------------- > > Key: JBCLUSTER-33 > URL: https://issues.jboss.org/browse/JBCLUSTER-33 > Project: JBoss Clustering > Issue Type: Bug > Security Level: Public(Everyone can see) > Environment: JBoss AS 4.01SP1 + 4.0.1, Suse Linux > Reporter: Scott Marlow (Novell) > Assignee: Scott Marlow > Priority: Minor > Fix For: Q2Y5 > > Attachments: FarmMemberService.zip > > Time Spent: 4 hours > Remaining Estimate: 0 minutes > > I setup a two node JBoss cluster (either same machine or two different machines) and copy a large ear (22,725,139 byte file) into the farm deploy folder. The file doesn't replicate to the other server instance farm folder. I have seen an outOfMemory exception occur but increasing Java memory makes that go away, however, the EAR still doesn't replicate to the other node. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JBCLUSTER-42) First deploy after joining a cluster is not farmed

by Scott Marlow (JIRA)

[ https://issues.jboss.org/browse/JBCLUSTER-42?page=com.atlassian.jira.plug... ] Scott Marlow reassigned JBCLUSTER-42: ------------------------------------- Assignee: Scott Marlow (was: Scott Marlow (Novell)) > First deploy after joining a cluster is not farmed > -------------------------------------------------- > > Key: JBCLUSTER-42 > URL: https://issues.jboss.org/browse/JBCLUSTER-42 > Project: JBoss Clustering > Issue Type: Bug > Security Level: Public(Everyone can see) > Affects Versions: Q2Y5 > Environment: Jboss 4.0.2 final, Java 1.5.0_02 > Reporter: Gabriele Garuglieri > Assignee: Scott Marlow > Fix For: Q2Y5 > > Time Spent: 3 hours > Remaining Estimate: 0 minutes > > There a problem in org.jboss.ha.framework.server.FarmMemberService that shows during service startup. > It happens with the following scenario. > 1- server starts up and joins the cluster, /farm applications are pulled from remote node. > 2- farmDeploy() is called for the applications, remotelyDeployed gets filled with their names > 3- scanner thread is started and begins calling deploy() for each application > 4- by chance, deploy() executes while service status is still STARTING so it call super.deploy() and applications are deployed but their names are not removed from remotelyDeployed > 5- you remove application from /farm and farmUndeploy() is invoked. > 6- you put again application in /farm, deploy() is called, super.deploy() is called, BUT remotelyDeployed is still dirty from the preceding deploy so farmDeploy() is not invoked and the application won't get farmed > Then everything cleans up and for subsequent deploy/undeploy works correctly. > I tested the solution proposed by Scott Marlow Novell to move the clearing of "remotelyDeployed" flag before the "getState() == STARTING" test and it looks to be working. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JBCLUSTER-42) First deploy after joining a cluster is not farmed

by Scott Marlow (JIRA)

[ https://issues.jboss.org/browse/JBCLUSTER-42?page=com.atlassian.jira.plug... ] Scott Marlow closed JBCLUSTER-42. --------------------------------- > First deploy after joining a cluster is not farmed > -------------------------------------------------- > > Key: JBCLUSTER-42 > URL: https://issues.jboss.org/browse/JBCLUSTER-42 > Project: JBoss Clustering > Issue Type: Bug > Security Level: Public(Everyone can see) > Affects Versions: Q2Y5 > Environment: Jboss 4.0.2 final, Java 1.5.0_02 > Reporter: Gabriele Garuglieri > Assignee: Scott Marlow > Fix For: Q2Y5 > > Time Spent: 3 hours > Remaining Estimate: 0 minutes > > There a problem in org.jboss.ha.framework.server.FarmMemberService that shows during service startup. > It happens with the following scenario. > 1- server starts up and joins the cluster, /farm applications are pulled from remote node. > 2- farmDeploy() is called for the applications, remotelyDeployed gets filled with their names > 3- scanner thread is started and begins calling deploy() for each application > 4- by chance, deploy() executes while service status is still STARTING so it call super.deploy() and applications are deployed but their names are not removed from remotelyDeployed > 5- you remove application from /farm and farmUndeploy() is invoked. > 6- you put again application in /farm, deploy() is called, super.deploy() is called, BUT remotelyDeployed is still dirty from the preceding deploy so farmDeploy() is not invoked and the application won't get farmed > Then everything cleans up and for subsequent deploy/undeploy works correctly. > I tested the solution proposed by Scott Marlow Novell to move the clearing of "remotelyDeployed" flag before the "getState() == STARTING" test and it looks to be working. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JBCLUSTER-68) enhance farm deployment to handle cluster partitioning and merging

by Scott Marlow (JIRA)

[ https://issues.jboss.org/browse/JBCLUSTER-68?page=com.atlassian.jira.plug... ] Scott Marlow reassigned JBCLUSTER-68: ------------------------------------- Assignee: Scott Marlow (was: Scott Marlow (Novell)) > enhance farm deployment to handle cluster partitioning and merging > ------------------------------------------------------------------ > > Key: JBCLUSTER-68 > URL: https://issues.jboss.org/browse/JBCLUSTER-68 > Project: JBoss Clustering > Issue Type: Task > Security Level: Public(Everyone can see) > Reporter: Scott Marlow (Novell) > Assignee: Scott Marlow > Priority: Optional > > Handle partitions and merges. Here's a use case: > * Group is {A,B,C,D,E} > * Partition occurs > * Groups are now {A,B,C} and {D,E} > * User drops WAR into E > * D and E will have WAR > * Partition heals, merge occurs > o Group is now {A,B,C,D,E} > * A,B,C don't have the WAR, D and E have it > We could possibly use the same algorithm we use to reconcile this when D > and E were offline and a user dropped the WAR into E's ./farm dir. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 10 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira August 2012