Re: JavaOne podcast for JSF 2
Kito Mann schrieb: Hello everyone, Is anyone going to JavaOne next week who wants to do a podcast about MyFaces 2.0? Werner, Leonardo? Hia Kito, I am definitely not at J1, I am bound to austria and the surrounding countries for this year by a five months old baby... Werner
Re: JavaOne podcast for JSF 2
Kito Mann schrieb: Hello everyone, Is anyone going to JavaOne next week who wants to do a podcast about MyFaces 2.0? Werner, Leonardo? Maybe Simon Lessard is, I am not sure if Martin is, but I don´t think so. Werner
Myfaces 2.0 an javascript compression
Hello since I was asked yesterday. We have a concatenation and build module integrated into the myfaces 2.0 script compression! Since we are currently bound to the offical alpha release quality build plugin by maven it is bound to changes. If anyone wants to enable it (it is currently disabled by comments in the build process) turn off compression, I am currently adding the latest plugin changes, and i am fixing some minor javascript issues the yahoo compressor is choking on! So, concatenation currently works, compression will be fixed by me today! Werner
[jira] Reopened: (MYFACES-2172) Attach a javascript concatentation and compression part of jsf.js
[ https://issues.apache.org/jira/browse/MYFACES-2172?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Werner Punz reopened MYFACES-2172: -- There have to be added some minor adjustments, the compression plugin has changed some internal name for the YUI compressor and generally the compressor is way mor nitpicky regarding errors! Attach a javascript concatentation and compression part of jsf.js - Key: MYFACES-2172 URL: https://issues.apache.org/jira/browse/MYFACES-2172 Project: MyFaces Core Issue Type: New Feature Components: JSR-314 Environment: Maven Reporter: Werner Punz Assignee: Werner Punz Priority: Minor The spec only allows one jsf.js file for all jsf related javascript includes, we have to map all external and internal apis to this file via the maven build process and also compression has to be added to reduce the file size to the possible minimum. The maven javascript plugin allows both mechanisms via its compress and compile directives, we have to add this to our maven build process to be in line with the spec! -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (MYFACES-2172) Attach a javascript concatentation and compression part of jsf.js
[ https://issues.apache.org/jira/browse/MYFACES-2172?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Werner Punz resolved MYFACES-2172. -- Resolution: Fixed issue has been resolved with the last commit everything works now again! Attach a javascript concatentation and compression part of jsf.js - Key: MYFACES-2172 URL: https://issues.apache.org/jira/browse/MYFACES-2172 Project: MyFaces Core Issue Type: New Feature Components: JSR-314 Environment: Maven Reporter: Werner Punz Assignee: Werner Punz Priority: Minor The spec only allows one jsf.js file for all jsf related javascript includes, we have to map all external and internal apis to this file via the maven build process and also compression has to be added to reduce the file size to the possible minimum. The maven javascript plugin allows both mechanisms via its compress and compile directives, we have to add this to our maven build process to be in line with the spec! -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Myfaces 2.0 an javascript compression
Werner Punz schrieb: Hello since I was asked yesterday. We have a concatenation and build module integrated into the myfaces 2.0 script compression! Since we are currently bound to the offical alpha release quality build plugin by maven it is bound to changes. If anyone wants to enable it (it is currently disabled by comments in the build process) turn off compression, I am currently adding the latest plugin changes, and i am fixing some minor javascript issues the yahoo compressor is choking on! So, concatenation currently works, compression will be fixed by me today! Werner Ok guys it works now again, just uncomment in the main pom.xml and in the api pom.xml the sections dealing with the javascript compression and it should work. Never mind that the YUI compressor throws a load of warnings, most of them if not all of them are simply false, the YUI compressor seems to have become somewhat overreactive with its warnings, often showing unused vars in sections where they are clearly used! The final non compressed jsf file has 3000-4000 locs and the YUI compressor achieves 54% compression rate! The final file has currently 56 kbyte which is an acceptable size given that it does more things than the RI! Since we also have our own compression plugin, I have not enabled it due to not being able to get it working. I personally think in the long run we should go with the official compression plugin anyway, but I have somewhat of a stomach ache due to running an alpha quality plugin in our build process! Werner
Re: Myfaces 2.0 and javascript compression
Hi Werner, After removing the comments of !-- repository idCodehaus Snapshots/id urlhttp://snapshots.repository.codehaus.org//url snapshots enabledtrue/enabled /snapshots releases enabledfalse/enabled /releases /repository -- and !-- disabled for now must be enabled to enable javascript compression pluginRepository idCodehaus Snapshots/id urlhttp://snapshots.repository.codehaus.org//url snapshots enabledtrue/enabled /snapshots releases enabledtrue/enabled /releases /pluginRepository -- I still don't get any jsf.js neither in api not in impl. Can you please explain in more detail how this is meant to work, so I can try and debug it? Best regards, Ganesh Werner Punz schrieb: Werner Punz schrieb: Hello since I was asked yesterday. We have a concatenation and build module integrated into the myfaces 2.0 script compression! Since we are currently bound to the offical alpha release quality build plugin by maven it is bound to changes. If anyone wants to enable it (it is currently disabled by comments in the build process) turn off compression, I am currently adding the latest plugin changes, and i am fixing some minor javascript issues the yahoo compressor is choking on! So, concatenation currently works, compression will be fixed by me today! Werner Ok guys it works now again, just uncomment in the main pom.xml and in the api pom.xml the sections dealing with the javascript compression and it should work. Never mind that the YUI compressor throws a load of warnings, most of them if not all of them are simply false, the YUI compressor seems to have become somewhat overreactive with its warnings, often showing unused vars in sections where they are clearly used! The final non compressed jsf file has 3000-4000 locs and the YUI compressor achieves 54% compression rate! The final file has currently 56 kbyte which is an acceptable size given that it does more things than the RI! Since we also have our own compression plugin, I have not enabled it due to not being able to get it working. I personally think in the long run we should go with the official compression plugin anyway, but I have somewhat of a stomach ache due to running an alpha quality plugin in our build process! Werner
Re: Myfaces 2.0 and javascript compression
Hello you just did one pom.xml
you have tu uncomment the sections below in the pom.xml from the main
project then in the api pom.xml you have to uncomment following section,
and you should be set!
Werner
!--
plugins
javascript plugin adjusted to our build process
please do not delete this it is just disabled for now
plugin
artifactIdjavascript-maven-plugin/artifactId
groupIdorg.codehaus.mojo.javascript/groupId
extensionstrue/extensions
executions
execution
idcompile/id
goals
goalcompile/goal
/goals
phaseprocess-resources/phase
configuration
descriptor${basedir}/src/assembler/jsfscripts-compiler.xml/descriptor
/configuration
/execution
execution
idcompress/id
goals
goalcompress/goal
/goals
phaseprocess-resources/phase
configuration
scriptstarget/classes/META-INF/resources/javax/faces/ajax//scripts
compressoryahooUI/compressor
/configuration
/execution
/executions
configuration
sourceDirectorysrc/main/javascript/sourceDirectory
webappDirectory${basedir}/webappDirectory
outputDirectory${basedir}/target/classes/META-INF/resources/javax/faces/ajax//outputDirectory
/configuration
/plugin
--
Ganesh schrieb:
Hi Werner,
After removing the comments of
!--
repository
idCodehaus Snapshots/id
urlhttp://snapshots.repository.codehaus.org//url
snapshots
enabledtrue/enabled
/snapshots
releases
enabledfalse/enabled
/releases
/repository
--
and
!--
disabled for now must be enabled to enable javascript compression
pluginRepository
idCodehaus Snapshots/id
urlhttp://snapshots.repository.codehaus.org//url
snapshots
enabledtrue/enabled
/snapshots
releases
enabledtrue/enabled
/releases
/pluginRepository
--
I still don't get any jsf.js neither in api not in impl. Can you please
explain in more detail how this is meant to work, so I can try and debug
it?
Best regards,
Ganesh
Werner Punz schrieb:
Werner Punz schrieb:
Hello since I was asked yesterday.
We have a concatenation and build module integrated into the myfaces
2.0 script compression!
Since we are currently bound to the offical alpha release quality
build plugin by maven it is bound to changes.
If anyone wants to enable it (it is currently disabled by comments in
the build process) turn off compression, I am currently adding the
latest plugin changes, and i am fixing some minor javascript issues
the yahoo compressor is choking on!
So, concatenation currently works, compression will be fixed by me
today!
Werner
Ok guys it works now again, just uncomment in the main pom.xml and in
the api pom.xml the sections dealing with the javascript compression
and it should work.
Never mind that the YUI compressor throws a load of warnings, most of
them if not all of them are simply false, the YUI compressor seems to
have become somewhat overreactive with its warnings, often showing
unused vars in sections where they are clearly used!
The final non compressed jsf file has 3000-4000 locs and the YUI
compressor achieves 54% compression rate!
The final file has currently 56 kbyte which is an acceptable size
given that it does more things than the RI!
Since we also have our own compression plugin, I have not enabled it
due to not being able to get it working.
I personally think in the long run we should go with the official
compression plugin anyway, but I have somewhat of a stomach ache due to
running an alpha quality plugin in our build process!
Werner
Re: JavaOne podcast for JSF 2
nope. none of the are here. I also suggested Simon for the podcast :-) On Fri, Jun 5, 2009 at 3:22 AM, Werner Punz werner.p...@gmail.com wrote: Kito Mann schrieb: Hello everyone, Is anyone going to JavaOne next week who wants to do a podcast about MyFaces 2.0? Werner, Leonardo? Maybe Simon Lessard is, I am not sure if Martin is, but I don´t think so. Werner -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf
slf4j and myfaces
hello all, again the logging-framework topic :) there were several discussions about it and i'm not aware of an agreement. udo wrote [1]: replace commons-logging with slf4j as i know we agreed on using one logging framework dependency for all myfaces projects. if i remember correctly, most of us prefer slf4j. - i suggest to vote about using slf4j in all myfaces projects. (at least if a project is using an external logging framework.) regards, gerhard [1] http://www.nabble.com/Re%3A-Trinidad-vs-Tobago-p23884581.html
Re: slf4j and myfaces
yep, Trinidad uses its own and I am not entirely sure if it is easy to replace... (the logger is sorta wrapper/facade for the standard logger) On Fri, Jun 5, 2009 at 8:18 AM, Gerhard Petracekgerhard.petra...@gmail.com wrote: hello all, again the logging-framework topic :) there were several discussions about it and i'm not aware of an agreement. udo wrote [1]: replace commons-logging with slf4j as i know we agreed on using one logging framework dependency for all myfaces projects. if i remember correctly, most of us prefer slf4j. - i suggest to vote about using slf4j in all myfaces projects. (at least if a project is using an external logging framework.) regards, gerhard [1] http://www.nabble.com/Re%3A-Trinidad-vs-Tobago-p23884581.html -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf
AW: slf4j and myfaces
Hi! Could one please eloberate a little bit more in detail what the pros are of slf4j? Notice, I switched to it in our company project - but always using the commons-logging api and just used the slf4j-over-cl wrapper. This is something wich is possible for each and ever user of myfaces already, just by adjusting the depencendcies correctly. Lately I even switched to my own logging wrapper, but this is another story. In the end, everything still uses the cl API which is proven to work fine. (I created the org.apache.commons.logging package structure with my own classes - which for sure is not possible for myfaces!). I still think, that using the cl api is the best we can do for our users. If they then use cl as implementation - and if this is considered good - is another story, but nothing WE should anticipate. As far as I can say the cl api is rock solid, just the class-loader stuff is a pain. But (again AFAIK), slf4j does not solve it, it just does not deal with it. Before we start using any other logging api I'd suggest to build our own thin myfaces-logging wrapper where one then can easily plug in log4j, cl, jul (java utils ogging) or whatever - we do not even have to provide any other impl than for jul. As a plus, this then will remove a dependency - a dependency to any logging framework - which - in terms of dependencies can be considered as a good thing, no? Ciao, Mario Von: Gerhard Petracek [mailto:gerhard.petra...@gmail.com] Gesendet: Freitag, 05. Juni 2009 17:18 An: MyFaces Development Betreff: slf4j and myfaces hello all, again the logging-framework topic :) there were several discussions about it and i'm not aware of an agreement. udo wrote [1]: replace commons-logging with slf4j as i know we agreed on using one logging framework dependency for all myfaces projects. if i remember correctly, most of us prefer slf4j. - i suggest to vote about using slf4j in all myfaces projects. (at least if a project is using an external logging framework.) regards, gerhard [1] http://www.nabble.com/Re%3A-Trinidad-vs-Tobago-p23884581.html
[jira] Updated: (TRINIDAD-1499) Regression issues with jsp tag class generation from move to jsr276 metadata
[ https://issues.apache.org/jira/browse/TRINIDAD-1499?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bill Baggett updated TRINIDAD-1499: --- Status: Patch Available (was: Open) Regression issues with jsp tag class generation from move to jsr276 metadata Key: TRINIDAD-1499 URL: https://issues.apache.org/jira/browse/TRINIDAD-1499 Project: MyFaces Trinidad Issue Type: Bug Components: Build Affects Versions: 1.2.10-plugins Reporter: Bill Baggett In the move to the new jsr-276 metadata we missed a couple things with the generation of the jsp tag classes. First, we needed to check for the deprecated metadata element in the new structure because this is used in the jsp tag class generation. Second, the move from mfp:literal-onlytrue/mfp:literal-only to fmd:value-expressionPROHIBITED/fmd:value-expression wasn't handled in all cases. I had previously made a fix that checked for either the old way or the new way. The problem is that there were a couple places that I missed (ie jsp tag class generation). Instead of making a check for the old way and the new way in each place, I decided to put the fix at a lower level. There were 2 parts to this. First, undo the check I had made for the old way and the new way. Second, in the digester bean handler for the new way, I just set the property corresponding to the old way. That makes it transparent. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (TRINIDAD-1499) Regression issues with jsp tag class generation from move to jsr276 metadata
Regression issues with jsp tag class generation from move to jsr276 metadata Key: TRINIDAD-1499 URL: https://issues.apache.org/jira/browse/TRINIDAD-1499 Project: MyFaces Trinidad Issue Type: Bug Components: Build Affects Versions: 1.2.10-plugins Reporter: Bill Baggett In the move to the new jsr-276 metadata we missed a couple things with the generation of the jsp tag classes. First, we needed to check for the deprecated metadata element in the new structure because this is used in the jsp tag class generation. Second, the move from mfp:literal-onlytrue/mfp:literal-only to fmd:value-expressionPROHIBITED/fmd:value-expression wasn't handled in all cases. I had previously made a fix that checked for either the old way or the new way. The problem is that there were a couple places that I missed (ie jsp tag class generation). Instead of making a check for the old way and the new way in each place, I decided to put the fix at a lower level. There were 2 parts to this. First, undo the check I had made for the old way and the new way. Second, in the digester bean handler for the new way, I just set the property corresponding to the old way. That makes it transparent. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: slf4j and myfaces
@matthias: yes - that's the reason for my comment: ...external logging framework... @udo: imo we should discuss the logging topic before we have a release which already uses slf4j - especially the suggestion of mario sounds interesting. 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/5 Mario Ivankovits ma...@ops.co.at Hi! Could one please eloberate a little bit more in detail what the pros are of slf4j? Notice, I switched to it in our company project - but always using the commons-logging api and just used the slf4j-over-cl wrapper. This is something wich is possible for each and ever user of myfaces already, just by adjusting the depencendcies correctly. Lately I even switched to my own logging wrapper, but this is another story. In the end, everything still uses the cl API which is proven to work fine. (I created the org.apache.commons.logging package structure with my own classes - which for sure is not possible for myfaces!). I still think, that using the cl api is the best we can do for our users. If they then use cl as implementation - and if this is considered good - is another story, but nothing WE should anticipate. As far as I can say the cl api is rock solid, just the class-loader stuff is a pain. But (again AFAIK), slf4j does not solve it, it just does not deal with it. Before we start using any other logging api I'd suggest to build our own thin myfaces-logging wrapper where one then can easily plug in log4j, cl, jul (java utils ogging) or whatever - we do not even have to provide any other impl than for jul. As a plus, this then will remove a dependency - a dependency to any logging framework - which - in terms of dependencies can be considered as a good thing, no? Ciao, Mario *Von:* Gerhard Petracek [mailto:gerhard.petra...@gmail.com] *Gesendet:* Freitag, 05. Juni 2009 17:18 *An:* MyFaces Development *Betreff:* slf4j and myfaces hello all, again the logging-framework topic :) there were several discussions about it and i'm not aware of an agreement. udo wrote [1]: replace commons-logging with slf4j as i know we agreed on using one logging framework dependency for all myfaces projects. if i remember correctly, most of us prefer slf4j. - i suggest to vote about using slf4j in all myfaces projects. (at least if a project is using an external logging framework.) regards, gerhard [1] http://www.nabble.com/Re%3A-Trinidad-vs-Tobago-p23884581.html
Result (was Re: [VOTE] release of myfaces core 1.2.7)
Hi Thanks to all people who vote. We have 6 +1: Gerhard Petracek Grant Smith Cagatay Civici Bruno Aranda Matthias Wessendorf Leonardo Uribe So we can continue with the necessary steps to release myfaces core 1.2.7 regards Leonardo Uribe
Result (was Re: [VOTE] release of myfaces core 1.1.7)
Hi Thanks to all people who vote. We have 4 +1: Gerhard Petracek Matthias Wessendorf Bruno Aranda Leonardo Uribe So we can continue with the necessary steps to release myfaces core 1.1.7 regards Leonardo Uribe
Re: slf4j and myfaces
@mario: which logging frameworks would be supported by such a wrapper. i can just mention that there are logging frameworks out there which internally force an exception and statically use entry x of the call hierarchy - so such a wrapper would lead to wrong logging information. regards, gerhard (after reformulating the previous mail quite quickly the text wasn't perfect - but i think you know what i mean...) 2009/6/5 Gerhard Petracek gerhard.petra...@gmail.com @matthias: yes - that's the reason for my comment: ...external logging framework... @udo: imo we should discuss the logging topic before we have a release which already uses slf4j - especially the suggestion of mario sounds interesting. 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/5 Mario Ivankovits ma...@ops.co.at Hi! Could one please eloberate a little bit more in detail what the pros are of slf4j? Notice, I switched to it in our company project - but always using the commons-logging api and just used the slf4j-over-cl wrapper. This is something wich is possible for each and ever user of myfaces already, just by adjusting the depencendcies correctly. Lately I even switched to my own logging wrapper, but this is another story. In the end, everything still uses the cl API which is proven to work fine. (I created the org.apache.commons.logging package structure with my own classes - which for sure is not possible for myfaces!). I still think, that using the cl api is the best we can do for our users. If they then use cl as implementation - and if this is considered good - is another story, but nothing WE should anticipate. As far as I can say the cl api is rock solid, just the class-loader stuff is a pain. But (again AFAIK), slf4j does not solve it, it just does not deal with it. Before we start using any other logging api I'd suggest to build our own thin myfaces-logging wrapper where one then can easily plug in log4j, cl, jul (java utils ogging) or whatever - we do not even have to provide any other impl than for jul. As a plus, this then will remove a dependency - a dependency to any logging framework - which - in terms of dependencies can be considered as a good thing, no? Ciao, Mario *Von:* Gerhard Petracek [mailto:gerhard.petra...@gmail.com] *Gesendet:* Freitag, 05. Juni 2009 17:18 *An:* MyFaces Development *Betreff:* slf4j and myfaces hello all, again the logging-framework topic :) there were several discussions about it and i'm not aware of an agreement. udo wrote [1]: replace commons-logging with slf4j as i know we agreed on using one logging framework dependency for all myfaces projects. if i remember correctly, most of us prefer slf4j. - i suggest to vote about using slf4j in all myfaces projects. (at least if a project is using an external logging framework.) regards, gerhard [1] http://www.nabble.com/Re%3A-Trinidad-vs-Tobago-p23884581.html
AW: slf4j and myfaces
Why? I think our wrapper can do pretty much the same than slf4j does. Having a public static Log log = LogFactory.getLog(MyClass.class) can easily be supported by our logging framework. Then, any known logging framework has the most possible information available, whatever it does with it. If a logging framework use a static position of the stack trace, to gather its information, is bound to fail anyway and has to be considered a bad implementation, no? AFAIK, in terms of cl class loader issues, having a static log ist not bad if the logging facade has been loaded with the same class-loader than the library were loaded. Which should always be the case with our own wrapper. Yes, I know, we end up having a slf4j within myfaces. But I see no point having a dependency to such a simple API - which exactly adds no value, but forces every cl user to setup the sfl4j-over-cl bridge. IMHO, the java way to do it is to provide our own simple logging wrapper, by using jul as default impl. I know that jul sucks, but this then can easily be customized by the developer. Mojarra also uses jul, no? So good or bad, this i something we have to deal with anyway - providing a pluggable logging api is fair enough then. I think, most of the time the user will not care and just start using jul. Too bad that SUN did not manage to provide a logging api which has been widely accepted :-( Ciao, Mario Von: Gerhard Petracek [mailto:gerhard.petra...@gmail.com] Gesendet: Freitag, 05. Juni 2009 20:22 An: MyFaces Development Betreff: Re: slf4j and myfaces @mario: which logging frameworks would be supported by such a wrapper. i can just mention that there are logging frameworks out there which internally force an exception and statically use entry x of the call hierarchy - so such a wrapper would lead to wrong logging information. regards, gerhard (after reformulating the previous mail quite quickly the text wasn't perfect - but i think you know what i mean...) 2009/6/5 Gerhard Petracek gerhard.petra...@gmail.commailto:gerhard.petra...@gmail.com @matthias: yes - that's the reason for my comment: ...external logging framework... @udo: imo we should discuss the logging topic before we have a release which already uses slf4j - especially the suggestion of mario sounds interesting. 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/5 Mario Ivankovits ma...@ops.co.atmailto:ma...@ops.co.at Hi! Could one please eloberate a little bit more in detail what the pros are of slf4j? Notice, I switched to it in our company project - but always using the commons-logging api and just used the slf4j-over-cl wrapper. This is something wich is possible for each and ever user of myfaces already, just by adjusting the depencendcies correctly. Lately I even switched to my own logging wrapper, but this is another story. In the end, everything still uses the cl API which is proven to work fine. (I created the org.apache.commons.logging package structure with my own classes - which for sure is not possible for myfaces!). I still think, that using the cl api is the best we can do for our users. If they then use cl as implementation - and if this is considered good - is another story, but nothing WE should anticipate. As far as I can say the cl api is rock solid, just the class-loader stuff is a pain. But (again AFAIK), slf4j does not solve it, it just does not deal with it. Before we start using any other logging api I'd suggest to build our own thin myfaces-logging wrapper where one then can easily plug in log4j, cl, jul (java utils ogging) or whatever - we do not even have to provide any other impl than for jul. As a plus, this then will remove a dependency - a dependency to any logging framework - which - in terms of dependencies can be considered as a good thing, no? Ciao, Mario Von: Gerhard Petracek [mailto:gerhard.petra...@gmail.commailto:gerhard.petra...@gmail.com] Gesendet: Freitag, 05. Juni 2009 17:18 An: MyFaces Development Betreff: slf4j and myfaces hello all, again the logging-framework topic :) there were several discussions about it and i'm not aware of an agreement. udo wrote [1]: replace commons-logging with slf4j as i know we agreed on using one logging framework dependency for all myfaces projects. if i remember correctly, most of us prefer slf4j. - i suggest to vote about using slf4j in all myfaces projects. (at least if a project is using an external logging framework.) regards, gerhard [1] http://www.nabble.com/Re%3A-Trinidad-vs-Tobago-p23884581.html
Re: slf4j and myfaces
On Fri, Jun 5, 2009 at 19:49, Mario Ivankovits ma...@ops.co.at wrote: Hi! Could one please eloberate a little bit more in detail what the pros are of slf4j? Pros: No class loader ambiguousness (as you mentioned) You get what you define (especially when using maven): compile-dependency to slf4j-api runtime-dependency to slf4j-adapter of YOUR choice -- that's it! No wild guessing like with JCL: Use Log4j if it is anywhere in the (web container) classpath, else use Java logging... What, if I want to use Java logging although there is Log4j in the classpath?! Someone dropped a log4j.jar in the tomcat/lib folder. Oh no, not again... Yes, I know commons-logging.properties solves this, but that's awful... (BTW, I hate properties files in the root package namespace!) Notice, I switched to it in our company project - but always using the commons-logging api and just used the slf4j-over-cl wrapper. This is something wich is possible for each and ever user of myfaces already, just by adjusting the depencendcies correctly. Guess, you meant the jcl-over-slf4j.jar bridge, right? That's the part that reroutes JCL calls to the slf4j API. Yes, that is a possible solution, but keep in mind that this is kind of a hack. It is actually a reimplementation of the JCL API (namespace) that routes all calls to SLF4J. It's meant as runtime solution for legacy libs. Using it as compile time dependency might be a shortcut, but my feeling says it's not the nicest solution. Lately I even switched to my own logging wrapper, but this is another story. In the end, everything still uses the cl API which is proven to work fine. (I created the org.apache.commons.logging package structure with my own classes - which for sure is not possible for myfaces!). yet another logging wrapper WHY do so many people feel they must write such a thing? JCL and slf4j ARE ready-to-use logging wrappers. So??? I still think, that using the cl api is the best we can do for our users. If they then use cl as implementation - and if this is considered good - is another story, but nothing WE should anticipate. They CAN use JCL if myfaces uses slf4j. They just define a slf4j-jcl-x.x.x.jar runtime-dependency and everything is fine. As far as I can say the cl api is rock solid, just the class-loader stuff is a pain. But (again AFAIK), slf4j does not solve it, it just does not deal with it. slf4j DOES solve the problem by avoiding highly sophisticated classloader magic! Before we start using any other logging api I'd suggest to build our own thin myfaces-logging wrapper where one then can easily plug in log4j, cl, jul (java utils ogging) or whatever - we do not even have to provide any other impl than for jul. yet another logging wrapper... (see above) How would you implement such a pluggable wrapper? Yet another (mandatory) config parameter. System property? Servlet context param? Come on! What about this: looking for existing well-known logging implementations and define some priority rules... Dejavu. See the problem? As a plus, this then will remove a dependency - a dependency to any logging framework - which - in terms of dependencies can be considered as a good thing, no? You buy this good thing by re-implementing SLF4J and/or JCL. Serious. I cannot imagine a wrapper (actually a facade, right?) implementation that is versatile for the developers and pluggable for the users and has less source code than any of the well-known logging facade APIs (slf4j and jcl). They both are actually meant to heal the java world from proprietary yet another logging facades/wrappers! +1 for using SLF4J as logging facade for future MyFaces developments (JSF 2.0, ...) +0 for replacing JCL by SLF4J for all existing code (if someone is volunteering to do the job I have no problem with that...) --Manfred
Re: slf4j and myfaces
ok - i thought you mean something different... i didn't thought that you mean something like: I know, we end up having a slf4j within myfaces do you mean to have a wrapper e.g. as commons-module [1]? - every myfaces project has a dependency to it? regards, gerhard [1] http://svn.apache.org/repos/asf/myfaces/commons/trunk/ http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces 2009/6/5 Mario Ivankovits ma...@ops.co.at Why? I think our wrapper can do pretty much the same than slf4j does. Having a public static Log log = LogFactory.getLog(MyClass.class) can easily be supported by our logging framework. Then, any known logging framework has the most possible information available, whatever it does with it. If a logging framework use a static position of the stack trace, to gather its information, is bound to fail anyway and has to be considered a bad implementation, no? AFAIK, in terms of cl class loader issues, having a static log ist not bad if the logging facade has been loaded with the same class-loader than the library were loaded. Which should always be the case with our own wrapper. Yes, I know, we end up having a slf4j within myfaces. But I see no point having a dependency to such a simple API - which exactly adds no value, but forces every cl user to setup the sfl4j-over-cl bridge. IMHO, the java way to do it is to provide our own simple logging wrapper, by using jul as default impl. I know that jul sucks, but this then can easily be customized by the developer. Mojarra also uses jul, no? So good or bad, this i something we have to deal with anyway - providing a pluggable logging api is fair enough then. I think, most of the time the user will not care and just start using jul. Too bad that SUN did not manage to provide a logging api which has been widely accepted :-( Ciao, Mario *Von:* Gerhard Petracek [mailto:gerhard.petra...@gmail.com] *Gesendet:* Freitag, 05. Juni 2009 20:22 *An:* MyFaces Development *Betreff:* Re: slf4j and myfaces @mario: which logging frameworks would be supported by such a wrapper. i can just mention that there are logging frameworks out there which internally force an exception and statically use entry x of the call hierarchy - so such a wrapper would lead to wrong logging information. regards, gerhard (after reformulating the previous mail quite quickly the text wasn't perfect - but i think you know what i mean...) 2009/6/5 Gerhard Petracek gerhard.petra...@gmail.com @matthias: yes - that's the reason for my comment: ...external logging framework... @udo: imo we should discuss the logging topic before we have a release which already uses slf4j - especially the suggestion of mario sounds interesting. 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/5 Mario Ivankovits ma...@ops.co.at Hi! Could one please eloberate a little bit more in detail what the pros are of slf4j? Notice, I switched to it in our company project - but always using the commons-logging api and just used the slf4j-over-cl wrapper. This is something wich is possible for each and ever user of myfaces already, just by adjusting the depencendcies correctly. Lately I even switched to my own logging wrapper, but this is another story. In the end, everything still uses the cl API which is proven to work fine. (I created the org.apache.commons.logging package structure with my own classes - which for sure is not possible for myfaces!). I still think, that using the cl api is the best we can do for our users. If they then use cl as implementation - and if this is considered good - is another story, but nothing WE should anticipate. As far as I can say the cl api is rock solid, just the class-loader stuff is a pain. But (again AFAIK), slf4j does not solve it, it just does not deal with it. Before we start using any other logging api I'd suggest to build our own thin myfaces-logging wrapper where one then can easily plug in log4j, cl, jul (java utils ogging) or whatever - we do not even have to provide any other impl than for jul. As a plus, this then will remove a dependency - a dependency to any logging framework - which - in terms of dependencies can be considered as a good thing, no? Ciao, Mario *Von:* Gerhard Petracek [mailto:gerhard.petra...@gmail.com] *Gesendet:* Freitag, 05. Juni 2009 17:18 *An:* MyFaces Development *Betreff:* slf4j and myfaces hello all, again the logging-framework topic :) there were several discussions about it and i'm not aware of an agreement. udo wrote [1]: replace commons-logging with slf4j as i know we agreed on using one logging framework dependency for all myfaces projects. if i remember
Re: slf4j and myfaces
JCL and slf4j ARE ready-to-use logging wrappers. +1 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/5 Manfred Geiler manfred.gei...@gmail.com On Fri, Jun 5, 2009 at 19:49, Mario Ivankovits ma...@ops.co.at wrote: Hi! Could one please eloberate a little bit more in detail what the pros are of slf4j? Pros: No class loader ambiguousness (as you mentioned) You get what you define (especially when using maven): compile-dependency to slf4j-api runtime-dependency to slf4j-adapter of YOUR choice -- that's it! No wild guessing like with JCL: Use Log4j if it is anywhere in the (web container) classpath, else use Java logging... What, if I want to use Java logging although there is Log4j in the classpath?! Someone dropped a log4j.jar in the tomcat/lib folder. Oh no, not again... Yes, I know commons-logging.properties solves this, but that's awful... (BTW, I hate properties files in the root package namespace!) Notice, I switched to it in our company project - but always using the commons-logging api and just used the slf4j-over-cl wrapper. This is something wich is possible for each and ever user of myfaces already, just by adjusting the depencendcies correctly. Guess, you meant the jcl-over-slf4j.jar bridge, right? That's the part that reroutes JCL calls to the slf4j API. Yes, that is a possible solution, but keep in mind that this is kind of a hack. It is actually a reimplementation of the JCL API (namespace) that routes all calls to SLF4J. It's meant as runtime solution for legacy libs. Using it as compile time dependency might be a shortcut, but my feeling says it's not the nicest solution. Lately I even switched to my own logging wrapper, but this is another story. In the end, everything still uses the cl API which is proven to work fine. (I created the org.apache.commons.logging package structure with my own classes - which for sure is not possible for myfaces!). yet another logging wrapper WHY do so many people feel they must write such a thing? JCL and slf4j ARE ready-to-use logging wrappers. So??? I still think, that using the cl api is the best we can do for our users. If they then use cl as implementation - and if this is considered good - is another story, but nothing WE should anticipate. They CAN use JCL if myfaces uses slf4j. They just define a slf4j-jcl-x.x.x.jar runtime-dependency and everything is fine. As far as I can say the cl api is rock solid, just the class-loader stuff is a pain. But (again AFAIK), slf4j does not solve it, it just does not deal with it. slf4j DOES solve the problem by avoiding highly sophisticated classloader magic! Before we start using any other logging api I'd suggest to build our own thin myfaces-logging wrapper where one then can easily plug in log4j, cl, jul (java utils ogging) or whatever - we do not even have to provide any other impl than for jul. yet another logging wrapper... (see above) How would you implement such a pluggable wrapper? Yet another (mandatory) config parameter. System property? Servlet context param? Come on! What about this: looking for existing well-known logging implementations and define some priority rules... Dejavu. See the problem? As a plus, this then will remove a dependency - a dependency to any logging framework - which - in terms of dependencies can be considered as a good thing, no? You buy this good thing by re-implementing SLF4J and/or JCL. Serious. I cannot imagine a wrapper (actually a facade, right?) implementation that is versatile for the developers and pluggable for the users and has less source code than any of the well-known logging facade APIs (slf4j and jcl). They both are actually meant to heal the java world from proprietary yet another logging facades/wrappers! +1 for using SLF4J as logging facade for future MyFaces developments (JSF 2.0, ...) +0 for replacing JCL by SLF4J for all existing code (if someone is volunteering to do the job I have no problem with that...) --Manfred
[jira] Created: (TRINIDAD-1500) XMLMenu / Facelets / rendered property
XMLMenu / Facelets / rendered property
--
Key: TRINIDAD-1500
URL: https://issues.apache.org/jira/browse/TRINIDAD-1500
Project: MyFaces Trinidad
Issue Type: Bug
Components: Facelets
Affects Versions: 1.0.10-core
Environment: Windows XP, JDK 5, Jboss 4.0.4, Facelets 1.1.14
Reporter: Jim Dolinski
I am using the XMLMenu Model component with facelets and when the rendered
property is added to the commandNavigationItem the entire menu fails to
display. The problem only occurs when using the rendered property and works
without Facelets using JSP. I receive the following log in the console:
13:42:33,819 ERROR [STDERR] Jun 5, 2009 1:42:33 PM
org.apache.myfaces.trinidadinternal.io.HtmlResponseWriter endElement
SEVERE: Element End name:nobr does not match start name:span
13:42:33,819 ERROR [STDERR] Jun 5, 2009 1:42:33 PM
org.apache.myfaces.trinidadinternal.io.HtmlResponseWriter endElement
SEVERE: Element End name:span does not match start name:td
13:42:33,819 ERROR [STDERR] Jun 5, 2009 1:42:33 PM
org.apache.myfaces.trinidadinternal.io.HtmlResponseWriter endElement
SEVERE: Element End name:td does not match start name:tr
13:42:33,835 ERROR [STDERR] Jun 5, 2009 1:42:33 PM
org.apache.myfaces.trinidadinternal.io.HtmlResponseWriter endElement
SEVERE: Element End name:tr does not match start name:table
13:42:33,835 ERROR [STDERR] Jun 5, 2009 1:42:33 PM
org.apache.myfaces.trinidadinternal.io.HtmlResponseWriter endElement
SEVERE: Element End name:span does not match start name:div
13:42:34,068 ERROR [STDERR] Jun 5, 2009 1:42:34 PM
org.apache.myfaces.trinidadinternal.io.HtmlResponseWriter endElement
SEVERE: Element End name:div does not match start name:span
13:42:34,068 ERROR [STDERR] Jun 5, 2009 1:42:34 PM
org.apache.myfaces.trinidadinternal.io.HtmlResponseWriter endElement
SEVERE: Element End name:span does not match start name:form
13:42:34,068 ERROR [STDERR] Jun 5, 2009 1:42:34 PM
org.apache.myfaces.trinidadinternal.io.HtmlResponseWriter endElement
SEVERE: Element End name:form does not match start name:body
13:42:34,068 ERROR [STDERR] Jun 5, 2009 1:42:34 PM
org.apache.myfaces.trinidadinternal.io.HtmlResponseWriter endElement
SEVERE: Element End name:body does not match start name:html
My facelet config in web.xml is as follows:
context-param
param-nameorg.apache.myfaces.trinidad.ALTERNATE_VIEW_HANDLER/param-name
param-valuecom.sun.facelets.FaceletViewHandler/param-value
/context-param
context-param
param-namefacelets.VIEW_MAPPINGS/param-name
param-value*.xhtml/param-value
/context-param
!-- Special Debug Output for Development --
context-param
param-namefacelets.DEVELOPMENT/param-name
param-valuetrue/param-value
/context-param
Menu model xml is:
itemNode id=menuTabs
itemNode id=search label=Project Search
action=menu.menuprojectsearch focusViewId=/pages/projectSearch.xhtml
itemNode id=results label=Project Results
focusViewId=/pages/projectSearchResults.xhtml/
itemNode id=edit label=Project Edit
focusViewId=/pages/projectEdit.xhtml/
/itemNode
itemNode id=new label=New Project action=menu.menuprojectnew
focusViewId=/pages/newProject.xhtml disabled=true/
itemNode id=dashboard label=Project Dashboard
action=menu.menuprojectdash focusViewId=/pages/projectDash.xhtml/
itemNode id=reports label=Reports action=menu.menureports
focusViewId=/pages/reports/reports.xhtml/
/itemNode
itemNode id=logout label=Logout action=logout
icon=/images/logout.gif/
itemNode id=help label=Help icon=/images/globalhelp.gif
destination=#{requestContext.helpSystem.frontPage}/
And the page snippet that creates the menu:
h:form id=form
tr:page id=page var=node value=#{menu}
f:facet name=nodeStamp
tr:commandNavigationItem id=cmdNavItem
text=#{node.label}
action=#{node.doAction}
icon=#{node.icon} immediate=true rendered=#{node.rendered}
/tr:commandNavigationItem
/f:facet
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: slf4j and myfaces
as we saw in previous discussions there are several different opinions. we really discussed that topic a lot. (i also don't really like the idea of having a myfaces logging facade which does more or less the same as other solutions... as mentioned before i thought mario was talking about something different (a mechanism i already had a look at it and won't work due to the mentioned problem...)) anyway, i don't like to have the next big discussion about this topic without a final vote... imo we should just vote about using slf4j as soon as possible for all myfaces projects (from now on). as mentioned: only for projects which use an external logging framework (so e.g. trinidad isn't affected right now). 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/5 Gerhard Petracek gerhard.petra...@gmail.com JCL and slf4j ARE ready-to-use logging wrappers. +1 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/5 Manfred Geiler manfred.gei...@gmail.com On Fri, Jun 5, 2009 at 19:49, Mario Ivankovits ma...@ops.co.at wrote: Hi! Could one please eloberate a little bit more in detail what the pros are of slf4j? Pros: No class loader ambiguousness (as you mentioned) You get what you define (especially when using maven): compile-dependency to slf4j-api runtime-dependency to slf4j-adapter of YOUR choice -- that's it! No wild guessing like with JCL: Use Log4j if it is anywhere in the (web container) classpath, else use Java logging... What, if I want to use Java logging although there is Log4j in the classpath?! Someone dropped a log4j.jar in the tomcat/lib folder. Oh no, not again... Yes, I know commons-logging.properties solves this, but that's awful... (BTW, I hate properties files in the root package namespace!) Notice, I switched to it in our company project - but always using the commons-logging api and just used the slf4j-over-cl wrapper. This is something wich is possible for each and ever user of myfaces already, just by adjusting the depencendcies correctly. Guess, you meant the jcl-over-slf4j.jar bridge, right? That's the part that reroutes JCL calls to the slf4j API. Yes, that is a possible solution, but keep in mind that this is kind of a hack. It is actually a reimplementation of the JCL API (namespace) that routes all calls to SLF4J. It's meant as runtime solution for legacy libs. Using it as compile time dependency might be a shortcut, but my feeling says it's not the nicest solution. Lately I even switched to my own logging wrapper, but this is another story. In the end, everything still uses the cl API which is proven to work fine. (I created the org.apache.commons.logging package structure with my own classes - which for sure is not possible for myfaces!). yet another logging wrapper WHY do so many people feel they must write such a thing? JCL and slf4j ARE ready-to-use logging wrappers. So??? I still think, that using the cl api is the best we can do for our users. If they then use cl as implementation - and if this is considered good - is another story, but nothing WE should anticipate. They CAN use JCL if myfaces uses slf4j. They just define a slf4j-jcl-x.x.x.jar runtime-dependency and everything is fine. As far as I can say the cl api is rock solid, just the class-loader stuff is a pain. But (again AFAIK), slf4j does not solve it, it just does not deal with it. slf4j DOES solve the problem by avoiding highly sophisticated classloader magic! Before we start using any other logging api I'd suggest to build our own thin myfaces-logging wrapper where one then can easily plug in log4j, cl, jul (java utils ogging) or whatever - we do not even have to provide any other impl than for jul. yet another logging wrapper... (see above) How would you implement such a pluggable wrapper? Yet another (mandatory) config parameter. System property? Servlet context param? Come on! What about this: looking for existing well-known logging implementations and define some priority rules... Dejavu. See the problem? As a plus, this then will remove a dependency - a dependency to any logging framework - which - in terms of dependencies can be considered as a good thing, no? You buy this good thing by re-implementing SLF4J and/or JCL. Serious. I cannot imagine a wrapper (actually a facade, right?) implementation that is versatile for the developers and pluggable for the users and has less source code than any of the well-known logging facade APIs (slf4j and jcl). They both are actually meant to heal the java world from proprietary yet another logging facades/wrappers! +1 for using SLF4J as logging facade for future MyFaces developments (JSF 2.0,
[jira] Resolved: (TRINIDAD-1494) Support java.util.Set as property type
[ https://issues.apache.org/jira/browse/TRINIDAD-1494?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeanne Waldman resolved TRINIDAD-1494. -- Resolution: Fixed Fix Version/s: 1.2.10-plugins 1.2.12-core 1.0.11-core Assignee: Jeanne Waldman Support java.util.Set as property type -- Key: TRINIDAD-1494 URL: https://issues.apache.org/jira/browse/TRINIDAD-1494 Project: MyFaces Trinidad Issue Type: Improvement Components: Plugins Environment: This is generic, not specific to any OS or software/hardware specifications. Reporter: Jing Wu Assignee: Jeanne Waldman Priority: Minor Fix For: 1.0.11-core, 1.2.12-core, 1.2.10-plugins Attachments: trinidad-1.0.patch, trinidad-1.2.11.3.patch, trinidad-mavan-plugin-trunk.patch, trinidad-maven-plugin-1.2.10.1.patch, trinidad-trunk.patch Original Estimate: 48h Remaining Estimate: 48h For some properties, java.util.Set is the best suitable type, trinidad should support java.util.Set as the property type. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (TRINIDAD-1499) Regression issues with jsp tag class generation from move to jsr276 metadata
[ https://issues.apache.org/jira/browse/TRINIDAD-1499?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matthias Weßendorf updated TRINIDAD-1499: - Resolution: Fixed Fix Version/s: 1.2.10-plugins Assignee: Matthias Weßendorf Status: Resolved (was: Patch Available) Regression issues with jsp tag class generation from move to jsr276 metadata Key: TRINIDAD-1499 URL: https://issues.apache.org/jira/browse/TRINIDAD-1499 Project: MyFaces Trinidad Issue Type: Bug Components: Build Affects Versions: 1.2.10-plugins Reporter: Bill Baggett Assignee: Matthias Weßendorf Fix For: 1.2.10-plugins Attachments: jsr276_090605.patch In the move to the new jsr-276 metadata we missed a couple things with the generation of the jsp tag classes. First, we needed to check for the deprecated metadata element in the new structure because this is used in the jsp tag class generation. Second, the move from mfp:literal-onlytrue/mfp:literal-only to fmd:value-expressionPROHIBITED/fmd:value-expression wasn't handled in all cases. I had previously made a fix that checked for either the old way or the new way. The problem is that there were a couple places that I missed (ie jsp tag class generation). Instead of making a check for the old way and the new way in each place, I decided to put the fix at a lower level. There were 2 parts to this. First, undo the check I had made for the old way and the new way. Second, in the digester bean handler for the new way, I just set the property corresponding to the old way. That makes it transparent. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
