You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@hivemind.apache.org by "Howard M. Lewis Ship" <hl...@comcast.net> on 2004/04/14 20:53:18 UTC
Status update
So ... what are people doing with HiveMind? It's back, it's free and I've been doing some work on
it. I've also been doing some planning for HiveMind on the Wiki.
I'm afraid that all the interruptions caused by the IP problem, and then by the infrastructure
delay, have hurt HiveMind. The community is failing to coalesce at the new home ... it's important
that the other HiveMind users and developers check in and start communicating about their needs.
I have plans for HiveMind in the immediate future:
- Hook into J2EE for declarative security on services via an interceptor
- Create a gateway into Spring, to allow managed Spring beans to appear as HiveMind services
- Interface with JMX: map JMX MBean interfaces to HiveMind services, and add a "performance"
interceptor that records method invocation data into other JMX beans
- Transaction interceptor
That's my immediate list ... what's your?
--
Howard M. Lewis Ship
Independent J2EE / Open-Source Java Consultant
Creator, Tapestry: Java Web Components
Creator, HiveMind
http://howardlewisship.com
---------------------------------------------------------------------
To unsubscribe, e-mail: hivemind-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: hivemind-dev-help@jakarta.apache.org
Re: Status update
Posted by Christian Essl <ch...@yahoo.de>.
I'm biased towards scripting. On one side it is impressive how fast and
what you can do with it on the other hand scripts can turn out to be
monsters quite soon. Hivemind in it's current static way makes things just
easy - most important to read the source, but I guess also for tools.
I agree that compile-time or classloading-time aop frameworks are
orthogonal to HiveMind. But in terms of intercepting proxies frameworks
like dynaop are way ahead of what we have at the moment. Maybe a
decorating service-factory which applies dynaop to a service-impl would
help. Exlplicit interceptors are given as parameters drafted-in
interceptors are specified in a config-point. The factory could be in the
lib module and therefore add no further dependencies to the core. Such an
explicit factory aproach would also prevent some nasty circularity
problems with drafted-in interceptors.
I guess this would also be quite easy to implement when there are
recursive-schemas or a way to specify that elements can be gotten under a
certain schema-element.
On Thu, 15 Apr 2004 00:16:41 -0400, Harish Krishnaswamy
<hk...@comcast.net> wrote:
>
>
> Howard M. Lewis Ship wrote:
>
>> Please elaborate on some of these ideas.
>>
>> I really, really, really don't want to sacrifice HiveDoc. I think
>> applications will be using dozens
>> if not hundreds of configurations, services and contributions and
>> without HiveDoc there will be no
>> way to make sense of it all.
>>
> I would absolutely not want to lose the hivedoc myself. I am simply
> suggesting producing the hivedoc from the script module descriptors.
> With scripting languages, you can document the descriptors in javadoc
> format and access them from the AST. And then its simply a matter
> spitting it out in the form of xml/html and formatting them for display.
> This can be further simplified with Groovy 'cause it has native support
> for markups!
>
>> AOP as in AspectJ is, I believe, orthogonal to HiveMind. What kinds of
>> introductions do you want?
>>
> I would like to see simple mixin type introductions. For eg., with the
> simple event producer/listener pattern I have to pollute my classes with
> event handling code which can be avoided by isolating this code and
> mixing it in as needed. May be this is orthogonal to HiveMind. May be we
> just need a hook to allow dynamic weaving of services by proxy based aop
> frameworks like dynaop.
>
>> Perhaps we need a more sophisticated way of defining the interceptors
>> for a service; a mix of
>> *explicitly* contributed interceptors and some other system where
>> interceptors are "drafted in" via
>> some other form of configuration. Regexp is a good idea ... though
>> that ties us to ORO or JDK 1.4.
>>
> Yes, it introduces a dependency but I think it is justified in this
> case. On a related note, I kinda like jakarta regexp package better than
> oro. regexp is very compact and seems as performant as its couterpart.
>
> -Harish
>
>> --
>> Howard M. Lewis Ship
>> Independent J2EE / Open-Source Java Consultant
>> Creator, Tapestry: Java Web Components Creator, HiveMind
>> http://howardlewisship.com
>>
>>
>>
>>> -----Original Message-----
>>> From: Harish Krishnaswamy [mailto:hkrishnaswamy@comcast.net] Sent:
>>> Wednesday, April 14, 2004 8:00 PM
>>> To: hivemind-dev@jakarta.apache.org
>>> Subject: Re: Status update
>>>
>>>
>>> 1. I want easier and more AOP! I think the interceptor-set idea is
>>> good but we need a way of applying these sets to services in one fell
>>> swoop using regexp or something. And we need atleast some simple
>>> introductions.
>>> 2. Secondly, I want easier and more powerful configuration with
>>> scripting especially with Howard's recent ideas on the wiki. I had
>>> second thoughts on this before due to the line-precise error reporting
>>> and hivedoc that comes with the current xml descriptors, but having
>>> done some research it turns out that the scripting languages provide a
>>> complete AST that simplifies things a whole lot. Really, all the
>>> complexity in HiveMind is simply due to the xml descriptors. I haven't
>>> yet had a chance to take a look at plugging this into Hivemind. I am
>>> guessing it should be simple.
>>>
>>> -Harish
>>>
>>> PS. Why don't the messages here not have the reply-to attribute set?
>>>
>>> Howard M. Lewis Ship wrote:
>>>
>>>
>>>> So ... what are people doing with HiveMind? It's back, it's
>>> free and I've been doing some work on
>>>
>>>> it. I've also been doing some planning for HiveMind on the Wiki.
>>>>
>>>> I'm afraid that all the interruptions caused by the IP
>>> problem, and then by the infrastructure
>>>
>>>> delay, have hurt HiveMind. The community is failing to
>>> coalesce at the new home ... it's important
>>>
>>>> that the other HiveMind users and developers check in and
>>> start communicating about their needs.
>>>
>>>> I have plans for HiveMind in the immediate future:
>>>> - Hook into J2EE for declarative security on services via an
>>> interceptor
>>>
>>>> - Create a gateway into Spring, to allow managed Spring
>>> beans to appear as HiveMind services
>>>
>>>> - Interface with JMX: map JMX MBean interfaces to HiveMind
>>> services, and add a "performance"
>>>
>>>> interceptor that records method invocation data into other JMX beans
>>>> - Transaction interceptor
>>>>
>>>> That's my immediate list ... what's your?
>>>>
>>>> --
>>>> Howard M. Lewis Ship
>>>> Independent J2EE / Open-Source Java Consultant
>>>> Creator, Tapestry: Java Web Components Creator, HiveMind
>>>> http://howardlewisship.com
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: hivemind-dev-unsubscribe@jakarta.apache.org
>>>> For additional commands, e-mail: hivemind-dev-help@jakarta.apache.org
>>>>
>>>>
>>>>
>>>>
>>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: hivemind-dev-unsubscribe@jakarta.apache.org
>>> For additional commands, e-mail: hivemind-dev-help@jakarta.apache.org
>>>
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: hivemind-dev-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail: hivemind-dev-help@jakarta.apache.org
>>
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: hivemind-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: hivemind-dev-help@jakarta.apache.org
--
Christian Essl
---------------------------------------------------------------------
To unsubscribe, e-mail: hivemind-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: hivemind-dev-help@jakarta.apache.org
Re: Status update
Posted by Harish Krishnaswamy <hk...@comcast.net>.
Howard M. Lewis Ship wrote:
>Please elaborate on some of these ideas.
>
>I really, really, really don't want to sacrifice HiveDoc. I think applications will be using dozens
>if not hundreds of configurations, services and contributions and without HiveDoc there will be no
>way to make sense of it all.
>
>
I would absolutely not want to lose the hivedoc myself. I am simply
suggesting producing the hivedoc from the script module descriptors.
With scripting languages, you can document the descriptors in javadoc
format and access them from the AST. And then its simply a matter
spitting it out in the form of xml/html and formatting them for display.
This can be further simplified with Groovy 'cause it has native support
for markups!
>AOP as in AspectJ is, I believe, orthogonal to HiveMind. What kinds of introductions do you want?
>
>
I would like to see simple mixin type introductions. For eg., with the
simple event producer/listener pattern I have to pollute my classes with
event handling code which can be avoided by isolating this code and
mixing it in as needed. May be this is orthogonal to HiveMind. May be we
just need a hook to allow dynamic weaving of services by proxy based aop
frameworks like dynaop.
>Perhaps we need a more sophisticated way of defining the interceptors for a service; a mix of
>*explicitly* contributed interceptors and some other system where interceptors are "drafted in" via
>some other form of configuration. Regexp is a good idea ... though that ties us to ORO or JDK 1.4.
>
>
Yes, it introduces a dependency but I think it is justified in this
case. On a related note, I kinda like jakarta regexp package better than
oro. regexp is very compact and seems as performant as its couterpart.
-Harish
>--
>Howard M. Lewis Ship
>Independent J2EE / Open-Source Java Consultant
>Creator, Tapestry: Java Web Components
>Creator, HiveMind
>http://howardlewisship.com
>
>
>
>
>>-----Original Message-----
>>From: Harish Krishnaswamy [mailto:hkrishnaswamy@comcast.net]
>>Sent: Wednesday, April 14, 2004 8:00 PM
>>To: hivemind-dev@jakarta.apache.org
>>Subject: Re: Status update
>>
>>
>>1. I want easier and more AOP! I think the interceptor-set
>>idea is good
>>but we need a way of applying these sets to services in one
>>fell swoop
>>using regexp or something. And we need atleast some simple
>>introductions.
>>2. Secondly, I want easier and more powerful configuration with
>>scripting especially with Howard's recent ideas on the wiki. I had
>>second thoughts on this before due to the line-precise error
>>reporting
>>and hivedoc that comes with the current xml descriptors, but
>>having done
>>some research it turns out that the scripting languages provide a
>>complete AST that simplifies things a whole lot. Really, all the
>>complexity in HiveMind is simply due to the xml descriptors.
>>I haven't
>>yet had a chance to take a look at plugging this into Hivemind. I am
>>guessing it should be simple.
>>
>>-Harish
>>
>>PS. Why don't the messages here not have the reply-to attribute set?
>>
>>Howard M. Lewis Ship wrote:
>>
>>
>>
>>>So ... what are people doing with HiveMind? It's back, it's
>>>
>>>
>>free and I've been doing some work on
>>
>>
>>>it. I've also been doing some planning for HiveMind on the Wiki.
>>>
>>>I'm afraid that all the interruptions caused by the IP
>>>
>>>
>>problem, and then by the infrastructure
>>
>>
>>>delay, have hurt HiveMind. The community is failing to
>>>
>>>
>>coalesce at the new home ... it's important
>>
>>
>>>that the other HiveMind users and developers check in and
>>>
>>>
>>start communicating about their needs.
>>
>>
>>>I have plans for HiveMind in the immediate future:
>>>- Hook into J2EE for declarative security on services via an
>>>
>>>
>>interceptor
>>
>>
>>>- Create a gateway into Spring, to allow managed Spring
>>>
>>>
>>beans to appear as HiveMind services
>>
>>
>>>- Interface with JMX: map JMX MBean interfaces to HiveMind
>>>
>>>
>>services, and add a "performance"
>>
>>
>>>interceptor that records method invocation data into other JMX beans
>>>- Transaction interceptor
>>>
>>>That's my immediate list ... what's your?
>>>
>>>--
>>>Howard M. Lewis Ship
>>>Independent J2EE / Open-Source Java Consultant
>>>Creator, Tapestry: Java Web Components
>>>Creator, HiveMind
>>>http://howardlewisship.com
>>>
>>>
>>>---------------------------------------------------------------------
>>>To unsubscribe, e-mail: hivemind-dev-unsubscribe@jakarta.apache.org
>>>For additional commands, e-mail: hivemind-dev-help@jakarta.apache.org
>>>
>>>
>>>
>>>
>>>
>>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: hivemind-dev-unsubscribe@jakarta.apache.org
>>For additional commands, e-mail: hivemind-dev-help@jakarta.apache.org
>>
>>
>>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: hivemind-dev-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: hivemind-dev-help@jakarta.apache.org
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: hivemind-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: hivemind-dev-help@jakarta.apache.org
RE: Status update
Posted by "Howard M. Lewis Ship" <hl...@comcast.net>.
Please elaborate on some of these ideas.
I really, really, really don't want to sacrifice HiveDoc. I think applications will be using dozens
if not hundreds of configurations, services and contributions and without HiveDoc there will be no
way to make sense of it all.
AOP as in AspectJ is, I believe, orthogonal to HiveMind. What kinds of introductions do you want?
Perhaps we need a more sophisticated way of defining the interceptors for a service; a mix of
*explicitly* contributed interceptors and some other system where interceptors are "drafted in" via
some other form of configuration. Regexp is a good idea ... though that ties us to ORO or JDK 1.4.
--
Howard M. Lewis Ship
Independent J2EE / Open-Source Java Consultant
Creator, Tapestry: Java Web Components
Creator, HiveMind
http://howardlewisship.com
> -----Original Message-----
> From: Harish Krishnaswamy [mailto:hkrishnaswamy@comcast.net]
> Sent: Wednesday, April 14, 2004 8:00 PM
> To: hivemind-dev@jakarta.apache.org
> Subject: Re: Status update
>
>
> 1. I want easier and more AOP! I think the interceptor-set
> idea is good
> but we need a way of applying these sets to services in one
> fell swoop
> using regexp or something. And we need atleast some simple
> introductions.
> 2. Secondly, I want easier and more powerful configuration with
> scripting especially with Howard's recent ideas on the wiki. I had
> second thoughts on this before due to the line-precise error
> reporting
> and hivedoc that comes with the current xml descriptors, but
> having done
> some research it turns out that the scripting languages provide a
> complete AST that simplifies things a whole lot. Really, all the
> complexity in HiveMind is simply due to the xml descriptors.
> I haven't
> yet had a chance to take a look at plugging this into Hivemind. I am
> guessing it should be simple.
>
> -Harish
>
> PS. Why don't the messages here not have the reply-to attribute set?
>
> Howard M. Lewis Ship wrote:
>
> >So ... what are people doing with HiveMind? It's back, it's
> free and I've been doing some work on
> >it. I've also been doing some planning for HiveMind on the Wiki.
> >
> >I'm afraid that all the interruptions caused by the IP
> problem, and then by the infrastructure
> >delay, have hurt HiveMind. The community is failing to
> coalesce at the new home ... it's important
> >that the other HiveMind users and developers check in and
> start communicating about their needs.
> >
> >I have plans for HiveMind in the immediate future:
> >- Hook into J2EE for declarative security on services via an
> interceptor
> >- Create a gateway into Spring, to allow managed Spring
> beans to appear as HiveMind services
> >- Interface with JMX: map JMX MBean interfaces to HiveMind
> services, and add a "performance"
> >interceptor that records method invocation data into other JMX beans
> >- Transaction interceptor
> >
> >That's my immediate list ... what's your?
> >
> >--
> >Howard M. Lewis Ship
> >Independent J2EE / Open-Source Java Consultant
> >Creator, Tapestry: Java Web Components
> >Creator, HiveMind
> >http://howardlewisship.com
> >
> >
> >---------------------------------------------------------------------
> >To unsubscribe, e-mail: hivemind-dev-unsubscribe@jakarta.apache.org
> >For additional commands, e-mail: hivemind-dev-help@jakarta.apache.org
> >
> >
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: hivemind-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: hivemind-dev-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: hivemind-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: hivemind-dev-help@jakarta.apache.org
Re: Status update
Posted by Harish Krishnaswamy <hk...@comcast.net>.
1. I want easier and more AOP! I think the interceptor-set idea is good
but we need a way of applying these sets to services in one fell swoop
using regexp or something. And we need atleast some simple introductions.
2. Secondly, I want easier and more powerful configuration with
scripting especially with Howard's recent ideas on the wiki. I had
second thoughts on this before due to the line-precise error reporting
and hivedoc that comes with the current xml descriptors, but having done
some research it turns out that the scripting languages provide a
complete AST that simplifies things a whole lot. Really, all the
complexity in HiveMind is simply due to the xml descriptors. I haven't
yet had a chance to take a look at plugging this into Hivemind. I am
guessing it should be simple.
-Harish
PS. Why don't the messages here not have the reply-to attribute set?
Howard M. Lewis Ship wrote:
>So ... what are people doing with HiveMind? It's back, it's free and I've been doing some work on
>it. I've also been doing some planning for HiveMind on the Wiki.
>
>I'm afraid that all the interruptions caused by the IP problem, and then by the infrastructure
>delay, have hurt HiveMind. The community is failing to coalesce at the new home ... it's important
>that the other HiveMind users and developers check in and start communicating about their needs.
>
>I have plans for HiveMind in the immediate future:
>- Hook into J2EE for declarative security on services via an interceptor
>- Create a gateway into Spring, to allow managed Spring beans to appear as HiveMind services
>- Interface with JMX: map JMX MBean interfaces to HiveMind services, and add a "performance"
>interceptor that records method invocation data into other JMX beans
>- Transaction interceptor
>
>That's my immediate list ... what's your?
>
>--
>Howard M. Lewis Ship
>Independent J2EE / Open-Source Java Consultant
>Creator, Tapestry: Java Web Components
>Creator, HiveMind
>http://howardlewisship.com
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: hivemind-dev-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: hivemind-dev-help@jakarta.apache.org
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: hivemind-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: hivemind-dev-help@jakarta.apache.org
Re: Status update
Posted by "Ronald V. Simmons" <Va...@TheSimmonses.Net>.
I'm giving thought to:
- a means of moving Jini proxies into and out of the Registry as a way
of hiding lookup service and javaspace interaction from people writing
masters in a master/worker tuple space pattern.
- writing an interceptor which which puts Jini constraints on objects
which are not proxies.
I'll be interested in the JMX code you mention.
rvs
On Apr 14, 2004, at 2:53 PM, Howard M. Lewis Ship wrote:
> So ... what are people doing with HiveMind? It's back, it's free and
> I've been doing some work on
> it. I've also been doing some planning for HiveMind on the Wiki.
>
> I'm afraid that all the interruptions caused by the IP problem, and
> then by the infrastructure
> delay, have hurt HiveMind. The community is failing to coalesce at the
> new home ... it's important
> that the other HiveMind users and developers check in and start
> communicating about their needs.
>
> I have plans for HiveMind in the immediate future:
> - Hook into J2EE for declarative security on services via an
> interceptor
> - Create a gateway into Spring, to allow managed Spring beans to
> appear as HiveMind services
> - Interface with JMX: map JMX MBean interfaces to HiveMind services,
> and add a "performance"
> interceptor that records method invocation data into other JMX beans
> - Transaction interceptor
>
> That's my immediate list ... what's your?
>
> --
> Howard M. Lewis Ship
> Independent J2EE / Open-Source Java Consultant
> Creator, Tapestry: Java Web Components
> Creator, HiveMind
> http://howardlewisship.com
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: hivemind-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: hivemind-dev-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: hivemind-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: hivemind-dev-help@jakarta.apache.org
Re: Status update
Posted by Achim Huegen <ah...@gmx-topmail.de>.
Ok, here are my interests:
short term:
- multiple service implementations, configuration and selection
- directory files for loading multiple modules from the classpath
(discussed here some weeks ago)
- Simplifying configurations that hold service instances (also discussed
as 'pushing an attribute value onto the rules stack)
long term:
- Manageability and Deployment
In my wildest dream I can add some meta data to my hivemind modules that
enables me to create automatically special deployment information.
One the one hand this information could be used as documentation
that tells the deployer (in terms of j2ee roles) which configuration
settings he must provide before deploying the (web) application (database
servers,
pool and cache sizes, log settings, mailservers etc.). This would be a
subset of the
documentation that can be generated with hivedoc.
One the other hand one could use the information to provide tool support
for the initial configuration and the runtime change of configuration data.
The latter one could be realized with jmx and a web interface (like the
tomcat
administration app). Runtime configuration additionally could be supported
by a
scripting language that changes the settings of a running application via
jmx remote calls.
Imagine a shell script for changing the log level
to 'debug' for all nodes of a web application cluster.
Bye
Achim Huegen
> So ... what are people doing with HiveMind? It's back, it's free and
> I've been doing some work on
> it. I've also been doing some planning for HiveMind on the Wiki.
>
> I'm afraid that all the interruptions caused by the IP problem, and then
> by the infrastructure
> delay, have hurt HiveMind. The community is failing to coalesce at the
> new home ... it's important
> that the other HiveMind users and developers check in and start
> communicating about their needs.
>
> I have plans for HiveMind in the immediate future:
> - Hook into J2EE for declarative security on services via an interceptor
> - Create a gateway into Spring, to allow managed Spring beans to appear
> as HiveMind services
> - Interface with JMX: map JMX MBean interfaces to HiveMind services, and
> add a "performance"
> interceptor that records method invocation data into other JMX beans
> - Transaction interceptor
>
> That's my immediate list ... what's your?
>
> --
> Howard M. Lewis Ship
> Independent J2EE / Open-Source Java Consultant
> Creator, Tapestry: Java Web Components
> Creator, HiveMind
> http://howardlewisship.com
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: hivemind-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: hivemind-dev-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: hivemind-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: hivemind-dev-help@jakarta.apache.org
Re: Status update
Posted by Daniel Feist <df...@technisys.net>.
Hi,
I new here so heres a quick intro:
" I had already got ideas and a vision very similar to that of
hivemind before "bumping into" hivemind a couple of weeks ago. As
hivemind is open source and already (although in alpha still) much more
down the road in terms of implementation than what i had i am moving
over to using hivemind at work and plan to contribute to the further
development of hivemind. "
Initial thoughts, ideas and suggestions based on personal experience are
as follows:
1) I am interested in and have a strong requirement for the micro-kernel
to be able to provide 'ready to use', localized and centrally configured
resources. This avoids properties etc being spread out all over
application but rather defined centrally in module descriptors and
easily changed/managed. Examples of a resource are datasource,
ResourceBundles, Properties, links to JNDI/LDAP trees or any other
custom resource.
The idea is to be able to define in module config files the resource and
attributes used to create these resources along with the ObjectFactory.
The ObjectFactory uses the Registry locale along with parameters
provided to instantiate and configure the resource. An objectfactory
can be implemented for each resource type, backing-store combination.
Module descriptor element would be somewhat like this:
<resource id="txfConfig" type="org.dom4j.Document"
factory="net.technisys.cyberbank.base.resource.impl.DOM4JDocumentFactory">
<parameters>
<attribute name="url">TxFrameworkConfiguration.xml</attribute>
<attribute name="validate">true</attribute>
</parameters>
</resource>
It would also be ideal to be able to pre-configure services with these
resources using the push "<set-resource..>" style right after service is
created.
I initially had "resources" as something top level the same as
"services" as from my point of view in what I am doing it they are just
as important as services. Everybody has different necessities and
viewpoints, it would be interesting to hear what others think and
whether my viewpoint is something lots of people agree with or if it is
quite a specific requirement.
I am looking into how i can accomplish this functionality while using
hivemind as it is. I am experimenting to see whether each resource can
in fact be a contribution to a "resources" configuration point and this
way along with an optional Resource service the functionality can be
achieved. The main disadvantage with this is that services would not be
able to push resources onto services after creation because a Resource
is something added onto the framework and not a core concept of the
framework like i had planned. Any suggestions are very welcome!!
2) I too am interested in JMX functionality too and have been
experimenting with mx4j. I was thinking of making this functionality
optional. Also was looking into exporting resources (described above)
via JMX for configuration/management etc.
3) I require the registry to auto-start when needed (lazy-load) rather
than having to explicitly bootstrap it. I am currently achieving this
by wrapping access to the registry with a singleton class solving this
particular need. I dont know if this need is something unique to me or
something fairly commonly needed.
4) I use a JNDI SPI facade for obtaining services/resources to give more
separation between code and the framework, works fine just have to pass
the interface of the service as "Object.class" as lookups via JNDI have
no way to specify the interface.
" return
Platform.getRegistry().getService(name.get(0).toString(),Object.class);"
Where "Platform" is my singleton wrapper and "name" is the JNDI name
being looked up.
5) Before using Hivemind i was using services that did not implement any
framework interfaces at all but rather through the use documented
optional methods such as start() and stop() reflection was used to
invoke these methods if available. The advantage of this was that the
service was always a POJO and could always be used in other frameworks
without exception, i see that it has disadvantages though. The
important think is that no framework interfaces are compulsory.
Daniel Feist
Howard M. Lewis Ship wrote:
>So ... what are people doing with HiveMind? It's back, it's free and I've been doing some work on
>it. I've also been doing some planning for HiveMind on the Wiki.
>
>I'm afraid that all the interruptions caused by the IP problem, and then by the infrastructure
>delay, have hurt HiveMind. The community is failing to coalesce at the new home ... it's important
>that the other HiveMind users and developers check in and start communicating about their needs.
>
>I have plans for HiveMind in the immediate future:
>- Hook into J2EE for declarative security on services via an interceptor
>- Create a gateway into Spring, to allow managed Spring beans to appear as HiveMind services
>- Interface with JMX: map JMX MBean interfaces to HiveMind services, and add a "performance"
>interceptor that records method invocation data into other JMX beans
>- Transaction interceptor
>
>That's my immediate list ... what's your?
>
>--
>Howard M. Lewis Ship
>Independent J2EE / Open-Source Java Consultant
>Creator, Tapestry: Java Web Components
>Creator, HiveMind
>http://howardlewisship.com
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: hivemind-dev-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: hivemind-dev-help@jakarta.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: hivemind-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: hivemind-dev-help@jakarta.apache.org
RE: Status update
Posted by David Solis <ds...@legosoft.com.mx>.
I like to see list is awakening.
What is the benefit to have spring beans wrapped by a Hivemind service?
Do you mean Spring integration? What about life cycles of Spring beans?
Do you mean full emulation of Spring container?
I'd like to see:
+ More AOP features.
+ Hibernate / ibatis integration
+ Web services integration
+ Groovy support
Regards
D.
> -----Original Message-----
> From: Howard M. Lewis Ship [mailto:hlship@comcast.net]
> Sent: Wednesday, April 14, 2004 12:53 PM
> To: hivemind-dev@jakarta.apache.org
> Subject: Status update
>
> So ... what are people doing with HiveMind? It's back, it's free and
I've
> been doing some work on
> it. I've also been doing some planning for HiveMind on the Wiki.
>
> I'm afraid that all the interruptions caused by the IP problem, and
then
> by the infrastructure
> delay, have hurt HiveMind. The community is failing to coalesce at the
new
> home ... it's important
> that the other HiveMind users and developers check in and start
> communicating about their needs.
>
> I have plans for HiveMind in the immediate future:
> - Hook into J2EE for declarative security on services via an
interceptor
> - Create a gateway into Spring, to allow managed Spring beans to
appear as
> HiveMind services
> - Interface with JMX: map JMX MBean interfaces to HiveMind services,
and
> add a "performance"
> interceptor that records method invocation data into other JMX beans
> - Transaction interceptor
>
> That's my immediate list ... what's your?
>
> --
> Howard M. Lewis Ship
> Independent J2EE / Open-Source Java Consultant
> Creator, Tapestry: Java Web Components
> Creator, HiveMind
> http://howardlewisship.com
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: hivemind-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: hivemind-dev-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: hivemind-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: hivemind-dev-help@jakarta.apache.org