[tomahawk] rename t:xmlTemplate to t:xmlTransform and all related names
Hi Checking the code I have seen that the component t:xmlTemplate was moved to tomahawk core, but the component was not renamed according to the vote. I'll rename it right now. regards Leonardo Uribe
Re: [myfaces-builder-plugin] can we do a release of it?
On Tue, Jul 22, 2008 at 11:19 AM, Leonardo Uribe [EMAIL PROTECTED] wrote: On Tue, Jul 22, 2008 at 11:33 AM, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] schrieb: An alternative is to split things up so that the parent pom (the pom that other modules inherit from) is not the module pom (the one used to drive bulk builds of nested directories). A subdirectory can be created, the existing pom moved down into it, and a new trivial pom created in the base directory that just has module tags in it. I don't see any need to change the artifactId for the parent pom, so AFAIK simply moving it within svn should not break anything. For example, the main myfaces pom is in its own subdir, and has no module tags. The Orchestra code is also set up like this, with the parent pom in the myfaces/orchestra/maven dir, and the myfaces/orchestra/pom.xml file (which is never released) just contains module tags. Setting things up like this makes sense when the various subdirs have different release cycles, as is the case for Myfaces in general (core, core12, tomahawk, trinidad, etc have different release cycles) and Orchestra (core, core15, flow have different release cycles). Of course thinks like (core/api, core/impl) do not have independent release cycles, so having the module pom also be the parent pom makes sense there. I think that the build-tools modules do (or should) have independent release cycles, so pushing the parent pom into a subdir makes sense there. And if it is pushed down into its own dir, then you could also use the maven-release-plugin to release it :-) Comments, anyone? Are there any objections if I move the parent pom for the maven2-plugins into its own subdir? If not, I'll try to find time to do that tonight... +1, we need to make more modular this part for release plugins The change was applied, so I'll start the procedure for release myfaces-builder-plugin, myfaces-builder-annotations and the moved myfaces-plugin-parent.
百分百营销软件网发送的测试信息。
[EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED]
Re: [tomahawk] rename t:xmlTemplate to t:xmlTransform and all related names
Yes Leonardo. I was about to do this as well. Thank you. On Mon, Jul 28, 2008 at 3:24 PM, Leonardo Uribe [EMAIL PROTECTED] wrote: Hi Checking the code I have seen that the component t:xmlTemplate was moved to tomahawk core, but the component was not renamed according to the vote. I'll rename it right now. regards Leonardo Uribe -- Hazem Ahmed Saleh Ahmed http://www.jroller.com/page/HazemBlog
Re: 百分百营销软件网发送的测试信息。
Sorry guys, I hit the wrong button in my mail app when browsing 200 moderate mails after coming back from vacation... Time for a coffee! ;-) --Manfred On 7/27/08, 百分百营销软件网 [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
MYFACES-1900: any news?
Hi MyFaces devs, Is there any news about MYFACES-1900? The error prevents me from deploying myfaces-1.2.3, so I'm stuck with 1.2.2. The fix can't be that hard, just roll back the change in the oamSubmitForm() JavaScript from 1.2.2 to 1.2.3, right? Kind regards, -- -- Gertjan van Oosten, [EMAIL PROTECTED], West Consulting B.V., +31 15 2191 600
Re: commons logging again
I have used SLF4J for some time now in a number of projects and did
not have any (serious) problem yet.
The biggest problem was that some classes where not serializable. So
when used in web apps that store objects with loggers in session or
client this was an issue of course. But this was fixed in the latest
stable release.
What I like about SLF4J is the clear separation of the API for
compiletime/runtime and the log implementation specific stub libraries
for runtime only. When using with Maven you can have clean
dependencies:
1. define a *compile* dep to slf4j-api for all your modules
2. define a *test* dep to slf4j-log4j12 to log unit testing output with Log4J
3. define a *runtime* dep to slf4j-log4j12 for the webapp module to
log with Log4J
4. define a *runtime* dep to jcl-over-slf4j to reroute third-party
lib's JCL logging over SLF4J
So, if (for some reason) you want to switch over from Log4J to
JDK-Logging all you need to do is replace the runtime dep to
slf4j-log4j12 (number 3) by a dependency to slf4j-jdk14.
Another nice feature of SLF4J is the chance to get rid of those ugly
if(logger.isDebugEnabled()) { lines by using parameterized messages
(see http://www.slf4j.org/faq.html#logging_performance)
--Manfred
On 7/14/08, Werner Punz [EMAIL PROTECTED] wrote:
Ok I just saw that the slf4j people provide a thin api layer
which replaces the commons logging if needed.
Then probably replacing commons logging is a non issue.
I just was raising this issue again, due to the problems i read
about log4j especially in combination with was and other big irons
which drop their own classloaders, and due to the fact that I feel
it is generally a bad idea for a low level library to have too many
dependencies into other libs.
Werner
[EMAIL PROTECTED] schrieb:
Werner Punz schrieb:
Hello everyone, we have been using commons-logging the past years.
I am not sure if it is a good idea,
first of all java has a decent logging api, which would allow us to
eliminate the logging dependency.
Using a logging API built into the JDK does feel tempting.
However before doing this, have a look at the number of alternative
implementations of the API.
* The one built into the JDK sucks. badly.
* There is one that is built into Tomcat (JULI) but that is not
available as a standalone lib.
* The SLF4J project provides jcl-over-slf4j. I haven't used this
myself, but presume that it needs to be in the system classpath to work
(one of the major issues with the java.util.logging design). So I'm not
sure how that would interact with Tomcat's JULI logging. See:
http://slf4j.org/api/org/slf4j/bridge/SLF4JBridgeHandler.html
I'm not aware of any other implementations.
And I'm not at all sure whether it is possible for different webapps
running in the same container to have different logging configuration.
It would be ugly to force a solution on users where all logging from all
their webapps ends up mixed together in the same output file. So I would
suggest analysing things carefully before moving to java.util.logging.
I have the feeling that java.util.logging was designed by Sun JDK
implementers to help debugging JDK (java.*) code. For that purpose it
works fine. Using it from application code seems far less useful..
Secondly,I have not looked into the code yet, but there are a load
of references that commons logging has problems due to messing around
with the classloader.
That's an ancient issue. There have been zero issues related to this
reported since the 1.1 commons release.
Projects like Tapestry already have moved away towards SLF4J which
apparently is better.
apparently doesn't sound like a terribly convincing reason to me to
move from one log wrapper to another.
Whats your opinion should we keep the commons logging
references?
Despite being a commons-logging developer, I don't care what
implementation is used. But AFAIK we do have a working solution now; I'd
like to be sure that whatever we move towards
(a) actually does work (java.util.logging), and
(b) brings benefits that are worth the effort of converting over (slf4j)
Regards,
Simon
--
http://www.irian.at
Your JSF powerhouse - JSF Consulting,
Development and Courses in English and
German
Professional Support for Apache MyFaces
[VOTE] release for myfaces builder plugin 1.0.1
Hi, I was running the needed tasks to get the 1.0.1 release of Apache MyFaces Builder Plugin out. Please note that this vote concerns all of the following parts: 1. Maven artifact group org.apache.myfaces.buildtools v1.0.0 (only myfaces-builder-plugin, myfaces-builder-annotations, myfaces-plugin-parent) [1] The artifacts are deployed to my private Apache account ([1]). Please take a look at the 1.0.1 artifacts and vote! Please note: This vote is majority approval with a minimum of three +1 votes (see [3]). [ ] +1 for community members who have reviewed the bits [ ] +0 [ ] -1 for fatal flaws that should cause these bits not to be released, and why.. Thanks, Leonardo Uribe [1] http://people.apache.org/~lu4242/m2-plugins-101 [2] http://www.apache.org/foundation/voting.html#ReleaseVotes
Re: [VOTE] release for myfaces builder plugin 1.0.1
+1 On Mon, Jul 28, 2008 at 4:49 PM, Leonardo Uribe [EMAIL PROTECTED] wrote: Hi, I was running the needed tasks to get the 1.0.1 release of Apache MyFaces Builder Plugin out. Please note that this vote concerns all of the following parts: 1. Maven artifact group org.apache.myfaces.buildtools v1.0.0 (only myfaces-builder-plugin, myfaces-builder-annotations, myfaces-plugin-parent) [1] The artifacts are deployed to my private Apache account ([1]). Please take a look at the 1.0.1 artifacts and vote! Please note: This vote is majority approval with a minimum of three +1 votes (see [3]). [ ] +1 for community members who have reviewed the bits [ ] +0 [ ] -1 for fatal flaws that should cause these bits not to be released, and why.. Thanks, Leonardo Uribe [1] http://people.apache.org/~lu4242/m2-plugins-101 http://people.apache.org/%7Elu4242/m2-plugins-101 [2] http://www.apache.org/foundation/voting.html#ReleaseVotes
Re: Odd generated component classes in the JSF1.2 trunk
On Tue, Jul 15, 2008 at 1:55 PM, simon [EMAIL PROTECTED] wrote: On Mon, 2008-07-14 at 16:36 +0200, Leonardo Uribe wrote: On Sun, Jul 13, 2008 at 12:48 PM, simon [EMAIL PROTECTED] wrote: Hi, I've just noticed that quite a few component classes are checked in to the JSF 1.2 trunk, but carry big generated code, do not modify warnings. And they look completely different from the versions in the JSF1.1 branch. Examples: UICommand.java UIData.java UIGraphic.java UIInput UINamingContainer I'm a little confused here. Can someone (Leonardo?) explain what is happening here? This comments should be removed, since this classes are not generated. But the weird thing is that they *look* generated. The code is just all over the place, variables declared in the middle of the file, odd line wrapping. And all the documentation that was on the UIData class is completely gone. I don't know what is going on here, but it feels wrong. When myfaces core 1.2 started, all classes were generated using myfaces-faces-plugin template approach, so the old code was just replaces. That is the reason because myfaces 1.1 component classes looks different from its 1.2 counterparts. Then, myfaces-builder-plugin was applied, so some generated classes using myfaces-faces-plugin were just moved to src/main/java. I have removed the wrong warnings, since this core classes should not be generated (makes easier to users to check if something is wrong). At a guess, it looks to me like the difference between JSF1.1 and JSF1.2 code is that in jsf1.2 things are set up to auto-generate the saveState/restoreState methods for these components, while in JSF1.1 branch it is not (hand-coded implementations are still used). But: * I would not expect any auto-generated classes to be checked in. * I would expect a private base class, or template class to exist which the generated class is derived from. But I can see no such thing (eg no _UIData class). The classes listed above just look horrible; something really does need to be done about this. Some classes that extends from UIComponent has its own custom code, so in my opinion it is better to let is without generation pattern (in this case template pattern is the only way but it is not too much flexible as myfaces-faces-plugin). It is more clear for developers. I don't understand this. I'll try reading it again after my upcoming holiday, maybe my brain will work better then :-) Regards, Simon
