[Design of EJB 3.0] - Any compilation errors in ejb3-proxy?
by jaikiran
I just updated my local repository (after many days) and see compilation failures in the EJB3 proxy module:
D:/JBoss/EJB3/proxy/src/main/java/org/jboss/ejb3/proxy/factory/session/stateful/StatefulSessionProxyFactoryBase.java:[29,45] cannot find symbol
| symbol : class StatefulSessionContainerMethodInvocation
| location: package org.jboss.ejb3.interceptors.container
|
| D:/JBoss/EJB3/proxy/src/main/java/org/jboss/ejb3/proxy/container/StatefulSessionInvokableContext.java:[24,45] cannot find symbol
| symbol : class StatefulSessionContainerMethodInvocation
| location: package org.jboss.ejb3.interceptors.container
|
| D:/JBoss/EJB3/proxy/src/main/java/org/jboss/ejb3/proxy/container/StatefulSessionInvokableContext.java:[38,26] cannot find symbol
| symbol: class StatefulSessionContainerMethodInvocation
| InvokableContext<StatefulSessionContainerMethodInvocation>
|
| D:/JBoss/EJB3/proxy/src/main/java/org/jboss/ejb3/proxy/container/StatefulSessionInvokableContext.java:[36,59] cannot find symbol
| symbol: class StatefulSessionContainerMethodInvocation
| public interface StatefulSessionInvokableContext<T extends StatefulSessionContainerMethodInvocation>
|
| D:/JBoss/EJB3/proxy/src/main/java/org/jboss/ejb3/proxy/factory/session/stateful/StatefulSessionProxyFactoryBase.java:[336,51] cannot find symbol
| symbol : class StatefulSessionContainerMethodInvocation
| location: class org.jboss.ejb3.proxy.factory.session.stateful.StatefulSessionProxyFactoryBase
|
Looks like the org.jboss.ejb3.interceptors.container.StatefulSessionContainerMethodInvocation has been moved to the ejb3-interceptors? The pom in proxy has a dependency on 0.13.2-SNAPSHOT of jboss-ejb3-interceptors, which doesn't seem to have this class.
| <dependency>
| <groupId>org.jboss.ejb3</groupId>
| <artifactId>jboss-ejb3-interceptors</artifactId>
| <version>0.13.2-SNAPSHOT</version>
| </dependency>
Have i messed up my setup? Or is this just a work-in-progress issue?
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4166702#4166702
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4166702
17 years, 8 months
[Design of JBoss jBPM] - Re: Defining the API Mission
by camunda
Hi guys,
wow, a lot of content (an me beeing to busy to really joing that interesting discussion :-/)...
anonymous wrote : Thats why I don't think we should pursue of making BPMN executable. It creates the false illusion that analysis models automagically can be made executable. That is a false promise that many BPM vendors promote and that gives BPM its bad reputation. We get our recognition from being more modest but honest.
I agree with it. Basically I think making BPMN executable or supporting Round-Tripping and all that is in the state of research. Interesting to keep up, but to early to really go for it. Would be very interesting for a Master Thesis or the like (camunda would volunteer for funding and supervise such a thesis ;-)). But I think, executing BPMN is not really the best try, better generate a execution language out of it.
And for now I would definitely keep the GTD (okay, get rid of some bugs ;-)), the people like jBPM because it is relatively easy.
anonymous wrote : I see no advantage in centering our execution design on BPMN: it imposes extraneous requirements and shreds no light on our particular challenges. I believe we should center it on our experiences with jBPM 3, and take BPMN compatibility as a secondary criterion.
|
Agreed. It should be obvious to center on our experiences with jBPM up to 4...
anonymous wrote :
| I think we should have a (one-way) BPMN to jPDL export functionality in the STP BPMN designer.
|
| That fits right into our vision and strategy. Analysts can then model freely in BPMN. When they're done, they can give that BPMN analysis model as part of the requirements input to the development team. Then the development team can do an export to jPDL and further make the process executable.
|
Agreed. This would be also a very interesting move forward! Very, very interesting!
anonymous wrote : After that, further iterations all happen on the jPDL executable process. The analysts will now still recognize the jPDL diagram. They still can discuss it. But further iterations will not be synchronized back to the original BPMN analysis model. (just like no one would keep their analysis UML class diagrams in sync with the implementation UML diagrams.) Once the tranlation is done to an executable process language, it becomes software is it comes under the control of the development team.
|
anonymous wrote : In fact, in case of UML class diagrams, no-one even thought of automagically synchronizing the analysis class model with the executable classes.
I do not really agree on this. I think, there could be more support than just one way generation. Even with UML there are tools that can at least keep traces between analysis and execution model. You can even set traces between use cases and classes. This can be very helpful if used (there you are right, not used very often).
With BPM I see tools today which can link process landscapes to analysis models, which can link to implementation models. This has a real value.
Supporting a roundtrip or maybe even share a same model (and have analysis and execution as different "views") is a interesting vision. I have the feeling it can be reached somehow, but it is still a stony path. So I wouldn't concentrate on this goal too early or at least with a clear focus on research. Shouldn't hinder the further development of jBPM itself! Again: I (or say we as camunda) would be interested in joining research activity in that field. We are very active in the field of BPMN and currently involved in some activities around it.
Workflow-Patterns: I wouldn't do too much effort in this, I see it a lot in universities, thesis and that stuff, but rarely in real life projects or evaluations.
Another thought: I get the feeling that currently a lot of experiences and thoughts of jBPM are not taken completely into account for some definitions.
Cheers
Bernd
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4166690#4166690
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4166690
17 years, 8 months
[Design the new POJO MicroContainer] - Performance - Update
by adrian＠jboss.org
Since I started looking at this at the start of the week,
the time to boot in the default config in JBoss5 on my laptop
has dropped from 1 minute to 45 seconds (approximate wall clock timings).
Obviously this is using unreleased versions of the MC project jars
so nobody else will be seeing this at the moment. ;-)
The big things left to do now are;
* Annotation Scanning - Ales's new code
Old code:
| java.lang.Throwable.fillInStackTrace(Throwable.java:Unknown line)
| java.lang.Throwable.<init>(Throwable.java:218)
| java.lang.Exception.<init>(Exception.java:59)
| java.lang.ClassNotFoundException.<init>(ClassNotFoundException.java:65)
| org.jboss.classloader.spi.base.BaseClassLoader.loadClass(BaseClassLoader.java:379)
| java.lang.ClassLoader.loadClass(ClassLoader.java:251)
| org.jboss.deployment.AnnotatedClassFilter.accepts(AnnotatedClassFilter.java:121)
| org.jboss.deployment.AnnotatedClassFilter.visit(AnnotatedClassFilter.java:102)
| org.jboss.virtual.plugins.vfs.helpers.WrappingVirtualFileHandlerVisitor.visit(WrappingVirtualFileHandlerVisitor.java:62)
| org.jboss.virtual.plugins.context.AbstractVFSContext.visit(AbstractVFSContext.java:264)
|
* Looking at the VFS, in particular the
file.getChild() -> getChildren() madness!
| org.jboss.virtual.plugins.context.file.FileHandler.getChildren(FileHandler.java:161)
| org.jboss.virtual.plugins.context.file.FileSystemContext.createVirtualFileHandler(FileSystemContext.java:337)
| org.jboss.virtual.plugins.context.file.FileSystemContext.createVirtualFileHandler(FileSystemContext.java:256)
| org.jboss.virtual.plugins.context.file.FileHandler.createChildHandler(FileHandler.java:224)
| org.jboss.virtual.plugins.context.AbstractVirtualFileHandler.structuredFindChild(AbstractVirtualFileHandler.java:509)
| org.jboss.virtual.plugins.context.file.FileHandler.getChild(FileHandler.java:233)
| org.jboss.virtual.VirtualFile.getChild(VirtualFile.java:427)
| org.jboss.classloading.spi.vfs.policy.VFSClassLoaderPolicy.findChild(VFSClassLoaderPolicy.java:450)
|
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4166674#4166674
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4166674
17 years, 8 months