Re: [Simple-support] Using constructors with arguments
Brought to you by:
niallg
Menu
▾
▴
Re: [Simple-support] Using constructors with arguments
|
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>
|
