You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avalon.apache.org by Paul Hammant <Pa...@yahoo.com> on 2001/12/03 20:31:40 UTC
xinfo replacement
An idea...
New interfaces/classes in Pheonix --->
class ProvidedServiceDef {
ProvidedServiceDef(Class cl, float vers) {..}
Class getProvidedClass() {..}
float getServiceVersion() {..}
}
class DependedServiceDef {
DependedServiceDef (String str, float vers) {..}
String getDependedClassName() {..}
float getServiceVersion() {..}
}
interface BlockDef {
ProvidedServiceDef[] getProvidedServices();
DependedServiceDef[] getDependedServices();
}
A example of use ---->
final class XCommanderServerBlockDef implements BlockDef {
ProvidedServiceDef[] getProvidedServices() {
return new ProvidedServiceDef[] {
new
ProvidedServiceDef(org.apache.avalon.xcommander.XCommanderService.class,
1.0),
};
}
DependedServiceDef [] getDependedServices() {
return new DependedServiceDef [] {
new DependedServiceDef
("org.apache.avalon.cornerstone.services.connection.ConnectionManager",
1.0),
new DependedServiceDef
("org.apache.avalon.cornerstone.services.sockets.SocketManager", 1.0),
};
}
}
The though is that as XML blocks go, the xinfo is fairly mundane. If
these were Java classes, they could be more visible to those perusing
the Java source of a thing. Half of our Phoenix newbie issues are
because people are not keeping their xinfo files in step with their
assembly.xml files. With advanced IDEs like Intellij it will hopefully
ripple changes through to this BlockDef class as people iteratively
rename their chosen demo/pdk starting point to become their server app.
Ho hum, just a thought and the last vestige of my smart, then abandoned,
idea for Peter's new classloader constructs...
Regards,
- Paul H
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: xinfo replacement
Posted by Peter Donald <pe...@apache.org>.
On Tue, 4 Dec 2001 22:02, Paul Hammant wrote:
> >That is a problem. There was a few things we can do to alleviate this
> > issue. We could allow some sort of automagic creation of .xinfo files
> > from javadocs of specified blocks. This would help keep cost of
> > maaintaining them down a bit.
>
> Value points = 1
>
> >We could also (finally) create ant tasks to run the verifier over .sars
> >before they are deployed. This should give a good indication whether the
> >format is valid.
>
> Value points = 2
It should be simple enough to do I think. Have a look at tools.verifier.* -
we just need to instantiate that and pass in the proper classloaders etc.
> >We could also create DTDs for the different formats as appropriate and
> >interpret
>
> VP = 1
>
> >the files with that mind.
> >
> >I could also write a "Block File Archive Verifier" that verified the
> > format of all the Blocks info files, and the relationship beteen services
> > inside the jar, the manifest entrtys and so forth.
>
> VP = 4.
>
> Something that owuld comprehensively tell you what is wrong with a SAR.
> Something that we might not want part of the regular Phoenix machine
> (which we are trying to keep lean?)
Well anything I intend to use from ant tasks I have placed in
phoenix.tools.*. That simply makes it easier to package these tools so that
they are separate from container.
--
Cheers,
Pete
-----------------------------------------------
"You can't depend on your eyes when your
imagination is out of focus." -Mark Twain
-----------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: xinfo replacement
Posted by Paul Hammant <Pa...@yahoo.com>.
Peter Donald wrote:
>>An idea...
>>
>...snip...
>
>That is very close to our original design - originally XML was meant to be
>only one option (and something that is used only rarely).
>
>However pure xml files have several advantages. The essential one being that
>you don't have to construct a classloader and resolve all the classes to just
>read the infos. It would also be cumbersome to represent things like XSchema
>in .java files (when we eventually get around to implementing config
>validation). Besides it makes for a faster dev cycle based on experience with
>BeanInfos (what this spec was originally based upon) and articles like that
>declative vs procedural one.
>
The "classloader construct" is key I guess. OK I'm convinced.
>>The though is that as XML blocks go, the xinfo is fairly mundane. If
>>these were Java classes, they could be more visible to those perusing
>>the Java source of a thing. Half of our Phoenix newbie issues are
>>because people are not keeping their xinfo files in step with their
>>assembly.xml files. With advanced IDEs like Intellij it will hopefully
>>ripple changes through to this BlockDef class as people iteratively
>>rename their chosen demo/pdk starting point to become their server app.
>>
>
>That is a problem. There was a few things we can do to alleviate this issue.
>We could allow some sort of automagic creation of .xinfo files from javadocs
>of specified blocks. This would help keep cost of maaintaining them down a
>bit.
>
Value points = 1
>We could also (finally) create ant tasks to run the verifier over .sars
>before they are deployed. This should give a good indication whether the
>format is valid.
>
Value points = 2
>We could also create DTDs for the different formats as appropriate and
>interpret
>
VP = 1
>the files with that mind.
>
>I could also write a "Block File Archive Verifier" that verified the format
>of all the Blocks info files, and the relationship beteen services inside the
>jar, the manifest entrtys and so forth.
>
VP = 4.
Something that owuld comprehensively tell you what is wrong with a SAR.
Something that we might not want part of the regular Phoenix machine
(which we are trying to keep lean?)
- Paul
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: xinfo replacement
Posted by Peter Donald <pe...@apache.org>.
On Tue, 4 Dec 2001 06:31, Paul Hammant wrote:
> An idea...
...snip...
That is very close to our original design - originally XML was meant to be
only one option (and something that is used only rarely).
However pure xml files have several advantages. The essential one being that
you don't have to construct a classloader and resolve all the classes to just
read the infos. It would also be cumbersome to represent things like XSchema
in .java files (when we eventually get around to implementing config
validation). Besides it makes for a faster dev cycle based on experience with
BeanInfos (what this spec was originally based upon) and articles like that
declative vs procedural one.
> The though is that as XML blocks go, the xinfo is fairly mundane. If
> these were Java classes, they could be more visible to those perusing
> the Java source of a thing. Half of our Phoenix newbie issues are
> because people are not keeping their xinfo files in step with their
> assembly.xml files. With advanced IDEs like Intellij it will hopefully
> ripple changes through to this BlockDef class as people iteratively
> rename their chosen demo/pdk starting point to become their server app.
That is a problem. There was a few things we can do to alleviate this issue.
We could allow some sort of automagic creation of .xinfo files from javadocs
of specified blocks. This would help keep cost of maaintaining them down a
bit.
We could also (finally) create ant tasks to run the verifier over .sars
before they are deployed. This should give a good indication whether the
format is valid.
We could also create DTDs for the different formats as appropriate and
interpret the files with that mind.
I could also write a "Block File Archive Verifier" that verified the format
of all the Blocks info files, and the relationship beteen services inside the
jar, the manifest entrtys and so forth.
Thoughts?
--
Cheers,
Pete
--------------------------------------------------
Logic: The art of being wrong with confidence...
--------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>