You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jackrabbit.apache.org by David Nuescheler <da...@gmail.com> on 2007/07/16 10:06:20 UTC
JSR 283 - Public Review - Content Repository for JavaTM Technology API Version 2.0
Dear Jackrabbit Community,
I am happy to report on behalf of the JSR-283 Expert Group that JCR v2.0
has reached public review status.
During the next 60 days we will collect input from the general public about
the changes that the Expert Group propose to JCR.
I think that members of the Jackrabbit community always had very valuable
comments about JCR.
This would be the ideal time to feed enhancement requests straight into the
standardization process.
Please have a look at the draft that you can download from...
http://jcp.org/en/jsr/detail?id=283
... and send comments to ...
jsr-283-comments@jcp.org
regards,
david
---------- Forwarded message ----------
From: Liz M Kiener <Li...@jcp.org>
Date: Jul 14, 2007 8:56 AM
Subject: JSR 283 - Content Repository for JavaTM Technology API
Version 2.0 - Public Review
To: JCP-INTEREST@java.sun.com
The Public Review Draft Specification for
JSR 283 - Content Repository for JavaTM Technology API Version 2.0
is now available for Public Review from
http://jcp.org/en/jsr/stage?listBy=public
as well as the JSR 283 detail page:
http://jcp.org/en/jsr/detail?id=283
This Public Review closes on 20 September 2007.
===========================================================================
To unsubscribe, send email to listserv@java.sun.com and include in the body
of the message "signoff JCP-INTEREST". For general help, send email to
listserv@java.sun.com and include in the body of the message "help".
Re: JSR 283 - Public Review - Content Repository for JavaTM Technology API Version 2.0
Posted by David Nuescheler <da...@gmail.com>.
Hi Tako,
thanks for your comments.
> > (7) New property types and new Nodetypes to enhance application
> > interoperability
> > around common meta data
> This one interests me, which new types are there? (well I read about the
> WEAKREFERENCE and URI ones, is that what you refer too? If so, the second
> part of your statement "to enhance application interoperability around
> common meta data" confuses me ;-)
I guess the "enhanced application interoperability" was targeted at the "new
nodetypes" only.
When I re-read my sentence now I realized that I probably should more specific
about mentioning the benefits of the new properties individually.
> > (9) Shareable nodes that allow the tree in a content repository workspace
> > to become a more implicit network.
> Could you maybe be a little more specific here, it all sounds very abstract
> when you say it like that :-)
Shareable nodes are nodes that share the same properties and childnodes
and can appear in different locations of a single workspace tree.
I think it can be viewed like a less harmful & less complex re-introduction
of the hard-links that we had in the early days of JSR-170.
A very simple example would be that you can now file a document in various
folders in a (semi-)transparent way for the application and therefore
have an alternative way to model many-to-many relationships.
> PS: Weren't you supposed to be on vacation?
what can i say... bad planning on my behalf ;)
regards,
david
Re: JSR 283 - Public Review - Content Repository for JavaTM Technology API Version 2.0
Posted by Tako Schotanus <qu...@gmail.com>.
On 7/16/07, David Nuescheler <da...@gmail.com> wrote:
>
> Hi Tor,
>
>
>
> (7) New property types and new Nodetypes to enhance application
> interoperability
> around common meta data
This one interests me, which new types are there? (well I read about the
WEAKREFERENCE and URI ones, is that what you refer too? If so, the second
part of your statement "to enhance application interoperability around
common meta data" confuses me ;-)
> (9) Shareable nodes that allow the tree in a content repository workspace
> to become a more implicit network.
Could you maybe be a little more specific here, it all sounds very abstract
when you say it like that :-)
Cheers,
-Tako
PS: Weren't you supposed to be on vacation?
Re: JSR 283 - Public Review - Content Repository for JavaTM Technology API Version 2.0
Posted by Mark Waschkowski <mw...@gmail.com>.
Hi David,
I just glanced through the spec and looks like it has some interesting new
features. One thing I noticed (as pointed out at theserverside.com) is that
sql and xpath is deprecated and replaced with a new AQM. A natural evolution
of xpath support would have, of course, been XQuery since JCR is a
hierarchical storage mechanism, for which xpath and xquery are well suited.
There is no mention of the reasoning behind this, would you provide some
please?
I do, however, like the idea of a Java query object model since doing
criteria queries with sql is a pain (having to append where criteria
together using a string is no fun) so I'm assuming that the JQOM would be
something akin to 'example' queries (create an example object and ask system
to get data that 'looks like' the example object), right?
Best,
Mark
Re: JSR 283 - Public Review - Content Repository for JavaTM Technology API Version 2.0
Posted by Thomas Mueller <th...@gmail.com>.
Hi,
(11) new interface javax.jcr.Binary
> We worked with a fine grained Diff until it became too big.
It would be good to have a higher level Diff (new interfaces, classes,
methods; change behaviour; deprecated methods and interfaces).
Thomas
Re: JSR 283 - Public Review - Content Repository for JavaTM Technology API Version 2.0
Posted by Thomas Mueller <th...@gmail.com>.
Hi,
There is now a changelog in the Jackrabbit wiki:
http://wiki.apache.org/jackrabbit/Proposed_JCR_2%2e0_API_Changes
Thomas
On 7/16/07, Torgeir Veimo <to...@pobox.com> wrote:
>
> On 16 Jul 2007, at 15:43, David Nuescheler wrote:
>
> > (2) Access Control Management to go beyond the introspection that is
> > already specified
> > in JCR v1.0
>
> It seems that access control in JCR 2.0 is limited to declarative
> security?
>
> I think this is a very bad restriction. Declarative security was
> never sufficient enough for EJBs, and is surely not sufficient for
> all types of applications which might be built on top of a JCR
> repository, and is very often much more verbatim than implied or
> programmatic security.
>
> What I'd like to see would be some means of getting access to Nodes
> in a read-only "before" session and an "after" session in a security
> manager. This would allow implementing a wide range of different
> security managers depending on the application at hand.
>
> I guess there are technical challenges with implementing such session
> access, but it could be an optional feature, and the suggested next
> generation persistence architecture would probably easily support it.
>
> --
> Torgeir Veimo
> torgeir@pobox.com
>
>
>
>
Re: JSR 283 - Public Review - Content Repository for JavaTM Technology API Version 2.0
Posted by David Nuescheler <da...@gmail.com>.
Hi Tor,
thanks for your feedback.
Please feel free to also send it to jsr-283-comments@jcp.org to make sure that
it is considered by the expert group.
> > (2) Access Control Management to go beyond the introspection that is
> > already specified
> > in JCR v1.0
> It seems that access control in JCR 2.0 is limited to declarative
> security?
It was not our intention to limit access control models at all.
JCR v2.0 proposes a default declarative access control mechanism
as well as a an abstract policy based one.
Obviously every repository is free to offer other means of access control
beyond that, and in the case of Jackrabbit i think it is safe to say that
access control will always remain "pluggable".
> I think this is a very bad restriction. Declarative security was
> never sufficient enough for EJBs, and is surely not sufficient for
> all types of applications which might be built on top of a JCR
> repository, and is very often much more verbatim than implied or
> programmatic security.
I think it is a very good observation that we probably cannot come up
with an access control model in JCR that fits all needs, that's
why we never wanted to be restrictive or exclude any particular
way of dealing with access control.
I guess we looked at the access control management spec as a default
standard way how access control can be dealt with in a repository
ootb. By no means as the only way to deal with access control.
Regarding the EJB comment:
I would also like to mention that access control management tends
to work much more intuitively in systems that support the concept of
hierarchy (like for example a filesystem or a content repository) than in
systems that don't (like for example rdbms in general).
> What I'd like to see would be some means of getting access to Nodes
> in a read-only "before" session and an "after" session in a security
> manager. This would allow implementing a wide range of different
> security managers depending on the application at hand.
> I guess there are technical challenges with implementing such session
> access, but it could be an optional feature, and the suggested next
> generation persistence architecture would probably easily support it.
I am not sure I understand your suggestion correctly.
Do you think you could explain it a little bit more in detail, maybe with
a specific example?
Generally, I think when it comes to very abstract concepts of
authorization I think JAAS provides you with everything
necessary. It certainly was never our intention to either re-specify JAAS
or exclude JAAS based architectures.
Please let me know if I misinterpreted your comments.
Thanks & regards,
david
Re: JSR 283 - Public Review - Content Repository for JavaTM Technology API Version 2.0
Posted by Torgeir Veimo <to...@pobox.com>.
On 16 Jul 2007, at 15:43, David Nuescheler wrote:
> (2) Access Control Management to go beyond the introspection that is
> already specified
> in JCR v1.0
It seems that access control in JCR 2.0 is limited to declarative
security?
I think this is a very bad restriction. Declarative security was
never sufficient enough for EJBs, and is surely not sufficient for
all types of applications which might be built on top of a JCR
repository, and is very often much more verbatim than implied or
programmatic security.
What I'd like to see would be some means of getting access to Nodes
in a read-only "before" session and an "after" session in a security
manager. This would allow implementing a wide range of different
security managers depending on the application at hand.
I guess there are technical challenges with implementing such session
access, but it could be an optional feature, and the suggested next
generation persistence architecture would probably easily support it.
--
Torgeir Veimo
torgeir@pobox.com
Re: JSR 283 - Public Review - Content Repository for JavaTM Technology API Version 2.0
Posted by David Nuescheler <da...@gmail.com>.
Hi Tor,
Good Point.
We worked with a fine grained Diff until it became too big.
I would probably like to mention the following additions as my top ten list ;)
---
(1) Query extionsions mainly around extended support for SQL specifically JOINs
We also introduced Java Bindings for the Query Object model that allow
for easier
"query wizards" and last but not least "Prepared" queries
(2) Access Control Management to go beyond the introspection that is
already specified
in JCR v1.0
(3) Retention & HoldSupport to enable records management applications
sitting on top of JCR repositories in a standardized fashion
(4) Simple versioning to provide for repositories that only support
linear versioning.
Versioing extensions around "Baselines" and "Activities" to cover the
full configuration
management spectrum
(5) Lifecycle Management to allow to easily hook content into a process engine.
(6) Standardized Nodetype Registration that allow application to
register and manage
their nodetypes with repository.
(7) New property types and new Nodetypes to enhance application interoperability
around common meta data
(8) Workspace Management to allow for creation and deletion of workspaces in
a repository
(9) Shareable nodes that allow the tree in a content repository workspace
to become a more implicit network.
(10) Journalling Observation that allows offline/polling applications
to find out what happend in
a content repository since they last checked.
---
.... is that helpful?
regards,
david
On 7/16/07, Torgeir Veimo <to...@pobox.com> wrote:
> On Mon, 2007-07-16 at 10:06 +0200, David Nuescheler wrote:
> > Dear Jackrabbit Community,
> >
> > I am happy to report on behalf of the JSR-283 Expert Group that JCR v2.0
> > has reached public review status.
> >
> > During the next 60 days we will collect input from the general public about
> > the changes that the Expert Group propose to JCR.
>
> There's no 'what's changed' section? The whole document is 450+ pages
> long so this would be handy.
>
> --
> -Tor
>
>
Re: JSR 283 - Public Review - Content Repository for JavaTM
Technology API Version 2.0
Posted by Torgeir Veimo <to...@pobox.com>.
On Mon, 2007-07-16 at 10:06 +0200, David Nuescheler wrote:
> Dear Jackrabbit Community,
>
> I am happy to report on behalf of the JSR-283 Expert Group that JCR v2.0
> has reached public review status.
>
> During the next 60 days we will collect input from the general public about
> the changes that the Expert Group propose to JCR.
There's no 'what's changed' section? The whole document is 450+ pages
long so this would be handy.
--
-Tor