Re: [VOTE] Moving the Sling Management Console to Apache Felix
+1 On 5/7/08 1:04 PM, Felix Meschberger [EMAIL PROTECTED] wrote: Hi all, After an initial round of discussion and letting it almost be forgotten, we should finally start to get this moving again. As noted in [1] the incubating Apache Sling project has a module - a single bundle - which provides a Web Based Management Console. The base bundle allows mainly for OSGi management such as bundle lifecycle management, configuration, etc. But the console is in fact extensible and more functionality may easily be plugged into it. Members of the Felix and Sling community met at ApacheCon in Amsterdam and and came to the conclusion, that the Apache Felix project would be the natural location for such a management console. Mainly because people looking for OSGi stuff would turn to Felix and not primarily to Sling. There is no release yet of the Sling Management Console and there are a number of open issues [2], which should be fixed/implemented before a first release of the console. Nevertheless the console is already usable in its current state and therefore, I think we may just move it as is and finish it in Apache Felix. So here is the vote. As always, it will be open for 72 hours and only votes of Sling PPMC members are binding (though anybody is cordially invited to vote): [+1] Yes, move the Management Console to Apache Felix [0] Don't care [-1] No, keep it in Sling Regards Felix PS: A paralell vote has been started on the Felix Dev list [3] to ask whether Felix would be willing to take over the console. [1] http://markmail.org/message/tizwcfggwcrnngei [2] http://issues.apache.org/jira/browse/SLING/component/12312091 [3] http://markmail.org/message/ex6wjqowp7psomv4
Re: Support for invoking methods in scripts
The script engine merely executes some chunk of script code with a given context. It has access to the execution context and should be able to call other scripts. Thus you could have scripts which call other scripts which in turn contain any function one wants. So support for script libraries should be supported. Yours, Paddy Sent via BlackBerry by ATT -Original Message- From: Felix Meschberger [EMAIL PROTECTED] Date: Mon, 10 Mar 2008 14:08:30 To:sling-dev@incubator.apache.org Subject: Re: Support for invoking methods in scripts Hi all, Am Montag, den 10.03.2008, 09:39 +0100 schrieb Carsten Ziegeler: Bertrand Delacretaz wrote: Hi Carsten, On Wed, Mar 5, 2008 at 3:23 PM, Carsten Ziegeler [EMAIL PROTECTED] wrote: ...If you think of scripting parts of your application it might be useful to group several methods into one script (for instance a javascript script) and execute exactly one method out of this script Sounds interesting, but can you give an example of how that would be used? Sure :) For instance if you want to script server side form validation or script some rule processing for business logic or script a workflow step etc. I think to support this we just need some minor changes: a) the eval method of the SlingScript needs a return value (Object) The ScriptEngine.eval method already is defined to return an Object. We just would have to forward this value. b) We need a convention to pass the method name and the method parameters to the script engine c) Check for the new info mentioned in b) and if available don't execute the whole script, but just the single method. The problem with calling a method (or function) is that there will probably not be a script file to be compiled and a method called on it but rather some already existing functions or objects in the ScriptEngine scope on which we call a function or method Probably we need to enter the arena of direct ScriptEngine use here ?? I am not in favor of defining special hacks into e.g. the SlingBindings object to support this. Regards Felix
[jira] Resolved: (SLING-169) Update jackrabbit references to 1.4
[ https://issues.apache.org/jira/browse/SLING-169?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Padraic Hannon resolved SLING-169. -- Resolution: Fixed Fix Version/s: 2.0.0 Checked in with revision 612985 Update jackrabbit references to 1.4 --- Key: SLING-169 URL: https://issues.apache.org/jira/browse/SLING-169 Project: Sling Issue Type: Improvement Components: Core Affects Versions: 2.0.0 Reporter: Padraic Hannon Assignee: Padraic Hannon Fix For: 2.0.0 Attachments: sling-jackrabbit-1.4.patch Now that jackrabbit has released the 1.4 version we should update references within sling to 1.4 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (SLING-169) Update jackrabbit references to 1.4
Update jackrabbit references to 1.4 --- Key: SLING-169 URL: https://issues.apache.org/jira/browse/SLING-169 Project: Sling Issue Type: Improvement Components: Core Affects Versions: 2.0.0 Reporter: Padraic Hannon Now that jackrabbit has released the 1.4 version we should update references within sling to 1.4 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SLING-169) Update jackrabbit references to 1.4
[ https://issues.apache.org/jira/browse/SLING-169?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Padraic Hannon updated SLING-169: - Attachment: sling-jackrabbit-1.4.patch Here is a patch to upgrade pom and readme files. Update jackrabbit references to 1.4 --- Key: SLING-169 URL: https://issues.apache.org/jira/browse/SLING-169 Project: Sling Issue Type: Improvement Components: Core Affects Versions: 2.0.0 Reporter: Padraic Hannon Attachments: sling-jackrabbit-1.4.patch Now that jackrabbit has released the 1.4 version we should update references within sling to 1.4 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: GHOP issue 2: Design two related logos for the sling project
I don't feel I have the graphics expertise to comment, although, I cannot help myself from doing so ;-). For reasons that I cannot rightly explain, except to say simplicity perhaps, I like the third treatment with the sling pill thingy next to it. The Green box ones are cool, sort of like one of those long skinny rubicks things that where popular in the 80s. -paddy On Jan 13, 2008, at 11:54 PM, Bertrand Delacretaz wrote: Hi Paul, Thanks very much for your proposals! Notes on http://bitliquid.com/private/sling.jpg (please use a different filename if you create new variants, so that we know which is which): On the first variant, the stylized feathers looks a bit like bananas to me ;-) And anyway, to answer your question, I think we have to use the official feather in the design. My favorite variant is the second one, where you improve on the existing logo. I like the left one with the turquoise color, although it needs something to separate the S from the top line better, IMHO. It has kind of a vintage look that I like very much. ...(my personal favourite is the bottom set... The green translucent shape is very nice, but IMHO this logo has much less unity that the second variant - it looks to me as an assembly of things instead of one thing. Note that we now write microsling as µsling with a greek mu letter. Let's hear what others think (and let's hope we don't get 6 different opinions from 5 people ;-) -Bertrand
Re: HTTP caching (Was: json export: recursive by default)
Bascially, you would want a resource to be able to let a caller know if it is stale? -paddy On Jan 10, 2008, at 12:44 AM, Felix Meschberger wrote: Hi, Am Donnerstag, den 10.01.2008, 03:02 +0200 schrieb Jukka Zitting: Which brings me to my followup point: How does Sling support HTTP caching? Is there something we should do to improve that? As a RESTful web framework, Sling should IMHO have built-in support for things like ETags, Expiration headers, 304 responses, etc. Currently Sling has nothing in it. But since this issue has been brought up in the Sling BOF in Atlanta, we certainly will have to think about, how we could provide support for that. But for the moment, there is no concept around yet (hint hint :-) ). Maybe something around the Resource interface along the lines of how Excalibur [1] does it ? Regards Felix [1] http://excalibur.apache.org/apidocs/org/apache/excalibur/source/SourceValidity.html
Re: Sling Application Development
I'll put something in the whiteboard area. Basically, I wanted to make a sample app that used some of the new concepts and also demonstrated how resources can be shared (along with their ocm mappings) across multiple bundles since I think this may be a common use case. -paddy On Jan 9, 2008, at 2:16 AM, Bertrand Delacretaz wrote: Hi Paddy, On Jan 9, 2008 2:21 AM, Padraic Hannon [EMAIL PROTECTED] wrote: ...So far we have a pretty strong link between Content and a Component (at least expressed by the documentation) Those interfaces are gone, replaced (in a different way) by Resource and Servlet. I think http://incubator.apache.org/sling/site/request-processing.html is very much out of date, do we want to remove it temporarily, or at least add a big warning at the top? ...What I'd like to look at is reusing content across multiple components and have that content mapped to the correct object model... Not sure if I understand the mapped to the correct object model part, but I'll be looking forward to your sample! Commit early, commit often! (maybe to http://svn.apache.org/repos/asf/incubator/sling/whiteboard/ first) -Bertrand
Re: json export: recursive by default
I think the use case approach is the best way to unpack this. As such it seems we have been discussing three use cases: 1 Display a node and its properties 2 Display a node, its properties, and its children 3 Display a node its properties, and the full structure underneath it If those are the use cases then I think the first one is the most basic case and should be the default, the other two should require some sort of addition to the URI. On the other hand, I guess, the discussion boils down to how we perceive the json request. Are we asking to serialize an object graph? If so then we should dump the whole thing. I am not sure, however, if I am comfortable with that given the potential consequences of dumping tons of data. Going back the the filesystem analogy given this structure: / /foo /foo/child1 /bar /bar/child2 When I ask to list / I do not get a recursive listing unless I explicitly ask for it. Using the use cases above how would we expect request calls to work? What should the URIs look like? I think I agree with Toby that UC1 and UC2 should be collapsed so that a request for / foo would return foo's attributes plus list foo's child node names. A request for /foo.recurse would return /foo + all its children their properties their children, and so on... With those two types of request one could fulfill the browsing and the dump models Toby described. I also agree that these should be done with selectors and not query params as it makes caching much easier. -paddy On Jan 9, 2008, at 1:01 PM, Tobias Bocanegra wrote: Why not: /stuff.json?depth=1 It's not like we need to use the URI mapping for everything. because this breaks caching. however, i think there are actually 2 use cases. the first is that you need the deep serialization of a tree, e.g. a page, or an exploded xml, or a dialog node structure description in this case you always want a depth=infinity. the other one is the 'browsing' use case where you only need the node and it's properties (and the names of the childnodes!). so this is a special case anyways. this would be like depth=0.5 :-) so is there really a use case for depth=0 (i.e. node+properties) ? or is depth=0 just the node name, depth=1 the node name and it's properties and it's childnode names? etc. ? regards, toby -- - [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 ---
Re: New Comitter and PPMC member
Thanks Felix, for those that don't know me, I currently run the website development team at Edmunds.com in Santa Monica, California (rough place to work ;-). I've been doing web site development for about twelve years or so and have focused mainly on the middle and back-end tiers. However, since coming to Edmunds (and becoming a manager) I have had to take on everything from HTML down to the DB and have been working a lot with my team on moving farther into the front end with javascript coding with ajax and whatnot. We have been a Day client for a few years now and are running a bunch of our site on CQ4.1. When I met Felix and he described Sling I became very excited about the possibilities, I have become a firm believer in the JCR model and look forward to helping in whatever way I can with building out this content centric approach as I feel that it offers a tremendous opportunity for the end developer. -paddy On Jan 8, 2008, at 12:13 AM, Felix Meschberger wrote: Hi, Please welcome Paddy Hannon as a new committer and PPMC member of the Apache Sling project. The Sling PPMC recently voted to grant committership to Paddy and he accepted the nomination. The related administrational work is currently being taken care of. Paddy, welcome to the team! Regards Felix
Sling Scripting, again
I'd like to update the various ScriptEngineFactories so that they provide their services via osgi. This way the registration of factories can be done via standard osgi bundle activation. This would allow the default script resolver to access Freemarker and the other engines, and could be used for microSling as well. WDYT? paddy
Re: Sling Scripting, again
I guess the current bundles are accessible to the DefaultSlingScript resolver (assuming they are active and an entry for META-INF/services/ javax.script.ScriptEngineFactory), I was thinking that it might be nice to have their packages exported rather than remain private. I guess, though, then people might start using them without going through the script resolver... -paddy On Jan 8, 2008, at 12:02 PM, Padraic Hannon wrote: I'd like to update the various ScriptEngineFactories so that they provide their services via osgi. This way the registration of factories can be done via standard osgi bundle activation. This would allow the default script resolver to access Freemarker and the other engines, and could be used for microSling as well. WDYT? paddy
Sling Application Development
So I've worked on various aspects of sling and written a component here and there, however, I'd like to work on a more complete example (perhaps this would go towards some of the documentation we have said is needed) and am stumbling. So far we have a pretty strong link between Content and a Component (at least expressed by the documentation). What I'd like to look at is reusing content across multiple components and have that content mapped to the correct object model. I am going to start building a sample over the next few days and will document the architecture, however, I wanted to check with everyone to see if there where any pre-existing ideas on what the best pattern for this would be. -paddy
Re: Rethinking Exceptions in Sling
I agree with Alex, if there is an exception case that we expect either the SlingServlet or other code to handle then having a typed exception such as HttpStatusCodeException makes sense. In general I guess status codes could be done by setting the response status and we could assume that the main servlet would handle this by checking the response code. I guess it depends on if you see a non-200 code as an exception or just normal. While writing this I think I have changed my mind and am less inclined to want a specific exception, however, I would not want to set a request attribute since there is a mechanism using the response code. -paddy On Jan 2, 2008, at 3:25 AM, Alexander Saar wrote: Hi all, Felix Meschberger schrieb: Hi, Am Montag, den 31.12.2007, 12:37 +0100 schrieb Carsten Ziegeler: +1 for the proposal in general and I think we should drop the HttpStatusCodeException as it seems a little bit wired to transfer a status code by throwing an exception. And to expect that someone will pick it up and do the appropriate thing. Agreed, that it is somewhat weired and strange. The idea is, that the sling main servlet which is called to start the Sling request processing is catching the SlingException (and its extensions) and handle it appropriately. I think this is not a bad solution, as it provides a simple way to propagate errors to the Sling main servlet which in turn is responsible for calling the error handler (correct me if I'm wrong, I'm new to the project and code base). Another solution could be to have additional request attributes that indicate errors occured previously in the request processing. But I aggree with the statement that this will lead to some ugly code for checking existence of such attributes in order to cancel further request processing. Regarding the HttpStatusCodeException: The question is (as mentioned in Alex blog post) if there is something you can do in reaction of an exception case that reflects your error model. If so IMHO there should be a special exception for that case. If not the HttpStatusCodeException is in my eyes is an appropriate solution, because it describes the error model of the protocol that is used between server and client so the error handler can communicate the right error to the client. Regards, Alex
Re: Everything is a Resource
I can see where you are going with this, however, in my mind there is one key piece of functionality that Nodes do not provide which is the adaptTo method. The adaptTo method would allow a resource to be implemented and respond to many different Node types. I guess, however, that this adaptable interface could be built into the OCM layer? I re-read your post linked below, could you go into more detail on your proposal? -paddy On Jan 2, 2008, at 1:39 AM, Jukka Zitting wrote: Hi, On Dec 29, 2007 9:51 PM, Felix Meschberger [EMAIL PROTECTED] wrote: After the recent thread on scripting everything and some off-line discussions around this matter, I come to the conclusion, that it is about time to introduce the Sling Paradigm: Everything is a Resource If Sling would be enhanced to make the ResourceResolver more flexibel and powerful by the addition of ResourceProvider instances to define a virtual resource tree accessible (and iterable) through the ResourceResolver, we can make Sling much more scriptable than it is today. Re-raising my earlier concern: To me it seems like the Resource interface, as currently envisioned, might well end up growing to a mini-Node abstraction by time. [1] Along those lines, my counter-proposal would be to use special sling:servlet and sling:filter nodes for configuring and accessing such resources, sticking with the Everything is Content paradigm. :-) [1] http://markmail.org/message/nmpzkpqtznd5cosv BR, Jukka Zitting
Re: Everything is a Resource
Do you think we could treat the script engines as resources as well? I'm thinking if so we could have resource bundles (stored in jcr) to provide scripting providers. The providers would still conform to the jcr spec, however, they would be loaded via the jcr using the resource locator mechanism you describe on the wiki page. -paddy
Re: Rethinking Exceptions in Sling
Got it, that makes sense as a RuntimeException. -paddy On Dec 29, 2007, at 12:13 PM, Felix Meschberger wrote: Hi, Well, the HttpStatusCodeException is a usefull tool to provide an error code to the client of the request and quickly abort request processing. Otherwise more or less complicated code would have to be implemented to terminate a request - esp. in the case of included requests - after the sendError call. Therefore, making it a RuntimeException (a SlingException that is) would help have the exception pass through all the way up and have the Sling main servlet do the sendError call and terminate the request. I agree, that the HttpStatusCodeException is kind of weird. But because IOExceptions are generally caught, logged and further ignored, the goal of that exception would most probably almost never be met, if it would be an IOException (or whatever checked Exception). Of course, we could just as well drop that exception... Regards Felix Am Samstag, den 29.12.2007, 12:06 -0800 schrieb Padraic Hannon: I agree with the points in your wiki post. One thing I didn't exactly follow is what you want to do with the HttpStatusCodeException as that seems to fit into the contingency camp of exceptions. I think you want to make those extend IOException and thus not be a runtime exception? I am unsure about the parent class, but I do agree that probably should not be a Runtime exception since it is something that a program would care about. -paddy On Dec 29, 2007, at 11:58 AM, Felix Meschberger wrote: Hi all, Prompted by a blog by Alexander Klimetschek [1] and a very interesting paper on exceptions [2] I set back to think about the exceptions in the Sling API and wrote a wiki page on this subject [3]. To summarize, we should make the SlingException a RuntimeException and all exceptions defined in the Sling API extend SlingException. Together with appropriate catching inside Sling itself (letting RuntimeExceptions pass through generally) this should help us streamline exception handling. A prototype API definition may be found in the whiteboard at [4]. What do you think ? Regards Felix [1] http://weblogs.goshaky.com/weblogs/alexkli/entry/exception_best_practices [2] http://dev2dev.bea.com/pub/a/2006/11/effective-exceptions.html [3] http://cwiki.apache.org/SLING/effective-exceptions.html [4] http://svn.apache.org/repos/asf/incubator/sling/whiteboard/fmeschbe/effective_exceptions
Re: [RT] Shall we merge microsling into Sling?
So for a microsling application project one would just use a different configuration for the DefaultServlet? Could this be handled via resource types? Using something like a microsling base node type for application resources (this just popped into my head and could be silly)? Integrating WebDAV as a bundle would be nice to have in general, all in all this sounds like a nice direction that would simplify explaining what is going on and allow for a more focused development effort as it seems that people tend to work on sling or microsling then they are faced with porting that into the other project. -paddy On Dec 17, 2007, at 3:02 PM, Felix Meschberger wrote: Hi, Agreed. About the only two differences I actually see between Sling and microsling are: * Full-Blown and powerfull DefaultServlet (ujax amongst other things) * very simple setup/startup The first issue may probably easily be ported to Sling in a separate DefaultServelt project. The basis for a flexible DefaultServlet is provided by ServletResolver of the sling/core project. The second issue is actually not really a big one: The launcher folder contains two projects app and webapp. The app project is a project setup to launch Sling from the command line. This may easily be extended to include all required bundles to run Sling (or a minimal subset). The launcher/webapp project is just an extension of the launcher/app project wrapping it in a web application archive instead of a standalone application. I think, for a quick 15minutes test, a standalone java application packed in a single exectuable JAR file is much easier to use than a web application ... So, basically, all is there in Sling to build such a thing. ... The only thing missing is WebDAV: I think, if we could integrate this also as a Bundle, we could have a single application jar file being able to launch Sling with a repo and WebDAV and initial content if requireed etc. WDYT ? Regards Felix Am Montag, den 17.12.2007, 10:33 +0100 schrieb Bertrand Delacretaz: Hi, I think microsling is now ready to become just a specific configuration of Sling. That would save us the extra work (and potential community fragmentation) (and user indecision) (and fuzzy marketing message) that comes with having two similar-but-still-different codebases. I'm pretty sure we can graft the microsling stuff on Sling as a set of OSGi bundles, without requiring any OSGi knowledge from beginners, and keep microsling's ease of use, all of microsling's current features, and the testable in 15 minutes from scratch requirement. Empowering users to jump from simple microsling scripted stuff to full-blown OSGi-based java modules, within the same framework and webapp, sounds quite exciting to me. WDYT? -Bertrand, operating in Monday Morning's Wild Thinking Mode ;-)
[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_12548023 ] hannonpi edited comment on SLING-110 at 12/3/07 2:36 PM: --- A few questions: 1) Why not have bindings implement the scripting bindings interface? 2) was (Author: hannonpi): Looks good, can we get the patch applied? Or does it need more work? Are there other sling apis that need updating for this change? 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, SLING-110_api.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.
[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_12548023 ] hannonpi edited comment on SLING-110 at 12/3/07 2:38 PM: --- A few questions/comments: * Drop dependency on BSF in the API ** Does this mean that you want to remove the ScriptEngineManager instance from the ScriptResolver classes? * Rename ScriptBindings to SlingBindings and extend HashMapString, Object instead of implementing Java Scripting Bindings. ** I do not understand why we do not want have the binding class implement the scripting bindings interface? * Remove getReader method from SlingScript interface, as it is not externally used ** Makes sense was (Author: hannonpi): A few questions: 1) Why not have bindings implement the scripting bindings interface? 2) 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, SLING-110_api.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
Hey guys, From Edmunds perspective the ability to keep compiled pages around is extremely important. When under load we have seen our application servers freeze when forced to compile pages. To overcome this in our traditional applications we now pre-compile all JSPs, place the classes in the EAR classpath (under APP-INF/classes) and remove the raw JSP files from the EAR. For CQ4 we also precompile JSPs and load their classes into the repository. While compilation for a single JSP is quick when one is faced with concurrent requests which cause compilation one runs into issues with CPU load (which is already high in a CMS backed application). I think that it is extremely important to ensure we keep the ability to pre-compile and store JSP class files in the repository so that we do not have to compile them on the fly while serving traffic. -paddy On Nov 28, 2007, at 12:47 AM, David Nuescheler wrote: Hi Bertrand, ...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? Definitely. Especially for larger projects, some real-life projects run with hundreds (if not thousands) of jsps, which used to be a huge overhead to compile. how much of that is better now using a different compiler and how much really was a jasper performance issue to begin with I don't really know. 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 am scared of everything that we don't put into the repository considering clustering and backup/restore issues. I recall that we basically went to hell and back for everything that we did not put into the repository, so please be very careful with that. Now for certain intermediary files that may not be an issue, I just would like to be very, very careful. ...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. I think we are looking for an additional abstraction when it comes to the place where we store the resulting servlet source, right? Well, let's see if we can come up with a good patch that is convincing and non-intrusive to allow our abstraction into Jasper. regards, david .ps: Is it correct that we don't have an issue actually compiling the classes into the repository (and also classload them from the repository), our issue would the transpilation to the servlet java source, right? (or did Jasper remove that intermediary step while I was asleep for a bunch of years ;))
[jira] Updated: (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:all-tabpanel ] Padraic Hannon updated SLING-110: - Attachment: bsf.patch This patch introduces eval(Map) to SlingScript and updates the MicroslingScriptResolver to call eval() on the script. Notes: 1) The MicroSlingScriptResolver still calls setEngine() on the script to give it a script engine. 2) The MicroSlingScript class calls ScriptEngine.eval() takes the output and dumps it to the RESPONSE passed into the eval call via the RESPONSE property. 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.
[jira] Updated: (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:all-tabpanel ] Padraic Hannon updated SLING-110: - Attachment: (was: bsf.patch) 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 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.
[jira] Updated: (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:all-tabpanel ] Padraic Hannon updated SLING-110: - Attachment: (was: bsf.patch) 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 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.
[jira] Updated: (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:all-tabpanel ] Padraic Hannon updated SLING-110: - Attachment: bsf.patch This now does (per Felix's suggestion) the following: * MicroslingScript's eval method creates a ScriptContext and sets the writer for that context * The microsling script then calls eval(getScriptReader(), context) on the script engine * The script engines now return null and write directly to the set writer 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.
[jira] Commented: (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_12546379 ] Padraic Hannon commented on SLING-110: -- Sure -- Not sent from my iPhone 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.
[jira] Updated: (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:all-tabpanel ] Padraic Hannon updated SLING-110: - Comment: was deleted 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.
[jira] Commented: (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_12546403 ] Padraic Hannon commented on SLING-110: -- Looking at the impl for MicroSlingScript it seems that the reader is fairly complex to create. Is there a use case for the Sling API where an outside party would be interested in getting the script's value as a Reader? It seems you are suggesting not, but I want to make sure. 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.
[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.
[jira] Created: (SLING-110) Update Script System to be JSR-223 Compatible
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 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.
[jira] Commented: (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_12545550 ] 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. Also, I still have SlingScript having a getScriptEngine() method which I would like to remove. 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. 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 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.
[jira] Updated: (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:all-tabpanel ] Padraic Hannon updated SLING-110: - Attachment: bsf.patch Here is a patch, it is a first pass, and I think more refactoring is needed. 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.
[jira] Updated: (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:all-tabpanel ] Padraic Hannon updated SLING-110: - Attachment: bsf.patch Updated to remove SlingScriptEninge interface 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.
[jira] Updated: (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:all-tabpanel ] Padraic Hannon updated SLING-110: - Attachment: (was: bsf.patch) 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.
[jira] Commented: (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 ] Padraic Hannon commented on SLING-110: -- 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.
[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_12545667 ] hannonpi edited comment on SLING-110 at 11/26/07 5:18 PM: Updated to remove SlingScriptEninge interface. Note the patch was created at the root level of the sling project. was (Author: hannonpi): Updated to remove SlingScriptEninge interface 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: Sling API: Hanlding non-existing resources in ResourceResolver
Sounds good to me, I never like throwing an exception if something cannot be found, as that seems to be a normal state when looking things up. -paddy On Nov 1, 2007, at 5:53 AM, Carsten Ziegeler wrote: Felix Meschberger wrote: Hi all, Currently the ResourceResolver.resolve(ServletRequest request) method throws a ResourceNotFoundException if the request cannot be resolved to a resource. This makes it virtually impossible to easily and transparently handle requests for resource creation. This in fact is also an overseen difference between microsling and Sling: microsling is built around accepting missing resources while Sling throws 404 unconditionally if a request cannot be resolved to a resource. This prevents applications trying to create resources. As a fix I propose the introduction of a new special resource type sling:nonexisting, which is to be used by the ResourceResolver.resolve method to create a pseudo-Resource from the request path (rawData and object are both null). This may then be used to create the resource, such as in the DefaultSlingServlet. (The nice thing about the sling:nonexisting resource type is, that of course scripts may be created to handle respective methods for these types). Consquences in the API: The methods of the ResourceResolver and ResourceManager interfaces throwing a ResourceNotFoundException are modified to return null if a Resource cannot be found (except the resolve method which always returns a Resource instance, with the sling:nonexisting resource type in the case of nonexisting resources). And of course the ResourceNodeFoundException is dropped as it is not needed any more. I will modify the API to reflect this proposal. WDYT ? +1 :) Carsten -- Carsten Ziegeler [EMAIL PROTECTED]
Re: Script engines as plugins?
Perhaps then the servlet init method is best. I would rather edit the web.xml than re-compile the script engine and all of the plugin mechanism seem to overblown for what microsling is tackling. -paddy On Oct 31, 2007, at 12:18 PM, Felix Meschberger wrote: Hi, Am Mittwoch, den 31.10.2007, 15:37 +0100 schrieb David Nuescheler: maybe thats a stupid idea and i am not sure if i even want to bring up this option ;) : This idea is probably not stupid at all, but not appropriate for microsling, maybe. (3) how about using the workspace itself as an extension mechanism... something like: /.microsling/script-engines/esp /.microsling/script-engines/fm /.microsling/script-engines/rb ... which would host all the mapping information also allow for dynamic extension and distribution/installation as a content package. Sounds really easy, but has some implications which make it inappropriate for microsling (keep in mind that microsling stands for small, limited, easy to understand, quick to fire-up): It needs class loader trickery as either the libraries are loaded through a JCR ClassLoader or are copied to some filesystem location to try to load them from there. Second phase is then update: What happens if a library is updated or removed in the repository ? So, I would say, that for microsling, we should not use this. Regards Felix
Re: [RT] ScriptResolver
I think that folks at this point tend to frown on using servlets for rendering. JSP, Velocity, and Freemarker (perhaps ESP ;-) are better suited for that. Pure servlets, imho, should be used for front controllers and other such applications but should not do any display rendering. -paddy On Oct 31, 2007, at 2:32 PM, Lars Trieloff wrote: Hi Felix, I see scripts mainly as a mechanism to express rendering/behavior and servlets serve the same purpose, so from my level of abstraction, there is no conceptual difference. Lars Am 31.10.2007 um 22:27 schrieb Felix Meschberger: Hi Lars, Am Mittwoch, den 31.10.2007, 22:01 +0100 schrieb Lars Trieloff: Is there a conceptual difference between servlets and scripts? Yes and no :-) On the one hand scripts are just a special case of servlets. But then scripts are loaded differently that servlets. Servlets are registered with the ServletResolver (either manually as in microsling or through the OSGi service registry as in Sling) while scripts are dynamically resolved. So, this is how the ServletResolver works: 1. Find a servlet for the resource type 2. Find a script for the request (mostly by the resource type again) (this step delegates to the ScriptResolver) 3. Fall back to the default servlet So, any solution involving the ServletResolver is inherently more powerful than solutions limited to involve the ScriptResolver only. In fact, we should not directly use the ScriptResolver and leave this to the ServletResolver. Regards Felix
[jira] Updated: (SLING-87) Add Freemarker Scripting Support
[ https://issues.apache.org/jira/browse/SLING-87?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Padraic Hannon updated SLING-87: Attachment: freemarker.patch This patch is a simple freemarker script engine. Add Freemarker Scripting Support Key: SLING-87 URL: https://issues.apache.org/jira/browse/SLING-87 Project: Sling Issue Type: New Feature Components: microsling Affects Versions: 2.0.0 Reporter: Padraic Hannon Attachments: freemarker.patch Add freemarker scripting support to microsling using the scriptengine interface. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SLING-87) Add Freemarker Scripting Support
[ https://issues.apache.org/jira/browse/SLING-87?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Padraic Hannon updated SLING-87: Attachment: freemarker.patch Add Freemarker Scripting Support Key: SLING-87 URL: https://issues.apache.org/jira/browse/SLING-87 Project: Sling Issue Type: New Feature Components: microsling Affects Versions: 2.0.0 Reporter: Padraic Hannon Attachments: freemarker.patch Add freemarker scripting support to microsling using the scriptengine interface. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
