Require ordering of for loading META-INF/faces-config.xml files from component jar

[Bruno Aranda <br...@gmail.com>]

Hi *,

I've just talked with Ed Burns in IRC and he has told me that he has
implemented the ordering of the loading of the config files [1]. He
has attached the implementation there for ideas.
I am not sure, but this is one of the JSF1.2 things that we could
implement without having to do major changes.

Regards,

Bruno

[1] https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=121

Re: Require ordering of for loading META-INF/faces-config.xml files from component jar

[Mike Kienenberger <mk...@gmail.com>]

I think the point is that it's not yet in the spec like this -- it's
just how the RI is currently implemented -- and now's the time to
insure it doesn't go into the spec :)  Implementing it this way in
MyFaces is a step in the wrong direction for getting the behavior
changed :)

On 12/5/05, Martin Marinschek <ma...@gmail.com> wrote:
> Yes, no one was.
>
> It's a workaround, but it's awkward at least.
>
> Still, it's better than nothing, and if it is in the Spec like this,
> we'll need to implement it.
>
> regards,
>
> Martin
>
> On 12/5/05, Mike Kienenberger <mk...@gmail.com> wrote:
> > -1 for doing it this way.   We've already heard from Ed and Adam that
> > once something becomes "official" in J2EE, there's no deprecating it
> > in the forseeable future, no matter how awful it is.    As Jacob
> > commented, this approach is a hack, and I'd hate to see it become the
> > standard.
> >
> > At the time of the original discussion, we proposed better ways of
> > handling this which should be archived in the mailing list.  (I think
> > Martin and Craig were also involved at the time, and we hammered out a
> > reasonable dependency-handling approach).  I'm not really sure why Ed
> > went with it the way he did because no one else was happy with that
> > approach.
> >
> > On 12/5/05, Bruno Aranda <br...@gmail.com> wrote:
> > > Hi *,
> > >
> > > I've just talked with Ed Burns in IRC and he has told me that he has
> > > implemented the ordering of the loading of the config files [1]. He
> > > has attached the implementation there for ideas.
> > > I am not sure, but this is one of the JSF1.2 things that we could
> > > implement without having to do major changes.
> > >
> > > Regards,
> > >
> > > Bruno
> > >
> > > [1] https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=121
> > >
> >
>
>
> --
>
> http://www.irian.at
>
> Your JSF powerhouse -
> JSF Consulting, Development and
> Courses in English and German
>
> Professional Support for Apache MyFaces
>

Re: Require ordering of for loading META-INF/faces-config.xml files from component jar

[Mike Kienenberger <mk...@gmail.com>]

If I recall, the original use case of it was the need to have a custom
phase listener registered before a tomahawk phase listener was
registered, but we didn't think the end-user should have to make the
tomahawk jar depend on the custom jar manually.

On 12/5/05, Adam Winer <aw...@gmail.com> wrote:
> Mike,
>
> For reference sake, do you have a use case for:
>
> > * "If component library BAR is used in this app, make sure that
> >   I am initialized before it is"
>
> The converse is obvious and common, but I don't have anything at
> my fingertips for this one;  it certainly doesn't surprise me that this
> would be necessary, but I'd feel a bit warmer and fuzzier when we get
> around to taking this up in the EG if I could point at an exact scenario.
>
> Thanks,
> Adam
>

Re: Require ordering of for loading META-INF/faces-config.xml files from component jar

[Adam Winer <aw...@gmail.com>]

Mike,

For reference sake, do you have a use case for:

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

The converse is obvious and common, but I don't have anything at
my fingertips for this one;  it certainly doesn't surprise me that this
would be necessary, but I'd feel a bit warmer and fuzzier when we get
around to taking this up in the EG if I could point at an exact scenario.

Thanks,
Adam

Re: Require ordering of for loading META-INF/faces-config.xml files from component jar

[Simon Kitching <sk...@obsidium.com>]

Mike Kienenberger wrote:
> In the jar's MANIFEST.MF file, create two new attributes, similar to
> the standard jar "Class-Path:" attribute.   These as-of-yet-unnamed
> attributes would represent the two relationships above.
> 
> For those jars that don't specify a dependency order, JSF would fall
> back to the behavior described in Issue #:121 (loading alphabetical by
> file name)

I disagree with this.

For the moment, *all* jars will be missing "dependency order" info, 
because there is no agreement on how to specify this, yes? So we're only 
talking about the second scenario for the moment?

I think it would be better to process such jarfiles in classpath order.

In particular, where some jars are in the container and some are in 
WEB-INF/lib I don't think it's appropriate to apply alphabetical order 
across the entire set of jars; it's just confusing. Also, when a 
faces-config.xml file contains a class NAME, that class will be looked 
up in classpath order, so to process the faces-config.xml files in a 
different order doesn't seem healthy to me.

And as I mentioned before, processing jarfiles in classpath order is 
exactly what MyFaces *already* does.

Have I misunderstood something here?


Regards,

Simon

Re: Require ordering of for loading META-INF/faces-config.xml files from component jar

[Mike Kienenberger <mk...@gmail.com>]

For some reason, I can't find an archive of our original discussion
("multiple component jars" - Sept 28, 2005 -
users@myfaces.apache.org).   So I'll post a summary to this thread.

As previously discussed by:

- Alexander Jesse
- Martin Marinschek
- Mike Kienenberger
- Ed Burns
- Craig McClanahan
- Andrew Robinson

You have to be able to declare dependencies both ways on a 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"

In the jar's MANIFEST.MF file, create two new attributes, similar to
the standard jar "Class-Path:" attribute.   These as-of-yet-unnamed
attributes would represent the two relationships above.

For those jars that don't specify a dependency order, JSF would fall
back to the behavior described in Issue #:121 (loading alphabetical by
file name)


I owe Ed an apology as I was the one that suggested it should fall
back to the above alphabetic behavior in the original thread, so I
don't have any basis for complaining about implementing it that way
other than a bad memory and an argumentative personality :)

So I'm changing my -1 to a +1 -- something needs to be in place as a
default ordering, and that's the best candidate to date.   No reason
why that step can't happen sooner rather than later.


I'm going to add the contents of this message as a comment to issue
121 so it doesn't get lost again.    I'll let it sit out here for
comment for a day first (or whenever the discussion reaches a lull) in
case anything needs to be corrected or updated.

-Mike

Re: Require ordering of for loading META-INF/faces-config.xml files from component jar

[Simon Kitching <sk...@obsidium.com>]

Adam Winer wrote:
> Yes, the desire for a real solution and the permanence of anything
> that does get into the spec was the reason why we deep-sixed
> any hacky fix.  A lot of times - in the world of long-living specs -
> doing nothing is by far the best solution.
> 
> I do think that Ed has a point that MyFaces would do well to
> mimic the JSF 1.2 solution;   it will do no harm (other than
> time spent implementing it).

I'm still puzzled as to why *anything* needs to be implemented..things 
work fine as they are. Just set the CLASSPATH order appropriately. Where 
the CLASSPATH is auto-determined by some tool, add a prefix to the jar 
filenames. I can't imagine a scenario in which this won't work.

Agreed, this isn't a tidy solution long-term, but it seems to achieve 
everything that the proposed hack does.

> 
> My preferred complete solution is something along the lines of
> giving a particular faces-config.xml file an ID (e.g., MyFaces tomahawk
> might be "org.apache.myfaces.tomhawk"), and then stating
> in each file what dependencies it has;  so you could explicitly
> say in a faces-config.xml file "I come *after* Tomahawk";  then you leave
> it up to the implementation to come up with a legit ordering of all the
> identified files

Agreed. This seems an excellent solution to me. A jar might need to have 
multiple *alias* names, to handle things like one jar being split into 
two: both jars should have their own names, but should also be able to 
define aliases to pretend they also have the original name so dependency 
refs don't break.

Having names could also help detect multiple jars in the same path: two 
jars claiming to be "javax.faces.api" should cause an error, solving the 
regular problem where people have both the RI and MyFaces in the classpath.


> 
> Other solutions I've seen are just lousy.  Numbers (like servlet loading
> orders) are a pain in the arse, especially with these faces-config.xml
> files distributed around JARs built by multiple people.  And specifying
> explicit orders in a web.xml file is rather poor too - we should not
> be making end users configure even *more*.  (The goal of J2EE should
> be eliminating required configuration.

Agreed.



Regards,

Simon

Re: Require ordering of for loading META-INF/faces-config.xml files from component jar

[Martin Marinschek <ma...@gmail.com>]

Sounds good to me!

especially a solution where we don't need a new type of configuration
file would be great ;)

regards,

Martin

On 12/6/05, Adam Winer <aw...@gmail.com> wrote:
> Yes, the desire for a real solution and the permanence of anything
> that does get into the spec was the reason why we deep-sixed
> any hacky fix.  A lot of times - in the world of long-living specs -
> doing nothing is by far the best solution.
>
> I do think that Ed has a point that MyFaces would do well to
> mimic the JSF 1.2 solution;   it will do no harm (other than
> time spent implementing it).
>
> My preferred complete solution is something along the lines of
> giving a particular faces-config.xml file an ID (e.g., MyFaces tomahawk
> might be "org.apache.myfaces.tomhawk"), and then stating
> in each file what dependencies it has;  so you could explicitly
> say in a faces-config.xml file "I come *after* Tomahawk";  then you leave
> it up to the implementation to come up with a legit ordering of all the
> identified files
>
> Other solutions I've seen are just lousy.  Numbers (like servlet loading
> orders) are a pain in the arse, especially with these faces-config.xml
> files distributed around JARs built by multiple people.  And specifying
> explicit orders in a web.xml file is rather poor too - we should not
> be making end users configure even *more*.  (The goal of J2EE should
> be eliminating required configuration.  It bugs me, for instance, that in
> J2EE 5.0, a user still has to explicitly register FacesServlet.  Why?)
>
> Of course, I'm open to any brilliant ideas out there. ;)
>
> -- Adam
>
>
> On 12/5/05, Mike Kienenberger <mk...@gmail.com> wrote:
> > Ed, I understand that you needed a short-term workaround, and I'm
> > overjoyed to hear you confirm to others that it's not in the spec this
> > way.
> >
> > I still think our time (the Myfaces committers' time) would be better
> > spent creating a full solution rather than implementing the
> > workaround.   The workaround is only in JSF 1.2 anyway, and not JSF
> > 1.1, so any solution we create under MyFaces is going to be different
> > (or "incompatible") with JSF RI 1.1's loading scheme.
> >
> > However, it's open source, so whoever's doing the work is going to
> > determine the initial behavior. :)
> >
> > On 12/5/05, Ed Burns <ed...@yahoo.com> wrote:
> > > > > At the time of the original discussion, we
> > > > proposed better ways of
> > > > > handling this which should be archived in the
> > > > mailing list.  (I think
> > > > > Martin and Craig were also involved at the time,
> > > > and we hammered out a
> > > > > reasonable dependency-handling approach).  I'm not
> > > > really sure why Ed
> > > > > went with it the way he did because no one else
> > > > was happy with that
> > > > > approach.
> > >
> > > As I said previously, I just put this in the Sun impl
> > > because we had a short term need for a deterministic
> > > approach to loadine META-INF/faces-config.xml files.
> > > I agree it's not the best approach but you must agree
> > > that it is unobtrusive.  I only intend it to be used
> > > in a pinch, anyway.
> > >
> > > Ed
> > >
> > >
> > >
> > > __________________________________________
> > > Yahoo! DSL – Something to write home about.
> > > Just $16.99/mo. or less.
> > > dsl.yahoo.com
> > >
> > >
> >
>


--

http://www.irian.at

Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German

Professional Support for Apache MyFaces

Re: Require ordering of for loading META-INF/faces-config.xml files from component jar

[Adam Winer <aw...@gmail.com>]

Yes, the desire for a real solution and the permanence of anything
that does get into the spec was the reason why we deep-sixed
any hacky fix.  A lot of times - in the world of long-living specs -
doing nothing is by far the best solution.

I do think that Ed has a point that MyFaces would do well to
mimic the JSF 1.2 solution;   it will do no harm (other than
time spent implementing it).

My preferred complete solution is something along the lines of
giving a particular faces-config.xml file an ID (e.g., MyFaces tomahawk
might be "org.apache.myfaces.tomhawk"), and then stating
in each file what dependencies it has;  so you could explicitly
say in a faces-config.xml file "I come *after* Tomahawk";  then you leave
it up to the implementation to come up with a legit ordering of all the
identified files

Other solutions I've seen are just lousy.  Numbers (like servlet loading
orders) are a pain in the arse, especially with these faces-config.xml
files distributed around JARs built by multiple people.  And specifying
explicit orders in a web.xml file is rather poor too - we should not
be making end users configure even *more*.  (The goal of J2EE should
be eliminating required configuration.  It bugs me, for instance, that in
J2EE 5.0, a user still has to explicitly register FacesServlet.  Why?)

Of course, I'm open to any brilliant ideas out there. ;)

-- Adam


On 12/5/05, Mike Kienenberger <mk...@gmail.com> wrote:
> Ed, I understand that you needed a short-term workaround, and I'm
> overjoyed to hear you confirm to others that it's not in the spec this
> way.
>
> I still think our time (the Myfaces committers' time) would be better
> spent creating a full solution rather than implementing the
> workaround.   The workaround is only in JSF 1.2 anyway, and not JSF
> 1.1, so any solution we create under MyFaces is going to be different
> (or "incompatible") with JSF RI 1.1's loading scheme.
>
> However, it's open source, so whoever's doing the work is going to
> determine the initial behavior. :)
>
> On 12/5/05, Ed Burns <ed...@yahoo.com> wrote:
> > > > At the time of the original discussion, we
> > > proposed better ways of
> > > > handling this which should be archived in the
> > > mailing list.  (I think
> > > > Martin and Craig were also involved at the time,
> > > and we hammered out a
> > > > reasonable dependency-handling approach).  I'm not
> > > really sure why Ed
> > > > went with it the way he did because no one else
> > > was happy with that
> > > > approach.
> >
> > As I said previously, I just put this in the Sun impl
> > because we had a short term need for a deterministic
> > approach to loadine META-INF/faces-config.xml files.
> > I agree it's not the best approach but you must agree
> > that it is unobtrusive.  I only intend it to be used
> > in a pinch, anyway.
> >
> > Ed
> >
> >
> >
> > __________________________________________
> > Yahoo! DSL – Something to write home about.
> > Just $16.99/mo. or less.
> > dsl.yahoo.com
> >
> >
>

Re: Require ordering of for loading META-INF/faces-config.xml files from component jar

[Mike Kienenberger <mk...@gmail.com>]

Ed, I understand that you needed a short-term workaround, and I'm
overjoyed to hear you confirm to others that it's not in the spec this
way.

I still think our time (the Myfaces committers' time) would be better
spent creating a full solution rather than implementing the
workaround.   The workaround is only in JSF 1.2 anyway, and not JSF
1.1, so any solution we create under MyFaces is going to be different 
(or "incompatible") with JSF RI 1.1's loading scheme.

However, it's open source, so whoever's doing the work is going to
determine the initial behavior. :)

On 12/5/05, Ed Burns <ed...@yahoo.com> wrote:
> > > At the time of the original discussion, we
> > proposed better ways of
> > > handling this which should be archived in the
> > mailing list.  (I think
> > > Martin and Craig were also involved at the time,
> > and we hammered out a
> > > reasonable dependency-handling approach).  I'm not
> > really sure why Ed
> > > went with it the way he did because no one else
> > was happy with that
> > > approach.
>
> As I said previously, I just put this in the Sun impl
> because we had a short term need for a deterministic
> approach to loadine META-INF/faces-config.xml files.
> I agree it's not the best approach but you must agree
> that it is unobtrusive.  I only intend it to be used
> in a pinch, anyway.
>
> Ed
>
>
>
> __________________________________________
> Yahoo! DSL – Something to write home about.
> Just $16.99/mo. or less.
> dsl.yahoo.com
>
>

Re: Require ordering of for loading META-INF/faces-config.xml files from component jar

[Ed Burns <ed...@yahoo.com>]

--- Martin Marinschek <ma...@gmail.com>
wrote:

> Yes, no one was.
> 
> It's a workaround, but it's awkward at least.
> 
> Still, it's better than nothing, and if it is in the
> Spec like this,
> we'll need to implement it.

To be clear, this isn't in the spec.  The resolution
of this issue in the JSF 1.2 EG was to defer it.  

I've attached patches to the bug to implement this,
agreeably "better than nothing" solution on the JSF
1.1 and 1.2 impls from Sun.

I just wanted to offer it here because I think it
would be nice if we both followed the same convention.
 

Ed


		
__________________________________________ 
Yahoo! DSL – Something to write home about. 
Just $16.99/mo. or less. 
dsl.yahoo.com 

Re: Require ordering of for loading META-INF/faces-config.xml files from component jar

[Ed Burns <ed...@yahoo.com>]

> > At the time of the original discussion, we
> proposed better ways of
> > handling this which should be archived in the
> mailing list.  (I think
> > Martin and Craig were also involved at the time,
> and we hammered out a
> > reasonable dependency-handling approach).  I'm not
> really sure why Ed
> > went with it the way he did because no one else
> was happy with that
> > approach.

As I said previously, I just put this in the Sun impl
because we had a short term need for a deterministic
approach to loadine META-INF/faces-config.xml files. 
I agree it's not the best approach but you must agree
that it is unobtrusive.  I only intend it to be used
in a pinch, anyway.

Ed


		
__________________________________________ 
Yahoo! DSL – Something to write home about. 
Just $16.99/mo. or less. 
dsl.yahoo.com 

Re: Require ordering of for loading META-INF/faces-config.xml files from component jar

[Martin Marinschek <ma...@gmail.com>]

Yes, no one was.

It's a workaround, but it's awkward at least.

Still, it's better than nothing, and if it is in the Spec like this,
we'll need to implement it.

regards,

Martin

On 12/5/05, Mike Kienenberger <mk...@gmail.com> wrote:
> -1 for doing it this way.   We've already heard from Ed and Adam that
> once something becomes "official" in J2EE, there's no deprecating it
> in the forseeable future, no matter how awful it is.    As Jacob
> commented, this approach is a hack, and I'd hate to see it become the
> standard.
>
> At the time of the original discussion, we proposed better ways of
> handling this which should be archived in the mailing list.  (I think
> Martin and Craig were also involved at the time, and we hammered out a
> reasonable dependency-handling approach).  I'm not really sure why Ed
> went with it the way he did because no one else was happy with that
> approach.
>
> On 12/5/05, Bruno Aranda <br...@gmail.com> wrote:
> > Hi *,
> >
> > I've just talked with Ed Burns in IRC and he has told me that he has
> > implemented the ordering of the loading of the config files [1]. He
> > has attached the implementation there for ideas.
> > I am not sure, but this is one of the JSF1.2 things that we could
> > implement without having to do major changes.
> >
> > Regards,
> >
> > Bruno
> >
> > [1] https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=121
> >
>


--

http://www.irian.at

Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German

Professional Support for Apache MyFaces

Re: Require ordering of for loading META-INF/faces-config.xml files from component jar

[Mike Kienenberger <mk...@gmail.com>]

-1 for doing it this way.   We've already heard from Ed and Adam that
once something becomes "official" in J2EE, there's no deprecating it
in the forseeable future, no matter how awful it is.    As Jacob
commented, this approach is a hack, and I'd hate to see it become the
standard.

At the time of the original discussion, we proposed better ways of
handling this which should be archived in the mailing list.  (I think
Martin and Craig were also involved at the time, and we hammered out a
reasonable dependency-handling approach).  I'm not really sure why Ed
went with it the way he did because no one else was happy with that
approach.

On 12/5/05, Bruno Aranda <br...@gmail.com> wrote:
> Hi *,
>
> I've just talked with Ed Burns in IRC and he has told me that he has
> implemented the ordering of the loading of the config files [1]. He
> has attached the implementation there for ideas.
> I am not sure, but this is one of the JSF1.2 things that we could
> implement without having to do major changes.
>
> Regards,
>
> Bruno
>
> [1] https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=121
>