Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [higgins-dev] IdASRegistry without XRDS


Don't know. I could do it either way, i.e.
1) Have the context factory instances at the global level, and let the IdASRegistry get them from there
2) Have the context factory instances directly in IdASRegistry's map

Right now with the code I checked in yesterday, it's 1). The advantage of 1) is that other components will also be able to find the context factories at a well-defined place.

On the other hand I agree with you that noone except the IdASRegistry should have to care about where to find them, so 2) somehow makes more sense.

Other opinions?

Markus

On 10/3/07, Daniel Sanders <dsanders@xxxxxxxxxx> wrote:
I'm not sure I understand this.  What, exactly is the instance handler "looking for"?  Regardless of where an htf:instance is defined in the settings, will it not create that object instance inside of whatever map it is found in?  The instance handler has no requirement that every htf:instance be inside the ComponentSettings map does it?  If we are only stating that we think that is where the STS expects context factory instances to be, then we may need some clarification.  As I understand this particular discussion, STS behavior is going to change with regards to context factories and their instantiation.  As I understand it, the STS will no longer have to know explicitly about context factory object instances.  It should not have to care where they are located in the settings map.  Only the IdentityAttributeService needs to know about them, so it seems makes sense to put them inside its map. -- Could someone verify/clarify these assumptions?

>>> Greg Byrd <gbyrd@xxxxxxxx> 10/3/2007 8:34 AM >>>

Currently, the instance handler looks for configuration info inside the ComponentSettings setting.  Assuming we want to keep that behavior (or else a lot of Mike's stuff will break), then I would propose to not move the configuration info for the factory instances inside the IdentityAttributeService setting.

A nice thing about using the (de facto) standard instance and singleton settings is that removes any dependency from the config.xml project to idas.  Before, we had a special handler for IdentityAttributeService, which created a dependency -- I was not quite happy with that.  Now that it's gone, I'd prefer to not reintroduce the dependency.

...Greg



Jim Sermersheim wrote:
Markus,

After you left the conversation, we wondered if we could move the factory instances (and their config of course) inside the IdentityAttributeService setting.

"Markus Sabadello" <msabadello@xxxxxxxxxxxxx> 10/02/07 5:01 PM >>> 

All,

Mike, Daniel, Greg and Jim really helped me today in IRC #higgins to
understand how the IdASRegistry needs to change.
Here's a short summary:
http://wiki.eclipse.org/ContextDiscoveryComponents_withoutXRDS

Please check this and let me know if anything about the described behavior
and/or example needs to change. A few more things may need to be adjusted,
but I think finally got the idea of what it means to "configure the
IdASRegistry using the Configuration API".

Thanks again for taking the time today.

Markus


_______________________________________________
higgins-dev mailing list
higgins-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/higgins-dev


_______________________________________________
higgins-dev mailing list
higgins-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/higgins-dev



Back to the top