Date: 2004-04-19T11:19:44 Editor: 63.69.231.245 <> Wiki: Jakarta HiveMind Wiki Page: ModuleResourcesProposal URL: http://wiki.apache.org/jakarta-hivemind/ModuleResourcesProposal
no comment Change Log: ------------------------------------------------------------------------------ @@ -188,3 +188,6 @@ DanielFeist: Ah, that's something i had in mind but forgot to mention. A service is always an implementation of an interface but it is unreasonable to try to fit resources into the same box. Some resources implement an interface (!DataSource, Context etc.) but others don't (e.g. !ResourceBundle, Properties, File, URL). ChristianEssl: While this is off-topic IMO it is a general problem that any injected Object has to implement an interface and has to be defined as a service. Further some service-implementations may implement different interfaces and so represent more than one service. Maybe implementations could be defined without necesseraly implenting a certain service and have in such a case their own id. I somehow imagine services as the interface of a module while implentations are the private - implementation - part. + +DanielFeist: Not particulary off topic as what you mention is the hurdle which seems to prevent resources being defined are services. You provide a more abstract way of looking at the problem i have been trying to tackle. My point of view was that its fair enough for a service to implement an interface and that this happens all the time whereas with resources this is not the case. This led me to the idea of defining resources as something complimentary to services that are biased to the needs of resources such as not having to implement an interface and managing the issue of backing store syncronization etc.. What you suggest it also another interesting and valid way too go which resolves a part of my proposal along with the other problem you mention of services that dont implement an interface ( does this happen much? should !HiveMind allow this? ). It would be good to see how this would work out in practice, maybe you could describe it in more detail with an example either as a part-solution to this proposal adding it along side the two proposals above or as a seperate change proposal? + --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
