Mailing-List: contact cxf-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: cxf-dev@incubator.apache.org
Received-SPF: pass (asf.osuosl.org: domain of andrea.smyth@iona.com designates
 62.221.12.33 as permitted sender)
Message-ID: <44D8B80D.9080601@iona.com>
Date: Tue, 08 Aug 2006 17:13:01 +0100
From: Andrea Smyth <andrea.smyth@iona.com>
User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206)
MIME-Version: 1.0
To: cxf-dev@incubator.apache.org
Subject: DeferredObjectManager
References: <200608071812.34014.daniel.kulp@iona.com>
 <53DF4AE5-F7D6-43FD-B686-58346CE0655E@formicary.net>
 <44D89DC8.1010501@apache.org>
In-Reply-To: <44D89DC8.1010501@apache.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

For an introduction to the subject see the copy attached below of the 
conversation Dan D, Dan K. and myself had last Friday on a non-public 
IRC channel:

What about calling the DeferredObjectManager ExtensionManager instead.
Dan D: Do you really want it in a separate module? Maybe 
cxf-rt2-extension, and have cxf-rt2-core and at least one of the Bus 
implementations in the core depend on it?

There is one bit that I don't like about the approach - or maybe I have 
misunderstood: If a particular object (say: BindingFactory) is marked 
for deferred loading, the Deferred ObjectManager would store the object 
class under the namespaceURI for the bindings that this factory can create.
And when the BindingFactory is finally is loaded, in one of its 
@PostConstruct annotated methods it registers these same namespaceURIs 
with the BindingFactoryManager (as that is the instance with which an 
Endpoint interacts when it needs a Binding created - not the Bus), i.e. 
we also store the association of a set of namespaceURIs with a 
BindingFactory in the BindingFactoryManager.
This seems to be duplicated information at best, but there is the risk 
that the set of namespaceURIs is not the same.
Should we inject the list of namespaceURIs into the deferred object to 
avoid namespaceURI mapping conflicts? Or rely on the fact that the 
@PostConstruct methods do the right thing?

Regards,
Andrea.


---

14:39:40 [dkulp]
    dan: I actually want to change the bus to ONLY have "<T> T
    getManager(Class<T>)" and "<T> void setManager(T, Class<T>)" and
    remove the fields (that cause direct dependencies)
14:40:26 [dkulp]
    The fact that "core" depends on management (and not the other way
    around) is kind of bugging me.
14:40:28 [asmyth]
    Yes I'd prefer that too - we end up with too many of them - but it's
    of course the no-go for getters/setters.
14:43:16 [dandiep]
    regarding transparency - so you're worried about different
    containers requiring different interfaces/constructors/etc in the
    celtix codebase? Or you're worried about users changing their
    container? I'm not sure I understand
14:43:47 [dandiep]
    dkulp: that could possibly work, but it seems like you're
    reinventing a container :-)
14:43:51 [asmyth]
    The core-to-management dependcy can be removed if in - provided we
    don't get an event processor and instrumentation manaber passed in
    the properties list, we don't construct them. But how should we make
    these available to instrumented components? Statically?
14:45:04 [dkulp]
    The Bus, at init time, should find all the objects that need to be
    constructed based on META-INF/XXXX files.
14:45:31 [dkulp]
    Thus, if the management jar is on the classpath, the management
    object would be constructed just like it does today.
14:45:34 [dkulp]
    If not, it doesn't.
14:46:06 [dkulp]
    This completely comes down to the dynamic loading story again.
14:46:18 [dandiep]
    I'd like that to be a feature layered on top of the bus though
14:47:18 [asmyth]
    Yes - but there's a difference between constructing a
    BindingManagerImpl based on META-INF/XXX information and populating
    one that is constructed useing hardcoded instructions.
14:47:40 [dkulp]
    Why?
14:47:55 [dkulp]
    Why do we need the hardcoded instructions?
14:48:06 [dandiep]
    because thats the job of the container
14:48:34 [asmyth]
    What should be in the META-INF/XXX files then say for the case of
    binding factories - can you sketch out?
14:50:47 [asmyth]
    We would need the classname of the binding factory manager
    implementation (once) and then snippets for the individual binding
    factories. I don't see the advantage of the former.
14:50:51 [dandiep]
    I would like to have a simple bus, and then we can make whatever bus
    implementation we want on top of that. Say PropertiesLoadingBus
    which will load the META-INF/XXX files.
14:52:20 [dkulp]
    andrea: not if stuff was properly injected
14:52:40 [dkulp]
    The XXXX file would just have a list of Objects to construct. 
14:52:46 [dkulp]
    The objects can be ANYTHING.
14:53:19 [dkulp]
    It constructs the objects, injects things like the Bus into them,
    calls the postContruct, etc...
14:53:27 [dandiep]
    the properties files are just like writing our own container IMO
14:54:11 [asmyth]
    So should there be one XXX file for the binding factories then? 
14:55:17 [dkulp]
    No.
14:55:44 [dkulp]
    Each jar (like soap.jar) would have it's own META-INF/XXXX file that
    contains the information about the object it needs created
14:56:07 [dkulp]
    dan: this could all be done in the configuration system instead of
    directly in the bus
14:56:37 [dandiep]
    hey - is there any chance we could continue this on #celtix-private
    on freenode or something? Jason van Zyl is around and I think could
    help clarify some of the container issues. If nothing else he is
    interested in listening as he will be building using celtixfire in
    plexus
14:57:03 [asmyth]
    Yes, that's what we have currently - the cxf-rt2-bindings-soap jar
    contains the fragments necessary to create a soap binding factory -
    but it does not include information about how to construjct the
    BindingfactoryManager implementation itself.
14:57:28 [dkulp]
    OK. So there is a level missing.
14:57:42 [dkulp]
    Well, not really. 
14:57:53 [dandiep]
    Why not?
14:58:12 [dkulp]
    The current setup differentiates between bindings,
    transports/conduits, etc....
14:59:14 [dkulp]
    There doesn't seem to be any "generic object" loading stuff.
14:59:40 [asmyth]
    yes - that's so we register the class specified in soap/META-INF/XXX
    with the binding manager factory - do we not want to do that?
15:01:08 [asmyth]
    Can we assume distinct keys for transport ids and binding ids .. and
    other stuff?
15:01:30 [dkulp]
    We CAN, but I was hoping for something more generic. Like we inject
    the bus into whatever object is created, and in the postConstruct
    method, it can register if it needs to.
15:03:04 [asmyth]
    That would mean we instantiate the binding and transport factories
    at bus init tiem - I though we wanted to defer that ...
15:05:39 [asmyth]
    So all XXX files should then have a common format that describes
    class name and values for (primitive) fields to inject, right?
15:06:41 [asmyth]
    Such as in case of the binding factories the lkist of namespace
    URI's served by that factory. And the bus gets injected on top of these.
15:10:19 [dkulp]
    Somewhat.
15:12:39 [dkulp]
    http://rafb.net/paste/paste.php
15:13:11 [asmyth]
    I have no permission to access this document
15:13:25 [dkulp]
    http://rafb.net/paste/results/zssoB335.html
15:13:30 [dkulp]
    Sorry,
15:14:28 [dkulp]
    At init, the bus can newInstance(...)/inject/postconstruct all the
    non-deferable objects
15:14:47 [dandiep]
    ok, now you've really just developed your own ioc container
15:15:08 [dkulp]
    Pretty much. Or we can use one.
15:15:21 [asmyth]
    OK - the first snippet fills the gap for me ...
15:15:41 [dandiep]
    but lets not bake ours in. It is perfectly fine as a layer on top
15:16:39 [asmyth]
    The advantage of this approach (cmpared with Spring) is that we can
    support multiple snippetrs of xml in a very lightweight fashion - as
    opposed to constructing an xml bean factory for each one of them.
15:18:40 [asmyth]
    Do you see a need for elements other than <namespace> as childern of
    <object> in the XXX files?
15:19:14 [dandiep]
    sure, and everyone is more than welcome to use that approach. I just
    want it to operate on the bus, not be part of it.
15:19:18 [dkulp]
    Well, I have another idea....
15:19:55 [dkulp]
    Hold on... phone call....
15:27:02 [dandiep]
    alright, I got to run for a bit.. Lets bring this up on the mailing
    list to discuss a bit more
15:36:04 [dkulp]
    OK. I'm back.
15:36:55 [dkulp]
    andrea: I was actually thinking to have a "DeferredObjectManager",
    and the objects would have a <activation> element that, for now,
    would just have "namespace" elements
15:37:12 [dkulp]
    However, we could extend that to have other events if needed.
15:38:51 [asmyth]
    DeferredObjectManager is what came to my mind when I say your xml
    snippets ...
15:39:31 [asmyth]
    Reason I am asking is that if we want this to be fully extensible we
    may simply use Spring files as XXX. But that is a bit heavyweight ...
15:41:46 [dkulp]
    Doesn't matter to me either way. 
15:42:13 [asmyth]
    But come to think of it - if we keep the second snippet in the bus's
    DeferredObjectManager, then how does a binding factory manager know
    about the namespaces 
15:43:04 [asmyth]
    It is constructed and initially empty - so when it gets a request
    for a bindingID then what?
15:43:44 [dkulp]
    It doesn't
15:43:56 [asmyth]
    ?
15:44:16 [dkulp]
    If the bindingFactory doesn't have a binding, it calls
    bus.getManager(deferredObjectMananger).activateViaNS(ns)
15:44:36 [dkulp]
    Then checks it's map again.
15:44:46 [asmyth]
    OK, that assumes then that all namespace uris are unique.
15:45:28 [asmyth]
    Alternatively we could inckude some sort of parent information in
    XXX, so that we know what entries in the deferred list to consider
15:45:31 [dkulp]
    Not necessarily. It WOULD activate all the objects for that namespace.
15:45:47 [asmyth]
    I see.
15:46:12 [asmyth]
    Well its unlikely there are clashes and if instantiating something
    that is not needed is the worst than can happen - fine
15:46:29 [dkulp]
    Although we could extend the "activation" tag to be more flexible.
15:46:55 [dkulp]
    <ns>http:...</ns><type>org.....Binding</type>
15:47:05 [dkulp]
    But then the call to "activate" becomes more complex.
15:47:38 [asmyth]
    Yes, the type would do it - but is not necessary for now.
15:48:17 [dkulp]
    Right, I really want to define a "activation policy" object that is
    sent to "activate(ActivationPolicy)". Right now, it would only have
    a NS, but we can add more later.
15:50:57 [asmyth]
    OK. namespace based activation is all we need for now (hello world).
    BTW I assume that, as is the case now, if an object for a certain
    property key is in the properties list passed to Bus.init, then the
    corresponding information in the xml snippet is ignored, right?
15:52:16 [dkulp]
    Sure
15:52:59 [asmyth]
    So if we are all ok with this now - who is going to implement what?
15:53:31 [asmyth]
    I could do it.
15:55:15 [dkulp]
    Go for it. :-)
15:55:49 [asmyth]
    OK - Won't be in on Monday though (bank holiday in Ireland).
15:58:15 [dandiep]
    I am not a fan of this at all
15:58:38 [dandiep]
    I'm against any of this going into the api/common/core for now
15:59:18 [dandiep]
    we need to discuss this more on the mailing list with the larger
    community
16:01:17 [asmyth]
    The mailing list is set up already, rught? But the community won't
    have code to look at explaining what we are talking about 
16:01:43 [dandiep]
    well we need to fix that!
16:02:12 [asmyth]
    AFAIK we can't drop code yet?
16:02:16 [davidb]
    davidb has quit
16:02:44 [dandiep]
    jira/svn is getting set up
16:02:55 [dandiep]
    it should be up by monday I think, I'm asking jason about it now
16:03:28 [vinoski]
    vinoski has quit
16:05:21 [asmyth]
    In any case, what do you dislike about it ? I remember Dan
    mentioning that this is the way things are done in tuscany - so it's
    not like we're introducing something totally new and strange.
16:16:18 [dandiep]
    I don't think it creates good separation of concerns. I think we
    already have these features in other containers (not just spring -
    pico, plexus). I don't think its very friendly to
    integrators/embedders like myself who are just using a small subset
    of the functionality or wish to wire things together differently.
    And I don't think its very amenable to other configuration models.
16:18:03 [dandiep]
    And I don't see any reason this can't be separated out of the
    runtime into a separate module that does configuration/wiring.
    Whether thats something you write, spring, whatever, is immaterial
16:18:19 [apaibir]
    apaibir has quit
16:20:11 [dkulp]
    FYI: Adi doesn't want the code moved until all the active IONAians
    have commit access.
16:20:37 [dkulp]
    I don't know how long it will take for Jason or whomever to create
    all the accounts.
16:21:01 [dandiep]
    thats not how it works
16:21:09 [dandiep]
    accounts get created once you need them
16:21:16 [dandiep]
    lazy policy
16:21:23 [dandiep]
    at least AFAIK
16:22:16 [dkulp]
    Well, we need the accounts immediately. How's that? :-)
16:22:58 [asmyth]
    But isn't the xml snippet/deferredObjectManager approach
    particularly suitable if you are using only parts of the system -
    your default object map would automatically size down to whatever
    you have on your classpath. Without changing any default 'celtix.xml'.
16:23:07 [dandiep]
    12:22] <jvanzyl> i will watch for the CLAs landing, then make the
    account requests
16:23:28 [dandiep]
    he's watching to see which clas come in. Once they're in he'll get
    the account requests
16:23:50 [ema]
    ema has quit
16:25:06 [dandiep]
    thats the thing, it depends on your classpath. I might have
    everything on my classpath, but want to create a bus with a
    different configuration
16:28:10 [dkulp]
    I don't know the status on all the IONA CLA's. I thought they would
    have already been faxed.
16:28:25 [dkulp]
    Adi's isn't on today.
16:32:11 [asmyth]
    But you can if you provide the bus properties yourself and pass them
    to Bus.init. You could create them in a different container (e.g.
    Spring) using a config file, or rather have that container create
    them for you. Then extract them and pass them to Bus.init(). And if
    you don't use everything, why would you have it on your classpath -
    with maven they's only be on your classpath of you actually
    specified a dependency. 
16:35:15 [dandiep]
    well I shouldn't have to extract them and pass them to Bus.init().
    The container should manage the injenction and initialization of all
    the components for me. Also, I was talking about cases where I would
    have multiple buses running concurrently
16:42:59 [edelln]
    edelln has quit
16:42:59 [asmyth]
    asmyth has quit
16:43:13 [seanoc]
    seanoc has quit
16:43:19 [seanoc]
    seanoc has joined #celtix
16:43:38 [dandiep]
    jason just set up a #cxf channel on irc.codehaus.org. he's giving
    infrastructure updates there
16:44:02 [edelln]
    edelln has joined #celtix
16:45:48 [asmyth]
    asmyth has joined #celtix
16:47:17 [seanoc]
    seanoc has quit
16:47:22 [asmyth]
    And what would you have to do to set up these multiple buses in a
    different way using your container based approach?
16:49:01 [dandiep]
    I could configure them via spring... <bean id="bus1"
    class="...CXFBus">...</bean> or via pico or whatever
16:51:02 [asmyth]
    Why not use a BusFactory that uses Spring or whatever other
    container ... The way of initialising the bus as discussed above is
    just one way ...
16:54:24 [dandiep]
    It could just as well be a BusFactory. But the current BusFactory
    mixes up configuration and factory responsibilities. It handles
    command line args, classloading, and configuration
16:54:35 [asmyth]
    There could be an option on option on the bus that causes it to
    ignore the XXX files.
16:54:46 [dandiep]
    why can't it just be a layer on top?
16:55:02 [dandiep]
    ConfiguredBus or something like that
16:56:43 [asmyth]
    CeltixBus is already an implementation of an interface - not exactly
    now, but we can make it that way.
16:59:31 [dandiep]
    Yes, we can separate it out. The same with the
    BindingFactoryManagerImpl. We can move all the properties stuff out
    and into PropertiesBindingFactoryManagerImpl or something
17:02:21 [asmyth]
    I don't follow you there. What would the
    PropertiesBindingFactoryManagerImpl be good for?
17:03:07 [dandiep]
    it could do all the properties loading that you're doing in the
    current BindingFactoryManagerImpl
17:03:43 [asmyth]
    That would be shifted into the Bus's DeferredObjectManager anyway 
17:04:30 [dandiep]
    ok, so its in DeferredObjectManager. Lets just not make that part of
    the core bus implementation. Lets keep it as a separate module
17:05:47 [asmyth]
    It could live in common - do you really need a separate module (its
    going to be only a handful of classes if at all)?
17:07:35 [dandiep]
    I don't see a reason to have it in common. Then people are going to
    assume its there and build with it in mind