AW: slf4j and myfaces
Sorry, for top-posting, but Outlook makes it too hard to do it right ;-) Well, yet another configuration option for configuring our logging facade (yes, you are right, it is a facade) is for sure also not a good option. As a last note to this discussion I'd like to say, that not dealing with the class loader issue does not mean that the webapp-reloading-memory-leak has been addressed in some way. Anyway, if you think it (slf4j) is a good way to go, I'll not stand in between :-) Ciao, Mario -Ursprüngliche Nachricht- Von: Manfred Geiler [mailto:manfred.gei...@gmail.com] Gesendet: Freitag, 05. Juni 2009 20:50 An: MyFaces Development Betreff: 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 anfred
AW: slf4j and myfaces
But why not use java.util.logging then at all. There is an example [1] which shows how to reroute it to any other logging impl. This too will remove the need of any logging dependency then. Look, with slf4j you will end with three dependencies. * the slf4j api * the commons-logging to slf4j bridge (for all the other libraries your app is going to use and which still are using commons-logging) * the slf4j impl (an since the impl itself provides nothing than the bridge, you need the logging impl to) If you are going to use java.util.logging - which is a pain to setup, but sufficient for many use-cases - these are three (up to four) dependencies too much - just for logging! I think, this will not be a bad move - and moves us completely out of line of this question once and for all I think. The java.util.logging api itself provides the same possibilities than we have today in our libraries - just different namings. Ciao, Mario [1] http://wiki.apache.org/myfaces/Trinidad_and_Common_Logging -Ursprüngliche Nachricht- Von: Mario Ivankovits [mailto:ma...@ops.co.at] Gesendet: Samstag, 06. Juni 2009 08:08 An: 'MyFaces Development' Betreff: AW: slf4j and myfaces Sorry, for top-posting, but Outlook makes it too hard to do it right ;-) Well, yet another configuration option for configuring our logging facade (yes, you are right, it is a facade) is for sure also not a good option. As a last note to this discussion I'd like to say, that not dealing with the class loader issue does not mean that the webapp-reloading-memory-leak has been addressed in some way. Anyway, if you think it (slf4j) is a good way to go, I'll not stand in between :-) Ciao, Mario -Ursprüngliche Nachricht- Von: Manfred Geiler [mailto:manfred.gei...@gmail.com] Gesendet: Freitag, 05. Juni 2009 20:50 An: MyFaces Development Betreff: 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
[jira] Commented: (TOMAHAWK-1072) MyFacesExtensionsFilter overfills memory
[
https://issues.apache.org/jira/browse/TOMAHAWK-1072?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12716848#action_12716848
]
Leonardo Uribe commented on TOMAHAWK-1072:
--
An inspection of the code reveals that there is not problem with extensions
filter.
On the first part of method doFilter:
public void doFilter(ServletRequest request, ServletResponse response,
FilterChain chain) throws IOException, ServletException {
if(request.getAttribute(DOFILTER_CALLED)!=null)
{
chain.doFilter(request, response);
return;
}
request.setAttribute(DOFILTER_CALLED,true);
A param is set on request scope to prevent call its methods more than once, so
there is no reason why ExtensionsFilter could overfills memory.
This one will be closed as invalid (can't be solved on myfaces land).
MyFacesExtensionsFilter overfills memory
Key: TOMAHAWK-1072
URL: https://issues.apache.org/jira/browse/TOMAHAWK-1072
Project: MyFaces Tomahawk
Issue Type: Bug
Components: File Upload
Affects Versions: 1.1.6
Environment: ajax4jsf-1.1.2-20070802.000138-143
richfaces-3.0.1-SNAPSHOT
tomahawk-1.1.6
tomcat 5.5.20
Reporter: Areshchenko Alexandr
when i include MyFacesExtensionsFilter into web.xml like this
filter
filter-nameMyFacesExtensionsFilter/filter-name
filter-classorg.apache.myfaces.webapp.filter.ExtensionsFilter/filter-class
init-param
param-nameuploadMaxFileSize/param-name
param-value10m/param-value
/init-param
init-param
param-nameuploadThresholdSize/param-name
param-value2m/param-value
/init-param
/filter
filter-mapping
filter-nameMyFacesExtensionsFilter/filter-name
servlet-nameFaces Servlet/servlet-name
/filter-mapping
!-- extension mapping for serving page-independent resources (javascript,
stylesheets, images, etc.) --
filter-mapping
filter-nameMyFacesExtensionsFilter/filter-name
url-pattern/*/url-pattern
/filter-mapping
then after clicking any button or link cases exceptions
javax.servlet.ServletException: Servlet execution threw an exception
org.ajax4jsf.framework.ajax.xmlfilter.BaseXMLFilter.doXmlFilter(BaseXMLFilter.java:139)
org.ajax4jsf.framework.ajax.xmlfilter.BaseFilter.doFilter(BaseFilter.java:276)
org.apache.myfaces.webapp.filter.ExtensionsFilter.doFilter(ExtensionsFilter.java:100)
org.apache.myfaces.webapp.filter.ExtensionsFilter.doFilter(ExtensionsFilter.java:147)
java.lang.OutOfMemoryError: Java heap space
19:06:03,546 ERROR [Faces Servlet]:253 - Servlet.service() for servlet Faces
Servlet threw exception
java.lang.OutOfMemoryError: Java heap space
--
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
Gerhard Petracek schrieb: 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 Ok here is another suggestion, for myfaces 1.2+ we have to be on JDK5, right? So why dont we simply move over to the Sun logging API? One dependency less is always welcome! Werner
Re: AW: slf4j and myfaces
+1 for that, the issue simply is, there is a standard api, while not the best it works good enough (since JDK5) and it is simple enough to be used why not finally get rid of another dependency. I am not a huge fan of dependencies in base projects anyway, so everything which removes one gets definitely a +1 by me. Is there any disadvantages of moving over to straight JUL? Werner Mario Ivankovits schrieb: But why not use java.util.logging then at all. There is an example [1] which shows how to reroute it to any other logging impl. This too will remove the need of any logging dependency then. Look, with slf4j you will end with three dependencies. * the slf4j api * the commons-logging to slf4j bridge (for all the other libraries your app is going to use and which still are using commons-logging) * the slf4j impl (an since the impl itself provides nothing than the bridge, you need the logging impl to) If you are going to use java.util.logging - which is a pain to setup, but sufficient for many use-cases - these are three (up to four) dependencies too much - just for logging! I think, this will not be a bad move - and moves us completely out of line of this question once and for all I think. The java.util.logging api itself provides the same possibilities than we have today in our libraries - just different namings. Ciao, Mario
Myfaces 2.0 PPR ResponseWriter impl
Hello everyone There are some corner cases which are not covered by our current implementation of the ppr response writer. (And neither by the RI as the comments from Salem seem to show) I will give an example PPR Response It usually starts with startUpate on the ppr response writer then the control tree is walked down and the controls are redrawn and an endUpdate is offered So what happens now is following someone issues a startElement(script) which means the script is embedded into the update code while a separate eval cycle which would be possible is omitted! We already have this covered in our javascript code by parsing the scripts, but I want to make a switch to have this turned off if performance is an issue. Nevertheless Javascript code should not be pushed into the html part of the ppr response anyway. So here is my proposal and I am working on it already. Scan for script startElement tags and postpone the rendering of those until the endUpdate or endInsert is issued! Scan for script src and add some dynamic loading code to it (already finished in the javascripts) and postpone it as well! eval within an active update or insert also causes the same delay behavior! if non update or insert is issued before then simply render script src as eval! The advantage of all this is we can cover corner cases which can occur while not breaking downward compatibility. As far as I have understood the reported RI behavior, the component writers should be self aware of being in a PPR cycle but I am not sure how to render scripts from the component side without this behavior, I doubt this will work out without the added delaying behavior and pushing the scripts into the eval stage! In our solution (which does the same as Trinidad mostly, btw, but in the jsf2 specific context) you dont have to care at all! I have coded the needed ResponseWriterImpl extension class, but I am not finished with debugging, but I assume we should add the delaying behavior to cover those cases correctly!
Re: slf4j and myfaces
On Sat, Jun 6, 2009 at 08:33, Mario Ivankovitsma...@ops.co.at wrote:
But why not use java.util.logging then at all. There is an example [1] which
shows how to reroute it to any other logging impl.
hmm, insteresting. might be a way.
there is even a ready-to-use slf4j bridge handler for JUL
(http://www.slf4j.org/api/org/slf4j/bridge/SLF4JBridgeHandler.html)
that does exactly the same.
The downside is, you need an init call during startup of your app.
This too will remove the need of any logging dependency then.
Look, with slf4j you will end with three dependencies.
* the slf4j api
* the commons-logging to slf4j bridge (for all the other libraries your app
is going to use and which still are using commons-logging)
* the slf4j impl (an since the impl itself provides nothing than the bridge,
you need the logging impl to)
If you are going to use java.util.logging - which is a pain to setup, but
sufficient for many use-cases - these are three (up to four) dependencies too
much - just for logging!
Actually we would have just one single compile time dependency to the
slf4j api in MyFaces (instead of the JCL dep. we have now).
The rest is configuration stuff (runtime dependencies), the user deals
with in his app. It just depends on the actual logging impl he wants.
I think, this will not be a bad move - and moves us completely out of line of
this question once and for all I think.
The java.util.logging api itself provides the same possibilities than we have
today in our libraries - just different namings.
There are two pros of slf4j I did not mention yet:
1. parameterized messages, which make it possible to omit those ugly
if (logger.isDebugEnabled()) {... conditions, without performance
issue: see http://www.slf4j.org/faq.html#logging_performance
2. it's no longer possible to forget the log message by writing
logger.error(exc) instead of logger.error(an error has occured,
exc). This is because the slf4j api is strict and only allows a
String (and not an Object) as first argument.
However, I'm starting to like the idea of using JUL and kicking out
any logging dependency (and future discussions). What I'm not sure is
if the JUL to other logging impl bridge is multiple application
friendly. What happens if the JUL root handler is replaced (thats what
these bridges seem to do). Does this influence the servlet container
logging and other apps as well?
--Manfred
Ciao,
Mario
[1] http://wiki.apache.org/myfaces/Trinidad_and_Common_Logging
-Ursprüngliche Nachricht-
Von: Mario Ivankovits [mailto:ma...@ops.co.at]
Gesendet: Samstag, 06. Juni 2009 08:08
An: 'MyFaces Development'
Betreff: AW: slf4j and myfaces
Sorry, for top-posting, but Outlook makes it too hard to do it right ;-)
Well, yet another configuration option for configuring our logging facade
(yes, you are right, it is a facade) is for sure also not a good option.
As a last note to this discussion I'd like to say, that not dealing with the
class loader issue does not mean that the webapp-reloading-memory-leak has
been addressed in some way.
Anyway, if you think it (slf4j) is a good way to go, I'll not stand in
between :-)
Ciao,
Mario
-Ursprüngliche Nachricht-
Von: Manfred Geiler [mailto:manfred.gei...@gmail.com]
Gesendet: Freitag, 05. Juni 2009 20:50
An: MyFaces Development
Betreff: 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,
Re: AW: slf4j and myfaces
that would be possible as well. i just started with slf4j since we already discussed it and udo wrote about the switch to slf4j in the next release... we could also vote first about slf4j and everybody who prefers jul should vote -1 if we don't have a majority for slf4j, we have to vote about jul. is that ok for everybody? (i don't like the idea that every myfaces project ends up with its special 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/6 Werner Punz werner.p...@gmail.com +1 for that, the issue simply is, there is a standard api, while not the best it works good enough (since JDK5) and it is simple enough to be used why not finally get rid of another dependency. I am not a huge fan of dependencies in base projects anyway, so everything which removes one gets definitely a +1 by me. Is there any disadvantages of moving over to straight JUL? Werner Mario Ivankovits schrieb: But why not use java.util.logging then at all. There is an example [1] which shows how to reroute it to any other logging impl. This too will remove the need of any logging dependency then. Look, with slf4j you will end with three dependencies. * the slf4j api * the commons-logging to slf4j bridge (for all the other libraries your app is going to use and which still are using commons-logging) * the slf4j impl (an since the impl itself provides nothing than the bridge, you need the logging impl to) If you are going to use java.util.logging - which is a pain to setup, but sufficient for many use-cases - these are three (up to four) dependencies too much - just for logging! I think, this will not be a bad move - and moves us completely out of line of this question once and for all I think. The java.util.logging api itself provides the same possibilities than we have today in our libraries - just different namings. Ciao, Mario
Re: AW: slf4j and myfaces
Hi, we could also vote first about slf4j and everybody who prefers jul should vote -1 if we don't have a majority for slf4j, we have to vote about jul. is that ok for everybody? From http://www.apache.org/foundation/voting.html my understanding of a -1 vote is different from this. Vetos A code-modification proposal may be stopped dead in its tracks by a -1 vote by a qualified voter. This constitutes a veto, and it cannot be overruled nor overridden by anyone. Vetos stand until and unless withdrawn by their casters. To prevent vetos from being used capriciously, they must be accompanied by a technical justification showing why the change is bad (opens a security exposure, negatively affects performance, etc.). A veto without a justification is invalid and has no weight. Better use the fraction system for voting on the logging system: * +0: 'I don't feel strongly about it, but I'm okey with this.' * -0: 'I won't get in the way, but I'd rather we didn't do this.' * -0.5: 'I don't like this idea, but I can't find any rational justification for my feelings.' * ++1: 'Wow! I like this! Let's do it!' * -0.9: 'I really don't like this, but I'm not going to stand in the way if everyone else wants to go ahead with it.' * +0.9: 'This is a cool idea and i like it, but I don't have time/the skills necessary to help out.' Best regards, Ganesh
AW: slf4j and myfaces
Hi!
There are two pros of slf4j I did not mention yet:
1. parameterized messages, which make it possible to omit those ugly
if (logger.isDebugEnabled()) {... conditions, without performance
issue: see http://www.slf4j.org/faq.html#logging_performance
http://java.sun.com/j2se/1.5.0/docs/api/java/util/logging/Logger.html
Seems that JUL support this too if we use the log() methods.
I've looked at the java source. JUL is using MessageFormat.Format then in the
formatter only if there is a placeholder in the message ({0-{4).
Not that bad.
2. it's no longer possible to forget the log message by writing
logger.error(exc) instead of logger.error(an error has occured,
exc). This is because the slf4j api is strict and only allows a
String (and not an Object) as first argument.
Funny, JUL also has no log(ex) method, just log(String, ex) (+ level for sure).
Seems the JUL API is not that bad :-)
What I'm not sure is
if the JUL to other logging impl bridge is multiple application
friendly. What happens if the JUL root handler is replaced (thats what
these bridges seem to do). Does this influence the servlet container
logging and other apps as well?
Seems to be true, JUL is not container friendly by default. But this needs to
be addressed by the container (and the Java Spec guys ;-) ).
It seems, this is the reason for JULI, the Tomcat logging impl.
Also JBoss solved that (as they use Tomcat ?!). See for a documentation here:
http://www.jboss.org/file-access/default/members/jbossweb/freezone/docs/latest/logging.html
They replace the LogManager by a container friendly LogManager. The JUL using
app does not need to know that.
Yeah, seems JUL can be our salvation finally ;-)
Ciao,
Mario
Re: slf4j and myfaces
that would be possible as well. i just started with slf4j since we already discussed it and udo wrote about the switch to slf4j in the next release... we could also vote first about slf4j and everybody who prefers jul should vote -1 Just wait until Monday if possible, then enough developers should have commented on the thread already. Probably it is clear then already that a vote for JUL is enough. (i don't like the idea that every myfaces project ends up with its special logging framework dependency.) Yes, thats true. Ciao, Mario
Re: AW: slf4j and myfaces
yes the -1 vote would be a veto in view of slf4j - no agreement - we would vote about jul. or as mario suggested - let's start voting about jul. @mario: yes - i'll wait until monday for sure. and we should vote a bit longer than usual - due to holidays (+ it's an important topic for all myfaces projects) 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/6 Ganesh gan...@j4fry.org Hi, we could also vote first about slf4j and everybody who prefers jul should vote -1 if we don't have a majority for slf4j, we have to vote about jul. is that ok for everybody? From http://www.apache.org/foundation/voting.html my understanding of a -1 vote is different from this. Vetos A code-modification proposal may be stopped dead in its tracks by a -1 vote by a qualified voter. This constitutes a veto, and it cannot be overruled nor overridden by anyone. Vetos stand until and unless withdrawn by their casters. To prevent vetos from being used capriciously, they must be accompanied by a technical justification showing why the change is bad (opens a security exposure, negatively affects performance, etc.). A veto without a justification is invalid and has no weight. Better use the fraction system for voting on the logging system: * +0: 'I don't feel strongly about it, but I'm okey with this.' * -0: 'I won't get in the way, but I'd rather we didn't do this.' * -0.5: 'I don't like this idea, but I can't find any rational justification for my feelings.' * ++1: 'Wow! I like this! Let's do it!' * -0.9: 'I really don't like this, but I'm not going to stand in the way if everyone else wants to go ahead with it.' * +0.9: 'This is a cool idea and i like it, but I don't have time/the skills necessary to help out.' Best regards, Ganesh
Re: slf4j and myfaces
Mario Ivankovits schrieb: that would be possible as well. i just started with slf4j since we already discussed it and udo wrote about the switch to slf4j in the next release... we could also vote first about slf4j and everybody who prefers jul should vote -1 Just wait until Monday if possible, then enough developers should have commented on the thread already. Probably it is clear then already that a vote for JUL is enough. (i don't like the idea that every myfaces project ends up with its special logging framework dependency.) Yes, thats true. Ciao, Mario The only downside I see is that we might break compatibility for java 1.4 since JUL gut some overhaul between 1.4 and 5, but on the other hand is it really important anymore? Which projects still have to be on 1.4
Re: Myfaces 2.0 PPR ResponseWriter impl
Hi, So here is my proposal and I am working on it already. Scan for script startElement tags and postpone the rendering of those until the endUpdate or endInsert is issued! Scan for script src and add some dynamic loading code to it (already finished in the javascripts) and postpone it as well! -1 for script scanning on the server side. You will get into serious troubles with this. 1. You don't know whether the HTML part contains !-- (or some other kind of comment) before the tag that includes the startElement or the script src. 2. This does cost performance in the server and all the corner cases can be handled on the Javascript side (and already are, as you mentioned in the beginning) 3. By default browsers should do an auto eval when xhr replaces scripts. IE doesn't, but this can be handled on the Javascript side. We shouldn't fix IE bugs in the ResponseWriterImpl. Doing it on the Javascript side only costs performance for browsers that don't support auto eval, the good guys will have a performance benefit. 4. RI doesn't do this kind of stuff. It may even break TCK compatibility. eval within an active update or insert also causes the same delay behavior! if non update or insert is issued before then simply render script src as eval! I don't understand the meaning of these two sentences. Though I'm not a qualified voter I'm probably the one besides Werner who is closest to the MyFaces AJAX code, so I thought I might have a vote on this. Best regards, Ganesh
Re: Myfaces 2.0 PPR ResponseWriter impl
Ganesh schrieb: Hi, So here is my proposal and I am working on it already. Scan for script startElement tags and postpone the rendering of those until the endUpdate or endInsert is issued! Scan for script src and add some dynamic loading code to it (already finished in the javascripts) and postpone it as well! -1 for script scanning on the server side. You will get into serious troubles with this. uff I think you got me wrong here what I propose to do is following writer.startElement(script writer.writeAttribute(src,bla.js should expand into eval![CDATA[ var script = myfaces.utils.loadScript(bla.js); eval(script); ]] /eval nothing fancy with script scanning! I formulated it the wrong way basically! 1. You don't know whether the HTML part contains !-- (or some other kind of comment) before the tag that includes the startElement or the script src. that is a corner case we cannot really cover on writer level, the component author has to take care of it!) The normal case on the component side simply is !-- means that you dont write it out at all but leave it out. I am not talking about page designer level here, but about component writer level. The only question is how facelets handles this case, but I assume faclets simply skips comments and passes it through with out.write! Dont get me wrong, but I have yet to see component code where the author is issuing a !-- instead of just setting an if which does not render anything! 2. This does cost performance in the server and all the corner cases can be handled on the Javascript side (and already are, as you mentioned in the beginning) Actually the funny thing is this does not cost any performance at all since it is done mostly with linear runtime complexity on the codeside (the evals are concatenated into a stringbuilder and after the end of the insert or update issued as eval section), embedded script parsing has a serious impact on the client side for some browsers (IE I am talking about you), which is the reason why I want to cover this on the server side if possible! 3. By default browsers should do an auto eval when xhr replaces scripts. IE doesn't, but this can be handled on the Javascript side. We shouldn't fix IE bugs in the ResponseWriterImpl. Doing it on the Javascript side only costs performance for browsers that don't support auto eval, the good guys will have a performance benefit. 4. RI doesn't do this kind of stuff. It may even break TCK compatibility. If it does we have to investigate why and to the worse simply turn it off, since it is just an extension class to our existing Impl class this is a non issue, but since it does not alter the standard behavior I rather doubt it! eval within an active update or insert also causes the same delay behavior! if non update or insert is issued before then simply render script src as eval! Well the corner case is this... If you are outside of an insert or update cycle the problem is following: What do you do with a simple issued script tag, you have to open an eval section in this case I am not sure what to do with simple issued html elements in this case! I have to test that but I assume the RI either throws an exception or renders buggy output in this case! (This case can happen only if you try to render the ppr cycle from begin to end yourself, otherwise, some parts of the framework have to issue the update automatically) Werner
Re: Myfaces 2.0 PPR ResponseWriter impl
Werner Punz schrieb: Dont get me wrong, but I have yet to see component code where the author is issuing a !-- instead of just setting an if which does not render anything! Ok even that we can cover, but the question is is the coverage of this corner case needed? As I said I have yet to see code which does this :-) Werner
AW: slf4j and myfaces
Hi! The only downside I see is that we might break compatibility for java 1.4 since JUL gut some overhaul between 1.4 and 5, but on the other hand is it really important anymore? Which projects still have to be on 1.4 In 1.4.2 the log methods in question were already there. So - as a logging user only - this might not be a problem. http://java.sun.com/j2se/1.4.2/docs/api/java/util/logging/Logger.html Ciao, Mario
Re: Myfaces 2.0 PPR ResponseWriter impl
Hi, -1 for script scanning on the server side. You will get into serious troubles with this. uff I think you got me wrong here what I propose to do is following writer.startElement(script writer.writeAttribute(src,bla.js should expand into eval![CDATA[ var script = myfaces.utils.loadScript(bla.js); eval(script); ]] /eval Yes, you are right, I got you wrong. You were saying We already have this covered in our javascript code by parsing the scripts, but I want to make a switch to have this turned off so I thought you wanted to preprocess all scripts on the server side. If it's only for writeElement/writeAttribute arguments are fewer. 1. You don't know whether the HTML part contains !-- (or some other kind of comment) before the tag that includes the startElement or the script src. that is a corner case we cannot really cover on writer level, the component author has to take care of it!) The normal case on the component side simply is !-- means that you dont write it out at all but leave it out. I am not talking about page designer level here, but about component writer level. The only question is how facelets handles this case, but I assume faclets simply skips comments and passes it through with out.write! I'm talking about !-- on the page level, not on the component level. Facelets will treat !-- as markup. Tags nested inside will still be evaluated. With the writeElement/writeAttribute solution this could end up in script being evaluated though nested inside !-- --. 2. This does cost performance in the server and all the corner cases can be handled on the Javascript side (and already are, as you mentioned in the beginning) Actually the funny thing is this does not cost any performance at all since it is done mostly with linear runtime complexity on the codeside (the evals are concatenated into a stringbuilder and after the end of the insert or update issued as eval section), embedded script parsing has a serious impact on the client side for some browsers (IE I am talking about you), which is the reason why I want to cover this on the server side if possible! Ok, I understand, there is no scanning, just another condition inside writeElement/writeAttribute. 3. By default browsers should do an auto eval when xhr replaces scripts. IE doesn't, but this can be handled on the Javascript side. We shouldn't fix IE bugs in the ResponseWriterImpl. Doing it on the Javascript side only costs performance for browsers that don't support auto eval, the good guys will have a performance benefit. 4. RI doesn't do this kind of stuff. It may even break TCK compatibility. If it does we have to investigate why and to the worse simply turn it off, since it is just an extension class to our existing Impl class this is a non issue, but since it does not alter the standard behavior I rather doubt it! You still modify the markup, this may even alter the page design. Well the corner case is this... If you are outside of an insert or update cycle the problem is following: What do you do with a simple issued script tag, you have to open an eval section in this case What do you want to express with outside of an insert or update cycle ? I am not sure what to do with simple issued html elements in this case! I have to test that but I assume the RI either throws an exception or renders buggy output in this case! (This case can happen only if you try to render the ppr cycle from begin to end yourself, otherwise, some parts of the framework have to issue the update automatically) Still unclear to me what you are referring to here. Best regards, Ganesh
Re: Myfaces 2.0 PPR ResponseWriter impl
Hi! Not sure if this adds any value to this discussion, but The only question is how facelets handles this case, but I assume faclets simply skips comments and passes it through with out.write! I'm talking about !-- on the page level, not on the component level. Facelets will treat !-- as markup. Tags nested inside will still be evaluated. With the writeElement/writeAttribute solution this could end up in script being evaluated though nested inside !-- --. You can configure this using facelets.SKIP_COMMENTS=true (what we did). Comments are comments then (and skipped) Hopefully mojarra will provide a setting for this too, and, even better, have true as default. Ciao, Mario
Re: slf4j and myfaces
I'd strongly prefer to see JUL instead of something else (including JCL) now that it's part of the standard. In Ganesh-speak, +0.9 JUL, -0.9 slf4j On Sat, Jun 6, 2009 at 6:37 AM, Mario Ivankovits ma...@ops.co.at wrote: Hi! The only downside I see is that we might break compatibility for java 1.4 since JUL gut some overhaul between 1.4 and 5, but on the other hand is it really important anymore? Which projects still have to be on 1.4 In 1.4.2 the log methods in question were already there. So - as a logging user only - this might not be a problem. http://java.sun.com/j2se/1.4.2/docs/api/java/util/logging/Logger.html Ciao, Mario
Re: Myfaces 2.0 PPR ResponseWriter impl
Ganesh schrieb: Well the corner case is this... If you are outside of an insert or update cycle the problem is following: What do you do with a simple issued script tag, you have to open an eval section in this case What do you want to express with outside of an insert or update cycle ? Following usecase: Someone writes the ppr response directly instead of going through the framework. What do you do in case of startElement(script then do you write it out or do you push it into an automated eval section! My personal guess is, after a second thought, you dont do anything special, you just should interfere with delayed evals in case an insert or update is issued and not finished, but I am not 100% sure!
Re: AW: slf4j and myfaces
Mario Ivankovits schrieb: Hi! The only downside I see is that we might break compatibility for java 1.4 since JUL gut some overhaul between 1.4 and 5, but on the other hand is it really important anymore? Which projects still have to be on 1.4 In 1.4.2 the log methods in question were already there. So - as a logging user only - this might not be a problem. http://java.sun.com/j2se/1.4.2/docs/api/java/util/logging/Logger.html Ok then everything is cleared up for me, then I am for JUL 100%, especially since it adds faster log handling with less locs compared to commons logging!
Re: Myfaces 2.0 PPR ResponseWriter impl
Hi, Let me summarize the arguments against pushing scripts to the eval section: 1. scripts inside !-- comments would suddenly become executed if facelets.SKIP_COMMENTS is false (which is the Facelets default) 2. omitting scripts within the markup may damage the layout 3. script order gets messed up if scripts rendered via startElement always come last 4. mojarra doesn't do it No pro arguments in sight, I guess ... Best regards, Ganesh Werner Punz schrieb: Ganesh schrieb: Well the corner case is this... If you are outside of an insert or update cycle the problem is following: What do you do with a simple issued script tag, you have to open an eval section in this case What do you want to express with outside of an insert or update cycle ? Following usecase: Someone writes the ppr response directly instead of going through the framework. What do you do in case of startElement(script then do you write it out or do you push it into an automated eval section! My personal guess is, after a second thought, you dont do anything special, you just should interfere with delayed evals in case an insert or update is issued and not finished, but I am not 100% sure!
[ANNOUNCE] MyFaces Core v1.2.7 Release
The Apache MyFaces team is pleased to announce the release of MyFaces Core 1.2.7. MyFaces Core is a JavaServer(tm) Faces 1.2 implementation as specified by JSR-252. MyFaces Core has passed Sun's JSR-252 TCK and is 100% compliant with the JSR-252 specification. MyFaces Core 1.2.7 is available in both binary and source distributions. * http://myfaces.apache.org/download.html MyFaces Core is also available in the central Maven repository under Group ID org.apache.myfaces.core. Release Notes - MyFaces Core - Version 1.2.7 Bug * [MYFACES-1761] - Handling PostConstruct annotations - wrong order * [MYFACES-1841] - HtmlResponseWriterImpl.writeURIAttribute does not perform proper URLs encoding ( ex: should be encoded in amp) * [MYFACES-1879] - Problems with myfaces when java2 security is enabled * [MYFACES-1891] - ClassCastException in converter when Hiding / Showing unselected selectOneRadio * [MYFACES-1975] - HtmlResponseStateManager.getSavedState() should handle javax.faces.ViewState= * [MYFACES-2007] - Converters are not created properly when target class is both, an enum and implements an interface * [MYFACES-2013] - h:dataTable renders caption facet twice on ear projects * [MYFACES-2099] - Detection of empty selection in UISelectOne through RenderUtils.NOTHING is faulty * [MYFACES-2134] - org.apache.myfaces.CONFIG_REFRESH_PERIOD != 0 causes a myfaces failure * [MYFACES-2139] - h:messages don't use styleClass attribute when rendering * [MYFACES-2144] - render-kit parsing problem * [MYFACES-2149] - Stream not closed * [MYFACES-2155] - HtmlLinkRenderer did not recognize ankers (#) * [MYFACES-2161] - MyFaces-API issue: getValue of UIInput * [MYFACES-2177] - ConvertDateTimeTag timeZone does not work with ValueExpression of return type String * [MYFACES-2214] - Cannot use custom error handler (param org.apache.myfaces.ERROR_HANDLER) due to bug in FacesServlet * [MYFACES-2232] - FacesConfig.getCurrentInstance and externalContext references should work before set application instance on facesContext init * [MYFACES-2233] - javax.faces.application.Application should check for default ApplicationImpl on methods added on 1.2 to enhance compatibility with existing jsf 1.1 apps as RI Improvement * [MYFACES-2156] - Performance improvement in HtmlRenderKitImpl * [MYFACES-2234] - add org.apache.myfaces.DELEGATE_FACES_SERVLET param, to make possible use other custom servlet instead FacesServlet New Feature * [MYFACES-1902] - Allow to use different ExpressionFactory implementation regards Leonardo Uribe
[ANNOUNCE] MyFaces Core v1.1.7 Release
The Apache MyFaces team is pleased to announce the release of MyFaces Core 1.1.7. MyFaces Core is a JavaServer(tm) Faces 1.1 implementation as specified by JSR-127. MyFaces Core has passed Sun's JSR-127 TCK and is 100% compliant with the JSR-127 specification. MyFaces Core 1.1.7 is available in both binary and source distributions. * http://myfaces.apache.org/download.html MyFaces Core is also available in the central Maven repository under Group ID org.apache.myfaces.core. Release Notes - MyFaces Core - Version 1.1.7 Bug * [MYFACES-1774] - HtmlLinkRenderer should output amp; instead of as the url param separator within href attribute according to HTML Spec * [MYFACES-1776] - f:view tag throws classcast exception if locale attribute is used on a portal page * [MYFACES-1841] - HtmlResponseWriterImpl.writeURIAttribute does not perform proper URLs encoding ( ex: should be encoded in amp) * [MYFACES-1891] - ClassCastException in converter when Hiding / Showing unselected selectOneRadio * [MYFACES-1975] - HtmlResponseStateManager.getSavedState() should handle javax.faces.ViewState= * [MYFACES-1981] - outputLink does not render onfocus and onblur * [MYFACES-2006] - getTableIndex: Integer to String (ClassCastException) * [MYFACES-2008] - Character encoding in Content-Type is ignored * [MYFACES-2099] - Detection of empty selection in UISelectOne through RenderUtils.NOTHING is faulty * [MYFACES-2139] - h:messages don't use styleClass attribute when rendering * [MYFACES-2155] - HtmlLinkRenderer did not recognize ankers (#) * [MYFACES-2160] - The action in tr:commandButton is not fired if you use the trinidad jsf library (in 1.1.5 it works). * [MYFACES-2167] - If graphicImage does not have value/url is not rendered in MyFaces Core JSF 1.1 Enjoy! regards Leonardo Uribe
[jira] Resolved: (TOBAGO-754) confirmation attribute in tc:message
[ https://issues.apache.org/jira/browse/TOBAGO-754?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bernd Bohmann resolved TOBAGO-754. -- Resolution: Fixed confirmation attribute in tc:message -- Key: TOBAGO-754 URL: https://issues.apache.org/jira/browse/TOBAGO-754 Project: MyFaces Tobago Issue Type: New Feature Components: Core Reporter: Thomas Renken Assignee: Udo Schnurpfeil Fix For: 1.0.21, 1.1.0 The default is false (same behaviour as now). If the feature is activated, the application require an explicit confirmation of the message. You may want to warn the user about a problem, and the user has to confirm the message before he/she can continue. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (TOBAGO-753) tc:popupReference/PopupActionListener should allow valueBinding
[ https://issues.apache.org/jira/browse/TOBAGO-753?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bernd Bohmann resolved TOBAGO-753. -- Resolution: Fixed Resolved for 1.0.x not for 1.1.x tc:popupReference/PopupActionListener should allow valueBinding --- Key: TOBAGO-753 URL: https://issues.apache.org/jira/browse/TOBAGO-753 Project: MyFaces Tobago Issue Type: Improvement Affects Versions: 1.0.20 Reporter: Volker Weber Assignee: Bernd Bohmann Fix For: 1.0.21, 1.1.0 tc:popupReference/PopupActionListener should allow valueBinding in the forComponent/popupId attribute -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (TOBAGO-626) Input length restriction for tc:textarea
[ https://issues.apache.org/jira/browse/TOBAGO-626?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bernd Bohmann resolved TOBAGO-626. -- Resolution: Fixed Input length restriction for tc:textarea Key: TOBAGO-626 URL: https://issues.apache.org/jira/browse/TOBAGO-626 Project: MyFaces Tobago Issue Type: Improvement Components: Themes Affects Versions: 1.0.16 Environment: All / IE Reporter: Helmut Swaczinna Assignee: Bernd Bohmann Fix For: 1.0.21, 1.1.0 Attachments: TOBAGO-626-core.diff, TOBAGO-626-theme-scarborough.diff, TOBAGO-626-theme-standard.diff The length of the input text in a tc:textrea should be restricted by the browser like it is in tc:in -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (TOMAHAWK-1208) NotSerializableException for org.apache.myfaces.custom.fileupload.UploadedFileDefaultMemoryImpl$1
[ https://issues.apache.org/jira/browse/TOMAHAWK-1208?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leonardo Uribe resolved TOMAHAWK-1208. -- Resolution: Fixed Fix Version/s: 1.1.9-SNAPSHOT Assignee: Leonardo Uribe Added test for object serialization and added inner classes that implements Serializable interface NotSerializableException for org.apache.myfaces.custom.fileupload.UploadedFileDefaultMemoryImpl$1 - Key: TOMAHAWK-1208 URL: https://issues.apache.org/jira/browse/TOMAHAWK-1208 Project: MyFaces Tomahawk Issue Type: Bug Components: File Upload Affects Versions: 1.1.7-SNAPSHOT Environment: Apache Tomcat 5.5.23, Tomahawk 1.1.7 Snapshot (8. January 2008), myfaces 1.1.6, tiles 2.0.5 Reporter: Erol Koc Assignee: Leonardo Uribe Fix For: 1.1.9-SNAPSHOT Since we decided to use Tiles 2 in our project, we had to upgrade from tomahawk 1.1.6 to the next available version (currently tomahawk 1.1.7 snapshot) to be able to use the JspTilesTwoViewHandler. However, with this upgrade, we now get the following exception on pages using the t:inputFileUpload tag: ERROR 03/Mar/08:14:48:08: Exiting serializeView - Could not serialize state: org.apache.myfaces.custom.fileupload.UploadedFileDefaultMemoryImpl$1 org.apache.myfaces.application.jsp.JspStateManagerImpl:520 java.io.NotSerializableException: org.apache.myfaces.custom.fileupload.UploadedFileDefaultMemoryImpl$1 at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1081) at java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1375) at java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1347) at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1290) at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1079) at java.io.ObjectOutputStream.writeArray(ObjectOutputStream.java:1251) at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1075) at java.io.ObjectOutputStream.writeArray(ObjectOutputStream.java:1251) at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1075) at java.io.ObjectOutputStream.writeArray(ObjectOutputStream.java:1251) at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1075) at java.io.ObjectOutputStream.writeArray(ObjectOutputStream.java:1251) at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1075) at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:302) at java.util.ArrayList.writeObject(ArrayList.java:569) at sun.reflect.GeneratedMethodAccessor268.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) To be more precise: the exception occurrs on pages containing a sortable table and the and at least one t:inputFileUpload (both in the same form). Whenever the table is sorted, the exception is thrown. Unfortunately, all other command links do not work for the next click! The $1 at the end of UploadedFileDefaultMemoryImpl$1 indicates that there is an inner class which does not implement the Serializable interface. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (MYFACES-2240) typo in javascript build script and target folder doesn't fit the spec
typo in javascript build script and target folder doesn't fit the spec -- Key: MYFACES-2240 URL: https://issues.apache.org/jira/browse/MYFACES-2240 Project: MyFaces Core Issue Type: Sub-task Components: JSR-314 Affects Versions: 2.0.0-alpha Environment: Maven/Javascript Reporter: Ganesh Jung Assignee: Ganesh Jung Priority: Trivial path for source jsf.js must be include**/api/jsf.js/include not include**./api/jsf.js/include correct folder for jsf.js is /META-INF/resources/javax.faces/jsf.js not /META-INF/resources/javax/faces/ajax/jsf.js -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (MYFACES-2240) typo in javascript build script and target folder doesn't fit the spec
[ https://issues.apache.org/jira/browse/MYFACES-2240?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ganesh Jung resolved MYFACES-2240. -- Resolution: Fixed Fix Version/s: 2.0.0-alpha fixed committed typo in javascript build script and target folder doesn't fit the spec -- Key: MYFACES-2240 URL: https://issues.apache.org/jira/browse/MYFACES-2240 Project: MyFaces Core Issue Type: Sub-task Components: JSR-314 Affects Versions: 2.0.0-alpha Environment: Maven/Javascript Reporter: Ganesh Jung Assignee: Ganesh Jung Priority: Trivial Fix For: 2.0.0-alpha Original Estimate: 3h Remaining Estimate: 3h path for source jsf.js must be include**/api/jsf.js/include not include**./api/jsf.js/include correct folder for jsf.js is /META-INF/resources/javax.faces/jsf.js not /META-INF/resources/javax/faces/ajax/jsf.js -- 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 and javascript compression
Hi,
This is nice stuff - works fine. I'm using Mojarra plus this generated
MyFaces jsf.js for the dojo facelets example page and it improves the
f:ajax functionality quite a bit! What is your reason to comment it?
Could stay uncommented IMO.
Best regards,
Ganesh
Werner Punz schrieb:
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: slf4j and myfaces
I second what mike said. On Sat, Jun 6, 2009 at 4:47 AM, Mike Kienenbergermkien...@gmail.com wrote: I'd strongly prefer to see JUL instead of something else (including JCL) now that it's part of the standard. In Ganesh-speak, +0.9 JUL, -0.9 slf4j On Sat, Jun 6, 2009 at 6:37 AM, Mario Ivankovits ma...@ops.co.at wrote: Hi! The only downside I see is that we might break compatibility for java 1.4 since JUL gut some overhaul between 1.4 and 5, but on the other hand is it really important anymore? Which projects still have to be on 1.4 In 1.4.2 the log methods in question were already there. So - as a logging user only - this might not be a problem. http://java.sun.com/j2se/1.4.2/docs/api/java/util/logging/Logger.html Ciao, Mario -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf
