[Design of JCA on JBoss] - Programmatic deployment--Redux
by weston.price＠jboss.com
Finally have been able to get back on this. I have been looking at the new Deployer framework and the *-ds.xml deployer is a unique case in that it falls somewhere in the middle of an ObjectModelFactoryDeployer and a JaxpDeployer. Effectively there are two steps
1) parse the *-ds.xml
2) generate the metadata (somehow)
I have a working model of the new DsParserDeployer and the new DsDeployer. While it's not too bad, I just get the feeling that something is wrong. Don't know why, but it just seems like a lot of useless work for the following reasons:
a) The parsing
While I am no fan of JBossXB, I am equally reluctant to use straight JAXP for the otherwise mindless task of databinding. The initial implementation was written with JBossXB and I have started on a DsParser that uses straight JAXP to parse the *-ds.xml file. Neither seem ideal to me. This is just one of those tasks that I think other tools can handle better. I
b)The *-ds.xml format
While compatiblity is important, I don't see why we can't keep the XSLDeployer and with JBoss5 release a new deployment format fo MCF's...call it *-dsx.xml. We could generate a schema and get rid of stuff like arbitrary MBean definitions that make the parsing more complex that what it really needs to be. Further, with an XSD it would open up other options as to the binding rather than having to contend with a DTD that quite frankly none of us are all that dilligent in updating.
c)
The MBean generation. This actually isn't so bad after I looked at the new stuff. However, with the *-ds.xml format there is always the MBean stuff to contend with. Clearly we are going to replace this with MC at some point, but for now, it's still annoying.
So..my proposal
Chuck this mess. Write an XSD, lock it down and use *some* binding framework to generate the meta data and do the binding. Otherwise I don't see anyway around the ugliness that's going to be associated with either maintaining the JBossXB factory or the JAXP parsinng code. Once we start going down that path (actually have gone down it twice now) the code becomes no more maintainable that the XSL, in fact, I would argue that it's worse, solely for the fact that if a property needs to be added to the *-ds.xml file suddenly it has to chage in
1) The parser (JBossXB or JAXP)
2) The metadata
3) The JCA object itself (Pool, CM)
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3987514#3987514
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3987514
19 years, 4 months
[Design the new POJO MicroContainer] - ControllerState Details ...
by vickyk
| public AbstractController() throws Exception
| {
| addState(ControllerState.NOT_INSTALLED, null);
| addState(ControllerState.DESCRIBED, null);
| addState(ControllerState.INSTANTIATED, null);
| addState(ControllerState.CONFIGURED, null);
| addState(ControllerState.CREATE, null);
| addState(ControllerState.START, null);
| addState(ControllerState.INSTALLED, null);
| }
|
Can I get some description about the above specified states ?
Normally I would have expected CREATE,START,STOP,DESTROY states . The default one being the NOT_INSTALLED .
Do we have some wiki explaining this ?
The above code is from the dependency module AbstractController class .
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3987467#3987467
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3987467
19 years, 4 months
[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Incorporating Remoting http transport into Messaging
by ovidiu.feodorov＠jboss.com
Ron,
I've done a first pass over your changes. I have several questions/things to fix:
1. Is jboss-remoting.jar in lib 2.2.0.Alpha3, or it contains private changes? If it contains private changes, I need the source code, or better still, check in your changes on the Remoting 2x branch and tag it somehow, so I can get the right snapshot.
2. Looks like we need tomcat-http.jar, tomcat-util.jar, etc. This is fine, but Messaging should not guess what version is needed, the build process should pick this information automatically from Remoting's component-info.xml in the repository. Take a look at serialization's http://repository.jboss.com/jboss/serialization/1.0.3.GA/component-info.xml , see how Clebert declared a dependency of a specifc release of trove. Remoting needs to do the same thing with tomcat. Now I am using an arbitrary tomcat version declared in build-thirdparty.xml, and this is not correct.
3. CallbackManager: why is the lookup value calculated based on consumerID AND serverID. Can a CallbackManager receive callbacks originating from different servers? Why is serverID needed there?
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3987456#3987456
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3987456
19 years, 4 months
[Design of JBoss Portal] - JBoss Portal User Account Management Question
by andytsoy
Dear all,
Platform: JBoss 4.0.3sp1 + JBoss Portal 2.2.1sp1
I am writing a portlet to handle user deletion. Could anyone help me to fix. The code for deleting the user as below:
User user = userModule.findUserByUserName(username);
userModule.removeUser(user.getId());
where username is the user to be deleted
But it throws the following exception:
[STDOUT] java.lang.reflect.UndeclaredThrowableException
[STDOUT] at $Proxy149.removeUser(Unknown Source)
.
.
.
.
.
.
.
.
[STDOUT] Caused by: java.lang.NoSuchMethodException: Unable to find operation removeUser(java.lang.Object)
[STDOUT] at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:209)
[STDOUT] at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:644)
[STDOUT] at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:176)
-------------------------------------------------------------------------------------
I also try to put
User user = userModule.findUserByUserName(username);
userModule.removeUser(user);
But it throws the same exception, I also check for the library portal-core-lib.jar, the class contains the method removeUser(Object), I really have no idea on how to solve it. Please help me . Thank you!
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3987451#3987451
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3987451
19 years, 4 months
[Design of JBoss jBPM] - Task Management
by hriver
We are evaluating jBPM for the purpose of replacing the custom work flow components of our operational support systems. We have two systems which have been in production for roughly five years and a couple of other systems with work flow requirements on the horizon.
We have run into difficultly with the way task instances are managed within jBPM and were hoping to get some feedback.
To start with, we view a task list as representing the tasks which can be performed on a particular process instance in it's current state. So if a user were to bring up an order (process instance), the task list would show the tasks which could be performed on the order at that time. We were hoping to back the task list with jBPM task instances. Hopefully there is nothing too unreasonable here.
One problem we run into is with with an optional task - a task which is valid (but not required) in one particular node, but is not valid in any other node. The task list needs to contain the task while we are in node B, but once we move to node C it should be removed. If we simple define the task on node B it will remain open until it is completed, even if we transition to node C (where it is no longer valid) or even if the process instance completes (when it certainly is not valid). If the task is valid and optional in multiple nodes we have another problem in that now multiple instances of the same task may exist as open. Is there any mechanism for supporting this type of scenario within a process definition? Should we not even attempt to represent these types of tasks on the process definition? Is it reasonable to modify the task instance management to remove any incomplete task instances on leaving a task node?
Another probelm area is with tasks which can be performed multiple times. If we call end() on the task instance when it is completed the instance will no longer be open and we will need to create another instance to get it into the task list. If we do not call end() we lose the event notification and history. Any suggestions?
We would also like to give the process designer greater ability to specify when a transition should be taken, especially based on the completion of a particular task. Given the task node signal property and a decision node there is some support for this, but it does not seem to be sufficent when dealing with multiple transitions or tasks (this particluar problem seems to somewhat covered in the Two Transfer Definitions thread). "It would be nice" to simple specificy on a task that a particular transition should be taken when it's complete. For more complex scenarios something along the lines of DecisionHandler might be a better solution. Do either of these solutions sound reasonable? Any other suggestions?
We would appreciate any help you can offer.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3987446#3987446
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3987446
19 years, 4 months