RE: Time plan for Hivemind release 1.0

["Howard M. Lewis Ship" <hl...@comcast.net>]

I'd rather respond on the HiveMind user mailing list.
 
There is a vote currently to release 1.0 beta-1.
 
The framework is very mature in my opinion; it wasn't slapped together like some open-source
projects. It has some hardcore TDD (test driven development) going on in there to give me confidence
that it all works.  
 
I've had no problems with Javassist with either HiveMind or Tapestry. We're using just a fraction
(perhaps a stable fraction) of what Javassist can do ... creating new classes at runtime, not
modifying classes that are already in existence.  Again, it works because the HiveMind test suite
contains well over 400 tests and most of those create dozens of new classes using Javassist.
 
 
--
Howard M. Lewis Ship
Independent J2EE / Open-Source Java Consultant
Creator, Jakarta Tapestry
Creator, Jakarta HiveMind
http://howardlewisship.com <http://howardlewisship.com/> 

-----Original Message-----
From: Matthias.Burbach@web.de [mailto:Matthias.Burbach@web.de] 
Sent: Thursday, July 01, 2004 2:08 PM
To: howard@howardlewisship.com
Subject: Time plan for Hivemind release 1.0


Hi Howard,
 
do you have kind of a plan when to release Hivemind 1.0 beta and 1.0?
 
I read the Hivemind documentation quite thoroughly and tried it out practically. I think it is
really a helpful framework for our J2EE software.
However I'm a bit concerned about its immaturity, at least judging by its early pre-release state.
 
The other thing that worries me a bit is this javassist thing. I didn't have the time to look more
closely into it yet. But a colleague of mine warned that it is quite immature either and that it
plays around with byte code in a way that is a bit unusual.
 
Can you make a clarifying statement on that?
 
Thanks,
Matthias Burbach
 

RE: Spring-like transaction features?

[Drew McAuliffe <dr...@lowerunit.com>]

I'd be extremely interested in it. One of the things that interests me
especially about a HiveMind approach to Hibernate configuration is the fact
that separate modules can each have their own set of hibernate mappings, and
these can be aggregated at the highest level by your application. I've found
it difficult to combine hibernate mappings from separate jars into one
session factory configuration without resorting to appserver-specific
contortions. If I'm not mistaken, this HiveMind approach of yours allows
exactly what I'm looking for.
 
Please let me know if you have more info or need my address.
 
Thanks,
 
Drew

  _____  

From: Pablo Lalloni [mailto:plalloni@afip.gov.ar] 
Sent: Thursday, July 01, 2004 12:50 PM
To: hivemind-user@jakarta.apache.org
Subject: Re: Spring-like transaction features?


We've written full support for Hibernate and JDBC as HiveMind services, and
I'm currently working on a TransactionInterceptor factory service to use
declarative transaction demarcation a-la EJB. 

To support Hibernate we made an HibernateSessionService who's able to
receive contributions of SessionFactory's configurations and also mappings
(hbm's) for persistent classes. On startup this service builds up all the
SessionFactory's as determined by contributions associating to each the
corresponding persistent classes. After this any dependant component can ask
for a Session corresponding to a given class or query name. Sessions are
associated to threads through ThreadStorageService so the same Session can
be returned for the same thread, they're cleaned up con thread cleanup
events.

Also did something alike for supporting a FastLaneReader through JDBC where
we take a similar approach for Connection management.

In front of this services we have a FinderService and a CRUDService which
can be used for what their names mean despite whether the data is accessed
through JDBC, Hibernate or any future data access backend implemented as a
HiveMind service.

Transactions are handled with the above mentioned interceptor supporting EJB
CMT policies.

If anyone's interested in any of this, I guess I can send out more details
and/or code (if my boss agree with it, of which I'm pretty confident).

Cheers,
PiL

El jue, 01-07-2004 a las 16:29, Drew McAuliffe escribió: 

Are there any plans to introduce features into HiveMind like Spring's
abstraction of transactionality of Hibernate or other data access? I like
the way that Spring can make the details of data access and transactionality
configurable but I prefer the way HiveMind deals with the overall service
abstraction, pluggability, interception, etc. Is there any plan to introduce
these higher-order features into HiveMind, or is it still concentrating
mainly on the IoC/container/pluggability side of things? Or does anyone out
there have a HiveMind module that does a similar thing? I'm investigating
moving a combination of homegrown app layers to either one of these two big
guys, and I don't like the idea of mixing them because of the functionality
overlap.
 
Thanks,
Drew 

Re: Spring-like transaction features?

[Pablo Lalloni <pl...@afip.gov.ar>]

We've written full support for Hibernate and JDBC as HiveMind services,
and I'm currently working on a TransactionInterceptor factory service to
use declarative transaction demarcation a-la EJB. 

To support Hibernate we made an HibernateSessionService who's able to
receive contributions of SessionFactory's configurations and also
mappings (hbm's) for persistent classes. On startup this service builds
up all the SessionFactory's as determined by contributions associating
to each the corresponding persistent classes. After this any dependant
component can ask for a Session corresponding to a given class or query
name. Sessions are associated to threads through ThreadStorageService so
the same Session can be returned for the same thread, they're cleaned up
con thread cleanup events.

Also did something alike for supporting a FastLaneReader through JDBC
where we take a similar approach for Connection management.

In front of this services we have a FinderService and a CRUDService
which can be used for what their names mean despite whether the data is
accessed through JDBC, Hibernate or any future data access backend
implemented as a HiveMind service.

Transactions are handled with the above mentioned interceptor supporting
EJB CMT policies.

If anyone's interested in any of this, I guess I can send out more
details and/or code (if my boss agree with it, of which I'm pretty
confident).

Cheers,
PiL

El jue, 01-07-2004 a las 16:29, Drew McAuliffe escribió:

> Are there any plans to introduce features into HiveMind like Spring's
> abstraction of transactionality of Hibernate or other data access? I
> like the way that Spring can make the details of data access and
> transactionality configurable but I prefer the way HiveMind deals with
> the overall service abstraction, pluggability, interception, etc. Is
> there any plan to introduce these higher-order features into HiveMind,
> or is it still concentrating mainly on the IoC/container/pluggability
> side of things? Or does anyone out there have a HiveMind module that
> does a similar thing? I'm investigating moving a combination of
> homegrown app layers to either one of these two big guys, and I don't
> like the idea of mixing them because of the functionality overlap.
>  
> Thanks,
> Drew

Re: Spring-like transaction features?

[Howard Lewis Ship <hl...@gmail.com>]

Rod (Johnson) has repeatedly suggest that we leverage their
implementation of transactions. I've been short on time pursuing that.
I think I would whip together a simple transaction interceptor in a
few hours, and probalby not much longer to try and grok the Spring
Transaction support and turn that into an interceptor.

The overlap doesn't bother me too much and it's certainly a great way
to leapfrog functionality in HiveMind, by leveraging what Spring
already offers. Rod is interested in the other way, since Spring
doesn't have anything sufficiently like configurations. You don't have
to zoom in very far to see that HiveMind and Spring are significantly
different from each other and, I think , complementary.


----- Original Message -----
From: Drew McAuliffe <dr...@lowerunit.com>
Date: Thu, 1 Jul 2004 12:29:55 -0700
Subject: Spring-like transaction features?
To: hivemind-user@jakarta.apache.org


Are there any plans to introduce features into HiveMind like Spring's
abstraction of transactionality of Hibernate or other data access? I
like the way that Spring can make the details of data access and
transactionality configurable but I prefer the way HiveMind deals with
the overall service abstraction, pluggability, interception, etc. Is
there any plan to introduce these higher-order features into HiveMind,
or is it still concentrating mainly on the IoC/container/pluggability
side of things? Or does anyone out there have a HiveMind module that
does a similar thing? I'm investigating moving a combination of
homegrown app layers to either one of these two big guys, and I don't
like the idea of mixing them because of the functionality overlap.
 
Thanks,

Drew


-- 
Howard M. Lewis Ship
Independent J2EE / Open-Source Java Consultant
Creator, Jakarta Tapestry
Creator, Jakarta HiveMind
http://howardlewisship.com

---------------------------------------------------------------------
To unsubscribe, e-mail: hivemind-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: hivemind-user-help@jakarta.apache.org

Spring-like transaction features?

[Drew McAuliffe <dr...@lowerunit.com>]

Are there any plans to introduce features into HiveMind like Spring's
abstraction of transactionality of Hibernate or other data access? I like
the way that Spring can make the details of data access and transactionality
configurable but I prefer the way HiveMind deals with the overall service
abstraction, pluggability, interception, etc. Is there any plan to introduce
these higher-order features into HiveMind, or is it still concentrating
mainly on the IoC/container/pluggability side of things? Or does anyone out
there have a HiveMind module that does a similar thing? I'm investigating
moving a combination of homegrown app layers to either one of these two big
guys, and I don't like the idea of mixing them because of the functionality
overlap.
 
Thanks,

Drew