That's exactly the solution I've used in the past... and it's working
flawlessly, being the only disadvantage the need for a static to get it
working.
But I think this is acceptable for an application. Not for HiveMind itself
though.
This makes me think that HiveMind's current (1.1-beta-1) solution to service
serialization is out of place since it's an application level decision how
the registry is obtained (a static, jndi, whatever).
So I think hivemind could just detect when a service is Serializable and then
in the proxy the methods corresponding to java serialization protocol that
the service implementation has. Of course, leaving the current support as an
optional default in some way could be nice, but I can not see how to do that
in this moment.
El Mar 10 May 2005 00:06, Viktor Szathmary escribi�:
> I went with the service-id injection and implementing a
> readresolve/writereplace myself, just because i needed the service-id
> anyway, and found it more natural to use "this" instead of getSelf() -
> so I ended up with a service base class similar to this:
>
> public abstract class AbstractFooService implements FooServiceI,
> Serializable {
>
> private String name;
>
> public String getName() {
> return name;
> }
>
> public void setName(String name) {
> this.name = name;
> }
>
> protected Object writeReplace() {
> return new ServiceRef(getName());
> }
>
> private static class ServiceRef implements Serializable {
> private final String name;
>
> public ServiceRef(String name) {
> this.name = name;
> }
>
> protected Object readResolve() throws ObjectStreamException {
> Object service =
> MyRegistry.getInstance().getService(name,
> FooServiceI.class);
> if (service == null) {
> throw new InvalidObjectException("Unable to
> find in FDRegistry: " +
> name); }
> return service;
> }
>
> }
> }
>
> On 5/9/05, James Carman <[EMAIL PROTECTED]> wrote:
> > Yes, basically it'd be a service that's dependent upon itself...
> >
> > public class MyService implements MyServiceI
> > {
> > private MyServiceI self;
> >
> > public void setSelf( MyServiceI self )
> > {
> > this.self = self;
> > }
> >
> > public Foo findObject()
> > {
> > return new Foo( self );
> > }
> > }
> >
> > -----Original Message-----
> > From: Howard Lewis Ship [mailto:[EMAIL PROTECTED]
> > Sent: Monday, May 09, 2005 7:00 PM
> > To: [email protected]; Viktor Szathmary
> > Subject: Re: referencing "self" in a service
> >
> > BTW ... you can have HiveMind inject the service proxy into the service
> > implementation, just like any other collaborating service.
> >
> > On 5/9/05, Viktor Szathmary <[EMAIL PROTECTED]> wrote:
> > > On 5/9/05, Pablo Lalloni <[EMAIL PROTECTED]> wrote:
> > > > Or better:
> > > >
> > > > <service-point id="MyService" interface="com.example.MyServiceI">
> > > > <invoke-factory>
> > > > <construct class="com.example.MyService"
> >
> > service-id-property="aProperty"/>
> >
> > > > </invoke-factory>
> > > > </service-point>
> > >
> > > thanks, injecting the service-id works well for me. (and it is cool :)
> > >
> > > > Now we have support natively in HiveMind 1.1 for serialization with
> > > > a similar approach but you have to call registry.setupThread()
> > > > before the functionality can be used on a given thread.
> > >
> > > seems like it worked fine without setupThread in alpha-2 (but not in
> > > beta-1)... but I suspect the reason for this change was this: "Allow
> > > for running with multiple Registries. (HLS) Fixes HIVEMIND-83"
> > >
> > > thanks,
> > > viktor
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> > --
> > Howard M. Lewis Ship
> > Independent J2EE / Open-Source Java Consultant
> > Creator, Jakarta Tapestry
> > Creator, Jakarta HiveMind
> >
> > Professional Tapestry training, mentoring, support
> > and project work. http://howardlewisship.com
> >
> > ---------------------------------------------------------------------
> > 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]
--
Pablo I. Lalloni <[EMAIL PROTECTED]>
Tel�fono +54 (11) 4347-3177
Proyecto Pampa
Direcci�n Inform�tica Tributaria
AFIP
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
We are each entitled to our own opinion, but no one is entitled to his
own facts.
-- Patrick Moynihan
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
