simple-support Mailing List for Simple (Page 68)
Brought to you by:
niallg
Menu
▾
▴
simple-support — General user and support issues
You can subscribe to this list here.
| 2007 |
Jan
|
Feb
(2) |
Mar
(2) |
Apr
(13) |
May
(13) |
Jun
(27) |
Jul
(4) |
Aug
(14) |
Sep
(7) |
Oct
|
Nov
(6) |
Dec
(24) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2008 |
Jan
|
Feb
(21) |
Mar
(10) |
Apr
(15) |
May
(24) |
Jun
(24) |
Jul
(30) |
Aug
(5) |
Sep
(19) |
Oct
(27) |
Nov
(16) |
Dec
(24) |
| 2009 |
Jan
(34) |
Feb
(24) |
Mar
(35) |
Apr
(26) |
May
(8) |
Jun
(17) |
Jul
(28) |
Aug
(31) |
Sep
(36) |
Oct
(35) |
Nov
(20) |
Dec
(16) |
| 2010 |
Jan
(40) |
Feb
(21) |
Mar
(47) |
Apr
(45) |
May
(34) |
Jun
(68) |
Jul
(46) |
Aug
(39) |
Sep
(47) |
Oct
(20) |
Nov
(42) |
Dec
(13) |
| 2011 |
Jan
(41) |
Feb
(16) |
Mar
(32) |
Apr
(44) |
May
(28) |
Jun
(35) |
Jul
(37) |
Aug
(33) |
Sep
(60) |
Oct
(20) |
Nov
(35) |
Dec
(23) |
| 2012 |
Jan
(34) |
Feb
(23) |
Mar
(34) |
Apr
(21) |
May
(48) |
Jun
(24) |
Jul
(31) |
Aug
(39) |
Sep
(25) |
Oct
(10) |
Nov
(27) |
Dec
(28) |
| 2013 |
Jan
(32) |
Feb
(24) |
Mar
(24) |
Apr
(9) |
May
(4) |
Jun
(6) |
Jul
(2) |
Aug
(5) |
Sep
|
Oct
(5) |
Nov
(1) |
Dec
(12) |
| 2014 |
Jan
(14) |
Feb
(16) |
Mar
(5) |
Apr
(3) |
May
(2) |
Jun
(8) |
Jul
(2) |
Aug
|
Sep
(6) |
Oct
|
Nov
(6) |
Dec
|
| 2015 |
Jan
(3) |
Feb
(15) |
Mar
(7) |
Apr
|
May
|
Jun
(1) |
Jul
|
Aug
|
Sep
(2) |
Oct
|
Nov
|
Dec
(1) |
| 2016 |
Jan
|
Feb
(6) |
Mar
(2) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2017 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(1) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2018 |
Jan
(1) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(1) |
Dec
|
| 2019 |
Jan
|
Feb
|
Mar
|
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Kevin D. <for...@tr...> - 2009-01-29 17:51:56
|
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<STYLE type=text/css> P, UL, OL, DL, DIR, MENU, PRE { margin: 0 auto;}</STYLE>
<META content="MSHTML 6.00.6000.16788" name=GENERATOR></HEAD>
<BODY leftMargin=1 topMargin=1 rightMargin=1><FONT face=Arial size=2>
<DIV>Just curious if there is any functional difference between these two. The source has some slight differences, but they seem like they are doing pretty much the same thing.</DIV>
<DIV> </DIV>
<DIV>Thanks!</DIV>
<DIV> </DIV>
<DIV>- K</DIV>
<DIV> </DIV>
<DIV> </DIV>
<DIV></DIV>
<DIV> </DIV></FONT></BODY></HTML>
|
|
From: <Nia...@ub...> - 2009-01-29 10:27:56
|
Hi, Yes, it is fixed in 2.0.2. Niall -----Original Message----- From: Timo Rumland [mailto:cr...@ol...] Sent: 29 January 2009 09:46 To: sim...@li... Subject: [Simple-support] Issue from Oct 1st,2008 - Deserialization of type Calendar Hello Niall, in October 2008, I asked about the deserialization of the type Calendar, and why SimpleXML does not use the 'class="GregorianCalendar"' attribute to deserialize it to an instance of GregorianCalendar (for details, see the mailinglist). You wrote: > Yes, this will be fixed very soon in the next version, it is a bug at > the moment. Unfortunately it is something I did not spot until > recently. I would like to know, is this issue fixed in the latest version of Simple? Thanks a lot for your help - Timo ------------------------------------------------------------------------ ------ This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword _______________________________________________ Simple-support mailing list Sim...@li... https://lists.sourceforge.net/lists/listinfo/simple-support Visit our website at http://www.ubs.com This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mails are not encrypted and cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message which arise as a result of e-mail transmission. If verification is required please request a hard-copy version. This message is provided for informational purposes and should not be construed as a solicitation or offer to buy or sell any securities or related financial instruments. UBS Limited is a company registered in England & Wales under company number 2035362, whose registered office is at 1 Finsbury Avenue, London, EC2M 2PP, United Kingdom. UBS AG (London Branch) is registered as a branch of a foreign company under number BR004507, whose registered office is at 1 Finsbury Avenue, London, EC2M 2PP, United Kingdom. UBS Clearing and Execution Services Limited is a company registered in England & Wales under company number 03123037, whose registered office is at 1 Finsbury Avenue, London, EC2M 2PP, United Kingdom. |
|
From: Timo R. <cr...@ol...> - 2009-01-29 10:11:27
|
Hello Niall, in October 2008, I asked about the deserialization of the type Calendar, and why SimpleXML does not use the 'class="GregorianCalendar"' attribute to deserialize it to an instance of GregorianCalendar (for details, see the mailinglist). You wrote: > Yes, this will be fixed very soon in the next version, it is a bug > at the moment. Unfortunately it is something I did not spot until > recently. I would like to know, is this issue fixed in the latest version of Simple? Thanks a lot for your help - Timo |
|
From: Niall G. <gal...@ya...> - 2009-01-28 19:20:48
|
Hi,
The XML
<pfx:MyRoot xmlns:pfx="namespace">
<SubElement/>
</pfx:MyRoot>
is equal to
<pfx:MyRoot xmlns:pfx="namespace">
<pfx:SubElement/>
</pfx:MyRoot>
I realise that the prefixes are redundant but the qualification is identical. If you want you can do this.
@Root
@NamespaceList({@Namespace(reference="default")})
@Namespace(prefix="pfx", reference="namespace")
class MyRoot {
@Element
@Namespace(reference="default")
private SubElement subElement;
}
Which will give you.
<pfx:MyRoot xmlns:pfx="namespace" xmlns="default">
<SubElement/>
</pfx:MyRoot>
But this has a difference qualification to the XML you provide.
Niall
--- On Wed, 1/28/09, Wetmiller, Eric <ewe...@ha...> wrote:
> From: Wetmiller, Eric <ewe...@ha...>
> Subject: RE: [Simple-support] elementFormDefault
> To: gal...@ya...
> Date: Wednesday, January 28, 2009, 10:55 AM
> I tried that and I got the following while serializing my
> Object:
>
> <pfx:MyRoot xmlns:pfx="namespace">
> <SubElement xmlns=""/>
> </pfx:MyRoot>
>
> This is what I was expecting:
>
> <pfx:MyRoot xmlns:pfx="namespace">
> <SubElement/>
> </pfx:MyRoot>
>
> -----Original Message-----
> From: Niall Gallagher [mailto:gal...@ya...]
> Sent: Wednesday, January 28, 2009 1:49 PM
> To: sim...@li...; Wetmiller, Eric
> Subject: Re: [Simple-support] elementFormDefault
>
>
> Just use @Namespace without anything and all children of
> that object
> will be unqualified. You can put it on @Elements or
> @Attributes as well
> as @Root. And even on @Version. No need so keep specifying.
>
>
> --- On Wed, 1/28/09, Wetmiller, Eric
> <ewe...@ha...> wrote:
>
> > From: Wetmiller, Eric <ewe...@ha...>
> > Subject: [Simple-support] elementFormDefault
> > To: sim...@li...
> > Date: Wednesday, January 28, 2009, 10:46 AM
> > I am using SimpleXML version 2.0.2 and was wondering
> if
> > there is a way
> > to set elementFormDefault="unqualified" on
> my
> > schema. It appears that I
> > have to qualify all of the sub-elements in my schema.
> So,
> > in other
> > words, when I set my root element namespace, ie
> > @Namespace("pfx",
> > "namespace"), I have to use prefix for all
> > sub-elements also. Any help
> > would be appreciated.
> >
> >
> >
> > -Eric
> >
> >
> ------------------------------------------------------------------------
> ------
> > This SF.net email is sponsored by:
> > SourcForge Community
> > SourceForge wants to tell your story.
> >
> http://p.sf.net/sfu/sf-spreadtheword____________________________________
> ___________
> > Simple-support mailing list
> > Sim...@li...
> >
> https://lists.sourceforge.net/lists/listinfo/simple-support
|
|
From: Niall G. <gal...@ya...> - 2009-01-28 18:49:21
|
Just use @Namespace without anything and all children of that object will be unqualified. You can put it on @Elements or @Attributes as well as @Root. And even on @Version. No need so keep specifying.
--- On Wed, 1/28/09, Wetmiller, Eric <ewe...@ha...> wrote:
> From: Wetmiller, Eric <ewe...@ha...>
> Subject: [Simple-support] elementFormDefault
> To: sim...@li...
> Date: Wednesday, January 28, 2009, 10:46 AM
> I am using SimpleXML version 2.0.2 and was wondering if
> there is a way
> to set elementFormDefault="unqualified" on my
> schema. It appears that I
> have to qualify all of the sub-elements in my schema. So,
> in other
> words, when I set my root element namespace, ie
> @Namespace("pfx",
> "namespace"), I have to use prefix for all
> sub-elements also. Any help
> would be appreciated.
>
>
>
> -Eric
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by:
> SourcForge Community
> SourceForge wants to tell your story.
> http://p.sf.net/sfu/sf-spreadtheword_______________________________________________
> Simple-support mailing list
> Sim...@li...
> https://lists.sourceforge.net/lists/listinfo/simple-support
|
|
From: Wetmiller, E. <ewe...@ha...> - 2009-01-28 18:46:28
|
I am using SimpleXML version 2.0.2 and was wondering if there is a way
to set elementFormDefault="unqualified" on my schema. It appears that I
have to qualify all of the sub-elements in my schema. So, in other
words, when I set my root element namespace, ie @Namespace("pfx",
"namespace"), I have to use prefix for all sub-elements also. Any help
would be appreciated.
-Eric
|
|
From: <Nia...@ub...> - 2009-01-27 16:32:24
|
Visit our website at http://www.ubs.com This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mails are not encrypted and cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message which arise as a result of e-mail transmission. If verification is required please request a hard-copy version. This message is provided for informational purposes and should not be construed as a solicitation or offer to buy or sell any securities or related financial instruments. UBS Limited is a company registered in England & Wales under company number 2035362, whose registered office is at 1 Finsbury Avenue, London, EC2M 2PP, United Kingdom. UBS AG (London Branch) is registered as a branch of a foreign company under number BR004507, whose registered office is at 1 Finsbury Avenue, London, EC2M 2PP, United Kingdom. UBS Clearing and Execution Services Limited is a company registered in England & Wales under company number 03123037, whose registered office is at 1 Finsbury Avenue, London, EC2M 2PP, United Kingdom. |
|
From: Kevin D. <for...@tr...> - 2009-01-26 23:42:10
|
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<STYLE type=text/css> P, UL, OL, DL, DIR, MENU, PRE { margin: 0 auto;}</STYLE>
<META content="MSHTML 6.00.6000.16788" name=GENERATOR></HEAD>
<BODY leftMargin=1 topMargin=1 rightMargin=1><FONT face=Arial size=2>
<DIV>Ahh - it took a few seconds, but now I see what you are doing (an elegant hack!). It is interesting to me how many ways there are to solve a given problem.</DIV>
<DIV> </DIV>
<DIV>One issue with this approach: the fields still need to be marked as final, so I'm not sure how well this will work... Specifying final is important for concurrency reasons as well as ensuring the object is immutable, so I'm not crazy about having to drop the 'final' keyword.</DIV>
<DIV> </DIV>
<DIV>The ObjectInputStream has to be doing to really funky things to get those final fields specified.</DIV>
<DIV> </DIV>
<DIV>The whole Java object serialization approach with it's magic access to fields that it shouldn't, etc... has always bugged me. I'm cool with overriding visibility of a method, but to construct one out of thin air like that has always caused problems for me philosophically. If this is the approach we are forced into, I'd rather provide a private zero arg constructor so at least I'll know what's getting called (but then I run into the problem with the final fields, and the dependency injection needs still aren't addressed).</DIV>
<DIV> </DIV>
<DIV>- K</DIV>
<DIV> </DIV>
<DIV></DIV>
<DIV> </DIV></FONT>
<DIV style="FONT-SIZE: x-small; FONT-FAMILY: Tahoma">
<DIV>----------------------- <B>Original Message</B> -----------------------</DIV>
<DIV> </DIV>
<DIV><B>From:</B> Niall Gallagher <A href="mailto:gal...@ya..."><FONT color=#0000ff><gal...@ya...></FONT></A></DIV>
<DIV><B>To:</B> <A href="mailto:sim...@li..."><FONT color=#0000ff>sim...@li...,</FONT></A> Kevin Day <A href="mailto:for...@tr..."><FONT color=#0000ff><for...@tr...></FONT></A></DIV>
<DIV><B>Cc:</B> </DIV>
<DIV><B>Date:</B> Mon, 26 Jan 2009 11:40:50 -0800 (PST)</DIV>
<DIV><B>Subject: <U>Re: [Simple-support] Using constructors with arguments</U></B></DIV>
<DIV> </DIV></DIV><FONT face=Tahoma size=2>
<DIV>Hi,<BR><BR>Take a look at this. I will add this form of instantiation without a no-arg constructor in the next release.<BR><BR><A href="http://simple.svn.sourceforge.net/viewvc/simple/trunk/download/stream/src/test/java/org/simpleframework/xml/core/ObjectStreamClassTest.java?revision=1158&view=markup"><FONT color=#0000ff>http://simple.svn.sourceforge.net/viewvc/simple/trunk/download/stream/src/test/java/org/simpleframework/xml/core/ObjectStreamClassTest.java?revision=1158&view=markup</FONT></A><BR><BR>Let me know if this is suitable.<BR><BR>Niall<BR><BR><BR>--- On Mon, 1/26/09, Niall Gallagher <A href="mailto:gal...@ya..."><FONT color=#0000ff><gal...@ya...></FONT></A> wrote:<BR><BR>> From: Niall Gallagher <A href="mailto:gal...@ya..."><FONT color=#0000ff><gal...@ya...></FONT></A><BR>> Subject: Re: [Simple-support] Using constructors with arguments<BR>> To: <A href="mailto:simple-support@list
s.sourceforge.net"><FONT color=#0000ff>sim...@li...,</FONT></A> "Kevin Day" <A href="mailto:for...@tr..."><FONT color=#0000ff><for...@tr...></FONT></A><BR>> Date: Monday, January 26, 2009, 11:20 AM<BR>> Hi,<BR>> <BR>> Thanks for the feedback, if you have any suggestions I am<BR>> open to them. I was thinking of something like.<BR>> <BR>> <BR>> public class Tuple {<BR>> <BR>> @Attribute<BR>> private String name;<BR>> <BR>> @Element<BR>> private String value;<BR>> <BR>> public <A href="mailto:Tuple(@Inject"><FONT color=#0000ff>Tuple(@Inject</FONT></A> String name, @Inject String value)<BR>> {<BR>> this.name = name;<BR>> this.value =
value;<BR>> }<BR>> }<BR>> <BR>> This would make it readable and writable. Taking the<BR>> parameters and seeing where they can be injected. This would<BR>> be easy to write.<BR>> <BR>> Niall<BR>> <BR>> <BR>> --- On Mon, 1/26/09, Kevin Day<BR>> <A href="mailto:for...@tr..."><FONT color=#0000ff><for...@tr...></FONT></A> wrote:<BR>> <BR>> > From: Kevin Day <A href="mailto:for...@tr..."><FONT color=#0000ff><for...@tr...></FONT></A><BR>> > Subject: Re: [Simple-support] Using constructors with<BR>> arguments<BR>> > To: <A href="mailto:sim...@li..."><FONT color=#0000ff>sim...@li...</FONT></A><BR>> > Date: Monday, January 26, 2009, 10:51 AM<BR>> > Thanks for taking a look. I may be trying to use this<BR>> > framework for more than what it is intented to do. If<BR>
> you<BR>> > are interested in pursuing some use-cases, I'd be<BR>> happy<BR>> > to work with you on aspects of the design, etc... But<BR>> I<BR>> > also understand that different projects have different<BR>> > goals, and direct encapsulation of business layer<BR>> objects<BR>> > (which are more likely to be required to be immutable)<BR>> may<BR>> > not be part of the goal of Simple-XML.<BR>> > <BR>> > Using the @Commit or a combination of<BR>> @Replace/@Resolve<BR>> > requires an aweful lot of coding that it seems a<BR>> persistence<BR>> > framework could address... Coding with the @Commit,<BR>> etc...<BR>> > style is roughly similar to using a JAXB generated<BR>> object<BR>> > structure for persistence, then having a bunch of<BR>> > translators written to convert persistent values into<BR>> > business objects and vice-versa. It can be done, but<B
R>> > I'm looking for something a lot more elegant.<BR>> > <BR>> > <BR>> > I'm also fine with using a Strategy to achieve the<BR>> goal<BR>> > (I've implemented a really rough first cut at this<BR>> > already), but there may be a couple of challenges.<BR>> > <BR>> > As an example, my work so far indicates that the<BR>> Strategy<BR>> > interface can provide a hook for instantiation of<BR>> objects<BR>> > (i.e. via a factory that could use injected parameters<BR>> from<BR>> > a DI container) - however, unless I'm missing<BR>> something,<BR>> > it doesn't look like Strategy has access to the<BR>> Type<BR>> > objects generated from parsing the XML tree, which<BR>> means<BR>> > that I can't use objects recovered from the<BR>> > deserialization during instantiation. If the objects<BR>> are<BR>> > simple (String or something easily handled with the<BR>> &
gt; *Transform classes), then this is no big deal (we can<BR>> just<BR>> > instantiate from the Type object in the node map), but<BR>> for<BR>> > complicated objects, I'm not sure how to handle<BR>> it.<BR>> > <BR>> > This makes me wonder if I'm trying to get Strategy<BR>> to<BR>> > do something that it just isn't designed to do<BR>> (maybe<BR>> > this kind of thing should be implemented using a<BR>> different<BR>> > layer of the API), or if I can somehow use the map<BR>> passed<BR>> > into the getElement method to make this work.<BR>> > <BR>> > <BR>> > So, is it possible that the Instantiator class is the<BR>> place<BR>> > where this functionality needs to take place? If so,<BR>> then<BR>> > the Instantiator would need to have access to the<BR>> > deserialization's context during the call to<BR>> getType(). <BR>> > For example, if there were some way
to obtain named<BR>> Type<BR>> > objects for the fields/values of the object being<BR>> > deserialized? These could be used to instantiate<BR>> values<BR>> > that could then be passed to a factory or constructor.<BR>> I<BR>> > suspect this would involve making a read-only view of<BR>> the<BR>> > Collector available to Instantiator.<BR>> > <BR>> > I'm not sure how much control Simple has over the<BR>> > *order* that instantiation occurs in, or whether this<BR>> would<BR>> > impact things. It appears that Simple builds the Type<BR>> > hierarchy before it starts instantiating objects, so<BR>> that<BR>> > should be OK (unless there is a cyclic reference in<BR>> the<BR>> > constructor parameters - but that won't happen in<BR>> a well<BR>> > designed object hierarchy :-) )<BR>> > <BR>> > I'm wondering if you have a philosophical overview<BR>>
; of<BR>> > the Simple architecture captured anywhere? The<BR>> JavaDocs<BR>> > don't really provide a high level overview, and<BR>> the API<BR>> > has a *lot* of layers to it that make it difficult for<BR>> > someone new the source to get a handle on what types<BR>> of<BR>> > behavior should be implemented at which level. My<BR>> > assumption is that the system takes several logical<BR>> passes<BR>> > over the object hierarchy:<BR>> > <BR>> > Parse XML into nodes<BR>> > For each node, obtain it's Type (this is the job<BR>> of<BR>> > Strategy I think?)<BR>> > Determine the class for each Type and determine<BR>> it's<BR>> > fields/parameters/etc... and create Contacts for those<BR>> (this<BR>> > is the job of Scanner I think? And that interacts<BR>> with the<BR>> > Collector somehow)<BR>> > Use each Type to instantiate a concrete object and
<BR>> inject<BR>> > it into the Contacts (I think the Collector does this)<BR>> > <BR>> > Is that approximately correct?<BR>> > <BR>> > - K<BR>> > <BR>> > <BR>> > <BR>> > <BR>> > <BR>> > <BR>> > <BR>> > ----------------------- Original Message<BR>> > -----------------------<BR>> > <BR>> > From: <A href="mailto:Nia...@ub..."><FONT color=#0000ff><Nia...@ub...></FONT></A><BR>> > To: <A href="mailto:for...@tr..."><FONT color=#0000ff><for...@tr...>,</FONT></A><BR>> > <A href="mailto:sim...@li..."><FONT color=#0000ff><sim...@li...></FONT></A><BR>> > Cc: <BR>> > Date: Mon, 26 Jan 2009 09:11:54 -0000<BR>> > Subject: RE: [Simple-support] Using constructors with<BR>> > arguments<BR>> > <BR>> > Hi,<BR>> > <BR>
> > Ill take a look at the read resolve and write replace<BR>> > issues you<BR>> > mention. The reason @Replace and @Resolve do not work<BR>> in<BR>> > lists is they<BR>> > go through the Traverser object, rather than the<BR>> Composite<BR>> > object<BR>> > directly. This is something I will have to address. So<BR>> > there are two<BR>> > options, the first is to use a strategy (there should<BR>> be<BR>> > plenty of<BR>> > examples in the test cases), the second is to use<BR>> @Commit<BR>> > to build the<BR>> > Tuples like so. <BR>> > <BR>> > public class TupleDatabase {<BR>> > <BR>> > private List<Tuple> tuples;<BR>> > <BR>> > @ElementList<BR>> > private List<TupleEntry> entries;<BR>> > <BR>> > @Commit<BR>> > private void commit() {<BR>> > for(TupleEntry e
ntry : entries) {<BR>> > tuples.add(entry.name, entry.value);<BR>> > }<BR>> > }<BR>> > <BR>> > @Root<BR>> > private static class TupleEntry {<BR>> > @Element String name;<BR>> > @Element String value;<BR>> > }<BR>> > }<BR>> > <BR>> > Here when building the list you can create the tuples<BR>> > without a no-arg<BR>> > constructor.<BR>> > <BR>> > Hope this helps,<BR>> > Niall<BR>> > <BR>> > -----Original Message-----<BR>> > From: Kevin Day <A href="mailto:for...@tr..."><FONT color=#0000ff>[mailto:for...@tr...]</FONT></A> <BR>> > Sent: 24 January 2009 00:21<BR>> > To: <A href="mailto:sim...@li..."><FONT color=#0000ff>sim...@li...</FONT></A><B
R>> > Subject: Re: [Simple-support] Using constructors with<BR>> > arguments<BR>> > <BR>> > Thanks for the suggestion, this type of strategy is<BR>> exactly<BR>> > what we do<BR>> > with our current Java serialization based persistence,<BR>> so<BR>> > it's easy to<BR>> > relate to (even though there's a lot of duplicate<BR>> > code).<BR>> > <BR>> > <BR>> > For some reason, though, @Replace isn't working<BR>> (the<BR>> > getSubstitute()<BR>> > method is never called).<BR>> > <BR>> > After a bit of digging into the source, I think that<BR>> the<BR>> > problem is that<BR>> > the only place that Caller#replace() is actually<BR>> called is<BR>> > in<BR>> > Composite#writeReplace(). And that method is only<BR>> called<BR>> > for composite<BR>> > objects. We are dealing with a list of objects, so it<BR>> > seems that
maybe<BR>> > writeReplace() hasn't been properly implemented<BR>> for<BR>> > ElementList<BR>> > handlers?<BR>> > <BR>> > If I place my object outside the list (as part of a<BR>> > composite element),<BR>> > then it serializes fine.<BR>> > <BR>> > <BR>> > Another issue I'm running into is during<BR>> > deserialization. In this case,<BR>> > I am using @Resolve on the replaced object (which is<BR>> part<BR>> > of a composite<BR>> > object structure). I set a break point on<BR>> > Composite.readResolve(), but<BR>> > readResolve never gets called. The framework throws<BR>> an<BR>> > InstantiationException from Factory#getOverride().<BR>> > <BR>> > <BR>> > I'm not sure if the problem here is my lack of<BR>> > understanding of the API,<BR>> > or if this is just a corner case that didn't get<BR>> unit<BR>> > testing
written<BR>> > for it. I am attaching a self contained unit test<BR>> case<BR>> > that exhibits<BR>> > all of the above behavior. Please let me know if you<BR>> have<BR>> > any<BR>> > pointers/suggestions, or if I may just be missing<BR>> > something!<BR>> > <BR>> > Cheers,<BR>> > <BR>> > - Kevin<BR>> > <BR>> > <BR>> > PS - I suspect that the use of @Replace and @Resolve<BR>> may<BR>> > not solve our<BR>> > entire use case, but it is a great start at a solution<BR>> and<BR>> > is helping me<BR>> > understand the Simple framework better. Our ultimate<BR>> need<BR>> > also includes<BR>> > injection of resources via a DI framework, and I'm<BR>> > having a hard time<BR>> > figuring out how that's going to happen without<BR>> using<BR>> > some sort of<BR>> > factory instantiation strategy (I suppose that we<B
R>> could use<BR>> > a singleton<BR>> > to get the DI hook, but that's an anti-design<BR>> pattern<BR>> > that I really<BR>> > would prefer to avoid at all costs). Hopefully we can<BR>> > discuss this<BR>> > aspect a bit more after I understand why my @Replace<BR>> and<BR>> > @Resolve aren't<BR>> > working!<BR>> > <BR>> > <BR>> > <BR>> > <BR>> > <BR>> > ----------------------- Original Message<BR>> > -----------------------<BR>> > <BR>> > From: <A href="mailto:Nia...@ub..."><FONT color=#0000ff><Nia...@ub...></FONT></A><BR>> > To: <A href="mailto:for...@tr..."><FONT color=#0000ff><for...@tr...>,</FONT></A><BR>> > <A href="mailto:sim...@li..."><FONT color=#0000ff><sim...@li...></FONT></A><BR>> > Cc: <BR>> > Date: Thu, 22 Jan
2009 16:45:15 -0000<BR>> > Subject: RE: [Simple-support] Using constructors with<BR>> > arguments<BR>> > <BR>> > Hi,<BR>> > <BR>> > There is no need to do this. You can do the following.<BR>> > <BR>> > @Root<BR>> > public class Tuple {<BR>> > <BR>> > final private String from;<BR>> > final private String to;<BR>> > <BR>> > public Tuple(String from, String to){<BR>> > this.from = from;<BR>> > this.to = to;<BR>> > }<BR>> > <BR>> > @Replace<BR>> > private TupleSubstitute getSubstitute() {<BR>> > return new TupleSubstitute(from, to);<BR>> > }<BR>> > <BR>> > public String getFrom() {<BR>> > return from;<BR>> > }<BR>> > <BR>> > public String getTo() {<BR>> > return to;<BR>> > }<BR>> >
<BR>> > public String toString() {<BR>> > return from + " -> " + to;<BR>> > }<BR>> > <BR>> > }<BR>> > <BR>> > @Root<BR>> > private class TupleSubstitute {<BR>> > <BR>> > @Element<BR>> > private String from;<BR>> > @Element<BR>> > private String to;<BR>> > <BR>> > public TupleSubstitute() {<BR>> > super();<BR>> > }<BR>> > <BR>> > public TupleSubstitute(String from, String to) {<BR>> > this.from = from;<BR>> > this.to = to;<BR>> > }<BR>> > <BR>> > @Resolve<BR>> > public Tuple getTuple() {<BR>> > return new Tuple();<BR>> > }<BR>> > }<BR>> > <BR>> > This should work, for you. The @Resolve annotation<BR>> resolves<BR>> > the<BR>> > deserialized object before assigning it to the field<BR>> or<BR>> > method.
The<BR>> > @Replace object replaces the object in the stream.<BR>> Just<BR>> > like java object<BR>> > serialization. Let me know how this works out for you.<BR>> > <BR>> > Hope this helps,<BR>> > Niall<BR>> > <BR>> > <BR>> > <BR>> > -----Original Message-----<BR>> > From: Kevin Day <A href="mailto:for...@tr..."><FONT color=#0000ff>[mailto:for...@tr...]</FONT></A><BR>> > Sent: 21 January 2009 22:56<BR>> > To: Simple (Java Project)<BR>> > Subject: Re: [Simple-support] Using constructors with<BR>> > arguments<BR>> > <BR>> > I've done some additional work on handling classes<BR>> that<BR>> > do not have<BR>> > zero-arg constructors. First, I've put together<BR>> some<BR>> > simple sample code<BR>> > (attached, start with TryIt#main) that shows one of<BR>> the<BR>> > situations we<BR>> > are facing: w
e have a number of immutable Tuple<BR>> objects<BR>> > that we need to<BR>> > serialize/deserialze. The values used in the Tuple<BR>> > class' constructor<BR>> > come from attributes (or elements) from the XML. The<BR>> > attached<BR>> > serializes fine, but we can't deserialize it b/c<BR>> of the<BR>> > lack of<BR>> > no-argument constructor. We can't add a no-arg<BR>> > constructor because the<BR>> > class is intended to be immutable (in fact, the fields<BR>> are<BR>> > marked as<BR>> > final). In addition, the sample code shows the Tuple<BR>> > values as holding<BR>> > simple strings - but in our application, the values<BR>> are<BR>> > going to be<BR>> > complex objects.<BR>> > <BR>> > <BR>> > I have put together a Strategy and Type implementation<BR>> that<BR>> > *kind* of<BR>> > works, but I'm running into s
ome issues (may be<BR>> related<BR>> > to my lack of<BR>> > familiarity with the code base).<BR>> > <BR>> > The approach that I'm working on now creates a new<BR>> > Strategy that allows<BR>> > us to register special Type objects that can handle<BR>> object<BR>> > instantiation<BR>> > based on state of the deserialization process (for<BR>> now,<BR>> > I'm calling this<BR>> > FactoryGeneratedStrategy). Ideally,<BR>> > FactoryGeneratedStrategy would be<BR>> > able to inter-operate with any other Strategy<BR>> > (DefaultStrategy,<BR>> > CycleStrategy, TreeStrategy) - after all, it's<BR>> only<BR>> > purpose is to help<BR>> > instantiate objects during deserialization - the<BR>> behavior<BR>> > of the other<BR>> > strategies is still desirable.<BR>> > <BR>> > I ran into a couple of problems with this type of<BR>> Strategy<BR>> > ch
aining<BR>> > approach:<BR>> > <BR>> > 1. DefaultStrategy is not instantiable due to package<BR>> > scope visibility<BR>> > (this is the smaller issue) 2. The other strategies<BR>> appear<BR>> > to be<BR>> > implemented in a way that assumes use of zero-arg<BR>> > constructors. For<BR>> > example, CycleStrategy#getElement returns an Allocate<BR>> > object depending<BR>> > on the deserialization state. The Allocate object is<BR>> > ultimately backed<BR>> > by an Instance object as it's delegate Type. <BR>> Instance<BR>> > assumes a<BR>> > zero-arg constructor.<BR>> > <BR>> > <BR>> > Short of re-implementing all of the *Strategy classes,<BR>> I<BR>> > can't see how<BR>> > to go about providing a factory to create new object<BR>> > instances (without<BR>> > losing functionality provided by various Strategy<BR>> c
lasses).<BR>> > <BR>> > <BR>> > My initial impression based on the above is that<BR>> Strategy<BR>> > may not be the<BR>> > appropriate place in the hierarchy to add object<BR>> > instantiation behavior.<BR>> > If not, where? The Instantiator class seems a likely<BR>> > candidate, except<BR>> > that it's getInstace() method doesn't have<BR>> access<BR>> > to deserialization<BR>> > context information.<BR>> > <BR>> > <BR>> > <BR>> > Maybe I'm just going about this all wrong... If<BR>> anyone<BR>> > can provide some<BR>> > suggestions, I'd love to hear them!<BR>> > <BR>> > <BR>> > Thanks,<BR>> > <BR>> > - K<BR>> > <BR>> > <BR>> > ----------------------- Original Message<BR>> > -----------------------<BR>> > <BR>> > From: Kevin Day <A href="mailto:ke...@tr..."><FONT color=#0000ff><
;ke...@tr...></FONT></A><BR>> > To: Simple (Java Project)<BR>> > <A href="mailto:sim...@li..."><FONT color=#0000ff><sim...@li...></FONT></A><BR>> > Cc: <BR>> > Date: Tue, 20 Jan 2009 17:28:05 -0700<BR>> > Subject: [Simple-support] Using constructors with<BR>> arguments<BR>> > <BR>> > For starters, I really like what I see in this project<BR>> > (just started<BR>> > reviewing it this afternoon). I'm hoping that I<BR>> can<BR>> > get some pointers<BR>> > on a specific use-case.<BR>> > <BR>> > <BR>> > I would like to use Simple in conjunction with a<BR>> dependency<BR>> > injection<BR>> > system (probably Guice) and List implementations from<BR>> the<BR>> > GlazedLists<BR>> > project.<BR>> > <BR>> > We have to use a constructor on our list<BR>> implementations<BR>> > t
hat contains<BR>> > arguments (some of the arguments provided by Guice,<BR>> some<BR>> > from element or<BR>> > attribute data in the XML).<BR>> > <BR>> > What is the best way to approach this with Simple?<BR>> > <BR>> > It seems that some sort of Strategy mixed with a<BR>> custom<BR>> > Type is in<BR>> > order, but I'm not entirely clear on the best<BR>> approach.<BR>> > The<BR>> > architecture of the framework looks powerful enough to<BR>> do<BR>> > what we need,<BR>> > but I can't see where to get started just yet.<BR>> > <BR>> > <BR>> > To give a pseudo-code example of what we are trying to<BR>> do<BR>> > (in real life,<BR>> > we'll be injecting SomeInjectedObject using Guice<BR>> or a<BR>> > factory/service<BR>> > provider call):<BR>> > <BR>> > class SpecialList<E>{<BR>> > public SpecialList(SomeInjectedO
bject injected, String<BR>> > valueFromAttribute, SomeObject valueFromElement){ ...<BR>> > }<BR>> > }<BR>> > <BR>> > <BR>> > class MyObject{<BR>> > @ElementList<BR>> > SpecialList<ElementObject> list = new<BR>> ><BR>> SpecialList<ElementObject>(SomeInjectedObject.defaultInstance,<BR>> > "test",<BR>> > new SomeObject());<BR>> > <BR>> > }<BR>> > <BR>> > <BR>> > When we serialize this with Simple, we'd like to<BR>> see<BR>> > something<BR>> > approximately like the following:<BR>> > <BR>> > <myObject valueFromAttribute="test"><BR>> > <someObject> ... </someObject><BR>> > <list><BR>> > <elementObject> ... whatever goes into this ...<BR>> > </elementObject><BR>> > <elementObject> ... whatever goes into this ...<BR>> > </elementObject> ...<BR>> >
; </list><BR>> > </myObject><BR>> > <BR>> > <BR>> > Note that:<BR>> > <BR>> > 1. The <list> element doesn't have a class<BR>> > attribute 2. When we<BR>> > construct the list during deserialization, we need to<BR>> be<BR>> > able to pull<BR>> > the 'valueFromAttribute' and<BR>> 'someObject'<BR>> > values to use during<BR>> > construction of the SpecialList object 3. The<BR>> SpecialList<BR>> > object needs<BR>> > to have the 3 argument constructor called (not a<BR>> zero-arg<BR>> > constructor).<BR>> > And it is not possible to call a zero arg constructor,<BR>> then<BR>> > modify the<BR>> > object afterwards to get the same result.<BR>> > <BR>> > <BR>> > Any pointers? I may be pushing the framework too hard<BR>> > (some of the<BR>> > above requirements can be relaxed - if it isn't<BR
>> > possible to obtain<BR>> > valueFromAttribute or someObject at construction time,<BR>> we<BR>> > can find<BR>> > workarounds - but we have to be able to create the<BR>> > SpecialList instance<BR>> > using values from a factory/Guice/etc...). For what<BR>> > it's worth, we have<BR>> > this type of behavior working in Betwixt using custom<BR>> > BeanCreator<BR>> > implementations.<BR>> > <BR>> > Thanks much,<BR>> > <BR>> > - Kevin<BR>> ><BR>> ------------------------------------------------------------------------<BR>> > ------<BR>> > This SF.net email is sponsored by:<BR>> > SourcForge Community<BR>> > SourceForge wants to tell your story.<BR>> > <A href="http://p.sf.net/sfu/sf-spreadtheword"><FONT color=#0000ff>http://p.sf.net/sfu/sf-spreadtheword</FONT></A><BR>> > <BR>> > <BR>> > ___________________________________________
____<BR>> > Simple-support mailing list<BR>> > <A href="mailto:Sim...@li..."><FONT color=#0000ff>Sim...@li...</FONT></A><BR>> ><BR>> <A href="https://lists.sourceforge.net/lists/listinfo/simple-support"><FONT color=#0000ff>https://lists.sourceforge.net/lists/listinfo/simple-support</FONT></A><BR>> > Visit our website at <A href="http://www.ubs.com"><FONT color=#0000ff>http://www.ubs.com</FONT></A><BR>> > <BR>> > This message contains confidential information and is<BR>> > intended only for<BR>> > the individual named. If you are not the named<BR>> addressee<BR>> > you should not<BR>> > disseminate, distribute or copy this e-mail. Please<BR>> notify<BR>> > the sender<BR>> > immediately by e-mail if you have received this e-mail<BR>> by<BR>> > mistake and<BR>> > delete this e-mail from your system.<BR>> > <BR>&g
t; > E-mails are not encrypted and cannot be guaranteed to<BR>> be<BR>> > secure or<BR>> > error-free as information could be intercepted,<BR>> corrupted,<BR>> > lost,<BR>> > destroyed, arrive late or incomplete, or contain<BR>> viruses. <BR>> > The sender<BR>> > therefore does not accept liability for any errors or<BR>> > omissions in the<BR>> > contents of this message which arise as a result of<BR>> e-mail<BR>> > transmission.<BR>> > <BR>> > If verification is required please request a hard-copy<BR>> > version. This<BR>> > message is provided for informational purposes and<BR>> should<BR>> > not be<BR>> > construed as a solicitation or offer to buy or sell<BR>> any<BR>> > securities or<BR>> > related financial instruments.<BR>> > <BR>> > UBS Limited is a company registered in England &<BR>> Wales<BR>> > under company<BR>
> > number 2035362, whose registered office is at 1<BR>> Finsbury<BR>> > Avenue, London,<BR>> > EC2M 2PP, United Kingdom.<BR>> > <BR>> > UBS AG (London Branch) is registered as a branch of a<BR>> > foreign company<BR>> > under number BR004507, whose registered office is at<BR>> > 1 Finsbury Avenue, London, EC2M 2PP, United Kingdom.<BR>> > <BR>> > UBS Clearing and Execution Services Limited is a<BR>> company<BR>> > registered in<BR>> > England & Wales under company number 03123037,<BR>> whose<BR>> > registered office<BR>> > is at 1 Finsbury Avenue, London, EC2M 2PP, United<BR>> Kingdom.<BR>> > Visit our website at <A href="http://www.ubs.com"><FONT color=#0000ff>http://www.ubs.com</FONT></A><BR>> > <BR>> > This message contains confidential information and is<BR>> > intended only <BR>> > for the individual named. If you are not the named<BR>&
gt; > addressee you <BR>> > should not disseminate, distribute or copy this<BR>> e-mail. <BR>> > Please <BR>> > notify the sender immediately by e-mail if you have<BR>> > received this <BR>> > e-mail by mistake and delete this e-mail from your<BR>> system.<BR>> > <BR>> > E-mails are not encrypted and cannot be guaranteed to<BR>> be<BR>> > secure or <BR>> > error-free as information could be intercepted,<BR>> corrupted,<BR>> > lost, <BR>> > destroyed, arrive late or incomplete, or contain<BR>> viruses. <BR>> > The sender <BR>> > therefore does not accept liability for any errors or<BR>> > omissions in the <BR>> > contents of this message which arise as a result of<BR>> e-mail<BR>> > transmission. <BR>> > If verification is required please request a hard-copy<BR>> > version. This <BR>> > message is provided for inf
ormational purposes and<BR>> should<BR>> > not be <BR>> > construed as a solicitation or offer to buy or sell<BR>> any<BR>> > securities <BR>> > or related financial instruments.<BR>> > <BR>> > UBS Limited is a company registered in England &<BR>> Wales<BR>> > under company<BR>> > number 2035362, whose registered office is at 1<BR>> Finsbury<BR>> > Avenue,<BR>> > London, EC2M 2PP, United Kingdom.<BR>> > <BR>> > UBS AG (London Branch) is registered as a branch of a<BR>> > foreign company<BR>> > under number BR004507, whose registered office is at<BR>> > 1 Finsbury Avenue, London, EC2M 2PP, United Kingdom.<BR>> > <BR>> > UBS Clearing and Execution Services Limited is a<BR>> company<BR>> > registered<BR>> > in England & Wales under company number 03123037,<BR>> whose<BR>> > registered<BR>> > office is at 1 Finsbury Avenue, Londo
n, EC2M 2PP,<BR>> United<BR>> > Kingdom.<BR>> > <BR>> ><BR>> ------------------------------------------------------------------------------<BR>> > This SF.net email is sponsored by:<BR>> > SourcForge Community<BR>> > SourceForge wants to tell your story.<BR>> > <A href="http://p.sf.net/sfu/sf-spreadtheword"><FONT color=#0000ff>http://p.sf.net/sfu/sf-spreadtheword</FONT></A><BR>> > _______________________________________________<BR>> > Simple-support mailing list<BR>> > <A href="mailto:Sim...@li..."><FONT color=#0000ff>Sim...@li...</FONT></A><BR>> ><BR>> <A href="https://lists.sourceforge.net/lists/listinfo/simple-support"><FONT color=#0000ff>https://lists.sourceforge.net/lists/listinfo/simple-support</FONT></A><BR>> <BR>> <BR>> <BR>> <BR>> -----------------------------------------------------------------
-------------<BR>> This SF.net email is sponsored by:<BR>> SourcForge Community<BR>> SourceForge wants to tell your story.<BR>> <A href="http://p.sf.net/sfu/sf-spreadtheword"><FONT color=#0000ff>http://p.sf.net/sfu/sf-spreadtheword</FONT></A><BR>> _______________________________________________<BR>> Simple-support mailing list<BR>> <A href="mailto:Sim...@li..."><FONT color=#0000ff>Sim...@li...</FONT></A><BR>> <A href="https://lists.sourceforge.net/lists/listinfo/simple-support"><FONT color=#0000ff>https://lists.sourceforge.net/lists/listinfo/simple-support</FONT></A><BR><BR><BR> <BR><BR></DIV></FONT></BODY></HTML>
|
|
From: Kevin D. <for...@tr...> - 2009-01-26 22:52:12
|
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<STYLE type=text/css> P, UL, OL, DL, DIR, MENU, PRE { margin: 0 auto;}</STYLE>
<META content="MSHTML 6.00.6000.16788" name=GENERATOR></HEAD>
<BODY leftMargin=1 topMargin=1 rightMargin=1><FONT face=Arial size=2>
<DIV>Yes - this works. As long as the private constructor calls a public constructor somehow, there won't be problems with inheritence... Plus we have to lose the 'final' keyword. I'm willing to compromise on that (though I'd prefer not to), as long as we can get the dependency injection working. My final concern here is that there are a number of frameworks we use where object creation is always done via factory method (JSR 295 bindings, for example). In these cases, attempting to get a private zero-arg constructor into the class just won't work - there are a lot of things going on in the factory method that still need to be done. It's easy to develop a factory proxy that has the correct annotations in it to support Simple, but trying to get Simple to construct those objects directly seems like a very difficult challenge.</DIV>
<DIV> </DIV>
<DIV>One other advantage of having a registered factory for creating objects is that it opens up the possibility of seriliazing/deserializing objects that we don't control the source of (i.e. where we can't add annotations).</DIV>
<DIV> </DIV>
<DIV>By the way, in case I haven't mentioned it, I *really* appreciate your taking the time to correspond with my about this. I am a contributor to a number of OS projects and a maintainer on one, and I know that it can be tough to get input from someone that doesn't understand the API very well. Thanks for your patience on anything that I'm oversimplifying. I am so enamored with the general strategy that you have used here that I really want to be able to use Simple for our next project.</DIV>
<DIV> </DIV>
<DIV>- K</DIV>
<DIV></DIV>
<DIV> </DIV></FONT>
<DIV style="FONT-SIZE: x-small; FONT-FAMILY: Tahoma">
<DIV>----------------------- <B>Original Message</B> -----------------------</DIV>
<DIV> </DIV>
<DIV><B>From:</B> Niall Gallagher <A href="mailto:gal...@ya..."><FONT color=#0000ff><gal...@ya...></FONT></A></DIV>
<DIV><B>To:</B> <A href="mailto:sim...@li..."><FONT color=#0000ff>sim...@li...,</FONT></A> Kevin Day <A href="mailto:for...@tr..."><FONT color=#0000ff><for...@tr...></FONT></A></DIV>
<DIV><B>Cc:</B> </DIV>
<DIV><B>Date:</B> Mon, 26 Jan 2009 11:43:35 -0800 (PST)</DIV>
<DIV><B>Subject: <U>Re: [Simple-support] Using constructors with arguments</U></B></DIV>
<DIV> </DIV></DIV><FONT face=Tahoma size=2>
<DIV>Hi,<BR><BR>Also, just to mention you can do this.<BR><BR>public class Tuple {<BR><BR> private Tuple() {<BR> super();<BR> }<BR><BR> // etc...<BR>}<BR><BR>Private no-arg constructors will also get invoked.<BR><BR>Niall<BR><BR><BR>--- On Mon, 1/26/09, Niall Gallagher <A href="mailto:gal...@ya..."><FONT color=#0000ff><gal...@ya...></FONT></A> wrote:<BR><BR>> From: Niall Gallagher <A href="mailto:gal...@ya..."><FONT color=#0000ff><gal...@ya...></FONT></A><BR>> Subject: Re: [Simple-support] Using constructors with arguments<BR>> To: <A href="mailto:sim...@li..."><FONT color=#0000ff>sim...@li...,</FONT></A> "Kevin Day" <A href="mailto:for...@tr..."><FONT color=#0000ff><for...@tr...></FONT></A><BR>> Date: Monday, January 26, 2009, 11:40 AM<BR>> Hi,<BR>> <BR>> Take a look at this. I
will add this form of instantiation<BR>> without a no-arg constructor in the next release.<BR>> <BR>> <A href="http://simple.svn.sourceforge.net/viewvc/simple/trunk/download/stream/src/test/java/org/simpleframework/xml/core/ObjectStreamClassTest.java?revision=1158&view=markup"><FONT color=#0000ff>http://simple.svn.sourceforge.net/viewvc/simple/trunk/download/stream/src/test/java/org/simpleframework/xml/core/ObjectStreamClassTest.java?revision=1158&view=markup</FONT></A><BR>> <BR>> Let me know if this is suitable.<BR>> <BR>> Niall<BR>> <BR>> <BR>> --- On Mon, 1/26/09, Niall Gallagher<BR>> <A href="mailto:gal...@ya..."><FONT color=#0000ff><gal...@ya...></FONT></A> wrote:<BR>> <BR>> > From: Niall Gallagher<BR>> <A href="mailto:gal...@ya..."><FONT color=#0000ff><gal...@ya...></FONT></A><BR>> > Subject: Re: [Simple-support] Using constructors with<BR>> ar
guments<BR>> > To: <A href="mailto:sim...@li..."><FONT color=#0000ff>sim...@li...,</FONT></A> "Kevin<BR>> Day" <A href="mailto:for...@tr..."><FONT color=#0000ff><for...@tr...></FONT></A><BR>> > Date: Monday, January 26, 2009, 11:20 AM<BR>> > Hi,<BR>> > <BR>> > Thanks for the feedback, if you have any suggestions I<BR>> am<BR>> > open to them. I was thinking of something like.<BR>> > <BR>> > <BR>> > public class Tuple {<BR>> > <BR>> > @Attribute<BR>> > private String name;<BR>> > <BR>> > @Element<BR>> > private String value;<BR>> > <BR>> > public <A href="mailto:Tuple(@Inject"><FONT color=#0000ff>Tuple(@Inject</FONT></A> String name, @Inject String<BR>
> value)<BR>> > {<BR>> > this.name = name;<BR>> > this.value = value;<BR>> > }<BR>> > }<BR>> > <BR>> > This would make it readable and writable. Taking the<BR>> > parameters and seeing where they can be injected. This<BR>> would<BR>> > be easy to write.<BR>> > <BR>> > Niall<BR>> > <BR>> > <BR>> > --- On Mon, 1/26/09, Kevin Day<BR>> > <A href="mailto:for...@tr..."><FONT color=#0000ff><for...@tr...></FONT></A> wrote:<BR>> > <BR>> > > From: Kevin Day <A href="mailto:for...@tr..."><FONT color=#0000ff><for...@tr...></FONT></A><BR>> > > Subject: Re: [Simple-support] Using constructors<BR>> with<BR>> > arguments<BR>> > > To: <A href="mailto:sim...@li...
rge.net"><FONT color=#0000ff>sim...@li...</FONT></A><BR>> > > Date: Monday, January 26, 2009, 10:51 AM<BR>> > > Thanks for taking a look. I may be trying to use<BR>> this<BR>> > > framework for more than what it is intented to<BR>> do. If<BR>> > you<BR>> > > are interested in pursuing some use-cases,<BR>> I'd be<BR>> > happy<BR>> > > to work with you on aspects of the design, etc...<BR>> But<BR>> > I<BR>> > > also understand that different projects have<BR>> different<BR>> > > goals, and direct encapsulation of business layer<BR>> > objects<BR>> > > (which are more likely to be required to be<BR>> immutable)<BR>> > may<BR>> > > not be part of the goal of Simple-XML.<BR>> > > <BR>> > > Using the @Commit or a combination of<BR>> > @Replace/@Resolve<BR>> > > requires an aweful
lot of coding that it seems a<BR>> > persistence<BR>> > > framework could address... Coding with the<BR>> @Commit,<BR>> > etc...<BR>> > > style is roughly similar to using a JAXB<BR>> generated<BR>> > object<BR>> > > structure for persistence, then having a bunch of<BR>> > > translators written to convert persistent values<BR>> into<BR>> > > business objects and vice-versa. It can be done,<BR>> but<BR>> > > I'm looking for something a lot more elegant.<BR>> > > <BR>> > > <BR>> > > I'm also fine with using a Strategy to<BR>> achieve the<BR>> > goal<BR>> > > (I've implemented a really rough first cut at<BR>> this<BR>> > > already), but there may be a couple of<BR>> challenges.<BR>> > > <BR>> > > As an example, my work so far indicates that the<BR>> > Strategy<BR>> > > interface can provide a
hook for instantiation of<BR>> > objects<BR>> > > (i.e. via a factory that could use injected<BR>> parameters<BR>> > from<BR>> > > a DI container) - however, unless I'm missing<BR>> > something,<BR>> > > it doesn't look like Strategy has access to<BR>> the<BR>> > Type<BR>> > > objects generated from parsing the XML tree,<BR>> which<BR>> > means<BR>> > > that I can't use objects recovered from the<BR>> > > deserialization during instantiation. If the<BR>> objects<BR>> > are<BR>> > > simple (String or something easily handled with<BR>> the<BR>> > > *Transform classes), then this is no big deal (we<BR>> can<BR>> > just<BR>> > > instantiate from the Type object in the node<BR>> map), but<BR>> > for<BR>> > > complicated objects, I'm not sure how to<BR>> handle<BR>> > it.<BR>> > > <BR>> > >
This makes me wonder if I'm trying to get<BR>> Strategy<BR>> > to<BR>> > > do something that it just isn't designed to<BR>> do<BR>> > (maybe<BR>> > > this kind of thing should be implemented using a<BR>> > different<BR>> > > layer of the API), or if I can somehow use the<BR>> map<BR>> > passed<BR>> > > into the getElement method to make this work.<BR>> > > <BR>> > > <BR>> > > So, is it possible that the Instantiator class is<BR>> the<BR>> > place<BR>> > > where this functionality needs to take place? If<BR>> so,<BR>> > then<BR>> > > the Instantiator would need to have access to the<BR>> > > deserialization's context during the call to<BR>> > getType(). <BR>> > > For example, if there were some way to obtain<BR>> named<BR>> > Type<BR>> > > objects for the fields/values of the object being<BR>> &g
t; > deserialized? These could be used to instantiate<BR>> > values<BR>> > > that could then be passed to a factory or<BR>> constructor.<BR>> > I<BR>> > > suspect this would involve making a read-only<BR>> view of<BR>> > the<BR>> > > Collector available to Instantiator.<BR>> > > <BR>> > > I'm not sure how much control Simple has over<BR>> the<BR>> > > *order* that instantiation occurs in, or whether<BR>> this<BR>> > would<BR>> > > impact things. It appears that Simple builds the<BR>> Type<BR>> > > hierarchy before it starts instantiating objects,<BR>> so<BR>> > that<BR>> > > should be OK (unless there is a cyclic reference<BR>> in<BR>> > the<BR>> > > constructor parameters - but that won't<BR>> happen in<BR>> > a well<BR>> > > designed object hierarchy :-) )<BR>> > > <BR>> &
gt; > I'm wondering if you have a philosophical<BR>> overview<BR>> > of<BR>> > > the Simple architecture captured anywhere? The<BR>> > JavaDocs<BR>> > > don't really provide a high level overview,<BR>> and<BR>> > the API<BR>> > > has a *lot* of layers to it that make it<BR>> difficult for<BR>> > > someone new the source to get a handle on what<BR>> types<BR>> > of<BR>> > > behavior should be implemented at which level. <BR>> My<BR>> > > assumption is that the system takes several<BR>> logical<BR>> > passes<BR>> > > over the object hierarchy:<BR>> > > <BR>> > > Parse XML into nodes<BR>> > > For each node, obtain it's Type (this is the<BR>> job<BR>> > of<BR>> > > Strategy I think?)<BR>> > > Determine the class for each Type and determine<BR>> > it's<BR>> > > fields/parameters/etc... and crea
te Contacts for<BR>> those<BR>> > (this<BR>> > > is the job of Scanner I think? And that<BR>> interacts<BR>> > with the<BR>> > > Collector somehow)<BR>> > > Use each Type to instantiate a concrete object<BR>> and<BR>> > inject<BR>> > > it into the Contacts (I think the Collector does<BR>> this)<BR>> > > <BR>> > > Is that approximately correct?<BR>> > > <BR>> > > - K<BR>> > > <BR>> > > <BR>> > > <BR>> > > <BR>> > > <BR>> > > <BR>> > > <BR>> > > ----------------------- Original Message<BR>> > > -----------------------<BR>> > > <BR>> > > From: <A href="mailto:Nia...@ub..."><FONT color=#0000ff><Nia...@ub...></FONT></A><BR>> > > To: <A href="mailto:for...@tr..."><FONT color=#0000ff><for...@tr...>,</FO
NT></A><BR>> > > <A href="mailto:sim...@li..."><FONT color=#0000ff><sim...@li...></FONT></A><BR>> > > Cc: <BR>> > > Date: Mon, 26 Jan 2009 09:11:54 -0000<BR>> > > Subject: RE: [Simple-support] Using constructors<BR>> with<BR>> > > arguments<BR>> > > <BR>> > > Hi,<BR>> > > <BR>> > > Ill take a look at the read resolve and write<BR>> replace<BR>> > > issues you<BR>> > > mention. The reason @Replace and @Resolve do not<BR>> work<BR>> > in<BR>> > > lists is they<BR>> > > go through the Traverser object, rather than the<BR>> > Composite<BR>> > > object<BR>> > > directly. This is something I will have to<BR>> address. So<BR>> > > there are two<BR>> > > options, the first is to use a strategy (there<BR>> should<BR>> > be<BR>> > > p
lenty of<BR>> > > examples in the test cases), the second is to use<BR>> > @Commit<BR>> > > to build the<BR>> > > Tuples like so. <BR>> > > <BR>> > > public class TupleDatabase {<BR>> > > <BR>> > > private List<Tuple> tuples;<BR>> > > <BR>> > > @ElementList<BR>> > > private List<TupleEntry> entries;<BR>> > > <BR>> > > @Commit<BR>> > > private void commit() {<BR>> > > for(TupleEntry entry : entries) {<BR>> > > tuples.add(entry.name, entry.value);<BR>> > > }<BR>> > > }<BR>> > > <BR>> > > @Root<BR>> > > private static class TupleEntry {<BR>> > > @Element String name;<BR>> > > @Elemen
t String value;<BR>> > > }<BR>> > > }<BR>> > > <BR>> > > Here when building the list you can create the<BR>> tuples<BR>> > > without a no-arg<BR>> > > constructor.<BR>> > > <BR>> > > Hope this helps,<BR>> > > Niall<BR>> > > <BR>> > > -----Original Message-----<BR>> > > From: Kevin Day <A href="mailto:for...@tr..."><FONT color=#0000ff>[mailto:for...@tr...]</FONT></A><BR>> <BR>> > > Sent: 24 January 2009 00:21<BR>> > > To: <A href="mailto:sim...@li..."><FONT color=#0000ff>sim...@li...</FONT></A><BR>> > > Subject: Re: [Simple-support] Using constructors<BR>> with<BR>> > > arguments<BR>> > > <BR>> > > Thanks for the suggestion, this type of strategy<BR>> is<BR>> > exactly<BR>> > > what we do<BR>> > > with ou
r current Java serialization based<BR>> persistence,<BR>> > so<BR>> > > it's easy to<BR>> > > relate to (even though there's a lot of<BR>> duplicate<BR>> > > code).<BR>> > > <BR>> > > <BR>> > > For some reason, though, @Replace isn't<BR>> working<BR>> > (the<BR>> > > getSubstitute()<BR>> > > method is never called).<BR>> > > <BR>> > > After a bit of digging into the source, I think<BR>> that<BR>> > the<BR>> > > problem is that<BR>> > > the only place that Caller#replace() is actually<BR>> > called is<BR>> > > in<BR>> > > Composite#writeReplace(). And that method is<BR>> only<BR>> > called<BR>> > > for composite<BR>> > > objects. We are dealing with a list of objects,<BR>> so it<BR>> > > seems that maybe<BR>> > > writeReplace() hasn't been properly<BR>> i
mplemented<BR>> > for<BR>> > > ElementList<BR>> > > handlers?<BR>> > > <BR>> > > If I place my object outside the list (as part of<BR>> a<BR>> > > composite element),<BR>> > > then it serializes fine.<BR>> > > <BR>> > > <BR>> > > Another issue I'm running into is during<BR>> > > deserialization. In this case,<BR>> > > I am using @Resolve on the replaced object (which<BR>> is<BR>> > part<BR>> > > of a composite<BR>> > > object structure). I set a break point on<BR>> > > Composite.readResolve(), but<BR>> > > readResolve never gets called. The framework<BR>> throws<BR>> > an<BR>> > > InstantiationException from<BR>> Factory#getOverride().<BR>> > > <BR>> > > <BR>> > > I'm not sure if the problem here is my lack<BR>> of<BR>> > > understanding of the API
,<BR>> > > or if this is just a corner case that didn't<BR>> get<BR>> > unit<BR>> > > testing written<BR>> > > for it. I am attaching a self contained unit<BR>> test<BR>> > case<BR>> > > that exhibits<BR>> > > all of the above behavior. Please let me know if<BR>> you<BR>> > have<BR>> > > any<BR>> > > pointers/suggestions, or if I may just be missing<BR>> > > something!<BR>> > > <BR>> > > Cheers,<BR>> > > <BR>> > > - Kevin<BR>> > > <BR>> > > <BR>> > > PS - I suspect that the use of @Replace and<BR>> @Resolve<BR>> > may<BR>> > > not solve our<BR>> > > entire use case, but it is a great start at a<BR>> solution<BR>> > and<BR>> > > is helping me<BR>> > > understand the Simple framework better. Our<BR>> ultimate<BR>> > need<BR>> > >
also includes<BR>> > > injection of resources via a DI framework, and<BR>> I'm<BR>> > > having a hard time<BR>> > > figuring out how that's going to happen<BR>> without<BR>> > using<BR>> > > some sort of<BR>> > > factory instantiation strategy (I suppose that we<BR>> > could use<BR>> > > a singleton<BR>> > > to get the DI hook, but that's an anti-design<BR>> > pattern<BR>> > > that I really<BR>> > > would prefer to avoid at all costs). Hopefully<BR>> we can<BR>> > > discuss this<BR>> > > aspect a bit more after I understand why my<BR>> @Replace<BR>> > and<BR>> > > @Resolve aren't<BR>> > > working!<BR>> > > <BR>> > > <BR>> > > <BR>> > > <BR>> > > <BR>> > > ----------------------- Original Message<BR>> > > -----------------------<BR>> > > <BR>> &
gt; > From: <A href="mailto:Nia...@ub..."><FONT color=#0000ff><Nia...@ub...></FONT></A><BR>> > > To: <A href="mailto:for...@tr..."><FONT color=#0000ff><for...@tr...>,</FONT></A><BR>> > > <A href="mailto:sim...@li..."><FONT color=#0000ff><sim...@li...></FONT></A><BR>> > > Cc: <BR>> > > Date: Thu, 22 Jan 2009 16:45:15 -0000<BR>> > > Subject: RE: [Simple-support] Using constructors<BR>> with<BR>> > > arguments<BR>> > > <BR>> > > Hi,<BR>> > > <BR>> > > There is no need to do this. You can do the<BR>> following.<BR>> > > <BR>> > > @Root<BR>> > > public class Tuple {<BR>> > > <BR>> > > final private String from;<BR>> > > final private String to;<BR>> > > <BR>> > > public Tuple(String from, String to
){<BR>> > > this.from = from;<BR>> > > this.to = to;<BR>> > > }<BR>> > > <BR>> > > @Replace<BR>> > > private TupleSubstitute getSubstitute() {<BR>> > > return new TupleSubstitute(from, to);<BR>> > > }<BR>> > > <BR>> > > public String getFrom() {<BR>> > > return from;<BR>> > > }<BR>> > > <BR>> > > public String getTo() {<BR>> > > return to;<BR>> > > }<BR>> > > <BR>> > > public String toString() {<BR>> > > return from + " -> " + to;<BR>> > > }<BR>> > > <BR>> > > }<BR>> > > <BR>> > > @Root<BR>> > > private class TupleSubstitute {<BR>> > > <BR>> > > @Element<BR>> > > private String from;<BR>&g
t; > > @Element<BR>> > > private String to;<BR>> > > <BR>> > > public TupleSubstitute() {<BR>> > > super();<BR>> > > }<BR>> > > <BR>> > > public TupleSubstitute(String from, String to) {<BR>> > > this.from = from;<BR>> > > this.to = to;<BR>> > > }<BR>> > > <BR>> > > @Resolve<BR>> > > public Tuple getTuple() {<BR>> > > return new Tuple();<BR>> > > }<BR>> > > }<BR>> > > <BR>> > > This should work, for you. The @Resolve<BR>> annotation<BR>> > resolves<BR>> > > the<BR>> > > deserialized object before assigning it to the<BR>> field<BR>> > or<BR>> > > method. The<BR>> > > @Replace object replaces the object in the<BR>> stream.<BR>> > Just<BR>> > > like java object<BR>> > > serialization. L
et me know how this works out for<BR>> you.<BR>> > > <BR>> > > Hope this helps,<BR>> > > Niall<BR>> > > <BR>> > > <BR>> > > <BR>> > > -----Original Message-----<BR>> > > From: Kevin Day <A href="mailto:for...@tr..."><FONT color=#0000ff>[mailto:for...@tr...]</FONT></A><BR>> > > Sent: 21 January 2009 22:56<BR>> > > To: Simple (Java Project)<BR>> > > Subject: Re: [Simple-support] Using constructors<BR>> with<BR>> > > arguments<BR>> > > <BR>> > > I've done some additional work on handling<BR>> classes<BR>> > that<BR>> > > do not have<BR>> > > zero-arg constructors. First, I've put<BR>> together<BR>> > some<BR>> > > simple sample code<BR>> > > (attached, start with TryIt#main) that shows one<BR>> of<BR>> > the<BR>> > > situations we<BR>> > >
are facing: we have a number of immutable Tuple<BR>> > objects<BR>> > > that we need to<BR>> > > serialize/deserialze. The values used in the<BR>> Tuple<BR>> > > class' constructor<BR>> > > come from attributes (or elements) from the XML. <BR>> The<BR>> > > attached<BR>> > > serializes fine, but we can't deserialize it<BR>> b/c<BR>> > of the<BR>> > > lack of<BR>> > > no-argument constructor. We can't add a<BR>> no-arg<BR>> > > constructor because the<BR>> > > class is intended to be immutable (in fact, the<BR>> fields<BR>> > are<BR>> > > marked as<BR>> > > final). In addition, the sample code shows the<BR>> Tuple<BR>> > > values as holding<BR>> > > simple strings - but in our application, the<BR>> values<BR>> > are<BR>> > > going to be<BR>> > > complex objects.<BR>> &
gt; > <BR>> > > <BR>> > > I have put together a Strategy and Type<BR>> implementation<BR>> > that<BR>> > > *kind* of<BR>> > > works, but I'm running into some issues (may<BR>> be<BR>> > related<BR>> > > to my lack of<BR>> > > familiarity with the code base).<BR>> > > <BR>> > > The approach that I'm working on now creates<BR>> a new<BR>> > > Strategy that allows<BR>> > > us to register special Type objects that can<BR>> handle<BR>> > object<BR>> > > instantiation<BR>> > > based on state of the deserialization process<BR>> (for<BR>> > now,<BR>> > > I'm calling this<BR>> > > FactoryGeneratedStrategy). Ideally,<BR>> > > FactoryGeneratedStrategy would be<BR>> > > able to inter-operate with any other Strategy<BR>> > > (DefaultStrategy,<BR>> > > CycleStrategy, TreeStrategy) -
after all,<BR>> it's<BR>> > only<BR>> > > purpose is to help<BR>> > > instantiate objects during deserialization - the<BR>> > behavior<BR>> > > of the other<BR>> > > strategies is still desirable.<BR>> > > <BR>> > > I ran into a couple of problems with this type of<BR>> > Strategy<BR>> > > chaining<BR>> > > approach:<BR>> > > <BR>> > > 1. DefaultStrategy is not instantiable due to<BR>> package<BR>> > > scope visibility<BR>> > > (this is the smaller issue) 2. The other<BR>> strategies<BR>> > appear<BR>> > > to be<BR>> > > implemented in a way that assumes use of zero-arg<BR>> > > constructors. For<BR>> > > example, CycleStrategy#getElement returns an<BR>> Allocate<BR>> > > object depending<BR>> > > on the deserialization state. The Allocate<BR>> object i
s<BR>> > > ultimately backed<BR>> > > by an Instance object as it's delegate Type. <BR>> > Instance<BR>> > > assumes a<BR>> > > zero-arg constructor.<BR>> > > <BR>> > > <BR>> > > Short of re-implementing all of the *Strategy<BR>> classes,<BR>> > I<BR>> > > can't see how<BR>> > > to go about providing a factory to create new<BR>> object<BR>> > > instances (without<BR>> > > losing functionality provided by various Strategy<BR>> > classes).<BR>> > > <BR>> > > <BR>> > > My initial impression based on the above is that<BR>> > Strategy<BR>> > > may not be the<BR>> > > appropriate place in the hierarchy to add object<BR>> > > instantiation behavior.<BR>> > > If not, where? The Instantiator class seems a<BR>> likely<BR>> > > candidate, except<BR>> > > that it's getIns
tace() method doesn't<BR>> have<BR>> > access<BR>> > > to deserialization<BR>> > > context information.<BR>> > > <BR>> > > <BR>> > > <BR>> > > Maybe I'm just going about this all wrong... <BR>> If<BR>> > anyone<BR>> > > can provide some<BR>> > > suggestions, I'd love to hear them!<BR>> > > <BR>> > > <BR>> > > Thanks,<BR>> > > <BR>> > > - K<BR>> > > <BR>> > > <BR>> > > ----------------------- Original Message<BR>> > > -----------------------<BR>> > > <BR>> > > From: Kevin Day <A href="mailto:ke...@tr..."><FONT color=#0000ff><ke...@tr...></FONT></A><BR>> > > To: Simple (Java Project)<BR>> > > <A href="mailto:sim...@li..."><FONT color=#0000ff><sim...@li...></FONT></A><BR>> > > Cc: <BR>>
> > Date: Tue, 20 Jan 2009 17:28:05 -0700<BR>> > > Subject: [Simple-support] Using constructors with<BR>> > arguments<BR>> > > <BR>> > > For starters, I really like what I see in this<BR>> project<BR>> > > (just started<BR>> > > reviewing it this afternoon). I'm hoping<BR>> that I<BR>> > can<BR>> > > get some pointers<BR>> > > on a specific use-case.<BR>> > > <BR>> > > <BR>> > > I would like to use Simple in conjunction with a<BR>> > dependency<BR>> > > injection<BR>> > > system (probably Guice) and List implementations<BR>> from<BR>> > the<BR>> > > GlazedLists<BR>> > > project.<BR>> > > <BR>> > > We have to use a constructor on our list<BR>> > implementations<BR>> > > that contains<BR>> > > arguments (some of the arguments provided by<BR>> Guice,<BR>> > s
ome<BR>> > > from element or<BR>> > > attribute data in the XML).<BR>> > > <BR>> > > What is the best way to approach this with<BR>> Simple?<BR>> > > <BR>> > > It seems that some sort of Strategy mixed with a<BR>> > custom<BR>> > > Type is in<BR>> > > order, but I'm not entirely clear on the best<BR>> > approach.<BR>> > > The<BR>> > > architecture of the framework looks powerful<BR>> enough to<BR>> > do<BR>> > > what we need,<BR>> > > but I can't see where to get started just<BR>> yet.<BR>> > > <BR>> > > <BR>> > > To give a pseudo-code example of what we are<BR>> trying to<BR>> > do<BR>> > > (in real life,<BR>> > > we'll be injecting SomeInjectedObject using<BR>> Guice<BR>> > or a<BR>> > > factory/service<BR>> > > provider call):<BR>> > > <BR>>
> > class SpecialList<E>{<BR>> > > public SpecialList(SomeInjectedObject injected,<BR>> String<BR>> > > valueFromAttribute, SomeObject valueFromElement){<BR>> ...<BR>> > > }<BR>> > > }<BR>> > > <BR>> > > <BR>> > > class MyObject{<BR>> > > @ElementList<BR>> > > SpecialList<ElementObject> list = new<BR>> > ><BR>> ><BR>> SpecialList<ElementObject>(SomeInjectedObject.defaultInstance,<BR>> > > "test",<BR>> > > new SomeObject());<BR>> > > <BR>> > > }<BR>> > > <BR>> > > <BR>> > > When we serialize this with Simple, we'd like<BR>> to<BR>> > see<BR>> > > something<BR>> > > approximately like the following:<BR>> > > <BR>> > > <myObject<BR>> valueFromAttribute="test"><BR>> > > <someObject> ... </someObject><BR>> &g
t; > <list><BR>> > > <elementObject> ... whatever goes into this<BR>> ...<BR>> > > </elementObject><BR>> > > <elementObject> ... whatever goes into this<BR>> ...<BR>> > > </elementObject> ...<BR>> > > </list><BR>> > > </myObject><BR>> > > <BR>> > > <BR>> > > Note that:<BR>> > > <BR>> > > 1. The <list> element doesn't have a<BR>> class<BR>> > > attribute 2. When we<BR>> > > construct the list during deserialization, we<BR>> need to<BR>> > be<BR>> > > able to pull<BR>> > > the 'valueFromAttribute' and<BR>> > 'someObject'<BR>> > > values to use during<BR>> > > construction of the SpecialList object 3. The<BR>> > SpecialList<BR>> > > object needs<BR>> > > to have the 3 argument constructor called (not a<BR>&
gt; > zero-arg<BR>> > > constructor).<BR>> > > And it is not possible to call a zero arg<BR>> constructor,<BR>> > then<BR>> > > modify the<BR>> > > object afterwards to get the same result.<BR>> > > <BR>> > > <BR>> > > Any pointers? I may be pushing the framework too<BR>> hard<BR>> > > (some of the<BR>> > > above requirements can be relaxed - if it<BR>> isn't<BR>> > > possible to obtain<BR>> > > valueFromAttribute or someObject at construction<BR>> time,<BR>> > we<BR>> > > can find<BR>> > > workarounds - but we have to be able to create<BR>> the<BR>> > > SpecialList instance<BR>> > > using values from a factory/Guice/etc...). For<BR>> what<BR>> > > it's worth, we have<BR>> > > this type of behavior working in Betwixt using<BR>> custom<BR>> > > BeanCreator<BR>> >
> implementations.<BR>> > > <BR>> > > Thanks much,<BR>> > > <BR>> > > - Kevin<BR>> > ><BR>> ><BR>> ------------------------------------------------------------------------<BR>> > > ------<BR>> > > This SF.net email is sponsored by:<BR>> > > SourcForge Community<BR>> > > SourceForge wants to tell your story.<BR>> > > <A href="http://p.sf.net/sfu/sf-spreadtheword"><FONT color=#0000ff>http://p.sf.net/sfu/sf-spreadtheword</FONT></A><BR>> > > <BR>> > > <BR>> > > _______________________________________________<BR>> > > Simple-support mailing list<BR>> > > <A href="mailto:Sim...@li..."><FONT color=#0000ff>Sim...@li...</FONT></A><BR>> > ><BR>> ><BR>> <A href="https://lists.sourceforge.net/lists/listinfo/simple-support"><FONT color=#0000ff>https://lists.sourceforge.net/lists
/listinfo/simple-support</FONT></A><BR>> > > Visit our website at <A href="http://www.ubs.com"><FONT color=#0000ff>http://www.ubs.com</FONT></A><BR>> > > <BR>> > > This message contains confidential information<BR>> and is<BR>> > > intended only for<BR>> > > the individual named. If you are not the named<BR>> > addressee<BR>> > > you should not<BR>> > > disseminate, distribute or copy this e-mail. <BR>> Please<BR>> > notify<BR>> > > the sender<BR>> > > immediately by e-mail if you have received this<BR>> e-mail<BR>> > by<BR>> > > mistake and<BR>> > > delete this e-mail from your system.<BR>> > > <BR>> > > E-mails are not encrypted and cannot be<BR>> guaranteed to<BR>> > be<BR>> > > secure or<BR>> > > error-free as information could be intercepted,<BR>> > corrupted,<BR>> > > lost,<
BR>> > > destroyed, arrive late or incomplete, or contain<BR>> > viruses. <BR>> > > The sender<BR>> > > therefore does not accept liability for any<BR>> errors or<BR>> > > omissions in the<BR>> > > contents of this message which arise as a result<BR>> of<BR>> > e-mail<BR>> > > transmission.<BR>> > > <BR>> > > If verification is required please request a<BR>> hard-copy<BR>> > > version. This<BR>> > > message is provided for informational purposes<BR>> and<BR>> > should<BR>> > > not be<BR>> > > construed as a solicitation or offer to buy or<BR>> sell<BR>> > any<BR>> > > securities or<BR>> > > related financial instruments.<BR>> > > <BR>> > > UBS Limited is a company registered in England<BR>> &<BR>> > Wales<BR>> > > under company<BR>> > > number 2035362, whose
registered office is at 1<BR>> > Finsbury<BR>> > > Avenue, London,<BR>> > > EC2M 2PP, United Kingdom.<BR>> > > <BR>> > > UBS AG (London Branch) is registered as a branch<BR>> of a<BR>> > > foreign company<BR>> > > under number BR004507, whose registered office is<BR>> at<BR>> > > 1 Finsbury Avenue, London, EC2M 2PP, United<BR>> Kingdom.<BR>> > > <BR>> > > UBS Clearing and Execution Services Limited is a<BR>> > company<BR>> > > registered in<BR>> > > England & Wales under company number<BR>> 03123037,<BR>> > whose<BR>> > > registered office<BR>> > > is at 1 Finsbury Avenue, London, EC2M 2PP, United<BR>> > Kingdom.<BR>> > > Visit our website at <A href="http://www.ubs.com"><FONT color=#0000ff>http://www.ubs.com</FONT></A><BR>> > > <BR>> > > This message contains confidential information<BR>> a
nd is<BR>> > > intended only <BR>> > > for the individual named. If you are not the<BR>> named<BR>> > > addressee you <BR>> > > should not disseminate, distribute or copy this<BR>> > e-mail. <BR>> > > Please <BR>> > > notify the sender immediately by e-mail if you<BR>> have<BR>> > > received this <BR>> > > e-mail by mistake and delete this e-mail from<BR>> your<BR>> > system.<BR>> > > <BR>> > > E-mails are not encrypted and cannot be<BR>> guaranteed to<BR>> > be<BR>> > > secure or <BR>> > > error-free as information could be intercepted,<BR>> > corrupted,<BR>> > > lost, <BR>> > > destroyed, arrive late or incomplete, or contain<BR>> > viruses. <BR>> > > The sender <BR>> > > therefore does not accept liability for any<BR>> errors or<BR>> > > omissions in the
<BR>> > > contents of this message which arise as a result<BR>> of<BR>> > e-mail<BR>> > > transmission. <BR>> > > If verification is required please request a<BR>> hard-copy<BR>> > > version. This <BR>> > > message is provided for informational purposes<BR>> and<BR>> > should<BR>> > > not be <BR>> > > construed as a solicitation or offer to buy or<BR>> sell<BR>> > any<BR>> > > securities <BR>> > > or related financial instruments.<BR>> > > <BR>> > > UBS Limited is a company registered in England<BR>> &<BR>> > Wales<BR>> > > under company<BR>> > > number 2035362, whose registered office is at 1<BR>> > Finsbury<BR>> > > Avenue,<BR>> > > London, EC2M 2PP, United Kingdom.<BR>> > > <BR>> > > UBS AG (London Branch) is registered as a branch<BR>> of a<BR>> > >
; foreign company<BR>> > > under number BR004507, whose registered office is<BR>> at<BR>> > > 1 Finsbury Avenue, London, EC2M 2PP, United<BR>> Kingdom.<BR>> > > <BR>> > > UBS Clearing and Execution Services Limited is a<BR>> > company<BR>> > > registered<BR>> > > in England & Wales under company number<BR>> 03123037,<BR>> > whose<BR>> > > registered<BR>> > > office is at 1 Finsbury Avenue, London, EC2M 2PP,<BR>> > United<BR>> > > Kingdom.<BR>> > > <BR>> > ><BR>> ><BR>> ------------------------------------------------------------------------------<BR>> > > This SF.net email is sponsored by:<BR>> > > SourcForge Community<BR>> > > SourceForge wants to tell your story.<BR>> > > <A href="http://p.sf.net/sfu/sf-spreadtheword"><FONT color=#0000ff>http://p.sf.net/sfu/sf-spreadtheword</FONT></A><BR>> > >
; _______________________________________________<BR>> > > Simple-support mailing list<BR>> > > <A href="mailto:Sim...@li..."><FONT color=#0000ff>Sim...@li...</FONT></A><BR>> > ><BR>> ><BR>> <A href="https://lists.sourceforge.net/lists/listinfo/simple-support"><FONT color=#0000ff>https://lists.sourceforge.net/lists/listinfo/simple-support</FONT></A><BR>> > <BR>> > <BR>> > <BR>> > <BR>> ><BR>> ------------------------------------------------------------------------------<BR>> > This SF.net email is sponsored by:<BR>> > SourcForge Community<BR>> > SourceForge wants to tell your story.<BR>> > <A href="http://p.sf.net/sfu/sf-spreadtheword"><FONT color=#0000ff>http://p.sf.net/sfu/sf-spreadtheword</FONT></A><BR>> > _______________________________________________<BR>> > Simple-support mailing lis
t<BR>> > <A href="mailto:Sim...@li..."><FONT color=#0000ff>Sim...@li...</FONT></A><BR>> ><BR>> <A href="https://lists.sourceforge.net/lists/listinfo/simple-support"><FONT color=#0000ff>https://lists.sourceforge.net/lists/listinfo/simple-support</FONT></A><BR>> <BR>> <BR>> <BR>> <BR>> ------------------------------------------------------------------------------<BR>> This SF.net email is sponsored by:<BR>> SourcForge Community<BR>> SourceForge wants to tell your story.<BR>> <A href="http://p.sf.net/sfu/sf-spreadtheword"><FONT color=#0000ff>http://p.sf.net/sfu/sf-spreadtheword</FONT></A><BR>> _______________________________________________<BR>> Simple-support mailing list<BR>> <A href="mailto:Sim...@li..."><FONT color=#0000ff>Sim...@li...</FONT></A><BR>> <A href="https://lists.sourceforge.net/l
ists/listinfo/simple-support"><FONT color=#0000ff>https://lists.sourceforge.net/lists/listinfo/simple-support</FONT></A><BR><BR><BR> <BR><BR></DIV></FONT></BODY></HTML>
|
|
From: Kevin D. <for...@tr...> - 2009-01-26 21:10:48
|
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<STYLE type=text/css> P, UL, OL, DL, DIR, MENU, PRE { margin: 0 auto;}</STYLE>
<META content="MSHTML 6.00.6000.16788" name=GENERATOR></HEAD>
<BODY leftMargin=1 topMargin=1 rightMargin=1><FONT face=Arial size=2>
<DIV>This is exactly what I had in mind, with a possible addition/adjustment of specifying a registered factory so we can also address the dependency injection requirement.</DIV>
<DIV> </DIV>
<DIV>To expand the scope of the problem so it also includes a dependency injection component, I'd like to toss out the following class (this is contrived, logging is almost always done using singleton access, but it exercises the aspects of the problem and is easy to understand where a DI system comes into play). In the following the Log object appropriate to a given Tuple is provided by a DI framework (like Guice). It isn't possible to specify the log object's class in the LoggingTuple definition. Also note that I'm specifying ComplexValue instead of a simple String on the value parameter (this could be any complex object, maybe even a list or map))</DIV>
<DIV> </DIV>
<DIV>public class LoggingTuple {<BR></DIV>
<DIV> private Log log;</DIV>
<DIV><BR> @Attribute<BR> private String name;<BR> <BR> @Element<BR> private ComplexValue value;<BR><BR> public Logging<A href="mailto:Log@Inject"><FONT color=#0000ff>Tuple(Log log, </FONT></A>String name, ComplexValue value) {<BR> this.log = log;</DIV>
<DIV> this.name = name;<BR> this.value = value;<BR> }<BR>}</DIV>
<DIV> </DIV>
<DIV> </DIV>
<DIV> </DIV>
<DIV>I could see, then, something like the following:</DIV>
<DIV> </DIV>
<DIV>public class TupleFactory{</DIV>
<DIV> @Inject // <-- this is the Inject annotation from Guice, not the annotation from your sample below.</DIV>
<DIV> Log log;</DIV>
<DIV> </DIV>
<DIV> @FactoryMethod</DIV>
<DIV> public LoggingTuple createLoggingTuple(@SerializedValue String name, @SerializedValue ComplexValue value){</DIV>
<DIV> return new LoggingTuple(log, name, value);</DIV>
<DIV> }</DIV>
<DIV>}</DIV>
<DIV> </DIV>
<DIV> </DIV>
<DIV>When we construct the Persister, we register a factory for it:</DIV>
<DIV> </DIV>
<DIV>Persister p = new Persister(...);</DIV>
<DIV>p.registerObjectFactory(LoggingTuple.class, diContainer.getInstance(TupleFactory.class));</DIV>
<DIV>p.restore(TupleHolder.class, xmlSource);</DIV>
<DIV> </DIV>
<DIV>The DI container would take care of configuring the TupleFactory object with the appropriate Log parameters, etc... (ultimately, we'd actually probably just get the Persister itself from the DI container, and that would automatically inject the appropriate TupleFactory - but that's outside the scope of what Simple has to worry about).</DIV>
<DIV> </DIV>
<DIV>The key here is that values such as Log can be injected into the factory, and Simple can be used to construct new objects using that value. We could even push it a bit harder by making the TupleFactory have a reference to the DI context itself, and have the factory construct Tuple instances directly from the DI context.</DIV>
<DIV> </DIV>
<DIV> </DIV>
<DIV>
<DIV>I think that the factory approach allows for more flexibility, while still addressing the non-zero-argument constructor issue. This addresses both the injection and immutable object deserialization challenges.</DIV>
<DIV> </DIV>
<DIV>One challenge with this approach, though, is determining whether Simple should still attempt to set the field values for the fields used in object creation (in the case of immutable objects, the final field declaration prevents this from being a problem, but non-final fields that are configured by a factory probably shouldn't also be set by Simple... That may be a factor that makes this approach more complicated than I originally thought (you almost need to be able to specify that a given field is to be treated as read-only, and not touched during deserialization). But that wouldn't work in situations where a factory might not always be provided.</DIV>
<DIV> </DIV>
<DIV>Another approach would be to adjust the factory method annotations a bit:</DIV>
<DIV> </DIV>
<DIV> </DIV>
<DIV>
<DIV> @FactoryMethod</DIV>
<DIV> public LoggingTuple createLoggingTuple(@SerializedValue(consume=true) String name, @SerializedValue(consume=true) ComplexValue value){</DIV>
<DIV> return new LoggingTuple(log, name, value);</DIV>
<DIV> }</DIV></DIV>
<DIV> </DIV>
<DIV> </DIV>
<DIV>if 'consume' is specified, it means that the value should not be used beyond the factory instantiation (i.e. fields should not be set using those values).</DIV>
<DIV> </DIV>
<DIV>This is maybe getting too complicated - I'm going to go ahead and send this email and see what ideas it might spark. Maybe the DI requirement is better handled in a different way?</DIV></DIV>
<DIV> </DIV>
<DIV>- K</DIV>
<DIV> </DIV>
<DIV> </DIV>
<DIV></DIV>
<DIV> </DIV></FONT>
<DIV style="FONT-SIZE: x-small; FONT-FAMILY: Tahoma">
<DIV>----------------------- <B>Original Message</B> -----------------------</DIV>
<DIV> </DIV>
<DIV><B>From:</B> Niall Gallagher <A href="mailto:gal...@ya..."><FONT color=#0000ff><gal...@ya...></FONT></A></DIV>
<DIV><B>To:</B> <A href="mailto:sim...@li..."><FONT color=#0000ff>sim...@li...,</FONT></A> Kevin Day <A href="mailto:for...@tr..."><FONT color=#0000ff><for...@tr...></FONT></A></DIV>
<DIV><B>Cc:</B> </DIV>
<DIV><B>Date:</B> Mon, 26 Jan 2009 11:20:38 -0800 (PST)</DIV>
<DIV><B>Subject: <U>Re: [Simple-support] Using constructors with arguments</U></B></DIV>
<DIV> </DIV></DIV><FONT face=Tahoma size=2>
<DIV>Hi,<BR><BR>Thanks for the feedback, if you have any suggestions I am open to them. I was thinking of something like.<BR><BR><BR>public class Tuple {<BR><BR> @Attribute<BR> private String name;<BR> <BR> @Element<BR> private String value;<BR><BR> public <A href="mailto:Tuple(@Inject"><FONT color=#0000ff>Tuple(@Inject</FONT></A> String name, @Inject String value) {<BR> this.name = name;<BR> this.value = value;<BR> }<BR>}<BR><BR>This would make it readable and writable. Taking the parameters and seeing where they can be injected. This would be easy to write.<BR><BR>Niall<BR><BR><BR>--- On Mon, 1/26/09, Kevin Day <A href="mailto:for...@tr..."><FONT color=#0000ff><for...@tr...></FONT></A> wrote:<BR><BR>> From: Kevin Day <A href="mailto:forum_kev@t
rumpetinc.com"><FONT color=#0000ff><for...@tr...></FONT></A><BR>> Subject: Re: [Simple-support] Using constructors with arguments<BR>> To: <A href="mailto:sim...@li..."><FONT color=#0000ff>sim...@li...</FONT></A><BR>> Date: Monday, January 26, 2009, 10:51 AM<BR>> Thanks for taking a look. I may be trying to use this<BR>> framework for more than what it is intented to do. If you<BR>> are interested in pursuing some use-cases, I'd be happy<BR>> to work with you on aspects of the design, etc... But I<BR>> also understand that different projects have different<BR>> goals, and direct encapsulation of business layer objects<BR>> (which are more likely to be required to be immutable) may<BR>> not be part of the goal of Simple-XML.<BR>> <BR>> Using the @Commit or a combination of @Replace/@Resolve<BR>> requires an aweful lot of coding that it seems a persiste
nce<BR>> framework could address... Coding with the @Commit, etc...<BR>> style is roughly similar to using a JAXB generated object<BR>> structure for persistence, then having a bunch of<BR>> translators written to convert persistent values into<BR>> business objects and vice-versa. It can be done, but<BR>> I'm looking for something a lot more elegant.<BR>> <BR>> <BR>> I'm also fine with using a Strategy to achieve the goal<BR>> (I've implemented a really rough first cut at this<BR>> already), but there may be a couple of challenges.<BR>> <BR>> As an example, my work so far indicates that the Strategy<BR>> interface can provide a hook for instantiation of objects<BR>> (i.e. via a factory that could use injected parameters from<BR>> a DI container) - however, unless I'm missing something,<BR>> it doesn't look like Strategy has access to the Type<BR>> objects generated from parsing the XML tree, which means<BR>&g
t; that I can't use objects recovered from the<BR>> deserialization during instantiation. If the objects are<BR>> simple (String or something easily handled with the<BR>> *Transform classes), then this is no big deal (we can just<BR>> instantiate from the Type object in the node map), but for<BR>> complicated objects, I'm not sure how to handle it.<BR>> <BR>> This makes me wonder if I'm trying to get Strategy to<BR>> do something that it just isn't designed to do (maybe<BR>> this kind of thing should be implemented using a different<BR>> layer of the API), or if I can somehow use the map passed<BR>> into the getElement method to make this work.<BR>> <BR>> <BR>> So, is it possible that the Instantiator class is the place<BR>> where this functionality needs to take place? If so, then<BR>> the Instantiator would need to have access to the<BR>> deserialization's context during the call to getType(). <BR>> For exam
ple, if there were some way to obtain named Type<BR>> objects for the fields/values of the object being<BR>> deserialized? These could be used to instantiate values<BR>> that could then be passed to a factory or constructor. I<BR>> suspect this would involve making a read-only view of the<BR>> Collector available to Instantiator.<BR>> <BR>> I'm not sure how much control Simple has over the<BR>> *order* that instantiation occurs in, or whether this would<BR>> impact things. It appears that Simple builds the Type<BR>> hierarchy before it starts instantiating objects, so that<BR>> should be OK (unless there is a cyclic reference in the<BR>> constructor parameters - but that won't happen in a well<BR>> designed object hierarchy :-) )<BR>> <BR>> I'm wondering if you have a philosophical overview of<BR>> the Simple architecture captured anywhere? The JavaDocs<BR>> don't really provide a high level ove
rview, and the API<BR>> has a *lot* of layers to it that make it difficult for<BR>> someone new the source to get a handle on what types of<BR>> behavior should be implemented at which level. My<BR>> assumption is that the system takes several logical passes<BR>> over the object hierarchy:<BR>> <BR>> Parse XML into nodes<BR>> For each node, obtain it's Type (this is the job of<BR>> Strategy I think?)<BR>> Determine the class for each Type and determine it's<BR>> fields/parameters/etc... and create Contacts for those (this<BR>> is the job of Scanner I think? And that interacts with the<BR>> Collector somehow)<BR>> Use each Type to instantiate a concrete object and inject<BR>> it into the Contacts (I think the Collector does this)<BR>> <BR>> Is that approximately correct?<BR>> <BR>> - K<BR>> <BR>> <BR>> <BR>> <BR>> <BR>> <BR>> <BR>> ----------------------- Original Message<BR>> ----
-------------------<BR>> <BR>> From: <A href="mailto:Nia...@ub..."><FONT color=#0000ff><Nia...@ub...></FONT></A><BR>> To: <A href="mailto:for...@tr..."><FONT color=#0000ff><for...@tr...>,</FONT></A><BR>> <A href="mailto:sim...@li..."><FONT color=#0000ff><sim...@li...></FONT></A><BR>> Cc: <BR>> Date: Mon, 26 Jan 2009 09:11:54 -0000<BR>> Subject: RE: [Simple-support] Using constructors with<BR>> arguments<BR>> <BR>> Hi,<BR>> <BR>> Ill take a look at the read resolve and write replace<BR>> issues you<BR>> mention. The reason @Replace and @Resolve do not work in<BR>> lists is they<BR>> go through the Traverser object, rather than the Composite<BR>> object<BR>> directly. This is something I will have to address. So<BR>> there are two<BR>> options, the first is to use a strategy (there should be<
BR>> plenty of<BR>> examples in the test cases), the second is to use @Commit<BR>> to build the<BR>> Tuples like so. <BR>> <BR>> public class TupleDatabase {<BR>> <BR>> private List<Tuple> tuples;<BR>> <BR>> @ElementList<BR>> private List<TupleEntry> entries;<BR>> <BR>> @Commit<BR>> private void commit() {<BR>> for(TupleEntry entry : entries) {<BR>> tuples.add(entry.name, entry.value);<BR>> }<BR>> }<BR>> <BR>> @Root<BR>> private static class TupleEntry {<BR>> @Element String name;<BR>> @Element String value;<BR>> }<BR>> }<BR>> <BR>> Here when building the list you can create the tuples<BR>> without a no-arg<BR>> constructor.<BR>> <BR>> Hope this helps,<BR>> Niall<BR>> <BR>>
-----Original Message-----<BR>> From: Kevin Day <A href="mailto:for...@tr..."><FONT color=#0000ff>[mailto:for...@tr...]</FONT></A> <BR>> Sent: 24 January 2009 00:21<BR>> To: <A href="mailto:sim...@li..."><FONT color=#0000ff>sim...@li...</FONT></A><BR>> Subject: Re: [Simple-support] Using constructors with<BR>> arguments<BR>> <BR>> Thanks for the suggestion, this type of strategy is exactly<BR>> what we do<BR>> with our current Java serialization based persistence, so<BR>> it's easy to<BR>> relate to (even though there's a lot of duplicate<BR>> code).<BR>> <BR>> <BR>> For some reason, though, @Replace isn't working (the<BR>> getSubstitute()<BR>> method is never called).<BR>> <BR>> After a bit of digging into the source, I think that the<BR>> problem is that<BR>> the only place that Caller#replace() is actually called is<BR>> in<BR>> Comp
osite#writeReplace(). And that method is only called<BR>> for composite<BR>> objects. We are dealing with a list of objects, so it<BR>> seems that maybe<BR>> writeReplace() hasn't been properly implemented for<BR>> ElementList<BR>> handlers?<BR>> <BR>> If I place my object outside the list (as part of a<BR>> composite element),<BR>> then it serializes fine.<BR>> <BR>> <BR>> Another issue I'm running into is during<BR>> deserialization. In this case,<BR>> I am using @Resolve on the replaced object (which is part<BR>> of a composite<BR>> object structure). I set a break point on<BR>> Composite.readResolve(), but<BR>> readResolve never gets called. The framework throws an<BR>> InstantiationException from Factory#getOverride().<BR>> <BR>> <BR>> I'm not sure if the problem here is my lack of<BR>> understanding of the API,<BR>> or if this is just a corner case that didn't get u
nit<BR>> testing written<BR>> for it. I am attaching a self contained unit test case<BR>> that exhibits<BR>> all of the above behavior. Please let me know if you have<BR>> any<BR>> pointers/suggestions, or if I may just be missing<BR>> something!<BR>> <BR>> Cheers,<BR>> <BR>> - Kevin<BR>> <BR>> <BR>> PS - I suspect that the use of @Replace and @Resolve may<BR>> not solve our<BR>> entire use case, but it is a great start at a solution and<BR>> is helping me<BR>> understand the Simple framework better. Our ultimate need<BR>> also includes<BR>> injection of resources via a DI framework, and I'm<BR>> having a hard time<BR>> figuring out how that's going to happen without using<BR>> some sort of<BR>> factory instantiation strategy (I suppose that we could use<BR>> a singleton<BR>> to get the DI hook, but that's an anti-design pattern<BR>> that I really<BR>> would prefer to avoid
at all costs). Hopefully we can<BR>> discuss this<BR>> aspect a bit more after I understand why my @Replace and<BR>> @Resolve aren't<BR>> working!<BR>> <BR>> <BR>> <BR>> <BR>> <BR>> ----------------------- Original Message<BR>> -----------------------<BR>> <BR>> From: <A href="mailto:Nia...@ub..."><FONT color=#0000ff><Nia...@ub...></FONT></A><BR>> To: <A href="mailto:for...@tr..."><FONT color=#0000ff><for...@tr...>,</FONT></A><BR>> <A href="mailto:sim...@li..."><FONT color=#0000ff><sim...@li...></FONT></A><BR>> Cc: <BR>> Date: Thu, 22 Jan 2009 16:45:15 -0000<BR>> Subject: RE: [Simple-support] Using constructors with<BR>> arguments<BR>> <BR>> Hi,<BR>> <BR>> There is no need to do this. You can do the following.<BR>> <BR>> @Root<BR>> public class Tuple {<BR>> <BR>> final pri
vate String from;<BR>> final private String to;<BR>> <BR>> public Tuple(String from, String to){<BR>> this.from = from;<BR>> this.to = to;<BR>> }<BR>> <BR>> @Replace<BR>> private TupleSubstitute getSubstitute() {<BR>> return new TupleSubstitute(from, to);<BR>> }<BR>> <BR>> public String getFrom() {<BR>> return from;<BR>> }<BR>> <BR>> public String getTo() {<BR>> return to;<BR>> }<BR>> <BR>> public String toString() {<BR>> return from + " -> " + to;<BR>> }<BR>> <BR>> }<BR>> <BR>> @Root<BR>> private class TupleSubstitute {<BR>> <BR>> @Element<BR>> private String from;<BR>> @Element<BR>> private String to;<BR>> <BR>> public TupleSubstitute() {<BR>> super();<BR>> }<BR>> <BR>> public TupleSubstitute(String from, St
ring to) {<BR>> this.from = from;<BR>> this.to = to;<BR>> }<BR>> <BR>> @Resolve<BR>> public Tuple getTuple() {<BR>> return new Tuple();<BR>> }<BR>> }<BR>> <BR>> This should work, for you. The @Resolve annotation resolves<BR>> the<BR>> deserialized object before assigning it to the field or<BR>> method. The<BR>> @Replace object replaces the object in the stream. Just<BR>> like java object<BR>> serialization. Let me know how this works out for you.<BR>> <BR>> Hope this helps,<BR>> Niall<BR>> <BR>> <BR>> <BR>> -----Original Message-----<BR>> From: Kevin Day <A href="mailto:for...@tr..."><FONT color=#0000ff>[mailto:for...@tr...]</FONT></A><BR>> Sent: 21 January 2009 22:56<BR>> To: Simple (Java Project)<BR>> Subject: Re: [Simple-support] Using constructors with<BR>> arguments<BR>> <BR>> I've done some additional work on handling
classes that<BR>> do not have<BR>> zero-arg constructors. First, I've put together some<BR>> simple sample code<BR>> (attached, start with TryIt#main) that shows one of the<BR>> situations we<BR>> are facing: we have a number of immutable Tuple objects<BR>> that we need to<BR>> serialize/deserialze. The values used in the Tuple<BR>> class' constructor<BR>> come from attributes (or elements) from the XML. The<BR>> attached<BR>> serializes fine, but we can't deserialize it b/c of the<BR>> lack of<BR>> no-argument constructor. We can't add a no-arg<BR>> constructor because the<BR>> class is intended to be immutable (in fact, the fields are<BR>> marked as<BR>> final). In addition, the sample code shows the Tuple<BR>> values as holding<BR>> simple strings - but in our application, the values are<BR>> going to be<BR>> complex objects.<BR>> <BR>> <BR>> I have put together a Stra
tegy and Type implementation that<BR>> *kind* of<BR>> works, but I'm running into some issues (may be related<BR>> to my lack of<BR>> familiarity with the code base).<BR>> <BR>> The approach that I'm working on now creates a new<BR>> Strategy that allows<BR>> us to register special Type objects that can handle object<BR>> instantiation<BR>> based on state of the deserialization process (for now,<BR>> I'm calling this<BR>> FactoryGeneratedStrategy). Ideally,<BR>> FactoryGeneratedStrategy would be<BR>> able to inter-operate with any other Strategy<BR>> (DefaultStrategy,<BR>> CycleStrategy, TreeStrategy) - after all, it's only<BR>> purpose is to help<BR>> instantiate objects during deserialization - the behavior<BR>> of the other<BR>> strategies is still desirable.<BR>> <BR>> I ran into a couple of problems with this type of Strategy<BR>> chaining<BR>> approach:<BR>> <BR>> 1. DefaultStrate
gy is not instantiable due to package<BR>> scope visibility<BR>> (this is the smaller issue) 2. The other strategies appear<BR>> to be<BR>> implemented in a way that assumes use of zero-arg<BR>> constructors. For<BR>> example, CycleStrategy#getElement returns an Allocate<BR>> object depending<BR>> on the deserialization state. The Allocate object is<BR>> ultimately backed<BR>> by an Instance object as it's delegate Type. Instance<BR>> assumes a<BR>> zero-arg constructor.<BR>> <BR>> <BR>> Short of re-implementing all of the *Strategy classes, I<BR>> can't see how<BR>> to go about providing a factory to create new object<BR>> instances (without<BR>> losing functionality provided by various Strategy classes).<BR>> <BR>> <BR>> My initial impression based on the above is that Strategy<BR>> may not be the<BR>> appropriate place in the hierarchy to add object<BR>> instantiation behavi
or.<BR>> If not, where? The Instantiator class seems a likely<BR>> candidate, except<BR>> that it's getInstace() method doesn't have access<BR>> to deserialization<BR>> context information.<BR>> <BR>> <BR>> <BR>> Maybe I'm just going about this all wrong... If anyone<BR>> can provide some<BR>> suggestions, I'd love to hear them!<BR>> <BR>> <BR>> Thanks,<BR>> <BR>> - K<BR>> <BR>> <BR>> ----------------------- Original Message<BR>> -----------------------<BR>> <BR>> From: Kevin Day <A href="mailto:ke...@tr..."><FONT color=#0000ff><ke...@tr...></FONT></A><BR>> To: Simple (Java Project)<BR>> <A href="mailto:sim...@li..."><FONT color=#0000ff><sim...@li...></FONT></A><BR>> Cc: <BR>> Date: Tue, 20 Jan 2009 17:28:05 -0700<BR>> Subject: [Simple-support] Using constructors with arguments<BR>> <BR>> For starters
, I really like what I see in this project<BR>> (just started<BR>> reviewing it this afternoon). I'm hoping that I can<BR>> get some pointers<BR>> on a specific use-case.<BR>> <BR>> <BR>> I would like to use Simple in conjunction with a dependency<BR>> injection<BR>> system (probably Guice) and List implementations from the<BR>> GlazedLists<BR>> project.<BR>> <BR>> We have to use a constructor on our list implementations<BR>> that contains<BR>> arguments (some of the arguments provided by Guice, some<BR>> from element or<BR>> attribute data in the XML).<BR>> <BR>> What is the best way to approach this with Simple?<BR>> <BR>> It seems that some sort of Strategy mixed with a custom<BR>> Type is in<BR>> order, but I'm not entirely clear on the best approach.<BR>> The<BR>> architecture of the framework looks powerful enough to do<BR>> what we need,<BR>> but I can't see where to get start
ed just yet.<BR>> <BR>> <BR>> To give a pseudo-code example of what we are trying to do<BR>> (in real life,<BR>> we'll be injecting SomeInjectedObject using Guice or a<BR>> factory/service<BR>> provider call):<BR>> <BR>> class SpecialList<E>{<BR>> public SpecialList(SomeInjectedObject injected, String<BR>> valueFromAttribute, SomeObject valueFromElement){ ...<BR>> }<BR>> }<BR>> <BR>> <BR>> class MyObject{<BR>> @ElementList<BR>> SpecialList<ElementObject> list = new<BR>> SpecialList<ElementObject>(SomeInjectedObject.defaultInstance,<BR>> "test",<BR>> new SomeObject());<BR>> <BR>> }<BR>> <BR>> <BR>> When we serialize this with Simple, we'd like to see<BR>> something<BR>> approximately like the following:<BR>> <BR>> <myObject valueFromAttribute="test"><BR>> <someObject> ... </someObject><BR>> <list><BR>> <elementObject> ... wha
tever goes into this ...<BR>> </elementObject><BR>> <elementObject> ... whatever goes into this ...<BR>> </elementObject> ...<BR>> </list><BR>> </myObject><BR>> <BR>> <BR>> Note that:<BR>> <BR>> 1. The <list> element doesn't have a class<BR>> attribute 2. When we<BR>> construct the list during deserialization, we need to be<BR>> able to pull<BR>> the 'valueFromAttribute' and 'someObject'<BR>> values to use during<BR>> construction of the SpecialList object 3. The SpecialList<BR>> object needs<BR>> to have the 3 argument constructor called (not a zero-arg<BR>> constructor).<BR>> And it is not possible to call a zero arg constructor, then<BR>> modify the<BR>> object afterwards to get the same result.<BR>> <BR>> <BR>> Any pointers? I may be pushing the framework too hard<BR>> (some of the<BR>> above requirements can be relaxed - if i
t isn't<BR>> possible to obtain<BR>> valueFromAttribute or someObject at construction time, we<BR>> can find<BR>> workarounds - but we have to be able to create the<BR>> SpecialList instance<BR>> using values from a factory/Guice/etc...). For what<BR>> it's worth, we have<BR>> this type of behavior working in Betwixt using custom<BR>> BeanCreator<BR>> implementations.<BR>> <BR>> Thanks much,<BR>> <BR>> - Kevin<BR>> ------------------------------------------------------------------------<BR>> ------<BR>> This SF.net email is sponsored by:<BR>> SourcForge Community<BR>> SourceForge wants to tell your story.<BR>> <A href="http://p.sf.net/sfu/sf-spreadtheword"><FONT color=#0000ff>http://p.sf.net/sfu/sf-spreadtheword</FONT></A><BR>> <BR>> <BR>> _______________________________________________<BR>> Simple-support mailing list<BR>> <A href="mailto:Sim...@li..."><FONT color=#0000f
f>Sim...@li...</FONT></A><BR>> <A href="https://lists.sourceforge.net/lists/listinfo/simple-support"><FONT color=#0000ff>https://lists.sourceforge.net/lists/listinfo/simple-support</FONT></A><BR>> Visit our website at <A href="http://www.ubs.com"><FONT color=#0000ff>http://www.ubs.com</FONT></A><BR>> <BR>> This message contains confidential information and is<BR>> intended only for<BR>> the individual named. If you are not the named addressee<BR>> you should not<BR>> disseminate, distribute or copy this e-mail. Please notify<BR>> the sender<BR>> immediately by e-mail if you have received this e-mail by<BR>> mistake and<BR>> delete this e-mail from your system.<BR>> <BR>> E-mails are not encrypted and cannot be guaranteed to be<BR>> secure or<BR>> error-free as information could be intercepted, corrupted,<BR>> lost,<BR>> destroyed, arrive late or incomplete, or contain viruses. <BR
>> The sender<BR>> therefore does not accept liability for any errors or<BR>> omissions in the<BR>> contents of this message which arise as a result of e-mail<BR>> transmission.<BR>> <BR>> If verification is required please request a hard-copy<BR>> version. This<BR>> message is provided for informational purposes and should<BR>> not be<BR>> construed as a solicitation or offer to buy or sell any<BR>> securities or<BR>> related financial instruments.<BR>> <BR>> UBS Limited is a company registered in England & Wales<BR>> under company<BR>> number 2035362, whose registered office is at 1 Finsbury<BR>> Avenue, London,<BR>> EC2M 2PP, United Kingdom.<BR>> <BR>> UBS AG (London Branch) is registered as a branch of a<BR>> foreign company<BR>> under number BR004507, whose registered office is at<BR>> 1 Finsbury Avenue, London, EC2M 2PP, United Kingdom.<BR>> <BR>> UBS Clearing and Execution Services
Limited is a company<BR>> registered in<BR>> England & Wales under company number 03123037, whose<BR>> registered office<BR>> is at 1 Finsbury Avenue, London, EC2M 2PP, United Kingdom.<BR>> Visit our website at <A href="http://www.ubs.com"><FONT color=#0000ff>http://www.ubs.com</FONT></A><BR>> <BR>> This message contains confidential information and is<BR>> intended only <BR>> for the individual named. If you are not the named<BR>> addressee you <BR>> should not disseminate, distribute or copy this e-mail. <BR>> Please <BR>> notify the sender immediately by e-mail if you have<BR>> received this <BR>> e-mail by mistake and delete this e-mail from your system.<BR>> <BR>> E-mails are not encrypted and cannot be guaranteed to be<BR>> secure or <BR>> error-free as information could be intercepted, corrupted,<BR>> lost, <BR>> destroyed, arrive late or incomplete, or contain viruses. <BR>>
; The sender <BR>> therefore does not accept liability for any errors or<BR>> omissions in the <BR>> contents of this message which arise as a result of e-mail<BR>> transmission. <BR>> If verification is required please request a hard-copy<BR>> version. This <BR>> message is provided for informational purposes and should<BR>> not be <BR>> construed as a solicitation or offer to buy or sell any<BR>> securities <BR>> or related financial instruments.<BR>> <BR>> UBS Limited is a company registered in England & Wales<BR>> under company<BR>> number 2035362, whose registered office is at 1 Finsbury<BR>> Avenue,<BR>> London, EC2M 2PP, United Kingdom.<BR>> <BR>> UBS AG (London Branch) is registered as a branch of a<BR>> foreign company<BR>> under number BR004507, whose registered office is at<BR>> 1 Finsbury Avenue, London, EC2M 2PP, United Kingdom.<BR>> <BR>> UBS Clearing and Execution Services
Limited is a company<BR>> registered<BR>> in England & Wales under company number 03123037, whose<BR>> registered<BR>> office is at 1 Finsbury Avenue, London, EC2M 2PP, United<BR>> Kingdom.<BR>> <BR>> ------------------------------------------------------------------------------<BR>> This SF.net email is sponsored by:<BR>> SourcForge Community<BR>> SourceForge wants to tell your story.<BR>> <A href="http://p.sf.net/sfu/sf-spreadtheword"><FONT color=#0000ff>http://p.sf.net/sfu/sf-spreadtheword</FONT></A><BR>> _______________________________________________<BR>> Simple-support mailing list<BR>> <A href="mailto:Sim...@li..."><FONT color=#0000ff>Sim...@li...</FONT></A><BR>> <A href="https://lists.sourceforge.net/lists/listinfo/simple-support"><FONT color=#0000ff>https://lists.sourceforge.net/lists/listinfo/simple-support</FONT></A><BR><BR><BR> <BR><BR></D
IV></FONT></BODY></HTML>
|
|
From: Niall G. <gal...@ya...> - 2009-01-26 19:43:40
|
Hi,
Also, just to mention you can do this.
public class Tuple {
private Tuple() {
super();
}
// etc...
}
Private no-arg constructors will also get invoked.
Niall
--- On Mon, 1/26/09, Niall Gallagher <gal...@ya...> wrote:
> From: Niall Gallagher <gal...@ya...>
> Subject: Re: [Simple-support] Using constructors with arguments
> To: sim...@li..., "Kevin Day" <for...@tr...>
> Date: Monday, January 26, 2009, 11:40 AM
> Hi,
>
> Take a look at this. I will add this form of instantiation
> without a no-arg constructor in the next release.
>
> http://simple.svn.sourceforge.net/viewvc/simple/trunk/download/stream/src/test/java/org/simpleframework/xml/core/ObjectStreamClassTest.java?revision=1158&view=markup
>
> Let me know if this is suitable.
>
> Niall
>
>
> --- On Mon, 1/26/09, Niall Gallagher
> <gal...@ya...> wrote:
>
> > From: Niall Gallagher
> <gal...@ya...>
> > Subject: Re: [Simple-support] Using constructors with
> arguments
> > To: sim...@li..., "Kevin
> Day" <for...@tr...>
> > Date: Monday, January 26, 2009, 11:20 AM
> > Hi,
> >
> > Thanks for the feedback, if you have any suggestions I
> am
> > open to them. I was thinking of something like.
> >
> >
> > public class Tuple {
> >
> > @Attribute
> > private String name;
> >
> > @Element
> > private String value;
> >
> > public Tuple(@Inject String name, @Inject String
> value)
> > {
> > this.name = name;
> > this.value = value;
> > }
> > }
> >
> > This would make it readable and writable. Taking the
> > parameters and seeing where they can be injected. This
> would
> > be easy to write.
> >
> > Niall
> >
> >
> > --- On Mon, 1/26/09, Kevin Day
> > <for...@tr...> wrote:
> >
> > > From: Kevin Day <for...@tr...>
> > > Subject: Re: [Simple-support] Using constructors
> with
> > arguments
> > > To: sim...@li...
> > > Date: Monday, January 26, 2009, 10:51 AM
> > > Thanks for taking a look. I may be trying to use
> this
> > > framework for more than what it is intented to
> do. If
> > you
> > > are interested in pursuing some use-cases,
> I'd be
> > happy
> > > to work with you on aspects of the design, etc...
> But
> > I
> > > also understand that different projects have
> different
> > > goals, and direct encapsulation of business layer
> > objects
> > > (which are more likely to be required to be
> immutable)
> > may
> > > not be part of the goal of Simple-XML.
> > >
> > > Using the @Commit or a combination of
> > @Replace/@Resolve
> > > requires an aweful lot of coding that it seems a
> > persistence
> > > framework could address... Coding with the
> @Commit,
> > etc...
> > > style is roughly similar to using a JAXB
> generated
> > object
> > > structure for persistence, then having a bunch of
> > > translators written to convert persistent values
> into
> > > business objects and vice-versa. It can be done,
> but
> > > I'm looking for something a lot more elegant.
> > >
> > >
> > > I'm also fine with using a Strategy to
> achieve the
> > goal
> > > (I've implemented a really rough first cut at
> this
> > > already), but there may be a couple of
> challenges.
> > >
> > > As an example, my work so far indicates that the
> > Strategy
> > > interface can provide a hook for instantiation of
> > objects
> > > (i.e. via a factory that could use injected
> parameters
> > from
> > > a DI container) - however, unless I'm missing
> > something,
> > > it doesn't look like Strategy has access to
> the
> > Type
> > > objects generated from parsing the XML tree,
> which
> > means
> > > that I can't use objects recovered from the
> > > deserialization during instantiation. If the
> objects
> > are
> > > simple (String or something easily handled with
> the
> > > *Transform classes), then this is no big deal (we
> can
> > just
> > > instantiate from the Type object in the node
> map), but
> > for
> > > complicated objects, I'm not sure how to
> handle
> > it.
> > >
> > > This makes me wonder if I'm trying to get
> Strategy
> > to
> > > do something that it just isn't designed to
> do
> > (maybe
> > > this kind of thing should be implemented using a
> > different
> > > layer of the API), or if I can somehow use the
> map
> > passed
> > > into the getElement method to make this work.
> > >
> > >
> > > So, is it possible that the Instantiator class is
> the
> > place
> > > where this functionality needs to take place? If
> so,
> > then
> > > the Instantiator would need to have access to the
> > > deserialization's context during the call to
> > getType().
> > > For example, if there were some way to obtain
> named
> > Type
> > > objects for the fields/values of the object being
> > > deserialized? These could be used to instantiate
> > values
> > > that could then be passed to a factory or
> constructor.
> > I
> > > suspect this would involve making a read-only
> view of
> > the
> > > Collector available to Instantiator.
> > >
> > > I'm not sure how much control Simple has over
> the
> > > *order* that instantiation occurs in, or whether
> this
> > would
> > > impact things. It appears that Simple builds the
> Type
> > > hierarchy before it starts instantiating objects,
> so
> > that
> > > should be OK (unless there is a cyclic reference
> in
> > the
> > > constructor parameters - but that won't
> happen in
> > a well
> > > designed object hierarchy :-) )
> > >
> > > I'm wondering if you have a philosophical
> overview
> > of
> > > the Simple architecture captured anywhere? The
> > JavaDocs
> > > don't really provide a high level overview,
> and
> > the API
> > > has a *lot* of layers to it that make it
> difficult for
> > > someone new the source to get a handle on what
> types
> > of
> > > behavior should be implemented at which level.
> My
> > > assumption is that the system takes several
> logical
> > passes
> > > over the object hierarchy:
> > >
> > > Parse XML into nodes
> > > For each node, obtain it's Type (this is the
> job
> > of
> > > Strategy I think?)
> > > Determine the class for each Type and determine
> > it's
> > > fields/parameters/etc... and create Contacts for
> those
> > (this
> > > is the job of Scanner I think? And that
> interacts
> > with the
> > > Collector somehow)
> > > Use each Type to instantiate a concrete object
> and
> > inject
> > > it into the Contacts (I think the Collector does
> this)
> > >
> > > Is that approximately correct?
> > >
> > > - K
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > ----------------------- Original Message
> > > -----------------------
> > >
> > > From: <Nia...@ub...>
> > > To: <for...@tr...>,
> > > <sim...@li...>
> > > Cc:
> > > Date: Mon, 26 Jan 2009 09:11:54 -0000
> > > Subject: RE: [Simple-support] Using constructors
> with
> > > arguments
> > >
> > > Hi,
> > >
> > > Ill take a look at the read resolve and write
> replace
> > > issues you
> > > mention. The reason @Replace and @Resolve do not
> work
> > in
> > > lists is they
> > > go through the Traverser object, rather than the
> > Composite
> > > object
> > > directly. This is something I will have to
> address. So
> > > there are two
> > > options, the first is to use a strategy (there
> should
> > be
> > > plenty of
> > > examples in the test cases), the second is to use
> > @Commit
> > > to build the
> > > Tuples like so.
> > >
> > > public class TupleDatabase {
> > >
> > > private List<Tuple> tuples;
> > >
> > > @ElementList
> > > private List<TupleEntry> entries;
> > >
> > > @Commit
> > > private void commit() {
> > > for(TupleEntry entry : entries) {
> > > tuples.add(entry.name, entry.value);
> > > }
> > > }
> > >
> > > @Root
> > > private static class TupleEntry {
> > > @Element String name;
> > > @Element String value;
> > > }
> > > }
> > >
> > > Here when building the list you can create the
> tuples
> > > without a no-arg
> > > constructor.
> > >
> > > Hope this helps,
> > > Niall
> > >
> > > -----Original Message-----
> > > From: Kevin Day [mailto:for...@tr...]
>
> > > Sent: 24 January 2009 00:21
> > > To: sim...@li...
> > > Subject: Re: [Simple-support] Using constructors
> with
> > > arguments
> > >
> > > Thanks for the suggestion, this type of strategy
> is
> > exactly
> > > what we do
> > > with our current Java serialization based
> persistence,
> > so
> > > it's easy to
> > > relate to (even though there's a lot of
> duplicate
> > > code).
> > >
> > >
> > > For some reason, though, @Replace isn't
> working
> > (the
> > > getSubstitute()
> > > method is never called).
> > >
> > > After a bit of digging into the source, I think
> that
> > the
> > > problem is that
> > > the only place that Caller#replace() is actually
> > called is
> > > in
> > > Composite#writeReplace(). And that method is
> only
> > called
> > > for composite
> > > objects. We are dealing with a list of objects,
> so it
> > > seems that maybe
> > > writeReplace() hasn't been properly
> implemented
> > for
> > > ElementList
> > > handlers?
> > >
> > > If I place my object outside the list (as part of
> a
> > > composite element),
> > > then it serializes fine.
> > >
> > >
> > > Another issue I'm running into is during
> > > deserialization. In this case,
> > > I am using @Resolve on the replaced object (which
> is
> > part
> > > of a composite
> > > object structure). I set a break point on
> > > Composite.readResolve(), but
> > > readResolve never gets called. The framework
> throws
> > an
> > > InstantiationException from
> Factory#getOverride().
> > >
> > >
> > > I'm not sure if the problem here is my lack
> of
> > > understanding of the API,
> > > or if this is just a corner case that didn't
> get
> > unit
> > > testing written
> > > for it. I am attaching a self contained unit
> test
> > case
> > > that exhibits
> > > all of the above behavior. Please let me know if
> you
> > have
> > > any
> > > pointers/suggestions, or if I may just be missing
> > > something!
> > >
> > > Cheers,
> > >
> > > - Kevin
> > >
> > >
> > > PS - I suspect that the use of @Replace and
> @Resolve
> > may
> > > not solve our
> > > entire use case, but it is a great start at a
> solution
> > and
> > > is helping me
> > > understand the Simple framework better. Our
> ultimate
> > need
> > > also includes
> > > injection of resources via a DI framework, and
> I'm
> > > having a hard time
> > > figuring out how that's going to happen
> without
> > using
> > > some sort of
> > > factory instantiation strategy (I suppose that we
> > could use
> > > a singleton
> > > to get the DI hook, but that's an anti-design
> > pattern
> > > that I really
> > > would prefer to avoid at all costs). Hopefully
> we can
> > > discuss this
> > > aspect a bit more after I understand why my
> @Replace
> > and
> > > @Resolve aren't
> > > working!
> > >
> > >
> > >
> > >
> > >
> > > ----------------------- Original Message
> > > -----------------------
> > >
> > > From: <Nia...@ub...>
> > > To: <for...@tr...>,
> > > <sim...@li...>
> > > Cc:
> > > Date: Thu, 22 Jan 2009 16:45:15 -0000
> > > Subject: RE: [Simple-support] Using constructors
> with
> > > arguments
> > >
> > > Hi,
> > >
> > > There is no need to do this. You can do the
> following.
> > >
> > > @Root
> > > public class Tuple {
> > >
> > > final private String from;
> > > final private String to;
> > >
> > > public Tuple(String from, String to){
> > > this.from = from;
> > > this.to = to;
> > > }
> > >
> > > @Replace
> > > private TupleSubstitute getSubstitute() {
> > > return new TupleSubstitute(from, to);
> > > }
> > >
> > > public String getFrom() {
> > > return from;
> > > }
> > >
> > > public String getTo() {
> > > return to;
> > > }
> > >
> > > public String toString() {
> > > return from + " -> " + to;
> > > }
> > >
> > > }
> > >
> > > @Root
> > > private class TupleSubstitute {
> > >
> > > @Element
> > > private String from;
> > > @Element
> > > private String to;
> > >
> > > public TupleSubstitute() {
> > > super();
> > > }
> > >
> > > public TupleSubstitute(String from, String to) {
> > > this.from = from;
> > > this.to = to;
> > > }
> > >
> > > @Resolve
> > > public Tuple getTuple() {
> > > return new Tuple();
> > > }
> > > }
> > >
> > > This should work, for you. The @Resolve
> annotation
> > resolves
> > > the
> > > deserialized object before assigning it to the
> field
> > or
> > > method. The
> > > @Replace object replaces the object in the
> stream.
> > Just
> > > like java object
> > > serialization. Let me know how this works out for
> you.
> > >
> > > Hope this helps,
> > > Niall
> > >
> > >
> > >
> > > -----Original Message-----
> > > From: Kevin Day [mailto:for...@tr...]
> > > Sent: 21 January 2009 22:56
> > > To: Simple (Java Project)
> > > Subject: Re: [Simple-support] Using constructors
> with
> > > arguments
> > >
> > > I've done some additional work on handling
> classes
> > that
> > > do not have
> > > zero-arg constructors. First, I've put
> together
> > some
> > > simple sample code
> > > (attached, start with TryIt#main) that shows one
> of
> > the
> > > situations we
> > > are facing: we have a number of immutable Tuple
> > objects
> > > that we need to
> > > serialize/deserialze. The values used in the
> Tuple
> > > class' constructor
> > > come from attributes (or elements) from the XML.
> The
> > > attached
> > > serializes fine, but we can't deserialize it
> b/c
> > of the
> > > lack of
> > > no-argument constructor. We can't add a
> no-arg
> > > constructor because the
> > > class is intended to be immutable (in fact, the
> fields
> > are
> > > marked as
> > > final). In addition, the sample code shows the
> Tuple
> > > values as holding
> > > simple strings - but in our application, the
> values
> > are
> > > going to be
> > > complex objects.
> > >
> > >
> > > I have put together a Strategy and Type
> implementation
> > that
> > > *kind* of
> > > works, but I'm running into some issues (may
> be
> > related
> > > to my lack of
> > > familiarity with the code base).
> > >
> > > The approach that I'm working on now creates
> a new
> > > Strategy that allows
> > > us to register special Type objects that can
> handle
> > object
> > > instantiation
> > > based on state of the deserialization process
> (for
> > now,
> > > I'm calling this
> > > FactoryGeneratedStrategy). Ideally,
> > > FactoryGeneratedStrategy would be
> > > able to inter-operate with any other Strategy
> > > (DefaultStrategy,
> > > CycleStrategy, TreeStrategy) - after all,
> it's
> > only
> > > purpose is to help
> > > instantiate objects during deserialization - the
> > behavior
> > > of the other
> > > strategies is still desirable.
> > >
> > > I ran into a couple of problems with this type of
> > Strategy
> > > chaining
> > > approach:
> > >
> > > 1. DefaultStrategy is not instantiable due to
> package
> > > scope visibility
> > > (this is the smaller issue) 2. The other
> strategies
> > appear
> > > to be
> > > implemented in a way that assumes use of zero-arg
> > > constructors. For
> > > example, CycleStrategy#getElement returns an
> Allocate
> > > object depending
> > > on the deserialization state. The Allocate
> object is
> > > ultimately backed
> > > by an Instance object as it's delegate Type.
> > Instance
> > > assumes a
> > > zero-arg constructor.
> > >
> > >
> > > Short of re-implementing all of the *Strategy
> classes,
> > I
> > > can't see how
> > > to go about providing a factory to create new
> object
> > > instances (without
> > > losing functionality provided by various Strategy
> > classes).
> > >
> > >
> > > My initial impression based on the above is that
> > Strategy
> > > may not be the
> > > appropriate place in the hierarchy to add object
> > > instantiation behavior.
> > > If not, where? The Instantiator class seems a
> likely
> > > candidate, except
> > > that it's getInstace() method doesn't
> have
> > access
> > > to deserialization
> > > context information.
> > >
> > >
> > >
> > > Maybe I'm just going about this all wrong...
> If
> > anyone
> > > can provide some
> > > suggestions, I'd love to hear them!
> > >
> > >
> > > Thanks,
> > >
> > > - K
> > >
> > >
> > > ----------------------- Original Message
> > > -----------------------
> > >
> > > From: Kevin Day <ke...@tr...>
> > > To: Simple (Java Project)
> > > <sim...@li...>
> > > Cc:
> > > Date: Tue, 20 Jan 2009 17:28:05 -0700
> > > Subject: [Simple-support] Using constructors with
> > arguments
> > >
> > > For starters, I really like what I see in this
> project
> > > (just started
> > > reviewing it this afternoon). I'm hoping
> that I
> > can
> > > get some pointers
> > > on a specific use-case.
> > >
> > >
> > > I would like to use Simple in conjunction with a
> > dependency
> > > injection
> > > system (probably Guice) and List implementations
> from
> > the
> > > GlazedLists
> > > project.
> > >
> > > We have to use a constructor on our list
> > implementations
> > > that contains
> > > arguments (some of the arguments provided by
> Guice,
> > some
> > > from element or
> > > attribute data in the XML).
> > >
> > > What is the best way to approach this with
> Simple?
> > >
> > > It seems that some sort of Strategy mixed with a
> > custom
> > > Type is in
> > > order, but I'm not entirely clear on the best
> > approach.
> > > The
> > > architecture of the framework looks powerful
> enough to
> > do
> > > what we need,
> > > but I can't see where to get started just
> yet.
> > >
> > >
> > > To give a pseudo-code example of what we are
> trying to
> > do
> > > (in real life,
> > > we'll be injecting SomeInjectedObject using
> Guice
> > or a
> > > factory/service
> > > provider call):
> > >
> > > class SpecialList<E>{
> > > public SpecialList(SomeInjectedObject injected,
> String
> > > valueFromAttribute, SomeObject valueFromElement){
> ...
> > > }
> > > }
> > >
> > >
> > > class MyObject{
> > > @ElementList
> > > SpecialList<ElementObject> list = new
> > >
> >
> SpecialList<ElementObject>(SomeInjectedObject.defaultInstance,
> > > "test",
> > > new SomeObject());
> > >
> > > }
> > >
> > >
> > > When we serialize this with Simple, we'd like
> to
> > see
> > > something
> > > approximately like the following:
> > >
> > > <myObject
> valueFromAttribute="test">
> > > <someObject> ... </someObject>
> > > <list>
> > > <elementObject> ... whatever goes into this
> ...
> > > </elementObject>
> > > <elementObject> ... whatever goes into this
> ...
> > > </elementObject> ...
> > > </list>
> > > </myObject>
> > >
> > >
> > > Note that:
> > >
> > > 1. The <list> element doesn't have a
> class
> > > attribute 2. When we
> > > construct the list during deserialization, we
> need to
> > be
> > > able to pull
> > > the 'valueFromAttribute' and
> > 'someObject'
> > > values to use during
> > > construction of the SpecialList object 3. The
> > SpecialList
> > > object needs
> > > to have the 3 argument constructor called (not a
> > zero-arg
> > > constructor).
> > > And it is not possible to call a zero arg
> constructor,
> > then
> > > modify the
> > > object afterwards to get the same result.
> > >
> > >
> > > Any pointers? I may be pushing the framework too
> hard
> > > (some of the
> > > above requirements can be relaxed - if it
> isn't
> > > possible to obtain
> > > valueFromAttribute or someObject at construction
> time,
> > we
> > > can find
> > > workarounds - but we have to be able to create
> the
> > > SpecialList instance
> > > using values from a factory/Guice/etc...). For
> what
> > > it's worth, we have
> > > this type of behavior working in Betwixt using
> custom
> > > BeanCreator
> > > implementations.
> > >
> > > Thanks much,
> > >
> > > - Kevin
> > >
> >
> ------------------------------------------------------------------------
> > > ------
> > > This SF.net email is sponsored by:
> > > SourcForge Community
> > > SourceForge wants to tell your story.
> > > http://p.sf.net/sfu/sf-spreadtheword
> > >
> > >
> > > _______________________________________________
> > > Simple-support mailing list
> > > Sim...@li...
> > >
> >
> https://lists.sourceforge.net/lists/listinfo/simple-support
> > > Visit our website at http://www.ubs.com
> > >
> > > This message contains confidential information
> and is
> > > intended only for
> > > the individual named. If you are not the named
> > addressee
> > > you should not
> > > disseminate, distribute or copy this e-mail.
> Please
> > notify
> > > the sender
> > > immediately by e-mail if you have received this
> e-mail
> > by
> > > mistake and
> > > delete this e-mail from your system.
> > >
> > > E-mails are not encrypted and cannot be
> guaranteed to
> > be
> > > secure or
> > > error-free as information could be intercepted,
> > corrupted,
> > > lost,
> > > destroyed, arrive late or incomplete, or contain
> > viruses.
> > > The sender
> > > therefore does not accept liability for any
> errors or
> > > omissions in the
> > > contents of this message which arise as a result
> of
> > e-mail
> > > transmission.
> > >
> > > If verification is required please request a
> hard-copy
> > > version. This
> > > message is provided for informational purposes
> and
> > should
> > > not be
> > > construed as a solicitation or offer to buy or
> sell
> > any
> > > securities or
> > > related financial instruments.
> > >
> > > UBS Limited is a company registered in England
> &
> > Wales
> > > under company
> > > number 2035362, whose registered office is at 1
> > Finsbury
> > > Avenue, London,
> > > EC2M 2PP, United Kingdom.
> > >
> > > UBS AG (London Branch) is registered as a branch
> of a
> > > foreign company
> > > under number BR004507, whose registered office is
> at
> > > 1 Finsbury Avenue, London, EC2M 2PP, United
> Kingdom.
> > >
> > > UBS Clearing and Execution Services Limited is a
> > company
> > > registered in
> > > England & Wales under company number
> 03123037,
> > whose
> > > registered office
> > > is at 1 Finsbury Avenue, London, EC2M 2PP, United
> > Kingdom.
> > > Visit our website at http://www.ubs.com
> > >
> > > This message contains confidential information
> and is
> > > intended only
> > > for the individual named. If you are not the
> named
> > > addressee you
> > > should not disseminate, distribute or copy this
> > e-mail.
> > > Please
> > > notify the sender immediately by e-mail if you
> have
> > > received this
> > > e-mail by mistake and delete this e-mail from
> your
> > system.
> > >
> > > E-mails are not encrypted and cannot be
> guaranteed to
> > be
> > > secure or
> > > error-free as information could be intercepted,
> > corrupted,
> > > lost,
> > > destroyed, arrive late or incomplete, or contain
> > viruses.
> > > The sender
> > > therefore does not accept liability for any
> errors or
> > > omissions in the
> > > contents of this message which arise as a result
> of
> > e-mail
> > > transmission.
> > > If verification is required please request a
> hard-copy
> > > version. This
> > > message is provided for informational purposes
> and
> > should
> > > not be
> > > construed as a solicitation or offer to buy or
> sell
> > any
> > > securities
> > > or related financial instruments.
> > >
> > > UBS Limited is a company registered in England
> &
> > Wales
> > > under company
> > > number 2035362, whose registered office is at 1
> > Finsbury
> > > Avenue,
> > > London, EC2M 2PP, United Kingdom.
> > >
> > > UBS AG (London Branch) is registered as a branch
> of a
> > > foreign company
> > > under number BR004507, whose registered office is
> at
> > > 1 Finsbury Avenue, London, EC2M 2PP, United
> Kingdom.
> > >
> > > UBS Clearing and Execution Services Limited is a
> > company
> > > registered
> > > in England & Wales under company number
> 03123037,
> > whose
> > > registered
> > > office is at 1 Finsbury Avenue, London, EC2M 2PP,
> > United
> > > Kingdom.
> > >
> > >
> >
> ------------------------------------------------------------------------------
> > > This SF.net email is sponsored by:
> > > SourcForge Community
> > > SourceForge wants to tell your story.
> > > http://p.sf.net/sfu/sf-spreadtheword
> > > _______________________________________________
> > > Simple-support mailing list
> > > Sim...@li...
> > >
> >
> https://lists.sourceforge.net/lists/listinfo/simple-support
> >
> >
> >
> >
> >
> ------------------------------------------------------------------------------
> > This SF.net email is sponsored by:
> > SourcForge Community
> > SourceForge wants to tell your story.
> > http://p.sf.net/sfu/sf-spreadtheword
> > _______________________________________________
> > Simple-support mailing list
> > Sim...@li...
> >
> https://lists.sourceforge.net/lists/listinfo/simple-support
>
>
>
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by:
> SourcForge Community
> SourceForge wants to tell your story.
> http://p.sf.net/sfu/sf-spreadtheword
> _______________________________________________
> Simple-support mailing list
> Sim...@li...
> https://lists.sourceforge.net/lists/listinfo/simple-support
|
|
From: Niall G. <gal...@ya...> - 2009-01-26 19:40:54
|
Hi, Take a look at this. I will add this form of instantiation without a no-arg constructor in the next release. http://simple.svn.sourceforge.net/viewvc/simple/trunk/download/stream/src/test/java/org/simpleframework/xml/core/ObjectStreamClassTest.java?revision=1158&view=markup Let me know if this is suitable. Niall --- On Mon, 1/26/09, Niall Gallagher <gal...@ya...> wrote: > From: Niall Gallagher <gal...@ya...> > Subject: Re: [Simple-support] Using constructors with arguments > To: sim...@li..., "Kevin Day" <for...@tr...> > Date: Monday, January 26, 2009, 11:20 AM > Hi, > > Thanks for the feedback, if you have any suggestions I am > open to them. I was thinking of something like. > > > public class Tuple { > > @Attribute > private String name; > > @Element > private String value; > > public Tuple(@Inject String name, @Inject String value) > { > this.name = name; > this.value = value; > } > } > > This would make it readable and writable. Taking the > parameters and seeing where they can be injected. This would > be easy to write. > > Niall > > > --- On Mon, 1/26/09, Kevin Day > <for...@tr...> wrote: > > > From: Kevin Day <for...@tr...> > > Subject: Re: [Simple-support] Using constructors with > arguments > > To: sim...@li... > > Date: Monday, January 26, 2009, 10:51 AM > > Thanks for taking a look. I may be trying to use this > > framework for more than what it is intented to do. If > you > > are interested in pursuing some use-cases, I'd be > happy > > to work with you on aspects of the design, etc... But > I > > also understand that different projects have different > > goals, and direct encapsulation of business layer > objects > > (which are more likely to be required to be immutable) > may > > not be part of the goal of Simple-XML. > > > > Using the @Commit or a combination of > @Replace/@Resolve > > requires an aweful lot of coding that it seems a > persistence > > framework could address... Coding with the @Commit, > etc... > > style is roughly similar to using a JAXB generated > object > > structure for persistence, then having a bunch of > > translators written to convert persistent values into > > business objects and vice-versa. It can be done, but > > I'm looking for something a lot more elegant. > > > > > > I'm also fine with using a Strategy to achieve the > goal > > (I've implemented a really rough first cut at this > > already), but there may be a couple of challenges. > > > > As an example, my work so far indicates that the > Strategy > > interface can provide a hook for instantiation of > objects > > (i.e. via a factory that could use injected parameters > from > > a DI container) - however, unless I'm missing > something, > > it doesn't look like Strategy has access to the > Type > > objects generated from parsing the XML tree, which > means > > that I can't use objects recovered from the > > deserialization during instantiation. If the objects > are > > simple (String or something easily handled with the > > *Transform classes), then this is no big deal (we can > just > > instantiate from the Type object in the node map), but > for > > complicated objects, I'm not sure how to handle > it. > > > > This makes me wonder if I'm trying to get Strategy > to > > do something that it just isn't designed to do > (maybe > > this kind of thing should be implemented using a > different > > layer of the API), or if I can somehow use the map > passed > > into the getElement method to make this work. > > > > > > So, is it possible that the Instantiator class is the > place > > where this functionality needs to take place? If so, > then > > the Instantiator would need to have access to the > > deserialization's context during the call to > getType(). > > For example, if there were some way to obtain named > Type > > objects for the fields/values of the object being > > deserialized? These could be used to instantiate > values > > that could then be passed to a factory or constructor. > I > > suspect this would involve making a read-only view of > the > > Collector available to Instantiator. > > > > I'm not sure how much control Simple has over the > > *order* that instantiation occurs in, or whether this > would > > impact things. It appears that Simple builds the Type > > hierarchy before it starts instantiating objects, so > that > > should be OK (unless there is a cyclic reference in > the > > constructor parameters - but that won't happen in > a well > > designed object hierarchy :-) ) > > > > I'm wondering if you have a philosophical overview > of > > the Simple architecture captured anywhere? The > JavaDocs > > don't really provide a high level overview, and > the API > > has a *lot* of layers to it that make it difficult for > > someone new the source to get a handle on what types > of > > behavior should be implemented at which level. My > > assumption is that the system takes several logical > passes > > over the object hierarchy: > > > > Parse XML into nodes > > For each node, obtain it's Type (this is the job > of > > Strategy I think?) > > Determine the class for each Type and determine > it's > > fields/parameters/etc... and create Contacts for those > (this > > is the job of Scanner I think? And that interacts > with the > > Collector somehow) > > Use each Type to instantiate a concrete object and > inject > > it into the Contacts (I think the Collector does this) > > > > Is that approximately correct? > > > > - K > > > > > > > > > > > > > > > > ----------------------- Original Message > > ----------------------- > > > > From: <Nia...@ub...> > > To: <for...@tr...>, > > <sim...@li...> > > Cc: > > Date: Mon, 26 Jan 2009 09:11:54 -0000 > > Subject: RE: [Simple-support] Using constructors with > > arguments > > > > Hi, > > > > Ill take a look at the read resolve and write replace > > issues you > > mention. The reason @Replace and @Resolve do not work > in > > lists is they > > go through the Traverser object, rather than the > Composite > > object > > directly. This is something I will have to address. So > > there are two > > options, the first is to use a strategy (there should > be > > plenty of > > examples in the test cases), the second is to use > @Commit > > to build the > > Tuples like so. > > > > public class TupleDatabase { > > > > private List<Tuple> tuples; > > > > @ElementList > > private List<TupleEntry> entries; > > > > @Commit > > private void commit() { > > for(TupleEntry entry : entries) { > > tuples.add(entry.name, entry.value); > > } > > } > > > > @Root > > private static class TupleEntry { > > @Element String name; > > @Element String value; > > } > > } > > > > Here when building the list you can create the tuples > > without a no-arg > > constructor. > > > > Hope this helps, > > Niall > > > > -----Original Message----- > > From: Kevin Day [mailto:for...@tr...] > > Sent: 24 January 2009 00:21 > > To: sim...@li... > > Subject: Re: [Simple-support] Using constructors with > > arguments > > > > Thanks for the suggestion, this type of strategy is > exactly > > what we do > > with our current Java serialization based persistence, > so > > it's easy to > > relate to (even though there's a lot of duplicate > > code). > > > > > > For some reason, though, @Replace isn't working > (the > > getSubstitute() > > method is never called). > > > > After a bit of digging into the source, I think that > the > > problem is that > > the only place that Caller#replace() is actually > called is > > in > > Composite#writeReplace(). And that method is only > called > > for composite > > objects. We are dealing with a list of objects, so it > > seems that maybe > > writeReplace() hasn't been properly implemented > for > > ElementList > > handlers? > > > > If I place my object outside the list (as part of a > > composite element), > > then it serializes fine. > > > > > > Another issue I'm running into is during > > deserialization. In this case, > > I am using @Resolve on the replaced object (which is > part > > of a composite > > object structure). I set a break point on > > Composite.readResolve(), but > > readResolve never gets called. The framework throws > an > > InstantiationException from Factory#getOverride(). > > > > > > I'm not sure if the problem here is my lack of > > understanding of the API, > > or if this is just a corner case that didn't get > unit > > testing written > > for it. I am attaching a self contained unit test > case > > that exhibits > > all of the above behavior. Please let me know if you > have > > any > > pointers/suggestions, or if I may just be missing > > something! > > > > Cheers, > > > > - Kevin > > > > > > PS - I suspect that the use of @Replace and @Resolve > may > > not solve our > > entire use case, but it is a great start at a solution > and > > is helping me > > understand the Simple framework better. Our ultimate > need > > also includes > > injection of resources via a DI framework, and I'm > > having a hard time > > figuring out how that's going to happen without > using > > some sort of > > factory instantiation strategy (I suppose that we > could use > > a singleton > > to get the DI hook, but that's an anti-design > pattern > > that I really > > would prefer to avoid at all costs). Hopefully we can > > discuss this > > aspect a bit more after I understand why my @Replace > and > > @Resolve aren't > > working! > > > > > > > > > > > > ----------------------- Original Message > > ----------------------- > > > > From: <Nia...@ub...> > > To: <for...@tr...>, > > <sim...@li...> > > Cc: > > Date: Thu, 22 Jan 2009 16:45:15 -0000 > > Subject: RE: [Simple-support] Using constructors with > > arguments > > > > Hi, > > > > There is no need to do this. You can do the following. > > > > @Root > > public class Tuple { > > > > final private String from; > > final private String to; > > > > public Tuple(String from, String to){ > > this.from = from; > > this.to = to; > > } > > > > @Replace > > private TupleSubstitute getSubstitute() { > > return new TupleSubstitute(from, to); > > } > > > > public String getFrom() { > > return from; > > } > > > > public String getTo() { > > return to; > > } > > > > public String toString() { > > return from + " -> " + to; > > } > > > > } > > > > @Root > > private class TupleSubstitute { > > > > @Element > > private String from; > > @Element > > private String to; > > > > public TupleSubstitute() { > > super(); > > } > > > > public TupleSubstitute(String from, String to) { > > this.from = from; > > this.to = to; > > } > > > > @Resolve > > public Tuple getTuple() { > > return new Tuple(); > > } > > } > > > > This should work, for you. The @Resolve annotation > resolves > > the > > deserialized object before assigning it to the field > or > > method. The > > @Replace object replaces the object in the stream. > Just > > like java object > > serialization. Let me know how this works out for you. > > > > Hope this helps, > > Niall > > > > > > > > -----Original Message----- > > From: Kevin Day [mailto:for...@tr...] > > Sent: 21 January 2009 22:56 > > To: Simple (Java Project) > > Subject: Re: [Simple-support] Using constructors with > > arguments > > > > I've done some additional work on handling classes > that > > do not have > > zero-arg constructors. First, I've put together > some > > simple sample code > > (attached, start with TryIt#main) that shows one of > the > > situations we > > are facing: we have a number of immutable Tuple > objects > > that we need to > > serialize/deserialze. The values used in the Tuple > > class' constructor > > come from attributes (or elements) from the XML. The > > attached > > serializes fine, but we can't deserialize it b/c > of the > > lack of > > no-argument constructor. We can't add a no-arg > > constructor because the > > class is intended to be immutable (in fact, the fields > are > > marked as > > final). In addition, the sample code shows the Tuple > > values as holding > > simple strings - but in our application, the values > are > > going to be > > complex objects. > > > > > > I have put together a Strategy and Type implementation > that > > *kind* of > > works, but I'm running into some issues (may be > related > > to my lack of > > familiarity with the code base). > > > > The approach that I'm working on now creates a new > > Strategy that allows > > us to register special Type objects that can handle > object > > instantiation > > based on state of the deserialization process (for > now, > > I'm calling this > > FactoryGeneratedStrategy). Ideally, > > FactoryGeneratedStrategy would be > > able to inter-operate with any other Strategy > > (DefaultStrategy, > > CycleStrategy, TreeStrategy) - after all, it's > only > > purpose is to help > > instantiate objects during deserialization - the > behavior > > of the other > > strategies is still desirable. > > > > I ran into a couple of problems with this type of > Strategy > > chaining > > approach: > > > > 1. DefaultStrategy is not instantiable due to package > > scope visibility > > (this is the smaller issue) 2. The other strategies > appear > > to be > > implemented in a way that assumes use of zero-arg > > constructors. For > > example, CycleStrategy#getElement returns an Allocate > > object depending > > on the deserialization state. The Allocate object is > > ultimately backed > > by an Instance object as it's delegate Type. > Instance > > assumes a > > zero-arg constructor. > > > > > > Short of re-implementing all of the *Strategy classes, > I > > can't see how > > to go about providing a factory to create new object > > instances (without > > losing functionality provided by various Strategy > classes). > > > > > > My initial impression based on the above is that > Strategy > > may not be the > > appropriate place in the hierarchy to add object > > instantiation behavior. > > If not, where? The Instantiator class seems a likely > > candidate, except > > that it's getInstace() method doesn't have > access > > to deserialization > > context information. > > > > > > > > Maybe I'm just going about this all wrong... If > anyone > > can provide some > > suggestions, I'd love to hear them! > > > > > > Thanks, > > > > - K > > > > > > ----------------------- Original Message > > ----------------------- > > > > From: Kevin Day <ke...@tr...> > > To: Simple (Java Project) > > <sim...@li...> > > Cc: > > Date: Tue, 20 Jan 2009 17:28:05 -0700 > > Subject: [Simple-support] Using constructors with > arguments > > > > For starters, I really like what I see in this project > > (just started > > reviewing it this afternoon). I'm hoping that I > can > > get some pointers > > on a specific use-case. > > > > > > I would like to use Simple in conjunction with a > dependency > > injection > > system (probably Guice) and List implementations from > the > > GlazedLists > > project. > > > > We have to use a constructor on our list > implementations > > that contains > > arguments (some of the arguments provided by Guice, > some > > from element or > > attribute data in the XML). > > > > What is the best way to approach this with Simple? > > > > It seems that some sort of Strategy mixed with a > custom > > Type is in > > order, but I'm not entirely clear on the best > approach. > > The > > architecture of the framework looks powerful enough to > do > > what we need, > > but I can't see where to get started just yet. > > > > > > To give a pseudo-code example of what we are trying to > do > > (in real life, > > we'll be injecting SomeInjectedObject using Guice > or a > > factory/service > > provider call): > > > > class SpecialList<E>{ > > public SpecialList(SomeInjectedObject injected, String > > valueFromAttribute, SomeObject valueFromElement){ ... > > } > > } > > > > > > class MyObject{ > > @ElementList > > SpecialList<ElementObject> list = new > > > SpecialList<ElementObject>(SomeInjectedObject.defaultInstance, > > "test", > > new SomeObject()); > > > > } > > > > > > When we serialize this with Simple, we'd like to > see > > something > > approximately like the following: > > > > <myObject valueFromAttribute="test"> > > <someObject> ... </someObject> > > <list> > > <elementObject> ... whatever goes into this ... > > </elementObject> > > <elementObject> ... whatever goes into this ... > > </elementObject> ... > > </list> > > </myObject> > > > > > > Note that: > > > > 1. The <list> element doesn't have a class > > attribute 2. When we > > construct the list during deserialization, we need to > be > > able to pull > > the 'valueFromAttribute' and > 'someObject' > > values to use during > > construction of the SpecialList object 3. The > SpecialList > > object needs > > to have the 3 argument constructor called (not a > zero-arg > > constructor). > > And it is not possible to call a zero arg constructor, > then > > modify the > > object afterwards to get the same result. > > > > > > Any pointers? I may be pushing the framework too hard > > (some of the > > above requirements can be relaxed - if it isn't > > possible to obtain > > valueFromAttribute or someObject at construction time, > we > > can find > > workarounds - but we have to be able to create the > > SpecialList instance > > using values from a factory/Guice/etc...). For what > > it's worth, we have > > this type of behavior working in Betwixt using custom > > BeanCreator > > implementations. > > > > Thanks much, > > > > - Kevin > > > ------------------------------------------------------------------------ > > ------ > > This SF.net email is sponsored by: > > SourcForge Community > > SourceForge wants to tell your story. > > http://p.sf.net/sfu/sf-spreadtheword > > > > > > _______________________________________________ > > Simple-support mailing list > > Sim...@li... > > > https://lists.sourceforge.net/lists/listinfo/simple-support > > Visit our website at http://www.ubs.com > > > > This message contains confidential information and is > > intended only for > > the individual named. If you are not the named > addressee > > you should not > > disseminate, distribute or copy this e-mail. Please > notify > > the sender > > immediately by e-mail if you have received this e-mail > by > > mistake and > > delete this e-mail from your system. > > > > E-mails are not encrypted and cannot be guaranteed to > be > > secure or > > error-free as information could be intercepted, > corrupted, > > lost, > > destroyed, arrive late or incomplete, or contain > viruses. > > The sender > > therefore does not accept liability for any errors or > > omissions in the > > contents of this message which arise as a result of > e-mail > > transmission. > > > > If verification is required please request a hard-copy > > version. This > > message is provided for informational purposes and > should > > not be > > construed as a solicitation or offer to buy or sell > any > > securities or > > related financial instruments. > > > > UBS Limited is a company registered in England & > Wales > > under company > > number 2035362, whose registered office is at 1 > Finsbury > > Avenue, London, > > EC2M 2PP, United Kingdom. > > > > UBS AG (London Branch) is registered as a branch of a > > foreign company > > under number BR004507, whose registered office is at > > 1 Finsbury Avenue, London, EC2M 2PP, United Kingdom. > > > > UBS Clearing and Execution Services Limited is a > company > > registered in > > England & Wales under company number 03123037, > whose > > registered office > > is at 1 Finsbury Avenue, London, EC2M 2PP, United > Kingdom. > > Visit our website at http://www.ubs.com > > > > This message contains confidential information and is > > intended only > > for the individual named. If you are not the named > > addressee you > > should not disseminate, distribute or copy this > e-mail. > > Please > > notify the sender immediately by e-mail if you have > > received this > > e-mail by mistake and delete this e-mail from your > system. > > > > E-mails are not encrypted and cannot be guaranteed to > be > > secure or > > error-free as information could be intercepted, > corrupted, > > lost, > > destroyed, arrive late or incomplete, or contain > viruses. > > The sender > > therefore does not accept liability for any errors or > > omissions in the > > contents of this message which arise as a result of > e-mail > > transmission. > > If verification is required please request a hard-copy > > version. This > > message is provided for informational purposes and > should > > not be > > construed as a solicitation or offer to buy or sell > any > > securities > > or related financial instruments. > > > > UBS Limited is a company registered in England & > Wales > > under company > > number 2035362, whose registered office is at 1 > Finsbury > > Avenue, > > London, EC2M 2PP, United Kingdom. > > > > UBS AG (London Branch) is registered as a branch of a > > foreign company > > under number BR004507, whose registered office is at > > 1 Finsbury Avenue, London, EC2M 2PP, United Kingdom. > > > > UBS Clearing and Execution Services Limited is a > company > > registered > > in England & Wales under company number 03123037, > whose > > registered > > office is at 1 Finsbury Avenue, London, EC2M 2PP, > United > > Kingdom. > > > > > ------------------------------------------------------------------------------ > > This SF.net email is sponsored by: > > SourcForge Community > > SourceForge wants to tell your story. > > http://p.sf.net/sfu/sf-spreadtheword > > _______________________________________________ > > Simple-support mailing list > > Sim...@li... > > > https://lists.sourceforge.net/lists/listinfo/simple-support > > > > > ------------------------------------------------------------------------------ > This SF.net email is sponsored by: > SourcForge Community > SourceForge wants to tell your story. > http://p.sf.net/sfu/sf-spreadtheword > _______________________________________________ > Simple-support mailing list > Sim...@li... > https://lists.sourceforge.net/lists/listinfo/simple-support |
|
From: Niall G. <gal...@ya...> - 2009-01-26 19:20:43
|
Hi,
Thanks for the feedback, if you have any suggestions I am open to them. I was thinking of something like.
public class Tuple {
@Attribute
private String name;
@Element
private String value;
public Tuple(@Inject String name, @Inject String value) {
this.name = name;
this.value = value;
}
}
This would make it readable and writable. Taking the parameters and seeing where they can be injected. This would be easy to write.
Niall
--- On Mon, 1/26/09, Kevin Day <for...@tr...> wrote:
> From: Kevin Day <for...@tr...>
> Subject: Re: [Simple-support] Using constructors with arguments
> To: sim...@li...
> Date: Monday, January 26, 2009, 10:51 AM
> Thanks for taking a look. I may be trying to use this
> framework for more than what it is intented to do. If you
> are interested in pursuing some use-cases, I'd be happy
> to work with you on aspects of the design, etc... But I
> also understand that different projects have different
> goals, and direct encapsulation of business layer objects
> (which are more likely to be required to be immutable) may
> not be part of the goal of Simple-XML.
>
> Using the @Commit or a combination of @Replace/@Resolve
> requires an aweful lot of coding that it seems a persistence
> framework could address... Coding with the @Commit, etc...
> style is roughly similar to using a JAXB generated object
> structure for persistence, then having a bunch of
> translators written to convert persistent values into
> business objects and vice-versa. It can be done, but
> I'm looking for something a lot more elegant.
>
>
> I'm also fine with using a Strategy to achieve the goal
> (I've implemented a really rough first cut at this
> already), but there may be a couple of challenges.
>
> As an example, my work so far indicates that the Strategy
> interface can provide a hook for instantiation of objects
> (i.e. via a factory that could use injected parameters from
> a DI container) - however, unless I'm missing something,
> it doesn't look like Strategy has access to the Type
> objects generated from parsing the XML tree, which means
> that I can't use objects recovered from the
> deserialization during instantiation. If the objects are
> simple (String or something easily handled with the
> *Transform classes), then this is no big deal (we can just
> instantiate from the Type object in the node map), but for
> complicated objects, I'm not sure how to handle it.
>
> This makes me wonder if I'm trying to get Strategy to
> do something that it just isn't designed to do (maybe
> this kind of thing should be implemented using a different
> layer of the API), or if I can somehow use the map passed
> into the getElement method to make this work.
>
>
> So, is it possible that the Instantiator class is the place
> where this functionality needs to take place? If so, then
> the Instantiator would need to have access to the
> deserialization's context during the call to getType().
> For example, if there were some way to obtain named Type
> objects for the fields/values of the object being
> deserialized? These could be used to instantiate values
> that could then be passed to a factory or constructor. I
> suspect this would involve making a read-only view of the
> Collector available to Instantiator.
>
> I'm not sure how much control Simple has over the
> *order* that instantiation occurs in, or whether this would
> impact things. It appears that Simple builds the Type
> hierarchy before it starts instantiating objects, so that
> should be OK (unless there is a cyclic reference in the
> constructor parameters - but that won't happen in a well
> designed object hierarchy :-) )
>
> I'm wondering if you have a philosophical overview of
> the Simple architecture captured anywhere? The JavaDocs
> don't really provide a high level overview, and the API
> has a *lot* of layers to it that make it difficult for
> someone new the source to get a handle on what types of
> behavior should be implemented at which level. My
> assumption is that the system takes several logical passes
> over the object hierarchy:
>
> Parse XML into nodes
> For each node, obtain it's Type (this is the job of
> Strategy I think?)
> Determine the class for each Type and determine it's
> fields/parameters/etc... and create Contacts for those (this
> is the job of Scanner I think? And that interacts with the
> Collector somehow)
> Use each Type to instantiate a concrete object and inject
> it into the Contacts (I think the Collector does this)
>
> Is that approximately correct?
>
> - K
>
>
>
>
>
>
>
> ----------------------- Original Message
> -----------------------
>
> From: <Nia...@ub...>
> To: <for...@tr...>,
> <sim...@li...>
> Cc:
> Date: Mon, 26 Jan 2009 09:11:54 -0000
> Subject: RE: [Simple-support] Using constructors with
> arguments
>
> Hi,
>
> Ill take a look at the read resolve and write replace
> issues you
> mention. The reason @Replace and @Resolve do not work in
> lists is they
> go through the Traverser object, rather than the Composite
> object
> directly. This is something I will have to address. So
> there are two
> options, the first is to use a strategy (there should be
> plenty of
> examples in the test cases), the second is to use @Commit
> to build the
> Tuples like so.
>
> public class TupleDatabase {
>
> private List<Tuple> tuples;
>
> @ElementList
> private List<TupleEntry> entries;
>
> @Commit
> private void commit() {
> for(TupleEntry entry : entries) {
> tuples.add(entry.name, entry.value);
> }
> }
>
> @Root
> private static class TupleEntry {
> @Element String name;
> @Element String value;
> }
> }
>
> Here when building the list you can create the tuples
> without a no-arg
> constructor.
>
> Hope this helps,
> Niall
>
> -----Original Message-----
> From: Kevin Day [mailto:for...@tr...]
> Sent: 24 January 2009 00:21
> To: sim...@li...
> Subject: Re: [Simple-support] Using constructors with
> arguments
>
> Thanks for the suggestion, this type of strategy is exactly
> what we do
> with our current Java serialization based persistence, so
> it's easy to
> relate to (even though there's a lot of duplicate
> code).
>
>
> For some reason, though, @Replace isn't working (the
> getSubstitute()
> method is never called).
>
> After a bit of digging into the source, I think that the
> problem is that
> the only place that Caller#replace() is actually called is
> in
> Composite#writeReplace(). And that method is only called
> for composite
> objects. We are dealing with a list of objects, so it
> seems that maybe
> writeReplace() hasn't been properly implemented for
> ElementList
> handlers?
>
> If I place my object outside the list (as part of a
> composite element),
> then it serializes fine.
>
>
> Another issue I'm running into is during
> deserialization. In this case,
> I am using @Resolve on the replaced object (which is part
> of a composite
> object structure). I set a break point on
> Composite.readResolve(), but
> readResolve never gets called. The framework throws an
> InstantiationException from Factory#getOverride().
>
>
> I'm not sure if the problem here is my lack of
> understanding of the API,
> or if this is just a corner case that didn't get unit
> testing written
> for it. I am attaching a self contained unit test case
> that exhibits
> all of the above behavior. Please let me know if you have
> any
> pointers/suggestions, or if I may just be missing
> something!
>
> Cheers,
>
> - Kevin
>
>
> PS - I suspect that the use of @Replace and @Resolve may
> not solve our
> entire use case, but it is a great start at a solution and
> is helping me
> understand the Simple framework better. Our ultimate need
> also includes
> injection of resources via a DI framework, and I'm
> having a hard time
> figuring out how that's going to happen without using
> some sort of
> factory instantiation strategy (I suppose that we could use
> a singleton
> to get the DI hook, but that's an anti-design pattern
> that I really
> would prefer to avoid at all costs). Hopefully we can
> discuss this
> aspect a bit more after I understand why my @Replace and
> @Resolve aren't
> working!
>
>
>
>
>
> ----------------------- Original Message
> -----------------------
>
> From: <Nia...@ub...>
> To: <for...@tr...>,
> <sim...@li...>
> Cc:
> Date: Thu, 22 Jan 2009 16:45:15 -0000
> Subject: RE: [Simple-support] Using constructors with
> arguments
>
> Hi,
>
> There is no need to do this. You can do the following.
>
> @Root
> public class Tuple {
>
> final private String from;
> final private String to;
>
> public Tuple(String from, String to){
> this.from = from;
> this.to = to;
> }
>
> @Replace
> private TupleSubstitute getSubstitute() {
> return new TupleSubstitute(from, to);
> }
>
> public String getFrom() {
> return from;
> }
>
> public String getTo() {
> return to;
> }
>
> public String toString() {
> return from + " -> " + to;
> }
>
> }
>
> @Root
> private class TupleSubstitute {
>
> @Element
> private String from;
> @Element
> private String to;
>
> public TupleSubstitute() {
> super();
> }
>
> public TupleSubstitute(String from, String to) {
> this.from = from;
> this.to = to;
> }
>
> @Resolve
> public Tuple getTuple() {
> return new Tuple();
> }
> }
>
> This should work, for you. The @Resolve annotation resolves
> the
> deserialized object before assigning it to the field or
> method. The
> @Replace object replaces the object in the stream. Just
> like java object
> serialization. Let me know how this works out for you.
>
> Hope this helps,
> Niall
>
>
>
> -----Original Message-----
> From: Kevin Day [mailto:for...@tr...]
> Sent: 21 January 2009 22:56
> To: Simple (Java Project)
> Subject: Re: [Simple-support] Using constructors with
> arguments
>
> I've done some additional work on handling classes that
> do not have
> zero-arg constructors. First, I've put together some
> simple sample code
> (attached, start with TryIt#main) that shows one of the
> situations we
> are facing: we have a number of immutable Tuple objects
> that we need to
> serialize/deserialze. The values used in the Tuple
> class' constructor
> come from attributes (or elements) from the XML. The
> attached
> serializes fine, but we can't deserialize it b/c of the
> lack of
> no-argument constructor. We can't add a no-arg
> constructor because the
> class is intended to be immutable (in fact, the fields are
> marked as
> final). In addition, the sample code shows the Tuple
> values as holding
> simple strings - but in our application, the values are
> going to be
> complex objects.
>
>
> I have put together a Strategy and Type implementation that
> *kind* of
> works, but I'm running into some issues (may be related
> to my lack of
> familiarity with the code base).
>
> The approach that I'm working on now creates a new
> Strategy that allows
> us to register special Type objects that can handle object
> instantiation
> based on state of the deserialization process (for now,
> I'm calling this
> FactoryGeneratedStrategy). Ideally,
> FactoryGeneratedStrategy would be
> able to inter-operate with any other Strategy
> (DefaultStrategy,
> CycleStrategy, TreeStrategy) - after all, it's only
> purpose is to help
> instantiate objects during deserialization - the behavior
> of the other
> strategies is still desirable.
>
> I ran into a couple of problems with this type of Strategy
> chaining
> approach:
>
> 1. DefaultStrategy is not instantiable due to package
> scope visibility
> (this is the smaller issue) 2. The other strategies appear
> to be
> implemented in a way that assumes use of zero-arg
> constructors. For
> example, CycleStrategy#getElement returns an Allocate
> object depending
> on the deserialization state. The Allocate object is
> ultimately backed
> by an Instance object as it's delegate Type. Instance
> assumes a
> zero-arg constructor.
>
>
> Short of re-implementing all of the *Strategy classes, I
> can't see how
> to go about providing a factory to create new object
> instances (without
> losing functionality provided by various Strategy classes).
>
>
> My initial impression based on the above is that Strategy
> may not be the
> appropriate place in the hierarchy to add object
> instantiation behavior.
> If not, where? The Instantiator class seems a likely
> candidate, except
> that it's getInstace() method doesn't have access
> to deserialization
> context information.
>
>
>
> Maybe I'm just going about this all wrong... If anyone
> can provide some
> suggestions, I'd love to hear them!
>
>
> Thanks,
>
> - K
>
>
> ----------------------- Original Message
> -----------------------
>
> From: Kevin Day <ke...@tr...>
> To: Simple (Java Project)
> <sim...@li...>
> Cc:
> Date: Tue, 20 Jan 2009 17:28:05 -0700
> Subject: [Simple-support] Using constructors with arguments
>
> For starters, I really like what I see in this project
> (just started
> reviewing it this afternoon). I'm hoping that I can
> get some pointers
> on a specific use-case.
>
>
> I would like to use Simple in conjunction with a dependency
> injection
> system (probably Guice) and List implementations from the
> GlazedLists
> project.
>
> We have to use a constructor on our list implementations
> that contains
> arguments (some of the arguments provided by Guice, some
> from element or
> attribute data in the XML).
>
> What is the best way to approach this with Simple?
>
> It seems that some sort of Strategy mixed with a custom
> Type is in
> order, but I'm not entirely clear on the best approach.
> The
> architecture of the framework looks powerful enough to do
> what we need,
> but I can't see where to get started just yet.
>
>
> To give a pseudo-code example of what we are trying to do
> (in real life,
> we'll be injecting SomeInjectedObject using Guice or a
> factory/service
> provider call):
>
> class SpecialList<E>{
> public SpecialList(SomeInjectedObject injected, String
> valueFromAttribute, SomeObject valueFromElement){ ...
> }
> }
>
>
> class MyObject{
> @ElementList
> SpecialList<ElementObject> list = new
> SpecialList<ElementObject>(SomeInjectedObject.defaultInstance,
> "test",
> new SomeObject());
>
> }
>
>
> When we serialize this with Simple, we'd like to see
> something
> approximately like the following:
>
> <myObject valueFromAttribute="test">
> <someObject> ... </someObject>
> <list>
> <elementObject> ... whatever goes into this ...
> </elementObject>
> <elementObject> ... whatever goes into this ...
> </elementObject> ...
> </list>
> </myObject>
>
>
> Note that:
>
> 1. The <list> element doesn't have a class
> attribute 2. When we
> construct the list during deserialization, we need to be
> able to pull
> the 'valueFromAttribute' and 'someObject'
> values to use during
> construction of the SpecialList object 3. The SpecialList
> object needs
> to have the 3 argument constructor called (not a zero-arg
> constructor).
> And it is not possible to call a zero arg constructor, then
> modify the
> object afterwards to get the same result.
>
>
> Any pointers? I may be pushing the framework too hard
> (some of the
> above requirements can be relaxed - if it isn't
> possible to obtain
> valueFromAttribute or someObject at construction time, we
> can find
> workarounds - but we have to be able to create the
> SpecialList instance
> using values from a factory/Guice/etc...). For what
> it's worth, we have
> this type of behavior working in Betwixt using custom
> BeanCreator
> implementations.
>
> Thanks much,
>
> - Kevin
> ------------------------------------------------------------------------
> ------
> This SF.net email is sponsored by:
> SourcForge Community
> SourceForge wants to tell your story.
> http://p.sf.net/sfu/sf-spreadtheword
>
>
> _______________________________________________
> Simple-support mailing list
> Sim...@li...
> https://lists.sourceforge.net/lists/listinfo/simple-support
> Visit our website at http://www.ubs.com
>
> This message contains confidential information and is
> intended only for
> the individual named. If you are not the named addressee
> you should not
> disseminate, distribute or copy this e-mail. Please notify
> the sender
> immediately by e-mail if you have received this e-mail by
> mistake and
> delete this e-mail from your system.
>
> E-mails are not encrypted and cannot be guaranteed to be
> secure or
> error-free as information could be intercepted, corrupted,
> lost,
> destroyed, arrive late or incomplete, or contain viruses.
> The sender
> therefore does not accept liability for any errors or
> omissions in the
> contents of this message which arise as a result of e-mail
> transmission.
>
> If verification is required please request a hard-copy
> version. This
> message is provided for informational purposes and should
> not be
> construed as a solicitation or offer to buy or sell any
> securities or
> related financial instruments.
>
> UBS Limited is a company registered in England & Wales
> under company
> number 2035362, whose registered office is at 1 Finsbury
> Avenue, London,
> EC2M 2PP, United Kingdom.
>
> UBS AG (London Branch) is registered as a branch of a
> foreign company
> under number BR004507, whose registered office is at
> 1 Finsbury Avenue, London, EC2M 2PP, United Kingdom.
>
> UBS Clearing and Execution Services Limited is a company
> registered in
> England & Wales under company number 03123037, whose
> registered office
> is at 1 Finsbury Avenue, London, EC2M 2PP, United Kingdom.
> Visit our website at http://www.ubs.com
>
> This message contains confidential information and is
> intended only
> for the individual named. If you are not the named
> addressee you
> should not disseminate, distribute or copy this e-mail.
> Please
> notify the sender immediately by e-mail if you have
> received this
> e-mail by mistake and delete this e-mail from your system.
>
> E-mails are not encrypted and cannot be guaranteed to be
> secure or
> error-free as information could be intercepted, corrupted,
> lost,
> destroyed, arrive late or incomplete, or contain viruses.
> The sender
> therefore does not accept liability for any errors or
> omissions in the
> contents of this message which arise as a result of e-mail
> transmission.
> If verification is required please request a hard-copy
> version. This
> message is provided for informational purposes and should
> not be
> construed as a solicitation or offer to buy or sell any
> securities
> or related financial instruments.
>
> UBS Limited is a company registered in England & Wales
> under company
> number 2035362, whose registered office is at 1 Finsbury
> Avenue,
> London, EC2M 2PP, United Kingdom.
>
> UBS AG (London Branch) is registered as a branch of a
> foreign company
> under number BR004507, whose registered office is at
> 1 Finsbury Avenue, London, EC2M 2PP, United Kingdom.
>
> UBS Clearing and Execution Services Limited is a company
> registered
> in England & Wales under company number 03123037, whose
> registered
> office is at 1 Finsbury Avenue, London, EC2M 2PP, United
> Kingdom.
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by:
> SourcForge Community
> SourceForge wants to tell your story.
> http://p.sf.net/sfu/sf-spreadtheword
> _______________________________________________
> Simple-support mailing list
> Sim...@li...
> https://lists.sourceforge.net/lists/listinfo/simple-support
|
|
From: Kevin D. <for...@tr...> - 2009-01-26 18:51:57
|
Thanks for taking a look. I may be trying to use this framework for more than what it is intented to do. If you are interested in pursuing some use-cases, I'd be happy to work with you on aspects of the design, etc... But I also understand that different projects have different goals, and direct encapsulation of business layer objects (which are more likely to be required to be immutable) may not be part of the goal of Simple-XML.
Using the @Commit or a combination of @Replace/@Resolve requires an aweful lot of coding that it seems a persistence framework could address... Coding with the @Commit, etc... style is roughly similar to using a JAXB generated object structure for persistence, then having a bunch of translators written to convert persistent values into business objects and vice-versa. It can be done, but I'm looking for something a lot more elegant.
I'm also fine with using a Strategy to achieve the goal (I've implemented a really rough first cut at this already), but there may be a couple of challenges.
As an example, my work so far indicates that the Strategy interface can provide a hook for instantiation of objects (i.e. via a factory that could use injected parameters from a DI container) - however, unless I'm missing something, it doesn't look like Strategy has access to the Type objects generated from parsing the XML tree, which means that I can't use objects recovered from the deserialization during instantiation. If the objects are simple (String or something easily handled with the *Transform classes), then this is no big deal (we can just instantiate from the Type object in the node map), but for complicated objects, I'm not sure how to handle it.
This makes me wonder if I'm trying to get Strategy to do something that it just isn't designed to do (maybe this kind of thing should be implemented using a different layer of the API), or if I can somehow use the map passed into the getElement method to make this work.
So, is it possible that the Instantiator class is the place where this functionality needs to take place? If so, then the Instantiator would need to have access to the deserialization's context during the call to getType(). For example, if there were some way to obtain named Type objects for the fields/values of the object being deserialized? These could be used to instantiate values that could then be passed to a factory or constructor. I suspect this would involve making a read-only view of the Collector available to Instantiator.
I'm not sure how much control Simple has over the *order* that instantiation occurs in, or whether this would impact things. It appears that Simple builds the Type hierarchy before it starts instantiating objects, so that should be OK (unless there is a cyclic reference in the constructor parameters - but that won't happen in a well designed object hierarchy :-) )
I'm wondering if you have a philosophical overview of the Simple architecture captured anywhere? The JavaDocs don't really provide a high level overview, and the API has a *lot* of layers to it that make it difficult for someone new the source to get a handle on what types of behavior should be implemented at which level. My assumption is that the system takes several logical passes over the object hierarchy:
Parse XML into nodes
For each node, obtain it's Type (this is the job of Strategy I think?)
Determine the class for each Type and determine it's fields/parameters/etc... and create Contacts for those (this is the job of Scanner I think? And that interacts with the Collector somehow)
Use each Type to instantiate a concrete object and inject it into the Contacts (I think the Collector does this)
Is that approximately correct?
- K
----------------------- Original Message -----------------------
From: <Nia...@ub...>
To: <for...@tr...>, <sim...@li...>
Cc:
Date: Mon, 26 Jan 2009 09:11:54 -0000
Subject: RE: [Simple-support] Using constructors with arguments
Hi,
Ill take a look at the read resolve and write replace issues you
mention. The reason @Replace and @Resolve do not work in lists is they
go through the Traverser object, rather than the Composite object
directly. This is something I will have to address. So there are two
options, the first is to use a strategy (there should be plenty of
examples in the test cases), the second is to use @Commit to build the
Tuples like so.
public class TupleDatabase {
private List<Tuple> tuples;
@ElementList
private List<TupleEntry> entries;
@Commit
private void commit() {
for(TupleEntry entry : entries) {
tuples.add(entry.name, entry.value);
}
}
@Root
private static class TupleEntry {
@Element String name;
@Element String value;
}
}
Here when building the list you can create the tuples without a no-arg
constructor.
Hope this helps,
Niall
-----Original Message-----
From: Kevin Day [mailto:for...@tr...]
Sent: 24 January 2009 00:21
To: sim...@li...
Subject: Re: [Simple-support] Using constructors with arguments
Thanks for the suggestion, this type of strategy is exactly what we do
with our current Java serialization based persistence, so it's easy to
relate to (even though there's a lot of duplicate code).
For some reason, though, @Replace isn't working (the getSubstitute()
method is never called).
After a bit of digging into the source, I think that the problem is that
the only place that Caller#replace() is actually called is in
Composite#writeReplace(). And that method is only called for composite
objects. We are dealing with a list of objects, so it seems that maybe
writeReplace() hasn't been properly implemented for ElementList
handlers?
If I place my object outside the list (as part of a composite element),
then it serializes fine.
Another issue I'm running into is during deserialization. In this case,
I am using @Resolve on the replaced object (which is part of a composite
object structure). I set a break point on Composite.readResolve(), but
readResolve never gets called. The framework throws an
InstantiationException from Factory#getOverride().
I'm not sure if the problem here is my lack of understanding of the API,
or if this is just a corner case that didn't get unit testing written
for it. I am attaching a self contained unit test case that exhibits
all of the above behavior. Please let me know if you have any
pointers/suggestions, or if I may just be missing something!
Cheers,
- Kevin
PS - I suspect that the use of @Replace and @Resolve may not solve our
entire use case, but it is a great start at a solution and is helping me
understand the Simple framework better. Our ultimate need also includes
injection of resources via a DI framework, and I'm having a hard time
figuring out how that's going to happen without using some sort of
factory instantiation strategy (I suppose that we could use a singleton
to get the DI hook, but that's an anti-design pattern that I really
would prefer to avoid at all costs). Hopefully we can discuss this
aspect a bit more after I understand why my @Replace and @Resolve aren't
working!
----------------------- Original Message -----------------------
From: <Nia...@ub...>
To: <for...@tr...>, <sim...@li...>
Cc:
Date: Thu, 22 Jan 2009 16:45:15 -0000
Subject: RE: [Simple-support] Using constructors with arguments
Hi,
There is no need to do this. You can do the following.
@Root
public class Tuple {
final private String from;
final private String to;
public Tuple(String from, String to){
this.from = from;
this.to = to;
}
@Replace
private TupleSubstitute getSubstitute() {
return new TupleSubstitute(from, to);
}
public String getFrom() {
return from;
}
public String getTo() {
return to;
}
public String toString() {
return from + " -> " + to;
}
}
@Root
private class TupleSubstitute {
@Element
private String from;
@Element
private String to;
public TupleSubstitute() {
super();
}
public TupleSubstitute(String from, String to) {
this.from = from;
this.to = to;
}
@Resolve
public Tuple getTuple() {
return new Tuple();
}
}
This should work, for you. The @Resolve annotation resolves the
deserialized object before assigning it to the field or method. The
@Replace object replaces the object in the stream. Just like java object
serialization. Let me know how this works out for you.
Hope this helps,
Niall
-----Original Message-----
From: Kevin Day [mailto:for...@tr...]
Sent: 21 January 2009 22:56
To: Simple (Java Project)
Subject: Re: [Simple-support] Using constructors with arguments
I've done some additional work on handling classes that do not have
zero-arg constructors. First, I've put together some simple sample code
(attached, start with TryIt#main) that shows one of the situations we
are facing: we have a number of immutable Tuple objects that we need to
serialize/deserialze. The values used in the Tuple class' constructor
come from attributes (or elements) from the XML. The attached
serializes fine, but we can't deserialize it b/c of the lack of
no-argument constructor. We can't add a no-arg constructor because the
class is intended to be immutable (in fact, the fields are marked as
final). In addition, the sample code shows the Tuple values as holding
simple strings - but in our application, the values are going to be
complex objects.
I have put together a Strategy and Type implementation that *kind* of
works, but I'm running into some issues (may be related to my lack of
familiarity with the code base).
The approach that I'm working on now creates a new Strategy that allows
us to register special Type objects that can handle object instantiation
based on state of the deserialization process (for now, I'm calling this
FactoryGeneratedStrategy). Ideally, FactoryGeneratedStrategy would be
able to inter-operate with any other Strategy (DefaultStrategy,
CycleStrategy, TreeStrategy) - after all, it's only purpose is to help
instantiate objects during deserialization - the behavior of the other
strategies is still desirable.
I ran into a couple of problems with this type of Strategy chaining
approach:
1. DefaultStrategy is not instantiable due to package scope visibility
(this is the smaller issue) 2. The other strategies appear to be
implemented in a way that assumes use of zero-arg constructors. For
example, CycleStrategy#getElement returns an Allocate object depending
on the deserialization state. The Allocate object is ultimately backed
by an Instance object as it's delegate Type. Instance assumes a
zero-arg constructor.
Short of re-implementing all of the *Strategy classes, I can't see how
to go about providing a factory to create new object instances (without
losing functionality provided by various Strategy classes).
My initial impression based on the above is that Strategy may not be the
appropriate place in the hierarchy to add object instantiation behavior.
If not, where? The Instantiator class seems a likely candidate, except
that it's getInstace() method doesn't have access to deserialization
context information.
Maybe I'm just going about this all wrong... If anyone can provide some
suggestions, I'd love to hear them!
Thanks,
- K
----------------------- Original Message -----------------------
From: Kevin Day <ke...@tr...>
To: Simple (Java Project) <sim...@li...>
Cc:
Date: Tue, 20 Jan 2009 17:28:05 -0700
Subject: [Simple-support] Using constructors with arguments
For starters, I really like what I see in this project (just started
reviewing it this afternoon). I'm hoping that I can get some pointers
on a specific use-case.
I would like to use Simple in conjunction with a dependency injection
system (probably Guice) and List implementations from the GlazedLists
project.
We have to use a constructor on our list implementations that contains
arguments (some of the arguments provided by Guice, some from element or
attribute data in the XML).
What is the best way to approach this with Simple?
It seems that some sort of Strategy mixed with a custom Type is in
order, but I'm not entirely clear on the best approach. The
architecture of the framework looks powerful enough to do what we need,
but I can't see where to get started just yet.
To give a pseudo-code example of what we are trying to do (in real life,
we'll be injecting SomeInjectedObject using Guice or a factory/service
provider call):
class SpecialList<E>{
public SpecialList(SomeInjectedObject injected, String
valueFromAttribute, SomeObject valueFromElement){ ...
}
}
class MyObject{
@ElementList
SpecialList<ElementObject> list = new
SpecialList<ElementObject>(SomeInjectedObject.defaultInstance, "test",
new SomeObject());
}
When we serialize this with Simple, we'd like to see something
approximately like the following:
<myObject valueFromAttribute="test">
<someObject> ... </someObject>
<list>
<elementObject> ... whatever goes into this ... </elementObject>
<elementObject> ... whatever goes into this ... </elementObject> ...
</list>
</myObject>
Note that:
1. The <list> element doesn't have a class attribute 2. When we
construct the list during deserialization, we need to be able to pull
the 'valueFromAttribute' and 'someObject' values to use during
construction of the SpecialList object 3. The SpecialList object needs
to have the 3 argument constructor called (not a zero-arg constructor).
And it is not possible to call a zero arg constructor, then modify the
object afterwards to get the same result.
Any pointers? I may be pushing the framework too hard (some of the
above requirements can be relaxed - if it isn't possible to obtain
valueFromAttribute or someObject at construction time, we can find
workarounds - but we have to be able to create the SpecialList instance
using values from a factory/Guice/etc...). For what it's worth, we have
this type of behavior working in Betwixt using custom BeanCreator
implementations.
Thanks much,
- Kevin
------------------------------------------------------------------------
------
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
_______________________________________________
Simple-support mailing list
Sim...@li...
https://lists.sourceforge.net/lists/listinfo/simple-support
Visit our website at http://www.ubs.com
This message contains confidential information and is intended only for
the individual named. If you are not the named addressee you should not
disseminate, distribute or copy this e-mail. Please notify the sender
immediately by e-mail if you have received this e-mail by mistake and
delete this e-mail from your system.
E-mails are not encrypted and cannot be guaranteed to be secure or
error-free as information could be intercepted, corrupted, lost,
destroyed, arrive late or incomplete, or contain viruses. The sender
therefore does not accept liability for any errors or omissions in the
contents of this message which arise as a result of e-mail transmission.
If verification is required please request a hard-copy version. This
message is provided for informational purposes and should not be
construed as a solicitation or offer to buy or sell any securities or
related financial instruments.
UBS Limited is a company registered in England & Wales under company
number 2035362, whose registered office is at 1 Finsbury Avenue, London,
EC2M 2PP, United Kingdom.
UBS AG (London Branch) is registered as a branch of a foreign company
under number BR004507, whose registered office is at
1 Finsbury Avenue, London, EC2M 2PP, United Kingdom.
UBS Clearing and Execution Services Limited is a company registered in
England & Wales under company number 03123037, whose registered office
is at 1 Finsbury Avenue, London, EC2M 2PP, United Kingdom.
Visit our website at http://www.ubs.com
This message contains confidential information and is intended only
for the individual named. If you are not the named addressee you
should not disseminate, distribute or copy this e-mail. Please
notify the sender immediately by e-mail if you have received this
e-mail by mistake and delete this e-mail from your system.
E-mails are not encrypted and cannot be guaranteed to be secure or
error-free as information could be intercepted, corrupted, lost,
destroyed, arrive late or incomplete, or contain viruses. The sender
therefore does not accept liability for any errors or omissions in the
contents of this message which arise as a result of e-mail transmission.
If verification is required please request a hard-copy version. This
message is provided for informational purposes and should not be
construed as a solicitation or offer to buy or sell any securities
or related financial instruments.
UBS Limited is a company registered in England & Wales under company
number 2035362, whose registered office is at 1 Finsbury Avenue,
London, EC2M 2PP, United Kingdom.
UBS AG (London Branch) is registered as a branch of a foreign company
under number BR004507, whose registered office is at
1 Finsbury Avenue, London, EC2M 2PP, United Kingdom.
UBS Clearing and Execution Services Limited is a company registered
in England & Wales under company number 03123037, whose registered
office is at 1 Finsbury Avenue, London, EC2M 2PP, United Kingdom.
|
|
From: <Nia...@ub...> - 2009-01-26 09:12:23
|
Hi,
Ill take a look at the read resolve and write replace issues you
mention. The reason @Replace and @Resolve do not work in lists is they
go through the Traverser object, rather than the Composite object
directly. This is something I will have to address. So there are two
options, the first is to use a strategy (there should be plenty of
examples in the test cases), the second is to use @Commit to build the
Tuples like so.
public class TupleDatabase {
private List<Tuple> tuples;
@ElementList
private List<TupleEntry> entries;
@Commit
private void commit() {
for(TupleEntry entry : entries) {
tuples.add(entry.name, entry.value);
}
}
@Root
private static class TupleEntry {
@Element String name;
@Element String value;
}
}
Here when building the list you can create the tuples without a no-arg
constructor.
Hope this helps,
Niall
-----Original Message-----
From: Kevin Day [mailto:for...@tr...]
Sent: 24 January 2009 00:21
To: sim...@li...
Subject: Re: [Simple-support] Using constructors with arguments
Thanks for the suggestion, this type of strategy is exactly what we do
with our current Java serialization based persistence, so it's easy to
relate to (even though there's a lot of duplicate code).
For some reason, though, @Replace isn't working (the getSubstitute()
method is never called).
After a bit of digging into the source, I think that the problem is that
the only place that Caller#replace() is actually called is in
Composite#writeReplace(). And that method is only called for composite
objects. We are dealing with a list of objects, so it seems that maybe
writeReplace() hasn't been properly implemented for ElementList
handlers?
If I place my object outside the list (as part of a composite element),
then it serializes fine.
Another issue I'm running into is during deserialization. In this case,
I am using @Resolve on the replaced object (which is part of a composite
object structure). I set a break point on Composite.readResolve(), but
readResolve never gets called. The framework throws an
InstantiationException from Factory#getOverride().
I'm not sure if the problem here is my lack of understanding of the API,
or if this is just a corner case that didn't get unit testing written
for it. I am attaching a self contained unit test case that exhibits
all of the above behavior. Please let me know if you have any
pointers/suggestions, or if I may just be missing something!
Cheers,
- Kevin
PS - I suspect that the use of @Replace and @Resolve may not solve our
entire use case, but it is a great start at a solution and is helping me
understand the Simple framework better. Our ultimate need also includes
injection of resources via a DI framework, and I'm having a hard time
figuring out how that's going to happen without using some sort of
factory instantiation strategy (I suppose that we could use a singleton
to get the DI hook, but that's an anti-design pattern that I really
would prefer to avoid at all costs). Hopefully we can discuss this
aspect a bit more after I understand why my @Replace and @Resolve aren't
working!
----------------------- Original Message -----------------------
From: <Nia...@ub...>
To: <for...@tr...>, <sim...@li...>
Cc:
Date: Thu, 22 Jan 2009 16:45:15 -0000
Subject: RE: [Simple-support] Using constructors with arguments
Hi,
There is no need to do this. You can do the following.
@Root
public class Tuple {
final private String from;
final private String to;
public Tuple(String from, String to){
this.from = from;
this.to = to;
}
@Replace
private TupleSubstitute getSubstitute() {
return new TupleSubstitute(from, to);
}
public String getFrom() {
return from;
}
public String getTo() {
return to;
}
public String toString() {
return from + " -> " + to;
}
}
@Root
private class TupleSubstitute {
@Element
private String from;
@Element
private String to;
public TupleSubstitute() {
super();
}
public TupleSubstitute(String from, String to) {
this.from = from;
this.to = to;
}
@Resolve
public Tuple getTuple() {
return new Tuple();
}
}
This should work, for you. The @Resolve annotation resolves the
deserialized object before assigning it to the field or method. The
@Replace object replaces the object in the stream. Just like java object
serialization. Let me know how this works out for you.
Hope this helps,
Niall
-----Original Message-----
From: Kevin Day [mailto:for...@tr...]
Sent: 21 January 2009 22:56
To: Simple (Java Project)
Subject: Re: [Simple-support] Using constructors with arguments
I've done some additional work on handling classes that do not have
zero-arg constructors. First, I've put together some simple sample code
(attached, start with TryIt#main) that shows one of the situations we
are facing: we have a number of immutable Tuple objects that we need to
serialize/deserialze. The values used in the Tuple class' constructor
come from attributes (or elements) from the XML. The attached
serializes fine, but we can't deserialize it b/c of the lack of
no-argument constructor. We can't add a no-arg constructor because the
class is intended to be immutable (in fact, the fields are marked as
final). In addition, the sample code shows the Tuple values as holding
simple strings - but in our application, the values are going to be
complex objects.
I have put together a Strategy and Type implementation that *kind* of
works, but I'm running into some issues (may be related to my lack of
familiarity with the code base).
The approach that I'm working on now creates a new Strategy that allows
us to register special Type objects that can handle object instantiation
based on state of the deserialization process (for now, I'm calling this
FactoryGeneratedStrategy). Ideally, FactoryGeneratedStrategy would be
able to inter-operate with any other Strategy (DefaultStrategy,
CycleStrategy, TreeStrategy) - after all, it's only purpose is to help
instantiate objects during deserialization - the behavior of the other
strategies is still desirable.
I ran into a couple of problems with this type of Strategy chaining
approach:
1. DefaultStrategy is not instantiable due to package scope visibility
(this is the smaller issue) 2. The other strategies appear to be
implemented in a way that assumes use of zero-arg constructors. For
example, CycleStrategy#getElement returns an Allocate object depending
on the deserialization state. The Allocate object is ultimately backed
by an Instance object as it's delegate Type. Instance assumes a
zero-arg constructor.
Short of re-implementing all of the *Strategy classes, I can't see how
to go about providing a factory to create new object instances (without
losing functionality provided by various Strategy classes).
My initial impression based on the above is that Strategy may not be the
appropriate place in the hierarchy to add object instantiation behavior.
If not, where? The Instantiator class seems a likely candidate, except
that it's getInstace() method doesn't have access to deserialization
context information.
Maybe I'm just going about this all wrong... If anyone can provide some
suggestions, I'd love to hear them!
Thanks,
- K
----------------------- Original Message -----------------------
From: Kevin Day <ke...@tr...>
To: Simple (Java Project) <sim...@li...>
Cc:
Date: Tue, 20 Jan 2009 17:28:05 -0700
Subject: [Simple-support] Using constructors with arguments
For starters, I really like what I see in this project (just started
reviewing it this afternoon). I'm hoping that I can get some pointers
on a specific use-case.
I would like to use Simple in conjunction with a dependency injection
system (probably Guice) and List implementations from the GlazedLists
project.
We have to use a constructor on our list implementations that contains
arguments (some of the arguments provided by Guice, some from element or
attribute data in the XML).
What is the best way to approach this with Simple?
It seems that some sort of Strategy mixed with a custom Type is in
order, but I'm not entirely clear on the best approach. The
architecture of the framework looks powerful enough to do what we need,
but I can't see where to get started just yet.
To give a pseudo-code example of what we are trying to do (in real life,
we'll be injecting SomeInjectedObject using Guice or a factory/service
provider call):
class SpecialList<E>{
public SpecialList(SomeInjectedObject injected, String
valueFromAttribute, SomeObject valueFromElement){ ...
}
}
class MyObject{
@ElementList
SpecialList<ElementObject> list = new
SpecialList<ElementObject>(SomeInjectedObject.defaultInstance, "test",
new SomeObject());
}
When we serialize this with Simple, we'd like to see something
approximately like the following:
<myObject valueFromAttribute="test">
<someObject> ... </someObject>
<list>
<elementObject> ... whatever goes into this ... </elementObject>
<elementObject> ... whatever goes into this ... </elementObject> ...
</list>
</myObject>
Note that:
1. The <list> element doesn't have a class attribute 2. When we
construct the list during deserialization, we need to be able to pull
the 'valueFromAttribute' and 'someObject' values to use during
construction of the SpecialList object 3. The SpecialList object needs
to have the 3 argument constructor called (not a zero-arg constructor).
And it is not possible to call a zero arg constructor, then modify the
object afterwards to get the same result.
Any pointers? I may be pushing the framework too hard (some of the
above requirements can be relaxed - if it isn't possible to obtain
valueFromAttribute or someObject at construction time, we can find
workarounds - but we have to be able to create the SpecialList instance
using values from a factory/Guice/etc...). For what it's worth, we have
this type of behavior working in Betwixt using custom BeanCreator
implementations.
Thanks much,
- Kevin
------------------------------------------------------------------------
------
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
_______________________________________________
Simple-support mailing list
Sim...@li...
https://lists.sourceforge.net/lists/listinfo/simple-support
Visit our website at http://www.ubs.com
This message contains confidential information and is intended only for
the individual named. If you are not the named addressee you should not
disseminate, distribute or copy this e-mail. Please notify the sender
immediately by e-mail if you have received this e-mail by mistake and
delete this e-mail from your system.
E-mails are not encrypted and cannot be guaranteed to be secure or
error-free as information could be intercepted, corrupted, lost,
destroyed, arrive late or incomplete, or contain viruses. The sender
therefore does not accept liability for any errors or omissions in the
contents of this message which arise as a result of e-mail transmission.
If verification is required please request a hard-copy version. This
message is provided for informational purposes and should not be
construed as a solicitation or offer to buy or sell any securities or
related financial instruments.
UBS Limited is a company registered in England & Wales under company
number 2035362, whose registered office is at 1 Finsbury Avenue, London,
EC2M 2PP, United Kingdom.
UBS AG (London Branch) is registered as a branch of a foreign company
under number BR004507, whose registered office is at
1 Finsbury Avenue, London, EC2M 2PP, United Kingdom.
UBS Clearing and Execution Services Limited is a company registered in
England & Wales under company number 03123037, whose registered office
is at 1 Finsbury Avenue, London, EC2M 2PP, United Kingdom.
Visit our website at http://www.ubs.com
This message contains confidential information and is intended only
for the individual named. If you are not the named addressee you
should not disseminate, distribute or copy this e-mail. Please
notify the sender immediately by e-mail if you have received this
e-mail by mistake and delete this e-mail from your system.
E-mails are not encrypted and cannot be guaranteed to be secure or
error-free as information could be intercepted, corrupted, lost,
destroyed, arrive late or incomplete, or contain viruses. The sender
therefore does not accept liability for any errors or omissions in the
contents of this message which arise as a result of e-mail transmission.
If verification is required please request a hard-copy version. This
message is provided for informational purposes and should not be
construed as a solicitation or offer to buy or sell any securities
or related financial instruments.
UBS Limited is a company registered in England & Wales under company
number 2035362, whose registered office is at 1 Finsbury Avenue,
London, EC2M 2PP, United Kingdom.
UBS AG (London Branch) is registered as a branch of a foreign company
under number BR004507, whose registered office is at
1 Finsbury Avenue, London, EC2M 2PP, United Kingdom.
UBS Clearing and Execution Services Limited is a company registered
in England & Wales under company number 03123037, whose registered
office is at 1 Finsbury Avenue, London, EC2M 2PP, United Kingdom.
|
|
From: Kevin D. <for...@tr...> - 2009-01-24 00:21:42
|
Thanks for the suggestion, this type of strategy is exactly what we do with our current Java serialization based persistence, so it's easy to relate to (even though there's a lot of duplicate code).
For some reason, though, @Replace isn't working (the getSubstitute() method is never called).
After a bit of digging into the source, I think that the problem is that the only place that Caller#replace() is actually called is in Composite#writeReplace(). And that method is only called for composite objects. We are dealing with a list of objects, so it seems that maybe writeReplace() hasn't been properly implemented for ElementList handlers?
If I place my object outside the list (as part of a composite element), then it serializes fine.
Another issue I'm running into is during deserialization. In this case, I am using @Resolve on the replaced object (which is part of a composite object structure). I set a break point on Composite.readResolve(), but readResolve never gets called. The framework throws an InstantiationException from Factory#getOverride().
I'm not sure if the problem here is my lack of understanding of the API, or if this is just a corner case that didn't get unit testing written for it. I am attaching a self contained unit test case that exhibits all of the above behavior. Please let me know if you have any pointers/suggestions, or if I may just be missing something!
Cheers,
- Kevin
PS - I suspect that the use of @Replace and @Resolve may not solve our entire use case, but it is a great start at a solution and is helping me understand the Simple framework better. Our ultimate need also includes injection of resources via a DI framework, and I'm having a hard time figuring out how that's going to happen without using some sort of factory instantiation strategy (I suppose that we could use a singleton to get the DI hook, but that's an anti-design pattern that I really would prefer to avoid at all costs). Hopefully we can discuss this aspect a bit more after I understand why my @Replace and @Resolve aren't working!
----------------------- Original Message -----------------------
From: <Nia...@ub...>
To: <for...@tr...>, <sim...@li...>
Cc:
Date: Thu, 22 Jan 2009 16:45:15 -0000
Subject: RE: [Simple-support] Using constructors with arguments
Hi,
There is no need to do this. You can do the following.
@Root
public class Tuple {
final private String from;
final private String to;
public Tuple(String from, String to){
this.from = from;
this.to = to;
}
@Replace
private TupleSubstitute getSubstitute() {
return new TupleSubstitute(from, to);
}
public String getFrom() {
return from;
}
public String getTo() {
return to;
}
public String toString() {
return from + " -> " + to;
}
}
@Root
private class TupleSubstitute {
@Element
private String from;
@Element
private String to;
public TupleSubstitute() {
super();
}
public TupleSubstitute(String from, String to) {
this.from = from;
this.to = to;
}
@Resolve
public Tuple getTuple() {
return new Tuple();
}
}
This should work, for you. The @Resolve annotation resolves the
deserialized object before assigning it to the field or method. The
@Replace object replaces the object in the stream. Just like java object
serialization. Let me know how this works out for you.
Hope this helps,
Niall
-----Original Message-----
From: Kevin Day [mailto:for...@tr...]
Sent: 21 January 2009 22:56
To: Simple (Java Project)
Subject: Re: [Simple-support] Using constructors with arguments
I've done some additional work on handling classes that do not have
zero-arg constructors. First, I've put together some simple sample code
(attached, start with TryIt#main) that shows one of the situations we
are facing: we have a number of immutable Tuple objects that we need to
serialize/deserialze. The values used in the Tuple class' constructor
come from attributes (or elements) from the XML. The attached
serializes fine, but we can't deserialize it b/c of the lack of
no-argument constructor. We can't add a no-arg constructor because the
class is intended to be immutable (in fact, the fields are marked as
final). In addition, the sample code shows the Tuple values as holding
simple strings - but in our application, the values are going to be
complex objects.
I have put together a Strategy and Type implementation that *kind* of
works, but I'm running into some issues (may be related to my lack of
familiarity with the code base).
The approach that I'm working on now creates a new Strategy that allows
us to register special Type objects that can handle object instantiation
based on state of the deserialization process (for now, I'm calling this
FactoryGeneratedStrategy). Ideally, FactoryGeneratedStrategy would be
able to inter-operate with any other Strategy (DefaultStrategy,
CycleStrategy, TreeStrategy) - after all, it's only purpose is to help
instantiate objects during deserialization - the behavior of the other
strategies is still desirable.
I ran into a couple of problems with this type of Strategy chaining
approach:
1. DefaultStrategy is not instantiable due to package scope visibility
(this is the smaller issue) 2. The other strategies appear to be
implemented in a way that assumes use of zero-arg constructors. For
example, CycleStrategy#getElement returns an Allocate object depending
on the deserialization state. The Allocate object is ultimately backed
by an Instance object as it's delegate Type. Instance assumes a
zero-arg constructor.
Short of re-implementing all of the *Strategy classes, I can't see how
to go about providing a factory to create new object instances (without
losing functionality provided by various Strategy classes).
My initial impression based on the above is that Strategy may not be the
appropriate place in the hierarchy to add object instantiation behavior.
If not, where? The Instantiator class seems a likely candidate, except
that it's getInstace() method doesn't have access to deserialization
context information.
Maybe I'm just going about this all wrong... If anyone can provide some
suggestions, I'd love to hear them!
Thanks,
- K
----------------------- Original Message -----------------------
From: Kevin Day <ke...@tr...>
To: Simple (Java Project) <sim...@li...>
Cc:
Date: Tue, 20 Jan 2009 17:28:05 -0700
Subject: [Simple-support] Using constructors with arguments
For starters, I really like what I see in this project (just started
reviewing it this afternoon). I'm hoping that I can get some pointers
on a specific use-case.
I would like to use Simple in conjunction with a dependency injection
system (probably Guice) and List implementations from the GlazedLists
project.
We have to use a constructor on our list implementations that contains
arguments (some of the arguments provided by Guice, some from element or
attribute data in the XML).
What is the best way to approach this with Simple?
It seems that some sort of Strategy mixed with a custom Type is in
order, but I'm not entirely clear on the best approach. The
architecture of the framework looks powerful enough to do what we need,
but I can't see where to get started just yet.
To give a pseudo-code example of what we are trying to do (in real life,
we'll be injecting SomeInjectedObject using Guice or a factory/service
provider call):
class SpecialList<E>{
public SpecialList(SomeInjectedObject injected, String
valueFromAttribute, SomeObject valueFromElement){ ...
}
}
class MyObject{
@ElementList
SpecialList<ElementObject> list = new
SpecialList<ElementObject>(SomeInjectedObject.defaultInstance, "test",
new SomeObject());
}
When we serialize this with Simple, we'd like to see something
approximately like the following:
<myObject valueFromAttribute="test">
<someObject> ... </someObject>
<list>
<elementObject> ... whatever goes into this ... </elementObject>
<elementObject> ... whatever goes into this ... </elementObject>
...
</list>
</myObject>
Note that:
1. The <list> element doesn't have a class attribute 2. When we
construct the list during deserialization, we need to be able to pull
the 'valueFromAttribute' and 'someObject' values to use during
construction of the SpecialList object 3. The SpecialList object needs
to have the 3 argument constructor called (not a zero-arg constructor).
And it is not possible to call a zero arg constructor, then modify the
object afterwards to get the same result.
Any pointers? I may be pushing the framework too hard (some of the
above requirements can be relaxed - if it isn't possible to obtain
valueFromAttribute or someObject at construction time, we can find
workarounds - but we have to be able to create the SpecialList instance
using values from a factory/Guice/etc...). For what it's worth, we have
this type of behavior working in Betwixt using custom BeanCreator
implementations.
Thanks much,
- Kevin
------------------------------------------------------------------------
------
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
_______________________________________________
Simple-support mailing list
Sim...@li...
https://lists.sourceforge.net/lists/listinfo/simple-support
Visit our website at http://www.ubs.com
This message contains confidential information and is intended only
for the individual named. If you are not the named addressee you
should not disseminate, distribute or copy this e-mail. Please
notify the sender immediately by e-mail if you have received this
e-mail by mistake and delete this e-mail from your system.
E-mails are not encrypted and cannot be guaranteed to be secure or
error-free as information could be intercepted, corrupted, lost,
destroyed, arrive late or incomplete, or contain viruses. The sender
therefore does not accept liability for any errors or omissions in the
contents of this message which arise as a result of e-mail transmission.
If verification is required please request a hard-copy version. This
message is provided for informational purposes and should not be
construed as a solicitation or offer to buy or sell any securities
or related financial instruments.
UBS Limited is a company registered in England & Wales under company
number 2035362, whose registered office is at 1 Finsbury Avenue,
London, EC2M 2PP, United Kingdom.
UBS AG (London Branch) is registered as a branch of a foreign company
under number BR004507, whose registered office is at
1 Finsbury Avenue, London, EC2M 2PP, United Kingdom.
UBS Clearing and Execution Services Limited is a company registered
in England & Wales under company number 03123037, whose registered
office is at 1 Finsbury Avenue, London, EC2M 2PP, United Kingdom. |
|
From: <Nia...@ub...> - 2009-01-23 07:17:06
|
Visit our website at http://www.ubs.com This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mails are not encrypted and cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message which arise as a result of e-mail transmission. If verification is required please request a hard-copy version. This message is provided for informational purposes and should not be construed as a solicitation or offer to buy or sell any securities or related financial instruments. UBS Limited is a company registered in England & Wales under company number 2035362, whose registered office is at 1 Finsbury Avenue, London, EC2M 2PP, United Kingdom. UBS AG (London Branch) is registered as a branch of a foreign company under number BR004507, whose registered office is at 1 Finsbury Avenue, London, EC2M 2PP, United Kingdom. UBS Clearing and Execution Services Limited is a company registered in England & Wales under company number 03123037, whose registered office is at 1 Finsbury Avenue, London, EC2M 2PP, United Kingdom. |
|
From: Simi, N. <NS...@pe...> - 2009-01-23 02:56:53
|
Hello All, I want to have an Element that is a Hashtable/map of key = String, value = list of string. Is this possible? Thank you, Nick Simi Software Engineer PELCO USA 1-559-292-1981 x6474 3500 Pelco Way Clovis Ca, 93611 USA ns...@pe... - ------------------------------------------------------------------------------ Confidentiality Notice: The information contained in this transmission is legally privileged and confidential, intended only for the use of the individual(s) or entities named above. This email and any files transmitted with it are the property of Pelco. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any review, disclosure, copying, distribution, retention, or any action taken or omitted to be taken in reliance on it is prohibited and may be unlawful. If you receive this communication in error, please notify us immediately by telephone call to +1-559-292-1981 or forward the e-mail to adm...@pe... and then permanently delete the e-mail and destroy all soft and hard copies of the message and any attachments. Thank you for your cooperation. - ------------------------------------------------------------------------------ |
|
From: <Nia...@ub...> - 2009-01-22 16:45:46
|
Hi,
There is no need to do this. You can do the following.
@Root
public class Tuple {
final private String from;
final private String to;
public Tuple(String from, String to){
this.from = from;
this.to = to;
}
@Replace
private TupleSubstitute getSubstitute() {
return new TupleSubstitute(from, to);
}
public String getFrom() {
return from;
}
public String getTo() {
return to;
}
public String toString() {
return from + " -> " + to;
}
}
@Root
private class TupleSubstitute {
@Element
private String from;
@Element
private String to;
public TupleSubstitute() {
super();
}
public TupleSubstitute(String from, String to) {
this.from = from;
this.to = to;
}
@Resolve
public Tuple getTuple() {
return new Tuple();
}
}
This should work, for you. The @Resolve annotation resolves the
deserialized object before assigning it to the field or method. The
@Replace object replaces the object in the stream. Just like java object
serialization. Let me know how this works out for you.
Hope this helps,
Niall
-----Original Message-----
From: Kevin Day [mailto:for...@tr...]
Sent: 21 January 2009 22:56
To: Simple (Java Project)
Subject: Re: [Simple-support] Using constructors with arguments
I've done some additional work on handling classes that do not have
zero-arg constructors. First, I've put together some simple sample code
(attached, start with TryIt#main) that shows one of the situations we
are facing: we have a number of immutable Tuple objects that we need to
serialize/deserialze. The values used in the Tuple class' constructor
come from attributes (or elements) from the XML. The attached
serializes fine, but we can't deserialize it b/c of the lack of
no-argument constructor. We can't add a no-arg constructor because the
class is intended to be immutable (in fact, the fields are marked as
final). In addition, the sample code shows the Tuple values as holding
simple strings - but in our application, the values are going to be
complex objects.
I have put together a Strategy and Type implementation that *kind* of
works, but I'm running into some issues (may be related to my lack of
familiarity with the code base).
The approach that I'm working on now creates a new Strategy that allows
us to register special Type objects that can handle object instantiation
based on state of the deserialization process (for now, I'm calling this
FactoryGeneratedStrategy). Ideally, FactoryGeneratedStrategy would be
able to inter-operate with any other Strategy (DefaultStrategy,
CycleStrategy, TreeStrategy) - after all, it's only purpose is to help
instantiate objects during deserialization - the behavior of the other
strategies is still desirable.
I ran into a couple of problems with this type of Strategy chaining
approach:
1. DefaultStrategy is not instantiable due to package scope visibility
(this is the smaller issue) 2. The other strategies appear to be
implemented in a way that assumes use of zero-arg constructors. For
example, CycleStrategy#getElement returns an Allocate object depending
on the deserialization state. The Allocate object is ultimately backed
by an Instance object as it's delegate Type. Instance assumes a
zero-arg constructor.
Short of re-implementing all of the *Strategy classes, I can't see how
to go about providing a factory to create new object instances (without
losing functionality provided by various Strategy classes).
My initial impression based on the above is that Strategy may not be the
appropriate place in the hierarchy to add object instantiation behavior.
If not, where? The Instantiator class seems a likely candidate, except
that it's getInstace() method doesn't have access to deserialization
context information.
Maybe I'm just going about this all wrong... If anyone can provide some
suggestions, I'd love to hear them!
Thanks,
- K
----------------------- Original Message -----------------------
From: Kevin Day <ke...@tr...>
To: Simple (Java Project) <sim...@li...>
Cc:
Date: Tue, 20 Jan 2009 17:28:05 -0700
Subject: [Simple-support] Using constructors with arguments
For starters, I really like what I see in this project (just started
reviewing it this afternoon). I'm hoping that I can get some pointers
on a specific use-case.
I would like to use Simple in conjunction with a dependency injection
system (probably Guice) and List implementations from the GlazedLists
project.
We have to use a constructor on our list implementations that contains
arguments (some of the arguments provided by Guice, some from element or
attribute data in the XML).
What is the best way to approach this with Simple?
It seems that some sort of Strategy mixed with a custom Type is in
order, but I'm not entirely clear on the best approach. The
architecture of the framework looks powerful enough to do what we need,
but I can't see where to get started just yet.
To give a pseudo-code example of what we are trying to do (in real life,
we'll be injecting SomeInjectedObject using Guice or a factory/service
provider call):
class SpecialList<E>{
public SpecialList(SomeInjectedObject injected, String
valueFromAttribute, SomeObject valueFromElement){ ...
}
}
class MyObject{
@ElementList
SpecialList<ElementObject> list = new
SpecialList<ElementObject>(SomeInjectedObject.defaultInstance, "test",
new SomeObject());
}
When we serialize this with Simple, we'd like to see something
approximately like the following:
<myObject valueFromAttribute="test">
<someObject> ... </someObject>
<list>
<elementObject> ... whatever goes into this ... </elementObject>
<elementObject> ... whatever goes into this ... </elementObject>
...
</list>
</myObject>
Note that:
1. The <list> element doesn't have a class attribute 2. When we
construct the list during deserialization, we need to be able to pull
the 'valueFromAttribute' and 'someObject' values to use during
construction of the SpecialList object 3. The SpecialList object needs
to have the 3 argument constructor called (not a zero-arg constructor).
And it is not possible to call a zero arg constructor, then modify the
object afterwards to get the same result.
Any pointers? I may be pushing the framework too hard (some of the
above requirements can be relaxed - if it isn't possible to obtain
valueFromAttribute or someObject at construction time, we can find
workarounds - but we have to be able to create the SpecialList instance
using values from a factory/Guice/etc...). For what it's worth, we have
this type of behavior working in Betwixt using custom BeanCreator
implementations.
Thanks much,
- Kevin
------------------------------------------------------------------------
------
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
_______________________________________________
Simple-support mailing list
Sim...@li...
https://lists.sourceforge.net/lists/listinfo/simple-support
Visit our website at http://www.ubs.com
This message contains confidential information and is intended only
for the individual named. If you are not the named addressee you
should not disseminate, distribute or copy this e-mail. Please
notify the sender immediately by e-mail if you have received this
e-mail by mistake and delete this e-mail from your system.
E-mails are not encrypted and cannot be guaranteed to be secure or
error-free as information could be intercepted, corrupted, lost,
destroyed, arrive late or incomplete, or contain viruses. The sender
therefore does not accept liability for any errors or omissions in the
contents of this message which arise as a result of e-mail transmission.
If verification is required please request a hard-copy version. This
message is provided for informational purposes and should not be
construed as a solicitation or offer to buy or sell any securities
or related financial instruments.
UBS Limited is a company registered in England & Wales under company
number 2035362, whose registered office is at 1 Finsbury Avenue,
London, EC2M 2PP, United Kingdom.
UBS AG (London Branch) is registered as a branch of a foreign company
under number BR004507, whose registered office is at
1 Finsbury Avenue, London, EC2M 2PP, United Kingdom.
UBS Clearing and Execution Services Limited is a company registered
in England & Wales under company number 03123037, whose registered
office is at 1 Finsbury Avenue, London, EC2M 2PP, United Kingdom.
|
|
From: Kevin D. <for...@tr...> - 2009-01-21 22:56:05
|
I've done some additional work on handling classes that do not have zero-arg constructors. First, I've put together some simple sample code (attached, start with TryIt#main) that shows one of the situations we are facing: we have a number of immutable Tuple objects that we need to serialize/deserialze. The values used in the Tuple class' constructor come from attributes (or elements) from the XML. The attached serializes fine, but we can't deserialize it b/c of the lack of no-argument constructor. We can't add a no-arg constructor because the class is intended to be immutable (in fact, the fields are marked as final). In addition, the sample code shows the Tuple values as holding simple strings - but in our application, the values are going to be complex objects.
I have put together a Strategy and Type implementation that *kind* of works, but I'm running into some issues (may be related to my lack of familiarity with the code base).
The approach that I'm working on now creates a new Strategy that allows us to register special Type objects that can handle object instantiation based on state of the deserialization process (for now, I'm calling this FactoryGeneratedStrategy). Ideally, FactoryGeneratedStrategy would be able to inter-operate with any other Strategy (DefaultStrategy, CycleStrategy, TreeStrategy) - after all, it's only purpose is to help instantiate objects during deserialization - the behavior of the other strategies is still desirable.
I ran into a couple of problems with this type of Strategy chaining approach:
1. DefaultStrategy is not instantiable due to package scope visibility (this is the smaller issue)
2. The other strategies appear to be implemented in a way that assumes use of zero-arg constructors. For example, CycleStrategy#getElement returns an Allocate object depending on the deserialization state. The Allocate object is ultimately backed by an Instance object as it's delegate Type. Instance assumes a zero-arg constructor.
Short of re-implementing all of the *Strategy classes, I can't see how to go about providing a factory to create new object instances (without losing functionality provided by various Strategy classes).
My initial impression based on the above is that Strategy may not be the appropriate place in the hierarchy to add object instantiation behavior. If not, where? The Instantiator class seems a likely candidate, except that it's getInstace() method doesn't have access to deserialization context information.
Maybe I'm just going about this all wrong... If anyone can provide some suggestions, I'd love to hear them!
Thanks,
- K
----------------------- Original Message -----------------------
From: Kevin Day <ke...@tr...>
To: Simple (Java Project) <sim...@li...>
Cc:
Date: Tue, 20 Jan 2009 17:28:05 -0700
Subject: [Simple-support] Using constructors with arguments
For starters, I really like what I see in this project (just started reviewing it this afternoon). I'm hoping that I can get some pointers on a specific use-case.
I would like to use Simple in conjunction with a dependency injection system (probably Guice) and List implementations from the GlazedLists project.
We have to use a constructor on our list implementations that contains arguments (some of the arguments provided by Guice, some from element or attribute data in the XML).
What is the best way to approach this with Simple?
It seems that some sort of Strategy mixed with a custom Type is in order, but I'm not entirely clear on the best approach. The architecture of the framework looks powerful enough to do what we need, but I can't see where to get started just yet.
To give a pseudo-code example of what we are trying to do (in real life, we'll be injecting SomeInjectedObject using Guice or a factory/service provider call):
class SpecialList<E>{
public SpecialList(SomeInjectedObject injected, String valueFromAttribute, SomeObject valueFromElement){
...
}
}
class MyObject{
@ElementList
SpecialList<ElementObject> list = new SpecialList<ElementObject>(SomeInjectedObject.defaultInstance, "test", new SomeObject());
}
When we serialize this with Simple, we'd like to see something approximately like the following:
<myObject valueFromAttribute="test">
<someObject> ... </someObject>
<list>
<elementObject> ... whatever goes into this ... </elementObject>
<elementObject> ... whatever goes into this ... </elementObject>
...
</list>
</myObject>
Note that:
1. The <list> element doesn't have a class attribute
2. When we construct the list during deserialization, we need to be able to pull the 'valueFromAttribute' and 'someObject' values to use during construction of the SpecialList object
3. The SpecialList object needs to have the 3 argument constructor called (not a zero-arg constructor). And it is not possible to call a zero arg constructor, then modify the object afterwards to get the same result.
Any pointers? I may be pushing the framework too hard (some of the above requirements can be relaxed - if it isn't possible to obtain valueFromAttribute or someObject at construction time, we can find workarounds - but we have to be able to create the SpecialList instance using values from a factory/Guice/etc...). For what it's worth, we have this type of behavior working in Betwixt using custom BeanCreator implementations.
Thanks much,
- Kevin
------------------------------------------------------------------------------
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
_______________________________________________
Simple-support mailing list
Sim...@li...
https://lists.sourceforge.net/lists/listinfo/simple-support |
|
From: Kevin D. <ke...@tr...> - 2009-01-21 00:28:16
|
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<STYLE type=text/css> P, UL, OL, DL, DIR, MENU, PRE { margin: 0 auto;}</STYLE>
<META content="MSHTML 6.00.6000.16788" name=GENERATOR></HEAD>
<BODY leftMargin=1 topMargin=1 rightMargin=1><FONT face=Arial size=2>
<DIV>For starters, I really like what I see in this project (just started reviewing it this afternoon). I'm hoping that I can get some pointers on a specific use-case.</DIV>
<DIV> </DIV>
<DIV> </DIV>
<DIV>I would like to use Simple in conjunction with a dependency injection system (probably Guice) and List implementations from the GlazedLists project.</DIV>
<DIV> </DIV>
<DIV>We have to use a constructor on our list implementations that contains arguments (some of the arguments provided by Guice, some from element or attribute data in the XML).</DIV>
<DIV> </DIV>
<DIV>What is the best way to approach this with Simple?</DIV>
<DIV> </DIV>
<DIV></DIV>
<DIV>It seems that some sort of Strategy mixed with a custom Type is in order, but I'm not entirely clear on the best approach. The architecture of the framework looks powerful enough to do what we need, but I can't see where to get started just yet.</DIV>
<DIV> </DIV>
<DIV> </DIV>
<DIV>To give a pseudo-code example of what we are trying to do (in real life, we'll be injecting SomeInjectedObject using Guice or a factory/service provider call):</DIV>
<DIV> </DIV>
<DIV>class SpecialList<E>{</DIV>
<DIV> public SpecialList(SomeInjectedObject injected, String valueFromAttribute, SomeObject valueFromElement){</DIV>
<DIV> ...</DIV>
<DIV> }</DIV>
<DIV>}</DIV>
<DIV> </DIV>
<DIV> </DIV>
<DIV>class MyObject{</DIV>
<DIV><FONT color=#646464 size=2><FONT color=#646464 size=2>
<P> @ElementList</P></FONT></FONT></DIV>
<DIV> SpecialList<ElementObject> list = new SpecialList<ElementObject>(SomeInjectedObject.defaultInstance, "test", new SomeObject());</DIV>
<DIV> </DIV>
<DIV>}</DIV>
<DIV> </DIV>
<DIV> </DIV>
<DIV>When we serialize this with Simple, we'd like to see something approximately like the following:</DIV>
<DIV> </DIV>
<DIV><myObject valueFromAttribute="test"></DIV>
<DIV>
<DIV> <someObject> ... </someObject></DIV> <list></DIV>
<DIV> <elementObject> ... whatever goes into this ... </elementObject></DIV>
<DIV>
<DIV> <elementObject> ... whatever goes into this ... </elementObject></DIV>
<DIV> ...</DIV> </list></DIV>
<DIV></myObject></DIV>
<DIV> </DIV>
<DIV> </DIV>
<DIV>Note that:</DIV>
<DIV> </DIV>
<DIV>1. The <list> element doesn't have a class attribute</DIV>
<DIV>2. When we construct the list during deserialization, we need to be able to pull the 'valueFromAttribute' and 'someObject' values to use during construction of the SpecialList object</DIV>
<DIV>3. The SpecialList object needs to have the 3 argument constructor called (not a zero-arg constructor). And it is not possible to call a zero arg constructor, then modify the object afterwards to get the same result.</DIV>
<DIV> </DIV>
<DIV> </DIV>
<DIV>Any pointers? I may be pushing the framework too hard (some of the above requirements can be relaxed - if it isn't possible to obtain valueFromAttribute or someObject at construction time, we can find workarounds - but we have to be able to create the SpecialList instance using values from a factory/Guice/etc...). For what it's worth, we have this type of behavior working in Betwixt using custom BeanCreator implementations.</DIV>
<DIV> </DIV>
<DIV>Thanks much,</DIV>
<DIV> </DIV>
<DIV>- Kevin</DIV></FONT></BODY></HTML>
|
|
From: <Nia...@ub...> - 2009-01-19 12:58:35
|
Hi,
I was just about to write how you could wrap all the transforms or even a transformer such that it could intercept the strings before conversion and decode them. But the persister only has access to the Matcher :(. Anyway that is something I can fix later. You can use the org.simpleframework.xml.graph.TreeStrategy, it's the very same as the DefaultStrategy only its public (in 2.0.2). There you can match the class and decode it when deserializing. There are plenty of unit tests and some info in the tutorial that will show you how to do this.
Hope this helps,
Niall
-----Original Message-----
From: Paweł Kierat [mailto:paw...@gm...]
Sent: 19 January 2009 10:58
To: sim...@li...
Subject: [Simple-support] value preprocessing before deserialization
Hi,
I need to (de)serialize a list of java beans to/from XML message. The problem is that all values (i.e. integers, doubles, dates etc.) in each bean are sent as base64-encoded strings, e.g.:
<response>
<person>
<name>[base64-encoded String]</name>
<age>[base64-encoded int]</name>
<birthDate>[base64-encoded date]</birthDate>
...
</person>
</response>
Is there a simple way to decode those beans without holding all their fields as Strings?
I thought of creating a custom transformation, but then I would have to reimplement all the default transforms as they are not exported by the org.simpleframework.xml package (all classes have "package private" scope).
I was also considering a custom strategy, but again - the DefaultStrategy is "package private" too.
Thanks in advance,
Pawel
------------------------------------------------------------------------------
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
_______________________________________________
Simple-support mailing list
Sim...@li...
https://lists.sourceforge.net/lists/listinfo/simple-support
Visit our website at http://www.ubs.com
This message contains confidential information and is intended only
for the individual named. If you are not the named addressee you
should not disseminate, distribute or copy this e-mail. Please
notify the sender immediately by e-mail if you have received this
e-mail by mistake and delete this e-mail from your system.
E-mails are not encrypted and cannot be guaranteed to be secure or
error-free as information could be intercepted, corrupted, lost,
destroyed, arrive late or incomplete, or contain viruses. The sender
therefore does not accept liability for any errors or omissions in the
contents of this message which arise as a result of e-mail transmission.
If verification is required please request a hard-copy version. This
message is provided for informational purposes and should not be
construed as a solicitation or offer to buy or sell any securities
or related financial instruments.
UBS Limited is a company registered in England & Wales under company
number 2035362, whose registered office is at 1 Finsbury Avenue,
London, EC2M 2PP, United Kingdom.
UBS AG (London Branch) is registered as a branch of a foreign company
under number BR004507, whose registered office is at
1 Finsbury Avenue, London, EC2M 2PP, United Kingdom.
UBS Clearing and Execution Services Limited is a company registered
in England & Wales under company number 03123037, whose registered
office is at 1 Finsbury Avenue, London, EC2M 2PP, United Kingdom.
|
|
From: Paweł K. <paw...@gm...> - 2009-01-19 10:57:38
|
Hi,
I need to (de)serialize a list of java beans to/from XML message. The
problem is that all values (i.e. integers, doubles, dates etc.) in
each bean are sent as base64-encoded strings, e.g.:
<response>
<person>
<name>[base64-encoded String]</name>
<age>[base64-encoded int]</name>
<birthDate>[base64-encoded date]</birthDate>
...
</person>
</response>
Is there a simple way to decode those beans without holding all their
fields as Strings?
I thought of creating a custom transformation, but then I would have
to reimplement all the default transforms as they are not exported by
the org.simpleframework.xml package (all classes have "package
private" scope).
I was also considering a custom strategy, but again - the
DefaultStrategy is "package private" too.
Thanks in advance,
Pawel
|
|
From: Paweł K. <paw...@gm...> - 2009-01-19 09:47:10
|
Hi,
I need to (de)serialize a list of java beans to/from XML message. The
problem is that all values (i.e. integers, doubles, dates etc.) in
each bean are sent as base64-encoded strings, e.g.:
<response>
<person>
<name>[base64-encoded String]</name>
<age>[base64-encoded int]</name>
<birthDate>[base64-encoded date]</birthDate>
...
</person>
</response>
Is there a simple way to decode those beans without holding all their
fields as Strings?
I thought of creating a custom transformation, but then I would have
to reimplement all the default transforms as they are not exported by
the org.simpleframework.xml package (all classes have "package
private" scope).
I was also considering a custom strategy, but again - the
DefaultStrategy is "package private" too.
Thanks in advance,
Pawel
|
|
From: Niall G. <gal...@ya...> - 2009-01-18 11:29:10
|
Hi, With an indent of 0 there is no formatting at all. The XML is just output on to a single line. There are no new lines added with the indent of zero. For example, your XML will look like this. <root><child><grandchild>text</grandchild></child></root> The indent of 0 is a special format, for no new lines or spaces at all. Give it a try, everything will be on a single line. Niall --- On Sat, 1/17/09, Lardy <na...@he...> wrote: > From: Lardy <na...@he...> > Subject: [Simple-support] How to disable pretty formatting? > To: sim...@li... > Date: Saturday, January 17, 2009, 4:25 PM > I don't need readable XML - in fact it is a hindrance > since I am sending > large amounts of it over a network and all those spaces and > new lines just > add to the bulk - and so I need to stop simpleXML inserting > spaces and new > lines. I can't find anything on Style, Format, etc. > that allows this. How > would I go about it? I see I can set the indent to 0 but I > need to stop the > new lines being output too as I write each XML on a single > line for easy > reading at the other end. > > Nice library BTW - up and running in a few minutes. > > Thanks > -- > View this message in context: > http://www.nabble.com/How-to-disable-pretty-formatting--tp21522727p21522727.html > Sent from the Simple XML Serialization mailing list archive > at Nabble.com. > > > ------------------------------------------------------------------------------ > This SF.net email is sponsored by: > SourcForge Community > SourceForge wants to tell your story. > http://p.sf.net/sfu/sf-spreadtheword > _______________________________________________ > Simple-support mailing list > Sim...@li... > https://lists.sourceforge.net/lists/listinfo/simple-support |
51 messages has been excluded from this view by a project administrator.
