[Design of JBoss Remoting, Unified Invokers] - Re: Callback acknowledgements
by ron_sigal
"timfox" wrote : Messaging has no requirement to get acknowledgements that messages have been delivered to the client side.
|
There may be no formal messaging requirement for acknowledgements, but it seems to derive from the current implementation. Currently, messaging delivers messages from the server to the client by the synchronous Remoting Client.invoke() method, and ServerConsumerEndpoint.stop() waits for the completion of the call to invoke():
| this.executor.execute(new Deliverer());
| //Now wait for it to execute
| Future result = new Future();
| this.executor.execute(new Waiter(result));
| result.getResult();
|
Now, if you want to have the client side poll for messages, then the completion of the Deliverer only means that the messages have been handed over to Remoting. My understanding is that you want all messages that have left ServerConsumerEndpoint to be delivered to MessageCallbackHandler before concluding ServerConsumerEndpoint.stop(), and the only way I can see to get that information is to get an acknowledgement from the client side. Let me know if I've misinterpreted something.
anonymous wrote :
| (The HTTP transport might use acknowledgments internally to manage it's buffer -although I am not sure that is the best way to do it- but that's an implementation detail of the HTTP transport).
|
My understanding is that this issue isn't specific to the HTTP transport. Messaging's current use of the socket transport involves a callback Remoting Client on the server side contacting a ServerSocket on the client side. I thought you wanted to avoid the client side ServerSocket in all cases. Or does this restriction apply only to the HTTP transport?
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3974965#3974965
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3974965
17 years, 7 months
[Design of JBoss Portal] - JUnit improvements
by julien＠jboss.com
I have added some improvements in the JUnit stuff we have in order to be able to parameterize a testcase from the junit ant declaration.
It plays nicely with the test metadata improvements I added recently too. Here is an example of usage :
| <zest todir="${test.reports}" name="org.jboss.portal.test.core.model.instance.InstanceContainerTestCase"
| outfile="TEST-LocalInstanceContainerTestCase">
| <parameter name="PersistLocally" value="true"/>
| </zest>
| <zest todir="${test.reports}" name="org.jboss.portal.test.core.model.instance.InstanceContainerTestCase"
| outfile="TEST-RemoteInstanceContainerTestCase">
| <parameter name="PersistLocally" value="false"/>
| </zest>
|
Note that :
1/ the name of the nested element is Zest (because it needs a custom subclass of JUnitTest to integrate parameter).
2/ the outfile attribute is required in order to avoid collisions between the TEST-* files created by the formatters.
Once you are in a test case, you can retrieve the parameters by using :
Map params = TestParameter.readExternalParameters();
or by extending ConfigurableTestCase and using the getParameters().
I'll try to perform injection of parameters on the test case class using reflection later.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3974964#3974964
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3974964
17 years, 7 months
[Design of JBoss jBPM] - Re: 3.2 alpha 1 release status
by falazar
No, Ive read both of these issues before, and this doesnt appear to be linked to that.
We have a simple process that starts with the initiator, and goes to a submitted state.
In the submitted state it is controlled by a swimlane named 'approvers'
3 people or so are being added to the approvers swimlane, and that shows correctly in the database,
but when we go and look on the web, it does not show up on anyone's inbox.
Upon further looking, we saw that the function that gets the pooled tasks ONLY appears to get the tasks for pooled actors if they are direfctly declared as pooled actors, like pooled-actors=xxxx.
The query for that joins across three tables or so. But for swimlane actors, there is no entry in the JBPM_TASKACTORPOOL.
And it gets really hairy at that point, cause many of the names are so related, and the query says it is using a swimlaneactorid, when its just using an actorid, semantically different, but....
So if you can take a look at it at least, would be great.
As I said earlier, we created another function/query, which seems to get in the rest of the swimlane tasks ok.
James Ratcliff
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3974938#3974938
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3974938
17 years, 7 months
[Design of POJO Server] - Re: VFS isLeaf() vs isDirectory()/isFile()
by scott.stark＠jboss.org
"adrian(a)jboss.org" wrote : "scott.stark(a)jboss.org" wrote :
| | - we need to support a virtual war/ejb-jar that is directory, that does not have to end in .war/.jar, containing war/ejb-jar contents.
| |
|
|
| This already works, provided it is a top level directory
| or it has a META-INF folder, see the JARStruture deployer.
|
| or WEB-INF folder in the WARStructureDeployer
|
Yes, I know, but the existence of a WEB-INF is no longer a defining characteristic of a war. Think about sitting in jbosside with a single jsp or servlet that I want to deploy as a war. I view this as needing to setup a vfs repsentation of a war that is consumed by the structural deployers, and then deployed to the kernel. The virtual aspect of the vfs is being folded into the structural deployers too much currently.
This also does not get to the current question of how the VFScanner knows whether a given VirtualFile contains subdeployers. Maybe this is just a decision it should not be making though. The current recursion behavior is an artifact of porting the old url scanner.
"adrian(a)jboss.org" wrote :
| The attribute VFS notion is the DeploymentContext.
| The "isDeployment" is determined by the structure deployers
| (or you can pass it in as a predetermined deployment context).
|
I suppose this is where I'm currently out of synch. I see too much vfs related structure parsing happening in the structural deployers. I would rather have clearer steps to the structural part of deployment:
1. establish a vfs that encapsulates both the protocol for accessing raw files and structural layout in terms of a root VirtualFile and its children. By this I mean a tree of names is defined, and the basic attributes of the nodes in the tree are defined. This means marking files as ears, ejb-jar, wars, etc.
2. structural deployers come along and identify the virtual file relationships in terms of classpaths, metadata descriptors, etc.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3974925#3974925
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3974925
17 years, 7 months