JBossWS SOAP Attachment sample invoke
by Sreedhar S
Hi,
I've a requirement to attach documents(txt,image,xml) through soap on
Jboss. I'm working on samples provided by Jbossws.
The deatils are below.
Jboss App server : jboss-4.0.4.GA
JDK : Jdk1.5
Samples provided by Jbossws1.2.0 : jbossws-samples-1.2.0.GA
I build the samples and was able to successfully deploy on
jboss-4.0.4.GA server.
When I run, http://localhost:8080/jbossws/services I can find all
Registered Service Endpoints. Among the registered service endpoints,
I'm interested in invoking the following sample.
ServiceEndpointID jboss.ws:context=jaxrpc-samples-swa,endpoint=AttachmentJSE
ServiceEndpointAddress http://SREEDHAR-S:8080/jaxrpc-samples-swa?wsdl
Now the problem is, how to invoke the Attachment sample? When I build
the war, jaxrpc-samples-swa-client.jar is created and I placed it in
\jboss-4.0.4.GA\client and set the classpath.
HOW SHOULD I ACCESS THE ABOVE EXAMPLE? Please provide the exact steps from here.
Help is greatly appreciated.
Regards,
Sreedhar
17 years
JBWS801TestCase
by Magesh Kumar Bojan
Hi,
I see in this testcase there is a line which says:
long size = 6L * 1024L * 1024L * 1024L // approx 600mb
Isn't this size 6442450944 = 6144 MB = 6 GB?
Was this size intended? Because in windows it hangs the system with 1 GB
memory after finally saying no disk space!
--
-Magesh
skype: mageshbk
msn: mageshbk
irc: mbojan
yahoo: mageshbk
phone: +919945699931
17 years
Fw: [ws-rx] WS-ReliableMessaging 1.1 Submitted for OASIS Standard
by Heiko Braun
Begin forwarded message:
Date: Tue, 1 May 2007 09:33:55 -0400
From: "Mary McRae" <mary.mcrae(a)oasis-open.org>
To: <members(a)lists.oasis-open.org>, <tc-announce(a)lists.oasis-open.org>
Cc: <ws-rx(a)lists.oasis-open.org>
Subject: [ws-rx] WS-ReliableMessaging 1.1 Submitted for OASIS Standard
OASIS Members:
The OASIS Web Services Reliable Exchange (WS-RX) Technical Committee
has submitted the following specification, which is an approved
Committee Specification, to be considered as an OASIS Standard:
WS-ReliableMessaging 1.1:
- Web Services ReliableMessaging 1.1
- Web Services ReliableMessaging Policy 1.1
- Web Services MakeConnection 1.0
The text of the TC submission is appended.
You now have until 15 May to familiarize yourself with the submission
and provide input to your organization's voting representative.
On 16 May, a Call For Vote will be issued to all Voting Representatives
of OASIS member organizations. They will have until the last day of
May, inclusive, to cast their ballots on whether this Committee
Specification should be approved as an OASIS Standard or not.
Members who wish to discuss this ballot may do so through
member-discuss(a)lists.oasis-open.org.
In accordance with the OASIS Technical Committee Process, this
Committee Specification has already completed the necessary 60-day
public review period as noted in the submission below.
The normative TC Process for approval of Committee Specifications as
OASIS Standards is found at
http://www.oasis-open.org/committees/process.php#3.4
Any statements related to the IPR of this specification are posted at:
http://www.oasis-open.org/committees/ws-rx/ipr.php
Your participation in the review and balloting process is greatly
appreciated.
Mary
Mary P McRae
Manager of TC Administration, OASIS
email: mary.mcrae(a)oasis-open.org
phone: 603.232.9090
-----------------------
(a) Links to the approved Committee Specification in the TC's document
repository, and any appropriate supplemental documentation for the
specification, both of which must be written using the OASIS templates.
The specification may not have been changed between its approval as a
Committee Specification and its submission to OASIS for consideration
as an OASIS Standard, except for the changes on the title page and
running footer noting the approval status and date.
Web Services ReliableMessaging 1.1
PDF -
http://docs.oasis-open.org/ws-rx/wsrm/200702/wsrm-1.1-spec-cs-01.pdf
HTML -
http://docs.oasis-open.org/ws-rx/wsrm/200702/wsrm-1.1-spec-cs-01.html
Schema -
http://docs.oasis-open.org/ws-rx/wsrm/200702/wsrm-1.1-schema-200702.xsd
WSDL -
http://docs.oasis-open.org/ws-rx/wsrm/200702/wsrm-1.1-wsdl-200702.wsdl
Namespace -
http://docs.oasis-open.org/ws-rx/wsrm/200702/wsrm-1.1-rddl-200702.html
Web Services ReliableMessaging Policy 1.1
PDF -
http://docs.oasis-open.org/ws-rx/wsrmp/200702/wsrmp-1.1-spec-cs-01.pdf
HTML -
http://docs.oasis-open.org/ws-rx/wsrmp/200702/wsrmp-1.1-spec-cs-01.html
Schema -
http://docs.oasis-open.org/ws-rx/wsrmp/200702/wsrmp-1.1-schema-200702.xsd
Namespace -
http://docs.oasis-open.org/ws-rx/wsrmp/200702/wsrmp-1.1-rddl-200702.html
Web Services MakeConnection 1.0
PDF -
http://docs.oasis-open.org/ws-rx/wsmc/200702/wsmc-1.0-spec-cs-01.pdf
HTML -
http://docs.oasis-open.org/ws-rx/wsmc/200702/wsmc-1.0-spec-cs-01.html
Schema -
http://docs.oasis-open.org/ws-rx/wsmc/200702/wsmc-1.0-schema-200702.xsd
WSDL -
http://docs.oasis-open.org/ws-rx/wsmc/200702/wsmc-1.0-wsdl-200702.wsdl
Namespace -
http://docs.oasis-open.org/ws-rx/wsmc/200702/wsmc-1.0-rddl-200702.html
(b) The editable version of all files that are part of the Committee
Specification;
http://docs.oasis-open.org/ws-rx/wsrm/200702/wsrm-1.1-spec-cs-01.doc
http://docs.oasis-open.org/ws-rx/wsrmp/200702/wsrmp-1.1-spec-cs-01.doc
http://docs.oasis-open.org/ws-rx/wsmc/200702/wsmc-1.0-spec-cs-01.doc
(c) Certification by the TC that all schema and XML instances included
in the specification, whether by inclusion or reference, including
fragments of such, are well formed, and that all expressions are valid;
All schema and XML instances included in the specification are well
formed and all expressions are valid.
(d) A clear English-language summary of the specification;
The WS-ReliableMessaging 1.1 specification consists of multiple parts.
The core WS-ReliableMessaging 1.1 document defines a protocol for
reliable message exchange between two Web services, even in the
presence of network or system failures. For example, the protocol can
ensure the resending of messages that have been lost, and can ensure
that duplicate messages are not delivered. The protocol allows Web
service nodes to implement a variety of delivery assurances, including
At Most Once, At Least Once, Exactly Once and In Order delivery of
messages. The protocol fundamentally defines a one-way reliable channel
(known as a Sequence), but also includes mechanisms to optimize the
creation of two-way reliable exchanges. The protocol is designed to
compose with other relevant standards such as WS-Security and
WS-SecureConversation. The protocol allows developers to add reliable
delivery of messages to their applications on a variety of platforms,
including Java and .NET.
The WS-ReliableMessaging Policy 1.1 document defines an XML policy
language that enables Web services to advertise their support for the
WS-ReliableMessaging specification. The specification is designed for
use with the WS-Policy Framework. The language aids the
interoperability of nodes that support WS-ReliableMessaging by
publishing their support and requirements for aspects of reliable
messaging. For example, an endpoint may use this specification to
indicate that it requires that the reliable message protocol to be
secured using transport level security. WS-ReliableMessaging Policy is
designed to be used with other policy languages, such as WS-Security
Policy, in the scope of the WS-Policy Framework.
The WS-MakeConnection 1.0 document defines a protocol that can be
used to allow two-way communications when only a transport specific
back-channel (such as the HTTP response mechanism) is available. For
example, this allows a client to establish a two-way reliable
message exchange even in the presence of firewalls and network address
translation, that otherwise would prevent the server from initiating
connections to the client.
(e) A statement regarding the relationship of this specification to
similar work of other OASIS TCs or other standards developing
organizations;
-- The OASIS WS-Reliable Messaging (WSRM) TC also defines a reliable
messaging specification for Web services. The WS-RX TC and
WS-ReliableMessaging specification focuses on creating a specification
that works in conjunction with and composes with other specifications,
in particular the WS-Addressing, WS-Security and WS-SecureConversation,
and WS-Policy Framework specifications.
(f) Certification by at least three OASIS member organizations that
they are successfully using the specification;
Certification via email:
WSO2:
http://www.oasis-open.org/archives/ws-rx/200702/msg00068.html
IBM:
http://www.oasis-open.org/archives/ws-rx/200702/msg00069.html
SAP AG:
http://www.oasis-open.org/archives/ws-rx/200703/msg00000.html
(g) The beginning and ending dates of the public review(s), a pointer
to the announcement of the public review(s), and a pointer to an
account of each of the comments/issues raised during the public review
period(s), along with its resolution;
First Public Review: 24 August 2006 to 21 October 2006
Second Public Review: 12 February 2007 to 27 February 2007
Announcement of the first Public Review:
http://lists.oasis-open.org/archives/tc-announce/200608/msg00005.html
Announcement of the second Public Review:
http://lists.oasis-open.org/archives/tc-announce/200702/msg00004.html
Public Review Issue and Resolution Log:
http://docs.oasis-open.org/ws-rx/issues/pr/Issues.xml
(h) An account of and results of the voting to approve the
specification as a Committee Specification, including the date of the
ballot and a pointer to the ballot;
http://www.oasis-open.org/committees/ballot.php?id=1266
(i) An account of or pointer to votes and comments received in any
earlier attempts to standardize substantially the same specification,
together with the originating TC's response to each comment;
This is the first submission to the OASIS membership
(j) A pointer to the publicly visible comments archive for the
originating TC;
http://lists.oasis-open.org/archives/ws-rx-comment/
(k) A pointer to any minority reports submitted by one or more Members
who did not vote in favor of approving the Committee Specification,
which report may include statements regarding why the member voted
against the specification or that the member believes that Substantive
Changes were made which have not gone through public review; or
certification by the Chair that no minority reports exist.
There are no minority reports.
17 years
Re: JBoss web services versus AXE?
by Thomas Diesler
Hi Rob,
Is "Apache Web Services" the Axis stack?
http://ws.apache.org/axis2/
If so, it is because Axis is the worst stack out there, which is also
far from beeing a JavaEE5 certified stack.
A more valid question would be why do we not ship with the Sun RI
(https://jax-ws.dev.java.net/) or XFire (http://xfire.codehaus.org/)
both of which are more feature complete and stable than Axis.
The problem with XFire is that it is not (yet) JavaEE5 certified and
does not (and will not) support JAXRPC.
The Sun RI is certified but also does not support JAXRPC but recently
has made good progress and provides support for a number of WS-*
specifications.
For future direction we plan that JBossWS uses both of these stacks as
the underlying engine. So you will be able to run
JBossWS: AS50, AS42, AS40, TC55
JBossWS-RI: AS50, AS42, AS40, TC55
JBossWS-XF: AS50, AS42, AS40, TC55
This is planed for jbossws-2.1.0 (01-Sep-2007)
Bottom Line: If you care about interoperability use a certified stack,
which Axis is not.
cheers
-thomas
On Thu, 2007-05-10 at 13:29 -0400, Robert Greathouse wrote:
> Hi,
>
> I have a client who wanted to know why we did not include the Apache Web
> Services and instead built our own.
>
> The real question is for compatibility. The want to be able to write
> portable Web Services applications that can run on other App Servers.
>
> This is Telcordia and we are looking for ways to jam our foot in the
> door. So a good story on our portability would be nice.
>
> Robb,
--
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
Thomas Diesler
Web Service Lead
JBoss, a division of Red Hat
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
17 years
jbossas internal test suite with jbossws 1.2.0_SP1
by Aleksandar Kostadinov
Hi,
Can anybody tell me what are the required steps to run the JBoss AS
4.0.5_GA internal test suite with JBossWS 1.2.0_SP1
I can find only a wiki about 1.0 series
(http://wiki.jboss.org/wiki/Wiki.jsp?page=WebservicesReleaseGuide). And
I'm unable to find out how to make them passing.
I need to know how to do it with jdk14 as well jdk15!
Here is what I tried last (jdk14):
1. build jboss
2. replace all occurrences of jbossws14-client.jar with the one from jbossws
3. do the same with jboss-xml-binding.jar RC9
4. replace jbossws14.sar with jbossws40-jdk14.sar
And most tests fail. First ones with an error message like:
expected:<...s://qa02.qa.atl.jboss.com:8443...> but
was:<...://qa02.qa.atl.jboss.com:8080...>
So it looks like a configuration issue rather than jbossws bugs...
Also tried to deploy-jboss40-jdk14 jbossws and run the testsuite again
but had most tests fail too.
I've run out of time so any help will be appreciated,
Aleksandar
17 years
[Design of JBoss Web Services] - jbossws 1.2.1 questions/potential issues?
by tzhou
Hi all,
I posted this earlier to user forum but I didn't get any response. Thought it might be more appropriate for design forum. Sorry for the reposting...
I've been using JBossWS 1.2.1 along with Sun's Wiseman API for WS-Management development. After days of hard debugging, here are some of the issues (or maybe non-issues) I found. Either case, I hope the gurus here can shed some light.
1. WRONG_DOCUMENT_ERR when marshaling a SOAP document complaining that caller tries to append a node to another node that belongs to a different owner document
Turns out the problem was caused by DOMUtils, which uses ThreadLocal to keep track of owner document. This would work fine if everything is in the same thread. But in my case, Wiseman code constructs a response message, and then pass that response object to a separate handler thread for further processing. And that becomes a _problem_. I'm not sure about the rationale behind the threadlocal mechanism, but to me assuming all DOM processing is in one thread is simply dangerous. Thoughts?
2. JAXB and JBossWS compatibility issue
The upper-level code (Wiseman) constructs a SOAP message, and uses JAXB to marshal content to the body, something like "marshaller.marshal(contentObj, getBody())". The result: only the top-level node gets added to the body, but not its decedents. After some digging, I found the problem was caused by SOAPBodyImpl.appendChild(), which constructs a new child from the existing child node. This apparently is a problem for JAXB, since the subsequent tree construction is all based on the original child node. The same issue also occurs to SOAPHeaderImpl.appendChild().
FYI, I'm using JBossWS 1.2.1GA.
Thanks,
Ting
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4044128#4044128
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4044128
17 years
