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
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
[
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
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
+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
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
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
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
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.
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
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
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
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
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
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)
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
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
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 =
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 !--
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
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 ?
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
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
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
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
[
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
[
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
[
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
[
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
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
[
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
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
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
33 matches
Mail list logo
