[jBPM Development] - Re: Some bugs and feature requests on jBPM 4.1
by jbarrez
"kukeltje" wrote : "jbarrez" wrote :
| | "camunda" wrote :
| | | 8. Support EJB3 Entities as process variables
| | | I think this is a pretty important feature, since a lot of projeects start with EJB3 today. Since Tom fixed a bug in the binding code, I think I can go ahead with that. Will post something as soon I had time to work on it again. If anybody else putting effort into this, please let me know!
| | |
| |
| | The idea is to have a native activity for EJB3 invocations. If im correct, it was scheduled for 4.3.
| |
|
| Isn't there a difference between EJB3 invocations (SFSB, SLSB) and Entity(beans)? Bernd talks about the latter, while you talk about the former.
|
| In combination with the former, integration with Seam (components) should also have a high priority. Personally I'd not have a separate EJB activity, but extend the java activity in such a way that (component)resolvers are used to find the SLSB/SFSB/Seam component/Springbean by name
Right ... in my head EJB3 = SF/SL session beans and JPA is something else ... probably has to do something with bad EJB2 entity memories. So sorry for not reading the remark correctly.
Anyway. Afaik, the current plan is to extends the java activity with EJB capabilities and not create a new activity type.
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4261611#4261611
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4261611
16 years, 5 months
[jBPM Development] - Re: Some bugs and feature requests on jBPM 4.1
by kukeltje
"jbarrez" wrote :
| "camunda" wrote :
| | 8. Support EJB3 Entities as process variables
| | I think this is a pretty important feature, since a lot of projeects start with EJB3 today. Since Tom fixed a bug in the binding code, I think I can go ahead with that. Will post something as soon I had time to work on it again. If anybody else putting effort into this, please let me know!
| |
|
| The idea is to have a native activity for EJB3 invocations. If im correct, it was scheduled for 4.3.
|
Isn't there a difference between EJB3 invocations (SFSB, SLSB) and Entity(beans)? Bernd talks about the latter, while you talk about the former.
In combination with the former, integration with Seam (components) should also have a high priority. Personally I'd not have a separate EJB activity, but extend the java activity in such a way that (component)resolvers are used to find the SLSB/SFSB/Seam component/Springbean by name
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4261610#4261610
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4261610
16 years, 5 months
[JBoss AS Development Deployment Framework] - Incorrect Undeployment Order
by rodos77
Hello,
I believe I have found a bug in the jboss-deployers project that comes with JBoss 5.1.0.GA. It appears that during the normal shutdown of the server (triggered by Ctrl-C on Win XP SP3 machine with JDK 1.5), the Resource Adapters are being stopped/undeployed prior to the application being stopped/undeployed. This is contrary to the JCA Spec 5.3.4.1:
5.3.4.1 Phase One
|
| Before calling the stop method on the ResourceAdapter JavaBean, the application
| server must ensure that all dependant applications using the specific resource
| adapter instance are stopped. This includes deactivating all message endpoints
| receiving messages via the specific resource adapter. Note, however, since
| dependant applications typically cannot be stopped until they are undeployed, the
| application server may have to delay stopping the resource adapter instance, until
| all such dependant applications are undeployed.
|
| Completion of phase one guarantees that application threads will not use the
| resource adapter instance, even though the resource adapter instance specific objects
| may still be in the memory heap. This ensures that all application activities
| including transactional activities are completed.
|
| Thus, phase one ensures that even if a resource adapter instance does not properly
| shutdown during phase two, the resource adapter instance is practically unusable.
I think I have traced down the problem to the fact that the list of deployments is reversed twice during undeployment - once, correctly, to perform the undeployment in the reverse order of deployment and the second time incorrectly.
The following is the code where this happens:
Called first:
org.jboss.deployers.plugins.main.MainDeployerImpl:
public void undeploy(String... names) throws DeploymentException
| {
| ...
|
| List<DeploymentContext> undeployContexts = null;
| if (undeploy.isEmpty() == false)
| {
| // Undeploy in reverse order (subdeployments first)
| undeployContexts = new ArrayList<DeploymentContext>(undeploy);
| undeploy.clear();
| Collections.reverse(undeployContexts);
| if (reverted != null)
| Collections.sort(undeployContexts, reverted);
| }
|
| ...
| }
Called later:
org.jboss.deployers.plugins.deployers.DeployersImpl:
public void process(List<DeploymentContext> deploy, List<DeploymentContext> undeploy)
| {
| ...
|
| // Build a list in reverse order
| List<DeploymentControllerContext> toUndeploy = new ArrayList<DeploymentControllerContext>();
| for (int i = undeploy.size() - 1; i >= 0; --i)
| {
| DeploymentContext context = undeploy.get(i);
| if (DeploymentState.ERROR.equals(context.getState()) == false)
| context.setState(DeploymentState.UNDEPLOYING);
| log.debug("Undeploying " + context.getName());
| DeploymentControllerContext deploymentControllerContext = context.getTransientAttachments().getAttachment(ControllerContext.class.getName(), DeploymentControllerContext.class);
| if (deploymentControllerContext == null)
| {
| log.debug("DeploymentContext has no DeploymentControllerContext during undeploy request, ignoring: " + context);
| }
| else
| {
| toUndeploy.add(deploymentControllerContext);
| }
| }
|
| ...
| }
This is causing our application to hang because one of the resource adapters that ships with our application has logic in its shutdown code to block until the whole application is shutdown. This is done to make sure that all requests from the application to the RA finish processing and no new ones are received.
Because the deployment list is reversed twice, the RA is getting undeployed before the application and since this all happens in the single JBoss Shutdown thread, when the above logic in our RA is invoked, the block causes the whole shutdown process to hang.
Even not taking into consideration my specific case, shutting down the RAs before the app is very bad as any new requests coming from the app will not have a running RA to service them, transactions that should otherwise commit can be rolled back and vise versa, etc.
Please note that this problem only manifests itself under the default server configuration. Under the all configuration, it does not show up. I did not fully trace the reason but it has to do with the fact that under all, the ear file is deployed in a separate directory (farm vs deploy) and because of that the app gets undeployed before the RAs.
I think this should be a high priority bug as this affects a critical component of the J2EE architecture not to mention the fact that it results in a difference in behavior between the all and default JBoss configurations as well as a difference in behavior between JBoss 4 and JBoss 5.
If my analysis of the problem is correct, can someone please open a JIRA for it to allow tracking of status and progress?
Thx.
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4261597#4261597
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4261597
16 years, 5 months
[JBoss Transactions Development] - tooling refresh
by jhalliday
I'm getting dangerously bored of hacking configuration beans and my mind is wandering towards tooling...
We currently have a jmx browser, performance graphing tool and object store browser, along with a generic swing based container for hosting these.
Since trunk is now tied to version of the JDK guaranteed to be recent enough include jconsole (and even VisualVM if you happen to be using Sun's JDK), I'm leaning towards throwing out the jmx browser and perf graphing bits in favour of jmx hooks that will let jconsole provide equivalent functionality. Its built in graphing support is not great, but we could offer a plugin, or upsell Jopr :-)
The object store browser is the heavy weight bit. Right now it talks direct to the object store on disk, which is a bit limiting. Would something based on dynamic mbeans be feasible? I'm looking to reuse as much generic tool support as possible and going the jmx route gives us a lot of functionality for free. REST is another option, although generic front end tools for RESTful APIs are still scarce compared to things that consume mbeans and we'd need an embedded web server if running outside JBossAS.
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4261545#4261545
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4261545
16 years, 5 months
[Embedded JBoss Development] - Re: Peer Review of Embedded, ShrinkWrap and Bootstrap
by ALRubinger
"Jesper Pedersen" wrote : Overall:
| ========
|
| * Good idea to add overview.html / package.html
https://jira.jboss.org/jira/browse/JBBOOT-112
https://jira.jboss.org/jira/browse/SHRINKWRAP-58
"Jesper Pedersen" wrote : * Good idea to run checkstyle
| * Good idea to run findbugs (with reportLevel="low")
Will look into these. I'm not convinced of the benefits to CheckStyle.
"Jesper Pedersen" wrote : Bootstrap:
| ==========
| * api-embedded
| * impl-embedded
|
| - Needs to be move to Embedded - as they are a specific use-case of Bootstrap
| - Refactor package names
Emanuel agrees, now I do too. @see http://www.jboss.org/index.html?module=bb&op=viewtopic&t=162643. These can be moved as-is to org.jboss.embedded. However for the time being we'll keep the API of Embedded the same as Bootstrap. Later on we'll piece together by composition (Bootstrap for lifecycle, PS for Config, TMPDPL for Deployment).
"Jesper Pedersen" wrote : * I'm not too crazy about BootstrapMetadata being in the spi/ package
| * Also there are constants in spi/ which may not have a relevance for the actual environment
This really hasn't been touched much from the legacy (1.0.0-X) bootstrap impl. It's used in parsing out the bootstrap XML descriptors. Doesn't need to be in API and exposed to users, but needs to be locked down. Hence SPI.
"Jesper Pedersen" wrote : * I guess it is ok to keep the MC and AS specific modules here - as many projects will use them
I don't know if that's really true either. :) I think api-as/impl-as should definitely move to modules within the AS. If the MC team wants to adopt the MC bootstrap components that'd make sense too.
"Jesper Pedersen" wrote : * Missing excludes in pom.xml for MC and AS
Which ones? :) It's likely that projects we're consuming should instead be defining optional==true for their transitive deps. But this is an issue across all projects I've seen.
"Jesper Pedersen" wrote : org.jboss.bootstrap.api.server.Server
| -------------------------------------
| void registerEventHandler(LifecycleState state, LifecycleEventHandler handler) throws IllegalArgumentException;
|
| arguments should be reversed to follow other registerEventHandler methods
The reason for this is due to the varargs requirement to be last, and this is an overloaded method. Perhaps we should explore alternative method names to make things more clear? That's a Bloch point. ;)
"Jesper Pedersen" wrote : org.jboss.bootstrap.api.lifecycle.LifecycleState
| ------------------------------------------------
|
| Are we sure that there won't be any additional server states in the future ?
| Or that an implementation will define additional states ?
|
| In those cases an enum won't work - as it can't be extended.
Bootstrap currently supports a finite/immutable set of states. Unlike MC. :)
"Jesper Pedersen" wrote : Embedded:
| =========
|
| * Missing excludes in pom.xml
Same point as above. Or I could declare all deps as optional. But I'd want to know specifically what problems we're reaching to solve.
"Jesper Pedersen" wrote : org.jboss.bootstrap.api.embedded.server.JBossASEmbeddedServerFactory
| --------------------------------------------------------------------
|
| "public static final ..." -> "private static final ..."
|
| ... otherwise a
|
| createServer(final ClassLoader cl, final String className)
|
| method is needed...
You're referring to "DEFAULT_SERVER_IMPL_CLASS_NAME". https://jira.jboss.org/jira/browse/JBBOOT-113 and done.
"Jesper Pedersen" wrote : ShrinkWrap:
| ===========
|
| - Check ContextClassLoader assumptions
I found as an example JavaArchiveFactory does not provide a way for the user to specify the ClassLoader to be used in creating an instance. We assume the TCCL is sufficient. We'll do a full review on this.
https://jira.jboss.org/jira/browse/SHRINKWRAP-59
"Jesper Pedersen" wrote : org.jboss.shrinkwrap.api.Path
| -----------------------------
|
| * Would a org.jboss.cache.Fqn style be better ?
In any case, we need a factory method to create Paths, otherwise users with only the API on their classpath will get some NCDFE when BasicPath is encountered.
https://jira.jboss.org/jira/browse/SHRINKWRAP-57
I think Path is sufficient for us when contrasted with the broader support offered by FQN.
"Jesper Pedersen" wrote : org.jboss.shrinkwrap.api.Archive
| --------------------------------
|
| T add(Path target, String name, Asset asset) throws IllegalArgumentException;
|
| switch assert and name
https://jira.jboss.org/jira/browse/SHRINKWRAP-60
"Jesper Pedersen" wrote : * Remove all "String target" -- Path should be used
We've debated this a bunch and came to the conclusion that we need to accept the the String form of "target". The API makes for method chaining and that quickly gets muddled when you need to introduce "new BasicPath("path")" all over.
"Jesper Pedersen" wrote : T merge(Path path, Archive<?> source) throws IllegalArgumentException;
|
| switch path and source
https://jira.jboss.org/jira/browse/SHRINKWRAP-61
"Jesper Pedersen" wrote : org.jboss.shrinkwrap.api.spec.FactoryUtil
| -----------------------------------------
|
| * createInstance method with ClassLoader
Covered by SHRINKWRAP-59 above.
"Jesper Pedersen" wrote : org.jboss.shrinkwrap.api.container.ResourceContainer
| org.jboss.shrinkwrap.api.container.EnterpriseContainer
| org.jboss.shrinkwrap.api.container.WebContainer
| org.jboss.shrinkwrap.api.container.ManifestContainer
| ----------------------------------------------------
|
| * Alignment of method arguments
It's "path, resource, classloader" in all places I've seen.
"Jesper Pedersen" wrote : org.jboss.shrinkwrap.api.container.LibraryContainer
| ---------------------------------------------------
|
| * addLibraries()
|
| https://jira.jboss.org/jira/browse/SHRINKWRAP-62
|
| "Jesper Pedersen" wrote : org.jboss.shrinkwrap.api.export.FactoryUtil
| | -------------------------------------------
| |
| | * createInstance() with ClassLoader
|
| Above, again. :)
|
| Thanks for the review.
|
| S,
| ALR
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4261519#4261519
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4261519
16 years, 5 months
[jBPM Development] - Re: Some bugs and feature requests on jBPM 4.1
by jbarrez
"camunda" wrote : 1. Classloading problems
| When you put you EventHandlers, Java delegation classes and/or process variable types in an EJB3 deployment and redeploy that, jBPM still holds a reference to the old class definitions, which results in class cast exceptions. My guess is, that this is becasue EventHandler and such are reused/pooled? So there we might have to discuss, what scenario we want to support.
Eventhandlers, custom activities, etc were indeed instantiated at deploytime and pooled. Tom has recentlry changed this behaviour to instantiation at runtime (saves me a lot of hassle when deploying outside a project).
But I still think the instances are pooled afterwards, for performance reasons. So imo, this is a bug and needs to be fixed. In the meantime, you can restart the processEngine after a deploy as a 'workaround' (albeit not a good one...)
"camunda" wrote :
| 2. Invalid types.xml doesn't result in a parsing error
| We changed the types mapping and had a small XML error in that file. But this didn't resulted in a parsing exception, the parsing just stopped at this line and our type mapping wasn't read (which puzzled us for quite a while ;-)):
|
|
| | <type name="..." class="..." variable-class="...EntityVariable"> <!-- end tag was missing! -->
| | <type name="serializable" class="serializable"
| | converter="org.jbpm.pvm.internal.type.converter.SerializableToBytesConverter"
| | variable-class="org.jbpm.pvm.internal.type.variable.BlobVariable" />
| |
|
| Now every Serializable process variable was rejected...
|
Indeed a 'nice to have' feature ... should be easy to catch and log.
"camunda" wrote :
| 3. Bind e.g. integer value to EventListener field by expression
| This didn't work, and I don't know how to get it to work:
|
|
| | <custom class="de...jbpm.NoopActivity" g="83,61,143,50" name="xxx">
| | <on event="start">
| | <event-listener class="de.....SomeEvenetListener">
| | <field name="programm"><int value="#{programm}"/></field>
| | </event-listener>
| | </on>
| | <transition g="14,-11" name="ok" to="b"/>
| | </custom>
| |
| The only possibility with expressions seems to be the which results in a field type doesn't match problem:
|
| | <custom class="de...jbpm.NoopActivity" g="83,61,143,50" name="xxx">
| | <on event="start">
| | <event-listener class="de.....SomeEvenetListener">
| | <field name="programm"><object expr="#{programm}"/></field>
| | </event-listener>
| | </on>
| | <transition g="14,-11" name="ok" to="b"/>
| | </custom>
| |
|
The first code snippet should indeed work. Probably a bug.
"camunda" wrote :
| 4. Should be possible to set Subprocess Key by expression
| If you start a nw sub process instance, this normally has no special key, thus a key is created for it. It would be really convinient, if the main process could influence the sub process key by an expression (e.g. "#{execution.key}.SubXX.#{someUniqueVariableForIt}). maybe this need some more thoughts (what in case the key is not unique? ...?), but I think it could get handy in lot of situations.
|
I've heard this request from someone else too. Besides have an easier overview with multiple subprocesses, what other benefits do you see?
"camunda" wrote :
| 7. Signavio
| by the way, using the Signavio Editor for a already running process results in a lot of attributes beeing removed when saving with Signavio. It should be somehow the default, to keep everything, it doesn't know. I think I remember a discussion, that this is pretty hard to implement. But I think it is crucial for real live use cases. At least for use cases I have in mind for Business-/-Alignment. But maybe we can discuss that in the next meeting in Berlin.
|
I agree. I got the same feedback from a meeting with real-life users. Also, the other way around (from Eclipse -> Signavio) doesn't always work well regarding coordinates, it seems.
"camunda" wrote :
| 8. Support EJB3 Entities as process variables
| I think this is a pretty important feature, since a lot of projeects start with EJB3 today. Since Tom fixed a bug in the binding code, I think I can go ahead with that. Will post something as soon I had time to work on it again. If anybody else putting effort into this, please let me know!
|
The idea is to have a native activity for EJB3 invocations. If im correct, it was scheduled for 4.3.
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4261517#4261517
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4261517
16 years, 5 months