Re: [jbossws-dev] WS-RM, depends on WS-Policy, WS-PolicyAttachment
by Thomas Diesler
I am wondering whether to integrate WS-Policy, WS-PolicyAttachments
first before we move on to WS-RM. From an implemenation perspective
WS-RM depends on WS-PO, WS-POA
On Tue, 2007-02-27 at 13:27 +0000, Mark Little wrote:
> Are you asking whether WS-Policy is a better starting point than WS-RM?
>
> Mark.
>
>
> On 27 Feb 2007, at 13:17, Thomas Diesler wrote:
>
> > Hi Folks,
> >
> > you've probably already noticed that WS-RM has dependency on WS-
> > Policy,
> > WS-PolicyAttachment for configuration purposes. Not sure if it makes
> > sense to start with those pieces. OTOH it may make sence to provide
> > configuration aspects in an alternative manner to get started.
> >
> > cheers
> > -thomas
> >
> > --
> > xxxxxxxxxxxxxxxxxxxxxxxxxxxx
> > Thomas Diesler
> > Web Service Lead
> > JBoss, a division of Red Hat
> > xxxxxxxxxxxxxxxxxxxxxxxxxxxx
> >
> >
> > _______________________________________________
> > jbossws-dev mailing list
> > jbossws-dev(a)lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/jbossws-dev
>
--
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
Thomas Diesler
Web Service Lead
JBoss, a division of Red Hat
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
19 years, 1 month
WS-RM, depends on WS-Policy, WS-PolicyAttachment
by Thomas Diesler
Hi Folks,
you've probably already noticed that WS-RM has dependency on WS-Policy,
WS-PolicyAttachment for configuration purposes. Not sure if it makes
sense to start with those pieces. OTOH it may make sence to provide
configuration aspects in an alternative manner to get started.
cheers
-thomas
--
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
Thomas Diesler
Web Service Lead
JBoss, a division of Red Hat
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
19 years, 1 month
Re: WS-RM relevant spec
by Thomas Diesler
Hi Stefano,
The objective of this excercise is to bring the functionality that is
offered by Tango to JBossWS. So, the question should really be asked
differently, i.e. what spec is currently implemented by tango?
The answer to that is https://wsit.dev.java.net/specification-links.html
So, even WS-RX is the most advanced spec we need to look at the spec
that is the basis of the current tango implementation.
cheers
-thomas
On Mon, 2007-02-26 at 17:01 +0100, Stefano Maestri wrote:
> Hi all,
> the link ask me a user and password. Might we have one?
>
> bye
>
> Stefano
>
> Mark Little wrote on 26/02/07 16:17:
> > OASIS WS-RX is the one you want
> > (http://www.oasis-open.org/apps/org/workgroup/ws-rx/)
> >
> > Mark.
> >
> >
> >
> > On 26 Feb 2007, at 14:31, Thomas Diesler wrote:
> >
> >> Hi Mark,
> >>
> >> do you know whats the most relevant WS-RM spec out there?
> >>
> >> http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=wsrm'
> >>
> >> http://www-128.ibm.com/developerworks/library/specification/ws-rm/
> >>
> >> cheers
> >> -thomas
> >>
> >>
> >> --xxxxxxxxxxxxxxxxxxxxxxxxxxxx
> >> Thomas Diesler
> >> Web Service Lead
> >> JBoss, a division of Red Hat
> >> xxxxxxxxxxxxxxxxxxxxxxxxxxxx
> >>
> >>
> >
>
>
--
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
Thomas Diesler
Web Service Lead
JBoss, a division of Red Hat
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
19 years, 1 month
[Design of JBoss Web Services] - Re: Using jbossws/trunk for jboss-5.0, jboss-4.2, jboss-4.0.
by gduan2000
I had the same ERROR, and it cost me 1 day to figure out that it's something to do with the JDK version - JDK1.6.0. switched back to JDK1.5.0_11, and this ERROR was gone.
All other portions of the application were working fine with JDK1.6.0, but just JBossWS piece.
Hope this help.
-g
"dwin" wrote : hey guys
|
| thanks for the help, adding junit.jar to the ant/lib fixed it (although ant already has an ant-junir.jar in its classpath already) and upgrading to ant 1.7 fixed the xerces bug. Perhaps, you guys could put ant 1.7 as a requirement for building JBossWS on the Wiki to avoid future confusion with other developers.
|
| However, the tests are failing for me.
|
| On the server side, I am regularly getting these exceptions which all basically relate to the "setProperty must be overridden by all subclasses of SOAPMessage" message. Every test seems to fail because of these exceptions.
|
|
| | 14:10:57,445 ERROR [SOAPFaultHelperJAXRPC] SOAP request exception
| | java.lang.UnsupportedOperationException: setProperty must be overridden by all subclasses of SOAPMessage
| | at javax.xml.soap.SOAPMessage.setProperty(SOAPMessage.java:424)
| | at org.jboss.ws.core.soap.SOAPMessageImpl.<init>(Unknown Source)
| | at org.jboss.ws.core.soap.MessageFactoryImpl.createMessageInternal(Unknown Source)
| | at org.jboss.ws.core.soap.MessageFactoryImpl.createMessage(Unknown Source)
| | at org.jboss.ws.core.server.ServiceEndpoint.handleRequest(Unknown Source)
| | at org.jboss.ws.core.server.ServiceEndpointManager.processSOAPRequest(Unknown Source)
| | at org.jboss.ws.core.server.AbstractServiceEndpointServlet.doPost(Unknown Source)
| | at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
| | at org.jboss.ws.core.server.AbstractServiceEndpointServlet.service(Unknown Source)
| | at javax.servlet.http.HttpServlet.service(HttpServlet.java:810)
| | at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252)
| | at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
| | at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96)
| | at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202)
| | at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
| | at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213)
| | at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:178)
| | at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:175)
| | at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:74)
| | at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126)
| | at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105)
| | at org.jboss.web.tomcat.tc5.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:156)
| | at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107)
| | at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148)
| | at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:869)
| | at org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection(Http11BaseProtocol.java:664)
| | at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:527)
| | at org.apache.tomcat.util.net.MasterSlaveWorkerThread.run(MasterSlaveWorkerThread.java:112)
| | at java.lang.Thread.run(Thread.java:619)
| | 14:10:57,477 ERROR [AbstractServiceEndpointServlet] Error processing web service request
| | java.lang.UnsupportedOperationException: setProperty must be overridden by all subclasses of SOAPMessage
| | at javax.xml.soap.SOAPMessage.setProperty(SOAPMessage.java:424)
| | at org.jboss.ws.core.soap.SOAPMessageImpl.<init>(Unknown Source)
| | at org.jboss.ws.core.soap.MessageFactoryImpl.createMessage(Unknown Source)
| | at org.jboss.ws.core.jaxrpc.SOAPFaultHelperJAXRPC.toSOAPMessage(Unknown Source)
| | at org.jboss.ws.core.jaxrpc.SOAPFaultHelperJAXRPC.exceptionToFaultMessage(Unknown Source)
| | at org.jboss.ws.core.jaxrpc.SOAP11BindingJAXRPC.createFaultMessageFromException(Unknown Source)
| | at org.jboss.ws.core.CommonSOAPBinding.bindFaultMessage(Unknown Source)
| | at org.jboss.ws.core.server.ServiceEndpoint.handleRequest(Unknown Source)
| | at org.jboss.ws.core.server.ServiceEndpointManager.processSOAPRequest(Unknown Source)
| | at org.jboss.ws.core.server.AbstractServiceEndpointServlet.doPost(Unknown Source)
| | at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
| | at org.jboss.ws.core.server.AbstractServiceEndpointServlet.service(Unknown Source)
| | at javax.servlet.http.HttpServlet.service(HttpServlet.java:810)
| | at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252)
| | at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
| | at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96)
| | at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202)
| | at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
| | at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213)
| | at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:178)
| | at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:175)
| | at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:74)
| | at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126)
| | at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105)
| | at org.jboss.web.tomcat.tc5.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:156)
| | at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107)
| | at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148)
| | at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:869)
| | at org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection(Http11BaseProtocol.java:664)
| | at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:527)
| | at org.apache.tomcat.util.net.MasterSlaveWorkerThread.run(MasterSlaveWorkerThread.java:112)
| |
|
| The vast majority of my unit tests fail (but not all fail, a minute portion of them do pass).
|
| I am guessing that my environment is not setup as the rest of the JBoss team.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4022753#4022753
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4022753
19 years, 1 month
[Design of JBoss Web Services] - Re: WSContractConsumer API in a seam app
by jason.greene＠jboss.com
"maeste" wrote : Ops, something went wrong in my last post and the final part of my message doesn't be visible:
| "jason.greene(a)jboss.com" wrote :
| |
| | Be careful when replacing the context loader when running in a container. If you do this you should restore the original thread context loader.
| |
| | -Jason
| I suspected it is too aggressive. What is the best way to tell the current class loader to include also my generated client class?
|
| Many many tanks for your time
You don't actually need to mess with the context classloader. Once a class is loaded you can freely pass the class reference around. The JVM associates the class reference to the loader that loaded it, and that loader is preserved until all class references are garbage collected. The only scenario to replace a context loader is if you are using an API that uses it, and doesnt offer a mechanism to pass the loader directly. However, when you do this you must use a try finally block that restores the context loader to the original version.
So, your problems might go away if remove the context loader assignment, and the RMIAdaptor hack.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4022553#4022553
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4022553
19 years, 1 month
