Date: 2004-04-19T06:50:22 Editor: HowardLewisShip <[EMAIL PROTECTED]> Wiki: Jakarta HiveMind Wiki Page: ModuleResourcesProposal URL: http://wiki.apache.org/jakarta-hivemind/ModuleResourcesProposal
no comment Change Log: ------------------------------------------------------------------------------ @@ -178,6 +178,9 @@ Please add your comments, ideas and suggestions here ... -HowardLewisShip: Not quite seeing what a resource can do that a service can not. For example, a data source: For this, I would picture a special factory, specific for creating a service that implements the DataSource interface. The parameters would be the same as what you are contributing to a <resource> element. For another service to obtain JDBC connections, it would simply inject the correct data source service. What your syntax (in the second implementation suggestion) seems to allow is a bit more succinct approach; annoymous <resource> elements, in place, vs. well known services. Lets noodle on this more and consider wider use cases. +HowardLewisShip: Not quite seeing what a resource can do that a service can not. For example, a data source: For this, I would picture a special factory, specific for creating a service that implements the !DataSource interface. The parameters would be the same as what you are contributing to a <resource> element. For another service to obtain JDBC connections, it would simply inject the correct data source service. What your syntax (in the second implementation suggestion) seems to allow is a bit more succinct approach; annoymous <resource> elements, in place, vs. well known services. Lets noodle on this more and consider wider use cases. DanielFeist: I agree there is a fine line between the concept of a service and of a resource. The main difference is that resources have different concerns as i tired to describe in the definitions above. What you seem to be suggesting is that the <service-points> are not in fact limited to services as I have defined but should be considered as a something which, through the use of factories, are able to provide services, resources or any number of other things. I see your point. That would mean that a service could be anything including a !DataSource or Properties etc. and that the factory it uses in <invoke-factory> would create these resource object in a similar way to in my examples. Is this correct? There are concerns specific to resources that would need to be thought though particularly thinking of resources that have a backing store such as change notification etc. I will look into this and add these specific concerns above. + +HowardLewisShip: If it can be represented as a Java interface, it can be a service. So certainly for things like !DataSource, this is practical. Strictly speaking, then, we don't need this concept of resources. However, strict is not always ''correct''. !HiveMind should be easy to use, and if people are going to get constantly bogged down creating resource-like services and get +annoyed or confused doing so, then we should adapt the framework to address this. For example, the <conversion> element was a recent addition: it doesn't do anything you can do with <rules>, but it makes it ''much'' easier. Something simiilar, to streamline your use cases may, or may not, be reasonable. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
