You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avalon.apache.org by Tom Bradford <br...@dbxmlgroup.com> on 2001/09/01 22:19:55 UTC
Porting dbXML to Avalon
The next version of dbXML (1.5) will be ported from the Juggernaut
server framework to Avalon. From a very high level, it looks like it
should be fairly easy, but I was wondering if anybody has run into any
gotchas porting between server frameworks.
My one concern is the configuration system. Avalon's configuration
interfaces seem to be read-only, but our server needs to maintain its
own configuration on disk. Are there additional interfaces in Avalon
for managing 'writable' configurations?
Also, is Tomcat 4 running on top of Avalon? I had heard rumblings to
this degree, but can't confirm it from looking at the distro.
--
Tom Bradford The dbXML Group, L.L.C. http://www.dbxmlgroup.com/
Desktop, Laptop, Settop, Palmtop. Can your XML database do that?
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
Re: Porting dbXML to Avalon
Posted by Peter Donald <do...@apache.org>.
On Sun, 2 Sep 2001 06:19, Tom Bradford wrote:
> The next version of dbXML (1.5) will be ported from the Juggernaut
> server framework to Avalon. From a very high level, it looks like it
> should be fairly easy, but I was wondering if anybody has run into any
> gotchas porting between server frameworks.
A month or two back I went and ported all my remaining apps to Avalon or
Avalon/Phoenix and here were the issues I faced.
1. I used to access a lot of objects via singletons like
ChannelManager.getChannelManager() and this was painful to change.
2. I used to have my objects access their own dependents rather than letting
them get passed to it ... also I used to intermix "startup" code all through
my components and this took a while to reorganize into separate stages (ie
logger vs context vs config vs init)
3. I used to have components depend on each other (ie A depends on B which
depends on A) with specific startup ordering issues. I had to rework this by
creating extra interfaces. ie A could depend on B, but A could pass itself to
B via an interface. (See ConnectionManager in Cornerstone for a similar
arrangement). This was a minor but annoying change.
4. I manually implemented a Telnet management component for old code but this
had no equivelent in Avalon/Phoenix. The "proper" way to do this is via JMX
(see below) but in the meantime I left this in but it is relatively unsafe.
5. Modification of Configuration, Logging and Deployments not doable at
runtime (see below) but eventually this will be fixed.
6. Import names are soooo damn long ;)
7. In some cases the number of interfaces to implement is excessive. For
instance one object implemented Loggable, Contextualizable, Configurable,
Initialzable, Startable, Disposable. I fixed this by creating Animatable
interface that extends Initialzable, Startable, Disposable.
8. No way to depend on multiple components with same interface. ie I would
like Block A to depend on 1+ interfaces that implement Service Foo. To work
around this I had to add an extra "Director" block that linked together
blocks using mechanism similar to described in (3). This is a similar pattern
as seen in JAMES.
Many of those faults were due to me not writing the software the "right way"
the first time round. The others are in progress of being "fixed" in
Avalon/Phoenix at the moment.
The only unaddressed issue for my integration is (8) but I have yet to come
up with a good way of solving it. We have discussed it extensively in the
past but with no resolutions.
One other issue that you may come across though I haven't is the innability
for Blocks to be "optionally" loaded (or not). We may address this in the
future.
> My one concern is the configuration system. Avalon's configuration
> interfaces seem to be read-only, but our server needs to maintain its
> own configuration on disk. Are there additional interfaces in Avalon
> for managing 'writable' configurations?
At this current stage there are no writeable configurations. Changing that to
allow modification of Configuration would be relatively simple 10 line
addition to ConfigurationRepository.
The problem is that this is not accessible from normal Server Applications
because it exists inside Kernel ClassLoader. The proper way to "fix" this
problem is to make some of the interfaces in the kernel
(ConfigurationRepository, Application, Deployer, Embeddor) accessible from
outside kernel by exporting it via some managment interface (preferrably JMX).
This is a big TODO but I don't really understand JMX enough to do it yet ...
and I don't need it in any of my apps. It will be done sometime ... if it
ends up holding you up drop us a note and I will try to have a go at it ;)
In the meantime you can continue to use your own Configuration interface to
minimize changes.
> Also, is Tomcat 4 running on top of Avalon? I had heard rumblings to
> this degree, but can't confirm it from looking at the distro.
Nope. Maybe the next Tomcat but not the current one.
--
Cheers,
Pete
--------------------------------
My opinions may have changed,
but not the fact that I am right
--------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
Re: ModifiableConfiguration [ was "Porting dbXML to Avalon" ]
Posted by Peter Donald <do...@apache.org>.
On Sun, 2 Sep 2001 20:49, Paul Hammant wrote:
> Peter Donald wrote:
> >I was thinking about something as simple as current setup.
> >
> >ie
> >
> >vois storeConfiguration( String application,
> > String block,
> > Configuration config );
>
> Hmm, that forced the comp writer to have some way of constructing an
> tree of Configuration objects themselves. I'd guess getting it right is
> a high art and buckets of code. Though there are good points raised
> about reliance on Xpath and it's implicit underlying XML document, I
> think it's a simple think for component writers to use.
Well we could always add a helper class. Something like
MutableConfiguration config = ConfigurationHelper.clone( readOnlyConfig );
ConfigurationHelper.set( "client-connections/connection[@name='ssl']/@auth",
"true" );
repo.storeConfiguration( myApp, "connections", config );
This would be simplified if we used something like the recent XPath APIs in
commons or on sourceforge. Some of them work on multiple doc types (ie
DOM/JDOM/DOM4J/JavaBeans). Look for jxpath in commons I think.
Re: dom4j license issues.
Ask the author (who is also a member of commons-dev IIRC) and I am sure they
would be willing to help fix whatever needs doing.
--
Cheers,
Pete
*-----------------------------------------------------*
| Never argue with an idiot, they'll drag you down to |
| their level, and beat you with experience |
*-----------------------------------------------------*
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
Re: ModifiableConfiguration [ was "Porting dbXML to Avalon" ]
Posted by Paul Hammant <Pa...@yahoo.com>.
Berin,
>>> cfg.getChild("somechild").getChild("anotherchild").getValueAsLong();
>>
>> setableCfg.getChild("somechild").getChild("anotherchild").setLongValue(14);
>
>
>Thanks for the refocusing comment above. My question
>is, "who is responsible for setting the
>configuration?"
>The point being, with the IoC pattern (see site docs
>for those not familiar), the Configuration is given as
>a read only instance for a reason. The Configurable
>Component is not supposed to alter the system beneath
>it in the Component heirarchy. With that in mind, we
>have to consider exactly what types of configuration
>changes are occuring, the affect on the system, and
>which component/service is responsible for altering
>the
>configuration.
>
Yes it's true that Configurable gived a read-only configuration, but if
the block......
1) implements ConfigurationModifier,
2) specifies which Configuration nodes it will be seeking to have
modification rights for, in it's assembly.xml,
3) is then handed a ModifiableConfiguration during startup,
4) call invoke getChild("x").getChild("y").setLongValue(14) on that
only, not it's own Configuration.
..... does that still break the IoC design goals?
>It is probable that the dbXML folks have thought many
>of these things through, so I am very interested in
>the approach and thought processes they have gone
>through for their system.
>
>It could be that we should develop a special purpose
>configuration management service that manages the
>persistence of the Configuration elements. In that
>case we programmatically build what we _want_ the
>configuration to be (i.e. the current method building
>configuration trees) and register it with the
>Configuration Management Service. The service would
>be an Avalon Block in CornerStone.
>
Sounds superior to the above...
- Paul
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
Re: ModifiableConfiguration [ was "Porting dbXML to Avalon" ]
Posted by Berin Loritsch <bl...@yahoo.com>.
--- Paul Hammant <Pa...@yahoo.com> wrote:
> >
> >
> >[... Xpath complex & room for plenty of error ...]
> >
> Conceeded.
>
> >
> >Another possibility, is to just stick with method
> calls (ex):
> >
>
>cfg.getChild("somechild").getChild("anotherchild").getValueAsLong();
> >
> That's what Configurable gives already. We're
> dwelling on the setting
> of config rather than the getting of it in this
> discussion.
>
>
>
setableCfg.getChild("somechild").getChild("anotherchild").setLongValue(14);
>
> How that?
Thanks for the refocusing comment above. My question
is, "who is responsible for setting the
configuration?"
The point being, with the IoC pattern (see site docs
for those not familiar), the Configuration is given as
a read only instance for a reason. The Configurable
Component is not supposed to alter the system beneath
it in the Component heirarchy. With that in mind, we
have to consider exactly what types of configuration
changes are occuring, the affect on the system, and
which component/service is responsible for altering
the
configuration.
It is probable that the dbXML folks have thought many
of these things through, so I am very interested in
the approach and thought processes they have gone
through for their system.
It could be that we should develop a special purpose
configuration management service that manages the
persistence of the Configuration elements. In that
case we programmatically build what we _want_ the
configuration to be (i.e. the current method building
configuration trees) and register it with the
Configuration Management Service. The service would
be an Avalon Block in CornerStone.
__________________________________________________
Do You Yahoo!?
Get email alerts & NEW webcam video instant messaging with Yahoo! Messenger
http://im.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
Re: ModifiableConfiguration [ was "Porting dbXML to Avalon" ]
Posted by Tom Bradford <br...@dbxmlgroup.com>.
Paul Hammant wrote:
> >cfg.getChild("somechild").getChild("anotherchild").getValueAsLong();
> >
> That's what Configurable gives already. We're dwelling on the setting
> of config rather than the getting of it in this discussion.
Yeah, I know... It's a simple, straight-forward approach, which is why
I suggested sticking with it. Should have use the setValue as an
example instead of getValue...
> setableCfg.getChild("somechild").getChild("anotherchild").setLongValue(14);
>
> How that?
Fine by me. Another thing that we do in our configuration system is the
idea of a ConfigurationCallback interface, so for example:
colConfig.processChildren("collection",
new ConfigurationCallback() {
public void process(Configuration cfg) throws dbXMLException {
Collection col = new
Collection((Collection)CollectionManager.this);
col.setConfig(cfg);
collections.put(col.getName(), col);
}
});
This would behave in a similar fashion to getting the child set by name
except that there wouldn't be the additional overhead of having to
produce an array and then iterate over it.
--
Tom Bradford The dbXML Group, L.L.C. http://www.dbxmlgroup.com/
Desktop, Laptop, Settop, Palmtop. Can your XML database do that?
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
Re: ModifiableConfiguration [ was "Porting dbXML to Avalon" ]
Posted by Paul Hammant <Pa...@yahoo.com>.
>
>
>[... Xpath complex & room for plenty of error ...]
>
Conceeded.
>
>Another possibility, is to just stick with method calls (ex):
>
>cfg.getChild("somechild").getChild("anotherchild").getValueAsLong();
>
That's what Configurable gives already. We're dwelling on the setting
of config rather than the getting of it in this discussion.
setableCfg.getChild("somechild").getChild("anotherchild").setLongValue(14);
How that?
- PH
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
Re: ModifiableConfiguration [ was "Porting dbXML to Avalon" ]
Posted by Tom Bradford <br...@dbxmlgroup.com>.
Paul Hammant wrote:
>
> Peter Donald wrote:
>
> >I was thinking about something as simple as current setup.
> >
> >ie
> >
> >vois storeConfiguration( String application,
> > String block,
> > Configuration config );
> >
> Hmm, that forced the comp writer to have some way of constructing an
> tree of Configuration objects themselves. I'd guess getting it right is
> a high art and buckets of code. Though there are good points raised
> about reliance on Xpath and it's implicit underlying XML document, I
> think it's a simple think for component writers to use.
There are issues beyond that as well. XPath is in no way simple. It's
actually a potentially very complex and highly flexible language that
maps well to XML documents, but not necessary well to non-XML
structures. It's definitely not easy to write an XPath implementation
(as the Xalan people). Beyond that, there are other issues, like the
nature of selectors, for example:
//node()
Is a perfectly valid XPath selector that recursively selects *every*
node in a tree. This includes elements, attributes, text, cdata,
comments, etc.... If you were to use this XPath as a selector for
performing a modification to a tree, you'd end up touching the entire
tree, which could be very bad. There are also the functions that return
non-nodesets, and may modify the values of the returned values in the
process.
I would propose a terse, simplified pathing system that does not support
functions, all-descendent/ancestor axis, and many of the other nice
features of XPath that neither translate well to a configuration model,
or translate well to a non-XML structure.
Another possibility, is to just stick with method calls (ex):
cfg.getChild("somechild").getChild("anotherchild").getValueAsLong();
For two reasons:
1 - Though verbose, it provides the same functionality a terse pathing
form would.
2 - It's structural validity can be qualified at compile-time.. XPath
would require run-time validation.
--
Tom Bradford The dbXML Group, L.L.C. http://www.dbxmlgroup.com/
Desktop, Laptop, Settop, Palmtop. Can your XML database do that?
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
Re: ModifiableConfiguration [ was "Porting dbXML to Avalon" ]
Posted by Paul Hammant <Pa...@yahoo.com>.
Peter Donald wrote:
>I was thinking about something as simple as current setup.
>
>ie
>
>vois storeConfiguration( String application,
> String block,
> Configuration config );
>
Hmm, that forced the comp writer to have some way of constructing an
tree of Configuration objects themselves. I'd guess getting it right is
a high art and buckets of code. Though there are good points raised
about reliance on Xpath and it's implicit underlying XML document, I
think it's a simple think for component writers to use.
<aside short="Crossed the same bridge with Jesktop">
I'm mentioning it becuase Jesktop now has Configlets - e.g.
BackdropConfigket being one such publisher of XML. The subscriber to
the backdrop config (XML) is the WindowManager. The publisher makes
changes as it's visible in ControlPanel and the changes are forwarded on
to the WindowManager for acting upon. For Configlets writing xml is
pain. So much so that I also created Configlets that deal in serialized
objects. I was toying with Dom4JConfiglet but that raised license issues.
</aside>
Regards,
- Paul H
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
Re: ModifiableConfiguration [ was "Porting dbXML to Avalon" ]
Posted by Peter Donald <do...@apache.org>.
On Sun, 2 Sep 2001 19:01, Tom Bradford wrote:
> Paul Hammant wrote:
> > Hypothetical -
> >
> > If we went ahead with ModifiableConfiguration ConfigurationModifier and
> > Reconfigurable (extends Configurable) would we invoke the update method
> > with a xpath-style ID for the node within the sub-ddocument to change?
> > If yes, we could use dom4j as an interim implmentation (it's very good).
>
> I would try to keep it in the family and just use the Xalan XPathAPI
> stuff. I'm skeptible of exposing XPaths as the form for performing
> selection against the configuration though, as it assumes (to a degree)
> that the underlying representation is XML, when it may not be.
I was thinking about something as simple as current setup.
ie
vois storeConfiguration( String application,
String block,
Configuration config );
I haven't really thought about how logging/security/threading can be
reconfigured. Those changes would require an app shutdown - while changing a
blocks configuration does not require that.
As I have hinted at in past I really really want to have one ConfigRepository
stored in a directory (ala LDAP) to ease management.
--
Cheers,
Pete
-------------------------------------------------------
To fight and conquer in all your battles is not supreme
excellence; supreme excellence consists in breaking the
enemy's resistance without fighting. - Sun Tzu, 300 B.C.
-------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
Re: ModifiableConfiguration [ was "Porting dbXML to Avalon" ]
Posted by Tom Bradford <br...@dbxmlgroup.com>.
Paul Hammant wrote:
> Hypothetical -
>
> If we went ahead with ModifiableConfiguration ConfigurationModifier and Reconfigurable (extends Configurable) would we invoke the update method with a xpath-style ID for the node within the sub-ddocument to change? If yes, we could use dom4j as an interim implmentation (it's very good).
I would try to keep it in the family and just use the Xalan XPathAPI
stuff. I'm skeptible of exposing XPaths as the form for performing
selection against the configuration though, as it assumes (to a degree)
that the underlying representation is XML, when it may not be.
--
Tom Bradford The dbXML Group, L.L.C. http://www.dbxmlgroup.com/
Desktop, Laptop, Settop, Palmtop. Can your XML database do that?
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
ModifiableConfiguration [ was "Porting dbXML to Avalon" ]
Posted by Paul Hammant <Pa...@yahoo.com>.
>
>
>I was thinking ModifiableConfiguration (if we choose to use an interface
>rather than an implementation) and ConfigurationModifier (a callback passed
>to ConfigurationRepository).
>
Hypothetical -
If we went ahead with ModifiableConfiguration ConfigurationModifier and Reconfigurable (extends Configurable) would we invoke the update method with a xpath-style ID for the node within the sub-ddocument to change? If yes, we could use dom4j as an interim implmentation (it's very good).
Would a listener architecture be needed for comps that might want to listen for changes, or is Reconfigurable (implicit listener) enough?
Would some blocks be designated maintainers of others blocks configuration? As could be defined in assembly.xml and config.xml:
<!-- assembly.xml -->
<block class="package.classname" name="xyz-server"/>
<block class="package2.classname2" name="xyz-settings-controller" />
<!-- config.xml -->
<xyz-settings>
<a>b</b>
<c>d</c>
</xyz-settings>
<xyz-settings-controller>
<reconfigurer-of>
<block-name>xyz-server</block-name>
</reconfigurer-of>
</xyz-settings-controller>
-PH
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
Re: Porting dbXML to Avalon
Posted by Peter Donald <do...@apache.org>.
On Sun, 2 Sep 2001 09:38, Paul Hammant wrote:
> If you can mine this maillist you'll see Peter and Fede ++ discussing
> things about six months ago. Configurable and Reconfigurable. Perhaps
> you need a ConfigurationUpdate interface ..
>
> interface ConfigurationUpdater {
> void setConfigurationUpdateThing(ConfigurationUpdateThing cut);
> }
>
> interface ConfigurationUpdateThing {
> void setConfiguration(XPath path, String value);
> void setConfiguration(XPath path, int value);
> ...
> }
>
> Note - I am not sure what the best name for these interfaces are.
> Especially the "Thing" bit.
I was thinking ModifiableConfiguration (if we choose to use an interface
rather than an implementation) and ConfigurationModifier (a callback passed
to ConfigurationRepository).
--
Cheers,
Pete
*----------------------------------------------------------*
The phrase "computer literate user" really means the person
has been hurt so many times that the scar tissue is thick
enough so he no longer feels the pain.
-- Alan Cooper, The Inmates are Running the Asylum
*----------------------------------------------------------*
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
Re: Porting dbXML to Avalon
Posted by Tom Bradford <br...@dbxmlgroup.com>.
Paul Hammant wrote:
> You've beaten it already then I think. Start by having a look
> HelloWorldServer or some of the others. Wehn starting new blocks, I
> invariable clone one of these and make it what I want (iteratively).
>
> "top-level object graph" Not sure what you mean here.
Just mean that when we start up the server framework we create a single
Kernel instance, hand it a configuration location, and let 'er rip. Top
level would be the kernel instance that contains everything else. In
theory the juggernaut stuff can have many Kernels in a VM, but we've
never had a reason to do it.
> The only static in Avalon will be genuine factories.
Cool.
> >Worse case, we can use our existing configuration framework, which is
> You're saying what we've done (or not done) is the worst case scenarios
> for you? Perhaps then suggest and interface that could touch on what
> you need :-)
Actually, by worst case, I meant that if we ultimately decide that it
would be too much of a pain to immediately convert things over to the
Avalon configuration system, we could keep our own.
--
Tom Bradford The dbXML Group, L.L.C. http://www.dbxmlgroup.com/
Desktop, Laptop, Settop, Palmtop. Can your XML database do that?
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
Re: Porting dbXML to Avalon
Posted by Paul Hammant <Pa...@yahoo.com>.
>
>
>>Static is the killer. I guess only beginners make that mistake. No
>>singletons needed for Avalon/phoenix.
>>
>
>Can you elaborate a little? In the Juggernaut framework (which I
>designed about 4-5 years ago) there is a single static instance of a
>kernel just by virtue of the VM only creating one in the main method,
>but the reference to the kernel is passed down to all child components
>in the object graph that support a kernel-accessible interface. Is the
>top-level object graph only available in Avalon/Phoenix via static
>methods?
>
You've beaten it already then I think. Start by having a look
HelloWorldServer or some of the others. Wehn starting new blocks, I
invariable clone one of these and make it what I want (iteratively).
"top-level object graph" Not sure what you mean here.
The only static in Avalon will be genuine factories.
>>>My one concern is the configuration system. Avalon's configuration
>>>
>>Yes, it's read only. One day it will be updatable. For now, perhaps
>>seperate logically into your own interal services (and one or more
>>blocks that deliver than service). What you could do in one
>>DbXmlConfiguration service (and it's DefaultDbXmlConfiguration block) is
>>copy stuff from the read only Configuration (from assembly.xml) and
>>write immediately to the persistence store. Charles' SimpleServer demo
>>uses the persistence store. When the writable configuration arrives,
>>you could change (hopefully) the block only. You et the functioanly you
>>require immediately though.
>>
>
>Worse case, we can use our existing configuration framework, which is
>almost identical to the Avalon framework (interface-wise) except that it
>supports writing and is implemented using concrete classes layered on
>top of a DOM.
>
You're saying what we've done (or not done) is the worst case scenarios
for you? Perhaps then suggest and interface that could touch on what
you need :-)
If you can mine this maillist you'll see Peter and Fede ++ discussing
things about six months ago. Configurable and Reconfigurable. Perhaps
you need a ConfigurationUpdate interface ..
interface ConfigurationUpdater {
void setConfigurationUpdateThing(ConfigurationUpdateThing cut);
}
interface ConfigurationUpdateThing {
void setConfiguration(XPath path, String value);
void setConfiguration(XPath path, int value);
...
}
Note - I am not sure what the best name for these interfaces are.
Especially the "Thing" bit.
The idea being that some blocks implement Configurable. Some blocks
implement Configurable and ConfigurationUpdater (does not extend the
former though).
Regards,
- Paul H
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
Re: Porting dbXML to Avalon
Posted by Tom Bradford <br...@dbxmlgroup.com>.
Paul Hammant wrote:
> Static is the killer. I guess only beginners make that mistake. No
> singletons needed for Avalon/phoenix.
Can you elaborate a little? In the Juggernaut framework (which I
designed about 4-5 years ago) there is a single static instance of a
kernel just by virtue of the VM only creating one in the main method,
but the reference to the kernel is passed down to all child components
in the object graph that support a kernel-accessible interface. Is the
top-level object graph only available in Avalon/Phoenix via static
methods?
> >My one concern is the configuration system. Avalon's configuration
> Yes, it's read only. One day it will be updatable. For now, perhaps
> seperate logically into your own interal services (and one or more
> blocks that deliver than service). What you could do in one
> DbXmlConfiguration service (and it's DefaultDbXmlConfiguration block) is
> copy stuff from the read only Configuration (from assembly.xml) and
> write immediately to the persistence store. Charles' SimpleServer demo
> uses the persistence store. When the writable configuration arrives,
> you could change (hopefully) the block only. You et the functioanly you
> require immediately though.
Worse case, we can use our existing configuration framework, which is
almost identical to the Avalon framework (interface-wise) except that it
supports writing and is implemented using concrete classes layered on
top of a DOM.
> >Also, is Tomcat 4 running on top of Avalon? I had heard rumblings to
> Not yet. Marketing campaign to begin soon....
Cool. We plan on replacing our own HTTPServer with Tomcat when it's
time to do so.
> Welcome aboard, by the way.
Thanks,
Tom
--
Tom Bradford The dbXML Group, L.L.C. http://www.dbxmlgroup.com/
Desktop, Laptop, Settop, Palmtop. Can your XML database do that?
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
Re: Porting dbXML to Avalon
Posted by Paul Hammant <Pa...@yahoo.com>.
>
>
>The next version of dbXML (1.5) will be ported from the Juggernaut
>server framework to Avalon. From a very high level, it looks like it
>should be fairly easy, but I was wondering if anybody has run into any
>gotchas porting between server frameworks.
>
I guess I am chief porter for the mo ;-)
Static is the killer. I guess only beginners make that mistake. No
singletons needed for Avalon/phoenix.
>My one concern is the configuration system. Avalon's configuration
>interfaces seem to be read-only, but our server needs to maintain its
>own configuration on disk. Are there additional interfaces in Avalon
>for managing 'writable' configurations?
>
Yes, it's read only. One day it will be updatable. For now, perhaps
seperate logically into your own interal services (and one or more
blocks that deliver than service). What you could do in one
DbXmlConfiguration service (and it's DefaultDbXmlConfiguration block) is
copy stuff from the read only Configuration (from assembly.xml) and
write immediately to the persistence store. Charles' SimpleServer demo
uses the persistence store. When the writable configuration arrives,
you could change (hopefully) the block only. You et the functioanly you
require immediately though.
>Also, is Tomcat 4 running on top of Avalon? I had heard rumblings to
>this degree, but can't confirm it from looking at the distro.
>
Not yet. Marketing campaign to begin soon....
Welcome aboard, by the way.
Regards,
- Paul H
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org