Re: [tiger] speedup of startup and extension to view annotation
Hi Craig! 1) Speedup of startup ... because it expects the developer to have a fairly complete understanding of all the classes in every jar, even if you got it from a third party. oh yes, right you are So the syntax of the configuration should be somehow different: classes=org.any.faces.beans,super-3rdparty.jar=*,myapp.jar=com.company.faces.backings,com.company.faces2.backings,mapp2.jar= etc That way you do not need to know much about super-3rdparty.jar, just that it might contain beans. And notice, you do not need to configure it, if there is no configuration you do not need to take this burden, just the current behavior apply. If the class is ultimately used later, one could argue that cost is worth the price, But you might have only a handful beans compared to the number of classes you find in the jars. If you know the package you can decrease the number of scanned classes. It might well be a nice addition to a commons project, but I'm getting allergic to increasing the number of dependencies. Indeed, I'd rather focus on decreasing them :-). Yea, same old story ... all the time ... we create reusable code, but don't want to depend on it :-( 2) extension to @View annotation This seems like a good idea. ... Maybe something like the way that LifecycleListener transparently delegates toi LifecycleListener2 could be added to the default mapper implementation. Ok, I'll have a look at it that way. Ciao, Mario
Re: [tiger] speedup of startup and extension to view annotation
On 9/28/06, Mario Ivankovits [EMAIL PROTECTED] wrote: Hi Craig! 1) Speedup of startup ... because it expects the developer to have a fairly complete understanding of all the classes in every jar, even if you got it from a third party. oh yes, right you are So the syntax of the configuration should be somehow different: classes=org.any.faces.beans,super-3rdparty.jar=*, myapp.jar=com.company.faces.backings,com.company.faces2.backings, mapp2.jar= etc That way you do not need to know much about super-3rdparty.jar, just that it might contain beans. And notice, you do not need to configure it, if there is no configuration you do not need to take this burden, just the current behavior apply. See my response on your JIRA issue ... if the developer *does* include this context init parameter, then it seem that we would have to analyze *all* JARs in WEB-INF/lib, even those that are pretty much guaranteed *not* to have anytihing relevant (such as Hibernate and all of its dependencies). From my viewpoint, implementing this approach seems like a net loss in performance (for the normal use cases), rather than a gain. If the class is ultimately used later, one could argue that cost is worth the price, But you might have only a handful beans compared to the number of classes you find in the jars. If you know the package you can decrease the number of scanned classes. Doesn't matter ... the key to improving performance is minimizing the list of classes you ever look at in the first place (and therefore have to load into memory in the JVM). If you explicitly specify that any class in com.mycompany.mypackage.mybeans might include annotated beans, then you are implicitly requiring Shale to check for such classes in *all* jars included in the webapp ... even if they came from something like Hibernate. It might well be a nice addition to a commons project, but I'm getting allergic to increasing the number of dependencies. Indeed, I'd rather focus on decreasing them :-). Yea, same old story ... all the time ... we create reusable code, but don't want to depend on it :-( 2) extension to @View annotation This seems like a good idea. ... Maybe something like the way that LifecycleListener transparently delegates toi LifecycleListener2 could be added to the default mapper implementation. Ok, I'll have a look at it that way. Ciao, Mario Craig
Re: [tiger] speedup of startup and extension to view annotation
Hi Craig! 1) Speedup of startup See my response on your JIRA issue ... The JIRA issue and this topic are two completely different things. Please take a look at the patch and you'll see. if the developer *does* include this context init parameter, then it seem that we would have to analyze *all* JARs in WEB-INF/lib, No. You can get access to a package listing by. * converting the class name to a path name: org.apache.shale = org/apache/shale * then use classLoader.getResources(path) then you'll get a list of urls where you can get a directory listing of (even if within an jar) * then convert the directory listing back to class names * scan the classes you are done ... You do NOT have to scan all classes. Thats the point. Ciao, Mario
Re: [PROPOSAL] Migrate Dialog2 Support From Sandbox To Framework
+1 -- James Mitchell 678.910.8017 On Sep 28, 2006, at 9:41 PM, Craig McClanahan wrote: The work we've done on the dialog support in the sandbox is showing clear earmarks of success. We can now support 100% of the functionality that actually works in the original implementation, plus have addressed a number of outstanding bug and RFE issues (plus supported a few extra enhancements like programmatic starting of a dialog that were not explicitly mentioned in an issue). I think it is now time to incorporate the results of this effort back into the mainline trunk code. Specifically, I propose to do the following: * Eliminate the original org.apache.shale.dialog (and child packages) code from shale-core. Yes, this is pretty abrupt, but developers who only use the APIs we've exposed for application use will not be affected -- it only impacts those who are using APIs targeted for framework users, and those folks need to be more accomodating about API evolution. * Create new modules under frameworks as follows: - shale-dialog (copied from sandbox shale-dialog2 with package names (etc.) changed from org.apache.shale.dialog2 to org.apache.shale.dialog. - shale-dialog-basic (copied from sandbox shale-dialog2-legacy with packgae names (etc.) changed from org.apache.shale.dialog2.legacy to org.apache.shale.dialog.basic. - shale-dialog-scxml (copied from sandbox shale-dialog2-scxml with package names (etc.) changed from org.apache.shale.dialog2.scxml to org.apache.shale.dialog.scxml. * Update website content in a manner consistent with the refactoring proposal I just sent out. * If we accept the SCXML implementation, start a vote to accept Rahul as a Shale committer. As with the refactoring proposal, I've got some time available starting tomorrow night and through the weekend to devote to these changs, if there are no objections. Thoughts? Craig
Re: [PROPOSAL] Migrate Dialog2 Support From Sandbox To Framework
+1 On Sep 28, 2006, at 8:41 PM, Craig McClanahan wrote: The work we've done on the dialog support in the sandbox is showing clear earmarks of success. We can now support 100% of the functionality that actually works in the original implementation, plus have addressed a number of outstanding bug and RFE issues (plus supported a few extra enhancements like programmatic starting of a dialog that were not explicitly mentioned in an issue). I think it is now time to incorporate the results of this effort back into the mainline trunk code. Specifically, I propose to do the following: * Eliminate the original org.apache.shale.dialog (and child packages) code from shale-core. Yes, this is pretty abrupt, but developers who only use the APIs we've exposed for application use will not be affected -- it only impacts those who are using APIs targeted for framework users, and those folks need to be more accomodating about API evolution. * Create new modules under frameworks as follows: - shale-dialog (copied from sandbox shale-dialog2 with package names (etc.) changed from org.apache.shale.dialog2 to org.apache.shale.dialog. - shale-dialog-basic (copied from sandbox shale-dialog2-legacy with packgae names (etc.) changed from org.apache.shale.dialog2.legacy to org.apache.shale.dialog.basic. - shale-dialog-scxml (copied from sandbox shale-dialog2-scxml with package names (etc.) changed from org.apache.shale.dialog2.scxml to org.apache.shale.dialog.scxml. * Update website content in a manner consistent with the refactoring proposal I just sent out. * If we accept the SCXML implementation, start a vote to accept Rahul as a Shale committer. As with the refactoring proposal, I've got some time available starting tomorrow night and through the weekend to devote to these changs, if there are no objections. Thoughts? Craig
Re: [jira] Commented: (SHALE-295) collect web archives with explicit configured faces-config.xml pointing to them
On 9/29/06, Mario Ivankovits [EMAIL PROTECTED] wrote: Hi Craig! Ok, lets concentrate only on the patch. Please, forget the discussion about speedup, this has nothing to do with the patch. I do not want to overload CONFIG_FILES nor change its meaning. Say you have a web.xml with the following configuration: javax.faces.CONFIG_FILES=/content/app/conf/faces-config.xml ,/content/app2/conf/faces-config.xml OK, so lets continue the twenty questions game for a minute, and ask, why would you have a faces-config.xml file nested like this? JSF is going to ignore it as well. The whole point of the META-INF convention in the spec is so that you do not have to explicitly configure things like this. Second thing to note is that the spec defines this context init parameter as defining *context-relative* resource paths to faces-config.xml resources, not to classpath resources inside a JAR. Any application that relies on the latter (which I assume the MyFaces impl must be supporting?) is not going to be portable. Craig The first faces-config.xml is located in myapp.jar and the second one is located in myapp2.jar. Both jars do NOT have a META-INF/faces-config.xml due to the use of javax.faces.CONFIG_FILES shale-tiger ignores those jars due to this fact. The patch do nothing else than to lookup those jars and add them to the list of webArchives. Just for safety I changed the List to a TreeSet. It is possible that such a jar contains a META-INF/faces-config.xml and also some additional special config.xml pointing to with javax.faces.CONFIG_FILES. To not parse them twice is the reason why I changed it to a Set. You see, no special tricks with javax.faces.CONFIG_FILES, nor any other style of class scanning. Ciao, Mario
Re: [jira] Commented: (SHALE-295) collect web archives with explicit configured faces-config.xml pointing to them
On 9/29/06, Mario Ivankovits [EMAIL PROTECTED] wrote: Hi Craig, or should I say - good morning :-) Yep, at the moment :-). javax.faces.CONFIG_FILES=/content/app/conf/faces-config.xml ,/content/app2/conf/faces-config.xml OK, so lets continue the twenty questions game for a minute, and ask, why would you have a faces-config.xml file nested like this? JSF is going to ignore it as well. Why will JSF ignore it? I dont understand what you mean. (I checked the JSR-RI source, please read on) Our application works using such a configuration like a charme. We use the myfaces JSF impl, but as far as I remember, this worked with JSF-RI too. See below. The whole point of the META-INF convention in the spec is so that you do not have to explicitly configure things like this. Yes, I know this, but we decided to use the javax.faces.CONFIG_FILES way. I think I was assuming from your description that the actual faces-config.xml file was buried inside a JAR file inside WEB-INF/lib. If that's not the case, then the discussion below about whats supported is not relevant. One thing to note, however, is that if your faces-config.xml resource *is* a static resource under the content directory in your web application, then it is accessible to web clients that do a GET on the appropriate URL. Some people (including me :-) would consider this a security hole. Second thing to note is that the spec defines this context init parameter as defining *context-relative* resource paths to faces-config.xmlresources, not to classpath resources inside a JAR. I cant find a pointer to what you say about the spec, however, the way how your explicitResource() method works is the same as the one how myfaces lookup the faces-config.xml. The patch didn't change the way how to lookup resources pointed to by javax.faces.CONFIG_FILES. See Section 10.1.3, first bullet: javax.faces.CONFIG_FILES -- Comma-delimited list of context relative resource paths under which the JSF implementation will look for application configuration resources (see Section 10.4.3 Application Configuration Resource Format) before loading a configuration resource named /WEB-INF/faces-config.xml (if such a resource exists). The RI class that reads this init parameter ( com.sun.faces.config.ConfigureListener obeys this definition ... it treats all the paths as context relative, not class loader relative. Any application that relies on the latter (which I assume the MyFaces impl must be supporting?) is not going to be portable. I had a look at the JSF-RI impl, there you will find in ConfigureListener the method getContextURLForPath which will be used to lookup the configuration files configured in javax.faces.CONFIG_FILES. This method use ServletContext.getResource(path) - the same as shale-tiger use, and for sure myfaces-impl. Right. That looks for a static resource in the webapp, not a resource buried inside a JAR file,. because it uses ServletContext.getResource() instead of ClassLoader.getResource(). The two most important JSF implementations behaves the same way, also shale-tiger uses this strategy to lookup javax.faces.CONFIG_FILES configured faces-config.xml files. So my patch simply completes the webArchives lookup strategy. Ciao, Mario Craig
Re: [tiger] speedup of startup and extension to view annotation
Hi Craig! I wont leave this mailing list ;-) For the speedup thing (with a new context parameter) I'll try to implement my thoughts in LifecycleListener2 and create a simple benchmark. Then we will see if its worth it. Ciao, Mario
Re: [jira] Commented: (SHALE-295) collect web archives with explicit configured faces-config.xml pointing to them
On 9/29/06, Mario Ivankovits [EMAIL PROTECTED] wrote: Hi! I had a look at the JSF-RI impl, there you will find in ConfigureListener the method getContextURLForPath which will be used to lookup the configuration files configured in javax.faces.CONFIG_FILES. This method use ServletContext.getResource(path) - the same as shale-tiger use, and for sure myfaces-impl. Right. That looks for a static resource in the webapp, not a resource buried inside a JAR file,. because it uses ServletContext.getResource() instead of ClassLoader.getResource(). Ok, now I am a idiot :-) This is a perfect example of test your patch before post it ... Craig, please close this jira as invalid, it just wont work. Will do. You are right with this. Thanks for your patience, if it will ever happen you'll have two free beer (or three ;-) ) Be happy to raise up beers with you next time we're on the same continent :-). Craig Ciao, Mario
[tiger] speedup of startup [was: [tiger] speedup of startup and extension to view annotation]
Hi! For the speedup thing (with a new context parameter) I'll try to implement my thoughts in LifecycleListener2 and create a simple benchmark. Then we will see if its worth it. I created https://issues.apache.org/struts/browse/SHALE-301 with a first try to speedup startup times, so everyone can download it and give it a try. As written in the issue, if we would like to add it to the codebase, I'll do the test-case, documentation thing. Ciao, Mario
[dialog] 'data' instance variable
The code review tool flags the instance variable data (the dialog data) being declared as an Object, in relevant places in both the basic and scxml impl. While we do document the fact that dialog data should be Serializable, we do not enforce that in code. Any downside to changing the type of 'data' to Serializable? Also getting flagged for missing serialVersionUIDs, don't see them elsewhere either (except in clay). -Rahul
Re: [dialog] 'data' instance variable
On 9/29/06, Rahul Akolkar [EMAIL PROTECTED] wrote: The code review tool flags the instance variable data (the dialog data) being declared as an Object, in relevant places in both the basic and scxml impl. While we do document the fact that dialog data should be Serializable, we do not enforce that in code. Any downside to changing the type of 'data' to Serializable? This particular one is a case that I don't think we should necessarily enforce ... for example, if you run your app on a non-distributed version of Tomcat, and disable the ability to save and restore session state across app restarts, it will not matter that you've got non-serializable stuff here. Changing the type to Serializable would disallow this use case. Also getting flagged for missing serialVersionUIDs, don't see them elsewhere either (except in clay). For things we explicitly declare as serializable, we'll definitely want these. -Rahul Craig
