Re: Jira rights to set an issue to 'resolved'
Just fixed that. Mark, you are now in the myfaces-committers jira group. --Manfred On Sat, Feb 5, 2011 at 20:31, Gerhard gerhard.petra...@gmail.com wrote: maybe you aren't listed as committer (in jira). @workflow: +1 regards, gerhard http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces 2011/2/5 Mark Struberg strub...@yahoo.de Hi! I have (hopefully) resolved MYFACES-3024 but I cannot set it to 'resolved' with our new Jira. How does our new workflow look like? open - resolved - fixed (via bulk after a release) ? LieGrue, strub
Re: [VOTE] use of jul or commons logging on myfaces core 2.0
+1 for JUL On Tue, Oct 6, 2009 at 17:02, Matthias Wessendorf mat...@apache.org wrote: +1 for JUL On Sat, Oct 3, 2009 at 10:41 AM, Jan-Kees van Andel jankeesvanan...@gmail.com wrote: +1 for JUL. Jan-Kees van Andel 2009/10/1 Mike Kienenberger mkien...@gmail.com: +1 for jul -- it's not ideal, but it's the standard and doesn't require any dependencies. On Thu, Oct 1, 2009 at 12:22 PM, Grant Smith work.gr...@gmail.com wrote: +1 java.util.logging.Logger On Thu, Oct 1, 2009 at 9:14 AM, Michael Concini mconc...@gmail.com wrote: +1 for JUL Antonio Petrelli wrote: 2009/10/1 Werner Punz werner.p...@gmail.com: Why don't you consider using SLF4J? Probably it is the same question asked over and over again, but I try anyway :-D That would be a dependency replacement with another. Just my personal opinion regarding SLF4J Don't bother, I noticed that there is a bridge with which you can use JUL messages with SLF4J: http://www.slf4j.org/legacy.html For a library like MyFaces makes perfectly sense. Antonio -- Grant Smith -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf
Re: jira organisation question regarding myfaces-extensions
+1 On Fri, Aug 14, 2009 at 20:58, Gerhard Petracekgerhard.petra...@gmail.com wrote: hi, i was told that independent releases of the different subprojects wouldn't be possible. it seems that this information isn't correct. however, the much more interesting part is that the constellation at trinidad is ok because these parts belong together. that's not the case with myfaces extensions. since we don't expect that much subprojects i think we should continue to have a jira project for each extension project. furthermore, it would get a bit confusing to have one jira project and a lot of components which don't belong together. if we keep the current structure, we have: jira project: EXTVAL component: Core component: Property Validation component: Bean Validation component: Generic Support component: Trinidad Support and e.g.: jira project: EXTSCRIPT component: Core component: Groovy component: [other scripting language] so it's a clear separation... if there are no major concerns about it, i think we should keep it as it is. regards, gerhard http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces 2009/8/14 Matthias Wessendorf mat...@apache.org On Fri, Aug 14, 2009 at 11:04 AM, Werner Punzwerner.p...@gmail.com wrote: Werner Punz schrieb: Hello everyone while I am preparing my initial commit I noticed following. We have a subproject for extension-extval but nothing more in this regard. Which means since I cannot open my own subproject in jira I am somehow blocked. Wouldnt it be better to have the project itself reside under extensions and then have different modules for extval, groovy etc.? Ok Gerhard just gave me the explanation, it has something to do with the release management. I think that in Trinidad it pretty much works well. We have plugin releases and core releases. With different release notes. Not sure what he means. Perhaps he could jump in ?! Anyway Manfred, Matthias, can anyone of you open an extensions-groovy jira subprojekt for me? Werner -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf
Re: [VOTE] SVN structure change (was: Re: [MyFaces CORE] SVN layout (was: Re: [source control] git and the ASF ...))
+1 thanks leonardo --Manfred On Thu, Jul 9, 2009 at 04:24, Leonardo Uribelu4...@gmail.com wrote: Hi Myfaces core 1.2.7 and 1.1.7 were released. So we can close this vote and make the necessary changes. Just to note it, after reading all previous emails the suggested layout is this: /trunk - 2.0 /branches/1.1.x /branches/1.2.x If no objections I'll do the necessary changes on svn (note that to do this change we need to update nightly build configuration and I can't help with that). regards Leonardo Uribe 2009/5/28 Simon Lessard simon.lessar...@gmail.com +1 On Thu, May 28, 2009 at 2:23 AM, Matthias Wessendorf mat...@apache.org wrote: sure! On Thu, May 28, 2009 at 6:34 AM, Leonardo Uribe lu4...@gmail.com wrote: +1, but just a small suggestion. Right now I'm running the necessary steps for release myfaces core 1.2.7, core 1.1.7, so I would like if it is possible to delay this change after the release. regards Leonardo Uribe 2009/5/27 Cagatay Civici cagatay.civ...@gmail.com +1 for sure On Wed, May 27, 2009 at 8:53 AM, Bruno Aranda brunoara...@gmail.com wrote: +1 sounds good to me 2009/5/27 Matthias Wessendorf mat...@apache.org: so, there are no objections in making the MyFaces 2.0 efforts become trunk ? -Matthias On Fri, May 22, 2009 at 9:10 PM, Bernd Bohmann bernd.bohm...@atanion.com wrote: Hello, +1 I would prefer /trunk - 2.0 /branches/myfaces-1.1.x /branches/myfaces-1.2.x because we are not using cvs anymore and the path already contains http://svn.apache.org/repos/asf/myfaces/core/ maybe we can omit the 'myfaces' in the branch name. Regards Bernd On Fri, May 22, 2009 at 5:27 PM, Matthias Wessendorf mat...@apache.org wrote: actually, I agree with Bernd. For the following layout: /trunk - 2.0 /branches/myfaces_1_1_x /branches/myfaces_1_2_x Two reasons for way making 2.0 trunk: -most current development is on-going in 2.0 (new spec) -most commits are going to the 2.0 branch (so, let's make it trunk) So, I am +1 on the above svn layout -Matthias On Sat, May 16, 2009 at 1:04 PM, Matthias Wessendorf mat...@apache.org wrote: from Bernd, on a different thread: Hello, I would suggest following layout 1.1.x branch/1.1.x 1.2.x branch/1.2.x 2.0.x trunk because the 2.0.x version is in development the other branches are only in bugfix state. On Fri, May 15, 2009 at 1:13 PM, Werner Punz werner.p...@gmail.com wrote: Matthias Wessendorf schrieb: Hi, ... Ok, I filed this: https://issues.apache.org/jira/browse/INFRA-2053 maybe we should also think about making the JSF 1.1.x stuff a branch ... (since we already work on 2.0.x) what do people think if the 1.2 stuff becomes trunk And the following efforts are on a branch: -2.0.x -1.1.x +1 -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf
Re: MyFaces Core + Trinidad + Facelets in OSGi container
+1 would be great thanks, Manfred 2009/7/9 Felix Röthenbacher froethenbac...@apache.org: Hi I recently made some modifications to MyFaces Core and MyFaces Trinidad to get it running in an OSGi container (Equinox) together with Facelets. I wonder if there is any interest in adding bundle metadata to MyFaces Core and Trinidad to make them runnable in an OSGi environment? If so, I could finalize my modifications and submit a patch with the necessary changes. Basically, the changes include: - adding bundle information in MANIFEST.MF (uses Maven bundle plugin) - assure that classes and resources are loaded with proper class loaders The changes to MyFaces core are minor, e.g. adding a bundle activator and small modifications to ClassUtil for class loading. Modifications to Trinidad comprise a systematic use of ClassLoaderUtils to load classes and resources. Currently, often Thread.currentThread.getContextClassLoader() is used directly, which doesn't work well in an OSGi environment. WDYT? - Felix
Re: Caching the result of an EL expression evaluation with in a life cycle
A standard EL expression evaluator cannot and MUST never cache results.
Imagine the following expression:
h:outputText#{someBean.nextCounterValue}/h:outputText
The app developer would not be very happy if EL caches that result, right?
So caching can only be a matter for the model.
OR: you write your own custom ELResolver that somehow knows which
values to cache and which it should not cache. Perhaps by inspecting
the annotations of your getters? I could imagine a custom @Cacheable
annotation for that purpose.
However, there is no magic config param. Sorry.
--Manfred
On Fri, Jun 26, 2009 at 03:36, Sam Wittysamkwi...@yahoo.com wrote:
If you have the following code:
h:h:outputText#{someBean.user.firstName}/h:outputText
h:h:outputText#{someBean.user.lastName}/h:outputText
h:h:outputText#{someBean.user.age}/h:outputText
and if SomeBean.user() is a call to the db then every one of the above
expressions will cause a trip to the db. Of course to get around this one
simply has to cache the value of user from the db (the first time) and then
return the cached value instead of going to the db again.
This is all well and good... however, I find myself writing a lot of this
type of caching code in various places. It would seem that a much elegant
solution would be to have the EL expression evaluator cache the result of an
expression within a life cycle avoiding the need for every JSF developer to
sprinkle caching code all over the place.
Then again there maybe something out there that does this already (magical
config param?) I just could not find anything.
Thanks
-Sam
--
View this message in context:
http://www.nabble.com/Caching-the-result-of-an-EL-expression-evaluation-with-in-a-life-cycle-tp24213650p24213650.html
Sent from the My Faces - Dev mailing list archive at Nabble.com.
Re: JSF 'blockinput' component
Yep, GPL might be a problem. Easiest think might be to switch to ASF-license prior to donating this bit. Thanks, Manfred On Thu, Jun 18, 2009 at 15:46, Cagatay Civicicagatay.civ...@gmail.com wrote: Looks nice but not sure about the license. On Thu, Jun 18, 2009 at 8:44 AM, Roger Laenen roger.lae...@telenet.be wrote: Hello, I've made a custom facelets component that simulates 'cell/block based' input like you find on official input forms. This type of input field can be useful in some specific situations. We use it for a bankaccount field with specific formatting and validation. You can find binaries and svn-trunk on http://code.google.com/p/blockinput An example app is also included. I thought it would maybe be interesting for inclusion in tomahawk. If there is any interest, let me know. grtz, Roger.
Re: [VOTE] jul instead of commons-logging
+0.5 I like SLF4J as well, but I won't get in the way of JUL. Never used JUL myself, so I don't know for sure if there might be any hidden quirks. ;-) --Manfred On Tue, Jun 9, 2009 at 20:32, Gerhard Petracekgerhard.petra...@gmail.com wrote: hi, short description: this first vote is about the switch from commons-logging (cl) to java.util.logging (jul). it's a binding vote for the next releases of all myfaces libs which are currently using commons-logging. so e.g. trinidad isn't affected. details are available at [1] if there won't be a majority, we will open a second vote (switch from commons-logging to slf4j). [ ] +1 for replacing cl with jul [ ] +0 [ ] -1 for keeping cl or to force a second vote for slf4j as replacement regards, gerhard [1] http://www.nabble.com/slf4j-and-myfaces-td23890255.html
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: 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: License question
On Wed, Jun 3, 2009 at 15:49, Matthias Wessendorf mat...@apache.org wrote: On Tue, Jun 2, 2009 at 5:57 PM, Cagatay Civici cagatay.civ...@gmail.com wrote: Hi guys, I've question regarding licensing. For a side open source project(PrimeFaces), I needed access to package private StateWriter class and as a hack I added com.sun.facelets package to the project. That way I got the access for that class. Does anyone see a legal issue here? no, why ? you just fake the package in order to get more to see Hmm. Don't think it's _that_ easy. For instance the java. and javax. namespaces are reserved and must not be used by any (official) product that does not implement the regarding JCR. However. I am not a lawer and I have no idea if that also applies to hacks and I do not know if there is a precendent about using a foreign reserved domain name as java namespace. My feeling is, that it is ok for the hack. But I'm not totally sure. --Manfred
[jira] Commented: (ORCHESTRA-40) A transaction token component inspired by the struts transaction processor
[ https://issues.apache.org/jira/browse/ORCHESTRA-40?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12706086#action_12706086 ] Manfred Geiler commented on ORCHESTRA-40: - The LOG.error should be replaced by a LOG.debug in the TransactionTokenPhaseListener. (looks like a debugging remainder) A transaction token component inspired by the struts transaction processor -- Key: ORCHESTRA-40 URL: https://issues.apache.org/jira/browse/ORCHESTRA-40 Project: MyFaces Orchestra Issue Type: New Feature Components: Conversation Affects Versions: 1.3.1 Reporter: Bernd Bohmann Assignee: Simon Kitching Attachments: ORCHESTRA-40-CacheControl+TransactionToken-before-restore-View2.patch, ORCHESTRA-40-CacheControl+TransactionTokenListener-after-restore-View3.patch, ORCHESTRA-40-CacheControl.patch, ORCHESTRA-40-TransactionToken.patch A transactionToken Component for orchestra inspired by the struts transaction processor. The transaction token is to be used for enforcing a single request for a particular transaction. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Connect my committer account to jira
done. Ganesh, Alexander, Michael, you are all three now member of the jira group myfaces committers --Manfred On Fri, May 1, 2009 at 12:03, Matthias Wessendorf mat...@apache.org wrote: Hello Manfred, can you do the jira-update for all the three new committers ? :-) Thanks! Matthias On Fri, May 1, 2009 at 11:47 AM, Ganesh gan...@j4fry.org wrote: Hi, How do I connect my jira account (ganesh.jung) to my committer account (ganesh)? I want to assingn jira tasks to myself which isn't possible with my current jira account. Best Regards, Ganesh -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf
[jira] Commented: (ORCHESTRA-40) A transaction token component inspired by the struts transaction processor
[ https://issues.apache.org/jira/browse/ORCHESTRA-40?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12705595#action_12705595 ] Manfred Geiler commented on ORCHESTRA-40: - MANAGED_BEAN_NAME = org.apache.myfaces.orchestra.TransactionToken is suboptimal because dots are (officially) not allowed within a managed bean name. Only underscores, letters and digits are allowed according to jsf spec. A transaction token component inspired by the struts transaction processor -- Key: ORCHESTRA-40 URL: https://issues.apache.org/jira/browse/ORCHESTRA-40 Project: MyFaces Orchestra Issue Type: New Feature Components: Conversation Affects Versions: 1.3.1 Reporter: Bernd Bohmann Assignee: Simon Kitching Attachments: ORCHESTRA-40-CacheControl+TransactionToken-before-restore-View2.patch, ORCHESTRA-40-CacheControl+TransactionTokenListener-after-restore-View3.patch, ORCHESTRA-40-CacheControl.patch, ORCHESTRA-40-TransactionToken.patch A transactionToken Component for orchestra inspired by the struts transaction processor. The transaction token is to be used for enforcing a single request for a particular transaction. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Jira account for developers
yeah, of course. Jan-Kees, you were not in the myfaces-committers group on Jira. I fixed that. @all, FYI: There are actually 4 myfaces related groups on Jira. The permissions are equal to the standard roles that are used by almost all Apache projects: myfaces-administrators ... people allowed to manage Jira groups/permissions myfaces-contributors ... contributors and committer candidates (allowed to edit issues) myfaces-committers ... committers (additionally allowed to delete issues and comments) myfaces-pmc ... PMC members --Manfred On Wed, Apr 15, 2009 at 22:49, Matthias Wessendorf mat...@apache.org wrote: Hey Manfred, do you know if this is fixable via the JIRA configurations ? -Matthias On Wed, Apr 15, 2009 at 8:24 PM, Jan-Kees van Andel jankeesvanan...@gmail.com wrote: Hi, Last week I've committed the fix for a Jira issue, but I can't resolve the issue, because my Jira account seems to be separated from my Apache account. Am I missing the needed roles in Jira? I authenticate on Jira using my Apache username/email address. Someone knows the answer? It would definitely make work easier. ;-) Thanks, Jan-Kees -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf
Re: CI server support / setup (was Fwd: Buildbot at Apache, and a new builds mailing list.)
+1 for moving to new infrastructure --Manfred On Wed, Apr 15, 2009 at 10:02, Matthias Wessendorf mat...@apache.org wrote: Hi, attached is an announcement that there is now a nice support for CI servers. I'd like to move the myfaces (sub) projects to this new infrastructure. What do folks think about that ? I mean in the past our own zone somewhat worked, but the server had also every now and than its hick-ups. so, I am +1 in moving forward to the new Buildbot. what do folks think about it ? -Matthias -- Forwarded message -- From: Gavin ga...@16degrees.com.au Date: Sat, Apr 11, 2009 at 11:15 AM Subject: Buildbot at Apache, and a new builds mailing list. To: p...@apache.org Hi All, This is a heads-up that Buildbot CI server is now available for projects use. Some projects that have been used for testing Buildbot here at the ASF can be seen at http://ci.apache.org. I have a development installation at http://build01.16degrees.com.au:8020/waterfall where I have been testing many more projects (about 20 including the Buildbot project itself). Any new or existing project that wants to add Buildbot to their arsenal of tools to help them build,test,snapshot,deploy,etc can create an issue on the Infrastructure Issue Tracker : https://issues.apache.org/jira/browse/INFRA/component/12312782 There has been a new mailing list created specifically for all our CI servers (Buildbot, Hudson, Continuum) - bui...@apache.org - sign up at builds-subscr...@apache.org . I made use of our infra blog and posted a short note about it at https://blogs.apache.org/infra/entry/new_mailing_list_for_ci So, any requests to make use of any of the build servers are made to the appropriate Jira component on the Infra Issue Tracker. All discussions regarding them should be directed to the bui...@apache.org list from now on. Thanks, and see you there! Gav... - To unsubscribe, e-mail: private-unsubscr...@incubator.apache.org For additional commands, e-mail: private-h...@incubator.apache.org -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf
[jira] Updated: (MYFACES-2154) mobile internet explorer version 6.12 issue
[
https://issues.apache.org/jira/browse/MYFACES-2154?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Manfred Geiler updated MYFACES-2154:
Status: Patch Available (was: Open)
mobile internet explorer version 6.12 issue
---
Key: MYFACES-2154
URL: https://issues.apache.org/jira/browse/MYFACES-2154
Project: MyFaces Core
Issue Type: Improvement
Components: General
Environment: mobile internet explorer version 6.12
MyFaces v???
Reporter: Manfred Geiler
Tobias Bräuer reported the following issue:
Hello,
There is a problem with mobile internet explorer version 6.12 and
myfaces. The browser sends a Accept:
application/vnd.wap.mms-message;*/*. We solved that problem by adding
the following code in the class
org.apache.myfaces.shared_impl.renderkit.html.HtmlRendererUtils at
line 1619. If used with tomahawk, the same fix is needed there.
I have no idea how your community process works, but feel free to add
the code to your repository.
if (contentTypeListString == null) {
FacesContext context =
FacesContext.getCurrentInstance();
if (context != null) {
contentTypeListString = (String)
context.getExternalContext()
.getRequestHeaderMap().get(Accept);
// There is a windows mobile IE client (6.12)
sending
// application/vnd.wap.mms-message;*/*
// This is a workaround ...
if (contentTypeListString
.startsWith(application/vnd.wap.mms-message;*/*)) {
contentTypeListString = */*;
}
}
if (contentTypeListString == null) {
if (log.isDebugEnabled())
log
.debug(No content
type list given, creating
HtmlResponseWriterImpl with default content type.);
contentTypeListString = HTML_CONTENT_TYPE;
}
}
Cheers,
Tobias Bräuer
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (MYFACES-2154) mobile internet explorer version 6.12 issue
mobile internet explorer version 6.12 issue
---
Key: MYFACES-2154
URL: https://issues.apache.org/jira/browse/MYFACES-2154
Project: MyFaces Core
Issue Type: Improvement
Components: General
Environment: mobile internet explorer version 6.12
MyFaces v???
Reporter: Manfred Geiler
Tobias Bräuer reported the following issue:
Hello,
There is a problem with mobile internet explorer version 6.12 and
myfaces. The browser sends a Accept:
application/vnd.wap.mms-message;*/*. We solved that problem by adding
the following code in the class
org.apache.myfaces.shared_impl.renderkit.html.HtmlRendererUtils at
line 1619. If used with tomahawk, the same fix is needed there.
I have no idea how your community process works, but feel free to add
the code to your repository.
if (contentTypeListString == null) {
FacesContext context = FacesContext.getCurrentInstance();
if (context != null) {
contentTypeListString = (String)
context.getExternalContext()
.getRequestHeaderMap().get(Accept);
// There is a windows mobile IE client (6.12)
sending
// application/vnd.wap.mms-message;*/*
// This is a workaround ...
if (contentTypeListString
.startsWith(application/vnd.wap.mms-message;*/*)) {
contentTypeListString = */*;
}
}
if (contentTypeListString == null) {
if (log.isDebugEnabled())
log
.debug(No content type
list given, creating
HtmlResponseWriterImpl with default content type.);
contentTypeListString = HTML_CONTENT_TYPE;
}
}
Cheers,
Tobias Bräuer
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: Project File Encoding for the MyFaces Source
good idea. except for properties files. they MUST be in ISO 8859-1 character encoding! (see http://java.sun.com/j2se/1.5.0/docs/api/java/util/Properties.html) therefore: please take care of the resource bundle files when you change encoding. --Manfred On Tue, Feb 10, 2009 at 19:47, Bernd Bohmann bernd.bohm...@atanion.com wrote: Hello, could we define a default file encoding for the MyFaces Project? I would suggest UTF-8. And add following property to the poms: project.build.sourceEncodingUTF-8/project.build.sourceEncoding See: http://docs.codehaus.org/display/MAVENUSER/POM+Element+for+Source+File+Encoding Regards Bernd
[Travel Assistance] Applications for ApacheCon EU 2009 - Now Open
FYI -- Forwarded message -- From: Tony Stevenson pct...@apache.org To: travel-assista...@apache.org Date: Fri, 23 Jan 2009 13:28:19 + Subject: [Travel Assistance] Applications for ApacheCon EU 2009 - Now Open The Travel Assistance Committee is now accepting applications for those wanting to attend ApacheCon EU 2009 between the 23rd and 27th March 2009 in Amsterdam. The Travel Assistance Committee is looking for people who would like to be able to attend ApacheCon EU 2009 who need some financial support in order to get there. There are very few places available and the criteria is high, that aside applications are open to all open source developers who feel that their attendance would benefit themselves, their project(s), the ASF or open source in general. Financial assistance is available for travel, accommodation and entrance fees either in full or in part, depending on circumstances. It is intended that all our ApacheCon events are covered, so it may be prudent for those in the United States or Asia to wait until an event closer to them comes up - you are all welcome to apply for ApacheCon EU of course, but there must be compelling reasons for you to attend an event further away that your home location for your application to be considered above those closer to the event location. More information can be found on the main Apache website at http://www.apache.org/travel/index.html - where you will also find a link to the online application form. Time is very tight for this event, so applications are open now and will end on the 4th February 2009 - to give enough time for travel arrangements to be made. Good luck to all those that apply. Regards, The Travel Assistance Committee -- -- Tony Stevenson t...@pc-tony.com // pct...@apache.org // pct...@freenode.net http://blog.pc-tony.com/ 1024D/51047D66 ECAF DC55 C608 5E82 0B5E 3359 C9C7 924E 5104 7D66 --
Re: [VOTE] Support new JSR for the Portlet 2.0 Bidge for JavaServer Faces 1.2
+1 --Manfred On Tue, Jan 20, 2009 at 22:04, Scott O'Bryan darkar...@gmail.com wrote: Hey community, Oracle is trying to open up a new JSR for the Portlet 2.0 Bridge. Originally this was part of the JSR-301 but there was a slight misunderstanding of the intentions of the specs regarding release dates. To make a long story short, instead of doing both the specifications for Portlet 1.0 and 2.0 as part of the JSR, it's being split up. The Project lead will be Michael Freedman who is a MyFaces committer and has been very active on the Apache MyFaces Portlet Bridge project and he was also the spec-lead for the JSR-301. The Apache implementations of these specifications are being written as the eventual R.I.'s for the bridge projects. In any case, should Apache MyFaces put its vote in for the formation of this JSR? Understand that this is not a vote for a project or spec, just to allow the JCP to start a JSR to support this project. I have gotten word from Apache that this can be done if a community decides to support it. Since the Apache MyFaces Portlet Bridge is being developed as the eventual R.I. and Oracle has been very open to aiding the OpenSource development of this bridge here at Apache, I think it's a good opportunity for us to support the JCP and, in particular, the Portlet Bridge Projects. Vote: [ ] +1 to support the formation of a new JSR for the Portlet Bridge 2.0 [ ] +0 don't really care, it's just a silly green checkmark on the ballot [ ] -1 don't put the green checkmark on the ballot, Apache shouldn't support the JCP Thanks, Scott O'Bryan
Re: [ExtVal] logo proposal
+1 On Sun, Dec 14, 2008 at 16:48, Gerhard Petracek gerhard.petra...@gmail.com wrote: hello, we have a final proposal for the extval logo [1]. please send your opinions. [ ] +1 for: i like the logo [ ] +0 for: i like a different version of the logo [ ] -1 for: i don't like the logo thanks, gerhard [1] http://os890.blogspot.com/2008/12/myfaces-extval-logo-proposal.html -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
Re: MyFaces Commons does not have a JIRA entry
ok, done. created the MFCOMMONS Jira Project together with all the components (myfaces-converters, myfaces-validators, myfaces-commons-utils, ...) --Manfred On Mon, Nov 24, 2008 at 12:10 PM, Gerhard Petracek [EMAIL PROTECTED] wrote: +1 regards, gerhard 2008/11/24 Cagatay Civici [EMAIL PROTECTED] MFCOMMONS is fine for me as well On Mon, Nov 24, 2008 at 10:36 AM, Manfred Geiler [EMAIL PROTECTED] wrote: any other comments on this? if not I will create the MFCOMMONS in a few minutes. --Manfred On Mon, Nov 24, 2008 at 3:15 AM, Hazem Saleh [EMAIL PROTECTED] wrote: MFCOMMONS is nice for me. On Sun, Nov 23, 2008 at 11:41 PM, Manfred Geiler [EMAIL PROTECTED] wrote: I can do it. I am adding the new Jira project tomorrow. However, first of all we need a unique short name (the Jira key) for it. Some proposals are: 1 MFCOMMONS 2 MCOMMONS 3 MYFACESCOMMONS 4 COMMONS 3 is too long I think 4 though unique might be misleading -- Apache Commons ! --Manfred On Sun, Nov 23, 2008 at 11:17 AM, Matthias Wessendorf [EMAIL PROTECTED] wrote: Let's fix that Sent from my iPod. Am 23.11.2008 um 00:42 schrieb Leonardo Uribe [EMAIL PROTECTED]: Hi Unfortunately no. I can do almost everything but not create projects on JIRA. And I don't know who can do it. regards Leonardo Uribe On Sat, Nov 22, 2008 at 2:17 PM, Matthias Wessendorf [EMAIL PROTECTED] wrote: Are you an admin on jira, leo? Sent from my iPod. Am 22.11.2008 um 20:12 schrieb Leonardo Uribe [EMAIL PROTECTED]: On Sat, Nov 22, 2008 at 12:22 PM, Leonardo Uribe [EMAIL PROTECTED] wrote: On Sat, Nov 22, 2008 at 11:46 AM, Hazem Saleh [EMAIL PROTECTED] wrote: Hello Team, Can any body please add MyFaces Commons to the MyFaces subprojects in JIRA. I wish to create an issue on Commons but could not find an entry. Thanks all! I did it yesterday. Sorry, a misunderstanding. I added the common components module but still we need the JIRA entry. regards Leonardo Uribe regards Leonardo Uribe -- Hazem Ahmed Saleh Ahmed Author of (The Definitive Guide to Apache MyFaces and Facelets): http://www.amazon.com/Definitive-Guide-Apache-MyFaces-Facelets/dp/1590597370 Web blog: http://www.jroller.com/page/HazemBlog [Web 2.0] Google Maps Integration with JSF: http://code.google.com/p/gmaps4jsf/ http://www.theserverside.com/news/thread.tss?thread_id=51250 -- Hazem Ahmed Saleh Ahmed Author of (The Definitive Guide to Apache MyFaces and Facelets): http://www.amazon.com/Definitive-Guide-Apache-MyFaces-Facelets/dp/1590597370 Web blog: http://www.jroller.com/page/HazemBlog [Web 2.0] Google Maps Integration with JSF: http://code.google.com/p/gmaps4jsf/ http://www.theserverside.com/news/thread.tss?thread_id=51250 -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
Re: MyFaces Commons does not have a JIRA entry
any other comments on this? if not I will create the MFCOMMONS in a few minutes. --Manfred On Mon, Nov 24, 2008 at 3:15 AM, Hazem Saleh [EMAIL PROTECTED] wrote: MFCOMMONS is nice for me. On Sun, Nov 23, 2008 at 11:41 PM, Manfred Geiler [EMAIL PROTECTED] wrote: I can do it. I am adding the new Jira project tomorrow. However, first of all we need a unique short name (the Jira key) for it. Some proposals are: 1 MFCOMMONS 2 MCOMMONS 3 MYFACESCOMMONS 4 COMMONS 3 is too long I think 4 though unique might be misleading -- Apache Commons ! --Manfred On Sun, Nov 23, 2008 at 11:17 AM, Matthias Wessendorf [EMAIL PROTECTED] wrote: Let's fix that Sent from my iPod. Am 23.11.2008 um 00:42 schrieb Leonardo Uribe [EMAIL PROTECTED]: Hi Unfortunately no. I can do almost everything but not create projects on JIRA. And I don't know who can do it. regards Leonardo Uribe On Sat, Nov 22, 2008 at 2:17 PM, Matthias Wessendorf [EMAIL PROTECTED] wrote: Are you an admin on jira, leo? Sent from my iPod. Am 22.11.2008 um 20:12 schrieb Leonardo Uribe [EMAIL PROTECTED]: On Sat, Nov 22, 2008 at 12:22 PM, Leonardo Uribe [EMAIL PROTECTED] wrote: On Sat, Nov 22, 2008 at 11:46 AM, Hazem Saleh [EMAIL PROTECTED] wrote: Hello Team, Can any body please add MyFaces Commons to the MyFaces subprojects in JIRA. I wish to create an issue on Commons but could not find an entry. Thanks all! I did it yesterday. Sorry, a misunderstanding. I added the common components module but still we need the JIRA entry. regards Leonardo Uribe regards Leonardo Uribe -- Hazem Ahmed Saleh Ahmed Author of (The Definitive Guide to Apache MyFaces and Facelets): http://www.amazon.com/Definitive-Guide-Apache-MyFaces-Facelets/dp/1590597370 Web blog: http://www.jroller.com/page/HazemBlog [Web 2.0] Google Maps Integration with JSF: http://code.google.com/p/gmaps4jsf/ http://www.theserverside.com/news/thread.tss?thread_id=51250 -- Hazem Ahmed Saleh Ahmed Author of (The Definitive Guide to Apache MyFaces and Facelets): http://www.amazon.com/Definitive-Guide-Apache-MyFaces-Facelets/dp/1590597370 Web blog: http://www.jroller.com/page/HazemBlog [Web 2.0] Google Maps Integration with JSF: http://code.google.com/p/gmaps4jsf/ http://www.theserverside.com/news/thread.tss?thread_id=51250
Re: MyFaces Commons does not have a JIRA entry
I can do it. I am adding the new Jira project tomorrow. However, first of all we need a unique short name (the Jira key) for it. Some proposals are: 1 MFCOMMONS 2 MCOMMONS 3 MYFACESCOMMONS 4 COMMONS 3 is too long I think 4 though unique might be misleading -- Apache Commons ! --Manfred On Sun, Nov 23, 2008 at 11:17 AM, Matthias Wessendorf [EMAIL PROTECTED] wrote: Let's fix that Sent from my iPod. Am 23.11.2008 um 00:42 schrieb Leonardo Uribe [EMAIL PROTECTED]: Hi Unfortunately no. I can do almost everything but not create projects on JIRA. And I don't know who can do it. regards Leonardo Uribe On Sat, Nov 22, 2008 at 2:17 PM, Matthias Wessendorf [EMAIL PROTECTED] wrote: Are you an admin on jira, leo? Sent from my iPod. Am 22.11.2008 um 20:12 schrieb Leonardo Uribe [EMAIL PROTECTED]: On Sat, Nov 22, 2008 at 12:22 PM, Leonardo Uribe [EMAIL PROTECTED] wrote: On Sat, Nov 22, 2008 at 11:46 AM, Hazem Saleh [EMAIL PROTECTED] wrote: Hello Team, Can any body please add MyFaces Commons to the MyFaces subprojects in JIRA. I wish to create an issue on Commons but could not find an entry. Thanks all! I did it yesterday. Sorry, a misunderstanding. I added the common components module but still we need the JIRA entry. regards Leonardo Uribe regards Leonardo Uribe -- Hazem Ahmed Saleh Ahmed Author of (The Definitive Guide to Apache MyFaces and Facelets): http://www.amazon.com/Definitive-Guide-Apache-MyFaces-Facelets/dp/1590597370 Web blog: http://www.jroller.com/page/HazemBlog [Web 2.0] Google Maps Integration with JSF: http://code.google.com/p/gmaps4jsf/ http://www.theserverside.com/news/thread.tss?thread_id=51250
Re: [VOTE] Release of Trinidad 1.0.10
+1 On Fri, Nov 14, 2008 at 9:15 AM, Thomas Spiegl [EMAIL PROTECTED] wrote: +1 On Thu, Nov 13, 2008 at 7:06 PM, Grant Smith [EMAIL PROTECTED] wrote: +1 On Thu, Nov 13, 2008 at 7:40 AM, [EMAIL PROTECTED] wrote: +1 ..no noticeable negative side effects :) Best wishes Wolfgang Matthias Wessendorf [EMAIL PROTECTED] Gesendet von: [EMAIL PROTECTED] 13.11.2008 09:19 Bitte antworten an MyFaces Development dev@myfaces.apache.org An MyFaces Development dev@myfaces.apache.org Kopie Thema [VOTE] Release of Trinidad 1.0.10 Hi, I was running the needed tasks to get the 1.0.10 release of the Apache MyFaces Trinidad CORE out. The artifacts are deployed to my private Apache account ([1]). Please take a look at the 1.0.10 artifacts and vote [ ] +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, Matthias [1] http://people.apache.org/~matzew/trinidad1010/ -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -- Grant Smith
Re: [VOTE] Release of Trinidad 1.2.10
+1 On Fri, Nov 14, 2008 at 9:15 AM, Thomas Spiegl [EMAIL PROTECTED] wrote: +1 On Thu, Nov 13, 2008 at 7:06 PM, Grant Smith [EMAIL PROTECTED] wrote: +1 On Thu, Nov 13, 2008 at 6:28 AM, Gerhard Petracek [EMAIL PROTECTED] wrote: hello paul, the jira link is [1] e.g. [2] regards, gerhard [1] http://issues.apache.org/jira/secure/ConfigureReleaseNote.jspa?projectId=12310661 [2] http://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12313342styleName=HtmlprojectId=12310661Create=Create 2008/11/13 Matthias Wessendorf [EMAIL PROTECTED] On Thu, Nov 13, 2008 at 3:12 PM, Paul Spencer [EMAIL PROTECTED] wrote: Where can I find the proposed release notes? usually all these myfaces projects provide that after a release. You can do a jira search on your own -M BTW: I will not be able to look at the artifacts until this evening, Eastern Standard Time, at the earliest. Paul Spencer Matthias Wessendorf wrote: Hi, I was running the needed tasks to get the 1.2.10 release of the Apache MyFaces Trinidad CORE out. The artifacts are deployed to my private Apache account ([1]). Please take a look at the 1.2.10 artifacts and vote [ ] +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, Matthias [1] http://people.apache.org/~matzew/trinidad1210/ -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces -- Grant Smith
Re: Impl compile time dependency to Shared
since classes are copied into the myfaces-impl jar, there should not be any dependency at all. but, to force maven to build myfaces-shared-impl first there should be a fake provided dependency. AFAIR this was the case. I wonder if someone has modified/added this dependency lately? --Manfred On Wed, Nov 12, 2008 at 4:27 PM, Bruno Aranda [EMAIL PROTECTED] wrote: If it is not the case, the myfaces-shared-impl should be marked as 'optional' in the impl pom.xml? Bruno 2008/11/12 Cagatay Civici [EMAIL PROTECTED] When I add myfaces-imp 1.2.5 to my pom as a dependency, myfaces-shared-impl-3.0.5.jar also implicitly added to the classpath. It is a problem for myfaces users since now we have the same classes added twice to the classpath. Cagatay
Re: [release] signing assembly artifacts
AFAIR the gpg maven plugin worked well. And I think there is a certain profile you just have to activate when launching the release build. --Manfred On Wed, Nov 12, 2008 at 11:29 AM, Matthias Wessendorf [EMAIL PROTECTED] wrote: Hi, I wonder if one of the myfaces projects has a *scriptlet* (or something like that), included in the build to do a gpg-signing of the assembly artifacts ? I have currently a Phyton (from Scott O'Bryan) that does the work for me. Any hint would be appreciated. Thx, Matthias -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf
[Announce] Call For Papers opens for ApacheCon US 2009
If you have only 30 seconds to read this; Join us in celebrating the ASF's 10th Anniversary at ApacheCon! The Call for Papers is now open for ApacheCon US 2009, taking place 2-6 November in Oakland, California. Proposals are being accepted at http://us.apachecon.com/c/acus2009/cfp/ and can be revised at anytime until the submissions closing deadline of 28 February 2009. In addition, sponsorship opportunities for both ApacheCon EU 2009/Amsterdam and ApacheCon US 2009/Oakland are available. Please contact Delia Frees at [EMAIL PROTECTED] for further information. Please, read on... *** ApacheCon Celebrates the ASF's 10th Anniversary in Oakland, California, 2-6 November 2009 Call for Papers Opens for ApacheCon US 2009 The Apache Software Foundation (ASF) invites submissions to its official user and developer conference, taking place 2-6 November 2009 at the Oakland Convention Center and Marriott Hotel. ApacheCon serves as a forum for showcasing the ASF's latest projects, members, and community initiatives. Offering unparalleled educational opportunities, ApacheCon's presentations, hands-on trainings, and sessions address key technology, development, business/community, and licensing issues in Open Source. The wide range of activities offered at ApacheCon promotes the exchange of ideas amongst ASF Members, committers, innovators, developers, vendors, and users interested in the future of Open Source technology. The conference program includes peer-reviewed sessions, trainings/workshops, and select invited keynote presentations and speakers. Conference Themes and Topics Building on ten years of success, ApacheCon returns to the Bay Area for the 10th anniversary of the Apache Software Foundation. Comprising some of the most active and recognized developers in the Open Source community, ApacheCon provides an influential platform for dialogue between Open Source developers and users, traversing a wide range of ideas, expertise, and personalities. ApacheCon welcomes submissions across many fields, geographic locations, and areas of development. The breadth of the Apache community lends itself to conference content that is somewhat loosely-structured, with common themes of interest addressing groundbreaking technologies and emerging trends, best practices (from development to deployment), case studies and lessons learned (tips, tools, and tricks). In addition, ApacheCon will continue to offer its highly popular, two-day intensive trainings; certifications of completion will be distributed to those who fulfill all the training requirements. Topics appropriate for submission are manifold, and may include but are not restricted to: Apache HTTP server (installation, configuration, migration, and more); ASF-wide projects (including Lucene, Hadoop, Jackrabbit, and Maven); Scripting languages and dynamic content (such as Java, Perl, Python, Ruby, XSL, and PHP); Security and e-commerce (performance tuning, load balancing and high availability); New technologies (including broader initiatives such as Web Services and Web 2.0); ASF-Incubated projects (such as Sling, UIMA, and Shindig); and Business/Community issues (Open Source driven business models, open development, enterprise adoption, and more). Submission Guidelines Submissions must include; – Session title - Speaker name - Speaker biography - Session description - Format and duration - Audience expertise level Full details are available online on the CFP page at [WWW] http://us.apachecon.com/c/acus2009/cfp/ Types of Presentations; - Trainings/Workshops - General Sessions - Case Studies/Industry Profiles - Corporate Showcases Demonstrations - Fast Feather (short) sessions - Birds of a Feather discussions - Invited Keynotes/Panels/Speakers Pre-Conference Trainings/Workshops Held on the first two days of the conference (2-3 November 2009), ApacheCon trainings are available at a registration fee beyond the regular conference fee. Proposals may be submitted for half-day (3 hours), full-day (6 hours), or two-day (12 hours) training sessions. These proposed tutorials should be aimed at providing in-depth, hands-on development experience or related continuing education. Training submissions are welcome at beginner, intermediate, and expert levels. General Sessions include presentations on practical development applications, insight into high-interest projects, best practices and key advances, overcoming implementation challenges, and industry innovations. Especially welcome are submissions that extend participants' understanding the role of ASF projects and their influence on the Open Source community at large. General Sessions are scheduled for 50 minutes and are accessible to all conference delegates. Case Study/Industry Profile Practitioners are invited to submit presentations that focus on how implementing particular ASF technologies led to improved products/solutions, service offerings, changes in work practices, among other successes. Proposals
Re: Incorrect versions for MyFaces on http://www.apache.org/licenses/exports/
As a first step I updated the version number in the Classification Matrix from 2.0 to 1.1.2 (please wait for mirrors). Well, as far as I understand we should rather specify the various MyFaces sub projects with their version number. Please give me more information about cryptography in all the MyFaces projects. Especially Trinidad, Tobago, Orchestra, Commons Thanks for your help, Manfred On Fri, Oct 31, 2008 at 7:15 PM, Mike Kienenberger [EMAIL PROTECTED] wrote: Manfred, You still need to take action on this. Nothing has changed on this issue except the url. It's been 18 months. Since the code is in myfaces-shared, I'm guessing it affects both MyFaces Core and Tomahawk. There's some other stuff in Tomahawk now that might qualify it too, but I haven't evaluated it. On Tue, Feb 20, 2007 at 10:52 PM, Mike Kienenberger [EMAIL PROTECTED] wrote: Does this help? #Generated by Maven #Thu Apr 13 14:18:08 EDT 2006 version=2.0.0 groupId=org.apache.myfaces.shared artifactId=myfaces-shared-impl So perhaps the change that needs to be made is to have it say myfaces-shared 2.0 rather than simply 2.0? http://www.apache.org/licenses/exports/ On 2/20/07, Dennis Byrne [EMAIL PROTECTED] wrote: I'm not sure why 2.0 is there. Perhaps I was thinking the version of the shared lib. Anyone know which version of the shared lib we had when encryption was brought in? Dennis Byrne On 2/20/07, Mike Kienenberger [EMAIL PROTECTED] wrote: Manfred, The crypto page contains the incorrect version numbers for MyFaces. Apache MyFaces Project Product NameVersionsECCNControlled Source Apache MyFaces development 5D002 ASF 2.0 and later 5D002 ASF I'm not sure where 2.0 came into this, but we started allowing cryptography as of Myfaces version 1.1.2. See http://issues.apache.org/jira/browse/MYFACES-742 for details. As pmc-chair, you should have the karma to update this page according the instructions at this url: http://www.apache.org/dev/crypto.html#sources -- Dennis Byrne
Re: new sandbox component proposal - s:globalId obsoletes forceId
sounds good!
+1
--Manfred
On Fri, Oct 24, 2008 at 2:12 PM, Simon Kitching [EMAIL PROTECTED] wrote:
Hi All,
I've always hated the forceId feature of tomahawk for two reasons:
(a) it makes it dangerous to compose pages using facelets templating,
jsp:include or similar
(b) it only works for tomahawk components
There is nothing that can be done about (a); any flattening of the id
is dangerous. But sometimes it is just necessary.
It is possible to do something about (b) though. JSF1.2 adds method
UIComponentBase.getContainerClientId. A trivial component can therefore
be written that prevents any prefix being applied to the ids of its
child components:
f:subview id=mysubview1
h:commandButton id=btn1 ../ # clientId = mysubview1:btn1
s:globalId id=whatever
h:commandButton id=btn2 .../ # clientId=btn2
h:graphicImage id=img1 ../# clientId=img1
/s:globalId
/f:subview
The implementation is trivial:
public class GlobalId extends UIComponentBase implements NamingContainer
{
private final static String COMPONENT_FAMILY = oamc.GlobalId;
public String getFamily()
{
return COMPONENT_FAMILY;
}
public String getContainerClientId(FacesContext facesContext)
{
return null;
}
}
Note that this component would only work for JSF1.2 or later (though it
will compile fine with JSF1.1).
Would this be useful or not?
Regards,
Simon
--
-- Emails in mixed posting style will be ignored
-- (http://en.wikipedia.org/wiki/Posting_style)
Re: JIRA: project entry needed for sandbox
But Sandbox IS a part of Tomahawk and not a single project, so I do not see the problem here. Sandbox issues SHOULD be filed using TOMAHAWK and - of course - the regarding component (SubForm, PPRPanelGroup, ...). -1 for a new Jira project(!) --Manfred On Tue, Oct 14, 2008 at 4:06 PM, Simon Kitching [EMAIL PROTECTED] wrote: Any JIRA admins here? There currently is no JIRA project defined for the myfaces sandbox. It appears that people have simply been using TOMAHAWK to file bugs against. But as recent releases has used a jira report as the release notes this is causing confusion. Can someone please create it? The name SANDBOX is already taken, so perhaps MF-SANDBOX or similar could be used. Perhaps we should file a jira issue to create the new project? :-)
Re: JIRA: project entry needed for sandbox
On Tue, Oct 14, 2008 at 5:35 PM, Volker Weber [EMAIL PROTECTED] wrote: Hi, 2008/10/14 Simon Kitching [EMAIL PROTECTED]: Any JIRA admins here? There currently is no JIRA project defined for the myfaces sandbox. It appears that people have simply been using TOMAHAWK to file bugs against. But as recent releases has used a jira report as the release notes this is causing confusion. a Myfaces-Commons is also missing. Other than Tomahawk Sandbox the MyFaces Commons is a standalone project under the MyFaces umbrella. So a Jira project makes sense here. This also demands a project site under http://myfaces.apache.org/commons; and a Commons logo of course. Any volunteers? ;-) If everyone is ok with it, I will create the Jira project for MyFaces Commons with the Jira-ID MFCOMMONS. --Manfred
Re: JIRA: project entry needed for sandbox
On Tue, Oct 14, 2008 at 9:40 PM, Matthias Wessendorf [EMAIL PROTECTED] wrote: On Tue, Oct 14, 2008 at 9:33 PM, Manfred Geiler [EMAIL PROTECTED] wrote: But Sandbox IS a part of Tomahawk and not a single project, so I do not see the problem here. Sandbox issues SHOULD be filed using TOMAHAWK and - of course - the regarding component (SubForm, PPRPanelGroup, ...). -1 for a new Jira project(!) for tomahawk, right ? +1 on that you mean +1 for my -1 ? Wow! :-) That's like: I am against being in favor or: I am in favor of being against Which is actually the same. Is it? Hmm. Very philosophical... :-) --Manfred
Re: JIRA: project entry needed for sandbox
This also demands a project site under http://myfaces.apache.org/commons; and a Commons logo of course. Any volunteers? ;-) Just saw that there IS already a site under http://myfaces.apache.org/commons/ Cool! What's just missing is the menu entry on the main MyFaces page. --Manfred
Re: Handling component rendered state during postback
My understanding of attributes with a value binding is, that the EL expressions must ALWAYS be evaluated dynamically and must never be cached. The same applies for the rendered attribute. There is (should be) no special handling IMHO. Regarding ugly problems and performance issues: My feeling is, that both can be avoided by having a well designed model. Please give us an example, Simon, if you cannot agree. --Manfred On Tue, Aug 5, 2008 at 4:27 PM, Simon Kitching [EMAIL PROTECTED] wrote: Hi, A question on the user list reminded me of something I've been puzzled about for quite a while. Does the JSF spec actually say that rendered EL expressions should be re-evaluated during postback? That's what MyFaces currently does, but it seems to me that the true/false state should really be part of the component's saved state and the restored value simply used during postback (and recalculated in render phase). Does anyone know why in the current myfaces implementation each component recomputes its rendered state during postback by using its EL expression rather than using a value cached from the render phase? Using a cached value would avoid some ugly problems with EL expressions being called before updateModel, as well as being a significant performance boost (rendered property tends to get queried several times during postback). Regards, Simon
[OT] Travel Assistance to ApacheCon US 2008 - 3 days to apply!
The Travel Assistance Committee is taking in applications for those wanting to attend ApacheCon US 2008 between the 3rd and 7th November 2008 in New Orleans. The Travel Assistance Committee is looking for people who would like to be able to attend ApacheCon US 2008 who need some financial support in order to get there. There are VERY few places available and the criteria is high, that aside applications are open to all open source developers who feel that their attendance would benefit themselves, their project(s), the ASF and open source in general. Financial assistance is available for flights, accommodation and entrance fees either in full or in part, depending on circumstances. It is intended that all our ApacheCon events are covered, so it may be prudent for those in Europe and or Asia to wait until an event closer to them comes up - you are all welcome to apply for ApacheCon US of course, but there must be compelling reasons for you to attend an event further away that your home location for your application to be considered above those closer to the event location. More information can be found on the main Apache website at http://www.apache.org/travel/index.html - where you will also find a link to the application form and details for submitting. Time is very tight for this event, so applications are open now and will end on the 2nd October 2008 - to give enough time for travel arrangements to be made. Good luck to all those that will apply. Regards, The Travel Assistance Committee
Re: Make dev@ private?
-1 for permissions change for dev@ +1 for a clearer description any native speaker volunteering? --Manfred On Thu, Sep 4, 2008 at 6:54 PM, Simon Lessard [EMAIL PROTECTED] wrote: -1 However, it's true that Apache product users often consider themselves developer and thus post on the developer forum even when their question should really be on the user list. We could probably reduce such occurrences a little by adding a clearer explanation of the purpose of each list on the mailing page. Regards, ~ Simon On Thu, Sep 4, 2008 at 12:12 PM, Paul Spencer [EMAIL PROTECTED] wrote: Andrew, The dev@ mailing list is described on the Jakarts site[1] as: The Developer lists where you can send questions and comments about the actual software source code and general development types of questions. Making the developer list private is extreme and I would resist this change. Their are many productive discussion on the developer list that include non-committers or non-pmc members. Are the posting to the developer list because the question is not answered on the user list? If so, then lets address this problem first. If not, then should the response to an user@ post on the dev@ list be something like You have posted this to the wrong list, please repost this on the user@ list The dev@ mailing list is described on the Jakarts site[1] as: The Developer lists where you can send questions and comments about the actual software source code and general development types of questions. Making the developer list private is extreme. Their are many discussion on the developer list that include non-committers or non-pmc members. Paul Spencer [1]http://jakarta.apache.org/site/mail.html Andrew Robinson wrote: Is it possible to make dev@ a private mailing list, so only commiters and people that PMCs decide should have access to post are allowed to send emails to this list? That way we can reduce the accidental posting to dev@ instead of [EMAIL PROTECTED] -Andrew
Re: [VOTE] release of myfaces core 1.2.4
+0 thanks Leonardo! --Manfred On Wed, Aug 27, 2008 at 8:07 PM, Leonardo Uribe [EMAIL PROTECTED] wrote: Hi, I was running the needed tasks to get the 1.2.4 release of Apache MyFaces core out. The artifacts passed all TCK test. Please note that this vote concerns all of the following parts: 1. Maven artifact group org.apache.myfaces.shared v3.0.4 [1] 2. Maven artifact group org.apache.myfaces.core v1.2.4 [1] The artifacts are deployed to my private Apache account ([1] and [3] for binary and source packages). The release notes could be found at [4]. Also the clirr test does not show binary incompatibilities with myfaces-api. Please take a look at the 1.2.4 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/myfaces124 [2] http://www.apache.org/foundation/voting.html#ReleaseVotes [3] http://people.apache.org/~lu4242/myfaces124binsrc [4] https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=10600styleName=Htmlversion=12313378 -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
Re: Jira configuration ? (was Fwd: [Trinidad] Missing issue in 1.0.8)
Ok, re-enabled the fix version on the edit screen. --Manfred On Thu, Aug 21, 2008 at 10:50 AM, Matthias Wessendorf [EMAIL PROTECTED] wrote: On Thu, Aug 21, 2008 at 10:42 AM, Volker Weber [EMAIL PROTECTED] wrote: Hi, isn't the fixVersion field needed for unresolved issues to prepare the roadmap? yes. I think the main point is, that actually bug-filers abuse the field. They understand it as a wish list, like you have to fix my bug in version 'yesterday' :) -Matthias Regards, Volker 2008/8/21 Manfred Geiler [EMAIL PROTECTED]: The Fix version field is still there on the Resolve Issue page! That is where it belongs to. Right? But: I see that there are 964 issues (in all MyFaces projects) with Status Resolved that have no Fix Version. Which is weird! What I COULD do is (re)enable the fix version on the Edit Screen. But I CANNOT restrict it to committers only. There is no way in Jira AFAIK. What I suggest: - Leave it that way. Fix versions normally set during resolve workflow. - Fix missing fix versions by doing bulk operations (Fix version is editable there) Thoughts? --Manfred On Thu, Aug 21, 2008 at 10:11 AM, Bernd Bohmann [EMAIL PROTECTED] wrote: Hello Manfred, how can I edit the fix version field, now? I would like to prepare the tobago-1.0.18 release. Can you revert the MyFaces Screen configuration for Tobago. Regards Bernd Manfred Geiler schrieb: The Jira permissions settings cannot be adjusted on field level. As a workaround I added a new MyFaces Screen configuration to Jira. With this configuration the Fix version field should no longer show up on the Edit screen. I activated this scheme for Trinidad. Please check it out. If ok, I will activate this scheme for all other MyFaces projects as well. --Manfred On Tue, Aug 5, 2008 at 10:27 PM, Matthias Wessendorf [EMAIL PROTECTED] wrote: Hi, we had the discussion already in the past. I'd love to see that the fix-version/s is not! editable by filers. Greetings, Matthias -- Forwarded message -- From: Rottstock, Sven [EMAIL PROTECTED] Date: Tue, Aug 5, 2008 at 10:35 AM Subject: [Trinidad] Missing issue in 1.0.8 To: dev@myfaces.apache.org Hi Devs, i have seen that the patch of TRINIDAD-1010 was not included in the 1.0.8 release but was listed in the release notes. Is there anything wrong with it or was the patch only forgotten to submit? Regards, Sven -- inexso - information exchange solutions GmbH Bismarckstraße 13 | 26122 Oldenburg Tel.: +49 441 4082 356 | FAX: +49 441 4082 355 | www.inexso.de -- Matthias Wessendorf Need JSF and Web 2.0? http://code.google.com/p/facesgoodies further stuff: blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf mail: matzew-at-apache-dot-org
Re: svn commit: r686525 - /myfaces/core/tags/1_1_6/
Hmm, long time ago since I wrote this diary Cannot remember the exact reason. Maybe the idea was it to have the branch available for a quick fix. i.e. to do a quick 1.1.7 when a security flaw arises and the trunk is already unstable due to other changes and cannot be used for the release. We once had that situation because of a javascript injection vulnerability that was detected shortly after the release. Of course you could always achieve this by copying the tag to the branches folder on demand later. But since SVN copies are only pointers this is no big problem IMO. So I'd rather keep the tradition. However, feel free to adopt the release process. --Manfred On Mon, Aug 18, 2008 at 9:07 PM, Leonardo Uribe [EMAIL PROTECTED] wrote: On Mon, Aug 18, 2008 at 11:38 AM, simon [EMAIL PROTECTED] wrote: On Sat, 2008-08-16 at 17:19 +, [EMAIL PROTECTED] wrote: Author: lu4242 Date: Sat Aug 16 10:19:13 2008 New Revision: 686525 URL: http://svn.apache.org/viewvc?rev=686525view=rev Log: Copy from branch to trunk for release procedure Added: myfaces/core/tags/1_1_6/ - copied from r686524, myfaces/core/branches/1_1_6/ Just a very minor question: why copy instead of move? Presumably you'll need to now delete that branch... Really is a procedure copied from 1.1.5. See: http://wiki.apache.org/myfaces/CoreRelease115 But I don't know the specific reason about let the branch and the tag. regards Leonardo Uribe
Re: Continuum environment upgrade
+1 for option (1) Already ran through recreating config myself some months ago. Simon, thanks for taking this over! Please be careful with the automatic site build. I once managed to destroy the myfaces site with continuum, which was then screwed up half a day because of mirror delays. Remember? ;-) --Manfred On Mon, Aug 18, 2008 at 2:04 PM, Simon Kitching [EMAIL PROTECTED] wrote: Hi All, I managed to get continuum-1.1 installed and running on myfaces.zones.apache.org, and also to get the user accounts loaded into the new instance. However I just cannot get the existing build configuration to load. The load appears to go ok, but continuum just fails to restart afterwards. So the options are: (1) go with new installation, and recreate the project config (2) move to using the central server at vmbuild.apache.org (which will mean creating all new user accounts, as well as manually recreating the project config) (3) leave myfaces on continuum-1.1-beta-2 forever (4) someone else can have a try Personally, I'm happy with (1). Adding the projects again is only an hour's work or so. I think that we work our install hard enough to justify using a separate server rather than a central one. Opinions? Regards, Simon -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
Re: [VOTE] Release of Portlet Bridge Master POM v2
+1 On Thu, Aug 14, 2008 at 11:46 AM, Scott O'Bryan [EMAIL PROTECTED] wrote: Hi, I'm trying to release the MyFaces Portlet Bridge Master POM v2. This pom file was created in order to support the latest portlet-bridge project's website as well as the multiple open code lines needed for this project going forward. This file manages the commonalities between all of the Portlet Bridge projects and is derived off of the MyFaces Master POM v. 6. I was running the needed tasks to get the v2 release of the Apache MyFaces Portlet Bridge Master pom out. The artifacts are deployed to my private Apache account ([1]). Please take a look at the portlet-bridge-master-pom-1 artifacts and vote [ ] +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, Scott [1] http://people.apache.org/~sobryan/portlet-bridge/portlet-bridge-master-pom-2/ -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
[Idea] reCAPTCHA JSF component
Just came across the http://recaptcha.net/ website and wondered if anyone is willing to develop (and contribute) a reCAPTCHA JSF component for Tomahawk? From the website: reCAPTCHA is a free CAPTCHA service that helps to digitize books. A CAPTCHA is a program that can tell whether its user is a human or a computer. You've probably seen them — colorful images with distorted text at the bottom of Web registration forms. CAPTCHAs are used by many websites to prevent abuse from bots, or automated programs usually written to generate spam. No computer program can read distorted text as well as humans can, so bots cannot navigate sites protected by CAPTCHAs. Shouldn't be that difficult. There are already some implementations for different languages/systems but none yet for JSF: http://recaptcha.net/resources.html So, when beijing08 bores you - this is your opportunity! ;-) --Manfred
Re: [Idea] reCAPTCHA JSF component
On Thu, Aug 14, 2008 at 10:13 PM, Mike Kienenberger [EMAIL PROTECTED] wrote: I think what Manfred is suggesting is that we implement a reCAPTCHA component specifically rather than captcha in general. For those people who want to secure their applications and promote digital book scan correcting at the same time :-) yes, exactly. On 8/14/08, Hazem Saleh [EMAIL PROTECTED] wrote: Hi Manfred, I already implemented one http://myfaces.apache.org/tomahawk/tagdoc/t_captcha.html :). of course I know we already have a captcha comp. ;-) perhaps it's possible to add the reCAPTCHA functionality as a feature to the existing component? --Manfred
Re: [VOTE] release of myfaces core 1.1.6
+0 (unfortunately stuck in my day job - no time for testing - but appreciating the new release) Thanks Leonardo! --Manfred On Tue, Aug 12, 2008 at 11:11 PM, Leonardo Uribe [EMAIL PROTECTED] wrote: Hi, I was running the needed tasks to get the 1.1.6 release of Apache MyFaces core out. The artifacts passed all TCK test. It also passes maven clirr test (mvn clirr:check -DcomparsionVersion=1.1.5). Please note that this vote concerns all of the following parts: 1. Maven artifact group org.apache.myfaces.shared v2.0.8 [1] 2. Maven artifact group org.apache.myfaces.core v1.1.6 [1] The artifacts are deployed to my private Apache account ([1] and [3] for binary and source packages). The release notes could be found at [4]. Also the clirr test does not show binary incompatibilities with myfaces-api. Please take a look at the 1.1.6 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/myfaces116 [2] http://www.apache.org/foundation/voting.html#ReleaseVotes [3] http://people.apache.org/~lu4242/myfaces116binsrc [4] https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12312312styleName=HtmlprojectId=10600 -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
[jira] Updated: (MYFACES-152) ResponseWriter.endDocument() abuse breaks ADF Faces
[ https://issues.apache.org/jira/browse/MYFACES-152?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Manfred Geiler updated MYFACES-152: --- Status: Open (was: Patch Available) ResponseWriter.endDocument() abuse breaks ADF Faces --- Key: MYFACES-152 URL: https://issues.apache.org/jira/browse/MYFACES-152 Project: MyFaces Core Issue Type: Bug Components: General Affects Versions: 1.0.9m9 Reporter: Adam Winer Assignee: Bruno Aranda Priority: Critical I've been shown some problems lately with MyFaces 1.0.9 and ADF Faces. The problems specifically trace to MyFaces's use of ResponseWriter.endDocument() to output Javascript. Since ADF Faces runs with its own RenderKit (and therefore its own ResponseWriter), this Javascript is getting dropped and not written. I'd recommend (both as JSF EG guy and ADF Faces guy) that this MyFaces code be moved *out* of ResponseWriter.endDocument(). Specifically: - ResponseWriter.endDocument() is not guaranteed to be called before the close of or even the close of , and therefore this script cannot be safely output at this point. It's quite likely that changes in JSF 1.2 will essentially guarantee that endDocument() is not called until the close of all output. - This is not really the intent of ResponseWriter.endDocument(). In HTML, it should be a no-op. It's there for more bizarre scenarios like a ResponseWriter outputting a SOAP envelope around a response. - It's breaking ADF Faces. :) A significantly cleaner way to output needed Javascript is to add it as needed from the Renderers that require it (using a request-scoped attribute to track if its been added already). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (MYFACES-152) ResponseWriter.endDocument() abuse breaks ADF Faces
[ https://issues.apache.org/jira/browse/MYFACES-152?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Manfred Geiler updated MYFACES-152: --- Status: Patch Available (was: Reopened) ResponseWriter.endDocument() abuse breaks ADF Faces --- Key: MYFACES-152 URL: https://issues.apache.org/jira/browse/MYFACES-152 Project: MyFaces Core Issue Type: Bug Components: General Affects Versions: 1.0.9m9 Reporter: Adam Winer Assignee: Bruno Aranda Priority: Critical I've been shown some problems lately with MyFaces 1.0.9 and ADF Faces. The problems specifically trace to MyFaces's use of ResponseWriter.endDocument() to output Javascript. Since ADF Faces runs with its own RenderKit (and therefore its own ResponseWriter), this Javascript is getting dropped and not written. I'd recommend (both as JSF EG guy and ADF Faces guy) that this MyFaces code be moved *out* of ResponseWriter.endDocument(). Specifically: - ResponseWriter.endDocument() is not guaranteed to be called before the close of or even the close of , and therefore this script cannot be safely output at this point. It's quite likely that changes in JSF 1.2 will essentially guarantee that endDocument() is not called until the close of all output. - This is not really the intent of ResponseWriter.endDocument(). In HTML, it should be a no-op. It's there for more bizarre scenarios like a ResponseWriter outputting a SOAP envelope around a response. - It's breaking ADF Faces. :) A significantly cleaner way to output needed Javascript is to add it as needed from the Renderers that require it (using a request-scoped attribute to track if its been added already). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Jira configuration ? (was Fwd: [Trinidad] Missing issue in 1.0.8)
The Jira permissions settings cannot be adjusted on field level. As a workaround I added a new MyFaces Screen configuration to Jira. With this configuration the Fix version field should no longer show up on the Edit screen. I activated this scheme for Trinidad. Please check it out. If ok, I will activate this scheme for all other MyFaces projects as well. --Manfred On Tue, Aug 5, 2008 at 10:27 PM, Matthias Wessendorf [EMAIL PROTECTED] wrote: Hi, we had the discussion already in the past. I'd love to see that the fix-version/s is not! editable by filers. Greetings, Matthias -- Forwarded message -- From: Rottstock, Sven [EMAIL PROTECTED] Date: Tue, Aug 5, 2008 at 10:35 AM Subject: [Trinidad] Missing issue in 1.0.8 To: dev@myfaces.apache.org Hi Devs, i have seen that the patch of TRINIDAD-1010 was not included in the 1.0.8 release but was listed in the release notes. Is there anything wrong with it or was the patch only forgotten to submit? Regards, Sven
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
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
Re: [Build] philosophy behind the myfaces build ?
What matthias ment was, that we should rather have no myfaces-inter-subproject-snapshot-dependencies. I second that. The trunk of a MyFaces sub-project should always depend on release versions of other projects UNLESS there is a good reason for having a dependency to a snapshot. What reasons are there? 1. the other project has a new feature we depend on and has not yet released 2. there is no release yet of the other project 3. ...more? In all cases the snapshot dependency should be a temporary option and as soon as the other is released we should switch to release dependency (again). --Manfred On Mon, Jun 16, 2008 at 8:55 AM, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Matthias Wessendorf schrieb: Hi, when doing a checkout of myfaces, pretty much everything is build. Fine. Except Trinidad and Tobago. No problem with that. But, when just updating a single svn-folder, like tomahawk, there is a very high chance that the build pretty much fails. Why? because it depends on snapshots that are build via the master myfaces build. In this case I am refering to the myfaces-builder plugin. Isn't is kinda annoying that you always have to build all? Just b/c of a snapshot dependency? At least to me. Why not testing the builder-snapshot in a branch (like tomahawk-move-to-builder-branch). Do a builder release, once stable. And update trunk. (I am only using builder-plug as an example). That's what we do for Trinidad. It doesn't depend on a snapshot plugin, so it is easy (and straightforward) to build it. Not sure why there is this, build the world first philosophy :-) What do you think ? Add the following to ~/.m2/settings.xml. Then add -Papachesnap when building a project. This allows maven to download stuff published to the snapshot repository. Which is kind of useful when building snapshot projects :-) settings profiles profile idapachesnap/id repositories repository idapache.org/id nameMaven Snapshots/name urlhttp://people.apache.org/repo/m2-snapshot-repository/url releases enabledfalse/enabled /releases snapshots enabledtrue/enabled /snapshots /repository /repositories pluginRepositories pluginRepository idapache.org/id nameMaven Plugin Snapshots/name urlhttp://people.apache.org/repo/m2-snapshot-repository/url releases enabledfalse/enabled /releases snapshots enabledtrue/enabled /snapshots /pluginRepository /pluginRepositories /profile /profiles /settings Regards, Simon -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
Re: cleaning up whitespace in source files
Simon, Do you have a number? How many files do have tab characters? I think (b - fix them) would be the better solution. But only if that does not change every second file. --Manfred On Wed, Jul 2, 2008 at 7:28 PM, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Hi All, In the new checkstyle rules file I enabled checks for tab characters, as the myfaces convention is (AFAIK) to use 4 spaces, not tabs. However the checkstyle report points out a lot of files containing tabs. It's no big deal, but do we want to: (a) disable the checkstyle rule and ignore tabs or (b) fix them? Tabs are a minor nuisance when viewing the source as some tools render 4 spaces, some 8. I've written a simple shellscript that can clean this up very easily, and am happy to do so. The script also removes trailing whitespace from lines, of which we also appear to have quite a lot. But doing this will create some large commit messages and make comparing files with past versions noisier. It can also cause svn conflicts if people have modified files they have not yet committed, unless they run the cleanup script against their own working dir before doing svn update. So, option (a) or (b)? Regards, Simon -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
Re: Checkstyle rules
+1 (yes, change the myfaces-master-pom ...) --Manfred On Mon, Jun 30, 2008 at 11:28 PM, simon [EMAIL PROTECTED] wrote: Hi, As I mentioned a few weeks ago, I'd like to clean up the way we do our checkstyle rule checking. Right now we point the maven-checkstyle-report plugin directly at a file in the svn repository. Using svn directly does have the benefit of simplicity, and allows us to update the rules easily. However it has the following disadvantages: * prevents us from changing our repository layout without breaking old releases. * changing the rules changes the report generated when rebuilding old releases * cannot build maven site without network access to svn repo. The alternative is to create a maven artifact containing the checkstyle rules and deploy it to the repository. Then this artifact can be used by the report plugin. This fixes all of the above. The only real disadvantage is that to update the checkstyle rules we need to release a new version of the rules artifact, then update the master pom. That's no big deal though. I have already checked in a checkstyle module here: http://svn.apache.org/repos/asf/myfaces/myfaces-build-tools/trunk/other/checkstyle-rules/ The original checkstyle rules file had almost every check commented out; in this module I have enabled the checks I think are reasonable. Note that this module also holds tobago checkstyle rules, although I have no idea whether the tobago team want to use this or not; this is mostly to demonstrate that separate checkstyle rules *can* be in the same checkstyle artifact if it is desired. Or can be overridden in a project, just by redefining the maven-checkstyle-plugin configuration. The patch below to the myfaces-master-pom would then switch over to using this new module. Note that the checkstyle plugin is now configured in plugins not pluginManagement. Using pluginManagement makes no sense if we then reference the plugin in the reporting section of the same pom. Could you please indicate: [+1] yes, change the myfaces-master-pom to use checkstyle rules artifact [-1] no, leave things alone and remove the new checkstyle artifact If people are happy with this, I will update the master pom, leave it to settle in for a week or so, then call a vote to make a release of both the rules artifact and a new master pom. Thanks, Simon Index: pom.xml === --- pom.xml (revision 660720) +++ pom.xml (working copy) @@ -639,6 +639,20 @@ build defaultGoalinstall/defaultGoal +plugins + plugin +artifactIdmaven-checkstyle-plugin/artifactId +version2.2/version +dependencies + dependency +groupIdorg.apache.myfaces.buildtools/groupId +artifactIdcheckstyle-rules/artifactId +version1-SNAPSHOT/version + /dependency +/dependencies + /plugin +/plugins + !-- - The pluginManagement section does not declare actual dependencies. - However if a child pom declares a dependency on one of the plugins @@ -685,11 +699,6 @@ /plugin plugin -artifactIdmaven-checkstyle-plugin/artifactId -version2.1/version - /plugin - - plugin artifactIdmaven-javadoc-plugin/artifactId version2.3/version /plugin @@ -762,17 +771,10 @@ plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-checkstyle-plugin/artifactId -version2.1/version +version2.2/version configuration -!-- TODO: FIX THIS! - - - - Referencing resources directly from svn is very bad. Firstly, it needs network access to build anything. - - But worse, if this pom is released with this here, then svn cannot be reorganised to move these files - - without breaking any builds that use that released pom. Which means the svn directory structure is - - effectively locked in place for years. - -- - configLocationhttp://svn.apache.org/repos/asf/myfaces/myfaces-master-pom/trunk/checkstyle/default/myfaces-checks.xml/configLocation - headerLocationhttp://svn.apache.org/repos/asf/myfaces/myfaces-master-pom/trunk/checkstyle/default/myfaces-header.txt/headerLocation + configLocationdefault/myfaces-checks.xml/configLocation + headerLocationdefault/myfaces-header.txt/headerLocation /configuration /plugin /plugins -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
[jira] Commented: (TOMAHAWK-1291) t:graphicImage doesnot generate XHTML complaint code
[ https://issues.apache.org/jira/browse/TOMAHAWK-1291?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12609182#action_12609182 ] Manfred Geiler commented on TOMAHAWK-1291: -- +1 for a strict (but sweet-tempered) behaviour that means: - log a nag warning - render a non-empty alt attribute with a meaningful default text if the developer omits the attribute (or provides an empty one) t:graphicImage doesnot generate XHTML complaint code Key: TOMAHAWK-1291 URL: https://issues.apache.org/jira/browse/TOMAHAWK-1291 Project: MyFaces Tomahawk Issue Type: Bug Affects Versions: 1.1.7-SNAPSHOT Reporter: Hazem Saleh Assignee: Hazem Saleh Fix For: 1.1.7-SNAPSHOT -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Time for an Orchestra 1.2 release?
+1 --Manfred On Tue, Jun 24, 2008 at 5:45 PM, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Hi All, I'm about to start working on a new Orchestra feature (basic dialog support). It therefore seems a good idea to get an Orchestra release out before I start messing with the trunk. In particular, there are two bugs which are fixed in trunk and would be good to have in an official release: * ORCHESTRA-21 Issue with weird urls (esp. ones created by Trinidad) * ORCHESTRA-23 (locking bug, triggered by ajax or double-click) There are also a couple of minor enhancements, but not much has really happened since the 1.1 release. As always, there is more we *could* do; there are a couple of open bug issues. But none of them are simple to tackle, so I'd rather get 1.2 out now and tackle the other issues (esp. portlets) at some later time. I've created a release branch in svn, and taken out a few things that are not completely baked in trunk. The resulting code is binary compatible with 1.1 except in one minor case that I don't think we need to worry about. But see the RELEASE-NOTES.txt file for details. Unless there are any objections, I'll create an RC in the next few days. Cheers, Simon -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
Re: checkstyle rules
yeah +1 AFAIR, that crazy workaround was done by me. Pointing to svn is really ugly, yes. I did it as a quick fix of something even more ugly. Don't remember exactly what it was. I think something like pointing to a relative path that only existed when checking out the whole current project with the externals... Great if there is a clean maven like way to fix this. Thanks Simon. --Manfred On Sun, Jun 15, 2008 at 5:47 PM, simon [EMAIL PROTECTED] wrote: Hi, Currently the myfaces master pom checkstyle configuration points directly at our subversion repository: plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-checkstyle-plugin/artifactId version2.1/version configuration !-- TODO: FIX THIS! - - Referencing resources directly from svn is very bad. - Firstly, it needs network access to build anything. - But worse, if this pom is released with this here, - then svn cannot be reorganised to move these files - without breaking any builds that use that released - pom. Which means the svn directory structure is - effectively locked in place for years. -- configLocation http://svn.apache.org/repos/asf/myfaces/ myfaces-master-pom/trunk/checkstyle/ default/myfaces-checks.xml /configLocation headerLocation http://svn.apache.org/repos/asf/myfaces/ myfaces-master-pom/trunk/checkstyle/ default/myfaces-header.txt /headerLocation /configuration /plugin The comment is mine, having discovered that the old and completely obsolete directory http://svn.apache.org/repos/asf/myfaces/maven/trunk/ cannot be deleted because older releases of the master pom like this one: http://svn.apache.org/repos/asf/myfaces/ myfaces-master-pom/tags/myfaces-5/pom.xml point to http://svn.apache.org/repos/asf/myfaces/maven/trunk/ build-tools/src/main/resources/config/myfaces-checks.xml I would like to fix this crazy setup by following the multimodule setup as described here: http://maven.apache.org/plugins/maven-checkstyle-plugin/examples/multi-module-config.html This means creating a new project under myfaces-build-tools that contains our checkstyle rules, then following a normal release cycle for it. An alternative I tried was to use svn peg revisions to try to point to a file in a specific version of the svn repo but that doesn't seem to work via the svn web interface, just with the svn commandline tool. And anyway it still leaves us needing internet connectivity to run checkstyle. Are there any objections? If not, I'll try to implement that later this week. Regards, Simon
Re: [VOTE] promoting the subform component to Tomahawk
+1 On Mon, Jun 9, 2008 at 5:54 PM, Hazem Saleh [EMAIL PROTECTED] wrote: Hi Team, I wish to promote this subForm component to the next Tomahawk release. [+1] for agreeing with promoting the component to the next Tomahawk release. [-1] for disagreeing with promoting the component to the next Tomahawk release. Thanks all very much! -- Hazem Ahmed Saleh Ahmed http://www.jroller.com/page/HazemBlog -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
Re: [VOTE] myfaces-extensions as a new myfaces sub-project
+1 On Mon, Jun 2, 2008 at 8:52 AM, Gerhard Petracek [EMAIL PROTECTED] wrote: hello, we discussed whether or not we should start a new myfaces sub-project (details at: [1] and [2]). name: myfaces-extensions description: place for small innovative projects (which are beyond the current std. mechanisms of jsf) currently these small projects are: aspect-el, sev-en and scripting so - after the positive response let's vote! (there will be a separated discussion + vote concerning the names.) --- [ ] +1 for: myfaces-extensions should become a myfaces sub-project [ ] +0 [ ] -1 for: myfaces-extensions shouldn't become a myfaces sub-project --- regards, gerhard [1] http://www.nabble.com/-PROPOSAL--myfaces-extensions-to17466179.html#a17466179 [2] http://www.nabble.com/Re%3A--PROPOSAL--myfaces-extensions-p17474665.html -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
[COMMUNITY] MyFaces += Hazem Saleh
The Myfaces PMC is proud to announce a new addition to our community. Please welcome Hazem Saleh as the newest MyFaces committer! Hazem is an active member of the myfaces community, he contributed some cool components like captcha, password strength and provided many patches. He is also involved in the Apache Myfaces and Facelets book. @Hazem: Please add yourself to the Master-POM at https://svn.apache.org/repos/asf/myfaces/myfaces-master-pom/trunk/pom.xml --Manfred
Re: myfaces groovy support
Cool thing, Werner. Congrats! --Manfred On Tue, May 13, 2008 at 7:45 AM, Werner Punz [EMAIL PROTECTED] wrote: Hello everyone I just wanted to give notification that I took a small break from my components project which is still on track and that I am working on myfaces groovy support. I got the first artefacts already reloading, and a first code will be made available by the end of the week, early next week. (For the Sun guys reading, thanks a lot you gave me the final push to do it, although I did many things differently than you did) Ok what will be done: First of all I replaced all the factories with my own ones to enable the entire system, I also had to write my own context listener to handle the classloader issues. (We really need a change in the spec here to enable scripting properly - Ed?) Secondly once the factories were in place I added proxy generation code wherever needed to enable reloading proxies. Third, a classloader which forks into the groovy system to load the groovy code. The groovy code also has its own reloading weaving code added to enable reloading of groovy files on the groovy side of things (the woven aop reloading code is lost on the java side however if you just deliver classes instead of objects, my first approach was a try to enable everything on the java side) So what do we get Reloading for most artefacts (probably on method level if things work out the way I intend them to be (For certain artefacts there are contracts you have to program in on the groovy side to enable this - aka expose the private properties some artefacts have otherwise a on method reloading will not be possible). Maybe and this is a big maybe, if I can get it up and running (I want to replace code on the fly) reloading of methods on groovy classes loaded by groovy over the new classloader. Again this is a big if, I have not prototyped this fully yet, but it should be possible. The idea is, once you load an in groovy object over the classloader it should be possible to change its methods on the fly via the meta programming capabilities of groovy. Ok first code around friday or early next week. After that I will start further discussions. And again, thanks to Ryan and Ed for finally pushing me towards it (indirectly by doing it). I also have to admit I have had a look at some parts of the code to check how you guys solved some problems I have been facing - especially the dreaded classloader issues and weaving issues. (I did most of the stuff differently though due to the different approach I am doing, of a mixed groovy/java infrastructure to enable some things not reachable from the java side that easily, also I did not want to change the core code, I wanted to have it more as an extension). If you want to have a look at the code upfront before next week, send me a private mail, I just do not want to post it yet because it still is not done enough for a public post. Especially the init code I am still very unhappy with. Werner -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
Re: [Commons] Library Dependencies
+1 for removing any (transient) dependency to commons-logging And for logging that myfaces-commons-util classes wanna do themselves I strongly suggest SLF4J! --Manfred On Thu, Apr 24, 2008 at 8:16 PM, Scott O'Bryan [EMAIL PROTECTED] wrote: Hey guys, At the risk of getting hit with tomatoes and all kinds of rotten fruit, I would like to ask about some of the dependencies for the MyFaces Commons projects. IMO the MyFaces commons projects should not carry around an unnecessary amount of dependencies. Provided dependencies are one thing, but in general I think that dependencies on the JSF and Servlet should be just about the extent of it for most libraries. Currently the myfaces-commons-util's has a runtime dependency on the Apache Commons Logger. This means that if I'm using the renderkit and the R.I. I have to also include the logger in my libraries. I would like to remove this dependency and either use J2EE logging or standard java logging. Better yet, we might be able to beef up the contract on the utilities to throw exceptions and let logging be handled by the parent application. Does anyone concur? If not, please don't throw any tomatoes at me. :) Scott -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
Re: [ANNOUNCE] AspectEL code donation
Incubation is definitely not necessary. The bits of code that you can download at http://people.apache.org/~manolito/aspectel-1.0-SNAPSHOT.zip where built from scratch. The Aspect stuff that Gerald mentioned is not this library. He used a slightly different proprietary implementation. But the idea and concept where the same. AspectEL could be seen as a donation by a single MyFaces committer (= me). Don't think that we need an IP clearance in that case. So, should we start a voting then? --Manfred On Fri, Mar 28, 2008 at 3:56 PM, Matthias Wessendorf [EMAIL PROTECTED] wrote: Hi Manfred, sounds good. I strongly doubt, that an incubation of the library is required ;-) Not sure if we even need the much smaller process of the software grant / ip clearance. (Like we did with the portal bridge). I saw your presentation and like the main idea behind it, so I'll give you my +1 for a myfaces aspect el subproject. -Matthias On Fri, Mar 28, 2008 at 2:44 PM, Manfred Geiler [EMAIL PROTECTED] wrote: Hi all, As some of you already know (at least those who attended the JSFDays08 conference) I wrote a small goody project called AspectEL that I would like to donate to the MyFaces community. To give you an idea what it is about, here is the abstract of my presentation called Lightweight AOP with JSF: Dealing with entities and domain objects in your JSF views and backing beans is sometimes unnecessarily complicated. Aspect oriented programming would be a much more elegant way to add GUI specific logic directly to your entity classes rather than writing backing bean methods for all these GUI tasks. Real highly sophisticated AOP solutions might be overkill here and could make things even more complicated. This sessions shows you a surprisingly easy way of adding certain GUI aspects to your objects while dealing with them from within the presentation layer. Or in the words of a canvasser: AspectEL gives OOP back to your JSF managed beans :-) You could also have a look at the slides [1] for more details about the theory. If you are interested, please have a look at the source code and the example application at [2]. Just drop the example war into your Tomcat 5.x and manage your favorite beer brands. ;-) Please give me feedback. If there is enough interest I will start a discussion/vote thread about adding AspectEL as a new MyFaces sub project. Regards, Manfred [1] http://conference.irian.at/slidesvideo/pdfs/13_Th_14_Lightweight_AOP_with_JSF.pdf [2] http://people.apache.org/~manolito/aspectel-1.0-SNAPSHOT.zip -- Matthias Wessendorf further stuff: blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf mail: matzew-at-apache-dot-org -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
Re: JspStateManagerImpl into shared?
Mario, you are not alone in hating the shared concept. ;-) This is exactly where the myfaces-commons-xxx library comes into play, I often mentioned before. What we need is a module, that 1) has a super stable API 2) is used (ie. shared) by the myfaces core(!) as well as other myfaces projects 3) may be used by the experienced JSF app developer who wants to write his own StateManager or ELResolver or some other pluggable/replaceable JSF thingy (ie. all the things you can replace via faces-config.xml) Problem here again is the name of such a lib: myfaces-commons-base? myfaces-commons-core? myfaces-commons-super? myfaces-commons-commons? ;-) The name MUST reflect the fact that this jar is a very basic lib all other JSF stuff depends on. It is no place where we swiftly drop some nice and convenient utils stuff and the API is nothing to play around with. I think that if we find a good name and define some strict rules we could move most (or all?) stuff from myfaces-shared to this lib. And perhaps even get rid of shard in the long run! Of course, some well-known issues pop up immediately: which JSF-Spec - 1.1 and 1.2 or only 1.2? What about JSF 2.0? Thoughts? --Manfred On Tue, Apr 1, 2008 at 9:31 PM, Mario Ivankovits [EMAIL PROTECTED] wrote: Hi! Just to reiterate: I hate shared! ;-) Seriously, it seems that Orchestra has to implement a StateManager which holds the view state in the conversationContext instead of the session. At the moment it seems that large portions of JspStateManagerImpl can be reused, but requires to copy it over into Orchestra. With slight refactoring of JspStateManagerImpl it should be possible to just replace the actual storing/loading stuff. Does this qualify to move JspStateManagerImpl into shared? Or should I better copy the source over? Ciao, Mario -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
Re: MarkMail link adjustment
Jason, Thanks for the info. @dev, I adjusted all markmail links in the myfaces-master-pom accordingly. --Manfred On Tue, Apr 1, 2008 at 8:45 AM, Jason Hunter [EMAIL PROTECTED] wrote: Hi Manfred, I wanted to let you know that on MarkMail we've setup list home pages at URLs like /list/listid. I'm hoping you can adjust the MyFaces per-list archive links on http://myfaces.apache.org/mail-lists.html to point at these pages instead of using the multi-subdomains. Before: http://users.myfaces.markmail.org/ After: http://markmail.org/list/org.apache.myfaces.users The list home page URLs are more elegant and (we think) will help us some with Google that doesn't like sites having thousands of subdomains that seem to point at the same content. The list pages are pretty basic right now. We're going to make these pages sexy in the future with list metadata and everything, but for now we want to get people pointing at the right pages and phase out the multiple subdomain hack. Hopefully this is an easy fix for you. We see lots of referrals from the MyFaces links! (Please let me know if you're not the right person to contact about this.) -jh-
[ANNOUNCE] AspectEL code donation
Hi all, As some of you already know (at least those who attended the JSFDays08 conference) I wrote a small goody project called AspectEL that I would like to donate to the MyFaces community. To give you an idea what it is about, here is the abstract of my presentation called Lightweight AOP with JSF: Dealing with entities and domain objects in your JSF views and backing beans is sometimes unnecessarily complicated. Aspect oriented programming would be a much more elegant way to add GUI specific logic directly to your entity classes rather than writing backing bean methods for all these GUI tasks. Real highly sophisticated AOP solutions might be overkill here and could make things even more complicated. This sessions shows you a surprisingly easy way of adding certain GUI aspects to your objects while dealing with them from within the presentation layer. Or in the words of a canvasser: AspectEL gives OOP back to your JSF managed beans :-) You could also have a look at the slides [1] for more details about the theory. If you are interested, please have a look at the source code and the example application at [2]. Just drop the example war into your Tomcat 5.x and manage your favorite beer brands. ;-) Please give me feedback. If there is enough interest I will start a discussion/vote thread about adding AspectEL as a new MyFaces sub project. Regards, Manfred [1] http://conference.irian.at/slidesvideo/pdfs/13_Th_14_Lightweight_AOP_with_JSF.pdf [2] http://people.apache.org/~manolito/aspectel-1.0-SNAPSHOT.zip
Re: [orchestra] plans
yes, +1 on moving dynaform to sandbox. the annotation stuff seems stable and there are many people out there who would like it to see this dings in the official maven repo. --Manfred On Wed, Mar 5, 2008 at 8:59 AM, Mario Ivankovits [EMAIL PROTECTED] wrote: Hi! 2) release of orchestra-core15-1.0 We're working on it, but there's quite a lot of effort still needed. It all works (and is being used in production) but needs a lot of polishing before a stable API can be declared. Probably a couple of months away.. Really months? What do you plan to change/polish? As it is now, probably yes. The dynaForm stuff is really a hughe code-base needing some thoughts to being sure having a stable api. What we can think of moving the dynaForm stuff into the Orchestra sandbox. Then core15 should be a no-brainer for a release. This might make sense as thoughts are to merge the dynaForm stuff with another project. I'll kick off a discussion about it soon. Ciao, Mario -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
Re: The MyFaces Sandbox CAPTCHA component is released :)
cool component - thanks! --Manfred On Fri, Feb 29, 2008 at 6:15 PM, Hazem Saleh [EMAIL PROTECTED] wrote: Hi Guys, Iam pleased to tell you that I finally finished developing the CAPTCHA component. We can now have a CAPTCHA by just writing: s:captcha captchaSessionKeyName=mySessionKey/ This would generates a captcha with a random text image then set the generated text in the session attribute mySessionKey. I hope that you all like the new Apache MyFaces sandbox CAPTCHA component :). Here is the patch link: https://issues.apache.org/jira/browse/TOMAHAWK-1207 Later, I will include the component documentation patch. BTW, I would like to thank Zubin wadia, Martin Marinschek, Thomas speigl for encouraging me developing this component. I really like all the Apache MyFaces community. Thanks to all of you. -- Hazem Ahmed Saleh Ahmed http://www.jroller.com/HazemBlog -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
[continuum] upgrading
FYI MyFaces Continuum is currently down for maintainance. Trying to upgrade to 1.1 final --Manfred
[continuum] upgrading
??? Is somebody logged in as mrmaven and killing my processes? --Manfred -- Forwarded message -- From: Manfred Geiler [EMAIL PROTECTED] Date: Mon, Feb 25, 2008 at 1:54 PM Subject: [continuum] upgrading To: MyFaces Development dev@myfaces.apache.org FYI MyFaces Continuum is currently down for maintainance. Trying to upgrade to 1.1 final --Manfred -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
[continuum] AAARGH! (was: svn commit: r628196 - /myfaces/myfaces-master-pom/trunk/pom.xml)
Scott, your faulty master pom commit (timezome instead of timezone) cost me half a day. How come? - Continuum did no longer build the master pom correctly -- your fault - The continuum messages (see [1]) where totally misleading -- NOT your fault of course ;-) - Since I could not determine the cause (clearing working dir or restarting continuum did not work) I decided to upgrade to continuum 1.1 final - due anyway -- MY fault! - I was able to install the new version but migrating the data from 1.1-beta2 to 1.1 was a total flop - although I tried hard, believe me! (see http://wiki.apache.org/myfaces/Continuum_Build for details) - So I stepped back to continuum 1.1-beta2 - I removed the build definition for the myfaces master - I was not able to create a new build definition - Now the continuum exceptions luckily lead me to the actual cause @Scott Please note: I'm NOT posting this publicly to dev@ to blame you. Yes, I'm angry. But not because of your mistake (could happen) but because of Continuum. And I want to prevent others form stepping into the same traps. ;-) @All What should we do regarding Continuum builds? Anyone volunteering to migrate all build definitions and users manually? --Manfred [1] Build Error: org.codehaus.plexus.taskqueue.execution.TaskExecutionException: Error executing action 'update-project-from-working-directory' at org.apache.maven.continuum.buildcontroller.DefaultBuildController.performAction(DefaultBuildController.java:432) at org.apache.maven.continuum.buildcontroller.DefaultBuildController.build(DefaultBuildController.java:137) at org.apache.maven.continuum.buildcontroller.BuildProjectTaskExecutor.executeTask(BuildProjectTaskExecutor.java:50) at org.codehaus.plexus.taskqueue.execution.ThreadedTaskQueueExecutor$ExecutorRunnable$1.run(ThreadedTaskQueueExecutor.java:116) at edu.emory.mathcs.backport.java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:442) at edu.emory.mathcs.backport.java.util.concurrent.FutureTask.run(FutureTask.java:176) at edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:665) at edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:690) at java.lang.Thread.run(Thread.java:595) Caused by: org.apache.maven.continuum.execution.ContinuumBuildExecutorException: Error while mapping metadata:add.project.project.building.error add.project.unknown.error at org.apache.maven.continuum.execution.maven.m2.MavenTwoBuildExecutor.updateProjectFromCheckOut(MavenTwoBuildExecutor.java:159) at org.apache.maven.continuum.core.action.UpdateProjectFromWorkingDirectoryContinuumAction.execute(UpdateProjectFromWorkingDirectoryContinuumAction.java:75) at org.apache.maven.continuum.buildcontroller.DefaultBuildController.performAction(DefaultBuildController.java:406) ... 8 more [2] -- Forwarded message -- From: [EMAIL PROTECTED] Date: Fri, Feb 15, 2008 at 11:58 PM Subject: svn commit: r628196 - /myfaces/myfaces-master-pom/trunk/pom.xml To: [EMAIL PROTECTED] Author: sobryan Date: Fri Feb 15 14:58:57 2008 New Revision: 628196 URL: http://svn.apache.org/viewvc?rev=628196view=rev Log: Added myself as a developer to MyFaces... Modified: myfaces/myfaces-master-pom/trunk/pom.xml Modified: myfaces/myfaces-master-pom/trunk/pom.xml URL: http://svn.apache.org/viewvc/myfaces/myfaces-master-pom/trunk/pom.xml?rev=628196r1=628195r2=628196view=diff == --- myfaces/myfaces-master-pom/trunk/pom.xml (original) +++ myfaces/myfaces-master-pom/trunk/pom.xml Fri Feb 15 14:58:57 2008 @@ -205,6 +205,19 @@ timezone+1/timezone /developer developer +idsobryan/id +nameScott O'Bryan/name +email[EMAIL PROTECTED]/email +organizationOracle, U.S.A/organization +organizationUrlhttp://www.oracle.com/organizationUrl +roles +rolePortlet Bridge Project Lead/role +roleJSR-301 JSF Portlet Bridge EG Member/role +rolePortlet Guru/role +/roles +timezome-7/timezone +/developer +developer idschof/id nameSean Schofield/name email[EMAIL PROTECTED]/email
Re: [continuum] AAARGH! (was: svn commit: r628196 - /myfaces/myfaces-master-pom/trunk/pom.xml)
On Mon, Feb 25, 2008 at 7:43 PM, Scott O'Bryan [EMAIL PROTECTED] wrote: Sigh... I'm sorry about that Manfred. I should have been more careful. It was a simple change, but apparently it was a simple change with a typo... Yeah, no problem. As I said before, my anger was at Continuum not at you. But as we have learned: always look at the bright side. Now, I actually learned how to start/stop/install/upgrade continuum. Hooray! :-) --Manfred Anyway, thanks for the information and the upgrade... ;-) Scott Manfred Geiler wrote: Scott, your faulty master pom commit (timezome instead of timezone) cost me half a day. How come? - Continuum did no longer build the master pom correctly -- your fault - The continuum messages (see [1]) where totally misleading -- NOT your fault of course ;-) - Since I could not determine the cause (clearing working dir or restarting continuum did not work) I decided to upgrade to continuum 1.1 final - due anyway -- MY fault! - I was able to install the new version but migrating the data from 1.1-beta2 to 1.1 was a total flop - although I tried hard, believe me! (see http://wiki.apache.org/myfaces/Continuum_Build for details) - So I stepped back to continuum 1.1-beta2 - I removed the build definition for the myfaces master - I was not able to create a new build definition - Now the continuum exceptions luckily lead me to the actual cause @Scott Please note: I'm NOT posting this publicly to dev@ to blame you. Yes, I'm angry. But not because of your mistake (could happen) but because of Continuum. And I want to prevent others form stepping into the same traps. ;-) @All What should we do regarding Continuum builds? Anyone volunteering to migrate all build definitions and users manually? --Manfred [1] Build Error: org.codehaus.plexus.taskqueue.execution.TaskExecutionException: Error executing action 'update-project-from-working-directory' at org.apache.maven.continuum.buildcontroller.DefaultBuildController.performAction(DefaultBuildController.java:432) at org.apache.maven.continuum.buildcontroller.DefaultBuildController.build(DefaultBuildController.java:137) at org.apache.maven.continuum.buildcontroller.BuildProjectTaskExecutor.executeTask(BuildProjectTaskExecutor.java:50) at org.codehaus.plexus.taskqueue.execution.ThreadedTaskQueueExecutor$ExecutorRunnable$1.run(ThreadedTaskQueueExecutor.java:116) at edu.emory.mathcs.backport.java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:442) at edu.emory.mathcs.backport.java.util.concurrent.FutureTask.run(FutureTask.java:176) at edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:665) at edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:690) at java.lang.Thread.run(Thread.java:595) Caused by: org.apache.maven.continuum.execution.ContinuumBuildExecutorException: Error while mapping metadata:add.project.project.building.error add.project.unknown.error at org.apache.maven.continuum.execution.maven.m2.MavenTwoBuildExecutor.updateProjectFromCheckOut(MavenTwoBuildExecutor.java:159) at org.apache.maven.continuum.core.action.UpdateProjectFromWorkingDirectoryContinuumAction.execute(UpdateProjectFromWorkingDirectoryContinuumAction.java:75) at org.apache.maven.continuum.buildcontroller.DefaultBuildController.performAction(DefaultBuildController.java:406) ... 8 more [2] -- Forwarded message -- From: [EMAIL PROTECTED] Date: Fri, Feb 15, 2008 at 11:58 PM Subject: svn commit: r628196 - /myfaces/myfaces-master-pom/trunk/pom.xml To: [EMAIL PROTECTED] Author: sobryan Date: Fri Feb 15 14:58:57 2008 New Revision: 628196 URL: http://svn.apache.org/viewvc?rev=628196view=rev Log: Added myself as a developer to MyFaces... Modified: myfaces/myfaces-master-pom/trunk/pom.xml Modified: myfaces/myfaces-master-pom/trunk/pom.xml URL: http://svn.apache.org/viewvc/myfaces/myfaces-master-pom/trunk/pom.xml?rev=628196r1=628195r2=628196view=diff == --- myfaces/myfaces-master-pom/trunk/pom.xml (original) +++ myfaces/myfaces-master-pom/trunk/pom.xml Fri Feb 15 14:58:57 2008 @@ -205,6 +205,19 @@ timezone+1/timezone /developer developer +idsobryan/id +nameScott O'Bryan/name +email[EMAIL PROTECTED]/email
Fwd: MyFaces API and IMPL docs 404.
Simon, is http://myfaces.apache.org/javadoc.html an official page? Google search says that there is no external link to that page. Should we get rid of it or is there a quick way to fix this? Thanks, Manfred -- Forwarded message -- From: [EMAIL PROTECTED] Date: Feb 20, 2008 7:25 AM Subject: MyFaces API and IMPL docs 404. To: [EMAIL PROTECTED] Hi, Wasn't sure whom to inform. http://myfaces.apache.org/javadoc.html getting 404s for the API and IMPL docs. Thanks Rohit. The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain proprietary, confidential or privileged information. If you are not the intended recipient, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately and destroy all copies of this message and any attachments. WARNING: Computer viruses can be transmitted via email. The recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email. www.wipro.com -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
Re: [VOTE] Move Portlet-Bridge trunk
+1 --Manfred On Feb 19, 2008 11:49 PM, Scott O'Bryan [EMAIL PROTECTED] wrote: Over the next few days I'm going to be moving in my changes to support multiple bridges. As a fist step, I need to move the current trunk at https://svn.apache.org/repos/asf/myfaces/portlet-bridge/trunk to https://svn.apache.org/repos/asf/myfaces/portlet-bridge/core/trunk [1]. This will allow me to add a folder for a master pom and the main page of the website. This will require developers currently working on the trunk to switch their working copies to use the new location and we will also loose some history. Given these effects, please vote: +1 Yes, moving it is okay 0 Don't care -1 No, do not move it.. Provide reasons and alternatives. Thanks, Scott [1] https://issues.apache.org/jira/browse/PORTLETBRIDGE-26 -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
Re: MyFaces API and IMPL docs 404.
Deleting it seems not so easy. There is still some update cron job running with user schof. Right? This are the properties of the file in /www/myfaces.apache.org 85847169 8 -rw-rw-r-- 1 schof myfaces 7397 Feb 17 21:34 javadoc.html So it seems that it gets updated/copied on a regular basis. Where is this script and from where does it update/copy the files? Thanks, Manfred On Feb 20, 2008 12:12 PM, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Hi Manfred, No, that page http://myfaces.apache.org/javadoc.html is just a leftover. It should not exist, and can be deleted. The maven website deploy stuff doesn't delete old obsolete stuff when a new site is deployed. I guess google indexed it when it was once valid, and now people are finding it :-( The thread that Matthias refers to is about something a bit different. There should be no javadoc.html page at the top level of the site, as this just does not make sense with the large number of myfaces projects that now exist. But there should be (and are) javadoc index pages under core11 and core12 directories - and possibly tomahawk directory (TODO). Regards, Simon Matthias Wessendorf schrieb: Hi On Feb 20, 2008 10:39 AM, Manfred Geiler [EMAIL PROTECTED] wrote: Simon, is http://myfaces.apache.org/javadoc.html an official page? Google search says that there is no external link to that page. it was... and we talked about that already in this thread ([1]). This page was also linked to tagdocs. -Matthias [1] http://www.mail-archive.com/dev@myfaces.apache.org/msg29331.html Should we get rid of it or is there a quick way to fix this? Thanks, Manfred -- Forwarded message -- From: [EMAIL PROTECTED] Date: Feb 20, 2008 7:25 AM Subject: MyFaces API and IMPL docs 404. To: [EMAIL PROTECTED] Hi, Wasn't sure whom to inform. http://myfaces.apache.org/javadoc.html getting 404s for the API and IMPL docs. Thanks Rohit. -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
Re: Can I be added to Admin role on portlet-bridge jira
The portlet bridge project role assigments where a total mess. I fixed them and also added you to the myfaces-administrators group. Scott, please try again. --Manfred On Feb 18, 2008 9:22 PM, Scott O'Bryan [EMAIL PROTECTED] wrote: Hey guys, For some reason I do not have administrative rights to the Portlet-Bridge role on Jira. Can someone add me to that role please? I'm trying to create the release notes for the alpha release we just did and I can't seem to. :) Thanks, Scott
Re: [Jira] Question about Fix Version field
Matze, This is a (hardcoded?) Jira feature. There is one special issue permission in Jira that controls who is allowed to assign a fix version: Resolve Issues (Ability to resolve and reopen issues. This includes the ability to set a fix version.) Since it is necessary for the reporter to be able to reopen issues, this permission is assigned to the reporter role in the Standard Permission Scheme that MyFaces uses. --Manfred On Feb 6, 2008 10:49 AM, Matthias Wessendorf [EMAIL PROTECTED] wrote: our jira instance has these fields (and more...): Fix Version/s: Affects Version/s: Both are editable by the bug filer. The Affects Version/s: makes sense, since they need to identify the broken version. Now, I have problems in understanding the Fix Version/s field. I understand it this way: -a committer fixed the problem and marks the fixed version is this field. If this is correct, why should we leave it editable by the filer ? Or is it more a I wish to have a fix for version blah ? If so, not sure if that really works well in OS culture. Would be great if someone could help me :-) -Matthias -- Matthias Wessendorf further stuff: blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf mail: matzew-at-apache-dot-org -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
Re: [Jira] Question about Fix Version field
Yes, and this is only possible by taking away the Resolve Issues permission for reporters (=issue-filers) which would also forbid the reporter to reopen an issue. Question is: do we want this. My feeling is: no, because: In a perfect world :-) the reporter downloads the fix version release as soon as it is out and tests his issue with this new release. In case the fix did not really fix the issue in question, the reporter changes the jira issue to reopened and sets the fix version field to unknown. This is the idea behind this permission, I think. --Manfred On Feb 6, 2008 12:31 PM, Matthias Wessendorf [EMAIL PROTECTED] wrote: On Feb 6, 2008 12:29 PM, Antonio Petrelli [EMAIL PROTECTED] wrote: 2008/2/6, Matthias Wessendorf [EMAIL PROTECTED]: but the Fix version/s should be only for the committer, when closing. Not only when closing. It can be used to schedule tickets. At Struts and Tiles we use this technique very frequently: at least it is useful to schedule on a branch or on the trunk. yeah, I was unclear. let's say it this way: -an issue-filer (a non-committer) should not be able to edit this field. -M Antonio -- Matthias Wessendorf further stuff: blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf mail: matzew-at-apache-dot-org -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
Re: [orchestra] rename scope flash to access
yes, good idea +1 I like the name access scope and also experienced people who use the term flash scope for t:saveState usage. --Manfred On Jan 29, 2008 8:59 AM, Simon Kitching [EMAIL PROTECTED] wrote: Hi All, Currently in orchestra there are two types of conversation scope: manual and flash. With manual, a conversation must be explicitly ended via either a call to the Orchestra API, or use of a jsf tag. With flash, the conversation is automatically ended when a request cycle ends and no object in the conversation was accessed. Some people have noted that other libraries use the term flash scope for a somewhat different purpose. I therefore propose changing the name to access scope. This change will mean renaming about 6 classes, updating the examples and updating the website documentation. I intend to keep backwards compatibility with 1.0 to the level where normal Spring configuration files still work unaltered (and will test this by making sure the existing orchestra examples work unaltered, before I update them to show the new config). However for classes which would only be used by people deriving their own custom scope-managers, etc., I don't currently plan to keep full binary compatibility. Are there any objections? Regards, Simon -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
[COMMUNITY] MyFaces += Bernhard Huemer
The Myfaces PMC is proud to announce a new addition to our community. Please welcome Bernhard Huemer as the newest MyFaces committer. Bernhard Huemer has been providing several patches (including a very tricky EL-bug) and has also been very active on the mailing-list. @Bernhard: Please add yourself to the Master-POM at https://svn.apache.org/repos/asf/myfaces/myfaces-master-pom/trunk/pom.xml --Manfred
Re: [orchestra] rename scope flash to access
access says exactly what it does. keeps the conversation active as long as it is accessed - ie. as long as any bean in this conversation is used during the next request. --Manfred On Jan 29, 2008 9:32 PM, Kito D. Mann [EMAIL PROTECTED] wrote: Hmmm... I agree that flash can be misleading, but access doesn't seem very descriptive to me. I think page or view might be more appropriate. ~~~ Kito D. Mann - Author, JavaServer Faces in Action http://www.virtua.com - JSF/Java EE consulting, training, and mentoring http://www.JSFCentral.com - JavaServer Faces FAQ, news, and info -Original Message- From: Simon Kitching [mailto:[EMAIL PROTECTED] Sent: Tuesday, January 29, 2008 3:00 AM To: dev@myfaces.apache.org Subject: [orchestra] rename scope flash to access Hi All, Currently in orchestra there are two types of conversation scope: manual and flash. With manual, a conversation must be explicitly ended via either a call to the Orchestra API, or use of a jsf tag. With flash, the conversation is automatically ended when a request cycle ends and no object in the conversation was accessed. Some people have noted that other libraries use the term flash scope for a somewhat different purpose. I therefore propose changing the name to access scope. This change will mean renaming about 6 classes, updating the examples and updating the website documentation. I intend to keep backwards compatibility with 1.0 to the level where normal Spring configuration files still work unaltered (and will test this by making sure the existing orchestra examples work unaltered, before I update them to show the new config). However for classes which would only be used by people deriving their own custom scope-managers, etc., I don't currently plan to keep full binary compatibility. Are there any objections? Regards, Simon -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
Re: [MyFaces 1.2.1] question on trunk and tag
On Jan 20, 2008 6:50 PM, Matthias Wessendorf [EMAIL PROTECTED] wrote: Hi, 2) The trunk says 1.2.1-SNAPSHOT. In case we use the above mentioned TAG, shouldn't it say 1.2.2-SNAPSHOT already? No, I think 1.2.1-SNAPSHOT on trunk is ok as long as there is no release. The 1_2_1_RC (normally) is a working copy branch(!) that is used to prepare the release without disturbing concurrent development. BTW, why is 1_2_1_RC a tag? It should be a branch of course. Leaving the version on trunk unchanged gives the release manager the chance to throw away this working copy branch and start over with a new copy from the trunk. textbook example: As soon as the release is out, all important fixes and changes on this branch (including the pom updates to 1.2.2-SNAPSHOT) will be merged back to the trunk. --Manfred
Myfaces commons utils
Just had a look at the new commons-utils module and found the class TagUtils. Please forgive me for saying it directly: This piece of code is horrible! It seems to be a mixture of various static methods without any direct relation to Tags. Looks like a huge graveyard for quick and dirty static code pieces. Having in mind a stable API (this is what we intended with these commons jars - right?) I must say we SHOULD get rid of this code and/or refactor it to several separate utils classes. Each one of them having a clear and certain scope. WDYT? --Manfred
[VOTE] MyFaces Master pom v5
This is the formal vote for the new myfaces master POM version 5. You can find the signed release candidate at [1]. Please vote +1 if you reviewed the new master pom version and think we can use it -1 if you found a flaw or potential problem with the new master pom Thanks, --Manfred [1] http://people.apache.org/builds/myfaces/m2-staging-repository/org/apache/myfaces/myfaces/5/
Re: [VOTE] MyFaces Master pom v5
here is my own
+1
We got 4 positive votes. I hereby formally close this poll.
--Manfred
On Jan 18, 2008 2:51 PM, Bruno Aranda [EMAIL PROTECTED] wrote:
+1
On 18/01/2008, Martin Marinschek [EMAIL PROTECTED] wrote:
+1,
regards,
Martin
On 1/18/08, Simon Kitching [EMAIL PROTECTED] wrote:
Manfred Geiler [EMAIL PROTECTED] schrieb:
This is the formal vote for the new myfaces master POM version 5.
You can find the signed release candidate at [1].
Please vote
+1 if you reviewed the new master pom version and think we can use it
-1 if you found a flaw or potential problem with the new master pom
+1 (non-binding).
--
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
--
http://www.irian.at
Your JSF powerhouse - JSF Consulting,
Development and Courses in English and
German
Professional Support for Apache MyFaces
Re: MyFaces Build Tools
ok, I will start the myfaces-master-pom release process right now --Manfred On Jan 18, 2008 12:59 PM, Simon Kitching [EMAIL PROTECTED] wrote: Matthias Wessendorf [EMAIL PROTECTED] schrieb: Hi, I ported some Trinidad fixes over to the build-tools. I also think it might be the case where we want to release the bits, to get them into usage. I think they are stable (since just created out to Trinidad), so we might want go with a 1.0.0 instead of something like 1.0.0-alpha What do you think? Sounds good to me. I'd love to see these released, and 1.0.0 sounds reasonable as the code is already known to work. However at the moment, myfaces-plugin-parent depends on the myfaces-master-pom version 4. IMO it would be nice to get myfaces-master-pom:5 released first, then used by the build plugins. The trunk version of myfaces-master has: (1) a new developer (gerhard) (2) updated plugin versions (3) versions defined for a bunch of plugins that had no version defined previously (ie not reproducable builds) Sorry, but I cannot offer to help with releasing the master, as I am rather overloaded at the moment... Regards, Simon -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
[COMMUNITY] MyFaces += Gerhard Petracek
The Myfaces PMC is proud to announce a new addition to our community. Please welcome Gerhard Petracek as the newest MyFaces committer. Gerhard has been very active on the mailing lists and has provided several patches for the Trinidad components. He also cares about up-to-date wiki pages. @Gerhard: Please add yourself to the Master-POM at https://svn.apache.org/repos/asf/myfaces/myfaces-master-pom/trunk/pom.xml --Manfred
Re: UIInput.resetValue()
-1 Sorry, I cannot agree. The API doc of resetValue() tells you why: Convenience method to reset [..] A utility like method for convenience like this one does not belong to an interface. It does not add any behavioural function. UIInput is not an interface but a (base) class, so it is ok to have such a method there. Matze, do you have any concrete use case that could confirm your POV? --Manfred On Jan 15, 2008 7:22 AM, Matthias Wessendorf [EMAIL PROTECTED] wrote: Hi, the resetValue() method was added directly to UIinput, instead to a proper interface (EditableValueHolder). I guess this was done, to not break impls of that interface. IMO this is wrong and should (at least in JSF2) be part of the EditableValueHolder interface. Since JSF2 will bring much more new bits, such an enhancement on the interface might be valueable. What is your take on that ? -Matthias -- Matthias Wessendorf further stuff: blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf mail: matzew-at-apache-dot-org
[jira] Created: (MYFACES-1803) noscript elements should be rendered for better WAI support
noscript elements should be rendered for better WAI support - Key: MYFACES-1803 URL: https://issues.apache.org/jira/browse/MYFACES-1803 Project: MyFaces Core Issue Type: Improvement Components: General Affects Versions: 1.2.0, 1.1.5 Reporter: Manfred Geiler Assignee: Manfred Geiler Priority: Minor According to the Web Accessibility Initiative (WAI) guidelines (http://www.w3.org/WAI/) for every script element there should also be a noscript element. Although standard JSF apps won't function without Javascript, it is possibly to write accessible apps if the developer provides alternative paths (outputLinks instead of commandLinks, etc.) through the application. Automated web accessibility check tools signal missing noscript elements as errors. For most script elements we render in the JSF core now, it might be difficult or even impossible (eg commandLink) to automatically render alternative code that would work with scripting disabled. But anyway, we should at least render noscript elements that tell the user why the app does not run in his browser. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: UIInput.resetValue()
Why not use the last if alone?
if (component instanceof EditableValueHolder)
{
EditableValueHolder holder = (EditableValueHolder)component;
holder.setValue(null);
holder.setSubmittedValue(null);
holder.setLocalValueSet(false);
holder.setValid(true);
}
Every UIInput is an EditableValueHolder and the UIXEditable as well, right?
This code fragement could also be candidate for a
EditableValueHolderUtils class in the MyFaces Commons.
--Manfred
On Jan 15, 2008 3:47 PM, Simon Lessard [EMAIL PROTECTED] wrote:
Although I'm -1 also because of backward compatibility, I also felt that it
should have been added to the interface to start with as it simplifies many
loops used for reseting EditableValueHolder of the whole tree. You cannot
use instanceof UIInput for those as Trinidad input components, for example,
does not extends UIInput, but do implement EditableValueHolder so the loop's
body has to look like:
if (component instanceof UIXEditable)
{
((UIXEditable)component).resetValue();
}
else if (component instanceof UIInput)
{
((UIInput)component).resetValue();
}
else if (component instanceof EditableValueHolder)
{
EditableValueHolder holder = (EditableValueHolder)component;
holder.setValue(null);
holder.setSubmittedValue(null);
holder.setLocalValueSet(false);
holder.setValid(true);
}
Maybe a good compromise would be to alter UIViewRoot to add a
resetAllEditableValueHolderValues method.
Regards,
~ Simon
On Jan 15, 2008 3:19 AM, Manfred Geiler [EMAIL PROTECTED] wrote:
-1
Sorry, I cannot agree.
The API doc of resetValue() tells you why:
Convenience method to reset [..]
A utility like method for convenience like this one does not belong
to an interface. It does not add any behavioural function.
UIInput is not an interface but a (base) class, so it is ok to have
such a method there.
Matze, do you have any concrete use case that could confirm your POV?
--Manfred
On Jan 15, 2008 7:22 AM, Matthias Wessendorf [EMAIL PROTECTED] wrote:
Hi,
the resetValue() method was added directly to UIinput, instead to a
proper interface (EditableValueHolder).
I guess this was done, to not break impls of that interface.
IMO this is wrong and should (at least in JSF2) be part of the
EditableValueHolder interface.
Since JSF2 will bring much more new bits, such an enhancement on the
interface might be valueable.
What is your take on that ?
-Matthias
--
Matthias Wessendorf
further stuff:
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
mail: matzew-at-apache-dot-org
Re: UIInput.resetValue()
On Jan 15, 2008 4:16 PM, Matthias Wessendorf [EMAIL PROTECTED] wrote: We here can only talk... The spec itself is made behind closed doors ;-) Not really closed ajar would be a better word: at least everyone is allowed to comment on early drafts ;-) --Manfred
Re: Master pom and pmd plugin
I could live with (3) --Manfred On Jan 14, 2008 11:55 AM, Simon Kitching [EMAIL PROTECTED] wrote: Hi All, Currently the master pom (5-SNAPSHOT) defines the pmd plugin in the reporting section. Unfortunately it appears that while most maven report plugins are smart enough not to generate any output if they have no input files, pmd does not do this. As a result, every project module (which is just generating a site) gets pointless CMD and PMD reports (which causes the creation of a whole project reports menu to hold them). Solution (1) is to just take this definition out of the master pom, and have modules that want pmd/cmd reports define the plugin. Solution (2) is for each project module to disable these reports by defining an empty reportSet. Note that the child modules need to then re-enable the reportSet which means repeating all of the config for that plugin anyway. However when/if the pmd plugin is fixed it is slightly easier to then go back to defining it just in the parent. Solution (3) is to live with these pointless project reports menus containing pointless cmd/pmd report pages until/if the plugin is fixed. I'm in favour of (1) myself, although (2) is also possible (I have just done this for core12 module a few minutes ago). What would you prefer? Regards, Simon
Re: jira: resolved versus closed status
Common practice in the past was that the release manager sets all resolved issues to closed after the release is out. --Manfred On 1/9/08, Simon Kitching [EMAIL PROTECTED] wrote: Hi All, I see that there are quite a few issues in JIRA marked as resolved. The status of resolved means that the developer thinks it is now fixed, and is waiting for either the person who raised the request or the QA department to check it and then close the issue. If you fix an issue, and there is no-one who is going to double-check it for you, then please mark the issue as *closed*, not as *resolved*. Thanks, Simon
[COMMUNITY] MyFaces += Michael Freedman
The Myfaces PMC is proud to announce a new addition to our community. Please welcome Michael Freedman as the newest MyFaces committer. Michael has been very, very active with the portlet-bridge project, has submitted a lot of patches, most of which already have been applied, and he is also active in the community. @Michael: Please add yourself to the Master-POM at https://svn.apache.org/repos/asf/myfaces/myfaces-master-pom/trunk/pom.xml --Manfred
Re: [Build-Tools] java packages
maven2 is ok I think at least it makes sure we have a namespace for incompatible maven3 plugins in the future... ;-) --Manfred On 12/21/07, Matthias Wessendorf [EMAIL PROTECTED] wrote: Hi, should we always start with this package ? org.apache.myfaces.buildtools.maven2 or org.apache.myfaces.buildtools.maven than -plugin.wagon -plugin.jdev -plugin.faces -plugin.javascript that would be similar to the maven-plugins, provided by the maven-folks; not really sure on maven vs maven2 thx! Matthias -- Matthias Wessendorf further stuff: blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf mail: matzew-at-apache-dot-org -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
Re: Question on ValueExpression, with an empty ExpressionString (Jetty vs Tomcat)
My personal feeling is that getValueExpression should NOT return null if explictly called with an empty String. However, this is something for the Unified EL (ie. JSP) specification. If this behaviour is unclear from the spec, it should be explicitly defined there. --Manfred On 12/21/07, Matthias Wessendorf [EMAIL PROTECTED] wrote: Inside of Trinidad's EditableValueRenderer (org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.EditableValueRenderer) there getReadOnly(...), which is called by all inputXyz Renderers to check if the component should be rendered readOnly or not That method checks if the component is readOnly AND it also checks if the underlying EL is readOnly. If that method returns TRUE, the component is readOnly (and there for a inputText isn't editable)...makes sense, so far... Here is a use-case tr:inputText label=Label a) value=/ (yes, may be stupid, but can happen...) Since the getReadOnly() checks if the EL is readOnly... it does this as well: ValueExpression ve = getValueExpression(bean); In Jetty (jetty-6.1.2rc2), which uses Sun/Glassfish/RI EL (com.sun.el.ValueExpressionImpl) == It returns an object that is readOnly (which is correct) and the getExpressionString is (empty). In tomcat 6. which uses this EL-Impl org.apache.jasper.el.JspValueExpression, it returns NULL Now, I wonder what the correct EL behavior is. I tend to think, that Tomcat is right, because there is no ExpressionString, so not a real Expression, but others could have a different understanding of it. What is your take on that ? -- Matthias Wessendorf further stuff: blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf mail: matzew-at-apache-dot-org -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
Re: [Build-Tools] Archetypes ?
+1 yes, sure On 12/20/07, Matthias Wessendorf [EMAIL PROTECTED] wrote: Hi, IMO the archetypes could be moved into the build-tools as well. /myfaces-build-tools -/maven2-plugins -/maven2-archetype -here they are -M -- Matthias Wessendorf further stuff: blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf mail: matzew-at-apache-dot-org -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
Re: [Build-Tools] GroupId
yes, ok or org.apache.myfaces.buildtools ? --Manfred On 12/20/07, Matthias Wessendorf [EMAIL PROTECTED] wrote: Hi, I like to use groupIdorg.apache.myfaces.build/groupId as the groupId And the java packages like: -org.apache.myfaces.build.wagon -org.apache.myfaces.build.faces -... WDYT ? -M -- Matthias Wessendorf further stuff: blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf mail: matzew-at-apache-dot-org -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
Re: [site] wiki page on deploying the website
I also wondered about this wiki page and I think it is somehow outdated. Last time I played around with the site build, I could not find this deploy.sh thing and there actually was no automatic site deployment. What I did: I added the site build to Continuum. So in fact it IS getting automatically deployed every night now. And it's also possible to build it manually from there. (Continuum group org.apache.myfaces) Simon, please register at: http://myfaces.zones.apache.org:8080/continuum/ I will assign the needed permissions as soon as you have your user. And: Could you then please update the wiki ? ;-) --Manfred On 12/17/07, simon [EMAIL PROTECTED] wrote: Hi, There is a page on deploying the myfaces website here: http://wiki.apache.org/myfaces/Deploying_the_Webpage_of_MyFaces However it says that site deployment is automatic. I have never heard of this, and have always deployed sites elsewhere using: mvn site-deploy This builds the site locally, uses scp to copy it to the configured distribution location (usu. on people.apache.org aka minotaur), from where it is automatically copied to the public site ( mirrors). Can someone enlighten me about this automatic site deployment thing? Regards, SImon -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
