Re: Extracting objects ( with their class names, ID methods and member variables) from ozone

Hi Kalyan,

Ozone uses the java serialization API for persistence. That means that
only object instance data is normally saved into the database; there is
no default storage of classes. This also means that there is no way to
recreate objects from Ozone if you do not have access to the original
class files.

There is however nothing that prevents you to implement your own
classloader and store classes, or actually a 'byte[]' containing
jvm-opcodes, into ozone; that classloader should implement
'defineClass()'.

Back your your case: if your tool already has the ability to generate
uml from class files, then you are already where you want to be. All
classes that can have their instances stored directly into ozone must
implement 'org.ozoneDB.OzoneCompatible'.

Cheers,
Leo

On Wed, 2003-01-22 at 15:34, kalyan wrote:
> Hi all  myself kalyan, I am working on tool to generate UML class 
> diagram from OODBMS. Is there any  available API for ozone, which  
> allows me to extract objects (with their class names, ID,  methods and 
> member variables) stored in  ozone.
> 
> Any help will be greatly appreciated
> 
> Thanks

problem with classpath

Re: problem with classpath

Hi

First of all - use the the build script build.bat or build.sh to build the 
source not your IDE or through javac. If you are doing this and still have 
problems you need to clarify some things such as what version you downloaded 
and are trying to build, what Java and OS you are running, othervise it's 
going to be hard to help you...

Best regards,
Per
On Thursday 23 January 2003 16.51, Simona Stringa wrote:
> Hi,
> I downloaded ozone and now I'm trying to install it but I can't build it.
> I guess it is a classpath problem but I don't know what (and where) are the
> needed files. I added all the jar files contained in the
> ..\ozone\server\lib but it doesn't work; what I am missing? or what is
> wrong?
>
> Si.

-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com

using ozone with Jboss

using ozone with Jboss

Re: using ozone with Jboss

Hi Jose,

If you want to continue to use ExternalDatabase then you do not need to do 
much just use your Session Beans as clients to the business logic provided by 
your ozone application. Alternativly you can create a JMX service that 
creates a valid ExternalDatabase connection to your server and register that 
with JNDI for easy acces from your session beans. If you want to run Ozone 
embedded into Jboss, take a look at the JMX embedded solution for JBoss in 
the thirdparty stuff in the latest cvs.  

Keep in mind that there is no support for distributed transactions between 
Ozone and Jboss yet. If this is something you want and have time to commit I 
would be happy to help you to try to implement this...

Best regards,
Per

On Friday 24 January 2003 13.11, José Carlos Meira e Silva wrote:
> Hi all,
>
> I am thinking in port my Ozone application to JBoss. I will use only
> session beans (the persistent classes will remain in ozone). Anibody can
> send me suggestions (or a how to...) to configure Ozone with JBoss? My
> application is using ozone external database.
>
> Thanks,
>
>  Jose Carlos.

-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com

design, RMI

I'm looking for more opinions, experiences, etc. on an idea.

I've currently designed all of my persistent objects as unnamed
OzoneObject's. I've created a home class for each object type with a
Hashtable containing Proxies to each instance of each class. This works
but I'm considering changing the data objects to be simply Serializable
and stored within the hashtable home for each type. This is so that the
client can manipulate the objects and have control over when and what is
communicated via RMI rather than having every get/set immediately
persist to ozone. I will add,delete,update methods to the OzoneObject
home classes which will be called when the client is ready to persist
something passing the proper Serializable object. I understand that
storing Serializable objects in an collection in ozone will cause all
collection elements to be loaded into memory. Obviously, I want to avoid
this. I was thinking of creating a wrapper OzoneObject for each
Serializable object to avoid that. Would this work as expected?

Thanks,

Ken

-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com

Re: design, RMI

Another question along the same lines. Consider an OzoneObject having a
Hashtable containing objects which is being accessed by code running
inside an OzoneObject, inside the DB that is. I'm trying to understand
how I would ensure that the Hashtable elements were lazily loaded
instead of all being loaded into memory with the Hashtable? As far as I
understand, the solution is to make the Hastable elements Ozone Proxies?
So then, the proxies provide two valuable features, lazy loading inside
the db, and communication to a standalone server? My concern is that
using proxies inside the db to gain lazy loading will cause additional
unnecessary overhead like RMI.

On Fri, 2003-01-24 at 13:51, Ken Brewer wrote:
> I'm looking for more opinions, experiences, etc. on an idea.
> 
> I've currently designed all of my persistent objects as unnamed
> OzoneObject's. I've created a home class for each object type with a
> Hashtable containing Proxies to each instance of each class. This works
> but I'm considering changing the data objects to be simply Serializable
> and stored within the hashtable home for each type. This is so that the
> client can manipulate the objects and have control over when and what is
> communicated via RMI rather than having every get/set immediately
> persist to ozone. I will add,delete,update methods to the OzoneObject
> home classes which will be called when the client is ready to persist
> something passing the proper Serializable object. I understand that
> storing Serializable objects in an collection in ozone will cause all
> collection elements to be loaded into memory. Obviously, I want to avoid
> this. I was thinking of creating a wrapper OzoneObject for each
> Serializable object to avoid that. Would this work as expected?
> 
> Thanks,
> 
> Ken
> 
> 
> 
> -------------------------------------------------------
> This SF.NET email is sponsored by:
> SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
> http://www.vasoftware.com
> _______________________________________________
> Ozone-users mailing list
> Ozone-users <at> lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/ozone-users

-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com

Re: design, RMI

On Fri, 2003-01-24 at 15:27, Ken Brewer wrote:
> Another question along the same lines. Consider an OzoneObject having a
> Hashtable containing objects which is being accessed by code running
> inside an OzoneObject, inside the DB that is. I'm trying to understand
> how I would ensure that the Hashtable elements were lazily loaded
> instead of all being loaded into memory with the Hashtable? As far as I
> understand, the solution is to make the Hastable elements Ozone Proxies?

Yes and no. All objects in a hashtable are all (de)serialized together
with that hashtable. References to an ozone object are (should always
be) proxies. So when you store an ozone object in a collection, you
store a proxy to that ozone object. All those proxies are the actual
objects in the hashtable.
That is also the reason why you should be _very_ careful with the use of
'this'; in 99.9% of all cases where one uses 'this' in a 'normal' java
program one must use 'self()' in ozone objects.

> So then, the proxies provide two valuable features, lazy loading inside
> the db, and communication to a standalone server? My concern is that
> using proxies inside the db to gain lazy loading will cause additional
> unnecessary overhead like RMI.

That's what prototyping is for 

> On Fri, 2003-01-24 at 13:51, Ken Brewer wrote:
> > I'm looking for more opinions, experiences, etc. on an idea.
> > 
> > I've currently designed all of my persistent objects as unnamed
> > OzoneObject's. I've created a home class for each object type with a
> > Hashtable containing Proxies to each instance of each class. This works
> > but I'm considering changing the data objects to be simply Serializable
> > and stored within the hashtable home for each type. This is so that the

Could work. But you would have to keep in mind that an OzoneObject can
be referenced from another object; a mere Serializable cannot. Well, it
can actually, but when ozone persist 2 different ozone objects
referencing the same Serializable, then you might end up having one OR
two serialized versions of that Serializable; the serialization api
stores a Serializable only once within an object stream, but 2 ozone
objects might be saved in different object streams.

If you use Serializable objects to store in your collection, make sure
they are only referenced by exactely 1 ozone object; also all changing
of that Serializable must take place through its contaning ozone object.

So it can be done, but you are walking a very thin line.

> > client can manipulate the objects and have control over when and what is
> > communicated via RMI rather than having every get/set immediately
> > persist to ozone. I will add,delete,update methods to the OzoneObject
> > home classes which will be called when the client is ready to persist
> > something passing the proper Serializable object.

Sounds like a ValueObject design pattern; easy to implement because
ozone already uses an interface structure.

 I understand that
> > storing Serializable objects in an collection in ozone will cause all
> > collection elements to be loaded into memory. Obviously, I want to avoid
> > this. I was thinking of creating a wrapper OzoneObject for each
> > Serializable object to avoid that. Would this work as expected?

Yes, probably. But I would not like to be the one doing maintenance on
that sort of code 

Cheers,
Leo

--

-- 
____________________________________________________________________________
Leo Mekenkamp      | Tired of Windows' blue screens, Internet Eplorer
and
+31 (0)6 41234919  | Outlook security vulnerabilities and Office'
pricetags?
___________________| Why not try the free and open source alternatives:
http://www.linux.org, http://www.mozilla.org and
http://www.openoffice.org

-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com

Re: design, RMI

Thanks for your response. I understand some of your points but other are
confusing. My requirements of the DB are minimal but I'm still not sure
that ozone will fit the bill. It seems that the guidance I'm getting is
very contradictory and there are several design gotcha's with ozone.

Use the ValueObject pattern but mere Serializable objects could be
problematic. That means all data access would have to copy values back
and forth between OzoneObjects and ValueObjects which causes more coding
and reduces performance.

Collections should contain proxies in order avoid loading each and every
entire object of a collection. My question then is: will using proxies
inside the db result in the same RMI, or similar, overhead as if the
proxy was used outside the db? The answer to this question was: do
prototyping. That makes no sense.

The documentation says that every proxy method call is itself a
transaction. Well, if so, then every get/set operation of a proxy is a
transaction? That is absurd, transaction overhead where I don't need it.
So then, to control a transaction, I have to pass ValueObjects to a
proxy method call then copy data back and forth between the
ValueObject's and the OzoneObject's because mere Serializable objects,
ValueObject's, cannot be persisted reliably.

If ozone and the app are running in the same VM, you still need to use
proxies to control transactions and get lazy loading but will I be
getting RMI too when I don't need it?

Then there's the searching issues. I asked for help on creating indexes
on fields and unique fields. The response was essentially that I was
thinking RDBMS not OODBMS. Ozone has no publicly documented way of
finding an object or determining what object types are stored in it or
anything of the sort. That leaves the programmer to code in mechanics of
doing this.

I'm not knocking ozone. I would love to be able to use a pure java
OODBMS and I'm depressed at the thought of doing another OR mapped
application but your advice isn't very helpful and doesn't seem to
consider the requirements of a real world application.

On Sat, 2003-01-25 at 09:34, Leo Mekenkamp wrote:
> On Fri, 2003-01-24 at 15:27, Ken Brewer wrote:
> > Another question along the same lines. Consider an OzoneObject having a
> > Hashtable containing objects which is being accessed by code running
> > inside an OzoneObject, inside the DB that is. I'm trying to understand
> > how I would ensure that the Hashtable elements were lazily loaded
> > instead of all being loaded into memory with the Hashtable? As far as I
> > understand, the solution is to make the Hastable elements Ozone Proxies?
> 
> Yes and no. All objects in a hashtable are all (de)serialized together
> with that hashtable. References to an ozone object are (should always
> be) proxies. So when you store an ozone object in a collection, you
> store a proxy to that ozone object. All those proxies are the actual
> objects in the hashtable.
> That is also the reason why you should be _very_ careful with the use of
> 'this'; in 99.9% of all cases where one uses 'this' in a 'normal' java
> program one must use 'self()' in ozone objects.
> 
> > So then, the proxies provide two valuable features, lazy loading inside
> > the db, and communication to a standalone server? My concern is that
> > using proxies inside the db to gain lazy loading will cause additional
> > unnecessary overhead like RMI.
> 
> That's what prototyping is for 
> 
> > On Fri, 2003-01-24 at 13:51, Ken Brewer wrote:
> > > I'm looking for more opinions, experiences, etc. on an idea.
> > > 
> > > I've currently designed all of my persistent objects as unnamed
> > > OzoneObject's. I've created a home class for each object type with a
> > > Hashtable containing Proxies to each instance of each class. This works
> > > but I'm considering changing the data objects to be simply Serializable
> > > and stored within the hashtable home for each type. This is so that the
> 
> Could work. But you would have to keep in mind that an OzoneObject can
> be referenced from another object; a mere Serializable cannot. Well, it
> can actually, but when ozone persist 2 different ozone objects
> referencing the same Serializable, then you might end up having one OR
> two serialized versions of that Serializable; the serialization api
> stores a Serializable only once within an object stream, but 2 ozone
> objects might be saved in different object streams.
> 
> If you use Serializable objects to store in your collection, make sure
> they are only referenced by exactely 1 ozone object; also all changing
> of that Serializable must take place through its contaning ozone object.
> 
> So it can be done, but you are walking a very thin line.
> 
> > > client can manipulate the objects and have control over when and what is
> > > communicated via RMI rather than having every get/set immediately
> > > persist to ozone. I will add,delete,update methods to the OzoneObject
> > > home classes which will be called when the client is ready to persist
> > > something passing the proper Serializable object.
> 
> Sounds like a ValueObject design pattern; easy to implement because
> ozone already uses an interface structure.
> 
>  I understand that
> > > storing Serializable objects in an collection in ozone will cause all
> > > collection elements to be loaded into memory. Obviously, I want to avoid
> > > this. I was thinking of creating a wrapper OzoneObject for each
> > > Serializable object to avoid that. Would this work as expected?
> 
> Yes, probably. But I would not like to be the one doing maintenance on
> that sort of code 
> 
> Cheers,
> Leo
> 
> -- 
> ____________________________________________________________________________
> Leo Mekenkamp      | Tired of Windows' blue screens, Internet Eplorer
> and
> +31 (0)6 41234919  | Outlook security vulnerabilities and Office'
> pricetags?
> ___________________| Why not try the free and open source alternatives:
> http://www.linux.org, http://www.mozilla.org and
> http://www.openoffice.org
> 
> 
> 
> -------------------------------------------------------
> This SF.NET email is sponsored by:
> SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
> http://www.vasoftware.com
> _______________________________________________
> Ozone-users mailing list
> Ozone-users <at> lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/ozone-users

-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com