[Design the new POJO MicroContainer] - Re: Need a NamedObject SimpleMetaType
by adrian＠jboss.org
"scott.stark(a)jboss.org" wrote : The name of the ManagedObject is generally not useful for referencing as its a DeploymentUnit attachment name. This is not usable for a datasource referencing a security domain whose deployment type and attachment type won't be known.
|
If the name is not usable then we should change it.
I remember putting a comment somewhere that I thought the current
use of the name was wrong.
IIRC, it is only currently used to know the key to which
the attachment should be put back in the attachments.
anonymous wrote :
| You don't think the Name type belongs here, the ManagedObjectRegistry, or both?
|
Both.
I don't expect that there will be a bus in the managed project, just the spi to allow references to be resolved.
Its also not sufficient to just have the name in the registry. I also need to be able to validate that the source the name is bound to supports the expected property type. I guess this requires the use of the GenericMetaType on the property and source to check that the expected type exists. However, if the source supports an extension of an interface the property wants, this cannot be determined from the classname comparision GenericMetaType supports. The source would have to declare a GenericMetaType for each interface.
Based on your "SecurityDomain" example then I don't see this as anything
more than a name with qualifier.
i.e. SecurityDomain/Default.
The trivial requirement could be served from the following
pseudo markup.
| public class ConnectionManagerMetaData
| {
| @ManagedObjectRef(type="SecurityDomain');
| public void setSecurityDomain(String securityDomain);
| }
|
| @MangedObject
| public class SecurityDeployment
| {
| @ManagedProperty
| Collection<SecurityPolicy> getPolicies();
| }
|
| public SecurityPolicyMetaData
| {
| @ManagedObjectID(type="SecurityDomain")
| public String getName();
| }
|
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4070629#4070629
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4070629
16 years, 9 months
[Design of JBoss jBPM] - Re: Failure handling
by bill.burke＠jboss.com
Ed, with the disclaimer that I've never written a jBPM application, doesn't it really depends who is driving the process. If user code is managing both the transaction and signaling the process, then you can handle this quite easily:
| userTransaction.begin();
| boolean rollback = false;
| try {
| process.signal();
| if (userTransaction.getStatus() == ROLLBACK CONDITION) {
| rollback =true; ut.rollback();
| else ut.commit();
| } catch (Exception ex) { rollback = true; userTransaction.rollback()}
|
| if (rollback) {
| ut.begin(); process.signal("failure");
| }
|
If the process is being driven by an asynchronous continuation or a user MDB, then you can use the DLQ or Transaction Synchronization ideas stated. I'm writing a blog about this very case. I'll link when I'm done.
As far as DLQ goes. Most(all?) major JMS providers have DLQ support. As for Transaction Synchronizations? You'd need access to TM yes. But there are well documented ways of obtaining the TM on each major application server. You just have to look. If you're in EE5, there is a TransactionSynchroniationRegistry that all vendors must provide.
Answer your questions?
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4070594#4070594
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4070594
16 years, 9 months
[Design of JBoss jBPM] - Re: Failure handling
by estaub
Tom,
I'm not at all sure, but I suspect we're thinking about different problems, or at least approaching them from different perspectives.
I'm not sure, but I suspect this is the context for the scenario Bill originally described. If not, I am guilty of 3rd degree thread-hijacking ;-)
An application has a set of preexisting EJBs (or other analogous components). These use CMT with a REQUIRED transaction attribute, so that multiple EJB calls can share a transaction. The EJB's frequently throw and setRollbackOnly(), most frequently because of gross concurrency issues. As an example, think of trying to reserve a seat on an airplane, but someone else got the last seat just before you clicked.
Now imagine a business process that tries to explicitly model the failure recovery in this case, either using exception handlers or anything else that can be expressed in JPDL.
How would you make the process model behave well, i.e., fairly WYSIWYG? Would you isolate the business logic (calling these EJBs) in a separate transaction in the actionhandler, as I was thinking?
I'm a little wary of trying to use fine-grained control of transactions (e.g. inserting end/begin pairs via TransactionManager when exceptions occur), because we run in multiple appservers (WebLogic, WebSphere, and now maybe JBoss) and I understand that they tend to behave differently. If you think I'm making a mountain out of a molehill, please say so - I'm just repeating hearsay!
I also suspect that in order to use TransactionManager, we'd need to avoid participating in any surrounding CMT transaction - I'd think that the container would freak out if we ended it's Container-Managed-Transaction and started another within a CMT EJB. Do you have any experience with this?
-Ed Staub
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4070577#4070577
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4070577
16 years, 9 months
[Design of JBoss ESB] - Re: MessageType design
by mark.little＠jboss.com
"tcunning" wrote : I think I agree with Kurt on CommandMessage - I'm not sure it really has to be a special type of ObjectMessage.
|
Maybe. It seemed to fit the simplification/view approach.
anonymous wrote :
| For the stats gathering, I think we were planning on excluding all CommandMessages from the counts - basically because there's the potential for them to skew the statistics a great deal.
|
| We're going to have to check each Message to see if it is a CommandMessage, so whatever allows you to determine that should be pretty lightweight, especially if there are a lot of Messages being processed by the ESB. Is isCommandMessage going to be fast enough?
It should be fast enough. All it's doing is looking at the presence (or absence) of the command name in the Body.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4070490#4070490
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4070490
16 years, 9 months
[Design of JBoss ESB] - Re: MessageType design
by mark.little＠jboss.com
"kurt.stam(a)jboss.com" wrote : It looks like we copied the JMS message types of: BytesMessage, MapMessage, ObjectMessage, StreamMessage and TextMessage
|
Not quite. There's no StreamMessage.
anonymous wrote :
| I see the following issues with the current implementation:
|
| 1. There are no interfaces for them in our implementation, so our Message
| will not actually 'be' one of these types. You'll have to do Message.getPayload() and then figure out what type this it by using getInstanceOf().
|
There's no such operation Message.getPayload. You mean Payload.getPayload, I think.
But yes, that's essentially correct. Without changing interfaces to existing infrastructure (and potentially breaking existing deployments), these simply represent different views on to the underlying Message Body contents.
anonymous wrote :
| 2. We have left the old body implementation, so we have a body and a payload-body as I understand it. This is confusing. I mean I can still do msg.getBody.add("kurt", "Stam") and ignore the new payload stuff.
|
We cannot remove Body because it is the underlying Message structure that supports more than any of these views allow. It's more powerful. These are simplifications for users who know they only want to send text, Serialized objects etc.
anonymous wrote :
| 3. CommandMessage is listed at the same level as BytesMessage, but I think a CommandMessage is more at the ESB logical level. It has nothing to do with the implementation of the message. Maybe we can simple add
| a Message.property of MESSAGE_TYPE for this? No need to have a different API for this type of message.
|
Possibly. It's just another simplification view. At present it supports type (what type of CommandMessage) and a serialized object. Since we don't have any of these CommandMessage implementations yet, it's hard to argue for or against.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4070488#4070488
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4070488
16 years, 9 months