November 2008 - jboss-jira - Jboss List Archives

[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, 7 months

2
4
0 / 0

[JBoss JIRA] Created: (EJBTHREE-1074) Circular @EJB3 references in session beans fail to deploy.

by Gunnar Grim (JIRA)

Circular @EJB3 references in session beans fail to deploy. ---------------------------------------------------------- Key: EJBTHREE-1074 URL: http://jira.jboss.com/jira/browse/EJBTHREE-1074 Project: EJB 3.0 Issue Type: Bug Affects Versions: AS 4.2.1.GA Reporter: Gunnar Grim The following circular references makes the application undeployable: In ArchiveBrokerBean: @EJB private SeriesBrokerLocal itsSeriesBroker; In SeriesBrokerBean @EJB private ArchiveBrokerLocal itsArchiveBroker; Circular references like these work fine in Glassfish but JBoss shows the following error message: ObjectName: jboss.j2ee:ear=klara5.ear,jar=klara5.jar,name=ArchiveBroker,service=EJB3 State: NOTYETINSTALLED I Depend On: jboss.j2ee:ear=klara5.ear,jar=klara5.jar,name=SeriesBroker,service=EJB3 jboss.j2ee:ear=klara5.ear,jar=klara5.jar,name=ArchiveTypeBroker,service=EJB3 persistence.units:ear=klara5.ear,jar=klara5.jar,unitName=KlaraPU Depends On Me: jboss.j2ee:ear=klara5.ear,jar=klara5.jar,name=ArchiveOrigBroker,service=EJB3 jboss.j2ee:ear=klara5.ear,jar=klara5.jar,name=SeriesBroker,service=EJB3 ObjectName: jboss.j2ee:ear=klara5.ear,jar=klara5.jar,name=ArchiveOrigBroker,service=EJB3 State: NOTYETINSTALLED I Depend On: jboss.j2ee:ear=klara5.ear,jar=klara5.jar,name=ArchiveBroker,service=EJB3 persistence.units:ear=klara5.ear,jar=klara5.jar,unitName=KlaraPU ObjectName: jboss.j2ee:ear=klara5.ear,jar=klara5.jar,name=SeriesBroker,service=EJB3 State: NOTYETINSTALLED I Depend On: jboss.j2ee:ear=klara5.ear,jar=klara5.jar,name=ArchiveBroker,service=EJB3 persistence.units:ear=klara5.ear,jar=klara5.jar,unitName=KlaraPU Depends On Me: jboss.j2ee:ear=klara5.ear,jar=klara5.jar,name=ArchiveBroker,service=EJB3 jboss.j2ee:ear=klara5.ear,jar=klara5.jar,name=VolumeBroker,service=EJB3 ObjectName: jboss.j2ee:ear=klara5.ear,jar=klara5.jar,name=VolumeBroker,service=EJB3 State: NOTYETINSTALLED I Depend On: jboss.j2ee:ear=klara5.ear,jar=klara5.jar,name=SeriesBroker,service=EJB3 persistence.units:ear=klara5.ear,jar=klara5.jar,unitName=KlaraPU -- 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, 7 months

10
11
0 / 0

[JBoss JIRA] Created: (JGRP-747) RELAY: replication between data centers

by Bela Ban (JIRA)

RELAY: replication between data centers --------------------------------------- Key: JGRP-747 URL: http://jira.jboss.com/jira/browse/JGRP-747 Project: JGroups Issue Type: Feature Request Reporter: Bela Ban Assigned To: Bela Ban Fix For: 2.x [from JGroups/doc/design/DataCenterReplication.txt] Replication between data centers ================================ Author: Bela Ban Version: $Id: DataCenterReplication.txt,v 1.6 2008/04/25 15:54:30 belaban Exp $ We have data centers in New York (NYC) and San Francisco (SFO). The idea is to replicate traffic from NYC to SFO asynchronously. In case of a site failure of NYC, all clients can be switched over to SFO and continue working with (almost) up-to-date data. The failing over of clients to SFO is outside the scope of this proposal, and could be done for example by changing DNS entries, load balancers etc. There is no replication going on from SFO to NYC by default, only when SFO becomes the primary site. The assumption is that there is no message between data centers which requires a response. This would require NAT functionlity, which we may provide in a future version. For the example, we assume that each site uses a UDP based stack, and replication between the sites use a TCP based stack, see figure DataCenterReplication.png. There is a local cluster, based on UDP, at each site and one global cluster, based on TCP, which connects the two sites. Each coordinator of the local cluster is also a member of the global cluster, e.g. member E in NYC (assuming it is the coordinator) is also member X of the TCP cluster. This is called a *relay* member. A relay member is always member of the local and global cluster. A relay member has a UDP stack which additionally contains a protocol RELAY at the top (shown in the bottom part of the figure). RELAY has a JChannel which connects to the TCP group, but *only* when it is (or becomes) coordinator of the local cluster. The configuration of the TCP channel is done via a property in RELAY. Any *multicast* message (we don't relay unicast messages) that is received by RELAY traveling up the stack is sent via the TCP channel to the other site. When received there, the corresponding RELAY protocol changes the destination of the message to null (those are multicast messages after all) and leaves the src (which might point to X if sent from NYC), then it sends the message down the stack, where it will get multicast to all members of the local cluster (including the sender). When a response is received which points to any non-local address (e.g. X), RELAY simply drops it. When forwarding a message to the local cluster, RELAY adds a header. When it receives the multicast message it forwarded itself, and a header is present, it does *not* relay it back to the other site but simply drops it. Otherwise, we would have a cycle. When a coordinator crashes or leaves, the next-in-line becomes coordinator and activates the RELAY protocol, connecting to the TCP channel and starting to relay messages. However, if we receive messages from the local cluster while the coordinator has crashed and the new one hasn't taken over yet, we'd lose messages. Therefore, we need additional functionality in RELAY which buffers the last N messages (or M bytes, or for T seconds) and numbers all messages sent. This is done by the second-in-line. When there is a coordinator failover, the new coordinator communicates briefly with the other site to determine which was the highest message relayed by it. It then forwards buffered messages with lower numbers and removes the remaining messages in the buffer. During this replay, message relaying is suspended. Therefore, a relay has to handle 3 types of messages from the global (TCP) cluster: (1) Regular multicast messages (2) A message asking for the highest sequence number received from another relay, and the response to this (3) A message stating that the other side will go down gracefully (no need to replay buffered messages) Example walkthrough ------------------- - C (in the NYC cluster, with coordinator E) multicasts a message - A, B, C, D and E receive the multicast - D (second-in-line) buffer the message (bounded buffer) - E is the relay. The byte buffer is extracted and a new message M is created. M's source is C, the dest is null (= send to all). Note that the original headers are *not* sent with M. If this is needed, we need to revisit. - X receives M, drops it (because it is the sender, determined by the header). - Y receives M, adds a RELAY header and sends it down the stack - T, U, V, W and S receive M and deliver it - Y does not relay M because M has a header - Should some member reply (to X), then RELAY at Y will drop the message -- 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, 7 months

1
8
0 / 0

[JBoss JIRA] Created: (SECURITY-136) jboss-web defined authenticators in JBoss 4.2.x?

by Darran Lofthouse (JIRA)

jboss-web defined authenticators in JBoss 4.2.x? ------------------------------------------------ Key: SECURITY-136 URL: http://jira.jboss.com/jira/browse/SECURITY-136 Project: JBoss Security and Identity Management Issue Type: Task Security Level: Public (Everyone can see) Components: Negotiation Reporter: Darran Lofthouse Assigned To: Darran Lofthouse -- 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

1
6
0 / 0

[JBoss JIRA] Created: (EJBTHREE-1073) SessionContext.getBusinessObject(...) throws IllegalStateException on @Service EJB

by Michael McKibben (JIRA)

SessionContext.getBusinessObject(...) throws IllegalStateException on @Service EJB ---------------------------------------------------------------------------------- Key: EJBTHREE-1073 URL: http://jira.jboss.com/jira/browse/EJBTHREE-1073 Project: EJB 3.0 Issue Type: Bug Components: EJB3 Extensions Affects Versions: AS 4.2.1.GA Reporter: Michael McKibben Calling SessionContext.getBusinessObject(...) throws an IllegalStateException within a @Service EJB. This should behave like a Stateless/Stateful EJB no? -- 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

2
2
0 / 0

[JBoss JIRA] Created: (JBRULES-1800) SNAPSHOT versions should have a version suffix of -SNAPSHOT instead of .SNAPSHOT

by Geoffrey De Smet (JIRA)

SNAPSHOT versions should have a version suffix of -SNAPSHOT instead of .SNAPSHOT -------------------------------------------------------------------------------- Key: JBRULES-1800 URL: https://jira.jboss.org/jira/browse/JBRULES-1800 Project: JBoss Drools Issue Type: Bug Security Level: Public (Everyone can see) Components: All Affects Versions: 5.0.0.M2 Reporter: Geoffrey De Smet Assignee: Mark Proctor Priority: Minor Fix For: 5.0.0.M3 It causes problems, because maven doesn't recognize it as a snapshot, it's just a fake snapshot: - sources aren't downloaded for "mvn eclipse:eclipse", etc Mark told me he uses .SNAPSHOT intentionally, as a hack for building the drools eclipse plugin, but is that still necessary? What is the problem with using -SNAPSHOT there exactly and can we solve it another way? :) -- 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

4
10
0 / 0

[JBoss JIRA] Created: (JBMETA-117) Prohibit bindings is there isn't a corresponding business interface

by Andrew Lee Rubinger (JIRA)

Prohibit bindings is there isn't a corresponding business interface ------------------------------------------------------------------- Key: JBMETA-117 URL: https://jira.jboss.org/jira/browse/JBMETA-117 Project: JBoss Metadata Issue Type: Feature Request Security Level: Public (Everyone can see) Reporter: Andrew Lee Rubinger Assignee: Andrew Lee Rubinger Fix For: 1.0.0.CR2 The following 2 constructs should throw an informative error to the bean provider: @Stateless @Remote(MyRemote.class) @LocalBinding(jndiBinding="Whatever") // There's no local business interface public class MyBean implements MyRemote{...} @Stateless @Local(MyLocal.class) @RemoteBinding(jndiBinding="Whatever") // There's no remote business interface public class MyBean implements MyLocal{...} -- 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

2
16
0 / 0

[JBoss JIRA] Created: (JBRULES-1370) [M]Bulk change of package, category of asset lists

by Michael Neale (JIRA)

[M]Bulk change of package, category of asset lists -------------------------------------------------- Key: JBRULES-1370 URL: http://jira.jboss.com/jira/browse/JBRULES-1370 Project: JBoss Drools Issue Type: Sub-task Security Level: Public (Everyone can see) Reporter: Michael Neale Assigned To: Michael Neale -- 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

6
16
0 / 0

[JBoss JIRA] Created: (EJBTHREE-1045) Improve error message when binding fails

by Carlo de Wolf (JIRA)

Improve error message when binding fails ---------------------------------------- Key: EJBTHREE-1045 URL: http://jira.jboss.com/jira/browse/EJBTHREE-1045 Project: EJB 3.0 Issue Type: Feature Request Affects Versions: AS 4.2.1.GA Reporter: Carlo de Wolf Fix For: AS 4.2.2.GA, EJB 3.0 RC11 - FD 2007-09-03 14:58:50,737 WARN [org.jboss.system.ServiceController] Problem starting service jboss.j2 ee:ear=jbilling.ear,jar=jbilling.jar,name=com/xxx/yyy/server/item/ItemSession,service=EJB3 java.lang.ClassCastException: $Proxy76 cannot be cast to javax.naming.Context at org.jboss.util.naming.Util.createSubcontext(Util.java:69) at org.jboss.util.naming.Util.rebind(Util.java:125) at org.jboss.util.naming.Util.rebind(Util.java:113) at org.jboss.ejb3.stateless.StatelessRemoteProxyFactory.start(StatelessRemoteProxyFactory.java:115) In EJB 3 a stateful session bean can be created directly via a loopup on it's business interface. By default this one is bound to <ejb-name>/remote (or /local). The home interface is bound to <ejb-name>/home (or /localHome). If you override the JNDI name for the bean by <ejb-name> then this exception occurs. The log file should show "Binding proxy for <ejb-name> in JNDI at <jndi-name>" just before this happens. It should say an error message in the likes of: "Can't bind ItemSession/remoteHome, because ItemSession is already bound" -- 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

2
8
0 / 0

[JBoss JIRA] Created: (JBAS-4211) Detecting OutOfMemoryErrors in Servers in the Test Suite

by Ryan Campbell (JIRA)

Detecting OutOfMemoryErrors in Servers in the Test Suite -------------------------------------------------------- Key: JBAS-4211 URL: http://jira.jboss.com/jira/browse/JBAS-4211 Project: JBoss Application Server Issue Type: Feature Request Security Level: Public (Everyone can see) Components: Test Suite Reporter: Ryan Campbell Assigned To: Martin Vecera Fix For: JBossAS-4.2.0.GA, JBossAS-5.0.0.Beta3, JBossAS-4.0.5.SP1 We need a custom test runner which checks for OOME's in any running servers between each test. Optionally, only check for this after a failed test. See the discussion for details. -- 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

4
16
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 2008