hivemind-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Howard M. Lewis Ship" <hlshipli...@comcast.net>
Subject RE: Validation of the configuration (the sum of all loaded hivemodules)
Date Mon, 26 Apr 2004 12:54:53 GMT
I've been thinking about these things a bit during my spare time (I've been consulting in North
Carolina, and speaking at NoFluffJustStuff outside Boston).

Some of my ideas are going up on the proposals page.

I think we definately need to split the Registry interface in two: a simplified version used
by
client code, and an extended version (RegsitryInternal, perhaps?) that is visible to some
of the
other machinery inside HiveMind, and would allow for things like pre-loading services and
configuration points, and doing other validations.

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


> -----Original Message-----
> From: Stefan.Liebig@compeople.de [mailto:Stefan.Liebig@compeople.de] 
> Sent: Monday, April 26, 2004 7:42 AM
> To: hivemind-user@jakarta.apache.org
> Subject: Re: Validation of the configuration (the sum of all 
> loaded hivemodules)
> 
> 
> 
> How about widening/extending some interfaces of the API
> in such a way that it would be possible to perform the
> validating ourselfes?
> E.g. extend Registry with a >List getModules()< returning
> a List of Modules and so forth.
> Returned objects should be read-only, so that the internals
> can not be corrupted.
> 
> -----Luke Blanshard <luke@blanshard.us> wrote: -----
> 
> To: hivemind-user@jakarta.apache.org
> From: Luke Blanshard <luke@blanshard.us>
> Date: 23.04.2004 18:46
> Subject: Re: Validation of the configuration (the sum of all loaded
> hivemodules)
> 
> I was thinking client side, not server side. On the server, I
> would do it as a special diagnostic service, accessible via
> servlet or ejb. I might actually do it that way on the client
> too, though it would be nice to have a separate program.
> 
> ---- Original message ----
> >Date: Fri, 23 Apr 2004 15:55:22 +0200
> >From: "Johan Lindquist" <johan@kawoo.co.uk>
> >Subject: Re: Validation of the configuration (the sum of all
> loaded hivemodules)
> >To: hivemind-user@jakarta.apache.org
> >
> >Curious - how would you specify the class-path in such a case?
> If you
> >deploy the registry as part of an ear, a lot of magic is done by
> the
> >container ... Or would the tool look at the ear (in this example)
> and
> >process it accordingly to construct the correct path?
> >
> >Johan
> >
> >On Fri, 23 Apr 2004 08:42:31 -0500, Luke Blanshard
> <luke@blanshard.us>
> >wrote:
> >
> >> I'm with Stefan here. For complex environments, it would be a
> >> real help to be able to run a little program that did a sanity
> >> check on the classpath and configuration. HiveMind has all the
> >> information needed to do a simple validation of all services in a
> >> registry, by forcing instantiation of all of them.
> >>
> >> Luke
> >>
> >> ---- Original message ----
> >>> Date: Fri, 23 Apr 2004 14:38:32 +0200
> >>> From: Stefan.Liebig@compeople.de
> >>> Subject: RE: Validation of the configuration (the sum of all
> >> loaded hivemodules)
> >>> To: hivemind-user@jakarta.apache.org
> >>>
> >>>
> >>> Hmm, depends on the definition of unit test. I do not think that
> >>> this is what unit tests are for. I would call such tests
> integration
> >>> tests, which put all pieces together and test if they behave as
> >>> excpected. Although you might use JUnit for doing that.
> >>> With unit test I would like to test my "business" components, not
> >>> neccessarily the components construction done by HiveMind.
> >>>
> >>> So, in principle you are right. With a good test coverage this
> would
> >>> not be necessary. But why not supporting it with a (optional)
> >> validation?
> >>>
> >>> -----"Howard M. Lewis Ship" <hlship@comcast.net> wrote: -----
> >>>
> >>> To: <hivemind-user@jakarta.apache.org>
> >>> From: "Howard M. Lewis Ship" <hlship@comcast.net>
> >>> Date: 23.04.2004 13:26
> >>> Subject: RE: Validation of the configuration (the sum of all
> loaded
> >>> hivemodules)
> >>>
> >>> At the risk of sounding flip ... isn't this what unit tests
> are for?
> >>> There's a finite limit to what
> >>> HiveMind can, in fact, validate without actually executing the
> >> application.
> >>> HiveMind should make
> >>> your testing easier (or, in fact, possible) ... not replace the
> >> need for
> >>> testing.
> >>>
> >>> --
> >>> Howard M. Lewis Ship
> >>> Independent J2EE / Open-Source Java Consultant
> >>> Creator, Tapestry: Java Web Components
> >>> Creator, HiveMind
> >>> http://howardlewisship.com
> >>>
> >>>
> >>>> -----Original Message-----
> >>>> From: Stefan.Liebig@compeople.de
> >> [mailto:Stefan.Liebig@compeople.de]
> >>>> Sent: Thursday, April 22, 2004 9:49 AM
> >>>> To: hivemind-user@jakarta.apache.org
> >>>> Subject: Validation of the configuration (the sum of all
> >>>> loaded hivemodules)
> >>>>
> >>>>
> >>>>
> >>>> Hi,
> >>>>
> >>>> we are using HiveMind as our component framework. Our
> >> application is a
> >>>> almost typical client/server application.
> >>>> As our application grows and grows we would like to have some
> >>>> support for
> >>>> validating the configuration. I would like to ask the
> >>>> registry to validate:
> >>>> - point all implementations to existing service points
> >>>> - same for contributions/configuration points
> >>>> - same for schema/schema-id
> >>>> - same for .. (are there any others?)
> >>>> - are all referenced classes available (not neccessarily load
> >>>> them), so far
> >>>> HiveMind is aware of knowing that some attribute relates to a
> >> class.
> >>>>
> >>>> Sure I could parse myself all the hivemodules but ..
> >>>> How about contributing?
> >>>>
> >>>> Regards,
> >>>> Stefan
> >>>>
> >>>>
> >>>>
> >>>>
> >>
> ---------------------------------------------------------------------
> >>>> To unsubscribe, e-mail:
> >> hivemind-user-unsubscribe@jakarta.apache.org
> >>>> For additional commands, e-mail:
> >> hivemind-user-help@jakarta.apache.org
> >>>>
> >>>
> >>>
> >>>
> ---------------------------------------------------------------------
> >>> To unsubscribe, e-mail:
> hivemind-user-unsubscribe@jakarta.apache.org
> >>> For additional commands, e-mail:
> >> hivemind-user-help@jakarta.apache.org
> >>>
> >>>
> >>>
> >>>
> ---------------------------------------------------------------------
> >>> To unsubscribe, e-mail:
> hivemind-user-unsubscribe@jakarta.apache.org
> >>> For additional commands, e-mail:
> >> hivemind-user-help@jakarta.apache.org
> >>>
> >>
> >>
> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail:
> hivemind-user-unsubscribe@jakarta.apache.org
> >> For additional commands, e-mail:
> hivemind-user-help@jakarta.apache.org
> >>
> >>
> >
> >
> >
> >--
> >you too?
> >
> >---------------------------------------------------------------------
> >To unsubscribe, e-mail: hivemind-user-unsubscribe@jakarta.apache.org
> >For additional commands, e-mail:
> hivemind-user-help@jakarta.apache.org
> >
> 
> ---------------------------------------------------------------------
>  To unsubscribe, e-mail: hivemind-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: hivemind-user-help@jakarta.apache.org
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: hivemind-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: hivemind-user-help@jakarta.apache.org
> 


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


Mime
View raw message