IMHO this sounds like a rather good idea. Defining a service using an interface is unquestionably a best practice, but I'm not sure if it should be imposed by the framework. Especially when prototyping I think it would be nice to be able to define services through their implementing class only.
--knut From: Achim Huegen [mailto:[EMAIL PROTECTED] > > Do you mean the PrototypeBeanFactory? > This is an excellent proposal. By the way, it's mine ;-) > Did you have time to look at the implementation I filed to jira? > > Nevertheless its use is of quite different nature. > I want singletons and the possibility to reference my pojo services > from other services and configurations. > > Achim Huegen > > Howard Lewis Ship wrote: > > You might want to look at BeanFactory. A BeanFactory vends out > > objects instantiated by factories, but it is much looser (and less > > powerful) than services. There's also a proposal to have resources, > > which are objects built by something similar to the BuilderFactory, > > but not be services, just objects. > > > > On Mon, 12 Jul 2004 22:04:27 -0400, James Carman > > <[EMAIL PROTECTED]> wrote: > > > >>Actually, if you use CGLIB (I don't know about the capabilities of > >>javassist, as I'm no expert, so it might actually work > there too), you can > >>create interceptors on POJOs too! Spring already does this. > >> > >> > >> > >>-----Original Message----- > >>From: Achim Huegen [mailto:[EMAIL PROTECTED] > >>Sent: Monday, July 12, 2004 4:25 PM > >>To: [email protected] > >>Subject: POJOs as services > >> > >>I must admit I'm lazy, sometimes. Whenever I complete a new service > >>implementation I think 'oh no, now I have to split my service into > >>interface and implementation, just to be able to use it in hivemind. > >>Dealing with two units which both contain the same methods > and use linked > >>javadoc is extra work. Some service interfaces are not very > stable in the > >>beginning of development and some services will never > require the use of > >>interceptors or benefit from multiple implementations. > >> > >>So, why don't we support POJO (interface free) services? > >>- It would ease adoption of hivemind for new users, by > reducing some of > >>the overhead of using hivemind. > >>- Integration of existing classes would be able without adapters or > >>wrappers. For example you can setup a global > SimpleDateFormat instance > >>without problem. > >> > >>Of course it would not be possible to use interceptors or > any service > >>model besides primitive. > >> > >>In fact it is very easy to implement, just remove the > interface check from > >>ServicePointImpl.lookupServiceInterface and hivemind is > ready for POJOs. > >>Better: Let the serviceModel decide whether it want to support > >>non-interface classes. > >> > >>Achim Huegen > >> > >>------------------------------------------------------------ > --------- > >>To unsubscribe, e-mail: [EMAIL PROTECTED] > >>For additional commands, e-mail: > [EMAIL PROTECTED] > >> > >>------------------------------------------------------------ > --------- > >>To unsubscribe, e-mail: [EMAIL PROTECTED] > >>For additional commands, e-mail: > [EMAIL PROTECTED] > >> > >> > > > > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
