As part of JBNAME-8 to add security for sensitive operations, I really need to remove access to the public static localServer variable of the org.jnp.interfaces.NamingContext class. It looks like the only current user of this outside of the naming project is the org.jboss.ha.jndi.HAJNDI class which implements the Naming server interface.
I'm going to add a static Naming getLocalServer() accessor that can have a permission check, so HAJNDI naming will have to be updated to use this once the 5.0.0.CR3 jnpserver release is out. I'll do the update when I switch over the jbossas version of jnpserver.
For the related TODO in the HAJNDI code we really should be injecting the Naming instance. When I integrate the next jnpserver version I will be switching the naming service configuration to be an mc -beans.xml deployment.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4179654#4179654
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4179654
i would like to search for tasks and processes the same way I search for business objects. Our client has a library for defining filter, and it sends the filter to server. On server hibernate query is constructed from filter and the results are sent back to client.
I would like to use the same mechanism for searching for business task. But tasks + variable instances don't have such a simple structure. E.g. "friend link" example in book Seam in Action, chapter 14. I would program, that the process has two variables one is friend1 which create the request and the second is friend2 which can either accept or reject request. On one page I would like to show a table of all requests, so I would like to create a filter for all tasks where logged user is in variable friend2. Maybe you think it is better to assign task to some user. In this case maybe yes, but many times we offer editation of business objects(not users) and we need to search for tasks based on this object and assigned to logged user. Now I support searching for tasks with some criteria on business objects. E.g. friend1.age>30 searches for all the tasks where the age of friend in variable friend1 is older than 30. (Of course it makes few selects instead of one, because of any mapping of object variablesand you need to specify process and task name in the method you are calling).
Except business objects I support String attributes, but to support all other attributes I need open api of JbpmType.
I need these public methods:
public boolean matches(Class variableClass) ;
public JbpmTypeMatcher getJbpmTypeMatcher();
public Class getVariableInstanceClass ();
Do you think it is possible/reasonable? If it helps somebody I can ask my colleagues if I can post our filter solution. And if you like it you can pack it in jbpm library. It was developed for searching business objects and we want to make a simple api for searching for tasks (our filter doesn't know that there are some VariableInstances and value conversions..). Or do you prepare any solution for this in the future?
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4179648#4179648
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4179648
"smcgowan(a)redhat.com" wrote : Do you recommend to change the test code to avoid the inconsistent result?
Not until we understand the cause of the inconsistency. :-)
This looks more like a server side problem rather than a broken test.
I looked at Files.copy() and it does flush and close the file.
If Ales can't find a problem in the VFS, then I'd suggest trying to reproduce it
with Iced Tea where we can debug the native zip code.
Or failing that, producing a simple cutdown version of the test to give to Sun
so they can fix it. You should definitely give them core dump if you can reproduce
it with the latest JDK6 release.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4179629#4179629
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4179629
Yeah, the ContextClassLoader is an own problem which can be solved seperatly and I will start on it next week.
The other stuff with the jbpm.deployer is an additional feature (but which needs the ContextClassLoader to be fixed to work correctly).
For testing: Hmm, good question. Do you have something in mind? the existing test cases should cover if delegation classes are still executed correctly, but ContextClassLoader issues may be more a problem in complex environments?
Maybe Thomas has good thoughts on this?
The ideas with the jbpm.deployer also will get interesting to test, I thought about deploying different EAR versions in parallel and test the used classloader and that stuff in the action classes. But it will definitly require a running JBoss... But this will be only part of the Enterprise version anyway... We can also discuss that on friday, but it is indeed independant from the ContextClassLoader problem.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4179626#4179626
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4179626
anonymous wrote : Have you looked at the classloader issue(s) in ESB/SOA-P that relate to jBPM?
I am not sure if I found all of them, do you have concrete issues in mind? Can you maybe post the links which I shouldn't miss?
anonymous wrote : The current codebase appears to be based on the premise that each jBPM instance is standalone and co-located with the code running within the system but this is not valid in an environment like the AS which can rely on a shared codebase.
Exactly! This is what I want to address with this...
anonymous wrote : The notion of a jBPM deployer is an interesting one and is something that I have mentioned in the past. It is likely to be the keystone in any real solution to these issues.
Glad to hear that :-) Some evidence that we both are on the right track....
anonymous wrote : What is really missing is for jBPM to define a proper lifecycle for the processes in a shared environment, including support for artifacts which can be undeployed/redeployed.
Sorry, I didn't get that completly. You mean for the processdefinition-XML's? Or what to include in what lifecycle (classes in EAR, processdefinition.xml in DB, ...)?
anonymous wrote : I should also add that I do not think that ESB is the correct location for this work
Yeah, I think it fits better in the jBPM corner, same logic fits in a pure AppServer environment and maybe even the OSGI world or something else... So it is not tied to the ESB...
I'm going to have a telco with Tom on this issue on friday, I think he has an oppinion to that too....
Regards from Berlin
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4179623#4179623
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4179623
Running locally I've seen this test pass, fail with EntityA not found or crash. These different results can be also seen in the full AS 5 testsuite runs depending on which report you view. I was considering a test code change to avoid the Sun JDK issue but didn't want to overlook an issue with the VFS implementation handling the same-name jar redeployment. Previously looking at org.jboss.virtual.plugins.context.zip.ZipEntryContext.java whether checkIfModified() and initEntries() were correct and, alternatively, as Adrian's points out above, possible issue with Files.copy(). Do you recommend to change the test code to avoid the inconsistent result?
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4179621#4179621
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4179621