[Deployers on JBoss (Deployers/JBoss)] - Question of hot-deploying jar file
by anna_karina
Sorry if this sounds like a stupid question.
It is fine to hot-deploy web app, but I'm wondering what does it take to be able to hot-deploy a normal jar file.
The reason is this: we want to put Mule inside JBoss, which is done with JCA right now, but we want to make it better. While Mule is running the inbound and outbound routers and servicing the apps, when the administrator wants to add new model (which might have to add the UMO implementation jar file to Mule), we don't want to stop Mule …
[View More](and JBoss), we want the new jar file "hot-deployed" so that the class files can be accessed right away.
I'm looking at the new deployer model in JBoss 5, and thinking of implementing the spi to provide a module to hot-deploy jar file.
The problem is, web app has a life cycle, which normal class does not have. The question is, how much would it take to develop a hot deployer for jar files, especially those that must be shared between different web apps? This can be used, not just for us in Mule, it would be nice to be able to deploy a jar file (e.g. patch a running system) without stopping the server.
Thanks for any hint.
ak
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4044250#4044250
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4044250
[View Less]
17 years, 9 months
[Design of JBoss jBPM] - Re: including graphical information in the process definitio
by kukeltje
I miss one thing: what is the advantage of one file with two sections over two files? (assuming we still want to merge the forms.xml into the processdefinition.xml)
And if there are some gpd namespaced elements that have no relation to any process construct (besides the processdefinition at the highest level) I see no problem puting them separately, but having the processconstruct related gpd elements in there would not be a problem imo. So something like
| <process-definition
| …
[View More]xmlns="urn:jbpm.org:jpdl-3.2"
| xmlns:gpd="urn:jbpm.org:jpdl-gpd-3.2"
| name="simple"
| gpd:width="469" gpd:height="439">
| <start-state name="start" gpd:x="150" gpd:y="25" gpd:width="140" gpd:height="40">
| <transition name="to_state" to="first">
| <gpd:bendpoint x="23" y="45"/>
| <gpd:bendpoint x="45" y="67"/>
| <gpd:bendpoint x="22" y="11"/>
| <action name="action" class="com.sample.action.MessageActionHandler">
| <message>Going to the first state!</message>
| </action>
| </transition>
| </start-state>
| <state name="first" gpd:x="150" gpd:y="125" gpd:width="140" gpd:height="40">
| <transition name="to_end" to="end">
| </state>
| <gpd:note>
| Just a not in a separate element, but no section
| </gpd:note>
| </process-definition>
|
Or do you mean colorinfo etc??? instead of notes? Still then, putting that in a separate element and refering to it is not a problem imo.
Or do I miss something?
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4044236#4044236
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4044236
[View Less]
17 years, 9 months
[Design of JBoss Web Services] - jbossws 1.2.1 questions/potential issues?
by tzhou
Hi all,
I posted this earlier to user forum but I didn't get any response. Thought it might be more appropriate for design forum. Sorry for the reposting...
I've been using JBossWS 1.2.1 along with Sun's Wiseman API for WS-Management development. After days of hard debugging, here are some of the issues (or maybe non-issues) I found. Either case, I hope the gurus here can shed some light.
1. WRONG_DOCUMENT_ERR when marshaling a SOAP document complaining that caller tries to append a node to …
[View More]another node that belongs to a different owner document
Turns out the problem was caused by DOMUtils, which uses ThreadLocal to keep track of owner document. This would work fine if everything is in the same thread. But in my case, Wiseman code constructs a response message, and then pass that response object to a separate handler thread for further processing. And that becomes a _problem_. I'm not sure about the rationale behind the threadlocal mechanism, but to me assuming all DOM processing is in one thread is simply dangerous. Thoughts?
2. JAXB and JBossWS compatibility issue
The upper-level code (Wiseman) constructs a SOAP message, and uses JAXB to marshal content to the body, something like "marshaller.marshal(contentObj, getBody())". The result: only the top-level node gets added to the body, but not its decedents. After some digging, I found the problem was caused by SOAPBodyImpl.appendChild(), which constructs a new child from the existing child node. This apparently is a problem for JAXB, since the subsequent tree construction is all based on the original child node. The same issue also occurs to SOAPHeaderImpl.appendChild().
FYI, I'm using JBossWS 1.2.1GA.
Thanks,
Ting
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4044128#4044128
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4044128
[View Less]
17 years, 9 months
[Design of JBoss jBPM] - Re: including graphical information in the process definitio
by koen.aers@jboss.com
Well, finally a reaction from me...
Sorry guys, I was strolling around in Yosemite National Park this weekend and had to go to the San Francisco Giants - New York Mets baseball game with the JBoss marketing girls yesterday evening ;-))
So it seems that everyone agrees... except for me...
I definitely see the value of keeping the information in one file. And if that is the way to go, I would strongly opt for a separate section with graphical information. I gave the example with the different …
[View More]bendpoint tags and with the coloring information but the problem stretches further than that. It could e.g. contain a textual note graphical element that is completely unrelated to any of the jpdl constructs, but has only a relationship with the graphical information. All in all it boils down to the fact that some of the graphical information is not related at all to the business infromation and the other way round. So keeping the information in two separate sections seems appropriate to me. Whatever you may think and how good the tool in the future may become, the processdefinition.xml file will be read by humans, so we should make this not too difficult.
Regards,
Koen
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4044055#4044055
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4044055
[View Less]
17 years, 9 months