[Design of POJO Server] - VFSClassLoader has been committed
by adrian@jboss.org
The new VFSClassLoader has been committed.
But it is disabled. JBoss Head is still using the UCL (UnifiedClassLoader).
If you want to try it out, then you need to goto conf/bootstrap-beans.xml and set
oldClassLoader=false
on the JMXKernel
and then go further down the file, comment out the ServiceClassLoaderDeployer
and uncomment the section marked as VFSClassLoader
(including the one that says it is a hack :-).
This really needs integrating in a cleaner way possibly using the deployers
notion of the ClassLoaderFactory so you only have to define it in one place.
AFAIK, everything should work with the new classloader,
but I need to do more testing to make sure there isn't something overlooked.
The exceptions are the following:
1) Anything that is referencing RepositoryClassLoader directly.
At time of writing the ones I'm aware of are:
a) The Hibernate MBean (which is broken anyway since it still used DeploymentInfo)
b) AOP in a scoped deployment, there's a seperate thread about this in the AOP forum
2) Jasper - jsp compilation
This works, as long as you use the default compiler, i.e. JDT (eclipse compiler)
If you try to use the ANT compiler it won't know the classpath.
Since the ANT compiler is inefficient and won't work anyway when we do
full OSGi classloading semantics, I'm not worried about this.
3) Testsuite
Some of the tests are assuming the UCL. A lot of them run on the client side,
so its not really an issue. But some are designed to run inside the appserver.
All of these tests have already been duplicated into the jboss-classloader
project for the new classloader, so the issue is how we do the tests
if we want to maintain support for the UCL.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4064092#4064092
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4064092
18 years, 9 months
[Design of JBoss jBPM] - ProcessState 'leave' method
by rgullett
The leave method for ProcessStates currently automatically takes the default transition despite taking a transition as a parameter. Can it be modified so that it leaves by the transition passed in (if it isn't null) like you'd expect it to? I want to be able to short-circuit my subprocesses in certain scenarios. See the method as it's currently coded below.
public void leave(ExecutionContext executionContext, Transition transition) {
ProcessInstance subProcessInstance = executionContext.getSubProcessInstance();
Token superProcessToken = subProcessInstance.getSuperProcessToken();
// feed the readable variableInstances
if ((variableAccesses != null) && (!variableAccesses.isEmpty())) {
ContextInstance superContextInstance = executionContext.getContextInstance();
ContextInstance subContextInstance = subProcessInstance.getContextInstance();
// loop over all the variable accesses
Iterator iter = variableAccesses.iterator();
while (iter.hasNext()) {
VariableAccess variableAccess = (VariableAccess) iter.next();
// if this variable access is writable
if (variableAccess.isWritable()) {
// the variable is copied from the sub process mapped name
// to the super process variable name
String mappedName = variableAccess.getMappedName();
Object value = subContextInstance.getVariable(mappedName);
String variableName = variableAccess.getVariableName();
log.debug("copying sub process var '"+mappedName+"' to super process var '"+variableName+"': "+value);
if (value!=null) {
superContextInstance.setVariable(variableName, value, superProcessToken);
}
}
}
}
// fire the subprocess ended event
fireEvent(Event.EVENTTYPE_SUBPROCESS_END, executionContext);
// remove the subprocess reference
superProcessToken.setSubProcessInstance(null);
// We replaced the normal log generation of super.leave() by creating the log here
// and overriding the addNodeLog method with an empty version
superProcessToken.addLog(new ProcessStateLog(this, superProcessToken.getNodeEnter(), new Date(), subProcessInstance));
// call the subProcessEndAction
super.leave(executionContext, getDefaultLeavingTransition()); }
The bold line could be replaced by something like:
if(transition != null) {
super.leave(executionContext, transition);
} else {
super.leave(executionContext, getDefaultLeavingTransition());
}
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4064089#4064089
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4064089
18 years, 9 months
[Design of JBoss Build System] - Re: jboss-head build testsuite action plan
by bill.burke@jboss.com
Maybe a freeze is better than a rollback? Not even necessarily a real SVN freeze. What we do when we see a regression is send an email saying we're freezing, no commits. We look at Hudson, or wherever on who committed what and get them to fix their stuff.
Here are my thoughts that I posted on a different forum by mistake:
1. Freeze trunk
2. Generate JIRA tasks for each failing test in EJB3 and testsuite module (and any other module that has a testsuite in AS trunk.
3. Disable all failing tests
4. Unfreeze trunk.
5. Nightly build runs
6. If it is not successful, then freeze trunk until regressions are fixed
7. If successful tag and increment build number
The TCK should be a part of the regression process. If it regresses, we should freeze as well. I dont' know how feasible this is given TCK takes what, 10 hours to run?
I've seen this process work well at other companies (one of them a middleware company!). One thing that makes this process work is for developers to work in their own branch off of trunk. This allows them to commit and share work with others, without breaking or regressing trunk. Since we are on SVN now, this should be much much easier to do.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4064083#4064083
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4064083
18 years, 9 months