Re: Node name generation
Hi, Am Dienstag, den 15.04.2008, 11:27 +0200 schrieb Carsten Ziegeler: Ok, anyonw *against* using name and nameHint? I'll commit a version using these parameter names. If anyone has a good reason for better names, I'm happy to change the impl. +1 for these names ;-) Thanks and Regards Felix Carsten David Nuescheler wrote: hi guys, personally, i don't care too much as long as we keep the simple case namely where the default namehint (if it is not explicitly set) is derived from jcr:title, title etc.. of course, i think we should (like for all form elements that have a special meaning to sling) prefix it with sling: my personal favorite would be sling:nameHint regards, david On Mon, Apr 14, 2008 at 5:05 PM, Carsten Ziegeler [EMAIL PROTECTED] wrote: Bertrand Delacretaz wrote: On Mon, Apr 14, 2008 at 4:38 PM, Felix Meschberger [EMAIL PROTECTED] wrote: ...Can we find something else than nodeName ? How about exactName ?... nodeName is IMHO better, as the parameter describes the name of the created node...exactName could be the exact name of your sister ;-) :) But to be consistent, nameHint should be nodeNameHint maybe. A bit longish but very clear. Ok, we should either use nodeNameHint and nodeName or name and nameHint From those two options I would prefer the first one. Carsten ... And then, I would not filter or otherwise mangle the exact name (this is the difference to Betrand's proposal) and rather fail if the name is invalid We are in agreement, that's what I suggested, no filtering for nodeName. -Bertrand -- Carsten Ziegeler [EMAIL PROTECTED]
Re: Current trunk broken?
Felix Meschberger wrote: Am Montag, den 14.04.2008, 15:50 -0500 schrieb Craig L. Ching: yes, it seems. just comment out those modules in the pom. i get another error that some taglibs are missing. so i commented those conflicting modules as well. This is SLING-361 actually. Are you looking into it, or should i? Carsten -- Carsten Ziegeler [EMAIL PROTECTED]
Re: Current trunk broken?
Am Mittwoch, den 16.04.2008, 08:08 +0200 schrieb Carsten Ziegeler: Felix Meschberger wrote: Am Montag, den 14.04.2008, 15:50 -0500 schrieb Craig L. Ching: yes, it seems. just comment out those modules in the pom. i get another error that some taglibs are missing. so i commented those conflicting modules as well. This is SLING-361 actually. Are you looking into it, or should i? If you could do it, it would be great. It is probably related to how Maven resolves the build class path and the Sling JSP compiler and jspc plugins find the tag libs... Regards Felix
[jira] Assigned: (SLING-361) The sling/sample module fails to compile JSP scripts when run in a reactor build
[
https://issues.apache.org/jira/browse/SLING-361?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Carsten Ziegeler reassigned SLING-361:
--
Assignee: Carsten Ziegeler
The sling/sample module fails to compile JSP scripts when run in a reactor
build
Key: SLING-361
URL: https://issues.apache.org/jira/browse/SLING-361
Project: Sling
Issue Type: Bug
Components: JSP
Affects Versions: 2.0.0
Reporter: Felix Meschberger
Assignee: Carsten Ziegeler
Fix For: 2.0.0
JSP script file compilation with the maven-jspc-plugin fails when run in
reactor mode build. The problem seems to be that the tag library cannot be
resolved:
[INFO] [jspc:jspc {execution: compile-jsp}]
[ERROR] Compilation Failure
org.apache.sling.scripting.jsp.jasper.JasperException: The absolute uri:
http://sling.apache.org/taglibs/sling/1.0 cannot be resolved in either
web.xml or the jar files deployed with this application
at
org.apache.sling.scripting.jsp.jasper.compiler.DefaultErrorHandler.jspError(DefaultErrorHandler.java:51)
at
org.apache.sling.scripting.jsp.jasper.compiler.ErrorDispatcher.dispatch(ErrorDispatcher.java:409)
at
org.apache.sling.scripting.jsp.jasper.compiler.ErrorDispatcher.jspError(ErrorDispatcher.java:116)
at
org.apache.sling.scripting.jsp.jasper.compiler.TagLibraryInfoImpl.generateTLDLocation(TagLibraryInfoImpl.java:315)
at
org.apache.sling.scripting.jsp.jasper.compiler.TagLibraryInfoImpl.init(TagLibraryInfoImpl.java:148)
at
org.apache.sling.scripting.jsp.jasper.compiler.Parser.parseTaglibDirective(Parser.java:420)
at
org.apache.sling.scripting.jsp.jasper.compiler.Parser.parseDirective(Parser.java:476)
at
org.apache.sling.scripting.jsp.jasper.compiler.Parser.parseElements(Parser.java:1426)
at
org.apache.sling.scripting.jsp.jasper.compiler.Parser.parse(Parser.java:133)
at
org.apache.sling.scripting.jsp.jasper.compiler.ParserController.doParse(ParserController.java:216)
at
org.apache.sling.scripting.jsp.jasper.compiler.ParserController.parse(ParserController.java:103)
at
org.apache.sling.scripting.jsp.jasper.compiler.Compiler.generateJava(Compiler.java:168)
at
org.apache.sling.scripting.jsp.jasper.compiler.Compiler.compile(Compiler.java:307)
at org.apache.sling.maven.jspc.JspcMojo.processFile(JspcMojo.java:360)
at
org.apache.sling.maven.jspc.JspcMojo.executeInternal(JspcMojo.java:313)
at org.apache.sling.maven.jspc.JspcMojo.execute(JspcMojo.java:225)
at
org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:443)
The interesting question - once again - is why the build succeeds in single
build but not in a reactor build. Probably there is some project resolution
issue. Will have to trace this.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (SLING-384) Replace logback in the osgi/log module
Replace logback in the osgi/log module -- Key: SLING-384 URL: https://issues.apache.org/jira/browse/SLING-384 Project: Sling Issue Type: Bug Reporter: Felix Meschberger Assignee: Felix Meschberger Fix For: 2.0.0 The osgi/log module currently includes LogBack [1] as the logging backend. This library is licensed under LGPL 3.0, which makes it hard to include in Sling. In addition, the full functionality of LogBack is probably not used at all. The goal of this issue is to replace LogBack with a very simple implementation of the SLF4J API suitable for our needs, that is: * Log to a file or to the console * Support log file rotation * Support simple log message formatting [1] http://www.logback.org -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SLING-384) Replace logback in the osgi/log module
[ https://issues.apache.org/jira/browse/SLING-384?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Meschberger updated SLING-384: Component/s: OSGi Replace logback in the osgi/log module -- Key: SLING-384 URL: https://issues.apache.org/jira/browse/SLING-384 Project: Sling Issue Type: Bug Components: OSGi Reporter: Felix Meschberger Assignee: Felix Meschberger Fix For: 2.0.0 The osgi/log module currently includes LogBack [1] as the logging backend. This library is licensed under LGPL 3.0, which makes it hard to include in Sling. In addition, the full functionality of LogBack is probably not used at all. The goal of this issue is to replace LogBack with a very simple implementation of the SLF4J API suitable for our needs, that is: * Log to a file or to the console * Support log file rotation * Support simple log message formatting [1] http://www.logback.org -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Current trunk broken?
Felix Meschberger wrote: Am Mittwoch, den 16.04.2008, 08:08 +0200 schrieb Carsten Ziegeler: Felix Meschberger wrote: Am Montag, den 14.04.2008, 15:50 -0500 schrieb Craig L. Ching: yes, it seems. just comment out those modules in the pom. i get another error that some taglibs are missing. so i commented those conflicting modules as well. This is SLING-361 actually. Are you looking into it, or should i? If you could do it, it would be great. It is probably related to how Maven resolves the build class path and the Sling JSP compiler and jspc plugins find the tag libs... I changed the classpath generation for the plugin (by using the setup we use for the SCR plugin), and it seems to work now. Carsten -- Carsten Ziegeler [EMAIL PROTECTED]
Re: Current trunk broken?
On Wed, Apr 16, 2008 at 8:56 AM, Carsten Ziegeler ... I changed the classpath generation for the plugin (by using the setup we use for the SCR plugin), and it seems to work now Works for me, thanks! -Bertrand
Re: Current trunk broken?
Cool. Thanks. Regards Felix Am Mittwoch, den 16.04.2008, 08:56 +0200 schrieb Carsten Ziegeler: Felix Meschberger wrote: Am Mittwoch, den 16.04.2008, 08:08 +0200 schrieb Carsten Ziegeler: Felix Meschberger wrote: Am Montag, den 14.04.2008, 15:50 -0500 schrieb Craig L. Ching: yes, it seems. just comment out those modules in the pom. i get another error that some taglibs are missing. so i commented those conflicting modules as well. This is SLING-361 actually. Are you looking into it, or should i? If you could do it, it would be great. It is probably related to how Maven resolves the build class path and the Sling JSP compiler and jspc plugins find the tag libs... I changed the classpath generation for the plugin (by using the setup we use for the SCR plugin), and it seems to work now. Carsten
[jira] Closed: (SLING-351) Use uppercase Sling in sling.js
[ https://issues.apache.org/jira/browse/SLING-351?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler closed SLING-351. -- Resolution: Fixed Use uppercase Sling in sling.js --- Key: SLING-351 URL: https://issues.apache.org/jira/browse/SLING-351 Project: Sling Issue Type: Improvement Affects Versions: 2.0.0 Reporter: Bertrand Delacretaz Fix For: 2.0.0 The Sling variable in sling.js is similar to a class, so should be called Sling and not sling -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SLING-311) Record loaded content to not reload inadvertedly.
[ https://issues.apache.org/jira/browse/SLING-311?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12589451#action_12589451 ] Carsten Ziegeler commented on SLING-311: It would be great, if the content would be overwritten if I update a bundle. This would make the development much easier. Record loaded content to not reload inadvertedly. - Key: SLING-311 URL: https://issues.apache.org/jira/browse/SLING-311 Project: Sling Issue Type: Improvement Components: Resource Reporter: Felix Meschberger Fix For: 2.0.0 Currently, the content loader always reloads content indicated as initial content from the bundles if the repository does not contain the respective content. Sometimes it may be desirable to remove the content from the repository and not get the content reloaded on bundle (or system) restart. To prevent such content reload, the content loader should take note of loaded content and not try to reload content, which is marked as loaded, regardless of whether the actual content (still) exists or not. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SLING-311) Record loaded content to not reload inadvertedly.
[ https://issues.apache.org/jira/browse/SLING-311?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12589456#action_12589456 ] Felix Meschberger commented on SLING-311: - I think this mark can also be used for this overwriting: If the mark is missing, content is replaced. There is one catch though: Consider a node at /apps/path loaded by the loader and content at /apps/path/child not loaded by the loader. I assume, /apps/path should be replaced while /apps/path/child might be left untouched. In this case, primary node types of the node to be replaced may probably not be changed. We can still change the mixin node types. In the end we may be left with invalid content as the nodes we do not replace may not be allowed anymore. But this is probably as good as we can do without much overloading the work. WDYT ? Record loaded content to not reload inadvertedly. - Key: SLING-311 URL: https://issues.apache.org/jira/browse/SLING-311 Project: Sling Issue Type: Improvement Components: Resource Reporter: Felix Meschberger Fix For: 2.0.0 Currently, the content loader always reloads content indicated as initial content from the bundles if the repository does not contain the respective content. Sometimes it may be desirable to remove the content from the repository and not get the content reloaded on bundle (or system) restart. To prevent such content reload, the content loader should take note of loaded content and not try to reload content, which is marked as loaded, regardless of whether the actual content (still) exists or not. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
question about adding a bundle using launchpad net beans 5.0 warning.
Hi ,
I have two questions.
First is about starting a new bundle manually. Second is about a warning
message shown by net beans 5.0.
This is a lenghty description but i think it is necessary.
*
First question*
I wrote two skeleton classes ScalaScriptEngineFactory and ScalaScriptEngine
with out any logic only implementing the required interfaces referring the
Velocity , Ruby , Freemarker Rhino modules.
I saved them under
sling\scripting\scala\src\main\java\org\apache\sling\scripting\scala.
then i modified the pom.xml generated by maven as follows
project xmlns=http://maven.apache.org/POM/4.0.0; xmlns:xsi=
http://www.w3.org/2001/XMLSchema-instance;
xsi:schemaLocation=http://maven.apache.org/POM/4.0.0
http://maven.apache.org/maven-v4_0_0.xsd;
modelVersion4.0.0/modelVersion
parent
groupIdorg.apache.sling/groupId
artifactIdsling/artifactId
version1-incubator-SNAPSHOT/version
relativePath../../parent/pom.xml/relativePath
/parent
artifactIdorg.apache.sling.scripting.scala/artifactId
version2.0.0-incubator-SNAPSHOT/version
packagingbundle/packaging
nameSling - Scripting - Scala Support/name
descriptionSupport for Scala scripting/description
build
plugins
plugin
groupIdorg.apache.felix/groupId
artifactIdmaven-bundle-plugin/artifactId
extensionstrue/extensions
configuration
instructions
Private-Package
org.apache.sling.scripting.scala
/Private-Package
ScriptEngine-Name${pom.name}/ScriptEngine-Name
ScriptEngine-Version${pom.version}/ScriptEngine-Version
/instructions
/configuration
/plugin
/plugins
/build
dependencies
dependency
groupIdorg.apache.sling/groupId
artifactIdorg.apache.sling.api/artifactId
version2.0.0-incubator-SNAPSHOT/version
/dependency
dependency
groupIdorg.apache.sling/groupId
artifactIdorg.apache.sling.scripting.api/artifactId
version2.0.0-incubator-SNAPSHOT/version
/dependency
dependency
groupIdjavax.jcr/groupId
artifactIdjcr/artifactId
/dependency
dependency
groupIdjunit/groupId
artifactIdjunit/artifactId
version3.8.1/version
scopetest/scope
/dependency
/dependencies
/project
*After adding the line modulescripting/scala/module under !--
Scripting Support -- in the main pom.xml I rebuilt sling using command
mvn install
Once the build is complete it was possible to add the created jar using the
launchpad web interface. When I click start it shows that the new bundle has
started.
But I didn't write any logic.
So how is it possible for the bundle to load and start. How can i really
check whether it is started ?.*
*Second question*
when i wrote the code using net beans 5.0 IDE there is this warning.
but the get methods in the Script Engine Factory classes for other scripting
languges have similar META DATA get methods as shown in JSR 223 spec.
why is this warning telling AbstractScriptEngineFactory cannot implement
getMethodCallSyntax in javax.script.ScriptEngineFactory. Will it create an
issue for the execution of the bundle. ?
regards,
janandith.
[jira] Commented: (SLING-311) Record loaded content to not reload inadvertedly.
[ https://issues.apache.org/jira/browse/SLING-311?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12589457#action_12589457 ] Philipp Koch commented on SLING-311: the update functionality is very important in regards of bundle updates (where the bundle is supposed to update content) Record loaded content to not reload inadvertedly. - Key: SLING-311 URL: https://issues.apache.org/jira/browse/SLING-311 Project: Sling Issue Type: Improvement Components: Resource Reporter: Felix Meschberger Fix For: 2.0.0 Currently, the content loader always reloads content indicated as initial content from the bundles if the repository does not contain the respective content. Sometimes it may be desirable to remove the content from the repository and not get the content reloaded on bundle (or system) restart. To prevent such content reload, the content loader should take note of loaded content and not try to reload content, which is marked as loaded, regardless of whether the actual content (still) exists or not. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: question about adding a bundle using launchpad net beans 5.0 warning.
Hi,
Sorry i couldn't send the warning in net beans 5.0 for my second question.
It is in the attachment screenshot.
regards ,
janandith.
On Wed, Apr 16, 2008 at 2:01 PM, janandith jayawardena [EMAIL PROTECTED]
wrote:
Hi ,
I have two questions.
First is about starting a new bundle manually. Second is about a warning
message shown by net beans 5.0.
This is a lenghty description but i think it is necessary.
*
First question*
I wrote two skeleton classes ScalaScriptEngineFactory and
ScalaScriptEngine with out any logic only implementing the required
interfaces referring the Velocity , Ruby , Freemarker Rhino modules.
I saved them under
sling\scripting\scala\src\main\java\org\apache\sling\scripting\scala.
then i modified the pom.xml generated by maven as follows
project xmlns=http://maven.apache.org/POM/4.0.0; xmlns:xsi=
http://www.w3.org/2001/XMLSchema-instance;
xsi:schemaLocation=http://maven.apache.org/POM/4.0.0
http://maven.apache.org/maven-v4_0_0.xsd;
modelVersion4.0.0/modelVersion
parent
groupIdorg.apache.sling/groupId
artifactIdsling/artifactId
version1-incubator-SNAPSHOT/version
relativePath../../parent/pom.xml/relativePath
/parent
artifactIdorg.apache.sling.scripting.scala/artifactId
version2.0.0-incubator-SNAPSHOT/version
packagingbundle/packaging
nameSling - Scripting - Scala Support/name
descriptionSupport for Scala scripting/description
build
plugins
plugin
groupIdorg.apache.felix/groupId
artifactIdmaven-bundle-plugin/artifactId
extensionstrue/extensions
configuration
instructions
Private-Package
org.apache.sling.scripting.scala
/Private-Package
ScriptEngine-Name${pom.name}/ScriptEngine-Name
ScriptEngine-Version${pom.version}/ScriptEngine-Version
/instructions
/configuration
/plugin
/plugins
/build
dependencies
dependency
groupIdorg.apache.sling/groupId
artifactIdorg.apache.sling.api/artifactId
version2.0.0-incubator-SNAPSHOT/version
/dependency
dependency
groupIdorg.apache.sling/groupId
artifactIdorg.apache.sling.scripting.api/artifactId
version2.0.0-incubator-SNAPSHOT/version
/dependency
dependency
groupIdjavax.jcr/groupId
artifactIdjcr/artifactId
/dependency
dependency
groupIdjunit/groupId
artifactIdjunit/artifactId
version3.8.1/version
scopetest/scope
/dependency
/dependencies
/project
*After adding the line modulescripting/scala/module under !--
Scripting Support -- in the main pom.xml I rebuilt sling using command
mvn install
Once the build is complete it was possible to add the created jar using
the launchpad web interface. When I click start it shows that the new bundle
has started.
But I didn't write any logic.
So how is it possible for the bundle to load and start. How can i really
check whether it is started ?.*
*Second question*
when i wrote the code using net beans 5.0 IDE there is this warning.
but the get methods in the Script Engine Factory classes for other
scripting languges have similar META DATA get methods as shown in JSR 223
spec.
why is this warning telling AbstractScriptEngineFactory cannot implement
getMethodCallSyntax in javax.script.ScriptEngineFactory. Will it create an
issue for the execution of the bundle. ?
regards,
janandith.
[jira] Commented: (SLING-311) Record loaded content to not reload inadvertedly.
[ https://issues.apache.org/jira/browse/SLING-311?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12589463#action_12589463 ] Carsten Ziegeler commented on SLING-311: I'm not sure if we can use the mark for overwriting/handling the update case - if I start a bundle, the mark will be added. If I now update the bundle, the mark is still there. Or do you want to remove the mark on bundle stop? If the user touched the content in the meantime and for instance added child nodes etc., then maybe the approach described might work and seems to be good enough. Record loaded content to not reload inadvertedly. - Key: SLING-311 URL: https://issues.apache.org/jira/browse/SLING-311 Project: Sling Issue Type: Improvement Components: Resource Reporter: Felix Meschberger Fix For: 2.0.0 Currently, the content loader always reloads content indicated as initial content from the bundles if the repository does not contain the respective content. Sometimes it may be desirable to remove the content from the repository and not get the content reloaded on bundle (or system) restart. To prevent such content reload, the content loader should take note of loaded content and not try to reload content, which is marked as loaded, regardless of whether the actual content (still) exists or not. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: question about adding a bundle using launchpad net beans 5.0 warning.
Hi For the second question: I fear attachements do not make it to the mailing list. You may come by this restriction by creating a JIRA issue and attaching the screen shot. Am Mittwoch, den 16.04.2008, 14:05 +0600 schrieb janandith jayawardena: ... snip snip snip ... Second question when i wrote the code using net beans 5.0 IDE there is this warning. but the get methods in the Script Engine Factory classes for other scripting languges have similar META DATA get methods as shown in JSR 223 spec. why is this warning telling AbstractScriptEngineFactory cannot implement getMethodCallSyntax in javax.script.ScriptEngineFactory. Will it create an issue for the execution of the bundle. ? Could it be that you are running NetBeans in Java 6 or have configured your project to be a Java 6 project ? In this case it would be possible to have a collision between the BSF3 classes included in the Sling Scripting API bundle and the Java 6 provided classes. I use Eclipse and configure my projects to only use JDK 5 for internal building. This prevents this collision. For maven build we have created the correct project setup to prevent this kind of collision even if using JDK 6 to build. Hope this helps. Otherwise, creating a JIRA and posting the screenshot would probably be best. Regards Felix
Content Overwrite in the Content Loader (was: [jira] Commented: (SLING-311) Record loaded content to not reload inadvertedly.)
Taking this to the list ... Am Mittwoch, den 16.04.2008, 01:22 -0700 schrieb Carsten Ziegeler (JIRA): [ https://issues.apache.org/jira/browse/SLING-311?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12589463#action_12589463 ] Carsten Ziegeler commented on SLING-311: I'm not sure if we can use the mark for overwriting/handling the update case - if I start a bundle, the mark will be added. If I now update the bundle, the mark is still there. Or do you want to remove the mark on bundle stop? If the user touched the content in the meantime and for instance added child nodes etc., then maybe the approach described might work and seems to be good enough. So the content loader should try to overwrite existing nodes and properties ? This is particulary required probably for files. WDYT ? OTOH: The marker is used to prevent reloading of the content. Now, you would like to have content overwrite. Of course we could do as such: * Marker existing and bundle install: Don't do nothing with the content * Marker missing and bundle install: Load the content (overwriting if needed) * Marker missing and system startup: Load the content (overwriting if needed) * Marker existing and bundle update: Load the content (overwriting if needed) * Marker missing and bundle update: Load the content (overwriting if needed) In other words, content is loaded (create or replace) if either the marker is missing or the bundle is being updated. If the marker exists when the bundle is started, no content loading takes place. Right ? Regards Felix
Re: Content Overwrite in the Content Loader
Felix Meschberger wrote: Taking this to the list ... Thanks :) Am Mittwoch, den 16.04.2008, 01:22 -0700 schrieb Carsten Ziegeler (JIRA): [ https://issues.apache.org/jira/browse/SLING-311?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12589463#action_12589463 ] Carsten Ziegeler commented on SLING-311: I'm not sure if we can use the mark for overwriting/handling the update case - if I start a bundle, the mark will be added. If I now update the bundle, the mark is still there. Or do you want to remove the mark on bundle stop? If the user touched the content in the meantime and for instance added child nodes etc., then maybe the approach described might work and seems to be good enough. So the content loader should try to overwrite existing nodes and properties ? Yes. The only problem might be that a user has changed a property and this gets then overwritten by an update. But I think this is an expected behaviour OTOH: The marker is used to prevent reloading of the content. Now, you would like to have content overwrite. Yes :) Of course we could do as such: * Marker existing and bundle install: Don't do nothing with the content * Marker missing and bundle install: Load the content (overwriting if needed) * Marker missing and system startup: Load the content (overwriting if needed) * Marker existing and bundle update: Load the content (overwriting if needed) * Marker missing and bundle update: Load the content (overwriting if needed) In other words, content is loaded (create or replace) if either the marker is missing or the bundle is being updated. If the marker exists when the bundle is started, no content loading takes place. Right ? Yepp. I think this sums it up nicely. Carsten -- Carsten Ziegeler [EMAIL PROTECTED]
Re: Content Overwrite in the Content Loader
On Wed, Apr 16, 2008 at 10:48 AM, Carsten Ziegeler [EMAIL PROTECTED] wrote: ...So the content loader should try to overwrite existing nodes and properties ? Yes. The only problem might be that a user has changed a property and this gets then overwritten by an update. But I think this is an expected behaviour Not sure - if people use content from bundles as initial content that's meant to be modified after being installed, overwriting their changes would be a nasty surprise. Handling this nicely might be a lot of work, as we'd need to keep track of what is untouched initial content and what has been modified. I don't have a simple solution ATM, but we should at least have a prominent warning somewhere when this happens. -Bertrand
Re: question about adding a bundle using launchpad net beans 5.0 warning.
On Wed, Apr 16, 2008 at 10:29 AM, Felix Meschberger [EMAIL PROTECTED] wrote: ...For maven build we have created the correct project setup to prevent this kind of collision even if using JDK 6 to build FWIW, I recently noticed that our continuum builds on vmbuild.apache.org run under java 6, here's an excerpt from a vmbuild notification: Building machine hostname: vmbuild.apache.org Operating system : Linux(unknown) Java Home version : java version 1.6.0_05 Java(TM) SE Runtime Environment (build 1.6.0_05-b13) Java HotSpot(TM) Client VM (build 10.0-b19, mixed mode, sharing) Builder version : Maven version: 2.0.7 Java version: 1.6.0_05 OS name: linux version: 2.6.20-16-server arch: i386 -Bertrand
Re: Content Overwrite in the Content Loader
Bertrand Delacretaz wrote: On Wed, Apr 16, 2008 at 11:06 AM, Carsten Ziegeler [EMAIL PROTECTED] wrote: ... Hmm, the more I think about it, the more I have the feeling that initial content comming from a bundle should only be used for static stuff - it should not be abused to get something into the repository which is intended to be changed by a user Not by an end user probably, but maybe by an admin or programmer. And the immutability of this content is not enforced anyway, so people will find creative uses for that ;-) Yes, but I would assume that an admin or programmer knows what she does and how things work. If she doesn't, well, there are so many other traps. For instance, the same person could just delete all scripts in the repository and than wonder why nothing is working anymore. We definitly prevent someone from doing that :) Carsten -- Carsten Ziegeler [EMAIL PROTECTED]
Re: Content Overwrite in the Content Loader
Hi, Am Mittwoch, den 16.04.2008, 11:11 +0200 schrieb Bertrand Delacretaz: On Wed, Apr 16, 2008 at 11:04 AM, Felix Meschberger [EMAIL PROTECTED] wrote: ... We could of course add a setting to force overwrite: Sling-InitialContent /content;overwrite:=true /Sling-InitialContent Without this setting (or having it set to false), content is never overwritten Good idea to set this per bundle - in this way, the bundle author decides, and we can keep our simple rules. +1 to this, or to Carsten's expanded version with a per-bundle and per-path setting. To clarify: Carsten and my proposal are the same. My setting is also intended for a per-path setting much like we already have proposed for auto-checkin on versionable nodes. Regards Felix
Re: Content Overwrite in the Content Loader
On Wed, Apr 16, 2008 at 11:06 AM, Carsten Ziegeler [EMAIL PROTECTED] wrote: ... Hmm, the more I think about it, the more I have the feeling that initial content comming from a bundle should only be used for static stuff - it should not be abused to get something into the repository which is intended to be changed by a user Not by an end user probably, but maybe by an admin or programmer. And the immutability of this content is not enforced anyway, so people will find creative uses for that ;-) -Bertrand
Re: Content Overwrite in the Content Loader
Bertrand Delacretaz wrote: On Wed, Apr 16, 2008 at 10:48 AM, Carsten Ziegeler [EMAIL PROTECTED] wrote: ...So the content loader should try to overwrite existing nodes and properties ? Yes. The only problem might be that a user has changed a property and this gets then overwritten by an update. But I think this is an expected behaviour Not sure - if people use content from bundles as initial content that's meant to be modified after being installed, overwriting their changes would be a nasty surprise. Hmm, the more I think about it, the more I have the feeling that initial content comming from a bundle should only be used for static stuff - it should not be abused to get something into the repository which is intended to be changed by a user. Carsten Handling this nicely might be a lot of work, as we'd need to keep track of what is untouched initial content and what has been modified. I don't have a simple solution ATM, but we should at least have a prominent warning somewhere when this happens. -Bertrand -- Carsten Ziegeler [EMAIL PROTECTED]
Re: Content Overwrite in the Content Loader
Felix Meschberger wrote: This all is actually the reason, why do not overwrite at the moment. We could of course add a setting to force overwrite: Sling-InitialContent /content;overwrite:=true /Sling-InitialContent Without this setting (or having it set to false), content is never overwritten. Hmpf, you beat me by 10 minutes :) I just wanted to come up with the same idea :( I assume, it's possible to specify several paths, like: Sling-InitialContent /content, /resources;overwrite:=true /Sling-InitialContent Carsten -- Carsten Ziegeler [EMAIL PROTECTED]
Re: Content Overwrite in the Content Loader
Hi, Am Mittwoch, den 16.04.2008, 11:21 +0200 schrieb Carsten Ziegeler: Bertrand Delacretaz wrote: On Wed, Apr 16, 2008 at 11:06 AM, Carsten Ziegeler [EMAIL PROTECTED] wrote: ... Hmm, the more I think about it, the more I have the feeling that initial content comming from a bundle should only be used for static stuff - it should not be abused to get something into the repository which is intended to be changed by a user Not by an end user probably, but maybe by an admin or programmer. And the immutability of this content is not enforced anyway, so people will find creative uses for that ;-) Yes, but I would assume that an admin or programmer knows what she does and how things work. If she doesn't, well, there are so many other traps. For instance, the same person could just delete all scripts in the repository and than wonder why nothing is working anymore. We definitly prevent someone from doing that :) This is actually the reason, why I like bundles : The casual user (or programmer or admin) just cannot easily tamper with the code. But this is for another thread ;-) Regards Felix
Re: Content Overwrite in the Content Loader
On Wed, Apr 16, 2008 at 11:04 AM, Felix Meschberger [EMAIL PROTECTED] wrote: ... We could of course add a setting to force overwrite: Sling-InitialContent /content;overwrite:=true /Sling-InitialContent Without this setting (or having it set to false), content is never overwritten Good idea to set this per bundle - in this way, the bundle author decides, and we can keep our simple rules. +1 to this, or to Carsten's expanded version with a per-bundle and per-path setting. -Bertrand
Re: Content Overwrite in the Content Loader
Hi, Am Mittwoch, den 16.04.2008, 10:56 +0200 schrieb Bertrand Delacretaz: On Wed, Apr 16, 2008 at 10:48 AM, Carsten Ziegeler [EMAIL PROTECTED] wrote: ...So the content loader should try to overwrite existing nodes and properties ? Yes. The only problem might be that a user has changed a property and this gets then overwritten by an update. But I think this is an expected behaviour Not sure - if people use content from bundles as initial content that's meant to be modified after being installed, overwriting their changes would be a nasty surprise. Handling this nicely might be a lot of work, as we'd need to keep track of what is untouched initial content and what has been modified. I don't have a simple solution ATM, but we should at least have a prominent warning somewhere when this happens. This all is actually the reason, why do not overwrite at the moment. We could of course add a setting to force overwrite: Sling-InitialContent /content;overwrite:=true /Sling-InitialContent Without this setting (or having it set to false), content is never overwritten. WDYT ? Regards Felix
[jira] Closed: (SLING-384) Replace logback in the osgi/log module
[
https://issues.apache.org/jira/browse/SLING-384?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Felix Meschberger closed SLING-384.
---
Resolution: Fixed
Replaced logback by our own simple SLF4J implementation in Rev. 648644.
The size of the bundle is drammatically reduced. Some overhead is removed from
the logging tool, so it might well be that logging performance is even better
(can probably still be enhanced)
The external configuration is still the same: We have rolling file support with
configuration of log file path, number of files to keep and maximum file size.
Also the log message pattern is still available but different: It is now a
java.util.MessageFormat pattern taking up to five arguments as follows:
{0} The timestamp of type java.util.Date
{1} the log marker (generally null, not used by Sling actually)
{2} the name of the current thread
{3} the name of the logger
{4} the debug level
{5} the actual debug message
The default pattern is changed to :
{0,date,dd.MM. HH:mm:ss.SSS} *{4}* [{2}] {3} {5}
Thus besides the date (incl. microseconds) the current thread name and logger
name along with the debug level and actual message are logged. If an exception
is logged, the dump is just appended to the message.
The log file is generally only rolled after a complete log entry (incl. stack
trace). This means, that files may get slightly bigger than the configured
maximum to take the complete last entry.
Replace logback in the osgi/log module
--
Key: SLING-384
URL: https://issues.apache.org/jira/browse/SLING-384
Project: Sling
Issue Type: Bug
Components: OSGi
Reporter: Felix Meschberger
Assignee: Felix Meschberger
Fix For: 2.0.0
The osgi/log module currently includes LogBack [1] as the logging backend.
This library is licensed under LGPL 3.0, which makes it hard to include in
Sling. In addition, the full functionality of LogBack is probably not used at
all.
The goal of this issue is to replace LogBack with a very simple
implementation of the SLF4J API suitable for our needs, that is:
* Log to a file or to the console
* Support log file rotation
* Support simple log message formatting
[1] http://www.logback.org
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: Where does the name Sling come from?
Hi Bertrand, I had the same question in my mind from the time I came to know of this project. I was trying to solve it myself :-). This might not be the best source for coming out with an answer to this question but I thought of helping out with my finding. Slinging org has a description about a weapon called sling by Romans etc. http://slinging.org/index.php?page=a-brief-history-of-the-sling---chris-harrison I guess it's possible to relate the capabilities of Apache Sling around this weapon. janandith. On Tue, Apr 15, 2008 at 3:10 PM, Bertrand Delacretaz [EMAIL PROTECTED] wrote: Hi, I guess we need an explanation from Uncle Felix on that one ;-) For now, I've added a placeholder at http://cwiki.apache.org/confluence/display/SLINGxSITE/Index to remind us to add the information. Using the word Catapult in this thread is forbidden by the Geneva convention. -Bertrand
Re: question about adding a bundle using launchpad net beans 5.0 warning.
Hi , Thanks a lot. I'm sorry i didn't know screenshots are not allowed in the mailing list. I have configured my project to use java 6. Therefore I guess then there is a conflict with BSF 3.0 which causes the warning. I havent implemented any code for the engine yet. I have to get more insight in to Scala first. Can you tell me where can i place my scripts to be loaded by Sling for testing ?. Thanks again for the valuable advice. regards, janandith. On Wed, Apr 16, 2008 at 2:57 PM, Bertrand Delacretaz [EMAIL PROTECTED] wrote: On Wed, Apr 16, 2008 at 10:29 AM, Felix Meschberger [EMAIL PROTECTED] wrote: ...For maven build we have created the correct project setup to prevent this kind of collision even if using JDK 6 to build FWIW, I recently noticed that our continuum builds on vmbuild.apache.org run under java 6, here's an excerpt from a vmbuild notification: Building machine hostname: vmbuild.apache.org Operating system : Linux(unknown) Java Home version : java version 1.6.0_05 Java(TM) SE Runtime Environment (build 1.6.0_05-b13) Java HotSpot(TM) Client VM (build 10.0-b19, mixed mode, sharing) Builder version : Maven version: 2.0.7 Java version: 1.6.0_05 OS name: linux version: 2.6.20-16-server arch: i386 -Bertrand
Re: question about adding a bundle using launchpad net beans 5.0 warning.
Hi Janandith, Am Mittwoch, den 16.04.2008, 16:40 +0600 schrieb janandith jayawardena: Hi , Thanks a lot. I'm sorry i didn't know screenshots are not allowed in the mailing list. I have configured my project to use java 6. Therefore I guess then there is a conflict with BSF 3.0 which causes the warning. alright. I havent implemented any code for the engine yet. I have to get more insight in to Scala first. Can you tell me where can i place my scripts to be loaded by Sling for testing ?. Probably the easiest way to create some content and an initial script is following the steps of the Create some content section of the Sling Launchpad page [1]. Instead of creating a JavaScript file, you would create the scala file, which would be taken provided the ScalaScriptEngineFactory is correctly loaded. Regards Felix [1] http://incubator.apache.org/sling/site/discover-sling-in-15-minutes.html Thanks again for the valuable advice. regards, janandith. On Wed, Apr 16, 2008 at 2:57 PM, Bertrand Delacretaz [EMAIL PROTECTED] wrote: On Wed, Apr 16, 2008 at 10:29 AM, Felix Meschberger [EMAIL PROTECTED] wrote: ...For maven build we have created the correct project setup to prevent this kind of collision even if using JDK 6 to build FWIW, I recently noticed that our continuum builds on vmbuild.apache.org run under java 6, here's an excerpt from a vmbuild notification: Building machine hostname: vmbuild.apache.org Operating system : Linux(unknown) Java Home version : java version 1.6.0_05 Java(TM) SE Runtime Environment (build 1.6.0_05-b13) Java HotSpot(TM) Client VM (build 10.0-b19, mixed mode, sharing) Builder version : Maven version: 2.0.7 Java version: 1.6.0_05 OS name: linux version: 2.6.20-16-server arch: i386 -Bertrand
Reusing launchpad-app/-webapp
Hi, I'm currently using the launchpad/webapp to build my own webapp. All I need from the webapp are the configuration files for Sling and the classes which launch Sling; no bundles etc. Now, this works, but unfortunately the current webapp is about 40mb, and I only need some files out of it. So it would be great if we could solve this somehow, perhaps by splitting the configuration and classes into an own project? Carsten -- Carsten Ziegeler [EMAIL PROTECTED]
Re: Reusing launchpad-app/-webapp
On Wed, Apr 16, 2008 at 1:22 PM, Carsten Ziegeler [EMAIL PROTECTED] wrote: I'm currently using the launchpad/webapp to build my own webapp. All I need from the webapp are the configuration files for Sling and the classes which launch Sling; no bundles etc. Now, this works, but unfortunately the current webapp is about 40mb, and I only need some files out of it. So it would be great if we could solve this somehow, perhaps by splitting the configuration and classes into an own project? I would love to see this as I'm using Sling for the pretty much exact same purpose. The only bundle I'm really interested in is the admin GUI which is moving to Felix. If a separation of the launchpad was done, would it not be suitable for moving to Felix as well as it would be a generic OSGi launcher (if I understood your proposal correctly Carsten)? /niklas
Re: Reusing launchpad-app/-webapp
On Wed, Apr 16, 2008 at 1:22 PM, Carsten Ziegeler [EMAIL PROTECTED] wrote: ...it would be great if we could solve this somehow, perhaps by splitting the configuration and classes into an own project?... In theory, if the two org.apache.sling.launcher.webapp classes move to another maven module, one would only need to create a pom.xml, web.xml and jcr-client.properties (not sure what that file does exactly) to create a different Sling-based webapp. The problem is that the current launchpad/webapp pom contains quite a lot of maven procedural code disguising as plugin configurations, to unpack the launchpad/app dependency and keep only what's needed. So making it easier to build Sling-based webapps might be a bit more complicated than just moving the classes to a different module. But I'm all for it if someone makes it happen! -Bertrand
Re: Simplifying script paths and names?
Hi, On Mon, Apr 14, 2008 at 6:26 PM, Alexander Klimetschek [EMAIL PROTECTED] wrote: ... /apps/foo/selector/html.esp /apps/foo/selector.html.esp (same but with dots instead a subfolder) /apps/foo/foo.selector.html.esp (NEW, for unique filenames of selector scripts) /apps/foo/selector.esp /apps/foo/foo.selector.esp (NEW, for unique filenames of selector scripts) /apps/foo/html.esp (not specific to the selector) /apps/foo/foo.esp (not specific either)... I like this, and IIUC the what to use for pdf problem mentioned by Carsten is also solved, using /apps/foo/selector.pdf.esp for example? I don't like removing the slash after foo, for example /apps/foo.selector.html.esp, because that means that some foo scripts are outside of the foo folder. Having them all under /apps/foo/ makes it much easier to copy and move complete applications. I'm not sure if I'd be able to implement this before our first release, that depends on other priorities in my current project. -Bertrand
Re: Reusing launchpad-app/-webapp
Niklas Gustavsson wrote: On Wed, Apr 16, 2008 at 1:22 PM, Carsten Ziegeler [EMAIL PROTECTED] wrote: I'm currently using the launchpad/webapp to build my own webapp. All I need from the webapp are the configuration files for Sling and the classes which launch Sling; no bundles etc. Now, this works, but unfortunately the current webapp is about 40mb, and I only need some files out of it. So it would be great if we could solve this somehow, perhaps by splitting the configuration and classes into an own project? I would love to see this as I'm using Sling for the pretty much exact same purpose. The only bundle I'm really interested in is the admin GUI which is moving to Felix. If a separation of the launchpad was done, would it not be suitable for moving to Felix as well as it would be a generic OSGi launcher (if I understood your proposal correctly Carsten)? Yes, this would be the result. Carsten -- Carsten Ziegeler [EMAIL PROTECTED]
Re: Simplifying script paths and names?
Bertrand Delacretaz wrote: Hi, On Mon, Apr 14, 2008 at 6:26 PM, Alexander Klimetschek [EMAIL PROTECTED] wrote: ... /apps/foo/selector/html.esp /apps/foo/selector.html.esp (same but with dots instead a subfolder) /apps/foo/foo.selector.html.esp (NEW, for unique filenames of selector scripts) /apps/foo/selector.esp /apps/foo/foo.selector.esp (NEW, for unique filenames of selector scripts) /apps/foo/html.esp (not specific to the selector) /apps/foo/foo.esp (not specific either)... I like this, and IIUC the what to use for pdf problem mentioned by Carsten is also solved, using /apps/foo/selector.pdf.esp for example? I don't like removing the slash after foo, for example /apps/foo.selector.html.esp, because that means that some foo scripts are outside of the foo folder. Having them all under /apps/foo/ makes it much easier to copy and move complete applications. So, you would duplicate the last path element instead? (like .../foo/foo.esp instead of .../foo.esp) I'm not sure if I'd be able to implement this before our first release, that depends on other priorities in my current project. I would love to see a complete description (followed by a discussion/vote) before changing/implementing something. Carsten -- Carsten Ziegeler [EMAIL PROTECTED]
Re: Simplifying script paths and names?
Hi all,
Basically, I agree with the proposed extensions. But we should try to
not exagerate ... After all we have to concoct this all (1) in a decent
description and (2) into code.
So to continue my discussion, lets add another example:
resource type = sling:sample
uri = /foo/bar.print.a4.html
thus
resource type path = sling/sample
selector string = print.a4
extension = html
First lets reconsider how a script is looked up today (assume a search
path of [ /apps, /libs ] :
(1) check for resource type
/apps/sling/sample/print/a4/html.*
/apps/sling/sample/print/html.*
/apps/sling/sample/html.*
/libs/sling/sample/print/a4/html.*
/libs/sling/sample/print/html.*
/libs/sling/sample/html.*
/apps/sling/sample/print/a4/GET.*
/apps/sling/sample/print/GET.*
/apps/sling/sample/GET.*
/libs/sling/sample/print/a4/GET.*
/libs/sling/sample/print/GET.*
/libs/sling/sample/GET.*
(2) check for resource super type
{ repeat above steps for resource super types }
(3) check for default servlet
/apps/sling/servlet/default/print/a4/html.*
/apps/sling/servlet/default/print/html.*
/apps/sling/servlet/default/html.*
/libs/sling/servlet/default/print/a4/html.*
/libs/sling/servlet/default/print/html.*
/libs/sling/servlet/default/html.*
/apps/sling/servlet/default/print/a4/GET.*
/apps/sling/servlet/default/print/GET.*
/apps/sling/servlet/default/GET.*
/libs/sling/servlet/default/print/a4/GET.*
/libs/sling/servlet/default/print/GET.*
/libs/sling/servlet/default/GET.*
This is - ignoreing resource super types - at most 24 checks ! Agreed,
this is worst case but falling back to the default GET servlet really
requires this number and I think, this is not really worst case, but
realistic.
Now lets add support for scripts named after the last part of the
resource type, e.g. sample here: For each check for html.* we add
another check for that name :
(1) check for resource type
/apps/sling/sample/print/a4/html.*
/apps/sling/sample/print/html.*
/apps/sling/sample/html.*
/apps/sling/sample/sample.html.*
/apps/sling/sample/sample.*
/libs/sling/sample/print/a4/html.*
/libs/sling/sample/print/html.*
/libs/sling/sample/html.*
/libs/sling/sample/sample.html.*
/libs/sling/sample/sample.*
/apps/sling/sample/print/a4/GET.*
/apps/sling/sample/print/GET.*
/apps/sling/sample/GET.*
/libs/sling/sample/print/a4/GET.*
/libs/sling/sample/print/GET.*
/libs/sling/sample/GET.*
(2) check for resource super type
{ repeat above steps for resource super types }
(3) check for default servlet
/apps/sling/servlet/default/print/a4/html.*
/apps/sling/servlet/default/print/html.*
/apps/sling/servlet/default/html.*
/apps/sling/servlet/default/sample.html.*
/apps/sling/servlet/default/sample.*
/libs/sling/servlet/default/print/a4/html.*
/libs/sling/servlet/default/print/html.*
/libs/sling/servlet/default/html.*
/libs/sling/servlet/default/sample.html.*
/libs/sling/servlet/default/sample.*
/apps/sling/servlet/default/print/a4/GET.*
/apps/sling/servlet/default/print/GET.*
/apps/sling/servlet/default/GET.*
/libs/sling/servlet/default/print/a4/GET.*
/libs/sling/servlet/default/print/GET.*
/libs/sling/servlet/default/GET.*
This is just beginning and we generate a whole lot of combinations (task
for the student: How many, actually ? ) and we not even started using
the selector as dot-separated instead of a relative path (slash
separated).
Don't get me wrong: I am all for simplifying matters. But for now we are
merely adding more options And this is not simplifying at all.
So here is my proposal: We don't search a subtree below the resource
type path anymore but expect the scripts to all be in the same folder.
That is the selector string is used as is as a file name part. To find a
script we apply a longest substring match. The generic script name would
then be:
{pathPrefix}/{resourceTypePath}/{resourceTypeLabel}.{selectorString}.{extension}.*
where:
{pathPrefix}- search path prefix, e.g. /apps
{resourceTypePath} - resource type converted to path, e.g.
sling/sample
{resourceTypeLabel} - last part of resource type converted, e.g.
sample
{selectorString}- the selector string, e.g. print.a4
{extension} - the request extension, e.g. html, but may also
be GET
* - any script extension
The implementation is probably very easy: We just find a script whose
name has the most specific match in terms of selectorString and
extension. Because all scripts are looked up in the same parent node, we
can just get a single listing and look for the best match. (working on
subtrees we have to access pretty exhaustive with multiple listings etc.
This is, of course, not compatible with what we do currently (with
respect to selectors). But I am convinced, that we have to make a
concession on one end to get the other end. We cannot
Re: Reusing launchpad-app/-webapp
Hi, Am Mittwoch, den 16.04.2008, 13:22 +0200 schrieb Carsten Ziegeler: I'm currently using the launchpad/webapp to build my own webapp. All I need from the webapp are the configuration files for Sling and the classes which launch Sling; no bundles etc. Now, this works, but unfortunately the current webapp is about 40mb, and I only need some files out of it. So it would be great if we could solve this somehow, perhaps by splitting the configuration and classes into an own project? To recap we currently have the launchpad/app and launchpad/webapp modules. The first contains the main launcher classes as well as a sling.properties file for use. In addition when building the project most Sling bundles as well as some Felix bundles are added into the final jar file to be installed on first startup. The webapp module extends the app module and shuffles the classes and integrated bundles around. Now, it would of course possibly be interesting to have this all in a single module ? What is the price we pay ? (1) The app has a Main class not used by the serlvet and the webapp has a Servlet not used by the app. This is not much, so could probably be merged. (2) The app has the bundles in resources/bundles while the webapp has them under WEB-INF/resources/bundles. When merging the app would probably also have to look for the resources under WEB-INF. This would be kind of strange. Same holds for the sling.properties file - but this we could also put in the classes folder in the web app ... So here is my proposal: We create a launchpad/core module, which just contains the classes from the app and web app module and combine them in a single (simple) jar file. In addition the core sling.properties file would also be part of this jar file. This jar file, by itself is not usable. The launchpad/app module would have a dependency on the core module and just unpack the classes and properties file - through the maven dependency plugin. We also need to get the bundles into the jar. The launchpadd/webapp module also would have a dependency on the core module, but would pack the core jar file into the WEB-INF/lib folder unmodified. Again, we need to get the bundles into the jar and the of course the web.xml file. Now my question is: both launchpad/app and launchpadd/webapp use the same set of bundles. Is there a way of sharing this common knowledge between the app and webapp modules without creating a dependency on the app module in the webapp module ? Could the maven assembly plugin be used for this ? If we split like this, we could also make the launchpadd/jcrapp module simpler by just adding the dependency to the launchpad/core module and setup the dependency list. Is this correct ? Does this make sense ? Regards Felix
Re: Reusing launchpad-app/-webapp
Hi, Am Mittwoch, den 16.04.2008, 14:19 +0200 schrieb Niklas Gustavsson: On Wed, Apr 16, 2008 at 1:22 PM, Carsten Ziegeler [EMAIL PROTECTED] wrote: I'm currently using the launchpad/webapp to build my own webapp. All I need from the webapp are the configuration files for Sling and the classes which launch Sling; no bundles etc. Now, this works, but unfortunately the current webapp is about 40mb, and I only need some files out of it. So it would be great if we could solve this somehow, perhaps by splitting the configuration and classes into an own project? I would love to see this as I'm using Sling for the pretty much exact same purpose. The only bundle I'm really interested in is the admin GUI which is moving to Felix. If a separation of the launchpad was done, would it not be suitable for moving to Felix as well as it would be a generic OSGi launcher (if I understood your proposal correctly Carsten)? Not sure, actually. In fact the Felix project has a launcher (in the main project). At the time we started this launcher/launchpad business here in Sling, I decided to not go with the Felix main project but start my own (based on Felix main, though) to be able to inject my properties file and manage a runtime copy as well as integrate command line and web app starts as much as possible. Therefore, I do not think, we should actually move our launcher. What you of course can do, if you only need the console, is to use the Felix main programm and add the console as well as any additional requirements there. To run the console, you do not need anything from the Sling project at all. Hope this helps. Regards Felix
Re: Simplifying script paths and names?
Felix Meschberger wrote:
This is just beginning and we generate a whole lot of combinations (task
for the student: How many, actually ? ) and we not even started using
the selector as dot-separated instead of a relative path (slash
separated).
Don't get me wrong: I am all for simplifying matters. But for now we are
merely adding more options And this is not simplifying at all.
Yes, that were exactly my fears with the proposal as well. And that's
why I suggested to change the current solution by using file names
instead of paths :)
So here is my proposal: We don't search a subtree below the resource
type path anymore but expect the scripts to all be in the same folder.
That is the selector string is used as is as a file name part. To find a
script we apply a longest substring match. The generic script name would
then be:
{pathPrefix}/{resourceTypePath}/{resourceTypeLabel}.{selectorString}.{extension}.*
where:
{pathPrefix}- search path prefix, e.g. /apps
{resourceTypePath} - resource type converted to path, e.g.
sling/sample
{resourceTypeLabel} - last part of resource type converted, e.g.
sample
{selectorString}- the selector string, e.g. print.a4
{extension} - the request extension, e.g. html, but may also
be GET
* - any script extension
The implementation is probably very easy: We just find a script whose
name has the most specific match in terms of selectorString and
extension. Because all scripts are looked up in the same parent node, we
can just get a single listing and look for the best match. (working on
subtrees we have to access pretty exhaustive with multiple listings etc.
Yes, this looks good to me and makes everything simpler.
This is, of course, not compatible with what we do currently (with
respect to selectors). But I am convinced, that we have to make a
concession on one end to get the other end. We cannot easily get all.
Exactly, that's why I wanted to discuss this before a release :)
Carsten
--
Carsten Ziegeler
[EMAIL PROTECTED]
Re: Reusing launchpad-app/-webapp
On Wed, Apr 16, 2008 at 5:54 PM, Felix Meschberger [EMAIL PROTECTED] wrote: What you of course can do, if you only need the console, is to use the Felix main programm and add the console as well as any additional requirements there. To run the console, you do not need anything from the Sling project at all. The part I primiraly use in Sling is the launcher webapp, as far as I know there's nothing similar in Felix? /niklas
