[mauromol]

Hi Andrew,

this is great work, thank you very much! I will certainly try the new XTS version as soon as it gets released (I don't know if I will be able to do that before)!

From what I understood reading your post here and the comment on the JIRA issue, this sounds to be a huge improvement.

On a first thought, these are some further suggetions:

SEARCHING FOR THE CONFIGURATION

I'm not really sure I understood how the xts-properties.xml is found. I mean, if you use ClassLoader.getResourceAsStream("xts-properties.xml") from a class of ws-c11.jar, shouldn't xts-properties.xml be located on the same package of the calling class? Or can it be deployed also in the root of the classpath?

Anyway, I would suggest to improve this further in order to be able to customize the position of xts-properties.xml; one solution could be to use the same mechanism of JBossTS Core/JTA (which tests the presence of its configuration files in different locations, like the root of the classpath, the user home, one specified through system property and so on). However, an even better solution would be to also support dependency injection, so that one could specify the path to xts-properties.xml before the XTS initialization code has started, and this could be done by Spring for instance. In this way I could deploy xts-properties.xml wherever I want and I would not be forced to use System properties (which are not suitable in a container environment... suppose you have more than one webapps deployed on an application server, each of which embeds its own JBossTS instance...).

Even better, the configuration system could optionally support injecting configuration properties as a Properties instance: in this way I would not be bound to an xts-properties.xml, but I could store my configuration in whatever format I want (and wherever I can get it back at dependency injection time) and supply it to XTS without it even boring about finding xts-properties.xml.

This dependency injection suggestions are also valid for JBossTS Core/JTA. Do you suggest I open a JIRA for this?

ENDPOINT CONFIGURATION

There's one thing not yet clear to me. How XTS knows the corrent paths (besides the host names and ports) to the different WS-T/WS-C/WS-AT endpoints?

In one of your previous messages, you said that I may have had to tweak the code a bit if I arbitrarily chose the deploy path to my service endpoints (through CXF). Is it possible to configure this aspect with the new configuration architecture without touching the XTS code?

Thanks in advance,

Mauro.

[mauromol]

Meanwhile I haven't stopped experimenting with the 4.11 version of XTS. I'm trying to get an even simpler scenario (compared to the XTS demo)  where the transaction infrastructure is only used to output messages to the System.out.  I just want to see the whole thing working. I'm not using the bridge for now.

So I did the following. I set up three different web applications, one for the client, one for the coordinator and one for the server. Every webapp has Spring, CXF, Log4j support in it. Every webapp has the JARs of JBossTS JTA, XTS-API and all the JARs I determined were needed in order to make the  webapp start. Every webapp, at startup, manually starts the JBossTS core through a call to com.arjuna.ats.arjuna.coordinator.TxControl.enable(), while at shutdown it  stops the core with a call to com.arjuna.ats.arjuna.coordinator.TxControl.disable(boolean) followed by  com.arjuna.ats.arjuna.coordinator.TransactionReaper.terminate(boolean).

Moreover, every webapp calls org.jboss.jbossts.XTSService.start() at startup  (after injecting the bind address and port) and org.jboss.jbossts.XTSService.stop() at shutdown. The XTSService.start() code has been changed in order to replace  the use of the JBoss Logger with a plain Log4j logger and it has been customized on each webapp, as reported in the following sections.

These are the  thing I deployed on each webapp:

SERVER

Initialisation listeners:

1) com.arjuna.webservices11.wsat.server.ParticipantInitialisation

2) com.arjuna.wst11.messaging.deploy.TransactionInitialisation (this closes the WS-T sequence)

3) com.arjuna.mw.wst11.deploy.WSTXInitialisation (this closes the WS-TX sequence)

(in this order)

Service endpoints:

1) wsat-participant-binding.wsdl

    handler-chain: handlers.xml from ws-t11.war

XTSService.start() changes:

1) removed the BA recovery modules initialisation cod

Application code:

1) a very simple webservice (called TestService) is published;  this has com.arjuna.mw.wst11.service.JaxWSHeaderContextProcessor registered as the only handler class

The service is  defined with Spring as:

<jaxws:endpoint id="testService"
      implementor="test.TestServiceImpl"
      address="/TestService" >
      <jaxws:handlers>
           <bean class="com.arjuna.mw.wst11.service.JaxWSHeaderContextProcessor" />
      </jaxws:handlers>
</jaxws:endpoint>

COORDINATOR

Initialisation listeners:

1) com.arjuna.webservices11.wsat.server.CompletionCoordinatorInitialisation

2) com.arjuna.webservices11.wsat.server.CoordinatorInitialisation

3) com.arjuna.wst11.messaging.deploy.TransactionInitialisation (this closes the WS-T sequence)

4) com.arjuna.webservices11.wscoor.server.ActivationCoordinatorInitialisation

5) com.arjuna.webservices11.wscoor.server.RegistrationCoordinatorInitialisation

6) com.arjuna.wsc11.messaging.deploy.CoordinationInitialisation (this closes the WS-C sequence)

7) com.arjuna.mw.wsc11.deploy.WSCFInitialisation (this closes the WS-CF sequence)

(in this order)

Service endpoints:

1) wsat-completion-coordinator-binding.wsdl

    handler-chain: handlers.xml from ws-t11.war

2) wsat-coordinator-binding.wsdl

   handler-chain:  handlers.xml from ws-t11.war

3) wscoor-activation-binding.wsdl

    handler-chain: handlers.xml from ws-c11.war

4) wscoor-registration-binding.wsdl

    handler-chain: handlers.xml from ws-c11.war

XTSService.start() changes:

1) removed the BA recovery modules initialisation code

Application code:

<none>

CLIENT

Initialisation listeners:

1)  test.CompletionInitiatorInitialisationEx (extends com.arjuna.webservices11.wsat.server.CompletionInitiatorInitialisation to close the WS-T11 sequence)

Service endpoints:

1) wsat-completion-initiator-binding.wsdl

    handler-chain: handlers.xml from ws-t11.war

XTSService.start() changes:

1)  removed all the recovery modules initialisation code

Application code:

1) a webservice client to TestService with the following handler registered:  com.arjuna.mw.wst11.client.JaxWSHeaderContextProcessor

This client is defined with Spring as:

<jaxws:client id="testServiceClient"
      address="http://localhost:8080/xts-server/services/TestService"
      serviceClass="test.TestServiceInterface" >
      <jaxws:handlers>
          <bean class="com.arjuna.mw.wst11.client.JaxWSHeaderContextProcessor" />
      </jaxws:handlers>
</jaxws:client>

2) a servlet which uses the client and that I invoke using my browser to test the whole thing. This servlet simply does the following:

// client is the webservice client from the Spring beans container
com.arjuna.mw.wst11.UserTransaction ut = com.arjuna.mw.wst11.UserTransactionFactory.userTransaction();
try
{
  ut.begin();
  client.doOperation("hello world");
  ut.commit();
}
catch(Exception e}
{
  e.printStackTrace();
}

The situation is the following: all the webapps start correctly, without any errors. However, when I execute the client servlet code, I get a NullPointerException because ut is null. I'm going to debug the code, however, if you have suggestions you are welcome.

Thanks in advance,

Mauro.

[adinn]

Mauro Molinari wrote:

this is great work, thank you very much! I will certainly try the new XTS version as soon as it gets released (I don't know if I will be able to do that before)!

Good. These changes should be available in JBossTS 4.13 which will is currently scheduled for release in October.

I'm not really sure I understood how the xts-properties.xml is found. I mean, if you use ClassLoader.getResourceAsStream("xts-properties.xml") from a class of ws-c11.jar, shouldn't xts-properties.xml be located on the same package of the calling class? Or can it be deployed also in the root of the classpath?

Yes, you are expected to package xts-properties.xml with the XTS code in your dpeloyment. It is not packaged in the sar because we use a jboss-beans.xml file in its place. However, if we were to use the properties file it would be placed in the root of the sar deployment. You can also deploy it in any of the directories contained in the java classpath.

Anyway, I would suggest to improve this further in order to be able to customize the position of xts-properties.xml; one solution could be to use the same mechanism of JBossTS Core/JTA (which tests the presence of its configuration files in different locations, like the root of the classpath, the user home, one specified through system property and so on). However, an even better solution would be to also support dependency injection, so that one could specify the path to xts-properties.xml before the XTS initialization code has started, and this could be done by Spring for instance. In this way I could deploy xts-properties.xml wherever I want and I would not be forced to use System properties (which are not suitable in a container environment... suppose you have more than one webapps deployed on an application server, each of which embeds its own JBossTS instance...).

Even better, the configuration system could optionally support injecting configuration properties as a Properties instance: in this way I would not be bound to an xts-properties.xml, but I could store my configuration in whatever format I want (and wherever I can get it back at dependency injection time) and supply it to XTS without it even boring about finding xts-properties.xml.

This dependency injection suggestions are also valid for JBossTS Core/JTA. Do you suggest I open a JIRA for this?

No,don't bother with a JIRA. If you want to use dependency injection then you can forget about deploying the property file altogether. Insetad just use the same approach as we do in JBoss AS where we inject configuration as specified in file jboss-beans.xml. You need to get your injection framework to invoke the setters on the various configuration beans, WSCEnvrionmentBean, WSTEnvironmentBean etc. You can get the singleton instance of these beans by calling the factory method on XTSPropertyManager. If you look at the beans file it should be obvious how to proceed. For example, here is the entry for the WSCF bean:

    <bean name="XTS:WSCFEnvironmentBean">
        <constructor factoryClass="org.jboss.jbossts.xts.environment.XTSPropertyManager"
            factoryMethod="getWSCFEnvironmentBean"/>

        <property name="protocolImplementations">
            <list elementClass="java.lang.String">
                <value>com.arjuna.mwlabs.wscf11.model.twophase.arjunacore.TwoPhaseHLSImple</value>
                <value>com.arjuna.mwlabs.wscf11.model.sagas.arjunacore.SagasHLSImple</value>
                <value>com.arjuna.mwlabs.wst11.at.ContextFactoryImple</value>
                <value>com.arjuna.mwlabs.wst11.ba.ContextFactoryImple</value>
            </list>
        </property>
    </bean>

This bean entry configures the list of protocol implementations which were defined in xts-properties.xml using the prefix property org.jboss.jbossts.xts.protocolImplementation. The same applies fo rthe WST, WSC, Recovery and Initialisaton beans. For each property or set of common prefix properties in the properties file there is a corresponding bean and bean field into which you can inject your configuration values. The factory methods on XTSPropertyManager return a unique instance of each configuration bean. The properties in each <bean/> entry all have corresponding setters which the AS uses to inject the values defined in the beans file. I don't use Spring but I assume you can wire it to do exactly the same sort of injection before you call XTSService.start.

Anyway, in order to help anyone who still wants to use a properties file I will update XTSPropertyManager so that it reuses the code employed by the JBossTS PropertyManager. So,the lookup algorithm will be as follows:

• The property manager will use the value of System property org.jboss.jbossts.xts.propertiesFile as the name of the property file to look up. If that is not set it will use name xts-properties.xml.
• The property manager will try to load it as an absolute file if it resolves as an absolute path
• Othewise the property manager will try to load it as an absolute file if the name is prefixed with abs://
• Otherwise the property manager will try to load the file from user.dir, user.home or java.home
• Otherwise the property manager will try to locate the file as a resource relative to the XTS deployment's classloader by appending "/" to the name and calling loader.getResource on the result.
• System properties are merged into the loaded properties set overwrtiing values derived from the proeprties file.

ENDPOINT CONFIGURATION

There's one thing not yet clear to me. How XTS knows the current paths (besides the host names and ports) to the different WS-T/WS-C/WS-AT endpoints?

In one of your previous messages, you said that I may have had to tweak the code a bit if I arbitrarily chose the deploy path to my service endpoints (through CXF). Is it possible to configure this aspect with the new configuration architecture without touching the XTS code?

The URL paths are pretty much hard-wired at the moment based on the rules JBossWS employs to map <url-pattern/> entries as declared in web.xml to the full URL paths. You are right that this ought to be configurable in some way. I am happy to provide a way to make this possible but am somewhat undersupplied by requirements. Can you explain how CXF performs this mapping in your deployment and what control you have over how it operates?

[adinn]

Mauro Molinari wrote:

2) a servlet which uses the client and that I invoke using my browser to test the whole thing. This servlet simply does the following:

// client is the webservice client from the Spring beans container
com.arjuna.mw.wst11.UserTransaction ut = com.arjuna.mw.wst11.UserTransactionFactory.userTransaction();
try
{
  ut.begin();
  client.doOperation("hello world");
  ut.commit();
}
catch(Exception e}
{
  e.printStackTrace();
}

The situation is the following: all the webapps start correctly, without any errors. However, when I execute the client servlet code, I get a NullPointerException because ut is null. I'm going to debug the code, however, if you have suggestions you are welcome.

The version of the client code you are using relies upon the WSTXIntiialisation code being run to initialise UserTransaction and TransactionManager. If you call this it will load the UserTransactionImple and TransactionManagerImple classe, create a singleton instance of each and then call UserTransaction.setUserTransaction() and TransactionManager.setTransactionManager() to initialise the API classes.

[mauromol]

Andrew Dinn ha scritto:

No,don't bother with a JIRA. If you want to use dependency injection then you can forget about deploying the property file altogether. Insetad just use the same approach as we do in JBoss AS where we inject configuration as specified in file jboss-beans.xml. You need to get your injection framework to invoke the setters on the various configuration beans, WSCEnvrionmentBean, WSTEnvironmentBean etc.

You're right, I didn't thought of this possibility. I could do that for JBossTS JTA, too. However, I don't remember how these injected properties merge with a property file: isn't a property file still required? Or is there a way to force JBossTS (and XTS) to ignore it and use only properties injected in this way?

Anyway, my suggested approach to inject a Properties instance has the benefit that you have to write few lines of XML configuration to inject a single Properties object (with properties stored in a plain .properties file, for instance), while by using your suggested approach I have to write a lot of wiring XML code to inject all the properties one by one. This can have more maintenance costs when upgrading the library.

Andrew Dinn ha scritto:

The URL paths are pretty much hard-wired at the moment based on the rules JBossWS employs to map <url-pattern/> entries as declared in web.xml to the full URL paths. You are right that this ought to be configurable in some way. I am happy to provide a way to make this possible but am somewhat undersupplied by requirements. Can you explain how CXF performs this mapping in your deployment and what control you have over how it operates?

I have full control on the paths used by CXF to expose my services. I mean, once I have mapped the CXF servlet in web.xml, every endpoint definition has to specify the path to its service.

For instance, if I map the CXF servlet to path /services/* and I want to publish a webservice called MyTestService at /myservicepath/MyTestService, I have to declare the corresponding endpoint (either programmatically or through Spring configuration) specifying the /myservicepath/MyTestService path. After that, my service will be reachable at http://<hostname>:<port>/services/myservicepath/MyTestService.

Therefore, I need to tell XTS this information in order to make it find its needed services. I don't know if there's a simple way for XTS to get this information directly from CXF by itself. However, I think it would be more flexible to let the user do the wiring.

HTH.

Mauro.

[mauromol]

Andrew Dinn ha scritto:

The version of the client code you are using relies upon the WSTXIntiialisation code being run to initialise UserTransaction and TransactionManager. If you call this it will load the UserTransactionImple and TransactionManagerImple classe, create a singleton instance of each and then call UserTransaction.setUserTransaction() and TransactionManager.setTransactionManager() to initialise the API classes.

You're right, I realized that by debugging and inspecting the XTS code. It seems like the callback defined in com.arjuna.mw.wst11.deploy.WSTXInitialisation is never executed, althuogh it is correctly registered and the corresponding sequence is closed by the WSTXInitialisation listener itself. I will check the XTSService.start() code.

Mauro.

[mauromol]

The problem is that runCallbacks() is never executed since I'm not registering the expected number of callbacks (com.arjuna.services.framework.startup.Sequencer.WEBAPP_MAX11). Tomorrow I'll tweak the code so that in each webapp the exact number of needed callbacks overrides this constant. I think I'll discover a lot of new problems to fix then! :-D

Mauro.

[adinn]

Mauro Molinari wrote:

You're right, I didn't thought of this possibility. I could do that for JBossTS JTA, too. However, I don't remember how these injected properties merge with a property file: isn't a property file still required? Or is there a way to force JBossTS (and XTS) to ignore it and use only properties injected in this way?

If you don't provide a properties file then XTS and JBossTS do not complain.The config bean fields are just left with whatever values the defining class supplies them with.

Mauro Molinari wrote:

Anyway, my suggested approach to inject a Properties instance has the benefit that you have to write few lines of XML configuration to inject a single Properties object (with properties stored in a plain .properties file, for instance), while by using your suggested approach I have to write a lot of wiring XML code to inject all the properties one by one. This can have more maintenance costs when upgrading the library.

Well, if you look at the latest XTS code you can see that XTSPropertyManager uses a class call XTSPropertyFactory to obtain the default properties. It uses the JBossTS code to implement the algorithm I mentioned before which loads the proeprties file. However, it only does htis if static field defaultProperties is unset. This field has a public setter. So, you shoudl be abel to use your injection framework to install a Properties object into this field before calling XTSService.start. When the XTS code tries to read the config beans they will be pre-populated wiht config values derived from this Properties set.

I have full control on the paths used by CXF to expose my services. I mean, once I have mapped the CXF servlet in web.xml, every endpoint definition has to specify the path to its service.

For instance, if I map the CXF servlet to path /services/* and I want to publish a webservice called MyTestService at /myservicepath/MyTestService, I have to declare the corresponding endpoint (either programmatically or through Spring configuration) specifying the /myservicepath/MyTestService path. After that, my service will be reachable at http://<hostname>:<port>/services/myservicepath/MyTestService.

Therefore, I need to tell XTS this information in order to make it find its needed services. I don't know if there's a simple way for XTS to get this information directly from CXF by itself. However, I think it would be more flexible to let the user do the wiring.

Ok, that's a little different to how JBossWS works. It builds up the context path for the URL from two components. The first is defined by the war file name and the second by the <urlpattern> in the web.xml. For example, ws-c11.war contains a service named ActvationService whose urlpattern is declared as ActivationService. So, the URL ends up being http://localhost:8080/ws-c11/ActivationService.

What we probably ought to do is define String properties in the WSC and WST environment beans for each of the WSC and WST services. This can be used to define the complete context path for the service. If the property is not defined then the path will default to the ones currently in use.

So, for example in class WSCEnvironmentBean I will add the following field and provdie a setter and getter for it:

    @FullPropertyName(name="org.jboss.jbossts.xts.contextPath.ActivationCoordinator")
    private volatile String activationCoordinatorContextPath = "ws-c11/ActivationService"

You can inject whatever path you like to override this component of the URL. I'll do the same for the other paths.

[adinn]

Mauro Molinari wrote:

The problem is that runCallbacks() is never executed since I'm not registering the expected number of callbacks (com.arjuna.services.framework.startup.Sequencer.WEBAPP_MAX11). Tomorrow I'll tweak the code so that in each webapp the exact number of needed callbacks overrides this constant. I think I'll discover a lot of new problems to fix then! :-D

Yes, if you drop any of the listeners which calls close (because it is doing something else you don't want) then you will need to add an alternative listener which just calls close.

[mauromol]

Andrew Dinn ha scritto:

Well, if you look at the latest XTS code you can see that XTSPropertyManager uses a class call XTSPropertyFactory to obtain the default properties. It uses the JBossTS code to implement the algorithm I mentioned before which loads the proeprties file. However, it only does htis if static field defaultProperties is unset. This field has a public setter. So, you shoudl be abel to use your injection framework to install a Properties object into this field before calling XTSService.start. When the XTS code tries to read the config beans they will be pre-populated wiht config values derived from this Properties set.

Exactly what I needed, thank you! Do you know there is something equivalent for JBossTS core/JTA? I searched some weeks ago to see if there was, but I couldn't find any way to inject a Properties instance (or a custom location to jbossts-properties.xml).

Andrew Dinn ha scritto:

Ok, that's a little different to how JBossWS works. It builds up the context path for the URL from two components. The first is defined by the war file name and the second by the <urlpattern> in the web.xml. For example, ws-c11.war contains a service named ActvationService whose urlpattern is declared as ActivationService. So, the URL ends up being http://localhost:8080/ws-c11/ActivationService.

I realized that in my example I forgot to mention the webapp context path. The full picture is the following: if I have a web application with CXF, I map the CXF servlet to path /services/* and I publish a webservice called MyTestService at /myservicepath/MyTestService, I have to declare the corresponding endpoint (either programmatically or through Spring configuration) specifying the /myservicepath/MyTestService path. After that, my service will be reachable at http://<hostname>:<port>/<webapp context path>/services/myservicepath/MyTestService.

The webapp context path is tipically the directory in which the web application was deployed (and it is derived from the WAR file name when deploying using a WAR).

Anyway, this does not change the validity of your proposed solution. In general I can't know where (i.e. full path) my services are deployed, so I must have a way to supply this information. In JBossAS it's more simple because you deploy YOUR webapps containing the services using YOUR WAR files (with a fixed name). If I understood it well, at the moment the whole thing wouldn't work anymore if you change the name of a WAR file without changing the XTS code.

Mauro.

[mauromol]

Hi Andrew!

I think I'm at the core of the problem. I solved the Sequencer issues and now I'm at this point. When invoking begin() on the UserTransaction on the client side I get the following exception:

java.lang.NullPointerException
     at com.arjuna.webservices11.wsaddr.AddressingHelper.createRequestContext(AddressingHelper.java:132)
     at com.arjuna.wsc11.ActivationCoordinator.createCoordinationContext(ActivationCoordinator.java:62)
     at com.arjuna.mwlabs.wst11.at.remote.UserTransactionImple.startTransaction(UserTransactionImple.java:270)
     at com.arjuna.mwlabs.wst11.at.remote.UserTransactionImple.begin(UserTransactionImple.java:85)
     at com.arjuna.mwlabs.wst11.at.remote.UserTransactionImple.begin(UserTransactionImple.java:75)
     at test.TestServiceClient.doGet(TestServiceClient.java:37)
     at javax.servlet.http.HttpServlet.service(HttpServlet.java:617)
     at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
     at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
     at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
     at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233)
     at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
     at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
     at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
     at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
     at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:298)
     at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:857)
     at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:588)
     at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:489)

Please note that in my webapp I had to put jbossws-common.jar (because the endpoint implementations use org.jboss.wsf.common.addressing.MAP from it) and jbossws-spi.jar (because org.jboss.wsf.spi.util.ServiceLoader is needed at runtime when trying to begin a transaction). I don't think I can make XTS live without JBossWS at all, however it would be acceptable if it used only some data structures and/or utility methods to manage the addressing issues.

The affected line of AddressingHelper reads:

        MAPBuilder builder = MAPBuilderFactory.getInstance().getBuilderInstance();

So there's no MAPBuilderFactory instance available. This makes me think that some initialisation, usually done by the JBossWS engine, is missing in my environment. Is this something I can easily manage by myself? Or is it too complex?

Any suggestion is welcome.

Mauro

[adinn]

Mauro Molinari wrote:

Exactly what I needed, thank you! Do you know there is something equivalent for JBossTS core/JTA? I searched some weeks ago to see if there was, but I couldn't find any way to inject a Properties instance (or a custom location to jbossts-properties.xml).

There is a comparable static which holds the Properties instance in class com.arjuna.common.util.propertyservice.PropertiesFactory. However,  it does not provide a setter method. You could raise a JIRA asking for this to be provided. It's not jsut a question of adding the method though -- Jonathan may not feel obliged to continue to support this way of configuring your app. I suspect he will suggest you use one of the two xisting methods.

I believe you can specify an alternative location for the properties file but only by setting a system property.

I realized that in my example I forgot to mention the webapp context path. The full picture is the following: if I have a web application with CXF, I map the CXF servlet to path /services/* and I publish a webservice called MyTestService at /myservicepath/MyTestService, I have to declare the corresponding endpoint (either programmatically or through Spring configuration) specifying the /myservicepath/MyTestService path. After that, my service will be reachable at http://<hostname>:<port>/<webapp context path>/services/myservicepath/MyTestService.

The webapp context path is tipically the directory in which the web application was deployed (and it is derived from the WAR file name when deploying using a WAR).

Anyway, this does not change the validity of your proposed solution. In general I can't know where (i.e. full path) my services are deployed, so I must have a way to supply this information. In JBossAS it's more simple because you deploy YOUR webapps containing the services using YOUR WAR files (with a fixed name). If I understood it well, at the moment the whole thing wouldn't work anymore if you change the name of a WAR file without changing the XTS code.

Ok, so we will stick with what I suggested. I'll raise another JIRA for it.

[adinn]

Mauro Molinari wrote:

When invoking begin() on the UserTransaction on the client side I get the following exception:

java.lang.NullPointerException
     at com.arjuna.webservices11.wsaddr.AddressingHelper.createRequestContext(AddressingHelper.java:132)
     at com.arjuna.wsc11.ActivationCoordinator.createCoordinationContext(ActivationCoordinator.java:62)
     at com.arjuna.mwlabs.wst11.at.remote.UserTransactionImple.startTransaction(UserTransactionImple.java:270)
     at com.arjuna.mwlabs.wst11.at.remote.UserTransactionImple.begin(UserTransactionImple.java:85)
     at com.arjuna.mwlabs.wst11.at.remote.UserTransactionImple.begin(UserTransactionImple.java:75)
     at test.TestServiceClient.doGet(TestServiceClient.java:37)
     at javax.servlet.http.HttpServlet.service(HttpServlet.java:617)
     at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
     at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
     at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
     at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233)
     at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
     at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
     at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
     at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
     at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:298)
     at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:857)
     at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:588)
     at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:489)

Please note that in my webapp I had to put jbossws-common.jar (because the endpoint implementations use org.jboss.wsf.common.addressing.MAP from it) and jbossws-spi.jar (because org.jboss.wsf.spi.util.ServiceLoader is needed at runtime when trying to begin a transaction). I don't think I can make XTS live without JBossWS at all, however it would be acceptable if it used only some data structures and/or utility methods to manage the addressing issues.

The affected line of AddressingHelper reads:

        MAPBuilder builder = MAPBuilderFactory.getInstance().getBuilderInstance();

So there's no MAPBuilderFactory instance available. This makes me think that some initialisation, usually done by the JBossWS engine, is missing in my environment. Is this something I can easily manage by myself? Or is it too complex?

Hmm, that's good progress anyway even if it has stopped here. The map builder factory class MapBuilderFactory must be configured to load either a CXF or a JBossWS Native implementation of the MAP interface classes which hide the details of how WSAddressing is implemented. The code you need is in jbossws-cxf-client.jar. It contains a resourec in META-INF/services which guides the generci factory class to  load the relevant implementtatuion. This jar also contains the implementation classes for  the MAP abstraction layer.

[mauromol]

Andrew Dinn ha scritto:

Hmm, that's good progress anyway even if it has stopped here. The map builder factory class MapBuilderFactory must be configured to load either a CXF or a JBossWS Native implementation of the MAP interface classes which hide the details of how WSAddressing is implemented. The code you need is in jbossws-cxf-client.jar. It contains a resourec in META-INF/services which guides the generci factory class to  load the relevant implementtatuion. This jar also contains the implementation classes for  the MAP abstraction layer.

The ghost of org.jboss.logging.Logger is back!! Thanks to your suggestion, now I'm stuck at:

java.lang.ClassNotFoundException: org.jboss.logging.Logger
     org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1645)
     org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1491)
     org.jboss.wsf.stack.cxf.extensions.addressing.map.CXFMAP.<clinit>(CXFMAP.java:54)
     org.jboss.wsf.stack.cxf.extensions.addressing.map.CXFMAPBuilder.newMap(CXFMAPBuilder.java:68)
     com.arjuna.webservices11.wsaddr.AddressingHelper.createRequestContext(AddressingHelper.java:133)
     com.arjuna.wsc11.ActivationCoordinator.createCoordinationContext(ActivationCoordinator.java:62)
     com.arjuna.mwlabs.wst11.at.remote.UserTransactionImple.startTransaction(UserTransactionImple.java:270)
     com.arjuna.mwlabs.wst11.at.remote.UserTransactionImple.begin(UserTransactionImple.java:85)
     com.arjuna.mwlabs.wst11.at.remote.UserTransactionImple.begin(UserTransactionImple.java:75)
     test.TestServiceClient.doGet(TestServiceClient.java:37)
     javax.servlet.http.HttpServlet.service(HttpServlet.java:617)
     javax.servlet.http.HttpServlet.service(HttpServlet.java:717)

Now, where do I get jboss-logging.jar? I can't find it in the JBossWS sources, nor in JBossTS 4.11 sources. I can't find the download for JBossTS 4.12 in the JBossTS website (although it's marked as released in JIRA), so I can't see if it is in there. Browsing the source code of JBoss Common project I see that jboss-logging component should be part of JBoss Common. But there are no Download links in JBoss Common web page.

Is there a way to download jboss-logging.jar without using Maven?

Thanks in advance,

Mauro.

[adinn]

Mauro Molinari wrote:

Is there a way to download jboss-logging.jar without using Maven?

Yes. Use the nexus repo  manager at

http://repository.jboss.org/nexus/index.html#welcome

Click on repositories in the left bar and then select "JBoss public repo group" in the right hand pane. You should see a tree view of the repo open up below. Browse the tree to org.jboss.logging.jboss-logging and you will see all the different release versions. The jars in the release version you need can be viewed by clicking the left button on the jar itself. The right button popup menu allows you to download.

n.b. if you want to identify which version is approrpiate then check a compatible AS tree for the pom.xml in the top level directory called component-matrix. It defines the version for all the dependencies. I think 4.11 was used in AS 6.0.0.M4 so you should be able to use this file to resolve versions:

http://anonsvn.jboss.org/repos/jbossas/tags/6.0.0.20100721-M4/component-matrix/pom.xml