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 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>
|
