hivemind-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Luke Blanshard <l...@blanshard.us>
Subject Re: Validation of the configuration (the sum of all loaded hivemodules)
Date Fri, 23 Apr 2004 16:46:29 GMT
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


Mime
View raw message