[Design of JBoss jBPM] - Re: JobExecutor enhencement proposition to allow 3rd framewo
by p.pasqual
hi tom,
thanks for the return, i will see if i have all acces to cvs/svn to see what you commit.
ok concerning last part of the patch it's only a refactor by externalisation of context creation/closing/error handling made by old executeJob(Job) under JobExecutorThread soo it's the same thant before. (Incremetal refactoring to limit impact of modifications).
to answer Fady: I just adapt Some Coding pattern "inspired" by Spring and i adapte to the current project without add dependencises with Spring soo dont worry. but now decoupling is sufisant to permit Sprint or Other kind of framework. Jbpm project is independant of integartion framework and it must continue to be.
About : "And what would be left to do to include a complete integration with Spring?"
it's a large domain, and there is no real answer!!! Because there is no only one complete integration with Spring or other framework but multiple coresponding to your need, your existing software, and level of integration or use of framworks.
Soo the good question can be more : what would be left to do to to permit to use Jbpm under all kind of architecture ? :-)
I think there is some hard coded things or some part of implementation that are no in corespondance with other in terme of design. But i prefer threat all those point later with concret and pre-package proposition. :-)
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4091394#4091394
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4091394
18 years, 3 months
[Design of POJO Server] - Re: New KernelBus lookup failure
by alesj
"alesj" wrote :
| simple 'name=DefaultDS,service=ManagedConnectionPool' service
This part is wrong. And I know why. :-)
I copied the name from jmx-console web site, which has domain name on top.
So that's why jboss.jca is missing.
And I also know why the difference in sizes.
And why I'm not able to find my service.
Going to bed early and thinking about this things always helps. :-)
The difference is in MBeans being registered through ServiceController, which doesn't add installed MBean to KernelRegister - since ServiceControllerContext doesn't implement KernelRegistryEntry.
Since all this code is org.jboss.kernel aware:
| ServiceController.java[(46, 8) |import| |org|.|jboss|.|kernel|.|Kernel|;, (47, 8) |import| |org|.|jboss|.|kernel|.|plugins|.|bootstrap|.|basic|.|BasicBootstrap|;, (48, 8) |import| |org|.|jboss|.|kernel|.|spi|.|dependency|.|KernelController|;]
| (46, 8) |import| |org|.|jboss|.|kernel|.|Kernel|;
| (47, 8) |import| |org|.|jboss|.|kernel|.|plugins|.|bootstrap|.|basic|.|BasicBootstrap|;
| (48, 8) |import| |org|.|jboss|.|kernel|.|spi|.|dependency|.|KernelController|;
|
| rg.jboss.system.metadata[ServiceInjectionValueMetaData.java[(32, 8) |import| |org|.|jboss|.|kernel|.|spi|.|config|.|KernelConfigurator|;, (33, 8) |import| |org|.|jboss|.|kernel|.|spi|.|dependency|.|KernelController|;],
|
| ServiceValueContext.java[(27, 8) |import| |org|.|jboss|.|kernel|.|Kernel|;, (28, 8) |import| |org|.|jboss|.|kernel|.|spi|.|dependency|.|KernelController|;]]
|
| ServiceInjectionValueMetaData.java[(32, 8) |import| |org|.|jboss|.|kernel|.|spi|.|config|.|KernelConfigurator|;, (33, 8) |import| |org|.|jboss|.|kernel|.|spi|.|dependency|.|KernelController|;]
| (32, 8) |import| |org|.|jboss|.|kernel|.|spi|.|config|.|KernelConfigurator|;
| (33, 8) |import| |org|.|jboss|.|kernel|.|spi|.|dependency|.|KernelController|;
|
| ServiceValueContext.java[(27, 8) |import| |org|.|jboss|.|kernel|.|Kernel|;, (28, 8) |import| |org|.|jboss|.|kernel|.|spi|.|dependency|.|KernelController|;]
| (27, 8) |import| |org|.|jboss|.|kernel|.|Kernel|;
| (28, 8) |import| |org|.|jboss|.|kernel|.|spi|.|dependency|.|KernelController|;
| org.jboss.system.server.jmx[JMXKernel.java[(46, 8) |import| |org|.|jboss|.|kernel|.|Kernel|;]]
|
| JMXKernel.java[(46, 8) |import| |org|.|jboss|.|kernel|.|Kernel|;]
| (46, 8) |import| |org|.|jboss|.|kernel|.|Kernel|;
|
it's probably the easiest way to add that ServiceControllerContext implements KernelRegistryEntry, and when the MBean is installed (in InstallAction) it is added to the KernelRegistry.
If so, what about the MBeans that are only running these actions: ServiceControllerContextActions.getLifecycleOnly() ?
I guess since InstallAction is currently an empty impl, adding InstallAction to LifecycleOnly won't be a problem?
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4091297#4091297
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4091297
18 years, 3 months
[Design of POJO Server] - Re: ManagedOperation aspects for the ProfileService.Manageme
by alesj
Regarding ManagedOperations (MOps).
How can we be sure that the MOps proxy change will take place?
Otherwise client will simply get plain ManagedOperationImpl serialized over.
This is what I questioned myself when trying to correctly impl ManagedPropertys.
Since WritethroughManagedPropertyImpl is exactly what we need on the server side, but we definitely don't want to push/serialize this to the client.
But if I change this similar to MOps, then the server side also sticks with simplified version.
Is there a way/mechanism to serialize something else to the client - other that hacky writeObject that would return not the class instance on which this is implemented.
Or should we transform every server side impl to client side impl on every client call/demand for MObjects, MComponents, ... ?
Or if we eventually used WrapperAdvice for MProps/Fields on server side, how to efficiently change this for the client?
I hope you understand what I'm rambling about. :-)
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4091240#4091240
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4091240
18 years, 3 months