You are viewing a plain text version of this content. The canonical link for it is here.
Posted to xindice-dev@xml.apache.org by Paul Hammant <Pa...@yahoo.com> on 2001/12/29 13:16:21 UTC
Xindice on Avalon
Folks,
Has this been discussed on the list before? That is : migrating Xindice
to be an Avalon based application.
I know Tom hovers on the Avalon list, but don't know whether a migration
would be too daunting. Especially given excellent articles like this :
http://www.joelonsoftware.com/articles/fog0000000069.html
For those that don't know about Avalon, see this page
http://jakarta.apache.org/avalon/
Especially read up on Stefano's Inversion of Control (Ioc) pattern :
http://jakarta.apache.org/avalon/framework/inversion-of-control.html
If consenting, for Xindice I would recomend aiming at Avalon/Phoenix -
http://jakarta.apache.org/avalon/phoenix/index.html ( *nice pictures* ).
I'd suggest many refactorings over a month or so to get closer and
closer to Phoenix capability. Refactorings that do not at any point
detract from Xindice's capacity to function fully.
What is thought of this?
Regards,
- Paul H
Re: Xindice on Avalon
Posted by Tom Bradford <br...@dbxmlgroup.com>.
On Saturday, December 29, 2001, at 11:22 AM, Paul Hammant wrote:
> Great. Do you mean port (as in fork) or migration.
Migration.
>> As part of the porting effort, we'll need to convert a handful of
>> specific entities in the Xindice tree that were implemented as part of
>> the Juggernaut framework:
>>
>> - Services
>> HTTPServer (May modify this to be Servlet-based)
>>
> This sounds cool. Is there any chance this could ultimately be made a
> seperate Phoenix block? If lightweight, it could be a deployment
> choice for assemblers.
This is a possibility. The code for the service itself is very minimal
and modular... All method handling is dispatched. Take a look at
org.apache.xindice.server.services.HTTPServer for the source code.
> This is where a gradual refactor approach could help. If you strive
> towards "beanification" where by the configurable component has
> multiple setter methods for configurable things, followed by an
> initialize() and start() invocations, then you'l be ready for allowing
> Phoenix to 'decorate' the server components block with configuration
> details, that it has retreieved from XML.
These patterns have been part of Juggernaut since the very beginning, so
it should be pretty straight-forward.
> As in code permissions or user authentication, authorisation and
> administration (AAA) or measures to prevent hacking and malicious code
> within the Phoenix machine?
Authentication and Permissioning.
> Incidentally, take a look at
> http://cvs.apache.org/viewcvs/jakarta-commons-sandbox/armi/
> It is something that is based on work in AvalonDB and overlaps a little
> with your recently announced "Labroador". I am going to ask Peter
> Donald to consider it for use internally in Phoenix for
> inter-application comms.
It looks interesting, but is a pretty grandiose undertaking. I'll take
a deeper look to see if there is any overlap or synergy. If we only
even support SOAP and XML-RPC in Labrador, I'd be very happy.
--
Tom Bradford - http://www.tbradford.org
Chief Architect - The dbXML Group, L.L.C.
Developer - Apache Xindice (formerly dbXML)
Maintainer - jEdit-Syntax Java Editing Bean
Co-Author - O'Reilly's "Learning Xindice"
Re: Xindice on Avalon
Posted by Paul Hammant <Pa...@yahoo.com>.
Tom,
>>[ migration to Avalon ]
>>
>>What is thought of this?
>>
>
>Part of what I'm working on these days is peeling back and chucking the
>layers of the Juggernaut framework that we don't need, so that a
>migration to Avalon won't be overly complicated when we're ready to do
>it. It won't happen with the 1.0 release, but I will start working on
>the port shortly thereafter.
>
Great. Do you mean port (as in fork) or migration.
>As part of the porting effort, we'll need to convert a handful of
>specific entities in the Xindice tree that were implemented as part of
>the Juggernaut framework:
>
> - Services
> HTTPServer (May modify this to be Servlet-based)
>
This sounds cool. Is there any chance this could ultimately be made a
seperate Phoenix block? If lightweight, it could be a deployment choice
for assemblers.
>XindiceService
> APIService (Won't be needed when we drop CORBA)
> - Logging
> Simple file logging with rollover
> - Component Management
> DBConduit (Can ultimately go away)
>
Cool.
>- Configuration (Not a super priority)
>
This is where a gradual refactor approach could help. If you strive
towards "beanification" where by the configurable component has multiple
setter methods for configurable things, followed by an initialize() and
start() invocations, then you'l be ready for allowing Phoenix to
'decorate' the server components block with configuration details, that
it has retreieved from XML.
>Also, what is the current state of a Security layer in Avalon?
>
As in code permissions or user authentication, authorisation and
administration (AAA) or measures to prevent hacking and malicious code
within the Phoenix machine?
>As you can see, there really isn't all that much to address, so the port
>should be straight-forward. I think we'd just like to get a 1.0 out
>before we start gutting the service framework out completely. Overall,
>changing the service framework won't change how users interact with the
>server, so doing it after 1.0 won't be like pulling the rug out.
>
:-)
Sounds like a good plan.
Incidentally, take a look at
http://cvs.apache.org/viewcvs/jakarta-commons-sandbox/armi/
It is something that is based on work in AvalonDB and overlaps a little
with your recently announced "Labroador". I am going to ask Peter
Donald to consider it for use internally in Phoenix for
inter-application comms.
Regards,
- Paul H
Re: Xindice on Avalon
Posted by Tom Bradford <br...@dbxmlgroup.com>.
Paul Hammant wrote:
> Has this been discussed on the list before? That is : migrating Xindice
> to be an Avalon based application.
>
> I know Tom hovers on the Avalon list, but don't know whether a migration
> would be too daunting. Especially given excellent articles like this :
> http://www.joelonsoftware.com/articles/fog0000000069.html
>
> If consenting, for Xindice I would recomend aiming at Avalon/Phoenix -
> http://jakarta.apache.org/avalon/phoenix/index.html ( *nice pictures* ).
> I'd suggest many refactorings over a month or so to get closer and
> closer to Phoenix capability. Refactorings that do not at any point
> detract from Xindice's capacity to function fully.
>
> What is thought of this?
Part of what I'm working on these days is peeling back and chucking the
layers of the Juggernaut framework that we don't need, so that a
migration to Avalon won't be overly complicated when we're ready to do
it. It won't happen with the 1.0 release, but I will start working on
the port shortly thereafter.
As part of the porting effort, we'll need to convert a handful of
specific entities in the Xindice tree that were implemented as part of
the Juggernaut framework:
- Services
HTTPServer (May modify this to be Servlet-based)
XindiceService
APIService (Won't be needed when we drop CORBA)
- Logging
Simple file logging with rollover
- Component Management
DBConduit (Can ultimately go away)
- Configuration (Not a super priority)
Also, what is the current state of a Security layer in Avalon?
As you can see, there really isn't all that much to address, so the port
should be straight-forward. I think we'd just like to get a 1.0 out
before we start gutting the service framework out completely. Overall,
changing the service framework won't change how users interact with the
server, so doing it after 1.0 won't be like pulling the rug out.
--
Tom Bradford - http://www.tbradford.org
Chief Architect - The dbXML Group, L.L.C.
Developer - Apache Xindice (formerly dbXML)
Maintainer - jEdit-Syntax Java Editing Bean
Co-Author - O'Reilly's "Learning Xindice"