[JBoss JIRA] (WFLY-5795) HA JMS Topic Subscriber of Colocated life backup symmetrical 2 nodes cluster violates Publish-Subscribe pattern.
by Jeff Mesnil (JIRA)
[ https://issues.jboss.org/browse/WFLY-5795?page=com.atlassian.jira.plugin.... ]
Jeff Mesnil resolved WFLY-5795.
-------------------------------
Fix Version/s: 10.0.0.Final
Resolution: Done
I've run your test agains WildFly 10.0.0.Final and it passes as expected:
{noformat}
Sent message: This is text message 0
Sent message: This is text message 1
Sent message: This is text message 2
Sent message: This is text message 3
Sent message: This is text message 4
Sent message: This is text message 5
Sent message: This is text message 6
Sent message: This is text message 7
Sent message: This is text message 8
Sent message: This is text message 9
0 Recieved message: This is text message 0 from node 0 from jms/topic/ClusterStateTopic
1 Recieved message: This is text message 1 from node 0 from jms/topic/ClusterStateTopic
2 Recieved message: This is text message 2 from node 0 from jms/topic/ClusterStateTopic
3 Recieved message: This is text message 3 from node 0 from jms/topic/ClusterStateTopic
4 Recieved message: This is text message 4 from node 0 from jms/topic/ClusterStateTopic
5 Recieved message: This is text message 5 from node 0 from jms/topic/ClusterStateTopic
6 Recieved message: This is text message 6 from node 0 from jms/topic/ClusterStateTopic
7 Recieved message: This is text message 7 from node 0 from jms/topic/ClusterStateTopic
8 Recieved message: This is text message 8 from node 0 from jms/topic/ClusterStateTopic
9 Recieved message: This is text message 9 from node 0 from jms/topic/ClusterStateTopic
0 Recieved message: This is text message 0 from node 1 from jms/topic/ClusterStateTopic
1 Recieved message: This is text message 1 from node 1 from jms/topic/ClusterStateTopic
2 Recieved message: This is text message 2 from node 1 from jms/topic/ClusterStateTopic
3 Recieved message: This is text message 3 from node 1 from jms/topic/ClusterStateTopic
4 Recieved message: This is text message 4 from node 1 from jms/topic/ClusterStateTopic
5 Recieved message: This is text message 5 from node 1 from jms/topic/ClusterStateTopic
6 Recieved message: This is text message 6 from node 1 from jms/topic/ClusterStateTopic
7 Recieved message: This is text message 7 from node 1 from jms/topic/ClusterStateTopic
8 Recieved message: This is text message 8 from node 1 from jms/topic/ClusterStateTopic
9 Recieved message: This is text message 9 from node 1 from jms/topic/ClusterStateTopic
example complete
#####################
### SUCCESS! ###
#####################
{noformat}
Note that I have a different domain configuration with my 2 servers on the same host but I don't think it has any impact on your test.
> HA JMS Topic Subscriber of Colocated life backup symmetrical 2 nodes cluster violates Publish-Subscribe pattern.
> ----------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-5795
> URL: https://issues.jboss.org/browse/WFLY-5795
> Project: WildFly
> Issue Type: Bug
> Components: JMS
> Affects Versions: 10.0.0.CR4
> Environment: 2 node symmetrical colocated life backup cluster (domain mode). Configuration (domain.xml, host.xml) provided as attachment.
> Reporter: Michal Sudra
> Assignee: Jeff Mesnil
> Priority: Critical
> Fix For: 10.0.0.Final
>
> Attachments: ClusteredTopicTest.java, domain.xml, host-slave.xml, host.xml
>
>
> Test Client is producing 10 messages on topic on node 1 and 2 consumers connected to node 1 and the other to node 2 are then consuming the messages.
> Expectation: Every consumer receives 10 Messages.
> Result of test: Consumer connected to node 1 is only getting every second message. Consumer connected to node 2 is receiving all 10 messages:
> Output of test program:
> Sent message: This is text message 0
> Sent message: This is text message 1
> Sent message: This is text message 2
> Sent message: This is text message 3
> Sent message: This is text message 4
> Sent message: This is text message 5
> Sent message: This is text message 6
> Sent message: This is text message 7
> Sent message: This is text message 8
> Sent message: This is text message 9
> 0 Recieved message: This is text message 0 from node 0 from java:/jms/topic/ClusterStateTopic
> 1 Recieved message: This is text message 2 from node 0 from java:/jms/topic/ClusterStateTopic
> 2 Recieved message: This is text message 4 from node 0 from java:/jms/topic/ClusterStateTopic
> 3 Recieved message: This is text message 6 from node 0 from java:/jms/topic/ClusterStateTopic
> 4 Recieved message: This is text message 8 from node 0 from java:/jms/topic/ClusterStateTopic
> 5 error receiving message from node 0
> 6 error receiving message from node 0
> 7 error receiving message from node 0
> 8 error receiving message from node 0
> 9 error receiving message from node 0
> 0 Recieved message: This is text message 0 from node 1 from java:/jms/topic/ClusterStateTopic
> 1 Recieved message: This is text message 1 from node 1 from java:/jms/topic/ClusterStateTopic
> 2 Recieved message: This is text message 2 from node 1 from java:/jms/topic/ClusterStateTopic
> 3 Recieved message: This is text message 3 from node 1 from java:/jms/topic/ClusterStateTopic
> 4 Recieved message: This is text message 4 from node 1 from java:/jms/topic/ClusterStateTopic
> 5 Recieved message: This is text message 5 from node 1 from java:/jms/topic/ClusterStateTopic
> 6 Recieved message: This is text message 6 from node 1 from java:/jms/topic/ClusterStateTopic
> 7 Recieved message: This is text message 7 from node 1 from java:/jms/topic/ClusterStateTopic
> 8 Recieved message: This is text message 8 from node 1 from java:/jms/topic/ClusterStateTopic
> 9 Recieved message: This is text message 9 from node 1 from java:/jms/topic/ClusterStateTopic
> The test program is added and the 2 node names are given as parameters for main.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 2 months
[JBoss JIRA] (WFLY-5068) Console don't show web services deployed in jar
by Harald Pehl (JIRA)
[ https://issues.jboss.org/browse/WFLY-5068?page=com.atlassian.jira.plugin.... ]
Harald Pehl reassigned WFLY-5068:
---------------------------------
Assignee: Harald Pehl (was: Heiko Braun)
> Console don't show web services deployed in jar
> -----------------------------------------------
>
> Key: WFLY-5068
> URL: https://issues.jboss.org/browse/WFLY-5068
> Project: WildFly
> Issue Type: Bug
> Components: Web Console
> Affects Versions: 8.2.0.Final, 9.0.1.Final
> Reporter: Manuel Aznar Pérez
> Assignee: Harald Pehl
> Priority: Minor
> Attachments: Captura de pantalla de 2015-08-07 09-09-13.png
>
>
> - I see webservices deployed at log console:
> 08:40:20,849 INFO [org.jboss.ws.cxf.metadata] (MSC service thread 1-8) JBWS024061: Adding service endpoint metadata: id=TOCService
> address=http://localhost.localdomain:10080/comet-iop/TOCService
> implementor=carreras.comet.iop.cgl.TOCService
> serviceName={http://cgl.iop.comet.carreras/}TOCServiceService
> portName={http://cgl.iop.comet.carreras/}TOCServicePort
> annotationWsdlLocation=null
> wsdlLocationOverride=null
> - From jboss-cli view endpoints:
> [standalone@127.0.0.1:11990 /] /deployment=comet-ear-1.0-SNAPSHOT.ear/subdeployment=comet-iop-1.0-SNAPSHOT.jar/subsystem=webservices/endpoint="*":read-resource
> {
> "outcome" => "success",
> "result" => [
> {
> "address" => [
> ("deployment" => "comet-ear-1.0-SNAPSHOT.ear"),
> ("subdeployment" => "comet-iop-1.0-SNAPSHOT.jar"),
> ("subsystem" => "webservices"),
> ("endpoint" => "comet-iop%3ATOCService")
> ],
> "outcome" => "success",
> "result" => {
> "class" => "carreras.comet.iop.cgl.TOCService",
> "context" => "comet-iop",
> "name" => "TOCService",
> "type" => "JAXWS_EJB3",
> "wsdl-url" => "http://localhost.localdomain:10080/comet-iop/TOCService?wsdl"
> }
> }
> ]
> }
> - But in admin console "Runtime/System Status/Subsystems/Webservices" don't show endpoints deployed. I attach screenshot.
> - I tested at WF 8.2.0 and WF 9.0.1.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 2 months
[JBoss JIRA] (DROOLS-1053) Change date formats for JSON representations used in the REST API
by William Siqueira (JIRA)
William Siqueira created DROOLS-1053:
----------------------------------------
Summary: Change date formats for JSON representations used in the REST API
Key: DROOLS-1053
URL: https://issues.jboss.org/browse/DROOLS-1053
Project: Drools
Issue Type: Feature Request
Components: kie server
Affects Versions: 6.3.0.Final
Environment: jBPM 6.3 running on Wildfly 8.2
Reporter: William Siqueira
Assignee: Edson Tirelli
The format for dates are are using milliseconds form, for example:
{code:javascript}
{
"request-instance-id" : 4,
"request-status" : "QUEUED",
"request-message" : "Ready to execute",
"request-retries" : 3,
"request-executions" : 0,
"request-command" : "org.jbpm.executor.commands.PrintOutCommand",
"request-scheduled-date" : 1455069600000
}
{code}
The problem with this format is that it is not readable and might confuse users using other ways to communicate with the kie server than using its REST API.
The suggested solution is use a Jackson object mapper to configure the desired date format. This is better explained in this article:
http://wiki.fasterxml.com/JacksonFAQDateHandling
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 2 months
[JBoss JIRA] (WFLY-6138) implemtentation of java.rmi.server.UnicastRemoteObject always sent as value when remote jndi lookup
by Bartosz Baranowski (JIRA)
Bartosz Baranowski created WFLY-6138:
----------------------------------------
Summary: implemtentation of java.rmi.server.UnicastRemoteObject always sent as value when remote jndi lookup
Key: WFLY-6138
URL: https://issues.jboss.org/browse/WFLY-6138
Project: WildFly
Issue Type: Feature Request
Components: Naming
Reporter: Bartosz Baranowski
We have an legacy j2ee app that runs on many application servers. We are trying to port it to AS 7.x, but found one issue.
We use java rmi. Our remote interface implementation (ImplClass) extends java.rmi.server.UnicastRemoteObject. We have a singleton instance of this class in our app that is initialized at the start of the application and then bound into the jndi tree.
For this, we use a context created with org.jboss.as.naming.InitialContextFactory as java.naming.factory.initial
We bind to "java:jboss/exported/" prefix and it works for us for all the other simple values but not for our ImplClass.
When doing lookup on the server, the jndi lookup returns correctly an instance that was created on the server pointing to local connection, but when doing lookup on client with this context
org.jboss.naming.remote.client.InitialContextFactory
remote://localhost:port/
we retrieve the same instance as on the server that point to local connection. Hence it seems, that our object is always copied and sent as a value to the client instead of sending the remote proxy which can be used on the client.
The same code works on jboss AS 5.1 (when using jnp) and also on netweaver, websphere and weblogic when using their context implementations.
It would be great if this could be also fixed in jboss as 7.x.
Known workaround: Use a java.rmi.registry.Registry on the server for registering proxy instead of jndi.
According to this site (and possibly some spec)
http://www.javaworld.com/article/2076234/soa/get-smart-with-proxies-and-r...
an object should be passed by value if and only if it is implementing Serializable interface, but the current implementation in jboss as 7.x does not respect this and always passes objects by value.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 2 months
[JBoss JIRA] (WFLY-6137) org.dom4j.DocumentFactory cannot be cast to org.dom4j.DocumentFactory
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFLY-6137?page=com.atlassian.jira.plugin.... ]
Stuart Douglas resolved WFLY-6137.
----------------------------------
Resolution: Rejected
These issues can be worked around by setting the local-last flag in jboss-deployment-structure.xml, however in general this is considered to be a bug in your deployment. If you bundle Java EE components that should be provided by the application server you will get problems (you should use the maven 'provided' scope if you need something present at compile time).
> org.dom4j.DocumentFactory cannot be cast to org.dom4j.DocumentFactory
> ---------------------------------------------------------------------
>
> Key: WFLY-6137
> URL: https://issues.jboss.org/browse/WFLY-6137
> Project: WildFly
> Issue Type: Bug
> Components: Application Client, EE, JPA / Hibernate, Server
> Affects Versions: 10.0.0.Final
> Reporter: Karl Nicholas
> Assignee: Stuart Douglas
>
> Including hibernate-entitymanager (up to version 5.0.7.Final) into a project causes dom4j-1.6.1.jar to be included which causes the application to fail to deploy in Wildfly 10.0.0.Final.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 2 months
[JBoss JIRA] (DROOLS-1008) KieServer to update container for SNAPSHOT kjar
by Andrew Collins (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1008?page=com.atlassian.jira.plugi... ]
Andrew Collins commented on DROOLS-1008:
----------------------------------------
I updated the description. Please let me know if it still needs clarification.
> KieServer to update container for SNAPSHOT kjar
> -----------------------------------------------
>
> Key: DROOLS-1008
> URL: https://issues.jboss.org/browse/DROOLS-1008
> Project: Drools
> Issue Type: Feature Request
> Components: kie server
> Affects Versions: 6.2.0.Final, 6.3.0.Final
> Reporter: Andrew Collins
> Assignee: Mario Fusco
> Attachments: snapshot_kjar_reproducer.patch
>
>
> General:
> When a kjar has a snapshot version, kie-server will not react to new snapshot versions deployed to a remote artifact repository. The remote artifact repository is only queried the first time after JVM startup, regardless of settings.xml snapshot updatePolicy setting. Retrieving a new snapshot version is only possible through use of KieScanner.scanNow() or recycling the JVM, which will both fetch the new artifact from the remote repository and reload the kmodule in the KieServer JVM.
> Steps to reproduce:
> * KieServer and Business Central deployed to separate JVMs, pointing to independent maven repositories. Snapshot updatePolicy should be "always" in KieServer settings.xml.
> * Deploy new kjar snapshot from Business Central to remote artifactory. (unique version "1")
> * Start KieServer (verify new snapshot version is pulled from remote)
> * Deploy new kjar snapnshot. (unique version "2")
> Expected behavior:
> * Creating a new container, or invoking updateReleaseId() on existing container will pull latest snapshot from remote artifactory.
> Actual Behavior
> * Creating a new container, or invoking updateReleaseId() on existing container, does not query remote artifactory for latest snapshots.
> Workaround:
> * Forcing a KieScanner.scanNow() will fetch new snapshot from remote artifactory.
> * Or, restarting KieScanner JVM will fetch new snapshot from remote artifactory.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 2 months
[JBoss JIRA] (DROOLS-355) Do not import com.sun.tools.xjc in drools-core and drools-compiler to fix drools on Karaff/Fuse and/or Java 9
by Marco Rietveld (JIRA)
[ https://issues.jboss.org/browse/DROOLS-355?page=com.atlassian.jira.plugin... ]
Marco Rietveld reassigned DROOLS-355:
-------------------------------------
Assignee: Marco Rietveld (was: Mario Fusco)
> Do not import com.sun.tools.xjc in drools-core and drools-compiler to fix drools on Karaff/Fuse and/or Java 9
> -------------------------------------------------------------------------------------------------------------
>
> Key: DROOLS-355
> URL: https://issues.jboss.org/browse/DROOLS-355
> Project: Drools
> Issue Type: Task
> Affects Versions: 6.0.0.Final
> Reporter: Geoffrey De Smet
> Assignee: Marco Rietveld
>
> By importing com.sun.tools.xjc, 3 problems arise:
> * OSGi and Karaf trip over it.
> {code}
> [WARNING] No export found to match com.sun.tools.xjc (imported by mvn:org.drools/drools-core/6.0.0.Final)
> {code}
> * JDK 9 will break any java app that uses com.sun.* classes. See Mark Reinhold's Jigsaw presentation at devoxxBE 2013.
> * IBM JDK's etc don't have com.sun.* classes. Why don't they trip over this?
> Why do we have those imports in the first place? Looks like code for old JAXB code - which is hopefully stale now.
> Where do we use it?
> {code}
> Targets
> String 'com.sun.tools.xjc'
> Found usages (38 usages found)
> drools-compiler (7 usages found)
> /home/gdesmet/projects/jboss/droolsjbpm/drools/drools-compiler (1 usage found)
> pom.xml (1 usage found)
> (246: 15) com.sun.tools.xjc.*;resolution:=optional,
> org.drools.compiler.builder.impl (1 usage found)
> KnowledgeBuilderFactoryServiceImpl.java (1 usage found)
> (18: 8) import com.sun.tools.xjc.Options;
> org.drools.compiler.runtime.pipeline.impl (5 usages found)
> DroolsJaxbHelperProviderImpl.java (5 usages found)
> (77: 8) import com.sun.tools.xjc.BadCommandLineException;
> (78: 8) import com.sun.tools.xjc.ErrorReceiver;
> (79: 8) import com.sun.tools.xjc.ModelLoader;
> (80: 8) import com.sun.tools.xjc.Options;
> (81: 8) import com.sun.tools.xjc.model.Model;
> drools-core (2 usages found)
> org.drools.core.builder.conf.impl (2 usages found)
> JaxbConfigurationImpl.java (2 usages found)
> (28: 8) import com.sun.tools.xjc.Language;
> (34: 8) import com.sun.tools.xjc.Options;
> kie-internal (6 usages found)
> /home/gdesmet/projects/jboss/droolsjbpm/droolsjbpm-knowledge/kie-internal (1 usage found)
> pom.xml (1 usage found)
> (27: 15) com.sun.tools.xjc;resolution:=optional,
> org.kie.internal.builder (3 usages found)
> JaxbConfiguration.java (1 usage found)
> (23: 8) import com.sun.tools.xjc.Options;
> KnowledgeBuilderFactory.java (1 usage found)
> (24: 8) import com.sun.tools.xjc.Options;
> KnowledgeBuilderFactoryService.java (1 usage found)
> (24: 8) import com.sun.tools.xjc.Options;
> org.kie.internal.builder.help (2 usages found)
> DroolsJaxbHelperProvider.java (1 usage found)
> (29: 8) import com.sun.tools.xjc.Options;
> KnowledgeBuilderHelper.java (1 usage found)
> (30: 8) import com.sun.tools.xjc.Options;
> knowledge-api (8 usages found)
> org.drools.builder (3 usages found)
> JaxbConfiguration.java (1 usage found)
> (21: 8) import com.sun.tools.xjc.Options;
> KnowledgeBuilderFactory.java (1 usage found)
> (24: 8) import com.sun.tools.xjc.Options;
> KnowledgeBuilderFactoryService.java (1 usage found)
> (24: 8) import com.sun.tools.xjc.Options;
> org.drools.builder.help (3 usages found)
> DroolsJaxbHelperProvider.java (1 usage found)
> (29: 8) import com.sun.tools.xjc.Options;
> KnowledgeBuilderHelper.java (2 usages found)
> (32: 8) import com.sun.tools.xjc.Language;
> (33: 8) import com.sun.tools.xjc.Options;
> org.drools.impl (1 usage found)
> KnowledgeBuilderFactoryServiceImpl.java (1 usage found)
> (16: 8) import com.sun.tools.xjc.Options;
> org.drools.impl.adapters (1 usage found)
> JaxbConfigurationAdapter.java (1 usage found)
> (3: 8) import com.sun.tools.xjc.Options;
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 2 months
[JBoss JIRA] (WFLY-6137) org.dom4j.DocumentFactory cannot be cast to org.dom4j.DocumentFactory
by Karl Nicholas (JIRA)
[ https://issues.jboss.org/browse/WFLY-6137?page=com.atlassian.jira.plugin.... ]
Karl Nicholas updated WFLY-6137:
--------------------------------
Description: Including hibernate-entitymanager (up to version 5.0.7.Final) into a project causes dom4j-1.6.1.jar which causes the application to fail to deploy in Wildfly 10.0.0.Final.
> org.dom4j.DocumentFactory cannot be cast to org.dom4j.DocumentFactory
> ---------------------------------------------------------------------
>
> Key: WFLY-6137
> URL: https://issues.jboss.org/browse/WFLY-6137
> Project: WildFly
> Issue Type: Bug
> Components: Application Client, EE, JPA / Hibernate, Server
> Affects Versions: 10.0.0.Final
> Reporter: Karl Nicholas
> Assignee: Stuart Douglas
>
> Including hibernate-entitymanager (up to version 5.0.7.Final) into a project causes dom4j-1.6.1.jar which causes the application to fail to deploy in Wildfly 10.0.0.Final.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 2 months