going back to the .NET issue, is there any way to configure XFire to be able to talk to .NET services? Even if it does not follow the spec, I believe being able to connect to .NET will give a bigger user-base to XFire, something we will all benefit from.
Regards¿
AB
On 11/2/06, Taras Puchko <[EMAIL PROTECTED]> wrote:
I did it almost half a year ago, but AFAIR I had successfully run both
a Java 5 server and a generated Java 5 client on JRE 1.4. Both of them
were using annotations and generics. I translated them along with
XFire, like this:
java -jar retrotranslator-transformer-1.0.9.jar -srcjar server.jar
-srcjar client.jar -srcjar xfire-all-1.2.2.jar
And at runtime I specified -Djava.class.version=49.0 both for the
client and the server:
java - Djava.class.version=49.0 -jar client.jar
This was needed especially on the server for generic collections to be
correctly exposed via autogenerated WSDL, since XFire sometimes does
not use generics and annotations if this option is 48.0.
On 11/2/06, Tomek Sztelak <[EMAIL PROTECTED]> wrote:
> Hi Taras
> Did run translated XFire client succesuly ? If so, maybe you can write
> few words what must be done ? :)
>
> On 11/2/06, Taras Puchko <[EMAIL PROTECTED]> wrote:
> > Hi!
> >
> > To make generated XFire client work on JRE 1.4 all modules can be
> > translated with Retrotranslator to fully eliminate Java 5 API usages.
> > The module dependencies should be provided via -classpath ONLY if
> > verification is enabled, since they are not used during the
> > translation. Setting -Djava.class.version=49.0 property when running
> > client can also help in case of problems with type mapping.
> >
> > I am the author of Retrotranslator.
> >
> > Regards,
> > Taras
> >
---------------------------------------------------------------------
To unsubscribe from this list please visit:
http://xircles.codehaus.org/manage_email
