Suns RI has been released under CDDL
I just wonder what this will mean for the myfaces core? http://www.theserverside.com/news/thread.tss?thread_id=36160 Werner
Re: Suns RI has been released under CDDL
Well, I am not a lawer and so I don't know the detailed difs between those both licences. But, I see no problem in having an open source RI -Matthias On 8/27/05, Werner Punz [EMAIL PROTECTED] wrote: I just wonder what this will mean for the myfaces core? http://www.theserverside.com/news/thread.tss?thread_id=36160 Werner -- Matthias Wessendorf Zülpicher Wall 12, 239 50674 Köln
Re: Suns RI has been released under CDDL
On 8/27/05, Werner Punz [EMAIL PROTECTED] wrote: I hope it will make things easier, I do not know the CDDL but I assume it is some kind of LGPL derivate, :) think so too, but then ASF's jsf version is *free* 8-) but even if the myfaces people cannot take code directly from it, at least there now is a chance to check out the sources on how the RI does instead of having to go over the reverse engineering/blackbox testing way. well, on java.net there is allready the source available. So I don't see any news in this topic, perhaps only licencing stuff changed... Ideal would be if Sun could warm up to the idea to put the RI into something BSDish, sort of using an apache project as RI, just like they do it with Tomcat for the JSP/Servlet core of their stuff. Is Tomcat really the RI ? I think no. Its website states out: snip Apache Tomcat is the servlet container that is used in the official Reference Implementation for the Java Servlet and JavaServer Pages technologies. The Java Servlet and JavaServer Pages specifications are developed by Sun under the Java Community Process. /snip However, a BSDish RI stuff for JSF would be fine, yes! Matthias That model has worked the best for them in the past, and probably would work for JSF as well, having one project under the Apache Umbrella being the RI and also a good solid codebase where vendors can take over and other sideprojects can concentrate on the component sets and extension libs. But having it under the CDDL is at least a big improvement over the past of having the specs and a close sourced RI. Werner Matthias Wessendorf wrote: Well, I am not a lawer and so I don't know the detailed difs between those both licences. But, I see no problem in having an open source RI -Matthias On 8/27/05, Werner Punz [EMAIL PROTECTED] wrote: I just wonder what this will mean for the myfaces core? http://www.theserverside.com/news/thread.tss?thread_id=36160 Werner -- Matthias Wessendorf Zülpicher Wall 12, 239 50674 Köln
/WEB-INF/faces-config.xml gets loaded twice?
Hi, Has anyone else noticed that /WEB-INF/faces-config.xml gets parsed twice if the web DD has a context parameter that specifies /WEB-INF/faces-config.xml? Here is what I observed: if there is a PhaseListener declared in /WEB-INF/faces-config.xml like this lifecycle phase-listenerexample.MyPhaseListener/phase-listener /lifecycle And there is a context parameter declared in /WEB-INF/web.xml like this context-param param-namejavax.faces.CONFIG_FILES/param-name param-value /WEB-INF/faces-config.xml /param-value /context-param Then two instances of the MyPhaseListener get created and added to the FacesContext. Once I removed the context-param from /WEB-INF/web.xml, it worked as I expected: exactly one instance of MyPhaseListener was created. I took a look at the JIRA database, and didn't find anything about this, should I file a bug report? BTW, I discovered this while trying out an idea I had about using PhaseListener and an application scope bean to make a JSF managed-bean that manages Hibernate sessions. I've seen the Spring session-in-view stuff, and I wanted to see if it could be done more simply, as I don't want to add Spring to the test application I'm working with just yet. Is PhaseListener is the right 'JSF-ish' way to do such a thing? Thanks In Advance - Josh [EMAIL PROTECTED]
Re: /WEB-INF/faces-config.xml gets loaded twice?
This is not a bug - it works as intended. if you have a faces-config.xml in your WEB-INF directory, it will be found and parsed automatically by the framework. If you specify this very same file another time in the web.xml file - it will be parsed twice. so this is not a bug! regards, Martin On 8/27/05, Joshua Davis [EMAIL PROTECTED] wrote: Hi, Has anyone else noticed that /WEB-INF/faces-config.xml gets parsed twice if the web DD has a context parameter that specifies /WEB-INF/faces-config.xml? Here is what I observed: if there is a PhaseListener declared in /WEB-INF/faces-config.xml like this lifecycle phase-listenerexample.MyPhaseListener/phase-listener /lifecycle And there is a context parameter declared in /WEB-INF/web.xml like this context-param param-namejavax.faces.CONFIG_FILES/param-name param-value /WEB-INF/faces-config.xml /param-value /context-param Then two instances of the MyPhaseListener get created and added to the FacesContext. Once I removed the context-param from /WEB-INF/web.xml, it worked as I expected: exactly one instance of MyPhaseListener was created. I took a look at the JIRA database, and didn't find anything about this, should I file a bug report? BTW, I discovered this while trying out an idea I had about using PhaseListener and an application scope bean to make a JSF managed-bean that manages Hibernate sessions. I've seen the Spring session-in-view stuff, and I wanted to see if it could be done more simply, as I don't want to add Spring to the test application I'm working with just yet. Is PhaseListener is the right 'JSF-ish' way to do such a thing? Thanks In Advance - Josh [EMAIL PROTECTED] -- http://www.irian.at Your JSF powerhouse - JSF Trainings in English and German
RE: /WEB-INF/faces-config.xml gets loaded twice?
That's what I get for not reading the spec. ;) Section 10.1.3: javax.faces.CONFIG_FILES -- Comma-delimited list of context-relative resource paths under which the JSF implementation will look for application configuration resources before loading a configuration resource named /WEB-INF/faces-config. xml (if such a resource exists). -Original Message- From: Martin Marinschek [mailto:[EMAIL PROTECTED] Sent: Saturday, August 27, 2005 10:14 AM To: MyFaces Discussion Subject: Re: /WEB-INF/faces-config.xml gets loaded twice? if you have a faces-config.xml in your WEB-INF directory, it will be found and parsed automatically by the framework. If you specify this very same file another time in the web.xml file - it will be parsed twice.
Re: eclipse debugging problem :(
Hi Fabian, I am still on vacation and I I don't know how to debug myfaces with eclipse, but maybe someone on the list will tell :) Regards, Bruno 2005/8/22, Fab Psycho [EMAIL PROTECTED]: Hi Bruno, I'm back with some more trivial problem : I'd like to understand how inputDate works and see it through eclipse debugger. I already tried debugging from a project put in tomcat path having a breakpoint in my bean and it works but this time, I'd like to debug let's say through myfaces-simple-examples.war ... Is it possible to put a breakpoint in my svn myfaces/current project and launch a debug telling eclipse deployement path or something ? Best regards, Fabian
Re: Dealing with links/buttons to fire off an action? confusion on how to set this up
Thanks Brendan, the description of using t:saveState sounds great. I look forward to trying it out shortly.
I'm still a bit confused on how you deal with links that go to
backing bean methods for standard links/buttons. As an example, imagine
the header on a page [..]=links...
John Doe [edit user] [logs for user] [user summary] [look up company]
1455 some address [edit address]
Somewhere, state, 12456
The example above is a bit exaggerated, but the point is the links
would have to access methods in all different kinds of backing beans.
If I use commandLink for those links and provide f:param with the
appropriate vars, will the backing bean called automatically be
populated with those vars (assuming the backing bean has the same
matching member variables)? ( Similar to the same way in Struts calling
an action from a link with get params attached will populate the
backing ActionForm?) or do I need to manually pull these params from
the request?
Thanks for all your help.On 8/26/05, CONNER, BRENDAN (SBCSI) [EMAIL PROTECTED] wrote:
t:saveState is trivially simple to use, but it's a Godsend.
Wherever you want the state of a bean to be maintained across requests, just
declare the bean with request scope andput a t:saveSave
value=#{myBean} on the pages that use it. The bean's state will be
maintained until control reaches a page that doesn't have a t:saveState
declared for it, at which point it will go away
automatically.
So
wherever you need to maintain the state of a bean for more than one request (but
don't need it for the entire session), stick in a t:saveState tag for
all pages that use it, and you're set.
If you
do this, and you follow Mike Kienenberger's suggestion to access the DataModel
object that backs the dataTable component(illustrated in the O'Reilly book
JavaServer Faces, pp. 175 - 179), you're all set; you don't need to
pass any parameters through the request.
Using
the DataModel object also is explained in the book CoreJavaServer Faces
(Geary, Horstmann), pp. 185 - 201.
-
Brendan
-Original Message-From: Rick Reumann
[mailto:[EMAIL PROTECTED]] Sent: Friday, August 26, 2005 4:41
PMTo: MyFaces DiscussionSubject: Re: Dealing with
links/buttons to fire off an action? confusion on how to set this
up
On 8/26/05, CONNER,
BRENDAN (SBCSI) [EMAIL PROTECTED]
wrote:
However, I believe that,
using this mechanism, there's no real way to get around usingsomething
liket:saveState or having a session-scoped bean. Just
out of curiosity, what is the objection to using
t:saveState?
Well I haven't gotten that far in my learning to have touched
upon t:saveState. Was actually just more curious in general of how you deal
with cases where you would typically want to use requestParams attached to a
url link. -- Rick
-- Rick
Re: Suns RI has been released under CDDL
On 8/27/05, Werner Punz [EMAIL PROTECTED] wrote: I hope it will make things easier, I do not know the CDDL but I assume it is some kind of LGPL derivate, Not a good assumption. CDDL is broadly based on the Mozilla Public License, and has been approved by the OSI. but even if the myfaces people cannot take code directly from it, If the ASF Board deems the license compatible (on the agenda soon), that would indeed be possible, as would using code from it (or other CDDL projects -- this is the same license that Project Glassfish, the J2EE 1.4 app server, is under). at least there now is a chance to check out the sources on how the RI does instead of having to go over the reverse engineering/blackbox testing way. Ideal would be if Sun could warm up to the idea to put the RI into something BSDish, sort of using an apache project as RI, just like they do it with Tomcat for the JSP/Servlet core of their stuff. That model has worked the best for them in the past, and probably would work for JSF as well, having one project under the Apache Umbrella being the RI and also a good solid codebase where vendors can take over and other sideprojects can concentrate on the component sets and extension libs. But having it under the CDDL is at least a big improvement over the past of having the specs and a close sourced RI. CDDL *is* open source. It *can* be used freely (under the license terms, just ike anything else, but please read it before you make incorrect assumptions). It *is* being developed in an open project (at java.net). For the market as a whole, it just means there will be two open source impementations of the spec. Werner Craig
Re: Suns RI has been released under CDDL
Yes. more competition makes things better for the users ;) regards, Martin On 8/27/05, Craig McClanahan [EMAIL PROTECTED] wrote: On 8/27/05, Werner Punz [EMAIL PROTECTED] wrote: I hope it will make things easier, I do not know the CDDL but I assume it is some kind of LGPL derivate, Not a good assumption. CDDL is broadly based on the Mozilla Public License, and has been approved by the OSI. but even if the myfaces people cannot take code directly from it, If the ASF Board deems the license compatible (on the agenda soon), that would indeed be possible, as would using code from it (or other CDDL projects -- this is the same license that Project Glassfish, the J2EE 1.4 app server, is under). at least there now is a chance to check out the sources on how the RI does instead of having to go over the reverse engineering/blackbox testing way. Ideal would be if Sun could warm up to the idea to put the RI into something BSDish, sort of using an apache project as RI, just like they do it with Tomcat for the JSP/Servlet core of their stuff. That model has worked the best for them in the past, and probably would work for JSF as well, having one project under the Apache Umbrella being the RI and also a good solid codebase where vendors can take over and other sideprojects can concentrate on the component sets and extension libs. But having it under the CDDL is at least a big improvement over the past of having the specs and a close sourced RI. CDDL *is* open source. It *can* be used freely (under the license terms, just ike anything else, but please read it before you make incorrect assumptions). It *is* being developed in an open project (at java.net). For the market as a whole, it just means there will be two open source impementations of the spec. Werner Craig -- http://www.irian.at Your JSF powerhouse - JSF Trainings in English and German
Re: Suns RI has been released under CDDL
On 8/27/05, Matthias Wessendorf [EMAIL PROTECTED] wrote: On 8/27/05, Werner Punz [EMAIL PROTECTED] wrote: I hope it will make things easier, I do not know the CDDL but I assume it is some kind of LGPL derivate, :) think so too, but then ASF's jsf version is *free* 8-) but even if the myfaces people cannot take code directly from it, at least there now is a chance to check out the sources on how the RI does instead of having to go over the reverse engineering/blackbox testing way. well, on java.net there is allready the source available. So I don't see any news in this topic, perhaps only licencing stuff changed... That's correct ... same code, more liberal license. Ideal would be if Sun could warm up to the idea to put the RI into something BSDish, sort of using an apache project as RI, just like they do it with Tomcat for the JSP/Servlet core of their stuff. Is Tomcat really the RI ? I think no. Its website states out: snip Apache Tomcat is the servlet container that is used in the official Reference Implementation for the Java Servlet and JavaServer Pages technologies. The Java Servlet and JavaServer Pages specifications are developed by Sun under the Java Community Process. /snip Tomcat is often mis-characterized as the RI. Code from Tomcat is indeed *used* in the RI (which, for all the J2EE specs, is the J2EE SDK you can get from sun.com), and Tomcat itself has been tested with the TCKs for servlet and JSP, but it's not the RI. Craig
