tek1 wrote:
>
> At 13:22 03/05/30 -0500, you wrote:
> > >
> > > So would each JDO (and its associated cache) instance have a uniquely
> > > identifiable name for its "Group" in JavaGroups, perhaps IP address +
> > > counter (or other id/number that could uniquely identify several JDO
> > > instances on the same machine)?
> >
> >I'm not even sure the individual names matter in this case. You'd just
> >broadcast the message to invalidate a given object. Any Castor JDO
> >instance listening in on a particular group-channel would then honor the
> >request and send an acknowledgement.
>
> Thanks for explaining how JavaGroups works. Just registering the JDO to
> JavaGroup sounds fairly straight forward. Just trying to get a picture of
> how clustering can be implemented in Castor... So each JDO would fire off
> a "CacheEvent" (types could be OBJECT_ADDED, OBJECT_MODIFIED_,
> OBJECT_REMOVED) to JavaGroups, and each JDO's "CacheListener" would be
> registered with JavaGroups and listen for "CacheEvent"s, and update their
> local cache appropriately, depending on the CacheEvent?
Yep. The only issue would be synchronizing the CacheEvents so that if
two Castor instances have modified versions of the "same" object and
fire off CacheEvents simultaneously, then you would need a way of
choosing which one to accept and which one to throw out.
>
> >Yes. Once we hit Castor 0.9.6 we'll be on the fast track to 1.0. My goal
> >is for 0.9.7->1.0 to be only bug fixes, additional test cases, and
> >documentation. No feature develepmont. 0.9.6 will be the last release
> >with new features, which is why we're moving slowly to that point
> >because there are still features we're trying to finish up.
> >
> >Actually we're ready to do a new release, so hopefully I'll find the
> >time this weekend to do it.
>
> So is the next release (possibly this weekend) 0.9.6, skipping 0.9.5?
Now we won't skip 0.9.5, as there are still a number of features, for
example the JAXB compatibility layer for Castor XML.
> so, then could bug fixes for 0.9.6 be wrapped up and released as 1.0? Bug
> fixes could always be released as 1.0.1, 1.0.2, etc. Again, 1.0 milestone
> is a big psychological mark, especially since the Castor releases are not
> as frequent (i.e. monthly, roughly the case with JBoss).
Recently we've been trying to do a Castor release bi-monthy (every two
months) but sometimes this gets pushed out if the core developers
haven't had much spare time to finish the tasks they wanted to get done
for a particular release.
It's definately psychological though. I know that "1.0" means a lot in
terms of management. To me though, 1.0 means we've finished all that we
wanted to for the 1.0 release, we've documented as much as we're going
to document and we've done as much testing as we feel necessary so that
we've created what we feel is a stable, mature product.
yes...we won't get all the bugs, so we'll have to do 1.0.1 and 1.0.2
releases, but I wouldn't want to do implement a bunch of new features
right before 1.0 and then say we can always do a 1.0.1 release...because
1.0 should have gone through at least a few releases of only bug fixes
so that users know that we've not sacrificed the stability of the
product.
If we come up with some new features after the eventual 0.9.6 release,
those features will go into a 1.1 branch.
> I noticed in a
> previous article that someone mentioned Castor never having released 1.0
> despite it being around for a while.
Yeah I saw that too...but the number of Castor users continues to grow,
not decline, so while there are a number of areas that we could improve
upon, such as getting to 1.0 quickly, we're still building a free
product that a large number of people want to use.
> Releasing 1.0 will definitely give
> Castor a better image, that it is capable of production use. Are there any
> major outstanding bugs preventing a sooner 1.0 release?
You can take a peak in Bugzilla.
What we really need to do is set the full roadmap to 1.0. The problem is
that people's time for contributing to the project changes on a weekly
(if not daily) basis. So setting hard deadlines is difficult. And if you
release a deadline, people will expect you to stick to it, even on an
open source project. But I think a roadmap in terms of features and
milestones would be nice so that people can see the progress to 1.0
being made without needing actual hard dates.
>
> I believe that a lot of people had a problem with ObjectModifiedException
> because no "count-limited" attribute value was specified for the Class
> <cache-type> element and the default was broken? I also had a minor
> problem with a read-only Class, but I have to dive into the details of that
> again...
I'll leave that one up to Bruce, since he's the JDO lead.
>
> Other than that, are there are real Castor killers?
>
I'm not sure why anyone would want to kill Castor, hopefully improve it
instead of kill it.
>
> Overall, Castor is a great product and is greatly appreciated!
>
:-)
--Keith
-----------------------------------------------------------
If you wish to unsubscribe from this mailing, send mail to
[EMAIL PROTECTED] with a subject of:
unsubscribe castor-dev
