[Design of POJO Server] - Re: Sub-Profiles ProfileService changes
by emuckenhuber
"bstansberry(a)jboss.com" wrote : You're right; I think it's fine. I'd misunderstood what the validate(ControllerContext) call was really doing. I got sucked into a unrelated debugging fest today so haven't proved it yet, but it should be fine.
No problem, i've updated the xml format to use <hotdeployment-profile/> and stuff like that.
There are actually no changes to the testsuite prototype, as this is the default configuration :)
I like this, because it's also fitting good to my other stuff i'm working on in my sandbox...
So beside the weird implicit dependencies the xml format should not change much, maybe some optional attributes if needed.
One other issue related to your prototype - there is one major cleanup in the spi outstanding.
Basically i want to drop the VFSDeployment from the spi, as it should not be there.
This would also mean - that actually everything related to DeploymentRepositories would
get an implementation detail...
I still need to check how this would affect ManagementView and DeploymentManager,
but i doubt that we need the VFSDeployment there at all.
I guess you don't have a need for an VFSDeployment for your use case? well there will be a similar ProfileDeployment.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4205214#4205214
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4205214
17 years, 2 months
[Design the new POJO MicroContainer] - Deployment cleanup & modifications
by alesj
An exception I got yesterday while testing new MC releases
gave me plenty to think about in the evening.
WRT:
- http://www.jboss.com/index.html?module=bb&op=viewtopic&t=148563
Doing just DeploymentContext::cleanup is not enough.
Why?
Since we have a notion of modifying a deployment (X):
- http://www.jboss.com/index.html?module=bb&op=viewtopic&t=149077
What does this actually do?
If using 'temp' directive we create a temporary copy of deployment's file,
hence the actual Deployment::root != DeploymentContext::root.
In other words:
* Deployment == client view
* DeploymentContext == server view
But while we're trying to recognize the structure, to create a DeploymentContext instance,
we already potentially do some temp unpacking, ...
That's why a need to do cleanup also on client side Deployment.
How to do this?
1) Deployment::cleanup - add new method
2) DeploymentFactory::destroyDeployment - add new method
3) usage specific, e.g. in Profile Service code: VFSDeployment::getRoot::cleanup
Which one to use/impl?
Also a few observations/issues about modification usage.
There might be more, but this are the one's I scrapped together.
(a) When to replace a handler when doing a modification?
I actually forgot about this issue and changed how this behaved in VFS. :-(
In my opinion 'temp' and 'explode' should not replace handler.
As this changes client behavior.
e.g. server/deploy/myapp.ear --> server/temp/some-uuid/myapp.ear
If I did a replacement on a parent (= deploy/), then deploy/ would actually see both deployments at update.
Only unpack should replace it. As it only applies to nested resoruces,
hence doesn't change client view that much. At least not in a confusing fashion.
(b) direct URL usage
Although we use modification, the URL's are still the same as non modified.
So, if you use direct URL (any of its ops), the vfs cache is gonna navigate you to non-temp view.
Meaning even though you're using things on server side,
it's gonna drive you off into client side.
It's still gonna be somehow the same, as modifications don't modify the resource itself,
but it's just conceptually wrong, since you did modifications for a reason.
(c) Even if you use modifications, all undeploy (see (X)) issues don't go away
e.g. if you use a direct VFS URL, at undeploy, it's gonna go to VFS cache,
and try to navigate to previously deleted file (aka client view).
Since VFS cache has no idea that you actually created a temp version of your deployment.
If you use other mechanisms, e.g. classloaders, deployers,
they are gonna work, as they transparently know about the temp.
(d) tmp and VFSCache
How to apply vfs cache to tmp directory so that we don't hit vfs-nested.tmp dir,
which will be massive memory drawback.
How to actually make usage of it, as temp should be impl detail/hidden.
Really uncharted territory ...
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4205156#4205156
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4205156
17 years, 2 months
[Design the new POJO MicroContainer] - Inject descriptions
by wolfc
I'm separating out user configuration and system configuration in some beans.xml files, but I don't like the user configuration errors I might get.
Right now I can do:
<inject bean="QuartzSQLProperties"/>
But I really would like to have:
<inject bean="QuartzSQLProperties" description="QuartzSQLProperties is not configured, see wiki http://..."/>
So that this:
org.jboss.deployers.client.spi.IncompleteDeploymentException: Summary of incomplete deployments (SEE PREVIOUS ERRORS FOR DETAILS):
|
| *** CONTEXTS MISSING DEPENDENCIES: Name -> Dependency{Required State:Actual State}
|
| QuartzTimerServiceFactory
| -> QuartzSQLProperties{Configured:** NOT FOUND Depends on 'QuartzSQLProperties' **}
|
|
| *** CONTEXTS IN ERROR: Name -> Error
|
| QuartzSQLProperties -> ** NOT FOUND Depends on 'QuartzSQLProperties' **
|
|
| at org.jboss.deployers.plugins.deployers.DeployersImpl.checkComplete(DeployersImpl.java:993)
| at org.jboss.deployers.plugins.deployers.DeployersImpl.checkComplete(DeployersImpl.java:939)
| at org.jboss.deployers.plugins.main.MainDeployerImpl.deploy(MainDeployerImpl.java:427)
| at org.jboss.ejb3.timerservice.quartz.test.simple.unit.SimpleUnitTestCase.setUpBeforeClass(SimpleUnitTestCase.java:110)
| at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
| ...
Becomes more like this:
org.jboss.deployers.client.spi.IncompleteDeploymentException: Summary of incomplete deployments (SEE PREVIOUS ERRORS FOR DETAILS):
|
| *** CONTEXTS MISSING DEPENDENCIES: Name -> Dependency{Required State:Actual State}
|
| QuartzTimerServiceFactory
| -> QuartzSQLProperties{Configured:** NOT FOUND Depends on 'QuartzSQLProperties' ** QuartzSQLProperties is not configured, see wiki http://...}
|
|
| *** CONTEXTS IN ERROR: Name -> Error
|
| QuartzSQLProperties -> ** NOT FOUND Depends on 'QuartzSQLProperties' **
|
|
| at org.jboss.deployers.plugins.deployers.DeployersImpl.checkComplete(DeployersImpl.java:993)
| ...
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4205145#4205145
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4205145
17 years, 2 months
[Design of JBoss ESB] - Drools RuleFlow integration
by beve
Kris Verlaenen has written an example integrating Drools RuleFlow with JBossESB that we have used as the basis of our integration. This post describes the work that has been done so fare.
Communication from JBossESB to Drools RuleFlow is performed by using the org.jboss.soa.esb.ruleflow.action.BpmProcessor action. Examples of such communications are deploying a process, starting a process, and completing a process.
Here is an example of deploying a process definition:
| <action name="create_new_process_instance" class="org.jboss.soa.esb.actions.ruleflow.BpmProcessor">
| <property name="command" value="deployProcess" />
| </action>
|
This will deploy a process definition which is expected to be located in the default body location. This is the location that is used when you call:
esbMessage.getBody().add("some data");
This can be configured by specifying a different location by using the 'processLocation' property. You will also be able to specify a 'file' property if the process definition is to be picked up from the filesystem/classpath.
Here is an example of a RuleFlow process definition:
<?xml version="1.0" encoding="UTF-8"?>
| <process xmlns="http://drools.org/drools-5.0/process"
| xmlns:xs="http://www.w3.org/2001/XMLSchema-instance"
| xs:schemaLocation="http://drools.org/drools-5.0/process drools-processes-5.0.xsd"
| type="RuleFlow" name="flow" [1]id="test-ruleflow" package-name="org.jboss.soa.esb" version="1.0" >
|
| <header>
| <variables>
| [2]<variable name="org.jboss.soa.esb.message.defaultEntry" >
| <type name="org.drools.process.core.datatype.impl.type.StringDataType" />
| </variable>
| </variables>
| </header>
|
| <nodes>
| <workItem id="2" name="Service1" x="128" y="16" width="97" height="40" >
| <work [3]name="ESB Service" >
| <parameter name="Body">
| <type name="org.drools.process.core.datatype.impl.type.StringDataType" />
| </parameter>
| <parameter name="ServiceName" >
| <type name="org.drools.process.core.datatype.impl.type.StringDataType" />
| <value>TestService1</value>
| </parameter>
| <parameter name="CategoryName" >
| <type name="org.drools.process.core.datatype.impl.type.StringDataType" />
| <value>TestCategory</value>
| </parameter>
| </work>
| <mapping type="in" from="org.jboss.soa.esb.message.defaultEntry" to="Body" />
| <mapping type="out" from="Result" to="org.jboss.soa.esb.message.defaultEntry" />
| <onEntry>
| <action type="expression" dialect="java" >System.out.println("Entering Service1");</action>
| </onEntry>
| <onExit>
| <action type="expression" dialect="java" >System.out.println("Exiting Service1");</action>
| </onExit>
| </workItem>
|
| <end id="6" name="End" x="646" y="16" width="80" height="40" />
| <start id="1" name="Start" x="16" y="16" width="80" height="40" />
| </nodes>
|
| <connections>
| <connection from="1" to="2" />
| <connection from="2" to="6" />
| </connections>
|
| </process>
|
[1]. This is the process 'id' which will be used later used to start the process.
[2]. This is the variable name which will store the ESB Message payload. Notice the variable that is named after the default body location. This can also be a named body location as long as you use the same value for bodyLocations when starting the process.
[3]. Work name specifies a WorkItemHandler and in this case we have named it "ESB Service". This name is used to register the ESBServiceWorkItemHandler with the process engine. ESBServiceWorkItemHandler is a WorkItemHandler that takes care of communication from a Drools RuleFlow to JBossESB. The registration of ESBServiceWorkItemHandler is done by the registerEsbWorkItemHandler() method in http://anonsvn.jboss.org/repos/labs/labs/jbossesb/workspace/dbevenius/rul... .
After a process has been deployed it can be started like this:
| <action name="create_new_process_instance" class="org.jboss.soa.esb.actions.ruleflow.BpmProcessor">
| <property name="command" value="startProcess" />
| <property name="processId" value="test-ruleflow"/>
| </action>
|
Notice that we are specifying the 'processId' that we deployed above. We are not specifying a mapping for the ESB Message payload which means that the payload to be used will default to the default body location (org.jboss.soa.esb.message.defaultEntry).
For more information about startProcess see: http://anonsvn.jboss.org/repos/labs/labs/jbossesb/workspace/dbevenius/rul...
Finally, there is a command to complete a work item:
| <action name="action" class="org.jboss.soa.esb.ruleflow.action.BpmProcessor">
| <property name="command" value="completeWorkItem" />
| </action>
|
Note that this version was built using drools-5.0.0.M4 and is very much a work in progress. We are posting this to get some early feedback and comments from anyone that is interested.
Links:
Workspace: http://anonsvn.jboss.org/repos/labs/labs/jbossesb/workspace/dbevenius/rul...
Quickstart: http://anonsvn.jboss.org/repos/labs/labs/jbossesb/workspace/dbevenius/rul...
Unittest: http://anonsvn.jboss.org/repos/labs/labs/jbossesb/workspace/dbevenius/rul...
/Daniel
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4205138#4205138
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4205138
17 years, 2 months