Unfortunately there is a hard dependency to gigaspaces, or rather
their j_spaces API. I'm not sure about the licensing, but that is
definitely something we need to investigate. I could find no
information on their website. To my understanding this is not part of
the GigaSpaces implementation, but rather part of their addon API to
the JavaSpaces standard.
The problem with plain JavaSpaces is that it requires that you have a
Java class with public fields to represent each type of entity. And
this is in turn because it is based on Jini. j_spaces includes the
class ExternalEntry which is a generic entry that can be stored in the
Java Space without having to create a Java class for each type. If you
can find out how to get around this problem, please refactor or let me
know!
Of course, it is possible to just serialize everything down into the
space in a single field, but I would like to be able to take advantage
of indexing, templates etc. Simply put, just serializing it to a blob
doesn't take advantage of the space.
I have also completed the implementation of associations, although I
was a bit confused why the qualified name of ManyAssociation model
must differ in the EntityState? Is this a bug or have I missed
somthing? Like this:
JavaSpacesEntityStoreMixin
String qn = model.getQualifiedName();
qn = qn.replace('$', '&');
manyAssociations.put(qn, collection);
(By the way, I installed IntelliJ the other day and will try to learn it.... :-)
/Jan
On Mon, May 12, 2008 at 10:46 AM, Niclas Hedhman <[EMAIL PROTECTED]> wrote:
> Jan,
>
> there is a hard dependency on GigaSpaces' "com.j_spaces"...
>
> 1. Is it really necessary to have a hard coded dependency on the
> GigaSpaces implementation, instead of coding against the JavaSpaces
> Spec API? And wouldn't GigaSpaces simple be a drop-in replacement?
>
> 2. If that is not possible, are we allowed to upload the
> "gigaspaces-JSpaces" jar to a maven repository without breaking any
> licenses? I.e. we must have the right to redistribute without the user
> agreeing to any click-thru license and essentially not risking to be
> sued for using their stuff.
>
>
> I think I will modify it for the JavaSpaces Spec API for now, since it
> has already suffered from being outside the IDEA view and refactoring.
>
>
>
> Cheers
> Niclas
>
> _______________________________________________
> qi4j-dev mailing list
> [email protected]
> http://lists.ops4j.org/mailman/listinfo/qi4j-dev
>
_______________________________________________
qi4j-dev mailing list
[email protected]
http://lists.ops4j.org/mailman/listinfo/qi4j-dev
