Hello,
I think there are users that love the quick Unmarshaller.unmarshal
style and others would like to have far more control of the process
behind....
I think the point is to get rid of the static methods from Un-/
Marshaller and the generated classes!
And then we need two styles to work with Castor:
*) starting with XMLContext and havin full control of loading mapping
information and marshalling...
*) with a new facade for quick access of un-/marshal outside of Un-/
Marshaller
Regards
Joachim
On Oct 30, 2007, at 1:45 PM, Ralf Joachim wrote:
Godmar,
you got a good point with type safety.
Ralf
Godmar Back schrieb:
Both of the alternatives you describe require the use of casts, which
can fail at runtime. An advantage of code generators such as
Castor is
that they allow for more compile-time checking, reducing the
likelihood of runtime failures. (Compare to Java generics, which
require you to provide a wildcard type whenever unsafe casts are
used.) You give up that advantage in your proposal.
Also, requiring the user to manage the XMLContext (whatever that is)
seems burdensome. I would not completely remove those methods.
Instead, maybe there is a way to make them more robust to avoid the
complications you describe?
- Godmar
On 10/30/07, Ralf Joachim <[EMAIL PROTECTED]> wrote:
Hi Godmar,
the driver behind deprecating/removing the static methods is,
that we
frequently get requests from users that set mapping or other
properties
on a (un)marshaller instance but use one of the static (un)marshal
methods. What happens is that their mapping or properties get not
recognized and the result does not look as expected (e.g. they get
exceptions at unmarshalling). The only way we see to prevent such
problems is to deprecate/remove those static convinience methods.
On the other side you are right that these methods make your own
code
shorter and easier to understand. Instead of:
SomeXMLClass obj = SomeXMLClass.unmarshal(reader);
or
SomeXMLClass obj = (SomeXMLClass)
Unmarshaller.unmarshal(SomeXMLClass.class, reader);
you will need:
Unmarshaller unmarshaller = new Unmarshaller(SomeXMLClass.class);
SomeXMLClass obj = (SomeXMLClass) unmarshaller.unmarshal(reader);
or better using XMLContext:
// create context once, load class descriptors and set properties
XMLContext context = new XMLContext();
context.addClass(SomeXMLClass.class);
// create unmarshaller to unmarshal from reader
Unmarshaller unmarshaller = context.createUnmarshaller();
unmarshaller.setClass(SomeXMLClass.class);
SomeXMLClass obj = (SomeXMLClass) unmarshaller.unmarshal(reader);
Using XMLContext you will also gain some performance improvements
with
the reuse of context and it makes it easier for you to use multiple
(un)marshaller instances with different configurations in one
application. This is what happens internally if you call the static
Unmarshaller.unmarshal(Class, Reader) method.
Having said that we do not intend to remove the static methods
with next
release. Instead we will declare them deprecated for some releases
before they get removed finally.
Regards
Ralf
Godmar Back schrieb:
The static methods on Marshaller/Unmarshaller is what we're
currently
using. [ I didn't know that the generated code contained marshal
methods, but now that you mentioned them I discovered them.]
I find those methods necessary, and I don't understand the
motivation
for getting rid of them.
Suppose I now code:
SomeXMLClass obj = SomeXMLClass.unmarshal(reader);
(which I like best, but see above.)
or
SomeXMLClass obj =
(SomeXMLClass)Unmarshaller.unmarshal(SomeXMLClass.class, reader):
What would the equivalent code look like under your proposal?
- Godmar
On 10/29/07, Werner Guttmann <[EMAIL PROTECTED]> wrote:
True, actually. Good point ...
Werner
Ralf Joachim wrote:
Werner,
but if we keep that switch we won't be able to deprecate/
remove the
static methods on marshaller/unmarshaller which cause more
problems then
those on generated code.
IMHO removing the static methods on generated code could only
be a step
to also remove those of (un)marshaller.
Ralf
Werner Guttmann schrieb:
Claudio,
Can I (safely) assume that you know that you can turn off
generation
of these methods already now ? In other words, we might
change the
default value of the property in question so that these
methods won't
be generated in the future anymore. If you still want them,
yo can get
them by asking for them specifically.
Werner
Claudio Di Vita wrote:
Werner Guttmann ha scritto:
Hi,
we (committers) are currently thinking about deprecating (and
eventually) removing all the static (un-)marshal() methods on
classes as
generated using the Castor XML code generator.
The reason for this is simple: we'd like people to use
explicit
(Un-)Marshaller instances as there's been a lot of
confusion around
usage of mapping files and static methods.
As it is very hard to get one's head around the impact of
this change,
I'd like to hear from you, the users, what you think about
this change.
As always, if there's no feedback, we consider this
suggested change as
acceptable and will continue going about an implementation.
You are right, those static methods generates a lot of
confusion.
Moreover I hope that who use the classes generated with the
Castor XML
code generator instantiates explicitly a (Un) Marshaller.
Best regards,
Claudio
---------------------------------------------------------------
------
To unsubscribe from this list please visit:
http://xircles.codehaus.org/manage_email
----------------------------------------------------------------
-----
To unsubscribe from this list please visit:
http://xircles.codehaus.org/manage_email
-----------------------------------------------------------------
----
To unsubscribe from this list please visit:
http://xircles.codehaus.org/manage_email
------------------------------------------------------------------
---
To unsubscribe from this list please visit:
http://xircles.codehaus.org/manage_email
-------------------------------------------------------------------
--
To unsubscribe from this list please visit:
http://xircles.codehaus.org/manage_email
--
Syscon Ingenieurbüro für Meß- und Datentechnik GmbH
Ralf Joachim
Raiffeisenstraße 11
72127 Kusterdingen
Germany
Tel. +49 7071 3690 52
Mobil: +49 173 9630135
Fax +49 7071 3690 98
Internet: www.syscon.eu
E-Mail: [EMAIL PROTECTED]
Sitz der Gesellschaft: D-72127 Kusterdingen
Registereintrag: Amtsgericht Stuttgart, HRB 382295
Geschäftsleitung: Jens Joachim, Ralf Joachim
--------------------------------------------------------------------
-
To unsubscribe from this list please visit:
http://xircles.codehaus.org/manage_email
---------------------------------------------------------------------
To unsubscribe from this list please visit:
http://xircles.codehaus.org/manage_email
--
Syscon Ingenieurbüro für Meß- und Datentechnik GmbH
Ralf Joachim
Raiffeisenstraße 11
72127 Kusterdingen
Germany
Tel. +49 7071 3690 52
Mobil: +49 173 9630135
Fax +49 7071 3690 98
Internet: www.syscon.eu
E-Mail: [EMAIL PROTECTED]
Sitz der Gesellschaft: D-72127 Kusterdingen
Registereintrag: Amtsgericht Stuttgart, HRB 382295
Geschäftsleitung: Jens Joachim, Ralf Joachim
---------------------------------------------------------------------
To unsubscribe from this list please visit:
http://xircles.codehaus.org/manage_email
---------------------------------------------------------------------
To unsubscribe from this list please visit:
http://xircles.codehaus.org/manage_email
