Hi,
Quick summary:
UIComponent.getAttributes().put(propName, value)
returns the old value of the property. When the property is a
value-binding this can cause problems, but there is no obvious way to
set a property without getting the old value returned.
== details
When a component is crea
Volker,
The examples built ok. I haven't had a chance to test them yet but
I'll assume they work fine ;-)
I could use some help with "assembly" if you or the other Tobago guys
gets a chance. We need a binary, source and examples bundle. Right
now the assembly plugin seems to be able to build o
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
woul
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 t
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
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 My
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 <[EMAIL PROTECTED]> wrote:
> Yes, the desire for a real solution and the permanence of anything
> that does get into the spec was the reason why
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
Now and this is what Ed's suggestion originally was - enforcing this
alphabetic parsing on the JSF level.
regards,
Martin
On 12/6/05, Simon Kitching <[EMAIL PROTECTED]> wrote:
> Hi,
>
> I struck this problem when I had to override the renderer for tomahawk's
> JSCookMenu component. My jar's face
Hi,
I struck this problem when I had to override the renderer for tomahawk's
JSCookMenu component. My jar's faces-config.xml needs to be processed
after the tomahawk one in order for my renderer to override the tomahawk
one.
I believe that MyFaces processes files in the order returned by
Cl
Now this is Open Source again. Jesse will scratch his itch and provide
a patch, and we will still discuss about what is the optimum in two
years from now ;)
regards,
Martin
On 12/6/05, Jesse Alexander (KBSA 21) <[EMAIL PROTECTED]> wrote:
> So you prefer to keep a rather UGLY behaviour, th eone w
So you prefer to keep a rather UGLY behaviour, th eone where you never
can be
sure in which sequence the jar-files are processed?
It just makes it almost impossible to use a set of custom-components
from external
companies, if you need to override a renderer for example...
I'd rather have the ak
Ok. Hearing no objections, or comments of any sort today, I guess
I'll go ahead and commit this change, and someone can change it back
if I'm wrong.
On 12/5/05, Mike Kienenberger <[EMAIL PROTECTED]> wrote:
> I'm looking into this, and it appears that the problem is that the new code
> uses
>
>
[
http://issues.apache.org/jira/browse/MYFACES-854?page=comments#action_12359351
]
Mike Kienenberger commented on MYFACES-854:
---
Sean,
I guess it's possible. Try changing the first line of
org.apache.myfaces.component.html.util.AddResource.serv
I'm looking into this, and it appears that the problem is that the new code uses
public void serveResource(HttpServletRequest request,
HttpServletResponse response)
throws IOException
{
String uri = request.getRequestURI();
for which the javadocs read "The web containe
[
http://issues.apache.org/jira/browse/MYFACES-854?page=comments#action_12359347
]
sean schofield commented on MYFACES-854:
I wonder if this is the same problem I am having with tree2? I am getting
ClassNotFound for classes during the resource loa
[
http://issues.apache.org/jira/browse/MYFACES-854?page=comments#action_12359346
]
Mike Kienenberger commented on MYFACES-854:
---
Ok. I can't seem to post the same errors errors into the web page.
But if you have resource loading errors somewhat l
[ http://issues.apache.org/jira/browse/MYFACES-854?page=all ]
Mike Kienenberger updated MYFACES-854:
--
Comment: was deleted
> Problem w/ InputSuggestAjax popup suggestion list
> -
>
> Key: MYFA
[
http://issues.apache.org/jira/browse/MYFACES-854?page=comments#action_12359344
]
Mike Kienenberger commented on MYFACES-854:
---
Chris,
Can you confirm whether you're seeing errors like this when you first load the
page? If so, does the problem
[
http://issues.apache.org/jira/browse/MYFACES-854?page=comments#action_12359345
]
Mike Kienenberger commented on MYFACES-854:
---
Somehow lost the errors.
13:38:30.250 ERROR! [SocketListener0-0]
org.apache.myfaces.component.html.util.MyFacesResourc
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 workarou
> > 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
--- Martin Marinschek <[EMAIL PROTECTED]>
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
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
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 <[EMAIL PROTECTED]> wrote:
> -1 for doing it this way. We've already heard from Ed and
[ http://issues.apache.org/jira/browse/MYFACES-886?page=all ]
Mike Kienenberger closed MYFACES-886:
-
Resolution: Invalid
The error you're seeing is some kind of JSF RI configuration error. It doesn't
have anything to do with Tomahawk nor would
Sometime between 10/24 and 11/28, Myfaces stopped loading resources on
a page request with a new session fragment.
I'm guessing there must have originally been code to handle the
";jsession=*" part of the URL that somehow was removed. Once the
session is created, (on the next request) the resourc
-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
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 cha
Jurgen,
Where does this fit on your schedule?
I would like to create a patch based the changes posted in JIRA if you
are not able to get to it.
Paul Spencer
Jurgen Lust (JIRA) wrote:
[ http://issues.apache.org/jira/browse/MYFACES-888?page=comments#action_12358857 ]
Jurgen Lust comment
30 matches
Mail list logo
