[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
18 years, 6 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
18 years, 6 months
[JBoss JIRA] Created: (JBRULES-1446) ClassCastException when iterating over an array using "from"
by Krzysztof Karski (JIRA)
ClassCastException when iterating over an array using "from"
------------------------------------------------------------
Key: JBRULES-1446
URL: http://jira.jboss.com/jira/browse/JBRULES-1446
Project: JBoss Drools
Issue Type: Bug
Security Level: Public (Everyone can see)
Affects Versions: 4.0.4
Environment: Windows XP
Reporter: Krzysztof Karski
To reproduce the error, please create the two following objects:
package test;
public class DomainObject {
private String message;
private int value;
private double value2;
public String getMessage() {
return message;
}
public void setMessage(String message) {
this.message = message;
}
public int getValue() {
return value;
}
public void setValue(int value) {
this.value = value;
}
public double getValue2() {
return value2;
}
public void setValue2(double value2) {
this.value2 = value2;
}
}
package test;
public class DomainObjectHolder {
DomainObject[] objects = new DomainObject[3];
public DomainObjectHolder(){
objects[0] = new DomainObject();
objects[0].setMessage("Message1");
objects[0].setValue(1);
objects[0].setValue2(2);
objects[1] = new DomainObject();
objects[1].setMessage("Message2");
objects[1].setValue(3);
objects[1].setValue2(4);
objects[2] = new DomainObject();
objects[2].setMessage("Message3");
objects[2].setValue(5);
objects[2].setValue2(6);
}
public DomainObject[] getObjects(){
return objects;
}
}
Here are a few rule that will trigger the ClassCastException:
rule "Test Rule"
when
$holder : DomainObjectHolder()
$object : DomainObject( $message : message) from $holder.objects;
then
System.out.println("Selected Object " + $message);
end
rule "Test Rule"
when
$holder : DomainObjectHolder()
$object : DomainObject( ) from $holder.objects;
then
System.out.println("Selected Object " + $object.getMessage());
end
This rule does not trigger the exception:
rule "Test Rule"
when
$holder : DomainObjectHolder()
$object : DomainObject( ) from $holder.objects;
then
System.out.println("Selected Object");
end
Here is the exception message:
java.lang.ClassCastException: [Ltest.DomainObject; cannot be cast to test.DomainObject
at org.drools.base.test.DomainObject9939622$getMessage.getValue(Unknown Source)
at org.drools.base.ClassFieldExtractor.getValue(ClassFieldExtractor.java:127)
at org.drools.rule.Declaration.getValue(Declaration.java:198)
at sequitem.quanteq.rules.exit.Rule_Test_Rule_0ConsequenceInvoker.evaluate(Rule_Test_Rule_0ConsequenceInvoker.java:17)
at org.drools.common.DefaultAgenda.fireActivation(DefaultAgenda.java:550)
at org.drools.common.DefaultAgenda.fireNextItem(DefaultAgenda.java:514)
at org.drools.common.AbstractWorkingMemory.fireAllRules(AbstractWorkingMemory.java:471)
at org.drools.common.AbstractWorkingMemory.fireAllRules(AbstractWorkingMemory.java:433)
at sequitem.quanteq.rules.engine.StatefulEngine.execute(StatefulEngine.java:98)
at sequitem.quanteq.rules.engine.StatefulEngine.execute(StatefulEngine.java:45)
at sequitem.quanteq.tradesystem.RuleBasedTradeSystem.onStart(RuleBasedTradeSystem.java:186)
at org.activequant.tradesystem.simple.TradeSystemBase.start(TradeSystemBase.java:242)
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:597)
at org.activequant.container.context.TradeSystemContextBase.invoke(TradeSystemContextBase.java:134)
at org.activequant.container.context.TradeSystemContextBase.access$2(TradeSystemContextBase.java:132)
at org.activequant.container.context.TradeSystemContextBase$2.start(TradeSystemContextBase.java:152)
at org.activequant.container.context.TradeSystemContextBase.start(TradeSystemContextBase.java:179)
at sequitem.quanteq.backtest.exits.StandardExistBackTest.main(StandardExistBackTest.java:36)
Exception in thread "main" java.lang.reflect.InvocationTargetException
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:597)
at org.activequant.container.context.TradeSystemContextBase.invoke(TradeSystemContextBase.java:134)
at org.activequant.container.context.TradeSystemContextBase.access$2(TradeSystemContextBase.java:132)
at org.activequant.container.context.TradeSystemContextBase$2.start(TradeSystemContextBase.java:152)
at org.activequant.container.context.TradeSystemContextBase.start(TradeSystemContextBase.java:179)
at sequitem.quanteq.backtest.exits.StandardExistBackTest.main(StandardExistBackTest.java:36)
Caused by: org.drools.spi.ConsequenceException: java.lang.ClassCastException: [Ltest.DomainObject; cannot be cast to test.DomainObject
at org.drools.base.DefaultConsequenceExceptionHandler.handleException(DefaultConsequenceExceptionHandler.java:14)
at org.drools.common.DefaultAgenda.fireActivation(DefaultAgenda.java:554)
at org.drools.common.DefaultAgenda.fireNextItem(DefaultAgenda.java:514)
at org.drools.common.AbstractWorkingMemory.fireAllRules(AbstractWorkingMemory.java:471)
at org.drools.common.AbstractWorkingMemory.fireAllRules(AbstractWorkingMemory.java:433)
at sequitem.quanteq.rules.engine.StatefulEngine.execute(StatefulEngine.java:98)
at sequitem.quanteq.rules.engine.StatefulEngine.execute(StatefulEngine.java:45)
at sequitem.quanteq.tradesystem.RuleBasedTradeSystem.onStart(RuleBasedTradeSystem.java:186)
at org.activequant.tradesystem.simple.TradeSystemBase.start(TradeSystemBase.java:242)
... 9 more
Caused by: java.lang.ClassCastException: [Ltest.DomainObject; cannot be cast to test.DomainObject
at org.drools.base.test.DomainObject9939622$getMessage.getValue(Unknown Source)
at org.drools.base.ClassFieldExtractor.getValue(ClassFieldExtractor.java:127)
at org.drools.rule.Declaration.getValue(Declaration.java:198)
at sequitem.quanteq.rules.exit.Rule_Test_Rule_0ConsequenceInvoker.evaluate(Rule_Test_Rule_0ConsequenceInvoker.java:17)
at org.drools.common.DefaultAgenda.fireActivation(DefaultAgenda.java:550)
... 16 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, 6 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
18 years, 6 months
[JBoss JIRA] Created: (JBMICROCONT-233) SchemaResolverDeployer.parse(VFSDeploymentUnit unit, VirtualFile file, T root) needs to validate file InputStream
by Scott M Stark (JIRA)
SchemaResolverDeployer.parse(VFSDeploymentUnit unit, VirtualFile file, T root) needs to validate file InputStream
-----------------------------------------------------------------------------------------------------------------
Key: JBMICROCONT-233
URL: http://jira.jboss.com/jira/browse/JBMICROCONT-233
Project: JBoss MicroContainer
Issue Type: Bug
Affects Versions: JBossMC-2.0.0.Beta10
Reporter: Scott M Stark
Assigned To: Scott M Stark
Its possible that the file passed into parse fails to return a non-null InputStream. This produces this type of uninformative error:
... 25 more
Caused by: java.net.MalformedURLException
at java.net.URL.<init>(URL.java:601)
at java.net.URL.<init>(URL.java:464)
at java.net.URL.<init>(URL.java:413)
at org.apache.xerces.impl.XMLEntityManager.setupCurrentEntity(Unknown Source)
at org.apache.xerces.impl.XMLVersionDetector.determineDocVersion(Unknown Source)
at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source)
at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source)
at org.apache.xerces.parsers.XMLParser.parse(Unknown Source)
at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown Source)
at org.apache.xerces.jaxp.SAXParserImpl$JAXPSAXParser.parse(Unknown Source)
at org.jboss.xb.binding.parser.sax.SaxJBossXBParser.parse(SaxJBossXBParser.java:189)
... 29 more
The file InputStream needs to be validated for null.
--
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, 6 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
18 years, 6 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
18 years, 6 months