THIS IS A TEST INSTANCE. ALL YOUR CHANGES WILL BE LOST!!!!
...
Using the userManager:
| Code Block |
|---|
curl \ -F"oldPwd=admin" \ -F"newPwd=Fritz" \ -F"newPwdConfirm=Fritz" \ http://admin:admin@localhost:8080/system/userManager/user/admin.changePassword.html |
You will also have to set that password in the Felix Web Management Console (/system/console/configMgr) under "Apache Sling Embedded JCR Repository." This is used by Sling to create an admin JCR session (using SlingRepository.loginAdministrative()) for components that need to have full access to the repository.
...
Now you should be able to see an HTML version of the resource at http://localhost.local:8080/content/greet
. This script matches the sling:resourceType we set and the HTTP method we used. Note that resourceType matches must be exact.
...
| Code Block |
|---|
<html>
<%
// Get version node UUID, which is the second selector
var uuid = null;
var sel = request.getRequestPathInfo().getSelectors();
if(sel.length >= 2) {
uuid = sel[1];
} else {
response.sendError(400, "Version node UUID must be given as second selector");
}
// Get version node
var v = currentNode.getSession().getNodeByUUID(uuid);
var frozen = v.getNode("jcr:frozenNode");
var title = frozen.title;
%>
<body>
<h1>Version of node <%= currentNode.getPath() %></h1>
Name: <b><%= v.getName() %></b><br/>
UUID: <b><%= uuid %></b><br/>
Path: <b><%= v.getPath() %></b><br/>
Frozen node path: <b><%= frozen.getPath() %></b><br/>
<% if(title) { %>
Frozen node title: <b><%= frozen.getProperty("title") %></b><br/>
<% } else { %>
Frozen node does not have a title property
<% } %>
</body>
</html>
|
...
The second trick here is that the versioned data is saved as a "jcr:frozenNode" node under the Version node. This is explained for example at http://www.onjava.com/lpt/a/6784 .
How do I find out why a given script or servlet is preferred to another when processing a request?
...
| No Format |
|---|
content --gradapp ----application --------app1 --------app2 ------------tabs ----------------tab1 ----------------tab2 apps --gradapp ----application --------edit.esp --------html.esp --------list.esp ----tab --------edit.esp |
In this case, http://localhost:8888/gradapp/application/app1.edit.html will provide an edit page for the app1 resource using the script from apps/gradapp/application/edit.esp. However, http://localhost:8888/gradapp/application/*.edit.html will not use that edit.esp script.
...
for showing the tab form.
See: http://markmail.org/message/htl6r3uctuzb6l5q and http://mail-archives.apache.org/mod_mbox/sling-users/200911.mbox/%3c8A802DC6-7472-4040-807A-D55524F30D3E@gmail.com%3e
How to replace the default json renderer (for example) with my own?
...
If on the other hand you cannot prevent the installation of such bundles and hence the export of the respective packages, you might want to set the org.osgi.framework.bootdelegation property conditionally as described above in the answer to how this property is supported in Sling. This ensures the property is only set, if the classes are actually available. This should be used as a fall back only, if the org.osgi.framework.system.packages method does not work.
How to share session between Sling and other web applications?
It is some times required to share HTTP session between Sling and other web applications. This is typically needed when existing Web MVC applicatios are getting migrated to Sling.
Most leading application servers (Oracle Weblogic, IBM Websphere) allow feature called 'shared session context'. It is allowed to share HTTP session between two web applications packaged in single EAR archive.
For sharing session with Sling, you need to package launchpad.war in to the EAR with other WARs. Sling is little tricky, because its not just a WAR. Its based on OSGI and on top of Web application classloading rules, it is also bounded by OSGI classloading rules.
I will explain configuration with weblogic here, because thats what I have tried out. Configuration in IBM Websphere should be similar.
The approach to share classes and session in Sling with other web
application in weblogic is as following.
1. Package CQ/Sling as web application in an existing EAR.
2. Deploy system.bundle extension fragment exporting all the packages
that you need to access in CQ.
3. In Weblogic, there are two ways to share classes
a) Put all the shared jars in APP-INF/lib directory in EAR. With
this approach you do not need Class-Path entries in MANIFEST.MF. And
classes are loaded by EAR classloader.
b) Put jars in some common lib in ear. Say EAR/lib. Then in all
the web applications have Class-path entry in MANIFEST.MF to list the
jars in EAR/lib. Make sure all the classes in shared jars are
serializable.
Update MANIFEST.MF in launchpad.war to have same Class-Path entries.
Now whenever you access a session object by
request.getSession().getAttribute(), the object will be serialized,
and then deserialized again. While deserialzing, it will resolve class
by Launchpad's classloader.
APP-INF/lib is the prefered approach to MANIFEST.MF, as the later
is adding unnecessary overhead of serialization and deserialization
for session sharing within same JVM.
In J2EE 5, there is addition of library element in
application.xml in EAR, which allows you to define EAR level library.
That is much cleaner than above two approaches.
There is one more approach that was tried out in our case. This is buggy and will not work, but I am explaining it here so that anyone else trying it out knows that it does not work.
1. In this approach, instead of deploying a system.bundle extension fragment, you package all the shared jars in an OSGI bundle and export all the shared packages from that bundle.
2. This seems to resolve classes only in JSPs in sling but fails in Sling servlets with ClassCastException.
The reason for this is as following.
Weblogic uses context classloader of the thread to resolve classes while deserializing session objects. When JSP is processed in Sling, the context classloader is set to org.apache.sling.commons.classloader.impl.ClassLoaderFacade
This classloader can find all the classes ex ported from OSGI bundles loaded in felix.
So, when session attributes are accessed from migrated JSPs in CQ, the objects used to get serialized, and then deserialized. While deserializing, the classes were resolved by org.apache.sling.commons.classloader.impl.ClassLoaderFacade.
Even if it appeared to work fine, this is not the right solution for the problem at all. The worst part here is that, once the object is deserialized, weblogic replaces original object reference to the deserialized object. So if any other WAR needs the object again, it needs to be serialized/deserialized again. But that works only if original object is loaded with weblogic classloader. So once object is serialized/deserialized with Sling classloader, it will never be serialized/deserialized for other WARs and you will always get ClassCastException. e.g. If CustomerDetailVO is once accessed from CQ JSP component, any other WAR, like OnlineCustomerDetail.war, trying to get CustomerDetailVO from session will get ClassCastException. This happens because, when CustomerDetailVO is accessed by CQ component JSP, it is serialized/deserialized and resolved using org.apache.sling.commons.classloader.impl.ClassLoaderFacade. If its accessed in any other WAR after that, it will not be serialized again and we will get ClassCastException.
It did not work with Sling Servlets because, when servlet is executed, the context classloader is weblogic.utils.classloaders.ChangeAwareClassLoader. This classloader finds classes in EAR or classpath, so we get ClassCastException. Even here, some weblogic classloader magic is going on. The context classloader here, is the classloader for launchpad.war. This is the WAR file for CQ. The classes referred by servlet can not be loaded by this classloader, because classes exported from OSGI bundles are not visible to this classloader. So welogic, seeing the ClassNotFoundException from context classloader, uses the WAR classloader of the WAR which set the object in the session. Obviously, we get ClassCastException in the sling servlet.
So class/session sharing should never be done with classes packaged
and exported in an OSGI bundle. Relying on weblogic to serialize and
deserialize is always likely to fail.
System fragment extensions is the only safer approach in this case.
Miscellaneous
Why can't I connect to Sling's WebDAV using Windows NetworkDriveMapping ?
...