You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cxf.apache.org by Andrea Smyth <an...@iona.com> on 2006/08/08 18:13:01 UTC
DeferredObjectManager
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
Re: DeferredObjectManager
Posted by Dan Diephouse <da...@envoisolutions.com>.
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 <an...@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
Re: DeferredObjectManager
Posted by Guillaume Nodet <gn...@gmail.com>.
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 <an...@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
Re: Component discovery/DeferredObjectManager
Posted by Andrea Smyth <an...@iona.com>.
Some comments below ...
Dan Diephouse wrote:
> Lets back up a little bit first so people can follow a bit better.
> There are two things I feel we need to have thorough discussions
> about. The first, which is in this email, I think could be referred to
> as discovery. The second is Configuration, but we'll get to that
> later. I want to outline the case of the BindingFactoryManager here as
> it succinctly encapsulates what we need to do.
>
> In the merged code base we have a class called BindingFactory. This
> class takes metadata about the binding called BindingInfo and turns it
> into classes which actually handle the binding processing. So for SOAP
> it would take our metadata about the style, use, etc and configure
> interceptors which process the xml.
>
> Now we have all these BindingFactorys. One for REST, one for SOAP, one
> for JBI, etc. We need a way to look up the appropriate BindingFactory
> from the code which takes a WSDL and builds a Service from it. This is
> where the BindingFactoryManager comes into play. It has a pretty
> simple interface:
>
> public interface BindingFactoryManager {
> void registerBindingFactory(String name, BindingFactory binding)
> void unregisterBindingFactory(String name)
> BindingFactory getBindingFactory(String name);
> }
>
> Now the big question here is - how does the BindingFactoryManager
> learn about the BindingFactorys?
>
> Currently in Celtix there is a binding.properties file like this which
> the BindingFactoryManagerImpl reads in:
>
> <properties>
> <entry
> key="http://schemas.xmlsoap.org/wsdl/soap/">org.objectweb.celtix.bindings.soap.SOAPBindingFactory</entry>
>
> <entry
> key="http://schemas.xmlsoap.org/wsdl/soap/http">org.objectweb.celtix.bindings.soap.SOAPBindingFactory</entry>
>
> <entry
> key="http://celtix.objectweb.org/transports/jms">org.objectweb.celtix.bindings.soap.SOAPBindingFactory</entry>
>
> </properties>
>
> One can see each BindingFactory in the xml has a name (aka key) and a
> class. The BindingFactoryManagerImpl reads these in and loads each one.
One binding factory can serve multiple namespaces (bindingIds) - i.e. we
can have the same BindingFactory stored under the same key in the
BindingFactoryManager.
>
> The proposed DeferredObjectManager is an improvement on this format,
> where there is something like:
>
> <extensions>
> <extension namespace="http://cxf.apache.org/bindings"
> name="http://schemas.xmlsoap.org/wsdl/soap/"
> class="org.objectweb.celtix.bindings.soap.SOAPBindingFactory"/>
> </extensions>
It would be more like:
1)
<extension name="bindingFactoryManager"
class="org.objectweb.celtix.bindings.BindingFactoryManagerImpl" deferred
="false"/> // no namespace child elements here
and 2)
<extension class="org.objectweb.celtix.bindings.soap.SoapBindingFactory"
deferred="true">
<namespace>http://schemas.xmlsoap.org/wsdl/soap/</namespace>
<namespace>http://schemas.xmlsoap.org/wsdl/soap/http</namespace>
</extension>
The name attribute of the first extension element is used to make the
extension available through the Bus via
getObject("bindingFactoryManager", BindingFactoryManager.class);
Not sure if the second element should have its name attribute set ? To
"bindingFactoryManager" maybe and use this name in constructor of the
DeferredMap below? Or do we both a name and a namespace attribute in the
extension element for that purpose?
I find it a bit confusing to have child elements and attributes of the
same name.
Andrea.
>
> Now, I believe the point of this is that a) an extension could be
> registered for any manager (TransportManager, BindingFactoryManager,
> etc) and b) that the DeferredObjectManager would not load things until
> they were needed.
>
> I am of the opinion that this kind of thing shouldn't be part of the
> core. It is the job of the container. I.e. BindingFactoryManager
> should not be aware of whatever it is that loads teh transports. So we
> discussed doing something like so:
>
> // this would read in all the <extension> files
> DeferredObjectManager dom = new DefferredObjectManager();
> // the deferred map looks up extensions in the specified namespace
> DeferredMap bindings = new DeferredMap("http://cxf.apache.org/bindings")
>
> BindingFactoryManager bfm = new BindingFactoryManagerImpl(bindings);
>
> This has a couple benefits:
> - IMO its nicer because we've inverted control. The
> BindingFactoryManager isn't aware of things that load Bindings. It
> just manages bindings.
> - The configuration of the BindingFactoryManager is now separate from
> its implementation. We can move the classes (deferredobjectmanager)
> out of the core and have it be a separate container.
> - We now play nicer with other containers - Spring, Plexus, Pico, etc
> could all supply the Map of bindingfactorys.
> - The core is now focused on being an excellent API, not being a
> container.
>
> I am still not 100% sure I like having a deferredobjectmanager when
> there are a bunch of other containers out there that do this type of
> thing. However, this does have benefits because there are a) no
> dependencies and b) it is very small.
>
> Thoughts?
> - Dan
>
> Andrea Smyth 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.
>>
>>
>
>
Component discovery/DeferredObjectManager
Posted by Dan Diephouse <da...@envoisolutions.com>.
Lets back up a little bit first so people can follow a bit better. There
are two things I feel we need to have thorough discussions about. The
first, which is in this email, I think could be referred to as
discovery. The second is Configuration, but we'll get to that later. I
want to outline the case of the BindingFactoryManager here as it
succinctly encapsulates what we need to do.
In the merged code base we have a class called BindingFactory. This
class takes metadata about the binding called BindingInfo and turns it
into classes which actually handle the binding processing. So for SOAP
it would take our metadata about the style, use, etc and configure
interceptors which process the xml.
Now we have all these BindingFactorys. One for REST, one for SOAP, one
for JBI, etc. We need a way to look up the appropriate BindingFactory
from the code which takes a WSDL and builds a Service from it. This is
where the BindingFactoryManager comes into play. It has a pretty simple
interface:
public interface BindingFactoryManager {
void registerBindingFactory(String name, BindingFactory binding)
void unregisterBindingFactory(String name)
BindingFactory getBindingFactory(String name);
}
Now the big question here is - how does the BindingFactoryManager learn
about the BindingFactorys?
Currently in Celtix there is a binding.properties file like this which
the BindingFactoryManagerImpl reads in:
<properties>
<entry
key="http://schemas.xmlsoap.org/wsdl/soap/">org.objectweb.celtix.bindings.soap.SOAPBindingFactory</entry>
<entry
key="http://schemas.xmlsoap.org/wsdl/soap/http">org.objectweb.celtix.bindings.soap.SOAPBindingFactory</entry>
<entry
key="http://celtix.objectweb.org/transports/jms">org.objectweb.celtix.bindings.soap.SOAPBindingFactory</entry>
</properties>
One can see each BindingFactory in the xml has a name (aka key) and a
class. The BindingFactoryManagerImpl reads these in and loads each one.
The proposed DeferredObjectManager is an improvement on this format,
where there is something like:
<extensions>
<extension namespace="http://cxf.apache.org/bindings"
name="http://schemas.xmlsoap.org/wsdl/soap/"
class="org.objectweb.celtix.bindings.soap.SOAPBindingFactory"/>
</extensions>
Now, I believe the point of this is that a) an extension could be
registered for any manager (TransportManager, BindingFactoryManager,
etc) and b) that the DeferredObjectManager would not load things until
they were needed.
I am of the opinion that this kind of thing shouldn't be part of the
core. It is the job of the container. I.e. BindingFactoryManager should
not be aware of whatever it is that loads teh transports. So we
discussed doing something like so:
// this would read in all the <extension> files
DeferredObjectManager dom = new DefferredObjectManager();
// the deferred map looks up extensions in the specified namespace
DeferredMap bindings = new DeferredMap("http://cxf.apache.org/bindings")
BindingFactoryManager bfm = new BindingFactoryManagerImpl(bindings);
This has a couple benefits:
- IMO its nicer because we've inverted control. The
BindingFactoryManager isn't aware of things that load Bindings. It just
manages bindings.
- The configuration of the BindingFactoryManager is now separate from
its implementation. We can move the classes (deferredobjectmanager) out
of the core and have it be a separate container.
- We now play nicer with other containers - Spring, Plexus, Pico, etc
could all supply the Map of bindingfactorys.
- The core is now focused on being an excellent API, not being a container.
I am still not 100% sure I like having a deferredobjectmanager when
there are a bunch of other containers out there that do this type of
thing. However, this does have benefits because there are a) no
dependencies and b) it is very small.
Thoughts?
- Dan
Andrea Smyth 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.
>
>
--
Dan Diephouse
(616) 971-2053
Envoi Solutions LLC
http://netzooid.com