You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@continuum.apache.org by Rahul Thakur <ra...@gmail.com> on 2007/01/03 04:43:09 UTC
[discuss] iBatis, JPA and Java 5.0
These buzzwords have been making rounds on IRC and dev list :-), and
after slight digging around I found a reference to a similar discussion
here:
http://www.mail-archive.com/ibatis-user-java@incubator.apache.org/msg01251.html
Agreed that the store implementation for Continuum should be pluggable,
and if we are rethinking JPOX, then IMHO it might be worth taking into
account JPA and Java 5.0.
What do others think?
Cheers,
Rahul
Re: [discuss] iBatis, JPA and Java 5.0
Posted by Brett Porter <br...@apache.org>.
On 03/01/2007, at 4:29 PM, Rahul Thakur wrote:
> I am not sure what you refer to by:
> [snip]
> The way Continuum is designed means
>> you get to a certain point where you want to save an object and
>> you find that you can't, or you aren't saving everything you want,
>> etc.
> [/snip]
>
> Could you please give an example?
Probably stretching my memory a bit too much for specific examples.
ISTR there being worse things, but even looking at the
DefaultBuildController there are a few ugly things.
In particular, storing build results, then having to get them back
because they are going to be used again.
I think the transactions aren't long enough. It's possible to do
things like:
doSomething
saveSomething
throw an exception
didn't get to save something else, so something is in a 'partial' state.
This is a continuum design issue, and if it were fixed the store
would be simpler because you wouldn't need to be constantly updating/
storing/getting objects if they are still in the same open
transaction that will either be committed or rolled back when it is
done.
But bear in mind this is more my general impression than careful
analysis :)
It was definitely the build results, the build number and the build
state that I felt wasn't managed carefully enough.
- Brett
Re: [discuss] iBatis, JPA and Java 5.0
Posted by Trygve Laugstøl <tr...@apache.org>.
Carlos Sanchez wrote:
> On 1/2/07, Rahul Thakur <ra...@gmail.com> wrote:
>> ----- Original Message -----
>> From: "Brett Porter" <br...@apache.org>
>> To: <co...@maven.apache.org>
>> Sent: Wednesday, January 03, 2007 4:59 PM
>> Subject: Re: [discuss] iBatis, JPA and Java 5.0
>>
>>
>> > I've been thinking stay with JDO for now, look at JPA in the long
>> > term.
>> >
>> > I haven't used iBatis, and would be happy to hear some practical
>> > experience from people who have. I tend to think of it as "a more
>> > productive JDBC", as opposed to the different programming model of
>> > JDO/Hibernate/JPA.
>> >
>>
>> I haven't used it either, but that thread got me thinking about what
>> would drive the choice of a persistence solution if we were rethinking
>> jpox.
>
> I did use it and yes, it's a "more productive" JDBC. If you need to do
> low level stuff then go for ibatis, but I wouldn't do it for Continuum
> unless really needed, it's going to be pretty verbose.
I agree with this, iBatis makes your code very verbose and it is not
nearly as elegant as it coult be. I've been trying out out iBatis for a
while not, and it's not really that much easier to program with than
JDO, and if you have a rich object model like Continuum has it really is
a pain to make sure you SELECT the entire model and UPDATE when storing.
Doing dirty checking and fancy stuff like that that the OODB/ORM-style
tools can do you can just forget about doing.
> I don't thing it's a good idea to have several implementations of the
> data store (JDO, ibatis, JPA,...), there's gonna be a lot of
> refactoring work and one will be the default while the others won't
> get a good level of stability not being widely used.
I wholeheartedly agree that having many implementations of the store is
not a good idea as other has said in this thread before, the different
models are too different and there is no good reason to have many
implementations at the same time. Branching and trying out a replacement
is one thing, but there should not be multiple implementations at once.
[snip]
--
Trygve
Re: [discuss] iBatis, JPA and Java 5.0
Posted by Carlos Sanchez <ca...@apache.org>.
On 1/2/07, Rahul Thakur <ra...@gmail.com> wrote:
> ----- Original Message -----
> From: "Brett Porter" <br...@apache.org>
> To: <co...@maven.apache.org>
> Sent: Wednesday, January 03, 2007 4:59 PM
> Subject: Re: [discuss] iBatis, JPA and Java 5.0
>
>
> > I've been thinking stay with JDO for now, look at JPA in the long
> > term.
> >
> > I haven't used iBatis, and would be happy to hear some practical
> > experience from people who have. I tend to think of it as "a more
> > productive JDBC", as opposed to the different programming model of
> > JDO/Hibernate/JPA.
> >
>
> I haven't used it either, but that thread got me thinking about what
> would drive the choice of a persistence solution if we were rethinking
> jpox.
I did use it and yes, it's a "more productive" JDBC. If you need to do
low level stuff then go for ibatis, but I wouldn't do it for Continuum
unless really needed, it's going to be pretty verbose.
I don't thing it's a good idea to have several implementations of the
data store (JDO, ibatis, JPA,...), there's gonna be a lot of
refactoring work and one will be the default while the others won't
get a good level of stability not being widely used.
>
> > Having worked with a number of models myself on large production
> > sites (straight jdbc, castor, object structured jdbc, and now jdo2),
> > I really like the design of the jdo2 API. It does a good job of
> > giving a nice clean API that manages to keep the declarativeness
> > while still allowing good performance through fetch groups and lazy
> > loading.
> >
> > I think the store itself that we have is quite stable, but it's API
> > is too simple.
>
> Yep, it is verbose, IMHO. I am keen to explore and see if we can
> consolidate some of them by wrapping up the possible criteria in a
> 'Query' object and make the store interface leaner.
>
> >
> > I think that the way we use the store hasn't taken into consideration
> > the way that the objects are returned (ie, they may be missing some
> > fields you didn't request, etc). The way Continuum is designed means
> > you get to a certain point where you want to save an object and you
> > find that you can't, or you aren't saving everything you want, etc.
> >
>
> I am not sure what you refer to by:
> [snip]
> The way Continuum is designed means
> > you get to a certain point where you want to save an object and you
> > find that you can't, or you aren't saving everything you want, etc.
> [/snip]
>
> Could you please give an example?
>
> > Changing to another type of store will make that worse and we'll
> > discover the same problems and have to make the same design choices
> > then. So, I'd prefer to address them first.
> >
>
> Yeah, possibly will make it worse if and when we start :-), and +1 on
> the design choices bit.
>
> > IMO, we need to centralise more of the object access. So, obviously
> > we've centralised JDO to the store, which is good. But I think you'll
> > find the use of the store itself is a little too proliferated, at
> > least for the level of abstraction you have.
> >
>
> That is what we want to try on that branch that Jesse created. I am
> hoping I can get a proof out before Jesse wraps up his changes :-)
>
> Rahul
>
> > What you ideally want to be able to do is say that a certain set of
> > actions are going to constitute the entire transaction, and do the
> > reading from the store at the start and the saving at the end
> >
> > I'm oversimplifying, but that's what I'm generally thinking. I
> > haven't looked at that code in a year and a half though - so maybe
> > it's not quite as relevant now.
> >
> > - Brett
> >
> > On 03/01/2007, at 2:43 PM, Rahul Thakur wrote:
> >
> >>
> >> These buzzwords have been making rounds on IRC and dev list :-), and
> >> after slight digging around I found a reference to a similar
> >> discussion here:
> >> http://www.mail-archive.com/ibatis-user-java@incubator.apache.org/
> >> msg01251.html
> >>
> >> Agreed that the store implementation for Continuum should be
> >> pluggable, and if we are rethinking JPOX, then IMHO it might be
> >> worth taking into account JPA and Java 5.0.
> >>
> >> What do others think?
> >>
> >> Cheers,
> >> Rahul
>
>
--
I could give you my word as a Spaniard.
No good. I've known too many Spaniards.
-- The Princess Bride
Re: [discuss] iBatis, JPA and Java 5.0
Posted by Rahul Thakur <ra...@gmail.com>.
----- Original Message -----
From: "Brett Porter" <br...@apache.org>
To: <co...@maven.apache.org>
Sent: Wednesday, January 03, 2007 4:59 PM
Subject: Re: [discuss] iBatis, JPA and Java 5.0
> I've been thinking stay with JDO for now, look at JPA in the long
> term.
>
> I haven't used iBatis, and would be happy to hear some practical
> experience from people who have. I tend to think of it as "a more
> productive JDBC", as opposed to the different programming model of
> JDO/Hibernate/JPA.
>
I haven't used it either, but that thread got me thinking about what
would drive the choice of a persistence solution if we were rethinking
jpox.
> Having worked with a number of models myself on large production
> sites (straight jdbc, castor, object structured jdbc, and now jdo2),
> I really like the design of the jdo2 API. It does a good job of
> giving a nice clean API that manages to keep the declarativeness
> while still allowing good performance through fetch groups and lazy
> loading.
>
> I think the store itself that we have is quite stable, but it's API
> is too simple.
Yep, it is verbose, IMHO. I am keen to explore and see if we can
consolidate some of them by wrapping up the possible criteria in a
'Query' object and make the store interface leaner.
>
> I think that the way we use the store hasn't taken into consideration
> the way that the objects are returned (ie, they may be missing some
> fields you didn't request, etc). The way Continuum is designed means
> you get to a certain point where you want to save an object and you
> find that you can't, or you aren't saving everything you want, etc.
>
I am not sure what you refer to by:
[snip]
The way Continuum is designed means
> you get to a certain point where you want to save an object and you
> find that you can't, or you aren't saving everything you want, etc.
[/snip]
Could you please give an example?
> Changing to another type of store will make that worse and we'll
> discover the same problems and have to make the same design choices
> then. So, I'd prefer to address them first.
>
Yeah, possibly will make it worse if and when we start :-), and +1 on
the design choices bit.
> IMO, we need to centralise more of the object access. So, obviously
> we've centralised JDO to the store, which is good. But I think you'll
> find the use of the store itself is a little too proliferated, at
> least for the level of abstraction you have.
>
That is what we want to try on that branch that Jesse created. I am
hoping I can get a proof out before Jesse wraps up his changes :-)
Rahul
> What you ideally want to be able to do is say that a certain set of
> actions are going to constitute the entire transaction, and do the
> reading from the store at the start and the saving at the end
>
> I'm oversimplifying, but that's what I'm generally thinking. I
> haven't looked at that code in a year and a half though - so maybe
> it's not quite as relevant now.
>
> - Brett
>
> On 03/01/2007, at 2:43 PM, Rahul Thakur wrote:
>
>>
>> These buzzwords have been making rounds on IRC and dev list :-), and
>> after slight digging around I found a reference to a similar
>> discussion here:
>> http://www.mail-archive.com/ibatis-user-java@incubator.apache.org/
>> msg01251.html
>>
>> Agreed that the store implementation for Continuum should be
>> pluggable, and if we are rethinking JPOX, then IMHO it might be
>> worth taking into account JPA and Java 5.0.
>>
>> What do others think?
>>
>> Cheers,
>> Rahul
Re: [discuss] iBatis, JPA and Java 5.0
Posted by Christian Edward Gruber <cg...@israfil.net>.
Sorry, I was writing my post when this came in. I'm in general
agreement, and while I do think moving to something more than JDO is
important, Brett is right, the use of hte store could use a good audit
and re-factor. Probably some of the problems of strange access
approaches used currently could be identified with adding some unit
tests that expand the current assumptions of the model. These would then
provide some good regression tests for the eventual move to something
more robust.
Also, I really like modello, but don't know if there are plans/schedules
around its support for other forms of persistence than JDO. (Though if
we went with JPA and annotated the model, we could go the other way,
generating all the other artifacts from the code.)
regards,
Christian.
Brett Porter wrote:
> I've been thinking stay with JDO for now, look at JPA in the long term.
>
> I haven't used iBatis, and would be happy to hear some practical
> experience from people who have. I tend to think of it as "a more
> productive JDBC", as opposed to the different programming model of
> JDO/Hibernate/JPA.
>
> Having worked with a number of models myself on large production sites
> (straight jdbc, castor, object structured jdbc, and now jdo2), I
> really like the design of the jdo2 API. It does a good job of giving a
> nice clean API that manages to keep the declarativeness while still
> allowing good performance through fetch groups and lazy loading.
>
> I think the store itself that we have is quite stable, but it's API is
> too simple.
>
> I think that the way we use the store hasn't taken into consideration
> the way that the objects are returned (ie, they may be missing some
> fields you didn't request, etc). The way Continuum is designed means
> you get to a certain point where you want to save an object and you
> find that you can't, or you aren't saving everything you want, etc.
>
> Changing to another type of store will make that worse and we'll
> discover the same problems and have to make the same design choices
> then. So, I'd prefer to address them first.
>
> IMO, we need to centralise more of the object access. So, obviously
> we've centralised JDO to the store, which is good. But I think you'll
> find the use of the store itself is a little too proliferated, at
> least for the level of abstraction you have.
>
> What you ideally want to be able to do is say that a certain set of
> actions are going to constitute the entire transaction, and do the
> reading from the store at the start and the saving at the end
>
> I'm oversimplifying, but that's what I'm generally thinking. I haven't
> looked at that code in a year and a half though - so maybe it's not
> quite as relevant now.
>
> - Brett
>
--
*christian** gruber + process coach and architect*
*Israfil Consulting Services Corporation*
*email** cgruber@israfil.net + bus 905.640.1119 + mob 416.998.6023*
Re: [discuss] iBatis, JPA and Java 5.0
Posted by Rahul Thakur <ra...@gmail.com>.
Hi Erik,
I am playing around refactoring some store stuff using jdo and ibatis on
a separate branch (key-refactoring) and welcome any help i can get with
JDO :-). I am usually on #continuum on IRC (irc.codehaus.org), or happy
to join jpox lists.
Cheers,
Rahul
Erik Bengtson wrote:
> Quoting Jason van Zyl <ja...@maven.org>:
>
>
>> JDO is not bad, but JPOX has proven to be less then robust.
>>
>
> Sometime ago I joined this list to provide an easier a communication channel for
> solving continuum/jpox issues and besides a few emails no one has ever
> requested any help on issues neither gave any feedback.
>
> JPOX is the only implementation that passes JDO 2 TCK, and less than robust
> argument does not sounds fair since you dont even ask for help.
>
> Regards,
>
> Erik Bengtson
>
>
>
Re: [discuss] iBatis, JPA and Java 5.0
Posted by Jesse McConnell <je...@gmail.com>.
its not just jpox in continuum but also the jpox usage in the
plexus-security rbac and user management stores that joakim worked
through a couple of months back while consulting with you I think.
Joakim can explain more on that if he likes. I just remember that we
had a mess of issues in getting things working there because of
something like certain lists of objects where not supported or
something of that ilk. We need to go back through and refactor some
of the fields on the models and we're kinda dreading having to do it
since we'll have to deal with the store again.
jesse
On 1/3/07, Erik Bengtson <er...@jpox.org> wrote:
> Quoting Jason van Zyl <ja...@maven.org>:
>
> > JDO is not bad, but JPOX has proven to be less then robust.
>
> Sometime ago I joined this list to provide an easier a communication channel for
> solving continuum/jpox issues and besides a few emails no one has ever
> requested any help on issues neither gave any feedback.
>
> JPOX is the only implementation that passes JDO 2 TCK, and less than robust
> argument does not sounds fair since you dont even ask for help.
>
> Regards,
>
> Erik Bengtson
>
>
--
jesse mcconnell
jesse.mcconnell@gmail.com
Re: [discuss] iBatis, JPA and Java 5.0
Posted by Erik Bengtson <er...@jpox.org>.
Quoting Jason van Zyl <ja...@maven.org>:
> JDO is not bad, but JPOX has proven to be less then robust.
Sometime ago I joined this list to provide an easier a communication channel for
solving continuum/jpox issues and besides a few emails no one has ever
requested any help on issues neither gave any feedback.
JPOX is the only implementation that passes JDO 2 TCK, and less than robust
argument does not sounds fair since you dont even ask for help.
Regards,
Erik Bengtson
Re: [discuss] iBatis, JPA and Java 5.0
Posted by Jason van Zyl <ja...@maven.org>.
On 2 Jan 07, at 10:59 PM 2 Jan 07, Brett Porter wrote:
> I've been thinking stay with JDO for now, look at JPA in the long
> term.
>
I think anyone who wanted to look at an iBatis store I say go for it.
JDO is not bad, but JPOX has proven to be less then robust. If we
were using Kodo it would be a different story and it's too bad that
BEA did not release the JDO bindings for the JPA stuff.
I would also say try another tool like a JDBM store so that you get
the magic three. If the store API was fleshed out and worked with
three backend implementations you would have something that works. I
think part of the problem is that we've let JDO shape the store API
instead of arriving at an ideal API. I think this can only be
accomplished by attempting to use another back end store.
If Rahul wants to try iBatis I say let it rip.
Jason.
>
Re: [discuss] iBatis, JPA and Java 5.0
Posted by Brett Porter <br...@apache.org>.
I've been thinking stay with JDO for now, look at JPA in the long term.
I haven't used iBatis, and would be happy to hear some practical
experience from people who have. I tend to think of it as "a more
productive JDBC", as opposed to the different programming model of
JDO/Hibernate/JPA.
Having worked with a number of models myself on large production
sites (straight jdbc, castor, object structured jdbc, and now jdo2),
I really like the design of the jdo2 API. It does a good job of
giving a nice clean API that manages to keep the declarativeness
while still allowing good performance through fetch groups and lazy
loading.
I think the store itself that we have is quite stable, but it's API
is too simple.
I think that the way we use the store hasn't taken into consideration
the way that the objects are returned (ie, they may be missing some
fields you didn't request, etc). The way Continuum is designed means
you get to a certain point where you want to save an object and you
find that you can't, or you aren't saving everything you want, etc.
Changing to another type of store will make that worse and we'll
discover the same problems and have to make the same design choices
then. So, I'd prefer to address them first.
IMO, we need to centralise more of the object access. So, obviously
we've centralised JDO to the store, which is good. But I think you'll
find the use of the store itself is a little too proliferated, at
least for the level of abstraction you have.
What you ideally want to be able to do is say that a certain set of
actions are going to constitute the entire transaction, and do the
reading from the store at the start and the saving at the end
I'm oversimplifying, but that's what I'm generally thinking. I
haven't looked at that code in a year and a half though - so maybe
it's not quite as relevant now.
- Brett
On 03/01/2007, at 2:43 PM, Rahul Thakur wrote:
>
> These buzzwords have been making rounds on IRC and dev list :-),
> and after slight digging around I found a reference to a similar
> discussion here:
> http://www.mail-archive.com/ibatis-user-java@incubator.apache.org/
> msg01251.html
>
> Agreed that the store implementation for Continuum should be
> pluggable, and if we are rethinking JPOX, then IMHO it might be
> worth taking into account JPA and Java 5.0.
>
> What do others think?
>
> Cheers,
> Rahul
Re: [discuss] iBatis, JPA and Java 5.0
Posted by Rahul Thakur <ra...@gmail.com>.
----- Original Message -----
From: "Rahul Thakur" <ra...@gmail.com>
To: <co...@maven.apache.org>
Sent: Monday, January 08, 2007 4:05 PM
Subject: Re: [discuss] iBatis, JPA and Java 5.0
>
> <snip>
>> Having said all of that, my vote (which no one need care about, since
>> I haven't had much time to actually contribute code here) is to
>> support hibernate with slight abstraction on top of it (modeled on
>> JPA's entity manager), so we get the benefits of transparent
>> persistence without requiring Java 5.0 - at least until we get to the
>> point where we can run in java 5 but execute maven/ant in java 1.4
>> and earlier. Once we are at that point, maybe we can move to JPA
>> (which is a small delta), or at least update the abstraction some.
>>
>> If we were to decide that, hey, screw jdk 1.4, let's just go with
>> java5, then I'd just suggest going for JPA as the abstraction. It's
>> got problems, but everything does, and it's an increasingly adopted
>> standard with some decent implementations.
> </snip>
>
> Okies, purely experimental and exploring options more out of curiosity
> than anything else, here's more on this thread.....
>
> If I gathered correctly from the #openjpa, all needed to use JPA is to
> enhance the model classes with OpenJPA Enhancer. I haven't finished
> trying it yet but I am in middle of writing an OpenJPA mojo to enhance
> the continuum model and take it for a spin with some minimal scoped
> Store operations.
>
> Oh btw, OpenJPA source, it looks from their website, is derived from
> Kodo. I remember Jason mentioned Kodo on this thread and the Enhancer
> seems to accept .jdo files for processing.
>
> Cheers,
> Rahul
Correction:
>From openjpa mailing list - .jdo processing is only available in Kodo.
Rahul
Re: [discuss] iBatis, JPA and Java 5.0
Posted by Rahul Thakur <ra...@gmail.com>.
<snip>
> Having said all of that, my vote (which no one need care about, since
> I haven't had much time to actually contribute code here) is to
> support hibernate with slight abstraction on top of it (modeled on
> JPA's entity manager), so we get the benefits of transparent
> persistence without requiring Java 5.0 - at least until we get to the
> point where we can run in java 5 but execute maven/ant in java 1.4 and
> earlier. Once we are at that point, maybe we can move to JPA (which
> is a small delta), or at least update the abstraction some.
>
> If we were to decide that, hey, screw jdk 1.4, let's just go with
> java5, then I'd just suggest going for JPA as the abstraction. It's
> got problems, but everything does, and it's an increasingly adopted
> standard with some decent implementations.
</snip>
Okies, purely experimental and exploring options more out of curiosity
than anything else, here's more on this thread.....
If I gathered correctly from the #openjpa, all needed to use JPA is to
enhance the model classes with OpenJPA Enhancer. I haven't finished
trying it yet but I am in middle of writing an OpenJPA mojo to enhance
the continuum model and take it for a spin with some minimal scoped
Store operations.
Oh btw, OpenJPA source, it looks from their website, is derived from
Kodo. I remember Jason mentioned Kodo on this thread and the Enhancer
seems to accept .jdo files for processing.
Cheers,
Rahul
Re: [discuss] iBatis, JPA and Java 5.0
Posted by Christian Edward Gruber <cg...@israfil.net>.
Yeah. But to have truly pluggable persistence, then we end up having to
pick LCD features. For isntance, if we want JDO, iBatis, and
JPA/Hibernate as possible approaches, then our design has to pretty much
ignore transparent relationship manifestation that JPA/hibernate/Toplink
provide. True, the Store API could be common, but the assumptions about
the objects returned will be different.
For example, if we were using a JPA/Hibernate approach, then we could
have something in the style of:
ProjectGroup group = store.get(ProjectGroup.class,"myGroup");
for (Project project : group.getProjects().iterator()) {
do stuff;
}
But we would have to do a lot more work to get that for iBatis, for
example, which merely maps the tables/queries to classes, without any
assumptions about relationships. So we couldn't have the same object
model persisted and manifested from the same store impl, and get hte
same behavioural assumptions. If we went with the LCD features, then we
could implement it with iBatis, spring-jdbc, hibernate, jpa or anythign,
but we aren't really dealing with an articulated object model any more,
but an objectified set of tables. Our code would be highly
functional/relational, rather than OO. On the other hand, if we wanted
to go the higher road, we could still provide abstractions that could be
implemented using Hibernate/Toplink/WebObjects-EOF/JPA, since they all
share transparent mapping and manifestation of relationships.
So the choice here is what level of abstraction do we want, and what
functionality do we want to have to implement in our model, and what do
we want to implement via the persistent store mechanism.
We also need to ask ourselves what we gain by over-abstraction. What are
the actual benefits if swapping store implementations. What are the
expected scenarios where this would happen. I honestly don't think
we're going to find many. At most, I think we're going to move between
an O/R mapping framework to a pure OO database. But even that I doubt.
If it's just swapping in/out new RDBMS back-ends, most of the above
transparent persistence mechanisms already support a large variety of such.
Having said all of that, my vote (which no one need care about, since I
haven't had much time to actually contribute code here) is to support
hibernate with slight abstraction on top of it (modeled on JPA's entity
manager), so we get the benefits of transparent persistence without
requiring Java 5.0 - at least until we get to the point where we can run
in java 5 but execute maven/ant in java 1.4 and earlier. Once we are at
that point, maybe we can move to JPA (which is a small delta), or at
least update the abstraction some.
If we were to decide that, hey, screw jdk 1.4, let's just go with java5,
then I'd just suggest going for JPA as the abstraction. It's got
problems, but everything does, and it's an increasingly adopted standard
with some decent implementations.
Christian.
Rahul Thakur wrote:
>
> These buzzwords have been making rounds on IRC and dev list :-), and
> after slight digging around I found a reference to a similar
> discussion here:
> http://www.mail-archive.com/ibatis-user-java@incubator.apache.org/msg01251.html
>
>
> Agreed that the store implementation for Continuum should be
> pluggable, and if we are rethinking JPOX, then IMHO it might be worth
> taking into account JPA and Java 5.0.
>
> What do others think?
>
> Cheers,
> Rahul
>
--
*christian** gruber + process coach and architect*
*Israfil Consulting Services Corporation*
*email** cgruber@israfil.net + bus 905.640.1119 + mob 416.998.6023*