Fwd: Jenkins job MyFaces/Tobago pipeline/master#56 failed
I've been getting these emails for ~2 weeks now. Can someone please fix the build? Dennis -- Forwarded message - From: Mr. Jenkins Date: Mon, Sep 14, 2020 at 6:02 AM Subject: Jenkins job MyFaces/Tobago pipeline/master#56 failed To: There is a build failure in MyFaces/Tobago pipeline/master. Build: https://ci-builds.apache.org/job/MyFaces/job/Tobago%20pipeline/job/master/56/ Logs: https://ci-builds.apache.org/job/MyFaces/job/Tobago%20pipeline/job/master/56/console Changes: https://ci-builds.apache.org/job/MyFaces/job/Tobago%20pipeline/job/master/56/changes -- Mr. Jenkins Director of Continuous Integration
you know the project is getting big when ...
The system is out of resources. Consult the following stack trace for details. java.lang.OutOfMemoryError: Java heap space at com.sun.tools.javac.util.Position$LineMapImpl.build(Position.java:139) at com.sun.tools.javac.util.Position.makeLineMap(Position.java:63) at com.sun.tools.javac.parser.Scanner.getLineMap(Scanner.java:1105) at com.sun.tools.javac.main.JavaCompiler.parse(JavaCompiler.java:512) at com.sun.tools.javac.main.JavaCompiler.parse(JavaCompiler.java:550) at com.sun.tools.javac.main.JavaCompiler.parseFiles(JavaCompiler.java:801) at com.sun.tools.javac.main.JavaCompiler.compile(JavaCompiler.java:727) at com.sun.tools.javac.main.Main.compile(Main.java:353) at com.sun.tools.javac.main.Main.compile(Main.java:279) at com.sun.tools.javac.main.Main.compile(Main.java:270) at com.sun.tools.javac.Main.compile(Main.java:87) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.codehaus.plexus.compiler.javac.JavacCompiler.compileInProcess(JavacCompiler.java:420) at org.codehaus.plexus.compiler.javac.JavacCompiler.compile(JavacCompiler.java:141) at org.apache.maven.plugin.AbstractCompilerMojo.execute(AbstractCompilerMojo.java:493) at org.apache.maven.plugin.CompilerMojo.execute(CompilerMojo.java:114) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:451) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:558) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:499) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:478) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:330) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:291) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:142) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:336) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:129) at org.apache.maven.cli.MavenCli.main(MavenCli.java:287) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) [INFO] [INFO] For more information, run Maven with the -e switch [INFO] [INFO] Total time: 4 minutes 34 seconds [INFO] Finished at: Fri Jan 23 17:25:15 CST 2009 [INFO] Final Memory: 54M/63M [INFO] -- Dennis Byrne
Re: Becoming a contributor
Hi Shawn, You might want to start by putting your patch in the issue tracker http://myfaces.apache.org/issue-tracking.html . If your interested in becoming an open source contributor, http://www.apache.org/foundation/getinvolved.html will put you well on your way. On Thu, May 8, 2008 at 8:51 AM, Bertrand, Shawn R [EMAIL PROTECTED] wrote: Hi all, I have a fix for a Trinidad issue that I'd like to contribute to the project, but I'm not altogether sure of the process necessary to become a contributor. I've read the MyFaces developer noteshttp://wiki.apache.org/myfaces/MyFaces_Developer_Notes, and thought there were some guidelines for contributing to Trinidad but can't seem to find them. Can someone point me in the right direction? Thanks, Shawn Bertrand Tyco Electronics Corporation -- Dennis Byrne
MyFaces/Facelets Book Author
We are currently writing a book called The Definitive Guide to Apache MyFaces Facelets for Apress Publishing. When published it will become the first book focused on designing, developing and deploying applications built on the MyFaces family of projects. * JSF (General Overview) * MyFaces (General Overview) * Tomahawk (Covers major components context of use) * Trinidad * Tobago * Facelets * Orchestra * MyFaces Anti-Patterns We have already received fantastic contributions from the MyFaces community for the above submissions and it has been a very rewarding exercise so far. At this time, we have approximately 280 pages of Technical Review Round 1 material. Our goal is to provide a comprehensive guide to all developers, beginner up, that are interested in leveraging MyFaces-related technologies. We are well on the way to doing that, as the subject matter list above would indicate. Unfortunately, some unforeseen circumstances have resulted in one of our lead authors to back out of the project leaving a place open for an aspiring writer to join into the mix and close this publication out. This is a fantastic opportunity for anyone looking to make a mark on the publishing scene and giving back to a fantastic community and the foundation it belongs to. The potential author will be responsible for closing out the Apache Tomahawk chapter (we have a draft version, but it needs work for it to be of value to a reader) and polish up the introduction chapters for JSF/MyFaces. We are looking for a person who can commit significant time over the coming 4 weeks to close this book out and release for publication. If interested, you can contact me and we can discuss contractual details. We look forward to closing this out and publishing a book worthy of the MyFaces community and the people that contribute to it. Dennis Byrne
Re: myFaces vs MyFaces ... what do you think ?
Capital M, always. On 12/9/07, Catalin Kormos [EMAIL PROTECTED] wrote: I also prefer M, as i always known MyFaces like that, and agreed with Mathias for the naming convention Apache MyFaces, etc instead of Apache myFaces, etc. regards, Catalin On Dec 9, 2007 2:18 PM, Hazem Saleh [EMAIL PROTECTED] wrote: +1 for M :). On Dec 9, 2007 1:34 PM, Matthias Wessendorf [EMAIL PROTECTED] wrote: I'd always call it: Apache MyFaces Tomahawk Apache MyFaces Tobago Apache MyFaces Trinidad Apache MyFaces Blah ... On Dec 9, 2007 3:25 AM, Adonis Raduca [EMAIL PROTECTED] wrote: I think that is important to have a consistent naming strategy for all myFaces (MyFaces) projects. For example I thought to one similar with the Java naming convention for the instance variables. Something like: myFaces tobago tomahawk … I think that once the naming strategy will be in place must be respected everywhere (logos, text stuff, etc.) Adonis On 12/8/07, Matthias Wessendorf [EMAIL PROTECTED] wrote: Eh, I think that is total different beast. We all work here as individuals and it is ok to misspell names... But... starting to misspell the own project, is ... yes, confusing. -M On Dec 8, 2007 8:47 PM, Bruno Aranda [EMAIL PROTECTED] wrote: I am not so sure if it is the same writing the official name of the project (Apache MyFaces) that what we find in the (myFaceS). For instance, most of the time we write in this list Oracle instead of ORACLE (logo). I guess we should just choose which one is more appealing to us, so just vote and let the outcome be our choice :) My 2 cents, Bruno On 08/12/2007, Rahul Akolkar [EMAIL PROTECTED] wrote: On 12/8/07, Matthias Wessendorf [EMAIL PROTECTED] wrote: I too, and I think it is confusing, when we start to write it wrong.. snip/ Indeed, its important to get the name right (case et al), especially in the logo :-) -Rahul -- Matthias Wessendorf further stuff: blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf mail: matzew-at-apache-dot-org -- Matthias Wessendorf further stuff: blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf mail: matzew-at-apache-dot-org -- Hazem Ahmed Saleh Ahmed http://www.jroller.com/page/HazemBlog -- Dennis Byrne
Re: distribution of Sun XSD and DTDs
Thanks for the reply Ryan. I ended up pulling the Apache versions of the documents from the MyFaces and Tomcat svn repo. Dennis Byrne On 11/12/07, rlubke [EMAIL PROTECTED] wrote: As I understand it you must do the following: 1. Include the entire contents of the CDDL header notice [1]. 2. Include the entire contentns of the CDDL license text [2] in full for both source and binary distributions. [1] http://fisheye5.cenqua.com/browse/~raw,r=1.2/javaserverfaces-sources/www/legal/jsf-cddl/jsf-cddl-header.txt [2] https://javaserverfaces.dev.java.net/LICENSE.txt Dennis Byrne-3 wrote: I would like to use a custom EntityResolver in order to prevent apps from going to the Internet each time faces-config.xml or a .tld file is parsed. Doing that means distributing the jar with these four files [1]. I'm not seeking official legal advice, but is this as simple as shipping the binary w/ a copy of the CDDL, and adding the following to the four files? !-- This software in this distribution under the CDDL license. -- Several MyFaces committers (and apparently Shale and Geronimo) went the other route - they rewrote some of these by hand. I googled a bit and couldn't see why the extra work. Can anyone point me to the discussion? Sorry for the cross post. [1] http://fisheye.jboss.org/browse/JSFUnit/trunk/jboss-jsfunit-core/src/main/resources -- Dennis Byrne -- View this message in context: http://www.nabble.com/distribution-of-Sun-XSD-and-DTDs-tf4781017.html#a13715674 Sent from the My Faces - Dev mailing list archive at Nabble.com. -- Dennis Byrne
distribution of Sun XSD and DTDs
I would like to use a custom EntityResolver in order to prevent apps from going to the Internet each time faces-config.xml or a .tld file is parsed. Doing that means distributing the jar with these four files [1]. I'm not seeking official legal advice, but is this as simple as shipping the binary w/ a copy of the CDDL, and adding the following to the four files? !-- This software in this distribution under the CDDL license. -- Several MyFaces committers (and apparently Shale and Geronimo) went the other route - they rewrote some of these by hand. I googled a bit and couldn't see why the extra work. Can anyone point me to the discussion? Sorry for the cross post. [1] http://fisheye.jboss.org/browse/JSFUnit/trunk/jboss-jsfunit-core/src/main/resources -- Dennis Byrne
distribution of Sun XSD and DTDs
I would like to use a custom EntityResolver in order to prevent apps from going to the Internet each time faces-config.xml or a .tld file is parsed. Doing that means distributing the jar with these four files [1]. I'm not seeking official legal advice, but is this as simple as shipping the binary w/ a copy of the CDDL, and adding the following to the four files? !-- This software in this distribution under the CDDL license. -- Several MyFaces committers (and apparently Shale and Geronimo) went the other route - they rewrote some of these by hand. I googled a bit and couldn't see why the extra work. Can anyone point me to the discussion? [1] http://fisheye.jboss.org/browse/JSFUnit/trunk/jboss-jsfunit-core/src/main/resources -- Dennis Byrne
Re: JSF 2
This was on the 1.1 branch. I agree, it would be nice to have in this in JSF 2.0. It's hard to beat Caucho :( Dennis Byrne On 10/26/07, Matthias Wessendorf [EMAIL PROTECTED] wrote: wouldn't it make sense to have that on standard, instead of tomahawk / sandbox? On 10/26/07, Dennis Byrne [EMAIL PROTECTED] wrote: I committed this to Tomahawk a few weeks ago. Dennis Byrne On 10/26/07, Matthias Wessendorf [EMAIL PROTECTED] wrote: Hi, do you guys plan to support converters for the Numbers in package java.util.concurrent.atomic, like AtomicLong or AtomicInteger ? -Matthias -- Matthias Wessendorf further stuff: blog: http://matthiaswessendorf.wordpress.com/ mail: matzew-at-apache-dot-org -- Dennis Byrne -- Matthias Wessendorf further stuff: blog: http://matthiaswessendorf.wordpress.com/ mail: matzew-at-apache-dot-org -- Dennis Byrne
Re: JSF 2
I committed this to Tomahawk a few weeks ago. Dennis Byrne On 10/26/07, Matthias Wessendorf [EMAIL PROTECTED] wrote: Hi, do you guys plan to support converters for the Numbers in package java.util.concurrent.atomic, like AtomicLong or AtomicInteger ? -Matthias -- Matthias Wessendorf further stuff: blog: http://matthiaswessendorf.wordpress.com/ mail: matzew-at-apache-dot-org -- Dennis Byrne
Re: [shared] trivial fix for missing serialVersionUID
I've read through my posts here and I think there might be some
miscommunication.
Dennis Byrne
On 10/24/07, Martin Marinschek [EMAIL PROTECTED] wrote:
Exactly - that's for sure. If it wasn't like that, Eclipse wouldn't
use 1 as a default version id. If it was like Dennis suggested, every
app built with Eclipse would go kaboom.
;)
regards,
Martin
On 10/24/07, Mike Kienenberger [EMAIL PROTECTED] wrote:
Yes, wouldn't that have to be the case? Otherwise, A.jar and B.jar,
created by two independent groups, might use the same version id
without realizing it, and thus break a project depending on both of
them.
On 10/24/07, Martin Marinschek [EMAIL PROTECTED] wrote:
The stream identifier will take into account the FQCN, and the
version-identifier - so the two classes won't have the same stream
identifier, IMHO.
regards,
Martin
On 10/19/07, Dennis Byrne [EMAIL PROTECTED] wrote:
Please consider the consequences of two different classes w/ the
same
stream
identifier.
Dennis Byrne
On 10/19/07, simon [EMAIL PROTECTED] wrote:
Why would that make any difference? The classes are in two
different
packages
On Fri, 2007-10-19 at 14:29 -0500, Dennis Byrne wrote:
(not sure if this issue has been covered yet in this thread)
Because these classes are in shared, they will be split into
two
classes, one for core and one for tomahawk. When they are
split,
you
will have two completely classes in the JVM who have the same
serial
id. I'm not going to say don't do it, but I do think we can
agree
this is not a good idea?
Dennis Byrne
On 10/19/07, Simon Kitching [EMAIL PROTECTED] wrote:
Hi All,
I'd like to make a trivial commit to add
serialVersionUID
values to two classes in shared that don't yet have
them.
This
avoids compile warnings in IDEs that have warn on
missing
serialVersionUID set.
Adding the serialVersionUID is technically the right
thing
to
do, IMO although in practice I agree it isn't terribly
important for these particular classes.
Any objections?
Cheers,
Simon
Index:
/home/sk/projects/apache/myfaces/shared/core/src/main/java/org/apache/myfaces/shared/renderkit/RendererUtils.java
===
---
/home/sk/projects/apache/myfaces/shared/core/src/main/java/org/apache/myfaces/shared/renderkit/RendererUtils.java
(revision 586396)
+++
/home/sk/projects/apache/myfaces/shared/core/src/main/java/org/apache/myfaces/shared/renderkit/RendererUtils.java
(working copy)
@@ -74,6 +74,7 @@
public static final String SELECT_ITEM_LIST_ATTR =
RendererUtils.class.getName () + .LIST;
public static final String EMPTY_STRING = ;
public static final Object NOTHING = new
Serializable()
{
+private static final long serialVersionUID =
-8618356560493578754L;
};
public static final String ACTION_FOR_LIST =
org.apache.myfaces.ActionForList;
Index:
/home/sk/projects/apache/myfaces/shared/core/src/main/java/org/apache/myfaces/shared/util/servlet/SourceCodeServlet.java
===
---
/home/sk/projects/apache/myfaces/shared/core/src/main/java/org/apache/myfaces/shared/util/servlet/SourceCodeServlet.java
(revision
586396)
+++
/home/sk/projects/apache/myfaces/shared/core/src/main/java/org/apache/myfaces/shared/util/servlet/SourceCodeServlet.java
(working
copy)
@@ -25,6 +25,8 @@
public class SourceCodeServlet extends HttpServlet
{
+private static final long serialVersionUID =
-2233965185519715475L;
+
public void doGet(HttpServletRequest req,
HttpServletResponse res)
throws IOException, ServletException
{
--
Dennis Byrne
--
Dennis Byrne
--
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
--
Dennis Byrne
JSF 2.0 is already finished
Caucho claims to have implemented and released JSF 2.0 [1] before the spec was finished! [1] http://www.caucho.com/press/2007-10-07.xtp -- Dennis Byrne
Re: Merging Shale into MyFaces
+1 from me, but only if my logo contest entry is retroactively promoted to the official Shale logo. http://shale.apache.org/logo-contest.html Dennis Byrne On 10/20/07, Kito D. Mann [EMAIL PROTECTED] wrote: Hello everyone, I sent out an e-mail to the Shale mailing list a week or so ago about the possibility of merging Shale with MyFaces. Development of Shale has become somewhat stale, and I'd rather see MyFaces pickup the pieces than have the code base atrophy The overwhelming consensus for the Shale list is yes (and Craig is no exception). What does the MyFaces PMC think? ~~~ Kito D. Mann - Author, JavaServer Faces in Action http://www.virtua.com - JSF/Java EE consulting, training, and mentoring http://www.JSFCentral.com http://www.jsfcentral.com/ - JavaServer Faces FAQ, news, and info -- Dennis Byrne
Re: [shared] trivial fix for missing serialVersionUID
(not sure if this issue has been covered yet in this thread)
Because these classes are in shared, they will be split into two classes,
one for core and one for tomahawk. When they are split, you will have two
completely classes in the JVM who have the same serial id. I'm not going to
say don't do it, but I do think we can agree this is not a good idea?
Dennis Byrne
On 10/19/07, Simon Kitching [EMAIL PROTECTED] wrote:
Hi All,
I'd like to make a trivial commit to add serialVersionUID values to two
classes in shared that don't yet have them. This avoids compile warnings in
IDEs that have warn on missing serialVersionUID set.
Adding the serialVersionUID is technically the right thing to do, IMO
although in practice I agree it isn't terribly important for these
particular classes.
Any objections?
Cheers,
Simon
Index:
/home/sk/projects/apache/myfaces/shared/core/src/main/java/org/apache/myfaces/shared/renderkit/RendererUtils.java
===
---
/home/sk/projects/apache/myfaces/shared/core/src/main/java/org/apache/myfaces/shared/renderkit/RendererUtils.java
(revision 586396)
+++
/home/sk/projects/apache/myfaces/shared/core/src/main/java/org/apache/myfaces/shared/renderkit/RendererUtils.java
(working copy)
@@ -74,6 +74,7 @@
public static final String SELECT_ITEM_LIST_ATTR =
RendererUtils.class.getName() + .LIST;
public static final String EMPTY_STRING = ;
public static final Object NOTHING = new Serializable() {
+private static final long serialVersionUID =
-8618356560493578754L;
};
public static final String ACTION_FOR_LIST =
org.apache.myfaces.ActionForList;
Index:
/home/sk/projects/apache/myfaces/shared/core/src/main/java/org/apache/myfaces/shared/util/servlet/SourceCodeServlet.java
===
---
/home/sk/projects/apache/myfaces/shared/core/src/main/java/org/apache/myfaces/shared/util/servlet/SourceCodeServlet.java
(revision
586396)
+++
/home/sk/projects/apache/myfaces/shared/core/src/main/java/org/apache/myfaces/shared/util/servlet/SourceCodeServlet.java
(working
copy)
@@ -25,6 +25,8 @@
public class SourceCodeServlet extends HttpServlet
{
+private static final long serialVersionUID = -2233965185519715475L;
+
public void doGet(HttpServletRequest req, HttpServletResponse res)
throws IOException, ServletException
{
--
Dennis Byrne
Re: [shared] trivial fix for missing serialVersionUID
Please consider the consequences of two different classes w/ the same stream
identifier.
Dennis Byrne
On 10/19/07, simon [EMAIL PROTECTED] wrote:
Why would that make any difference? The classes are in two different
packages
On Fri, 2007-10-19 at 14:29 -0500, Dennis Byrne wrote:
(not sure if this issue has been covered yet in this thread)
Because these classes are in shared, they will be split into two
classes, one for core and one for tomahawk. When they are split, you
will have two completely classes in the JVM who have the same serial
id. I'm not going to say don't do it, but I do think we can agree
this is not a good idea?
Dennis Byrne
On 10/19/07, Simon Kitching [EMAIL PROTECTED] wrote:
Hi All,
I'd like to make a trivial commit to add serialVersionUID
values to two classes in shared that don't yet have them. This
avoids compile warnings in IDEs that have warn on missing
serialVersionUID set.
Adding the serialVersionUID is technically the right thing to
do, IMO although in practice I agree it isn't terribly
important for these particular classes.
Any objections?
Cheers,
Simon
Index:
/home/sk/projects/apache/myfaces/shared/core/src/main/java/org/apache/myfaces/shared/renderkit/RendererUtils.java
===
---
/home/sk/projects/apache/myfaces/shared/core/src/main/java/org/apache/myfaces/shared/renderkit/RendererUtils.java
(revision 586396)
+++
/home/sk/projects/apache/myfaces/shared/core/src/main/java/org/apache/myfaces/shared/renderkit/RendererUtils.java
(working copy)
@@ -74,6 +74,7 @@
public static final String SELECT_ITEM_LIST_ATTR =
RendererUtils.class.getName () + .LIST;
public static final String EMPTY_STRING = ;
public static final Object NOTHING = new Serializable() {
+private static final long serialVersionUID =
-8618356560493578754L;
};
public static final String ACTION_FOR_LIST =
org.apache.myfaces.ActionForList;
Index:
/home/sk/projects/apache/myfaces/shared/core/src/main/java/org/apache/myfaces/shared/util/servlet/SourceCodeServlet.java
===
---
/home/sk/projects/apache/myfaces/shared/core/src/main/java/org/apache/myfaces/shared/util/servlet/SourceCodeServlet.java
(revision
586396)
+++
/home/sk/projects/apache/myfaces/shared/core/src/main/java/org/apache/myfaces/shared/util/servlet/SourceCodeServlet.java
(working
copy)
@@ -25,6 +25,8 @@
public class SourceCodeServlet extends HttpServlet
{
+private static final long serialVersionUID =
-2233965185519715475L;
+
public void doGet(HttpServletRequest req,
HttpServletResponse res)
throws IOException, ServletException
{
--
Dennis Byrne
--
Dennis Byrne
[jira] Commented: (MYFACES-1747) GuiceResolver
[ https://issues.apache.org/jira/browse/MYFACES-1747?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12535788 ] Dennis Byrne commented on MYFACES-1747: --- created issue per Matze request. GuiceResolver - Key: MYFACES-1747 URL: https://issues.apache.org/jira/browse/MYFACES-1747 Project: MyFaces Core Issue Type: New Feature Components: JSR-252 Affects Versions: 1.2.1-SNAPSHOT Environment: trunk Reporter: Dennis Byrne Assignee: Dennis Byrne Fix For: 1.2.1-SNAPSHOT ... extends ManagedBeanResolver.java -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (MYFACES-1747) GuiceResolver
GuiceResolver - Key: MYFACES-1747 URL: https://issues.apache.org/jira/browse/MYFACES-1747 Project: MyFaces Core Issue Type: New Feature Components: JSR-252 Affects Versions: 1.2.1-SNAPSHOT Environment: trunk Reporter: Dennis Byrne Assignee: Dennis Byrne Fix For: 1.2.1-SNAPSHOT ... extends ManagedBeanResolver.java -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
GuiceFaces
I've thrown together a couple of different ways of getting MyFaces to use Guice (similar to org.springframework.web.jsf.DelegatingVariableResolver ). I would like a place to commit this but some of this code (a custom ELResolver) depends on JSP 2.1 . Taking this code along the sandbox-tomahawk route will obviously interfere w/ the dependencies that are already in those pom files. Thoughts on the following? - create a new project in the 1.2 branch? this might be overkill for something that may end up being 30 lines of code. anyone else been needing this lately? - put this in the 1.2 impl project (this code is standalone, can this interfere w/ users who don't use this class)? - other bright ideas? - give it to Shale even though it is currently tied to the MyFaces impl? -- Dennis Byrne
[jira] Created: (TOMAHAWK-1102) Race Condition in Schedule component
Race Condition in Schedule component Key: TOMAHAWK-1102 URL: https://issues.apache.org/jira/browse/TOMAHAWK-1102 Project: MyFaces Tomahawk Issue Type: Bug Components: Schedule Environment: fresh co as of aug. 31, 2007 Reporter: Dennis Byrne Assignee: Dennis Byrne Fix For: 1.1.7-SNAPSHOT http://java.sun.com/j2se/1.4.2/docs/api/java/text/Format.html : Formats are generally not synchronized. It is recommended to create separate format instances for each thread. If multiple threads access a format concurrently, it must be synchronized externally. ScheduleUtil uses a static instance of SimpleDateFormat. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: 301 almost ready
believe the TCK will be developed in-house at Oracle, but the development of the 301 bridge itself will be done as part of MyFaces community. Hello Scott. Does Oracle have control of the TCK licensing? If so, what are the chances of having anonymous read access to the code, and a license that lets us keep this in the continuous integration loop right next the unit tests. Thanks Thanks, Scott -- Dennis Byrne
Re: [VOTE] MyFaces 1.2.x become trunk
+1 On 7/19/07, Martin Marinschek [EMAIL PROTECTED] wrote: +1, regards, Martin On 7/19/07, Simon Lessard [EMAIL PROTECTED] wrote: [x] +1 for moving the myfaces 1.2.x to trunk On 7/19/07, Bruno Aranda [EMAIL PROTECTED] wrote: +1 On 19/07/07, Mario Ivankovits [EMAIL PROTECTED] wrote: Matthias Wessendorf schrieb: Hi, this is a vote for making the JSF 1.2 efforts by our group to become the current trunk. Currently the JSF 1.2-work lives on a branch (1.2.1-SNAPSHOT is the current version). Please cast your vote [X] +1 for moving the myfaces 1.2.x to trunk [ ] +0 [ ] -1 and why.. -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces -- Dennis Byrne
Re: Assembly MyFaces - Core - JavaDoc
I don't feel Trinidad should have to document IMPL related code just because the core does. I also don't think we should stop documenting core because Trinidad only documents the API based code. Dennis Byrne On 7/14/07, Matthias Wessendorf [EMAIL PROTECTED] wrote: Hi, in Trinidad we only publish the javadoc for API-based classes and not for impl-specific ones. MyFaces core is currently delivering in the assembled stuff both, API and IMPL. What do we want to do ? -- Matthias Wessendorf further stuff: blog: http://matthiaswessendorf.wordpress.com/ mail: matzew-at-apache-dot-org -- Dennis Byrne
Re: MyFaces 1.2.0 - trunk ?
Well, it is 2007 :) Dennis Byrne On 7/14/07, Matthias Wessendorf [EMAIL PROTECTED] wrote: Should we do it now ? -- Matthias Wessendorf further stuff: blog: http://matthiaswessendorf.wordpress.com/ mail: matzew-at-apache-dot-org -- Dennis Byrne
Re: [Vote] Release of Apache MyFaces 1.2.0
+1 On 7/14/07, Matthias Wessendorf [EMAIL PROTECTED] wrote: Hi, I was running the needed tasks to get the 1.2.0 release of Apache MyFaces core out. . The artifacts are deployed to my private Apache account ([1] and [2]). Please take a look at the 1.2.0 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, Matthias [1] http://people.apache.org/~matzew/myfaces120/ [2] http://people.apache.org/~matzew/myfaces120/_dist/ [3] http://www.apache.org/foundation/voting.html#ReleaseVotes -- Matthias Wessendorf further stuff: blog: http://matthiaswessendorf.wordpress.com/ mail: matzew-at-apache-dot-org -- Dennis Byrne
Re: Tomahawk + WorkingWithLargeTables
pageIndexVar=pageIndex
styleClass=scroller
paginator=true
paginatorMaxPages=9
paginatorTableClass=paginator
paginatorActiveColumnStyle=font-weight:bold;
immediate=true
f:facet name=first
t:graphicImage url=images/arrow-
first.gif
border=1/
/f:facet
f:facet name=last
t:graphicImage url=images/arrow-
last.gif
border=1/
/f:facet
f:facet name=previous
t:graphicImage url=images/arrow-
previous.gif
border=1/
/f:facet
f:facet name=next
t:graphicImage url=images/arrow-
next.gif
border=1/
/f:facet
f:facet name=fastforward
t:graphicImage url=images/arrow-
ff.gif
border=1/
/f:facet
f:facet name=fastrewind
t:graphicImage url=images/arrow-
fr.gif
border=1/
/f:facet
/t:dataScroller
t:dataScroller id=scroll_2 for=data
rowsCountVar=rowsCount
displayedRowsCountVar=displayedRowsCountVar
firstRowIndexVar=firstRowIndex
lastRowIndexVar=lastRowIndex
pageCountVar=pageCount
immediate=true
pageIndexVar=pageIndex
h:outputFormat
value=#{example_messages[\'dataScroller_pages\']}
styleClass=standard
f:param value=#{rowsCount}/
f:param
value=#{displayedRowsCountVar}/
f:param value=#{firstRowIndex}/
f:param value=#{lastRowIndex}/
f:param value=#{pageIndex}/
f:param value=#{pageCount}/
/h:outputFormat
/t:dataScroller
/h:panelGrid
/h:panelGroup
t:commandLink value=test immediate=true/
/h:form/body
/html
/f:view
Please help me with this, we are actually deciding which
implementation of myfaces to use, and I really trust in apache work, I don´t
want that other implementation be choose for our applications, thanks!!!
--
Dennis Byrne
Re: Orchestra on code.google.com
Perhaps this has been covered already, but does it have binary deps on MyFaces? Or just the JSF API? If Orchstra has no dep on the MyFaces implementation, you may be able to open this up to more users and you wouldn't have to find a new name - just add it to facesgoodies. Dennis Byrne On 6/26/07, Mario Ivankovits [EMAIL PROTECTED] wrote: Hi! Kito D. Mann schrieb: I don't know -- this might be confusing since Matthias already has FacesGoodies [1] :-). [1] http://code.google.com/p/facesgoodies/ Why not adding it to facesgoodies then? I understand facesgoodies as template for quickstarting an application. I'd opt for the project name myfaces-orchestra-extras if we think nonasf is too non standard. Ciao, Mario -- Dennis Byrne
Re: [vote] release of Trinidad plugins (1.2.1)
+1 On 6/24/07, Bruno Aranda [EMAIL PROTECTED] wrote: +1 On 24/06/07, Matthias Wessendorf [EMAIL PROTECTED] wrote: +1 On 6/24/07, Matthias Wessendorf [EMAIL PROTECTED] wrote: Hi, I was running the needed tasks to get the 1.2.1 release of the Apache MyFaces Trinidad Plugins out. This is the first release of the 1.2.x plugins series. The artifacts are deployed to my private Apache account ([1]). Please take a look at the 1.2.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, Matthias [1] http://people.apache.org/~matzew/121_plugins/ -- Matthias Wessendorf further stuff: blog: http://matthiaswessendorf.wordpress.com/ mail: matzew-at-apache-dot-org -- Matthias Wessendorf further stuff: blog: http://matthiaswessendorf.wordpress.com/ mail: matzew-at-apache-dot-org -- Dennis Byrne
Re: svn commit: r545645 - /myfaces/core/trunk/api/src/main/java/javax/faces/webapp/UIComponentTag.java
I think there is a maven lever for it, no? On 6/10/07, Matthias Wessendorf [EMAIL PROTECTED] wrote: Why is our continuum not catching issues like this ? -M On 6/8/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Author: dennisbyrne Date: Fri Jun 8 14:51:54 2007 New Revision: 545645 URL: http://svn.apache.org/viewvc?view=revrev=545645 Log: Patch from johann renck Modified: myfaces/core/trunk/api/src/main/java/javax/faces/webapp/UIComponentTag.java Modified: myfaces/core/trunk/api/src/main/java/javax/faces/webapp/UIComponentTag.java URL: http://svn.apache.org/viewvc/myfaces/core/trunk/api/src/main/java/javax/faces/webapp/UIComponentTag.java?view=diffrev=545645r1=545644r2=545645 == --- myfaces/core/trunk/api/src/main/java/javax/faces/webapp/UIComponentTag.java (original) +++ myfaces/core/trunk/api/src/main/java/javax/faces/webapp/UIComponentTag.java Fri Jun 8 14:51:54 2007 @@ -1165,7 +1165,7 @@ } intBuf.append(]); -buf.insert(0,intBuf); +buf.insert(0,(Object)intBuf); getPathToComponent(component.getParent(),buf); } -- Matthias Wessendorf further stuff: blog: http://matthiaswessendorf.wordpress.com/ mail: matzew-at-apache-dot-org -- Dennis Byrne
Re: JavaOne 2007 Slides
JSF 1.2 implementation ! On 5/31/07, Paul Spencer [EMAIL PROTECTED] wrote: Nice to put picture with names. What was the Surprise Announcement ? Paul Spencer Manfred Geiler wrote: Hi all, Some requested them, here they are: The slides of our presentation at the last JavaOne about the MyFaces community. The Faces of MyFaces http://people.apache.org/~manolito/javaone07/BOF-7405.ppt Have fun! Manfred -- Dennis Byrne
Re: Continuum - TCK task - feasible ?
Thanks Paul. This would be great. Dennis Byrne On 5/17/07, Paul McMahan [EMAIL PROTECTED] wrote: There has been a lot of progress towards automating TCK runs in the Geronimo project. The automation framework produces very detailed reports and graphs broken down by component, one of those components being JSF. The Geronimo project has a process in place for providing access to ASF committers who have signed the NDA. Now that JSF is part of the Java EE specification and Geronimo (a Java EE server) uses MyFaces for JSF, I think it would make sense to streamline our efforts here. Do others agree? If so then I can follow up with the Geronimo devs to see if there's interest. Best wishes, Paul On May 16, 2007, at 6:40 PM, Grant Smith wrote: Would it be feasible to have a Continuum task that runs the TCK against the current build ? Then we'd know if anything we've done has broken TCK compliance. Is our zone even powerful enough to run the TCK ? I seem to remember it being a huge memory and resource hog. Of course, the other aspect to keep in mind is visibility to NDA signers only, etc. Thoughts ? -- Grant Smith -- Dennis Byrne
Re: Permission to upgrade shale-test v1.1.0-SNAPSHOT to allows for testing against the RI?
I'm 0 on this. The only warning I have is that we have to make sure the next version of Shale test is out before we release the next version of Tomahawk. If you think it is realistic, go for it. Dennis Byrne On 5/17/07, Paul Spencer [EMAIL PROTECTED] wrote: I would like to add more Shale Test based tests to Tomahawk and do it in such a way that allows tests to be run against different JSF implementations, including the RI and MyFaces. In order to do this, the ConfigParser()[1] of shale-test v1.1.0-SNAPSHOT is required. We are already using shale-test v1.0.3. Although I an not keen on adding a SNAPSHOT dependency, this is one that is used only by some of the test cases. The major advantages in using the ConfigParser() is that the implementation's configuration files are used. I created an utility, TestUtils.addDefaultRenderers() [2], that manually add Tomahawks configuration. TestUtils currently works for Tomahawks components, since it manually add the configuration, it has to be maintained in parallel with faces-config.xml. In addition it does not work with other implementation. This utility class would be changed to reference ConfigParser(), not the tests. In short, I am asking for: 1) Permission to upgrade shale-test v1.1.0-SNAPSHOT. 2) Permission to add a continuum build of Tomahawk against the RI Paul Spencer [1]http://shale.apache.org/shale-test/apidocs/org/apache/shale/test/config/ConfigParser.html [2]http://svn.apache.org/viewvc/myfaces/tomahawk/trunk/core/src/test/java/org/apache/myfaces/test/utils/TestUtils.java?view=markup -- Dennis Byrne
Re: MyFaces 2.0.0 (was Re: Tomahawk 1.1.5 release plans?)
+1 for JSF 1.2 . It's more intuitive. Dennis Byrne On 5/17/07, Zubin Wadia [EMAIL PROTECTED] wrote: +1 for 1.2. IMO, Save 2.0 for JSF2.0. It's just easier to explain to non-community members that way and keeps it aligned with the spec releases. Cheers, Zubin. On 5/18/07, Matthias Wessendorf [EMAIL PROTECTED] wrote: So, any interest in making this to 2.0.0 ? -Matthias On 2/23/07, Manfred Geiler [EMAIL PROTECTED] wrote: ... I am +1 for Paul's suggestion: JSF 1.1 - MyFaces 1.x JSF 1.2 - MyFaces 2.x and I am +1 for JSF 2.0 (or JSF6 or whatever) - MyFaces 3.x --Manfred -- Dennis Byrne
Re: MyFaces 2.0.0 (was Re: Tomahawk 1.1.5 release plans?)
Did you mean for that to go to the list ? :) On 5/17/07, Paul Spencer [EMAIL PROTECTED] wrote: I am still +1 for JSF 1.1 - MyFaces 1.x JSF 1.2 - MyFaces 2.x Paul Spencer Matthias Wessendorf wrote: So, any interest in making this to 2.0.0 ? -Matthias On 2/23/07, Manfred Geiler [EMAIL PROTECTED] wrote: ... I am +1 for Paul's suggestion: JSF 1.1 - MyFaces 1.x JSF 1.2 - MyFaces 2.x and I am +1 for JSF 2.0 (or JSF6 or whatever) - MyFaces 3.x --Manfred -- Dennis Byrne
Re: MyFaces 2.0.0 (was Re: Tomahawk 1.1.5 release plans?)
Whoops. It *was* to the list. On 5/17/07, Dennis Byrne [EMAIL PROTECTED] wrote: Did you mean for that to go to the list ? :) On 5/17/07, Paul Spencer [EMAIL PROTECTED] wrote: I am still +1 for JSF 1.1 - MyFaces 1.x JSF 1.2 - MyFaces 2.x Paul Spencer Matthias Wessendorf wrote: So, any interest in making this to 2.0.0 ? -Matthias On 2/23/07, Manfred Geiler [EMAIL PROTECTED] wrote: ... I am +1 for Paul's suggestion: JSF 1.1 - MyFaces 1.x JSF 1.2 - MyFaces 2.x and I am +1 for JSF 2.0 (or JSF6 or whatever) - MyFaces 3.x --Manfred -- Dennis Byrne -- Dennis Byrne
Re: MyFaces PMC += Adam Winer
Therefore last week there was a vote to invite her to the MyFaces Project Management Committee (PMC) and fortunately she did accept. It is Adam, not Eve :) Copy and paste aside, I welcome you Adam. Dennis Byrne Adam, Please subscribe to the [EMAIL PROTECTED] list and update your status on the site. Thanks. -- Matthias Wessendorf http://tinyurl.com/fmywh further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com -- Dennis Byrne
Re: JSF DataTable
Can we please move this conversation to [EMAIL PROTECTED] ? On 5/1/07, Cagatay Civici [EMAIL PROTECTED] wrote: Would'nt a list instead of a hacked datamodel be better? I mean a list is ordered so when you click to move, get the selected index from the datatable and do a swap it in the list by the next or previous one. Also it would be better to use the users list instead of dev list since there's more chance to get replies there. On 5/1/07, Santhosh K S [EMAIL PROTECTED] wrote: Hi All, We have a requirement to move the row up and down based on the user selection. I need to update the DataModel of the tomahawak datatable. How can I achieve this. Any pointers will be appreciated. Thanks, Santhosh -- Dennis Byrne
Re: MyFaces community BOF at J1
I probably won't be able to make the Tuesday deadline but count me in. Good idea Martin, see you there. On 4/28/07, Matthias Wessendorf [EMAIL PROTECTED] wrote: after may 2nd I am able to sent you some data -M On 4/28/07, Manfred Geiler [EMAIL PROTECTED] wrote: Martins idea rocks! The Faces of MyFaces. Great! I'm sure we all will have much fun at this BOF. Well, regarding the photos and statements I think we will use the lazy consensus approach: Everybody has 72 hours to object OR send us a photo and a few words about his/her role in the community and why it is fun to be member of the MyFaces team. If someone is too lazy WE will choose a photo and a story! Be warned: We can be creative. :-) BTW, this is also a good opportunity to doublecheck your data in the team list at http://myfaces.apache.org/team-list.html And please dont forget to tell us your nationality, current residence and age - we believe every number between 14 and 122 and we will not verify it. ;-) Looking forward to meeting many of you at J1. --Manfred On 4/27/07, Martin Marinschek [EMAIL PROTECTED] wrote: Exactly. Well, you can choose a nice photo, or the photo of a person who isn't you ;) regards, Martin On 4/27/07, Grant Smith [EMAIL PROTECTED] wrote: Let me see if I understand this. You want to highlight how little I've contributed this year with a presentation of how ugly I am... On 4/27/07, Martin Marinschek [EMAIL PROTECTED] wrote: Well, that's an exceptionally good title as well! thanks Bruno. regards, Martin On 4/27/07, Bruno Aranda [EMAIL PROTECTED] wrote: Hehe The Faces of MyFaces, focusing the community, the pillar of the project, is a good idea. No problems for me :-) Cheers, Bruno On 27/04/07, Martin Marinschek [EMAIL PROTECTED] wrote: Hi *, we (Manfred and me, but get in contact with us if you are at J1, we'll share the stage!) have been accepted for a MyFaces community BOF at J1, and as the community is the most important asset in this project, we'd like to talk about the community. What I've thought about is to do a session where we show a photo of each of the MyFaces committers, nationality (so that we can show how different we are in region), age, and a funny statement with regards to her/him (either what she/he said or what one can say about her/him), and then what she/he's done for the MyFaces project (so we're introducing MyFaces and what it can do by introducing the MyFaces community). Now I've got three questions for you: - Is that an idea you'd approve of? - Would you be willing to send me photos until Tuesday the latest? - Would you be against being shown on a J1 presentation with your photo, plus a funny remark, which will hopefully be tasteful and not disgraceful ;) regards, Martin -- 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 -- Grant Smith -- 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 -- Matthias Wessendorf http://tinyurl.com/fmywh further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com -- Dennis Byrne
Re: JIRA Permissions
We've had this discussion in the past. I think the outcome was to pair up w/ a committer who would assign the bug to themselves on your behalf. If this doesn't work, perhaps a I'm working on this comment will do. Thanks for your interest Tim. Dennis Byrne On 4/25/07, Mike Kienenberger [EMAIL PROTECTED] wrote: Tim, You should already be able to open new issues. There's no point in giving you the ability to assign yourself to an issue until you have commit access.For now, just attach patches and mark the issue accordingly. On 4/25/07, Tim McConnell [EMAIL PROTECTED] wrote: Hi, I'm helping Paul McMahan work through some of the JSR-252 JIRAs. Could someone update the permissions on my JIRA profile (mcconne) so that I can assign myself existing issues, and to open new issues, for the MyFaces project ?? -- Thanks, Tim McConnell -- Dennis Byrne
Re: PPRPhaseListener
What do you guys think the chances are of moving this into the next Tomahawk release? On 4/24/07, Matthias Wessendorf [EMAIL PROTECTED] wrote: Is there any reason for not making it part of the AJAX api ? The AjaxDecodePhaseListener is also part of the package org.apache.myfaces.custom.ajax.api One more, can we make the package named org.apache.myfaces.ajax.api -- Matthias Wessendorf http://tinyurl.com/fmywh further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com -- Dennis Byrne
Re: [continuum] BUILD FAILURE: Myfaces Nightly Build Script
Please advise Downloading: http://people.apache.org/repo/m2-snapshot-repository/org/apache/myfaces/tomahawk/tomahawk-sandbox15-examples/1.1.6-SNAPSHOT/tomahawk-sandbox15-examples-1.1.6-SNAPSHOT-sources.jar [WARNING] Unable to get resource ' org.apache.myfaces.tomahawk:tomahawk-sandbox15-examples:jar:sources:1.1.6-SNAPSHOT' from repository apache.snapshots ( http://people.apache.org/repo/m2-snapshot-repository) [INFO] [ERROR] BUILD ERROR Dennis Byrne
Re: Use 1.2 as current
+1 for making the 1.2 tag the main show. I'm pretty confident that merging is no longer an option. The code bases have been separate for more than six months and they are very different. Plenty commits from several of us have touched 30 or 40 files at a time. Dennis Byrne On 4/18/07, Martin Marinschek [EMAIL PROTECTED] wrote: Hi *, this is a formal vote on using the 1.2 branch as current now. Steps in doing this: - branch the current head as 1.1.5_1 - merge down the 1.2 branch to current head (that will be a lot of work, I'll tackle it) my +1 for doing this right now. regards, Martin -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces -- Dennis Byrne
Re: svn commit: r530154 - /myfaces/core/branches/jsf12/impl/src/main/java/org/apache/myfaces/el/unified/resolver/ManagedBeanResolver.java
I don't think anyone has run the cactus tests in about six months. They
aren't a part of the CI loop either.
Dennis Byrne
On 4/18/07, Paul McMahan [EMAIL PROTECTED] wrote:
Just wanted to invite some peer review for this change I just
committed for MYFACES-1588. The problem was that managed beans in
scope none weren't accessible via the resolver. The change I made
passes the test cases but there might be a more elegant way to
implement it.
Also, I have an update for the ValueBindingImplCactus.java test case
to check for this bug (looked like a good place for it) but I
couldn't figure out how to run cactus from maven. Does that work OK
and if so can anyone provide tips on how to execute?
Best wishes,
Paul
On Apr 18, 2007, at 4:53 PM, [EMAIL PROTECTED] wrote:
Author: pmcmahan
Date: Wed Apr 18 13:53:26 2007
New Revision: 530154
URL: http://svn.apache.org/viewvc?view=revrev=530154
Log:
MYFACES-1588 resolve managed beans in scope none
Modified:
myfaces/core/branches/jsf12/impl/src/main/java/org/apache/
myfaces/el/unified/resolver/ManagedBeanResolver.java
Modified: myfaces/core/branches/jsf12/impl/src/main/java/org/apache/
myfaces/el/unified/resolver/ManagedBeanResolver.java
URL: http://svn.apache.org/viewvc/myfaces/core/branches/jsf12/impl/
src/main/java/org/apache/myfaces/el/unified/resolver/
ManagedBeanResolver.java?view=diffrev=530154r1=530153r2=530154
==
--- myfaces/core/branches/jsf12/impl/src/main/java/org/apache/
myfaces/el/unified/resolver/ManagedBeanResolver.java (original)
+++ myfaces/core/branches/jsf12/impl/src/main/java/org/apache/
myfaces/el/unified/resolver/ManagedBeanResolver.java Wed Apr 18
13:53:26 2007
@@ -74,15 +74,6 @@
extContext.getApplicationMap().put(name, obj);
}
});
-s_standardScopes.put(
-none,
-new Scope()
-{
-public void put(ExternalContext extContext, String
name, Object obj)
-{
-// do nothing
-}
-});
}
/**
@@ -156,8 +147,13 @@
ManagedBean managedBean = runtimeConfig
(context).getManagedBean(strProperty);
if (managedBean != null) {
-storeManagedBean(managedBean, facesContext(context));
+FacesContext facesContext = facesContext(context);
context.setPropertyResolved(true);
+if (none.equals(managedBean.getManagedBeanScope())) {
+return beanBuilder.buildManagedBean(facesContext,
managedBean);
+} else {
+storeManagedBean(managedBean, facesContext);
+}
}
return null;
--
Dennis Byrne
svn externals
I think I've asked Sean this before but I can't remember his response. What was the verdict on why we don't use svn externals very much? Didn't this have something to do with losing history? -- Dennis Byrne
Call for Papers Opens for ApacheCon US 2007
Call for Papers Opens for ApacheCon US 2007 The Call for Papers is now open for ApacheCon US, to be held November 12-16 at the Peachtree Westin, Atlanta. The conference will consist of two day of tutorials (November 12-13) and three days of regular conference sessions (November 14-16). Please log in to the website at http://apachecon.com/html/login.html to submit your proposal. Further details about fees and are avaialable on the CFP form. Topics appropriate for submission to this conference are manifold, and may include but are not restricted to: * ASF projects * ASF-Incubated projects * Scripting languages and dynamic content such as Java, Perl, Python, Ruby, XSL, and PHP * New technologies and broader initiatives such as Web Services and Web 2.0 * Security and e-commerce, performance tuning, load balancing, and high availability * Business and community issues surrounding the ASF and Open Source The paper submission deadline is Monday, 28 April 2007, Midnight GMT. Thanks, and we hope to hear from you, and to see you in Atlanta. -- The ApacheCon Planners [EMAIL PROTECTED]
Re: [Vote] accepting Trinidad as a subproject
+1 On 4/15/07, Matthias Wessendorf [EMAIL PROTECTED] wrote: +1 for accepting Trinidad as a MyFaces subproject On 4/15/07, Matthias Wessendorf [EMAIL PROTECTED] wrote: Hi, the Trinidad community has voted to graduate and being a subproject of the Apache MyFaces project ([1]). Now it's up to the MyFaces PMC to accept Trinidad as a subproject. Please cast your votes. -Matthias [1] http://mail-archive.com/adffaces-dev%40incubator.apache.org/msg02417.html -- Matthias Wessendorf http://tinyurl.com/fmywh further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com -- Matthias Wessendorf http://tinyurl.com/fmywh further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com -- Dennis Byrne
[WELCOME] Paul McMahan
The MyFaces PMC is proud to welcome another member to the team. Paul's activities on the mailing list and the issue tracker have been recognized. He has accepted an invitation to become the next member of MyFaces. Welcome Paul! Dennis Byrne
StartupServletContextListener.setFacesInitializer
Having a little trouble determining when and how this method is invoked. Any ideas? Thanks, -- Dennis Byrne
Re: StartupServletContextListener.setFacesInitializer
I'm having a hard time seeing where it's invoked. Can you please help? http://svn.apache.org/viewvc/myfaces/core/tags/1_1_5/impl/src/main/java/org/apache/myfaces/webapp/MyFacesServlet.java?revision=509198view=markup Dennis Byrne On 4/6/07, Mike Kienenberger [EMAIL PROTECTED] wrote: org.apache.myfaces.webapp - myfaces-impl-1.1.5.jar MyFacesServlet init(ServletConfig) StartupServletContextListener contextInitialized(ServletContextEvent) On 4/6/07, Dennis Byrne [EMAIL PROTECTED] wrote: Having a little trouble determining when and how this method is invoked. Any ideas? Thanks, -- Dennis Byrne -- Dennis Byrne
Re: [VOTE] MyFaces Tomahawk 1.1.5
+1 On 3/30/07, Manfred Geiler [EMAIL PROTECTED] wrote: Hi all, This is the official vote for MyFaces Tomahawk 1.1.5. (aka The Tomahawk Easter Release 2007 - can you find the egg?) Please note that this vote concerns all of the following parts: 1. Maven artifact group org.apache.myfaces.tomahawk v1.1.5 [1] 2. MyFaces Tomahawk Assembly [2] 3. MyFaces Tomahawk Examples Assembly [2] 4. MyFaces Tomahawk Sandbox Assembly [2] 5. MyFaces Tomahawk Sandbox Examples Assembly [2] 6. Proposed Release Announcement [3] Please note: This vote is majority approval with a minimum of three +1 votes (see [4]). I know this release is overdue but please do only cast a +1 if you really have tested the artifacts and assemblies and not only because you have waited so long... ;-) Please cast your votes: [ ] +1 (I confirm that I tested this release and therefore approve it) [ ] +0 (I have no time to test now but I look forward to this new release) [ ] -1 (Serious concerns because...) --Manfred [1] http://people.apache.org/builds/myfaces/m2-staging-repository/ [2] http://people.apache.org/builds/myfaces/tomahawk-1.1.5/ [3] http://wiki.apache.org/myfaces/TomahawkRelease115#releasenotes [4] http://www.apache.org/foundation/voting.html#ReleaseVotes -- Dennis Byrne
Re: http://www.irian.at/myfaces/swapimage.jsf
TOMAHAWK-943 On 3/28/07, Matthias Wessendorf [EMAIL PROTECTED] wrote: same here On 3/28/07, Jeff Bischoff [EMAIL PROTECTED] wrote: Looks broken to me, Dennis. It is supposed to be a mouseover, but not working in anything I've tested (firefox or IE7). Dennis Byrne wrote: This page doesn't do much. Am I missing something or is the example broken? -- Matthias Wessendorf http://tinyurl.com/fmywh further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com -- Dennis Byrne
Re: ExcelExport
Marco,
Thanks for playing a part in the community. Please open an issue in the
issue tracker
http://issues.apache.org/jira/secure/BrowseProject.jspa?id=10600 , along
with your patch.
Dennis Byrne
On 3/27/07, Marco Pöhler [EMAIL PROTECTED] wrote:
Hi,
I have two minor changes made to the Excelexport to make it work with
facelets (or more exacly to work with other suffixes as .jsf) and to
avoid hints in new Excel-Versions if you have Numbers in Text-Cells.
This is my first try to contribute, I hope everything is okay. Don't
hesitate to correct me.
best regards
Marco
Index:
/myfaces-current/tomahawk/sandbox/core/src/main/java/org/apache/myfaces/custom/excelexport/ExcelExportRenderer.java
===
---
/myfaces-current/tomahawk/sandbox/core/src/main/java/org/apache/myfaces/custom/excelexport/ExcelExportRenderer.java
(revision 522807)
+++
/myfaces-current/tomahawk/sandbox/core/src/main/java/org/apache/myfaces/custom/excelexport/ExcelExportRenderer.java
(working copy)
@@ -67,8 +67,10 @@
private String getJSCall(FacesContext facesContext, String tableId) {
String viewId = StringUtils.split(
facesContext.getViewRoot().getViewId() , \\.)[0];
-String contextPath =
facesContext.getExternalContext().getRequestContextPath();
-return window.open(' + contextPath + viewId +
.jsf?excelExportTableId= + tableId + ');return false;;
+return window.open('
++
facesContext.getApplication().getViewHandler().getActionURL(
+facesContext, viewId) + ?excelExportTableId=
++ tableId + ');return false;;
}
Index:
/myfaces-current/tomahawk/sandbox/core/src/main/java/org/apache/myfaces/custom/excelexport/ExcelExportPhaseListener.java
===
---
/myfaces-current/tomahawk/sandbox/core/src/main/java/org/apache/myfaces/custom/excelexport/ExcelExportPhaseListener.java
(revision 522807)
+++
/myfaces-current/tomahawk/sandbox/core/src/main/java/org/apache/myfaces/custom/excelexport/ExcelExportPhaseListener.java
(working copy)
@@ -117,6 +117,18 @@
cell.setEncoding(HSSFCell.ENCODING_UTF_16);
if(component instanceof ValueHolder) {
String stringValue =
RendererUtils.getStringValue(FacesContext.getCurrentInstance(),
component);
+// try some parsings
+try {
+cell.setCellValue(Double.parseDouble(stringValue));
+return;
+} catch (NumberFormatException nfe) {
+}
+try {
+cell.setCellNum(Short.parseShort(stringValue));
+return;
+} catch (NumberFormatException nfe) {
+}
+// default to string value
cell.setCellValue(stringValue);
}
}
--
Dennis Byrne
[jira] Commented: (MYFACES-1561) Validators, Converters are not recognized
[
https://issues.apache.org/jira/browse/MYFACES-1561?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12484648
]
Dennis Byrne commented on MYFACES-1561:
---
Hi Christoph,
I appreciate your interest here but can you please look at the patch files? It
looks like a formatter was run on them and not much else. The
UIComponentClassicTagBase patch does have one null check in it. Please advise
Validators, Converters are not recognized
-
Key: MYFACES-1561
URL: https://issues.apache.org/jira/browse/MYFACES-1561
Project: MyFaces Core
Issue Type: Bug
Components: JSR-252
Affects Versions: 1.2.0-SNAPSHOT
Environment: Tomcat 6.0.10
Reporter: Cagatay Civici
Assigned To: Christoph Ebner
Attachments: ConverterTag.java, ConverterTag.patch,
UIComponentClassicTagBase.java, UIComponentClassicTagBase.patch
For a component like;
h:inputText id=date value=#{person.birth}
f:validateLength minimum=10 /
f:convertDateTime dateStyle=full /
/h:inputText
Both validators and converters specified for the input text are ignored.
UIInput getValidators.length returns 0 and getConverter is always null.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: [Announce] Release of Apache Trinidad Podling's 1.0.0-incubating
Hi Matthias, Not job incubators! Please make sure to announce this on http://www.theserverside.com/ . Dennis Byrne On 3/26/07, Scheper, Erik-Berndt [EMAIL PROTECTED] wrote: Hi, Congratulations on the first incubating release! However, I am sorry to find that the source jars are missing for both the examples and binaries. I know these can be retrieved from svn (URL?), but is it possible to add them in upcoming releases? Many thanks and regards, Erik-Berndt -Oorspronkelijk bericht- Van: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Namens Matthias Wessendorf Verzonden: zondag 25 maart 2007 17:06 Aan: MyFaces Development; MyFaces Discussion Onderwerp: [Announce] Release of Apache Trinidad Podling's 1.0.0-incubating The Apache Trinidad Podling is pleased to announce the release of Trinidad Core 1.0.0-incubating. Apache Trinidad is a JavaServer(tm) Faces 1.1 component library. Apache Trinidad Core 1.0.0-incubating is available in both binary and source distributions: * http://incubator.apache.org/adffaces/download.html Apache Trinidad is also available in the incubator Maven repository under Group ID org.apache.myfaces.trinidad. (http://people.apache.org/repo/m2-incubating-repository/) Release Notes: http://wiki.apache.org/myfaces/ADF_Faces/core_release_1_0_0-incubating Enjoy! -- Matthias Wessendorf http://tinyurl.com/fmywh further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com Disclaimer: This message contains information that may be privileged or confidential and is the property of Sogeti Nederland B.V. or its Group members. It is intended only for the person to whom it is addressed. If you are not the intended recipient, you are not authorized to read, print, retain, copy, disseminate, distribute, or use this message or any part thereof. If you receive this message in error, please notify the sender immediately and delete all copies of this message. -- Dennis Byrne
[jira] Commented: (MYFACES-1561) Validators, Converters are not recognized
[
https://issues.apache.org/jira/browse/MYFACES-1561?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12484271
]
Dennis Byrne commented on MYFACES-1561:
---
Christoph, are the two attached files fixes? If so, please do us a favor and
submit this in subversion patch form.
Thanks.
Validators, Converters are not recognized
-
Key: MYFACES-1561
URL: https://issues.apache.org/jira/browse/MYFACES-1561
Project: MyFaces Core
Issue Type: Bug
Components: JSR-252
Affects Versions: 1.2.0-SNAPSHOT
Environment: Tomcat 6.0.10
Reporter: Cagatay Civici
Assigned To: Christoph Ebner
Attachments: ConverterTag.java, UIComponentClassicTagBase.java
For a component like;
h:inputText id=date value=#{person.birth}
f:validateLength minimum=10 /
f:convertDateTime dateStyle=full /
/h:inputText
Both validators and converters specified for the input text are ignored.
UIInput getValidators.length returns 0 and getConverter is always null.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
http://www.irian.at/myfaces/swapimage.jsf
This page doesn't do much. Am I missing something or is the example broken? -- Dennis Byrne
Re: [continuum] BUILD FAILURE: API
Can anyone help with this? It looks like velocity errors are being generated from a checkstyle report. Dennis Byrne [WARNING] Error loading report org.apache.maven.changelog.ChangeLogReport - AbstractMethodError: canGenerateReport() [WARNING] Error loading report org.apache.maven.changelog.DeveloperActivityReport - AbstractMethodError: canGenerateReport() [WARNING] Error loading report org.apache.maven.changelog.FileActivityReport- AbstractMethodError: canGenerateReport() [WARNING] Error loading report org.apache.maven.plugin.jxr.JxrReport - AbstractMethodError: canGenerateReport() [WARNING] Error loading report org.codehaus.mojo.surefire.SurefireReportMojo- AbstractMethodError: canGenerateReport() [WARNING] Unable to load parent project from repository: Could not find the model file '/local/continuum-1.0.3-SNAPSHOT /apps/continuum/working-directory/8/../pom.xml'. [INFO] artifact org.apache.maven.skins:maven-default-skin: checking for updates from central [INFO] Skipped About report, file index.html already exists for the English version. [ERROR] VM #displayTree: error : too few arguments to macro. Wanted 2 got 0 [ERROR] VM #menuItem: error : too few arguments to macro. Wanted 1 got 0 [INFO] Generate Checkstyle report. [INFO] [ERROR] BUILD ERROR
Re: [continuum] BUILD FAILURE: API
Has the password changed or does the user just no longer exist? Maybe I can kill the dir - which machine is this on? Dennis Byrne On 3/24/07, Wendy Smoak [EMAIL PROTECTED] wrote: On 3/24/07, Wendy Smoak [EMAIL PROTECTED] wrote: I vote we move it over to the (newer) Continuum instance on port 8081 and see if it works there. It was already there, and building fine. I changed the build definition to deploy, etc. http://myfaces.zones.apache.org:8081/continuum/projectGroupSummary.action?projectGroupId=6 However, I can't seem to log into the old Continuum on port 8080 to delete the core/api/impl projects. Can someone else try it? Or we can just see what else needs to be moved over and turn that one off. -- Wendy -- Dennis Byrne
Re: [continuum] BUILD FAILURE: API
I don't know either, but thanks. Dennis Byrne On 3/24/07, Wendy Smoak [EMAIL PROTECTED] wrote: On 3/24/07, Dennis Byrne [EMAIL PROTECTED] wrote: Has the password changed or does the user just no longer exist? Maybe I can kill the dir - which machine is this on? It was just me forgetting the password. I removed core/api/impl from the old continuum on port 8080, but I still don't know why it just started complaining about a checkstyle config file. -- Wendy -- Dennis Byrne
Re: Hello
The source used 1.4? Which part? The binaries should remain 1.3. Dennis Byrne On 3/20/07, Zdeněk Sochor [EMAIL PROTECTED] wrote: Dennis Byrne napsal(a): Don't forget that MyFaces projects use Maven2 for building and Myfaces 1.1 must be compiled under J2SE 1.4. JSF 1.1 requires 1.3 compatibility. Cheers, Dennis Byrne Dennis, J2SE 1.3 ended it's life cycle (except on Solaris), but anyway: Maven2 depends on 1.4 and part of MyFaces code uses 1.4 features. Regards, Zdenek -- Dennis Byrne
Re: [continuum] BUILD ERROR: Tobago Gendoc
Does anyone know why this keeps repeating? On 3/19/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Online report : http://myfaces.zones.apache.org:8080/continuum/servlet/continuum/target/ProjectBuild.vm/view/ProjectBuild/id/203/buildId/9596 Build statistics: State: Error Previous State: Error Started at: Mon, 19 Mar 2007 23:06:24 + Finished at: Mon, 19 Mar 2007 23:06:26 + Total time: 1s Build Trigger: Schedule Exit code: 0 Building machine hostname: myfaces.zones.apache.org Operating system : SunOS(unknown) Java version : 1.5.0_10(Sun Microsystems Inc.) Changes No files changed Build Error: Provider message: The svn command failed. Command output: --- svn: REPORT request failed on '/repos/asf/!svn/vcc/default' svn: Target path does not exist --- -- Dennis Byrne
Re: Servlet API thread safety ... was [jira] MYFACES-1558
David has found a few interesting things about the FactoryFinder implementation. I think we can all agree that the memory leak can be fixed, I have mixed feelings about the use of synchronization here. The code is invoked from many places in the app and I am mostly concerned about performance. If FactoryFinder.setFactory() is only invoked from the context startup listener, or the servlet's init method, do we need synchronization? Dennis Byrne On 3/13/07, David Jencks (JIRA) dev@myfaces.apache.org wrote: [ https://issues.apache.org/jira/browse/MYFACES-1558?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel] David Jencks updated MYFACES-1558: -- Attachment: MYFACES-1558-jsf11.patch Here's a patch for the jsf11 branch. I believe its the same as the patch for jsf 1.2 branch with generics removed, but I spent less time on it than the first one. The entire jsf11 project builds fine with this. FactoryFinder not thread safe, and has a memory leak Key: MYFACES-1558 URL: https://issues.apache.org/jira/browse/MYFACES-1558 Project: MyFaces Core Issue Type: Bug Components: General Affects Versions: 1.2.0-SNAPSHOT Reporter: David Jencks Assigned To: Dennis Byrne Attachments: MYFACES-1558-jsf11.patch, MYFACES-1558.patch FactoryFinder has insufficient synchronization to be thread safe, and has a memory leak in _registeredFactoryNames. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. -- Dennis Byrne
[jira] Commented: (MYFACES-1558) FactoryFinder not thread safe, and has a memory leak
[ https://issues.apache.org/jira/browse/MYFACES-1558?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12479972 ] Dennis Byrne commented on MYFACES-1558: --- we can use generics - we can not use generics FactoryFinder not thread safe, and has a memory leak Key: MYFACES-1558 URL: https://issues.apache.org/jira/browse/MYFACES-1558 Project: MyFaces Core Issue Type: Bug Components: General Affects Versions: 1.2.0-SNAPSHOT Reporter: David Jencks Assigned To: Dennis Byrne Attachments: MYFACES-1558.patch FactoryFinder has insufficient synchronization to be thread safe, and has a memory leak in _registeredFactoryNames. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (MYFACES-1558) FactoryFinder not thread safe, and has a memory leak
[ https://issues.apache.org/jira/browse/MYFACES-1558?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12479976 ] Dennis Byrne commented on MYFACES-1558: --- OK, if you are working w/ myfaces/current12 then you are fine, it's the JSF 1.2 branch. I can't look at this tonight but it'll happen soon. If you have time, a non-generics version of the patch (for myfaces/current, the JSF 1.1 maintenance mode branch) would be appreciated. Thanks FactoryFinder not thread safe, and has a memory leak Key: MYFACES-1558 URL: https://issues.apache.org/jira/browse/MYFACES-1558 Project: MyFaces Core Issue Type: Bug Components: General Affects Versions: 1.2.0-SNAPSHOT Reporter: David Jencks Assigned To: Dennis Byrne Attachments: MYFACES-1558.patch FactoryFinder has insufficient synchronization to be thread safe, and has a memory leak in _registeredFactoryNames. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [VOTE] Release Tobago 1.0.10
+1 On 3/8/07, Bernd Bohmann [EMAIL PROTECTED] wrote: Hello, I would like to release Tobago 1.0.10, This release contains over 80 changes. For a detail list please consult the release notes: http://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310273styleName=Htmlversion=12312204 The version is available at the staging location and the revision number of the release is 515806 and tagged as tobago-1.0.10. Staging distribution: http://people.apache.org/~bommel Staging repository: http://people.apache.org/~bommel/repo The Vote is open for 72h. [ ] +1 [ ] +0 [ ] -1 Regards Bernd -- Dennis Byrne
http://www.keelframework.org/
Anyone here of this firm? http://www.keelframework.org/release/HEAD/javadoc/org/keel/faces/component/UIViewRoot.html Looks like they've got webwork2, avalon, hibernate, etc. in there as well. -- Dennis Byrne
Tests failures in 1.2 branch
I realize Continuum is coming up w/ a lot of false positives right now but it appears as though we have some actual test failures in the 1.2 branch. Can anyone do a full update and a build right now and let me know if HtmlTextRenderTest is failing? -- Dennis Byrne
Re: @PreDestroy, Servlet API,
On 3/3/07, Bernd Bohmann [EMAIL PROTECTED] wrote:
Hello Dennis,
why we should look at the RI?
I'd prefer doing things that is compatible with them. This is easier on the
users and it makes passing TCK smoother.
Can we use this Interface
http://tomcat.apache.org/tomcat-6.0-doc/api/org/apache/AnnotationProcessor.html
?
I'd prefer something that would work on other Servlet containers. I am open
to ideas.
Why you don't like to import javax.annotation. in the code. If the
annotation are missing in the container the annotations in the managed
bean would be meaningless. But maybe the annotation are required by the
servlet spec.
I didn't do this for users who were using @PostConstruct in their managed
beans, I did this to avoid ClassDefNotFoundErrors for users who *didn't* use
@PostConstruct. However Paul has already pointed out in this thread that
this is not realistic, since Servlet 2.5 requires these annotations.
Why you create a own class for each Listener?
Regards
Bernd
Dennis Byrne wrote:
As much as I agree w/ you about how better things would be if this were
in
the spec, and as much as I hate to bow down here, I am actually OK
with
using com.sun.faces.spi.InjectionProvider as the parameter in MyFaces as
well ... for the sake of users. If anyone has a problem w/ it, we can
go
with org.apache.myfaces.InjectionProvider.
Dennis Byrne
On 3/2/07, Mathias Brökelmann [EMAIL PROTECTED] wrote:
The RI looks for com.sun.faces.spi.InjectionProvider for a class
name which implements this interface. It would have been very nice if
this is part of the spec. But that is not the case so we need to find
a way to support any kind of j2ee container. IMO injecting j2ee
resources without knowing where these resources can be found is not
possible. Therefore myfaces should call an InjectionProvider which
simply do this job.
2007/3/3, Dennis Byrne [EMAIL PROTECTED]:
Are any of these class names or context params start w/
javax.faces? If
so, we can move the conversation back into the issue tracker and I'll
close
the @PostConstruct issue once Paul says it's good to go. I don't see
the
point of the system property though.
Dennis Byrne
On 3/2/07, Mathias Brökelmann [EMAIL PROTECTED] wrote:
The RI uses two ways to lookup the implementation of the vendor
specific implementation of the InjectionProvider. They first try to
use a web context init param and if that is not configured they
simply
use a system property. Both keyed by the class name of the
InjectionProvider interface.
2007/3/2, Paul McMahan [EMAIL PROTECTED]:
I think Mathias' suggestion is right on. I haven't looked at
the RI
code but I read somewhere that it passes the name of
InjectionProviders via entries in META-INF/services. If MyFaces
used
a similar approach I think it should work OK for Geronimo and
just
about any other container that supports injection, And it should
also
make MyFaces more interchangeable with the RI.
Best wishes,
Paul
On 3/2/07, Dennis Byrne [EMAIL PROTECTED] wrote:
Similar to what Mathias mentioned?
http://issues.apache.org/jira/browse/MYFACES-1246#action_12475337
It's not much work (on our side) but it sounds pretty vendor
specific.
Again, I don't have a better solution. Mathias writes which
is
implemented
by j2ee containers. I wonder if each container will end up
looking
for
different interfaces. How would MyFaces find Geronimo's
implementation ? A
context parameter? A for loop like this ...
String[] providers = new String[]{org,
apache.geronimo.DIProvider
,
com.bea.DIProvider, org.jboss.DIProvider }
for(String clazz : providers){
try{
return ClassUtils.load (clazz)
}catch(){}
}
Dennis Byrne
On 3/1/07, Paul McMahan [EMAIL PROTECTED] wrote:
OK, I think your interpretation of the spec makes sense and
there's
one particular aspect we should discuss a little further.
The container doesn't know which classes are managed beans
so it
wouldn't know when to intercept the instantiation process to
perform
injection. What would you all think about MyFaces providing
an
interface that containers could implement to perform
injection
on a
managed bean when MyFaces brings that bean into
service? This
would
allow MyFaces to maintain control of the timing while
allowing
the
container to scan for annotations and handle injection when
prompted
to do so.
Best wishes,
Paul
On 2/26/07, Dennis Byrne [EMAIL PROTECTED] wrote:
I know the specs can be vague sometimes, but I don't
interpret
the
first
paragraph of section 5.4 as meaning the JSF implementation
is
responsible
for @EJB, @Resources, etc. The JSF spec specifically
mentions
Re: @PreDestroy, Servlet API,
I added a comment
http://blogs.sun.com/rlubke/entry/jsf_ri_1_2_and#comment-1172947192023 .
Two more ideas. Ryan mentions applications using facelets, jsf 1.2 and
servlet 2.4. Unless I'm missing something, there's one reason to use
annotation.getName().equals(javax.annotation.PostConstruct) rather than
annotation.class == PostConstruct.class. Also, the tomcat guys are
processing annotations even when the method is marked private.
Dennis Byrne
On 3/3/07, Paul McMahan [EMAIL PROTECTED] wrote:
OK, I think the RI also recently added the META-INF/services
technique. But I don't know how reliable this sun blog entry is:
http://tinyurl.com/yrrjs2
Best wishes,
Paul
On 3/2/07, Mathias Brökelmann [EMAIL PROTECTED] wrote:
The RI uses two ways to lookup the implementation of the vendor
specific implementation of the InjectionProvider. They first try to
use a web context init param and if that is not configured they simply
use a system property. Both keyed by the class name of the
InjectionProvider interface.
2007/3/2, Paul McMahan [EMAIL PROTECTED]:
I think Mathias' suggestion is right on. I haven't looked at the RI
code but I read somewhere that it passes the name of
InjectionProviders via entries in META-INF/services. If MyFaces used
a similar approach I think it should work OK for Geronimo and just
about any other container that supports injection, And it should also
make MyFaces more interchangeable with the RI.
Best wishes,
Paul
On 3/2/07, Dennis Byrne [EMAIL PROTECTED] wrote:
Similar to what Mathias mentioned?
http://issues.apache.org/jira/browse/MYFACES-1246#action_12475337
It's not much work (on our side) but it sounds pretty vendor
specific.
Again, I don't have a better solution. Mathias writes which is
implemented
by j2ee containers. I wonder if each container will end up looking
for
different interfaces. How would MyFaces find Geronimo's
implementation ? A
context parameter? A for loop like this ...
String[] providers = new String[]{org,apache.geronimo.DIProvider,
com.bea.DIProvider, org.jboss.DIProvider}
for(String clazz : providers){
try{
return ClassUtils.load (clazz)
}catch(){}
}
Dennis Byrne
On 3/1/07, Paul McMahan [EMAIL PROTECTED] wrote:
OK, I think your interpretation of the spec makes sense and
there's
one particular aspect we should discuss a little further.
The container doesn't know which classes are managed beans so it
wouldn't know when to intercept the instantiation process to
perform
injection. What would you all think about MyFaces providing an
interface that containers could implement to perform injection on
a
managed bean when MyFaces brings that bean into service? This
would
allow MyFaces to maintain control of the timing while allowing the
container to scan for annotations and handle injection when
prompted
to do so.
Best wishes,
Paul
On 2/26/07, Dennis Byrne [EMAIL PROTECTED] wrote:
I know the specs can be vague sometimes, but I don't interpret
the first
paragraph of section 5.4 as meaning the JSF implementation is
responsible
for @EJB, @Resources, etc. The JSF spec specifically mentions
the
container to inject references. If Geronimo can intercept the
instantiation of these classes in the classloader (something I
know
nothing
about right now), I think we are all good here. Wouldn't
MyFaces then
be
observing the requirements (in plain java) around @PostConstruct
after
Geronimo had injected the resources?
I think the JSF impl is only responsible for @PostConstruct and
@Predestroy.
This makes sense because scoped (request, session, application)
are the
only candidates for this, and it would be more awkward to do
that from
the
container. I say all of this in an open manner, so anyone feel
free to
discuss.
You're point about javax.annotation being in the Servlet 2.5 is
taken.
I
totally missed that.
Dennis Byrne
On 2/26/07, Paul McMahan [EMAIL PROTECTED] wrote:
Actually by dependency injection I'm specifically referring
to the
portion of the JSF spec that discusses injecting resources
where
certain annotations are found in a managed bean. So, while
scanning
for the @PreConstruct and @PostDestroy annotations MyFaces
would also
scan for @EJB, @Resource, @WebServiceRef, etc and then time
the
invocation of @PreConstruct and @PostDestroy to support the
injection.
Tomcat provides an example of how this can be done. The
following
class scans for annotations when a web app starts:
http://svn.apache.org/repos/asf/tomcat/tc6.0.x/trunk/java/org/apache/catalina/startup/WebAnnotationSet.java
And then this class handles the injection and calling the
PostConstruct and PreDestroy methods when
Re: @PreDestroy, Servlet API,
Are you under the impression that our 1.2 branch didn't already handle
@PostConstruct and @PreDestroy? Looks like the left hand doesn't know what
the right hand is doing here.
Dennis Byrne
On 3/3/07, Bernd Bohmann [EMAIL PROTECTED] wrote:
Just added an implementation of the annotation handling based on the
tomcat implementation.
Bernd
Dennis Byrne wrote:
I added a comment
http://blogs.sun.com/rlubke/entry/jsf_ri_1_2_and#comment-1172947192023 .
Two more ideas. Ryan mentions applications using facelets, jsf 1.2 and
servlet 2.4. Unless I'm missing something, there's one reason to use
annotation.getName().equals(javax.annotation.PostConstruct) rather
than
annotation.class == PostConstruct.class. Also, the tomcat guys are
processing annotations even when the method is marked private.
Dennis Byrne
On 3/3/07, Paul McMahan [EMAIL PROTECTED] wrote:
OK, I think the RI also recently added the META-INF/services
technique. But I don't know how reliable this sun blog entry is:
http://tinyurl.com/yrrjs2
Best wishes,
Paul
On 3/2/07, Mathias Brökelmann [EMAIL PROTECTED] wrote:
The RI uses two ways to lookup the implementation of the vendor
specific implementation of the InjectionProvider. They first try to
use a web context init param and if that is not configured they
simply
use a system property. Both keyed by the class name of the
InjectionProvider interface.
2007/3/2, Paul McMahan [EMAIL PROTECTED]:
I think Mathias' suggestion is right on. I haven't looked at the
RI
code but I read somewhere that it passes the name of
InjectionProviders via entries in META-INF/services. If MyFaces
used
a similar approach I think it should work OK for Geronimo and just
about any other container that supports injection, And it should
also
make MyFaces more interchangeable with the RI.
Best wishes,
Paul
On 3/2/07, Dennis Byrne [EMAIL PROTECTED] wrote:
Similar to what Mathias mentioned?
http://issues.apache.org/jira/browse/MYFACES-1246#action_12475337
It's not much work (on our side) but it sounds pretty vendor
specific.
Again, I don't have a better solution. Mathias writes which is
implemented
by j2ee containers. I wonder if each container will end up
looking
for
different interfaces. How would MyFaces find Geronimo's
implementation ? A
context parameter? A for loop like this ...
String[] providers = new String[]{org,apache.geronimo.DIProvider
,
com.bea.DIProvider, org.jboss.DIProvider}
for(String clazz : providers){
try{
return ClassUtils.load (clazz)
}catch(){}
}
Dennis Byrne
On 3/1/07, Paul McMahan [EMAIL PROTECTED] wrote:
OK, I think your interpretation of the spec makes sense and
there's
one particular aspect we should discuss a little further.
The container doesn't know which classes are managed beans so
it
wouldn't know when to intercept the instantiation process to
perform
injection. What would you all think about MyFaces providing an
interface that containers could implement to perform injection
on
a
managed bean when MyFaces brings that bean into service? This
would
allow MyFaces to maintain control of the timing while allowing
the
container to scan for annotations and handle injection when
prompted
to do so.
Best wishes,
Paul
On 2/26/07, Dennis Byrne [EMAIL PROTECTED] wrote:
I know the specs can be vague sometimes, but I don't
interpret
the first
paragraph of section 5.4 as meaning the JSF implementation is
responsible
for @EJB, @Resources, etc. The JSF spec specifically
mentions
the
container to inject references. If Geronimo can intercept
the
instantiation of these classes in the classloader (something
I
know
nothing
about right now), I think we are all good here. Wouldn't
MyFaces then
be
observing the requirements (in plain java) around
@PostConstruct
after
Geronimo had injected the resources?
I think the JSF impl is only responsible for @PostConstruct
and
@Predestroy.
This makes sense because scoped (request, session,
application)
are the
only candidates for this, and it would be more awkward to do
that from
the
container. I say all of this in an open manner, so anyone
feel
free to
discuss.
You're point about javax.annotation being in the Servlet 2.5is
taken.
I
totally missed that.
Dennis Byrne
On 2/26/07, Paul McMahan [EMAIL PROTECTED] wrote:
Actually by dependency injection I'm specifically
referring
to the
portion of the JSF spec that discusses injecting resources
where
certain annotations are found in a managed bean. So, while
scanning
for the @PreConstruct and @PostDestroy annotations MyFaces
would also
scan for @EJB
Re: @PreDestroy, Servlet API,
Mathias, me and Paul were discussing the future of this feature. For the
most part we were in agreement. I appreciate your input, but it did not
gain traction w/ anyone. You then went ahead and committed a bunch of code.
IMO, you have not been a good team member today Bernd. Please assign the
issue to yourself.
Thank you very much for your interest in getting us closer to a
1.2implementation.
Dennis Byrne
On 3/3/07, Bernd Bohmann [EMAIL PROTECTED] wrote:
??? Yes, I know it.
Dennis Byrne wrote:
Are you under the impression that our 1.2 branch didn't already handle
@PostConstruct and @PreDestroy? Looks like the left hand doesn't know
what
the right hand is doing here.
Dennis Byrne
On 3/3/07, Bernd Bohmann [EMAIL PROTECTED] wrote:
Just added an implementation of the annotation handling based on the
tomcat implementation.
Bernd
Dennis Byrne wrote:
I added a comment
http://blogs.sun.com/rlubke/entry/jsf_ri_1_2_and#comment-1172947192023.
Two more ideas. Ryan mentions applications using facelets, jsf 1.2and
servlet 2.4. Unless I'm missing something, there's one reason to use
annotation.getName().equals(javax.annotation.PostConstruct) rather
than
annotation.class == PostConstruct.class. Also, the tomcat guys are
processing annotations even when the method is marked private.
Dennis Byrne
On 3/3/07, Paul McMahan [EMAIL PROTECTED] wrote:
OK, I think the RI also recently added the META-INF/services
technique. But I don't know how reliable this sun blog entry is:
http://tinyurl.com/yrrjs2
Best wishes,
Paul
On 3/2/07, Mathias Brökelmann [EMAIL PROTECTED] wrote:
The RI uses two ways to lookup the implementation of the vendor
specific implementation of the InjectionProvider. They first try
to
use a web context init param and if that is not configured they
simply
use a system property. Both keyed by the class name of the
InjectionProvider interface.
2007/3/2, Paul McMahan [EMAIL PROTECTED]:
I think Mathias' suggestion is right on. I haven't looked at
the
RI
code but I read somewhere that it passes the name of
InjectionProviders via entries in META-INF/services. If MyFaces
used
a similar approach I think it should work OK for Geronimo and
just
about any other container that supports injection, And it
should
also
make MyFaces more interchangeable with the RI.
Best wishes,
Paul
On 3/2/07, Dennis Byrne [EMAIL PROTECTED] wrote:
Similar to what Mathias mentioned?
http://issues.apache.org/jira/browse/MYFACES-1246#action_12475337
It's not much work (on our side) but it sounds pretty vendor
specific.
Again, I don't have a better solution. Mathias writes which
is
implemented
by j2ee containers. I wonder if each container will end up
looking
for
different interfaces. How would MyFaces find Geronimo's
implementation ? A
context parameter? A for loop like this ...
String[] providers = new
String[]{org,apache.geronimo.DIProvider
,
com.bea.DIProvider, org.jboss.DIProvider}
for(String clazz : providers){
try{
return ClassUtils.load (clazz)
}catch(){}
}
Dennis Byrne
On 3/1/07, Paul McMahan [EMAIL PROTECTED] wrote:
OK, I think your interpretation of the spec makes sense and
there's
one particular aspect we should discuss a little further.
The container doesn't know which classes are managed beans
so
it
wouldn't know when to intercept the instantiation process to
perform
injection. What would you all think about MyFaces
providing an
interface that containers could implement to perform
injection
on
a
managed bean when MyFaces brings that bean into
service? This
would
allow MyFaces to maintain control of the timing while
allowing
the
container to scan for annotations and handle injection when
prompted
to do so.
Best wishes,
Paul
On 2/26/07, Dennis Byrne [EMAIL PROTECTED] wrote:
I know the specs can be vague sometimes, but I don't
interpret
the first
paragraph of section 5.4 as meaning the JSF
implementation is
responsible
for @EJB, @Resources, etc. The JSF spec specifically
mentions
the
container to inject references. If Geronimo can
intercept
the
instantiation of these classes in the classloader
(something
I
know
nothing
about right now), I think we are all good here. Wouldn't
MyFaces then
be
observing the requirements (in plain java) around
@PostConstruct
after
Geronimo had injected the resources?
I think the JSF impl is only responsible for
@PostConstruct
and
@Predestroy.
This makes sense because scoped (request, session,
application)
are the
only candidates for this, and it would be more awkward to
do
Re: @PreDestroy, Servlet API,
I don't hold anything against you. Ultimately I feel like this is a
lose-lose situation for MyFaces because where things stand now, you are
likely to feel as though your efforts on that branch are not appreciated.
They are.
Ryan has responded ...
http://blogs.sun.com/rlubke/entry/jsf_ri_1_2_and#comment-1172947192000
Dennis Byrne
On 3/3/07, Bernd Bohmann [EMAIL PROTECTED] wrote:
Sorry,
I ask you if it's ok to add the code.
I get no answer then I asume it's ok to add my idea.
It's only a different possible implementation.
If you don't like it you can remove it.
Is anything wrong with the code?
Bernd
Dennis Byrne wrote:
Mathias, me and Paul were discussing the future of this feature. For
the
most part we were in agreement. I appreciate your input, but it did not
gain traction w/ anyone. You then went ahead and committed a bunch of
code.
IMO, you have not been a good team member today Bernd. Please assign
the
issue to yourself.
Thank you very much for your interest in getting us closer to a
1.2implementation.
Dennis Byrne
On 3/3/07, Bernd Bohmann [EMAIL PROTECTED] wrote:
??? Yes, I know it.
Dennis Byrne wrote:
Are you under the impression that our 1.2 branch didn't already
handle
@PostConstruct and @PreDestroy? Looks like the left hand doesn't
know
what
the right hand is doing here.
Dennis Byrne
On 3/3/07, Bernd Bohmann [EMAIL PROTECTED] wrote:
Just added an implementation of the annotation handling based on the
tomcat implementation.
Bernd
Dennis Byrne wrote:
I added a comment
http://blogs.sun.com/rlubke/entry/jsf_ri_1_2_and#comment-1172947192023.
Two more ideas. Ryan mentions applications using facelets, jsf
1.2and
servlet 2.4. Unless I'm missing something, there's one reason to
use
annotation.getName().equals(javax.annotation.PostConstruct)
rather
than
annotation.class == PostConstruct.class. Also, the tomcat guys
are
processing annotations even when the method is marked private.
Dennis Byrne
On 3/3/07, Paul McMahan [EMAIL PROTECTED] wrote:
OK, I think the RI also recently added the META-INF/services
technique. But I don't know how reliable this sun blog entry is:
http://tinyurl.com/yrrjs2
Best wishes,
Paul
On 3/2/07, Mathias Brökelmann [EMAIL PROTECTED]
wrote:
The RI uses two ways to lookup the implementation of the vendor
specific implementation of the InjectionProvider. They first
try
to
use a web context init param and if that is not configured they
simply
use a system property. Both keyed by the class name of the
InjectionProvider interface.
2007/3/2, Paul McMahan [EMAIL PROTECTED]:
I think Mathias' suggestion is right on. I haven't looked at
the
RI
code but I read somewhere that it passes the name of
InjectionProviders via entries in META-INF/services. If
MyFaces
used
a similar approach I think it should work OK for Geronimo and
just
about any other container that supports injection, And it
should
also
make MyFaces more interchangeable with the RI.
Best wishes,
Paul
On 3/2/07, Dennis Byrne [EMAIL PROTECTED] wrote:
Similar to what Mathias mentioned?
http://issues.apache.org/jira/browse/MYFACES-1246#action_12475337
It's not much work (on our side) but it sounds pretty
vendor
specific.
Again, I don't have a better solution. Mathias writes
which
is
implemented
by j2ee containers. I wonder if each container will end
up
looking
for
different interfaces. How would MyFaces find Geronimo's
implementation ? A
context parameter? A for loop like this ...
String[] providers = new
String[]{org,apache.geronimo.DIProvider
,
com.bea.DIProvider, org.jboss.DIProvider}
for(String clazz : providers){
try{
return ClassUtils.load (clazz)
}catch(){}
}
Dennis Byrne
On 3/1/07, Paul McMahan [EMAIL PROTECTED] wrote:
OK, I think your interpretation of the spec makes sense
and
there's
one particular aspect we should discuss a little further.
The container doesn't know which classes are managed
beans
so
it
wouldn't know when to intercept the instantiation
process to
perform
injection. What would you all think about MyFaces
providing an
interface that containers could implement to perform
injection
on
a
managed bean when MyFaces brings that bean into
service? This
would
allow MyFaces to maintain control of the timing while
allowing
the
container to scan for annotations and handle injection
when
prompted
to do so.
Best wishes,
Paul
On 2/26/07, Dennis Byrne [EMAIL PROTECTED] wrote:
I know the specs can be vague sometimes, but I don't
interpret
the first
Re: @PreDestroy, Servlet API,
On 3/3/07, Mathias Brökelmann [EMAIL PROTECTED] wrote: No code in myfaces (or any other apache project) is owned by someone. That is important for a healthy and moving community. Bernds submission was a little bit fast but sometimes a complex issue is better understand if we can look at the code - no matter if that is the solution we finally have. I hope you did not get the idea that this was about territory here. How about this solution: We define a myfaces specific interface of an AnnotationProcessor/InjectionProvider which will be used throughout the code in myfaces. The initialization code lookups an implementation for that interface. If there is nothing found (through context param, META-INF/service, etc.) we implement some fallback strategies to either looking for a InjectionProvider implementation for suns RI or if that also fails we try to lookup container specific implementations like tomcats AnnotationProcessor implementation. If all fails we supply a default implementation which only handles @PostConstruct and @PreDestroy annotations - I don't think that it is possible to inject any resource w/o knowing how to lookup these. This sounds very similar to what Ryan just talked about in his blog. Bernd, if are happy w/ this and still interested, feel free to go forward with this. If you still want to, I ask that the default implementation uses the annotation name, rather than the annotation. This gives Tomcat 5.5/Facelets users fewer headaches. Do either of you have a problem w/ the context listener doing a classpath search for well known injection providers? I meet a lot of devs who find JSF too configuration heavy. Bernd if you don't get around to doing this, I will just end up doing it sometime next week. 2007/3/3, Bernd Bohmann [EMAIL PROTECTED]: Sorry, I ask you if it's ok to add the code. I get no answer then I asume it's ok to add my idea. It's only a different possible implementation. If you don't like it you can remove it. Is anything wrong with the code? Bernd Dennis Byrne wrote: Mathias, me and Paul were discussing the future of this feature. For the most part we were in agreement. I appreciate your input, but it did not gain traction w/ anyone. You then went ahead and committed a bunch of code. IMO, you have not been a good team member today Bernd. Please assign the issue to yourself. Thank you very much for your interest in getting us closer to a 1.2implementation. Dennis Byrne On 3/3/07, Bernd Bohmann [EMAIL PROTECTED] wrote: ??? Yes, I know it. Dennis Byrne wrote: Are you under the impression that our 1.2 branch didn't already handle @PostConstruct and @PreDestroy? Looks like the left hand doesn't know what the right hand is doing here. Dennis Byrne On 3/3/07, Bernd Bohmann [EMAIL PROTECTED] wrote: Just added an implementation of the annotation handling based on the tomcat implementation. Bernd Dennis Byrne wrote: I added a comment http://blogs.sun.com/rlubke/entry/jsf_ri_1_2_and#comment-1172947192023. Two more ideas. Ryan mentions applications using facelets, jsf 1.2and servlet 2.4. Unless I'm missing something, there's one reason to use annotation.getName().equals(javax.annotation.PostConstruct) rather than annotation.class == PostConstruct.class. Also, the tomcat guys are processing annotations even when the method is marked private. Dennis Byrne On 3/3/07, Paul McMahan [EMAIL PROTECTED] wrote: OK, I think the RI also recently added the META-INF/services technique. But I don't know how reliable this sun blog entry is: http://tinyurl.com/yrrjs2 Best wishes, Paul On 3/2/07, Mathias Brökelmann [EMAIL PROTECTED] wrote: The RI uses two ways to lookup the implementation of the vendor specific implementation of the InjectionProvider. They first try to use a web context init param and if that is not configured they simply use a system property. Both keyed by the class name of the InjectionProvider interface. 2007/3/2, Paul McMahan [EMAIL PROTECTED]: I think Mathias' suggestion is right on. I haven't looked at the RI code but I read somewhere that it passes the name of InjectionProviders via entries in META-INF/services. If MyFaces used a similar approach I think it should work OK for Geronimo and just about any other container that supports injection, And it should also make MyFaces more interchangeable with the RI. Best wishes, Paul On 3/2/07, Dennis Byrne [EMAIL PROTECTED] wrote: Similar to what Mathias mentioned? http://issues.apache.org/jira/browse/MYFACES-1246#action_12475337 It's not much work (on our side) but it sounds pretty vendor specific. Again, I don't have a better solution. Mathias
Re: @PreDestroy, Servlet API,
Unfortunately, I don't see a way to do non proprietary annotation/injection processing, since the component that has to do it (JSP or JSF) cannot possibly get the configuration (which could define overrides, etc). Since I suppose you'll want to support all containers, that's a problem. (It would have been solved if the servlet spec had defined an interface like InjectionProvider in javax.servlet, of course.) This is going to go down in the same category as inter Portlet communication and j2ee 1.4 web services deployment. It's no problem to use the annotation name instead of using the class. But personal i prefer the class. Rémy -- Dennis Byrne
Re: @PreDestroy, Servlet API,
Similar to what Mathias mentioned?
http://issues.apache.org/jira/browse/MYFACES-1246#action_12475337
It's not much work (on our side) but it sounds pretty vendor specific.
Again, I don't have a better solution. Mathias writes which is implemented
by j2ee containers. I wonder if each container will end up looking for
different interfaces. How would MyFaces find Geronimo's implementation ? A
context parameter? A for loop like this ...
String[] providers = new String[]{org,apache.geronimo.DIProvider,
com.bea.DIProvider, org.jboss.DIProvider}
for(String clazz : providers){
try{
return ClassUtils.load(clazz)
}catch(){}
}
Dennis Byrne
On 3/1/07, Paul McMahan [EMAIL PROTECTED] wrote:
OK, I think your interpretation of the spec makes sense and there's
one particular aspect we should discuss a little further.
The container doesn't know which classes are managed beans so it
wouldn't know when to intercept the instantiation process to perform
injection. What would you all think about MyFaces providing an
interface that containers could implement to perform injection on a
managed bean when MyFaces brings that bean into service? This would
allow MyFaces to maintain control of the timing while allowing the
container to scan for annotations and handle injection when prompted
to do so.
Best wishes,
Paul
On 2/26/07, Dennis Byrne [EMAIL PROTECTED] wrote:
I know the specs can be vague sometimes, but I don't interpret the first
paragraph of section 5.4 as meaning the JSF implementation is
responsible
for @EJB, @Resources, etc. The JSF spec specifically mentions the
container to inject references. If Geronimo can intercept the
instantiation of these classes in the classloader (something I know
nothing
about right now), I think we are all good here. Wouldn't MyFaces then
be
observing the requirements (in plain java) around @PostConstruct after
Geronimo had injected the resources?
I think the JSF impl is only responsible for @PostConstruct and
@Predestroy.
This makes sense because scoped (request, session, application) are the
only candidates for this, and it would be more awkward to do that from
the
container. I say all of this in an open manner, so anyone feel free to
discuss.
You're point about javax.annotation being in the Servlet 2.5 is
taken. I
totally missed that.
Dennis Byrne
On 2/26/07, Paul McMahan [EMAIL PROTECTED] wrote:
Actually by dependency injection I'm specifically referring to the
portion of the JSF spec that discusses injecting resources where
certain annotations are found in a managed bean. So, while scanning
for the @PreConstruct and @PostDestroy annotations MyFaces would also
scan for @EJB, @Resource, @WebServiceRef, etc and then time the
invocation of @PreConstruct and @PostDestroy to support the injection.
Tomcat provides an example of how this can be done. The following
class scans for annotations when a web app starts:
http://svn.apache.org/repos/asf/tomcat/tc6.0.x/trunk/java/org/apache/catalina/startup/WebAnnotationSet.java
And then this class handles the injection and calling the
PostConstruct and PreDestroy methods when an servlet, filter, or
listener is brought into service:
http://svn.apache.org/repos/asf/tomcat/tc6.0.x/trunk/java/org/apache/catalina/util/DefaultAnnotationProcessor.java
Would it make sense for MyFaces to follow a similar approach for
managed beans? Also, I'm curious why you're hoping to avoid importing
classes from javax.annotation classes since servlet 2.5 containers are
required to support them. Is this so that MyFaces 1.2 can support
servlet 2.4 containers?
Best wishes,
Paul
On 2/26/07, Dennis Byrne [EMAIL PROTECTED] wrote:
I ended up going with Servlet/Request/Context attribute listeners
for
@PreDestroy. This did not involve importing
javax.annotation.PreDestroy, so
people w/out application servers don't have to worry about
ClassDefNotFoundErrors. This also keeps us compatible with the
reference
implementation in terms of timing, although I really wish they'd
change
the
wording in the spec.
Dennis Byrne
On 2/26/07, Paul McMahan [EMAIL PROTECTED] wrote:
Sorry if I'm behind on this discussion but what are the current
thoughts on how dependency injection will be implemented for
managed
beans? The reason I'm curious is because PreDestroy and
PostConstruct
annotations are used to deal with injected resources, so from a
timing
perspective it would be important to process all these annotations
accordingly.
Best wishes,
Paul
On 2/24/07, Dennis Byrne [EMAIL PROTECTED] wrote:
I'm weighing options about invoking @PreDestroy methods
(@PostConstruct
is
done BTW). I haven't made up my mind yet but here's where I'm
at on
this.
As far as *when* this happens, the request is easy, in
FacesServelet.service(). Session and app scope are more
difficult
decisions
Re: @PreDestroy, Servlet API,
Are any of these class names or context params start w/ javax.faces ? If
so, we can move the conversation back into the issue tracker and I'll close
the @PostConstruct issue once Paul says it's good to go. I don't see the
point of the system property though.
Dennis Byrne
On 3/2/07, Mathias Brökelmann [EMAIL PROTECTED] wrote:
The RI uses two ways to lookup the implementation of the vendor
specific implementation of the InjectionProvider. They first try to
use a web context init param and if that is not configured they simply
use a system property. Both keyed by the class name of the
InjectionProvider interface.
2007/3/2, Paul McMahan [EMAIL PROTECTED]:
I think Mathias' suggestion is right on. I haven't looked at the RI
code but I read somewhere that it passes the name of
InjectionProviders via entries in META-INF/services. If MyFaces used
a similar approach I think it should work OK for Geronimo and just
about any other container that supports injection, And it should also
make MyFaces more interchangeable with the RI.
Best wishes,
Paul
On 3/2/07, Dennis Byrne [EMAIL PROTECTED] wrote:
Similar to what Mathias mentioned?
http://issues.apache.org/jira/browse/MYFACES-1246#action_12475337
It's not much work (on our side) but it sounds pretty vendor specific.
Again, I don't have a better solution. Mathias writes which is
implemented
by j2ee containers. I wonder if each container will end up looking
for
different interfaces. How would MyFaces find Geronimo's
implementation ? A
context parameter? A for loop like this ...
String[] providers = new String[]{org,apache.geronimo.DIProvider,
com.bea.DIProvider, org.jboss.DIProvider}
for(String clazz : providers){
try{
return ClassUtils.load (clazz)
}catch(){}
}
Dennis Byrne
On 3/1/07, Paul McMahan [EMAIL PROTECTED] wrote:
OK, I think your interpretation of the spec makes sense and there's
one particular aspect we should discuss a little further.
The container doesn't know which classes are managed beans so it
wouldn't know when to intercept the instantiation process to perform
injection. What would you all think about MyFaces providing an
interface that containers could implement to perform injection on a
managed bean when MyFaces brings that bean into service? This would
allow MyFaces to maintain control of the timing while allowing the
container to scan for annotations and handle injection when prompted
to do so.
Best wishes,
Paul
On 2/26/07, Dennis Byrne [EMAIL PROTECTED] wrote:
I know the specs can be vague sometimes, but I don't interpret the
first
paragraph of section 5.4 as meaning the JSF implementation is
responsible
for @EJB, @Resources, etc. The JSF spec specifically mentions
the
container to inject references. If Geronimo can intercept the
instantiation of these classes in the classloader (something I
know
nothing
about right now), I think we are all good here. Wouldn't MyFaces
then
be
observing the requirements (in plain java) around @PostConstruct
after
Geronimo had injected the resources?
I think the JSF impl is only responsible for @PostConstruct and
@Predestroy.
This makes sense because scoped (request, session, application)
are the
only candidates for this, and it would be more awkward to do that
from
the
container. I say all of this in an open manner, so anyone feel
free to
discuss.
You're point about javax.annotation being in the Servlet 2.5 is
taken.
I
totally missed that.
Dennis Byrne
On 2/26/07, Paul McMahan [EMAIL PROTECTED] wrote:
Actually by dependency injection I'm specifically referring to
the
portion of the JSF spec that discusses injecting resources where
certain annotations are found in a managed bean. So, while
scanning
for the @PreConstruct and @PostDestroy annotations MyFaces would
also
scan for @EJB, @Resource, @WebServiceRef, etc and then time the
invocation of @PreConstruct and @PostDestroy to support the
injection.
Tomcat provides an example of how this can be done. The
following
class scans for annotations when a web app starts:
http://svn.apache.org/repos/asf/tomcat/tc6.0.x/trunk/java/org/apache/catalina/startup/WebAnnotationSet.java
And then this class handles the injection and calling the
PostConstruct and PreDestroy methods when an servlet, filter, or
listener is brought into service:
http://svn.apache.org/repos/asf/tomcat/tc6.0.x/trunk/java/org/apache/catalina/util/DefaultAnnotationProcessor.java
Would it make sense for MyFaces to follow a similar approach for
managed beans? Also, I'm curious why you're hoping to avoid
importing
classes from javax.annotation classes since servlet 2.5containers are
required to support them. Is this so that MyFaces 1.2 can
support
servlet 2.4
Re: @PreDestroy, Servlet API,
As much as I agree w/ you about how better things would be if this were in
the spec, and as much as I hate to bow down here, I am actually OK with
using com.sun.faces.spi.InjectionProvider as the parameter in MyFaces as
well ... for the sake of users. If anyone has a problem w/ it, we can go
with org.apache.myfaces.InjectionProvider.
Dennis Byrne
On 3/2/07, Mathias Brökelmann [EMAIL PROTECTED] wrote:
The RI looks for com.sun.faces.spi.InjectionProvider for a class
name which implements this interface. It would have been very nice if
this is part of the spec. But that is not the case so we need to find
a way to support any kind of j2ee container. IMO injecting j2ee
resources without knowing where these resources can be found is not
possible. Therefore myfaces should call an InjectionProvider which
simply do this job.
2007/3/3, Dennis Byrne [EMAIL PROTECTED]:
Are any of these class names or context params start w/ javax.faces? If
so, we can move the conversation back into the issue tracker and I'll
close
the @PostConstruct issue once Paul says it's good to go. I don't see
the
point of the system property though.
Dennis Byrne
On 3/2/07, Mathias Brökelmann [EMAIL PROTECTED] wrote:
The RI uses two ways to lookup the implementation of the vendor
specific implementation of the InjectionProvider. They first try to
use a web context init param and if that is not configured they simply
use a system property. Both keyed by the class name of the
InjectionProvider interface.
2007/3/2, Paul McMahan [EMAIL PROTECTED]:
I think Mathias' suggestion is right on. I haven't looked at the RI
code but I read somewhere that it passes the name of
InjectionProviders via entries in META-INF/services. If MyFaces
used
a similar approach I think it should work OK for Geronimo and just
about any other container that supports injection, And it should
also
make MyFaces more interchangeable with the RI.
Best wishes,
Paul
On 3/2/07, Dennis Byrne [EMAIL PROTECTED] wrote:
Similar to what Mathias mentioned?
http://issues.apache.org/jira/browse/MYFACES-1246#action_12475337
It's not much work (on our side) but it sounds pretty vendor
specific.
Again, I don't have a better solution. Mathias writes which is
implemented
by j2ee containers. I wonder if each container will end up
looking
for
different interfaces. How would MyFaces find Geronimo's
implementation ? A
context parameter? A for loop like this ...
String[] providers = new String[]{org,apache.geronimo.DIProvider
,
com.bea.DIProvider, org.jboss.DIProvider }
for(String clazz : providers){
try{
return ClassUtils.load (clazz)
}catch(){}
}
Dennis Byrne
On 3/1/07, Paul McMahan [EMAIL PROTECTED] wrote:
OK, I think your interpretation of the spec makes sense and
there's
one particular aspect we should discuss a little further.
The container doesn't know which classes are managed beans so it
wouldn't know when to intercept the instantiation process to
perform
injection. What would you all think about MyFaces providing an
interface that containers could implement to perform injection
on a
managed bean when MyFaces brings that bean into service? This
would
allow MyFaces to maintain control of the timing while allowing
the
container to scan for annotations and handle injection when
prompted
to do so.
Best wishes,
Paul
On 2/26/07, Dennis Byrne [EMAIL PROTECTED] wrote:
I know the specs can be vague sometimes, but I don't interpret
the
first
paragraph of section 5.4 as meaning the JSF implementation is
responsible
for @EJB, @Resources, etc. The JSF spec specifically mentions
the
container to inject references. If Geronimo can intercept
the
instantiation of these classes in the classloader (something I
know
nothing
about right now), I think we are all good here. Wouldn't
MyFaces
then
be
observing the requirements (in plain java) around
@PostConstruct
after
Geronimo had injected the resources?
I think the JSF impl is only responsible for @PostConstruct
and
@Predestroy.
This makes sense because scoped (request, session,
application)
are the
only candidates for this, and it would be more awkward to do
that
from
the
container. I say all of this in an open manner, so anyone feel
free to
discuss.
You're point about javax.annotation being in the Servlet 2.5is
taken.
I
totally missed that.
Dennis Byrne
On 2/26/07, Paul McMahan [EMAIL PROTECTED] wrote:
Actually by dependency injection I'm specifically
referring to
the
portion of the JSF spec that discusses injecting resources
where
certain annotations are found in a managed bean. So, while
scanning
Re: MyFaces Fusion Naming
What about Apache MyFaces Seamless ?! +1 --Manfred On 2/27/07, Manfred Geiler [EMAIL PROTECTED] wrote: +1: Apache MyFaces Fusion -0.9 : Apache MyFaces Salida -1 : Apache MyFaces Defender -1 : Apache MyFaces Sesams On 2/27/07, Grant Smith [EMAIL PROTECTED] wrote: + 1: Apache MyFaces Fusion - 2 : Apache MyFaces Defender (awful!) +0 : Apache MyFaces Salida (e...) -- Grant Smith -- Dennis Byrne
logging again ... was Re: Running MyFaces 1.2
Since JSF is part of the JEE 5 spec users don't need to include the JSF jars or their dependencies in their webapps when deploying into Geronimo 2.0. This makes developing a webapp much easier but makes developing JSF a little more tricky because the MyFaces jars are part of the server runtime. Hi Paul, On this team there is an age old debate about how logging. The gist is that we have static loggers all over the place. This of course is not good because the jars are not going to be located in the war (where they are isolated by separate class loaders). Well, team ... we've never had a better reason to rip out the static loggers. What do you say? Best wishes, Paul On 2/26/07, Matthias Wessendorf [EMAIL PROTECTED] wrote: geronimo2-SNAPSHOT you don't need to include the jsf-xxx jars A Java EE 5 compliant server has to ignore the jsf-xxx libs, shipped in WEB-INF/lib Since Tomcat 6.x and Jetty 6.x don't ship JSF, you have to include them in your lib, like in the past -M On 2/26/07, Martin Haimberger [EMAIL PROTECTED] wrote: Sorry for spamming, but is there another Application Server which will work with MyFaces 1.2 and Intellij Idea ? Regards, Martin Haimberger On 2/26/07, Martin Haimberger [EMAIL PROTECTED] wrote: No nothing more. No Exception, nothing. I will try Jetty6.1.x, i hope the myfaces1.2 will start. Regards, Martin Haimberger On 2/26/07, Matthias Wessendorf [EMAIL PROTECTED] wrote: does the tomcat log say more? I am able to deploy a jsf 1.2 app with Jetty6.1.x -M On 2/26/07, Martin Haimberger [EMAIL PROTECTED] wrote: Hy *, i am going to help to develop myfaces 1.2. I have checked it out, compiled it (with some difficulties, because some jars were not found). I installed tomcat 6.0.9 alpha and i got this error: DEBUG [main] (HtmlRenderKitImpl.java:112) - add Renderer family = javax.faces.SelectOne rendererType = javax.faces.Radio renderer class = org.apache.myfaces.renderkit.html.HtmlRadioRenderer INFO [main] (FacesConfigurator.java:972) - Serialization provider : class org.apache.myfaces.shared_impl.util.serial.DefaultSerialFactory Feb 26, 2007 2:14:34 PM org.apache.catalina.core.StandardContextstart SEVERE: Error listenerStart Feb 26, 2007 2:14:34 PM org.apache.catalina.core.StandardContextstart I am running Intellij 6.0.4 and tomcat 6.0.9 on MacOsX. Has someone any idea what i did wrong? Regards, Martin Haimberger -- Matthias Wessendorf http://tinyurl.com/fmywh further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com -- Matthias Wessendorf http://tinyurl.com/fmywh further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com -- Dennis Byrne
Re: @author tags
there is reasons for having them and for not having them. I personally like to have a quick glance on the author tag to check where the class originated - and I personally don't think they work as a no trespassing sign at all, and have never done so. Ever? Anywhere? No way. The closest thing is a loose association you pick up after being on the list for a while. For example, when I think of the tree2 component, I think of Sean. When I think of Portlets, I think of Stan. The scheduler/calendar component, Jurgen. But there's no way any of them would/could say hey, that's my area. geir BTW, I'm ccing the dev list because Matze moved it there. Dennis Byrne regards, Martin On 2/25/07, Bernd Bohmann [EMAIL PROTECTED] wrote: Hello, I'm fine with removing the author tags, too. We can enforce this with a checkstyle rule: !-- No @author tags -- module name=GenericIllegalRegexp property name=format value=@author/ property name=message value=No @author tag allowed/ /module Regards Bernd Matthias Wessendorf wrote: Hi PMC fellows, I'd like to resuscitate the discussion we had in the past on the @author tags. These tags aren't a good practice. For instance, when the @author tags belong to committers no longer active in the project so they no longer function as a no trespassing sign. Also on a incubator based discussion, Bill pointed out: snip In general, @author tags and attributions are poison to ASF-style collaboration, they are all about carving out niches in the code. The ASF-style development is about tearing down niches and promoting collaboration across an entire code base. Collaboration and ownership are generally mutually exclusive. /snip What do you think? I am fine w/ removing them step by step Thanks, Matthias -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces -- Dennis Byrne
Re: @PreDestroy, Servlet API,
I ended up going with Servlet/Request/Context attribute listeners for @PreDestroy. This did not involve importing javax.annotation.PreDestroy, so people w/out application servers don't have to worry about ClassDefNotFoundErrors. This also keeps us compatible with the reference implementation in terms of timing, although I really wish they'd change the wording in the spec. Dennis Byrne On 2/26/07, Paul McMahan [EMAIL PROTECTED] wrote: Sorry if I'm behind on this discussion but what are the current thoughts on how dependency injection will be implemented for managed beans? The reason I'm curious is because PreDestroy and PostConstruct annotations are used to deal with injected resources, so from a timing perspective it would be important to process all these annotations accordingly. Best wishes, Paul On 2/24/07, Dennis Byrne [EMAIL PROTECTED] wrote: I'm weighing options about invoking @PreDestroy methods (@PostConstruct is done BTW). I haven't made up my mind yet but here's where I'm at on this. As far as *when* this happens, the request is easy, in FacesServelet.service(). Session and app scope are more difficult decisions. A new HttpSessionActivationListener.attributeRemoved and a new ServletContextAttributeListener.attributeRemoved() seem like nice solutions, but this doesn't meet the spec requirements for 5.4.1. The methods have to be invoked *before* the bean is pulled from scope and the servlet API does not provide a ServletContextAttributeListener.attribute_WILL_BE_Removed() or a HttpSessionActivationListener.attribute_WILL_BE_Removed (). Also, I say *new* ServletContextAttributeListener and because StartupServletContextListener (already in code base) implements ServletContextListener, not ServletContextAttributeListener. The other side of the problem is *how* to invoke each @PreDestroy method, much easier. Iterating over the attributes at each scope level is trivial, and so is determining if the bean's class is a managed bean class. But this does not mean the *instance* was placed there by the JSF implementation. Using a list (at each level of scope) to track managed instances solves the problem, as long as you sync on the session (only one time per session) in order to avoid concurrency issues; it also means three more data structures in memory. -- Dennis Byrne -- Dennis Byrne
Re: @PreDestroy, Servlet API,
I know the specs can be vague sometimes, but I don't interpret the first paragraph of section 5.4 as meaning the JSF implementation is responsible for @EJB, @Resources, etc. The JSF spec specifically mentions the container to inject references. If Geronimo can intercept the instantiation of these classes in the classloader (something I know nothing about right now), I think we are all good here. Wouldn't MyFaces then be observing the requirements (in plain java) around @PostConstruct after Geronimo had injected the resources? I think the JSF impl is only responsible for @PostConstruct and @Predestroy. This makes sense because scoped (request, session, application) are the only candidates for this, and it would be more awkward to do that from the container. I say all of this in an open manner, so anyone feel free to discuss. You're point about javax.annotation being in the Servlet 2.5 is taken. I totally missed that. Dennis Byrne On 2/26/07, Paul McMahan [EMAIL PROTECTED] wrote: Actually by dependency injection I'm specifically referring to the portion of the JSF spec that discusses injecting resources where certain annotations are found in a managed bean. So, while scanning for the @PreConstruct and @PostDestroy annotations MyFaces would also scan for @EJB, @Resource, @WebServiceRef, etc and then time the invocation of @PreConstruct and @PostDestroy to support the injection. Tomcat provides an example of how this can be done. The following class scans for annotations when a web app starts: http://svn.apache.org/repos/asf/tomcat/tc6.0.x/trunk/java/org/apache/catalina/startup/WebAnnotationSet.java And then this class handles the injection and calling the PostConstruct and PreDestroy methods when an servlet, filter, or listener is brought into service: http://svn.apache.org/repos/asf/tomcat/tc6.0.x/trunk/java/org/apache/catalina/util/DefaultAnnotationProcessor.java Would it make sense for MyFaces to follow a similar approach for managed beans? Also, I'm curious why you're hoping to avoid importing classes from javax.annotation classes since servlet 2.5 containers are required to support them. Is this so that MyFaces 1.2 can support servlet 2.4 containers? Best wishes, Paul On 2/26/07, Dennis Byrne [EMAIL PROTECTED] wrote: I ended up going with Servlet/Request/Context attribute listeners for @PreDestroy. This did not involve importing javax.annotation.PreDestroy, so people w/out application servers don't have to worry about ClassDefNotFoundErrors. This also keeps us compatible with the reference implementation in terms of timing, although I really wish they'd change the wording in the spec. Dennis Byrne On 2/26/07, Paul McMahan [EMAIL PROTECTED] wrote: Sorry if I'm behind on this discussion but what are the current thoughts on how dependency injection will be implemented for managed beans? The reason I'm curious is because PreDestroy and PostConstruct annotations are used to deal with injected resources, so from a timing perspective it would be important to process all these annotations accordingly. Best wishes, Paul On 2/24/07, Dennis Byrne [EMAIL PROTECTED] wrote: I'm weighing options about invoking @PreDestroy methods (@PostConstruct is done BTW). I haven't made up my mind yet but here's where I'm at on this. As far as *when* this happens, the request is easy, in FacesServelet.service(). Session and app scope are more difficult decisions. A new HttpSessionActivationListener.attributeRemoved and a new ServletContextAttributeListener.attributeRemoved() seem like nice solutions, but this doesn't meet the spec requirements for 5.4.1. The methods have to be invoked *before* the bean is pulled from scope and the servlet API does not provide a ServletContextAttributeListener.attribute_WILL_BE_Removed() or a HttpSessionActivationListener.attribute_WILL_BE_Removed (). Also, I say *new* ServletContextAttributeListener and because StartupServletContextListener (already in code base) implements ServletContextListener, not ServletContextAttributeListener. The other side of the problem is *how* to invoke each @PreDestroy method, much easier. Iterating over the attributes at each scope level is trivial, and so is determining if the bean's class is a managed bean class. But this does not mean the *instance* was placed there by the JSF implementation. Using a list (at each level of scope) to track managed instances solves the problem, as long as you sync on the session (only one time per session) in order to avoid concurrency issues; it also means three more data structures in memory. -- Dennis Byrne -- Dennis Byrne -- Dennis Byrne
[VOTE] Remove Static loggers from 1.2
Alright. Here's my +1 binding. Let's put the nail in this coffin. Dennis Byrne On 2/26/07, Paul McMahan [EMAIL PROTECTED] wrote: Excellent observation, Dennis. In Geronimo and a few other app servers I am familiar with the user is provided with several knobs that can affect classloading. Ideally, a component designed to run in different types of containers would make as few assumptions about its container's classloader configuration as possible. For example, Geronimo's classloaders can have multiple immediate parents which confuses code that thinks it can find resources (like TLDs) in the app's classloader by walking up a direct lineage of classloaders using getParent(). And like you say, factories and services like logging can get confused when they key on classes that are available from multiple classloaders. Another item somewhat related to this discussion that comes to mind is how Geronimo provides a shared instance of the Dojo toolkit in a preinstalled webapp that is deployed at the context /dojo. Webapps can of course include their own private copy of the Dojo toolkit in their WAR but they miss out on several benefits such as improved resource caching across application contexts, smaller application footprint, and having the ability to upgrade and otherwise manage the Dojo component separately from their webapp. I thought this might be interesting to those working on Dojo/MyFaces integration. Best wishes, Paul On 2/26/07, Dennis Byrne [EMAIL PROTECTED] wrote: Since JSF is part of the JEE 5 spec users don't need to include the JSF jars or their dependencies in their webapps when deploying into Geronimo 2.0. This makes developing a webapp much easier but makes developing JSF a little more tricky because the MyFaces jars are part of the server runtime. Hi Paul, On this team there is an age old debate about how logging. The gist is that we have static loggers all over the place. This of course is not good because the jars are not going to be located in the war (where they are isolated by separate class loaders). Well, team ... we've never had a better reason to rip out the static loggers. What do you say? Best wishes, Paul On 2/26/07, Matthias Wessendorf [EMAIL PROTECTED] wrote: geronimo2-SNAPSHOT you don't need to include the jsf-xxx jars A Java EE 5 compliant server has to ignore the jsf-xxx libs, shipped in WEB-INF/lib Since Tomcat 6.x and Jetty 6.x don't ship JSF, you have to include them in your lib, like in the past -M On 2/26/07, Martin Haimberger [EMAIL PROTECTED] wrote: Sorry for spamming, but is there another Application Server which will work with MyFaces 1.2 and Intellij Idea ? Regards, Martin Haimberger On 2/26/07, Martin Haimberger [EMAIL PROTECTED] wrote: No nothing more. No Exception, nothing. I will try Jetty6.1.x, i hope the myfaces1.2 will start. Regards, Martin Haimberger On 2/26/07, Matthias Wessendorf [EMAIL PROTECTED] wrote: does the tomcat log say more? I am able to deploy a jsf 1.2 app with Jetty6.1.x -M On 2/26/07, Martin Haimberger [EMAIL PROTECTED] wrote: Hy *, i am going to help to develop myfaces 1.2. I have checked it out, compiled it (with some difficulties, because some jars were not found). I installed tomcat 6.0.9 alpha and i got this error: DEBUG [main] ( HtmlRenderKitImpl.java:112) - add Renderer family = javax.faces.SelectOne rendererType = javax.faces.Radiorenderer class = org.apache.myfaces.renderkit.html.HtmlRadioRenderer INFO [main] (FacesConfigurator.java:972) - Serialization provider : class org.apache.myfaces.shared_impl.util.serial.DefaultSerialFactory Feb 26, 2007 2:14:34 PM org.apache.catalina.core.StandardContext start SEVERE: Error listenerStart Feb 26, 2007 2:14:34 PM org.apache.catalina.core.StandardContext start I am running Intellij 6.0.4 and tomcat 6.0.9 on MacOsX. Has someone any idea what i did wrong? Regards, Martin Haimberger -- Matthias Wessendorf http://tinyurl.com/fmywh further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com -- Matthias Wessendorf http://tinyurl.com/fmywh further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com -- Dennis Byrne -- Dennis Byrne
repository for java.net
I've removed the repository elements for java.net in two of the poms for the 1.2 branch and mvn clean install runs fine. I may be missing something here, but is there any reason we need these? -- Dennis Byrne
We've been Kibitzed!
http://www.sourcekibitzer.org/index.php?option=com_skprojectprojectid=myfaces-core -- Dennis Byrne
Re: JSF 1.2 / continuum
Hello Matze, where does it deploy it to. Is there any way we can use this for feedback? Dennis Byrne On 2/24/07, Matthias Wessendorf [EMAIL PROTECTED] wrote: ok, continuum deploys the JSF 1.2 stuff now to: q On 2/23/07, Matthias Wessendorf [EMAIL PROTECTED] wrote: ah, ok for cont. however, I am not able to edit the things... I committed the dist. mgmt in the meantime. mvn clean install should be moved to mvn clean install source:jar deploy On 2/23/07, Mathias Brökelmann [EMAIL PROTECTED] wrote: no I'm not root. 2007/2/23, Matthias Wessendorf [EMAIL PROTECTED]: btw. you are root ? if so, can you create me an account matzew as well on the zone ? (speaking of a unix account) -M On 2/23/07, Matthias Wessendorf [EMAIL PROTECTED] wrote: we should overhaul the distributionManagement section to be able to run mvn clean install source:jar deploy -M On 2/23/07, Mathias Brökelmann [EMAIL PROTECTED] wrote: Hi Matthias, I still have no rights on the continuum server at port 8081. The account mrmaven is locked there. I've created an account for me (mbr) but someone needs to give me more rights. Have you configured continuum to do the deployment? Or have you done it manually? The build problems for 1.2 are fixed now. I just had to add an additional dependency (commons-logging:1.0.4) to the maven-faces-plugin. But the pom of the plugin is probably the better place. 2007/2/23, Matthias Wessendorf [EMAIL PROTECTED]: Mathias- did you now add the myfaces 1.2 stuff to continuum ? In the meantime, I just published myfaces12 to a staging repo ([1]). that should at least help the geronimo folks a bit . -M [1] http://people.apache.org/~matzew/myfaces12-stage/ -- Matthias Wessendorf http://tinyurl.com/fmywh further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com -- Mathias -- Matthias Wessendorf http://tinyurl.com/fmywh further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com -- Matthias Wessendorf http://tinyurl.com/fmywh further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com -- Mathias -- Matthias Wessendorf http://tinyurl.com/fmywh further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com -- Matthias Wessendorf http://tinyurl.com/fmywh further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com -- Dennis Byrne
Re: Tomahawk 1.1.5 release plans?
6.0? Seriously? Dennis Byrne On 2/23/07, Matthias Wessendorf [EMAIL PROTECTED] wrote: there was a wiki page which says that they want to have the next version of jsf (2.0) named 6.0 so... I am not really seeing any reason to go from myfaces 1.2 to a 6 ... :-) On 2/23/07, Dennis Byrne [EMAIL PROTECTED] wrote: JSF 1.1 - MyFaces 1.x JSF 1.2 - MyFaces 2.x I'd rather keep the release numbers in sync with the spec numbers. 1.1 - 1.1.x, 1.2 - 1.2.x Paul Spencer Matthias Wessendorf wrote: we sould do the same for core next is 1.5.0 and JSF 1.2 stuff should be changed to 2.0.0 On 2/23/07, Manfred Geiler [EMAIL PROTECTED] wrote: 1.5.0 or 1.6.0. One is as good as the other IMO. You mean 1.6.0 is better because it does not match the 1.1.5 of current core? I think Martin suggested 1.5.0 because it would be in the style of Tomcat 5.0.x vs Tomcat 5.5.x, right? --Manfred On 2/23/07, Paul Spencer [EMAIL PROTECTED] wrote: If the version of Tomahawk is not tied to the version of MyFaces, then how about the NEXT version of Tomahawk be 1.6? This would allow Tomahawk, like Tobago, to be version independently of MyFaces. Paul Spencer Martin Marinschek wrote: slightly too late, but 1.1.5 would have been my option as well. other option: 1.5 - and let tomahawk and impl version numbers get out of sync. regards, Martin On 2/23/07, Manfred Geiler [EMAIL PROTECTED] wrote: Ok, thanks for your feedback. Branch 1.1.5 created. --Manfred On 2/23/07, Wendy Smoak [EMAIL PROTECTED] wrote: On 2/23/07, Manfred Geiler [EMAIL PROTECTED] wrote: The new tomahawk release number is a trade-off. We must decide between - releasing tomahawk 1.1.4 which is not compatible to core 1.1.4 and therefore might confuse users - skipping tomahawk 1.1.4, stay in sync with core and have a tomahawk 1.1.5 that is 100% compatible to the current core 1.1.5 +1 for Tomahawk 1.1.5 this time around, which will be compatible with Core 1.1.5. (There is plenty of information in the archives if anyone asks what happened to 1.1.4. As Paul points out, Tomcat skips version numbers in their public release series.) -- Wendy -- Dennis Byrne -- Matthias Wessendorf http://tinyurl.com/fmywh further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com -- Dennis Byrne
[jira] Commented: (MYFACES-1246) JSR-252 Issue #119: implementations running in a JSR-250 container have their managed bean methods annotated with @PostConstruct be called after the object is instanti
[ https://issues.apache.org/jira/browse/MYFACES-1246?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12475580 ] Dennis Byrne commented on MYFACES-1246: --- Thanks Bernd, Hi Paul, Paul, I plan on diving into this for the weekend. Thanks for the information but I'm not sure what you're saying. Are you saying I should not bother implementing this for the sake of passing J2EE TCK? Ultimately I think we can all agree MyFaces should have this functionality w/ or w/out a full container. Please give me any info you can ASAP in order to avoid unnecessary work. JSR-252 Issue #119: implementations running in a JSR-250 container have their managed bean methods annotated with @PostConstruct be called after the object is instantiated, and after injection is performed, but before the bean is placed into scope. Key: MYFACES-1246 URL: https://issues.apache.org/jira/browse/MYFACES-1246 Project: MyFaces Core Issue Type: New Feature Components: JSR-252 Reporter: Stan Silvert Assigned To: Dennis Byrne Specified that implementations running in a JSR-250 compliant container have their managed bean methods annotated with @PostConstruct be called after the object is instantiated, and after injection is performed, but before the bean is placed into scope. Specified that methods annotated with @PreDestroy be called when the scope for the bean is ending. See https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=252 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (MYFACES-1246) JSR-252 Issue #119: implementations running in a JSR-250 container have their managed bean methods annotated with @PostConstruct be called after the object is instanti
[ https://issues.apache.org/jira/browse/MYFACES-1246?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12475593 ] Dennis Byrne commented on MYFACES-1246: --- Well, I appreciate the help but I'd like to nail this one for all environments. I've got a few unit tests running for @PC and I don't think it should be too much. Once again, thanks. And feel free to help this way. You can never have enough info. JSR-252 Issue #119: implementations running in a JSR-250 container have their managed bean methods annotated with @PostConstruct be called after the object is instantiated, and after injection is performed, but before the bean is placed into scope. Key: MYFACES-1246 URL: https://issues.apache.org/jira/browse/MYFACES-1246 Project: MyFaces Core Issue Type: New Feature Components: JSR-252 Reporter: Stan Silvert Assigned To: Dennis Byrne Specified that implementations running in a JSR-250 compliant container have their managed bean methods annotated with @PostConstruct be called after the object is instantiated, and after injection is performed, but before the bean is placed into scope. Specified that methods annotated with @PreDestroy be called when the scope for the bean is ending. See https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=252 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [jira] Created: (MYFACES-1539) Replaced _link_hidden with idcl
This also makes it easier for application developers to run external performance/quality tools against applications built with either JSF implementation. We are of course gaining this at the expense of backwards compatibility. Dennis Byrne On 2/22/07, Martin Marinschek (JIRA) dev@myfaces.apache.org wrote: Replaced _link_hidden with idcl --- Key: MYFACES-1539 URL: https://issues.apache.org/jira/browse/MYFACES-1539 Project: MyFaces Core Issue Type: Improvement Affects Versions: 1.1.4 Reporter: Martin Marinschek Assigned To: Martin Marinschek Fix For: 1.1.5 In the MyFaces-generated JavaScript for links, the parameter for saving the id of the link has been changed from: _link_hidden to _idcl This was necessary to increase compatibility with the RI 1.1 - without the change, t:commanLink elements wouldn't work with the RI. Please change your javascript-code accordingly, if you program against this implementation dependent parameter. regards, Martin -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. -- Dennis Byrne
Re: MyFaces Fusion
snip Some of us reviewed it (offlist) and we came to the conclusion that it has enough power to live as separate project. /snip my understanding is that we all should at least have been involved in this discussion. hard to be a healthy community, when three or four do offline development. To me to that is against a key of apache-style projects. I agree. I like the idea, but perhaps in future, please send out an email. I bet that won't hurt. We discussed that already back 2006, when sb. did an alien commit for the stuff of Ernst Thanks, Matthias On 2/22/07, Mario Ivankovits [EMAIL PROTECTED] wrote: Hi! MyFaces Fusion is just a collection of already existing myfaces sandbox components. The main goal of this project is to ease the development of JSF applications especially if they have to deal with an ORM backend. I tried to do so a while back by developing a ConversationTag, which worked not that bad, but I was told that such a logic should not be put into the view. And well, the feeling was that it would be nice if it could be easier to deal with conversation. Spring allowed us to create a custom scope AND to reuse the well known way how it deal with persistence. So I've rewritten the ConversationTag to use Spring and first tests were really nice. No need to learn any new programming style, just code as before. Some of us reviewed it (offlist) and we came to the conclusion that it has enough power to live as separate project. Thats why I created the initial structure - not really new code, just taken from the sandbox. I know, I didnt use the svn cp command, but, since ALL of this code has been developed by me and there is not much value in the current history, I did it the easier way. Sorry for this. The current structure is divided into core and core15. The core part contains the ConversationTag and the RequestParameterProvider. In contrast to the tomahawk-sandbox ConversationTag the conversation tag now works using Spring and a custom scope. The RequestParameterProvider is used to allow multiple open windows within the same session. So e.g. I you have a order processing system you can open it twice and work in two independed conversations (even if their names are the same) The core15 part contains the DynaForm from tomahawk-sandbox15 It will create parts of the view automatically based on EJB3 annotated beans. Its migth become a great time-saver for simple tables. The current check-in do not bulid usable jars, some maven/tld/xml stuff has to be put in line, I hope to manage to do so in the next few hours. In the next few days I'll commit a sample application (given that you do not cancel my efforts), afterwards the documentation has to be done. The status of this project is sandbox like. Ciao, Mario -- Matthias Wessendorf http://tinyurl.com/fmywh further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com -- Dennis Byrne
Re: Incorrect versions for MyFaces on http://www.apache.org/dev/crypto.html
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: [VOTE] MyFaces Core 1.1.5
+1 (binding) Dennis Byrne On 2/14/07, Manfred Geiler [EMAIL PROTECTED] wrote: Hi all, This is the official vote for MyFaces Core 1.1.5. Please note that this vote concerns all of the following parts: 1. Maven artifact group org.apache.myfaces.maven v1.0.5 [1] 2. Maven artifact group org.apache.myfaces.shared v2.0.5 [1] 3. Maven artifact group org.apache.myfaces.core v1.1.5 [1] 4. MyFaces Core Assembly [2] 5. Proposed Release Announcement [3] [1] http://people.apache.org/builds/myfaces/m2-staging-repository/ [2] http://people.apache.org/builds/myfaces/core-1.1.5/ [3] http://wiki.apache.org/myfaces/CoreRelease115#releasenotes --Manfred -- Dennis Byrne
Re: WAP components issue
Kevin, Your best bet on getting a discussion going on these questions is to ask them on users@myfaces.apache.org mailing list. Thanks, Dennis Byrne On 2/15/07, kevin wu [EMAIL PROTECTED] wrote: Are there mature JSF WAP components in MyFaces or the other JSF implements? Where can I find them? -- Dennis Byrne
Re: [jira] Resolved: (TOMAHAWK-597) Client Side Validation Support
Nice job Cagatay! Dennis Byrne On 2/7/07, Cagatay Civici (JIRA) dev@myfaces.apache.org wrote: [ https://issues.apache.org/jira/browse/TOMAHAWK-597?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel] Cagatay Civici resolved TOMAHAWK-597. - Resolution: Fixed Fix Version/s: 1.1.5-SNAPSHOT Core infrastructure added to sandbox Client Side Validation Support -- Key: TOMAHAWK-597 URL: https://issues.apache.org/jira/browse/TOMAHAWK-597 Project: MyFaces Tomahawk Issue Type: New Feature Affects Versions: 1.1.4-SNAPSHOT Reporter: Cagatay Civici Assigned To: Cagatay Civici Fix For: 1.1.5-SNAPSHOT Initially client side validation will be enabled at sandbox. The design is discussed and agreed as; http://www.nabble.com/Client-Validation-Design-Discussion-tf1930173.html#a5286457 . -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. -- Dennis Byrne
Re: saveState will cause memory leak?
Dellee , Please ask these questions on the users@myfaces.apache.org mailing list. Thanks, Dennis Byrne On 2/7/07, Dellee [EMAIL PROTECTED] wrote: Hi all, I am new to myFaces and I think a little bit confusing on the saveState option. When using the saveState, will it keep referencing the beans that it pointed to ? if yes, will this cause a memory leak coz the pointed bean should be died and GC after the server method finished. However, as someone is pointing to it (by saveState), so it still alive and won't be collected when GC start. what do u think ? am i mis-understanding something ? Thanks for any help! Dell -- View this message in context: http://www.nabble.com/saveState-will-cause-memory-leak--tf3185987.html#a8842756 Sent from the My Faces - Dev mailing list archive at Nabble.com. -- Dennis Byrne
Re: Question regarding adding a new verification task
You may want to let this do the work for you. http://svn.apache.org/viewvc/myfaces/shared/trunk/core/src/test/java/org/apache/myfaces/shared/taglib/UIComponentTagUtilsTest.java?view=log Dennis Byrne On 2/6/07, Werner Punz [EMAIL PROTECTED] wrote: Hi Since I am currently working on fixing a lot of missing references in the sandbox Taglib classes. (Some people including me used a lot of includes from entities resulting in several missing attribute implementations) I am going to write, since this seems to be the most obvious way, a program which checks the generated component tlds via introspection against the taglib classes for those references. If anyone is willing, to integrate it into maven once I am done please drop a note here. Otherwise is there maybe already a check in maven which does this test? Tomcat is unable to check it as it seems, although I turned on tldValidation it did not report errors which were there. Also most other app server skip it, but weblogic does not and it is correct that it does not skip it. -- Dennis Byrne
Re: Question regarding adding a new verification task
You may want to let this do the work for you. http://svn.apache.org/viewvc/myfaces/shared/trunk/core/src/test/java/org/apache/myfaces/shared/taglib/UIComponentTagUtilsTest.java?view=log Dennis Byrne On 2/6/07, Martin Marinschek [EMAIL PROTECTED] wrote: There was someone who wrote an automatic test to check for this - I don't remember who and when that was, though. Can you have a look into the test directories and check? Maybe you can extend one of the test-classes instead of writing a new utility? regards, Martin On 2/6/07, Werner Punz [EMAIL PROTECTED] wrote: Hi Since I am currently working on fixing a lot of missing references in the sandbox Taglib classes. (Some people including me used a lot of includes from entities resulting in several missing attribute implementations) I am going to write, since this seems to be the most obvious way, a program which checks the generated component tlds via introspection against the taglib classes for those references. If anyone is willing, to integrate it into maven once I am done please drop a note here. Otherwise is there maybe already a check in maven which does this test? Tomcat is unable to check it as it seems, although I turned on tldValidation it did not report errors which were there. Also most other app server skip it, but weblogic does not and it is correct that it does not skip it. -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces -- Dennis Byrne
Re: Question regarding adding a new verification task
When it came time to commit it, including the sandbox wasn't realistic. There were a lot of failures. Dennis Byrne On 2/6/07, Paul Spencer [EMAIL PROTECTED] wrote: I believe this is what Martin is referring to the Tomahawk test MyFacesTagLibTestCase[1]. BTW: It looks like the verification of the sandbox taglibs was commented out. Paul Spencer [1]http://svn.apache.org/viewvc/myfaces/tomahawk/trunk/core/src/test/java/org/apache/myfaces/test/MyFacesTagLibTestCase.java?view=markup Martin Marinschek wrote: There was someone who wrote an automatic test to check for this - I don't remember who and when that was, though. Can you have a look into the test directories and check? Maybe you can extend one of the test-classes instead of writing a new utility? regards, Martin On 2/6/07, Werner Punz [EMAIL PROTECTED] wrote: Hi Since I am currently working on fixing a lot of missing references in the sandbox Taglib classes. (Some people including me used a lot of includes from entities resulting in several missing attribute implementations) I am going to write, since this seems to be the most obvious way, a program which checks the generated component tlds via introspection against the taglib classes for those references. If anyone is willing, to integrate it into maven once I am done please drop a note here. Otherwise is there maybe already a check in maven which does this test? Tomcat is unable to check it as it seems, although I turned on tldValidation it did not report errors which were there. Also most other app server skip it, but weblogic does not and it is correct that it does not skip it. -- Dennis Byrne
Re: Question regarding adding a new verification task
Oops, I meant this. http://svn.apache.org/viewvc/myfaces/tomahawk/trunk/core/src/test/java/org/apache/myfaces/test/AbstractTagLibTestCase.java?revision=491515view=markup Dennis Byrne On 2/6/07, Dennis Byrne [EMAIL PROTECTED] wrote: You may want to let this do the work for you. http://svn.apache.org/viewvc/myfaces/shared/trunk/core/src/test/java/org/apache/myfaces/shared/taglib/UIComponentTagUtilsTest.java?view=log Dennis Byrne On 2/6/07, Werner Punz [EMAIL PROTECTED] wrote: Hi Since I am currently working on fixing a lot of missing references in the sandbox Taglib classes. (Some people including me used a lot of includes from entities resulting in several missing attribute implementations) I am going to write, since this seems to be the most obvious way, a program which checks the generated component tlds via introspection against the taglib classes for those references. If anyone is willing, to integrate it into maven once I am done please drop a note here. Otherwise is there maybe already a check in maven which does this test? Tomcat is unable to check it as it seems, although I turned on tldValidation it did not report errors which were there. Also most other app server skip it, but weblogic does not and it is correct that it does not skip it. -- Dennis Byrne -- Dennis Byrne
Re: Question regarding adding a new verification task
Hi Werner, Glad to help. Please take the time to vote for getting this feature into the Shale test framework. https://issues.apache.org/struts/browse/SHALE-382 Dennis Byrne On 2/6/07, Werner Punz [EMAIL PROTECTED] wrote: Ok guys, especially Dennis and Martin thanks to you I finally could nail down and fix or mark the missing attributes. The sandbox now should work in way more containers than it used to (commit follows in a few minutes) Werner Werner Punz schrieb: Thanks a lot Dennis this was exactly what I was looking for! Dennis Byrne schrieb: You may want to let this do the work for you. http://svn.apache.org/viewvc/myfaces/shared/trunk/core/src/test/java/org/apache/myfaces/shared/taglib/UIComponentTagUtilsTest.java?view=log http://svn.apache.org/viewvc/myfaces/shared/trunk/core/src/test/java/org/apache/myfaces/shared/taglib/UIComponentTagUtilsTest.java?view=log Dennis Byrne On 2/6/07, *Werner Punz* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Hi Since I am currently working on fixing a lot of missing references in the sandbox Taglib classes. (Some people including me used a lot of includes from entities resulting in several missing attribute implementations) I am going to write, since this seems to be the most obvious way, a program which checks the generated component tlds via introspection against the taglib classes for those references. If anyone is willing, to integrate it into maven once I am done please drop a note here. Otherwise is there maybe already a check in maven which does this test? Tomcat is unable to check it as it seems, although I turned on tldValidation it did not report errors which were there. Also most other app server skip it, but weblogic does not and it is correct that it does not skip it. -- Dennis Byrne -- Dennis Byrne
