-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
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 wou
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,
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
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
ailto:[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 co
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 nec
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.
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
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 e
> 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 wo
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 wou
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 ord
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 ord
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
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 requ
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
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 orderi
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'
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 complete
-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
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-
> F
-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 "prio
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 tomah
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-c
26 matches
Mail list logo
