[JBoss JIRA] Created: (EJBTHREE-1072) Ejb3TxPolicy does not rollback the transaction in case of an error
by Olaf Fricke (JIRA)
Ejb3TxPolicy does not rollback the transaction in case of an error
------------------------------------------------------------------
Key: EJBTHREE-1072
URL: http://jira.jboss.com/jira/browse/EJBTHREE-1072
Project: EJB 3.0
Issue Type: Bug
Affects Versions: HEAD
Reporter: Olaf Fricke
Priority: Blocker
The class Ejb3TxPolicy is used to rollback the transaction in the case of exceptions. According to the ejb 3.0 spec, the transaction is rolled back in case of ApplicationException with rollback() evaluating to true, in case of RuntimeExceptions or in case of EjbException.
All other exception will not lead to a rollback on the current transaction.
Unfortunately, the same is true in case of errors. If, for example, an AssertionError (or a ClassDefNotFoundError etc.) occurs, the current transaction will be committed and not rolled back. This behaviour is wrong with respect to the ejb 3.0 spec (see for example table 14 on page 360 of ejbcore.pdf)
A possible solution would be to wrap the error into a new RuntimeException after handling ApplicationException (in both methods handleExceptionInOurTx and handleInCallerTx):
<code>
if (t instanceof Error)
{
t = new RuntimeException(t);
}
if (!(t instanceof RuntimeException || t instanceof RemoteException))
{
throw t;
}
</code>
The wrapping is necessary, because both the EJBException and the EJBTransactionRolledbackException can only handle exceptions, but not errors.
--
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
16 years, 10 months
[JBoss JIRA] Created: (JBRULES-1060) Unexpected exit with no stack trace or other information
by christopher barham (JIRA)
Unexpected exit with no stack trace or other information
--------------------------------------------------------
Key: JBRULES-1060
URL: http://jira.jboss.com/jira/browse/JBRULES-1060
Project: JBoss Rules
Issue Type: Bug
Security Level: Public (Everyone can see)
Affects Versions: 4.0.0.GA
Environment: Windows XP sp2, 1GB RAM, Sun Java JDK 1.5.0_11, Eclipse 3.3 Build id: I20070621-1340, JBOSS Rules feature/plugin 4.0.0
Reporter: christopher barham
Assigned To: Mark Proctor
When inserting a number of facts, (seems to be somewhere around 450 facts in this test example here), the rules system exits unexpectedly with no stack trace or other information. I pared down my code to a simple example that demonstrates this below. I can get it to run normally if I insert 450 facts, however 475 or above exhibits this unexpected system exit. I am running this from Eclipse.
Garbage.java (fact bean):
package com.sample;
public class Garbage {
private char id;
private int someNumber;
public Garbage(char garbageId, int someNumber) {
setSomeNumber(someNumber);
setId(garbageId);
}
public char getId() {
return id;
}
public int getSomeNumber() {
return someNumber;
}
public void setId(char id) {
this.id = id;
}
public void setSomeNumber(int someNumber) {
this.someNumber = someNumber;
}
@Override
public String toString() {
StringBuilder sb = new StringBuilder();
sb.append("a Garbage { ");
sb.append("someNumber= ");
sb.append(getSomeNumber());
sb.append(", id= ");
sb.append(getId());
sb.append(" }");
return sb.toString();
}
}
StrangeExit.Java (Rule Engine startup and fact insertion):
package com.sample;
import java.io.InputStreamReader;
import java.io.Reader;
import org.drools.RuleBase;
import org.drools.RuleBaseFactory;
import org.drools.WorkingMemory;
import org.drools.compiler.PackageBuilder;
import org.drools.event.DebugWorkingMemoryEventListener;
import org.drools.rule.Package;
public class StrangeExit {
public static final void main(String[] args) {
try {
long startTime = System.currentTimeMillis();
System.out.println("Starting problem at " + new java.util.Date());
RuleBase ruleBase = readRule();
WorkingMemory workingMemory = ruleBase.newStatefulSession();
workingMemory.addEventListener(new DebugWorkingMemoryEventListener());
assertAllFacts(workingMemory);
workingMemory.fireAllRules();
long stopTime = System.currentTimeMillis();
long runTime = stopTime - startTime;
System.out.println("Run time (milliseconds): " + runTime);
System.out.println("Finished problem at " + new java.util.Date());
} catch (Throwable t) {
t.printStackTrace();
}
}
private static void assertAllFacts(WorkingMemory workingMemory) {
for (int i = 1; i <= 3; i++) {
for (int j = 1; j <= 475; j++) {
Garbage gar = new Garbage((char)(i + 64), j);
workingMemory.insert(gar);
}
}
}
private static RuleBase readRule() throws Exception {
Reader source = new InputStreamReader(StrangeExit.class.getResourceAsStream("/strange.drl"));
PackageBuilder builder = new PackageBuilder();
builder.addPackageFromDrl(source);
Package pkg = builder.getPackage();
RuleBase ruleBase = RuleBaseFactory.newRuleBase();
ruleBase.addPackage(pkg);
return ruleBase;
}
}
The Rule itself:
package com.sample
import com.sample.Garbage;
rule "Weird exit with no stack trace error"
when
$garA : Garbage( )
$garB : Garbage( id == 'B' , someNumber >= $garA.someNumber )
then
System.out.println("Something is up");
end
--
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
16 years, 10 months
[JBoss JIRA] Created: (JBRULES-1386) OC4J Support
by Jason Lee (JIRA)
OC4J Support
------------
Key: JBRULES-1386
URL: http://jira.jboss.com/jira/browse/JBRULES-1386
Project: JBoss Drools
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Components: drools-brms
Affects Versions: 4.1.0
Environment: OC4J 10.1.3.3
Reporter: Jason Lee
Priority: Minor
The current nightly build fails to deploy and/or run on OC4J 10.1.3.3. To fix this, I did the following:
* Upgrade jboss-seam to 2.0.0 CVS (GA might work, but I added some logging to org.jboss.seam.init.Initialization to help track down deployment issues)
* Upgrade jboss-el to 2.0.0.GA
* Added Mojarra 1.2_07 jars
* Added the following to web.xml:
<context-param>
<param-name> com.sun.faces.forceLoadConfiguration</param-name>
<param-value>true</param-value>
</context-param>
--
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
16 years, 10 months
[JBoss JIRA] Created: (JBRULES-1338) DirectoryScanner should only take into account relevant files
by Jￃﾶrg Erdmenger (JIRA)
DirectoryScanner should only take into account relevant files
-------------------------------------------------------------
Key: JBRULES-1338
URL: http://jira.jboss.com/jira/browse/JBRULES-1338
Project: JBoss Drools
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Components: All
Reporter: Jￃﾶrg Erdmenger
Currently DirectoryScanner in its configure and loadPackageChanges methods takes into account all types of files and hands them to FileScanner. This causes issues when the directory specified is under source management control (at least if CVS or Subversion are used) as the .svn or similar files/dirs cause FileScanner to barf. Now I'm sure that for plenty of cases the dir passed to DirectoryScanner won't be SCM managed but I think there might also be lots of situations where it is. Considering that it would be such a trivial change to either:
- only take into account .pkg and .drl files (or do we need .dsl, .rf as well)
- or at least ignore dot files (and maybe directories in general?)
I think it will be worth doing.
--
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
16 years, 10 months
[JBoss JIRA] Created: (JBMESSAGING-1213) Client side connection exception is not thrown on the client side when the lease times out
by Jay Howell (JIRA)
Client side connection exception is not thrown on the client side when the lease times out
------------------------------------------------------------------------------------------
Key: JBMESSAGING-1213
URL: http://jira.jboss.com/jira/browse/JBMESSAGING-1213
Project: JBoss Messaging
Issue Type: Bug
Components: JMS Remoting
Affects Versions: 1.4.0.SP3
Reporter: Jay Howell
Assigned To: Tim Fox
Clients that are connected that experience a lease timeout are not notified that they no longer have a connection on the server. The behavior is that clients think that they are alive, while they will no longer get any messages. Also something of note, the Server side pinger has been disabled for JBM.
Note: this is an issue that can either be fixed on the remoting side or the JBM side. Discussing this with Clebert, it may be prudent to fix it on both sides. I've opened this jira to facilitate the communication about where the logic should go. Please refer to the linked Remoting Jira JBREM-888 that was opened for this same topic.
--
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
16 years, 10 months
[JBoss JIRA] Created: (JBMESSAGING-1121) Allow command line configuration of ServerPeerID
by Brian Stansberry (JIRA)
Allow command line configuration of ServerPeerID
------------------------------------------------
Key: JBMESSAGING-1121
URL: http://jira.jboss.com/jira/browse/JBMESSAGING-1121
Project: JBoss Messaging
Issue Type: Feature Request
Components: JMS Clustering
Affects Versions: 1.4.0.GA
Reporter: Brian Stansberry
Assigned To: Tim Fox
Fix For: AS 5.0 Integration, EAP 4.3 Integration
The ServerPeer ServerPeerID is currently hard coded at 0 in messaging-service.xml. If you want to set up a cluster, the only way to get it to work is to manually change the value in that file in each node. This needs to be configurable from the command line; i.e via system property substitution.
Need to be sure any changes made in the messaging-service.xml are also reflected in docs/examples/binding-manager/sample-bindings.xml.
--
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
16 years, 10 months
[JBoss JIRA] Created: (JBSER-98) Write slot with fields only if both readObject and writeObject are missing
by Galder Zamarreno (JIRA)
Write slot with fields only if both readObject and writeObject are missing
--------------------------------------------------------------------------
Key: JBSER-98
URL: http://jira.jboss.com/jira/browse/JBSER-98
Project: JBoss Serialization
Issue Type: Feature Request
Affects Versions: 1.0.3 GA
Reporter: Galder Zamarreno
Assigned To: Clebert Suconic
Over the last few weeks, I've been dealing with a funky support case which showed the following
stacktrace:
...
Caused by: org.jboss.serial.exception.SerializationException: Excepted to be String
at org.jboss.serial.objectmetamodel.DataContainer$DataContainerInput.readUTF(DataContainer.java:1120)
at org.jboss.serial.classmetamodel.StreamingClass.readStream(StreamingClass.java:71)
at org.jboss.serial.objectmetamodel.ObjectDescriptorFactory.readObjectDescriptionFromStreaming(ObjectDescriptorFactory.java:381)
at org.jboss.serial.objectmetamodel.ObjectDescriptorFactory.objectFromDescription(ObjectDescriptorFactory.java:82)
at org.jboss.serial.objectmetamodel.DataContainer$DataContainerInput.readObject(DataContainer.java:845)
at org.jboss.serial.persister.RegularObjectPersister.readSlotWithFields(RegularObjectPersister.java:353)
at org.jboss.serial.persister.RegularObjectPersister.defaultRead(RegularObjectPersister.java:273)
at org.jboss.serial.persister.RegularObjectPersister.readData(RegularObjectPersister.java:241)
at org.jboss.serial.objectmetamodel.ObjectDescriptorFactory.readObjectDescriptionFromStreaming(ObjectDescriptorFactory.java:412)
at org.jboss.serial.objectmetamodel.ObjectDescriptorFactory.objectFromDescription(ObjectDescriptorFactory.java:82)
at org.jboss.serial.objectmetamodel.DataContainer$DataContainerInput.readObject(DataContainer.java:845)
at org.jboss.serial.io.MarshalledObjectForLocalCalls.get(MarshalledObjectForLocalCalls.java:60)
at org.jboss.ejb3.remoting.IsLocalInterceptor.invoke(IsLocalInterceptor.java:74)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
at org.jboss.ejb3.stateless.StatelessRemoteProxy.invoke(StatelessRemoteProxy.java:102)
... 28 more
Caused by: java.lang.ClassCastException: org.jboss.serial.finalcontainers.IntegerContainer
at org.jboss.serial.objectmetamodel.DataContainer$DataContainerInput.readUTF(DataContainer.java:1116)
... 42 more
The cause of the issue was that the customer had a class where it had re-implemented
readObject(java.io.ObjectInputStream stream) but had not re-implemented
writeObject(java.io.ObjectOutputStream stream). This is obviously a programming error on their side,
but it took a while to detect such stupid mistake.
The problem within JBoss Serialization was that because this class didn't have a writeObject()
reimplementation, it was a writing the class as a slot with fields, but when it came to reading it, it
was reading the class as a slot with method because readObject had been reimplemented. The
next time a slot with fields was read, the fields were mixed up.
To avoid these type of situations, I'd suggest that:
- JBS only writes as fields if *both* writeObject and readObject are missing. Right now, can't see a
situation where you'd implement one and not the other, thoughts?
--
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
16 years, 10 months
[JBoss JIRA] Created: (JBAOP-492) Duplicate _getAdvisor
by Flavia Rainone (JIRA)
Duplicate _getAdvisor
---------------------
Key: JBAOP-492
URL: http://jira.jboss.com/jira/browse/JBAOP-492
Project: JBoss AOP
Issue Type: Bug
Security Level: Public (Everyone can see)
Affects Versions: 2.0.0.CR1
Reporter: Flavia Rainone
Users are getting the following error message:
AOP Instrumentor failed to transform com.radware.insite.model.trafficredirection.farm.profile.FarmProfile
_$$_javassist_233
16:09:12,066 ERROR [STDERR] javassist.bytecode.DuplicateMemberException: duplicate method: _getAdvis
or in com.radware.insite.model.trafficre
This bug has been reproduced when using Hibernate with JBoss AOP. Refer to the forum link for more information.
--
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
16 years, 10 months