[RT] docs should be in bundles
Hi, Considering we're aiming for individual release cycles for our bundles (or groups of bundles), I think the only sane way for docs to be in sync with the bundles is to have those docs *inside* the bundles. And maintain them alongside the source code. Bundle jars could store docs (in simple unstyled HTML or APT format) under /SLING-INF/docs for example, and a service would pick them up and dynamically assemble documentation pages for the current combination of bundles that is installed, available under /system/sling/docs. Doc paths from that page should be normalized to contain the bundle symbolic ID and version, for example /system/sling/docs/bundles/org.apache.sling.servlets.get/2.0.2/ And the same for javadocs, /system/sling/docs/javadocs/... This will make our bundles a bit larger (thought we don't have tons of docs ATM ;-), to get a feel I tried putting the javadocs and the current website pages that relate to the org.apache.sling.servlets.post bundle in a jar, resulting compressed size is 77kBytes, that's not too bad, though that bundle jar is currently 62kBytes, so including docs would more than double it. But the convenience trumps the size increase, IMO. And providing a tool, or build profile, that strips the docs from bundles is not hard. We might need some javadocs customization to create links to interfaces that are in different bundles, and I'm not sure how to handle the "2.0.2" version number in the above path for this. Maybe provide a "current" alias to this for such links, that redirects to the actual version being installed. The reference docs part of the website can then be generated by running Sling with the current set of bundles, and spidering the docs starting at /system/sling/docs. We can discuss the details of course, but WDYT about the general idea? -Bertrand
RE: sling - wicket integration?
Does this means that sling will tightly integrated or remain modular for use of other frameworks that may find sling useful? Ransford Segu-Baffoe paks...@yahoo.com http://www.noqmx.com/ https://serenade.dev.java.net/ --- On Tue, 3/31/09, Stefan Seifert wrote: From: Stefan Seifert Subject: RE: sling - wicket integration? To: "sling-dev@incubator.apache.org" Cc: "Martin Wehner" Date: Tuesday, March 31, 2009, 3:53 PM >And maybe asking the Wicket people what the best option would be would >be worth it? > >Asking how to run Wicket in an OSGi environment might raise their >interest, and the "Wicket takes over the request processing cycle >after Sling has selected content" integration that Dominik suggests >might be of general interest to them. btw - wicket 1.4rc2 ships already with OSGI bundle metadata included in the distribution jar. http://repo2.maven.org/maven2/org/apache/wicket/wicket/1.4-rc2/wicket-1.4-rc2.jar and there exists a OPS4J - Pax Wicket project with advanced osgi support inside wicket itself, with support to dynamically load and unload model parts at runtime without reloading the wicket application itself. http://www.ops4j.org/projects/pax/wicket/ but i think for the first steps we do not need this features, but will integrate wicket applications with the sling request processing and are happy to deploy the whole wicket application itself as osgi bundle into sling. as soon as we've a first proof of concept integration running, we will post it here and in the wicket mailing list as well, to see what the others are thinking. stefan
RE: sling - wicket integration?
>And maybe asking the Wicket people what the best option would be would >be worth it? > >Asking how to run Wicket in an OSGi environment might raise their >interest, and the "Wicket takes over the request processing cycle >after Sling has selected content" integration that Dominik suggests >might be of general interest to them. btw - wicket 1.4rc2 ships already with OSGI bundle metadata included in the distribution jar. http://repo2.maven.org/maven2/org/apache/wicket/wicket/1.4-rc2/wicket-1.4-rc2.jar and there exists a OPS4J - Pax Wicket project with advanced osgi support inside wicket itself, with support to dynamically load and unload model parts at runtime without reloading the wicket application itself. http://www.ops4j.org/projects/pax/wicket/ but i think for the first steps we do not need this features, but will integrate wicket applications with the sling request processing and are happy to deploy the whole wicket application itself as osgi bundle into sling. as soon as we've a first proof of concept integration running, we will post it here and in the wicket mailing list as well, to see what the others are thinking. stefan
Re: "mvn clean" should delete "sling" work folders
Yeah, that cost me a fair bit of time when I tried starting using Sling again last week. I patched launchpad/testing/pom.xml to clean some of the files in that sling folder, but I suspect the right thing is to delete the whole thing. https://issues.apache.org/jira/browse/SLING-900 Jim Carsten Ziegeler wrote: Bertrand Delacretaz wrote: Hi, I was bitten by this one again, trying to run Sling tests failed due to a stale "sling" work folder, or more precisely gave different results when run in the launchpad/testing folder vs. top of the source code tree. In my opinion, "mvn clean test" should have predictable results, without taking previous runs into account. Why did we move the "sling" folders from target/sling (where mvn clean kills them) to siblings of src folders? Is that on purpose, or a side effect of other changes? I'd move them back, if people agree - having non-repeatable "mvn clean test" cycles can be a big waste of people's time. Don't know why we moved them - When running "mvn clean install" from the root (multi project build) I even get a .sling folder in the root directory which is totally confusing. So big +1 to get this sorted out properly, which means create the folders in the modules they are created from under "target". Carsten
Re: sling-test.html fails
Bertrand Delacretaz wrote: Hi, On Sun, Mar 29, 2009 at 6:58 AM, Jim White wrote: The Sling client library test page (/sling-test/sling/sling-test.html) has an assertion that fails for me (fixing the clean build didn't fix this problem). assertNull failed: testRemoveContent: data should be gone after deletePath (/test-data/sling-test/testhtml-nodes/sling-test/testhtml-nodes/delete-1238302522312)... It works for me in the current trunk, did you change the default config according to this note at the top of the test page? "Note that, in Sling revision 669215, the tests fail unless the Allow Anonymous Access parameter of the Sling Request Authenticator component is set to false, see SLING-322." Yes. The error without Allow Anonymous Access occurs on the first Sling action with a different error code rather than this test which is about the last one. I just tried with my latest really squeaky clean build and all the tests pass now (both with and without Allow Anonymous Access). I suspect there are problems with the build and stale jar files beyond the one I fixed in SLING-900. Jim
Re: "mvn clean" should delete "sling" work folders
Bertrand Delacretaz wrote: > Hi, > > I was bitten by this one again, trying to run Sling tests failed due > to a stale "sling" work folder, or more precisely gave different > results when run in the launchpad/testing folder vs. top of the source > code tree. > > In my opinion, "mvn clean test" should have predictable results, > without taking previous runs into account. > > Why did we move the "sling" folders from target/sling (where mvn clean > kills them) to siblings of src folders? > Is that on purpose, or a side effect of other changes? > > I'd move them back, if people agree - having non-repeatable "mvn clean > test" cycles can be a big waste of people's time. > Don't know why we moved them - When running "mvn clean install" from the root (multi project build) I even get a .sling folder in the root directory which is totally confusing. So big +1 to get this sorted out properly, which means create the folders in the modules they are created from under "target". Carsten -- Carsten Ziegeler cziege...@apache.org
Re: Renaming SlingWebDavServlet? (was: SlingWebDavServlet serves resource not only below /dav?)
On Tue, Mar 31, 2009 at 4:46 PM, Carsten Ziegeler wrote: >> 2009/3/31 Bertrand Delacretaz >>> I agree that this can be confusing, do people agree about renaming the >>> Sling servlet, to SlingSimpleWebDavServlet, maybe? > ...I'm fine with the name change, but what is really the idea of having a > "Simple" in the name? Especially if this is the only implementation?... Right, should rather be SlingWebDavServlet then. -Bertrand
[jira] Commented: (SLING-788) Provide /etc/cron.d/ style approach to scripting timed events
[ https://issues.apache.org/jira/browse/SLING-788?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12694139#action_12694139 ] Bertrand Delacretaz commented on SLING-788: --- See http://markmail.org/message/easrhtpuexplezgb for discussion of user identities when running such scripts > Provide /etc/cron.d/ style approach to scripting timed events > - > > Key: SLING-788 > URL: https://issues.apache.org/jira/browse/SLING-788 > Project: Sling > Issue Type: New Feature > Components: Commons Scheduler, Scripting >Reporter: Lars Trieloff > > I would like to be able to script scheduled events in an easy fashion that > works just like the /etc/cron.d/ directory on my Linux server: I put a shell > script into /etc/cron.d/daily and it will get executed once a day. In Sling > terms this would mean having a node that takes nt:file scripts in any > scripting language supported by sling that is executed on hourly, daily, > weekly, monthly basis. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Support XML-compliant script delimiter
This is off the top of my head from the Jackrabbit/Sling BOF at ApacheCon: It would be of great use to support another script delimiter in script files. The current delimiters (<% and %>) does not play well with most IDEs (at least the one I've tried). At least in IntelliJ IDEA, you can mix XML/HTML with other languages (and have auto-completion and error checking) only if it is delimited by a valid XML element. We have at least two options here: 1. Use the standard HTML
Re: Sling Repository Explorer
Hi Valentin, Sorry to take so long to reply... On Sat, Mar 7, 2009 at 12:23 PM, Valentin Jacquemin wrote: > ...my prototype is here (I don't know the usual process to > propose a contribution, are there any repository available for the > non-comitters?):... Thanks - I got it working by copying your script to apps/sling/servlet/default/explorer.html.esp and requesting URLs like http://localhost:/apps.explorer.html The script does a lot with few lines of code, that's a good demo for Sling! As discussed recently in another thread, however, an explorer that allows you to create, edit and delete nodes, assign nodetypes, search the repository and generally perform all available JCR operations might need some additional server-side components. Or better, improvements to Sling's existing RESTful interface - if that can support a full featured explorer, the interface will be reasonably feature complete ;-) The current process for contributions by community members who are not (yet) committers is to upload patches to JIRA issues. You could also create a project hosted elsewhere, and have that (possibly) adopted by Sling later on. If you do that, however, I'd recommend using the Apache License 2.0 from the start, to make it easier for us to adopt the code, should that happen. Simpler examples can also be attached to our public wiki at http://cwiki.apache.org/SLING/ -Bertrand
Re: Public snapshots, javadocs and CI
Jukka Zitting wrote: > Hi, > > On Tue, Mar 31, 2009 at 4:29 PM, Bertrand Delacretaz > wrote: >> I assume we need the artifacts created by our continuum server [1] to >> be pushed somewhere when the builds are successful, but I'm not sure >> how to set that up. RTFM links are welcome of course. > > The easiest way to do that is to use the new repository.apache.org > server. See https://issues.apache.org/jira/browse/INFRA-1896 and > related links for background. > Ok, I'll take a look at that in the next days. Carsten -- Carsten Ziegeler cziege...@apache.org
Re: Renaming SlingWebDavServlet? (was: SlingWebDavServlet serves resource not only below /dav?)
Paul Noden wrote: > 2009/3/31 Bertrand Delacretaz > >> I agree that this can be confusing, do people agree about renaming the >> Sling servlet, to SlingSimpleWebDavServlet, maybe? >> > > +1 > I'm fine with the name change, but what is really the idea of having a "Simple" in the name? Especially if this is the only implementation? Regards Carsten -- Carsten Ziegeler cziege...@apache.org
Re: Public snapshots, javadocs and CI
Hi, On Tue, Mar 31, 2009 at 4:29 PM, Bertrand Delacretaz wrote: > I assume we need the artifacts created by our continuum server [1] to > be pushed somewhere when the builds are successful, but I'm not sure > how to set that up. RTFM links are welcome of course. The easiest way to do that is to use the new repository.apache.org server. See https://issues.apache.org/jira/browse/INFRA-1896 and related links for background. BR, Jukka Zitting
Re: Renaming SlingWebDavServlet? (was: SlingWebDavServlet serves resource not only below /dav?)
2009/3/31 Bertrand Delacretaz > I agree that this can be confusing, do people agree about renaming the > Sling servlet, to SlingSimpleWebDavServlet, maybe? > +1 Kind Regards, Paul Noden
Public snapshots, javadocs and CI
Hi, There were questions recently about making public snapshots of Sling available, and also about making javadocs available. I'm not an expert w.r.t to configuration of continuous integration servers - could someone outline what's needed to make this happen? I assume we need the artifacts created by our continuum server [1] to be pushed somewhere when the builds are successful, but I'm not sure how to set that up. RTFM links are welcome of course. In the future, we might also want to generate the Sling website using Sling, based on a similar mechanism. But that's another story. -Bertrand [1] http://vmbuild.apache.org/continuum/projectGroupSummary.action?projectGroupId=53
Renaming SlingWebDavServlet? (was: SlingWebDavServlet serves resource not only below /dav?)
(still catching up with my Sling mail ;-) Hi, On Tue, Mar 17, 2009 at 2:46 PM, Marc Speck wrote: > ...You have also my vote if you want to rename > org.apache.sling.jcr.webdav.impl.servlets.SimpleWebdavServlet. "public class > SimpleWebDavServlet extends SimpleWebdavServlet" is not very readable and in > SlingWebDavServlet, there are SimpleWebDavServlet and SimpleWebdavServlet > that refer to different classes I agree that this can be confusing, do people agree about renaming the Sling servlet, to SlingSimpleWebDavServlet, maybe? -Bertrand
Re: SlingWebDavServlet serves resource not only below /dav?
Hi Marc, On Tue, Mar 17, 2009 at 2:46 PM, Marc Speck wrote: > While testing a custom bundle, I found that the SlingWebDavServlet also > handles HTTP POST requests which are not below the root path (default > "/dav"). Is this expected or a bug?... I don't think that's expected, but is that really a problem? I thought WebDAV would just ignore POST requests as it does not care for that method. -Bertrand > ...To test this behavior, stop o.a.s.server.post bundle and send a POST > request. ResourceCollector.getServelts() finds the SlingWebDavServlet under > the path "/apps/sling/servlet/default". I've not found yet, how the root > path is checked for the WebDav servlet. Could you point to that?...
Re: Sling javadocs?
On Thu, Mar 19, 2009 at 7:04 PM, Jukka Zitting wrote: > ...Something I look for every now and then. Do we have the javadocs of a) > the latest trunk and b) the release up somewhere?... I don't think so...the best might be to have a continuous integration server generate them, and make the results available on the website, with version-based paths? Paths would probably need to include the bundle name, something like /javadocs/org.apache.sling.api/2.0.2/ -Bertrand
[jira] Created: (SLING-904) jcrinstall - take three
jcrinstall - take three --- Key: SLING-904 URL: https://issues.apache.org/jira/browse/SLING-904 Project: Sling Issue Type: Improvement Components: JCR Install Reporter: Bertrand Delacretaz Refactor and reengineer jcrinstall based on the accumulated experiences of the "take two", SLING-646. See discussion in http://markmail.org/message/ld6tkz6fdseknntx -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (SLING-646) jcrinstall - take two
[ https://issues.apache.org/jira/browse/SLING-646?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bertrand Delacretaz closed SLING-646. - Resolution: Fixed Implemented, SLING-904 is the next step > jcrinstall - take two > - > > Key: SLING-646 > URL: https://issues.apache.org/jira/browse/SLING-646 > Project: Sling > Issue Type: New Feature > Components: JCR Install >Reporter: Bertrand Delacretaz >Assignee: Bertrand Delacretaz > > Based on the jcrinstall [1] and jcrbundles [2][SLiNG-587] experiments, and > after playing a bit with these modules and talking to (our) Felix, I'll start > re-implementing the jcrinstall module under sling/extensions/jcrinstall, > based on a mix of both codebases (jcrbundles was based on the existing > jcrinstall anyway, so it's a mix already). > Here's a quick specification. > The jcrinstall module looks for OSGi resources (bundles in jar files, > configurations in text (.cfg) files, deployment packages in .dp files) under > a configurable set of paths in the repository. > Those resources are "installed" in the OSGi framework when detected: bundles, > deployment packages and configurations are installed, updated or removed as > needed. > The jcrinstall module is considered as another "user interface" to the OSGi > framework, besides the existing OSGi console, and as such aims to play well > with the console, and avoid any inconsistencies when both user interfaces are > used. That's only a best effort, though, as we'll probably find edge cases > when using both can cause problems. > The module is split in two components: > = OSGi controller component = > Receives notifications of new, updated or deleted OSGi resources from the JCR > observation component. > Does not use any JCR interfaces, so as to be reusable independently. > Manages the required queues and retries to ensure that received bundles, > configurations and deployment packages are eventually activated, even if > their dependencies are made available later. > Provides permanent storage (based on BundleContext.getDataFile()) for the JCR > component to store Properties for the resources that it detects. > Uses handlers based on a common interface for the various types of resources > (bundles, configs, deployment packages). > = JCR observation component = > Observes a number of folders in the JCR repository, based on configurable > regular expressions for their paths. The default regexp causes folders named > "install" to be observed. > Limited to a configurable list of root paths, by default /libs and /apps. > Detects added or modified files in those folders and notifies the OSGi > controller of these events, providing the file's InputStream with the event, > along with an event type. > Uses the permanent storage provided by the OSGi controller to store > information that allows for detecting updates and deletes of OSGi resources. > = coda = > Splitting the module in two well-separated components should also help > automated testing - as described above, both components should be readily > testable without requiring complicated setups. > [1] http://svn.apache.org/repos/asf/incubator/sling/whiteboard/jcrinstall/ > [2] http://svn.apache.org/repos/asf/incubator/sling/whiteboard/jcrbundles/ -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: JCR Install next steps
Hi Felix, On Tue, Mar 24, 2009 at 5:34 PM, Felix Meschberger wrote: > ...Therefore, I think, we might want to refactor JCR Install along the > following lines... Agree 100% with what you suggest, the experiences collected while working on jcrinstall should help us make it better. And, in the process, we might be able to create a reusable framework for OSGi installers, that could be used with other data sources besides JCR. For now, created SLING-904. -Bertrand
Re: How about renaming the "bundles" source code folder to "core" ?
Hi, On Tue, Mar 31, 2009 at 3:31 PM, Bertrand Delacretaz wrote: > The names of the subfolders at the top of the Sling source code tree > all make sense to me, except "bundles": My rationale for the "bundles" name was that there we have all the OSGi bundles included in a normal Sling deployment. Renaming it to "core" would sound a bit strange to me, as we have stuff like all the extensions and scripting languages in there. BR, Jukka Zitting
Re: How about renaming the "bundles" source code folder to "core" ?
I think we disregarded "core" when we discussed a good name and simply choose "bundles"; "core" implies that you need all this stuff to run Sling which is not true; you just need some the bundles there. Carsten Bertrand Delacretaz wrote: > Hi, > > The names of the subfolders at the top of the Sling source code tree > all make sense to me, except "bundles": > > bundles > contrib > launchpad > maven > parent > samples > site > > How about renaming "bundles" to "core"? That folder contains > > api > commons > engine > extensions > jcr > scripting > servlets > > Which IMHO fit well into what we consider to be the core of Sling. > > -Bertrand > (catching up with Sling after a few weeks of low activity - please > bear with me and possibly weird suggestions, this one's not too bad > ;-) > -- Carsten Ziegeler cziege...@apache.org
How about renaming the "bundles" source code folder to "core" ?
Hi, The names of the subfolders at the top of the Sling source code tree all make sense to me, except "bundles": bundles contrib launchpad maven parent samples site How about renaming "bundles" to "core"? That folder contains api commons engine extensions jcr scripting servlets Which IMHO fit well into what we consider to be the core of Sling. -Bertrand (catching up with Sling after a few weeks of low activity - please bear with me and possibly weird suggestions, this one's not too bad ;-)
Re: test failures
Hi, On Fri, Mar 27, 2009 at 6:44 AM, Jim White wrote: > I get the following test failures with the trunk (r758703) : > > Results : > Failed tests: > testRemoveAce(org.apache.sling.launchpad.webapp.integrationtest.accessManager.RemoveAcesTest) > testRemoveAces(org.apache.sling.launchpad.webapp.integrationtest.accessManager.RemoveAcesTest) > testModifyAceForUser(org.apache.sling.launchpad.webapp.integrationtest.accessManager.ModifyAceTest) > testModifyAceForGroup(org.apache.sling.launchpad.webapp.integrationtest.accessManager.ModifyAceTest)... Do you still have this problem? I had a similar one this morning, caused by a stale "sling" working folder being used for testing. Unfortunately, "mvn clean" does not delete those work folders - if you want to kill them manually they are: ./launchpad/app/sling ./launchpad/webapp/sling . /sling relative to the top of the source code tree. -Bertrand
Re: securing a sling based application
Hi, On Fri, Mar 27, 2009 at 4:39 PM, Ruben Reusser wrote: > ...I am wondering how to best secure a sling based application so once my app > is deployed and I allow access from the internet I do not run into security > issues or unexpected outside exposure.Is there a best practice what one > should look out for or a set of apache rewrite rules one should use?... One thing that I would recommend is having all your content under /content, and configuring a virtual httpd host so that the root of your public website points to /content, hiding everything else. This will prevent outside access to things that people shouldn't see, like /system, /libs, /apps, etc. Apart from that, the usual rules for securing webapps apply. One benefit of JCR is that handling security at the repository level makes sure nothing bad can happen as long as users cannot elevate their privileges. -Bertrand
Re: sling-test.html fails
Hi, On Sun, Mar 29, 2009 at 6:58 AM, Jim White wrote: > The Sling client library test page (/sling-test/sling/sling-test.html) has > an assertion that fails for me (fixing the clean build didn't fix this > problem). > > assertNull failed: testRemoveContent: data should be gone after deletePath > (/test-data/sling-test/testhtml-nodes/sling-test/testhtml-nodes/delete-1238302522312)... It works for me in the current trunk, did you change the default config according to this note at the top of the test page? "Note that, in Sling revision 669215, the tests fail unless the Allow Anonymous Access parameter of the Sling Request Authenticator component is set to false, see SLING-322." -Bertrand
Re: sling - wicket integration?
Hi Alex, On Fri, Mar 27, 2009 at 9:42 PM, Alex Parvulescu wrote: > ...I'm new around here, so excuse my ignorance :).. Welcome ;-) > ...I'm very interested in integrating sling as a content repository with > wicket... So am I, but my Copious Free Time doesn't allow me to actually work on it ATM. I'd be very happy to see this happen, and the way Dominik suggests tackling it looks promising. Maybe you guys can join forces on this? And maybe asking the Wicket people what the best option would be would be worth it? Asking how to run Wicket in an OSGi environment might raise their interest, and the "Wicket takes over the request processing cycle after Sling has selected content" integration that Dominik suggests might be of general interest to them. > ...By the way, if anyting good comes out of this, I can happily contribute it > back to the project as an example/usecase That would be great, and Wicket integration could be much more than a use case - the nice thing with Wicket is that everything is done in Java, so you can fully take advantage of debuggers and IDEs. Having that option in Sling, for people who want to work in this way, would be great! -Bertrand
"mvn clean" should delete "sling" work folders
Hi, I was bitten by this one again, trying to run Sling tests failed due to a stale "sling" work folder, or more precisely gave different results when run in the launchpad/testing folder vs. top of the source code tree. In my opinion, "mvn clean test" should have predictable results, without taking previous runs into account. Why did we move the "sling" folders from target/sling (where mvn clean kills them) to siblings of src folders? Is that on purpose, or a side effect of other changes? I'd move them back, if people agree - having non-repeatable "mvn clean test" cycles can be a big waste of people's time. -Bertrand
[jira] Closed: (SLING-903) Access-control related integration tests run "too early" and fail
[ https://issues.apache.org/jira/browse/SLING-903?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bertrand Delacretaz closed SLING-903. - Resolution: Invalid I was wrong, the problem was caused by a stale "sling" folder with old repository data, and "mvn clean" doesn't delete all such sling test folders. Will bring this up on the dev list. > Access-control related integration tests run "too early" and fail > - > > Key: SLING-903 > URL: https://issues.apache.org/jira/browse/SLING-903 > Project: Sling > Issue Type: Bug > Components: Testing >Reporter: Bertrand Delacretaz >Priority: Minor > > Some integration tests to fail on my macosx JDK 1.5 system: > org.apache.sling.launchpad.webapp.integrationtest.accessManager.RemoveAcesTest, > UpdateGroupTest, ModifyAceTest, etc. > The tests pass when run against a separate Sling instance that's been started > from some time, but when run as part of a full build they fail with the NPE > of SLING-868 > I assume that's because the tests run "too early", before the required > authenticator is started. Implementing a better readyness detection test > (SLING-490) should help. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (SLING-903) Access-control related integration tests run "too early" and fail
Access-control related integration tests run "too early" and fail - Key: SLING-903 URL: https://issues.apache.org/jira/browse/SLING-903 Project: Sling Issue Type: Bug Components: Testing Reporter: Bertrand Delacretaz Priority: Minor Some integration tests to fail on my macosx JDK 1.5 system: org.apache.sling.launchpad.webapp.integrationtest.accessManager.RemoveAcesTest, UpdateGroupTest, ModifyAceTest, etc. The tests pass when run against a separate Sling instance that's been started from some time, but when run as part of a full build they fail with the NPE of SLING-868 I assume that's because the tests run "too early", before the required authenticator is started. Implementing a better readyness detection test (SLING-490) should help. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Gwt + Sling
2009/3/30 Glenn Silverman > Hi, Christophe, > > How do you handle relative paths in your GWT application, such as image > hrefs' and links, I have not yet tested hrefs & links but it should works with the noServer gwt option. I will test it asap. What I did is a sample gwt module which display a tree view populated with a json based sling request. > for > content in your repository? Do you recreate your repository structure > locally. That seems bug -prone > and not ideal for RAD. I'm not recreate the repository structure locally. There is 2 possiblities : - Using the FsResourceProvider bundle to point to your local gwt web app folder (inside your project). you have to configure it from the Sling console. - create a new sling folder and copy the minimum gwt files. > > > By the way, I would like to see your development directory structure. I'm testing the gwt maven plugin. So, the structure is the usual maven one. > When you say you match your > Sling folder to your GWT application, what exactly does that look like. Are > you talking about just matching > the compiled GWT structure, or the development one? see on http://www.screaming-penguin.com/node/4500. This is the same for Sling. Until now, I have some problems with the gwt maven plugin to generate a correct launch file and I have not yet tested all possibilities. > > Glenn... > > > Christophe Lombart wrote: > >> Hi Glenn, >> >> I'm taking a different approach. We can create a Sling folder that match >> to >> the GWT application in which we add the necessary gwt files [1] and that's >> all for running the application in the hosted mode with Sling. So, a maven >> plugin can do that. Do you think that is not a good idea ? Following my >> first test, it works fine. I have to check if debugging is well supported. >> >> br, >> Christophe >> >> >> [1] http://www.screaming-penguin.com/node/4500 >> >> >> Hi, >> >> >>> I've too am interested in a RAD development environment for GWT + Sling >>> in >>> Eclipse. >>> What is really needed is a Sling plugin for Eclipse that would allow your >>> local Eclipse workspace to be "attached" to your running Sling repository >>> >>> >> >> >> It could be possible with the fsresource bundle. I have only test it with >> a >> js based application. I didn't test it with a gwt application. >> >> >> > >
