July 2009 - jboss-dev-forums - Jboss List Archives

[Design the new POJO MicroContainer] - Re: Parallel deployments

by kabir.khan＠jboss.com

"smarlow(a)redhat.com" If we were to asynchronously deploy in named threads, that might require a separate thread pool.[/quote wrote : | if we are to tie beans to named threads, we could use an annotation on the bean's metadata beans.xml to specify the name of the thread. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4245411#4245411 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4245411

16 years, 8 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: Parallel deployments

by kabir.khan＠jboss.com

"kabir.khan(a)jboss.com" wrote : When looking at http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4243667 I realised that I have not tested/handled the following scenario: | | *Install ctx A asynchronously | *Uninstall ctx A while is is being installed asynchronously. | | I will add support for this This is now implemented and tested View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4245410#4245410 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4245410

16 years, 8 months

1
0
0 / 0

[Design of JBoss ESB] - Re: Http Gateway - requirements please...

by dward

Cross-referencing: http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4245398#4245398 View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4245399#4245399 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4245399

16 years, 8 months

1
0
0 / 0

[Design of JBoss ESB] - Re: SOAPProxy Enhancements

by dward

d) Integration with http-provider. http-provider is being re-worked in 4.7: http://www.jboss.org/index.html?module=bb&op=viewtopic&t=157057&start=32 I respect Kev's comment: "Kevin.Conner(a)jboss.com" wrote : can we please get the http gateway working first before we go off track and implement other features? , however I just want to make sure we don't implement anything that would preclude the following two enhancements, based on a URL that looks something like: http://host/context/http/${service.category}/${service.name} 1. Possibly introduce a new property on SOAPProxy, like: <property name="publish" value="true"/> , similar to EBWS's ability to auto-publish an endpoint. This way you don't have to define an http-provider or http-listener. The default for this would be false, but if true, it would go with some sensible defaults. 2. Make sure that wsdl is available via the http-provider for published SOAPProxy endpoints via the "?wsdl" suffix convention: http://host/context/http/${service.category}/${service.name}?wsdl This could be implemented via a simple servlet/filter that just request-dispatches to the wsdl already exposed via the contract app. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4245398#4245398 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4245398

16 years, 8 months

1
0
0 / 0

[Design of JBoss ESB] - SOAPProxy Enhancements

by dward

In 4.6, the SOAPProxy class was added, which is an easy mechanism to proxy an external web service via the bus. All that is required is the original wsdl location, whose endpoints get transformed so consumers go through the bus. Further wsdl transformation can be configured via Smooks, and you can also optionally transform the soap envelope before and after the proxying, via the new XsltAction, or via the SmooksAction. Also, for soap-over-http, any of the HttpRouter properties can be set as properties on the SOAPProxy. For 4.7, I would like to propose a few enhancements: a) Support Basic Auth. This was an oversight on my part, and is documented in this Jira: https://jira.jboss.org/jira/browse/JBESB-2759 b) (a) is the minimal requirement. I'm wondering if we might want to do more with this, maybe introduce the notion of a "runAs"? c) HttpRouter property overrides per endpoint address. Currently, any HttpRouter properties can be set as properties on the SOAPProxy, since SOAPProxy (actually HttpSOAPProxyTransport) wraps usage of HttpRouter, setting sensible HttpRouter defaults. A distinct HttpSOAPProxyTransport is created per endpoint address, however any HttpRouter overrides set at the SOAPProxy level are shared for each endpoint address. This is a bad assumption, as what if you wanted different overrides per endpoint address? I propose keeping having the notion of a 3-tier property configuration: 1. If no HttpRouter properties are set on SOAPProxy, the default HttpRouter properties coded inside HttpSOAPProxyTransport take effect. This is current behavior and would remain. 2. If HttpRouter properties are set on SOAPProxy, they can override those coded inside HttpSOAPProxyTransport, however across all wsdl-defined endpoint addresses. This supercedes #1. This is also current behavior and would remain. 3. NEW: Add the ability to override HttpRouter properties per endpoint address, as nested properties. This supercedes #2 and #1. The question is, "What should the property names be / how can they be distinguished?" I thought of a couple options, first being the binding QName: <property name="{http://foo/oof}FooBinding"> second, being the actual soap:address location: <property name="http://host1/foo/FooWS"> I like the second option best, as that is really most about the transport itself, so here's what it would look like: <action name="..." class="...SOAPProxy"> | <property name="wsdl" value="...?wsdl"/> |  | <property name="method" value="POST"/> | <property name="http://host1/foo/FooWS"> |  | <property name="responseType" value="STRING"/> | </property> | <property name="http://host2/bar/BarWS"> |  | <property name="responseType" value="BYTES"/> | </property> | </action> In code, I would just find all properties starting with "http" to give to the HttpSOAPProxyTransport for it's HttpRouter overrides. In the future (when a JmsSOAPProxyTransport gets added, for example), I might look for properties starting with "jms" for overrides. Or SmtpSOAPProxyTransport... Also note the tier 3 elements are still called "property". This is a free-form content section (xsd:any), so this could have been "transport-property" or similar, however I would prefer just "property" for consistency at either tier. Thoughts? Opinions? Questions? Concerns? View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4245387#4245387 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4245387

16 years, 8 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: PagingManager activation

by clebert.suconic＠jboss.com

Sorry for the delay.. I was trying to look for a good reason. Maybe it could be done like that. It would just need to be tested. I'm doing it this way, because I believe this is the way we also start the server. When the server is started, I start global depage on all the destinations that were being depaged before. If this is bringing you problems (or if you see a problem) I can take a look. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4245369#4245369 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4245369

16 years, 8 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Large Messages and the JMS Bridge

by clebert.suconic＠jboss.com

This is a discussion for https://jira.jboss.org/jira/browse/JBMESSAGING-1601 Once you received a LargeMessage, as soon as you consume another message you can't move back to an already received message. This is explained at 22.6 on the user' s doc: http://labs.jboss.com/file-access/default/members/jbossmessaging/freezone... But it happens that the JMS Bridge is caching messages, and it needs to eventually go back and reprocess messages. I was looking around the code, and I can think of two options to fix it: - Ressurrect the option for FileConsumers. (This would be optional. and all could be controlled within the LargeMessageBuffer). This would be a good option for users caching messages in other scenarios. And this is my preferred option. - Make the JMSBridge aware of LargeMessages. I could have some JMS property identifying a message as LargeMessage, and the JMSBridge won't cache those messages. - Make the user to turn of caching on the bridge. (I don't like this option. I would prefer the Bridge dealing with it automatically). View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4245368#4245368 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4245368

16 years, 8 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Transaction management in JCA adapter is screwed up

by timfox

Are you allowing Clebert's suggestion of batching too? View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4245314#4245314 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4245314

16 years, 8 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - MessagingXAResourceRecovery configuration

by jmesnil

related to https://jira.jboss.org/jira/browse/JBMESSAGING-1506 currently, the MessagingXAResourceRecovery depends on JMS and JNDI to retrieve the JMS XASession used to recover. The information is passed as a String in jbossts-properties.xml: | <property name="com.arjuna.ats.jta.recovery.XAResourceRecovery.JBMESSAGING1" | value="org.jboss.messaging.jms.server.recovery.MessagingXAResourceRecovery;$jndi,$user,$password" /> | where $jndi is the JNDI lookup for the XAConnectionFactory and $user and $pass are the (optional) user credentials. We can get rid of the dependencies to JMS and JNDI as JBoss Messaging Core API exposes its ClientSession as a XAResource directly. In order to use a ClientSession we need to create a ClientSessionFactory from inside the MessagingXAResourceRecovery. The only constraint is that the single input we have to this class is the String passed to its initialise() method. There are 2 possibilites: 1. Pass all the informations required to create the ClientSessionFactory under a serialized form directly in the String 2. Put all the information in a configuration file and pass the file configuration name to the MessagingXAResourceRecovery and read the content from there #1 is simpler. If we constraint to only support a connection to a single live server, the initialization string would be: "$connectorFactoryClassName, $user, $pass, key1=val1, key2=val2" This would be enough to create a TransportConfiguration with the class name and the parameters. Then we could create a ClientSessionFactory and a ClientSession (with the optional user credentials) However this limits the type of connection supported by the recovery to a single server. Does it make sense for JBM 2 to have the TM recover from something else than the Messaging Server embedded in the same server instance than the TM? If that's the case, we could put the client session factory in a separate configuration file (with the support of whole stuff, discovery, live and backup servers, etc.) and read this config file from the MessagingXAResource. The cons is that it means yet another configuration file and it may be too complex for 80% (99%?) of the case where the TM will recover the messaging resources from the same server. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4245306#4245306 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4245306

16 years, 8 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Transaction management in JCA adapter is screwed up

by ataylor

Ive implemented this with the following changes. anonymous wrote : 2) CMT, tx=NOT_SUPPORTED, local_optimisation = true | | MDB should be *non transacted* - it should use the ack mode as specified in the meta data Ive made this option so that it uses the a local tx, this is to allow the user to run with *only* a single local tx. see next. anonymous wrote : 4) CMT, REQUIRED, local_optimisation = true | | MDB should create a *** local tx *** *before delivery* and commit at completion of onMessage When 'REQUIRED' is chosen then the container will always create a global tx no matter what. This happens when the call is made to endpoint..onMessage(message) method (endpoint is a proxy and creates the tx before the actual call to the MDB's onMessage). This means that there would be a local proxy and a global proxy. I've left this configurable and i'll explain fully in the docs how local optimization works. anonymous wrote : 5) BMT, local_optimisation = false: | | MDB should be *non transacted* - it should use the ack mode as specified in the meta data (unless a user transaction is started) The ack mode is always used. The outcome of a user transaction when used in an MDB has no effect on the actual delivery. anonymous wrote : 6) BMT, local_optimisation = true | | MDB should be *non transacted* - it should use the ack mode as specified in the meta data (unless a user transaction is started) I've allowed the user to be able to use local tx's if they want. because of the reason mentioned for 5). This means that if an exception is thrown from inside the MDb the user can have the message redelivered. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4245305#4245305 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4245305

16 years, 8 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-dev-forums July 2009