[jira] Commented: (MYFACES-1820) Infinite loop can occur when custom FacesContext subclass compiled against JSF1.1 but used with JSF1.2
[
https://issues.apache.org/jira/browse/MYFACES-1820?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12792419#action_12792419
]
Simon Kitching commented on MYFACES-1820:
-
Yes, Leonardo's posting shows the latest code.
I'm not sure Leonardo's suggested change is needed though. The whole point of
the patch I applied is that we can have this situation:
custom FacesContext decorator object #1 (eg from Orchestra)
-- custom FacesContext decorator object #2 (eg from PrettyFaces) [1]
-- the base implementation (eg the standard MyFaces FacesContextImpl
object)
There are two situations when a decorator class wants to do some of its own
logic *then* delegate to the next instance in the chain:
(a) when it wants to do something *in addition to the standard logic*
(b) when the class wants to be useable with versions of JSF earlier than the
one it was compiled with; in this case it needs to provide stubs for new
methods, which just delegate to the wrapped instance.
The custom subclasses of FacesContext are supposed to just call the
corresponding method on the super-class (FacesContext), and let that delegate
to the wrapped instance. However in the original code, what was delegated to
was whatever object setCurrentInstance() had been called on. Obviously, when
the wrapper has set itself as the current instance a loop occurs [2].
Unfortunately, JSF makes finding the wrapped instance very difficult. The
current code (this _firstInstance stuff) just returns the base implementation
every time, which means it can skip objects in the middle of the chain. But it
is better than nothing.
Leonardo's suggested check for
if (ctx == this)
should not be necessary as far as I can see, because ctx will always be the
base implementation, and that should never call methods on the superclass;
the base implementation is required to override the getELContext method in
the FacesContext class with a proper implementation.
[1] I'm not 100% sure that PrettyFaces customises FacesContext, but certainly
some libraries out there do. Sorry, I've forgotten exactly which ones
definitely do it..
[2] I guess that the JSF designers had assumed that the ability to customise
the FacesContextFactory would be used only to completely replace a FacesContext
implementation, rather than to write a decorator. But FacesContext decorators
are very useful - in fact, critical in some cases. And several libraries out
there already use them.
Infinite loop can occur when custom FacesContext subclass compiled against
JSF1.1 but used with JSF1.2
--
Key: MYFACES-1820
URL: https://issues.apache.org/jira/browse/MYFACES-1820
Project: MyFaces Core
Issue Type: Bug
Components: JSR-252
Affects Versions: 1.2.2
Reporter: Simon Kitching
Attachments: FacesContext.patch.txt, patch-1820.txt
The problem is method FacesContext.getELContext. JSF1.2 added a method to
this base class that was not there in JSF1.1. This makes life difficult for
existing JSF1.1 code that already subclasses that class.
A default concrete implementation needs to exist, in order not to break
existing JSF1.1 code, but (a) the current one gets it wrong, and (b) defining
a correct one is difficult (impossible?)
(1) Stan Silvert initially defined this method like this:
// The following concrete method was added for JSF 1.2.
// It supplies a default
// implementation that throws UnsupportedOperationException.
// This allows old FacesContext implementations to still work.
public ELContext getELContext() {
throw new UnsupportedOperationException();
}
(2) Dennis Byrne changed it to its current form:
public ELContext getELContext() {
FacesContext ctx = getCurrentInstance();
if (ctx == null)
throw new NullPointerException(FacesContext.class.getName());
ELContext elctx = ctx.getELContext();
if (elctx == null)
throw new UnsupportedOperationException();
return elctx;
}
However (2) assumes that custom subclasses never set themselves as the
current instance, instead only ever *delegating* to the real instance.
If someone's custom subclass of FacesContext ever calls
setCurrentInstance(this), then an infinite loop will occur here.
And in fact, this is just what we get:
java.lang.StackOverflowError
at java.lang.ThreadLocal$ThreadLocalMap.getEntry(ThreadLocal.java:357)
at java.lang.ThreadLocal$ThreadLocalMap.access$000(ThreadLocal.java:242)
at java.lang.ThreadLocal.get(ThreadLocal.java:127)
at
javax.faces.context.FacesContext.getCurrentInstance(FacesContext.java:98)
at javax.faces.context.FacesContext.getELContext(FacesContext.java:35)
at javax.faces.context.FacesContext.getELContext
[jira] Commented: (MYFACES-1820) Infinite loop can occur when custom FacesContext subclass compiled against JSF1.1 but used with JSF1.2
[
https://issues.apache.org/jira/browse/MYFACES-1820?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12792071#action_12792071
]
Simon Kitching commented on MYFACES-1820:
-
For FacesContext subclasses, this issue could originally be triggered by:
[1] create class CustomFacesContextFactory which returns a new
CustomFacesContext instance
[2] define class CustomFacesContext, and have its constructor call
FacesContext.setCurrentInstance(this)
(just as the default FacesContextImpl class does)
[3] configure the faces-config.xml so that this factory is used.
then accessing any standard jsf page. The faces contexts were created, and then
when an EL expression is found in the page, JSF called
FacesContext.getCurrentInstance().getELContext() and an infinite loop
immediately occured.
I committed the attached patch for the FacesContext class quite a while ago;
see r634007. This is a *partial* fix, in that it does avoid infinite loops.
However it does not properly delegate to the wrapped instance; instead, it
delegates directly to the last instance in the chain of wrapped classes.
The issue is not closed because
(a) the solution is not right when multiple layers of wrappers exist, and
(b) the same issue exists for JSF decorator classes other than FacesContext.
It's been quite a while since I wrote this issue, so I can't remember exactly
which other classes have problems. But they are those classes that may want to
delegate to an underlying implementation (ie implement the decorator
pattern), but JSF provides no way to locate that underlying implementation. I
think they include:
* Lifecycle
* RenderKit
* NavigationHandler?
Infinite loop can occur when custom FacesContext subclass compiled against
JSF1.1 but used with JSF1.2
--
Key: MYFACES-1820
URL: https://issues.apache.org/jira/browse/MYFACES-1820
Project: MyFaces Core
Issue Type: Bug
Components: JSR-252
Affects Versions: 1.2.2
Reporter: Simon Kitching
Attachments: FacesContext.patch.txt, patch-1820.txt
The problem is method FacesContext.getELContext. JSF1.2 added a method to
this base class that was not there in JSF1.1. This makes life difficult for
existing JSF1.1 code that already subclasses that class.
A default concrete implementation needs to exist, in order not to break
existing JSF1.1 code, but (a) the current one gets it wrong, and (b) defining
a correct one is difficult (impossible?)
(1) Stan Silvert initially defined this method like this:
// The following concrete method was added for JSF 1.2.
// It supplies a default
// implementation that throws UnsupportedOperationException.
// This allows old FacesContext implementations to still work.
public ELContext getELContext() {
throw new UnsupportedOperationException();
}
(2) Dennis Byrne changed it to its current form:
public ELContext getELContext() {
FacesContext ctx = getCurrentInstance();
if (ctx == null)
throw new NullPointerException(FacesContext.class.getName());
ELContext elctx = ctx.getELContext();
if (elctx == null)
throw new UnsupportedOperationException();
return elctx;
}
However (2) assumes that custom subclasses never set themselves as the
current instance, instead only ever *delegating* to the real instance.
If someone's custom subclass of FacesContext ever calls
setCurrentInstance(this), then an infinite loop will occur here.
And in fact, this is just what we get:
java.lang.StackOverflowError
at java.lang.ThreadLocal$ThreadLocalMap.getEntry(ThreadLocal.java:357)
at java.lang.ThreadLocal$ThreadLocalMap.access$000(ThreadLocal.java:242)
at java.lang.ThreadLocal.get(ThreadLocal.java:127)
at
javax.faces.context.FacesContext.getCurrentInstance(FacesContext.java:98)
at javax.faces.context.FacesContext.getELContext(FacesContext.java:35)
at javax.faces.context.FacesContext.getELContext(FacesContext.java:40)
at javax.faces.context.FacesContext.getELContext(FacesContext.java:40)
at javax.faces.context.FacesContext.getELContext(FacesContext.java:40)
at javax.faces.context.FacesContext.getELContext(FacesContext.java:40)
at javax.faces.context.FacesContext.getELContext(FacesContext.java:40)
at javax.faces.context.FacesContext.getELContext(FacesContext.java:40)
at javax.faces.context.FacesContext.getELContext(FacesContext.java:40)
at javax.faces.context.FacesContext.getELContext(FacesContext.java:40)
at javax.faces.context.FacesContext.getELContext(FacesContext.java:40)
at javax.faces.context.FacesContext.getELContext(FacesContext.java:40)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add
[jira] Commented: (MYFACES-1820) Infinite loop can occur when custom FacesContext subclass compiled against JSF1.1 but used with JSF1.2
[
https://issues.apache.org/jira/browse/MYFACES-1820?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12792073#action_12792073
]
Simon Kitching commented on MYFACES-1820:
-
This problem was noticed during the implementation of the Orchestra library. We
wanted to decorate a number of standard classes, to *add* our own logic to
the normal processing. But it was then impossible to find the wrapped
instance to delegate to.
Infinite loop can occur when custom FacesContext subclass compiled against
JSF1.1 but used with JSF1.2
--
Key: MYFACES-1820
URL: https://issues.apache.org/jira/browse/MYFACES-1820
Project: MyFaces Core
Issue Type: Bug
Components: JSR-252
Affects Versions: 1.2.2
Reporter: Simon Kitching
Attachments: FacesContext.patch.txt, patch-1820.txt
The problem is method FacesContext.getELContext. JSF1.2 added a method to
this base class that was not there in JSF1.1. This makes life difficult for
existing JSF1.1 code that already subclasses that class.
A default concrete implementation needs to exist, in order not to break
existing JSF1.1 code, but (a) the current one gets it wrong, and (b) defining
a correct one is difficult (impossible?)
(1) Stan Silvert initially defined this method like this:
// The following concrete method was added for JSF 1.2.
// It supplies a default
// implementation that throws UnsupportedOperationException.
// This allows old FacesContext implementations to still work.
public ELContext getELContext() {
throw new UnsupportedOperationException();
}
(2) Dennis Byrne changed it to its current form:
public ELContext getELContext() {
FacesContext ctx = getCurrentInstance();
if (ctx == null)
throw new NullPointerException(FacesContext.class.getName());
ELContext elctx = ctx.getELContext();
if (elctx == null)
throw new UnsupportedOperationException();
return elctx;
}
However (2) assumes that custom subclasses never set themselves as the
current instance, instead only ever *delegating* to the real instance.
If someone's custom subclass of FacesContext ever calls
setCurrentInstance(this), then an infinite loop will occur here.
And in fact, this is just what we get:
java.lang.StackOverflowError
at java.lang.ThreadLocal$ThreadLocalMap.getEntry(ThreadLocal.java:357)
at java.lang.ThreadLocal$ThreadLocalMap.access$000(ThreadLocal.java:242)
at java.lang.ThreadLocal.get(ThreadLocal.java:127)
at
javax.faces.context.FacesContext.getCurrentInstance(FacesContext.java:98)
at javax.faces.context.FacesContext.getELContext(FacesContext.java:35)
at javax.faces.context.FacesContext.getELContext(FacesContext.java:40)
at javax.faces.context.FacesContext.getELContext(FacesContext.java:40)
at javax.faces.context.FacesContext.getELContext(FacesContext.java:40)
at javax.faces.context.FacesContext.getELContext(FacesContext.java:40)
at javax.faces.context.FacesContext.getELContext(FacesContext.java:40)
at javax.faces.context.FacesContext.getELContext(FacesContext.java:40)
at javax.faces.context.FacesContext.getELContext(FacesContext.java:40)
at javax.faces.context.FacesContext.getELContext(FacesContext.java:40)
at javax.faces.context.FacesContext.getELContext(FacesContext.java:40)
at javax.faces.context.FacesContext.getELContext(FacesContext.java:40)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Reopened: (ORCHESTRA-32) Hot-restart of Tomcat causes NullPointerException while deserializing saved http-session
[ https://issues.apache.org/jira/browse/ORCHESTRA-32?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Simon Kitching reopened ORCHESTRA-32: - Thanks for reporting this Mark. It's definitely a bad idea for a readResolve method to use the FrameworkAdapter because it may not exist at that time. Hot-restart of Tomcat causes NullPointerException while deserializing saved http-session Key: ORCHESTRA-32 URL: https://issues.apache.org/jira/browse/ORCHESTRA-32 Project: MyFaces Orchestra Issue Type: Bug Components: Conversation Affects Versions: 1.2 Reporter: Simon Kitching Assignee: Simon Kitching Fix For: 1.4 Tomcat displays this message on restart: SCHWERWIEGEND: Exception loading sessions from persistent storage java.lang.NullPointerException at java.util.concurrent.ConcurrentHashMap.put(ConcurrentHashMap.java:881) at org.apache.catalina.session.StandardSession.readObject(StandardSession.java:1445) The problem is that the orchestra ConversationManager class has a readResolve method that returns null, intending that the object just gets created on demand later. However Tomcat tries to put the deserialized object into its session - and null objects are not permitted in an HttpSession. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (ORCHESTRA-32) Hot-restart of Tomcat causes NullPointerException while deserializing saved http-session
[ https://issues.apache.org/jira/browse/ORCHESTRA-32?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12710375#action_12710375 ] Simon Kitching commented on ORCHESTRA-32: - Ok, should be fixed now (see r775960). It's not the most elegant fix, but seems to do the job. Please test... Hot-restart of Tomcat causes NullPointerException while deserializing saved http-session Key: ORCHESTRA-32 URL: https://issues.apache.org/jira/browse/ORCHESTRA-32 Project: MyFaces Orchestra Issue Type: Bug Components: Conversation Affects Versions: 1.2 Reporter: Simon Kitching Assignee: Simon Kitching Fix For: 1.4 Tomcat displays this message on restart: SCHWERWIEGEND: Exception loading sessions from persistent storage java.lang.NullPointerException at java.util.concurrent.ConcurrentHashMap.put(ConcurrentHashMap.java:881) at org.apache.catalina.session.StandardSession.readObject(StandardSession.java:1445) The problem is that the orchestra ConversationManager class has a readResolve method that returns null, intending that the object just gets created on demand later. However Tomcat tries to put the deserialized object into its session - and null objects are not permitted in an HttpSession. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: f:ajax and MyFaces extensions
Werner Punz schrieb: Matthias Wessendorf schrieb: On Tue, Apr 21, 2009 at 8:13 PM, Werner Punz werner.p...@gmail.com wrote: Actually We probably can provide a non facelets based solution under the myfaces umbrella, tomahawk, extensions or impl I don´t care but I am definitely sure we will be unable to provide it under the standard f: tags... yeah. I know. I am really wondering why the support all views ship sailed away. Again, I understand that some solutions may only fly in Facelets land... That said, but wasn't the promised goal of the formal/current EG that a flexible ViewLayer was the KEY ? == Swing-based RenderKit etc ? Or is this (JSF) just another web-framework ? Well the entire ajax part makes only sense in the web domain. f:ajax definitely is not suitable for swing and others. Why doesn't partial-page-updating make sense for presentation layers other than HTML? If a JSF renderkit was to generate some special markup that a client app (browser replacement) then created swing components from, that submitting part of the page (a subset of the swing widgets) would still be a useful thing to do, wouldn't it? Is the JSF2.0 PPR-related spec designed to handle this, ie is the response message structured so that a non-browser can still interpret it correctly? As long as the response contains just XML with component ids and values, it seems that this would work ok... Cheers, Simon
Re: f:ajax and MyFaces extensions
Hi, Unlike JSP tags, facelet tags do not declare or validate attributes (ie you can define any attributes you like on a facelet tag without getting a this attribute does not exist error) [1], so the TCK presumably would not be able to detect whether MyFaces has extended the spec with custom attributes. However my personal opinion is that adding custom behaviour to a standard tag is *wrong* if the app would fail to work correctly when the attributes are ignored. In other words, adding optimisation or debugging-helper params is acceptable, but otherwise not. Adding behaviour-changing features to standard tags is setting a portability trap for users, where their app will silently fail to run correctly when executed on a different JSF implementation. That seems unacceptable to me, even if the TCK cannot technically detect it. So for the two params you are proposing which are just performance tweaks, just attributes on f:ajax, or using nested f:attribute seems ok. But for the other one (queueLength?) I would strongly recommend an mf:ajax or mf:attribute tag be created. [1] At least, facelets for JSF1.2 works this way. I presume this hasn't changed... Regards, Simon Ganesh schrieb: Hi Werner, Does this mean Matthias succeeded in convincing you that f:ajax is facelets-only and can receive an additional attribute without breaking the TCK or the spec? Also, please see the spec, section 10.1: New features introduced in version 2 and later are only exposed to page authors using Facelets. JSP is retained for backwards compatibility. Imho, this is the polite way of saying JSP is dead. Best Regards, Ganesh Werner Punz schrieb: Ok I did a quick look over the facelets section as it seems, it is facelets or jsp just like we had in the past... I would have loved to have a templating on the renderer side for jsp as well, oh well... Werner
Re: f:ajax and MyFaces extensions
Matthias Wessendorf schrieb:
On Fri, Apr 17, 2009 at 12:41 PM, Ganesh gan...@j4fry.org wrote:
Hi,
Here's a question concerning the extension parameters pps, queuesize and
errorlevel in conjunction with the f:ajax tag. They form part of the
Javascript xhrCore and can be set via jsf.ajax.request(this, event,
{execute:'xxx', render:'yyy', myfaces:{pps:true, queuesize:1, errorlevel:
'error'}}).
For the ajax tag the extension parameters could reside in an attribute
myfaces: myfaces={pps:true, queuesize:1, errorlevel: 'error'}.
Now, should this extension parameter become part of the f:ajax tag or should
mf:ajax ?
By that one could use this core extension, when using myfaces lib.
we build a t:ajax tomahawk tag?
-1 this would tie the use really to tomahawk;
Why not doing a mf:ajax which is a taglib that sits inside the
myfaces-impl.jar
But then any web page that uses this mf:ajax tag would not work when run
on a different container (eg mojarra), as that tag would not exist.
The tomahawk tag sounds better to me. If I understand correctly, a page
using it would still work on other containers as long as tomahawk was in
the classpath. The extra params to jsf.ajax.request would be rendered
into the page, and sent back to the container, but then not used.
Possibly nested attributes could be used?
f:ajax ...
f:attribute name=myfaces:pps value=true/
f:attribute name=myfaces:queuesize value=1/
/f:ajax
When a page containing that tag is used in a container that doesn't
recognise these attributes, I expect they would just be ignored (the
extra attributes would not be rendered into the generated page).
Regards,
Simon
Re: f:ajax and MyFaces extensions
Matthias Wessendorf schrieb:
On Fri, Apr 17, 2009 at 1:12 PM, Simon Kitching skitch...@apache.org wrote:
Matthias Wessendorf schrieb:
On Fri, Apr 17, 2009 at 12:41 PM, Ganesh gan...@j4fry.org wrote:
Hi,
Here's a question concerning the extension parameters pps, queuesize and
errorlevel in conjunction with the f:ajax tag. They form part of the
Javascript xhrCore and can be set via jsf.ajax.request(this, event,
{execute:'xxx', render:'yyy', myfaces:{pps:true, queuesize:1, errorlevel:
'error'}}).
For the ajax tag the extension parameters could reside in an attribute
myfaces: myfaces={pps:true, queuesize:1, errorlevel: 'error'}.
Now, should this extension parameter become part of the f:ajax tag or
should
mf:ajax ?
By that one could use this core extension, when using myfaces lib.
we build a t:ajax tomahawk tag?
-1 this would tie the use really to tomahawk;
Why not doing a mf:ajax which is a taglib that sits inside the
myfaces-impl.jar
But then any web page that uses this mf:ajax tag would not work when run
on a different container (eg mojarra), as that tag would not exist.
correct.
same would be the case (even worse) if the behavior of f:ajax (silly name btw)
is different than expected.
Well, I guess it depends on what these pps/queuesize/errorlevel params
do. They looked to me like optimisation tweaks, ie if they weren't
there then the page would still work.
But if they do fundamentally change the behaviour of the app (ie the app
won't work as expected if they are ignored) then I would agree that your
suggested mf:ajax tag would be better than nested f:attribute tags.
Possibly nested attributes could be used?
f:ajax ...
f:attribute name=myfaces:pps value=true/
f:attribute name=myfaces:queuesize value=1/
/f:ajax
The tomahawk tag sounds better to me. If I understand correctly, a page
isn't that big ? including tons of components, extras etc just because of
that ?
Or, an myfaces-extension lib ? (good old times... :-) )
Yes, I guess a myfaces-extension lib would be better (smaller) than
tomahawk. It didn't occur to me because I have never used one (has anyone?).
Regards,
Simon
Re: f:ajax and MyFaces extensions
Matthias Wessendorf schrieb: On Fri, Apr 17, 2009 at 2:24 PM, Ganesh gan...@j4fry.org wrote: As Simon said, inclusion into f:ajax is probably not a good idea, because applications using JSP+Mojarra would break when containing the additional param. Just FYI, myfaces core *must* pass the Sun TCK (compatibility test kit) in order to call itself JSF at all. And the TCK specifically checks for non-standard attributes on any standard tags/classes. So adding any non-standard attributes to standard tags (eg adding stuff to f:ajax) simply cannot be done; the TCK will fail. Sun's intention is to specifically catch cases where a vendor has non-standard extensions that make pages non-portable to other implementations - like when Microsoft tried to extend Java with windows-only features. And this is a good thing IMO. Non-portable extensions have to go into separate libs instead. From your description of the new flags, it sounds like a page will fall back gracefully when run on other containers (slightly noisier with JSF error messages, slightly more data posted on each submit, but still working) so nesting f:attributes seems fair in this case. One thing to check would be that the f:ajax tag isn't marked as empty in the DTD/schema, ie that f:attribute tags can be nested inside it. Cheers, Simon
Re: CI server support / setup (was Fwd: Buildbot at Apache, and a new builds mailing list.)
+1 for moving to the common server. Our build zone has been broken for ages, and as someone who tried hard to fix it, I can say it is a difficult problem! Note that buildbot is a specific tool (http://buildbot.net/trac). I presume we would be moving to the ci.apache.org continuum instance? Cheers, Simon Manfred Geiler schrieb: +1 for moving to new infrastructure --Manfred On Wed, Apr 15, 2009 at 10:02, Matthias Wessendorf mat...@apache.org wrote: Hi, attached is an announcement that there is now a nice support for CI servers. I'd like to move the myfaces (sub) projects to this new infrastructure. What do folks think about that ? I mean in the past our own zone somewhat worked, but the server had also every now and than its hick-ups. so, I am +1 in moving forward to the new Buildbot. what do folks think about it ? -Matthias -- Forwarded message -- From: Gavin ga...@16degrees.com.au Date: Sat, Apr 11, 2009 at 11:15 AM Subject: Buildbot at Apache, and a new builds mailing list. To: p...@apache.org Hi All, This is a heads-up that Buildbot CI server is now available for projects use. Some projects that have been used for testing Buildbot here at the ASF can be seen at http://ci.apache.org. I have a development installation at http://build01.16degrees.com.au:8020/waterfall where I have been testing many more projects (about 20 including the Buildbot project itself). Any new or existing project that wants to add Buildbot to their arsenal of tools to help them build,test,snapshot,deploy,etc can create an issue on the Infrastructure Issue Tracker : https://issues.apache.org/jira/browse/INFRA/component/12312782 There has been a new mailing list created specifically for all our CI servers (Buildbot, Hudson, Continuum) - bui...@apache.org - sign up at builds-subscr...@apache.org . I made use of our infra blog and posted a short note about it at https://blogs.apache.org/infra/entry/new_mailing_list_for_ci So, any requests to make use of any of the build servers are made to the appropriate Jira component on the Infra Issue Tracker. All discussions regarding them should be directed to the bui...@apache.org list from now on. Thanks, and see you there! Gav...
[jira] Commented: (ORCHESTRA-40) A transaction token component inspired by the struts transaction processor
[ https://issues.apache.org/jira/browse/ORCHESTRA-40?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12699345#action_12699345 ] Simon Kitching commented on ORCHESTRA-40: - Could you describe some of the use-cases for this? For transaction-oriented websites, back-buttons or double clicking of a page can be nasty; it can cause operations to be done multiple times (eg buying multiple copies of something) when the user didn't want that. The standard way to detect back-button usage or double clicks on a web page is to have a counter component in the page, and a matching counter in the http session. Both get incremented on each request; if at the start of a request they don't match then we have one of the above problems. If I understand correctly, this patch adds a conversation-aware version of this, which stores the counter in the current conversation for the submitting page. But I'm not sure why this is useful. Why isn't a normal non-conversation-aware token implementation sufficient? Note that the Orchestra ViewController already has features to detect when a page tries to use a conversation that does not exist (eg because it has been invalidated at end of a transaction), and can redirect to the appropriate entry page for the conversation. A transaction token component inspired by the struts transaction processor -- Key: ORCHESTRA-40 URL: https://issues.apache.org/jira/browse/ORCHESTRA-40 Project: MyFaces Orchestra Issue Type: New Feature Components: Conversation Affects Versions: 1.3.1 Reporter: Bernd Bohmann Assignee: Simon Kitching Attachments: ORCHESTRA-40-CacheControl.patch, ORCHESTRA-40-TransactionToken.patch A transactionToken Component for orchestra inspired by the struts transaction processor. The transaction token is to be used for enforcing a single request for a particular transaction. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: trh:script tag causes deadlock on weblogic 9.2 cluster
No, it seems clear to me that there is a bug in weblogic that is only triggered under some conditions. The new EL library happens to trigger these conditions, but the bug is still clearly in weblogic. I suggest asking the Weblogic support team what datastructures in the session are not supported for replication, and are expected to cause a hang. I would expect the answer to be none, in which case a hang is *definitely* their problem. Circular references, weak/strong refs etc. should all be handled by proper replication. The only *possible* user-created problem I can imagine is with locks. If perhaps session replication needs to obtain a lock on the Session object, but the new EL library is obtaining a lock, then never releasing it, that *would* be a user problem, not weblogic. However it seems unlikely as it would almost certainly be a monitor lock, ie a synchronized() block. And those locks are always released when the thread leaves the block. So the only possible way to lock it would be for a thread to enter an infinite loop or block - but that would be pretty quickly spotted as it would have obvious effects. Still, it might be worth looking at what locks are held when the problem occurs. And anyway, nobody except you has reported this issue, so it doesn't seem to be a problem on other servlet containers. So again, it's a weblogic problem. Possibly the new EL code sets up the conditions for this to be triggered, but the real bug is elsewhere. Sorry, but the Myfaces list really doesn't seem the right place for this to be investigated. Regards, Simon Matthias Wessendorf schrieb: hrm, when replacing the EL jars fixes it (or causes it on the other direction) AND the same issue occurs with vanilla JSF, it is somewhat clear to me that the issue is in the EL layer. Do you see where it is deadlocked ? -Matthias On Tue, Apr 14, 2009 at 11:19 AM, Rupak Kumar Sah rupak@chordiant.com wrote: Yeah, it's clearly says the thread is stuck on session replication, but as the same version of Weblogic works fine with older version of EL jars, hence they would never accept it as their issue at first place. I raised this issue with Sun also, and they says they suggests to raise it with Trinidad as the issue is with the trinidad components and the same version of jars works fine else where. Suggest us what to do next. -Original Message- From: simon.kitch...@chello.at [mailto:simon.kitch...@chello.at] Sent: Tuesday, April 14, 2009 2:20 PM To: MyFaces Development Cc: Sabitha Gopal Pandit Subject: Re: trh:script tag causes deadlock on weblogic 9.2 cluster The stacktrace clearly shows that this is a problem with Weblogic session replication or network configuration and nothing whatsoever to do with JSF or Myfaces. Data is being stored into the session, and then when weblogic tries to replicate that data to other members of the cluster a hang is occurring within Weblogic. So please take this discussion to the correct weblogic-specific list or forum. Thanks, Simon Matthias Wessendorf schrieb: Hi, looks like the issue is not really tied to Trinidad. It occurs with vanilla JSF as well. Perhaps this is a problem in the weblogic core, and not the frameworks ? -Matthias On Thu, Apr 9, 2009 at 6:53 AM, Sabitha Gopal Pandit sabitha.go...@chordiant.com wrote: Hi Matthias, We tried the same but didn't work for us Thanks, Sabitha -Original Message- From: mwessend...@gmail.com [mailto:mwessend...@gmail.com] On Behalf Of Matthias Wessendorf Sent: Wednesday, April 08, 2009 7:52 PM To: MyFaces Development Cc: Sabitha Gopal Pandit Subject: Re: trh:script tag causes deadlock on weblogic 9.2 cluster Sabitha, can you take a look at the bug ? Max Starets added a comment. Thx, Matthias On Wed, Apr 8, 2009 at 2:42 PM, Sabitha Gopal Pandit sabitha.go...@chordiant.com wrote: I have raised TRINIDAD-1450 for this issue Thanks, Sabitha -Original Message- From: mwessend...@gmail.com [mailto:mwessend...@gmail.com] On Behalf Of Matthias Wessendorf Sent: Wednesday, April 08, 2009 6:08 PM To: MyFaces Development Subject: Re: trh:script tag causes deadlock on weblogic 9.2 cluster On Wed, Apr 8, 2009 at 2:33 PM, Sabitha Gopal Pandit sabitha.go...@chordiant.com wrote: Can I know the URL to create the JIRA? https://issues.apache.org/jira/browse/TRINIDAD -M Thanks, Sabitha -Original Message- From: mwessend...@gmail.com [mailto:mwessend...@gmail.com] On Behalf Of Matthias Wessendorf Sent: Wednesday, April 08, 2009 6:02 PM To: MyFaces Development Subject: Re: trh:script tag causes deadlock on weblogic 9.2 cluster Hey Sabitha, can you create a JIRA ticket ? Once done, I'll ask our WLS folks to take a look... thanks, matthias On Wed, Apr 8, 2009 at 2:23 PM, Sabitha Gopal Pandit sabitha.go...@chordiant.com wrote: Hi Matthias, As part facelets1.1.14 the el jars which earlier was el-ri.jar is now el-impl.jar We
[orchestra] transaction token patch, session timeout fix
Hi Bernd, I'm keen to look at your patch in JIRA, but it will probably have to wait until this weekend. I hope that's ok https://issues.apache.org/jira/browse/ORCHESTRA-40 This reminds me that you did a follow-up patch (r759100) to your previous Orchestra patch, and Mario had a few comments on it. We both have been busy though, and haven't got around to emailing about it. Your commit was about preventing a cannot remove current contexxt conversation exception while clearing conversations. I presume this actually happened for you, but neither Mario nor I can figure out why that would ever happen. Is there a chance you can look into what actually causes this? Or suggest how we could duplicate this? The SessionListener should never have a FrameworkAdapter in its thread, and so should never have any request param that references a conversation context id. So it's puzzling why you would get that exception. It would also be nice if the new code in the SessionListener would use a finally block to reset the FrameworkAdapter to null, so that if anything does throw an exception then we don't leak the threadlocal var. I can do that myself later .. but if you're investigating the question above, then maybe you could test this at the same time? Also, it might be nice to remove the context from the wiper thread before destroying it, rather than after... Cheers, Simon
Re: [Trinidad] JDK build issue
The problem shown below is that the unit tests are *compiling* on java1.5, but failing when run. It's unfortunately not unusual for unit tests to pass on one version of java, and fail on others; java does change behaviour between releases (eg order of iteration through maps) and sometimes tests are sensitive to these things when the actual program is not. Unless you really want to run the unit tests with java1.5, just do mvn -DskipTests to skip the unit tests when building. Regards, Simon ARausch schrieb: Hi all, I'm struggling here a bit. I'm trying to build Trinidad and am using Maven for the first time. I get exactly the same error messages as Matt. I've tried using a selection of JDK from 1.5.06 to 1.5.17 and always get the same messages. Do I perhaps have to make a profile entry in the settings.xml of maven? Thanks Achim Matt Cooper-2 wrote: Hi all, I've noticed lately that in order to build Trinidad, I have to use jdk6 on the command line (though the settings.xml uses jdk5). My ~/.m2/settings.xml has the following: profiles profile idjava5.home/id activation activeByDefaulttrue/activeByDefault /activation properties jdk5.home/System/Library/Frameworks/JavaVM.framework/Versions/1.5.0/Home/jdk5.home /properties /profile /profiles If I try to build using a jdk5 JAVA_HOME on the command line, I get these test errors: Tests in error: initializationError0(org.apache.myfaces.trinidadinternal.renderkit.CoreRenderKitTest) testEscapeInQuoteJS(org.apache.myfaces.trinidadinternal.ui.laf.base.xhtml.XhtmlLafUtilsTest) testDoubleEscapeInQuoteJS(org.apache.myfaces.trinidadinternal.ui.laf.base.xhtml.XhtmlLafUtilsTest) JAVA_HOME=/System/Library/Frameworks/JavaVM.framework/Versions/1.5.0/Home However, if I build using a jdk6 JAVA_HOME (and keep the jdk5 setting in the settings.xml file), it builds fine. JAVA_HOME=/System/Library/Frameworks/JavaVM.framework/Versions/1.6.0/Home Has anyone else noticed that Trinidad requires this strange build quirk (if so what OS are you using)? It might be a Mac-specific issue or perhaps something else strange on my machine. Thank you, Matt
[jira] Commented: (TOMAHAWK-1409) t:inputCalendar java script problem: org_apache_myfaces_PopupCalendar() is undefined
[
https://issues.apache.org/jira/browse/TOMAHAWK-1409?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12694117#action_12694117
]
Simon Kitching commented on TOMAHAWK-1409:
--
Hi Klaus,
This is a bug-tracking system for myfaces, not a user forum. You should not
create entries here unless you are really sure that there is a bug. In most
cases, you should *first* subscribe to the myfaces user email list, and *only*
when someone confirms that there is a bug should an issue be created here. See
the myfaces website for the email list details.
So please subscribe to the list and post your question there.
t:inputCalendar java script problem: org_apache_myfaces_PopupCalendar() is
undefined
Key: TOMAHAWK-1409
URL: https://issues.apache.org/jira/browse/TOMAHAWK-1409
Project: MyFaces Tomahawk
Issue Type: Bug
Components: Calendar
Affects Versions: 1.1.8
Reporter: Klaus Schuster
Priority: Critical
Hi,
I am using a t:inputCalendar tag from Tomahawk 1.1.8:
view plaincopy to clipboardprint?
t:inputCalendar id=mycal
addResources=false
monthYearRowClass=yearMonthHeader
weekRowClass=weekHeader
popupButtonStyleClass=standard_bold
currentDayCellClass=currentDayCell
value=#{BB.geburtsdatum}
renderAsPopup=true
popupTodayString=Heute ist der:
helpText=MM/DD/
/t:inputCalendar
h:outputText value=#{BB.geburtsdatum} /
t:inputCalendar id=mycal
addResources=false
monthYearRowClass=yearMonthHeader
weekRowClass=weekHeader
popupButtonStyleClass=standard_bold
currentDayCellClass=currentDayCell
value=#{BB.geburtsdatum}
renderAsPopup=true
popupTodayString=Heute ist der:
helpText=MM/DD/
/t:inputCalendar
h:outputText value=#{BB.geburtsdatum} /
geburtsdatum is a DATE in my BB with its getter and setter.
The t:inputCalendar is embedded in an form.
When I open the JSF Page with Internet Explorer 6 I get the following
JavaScript error:
view plaincopy to clipboardprint?
org_apache_myfaces_PopupCalendar() is undefined
org_apache_myfaces_PopupCalendar() is undefined
I read a lot on the web, and tryed to use the command addResources=false in
combination with
the extension filter in my web.xml:
view plaincopy to clipboardprint?
filter-mapping
filter-nameMyFacesExtensionsFilter/filter-name
servlet-nameFaces Servlet/servlet-name
/filter-mapping
filter-mapping
filter-nameMyFacesExtensionsFilter/filter-name
servlet-nameFaces Servlet/servlet-name
/filter-mapping
My page source code look like this:
view plaincopy to clipboardprint?
input id=frm1:mycal name=frm1:mycal type=text
onfocus=selectText('MM/DD/', 'frm1:mycal')
onclick=selectText('MM/DD/', 'frm1:mycal') value=MM/DD/ /span
id=frm1:mycalSpan/spanscript type=text/javascript!--
frm1_3AmycalCalendarVar=new org_apache_myfaces_PopupCalendar();
frm1_3AmycalCalendarVar.initData.themePrefix = jscalendar-DB;
frm1_3AmycalCalendarVar.initData.imgDir =
/ewc/faces/myFacesExtensionResource/org.apache.myfaces.renderkit.html.util.MyFacesResourceLoader/12385048/calendar.HtmlCalendarRenderer/DB/;
frm1_3AmycalCalendarVar.initData.monthName = new
Array(Januar,Februar,M\u00E4rz,April,Mai,Juni,Juli,August,September,Oktober,November,Dezember);
frm1_3AmycalCalendarVar.initData.dayName = new
Array(Mo,Di,Mi,Do,Fr,Sa,So);
frm1_3AmycalCalendarVar.initData.startAt = 1;
frm1_3AmycalCalendarVar.dateFormatSymbols.weekdays = new
Array(Sonntag,Montag,Dienstag,Mittwoch,Donnerstag,Freitag,Samstag);
frm1_3AmycalCalendarVar.dateFormatSymbols.shortWeekdays = new
Array(So,Mo,Di,Mi,Do,Fr,Sa);
frm1_3AmycalCalendarVar.dateFormatSymbols.shortMonths = new
Array(Jan,Feb,M\u00E4r,Apr,Mai,Jun,Jul,Aug,Sep,Okt,Nov,Dez);
frm1_3AmycalCalendarVar.dateFormatSymbols.months = new
Array(Januar,Februar,M\u00E4rz,April,Mai,Juni,Juli,August,September,Oktober,November,Dezember);
frm1_3AmycalCalendarVar.dateFormatSymbols.eras = new Array(v. Chr.,n.
Chr.);
frm1_3AmycalCalendarVar.dateFormatSymbols.ampms = new Array(AM,PM);
frm1_3AmycalCalendarVar.initData.todayString = Heute ist der: ;
frm1_3AmycalCalendarVar.initData.popupLeft = false;
frm1_3AmycalCalendarVar.initData.selectMode = day;
frm1_3AmycalCalendarVar.init(document.getElementById('frm1:mycalSpan'));
//--/scriptinput type=button
onclick=frm1_3AmycalCalendarVar._popUpCalendar(this,document.getElementById('frm1:mycal'),'dd.MM.yy')
value=... class=standard_bold //div
input id=frm1:mycal name=frm1:mycal type=text
onfocus=selectText('MM/DD/', 'frm1:mycal')
onclick=selectText('MM/DD/', 'frm1:mycal') value=MM
[jira] Commented: (ORCHESTRA-39) Conversations are not cleaned up if session timeout is near conversation timeout
[ https://issues.apache.org/jira/browse/ORCHESTRA-39?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12689192#action_12689192 ] Simon Kitching commented on ORCHESTRA-39: - This looks pretty good to me. One minor note: I think new method ConversationWiperThread.removeAndInvalidateConversationManager is better as a private method on the ConversationManagerSessionListener class. There is also a spelling mistake in this method name: removeAndInvalidateConversationContextAndChilden Childen -- Children Possibly new methods protected ConversationManager.removeAndInvalidateAllConversationContexts private ConversationManager.removeAndInvalidateConversationContextAndChildren could be public. There are already public methods that act on the flat contexts, and we expose the concept of child contexts through public APIs. So I don't see any reason not to make these new methods generally available. I suggest making them public now, and if anyone (eg mario) objects, we can reduce the visibility before the next release. If you're ok with making these minor changes, then please go ahead and commit your patch...and thanks for the fix! Conversations are not cleaned up if session timeout is near conversation timeout Key: ORCHESTRA-39 URL: https://issues.apache.org/jira/browse/ORCHESTRA-39 Project: MyFaces Orchestra Issue Type: Improvement Components: Conversation Affects Versions: 1.3.1 Reporter: Bernd Bohmann Assignee: Simon Kitching Attachments: ORCHESTRA-39.patch The ConversationManager can be removed by the ConversationManagerSessionListener before the ConversationWiperThread has timed out the Conversations. This can cause open PersistenceContext if the session timed out or is invalidated. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (TOMAHAWK-1404) Project Dependencies note mistakenly states There are no dependencies for this project
[ https://issues.apache.org/jira/browse/TOMAHAWK-1404?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12683888#action_12683888 ] Simon Kitching commented on TOMAHAWK-1404: -- Yes, I suppose that some more helpful info could go into that section on the project page. I have now updated the site in SVN to contain the following text. This will appear on the website when the site next gets republished (which only happens occasionally): Note that some specific Tomahawk components need additional libraries. For example, if you use the t:fileUpload component, then you will need to also add the commons-fileupload jarfile to your application classpath (eg in WEB-INF/lib). Components which need additional jars should describe that requirement in their documentation. Note also that this webpage is part of the special site project for all the tomahawk modules (core, sandbox, examples, etc). Therefore the pages under the project documentation menu on the left refer just to this site, and not to the tomahawk library. For information about a specific tomahawk library (dependencies, unit test reports, etc.) select that library from the left menu bar then select the project documentation menu. Thanks for the suggestion. Project Dependencies note mistakenly states There are no dependencies for this project Key: TOMAHAWK-1404 URL: https://issues.apache.org/jira/browse/TOMAHAWK-1404 Project: MyFaces Tomahawk Issue Type: Task Affects Versions: 1.1.8 Environment: NA Reporter: Edward F Eaglehouse Priority: Minor The Project Dependencies page for the project states There are no dependencies for this project. It is a standalone application that does not depend on any other project. This is incorrect. The page needs to be updated to identify the dependency on the Apache Commons FileUpload library. This is a documentation issue only. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [trinidad] add myfaces-builder-annotations version 1.0.2 to components only, so trinidad has myfaces-metadata.xml and trinidad-sanbox uses builder plugin 1.0.2
Leonardo Uribe schrieb: On Mon, Mar 16, 2009 at 3:18 AM, Matthias Wessendorf mat...@apache.org mailto:mat...@apache.org wrote: On Mon, Mar 16, 2009 at 8:42 AM, Leonardo Uribe lu4...@gmail.com mailto:lu4...@gmail.com wrote: Hi It could be good to add myfaces-builder-annotations to trinidad 1.2.x, doing a modification on maven-faces-plugin. please note, that Trinidad still uses the trinidad-maven stuff looking at the POMs: builder-plugin.version1.0.3-SNAPSHOT/builder-plugin.version builder-annotations.version1.0.3-SNAPSHOT/builder-annotations.version are there released version of these plugins ? Trinidad does releases on a frequent cycle, so we somewhat require a released version of the plugins. On the patch there is used 1.0.3-SNAPSHOT, but I have tested it with 1.0.2 and everything works fine. The idea is use 1.0.2. But in my latest code I tried to generate all files, to check that myfaces-builder-plugin can do it. I founded some problems, and did some fixes on 1.0.3-SNAPSHOT. There is a working patch on TRINIDAD-1409, but the idea for now is only add annotations for components and update trinidad sandbox, because some bugs in qdox(not parse enums correctly) and myfaces-builder-plugin 1.0.2 (not handle converter hierarchy) are present. I would like to hear what people think about it before commit this code. This change does not change any code generation procedure for trinidad, and So, we still read the our own metadata, right ? You just add these annotations and they aren't really used ? Or what are you saying. I *think* that there is some future work in the pipeline to enhance the Trinidad metadata, to support the JSR-276 metadata thing. Right now, trinidad sandbox needs to duplicate .xml files to create one component (take a look at trinidad sandbox build project). The idea is just add this annotations on trinidad so trinidad sandbox can use myfaces-builder-plugin to generate components (including in trinidad jars myfaces-metadata.xml). In other words, trinidad project still uses config files on trinidad-build project. myfaces-builder-annotations are just source retention annotations, so no changes are present on compiled files. the intention is just help developers making custom trinidad components. how does that help `? With this change, there is no need of use trinidad sandbox build project to create custom components, replacing it with myfaces-builder-plugin stuff. Quick note: before the myfaces-builder-plugin stuff becomes usable by normal mortals, it does need some better documentation. I tried to do this some months ago, but could not figure out what many of the annotations were for... Regards, Simon
[jira] Created: (TOMAHAWK-1403) t:selectItems behaviour with Map values is weird
t:selectItems behaviour with Map values is weird Key: TOMAHAWK-1403 URL: https://issues.apache.org/jira/browse/TOMAHAWK-1403 Project: MyFaces Tomahawk Issue Type: Bug Affects Versions: 1.1.8 Reporter: Simon Kitching The t:selectItems tag documentation says that the value attribute can return a Map, and that a list of select-items is built using the key and value of the map. The docs are completely wrong. This was originally reported by Johannes Ruthenberg here: http://mail-archives.apache.org/mod_mbox/myfaces-users/200903.mbox/%3c49babcd9.6030...@software-friends.de%3e The situation appears to be that: (a) the myfaces f:selectItems tag handles situations where the value is a Map by building a list of SelectItems from the map value/key automatically. This may not be compliant with the JSF specification; I don't know of anywhere that this behaviour is specified. The class that does this is SelectItemsIterator (from myfaces shared library). (b) The tomahawk t:selectItems tag maps to the AbstractUISelectItems component class. This overrides the handling of Map objects by building the SelectItem list itself, which disables the behaviour from (a) as the SelectItemsIterator never sees the Map object. The AbstractUISelectItems custom Map handling does NOT use the map keys when building the SelectItem list, ie its behaviour is quite different from what SelectItemsIterator does for maps. It does make it possible to do some other things when building the SelectItems list, but using the map key is impossible. It would be nice to know whether behaviour (a) is also implemented in Mojarra. If that behaviour is also in Mojarra, then it would be nice for t:selectItems to be able to behave in a compatible manner. At the least, the t:selectItems documentation needs to be updated in tomahawk/core/src/main/tagdoc/t_selectItems-base.xml The custom Map handling in AbstractUISelectItems was originally added by Cagatay. It is not clear where the wrong documentation came from, but that is more recent. See the email thread for more details. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (MYFACES-2158) Tag inherited from tag class in component hierarchy does not inherit properties [myfaces builder plugin]
[ https://issues.apache.org/jira/browse/MYFACES-2158?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12680771#action_12680771 ] Simon Kitching commented on MYFACES-2158: - Minor comment: correct spelling is deferred, not deffered Tag inherited from tag class in component hierarchy does not inherit properties [myfaces builder plugin] Key: MYFACES-2158 URL: https://issues.apache.org/jira/browse/MYFACES-2158 Project: MyFaces Core Issue Type: Bug Components: build process Reporter: Leonardo Uribe Assignee: Leonardo Uribe Trinidad has a tag called tr:componentRef. Its implementation: org.apache.myfaces.trinidadinternal.taglib.ComponentRefTag inherits from: org.apache.myfaces.trinidadinternal.taglib.UIXComponentRefTag which it is tied to UIXComponentRef In tomahawk, the strategy is create an abstract tag class that can be include before the generated tag class. But this case could be also valid. The solution is when the tree is flattened, inspect tags and if some tag inherit from a component tag class, convert component properties to attributes and inject on tag meta. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [FYI] open discussion list from the JSF 2.0 EG
Matthias Wessendorf schrieb: pretty late, but better than never: http://weblogs.java.net/blog/edburns/archive/2009/03/response_to_a_c.html I love the way this posting says We have opened the process - and by the way, the JSF2.0 spec is finished. With timing like that, Ed should do stand-up comedy.
[VOTE RESULT] Orchestra 1.3.1
Thanks to all who voted. We have: Gerhard Petracek +0 Mario Ivankovits +1 Grant Smith +1 Matthias Wessendorf +1 Simon Kitching +1 I will therefore complete the release process now.. Regards, Simon
[VOTE] Orchestra 1.3.1 release candidate
Hi All, I think it's time to release an update to Orchestra Core; we have about half-a-dozen minor/medium bugs fixed. Therefore I have created a release candidate for orchestra-core 1.3.1. Please have a look at these artifacts and vote: [1] http://people.apache.org/builds/myfaces/m2-staging-repository/org/apache/myfaces/orchestra/myfaces-orchestra-core/1.3.1 [2] http://people.apache.org/~skitching/orchestra-core-1.3.1/index.html [3] https://svn.apache.org/repos/asf/myfaces/orchestra/branches/core-1_3_1-prepare/RELEASE-NOTES.txt Note that the link from the site to the 1.3.1 release notes isn't there yet - it can't be done until after the vote has passed and the release-branch has been made a tag :-). But that's just a trivial site update.. [ ] +1 for community members who have reviewed the bits [ ] +0 [ ] -1 for fatal flaws that should cause these bits not to be released, and why.. Thanks! Simon
[jira] Created: (ORCHESTRA-37) icefaces links and conversationContexts don't work well together
icefaces links and conversationContexts don't work well together Key: ORCHESTRA-37 URL: https://issues.apache.org/jira/browse/ORCHESTRA-37 Project: MyFaces Orchestra Issue Type: Bug Components: Conversation Affects Versions: 1.3 Reporter: Simon Kitching Priority: Minor As reported by hnkwan...@yahoo.com, the conversationContext query parameter does not get correctly set when a page is submitted via an ICEFaces command button component. The html generated for the command-button does not have the query param, ie it would appear that the button renderer is not calling the EncodeURL method.. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (ORCHESTRA-38) richfaces command components don't work with o:separateConversationContext
richfaces command components don't work with o:separateConversationContext -- Key: ORCHESTRA-38 URL: https://issues.apache.org/jira/browse/ORCHESTRA-38 Project: MyFaces Orchestra Issue Type: Bug Components: Conversation Reporter: Simon Kitching As reported by Bernd Winterstein, a richfaces commandButton opens the new page in the same conversation context even when o:separateConversationContext is used. I suspect that the problem is that in the problem case, the commandButton is in an ajax panel that has been already refreshed at least once. And that when a richfaces ajax panel refreshes, the o:separateConversationContext tag outside of the panel is not executed and therefore has not set the magic flag that tells EncodeURL to skip adding the conversationContext=?? parameter. If this is the case, then perhaps the solution involves the EncodeURL method actively looking for an *ancestor component* of type o:separateConversationContext rather than just checking the global flag. Or some kind of hook for the start of the richfaces rendering that looks for any ancestor o:separateConversationContext component. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (ORCHESTRA-30) ViewController does not invoke initView on new instance of same view
[ https://issues.apache.org/jira/browse/ORCHESTRA-30?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12675711#action_12675711 ] Simon Kitching commented on ORCHESTRA-30: - Hmm. We can find which viewcontroller we are about to init by simply calling Object viewController = manager.getViewController(viewId); and then do the init only if we have not invoked that particular instance before. Unfortunately, that doesn't work; the returned view controller bean remains unchanged even when the conversation in which it lives is invalidated. Why? Because it is not actually the controller bean, but instead a spring proxy to it which is cached in request scope for performance. This caching is perfectly valid (even across invalidations) because the proxy looks up its bean dynamically. But it means that this reference is no good for determining if we are invoking the same controller bean or not. We could: (a) somehow check if the ref is a proxy, and if so fetch the real reference (ecch) (b) ensure that these proxies are removed from the request-scope when their conversation is invalidated (ecch) (c) find some other way of deciding when to call initView again. Option (a) really couples the ViewController and the bean-lookup processes more than is desirable. It shouldn't be any business of anything else how the DI adapter decides to proxy managed beans. Option (b) means that the Conversation class needs to be aware that the DI adapter might cache proxies in request scope. That also seems undesirable. But option (c) is also tricky. (1) We can't invoke init whenever the viewroot *instance* changes, because code that simply returns from a navigation method will trigger that, even when the controller bean has not been invalidated. That is a major behaviour change from earlier Orchestra releases. (2) We can't set a global flag when any conversation is invalidated and use that, because the conversation that was invalidated might not be the one in which the controller lives. Maybe we can determine the name of the conversation in which the controller bean lives, then see if that has been recreated? ViewController does not invoke initView on new instance of same view Key: ORCHESTRA-30 URL: https://issues.apache.org/jira/browse/ORCHESTRA-30 Project: MyFaces Orchestra Issue Type: Bug Affects Versions: 1.2 Reporter: Simon Kitching The lifecycle methods for backing beans are executed via the ViewControllerPhaseListener. In particular, for the initView call it checks at the beginning of every phase whether the current view has had the initView run on it for the current request-cycle, and if not then runs it. It therefore needs to remember whether initView has been executed for a view in this request. This is done by keeping a map keyed by viewId. However it is reasonable for an action method to reset a view by calling Conversation.getCurrent().invalidate() return ; In this case, the new view is rendered and a new backing bean is created, but the viewId is the same so the ViewController does not call the initView lifecycle method. One possible workaround is to define a navigation-case using redirect/, which means the new view is rendered in a new request-cycle and therefore the ViewController is run. The code could be changed to use System.identityHashCode(viewRoot) rather than viewRoot.getViewId() as the map key; that would ensure we run the lifecycle methods when the viewRoot *object* changes even if it has the same viewId. But perhaps what we really want is to run the lifecycle method if the backing bean is new, regardless of whether the view-tree is new or not? Looks like we need to more clearly define exactly what initView means -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (TOMAHAWK-1393) t:selectManyCheckbox renders the checkbox after the text when it should be before the text
[ https://issues.apache.org/jira/browse/TOMAHAWK-1393?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12673178#action_12673178 ] Simon Kitching commented on TOMAHAWK-1393: -- Can you please show a (short) example of the html output currently generated? t:selectManyCheckbox renders the checkbox after the text when it should be before the text -- Key: TOMAHAWK-1393 URL: https://issues.apache.org/jira/browse/TOMAHAWK-1393 Project: MyFaces Tomahawk Issue Type: Bug Affects Versions: 1.1.8 Environment: I am using Windows XP with Tomcat 6.0.18 and MyFaces 1.2.5. Reporter: Joe Knudsen Priority: Minor Attachments: screen shot of bug.jpg Original Estimate: 2h Remaining Estimate: 2h When using the t:selectManyCheckbox component the checkbox is on the wrong side. When I use h:selectManyCheckbox that works but I wanted two columns and the layoutWidth is support in Tomahawk. Seems like an easy issue to resolve. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (TRINIDAD-1389) multiple browser tab should not share same session state
[ https://issues.apache.org/jira/browse/TRINIDAD-1389?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12671041#action_12671041 ] Simon Kitching commented on TRINIDAD-1389: -- Detecting different browser windows is a really nasty issue. I've spent a lot of time thinking about this and eventually concluded that there is *no* solution to this except changing the http spec so browsers send a window id field in each http request. See here for some related info: http://myfaces.apache.org/orchestra/myfaces-orchestra-core/multiwindow.html If you do come up with a solution, I would be very interested to know! multiple browser tab should not share same session state Key: TRINIDAD-1389 URL: https://issues.apache.org/jira/browse/TRINIDAD-1389 Project: MyFaces Trinidad Issue Type: Improvement Affects Versions: 1.2.10-core Reporter: Matthias Weßendorf Two tabs of the same browser share the same state currently, b/c Trinidad can't distinguish between windows, so the SessionChangeManager can't store the state separately. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [RESULTS] Release of myfaces core 1.2.6
Interesting icon :-) I see the same one here, against directory myfaces-extval-core: http://mirrors.ibiblio.org/pub/mirrors/maven2/org/apache/myfaces/extensions/validator/ Maybe the webserver is detecting the word core and thinking these are core-dump files, so applying an appropriate icon? It doesn't seem to be causing any problems.. Leonardo has already contacted the reposit...@apache.org list regarding the lack of replication to the mirrors. Hopefully someone on that list will let us know what the issue is... Regards, Simon Joe Bohn schrieb: Thanks for driving this Leonardo. I'm wondering if there is some problem with getting the 1.2.6 artifacts out to the mirrors from rsync. They are not yet ibiblio and I see something strange when I look at ibiblio from a browser. Looking at http://mirrors.ibiblio.org/pub/mirrors/maven2/org/apache/myfaces/ I see an icon that resembles a bomb next to myfaces/core rather than the typical folder. Does anybody know what this means? Thanks, Joe Leonardo Uribe wrote: Hi Thanks to all people who vote. We have 6 +1 Grant Smith Gerhard Petracek Bruno Aranda Joe Bohn Matthias Wessendorf Leonardo Uribe So I'll continue with the necessary steps to release myfaces core 1.2.6 regards Leonardo Uribe
[jira] Commented: (MYFACES-2141) NotSerializable Component: HtmlInputDate
[ https://issues.apache.org/jira/browse/MYFACES-2141?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12668067#action_12668067 ] Simon Kitching commented on MYFACES-2141: - Ah - I thought you had written a component that has inherited from HtmlInputDate. Binding should *never* be used for objects that have anything other than request scope. There are a number of horrible consequences otherwise. This is weird anyway - if you just have a bean that has a member of type HtmlInputDate, then I don't see why changing the SERIALIZE_STATE_IN_SESSION setting would do anything. It would make a difference if you had written a custom component that didn't implement StateHolder (my original misunderstanding). But serializing the tree shouldn't cause your backing beans to be serialized. Are you perhaps also using tomahawk's t:saveState (which saves beans into the component tree)? Anyway, this is almost certainly NOT a bug in myfaces - components are not required to implement java.io.Serializable. So please close this as INVALID then subscribe to the myfaces user list and post your question there. NotSerializable Component: HtmlInputDate Key: MYFACES-2141 URL: https://issues.apache.org/jira/browse/MYFACES-2141 Project: MyFaces Core Issue Type: Bug Affects Versions: 1.2.5 Environment: tomcat 6.0.18, myfaces 1.2.5, tomahawk 1.1.8 for jsf1.2 Reporter: Andrej Konkow When changing the config in web.xml from param-nameorg.apache.myfaces.SERIALIZE_STATE_IN_SESSION/param-name param-valuefalse/param-value to param-nameorg.apache.myfaces.SERIALIZE_STATE_IN_SESSION/param-name param-valuetrue/param-value my pages don't get rendered properly any more. One exception is: [2009-01-26 20:14:25,968] [http-8080-2] [ERROR] javax.faces.webapp._ErrorPageWriter - An exception occurred javax.faces.FacesException: java.io.NotSerializableException: org.apache.myfaces.custom.date.HtmlInputDate Hint: My java-class is inheriting from another class in which an attribute is existing of type org.apache.myfaces.custom.date.HtmlInputDate -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [myfaces core] release files version 1.2.6 not replicated on maven main repository
Leonardo Uribe schrieb: Hi I published the files for release myfaces core 1.2.6 on rsync repository http://people.apache.org/repo/m2-ibiblio-rsync-repository but there aren't on repo1.maven.org http://repo1.maven.org repo yet (more than 24 hours has passed) Does anyone knows what to do in this case? Syncing happens just once a day now, so in the unlucky case you *do* have to wait 24 hours. If nothing has happened after that time, and you've checked that the files and dirs are all readable, then contact list reposit...@apache.org which has some very helpful people on it. Regards, Simon -- -- Emails in mixed posting style will be ignored -- (http://en.wikipedia.org/wiki/Posting_style)
[jira] Commented: (MYFACES-2135) Remove @Deprecated annotations inserted on api methods, since this annotation is runtime type and changes method signature (a tck test fails if this annotation is pres
[ https://issues.apache.org/jira/browse/MYFACES-2135?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12667807#action_12667807 ] Simon Kitching commented on MYFACES-2135: - Just a note for future reference: the changes method signature comment here means that the Sun JSF TCK is complaining. It really should not; if the methods can be annotated with the javadoc @deprecated comment, then there is no sane reason why the more modern @Deprecated annotation should not be allowed. However getting the TCK fixed is difficult or maybe impossible, so the (perfectly valid) @Deprecated annotations have been removed from the myfaces source instead. Remove @Deprecated annotations inserted on api methods, since this annotation is runtime type and changes method signature (a tck test fails if this annotation is present) --- Key: MYFACES-2135 URL: https://issues.apache.org/jira/browse/MYFACES-2135 Project: MyFaces Core Issue Type: Bug Affects Versions: 1.2.5 Reporter: Leonardo Uribe Assignee: Leonardo Uribe Fix For: 1.2.6 The list of changes is this: javax.faces.component.UICommand.getAction():anno 0 java.lang.Deprecated() javax.faces.component.UICommand.getActionListener():anno 0 java.lang.Deprecated() javax.faces.component.UICommand.setAction(javax.faces.el.MethodBinding): anno 0 java.lang.Deprecated() javax.faces.component.UICommand.setActionListener(javax.faces.el.MethodBinding):anno 0 java.lang.Deprecated() javax.faces.component.UIInput.getValueChangeListener(): anno 0 java.lang.Deprecated() javax.faces.component.UIInput.getValueChangeListener(): anno 0 java.lang.Deprecated() javax.faces.component.UIInput.getValueChangeListener(): anno 0 java.lang.Deprecated() javax.faces.component.UIInput.getValueChangeListener(): anno 0 java.lang.Deprecated() javax.faces.component.UIInput.setValidator(javax.faces.el.MethodBinding): anno 0 java.lang.Deprecated() javax.faces.component.UIInput.setValidator(javax.faces.el.MethodBinding): anno 0 java.lang.Deprecated() javax.faces.component.UIInput.setValidator(javax.faces.el.MethodBinding): anno 0 java.lang.Deprecated() javax.faces.component.UIInput.setValidator(javax.faces.el.MethodBinding): anno 0 java.lang.Deprecated() javax.faces.component.UIInput.setValueChangeListener(javax.faces.el.MethodBinding): anno 0 java.lang.Deprecated() javax.faces.component.UIInput.setValueChangeListener(javax.faces.el.MethodBinding): anno 0 java.lang.Deprecated() javax.faces.component.UIInput.setValueChangeListener(javax.faces.el.MethodBinding): anno 0 java.lang.Deprecated() javax.faces.component.UIInput.setValueChangeListener(javax.faces.el.MethodBinding): anno 0 java.lang.Deprecated() -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (TOMAHAWK-1389) TableSuggestAjax - security popup in IE7 when using SSL
[ https://issues.apache.org/jira/browse/TOMAHAWK-1389?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12667810#action_12667810 ] Simon Kitching commented on TOMAHAWK-1389: -- IE7 has a paranoid security check: if the main page is loaded via an https url, then it complains if any resource loaded by the page (javascript, css, images) is loaded by a normal http url. This check really is too strict; it catches almost no real bugs, but complains about perfectly sane pages. Well, I suppose it might prevent man in the middle attacks that inject evil javascript. But in practice it causes far more pain than benefit. Other browsers have more sense, and don't bother to apply this check. However given the number of IE7 installations, it is (sigh) reasonable to apply a workaround for this. The fix is to ensure that when JSF components write references into the generated page (javascript, css, images, etc) the generated URL always uses the same scheme as the main page (ie https when the main page is https). In this case, it means a code-chane to the TableSuggestAjax component. Gerd, please view source on the problem page and report any urls in the page that are using http://;. These are the ones that will need to be fixed. TableSuggestAjax - security popup in IE7 when using SSL --- Key: TOMAHAWK-1389 URL: https://issues.apache.org/jira/browse/TOMAHAWK-1389 Project: MyFaces Tomahawk Issue Type: Bug Components: Alias Bean Affects Versions: 1.1.8 Environment: myfaces 1.2.5 tomahawk 1.1.8 sandbox 1.1.7 snapshot facelets 1.1.14 tomcat 6.16 Apache mod_jk 2 (issue also comes up without mod_jk) Reporter: Gerd Schaffer A security popup comes up when using TableSuggestAjax in Internet Explorer 7 (IE7) when using SSL / HTTPS with the message: Warning: This page contains secure and non secure items ... Warnung: Diese Seite enthält sichere und nicht sichere Objekte ... TableSuggestAjax works in IE6, Mozilla, Safari and Google Chrome - just IE7 has this security-issue. what is going on in TableSuggestAjax component? Is there a possibility to fix this (with or without code change)? (telling IE7 not to report this errors (in ie-preferences) is not meant as fix) thank you in advance! -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (TOMAHAWK-1388) CAPTCHA - Add random string to image url. It prevent browser from caching captcha image.
[ https://issues.apache.org/jira/browse/TOMAHAWK-1388?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12666447#action_12666447 ] Simon Kitching commented on TOMAHAWK-1388: -- The committed patch does this: writer.writeAttribute(HTML.SRC_ATTR, url + dummyParameter= + System.currentTimeMillis(), null); Was that perhaps meant to be url+?dummyParameter= ... ? CAPTCHA - Add random string to image url. It prevent browser from caching captcha image. Key: TOMAHAWK-1388 URL: https://issues.apache.org/jira/browse/TOMAHAWK-1388 Project: MyFaces Tomahawk Issue Type: Bug Affects Versions: 1.1.8 Reporter: Marcin Muras Assignee: Hazem Saleh Fix For: 1.1.9-SNAPSHOT Some browser caches image generated by captcha component. It could be greate to have some parameter (e.g. randomString=true/false) telling component to add some random param to image url. It prevent any browser from caching such image. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [VOTE] Release of myfaces core 1.2.6
Leonardo Uribe schrieb: On Thu, Jan 22, 2009 at 2:32 AM, Simon Kitching skitch...@apache.org mailto:skitch...@apache.org wrote: Hi, Could someone explain to me what this is about? https://issues.apache.org/jira/browse/MYFACES-2135 How can @Deprecated annotations change the method signature? Hi If the annotations are marked to be preserved at runtime, they are added to method signature. Anyway, binary compatibility test (using maven clirr plugin) does not show problems if they are present or not, but j2ee tck detects it. Ah ok. So this functionality has to be removed from myfaces in order to keep a broken TCK happy? It would be nicer to fix the TCK...but I expect that is not an easy thing to get done. Do we actually have any channel for reporting bugs in the TCK? BTW, it would be nice for the Jira issue to point out that the TCK is the reason for this change.. Regards, Simon
Re: [VOTE] Release of myfaces core 1.2.6
Hi, Could someone explain to me what this is about? https://issues.apache.org/jira/browse/MYFACES-2135 How can @Deprecated annotations change the method signature? Thanks, Simon
Re: Scanning for annotated classes in MyFaces 2
On Sun, 2009-01-18 at 14:41 +0100, Jan-Kees van Andel wrote: 2009/1/11 Matthias Wessendorf mat...@apache.org: On Sun, Jan 11, 2009 at 4:46 AM, Mario Ivankovits ma...@ops.co.at wrote: ;-) I really hate to wait on the boot-up. :-) -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf Last week I've been playing around with a (non-Reflection) classpath scanner of my own. It's actually not that hard to write (if you have the class file format specification somewhere for reference) and my experience until now is that it's much faster than using Reflection. I have a test webapp which I deploy on Tomcat. This webapp contains about 650 classes. With reflection, it takes about 1500ms to read them all, with my custom home brewn scanner, it only takes between 300ms and 350ms. The only performance tweak I have made was a BufferedInputStream, so I'm sure there is enough room for other improvements (maybe some fork-join algorithm to support parallelism). I haven't really tested memory footprint yet, but 650 classes is still not that much. Current status (I do this in spare time ;-)): - Expose the parsed classes in a developer-friendly format, instead of the raw class file format. (it's like a lite version of the Reflection API, to keep it fast). - Read classes in jars. - Test for possible ClassLoader issues. - Allow users to specify their own searchpaths. - Package filtering. - Search/filter API to allow the developer to only load classes that implement some interface or are tagged with an annotation. If I'm satisfied with the results, we can see if it may fit into MyFaces (or maybe a reusable utility, since there are other projects that need to scan for annotations). It's not that much code and this way there is no need for an additional dependency. That sounds great. What is your general approach? Just read in the class as byte[], then use the class-file-format rules to get to the annotations sections on the class and the methods? From my quick scan of the classfile spec it seemed reasonably easy to do that... I'd be interested to know the actual requirements that MyFaces has for such a scanner. For example, does it ever need to look for annotations on methods when the class itself is not annotated? Your comment about expose parsed classes seems to imply that you are providing some kind of DOM-style API. I would have thought that a SAX-style API would be better, ie various bits of code interested in annotations registers callbacks for annotations it cares about with the scanner. Then the scanner scans all jars in the classpath and when something is found that matches a registered annotation, then it invokes the appropriate callback. That approach would minimise memory usage, and I can't see where we would need anything dom-like... Regards, Simon
[jira] Commented: (MYFACES-1786) Encryption is enabled by default, causing problems if no secret is set
[ https://issues.apache.org/jira/browse/MYFACES-1786?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12663778#action_12663778 ] Simon Kitching commented on MYFACES-1786: - I don't believe this is a bug at all. IMO, state *should* be encrypted by default; no system should default to being insecure. And it also seems reasonable that when the secret is auto-generated then it should be regenerated on restart. In fact, there is no obvious alternative; I can't think of anywhere to store app-scope data over a webserver restart. The real solution here seems for people to just define a constant secret for their webapp, ie define init-parameter org.apache.myfaces.SECRET in the web.xml file. Possibly a WARN message could be output in the startup logs to tell administrators to set that property in web.xml. Encryption is enabled by default, causing problems if no secret is set -- Key: MYFACES-1786 URL: https://issues.apache.org/jira/browse/MYFACES-1786 Project: MyFaces Core Issue Type: Bug Components: General Affects Versions: 1.2.0, 1.2.1-SNAPSHOT Environment: Any Reporter: Jon Harley Priority: Minor According to the documentation of org.apache.myfaces.util.StateUtils To enable encryption, a secret must be provided. StateUtils looks first for the org.apache.myfaces.secret init param, then system properties. If a secret cannot be located, encryption is not used. This is the correct behaviour but in fact the isSecure() method of that class includes: return ! false.equals(ctx.getInitParameter(USE_ENCRYPTION)); This enables encryption in ALL cases except where the init parameter is PRESENT and EQUAL to false. For example if it is absent, encryption is enabled. It looks as though a secret is then generated. This causes a problem because if the web container is restarted, a new secret is generated. Existing users who then submit any view encoded with the old secret hit an exception in the restore view phase which looks like this, at least in my environment: javax.faces.FacesException: javax.crypto.BadPaddingException: Given final block not properly padded at org.apache.myfaces.shared_impl.util.StateUtils.symmetric(StateUtils.java:370) at org.apache.myfaces.shared_impl.util.StateUtils.symmetric(StateUtils.java:408) at org.apache.myfaces.shared_impl.util.StateUtils.decrypt(StateUtils.java:288) at org.apache.myfaces.shared_impl.util.StateUtils.reconstruct(StateUtils.java:237) at org.apache.myfaces.renderkit.html.HtmlResponseStateManager.getTreeStructureToRestore(HtmlResponseStateManager.java:129) at javax.faces.render.ResponseStateManager.getState(ResponseStateManager.java:81) at org.apache.myfaces.application.jsp.JspStateManagerImpl.restoreView(JspStateManagerImpl.java:283) at org.ajax4jsf.framework.ajax.AjaxStateManager.restoreView(AjaxStateManager.java:83) at org.apache.myfaces.application.jsp.JspViewHandlerImpl.restoreView(JspViewHandlerImpl.java:354) at com.sun.facelets.FaceletViewHandler.restoreView(FaceletViewHandler.java:317) at org.ajax4jsf.framework.ViewHandlerWrapper.restoreView(ViewHandlerWrapper.java:116) at org.ajax4jsf.framework.ajax.AjaxViewHandler.restoreView(AjaxViewHandler.java:147) at org.jenia.faces.template.handler.ViewHandler.restoreView(ViewHandler.java:263) at com.sun.facelets.FaceletViewHandler.restoreView(FaceletViewHandler.java:317) at org.ajax4jsf.framework.ViewHandlerWrapper.restoreView(ViewHandlerWrapper.java:116) at org.ajax4jsf.framework.ajax.AjaxViewHandler.restoreView(AjaxViewHandler.java:147) at org.apache.myfaces.lifecycle.RestoreViewExecutor.execute(RestoreViewExecutor.java:85) at org.apache.myfaces.lifecycle.LifecycleImpl.executePhase(LifecycleImpl.java:95) at org.apache.myfaces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:70) at javax.faces.webapp.FacesServlet.service(FacesServlet.java:137) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at org.ajax4jsf.framework.ajax.xmlfilter.BaseXMLFilter.doXmlFilter(BaseXMLFilter.java:96) at org.ajax4jsf.framework.ajax.xmlfilter.BaseFilter.doFilter(BaseFilter.java:220) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at org.apache.myfaces.webapp.filter.ExtensionsFilter.doFilter(ExtensionsFilter.java:147
[jira] Commented: (MYFACES-1838) javax.crypto.BadPaddingException: Given final block not properly padded
[ https://issues.apache.org/jira/browse/MYFACES-1838?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12663780#action_12663780 ] Simon Kitching commented on MYFACES-1838: - I don't believe this is a bug at all. Unless I've misunderstood something, it's just missing configuration. I think any of the following (in order of preference) should solve this: (1) in web.xml, define init-parameter org.apache.myfaces.SECRET to be some reasonably long string. The server will then use the same encryption secret after restart (instead of generating a key itself), and so will be able to decrypt old sessions. (2) in web.xml, define init-parameter org.apache.myfaces.USE_ENCRYPTION to be false, in order to disable client-side state encryption. Of course this potentially opens a security hole in the app. (3) use server-side state saving (only client-side state is encrypted) javax.crypto.BadPaddingException: Given final block not properly padded --- Key: MYFACES-1838 URL: https://issues.apache.org/jira/browse/MYFACES-1838 Project: MyFaces Core Issue Type: Bug Affects Versions: 1.2.2 Reporter: Guy Bashan Attachments: MYFACES-1838.patch I keep getting this exception from time to time when moving between pages: javax.faces.FacesException: javax.crypto.BadPaddingException: Given final block not properly padded at org.apache.myfaces.shared_impl.util.StateUtils.symmetric(StateUtils.java:373) at org.apache.myfaces.shared_impl.util.StateUtils.symmetric(StateUtils.java:411) at org.apache.myfaces.shared_impl.util.StateUtils.decrypt(StateUtils.java:291) at org.apache.myfaces.shared_impl.util.StateUtils.reconstruct(StateUtils.java:240) at org.apache.myfaces.renderkit.html.HtmlResponseStateManager.getSavedState(HtmlResponseStateManager.java:184) at org.apache.myfaces.renderkit.html.HtmlResponseStateManager.getState(HtmlResponseStateManager.java:136) at org.apache.myfaces.application.jsp.JspStateManagerImpl.restoreView(JspStateManagerImpl.java:289) at org.apache.myfaces.application.jsp.JspViewHandlerImpl.restoreView(JspViewHandlerImpl.java:505) at org.apache.myfaces.lifecycle.RestoreViewExecutor.execute(RestoreViewExecutor.java:85) at org.apache.myfaces.lifecycle.LifecycleImpl.executePhase(LifecycleImpl.java:103) at org.apache.myfaces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:76) at javax.faces.webapp.FacesServlet.service(FacesServlet.java:148) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at com.vdo.admin.model.persistence.OpenSessionInViewFilterIC.doFilterInternal(OpenSessionInViewFilterIC.java:155) at com.vdo.admin.model.persistence.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:61) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at org.apache.myfaces.webapp.filter.ExtensionsFilter.doFilter(ExtensionsFilter.java:147) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:263) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:844) at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:584) at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447) at java.lang.Thread.run(Thread.java:619) Caused by: javax.crypto.BadPaddingException: Given final block not properly padded at com.sun.crypto.provider.SunJCE_f.b(DashoA13*..) at com.sun.crypto.provider.SunJCE_f.b(DashoA13*..) at com.sun.crypto.provider.DESCipher.engineDoFinal(DashoA13*..) at javax.crypto.Cipher.doFinal(DashoA13*..) at org.apache.myfaces.shared_impl.util.StateUtils.symmetric(StateUtils.java:369) ... 30
[jira] Commented: (MYFACES-1786) Encryption is enabled by default, causing problems if no secret is set
[ https://issues.apache.org/jira/browse/MYFACES-1786?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12663782#action_12663782 ] Simon Kitching commented on MYFACES-1786: - Oh, and possibly the code could avoid logging this exception, instead catching all javax.crypto exceptions in StateUtils.symmetric() and instead just logging INFO: postback could not be decrypted; ignoring data. Encryption is enabled by default, causing problems if no secret is set -- Key: MYFACES-1786 URL: https://issues.apache.org/jira/browse/MYFACES-1786 Project: MyFaces Core Issue Type: Bug Components: General Affects Versions: 1.2.0, 1.2.1-SNAPSHOT Environment: Any Reporter: Jon Harley Priority: Minor According to the documentation of org.apache.myfaces.util.StateUtils To enable encryption, a secret must be provided. StateUtils looks first for the org.apache.myfaces.secret init param, then system properties. If a secret cannot be located, encryption is not used. This is the correct behaviour but in fact the isSecure() method of that class includes: return ! false.equals(ctx.getInitParameter(USE_ENCRYPTION)); This enables encryption in ALL cases except where the init parameter is PRESENT and EQUAL to false. For example if it is absent, encryption is enabled. It looks as though a secret is then generated. This causes a problem because if the web container is restarted, a new secret is generated. Existing users who then submit any view encoded with the old secret hit an exception in the restore view phase which looks like this, at least in my environment: javax.faces.FacesException: javax.crypto.BadPaddingException: Given final block not properly padded at org.apache.myfaces.shared_impl.util.StateUtils.symmetric(StateUtils.java:370) at org.apache.myfaces.shared_impl.util.StateUtils.symmetric(StateUtils.java:408) at org.apache.myfaces.shared_impl.util.StateUtils.decrypt(StateUtils.java:288) at org.apache.myfaces.shared_impl.util.StateUtils.reconstruct(StateUtils.java:237) at org.apache.myfaces.renderkit.html.HtmlResponseStateManager.getTreeStructureToRestore(HtmlResponseStateManager.java:129) at javax.faces.render.ResponseStateManager.getState(ResponseStateManager.java:81) at org.apache.myfaces.application.jsp.JspStateManagerImpl.restoreView(JspStateManagerImpl.java:283) at org.ajax4jsf.framework.ajax.AjaxStateManager.restoreView(AjaxStateManager.java:83) at org.apache.myfaces.application.jsp.JspViewHandlerImpl.restoreView(JspViewHandlerImpl.java:354) at com.sun.facelets.FaceletViewHandler.restoreView(FaceletViewHandler.java:317) at org.ajax4jsf.framework.ViewHandlerWrapper.restoreView(ViewHandlerWrapper.java:116) at org.ajax4jsf.framework.ajax.AjaxViewHandler.restoreView(AjaxViewHandler.java:147) at org.jenia.faces.template.handler.ViewHandler.restoreView(ViewHandler.java:263) at com.sun.facelets.FaceletViewHandler.restoreView(FaceletViewHandler.java:317) at org.ajax4jsf.framework.ViewHandlerWrapper.restoreView(ViewHandlerWrapper.java:116) at org.ajax4jsf.framework.ajax.AjaxViewHandler.restoreView(AjaxViewHandler.java:147) at org.apache.myfaces.lifecycle.RestoreViewExecutor.execute(RestoreViewExecutor.java:85) at org.apache.myfaces.lifecycle.LifecycleImpl.executePhase(LifecycleImpl.java:95) at org.apache.myfaces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:70) at javax.faces.webapp.FacesServlet.service(FacesServlet.java:137) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at org.ajax4jsf.framework.ajax.xmlfilter.BaseXMLFilter.doXmlFilter(BaseXMLFilter.java:96) at org.ajax4jsf.framework.ajax.xmlfilter.BaseFilter.doFilter(BaseFilter.java:220) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at org.apache.myfaces.webapp.filter.ExtensionsFilter.doFilter(ExtensionsFilter.java:147) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at net.parkplatz.rr.webframework.Doorkeeper.doFilter(Doorkeeper.java:185) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235
Re: Scanning for annotated classes in MyFaces 2
On Sat, 2009-01-10 at 19:56 -0700, Matthias Wessendorf wrote: On Sat, Jan 10, 2009 at 11:21 AM, Jan-Kees van Andel jankeesvanan...@gmail.com wrote: I don't think Scannotation itself is an issue, but it has a required dependency on Javassist, which has an LGPL license. Isn't that a problem? hrm, I think not really, b/c it's not a direct dependency. I'm pretty sure that scannotation's dependency on an LGLP project is a showstopper. There is some brief info here: http://www.apache.org/legal/resolved.html I'm not sure this approach is a good one anyway. Javasisst's jar is 560kb. That's a fairly heavy dependency for such a simple task as scanning for annotations. Regards, Simon
Re: Scanning for annotated classes in MyFaces 2
Yep, I should have checked the original statement. The javassist website here: http://www.jboss.org/javassist/ states clearly that: quote License: You can choose either MPL or LGPL. /quote Surprising for a jboss project, but the website clearly says so. The MPL is no problem. So using Scannotation is also fine. I'm still not convinced that adding a 560kb dependency for such a simple task is optimal, but simply getting *any* solution in place for myfaces is better than doing multiple scans. It can always be further improved later.. Regards, Simon On Sun, 2009-01-11 at 11:45 +, Mark Struberg wrote: Fwik Javassist uses a Mozilla Public License 1.1 not a pure LGPL (though I've not checked explicitly for the javassist version we use). MPL 1.1 is explicitly listed as appropriate license at least. Maybe we can kick scannotation, and do the scanning ourself (in a later phase). But Javassist is imho a big deal, because we don't need to class-load all classes. Otoh I have to admit that I've never did any performance/memory tests comparing them both. LieGrue, strub --- Simon Kitching skitch...@apache.org schrieb am So, 11.1.2009: Von: Simon Kitching skitch...@apache.org Betreff: Re: Scanning for annotated classes in MyFaces 2 An: MyFaces Development dev@myfaces.apache.org Datum: Sonntag, 11. Januar 2009, 12:06 On Sat, 2009-01-10 at 19:56 -0700, Matthias Wessendorf wrote: On Sat, Jan 10, 2009 at 11:21 AM, Jan-Kees van Andel jankeesvanan...@gmail.com wrote: I don't think Scannotation itself is an issue, but it has a required dependency on Javassist, which has an LGPL license. Isn't that a problem? hrm, I think not really, b/c it's not a direct dependency. I'm pretty sure that scannotation's dependency on an LGLP project is a showstopper. There is some brief info here: http://www.apache.org/legal/resolved.html I'm not sure this approach is a good one anyway. Javasisst's jar is 560kb. That's a fairly heavy dependency for such a simple task as scanning for annotations. Regards, Simon
Re: [jira] Updated: (MYFACES-1347) javax.faces.application.FacesMessage cannot be serialized
Hi Nishi, I see you have attached your patch to the MYFACES-1347 issue. So you just need to wait for one of the people with commit rights to review the patch and commit it. Sending a reminder to this list every week or two is ok, but don't do it too frequently. People are busy (particularly over christmas) so reviewing patches can take time. I do see that you have attached a *complete* copy of the new .java file to the jira issue. Attaching a patch-file (ie the output of svn diff) is easier to review. And attaching a .jar file is not useful; nobody should ever run a jarfile from an unknown source. Regards, Simon On Tue, 2009-01-06 at 16:37 -0500, nishi.s...@us.pwc.com wrote: Hi, I fixed the issue MyFaces-1347 by implementing writeObject and readObject method in FacesMessage class. How do I check in this file to SVN repository? Kindly advice, Thanks and Regards, Nishi Nishi, CISSP CISA | Advisory | PricewaterhouseCoopers | Telephone: +1 732 647 5773 | Facsimile: +1 813 639 3572 | nishi.s...@us.pwc.com Print less, think more. Nishi Shah/US/FAS/p...@americas-us 12/30/2008 07:35 PM Please respond to MyFaces Development dev@myfaces.apache.org Reply to All is Disabled To dev@myfaces.apache.org cc Subject Re: [jira] Updated: (MYFACES-1347) javax.faces.application.FacesMessage cannot be serialized Hello Devs, How do I check in code for this bug fix? https://issues.apache.org/jira/browse/MYFACES-1347 Kindly advise, Thanks and Regards, Nishi Nishi, CISSP CISA | Advisory | PricewaterhouseCoopers | Telephone: +1 732 647 5773 | Facsimile: +1 813 639 3572 | nishi.s...@us.pwc.com Print less, think more. Nishidhdha (JIRA) dev@myfaces.apache.org 12/29/2008 03:50 PM Reply to All is Disabled To Nishi Shah/US/FAS/p...@americas-us cc Subject [jira] Updated: (MYFACES-1347) javax.faces.application.FacesMessage cannot be serialized [ https://issues.apache.org/jira/browse/MYFACES-1347?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nishidhdha updated MYFACES-1347: Status: Patch Available (was: Open) javax.faces.application.FacesMessage cannot be serialized - Key: MYFACES-1347 URL: https://issues.apache.org/jira/browse/MYFACES-1347 Project: MyFaces Core Issue Type: Bug Reporter: Val Blant javax.faces.application.FacesMessage is declared serializable as it should be, but its top level inner memeber class Severity is not serializable. As a result FacesMessage cannot be serialized, which means that no objects that contain a FacesMessage can be serialized
[jira] Created: (ORCHESTRA-35) ConversationManager instances leak when using OC4J servlet engine
ConversationManager instances leak when using OC4J servlet engine - Key: ORCHESTRA-35 URL: https://issues.apache.org/jira/browse/ORCHESTRA-35 Project: MyFaces Orchestra Issue Type: Bug Components: Conversation Affects Versions: 1.3 Reporter: Simon Kitching Priority: Minor As reported by Steve Ronderos, the OC4J servlet container does not call removeAttribute on session attributes when the session is invalidated. This means that the ConversationManagerSessionListener does not remove ConversationManager instances from the ConversationWiperThread when the owning session is destroyed. This is possibly a bug in OC4J; the servlet specs aren't entirely clear what should happen when a session is invalidated but it seems that the HttpSessionBindingListener javadoc does imply that removeAttribute should be called. Apache Tomcat certainly does call removeAttribute (see method StandardSession.removeAttributeInternal for details). Regardless of whether this is a servlet-engine bug or not, this is something that it would be nice to handle. One option would be to use weak references in the ConversationWiperThread. Another would be for ConversationManagerSessionListener to implement the HttpSessionListener interface and use the sessionDestroyed callback to scan for ConversationManager instances and remove them from the wiper thread. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Quite advanced JSF problem
gibiman schrieb: Hi , I'm trying to develop custom AJAX components, and i'm facing some problems on the JSF technology architecture . Pay attention ;) : An action on the page launches an XMLHttpRequest to a certain URL ( .jsf suffix). My aim is to have the JSF engine process only a certain part of the JSF tree , that is the part which contains the children of the component that launched the request ( for example a tabPanel component generates an ajax request , and only that certain tabPanel needs to be processed by the JSF engine ) . My aproach on the problem was to build a listener which would : after RESTORE_VIEW(1) 1. Fetch the UIComponent which launched the request 2. Create a new UIViewRoot and set the new UIViewRoot to the facesContext 3. Add the UICompononet fetched at step 1 as child to the UIviewRoot 4. Invoke action specific behavior of the component - is ok to ignore this part The thing is that new UIViewRoot will get populated - by that i mean all the previous children erased - on renderResponse phase with the JSP tags ( naturally because the engine would return the corresponding viewId ) . If I were to set an invalid viewId , e.g. a page that would not exist, than it would return a 404 page not found response. What are your opinions on my approach , and what alternate suggestions do you have ? Victor What you are describing sounds to me very similar to the AJAX-related work in the upcoming JSF2.0 design. You might want to download the JSF2.0 spec and a JSF2.0 draft implementation and see if it suits your requirements. I have seen a lot of work going into a MyFaces 2.0 implementation, but not sure whether they have the ajax parts done yet: Sun Mojarra is almost certainly ahead at this stage. Regards, Simon -- -- Emails in mixed posting style will be ignored -- (http://en.wikipedia.org/wiki/Posting_style)
[jira] Created: (ORCHESTRA-34) NullPointerException triggered by ConversationWiperThread
NullPointerException triggered by ConversationWiperThread
-
Key: ORCHESTRA-34
URL: https://issues.apache.org/jira/browse/ORCHESTRA-34
Project: MyFaces Orchestra
Issue Type: Bug
Components: Conversation
Affects Versions: 1.3
Reporter: Simon Kitching
As reported by Petr Juza, a NullPointerException can be triggered by the
ConversationWiperThread:
Exception in thread
org.apache.myfaces.orchestra.conversation.ConversationWiperThread
java.lang.NullPointerException
at
org.apache.myfaces.orchestra.conversation.ConversationManager.findConver
sationContextId(ConversationManager.java:140)
at
org.apache.myfaces.orchestra.conversation.ConversationManager.removeAndI
nvalidateConversationContext(ConversationManager.java:343)
at
org.apache.myfaces.orchestra.conversation.ConversationManager.checkTimeo
uts(ConversationManager.java:626)
at
org.apache.myfaces.orchestra.conversation.ConversationWiperThread._run(C
onversationWiperThread.java:113)
at
org.apache.myfaces.orchestra.conversation.ConversationWiperThread.run(Co
nversationWiperThread.java:90)
After initial investigation, the problem appears to be that the
ConversationWiperThread is detecting a ConversationContext timeout, and so is
trying to delete the ConversationContext. However in the
ConversationManager.removeAndInvalidateConversationContext(ctx) method, a check
is done to see if the context being removed is the current one, in order to
prevent code within a request from accidentally deleting the context that is
being used to process that request. However this check requires the
FrameworkAdapter - but there is no FrameworkAdapter instance for a background
thread like the ConversationWiperThread:
public void removeAndInvalidateConversationContext(ConversationContext context)
{
.
if (context.getIdAsLong().equals(findConversationContextId()))
...
where findConversationContextId tries to use FrameworkAdapter to look in the
current HttpRequest object.
Here, we could check whether a FrameworkAdapter exists, and if not then assume
that the context is not the current one. Ideally, we would actually block the
wiper thread from deleting a context if it is locked, but the odds of a
context timing out while actually in use are very low indeed.
I'm a little puzzled why I don't see this exception in the logs for my apps
that use Orchestra...
Note that this exception is fairly harmless: it just disables the
ConversationWiperThread
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
JCP process issues
Here is an interesting blog from one member of the JCP/JSR group for the servlet 3.0 specification. He is one of the Jetty webserver developers, so should know what he is talking about. As someone who has been watching the JSF2.0 spec develop, this all looks very familiar... http://blogs.webtide.com/gregw/entry/servlet_3_0_public_review Regards, Simon
[jira] Created: (ORCHESTRA-33) ConversationContext timeout should be configurable
ConversationContext timeout should be configurable -- Key: ORCHESTRA-33 URL: https://issues.apache.org/jira/browse/ORCHESTRA-33 Project: MyFaces Orchestra Issue Type: Improvement Components: Conversation Affects Versions: 1.3 Reporter: Simon Kitching The ConversationContext class has a timeout property, so that all data in the context will be discarded if the context is not used for the timeout period. The default value is 30 minutes. However there is no obvious way to configure this timeout: * nothing in Orchestra ever calls ConversationContext.setTimeout * the ConversationManager cannot be overridden, as ConversationManager.getInstance calls new ConversationManager directly. Note that setting the ConversationContext timeout is not particularly important; because it is in the http-session, it is deleted when the session is deleted. However if a user has multiple windows open on an app, and then closes a window the ConversationContext continues to exist until the timeout occurs; some people may therefore wish to control how long that timeout is. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (ORCHESTRA-33) ConversationContext timeout should be configurable
[ https://issues.apache.org/jira/browse/ORCHESTRA-33?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12656569#action_12656569 ] Simon Kitching commented on ORCHESTRA-33: - One other note: a ConversationContext object itself doesn't take up much memory. Conversation objects within a context can use significant memory, but they have a separate (and configurable) timeout. ConversationContext timeout should be configurable -- Key: ORCHESTRA-33 URL: https://issues.apache.org/jira/browse/ORCHESTRA-33 Project: MyFaces Orchestra Issue Type: Improvement Components: Conversation Affects Versions: 1.3 Reporter: Simon Kitching The ConversationContext class has a timeout property, so that all data in the context will be discarded if the context is not used for the timeout period. The default value is 30 minutes. However there is no obvious way to configure this timeout: * nothing in Orchestra ever calls ConversationContext.setTimeout * the ConversationManager cannot be overridden, as ConversationManager.getInstance calls new ConversationManager directly. Note that setting the ConversationContext timeout is not particularly important; because it is in the http-session, it is deleted when the session is deleted. However if a user has multiple windows open on an app, and then closes a window the ConversationContext continues to exist until the timeout occurs; some people may therefore wish to control how long that timeout is. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: JavaDoc and checkstyle
I would also prefer to change the checkstyle rules to ignore missing @param and @return comments. Sometimes params really are obvious enough not to be documented, and in some other cases it is better to document them as part of the main method description rather than a separate tag. So blindly enforcing this check doesn't seem helpful... Simon Lessard wrote: To be more precise checkstyle whines about missing @param and @return, which is theoretically nice. However, JSF's JavaDoc is broken and doesn't specifies those most of the time, so the question is is it better to match the official API or to make checkstyle happy? On Tue, Dec 2, 2008 at 6:33 PM, Simon Lessard [EMAIL PROTECTED]wrote: Hi all, It seems that checkstyle doesn't like JSF's official JavaDoc. Personally I would give higher priority to completed comments than checkstyle whining, what you guys think about it? -- View this message in context: http://www.nabble.com/JavaDoc-and-checkstyle-tp20803530p20911066.html Sent from the My Faces - Dev mailing list archive at Nabble.com.
[jira] Commented: (ORCHESTRA-22) portlet: Error creating bean with name 'org.apache.myfaces.orchestra.conversation.AccessScopeManager'
[ https://issues.apache.org/jira/browse/ORCHESTRA-22?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12654743#action_12654743 ] Simon Kitching commented on ORCHESTRA-22: - The current Orchestra developers (Mario and myself) do not use portlets. So getting Orchestra working in portlet environments is waiting for someone who actually uses portlets to step up and do it. There have been no volunteers so far.. portlet: Error creating bean with name 'org.apache.myfaces.orchestra.conversation.AccessScopeManager' - Key: ORCHESTRA-22 URL: https://issues.apache.org/jira/browse/ORCHESTRA-22 Project: MyFaces Orchestra Issue Type: Bug Components: Conversation Affects Versions: 1.1 Environment: myfaces 1.1.5, myfaces-orchestra-core1.1, ascpectel-1.0-Snapshot,liferay portal 4.3.3 Reporter: Rashmi Hello, When I deploy the portal application in Liferay 4.3.3, I am getting the following exception: 2008-04-11 12:59:02,875 ERROR [org.apache.myfaces.lifecycle.PhaseListenerManager] - Exception in PhaseListener RENDER_RESPONSE(6) beforePhase. org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'org.apache.myfaces.orchestra.conversation.AccessScopeManager': Scope 'request' is not active for the current thread; consider defining a scoped proxy for this bean if you intend to refer to it from a singleton; nested exception is java.lang.IllegalStateException: No thread-bound request found: Are you referring to request attributes outside of an actual web request? If you are actually operating within a web request and still receive this message,your code is probably running outside of DispatcherServlet/DispatcherPortlet: In this case, use RequestContextListener or RequestContextFilter to expose the current request. Caused by: java.lang.IllegalStateException: No thread-bound request found: Are you referring to request attributes outside of an actual web request? If you are actually operating within a web request and still receive this message,your code is probably running outside of DispatcherServlet/DispatcherPortlet: In this case, use RequestContextListener or RequestContextFilter to expose the current request. at org.springframework.web.context.request.RequestContextHolder.currentRequestAttributes(RequestContextHolder.java:102) at org.springframework.web.context.request.AbstractRequestAttributesScope.get(AbstractRequestAttributesScope.java:40) at org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:285) at org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:160) at org.springframework.context.support.AbstractApplicationContext.getBean(AbstractApplicationContext.java:733) at org.springframework.web.jsf.DelegatingVariableResolver.resolveVariable(DelegatingVariableResolver.java:122) at org.apache.myfaces.orchestra.frameworkAdapter.jsf.JsfFrameworkAdapter.getBean(JsfFrameworkAdapter.java:174) at org.apache.myfaces.orchestra.conversation.AccessScopeManager.getInstance(AccessScopeManager.java:88) at org.apache.myfaces.orchestra.conversation.jsf.AccessScopePhaseListener.beforePhase(AccessScopePhaseListener.java:91) at org.apache.myfaces.lifecycle.PhaseListenerManager.informPhaseListenersBefore(PhaseListenerManager.java:73) at org.apache.myfaces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:126) at org.apache.myfaces.portlet.MyFacesGenericPortlet.nonFacesRequest(MyFacesGenericPortlet.java:397) at org.apache.myfaces.portlet.MyFacesGenericPortlet.nonFacesRequest(MyFacesGenericPortlet.java:377) at de.seat.common.portlet.jsf.MyFacesFaceletPortlet.facesRender(MyFacesFaceletPortlet.java:156) at org.apache.myfaces.portlet.MyFacesGenericPortlet.doView(MyFacesGenericPortlet.java:323) at javax.portlet.GenericPortlet.doDispatch(GenericPortlet.java:235) at javax.portlet.GenericPortlet.render(GenericPortlet.java:163) at de.seat.common.portlet.jsf.MyFacesFaceletPortlet.render(MyFacesFaceletPortlet.java:117) at com.liferay.portal.kernel.servlet.PortletServlet.service(PortletServlet.java:107) at javax.servlet.http.HttpServlet.service(HttpServlet.java:803) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:269) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:188) at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:691) at org.apache.catalina.core.ApplicationDispatcher.doInclude
myfaces commons modules
Hi, Firstly: I've noticed that the maven repo contains a lot of garbage files. For example, in here: http://repo2.maven.org/maven2/org/apache/myfaces/commons/myfaces-commons-utils12/1.0.0/ there are lots of .asc.asc files. These are created automatically by our maven build commands and should NOT be copied to the maven repo directory. I suggest contacting the [EMAIL PROTECTED] list to get these removed; they don't do any actual harm but are pointless garbage. Secondly: I was looking for the commons-components12 module, but don't see it in the list. Is it missing, or was the components submodule it not part of the 1.0 release? Thanks, Simon
Re: JavaDoc and checkstyle
Hmm..by the way, are you copying-and-pasting the JSF javadoc into myfaces classes? If so, are you sure that this is allowed? Javadoc descriptions would definitely be copyrightable, so explicit permission would be needed to place text released under the CDDL into a file licensed under the Apache license... In Myfaces core 1.1 and 1.2 releases we have been careful to NOT copy any javadoc from the spec.. Regards, Simon Simon Lessard wrote: To be more precise checkstyle whines about missing @param and @return, which is theoretically nice. However, JSF's JavaDoc is broken and doesn't specifies those most of the time, so the question is is it better to match the official API or to make checkstyle happy? On Tue, Dec 2, 2008 at 6:33 PM, Simon Lessard [EMAIL PROTECTED]wrote: Hi all, It seems that checkstyle doesn't like JSF's official JavaDoc. Personally I would give higher priority to completed comments than checkstyle whining, what you guys think about it?
Re: JavaDoc and checkstyle
Hi, I doubt very much that simply retyping javadoc from the spec is legally sufficient to permit non-Aapache-licensed text to be included in an Apache-licensed file. Note that I was *asking* whether copying was allowed; hopefully there is something in the spec licenses that *does* permit it. But if not, then we must follow the relevant copyright laws. I definitely interpreted the original JSF1.1/JSF1.2 specs as NOT permitting copying of javadoc from the spec into our classes. Do you happen to have a link (or even the email subject line) for the earlier discussion? I must have missed that... Note that for dtd and schema files it is pretty easy to avoid copyright issues; the vast majority of such files is data-structure definition that has only one possible form, and therefore is not copyrightable. Simply taking someone else's file is still wrong here, but the original can be used as a reference for the non-copyrightable technical details, so creating the new version is effectively pretty close to just retyping. Javadoc, however, is prose writing which is creative expression. So it should *not* be used as a reference when writing new javadoc; that would be plagiarism. I did create a significant amount of javadoc for the JSF1.1 and JSF1.2 implementations (though still far from complete coverage); my approach was to (a) ensure that the implementation matched the specification description (referencing the original docs) (b) go away for a while (c) some time later, write the javadoc based on the *code* (not using the original docs as a reference) From your other email: quote p.s. I know that 1.1 and 1.2 don't have any JavaDoc copied, actually it only refer to the official one online which isn't very useful for offline users nor those working directly looking at the code. Keeping JavaDoc out is of course a valid option as well if the community wishes it, but it also implies our Maven generated JavaDoc for the site won't be any good. /quote I think the javadoc that was specifically written for myfaces classes is more useful for end-users than the spec stuff (more helpful, less picky technical detail). But yes it is a minority of classes, with most still just linking to the external specs. I'm sure nobody *wants* to keep javadoc external to the classes, but recreating all the docs is a big task, and the alternative (copying) was IMO just not legal. Yes, it's annoying but copyright is copyright. And if we don't follow the law then the spec copyright-holder has every right to sue. IANAL and all that. Regards, Simon K. Simon Lessard schrieb: Hi Simon K., We had that discussion not long ago on another post. We're actually retyping the whole thing, but mimicking the official JavaDoc. Since it's not copied directly it seems it's allowed. ~ Simon On Tue, Dec 9, 2008 at 10:06 AM, Simon Kitching [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Hmm..by the way, are you copying-and-pasting the JSF javadoc into myfaces classes? If so, are you sure that this is allowed? Javadoc descriptions would definitely be copyrightable, so explicit permission would be needed to place text released under the CDDL into a file licensed under the Apache license... In Myfaces core 1.1 and 1.2 releases we have been careful to NOT copy any javadoc from the spec.. Regards, Simon Simon Lessard wrote: To be more precise checkstyle whines about missing @param and @return, which is theoretically nice. However, JSF's JavaDoc is broken and doesn't specifies those most of the time, so the question is is it better to match the official API or to make checkstyle happy? On Tue, Dec 2, 2008 at 6:33 PM, Simon Lessard [EMAIL PROTECTED] mailto:[EMAIL PROTECTED]wrote: Hi all, It seems that checkstyle doesn't like JSF's official JavaDoc. Personally I would give higher priority to completed comments than checkstyle whining, what you guys think about it?
Re: [VOTE] release for tomahawk 1.1.8
Leonardo Uribe schrieb: On Wed, Nov 12, 2008 at 2:45 PM, Leonardo Uribe [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: On Wed, Nov 12, 2008 at 10:58 AM, Simon Kitching [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Leonardo Uribe schrieb: Hi, I was running the needed tasks to get the 1.1.8 release of Apache MyFaces Tomahawk out. Some initial test results: The tomahawk-1.1.8 jar works well with Facelets + Mojarra1.2.0_09 + java1.6. For the staging repo files deployed here: http://people.apache.org/~lu4242/tomahawk118 http://people.apache.org/%7Elu4242/tomahawk118 http://people.apache.org/%7Elu4242/tomahawk118 The binary jar license, manifest all look ok. Checksums all look ok. Oddly, the NOTICE file in the binary jarfile has nothing but the standard ASF claim. However the NOTICE in the source jar has a lot more credits in it. Looks like the NOTICE in the binary file could be wrong... And on both NOTICE files, it says copyright 2004-2007 which should probably be updated. That's strange but true, the notice should be the same for all. I'll take a look. The problem was a override when unpacking shared tomahawk sources. This was fixed and updated the part of copyright to copyright 2004-2008. The new artifacts will be generated after the question about optional dependency to commons is solved. I'm not convinced about this change to the tomahawk pom: !-- Transitive dependency from commons-fileupload. in 1.2 it was declared optional, but t:inputFileUpload uses it indirectly, so it is necessary to include it in our pom as runtime dependency -- dependency groupIdcommons-io/groupId artifactIdcommons-io/artifactId version1.3.2/version scoperuntime/scope /dependency I think that this should indeed be an optional dependency; if someone wants to use Tomahawk but not use the t:inputFileUpload, then why should we force commons-io to be included in their classpath? This change was introduced on 1.1.7, since from commons-io 1.2, this library was marked as optional. From other point of view if someone does not want commons-io to be included in their classpath he/she can exclude it. Good question. In my opinion one or other it is the same (read it as +0 taking the + to let it as is), but I prefer add to the classpath by default because if not, every user of t:inputFileUpload must add this dependency by hand. It could be good to have a community point of view about it. In my opinion, it is more easier use this for exclude commons-io dependency: dependency groupIdorg.apache.myfaces.tomahawk/groupId artifactIdtomahawk/artifactId version1.1.8/version exclusions exclusion groupIdcommons-io/groupId artifactIdcommons-io/artifactId /exclusion /exclusions /dependency In the other case, you need to find the proper version of commons-io (requires that users check tomahawk 1.1.8 pom) and add it as dependency if the user wants to use t:inputFileUpload. Ok, I'm convinced, particularly as this change was already in 1.1.7. So no objection from me on the commons-io dependency. Regards, Simon -- -- Emails in mixed posting style will be ignored -- (http://en.wikipedia.org/wiki/Posting_style)
Re: Cleanup of branches ?
Some release managers have the habit of copying trunk to a branch, then copying the branch to the tags dir (rather than moving it). In this case, deleting the branch makes sense; nothing of value is lost. But for other branches, I would prefer to see them left there. As Matthias points out, anyone checking out the root is screwed anyway as they get all the tag dirs. Removing tags for old releases would be a very bad idea; it's important to have easy traceability of tagged releases. Regards, Simon Matthias Wessendorf schrieb: Hi, I deleted 19 older Trinidad branches: -713669 -713670 Some are still there, and I keep them, since I need them. However, regarding your mistake :-) if one checks out the TAGs as well, that would be more a pain, since we don't delete old TAGs generally (for some reason). Anyways, that said, the Trinidad branches are now cleaned up. The other projects I have no clue but just deleting them, even if there is no response here on the list... is kinda harsh. -Matthias On Wed, Nov 12, 2008 at 11:08 PM, Grant Smith [EMAIL PROTECTED] wrote: Yes, I made that mistake :) It would be nice to reduce the pain of anyone making the same mistake in the future ! On Wed, Nov 12, 2008 at 1:46 PM, Matthias Wessendorf [EMAIL PROTECTED] wrote: yes, I agree. I will take care of the Trinidad branches. However, I wonder why you notice that. Do you check out all branches as well? -M On Wed, Nov 12, 2008 at 9:06 PM, Grant Smith [EMAIL PROTECTED] wrote: Hi All, There seems to be an ever expanding number of branches in svn. I was wondering if we should start clearing some of them out ? I'm more than willing to take this on.. Thanks, -- Grant Smith -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -- Grant Smith -- -- Emails in mixed posting style will be ignored -- (http://en.wikipedia.org/wiki/Posting_style)
[jira] Resolved: (ORCHESTRA-32) Hot-restart of Tomcat causes NullPointerException while deserializing saved http-session
[ https://issues.apache.org/jira/browse/ORCHESTRA-32?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Simon Kitching resolved ORCHESTRA-32. - Resolution: Fixed Fix Version/s: 1.4 Fixed by r713702 Hot-restart of Tomcat causes NullPointerException while deserializing saved http-session Key: ORCHESTRA-32 URL: https://issues.apache.org/jira/browse/ORCHESTRA-32 Project: MyFaces Orchestra Issue Type: Bug Components: Conversation Affects Versions: 1.2 Reporter: Simon Kitching Assignee: Simon Kitching Fix For: 1.4 Tomcat displays this message on restart: SCHWERWIEGEND: Exception loading sessions from persistent storage java.lang.NullPointerException at java.util.concurrent.ConcurrentHashMap.put(ConcurrentHashMap.java:881) at org.apache.catalina.session.StandardSession.readObject(StandardSession.java:1445) The problem is that the orchestra ConversationManager class has a readResolve method that returns null, intending that the object just gets created on demand later. However Tomcat tries to put the deserialized object into its session - and null objects are not permitted in an HttpSession. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (ORCHESTRA-32) Hot-restart of Tomcat causes NullPointerException while deserializing saved http-session
Hot-restart of Tomcat causes NullPointerException while deserializing saved http-session Key: ORCHESTRA-32 URL: https://issues.apache.org/jira/browse/ORCHESTRA-32 Project: MyFaces Orchestra Issue Type: Bug Components: Conversation Affects Versions: 1.2 Reporter: Simon Kitching Assignee: Simon Kitching Tomcat displays this message on restart: SCHWERWIEGEND: Exception loading sessions from persistent storage java.lang.NullPointerException at java.util.concurrent.ConcurrentHashMap.put(ConcurrentHashMap.java:881) at org.apache.catalina.session.StandardSession.readObject(StandardSession.java:1445) The problem is that the orchestra ConversationManager class has a readResolve method that returns null, intending that the object just gets created on demand later. However Tomcat tries to put the deserialized object into its session - and null objects are not permitted in an HttpSession. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Promoting the s:limitRendered component as t:renderOne
Hi All, There was a discussion a while ago on this list about promoting the sandbox s:limitRendered component (written by Andrew Robinson) into tomahawk. There seemed to be general agreement that it was useful, but that some rework should be done, including: * renaming to t:renderOne * simplifying so that it only supports rendering one child, not N. * improving the documentation. There was also discussion about whether it should go into Tomahawk or into the new commons-components module (as it doesn't actually render any html). Although it was agreed to promote into Tomahawk, it looks like nothing actually happened. I was reminded of this today, as I found a situation where it would have been very useful... I'm just reminding people that it exists. I'm off on holiday soon for a few weeks so won't be able to do anything in the near future, but if no-one has dealt with it before I'm back then I intend to do the agreed work to get it ready for promotion. Cheers, Simon
Re: [VOTE] release for tomahawk 1.1.8
Leonardo Uribe schrieb: Hi, I was running the needed tasks to get the 1.1.8 release of Apache MyFaces Tomahawk out. Some initial test results: The tomahawk-1.1.8 jar works well with Facelets + Mojarra1.2.0_09 + java1.6. For the staging repo files deployed here: http://people.apache.org/~lu4242/tomahawk118 http://people.apache.org/%7Elu4242/tomahawk118 The binary jar license, manifest all look ok. Checksums all look ok. Oddly, the NOTICE file in the binary jarfile has nothing but the standard ASF claim. However the NOTICE in the source jar has a lot more credits in it. Looks like the NOTICE in the binary file could be wrong... And on both NOTICE files, it says copyright 2004-2007 which should probably be updated. I'm not convinced about this change to the tomahawk pom: !-- Transitive dependency from commons-fileupload. in 1.2 it was declared optional, but t:inputFileUpload uses it indirectly, so it is necessary to include it in our pom as runtime dependency -- dependency groupIdcommons-io/groupId artifactIdcommons-io/artifactId version1.3.2/version scoperuntime/scope /dependency I think that this should indeed be an optional dependency; if someone wants to use Tomahawk but not use the t:inputFileUpload, then why should we force commons-io to be included in their classpath? Regards, Simon -- -- Emails in mixed posting style will be ignored -- (http://en.wikipedia.org/wiki/Posting_style)
Re: Promoting the s:limitRendered component as t:renderOne
Hi Hazem, If you have time then that would be great! The discussion thread can be found here: http://www.nabble.com/-VOTE--Upgrade-s:limitRendered-to-tomahawk-td18226749.html Regards, Simon Hazem Saleh schrieb: Hi Simon, I can work on this task. On Wed, Nov 12, 2008 at 5:20 PM, Simon Kitching [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Hi All, There was a discussion a while ago on this list about promoting the sandbox s:limitRendered component (written by Andrew Robinson) into tomahawk. There seemed to be general agreement that it was useful, but that some rework should be done, including: * renaming to t:renderOne * simplifying so that it only supports rendering one child, not N. * improving the documentation. There was also discussion about whether it should go into Tomahawk or into the new commons-components module (as it doesn't actually render any html). Although it was agreed to promote into Tomahawk, it looks like nothing actually happened. I was reminded of this today, as I found a situation where it would have been very useful... I'm just reminding people that it exists. I'm off on holiday soon for a few weeks so won't be able to do anything in the near future, but if no-one has dealt with it before I'm back then I intend to do the agreed work to get it ready for promotion. Cheers, Simon -- Hazem Ahmed Saleh Ahmed Author of (The Definitive Guide to Apache MyFaces and Facelets): http://www.amazon.com/Definitive-Guide-Apache-MyFaces-Facelets/dp/1590597370 Web blog: http://www.jroller.com/page/HazemBlog [Web 2.0] Google Maps Integration with JSF: http://code.google.com/p/gmaps4jsf/ http://www.theserverside.com/news/thread.tss?thread_id=51250
Re: Impl compile time dependency to Shared
Previously the shared lib was marked as a provided dependency, and the shared code was physically copied into the project on each build. Someone (I think it was Leonardo) made changes recently to try to make development on myfaces easier, so that when building core maven didn't have to copy over the sources from the shared lib, and only did that when an actual release build was made. This was announced on the list, although not much discussion occurred. But it looks like there is a second step that needs to be made: in release builds the pom also has to avoid having the standard dependency. Maybe a maven profile could be used here, so developers can do: mvn -Pdev clean install which causes the pom to use a standard compile-scope dependency and skip source import, while mvn clean install will cause the shared sources to be imported, and the compile-scope dependency to be excluded. Cheers, Simon Manfred Geiler schrieb: since classes are copied into the myfaces-impl jar, there should not be any dependency at all. but, to force maven to build myfaces-shared-impl first there should be a fake provided dependency. AFAIR this was the case. I wonder if someone has modified/added this dependency lately? --Manfred On Wed, Nov 12, 2008 at 4:27 PM, Bruno Aranda [EMAIL PROTECTED] wrote: If it is not the case, the myfaces-shared-impl should be marked as 'optional' in the impl pom.xml? Bruno 2008/11/12 Cagatay Civici [EMAIL PROTECTED] When I add myfaces-imp 1.2.5 to my pom as a dependency, myfaces-shared-impl-3.0.5.jar also implicitly added to the classpath. It is a problem for myfaces users since now we have the same classes added twice to the classpath. Cagatay -- -- Emails in mixed posting style will be ignored -- (http://en.wikipedia.org/wiki/Posting_style)
Re: SVN question
Another good reason not to use maven-release-plugin :-) Matthias Wessendorf schrieb: http://jira.codehaus.org/browse/SCM-406 On Tue, Nov 11, 2008 at 12:40 PM, Mario Ivankovits [EMAIL PROTECTED] wrote: Probably something went wrong during the copy process and you have old .svn directories in the structure. Check the content of the files in the .svn directory in trinidad-1.0.10/trinidad-api and check if the url points to the correct svn path and not to the trunk or any other tag path. Ciao, Mario -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Matthias Wessendorf Sent: Tuesday, November 11, 2008 11:28 AM To: MyFaces Development Subject: SVN question Hi, a little quiz. I got this output, from my lovely svn tool... svn: Commit failed (details follow): svn: File '/repos/asf/myfaces/trinidad/tags/trinidad-1.0.10/trinidad- api/pom.xml' already exists However, as a matter of fact, there is nothing like this: http://svn.apache.org/viewvc/myfaces/trinidad/tags/ So, I am really really wondering, what is wrong here... Any hint is totally appreciated! -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -- -- Emails in mixed posting style will be ignored -- (http://en.wikipedia.org/wiki/Posting_style)
JSF core TCK - non-javax classes allowed in api jar?
Hi All, A thought just occurred to me. The JSF core spec license (and TCK) require that we do not add any class to the javax.faces namespace which is not in the spec. This is fair, as doing so would confuse users and lead to unportable code. However this limitation has caused some real pain, as we would *like* to have helper methods shared across javax.faces classes which are not in the same package. Our current solution for this is some very ugly templating in the build tools, where we generate classes in the javax.faces packages so that we can paste the same code into them. But does anything in the spec or TCK actually say that the myfaces-api.jar file cannot contain classes in the org.apache.myfaces namespace, or that our implementations of javax.faces classes (eg javax.faces.component.UIComponentBase) cannot then call static methods on those classes or have instances of them as private members? Sun doesn't do that; simply looking at the classes within the jsf-api.jar file shows that it contains nothing that is not in the javax.faces namespace. But are we required to do the same? Adding such classes doesn't seem to me to violate the spirit of JSF at all; the point is to avoid tricking users into writing non-portable code, but we wouldn't be doing that. And if you look at the standard java rt.jar, it contains lots of com.sun classes, and no-one claims that this forces or deceives people into writing non-portable java. Being able to add helper classes into the myfaces-api.jar file would make life simpler in a lot of ways. In fact, is there any reason why JSF needs to be split into two api and impl jar files, rather than just one? Not that I'm suggesting that; but it does seem possible. Regards, Simon -- -- Emails in mixed posting style will be ignored -- (http://en.wikipedia.org/wiki/Posting_style)
Re: JSF core TCK - non-javax classes allowed in api jar?
Matthias Wessendorf schrieb: On Wed, Nov 5, 2008 at 10:55 AM, Simon Kitching [EMAIL PROTECTED] wrote: Hi All, A thought just occurred to me. The JSF core spec license (and TCK) require that we do not add any class to the javax.faces namespace which is not in the spec. This is fair, as doing so would confuse users and lead to unportable code. However this limitation has caused some real pain, as we would *like* to have helper methods shared across javax.faces classes which are not in the same package. Our current solution for this is some very ugly templating in the build tools, where we generate classes in the javax.faces packages so that we can paste the same code into them. But does anything in the spec or TCK actually say that the myfaces-api.jar file cannot contain classes in the org.apache.myfaces namespace, or that our implementations of javax.faces classes (eg javax.faces.component.UIComponentBase) cannot then call static methods on those classes or have instances of them as private members? hrm, I am not sure on this, but doubt it would be OK. Leo acutally has the TCK, perhaps he just could try to add things like that to see what the binary compatibility hammer tells you. Yep, it would be great if Leonardo would be willing to try this out some time... That said, I think it would confuse users of the API JAR, if they see stuff in there... that is not part of the spec... they start to use it and have issues when they say good bye myfaces... I am not really thrilled to add those vendor locks... I think that if anyone has this in their class: import org.apache.myfaces.core._StateHolderHelper; then it should be reasonably obvious to them that they are using a non-portable feature... Sun doesn't do that; simply looking at the classes within the jsf-api.jar file shows that it contains nothing that is not in the javax.faces namespace. But are we required to do the same? Adding such classes doesn't seem to me to violate the spirit of JSF at all; the point is to avoid tricking users into writing non-portable code, but we wouldn't be doing that. And if you look at the standard java rt.jar, it contains lots of com.sun classes, and no-one claims that this forces or deceives people into writing non-portable java. Being able to add helper classes into the myfaces-api.jar file would make life simpler in a lot of ways. In fact, is there any reason why JSF needs to be split into two api and impl jar files, rather than just one? Not that I'm suggesting that; but it does seem possible. In a tool (JDeveloper, Eclipse, name it) you only want the API, since that is specified. The impl is private and not intended for usage in someones application. If we would mix api and impl into one jar... we would expose the stuff from impl, which is mostly not desired when one cares about writing jsf-based apps... You are worried about auto-complete offering non-standard classes as possible completions? I agree that it would be a bad idea to include a class named org.apache.myfaces.core.FacesContext in the myfaces-api.jar file. Some common-sense is needed. Maybe we could adopt the convention that all non-standard classes in the jar start with underscore or similar; that should prevent them popping up when not wanted. But I don't think that simply having org.apache.myfaces classes in the jar is going to confuse anyone that has more than two brain-cells. And it would make the implementation a *lot* easier to work on, with less build magic involved. Regards, Simon
Re: [Orchestra]
Grant Smith schrieb: I noticed there are Orchestra artifacts on the myfaces website, but no links to them from the download page. Is this by design, or can I fix it ? Yes it is deliberate. Orchestra has its own download page here: http://myfaces.apache.org/orchestra/download.html You could possibly put a link from the myfaces generic download page to that page if you want. But please don't add links to the released binaries, as I don't want to have to update that page when I make an Orchestra release. Having a single download page for all myfaces projects is dumb: (a) it doesn't scale; as myfaces gains more projects the page gets hard to use (b) it means that when a project makes a release, the main download page needs to be edited and the main site redeployed. This seems wrong. I think the single download page is really a leftover from the old days where myfaces had just one lib to download: a JSF1.1 implementation. IMO the website should be restructured so that all projects provide their own download page, but I don't have the enthusiasm to actually do anything about it :-) Regards, Simon -- -- Emails in mixed posting style will be ignored -- (http://en.wikipedia.org/wiki/Posting_style)
[orchestra flow] support JSF1.2 only?
Hi, Currently orchestra-flow 0.0.1 supports JSF1.1. However in order to allow pages that declare orchestra flows to be *included* in other pages, eg ui:include src=somePageThatCallsAFlow ui:param name=vname value=value/ /ui:include the EL expressions in the included page need to be build using the correct ELContext object (otherwise they cannot see the params). Rather than build some kind of reflection-based solution, it would be simpler to just ditch JSF1.1 support for orchestra-flow. Note that there are no plans to ditch JSF1.1 support for orchestra-core .. Any objections? Regards, Simon. -- -- Emails in mixed posting style will be ignored -- (http://en.wikipedia.org/wiki/Posting_style)
Re: [orchestra] [VOTE] Orchestra Core 1.3 Release
The orchestra 1.3 release vote has passed with the following votes: Mario Ivankovits +1 Matthias Wessendorf +1 Gerhard Petracek +1 Simon Kitching +1 I will therefore go ahead and deploy the RC artifacts Thanks to those who voted. Regards, Simon
[jira] Commented: (TOMAHAWK-1365) Input field id in error messages is not properly replaced with label text
[ https://issues.apache.org/jira/browse/TOMAHAWK-1365?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12643166#action_12643166 ] Simon Kitching commented on TOMAHAWK-1365: -- And where exactly in the JSF specification does it say that this behaviour is not correct? The fact that you personally might want a different behaviour does not make this a bug... Input field id in error messages is not properly replaced with label text - Key: TOMAHAWK-1365 URL: https://issues.apache.org/jira/browse/TOMAHAWK-1365 Project: MyFaces Tomahawk Issue Type: Bug Components: Message(s) Affects Versions: 1.1.8-SNAPSHOT Reporter: Val Blant Attachments: TOMAHAWK-1365.patch When we have a label associated with an input field via the 'for' attribute on the label, the client id substitution is not properly handled by org.apache.myfaces.renderkit.html.ext.HtmlMessageRenderer.findInputId(). The problem is that when an error message is put together by a converter, javax.faces.convert._MessageUtils.getLabel() places the full clientId of the input component into the message text, whereas HtmlMessageRenderer replaces only the id with the label text. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (TOMAHAWK-1365) Input field id in error messages is not properly replaced with label text
[
https://issues.apache.org/jira/browse/TOMAHAWK-1365?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12643168#action_12643168
]
Simon Kitching commented on TOMAHAWK-1365:
--
Sorry, please ignore previous comment; I hadn't looked carefully enough at your
patch comments.
AIUI, the problem is when using Tomahawk with JSF1.2. In this case, JSF1.2
implementations (both Mojarra and Myfaces 1.2.x) generate conversion-failure
messages by replacing {0} with the full clientId of the component.
Myfaces 1.1.x however replaces {0} with just the clientId of the component.
Tomahawk's custom t:messages component has a special feature to replace the
component id in a message with the component's associated label. But it only
looks for the component's plain id, ie doesn't remove the whole clientId when
it does its message replacement.
Is this right? If so, does your patch work for both myfaces 1.1.x (just
component id) and myfaces 1.2.x (clientId)?
Input field id in error messages is not properly replaced with label text
-
Key: TOMAHAWK-1365
URL: https://issues.apache.org/jira/browse/TOMAHAWK-1365
Project: MyFaces Tomahawk
Issue Type: Bug
Components: Message(s)
Affects Versions: 1.1.8-SNAPSHOT
Reporter: Val Blant
Attachments: TOMAHAWK-1365.patch
When we have a label associated with an input field via the 'for' attribute
on the label, the client id substitution is not properly handled by
org.apache.myfaces.renderkit.html.ext.HtmlMessageRenderer.findInputId().
The problem is that when an error message is put together by a converter,
javax.faces.convert._MessageUtils.getLabel() places the full clientId of the
input component into the message text, whereas HtmlMessageRenderer replaces
only the id with the label text.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: [orchestra] clirr-orchestra-1.2-to-1.3.txt
Mike Kienenberger schrieb: On Fri, Oct 24, 2008 at 5:27 AM, Simon Kitching [EMAIL PROTECTED] wrote: The latest maven-clirr-report plugin unfortunately crashes on orchestra, but I have created a report using clirr trunk; please see here: http://people.apache.org/~skitching/orchestra-core-1.3/clirr-orchestra-1.2-to-1.3.txt I took a look at this since I wasn't sure what it was. I'm guessing it's some kind of api changelog report. Unfortunately, it's in German (at least, that's my guess). Yes it is German. I've been here in Austria too long :-) Clirr (clirr.sourceforge.net) is a wonderful tool that compares two jarfiles and displays the API differences between them. This report therefore shows what API changes have occurred between orchestra 1.2 and the 1.3 release candidate. This report can then be used to (a) look for accidental binary incompatibilities (b) ensure documentation exists for deliberate incompatibilities (c) ensure that classes or methods added since the previous release are all marked with @since Normally running the report is easy; just configure it as a maven report. However as I mentioned, the maven plugin crashes; there is something in orchestra that triggers a bug which is fixed in trunk but not in a plugin release. So I ran this manually (in a german locale). Rather than run the report again, here's a quick translation guide: wurde hinzugefügt == was added wurde als deprecated markiert == marked as deprecated wurde entfernt == was removed Sichtbarkeit der Methode == visibility of method Anything marked as ERROR is a binary incompatibility. Actually there is one case that *is* an incompatibility that clirr has only rated as INFO: a method was promoted from protected to public. This technically can break subclasses that override the method and declare the overriding version as protected. So if you feel enthusiastic, and want to check that the two binary incompatibilities are documented in the release notes, and that all the added methods have an appropriate @since annotation that would be great. But I have already done that.. I included the report in the release info just to point out that this task has been done. Regards, Simon -- -- Emails in mixed posting style will be ignored -- (http://en.wikipedia.org/wiki/Posting_style)
Re: [Orchestra] Drawbacks of Orchestra I'd like to discuss
Mario Ivankovits schrieb: Which does not mean that I am against your ideas. The opposite is the case, if all your promises turn out to be true, and if this realy adds some value, well, why not drop the way Orchestra currently works in favor of your way. Just, I need to see it in action. I feel the same as Mario here. Your ideas are interesting, and *might* turn out great. But as the recent thread shows, we both have a number of significant questions about how this would work in various scenarios. Immediately investing a large amount of time completely rewriting Orchestra from the beginning is a brave step to take; it would be very awkward if it turned out that the new idea didn't work out so well in practice. It would seem more reasonable to add the new functionality as an extension to the existing code rather than as a rewrite. Yes, it might not be so elegant to implement but it would be less to write (you don't need to implement all the existing behaviour on top of your new ideas). And *then* if it works we can talk about refactoring to clean things up. If you do take the approach we suggest: build *on* the existing code, then you can create an svn branch of the orchestra trunk and work there. Then we can reasonably easily merge those changes into trunk if things work out (orchestra core is now fairly stable). And because the new branch is an *enhancement* only, it is no big deal to even release new orchestra versions with your enhancements - the new code won't break existing users because the old code is still the same. This allows people (including Mario and I) to try out the new functionality in our existing large complex systems to see how it works in the real world. That won't be possible if you start again from scratch unless you are *very* careful to replicate the existing functionality correctly. Of course if you really want to implement everything at once (a big rewrite) then that's up to you. If you can come up with a super new implementation that does everything the old implementation does and more then great. But that's quite a big task..incremental development would seem easier. However you choose to work, I'm happy to answer any questions you have about the existing code functionality, but am not likely to contribute code directly (at least until there is something that I can actually test). Orchestra works adequately for me in its current form... Regards, Simon
Re: [Orchestra] Drawbacks of Orchestra I'd like to discuss
Hi Bernhard,
It's great to see some design discussion about Orchestra!
Bernhard Huemer schrieb:
Hi folks,
I've been using Orchestra for a few months now and in doing so I've
been questioning some major implementation decisions, to be more
specific I really want to discuss if it's really necessary to bind
beans to a certain conversation (and therefore also a certein
persistence context!). Let me give you some examples:
Example 1)
I've developed some views for a search dialog that I wanted to use in
at least two different conversations. Everything worked fine for the
first conversation. The following code listing should give you an idea
of the problem.
///
view.xhtml
h:inputText value=#{conversationBean.value} /
spring-bean-config.xml
bean id=conversationBean class=... scope=conversation.manual
orchestra:conversationName=conversationA /
\\\
Maybe some of you have realized my problem by now: The bean somehow
depends on the conversation and as the view depends on the bean I
can't use it with a different conversation (or at least I'm missing a
major feature of Orchestra). :-f
The approach we (Mario I) use in these kind of situations is to
deliberately *not* share a conversation between the calling and called
pages. We pass input parameters to the called page (your search
dialog) and it returns some values. But it doesn't use the conversation
of the caller. Of course this means that it cannot access the
persistence context of the caller; in particular it cannot perform
persistence operations within the persistence context associated with
the caller. In the case of a search type page, that means that the
search dialog just returns the *key* of the record that the user
selected and the caller must then load that object again by key. We
don't find that any major inconvenience.
I actually think this design is an advantage; when a java method calls a
method on a different class, the called code cannot mess with the
private members of the caller, and this is *good*. Equally, when a JSF
view calls another, I don't think that allowing the called view to
mess with the conversation-state of the caller is good. JSF already is
such a loose programming language that we are losing all the benefits
of a strictly-typed programming language; JSF apps can easily degenerate
into spaghetti code and I think allowing free access to
conversation-state from anywhere makes things more dangerous (though
possibly more convenient in the short term).
Mario's reply mentioned the new orchestra flow stuff that I have been
working on. However that works in the same way, just a little more
convenient: the called view(s) still run in their own environment
without access to the caller except for parameters that are explicitly
passed in. In fact, orchestra-flow isolates things even more strongly as
the called flow runs not just in a new conversation, but in a completely
different conversation-context so cannot access existing beans in other
conversation-contexts at all.
An alternative approach might be for the called view to require some
kind of helper object to be passed to it. You can do this via
f:setPropertyActionListener in the calling page. The helper object can
provide methods to do persistence operations, and they will run in
whatever conversation the helper object is in, regardless of what
conversation the called view's backing bean is in. Of course the
helper object could be the backing bean for the calling view itself.
Note that I haven't tried this; however I can't see any reason why it
wouldn't work.
Example 2)
In a different part of the same application I've created a view that
should serve for three different usecases. Basically the view doesn't
change for these usecases at all, but the logic of the backing bean
does. My first approach was to determine the specific page bean at
runtime in the action method that navigates to this view. This action
method was supposed to register the specific page bean under a common
name. So somehow it can be said that I wanted to use polymorphic beans.
///
public String action() {
Conversation conversation = getCurrentConversation();
switch (criterium) {
case CASE_A:
conversation.setAttribute(commonBean, specificBeanA);
break;
case CASE_B:
conversation.setAttribute(commonBean, specificBeanB);
break;
case CASE_C:
conversation.setAttribute(commonBean, specificBeanC);
break;
default:
throw new IllegalStateException(); // shouldn't occur anway
}
return outcome;
}
view.xhtml
h:commandButton action=#{commonBean.save} /
\\\
However, that wouldn't work for two reasons:
- Orchestra only knows how to resolve Spring beans as the bean
definition determines the conversation being used (well, Orchestra
doesn't know how to resolve anything, actually it's the
EL-/VariableResolver of Spring that does this job in this case). It's
only possible to resolve such
Re: AW: [Orchestra] Drawbacks of Orchestra I'd like to discuss
Mario Ivankovits schrieb: Hi! Example 1) I've developed some views for a search dialog that I wanted to use in at least two different conversations. Everything worked fine for the first conversation. The following code listing should give you an idea of the problem. Simon developed Orchestra Flow which might solve this problem as it creates an all new conversation context for this flow and thus can reuse the conversation setup. Simon is still working on it to make it work with our latest requirements, but it should work for many use-cases already. I am not sure if there is a detailed documentation already. Documentation is partially there, on the website and on the wiki. But as the code is changing rapidly the docs are lagging somewhat behind. However I think it likely that that things will stabilise into their final form during this week. However (as noted in my other email) flow won't solve this issue. In fact it sets up even more strict isolation between caller and called views - deliberately. The called view cannot access any conversation-scoped data except its own - and whatever parameters it gets explicitly passed. Of course it is possible to pass as a parameter a helper object that *can* access conversation-scope elsewhere. But that is also possible to do without using orchestra-flow. Example 2) In a different part of the same application I've created a view that should serve for three different usecases. Basically the view doesn't change for these usecases at all, but the logic of the backing bean does. My first approach was to determine the specific page bean at runtime in the action method that navigates to this view. This action method was supposed to register the specific page bean under a common name. So somehow it can be said that I wanted to use polymorphic beans. You might treat it as workaround (which you don't want to hear), but the latest Orchestra provides the method convObject = ConversationUtils.bindToCurrent(object) which allows you to attach all the aspects to any bean you'd like to. Allowing to use that from within the spring configuration is on our todo list. I'm not sure how the new Conversationutils.bindToCurrent would help here.. It is very useful when a conversation-scoped backing bean wants to pass one of its member objects to some other object. But I don't see how it applies to this caller/callee situation. Well, now with Orchestra Flow it might be possible to reach what you want. If I understood that right. You'd like to have a single conversation active for the request instead for a bean. So, creating a SingleConversationScope, this scope then should hold the persistence context in the conversationContext and bind/unbind it on request start/end. Different conversations then are only possible by utilizing Orchestra Flow. How parallel running conversations should work in such a setup, I don't know yet ... The SingleConversationScope class was recently deleted from Orchestra - as discussed on the list. Partly because there did not seem to be any use-case that it was useful for. We can resurrect it if such a use-case is found. But I don't understand the above description...how exactly does it solve the two issues that Bernhard had? Regards, Simon
Re: [Orchestra] Drawbacks of Orchestra I'd like to discuss
Link [1] is obsolete; it is there only for historical purposes. Link [2] is mostly up-to-date. There have been a few changes to the code that are not reflected here, but it is 95% correct and certainly good enough for a general understanding of orchestra-flow. Regards, Simon Gerhard Petracek schrieb: hello, are the wiki pages [1] and [2] up-to-date? regards, gerhard [1] http://wiki.apache.org/myfaces/OrchestraDialogPageFlowDesign1 [2] http://wiki.apache.org/myfaces/OrchestraDialogPageFlowDesign2
[orchestra] [VOTE] Orchestra Core 1.3 Release
Hi All, A release-candidate has been prepared for Orchestra Core 1.3. The release-candidate source is currently at: http://svn.apache.org/repos/asf/myfaces/orchestra/branches/core-1_3-prepare and will be moved to tags dir when/if the release vote passes. The artifacts have been deployed to the staging repository here: http://people.apache.org/builds/myfaces/m2-staging-repository/org/apache/myfaces/orchestra/myfaces-orchestra-core/1.3/ Sorry about the .asc.asc.* files; please ignore those and I will remove them before deploying the final artifacts to the central repo. The latest maven-clirr-report plugin unfortunately crashes on orchestra, but I have created a report using clirr trunk; please see here: http://people.apache.org/~skitching/orchestra-core-1.3/clirr-orchestra-1.2-to-1.3.txt Javadocs etc for this release can be found here: http://people.apache.org/~skitching/orchestra-core-1.3/myfaces-orchestra-core-1.3/site/ The release notes from this version can be found at: http://svn.apache.org/repos/asf/myfaces/orchestra/branches/core-1_3-prepare/RELEASE-NOTES.txt Please have a look at these artifacts and vote: [ ] +1 for community members who have reviewed the bits [ ] +0 [ ] -1 for fatal flaws that should cause these bits not to be released, and why.. Regards, Simon -- -- Emails in mixed posting style will be ignored -- (http://en.wikipedia.org/wiki/Posting_style)
new sandbox component proposal - s:globalId obsoletes forceId
Hi All,
I've always hated the forceId feature of tomahawk for two reasons:
(a) it makes it dangerous to compose pages using facelets templating,
jsp:include or similar
(b) it only works for tomahawk components
There is nothing that can be done about (a); any flattening of the id
is dangerous. But sometimes it is just necessary.
It is possible to do something about (b) though. JSF1.2 adds method
UIComponentBase.getContainerClientId. A trivial component can therefore
be written that prevents any prefix being applied to the ids of its
child components:
f:subview id=mysubview1
h:commandButton id=btn1 ../ # clientId = mysubview1:btn1
s:globalId id=whatever
h:commandButton id=btn2 .../ # clientId=btn2
h:graphicImage id=img1 ../# clientId=img1
/s:globalId
/f:subview
The implementation is trivial:
public class GlobalId extends UIComponentBase implements NamingContainer
{
private final static String COMPONENT_FAMILY = oamc.GlobalId;
public String getFamily()
{
return COMPONENT_FAMILY;
}
public String getContainerClientId(FacesContext facesContext)
{
return null;
}
}
Note that this component would only work for JSF1.2 or later (though it
will compile fine with JSF1.1).
Would this be useful or not?
Regards,
Simon
--
-- Emails in mixed posting style will be ignored
-- (http://en.wikipedia.org/wiki/Posting_style)
MFSANDBOX jira project?
Hi, There was a discussion a few days ago about creating a JIRA project for the myfaces sandbox. Is this going ahead? I'd like to propose a new component for sandbox, and the JIRA sandbox category would be the ideal place to attach the proposed code... Regards, Simon
[jira] Created: (ORCHESTRA-30) ViewController does not invoke initView on new instance of same view
ViewController does not invoke initView on new instance of same view Key: ORCHESTRA-30 URL: https://issues.apache.org/jira/browse/ORCHESTRA-30 Project: MyFaces Orchestra Issue Type: Bug Affects Versions: 1.2 Reporter: Simon Kitching The lifecycle methods for backing beans are executed via the ViewControllerPhaseListener. In particular, for the initView call it checks at the beginning of every phase whether the current view has had the initView run on it for the current request-cycle, and if not then runs it. It therefore needs to remember whether initView has been executed for a view in this request. This is done by keeping a map keyed by viewId. However it is reasonable for an action method to reset a view by calling Conversation.getCurrent().invalidate() return ; In this case, the new view is rendered and a new backing bean is created, but the viewId is the same so the ViewController does not call the initView lifecycle method. One possible workaround is to define a navigation-case using redirect/, which means the new view is rendered in a new request-cycle and therefore the ViewController is run. The code could be changed to use System.identityHashCode(viewRoot) rather than viewRoot.getViewId() as the map key; that would ensure we run the lifecycle methods when the viewRoot *object* changes even if it has the same viewId. But perhaps what we really want is to run the lifecycle method if the backing bean is new, regardless of whether the view-tree is new or not? Looks like we need to more clearly define exactly what initView means -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (ORCHESTRA-31) No warning/error reported when fetching bean from conversation marked as invalidated
No warning/error reported when fetching bean from conversation marked as invalidated Key: ORCHESTRA-31 URL: https://issues.apache.org/jira/browse/ORCHESTRA-31 Project: MyFaces Orchestra Issue Type: Bug Components: Conversation Affects Versions: 1.2 Reporter: Simon Kitching Priority: Minor If a bean A is within conversation A, and a method on the bean does: Conversation.getCurrentInstance().invalidate(); Object o2 = frameworkAdapter.getBean(A); assert(o1 != this); The above will fail; the bean is the same one. The issue is that the invalidate() actually does nothing because the conversation is currently active; we actually delete the conversation after the method returns. And therefore the getBean() call still returns the same object instance. Why is invalidation delayed (ie the Conversation detached from the scope) until the conversation is inactive? It would be nice if an error was returned in this case; it doesn't seem useful to return beans from a conversation after the conversation has been invalidated. Or alternately, unlink the conversation from the SpringConversationScope so that a new conversation instance will be created immediately, even if it isn't invalidated, so that we get new instances of the beans returned. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (TOMAHAWK-1356) Add target java version to MANIFEST.MF
Add target java version to MANIFEST.MF
--
Key: TOMAHAWK-1356
URL: https://issues.apache.org/jira/browse/TOMAHAWK-1356
Project: MyFaces Tomahawk
Issue Type: Improvement
Affects Versions: 1.1.7
Reporter: Simon Kitching
Priority: Minor
The tomahawk jars are compiled with -target set appropriately (1.4 for the
old tomahawk, 1.5 for tomahawk12). However this information is not
available in the MANIFEST.MF file.
It would be nice to add this info to the jarfile so that people can see clearly
what JVM is required. All the apache commons libs do this. Actually, it would
be nice to add all the same settings that commons jars add to MANIFEST.MF
Note that it is possible to tell what version of java the code generates by
using
javap -verbose -classpath {jarfilename} {some-class-in-jar}
which will print something like
SourceFile: HtmlInputTextTag.java
minor version: 0
major version: 49
The major version number can then be looked up to determine what java version
the class is compatible with. But it's not very convenient.
I vaguely remember something like the file command under linux reporting the
java version, but I can't get that to work at the moment.
This is related to TOMAHAWK-1354
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (TOMAHAWK-1354) Tomahawk for JSF 1.2 should be compiled with Java 5 compatibility
[ https://issues.apache.org/jira/browse/TOMAHAWK-1354?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12639751#action_12639751 ] Simon Kitching commented on TOMAHAWK-1354: -- I've created issue TOMAHAWK-1356 which is related to this issue. But as Leonardo points out, the released jar *is* 1.5-compatible so this issue is invalid. For things like this, please ask on the user mailing list; this is a bug-tracker system not a help forum. Tomahawk for JSF 1.2 should be compiled with Java 5 compatibility - Key: TOMAHAWK-1354 URL: https://issues.apache.org/jira/browse/TOMAHAWK-1354 Project: MyFaces Tomahawk Issue Type: Improvement Components: Build Process (Assembly) Affects Versions: 1.1.7 Environment: Java 5, Tomcat 6 Reporter: Rogério Pereira Araújo Assignee: Leonardo Uribe The jar available at central maven repo has been compiled with Java 6 compatibility only, is it correct? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: JIRA: project entry needed for sandbox
The problem is that Leonardo generates the release-notes for Tomahawk using a JIRA report. And this appears to be standard practice for many myfaces projects. So issues related to the sandbox then get listed in the Tomahawk release notes. This confuses users, particularly when a new feature is added to sandbox and it looks like that new feature got added to tomahawk. They then wonder why they can't find it (see emails yesterday in the user list). So either JIRA issues need to be filed against sandbox, or the release-notes need to be created in some other way. I think filing jira issues against sandbox is likely to be the most popular choice. It also feels to me personally like the *right* choice, particularly as sandbox components now often get promoted into myfaces-commons-* projects rather than tomahawk. Regards, Simon Manfred Geiler schrieb: But Sandbox IS a part of Tomahawk and not a single project, so I do not see the problem here. Sandbox issues SHOULD be filed using TOMAHAWK and - of course - the regarding component (SubForm, PPRPanelGroup, ...). -1 for a new Jira project(!) --Manfred On Tue, Oct 14, 2008 at 4:06 PM, Simon Kitching [EMAIL PROTECTED] wrote: Any JIRA admins here? There currently is no JIRA project defined for the myfaces sandbox. It appears that people have simply been using TOMAHAWK to file bugs against. But as recent releases has used a jira report as the release notes this is causing confusion. Can someone please create it? The name SANDBOX is already taken, so perhaps MF-SANDBOX or similar could be used. Perhaps we should file a jira issue to create the new project? :-)
[orchestra] release orchestra-core version 1.3?
Hi All, I think it is a good time to make another Orchestra Core release. There is nothing radical in this new version, but there are a couple of nice new features and a couple of useful bugfixes. See the release notes for further details: http://svn.apache.org/repos/asf/myfaces/orchestra/trunk/core/RELEASE-NOTES.txt The previous release of core was version 1.2 on 15 Jun 2008. Unless there are any objections, I will create a release branch and a release candidate in a couple of days time. Regards, Simon
JIRA: project entry needed for sandbox
Any JIRA admins here? There currently is no JIRA project defined for the myfaces sandbox. It appears that people have simply been using TOMAHAWK to file bugs against. But as recent releases has used a jira report as the release notes this is causing confusion. Can someone please create it? The name SANDBOX is already taken, so perhaps MF-SANDBOX or similar could be used. Perhaps we should file a jira issue to create the new project? :-)
Re: tomahawk examples design proposal
Just a general request: I think it would be nicer for emails to contain *links* to large images rather than include them inline. A copy of every single pixel in an attached image is send through the internet to every person subscribed to the dev list, and they can be scattered around the world from Iceland to New Zealand. It's chewing up a lot of bandwidth...and for some people that may not be free or fast. In addition, the sites that archive these lists are either storing copies of the images (waste) or are not (in which case the archived emails are not useful). Every apache committer has an account on people.apache.org that can be used to store stuff like this on. Or images could be put on the myfaces wiki... Regards, Simon
[Orchestra] Binding an arbitrary instance to a conversation
Hi, As all of you who carefully read commit-messages may have seen (:-), yesterday I committed the ability to call Conversation.bind(instance) so that later calls to any method on that instance will run within the context of the specified conversation (including its associated persistence context if any) [1]. This is useful functionality and I don't think anyone will object. There is one question about the actual implementation, though, that I thought people might have an opinion on. The current approach adds interface ConversationBinder, and a setter method has been added to the Conversation class. Each dependency-injection-specific layer then provides a different implementation of this (eg SpringConversationBinder) when creating Conversation instances. An alternative would be for each dependency-framework to instead return a subclass of Conversation, then the binder interface would not be needed. This approach would potentially be more extensible in future (any future new features requiring tight couplings between conversation and dependency-injection-framework can just be added transparently without new interfaces) but would make the Conversation class a little harder to understand IMO. Both seem reasonable to me; anyone got arguments about preferring one over the other? Or any other issues about those patches in general? [1] Mario came up with this idea, and did an initial prototype. Regards, Smion
[jira] Resolved: (ORCHESTRA-4) Clean up build files
[ https://issues.apache.org/jira/browse/ORCHESTRA-4?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Simon Kitching resolved ORCHESTRA-4. Resolution: Fixed As noted in previous comment, all of the relevant attached patches seem to have been committed. So marking as fixed. Clean up build files Key: ORCHESTRA-4 URL: https://issues.apache.org/jira/browse/ORCHESTRA-4 Project: MyFaces Orchestra Issue Type: Improvement Affects Versions: 1.0 Environment: xp Reporter: Dan Tran Assignee: Mario Ivankovits Attachments: ORCHESTRA-4-2.patch, ORCHESTRA-4-3.patch, ORCHESTRA-4.diff the pom files can be cleanup based on the following facts: - core15 depends on core, therefore lots of core15's dependencies can be removed. There is no need to unpack orchestra-share either - Repositories: remove iblio repo can be removed, maven already includes repo1.maven.org/maven2 use faster java.net maven repo. Refactor repository to the root pom - remove unnessesary unpacking of orchestra-share classes in core since we build it from source any way. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (ORCHESTRA-28) Conversation (Access) is lost when jsf validation fails
[
https://issues.apache.org/jira/browse/ORCHESTRA-28?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Simon Kitching resolved ORCHESTRA-28.
-
Resolution: Fixed
Fixed in trunk. Orchestra now does checks for unaccessed conversations only
after rendering a new view. On validation-failure the viewId does not change,
so unaccessed conversations are never discarded due to validation failure.
Conversation (Access) is lost when jsf validation fails
---
Key: ORCHESTRA-28
URL: https://issues.apache.org/jira/browse/ORCHESTRA-28
Project: MyFaces Orchestra
Issue Type: Bug
Components: Conversation
Affects Versions: 1.1
Reporter: Stefan Glase
Priority: Critical
I am loosing my conversation the bean CategoryController is in, when
required-validation in the view fails.
Without further investigation it looks like it can be explained in the
following way: Orchestra uses a proxy-class to notice calls to
bean-methods,-getters or -setters while in the conversation and when there is
no direct access to the bean from the view, the access scope will be lost.
That is fine in standard cases but when calls only go to the extending class
this behaviour should be considered wrong.
My ugly workaround can be seen in the bottom of the CategoryController
implementation and the view, where I fetch this fake-property just to have a
call to a bean-method.
***
Class: CategoryController
***
@Controller
@Scope(conversation.access)
public class CategoryController extends AbstractCrudControllerCategory {
private CategoryService categoryService;
@Resource
public void setCategoryService(CategoryService categoryService) {
this.categoryService = categoryService;
}
@Override
protected CategoryService getService() {
return this.categoryService;
}
/**
* Bug: Orchestra invalidiert eine Klasse X, welche eine Klasse Y
erweitert, wenn in einem
* Request-Zyklus lediglich Zugriffe auf Methoden und Properties von Y
erfolgt sind.
*
* @return Leerer String
*/
public String getBug() {
return ;
}
}
***
Class: AbstractCrudController
***
public abstract class AbstractCrudControllerT extends PersistentEntity {
private T entity;
public T getEntity() {
return entity;
}
}
***
View: categoryEditForm.xhtml
***
h:form
h:panelGrid columns=3
h:outputLabel value=#{msg.category_name} for=name /
h:inputText size=40 id=name
value=#{categoryController.entity.name}
required=true /
h:message for=name /
h:outputLabel value=#{msg.category_description}
for=description /
h:inputTextarea rows=3 cols=40 id=description
value=#{categoryController.entity.description}
required=true /
h:message for=description /
/h:panelGrid
h:panelGrid columns=2
h:commandButton action=#{categoryController.doSaveEntity}
value=#{msg.category_save} /
/h:panelGrid
!-- === Bug === --
h:outputText value=#{categoryController.bug} /
!-- === End of Bug === --
/h:form
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[Orchestra] SpringSingleConversationScope
Hi Mario, A while ago you added class SpringSingleConversationScope to orchestra with the comment Mostly useful for dialog/flow frameworks. Do we still want this class? I'm not sure what it would be used for; AFAIK the intention is to use a nested conversation context for flows/dialogs, and in that case we can use the normal SpringConversationScope class. Unless there is something I've missed, we can remove this class (it has never been in a released Orchestra version). Thanks, Simon
[jira] Commented: (ORCHESTRA-15) Orchestra in Portal Environment
[ https://issues.apache.org/jira/browse/ORCHESTRA-15?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12638286#action_12638286 ] Simon Kitching commented on ORCHESTRA-15: - Well, it's just that we still have these portal-related issues open: https://issues.apache.org/jira/browse/ORCHESTRA-22 https://issues.apache.org/jira/browse/ORCHESTRA-25 If someone can confirm that they are using Orchestra in a portal and it is working fine then we can close this and the other two issues together. But if there is a problem, then the orchestraPortlet.zip attachment to this issue could be useful to someone working on this. Closing the issue makes it harder to find that useful attachment. Portals are not something I use, so testing/debugging orchestra in a portlet environment is waiting for someone to come along who actually cares about this enough to spend some time on it. It shouldn't be a big deal (in fact it *might* work now). Orchestra in Portal Environment --- Key: ORCHESTRA-15 URL: https://issues.apache.org/jira/browse/ORCHESTRA-15 Project: MyFaces Orchestra Issue Type: Bug Affects Versions: 1.0 Environment: myfaces1.1.5, liferay portal4.3.3, orchestra-core1.0, tomcat 5.5 Reporter: Rashmi Assignee: Mario Ivankovits Priority: Blocker Fix For: 1.1 Attachments: orchestraPortlet.zip, stacktrace.txt In the portlet environment ConversationManager is not getting initialized. The FrameworkAdapter.getCurrentInstance() is as well NULL. The part of the exception is as follows: Caused by: java.lang.NullPointerException at org.apache.myfaces.orchestra.conversation.ConversationManager.getInstance(ConversationManager.java:90) at org.apache.myfaces.orchestra.conversation.ConversationManager.getInstance(ConversationManager.java:76) at org.apache.myfaces.orchestra.conversation.spring.AbstractSpringOrchestraScope.getBean(AbstractSpringOrchestraScope.java:125) at org.apache.myfaces.orchestra.conversation.spring.AbstractSpringOrchestraScope.get(AbstractSpringOrchestraScope.java:117) at org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:285) at org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:160) at org.springframework.aop.target.SimpleBeanTargetSource.getTarget(SimpleBeanTargetSource.java:33) at org.springframework.aop.framework.Cglib2AopProxy$DynamicAdvisedInterceptor.getTarget(Cglib2AopProxy.java:661) at org.springframework.aop.framework.Cglib2AopProxy$DynamicAdvisedInterceptor.intercept(Cglib2AopProxy.java:611) at de.seat.mitarbeiterinfo.view.mitarbeiterlist$$EnhancerByCGLIB$$4f90561b.getMitarbeiterListModel(generated) ... 125 more The filter is not working as expected in Portlet environment but works perfetly well in norman Servlet container. Can myfaces-portlet-bridge be used in someway to configure the filter to run in portlet environment? Thanks and Regards, Rashmi -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (ORCHESTRA-19) refactor conversationContext to allow nested conversationContext
[ https://issues.apache.org/jira/browse/ORCHESTRA-19?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Simon Kitching resolved ORCHESTRA-19. - Resolution: Fixed Trunk now has the ability to create nested conversations and swap between them. So closing this as fixed. refactor conversationContext to allow nested conversationContext Key: ORCHESTRA-19 URL: https://issues.apache.org/jira/browse/ORCHESTRA-19 Project: MyFaces Orchestra Issue Type: Improvement Components: Conversation Reporter: Mario Ivankovits The conversationContext should be enhanced to allow nested conversationContext which is a requirement for dialog/flow implementations to separate the conversations for different flows. The new conversationContext should be able to handle: * a conversation context per windows * multiple named conversationContexts * a stack of conversationContexts to fulfill the requirement a dialog framework has with its subflows Technically this might all be the same conversationContext implementation probably. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Make dev@ private?
Matthias Wessendorf schrieb: On Fri, Sep 5, 2008 at 2:50 AM, Matthias Wessendorf [EMAIL PROTECTED] wrote: On Thu, Sep 4, 2008 at 12:19 PM, Manfred Geiler [EMAIL PROTECTED] wrote: -1 for permissions change for dev@ +1 for a clearer description any native speaker volunteering? Nice move ;-) I wonder if a native speaker has already tried to come up with a better text... I did this in early september when this thread first ran. The myfaces mailing list page now has these descriptions: (http://myfaces.apache.org/mail-lists.html) user: List for posting questions about how to use myfaces projects. Subscribe to this list before posting dev: List for posting patches and discussing internal code implementation issues. Subscribe to this list before posting This seems reasonably clear to me. Regards, Simon
Re: Another approach to the templating problem
Werner Punz schrieb: Paul Rivera schrieb: Interesting solution :) I agree that the execution time of a compiler level solution will be better than an interpreted template solution. Perhaps the only scenario that our interpreted template solution will yeild significant execution performance gain is when it caches large amounts of javascript code. Browsing through the components, most of our large javascript code are already rendered through AddResource which is already cached. The remaining javascript code embedded into some renderers are just not significantly large enough. Do we plan to implement the same convention in myfaces-builder-plugin? I.e. An abstract renderer class that c ontains the javascript template comment A concrete subclass of the one above generated by myfaces-builder-plugin that has the template comment from parent abstract class converted into java code Actually I would go for the concrete implementation approach. The maven plugin of the compiler can take care if picking up the correct files. It even has package rewriting possibilities (I added such a directive to the grammar on thursday) So that people can work on the templated java files and have haven compile the result into the generated sources (and still can link into those if needed, due to being in a different package)... This approach to templating is very interesting..and anything that improves the current StringBuffer-based approach for javascript generation is very nice to see! That code is really hard to work on.. What happens with breakpoints etc? This is always a tricky problem with templates. Generating a subclass does at least mean that breakpoints can be set in the real parent class, and the subclass contains only generated code (for which breakpoints are not much use). If things get magically compiled into a different package, then won't breakpoints set in the original file be ignored? I'm also somewhat concerned about the debuggability of classes when templates and normal code are mixed in the same method. Does this work ok? If not, then is it possible to use the convention of creating a method containing *just* the magic template-comment, with the method parameters as the data referenced from the template? Regards, Simon
Re: Another approach to the templating problem
Werner Punz schrieb: Andrew Robinson schrieb: Think I worded this too strongly, as renderers also produce HTML via Java. I just think that if you are going to have templates, it would be great to keep them in separate files, be it *.vm for velocity or xhtml/xml for facelets/JSF2 or what have you. These files can not only be edited by some tools (at least facelets can, not so sure about velocity), but they can also be changed on the fly without any java recompilation. Java went away from servlets building HTML for this reason and adopted JSP. I personally do not feel that going back to more Java built HTML is going to be a great direction, but maybe that is just me. Actually I am not harsh about myfaces not adopting my solution, it was just an effort to improve readability on the source from my side. No harm is done if we do not adopt it. Problem is as I see it, everything is better for jsf 1.x than the current printwriter API. Even my, and I agree from an academic standpoint dirty, solution. If anyone could provide a decent backport of the JSF2 templating compiler to JSF1 I would be happy as well. (My compiler building knowledge is way too limited to pull this off in a limited time myself) But the problem persists, how are we going to improve the readability of the rendered code and how do we maintain the much needed speed on component level? We are not talking about doing away with any existing templates, right? AIUI we're just talking about replacing a whole bunch of calls to responseWriter.startElement(span) responseWriter.write(hello, + planetName); responseWriter.endElement(span) etc with some kind of in-class templating that compiles down to exactly the same code, but has a more readable syntax. The performance will clearly be exactly the same as the current code, because it results in exactly the same code in the end. Whether it is actually easier to work with is up for debate, but I've spent hours looking at code for the Calendar control trying to figure out exactly what it generates; all those StringBuffer manipulations are really nasty. The current approach sucks for readability. So Werner's proposal is not terribly radical (though clever). It's equivalent to SQLJ, but compiles direct to bytecode rather than java source. Refactoring all the components to use external templating interpreted at runtime is certainly more flexible and elegant but Werner seems to have proved that this is just a no-go from the performance point of view. Pages do often have dozens of components, and rendering dozens of Velocity templates doesn't seem to be feasable. Any template-based approach would have to be one with very high performance. JSP2.0 does support tag files, ie jsp files with suffix .tag that can then be referenced via jsp tags in a page. I would presume that these do get precompiled like other jsp files do, but cannot see how we could hook into that. Same with Facelets; I don't know of a way to have a template processed into an optimised form that the renderer can pass data to; facelets pages are used at build-time to create a view-tree, not at render time when the view-tree is being walked to generate output. I suppose that Werner's templating approach could be applied to *external* templates rather than ones embedded in the class. For example, a HtmlCalendar.tmpl file could exist next to the .java file, and could generate a HtmlCalendarTmpl.class file at compiletime with a static render(Map args) method and a bunch of print statements. This could then be invoked from the calendar component. That does feel cleaner to me than embedding the template within the java code, although the end result is pretty much the same. This then *is* effectively a high-performance template system, although a recompile is required to change the template output. What do you think, Werner? I don't think comparing this to JSP vs hard-coded HTML is fair. Pages are expected to be changed on a daily basis; the representation a JSF component generates will often not change between releases (ie remains untouched for months). One thing I did try a while ago was to simply define a template string in the java class, then use java.text.MessageFormat.format(template, args). But I don't think that the performance is really good enough. Regards, Simon
[jira] Commented: (MYFACES-1976) Enhance build process, unpacking shared only when a release occur and use a dependency to shared instead
[ https://issues.apache.org/jira/browse/MYFACES-1976?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12635962#action_12635962 ] Simon Kitching commented on MYFACES-1976: - Sounds good to me. Enhance build process, unpacking shared only when a release occur and use a dependency to shared instead Key: MYFACES-1976 URL: https://issues.apache.org/jira/browse/MYFACES-1976 Project: MyFaces Core Issue Type: Task Reporter: Leonardo Uribe Attachments: MYFACES-1976-jsf11.patch It could be good use maven profiles to unpack shared sources and add to myfaces core impl jar only when a release occur, and on snapshot version use a dependency to shared jar instead. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Travel Assistance to ApacheCon US 2008 - 3 days to apply!
The Travel Assistance Committee is taking in applications for those wanting to attend ApacheCon US 2008 between the 3rd and 7th November 2008 in New Orleans. The Travel Assistance Committee is looking for people who would like to be able to attend ApacheCon US 2008 who need some financial support in order to get there. There are VERY few places available and the criteria is high, that aside applications are open to all open source developers who feel that their attendance would benefit themselves, their project(s), the ASF and open source in general. Financial assistance is available for flights, accommodation and entrance fees either in full or in part, depending on circumstances. It is intended that all our ApacheCon events are covered, so it may be prudent for those in Europe and or Asia to wait until an event closer to them comes up - you are all welcome to apply for ApacheCon US of course, but there must be compelling reasons for you to attend an event further away that your home location for your application to be considered above those closer to the event location. More information can be found on the main Apache website at http://www.apache.org/travel/index.html - where you will also find a link to the application form and details for submitting. Time is very tight for this event, so applications are open now and will end on the 2nd October 2008 - to give enough time for travel arrangements to be made. Good luck to all those that will apply. Regards, The Travel Assistance Committee
Re: MyFaces shared question
Simon Lessard schrieb: Hi Paul, Simon and others, I guess those are valid concerns, but I see one evolutivity problem, even with a private copy. Let say you have: 1. Shared class A with method foo() in shared x.y.1 2. Core 1.2.1 uses that method as well as Tomahawk 1.2.1 3. For Core 1.2.2, a change is required to foo's contract, releasing shared x.y.2. For now everything is good since Tomahawk has a private copy of x.y.1 4. Tomahawk 1.2.2 also need a change to foo's contract, but not the same as Core 1.2.2 and furthermore excluding the changes needed so applying the change to shared from x.y.1 base, causing a new release of shared x.y.3. Still everything is fine. From that point onward though, foo method will have to get reverted back and forth for both projects in order to include other fixes and improvements, no? Yep. So in that case either a method foo2() needs to be created, or a class A2. Hopefully that doesn't happen too often. As for the current structure, I'm not adamantly against it, so given we keep it, do you think I shared rebranch it for 2.0 or try to use 3.0.x? I would suggest using 3.0.x until you find that something just won't fit, and branch it then. I guess the danger with that is that you could add a bunch of code that only 2.0.x needs and then find you need to branch anyway, leaving a JSF1.2-specific shared version containing code that nothing is using. But the disadvantage of forking is obviously that patches need to be applied to multiple branches. Where's that crystal ball :-) Regards, Simon
Re: Bug in ApplicationImpl
Red schrieb:
Hello.
I decided to upgrade to MyFaces 1.2.4 (from 1.1.something) today, and I
noticed something odd - some of my converters stopped working. I traced
the problem to ApplicationImpl.internalCreateConverter, which appears to
have a bug.
My converter is bound in faces-config.xml to an interface type called
EnumCoded. My enum classes implement EnumCoded, like this:
public enum PickListActionType implements EnumCoded {
. etc...
}
I have a converter called a GenericEnumTypeConverter, which knows how to
deal with these and is declared like this:
converter
converter-for-classEnumCoded/converter-for-class
converter-classGenericEnumTypeConverter/converter-class
/converter
This used to work in MyFaces 1.1, but in 1.2 it looks like the fact that
my type is an enum takes precedence over the fact that it implements
EnumCoded interface, so I end up with the built-in EnumConverter instead
of my GenericEnumTypeConverter.
The solution seems to be to simply reverse the checks on lines 757 and
763 in ApplicationImpl.internalCreateConverter(), so that we check for
interfaces before defaulting to EnumConverter.
Does this look right? Thank you for you help.
Your suggestion looks like a good idea to me.
Of course this issue was not relevant in JSF1.1, as java1.5 native enums
were not supported (JSF1.1 is java1.4-compatible). But for JSF1.2, it
makes a lot of sense to check for an optional interface first.
I suggest you create a JIRA issue for this. If you can provide a patch
(and even better a simple unit test) that would be even better..
Regards,
Simon
