Re: [Trinidad] RC1 for 1.2.14 with the new skin?
+1 regards, Catalin On Tue, Feb 23, 2010 at 9:46 PM, Mathias Walter mathias.wal...@gmx.netwrote: +1 I didn't find time to test the new skin with other projects too. I'll do this at the end of March. -- Mathias Walter 2010/2/23 Matthias Wessendorf mat...@apache.org: Hi, should we generate a RC1 for the 1.2.14 release, to have the new skin hitting the road ? I am all for it ;-) -Matthias -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -- Codebeat www.codebeat.ro
[ExtVal] ExtVal-metadata-provider addon (performance) improvement
Hi all,
With the Extval metadata provider addon, the developer has the possibility
to specify the packages that needs to be scanned for the @MetaDataProvider.
However, doing this, results in some performance penalty.
During initialization of the MetaDataProviderStorage class, it stores the
information in the property customMetaDataProviderStorage. This property is
not consulted (not immediately) when a metadata provider class is requested
from the storage. And the scanning is performed again in the method
getMetaDataProviderClassFor and now kept in metaDataProviderStorage
property.
As a side effect of keeping 2 properties, the result of the method is a list
that contains twice the metadata provider class. The doubles are handled
correctly in the
MetaDataProviderScanningInterceptor.createAdditionalMetaDataEntries and thus
only processed once (but instantiated twice)
The advanced metadata addon has the same 'defect'.
Possible solutions
1) keep the 2 properties (customMetaDataProviderStorage and
metaDataProviderStorage) but add following code just before the try in the
getMetaDataProviderClassFor method
*if(this.customMetaDataProviderStorage.containsKey(sourceClass))
{
return this.customMetaDataProviderStorage.get(sourceClass);
}*
although rewrite is a better option.
2) remove the 'double' storage property (remove the
customMetaDataProviderStorage) and the getMetaDataProviderClassFor method
could look like this:
* public ListClass getMetaDataProviderClassFor(Class sourceClass)
{
if(this.metaDataProviderStorage.containsKey(sourceClass))
{
return this.metaDataProviderStorage.get(sourceClass);
}
try
{
for(Class foundProvider :
processTarget(sourceClass.getPackage().getName()))
{
addMetaDataProvider(sourceClass, foundProvider,
this.metaDataProviderStorage);
}
}
catch(Throwable t)
{
if(this.logger.isWarnEnabled())
{
this.logger.warn(unable to setup annotation based metadata
provider for + sourceClass.getName(), t);
}
this.metaDataProviderStorage.put(sourceClass, null);
}
return this.metaDataProviderStorage.get(sourceClass);
}*
and use the metaDataProviderStorage in the constructor instead of the
removed property.
regards
Rudy
Re: [ExtVal] ExtVal-metadata-provider addon (performance) improvement
hi rudy,
thx for providing the improvement.
i'll have a look at it after the jsfdays.
regards,
gerhard
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
2010/2/24 Rudy De Busscher rdebussc...@gmail.com
Hi all,
With the Extval metadata provider addon, the developer has the possibility
to specify the packages that needs to be scanned for the @MetaDataProvider.
However, doing this, results in some performance penalty.
During initialization of the MetaDataProviderStorage class, it stores the
information in the property customMetaDataProviderStorage. This property is
not consulted (not immediately) when a metadata provider class is requested
from the storage. And the scanning is performed again in the method
getMetaDataProviderClassFor and now kept in metaDataProviderStorage
property.
As a side effect of keeping 2 properties, the result of the method is a
list that contains twice the metadata provider class. The doubles are
handled correctly in the
MetaDataProviderScanningInterceptor.createAdditionalMetaDataEntries and thus
only processed once (but instantiated twice)
The advanced metadata addon has the same 'defect'.
Possible solutions
1) keep the 2 properties (customMetaDataProviderStorage and
metaDataProviderStorage) but add following code just before the try in the
getMetaDataProviderClassFor method
*if(this.customMetaDataProviderStorage.containsKey(sourceClass))
{
return this.customMetaDataProviderStorage.get(sourceClass);
}*
although rewrite is a better option.
2) remove the 'double' storage property (remove the
customMetaDataProviderStorage) and the getMetaDataProviderClassFor method
could look like this:
* public ListClass getMetaDataProviderClassFor(Class sourceClass)
{
if(this.metaDataProviderStorage.containsKey(sourceClass))
{
return this.metaDataProviderStorage.get(sourceClass);
}
try
{
for(Class foundProvider :
processTarget(sourceClass.getPackage().getName()))
{
addMetaDataProvider(sourceClass, foundProvider,
this.metaDataProviderStorage);
}
}
catch(Throwable t)
{
if(this.logger.isWarnEnabled())
{
this.logger.warn(unable to setup annotation based metadata
provider for + sourceClass.getName(), t);
}
this.metaDataProviderStorage.put(sourceClass, null);
}
return this.metaDataProviderStorage.get(sourceClass);
}*
and use the metaDataProviderStorage in the constructor instead of the
removed property.
regards
Rudy
[jira] Created: (MYFACES-2573) NavigationHandler decoration/delegation not supported in 2.0.0-beta2
NavigationHandler decoration/delegation not supported in 2.0.0-beta2 Key: MYFACES-2573 URL: https://issues.apache.org/jira/browse/MYFACES-2573 Project: MyFaces Core Issue Type: Bug Components: General Affects Versions: 2.0.0-beta-2 Environment: PrettyFaces 2.0.4, Jetty Reporter: Lincoln Baxter III Priority: Blocker http://code.google.com/p/prettyfaces/issues/detail?id=28 Section 11.4.6 of the JSF spec states that when delegating NavigationHandler, it should accept (as a constructor parameter) the parent NavigationHandler to be decorated. This is no longer working in MyFaces 2.0.0-x. SEVERE: com.ocpsoft.pretty.faces.application.PrettyNavigationHandler java.lang.InstantiationException: com.ocpsoft.pretty.faces.application.PrettyNavigationHandler at java.lang.Class.newInstance0(Class.java:340) at java.lang.Class.newInstance(Class.java:308) at org.apache.myfaces.shared_impl.util.ClassUtils.newInstance(ClassUtils.java:343) at org.apache.myfaces.config.FacesConfigurator.getApplicationObject(FacesConfigurator.java:2094) at org.apache.myfaces.config.FacesConfigurator.configureApplication(FacesConfigurator.java:1871) at org.apache.myfaces.config.FacesConfigurator.configure(FacesConfigurator.java:515) at org.apache.myfaces.webapp.AbstractFacesInitializer.buildConfiguration(AbstractFacesInitializer.java:203) at org.apache.myfaces.webapp.Jsp21FacesInitializer.initContainerIntegration(Jsp21FacesInitializer.java:73) at org.apache.myfaces.webapp.AbstractFacesInitializer.initFaces(AbstractFacesInitializer.java:99) at org.apache.myfaces.webapp.StartupServletContextListener.contextInitialized(StartupServletContextListener.java:155) at org.eclipse.jetty.server.handler.ContextHandler.startContext(ContextHandler.java:645) at org.eclipse.jetty.servlet.ServletContextHandler.startContext(ServletContextHandler.java:189) at org.eclipse.jetty.webapp.WebAppContext.startContext(WebAppContext.java:978) at org.eclipse.jetty.server.handler.ContextHandler.doStart(ContextHandler.java:586) at org.eclipse.jetty.webapp.WebAppContext.doStart(WebAppContext.java:349) at org.mortbay.jetty.plugin.JettyWebAppContext.doStart(JettyWebAppContext.java:102) at org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:55) at org.eclipse.jetty.server.handler.HandlerCollection.doStart(HandlerCollection.java:165) at org.eclipse.jetty.server.handler.ContextHandlerCollection.doStart(ContextHandlerCollection.java:162) at org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:55) at org.eclipse.jetty.server.handler.HandlerCollection.doStart(HandlerCollection.java:165) at org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:55) at org.eclipse.jetty.server.handler.HandlerWrapper.doStart(HandlerWrapper.java:92) at org.eclipse.jetty.server.Server.doStart(Server.java:228) at org.mortbay.jetty.plugin.JettyServer.doStart(JettyServer.java:69) at org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:55) at org.mortbay.jetty.plugin.AbstractJettyMojo.startJetty(AbstractJettyMojo.java:433) at org.mortbay.jetty.plugin.AbstractJettyMojo.execute(AbstractJettyMojo.java:377) at org.mortbay.jetty.plugin.JettyRunWarMojo.execute(JettyRunWarMojo.java:68) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:490) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:694) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:569) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:539) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:387) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:348) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:180) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:328) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:138) at org.apache.maven.cli.MavenCli.main(MavenCli.java:362) at org.apache.maven.cli.compat.CompatibleMain.main(CompatibleMain.java:60) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) at
[jira] Created: (MYFACES-2574) InterfaceHandler stores the componentType as the resolved value instead of the ValueExpression
InterfaceHandler stores the componentType as the resolved value instead of the ValueExpression -- Key: MYFACES-2574 URL: https://issues.apache.org/jira/browse/MYFACES-2574 Project: MyFaces Core Issue Type: Bug Components: JSR-314 Affects Versions: 2.0.0-beta-3 Reporter: Jakob Korherr Assignee: Jakob Korherr Priority: Minor This causes a ClassCastException in ApplicationImpl, because there the code wants to cast to a ValueExpression, but the value in the attribute map is of type String. So we have to put the ValueExpression instead of the resolved value in the attribute map in InterfaceHandler. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (MYFACES-2574) InterfaceHandler stores the componentType as the resolved value instead of the ValueExpression
[ https://issues.apache.org/jira/browse/MYFACES-2574?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jakob Korherr resolved MYFACES-2574. Resolution: Fixed Fix Version/s: 2.0.0-beta-3 InterfaceHandler stores the componentType as the resolved value instead of the ValueExpression -- Key: MYFACES-2574 URL: https://issues.apache.org/jira/browse/MYFACES-2574 Project: MyFaces Core Issue Type: Bug Components: JSR-314 Affects Versions: 2.0.0-beta-3 Reporter: Jakob Korherr Assignee: Jakob Korherr Priority: Minor Fix For: 2.0.0-beta-3 This causes a ClassCastException in ApplicationImpl, because there the code wants to cast to a ValueExpression, but the value in the attribute map is of type String. So we have to put the ValueExpression instead of the resolved value in the attribute map in InterfaceHandler. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (TRINIDAD-1737) LocaleSymbols* at LocaleElements*.js files are empty in 1.0.12 release
LocaleSymbols* at LocaleElements*.js files are empty in 1.0.12 release
--
Key: TRINIDAD-1737
URL: https://issues.apache.org/jira/browse/TRINIDAD-1737
Project: MyFaces Trinidad
Issue Type: Bug
Affects Versions: 1.0.12-core
Reporter: Rafael Pérez
Priority: Critical
Locale*.js files are not getting filled properly for any locale. For example,
the file at
http://localhost:8080/trinidad-demo/adf/jsLibs/resources/LocaleElements_en1_0_11.js?loc=en
Looks in 1.0.12 as:
var LocaleSymbols_en = new LocaleSymbols({
});
TrMessageFactory._TRANSLATIONS={
'org.apache.myfaces.trinidad.validator.DoubleRangeValidator.NOT_IN_RANGE_detail':'The
number must be between {2} and {3}.',
...
}
And it should be (as in 1.0.11):
var LocaleSymbols_en = new LocaleSymbols({
MonthNames:[January, February, March, April, May, June, July,
August, September, October, November, December, ],
MonthAbbreviations:[Jan, Feb, Mar, Apr, May, Jun, Jul, Aug,
Sep, Oct, Nov, Dec, ],
DayNames:[Sunday, Monday, Tuesday, Wednesday, Thursday, Friday,
Saturday],
DayAbbreviations:[Sun, Mon, Tue, Wed, Thu, Fri, Sat],
AmPmMarkers:[AM, PM],
Eras:[BC, AD],
DateTimePatterns:[h:mm:ss a z, h:mm:ss a z, h:mm:ss a, h:mm a, ,
d, , d, , MMM d, , M/d/yy, {1} {0}],
DateTimeElements:[1, 1],
NumberElements:[., ,, ;, %, 0, #, -, E, \u2030, \u221e,
\ufffd],
CurrencyElements:[\xa4, XXX, \xa4, , -\xa4, ]
});
TrMessageFactory._TRANSLATIONS={
'org.apache.myfaces.trinidad.validator.DoubleRangeValidator.NOT_IN_RANGE_detail':'The
number must be between {2} and {3}.',
...
}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (MYFACES-2575) Replace RequestMap with FacesContext.getAttributes() where possible
Replace RequestMap with FacesContext.getAttributes() where possible --- Key: MYFACES-2575 URL: https://issues.apache.org/jira/browse/MYFACES-2575 Project: MyFaces Core Issue Type: Improvement Components: JSR-314 Affects Versions: 2.0.0-beta-2 Reporter: Udo Schnurpfeil Assignee: Bernd Bohmann Priority: Minor -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (MYFACES-2508) Miscellaneous CTS fixes
[ https://issues.apache.org/jira/browse/MYFACES-2508?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12837760#action_12837760 ] Curtiss Howard commented on MYFACES-2508: - Fixed CTS testcase jsf/spec/jstl/foreachtag/URLClient_jstlCoreForEachTagTest: IterationStatus was missing required properties. Miscellaneous CTS fixes --- Key: MYFACES-2508 URL: https://issues.apache.org/jira/browse/MYFACES-2508 Project: MyFaces Core Issue Type: Bug Components: JSR-314 Affects Versions: 2.0.0-beta-2 Reporter: Curtiss Howard This issue will be used to fix problems identified by CTS testing. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (MYFACES-2573) NavigationHandler decoration/delegation not supported in 2.0.0-beta2
[ https://issues.apache.org/jira/browse/MYFACES-2573?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12837775#action_12837775 ] Jakob Korherr commented on MYFACES-2573: Are you using some kind of ording in your faces-config files? Because if the faces-config file, which adds your NavigationHandler is the first one that gets loaded (also before the myfaces' standard-faces-config.xml) you will surely run into this problem, because there is no NavigationHandler implementation installed yet which could be wrapped. Otherwise it does work - I just tried it! NavigationHandler decoration/delegation not supported in 2.0.0-beta2 Key: MYFACES-2573 URL: https://issues.apache.org/jira/browse/MYFACES-2573 Project: MyFaces Core Issue Type: Bug Components: JSR-314 Affects Versions: 2.0.0-beta-2 Environment: PrettyFaces 2.0.4, Jetty Reporter: Lincoln Baxter III Priority: Blocker http://code.google.com/p/prettyfaces/issues/detail?id=28 Section 11.4.6 of the JSF spec states that when delegating NavigationHandler, it should accept (as a constructor parameter) the parent NavigationHandler to be decorated. This is no longer working in MyFaces 2.0.0-x. SEVERE: com.ocpsoft.pretty.faces.application.PrettyNavigationHandler java.lang.InstantiationException: com.ocpsoft.pretty.faces.application.PrettyNavigationHandler at java.lang.Class.newInstance0(Class.java:340) at java.lang.Class.newInstance(Class.java:308) at org.apache.myfaces.shared_impl.util.ClassUtils.newInstance(ClassUtils.java:343) at org.apache.myfaces.config.FacesConfigurator.getApplicationObject(FacesConfigurator.java:2094) at org.apache.myfaces.config.FacesConfigurator.configureApplication(FacesConfigurator.java:1871) at org.apache.myfaces.config.FacesConfigurator.configure(FacesConfigurator.java:515) at org.apache.myfaces.webapp.AbstractFacesInitializer.buildConfiguration(AbstractFacesInitializer.java:203) at org.apache.myfaces.webapp.Jsp21FacesInitializer.initContainerIntegration(Jsp21FacesInitializer.java:73) at org.apache.myfaces.webapp.AbstractFacesInitializer.initFaces(AbstractFacesInitializer.java:99) at org.apache.myfaces.webapp.StartupServletContextListener.contextInitialized(StartupServletContextListener.java:155) at org.eclipse.jetty.server.handler.ContextHandler.startContext(ContextHandler.java:645) at org.eclipse.jetty.servlet.ServletContextHandler.startContext(ServletContextHandler.java:189) at org.eclipse.jetty.webapp.WebAppContext.startContext(WebAppContext.java:978) at org.eclipse.jetty.server.handler.ContextHandler.doStart(ContextHandler.java:586) at org.eclipse.jetty.webapp.WebAppContext.doStart(WebAppContext.java:349) at org.mortbay.jetty.plugin.JettyWebAppContext.doStart(JettyWebAppContext.java:102) at org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:55) at org.eclipse.jetty.server.handler.HandlerCollection.doStart(HandlerCollection.java:165) at org.eclipse.jetty.server.handler.ContextHandlerCollection.doStart(ContextHandlerCollection.java:162) at org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:55) at org.eclipse.jetty.server.handler.HandlerCollection.doStart(HandlerCollection.java:165) at org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:55) at org.eclipse.jetty.server.handler.HandlerWrapper.doStart(HandlerWrapper.java:92) at org.eclipse.jetty.server.Server.doStart(Server.java:228) at org.mortbay.jetty.plugin.JettyServer.doStart(JettyServer.java:69) at org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:55) at org.mortbay.jetty.plugin.AbstractJettyMojo.startJetty(AbstractJettyMojo.java:433) at org.mortbay.jetty.plugin.AbstractJettyMojo.execute(AbstractJettyMojo.java:377) at org.mortbay.jetty.plugin.JettyRunWarMojo.execute(JettyRunWarMojo.java:68) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:490) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:694) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:569) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:539) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:387) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:348) at
[Facelets] deploying old Facelets templates with MyFaces 2
Again... MYFACES-2543 *snip* If the answer to this question is no, Facelets in JSF 2.0 is backwards compatible with pre-JSF 2.0 Facelets and such an application must not continue to bundle the Facelets jar file along with the application, and must not continue to set the Facelets configuration parameters. *snip* So, this is actually blocking a reasonable use-case. Please keep the bug open ;-) -Matthias -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf
[jira] Created: (MYFACES-2576) Race condition in _ExternalSpecifications methods
Race condition in _ExternalSpecifications methods - Key: MYFACES-2576 URL: https://issues.apache.org/jira/browse/MYFACES-2576 Project: MyFaces Core Issue Type: Bug Components: JSR-314 Affects Versions: 2.0.0-beta-2 Environment: * Reporter: Jan-Kees van Andel The static final fields in the _ExternalSpecifications have recently been refactored into methods. But unfortunately, this has broken thread safety, possibly leading to strange errors (like NPE). I think the only solution with the current implementation is to make the methods synchronized. Volatile is not enough AFAICS... -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (EXTSCRIPT-73) Facelets resource handler does not trigger anymore
Facelets resource handler does not trigger anymore -- Key: EXTSCRIPT-73 URL: https://issues.apache.org/jira/browse/EXTSCRIPT-73 Project: MyFaces Extensions Scripting Issue Type: Bug Reporter: Werner Punz Assignee: Werner Punz The faclets resource handler does not trigger anymore, maybe there was a namechange in the myfaces codebase regarding the facelets extension point -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (MYFACES-2573) NavigationHandler decoration/delegation not supported in 2.0.0-beta2
[ https://issues.apache.org/jira/browse/MYFACES-2573?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12837802#action_12837802 ] Lincoln Baxter III commented on MYFACES-2573: - No, there is no special ordering. I've also just verified this again personally on Tomcat 6. This functions just fine when using Mojarra. PrettyFaces bundles its own faces-config.xml file, however: ?xml version=1.0 encoding=UTF-8? faces-config xmlns=http://java.sun.com/xml/ns/javaee; xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; xsi:schemaLocation=http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-facesconfig_2_0.xsd; version=2.0 nameocpsoft_pretty_faces/name application view-handlercom.ocpsoft.pretty.faces.application.PrettyViewHandler/view-handler navigation-handlercom.ocpsoft.pretty.faces.application.PrettyNavigationHandler/navigation-handler /application lifecycle phase-listenercom.ocpsoft.pretty.faces.event.PrettyPhaseListener/phase-listener /lifecycle component component-type com.ocpsoft.pretty.Link /component-type component-class com.ocpsoft.pretty.faces.component.Link /component-class /component component component-type com.ocpsoft.pretty.UrlBuffer /component-type component-class com.ocpsoft.pretty.faces.component.UrlBuffer /component-class /component render-kit renderer description Renderer for the pretty link component. /description component-family PRETTY_FACES_FAMILY /component-family renderer-type javax.faces.Link /renderer-type renderer-class com.ocpsoft.pretty.faces.component.renderer.LinkRenderer /renderer-class /renderer renderer description Renderer for the pretty urlbuffer component. /description component-family PRETTY_FACES_FAMILY /component-family renderer-type com.ocpsoft.pretty.UrlBuffer /renderer-type renderer-class com.ocpsoft.pretty.faces.component.renderer.UrlBufferRenderer /renderer-class /renderer /render-kit /faces-config NavigationHandler decoration/delegation not supported in 2.0.0-beta2 Key: MYFACES-2573 URL: https://issues.apache.org/jira/browse/MYFACES-2573 Project: MyFaces Core Issue Type: Bug Components: JSR-314 Affects Versions: 2.0.0-beta-2 Environment: PrettyFaces 2.0.4, Jetty Reporter: Lincoln Baxter III Priority: Blocker http://code.google.com/p/prettyfaces/issues/detail?id=28 Section 11.4.6 of the JSF spec states that when delegating NavigationHandler, it should accept (as a constructor parameter) the parent NavigationHandler to be decorated. This is no longer working in MyFaces 2.0.0-x. SEVERE: com.ocpsoft.pretty.faces.application.PrettyNavigationHandler java.lang.InstantiationException: com.ocpsoft.pretty.faces.application.PrettyNavigationHandler at java.lang.Class.newInstance0(Class.java:340) at java.lang.Class.newInstance(Class.java:308) at org.apache.myfaces.shared_impl.util.ClassUtils.newInstance(ClassUtils.java:343) at org.apache.myfaces.config.FacesConfigurator.getApplicationObject(FacesConfigurator.java:2094) at org.apache.myfaces.config.FacesConfigurator.configureApplication(FacesConfigurator.java:1871) at org.apache.myfaces.config.FacesConfigurator.configure(FacesConfigurator.java:515) at org.apache.myfaces.webapp.AbstractFacesInitializer.buildConfiguration(AbstractFacesInitializer.java:203) at org.apache.myfaces.webapp.Jsp21FacesInitializer.initContainerIntegration(Jsp21FacesInitializer.java:73) at org.apache.myfaces.webapp.AbstractFacesInitializer.initFaces(AbstractFacesInitializer.java:99) at org.apache.myfaces.webapp.StartupServletContextListener.contextInitialized(StartupServletContextListener.java:155) at org.eclipse.jetty.server.handler.ContextHandler.startContext(ContextHandler.java:645) at org.eclipse.jetty.servlet.ServletContextHandler.startContext(ServletContextHandler.java:189) at
[jira] Commented: (MYFACES-2576) Race condition in _ExternalSpecifications methods
[ https://issues.apache.org/jira/browse/MYFACES-2576?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12837807#action_12837807 ] Jakob Korherr commented on MYFACES-2576: How would you be able to get a NullPointerException with the current state of _ExternalSpecifications? From my point of view the only thing which could happen is that the properties get configured more than once, which should not be a problem! Race condition in _ExternalSpecifications methods - Key: MYFACES-2576 URL: https://issues.apache.org/jira/browse/MYFACES-2576 Project: MyFaces Core Issue Type: Bug Components: JSR-314 Affects Versions: 2.0.0-beta-2 Environment: * Reporter: Jan-Kees van Andel The static final fields in the _ExternalSpecifications have recently been refactored into methods. But unfortunately, this has broken thread safety, possibly leading to strange errors (like NPE). I think the only solution with the current implementation is to make the methods synchronized. Volatile is not enough AFAICS... -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (MYFACES-2573) NavigationHandler decoration/delegation not supported in 2.0.0-beta2
[ https://issues.apache.org/jira/browse/MYFACES-2573?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12837810#action_12837810 ] Lincoln Baxter III commented on MYFACES-2573: - Have you tested decoration for ConfigurableNavigationHandler s? MyFaces is looking for a constructor with navhandler type NavigationHandler, but all NavigationHandlers in JSF2 are required to extend ConfigurableNavigationHandler. Decorating with NavigationHandler in the constructor is fine, but with ConfigurableNavigationHandler we get the exception. NavigationHandler decoration/delegation not supported in 2.0.0-beta2 Key: MYFACES-2573 URL: https://issues.apache.org/jira/browse/MYFACES-2573 Project: MyFaces Core Issue Type: Bug Components: JSR-314 Affects Versions: 2.0.0-beta-2 Environment: PrettyFaces 2.0.4, Jetty Reporter: Lincoln Baxter III Priority: Blocker http://code.google.com/p/prettyfaces/issues/detail?id=28 Section 11.4.6 of the JSF spec states that when delegating NavigationHandler, it should accept (as a constructor parameter) the parent NavigationHandler to be decorated. This is no longer working in MyFaces 2.0.0-x. SEVERE: com.ocpsoft.pretty.faces.application.PrettyNavigationHandler java.lang.InstantiationException: com.ocpsoft.pretty.faces.application.PrettyNavigationHandler at java.lang.Class.newInstance0(Class.java:340) at java.lang.Class.newInstance(Class.java:308) at org.apache.myfaces.shared_impl.util.ClassUtils.newInstance(ClassUtils.java:343) at org.apache.myfaces.config.FacesConfigurator.getApplicationObject(FacesConfigurator.java:2094) at org.apache.myfaces.config.FacesConfigurator.configureApplication(FacesConfigurator.java:1871) at org.apache.myfaces.config.FacesConfigurator.configure(FacesConfigurator.java:515) at org.apache.myfaces.webapp.AbstractFacesInitializer.buildConfiguration(AbstractFacesInitializer.java:203) at org.apache.myfaces.webapp.Jsp21FacesInitializer.initContainerIntegration(Jsp21FacesInitializer.java:73) at org.apache.myfaces.webapp.AbstractFacesInitializer.initFaces(AbstractFacesInitializer.java:99) at org.apache.myfaces.webapp.StartupServletContextListener.contextInitialized(StartupServletContextListener.java:155) at org.eclipse.jetty.server.handler.ContextHandler.startContext(ContextHandler.java:645) at org.eclipse.jetty.servlet.ServletContextHandler.startContext(ServletContextHandler.java:189) at org.eclipse.jetty.webapp.WebAppContext.startContext(WebAppContext.java:978) at org.eclipse.jetty.server.handler.ContextHandler.doStart(ContextHandler.java:586) at org.eclipse.jetty.webapp.WebAppContext.doStart(WebAppContext.java:349) at org.mortbay.jetty.plugin.JettyWebAppContext.doStart(JettyWebAppContext.java:102) at org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:55) at org.eclipse.jetty.server.handler.HandlerCollection.doStart(HandlerCollection.java:165) at org.eclipse.jetty.server.handler.ContextHandlerCollection.doStart(ContextHandlerCollection.java:162) at org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:55) at org.eclipse.jetty.server.handler.HandlerCollection.doStart(HandlerCollection.java:165) at org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:55) at org.eclipse.jetty.server.handler.HandlerWrapper.doStart(HandlerWrapper.java:92) at org.eclipse.jetty.server.Server.doStart(Server.java:228) at org.mortbay.jetty.plugin.JettyServer.doStart(JettyServer.java:69) at org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:55) at org.mortbay.jetty.plugin.AbstractJettyMojo.startJetty(AbstractJettyMojo.java:433) at org.mortbay.jetty.plugin.AbstractJettyMojo.execute(AbstractJettyMojo.java:377) at org.mortbay.jetty.plugin.JettyRunWarMojo.execute(JettyRunWarMojo.java:68) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:490) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:694) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:569) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:539) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:387) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:348) at
[jira] Commented: (MYFACES-2573) NavigationHandler decoration/delegation not supported in 2.0.0-beta2
[ https://issues.apache.org/jira/browse/MYFACES-2573?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12837819#action_12837819 ] Jakob Korherr commented on MYFACES-2573: Right, so know I see what the real problem is: MyFaces' NavigationHandlerImpl does not implement javax.faces.application.ConfigurableNavigationHandler at the moment. Thanks for pointing out this bug! NavigationHandler decoration/delegation not supported in 2.0.0-beta2 Key: MYFACES-2573 URL: https://issues.apache.org/jira/browse/MYFACES-2573 Project: MyFaces Core Issue Type: Bug Components: JSR-314 Affects Versions: 2.0.0-beta-2 Environment: PrettyFaces 2.0.4, Jetty Reporter: Lincoln Baxter III Priority: Blocker http://code.google.com/p/prettyfaces/issues/detail?id=28 Section 11.4.6 of the JSF spec states that when delegating NavigationHandler, it should accept (as a constructor parameter) the parent NavigationHandler to be decorated. This is no longer working in MyFaces 2.0.0-x. SEVERE: com.ocpsoft.pretty.faces.application.PrettyNavigationHandler java.lang.InstantiationException: com.ocpsoft.pretty.faces.application.PrettyNavigationHandler at java.lang.Class.newInstance0(Class.java:340) at java.lang.Class.newInstance(Class.java:308) at org.apache.myfaces.shared_impl.util.ClassUtils.newInstance(ClassUtils.java:343) at org.apache.myfaces.config.FacesConfigurator.getApplicationObject(FacesConfigurator.java:2094) at org.apache.myfaces.config.FacesConfigurator.configureApplication(FacesConfigurator.java:1871) at org.apache.myfaces.config.FacesConfigurator.configure(FacesConfigurator.java:515) at org.apache.myfaces.webapp.AbstractFacesInitializer.buildConfiguration(AbstractFacesInitializer.java:203) at org.apache.myfaces.webapp.Jsp21FacesInitializer.initContainerIntegration(Jsp21FacesInitializer.java:73) at org.apache.myfaces.webapp.AbstractFacesInitializer.initFaces(AbstractFacesInitializer.java:99) at org.apache.myfaces.webapp.StartupServletContextListener.contextInitialized(StartupServletContextListener.java:155) at org.eclipse.jetty.server.handler.ContextHandler.startContext(ContextHandler.java:645) at org.eclipse.jetty.servlet.ServletContextHandler.startContext(ServletContextHandler.java:189) at org.eclipse.jetty.webapp.WebAppContext.startContext(WebAppContext.java:978) at org.eclipse.jetty.server.handler.ContextHandler.doStart(ContextHandler.java:586) at org.eclipse.jetty.webapp.WebAppContext.doStart(WebAppContext.java:349) at org.mortbay.jetty.plugin.JettyWebAppContext.doStart(JettyWebAppContext.java:102) at org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:55) at org.eclipse.jetty.server.handler.HandlerCollection.doStart(HandlerCollection.java:165) at org.eclipse.jetty.server.handler.ContextHandlerCollection.doStart(ContextHandlerCollection.java:162) at org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:55) at org.eclipse.jetty.server.handler.HandlerCollection.doStart(HandlerCollection.java:165) at org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:55) at org.eclipse.jetty.server.handler.HandlerWrapper.doStart(HandlerWrapper.java:92) at org.eclipse.jetty.server.Server.doStart(Server.java:228) at org.mortbay.jetty.plugin.JettyServer.doStart(JettyServer.java:69) at org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:55) at org.mortbay.jetty.plugin.AbstractJettyMojo.startJetty(AbstractJettyMojo.java:433) at org.mortbay.jetty.plugin.AbstractJettyMojo.execute(AbstractJettyMojo.java:377) at org.mortbay.jetty.plugin.JettyRunWarMojo.execute(JettyRunWarMojo.java:68) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:490) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:694) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:569) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:539) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:387) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:348) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:180) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:328) at
[jira] Commented: (MYFACES-2573) NavigationHandler decoration/delegation not supported in 2.0.0-beta2
[ https://issues.apache.org/jira/browse/MYFACES-2573?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12837824#action_12837824 ] Jakob Korherr commented on MYFACES-2573: Oh, actually it does. So the problem is on the instantiation code. Anyhow, I'll fix it! NavigationHandler decoration/delegation not supported in 2.0.0-beta2 Key: MYFACES-2573 URL: https://issues.apache.org/jira/browse/MYFACES-2573 Project: MyFaces Core Issue Type: Bug Components: JSR-314 Affects Versions: 2.0.0-beta-2 Environment: PrettyFaces 2.0.4, Jetty Reporter: Lincoln Baxter III Assignee: Jakob Korherr Priority: Blocker http://code.google.com/p/prettyfaces/issues/detail?id=28 Section 11.4.6 of the JSF spec states that when delegating NavigationHandler, it should accept (as a constructor parameter) the parent NavigationHandler to be decorated. This is no longer working in MyFaces 2.0.0-x. SEVERE: com.ocpsoft.pretty.faces.application.PrettyNavigationHandler java.lang.InstantiationException: com.ocpsoft.pretty.faces.application.PrettyNavigationHandler at java.lang.Class.newInstance0(Class.java:340) at java.lang.Class.newInstance(Class.java:308) at org.apache.myfaces.shared_impl.util.ClassUtils.newInstance(ClassUtils.java:343) at org.apache.myfaces.config.FacesConfigurator.getApplicationObject(FacesConfigurator.java:2094) at org.apache.myfaces.config.FacesConfigurator.configureApplication(FacesConfigurator.java:1871) at org.apache.myfaces.config.FacesConfigurator.configure(FacesConfigurator.java:515) at org.apache.myfaces.webapp.AbstractFacesInitializer.buildConfiguration(AbstractFacesInitializer.java:203) at org.apache.myfaces.webapp.Jsp21FacesInitializer.initContainerIntegration(Jsp21FacesInitializer.java:73) at org.apache.myfaces.webapp.AbstractFacesInitializer.initFaces(AbstractFacesInitializer.java:99) at org.apache.myfaces.webapp.StartupServletContextListener.contextInitialized(StartupServletContextListener.java:155) at org.eclipse.jetty.server.handler.ContextHandler.startContext(ContextHandler.java:645) at org.eclipse.jetty.servlet.ServletContextHandler.startContext(ServletContextHandler.java:189) at org.eclipse.jetty.webapp.WebAppContext.startContext(WebAppContext.java:978) at org.eclipse.jetty.server.handler.ContextHandler.doStart(ContextHandler.java:586) at org.eclipse.jetty.webapp.WebAppContext.doStart(WebAppContext.java:349) at org.mortbay.jetty.plugin.JettyWebAppContext.doStart(JettyWebAppContext.java:102) at org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:55) at org.eclipse.jetty.server.handler.HandlerCollection.doStart(HandlerCollection.java:165) at org.eclipse.jetty.server.handler.ContextHandlerCollection.doStart(ContextHandlerCollection.java:162) at org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:55) at org.eclipse.jetty.server.handler.HandlerCollection.doStart(HandlerCollection.java:165) at org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:55) at org.eclipse.jetty.server.handler.HandlerWrapper.doStart(HandlerWrapper.java:92) at org.eclipse.jetty.server.Server.doStart(Server.java:228) at org.mortbay.jetty.plugin.JettyServer.doStart(JettyServer.java:69) at org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:55) at org.mortbay.jetty.plugin.AbstractJettyMojo.startJetty(AbstractJettyMojo.java:433) at org.mortbay.jetty.plugin.AbstractJettyMojo.execute(AbstractJettyMojo.java:377) at org.mortbay.jetty.plugin.JettyRunWarMojo.execute(JettyRunWarMojo.java:68) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:490) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:694) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:569) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:539) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:387) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:348) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:180) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:328) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:138) at org.apache.maven.cli.MavenCli.main(MavenCli.java:362) at
[jira] Commented: (EXTSCRIPT-73) Facelets resource handler does not trigger anymore
[ https://issues.apache.org/jira/browse/EXTSCRIPT-73?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12837834#action_12837834 ] Werner Punz commented on EXTSCRIPT-73: -- works again not sure why it failed before, probably pebcak Facelets resource handler does not trigger anymore -- Key: EXTSCRIPT-73 URL: https://issues.apache.org/jira/browse/EXTSCRIPT-73 Project: MyFaces Extensions Scripting Issue Type: Bug Reporter: Werner Punz Assignee: Werner Punz The faclets resource handler does not trigger anymore, maybe there was a namechange in the myfaces codebase regarding the facelets extension point -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (TRINIDAD-1738) TRINIDAD-1545 caused a regression by causing an infinite loop
TRINIDAD-1545 caused a regression by causing an infinite loop - Key: TRINIDAD-1738 URL: https://issues.apache.org/jira/browse/TRINIDAD-1738 Project: MyFaces Trinidad Issue Type: Bug Components: Components Affects Versions: 1.2.12-core Reporter: Andrew Robinson Assignee: Andrew Robinson Priority: Blocker The fix for 1545 results in an infinite loop in the code if there are enough circular dependencies with partialTriggers in a view. This causes the server CPU to peg. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (EXTSCRIPT-74) Cleanup the ASP part
Cleanup the ASP part Key: EXTSCRIPT-74 URL: https://issues.apache.org/jira/browse/EXTSCRIPT-74 Project: MyFaces Extensions Scripting Issue Type: Improvement Reporter: Werner Punz Assignee: Werner Punz Priority: Minor The ASM part needs some cleanup, we introduce a registry/filter system for the dependency registration -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (MYFACES-2576) Race condition in _ExternalSpecifications methods
[ https://issues.apache.org/jira/browse/MYFACES-2576?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12837915#action_12837915 ] Jan-Kees van Andel commented on MYFACES-2576: - It has to do with safe publication of the variable on multicore systems. Synchronizing is more than just locking, it's also about visibility of variables over multiple processor caches. Synchronizing also doesn't hurt performance in practice. I'm sure of that, because the expensive part is only executed once while holding the lock. If there happens to be a performance issue, we can always switch to some kind of other implementation, like Double Checked Locking, which is safe since Java 5. The only issue I currently see is the risk of deadlock, because we're effectively invoking alien code within the initialization code (we can't know the). Race condition in _ExternalSpecifications methods - Key: MYFACES-2576 URL: https://issues.apache.org/jira/browse/MYFACES-2576 Project: MyFaces Core Issue Type: Bug Components: JSR-314 Affects Versions: 2.0.0-beta-2 Environment: * Reporter: Jan-Kees van Andel The static final fields in the _ExternalSpecifications have recently been refactored into methods. But unfortunately, this has broken thread safety, possibly leading to strange errors (like NPE). I think the only solution with the current implementation is to make the methods synchronized. Volatile is not enough AFAICS... -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (TRINIDAD-1739) ComponentReference doesn't work with bindings and should be more thread-safe
ComponentReference doesn't work with bindings and should be more thread-safe Key: TRINIDAD-1739 URL: https://issues.apache.org/jira/browse/TRINIDAD-1739 Project: MyFaces Trinidad Issue Type: Improvement Components: Archetype Affects Versions: 2.0.0-alpha, 1.2.13-core Environment: All Reporter: Blake Sullivan Assignee: Blake Sullivan ComponentReference has three problems: 1) Because it requires that the Component be in the component tree at the time that the ComponentReference is created, it doesn't work with component bindings, which at called before the component is added to the component tree 2) The current thread-safety guarantees (none) are insufficient for a utility class that is designed to be used from beans in scopes longer than request. These beans always have the possibility of being called from multiple threads. 3) Doesn't implement hashCode() and equals() The solution to 1) is to internally use two different implementations--one for the case where the component meets the current requirements, the second to handle the case where the component has no id or isn't in the component tree yet. In this case, we defer calculating the scoped id until all call that requires a scoped id--getComponent(), hashCode() and equals(). At this point, presumably the component is in the tree and if it isn't we throw an IllegalStateException (instead of the previous IllegalArgumentException). There are two more parts to this problem--there is no guarantee that the deferred ComponentReference will actually be called at all, but the deferred instance is holding onto a Component and we don't want to do so across requests, so we maintain a list of all of the deferred ComponentRefererences and call a new method--ensureInstantiation() on all of them at the end of the request from the GlobalConfiguratorImpl. The other trick is that we only want to deserialize stable component references, so we now use a serialization proxy instead of default serialization. The thread-safety solution is to make judicious use of thread-safe references to mutable data internally and guarantee that getComponent() can be called on an instantiated ComponentReference as long as the call is made from a Thread with a FacesContext. hashCode() and equals() are based on the scoped id of the ComponentReferences. Two ComponentReferences with the same scoped id are equivalent. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (PORTLETBRIDGE-124) Edit in portlet-bridge-demo-2.0.0-SNAPSHOT does not work
Edit in portlet-bridge-demo-2.0.0-SNAPSHOT does not work Key: PORTLETBRIDGE-124 URL: https://issues.apache.org/jira/browse/PORTLETBRIDGE-124 Project: MyFaces Portlet Bridge Issue Type: Bug Components: General Affects Versions: 2.0.0-alpha Reporter: Deepak Gothe The edit in the example jsf-portlet - portlet-bridge-demo-2.0.0-SNAPSHOT.war does not work. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (PORTLETBRIDGE-124) Edit in portlet-bridge-demo-2.0.0-SNAPSHOT does not work
[ https://issues.apache.org/jira/browse/PORTLETBRIDGE-124?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Deepak Gothe updated PORTLETBRIDGE-124: --- Status: Patch Available (was: Open) Edit in portlet-bridge-demo-2.0.0-SNAPSHOT does not work Key: PORTLETBRIDGE-124 URL: https://issues.apache.org/jira/browse/PORTLETBRIDGE-124 Project: MyFaces Portlet Bridge Issue Type: Bug Components: General Affects Versions: 2.0.0-alpha Reporter: Deepak Gothe Attachments: portlet.xml.patch The edit in the example jsf-portlet - portlet-bridge-demo-2.0.0-SNAPSHOT.war does not work. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (PORTLETBRIDGE-125) Portlet Schema Validation for portlet-bridge-blank-2.0.0-SNAPSHOT.war fails
Portlet Schema Validation for portlet-bridge-blank-2.0.0-SNAPSHOT.war fails --- Key: PORTLETBRIDGE-125 URL: https://issues.apache.org/jira/browse/PORTLETBRIDGE-125 Project: MyFaces Portlet Bridge Issue Type: Bug Components: General Affects Versions: 2.0.0-alpha Environment: GlassFish Web Space Server 10.0, Liferay Portal 5.2.3 Reporter: Deepak Gothe Attachments: portlet.xml.patch The example portlet-bridge-blank-2.0.0-SNAPSHOT.war fails to deploy on GlassFish Web Space Server and Liferay Portal 5.2.3 as the portlet schema validation fails. The following exception is thrown during deployment: error parsing portlet stream org.xml.sax.SAXParseException: cvc-complex-type.3.2.2: Attribute 'lang' is not allowed to appear in element 'description'. Also the edit does not work. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (PORTLETBRIDGE-125) Portlet Schema Validation for portlet-bridge-blank-2.0.0-SNAPSHOT.war fails
[ https://issues.apache.org/jira/browse/PORTLETBRIDGE-125?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Deepak Gothe updated PORTLETBRIDGE-125: --- Status: Patch Available (was: Open) Portlet Schema Validation for portlet-bridge-blank-2.0.0-SNAPSHOT.war fails --- Key: PORTLETBRIDGE-125 URL: https://issues.apache.org/jira/browse/PORTLETBRIDGE-125 Project: MyFaces Portlet Bridge Issue Type: Bug Components: General Affects Versions: 2.0.0-alpha Environment: GlassFish Web Space Server 10.0, Liferay Portal 5.2.3 Reporter: Deepak Gothe Attachments: portlet.xml.patch The example portlet-bridge-blank-2.0.0-SNAPSHOT.war fails to deploy on GlassFish Web Space Server and Liferay Portal 5.2.3 as the portlet schema validation fails. The following exception is thrown during deployment: error parsing portlet stream org.xml.sax.SAXParseException: cvc-complex-type.3.2.2: Attribute 'lang' is not allowed to appear in element 'description'. Also the edit does not work. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [Facelets] deploying old Facelets templates with MyFaces 2
Also this blocks me from testing the beta with DojoFaces which might reveal other issues ... Best regards, Ganesh Matthias Wessendorf schrieb: Again... MYFACES-2543 *snip* If the answer to this question is no, Facelets in JSF 2.0 is backwards compatible with pre-JSF 2.0 Facelets and such an application must not continue to bundle the Facelets jar file along with the application, and must not continue to set the Facelets configuration parameters. *snip* So, this is actually blocking a reasonable use-case. Please keep the bug open ;-) -Matthias
