July 2011 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (AS7-1243) Picketbox is added to the deployment with export=true

by Stuart Douglas (JIRA)

Picketbox is added to the deployment with export=true ----------------------------------------------------- Key: AS7-1243 URL: https://issues.jboss.org/browse/AS7-1243 Project: Application Server 7 Issue Type: Bug Components: Security Affects Versions: 7.0.0.CR1 Reporter: Stuart Douglas Assignee: Stuart Douglas -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 10 months

1
1
0 / 0

[JBoss JIRA] Created: (AS7-1226) Doubled word in exception message

by Martin Vecera (JIRA)

Doubled word in exception message --------------------------------- Key: AS7-1226 URL: https://issues.jboss.org/browse/AS7-1226 Project: Application Server 7 Issue Type: Bug Components: Server Affects Versions: 7.0.0.CR1 Reporter: Martin Vecera Priority: Minor I had broken EAR deployment and I received the following error which is expected. IMHO there should be only one "class" word in the error message. Caused by: java.lang.RuntimeException: Error getting reflective information for class >>class<< org.jboss.test.TaskHelper at org.jboss.as.server.deployment.reflect.DeploymentReflectionIndex.getClassIndex(DeploymentReflectionIndex.java:70) at org.jboss.as.ejb3.deployment.processors.dd.EjbConcurrencyProcessor.checkMethodOverrides(EjbConcurrencyProcessor.java:109) at org.jboss.as.ejb3.deployment.processors.dd.EjbConcurrencyProcessor.deploy(EjbConcurrencyProcessor.java:86) at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:115) ... 5 more -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 10 months

2
1
0 / 0

[JBoss JIRA] Created: (JBRULES-3036) org.antlr.runtime.CommonToken cannot be cast to org.drools.lang.DroolsToken

by Anibal Marques (JIRA)

org.antlr.runtime.CommonToken cannot be cast to org.drools.lang.DroolsToken --------------------------------------------------------------------------- Key: JBRULES-3036 URL: https://issues.jboss.org/browse/JBRULES-3036 Project: Drools Issue Type: Bug Security Level: Public (Everyone can see) Reporter: Anibal Marques Assignee: Mark Proctor -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 10 months

3
7
0 / 0

[JBoss JIRA] Created: (EJBTHREE-2243) Transaction problems, possible bug in ApplicationExceptionComponentMetaDataLoaderFactory

by Benoit Heinrich (JIRA)

Transaction problems, possible bug in ApplicationExceptionComponentMetaDataLoaderFactory ---------------------------------------------------------------------------------------- Key: EJBTHREE-2243 URL: https://issues.jboss.org/browse/EJBTHREE-2243 Project: EJB 3.0 Issue Type: Bug Components: transactions Affects Versions: EJB3_1 1.0.3 Environment: JBoss AS 6.0.0.Final Reporter: Benoit Heinrich I think I've found a possible bug with transaction attributes management in jboss 6.0.0 Final. The problem appears when using the @TransactionAttribute annotation on an EJB bean with the @Interceptors. When using that it seems that the @TransactionAttribute annotation is ignored. By removing the @Interceptors annotation it works and the right transaction attribute is used. More details available in the jboss forum link. Cheers, /Benoit -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 10 months

2
10
0 / 0

[JBoss JIRA] Created: (JBAS-9397) Memory leak in EJB3.1 no interface view for stateful beans

by Jürgen Koras (JIRA)

Memory leak in EJB3.1 no interface view for stateful beans ---------------------------------------------------------- Key: JBAS-9397 URL: https://issues.jboss.org/browse/JBAS-9397 Project: Legacy JBoss Application Server 6 Issue Type: Bug Security Level: Public (Everyone can see) Components: EJB Affects Versions: 6.0.0.Final Environment: All platforms Reporter: Jürgen Koras Assignee: Carlo de Wolf Priority: Critical Using a stateful no-interface bean causes a memory leak in PermGen space. This can easily be reproduced by creating and removing such a bean. On my machine it fails after 22500 instances. The problem is that for each instance of a bean a new Proxy-class is generated. This is done using javassist framework in the class org.jboss.ejb3.proxy.javassist.JavassistProxyFactory in method createProxy(Class[], InvocationHandler). Here the depreciated javassist method (instance).setHandler(...) is used. Due to documentation (http://www.csg.is.titech.ac.jp/~chiba/javassist/html/javassist/util/proxy...) this call deactivates the cache! The solution is simply to remove that call and pass the handler right in the (instance).create(...) method. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 10 months

3
6
0 / 0

[JBoss JIRA] Created: (AS7-1237) File-based deployments stop working after either a failed attempt or an undeploy

by Jim Crossley (JIRA)

File-based deployments stop working after either a failed attempt or an undeploy -------------------------------------------------------------------------------- Key: AS7-1237 URL: https://issues.jboss.org/browse/AS7-1237 Project: Application Server 7 Issue Type: Bug Affects Versions: 7.0.0.CR1 Reporter: Jim Crossley If I create a new, valid war from scratch and copy it to standalone/deployments, AS7 will deploy it fine. Further, I can touch it or overwrite it and AS7 will redeploy it. But once I undeploy it, AS7 will never deploy it again, at least not by my touching it. Also, if I break it and cause a failed deployment, AS7 will never attempt to redeploy it as a result of my updating it. Hence, I can't overwrite an invalid war file with a valid one and have it deploy. To force a deploy, I must either rename my.war.failed to my.war.dodeploy or use the CLI. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 10 months

2
1
0 / 0

[JBoss JIRA] Created: (JBRULES-2730) Duplicate rules name errors not being identified across multiple resources in same package

by Michael Pellegrini (JIRA)

Duplicate rules name errors not being identified across multiple resources in same package ------------------------------------------------------------------------------------------ Key: JBRULES-2730 URL: https://jira.jboss.org/browse/JBRULES-2730 Project: Drools Issue Type: Bug Security Level: Public (Everyone can see) Environment: Windows XP, Java 1.6.0_17 Reporter: Michael Pellegrini Assignee: Mark Proctor The validateUniqueRuleNamesmethod in the org.drools.compiler.PackageBuilder class currently only checks for duplicate rule names that are defined within the same resource. However, in the case where there are multiple resources added to the knowledge builder that share the same package name then the validateUniqueRuleNames method is not detecting duplicates across the package. In cases where rules have the same name and are defined in the same package then I would have expected to get a duplicate rule error but I do not as the rules are physically reside in two separate resources. It seems logical that in addition to checking if any rules are duplicated within the resource that it also checks to see that rule was already defined in the package registry as well. Otherwise the last rule overwrites the first and creates some rather odd behavior. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 10 months

2
2
0 / 0

[JBoss JIRA] Created: (JBRULES-2221) duplicate function in different .drl files of same package silently overridden

by Wolfgang Laun (JIRA)

duplicate function in different .drl files of same package silently overridden ------------------------------------------------------------------------------ Key: JBRULES-2221 URL: https://jira.jboss.org/jira/browse/JBRULES-2221 Project: JBoss Drools Issue Type: Bug Security Level: Public (Everyone can see) Components: drools-compiler (expert) Affects Versions: 5.0.1.FINAL Reporter: Wolfgang Laun Assignee: Mark Proctor Given package p and .drl files a.drl and b.drl, both in this package. If a.drl contains a function foo and b.drl a function foo, then b's function will silently supercede a's function, or vice versa. There is no indication of an error in the return value of kBuilder.getErrors(). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 10 months

3
2
0 / 0

[JBoss JIRA] Commented: (JBRULES-3063) Drools should not allow set two rules with the same name for the same package

by Mark Proctor (JIRA)

[ https://issues.jboss.org/browse/JBRULES-3063?page=com.atlassian.jira.plug... ] Mark Proctor commented on JBRULES-3063: --------------------------------------- Rule replacement is allowed and an important part of a dynamic rule engine. I believe what we do is disallow it from the same resource (should double check that) i.e. a drl that repeats the rule twice is an error. If you load a later resource it will overwrite the previous. Thinking about this some more. We should probably add a "getWarnings" as well as getErrors. Rule overwriting would come with a warning. We might even find a way build warning filters, a composite set of warnings to fail on, but user defineable. > Drools should not allow set two rules with the same name for the same package > ----------------------------------------------------------------------------- > > Key: JBRULES-3063 > URL: https://issues.jboss.org/browse/JBRULES-3063 > Project: Drools > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: drools-compiler > Affects Versions: 5.1.1.FINAL > Reporter: Alessandro Lazarotti > Assignee: Tihomir Surdilovic > Priority: Minor > Fix For: FUTURE > > > Drools should not allow set two rules with the same name for the same package > As expected, Drools does not allow us to define two rules with the same name in a same DRL file. > But if there are two rules with the same name, in the same package, but in separate files, no exception or warning is issued, just one rule overrides the other in silence. > From documentation: > "A rule must have a name, unique within its rule package. If a rule is defined twice in a single DRL, an error will appear when one loads it. If a DRL that includes a rule name already in the package is added, the previous rule is repalced."[1] > [1] http://docs.redhat.com/docs/en-US/JBoss_Enterprise_SOA_Platform/5/html/JB... > Different behavior for a similar action is not good. Both should alert user about a rule name repeated. > For large projects using a lot of DRL files can be hard to track mistakes occurred by rules override . It is really necessary provide an ERROR message for this. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 10 months

1
0
0 / 0

[JBoss JIRA] Created: (AS7-1239) Don't WARN about files in WEB-INF/classes/META-INF

by jaikiran pai (JIRA)

Don't WARN about files in WEB-INF/classes/META-INF -------------------------------------------------- Key: AS7-1239 URL: https://issues.jboss.org/browse/AS7-1239 Project: Application Server 7 Issue Type: Task Components: EE Affects Versions: 7.0.0.CR1 Reporter: jaikiran pai Assignee: jaikiran pai Currently we log a WARN message if we find any files, other than persistence.xml, in .war/WEB-INF/classes/META-INF folder. We need to get rid of the WARN since Weld looks for beans.xml in that location, although CDI doesn't mandate it, but as per the folks on seam-dev mailing list, all application servers look for beans.xml in this location (including previous version on AS). From what I understand, even AS7 looks for beans.xml in this location currently. So this WARN message is misleading and unnecessary. Let's just allow the individual techs to pick up files from this location, as they wish and get rid of this WARN. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 10 months

1
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 July 2011