February 2009 - jboss-dev-forums - Jboss List Archives

[Design of POJO Server] - Re: Stable deployment API for tools

by emuckenhuber

"scott.stark(a)jboss.org" wrote : Ok, I'll propose and mbean interface for this shortly. Hmm but JSR88 or DeploymentManager seem to provide those nice-to-have already ? (well maybe not fully implemented but still :) Beside that we still need to integrate JSR88 properly into the ProfileService. I mean we can also just expose HDScanner in JMX, as the legacy MainDeployer(MBean) should be still there, as the testsuite is also using that. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4211544#4211544 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4211544

17 years, 1 month

1
0
0 / 0

[Design of POJO Server] - Re: Stable deployment API for tools

by adrian＠jboss.org

"scott.stark(a)jboss.org" wrote : Ok, I'll propose and mbean interface for this shortly. But why not just use jsr88? That should work in all versions of JBoss whether it is implemented on top of the legacy DeploymentManagerService or the ProfileService. The legacy implementation already has all the features Max is asking for, except the remote/isolated logging stuff. You do get deployment exceptions. Even if you don't like the jsr88 api you could use the DeploymentManagerService directly. http://www.jboss.org/community/docs/DOC-9553 It should then just be a case of re-implementing it at some point on top of the profile service so that those deployments become manageable in the console (i.e. the profile service knows about them). View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4211543#4211543 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4211543

17 years, 1 month

1
0
0 / 0

[Design of JBoss jBPM] - Re: process resume

by galanfish

i am sorry, i am new(just a college student)... but i...... i thought at first that some one develops a workflow-like thing with the pvm kernel would be called developer, and some one develops application-like with jbpm would called user... i want to develop a simple workflow with my own simple language View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4211542#4211542 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4211542

17 years, 1 month

1
0
0 / 0

[Design of POJO Server] - Re: Stable deployment API for tools

by scott.stark＠jboss.org

Yes, I was thinking of this today as a simple facade that would avoid introducing a dependency on the deployment manager stuff that is in progress. Define the mbean interface they need and we'll validate it and get some tests in the as testsuite for it. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4211313#4211313 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4211313

17 years, 1 month

3
2
0 / 0

[Design of POJO Server] - Re: Stable deployment API for tools

by scott.stark＠jboss.org

Ok, I'll propose and mbean interface for this shortly. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4211532#4211532 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4211532

17 years, 1 month

1
0
0 / 0

[Design of POJO Server] - Re: Stable deployment API for tools

by max.andersen＠jboss.com

Things that we do today on AS 4.x: We "deploy" by copying files. We rely on both zipped and exploded deployments and even copies -ds.xml files for easy configuration. Add an url for deployment location so we can avoid "polluting" the default/deploy directory suspend/restart hotdeploy scanning to avoid unnecessary restarts while we are copying files (even if we got an option for doing 100% remote deploy instead of file copy I still think file copy should be supported since it is the *simple* and works 99,9% of the time) Things that would be really nice to do: Do a remote deploy for remote systems and be able to somehow control where it gets "copied" or at least get info on where a deployment is located. Get stacktrace/exceptions/logging per deployment so we can do a better error tracing than just tell them to look in the console. (this could be as simple as have a log file or folder per deployment instead of all munged together). Actual exceptions occurring doing runtime would help a lot too. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4211519#4211519 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4211519

17 years, 1 month

1
0
0 / 0

[Design of JBoss jBPM] - Re: statefull vs stateless delegation classes

by camunda

+1 View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4211517#4211517 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4211517

17 years, 1 month

1
0
0 / 0

[Design of JBoss jBPM] - Re: statefull vs stateless delegation classes

by koen.aers＠jboss.com

Actually, since at this moment the handler classes are instantiated at each use and thrown away afterwards, the use of them is stateless by definition. So if users use instance variables (fields) to hold variables temporarily they can somehow always be refactored as local variables in the execute method (or maybe as method calls in some superclass as in Robert's case). In these cases the change will indeed not be backwards compatible. The question is whether the performance gain of being able to cache these action handlers is worth the incompatibility. In my opinion it is. Of course, action handlers need to clearly be documented as stateless if we perform this change. Cheers, Koen View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4211516#4211516 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4211516

17 years, 1 month

1
0
0 / 0

[Design of JBoss jBPM] - Re: statefull vs stateless delegation classes

by kukeltje

"camunda" wrote : But it is true still that it puts higher requirements on your ActionHandlers (no member fields)... 100% higher from 0 is still 0 :-) You can have member fields, in fact they are there since they are populated by the engine via reflection, they just should not change... So it's not that big a deal imo View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4211514#4211514 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4211514

17 years, 1 month

1
0
0 / 0

[Design of JBoss jBPM] - Re: process resume

by kukeltje

Please read the first line of my previous response... In case it was not clear ;-) this is the developer forum View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4211511#4211511 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4211511

17 years, 1 month

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-dev-forums February 2009