You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@excalibur.apache.org by Matthew Harrah <ma...@platinumsolutions.com> on 2004/10/25 14:49:54 UTC
- no subject -
I am insterested in creating the metadata that fortress requires without
using the javadoc tags.
We have an application using the old ECM roles files and turning its
contents into javadoc tags into 750 or so java classes is unappealing.
Plus, we are using a tool at development time that maintains our roles
file for us and needs it to be there for us to continue to be able to
use it, and it does not know about the javadoc tags.
So, what I'm thinking is writing something to take the roles file and
make the .meta files and the services.list file and whatever else
fortress might need, perhaps through an XSL transform....
You seasoned fortress guys and gals: does this sound feasible? Is there
documentation (stop laughing!) about the format of the metadata, or do I
need to reverse engineer classes like
org.apache.avalon.fortress.tools.ComponentMetaInfoCollector and hack it?
Or is it so simple as to be trivial?
--
Matt Harrah
Senior Consultant, PlatinumSolutions, Inc.
matt.harrah@platinumsolutions.com
http://www.platinumsolutions.com
Two Discovery Square, 12012 Sunset Hills Road, Suite 445
Reston, VA 20190 PH: 703.471.9793 FAX: 703.471.7140
This message is for the designated recipient only and may contain
privileged, proprietary, or otherwise private information. If you have
received it in error, please notify the sender immediately and delete
the original. Any other use of the email by you is prohibited.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@excalibur.apache.org
For additional commands, e-mail: dev-help@excalibur.apache.org
Apache Excalibur Project -- URL: http://excalibur.apache.org/
Re: - no subject -
Posted by Marcus Crafter <cr...@managesoft.com>.
On Mon, 2004-10-25 at 15:54, Matthew Harrah wrote:
> What I'm really hoping to do is fool the container by emulating the
> javadoc tag output from an alternate source (the roles file instead of
> javadoc tags). I want the container to think I used javadoc tags when in
> reality I used roles files.
>
> From my research, it looks like I could just create .meta files with the
> shorthands in them, and services.list files with the classnames of the
> services being used, and that's all that's needed. Can anyone think of
> anything else I might need?
OK, well, normal Fortress .meta/services.list files are created from the
@tags using the Fortress Tools ant task. This is what an app developer
needs to call to create the services files that Fortress reads at
runtime.
If you're looking to generate the same data from ECM roles file, I'd
look at enhancing the tool ant task to read a roles file and generate
the metadata files.
This would be useful for anyone using ECM who wants to use their
components in Fortress without wanting to add the @tags.
You'd just need to generate the files you mention above from the roles
file, but also you'd need to deduce the lifestyle type from the
component (singleton, transient, pooled) since ECM uses SingleThreaded,
Pooled, etc interfaces which aren't in the roles file.
Hope this helps.
Cheers,
Marcus
--
.....
,,$$$$$$$$$, Marcus Crafter
;$' '$$$$: Computer Systems Engineer
$: $$$$: ManageSoft Corporation
$ o_)$$$: Frankfurt am Main, Germany
;$, _/\ &&:'
' /( &&&
\_&&&&'
&&&&.
&&&&&&&:
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@excalibur.apache.org
For additional commands, e-mail: dev-help@excalibur.apache.org
Apache Excalibur Project -- URL: http://excalibur.apache.org/
Re: - no subject -
Posted by Berin Loritsch <bl...@d-haven.org>.
Matthew Harrah wrote:
> You are probably correct. However, I am doing this from within Keel 2.0,
> which as near as I can tell does not allow me to select how the metadata
> is read by the container, or which container is used. So, for me
> changing or enhancing Avalon is not really an option. I didn't say this
> before because I didn't want to muddy the water with something that
> seemed at the time like it didn't matter, but I guess it does.
>
> What I'm really hoping to do is fool the container by emulating the
> javadoc tag output from an alternate source (the roles file instead of
> javadoc tags). I want the container to think I used javadoc tags when in
> reality I used roles files.
>
>>>From my research, it looks like I could just create .meta files with the
> shorthands in them, and services.list files with the classnames of the
> services being used, and that's all that's needed. Can anyone think of
> anything else I might need?
>
The services.list file is a list of all the service interface class
names, pointing to the Java 1.4 services interface:
META-INF/services/<classname>
Each file in the directory (above) has the same name as the class name,
and is a list of the implementation classes (the actual components) that
implement that interface. NOTE: if a component implements more than one
interface, it's implementation is listed for each interface.
For each component there are the .meta and .deps files right next to the
class file. The .meta class has the info you described, and the .deps
file has the list of interface names that the class depends on. It is
used both for ordering the startup and shutdown of components and to
detect circular dependencies (or potential circular dependencies).
--
"Programming today is a race between software engineers striving to
build bigger and better idiot-proof programs, and the Universe trying to
produce bigger and better idiots. So far, the Universe is winning."
- Rich Cook
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@excalibur.apache.org
For additional commands, e-mail: dev-help@excalibur.apache.org
Apache Excalibur Project -- URL: http://excalibur.apache.org/
Re: - no subject -
Posted by Matthew Harrah <ma...@platinumsolutions.com>.
You are probably correct. However, I am doing this from within Keel 2.0,
which as near as I can tell does not allow me to select how the metadata
is read by the container, or which container is used. So, for me
changing or enhancing Avalon is not really an option. I didn't say this
before because I didn't want to muddy the water with something that
seemed at the time like it didn't matter, but I guess it does.
What I'm really hoping to do is fool the container by emulating the
javadoc tag output from an alternate source (the roles file instead of
javadoc tags). I want the container to think I used javadoc tags when in
reality I used roles files.
>From my research, it looks like I could just create .meta files with the
shorthands in them, and services.list files with the classnames of the
services being used, and that's all that's needed. Can anyone think of
anything else I might need?
On Oct 25, 2004 09:31 AM, Marcus Crafter <cr...@managesoft.com>
wrote:
> Hi Matthew,
>
> Hope all is going well.
>
> >From memory, Fortress already supports reading the ECM style roles
> >file,
> so it's quite possible that you don't have to change anything. Check
> out
> this class:
>
> org/apache/avalon/fortress/impl/role/ECMRoleManager.java
>
> Aside from that, It would be good to have a migration tool to build
> metadata from ECM components. Might be worth enhancing the fortress
> metadata generation ant task to handle the existence of a .roles file.
> This would then let people use the newer @tags based and older ECM
> style
> components.
>
> Let us know which way you decide to go :)
>
> Cheers,
>
> Marcus
>
> On Mon, 2004-10-25 at 14:49, Matthew Harrah wrote:
> > I am insterested in creating the metadata that fortress requires
> > without
> > using the javadoc tags.
> >
> > We have an application using the old ECM roles files and turning its
> > contents into javadoc tags into 750 or so java classes is
> > unappealing.
> > Plus, we are using a tool at development time that maintains our
> > roles
> > file for us and needs it to be there for us to continue to be able
> > to
> > use it, and it does not know about the javadoc tags.
> >
> > So, what I'm thinking is writing something to take the roles file
> > and
> > make the .meta files and the services.list file and whatever else
> > fortress might need, perhaps through an XSL transform....
> >
> > You seasoned fortress guys and gals: does this sound feasible? Is
> > there
> > documentation (stop laughing!) about the format of the metadata, or
> > do I
> > need to reverse engineer classes like
> > org.apache.avalon.fortress.tools.ComponentMetaInfoCollector and hack
> > it?
> > Or is it so simple as to be trivial?
> --
> .....
> ,,$$$$$$$$$, Marcus Crafter
> ;$' '$$$$: Computer Systems Engineer
> $: $$$$: ManageSoft Corporation
> $ o_)$$$: Frankfurt am Main, Germany
> ;$, _/ &&:'
> ' /( &&&
> _&&&&'
> &&&&.
> &&&&&&&:
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@excalibur.apache.org
> For additional commands, e-mail: dev-help@excalibur.apache.org
> Apache Excalibur Project -- URL: http://excalibur.apache.org/
>
--
Matt Harrah
Senior Consultant, PlatinumSolutions, Inc.
matt.harrah@platinumsolutions.com
http://www.platinumsolutions.com
Two Discovery Square, 12012 Sunset Hills Road, Suite 445
Reston, VA 20190 PH: 703.471.9793 FAX: 703.471.7140
This message is for the designated recipient only and may contain
privileged, proprietary, or otherwise private information. If you have
received it in error, please notify the sender immediately and delete
the original. Any other use of the email by you is prohibited.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@excalibur.apache.org
For additional commands, e-mail: dev-help@excalibur.apache.org
Apache Excalibur Project -- URL: http://excalibur.apache.org/
Re: - no subject -
Posted by Marcus Crafter <cr...@managesoft.com>.
Hi Matthew,
Hope all is going well.
>>From memory, Fortress already supports reading the ECM style roles file,
so it's quite possible that you don't have to change anything. Check out
this class:
org/apache/avalon/fortress/impl/role/ECMRoleManager.java
Aside from that, It would be good to have a migration tool to build
metadata from ECM components. Might be worth enhancing the fortress
metadata generation ant task to handle the existence of a .roles file.
This would then let people use the newer @tags based and older ECM style
components.
Let us know which way you decide to go :)
Cheers,
Marcus
On Mon, 2004-10-25 at 14:49, Matthew Harrah wrote:
> I am insterested in creating the metadata that fortress requires without
> using the javadoc tags.
>
> We have an application using the old ECM roles files and turning its
> contents into javadoc tags into 750 or so java classes is unappealing.
> Plus, we are using a tool at development time that maintains our roles
> file for us and needs it to be there for us to continue to be able to
> use it, and it does not know about the javadoc tags.
>
> So, what I'm thinking is writing something to take the roles file and
> make the .meta files and the services.list file and whatever else
> fortress might need, perhaps through an XSL transform....
>
> You seasoned fortress guys and gals: does this sound feasible? Is there
> documentation (stop laughing!) about the format of the metadata, or do I
> need to reverse engineer classes like
> org.apache.avalon.fortress.tools.ComponentMetaInfoCollector and hack it?
> Or is it so simple as to be trivial?
--
.....
,,$$$$$$$$$, Marcus Crafter
;$' '$$$$: Computer Systems Engineer
$: $$$$: ManageSoft Corporation
$ o_)$$$: Frankfurt am Main, Germany
;$, _/\ &&:'
' /( &&&
\_&&&&'
&&&&.
&&&&&&&:
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@excalibur.apache.org
For additional commands, e-mail: dev-help@excalibur.apache.org
Apache Excalibur Project -- URL: http://excalibur.apache.org/