Re: Setting codebase on a per entry basis....

If I understand you setup correctly (a big if...), I would expect
the entries being produced by the FactoryEntry to be tagged with
the FactoryEntry's codebase (which I think is what you are looking for).
One (the primary?) reason this might not happen is if the Generic
processes have the the FactoryEntry (or possibly parts of the
FactoryEntry) in their classpath (which I suppose is quite likely
considering the concrete nature of template matching in spaces).

Can you talk a little more about your class hierarchy, what classes are
in each classpath, and what classes are in each codebase?

I suspect by refactoring your interfaces, classpaths, and codebases a
bit and possibly using preferred classes you can get the behavior you
want w/o having to hack outrigger.

Hope this helps

Ewan Silver wrote:
> Hi all,
>
> I am having a little codebase issue and am looking for some
> alternative viewpoints. My situation is as follows:
>
> I have multiple processes using a Javaspace to communicate. One of the
> Entries that is passing through the space can be considered to be a
> kind of FactoryEntry. Its role is to allow a generic JavaSpace process
> to create (and then write back into a Space) multiple instances of an
> Entry whose parent type is well known. The process that is using the
> FactoryEntry does not need to know the what type of Entry has actually
> been created.
>
> The generic process is able to retrieve and use the FactoryEntry in
> the first instance because the codebase has been set properly by the
> process that first placed the FactoryEntry into the space. The issue
> is: how does the Generic process set the codebase for the new Entrys
> that were created by the FactoryEntry?
>
> One solution would be to ensure that the codebase of the generic
> process always contains the details of any entry that it will ever
> potentially see. This is not really feasible because it will involve
> updating the codebase of many different generic processes everytime a
> new Entry type is created. This will be an administrative nightmare.
>
> What I really need is a way to programmatically set the codebase on a
> per Entry basis as it is written into the Space.
>
> It occurred to me that it might be possible to replace aspects of the
> Marshalling code within the Jeri Exporter used by the Javaspace (most
> notably MarshalOutputStreams and InvocationHandlers)  with code that
> dynamically allows me to set the codebase based on the type of Entry
> that is passing through. This would have the advantage in that I would
> only have to change code in a few places (notably the proxys generated
> by the Javaspace implementations I have deployed).
>
> This was quickly a non starter - the MarshalOutputStreams, etc used by
> the Jeri exporter are only for the PROXY - what I really need is a way
> to be able to set the codebase INSIDE the proxy, not the codebase FOR
> the proxy.
>
> I am left with the feeling that there is no way to programmatically
> set per Entry codebases without going inside the JavaSpace
> implementation and making internal proxy/server changes..... am I
> right in thinking this?



--
BTW, if you want to reply to this message, please direct your reply
to the list, thanks

John McClain                                    [email protected]
Sun Microsystems, Inc.
Burlington, MA

It could be said that without sticky tape there would be no such thing
as biocontainment.              -Richard Preston

===========================================================================
To unsubscribe, send email to [email protected] and include in the body
of the message "signoff JAVASPACES-USERS".  For general help, send email to
[email protected] and include in the body of the message "help".

To view past JAVASPACES-USERS postings, please see:
http://archives.java.sun.com/archives/javaspaces-users.html