Re: wsdl2js, namespace prefixes

[sparktronics]

you can include the following as part of the jaxws:endpoint node


  




http://gencat.net/scsp/esquemes/productes/gro/bo/resposta
pica1



  
 

And it will use the specified prefix

--
View this message in context: 
http://cxf.547215.n5.nabble.com/wsdl2js-namespace-prefixes-tp571839p5485631.html
Sent from the cxf-dev mailing list archive at Nabble.com.

Re: WSDL2JS

[Demetris]

Nothing like the good old 'giving it a shot' trick ;) My problem is 
indeed how to both run clients and servers
on mobile devices and under J2ME-CDC. And it is a pretty damn limited 
field to manage to fit in it
comprehensive stacks either from Axis or CXF. In any case, I will try to 
see if a rich CXF client can

call a ksoap-server WS and let the list know.

Thanks much

Oisin Hurley wrote:

How convoluted would it be for me at least to isolate tools like the wsdl2js
and their classes (WSDLToJavascript etc.)
and port it into J2ME-CDC or CLDC?



Pretty damn convoluted, and many months of labor, if I recall the CDC, CLDC
profile limitations correctly (file system issues, missing classes, potentially
weird XML parser issues, resource constraints, missing java annotations,
missing generics...)

If you use standard WS interactions, then YES, you SHOULD be able to
invoke services implemented using different technologies from a CXF
client, although it is seldom trivial if your WSDL is complex. So, in theory
you should be able to invoke a ksoap server from a CXF client. The best
way to find out more is to just give it a shot.

 --oh

  

Re: WSDL2JS

[Oisin Hurley]

> How convoluted would it be for me at least to isolate tools like the wsdl2js
> and their classes (WSDLToJavascript etc.)
> and port it into J2ME-CDC or CLDC?

Pretty damn convoluted, and many months of labor, if I recall the CDC, CLDC
profile limitations correctly (file system issues, missing classes, potentially
weird XML parser issues, resource constraints, missing java annotations,
missing generics...)

If you use standard WS interactions, then YES, you SHOULD be able to
invoke services implemented using different technologies from a CXF
client, although it is seldom trivial if your WSDL is complex. So, in theory
you should be able to invoke a ksoap server from a CXF client. The best
way to find out more is to just give it a shot.

 --oh

Re: WSDL2JS

[Demetris]

I guess no replies to the previous email below means I am on my own ...

At least one more Q:
How convoluted would it be for me at least to isolate tools like the 
wsdl2js and their classes (WSDLToJavascript etc.)
and port it into J2ME-CDC or CLDC? I guess primarily the tools 
cxf,common, cxf.tools.common and a few other
classes would be involved but other than that I can find a clean 
separation between them and the main baseline.

Any ideas?

Thanks again

Demetris wrote:


Hi Benson et. al.,

   I tried running the D-OSGi in Equinox under J2ME CDC on a Nokia 
N800 but it failed (I downloaded
and activated the single-bungle distro). So I have a feeling I will 
have the same luck running the CXF
stack on that mobile.  But I will give the WSDL2JS tool a shot as 
standalone and run it on a WSDL file
that I can generate off the mobile either on a CXF or Axis enabled 
servers on a hoping that would work.

Before I do I am wondering the following -
 I will have the client mobile generate the javascript code that I 
can execute via its browser to generate
SOAP calls to the remote server mobile running a ksoap2 web service. 
My questions are, has anyone tried
to invoke Axis or any other SOAP-server-engine services from a CXF 
client (let's say the client is executing
the javascript generated from the server's WSDL)? Or do the SOAP 
messages generated by CXF is annotated
in such a way that only its server-side can understand? All this of 
course provided the client stack can run on the

mobile- I am working on testing that now.

Thanks

Benson Margulies wrote:

Demetris,

Let me answer/clarify what I can.

There are two ways of getting Javascript:

1: ask the server to generate it via the ?js URL.
2: run the generator yourself, either via the command-line driver or
the API it calls.

Both of this works either code-first or contract first. That is, you
start from Java classes with @nnotations, you can directly generate
javascript. You don't have to make a wsdl at any point.

You could do #2 on the client. However, I am ignorant of the
constraints of J2ME or CLDC, so I can't tell you if you can fit the
necessary set of our code onto there.

--benson


On Wed, Aug 19, 2009 at 4:41 PM, Demetris wrote:
 

Hi Benson.

do you mind if I ask for some clarification?
   
1) you can ask the server to generate and deliver the javascript 
client.


  

The server will actually generate and send a javascript client to the
requesting remote class correct?
But if need be, can the server also generate a WSDL file - which I am
assuming can be used on
the client side with the WSDL2js to generate the javascript client?

   

2) you can create a 'dynamic client' that can talk to moderately
complex services.

However, option 2 requires the entire CXF stack on the client, and I
have no idea if J2ME has the necessary goodies.


  

But still there is a reduced set of CXF classes that can be run under
J2ME-CDC or CLDC? I am
looking for the appropriate server/container that I can run under 
J2ME and

which can host CXF
web services and I am not having much luck. I think my only option 
would be

to use OSGi (I think
Equinox and Knopflerfish can run under J2ME) in which case I will 
need a

bundle-fied version of
CXF - I am going over the Distributed OSGi pages on the CXF site 
hoping that

is what I am looking
for.

Thanks again







  

Re: WSDL2JS

[Demetris]

Hi Benson et. al.,

   I tried running the D-OSGi in Equinox under J2ME CDC on a Nokia N800 
but it failed (I downloaded
and activated the single-bungle distro). So I have a feeling I will have 
the same luck running the CXF
stack on that mobile.  But I will give the WSDL2JS tool a shot as 
standalone and run it on a WSDL file
that I can generate off the mobile either on a CXF or Axis enabled 
servers on a hoping that would work.

Before I do I am wondering the following -
 I will have the client mobile generate the javascript code that I 
can execute via its browser to generate
SOAP calls to the remote server mobile running a ksoap2 web service. My 
questions are, has anyone tried
to invoke Axis or any other SOAP-server-engine services from a CXF 
client (let's say the client is executing
the javascript generated from the server's WSDL)? Or do the SOAP 
messages generated by CXF is annotated
in such a way that only its server-side can understand? All this of 
course provided the client stack can run on the

mobile- I am working on testing that now.

Thanks

Benson Margulies wrote:

Demetris,

Let me answer/clarify what I can.

There are two ways of getting Javascript:

1: ask the server to generate it via the ?js URL.
2: run the generator yourself, either via the command-line driver or
the API it calls.

Both of this works either code-first or contract first. That is, you
start from Java classes with @nnotations, you can directly generate
javascript. You don't have to make a wsdl at any point.

You could do #2 on the client. However, I am ignorant of the
constraints of J2ME or CLDC, so I can't tell you if you can fit the
necessary set of our code onto there.

--benson


On Wed, Aug 19, 2009 at 4:41 PM, Demetris wrote:
  

Hi Benson.

do you mind if I ask for some clarification?


1) you can ask the server to generate and deliver the javascript client.

  

The server will actually generate and send a javascript client to the
requesting remote class correct?
But if need be, can the server also generate a WSDL file - which I am
assuming can be used on
the client side with the WSDL2js to generate the javascript client?



2) you can create a 'dynamic client' that can talk to moderately
complex services.

However, option 2 requires the entire CXF stack on the client, and I
have no idea if J2ME has the necessary goodies.


  

But still there is a reduced set of CXF classes that can be run under
J2ME-CDC or CLDC? I am
looking for the appropriate server/container that I can run under J2ME and
which can host CXF
web services and I am not having much luck. I think my only option would be
to use OSGi (I think
Equinox and Knopflerfish can run under J2ME) in which case I will need a
bundle-fied version of
CXF - I am going over the Distributed OSGi pages on the CXF site hoping that
is what I am looking
for.

Thanks again







  

Re: WSDL2JS

[Demetris]

Hi Benson,

1: ask the server to generate it via the ?js URL.
2: run the generator yourself, either via the command-line driver or
the API it calls.

Both of this works either code-first or contract first. That is, you
start from Java classes with @nnotations, you can directly generate
javascript. You don't have to make a wsdl at any point.
  

Ok.

You could do #2 on the client. However, I am ignorant of the
constraints of J2ME or CLDC, so I can't tell you if you can fit the
necessary set of our code onto there.
  
I  guess there is only one way to find out - I will give it a shot and 
let the list know.


I appreciate the response - thanks again


On Wed, Aug 19, 2009 at 4:41 PM, Demetris wrote:
  

Hi Benson.

do you mind if I ask for some clarification?


1) you can ask the server to generate and deliver the javascript client.

  

The server will actually generate and send a javascript client to the
requesting remote class correct?
But if need be, can the server also generate a WSDL file - which I am
assuming can be used on
the client side with the WSDL2js to generate the javascript client?



2) you can create a 'dynamic client' that can talk to moderately
complex services.

However, option 2 requires the entire CXF stack on the client, and I
have no idea if J2ME has the necessary goodies.


  

But still there is a reduced set of CXF classes that can be run under
J2ME-CDC or CLDC? I am
looking for the appropriate server/container that I can run under J2ME and
which can host CXF
web services and I am not having much luck. I think my only option would be
to use OSGi (I think
Equinox and Knopflerfish can run under J2ME) in which case I will need a
bundle-fied version of
CXF - I am going over the Distributed OSGi pages on the CXF site hoping that
is what I am looking
for.

Thanks again







  

Re: WSDL2JS

[Benson Margulies]

Demetris,

Let me answer/clarify what I can.

There are two ways of getting Javascript:

1: ask the server to generate it via the ?js URL.
2: run the generator yourself, either via the command-line driver or
the API it calls.

Both of this works either code-first or contract first. That is, you
start from Java classes with @nnotations, you can directly generate
javascript. You don't have to make a wsdl at any point.

You could do #2 on the client. However, I am ignorant of the
constraints of J2ME or CLDC, so I can't tell you if you can fit the
necessary set of our code onto there.

--benson


On Wed, Aug 19, 2009 at 4:41 PM, Demetris wrote:
>
> Hi Benson.
>
> do you mind if I ask for some clarification?
>>
>> 1) you can ask the server to generate and deliver the javascript client.
>>
>
> The server will actually generate and send a javascript client to the
> requesting remote class correct?
> But if need be, can the server also generate a WSDL file - which I am
> assuming can be used on
> the client side with the WSDL2js to generate the javascript client?
>
>> 2) you can create a 'dynamic client' that can talk to moderately
>> complex services.
>>
>> However, option 2 requires the entire CXF stack on the client, and I
>> have no idea if J2ME has the necessary goodies.
>>
>>
>
> But still there is a reduced set of CXF classes that can be run under
> J2ME-CDC or CLDC? I am
> looking for the appropriate server/container that I can run under J2ME and
> which can host CXF
> web services and I am not having much luck. I think my only option would be
> to use OSGi (I think
> Equinox and Knopflerfish can run under J2ME) in which case I will need a
> bundle-fied version of
> CXF - I am going over the Distributed OSGi pages on the CXF site hoping that
> is what I am looking
> for.
>
> Thanks again
>
>
>

Re: WSDL2JS

[Demetris]

Hi Benson.

do you mind if I ask for some clarification?

1) you can ask the server to generate and deliver the javascript client.
  
The server will actually generate and send a javascript client to the 
requesting remote class correct?
But if need be, can the server also generate a WSDL file - which I am 
assuming can be used on

the client side with the WSDL2js to generate the javascript client?


2) you can create a 'dynamic client' that can talk to moderately
complex services.

However, option 2 requires the entire CXF stack on the client, and I
have no idea if J2ME has the necessary goodies.

  
But still there is a reduced set of CXF classes that can be run under 
J2ME-CDC or CLDC? I am
looking for the appropriate server/container that I can run under J2ME 
and which can host CXF
web services and I am not having much luck. I think my only option would 
be to use OSGi (I think
Equinox and Knopflerfish can run under J2ME) in which case I will need a 
bundle-fied version of
CXF - I am going over the Distributed OSGi pages on the CXF site hoping 
that is what I am looking

for.

Thanks again

Re: WSDL2JS

[Demetris]

Super - thanks.

Benson Margulies wrote:

The answer to your questions is "yes".

On Mon, Aug 17, 2009 at 12:51 AM, Demetris wrote:
  

Hi Benson,

  I took a look into the rt folder and did go over the cxf-utils.js module -
so the generated
client javascript code makes use of this module to send its requests to the
service - correct?

I  know that looking through the code is the best way to learn a lot of this
but this code
is fairly large so I am not sure I will have the time to go through it
before I need to make the
decision to go with CXF - the only Q I have here is, before I invest the
time going over the
documentation, is there enough material there to help me figure out CXF? It
seems that the
web site if fairly well organized so that's encouraging.

Thanks

Benson Margulies wrote:


I would recommend wrapping/intercepting the object in cxf-utils.js
that sends the requests.

There's really no substitute for reading some of this code.

On Fri, Aug 14, 2009 at 12:07 PM, Demetris wrote:

  

So if I want to intercept the SOAP message that the client javascript
will
be sending out I will need
to dig into the http layers? Is there anything I can do at the app layer
to
intercept that message without
disrupting/modifying the javascript?

Benson Margulies wrote:



When the server provides the javascript, it provides the correct URL.
Which is often not port 8080.

 To answer another question, no z/OS is not required.

On Thu, Aug 13, 2009 at 4:57 PM, Demetris wrote:


  

One more question for whoever has a few minutes to help out -
Let's say my client contacted the remote server using a URL in order to
obtain the javascript client.
When this script is loaded and ran on the client side browser, I am
assuming
that by default it uses
HTTP to send out the SOAP message to the server right? Which port does
it
write to - similar to
Axis, 8080?

Demetris wrote:




Hey guys,

 the documentation says:
"It is relatively straightforward to run a CXF service in a Tomcat
 container on z/OS". But the IBM OS
is not a requirement correct? I can run this service on any Tomcat
container running on any OS right?
I know this is an elementary Q but I wanted to make sure there are not
OS-specific dependencies.

Thanks

Benson Margulies wrote:


  

CXF has two things going on here.

1) you can ask the server to generate and deliver the javascript
client.
2) you can create a 'dynamic client' that can talk to moderately
complex services.

However, option 2 requires the entire CXF stack on the client, and I
have no idea if J2ME has the necessary goodies.


On Wed, Aug 12, 2009 at 4:47 PM, Demetris
wrote:





Does CXF support client-side programming for Web Services? What we
are
after
in one of our projects
is to:
(1) host web services (or at least a Soap engine) on mobile devices
(primarily running J2ME CDC)
(2) build web service clients on mobile devices, either by
discovering
and
utilizing WSDLs (to generate
javascript stubs) or some other mechanism to allow them to generate
the
client code.

Not sure how realistic this is at this stage but I am not finding
much
on
(1) and a bit on (2). Many people
have said that generating WSDLs on mobile devices is a difficult
task
so
we
are considering the off-the-
device mechanisms.

Daniel Kulp wrote:



  

On Tue August 11 2009 11:26:05 pm Demetris wrote:






Do you know if Axis 1.x can generate document/literal or only
rpc/encoded? I am wondering if setting
the OPERATION_STYLE_PROPERTY to document would do the trick.




  

I believe Axis1 can do doc/literal.   JAX-RPC did require some
level
of
support for that so I'm pretty sure Axis1 implemented it.   Not
sure
how to
go about configuring it to do so.   I'm not an Axis1 user.  :-)

Dan









Benson Margulies wrote:




  

Demetris,

If your place has a big investment in RPC/encoded, perhaps one of
you
would like to pick up the project that one of our committers
started
of adding RPC/encoded support to CXF. If you do it, you get to
ensure
that it works with your services :-). I'd be happy to mentor
someone
in figuring out where Dain left off.

--benson

On Tue, Aug 11, 2009 at 4:21 PM, Demetris
wrote:






Of course I do see infrastructures here in production still
using
Axis
1.x without any plans on
migrating while other systems come into play with Axis 2 etc.
and
interoperability between the
two sides is impossible - and of course the rest of us will need
to
sit
in between and needing to
do our own translations - not good.
In any case, CFX is a pretty impressive project so I have a
feeling
I
will be adapting it to my
work.

Cheers

Daniel Kulp wrote:




  

On Tue August 11 2009 12:15:40 pm Demetris wrote:






That's what I figured ;) Thanks  for the info Benson.

Re: WSDL2JS

[Benson Margulies]

The answer to your questions is "yes".

On Mon, Aug 17, 2009 at 12:51 AM, Demetris wrote:
>
> Hi Benson,
>
>   I took a look into the rt folder and did go over the cxf-utils.js module -
> so the generated
> client javascript code makes use of this module to send its requests to the
> service - correct?
>
> I  know that looking through the code is the best way to learn a lot of this
> but this code
> is fairly large so I am not sure I will have the time to go through it
> before I need to make the
> decision to go with CXF - the only Q I have here is, before I invest the
> time going over the
> documentation, is there enough material there to help me figure out CXF? It
> seems that the
> web site if fairly well organized so that's encouraging.
>
> Thanks
>
> Benson Margulies wrote:
>>
>> I would recommend wrapping/intercepting the object in cxf-utils.js
>> that sends the requests.
>>
>> There's really no substitute for reading some of this code.
>>
>> On Fri, Aug 14, 2009 at 12:07 PM, Demetris wrote:
>>
>>>
>>> So if I want to intercept the SOAP message that the client javascript
>>> will
>>> be sending out I will need
>>> to dig into the http layers? Is there anything I can do at the app layer
>>> to
>>> intercept that message without
>>> disrupting/modifying the javascript?
>>>
>>> Benson Margulies wrote:
>>>

 When the server provides the javascript, it provides the correct URL.
 Which is often not port 8080.

  To answer another question, no z/OS is not required.

 On Thu, Aug 13, 2009 at 4:57 PM, Demetris wrote:


>
> One more question for whoever has a few minutes to help out -
> Let's say my client contacted the remote server using a URL in order to
> obtain the javascript client.
> When this script is loaded and ran on the client side browser, I am
> assuming
> that by default it uses
> HTTP to send out the SOAP message to the server right? Which port does
> it
> write to - similar to
> Axis, 8080?
>
> Demetris wrote:
>
>
>>
>> Hey guys,
>>
>>  the documentation says:
>> "It is relatively straightforward to run a CXF service in a Tomcat
>>  container on z/OS". But the IBM OS
>> is not a requirement correct? I can run this service on any Tomcat
>> container running on any OS right?
>> I know this is an elementary Q but I wanted to make sure there are not
>> OS-specific dependencies.
>>
>> Thanks
>>
>> Benson Margulies wrote:
>>
>>
>>>
>>> CXF has two things going on here.
>>>
>>> 1) you can ask the server to generate and deliver the javascript
>>> client.
>>> 2) you can create a 'dynamic client' that can talk to moderately
>>> complex services.
>>>
>>> However, option 2 requires the entire CXF stack on the client, and I
>>> have no idea if J2ME has the necessary goodies.
>>>
>>>
>>> On Wed, Aug 12, 2009 at 4:47 PM, Demetris
>>> wrote:
>>>
>>>
>>>

 Does CXF support client-side programming for Web Services? What we
 are
 after
 in one of our projects
 is to:
 (1) host web services (or at least a Soap engine) on mobile devices
 (primarily running J2ME CDC)
 (2) build web service clients on mobile devices, either by
 discovering
 and
 utilizing WSDLs (to generate
 javascript stubs) or some other mechanism to allow them to generate
 the
 client code.

 Not sure how realistic this is at this stage but I am not finding
 much
 on
 (1) and a bit on (2). Many people
 have said that generating WSDLs on mobile devices is a difficult
 task
 so
 we
 are considering the off-the-
 device mechanisms.

 Daniel Kulp wrote:



>
> On Tue August 11 2009 11:26:05 pm Demetris wrote:
>
>
>
>
>>
>> Do you know if Axis 1.x can generate document/literal or only
>> rpc/encoded? I am wondering if setting
>> the OPERATION_STYLE_PROPERTY to document would do the trick.
>>
>>
>>
>>
>
> I believe Axis1 can do doc/literal.   JAX-RPC did require some
> level
> of
> support for that so I'm pretty sure Axis1 implemented it.   Not
> sure
> how to
> go about configuring it to do so.   I'm not an Axis1 user.  :-)
>
> Dan
>
>
>
>
>
>
>
>>
>> Benson Margulies wrote:
>>
>>
>>
>>
>>>
>>> Demetris,
>>>
>>> If your place has a big investment in RPC/encoded, perhaps one of
>>> you
>>> would like to pick up the proj

Re: WSDL2JS

[Demetris]

Hi Benson,

   I took a look into the rt folder and did go over the cxf-utils.js 
module - so the generated
client javascript code makes use of this module to send its requests to 
the service - correct?


I  know that looking through the code is the best way to learn a lot of 
this but this code
is fairly large so I am not sure I will have the time to go through it 
before I need to make the
decision to go with CXF - the only Q I have here is, before I invest the 
time going over the
documentation, is there enough material there to help me figure out CXF? 
It seems that the

web site if fairly well organized so that's encouraging.

Thanks

Benson Margulies wrote:

I would recommend wrapping/intercepting the object in cxf-utils.js
that sends the requests.

There's really no substitute for reading some of this code.

On Fri, Aug 14, 2009 at 12:07 PM, Demetris wrote:
  

So if I want to intercept the SOAP message that the client javascript will
be sending out I will need
to dig into the http layers? Is there anything I can do at the app layer to
intercept that message without
disrupting/modifying the javascript?

Benson Margulies wrote:


When the server provides the javascript, it provides the correct URL.
Which is often not port 8080.

 To answer another question, no z/OS is not required.

On Thu, Aug 13, 2009 at 4:57 PM, Demetris wrote:

  

One more question for whoever has a few minutes to help out -
Let's say my client contacted the remote server using a URL in order to
obtain the javascript client.
When this script is loaded and ran on the client side browser, I am
assuming
that by default it uses
HTTP to send out the SOAP message to the server right? Which port does it
write to - similar to
Axis, 8080?

Demetris wrote:



Hey guys,

 the documentation says:
"It is relatively straightforward to run a CXF service in a Tomcat
 container on z/OS". But the IBM OS
is not a requirement correct? I can run this service on any Tomcat
container running on any OS right?
I know this is an elementary Q but I wanted to make sure there are not
OS-specific dependencies.

Thanks

Benson Margulies wrote:

  

CXF has two things going on here.

1) you can ask the server to generate and deliver the javascript
client.
2) you can create a 'dynamic client' that can talk to moderately
complex services.

However, option 2 requires the entire CXF stack on the client, and I
have no idea if J2ME has the necessary goodies.


On Wed, Aug 12, 2009 at 4:47 PM, Demetris wrote:




Does CXF support client-side programming for Web Services? What we are
after
in one of our projects
is to:
(1) host web services (or at least a Soap engine) on mobile devices
(primarily running J2ME CDC)
(2) build web service clients on mobile devices, either by discovering
and
utilizing WSDLs (to generate
javascript stubs) or some other mechanism to allow them to generate
the
client code.

Not sure how realistic this is at this stage but I am not finding much
on
(1) and a bit on (2). Many people
have said that generating WSDLs on mobile devices is a difficult task
so
we
are considering the off-the-
device mechanisms.

Daniel Kulp wrote:


  

On Tue August 11 2009 11:26:05 pm Demetris wrote:





Do you know if Axis 1.x can generate document/literal or only
rpc/encoded? I am wondering if setting
the OPERATION_STYLE_PROPERTY to document would do the trick.



  

I believe Axis1 can do doc/literal.   JAX-RPC did require some level
of
support for that so I'm pretty sure Axis1 implemented it.   Not sure
how to
go about configuring it to do so.   I'm not an Axis1 user.  :-)

Dan








Benson Margulies wrote:



  

Demetris,

If your place has a big investment in RPC/encoded, perhaps one of
you
would like to pick up the project that one of our committers
started
of adding RPC/encoded support to CXF. If you do it, you get to
ensure
that it works with your services :-). I'd be happy to mentor
someone
in figuring out where Dain left off.

--benson

On Tue, Aug 11, 2009 at 4:21 PM, Demetris
wrote:





Of course I do see infrastructures here in production still using
Axis
1.x without any plans on
migrating while other systems come into play with Axis 2 etc. and
interoperability between the
two sides is impossible - and of course the rest of us will need
to
sit
in between and needing to
do our own translations - not good.
In any case, CFX is a pretty impressive project so I have a
feeling
I
will be adapting it to my
work.

Cheers

Daniel Kulp wrote:



  

On Tue August 11 2009 12:15:40 pm Demetris wrote:





That's what I figured ;) Thanks  for the info Benson.

Now regarding inteconnection of Web Services across
implementations,
if there is no bridge
between the old RPC/encoded and CFX, at least I am assuming that
newer
versions would
be able to handle SOAP c

Re: WSDL2JS

[Demetris]

You are absolutely right and I am already on it :) Thanks Benson

Benson Margulies wrote:

I would recommend wrapping/intercepting the object in cxf-utils.js
that sends the requests.

There's really no substitute for reading some of this code.

On Fri, Aug 14, 2009 at 12:07 PM, Demetris wrote:
  

So if I want to intercept the SOAP message that the client javascript will
be sending out I will need
to dig into the http layers? Is there anything I can do at the app layer to
intercept that message without
disrupting/modifying the javascript?

Benson Margulies wrote:


When the server provides the javascript, it provides the correct URL.
Which is often not port 8080.

 To answer another question, no z/OS is not required.

On Thu, Aug 13, 2009 at 4:57 PM, Demetris wrote:

  

One more question for whoever has a few minutes to help out -
Let's say my client contacted the remote server using a URL in order to
obtain the javascript client.
When this script is loaded and ran on the client side browser, I am
assuming
that by default it uses
HTTP to send out the SOAP message to the server right? Which port does it
write to - similar to
Axis, 8080?

Demetris wrote:



Hey guys,

 the documentation says:
"It is relatively straightforward to run a CXF service in a Tomcat
 container on z/OS". But the IBM OS
is not a requirement correct? I can run this service on any Tomcat
container running on any OS right?
I know this is an elementary Q but I wanted to make sure there are not
OS-specific dependencies.

Thanks

Benson Margulies wrote:

  

CXF has two things going on here.

1) you can ask the server to generate and deliver the javascript
client.
2) you can create a 'dynamic client' that can talk to moderately
complex services.

However, option 2 requires the entire CXF stack on the client, and I
have no idea if J2ME has the necessary goodies.


On Wed, Aug 12, 2009 at 4:47 PM, Demetris wrote:




Does CXF support client-side programming for Web Services? What we are
after
in one of our projects
is to:
(1) host web services (or at least a Soap engine) on mobile devices
(primarily running J2ME CDC)
(2) build web service clients on mobile devices, either by discovering
and
utilizing WSDLs (to generate
javascript stubs) or some other mechanism to allow them to generate
the
client code.

Not sure how realistic this is at this stage but I am not finding much
on
(1) and a bit on (2). Many people
have said that generating WSDLs on mobile devices is a difficult task
so
we
are considering the off-the-
device mechanisms.

Daniel Kulp wrote:


  

On Tue August 11 2009 11:26:05 pm Demetris wrote:





Do you know if Axis 1.x can generate document/literal or only
rpc/encoded? I am wondering if setting
the OPERATION_STYLE_PROPERTY to document would do the trick.



  

I believe Axis1 can do doc/literal.   JAX-RPC did require some level
of
support for that so I'm pretty sure Axis1 implemented it.   Not sure
how to
go about configuring it to do so.   I'm not an Axis1 user.  :-)

Dan








Benson Margulies wrote:



  

Demetris,

If your place has a big investment in RPC/encoded, perhaps one of
you
would like to pick up the project that one of our committers
started
of adding RPC/encoded support to CXF. If you do it, you get to
ensure
that it works with your services :-). I'd be happy to mentor
someone
in figuring out where Dain left off.

--benson

On Tue, Aug 11, 2009 at 4:21 PM, Demetris
wrote:





Of course I do see infrastructures here in production still using
Axis
1.x without any plans on
migrating while other systems come into play with Axis 2 etc. and
interoperability between the
two sides is impossible - and of course the rest of us will need
to
sit
in between and needing to
do our own translations - not good.
In any case, CFX is a pretty impressive project so I have a
feeling
I
will be adapting it to my
work.

Cheers

Daniel Kulp wrote:



  

On Tue August 11 2009 12:15:40 pm Demetris wrote:





That's what I figured ;) Thanks  for the info Benson.

Now regarding inteconnection of Web Services across
implementations,
if there is no bridge
between the old RPC/encoded and CFX, at least I am assuming that
newer
versions would
be able to handle SOAP calls across them or not? This is
something
I
never tried/looked into
while I worked exclusively with Axis so I was wondering.



  

Pretty much none of the modern SOAP toolkits support RPC/encoded.
 Axis2 doesn't.  CXF doesn't.  Metro/JAX-WS RI doesn't.  Etc
Basically, rpc/encoded was such an interopability nightmare that
it
really fell into the bucket of "You REALLY REALLY don't want to
use
it."If you want interopability, you really need to migrate to
one
of the literal forms.

Dan






Benson Margulies wrote:



 

Re: WSDL2JS

[Benson Margulies]

I would recommend wrapping/intercepting the object in cxf-utils.js
that sends the requests.

There's really no substitute for reading some of this code.

On Fri, Aug 14, 2009 at 12:07 PM, Demetris wrote:
>
> So if I want to intercept the SOAP message that the client javascript will
> be sending out I will need
> to dig into the http layers? Is there anything I can do at the app layer to
> intercept that message without
> disrupting/modifying the javascript?
>
> Benson Margulies wrote:
>>
>> When the server provides the javascript, it provides the correct URL.
>> Which is often not port 8080.
>>
>>  To answer another question, no z/OS is not required.
>>
>> On Thu, Aug 13, 2009 at 4:57 PM, Demetris wrote:
>>
>>>
>>> One more question for whoever has a few minutes to help out -
>>> Let's say my client contacted the remote server using a URL in order to
>>> obtain the javascript client.
>>> When this script is loaded and ran on the client side browser, I am
>>> assuming
>>> that by default it uses
>>> HTTP to send out the SOAP message to the server right? Which port does it
>>> write to - similar to
>>> Axis, 8080?
>>>
>>> Demetris wrote:
>>>

 Hey guys,

  the documentation says:
 "It is relatively straightforward to run a CXF service in a Tomcat
  container on z/OS". But the IBM OS
 is not a requirement correct? I can run this service on any Tomcat
 container running on any OS right?
 I know this is an elementary Q but I wanted to make sure there are not
 OS-specific dependencies.

 Thanks

 Benson Margulies wrote:

>
> CXF has two things going on here.
>
> 1) you can ask the server to generate and deliver the javascript
> client.
> 2) you can create a 'dynamic client' that can talk to moderately
> complex services.
>
> However, option 2 requires the entire CXF stack on the client, and I
> have no idea if J2ME has the necessary goodies.
>
>
> On Wed, Aug 12, 2009 at 4:47 PM, Demetris wrote:
>
>
>>
>> Does CXF support client-side programming for Web Services? What we are
>> after
>> in one of our projects
>> is to:
>> (1) host web services (or at least a Soap engine) on mobile devices
>> (primarily running J2ME CDC)
>> (2) build web service clients on mobile devices, either by discovering
>> and
>> utilizing WSDLs (to generate
>> javascript stubs) or some other mechanism to allow them to generate
>> the
>> client code.
>>
>> Not sure how realistic this is at this stage but I am not finding much
>> on
>> (1) and a bit on (2). Many people
>> have said that generating WSDLs on mobile devices is a difficult task
>> so
>> we
>> are considering the off-the-
>> device mechanisms.
>>
>> Daniel Kulp wrote:
>>
>>
>>>
>>> On Tue August 11 2009 11:26:05 pm Demetris wrote:
>>>
>>>
>>>

 Do you know if Axis 1.x can generate document/literal or only
 rpc/encoded? I am wondering if setting
 the OPERATION_STYLE_PROPERTY to document would do the trick.



>>>
>>> I believe Axis1 can do doc/literal.   JAX-RPC did require some level
>>> of
>>> support for that so I'm pretty sure Axis1 implemented it.   Not sure
>>> how to
>>> go about configuring it to do so.   I'm not an Axis1 user.  :-)
>>>
>>> Dan
>>>
>>>
>>>
>>>
>>>
>>>

 Benson Margulies wrote:



>
> Demetris,
>
> If your place has a big investment in RPC/encoded, perhaps one of
> you
> would like to pick up the project that one of our committers
> started
> of adding RPC/encoded support to CXF. If you do it, you get to
> ensure
> that it works with your services :-). I'd be happy to mentor
> someone
> in figuring out where Dain left off.
>
> --benson
>
> On Tue, Aug 11, 2009 at 4:21 PM, Demetris
> wrote:
>
>
>
>>
>> Of course I do see infrastructures here in production still using
>> Axis
>> 1.x without any plans on
>> migrating while other systems come into play with Axis 2 etc. and
>> interoperability between the
>> two sides is impossible - and of course the rest of us will need
>> to
>> sit
>> in between and needing to
>> do our own translations - not good.
>> In any case, CFX is a pretty impressive project so I have a
>> feeling
>> I
>> will be adapting it to my
>> work.
>>
>> Cheers
>>
>> Daniel Kulp wrote:
>>
>>
>>
>>>
>>> On Tue August 11 2009 12:15:40 pm Demetris wrote:
>>>
>>>

Re: WSDL2JS

[Demetris]

So if I want to intercept the SOAP message that the client javascript 
will be sending out I will need
to dig into the http layers? Is there anything I can do at the app layer 
to intercept that message without

disrupting/modifying the javascript?

Benson Margulies wrote:

When the server provides the javascript, it provides the correct URL.
Which is often not port 8080.

 To answer another question, no z/OS is not required.

On Thu, Aug 13, 2009 at 4:57 PM, Demetris wrote:
  

One more question for whoever has a few minutes to help out -
Let's say my client contacted the remote server using a URL in order to
obtain the javascript client.
When this script is loaded and ran on the client side browser, I am assuming
that by default it uses
HTTP to send out the SOAP message to the server right? Which port does it
write to - similar to
Axis, 8080?

Demetris wrote:


Hey guys,

  the documentation says:
"It is relatively straightforward to run a CXF service in a Tomcat
 container on z/OS". But the IBM OS
is not a requirement correct? I can run this service on any Tomcat
container running on any OS right?
I know this is an elementary Q but I wanted to make sure there are not
OS-specific dependencies.

Thanks

Benson Margulies wrote:
  

CXF has two things going on here.

1) you can ask the server to generate and deliver the javascript client.
2) you can create a 'dynamic client' that can talk to moderately
complex services.

However, option 2 requires the entire CXF stack on the client, and I
have no idea if J2ME has the necessary goodies.


On Wed, Aug 12, 2009 at 4:47 PM, Demetris wrote:



Does CXF support client-side programming for Web Services? What we are
after
in one of our projects
is to:
(1) host web services (or at least a Soap engine) on mobile devices
(primarily running J2ME CDC)
(2) build web service clients on mobile devices, either by discovering
and
utilizing WSDLs (to generate
javascript stubs) or some other mechanism to allow them to generate the
client code.

Not sure how realistic this is at this stage but I am not finding much
on
(1) and a bit on (2). Many people
have said that generating WSDLs on mobile devices is a difficult task so
we
are considering the off-the-
device mechanisms.

Daniel Kulp wrote:

  

On Tue August 11 2009 11:26:05 pm Demetris wrote:




Do you know if Axis 1.x can generate document/literal or only
rpc/encoded? I am wondering if setting
the OPERATION_STYLE_PROPERTY to document would do the trick.


  

I believe Axis1 can do doc/literal.   JAX-RPC did require some level of
support for that so I'm pretty sure Axis1 implemented it.   Not sure
how to
go about configuring it to do so.   I'm not an Axis1 user.  :-)

Dan







Benson Margulies wrote:


  

Demetris,

If your place has a big investment in RPC/encoded, perhaps one of you
would like to pick up the project that one of our committers started
of adding RPC/encoded support to CXF. If you do it, you get to ensure
that it works with your services :-). I'd be happy to mentor someone
in figuring out where Dain left off.

--benson

On Tue, Aug 11, 2009 at 4:21 PM, Demetris
wrote:




Of course I do see infrastructures here in production still using
Axis
1.x without any plans on
migrating while other systems come into play with Axis 2 etc. and
interoperability between the
two sides is impossible - and of course the rest of us will need to
sit
in between and needing to
do our own translations - not good.
In any case, CFX is a pretty impressive project so I have a feeling
I
will be adapting it to my
work.

Cheers

Daniel Kulp wrote:


  

On Tue August 11 2009 12:15:40 pm Demetris wrote:




That's what I figured ;) Thanks  for the info Benson.

Now regarding inteconnection of Web Services across
implementations,
if there is no bridge
between the old RPC/encoded and CFX, at least I am assuming that
newer
versions would
be able to handle SOAP calls across them or not? This is something
I
never tried/looked into
while I worked exclusively with Axis so I was wondering.


  

Pretty much none of the modern SOAP toolkits support RPC/encoded.
 Axis2 doesn't.  CXF doesn't.  Metro/JAX-WS RI doesn't.  Etc
Basically, rpc/encoded was such an interopability nightmare that it
really fell into the bucket of "You REALLY REALLY don't want to use
it."If you want interopability, you really need to migrate to
one
of the literal forms.

Dan





Benson Margulies wrote:


  

OK, that message is buried in the substrate somewhere. I'm not
sure
that I agree with it :-) In practical terms, we just don't have
the
code or RPC/encoded.

I'm unaware of anything you can use to interconnect an old Axis
RPC/encoded service with CXF.

On Mon, Aug 10, 2009 at 11:00 PM, Demetris




wrote:




Hi Be

Re: WSDL2JS

[Benson Margulies]

When the server provides the javascript, it provides the correct URL.
Which is often not port 8080.

 To answer another question, no z/OS is not required.

On Thu, Aug 13, 2009 at 4:57 PM, Demetris wrote:
>
> One more question for whoever has a few minutes to help out -
> Let's say my client contacted the remote server using a URL in order to
> obtain the javascript client.
> When this script is loaded and ran on the client side browser, I am assuming
> that by default it uses
> HTTP to send out the SOAP message to the server right? Which port does it
> write to - similar to
> Axis, 8080?
>
> Demetris wrote:
>>
>> Hey guys,
>>
>>   the documentation says:
>> "It is relatively straightforward to run a CXF service in a Tomcat
>>  container on z/OS". But the IBM OS
>> is not a requirement correct? I can run this service on any Tomcat
>> container running on any OS right?
>> I know this is an elementary Q but I wanted to make sure there are not
>> OS-specific dependencies.
>>
>> Thanks
>>
>> Benson Margulies wrote:
>>>
>>> CXF has two things going on here.
>>>
>>> 1) you can ask the server to generate and deliver the javascript client.
>>> 2) you can create a 'dynamic client' that can talk to moderately
>>> complex services.
>>>
>>> However, option 2 requires the entire CXF stack on the client, and I
>>> have no idea if J2ME has the necessary goodies.
>>>
>>>
>>> On Wed, Aug 12, 2009 at 4:47 PM, Demetris wrote:
>>>

 Does CXF support client-side programming for Web Services? What we are
 after
 in one of our projects
 is to:
 (1) host web services (or at least a Soap engine) on mobile devices
 (primarily running J2ME CDC)
 (2) build web service clients on mobile devices, either by discovering
 and
 utilizing WSDLs (to generate
 javascript stubs) or some other mechanism to allow them to generate the
 client code.

 Not sure how realistic this is at this stage but I am not finding much
 on
 (1) and a bit on (2). Many people
 have said that generating WSDLs on mobile devices is a difficult task so
 we
 are considering the off-the-
 device mechanisms.

 Daniel Kulp wrote:

>
> On Tue August 11 2009 11:26:05 pm Demetris wrote:
>
>
>>
>> Do you know if Axis 1.x can generate document/literal or only
>> rpc/encoded? I am wondering if setting
>> the OPERATION_STYLE_PROPERTY to document would do the trick.
>>
>>
>
> I believe Axis1 can do doc/literal.   JAX-RPC did require some level of
> support for that so I'm pretty sure Axis1 implemented it.   Not sure
> how to
> go about configuring it to do so.   I'm not an Axis1 user.  :-)
>
> Dan
>
>
>
>
>
>>
>> Benson Margulies wrote:
>>
>>
>>>
>>> Demetris,
>>>
>>> If your place has a big investment in RPC/encoded, perhaps one of you
>>> would like to pick up the project that one of our committers started
>>> of adding RPC/encoded support to CXF. If you do it, you get to ensure
>>> that it works with your services :-). I'd be happy to mentor someone
>>> in figuring out where Dain left off.
>>>
>>> --benson
>>>
>>> On Tue, Aug 11, 2009 at 4:21 PM, Demetris
>>> wrote:
>>>
>>>

 Of course I do see infrastructures here in production still using
 Axis
 1.x without any plans on
 migrating while other systems come into play with Axis 2 etc. and
 interoperability between the
 two sides is impossible - and of course the rest of us will need to
 sit
 in between and needing to
 do our own translations - not good.
 In any case, CFX is a pretty impressive project so I have a feeling
 I
 will be adapting it to my
 work.

 Cheers

 Daniel Kulp wrote:


>
> On Tue August 11 2009 12:15:40 pm Demetris wrote:
>
>
>>
>> That's what I figured ;) Thanks  for the info Benson.
>>
>> Now regarding inteconnection of Web Services across
>> implementations,
>> if there is no bridge
>> between the old RPC/encoded and CFX, at least I am assuming that
>> newer
>> versions would
>> be able to handle SOAP calls across them or not? This is something
>> I
>> never tried/looked into
>> while I worked exclusively with Axis so I was wondering.
>>
>>
>
> Pretty much none of the modern SOAP toolkits support RPC/encoded.
>  Axis2 doesn't.  CXF doesn't.  Metro/JAX-WS RI doesn't.  Etc
> Basically, rpc/encoded was such an interopability nightmare that it
> really fell into the bucket of "You REALLY REALLY don't want to use
> it."    If you want interopability, you really need to migrat

Re: WSDL2JS

[Demetris]

One more question for whoever has a few minutes to help out -
Let's say my client contacted the remote server using a URL in order to 
obtain the javascript client.
When this script is loaded and ran on the client side browser, I am 
assuming that by default it uses
HTTP to send out the SOAP message to the server right? Which port does 
it write to - similar to

Axis, 8080?

Demetris wrote:


Hey guys,

   the documentation says:
"It is relatively straightforward to run a CXF service in a Tomcat 
 container on z/OS". But the IBM OS
is not a requirement correct? I can run this service on any Tomcat 
container running on any OS right?
I know this is an elementary Q but I wanted to make sure there are not 
OS-specific dependencies.


Thanks

Benson Margulies wrote:

CXF has two things going on here.

1) you can ask the server to generate and deliver the javascript client.
2) you can create a 'dynamic client' that can talk to moderately
complex services.

However, option 2 requires the entire CXF stack on the client, and I
have no idea if J2ME has the necessary goodies.


On Wed, Aug 12, 2009 at 4:47 PM, Demetris wrote:
 
Does CXF support client-side programming for Web Services? What we 
are after

in one of our projects
is to:
(1) host web services (or at least a Soap engine) on mobile devices
(primarily running J2ME CDC)
(2) build web service clients on mobile devices, either by 
discovering and

utilizing WSDLs (to generate
javascript stubs) or some other mechanism to allow them to generate the
client code.

Not sure how realistic this is at this stage but I am not finding 
much on

(1) and a bit on (2). Many people
have said that generating WSDLs on mobile devices is a difficult 
task so we

are considering the off-the-
device mechanisms.

Daniel Kulp wrote:
   

On Tue August 11 2009 11:26:05 pm Demetris wrote:

 

Do you know if Axis 1.x can generate document/literal or only
rpc/encoded? I am wondering if setting
the OPERATION_STYLE_PROPERTY to document would do the trick.


I believe Axis1 can do doc/literal.   JAX-RPC did require some 
level of
support for that so I'm pretty sure Axis1 implemented it.   Not 
sure how to

go about configuring it to do so.   I'm not an Axis1 user.  :-)

Dan




 

Benson Margulies wrote:

   

Demetris,

If your place has a big investment in RPC/encoded, perhaps one of 
you

would like to pick up the project that one of our committers started
of adding RPC/encoded support to CXF. If you do it, you get to 
ensure

that it works with your services :-). I'd be happy to mentor someone
in figuring out where Dain left off.

--benson

On Tue, Aug 11, 2009 at 4:21 PM, Demetris 
wrote:


 
Of course I do see infrastructures here in production still 
using Axis

1.x without any plans on
migrating while other systems come into play with Axis 2 etc. and
interoperability between the
two sides is impossible - and of course the rest of us will need 
to sit

in between and needing to
do our own translations - not good.
In any case, CFX is a pretty impressive project so I have a 
feeling I

will be adapting it to my
work.

Cheers

Daniel Kulp wrote:

   

On Tue August 11 2009 12:15:40 pm Demetris wrote:

 

That's what I figured ;) Thanks  for the info Benson.

Now regarding inteconnection of Web Services across 
implementations,

if there is no bridge
between the old RPC/encoded and CFX, at least I am assuming that
newer
versions would
be able to handle SOAP calls across them or not? This is 
something I

never tried/looked into
while I worked exclusively with Axis so I was wondering.



Pretty much none of the modern SOAP toolkits support RPC/encoded.
 Axis2 doesn't.  CXF doesn't.  Metro/JAX-WS RI doesn't.  Etc
Basically, rpc/encoded was such an interopability nightmare 
that it
really fell into the bucket of "You REALLY REALLY don't want to 
use
it."If you want interopability, you really need to migrate 
to one

of the literal forms.

Dan


 

Benson Margulies wrote:

   
OK, that message is buried in the substrate somewhere. I'm 
not sure
that I agree with it :-) In practical terms, we just don't 
have the

code or RPC/encoded.

I'm unaware of anything you can use to interconnect an old Axis
RPC/encoded service with CXF.

On Mon, Aug 10, 2009 at 11:00 PM, Demetris

  

wrote:

 

Hi Benson,

the reason I mentioned JAX-WS is because a WSDL file that I 
passed

to WSDL2JS returned
"RCP/encoded WSDLs are not supported in JAX-2.0". I had a 
feeling

it
is "neither here nor
there" but I wanted to double-check - I think I know what 
the issue

is now after reading the
corresponding documentation but I will return and send more 
info if

I cannot resolve it.

A separate question - is there a "bridge" between Axis WS 
and its

tools and CFX? Can an Axis
WS client call a CFX-implemented WS and vice versa or not?

Thanks

Benson Margulies wrote:

  

Re: WSDL2JS

[Demetris]

Hey guys,

   the documentation says:
"It is relatively straightforward to run a CXF service in a Tomcat 
 container on z/OS". But the IBM OS
is not a requirement correct? I can run this service on any Tomcat 
container running on any OS right?
I know this is an elementary Q but I wanted to make sure there are not 
OS-specific dependencies.


Thanks

Benson Margulies wrote:

CXF has two things going on here.

1) you can ask the server to generate and deliver the javascript client.
2) you can create a 'dynamic client' that can talk to moderately
complex services.

However, option 2 requires the entire CXF stack on the client, and I
have no idea if J2ME has the necessary goodies.


On Wed, Aug 12, 2009 at 4:47 PM, Demetris wrote:
  

Does CXF support client-side programming for Web Services? What we are after
in one of our projects
is to:
(1) host web services (or at least a Soap engine) on mobile devices
(primarily running J2ME CDC)
(2) build web service clients on mobile devices, either by discovering and
utilizing WSDLs (to generate
javascript stubs) or some other mechanism to allow them to generate the
client code.

Not sure how realistic this is at this stage but I am not finding much on
(1) and a bit on (2). Many people
have said that generating WSDLs on mobile devices is a difficult task so we
are considering the off-the-
device mechanisms.

Daniel Kulp wrote:


On Tue August 11 2009 11:26:05 pm Demetris wrote:

  

Do you know if Axis 1.x can generate document/literal or only
rpc/encoded? I am wondering if setting
the OPERATION_STYLE_PROPERTY to document would do the trick.



I believe Axis1 can do doc/literal.   JAX-RPC did require some level of
support for that so I'm pretty sure Axis1 implemented it.   Not sure how to
go about configuring it to do so.   I'm not an Axis1 user.  :-)

Dan




  

Benson Margulies wrote:



Demetris,

If your place has a big investment in RPC/encoded, perhaps one of you
would like to pick up the project that one of our committers started
of adding RPC/encoded support to CXF. If you do it, you get to ensure
that it works with your services :-). I'd be happy to mentor someone
in figuring out where Dain left off.

--benson

On Tue, Aug 11, 2009 at 4:21 PM, Demetris wrote:

  

Of course I do see infrastructures here in production still using Axis
1.x without any plans on
migrating while other systems come into play with Axis 2 etc. and
interoperability between the
two sides is impossible - and of course the rest of us will need to sit
in between and needing to
do our own translations - not good.
In any case, CFX is a pretty impressive project so I have a feeling I
will be adapting it to my
work.

Cheers

Daniel Kulp wrote:



On Tue August 11 2009 12:15:40 pm Demetris wrote:

  

That's what I figured ;) Thanks  for the info Benson.

Now regarding inteconnection of Web Services across implementations,
if there is no bridge
between the old RPC/encoded and CFX, at least I am assuming that
newer
versions would
be able to handle SOAP calls across them or not? This is something I
never tried/looked into
while I worked exclusively with Axis so I was wondering.



Pretty much none of the modern SOAP toolkits support RPC/encoded.
 Axis2 doesn't.  CXF doesn't.  Metro/JAX-WS RI doesn't.  Etc
Basically, rpc/encoded was such an interopability nightmare that it
really fell into the bucket of "You REALLY REALLY don't want to use
it."If you want interopability, you really need to migrate to one
of the literal forms.

Dan


  

Benson Margulies wrote:



OK, that message is buried in the substrate somewhere. I'm not sure
that I agree with it :-) In practical terms, we just don't have the
code or RPC/encoded.

I'm unaware of anything you can use to interconnect an old Axis
RPC/encoded service with CXF.

On Mon, Aug 10, 2009 at 11:00 PM, Demetris

  

wrote:

  

Hi Benson,

the reason I mentioned JAX-WS is because a WSDL file that I passed
to WSDL2JS returned
"RCP/encoded WSDLs are not supported in JAX-2.0". I had a feeling
it
is "neither here nor
there" but I wanted to double-check - I think I know what the issue
is now after reading the
corresponding documentation but I will return and send more info if
I cannot resolve it.

A separate question - is there a "bridge" between Axis WS and its
tools and CFX? Can an Axis
WS client call a CFX-implemented WS and vice versa or not?

Thanks

Benson Margulies wrote:



Demetris,

CXF includes the ability to build Soap 1.1 Javascript clients for
doc/lit and rpc/lit services. JAX-WS is relatively neither here
nor
there.

The code can be run in two modes. You can run the tool as a
standalone, and you get Javascript that (with the utility file
supplied) will run anywhere that has a compatible request object.
Or, you can ask any CXF-implemented web service to deliver a
ja

Re: WSDL2JS

[Demetris]

Hmm - good point on (2). Ok thanks Benson, I will work with (1) first 
and see how it fairs.

It should be straight-forward.

Benson Margulies wrote:

CXF has two things going on here.

1) you can ask the server to generate and deliver the javascript client.
2) you can create a 'dynamic client' that can talk to moderately
complex services.

However, option 2 requires the entire CXF stack on the client, and I
have no idea if J2ME has the necessary goodies.


On Wed, Aug 12, 2009 at 4:47 PM, Demetris wrote:
  

Does CXF support client-side programming for Web Services? What we are after
in one of our projects
is to:
(1) host web services (or at least a Soap engine) on mobile devices
(primarily running J2ME CDC)
(2) build web service clients on mobile devices, either by discovering and
utilizing WSDLs (to generate
javascript stubs) or some other mechanism to allow them to generate the
client code.

Not sure how realistic this is at this stage but I am not finding much on
(1) and a bit on (2). Many people
have said that generating WSDLs on mobile devices is a difficult task so we
are considering the off-the-
device mechanisms.

Daniel Kulp wrote:


On Tue August 11 2009 11:26:05 pm Demetris wrote:

  

Do you know if Axis 1.x can generate document/literal or only
rpc/encoded? I am wondering if setting
the OPERATION_STYLE_PROPERTY to document would do the trick.



I believe Axis1 can do doc/literal.   JAX-RPC did require some level of
support for that so I'm pretty sure Axis1 implemented it.   Not sure how to
go about configuring it to do so.   I'm not an Axis1 user.  :-)

Dan




  

Benson Margulies wrote:



Demetris,

If your place has a big investment in RPC/encoded, perhaps one of you
would like to pick up the project that one of our committers started
of adding RPC/encoded support to CXF. If you do it, you get to ensure
that it works with your services :-). I'd be happy to mentor someone
in figuring out where Dain left off.

--benson

On Tue, Aug 11, 2009 at 4:21 PM, Demetris wrote:

  

Of course I do see infrastructures here in production still using Axis
1.x without any plans on
migrating while other systems come into play with Axis 2 etc. and
interoperability between the
two sides is impossible - and of course the rest of us will need to sit
in between and needing to
do our own translations - not good.
In any case, CFX is a pretty impressive project so I have a feeling I
will be adapting it to my
work.

Cheers

Daniel Kulp wrote:



On Tue August 11 2009 12:15:40 pm Demetris wrote:

  

That's what I figured ;) Thanks  for the info Benson.

Now regarding inteconnection of Web Services across implementations,
if there is no bridge
between the old RPC/encoded and CFX, at least I am assuming that
newer
versions would
be able to handle SOAP calls across them or not? This is something I
never tried/looked into
while I worked exclusively with Axis so I was wondering.



Pretty much none of the modern SOAP toolkits support RPC/encoded.
 Axis2 doesn't.  CXF doesn't.  Metro/JAX-WS RI doesn't.  Etc
Basically, rpc/encoded was such an interopability nightmare that it
really fell into the bucket of "You REALLY REALLY don't want to use
it."If you want interopability, you really need to migrate to one
of the literal forms.

Dan


  

Benson Margulies wrote:



OK, that message is buried in the substrate somewhere. I'm not sure
that I agree with it :-) In practical terms, we just don't have the
code or RPC/encoded.

I'm unaware of anything you can use to interconnect an old Axis
RPC/encoded service with CXF.

On Mon, Aug 10, 2009 at 11:00 PM, Demetris

  

wrote:

  

Hi Benson,

the reason I mentioned JAX-WS is because a WSDL file that I passed
to WSDL2JS returned
"RCP/encoded WSDLs are not supported in JAX-2.0". I had a feeling
it
is "neither here nor
there" but I wanted to double-check - I think I know what the issue
is now after reading the
corresponding documentation but I will return and send more info if
I cannot resolve it.

A separate question - is there a "bridge" between Axis WS and its
tools and CFX? Can an Axis
WS client call a CFX-implemented WS and vice versa or not?

Thanks

Benson Margulies wrote:



Demetris,

CXF includes the ability to build Soap 1.1 Javascript clients for
doc/lit and rpc/lit services. JAX-WS is relatively neither here
nor
there.

The code can be run in two modes. You can run the tool as a
standalone, and you get Javascript that (with the utility file
supplied) will run anywhere that has a compatible request object.
Or, you can ask any CXF-implemented web service to deliver a
javascript client, and one will be returned.

Have you read
http://cwiki.apache.org/CXF20DOC/javascript-clients.html?

--benson

On Mon, Aug 10, 2009 at 5:40 PM, Demetris

  

wrote:

  

And one more observation - because wsdl2js u

Re: WSDL2JS

[Benson Margulies]

CXF has two things going on here.

1) you can ask the server to generate and deliver the javascript client.
2) you can create a 'dynamic client' that can talk to moderately
complex services.

However, option 2 requires the entire CXF stack on the client, and I
have no idea if J2ME has the necessary goodies.


On Wed, Aug 12, 2009 at 4:47 PM, Demetris wrote:
>
> Does CXF support client-side programming for Web Services? What we are after
> in one of our projects
> is to:
> (1) host web services (or at least a Soap engine) on mobile devices
> (primarily running J2ME CDC)
> (2) build web service clients on mobile devices, either by discovering and
> utilizing WSDLs (to generate
> javascript stubs) or some other mechanism to allow them to generate the
> client code.
>
> Not sure how realistic this is at this stage but I am not finding much on
> (1) and a bit on (2). Many people
> have said that generating WSDLs on mobile devices is a difficult task so we
> are considering the off-the-
> device mechanisms.
>
> Daniel Kulp wrote:
>>
>> On Tue August 11 2009 11:26:05 pm Demetris wrote:
>>
>>>
>>> Do you know if Axis 1.x can generate document/literal or only
>>> rpc/encoded? I am wondering if setting
>>> the OPERATION_STYLE_PROPERTY to document would do the trick.
>>>
>>
>> I believe Axis1 can do doc/literal.   JAX-RPC did require some level of
>> support for that so I'm pretty sure Axis1 implemented it.   Not sure how to
>> go about configuring it to do so.   I'm not an Axis1 user.  :-)
>>
>> Dan
>>
>>
>>
>>
>>>
>>> Benson Margulies wrote:
>>>

 Demetris,

 If your place has a big investment in RPC/encoded, perhaps one of you
 would like to pick up the project that one of our committers started
 of adding RPC/encoded support to CXF. If you do it, you get to ensure
 that it works with your services :-). I'd be happy to mentor someone
 in figuring out where Dain left off.

 --benson

 On Tue, Aug 11, 2009 at 4:21 PM, Demetris wrote:

>
> Of course I do see infrastructures here in production still using Axis
> 1.x without any plans on
> migrating while other systems come into play with Axis 2 etc. and
> interoperability between the
> two sides is impossible - and of course the rest of us will need to sit
> in between and needing to
> do our own translations - not good.
> In any case, CFX is a pretty impressive project so I have a feeling I
> will be adapting it to my
> work.
>
> Cheers
>
> Daniel Kulp wrote:
>
>>
>> On Tue August 11 2009 12:15:40 pm Demetris wrote:
>>
>>>
>>> That's what I figured ;) Thanks  for the info Benson.
>>>
>>> Now regarding inteconnection of Web Services across implementations,
>>> if there is no bridge
>>> between the old RPC/encoded and CFX, at least I am assuming that
>>> newer
>>> versions would
>>> be able to handle SOAP calls across them or not? This is something I
>>> never tried/looked into
>>> while I worked exclusively with Axis so I was wondering.
>>>
>>
>> Pretty much none of the modern SOAP toolkits support RPC/encoded.
>>  Axis2 doesn't.  CXF doesn't.  Metro/JAX-WS RI doesn't.  Etc
>> Basically, rpc/encoded was such an interopability nightmare that it
>> really fell into the bucket of "You REALLY REALLY don't want to use
>> it."    If you want interopability, you really need to migrate to one
>> of the literal forms.
>>
>> Dan
>>
>>
>>>
>>> Benson Margulies wrote:
>>>

 OK, that message is buried in the substrate somewhere. I'm not sure
 that I agree with it :-) In practical terms, we just don't have the
 code or RPC/encoded.

 I'm unaware of anything you can use to interconnect an old Axis
 RPC/encoded service with CXF.

 On Mon, Aug 10, 2009 at 11:00 PM, Demetris

>>
>> wrote:
>>
>
> Hi Benson,
>
> the reason I mentioned JAX-WS is because a WSDL file that I passed
> to WSDL2JS returned
> "RCP/encoded WSDLs are not supported in JAX-2.0". I had a feeling
> it
> is "neither here nor
> there" but I wanted to double-check - I think I know what the issue
> is now after reading the
> corresponding documentation but I will return and send more info if
> I cannot resolve it.
>
> A separate question - is there a "bridge" between Axis WS and its
> tools and CFX? Can an Axis
> WS client call a CFX-implemented WS and vice versa or not?
>
> Thanks
>
> Benson Margulies wrote:
>
>>
>> Demetris,
>>
>> CXF includes the ability to build Soap 1.1 Javascript clients for
>> doc/lit and rpc/lit services. JAX-WS is relatively neither here
>> nor
>> there.
>>
>

Re: WSDL2JS

[Demetris]

Does CXF support client-side programming for Web Services? What we are 
after in one of our projects

is to:
(1) host web services (or at least a Soap engine) on mobile devices 
(primarily running J2ME CDC)
(2) build web service clients on mobile devices, either by discovering 
and utilizing WSDLs (to generate
javascript stubs) or some other mechanism to allow them to generate the 
client code.


Not sure how realistic this is at this stage but I am not finding much 
on (1) and a bit on (2). Many people
have said that generating WSDLs on mobile devices is a difficult task so 
we are considering the off-the-

device mechanisms.

Daniel Kulp wrote:

On Tue August 11 2009 11:26:05 pm Demetris wrote:
  

Do you know if Axis 1.x can generate document/literal or only
rpc/encoded? I am wondering if setting
the OPERATION_STYLE_PROPERTY to document would do the trick.



I believe Axis1 can do doc/literal.   JAX-RPC did require some level of 
support for that so I'm pretty sure Axis1 implemented it.   Not sure how to go 
about configuring it to do so.   I'm not an Axis1 user.  :-)


Dan



  

Benson Margulies wrote:


Demetris,

If your place has a big investment in RPC/encoded, perhaps one of you
would like to pick up the project that one of our committers started
of adding RPC/encoded support to CXF. If you do it, you get to ensure
that it works with your services :-). I'd be happy to mentor someone
in figuring out where Dain left off.

--benson

On Tue, Aug 11, 2009 at 4:21 PM, Demetris wrote:
  

Of course I do see infrastructures here in production still using Axis
1.x without any plans on
migrating while other systems come into play with Axis 2 etc. and
interoperability between the
two sides is impossible - and of course the rest of us will need to sit
in between and needing to
do our own translations - not good.
In any case, CFX is a pretty impressive project so I have a feeling I
will be adapting it to my
work.

Cheers

Daniel Kulp wrote:


On Tue August 11 2009 12:15:40 pm Demetris wrote:
  

That's what I figured ;) Thanks  for the info Benson.

Now regarding inteconnection of Web Services across implementations,
if there is no bridge
between the old RPC/encoded and CFX, at least I am assuming that newer
versions would
be able to handle SOAP calls across them or not? This is something I
never tried/looked into
while I worked exclusively with Axis so I was wondering.

Pretty much none of the modern SOAP toolkits support RPC/encoded.  
Axis2 doesn't.  CXF doesn't.  Metro/JAX-WS RI doesn't.  Etc   
Basically, rpc/encoded was such an interopability nightmare that it

really fell into the bucket of "You REALLY REALLY don't want to use
it."If you want interopability, you really need to migrate to one
of the literal forms.

Dan

  

Benson Margulies wrote:


OK, that message is buried in the substrate somewhere. I'm not sure
that I agree with it :-) In practical terms, we just don't have the
code or RPC/encoded.

I'm unaware of anything you can use to interconnect an old Axis
RPC/encoded service with CXF.

On Mon, Aug 10, 2009 at 11:00 PM, Demetris 
  

wrote:
  

Hi Benson,

the reason I mentioned JAX-WS is because a WSDL file that I passed
to WSDL2JS returned
"RCP/encoded WSDLs are not supported in JAX-2.0". I had a feeling it
is "neither here nor
there" but I wanted to double-check - I think I know what the issue
is now after reading the
corresponding documentation but I will return and send more info if
I cannot resolve it.

A separate question - is there a "bridge" between Axis WS and its
tools and CFX? Can an Axis
WS client call a CFX-implemented WS and vice versa or not?

Thanks

Benson Margulies wrote:


Demetris,

CXF includes the ability to build Soap 1.1 Javascript clients for
doc/lit and rpc/lit services. JAX-WS is relatively neither here nor
there.

The code can be run in two modes. You can run the tool as a
standalone, and you get Javascript that (with the utility file
supplied) will run anywhere that has a compatible request object.
Or, you can ask any CXF-implemented web service to deliver a
javascript client, and one will be returned.

Have you read
http://cwiki.apache.org/CXF20DOC/javascript-clients.html?

--benson

On Mon, Aug 10, 2009 at 5:40 PM, Demetris 
  

wrote:
  

And one more observation - because wsdl2js utilizes JAX-WS 2.0,
RPC/Encoded
documents are not supported. Is that correct?

Thanks again

Demetris wrote:


Ok now that I played a bit with wsdl2js I am beginning to
understand what
you said below.
So one can use the wsdlurl in order to get the server to return
the script
- can you please
clarify a few things since I am new to this -
1. what kind of server are we talking about in this case?
2. The only way to generate the Javascript is through a remote
server
+ URL? If I have the WSDL
in my possesion how can I use this tool to generate the script 

Re: WSDL2JS

[Demetris]

Nicely put - I wouldn't have been messing around with CXF if I didn't 
think it is worth it and the
more I read about the more I am finding a number of fairly interesting 
directions I can take using it.
So yes, I mentioned Axis2 cause I overhead some people talking about it 
but hey I have no problem

advocating CXF here ;)

Daniel Kulp wrote:

On Tue August 11 2009 11:12:04 pm Demetris wrote:
  

Hi Benson,

that would a great opportunity to get to know CXF but I am sure I won't
be given the time to
work on it. I will certainly pass it on and see if we can get someone to
work with you although
I still have a feeling that the pressure to migrate to Axis2 is
mounting. 



May I ask "why Axis2"?   Axis2 is as similar to Axis1 as CXF is.  :-)

If you're going to migrate, I'd suggest migrating to a standards based API 
like JAX-WS and chose one of the really good JAX-WS implementations, like CXF.  


:-)


Dan



  

We (at least I) appreciate the
offer Benson and I will make sure the word gets around here.

I will let you know how it goes or at least if I have any more Qs on CXF
in general.
Thanks




  

Re: WSDL2JS

[Demetris]

He he - didn't mean to put you on the spot Dan - but I think you are 
right so I will chase it

in the Axis lists.

Daniel Kulp wrote:

On Tue August 11 2009 11:26:05 pm Demetris wrote:
  

Do you know if Axis 1.x can generate document/literal or only
rpc/encoded? I am wondering if setting
the OPERATION_STYLE_PROPERTY to document would do the trick.



I believe Axis1 can do doc/literal.   JAX-RPC did require some level of 
support for that so I'm pretty sure Axis1 implemented it.   Not sure how to go 
about configuring it to do so.   I'm not an Axis1 user.  :-)


Dan



  

Benson Margulies wrote:


Demetris,

If your place has a big investment in RPC/encoded, perhaps one of you
would like to pick up the project that one of our committers started
of adding RPC/encoded support to CXF. If you do it, you get to ensure
that it works with your services :-). I'd be happy to mentor someone
in figuring out where Dain left off.

--benson

On Tue, Aug 11, 2009 at 4:21 PM, Demetris wrote:
  

Of course I do see infrastructures here in production still using Axis
1.x without any plans on
migrating while other systems come into play with Axis 2 etc. and
interoperability between the
two sides is impossible - and of course the rest of us will need to sit
in between and needing to
do our own translations - not good.
In any case, CFX is a pretty impressive project so I have a feeling I
will be adapting it to my
work.

Cheers

Daniel Kulp wrote:


On Tue August 11 2009 12:15:40 pm Demetris wrote:
  

That's what I figured ;) Thanks  for the info Benson.

Now regarding inteconnection of Web Services across implementations,
if there is no bridge
between the old RPC/encoded and CFX, at least I am assuming that newer
versions would
be able to handle SOAP calls across them or not? This is something I
never tried/looked into
while I worked exclusively with Axis so I was wondering.

Pretty much none of the modern SOAP toolkits support RPC/encoded.  
Axis2 doesn't.  CXF doesn't.  Metro/JAX-WS RI doesn't.  Etc   
Basically, rpc/encoded was such an interopability nightmare that it

really fell into the bucket of "You REALLY REALLY don't want to use
it."If you want interopability, you really need to migrate to one
of the literal forms.

Dan

  

Benson Margulies wrote:


OK, that message is buried in the substrate somewhere. I'm not sure
that I agree with it :-) In practical terms, we just don't have the
code or RPC/encoded.

I'm unaware of anything you can use to interconnect an old Axis
RPC/encoded service with CXF.

On Mon, Aug 10, 2009 at 11:00 PM, Demetris 
  

wrote:
  

Hi Benson,

the reason I mentioned JAX-WS is because a WSDL file that I passed
to WSDL2JS returned
"RCP/encoded WSDLs are not supported in JAX-2.0". I had a feeling it
is "neither here nor
there" but I wanted to double-check - I think I know what the issue
is now after reading the
corresponding documentation but I will return and send more info if
I cannot resolve it.

A separate question - is there a "bridge" between Axis WS and its
tools and CFX? Can an Axis
WS client call a CFX-implemented WS and vice versa or not?

Thanks

Benson Margulies wrote:


Demetris,

CXF includes the ability to build Soap 1.1 Javascript clients for
doc/lit and rpc/lit services. JAX-WS is relatively neither here nor
there.

The code can be run in two modes. You can run the tool as a
standalone, and you get Javascript that (with the utility file
supplied) will run anywhere that has a compatible request object.
Or, you can ask any CXF-implemented web service to deliver a
javascript client, and one will be returned.

Have you read
http://cwiki.apache.org/CXF20DOC/javascript-clients.html?

--benson

On Mon, Aug 10, 2009 at 5:40 PM, Demetris 
  

wrote:
  

And one more observation - because wsdl2js utilizes JAX-WS 2.0,
RPC/Encoded
documents are not supported. Is that correct?

Thanks again

Demetris wrote:


Ok now that I played a bit with wsdl2js I am beginning to
understand what
you said below.
So one can use the wsdlurl in order to get the server to return
the script
- can you please
clarify a few things since I am new to this -
1. what kind of server are we talking about in this case?
2. The only way to generate the Javascript is through a remote
server
+ URL? If I have the WSDL
in my possesion how can I use this tool to generate the script of
me?

Thanks again

Benson Margulies wrote:
  

The tool is part of CXF, so it requires Java 1.5. Since its
output is Javascript, I don't understand why you need to run it
under J2ME.
In fact, you can just use the ?js URL form from the server to
get the server to generate it on the fly.

On Mon, Aug 10, 2009 at 2:32 PM, Demetris


wrote:
  

Hi all,

 I am interested in generating Javascript stubs from a WSDL
file - I am
assuming that the WSDL2js tool is the
app

Re: WSDL2JS

[Daniel Kulp]

On Tue August 11 2009 11:26:05 pm Demetris wrote:
> Do you know if Axis 1.x can generate document/literal or only
> rpc/encoded? I am wondering if setting
> the OPERATION_STYLE_PROPERTY to document would do the trick.

I believe Axis1 can do doc/literal.   JAX-RPC did require some level of 
support for that so I'm pretty sure Axis1 implemented it.   Not sure how to go 
about configuring it to do so.   I'm not an Axis1 user.  :-)

Dan



> Benson Margulies wrote:
> > Demetris,
> >
> > If your place has a big investment in RPC/encoded, perhaps one of you
> > would like to pick up the project that one of our committers started
> > of adding RPC/encoded support to CXF. If you do it, you get to ensure
> > that it works with your services :-). I'd be happy to mentor someone
> > in figuring out where Dain left off.
> >
> > --benson
> >
> > On Tue, Aug 11, 2009 at 4:21 PM, Demetris wrote:
> >> Of course I do see infrastructures here in production still using Axis
> >> 1.x without any plans on
> >> migrating while other systems come into play with Axis 2 etc. and
> >> interoperability between the
> >> two sides is impossible - and of course the rest of us will need to sit
> >> in between and needing to
> >> do our own translations - not good.
> >> In any case, CFX is a pretty impressive project so I have a feeling I
> >> will be adapting it to my
> >> work.
> >>
> >> Cheers
> >>
> >> Daniel Kulp wrote:
> >>> On Tue August 11 2009 12:15:40 pm Demetris wrote:
>  That's what I figured ;) Thanks  for the info Benson.
> 
>  Now regarding inteconnection of Web Services across implementations,
>  if there is no bridge
>  between the old RPC/encoded and CFX, at least I am assuming that newer
>  versions would
>  be able to handle SOAP calls across them or not? This is something I
>  never tried/looked into
>  while I worked exclusively with Axis so I was wondering.
> >>>
> >>> Pretty much none of the modern SOAP toolkits support RPC/encoded.  
> >>> Axis2 doesn't.  CXF doesn't.  Metro/JAX-WS RI doesn't.  Etc   
> >>> Basically, rpc/encoded was such an interopability nightmare that it
> >>> really fell into the bucket of "You REALLY REALLY don't want to use
> >>> it."If you want interopability, you really need to migrate to one
> >>> of the literal forms.
> >>>
> >>> Dan
> >>>
>  Benson Margulies wrote:
> > OK, that message is buried in the substrate somewhere. I'm not sure
> > that I agree with it :-) In practical terms, we just don't have the
> > code or RPC/encoded.
> >
> > I'm unaware of anything you can use to interconnect an old Axis
> > RPC/encoded service with CXF.
> >
> > On Mon, Aug 10, 2009 at 11:00 PM, Demetris 
wrote:
> >> Hi Benson,
> >>
> >> the reason I mentioned JAX-WS is because a WSDL file that I passed
> >> to WSDL2JS returned
> >> "RCP/encoded WSDLs are not supported in JAX-2.0". I had a feeling it
> >> is "neither here nor
> >> there" but I wanted to double-check - I think I know what the issue
> >> is now after reading the
> >> corresponding documentation but I will return and send more info if
> >> I cannot resolve it.
> >>
> >> A separate question - is there a "bridge" between Axis WS and its
> >> tools and CFX? Can an Axis
> >> WS client call a CFX-implemented WS and vice versa or not?
> >>
> >> Thanks
> >>
> >> Benson Margulies wrote:
> >>> Demetris,
> >>>
> >>> CXF includes the ability to build Soap 1.1 Javascript clients for
> >>> doc/lit and rpc/lit services. JAX-WS is relatively neither here nor
> >>> there.
> >>>
> >>> The code can be run in two modes. You can run the tool as a
> >>> standalone, and you get Javascript that (with the utility file
> >>> supplied) will run anywhere that has a compatible request object.
> >>> Or, you can ask any CXF-implemented web service to deliver a
> >>> javascript client, and one will be returned.
> >>>
> >>> Have you read
> >>> http://cwiki.apache.org/CXF20DOC/javascript-clients.html?
> >>>
> >>> --benson
> >>>
> >>> On Mon, Aug 10, 2009 at 5:40 PM, Demetris 
wrote:
>  And one more observation - because wsdl2js utilizes JAX-WS 2.0,
>  RPC/Encoded
>  documents are not supported. Is that correct?
> 
>  Thanks again
> 
>  Demetris wrote:
> > Ok now that I played a bit with wsdl2js I am beginning to
> > understand what
> > you said below.
> > So one can use the wsdlurl in order to get the server to return
> > the script
> > - can you please
> > clarify a few things since I am new to this -
> > 1. what kind of server are we talking about in this case?
> > 2. The only way to generate the Javascript is through a remote
> > server
> > + URL? If I have the WSDL
> > in my possesion how can I use th

Re: WSDL2JS

[Daniel Kulp]

On Tue August 11 2009 11:12:04 pm Demetris wrote:
> Hi Benson,
>
> that would a great opportunity to get to know CXF but I am sure I won't
> be given the time to
> work on it. I will certainly pass it on and see if we can get someone to
> work with you although
> I still have a feeling that the pressure to migrate to Axis2 is
> mounting. 

May I ask "why Axis2"?   Axis2 is as similar to Axis1 as CXF is.  :-)

If you're going to migrate, I'd suggest migrating to a standards based API 
like JAX-WS and chose one of the really good JAX-WS implementations, like CXF.  

:-)


Dan



> We (at least I) appreciate the
> offer Benson and I will make sure the word gets around here.
>
> I will let you know how it goes or at least if I have any more Qs on CXF
> in general.
> Thanks
>

-- 
Daniel Kulp
dk...@apache.org
http://www.dankulp.com/blog

Re: WSDL2JS

[Demetris]

Do you know if Axis 1.x can generate document/literal or only 
rpc/encoded? I am wondering if setting

the OPERATION_STYLE_PROPERTY to document would do the trick.

Benson Margulies wrote:

Demetris,

If your place has a big investment in RPC/encoded, perhaps one of you
would like to pick up the project that one of our committers started
of adding RPC/encoded support to CXF. If you do it, you get to ensure
that it works with your services :-). I'd be happy to mentor someone
in figuring out where Dain left off.

--benson


On Tue, Aug 11, 2009 at 4:21 PM, Demetris wrote:
  

Of course I do see infrastructures here in production still using Axis 1.x
without any plans on
migrating while other systems come into play with Axis 2 etc. and
interoperability between the
two sides is impossible - and of course the rest of us will need to sit in
between and needing to
do our own translations - not good.
In any case, CFX is a pretty impressive project so I have a feeling I will
be adapting it to my
work.

Cheers

Daniel Kulp wrote:


On Tue August 11 2009 12:15:40 pm Demetris wrote:

  

That's what I figured ;) Thanks  for the info Benson.

Now regarding inteconnection of Web Services across implementations, if
there is no bridge
between the old RPC/encoded and CFX, at least I am assuming that newer
versions would
be able to handle SOAP calls across them or not? This is something I
never tried/looked into
while I worked exclusively with Axis so I was wondering.



Pretty much none of the modern SOAP toolkits support RPC/encoded.   Axis2
doesn't.  CXF doesn't.  Metro/JAX-WS RI doesn't.  EtcBasically,
rpc/encoded was such an interopability nightmare that it really fell into
the bucket of "You REALLY REALLY don't want to use it."If you want
interopability, you really need to migrate to one of the literal forms.

Dan



  

Benson Margulies wrote:



OK, that message is buried in the substrate somewhere. I'm not sure
that I agree with it :-) In practical terms, we just don't have the
code or RPC/encoded.

I'm unaware of anything you can use to interconnect an old Axis
RPC/encoded service with CXF.

On Mon, Aug 10, 2009 at 11:00 PM, Demetris wrote:

  

Hi Benson,

the reason I mentioned JAX-WS is because a WSDL file that I passed to
WSDL2JS returned
"RCP/encoded WSDLs are not supported in JAX-2.0". I had a feeling it is
"neither here nor
there" but I wanted to double-check - I think I know what the issue is
now after reading the
corresponding documentation but I will return and send more info if I
cannot resolve it.

A separate question - is there a "bridge" between Axis WS and its tools
and CFX? Can an Axis
WS client call a CFX-implemented WS and vice versa or not?

Thanks

Benson Margulies wrote:



Demetris,

CXF includes the ability to build Soap 1.1 Javascript clients for
doc/lit and rpc/lit services. JAX-WS is relatively neither here nor
there.

The code can be run in two modes. You can run the tool as a
standalone, and you get Javascript that (with the utility file
supplied) will run anywhere that has a compatible request object. Or,
you can ask any CXF-implemented web service to deliver a javascript
client, and one will be returned.

Have you read
http://cwiki.apache.org/CXF20DOC/javascript-clients.html?

--benson

On Mon, Aug 10, 2009 at 5:40 PM, Demetris wrote:

  

And one more observation - because wsdl2js utilizes JAX-WS 2.0,
RPC/Encoded
documents are not supported. Is that correct?

Thanks again

Demetris wrote:



Ok now that I played a bit with wsdl2js I am beginning to understand
what
you said below.
So one can use the wsdlurl in order to get the server to return the
script
- can you please
clarify a few things since I am new to this -
1. what kind of server are we talking about in this case?
2. The only way to generate the Javascript is through a remote
server
+ URL? If I have the WSDL
in my possesion how can I use this tool to generate the script of
me?

Thanks again

Benson Margulies wrote:

  

The tool is part of CXF, so it requires Java 1.5. Since its output
is Javascript, I don't understand why you need to run it under
J2ME.
In fact, you can just use the ?js URL form from the server to get
the server to generate it on the fly.

On Mon, Aug 10, 2009 at 2:32 PM, Demetris



wrote:

  

Hi all,

 I am interested in generating Javascript stubs from a WSDL file -
I am
assuming that the WSDL2js tool is the
appropriate tool to use. Has anyone used this tool so that I can
ask a couple of Qs?

(1) Which Java version is the tool built on?
(2) Can I used it under J2ME-CDC to generate stubs for mobile
devices?

Thanks in advanced

  
  


  

Re: WSDL2JS

[Demetris]

Hi Benson,

that would a great opportunity to get to know CXF but I am sure I won't 
be given the time to
work on it. I will certainly pass it on and see if we can get someone to 
work with you although
I still have a feeling that the pressure to migrate to Axis2 is 
mounting. We (at least I) appreciate the

offer Benson and I will make sure the word gets around here.

I will let you know how it goes or at least if I have any more Qs on CXF 
in general.

Thanks

Benson Margulies wrote:

Demetris,

If your place has a big investment in RPC/encoded, perhaps one of you
would like to pick up the project that one of our committers started
of adding RPC/encoded support to CXF. If you do it, you get to ensure
that it works with your services :-). I'd be happy to mentor someone
in figuring out where Dain left off.

--benson


On Tue, Aug 11, 2009 at 4:21 PM, Demetris wrote:
  

Of course I do see infrastructures here in production still using Axis 1.x
without any plans on
migrating while other systems come into play with Axis 2 etc. and
interoperability between the
two sides is impossible - and of course the rest of us will need to sit in
between and needing to
do our own translations - not good.
In any case, CFX is a pretty impressive project so I have a feeling I will
be adapting it to my
work.

Cheers

Daniel Kulp wrote:


On Tue August 11 2009 12:15:40 pm Demetris wrote:

  

That's what I figured ;) Thanks  for the info Benson.

Now regarding inteconnection of Web Services across implementations, if
there is no bridge
between the old RPC/encoded and CFX, at least I am assuming that newer
versions would
be able to handle SOAP calls across them or not? This is something I
never tried/looked into
while I worked exclusively with Axis so I was wondering.



Pretty much none of the modern SOAP toolkits support RPC/encoded.   Axis2
doesn't.  CXF doesn't.  Metro/JAX-WS RI doesn't.  EtcBasically,
rpc/encoded was such an interopability nightmare that it really fell into
the bucket of "You REALLY REALLY don't want to use it."If you want
interopability, you really need to migrate to one of the literal forms.

Dan



  

Benson Margulies wrote:



OK, that message is buried in the substrate somewhere. I'm not sure
that I agree with it :-) In practical terms, we just don't have the
code or RPC/encoded.

I'm unaware of anything you can use to interconnect an old Axis
RPC/encoded service with CXF.

On Mon, Aug 10, 2009 at 11:00 PM, Demetris wrote:

  

Hi Benson,

the reason I mentioned JAX-WS is because a WSDL file that I passed to
WSDL2JS returned
"RCP/encoded WSDLs are not supported in JAX-2.0". I had a feeling it is
"neither here nor
there" but I wanted to double-check - I think I know what the issue is
now after reading the
corresponding documentation but I will return and send more info if I
cannot resolve it.

A separate question - is there a "bridge" between Axis WS and its tools
and CFX? Can an Axis
WS client call a CFX-implemented WS and vice versa or not?

Thanks

Benson Margulies wrote:



Demetris,

CXF includes the ability to build Soap 1.1 Javascript clients for
doc/lit and rpc/lit services. JAX-WS is relatively neither here nor
there.

The code can be run in two modes. You can run the tool as a
standalone, and you get Javascript that (with the utility file
supplied) will run anywhere that has a compatible request object. Or,
you can ask any CXF-implemented web service to deliver a javascript
client, and one will be returned.

Have you read
http://cwiki.apache.org/CXF20DOC/javascript-clients.html?

--benson

On Mon, Aug 10, 2009 at 5:40 PM, Demetris wrote:

  

And one more observation - because wsdl2js utilizes JAX-WS 2.0,
RPC/Encoded
documents are not supported. Is that correct?

Thanks again

Demetris wrote:



Ok now that I played a bit with wsdl2js I am beginning to understand
what
you said below.
So one can use the wsdlurl in order to get the server to return the
script
- can you please
clarify a few things since I am new to this -
1. what kind of server are we talking about in this case?
2. The only way to generate the Javascript is through a remote
server
+ URL? If I have the WSDL
in my possesion how can I use this tool to generate the script of
me?

Thanks again

Benson Margulies wrote:

  

The tool is part of CXF, so it requires Java 1.5. Since its output
is Javascript, I don't understand why you need to run it under
J2ME.
In fact, you can just use the ?js URL form from the server to get
the server to generate it on the fly.

On Mon, Aug 10, 2009 at 2:32 PM, Demetris



wrote:

  

Hi all,

 I am interested in generating Javascript stubs from a WSDL file -
I am
assuming that the WSDL2js tool is the
appropriate tool to use. Has anyone used this tool so that I can
ask a couple of Qs?

(1) Which Java version is the tool built on?
(2) Can I used it under J2ME-CDC to generate 

Re: WSDL2JS

[Benson Margulies]

Demetris,

If your place has a big investment in RPC/encoded, perhaps one of you
would like to pick up the project that one of our committers started
of adding RPC/encoded support to CXF. If you do it, you get to ensure
that it works with your services :-). I'd be happy to mentor someone
in figuring out where Dain left off.

--benson


On Tue, Aug 11, 2009 at 4:21 PM, Demetris wrote:
>
> Of course I do see infrastructures here in production still using Axis 1.x
> without any plans on
> migrating while other systems come into play with Axis 2 etc. and
> interoperability between the
> two sides is impossible - and of course the rest of us will need to sit in
> between and needing to
> do our own translations - not good.
> In any case, CFX is a pretty impressive project so I have a feeling I will
> be adapting it to my
> work.
>
> Cheers
>
> Daniel Kulp wrote:
>>
>> On Tue August 11 2009 12:15:40 pm Demetris wrote:
>>
>>>
>>> That's what I figured ;) Thanks  for the info Benson.
>>>
>>> Now regarding inteconnection of Web Services across implementations, if
>>> there is no bridge
>>> between the old RPC/encoded and CFX, at least I am assuming that newer
>>> versions would
>>> be able to handle SOAP calls across them or not? This is something I
>>> never tried/looked into
>>> while I worked exclusively with Axis so I was wondering.
>>>
>>
>> Pretty much none of the modern SOAP toolkits support RPC/encoded.   Axis2
>> doesn't.  CXF doesn't.  Metro/JAX-WS RI doesn't.  Etc    Basically,
>> rpc/encoded was such an interopability nightmare that it really fell into
>> the bucket of "You REALLY REALLY don't want to use it."    If you want
>> interopability, you really need to migrate to one of the literal forms.
>>
>> Dan
>>
>>
>>
>>>
>>> Benson Margulies wrote:
>>>

 OK, that message is buried in the substrate somewhere. I'm not sure
 that I agree with it :-) In practical terms, we just don't have the
 code or RPC/encoded.

 I'm unaware of anything you can use to interconnect an old Axis
 RPC/encoded service with CXF.

 On Mon, Aug 10, 2009 at 11:00 PM, Demetris wrote:

>
> Hi Benson,
>
> the reason I mentioned JAX-WS is because a WSDL file that I passed to
> WSDL2JS returned
> "RCP/encoded WSDLs are not supported in JAX-2.0". I had a feeling it is
> "neither here nor
> there" but I wanted to double-check - I think I know what the issue is
> now after reading the
> corresponding documentation but I will return and send more info if I
> cannot resolve it.
>
> A separate question - is there a "bridge" between Axis WS and its tools
> and CFX? Can an Axis
> WS client call a CFX-implemented WS and vice versa or not?
>
> Thanks
>
> Benson Margulies wrote:
>
>>
>> Demetris,
>>
>> CXF includes the ability to build Soap 1.1 Javascript clients for
>> doc/lit and rpc/lit services. JAX-WS is relatively neither here nor
>> there.
>>
>> The code can be run in two modes. You can run the tool as a
>> standalone, and you get Javascript that (with the utility file
>> supplied) will run anywhere that has a compatible request object. Or,
>> you can ask any CXF-implemented web service to deliver a javascript
>> client, and one will be returned.
>>
>> Have you read
>> http://cwiki.apache.org/CXF20DOC/javascript-clients.html?
>>
>> --benson
>>
>> On Mon, Aug 10, 2009 at 5:40 PM, Demetris wrote:
>>
>>>
>>> And one more observation - because wsdl2js utilizes JAX-WS 2.0,
>>> RPC/Encoded
>>> documents are not supported. Is that correct?
>>>
>>> Thanks again
>>>
>>> Demetris wrote:
>>>

 Ok now that I played a bit with wsdl2js I am beginning to understand
 what
 you said below.
 So one can use the wsdlurl in order to get the server to return the
 script
 - can you please
 clarify a few things since I am new to this -
 1. what kind of server are we talking about in this case?
 2. The only way to generate the Javascript is through a remote
 server
 + URL? If I have the WSDL
 in my possesion how can I use this tool to generate the script of
 me?

 Thanks again

 Benson Margulies wrote:

>
> The tool is part of CXF, so it requires Java 1.5. Since its output
> is Javascript, I don't understand why you need to run it under
> J2ME.
> In fact, you can just use the ?js URL form from the server to get
> the server to generate it on the fly.
>
> On Mon, Aug 10, 2009 at 2:32 PM, Demetris
>
>>
>> wrote:
>>
>>
>> Hi all,
>>
>>  I am interested in generating Javascript stubs from a WSDL file -
>> I am
>> assuming that the WSDL2js tool is the
>> app

Re: WSDL2JS

[Demetris]

Of course I do see infrastructures here in production still using Axis 
1.x without any plans on
migrating while other systems come into play with Axis 2 etc. and 
interoperability between the
two sides is impossible - and of course the rest of us will need to sit 
in between and needing to

do our own translations - not good.
In any case, CFX is a pretty impressive project so I have a feeling I 
will be adapting it to my

work.

Cheers

Daniel Kulp wrote:

On Tue August 11 2009 12:15:40 pm Demetris wrote:
  

That's what I figured ;) Thanks  for the info Benson.

Now regarding inteconnection of Web Services across implementations, if
there is no bridge
between the old RPC/encoded and CFX, at least I am assuming that newer
versions would
be able to handle SOAP calls across them or not? This is something I
never tried/looked into
while I worked exclusively with Axis so I was wondering.



Pretty much none of the modern SOAP toolkits support RPC/encoded.   Axis2 
doesn't.  CXF doesn't.  Metro/JAX-WS RI doesn't.  EtcBasically, 
rpc/encoded was such an interopability nightmare that it really fell into the 
bucket of "You REALLY REALLY don't want to use it."If you want 
interopability, you really need to migrate to one of the literal forms.


Dan


  

Benson Margulies wrote:


OK, that message is buried in the substrate somewhere. I'm not sure
that I agree with it :-) In practical terms, we just don't have the
code or RPC/encoded.

I'm unaware of anything you can use to interconnect an old Axis
RPC/encoded service with CXF.

On Mon, Aug 10, 2009 at 11:00 PM, Demetris wrote:
  

Hi Benson,

the reason I mentioned JAX-WS is because a WSDL file that I passed to
WSDL2JS returned
"RCP/encoded WSDLs are not supported in JAX-2.0". I had a feeling it is
"neither here nor
there" but I wanted to double-check - I think I know what the issue is
now after reading the
corresponding documentation but I will return and send more info if I
cannot resolve it.

A separate question - is there a "bridge" between Axis WS and its tools
and CFX? Can an Axis
WS client call a CFX-implemented WS and vice versa or not?

Thanks

Benson Margulies wrote:


Demetris,

CXF includes the ability to build Soap 1.1 Javascript clients for
doc/lit and rpc/lit services. JAX-WS is relatively neither here nor
there.

The code can be run in two modes. You can run the tool as a
standalone, and you get Javascript that (with the utility file
supplied) will run anywhere that has a compatible request object. Or,
you can ask any CXF-implemented web service to deliver a javascript
client, and one will be returned.

Have you read http://cwiki.apache.org/CXF20DOC/javascript-clients.html?

--benson

On Mon, Aug 10, 2009 at 5:40 PM, Demetris wrote:
  

And one more observation - because wsdl2js utilizes JAX-WS 2.0,
RPC/Encoded
documents are not supported. Is that correct?

Thanks again

Demetris wrote:


Ok now that I played a bit with wsdl2js I am beginning to understand
what
you said below.
So one can use the wsdlurl in order to get the server to return the
script
- can you please
clarify a few things since I am new to this -
1. what kind of server are we talking about in this case?
2. The only way to generate the Javascript is through a remote server
+ URL? If I have the WSDL
in my possesion how can I use this tool to generate the script of me?

Thanks again

Benson Margulies wrote:
  

The tool is part of CXF, so it requires Java 1.5. Since its output
is Javascript, I don't understand why you need to run it under J2ME.
In fact, you can just use the ?js URL form from the server to get
the server to generate it on the fly.

On Mon, Aug 10, 2009 at 2:32 PM, Demetris 


wrote:
  

Hi all,

 I am interested in generating Javascript stubs from a WSDL file -
I am
assuming that the WSDL2js tool is the
appropriate tool to use. Has anyone used this tool so that I can
ask a couple of Qs?

(1) Which Java version is the tool built on?
(2) Can I used it under J2ME-CDC to generate stubs for mobile
devices?

Thanks in advanced
  


  

Re: WSDL2JS

[Demetris]

Well that's what I was after and I agree with you - Thanks much Dan

Daniel Kulp wrote:

On Tue August 11 2009 12:15:40 pm Demetris wrote:
  

That's what I figured ;) Thanks  for the info Benson.

Now regarding inteconnection of Web Services across implementations, if
there is no bridge
between the old RPC/encoded and CFX, at least I am assuming that newer
versions would
be able to handle SOAP calls across them or not? This is something I
never tried/looked into
while I worked exclusively with Axis so I was wondering.



Pretty much none of the modern SOAP toolkits support RPC/encoded.   Axis2 
doesn't.  CXF doesn't.  Metro/JAX-WS RI doesn't.  EtcBasically, 
rpc/encoded was such an interopability nightmare that it really fell into the 
bucket of "You REALLY REALLY don't want to use it."If you want 
interopability, you really need to migrate to one of the literal forms.


Dan


  

Benson Margulies wrote:


OK, that message is buried in the substrate somewhere. I'm not sure
that I agree with it :-) In practical terms, we just don't have the
code or RPC/encoded.

I'm unaware of anything you can use to interconnect an old Axis
RPC/encoded service with CXF.

On Mon, Aug 10, 2009 at 11:00 PM, Demetris wrote:
  

Hi Benson,

the reason I mentioned JAX-WS is because a WSDL file that I passed to
WSDL2JS returned
"RCP/encoded WSDLs are not supported in JAX-2.0". I had a feeling it is
"neither here nor
there" but I wanted to double-check - I think I know what the issue is
now after reading the
corresponding documentation but I will return and send more info if I
cannot resolve it.

A separate question - is there a "bridge" between Axis WS and its tools
and CFX? Can an Axis
WS client call a CFX-implemented WS and vice versa or not?

Thanks

Benson Margulies wrote:


Demetris,

CXF includes the ability to build Soap 1.1 Javascript clients for
doc/lit and rpc/lit services. JAX-WS is relatively neither here nor
there.

The code can be run in two modes. You can run the tool as a
standalone, and you get Javascript that (with the utility file
supplied) will run anywhere that has a compatible request object. Or,
you can ask any CXF-implemented web service to deliver a javascript
client, and one will be returned.

Have you read http://cwiki.apache.org/CXF20DOC/javascript-clients.html?

--benson

On Mon, Aug 10, 2009 at 5:40 PM, Demetris wrote:
  

And one more observation - because wsdl2js utilizes JAX-WS 2.0,
RPC/Encoded
documents are not supported. Is that correct?

Thanks again

Demetris wrote:


Ok now that I played a bit with wsdl2js I am beginning to understand
what
you said below.
So one can use the wsdlurl in order to get the server to return the
script
- can you please
clarify a few things since I am new to this -
1. what kind of server are we talking about in this case?
2. The only way to generate the Javascript is through a remote server
+ URL? If I have the WSDL
in my possesion how can I use this tool to generate the script of me?

Thanks again

Benson Margulies wrote:
  

The tool is part of CXF, so it requires Java 1.5. Since its output
is Javascript, I don't understand why you need to run it under J2ME.
In fact, you can just use the ?js URL form from the server to get
the server to generate it on the fly.

On Mon, Aug 10, 2009 at 2:32 PM, Demetris 


wrote:
  

Hi all,

 I am interested in generating Javascript stubs from a WSDL file -
I am
assuming that the WSDL2js tool is the
appropriate tool to use. Has anyone used this tool so that I can
ask a couple of Qs?

(1) Which Java version is the tool built on?
(2) Can I used it under J2ME-CDC to generate stubs for mobile
devices?

Thanks in advanced
  


  

Re: WSDL2JS

[Daniel Kulp]

On Tue August 11 2009 12:15:40 pm Demetris wrote:
> That's what I figured ;) Thanks  for the info Benson.
>
> Now regarding inteconnection of Web Services across implementations, if
> there is no bridge
> between the old RPC/encoded and CFX, at least I am assuming that newer
> versions would
> be able to handle SOAP calls across them or not? This is something I
> never tried/looked into
> while I worked exclusively with Axis so I was wondering.

Pretty much none of the modern SOAP toolkits support RPC/encoded.   Axis2 
doesn't.  CXF doesn't.  Metro/JAX-WS RI doesn't.  EtcBasically, 
rpc/encoded was such an interopability nightmare that it really fell into the 
bucket of "You REALLY REALLY don't want to use it."If you want 
interopability, you really need to migrate to one of the literal forms.

Dan


> Benson Margulies wrote:
> > OK, that message is buried in the substrate somewhere. I'm not sure
> > that I agree with it :-) In practical terms, we just don't have the
> > code or RPC/encoded.
> >
> > I'm unaware of anything you can use to interconnect an old Axis
> > RPC/encoded service with CXF.
> >
> > On Mon, Aug 10, 2009 at 11:00 PM, Demetris wrote:
> >> Hi Benson,
> >>
> >> the reason I mentioned JAX-WS is because a WSDL file that I passed to
> >> WSDL2JS returned
> >> "RCP/encoded WSDLs are not supported in JAX-2.0". I had a feeling it is
> >> "neither here nor
> >> there" but I wanted to double-check - I think I know what the issue is
> >> now after reading the
> >> corresponding documentation but I will return and send more info if I
> >> cannot resolve it.
> >>
> >> A separate question - is there a "bridge" between Axis WS and its tools
> >> and CFX? Can an Axis
> >> WS client call a CFX-implemented WS and vice versa or not?
> >>
> >> Thanks
> >>
> >> Benson Margulies wrote:
> >>> Demetris,
> >>>
> >>> CXF includes the ability to build Soap 1.1 Javascript clients for
> >>> doc/lit and rpc/lit services. JAX-WS is relatively neither here nor
> >>> there.
> >>>
> >>> The code can be run in two modes. You can run the tool as a
> >>> standalone, and you get Javascript that (with the utility file
> >>> supplied) will run anywhere that has a compatible request object. Or,
> >>> you can ask any CXF-implemented web service to deliver a javascript
> >>> client, and one will be returned.
> >>>
> >>> Have you read http://cwiki.apache.org/CXF20DOC/javascript-clients.html?
> >>>
> >>> --benson
> >>>
> >>> On Mon, Aug 10, 2009 at 5:40 PM, Demetris wrote:
>  And one more observation - because wsdl2js utilizes JAX-WS 2.0,
>  RPC/Encoded
>  documents are not supported. Is that correct?
> 
>  Thanks again
> 
>  Demetris wrote:
> > Ok now that I played a bit with wsdl2js I am beginning to understand
> > what
> > you said below.
> > So one can use the wsdlurl in order to get the server to return the
> > script
> > - can you please
> > clarify a few things since I am new to this -
> > 1. what kind of server are we talking about in this case?
> > 2. The only way to generate the Javascript is through a remote server
> > + URL? If I have the WSDL
> > in my possesion how can I use this tool to generate the script of me?
> >
> > Thanks again
> >
> > Benson Margulies wrote:
> >> The tool is part of CXF, so it requires Java 1.5. Since its output
> >> is Javascript, I don't understand why you need to run it under J2ME.
> >> In fact, you can just use the ?js URL form from the server to get
> >> the server to generate it on the fly.
> >>
> >> On Mon, Aug 10, 2009 at 2:32 PM, Demetris 
wrote:
> >>> Hi all,
> >>>
> >>>  I am interested in generating Javascript stubs from a WSDL file -
> >>> I am
> >>> assuming that the WSDL2js tool is the
> >>> appropriate tool to use. Has anyone used this tool so that I can
> >>> ask a couple of Qs?
> >>>
> >>> (1) Which Java version is the tool built on?
> >>> (2) Can I used it under J2ME-CDC to generate stubs for mobile
> >>> devices?
> >>>
> >>> Thanks in advanced

-- 
Daniel Kulp
dk...@apache.org
http://www.dankulp.com/blog

Re: WSDL2JS

[Demetris]

That's what I figured ;) Thanks  for the info Benson.

Now regarding inteconnection of Web Services across implementations, if 
there is no bridge
between the old RPC/encoded and CFX, at least I am assuming that newer 
versions would
be able to handle SOAP calls across them or not? This is something I 
never tried/looked into

while I worked exclusively with Axis so I was wondering.

Benson Margulies wrote:

OK, that message is buried in the substrate somewhere. I'm not sure
that I agree with it :-) In practical terms, we just don't have the
code or RPC/encoded.

I'm unaware of anything you can use to interconnect an old Axis
RPC/encoded service with CXF.

On Mon, Aug 10, 2009 at 11:00 PM, Demetris wrote:
  

Hi Benson,

the reason I mentioned JAX-WS is because a WSDL file that I passed to
WSDL2JS returned
"RCP/encoded WSDLs are not supported in JAX-2.0". I had a feeling it is
"neither here nor
there" but I wanted to double-check - I think I know what the issue is now
after reading the
corresponding documentation but I will return and send more info if I cannot
resolve it.

A separate question - is there a "bridge" between Axis WS and its tools and
CFX? Can an Axis
WS client call a CFX-implemented WS and vice versa or not?

Thanks

Benson Margulies wrote:


Demetris,

CXF includes the ability to build Soap 1.1 Javascript clients for
doc/lit and rpc/lit services. JAX-WS is relatively neither here nor
there.

The code can be run in two modes. You can run the tool as a
standalone, and you get Javascript that (with the utility file
supplied) will run anywhere that has a compatible request object. Or,
you can ask any CXF-implemented web service to deliver a javascript
client, and one will be returned.

Have you read http://cwiki.apache.org/CXF20DOC/javascript-clients.html?

--benson


On Mon, Aug 10, 2009 at 5:40 PM, Demetris wrote:

  

And one more observation - because wsdl2js utilizes JAX-WS 2.0,
RPC/Encoded
documents are not supported. Is that correct?

Thanks again

Demetris wrote:



Ok now that I played a bit with wsdl2js I am beginning to understand
what
you said below.
So one can use the wsdlurl in order to get the server to return the
script
- can you please
clarify a few things since I am new to this -
1. what kind of server are we talking about in this case?
2. The only way to generate the Javascript is through a remote server +
URL? If I have the WSDL
in my possesion how can I use this tool to generate the script of me?

Thanks again

Benson Margulies wrote:

  

The tool is part of CXF, so it requires Java 1.5. Since its output is
Javascript, I don't understand why you need to run it under J2ME. In
fact, you can just use the ?js URL form from the server to get the
server to generate it on the fly.

On Mon, Aug 10, 2009 at 2:32 PM, Demetris wrote:




Hi all,

 I am interested in generating Javascript stubs from a WSDL file - I
am
assuming that the WSDL2js tool is the
appropriate tool to use. Has anyone used this tool so that I can ask a
couple of Qs?

(1) Which Java version is the tool built on?
(2) Can I used it under J2ME-CDC to generate stubs for mobile devices?

Thanks in advanced




  

  


  

Re: WSDL2JS

[Benson Margulies]

OK, that message is buried in the substrate somewhere. I'm not sure
that I agree with it :-) In practical terms, we just don't have the
code or RPC/encoded.

I'm unaware of anything you can use to interconnect an old Axis
RPC/encoded service with CXF.

On Mon, Aug 10, 2009 at 11:00 PM, Demetris wrote:
>
> Hi Benson,
>
> the reason I mentioned JAX-WS is because a WSDL file that I passed to
> WSDL2JS returned
> "RCP/encoded WSDLs are not supported in JAX-2.0". I had a feeling it is
> "neither here nor
> there" but I wanted to double-check - I think I know what the issue is now
> after reading the
> corresponding documentation but I will return and send more info if I cannot
> resolve it.
>
> A separate question - is there a "bridge" between Axis WS and its tools and
> CFX? Can an Axis
> WS client call a CFX-implemented WS and vice versa or not?
>
> Thanks
>
> Benson Margulies wrote:
>>
>> Demetris,
>>
>> CXF includes the ability to build Soap 1.1 Javascript clients for
>> doc/lit and rpc/lit services. JAX-WS is relatively neither here nor
>> there.
>>
>> The code can be run in two modes. You can run the tool as a
>> standalone, and you get Javascript that (with the utility file
>> supplied) will run anywhere that has a compatible request object. Or,
>> you can ask any CXF-implemented web service to deliver a javascript
>> client, and one will be returned.
>>
>> Have you read http://cwiki.apache.org/CXF20DOC/javascript-clients.html?
>>
>> --benson
>>
>>
>> On Mon, Aug 10, 2009 at 5:40 PM, Demetris wrote:
>>
>>>
>>> And one more observation - because wsdl2js utilizes JAX-WS 2.0,
>>> RPC/Encoded
>>> documents are not supported. Is that correct?
>>>
>>> Thanks again
>>>
>>> Demetris wrote:
>>>

 Ok now that I played a bit with wsdl2js I am beginning to understand
 what
 you said below.
 So one can use the wsdlurl in order to get the server to return the
 script
 - can you please
 clarify a few things since I am new to this -
 1. what kind of server are we talking about in this case?
 2. The only way to generate the Javascript is through a remote server +
 URL? If I have the WSDL
 in my possesion how can I use this tool to generate the script of me?

 Thanks again

 Benson Margulies wrote:

>
> The tool is part of CXF, so it requires Java 1.5. Since its output is
> Javascript, I don't understand why you need to run it under J2ME. In
> fact, you can just use the ?js URL form from the server to get the
> server to generate it on the fly.
>
> On Mon, Aug 10, 2009 at 2:32 PM, Demetris wrote:
>
>
>>
>> Hi all,
>>
>>  I am interested in generating Javascript stubs from a WSDL file - I
>> am
>> assuming that the WSDL2js tool is the
>> appropriate tool to use. Has anyone used this tool so that I can ask a
>> couple of Qs?
>>
>> (1) Which Java version is the tool built on?
>> (2) Can I used it under J2ME-CDC to generate stubs for mobile devices?
>>
>> Thanks in advanced
>>
>>
>>
>>
>
>
>>
>>
>

Re: WSDL2JS

[Demetris]

And excuse the typos - CXF I meant to say all along .. :)

Demetris wrote:


Hi Benson,

the reason I mentioned JAX-WS is because a WSDL file that I passed to 
WSDL2JS returned
"RCP/encoded WSDLs are not supported in JAX-2.0". I had a feeling it 
is "neither here nor
there" but I wanted to double-check - I think I know what the issue is 
now after reading the
corresponding documentation but I will return and send more info if I 
cannot resolve it.


A separate question - is there a "bridge" between Axis WS and its 
tools and CFX? Can an Axis

WS client call a CFX-implemented WS and vice versa or not?

Thanks

Benson Margulies wrote:

Demetris,

CXF includes the ability to build Soap 1.1 Javascript clients for
doc/lit and rpc/lit services. JAX-WS is relatively neither here nor
there.

The code can be run in two modes. You can run the tool as a
standalone, and you get Javascript that (with the utility file
supplied) will run anywhere that has a compatible request object. Or,
you can ask any CXF-implemented web service to deliver a javascript
client, and one will be returned.

Have you read http://cwiki.apache.org/CXF20DOC/javascript-clients.html?

--benson


On Mon, Aug 10, 2009 at 5:40 PM, Demetris wrote:
 
And one more observation - because wsdl2js utilizes JAX-WS 2.0, 
RPC/Encoded

documents are not supported. Is that correct?

Thanks again

Demetris wrote:
   
Ok now that I played a bit with wsdl2js I am beginning to 
understand what

you said below.
So one can use the wsdlurl in order to get the server to return the 
script

- can you please
clarify a few things since I am new to this -
1. what kind of server are we talking about in this case?
2. The only way to generate the Javascript is through a remote 
server +

URL? If I have the WSDL
in my possesion how can I use this tool to generate the script of me?

Thanks again

Benson Margulies wrote:
 

The tool is part of CXF, so it requires Java 1.5. Since its output is
Javascript, I don't understand why you need to run it under J2ME. In
fact, you can just use the ?js URL form from the server to get the
server to generate it on the fly.

On Mon, Aug 10, 2009 at 2:32 PM, Demetris 
wrote:


   

Hi all,

 I am interested in generating Javascript stubs from a WSDL file 
- I am

assuming that the WSDL2js tool is the
appropriate tool to use. Has anyone used this tool so that I can 
ask a

couple of Qs?

(1) Which Java version is the tool built on?
(2) Can I used it under J2ME-CDC to generate stubs for mobile 
devices?


Thanks in advanced



  



  

Re: WSDL2JS

[Demetris]

Hi Benson,

the reason I mentioned JAX-WS is because a WSDL file that I passed to 
WSDL2JS returned
"RCP/encoded WSDLs are not supported in JAX-2.0". I had a feeling it is 
"neither here nor
there" but I wanted to double-check - I think I know what the issue is 
now after reading the
corresponding documentation but I will return and send more info if I 
cannot resolve it.


A separate question - is there a "bridge" between Axis WS and its tools 
and CFX? Can an Axis

WS client call a CFX-implemented WS and vice versa or not?

Thanks

Benson Margulies wrote:

Demetris,

CXF includes the ability to build Soap 1.1 Javascript clients for
doc/lit and rpc/lit services. JAX-WS is relatively neither here nor
there.

The code can be run in two modes. You can run the tool as a
standalone, and you get Javascript that (with the utility file
supplied) will run anywhere that has a compatible request object. Or,
you can ask any CXF-implemented web service to deliver a javascript
client, and one will be returned.

Have you read http://cwiki.apache.org/CXF20DOC/javascript-clients.html?

--benson


On Mon, Aug 10, 2009 at 5:40 PM, Demetris wrote:
  

And one more observation - because wsdl2js utilizes JAX-WS 2.0, RPC/Encoded
documents are not supported. Is that correct?

Thanks again

Demetris wrote:


Ok now that I played a bit with wsdl2js I am beginning to understand what
you said below.
So one can use the wsdlurl in order to get the server to return the script
- can you please
clarify a few things since I am new to this -
1. what kind of server are we talking about in this case?
2. The only way to generate the Javascript is through a remote server +
URL? If I have the WSDL
in my possesion how can I use this tool to generate the script of me?

Thanks again

Benson Margulies wrote:
  

The tool is part of CXF, so it requires Java 1.5. Since its output is
Javascript, I don't understand why you need to run it under J2ME. In
fact, you can just use the ?js URL form from the server to get the
server to generate it on the fly.

On Mon, Aug 10, 2009 at 2:32 PM, Demetris wrote:



Hi all,

 I am interested in generating Javascript stubs from a WSDL file - I am
assuming that the WSDL2js tool is the
appropriate tool to use. Has anyone used this tool so that I can ask a
couple of Qs?

(1) Which Java version is the tool built on?
(2) Can I used it under J2ME-CDC to generate stubs for mobile devices?

Thanks in advanced



  



  

Re: WSDL2JS

[Benson Margulies]

Demetris,

CXF includes the ability to build Soap 1.1 Javascript clients for
doc/lit and rpc/lit services. JAX-WS is relatively neither here nor
there.

The code can be run in two modes. You can run the tool as a
standalone, and you get Javascript that (with the utility file
supplied) will run anywhere that has a compatible request object. Or,
you can ask any CXF-implemented web service to deliver a javascript
client, and one will be returned.

Have you read http://cwiki.apache.org/CXF20DOC/javascript-clients.html?

--benson


On Mon, Aug 10, 2009 at 5:40 PM, Demetris wrote:
>
> And one more observation - because wsdl2js utilizes JAX-WS 2.0, RPC/Encoded
> documents are not supported. Is that correct?
>
> Thanks again
>
> Demetris wrote:
>>
>> Ok now that I played a bit with wsdl2js I am beginning to understand what
>> you said below.
>> So one can use the wsdlurl in order to get the server to return the script
>> - can you please
>> clarify a few things since I am new to this -
>> 1. what kind of server are we talking about in this case?
>> 2. The only way to generate the Javascript is through a remote server +
>> URL? If I have the WSDL
>> in my possesion how can I use this tool to generate the script of me?
>>
>> Thanks again
>>
>> Benson Margulies wrote:
>>>
>>> The tool is part of CXF, so it requires Java 1.5. Since its output is
>>> Javascript, I don't understand why you need to run it under J2ME. In
>>> fact, you can just use the ?js URL form from the server to get the
>>> server to generate it on the fly.
>>>
>>> On Mon, Aug 10, 2009 at 2:32 PM, Demetris wrote:
>>>

 Hi all,

  I am interested in generating Javascript stubs from a WSDL file - I am
 assuming that the WSDL2js tool is the
 appropriate tool to use. Has anyone used this tool so that I can ask a
 couple of Qs?

 (1) Which Java version is the tool built on?
 (2) Can I used it under J2ME-CDC to generate stubs for mobile devices?

 Thanks in advanced



>>>
>>>
>>
>

Re: WSDL2JS

[Demetris]

And one more observation - because wsdl2js utilizes JAX-WS 2.0, RPC/Encoded
documents are not supported. Is that correct?

Thanks again

Demetris wrote:


Ok now that I played a bit with wsdl2js I am beginning to understand 
what you said below.
So one can use the wsdlurl in order to get the server to return the 
script - can you please

clarify a few things since I am new to this -
1. what kind of server are we talking about in this case?
2. The only way to generate the Javascript is through a remote server 
+ URL? If I have the WSDL

in my possesion how can I use this tool to generate the script of me?

Thanks again

Benson Margulies wrote:

The tool is part of CXF, so it requires Java 1.5. Since its output is
Javascript, I don't understand why you need to run it under J2ME. In
fact, you can just use the ?js URL form from the server to get the
server to generate it on the fly.

On Mon, Aug 10, 2009 at 2:32 PM, Demetris wrote:
 

Hi all,

  I am interested in generating Javascript stubs from a WSDL file - 
I am

assuming that the WSDL2js tool is the
appropriate tool to use. Has anyone used this tool so that I can ask a
couple of Qs?

(1) Which Java version is the tool built on?
(2) Can I used it under J2ME-CDC to generate stubs for mobile devices?

Thanks in advanced





  

Re: WSDL2JS

[Demetris]

Ok now that I played a bit with wsdl2js I am beginning to understand 
what you said below.
So one can use the wsdlurl in order to get the server to return the 
script - can you please

clarify a few things since I am new to this -
1. what kind of server are we talking about in this case?
2. The only way to generate the Javascript is through a remote server + 
URL? If I have the WSDL

in my possesion how can I use this tool to generate the script of me?

Thanks again

Benson Margulies wrote:

The tool is part of CXF, so it requires Java 1.5. Since its output is
Javascript, I don't understand why you need to run it under J2ME. In
fact, you can just use the ?js URL form from the server to get the
server to generate it on the fly.

On Mon, Aug 10, 2009 at 2:32 PM, Demetris wrote:
  

Hi all,

  I am interested in generating Javascript stubs from a WSDL file - I am
assuming that the WSDL2js tool is the
appropriate tool to use. Has anyone used this tool so that I can ask a
couple of Qs?

(1) Which Java version is the tool built on?
(2) Can I used it under J2ME-CDC to generate stubs for mobile devices?

Thanks in advanced





  

Re: WSDL2JS

[Demetris]

Hi Benson,

thanks for the response - that was for cases where the mobile device is 
hosting a Web Service
then that server would be running under J2ME (ex. mAS) but I need to 
think that through a bit

more first.

However, you did answer my question regarding the tool.

Thanks

Benson Margulies wrote:

The tool is part of CXF, so it requires Java 1.5. Since its output is
Javascript, I don't understand why you need to run it under J2ME. In
fact, you can just use the ?js URL form from the server to get the
server to generate it on the fly.

On Mon, Aug 10, 2009 at 2:32 PM, Demetris wrote:
  

Hi all,

  I am interested in generating Javascript stubs from a WSDL file - I am
assuming that the WSDL2js tool is the
appropriate tool to use. Has anyone used this tool so that I can ask a
couple of Qs?

(1) Which Java version is the tool built on?
(2) Can I used it under J2ME-CDC to generate stubs for mobile devices?

Thanks in advanced





  

Re: WSDL2JS

[Benson Margulies]

The tool is part of CXF, so it requires Java 1.5. Since its output is
Javascript, I don't understand why you need to run it under J2ME. In
fact, you can just use the ?js URL form from the server to get the
server to generate it on the fly.

On Mon, Aug 10, 2009 at 2:32 PM, Demetris wrote:
>
> Hi all,
>
>   I am interested in generating Javascript stubs from a WSDL file - I am
> assuming that the WSDL2js tool is the
> appropriate tool to use. Has anyone used this tool so that I can ask a
> couple of Qs?
>
> (1) Which Java version is the tool built on?
> (2) Can I used it under J2ME-CDC to generate stubs for mobile devices?
>
> Thanks in advanced
>
>