RE: [SPAM] - RE: Configuration and management of Configuration - Email has different SMTP TO: and MIME TO: fields in the email addresses

[Steve Gibson <St...@cowww.com>]

Thats the problem with thinking out loud...

SymbolSource....
I guess what I should say to clarify is that the properties file is a
properties file because it was easy to implement...
That said, it is big and is now emulating xml/sdl/whatever format in the
usual properties file way:

service1.property1=
service1.property2=
service1.property3=
service2.property1=
service2.wrappedObject.property1=
service2.wrappedObject.complexProperty.property1=

On the other hand, I don't know if converting it to xml/sdl will help:

hibernate.dialect = net.sf.hibernate.dialect.HSQLDialect
hibernate.connection.driver_class = org.hsqldb.jdbcDriver
hibernate.connection.url = jdbc:hsqldb:hsql://localhost:9002
hibernate.use_outer_join = true
hibernate.connection.username = admin
hibernate.connection.password = 
hibernate.connection.pool_size = 20
hibernate.statement_cache.size = 10
hibernate.cache.provider_class = net.sf.hibernate.cache.OSCacheProvider

Also, a SymbolSource won't aggregate things to get them into classes
without duplicating the effort -
for this example:
<hibernate dialect="${hibernate.dialect}"
user_outer_join="${hibernate.use_outer_join}">
    <connection driver_class="${hibernate.connection.driver_class}"
url="${hibernate.connection.url}" pool_size=...>
        <credentials username="${hibernate.connection.username}"
password="${hibernate.connection.password}"/>
    </connection>
</hibernate>

Then again, this handles configuration "inheritance" for me...

sub-module - ahhhh...thats what was missing!

Thanks for your patience, Howard.

Steve Gibson

-----Original Message-----
From: Howard M. Lewis Ship [mailto:hlship@comcast.net] 
Sent: Thursday, June 10, 2004 1:27 PM
To: hivemind-dev@jakarta.apache.org
Subject: [SPAM] - RE: Configuration and management of Configuration -
Email has different SMTP TO: and MIME TO: fields in the email addresses


Didn't quite follow all of that. I would say that, yes, wrap your
.properties file as a SymbolSource.

A module can reference a <sub-module>. This allows a single
META-INF/hivemodule.sdl  to "bring in" related modules, which should
work well for you.


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

-----Original Message-----
From: Steve Gibson [mailto:Steve.Gibson@cowww.com] 
Sent: Thursday, June 10, 2004 11:54 AM
To: hivemind-dev@jakarta.apache.org
Subject: Configuration and management of Configuration


This is a borderline HiveMind user/development question...

Our embryonic application uses one big Property file to manage the
configuration of services.
The lazy programmer in me says leave this as a big Property file, wrap a
configuration class around it for passing into services and write a
configuration service that can manage changes to it (we need to be able
to reconfigure parts of this file, preferably putting changes from
default into a second file which is loaded over the top at startup).

Having one Property file makes the management easy, but means services
must search for their properties.
If I make a bunch of configuration points, though, the current api does
not allow me to call <module>.getConfigurationIds() or the like.
Thinking out loud, if I had that, I guess I could have services register
for change events on configuration points and even dynamically update
configurations (from the configuration service) without having to do
direct calls to the service(s) that use that configuration point.

Sounds a little scary to me, especially as some configuration items are
more like constructor parameters.

The other issue I currently have with configuration is this - I develop
and test without building a jar. That means I can only have the one
module descriptor. So all my configuration is mixed in with service
point definitions, etc. I really want to be able to put contributions
into separate configuration files. Maybe I need to look at the
BuilderFactory a little more closely...

Steve Gibson
Software Engineer
COWWW Software

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