Archive for 'December 2010'

Posted by Michael Marth DEC 17, 2010

Posted in cq5, crx, java content repository, ria, sling and tutorials Comments 5



Flexling: CRX for Flex developers

Flex developers interested in working with CRX or CQ5 might want to have a look at a package I have recently uploaded to the public section of the Package Share. It is called "Flexling" and contains:


• an Actionscript library for read and write access to CRX (as well as search)
• a help file and API docs for the library
• an example Flex application

Preview of the package:



After installation of the package point your browser to localhost:(port)/apps/flexling/docs/flexling.html where the introductory document is located.



How it works

The library basically wraps the Sling http API into an Actionscript object com.day.sling.Sling. There are three methods for reading and searching content: getContent (synchronous), loadContent (asynchronous) and search (asynchronous). Under the hood these leverage the json rendering of JCR content that Sling provides. In a similar fashion the methods saveContent and removeContent wrap the SlingPostServlet's functionality for writing to the repository (both are asynchronous).  All asynchronous methods dispatch com.day.sling.SlingEvent events when done (inherited from flash.events.Event).

The method getContent exists basically for educational purposes - loadContent would be sufficient to read from the repository. getContent shows how to leverage the browser's XHR object for reading from the repository (using flash.external.ExternalInterface) while loadContent uses the flash.net.URLLoader.


Alternatives

Through flash.external.ExternalInterface there is actually a third possibility to interface the repository (though not implemented in this package): Sling provides a Javascript file located at /system/sling.js (Apache svn http://svn.apache.org/repos/asf/sling/trunk/bundles/servlets/post/src/main/resources/system/sling.js). You could use e.g. Sling.httpGet to retrieve content.

This is exactly the approach taken by the Flex-based CQ5 standard slideshow component (see screenshot below). It ships with the complete Flex source code in the repository at /libs/foundation/components/slideshow/src.




Kudos to Josh Oransky who collaborated with me on the Flexling package.

Posted by Bertrand Delacretaz DEC 15, 2010

Posted in apache, java content repository, jcr and open source Comments 11



Apache leaves the JCP, what's next?

Written by David Nuescheler and Bertrand Delacretaz

The Apache Software Foundation (ASF) recently announced (https://blogs.apache.org/foundation/entry/the_asf_resigns_from_the) that it is leaving the Executive Committee of the JCP (http://www.jcp.org/) and that it will be "removing all official representatives from any and all JSRs".

In this post, we present our perspective on the impact of this decision for Java in general, and more specifically on JCR - the Java Repository API on which our products are based.

Impact on future Java API specs

As David's graph below shows, JCP activity has been going down to very low levels in recent years.



This might be due to uncertainty about the JCP's future since the Apache/Sun dispute started (http://www.apache.org/jcp/sunopenletterfaq.html) in 2006, but also very probably to a lack of need.

The Java language is a mature one, which has found its (large) niche. Do you really care about improvements in Java SE 7 and 8? We don't see much enthusiasm and the vast majority of programmers seem to be happy with Java SE 5 or 6.

In the API space, OSGi for example, brings real innovation, independently from the JCP. The OSGi alliance (http://www.osgi.org/) that manages it is working fine. As with any API spec that's outside of the JCP, OSGi is not allowed to use package names starting with javax, but...did you even notice that? It doesn't make much of a difference.

Many Java APIs are also being developed outside of the JCP, at the ASF, in other open source organizations and in industry consortiums. Their specification processes might not always be as formalized as the JCP's, but as long as one gets a versioned set of documented Java interfaces that a group of experts agrees on, along with a test suite, people are happy. This looks sufficient to us for the evolution (as opposed to a revolution, which is not needed) of the Java ecosystem.

So, on one hand the need for new Java APIs is not as big as it used to, and on the other hand there are other places where APIs can be developed.

Even a totally inactive JCP wouldn't have a serious impact on future Java APIs, in our opinion.

Impact on Java in the content management space

We don't think the JCP and the ASF going separate ways will have any impact on enterprise software in general and in the content management space in particular.

There even may be surprisingly little impact on Java based Apache projects. Apache Jackrabbit, which has been widely adopted as infrastructure for many content management related projects, will continue its development as planned.

Beyond Jackrabbit and Apache Sling, there are a large number of Java based content management projects outside the ASF which are not impacted, and we continue to see a vibrant Java content management community.

Impact on JCR

There are some minimum requirements put on spec leads by the JCP in terms of licensing. Since it is up to the spec lead of a JSR, the licensing varies from spec lead to spec lead.

As the spec lead for JCR (JSR-170, JSR-283 and ongoing work on JSR-333) we opted for the most open licensing we could use for those JSRs:

• http://www.day.com/specs/jcr/2.0/license.html
• http://www.day.com/content/dam/day/downloads/jsr283/LICENSE.txt
• http://www.day.com/day/en/products/jcr/jsr-283.html

The JCR APIs are also available from the central Maven repository under http://repo2.maven.org/maven2/javax/jcr, without requiring any click-through or other agreement.

The official test suites (TCK) for those JSR specs have been contributed to the Apache Jackrabbit project under the Apache CCLA (http://www.apache.org/licenses/cla-corporate.txt) and as such are freely available to anyone under the permissive and business-friendly Apache License.

Our ongoing work on JSR-333, the next release of the JCR API, is also unaffected by the ASF leaving the JCP. We are acting as Day/Adobe employees or individuals there, not as representatives of the Apache Software Foundation.

Impact on CQ5 and CRX

As we don't see any impact on JCR, we are not planning any changes concerning CQ5 and CRX in this area. JCR continues to gain momentum in the WCM industry and beyond, so we are looking forward to an even broader use of JCR.

Conclusions

In bad pun mode we could say nothing new under the Oracle.

Apache leaving the JCP is a step that was discussed for years, that helps clarify the situation and might help Oracle be more explicit about their plans for Java. People might need to find other places than the JCP to create new specifications, but our work on existing and in-process JSRs is not affected.

We're happy to have invested lots of energy in keeping the JCR specs that we're leading as open as possible. This helps the community understand that one can produce specifications, reference implementations and TCKs in an open manner, even within the JCP. Openness always pays, when it comes to creating sustainable ecosystems.

Full disclosure: David Nuescheler is a member of the ASF and Spec Lead for JSR 170, 283 and 333, and Bertrand Delacretaz is a member and board member of the ASF. So consider the above as educated but personal opinions, not wearing any particular ASF or JCP hat.

Posted by Jean-Christophe Kautzmann DEC 07, 2010

Add comment



Getting Resources and Properties in Sling

The Resource is one of the central parts of Sling. Extending from JCR's Everything is Content, Sling assumes Everthing is a Resource. Thus Sling is maintaining a virtual tree of resources, which is a merger of the actual contents in the JCR Repository and resources provided by so called resource providers. By doing this Sling fits very well in the paradigm of the REST architecture.

In this article we will explore a few ways to programmatically map a resource path (String) to a resource object (Resource) and its properties in Sling, from within an OSGI service, a servlet and a JSP.

The whole game consists in first getting a ResourceResolver and then getting the Resource itself.

Within an OSGI Service/Compoment

You can access a resource through the JcrResourceResolverFactory service:


/** @scr.reference */
private SlingRepository repository;

/** @scr.reference */
private JcrResourceResolverFactory resolverFactory;

public void myMethod() {
   Session adminSession = null;
   try {
      String resourcePath = "path/to/resource";
      adminSession = repository.loginAdministrative(null);
      ResourceResolver resourceResolver = resolverFactory.getResourceResolver(adminSession);
      Resource res = resourceResolver.getResource(resourcePath);
   } catch (RepositoryException e) {
       log.error("RepositoryException: " + e);
   } finally {
      if (adminSession != null && adminSession.isLive()) {
         adminSession.logout();
         adminSession = null;
      }
   }
}



Within a Servlet

You can access the resource defined by the request URL through the SlingHttpServletRequest:



Resource res = req.getResource();
// req is the SlingHttpServletRequest


You can access any resource by first accessing the ResourceResolver:



String resourcePath = "path/to/resource";
ResourceResolver resourceResolver = req.getResourceResolver();
// req is the SlingHttpServletRequest
Resource res = resourceResolver.getResource(resourcePath);


Within a JSP file

When you use the <sling:defineObjects> tag in a JSP file, you have access to a few handy objects, one of them is 'resource', the resource that is resolved from the URL. Another one is 'resourceResolver', the ResourceResolver defined through the SlingHttpServletRequest.

To access a resource:



<sling:defineObjects>
<%
String resourcePath = "path/to/resource";
Resource res = resourceResolver.getResource(resourcePath);
%>


For a list of all the objects available through this tag, please refer to the JSP Tag Libraries page.


If needed you can adapt a Sling Resource to a JCR Node:



Node node = resource.adaptTo(Node.class);


Note: resource.adaptTo(Node.class) may return null if the resource is not backed by a JCR node. This is particularly the case for NonExistingResource resources or resource provided by a non-JCR resource provider.

Accessing a Property

The ValueMap is an easy way to access properties of a resource. With most resources you can use Adaptable.adaptTo(Class) to adapt the resource to a value map:



ValueMap properties = res.adaptTo(ValueMap.class);
// res is the Resource


You can also access the properties through the ResourceUtil utility class:



ValueMap properties = ResourceUtil.getValueMap(res);
// res is the Resource


Then, to access a specific String property called 'propName':



String rule = properties.get(propName, (String) null);


For more details about resources and how to access them in Sling, you can refer to the Sling documentation about Resources .



Posted by Kas Thomas DEC 04, 2010

Posted in jcr, news and php Comment 1



A PHP Port of JCR

David Buchmann of Liip reports that the Jackalope project has all but finished porting the Java Content Repositry API (JCR) to PHP. Work on PHPCR began last year. Buchmann says: "With lots of input from Benjamin Eberlei and discussions on the Symfony2 cmf project mailing lists, I stripped all Java specific stuff out of the PHPCR API, making it more PHP. Most notably, we got rid of all the elements that are only relevant in strongly typed languages. Plus PHPCR now specifies to use the standard PHP iterators instead of specific classes that could not be used in foreach. If you had a look at the earlier interfaces, you will notice that we now use the PHP 5.3 namespaces. A full list of the changes is documented in from JCR to PHPCR.

While PHPCR defines an API, Jackalope is an implementation of that API. "In the last few weeks," Buchmann notes, "things got a real boost, as a full team at Liip is completing the implementation. We aim to have a beta release of Jackalope ready by the end of the year. Our implementation talks to the Java Jackrabbit backend for data storage. This is a quite performant setup, plus it allows to access data in existing Jackrabbit-based products. Ideas exist how we could write a PHP-only storage layer, but for now, we focus on creating a fully working implementation with Jackrabbit."

Buchmann says first performance tests are quite promising. He notes: "Chregu did a couple of performance tests and found that Jackrabbit scales really well. Having 15 Jackrabbits share one database backend with 350'000 nodes and doing requests scaled linearly and the database did not get overloaded."

For more details, see David Buchmann's post here.

Posted by Greg Klebus DEC 01, 2010

Posted in package Comments 2



Package Share Community for Higher Ed / North America



We have just launched a package share community for Adobe CQ5 Higher Education CQ5 User Group in North America. This CQ5 customer group has been very active already before -- they formed the Higher Ed CQ5 User Group back in 2009. After the latest Ignite 2010 in Chicago Erin Yarbrough from the University of Oklahoma contacted me and asked to set up a Package Share community for their user group.

And here it is - all the Higher Ed package share users from North America should see the new Higher Ed folder (in addition to their company's private folder). They all have read and write access to the new community folder. This way they can share content packages, projects, applications, packages, etc, in the group.




If you're interested in launching a community for your vertical or other customer / partner group (e.g., for a country or geography), let us know by writing to packageshare (at) adobe (dot) com!


Thanks again, Erin!