Sling Applications and Relational Databases
by Randall Hauch
Very interesting blog that is a use case around federattion with JCR.
Sling Applications and Relational Databases
One topic that periodically comes up is how to integrate data that
resides relational databases with a Sling application. The use case
might be that there is legacy data that cannot be migrated but needs
to displayed in a new (Sling-based) web application. In this post I
would like to discuss some aspects and possible strategies to
accomplish this goal.
One essential question for determining a fitting integration strategy
is if the db rows shall be exposed as resources (in the REST sense).
Let us start with the case that they shall not be exposed as
resources. In such a scenario a db row does not have its own URL. A
typical Sling application in such a scenario would expose the JCR-
based content as resources, but might add data from the db to the
presentation of the resources.
On a technical level this could be implemented by creating an OSGi
bundle that uses JDBC to connect to the database. The bundle would
then be called by the rendering script through an OSGi service
interface (as described here).
However, this approach cannot be used if the db rows shall be exposed
as resources and have their own URL.
For data that changes on low frequencies one can create a JCR node for
each db row. This requires the ability to keep the db and the JCR in
sync. The JCR nodes could contain the primary key of the db data.
Synching can be achieved by any programm capable of JCR and JDBC.
One seemingly obvious way to avoid having to synch is to create a
dummy node that represents all of the db data. However, the resulting
URLs would not be resource-oriented at all since you need to pass the
resource identifier as a request parameter.
The full monty and best solution for making your db URLs RESTful is to
create a Sling ResourceProvider. This would be an OSGi bundle that
claims a part of the URL space in Sling and maps the URLs to resources
of whatever kind. In the Sling samples there is an example
implementation for file systems. In this example a tree of the local
file system is mapped onto the URL space and all files are given Sling
resource types. As such, the normal mechanisms for rendering requests
are used. The same can be achieved with db rows, of course.
It should be noted that there is a generic problem when the relational
data needs to be mapped onto the hierarchical URL space. You could go
the brute force way of using /content/tablename/id. However, if your
data is somehow categorized using many-to-one relationships consider
"denormalizing" the data (mentally - you do not need to actually
change the tables). This would yield nicer URLs like /content/
category1/category2/data (e.g. like /content/wagons/mercedes/e-class).
18 years
JNDI implementation
by Randall Hauch
There was a question in the #jbossdna IRC about a JNDI
implementation. I knew JBoss had an implementation (at least one that
works within a VM) that could be used by DNA, but I wasn't sure where
it was. There's a "Naming" project in the main image on http://www.jboss.org/projects/
, but it's grayed out.
Found the JBoss Naming Service (JNS) project under the "jbossas/
projects/naming" folder in SVN. It doesn't appear to have top-level
project status like the microcontainer (which is also located in the
same "jbossas/projects" folder), but rather it's considered a "module"
of AS (along with JBoss JTA, JBoss CMP, etc.; see http://wiki.jboss.org/wiki
for a list of the modules, quite a few of which we'd want to use).
There's also a wiki page (http://wiki.jboss.org/wiki/JBossNS), but
that doesn't really explain how to set it up with the Microcontainer.
We'll have to investigate that.
Anyway, using the Microcontainer and setting it up with some of the
"standard" Java services (like Naming, JTS, etc.) is definitely the
way to go, and while it's new territory for us, it isn't for others at
JBoss. We'll just have to talk to the right people when the time comes.
BR,
Randall
18 years, 1 month
Adding umlgraph to our javadoc
by Stefano Maestri
I tried to add UmlGraph generated images to dna project javadocs.
The result is nice: http://www.javalinuxlabs.org/apidocs/index.html
I attached here the only modification needed to pom.xml to get this result.
UmlGraph can also model composition relation with custom javadocs tags,
but, IMHO the totally automatic results is fine and easy for all.
Also public method can be added to the model, but I think it's better to
have easy to read structural model and leave to javadoc deeper
descriptions of class components and methods.
The only problem with UmlGraph is that it depends on GraphViz, and this
dependencies can't be administered by maven, since graphvz isn't a java
package. UmlGraph just expect GraphViz instaed on building host and
fails if it isn't. I didn't find any elegant and brief way to solve the
problem: any suggestion?
BTW have Hudson's host GraphViz installed? Is this strong unmanaged
dependency acceptable for javadoc target?
IMHO enriched javadocs is nice and could help a lot community to
understand our sw architecture/class hierarchy. At least they helped me :)
best regards
S.
18 years, 1 month
Vacation
by Serge Emmanuel Pagop
I am now in vacation and I come back at 23.07.2008.
Best regards,
Serge
-------
|||| Serge Pagop
|||| Senior Consultant
||||
|||| JBUG Munich Founder
||||
|||| innoQ Deutschland GmbH, Halskestr. 17, D-40880 Ratingen, Germany
|||| Phone: +49 2102 77162-100, Mobile: +49 178 4049592, Fax: +49 2102
77160-1
|||| Mail: serge.pagop(a)innoq.com, Web: http://www.innoq.com,
|||| Weblog: http://www.innoq.com/blog/sp, JBug-munich: http://www.jbug-munich.org
18 years, 1 month
Holiday weekend
by Randall Hauch
This is a reminder that July 4 is a holiday in the US. Also, I'm
taking a few extra days vacation (through July 8) where I will not
have Internet access, so I'll be completely unavailable. (It is a
vacation, after all. :-) However, I'll be back and fully recharged on
Wednesday July 9.
Have a great weekend, everyone!
Best regards,
Randall
18 years, 1 month
Re: dna-dev Digest, Vol 4, Issue 1
by Serge Emmanuel Pagop
Hi Randall,
this compilation error is because of the missing of the commons.lang
artifact, that I used in the java sequencer. I already have configured
in the POM of the java sequencer:
<dependency>
<groupId>commons-lang</groupId>
<artifactId>commons-lang</artifactId>
<version>2.4</version>
</dependency>
Best regards,
Serge.
On Jul 2, 2008, at 6:00 PM, dna-dev-request(a)lists.jboss.org wrote:
> Send dna-dev mailing list submissions to
> dna-dev(a)lists.jboss.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://lists.jboss.org/mailman/listinfo/dna-dev
> or, via email, send a message with subject or body 'help' to
> dna-dev-request(a)lists.jboss.org
>
> You can reach the person managing the list at
> dna-dev-owner(a)lists.jboss.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of dna-dev digest..."
>
>
> Today's Topics:
>
> 1. Build failed in Hudson: DNA continuous on JDK1.5 ? JBoss DNA
> Java Sequencer #140 (jboss-qa-internal(a)redhat.com)
> 2. Hudson build is back to normal: DNA continuous on JDK1.5 ?
> JBoss DNA Java Sequencer #141 (jboss-qa-internal(a)redhat.com)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Tue, 1 Jul 2008 21:09:54 -0400 (EDT)
> From: jboss-qa-internal(a)redhat.com
> Subject: [dna-dev] Build failed in Hudson: DNA continuous on JDK1.5 ?
> JBoss DNA Java Sequencer #140
> To: dna-dev(a)lists.jboss.org
> Message-ID:
> <1191399406.13221214960994259.JavaMail.hudson(a)dev17.qa.atl2.redhat.com
> >
>
> Content-Type: text/plain; charset=us-ascii
>
> See http://hudson.qa.jboss.com/hudson/job/DNA%20continuous%20on%20JDK1.5/org....
>
> ------------------------------------------
> [INFO]
> ------------------------------------------------------------------------
> [INFO] Building JBoss DNA Java Sequencer
> [INFO] task-segment: [clean, package]
> [INFO]
> ------------------------------------------------------------------------
> [INFO] [clean:clean]
> [INFO] [resources:resources]
> [INFO] Using default encoding to copy filtered resources.
> [INFO] [compiler:compile]
> [INFO] Compiling 20 source files to http://hudson.qa.jboss.com/hudson/job/DNA%20continuous%20on%20JDK1.5/org....
> [HUDSON] Archiving http://hudson.qa.jboss.com/hudson/job/DNA%20continuous%20on%20JDK1.5/org....
> [INFO]
> ------------------------------------------------------------------------
> [ERROR] BUILD FAILURE
> [INFO]
> ------------------------------------------------------------------------
> [INFO] Compilation failure
>
> http://hudson.qa.jboss.com/hudson/job/DNA%20continuous%20on%20JDK1.5/org....
> :[27,31] package org.apache.commons.lang does not exist
>
> http://hudson.qa.jboss.com/hudson/job/DNA%20continuous%20on%20JDK1.5/org....
> :[119,20] cannot find symbol
> symbol : variable StringUtils
> location: class org.jboss.dna.sequencer.java.JavaMetadataSequencer
>
>
> [INFO]
> ------------------------------------------------------------------------
> [INFO] For more information, run Maven with the -e switch
> [INFO]
> ------------------------------------------------------------------------
> [INFO] Total time: 6 minutes 13 seconds
> [INFO] Finished at: Tue Jul 01 21:09:51 EDT 2008
> [INFO] Final Memory: 32M/212M
> [INFO]
> ------------------------------------------------------------------------
>
>
>
> ------------------------------
>
> Message: 2
> Date: Tue, 1 Jul 2008 21:26:02 -0400 (EDT)
> From: jboss-qa-internal(a)redhat.com
> Subject: [dna-dev] Hudson build is back to normal: DNA continuous on
> JDK1.5 ? JBoss DNA Java Sequencer #141
> To: dna-dev(a)lists.jboss.org
> Message-ID:
>
> <446363710.13231214961962934.JavaMail.hudson(a)dev17.qa.atl2.redhat.com>
> Content-Type: text/plain; charset=us-ascii
>
> See http://hudson.qa.jboss.com/hudson/job/DNA%20continuous%20on%20JDK1.5/org....
>
>
>
>
> ------------------------------
>
> _______________________________________________
> dna-dev mailing list
> dna-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/dna-dev
>
>
> End of dna-dev Digest, Vol 4, Issue 1
> *************************************
>
-------
|||| Serge Pagop
|||| Senior Consultant
||||
|||| JBUG Munich Founder
||||
|||| innoQ Deutschland GmbH, Halskestr. 17, D-40880 Ratingen, Germany
|||| Phone: +49 2102 77162-100, Mobile: +49 178 4049592, Fax: +49 2102
77160-1
|||| Mail: serge.pagop(a)innoq.com, Web: http://www.innoq.com,
|||| Weblog: http://www.innoq.com/blog/sp, JBug-munich: http://www.jbug-munich.org
18 years, 1 month
