November 2007 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JBAOP-380) JBoss AOP sets info field to null before rebuilding a chain

by Flavia Rainone (JIRA)

JBoss AOP sets info field to null before rebuilding a chain ----------------------------------------------------------- Key: JBAOP-380 URL: http://jira.jboss.com/jira/browse/JBAOP-380 Project: JBoss AOP Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 2.0.0.alpha4, 1.5.5.GA Reporter: Flavia Rainone Fix For: 1.5.6.GA, 2.0.0.alpha5 Advisor sets the joinpoint info field as null before rebuilding the interceptor chain. So, for a short period of time, that joinpoint will not be intercepted. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

18 years, 7 months

3
16
0 / 0

[JBoss JIRA] Created: (JBRULES-1308) getFactHandle with equality-based assert behavior

by Adam Lewandowski (JIRA)

getFactHandle with equality-based assert behavior ------------------------------------------------- Key: JBRULES-1308 URL: http://jira.jboss.com/jira/browse/JBRULES-1308 Project: JBoss Drools Issue Type: Feature Request Security Level: Public (Everyone can see) Affects Versions: 4.0.3 Reporter: Adam Lewandowski If I set my rule base to use equality-based assert behavior, I'm expecting to be able to use the getFactHandle(object) method to retrieve a previously asserted fact by providing an equivalent (by equals() and hashCode()) object as an argument. This appears to not be the case, as AbstractWorkingMemory uses it's identityMap and associated IdentityAssertMapComparator to do the getFactHandle lookup instead of the assertMap and EqualityAssertMapComparator. This causes the lookup to be done with the system hashCode() method and not the overridden version supplied in my fact class. The lookup thus fails and returns null. See attached unit test. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

18 years, 7 months

2
3
0 / 0

[JBoss JIRA] Created: (JBAS-4682) Web session passivation does very little with FIELD granularity

by Brian Stansberry (JIRA)

Web session passivation does very little with FIELD granularity --------------------------------------------------------------- Key: JBAS-4682 URL: http://jira.jboss.com/jira/browse/JBAS-4682 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Components: Clustering, Web (Tomcat) service Affects Versions: JBossAS-5.0.0.Beta2 Reporter: Brian Stansberry Assigned To: Brian Stansberry Passivation of clustered HttpSessions works by evicting the node tree representing a given session from the cache. Configuration is based on defining how many active (in-memory) sesssion are allowed and how old they can be before passivating them. Problem is, with FIELD replication, the bulk of the data associated with a session is not in that sessions's subtree; it's in the _JBossInternal_ area. Evicting the session's tree doesn't free up the memory associated with the POJOs. Structure of data in JBC: /JSESSION +++ /localhost ++++++/webapp +++++++++/session12345 +++++++++/session67890 +++++++++/_JBossInternal_ ++++++++++++/pojoAAAAA ++++++++++++/pojoBBBBB (Note: session passivation is not done using the regular JBC eviction algorithms, as JBC doesn't understand what a "session" is. The http session replication layer manages the passivation, just using the JBC evict() method to do the actual passivation.) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

18 years, 7 months

1
1
0 / 0

[JBoss JIRA] Created: (JBCLUSTER-137) Move the load balance policies from the AS cluster module

by Brian Stansberry (JIRA)

Move the load balance policies from the AS cluster module --------------------------------------------------------- Key: JBCLUSTER-137 URL: http://jira.jboss.com/jira/browse/JBCLUSTER-137 Project: JBoss Clustering Issue Type: Sub-task Security Level: Public (Everyone can see) Reporter: Brian Stansberry Assigned To: Brian Stansberry Need to decide with Tom Elrod whether these belong in clustering or remoting. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

18 years, 7 months

2
2
0 / 0

[JBoss JIRA] Created: (JBAS-4470) Move the load balance policies from the AS cluster module

by Brian Stansberry (JIRA)

Move the load balance policies from the AS cluster module --------------------------------------------------------- Key: JBAS-4470 URL: http://jira.jboss.com/jira/browse/JBAS-4470 Project: JBoss Application Server Issue Type: Sub-task Security Level: Public (Everyone can see) Components: Clustering Reporter: Brian Stansberry Assigned To: Brian Stansberry Fix For: JBossAS-5.0.0.CR1 JBAS corollary to JBCLUSTER-137 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

18 years, 7 months

1
1
0 / 0

[JBoss JIRA] Created: (JBCLUSTER-138) Move or replace ClusteringTargetsRepository and FamilyClusterInfo

by Brian Stansberry (JIRA)

Move or replace ClusteringTargetsRepository and FamilyClusterInfo ----------------------------------------------------------------- Key: JBCLUSTER-138 URL: http://jira.jboss.com/jira/browse/JBCLUSTER-138 Project: JBoss Clustering Issue Type: Sub-task Security Level: Public (Everyone can see) Reporter: Brian Stansberry Assigned To: Brian Stansberry Fix For: Q3Y6 Work with Tom Elrod to determine what's going to generically provide the functionality that ClusteringTargetsRepository and FCI do. When we do this we have to keep in mind the old detached invokers (unless we decide to get rid of them.) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

18 years, 7 months

2
3
0 / 0

[JBoss JIRA] Created: (JBAS-4471) Move or replace ClusteringTargetsRepository and FamilyClusterInfo

by Brian Stansberry (JIRA)

Move or replace ClusteringTargetsRepository and FamilyClusterInfo ----------------------------------------------------------------- Key: JBAS-4471 URL: http://jira.jboss.com/jira/browse/JBAS-4471 Project: JBoss Application Server Issue Type: Sub-task Security Level: Public (Everyone can see) Components: Clustering Reporter: Brian Stansberry Assigned To: Brian Stansberry Fix For: JBossAS-5.0.0.CR1 JBAS corollary to JBCLUSTER-138 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

18 years, 7 months

1
1
0 / 0

[JBoss JIRA] Created: (JBAS-4322) Wrong context path in Embedded JBoss JAR deployment

by Christian Bauer (JIRA)

Wrong context path in Embedded JBoss JAR deployment --------------------------------------------------- Key: JBAS-4322 URL: http://jira.jboss.com/jira/browse/JBAS-4322 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Components: Deployment services Reporter: Christian Bauer Assigned To: Dimitris Andreadis Embedded JBoss build from SVN trunk yesterday: 07:47:14,079 DEBUG [MainDeployerImpl] Add deployment context: vfsjar:file:/Users/turin/work/seamng/app/lib/seamng-config.jar!/deployers/deployers/aspect-deployer-beans.xml 07:47:14,082 ERROR [MainDeployerImpl] Unable to determine structure of deployment: vfsjar:file:/Users/turin/work/seamng/app/lib/seamng-config.jar!/deployers/deployers/aspect-deployer-beans.xml org.jboss.deployers.spi.DeploymentException: Failed to process context: vfsjar:file:/Users/turin/work/seamng/app/lib/seamng-config.jar!/deployers/deployers/aspect-deployer-beans.xml at org.jboss.deployers.plugins.structure.DefaultStructureBuilder.populateContext(DefaultStructureBuilder.java:94) at org.jboss.deployers.plugins.deployment.MainDeployerImpl.determineStructure(MainDeployerImpl.java:684) at org.jboss.deployers.plugins.deployment.MainDeployerImpl.addDeploymentContext(MainDeployerImpl.java:352) at org.jboss.embedded.DeploymentGroup.add(DeploymentGroup.java:164) at org.jboss.embedded.DeploymentGroup.addVirtualFiles(DeploymentGroup.java:205) at org.jboss.embedded.DeploymentGroup.addDirectoryByResource(DeploymentGroup.java:471) at org.jboss.embedded.DeploymentScanner.start(DeploymentScanner.java:99) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.jboss.reflect.plugins.introspection.ReflectionUtils.invoke(ReflectionUtils.java:55) at org.jboss.reflect.plugins.introspection.ReflectMethodInfoImpl.invoke(ReflectMethodInfoImpl.java:108) at org.jboss.joinpoint.plugins.BasicMethodJoinPoint.dispatch(BasicMethodJoinPoint.java:66) at org.jboss.kernel.plugins.dependency.KernelControllerContextAction.dispatchJoinPoint(KernelControllerContextAction.java:103) at org.jboss.kernel.plugins.dependency.LifecycleAction.installActionInternal(LifecycleAction.java:145) at org.jboss.kernel.plugins.dependency.KernelControllerContextAction.installAction(KernelControllerContextAction.java:197) at org.jboss.kernel.plugins.dependency.KernelControllerContextAction.install(KernelControllerContextAction.java:136) at org.jboss.dependency.plugins.AbstractControllerContextActions.install(AbstractControllerContextActions.java:51) at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:233) at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:724) at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:445) at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:555) at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:489) at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:289) at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:192) at org.jboss.kernel.plugins.deployment.AbstractKernelDeployer.deployBean(AbstractKernelDeployer.java:302) at org.jboss.kernel.plugins.deployment.AbstractKernelDeployer.deployBeans(AbstractKernelDeployer.java:272) at org.jboss.kernel.plugins.deployment.AbstractKernelDeployer.deploy(AbstractKernelDeployer.java:119) at org.jboss.kernel.plugins.deployment.xml.BeanXMLDeployer.deploy(BeanXMLDeployer.java:96) at org.jboss.embedded.Bootstrap.deployBaseBootstrapUrl(Bootstrap.java:150) at org.jboss.embedded.Bootstrap.bootstrapURL(Bootstrap.java:162) at org.jboss.embedded.Bootstrap.bootstrap(Bootstrap.java:201) at org.jboss.embedded.Bootstrap.bootstrap(Bootstrap.java:214) at my.app.HelloWorld.main(HelloWorld.java:37) Caused by: java.io.FileNotFoundException: JarEntryHandler@10196585[path= context=jar:file:/Users/turin/work/seamng/app/lib/seamng-config.jar!/deployers/ real=jar:jar:file:/Users/turin/work/seamng/app/lib/seamng-config.jar!/deployers/!/deployers/] has no child: deployers at org.jboss.virtual.plugins.context.jar.JarEntryHandler.createChildHandler(JarEntryHandler.java:197) at org.jboss.virtual.plugins.context.AbstractVirtualFileHandler.structuredFindChild(AbstractVirtualFileHandler.java:280) at org.jboss.virtual.plugins.context.jar.JarEntryHandler.findChild(JarEntryHandler.java:171) at org.jboss.virtual.plugins.context.AbstractVFSContext.findChild(AbstractVFSContext.java:118) at org.jboss.virtual.VFS.findChild(VFS.java:205) at org.jboss.deployers.plugins.structure.DefaultStructureBuilder.populateContext(DefaultStructureBuilder.java:74) ... 34 more This is the JAR on my classpath: 0 Thu Apr 12 07:38:50 CEST 2007 conf/ 9374 Wed Apr 11 16:49:12 CEST 2007 conf/bootstrap-beans.xml 4437 Thu Apr 12 07:40:24 CEST 2007 conf/jboss-service.xml 11295 Wed Apr 11 16:49:12 CEST 2007 conf/jbossjta-properties.xml 0 Thu Apr 12 08:19:44 CEST 2007 deploy/ 22444 Wed Apr 11 16:49:12 CEST 2007 deploy/ejb3-interceptors-aop.xml 2402 Wed Apr 11 16:49:12 CEST 2007 deploy/jboss-local-jdbc.rar 2517 Wed Apr 11 16:49:12 CEST 2007 deploy/jboss-xa-jdbc.rar 0 Wed Apr 11 16:49:12 CEST 2007 deployers/ 504 Wed Apr 11 16:49:12 CEST 2007 deployers/aspect-deployer-beans.xml 5190 Wed Apr 11 16:49:12 CEST 2007 deployers/ejb3-deployers-beans.xml 1900 Wed Apr 11 16:49:12 CEST 2007 deployers/jca-deployers-beans.xml 194 Wed Apr 11 16:49:12 CEST 2007 jndi.properties If I have the same structure exploded on my classpath, it works. The JAR scanner adds a duplicate subdirectory name to the context path. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

18 years, 7 months

3
3
0 / 0

[JBoss JIRA] Created: (JBAOP-480) NPE in concurrent join point generation

by Jason T. Greene (JIRA)

NPE in concurrent join point generation --------------------------------------- Key: JBAOP-480 URL: http://jira.jboss.com/jira/browse/JBAOP-480 Project: JBoss AOP Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 2.0.0.beta1 Reporter: Jason T. Greene Fix For: 2.0.0.beta2 Recently I have noticed intermittent failures in join point generation. It appears to happen when there are concurrent inocations on an advised method. Caused by: java.lang.RuntimeException: Error generating joinpoint class for joinpoint Method[method=public java.lang.Object org.jboss.cache.pojo.impl.PojoCacheImpl.detach(org.jboss.cache.Fqn,java.lang.String) throws org.jboss.cache.pojo.PojoCacheException] at org.jboss.aop.instrument.JoinPointGenerator.doGenerateJoinPointClass(JoinPointGenerator.java:304) at org.jboss.aop.instrument.JoinPointGenerator.access$100(JoinPointGenerator.java:75) at org.jboss.aop.instrument.JoinPointGenerator$GenerateJoinPointClassAction$2.generateJoinPointClass(JoinPointGenerator.java:1627) at org.jboss.aop.instrument.JoinPointGenerator.generateJoinPointClass(JoinPointGenerator.java:240) at org.jboss.aop.GeneratedClassAdvisor.generateJoinPointClass(GeneratedClassAdvisor.java:1020) at org.jboss.cache.pojo.impl.PojoCacheImpl$PojoCacheImplAdvisor.detach_N_6302035201148273652(PojoCacheImpl$PojoCacheImplAdvisor.java) at org.jboss.cache.pojo.impl.PojoCacheImpl$PojoCacheImplInstanceAdvisor.detach_N_6302035201148273652(PojoCacheImpl$PojoCacheImplInstanceAdvisor.java) at org.jboss.cache.pojo.impl.PojoCacheImpl.detach(PojoCacheImpl.java) at org.jboss.cache.pojo.impl.PojoCacheDelegate.putObjectII(PojoCacheDelegate.java:143) at org.jboss.cache.pojo.impl.PojoCacheImpl.putObject(PojoCacheImpl.java:135) at org.jboss.cache.pojo.impl.PojoCacheImpl.org$jboss$cache$pojo$impl$PojoCacheImpl$attach$aop(PojoCacheImpl.java:100) at org.jboss.cache.pojo.impl.PojoCacheImpl$JoinPoint_attach3085019539260813833.dispatch(PojoCacheImpl$JoinPoint_attach3085019539260813833.java) at org.jboss.cache.pojo.impl.JoinPoint_attach3085019539260813833_1.invokeNext(JoinPoint_attach3085019539260813833_1.java) at org.jboss.cache.pojo.interceptors.PojoTxUndoSynchronizationInterceptor.invoke(PojoTxUndoSynchronizationInterceptor.java:42) at org.jboss.cache.pojo.impl.JoinPoint_attach3085019539260813833_1.invokeNext(JoinPoint_attach3085019539260813833_1.java) at org.jboss.cache.pojo.interceptors.PojoTxLockInterceptor.invoke(PojoTxLockInterceptor.java:38) at org.jboss.cache.pojo.impl.JoinPoint_attach3085019539260813833_1.invokeNext(JoinPoint_attach3085019539260813833_1.java) at org.jboss.cache.pojo.interceptors.PojoFailedTxMockupInterceptor.invoke(PojoFailedTxMockupInterceptor.java:46) at org.jboss.cache.pojo.impl.JoinPoint_attach3085019539260813833_1.invokeNext(JoinPoint_attach3085019539260813833_1.java) at org.jboss.cache.pojo.interceptors.PojoTxInterceptor.invoke(PojoTxInterceptor.java:77) ... 14 more Caused by: java.lang.NullPointerException at org.jboss.aop.JoinPointInfo.getAdviceString(JoinPointInfo.java:184) at org.jboss.aop.instrument.JoinPointGenerator.doGenerateJoinPointClass(JoinPointGenerator.java:263) ... 33 more -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

18 years, 7 months

3
10
0 / 0

[JBoss JIRA] Created: (JBAOP-487) Make JoinPointInfos unique per joinpoint

by Flavia Rainone (JIRA)

Make JoinPointInfos unique per joinpoint ---------------------------------------- Key: JBAOP-487 URL: http://jira.jboss.com/jira/browse/JBAOP-487 Project: JBoss AOP Issue Type: Sub-task Security Level: Public (Everyone can see) Affects Versions: 2.0.0.beta2 Reporter: Flavia Rainone Assigned To: Flavia Rainone Fix For: 2.0.0.CR1 Every time the interceptor chains are rebuilt in the advisor, a new joinpointinfo object is created. This task consists in changing this scenario, by creating a joinpoint info object only once for each joinpoint. The main reason for this is to facilitate the synchronization of interceptor chain operations. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

18 years, 7 months

2
2
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira November 2007