[jBPM Development] - discuss about how to finish el refactor job
by HuiSheng Xu
HuiSheng Xu [http://community.jboss.org/people/rebody] created the discussion
"discuss about how to finish el refactor job"
To view the discussion, visit: http://community.jboss.org/message/542454#542454
--------------------------------------------------------------
Hi guys,
I notice that Tom didn't finish his job for el refactor. we could see these issues have not finished yet.
https://jira.jboss.org/jira/browse/JBPM-2686 https://jira.jboss.org/jira/browse/JBPM-2686
https://jira.jboss.org/jira/browse/JBPM-2653 https://jira.jboss.org/jira/browse/JBPM-2653
https://jira.jboss.org/jira/browse/JBPM-1209 https://jira.jboss.org/jira/browse/JBPM-1209
https://jira.jboss.org/jira/browse/JBPM-2777 https://jira.jboss.org/jira/browse/JBPM-2777
Some of them were stay on Coding in progress for a long time. And I think we should consider about them. And find way to finish the job.
At this moment, Tom has done lots of works for refactor el from jsr-223 to UEL. I think he want to remove all of reference for ScriptManger from existing classes except ScriptManager. And he also said that we should deprecate the language attribute from expr, because after refactor job, the expr will always use UEL to evaluate the value from execution or task.
So I think we could go through his work, let components use org.jbpm.pvm.internal.el.Expression to handle the expr. Here is the which components are using ScriptManager:
| jBPM-4.3 | jBPM-4.4 |
| | org.jbpm.bpmn.flownodes.ScriptTaskActivity.java |
| org.jbpm.jpdl.internal.activity.AssignActivity.java | |
| org.jbpm.jpdl.internal.activity.DecisionExpressionActivity.java | |
| org.jbpm.jpdl.internal.activity.JmsActivity.java | org.jbpm.jpdl.internal.activity.JmsActivity.java |
| org.jbpm.jpdl.internal.activity.RulesFact.java | |
| org.jbpm.jpdl.internal.activity.ScriptActivity.java | org.jbpm.jpdl.internal.activity.ScriptActivity.java |
| org.jbpm.jpdl.internal.activity.ScriptBinding.java | org.jbpm.jpdl.internal.activity.ScriptBinding.java |
| org.jbpm.jpdl.internal.activity.SubProcessActivity.java | org.jbpm.jpdl.internal.activity.SubProcessActivity.java |
| org.jbpm.jpdl.internal.activity.SubProcessInParameterImpl.java | |
| org.jbpm.jpdl.internal.activity.SubProcessOutParameterImpl.java | |
| | org.jbpm.jpdl.internal.activity.TaskActivity.java |
| | org.jbpm.pvm.internal.cal.Duration.java |
| | org.jbpm.pvm.internal.el.ScriptExpression.java |
| org.jbpm.pvm.internal.email.impl.MailProducerImpl.java | org.jbpm.pvm.internal.email.impl.MailProducerImpl.java |
| org.jbpm.pvm.internal.job.TimerImpl.java | |
| org.jbpm.pvm.internal.model.ExecutionImpl.java | org.jbpm.pvm.internal.model.ExecutionImpl.java |
| org.jbpm.pvm.internal.model.ExpressionCondition.java | org.jbpm.pvm.internal.model.ExpressionCondition.java |
| org.jbpm.pvm.internal.model.VariableDefinitionImpl.java | |
| org.jbpm.pvm.internal.model.VariableOutDefinitionSet.java | org.jbpm.pvm.internal.model.VariableOutDefinitionSet.java |
| org.jbpm.pvm.internal.script.ScriptManager.java | org.jbpm.pvm.internal.script.ScriptManager.java |
| org.jbpm.pvm.internal.wire.binding.ScriptManagerBinding.java | org.jbpm.pvm.internal.wire.binding.ScriptManagerBinding.java |
| org.jbpm.pvm.internal.wire.descriptor.ExpressionDescriptor.java | org.jbpm.pvm.internal.wire.descriptor.ExpressionDescriptor.java |
| org.jbpm.pvm.internal.wire.descriptor.ObjectDescriptor.java | |
| | |
We could see that some of them had been solved by Tom and Joram. But there are still some components were not solved yet. So I want to continue their jobs. Anyone has any ideas? Any reply is apprieciate. Thank you very much.
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/542454#542454]
Start a new discussion in jBPM Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
16 years
Re: [jboss-dev-forums] [JBoss Microcontainer Development POJO Server] - Implementing a non-flat deployment for Weld Integration
by Ales Justin
Ales Justin [http://community.jboss.org/people/alesj] replied to the discussion
"Implementing a non-flat deployment for Weld Integration"
To view the discussion, visit: http://community.jboss.org/message/542429#542429
--------------------------------------------------------------
> So, these features that we need to support provide the arguments as to why we should mirror the ClassLoader structure instead of implementing this from scratch.
Yeah, re-inventing this would be a nightmare. ;-)
> Pete also pointed out an important behaviour that should be fixed. In a nutshell, all archives visible to a BDA are scanned. In the given scenario: ejb.jar A reaches lib2. In lib2 we have a ClassPath reference in the manifest to lib3, which is not in the classpath of the server... it is somewhere in the filesystem. In this case, for what I understood from Pete's explanations, lib3 is going to be scanned for CDI stuff. But this shouldn't happen, so we would also need a way of differentiating lib3 from lib2. I'll stop my explanation here, as I think Pete can fill in the blanks and explain this much better :-)
I guess this is the discussion we already had once: actual Weld deployment vs. static "library"?
> So, Ales, how do you think this should be done? I think we have plenty of code in the ClassPools that do exactly that, mirror the ClassLoader structure in a way that allows us to find the classes and xml files in META-INF dirs. Maybe there is a way of reusing part of the ClassPool code to do this?
It is similar in a way, but I don't see how you would be able to re-use it.
In new CL layer it's one Module per ClassLoader and vice versa.
Each Module / ClassLoader belongs to some Domain.
So, we would have to keep track of Modules and how are they wired hierarchicaly and grouped by Domain.
A Module can see any ancestor Module and all Modules in its Domain and ancestor Domains.
I would differentiate between application's explicit Modules and what it can reach,
hence you don't scan yourself too deep; e.g. into default Domain.
This way it should be also easy to support a notin if libraries as long as they are deployed the same way / over new CL layer.
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/542429#542429]
Start a new discussion in JBoss Microcontainer Development POJO Server at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
16 years
Re: [jboss-dev-forums] [JBoss Microcontainer Development] - ClassPool bootstrap refactoring
by Kabir Khan
Kabir Khan [http://community.jboss.org/people/kabir.khan%40jboss.com] replied to the discussion
"ClassPool bootstrap refactoring"
To view the discussion, visit: http://community.jboss.org/message/542427#542427
--------------------------------------------------------------
> Andrew Rubinger wrote:
>
> Corrected the failing tests, made a couple other lil' tweaks.
>
> https://jira.jboss.org/jira/browse/JBBOOT-134 https://jira.jboss.org/jira/browse/JBBOOT-134
>
> Still something I'd like to investigate is moving some of these bits to event handlers or elsewhere. This patch brings in a lot of dependencies I'd like to understand/justify. If this is primarily for AS, what's the overhead in pure MC servers, where this is placed? If the answer is more than "nothing", we may have to extract this stuff out a bit so pure MCServer performance doesn't deteriorate.
>
> S,
> ALR
I agree these classpool bits should not be hard-coded in AbstractMcServerBase.doInitialize(). If the events and event handlers can be made more fine-grained or "precise" as to when they occur (as mentioned what I added must happen in *exactly* the place it does, although it might be possible to move the installation of the config bean into MC before the call to super.initialize()) then we should do that. The quick way would be to just add two new events, PRE_BOOTSTRAP and POST_BOOTSTRAP and raise them from where I am doing so, but I don't want to mess up your code if you have other ideas :-)
This is primarily for AS since what my new stuff does is basically to set up javassist classpools understanding the AS classloading, normal MC setups probably will not need to do that, or might need to do something else.
The overhead is installing a new bean waiting for the ClassLoading bean to be installed, which then installs itself as a ModuleRegistry in the ClassLoading bean. This ModuleRegistry then gets notified as classloader Modules are added/removed and does some work. So the overhead isn't exactly "nothing", so it should go somewhere else once we can have the event handlers triggered where I need them. I guess these event listeners could go into a different module in bootstrap or elsewhere. As long as the jars containing them are on the classpath, I think AS Main could just call registerEventHandler() after creating the server instance but before initializing it.
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/542427#542427]
Start a new discussion in JBoss Microcontainer Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
16 years