cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dan Diephouse <...@envoisolutions.com>
Subject Re: DeferredObjectManager
Date Tue, 08 Aug 2006 16:46:53 GMT
True... we're working on that. We are waiting for some accounts to get 
set up yet so we can actually work on the code once its in there.

I'll write up a summary of the new code this afternoon so people can 
feel somewhat like they're on same page. Maybe we can publish a dump too.

- Dan

Guillaume Nodet wrote:

> I guess it will be difficult to follow these discussions as long as 
> there is
> no code in svn :(
>
> On 8/8/06, Andrea Smyth <andrea.smyth@iona.com> wrote:
>
>>
>> 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
>>
>>
>>
>>
>
>


-- 
Dan Diephouse
(616) 971-2053
Envoi Solutions LLC
http://netzooid.com


Mime
View raw message