> Greetings! My name is Ken,
hi, and welcome!
> and I just lost my job.
bummer...
> My big project
> before the company folded was to reimplement a Dynamo site that I had
> done a lot of work on with servlets/JSP. I chose to use Struts as well.
> Moving away from Dynamo, we lost a lot of functionality, but it was a
> business decision. I think that the combination of Avalon, Struts,
> Tomcat, and JMX would have given us what we wanted.
>
> I kinda want to see that vision through. Anyway, I was starting a
> personal project and Avalon solves some of the issues in it.
If you're still planning on combining Tomcat/Avalon at a close level
you might want to look at eas.betaversion.org (IIRC) who are doing
just that.
> I've gotten my server to the point where I have a skeleton Block that
> depends on DataSourceSelector. I can't understand how, in config.xml,
> to resolve that dependency (i.e. link the blocks.) I'm also confused by
> the config.xml file at all, and how that information gets to the blocks.
>
> If someone can help me out with this, I'm also starting a visual block
> assembly/configuration tool, and that work can continue.
> OK. I understand how to link blocks together in the assembly.xml now.
>
> I was confused about config.xml because I didn't realize that
> Configuration objects are hierarchical. That's OK now.
>
> I'm still wondering... Is there anything planned to introspect a block
> and figure out how its configuration is structured? I'd think this
> would be important for visual tools to configure an Avalon server.
My guess is that an introspection tool where you can configure all aspects
of Avalon and all Avalon-compatible blocks/apps/components is hard rtti
programming using any structure.
The current structure is that there is a tree and otherwise no rules (except
that if there are children there is no content and if there is content there
are no children). I'd say you can handle this with a JTree where the nodes
map to configuration objects.
I might be missing the point...what are you looking for?
On a sidenote, phoenix doesn't have a very clean configuration system yet.
We're working on that (well not quite atm, but its on the list). If you
have ideas, shoot. Either way, don't get mad when things break ;)
guys, if Ken wants to submit his visual tool to the project, that'd be a
nice excuse to start the apps-built-on/with-avalon repository/package
thing (and move the cornerstone demos there while we're at it).
cheers!
Leo
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
