I will try to join you tomorrow in your call. I think this is a good
opportunity to give you some details of what we have and get some detailed
information of what you have in place and what still missing/needed.

--
Oliver

-----Ursprüngliche Nachricht-----
Von: Daniel Jemiolo [mailto:[EMAIL PROTECTED]
Gesendet: Donnerstag, 8. Juni 2006 18:25
An: [email protected]
Betreff: Re: client site accessors for muse


I believe Oliver is referring to just the client-side piece of code
generation, which is part of our existing code/contribution - we just
haven't gotten around to changing the package/identifier names yet (IBM ->
Apache).

The current client generation tool takes a WSDL and generates a class with
all of the appropriate operations, plus getters/setters for the resource
properties. If an RMD file is referenced, it will take the permissions
defined in the RMD into account and only generate the getters/setters that
will result in correct requests. The generated clients rely on a subset of
the Muse .jar files and whatever XML parser is available (Xerces, Crimson,
etc).

Like Balan said, we have been thinking about the service-side generation
vs. the way we do it in today's tooling, and how it will be changed to
operate both as an independent CLI and as a component of an IDE. Putting
the client generator in JIRA was put off until we had more of the
service-side generation concrete, but we can provide it sooner if you'd
like to help with this part. Please join the call Friday[1] if you'd like
to discuss.

Dan


[1] http://marc.theaimsgroup.com/?l=muse-dev&m=114917278003490&w=2



Balan Subramanian/Raleigh/[EMAIL PROTECTED] wrote on 06/08/2006 11:06:41 AM:

>
> Hi,
> We at IBM (Dan, Andrew, Mark and me) have been discussing a initial
design for
> this recently. It would be great to work together on this. Can you point
us to
> any of the existing code / design documents you might have? Is the code
in the
> repository?
>
> Dan, can we add this to the agenda for discussion during tomorrow's
call?
>
> Balan Subramanian
> Autonomic Computing, IBM, RTP, NC
> 919.543.0197 | [EMAIL PROTECTED]
>
>
>
>

>
> "Oliver Waeldrich" <[EMAIL PROTECTED]>
> 06/08/2006 04:03 AM
>
> Please respond to
> [email protected]
>
> To
>
> [email protected]
>
> cc
>
> Subject
>
> client site accessors for muse
>
>
>
>
> Hi,
>
> We have recently developed an addition to WSRF that extends the basic
> mechanisms of the WSRF WSDL2JAVA tool to generate the client accessors
> (interfaces, stubs, addressing locators) for WSRF services. Therefore we
make
> use of the client side pats of the Apache WS-Addressing framework and
XmlBeans
> to use the same comfortable environment we have on the server side as
well on
> the client side.
>
> Since WSRF and Pubscribe are merging into the Muse project, the Muse
project
> is going towards Axis2 and moving to the current WSRF specs with the IBM
code
> donation I wonder whether future versions of Muse will rely on the code
> generation features of Axis, this topic is already addressed by the IBM
code
> donation, or it is planed to write a own code generation facility like
it was
> the case in the WSRF project. In the latter case we would be interested
to
> donate our code and push it to a level that fits into the Muse project
and
> participate in the development of this project.
>
> Sal advised me that this mailing list would be the right place to
discuss this
> topic and I hope that we get a discussion started.
>
> Best regard,
> Oliver
>
> --
>
>
> Echte DSL-Flatrate dauerhaft für 0,- Euro*!
> "Feel free" mit GMX DSL! http://www.gmx.net/de/go/dsl
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to