[Design of POJO Server] - Re: Unifying metadata
by adrian＠jboss.org
"scott.stark(a)jboss.org" wrote : I wasn't sure how much of the old metadata should be usable as a drop in replacement. So it seems that the code that will have to change is the parsing related uses.
|
Any parsing related uses will need to be updated to the new parsing anyway.
anonymous wrote :
| There are also classes missing like org.jboss.metadata.ClientMetaData, but this and the ClientDeployer should be replaced by the ejb3 parsing deployer versions. Getting the metadata out of the server project is what I'm looking at first.
|
I only got as far as parsing the root j2ee/avaee and ejb2/3 xml (and even then
I didn't do the webservices stuff).
The others like client, web and connector stuff probably needs to be brought into line
if it is relevant. i.e. it is necessary to share the same model with/across EJB2/3
for some reason.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4086222#4086222
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4086222
18 years, 6 months
[Design of EJB 3.0] - Re: Component Proposal - Configurable Service Locator
by ALRubinger
Going to bring this one back and continue development looking forward.
I'm looking to limit the scope (for this first phase) of this component to the following points, which I find lacking in the JEE5 Spec for Application Clients. Eventually I'd like to work this into the Client Container/Deployer as a JBoss extension to the spec - I'm not looking to compete, but enhance.
* Support N Remote Hosts
* Provide programmatic access to remote services/beans (non-injected)
* Allow lookup outside of "main" class
anonymous wrote : EE9.4, Second Paragraph:
| Injection is also supported for the application client main class.
* Allow runtime lookup
anonymous wrote : EE9.4, Second Paragraph:
| Injection occurs before the main method is called.
* Provide caching facility for non-SFSB
* Dont restrict to "java:" namespace
anonymous wrote : EE9.4, First Paragraph:
| Application clients use the java: JNDI namespace to access these items.
The moving parts I'm proposing and will be working on:
Client-side Library
Will be charged with:
* Performing lookups
* Caching
* Requesting of the configured hosts which services are available
This is currently being re-written from a working implementation I've been using for the past year or so, and is housed in "projects/ejb3/trunk/locator". There is no formal build or POM as it stands, but I'll be adding these shortly when things are more stable and the refactoring has progressed.
EJB3Registrar
I believe this speaks to Bill's points about determining JNDI bindings, but also addresses a cross-reference to the business interfaces implemented by the EJB. Will be implemented as a POJO and deployed in ejb3-deployers-beans.xml; also to be exposed as an MBean for outside access.
Integration
On successful deployment of an EJB3 Deployable Unit (in "deploy" of EJBStage2Deployer?) , register with the new EJB3Registrar the EJBContainer and draw relationships between the implemented business interfaces and the resultant JNDI Addresses. Haven't fleshed this out yet.
S,
ALR
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4086199#4086199
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4086199
18 years, 6 months
[Design of JBoss ESB] - Re: Failover MessageRedelivery
by beve
I'm going to try describe this and hopefully this will be clearer.
I'll first show the configuration for a single service and then list the changes that we needed to make to get this working for us.
We are going to use this solution in production shortly.
Service : jboss-esb.xml
| <actions>
| <action name="PersistMessageOnEnter" class="org.jboss.soa.esb.actions.MessagePersister" >
| <property name="classification" value="TicketService-Cl"/>
| <property name="ignore-message-classification" value="true"/>
| <property name="message-store-class" value="org.jboss.internal.soa.esb.persistence.format.db.DBMessageStoreImpl"/>
| </action>
|
| <action name="Catch all Exceptions Action" class="xxx.exceptions.ExceptionHandlingAction" >
| <property name="exceptionMethod" value="catchesException" />
| <property name="replyTo-ServiceCategory" value="TicketService" />
| <property name="replyTo-ServiceName" value="TicketInformationResponse" />
| <property name="redeliver-ServiceCategory" value="TicketService" />
| <property name="redeliver-ServiceName" value="TicketInformationService" />
| <property name="classification" value="TicketService-Cl" />
| <property name="rdlv-classification" value="TicketService-Cl-RDLV" />
| <property name="retries" value="3" />
| <property name="undeliverable-classification" value="IPL_ERR_TicketService-Cl-RDLV"/>
| </action>
|
| ...actions that to the real work (transform,validate,poll webservices...)
| <action name="RemoveMessageOnExit" class="org.jboss.soa.esb.actions.MessagePersister"
| process="removeMessage">
| <property name="classification" value="TicketService-Cl"/>
| <property name="ignore-message-classification" value="true"/>
| <property name="message-store-class" value="org.jboss.internal.soa.esb.persistence.format.db.DBMessageStoreImpl"/>
| </action>
| </actions>
|
org.jboss.soa.esb.actions.MessagePersister
Has been updated so that one can specify that the classification that has been set as a property on the ESB Message object should be ignored. This is needed in the case where the message is being redelivered and would in our case would have a classification with the suffix "_RDLV". We want the message to be saved to the message store with a suffix of "_Cl" (Classification) upon entry to the service. The same logic is behind the action named "RemoveMessageOnExit" which should always remove the message from the store on exit.
We also have a redelivery service for every service:
| <listeners>
| <scheduled-listener name="redeliver-scheduled-listener"
| scheduleidref="rdlv-trigger"
| event-processor="xxx.redeliver.RedeliverEventMessageComposer">
| <property name="classification" value="TicketService-Cl-RDLV"/>
| </scheduled-listener>
| </listeners>
|
Our custom RedeliverEventMessageComposer is identical to the one in services/jbossesb the only difference being that the classification is configurable.
xxx.exceptions.ExceptionHandlingAction
| public void catchesException(Message message, Throwable exception)
| {
| log.debug( " ############### Caught Exception #############" );
| log.debug( "Exception was : " + exception.getMessage() );
|
| if ( exception instanceof ActionProcessingFaultException )
| message = ((ActionProcessingFaultException)exception).getFaultMessage();
|
| final URI messageURI = (URI) message.getProperties().getProperty( MessageStore.MESSAGE_URI );
|
| final Message messageFromMessageStore = getMessageFromMessageStore( messageURI );
|
| if ( checkRetries( messageFromMessageStore ) )
| {
| addForRedelivery( messageFromMessageStore );
| }
| else
| {
| messageFromMessageStore.getProperties().remove( RETRY_COUNT );
| addToMessageStore(messageFromMessageStore, undeliverableMesssageStoreClassification);
| }
|
| removeMessageFromMessageStore( messageURI );
| setErrorMessage(message, exception);
| setReplyTo(message);
|
| log.debug( " ############### Caught Exception done #############" );
| }
|
1. We retreive the message that was stored upon entring the service.
2. We check if the we have reached the number of retries specifiec in the configuration (property name="retries" value="3")
3. If "retries" has not been reached, we store the message with the redelivery classification specified in the configuration.
4. If "retries has been reached, we store the message with the undeliverable classification specified in the configuration.
5. We remove the message that was saved upon entry to the service.
6. We set an error message to the message object with a stacktrace and some other information.
7. Set the reply to for the message according to the configuration.
This gives us a simple mechanism for error handling and a way to try automatic redelivery and also minimizes the risk of loosing messages.
This also gives us a way to force messages to be redelivered by simply updating their classification in the message store database.
As said in a previous post this is a short term solution as we need this right now, and we will be building a more complete error handling process in the coming months.
Any thought or comments are appreciated.
Thanks,
Daniel
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4086161#4086161
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4086161
18 years, 6 months