Re: Location of JSP Classes
Hi all, Am Dienstag, den 27.11.2007, 16:30 -0500 schrieb Carsten Ziegeler: > ... - Cannot easily upgrade to more recent Jasper versions... > >>> That's the killer IMO, the purpose of Sling is not to maintain a JSP > >>> compiler, so I'm all for using a standard version, and forget about > >>> having classes in the repository, at least for now. > >> i would not care. i reckon the changes are not very complicated and > >> can easily be reapplied to a new jasper version. > > > > Not really, unfortunately. In addition, no matter how simple the patches > > are, keeping up is simply not worth the effort with regard to required > > work time and stability (been there, done that :-) ) > > > Can't we just provide a patch to the Jasper project, so the changes will > be included in the next release? Ok, so I created a patch against Tomcat trunk (version 6) and submitted a Tomcat enhancment bug report [1]. Let's see :-) Regards Felix [1] http://issues.apache.org/bugzilla/show_bug.cgi?id=43979
[jira] Issue Comment Edited: (SLING-110) Update Script System to be JSR-223 Compatible
[ https://issues.apache.org/jira/browse/SLING-110?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12545668 ] hannonpi edited comment on SLING-110 at 11/27/07 4:10 PM: I am still unsure if I like the fact that SlingScript has a getScriptEngine() method, it seems that the script resolver should handle this. However, I am wary of introducing such a change as it feels like a very fundamental change. Also, depending on the progress of BSF I can remove some of our script engines as BSF engines come online. Note: I did update getScriptEngine() to return javax.script.ScriptEngine. was (Author: hannonpi): I am still unsure if I like the fact that SlingScript has a getScriptEngine() method, it seems that the script resolver should handle this. However, I am wary of introducing such a change as it feels like a very fundamental change. Also, depending on the progress of BSF I can remove some of our script engines as BSF engines come online. > Update Script System to be JSR-223 Compatible > -- > > Key: SLING-110 > URL: https://issues.apache.org/jira/browse/SLING-110 > Project: Sling > Issue Type: Improvement > Components: microsling, Scripting >Affects Versions: 2.0.0 >Reporter: Padraic Hannon > Attachments: bsf.patch > > > Currently sling and microsling use a custom scripting framework. This > framework should be updated to be jsr-223 compatible. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Location of JSP Classes
Felix Meschberger wrote: > Am Dienstag, den 27.11.2007, 12:18 +0100 schrieb Tobias Bocanegra: >>> In order to get rid of the patched copy of Jasper 5.5, I propose to not >>> store JSP transpilations and compilations in the repository anymore and >>> fall back to using standard Jasper. >> what about compiling in temp files and moving them afterwards in the >> repository ? >> i'm strongly against removing the class files from the repository. >> from my experience it is very valuable if you can remove the classes >> remotely. > > This is one of the problems we are considering to find a solution. But > as there are workarounds, this possibility by itself does not warrant > keeping the classes in the repository. > > Of course copying the classes to the repository after the fact, would be > one way to go. In fact inspecting the class files is far more valuable > than just being able to remove the class files. > ... - Cannot easily upgrade to more recent Jasper versions... >>> That's the killer IMO, the purpose of Sling is not to maintain a JSP >>> compiler, so I'm all for using a standard version, and forget about >>> having classes in the repository, at least for now. >> i would not care. i reckon the changes are not very complicated and >> can easily be reapplied to a new jasper version. > > Not really, unfortunately. In addition, no matter how simple the patches > are, keeping up is simply not worth the effort with regard to required > work time and stability (been there, done that :-) ) > Can't we just provide a patch to the Jasper project, so the changes will be included in the next release? Carsten -- Carsten Ziegeler [EMAIL PROTECTED]
Re: Location of JSP Classes
On Nov 27, 2007, at 5:30 AM, Felix Meschberger wrote: Hi, Am Dienstag, den 27.11.2007, 14:59 +0200 schrieb Jukka Zitting: What's the patched Jasper version/revision? It would help if we could see how extensive the Jasper changes are. The base version was 5.5.20. The changes involved touching quite a few classes. I'm sure Jasper has also some other use cases where it would be useful to customize how the transpilation results are stored. Not sure, at least given the response to my message to the tomcat list [1]. Assuming you mean http://markmail.org/message/3wzlksqjrfsv3pqc I don't think that qualifies as contributing the patches upstream. Let's start with a diff from the original and see if all of those changes are necessary. I think we may be starting with a solution to the wrong problem. The problem that our users care about is that the cached class files correspond to the currently active view, such that the class files are marked invalid (or replaced) when the corresponding source within JCR is changed. A bonus feature might be to store the class files within the repository such that that they don't need to be regenerated, but some customers (those without terabyte storage) might not want that feature or may want to limit it to a small set of recent versions. We should be able to do both with a filesystem cache that is specific to Jasper's class generation but with a layout that can be calculated or stored as a property within the JCR "page" hierarchy. We can then present a JCR interface to the pages such that the classes operate as an intermediate cache (mapped by JCR) rather than being stored within the repository itself. This should be a safe option given that we don't want the class files to be "authored" directly and we do have central control over their generation. OTOH, I don't have a problem with forking jasper provided that the forked copy is not mistaken for the Tomcat project's copy. That means moving it to a different class location (not org/apache/jasper) and documenting the tag or revision number for comparison to the originals. Tomcat is free to adopt those changes at a later date. Roy
[jira] Closed: (SLING-113) Script resolution should consider partial selector string
[ https://issues.apache.org/jira/browse/SLING-113?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Meschberger closed SLING-113. --- Resolution: Fixed Implemented in Rev. 598744. Additionaly using the method name instead of the extension for GET requests if there is no extension. > Script resolution should consider partial selector string > - > > Key: SLING-113 > URL: https://issues.apache.org/jira/browse/SLING-113 > Project: Sling > Issue Type: Improvement > Components: Core >Reporter: Felix Meschberger >Assignee: Felix Meschberger > Fix For: 2.0.0 > > > Currently the Sling DefaultSlingScriptResolver class only considers the full > selector string (if one is available) for finding a script. Actually, it > should gradually cut off elements from the selector string until a script is > found or the complete selector string has been cut off. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SLING-113) Script resolution should consider partial selector string
[ https://issues.apache.org/jira/browse/SLING-113?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Meschberger updated SLING-113: Component/s: Core > Script resolution should consider partial selector string > - > > Key: SLING-113 > URL: https://issues.apache.org/jira/browse/SLING-113 > Project: Sling > Issue Type: Improvement > Components: Core >Reporter: Felix Meschberger >Assignee: Felix Meschberger > Fix For: 2.0.0 > > > Currently the Sling DefaultSlingScriptResolver class only considers the full > selector string (if one is available) for finding a script. Actually, it > should gradually cut off elements from the selector string until a script is > found or the complete selector string has been cut off. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (SLING-113) Script resolution should consider partial selector string
Script resolution should consider partial selector string - Key: SLING-113 URL: https://issues.apache.org/jira/browse/SLING-113 Project: Sling Issue Type: Improvement Reporter: Felix Meschberger Assignee: Felix Meschberger Fix For: 2.0.0 Currently the Sling DefaultSlingScriptResolver class only considers the full selector string (if one is available) for finding a script. Actually, it should gradually cut off elements from the selector string until a script is found or the complete selector string has been cut off. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (SLING-48) wrong content classname in componen-nt definition
[ https://issues.apache.org/jira/browse/SLING-48?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Meschberger closed SLING-48. -- Resolution: Won't Fix Issue pertains to former Component API and has no correspondence with the new Sling API. Closing. > wrong content classname in componen-nt definition > - > > Key: SLING-48 > URL: https://issues.apache.org/jira/browse/SLING-48 > Project: Sling > Issue Type: Bug > Components: Core >Reporter: christian >Priority: Trivial > Attachments: sling-core-component-nt.patch > > > The cnd containes an inexisting class name in its contentClassNames > default-value. > Have a patch fixing it attached. > But, would suggest to remove it, as it mandates any sub-class to write the > property if it wants to use a different content class(-name). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (SLING-36) Repository Based components not cleaned up when not existing any longer
[ https://issues.apache.org/jira/browse/SLING-36?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Meschberger closed SLING-36. -- Resolution: Won't Fix Issue pertains to former Component API and has no correspondence with the new Sling API. Closing. > Repository Based components not cleaned up when not existing any longer > --- > > Key: SLING-36 > URL: https://issues.apache.org/jira/browse/SLING-36 > Project: Sling > Issue Type: Bug > Components: Core >Affects Versions: 2.0.0 >Reporter: Felix Meschberger >Priority: Critical > Fix For: 2.0.0 > > > The RepositoryComponentRegistration services access the JCR repository to see > whether there are any component descriptors stored in the repository and > updates the component registry in case of new, modified or removed components. > Unfortunately, this service does not pay attention to the fact, that a bundle > providing mappings for such components may be stopped, removed, added or > updated. In such cases the registered components are not touched and stay. In > fact new components will not be visible until after a restart of the > RepositoryComponentResgistration. > The registration of JCR based components must be modified to take into > account that OCM mappings for such components may be added and/or removed at > run time and that there is another influence on the state of registered > components than just the repository. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (SLING-5) More flexible Component selection mechanism
[
https://issues.apache.org/jira/browse/SLING-5?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Felix Meschberger closed SLING-5.
-
Resolution: Won't Fix
Issue pertains to former Component API and has no correspondence with the new
Sling API. Closing.
In fact the requirement has been sort-of implement by the
RequestDispatcherOptions of the Sling API.
> More flexible Component selection mechanism
> ---
>
> Key: SLING-5
> URL: https://issues.apache.org/jira/browse/SLING-5
> Project: Sling
> Issue Type: Improvement
> Components: Core
>Reporter: Bertrand Delacretaz
>
> In many cases, the rendering of a Content object depends on the "context" of
> the rendering, for example:
> -Printable version
> -Customized rendering for a specific client (mobile terminal, broken browser,
> etc)
> -Contextual navigation: render a Content node using a query to find its
> neighboring nodes
> From the taglib user's point of view, this could be done like:
>
> or
>
> where the selectors influence the choice of a suitable Component (the
> sling:include tag already exists, only the selectors attribute is new).
> Allowing additional OSGi plugins to participate in the Component selection
> would enable this, and enable custom Component selection mechanisms.
> A workaround is to use a wrapper class to force the rendering of a Content
> with a specific Component, but there must be a better way:
> class ContentWrapper implements Content {
> private final Content content;
> private final String componentId;
>
> ContentWrapper(Content c,String componentId) {
> this.content = c;
> this.componentId = componentId;
> }
>
> public String getComponentId() {
> return componentId;
> }
> public String getPath() {
> return content.getPath();
> }
>
> Content getWrappedContent() {
> return content;
> }
> }
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Closed: (SLING-1) Add functionality for "self rendering content"
[
https://issues.apache.org/jira/browse/SLING-1?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Felix Meschberger closed SLING-1.
-
Resolution: Won't Fix
This issue pertained to the former Component API which has been replaced by the
Sling API.
So there is no need for an implementation of this.
> Add functionality for "self rendering content"
> --
>
> Key: SLING-1
> URL: https://issues.apache.org/jira/browse/SLING-1
> Project: Sling
> Issue Type: New Feature
> Components: Content, Core
>Reporter: Philipp Koch
>
> it would be nice to have some kind of functionality that allows to define the
> rendering in the content class itself. there should be a component which
> would call the service(ComponentRequest request, ComponentResponse respone)
> method of the "to be rendered" content object. for that, i suggest:
> 1. public interface SelfRenderingContent {
> void service(org.apache.sling.component.ComponentRequest
> componentRequest, org.apache.sling.component.ComponentResponse
> componentResponse) throws org.apache.sling.component.ComponentException,
> java.io.IOException;
>}
> 2. a component that calls the service method of the content object (in case
> the content class implements the SelfRenderingContent ). it could look
> somehow like this:
> public class SelfRenderingContentComponent extends BaseComponent {
> void service(org.apache.sling.component.ComponentRequest
> componentRequest, org.apache.sling.component.ComponentResponse
> componentResponse) throws org.apache.sling.component.ComponentException,
> java.io.IOException {
> SelfRenderingContent content = (SelfRenderingContent )
> request.getContent();
> content.service(componentRequest, componentResponse);
> }
> }
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Closed: (SLING-100) Recognize tag library descriptor by extension
[ https://issues.apache.org/jira/browse/SLING-100?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Meschberger closed SLING-100. --- Resolution: Fixed Fixed as proposed in Rev. 598658. The JSP compiler now looks for all *.tld files within the META-INF folders of the bundles. > Recognize tag library descriptor by extension > - > > Key: SLING-100 > URL: https://issues.apache.org/jira/browse/SLING-100 > Project: Sling > Issue Type: Improvement > Components: JSP >Reporter: Marcel Reutegger >Assignee: Felix Meschberger >Priority: Minor > Attachments: SLING-100.patch > > > Currently TldLocationsCacheSupport only recognizes tag library descriptors > named taglib.tld. Using Bundle.findEntries() all descriptors with a .tld > extension can be loaded. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (SLING-111) Remove local Jasper copy and use standard Jasper
[ https://issues.apache.org/jira/browse/SLING-111?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Meschberger closed SLING-111. --- Resolution: Fixed Removed the Jasper source from the repository and adapted the JSP scripting support accordingly. This has the following consequences: * Java source and class files for JSP scripts are stored in the file system * Any resources used by the JSP compiler through the ServletContext of the compiler are accessed through the ResourceResolver of the request being processed. > Remove local Jasper copy and use standard Jasper > > > Key: SLING-111 > URL: https://issues.apache.org/jira/browse/SLING-111 > Project: Sling > Issue Type: Bug > Components: JSP >Reporter: Felix Meschberger >Assignee: Felix Meschberger > Fix For: 2.0.0 > > > Currently we have a local copy of Jasper 5.5 with patches to write Java > classes into the JCR repository in our source tree. This virtually prevents > us from keeping up to date with more recent versions of Jasper and also > duplicates code (from the original Jasper code). > Class need - for the moment - not be stored in the repository any more and so > we may remove the Jasper code and use the standard Jasper build to write the > classes to the local file system. > A canonical location for the classes must be found an documented. > [1] http://markmail.org/message/ud4tlcbm53bxj7vd -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (SLING-100) Recognize tag library descriptor by extension
[ https://issues.apache.org/jira/browse/SLING-100?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Meschberger reassigned SLING-100: --- Assignee: Felix Meschberger > Recognize tag library descriptor by extension > - > > Key: SLING-100 > URL: https://issues.apache.org/jira/browse/SLING-100 > Project: Sling > Issue Type: Improvement > Components: JSP >Reporter: Marcel Reutegger >Assignee: Felix Meschberger >Priority: Minor > Attachments: SLING-100.patch > > > Currently TldLocationsCacheSupport only recognizes tag library descriptors > named taglib.tld. Using Bundle.findEntries() all descriptors with a .tld > extension can be loaded. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Location of JSP Classes
Hi, Am Dienstag, den 27.11.2007, 14:59 +0200 schrieb Jukka Zitting: > What's the patched Jasper version/revision? It would help if we could > see how extensive the Jasper changes are. The base version was 5.5.20. The changes involved touching quite a few classes. > I'm sure Jasper has also some other use cases where it would be useful > to customize how the transpilation results are stored. Not sure, at least given the response to my message to the tomcat list [1]. Regards Felix
Re: Location of JSP Classes
Hi, What's the patched Jasper version/revision? It would help if we could see how extensive the Jasper changes are. I'm sure Jasper has also some other use cases where it would be useful to customize how the transpilation results are stored. BR, Jukka Zitting
Re: Location of JSP Classes
Am Dienstag, den 27.11.2007, 12:18 +0100 schrieb Tobias Bocanegra: > > In order to get rid of the patched copy of Jasper 5.5, I propose to not > > store JSP transpilations and compilations in the repository anymore and > > fall back to using standard Jasper. > > what about compiling in temp files and moving them afterwards in the > repository ? > i'm strongly against removing the class files from the repository. > from my experience it is very valuable if you can remove the classes > remotely. This is one of the problems we are considering to find a solution. But as there are workarounds, this possibility by itself does not warrant keeping the classes in the repository. Of course copying the classes to the repository after the fact, would be one way to go. In fact inspecting the class files is far more valuable than just being able to remove the class files. > > > > ... - Cannot easily upgrade to more recent Jasper versions... > > > > That's the killer IMO, the purpose of Sling is not to maintain a JSP > > compiler, so I'm all for using a standard version, and forget about > > having classes in the repository, at least for now. > > i would not care. i reckon the changes are not very complicated and > can easily be reapplied to a new jasper version. Not really, unfortunately. In addition, no matter how simple the patches are, keeping up is simply not worth the effort with regard to required work time and stability (been there, done that :-) ) Regards Felix
Re: Location of JSP Classes
On Nov 27, 2007 12:18 PM, Tobias Bocanegra <[EMAIL PROTECTED]> wrote: > ...i'm strongly against removing the class files from the repository. > from my experience it is very valuable if you can remove the classes > remotely Do you need to be able to remove individual class files from the repository? If you can live with a "delete all compiled JSP classes" function, we can probably find another solution, like a utility that can be called from a script to do that. Deleting JSPs is a development/debugging concern, having to call a script (via a URL) to do that is not harder than having to know where and when to delete stuff in the repository. > >...I'm all for using a standard version, and forget about > > having classes in the repository, at least for now. > > i would not care. i reckon the changes are not very complicated and > can easily be reapplied to a new jasper version Sure, but it's easy to lose track, and I don't think we have a comprehensive set of automated tests for Jasper. Besides, having our own fork of Jasper bloats Sling and might make people wary of why we have that - all kinds of warnings go off in my programming brain when I see a project doing this. -Bertrand
[jira] Resolved: (SLING-112) DefaultSlingServlet.spool sets content/unknown Content-Type for css and js files
[ https://issues.apache.org/jira/browse/SLING-112?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bertrand Delacretaz resolved SLING-112. --- Resolution: Fixed Fixed in revision 598596, corresponding integration test added. DefaultSlingServlet used URLConnection.getContentType(), which apparently doesn't know about js and css files (at least on my macosx/JDK1.5 system). Changed to use the servlet context to get the content type. > DefaultSlingServlet.spool sets content/unknown Content-Type for css and js > files > > > Key: SLING-112 > URL: https://issues.apache.org/jira/browse/SLING-112 > Project: Sling > Issue Type: Bug > Components: microsling >Reporter: Bertrand Delacretaz >Priority: Minor > > $ curl -D - http://localhost:8080/microsling.css > HTTP/1.1 200 OK > Content-Type: content/unknown > Content-Length: 676 > Last-Modified: Mon, 19 Nov 2007 15:11:45 GMT > Server: Jetty(6.1.5) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Location of JSP Classes
> In order to get rid of the patched copy of Jasper 5.5, I propose to not > store JSP transpilations and compilations in the repository anymore and > fall back to using standard Jasper. what about compiling in temp files and moving them afterwards in the repository ? i'm strongly against removing the class files from the repository. from my experience it is very valuable if you can remove the classes remotely. > > ... - Cannot easily upgrade to more recent Jasper versions... > > That's the killer IMO, the purpose of Sling is not to maintain a JSP > compiler, so I'm all for using a standard version, and forget about > having classes in the repository, at least for now. i would not care. i reckon the changes are not very complicated and can easily be reapplied to a new jasper version. -- -< [EMAIL PROTECTED] >--- Tobias Bocanegra, Day Management AG, Barfuesserplatz 6, CH - 4001 Basel T +41 61 226 98 98, F +41 61 226 98 97 ---< http://www.day.com >---
[jira] Created: (SLING-112) DefaultSlingServlet.spool sets content/unknown Content-Type for css and js files
DefaultSlingServlet.spool sets content/unknown Content-Type for css and js files Key: SLING-112 URL: https://issues.apache.org/jira/browse/SLING-112 Project: Sling Issue Type: Bug Components: microsling Reporter: Bertrand Delacretaz Priority: Minor $ curl -D - http://localhost:8080/microsling.css HTTP/1.1 200 OK Content-Type: content/unknown Content-Length: 676 Last-Modified: Mon, 19 Nov 2007 15:11:45 GMT Server: Jetty(6.1.5) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: microsling integration-test does not currently work
On Nov 26, 2007 6:38 PM, Bertrand Delacretaz <[EMAIL PROTECTED]> wrote: > ...Just noticed that "mvn integration-test" fails in microsling-core... Fixed in revision 598583 - that was simply the tests include/exclude paths that were wrong, adding a new package yesterday under "integration" made the integration tests run as part of the normal test cycle instead of the "integration-test" one. -Bertrand
[jira] Created: (SLING-111) Remove local Jasper copy and use standard Jasper
Remove local Jasper copy and use standard Jasper Key: SLING-111 URL: https://issues.apache.org/jira/browse/SLING-111 Project: Sling Issue Type: Bug Components: JSP Reporter: Felix Meschberger Assignee: Felix Meschberger Fix For: 2.0.0 Currently we have a local copy of Jasper 5.5 with patches to write Java classes into the JCR repository in our source tree. This virtually prevents us from keeping up to date with more recent versions of Jasper and also duplicates code (from the original Jasper code). Class need - for the moment - not be stored in the repository any more and so we may remove the Jasper code and use the standard Jasper build to write the classes to the local file system. A canonical location for the classes must be found an documented. [1] http://markmail.org/message/ud4tlcbm53bxj7vd -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Location of JSP Classes
On Nov 27, 2007 11:18 AM, Felix Meschberger <[EMAIL PROTECTED]> wrote: > Currently we have a patched Jasper 5.5 source tree in our SVN tree ... > ... - Cannot easily upgrade to more recent Jasper versions... That's the killer IMO, the purpose of Sling is not to maintain a JSP compiler, so I'm all for using a standard version, and forget about having classes in the repository, at least for now. We can always try to restart the discussions with the tomcat people (now that we had breakfast with one of them at ApacheCon ;-) if we need tighter integration with the repository at a later point. -Bertrand
Location of JSP Classes
Hi all, Prompted by Roy's remarks [1], Bertrand and I discussed whether we should drop storing JSP classes in the repository; at least for the moment. Currently we have a patched Jasper 5.5 source tree in our SVN tree to be able to write the class files (and intermediate Java and SMAP files) in the JCR repository. Heads off, these are the advantages and disadvantages of having the class files in the repository: + Inspect the transpiled Java source files through normal JCR repository access + Remove (Cleanup) old classfiles through JCR repository access + Distribute JSP class files only from development to runtime servers - Slight performance overhead - Cannot easily upgrade to more recent Jasper versions In order to get rid of the patched copy of Jasper 5.5, I propose to not store JSP transpilations and compilations in the repository anymore and fall back to using standard Jasper. I am currently working on the JSP compiler project and will therefore take this route for now. The patched Jasper code is not lost however and still exists in our SVN tree inside the Sling_Component_API branche and can be revived later. Regards Felix PS: Yes, I was not successfull up to now, trying to push the changes required to Jasper back into the Tomcat project. [1] http://www.mail-archive.com/sling-dev@incubator.apache.org/msg00987.html
Re: svn commit: r598331 [1/22] - in /incubator/sling/trunk/scripting/jsp: ./ src/main/java/org/apache/jasper/ src/main/java/org/apache/jasper/compiler/ src/main/java/org/apache/jasper/compiler/tagplug
Hi Roy, Yes, you are right, the only reason, why we have this in our repository is to hack the output stuff, such that the classes go into the repository. Unfortunately, there is no proper OOP way of doing this as part of it is hard coded into Jasper and other parts have not the correct visibility. I am as unhappy with this as you are. I am currently considering two options to fix this: (1) Not writing the classes to the repository at all. This way, we can just use plain Jasper with our own CompilationContext. This has the drawback that removing classes remotely is difficult (it is not required but very helpfull sometimes). (2) Copy the classes to the repository after successfull compilation to the file system. This gives us the support for remote class removal at the expense of having to copy them. Regards Felix Am Montag, den 26.11.2007, 14:44 -0800 schrieb Roy T. Fielding: > On Nov 26, 2007, at 8:15 AM, [EMAIL PROTECTED] wrote: > > SLING-98 Migrate JSP scripting support > > + plus include Jasper Compiler and EL implementation > > Ouch. Just out of curiosity, why do we need the source of jasper? > Is it to replace the back-end storage bits with JCR? Would it be > possible to use some OOP to override the specific storage classes > within jasper instead of building the entire tree? If not, then > I think we should rename jasper to sling/ssi4j (or something) to > avoid the library binding clashes. > > Roy
Re: [jira] Commented: (SLING-110) Update Script System to be JSR-223 Compatible
Hi, Thanks alot for this. I will shortly look into the patch. However, here are some first remarks: Am Montag, den 26.11.2007, 11:00 -0800 schrieb Padraic Hannon (JIRA): > Padraic Hannon commented on SLING-110: > -- > > Currently I have a version which looks ok using the BSF 3.0-SNAPSHOT. > However, I still have a custom SlingScriptEngine interface which I would like > to get rid of. +1 If we are going to using Java Scripting, SlingScriptEngine interface is not needed anymore and should be dropped. > Also, I still have SlingScript having a getScriptEngine() method which I > would like to remove. +1 If there is no SlingScriptEngine anymore, there is no getScriptEngine. I suggest, we add a method eval(Map props) which then calls into Java Scripting to evaluate the script and use the props as bound variables. This way, sling/microsling just calls Script.eval to call the script. WDYT ? > One thing I do not like about BSF and JSR-223 is that the eval returns an > object. I would much > rather eval to a writer and not load a string into memory just to flush out > the wire. Java Scripting is generic in that scripts may be used to calculate results. As such there must be the possibility to return a value. Generally we might want to ignore this value. The writer to be used by scripts for sending back the response is available as the "out" property in props. Hope this helps. Regards Felix
