[Design of JBoss jBPM] - Re: Behavior when next state in a
by heiko.braun@jboss.com
anonymous wrote :
| I've been having very good success (with some agony) of morphing the jbpm-console into a useful "application", instead of a demo, that can have several business processes available and gives users of the processes a good experience. A few new tags and some customized pages with "tab" behavior, etc. have made it very useful. The use of the JSF and s4j tags makes it easy to test and retest without starting and stopping the server or having to redeploy the console ( I use Eclipse with my workspace pointing to the unzipped jbpm-console.war and alter it there ). The only time I have to start and stop the server is when I add a class to the console, of course. Business processes are deployed as usual to the console.
|
Not "end-user" targeted is wrong. The aim of the new console to provide a proper solution for the most common jBPM use cases. If you are interested in contributing or "shaping" the task management functionality, then I'd gladly here about your ideas.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4185806#4185806
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4185806
16 years, 4 months
[Design of POJO Server] - Re: Towards a canonical server
by scott.stark@jboss.org
Since we are not going to get too far on this for the 5.0.0.GA, I want to continue to talk about what the server contents might look like in the canonical distribution paradigm.
The server contents would probably be something like:
| jboss-5.1/bin
| jboss-5.1/repository
| jboss-5.1/server/default/profile.xml
| jboss-5.1/server/all/profile.xml
| ...
|
The repository has deployment bundles, be they library jars or deployer contents, along with metadata about each deployment that includes things like version, capabilities and requirements. See the OSGi OBR spec http://www.osgi.org/Download/File?url=/download/rfc-0112_BundleRepository... for an idea of capabilities/requirements.
A profile.xml should actually only be a statement of requirements that are matched up to content in the repository:
| <profile name="default">
| <requirement>ejb3-core</requirement>
| <requirement>ejb3-ext</requirement>
| <requirement>ejb2</requirement>
| <requirement>ejb2</requirement>
| <requirement>JMS</requirement>
| <requirement>jmx-console.war</requirement>
| <requirement>ROOT.war</requirement>
| <requirement>JSR77 MEJB</requirement>
| ...
| </profile>
|
We may need to include library version range requirements as well for applications that will be added dynamically via hot deploy.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4185782#4185782
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4185782
16 years, 4 months