Re: Shale Annotations
I personally don't think it's worth it. If someone wants to use annotations, I usually point them to a third party library (like Seam or Orchestra) or tell them to be patient and wait for JSF 2. Especially since it should be possible to run JSF 2 on current web containers like Tomcat 6, my idea is that migration goes faster and becomes easier than with Java EE 5. Regards, Jan-Kees 2009/7/8 Mario Ivankovits ma...@ops.co.at: Hmmm … it might be worth looking at using Orchestra without Spring. Guice is not an option for your clients either, is it? If you do not use Spring, you also do not use its persistence capabilities ;-) So then, using a CGLIB based (or whatever enhancer lib) approach which simply enhances the beans in a way which is required by Orchestra might be enough. Sure, we can not yet use the faces-config.xml to configure the managed beans for Orchestra. But probably we can introduce something like a orchestra-config.xml for the scope and managed bean configuration. @community: What do you think? Is it worth it? Ciao, Mario Von: Kito Mann [mailto:kito.m...@virtua.com] Gesendet: Dienstag, 07. Juli 2009 23:45 An: MyFaces Development Betreff: Re: Shale Annotations The problem with using Orchestra is that it requires Spring, which is an extra framework that some organizations don't necessarily need. Although JSF managed beans aren't that great, sometimes they're a better choice than integrating Spring into the project. --- Kito D. Mann -- Author, JavaServer Faces in Action http://twitter.com/kito99 http://twitter.com/jsfcentral http://www.virtua.com - JSF/Java EE consulting, training, and mentoring http://www.JSFCentral.com - JavaServer Faces FAQ, news, and info +1 203-404-4848 x3 On Tue, Jul 7, 2009 at 4:46 PM, Bruno Aranda brunoara...@gmail.com wrote: Hi, What about just using MyFaces Orchestra? It does many of the thing the shale tiger extensions used to do (and even includes lots of useful features). You have the Orchestra view controller annotations and if you want more annotations, you can use the Spring ones to register backing beans and so on... Cheers, Bruno 2009/7/7 Kito Mann kito.m...@virtua.com: Hello everyone, I know that MyFaces is in the process of swallowing Shale Test. What do you guys think about swallowing Shale Annotations, too? I know it's a dead-end add-on considering JSF 2, but I run into enough clients that aren't going to be using JSF 2 for a lng time, and could use annotation support today. Given Shale's retired status, they're never going to touch it. Thoughts? --- Kito D. Mann -- Author, JavaServer Faces in Action http://twitter.com/kito99 http://twitter.com/jsfcentral http://www.virtua.com - JSF/Java EE consulting, training, and mentoring http://www.JSFCentral.com - JavaServer Faces FAQ, news, and info +1 203-404-4848 x3
[jira] Created: (TOBAGO-773) tc:sheet should auto-sort the data according to sheetState at model-reload
tc:sheet should auto-sort the data according to sheetState at model-reload -- Key: TOBAGO-773 URL: https://issues.apache.org/jira/browse/TOBAGO-773 Project: MyFaces Tobago Issue Type: New Feature Components: Core Reporter: Matthias Wronka The Szenario is a page with a filter-panel and a sheet which displays the filtered data. The sheet contains sortable columns. When the filter is changed and the data reloaded the data should be displayed in the previously chosen order. By now only the sheetState-Information is preserved but the data is displayed in the order it is loaded from the database/backend. It would be nice to have an attribute like auto-sort in tc:sheet or an api to have to data sorted. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[trinidad] Trinidad sorting including checkboxes in tr:table
Hi Jan, I am just forwarding your issue to the MyFaces list, where you will get a better and faster response. I don't have time to look into this now. Cheers, Bruno -- Forwarded message -- From: Jan Tepper ven...@mail.uni-paderborn.de Date: 2009/7/8 Subject: Trinidad sorting including checkboxes in tr:table To: bara...@apache.org Hello Mr. Aranda, I do have a problem about amazing Trinidad. when i sort a column in tr:table all works fine, but if i use multiselection, the selected rows are not sorted. Here an example of my problem: here a simple example: ( 0 : unselected checkbox, X : selected checkbox) tr:table has one column and multiselection is set, first checkbox is checked: X | A O | B O | C after sorting in descending order it looks like this, where rows are sorted and checkbox-selection is ignored. X | C O | B 0 | A this is, what i need, where rowKeySet is sorted as well : 0 | C O | B X | A i've searched through many sites, but did not find any hint. it would be a great help, if you could give me a hint, how to solve this problem. Sorry for bothering you, but i don't know how to solve. thanks a lot. jan tepper _ Shah Mat - Computerspielprojekt der Universität Paderborn ComOff Coding Client Team www.wdr.de/mediathek/html/regional/2009/05/04/lokalzeit-owl-computer-spiel.xml (Stand : 03/2009) ven...@upb.de
Re: [VOTE] jul instead of commons-logging
Maybe we should stop the voting process +1 (due to several reasons) new suggestion: if a sub-project would like to switch to jul, we don't need a vote (since there is no new dependency). if a sub-project would like to switch e.g. to slf4j, we have to vote (due to the new logging-framework dependency). regards, gerhard http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces 2009/6/15 Werner Punz werner.p...@gmail.com Bernd Bohmann schrieb: Hi, i think many users are still using log4j in their projects. Switching to jul instead of slf4j would cause more consequences for the user. But maybe I'm wrong. Regards Bernd Maybe we should stop the voting process for now until we have done further research on the implications. My personal preferrence would be simply to get rid of another pesky dependency instead of just switching dependencies hence I voted +1 for JUL!
[jira] Created: (MYFACES-2268) Add support for registering client behavior renderers
Add support for registering client behavior renderers - Key: MYFACES-2268 URL: https://issues.apache.org/jira/browse/MYFACES-2268 Project: MyFaces Core Issue Type: Task Components: JSR-314 Affects Versions: 2.0.0-alpha Reporter: Curtiss Howard Add support for registering client behavior renderers via @FacesBehaviorRenderer and client-behavior-renderer. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (MYFACES-2268) Add support for registering client behavior renderers
[ https://issues.apache.org/jira/browse/MYFACES-2268?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Curtiss Howard updated MYFACES-2268: Status: Patch Available (was: Open) Add support for registering client behavior renderers - Key: MYFACES-2268 URL: https://issues.apache.org/jira/browse/MYFACES-2268 Project: MyFaces Core Issue Type: Task Components: JSR-314 Affects Versions: 2.0.0-alpha Reporter: Curtiss Howard Attachments: MYFACES-2268.patch Add support for registering client behavior renderers via @FacesBehaviorRenderer and client-behavior-renderer. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [VOTE] jul instead of commons-logging
+1 for Gerhard new suggestion. On Wed, Jul 8, 2009 at 12:54 PM, Gerhard Petracek gerhard.petra...@gmail.com wrote: Maybe we should stop the voting process +1 (due to several reasons) new suggestion: if a sub-project would like to switch to jul, we don't need a vote (since there is no new dependency). if a sub-project would like to switch e.g. to slf4j, we have to vote (due to the new logging-framework dependency). regards, gerhard http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces 2009/6/15 Werner Punz werner.p...@gmail.com Bernd Bohmann schrieb: Hi, i think many users are still using log4j in their projects. Switching to jul instead of slf4j would cause more consequences for the user. But maybe I'm wrong. Regards Bernd Maybe we should stop the voting process for now until we have done further research on the implications. My personal preferrence would be simply to get rid of another pesky dependency instead of just switching dependencies hence I voted +1 for JUL! -- Hazem Ahmed Saleh Ahmed Author of (The Definitive Guide to Apache MyFaces and Facelets): http://www.amazon.com/Definitive-Guide-Apache-MyFaces-Facelets/dp/1590597370 Web blog: http://www.jroller.com/page/HazemBlog [Web 2.0] Google Maps Integration with JSF: http://code.google.com/p/gmaps4jsf/ http://www.theserverside.com/tt/articles/article.tss?l=IntroductiontoGMaps4JSF
Re: [VOTE] jul instead of commons-logging
I agree with Hazem, +1 for Gerhards suggestion. /Jan-Kees 2009/7/8 Hazem Saleh haz...@apache.org: +1 for Gerhard new suggestion. On Wed, Jul 8, 2009 at 12:54 PM, Gerhard Petracek gerhard.petra...@gmail.com wrote: Maybe we should stop the voting process +1 (due to several reasons) new suggestion: if a sub-project would like to switch to jul, we don't need a vote (since there is no new dependency). if a sub-project would like to switch e.g. to slf4j, we have to vote (due to the new logging-framework dependency). regards, gerhard http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces 2009/6/15 Werner Punz werner.p...@gmail.com Bernd Bohmann schrieb: Hi, i think many users are still using log4j in their projects. Switching to jul instead of slf4j would cause more consequences for the user. But maybe I'm wrong. Regards Bernd Maybe we should stop the voting process for now until we have done further research on the implications. My personal preferrence would be simply to get rid of another pesky dependency instead of just switching dependencies hence I voted +1 for JUL! -- Hazem Ahmed Saleh Ahmed Author of (The Definitive Guide to Apache MyFaces and Facelets): http://www.amazon.com/Definitive-Guide-Apache-MyFaces-Facelets/dp/1590597370 Web blog: http://www.jroller.com/page/HazemBlog [Web 2.0] Google Maps Integration with JSF: http://code.google.com/p/gmaps4jsf/ http://www.theserverside.com/tt/articles/article.tss?l=IntroductiontoGMaps4JSF
[jira] Created: (MYFACES-2269) StreamingAddResource introduces memory leak
StreamingAddResource introduces memory leak --- Key: MYFACES-2269 URL: https://issues.apache.org/jira/browse/MYFACES-2269 Project: MyFaces Core Issue Type: Bug Affects Versions: 1.1.7 Reporter: Philipp Schoepf org.apache.myfaces.component.html.util.StreamingAddResource creates a Thread named CleanupThread. This causes a memory during development when an application is uninstalled/installed during development. The thread is unmanaged to the server and will hold references to the application classloader, even if the application is uninstalled from the server. The same problem will occur in production environments that use hot deploy features. I don't know if this does also affect 1.2.x stream. Suggestion: Please include a shutdown hook that can be used to stop the thread during application shutdown (via ContextLoaderListener or similar). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (TRINIDAD-1529) Enhanced support for tag doc generation to support screenshots and better formatting of example code snippets
Enhanced support for tag doc generation to support screenshots and better formatting of example code snippets - Key: TRINIDAD-1529 URL: https://issues.apache.org/jira/browse/TRINIDAD-1529 Project: MyFaces Trinidad Issue Type: Improvement Components: Plugins Reporter: Maria Kaval This JIRA is to support having a tag to mark screenshots within the tag doc xml. This will ensure that all pages have the same formatting for screenshots (e.g. the header text will be the same, one can easily skin the section, and the screenshots will appear at the same section of the tag doc, etc). I suggest modifying the plugin to understand: mfp:screenshot mfp:image HERE YOU PLACE YOUR IMG TAGS/mfp:image mfp:description HERE YOU PLACE THE CAPTION THAT GOES WITH YOUR IMG TAG /mfp:image-description /mfp:screen-shot A real-world example would look like: mfp:screenshot mfp:image ![CDATA[ img src=../images/inputDate.png alt=inputDate screenshot/img ]] /mfp:image mfp:description inputDate component as shown when rendered in a simple form /mfp:description /mfp:screenshot This JIRA also covers modifying the plugin for how it generates the mfp:example tag. Currently mfp:example outputs bold text at the end of the description with Example:. The issue is that depending on what text is towards the end of the long description, sometimes it appears the Example is for something very specific to that page instead of generic to the component. I've therefore modifed the plugin to create a new section when mfp:example tag is encountered. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (TRINIDAD-1530) The onsubmit function of tr:form is called after a client side validation error occurs and the form is not submitted.
The onsubmit function of tr:form is called after a client side validation error occurs and the form is not submitted. - Key: TRINIDAD-1530 URL: https://issues.apache.org/jira/browse/TRINIDAD-1530 Project: MyFaces Trinidad Issue Type: Bug Affects Versions: 1.2.11-core Reporter: Bernd Bohmann Documentation of the onsubmit attribute of tr:form: Javascript code to be called when the form is submitted. I don't expect that this code is called if a client side validation error occurs and the form is not submitted. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (TRINIDAD-1529) Enhanced support for tag doc generation to support screenshots and better formatting of example code snippets
[ https://issues.apache.org/jira/browse/TRINIDAD-1529?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maria Kaval updated TRINIDAD-1529: -- Status: Patch Available (was: Open) Enhanced support for tag doc generation to support screenshots and better formatting of example code snippets - Key: TRINIDAD-1529 URL: https://issues.apache.org/jira/browse/TRINIDAD-1529 Project: MyFaces Trinidad Issue Type: Improvement Components: Plugins Reporter: Maria Kaval This JIRA is to support having a tag to mark screenshots within the tag doc xml. This will ensure that all pages have the same formatting for screenshots (e.g. the header text will be the same, one can easily skin the section, and the screenshots will appear at the same section of the tag doc, etc). I suggest modifying the plugin to understand: mfp:screenshot mfp:image HERE YOU PLACE YOUR IMG TAGS/mfp:image mfp:description HERE YOU PLACE THE CAPTION THAT GOES WITH YOUR IMG TAG /mfp:image-description /mfp:screen-shot A real-world example would look like: mfp:screenshot mfp:image ![CDATA[ img src=../images/inputDate.png alt=inputDate screenshot/img ]] /mfp:image mfp:description inputDate component as shown when rendered in a simple form /mfp:description /mfp:screenshot This JIRA also covers modifying the plugin for how it generates the mfp:example tag. Currently mfp:example outputs bold text at the end of the description with Example:. The issue is that depending on what text is towards the end of the long description, sometimes it appears the Example is for something very specific to that page instead of generic to the component. I've therefore modifed the plugin to create a new section when mfp:example tag is encountered. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [VOTE] SVN structure change (was: Re: [MyFaces CORE] SVN layout (was: Re: [source control] git and the ASF ...))
Hi Myfaces core 1.2.7 and 1.1.7 were released. So we can close this vote and make the necessary changes. Just to note it, after reading all previous emails the suggested layout is this: /trunk - 2.0 /branches/1.1.x /branches/1.2.x If no objections I'll do the necessary changes on svn (note that to do this change we need to update nightly build configuration and I can't help with that). regards Leonardo Uribe 2009/5/28 Simon Lessard simon.lessar...@gmail.com +1 On Thu, May 28, 2009 at 2:23 AM, Matthias Wessendorf mat...@apache.orgwrote: sure! On Thu, May 28, 2009 at 6:34 AM, Leonardo Uribe lu4...@gmail.com wrote: +1, but just a small suggestion. Right now I'm running the necessary steps for release myfaces core 1.2.7, core 1.1.7, so I would like if it is possible to delay this change after the release. regards Leonardo Uribe 2009/5/27 Cagatay Civici cagatay.civ...@gmail.com +1 for sure On Wed, May 27, 2009 at 8:53 AM, Bruno Aranda brunoara...@gmail.com wrote: +1 sounds good to me 2009/5/27 Matthias Wessendorf mat...@apache.org: so, there are no objections in making the MyFaces 2.0 efforts become trunk ? -Matthias On Fri, May 22, 2009 at 9:10 PM, Bernd Bohmann bernd.bohm...@atanion.com wrote: Hello, +1 I would prefer /trunk - 2.0 /branches/myfaces-1.1.x /branches/myfaces-1.2.x because we are not using cvs anymore and the path already contains http://svn.apache.org/repos/asf/myfaces/core/ maybe we can omit the 'myfaces' in the branch name. Regards Bernd On Fri, May 22, 2009 at 5:27 PM, Matthias Wessendorf mat...@apache.org wrote: actually, I agree with Bernd. For the following layout: /trunk - 2.0 /branches/myfaces_1_1_x /branches/myfaces_1_2_x Two reasons for way making 2.0 trunk: -most current development is on-going in 2.0 (new spec) -most commits are going to the 2.0 branch (so, let's make it trunk) So, I am +1 on the above svn layout -Matthias On Sat, May 16, 2009 at 1:04 PM, Matthias Wessendorf mat...@apache.org wrote: from Bernd, on a different thread: Hello, I would suggest following layout 1.1.x branch/1.1.x 1.2.x branch/1.2.x 2.0.x trunk because the 2.0.x version is in development the other branches are only in bugfix state. On Fri, May 15, 2009 at 1:13 PM, Werner Punz werner.p...@gmail.com wrote: Matthias Wessendorf schrieb: Hi, ... Ok, I filed this: https://issues.apache.org/jira/browse/INFRA-2053 maybe we should also think about making the JSF 1.1.x stuff a branch ... (since we already work on 2.0.x) what do people think if the 1.2 stuff becomes trunk And the following efforts are on a branch: -2.0.x -1.1.x +1 -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf
MyFaces Core + Trinidad + Facelets in OSGi container
Hi I recently made some modifications to MyFaces Core and MyFaces Trinidad to get it running in an OSGi container (Equinox) together with Facelets. I wonder if there is any interest in adding bundle metadata to MyFaces Core and Trinidad to make them runnable in an OSGi environment? If so, I could finalize my modifications and submit a patch with the necessary changes. Basically, the changes include: - adding bundle information in MANIFEST.MF (uses Maven bundle plugin) - assure that classes and resources are loaded with proper class loaders The changes to MyFaces core are minor, e.g. adding a bundle activator and small modifications to ClassUtil for class loading. Modifications to Trinidad comprise a systematic use of ClassLoaderUtils to load classes and resources. Currently, often Thread.currentThread.getContextClassLoader() is used directly, which doesn't work well in an OSGi environment. WDYT? - Felix
Re: MyFaces Core + Trinidad + Facelets in OSGi container
Hi +1 regards Leonardo Uribe Am 8. Juli 2009 23:22 schrieb Felix Röthenbacher froethenbac...@apache.org : Hi I recently made some modifications to MyFaces Core and MyFaces Trinidad to get it running in an OSGi container (Equinox) together with Facelets. I wonder if there is any interest in adding bundle metadata to MyFaces Core and Trinidad to make them runnable in an OSGi environment? If so, I could finalize my modifications and submit a patch with the necessary changes. Basically, the changes include: - adding bundle information in MANIFEST.MF (uses Maven bundle plugin) - assure that classes and resources are loaded with proper class loaders The changes to MyFaces core are minor, e.g. adding a bundle activator and small modifications to ClassUtil for class loading. Modifications to Trinidad comprise a systematic use of ClassLoaderUtils to load classes and resources. Currently, often Thread.currentThread.getContextClassLoader() is used directly, which doesn't work well in an OSGi environment. WDYT? - Felix
Re: [VOTE] SVN structure change (was: Re: [MyFaces CORE] SVN layout (was: Re: [source control] git and the ASF ...))
that would be great ! Thx Leo! -Matthias On Thu, Jul 9, 2009 at 4:24 AM, Leonardo Uribelu4...@gmail.com wrote: Hi Myfaces core 1.2.7 and 1.1.7 were released. So we can close this vote and make the necessary changes. Just to note it, after reading all previous emails the suggested layout is this: /trunk - 2.0 /branches/1.1.x /branches/1.2.x If no objections I'll do the necessary changes on svn (note that to do this change we need to update nightly build configuration and I can't help with that). regards Leonardo Uribe 2009/5/28 Simon Lessard simon.lessar...@gmail.com +1 On Thu, May 28, 2009 at 2:23 AM, Matthias Wessendorf mat...@apache.org wrote: sure! On Thu, May 28, 2009 at 6:34 AM, Leonardo Uribe lu4...@gmail.com wrote: +1, but just a small suggestion. Right now I'm running the necessary steps for release myfaces core 1.2.7, core 1.1.7, so I would like if it is possible to delay this change after the release. regards Leonardo Uribe 2009/5/27 Cagatay Civici cagatay.civ...@gmail.com +1 for sure On Wed, May 27, 2009 at 8:53 AM, Bruno Aranda brunoara...@gmail.com wrote: +1 sounds good to me 2009/5/27 Matthias Wessendorf mat...@apache.org: so, there are no objections in making the MyFaces 2.0 efforts become trunk ? -Matthias On Fri, May 22, 2009 at 9:10 PM, Bernd Bohmann bernd.bohm...@atanion.com wrote: Hello, +1 I would prefer /trunk - 2.0 /branches/myfaces-1.1.x /branches/myfaces-1.2.x because we are not using cvs anymore and the path already contains http://svn.apache.org/repos/asf/myfaces/core/ maybe we can omit the 'myfaces' in the branch name. Regards Bernd On Fri, May 22, 2009 at 5:27 PM, Matthias Wessendorf mat...@apache.org wrote: actually, I agree with Bernd. For the following layout: /trunk - 2.0 /branches/myfaces_1_1_x /branches/myfaces_1_2_x Two reasons for way making 2.0 trunk: -most current development is on-going in 2.0 (new spec) -most commits are going to the 2.0 branch (so, let's make it trunk) So, I am +1 on the above svn layout -Matthias On Sat, May 16, 2009 at 1:04 PM, Matthias Wessendorf mat...@apache.org wrote: from Bernd, on a different thread: Hello, I would suggest following layout 1.1.x branch/1.1.x 1.2.x branch/1.2.x 2.0.x trunk because the 2.0.x version is in development the other branches are only in bugfix state. On Fri, May 15, 2009 at 1:13 PM, Werner Punz werner.p...@gmail.com wrote: Matthias Wessendorf schrieb: Hi, ... Ok, I filed this: https://issues.apache.org/jira/browse/INFRA-2053 maybe we should also think about making the JSF 1.1.x stuff a branch ... (since we already work on 2.0.x) what do people think if the 1.2 stuff becomes trunk And the following efforts are on a branch: -2.0.x -1.1.x +1 -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf
[jira] Commented: (MYFACES-2268) Add support for registering client behavior renderers
[ https://issues.apache.org/jira/browse/MYFACES-2268?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12729048#action_12729048 ] Leonardo Uribe commented on MYFACES-2268: - committed components that needs to implement ClientBehaviorHolder Add support for registering client behavior renderers - Key: MYFACES-2268 URL: https://issues.apache.org/jira/browse/MYFACES-2268 Project: MyFaces Core Issue Type: Task Components: JSR-314 Affects Versions: 2.0.0-alpha Reporter: Curtiss Howard Attachments: MYFACES-2268.patch Add support for registering client behavior renderers via @FacesBehaviorRenderer and client-behavior-renderer. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: MyFaces Core + Trinidad + Facelets in OSGi container
Hey Felix, 2009/7/9 Felix Röthenbacher froethenbac...@apache.org: Hi I recently made some modifications to MyFaces Core and MyFaces Trinidad to get it running in an OSGi container (Equinox) together with Facelets. I wonder if there is any interest in adding bundle metadata to MyFaces Core and Trinidad to make them runnable in an OSGi environment? If so, I could finalize my modifications and submit a patch with the necessary changes. Basically, the changes include: - adding bundle information in MANIFEST.MF (uses Maven bundle plugin) - assure that classes and resources are loaded with proper class loaders The changes to MyFaces core are minor, e.g. adding a bundle activator and small modifications to ClassUtil for class loading. Modifications to Trinidad comprise a systematic use of ClassLoaderUtils to load classes and resources. Currently, often Thread.currentThread.getContextClassLoader() is used directly, which doesn't work well in an OSGi environment. you mean this this one, right ? org.apache.myfaces.trinidad.util.ClassLoaderUtils -M WDYT? - Felix -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf
Re: MyFaces Core + Trinidad + Facelets in OSGi container
Matthias Wessendorf schrieb: Hey Felix, 2009/7/9 Felix Röthenbacher froethenbac...@apache.org: Hi I recently made some modifications to MyFaces Core and MyFaces Trinidad to get it running in an OSGi container (Equinox) together with Facelets. I wonder if there is any interest in adding bundle metadata to MyFaces Core and Trinidad to make them runnable in an OSGi environment? If so, I could finalize my modifications and submit a patch with the necessary changes. Basically, the changes include: - adding bundle information in MANIFEST.MF (uses Maven bundle plugin) - assure that classes and resources are loaded with proper class loaders The changes to MyFaces core are minor, e.g. adding a bundle activator and small modifications to ClassUtil for class loading. Modifications to Trinidad comprise a systematic use of ClassLoaderUtils to load classes and resources. Currently, often Thread.currentThread.getContextClassLoader() is used directly, which doesn't work well in an OSGi environment. you mean this this one, right ? org.apache.myfaces.trinidad.util.ClassLoaderUtils Right. To keep it clean, both bundles (api and impl) need class loader utils to use their respective bundle class loader. The class loader utils decide if the bundle is running in an OSGi environment and if so, uses the bundle class loader. The implementation doesn't require a runtime dependency on OSGi classes when not running in an OSGi container. A special case is resource loading, especially the ones under META-INF as this package is not exported and therefore not accessible from other bundles. MyFaces Core and Trinidad need to access these resources from different bundles in order to configure faces. - Felix -M WDYT? - Felix
