[JBoss JIRA] Created: (JBAS-5102) Crossreferencing EJBs using comp-names does not work
by Christian Nolte (JIRA)
Crossreferencing EJBs using comp-names does not work
----------------------------------------------------
Key: JBAS-5102
URL: http://jira.jboss.com/jira/browse/JBAS-5102
Project: JBoss Application Server
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: EJB3
Affects Versions: JBossAS-4.2.2.GA
Reporter: Christian Nolte
Assigned To: Carlo de Wolf
I have two stateless session beans which are referencing each other like
that:
@Stateless
public class SessionBeanA implements SessionBeanALocal {
@EJB private SessionBeanB sessionB;
}
and
@Stateless
public class SessionBeanB implement SessionBeanBLocal {
@EJB private SessionBeanA sessionA;
}
When deploying the application on JBoss AS I get
--- MBeans waiting for other MBeans ---
ObjectName: jboss.j2ee:jar=test.jar,name=SessionBeanA,service=EJB3
State: NOTYETINSTALLED
I Depend On:
jboss.j2ee:jar=test.jar,name=SessionBeanB,service=EJB3
persistence.units:jar=test.jar,unitName=test.jar
Depends On Me:
jboss.j2ee:jar=test.jar,name=SessionBeanB,service=EJB3
ObjectName: jboss.j2ee:jar=test.jar,name=SessionBeanB,service=EJB3
State: NOTYETINSTALLED
I Depend On:
jboss.j2ee:jar=test.jar,name=SessionBeanA,service=EJB3
Depends On Me:
jboss.j2ee:jar=test.jar,name=SessionBeanA,service=EJB3
and the deployment fails.
--
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
15 years, 8 months
[JBoss JIRA] Created: (JBAS-5197) Add "RetryInterceptor" functionality to all clustered proxies
by Brian Stansberry (JIRA)
Add "RetryInterceptor" functionality to all clustered proxies
-------------------------------------------------------------
Key: JBAS-5197
URL: http://jira.jboss.com/jira/browse/JBAS-5197
Project: JBoss Application Server
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Components: Clustering
Reporter: Brian Stansberry
Assigned To: Brian Stansberry
Fix For: JBossAS-5.1.0.CR1
Container issue for ensuring "RetryInterceptor" functionality is added to all clustered proxies.
"RetryInterceptor" functionality consists of adding an interceptor that is able to access the cluster (currently via JNDI) and get an updated set of cluster targets when all current targets have failed. Needed when a complete cluster restart has occurred since the current list of targets was deserialized on the client.
We currently have this for EJB2 proxies; need it for EJB3, HA-JNDI and generic AOP-based and ProxyFactoryHA-based proxies.
--
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
15 years, 8 months
[JBoss JIRA] Created: (JBAS-6144) Resolve intermittent org.jboss.test.cluster.defaultcfg.web.test.ScopedSetAttributeTestCase(Default-udp).testInvalidate failure
by Brian Stansberry (JIRA)
Resolve intermittent org.jboss.test.cluster.defaultcfg.web.test.ScopedSetAttributeTestCase(Default-udp).testInvalidate failure
------------------------------------------------------------------------------------------------------------------------------
Key: JBAS-6144
URL: https://jira.jboss.org/jira/browse/JBAS-6144
Project: JBoss Application Server
Issue Type: Task
Security Level: Public (Everyone can see)
Components: Clustering, Web (Tomcat) service
Reporter: Brian Stansberry
Assignee: Brian Stansberry
Fix For: JBossAS-5.0.1.CR1
This test intermittently fails. The web clustering tests in the default REPL_ASYNC config can occasionally fail due to timing, where the test fails over to the other cluster node before the replicated session arrives. There is a 200 ms delay before failover, but occasional bad luck (e.g. a full gc at wrong time) can make that too short. (Making it longer makes the whole testsuite longer.) But, this issue should cause random failures, whereas this particular test seems to pop up as a failure a high percentage of the time. Need to understand why.
--
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
15 years, 8 months
[JBoss JIRA] Created: (JBAS-5819) Don't call expire when processing remote invalidation of clustered session
by Brian Stansberry (JIRA)
Don't call expire when processing remote invalidation of clustered session
--------------------------------------------------------------------------
Key: JBAS-5819
URL: https://jira.jboss.org/jira/browse/JBAS-5819
Project: JBoss Application Server
Issue Type: Task
Security Level: Public (Everyone can see)
Components: Clustering, Web (Tomcat) service
Reporter: Brian Stansberry
Assignee: Brian Stansberry
Fix For: JBossAS-5.0.0.CR2, JBossAS-4.2.4.GA
When JBC notifies JBossCacheManager that the root node for a session has been invalidated via a remote call, JBMC.processRemoteInvalidation() calls Session.expire on the local session (if there is one). The expire call includes flags that result in no notifications being sent to any listeners.
I don't see any point to this expire call if there are no notifications. The other work expire does is removing content from JBC, but the remote invalidation that triggers all this is already removing that content. Just drop the session from the local session map. Perhaps flag the session so if there is a concurrency/sticky-session problem and a local request thread is handling the session it knows the session is invalid.
--
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
15 years, 8 months
[JBoss JIRA] Created: (JBAS-6562) Context entries don't work as explained in tomcat docs.
by Vicky Kak (JIRA)
Context entries don't work as explained in tomcat docs.
-------------------------------------------------------
Key: JBAS-6562
URL: https://jira.jboss.org/jira/browse/JBAS-6562
Project: JBoss Application Server
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Components: Web (Tomcat) service
Reporter: Vicky Kak
Assignee: Vicky Kak
Fix For: JBossAS-5.1.0.Beta1, JBossAS-4.2.4.GA
The documentation about the context configuration in Tomcat does not work in JbossAS deployments.
I have just spend some time looking at the related code at
http://anonsvn.jboss.org/repos/jbossas/branches/JBPAPP_4_2/tomcat/src/mai...
Here is the code snippet
****************************************************************
private String findConfig(URL warURL) throws IOException
{
String result = null;
// See if the warUrl is a dir or a file
File warFile = new File(warURL.getFile());
if (warURL.getProtocol().equals("file") && warFile.isDirectory() == true)
{
File webDD = new File(warFile, CONTEXT_CONFIG_FILE);
if (webDD.exists() == true) result = webDD.getAbsolutePath();
}
else
{
ZipFile zipFile = new ZipFile(warFile);
ZipEntry entry = zipFile.getEntry(CONTEXT_CONFIG_FILE);
if (entry != null)
{
InputStream zipIS = zipFile.getInputStream(entry);
byte[] buffer = new byte[512];
int bytes;
result = warFile.getAbsolutePath() + "-context.xml";
FileOutputStream fos = new FileOutputStream(result);
while ((bytes = zipIS.read(buffer)) > 0)
{
fos.write(buffer, 0, bytes);
}
zipIS.close();
fos.close();
}
zipFile.close();
}
return result;
}
****************************************************************
This code needs to be modified in such a way that it uses these configurations
**************************************************************************************
1. in the $CATALINA_HOME/conf/[enginename]/[hostname]/context.xml.default file: the Context element information will be loaded by all webapps of that host
2. in individual files (with a ".xml" extension) in the $CATALINA_HOME/conf/[enginename]/[hostname]/ directory. The name of the file (less the .xml) extension will be used as the context path. Multi-level context paths may be defined using #, e.g. context#path.xml. The default web application may be defined by using a file called ROOT.xml.
3. if the previous file was not found for this application, in an individual file at /META-INF/context.xml inside the application files
inside a Host element in the main conf/server.xml
**************************************************************************************
The point[3] is already rejected earlier by Scott, here is the related jira
https://jira.jboss.org/jira/browse/JBAS-2290
--
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
15 years, 8 months
[JBoss JIRA] Created: (JBRULES-1820) Exception: Input stream is not explicitly closed.
by Kris Nuttycombe (JIRA)
Exception: Input stream is not explicitly closed.
-------------------------------------------------
Key: JBRULES-1820
URL: https://jira.jboss.org/jira/browse/JBRULES-1820
Project: JBoss Drools
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: drools-compiler
Affects Versions: 4.0.7
Environment: Java 6, Linux
Reporter: Kris Nuttycombe
Assignee: Mark Proctor
I am using the Drools PackageBuilder to create business rules from a file. While the rules appear to function correctly, when the JVM which runs the application shuts down, an exception is thrown due to the forced closing of an unclosed stream. It looks from the stack trace like the Drools code is opening a stream using ClassLoader.getResourceAsStream which is then left unclosed and is forced close at JVM shutdown.
On application server shutdown, I receive the following exception. This appears to be the result of an unclosed input stream for a system resource used by the Drools compiler.
[#|2008-10-23T09:55:09.527-0600|WARNING|sun-appserver9.1|javax.enterprise.system.core.classloading|_ThreadID=22;_ThreadName=RMI TCP Connection(1197)-10.97.100.58;_RequestID=341c51d9-08de-4e67-9da1-c57375cb5f35;|Input stream has been finalized or forced closed without being explicitly closed; stream instantiation reported in following stack trace
java.lang.Throwable
at com.sun.enterprise.loader.EJBClassLoader$SentinelInputStream.<init>(EJBClassLoader.java:1169)
at com.sun.enterprise.loader.EJBClassLoader$InternalJarURLConnection.getInputStream(EJBClassLoader.java:1262)
at java.net.URL.openStream(URL.java:1009)
at java.lang.ClassLoader.getResourceAsStream(ClassLoader.java:1161)
at com.sun.enterprise.loader.EJBClassLoader.getResourceAsStream(EJBClassLoader.java:799)
at org.drools.rule.PackageCompilationData$PackageClassLoader.getResourceAsStream(PackageCompilationData.java:384)
at org.drools.commons.jci.compilers.EclipseJavaCompiler$2.isPackage(EclipseJavaCompiler.java:280)
at org.drools.commons.jci.compilers.EclipseJavaCompiler$2.findType(EclipseJavaCompiler.java:222)
at org.drools.commons.jci.compilers.EclipseJavaCompiler$2.findType(EclipseJavaCompiler.java:204)
at org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.askForType(LookupEnvironment.java:97)
at org.eclipse.jdt.internal.compiler.lookup.UnresolvedReferenceBinding.resolve(UnresolvedReferenceBinding.java:43)
at org.eclipse.jdt.internal.compiler.lookup.BinaryTypeBinding.resolveUnresolvedType(BinaryTypeBinding.java:138)
at org.eclipse.jdt.internal.compiler.lookup.BinaryTypeBinding.superclass(BinaryTypeBinding.java:936)
at org.eclipse.jdt.internal.compiler.lookup.BinaryTypeBinding.getExactMethod(BinaryTypeBinding.java:724)
at org.eclipse.jdt.internal.compiler.lookup.BinaryTypeBinding.getExactMethod(BinaryTypeBinding.java:727)
at org.eclipse.jdt.internal.compiler.lookup.Scope.findExactMethod(Scope.java:761)
at org.eclipse.jdt.internal.compiler.lookup.Scope.getMethod(Scope.java:2002)
at org.eclipse.jdt.internal.compiler.ast.MessageSend.resolveType(MessageSend.java:384)
at org.eclipse.jdt.internal.compiler.ast.ReturnStatement.resolve(ReturnStatement.java:220)
at org.eclipse.jdt.internal.compiler.ast.AbstractMethodDeclaration.resolveStatements(AbstractMethodDeclaration.java:432)
at org.eclipse.jdt.internal.compiler.ast.MethodDeclaration.resolveStatements(MethodDeclaration.java:190)
at org.eclipse.jdt.internal.compiler.ast.AbstractMethodDeclaration.resolve(AbstractMethodDeclaration.java:403)
at org.eclipse.jdt.internal.compiler.ast.TypeDeclaration.resolve(TypeDeclaration.java:1047)
at org.eclipse.jdt.internal.compiler.ast.TypeDeclaration.resolve(TypeDeclaration.java:1094)
at org.eclipse.jdt.internal.compiler.ast.CompilationUnitDeclaration.resolve(CompilationUnitDeclaration.java:353)
at org.eclipse.jdt.internal.compiler.Compiler.process(Compiler.java:596)
at org.eclipse.jdt.internal.compiler.Compiler.compile(Compiler.java:411)
at org.drools.commons.jci.compilers.EclipseJavaCompiler.compile(EclipseJavaCompiler.java:351)
at org.drools.commons.jci.compilers.AbstractJavaCompiler.compile(AbstractJavaCompiler.java:51)
at org.drools.rule.builder.dialect.java.JavaDialect.compileAll(JavaDialect.java:342)
at org.drools.compiler.DialectRegistry.compileAll(DialectRegistry.java:60)
at org.drools.compiler.PackageBuilder.addPackage(PackageBuilder.java:308)
at org.drools.compiler.PackageBuilder.addPackageFromDrl(PackageBuilder.java:167)
--
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
15 years, 8 months
[JBoss JIRA] Created: (JBAS-6983) Error configuring property: sessionIdAlphabet for WarDeployer
by Manuel Aznar Perez (JIRA)
Error configuring property: sessionIdAlphabet for WarDeployer
-------------------------------------------------------------
Key: JBAS-6983
URL: https://jira.jboss.org/jira/browse/JBAS-6983
Project: JBoss Application Server
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Web (Tomcat) service
Affects Versions: JBossAS-5.1.0.GA, JBossAS-5.0.1.GA
Environment: JBoss 5.0.1.GA or JBoss 5.1.0.GA
Reporter: Manuel Aznar Perez
Assignee: Remy Maucherat
Priority: Minor
At "server/default/deployers/jbossweb.deployer/META-INF/war-deployers-jboss-beans.xml" when i uncomment "<property name="sessionIdAlphabet">" and run JBoss. Launch exception:
2009-05-28 08:34:34,670 ERROR [org.jboss.kernel.plugins.dependency.AbstractKernelController] (main) Error installing to Configured: name=WarDeployer state=Instantiated
java.lang.RuntimeException: Error configuring property: sessionIdAlphabet for WarDeployer
at org.jboss.kernel.plugins.dependency.ConfigureAction.dispatchSetProperty(ConfigureAction.java:112)
at org.jboss.kernel.plugins.dependency.ConfigureAction.setAttributes(ConfigureAction.java:85)
at org.jboss.kernel.plugins.dependency.ConfigureAction.installActionInternal(ConfigureAction.java:44)
at org.jboss.kernel.plugins.dependency.InstallsAwareAction.installAction(InstallsAwareAction.java:54)
at org.jboss.kernel.plugins.dependency.InstallsAwareAction.installAction(InstallsAwareAction.java:42)
at org.jboss.dependency.plugins.action.SimpleControllerContextAction.simpleInstallAction(SimpleControllerContextAction.java:62)
at org.jboss.dependency.plugins.action.AccessControllerContextAction.install(AccessControllerContextAction.java:71)
at org.jboss.dependency.plugins.AbstractControllerContextActions.install(AbstractControllerContextActions.java:51)
at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348)
at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1631)
at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:934)
at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1082)
at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:984)
at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:774)
at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:540)
at org.jboss.deployers.vfs.deployer.kernel.BeanMetaDataDeployer.deploy(BeanMetaDataDeployer.java:121)
at org.jboss.deployers.vfs.deployer.kernel.BeanMetaDataDeployer.deploy(BeanMetaDataDeployer.java:51)
at org.jboss.deployers.spi.deployer.helpers.AbstractSimpleRealDeployer.internalDeploy(AbstractSimpleRealDeployer.java:62)
at org.jboss.deployers.spi.deployer.helpers.AbstractRealDeployer.deploy(AbstractRealDeployer.java:50)
at org.jboss.deployers.plugins.deployers.DeployerWrapper.deploy(DeployerWrapper.java:171)
at org.jboss.deployers.plugins.deployers.DeployersImpl.doDeploy(DeployersImpl.java:1439)
at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1157)
at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1178)
at org.jboss.deployers.plugins.deployers.DeployersImpl.install(DeployersImpl.java:1098)
at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348)
at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1631)
at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:934)
at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1082)
at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:984)
at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:822)
at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:553)
at org.jboss.deployers.plugins.deployers.DeployersImpl.process(DeployersImpl.java:781)
at org.jboss.deployers.plugins.main.MainDeployerImpl.process(MainDeployerImpl.java:702)
That is because don't have "jboss-web-service.jar" in deployer.
This jar is in "deploy/jbossweb.sar".
This is fixed copy jar file to deployer directory.
--
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
15 years, 8 months