[jira] Commented: (MYFACES-3006) FacesContext current instance is null in managed bean action method for Tomcat 7
[
https://issues.apache.org/jira/browse/MYFACES-3006?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12997680#comment-12997680
]
Gurkan Erdogdu commented on MYFACES-3006:
-
OK, you can close the issue. 7.0.8 has no problem.
FacesContext current instance is null in managed bean action method for
Tomcat 7
Key: MYFACES-3006
URL: https://issues.apache.org/jira/browse/MYFACES-3006
Project: MyFaces Core
Issue Type: Bug
Affects Versions: 2.0.2
Reporter: Gurkan Erdogdu
Assignee: Leonardo Uribe
Hello,
Actually I am not sure that this is an error related with MyFaces.
In a managed bean action method, I have stopped an application Tomcat
Context(not same with the current JSF application).
public String stopContext(){
FacesContext.getCurrentInsatnce() -- It is ok, faces context is not null
Context context = get Tomcat application context;
//Stop tomcat context
context.stop(); -- This is any application on Tomcat, not same with
current JSF application
FacesContext.getCurrentInstance() -- Problem, it is NULL
}
I think that Tomcat clear current JSF application thread locals. But I ask to
stop other application context, therefore it must not destroy current
application thread locals.
What do you think?
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
Publish tomahawk-sandbox-1.1.9.jar in Maven Repo
Good morning everyone, Yesterday I wrote a similar post on the user list, but I guess writing to the dev list would have been more appropriate. I hope there's no problem in having written to both lists. I'd like to use the tomahawk-sandbox-1.1.9.jar in my application, but to do so I need to have it in a public maven repo (I'm not allowed to build from the source to use it). Would it be possible for a commiter to deploy the artifact in a public repository. I'd do it myself if I had clearance, but I think its not the case (I'm not commiter). Hope someone can help me out. Thanks in advance. Sebastian Gomez
Re: Trinidad website
Bernd did that, I think... sent from my Android phone On Feb 20, 2011 9:29 PM, Scott Oapos;Bryan axe...@dwarf.org wrote: Hey everyone, the release for Trinidad 2.0.0-beta-2 is all but done however the website does not build for some reason on main. I'm going to het his figured out and I'll make the announcement once it's deployed. On a remaining note, I'm going to be on a business trip next week so I'll have some time in the evenings (sans kids) to work on this idea I had for automatic 'site' deployment from hudson. The idea is to, essentially, build the site in Hudson and then have a script on people.apache.org which wgets it and posts it to the real website. Has anyone else tried this? If not, would anyone else be interested in the work once I'm done. I'm hoping to hook up the bridge and Trinidad to this, but would be happy to do other modules and/or give the code to others to enable modules.. Let me know, Scott
Re: Publish tomahawk-sandbox-1.1.9.jar in Maven Repo
Hi Sebastian, Unfortunately tomahawk-sandbox was not part of the tomahawk 1.1.9 release (see [1]). Thus we can't upload it to an apache repo. However, you could create your own public maven repo, build tomahawk-sandbox yourself, and upload it (maybe with a slightly different name) to this repo. Regards, Jakob [1] http://people.apache.org/~lu4242/tomahawk119/org/apache/myfaces/tomahawk/ 2011/2/22 Sebastian Gomez sage...@gmail.com: Good morning everyone, Yesterday I wrote a similar post on the user list, but I guess writing to the dev list would have been more appropriate. I hope there's no problem in having written to both lists. I'd like to use the tomahawk-sandbox-1.1.9.jar in my application, but to do so I need to have it in a public maven repo (I'm not allowed to build from the source to use it). Would it be possible for a commiter to deploy the artifact in a public repository. I'd do it myself if I had clearance, but I think its not the case (I'm not commiter). Hope someone can help me out. Thanks in advance. Sebastian Gomez -- Jakob Korherr blog: http://www.jakobk.com twitter: http://twitter.com/jakobkorherr work: http://www.irian.at
[jira] Resolved: (MYFACES-3006) FacesContext current instance is null in managed bean action method for Tomcat 7
[
https://issues.apache.org/jira/browse/MYFACES-3006?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jakob Korherr resolved MYFACES-3006.
Resolution: Won't Fix
Fix Version/s: 2.0.5-SNAPSHOT
FacesContext current instance is null in managed bean action method for
Tomcat 7
Key: MYFACES-3006
URL: https://issues.apache.org/jira/browse/MYFACES-3006
Project: MyFaces Core
Issue Type: Bug
Affects Versions: 2.0.2
Reporter: Gurkan Erdogdu
Assignee: Leonardo Uribe
Fix For: 2.0.5-SNAPSHOT
Hello,
Actually I am not sure that this is an error related with MyFaces.
In a managed bean action method, I have stopped an application Tomcat
Context(not same with the current JSF application).
public String stopContext(){
FacesContext.getCurrentInsatnce() -- It is ok, faces context is not null
Context context = get Tomcat application context;
//Stop tomcat context
context.stop(); -- This is any application on Tomcat, not same with
current JSF application
FacesContext.getCurrentInstance() -- Problem, it is NULL
}
I think that Tomcat clear current JSF application thread locals. But I ask to
stop other application context, therefore it must not destroy current
application thread locals.
What do you think?
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Reopened: (MYFACES-3044) Resource jsf.js not found when using the OSGi bundle
[ https://issues.apache.org/jira/browse/MYFACES-3044?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jakob Korherr reopened MYFACES-3044: Assignee: (was: Leonardo Uribe) I disagree that this is the expected behavior. Users will use our OSGi-bundle also if ProjectStage==Development and not only in Production. So if we do not fix it, users would have to use ProjectStage==Production for development too and that's just wrong! Also it should be really easy to fix. From the dev-list: add META-INF.internal-resources.javax.faces and META-INF.services to the exported packages in MANIFEST.MF. Resource jsf.js not found when using the OSGi bundle Key: MYFACES-3044 URL: https://issues.apache.org/jira/browse/MYFACES-3044 Project: MyFaces Core Issue Type: Bug Affects Versions: 2.0.3 Reporter: Clovis First there is a WARNING: Resource referenced by resourceName jsf.js and libraryName javax.faces not found in call to ResourceHandler.createResource. It will be silenty ignored. and later a NullPointerException Using javax.faces.PROJECT_STAGE=Development, the class loader was trying to load META-INF/internal-resources/javax.faces/jsf-uncompressed-full.js (so I added the package META-INF.internal-resources.javax.faces to the list of exported packages of myfaces-bundle.jar). But then I changed it from Development to Production, and myfaces tried to load something else (and I decided to write a bug). -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (TOBAGO-976) The resize facet of the page should also support a script command
[ https://issues.apache.org/jira/browse/TOBAGO-976?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12997720#comment-12997720 ] Udo Schnurpfeil commented on TOBAGO-976: I've also changed: - the facet name from resizeAction to resize (the old one was set to deprecated) - the facet doesn't need to work with a tc:form, the validation bypass and value buffering should be done with immediate=true (the old behavior was set to deprecated) The resize facet of the page should also support a script command - Key: TOBAGO-976 URL: https://issues.apache.org/jira/browse/TOBAGO-976 Project: MyFaces Tobago Issue Type: New Feature Reporter: Udo Schnurpfeil Assignee: Udo Schnurpfeil Priority: Minor -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (TOBAGO-976) The resize facet of the page should also support a script command
[ https://issues.apache.org/jira/browse/TOBAGO-976?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Udo Schnurpfeil resolved TOBAGO-976. Resolution: Fixed Fix Version/s: 1.5.0 1.5.0-alpha-3 The resize facet of the page should also support a script command - Key: TOBAGO-976 URL: https://issues.apache.org/jira/browse/TOBAGO-976 Project: MyFaces Tobago Issue Type: New Feature Reporter: Udo Schnurpfeil Assignee: Udo Schnurpfeil Priority: Minor Fix For: 1.5.0-alpha-3, 1.5.0 -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MYFACES-3044) Resource jsf.js not found when using the OSGi bundle
[
https://issues.apache.org/jira/browse/MYFACES-3044?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12997722#comment-12997722
]
Jakob Korherr commented on MYFACES-3044:
Adding this to the export packages of the maven-bundle-plugin configuration
should fix this issue:
META-INF.internal-resources.javax.faces;version=${project.version},
META-INF.resources;version=${project.version},
META-INF.services;version=${project.version}
However, I am not sure if this is the expected thing to do here. Is anyone here
more familiar with OSGi?
Resource jsf.js not found when using the OSGi bundle
Key: MYFACES-3044
URL: https://issues.apache.org/jira/browse/MYFACES-3044
Project: MyFaces Core
Issue Type: Bug
Affects Versions: 2.0.3
Reporter: Clovis
First there is a
WARNING: Resource referenced by resourceName jsf.js and libraryName
javax.faces not found in call to ResourceHandler.createResource. It will be
silenty ignored.
and later a NullPointerException
Using javax.faces.PROJECT_STAGE=Development, the class loader was trying to
load META-INF/internal-resources/javax.faces/jsf-uncompressed-full.js (so I
added the package META-INF.internal-resources.javax.faces to the list of
exported packages of myfaces-bundle.jar). But then I changed it from
Development to Production, and myfaces tried to load something else (and I
decided to write a bug).
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MYFACES-3051) Use ClassLoaderUtils.getContextClassLoader() instead of Thread.currentThread().getContextClassLoader()
Use ClassLoaderUtils.getContextClassLoader() instead of Thread.currentThread().getContextClassLoader() -- Key: MYFACES-3051 URL: https://issues.apache.org/jira/browse/MYFACES-3051 Project: MyFaces Core Issue Type: Bug Affects Versions: 2.0.4 Environment: Very important for environments with SecurityManagers in place, or also in OSGi Reporter: Jakob Korherr The utility method ClassLoaderUtils.getContextClassLoader() uses the SecurityManager (if installed) to get the current context ClassLoader. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MYFACES-3044) Resource jsf.js not found when using the OSGi bundle
[ https://issues.apache.org/jira/browse/MYFACES-3044?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12997728#comment-12997728 ] Jakob Korherr commented on MYFACES-3044: Maybe this issue can also be fixed without adding these entries to the MANIFEST.MF, but by changing the resource loading mechanism to use multiple ClassLoaders.. Resource jsf.js not found when using the OSGi bundle Key: MYFACES-3044 URL: https://issues.apache.org/jira/browse/MYFACES-3044 Project: MyFaces Core Issue Type: Bug Affects Versions: 2.0.3 Reporter: Clovis First there is a WARNING: Resource referenced by resourceName jsf.js and libraryName javax.faces not found in call to ResourceHandler.createResource. It will be silenty ignored. and later a NullPointerException Using javax.faces.PROJECT_STAGE=Development, the class loader was trying to load META-INF/internal-resources/javax.faces/jsf-uncompressed-full.js (so I added the package META-INF.internal-resources.javax.faces to the list of exported packages of myfaces-bundle.jar). But then I changed it from Development to Production, and myfaces tried to load something else (and I decided to write a bug). -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MYFACES-3051) Use multiple ClassLoaders to find resources (not only ContextClassLoader)
[
https://issues.apache.org/jira/browse/MYFACES-3051?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12997739#comment-12997739
]
Jakob Korherr commented on MYFACES-3051:
This method from ResourceHandlerImpl is a perfect example for the ClassLoader
mechansim I am describing:
private static ResourceBundle getBundle(FacesContext facesContext, Locale
locale, String bundleName)
{
try
{
// First we try the JSF implementation class loader
return ResourceBundle.getBundle(bundleName, locale,
ResourceHandlerImpl.class.getClassLoader());
}
catch (MissingResourceException ignore1)
{
try
{
// Next we try the JSF API class loader
return ResourceBundle.getBundle(bundleName, locale,
ResourceHandler.class.getClassLoader());
}
catch (MissingResourceException ignore2)
{
try
{
// Last resort is the context class loader
return ResourceBundle.getBundle(bundleName, locale,
ClassUtils.getContextClassLoader());
}
catch (MissingResourceException damned)
{
return null;
}
}
}
}
Use multiple ClassLoaders to find resources (not only ContextClassLoader)
-
Key: MYFACES-3051
URL: https://issues.apache.org/jira/browse/MYFACES-3051
Project: MyFaces Core
Issue Type: Bug
Affects Versions: 2.0.4
Environment: OSGi
Reporter: Jakob Korherr
In most parts of the code we only use the ContextClassLoader to find Classes
and Resources. However, in some parts we also use the ClassLoader of the
current Class or of a specific Class (e.g. to use myfaces-api and/or
myfaces-impl ClassLoader, see ApplicationImpl.getResourceBundle(),
BeanValidator.postSetValidationGroups(), ResourceHandlerImpl.getBundle() or
FactoryFinder for example).
IMO we should unify this code and maybe provide a custom ClassLoader that
encapsulates three ClassLoaders (ContextClassLoader, myfaces-api and
myfaces-impl). This most certainly would solve a lot of OSGi related problems.
WDYT?
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MYFACES-3044) Resource jsf.js not found when using the OSGi bundle
[ https://issues.apache.org/jira/browse/MYFACES-3044?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12997740#comment-12997740 ] Clovis commented on MYFACES-3044: - I don't know if you are willing to add exported packages every time someone realizes that, for some configuration, a file from a non-exported package is required... For example, with PROJECT_STATE=Production, META-INF.resources.javax.faces is also needed as exported package. Resource jsf.js not found when using the OSGi bundle Key: MYFACES-3044 URL: https://issues.apache.org/jira/browse/MYFACES-3044 Project: MyFaces Core Issue Type: Bug Affects Versions: 2.0.3 Reporter: Clovis First there is a WARNING: Resource referenced by resourceName jsf.js and libraryName javax.faces not found in call to ResourceHandler.createResource. It will be silenty ignored. and later a NullPointerException Using javax.faces.PROJECT_STAGE=Development, the class loader was trying to load META-INF/internal-resources/javax.faces/jsf-uncompressed-full.js (so I added the package META-INF.internal-resources.javax.faces to the list of exported packages of myfaces-bundle.jar). But then I changed it from Development to Production, and myfaces tried to load something else (and I decided to write a bug). -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MYFACES-3044) Resource jsf.js not found when using the OSGi bundle
[ https://issues.apache.org/jira/browse/MYFACES-3044?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12997742#comment-12997742 ] Jakob Korherr commented on MYFACES-3044: Hehe, yes. That's why I am trying to fix this issue via MYFACES-3051. Resource jsf.js not found when using the OSGi bundle Key: MYFACES-3044 URL: https://issues.apache.org/jira/browse/MYFACES-3044 Project: MyFaces Core Issue Type: Bug Affects Versions: 2.0.3 Reporter: Clovis First there is a WARNING: Resource referenced by resourceName jsf.js and libraryName javax.faces not found in call to ResourceHandler.createResource. It will be silenty ignored. and later a NullPointerException Using javax.faces.PROJECT_STAGE=Development, the class loader was trying to load META-INF/internal-resources/javax.faces/jsf-uncompressed-full.js (so I added the package META-INF.internal-resources.javax.faces to the list of exported packages of myfaces-bundle.jar). But then I changed it from Development to Production, and myfaces tried to load something else (and I decided to write a bug). -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MYFACES-3051) Use multiple ClassLoaders to find resources (not only ContextClassLoader)
[ https://issues.apache.org/jira/browse/MYFACES-3051?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12997745#comment-12997745 ] Jakob Korherr commented on MYFACES-3051: Just found something similar at Apache ibatis: http://svn.apache.org/repos/asf/ibatis/java/ibatis-3/tags/java_release_3.0.0-196_beta_2/ibatis-3-core/src/main/java/org/apache/ibatis/io/ClassLoaderWrapper.java Use multiple ClassLoaders to find resources (not only ContextClassLoader) - Key: MYFACES-3051 URL: https://issues.apache.org/jira/browse/MYFACES-3051 Project: MyFaces Core Issue Type: Bug Affects Versions: 2.0.4 Environment: OSGi Reporter: Jakob Korherr In most parts of the code we only use the ContextClassLoader to find Classes and Resources. However, in some parts we also use the ClassLoader of the current Class or of a specific Class (e.g. to use myfaces-api and/or myfaces-impl ClassLoader, see ApplicationImpl.getResourceBundle(), BeanValidator.postSetValidationGroups(), ResourceHandlerImpl.getBundle() or FactoryFinder for example). IMO we should unify this code and maybe provide a custom ClassLoader that encapsulates three ClassLoaders (ContextClassLoader, myfaces-api and myfaces-impl). This most certainly would solve a lot of OSGi related problems. WDYT? -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Publish tomahawk-sandbox-1.1.9.jar in Maven Repo
short addition: if you are really sure that you need it and you don't have the infrastructure for it, you could use the wagon-svn maven extension for using a svn repository as maven repository. regards, gerhard http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces 2011/2/22 Jakob Korherr jakob.korh...@gmail.com Hi Sebastian, Unfortunately tomahawk-sandbox was not part of the tomahawk 1.1.9 release (see [1]). Thus we can't upload it to an apache repo. However, you could create your own public maven repo, build tomahawk-sandbox yourself, and upload it (maybe with a slightly different name) to this repo. Regards, Jakob [1] http://people.apache.org/~lu4242/tomahawk119/org/apache/myfaces/tomahawk/ 2011/2/22 Sebastian Gomez sage...@gmail.com: Good morning everyone, Yesterday I wrote a similar post on the user list, but I guess writing to the dev list would have been more appropriate. I hope there's no problem in having written to both lists. I'd like to use the tomahawk-sandbox-1.1.9.jar in my application, but to do so I need to have it in a public maven repo (I'm not allowed to build from the source to use it). Would it be possible for a commiter to deploy the artifact in a public repository. I'd do it myself if I had clearance, but I think its not the case (I'm not commiter). Hope someone can help me out. Thanks in advance. Sebastian Gomez -- Jakob Korherr blog: http://www.jakobk.com twitter: http://twitter.com/jakobkorherr work: http://www.irian.at
Re: Publish tomahawk-sandbox-1.1.9.jar in Maven Repo
Thanks for such quick and concise answer Jakob. One last thing, does anyone know if there are plans in incorporating the pprPanelGroup into the trunk to be released in some near future in a non-sandbox release? Best regards, Sebastian Gomez On Tue, Feb 22, 2011 at 10:41 AM, Jakob Korherr jakob.korh...@gmail.comwrote: Hi Sebastian, Unfortunately tomahawk-sandbox was not part of the tomahawk 1.1.9 release (see [1]). Thus we can't upload it to an apache repo. However, you could create your own public maven repo, build tomahawk-sandbox yourself, and upload it (maybe with a slightly different name) to this repo. Regards, Jakob [1] http://people.apache.org/~lu4242/tomahawk119/org/apache/myfaces/tomahawk/ 2011/2/22 Sebastian Gomez sage...@gmail.com: Good morning everyone, Yesterday I wrote a similar post on the user list, but I guess writing to the dev list would have been more appropriate. I hope there's no problem in having written to both lists. I'd like to use the tomahawk-sandbox-1.1.9.jar in my application, but to do so I need to have it in a public maven repo (I'm not allowed to build from the source to use it). Would it be possible for a commiter to deploy the artifact in a public repository. I'd do it myself if I had clearance, but I think its not the case (I'm not commiter). Hope someone can help me out. Thanks in advance. Sebastian Gomez -- Jakob Korherr blog: http://www.jakobk.com twitter: http://twitter.com/jakobkorherr work: http://www.irian.at
Re: Publish tomahawk-sandbox-1.1.9.jar in Maven Repo
Thanks Gerhard, I'll take look at the project and update! On Tue, Feb 22, 2011 at 1:17 PM, Sebastian Gomez sage...@gmail.com wrote: Thanks for such quick and concise answer Jakob. One last thing, does anyone know if there are plans in incorporating the pprPanelGroup into the trunk to be released in some near future in a non-sandbox release? Best regards, Sebastian Gomez On Tue, Feb 22, 2011 at 10:41 AM, Jakob Korherr jakob.korh...@gmail.comwrote: Hi Sebastian, Unfortunately tomahawk-sandbox was not part of the tomahawk 1.1.9 release (see [1]). Thus we can't upload it to an apache repo. However, you could create your own public maven repo, build tomahawk-sandbox yourself, and upload it (maybe with a slightly different name) to this repo. Regards, Jakob [1] http://people.apache.org/~lu4242/tomahawk119/org/apache/myfaces/tomahawk/ 2011/2/22 Sebastian Gomez sage...@gmail.com: Good morning everyone, Yesterday I wrote a similar post on the user list, but I guess writing to the dev list would have been more appropriate. I hope there's no problem in having written to both lists. I'd like to use the tomahawk-sandbox-1.1.9.jar in my application, but to do so I need to have it in a public maven repo (I'm not allowed to build from the source to use it). Would it be possible for a commiter to deploy the artifact in a public repository. I'd do it myself if I had clearance, but I think its not the case (I'm not commiter). Hope someone can help me out. Thanks in advance. Sebastian Gomez -- Jakob Korherr blog: http://www.jakobk.com twitter: http://twitter.com/jakobkorherr work: http://www.irian.at
[jira] Created: (MYFACES-3052) composite:insertchildren not working entirely correctly
composite:insertchildren not working entirely correctly --- Key: MYFACES-3052 URL: https://issues.apache.org/jira/browse/MYFACES-3052 Project: MyFaces Core Issue Type: Bug Affects Versions: 2.0.4 Reporter: Werner Punz According to the html spec insertchildren in a composite component should reposition every child component within the composite tag to the final rendering position defined via insertchildren. So far so good, but following usecase swallows the jsf component and only renders the html markup. component call: ezw:pull id=pull h:outputScript value=hello world /h:outputScript /ezw:pull with the component ui:component xmlns= xmlns:ui=http://java.sun.com/jsf/facelets; xmlns:composite=http://java.sun.com/jsf/composite; xmlns:f=http://java.sun.com/jsf/core; xmlns:h=http://java.sun.com/jsf/html; xmlns:c=http://java.sun.com/jsp/jstl/core; composite:interface /composite:interface composite:implementation composite:insertChildren/composite:insertChildren /composite:implementation /ui:component results in only being rendered but hello world emitted by the outputscript being swallowed. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MYFACES-3053) Improve error reporting and logging
Improve error reporting and logging --- Key: MYFACES-3053 URL: https://issues.apache.org/jira/browse/MYFACES-3053 Project: MyFaces Core Issue Type: Improvement Components: General Reporter: Martin Kočí Priority: Minor See http://www.mail-archive.com/dev@myfaces.apache.org/msg50721.html And from http://wiki.java.net/bin/view/Projects/Jsf2RequirementsScratchpad: Better Error reporting, like what you get with Tapestry (also in JSR-252-EG, where it was said: any time there is an error in *any* part of the lifecycle, the user should see not just a cryptic stack trace, but also the component - including file and line number - that triggered the problem, the EL expression that was being evaluated - including the part of the EL expression that triggered the problem, etc. Diagnosability for state saving is also important. On this point, Gavin King wants to have centralized error handling, with an interception point, perhaps using navigation rules, to help handle errors.) -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MYFACES-3052) composite:insertchildren not working entirely correctly
[ https://issues.apache.org/jira/browse/MYFACES-3052?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12997830#comment-12997830 ] Jakob Korherr commented on MYFACES-3052: Werner, I guess you misused h:outputScript /: h:outputScript value=some value / does not produce any output. You should use h:outputScript resourceName=... libraryName=... / instead. I think what you meant was h:outputText value=some value /. However, this should work with cc:insertChildren /. Could you please verify this? composite:insertchildren not working entirely correctly --- Key: MYFACES-3052 URL: https://issues.apache.org/jira/browse/MYFACES-3052 Project: MyFaces Core Issue Type: Bug Affects Versions: 2.0.4 Reporter: Werner Punz According to the html spec insertchildren in a composite component should reposition every child component within the composite tag to the final rendering position defined via insertchildren. So far so good, but following usecase swallows the jsf component and only renders the html markup. component call: ezw:pull id=pull h:outputScript value=hello world /h:outputScript /ezw:pull with the component ui:component xmlns= xmlns:ui=http://java.sun.com/jsf/facelets; xmlns:composite=http://java.sun.com/jsf/composite; xmlns:f=http://java.sun.com/jsf/core; xmlns:h=http://java.sun.com/jsf/html; xmlns:c=http://java.sun.com/jsp/jstl/core; composite:interface /composite:interface composite:implementation composite:insertChildren/composite:insertChildren /composite:implementation /ui:component results in only being rendered but hello world emitted by the outputscript being swallowed. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MYFACES-3054) Allow forClass and value (converterId) together for @FacesConverter
Allow forClass and value (converterId) together for @FacesConverter --- Key: MYFACES-3054 URL: https://issues.apache.org/jira/browse/MYFACES-3054 Project: MyFaces Core Issue Type: Bug Components: JSR-314 Affects Versions: 2.0.4 Environment: myfaces core trunk Reporter: Martin Kočí @FacesConverter(forClass=MyClass.class,value=myClassConverter) currently processes the forClass attribute and value( = converterId) is ignored. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MYFACES-3054) Allow forClass and value (converterId) together for @FacesConverter
[ https://issues.apache.org/jira/browse/MYFACES-3054?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Kočí updated MYFACES-3054: - Status: Patch Available (was: Open) Allow forClass and value (converterId) together for @FacesConverter --- Key: MYFACES-3054 URL: https://issues.apache.org/jira/browse/MYFACES-3054 Project: MyFaces Core Issue Type: Bug Components: JSR-314 Affects Versions: 2.0.4 Environment: myfaces core trunk Reporter: Martin Kočí @FacesConverter(forClass=MyClass.class,value=myClassConverter) currently processes the forClass attribute and value( = converterId) is ignored. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (MYFACES-3052) composite:insertchildren not working entirely correctly
[ https://issues.apache.org/jira/browse/MYFACES-3052?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Werner Punz resolved MYFACES-3052. -- Resolution: Invalid my fault composite:insertchildren not working entirely correctly --- Key: MYFACES-3052 URL: https://issues.apache.org/jira/browse/MYFACES-3052 Project: MyFaces Core Issue Type: Bug Affects Versions: 2.0.4 Reporter: Werner Punz According to the html spec insertchildren in a composite component should reposition every child component within the composite tag to the final rendering position defined via insertchildren. So far so good, but following usecase swallows the jsf component and only renders the html markup. component call: ezw:pull id=pull h:outputScript value=hello world /h:outputScript /ezw:pull with the component ui:component xmlns= xmlns:ui=http://java.sun.com/jsf/facelets; xmlns:composite=http://java.sun.com/jsf/composite; xmlns:f=http://java.sun.com/jsf/core; xmlns:h=http://java.sun.com/jsf/html; xmlns:c=http://java.sun.com/jsp/jstl/core; composite:interface /composite:interface composite:implementation composite:insertChildren/composite:insertChildren /composite:implementation /ui:component results in only being rendered but hello world emitted by the outputscript being swallowed. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (EXTCDI-144) projectStageActivationExtensionTest fails on hudson
[ https://issues.apache.org/jira/browse/EXTCDI-144?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gerhard Petracek resolved EXTCDI-144. - Resolution: Fixed projectStageActivationExtensionTest fails on hudson --- Key: EXTCDI-144 URL: https://issues.apache.org/jira/browse/EXTCDI-144 Project: MyFaces CODI Issue Type: Bug Components: Core Affects Versions: 0.9.3 Reporter: Mark Struberg Assignee: Mark Struberg Priority: Minor On hudson, the ProjectStageActivationExtensionTest throws an Exception. But all works fine if it runs locally. It also works if we pull the project from hg or git then all is fine and the test succeeds even in the hudson.a.o. It seems to have a problem if hudson checks out from SVN. javax.enterprise.inject.ResolutionException: Cannot find beans for class org.apache.myfaces.extensions.cdi.core.test.impl.projectstage.testbeans.MyMailService null at org.apache.webbeans.util.InjectionExceptionUtils.throwBeanNotFoundException(InjectionExceptionUtils.java:52) at org.apache.webbeans.cditest.owb.CdiTestOpenWebBeansContainer.getInstance(CdiTestOpenWebBeansContainer.java:156) at org.apache.myfaces.extensions.cdi.core.test.util.ContainerTestBase.getBeanInstance(ContainerTestBase.java:53) at org.apache.myfaces.extensions.cdi.core.test.impl.projectstage.ProjectStageActivationExtensionTest.testProjectStageActivationExtension(ProjectStageActivationExtensionTest.java:35) -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MYFACES-3054) Allow forClass and value (converterId) together for @FacesConverter
[ https://issues.apache.org/jira/browse/MYFACES-3054?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leonardo Uribe updated MYFACES-3054: Resolution: Fixed Fix Version/s: 2.0.5-SNAPSHOT Assignee: Leonardo Uribe Status: Resolved (was: Patch Available) thanks to Martin Koci for provide this patch Allow forClass and value (converterId) together for @FacesConverter --- Key: MYFACES-3054 URL: https://issues.apache.org/jira/browse/MYFACES-3054 Project: MyFaces Core Issue Type: Bug Components: JSR-314 Affects Versions: 2.0.4 Environment: myfaces core trunk Reporter: Martin Kočí Assignee: Leonardo Uribe Fix For: 2.0.5-SNAPSHOT Attachments: MYFACES-3054.patch @FacesConverter(forClass=MyClass.class,value=myClassConverter) currently processes the forClass attribute and value( = converterId) is ignored. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Publish tomahawk-sandbox-1.1.9.jar in Maven Repo
We've been really slow about promoting things out of sandbox. Here's how you can help make that happen. http://wiki.apache.org/myfaces/promotion I've not used pprPanelGroup so I don't really know the status of it. With the changes in MyFaces 2.0 supporting ajax, it may be no longer required. On Tue, Feb 22, 2011 at 7:17 AM, Sebastian Gomez sage...@gmail.com wrote: Thanks for such quick and concise answer Jakob. One last thing, does anyone know if there are plans in incorporating the pprPanelGroup into the trunk to be released in some near future in a non-sandbox release? Best regards, Sebastian Gomez On Tue, Feb 22, 2011 at 10:41 AM, Jakob Korherr jakob.korh...@gmail.com wrote: Hi Sebastian, Unfortunately tomahawk-sandbox was not part of the tomahawk 1.1.9 release (see [1]). Thus we can't upload it to an apache repo. However, you could create your own public maven repo, build tomahawk-sandbox yourself, and upload it (maybe with a slightly different name) to this repo. Regards, Jakob [1] http://people.apache.org/~lu4242/tomahawk119/org/apache/myfaces/tomahawk/ 2011/2/22 Sebastian Gomez sage...@gmail.com: Good morning everyone, Yesterday I wrote a similar post on the user list, but I guess writing to the dev list would have been more appropriate. I hope there's no problem in having written to both lists. I'd like to use the tomahawk-sandbox-1.1.9.jar in my application, but to do so I need to have it in a public maven repo (I'm not allowed to build from the source to use it). Would it be possible for a commiter to deploy the artifact in a public repository. I'd do it myself if I had clearance, but I think its not the case (I'm not commiter). Hope someone can help me out. Thanks in advance. Sebastian Gomez -- Jakob Korherr blog: http://www.jakobk.com twitter: http://twitter.com/jakobkorherr work: http://www.irian.at
[jira] Commented: (TRINIDAD-2042) Trinidad TagDoc report plugin does not allow mvn site:site target to run
[ https://issues.apache.org/jira/browse/TRINIDAD-2042?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12997924#comment-12997924 ] Scott O'Bryan commented on TRINIDAD-2042: - This was due to some local references to Log4J and commons logging in the tagdoc plugin. If those are removed, everything seems to work fine. I have checked the changes into the 2.0 plugins branch and am working on getting the fix to reference the snapshot checked into trinidad trunk. This will mean that a new version of the plugins will need to be released before the next version of trinidad. Trinidad TagDoc report plugin does not allow mvn site:site target to run Key: TRINIDAD-2042 URL: https://issues.apache.org/jira/browse/TRINIDAD-2042 Project: MyFaces Trinidad Issue Type: Bug Components: Plugins Reporter: Scott O'Bryan Assignee: Scott O'Bryan When running 'mvn site:site' on main, the following error is thrown: org.apache.commons.logging.LogConfigurationException: org.apache.commons.logging.LogConfigurationException: org.apache.commons.logging.LogConfigurationException: Invalid class loader hierarchy. You have more than one version of 'org.apache.commons.logging.Log' visible, which is not allowed. (Caused by org.apache.commons.logging.LogConfigurationException: Invalid class loader hierarchy. You have more than one version of 'org.apache.commons.logging.Log' visible, which is not allowed.) (Caused by org.apache.commons.logging.LogConfigurationException: org.apache.commons.logging.LogConfigurationException: Invalid class loader hierarchy. You have more than one version of 'org.apache.commons.logging.Log' visible, which is not allowed. (Caused by org.apache.commons.logging.LogConfigurationException: Invalid class loader hierarchy. You have more than one version of 'org.apache.commons.logging.Log' visible, which is not allowed.)) at org.apache.commons.logging.impl.LogFactoryImpl.newInstance(LogFactoryImpl.java:543) at org.apache.commons.logging.impl.LogFactoryImpl.getInstance(LogFactoryImpl.java:235) at org.apache.commons.logging.LogFactory.getLog(LogFactory.java:370) at org.apache.commons.digester.Digester.init(Digester.java:304) at org.apache.myfaces.trinidadbuild.plugin.tagdoc.TagdocReport.readIndex(TagdocReport.java:1673) at org.apache.myfaces.trinidadbuild.plugin.tagdoc.TagdocReport.processIndex(TagdocReport.java:1592) at org.apache.myfaces.trinidadbuild.plugin.tagdoc.TagdocReport.executeReport(TagdocReport.java:105) It looks like there is an incompatible logger version or the logger has been declared multiple times in the environment. This must be fixed before the maven site can be generated. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[codi] first steps for the next release
hi @ all, if there are no objections, i'll start with the first steps for the next release (review, documentation,...). it would be great to start with the release procedure next week. regards, gerhard http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
Re: [codi] first steps for the next release
+1 Regards, Jakob 2011/2/22 Gerhard gerhard.petra...@gmail.com: hi @ all, if there are no objections, i'll start with the first steps for the next release (review, documentation,...). it would be great to start with the release procedure next week. regards, gerhard http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces -- Jakob Korherr blog: http://www.jakobk.com twitter: http://twitter.com/jakobkorherr work: http://www.irian.at
Re: [codi] first steps for the next release
gimme a few hours, just like to fix a few things found by our sonar installation. Oh btw, now available: http://analysis.apache.org/dashboard/index/46254 Will request the same thing for MyFaces current20 also. LieGrue, strub --- On Tue, 2/22/11, Jakob Korherr jakob.korh...@gmail.com wrote: From: Jakob Korherr jakob.korh...@gmail.com Subject: Re: [codi] first steps for the next release To: MyFaces Development dev@myfaces.apache.org Date: Tuesday, February 22, 2011, 5:52 PM +1 Regards, Jakob 2011/2/22 Gerhard gerhard.petra...@gmail.com: hi @ all, if there are no objections, i'll start with the first steps for the next release (review, documentation,...). it would be great to start with the release procedure next week. regards, gerhard http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces -- Jakob Korherr blog: http://www.jakobk.com twitter: http://twitter.com/jakobkorherr work: http://www.irian.at
Re: [codi] first steps for the next release
+1 i'll also have a look at it and i'm going to start with the documentation anyway. regards, gerhard http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces 2011/2/22 Mark Struberg strub...@yahoo.de gimme a few hours, just like to fix a few things found by our sonar installation. Oh btw, now available: http://analysis.apache.org/dashboard/index/46254 Will request the same thing for MyFaces current20 also. LieGrue, strub --- On Tue, 2/22/11, Jakob Korherr jakob.korh...@gmail.com wrote: From: Jakob Korherr jakob.korh...@gmail.com Subject: Re: [codi] first steps for the next release To: MyFaces Development dev@myfaces.apache.org Date: Tuesday, February 22, 2011, 5:52 PM +1 Regards, Jakob 2011/2/22 Gerhard gerhard.petra...@gmail.com: hi @ all, if there are no objections, i'll start with the first steps for the next release (review, documentation,...). it would be great to start with the release procedure next week. regards, gerhard http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces -- Jakob Korherr blog: http://www.jakobk.com twitter: http://twitter.com/jakobkorherr work: http://www.irian.at
[ANNOUNCE] MyFaces Trinidad v2.0.0-beta-2 Release
The Apache MyFaces team is pleased to announce the release of MyFaces Trinidad 2.0.0-beta-2. MyFaces Trinidad is a feature-rich renderkit for JavaServer Faces that provides an extendibles framework and extensive skinning support. This version is designed to be used with the JSF 2.0 specification and works with either Mojarra or MyFaces. MyFaces Trinidad 2.0.0-beta-2 is available in both binary and source distributions[1]. * http://myfaces.apache.org/trinidad/download.html Release Notes - MyFaces Trinidad - Version 2.0.0-beta-2 Bug * [TRINIDAD-744] - Update translated message files * [TRINIDAD-1819] - PPR Issues in Windows Mobile 6 * [TRINIDAD-1922] - In Facelets, Partial Refreshingtr:inputText Not Working * [TRINIDAD-1958] - Client tr:numberConverter with type=currency incorrectly handles arabic locale for positive values * [TRINIDAD-1996] - FacesContextFactoryImpl's FacesContext (CacheRenderKit) needs to extend FacesContextWrapper not FacesContext * [TRINIDAD-2009] - tr:table selectAll also selects disabled chekcboxes * [TRINIDAD-2016] - wrong warning message for content compression * [TRINIDAD-2017] - Trinidad statemananger needs to store everything on the client, when HTML_Basic is used, in combination with standard client-side state-saving * [TRINIDAD-2020] - TableRenderer does not support JSF 2 source parameter for paging * [TRINIDAD-2023] - CheckSerializationConfigurator should use the Trinidad specific ObjectInputStream (ObjectInputStreamResolveClass) class * [TRINIDAD-2024] - UIXCollection holding only to application data * [TRINIDAD-2029] - LabeledFacesMessage should handle the case where label is of type ValueExpression * [TRINIDAD-2031] - Error message displayed on upload failure from custom ChainedUploadedFileProcessor has extra full stop * [TRINIDAD-2033] - trh:tableLayout tag doc should call out table-layout:fixed as desirable for programmatically-resizable cell contents * [TRINIDAD-2035] - Several resources do not have proper capitolization * [TRINIDAD-2037] - Unable to build from source archive Improvement * [TRINIDAD-1767] - Warn and no-op on SkinFactory.addSkin for duplicate skins. Regards, Scott O'Bryan
[jira] Resolved: (TRINIDAD-2043) af|separator:alias should be af|separator in base-desktop.css
[
https://issues.apache.org/jira/browse/TRINIDAD-2043?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jeanne Waldman resolved TRINIDAD-2043.
--
Resolution: Fixed
Fix Version/s: 2.0.0-beta-3
af|separator:alias should be af|separator in base-desktop.css
-
Key: TRINIDAD-2043
URL: https://issues.apache.org/jira/browse/TRINIDAD-2043
Project: MyFaces Trinidad
Issue Type: Bug
Reporter: Jeanne Waldman
Assignee: Jeanne Waldman
Fix For: 2.0.0-beta-3
In base-desktop.css, we have af|separator:alias {}. The selector should be
af|separator {}
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MYFACES-3055) META-INF/faces-config.xml files in JARs are loaded twice
META-INF/faces-config.xml files in JARs are loaded twice Key: MYFACES-3055 URL: https://issues.apache.org/jira/browse/MYFACES-3055 Project: MyFaces Core Issue Type: Bug Affects Versions: 2.0.4, 2.0.3 Environment: Mac OS X, EclipseRT Virgo 2.1.0 Reporter: vvasabi META-INF/faces-config.xml files in the jars of component libraries are loaded twice, causing OpenFaces to give the following error: Second notification for the same phase in the same request occurred. Below is the server log. Note that same config files, 99/1/bundlefile!/META-INF/faces-config.xml and 101/1/bundlefile!/META-INF/faces-config.xml are loaded twice. [2011-02-22 17:00:55.245] start-signalling-1 System.err Feb 22, 2011 5:00:55 PM org.apache.myfaces.config.DefaultFacesConfigurationProvider getClassloaderFacesConfig [2011-02-22 17:00:55.246] start-signalling-1 System.err INFO: Reading config : jar:file:/usr/local/virgo-web-server/work/osgi/configuration/org.eclipse.osgi/bundles/36/data/store/org.eclipse.osgi/bundles/99/1/bundlefile!/META-INF/faces-config.xml [2011-02-22 17:00:55.277] start-signalling-1 System.err Feb 22, 2011 5:00:55 PM org.apache.myfaces.config.DefaultFacesConfigurationProvider getClassloaderFacesConfig [2011-02-22 17:00:55.277] start-signalling-1 System.err INFO: Reading config : jar:file:/usr/local/virgo-web-server/work/osgi/configuration/org.eclipse.osgi/bundles/36/data/store/org.eclipse.osgi/bundles/101/1/bundlefile!/META-INF/faces-config.xml [2011-02-22 17:00:55.290] start-signalling-1 System.err Feb 22, 2011 5:00:55 PM org.apache.myfaces.config.DefaultFacesConfigurationProvider getClassloaderFacesConfig [2011-02-22 17:00:55.291] start-signalling-1 System.err INFO: Reading config : jar:file:/usr/local/virgo-web-server/work/osgi/configuration/org.eclipse.osgi/bundles/36/data/store/org.eclipse.osgi/bundles/99/1/bundlefile!/META-INF/faces-config.xml [2011-02-22 17:00:55.369] start-signalling-1 System.err Feb 22, 2011 5:00:55 PM org.apache.myfaces.config.DefaultFacesConfigurationProvider getClassloaderFacesConfig [2011-02-22 17:00:55.370] start-signalling-1 System.err INFO: Reading config : jar:file:/usr/local/virgo-web-server/work/osgi/configuration/org.eclipse.osgi/bundles/36/data/store/org.eclipse.osgi/bundles/101/1/bundlefile!/META-INF/faces-config.xml However, /WEB-INF/faces-config.xml in the war is only loaded once, so I suspect that this is a bug with org.apache.myfaces.config.DefaultFacesConfigurationProvider. My current workaround to install OpenFaces is, therefore, extract META-INF/faces-config.xml out of the jar, and load it with the war. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MYFACES-3055) META-INF/faces-config.xml files in JARs are loaded twice
[ https://issues.apache.org/jira/browse/MYFACES-3055?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12998066#comment-12998066 ] Mike Kienenberger commented on MYFACES-3055: What container are you using? Jetty? I had problems with Jetty loading META-INF resources in Eclipselink twice as well. META-INF/faces-config.xml files in JARs are loaded twice Key: MYFACES-3055 URL: https://issues.apache.org/jira/browse/MYFACES-3055 Project: MyFaces Core Issue Type: Bug Affects Versions: 2.0.3, 2.0.4 Environment: Mac OS X, EclipseRT Virgo 2.1.0 Reporter: vvasabi META-INF/faces-config.xml files in the jars of component libraries are loaded twice, causing OpenFaces to give the following error: Second notification for the same phase in the same request occurred. Below is the server log. Note that same config files, 99/1/bundlefile!/META-INF/faces-config.xml and 101/1/bundlefile!/META-INF/faces-config.xml are loaded twice. [2011-02-22 17:00:55.245] start-signalling-1 System.err Feb 22, 2011 5:00:55 PM org.apache.myfaces.config.DefaultFacesConfigurationProvider getClassloaderFacesConfig [2011-02-22 17:00:55.246] start-signalling-1 System.err INFO: Reading config : jar:file:/usr/local/virgo-web-server/work/osgi/configuration/org.eclipse.osgi/bundles/36/data/store/org.eclipse.osgi/bundles/99/1/bundlefile!/META-INF/faces-config.xml [2011-02-22 17:00:55.277] start-signalling-1 System.err Feb 22, 2011 5:00:55 PM org.apache.myfaces.config.DefaultFacesConfigurationProvider getClassloaderFacesConfig [2011-02-22 17:00:55.277] start-signalling-1 System.err INFO: Reading config : jar:file:/usr/local/virgo-web-server/work/osgi/configuration/org.eclipse.osgi/bundles/36/data/store/org.eclipse.osgi/bundles/101/1/bundlefile!/META-INF/faces-config.xml [2011-02-22 17:00:55.290] start-signalling-1 System.err Feb 22, 2011 5:00:55 PM org.apache.myfaces.config.DefaultFacesConfigurationProvider getClassloaderFacesConfig [2011-02-22 17:00:55.291] start-signalling-1 System.err INFO: Reading config : jar:file:/usr/local/virgo-web-server/work/osgi/configuration/org.eclipse.osgi/bundles/36/data/store/org.eclipse.osgi/bundles/99/1/bundlefile!/META-INF/faces-config.xml [2011-02-22 17:00:55.369] start-signalling-1 System.err Feb 22, 2011 5:00:55 PM org.apache.myfaces.config.DefaultFacesConfigurationProvider getClassloaderFacesConfig [2011-02-22 17:00:55.370] start-signalling-1 System.err INFO: Reading config : jar:file:/usr/local/virgo-web-server/work/osgi/configuration/org.eclipse.osgi/bundles/36/data/store/org.eclipse.osgi/bundles/101/1/bundlefile!/META-INF/faces-config.xml However, /WEB-INF/faces-config.xml in the war is only loaded once, so I suspect that this is a bug with org.apache.myfaces.config.DefaultFacesConfigurationProvider. My current workaround to install OpenFaces is, therefore, extract META-INF/faces-config.xml out of the jar, and load it with the war. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MYFACES-3055) META-INF/faces-config.xml files in JARs are loaded twice
[ https://issues.apache.org/jira/browse/MYFACES-3055?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12998072#comment-12998072 ] vvasabi commented on MYFACES-3055: -- EclipseRT's Virgo, which appears to be based on Tomcat 6. META-INF/faces-config.xml files in JARs are loaded twice Key: MYFACES-3055 URL: https://issues.apache.org/jira/browse/MYFACES-3055 Project: MyFaces Core Issue Type: Bug Affects Versions: 2.0.3, 2.0.4 Environment: Mac OS X, EclipseRT Virgo 2.1.0 Reporter: vvasabi META-INF/faces-config.xml files in the jars of component libraries are loaded twice, causing OpenFaces to give the following error: Second notification for the same phase in the same request occurred. Below is the server log. Note that same config files, 99/1/bundlefile!/META-INF/faces-config.xml and 101/1/bundlefile!/META-INF/faces-config.xml are loaded twice. [2011-02-22 17:00:55.245] start-signalling-1 System.err Feb 22, 2011 5:00:55 PM org.apache.myfaces.config.DefaultFacesConfigurationProvider getClassloaderFacesConfig [2011-02-22 17:00:55.246] start-signalling-1 System.err INFO: Reading config : jar:file:/usr/local/virgo-web-server/work/osgi/configuration/org.eclipse.osgi/bundles/36/data/store/org.eclipse.osgi/bundles/99/1/bundlefile!/META-INF/faces-config.xml [2011-02-22 17:00:55.277] start-signalling-1 System.err Feb 22, 2011 5:00:55 PM org.apache.myfaces.config.DefaultFacesConfigurationProvider getClassloaderFacesConfig [2011-02-22 17:00:55.277] start-signalling-1 System.err INFO: Reading config : jar:file:/usr/local/virgo-web-server/work/osgi/configuration/org.eclipse.osgi/bundles/36/data/store/org.eclipse.osgi/bundles/101/1/bundlefile!/META-INF/faces-config.xml [2011-02-22 17:00:55.290] start-signalling-1 System.err Feb 22, 2011 5:00:55 PM org.apache.myfaces.config.DefaultFacesConfigurationProvider getClassloaderFacesConfig [2011-02-22 17:00:55.291] start-signalling-1 System.err INFO: Reading config : jar:file:/usr/local/virgo-web-server/work/osgi/configuration/org.eclipse.osgi/bundles/36/data/store/org.eclipse.osgi/bundles/99/1/bundlefile!/META-INF/faces-config.xml [2011-02-22 17:00:55.369] start-signalling-1 System.err Feb 22, 2011 5:00:55 PM org.apache.myfaces.config.DefaultFacesConfigurationProvider getClassloaderFacesConfig [2011-02-22 17:00:55.370] start-signalling-1 System.err INFO: Reading config : jar:file:/usr/local/virgo-web-server/work/osgi/configuration/org.eclipse.osgi/bundles/36/data/store/org.eclipse.osgi/bundles/101/1/bundlefile!/META-INF/faces-config.xml However, /WEB-INF/faces-config.xml in the war is only loaded once, so I suspect that this is a bug with org.apache.myfaces.config.DefaultFacesConfigurationProvider. My current workaround to install OpenFaces is, therefore, extract META-INF/faces-config.xml out of the jar, and load it with the war. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (TRINIDAD-2044) Mismatch between trinidad-config.xsd and documentation
Mismatch between trinidad-config.xsd and documentation -- Key: TRINIDAD-2044 URL: https://issues.apache.org/jira/browse/TRINIDAD-2044 Project: MyFaces Trinidad Issue Type: Bug Components: Components Affects Versions: 2.0.0-beta-2 Reporter: Yee-Wah Lee Priority: Trivial The documentation for configuring trinidad lists the following which isn't in trinidad-config.xsd - two-digit-year-start Conversely, trinidad-config.xsd lists the following which isn't in the documentation - animation-enabled Link for documentation: http://myfaces.apache.org/trinidad/devguide/configuration.html -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MYFACES-3055) META-INF/faces-config.xml files in JARs are loaded twice
[ https://issues.apache.org/jira/browse/MYFACES-3055?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12998089#comment-12998089 ] vvasabi commented on MYFACES-3055: -- Thanks Mike. It does seem to be an issue specific to the Virgo server. I just tested with GlassFish v3, and this problem could not be reproduced. I will try other OSGi environments later and see if I could reproduce the same problem. META-INF/faces-config.xml files in JARs are loaded twice Key: MYFACES-3055 URL: https://issues.apache.org/jira/browse/MYFACES-3055 Project: MyFaces Core Issue Type: Bug Affects Versions: 2.0.3, 2.0.4 Environment: Mac OS X, EclipseRT Virgo 2.1.0 Reporter: vvasabi META-INF/faces-config.xml files in the jars of component libraries are loaded twice, causing OpenFaces to give the following error: Second notification for the same phase in the same request occurred. Below is the server log. Note that same config files, 99/1/bundlefile!/META-INF/faces-config.xml and 101/1/bundlefile!/META-INF/faces-config.xml are loaded twice. [2011-02-22 17:00:55.245] start-signalling-1 System.err Feb 22, 2011 5:00:55 PM org.apache.myfaces.config.DefaultFacesConfigurationProvider getClassloaderFacesConfig [2011-02-22 17:00:55.246] start-signalling-1 System.err INFO: Reading config : jar:file:/usr/local/virgo-web-server/work/osgi/configuration/org.eclipse.osgi/bundles/36/data/store/org.eclipse.osgi/bundles/99/1/bundlefile!/META-INF/faces-config.xml [2011-02-22 17:00:55.277] start-signalling-1 System.err Feb 22, 2011 5:00:55 PM org.apache.myfaces.config.DefaultFacesConfigurationProvider getClassloaderFacesConfig [2011-02-22 17:00:55.277] start-signalling-1 System.err INFO: Reading config : jar:file:/usr/local/virgo-web-server/work/osgi/configuration/org.eclipse.osgi/bundles/36/data/store/org.eclipse.osgi/bundles/101/1/bundlefile!/META-INF/faces-config.xml [2011-02-22 17:00:55.290] start-signalling-1 System.err Feb 22, 2011 5:00:55 PM org.apache.myfaces.config.DefaultFacesConfigurationProvider getClassloaderFacesConfig [2011-02-22 17:00:55.291] start-signalling-1 System.err INFO: Reading config : jar:file:/usr/local/virgo-web-server/work/osgi/configuration/org.eclipse.osgi/bundles/36/data/store/org.eclipse.osgi/bundles/99/1/bundlefile!/META-INF/faces-config.xml [2011-02-22 17:00:55.369] start-signalling-1 System.err Feb 22, 2011 5:00:55 PM org.apache.myfaces.config.DefaultFacesConfigurationProvider getClassloaderFacesConfig [2011-02-22 17:00:55.370] start-signalling-1 System.err INFO: Reading config : jar:file:/usr/local/virgo-web-server/work/osgi/configuration/org.eclipse.osgi/bundles/36/data/store/org.eclipse.osgi/bundles/101/1/bundlefile!/META-INF/faces-config.xml However, /WEB-INF/faces-config.xml in the war is only loaded once, so I suspect that this is a bug with org.apache.myfaces.config.DefaultFacesConfigurationProvider. My current workaround to install OpenFaces is, therefore, extract META-INF/faces-config.xml out of the jar, and load it with the war. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MYFACES-3055) META-INF/faces-config.xml files in JARs are loaded twice
[ https://issues.apache.org/jira/browse/MYFACES-3055?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12998096#comment-12998096 ] Mike Kienenberger commented on MYFACES-3055: In the case of jetty/eclipse, it was a bug in the classloading which would return the same resource twice. I think it was caused by a call to loader.getResources(*), but I don't remember exactly. I wonder if the same method is being called in your situation? For eclipselink, I worked around the problem by ignoring the second duplicate result. META-INF/faces-config.xml files in JARs are loaded twice Key: MYFACES-3055 URL: https://issues.apache.org/jira/browse/MYFACES-3055 Project: MyFaces Core Issue Type: Bug Affects Versions: 2.0.3, 2.0.4 Environment: Mac OS X, EclipseRT Virgo 2.1.0 Reporter: vvasabi META-INF/faces-config.xml files in the jars of component libraries are loaded twice, causing OpenFaces to give the following error: Second notification for the same phase in the same request occurred. Below is the server log. Note that same config files, 99/1/bundlefile!/META-INF/faces-config.xml and 101/1/bundlefile!/META-INF/faces-config.xml are loaded twice. [2011-02-22 17:00:55.245] start-signalling-1 System.err Feb 22, 2011 5:00:55 PM org.apache.myfaces.config.DefaultFacesConfigurationProvider getClassloaderFacesConfig [2011-02-22 17:00:55.246] start-signalling-1 System.err INFO: Reading config : jar:file:/usr/local/virgo-web-server/work/osgi/configuration/org.eclipse.osgi/bundles/36/data/store/org.eclipse.osgi/bundles/99/1/bundlefile!/META-INF/faces-config.xml [2011-02-22 17:00:55.277] start-signalling-1 System.err Feb 22, 2011 5:00:55 PM org.apache.myfaces.config.DefaultFacesConfigurationProvider getClassloaderFacesConfig [2011-02-22 17:00:55.277] start-signalling-1 System.err INFO: Reading config : jar:file:/usr/local/virgo-web-server/work/osgi/configuration/org.eclipse.osgi/bundles/36/data/store/org.eclipse.osgi/bundles/101/1/bundlefile!/META-INF/faces-config.xml [2011-02-22 17:00:55.290] start-signalling-1 System.err Feb 22, 2011 5:00:55 PM org.apache.myfaces.config.DefaultFacesConfigurationProvider getClassloaderFacesConfig [2011-02-22 17:00:55.291] start-signalling-1 System.err INFO: Reading config : jar:file:/usr/local/virgo-web-server/work/osgi/configuration/org.eclipse.osgi/bundles/36/data/store/org.eclipse.osgi/bundles/99/1/bundlefile!/META-INF/faces-config.xml [2011-02-22 17:00:55.369] start-signalling-1 System.err Feb 22, 2011 5:00:55 PM org.apache.myfaces.config.DefaultFacesConfigurationProvider getClassloaderFacesConfig [2011-02-22 17:00:55.370] start-signalling-1 System.err INFO: Reading config : jar:file:/usr/local/virgo-web-server/work/osgi/configuration/org.eclipse.osgi/bundles/36/data/store/org.eclipse.osgi/bundles/101/1/bundlefile!/META-INF/faces-config.xml However, /WEB-INF/faces-config.xml in the war is only loaded once, so I suspect that this is a bug with org.apache.myfaces.config.DefaultFacesConfigurationProvider. My current workaround to install OpenFaces is, therefore, extract META-INF/faces-config.xml out of the jar, and load it with the war. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MYFACES-3055) META-INF/faces-config.xml files in JARs are loaded twice
[ https://issues.apache.org/jira/browse/MYFACES-3055?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12998101#comment-12998101 ] vvasabi commented on MYFACES-3055: -- You are right. I just grabbed the following code from DefaultFacesConfigurationProvider: FacesConfigResourceProvider provider = FacesConfigResourceProviderFactory. getFacesConfigResourceProviderFactory(ectx).createFacesConfigResourceProvider(ectx); CollectionURL facesConfigs = provider.getMetaInfConfigurationResources(ectx); The FacesConfigResourceProvider implementation did not disappointment me and returned duplicate results. I'll see if I could create a simple implementation and pass it in to filter out the duplicate results. Thanks for your tips. META-INF/faces-config.xml files in JARs are loaded twice Key: MYFACES-3055 URL: https://issues.apache.org/jira/browse/MYFACES-3055 Project: MyFaces Core Issue Type: Bug Affects Versions: 2.0.3, 2.0.4 Environment: Mac OS X, EclipseRT Virgo 2.1.0 Reporter: vvasabi META-INF/faces-config.xml files in the jars of component libraries are loaded twice, causing OpenFaces to give the following error: Second notification for the same phase in the same request occurred. Below is the server log. Note that same config files, 99/1/bundlefile!/META-INF/faces-config.xml and 101/1/bundlefile!/META-INF/faces-config.xml are loaded twice. [2011-02-22 17:00:55.245] start-signalling-1 System.err Feb 22, 2011 5:00:55 PM org.apache.myfaces.config.DefaultFacesConfigurationProvider getClassloaderFacesConfig [2011-02-22 17:00:55.246] start-signalling-1 System.err INFO: Reading config : jar:file:/usr/local/virgo-web-server/work/osgi/configuration/org.eclipse.osgi/bundles/36/data/store/org.eclipse.osgi/bundles/99/1/bundlefile!/META-INF/faces-config.xml [2011-02-22 17:00:55.277] start-signalling-1 System.err Feb 22, 2011 5:00:55 PM org.apache.myfaces.config.DefaultFacesConfigurationProvider getClassloaderFacesConfig [2011-02-22 17:00:55.277] start-signalling-1 System.err INFO: Reading config : jar:file:/usr/local/virgo-web-server/work/osgi/configuration/org.eclipse.osgi/bundles/36/data/store/org.eclipse.osgi/bundles/101/1/bundlefile!/META-INF/faces-config.xml [2011-02-22 17:00:55.290] start-signalling-1 System.err Feb 22, 2011 5:00:55 PM org.apache.myfaces.config.DefaultFacesConfigurationProvider getClassloaderFacesConfig [2011-02-22 17:00:55.291] start-signalling-1 System.err INFO: Reading config : jar:file:/usr/local/virgo-web-server/work/osgi/configuration/org.eclipse.osgi/bundles/36/data/store/org.eclipse.osgi/bundles/99/1/bundlefile!/META-INF/faces-config.xml [2011-02-22 17:00:55.369] start-signalling-1 System.err Feb 22, 2011 5:00:55 PM org.apache.myfaces.config.DefaultFacesConfigurationProvider getClassloaderFacesConfig [2011-02-22 17:00:55.370] start-signalling-1 System.err INFO: Reading config : jar:file:/usr/local/virgo-web-server/work/osgi/configuration/org.eclipse.osgi/bundles/36/data/store/org.eclipse.osgi/bundles/101/1/bundlefile!/META-INF/faces-config.xml However, /WEB-INF/faces-config.xml in the war is only loaded once, so I suspect that this is a bug with org.apache.myfaces.config.DefaultFacesConfigurationProvider. My current workaround to install OpenFaces is, therefore, extract META-INF/faces-config.xml out of the jar, and load it with the war. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MYFACES-3055) META-INF/faces-config.xml files in JARs are loaded twice
[
https://issues.apache.org/jira/browse/MYFACES-3055?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12998131#comment-12998131
]
vvasabi commented on MYFACES-3055:
--
Okay, after hacking around for a bit, here's the solution that I have.
Web.xml:
context-param
param-nameorg.apache.myfaces.FACES_INIT_PLUGINS/param-name
param-valuemy.package.MyFacesStartupListener/param-value
/context-param
MyFacesStartupListener:
public class MyFacesStartupListener implements StartupListener {
private static final String FACTORY_KEY =
FacesConfigResourceProviderFactory.class.getName();
@Override
public void postDestroy(ServletContextEvent event) {
}
@Override
public void postInit(ServletContextEvent event) {
}
@Override
public void preDestroy(ServletContextEvent event) {
}
@Override
public void preInit(ServletContextEvent event) {
ServletContext context = event.getServletContext();
context.setAttribute(FACTORY_KEY, new
MyFacesConfigResourceProviderFactory());
}
}
MyFacesConfigResourceProviderFactory:
public class MyFacesConfigResourceProviderFactory
extends FacesConfigResourceProviderFactory {
@Override
public FacesConfigResourceProvider createFacesConfigResourceProvider(
ExternalContext ectx) {
return new MyFacesConfigResourceProvider();
}
}
MyFacesConfigResourceProvider:
public class MyFacesConfigResourceProvider
extends DefaultFacesConfigResourceProvider {
@Override
public CollectionURL getMetaInfConfigurationResources(
ExternalContext ectx) throws IOException {
CollectionURL resources =
super.getMetaInfConfigurationResources(ectx);
CollectionURL filtered = new HashSetURL();
for (URL resource : resources) {
if (!filtered.contains(resource)) {
filtered.add(resource);
}
}
return filtered;
}
}
This workaround may be helpful for people who also have a buggy ClassLoader.
META-INF/faces-config.xml files in JARs are loaded twice
Key: MYFACES-3055
URL: https://issues.apache.org/jira/browse/MYFACES-3055
Project: MyFaces Core
Issue Type: Bug
Affects Versions: 2.0.3, 2.0.4
Environment: Mac OS X, EclipseRT Virgo 2.1.0
Reporter: vvasabi
META-INF/faces-config.xml files in the jars of component libraries are loaded
twice, causing OpenFaces to give the following error:
Second notification for the same phase in the same request occurred.
Below is the server log. Note that same config files,
99/1/bundlefile!/META-INF/faces-config.xml and
101/1/bundlefile!/META-INF/faces-config.xml are loaded twice.
[2011-02-22 17:00:55.245] start-signalling-1 System.err
Feb 22, 2011 5:00:55 PM
org.apache.myfaces.config.DefaultFacesConfigurationProvider
getClassloaderFacesConfig
[2011-02-22 17:00:55.246] start-signalling-1 System.err
INFO: Reading config :
jar:file:/usr/local/virgo-web-server/work/osgi/configuration/org.eclipse.osgi/bundles/36/data/store/org.eclipse.osgi/bundles/99/1/bundlefile!/META-INF/faces-config.xml
[2011-02-22 17:00:55.277] start-signalling-1 System.err
Feb 22, 2011 5:00:55 PM
org.apache.myfaces.config.DefaultFacesConfigurationProvider
getClassloaderFacesConfig
[2011-02-22 17:00:55.277] start-signalling-1 System.err
INFO: Reading config :
jar:file:/usr/local/virgo-web-server/work/osgi/configuration/org.eclipse.osgi/bundles/36/data/store/org.eclipse.osgi/bundles/101/1/bundlefile!/META-INF/faces-config.xml
[2011-02-22 17:00:55.290] start-signalling-1 System.err
Feb 22, 2011 5:00:55 PM
org.apache.myfaces.config.DefaultFacesConfigurationProvider
getClassloaderFacesConfig
[2011-02-22 17:00:55.291] start-signalling-1 System.err
INFO: Reading config :
jar:file:/usr/local/virgo-web-server/work/osgi/configuration/org.eclipse.osgi/bundles/36/data/store/org.eclipse.osgi/bundles/99/1/bundlefile!/META-INF/faces-config.xml
[2011-02-22 17:00:55.369] start-signalling-1 System.err
Feb 22, 2011 5:00:55 PM
org.apache.myfaces.config.DefaultFacesConfigurationProvider
[jira] Commented: (MYFACES-3055) META-INF/faces-config.xml files in JARs are loaded twice
[ https://issues.apache.org/jira/browse/MYFACES-3055?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12998210#comment-12998210 ] Glyn Normington commented on MYFACES-3055: -- Please feel free to raise a bug against Virgo if you can provide a testcase which reproduces the problem behaviour. It would be good to fix any root cause in Virgo or the underlying web container (Gemini Web, based on Tomcat). META-INF/faces-config.xml files in JARs are loaded twice Key: MYFACES-3055 URL: https://issues.apache.org/jira/browse/MYFACES-3055 Project: MyFaces Core Issue Type: Bug Affects Versions: 2.0.3, 2.0.4 Environment: Mac OS X, EclipseRT Virgo 2.1.0 Reporter: vvasabi META-INF/faces-config.xml files in the jars of component libraries are loaded twice, causing OpenFaces to give the following error: Second notification for the same phase in the same request occurred. Below is the server log. Note that same config files, 99/1/bundlefile!/META-INF/faces-config.xml and 101/1/bundlefile!/META-INF/faces-config.xml are loaded twice. [2011-02-22 17:00:55.245] start-signalling-1 System.err Feb 22, 2011 5:00:55 PM org.apache.myfaces.config.DefaultFacesConfigurationProvider getClassloaderFacesConfig [2011-02-22 17:00:55.246] start-signalling-1 System.err INFO: Reading config : jar:file:/usr/local/virgo-web-server/work/osgi/configuration/org.eclipse.osgi/bundles/36/data/store/org.eclipse.osgi/bundles/99/1/bundlefile!/META-INF/faces-config.xml [2011-02-22 17:00:55.277] start-signalling-1 System.err Feb 22, 2011 5:00:55 PM org.apache.myfaces.config.DefaultFacesConfigurationProvider getClassloaderFacesConfig [2011-02-22 17:00:55.277] start-signalling-1 System.err INFO: Reading config : jar:file:/usr/local/virgo-web-server/work/osgi/configuration/org.eclipse.osgi/bundles/36/data/store/org.eclipse.osgi/bundles/101/1/bundlefile!/META-INF/faces-config.xml [2011-02-22 17:00:55.290] start-signalling-1 System.err Feb 22, 2011 5:00:55 PM org.apache.myfaces.config.DefaultFacesConfigurationProvider getClassloaderFacesConfig [2011-02-22 17:00:55.291] start-signalling-1 System.err INFO: Reading config : jar:file:/usr/local/virgo-web-server/work/osgi/configuration/org.eclipse.osgi/bundles/36/data/store/org.eclipse.osgi/bundles/99/1/bundlefile!/META-INF/faces-config.xml [2011-02-22 17:00:55.369] start-signalling-1 System.err Feb 22, 2011 5:00:55 PM org.apache.myfaces.config.DefaultFacesConfigurationProvider getClassloaderFacesConfig [2011-02-22 17:00:55.370] start-signalling-1 System.err INFO: Reading config : jar:file:/usr/local/virgo-web-server/work/osgi/configuration/org.eclipse.osgi/bundles/36/data/store/org.eclipse.osgi/bundles/101/1/bundlefile!/META-INF/faces-config.xml However, /WEB-INF/faces-config.xml in the war is only loaded once, so I suspect that this is a bug with org.apache.myfaces.config.DefaultFacesConfigurationProvider. My current workaround to install OpenFaces is, therefore, extract META-INF/faces-config.xml out of the jar, and load it with the war. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
