[JBoss JIRA] Created: (JBCLUSTER-186) Implementations of Invoker should implement equals as an equality check rather than relying on Object.equals, this is important for cluster fail-over support
by Scott Marlow (JIRA)
Implementations of Invoker should implement equals as an equality check rather than relying on Object.equals, this is important for cluster fail-over support
-------------------------------------------------------------------------------------------------------------------------------------------------------------
Key: JBCLUSTER-186
URL: http://jira.jboss.com/jira/browse/JBCLUSTER-186
Project: JBoss Clustering
Issue Type: Bug
Security Level: Public (Everyone can see)
Environment: JBoss as 4.0.4, although this seems to happen in 4.5 + 5.x as well.
Reporter: Scott Marlow
Assigned To: Scott Marlow
Priority: Minor
Part of how JRMPInvokerProxyHA handles fail-over includes removing the reference to the node that left the cluster. However, the dead node is not removed as an equality check is not implemented by certain Invoker implementations.
The relevant code in JRMPInvokerProxyHA is
protected void removeDeadTarget(Object target)
{
if (this.familyClusterInfo != null)
this.familyClusterInfo.removeDeadTarget (target);
}
The code in familyClusterInfo is:
public ArrayList removeDeadTarget(Object target)
{
synchronized (this)
{
ArrayList tmp = (ArrayList) targets.clone();
tmp.remove (target);
this.targets = tmp;
this.isViewMembersInSyncWithViewId = false;
}
return this.targets;
}
Since, we didn't include an equals test in many of the different Invoker implementations, the above "tmp.remove(target)" operation fails. The reason for the failure is due to the "targets" ArrayList changing on every invocation (to reflect the current cluster server membership list), a new "targets" is created (so of course comparing references later will not work.)
A similar problem occurs with the EJB2 load balancers after a cluster membership changes.
I think that these issues will be solved by implementing an equals test in the different invokers that can handle equality testing.
PooledInvokerProxy should implement equals based on ServerAddress.
--
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
13 years, 8 months
[JBoss JIRA] Created: (JGRP-371) TCP_NIO with SSL
by Bela Ban (JIRA)
TCP_NIO with SSL
----------------
Key: JGRP-371
URL: http://jira.jboss.com/jira/browse/JGRP-371
Project: JGroups
Issue Type: Feature Request
Affects Versions: 2.4
Reporter: Bela Ban
Assigned To: Bela Ban
Fix For: 2.5
Attachments: ssl-nio.jar
>From Hal Hildebrand:
Attached are the sources to allow a new protocol stack which uses SSL over
NIO. This protocol stack element provides security and authentication
(using client side authentication) for a JGroups TCP stack using NIO.
This required two minor modifications in the ConnectionTableNIO class.
These modifications allow one to subclass to create a connection table which
uses SSL for the connections. Finally, there is a new protocol stack
element, SSL_NIO, which one can add to a stack to make use of it.
Regardless of whether this makes it into the codeline of JGroups, it would
be nice to have the changes to ConnectionTableNIO make it into the mainline,
as I currently have to overwrite the original class to easily implement this
- the last thing I want to do is fork ConnectionTableNIO ;) I'd rather just
subclass it. The mods are simple and innocuous (marked with "HSH").
Right now, the SSL_NIO needs to be configured with an SSLSocketFactory. I
didn't bother with integrating with the normal JGroups mechanism using
properties from the configuration because I consider it inherently insecure
to ensconce my passwords in configuration files. But the changes to enable
this are straight forward. Currently, to configure the factory for the
protocol layer, do something like the following before connecting your
channel:
// Construct your Jchannel
JChannel jchannel = ...
// Access your protocol stack
ProtocolStack protocolStack = jchannel.getProtocolStack();
// Retrieve the SSL_NIO protocol layer
SSL_NIO protocol = (SSL_NIO) protocolStack.findProtocol("SSL_NIO");
// Create your SSLSocketFactory
SSLSocketFactory socketFactory = ....
// Set up the protocol
protocol. SetSocketFactory(socketFactory);
// Connect your channel
jchannel.connnect("my-group");
Cheers.
--
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
13 years, 8 months
[JBoss JIRA] Created: (JBAS-8751) javax.faces.INTERPRET_EMPTY_STRING_SUBMITTED_VALUES_AS_NULL not honored
by Nicklas Karlsson (JIRA)
javax.faces.INTERPRET_EMPTY_STRING_SUBMITTED_VALUES_AS_NULL not honored
-----------------------------------------------------------------------
Key: JBAS-8751
URL: https://issues.jboss.org/browse/JBAS-8751
Project: JBoss Application Server
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: JSF
Affects Versions: 6.0.0.CR1
Reporter: Nicklas Karlsson
Assignee: Stan Silvert
Given a model like
@javax.enterprise.inject.Model
public class Model
{
private String data;
public String getData()
{
return data;
}
public void setData(String data)
{
System.out.println("set data to " + data);
this.data = data;
}
}
and a view like
<h:form>
<h:inputText id="field" value="#{model.data}"/>
<h:commandButton value="!"/>
</h:form>
an empty value is submitted even with
<context-param>
<param-name>javax.faces.INTERPRET_EMPTY_STRING_SUBMITTED_VALUES_AS_NULL</param-name>
<param-value>true</param-value>
</context-param>
Debugging the application shows that the emptyStringIsNull of the component is true.
even with a @FacesConverter(forClass=String.class) which is correctly run and doing a setSubmittedValue(null), the model still sees a "" instead of a null
Tested to work correctly on a GF 3.0.1
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 8 months
[JBoss JIRA] Created: (JBRULES-3033) java.lang.ClassCastException when change rule condition and declarative facts/events are used
by Federico Weisse (JIRA)
java.lang.ClassCastException when change rule condition and declarative facts/events are used
---------------------------------------------------------------------------------------------
Key: JBRULES-3033
URL: https://issues.jboss.org/browse/JBRULES-3033
Project: Drools
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: drools-core
Affects Versions: 5.1.1.FINAL
Reporter: Federico Weisse
Assignee: Mark Proctor
We have drl files where we declare events. we use declarative events (there is no java class AlertaPosManual)
(like this)
declare AlertaPosManual
@role (event)
@expires(10s)
idTerminal : java.lang.String
end
We use a StatefullSession for fusion cep and we need that changes in rules refresh the kBase in runtime. But when a rule condition changes this exception in throw
Exception in thread "Thread-2" java.lang.ClassCastException: com.sample.ConsumoPostManual cannot be cast to com.sample.ConsumoPostManual
at org.drools.base.com.sample.ConsumoPostManual17710704$getIdTerminal.getValue(Unknown Source)
at org.drools.base.extractors.BaseObjectClassFieldReader.getHashCode(BaseObjectClassFieldReader.java:192)
at org.drools.base.ClassFieldReader.getHashCode(ClassFieldReader.java:193)
at org.drools.core.util.AbstractHashTable$SingleIndex.hashCodeOf(AbstractHashTable.java:582)
at org.drools.core.util.RightTupleIndexHashTable.getOrCreate(RightTupleIndexHashTable.java:360)
at org.drools.core.util.RightTupleIndexHashTable.add(RightTupleIndexHashTable.java:243)
at org.drools.reteoo.AccumulateNode.assertObject(AccumulateNode.java:246)
at org.drools.reteoo.ObjectTypeNode.updateSink(ObjectTypeNode.java:276)
at org.drools.reteoo.PropagationQueuingNode.updateSink(PropagationQueuingNode.java:111)
at org.drools.reteoo.BetaNode.attach(BetaNode.java:214)
at org.drools.reteoo.builder.BuildUtils.attachNode(BuildUtils.java:151)
at org.drools.reteoo.builder.CollectBuilder.build(CollectBuilder.java:114)
at org.drools.reteoo.builder.PatternBuilder.attachPattern(PatternBuilder.java:111)
at org.drools.reteoo.builder.PatternBuilder.build(PatternBuilder.java:72)
at org.drools.reteoo.builder.GroupElementBuilder$AndBuilder.build(GroupElementBuilder.java:132)
at org.drools.reteoo.builder.GroupElementBuilder.build(GroupElementBuilder.java:78)
at org.drools.reteoo.builder.ReteooRuleBuilder.addSubRule(ReteooRuleBuilder.java:155)
at org.drools.reteoo.builder.ReteooRuleBuilder.addRule(ReteooRuleBuilder.java:128)
at org.drools.reteoo.ReteooBuilder.addRule(ReteooBuilder.java:117)
at org.drools.reteoo.ReteooRuleBase.addRule(ReteooRuleBase.java:428)
at org.drools.common.AbstractRuleBase.addRule(AbstractRuleBase.java:721)
at org.drools.common.AbstractRuleBase.addPackages(AbstractRuleBase.java:545)
at org.drools.reteoo.ReteooRuleBase.addPackages(ReteooRuleBase.java:445)
at org.drools.reteoo.ReteooRuleBase.addPackage(ReteooRuleBase.java:452)
at org.drools.agent.impl.KnowledgeAgentImpl.addResourcesToKnowledgeBase(KnowledgeAgentImpl.java:937)
at org.drools.agent.impl.KnowledgeAgentImpl.incrementalBuildResources(KnowledgeAgentImpl.java:821)
at org.drools.agent.impl.KnowledgeAgentImpl.buildKnowledgeBase(KnowledgeAgentImpl.java:586)
at org.drools.agent.impl.KnowledgeAgentImpl.applyChangeSet(KnowledgeAgentImpl.java:185)
at org.drools.agent.impl.KnowledgeAgentImpl$ChangeSetNotificationDetector.run(KnowledgeAgentImpl.java:1106)
at java.lang.Thread.run(Thread.java:619)
I think that's because the statefullSession has an instance of
com.sample.ConsumoPostManual (loaded with the classLoader
org.drools.rule.JavaDialectRuntimeData$PackageClassLoader@1218b25) But when
the kBase is regenerated and the class com.sample.ConsumoPostManual to, the
classLoader org.drools.rule.JavaDialectRuntimeData is recreated so there
are two versions of the class com.sample.ConsumoPostManual in differents
classLoader (one in the statefullSession and the other in the kBase)
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 8 months
[JBoss JIRA] Created: (JBRULES-2962) Knowledge Agent rebuilding KnowledgeBase with scanner/notifier does not work with declared facts
by Ross Hall (JIRA)
Knowledge Agent rebuilding KnowledgeBase with scanner/notifier does not work with declared facts
------------------------------------------------------------------------------------------------
Key: JBRULES-2962
URL: https://issues.jboss.org/browse/JBRULES-2962
Project: Drools
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: drools-core
Affects Versions: 5.2.0.M1, 5.1.1.FINAL
Reporter: Ross Hall
Assignee: Mark Proctor
When reloading rules in a KnowledgeAgent declared facts will cause ClassCastExceptions when new-instance is set to false. When new-instance is set to true, the KnowledgeBase is rebuilt, however declared facts are not recognized and associated rules will not fire. Rules not using declared facts will fire normally. Using POJOs works fine.
In both cases the KnowledgeAgent will build the rule base the first time, the issue only seems to occur when the changeset resources are modified and are detected by the resource notifier and scanner.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 8 months
[JBoss JIRA] Created: (AS7-1613) NPE in TranslatingSuspendableChannel.scheduleReadTask
by Ondrej Zizka (JIRA)
NPE in TranslatingSuspendableChannel.scheduleReadTask
-----------------------------------------------------
Key: AS7-1613
URL: https://issues.jboss.org/browse/AS7-1613
Project: Application Server 7
Issue Type: Bug
Components: CLI
Affects Versions: 7.0.1.Final
Reporter: Ondrej Zizka
Assignee: Alexey Loubyansky
Happened after a while of inactivity (if that matters).
[standalone@localhost:9999 interface=public] cd ..
[standalone@localhost:9999 /] cd ..
[standalone@localhost:9999 /] ls
extension core-service path subsystem system-property deployment interface socket-binding-group
[standalone@localhost:9999 /] Exception in thread "pool-1-thread-21" java.lang.NullPointerException
at org.xnio.channels.TranslatingSuspendableChannel.scheduleReadTask(TranslatingSuspendableChannel.java:253)
at org.xnio.channels.TranslatingSuspendableChannel.resumeReads(TranslatingSuspendableChannel.java:233)
at org.jboss.remoting3.remote.ClientConnectionOpenListener$Authentication$2.run(ClientConnectionOpenListener.java:498)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:662)
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 8 months
[JBoss JIRA] Created: (JBRULES-2791) Spring's JpaTransactionManager should be used instead of both: DroolsSpringTransactionManager and DroolsSpringJpaManager
by Anatoly Polinsky (JIRA)
Spring's JpaTransactionManager should be used instead of both: DroolsSpringTransactionManager and DroolsSpringJpaManager
------------------------------------------------------------------------------------------------------------------------
Key: JBRULES-2791
URL: https://jira.jboss.org/browse/JBRULES-2791
Project: Drools
Issue Type: Bug
Security Level: Public (Everyone can see)
Affects Versions: 5.1.1.FINAL, FUTURE
Environment: Spring Based Applications
Reporter: Anatoly Polinsky
Assignee: Mark Proctor
Instead of having two different components: "DroolsSpringTransactionManager" and "DroolsSpringJpaManager" that aim to do the work of "org.springframework.orm.jpa.JpaTransactionManager", and trying to fit a JTA model into it, the Spring's "JpaTransactionManager" itself should be used.
And instead of manually managing and constantly getting references to a "proper entity manager" from JpaManger within a SingleSessionCommandService, a @PersistenceContext should be injected. This will decouple SingleSessionCommandService from JpaManager interface, and will allow _any_ JPA provider to inject an entity manager.
It has more benefits, such as trust in underline JPA providers ( e.g. Hibernate ) and Spring Transaction Management capabilities to manage the process that they are actually excellent at.
/Anatoly
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 8 months