CXF Server & Client | Same JRE | Config Conflict

2008-08-14 Thread Manolescu, Radu (IT) 
We are writing a program which is a CXF server on one side, and a client
to other services on another side.
We have successfully implemented the server and the client separately,
but we cannot bring them together in one JRE, because of configuration
conflicts.
 
 
Our CXF server faces a C# GUI and communicates with it via SOAP
messages. This works in a prototype.
The server needs to interact with some outside services for information.
We have successfully tested prototype clients for those services.
However, when we integrate the two, we find that the client becomes
unable to communicate to the outside services.
The exception being thrown is shown below. We believe that this means
that the conduit definition is not being found, and this raises the
question of which config file it should be in.
 

Caused by: java.io.IOException: Illegal Protocol https for HTTP
URLConnection Factory.

at
org.apache.cxf.transport.http.HttpURLConnectionFactoryImpl.createConnect
ion(HttpURLConnectionFactoryImpl.java:44)

at
org.apache.cxf.transport.http.MSHTTPConduit.prepare(MSHTTPConduit.java:4
25)

at
org.apache.cxf.interceptor.MessageSenderInterceptor.handleMessage(Messag
eSenderInterceptor.java:46)

... 37 more

 

Does anyone have any experience with running a CXF service and client in
the same JRE?
 
Thanks,
 
 
Radu Manolescu
Morgan Stanley | Technology
2000 Westchester Ave, 1st Floor | Purchase, NY  10577


NOTICE: If received in error, please destroy and notify sender. Sender does not 
intend to waive confidentiality or privilege. Use of this email is prohibited 
when received in error.

RE: CXF Error | Found element ... but could not find matching RPC/Literal part

2008-08-07 Thread Manolescu, Radu (IT) 
This worked, thank you!
We have extended DepthXMLStreamReader and in an interceptor in the
RECEIVE phase we have replaced the XMLStreamReader with an instance of
our DepthXMLStreamReader subclass.


Radu Manolescu
Morgan Stanley | Technology
2000 Westchester Ave, 1st Floor | Purchase, NY  10577

-Original Message-
From: Daniel Kulp [mailto:[EMAIL PROTECTED] 
Sent: Monday, August 04, 2008 4:29 PM
To: users@cxf.apache.org
Cc: Manolescu, Radu (IT); cxf-ea; Saveliff, James (IT)
Subject: Re: CXF Error | Found element ... but could not find matching
RPC/Literal part




On Monday 04 August 2008 4:15:39 pm Manolescu, Radu (IT) wrote:
> We must accept the messages sent by the service as they are, since we 
> cannot request it to be modified.
> We are thinking of writing an interceptor that would use XSL to modify

> the incoming message to make it WS-I BP compliant.
> Does this approach make sense? Is there a standard interceptor for 
> this, where we can configure the stylesheet to be used?
> We are looking at StaxInInterceptor as a model for our new
interceptor.
> Is there another more appropriate interceptor?
>
> We have developed an XSL stylesheet that removes all namespaces from 
> the incoming message.
> Would this be sufficient to make the incoming messages WS-I BP 
> compliant?

Probably not.   If the schemas have a elementFormDefault="qualified",
then the 
child elements should be qualified.   That, and the direct child of
soap:body 
needs to be qualified as well.   Using an XSLT would also be slower than
need 
be.   Use of the XSLT would require loading the whole message in (most
likely 
into a dom) where it's transformed.

However, I think you're on the right track.   I would SUGGEST creating a

subclass of our DepthXMLStreamReader that overrides the public QName
getName() public String getNamespaceURI()

To do something like:
public QName getName() {
   QName qn = super.getName();
   if (getDepth() == 4) {   
   // need to double check the depth.  4 is 
   // env/body/wrapper/part so should be OK
   qn = new QName("", qn.getLocalPart());
   }
   return qn;
}
(and likewise for getNamespaceURI())

In an interceptor immediately AFTER the StaxInInterceptor, grab the
reader and wrapper it with your implementation.

Dan



>
> Thanks,
>
>
> Radu Manolescu
> Morgan Stanley | Technology
> 2000 Westchester Ave, 1st Floor | Purchase, NY  10577
>
> -Original Message-
> From: Daniel Kulp [mailto:[EMAIL PROTECTED]
> Sent: Friday, August 01, 2008 12:12 PM
> To: users@cxf.apache.org
> Cc: cxf-ea; Saveliff, James (IT)
> Subject: Re: CXF Error | Found element ... but could not find matching

> RPC/Literal part
>
>
> Well, that SOAP response is NOT valid according to WSI Basic Profile 
> rules for RPC/Lit.
>
> The part accessors for RPC message should NOT be namespace qualified.
> Thus, the response message is invalid.
>
> Also, the message part:
>  is a 
> type (not element, which is correct for rpc/lit)
>
> Thus, the element would take on the target namespace of the wsdl where
> it's defined.   It wouldn't take on the namespace of the type.
>
> In anycase, this is a bug in the other service that is producing that 
> message.  It is not producing a correct message.
>
> Dan
>
> On Jul 31, 2008, at 6:02 PM, Manolescu, Radu (IT) wrote:
> > We did as suggested, but the error remains the same.
> > Upon closer inspection, we are confused by the way wsdl2java has 
> > interpreted the WSDL to generate the Java code.
> >
> >
> > Looking at the WSDL, we expect the operation's response to contain 
> > the elements "submitRawBidSetResponse/outputDataType", shown below 
> > with full namespace for clarity:
> > <{http://www.caiso.com/soa/2007-08-16/
> > submitRawBidSet.wsdl}submitRawBidS
> > etResponse>
> >
> > <{http://www.caiso.com/soa/2006-06-13/
> > SubmitStandardOutput.xsd}outputDat
> > aType>
> > 
> > 
> > Or maybe only the inner element "outputDataType":
> > <{http://www.caiso.com/soa/2006-06-13/
> > SubmitStandardOutput.xsd}outputDat
> > aType>
> > 
> >
> > However, the generated Java code has this signature, which uses the 
> > namespace from one of the above elements and the local part of the 
> > other:
> >@WebResult(name = "outputDataType"
> >, targetNamespace =
> > "http://www.caiso.com/soa/2007-08-16/submitRawBidSet.wsdl";
> >, partName = "outputDataType")
> >
> >
> > As a result of this mismatch, the response from the service cannot 
> > be parsed.
> > Is the signature of the generated Java code correct?
>

RE: CXF Error | Found element ... but could not find matching RPC/Literal part

2008-08-04 Thread Manolescu, Radu (IT) 
We must accept the messages sent by the service as they are, since we
cannot request it to be modified.
We are thinking of writing an interceptor that would use XSL to modify
the incoming message to make it WS-I BP compliant.
Does this approach make sense? Is there a standard interceptor for this,
where we can configure the stylesheet to be used?
We are looking at StaxInInterceptor as a model for our new interceptor.
Is there another more appropriate interceptor?

We have developed an XSL stylesheet that removes all namespaces from the
incoming message.
Would this be sufficient to make the incoming messages WS-I BP
compliant?

Thanks,


Radu Manolescu
Morgan Stanley | Technology
2000 Westchester Ave, 1st Floor | Purchase, NY  10577

-Original Message-
From: Daniel Kulp [mailto:[EMAIL PROTECTED] 
Sent: Friday, August 01, 2008 12:12 PM
To: users@cxf.apache.org
Cc: cxf-ea; Saveliff, James (IT)
Subject: Re: CXF Error | Found element ... but could not find matching
RPC/Literal part


Well, that SOAP response is NOT valid according to WSI Basic Profile  
rules for RPC/Lit.

The part accessors for RPC message should NOT be namespace qualified.   
Thus, the response message is invalid.

Also, the message part:

is a type (not element, which is correct for rpc/lit)

Thus, the element would take on the target namespace of the wsdl where  
it's defined.   It wouldn't take on the namespace of the type.

In anycase, this is a bug in the other service that is producing that  
message.  It is not producing a correct message.

Dan



On Jul 31, 2008, at 6:02 PM, Manolescu, Radu (IT) wrote:

> We did as suggested, but the error remains the same.
> Upon closer inspection, we are confused by the way wsdl2java has
> interpreted the WSDL to generate the Java code.
>
>
> Looking at the WSDL, we expect the operation's response to contain the
> elements "submitRawBidSetResponse/outputDataType", shown below with  
> full
> namespace for clarity:
> <{http://www.caiso.com/soa/2007-08-16/ 
> submitRawBidSet.wsdl}submitRawBidS
> etResponse>
>   
> <{http://www.caiso.com/soa/2006-06-13/ 
> SubmitStandardOutput.xsd}outputDat
> aType>
>   
> 
> Or maybe only the inner element "outputDataType":
> <{http://www.caiso.com/soa/2006-06-13/ 
> SubmitStandardOutput.xsd}outputDat
> aType>
> 
>
> However, the generated Java code has this signature,
> which uses the namespace from one of the above elements and the local
> part of the other:
>@WebResult(name = "outputDataType"
>, targetNamespace =
> "http://www.caiso.com/soa/2007-08-16/submitRawBidSet.wsdl";
>, partName = "outputDataType")
>
>
> As a result of this mismatch, the response from the service cannot be
> parsed.
> Is the signature of the generated Java code correct?
> How can we get around this?
>
>
>
> (All comments below are ours.)
>
>  targetNamespace =
> "http://www.caiso.com/soa/2007-08-16/submitRawBidSet.wsdl";
> xmlns:tns1  = "http://www.caiso.com/soa/2007-08-16/ 
> submitRawBidSet"
> xmlns:tns   =
> "http://www.caiso.com/soa/2007-08-16/submitRawBidSet.wsdl";
> xmlns:typeFault =
> "http://www.caiso.com/soa/2006-06-13/StandardOutput.xsd";
> xmlns:typeIn=
> "http://www.caiso.com/soa/2006-06-13/StandardAttachmentInfor.xsd";
> xmlns:typeOut   =
> "http://www.caiso.com/soa/2006-06-13/SubmitStandardOutput.xsd";
> ">
> 
>   
>   
>   
>   
> 
>
> 
> 
>   
>   
> 
>
> 
>  xmlns:m="http://www.caiso.com/soa/2006-06-13/SubmitStandardOutput.xsd";
>
targetNamespace="http://www.caiso.com/soa/2006-06-13/SubmitStandardOutpu
> t.xsd"
> elementFormDefault="qualified"
> attributeFormDefault="unqualified"
>>
> 
> 
> 
>
> // CXF-generated code
> SubmitRawBidSet.java
>@WebResult(name = "outputDataType"
>, targetNamespace =
> "http://www.caiso.com/soa/2007-08-16/submitRawBidSet.wsdl";
>, partName = "outputDataType")
>@WebMethod(action =
> "http://www.caiso.com/soa/2007-08-16/submitRawBidSet";)
>public  
> com.caiso.soa._2006_06_13.submitstandardoutput.OutputDataType
> submitRawBidSet(
>@WebParam(partName = "rawBidSet_attachment", name =
> "rawBidSet_attachment")
>byte[] rawBidSetAttachment
>) throws FaultReturnType;
>
>
> 
> 
>xmlns="http://www.caiso.com/soa/2007-08-16/submitRawBidSet";
>   xmlns:ns1="http://www.caiso.com/soa/2007-08-16/submitRawBidSet";>
>  
> xmlns="http://www.caiso.com/so

RE: CXF Error | Found element ... but could not find matching RPC/Literal part

2008-07-31 Thread Manolescu, Radu (IT) 
We did as suggested, but the error remains the same.
Upon closer inspection, we are confused by the way wsdl2java has
interpreted the WSDL to generate the Java code.


Looking at the WSDL, we expect the operation's response to contain the
elements "submitRawBidSetResponse/outputDataType", shown below with full
namespace for clarity:
<{http://www.caiso.com/soa/2007-08-16/submitRawBidSet.wsdl}submitRawBidS
etResponse>

<{http://www.caiso.com/soa/2006-06-13/SubmitStandardOutput.xsd}outputDat
aType>


Or maybe only the inner element "outputDataType":
<{http://www.caiso.com/soa/2006-06-13/SubmitStandardOutput.xsd}outputDat
aType>


However, the generated Java code has this signature,
which uses the namespace from one of the above elements and the local
part of the other:
@WebResult(name = "outputDataType"
, targetNamespace =
"http://www.caiso.com/soa/2007-08-16/submitRawBidSet.wsdl";
, partName = "outputDataType")


As a result of this mismatch, the response from the service cannot be
parsed.
Is the signature of the generated Java code correct?
How can we get around this?



(All comments below are ours.)

http://www.caiso.com/soa/2007-08-16/submitRawBidSet.wsdl";
xmlns:tns1  = "http://www.caiso.com/soa/2007-08-16/submitRawBidSet";
xmlns:tns   =
"http://www.caiso.com/soa/2007-08-16/submitRawBidSet.wsdl";
xmlns:typeFault =
"http://www.caiso.com/soa/2006-06-13/StandardOutput.xsd";
xmlns:typeIn=
"http://www.caiso.com/soa/2006-06-13/StandardAttachmentInfor.xsd";
xmlns:typeOut   =
"http://www.caiso.com/soa/2006-06-13/SubmitStandardOutput.xsd";
">














http://www.caiso.com/soa/2006-06-13/SubmitStandardOutput.xsd";
targetNamespace="http://www.caiso.com/soa/2006-06-13/SubmitStandardOutpu
t.xsd"
elementFormDefault="qualified"
attributeFormDefault="unqualified"
>




// CXF-generated code
SubmitRawBidSet.java
@WebResult(name = "outputDataType"
, targetNamespace =
"http://www.caiso.com/soa/2007-08-16/submitRawBidSet.wsdl";
, partName = "outputDataType")
@WebMethod(action =
"http://www.caiso.com/soa/2007-08-16/submitRawBidSet";)
public com.caiso.soa._2006_06_13.submitstandardoutput.OutputDataType
submitRawBidSet(
@WebParam(partName = "rawBidSet_attachment", name =
"rawBidSet_attachment")
byte[] rawBidSetAttachment
) throws FaultReturnType;




http://www.caiso.com/soa/2007-08-16/submitRawBidSet";
xmlns:ns1="http://www.caiso.com/soa/2007-08-16/submitRawBidSet";>
http://www.caiso.com/soa/2006-06-13/SubmitStandardOutput.xsd";

xmlns:ns2="http://www.caiso.com/soa/2006-06-13/SubmitStandardOutput.xsd";
>

// RPCInInterceptor throws exception when parsing above message
Caused by: org.apache.cxf.interceptor.Fault:
Found element
{http://www.caiso.com/soa/2006-06-13/SubmitStandardOutput.xsd}outputData
Type
but could not find matching RPC/Literal part
at
org.apache.cxf.binding.soap.interceptor.RPCInInterceptor.handleMessage(R
PCInInterceptor.java:128)




Thanks,


Radu Manolescu
Morgan Stanley | Technology
2000 Westchester Ave, 1st Floor | Purchase, NY  10577
[EMAIL PROTECTED]

-Original Message-----
From: Daniel Kulp [mailto:[EMAIL PROTECTED] 
Sent: Friday, July 18, 2008 2:13 PM
To: users@cxf.apache.org
Cc: cxf-ea; Saveliff, James (IT)
Subject: Re: CXF Error | Found element ... but could not find matching
RPC/Literal part


On Jul 18, 2008, at 1:33 PM, Manolescu, Radu (IT) wrote:

> OK, so we understand that the response is not WSI-BP compatible. (Our
> counterparty is using Axis.)
> (Grumbling: "great, so now we have two Apache products that don't talk
> to each other")

If everyone followed the standards, their wouldn't be a  
problem..   That's what standards are for.  :-(

I'm really not sure why the below isn't working.   That looks  
completely correct.   The only place we call "new RPCInInterceptor()"  
in the code is:
sb.getInInterceptors().add(new RPCInInterceptor());
Thus, removing it from the binding like you are doing should work  
fine.Very strange.   You might need to debug into that one.  :-(


Another option might be to use a locally modified WSDL.   Change:
>> > type="typeOut:outputDataType">

to

>> > type="typeOut:outputDataType">



An XSLT might be able to automate that.


Dan





> We set out to replace the standard RPCInInterceptor by our own  
> modified
> copy, which would accept the Axis messages.
>
> We have used the code pattern below, which has proved effective in
> replacing othe

RE: CXF Error | Found element ... but could not find matching RPC/Literal part

2008-07-18 Thread Manolescu, Radu (IT) 
OK, so we understand that the response is not WSI-BP compatible. (Our
counterparty is using Axis.)
(Grumbling: "great, so now we have two Apache products that don't talk
to each other")
We set out to replace the standard RPCInInterceptor by our own modified
copy, which would accept the Axis messages.

We have used the code pattern below, which has proved effective in
replacing other interceptors:

// Replace RPCInInterceptor to ensure compatibility with Axis
i = 0;
for (Interceptor interceptor: binding.getInInterceptors())
{
if (interceptor instanceof RPCInInterceptor)
{
binding.getInInterceptors().remove(i);
System.out.println("RPCInInterceptor removed from
binding.");
}
}
binding.getInInterceptors().add(new MSRPCInInterceptor());

My log shows the following interceptor flow:

Current flow:
  receive [LoggingInInterceptor, MSXMLStreamInInterceptor]
  post-stream [StaxInInterceptor]
  read [ReadHeadersInterceptor, SoapActionInInterceptor]
  pre-protocol [MustUnderstandInterceptor, SOAPHandlerInterceptor,
LogicalHandlerInInterceptor]
  post-protocol [CheckFaultInterceptor]
  unmarshal [URIMappingInterceptor, RPCInInterceptor,
SoapHeaderInterceptor, MSRPCInInterceptor]
  post-logical [WrapperClassInInterceptor]
  pre-invoke [SwAInInterceptor, HolderInInterceptor]

Note that our interceptor (MSRPCInInterceptor) has been added, but the
original interceptor (RPCInInterceptor) is still there.
We also get this output, which indicates that RPCInInterceptor should
have been removed (why twice?):
RPCInInterceptor removed from binding.
RPCInInterceptor removed from binding.

We also find this in the log, indicating that the interceptor is
attached to and should be removed from the binding object (and not other
objects):
Interceptors contributed by binding:
[EMAIL PROTECTED],
[EMAIL PROTECTED],
[EMAIL PROTECTED], ...

What are we missing? Is there a built-in reason why RPCInInterceptor
cannot be removed from the chain?


Thanks,



Radu Manolescu
Morgan Stanley | Technology
2000 Westchester Ave, 1st Floor | Purchase, NY  10577
Phone: +1 914 225-5871
[EMAIL PROTECTED]

-Original Message-
From: Daniel Kulp [mailto:[EMAIL PROTECTED] 
Sent: Thursday, July 17, 2008 2:25 PM
To: users@cxf.apache.org
Cc: cxf-ea; Saveliff, James (IT)
Subject: Re: CXF Error | Found element ... but could not find matching
RPC/Literal part


The soap message is wrong for an rpc/lit response.

The  element should be:


Per RPC/Lit rules, the part accessors come from the part names in the  
message/parts of the wsdl.   They are also supposed to be unqualified  
per wsi-bp rules (although some older toolkits do qualify them so our
RPCInInterceptor will allow that, but the out interceptor will not
qualify them).

Dan



On Jul 17, 2008, at 2:14 PM, Manolescu, Radu (IT) wrote:

> We have implemented a CXF client from a counterparty-supplied WSDL.
> As we call one operation, we get back a response containing valid
> business messages.
> However, the RPCInInterceptor throws an exception because it "could  
> not
> find matching RPC/Literal part".
>
> We have checked the response, and it contains the element
> "outputDataType", which is mentioned in the exception.
> In the response, this element's namespace is declared as
> "http://www.company.com/soa/SubmitStandardOutput.xsd";.
> When we look in the WSDL, I can see that the element outputDataType is
> declared in the operation's return type, with the same namespace.
> We do not understand why CXF "could not find matching RPC/Literal  
> part".
>
> We understand that CXF does not support RPC/Encoded.
> However, we have checked that the WSDL conforms to the RPC/Literal
> restrictions:
> * Each message contains zero or more parts.
> * Each part points to a schema type definition that describes the
> content of that part.
> * In the SOAP binding, the style is "RPC" and the use is
> "literal".
>
>
> What are we missing?
>
>
>
> -- EXCEPTION: --
> Caused by: org.apache.cxf.interceptor.Fault: Found element
> {http://www.company.com/soa/SubmitStandardOutput.xsd}outputDataType  
> but
> could not find matching RPC/Literal part
>   at
> org 
> .apache.cxf.binding.soap.interceptor.RPCInInterceptor.handleMessage(R
> PCInInterceptor.java:128)
>
> -- RESPONSE: --
>xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/";
>   xmlns:xsd="http://www.w3.org/2001/XMLSchema";
>   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";>
>   
>  xmlns="http:/

CXF Error | Found element ... but could not find matching RPC/Literal part

2008-07-17 Thread Manolescu, Radu (IT) 
We have implemented a CXF client from a counterparty-supplied WSDL.
As we call one operation, we get back a response containing valid
business messages.
However, the RPCInInterceptor throws an exception because it "could not
find matching RPC/Literal part".

We have checked the response, and it contains the element
"outputDataType", which is mentioned in the exception.
In the response, this element's namespace is declared as
"http://www.company.com/soa/SubmitStandardOutput.xsd";.
When we look in the WSDL, I can see that the element outputDataType is
declared in the operation's return type, with the same namespace.
We do not understand why CXF "could not find matching RPC/Literal part".

We understand that CXF does not support RPC/Encoded.
However, we have checked that the WSDL conforms to the RPC/Literal
restrictions:
*   Each message contains zero or more parts.
*   Each part points to a schema type definition that describes the
content of that part. 
*   In the SOAP binding, the style is "RPC" and the use is
"literal".


What are we missing?



-- EXCEPTION: --
Caused by: org.apache.cxf.interceptor.Fault: Found element
{http://www.company.com/soa/SubmitStandardOutput.xsd}outputDataType but
could not find matching RPC/Literal part
at
org.apache.cxf.binding.soap.interceptor.RPCInInterceptor.handleMessage(R
PCInInterceptor.java:128)

-- RESPONSE: --
http://schemas.xmlsoap.org/soap/envelope/";
xmlns:xsd="http://www.w3.org/2001/XMLSchema";
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";>

http://www.company.com/soa/submitDataSet";

xmlns:ns1="http://www.company.com/soa/submitDataSet";>
http://www.company.com/soa/SubmitStandardOutput.xsd";

xmlns:ns2="http://www.company.com/soa/SubmitStandardOutput.xsd";>






-- WSDL: --

http://www.company.com/soa/SubmitStandardOutput.xsd";>


http://schemas.xmlsoap.org/wsdl/";>
acknowledge data set submitted





http://schemas.xmlsoap.org/wsdl/";>
submit data set







http://schemas.xmlsoap.org/soap/http";
/>

http://www.company.com/soa/2007-08-16/someOp";
style="rpc" />



http://www.company.com/soa/2007-08-16/someOp"; />







http://schemas.xmlsoap.org/ws/2002/12/policy";>

http://schemas.xmlsoap.org/ws/2002/07/utility";>

http://schemas.xmlsoap.org/ws/2002/12/secext";>







wssp:X509v3







http://schemas.xmlsoap.org/soap/envelope/";

xmlns:ns2="http://www.company.com/soa/StandardAttachmentInfor.xsd";>

/SOAP-ENV:Envelope/SOAP-ENV:Header/ns2:standardAttachmentInfor






http://schemas.xmlsoap.org/ws/2002/12/secext";>







wssp:X509v3







http://schemas.xmlsoap.org/soap/envelope/";

xmlns:ns1="http://www.company.com/soa/2006-09-30/companyWSHeader.xsd";>

/SOAP-ENV:Envelope/SOAP-ENV:Header/ns1:companyWSHeader






http://schemas.xmlsoap.org/ws/2002/12/secext";>







wssp:X509v3







http://schemas.xmlsoap.org/soap/envelope/";

xmlns:ns1="http://www.company.com/soa/schemas/2005/09/attachmenthash";>

/SOAP-ENV:Envelope/SOAP-ENV:Header/ns1:attachmentHash

Multiple-Service CXF Client

2008-07-07 Thread Manolescu, Radu (IT) 
We need to write a program that connects (as a client) to more than one
web service. We have written CXF clients for each service separately,
and they each work.
As we try to combine the code bases and run them in the same JRE, we are
not sure how to make sure things continue to work.
 
 
For instance, we have come to believe that we need more than one
instance of the CXF Bus (org.apache.cxf.bus.CXFBusImpl) configured in
our program. This is because the CXF Bus bean references a
WSS4JOutInterceptor bean which is configured to access a specific
service.
To configure more than one CXF bus, we have switched from the "cxf:bus"
namespace configuration tags to the basic Spring config style:
  
 
This works for one service, but it seems that the client code expects
the CXFBus bean to be bound under the name "cxf". The client never
references the CXFBus bean explicitly, and therefore probably finds it
by some hard-coded reference to the bean name.  In the above
configuration fragment, we get an error if we change the bean's name
away from "cxf".
 
Since we need more than one CXFBus bean to be configured, we need to
control these beans' names. 
Furthermore, we believe that we need to specify that a given CXF client
should be "bound" to a CXF Bus instance (since this bus instance is
configured to interact with the service).
Is there an API call that can bind a CXF client to an instance of CXF
Bus?
 
Since CXF is configured in Spring files, we have tried to load the
Spring application context explicitly in the client code. This has
resulted in errors, since the map CXFBusImpl.extensions turned out empty
at runtime.
 
Is there a way to load the CXF Bus bean directly and associate it to a
service object? 
Looking at
org.apache.cxf.bus.spring.SpringBusFactory.defaultBusNotExists(), it
seems that the BusFactory will always return the bean named "cxf" from
the application context.
 
How can we develop a program that uses CXF to connect to more than one
service?

 
Thanks,
 
Radu Manolescu
Morgan Stanley | Technology
2000 Westchester Ave, 1st Floor | Purchase, NY  10577
[EMAIL PROTECTED]


NOTICE: If received in error, please destroy and notify sender. Sender does not 
intend to waive confidentiality or privilege. Use of this email is prohibited 
when received in error.

CXF | WS-Policy| Custom Header

2008-06-25 Thread Manolescu, Radu (IT) 
We need to send SOAP messages which include a custom security header
designed by our counterparty. The header is declared inside a Policy
element (WS-Policy). (See "CPTYWSHeader", below.)
We did WSDL-first, so our WSDL is static. We understand that we can get
CXF to add these custom headers by configuring WS-Policy in Spring, but
we have not found enough documentation or examples for this.

We have looked at the sample
apache-cxf-2.1.1-SNAPSHOT-src\systests\src\test\java\org\apache\cxf\syst
est\ws\policy\, but it is not clear how we can get to add a custom
element inside soap:header.


How can we add a custom element inside soap:header?
Which interceptor can provide this service, or do we have to write our
own? At what point in the interceptor chain should this interceptor
operate?


WSDL fragment:


http://www.cpty.com/submitRawDataSet"; />



http://schemas.xmlsoap.org/ws/2002/12/policy";>

http://schemas.xmlsoap.org/ws/2002/07/utility";>

http://schemas.xmlsoap.org/ws/2002/12/secext";>


wssp:X509v3


http://schemas.xmlsoap.org/soap/envelope/";
xmlns:ns1="http://www.cpty.com/CPTYWSHeader.xsd";>

/SOAP-ENV:Envelope/SOAP-ENV:Header/ns1:CPTYWSHeader




 
 
 
Our messages need to look like this:


 
 
 
 
Our out flow currently contains the following interceptors:

  pre-logical [HolderOutInterceptor, SwAOutInterceptor,
WrapperClassOutInterceptor, SoapHeaderOutFilterInterceptor]
  post-logical [SoapActionOutInterceptor]
  prepare-send [MessageSenderInterceptor]
  pre-stream [LoggingOutInterceptor, MSXMLStreamOutInterceptor,
SoapPreProtocolOutInterceptor, AttachmentOutInterceptor]
  pre-protocol [SAAJOutInterceptor, WSS4JOutInterceptor,
SOAPHandlerInterceptor, SOAPAuthOutInterceptor]
  write [SoapOutInterceptor]
  pre-marshal [LogicalHandlerOutInterceptor]
  marshal [RPCOutInterceptor]
  post-protocol [WSS4JOutInterceptorInternal]
  write-ending [SoapOutEndingInterceptor]
  pre-protocol-ending [SAAJOutEndingInterceptor]
  pre-stream-ending [AttachmentOutEndingInterceptor]
  prepare-send-ending [MessageFlushInterceptor,
MessageSenderEndingInterceptor]

We have read
http://netzooid.com/blog/2007/04/23/cxf-spring-and-ws-policy-internals/.


 
Thanks,
 
 
Radu Manolescu
Morgan Stanley | Technology
2000 Westchester Ave, 1st Floor | Purchase, NY  10577
Phone: +1 914 225-5871
Mobile: +1 203 648-6964
[EMAIL PROTECTED]


NOTICE: If received in error, please destroy and notify sender. Sender does not 
intend to waive confidentiality or privilege. Use of this email is prohibited 
when received in error.

RE: org.apache.cxf.jaxws.interceptors.SwAOutInterceptor | Unreachable Code

2008-06-24 Thread Manolescu, Radu (IT) 
I have entered the Jira.

Adding support for byte[] is a little more tricky, in my understanding,
because we cannot know (in a general case) what the content of the
byte[] represents. In our case, because we know that the byte[] contains
XML, I did the following:

//{ Start new code //
} else if (o instanceof byte[]) {
Source source = new StreamSource(new
ByteArrayInputStream((byte[])o));
dh = new DataHandler(createDataSource(source, ct));
//} End new code //
} else if (dh == null) {
throw new Fault(new
org.apache.cxf.common.i18n.Message("ATTACHMENT_NOT_SUPPORTED", 
 
LOG, o.getClass()));

I've put this code in a modified copy of SwAOutInterceptor; I have
removed SwAOutInterceptor from the chain and added our copy instead.

This seems to work for us, but does not solve the problem in general.

To solve the problem in general, I suppose you could:
-- add a method to SwAOutInterceptor
public DataHandler getDataHandler(Object o)
{
throw new RuntimeException("Extend this class and override this
method");
}
-- handle the byte[] as follows:
//{ Start new code //
} else if (o instanceof byte[]) {
dh = getDataHandler(o);
//} End new code //
This way, the base class (SwAOutInterceptor) is still unable to handle
byte[] properly, but at least it provides a mechanism that allows the
user to plug in the appropriate handling of that type.
It's quite inelegant, though.


Radu Manolescu
Morgan Stanley | Technology
2000 Westchester Ave, 1st Floor | Purchase, NY  10577
Phone: +1 914 225-5871
Mobile: +1 203 648-6964
[EMAIL PROTECTED]

-Original Message-
From: Daniel Kulp [mailto:[EMAIL PROTECTED] 
Sent: Monday, June 23, 2008 9:14 PM
To: users@cxf.apache.org
Cc: Saveliff, James (IT)
Subject: Re: org.apache.cxf.jaxws.interceptors.SwAOutInterceptor |
Unreachable Code


Yea, that looks like dead code to me as well.

Feel free to log a JIRA with a patch.   It would be great if you want  
to add byte[] support as well.   :-)

Dan


On Jun 23, 2008, at 4:56 PM, Manolescu, Radu (IT) wrote:

> 1. In my opinion, the code at
> org.apache.cxf.jaxws.interceptors.SwAOutInterceptor:197 is 
> unreachable.
> 2. Why does this interceptor support only Source/Image/DataHandler? I 
> have a byte[] as a SOAP attachment, and this throws an exception at 
> line 195.
>
> How can we handle a byte[] as a SOAP attachment using CXF SwA?
>
>
> Examine the code fragment below to see that line 197 is unreachable:
> On line 148, dh=null.
> Then we test the object o for its data type, in a series of if/elseif 
> clauses.
> There are two possibilities for the object o:
> 1. o instanceof Source / Image / DataHandler 2. all other situations
>
> In situation 1, execution will enter the blocks after lines 151, or 
> 155, or 182, then continue from line 202.
> In situation 2, execution will not enter any of the blocks after lines

> 151, or 155, or 182. As a result, dh is still null when we reach line 
> 194, and a Fault is thrown.
> Either way, execution cannot reach line 197.
>
> package org.apache.cxf.jaxws.interceptors;
> public class SwAOutInterceptor extends AbstractSoapInterceptor {
>DataHandler dh = null; // LINE 148
>if (o instanceof Source) { // LINE 151
>dh = new DataHandler(createDataSource((Source)o, ct));
>
>} else if (o instanceof Image) { // LINE 155
>dh = new DataHandler(new 
> ByteArrayDataSource(bos.toByteArray(), ct));
>} else if (o instanceof DataHandler) { // LINE 182
>dh = (DataHandler) o;
>} else if (dh == null) { // LINE 194
>throw new Fault(...);
>} else if (dh.getDataSource() instanceof URLDataSource) { 
> // <== LINE 197: UNREACHABLE
>URLDataSource ds = (URLDataSource)dh.getDataSource();
>dh = new DataHandler(ds.getURL());
>ct = ds.getContentType();
>} // LINE 201
>
>
>
> Radu Manolescu
> Morgan Stanley | Technology
> 2000 Westchester Ave, 1st Floor | Purchase, NY  10577
> Phone: +1 914 225-5871
> Mobile: +1 203 648-6964
> [EMAIL PROTECTED]
> 
>
> NOTICE: If received in error, please destroy and notify sender.  
> Sender does not intend to waive confidentiality or privilege. Use of  
> this email is prohibited when received in error.

---
Daniel Kulp
[EMAIL PROTECTED]
http://www.dankulp.com/blog


NOTICE: If received in error, please destroy and notify sender. Sender does not 
intend to waive confidentiality or privilege. Use of this email is prohibited 
when received in error.

org.apache.cxf.jaxws.interceptors.SwAOutInterceptor | Unreachable Code

2008-06-23 Thread Manolescu, Radu (IT) 
1. In my opinion, the code at
org.apache.cxf.jaxws.interceptors.SwAOutInterceptor:197 is unreachable.
2. Why does this interceptor support only Source/Image/DataHandler? I
have a byte[] as a SOAP attachment, and this throws an exception at line
195.
 
How can we handle a byte[] as a SOAP attachment using CXF SwA?
 
 
Examine the code fragment below to see that line 197 is unreachable:
On line 148, dh=null.
Then we test the object o for its data type, in a series of if/elseif
clauses.
There are two possibilities for the object o:
1. o instanceof Source / Image / DataHandler
2. all other situations
 
In situation 1, execution will enter the blocks after lines 151, or 155,
or 182, then continue from line 202.
In situation 2, execution will not enter any of the blocks after lines
151, or 155, or 182. As a result, dh is still null when we reach line
194, and a Fault is thrown.
Either way, execution cannot reach line 197.
 
package org.apache.cxf.jaxws.interceptors;
public class SwAOutInterceptor extends AbstractSoapInterceptor {
DataHandler dh = null; // LINE 148
if (o instanceof Source) { // LINE 151
dh = new DataHandler(createDataSource((Source)o, ct));

} else if (o instanceof Image) { // LINE 155
dh = new DataHandler(new
ByteArrayDataSource(bos.toByteArray(), ct));
} else if (o instanceof DataHandler) { // LINE 182
dh = (DataHandler) o;
} else if (dh == null) { // LINE 194
throw new Fault(...);
} else if (dh.getDataSource() instanceof URLDataSource) { //
<== LINE 197: UNREACHABLE
URLDataSource ds = (URLDataSource)dh.getDataSource();
dh = new DataHandler(ds.getURL()); 
ct = ds.getContentType();
} // LINE 201

 
 
Radu Manolescu
Morgan Stanley | Technology
2000 Westchester Ave, 1st Floor | Purchase, NY  10577
Phone: +1 914 225-5871
Mobile: +1 203 648-6964
[EMAIL PROTECTED]


NOTICE: If received in error, please destroy and notify sender. Sender does not 
intend to waive confidentiality or privilege. Use of this email is prohibited 
when received in error.

Jira CXF-1538 | SAAJOutInterceptor | Message Content OutputStream null | Seeking Workaround

2008-06-13 Thread Manolescu, Radu (IT) 
Is there a workaround at this time for Jira "CXF-1538"
(https://issues.apache.org/jira/browse/CXF-1538
 )?
We are hitting against this bug while trying to send signed SOAP
messages over HTTPS.
 
We understand that this is an open Jira, but we would like to understand
more about what is going on, so that we can find a workaround.
Why is this interceptor in the chain? What function does it provide?
Can we remove it from the chain? Can we replace it in the chain by our
own implementation?
If we were to implement a replacement, what should that replacement do?
Use an XMLStreamWriter?
 
Our interceptor chain is the following:
 
Chain [EMAIL PROTECTED] Current flow:
  pre-logical [HolderOutInterceptor, SwAOutInterceptor,
WrapperClassOutInterceptor, SoapHeaderOutFilterInterceptor]
  post-logical [SoapActionOutInterceptor]
  prepare-send [MessageSenderInterceptor]
  pre-stream [MSXMLStreamOutInterceptor, LoggingOutInterceptor,
SoapPreProtocolOutInterceptor, AttachmentOutInterceptor]
  pre-protocol [SAAJOutInterceptor, SOAPHandlerInterceptor]
  write [SoapOutInterceptor]
  pre-marshal [LogicalHandlerOutInterceptor]
  marshal [BareOutInterceptor]
  post-protocol [WSS4JOutInterceptor]
  write-ending [SoapOutEndingInterceptor]
  pre-protocol-ending [SAAJOutEndingInterceptor]
  prepare-send-ending [MessageFlushInterceptor,
MessageSenderEndingInterceptor]

The code which presents the problem (Jira CXF-1538):
 
SAAJOutInterceptor.java
public void handleMessage(SoapMessage message) throws Fault {
SOAPMessage soapMessage =
message.getContent(SOAPMessage.class);
 
if (soapMessage != null) { // IN OUR CASE, message!=null,
soapMessage!=null

OutputStream os =
message.getContent(OutputStream.class); // < IN OUR CASE, os == null
try {
setMessageContent(message, soapMessage);
soapMessage.writeTo(os); // < IN OUR CASE,
throws NullPointerException

The exception is:
[...]
Caused by: java.lang.NullPointerException
 at
com.sun.xml.messaging.saaj.soap.MessageImpl.writeTo(MessageImpl.java:122
1)
 at
org.apache.cxf.binding.soap.saaj.SAAJOutInterceptor$SAAJOutEndingInterce
ptor.handleMessage(SAAJOutInterceptor.java:116)
 at
org.apache.cxf.binding.soap.saaj.SAAJOutInterceptor$SAAJOutEndingInterce
ptor.handleMessage(SAAJOutInterceptor.java:103)

 
Thanks,
 
 
Radu Manolescu
Morgan Stanley | Technology
2000 Westchester Ave, 1st Floor | Purchase, NY  10577
Phone: +1 914 225-5871
Mobile: +1 203 648-6964
[EMAIL PROTECTED]


NOTICE: If received in error, please destroy and notify sender. Sender does not 
intend to waive confidentiality or privilege. Use of this email is prohibited 
when received in error.

View SOAP Messages

2008-06-12 Thread Manolescu, Radu (IT) 
We do not seem to be able to configure SOAP message logging for a CXF
client. What are we missing?
 
 
We have used http://cwiki.apache.org/CXF20DOC/debugging.html as a guide.
 
We have tried to put this in the client code, but nothing got printed:
PrintWriter pw = new PrintWriter(System.out);
Client client = ClientProxy.getClient(port);
client.getInInterceptors().add(new
LoggingInInterceptor(pw)); // Also tried "new LoggingInInterceptor()"
client.getOutInterceptors().add(new
LoggingOutInterceptor(pw));

We have tried to put this in the cxf.xml file, but nothing got printed:


 








We do not control the service, and our messages probably do not even get
sent.
We are getting an error that says that our messages are malformed, but
since they are automatically generated, we do not know what they look
like.
We would like to see the SOAP messages as they are generated, in order
to troubleshoot the problem.
 
For the record, the error message we get is the following:
 
Caused by: javax.xml.stream.XMLStreamException: ParseError at
[row,col]:[1,50]
Message: White spaces are required between publicId and systemId.
 at com.sun.xml.stream.XMLReaderImpl.next(XMLReaderImpl.java:563)
 at com.sun.xml.stream.XMLReaderImpl.nextTag(XMLReaderImpl.java:1177)
 at
msjava.msxml.stream.TextMSXMLStreamReader.nextTag(TextMSXMLStreamReader.
java:713)
 at
org.apache.cxf.binding.soap.interceptor.ReadHeadersInterceptor.handleMes
sage(ReadHeadersInterceptor.java:85)
 
 
Thanks,
 
Radu Manolescu
Morgan Stanley | Technology
2000 Westchester Ave, 1st Floor | Purchase, NY  10577
Phone: +1 914 225-5871
Mobile: +1 203 648-6964
[EMAIL PROTECTED]


NOTICE: If received in error, please destroy and notify sender. Sender does not 
intend to waive confidentiality or privilege. Use of this email is prohibited 
when received in error.

WSDLToJava Error : Non unique body parts! In a port, operations must have unique operation signaure

2008-06-10 Thread Manolescu, Radu (IT) 
We are receiving an error that we do not quite understand while trying
to generate a Java client from a multi-operation WSDL file.

The error message is:
[java] WSDLToJava Error : Non unique body parts! In a port, operations
must have unique operation signaure on the wire for successful dispatch.
In port {http://www.example.org/wsdl14/}wsdl14SOAP, Operations
"{http://www.example.org/wsdl14/}Operation35"; and
"{http://www.example.org/wsdl14/}Operation36"; have the same request body
block {http://www.example.org/wsdl14/}Operation35


The WSDL below is valid, and we can generate Java code from it using
"Apache CXF (incubator) 2.1-incubator-SNAPSHOT".
The WSDL contains two operations (Operation35,Operation36), which have
input and output messages in the signature.
As long as these input/output parameter messages are unique (by name),
everything is fine.
The "non unique body parts" error occurs if we try to say that both
operations use the same messages as input and output.
(See location marked "s/36/35/" below)
The same thing happens if we try to say that the two request messages
contain the same element (See location marked "s/73/71/" below).

Note that all the elements defined in this schema (Element71..Element74)
have identical structure, so we could use only one such element if it
were not for the requirement to have unique names.

Why does this error occur? In most programming languages, a method is
uniquely defined by its signature (name+parameters), so the parameters
can be the same as long as the method name is different.

Is this requirement for uniqueness contained in the WSDL (or SOAP)
specification, or was it introduced by the CXF implementation?
How can we get around this, i.e. how can we have one port with two
operations which take the same structures for input?
Operation1(Type1 input, Type2 output)
Operation2(Type1 input, Type2 output)



http://schemas.xmlsoap.org/wsdl/soap/";
xmlns:tns="http://www.example.org/wsdl13/";
xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/";
xmlns:xsd="http://www.w3.org/2001/XMLSchema"; name="wsdl13"
targetNamespace="http://www.example.org/wsdl13/";>
  
http://www.example.org/wsdl13/";>
  

  


  

  
  

  


  

  
  






  
  






  

  
  

  
  

  
  
 
  
  
 
  
  

  
  


 



  
  
http://schemas.xmlsoap.org/soap/http"/>

  http://www.example.org/wsdl13/Operation35"/>
  

  
  

  


  http://www.example.org/wsdl13/Operation36"/>
  

  
  

  

  
  

  http://www.example.org/"/>

  




[java] WSDLToJava Error : Non unique body parts! In a port, operations
must have unique operation signaure on the wire for successful dispatch.
In port {http://www.example.org/wsdl14/}wsdl14SOAP, Operations
"{http://www.example.org/wsdl14/}Operation35"; and
"{http://www.example.org/wsdl14/}Operation36"; have the same request body
block {http://www.example.org/wsdl14/}Operation35  

 
 
Radu Manolescu
Morgan Stanley | Technology
2000 Westchester Ave, 1st Floor | Purchase, NY  10577
Phone: +1 914 225-5871
Mobile: +1 203 648-6964
[EMAIL PROTECTED]


NOTICE: If received in error, please destroy and notify sender. Sender does not 
intend to waive confidentiality or privilege. Use of this email is prohibited 
when received in error.

RE: WSDLToJava Error | xmldsig-core-schema.xsd | Connection timed out

2008-06-05 Thread Manolescu, Radu (IT) 
This was due to a firewall issue. By adding proxy information to the
wsdl2java command line, I was able to move on to more challenging error
messages:

java -DproxySet=true -DproxyHost=myProxy.myCompany.com
-DproxyPort=myPort org.apache.cxf.tools.wsdlto.WSDLToJava -d ..
FileName.wsdl

Now I am battling "body part" errors such as:

In a port, operations must have unique operation signaure on the wire
for successful dispatch.
In port {http://www.myCo.com/wsdl/2007-06/abcd/efgh}HttpEndPoint,
Operations
"{http://www.myCo.com/wsdl/2007-06/abcd/efgh}Op1"; and
"{http://www.myCo.com/wsdl/2007-06/abcd/efgh}Op2";
have the same request body block
{http://www.myCo.com/schema/2007-06/abcd/ews/message}RequestMessage 

I assume that we need to contact the web service provider and ask them
to modify the WSDL to have unique signatures for each operation.

Thanks,


Radu Manolescu
Morgan Stanley | Technology
2000 Westchester Ave, 1st Floor | Purchase, NY  10577
Phone: +1 914 225-5871
Mobile: +1 203 648-6964
[EMAIL PROTECTED]

-Original Message-
From: Daniel Kulp [mailto:[EMAIL PROTECTED] 
Sent: Thursday, June 05, 2008 4:57 PM
To: users@cxf.apache.org
Cc: cxf-ea
Subject: Re: WSDLToJava Error | xmldsig-core-schema.xsd | Connection
timed out



If eclipse is having problems reading it, most likely we cannot  
either. I'm not exactly sure how you can get a connection timed  
out error with a file URL.   That seams a bit strange.   Maybe a  
permissions issue?   Is the file really readable?  (can you cat it?  
load it in notepad?)

Dan



On Jun 5, 2008, at 11:14 AM, Manolescu, Radu (IT) wrote:

> I am trying to generate client code from a WSDL file, and I am getting

> the error below.
> My WSDL references an XSD (authored by our counterpart) which 
> references the public file "oasis-200401-wss-wssecurity- 
> secext-1.0.xsd", which references the public file "xmldsig-core- 
> schema.xsd".
> I tried to use Eclipse to validate the WSDL and XSD files, and when 
> Eclipse complained that it could not read some XSD files, I downloaded

> them locally and changed the "schemaLocation" references accordingly.
>
> The last errors, which I cannot seem to be able to remove, are:
>   * "oasis-200401-wss-wssecurity-secext-1.0.xsd" does not pass
Eclipse 
> validation. Eclipse complains about being unable to read 
> "xmldsig-core-schema.xsd", whether that file is referenced locally or 
> from the Internet
>   * when using Ant to call wsdl2java to generate the client, I get
the 
> exception below. Which program is trying to connect, and where?
> Is Ant trying to download files from the Internet while parsing 
> "xmldsig-core-schema.xsd"?. If so, how can I make it connect? Define a

> proxy somewhere? Download the dependencies locally?
>
> wsdl2java:
>
> [java] WSDLToJava Error : java.lang.RuntimeException: Fail to create 
> wsdl definition from : file:/U:/NonVerConPrj/MyProj/src/ide-bin/etc/
> Nodal.wsdl
>
> [java] Caused by : WSDLException (at /wsdl:definitions/wsdl:types/
> xs:schema/xsd:schema/xsd:schema): faultCode=PARSER_ERROR: Problem 
> parsing 'file:/U:/NonVerConPrj/MyProj/src/ide-bin/etc/xmldsig-core-
> schema.xsd'.: java.net.ConnectException: Connection timed out: connect
>
>
> Public file references:
>
> http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-sec
> ext-1.0.xsd , saved locally as 
> oasis-200401-wss-wssecurity-secext-1.0.xsd
> (attached)
>
> http://www.w3.org/TR/xmldsig-core/xmldsig-core-schema.xsd, saved 
> locally as xmldsig-core-schema.xsd (attached)
>
> http://www.w3.org/2001/xml.xsd, saved locally as xml.xsd
>
>
> Thanks,
>
>
> Radu Manolescu
> Morgan Stanley | Technology
> 2000 Westchester Ave, 1st Floor | Purchase, NY  10577
> Phone: +1 914 225-5871
> Mobile: +1 203 648-6964
> [EMAIL PROTECTED]
>
> NOTICE: If received in error, please destroy and notify sender.  
> Sender does not intend to waive confidentiality or privilege. Use of 
> this email is prohibited when received in error.

---
Daniel Kulp
[EMAIL PROTECTED]
http://www.dankulp.com/blog


NOTICE: If received in error, please destroy and notify sender. Sender does not 
intend to waive confidentiality or privilege. Use of this email is prohibited 
when received in error.

WSDLToJava Error | xmldsig-core-schema.xsd | Connection timed out

2008-06-05 Thread Manolescu, Radu (IT) 
I am trying to generate client code from a WSDL file, and I am getting
the error below.
My WSDL references an XSD (authored by our counterpart) which references
the public file "oasis-200401-wss-wssecurity-secext-1.0.xsd", which
references the public file "xmldsig-core-schema.xsd".
I tried to use Eclipse to validate the WSDL and XSD files, and when
Eclipse complained that it could not read some XSD files, I downloaded
them locally and changed the "schemaLocation" references accordingly.
 
The last errors, which I cannot seem to be able to remove, are:

*   "oasis-200401-wss-wssecurity-secext-1.0.xsd" does not pass
Eclipse validation. Eclipse complains about being unable to read
"xmldsig-core-schema.xsd", whether that file is referenced locally or
from the Internet
*   when using Ant to call wsdl2java to generate the client, I get
the exception below. Which program is trying to connect, and where? Is
Ant trying to download files from the Internet while parsing
"xmldsig-core-schema.xsd"?. If so, how can I make it connect? Define a
proxy somewhere? Download the dependencies locally?

 
wsdl2java:

[java] WSDLToJava Error : java.lang.RuntimeException: Fail to create
wsdl definition from :
file:/U:/NonVerConPrj/MyProj/src/ide-bin/etc/Nodal.wsdl

[java] Caused by : WSDLException (at
/wsdl:definitions/wsdl:types/xs:schema/xsd:schema/xsd:schema):
faultCode=PARSER_ERROR: Problem parsing
'file:/U:/NonVerConPrj/MyProj/src/ide-bin/etc/xmldsig-core-schema.xsd'.:
java.net.ConnectException: Connection timed out: connect 

 

Public file references:

http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secex
t-1.0.xsd, saved locally as oasis-200401-wss-wssecurity-secext-1.0.xsd
  (attached)

http://www.w3.org/TR/xmldsig-core/xmldsig-core-schema.xsd, saved locally
as xmldsig-core-schema.xsd
  (attached)

http://www.w3.org/2001/xml.xsd, saved locally as xml.xsd
 

 

Thanks,

 
Radu Manolescu
Morgan Stanley | Technology
2000 Westchester Ave, 1st Floor | Purchase, NY  10577
Phone: +1 914 225-5871
Mobile: +1 203 648-6964
[EMAIL PROTECTED]


NOTICE: If received in error, please destroy and notify sender. Sender does not 
intend to waive confidentiality or privilege. Use of this email is prohibited 
when received in error.