[Design of Messaging on JBoss (Messaging/JBoss)] - Examples failing for JBM 1.4.1.GA on JBAS 4.2.2.GA
by rtm333
I'm trying to upgrade to JBM 1.4.1.GA on JBoss AS 4.2.2.GA.
The server starts up ok, but I had no success with running the JBM examples for validation. Most of the jar files (most notably jboss-messaging-client.jar) are not found.
It seems to me that the classpath has been changed to reflect the JBoss 5 structure. When I modify the classpath in build.xml to point to the existing jars, the topic test fails with
| run:
| [java] Topic /topic/testTopic exists
| [java] java.lang.IllegalArgumentException: Wrong target. class org.jboss.jms.client.delegate.ClientConnectionFactoryDelegate for public org.jboss.jms.delegate.CreateConnectionResult org.jboss.jms.client.delegate.ClientConnectionFactoryDelegate.createConnectionDelegate(java.lang.String,java.lang.String,int) throws javax.jms.JMSException
| [java] at org.jboss.aop.joinpoint.MethodInvocation.handleErrors(MethodInvocation.java:141)
| [java] at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:116)
| [java] at org.jboss.jms.client.container.StateCreationAspect.handleCreateConnectionDelegate(StateCreationAspect.java:81)
| [java] at org.jboss.aop.advice.org.jboss.jms.client.container.StateCreationAspect0.invoke(StateCreationAspect0.java)
| [java] at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
| [java] at org.jboss.jms.client.delegate.ClientConnectionFactoryDelegate.createConnectionDelegate(ClientConnectionFactoryDelegate.java)
| [java] at org.jboss.jms.client.JBossConnectionFactory.createConnectionInternal(JBossConnectionFactory.java:205)
| [java] at org.jboss.jms.client.JBossConnectionFactory.createConnection(JBossConnectionFactory.java:87)
| [java]
| [java] at org.jboss.jms.client.JBossConnectionFactory.createConnection(JBossConnectionFactory.java:82)
| [java] at org.jboss.example.jms.topic.TopicExample.example(TopicExample.java:67)
| [java] Please verify if you have access to the server. If you are using JBossEAP maybe you don't have security access
| [java] at org.jboss.example.jms.common.ExampleSupport.run(ExampleSupport.java:147)
| [java] at org.jboss.example.jms.topic.TopicExample.main(TopicExample.java:132)
| [java]
| [java] #####################
| [java] ### FAILURE! ###
| [java] #####################
|
Any hints welcome.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4195014#4195014
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4195014
17 years, 4 months
[Design of Messaging on JBoss (Messaging/JBoss)] - Management code now requires an always-on INVM acceptor
by jmesnil
I've refactored the management code to make it work on a cluster of JBM2 nodes.
Now, all management operations use core messages which are replicated on the live & backup nodes to ensure that their states are correctly replicated (e.g. creation on a queue on both nodes, etc.)
To make it simple to manage JBM, we still expose the management operations through JMX MBeans. These mbeans implementations are simple facade which creates a corresponding Core message, sent it to a well-known "management address" and wait for the reply (see top class ).
We use a INVM connector to connect to the server (since the core message is sent from *inside* the server).
To make the code more generic, JMX operation invocations *always* goes through a replicated core message wether the node is replicated or not.
This implies that the server *must* always have a INVM acceptor ready to accept the core message from the management code.
I hesitated to have a switch for every management operation implementation (if the node is not replicated, invokes directly, else use a replicated core message) but I stick to a single implementation (INVM connection code path is straightforward enough) to make the code more uniform.
For now, I have not changed the server configuration. This means that the user must explicitely add a INVM acceptor if he wants to be able to manage the server using JMX.
To make it more user-friendly, I'll add the creation of the INVM acceptor when the user configuration set jmx-enable to true.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4195005#4195005
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4195005
17 years, 4 months
[Design of JBoss jBPM] - task component interface comments
by tom.baeyens＠jboss.com
Hi Alejandro,
1) i'ld like to make the user provided taskId optional. so i think it would be good to have an extra method
TaskService.newTask()
that creates a new task without id. upon saving such a task, the command will detect this and automatically assign an id based on the DB primary key that has been generated by the DB after saving it. That way you don't force users to think of how they are going to obtain a unique id if they just want to add a task.
2) all the setters in the task could return the task itself. also a save method could be added to the task that delegates to the saveTask of the service it came from. then you could get shorter, more readable task creations like this:
taskService.newTask()
| .setName("Do laundry")
| .setDueDate(tomorrow)
| .setAssignee("johndoe")
| .save();
WDYT ?
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4194976#4194976
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4194976
17 years, 4 months
[Design of JBoss jBPM] - Re: Task Management component?
by tom.baeyens＠jboss.com
"aapthorp" wrote : I realise this likely requires modification to the client (hence why XUL - for prototyping with Lightning - doesn't help that Lightning doesn't currently support attachments) as well as extensions to the ICalendar model. Hopefully though you see the potential.
|
| Any thoughts on my other questions in my original post?
i only see a .ical attachment that a tool like outlook (thunderbird?) understands and translates automatically to your outlook calendar. maybe gmail does the same with google calendar.
but i don't see the concrete tools that you are referring to for other forms of integration. could you give a scenario ? something like
1) jbpm sends .ical file as an email attachment to the user
2) user's outlook automatically recognizes the .ical attachment and creates a reminder in the calendar for it and a task in the outlook task list
3) user marks task in outlook as completed.
4) outlook sends task completion response back to reply-address of .ical file
5) upon receipt of that mail notification, the jbpm-reply-email-processor completes the task in the jbpm task component.
of course, this is fictious, but it's in that kind of scenarios that i would like to understand what integrations that you have build.
also i would like to understand which concrete tools that we can integrate that way. the more widespread those tools, the more interesting, of course.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4194972#4194972
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4194972
17 years, 4 months
[Design of JBoss jBPM] - Re: Task Management component?
by tom.baeyens＠jboss.com
"kukeltje" wrote : yes, they do, but we do not go for seam right or jsf/facelets? The console components are GWT, not wrapped in a jsf tag (afaik, maybe just not yet). The issue for taskforms is resolved as rejected in jira. so..... you tell me where this is going?
|
the technology we build our console in is (should be) unrelated to the technology that we offer to our jPDL users.
we can offer facelets to our users to build task forms if we think that is the easiest technology for our jpdl users to work with.
and then separately we can decide to build our console in GWT because we think we can build the greatest console in that tech.
a consequence of taking both decisions would be that we have to show facelets task forms in a GWT based console. but i don't see a problem with that. do you ?
currently those 2 have my preference.
i'll ask heiko to start a thread with his ideas. so that we can discuss.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4194971#4194971
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4194971
17 years, 4 months