[Design of JBoss Transaction Services] - A Question about Baframework
by andy_bu
Hi.
I try to start your programm BAFRAMEWORK.
I clicked Initialise data (they were initialised), but then i try
to start Business Activity and i recieve a mistake:
Exception thrown:
VersionMismatch[html] and so on
23:52:54,921 INFO [HotelService] processRequest()
23:52:54,937 INFO [HotelService] Current state: 1
23:52:54,937 INFO [HotelService] Business Activity request: true
23:52:54,937 INFO [HotelService] Method name: startBA
23:52:54,937 INFO [HotelService] Parameters: null
23:52:54,937 INFO [HotelService] Starting Business Activity
23:52:55,906 INFO [JaxWSClientHeaderContextProcessor] handleOutbound
23:53:05,265 INFO [JaxWSServerHeaderContextProcessor] handleInbound
23:53:06,765 INFO [HotelImpl] resetView()
23:53:06,781 INFO [JaxWSServerHeaderContextProcessor] handleOutbound
23:53:07,093 INFO [JaxWSClientHeaderContextProcessor] handleInbound
23:53:07,093 INFO [JaxWSClientHeaderContextProcessor] handleOutbound
23:53:08,296 INFO [JaxWSServerHeaderContextProcessor] handleInbound
23:53:08,343 INFO [JaxWSServerHeaderContextProcessor] handleOutbound
23:53:08,343 INFO [JaxWSClientHeaderContextProcessor] handleInbound
23:53:09,078 ERROR [[HTTP SOAP Service Multiplexor Servlet]] Servlet.service() for servlet HTTP SOAP Service Multiplexor Servlet threw exception
java.io.IOException: javax.xml.stream.XMLStreamException: [com.arjuna.webservices.wsaddr.AddressingContext_1] - Addressing context is not valid
at com.arjuna.webservices.soap.SoapMessageBase.output(SoapMessageBase.java:87)
at com.arjuna.webservices.transport.http.HttpServiceMultiplexorServlet.doPost(HttpServiceMultiplexorServlet.java:177)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:710)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:803)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:230)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175)
at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:182)
at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:84)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
at org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:157)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:262)
at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:844)
at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:583)
at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:446)
at java.lang.Thread.run(Thread.java:619)
23:53:09,359 ERROR [STDERR] com.arjuna.wst.SystemException: VersionMismatch[html]
23:53:09,437 ERROR [STDERR] at com.arjuna.mwlabs.wst.ba.remote.UserBusinessActivityImple.startTransaction(UserBusinessActivityImple.java:274)
23:53:09,437 ERROR [STDERR] at com.arjuna.mwlabs.wst.ba.remote.UserBusinessActivityImple.begin(UserBusinessActivityImple.java:108)
23:53:09,437 ERROR [STDERR] at com.arjuna.mwlabs.wst.ba.remote.UserBusinessActivityImple.begin(UserBusinessActivityImple.java:98)
23:53:09,437 ERROR [STDERR] at com.jboss.ba.demo.client.HotelService.startBusinessActivity(Unknown Source)
23:53:11,562 ERROR [STDERR] at com.jboss.ba.demo.client.HotelService.processRequest(Unknown Source)
23:53:11,562 ERROR [STDERR] at com.jboss.ba.demo.client.HotelService.doGet(Unknown Source)
23:53:11,562 ERROR [STDERR] at javax.servlet.http.HttpServlet.service(HttpServlet.java:690)
23:53:11,562 ERROR [STDERR] at javax.servlet.http.HttpServlet.service(HttpServlet.java:803)
23:53:11,562 ERROR [STDERR] at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
23:53:11,562 ERROR [STDERR] at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
23:53:11,562 ERROR [STDERR] at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96)
23:53:11,562 ERROR [STDERR] at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
23:53:11,562 ERROR [STDERR] at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
23:53:11,562 ERROR [STDERR] at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:230)
23:53:11,562 ERROR [STDERR] at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175)
23:53:11,562 ERROR [STDERR] at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:182)
23:53:11,562 ERROR [STDERR] at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:84)
23:53:11,562 ERROR [STDERR] at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
23:53:11,562 ERROR [STDERR] at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
23:53:11,562 ERROR [STDERR] at org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:157)
23:53:11,562 ERROR [STDERR] at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
23:53:11,562 ERROR [STDERR] at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:262)
23:53:11,562 ERROR [STDERR] at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:844)
23:53:11,562 ERROR [STDERR] at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:583)
23:53:11,562 ERROR [STDERR] at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:446)
23:53:11,562 ERROR [STDERR] at java.lang.Thread.run(Thread.java:619)
May be someone had such a mistake?
Thanks
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4205921#4205921
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4205921
16 years, 1 month
[Design of POJO Server] - Re: The DeploymentManager and ProfileService
by emuckenhuber
Last but not least - the deploymentManager is one of the remaining parts which are making the cleanup of the profileservice-spi a bit harder.
Especially the basic locking which is done when copying a file into a hot-deployment folder.
So maybe we want to remove the enableModifiedDeploymentChecks from the Profile spi:
| public interface Profile
| {
| /**
| * Enable/disable the getModifiedDeployments results. This can be
| * used to disable the getModifiedDeployments results during
| * periods such as bootstrap where changes should be delayed.
| * @see #getModifiedDeployments
| * @param flag - the enable/disable flag
| */
| void enableModifiedDeploymentChecks(boolean flag);
| }
|
And just have a HDScanner.suspendProfile(ProfileKey key) and HDScanner.resumeProfile(ProfileKey key)
to avoid that the folder is hot-deployment checked when the DeploymentManager is copying a file.
Not sure if that makes more sense, but i think the enableModifiedDeploymentChecks in the Profile spi maybe should not be there.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4205886#4205886
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4205886
16 years, 1 month
[Design of POJO Server] - The DeploymentManager and ProfileService
by emuckenhuber
It seems there were some more people struggling with the DeploymentManger interface,
i'll would like to suggest some changes i was planning to do to make it a bit easier to use:
The current way to use DeploymentManager is (pseudo code):
| DeploymentProgress distribute = getDeploymentManager().distribute(name, getManagedURL(name), copyContent);
| distribute.run();
|
| if (copyContent)
| {
| DeploymentProgress start = getDeploymentManager().start(name);
| start.run();
| }
|
| DeploymentProgress stop = getDeploymentManager().stop(names);
| stop.run();
|
| if (copyContent)
| {
| DeploymentProgress undeploy = getDeploymentManager().undeploy(names);
| undeploy.run();
| }
|
Well atm there is still the DeploymentPhase which should also go away.
But this looks a bit confusing.
I think it should have be symmetric whether you do copyContent or not and always have:
| deploymentManager.distribute(name, isCopyContent);
| deploymentManager.start(name);
| deploymentManager.stop(name);
| deploymentManager.remove(name);
|
So for isCopyContent == false - we should have a own transient deployment profile - which gets activated / deactivated by the DeploymentManager.
So a isCopyContent == false app will only get removed from the repository, and not deleted (different for isCopyContent == true).
Especially if you look at the profileService tests in the testsuite, there are a lot of warnings from ManagementView
that the application (which are deployed with isCopyContent == false) don't exist anymore (because there were undeployed in the testcase before)
That's because they just can get stopped, but not be removed from the repository.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4205882#4205882
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4205882
16 years, 1 month
[Design of JBossCache] - Re: [JBCACHE-1470] Option to disable cache event generation
by galder.zamarreno＠jboss.com
Yesterday while testing this, I realised that Transaction Completed notifications will always happen regardless of whether I set the correct option override before the tx commit and with NotifierImpl.notifyTransactionCompleted() modified accordingly.
The root cause here is that in LocalSynchronizationHandler.beforeCompletioninvocation() invocation context options are subsitiuted with the ones from the transaction context:
// set any transaction wide options as current for this thread, caching original options that would then be reset
| originalOptions = ctx.getOptionOverrides();
| transactionalOptions = transactionContext.getOption();
| ctx.setOptionOverrides(transactionalOptions);
So, when NotifierImpl.notifyTransactionCompleted() is called, no matter what overrides I set before the tx.commit() call, they won't be used.
The quick'n'easy fix here would be doing something like this:
// set any transaction wide options as current for this thread, caching original options that would then be reset
| originalOptions = ctx.getOptionOverrides();
| transactionalOptions = transactionContext.getOption();
| transactionalOptions.setSuppressEventNotification(originalOptions.isSuppressEventNotification());
| ctx.setOptionOverrides(transactionalOptions);
But I'm not 100% sure about this.
Another interesting point here related to the following parallel thread going on about Options API (http://www.jboss.com/index.html?module=bb&op=viewtopic&t=149495) is that if we allow supression of transaction related notifications, then we'd need to keep to thread local use for this particular Option as we can't change the TM API.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4205874#4205874
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4205874
16 years, 1 month