[orchestra] rename scope flash to access
Hi All, Currently in orchestra there are two types of conversation scope: manual and flash. With manual, a conversation must be explicitly ended via either a call to the Orchestra API, or use of a jsf tag. With flash, the conversation is automatically ended when a request cycle ends and no object in the conversation was accessed. Some people have noted that other libraries use the term flash scope for a somewhat different purpose. I therefore propose changing the name to access scope. This change will mean renaming about 6 classes, updating the examples and updating the website documentation. I intend to keep backwards compatibility with 1.0 to the level where normal Spring configuration files still work unaltered (and will test this by making sure the existing orchestra examples work unaltered, before I update them to show the new config). However for classes which would only be used by people deriving their own custom scope-managers, etc., I don't currently plan to keep full binary compatibility. Are there any objections? Regards, Simon
[Trinidad] chart within SSL
I am having trouble displaying the tr:chart/ component in IE6+ within an SSL context. The chart displays just fine on other browsers and will display on IE if not within SSL (link to SVG viewer is displayed...does not help). I am using Trinidad 1.2.5 with JSF 1.2_04. My appserver is Tomcat 6.0.14 with jdk 1.5.0_14 on Windows 2003 server and my ssl configuration is: Connector protocol=org.apache.coyote.http11.Http11AprProtocol port=8443 minSpareThreads=5 maxSpareThreads=75 enableLookups=true disableUploadTimeout=true acceptCount=100 maxThreads=200 scheme=https secure=true SSLEnabled=true SSLCertificateFile=path-to-cert-file SSLCertificateKeyFile=path-to-key-file clientAuth=false sslProtocol=TLS/ I am getting the following error in the logs: ClientAbortException: java.io.IOException at org.apache.catalina.connector.OutputBuffer.realWriteBytes(OutputBuffer.java:358) at org.apache.tomcat.util.buf.ByteChunk.flushBuffer(ByteChunk.java:434) at org.apache.catalina.connector.OutputBuffer.doFlush(OutputBuffer.java:309) at org.apache.catalina.connector.OutputBuffer.close(OutputBuffer.java:273) at org.apache.catalina.connector.CoyoteOutputStream.close(CoyoteOutputStream.java:104) at org.apache.myfaces.trinidad.webapp.ResourceServlet.doGet(ResourceServlet.java:225) at javax.servlet.http.HttpServlet.service(HttpServlet.java:698) at javax.servlet.http.HttpServlet.service(HttpServlet.java:803) at org.apache.myfaces.trinidad.webapp.ResourceServlet.service(ResourceServlet.java:162) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175) at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:525) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:263) at org.apache.coyote.http11.Http11AprProcessor.process(Http11AprProcessor.java:852) at org.apache.coyote.http11.Http11AprProtocol$Http11ConnectionHandler.process(Http11AprProtocol.java:584) at org.apache.tomcat.util.net.AprEndpoint$Worker.run(AprEndpoint.java:1508) at java.lang.Thread.run(Thread.java:595) Caused by: java.io.IOException at org.apache.coyote.http11.InternalAprOutputBuffer.flushBuffer(InternalAprOutputBuffer.java:692) at org.apache.coyote.http11.InternalAprOutputBuffer$SocketOutputBuffer.doWrite(InternalAprOutputBuffer.java:722) at org.apache.coyote.http11.filters.IdentityOutputFilter.doWrite(IdentityOutputFilter.java:118) at org.apache.coyote.http11.InternalAprOutputBuffer.doWrite(InternalAprOutputBuffer.java:528) at org.apache.coyote.Response.doWrite(Response.java:560) at org.apache.catalina.connector.OutputBuffer.realWriteBytes(OutputBuffer.java:353) ... 21 more Jan 28, 2008 1:33:18 PM org.apache.myfaces.trinidad.webapp.ResourceServlet service SEVERE: ClientAbortException: java.io.IOException at org.apache.catalina.connector.OutputBuffer.realWriteBytes(OutputBuffer.java:358) at org.apache.tomcat.util.buf.ByteChunk.flushBuffer(ByteChunk.java:434) at org.apache.catalina.connector.OutputBuffer.doFlush(OutputBuffer.java:309) at org.apache.catalina.connector.OutputBuffer.close(OutputBuffer.java:273) at org.apache.catalina.connector.CoyoteOutputStream.close(CoyoteOutputStream.java:104) at org.apache.myfaces.trinidad.webapp.ResourceServlet.doGet(ResourceServlet.java:225) at javax.servlet.http.HttpServlet.service(HttpServlet.java:698) at javax.servlet.http.HttpServlet.service(HttpServlet.java:803) at org.apache.myfaces.trinidad.webapp.ResourceServlet.service(ResourceServlet.java:162) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175) at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:525) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) at
Re: [orchestra] rename scope flash to access
Aargh.. top posting! Simon Regards, I will try to find some time this weekend. Yes, we would like to get a new release out in the next couple of weeks. Hi Matthias, Matthias Wessendorf [EMAIL PROTECTED] schrieb: That sounds very good. Do you guys plan to release the bits soon as well ? -M On Jan 29, 2008 9:03 AM, Mario Ivankovits [EMAIL PROTECTED] wrote: Hi Simon! Are there any objections? Sounds good! Ciao, Mario -- Matthias Wessendorf further stuff: blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf mail: matzew-at-apache-dot-org
Re: [orchestra] rename scope flash to access
Hi Simon! Are there any objections? Sounds good! Ciao, Mario
Re: [orchestra] rename scope flash to access
That sounds very good. Do you guys plan to release the bits soon as well ? -M On Jan 29, 2008 9:03 AM, Mario Ivankovits [EMAIL PROTECTED] wrote: Hi Simon! Are there any objections? Sounds good! Ciao, Mario -- Matthias Wessendorf further stuff: blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf mail: matzew-at-apache-dot-org
Re: [orchestra] rename scope flash to access
Yes, we would like to get a new release out in the next couple of weeks. nice Hi Matthias, bonjourno Matthias Wessendorf [EMAIL PROTECTED] schrieb: That sounds very good. Do you guys plan to release the bits soon as well ? -M On Jan 29, 2008 9:03 AM, Mario Ivankovits [EMAIL PROTECTED] wrote: Hi Simon! Are there any objections? Sounds good! Ciao, Mario -- Matthias Wessendorf further stuff: blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf mail: matzew-at-apache-dot-org -- Matthias Wessendorf further stuff: blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf mail: matzew-at-apache-dot-org
Re: Tree skinning problem with Trinidad 1.2.5
Thanks Cristi,
did you just check in the changes, or are they in 1.2.5 of Trinidad
already ? I am asking because I was testing the skin with the Trinidad
component demo
Frank
Cristi Toth wrote:
Hey Frank,
Sorry for me beeing not attentive.
The code is comitted and should work.
But for the nice node icons (folder/document/...) to work,
you need to have in your tree node class a getNodeType() method
that returns for each node it's type (String)
i.e. if for one node the method returns "folder"
then you will have the following selectors:
af|tree::node-icon:folder-collapsed (for a collapsed node - if it has
children)
af|tree::node-icon:folder-expanded (for an expanded node - if it has
children)
af|tree::node-icon:folder (for a node that doesn't have children)
this way you could skin each node different,
just by changing the value returned by getNodeType() method.
A good example you find in the trinidad-demo
the node class is DemoTreeData and the skin file is beach.css
Sorry for the late answer and hope to be of some help.
On Jan 23, 2008 7:45 PM, Frank Nimphius [EMAIL PROTECTED]
wrote:
I am trying to skin the trinidad tree so it looks like the ADF Faces
tree. Looks good so far, but I am struggeling with the folder icon. I
downloaded Trinidad 1.2.5 (the latest release). Looking at the
treeRenderer and the SkinSelector class, it appears (as I understand the
code) that the tree folder icon is composed as
af|tree::node-icon:-collapsed{content:url('/skins/oracle/images/tfold.gif');}
af|tree::node-icon:-expanded{content:url('/skins/oracle/images/tfold.gif');}
This doesn't work and also looks strange. Can whoever built the
treeRenderer have a look to verify if its me or the code?
Frank
--
Frank Nimphius
Principal Product Manager
Application Development Tools
Oracle Corporation
mail: [EMAIL PROTECTED]
phone:+49 2058 782481
--
Cristi Toth
-
Codebeat
www.codebeat.ro
--
Frank Nimphius
Principal Product Manager
Application Development Tools
Oracle Corporation
mail: [EMAIL PROTECTED]
phone:+49 2058 782481
Re: Compatibility Matrix severely out of date
Barbalace schrieb: Hello. The Compatibility Matrix is so severely out of date as to be useless. Could someone familiar with the releases update this on the wiki: http://wiki.apache.org/myfaces/CompatibilityMatrix I have been trying to upgrade Tomahawk (from 1.1.3) and MyFaces core (from 1.1.4, the last compatible match) on my projects, but figuring out which versions to use has not been easy to say the least. This is something that simply needs time, to run each tomahawk version with each myfaces version and see what happens. That is something that *users* can do - ie people like you. Those who actually develop the code generally have better things to spend their time on, like fixing bugs and adding features. I'm tempted to delete this page completely, and move the info to the wiki where the user community can maintain it - if they wish. Regards, Simon
Re: [orchestra] rename scope flash to access
yes, good idea +1 I like the name access scope and also experienced people who use the term flash scope for t:saveState usage. --Manfred On Jan 29, 2008 8:59 AM, Simon Kitching [EMAIL PROTECTED] wrote: Hi All, Currently in orchestra there are two types of conversation scope: manual and flash. With manual, a conversation must be explicitly ended via either a call to the Orchestra API, or use of a jsf tag. With flash, the conversation is automatically ended when a request cycle ends and no object in the conversation was accessed. Some people have noted that other libraries use the term flash scope for a somewhat different purpose. I therefore propose changing the name to access scope. This change will mean renaming about 6 classes, updating the examples and updating the website documentation. I intend to keep backwards compatibility with 1.0 to the level where normal Spring configuration files still work unaltered (and will test this by making sure the existing orchestra examples work unaltered, before I update them to show the new config). However for classes which would only be used by people deriving their own custom scope-managers, etc., I don't currently plan to keep full binary compatibility. Are there any objections? Regards, Simon -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
Re: [COMMUNITY] MyFaces += Bernhard Huemer
Welcome dude, -M On Jan 29, 2008 12:20 PM, Manfred Geiler [EMAIL PROTECTED] wrote: The Myfaces PMC is proud to announce a new addition to our community. Please welcome Bernhard Huemer as the newest MyFaces committer. Bernhard Huemer has been providing several patches (including a very tricky EL-bug) and has also been very active on the mailing-list. @Bernhard: Please add yourself to the Master-POM at https://svn.apache.org/repos/asf/myfaces/myfaces-master-pom/trunk/pom.xml --Manfred -- Matthias Wessendorf further stuff: blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf mail: matzew-at-apache-dot-org
[COMMUNITY] MyFaces += Bernhard Huemer
The Myfaces PMC is proud to announce a new addition to our community. Please welcome Bernhard Huemer as the newest MyFaces committer. Bernhard Huemer has been providing several patches (including a very tricky EL-bug) and has also been very active on the mailing-list. @Bernhard: Please add yourself to the Master-POM at https://svn.apache.org/repos/asf/myfaces/myfaces-master-pom/trunk/pom.xml --Manfred
[jira] Created: (TOBAGO-609) Options on markup in tx components
Options on markup in tx components -- Key: TOBAGO-609 URL: https://issues.apache.org/jira/browse/TOBAGO-609 Project: MyFaces Tobago Issue Type: Improvement Affects Versions: 1.0.14 Environment: All Reporter: Ricardo S. Tanaka Add an attribute markup-for in tx components to define if the markup will affect only the component, the label or both. eg. If I put tx:in markup=color markup-for=label / only the label component will be with the markup color. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [COMMUNITY] MyFaces += Bernhard Huemer
Welcome Bernhard! I've been very glad for your help here with MyFaces. regards, Martin On Jan 29, 2008 12:25 PM, Matthias Wessendorf [EMAIL PROTECTED] wrote: Welcome dude, -M On Jan 29, 2008 12:20 PM, Manfred Geiler [EMAIL PROTECTED] wrote: The Myfaces PMC is proud to announce a new addition to our community. Please welcome Bernhard Huemer as the newest MyFaces committer. Bernhard Huemer has been providing several patches (including a very tricky EL-bug) and has also been very active on the mailing-list. @Bernhard: Please add yourself to the Master-POM at https://svn.apache.org/repos/asf/myfaces/myfaces-master-pom/trunk/pom.xml --Manfred -- Matthias Wessendorf further stuff: blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf mail: matzew-at-apache-dot-org -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
Re: [orchestra] rename scope flash to access
will there be a flash scope in Orchestra as well (as an option to using t:saveState)? will Trinidad ever be fixed to work with a flash-scope ;) ? regards, Martin On Jan 29, 2008 12:25 PM, Manfred Geiler [EMAIL PROTECTED] wrote: yes, good idea +1 I like the name access scope and also experienced people who use the term flash scope for t:saveState usage. --Manfred On Jan 29, 2008 8:59 AM, Simon Kitching [EMAIL PROTECTED] wrote: Hi All, Currently in orchestra there are two types of conversation scope: manual and flash. With manual, a conversation must be explicitly ended via either a call to the Orchestra API, or use of a jsf tag. With flash, the conversation is automatically ended when a request cycle ends and no object in the conversation was accessed. Some people have noted that other libraries use the term flash scope for a somewhat different purpose. I therefore propose changing the name to access scope. This change will mean renaming about 6 classes, updating the examples and updating the website documentation. I intend to keep backwards compatibility with 1.0 to the level where normal Spring configuration files still work unaltered (and will test this by making sure the existing orchestra examples work unaltered, before I update them to show the new config). However for classes which would only be used by people deriving their own custom scope-managers, etc., I don't currently plan to keep full binary compatibility. Are there any objections? Regards, Simon -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
[jira] Commented: (TOBAGO-609) Options on markup in tx components
[ https://issues.apache.org/jira/browse/TOBAGO-609?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12563488#action_12563488 ] Ricardo S. Tanaka commented on TOBAGO-609: -- Is this the best way to resolve this? I already using this way, but i was thinking to use the tx compoment because is more simple. Anyway, thanks. Options on markup in tx components -- Key: TOBAGO-609 URL: https://issues.apache.org/jira/browse/TOBAGO-609 Project: MyFaces Tobago Issue Type: Improvement Affects Versions: 1.0.14 Environment: All Reporter: Ricardo S. Tanaka Priority: Minor Add an attribute markup-for in tx components to define if the markup will affect only the component, the label or both. eg. If I put tx:in markup=color markup-for=label / only the label component will be with the markup color. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [COMMUNITY] MyFaces += Bernhard Huemer
Welcome!
[jira] Created: (MYFACES-1811) cannot set enctype on h:form with el
cannot set enctype on h:form with el
Key: MYFACES-1811
URL: https://issues.apache.org/jira/browse/MYFACES-1811
Project: MyFaces Core
Issue Type: Bug
Components: JSR-252
Affects Versions: 1.2.2
Environment: Windows, Tomcat 6.0.14, facelets 1.1.14
Reporter: John Singleton
I have the following code in a facelets composition
h:form onsubmit=return submitForm() id=main enctype=#{(empty
encoding) ? 'application/x-www-form-urlencoded' : encoding}
Depending on how the form is used the enctype might need to be
multipart/form-data
I use the composition like so:
ui:decorate xmlns=http://www.w3.org/1999/xhtml;
xmlns:t=http://myfaces.apache.org/tomahawk;
xmlns:ui=http://java.sun.com/jsf/facelets;
xmlns:h=http://java.sun.com/jsf/html;
xmlns:f=http://java.sun.com/jsf/core;
template=#{pqfn:absoluteStyle('homeTemplate.xhtml')}
ui:param name=encoding value=multipart/form-data /
This worked prior to MyFaces 1.2. It doesn't work in 1.2+ Looking at
HtmlForm.java :
// Property: enctype
private String _enctype = application/x-www-form-urlencoded;
/**
* Gets The content type used to submit this form to the server.
*
* @return the new enctype value
*/
public String getEnctype()
{
if (_enctype != null)
{
return _enctype;
}
ValueExpression expression = getValueExpression(enctype);
if (expression != null)
{
return (String)expression.getValue(getFacesContext().getELContext());
}
return application/x-www-form-urlencoded;
}
As enctype is initialized in it's declaration it is never null. Therefore the
ValueExpression is never evaluated. This means the enctype cannot be set using
an EL Expression in the page.
I'm not sure if this is a bug against HtmlForm, or the maven-faces-plugin that
is generating this class.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: [orchestra] rename scope flash to access
then maybe it should be named page-scope :-) will Trinidad ever be fixed to work with a flash-scope ;) ? I was referring to the fact that Trinidad does not work with t:saveState, due to the optimized state-saving. I wonder if this can/should be fixed at some point of time. ah, well. I don't care :-) You are talking about Orchestra, aren't you ? no - see above. happy schöpfing, gleichfalls Martin -- Matthias Wessendorf further stuff: blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf mail: matzew-at-apache-dot-org
Re: [COMMUNITY] MyFaces += Bernhard Huemer
welcome bernhard! regards, gerhard 2008/1/29, Leonardo Uribe [EMAIL PROTECTED]: Welcome! -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
Re: [orchestra] rename scope flash to access
Hi Matthias, from the commits looks like flash will be the alias for access then maybe it should be named page-scope will Trinidad ever be fixed to work with a flash-scope ;) ? I was referring to the fact that Trinidad does not work with t:saveState, due to the optimized state-saving. I wonder if this can/should be fixed at some point of time. You are talking about Orchestra, aren't you ? no - see above. happy schöpfing, Martin
[jira] Commented: (TRINIDAD-898) skinning keys af|input*:readOnly:disabled:content do not work
[ https://issues.apache.org/jira/browse/TRINIDAD-898?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12563492#action_12563492 ] Matthias Weßendorf commented on TRINIDAD-898: - should be read-only, instead of readOnly. Looks like read-only is used when both is true (readOnly:true, disabled:true). Not sure if that is really wrong. skinning keys af|input*:readOnly:disabled:content do not work - Key: TRINIDAD-898 URL: https://issues.apache.org/jira/browse/TRINIDAD-898 Project: MyFaces Trinidad Issue Type: Bug Components: Skinning Affects Versions: 1.2.5-core Reporter: Sandy Schaffner Assignee: Matthias Weßendorf Priority: Minor The following skinning keys do not work: af|inputColor:readOnly:disabled::content af|inputDate:readOnly:disabled::content af|inputListOfValues:readOnly:disabled::content af|inputNumberSpinbox:readOnly:disabled::content af|inputText:readOnly:disabled::content -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [orchestra] rename scope flash to access
On Jan 29, 2008 1:22 PM, Martin Marinschek [EMAIL PROTECTED] wrote: will there be a flash scope in Orchestra as well (as an option to using t:saveState)? from the commits looks like flash will be the alias for access will Trinidad ever be fixed to work with a flash-scope ;) ? I moved all my flash scopes to manual, but I think there was a fix related to that. You are talking about Orchestra, aren't you ? -M regards, Martin On Jan 29, 2008 12:25 PM, Manfred Geiler [EMAIL PROTECTED] wrote: yes, good idea +1 I like the name access scope and also experienced people who use the term flash scope for t:saveState usage. --Manfred On Jan 29, 2008 8:59 AM, Simon Kitching [EMAIL PROTECTED] wrote: Hi All, Currently in orchestra there are two types of conversation scope: manual and flash. With manual, a conversation must be explicitly ended via either a call to the Orchestra API, or use of a jsf tag. With flash, the conversation is automatically ended when a request cycle ends and no object in the conversation was accessed. Some people have noted that other libraries use the term flash scope for a somewhat different purpose. I therefore propose changing the name to access scope. This change will mean renaming about 6 classes, updating the examples and updating the website documentation. I intend to keep backwards compatibility with 1.0 to the level where normal Spring configuration files still work unaltered (and will test this by making sure the existing orchestra examples work unaltered, before I update them to show the new config). However for classes which would only be used by people deriving their own custom scope-managers, etc., I don't currently plan to keep full binary compatibility. Are there any objections? Regards, Simon -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces -- Matthias Wessendorf further stuff: blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf mail: matzew-at-apache-dot-org
Re: [COMMUNITY] MyFaces += Bernhard Huemer
Welcome Bernhard! Best wishes, Paul On Jan 29, 2008, at 6:20 AM, Manfred Geiler wrote: The Myfaces PMC is proud to announce a new addition to our community. Please welcome Bernhard Huemer as the newest MyFaces committer. Bernhard Huemer has been providing several patches (including a very tricky EL-bug) and has also been very active on the mailing-list. @Bernhard: Please add yourself to the Master-POM at https://svn.apache.org/repos/asf/myfaces/myfaces-master-pom/trunk/ pom.xml --Manfred
[Trinidad] Trinidad Form + dataScroller
Hi list, when i use an Tomahawk dataTable and a Tomahawk dataScroller component inside a Trinidad Form than it isn't possible to navigate with the dataScroller. The page is always the first. I want to use Triniad Form for partialTrigger. Knows anybody this issue? Regards Philipp Michel
Re: [COMMUNITY] MyFaces += Bernhard Huemer
Manfred Geiler schrieb: The Myfaces PMC is proud to announce a new addition to our community. Please welcome Bernhard Huemer as the newest MyFaces committer. Bernhard Huemer has been providing several patches (including a very tricky EL-bug) and has also been very active on the mailing-list. @Bernhard: Please add yourself to the Master-POM at https://svn.apache.org/repos/asf/myfaces/myfaces-master-pom/trunk/pom.xml --Manfred Congratulations
Re: [Trinidad] add method to get an application scoped concurrentMap to RequestContext (TRINIDAD-926)
Oops, and _getClassLoader
private ClassLoader _getClassLoader()
{
return Thread.currentThread().getContextClassLoader();
}
Gabrielle Crawford wrote:
Here's the implementation I have so far in
org.apache.myfaces.trinidadinternal.context.RequestContextImpl
@Override
public ConcurrentMapString, Object getApplicationScopedConcurrentMap()
{
ClassLoader cl = _getClassLoader();
ConcurrentMapString, Object classMap = _applicationMaps.get(cl);
if (classMap == null)
{
ConcurrentMapString, Object newClassMap = new
ConcurrentHashMapString, Object();
ConcurrentMapString, Object oldClassMap =
_applicationMaps.putIfAbsent(cl, newClassMap);
classMap = ((oldClassMap != null)? oldClassMap : newClassMap);
assert(classMap != null);
}
return classMap;
}
@SuppressWarnings({CollectionWithoutInitialCapacity})
private static final ConcurrentMapClassLoader,
ConcurrentMapString, Object _applicationMaps =
new ConcurrentHashMapClassLoader, ConcurrentMapString,
Object();
Martin Marinschek wrote:
where will this map be stored?
regards,
Martin
On Jan 29, 2008 6:38 AM, Matthias Wessendorf [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED] wrote:
+1
On Jan 29, 2008 2:48 AM, Blake Sullivan
[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote:
I'm, of course, in favor.
-- Blake Sullivan
Gabrielle Crawford wrote:
Hi,
In case anyone filtered away the [jira] message.
I'd like to add the method described below to the requestContext.
Comments? Objections?
Thanks,
Gab
Original Message
add method to get an application scoped concurrentMap to
RequestContext
---
Key: TRINIDAD-926
URL:
https://issues.apache.org/jira/browse/TRINIDAD-926
Project: MyFaces Trinidad
Issue Type: Improvement
Affects Versions: 1.2.5-core, 1.0.5-core
Reporter: Gabrielle Crawford
Assignee: Gabrielle Crawford
Priority: Minor
This started with Trin Issue 891
https://issues.apache.org/jira/browse/TRINIDAD-891
To avoid the locking in the class loader we'd like to store a
map of
name-class per app. However the external context app map calls
through to the ServletContext. The Servlet specification doesn't
specify whether the ServletContext performs any locking on the
ServletContext attributes and the ServletContext doesn't
expose the
necessary methods for efficient concurrent access
(essentially the
operations exposed on ConcurrentMap) necessary to work
efficiently in
many cases even if the ServletContext didn't need to perform
locking
on reads. The result is that the ExternalContext's
ApplicationMap
can't implement ConcurrentMap.
We'd like to add a method to the RequestContext to get an
application
scoped concurrent map. This would not call through to the servlet
context. The api proposed is this:
/**
* Gets a per application concurrent map. There is no
synchronization
* with ServletContext attributes.
*/
public abstract ConcurrentMapString, Object
getApplicationScopedConcurrentMap();
--
Matthias Wessendorf
further stuff:
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
mail: matzew-at-apache-dot-org
--
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
[jira] Updated: (TOBAGO-605) Readonly support for tc:selectOneRadio and tc:selectManyCheckbox
[ https://issues.apache.org/jira/browse/TOBAGO-605?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bernd Bohmann updated TOBAGO-605: - Status: Open (was: Patch Available) Readonly support for tc:selectOneRadio and tc:selectManyCheckbox Key: TOBAGO-605 URL: https://issues.apache.org/jira/browse/TOBAGO-605 Project: MyFaces Tobago Issue Type: Improvement Components: Core, Themes Affects Versions: 1.0.14 Reporter: Bernd Bohmann Assignee: Bernd Bohmann Fix For: 1.0.15, 1.1.0 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Bug in FacesConfigurator.feedClassloaderConfigurations()?
Hello. I just found something that I think is a bug in FacesConfigurator.feedClassloaderConfigurations() algorithm. Please correct me if I am wrong. The problem I see is this: ClassUtils.getResources(FACES_CONFIG_RESOURCE, this) will return an iterator over all META-INF/faces-config.xml resources that were found. The search is carried out by starting at WebAppClassLoader and making an Enumeration of all resources with the given name, that WebAppClassLoader and all its parents see. The jars placed into WEB-INF/lib will be seen by the WebAppClassLoader AND AppClassLoader, thus resulting in the same jars (the ones that have META-INF/faces-config.xml) being placed on the list twice. This is fine, but things break when FacesConfigurator.feedClassloaderConfigurations() does not check for duplicate URLs and just blindly registers everything from these jars twice. I noticed this b/c all of my phase listeners were executing twice due to being registered with the lifecycle twice. Is this a bug, or have I configured something wrong? Val -- View this message in context: http://www.nabble.com/Bug-in-FacesConfigurator.feedClassloaderConfigurations%28%29--tp15168891p15168891.html Sent from the My Faces - Dev mailing list archive at Nabble.com.
Re: [orchestra] rename scope flash to access
access says exactly what it does. keeps the conversation active as long as it is accessed - ie. as long as any bean in this conversation is used during the next request. --Manfred On Jan 29, 2008 9:32 PM, Kito D. Mann [EMAIL PROTECTED] wrote: Hmmm... I agree that flash can be misleading, but access doesn't seem very descriptive to me. I think page or view might be more appropriate. ~~~ Kito D. Mann - Author, JavaServer Faces in Action http://www.virtua.com - JSF/Java EE consulting, training, and mentoring http://www.JSFCentral.com - JavaServer Faces FAQ, news, and info -Original Message- From: Simon Kitching [mailto:[EMAIL PROTECTED] Sent: Tuesday, January 29, 2008 3:00 AM To: dev@myfaces.apache.org Subject: [orchestra] rename scope flash to access Hi All, Currently in orchestra there are two types of conversation scope: manual and flash. With manual, a conversation must be explicitly ended via either a call to the Orchestra API, or use of a jsf tag. With flash, the conversation is automatically ended when a request cycle ends and no object in the conversation was accessed. Some people have noted that other libraries use the term flash scope for a somewhat different purpose. I therefore propose changing the name to access scope. This change will mean renaming about 6 classes, updating the examples and updating the website documentation. I intend to keep backwards compatibility with 1.0 to the level where normal Spring configuration files still work unaltered (and will test this by making sure the existing orchestra examples work unaltered, before I update them to show the new config). However for classes which would only be used by people deriving their own custom scope-managers, etc., I don't currently plan to keep full binary compatibility. Are there any objections? Regards, Simon -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
RE: [orchestra] rename scope flash to access
Hmmm... I agree that flash can be misleading, but access doesn't seem very descriptive to me. I think page or view might be more appropriate. ~~~ Kito D. Mann - Author, JavaServer Faces in Action http://www.virtua.com - JSF/Java EE consulting, training, and mentoring http://www.JSFCentral.com - JavaServer Faces FAQ, news, and info -Original Message- From: Simon Kitching [mailto:[EMAIL PROTECTED] Sent: Tuesday, January 29, 2008 3:00 AM To: dev@myfaces.apache.org Subject: [orchestra] rename scope flash to access Hi All, Currently in orchestra there are two types of conversation scope: manual and flash. With manual, a conversation must be explicitly ended via either a call to the Orchestra API, or use of a jsf tag. With flash, the conversation is automatically ended when a request cycle ends and no object in the conversation was accessed. Some people have noted that other libraries use the term flash scope for a somewhat different purpose. I therefore propose changing the name to access scope. This change will mean renaming about 6 classes, updating the examples and updating the website documentation. I intend to keep backwards compatibility with 1.0 to the level where normal Spring configuration files still work unaltered (and will test this by making sure the existing orchestra examples work unaltered, before I update them to show the new config). However for classes which would only be used by people deriving their own custom scope-managers, etc., I don't currently plan to keep full binary compatibility. Are there any objections? Regards, Simon
[jira] Commented: (MYFACES-1225) JSR-252 Issue #58: Enabled protected access to internal DataModel in UIData
[ https://issues.apache.org/jira/browse/MYFACES-1225?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12563607#action_12563607 ] Paul Pogonyshev commented on MYFACES-1225: -- I dont't understand. It was private and is private in SVN. What has changed? I stumbled into it after I derived right from UIData: cannot play around with createDataModel, while I could with a custom Tomahawk table derivative. Apparently, Tomahawk uses some hack class. And Tomahawk's wish to have access to getDataModel() etc. is not Tomahawk-specific, I want to do the same... JSR-252 Issue #58: Enabled protected access to internal DataModel in UIData --- Key: MYFACES-1225 URL: https://issues.apache.org/jira/browse/MYFACES-1225 Project: MyFaces Core Issue Type: Improvement Components: JSR-252 Reporter: Stan Silvert Assignee: Dennis Byrne Enabled protected access to internal DataModel in UIData See https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=58 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [Trinidad] add method to get an application scoped concurrentMap to RequestContext (TRINIDAD-926)
Here's the implementation I have so far in
org.apache.myfaces.trinidadinternal.context.RequestContextImpl
@Override
public ConcurrentMapString, Object getApplicationScopedConcurrentMap()
{
ClassLoader cl = _getClassLoader();
ConcurrentMapString, Object classMap = _applicationMaps.get(cl);
if (classMap == null)
{
ConcurrentMapString, Object newClassMap = new
ConcurrentHashMapString, Object();
ConcurrentMapString, Object oldClassMap =
_applicationMaps.putIfAbsent(cl, newClassMap);
classMap = ((oldClassMap != null)? oldClassMap : newClassMap);
assert(classMap != null);
}
return classMap;
}
@SuppressWarnings({CollectionWithoutInitialCapacity})
private static final ConcurrentMapClassLoader, ConcurrentMapString,
Object _applicationMaps =
new ConcurrentHashMapClassLoader, ConcurrentMapString, Object();
Martin Marinschek wrote:
where will this map be stored?
regards,
Martin
On Jan 29, 2008 6:38 AM, Matthias Wessendorf [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED] wrote:
+1
On Jan 29, 2008 2:48 AM, Blake Sullivan [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED] wrote:
I'm, of course, in favor.
-- Blake Sullivan
Gabrielle Crawford wrote:
Hi,
In case anyone filtered away the [jira] message.
I'd like to add the method described below to the requestContext.
Comments? Objections?
Thanks,
Gab
Original Message
add method to get an application scoped concurrentMap to
RequestContext
---
Key: TRINIDAD-926
URL:
https://issues.apache.org/jira/browse/TRINIDAD-926
Project: MyFaces Trinidad
Issue Type: Improvement
Affects Versions: 1.2.5-core, 1.0.5-core
Reporter: Gabrielle Crawford
Assignee: Gabrielle Crawford
Priority: Minor
This started with Trin Issue 891
https://issues.apache.org/jira/browse/TRINIDAD-891
To avoid the locking in the class loader we'd like to store a
map of
name-class per app. However the external context app map calls
through to the ServletContext. The Servlet specification doesn't
specify whether the ServletContext performs any locking on the
ServletContext attributes and the ServletContext doesn't
expose the
necessary methods for efficient concurrent access (essentially the
operations exposed on ConcurrentMap) necessary to work
efficiently in
many cases even if the ServletContext didn't need to perform
locking
on reads. The result is that the ExternalContext's ApplicationMap
can't implement ConcurrentMap.
We'd like to add a method to the RequestContext to get an
application
scoped concurrent map. This would not call through to the servlet
context. The api proposed is this:
/**
* Gets a per application concurrent map. There is no
synchronization
* with ServletContext attributes.
*/
public abstract ConcurrentMapString, Object
getApplicationScopedConcurrentMap();
--
Matthias Wessendorf
further stuff:
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
mail: matzew-at-apache-dot-org
--
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
Re: [orchestra] rename scope flash to access
Hi! Hmmm... I agree that flash can be misleading, but access doesn't seem very descriptive to me. I think page or view might be more appropriate. As it is currently in Orchestra, the fomer flash-scope is exactly an access-scope. As long as the bean is accessed it stay alive, regardles of the page it is used on. page or view are different scopes where one assumes that the bean vanishes as soon as another page is navigated to even if a conversation with the same name will be used here. We can discuss if such a scope makes sense for Orchestra I guess not. Ciao, Mario
[jira] Updated: (TOBAGO-527) tcs:tree can't get marked node
[ https://issues.apache.org/jira/browse/TOBAGO-527?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bernd Bohmann updated TOBAGO-527: - Status: Open (was: Patch Available) tcs:tree can't get marked node Key: TOBAGO-527 URL: https://issues.apache.org/jira/browse/TOBAGO-527 Project: MyFaces Tobago Issue Type: Improvement Affects Versions: 1.0.13 Reporter: Jens Janssen The Tree from Sandbox or a child component should have a method to get the marked node -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [Trinidad] Trinidad Form + dataScroller
you should post this to the user-list. regards, Martin On Jan 29, 2008 4:59 PM, Philipp Michel [EMAIL PROTECTED] wrote: Hi list, when i use an Tomahawk dataTable and a Tomahawk dataScroller component inside a Trinidad Form than it isn't possible to navigate with the dataScroller. The page is always the first. I want to use Triniad Form for partialTrigger. Knows anybody this issue? Regards Philipp Michel -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
h:form prependId=false renders null:inputId as clientId
Has anyone else encountered this behaviour so far? regards, Martin -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
Re: Tree skinning problem with Trinidad 1.2.5
As Matthias said, the changes were comitted in december.
And as I said a good example you find in the trinidad-demo
the node class is DemoTreeData and the skin file is beach.css
Give more details about your problem so I can help you.
regards,
On Jan 29, 2008 9:33 AM, Frank Nimphius [EMAIL PROTECTED] wrote:
Thanks Cristi,
did you just check in the changes, or are they in 1.2.5 of Trinidad
already ? I am asking because I was testing the skin with the Trinidad
component demo
Frank
Cristi Toth wrote:
Hey Frank,
Sorry for me beeing not attentive.
The code is comitted and should work.
But for the nice node icons (folder/document/...) to work,
you need to have in your tree node class a getNodeType() method
that returns for each node it's type (String)
i.e. if for one node the method returns folder
then you will have the following selectors:
af|tree::node-icon:folder-collapsed (for a collapsed node - if it has
children)
af|tree::node-icon:folder-expanded (for an expanded node - if it has
children)
af|tree::node-icon:folder (for a node that doesn't have children)
this way you could skin each node different,
just by changing the value returned by getNodeType() method.
A good example you find in the trinidad-demo
the node class is DemoTreeData and the skin file is beach.css
Sorry for the late answer and hope to be of some help.
On Jan 23, 2008 7:45 PM, Frank Nimphius [EMAIL PROTECTED] wrote:
I am trying to skin the trinidad tree so it looks like the ADF Faces
tree. Looks good so far, but I am struggeling with the folder icon. I
downloaded Trinidad 1.2.5 (the latest release). Looking at the
treeRenderer and the SkinSelector class, it appears (as I understand the
code) that the tree folder icon is composed as
af|tree::node-icon:-collapsed{content:url('/skins/oracle/images/tfold.gif');}
af|tree::node-icon:-expanded{content:url('/skins/oracle/images/tfold.gif');}
This doesn't work and also looks strange. Can whoever built the
treeRenderer have a look to verify if its me or the code?
Frank
--
Frank Nimphius
Principal Product Manager
Application Development Tools
Oracle Corporation
mail: [EMAIL PROTECTED]
phone:+49 2058 782481
--
Cristi Toth
-
Codebeat
www.codebeat.ro
--
Frank Nimphius
Principal Product Manager
Application Development Tools
Oracle Corporation
mail: [EMAIL PROTECTED]
phone:+49 2058 782481
--
Cristi Toth
-
Codebeat
www.codebeat.ro
Re: Tree skinning problem with Trinidad 1.2.5
Cristi,
thanks. I'll have a look at the beach.css and try to understand what I
did wrong.
Frank
Cristi Toth wrote:
As Matthias said, the changes were comitted in december.
And as I said "a good example you find in the trinidad-demo
the node class is DemoTreeData and the skin file is beach.css"
Give more details about your problem so I can help you.
regards,
On Jan 29, 2008 9:33 AM, Frank Nimphius [EMAIL PROTECTED]
wrote:
Thanks Cristi,
did you just check in the changes, or are they in 1.2.5 of Trinidad
already ? I am asking because I was testing the skin with the Trinidad
component demo
Frank
Cristi Toth wrote:
Hey Frank,
Sorry for me beeing not attentive.
The code is comitted and should work.
But for the nice node icons (folder/document/...) to work,
you need to have in your tree node class a getNodeType() method
that returns for each node it's type (String)
i.e. if for one node the method returns "folder"
then you will have the following selectors:
af|tree::node-icon:folder-collapsed (for a collapsed node - if it has
children)
af|tree::node-icon:folder-expanded (for an expanded node - if it has
children)
af|tree::node-icon:folder (for a node that doesn't have children)
this way you could skin each node different,
just by changing the value returned by getNodeType() method.
A good example you find in the trinidad-demo
the node class is DemoTreeData and the skin file is beach.css
Sorry for the late answer and hope to be of some help.
On Jan 23, 2008 7:45 PM, Frank Nimphius [EMAIL PROTECTED]
wrote:
I am trying to skin the trinidad tree so it looks like the ADF Faces
tree. Looks good so far, but I am struggeling with the folder icon. I
downloaded Trinidad 1.2.5 (the latest release). Looking at the
treeRenderer and the SkinSelector class, it appears (as I understand the
code) that the tree folder icon is composed as
af|tree::node-icon:-collapsed{content:url('/skins/oracle/images/tfold.gif');}
af|tree::node-icon:-expanded{content:url('/skins/oracle/images/tfold.gif');}
This doesn't work and also looks strange. Can whoever built the
treeRenderer have a look to verify if its me or the code?
Frank
--
Frank Nimphius
Principal Product Manager
Application Development Tools
Oracle Corporation
mail: [EMAIL PROTECTED]
phone:+49 2058 782481
--
Cristi Toth
-
Codebeat
www.codebeat.ro
--
Frank Nimphius
Principal Product Manager
Application Development Tools
Oracle Corporation
mail: [EMAIL PROTECTED]
phone:+49 2058 782481
--
Cristi Toth
-
Codebeat
www.codebeat.ro
--
Frank Nimphius
Principal Product Manager
Application Development Tools
Oracle Corporation
mail: [EMAIL PROTECTED]
phone:+49 2058 782481
Got It !!! Re: Tree skinning problem with Trinidad 1.2.5
Cristi,
thanks for the pointer to the beach.css. I found a clue that got me
going with
af|tree::node-icon:folder
Frank
Cristi Toth wrote:
As Matthias said, the changes were comitted in december.
And as I said "a good example you find in the trinidad-demo
the node class is DemoTreeData and the skin file is beach.css"
Give more details about your problem so I can help you.
regards,
On Jan 29, 2008 9:33 AM, Frank Nimphius [EMAIL PROTECTED]
wrote:
Thanks Cristi,
did you just check in the changes, or are they in 1.2.5 of Trinidad
already ? I am asking because I was testing the skin with the Trinidad
component demo
Frank
Cristi Toth wrote:
Hey Frank,
Sorry for me beeing not attentive.
The code is comitted and should work.
But for the nice node icons (folder/document/...) to work,
you need to have in your tree node class a getNodeType() method
that returns for each node it's type (String)
i.e. if for one node the method returns "folder"
then you will have the following selectors:
af|tree::node-icon:folder-collapsed (for a collapsed node - if it has
children)
af|tree::node-icon:folder-expanded (for an expanded node - if it has
children)
af|tree::node-icon:folder (for a node that doesn't have children)
this way you could skin each node different,
just by changing the value returned by getNodeType() method.
A good example you find in the trinidad-demo
the node class is DemoTreeData and the skin file is beach.css
Sorry for the late answer and hope to be of some help.
On Jan 23, 2008 7:45 PM, Frank Nimphius [EMAIL PROTECTED]
wrote:
I am trying to skin the trinidad tree so it looks like the ADF Faces
tree. Looks good so far, but I am struggeling with the folder icon. I
downloaded Trinidad 1.2.5 (the latest release). Looking at the
treeRenderer and the SkinSelector class, it appears (as I understand the
code) that the tree folder icon is composed as
af|tree::node-icon:-collapsed{content:url('/skins/oracle/images/tfold.gif');}
af|tree::node-icon:-expanded{content:url('/skins/oracle/images/tfold.gif');}
This doesn't work and also looks strange. Can whoever built the
treeRenderer have a look to verify if its me or the code?
Frank
--
Frank Nimphius
Principal Product Manager
Application Development Tools
Oracle Corporation
mail: [EMAIL PROTECTED]
phone:+49 2058 782481
--
Cristi Toth
-
Codebeat
www.codebeat.ro
--
Frank Nimphius
Principal Product Manager
Application Development Tools
Oracle Corporation
mail: [EMAIL PROTECTED]
phone:+49 2058 782481
--
Cristi Toth
-
Codebeat
www.codebeat.ro
--
Frank Nimphius
Principal Product Manager
Application Development Tools
Oracle Corporation
mail: [EMAIL PROTECTED]
phone:+49 2058 782481
Re: Bug in FacesConfigurator.feedClassloaderConfigurations()?
Can you please post your logging-output? You should see info-messages starting with: Reading config with log-level info on FacesConfigurator.java. regards, Martin On Jan 29, 2008 9:39 PM, Val Blant [EMAIL PROTECTED] wrote: Hello. I just found something that I think is a bug in FacesConfigurator.feedClassloaderConfigurations() algorithm. Please correct me if I am wrong. The problem I see is this: ClassUtils.getResources(FACES_CONFIG_RESOURCE, this) will return an iterator over all META-INF/faces-config.xml resources that were found. The search is carried out by starting at WebAppClassLoader and making an Enumeration of all resources with the given name, that WebAppClassLoader and all its parents see. The jars placed into WEB-INF/lib will be seen by the WebAppClassLoader AND AppClassLoader, thus resulting in the same jars (the ones that have META-INF/faces-config.xml) being placed on the list twice. This is fine, but things break when FacesConfigurator.feedClassloaderConfigurations() does not check for duplicate URLs and just blindly registers everything from these jars twice. I noticed this b/c all of my phase listeners were executing twice due to being registered with the lifecycle twice. Is this a bug, or have I configured something wrong? Val -- View this message in context: http://www.nabble.com/Bug-in-FacesConfigurator.feedClassloaderConfigurations%28%29--tp15168891p15168891.html Sent from the My Faces - Dev mailing list archive at Nabble.com. -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
[jira] Created: (TRINIDAD-928) Skinning developer guide needs to be update about how to put a skin into a JAR file
Skinning developer guide needs to be update about how to put a skin into a JAR file --- Key: TRINIDAD-928 URL: https://issues.apache.org/jira/browse/TRINIDAD-928 Project: MyFaces Trinidad Issue Type: Improvement Components: Documentation Affects Versions: 1.2.5-core Reporter: Frank Nimphius According to the current developer guide. the trinidad-skin.xml file and its associated skin resources can go into a JAR file for deployment. I searched in Google but couldn't find any good hint on what exactly the configuration steps are (e.g. if I need to add extra tags into the trinidad-skin.xml file or if there is anything to keep in mind when referenceing images. Also, where in relation to trinidad-skin.xml do the CSS and image file have to be located -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [Trinidad] add method to get an application scoped concurrentMap to RequestContext (TRINIDAD-926)
Excellent! we should definitely get this into the impl as well ;)
regards,
Martin
On Jan 29, 2008 8:08 PM, Gabrielle Crawford [EMAIL PROTECTED]
wrote:
Oops, and _getClassLoader
private ClassLoader _getClassLoader()
{
return Thread.currentThread().getContextClassLoader();
}
Gabrielle Crawford wrote:
Here's the implementation I have so far in
org.apache.myfaces.trinidadinternal.context.RequestContextImpl
@Override
public ConcurrentMapString, Object
getApplicationScopedConcurrentMap()
{
ClassLoader cl = _getClassLoader();
ConcurrentMapString, Object classMap = _applicationMaps.get(cl);
if (classMap == null)
{
ConcurrentMapString, Object newClassMap = new
ConcurrentHashMapString, Object();
ConcurrentMapString, Object oldClassMap =
_applicationMaps.putIfAbsent(cl, newClassMap);
classMap = ((oldClassMap != null)? oldClassMap : newClassMap);
assert(classMap != null);
}
return classMap;
}
@SuppressWarnings({CollectionWithoutInitialCapacity})
private static final ConcurrentMapClassLoader,
ConcurrentMapString, Object _applicationMaps =
new ConcurrentHashMapClassLoader, ConcurrentMapString,
Object();
Martin Marinschek wrote:
where will this map be stored?
regards,
Martin
On Jan 29, 2008 6:38 AM, Matthias Wessendorf [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED] wrote:
+1
On Jan 29, 2008 2:48 AM, Blake Sullivan
[EMAIL PROTECTED] mailto:[EMAIL PROTECTED]
wrote:
I'm, of course, in favor.
-- Blake Sullivan
Gabrielle Crawford wrote:
Hi,
In case anyone filtered away the [jira] message.
I'd like to add the method described below to the
requestContext.
Comments? Objections?
Thanks,
Gab
Original Message
add method to get an application scoped concurrentMap to
RequestContext
---
Key: TRINIDAD-926
URL:
https://issues.apache.org/jira/browse/TRINIDAD-926
Project: MyFaces Trinidad
Issue Type: Improvement
Affects Versions: 1.2.5-core, 1.0.5-core
Reporter: Gabrielle Crawford
Assignee: Gabrielle Crawford
Priority: Minor
This started with Trin Issue 891
https://issues.apache.org/jira/browse/TRINIDAD-891
To avoid the locking in the class loader we'd like to store a
map of
name-class per app. However the external context app map calls
through to the ServletContext. The Servlet specification
doesn't
specify whether the ServletContext performs any locking on the
ServletContext attributes and the ServletContext doesn't
expose the
necessary methods for efficient concurrent access
(essentially the
operations exposed on ConcurrentMap) necessary to work
efficiently in
many cases even if the ServletContext didn't need to perform
locking
on reads. The result is that the ExternalContext's
ApplicationMap
can't implement ConcurrentMap.
We'd like to add a method to the RequestContext to get an
application
scoped concurrent map. This would not call through to the
servlet
context. The api proposed is this:
/**
* Gets a per application concurrent map. There is no
synchronization
* with ServletContext attributes.
*/
public abstract ConcurrentMapString, Object
getApplicationScopedConcurrentMap();
--
Matthias Wessendorf
further stuff:
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
mail: matzew-at-apache-dot-org
--
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
--
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
Re: Bug in FacesConfigurator.feedClassloaderConfigurations()?
The log shows that the configs are read twice: [2008-01-29 18:43:55,145] INFO myfaces.config.FacesConfigurator:159 - Reading standard config org/apache/myfaces/resource/standard-faces-config.xml [2008-01-29 18:43:55,226] INFO myfaces.config.FacesConfigurator:379 - Reading config jar:file:/home/val/workspaces/workspace.v2/OPSWeb/src/main/webapp/WEB-INF/lib/acegi-jsf.jar!/META-INF/faces-config.xml [2008-01-29 18:43:55,237] INFO myfaces.config.FacesConfigurator:379 - Reading config jar:file:/home/val/workspaces/workspace.v2/OPSWeb/src/main/webapp/WEB-INF/lib/jsf-facelets-1.1.11.jar!/META-INF/faces-config.xml [2008-01-29 18:43:55,245] INFO myfaces.config.FacesConfigurator:379 - Reading config jar:file:/home/val/workspaces/workspace.v2/OPSWeb/src/main/webapp/WEB-INF/lib/richfaces-3.0.0.jar!/META-INF/faces-config.xml [2008-01-29 18:43:55,330] INFO myfaces.config.FacesConfigurator:379 - Reading config jar:file:/home/val/workspaces/workspace.v2/OPSWeb/src/main/webapp/WEB-INF/lib/ajax4jsf-1.1.0.jar!/META-INF/faces-config.xml [2008-01-29 18:43:55,345] INFO myfaces.config.FacesConfigurator:379 - Reading config jar:file:/home/val/workspaces/workspace.v2/OPSWeb/src/main/webapp/WEB-INF/lib/tomahawk-1.1.5.jar!/META-INF/faces-config.xml [2008-01-29 18:43:55,384] INFO myfaces.config.FacesConfigurator:379 - Reading config jar:file:/home/val/workspaces/workspace.v2/OPSWeb/src/main/webapp/WEB-INF/lib/jenia4faces-dynamic_1.2.1.jar!/META-INF/faces-config.xml [2008-01-29 18:43:55,401] INFO myfaces.config.FacesConfigurator:379 - Reading config jar:file:/home/val/workspaces/workspace.v2/OPSWeb/src/main/webapp/WEB-INF/lib/jenia4faces-popup_1.2.1.jar!/META-INF/faces-config.xml [2008-01-29 18:43:55,410] INFO myfaces.config.FacesConfigurator:379 - Reading config jar:file:/home/val/workspaces/workspace.v2/OPS/shale-remoting-1.0.4.jar!/META-INF/faces-config.xml [2008-01-29 18:43:55,416] INFO myfaces.config.FacesConfigurator:379 - Reading config jar:file:/home/val/workspaces/workspace.v2/OPSWeb/src/main/webapp/WEB-INF/lib/jsf-message-decorator-1.2.jar!/META-INF/faces-config.xml [2008-01-29 18:43:55,422] INFO myfaces.config.FacesConfigurator:379 - Reading config jar:file:/home/val/workspaces/workspace.v2/OPSWeb/src/main/webapp/WEB-INF/lib/tomahawk-sandbox-1.1.7-SNAPSHOT.jar!/META-INF/faces-config.xml [2008-01-29 18:43:55,518] INFO myfaces.config.FacesConfigurator:379 - Reading config jar:file:/home/val/workspaces/workspace.v2/OPSWeb/src/main/webapp/WEB-INF/lib/jenia4faces-popup_1.2.1.jar!/META-INF/faces-config.xml [2008-01-29 18:43:55,583] INFO myfaces.config.FacesConfigurator:379 - Reading config jar:file:/home/val/workspaces/workspace.v2/OPSWeb/src/main/webapp/WEB-INF/lib/tomahawk-1.1.5.jar!/META-INF/faces-config.xml [2008-01-29 18:43:55,612] INFO myfaces.config.FacesConfigurator:379 - Reading config jar:file:/home/val/workspaces/workspace.v2/OPSWeb/src/main/webapp/WEB-INF/lib/jenia4faces-dynamic_1.2.1.jar!/META-INF/faces-config.xml [2008-01-29 18:43:55,621] INFO myfaces.config.FacesConfigurator:379 - Reading config jar:file:/home/val/workspaces/workspace.v2/OPSWeb/src/main/webapp/WEB-INF/lib/jsf-facelets-1.1.11.jar!/META-INF/faces-config.xml [2008-01-29 18:43:55,633] INFO myfaces.config.FacesConfigurator:379 - Reading config jar:file:/home/val/workspaces/workspace.v2/OPSWeb/src/main/webapp/WEB-INF/lib/tomahawk-sandbox-1.1.7-SNAPSHOT.jar!/META-INF/faces-config.xml [2008-01-29 18:43:55,748] INFO myfaces.config.FacesConfigurator:379 - Reading config jar:file:/home/val/workspaces/workspace.v2/OPSWeb/src/main/webapp/WEB-INF/lib/ajax4jsf-1.1.0.jar!/META-INF/faces-config.xml [2008-01-29 18:43:55,781] INFO myfaces.config.FacesConfigurator:379 - Reading config jar:file:/home/val/workspaces/workspace.v2/OPSWeb/src/main/webapp/WEB-INF/lib/richfaces-3.0.0.jar!/META-INF/faces-config.xml [2008-01-29 18:43:55,941] INFO myfaces.config.FacesConfigurator:379 - Reading config jar:file:/home/val/workspaces/workspace.v2/OPSWeb/src/main/webapp/WEB-INF/lib/jsf-message-decorator-1.2.jar!/META-INF/faces-config.xml [2008-01-29 18:43:55,949] INFO myfaces.config.FacesConfigurator:379 - Reading config jar:file:/home/val/workspaces/workspace.v2/OPSWeb/src/main/webapp/WEB-INF/lib/acegi-jsf.jar!/META-INF/faces-config.xml [2008-01-29 18:43:55,956] INFO myfaces.config.FacesConfigurator:540 - Reading config /WEB-INF/faces-config.xml Martin Marinschek wrote: Can you please post your logging-output? You should see info-messages starting with: Reading config with log-level info on FacesConfigurator.java. regards, Martin On Jan 29, 2008 9:39 PM, Val Blant [EMAIL PROTECTED] wrote: Hello. I just found something that I think is a bug in FacesConfigurator.feedClassloaderConfigurations() algorithm. Please correct me if I am wrong. The problem I see is this: ClassUtils.getResources(FACES_CONFIG_RESOURCE, this) will return an iterator over all META-INF/faces-config.xml resources
