cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Guillaume Nodet" <gno...@gmail.com>
Subject Re: DeferredObjectManager
Date Tue, 08 Aug 2006 16:33:41 GMT
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
>
>
>
>


-- 
Cheers,
Guillaume Nodet

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message