[Trinidad 2.0] introducing ProjectStage API
Hi, here is a (complete?) list of all Trinidad configuration parameters: * System Properties ( = System.getProperty()): org.apache.myfaces.trinidad.CHECK_STATE_SERIALIZATION documentation is here: http://issues.apache.org/jira/browse/TRINIDAD-1245 http://myfaces.apache.org/trinidad/trinidad-api/apidocs/org/apache/myfaces/trinidad/bean/util/StateUtils.html == does not really make sense to port to Stage. * The trinidad-config.xml file: See here for infos about it: http://myfaces.apache.org/trinidad/devguide/configuration.html I think that ONLY this element could make sense: -debug-output (e.g. as for PRODUCTION you want FALSE here... ) * Settings in the WEB.XML (aka Context Parameters): Some info is here as well: http://myfaces.apache.org/trinidad/devguide/configuration.html The web.xml has different types of settings: some fit to ProjectStage, some not.. Here is a grouped list, where I think they don't make sense with project_stage at all: -org.apache.myfaces.trinidad.CACHE_VIEW_ROOT -org.apache.myfaces.trinidad.CLIENT_STATE_METHOD -org.apache.myfaces.trinidad.CLIENT_STATE_MAX_TOKENS -org.apache.myfaces.trinidad.CHANGE_PERSISTENCE -org.apache.myfaces.trinidad.USE_APPLICATION_VIEW_CACHE -org.apache.myfaces.trinidad.ENABLE_LIGHTWEIGHT_DIALOGS -org.apache.myfaces.trinidad.ALTERNATE_VIEW_HANDLER -org.apache.myfaces.trinidad.FACELETS_VIEW_MAPPINGS -org.apache.myfaces.trinidad.UPLOAD_MAX_MEMORY -org.apache.myfaces.trinidad.UPLOAD_MAX_DISK_SPACE -org.apache.myfaces.trinidad.UPLOAD_TEMP_DIR These parameters do make sense: -org.apache.myfaces.trinidad.DEBUG_JAVASCRIPT -org.apache.myfaces.trinidad.DISABLE_CONTENT_COMPRESSION -org.apache.myfaces.trinidad.CHECK_FILE_MODIFICATION -org.apache.myfaces.trinidad.resource.DEBUG (note, we need a bug here, as this is NOT documented in the official documentation :-) ) This parameter _may_ make sense (*caution:* it is an internal and temporary param): -org.apache.myfaces.trinidadinternal.ENABLE_PPR_OPTIMIZATION See http://issues.apache.org/jira/browse/TRINIDAD-1368 So basically, only these make sense (for me): -org.apache.myfaces.trinidad.DEBUG_JAVASCRIPT -org.apache.myfaces.trinidad.DISABLE_CONTENT_COMPRESSION -org.apache.myfaces.trinidad.CHECK_FILE_MODIFICATION -org.apache.myfaces.trinidad.resource.DEBUG -org.apache.myfaces.trinidadinternal.ENABLE_PPR_OPTIMIZATION (*see above) -debug-output Let me know if you agree with this list and I will follow up on what values they should have, in what STAGE A note: Perhaps we want to be able to still override a _SINGLE_ setting, regardless for the current STAGE. Means: If the application runs in ProjectStage.Production, we do CSS compression. BUT... if the web.xml says org.apache.myfaces.trinidad.DISABLE_CONTENT_COMPRESSION = TRUE, we should honor that... This would give users a more fine grained control over these configuration settings. What do you think ? Greetings, Matthias -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf
[jira] Created: (MYFACES-2441) Make _ErrorPageWriter public to allow re-use of default functionality
Make _ErrorPageWriter public to allow re-use of default functionality
-
Key: MYFACES-2441
URL: https://issues.apache.org/jira/browse/MYFACES-2441
Project: MyFaces Core
Issue Type: Improvement
Affects Versions: 1.2.8
Reporter: Caius Gran
Using context parameter org.apache.myfaces.ERROR_HANDLER, you can override
default
error handling functionality. In my case, handling ViewExpiredException's is
particularly useful,
but otherwise the default is fine.
I couldn't do the obvious, because the default error handler is hidden:
public void handleException(FacesContext fc, Exception ex) throws
ServletException, IOException
{
if (ex instanceof ViewExpiredException)
{
// redirect
}
else
{
_ErrorPageWriter.handleException(fc, ex);
}
}
Could the default error handler be exposed and perhaps renamed to something
like DefaultErrorPageWriter?
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: [MyFaces 2.0] how to handle _SystemEventServletRequest and _SystemEventServletResponse classes (attn:Werner)
Hello,
well, of course you could as well just pass the proxy, it would work.
The difference is just that in my version the proxy actually will never
be called, i.e. there's definitely no performance impact. It's just as
I've mentioned a workaround for the not-null-check in the constructor of
those wrapper classes. :-)
regards,
Bernhard
Scott O'Bryan wrote:
I don't know why you couldn't just pass the proxy, and just throw
IllegalOperationExceptions for unrecognized methods. But this one may
be a bit cleaner. Don't know.
Sent from my iPhone
On Dec 1, 2009, at 6:21 PM, Bernhard Huemer bernhard.hue...@gmail.com
wrote:
Hello,
regarding the 1st solution:
According to the JavaDocs the ServletRequestWrapper throws an
IllegalArgumentException if you pass null as delegate, so this won't
work (I'll come back to that later though). However, given that you're
worried about NullPointerExceptions in case someone calls methods that
have been introduced in the Servlet 3.0 version release, I assume that
MyFaces isn't really concerned about those methods anyway. Otherwise
you'd probably override those methods? If I'm mistaken, please correct
me as some suggestions later on rely on this assumption.
regarding the 2nd solution:
Just ignoring the @Override annotation won't work as the respective
interfaces introduce dependencies to artifacts that are only available
in a Servlet 3.0 environment (for example, there's the startAsync()
method that returns an AsyncContext). If a class loader were to load
your request / response dummy class, he would now also have to load
the class AsyncContext as it's a dependency of your class itself,
which apparently the class loader cannot do in a Servlet 2.5 environment.
Given that I'd say you'll have to create two different dummy
implementations, one that implements the Servlet 2.5 ServletRequest
interface and one that implements the Servlet 3.0 ServletRequest (i.e.
the only thing that changes is the set of methods you have to
implement). However, now another problem arises as you can't just use
two different versions of the same API in a single build, i.e. there's
no way to tell the compiler that one class just implements the methods
in the Servlet 2.5 version whereas another class has to implement the
methods of the Servlet 3.0 version. Both versions have to be
compilable using the same Servlet API version and as the Servlet 2.5
API is just a subset of the Servlet 3.0 API, both versions have to be
compilable using the Servlet 3.0 version.
The big issue now is that we've got a contradiction now. If we want to
support a Servlet 3.0 environment, we'll have to use this version in
our build (again, Servlet 3.0 is if I'm not mistaken a superset of
Servlet 2.5, that's the reason for that). However, the 2.5 version of
the dummy class cannot compile if one uses the 3.0 version for the
actual build. Maybe that sounds a little bit strange up until now, but
hopefully now it will get clearer: A 2.5 compatible implementation of
the ServletRequest interface must not implement the method
startAsync as it introduces an unsatisfiable dependency, but a 3.0
compatible build environment requires any implementation to implement
the method startAsync (amongs others) as it is a part of the
interface after all.
Hence I'm afraid but this solution just won't work either. Of course,
the third solution would probably work, but why bother about the
performance implications if there's another solution? :-)
I think the preferable solution is actually the first one. It's easy
to implement as we don't have to deal with the difference between the
Servlet 2.5 API and Servlet 3.0 API, but as I've already mentioned
there is the IllegalArgumentException issue that you just can't ignore
either. We just want to get rid of the null value somehow, so why not
use a dummy proxy instead? Note that there are no performance
implications if you override the wrapped methods anyway, i.e. in fact,
the proxy won't be called even once. It's sole purpose is to replace
the null, that's it. It could look like the following:
///
public class DummyServletRequest extends ServletRequestWrapper {
public DummyServletRequest() {
super(Proxy.newProxyInstance(
DummyServletRequest.class.getClassLoader(),
new Class[] { ServletRequest.class },
new InvocationHandler() {
public Object invoke(Object proxy, Method m, Object[] args) {
throw new UnsupportedOperationException(...);
}
}
);
}
// - Implement the interface ServletRequest now!
public Object getAttribute(String name) {
// ...
}
// ...
}
\\\
Hope that helps. :-)
regards,
Bernhard Huemer
On 12/01/2009 09:48PM GMT, Michael Concini wrote:
I need some help with the best way to handle updating the dummy
request/response objects that we use for system event listeners
kicked off when there isn't a request context. Currently, we're
implementing ServletRequest
[jira] Commented: (TRINIDAD-1650) add support for empty field validation and BeanValidation API
[ https://issues.apache.org/jira/browse/TRINIDAD-1650?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12784715#action_12784715 ] Matthias Weßendorf commented on TRINIDAD-1650: -- code will live in UIXEditableValueTemplate (generates to UIXEditableValue) add support for empty field validation and BeanValidation API --- Key: TRINIDAD-1650 URL: https://issues.apache.org/jira/browse/TRINIDAD-1650 Project: MyFaces Trinidad Issue Type: New Feature Affects Versions: 2.0.0-core Reporter: Matthias Weßendorf Assignee: Matthias Weßendorf JSF 2.0 has support for run validation on empty fields (which integrates with BeanValidation) quoteFromSpec javax.faces.VALIDATE_EMPTY_FIELDS -- If this param is set, and calling toLowerCase().equals(true) on a String representation of its value returns true, all submitted fields will be validated. This is necessary to allow the model validator to decide whether null or empty values are allowable in the current application. If the value is false, null or empty values will not be passed to the validators. If the value is the string auto, the runtime must check if JSR-303 Beans Validation is present in the current environment. If so, the runtime must proceed as if the value true had been specified. If JSR-303 Beans Validation is not present in the current environment, the runtime most proceed as if the value false had been specified. If the param is not set, the system must behave as if the param was set with the value auto. /quoteFromSpec -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (TRINIDAD-1650) add support for empty field validation and BeanValidation API
add support for empty field validation and BeanValidation API --- Key: TRINIDAD-1650 URL: https://issues.apache.org/jira/browse/TRINIDAD-1650 Project: MyFaces Trinidad Issue Type: New Feature Affects Versions: 2.0.0-core Reporter: Matthias Weßendorf Assignee: Matthias Weßendorf JSF 2.0 has support for run validation on empty fields (which integrates with BeanValidation) quoteFromSpec javax.faces.VALIDATE_EMPTY_FIELDS -- If this param is set, and calling toLowerCase().equals(true) on a String representation of its value returns true, all submitted fields will be validated. This is necessary to allow the model validator to decide whether null or empty values are allowable in the current application. If the value is false, null or empty values will not be passed to the validators. If the value is the string auto, the runtime must check if JSR-303 Beans Validation is present in the current environment. If so, the runtime must proceed as if the value true had been specified. If JSR-303 Beans Validation is not present in the current environment, the runtime most proceed as if the value false had been specified. If the param is not set, the system must behave as if the param was set with the value auto. /quoteFromSpec -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (MYFACES-2441) Make _ErrorPageWriter public to allow re-use of default functionality
[
https://issues.apache.org/jira/browse/MYFACES-2441?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12784731#action_12784731
]
Jakob Korherr commented on MYFACES-2441:
I'm afraid the _ErrorPageWriter cannot be exposed, because the class is in
package javax.faces.webapp and it is not part of the JSF spec and thus MyFaces
would not pass the TCK, if it was public.
We could copy it to org.apache.myfaces.webapp and rename it to
DefaultErrorPageWriter, but that would lead to code duplication.
Make _ErrorPageWriter public to allow re-use of default functionality
-
Key: MYFACES-2441
URL: https://issues.apache.org/jira/browse/MYFACES-2441
Project: MyFaces Core
Issue Type: Improvement
Affects Versions: 1.2.8
Reporter: Caius Gran
Original Estimate: 0.25h
Remaining Estimate: 0.25h
Using context parameter org.apache.myfaces.ERROR_HANDLER, you can override
default
error handling functionality. In my case, handling ViewExpiredException's is
particularly useful,
but otherwise the default is fine.
I couldn't do the obvious, because the default error handler is hidden:
public void handleException(FacesContext fc, Exception ex) throws
ServletException, IOException
{
if (ex instanceof ViewExpiredException)
{
// redirect
}
else
{
_ErrorPageWriter.handleException(fc, ex);
}
}
Could the default error handler be exposed and perhaps renamed to something
like DefaultErrorPageWriter?
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: [Trinidad 2.0] introducing ProjectStage API
Hi, I created a quick wiki page for to cover our research: http://wiki.apache.org/myfaces/Trinidad_goes_ProjectStage -Matthias On Wed, Dec 2, 2009 at 10:49 AM, Bruno Aranda brunoara...@gmail.com wrote: Hi, I do agree. The list looks fine to me, and yes, we should allow the users to override parameters when they wish so in the web.xml. Cheers, Bruno 2009/12/2 Matthias Wessendorf mat...@apache.org Hi, here is a (complete?) list of all Trinidad configuration parameters: * System Properties ( = System.getProperty()): org.apache.myfaces.trinidad.CHECK_STATE_SERIALIZATION documentation is here: http://issues.apache.org/jira/browse/TRINIDAD-1245 http://myfaces.apache.org/trinidad/trinidad-api/apidocs/org/apache/myfaces/trinidad/bean/util/StateUtils.html == does not really make sense to port to Stage. * The trinidad-config.xml file: See here for infos about it: http://myfaces.apache.org/trinidad/devguide/configuration.html I think that ONLY this element could make sense: -debug-output (e.g. as for PRODUCTION you want FALSE here... ) * Settings in the WEB.XML (aka Context Parameters): Some info is here as well: http://myfaces.apache.org/trinidad/devguide/configuration.html The web.xml has different types of settings: some fit to ProjectStage, some not.. Here is a grouped list, where I think they don't make sense with project_stage at all: -org.apache.myfaces.trinidad.CACHE_VIEW_ROOT -org.apache.myfaces.trinidad.CLIENT_STATE_METHOD -org.apache.myfaces.trinidad.CLIENT_STATE_MAX_TOKENS -org.apache.myfaces.trinidad.CHANGE_PERSISTENCE -org.apache.myfaces.trinidad.USE_APPLICATION_VIEW_CACHE -org.apache.myfaces.trinidad.ENABLE_LIGHTWEIGHT_DIALOGS -org.apache.myfaces.trinidad.ALTERNATE_VIEW_HANDLER -org.apache.myfaces.trinidad.FACELETS_VIEW_MAPPINGS -org.apache.myfaces.trinidad.UPLOAD_MAX_MEMORY -org.apache.myfaces.trinidad.UPLOAD_MAX_DISK_SPACE -org.apache.myfaces.trinidad.UPLOAD_TEMP_DIR These parameters do make sense: -org.apache.myfaces.trinidad.DEBUG_JAVASCRIPT -org.apache.myfaces.trinidad.DISABLE_CONTENT_COMPRESSION -org.apache.myfaces.trinidad.CHECK_FILE_MODIFICATION -org.apache.myfaces.trinidad.resource.DEBUG (note, we need a bug here, as this is NOT documented in the official documentation :-) ) This parameter _may_ make sense (*caution:* it is an internal and temporary param): -org.apache.myfaces.trinidadinternal.ENABLE_PPR_OPTIMIZATION See http://issues.apache.org/jira/browse/TRINIDAD-1368 So basically, only these make sense (for me): -org.apache.myfaces.trinidad.DEBUG_JAVASCRIPT -org.apache.myfaces.trinidad.DISABLE_CONTENT_COMPRESSION -org.apache.myfaces.trinidad.CHECK_FILE_MODIFICATION -org.apache.myfaces.trinidad.resource.DEBUG -org.apache.myfaces.trinidadinternal.ENABLE_PPR_OPTIMIZATION (*see above) -debug-output Let me know if you agree with this list and I will follow up on what values they should have, in what STAGE A note: Perhaps we want to be able to still override a _SINGLE_ setting, regardless for the current STAGE. Means: If the application runs in ProjectStage.Production, we do CSS compression. BUT... if the web.xml says org.apache.myfaces.trinidad.DISABLE_CONTENT_COMPRESSION = TRUE, we should honor that... This would give users a more fine grained control over these configuration settings. What do you think ? Greetings, Matthias -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf
[jira] Commented: (TRINIDAD-1327) Wrong rendering of inputFile inside panelFormLayout
[
https://issues.apache.org/jira/browse/TRINIDAD-1327?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12784760#action_12784760
]
Markus Döring commented on TRINIDAD-1327:
-
I had a look into the issue and could at least find the cause of it.
In LabelAndMessageRenderer on Line 273 (trinidad 1.0.11 source) the
RootDomElementStyles get rendered, but at this point there are no open tags so
the class= attribute get's rendered outside of the tag.
In trinidad 1.0.7 the RootDomElementStyles where rendered on an tr tag that
was surrounding the panelFormLayout label and content cell.
An comment above the line says to me that this is not the first time that this
point makes trouble, and i don't want to change anything that might have side
effects on other renderers extending the LabelAndMessageRenderer.
Maybe someone deeper into that code could have a look at this.
An possible workaround that works for me is changing the line into:
if(!(component instanceof CoreInputFile)) {
renderRootDomElementStyles(context, arc, component, bean);
}
with this the InputFile get's at least rendered correctly, but it's hacky and
the RootDomElementStyle is completely missing for the InputFile Component.
Wrong rendering of inputFile inside panelFormLayout
---
Key: TRINIDAD-1327
URL: https://issues.apache.org/jira/browse/TRINIDAD-1327
Project: MyFaces Trinidad
Issue Type: Bug
Components: Components
Affects Versions: 1.0.10-core
Reporter: Tomas Havelka
The code below generates corrupted html output for inputFile component. This
happens just when inputFile is enclosed with panelFormLayout component
(locale javascript are rendered in the wrong place?).
f:view
tr:document
tr:form usesUpload=true
tr:panelFormLayout
tr:inputFile label=Input file/
/tr:panelFormLayout
/tr:form
/tr:document
/f:view
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[Trinidad] TRINIDAD-1327 Wrong rendering of inputFile inside panelFormLayout
Hi, I had a look at the issue https://issues.apache.org/jira/browse/TRINIDAD-1327 and added a comment, maybe someone deeper into this code could have another look at it because I think this is a major issue. Regards Markus
Apache Web Profile Edition of the Java EE 6 standard ?
FYI http://markmail.org/message/kbnb2imqdohkra7f -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf
Re: [Trinidad] remove application view cache in Trinidad 2?
Max Starets píše v Út 01. 12. 2009 v 20:42 -0500: Gabrielle, I think the main advantage of using application view cache is that state saving/view root caching is done once for a particular page within an application (that only applies to pages displayed in response to a GET request). Since we have seen some issues with the current implementation, I would vote for not supporting application view cache in Trinidad 2. Partial state saving should make its benefits much less tangible. Yes, I did some profiling few moths ago before we migrated to JSF 2.0 state saving and I can confirm that same very complex view written: - as .jspx + trinidad state saving + trinidad components + application view cache - and as .xhtml + mojarra partial state saving + base JSF components doesn't have performance problem (even no regression with .xhtml) in both cases regarding state saving. +1 for removing application view cache in trinidad 2.0 Regards, Martin Kočí If there is demand for this feature in the future, we can revisit it and try to address the issues we have seen. Max Gabrielle Crawford wrote: Hi, I'm working on state saving issues in Trinidad 2 (for JSF 2). I'm just wondering if we really want to support application view cache going forward. The application view cache has some limitations that make me wonder how commonly it's used, see the doc under The Application View Cache http://myfaces.apache.org/trinidad/trinidad-1_2/devguide/configuration.html Maybe more importantly, I'm not sure, but I think the reason it exists is to avoid rerunning the tags? Is rerunning tags as much of an issue with facelets? If not, maybe we should just say to move to facelets in 2.0. Thanks, Gabrielle
Re: [scripting extension] compile errors ?
Hi we could resolve that yesterday offline, I am in the middle of an
overhaul of the codebase, so I am reluctant to commit some quick fixes
now, the pom.xml needs to be upgraded to the latest stable
of myfaces (since the snapshots seem to be obviously older in shared
than what the project expects, not sure if the stable has the shared
trunk integrated, the classes were committed around last july or so, so
I assume they are in)
not sure if Matthias already has committed the fixes to the poms,
otherwise my next rather big commit will fix it (which wont be this week
anymore since I am working on the last huge open issue here regarding
the bean reloading and classloader classcast exceptions)
The scripting project however is fine, it is just that the shared code
which is needed for the projects initialisation is not picked up from
the deployed snapshots. Anyway it will be fixed with my next commit
(hopefully next week) if it is not fixed already.
Werner
Matthias Wessendorf schrieb:
On Tue, Dec 1, 2009 at 8:22 PM, Matthias Wessendorf mat...@apache.org wrote:
eh...
myfaces_129_SNAPSHOT needs shared_308_SNAPSHOT
see here:
http://markmail.org/message/qpkfmfjv2t5aa62a
and scripting needs 129:SNAPSHOT
and here:
http://svn.apache.org/viewvc?view=revisionrevision=885883
:-)
On Tue, Dec 1, 2009 at 7:57 PM, Matthias Wessendorf mat...@apache.org wrote:
Hello,
is it just me ? Or does the scripting module not compile for you as well ?
[INFO] Compilation failure
/home/matzew/work/source/javanight/extensions/core/core/src/main/java/org/apache/myfaces/scripting/servlet/CustomChainLoader.java:[26,42]
cannot find symbol
symbol : class ClassLoaderExtension
location: package org.apache.myfaces.shared_impl.util
/home/matzew/work/source/javanight/extensions/core/core/src/main/java/org/apache/myfaces/scripting/servlet/CustomChainLoader.java:[39,39]
cannot find symbol
symbol: class ClassLoaderExtension
public class CustomChainLoader extends ClassLoaderExtension {
/home/matzew/work/source/javanight/extensions/core/core/src/main/java/org/apache/myfaces/scripting/core/util/ClassUtils.java:[24,42]
cannot find symbol
symbol : class ClassLoaderExtension
location: package org.apache.myfaces.shared_impl.util
/home/matzew/work/source/javanight/extensions/core/core/src/main/java/org/apache/myfaces/scripting/core/util/ClassUtils.java:[166,48]
cannot find symbol
symbol : class ClassLoaderExtension
location: class org.apache.myfaces.scripting.core.util.ClassUtils
/home/matzew/work/source/javanight/extensions/core/core/src/main/java/org/apache/myfaces/scripting/servlet/StartupServletContextPluginChainLoader.java:[25,32]
cannot find symbol
symbol : class StartupListener
location: package org.apache.myfaces.webapp
/home/matzew/work/source/javanight/extensions/core/core/src/main/java/org/apache/myfaces/scripting/servlet/StartupServletContextPluginChainLoader.java:[35,63]
cannot find symbol
symbol: class StartupListener
public class StartupServletContextPluginChainLoader implements StartupListener {
--
Matthias Wessendorf
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf
--
Matthias Wessendorf
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf
Re: [Trinidad 2.0] introducing ProjectStage API
Hi, does trinidad reload both JSP and facelets views if org.apache.myfaces.trinidad.CHECK_FILE_MODIFICATION=true? For facelets based views there is a new JSF 2.0 param javax.faces.FACELETS_REFRESH_PERIOD (-1 = never reload, 0=always, 1,2, 3,.. - check interval) but it's relation to project stage is not clear - see https://javaserverfaces.dev.java.net/issues/show_bug.cgi?id=1434 Martin Kočí Matthias Wessendorf píše v St 02. 12. 2009 v 09:25 +0100: Hi, here is a (complete?) list of all Trinidad configuration parameters: * System Properties ( = System.getProperty()): org.apache.myfaces.trinidad.CHECK_STATE_SERIALIZATION documentation is here: http://issues.apache.org/jira/browse/TRINIDAD-1245 http://myfaces.apache.org/trinidad/trinidad-api/apidocs/org/apache/myfaces/trinidad/bean/util/StateUtils.html == does not really make sense to port to Stage. * The trinidad-config.xml file: See here for infos about it: http://myfaces.apache.org/trinidad/devguide/configuration.html I think that ONLY this element could make sense: -debug-output (e.g. as for PRODUCTION you want FALSE here... ) * Settings in the WEB.XML (aka Context Parameters): Some info is here as well: http://myfaces.apache.org/trinidad/devguide/configuration.html The web.xml has different types of settings: some fit to ProjectStage, some not.. Here is a grouped list, where I think they don't make sense with project_stage at all: -org.apache.myfaces.trinidad.CACHE_VIEW_ROOT -org.apache.myfaces.trinidad.CLIENT_STATE_METHOD -org.apache.myfaces.trinidad.CLIENT_STATE_MAX_TOKENS -org.apache.myfaces.trinidad.CHANGE_PERSISTENCE -org.apache.myfaces.trinidad.USE_APPLICATION_VIEW_CACHE -org.apache.myfaces.trinidad.ENABLE_LIGHTWEIGHT_DIALOGS -org.apache.myfaces.trinidad.ALTERNATE_VIEW_HANDLER -org.apache.myfaces.trinidad.FACELETS_VIEW_MAPPINGS -org.apache.myfaces.trinidad.UPLOAD_MAX_MEMORY -org.apache.myfaces.trinidad.UPLOAD_MAX_DISK_SPACE -org.apache.myfaces.trinidad.UPLOAD_TEMP_DIR These parameters do make sense: -org.apache.myfaces.trinidad.DEBUG_JAVASCRIPT -org.apache.myfaces.trinidad.DISABLE_CONTENT_COMPRESSION -org.apache.myfaces.trinidad.CHECK_FILE_MODIFICATION -org.apache.myfaces.trinidad.resource.DEBUG (note, we need a bug here, as this is NOT documented in the official documentation :-) ) This parameter _may_ make sense (*caution:* it is an internal and temporary param): -org.apache.myfaces.trinidadinternal.ENABLE_PPR_OPTIMIZATION See http://issues.apache.org/jira/browse/TRINIDAD-1368 So basically, only these make sense (for me): -org.apache.myfaces.trinidad.DEBUG_JAVASCRIPT -org.apache.myfaces.trinidad.DISABLE_CONTENT_COMPRESSION -org.apache.myfaces.trinidad.CHECK_FILE_MODIFICATION -org.apache.myfaces.trinidad.resource.DEBUG -org.apache.myfaces.trinidadinternal.ENABLE_PPR_OPTIMIZATION (*see above) -debug-output Let me know if you agree with this list and I will follow up on what values they should have, in what STAGE A note: Perhaps we want to be able to still override a _SINGLE_ setting, regardless for the current STAGE. Means: If the application runs in ProjectStage.Production, we do CSS compression. BUT... if the web.xml says org.apache.myfaces.trinidad.DISABLE_CONTENT_COMPRESSION = TRUE, we should honor that... This would give users a more fine grained control over these configuration settings. What do you think ? Greetings, Matthias
[jira] Commented: (TRINIDAD-1327) Wrong rendering of inputFile inside panelFormLayout
[ https://issues.apache.org/jira/browse/TRINIDAD-1327?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12784805#action_12784805 ] Markus Döring commented on TRINIDAD-1327: - Found an slightly better workaround: Overwrite renderRootDomElementStyles in InputFileRenderer and just do nothing. Same drawback that no RootDomElementStyles are used for fileInput, but no changes on the LabelAndMessageRenderer are needed. Wrong rendering of inputFile inside panelFormLayout --- Key: TRINIDAD-1327 URL: https://issues.apache.org/jira/browse/TRINIDAD-1327 Project: MyFaces Trinidad Issue Type: Bug Components: Components Affects Versions: 1.0.10-core Reporter: Tomas Havelka The code below generates corrupted html output for inputFile component. This happens just when inputFile is enclosed with panelFormLayout component (locale javascript are rendered in the wrong place?). f:view tr:document tr:form usesUpload=true tr:panelFormLayout tr:inputFile label=Input file/ /tr:panelFormLayout /tr:form /tr:document /f:view -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [Trinidad 2.0] introducing ProjectStage API
Hi, I think the best way would be that the init parameters have stage related standard values (actually that what Matthias suggested), for example: If we are in ProjectStage.Production the standard value of org.apache.myfaces.trinidad.DISABLE_CONTENT_COMPRESSION is false, otherwise it is true. But this only sets the DEFAULT value. The user still can configure each parameter independently by putting it in web.xml. Regards Jakob Korherr 2009/12/2 Martin Koci martin.k...@aura.cz Hi, does trinidad reload both JSP and facelets views if org.apache.myfaces.trinidad.CHECK_FILE_MODIFICATION=true? For facelets based views there is a new JSF 2.0 param javax.faces.FACELETS_REFRESH_PERIOD (-1 = never reload, 0=always, 1,2, 3,.. - check interval) but it's relation to project stage is not clear - see https://javaserverfaces.dev.java.net/issues/show_bug.cgi?id=1434 Martin Kočí Matthias Wessendorf píše v St 02. 12. 2009 v 09:25 +0100: Hi, here is a (complete?) list of all Trinidad configuration parameters: * System Properties ( = System.getProperty()): org.apache.myfaces.trinidad.CHECK_STATE_SERIALIZATION documentation is here: http://issues.apache.org/jira/browse/TRINIDAD-1245 http://myfaces.apache.org/trinidad/trinidad-api/apidocs/org/apache/myfaces/trinidad/bean/util/StateUtils.html == does not really make sense to port to Stage. * The trinidad-config.xml file: See here for infos about it: http://myfaces.apache.org/trinidad/devguide/configuration.html I think that ONLY this element could make sense: -debug-output (e.g. as for PRODUCTION you want FALSE here... ) * Settings in the WEB.XML (aka Context Parameters): Some info is here as well: http://myfaces.apache.org/trinidad/devguide/configuration.html The web.xml has different types of settings: some fit to ProjectStage, some not.. Here is a grouped list, where I think they don't make sense with project_stage at all: -org.apache.myfaces.trinidad.CACHE_VIEW_ROOT -org.apache.myfaces.trinidad.CLIENT_STATE_METHOD -org.apache.myfaces.trinidad.CLIENT_STATE_MAX_TOKENS -org.apache.myfaces.trinidad.CHANGE_PERSISTENCE -org.apache.myfaces.trinidad.USE_APPLICATION_VIEW_CACHE -org.apache.myfaces.trinidad.ENABLE_LIGHTWEIGHT_DIALOGS -org.apache.myfaces.trinidad.ALTERNATE_VIEW_HANDLER -org.apache.myfaces.trinidad.FACELETS_VIEW_MAPPINGS -org.apache.myfaces.trinidad.UPLOAD_MAX_MEMORY -org.apache.myfaces.trinidad.UPLOAD_MAX_DISK_SPACE -org.apache.myfaces.trinidad.UPLOAD_TEMP_DIR These parameters do make sense: -org.apache.myfaces.trinidad.DEBUG_JAVASCRIPT -org.apache.myfaces.trinidad.DISABLE_CONTENT_COMPRESSION -org.apache.myfaces.trinidad.CHECK_FILE_MODIFICATION -org.apache.myfaces.trinidad.resource.DEBUG (note, we need a bug here, as this is NOT documented in the official documentation :-) ) This parameter _may_ make sense (*caution:* it is an internal and temporary param): -org.apache.myfaces.trinidadinternal.ENABLE_PPR_OPTIMIZATION See http://issues.apache.org/jira/browse/TRINIDAD-1368 So basically, only these make sense (for me): -org.apache.myfaces.trinidad.DEBUG_JAVASCRIPT -org.apache.myfaces.trinidad.DISABLE_CONTENT_COMPRESSION -org.apache.myfaces.trinidad.CHECK_FILE_MODIFICATION -org.apache.myfaces.trinidad.resource.DEBUG -org.apache.myfaces.trinidadinternal.ENABLE_PPR_OPTIMIZATION (*see above) -debug-output Let me know if you agree with this list and I will follow up on what values they should have, in what STAGE A note: Perhaps we want to be able to still override a _SINGLE_ setting, regardless for the current STAGE. Means: If the application runs in ProjectStage.Production, we do CSS compression. BUT... if the web.xml says org.apache.myfaces.trinidad.DISABLE_CONTENT_COMPRESSION = TRUE, we should honor that... This would give users a more fine grained control over these configuration settings. What do you think ? Greetings, Matthias
Re: [Trinidad 2.0] introducing ProjectStage API
yep, that's what I was saying On Wed, Dec 2, 2009 at 3:04 PM, Jakob Korherr jakob.korh...@gmail.com wrote: Hi, I think the best way would be that the init parameters have stage related standard values (actually that what Matthias suggested), for example: If we are in ProjectStage.Production the standard value of org.apache.myfaces.trinidad.DISABLE_CONTENT_COMPRESSION is false, otherwise it is true. But this only sets the DEFAULT value. The user still can configure each parameter independently by putting it in web.xml. Regards Jakob Korherr 2009/12/2 Martin Koci martin.k...@aura.cz Hi, does trinidad reload both JSP and facelets views if org.apache.myfaces.trinidad.CHECK_FILE_MODIFICATION=true? For facelets based views there is a new JSF 2.0 param javax.faces.FACELETS_REFRESH_PERIOD (-1 = never reload, 0=always, 1,2, 3,.. - check interval) but it's relation to project stage is not clear - see https://javaserverfaces.dev.java.net/issues/show_bug.cgi?id=1434 Martin Kočí Matthias Wessendorf píše v St 02. 12. 2009 v 09:25 +0100: Hi, here is a (complete?) list of all Trinidad configuration parameters: * System Properties ( = System.getProperty()): org.apache.myfaces.trinidad.CHECK_STATE_SERIALIZATION documentation is here: http://issues.apache.org/jira/browse/TRINIDAD-1245 http://myfaces.apache.org/trinidad/trinidad-api/apidocs/org/apache/myfaces/trinidad/bean/util/StateUtils.html == does not really make sense to port to Stage. * The trinidad-config.xml file: See here for infos about it: http://myfaces.apache.org/trinidad/devguide/configuration.html I think that ONLY this element could make sense: -debug-output (e.g. as for PRODUCTION you want FALSE here... ) * Settings in the WEB.XML (aka Context Parameters): Some info is here as well: http://myfaces.apache.org/trinidad/devguide/configuration.html The web.xml has different types of settings: some fit to ProjectStage, some not.. Here is a grouped list, where I think they don't make sense with project_stage at all: -org.apache.myfaces.trinidad.CACHE_VIEW_ROOT -org.apache.myfaces.trinidad.CLIENT_STATE_METHOD -org.apache.myfaces.trinidad.CLIENT_STATE_MAX_TOKENS -org.apache.myfaces.trinidad.CHANGE_PERSISTENCE -org.apache.myfaces.trinidad.USE_APPLICATION_VIEW_CACHE -org.apache.myfaces.trinidad.ENABLE_LIGHTWEIGHT_DIALOGS -org.apache.myfaces.trinidad.ALTERNATE_VIEW_HANDLER -org.apache.myfaces.trinidad.FACELETS_VIEW_MAPPINGS -org.apache.myfaces.trinidad.UPLOAD_MAX_MEMORY -org.apache.myfaces.trinidad.UPLOAD_MAX_DISK_SPACE -org.apache.myfaces.trinidad.UPLOAD_TEMP_DIR These parameters do make sense: -org.apache.myfaces.trinidad.DEBUG_JAVASCRIPT -org.apache.myfaces.trinidad.DISABLE_CONTENT_COMPRESSION -org.apache.myfaces.trinidad.CHECK_FILE_MODIFICATION -org.apache.myfaces.trinidad.resource.DEBUG (note, we need a bug here, as this is NOT documented in the official documentation :-) ) This parameter _may_ make sense (*caution:* it is an internal and temporary param): -org.apache.myfaces.trinidadinternal.ENABLE_PPR_OPTIMIZATION See http://issues.apache.org/jira/browse/TRINIDAD-1368 So basically, only these make sense (for me): -org.apache.myfaces.trinidad.DEBUG_JAVASCRIPT -org.apache.myfaces.trinidad.DISABLE_CONTENT_COMPRESSION -org.apache.myfaces.trinidad.CHECK_FILE_MODIFICATION -org.apache.myfaces.trinidad.resource.DEBUG -org.apache.myfaces.trinidadinternal.ENABLE_PPR_OPTIMIZATION (*see above) -debug-output Let me know if you agree with this list and I will follow up on what values they should have, in what STAGE A note: Perhaps we want to be able to still override a _SINGLE_ setting, regardless for the current STAGE. Means: If the application runs in ProjectStage.Production, we do CSS compression. BUT... if the web.xml says org.apache.myfaces.trinidad.DISABLE_CONTENT_COMPRESSION = TRUE, we should honor that... This would give users a more fine grained control over these configuration settings. What do you think ? Greetings, Matthias -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf
[jira] Created: (MYFACES-2442) Problem when using MyFaces with Spring DM within an OSGi environment
Problem when using MyFaces with Spring DM within an OSGi environment
Key: MYFACES-2442
URL: https://issues.apache.org/jira/browse/MYFACES-2442
Project: MyFaces Core
Issue Type: Bug
Components: General
Affects Versions: 1.2.2
Environment: Spring 2.5.6, Spring DM 1.2.0, Tomcat 6.20, MyFaces
1.2.2, Equinox 3.5
Servlet HTTP 2.5, JSP 2.1
Reporter: Thierry Templier
Hello,
We detect a problem when using MyFaces 1.2.2 within an OSGi container. The
problem occurs when MyFaces tryies to initialize the default JspFactory from
the Jsp21FacesInitializer class. It seems that the code which poses problem is
the following:
if (jspFactory == null) {
// TODO: this Class.forName will be removed when Tomcat fixes a bug
// also, we should then be able to remove jasper.jar from the
deployment
try {
Class.forName(org.apache.jasper.compiler.JspRuntimeContext);
} catch (ClassNotFoundException e) {
; // ignore
} catch (Exception ex) {
log.debug(An unexpected exception occured
+ while loading the JspRuntimeContext., ex);
}
jspFactory = JspFactory.getDefaultFactory();
}
As a matter of fact, the getDefaultFactory method returns null in this
context...
If we force MyFaces to use the Jsp20FacesInitializer class from the
ContainerUtils class as following:
public class ContainerUtils
{
/**
* Determines whether we're running in a Servlet 2.5/JSP 2.1 environment.
*
* @return codetrue/code if we're running in a JSP 2.1 environment,
* codefalse/code otherwise
*/
public static boolean isJsp21()
{
/*try
{
// simply check if the class JspApplicationContext is available
Class.forName(javax.servlet.jsp.JspApplicationContext);
return true;
}
catch (ClassNotFoundException ex)
{
; // expected exception in a JSP 2.0 (or less) environment
}*/
return false;
}
(...)
}
the problem doesn't occur and MyFaces can be used.
Regards,
Thierry
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (TRINIDAD-1651) all serializable classes should have serialversionuids
all serializable classes should have serialversionuids -- Key: TRINIDAD-1651 URL: https://issues.apache.org/jira/browse/TRINIDAD-1651 Project: MyFaces Trinidad Issue Type: Improvement Components: Components Affects Versions: 1.2.12-core Reporter: Matthias Weßendorf Assignee: Matthias Weßendorf These classes need to be touched: org.apache.myfaces.trinidad.bean ValueBindingValueExpression.SerializableValueBindingValueExpression org.apache.myfaces.trinidad.bean ValueBindingValueExpression.SerializableStateHolderValueBindingValueExpression org.apache.myfaces.trinidad.bean ValueExpressionValueBinding.SerializableValueExpressionValueBinding org.apache.myfaces.trinidad.bean ValueExpressionValueBinding.SerializableStateHolderValueExpressionValueBinding org.apache.myfaces.trinidad.bean.util StateUtils.Saver org.apache.myfaces.trinidad.bean.util StateUtils.SHSaver org.apache.myfaces.trinidad.change AddChildComponentChange org.apache.myfaces.trinidad.change AddComponentChange org.apache.myfaces.trinidad.change AttributeComponentChange org.apache.myfaces.trinidad.change ChangeComponentProxy org.apache.myfaces.trinidad.change ComponentChange org.apache.myfaces.trinidad.change MoveChildComponentChange org.apache.myfaces.trinidad.change RemoveChildComponentChange org.apache.myfaces.trinidad.change RemoveFacetComponentChange org.apache.myfaces.trinidad.change ReorderChildrenComponentChange org.apache.myfaces.trinidad.change SessionChangeManager.ChangesForView org.apache.myfaces.trinidad.change SessionChangeManager.QualifiedComponentChange org.apache.myfaces.trinidad.change SetFacetChildComponentChange org.apache.myfaces.trinidad.component FacesMessageWrapper org.apache.myfaces.trinidad.component StampState org.apache.myfaces.trinidad.component StampState.RowState org.apache.myfaces.trinidad.component StampState.SDState org.apache.myfaces.trinidad.component StampState.TableState org.apache.myfaces.trinidad.component StampState.EVHState org.apache.myfaces.trinidad.component StampState.DualKey org.apache.myfaces.trinidad.component TableRowEvent org.apache.myfaces.trinidad.component TreeState org.apache.myfaces.trinidad.component UIXCollection.DefaultClientKeyManager org.apache.myfaces.trinidad.component UIXCollection.InternalState org.apache.myfaces.trinidad.component WrapperEvent org.apache.myfaces.trinidad.context AccessibilityProfile.SeriablizableAccessibilityProfile org.apache.myfaces.trinidad.context Window org.apache.myfaces.trinidad.convert ColorFormat org.apache.myfaces.trinidad.convert RGBColorFormat org.apache.myfaces.trinidad.event AttributeChangeEvent org.apache.myfaces.trinidad.event ChartDrillDownEvent org.apache.myfaces.trinidad.event DisclosureEvent org.apache.myfaces.trinidad.event FocusEvent org.apache.myfaces.trinidad.event LaunchEvent org.apache.myfaces.trinidad.event PollEvent org.apache.myfaces.trinidad.event RangeChangeEvent org.apache.myfaces.trinidad.event ReturnEvent org.apache.myfaces.trinidad.event RowDisclosureEvent org.apache.myfaces.trinidad.event RowKeySetChangeEvent org.apache.myfaces.trinidad.event SelectionEvent org.apache.myfaces.trinidad.event SortEvent org.apache.myfaces.trinidad.event WindowEvent org.apache.myfaces.trinidad.event WindowLifecycleEvent org.apache.myfaces.trinidad.event WindowLifecycleNavigateEvent org.apache.myfaces.trinidad.logging TrinidadLogRecord org.apache.myfaces.trinidad.model DefaultBoundedRangeModel org.apache.myfaces.trinidad.model RowKeySetImpl org.apache.myfaces.trinidad.model RowKeySetTreeImpl org.apache.myfaces.trinidad.model SortCriterion org.apache.myfaces.trinidad.render ClientRowKeyManager org.apache.myfaces.trinidad.util CollectionUtils.EmptyQueue org.apache.myfaces.trinidad.util ErrorMessages org.apache.myfaces.trinidad.util LabeledFacesMessage org.apache.myfaces.trinidad.util MessageFactory.BindingFacesMessage org.apache.myfaces.trinidad.util MessageFactory.BindingErrorMessages org.apache.myfaces.trinidad.util MessageFactory.CustomDetailErrorMessage org.apache.myfaces.trinidad.util MessageFactory.FormattedErrorMessages org.apache.myfaces.trinidadinternal.application StateManagerImpl.PageState org.apache.myfaces.trinidadinternal.application Structure org.apache.myfaces.trinidadinternal.binding AccessKeyBinding org.apache.myfaces.trinidadinternal.binding StripAccessKeyBinding org.apache.myfaces.trinidadinternal.config.upload ErrorFile org.apache.myfaces.trinidadinternal.config.upload UploadedFileImpl org.apache.myfaces.trinidadinternal.config.upload UploadedFiles.FixFilename org.apache.myfaces.trinidadinternal.context DialogServiceImpl.InternalLaunch org.apache.myfaces.trinidadinternal.context TrinidadPhaseListener org.apache.myfaces.trinidadinternal.convert TypeConversionException org.apache.myfaces.trinidadinternal.image.cache CacheException org.apache.myfaces.trinidadinternal.menu
[tobago] plans for tobago for jsf 2.0
Hi Just for curiosity, Is there any plans for a tobago and jsf 2.0? regards, Leonardo Uribe
[jira] Resolved: (TRINIDAD-1651) all serializable classes should have serialversionuids
[ https://issues.apache.org/jira/browse/TRINIDAD-1651?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matthias Weßendorf resolved TRINIDAD-1651. -- Resolution: Fixed Fix Version/s: 1.2.13-core all serializable classes should have serialversionuids -- Key: TRINIDAD-1651 URL: https://issues.apache.org/jira/browse/TRINIDAD-1651 Project: MyFaces Trinidad Issue Type: Improvement Components: Components Affects Versions: 1.2.12-core Reporter: Matthias Weßendorf Assignee: Matthias Weßendorf Fix For: 1.2.13-core These classes need to be touched: org.apache.myfaces.trinidad.bean ValueBindingValueExpression.SerializableValueBindingValueExpression org.apache.myfaces.trinidad.bean ValueBindingValueExpression.SerializableStateHolderValueBindingValueExpression org.apache.myfaces.trinidad.bean ValueExpressionValueBinding.SerializableValueExpressionValueBinding org.apache.myfaces.trinidad.bean ValueExpressionValueBinding.SerializableStateHolderValueExpressionValueBinding org.apache.myfaces.trinidad.bean.util StateUtils.Saver org.apache.myfaces.trinidad.bean.util StateUtils.SHSaver org.apache.myfaces.trinidad.change AddChildComponentChange org.apache.myfaces.trinidad.change AddComponentChange org.apache.myfaces.trinidad.change AttributeComponentChange org.apache.myfaces.trinidad.change ChangeComponentProxy org.apache.myfaces.trinidad.change ComponentChange org.apache.myfaces.trinidad.change MoveChildComponentChange org.apache.myfaces.trinidad.change RemoveChildComponentChange org.apache.myfaces.trinidad.change RemoveFacetComponentChange org.apache.myfaces.trinidad.change ReorderChildrenComponentChange org.apache.myfaces.trinidad.change SessionChangeManager.ChangesForView org.apache.myfaces.trinidad.change SessionChangeManager.QualifiedComponentChange org.apache.myfaces.trinidad.change SetFacetChildComponentChange org.apache.myfaces.trinidad.component FacesMessageWrapper org.apache.myfaces.trinidad.component StampState org.apache.myfaces.trinidad.component StampState.RowState org.apache.myfaces.trinidad.component StampState.SDState org.apache.myfaces.trinidad.component StampState.TableState org.apache.myfaces.trinidad.component StampState.EVHState org.apache.myfaces.trinidad.component StampState.DualKey org.apache.myfaces.trinidad.component TableRowEvent org.apache.myfaces.trinidad.component TreeState org.apache.myfaces.trinidad.component UIXCollection.DefaultClientKeyManager org.apache.myfaces.trinidad.component UIXCollection.InternalState org.apache.myfaces.trinidad.component WrapperEvent org.apache.myfaces.trinidad.context AccessibilityProfile.SeriablizableAccessibilityProfile org.apache.myfaces.trinidad.context Window org.apache.myfaces.trinidad.convert ColorFormat org.apache.myfaces.trinidad.convert RGBColorFormat org.apache.myfaces.trinidad.event AttributeChangeEvent org.apache.myfaces.trinidad.event ChartDrillDownEvent org.apache.myfaces.trinidad.event DisclosureEvent org.apache.myfaces.trinidad.event FocusEvent org.apache.myfaces.trinidad.event LaunchEvent org.apache.myfaces.trinidad.event PollEvent org.apache.myfaces.trinidad.event RangeChangeEvent org.apache.myfaces.trinidad.event ReturnEvent org.apache.myfaces.trinidad.event RowDisclosureEvent org.apache.myfaces.trinidad.event RowKeySetChangeEvent org.apache.myfaces.trinidad.event SelectionEvent org.apache.myfaces.trinidad.event SortEvent org.apache.myfaces.trinidad.event WindowEvent org.apache.myfaces.trinidad.event WindowLifecycleEvent org.apache.myfaces.trinidad.event WindowLifecycleNavigateEvent org.apache.myfaces.trinidad.logging TrinidadLogRecord org.apache.myfaces.trinidad.model DefaultBoundedRangeModel org.apache.myfaces.trinidad.model RowKeySetImpl org.apache.myfaces.trinidad.model RowKeySetTreeImpl org.apache.myfaces.trinidad.model SortCriterion org.apache.myfaces.trinidad.render ClientRowKeyManager org.apache.myfaces.trinidad.util CollectionUtils.EmptyQueue org.apache.myfaces.trinidad.util ErrorMessages org.apache.myfaces.trinidad.util LabeledFacesMessage org.apache.myfaces.trinidad.util MessageFactory.BindingFacesMessage org.apache.myfaces.trinidad.util MessageFactory.BindingErrorMessages org.apache.myfaces.trinidad.util MessageFactory.CustomDetailErrorMessage org.apache.myfaces.trinidad.util MessageFactory.FormattedErrorMessages org.apache.myfaces.trinidadinternal.application StateManagerImpl.PageState org.apache.myfaces.trinidadinternal.application Structure org.apache.myfaces.trinidadinternal.binding AccessKeyBinding org.apache.myfaces.trinidadinternal.binding StripAccessKeyBinding org.apache.myfaces.trinidadinternal.config.upload ErrorFile org.apache.myfaces.trinidadinternal.config.upload UploadedFileImpl
[jira] Commented: (TRINIDAD-1651) all serializable classes should have serialversionuids
[ https://issues.apache.org/jira/browse/TRINIDAD-1651?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12784934#action_12784934 ] Matthias Weßendorf commented on TRINIDAD-1651: -- some of them have already been touched (serialversionuid) before... all serializable classes should have serialversionuids -- Key: TRINIDAD-1651 URL: https://issues.apache.org/jira/browse/TRINIDAD-1651 Project: MyFaces Trinidad Issue Type: Improvement Components: Components Affects Versions: 1.2.12-core Reporter: Matthias Weßendorf Assignee: Matthias Weßendorf Fix For: 1.2.13-core These classes need to be touched: org.apache.myfaces.trinidad.bean ValueBindingValueExpression.SerializableValueBindingValueExpression org.apache.myfaces.trinidad.bean ValueBindingValueExpression.SerializableStateHolderValueBindingValueExpression org.apache.myfaces.trinidad.bean ValueExpressionValueBinding.SerializableValueExpressionValueBinding org.apache.myfaces.trinidad.bean ValueExpressionValueBinding.SerializableStateHolderValueExpressionValueBinding org.apache.myfaces.trinidad.bean.util StateUtils.Saver org.apache.myfaces.trinidad.bean.util StateUtils.SHSaver org.apache.myfaces.trinidad.change AddChildComponentChange org.apache.myfaces.trinidad.change AddComponentChange org.apache.myfaces.trinidad.change AttributeComponentChange org.apache.myfaces.trinidad.change ChangeComponentProxy org.apache.myfaces.trinidad.change ComponentChange org.apache.myfaces.trinidad.change MoveChildComponentChange org.apache.myfaces.trinidad.change RemoveChildComponentChange org.apache.myfaces.trinidad.change RemoveFacetComponentChange org.apache.myfaces.trinidad.change ReorderChildrenComponentChange org.apache.myfaces.trinidad.change SessionChangeManager.ChangesForView org.apache.myfaces.trinidad.change SessionChangeManager.QualifiedComponentChange org.apache.myfaces.trinidad.change SetFacetChildComponentChange org.apache.myfaces.trinidad.component FacesMessageWrapper org.apache.myfaces.trinidad.component StampState org.apache.myfaces.trinidad.component StampState.RowState org.apache.myfaces.trinidad.component StampState.SDState org.apache.myfaces.trinidad.component StampState.TableState org.apache.myfaces.trinidad.component StampState.EVHState org.apache.myfaces.trinidad.component StampState.DualKey org.apache.myfaces.trinidad.component TableRowEvent org.apache.myfaces.trinidad.component TreeState org.apache.myfaces.trinidad.component UIXCollection.DefaultClientKeyManager org.apache.myfaces.trinidad.component UIXCollection.InternalState org.apache.myfaces.trinidad.component WrapperEvent org.apache.myfaces.trinidad.context AccessibilityProfile.SeriablizableAccessibilityProfile org.apache.myfaces.trinidad.context Window org.apache.myfaces.trinidad.convert ColorFormat org.apache.myfaces.trinidad.convert RGBColorFormat org.apache.myfaces.trinidad.event AttributeChangeEvent org.apache.myfaces.trinidad.event ChartDrillDownEvent org.apache.myfaces.trinidad.event DisclosureEvent org.apache.myfaces.trinidad.event FocusEvent org.apache.myfaces.trinidad.event LaunchEvent org.apache.myfaces.trinidad.event PollEvent org.apache.myfaces.trinidad.event RangeChangeEvent org.apache.myfaces.trinidad.event ReturnEvent org.apache.myfaces.trinidad.event RowDisclosureEvent org.apache.myfaces.trinidad.event RowKeySetChangeEvent org.apache.myfaces.trinidad.event SelectionEvent org.apache.myfaces.trinidad.event SortEvent org.apache.myfaces.trinidad.event WindowEvent org.apache.myfaces.trinidad.event WindowLifecycleEvent org.apache.myfaces.trinidad.event WindowLifecycleNavigateEvent org.apache.myfaces.trinidad.logging TrinidadLogRecord org.apache.myfaces.trinidad.model DefaultBoundedRangeModel org.apache.myfaces.trinidad.model RowKeySetImpl org.apache.myfaces.trinidad.model RowKeySetTreeImpl org.apache.myfaces.trinidad.model SortCriterion org.apache.myfaces.trinidad.render ClientRowKeyManager org.apache.myfaces.trinidad.util CollectionUtils.EmptyQueue org.apache.myfaces.trinidad.util ErrorMessages org.apache.myfaces.trinidad.util LabeledFacesMessage org.apache.myfaces.trinidad.util MessageFactory.BindingFacesMessage org.apache.myfaces.trinidad.util MessageFactory.BindingErrorMessages org.apache.myfaces.trinidad.util MessageFactory.CustomDetailErrorMessage org.apache.myfaces.trinidad.util MessageFactory.FormattedErrorMessages org.apache.myfaces.trinidadinternal.application StateManagerImpl.PageState org.apache.myfaces.trinidadinternal.application Structure org.apache.myfaces.trinidadinternal.binding AccessKeyBinding org.apache.myfaces.trinidadinternal.binding StripAccessKeyBinding org.apache.myfaces.trinidadinternal.config.upload ErrorFile
[jira] Created: (TRINIDAD-1652) Use JSF ProjectState API for some configuration parameters
Use JSF ProjectState API for some configuration parameters -- Key: TRINIDAD-1652 URL: https://issues.apache.org/jira/browse/TRINIDAD-1652 Project: MyFaces Trinidad Issue Type: New Feature Components: Components Affects Versions: 2.0.0-core Reporter: Matthias Weßendorf Assignee: Matthias Weßendorf This wiki discusses the suggested enhancement in detail http://wiki.apache.org/myfaces/Trinidad_goes_ProjectStage -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [Trinidad 2.0] introducing ProjectStage API
Ok, I added some value suggestions to those guys that we identified to fit into the ProjectStage API: -org.apache.myfaces.trinidad.DEBUG_JAVASCRIPT * Production = FALSE * other stages = TRUE -org.apache.myfaces.trinidad.DISABLE_CONTENT_COMPRESSION * Production = FALSE * other stages = TRUE -org.apache.myfaces.trinidad.CHECK_FILE_MODIFICATION * Production = FALSE * other stages = TRUE -org.apache.myfaces.trinidad.resource.DEBUG * Production = FALSE * other stages = TRUE -org.apache.myfaces.trinidadinternal.ENABLE_PPR_OPTIMIZATION (see above) * Production = FALSE (current default) * other stages = TRUE -debug-output (from trinidad-config.xml file) * Production = FALSE * other stages = TRUE Please let me know what you think... I updated the wiki page, to reflect the suggestions: http://wiki.apache.org/myfaces/Trinidad_goes_ProjectStage I also created this JIRA ticket, to keep track of the item: https://issues.apache.org/jira/browse/TRINIDAD-1652 -Matthias On Wed, Dec 2, 2009 at 3:18 PM, Matthias Wessendorf mat...@apache.org wrote: yep, that's what I was saying On Wed, Dec 2, 2009 at 3:04 PM, Jakob Korherr jakob.korh...@gmail.com wrote: Hi, I think the best way would be that the init parameters have stage related standard values (actually that what Matthias suggested), for example: If we are in ProjectStage.Production the standard value of org.apache.myfaces.trinidad.DISABLE_CONTENT_COMPRESSION is false, otherwise it is true. But this only sets the DEFAULT value. The user still can configure each parameter independently by putting it in web.xml. Regards Jakob Korherr 2009/12/2 Martin Koci martin.k...@aura.cz Hi, does trinidad reload both JSP and facelets views if org.apache.myfaces.trinidad.CHECK_FILE_MODIFICATION=true? For facelets based views there is a new JSF 2.0 param javax.faces.FACELETS_REFRESH_PERIOD (-1 = never reload, 0=always, 1,2, 3,.. - check interval) but it's relation to project stage is not clear - see https://javaserverfaces.dev.java.net/issues/show_bug.cgi?id=1434 Martin Kočí Matthias Wessendorf píše v St 02. 12. 2009 v 09:25 +0100: Hi, here is a (complete?) list of all Trinidad configuration parameters: * System Properties ( = System.getProperty()): org.apache.myfaces.trinidad.CHECK_STATE_SERIALIZATION documentation is here: http://issues.apache.org/jira/browse/TRINIDAD-1245 http://myfaces.apache.org/trinidad/trinidad-api/apidocs/org/apache/myfaces/trinidad/bean/util/StateUtils.html == does not really make sense to port to Stage. * The trinidad-config.xml file: See here for infos about it: http://myfaces.apache.org/trinidad/devguide/configuration.html I think that ONLY this element could make sense: -debug-output (e.g. as for PRODUCTION you want FALSE here... ) * Settings in the WEB.XML (aka Context Parameters): Some info is here as well: http://myfaces.apache.org/trinidad/devguide/configuration.html The web.xml has different types of settings: some fit to ProjectStage, some not.. Here is a grouped list, where I think they don't make sense with project_stage at all: -org.apache.myfaces.trinidad.CACHE_VIEW_ROOT -org.apache.myfaces.trinidad.CLIENT_STATE_METHOD -org.apache.myfaces.trinidad.CLIENT_STATE_MAX_TOKENS -org.apache.myfaces.trinidad.CHANGE_PERSISTENCE -org.apache.myfaces.trinidad.USE_APPLICATION_VIEW_CACHE -org.apache.myfaces.trinidad.ENABLE_LIGHTWEIGHT_DIALOGS -org.apache.myfaces.trinidad.ALTERNATE_VIEW_HANDLER -org.apache.myfaces.trinidad.FACELETS_VIEW_MAPPINGS -org.apache.myfaces.trinidad.UPLOAD_MAX_MEMORY -org.apache.myfaces.trinidad.UPLOAD_MAX_DISK_SPACE -org.apache.myfaces.trinidad.UPLOAD_TEMP_DIR These parameters do make sense: -org.apache.myfaces.trinidad.DEBUG_JAVASCRIPT -org.apache.myfaces.trinidad.DISABLE_CONTENT_COMPRESSION -org.apache.myfaces.trinidad.CHECK_FILE_MODIFICATION -org.apache.myfaces.trinidad.resource.DEBUG (note, we need a bug here, as this is NOT documented in the official documentation :-) ) This parameter _may_ make sense (*caution:* it is an internal and temporary param): -org.apache.myfaces.trinidadinternal.ENABLE_PPR_OPTIMIZATION See http://issues.apache.org/jira/browse/TRINIDAD-1368 So basically, only these make sense (for me): -org.apache.myfaces.trinidad.DEBUG_JAVASCRIPT -org.apache.myfaces.trinidad.DISABLE_CONTENT_COMPRESSION -org.apache.myfaces.trinidad.CHECK_FILE_MODIFICATION -org.apache.myfaces.trinidad.resource.DEBUG -org.apache.myfaces.trinidadinternal.ENABLE_PPR_OPTIMIZATION (*see above) -debug-output Let me know if you agree with this list and I will follow up on what values they should have, in what STAGE A note: Perhaps we want to be able to still override a _SINGLE_ setting, regardless for the current STAGE. Means: If the application runs in ProjectStage.Production, we do CSS compression. BUT... if the web.xml says
[jira] Commented: (TRINIDAD-1601) adding INTERPRET_EMPTY_STRING_SUBMITTED_VALUES_AS_NULL support to UIXEditableValue
[ https://issues.apache.org/jira/browse/TRINIDAD-1601?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12784959#action_12784959 ] Matthias Weßendorf commented on TRINIDAD-1601: -- also, the JavaDoc (and SPEC) needs to be updated, to actually reflect the change: https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=671 Looks like this needs to wait for JSF 2.1. adding INTERPRET_EMPTY_STRING_SUBMITTED_VALUES_AS_NULL support to UIXEditableValue -- Key: TRINIDAD-1601 URL: https://issues.apache.org/jira/browse/TRINIDAD-1601 Project: MyFaces Trinidad Issue Type: New Feature Components: Components Affects Versions: 2.0.0-core Reporter: Matthias Weßendorf Assignee: Matthias Weßendorf Attachments: TRINIDAD-1601.patch With going forward on the JSF/Trinidad 2.0 integration, we need to support the INTERPRET_EMPTY_STRING_SUBMITTED_VALUES_AS_NULL ctx param inside of the UIXEditableValue class. the change needs to go into the template file/class. The behavior is specified in the spec, chapter 11 (page 11-5) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [Trinidad 2.0] introducing ProjectStage API
Hi, my question was not clear probably, so I try to reformulate it: - Trindad has param CHECK_FILE_MODIFICATION - JSF 2.0 has param FACELETS_REFRESH_PERIOD - javax.faces.ProjectStage is a general parameter at higher level of abstraction than previous two - FACELETS_REFRESH_PERIOD vs. ProjectStage is not specified, it is a implementation detail What happens if user set combination of all? 1) javax.faces.FACELETS_REFRESH_PERIOD 2) org.apache.myfaces.trinidad.CHECK_FILE_MODIFICATION 3) javax.faces.ProjectStage What I'm trying to say is that there are already *three* params with influence to view reloading and that is too much for user. Because facelets2 have own standardized FACELETS_REFRESH_PERIOD I suggest: - org.apache.myfaces.trinidad.CHECK_FILE_MODIFICATION only valid for JSPs (but consider project stage CHECK_FILE_MODIFICATION is not set explicitly) - for Facelets2 leave it to JSF impl (it will simply consider both javax.faces params as suggested in https://javaserverfaces.dev.java.net/issues/show_bug.cgi?id=1434) Or am I missing a basic point? Thanks, Martin Kočí Matthias Wessendorf píše v St 02. 12. 2009 v 15:18 +0100: yep, that's what I was saying On Wed, Dec 2, 2009 at 3:04 PM, Jakob Korherr jakob.korh...@gmail.com wrote: Hi, I think the best way would be that the init parameters have stage related standard values (actually that what Matthias suggested), for example: If we are in ProjectStage.Production the standard value of org.apache.myfaces.trinidad.DISABLE_CONTENT_COMPRESSION is false, otherwise it is true. But this only sets the DEFAULT value. The user still can configure each parameter independently by putting it in web.xml. Regards Jakob Korherr 2009/12/2 Martin Koci martin.k...@aura.cz Hi, does trinidad reload both JSP and facelets views if org.apache.myfaces.trinidad.CHECK_FILE_MODIFICATION=true? For facelets based views there is a new JSF 2.0 param javax.faces.FACELETS_REFRESH_PERIOD (-1 = never reload, 0=always, 1,2, 3,.. - check interval) but it's relation to project stage is not clear - see https://javaserverfaces.dev.java.net/issues/show_bug.cgi?id=1434 Martin Kočí Matthias Wessendorf píše v St 02. 12. 2009 v 09:25 +0100: Hi, here is a (complete?) list of all Trinidad configuration parameters: * System Properties ( = System.getProperty()): org.apache.myfaces.trinidad.CHECK_STATE_SERIALIZATION documentation is here: http://issues.apache.org/jira/browse/TRINIDAD-1245 http://myfaces.apache.org/trinidad/trinidad-api/apidocs/org/apache/myfaces/trinidad/bean/util/StateUtils.html == does not really make sense to port to Stage. * The trinidad-config.xml file: See here for infos about it: http://myfaces.apache.org/trinidad/devguide/configuration.html I think that ONLY this element could make sense: -debug-output (e.g. as for PRODUCTION you want FALSE here... ) * Settings in the WEB.XML (aka Context Parameters): Some info is here as well: http://myfaces.apache.org/trinidad/devguide/configuration.html The web.xml has different types of settings: some fit to ProjectStage, some not.. Here is a grouped list, where I think they don't make sense with project_stage at all: -org.apache.myfaces.trinidad.CACHE_VIEW_ROOT -org.apache.myfaces.trinidad.CLIENT_STATE_METHOD -org.apache.myfaces.trinidad.CLIENT_STATE_MAX_TOKENS -org.apache.myfaces.trinidad.CHANGE_PERSISTENCE -org.apache.myfaces.trinidad.USE_APPLICATION_VIEW_CACHE -org.apache.myfaces.trinidad.ENABLE_LIGHTWEIGHT_DIALOGS -org.apache.myfaces.trinidad.ALTERNATE_VIEW_HANDLER -org.apache.myfaces.trinidad.FACELETS_VIEW_MAPPINGS -org.apache.myfaces.trinidad.UPLOAD_MAX_MEMORY -org.apache.myfaces.trinidad.UPLOAD_MAX_DISK_SPACE -org.apache.myfaces.trinidad.UPLOAD_TEMP_DIR These parameters do make sense: -org.apache.myfaces.trinidad.DEBUG_JAVASCRIPT -org.apache.myfaces.trinidad.DISABLE_CONTENT_COMPRESSION -org.apache.myfaces.trinidad.CHECK_FILE_MODIFICATION -org.apache.myfaces.trinidad.resource.DEBUG (note, we need a bug here, as this is NOT documented in the official documentation :-) ) This parameter _may_ make sense (*caution:* it is an internal and temporary param): -org.apache.myfaces.trinidadinternal.ENABLE_PPR_OPTIMIZATION See http://issues.apache.org/jira/browse/TRINIDAD-1368 So basically, only these make sense (for me): -org.apache.myfaces.trinidad.DEBUG_JAVASCRIPT -org.apache.myfaces.trinidad.DISABLE_CONTENT_COMPRESSION -org.apache.myfaces.trinidad.CHECK_FILE_MODIFICATION -org.apache.myfaces.trinidad.resource.DEBUG -org.apache.myfaces.trinidadinternal.ENABLE_PPR_OPTIMIZATION (*see above) -debug-output Let me know if you agree with this list and I will follow up on what values they should have, in what STAGE A note: Perhaps we want to be able to
Re: [Trinidad 2.0] introducing ProjectStage API
Matthias Wessendorf wrote: On 12/2/2009 10:43 AM PT: Ok, I added some value suggestions to those guys that we identified to fit into the ProjectStage API: -org.apache.myfaces.trinidad.DEBUG_JAVASCRIPT * Production = FALSE * other stages = TRUE +1. although I think if a user were to change the recommended defaults, like set ProjectStage=Production and override the DEBUG_JS to be true, then we at least need to warn the user of this as appropriate. -org.apache.myfaces.trinidad.DISABLE_CONTENT_COMPRESSION * Production = FALSE * other stages = TRUE -org.apache.myfaces.trinidad.CHECK_FILE_MODIFICATION * Production = FALSE * other stages = TRUE -org.apache.myfaces.trinidad.resource.DEBUG * Production = FALSE * other stages = TRUE -org.apache.myfaces.trinidadinternal.ENABLE_PPR_OPTIMIZATION (see above) * Production = FALSE (current default) * other stages = TRUE -debug-output (from trinidad-config.xml file) * Production = FALSE * other stages = TRUE +1. I also was wondering if org.apache.myfaces.trinidad.CHECK_STATE_SERIALIZATION should be set to NONE in Production if this is really used for a testing Trinidad in pseudo-High Availability (HA) mode. It looks like we could set this different values based on the the ProjectStage Production org.apache.myfaces.trinidad.CHECK_STATE_SERIALIZATION=none Development, Unit Test org.apache.myfaces.trinidad.CHECK_STATE_SERIALIZATION=session,tree System Test org.apache.myfaces.trinidad.CHECK_STATE_SERIALIZATION=all -Pavitra Please let me know what you think... I updated the wiki page, to reflect the suggestions: http://wiki.apache.org/myfaces/Trinidad_goes_ProjectStage I also created this JIRA ticket, to keep track of the item: https://issues.apache.org/jira/browse/TRINIDAD-1652 -Matthias On Wed, Dec 2, 2009 at 3:18 PM, Matthias Wessendorf mat...@apache.org wrote: yep, that's what I was saying On Wed, Dec 2, 2009 at 3:04 PM, Jakob Korherr jakob.korh...@gmail.com wrote: Hi, I think the best way would be that the init parameters have stage related standard values (actually that what Matthias suggested), for example: If we are in ProjectStage.Production the standard value of org.apache.myfaces.trinidad.DISABLE_CONTENT_COMPRESSION is false, otherwise it is true. But this only sets the DEFAULT value. The user still can configure each parameter independently by putting it in web.xml. Regards Jakob Korherr 2009/12/2 Martin Koci martin.k...@aura.cz Hi, does trinidad reload both JSP and facelets views if org.apache.myfaces.trinidad.CHECK_FILE_MODIFICATION=true? For facelets based views there is a new JSF 2.0 param javax.faces.FACELETS_REFRESH_PERIOD (-1 = never reload, 0=always, 1,2, 3,.. - check interval) but it's relation to project stage is not clear - see https://javaserverfaces.dev.java.net/issues/show_bug.cgi?id=1434 Martin Kočí Matthias Wessendorf píše v St 02. 12. 2009 v 09:25 +0100: Hi, here is a (complete?) list of all Trinidad configuration parameters: * System Properties ( = System.getProperty()): org.apache.myfaces.trinidad.CHECK_STATE_SERIALIZATION documentation is here: http://issues.apache.org/jira/browse/TRINIDAD-1245 http://myfaces.apache.org/trinidad/trinidad-api/apidocs/org/apache/myfaces/trinidad/bean/util/StateUtils.html == does not really make sense to port to Stage. * The trinidad-config.xml file: See here for infos about it: http://myfaces.apache.org/trinidad/devguide/configuration.html I think that ONLY this element could make sense: -debug-output (e.g. as for PRODUCTION you want FALSE here... ) * Settings in the WEB.XML (aka Context Parameters): Some info is here as well: http://myfaces.apache.org/trinidad/devguide/configuration.html The web.xml has different types of settings: some fit to ProjectStage, some not.. Here is a grouped list, where I think they don't make sense with project_stage at all: -org.apache.myfaces.trinidad.CACHE_VIEW_ROOT -org.apache.myfaces.trinidad.CLIENT_STATE_METHOD -org.apache.myfaces.trinidad.CLIENT_STATE_MAX_TOKENS -org.apache.myfaces.trinidad.CHANGE_PERSISTENCE -org.apache.myfaces.trinidad.USE_APPLICATION_VIEW_CACHE -org.apache.myfaces.trinidad.ENABLE_LIGHTWEIGHT_DIALOGS -org.apache.myfaces.trinidad.ALTERNATE_VIEW_HANDLER -org.apache.myfaces.trinidad.FACELETS_VIEW_MAPPINGS -org.apache.myfaces.trinidad.UPLOAD_MAX_MEMORY -org.apache.myfaces.trinidad.UPLOAD_MAX_DISK_SPACE -org.apache.myfaces.trinidad.UPLOAD_TEMP_DIR These parameters do make sense: -org.apache.myfaces.trinidad.DEBUG_JAVASCRIPT -org.apache.myfaces.trinidad.DISABLE_CONTENT_COMPRESSION -org.apache.myfaces.trinidad.CHECK_FILE_MODIFICATION -org.apache.myfaces.trinidad.resource.DEBUG (note, we need a bug here, as this is NOT documented in the official documentation :-) ) This parameter _may_ make sense (*caution:* it is an internal and temporary param): -org.apache.myfaces.trinidadinternal.ENABLE_PPR_OPTIMIZATION See http://issues.apache.org/jira/browse/TRINIDAD-1368 So
[Trinidad 2.0] Updating Trinidad ResponseWriterDecorator and related classes...
Hi, I have provided a patch which fixes issue 1649 https://issues.apache.org/jira/browse/TRINIDAD-1649. The fix is to update the Trinidad ResponseWriter classes to override the new APIs added to javax.faces.context.ResponseWriter in JSF2.0. I am working on a project that uses the JSF 2.0 Ajax channel over Trinidad's and without these changes, the partial response never gets built properly. The changes made are: ResponseWriterDecorator.java (now extends ResponseWriterWrapper. Ideally we should remove ResponseWriterDecorator entirely and just use JSF2.0 ResponseWriterWrapper) HtmlResponseWriter.java (overrides 2 new methods added to javax.faces.context.ResponseWriter but never really gives a compilation error). XmlResponseWriter.java (same as above) XhtmlResponseWriter.java (-do-) If there are no questions regarding this change, I would like to submit my patch for approval. Thanks Pavitra
Re: [Trinidad 2.0] introducing ProjectStage API
On Wed, Dec 2, 2009 at 8:32 PM, Martin Koci martin.k...@aura.cz wrote: Hi, my question was not clear probably, so I try to reformulate it: - Trindad has param CHECK_FILE_MODIFICATION - JSF 2.0 has param FACELETS_REFRESH_PERIOD - javax.faces.ProjectStage is a general parameter at higher level of abstraction than previous two - FACELETS_REFRESH_PERIOD vs. ProjectStage is not specified, it is a implementation detail I am not surprised, that this is not specified. The entire specification doesn't even bother to talk about FACELETS_REFRESH_PERIOD at all. What happens if user set combination of all? 1) javax.faces.FACELETS_REFRESH_PERIOD 2) org.apache.myfaces.trinidad.CHECK_FILE_MODIFICATION 3) javax.faces.ProjectStage What I'm trying to say is that there are already *three* params with influence to view reloading and that is too much for user. Because facelets2 have own standardized FACELETS_REFRESH_PERIOD I suggest: - org.apache.myfaces.trinidad.CHECK_FILE_MODIFICATION only valid for JSPs (but consider project stage CHECK_FILE_MODIFICATION is not set explicitly) - for Facelets2 leave it to JSF impl (it will simply consider both javax.faces params as suggested in https://javaserverfaces.dev.java.net/issues/show_bug.cgi?id=1434) Or am I missing a basic point? For the CHECK_FILE_MODIFICATION I am planing (and that is true for other params) to give ProjectStage the highest priority. So, if application is on PRODUCTION, the CHECK_FILE_MODIFICATION will be FALSE. Now, if somebody sets the CHECK_FILE_MODIFICATION = TRUE, we will honor that AND we will log a WARNING that somebody is maybe confused with the parameters. Same for DEVELOPEMENT and the CHECK_FILE_MODIFICATION is set to FALSE. There we will log that it DEVELOPMENT_STAGE you may want CHECK_FILE_MODIFICATION to be TRUE On a similar pattern, I think the unspecified FACELETS_REFRESH_PERIOD fits in here. Does that make sense? -Matthias Thanks, Martin Kočí Matthias Wessendorf píše v St 02. 12. 2009 v 15:18 +0100: yep, that's what I was saying On Wed, Dec 2, 2009 at 3:04 PM, Jakob Korherr jakob.korh...@gmail.com wrote: Hi, I think the best way would be that the init parameters have stage related standard values (actually that what Matthias suggested), for example: If we are in ProjectStage.Production the standard value of org.apache.myfaces.trinidad.DISABLE_CONTENT_COMPRESSION is false, otherwise it is true. But this only sets the DEFAULT value. The user still can configure each parameter independently by putting it in web.xml. Regards Jakob Korherr 2009/12/2 Martin Koci martin.k...@aura.cz Hi, does trinidad reload both JSP and facelets views if org.apache.myfaces.trinidad.CHECK_FILE_MODIFICATION=true? For facelets based views there is a new JSF 2.0 param javax.faces.FACELETS_REFRESH_PERIOD (-1 = never reload, 0=always, 1,2, 3,.. - check interval) but it's relation to project stage is not clear - see https://javaserverfaces.dev.java.net/issues/show_bug.cgi?id=1434 Martin Kočí Matthias Wessendorf píše v St 02. 12. 2009 v 09:25 +0100: Hi, here is a (complete?) list of all Trinidad configuration parameters: * System Properties ( = System.getProperty()): org.apache.myfaces.trinidad.CHECK_STATE_SERIALIZATION documentation is here: http://issues.apache.org/jira/browse/TRINIDAD-1245 http://myfaces.apache.org/trinidad/trinidad-api/apidocs/org/apache/myfaces/trinidad/bean/util/StateUtils.html == does not really make sense to port to Stage. * The trinidad-config.xml file: See here for infos about it: http://myfaces.apache.org/trinidad/devguide/configuration.html I think that ONLY this element could make sense: -debug-output (e.g. as for PRODUCTION you want FALSE here... ) * Settings in the WEB.XML (aka Context Parameters): Some info is here as well: http://myfaces.apache.org/trinidad/devguide/configuration.html The web.xml has different types of settings: some fit to ProjectStage, some not.. Here is a grouped list, where I think they don't make sense with project_stage at all: -org.apache.myfaces.trinidad.CACHE_VIEW_ROOT -org.apache.myfaces.trinidad.CLIENT_STATE_METHOD -org.apache.myfaces.trinidad.CLIENT_STATE_MAX_TOKENS -org.apache.myfaces.trinidad.CHANGE_PERSISTENCE -org.apache.myfaces.trinidad.USE_APPLICATION_VIEW_CACHE -org.apache.myfaces.trinidad.ENABLE_LIGHTWEIGHT_DIALOGS -org.apache.myfaces.trinidad.ALTERNATE_VIEW_HANDLER -org.apache.myfaces.trinidad.FACELETS_VIEW_MAPPINGS -org.apache.myfaces.trinidad.UPLOAD_MAX_MEMORY -org.apache.myfaces.trinidad.UPLOAD_MAX_DISK_SPACE -org.apache.myfaces.trinidad.UPLOAD_TEMP_DIR These parameters do make sense: -org.apache.myfaces.trinidad.DEBUG_JAVASCRIPT -org.apache.myfaces.trinidad.DISABLE_CONTENT_COMPRESSION -org.apache.myfaces.trinidad.CHECK_FILE_MODIFICATION
Re: [Trinidad 2.0] introducing ProjectStage API
On Wed, Dec 2, 2009 at 8:52 PM, Pavitra Subramaniam pavitra.subraman...@oracle.com wrote: Matthias Wessendorf wrote: On 12/2/2009 10:43 AM PT: Ok, I added some value suggestions to those guys that we identified to fit into the ProjectStage API: -org.apache.myfaces.trinidad.DEBUG_JAVASCRIPT * Production = FALSE * other stages = TRUE +1. although I think if a user were to change the recommended defaults, like set ProjectStage=Production and override the DEBUG_JS to be true, then we at least need to warn the user of this as appropriate. Yeah I was planing do WARNING for everything that is overridden -org.apache.myfaces.trinidad.DISABLE_CONTENT_COMPRESSION * Production = FALSE * other stages = TRUE -org.apache.myfaces.trinidad.CHECK_FILE_MODIFICATION * Production = FALSE * other stages = TRUE -org.apache.myfaces.trinidad.resource.DEBUG * Production = FALSE * other stages = TRUE -org.apache.myfaces.trinidadinternal.ENABLE_PPR_OPTIMIZATION (see above) * Production = FALSE (current default) * other stages = TRUE -debug-output (from trinidad-config.xml file) * Production = FALSE * other stages = TRUE +1. I also was wondering if org.apache.myfaces.trinidad.CHECK_STATE_SERIALIZATION should be set to NONE in Production if this is really used for a testing Trinidad in pseudo-High Availability (HA) mode. It looks like we could set this different values based on the the ProjectStage Production org.apache.myfaces.trinidad.CHECK_STATE_SERIALIZATION=none Development, Unit Test org.apache.myfaces.trinidad.CHECK_STATE_SERIALIZATION=session,tree System Test org.apache.myfaces.trinidad.CHECK_STATE_SERIALIZATION=all great. thanks for the feedback. Makes sense to me. I think that this parameter actually *translates* to the ProjectStage. Your suggestions make sense to me. -Matthias -Pavitra Please let me know what you think... I updated the wiki page, to reflect the suggestions: http://wiki.apache.org/myfaces/Trinidad_goes_ProjectStage I also created this JIRA ticket, to keep track of the item: https://issues.apache.org/jira/browse/TRINIDAD-1652 -Matthias On Wed, Dec 2, 2009 at 3:18 PM, Matthias Wessendorf mat...@apache.org wrote: yep, that's what I was saying On Wed, Dec 2, 2009 at 3:04 PM, Jakob Korherr jakob.korh...@gmail.com wrote: Hi, I think the best way would be that the init parameters have stage related standard values (actually that what Matthias suggested), for example: If we are in ProjectStage.Production the standard value of org.apache.myfaces.trinidad.DISABLE_CONTENT_COMPRESSION is false, otherwise it is true. But this only sets the DEFAULT value. The user still can configure each parameter independently by putting it in web.xml. Regards Jakob Korherr 2009/12/2 Martin Koci martin.k...@aura.cz Hi, does trinidad reload both JSP and facelets views if org.apache.myfaces.trinidad.CHECK_FILE_MODIFICATION=true? For facelets based views there is a new JSF 2.0 param javax.faces.FACELETS_REFRESH_PERIOD (-1 = never reload, 0=always, 1,2, 3,.. - check interval) but it's relation to project stage is not clear - see https://javaserverfaces.dev.java.net/issues/show_bug.cgi?id=1434 Martin Kočí Matthias Wessendorf píše v St 02. 12. 2009 v 09:25 +0100: Hi, here is a (complete?) list of all Trinidad configuration parameters: * System Properties ( = System.getProperty()): org.apache.myfaces.trinidad.CHECK_STATE_SERIALIZATION documentation is here: http://issues.apache.org/jira/browse/TRINIDAD-1245 http://myfaces.apache.org/trinidad/trinidad-api/apidocs/org/apache/myfaces/trinidad/bean/util/StateUtils.html == does not really make sense to port to Stage. * The trinidad-config.xml file: See here for infos about it: http://myfaces.apache.org/trinidad/devguide/configuration.html I think that ONLY this element could make sense: -debug-output (e.g. as for PRODUCTION you want FALSE here... ) * Settings in the WEB.XML (aka Context Parameters): Some info is here as well: http://myfaces.apache.org/trinidad/devguide/configuration.html The web.xml has different types of settings: some fit to ProjectStage, some not.. Here is a grouped list, where I think they don't make sense with project_stage at all: -org.apache.myfaces.trinidad.CACHE_VIEW_ROOT -org.apache.myfaces.trinidad.CLIENT_STATE_METHOD -org.apache.myfaces.trinidad.CLIENT_STATE_MAX_TOKENS -org.apache.myfaces.trinidad.CHANGE_PERSISTENCE -org.apache.myfaces.trinidad.USE_APPLICATION_VIEW_CACHE -org.apache.myfaces.trinidad.ENABLE_LIGHTWEIGHT_DIALOGS -org.apache.myfaces.trinidad.ALTERNATE_VIEW_HANDLER -org.apache.myfaces.trinidad.FACELETS_VIEW_MAPPINGS -org.apache.myfaces.trinidad.UPLOAD_MAX_MEMORY -org.apache.myfaces.trinidad.UPLOAD_MAX_DISK_SPACE -org.apache.myfaces.trinidad.UPLOAD_TEMP_DIR These parameters do make sense: -org.apache.myfaces.trinidad.DEBUG_JAVASCRIPT
[jira] Resolved: (MYFACES-2434) dummy request/response classes for system event listeners will break with Servlet 3.0
[ https://issues.apache.org/jira/browse/MYFACES-2434?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Concini resolved MYFACES-2434. -- Resolution: Fixed Thanks to Bernhard Huemer for help in coming up with the final fix. dummy request/response classes for system event listeners will break with Servlet 3.0 - Key: MYFACES-2434 URL: https://issues.apache.org/jira/browse/MYFACES-2434 Project: MyFaces Core Issue Type: Bug Components: JSR-314 Affects Versions: 2.0.0-alpha Reporter: Michael Concini Assignee: Michael Concini Fix For: 2.0.0-alpha-2 Currently the _SystemEventServletRequest and _SystemEventServletResponse classes implement ServletRequest and ServletResponse directly. There are several new methods that must be implemented in the servlet 3.0 updates of those interfaces. This can be resolved by changing them to extend ServletRequestWrapper and ServletResponseWrapper instead of implementing directly. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (MYFACES-2443) org.apache.myfaces.shared_impl.webapp.webxml.WebXmlParser parse Unable to parse web.xml
org.apache.myfaces.shared_impl.webapp.webxml.WebXmlParser parse Unable to parse web.xml --- Key: MYFACES-2443 URL: https://issues.apache.org/jira/browse/MYFACES-2443 Project: MyFaces Core Issue Type: Bug Environment: AIX,WAS7 Reporter: viswam org.apache.myfaces.shared_impl.webapp.webxml.WebXmlParser parse Unable to parse web.xml java.net.ConnectException: A remote host did not respond within the timeout period. im getting error on WAS7,can some one help me -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (MYFACES-2443) org.apache.myfaces.shared_impl.webapp.webxml.WebXmlParser parse Unable to parse web.xml
[ https://issues.apache.org/jira/browse/MYFACES-2443?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matthias Weßendorf resolved MYFACES-2443. - Resolution: Invalid please use the user list to ask questions on myfaces. this is a bug tracker, not a discussion forum. also, more infos on the actual error are useful as well org.apache.myfaces.shared_impl.webapp.webxml.WebXmlParser parse Unable to parse web.xml --- Key: MYFACES-2443 URL: https://issues.apache.org/jira/browse/MYFACES-2443 Project: MyFaces Core Issue Type: Bug Environment: AIX,WAS7 Reporter: viswam org.apache.myfaces.shared_impl.webapp.webxml.WebXmlParser parse Unable to parse web.xml java.net.ConnectException: A remote host did not respond within the timeout period. this im getting when i deploy my webapplication on AIX,WAS7 box -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (TRINIDAD-1650) add support for empty field validation and BeanValidation API
[ https://issues.apache.org/jira/browse/TRINIDAD-1650?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matthias Weßendorf resolved TRINIDAD-1650. -- Resolution: Fixed Fix Version/s: 2.0.0-core add support for empty field validation and BeanValidation API --- Key: TRINIDAD-1650 URL: https://issues.apache.org/jira/browse/TRINIDAD-1650 Project: MyFaces Trinidad Issue Type: New Feature Affects Versions: 2.0.0-core Reporter: Matthias Weßendorf Assignee: Matthias Weßendorf Fix For: 2.0.0-core Attachments: TRINIDAD-1650.patch JSF 2.0 has support for run validation on empty fields (which integrates with BeanValidation) quoteFromSpec javax.faces.VALIDATE_EMPTY_FIELDS -- If this param is set, and calling toLowerCase().equals(true) on a String representation of its value returns true, all submitted fields will be validated. This is necessary to allow the model validator to decide whether null or empty values are allowable in the current application. If the value is false, null or empty values will not be passed to the validators. If the value is the string auto, the runtime must check if JSR-303 Beans Validation is present in the current environment. If so, the runtime must proceed as if the value true had been specified. If JSR-303 Beans Validation is not present in the current environment, the runtime most proceed as if the value false had been specified. If the param is not set, the system must behave as if the param was set with the value auto. /quoteFromSpec -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Tomahawk and JSF 2.0
is there anyone that is planing to do some stuff for JSF 2.0 and Tomahawk ? -Matthias -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf
