subject:"multiple component jars"

-Original Message-
In any case - Ed's solution is very simple, might find its way even in
1.2, and is a whole lot better than having no possibility at all to
get this problem fixed in your webapp!
-/Original Message-
a) great to see it already in 1.2
b) easy enough to backport it to 1.1.modified ;-)
c) working
d) sort of transparent. For a big company which will fix the version
   of such libraries (as JSF...) for wuite some time, this solution
   will work quite well.

The only thing to keep in mind is the sorting sequence used by the 
OS hosting the JVM... (I remember some nightmares in that direction...)

regards
Alexander

Re: Fwd: multiple component jars

P.S.:

In any case - Ed's solution is very simple, might find its way even in
1.2, and is a whole lot better than having no possibility at all to
get this problem fixed in your webapp!

regards,

Martin

On 9/28/05, Martin Marinschek <[EMAIL PROTECTED]> wrote:
> Yes, if this was handled, we all would be more than satisfied with the
> solution ;)
>
> regards,
>
> Martin
>
> P.S.: pi-pa-po = nice German term for something like "mess"
>
> On 9/28/05, Craig McClanahan <[EMAIL PROTECTED]> wrote:
> >
> >
> > On 9/28/05, Martin Marinschek <[EMAIL PROTECTED]> wrote:
> > > Mike, Craig,
> > >
> > > that was a solution I thought about as well.
> > >
> > > But what do you do for the case that the user needs to "insert"
> > > himself somewhere in the middle of this whole dependency pi-pa-po?
> >
> >
> >  Hmm ... a new geek-speak term to learn :-).
> >
> > > There was an issue on the MyFaces mailing list were a user needed to
> > > get his phase-listener executed right before a myfaces one.
> > >
> > > If we try to solve this whole issue with sequences, we will need to
> > > solve this situation as well, right?
> >
> >  Yep, I think you are right.  You have to be able to declare dependencies
> > both ways, on a per application (or at least per-JAR) basis:
> >
> >  * "I am dependent on component library FOO, which must be
> >initialized before I am"
> >
> >  * "If component library BAR is used in this app, make sure that
> >I am initialized before it is"
> >
> >  Craig
> >
> > > Now there needs to be a possibility for the user to rewrite the
> > > dependencies! How do you want to do this?
> > >
> > > regards,
> > >
> > > Martin
> > >
> > > On 9/28/05, Mike Kienenberger <[EMAIL PROTECTED]> wrote:
> > > > Exactly!   I was going to use the MANIFEST Class-Path: attribute as an
> > > > example in my last message, but I wasn't sure if it was evaluated for
> > > > any jar other than the original target jar.
> > > >
> > > > On 9/28/05, Craig McClanahan <[EMAIL PROTECTED] > wrote:
> > > > >  Some sort of dependency declaration is going to be necessary for
> > solving
> > > > > this problem completely.  There's precedent in the way that a JAR file
> > can
> > > > > declare dependencies on other JARs in it's MANIFEST.MF file ...
> > something
> > > > > like that should be explored here as well.
> > > >
> > > >
> > >
> > >
> > > --
> > >
> > > http://www.irian.at
> > > Your JSF powerhouse -
> > > JSF Trainings in English and German
> > >
> >
> >
>
>
> --
>
> http://www.irian.at
> Your JSF powerhouse -
> JSF Trainings in English and German
>


--

http://www.irian.at
Your JSF powerhouse -
JSF Trainings in English and German

Re: Fwd: multiple component jars

Yes, if this was handled, we all would be more than satisfied with the
solution ;)

regards,

Martin

P.S.: pi-pa-po = nice German term for something like "mess"

On 9/28/05, Craig McClanahan <[EMAIL PROTECTED]> wrote:
>
>
> On 9/28/05, Martin Marinschek <[EMAIL PROTECTED]> wrote:
> > Mike, Craig,
> >
> > that was a solution I thought about as well.
> >
> > But what do you do for the case that the user needs to "insert"
> > himself somewhere in the middle of this whole dependency pi-pa-po?
>
>
>  Hmm ... a new geek-speak term to learn :-).
>
> > There was an issue on the MyFaces mailing list were a user needed to
> > get his phase-listener executed right before a myfaces one.
> >
> > If we try to solve this whole issue with sequences, we will need to
> > solve this situation as well, right?
>
>  Yep, I think you are right.  You have to be able to declare dependencies
> both ways, on a per application (or at least per-JAR) basis:
>
>  * "I am dependent on component library FOO, which must be
>initialized before I am"
>
>  * "If component library BAR is used in this app, make sure that
>I am initialized before it is"
>
>  Craig
>
> > Now there needs to be a possibility for the user to rewrite the
> > dependencies! How do you want to do this?
> >
> > regards,
> >
> > Martin
> >
> > On 9/28/05, Mike Kienenberger <[EMAIL PROTECTED]> wrote:
> > > Exactly!   I was going to use the MANIFEST Class-Path: attribute as an
> > > example in my last message, but I wasn't sure if it was evaluated for
> > > any jar other than the original target jar.
> > >
> > > On 9/28/05, Craig McClanahan <[EMAIL PROTECTED] > wrote:
> > > >  Some sort of dependency declaration is going to be necessary for
> solving
> > > > this problem completely.  There's precedent in the way that a JAR file
> can
> > > > declare dependencies on other JARs in it's MANIFEST.MF file ...
> something
> > > > like that should be explored here as well.
> > >
> > >
> >
> >
> > --
> >
> > http://www.irian.at
> > Your JSF powerhouse -
> > JSF Trainings in English and German
> >
>
>


--

http://www.irian.at
Your JSF powerhouse -
JSF Trainings in English and German

Re: Fwd: multiple component jars

2005-09-28 Thread Craig McClanahan

On 9/28/05, Martin Marinschek <[EMAIL PROTECTED]> wrote:
Mike, Craig,that was a solution I thought about as well.But what do you do for the case that the user needs to "insert"himself somewhere in the middle of this whole dependency pi-pa-po?

Hmm ... a new geek-speak term to learn :-). 
There was an issue on the MyFaces mailing list were a user needed toget his phase-listener executed right before a myfaces one.
If we try to solve this whole issue with sequences, we will need tosolve this situation as well, right?
Yep, I think you are right.  You have to be able to declare
dependencies both ways, on a per application (or at least per-JAR)
basis:

* "I am dependent on component library FOO, which must be
  initialized before I am"

* "If component library BAR is used in this app, make sure that
  I am initialized before it is"

Craig
Now there needs to be a possibility for the user to rewrite thedependencies! How do you want to do this?
regards,MartinOn 9/28/05, Mike Kienenberger <[EMAIL PROTECTED]> wrote:> Exactly!   I was going to use the MANIFEST Class-Path: attribute as an
> example in my last message, but I wasn't sure if it was evaluated for> any jar other than the original target jar.>> On 9/28/05, Craig McClanahan <[EMAIL PROTECTED]
> wrote:> >  Some sort of dependency declaration is going to be necessary for solving> > this problem completely.  There's precedent in the way that a JAR file can> > declare dependencies on other JARs in it's 
MANIFEST.MF file ... something> > like that should be explored here as well.>>--http://www.irian.atYour JSF powerhouse -JSF Trainings in English and German

Re: Fwd: multiple component jars

Mike, Craig,

that was a solution I thought about as well.

But what do you do for the case that the user needs to "insert"
himself somewhere in the middle of this whole dependency pi-pa-po?

There was an issue on the MyFaces mailing list were a user needed to
get his phase-listener executed right before a myfaces one.

If we try to solve this whole issue with sequences, we will need to
solve this situation as well, right?

Now there needs to be a possibility for the user to rewrite the
dependencies! How do you want to do this?

regards,

Martin

On 9/28/05, Mike Kienenberger <[EMAIL PROTECTED]> wrote:
> Exactly!   I was going to use the MANIFEST Class-Path: attribute as an
> example in my last message, but I wasn't sure if it was evaluated for
> any jar other than the original target jar.
>
> On 9/28/05, Craig McClanahan <[EMAIL PROTECTED]> wrote:
> >  Some sort of dependency declaration is going to be necessary for solving
> > this problem completely.  There's precedent in the way that a JAR file can
> > declare dependencies on other JARs in it's MANIFEST.MF file ... something
> > like that should be explored here as well.
>
>

--

http://www.irian.at
Your JSF powerhouse -
JSF Trainings in English and German

RE: Fwd: multiple component jars

2005-09-28 Thread Andrew Robinson

There is always adding another XML config file to WEB-INF using a new XSD
for validation. Each element could reference a file in a jar or on the file
system relative to the WEB-INF directory. If the container doesn't find this
configuration file (with a standard file name, and/or have it as a
configuration value in web.xml), then it would default to current behavior. 

Perhaps something like:

faces-config.xml

Tomahawk.jar
meta-inf/faces-config.xml

-Original Message-
From: Martin Marinschek [mailto:[EMAIL PROTECTED] 
Sent: Wednesday, September 28, 2005 1:51 PM
To: Ed Burns
Cc: MyFaces Discussion; Mike Kienenberger
Subject: Re: Fwd: multiple component jars

You are right - simple naming rules are great! But RoRs naming rules
try to make it simpler for the user - this one makes it more complex,
as he has to take care of this ordering.

The users won't want to rename the libs to make this work...

I have carefully thought about it, and I think we will end up with the
need for a "priority", just like the Z-INDEX in CSS. With all its
problems, with all its advantages.

@Mike: customizing the comparator doesn't help anything - you finally
land at the problem again that every lib can provide it's comparator -
which one is wrapping which, which one takes precedence?

regards,

Martin

P.S.: apart from this, I think the real advantage of RoR is that you
don't have to restart your ServletContainer on a small change...

On 9/28/05, Ed Burns <[EMAIL PROTECTED]> wrote:
> >>>>> On Wed, 28 Sep 2005 20:57:34 +0200, Martin Marinschek
<[EMAIL PROTECTED]> said:
>
> MM> What happens if we (or the user) needs to change the ordering?
> MM> e.g. myfaces-sandbox.jar needs to make sure that the faces-config.xml
> MM> of myfaces-tomahawk.jar is parsed first.
>
> MM> We probably won't rename tomahawk to aaa_tomahawk ;)
>
> *You* won't, but the end user can, if it matters that much.  Granted,
> it seems hacky, and it is, but it is very simple.  How does RoR solve
> this sort of thing?  They seem to be all about simple naming rules,
> right?  Let's hear some other ideas!
>
> Ed
>
> --
> | [EMAIL PROTECTED]  | {home: 407 869 9587, office: 408 884 9519 OR x31640}
> | homepage: | http://purl.oclc.org/NET/edburns/
> | aim: edburns0sunw | iim: [EMAIL PROTECTED]
>
>

--

http://www.irian.at
Your JSF powerhouse -
JSF Trainings in English and German

Re: Fwd: multiple component jars

Exactly!   I was going to use the MANIFEST Class-Path: attribute as an
example in my last message, but I wasn't sure if it was evaluated for
any jar other than the original target jar.

On 9/28/05, Craig McClanahan <[EMAIL PROTECTED]> wrote:
>  Some sort of dependency declaration is going to be necessary for solving
> this problem completely.  There's precedent in the way that a JAR file can
> declare dependencies on other JARs in it's MANIFEST.MF file ... something
> like that should be explored here as well.

Re: Fwd: multiple component jars

2005-09-28 Thread Craig McClanahan

On 9/28/05, Martin Marinschek <[EMAIL PROTECTED]> wrote:
You are right - simple naming rules are great! But RoRs naming rulestry to make it simpler for the user - this one makes it more complex,as he has to take care of this ordering.The users won't want to rename the libs to make this work...

+1. But I can see Ed's point that doing something like this is still better than doing nothing.
I have carefully thought about it, and I think we will end up with theneed for a "priority", just like the Z-INDEX in CSS. With all its
problems, with all its advantages.
I don't think this solution is at all sufficient, though ... at least
if you store it inside the jar file for a particular component
library. As a developer of a third party component library
yourselves, what value should MyFaces pick for the Tomahawk
components? What happens to the build process of every
application using those components if the value is changed later?
What happens if a library that Tomahawk might depend on changes *their*
value so that it's suddenly higher than the Tomahawk one, instead of
lower?
@Mike: customizing the comparator doesn't help anything - you finallyland at the problem again that every lib can provide it's comparator -
which one is wrapping which, which one takes precedence?
Some sort of dependency declaration is going to be necessary for
solving this problem completely. There's precedent in the way
that a JAR file can declare dependencies on other JARs in it's
MANIFEST.MF file ... something like that should be explored here as
well.
regards,MartinP.S.: apart from this, I think the real advantage of RoR is that you
don't have to restart your ServletContainer on a small change...
If your development environment requires you to restart the entire
container on simple changes, you need a new development environment
:-). That's not to say we should still work on reducing the
number of times you have to redeploy the application you're currently
working on -- indeed, the fact that JSP pages recompile themselves on
demand shows that at least portions of the underlying problem were
solved ... five years ago !

Craig

Re: Fwd: multiple component jars

The problem with something like "priority" is that it either requires
an absolute priority scale, or another configuration file with an
option like load-on-startup specified for every jar file used.

What really needs to be done is a specification of dependencies.

jar A needs to be able to specify that it's dependent on jar B, C, and
D being processed first.   This keeps things relative and doesn't
force either the user or the jar developer from having to specify
(and, more importantly, understand) the individual loading
dependencies for every jar that might be used.

I think it could be something as simple as a list of dependencies
stored somewhere.   The loader itself would be responsible for merging
all of the lists into a "safe" loading order (or throwing an exception
if there are dependency cycles).   I also think that using the jar
names is unsafe, and using the manifest's "Implementation-Title:" (or
something else that's not subject to arbitrary renaming) would be
better.

For those jars that don't specify a dependency order, it could fall
back to the Issue #:121 loading (alphabetical by file name)

On 9/28/05, Martin Marinschek <[EMAIL PROTECTED]> wrote:
> You are right - simple naming rules are great! But RoRs naming rules
> try to make it simpler for the user - this one makes it more complex,
> as he has to take care of this ordering.
>
> The users won't want to rename the libs to make this work...
>
> I have carefully thought about it, and I think we will end up with the
> need for a "priority", just like the Z-INDEX in CSS. With all its
> problems, with all its advantages.
>
> @Mike: customizing the comparator doesn't help anything - you finally
> land at the problem again that every lib can provide it's comparator -
> which one is wrapping which, which one takes precedence?
>
> regards,
>
> Martin
>
> P.S.: apart from this, I think the real advantage of RoR is that you
> don't have to restart your ServletContainer on a small change...
>
> On 9/28/05, Ed Burns <[EMAIL PROTECTED]> wrote:
> > > On Wed, 28 Sep 2005 20:57:34 +0200, Martin Marinschek <[EMAIL 
> > > PROTECTED]> said:
> >
> > MM> What happens if we (or the user) needs to change the ordering?
> > MM> e.g. myfaces-sandbox.jar needs to make sure that the faces-config.xml
> > MM> of myfaces-tomahawk.jar is parsed first.
> >
> > MM> We probably won't rename tomahawk to aaa_tomahawk ;)
> >
> > *You* won't, but the end user can, if it matters that much.  Granted,
> > it seems hacky, and it is, but it is very simple.  How does RoR solve
> > this sort of thing?  They seem to be all about simple naming rules,
> > right?  Let's hear some other ideas!
> >
> > Ed
> >
> > --
> > | [EMAIL PROTECTED]  | {home: 407 869 9587, office: 408 884 9519 OR x31640}
> > | homepage: | http://purl.oclc.org/NET/edburns/
> > | aim: edburns0sunw | iim: [EMAIL PROTECTED]
> >
> >
>
>
> --
>
> http://www.irian.at
> Your JSF powerhouse -
> JSF Trainings in English and German
>

Re: Fwd: multiple component jars

You are right - simple naming rules are great! But RoRs naming rules
try to make it simpler for the user - this one makes it more complex,
as he has to take care of this ordering.

The users won't want to rename the libs to make this work...

I have carefully thought about it, and I think we will end up with the
need for a "priority", just like the Z-INDEX in CSS. With all its
problems, with all its advantages.

@Mike: customizing the comparator doesn't help anything - you finally
land at the problem again that every lib can provide it's comparator -
which one is wrapping which, which one takes precedence?

regards,

Martin

P.S.: apart from this, I think the real advantage of RoR is that you
don't have to restart your ServletContainer on a small change...

On 9/28/05, Ed Burns <[EMAIL PROTECTED]> wrote:
> > On Wed, 28 Sep 2005 20:57:34 +0200, Martin Marinschek <[EMAIL 
> > PROTECTED]> said:
>
> MM> What happens if we (or the user) needs to change the ordering?
> MM> e.g. myfaces-sandbox.jar needs to make sure that the faces-config.xml
> MM> of myfaces-tomahawk.jar is parsed first.
>
> MM> We probably won't rename tomahawk to aaa_tomahawk ;)
>
> *You* won't, but the end user can, if it matters that much.  Granted,
> it seems hacky, and it is, but it is very simple.  How does RoR solve
> this sort of thing?  They seem to be all about simple naming rules,
> right?  Let's hear some other ideas!
>
> Ed
>
> --
> | [EMAIL PROTECTED]  | {home: 407 869 9587, office: 408 884 9519 OR x31640}
> | homepage: | http://purl.oclc.org/NET/edburns/
> | aim: edburns0sunw | iim: [EMAIL PROTECTED]
>
>

--

http://www.irian.at
Your JSF powerhouse -
JSF Trainings in English and German

Re: Fwd: multiple component jars

2005-09-28 Thread Ed Burns

> On Wed, 28 Sep 2005 20:57:34 +0200, Martin Marinschek <[EMAIL PROTECTED]> 
> said:

MM> What happens if we (or the user) needs to change the ordering?
MM> e.g. myfaces-sandbox.jar needs to make sure that the faces-config.xml
MM> of myfaces-tomahawk.jar is parsed first.

MM> We probably won't rename tomahawk to aaa_tomahawk ;)

*You* won't, but the end user can, if it matters that much.  Granted,
it seems hacky, and it is, but it is very simple.  How does RoR solve
this sort of thing?  They seem to be all about simple naming rules,
right?  Let's hear some other ideas!

Ed

-- 
| [EMAIL PROTECTED]  | {home: 407 869 9587, office: 408 884 9519 OR x31640}
| homepage: | http://purl.oclc.org/NET/edburns/
| aim: edburns0sunw | iim: [EMAIL PROTECTED]

Re: Fwd: multiple component jars

What happens if we (or the user) needs to change the ordering?

e.g. myfaces-sandbox.jar needs to make sure that the faces-config.xml
of myfaces-tomahawk.jar is parsed first.

We probably won't rename tomahawk to aaa_tomahawk ;)

regards,

Martin

On 9/28/05, Ed Burns <[EMAIL PROTECTED]> wrote:
> > On Wed, 28 Sep 2005 20:16:57 +0200, Martin Marinschek <[EMAIL 
> > PROTECTED]> said:
>
> MM> Hmmm,
> MM> I'll try to include Ed on this discussion - wonder what he thinks on this.
>
> MM> @Ed: We have discussed how your proposed solution to the ordering
> MM> problem of the faces-config.xml files would also solve the problem
> MM> that a user might need to reorder them to fix problems occuring by a
> MM> wrong load order?
>
> MM> If I understand your solution right, the jar-files would always be
> MM> ordered by their name - which might not always be the perfect solution
> MM> we would want to have.
>
> Yes, that's right.  Ordered by name.  I know it's not optimal, but it
> does get the job done.
>
> Ed
>
> --
> | [EMAIL PROTECTED]  | {home: 407 869 9587, office: 408 884 9519 OR x31640}
> | homepage: | http://purl.oclc.org/NET/edburns/
> | aim: edburns0sunw | iim: [EMAIL PROTECTED]
>
>


--

http://www.irian.at
Your JSF powerhouse -
JSF Trainings in English and German

Re: Fwd: multiple component jars

2005-09-28 Thread Ed Burns

> On Wed, 28 Sep 2005 20:16:57 +0200, Martin Marinschek <[EMAIL PROTECTED]> 
> said:

MM> Hmmm,
MM> I'll try to include Ed on this discussion - wonder what he thinks on this.

MM> @Ed: We have discussed how your proposed solution to the ordering
MM> problem of the faces-config.xml files would also solve the problem
MM> that a user might need to reorder them to fix problems occuring by a
MM> wrong load order?

MM> If I understand your solution right, the jar-files would always be
MM> ordered by their name - which might not always be the perfect solution
MM> we would want to have.

Yes, that's right.  Ordered by name.  I know it's not optimal, but it
does get the job done.

Ed

-- 
| [EMAIL PROTECTED]  | {home: 407 869 9587, office: 408 884 9519 OR x31640}
| homepage: | http://purl.oclc.org/NET/edburns/
| aim: edburns0sunw | iim: [EMAIL PROTECTED]

Fwd: multiple component jars

Hmmm,

I'll try to include Ed on this discussion - wonder what he thinks on this.

@Ed: We have discussed how your proposed solution to the ordering
problem of the faces-config.xml files would also solve the problem
that a user might need to reorder them to fix problems occuring by a
wrong load order?

If I understand your solution right, the jar-files would always be
ordered by their name - which might not always be the perfect solution
we would want to have.

Have I misunderstood you somehow?

regards,

Martin

P.S.: Find below what Mike and me have been discussing - about
customizing the comparator you are proposing...

On 9/28/05, Mike Kienenberger <[EMAIL PROTECTED]> wrote:
> Chainable probably wasn't the right word.  I was originally thinking
> of wrapping like ViewHandler or NavigationManager, but by the time I
> was done writing the message, I didn't see how it could work that way.
>  Probably just adding in all of the comparators and doing some kind of
> dependency ordering may make more sense.   There's still some
> hand-waving involved here.  The concept is good, but the
> inplementation is still pretty vague.
>
> I also think this is going to need to be based on something other than
> the jar names.
> Otherwise, renaming your jar to tomahawk-2005-09-28 is going to break things.
> Maybe the "Implementation-Title:" field in the MANIFEST?  Is that possible?
>
> On 9/28/05, Martin Marinschek <[EMAIL PROTECTED]> wrote:
> > Nice!
> >
> > But how would we make sure that Alex' comparator wraps the sandbox
> > comparator wraps the tomahawk comparator?
> >
> > regards,
> >
> > Martin
> >
> > On 9/28/05, Mike Kienenberger <[EMAIL PROTECTED]> wrote:
> > > That's a pretty interesting idea.  Can we make it chainable?
> > >
> > > Ie, tomahawk adds a comparator that requires that myfaces-impl is loaded 
> > > first.
> > > sandbox adds a comparator that requires that tomahawk is loaded.
> > > Alexander adds a comparator that requires that tomahawk is loaded before 
> > > JarX.
> > >
> > > It'd be best if it were done in such a way that every jar can specify
> > > its own ordering dependencies.
> > >
> > > On 9/28/05, Martin Marinschek <[EMAIL PROTECTED]> wrote:
> > > > It might be good to be able to "hook in" a customized comparator for
> > > > this proposed map- we could then easily change the order of the loaded
> > > > chars by providing a different comparator implementation.
> > > >
> > > > wdyt?
> > > >
> > > > regards,
> > > >
> > > > Martin
> > > >
> > > > On 9/28/05, Mike Kienenberger <[EMAIL PROTECTED]> wrote:
> > > > > Since the ordering is currently unspecified, and since 1.2 is a ways
> > > > > off for MyFaces, it seems to me that there's nothing stopping the
> > > > > MyFaces project from imposing our own ordering system on the loading
> > > > > process under JSF 1.1.   And if it's demonstrated to be a good way of
> > > > > doing things, perhaps it'll influence the direction of JSF
> > > > > 1.2/2.0/etc.
> > > > >
> > > > > I don't think we want to be renaming our jar files to
> > > > > "a-myfaces-tomahawk.jar"
> > > > >
> > > > > On 9/28/05, Martin Marinschek <[EMAIL PROTECTED]> wrote:
> > > > > > Cool!
> > > > > >
> > > > > > Yes, we do have a great expert group there ;)
> > > > > >
> > > > > > I don't fully understand the proposed solution, though.
> > > > > >
> > > > > > It will make sure that the jars are loaded in a certain order, and
> > > > > > that order will be the name of the jar-files.
> > > > > >
> > > > > > How are we able to change this with the proposed scheme?
> > > > > >
> > > > > > Or am I completely overlooking something obvious?
> > > > > >
> > > > > > regards,
> > > > > >
> > > > > > Martin
> > > > > >
> > > > > > On 9/28/05, Jesse Alexander (KBSA 21) <[EMAIL PROTECTED]> wrote:
> > > > > > >   -Original Message-
> > > > > > >   too late for 1.2, I suppose!
> > > > > > >
> > > > > > >   exactly the right time for 2.0...
> > > > > > >
> > > > > > >   I think there is something like an issue tracker on 
> > > > > > > dev.java.net.
> > > > > > >   -/Original Message-
> > > > > > >
> > > > > > > Not really. Ed Burns has answered this:
> > > > > > >
> > > > > > > -Original Message-
> > > > > > > Yes, this problem is real, but we may be able to solve it in 1.2. 
> > > > > > >  As
> > > > > > > you may know, the webtier specs tend to ignore the config file 
> > > > > > > ordering
> > > > > > > problem.  In this case, we don't know the order in which the jar 
> > > > > > > files
> > > > > > > containing the faces-config files will be encountered.
> > > > > > >
> > > > > > > I think I have a simple solution.
> > > > > > >
> > > > > > > I've filed it as
> > > > > > >  > > > > > > =121>
> > > > > > > and will bring it to the EG.
> > > > > > > -/Original Message-
> > > > > > >
> > > > > > > I'd say: lightning fast response and in the best possible 
> > > > > > > direction.
> > > >

Re: multiple component jars

Hmmm,

I'll try to include Ed on this discussion - wonder what he thinks on this.

@Ed: We have discussed how your proposed solution to the ordering
problem of the faces-config.xml files would also solve the problem
that a user might need to reorder them to fix problems occuring by a
wrong load order?

If I understand your solution right, the jar-files would always be
ordered by their name - which might not always be the perfect solution
we would want to have.

Have I misunderstood you somehow?

regards,

Martin

P.S.: Find below what Mike and me have been discussing - about
customizing the comparator you are proposing...

On 9/28/05, Mike Kienenberger <[EMAIL PROTECTED]> wrote:
> Chainable probably wasn't the right word.  I was originally thinking
> of wrapping like ViewHandler or NavigationManager, but by the time I
> was done writing the message, I didn't see how it could work that way.
>  Probably just adding in all of the comparators and doing some kind of
> dependency ordering may make more sense.   There's still some
> hand-waving involved here.  The concept is good, but the
> inplementation is still pretty vague.
>
> I also think this is going to need to be based on something other than
> the jar names.
> Otherwise, renaming your jar to tomahawk-2005-09-28 is going to break things.
> Maybe the "Implementation-Title:" field in the MANIFEST?  Is that possible?
>
> On 9/28/05, Martin Marinschek <[EMAIL PROTECTED]> wrote:
> > Nice!
> >
> > But how would we make sure that Alex' comparator wraps the sandbox
> > comparator wraps the tomahawk comparator?
> >
> > regards,
> >
> > Martin
> >
> > On 9/28/05, Mike Kienenberger <[EMAIL PROTECTED]> wrote:
> > > That's a pretty interesting idea.  Can we make it chainable?
> > >
> > > Ie, tomahawk adds a comparator that requires that myfaces-impl is loaded 
> > > first.
> > > sandbox adds a comparator that requires that tomahawk is loaded.
> > > Alexander adds a comparator that requires that tomahawk is loaded before 
> > > JarX.
> > >
> > > It'd be best if it were done in such a way that every jar can specify
> > > its own ordering dependencies.
> > >
> > > On 9/28/05, Martin Marinschek <[EMAIL PROTECTED]> wrote:
> > > > It might be good to be able to "hook in" a customized comparator for
> > > > this proposed map- we could then easily change the order of the loaded
> > > > chars by providing a different comparator implementation.
> > > >
> > > > wdyt?
> > > >
> > > > regards,
> > > >
> > > > Martin
> > > >
> > > > On 9/28/05, Mike Kienenberger <[EMAIL PROTECTED]> wrote:
> > > > > Since the ordering is currently unspecified, and since 1.2 is a ways
> > > > > off for MyFaces, it seems to me that there's nothing stopping the
> > > > > MyFaces project from imposing our own ordering system on the loading
> > > > > process under JSF 1.1.   And if it's demonstrated to be a good way of
> > > > > doing things, perhaps it'll influence the direction of JSF
> > > > > 1.2/2.0/etc.
> > > > >
> > > > > I don't think we want to be renaming our jar files to
> > > > > "a-myfaces-tomahawk.jar"
> > > > >
> > > > > On 9/28/05, Martin Marinschek <[EMAIL PROTECTED]> wrote:
> > > > > > Cool!
> > > > > >
> > > > > > Yes, we do have a great expert group there ;)
> > > > > >
> > > > > > I don't fully understand the proposed solution, though.
> > > > > >
> > > > > > It will make sure that the jars are loaded in a certain order, and
> > > > > > that order will be the name of the jar-files.
> > > > > >
> > > > > > How are we able to change this with the proposed scheme?
> > > > > >
> > > > > > Or am I completely overlooking something obvious?
> > > > > >
> > > > > > regards,
> > > > > >
> > > > > > Martin
> > > > > >
> > > > > > On 9/28/05, Jesse Alexander (KBSA 21) <[EMAIL PROTECTED]> wrote:
> > > > > > >   -Original Message-
> > > > > > >   too late for 1.2, I suppose!
> > > > > > >
> > > > > > >   exactly the right time for 2.0...
> > > > > > >
> > > > > > >   I think there is something like an issue tracker on 
> > > > > > > dev.java.net.
> > > > > > >   -/Original Message-
> > > > > > >
> > > > > > > Not really. Ed Burns has answered this:
> > > > > > >
> > > > > > > -Original Message-
> > > > > > > Yes, this problem is real, but we may be able to solve it in 1.2. 
> > > > > > >  As
> > > > > > > you may know, the webtier specs tend to ignore the config file 
> > > > > > > ordering
> > > > > > > problem.  In this case, we don't know the order in which the jar 
> > > > > > > files
> > > > > > > containing the faces-config files will be encountered.
> > > > > > >
> > > > > > > I think I have a simple solution.
> > > > > > >
> > > > > > > I've filed it as
> > > > > > >  > > > > > > =121>
> > > > > > > and will bring it to the EG.
> > > > > > > -/Original Message-
> > > > > > >
> > > > > > > I'd say: lightning fast response and in the best possible 
> > > > > > > direction.
> > > >

Re: multiple component jars

Chainable probably wasn't the right word.  I was originally thinking
of wrapping like ViewHandler or NavigationManager, but by the time I
was done writing the message, I didn't see how it could work that way.
 Probably just adding in all of the comparators and doing some kind of
dependency ordering may make more sense.   There's still some
hand-waving involved here.  The concept is good, but the
inplementation is still pretty vague.

I also think this is going to need to be based on something other than
the jar names.
Otherwise, renaming your jar to tomahawk-2005-09-28 is going to break things.
Maybe the "Implementation-Title:" field in the MANIFEST?  Is that possible?

On 9/28/05, Martin Marinschek <[EMAIL PROTECTED]> wrote:
> Nice!
>
> But how would we make sure that Alex' comparator wraps the sandbox
> comparator wraps the tomahawk comparator?
>
> regards,
>
> Martin
>
> On 9/28/05, Mike Kienenberger <[EMAIL PROTECTED]> wrote:
> > That's a pretty interesting idea.  Can we make it chainable?
> >
> > Ie, tomahawk adds a comparator that requires that myfaces-impl is loaded 
> > first.
> > sandbox adds a comparator that requires that tomahawk is loaded.
> > Alexander adds a comparator that requires that tomahawk is loaded before 
> > JarX.
> >
> > It'd be best if it were done in such a way that every jar can specify
> > its own ordering dependencies.
> >
> > On 9/28/05, Martin Marinschek <[EMAIL PROTECTED]> wrote:
> > > It might be good to be able to "hook in" a customized comparator for
> > > this proposed map- we could then easily change the order of the loaded
> > > chars by providing a different comparator implementation.
> > >
> > > wdyt?
> > >
> > > regards,
> > >
> > > Martin
> > >
> > > On 9/28/05, Mike Kienenberger <[EMAIL PROTECTED]> wrote:
> > > > Since the ordering is currently unspecified, and since 1.2 is a ways
> > > > off for MyFaces, it seems to me that there's nothing stopping the
> > > > MyFaces project from imposing our own ordering system on the loading
> > > > process under JSF 1.1.   And if it's demonstrated to be a good way of
> > > > doing things, perhaps it'll influence the direction of JSF
> > > > 1.2/2.0/etc.
> > > >
> > > > I don't think we want to be renaming our jar files to
> > > > "a-myfaces-tomahawk.jar"
> > > >
> > > > On 9/28/05, Martin Marinschek <[EMAIL PROTECTED]> wrote:
> > > > > Cool!
> > > > >
> > > > > Yes, we do have a great expert group there ;)
> > > > >
> > > > > I don't fully understand the proposed solution, though.
> > > > >
> > > > > It will make sure that the jars are loaded in a certain order, and
> > > > > that order will be the name of the jar-files.
> > > > >
> > > > > How are we able to change this with the proposed scheme?
> > > > >
> > > > > Or am I completely overlooking something obvious?
> > > > >
> > > > > regards,
> > > > >
> > > > > Martin
> > > > >
> > > > > On 9/28/05, Jesse Alexander (KBSA 21) <[EMAIL PROTECTED]> wrote:
> > > > > >   -Original Message-
> > > > > >   too late for 1.2, I suppose!
> > > > > >
> > > > > >   exactly the right time for 2.0...
> > > > > >
> > > > > >   I think there is something like an issue tracker on dev.java.net.
> > > > > >   -/Original Message-
> > > > > >
> > > > > > Not really. Ed Burns has answered this:
> > > > > >
> > > > > > -Original Message-
> > > > > > Yes, this problem is real, but we may be able to solve it in 1.2.  
> > > > > > As
> > > > > > you may know, the webtier specs tend to ignore the config file 
> > > > > > ordering
> > > > > > problem.  In this case, we don't know the order in which the jar 
> > > > > > files
> > > > > > containing the faces-config files will be encountered.
> > > > > >
> > > > > > I think I have a simple solution.
> > > > > >
> > > > > > I've filed it as
> > > > > >  > > > > > =121>
> > > > > > and will bring it to the EG.
> > > > > > -/Original Message-
> > > > > >
> > > > > > I'd say: lightning fast response and in the best possible direction.
> > > > > >
> > > > > > kudos to the EG!!!
> > > > > >
> > > > > > regards
> > > > > > Alexander
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > > > --
> > > > >
> > > > > http://www.irian.at
> > > > > Your JSF powerhouse -
> > > > > JSF Trainings in English and German
> > > > >
> > > >
> > >
> > >
> > > --
> > >
> > > http://www.irian.at
> > > Your JSF powerhouse -
> > > JSF Trainings in English and German
> > >
> >
>
>
> --
>
> http://www.irian.at
> Your JSF powerhouse -
> JSF Trainings in English and German
>

Re: multiple component jars

Nice!

But how would we make sure that Alex' comparator wraps the sandbox
comparator wraps the tomahawk comparator?

regards,

Martin

On 9/28/05, Mike Kienenberger <[EMAIL PROTECTED]> wrote:
> That's a pretty interesting idea.  Can we make it chainable?
>
> Ie, tomahawk adds a comparator that requires that myfaces-impl is loaded 
> first.
> sandbox adds a comparator that requires that tomahawk is loaded.
> Alexander adds a comparator that requires that tomahawk is loaded before JarX.
>
> It'd be best if it were done in such a way that every jar can specify
> its own ordering dependencies.
>
> On 9/28/05, Martin Marinschek <[EMAIL PROTECTED]> wrote:
> > It might be good to be able to "hook in" a customized comparator for
> > this proposed map- we could then easily change the order of the loaded
> > chars by providing a different comparator implementation.
> >
> > wdyt?
> >
> > regards,
> >
> > Martin
> >
> > On 9/28/05, Mike Kienenberger <[EMAIL PROTECTED]> wrote:
> > > Since the ordering is currently unspecified, and since 1.2 is a ways
> > > off for MyFaces, it seems to me that there's nothing stopping the
> > > MyFaces project from imposing our own ordering system on the loading
> > > process under JSF 1.1.   And if it's demonstrated to be a good way of
> > > doing things, perhaps it'll influence the direction of JSF
> > > 1.2/2.0/etc.
> > >
> > > I don't think we want to be renaming our jar files to
> > > "a-myfaces-tomahawk.jar"
> > >
> > > On 9/28/05, Martin Marinschek <[EMAIL PROTECTED]> wrote:
> > > > Cool!
> > > >
> > > > Yes, we do have a great expert group there ;)
> > > >
> > > > I don't fully understand the proposed solution, though.
> > > >
> > > > It will make sure that the jars are loaded in a certain order, and
> > > > that order will be the name of the jar-files.
> > > >
> > > > How are we able to change this with the proposed scheme?
> > > >
> > > > Or am I completely overlooking something obvious?
> > > >
> > > > regards,
> > > >
> > > > Martin
> > > >
> > > > On 9/28/05, Jesse Alexander (KBSA 21) <[EMAIL PROTECTED]> wrote:
> > > > >   -Original Message-
> > > > >   too late for 1.2, I suppose!
> > > > >
> > > > >   exactly the right time for 2.0...
> > > > >
> > > > >   I think there is something like an issue tracker on dev.java.net.
> > > > >   -/Original Message-
> > > > >
> > > > > Not really. Ed Burns has answered this:
> > > > >
> > > > > -Original Message-
> > > > > Yes, this problem is real, but we may be able to solve it in 1.2.  As
> > > > > you may know, the webtier specs tend to ignore the config file 
> > > > > ordering
> > > > > problem.  In this case, we don't know the order in which the jar files
> > > > > containing the faces-config files will be encountered.
> > > > >
> > > > > I think I have a simple solution.
> > > > >
> > > > > I've filed it as
> > > > >  > > > > =121>
> > > > > and will bring it to the EG.
> > > > > -/Original Message-
> > > > >
> > > > > I'd say: lightning fast response and in the best possible direction.
> > > > >
> > > > > kudos to the EG!!!
> > > > >
> > > > > regards
> > > > > Alexander
> > > > >
> > > > >
> > > >
> > > >
> > > > --
> > > >
> > > > http://www.irian.at
> > > > Your JSF powerhouse -
> > > > JSF Trainings in English and German
> > > >
> > >
> >
> >
> > --
> >
> > http://www.irian.at
> > Your JSF powerhouse -
> > JSF Trainings in English and German
> >
>


--

http://www.irian.at
Your JSF powerhouse -
JSF Trainings in English and German

Re: multiple component jars

That's a pretty interesting idea.  Can we make it chainable?

Ie, tomahawk adds a comparator that requires that myfaces-impl is loaded first.
sandbox adds a comparator that requires that tomahawk is loaded.
Alexander adds a comparator that requires that tomahawk is loaded before JarX.

It'd be best if it were done in such a way that every jar can specify
its own ordering dependencies.

On 9/28/05, Martin Marinschek <[EMAIL PROTECTED]> wrote:
> It might be good to be able to "hook in" a customized comparator for
> this proposed map- we could then easily change the order of the loaded
> chars by providing a different comparator implementation.
>
> wdyt?
>
> regards,
>
> Martin
>
> On 9/28/05, Mike Kienenberger <[EMAIL PROTECTED]> wrote:
> > Since the ordering is currently unspecified, and since 1.2 is a ways
> > off for MyFaces, it seems to me that there's nothing stopping the
> > MyFaces project from imposing our own ordering system on the loading
> > process under JSF 1.1.   And if it's demonstrated to be a good way of
> > doing things, perhaps it'll influence the direction of JSF
> > 1.2/2.0/etc.
> >
> > I don't think we want to be renaming our jar files to
> > "a-myfaces-tomahawk.jar"
> >
> > On 9/28/05, Martin Marinschek <[EMAIL PROTECTED]> wrote:
> > > Cool!
> > >
> > > Yes, we do have a great expert group there ;)
> > >
> > > I don't fully understand the proposed solution, though.
> > >
> > > It will make sure that the jars are loaded in a certain order, and
> > > that order will be the name of the jar-files.
> > >
> > > How are we able to change this with the proposed scheme?
> > >
> > > Or am I completely overlooking something obvious?
> > >
> > > regards,
> > >
> > > Martin
> > >
> > > On 9/28/05, Jesse Alexander (KBSA 21) <[EMAIL PROTECTED]> wrote:
> > > >   -Original Message-
> > > >   too late for 1.2, I suppose!
> > > >
> > > >   exactly the right time for 2.0...
> > > >
> > > >   I think there is something like an issue tracker on dev.java.net.
> > > >   -/Original Message-
> > > >
> > > > Not really. Ed Burns has answered this:
> > > >
> > > > -Original Message-
> > > > Yes, this problem is real, but we may be able to solve it in 1.2.  As
> > > > you may know, the webtier specs tend to ignore the config file ordering
> > > > problem.  In this case, we don't know the order in which the jar files
> > > > containing the faces-config files will be encountered.
> > > >
> > > > I think I have a simple solution.
> > > >
> > > > I've filed it as
> > > >  > > > =121>
> > > > and will bring it to the EG.
> > > > -/Original Message-
> > > >
> > > > I'd say: lightning fast response and in the best possible direction.
> > > >
> > > > kudos to the EG!!!
> > > >
> > > > regards
> > > > Alexander
> > > >
> > > >
> > >
> > >
> > > --
> > >
> > > http://www.irian.at
> > > Your JSF powerhouse -
> > > JSF Trainings in English and German
> > >
> >
>
>
> --
>
> http://www.irian.at
> Your JSF powerhouse -
> JSF Trainings in English and German
>

Re: multiple component jars

It might be good to be able to "hook in" a customized comparator for
this proposed map- we could then easily change the order of the loaded
chars by providing a different comparator implementation.

wdyt?

regards,

Martin

On 9/28/05, Mike Kienenberger <[EMAIL PROTECTED]> wrote:
> Since the ordering is currently unspecified, and since 1.2 is a ways
> off for MyFaces, it seems to me that there's nothing stopping the
> MyFaces project from imposing our own ordering system on the loading
> process under JSF 1.1.   And if it's demonstrated to be a good way of
> doing things, perhaps it'll influence the direction of JSF
> 1.2/2.0/etc.
>
> I don't think we want to be renaming our jar files to
> "a-myfaces-tomahawk.jar"
>
> On 9/28/05, Martin Marinschek <[EMAIL PROTECTED]> wrote:
> > Cool!
> >
> > Yes, we do have a great expert group there ;)
> >
> > I don't fully understand the proposed solution, though.
> >
> > It will make sure that the jars are loaded in a certain order, and
> > that order will be the name of the jar-files.
> >
> > How are we able to change this with the proposed scheme?
> >
> > Or am I completely overlooking something obvious?
> >
> > regards,
> >
> > Martin
> >
> > On 9/28/05, Jesse Alexander (KBSA 21) <[EMAIL PROTECTED]> wrote:
> > >   -Original Message-
> > >   too late for 1.2, I suppose!
> > >
> > >   exactly the right time for 2.0...
> > >
> > >   I think there is something like an issue tracker on dev.java.net.
> > >   -/Original Message-
> > >
> > > Not really. Ed Burns has answered this:
> > >
> > > -Original Message-
> > > Yes, this problem is real, but we may be able to solve it in 1.2.  As
> > > you may know, the webtier specs tend to ignore the config file ordering
> > > problem.  In this case, we don't know the order in which the jar files
> > > containing the faces-config files will be encountered.
> > >
> > > I think I have a simple solution.
> > >
> > > I've filed it as
> > >  > > =121>
> > > and will bring it to the EG.
> > > -/Original Message-
> > >
> > > I'd say: lightning fast response and in the best possible direction.
> > >
> > > kudos to the EG!!!
> > >
> > > regards
> > > Alexander
> > >
> > >
> >
> >
> > --
> >
> > http://www.irian.at
> > Your JSF powerhouse -
> > JSF Trainings in English and German
> >
>


--

http://www.irian.at
Your JSF powerhouse -
JSF Trainings in English and German

Re: multiple component jars

Since the ordering is currently unspecified, and since 1.2 is a ways
off for MyFaces, it seems to me that there's nothing stopping the
MyFaces project from imposing our own ordering system on the loading
process under JSF 1.1.   And if it's demonstrated to be a good way of
doing things, perhaps it'll influence the direction of JSF
1.2/2.0/etc.

I don't think we want to be renaming our jar files to
"a-myfaces-tomahawk.jar"

On 9/28/05, Martin Marinschek <[EMAIL PROTECTED]> wrote:
> Cool!
>
> Yes, we do have a great expert group there ;)
>
> I don't fully understand the proposed solution, though.
>
> It will make sure that the jars are loaded in a certain order, and
> that order will be the name of the jar-files.
>
> How are we able to change this with the proposed scheme?
>
> Or am I completely overlooking something obvious?
>
> regards,
>
> Martin
>
> On 9/28/05, Jesse Alexander (KBSA 21) <[EMAIL PROTECTED]> wrote:
> >   -Original Message-
> >   too late for 1.2, I suppose!
> >
> >   exactly the right time for 2.0...
> >
> >   I think there is something like an issue tracker on dev.java.net.
> >   -/Original Message-
> >
> > Not really. Ed Burns has answered this:
> >
> > -Original Message-
> > Yes, this problem is real, but we may be able to solve it in 1.2.  As
> > you may know, the webtier specs tend to ignore the config file ordering
> > problem.  In this case, we don't know the order in which the jar files
> > containing the faces-config files will be encountered.
> >
> > I think I have a simple solution.
> >
> > I've filed it as
> >  > =121>
> > and will bring it to the EG.
> > -/Original Message-
> >
> > I'd say: lightning fast response and in the best possible direction.
> >
> > kudos to the EG!!!
> >
> > regards
> > Alexander
> >
> >
>
>
> --
>
> http://www.irian.at
> Your JSF powerhouse -
> JSF Trainings in English and German
>

Re: multiple component jars

Cool!

Yes, we do have a great expert group there ;)

I don't fully understand the proposed solution, though.

It will make sure that the jars are loaded in a certain order, and
that order will be the name of the jar-files.

How are we able to change this with the proposed scheme?

Or am I completely overlooking something obvious?

regards,

Martin

On 9/28/05, Jesse Alexander (KBSA 21) <[EMAIL PROTECTED]> wrote:
>   -Original Message-
>   too late for 1.2, I suppose!
>
>   exactly the right time for 2.0...
>
>   I think there is something like an issue tracker on dev.java.net.
>   -/Original Message-
>
> Not really. Ed Burns has answered this:
>
> -Original Message-
> Yes, this problem is real, but we may be able to solve it in 1.2.  As
> you may know, the webtier specs tend to ignore the config file ordering
> problem.  In this case, we don't know the order in which the jar files
> containing the faces-config files will be encountered.
>
> I think I have a simple solution.
>
> I've filed it as
>  =121>
> and will bring it to the EG.
> -/Original Message-
>
> I'd say: lightning fast response and in the best possible direction.
>
> kudos to the EG!!!
>
> regards
> Alexander
>
>


--

http://www.irian.at
Your JSF powerhouse -
JSF Trainings in English and German

RE: multiple component jars

  -Original Message-
  too late for 1.2, I suppose!

  exactly the right time for 2.0...

  I think there is something like an issue tracker on dev.java.net.
  -/Original Message-

Not really. Ed Burns has answered this:

-Original Message-
Yes, this problem is real, but we may be able to solve it in 1.2.  As
you may know, the webtier specs tend to ignore the config file ordering
problem.  In this case, we don't know the order in which the jar files
containing the faces-config files will be encountered.  

I think I have a simple solution.  

I've filed it as

and will bring it to the EG.
-/Original Message-

I'd say: lightning fast response and in the best possible direction.

kudos to the EG!!!

regards
Alexander

Re: multiple component jars

too late for 1.2, I suppose!

exactly the right time for 2.0...

I think there is something like an issue tracker on dev.java.net.

regards,

Martin

On 9/28/05, Jesse Alexander (KBSA 21) <[EMAIL PROTECTED]> wrote:
> -Original Message-
> No way around this.
> -/Original Message-
> Feared so :(
>
> -Original Message-
> Same problem with PhaseListeners.
> -/Original Message-
> and any other configurable item...
>
> -Original Message-
> Maybe the spec should introduce something like a "priority" (like the
> z-index in CSS) to get round such problems.
> -/Original Message-
> How are we supposed to contact the JSF 1.2 EG to include something this?
> Do they have a "bug-tracker"?
>
> Or are we already too late for such a request?
>
> regards
> Alexander
>


--

http://www.irian.at
Your JSF powerhouse -
JSF Trainings in English and German

RE: multiple component jars

-Original Message-
No way around this.
-/Original Message-
Feared so :(

-Original Message-
Same problem with PhaseListeners.
-/Original Message-
and any other configurable item...

-Original Message-
Maybe the spec should introduce something like a "priority" (like the
z-index in CSS) to get round such problems.
-/Original Message-
How are we supposed to contact the JSF 1.2 EG to include something this?
Do they have a "bug-tracker"?

Or are we already too late for such a request?

regards
Alexander

Re: multiple component jars

No way around this.

Same problem with PhaseListeners.

Maybe the spec should introduce something like a "priority" (like the
z-index in CSS) to get round such problems.

regards,

Martin

On 9/28/05, Jesse Alexander (KBSA 21) <[EMAIL PROTECTED]> wrote:
> Hi
>
> I use some components from the tomahawk collection and have
> written my own components as well.
>
> Now I am in the process of packaging my own components into
> jar-files and have run into a nasty feature of the JSF
> configuration.
> It is nice that each component-jar-file can have its own
> faces-config.xml and in that way add its components to
> the overall JSF runtime configuration. It is also easy
> to replace a single renderer for a componen, just add
> the renderer to the jar-file and "overwrite" the
> renderer-configuration in your own jar-faces-config. This
> works great for renderers delivered by JSF itself. BUT as
> soon as I want to override a renderer from the tomahawk
> components I run into troubles.
>
> The config mechanism first inserts the standard config,
> then adds the jar-faces-config and at the end adds the
> configured (in web.xml) config-files. Unfortunately
> there seems no way to specify the order in which the
> jar-faces-configs are added. Therefor its getting
> difficult to override single definitions (as described
> above) when having more than one jar with custom components.
>
> How do you deal with that problem?
> Alexander
>


--

http://www.irian.at
Your JSF powerhouse -
JSF Trainings in English and German

multiple component jars