[jira] Commented: (JCR-569) WorkspaceImporter Refactoring

2006-09-13 Thread Stefan Guggisberg (JIRA)
[ 
http://issues.apache.org/jira/browse/JCR-569?page=comments#action_12434386 ] 

Stefan Guggisberg commented on JCR-569:
---

 Overall I feel this class  is circumvoluted and really hard to understand. 
 For instance, the current code contains at most 5 imbricated if and uses a 
 lot of different ways to pass information (stacks, objects set on null).
 

sorry, i can't follow you here. what does 'circumvoluted' mean? what does 
'imbricated' mean? 
please note that if something is 'hard to understand' does not necessarily mean 
that it 
is too complex.

 I tried to refactor my SysViewImporter and the WorkspaceImporter but it 
 implies a new code for the WorkspaceImporter and the SysViewImporter. Here is 
 its skeleton! I first wanted to gather the community feedback before stepping 
 in. I tried moving all work code away from the startNode method and 
 reorganise it for readilibility.

what's the use of the private 'isAddabble'(?),  checkNode etc methods? why are 
they private?



 WorkspaceImporter Refactoring
 -

 Key: JCR-569
 URL: http://issues.apache.org/jira/browse/JCR-569
 Project: Jackrabbit
  Issue Type: Improvement
Reporter: Nicolas Toper
 Attachments: SysViewImporter.patch


 Hi,
 As you know, I have run into an issue with the backup tool using the 
 WorkspaceImporter. I ended up copy/pasting large body of code since the 
 current WorkspaceImporter was not flexible enough for my use (in my class 
 called SysViewImporter). This solution was perfectly valid for Google SoC (a 
 lot of time constraints) but unacceptable in the long run for any project (we 
 hate large body of duplicate code :p).
 Also, some issues have been raised with this class (i.e. jcr:root 
 importation, allowsSameNameSiblings issue). 
 Overall I feel this class  is circumvoluted and really hard to understand. 
 For instance, the current code contains at most 5 imbricated if and uses a 
 lot of different ways to pass information (stacks, objects set on null). 
 I tried to refactor my SysViewImporter and the WorkspaceImporter but it 
 implies a new code for the WorkspaceImporter and the SysViewImporter. Here is 
 its skeleton! I first wanted to gather the community feedback before stepping 
 in. I tried moving all work code away from the startNode method and 
 reorganise it for readilibility.
 Please give me your feedback.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira




bug in SQL Query

2006-09-13 Thread Paco Avila
I make this query:

SELECT * FROM okm:document WHERE jcr:path LIKE '/okm:root/%' OR
jcr:path='/okm:root'

and this exception is thrown:

Invalid combination of jcr:path clauses

But the specification says in 8.5.2.2 that this is a valid query (page
289).



Re: Nuclear Fission, Splitting the core: The SPI Effect [was: Improving the accessibility of the Jackrabbit core]

2006-09-13 Thread David Nuescheler

Hi,


However, I'm a bit concerned about the revolutionary approach of the
SPI effort. Rather than refactoring the Jackrabbit core to better
separate the session-local parts, the SPI comes up with a brand new
interface contract. This is probably the best thing to do given the
SPI goals, but it does leave the big question of how and when are we
going to integrate it with Jackrabbit core unanswered.


I think you are right. Just to be clear, I do not look at the
architecture suggested or hinted by the SPI to be implemented
in a the very near future in a clean way.

My original intention of this thread really was to stimulate some
discussions around a possible Jackrabbit 2.x architecture.


As of now the easiest way I see to integrate the SPI effort with the
Jackrabbit core is through a generic spi2jcr adapter, but that doesn't
really affect the core design or increase code re-use.


I agree.

As a side note: I even see value for an spi2jcr adapter
beyond the mid-term goal of a better remoting for the current
Jackrabbit core. I think that a spi2jcr adaptor (in conjunction with the
jcr2spi-client and the protocol bindings of the SPI) could serve as a
general purpose remoting layer for any JCR compliant repository.

Generally, I think we could also look at a phased approach, that
allows us to test, evolve and mature the components individually.

I think we could also do something like:
(Step1) Isolate the session-local parts into a standalone client (JCR2SPI)
(Step2) Build the SPI2JCR layer that exposes the current Jackrabbit
impl to the SPI
(Step3) Refactor the Jackrabbit core to natively implement the SPI

Thoughts?



What would a
more deeply integrated spi2jackrabbit component look like, and how
would we implement it in the core?

I am not sure how that would look like and I guess that this would be
subject to some investigations. It may well be that some portions
would benefit from being refactored to work efficiently.


And on the other hand, how can the SPI effort better reuse the
experience built into the session-local parts of Jackrabbit core?
For example looking at the SessionImpl implementations from both jcr2spi
and the core, I see quite a lot of duplicate functionality. How does
the SPI make sure that the lessons learned developing the core are
included in the new codebase?

I agree. I think the lessons learned should be transported through the
Jackrabbit Community and its experience with JCR and Jackrabbit
over the past years. Of course I would also prefer to re-use as much
existing and well tested code as possible. But personally I think
we should not make architectural sacrifices at this point.

I believe that the overlap and the redundance of the code between the
session-local parts and the core are rooted on the original compact
and intertwined design.

Do you think we would see the same overlap if we would basically
have a straight-up SPI implementation (on the server-side) more or
less from scratch and strictly separate the session-local parts?

regards,
david


[jira] Created: (JCR-570) Fix pom.xml in jackrabbit core (small fix, big return)

2006-09-13 Thread Darren Hartford (JIRA)
Fix pom.xml in jackrabbit core (small fix, big return)
--

 Key: JCR-570
 URL: http://issues.apache.org/jira/browse/JCR-570
 Project: Jackrabbit
  Issue Type: Bug
Affects Versions: 1.1
 Environment: Maven2
Reporter: Darren Hartford
Priority: Critical


Change the following dependency in pom.xml to match what is really available at 
the maven repos:
FROM:
dependency
  groupIdjsr170/groupId
  artifactIdjcr/artifactId
  version1.0/version
/dependency


TO:
dependency
  groupIdjavax.jcr/groupId
  artifactIdjcr/artifactId
  version1.0/version
/dependency


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] Updated: (JCR-570) Fix pom.xml in jackrabbit core (small fix, big return)

2006-09-13 Thread Jukka Zitting (JIRA)
 [ http://issues.apache.org/jira/browse/JCR-570?page=all ]

Jukka Zitting updated JCR-570:
--

  Component/s: maven
Affects Version/s: (was: 1.1)
 Assignee: Jukka Zitting

Oh,  the JCR jars were uploaded in the Maven repository at ibiblio. Cool!

 Fix pom.xml in jackrabbit core (small fix, big return)
 --

 Key: JCR-570
 URL: http://issues.apache.org/jira/browse/JCR-570
 Project: Jackrabbit
  Issue Type: Bug
  Components: maven
 Environment: Maven2
Reporter: Darren Hartford
 Assigned To: Jukka Zitting
Priority: Critical

 Change the following dependency in pom.xml to match what is really available 
 at the maven repos:
 FROM:
 dependency
   groupIdjsr170/groupId
   artifactIdjcr/artifactId
   version1.0/version
 /dependency
 TO:
 dependency
   groupIdjavax.jcr/groupId
   artifactIdjcr/artifactId
   version1.0/version
 /dependency

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] Commented: (JCR-544) JCR-Server: Workspace.restore not mapped correctly

2006-09-13 Thread angela (JIRA)
[ 
http://issues.apache.org/jira/browse/JCR-544?page=comments#action_12434477 ] 

angela commented on JCR-544:


additional thoughts: what is actually missing in the jcr-server is a distint 
resource representing the 'workspace'. currently the root node
also acts somehow as workspace.

i will take a closer look at this point, which may provide also a smarter 
solution for this bug.

 JCR-Server: Workspace.restore not mapped correctly
 --

 Key: JCR-544
 URL: http://issues.apache.org/jira/browse/JCR-544
 Project: Jackrabbit
  Issue Type: Bug
Reporter: angela
 Assigned To: angela

 (issue reported by David Kennedy)
 Workspace.restore(Version[], boolean) won't work, since versions are not 
 retrieved correctly. The version history that can be access from the request  
 resource, cannot be used to retrieve the versions needed for a 
 workspace.restore call.
 possible short term fix:
 From the version-hrefs present in the request body of the UPDATE request, 
 version resources must be built and
 the corresponding version item retrieved.
 alternative:
 find a proper mapping for Workspace.restore(Version[], boolean). having 
 UPDATE on a resource representing a javax.jcr.Node being mapped to a 
 workspace.restore is odd.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] Created: (JCR-571) jackrabbit JCA pom.xml

2006-09-13 Thread Darren Hartford (JIRA)
jackrabbit JCA pom.xml
--

 Key: JCR-571
 URL: http://issues.apache.org/jira/browse/JCR-571
 Project: Jackrabbit
  Issue Type: Improvement
Affects Versions: 1.1
 Environment: maven 2
Reporter: Darren Hartford


do not see a way to add attachments, so here it is below inline.
Note, need to move the src/rar/META-INF/ra.xml to src/main/rar/META-INF/ra.xml 
(which is the default location with maven rar packager).
==
?xml version=1.0 encoding=UTF-8?

!--
   Licensed to the Apache Software Foundation (ASF) under one or more
   contributor license agreements.  See the NOTICE file distributed with
   this work for additional information regarding copyright ownership.
   The ASF licenses this file to You under the Apache License, Version 2.0
   (the License); you may not use this file except in compliance with
   the License.  You may obtain a copy of the License at

   http://www.apache.org/licenses/LICENSE-2.0

   Unless required by applicable law or agreed to in writing, software
   distributed under the License is distributed on an AS IS BASIS,
   WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
   See the License for the specific language governing permissions and
   limitations under the License.
  --

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

!-- == --
!-- P R O J E C T  D E S C R I P T I O N   --
!-- == --
  groupIdorg.apache.jackrabbit/groupId
  artifactIdjackrabbit-jca/artifactId
  packagingrar/packaging
  nameJackrabbit JCA/name
  version1.1-SNAPSHOT/version
  !--
Keep the description on a single line. Otherwise Maven might generate
a corrupted MANIFEST.MF (see http://jira.codehaus.org/browse/MJAR-4)
   --
  description
A resource adapter for Jackrabbit as specified by JCA 1.0.
/description
  urlhttp://jackrabbit.apache.org//url
  prerequisites
maven2.0/maven
  /prerequisites
  issueManagement
systemJira/system
urlhttp://issues.apache.org/jira/browse/JCR/url
  /issueManagement
  inceptionYear2005/inceptionYear




!-- == --
!-- M A I L I N G   L I S T S  --
!-- == --
  mailingLists
mailingList
  nameJackrabbit Announce List/name
  subscribe[EMAIL PROTECTED]/subscribe
  unsubscribe[EMAIL PROTECTED]/unsubscribe
  
archivehttp://mail-archives.apache.org/mod_mbox/jackrabbit-announce//archive
/mailingList
mailingList
  nameJackrabbit Users List/name
  subscribe[EMAIL PROTECTED]/subscribe
  unsubscribe[EMAIL PROTECTED]/unsubscribe
  postusers at jackrabbit.apache.org/post
  
archivehttp://mail-archives.apache.org/mod_mbox/jackrabbit-users//archive
  otherArchives
otherArchive
  http://dir.gmane.org/gmane.comp.apache.jackrabbit.user
/otherArchive
otherArchive
  http://www.mail-archive.com/users@jackrabbit.apache.org/
/otherArchive
  /otherArchives
/mailingList
mailingList
  nameJackrabbit Development List/name
  subscribe[EMAIL PROTECTED]/subscribe
  unsubscribe[EMAIL PROTECTED]/unsubscribe
  postdev at jackrabbit.apache.org/post
  
archivehttp://mail-archives.apache.org/mod_mbox/jackrabbit-dev//archive
  otherArchives
otherArchive
  http://dir.gmane.org/gmane.comp.apache.jackrabbit.devel
/otherArchive
otherArchive
  http://www.mail-archive.com/dev@jackrabbit.apache.org/
/otherArchive
otherArchive
  http://www.mail-archive.com/jackrabbit-dev@incubator.apache.org/
/otherArchive
  /otherArchives
/mailingList
mailingList
  nameJackrabbit Source Control List/name
  subscribe[EMAIL PROTECTED]/subscribe
  unsubscribe[EMAIL PROTECTED]/unsubscribe
  
archivehttp://mail-archives.apache.org/mod_mbox/jackrabbit-commits//archive
/mailingList
  /mailingLists


  licenses
license
  nameThe Apache Software License, Version 2.0/name
  urlhttp://www.apache.org/licenses/LICENSE-2.0/url
  distributionrepo/distribution
/license
  /licenses
  scm

connectionscm:svn:http://svn.apache.org/repos/asf/jackrabbit/trunk/jca/connection

developerConnectionscm:svn:https://svn.apache.org/repos/asf/jackrabbit/trunk/jca/developerConnection
urlhttp://svn.apache.org/viewvc/jackrabbit/trunk/jca/url
  /scm
  organization

[jira] Updated: (JCR-571) jackrabbit JCA pom.xml

2006-09-13 Thread Darren Hartford (JIRA)
 [ http://issues.apache.org/jira/browse/JCR-571?page=all ]

Darren Hartford updated JCR-571:


Attachment: pom.xml

ahh...attach file on sidebar. Here is the JCA pom.xml

 jackrabbit JCA pom.xml
 --

 Key: JCR-571
 URL: http://issues.apache.org/jira/browse/JCR-571
 Project: Jackrabbit
  Issue Type: Improvement
Affects Versions: 1.1
 Environment: maven 2
Reporter: Darren Hartford
 Attachments: pom.xml


 do not see a way to add attachments, so here it is below inline.
 Note, need to move the src/rar/META-INF/ra.xml to 
 src/main/rar/META-INF/ra.xml (which is the default location with maven rar 
 packager).
 ==
 ?xml version=1.0 encoding=UTF-8?
 !--
Licensed to the Apache Software Foundation (ASF) under one or more
contributor license agreements.  See the NOTICE file distributed with
this work for additional information regarding copyright ownership.
The ASF licenses this file to You under the Apache License, Version 2.0
(the License); you may not use this file except in compliance with
the License.  You may obtain a copy of the License at
http://www.apache.org/licenses/LICENSE-2.0
Unless required by applicable law or agreed to in writing, software
distributed under the License is distributed on an AS IS BASIS,
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
See the License for the specific language governing permissions and
limitations under the License.
   --
 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
 !-- == 
 --
 !-- P R O J E C T  D E S C R I P T I O N   
 --
 !-- == 
 --
   groupIdorg.apache.jackrabbit/groupId
   artifactIdjackrabbit-jca/artifactId
   packagingrar/packaging
   nameJackrabbit JCA/name
   version1.1-SNAPSHOT/version
   !--
 Keep the description on a single line. Otherwise Maven might generate
 a corrupted MANIFEST.MF (see http://jira.codehaus.org/browse/MJAR-4)
--
   description
 A resource adapter for Jackrabbit as specified by JCA 1.0.
 /description
   urlhttp://jackrabbit.apache.org//url
   prerequisites
 maven2.0/maven
   /prerequisites
   issueManagement
 systemJira/system
 urlhttp://issues.apache.org/jira/browse/JCR/url
   /issueManagement
   inceptionYear2005/inceptionYear
 !-- == 
 --
 !-- M A I L I N G   L I S T S  
 --
 !-- == 
 --
   mailingLists
 mailingList
   nameJackrabbit Announce List/name
   subscribe[EMAIL PROTECTED]/subscribe
   unsubscribe[EMAIL PROTECTED]/unsubscribe
   
 archivehttp://mail-archives.apache.org/mod_mbox/jackrabbit-announce//archive
 /mailingList
 mailingList
   nameJackrabbit Users List/name
   subscribe[EMAIL PROTECTED]/subscribe
   unsubscribe[EMAIL PROTECTED]/unsubscribe
   postusers at jackrabbit.apache.org/post
   
 archivehttp://mail-archives.apache.org/mod_mbox/jackrabbit-users//archive
   otherArchives
 otherArchive
   http://dir.gmane.org/gmane.comp.apache.jackrabbit.user
 /otherArchive
 otherArchive
   http://www.mail-archive.com/users@jackrabbit.apache.org/
 /otherArchive
   /otherArchives
 /mailingList
 mailingList
   nameJackrabbit Development List/name
   subscribe[EMAIL PROTECTED]/subscribe
   unsubscribe[EMAIL PROTECTED]/unsubscribe
   postdev at jackrabbit.apache.org/post
   
 archivehttp://mail-archives.apache.org/mod_mbox/jackrabbit-dev//archive
   otherArchives
 otherArchive
   http://dir.gmane.org/gmane.comp.apache.jackrabbit.devel
 /otherArchive
 otherArchive
   http://www.mail-archive.com/dev@jackrabbit.apache.org/
 /otherArchive
 otherArchive
   http://www.mail-archive.com/jackrabbit-dev@incubator.apache.org/
 /otherArchive
   /otherArchives
 /mailingList
 mailingList
   nameJackrabbit Source Control List/name
   subscribe[EMAIL PROTECTED]/subscribe
   unsubscribe[EMAIL PROTECTED]/unsubscribe
   
 archivehttp://mail-archives.apache.org/mod_mbox/jackrabbit-commits//archive
 /mailingList
   /mailingLists
   licenses
 license
   nameThe Apache Software License, Version 2.0/name
   

[jira] Commented: (JCR-569) WorkspaceImporter Refactoring

2006-09-13 Thread Nicolas Toper (JIRA)
[ 
http://issues.apache.org/jira/browse/JCR-569?page=comments#action_12434496 ] 

Nicolas Toper commented on JCR-569:
---

Sure. Here it is:

Introduction
The current o.a.j.core.xml.WorspaceImporter class has one main responsability: 
to import data provided by a ContentHandler to the repository. It needs to 
check imported data to maintain consistancy and coherence of the repository and 
in some cases rejects them.

The calling stack is:
- WorkspaceImporter implements Importer
- SysViewImportHandler
- SaxParser (and various classes associated)
- Other classes

The Importer interface is composed of 4 methods: start, end, startNode, 
endNode. The current WorkspaceImporter contains only two protected classe

Currently the code is complex to grasp and have some issues I would like to 
solve with this iteration of the backup tool (I am using this class heavily).

Issues I am trying to solve:
- Methods are too long: there are 7 methods in this class for 619 lines. In 
average one method per 88 lines. This goes with the 4 levels of if/else. This 
code is hard to debug.

- Complexity: there is no clear separation of concerns between methods. This is 
partly due to the Importer interface quite close to the XML. For instance, 
startNode() checks the validity of the import ad endNode do. We need to create 
more methods giving a role to each one.

- Factorizing/Code duplicate: Right now we check several times the same thing 
and sometimes not at all. For instance we check the sanity of the workspace at 
the end of each node and at the end of the import. We also check several times 
if a node can be added without disrupting the consistancy of the repository. We 
should have a private dedicated method for that.

- Bugs: jcr:root is not handled correctly and other bugs have been detected. 
Since the code is hardly readable,

-  Lack of flexibility: I will give just an example. Because of this monolothic 
design (only 7 methods), the checks are embedded in each method (cf. upper). I 
had to subclass the 4 methods of the Importer interface. Also the 
WorkspaceImporter initiates versioning if needed and remap some UUID all the 
time.

Solution
My proposal is in four parts:

- Add some private methods to abstract some of the complex issue this class is 
managing

- Add more control in the constructor (for instance for our backup tool): add a 
constructor with the BatchedItemOperation so we can choose if needed the needed 
ItemStateManager. (For instance to restore the version history).

- Add a raw flag in the constructor to import the content as it is without 
initializing versioning and escaping some checks. This is a use case already 
encountered

- With this new design, solve remaining bugs and handle the jcr:root issue.

This new class will be subclassed by WorkspaceImporter to handle the workspace 
(I am not using it for now) and for the sanityCheck(): therefore it will be 
only a few lines and we will have good SoC.

Please have a look as the patch proposed earlier to have a look at the design 
and the new code (it is far from over and a lot of methods are incomplete).

BR
Nicolas

 WorkspaceImporter Refactoring
 -

 Key: JCR-569
 URL: http://issues.apache.org/jira/browse/JCR-569
 Project: Jackrabbit
  Issue Type: Improvement
Reporter: Nicolas Toper
 Attachments: SysViewImporter.patch


 Hi,
 As you know, I have run into an issue with the backup tool using the 
 WorkspaceImporter. I ended up copy/pasting large body of code since the 
 current WorkspaceImporter was not flexible enough for my use (in my class 
 called SysViewImporter). This solution was perfectly valid for Google SoC (a 
 lot of time constraints) but unacceptable in the long run for any project (we 
 hate large body of duplicate code :p).
 Also, some issues have been raised with this class (i.e. jcr:root 
 importation, allowsSameNameSiblings issue). 
 Overall I feel this class  is circumvoluted and really hard to understand. 
 For instance, the current code contains at most 5 imbricated if and uses a 
 lot of different ways to pass information (stacks, objects set on null). 
 I tried to refactor my SysViewImporter and the WorkspaceImporter but it 
 implies a new code for the WorkspaceImporter and the SysViewImporter. Here is 
 its skeleton! I first wanted to gather the community feedback before stepping 
 in. I tried moving all work code away from the startNode method and 
 reorganise it for readilibility.
 Please give me your feedback.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] Commented: (JCR-569) WorkspaceImporter Refactoring

2006-09-13 Thread Nicolas Toper (JIRA)
[ 
http://issues.apache.org/jira/browse/JCR-569?page=comments#action_12434497 ] 

Nicolas Toper commented on JCR-569:
---

Hi Stefan,

About your first point, you are right: this is why I sent yesterday a more in 
depth analysis. This JIRA issue will be used as Jukka suggested it, for 
refactoring issue of this class only.

I would like to create two classes: one generic Importer (name to be defined) 
and one dedicated to import a workspace. I would use the generic Importer for 
the backup and others could use it when they need to batch load some data (of 
course, it is more complex to use and set up). The WorkspaceImporter would be 
used for the same use case as now. The WorkspaceImporter constructor would stay 
the same to avoid backward compatibility issue.

Here is a quick descriptive of each methods of the generic Importer. They are 
private since no other class need them (this class is used with the 
ContentHandler).

 private boolean checkNode(NodeInfo nodeInfo)
Check if the node can be imported to the repository. For instance, it can try 
to delete a protected node, the same node might already exist (it can depend on 
the ImportUUIDBehavior used) or the node can be incorrect according to the node 
type in the repository.

Some checks are escaped if raw mode is chosen.

If the node is not correct, it puts the skip mode on true to exclude this 
subtree. When the subtree is over, the skip mode is put to off. If the error is 
serious (constraint issue for instance), an exception will be thrown.


 private NodeState createNode(NodeState parent, NodeInfo nodeInfo)
Create the NodeState depending according to ImportUUIDBehavior flag

 private void createProperties(NodeState myNode, List propInfos)
Create the properties depending according to ImportUUIDBehavior flag

 private boolean isSkipped(NodeInfo nodeInfo)
if we are in skip mode return true; else false.


private void postProcess(NodeState node)
Initialize if raw == false,  this method is not called. It will be empty for 
the generic Importer (we don't need to initialize any thing) but 
WorkspaceImporter will overload it.

protected NodeState resolveUUIDConflict
Resolve UUID conflict :p

 private boolean isAddabble(NodeState parent, NodeInfo nodeInfo) throws 
ConstraintViolationException, AccessDeniedException, VersionException, 
LockException, ItemNotFoundException, ItemExistsException, RepositoryException
This method is not needed.

 private boolean isCorrect(NodeState parent, NodeInfo nodeInfo, List propInfos)
Not needed.

If you are OK with this approach, I will work on this and propose you soon a 
patch implementing this refactoring.

BR,
Nico
my blog! http://www.deviant-abstraction.net !!

 WorkspaceImporter Refactoring
 -

 Key: JCR-569
 URL: http://issues.apache.org/jira/browse/JCR-569
 Project: Jackrabbit
  Issue Type: Improvement
Reporter: Nicolas Toper
 Attachments: SysViewImporter.patch


 Hi,
 As you know, I have run into an issue with the backup tool using the 
 WorkspaceImporter. I ended up copy/pasting large body of code since the 
 current WorkspaceImporter was not flexible enough for my use (in my class 
 called SysViewImporter). This solution was perfectly valid for Google SoC (a 
 lot of time constraints) but unacceptable in the long run for any project (we 
 hate large body of duplicate code :p).
 Also, some issues have been raised with this class (i.e. jcr:root 
 importation, allowsSameNameSiblings issue). 
 Overall I feel this class  is circumvoluted and really hard to understand. 
 For instance, the current code contains at most 5 imbricated if and uses a 
 lot of different ways to pass information (stacks, objects set on null). 
 I tried to refactor my SysViewImporter and the WorkspaceImporter but it 
 implies a new code for the WorkspaceImporter and the SysViewImporter. Here is 
 its skeleton! I first wanted to gather the community feedback before stepping 
 in. I tried moving all work code away from the startNode method and 
 reorganise it for readilibility.
 Please give me your feedback.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] Commented: (JCR-569) WorkspaceImporter Refactoring

2006-09-13 Thread Jukka Zitting (JIRA)
[ 
http://issues.apache.org/jira/browse/JCR-569?page=comments#action_12434503 ] 

Jukka Zitting commented on JCR-569:
---

Nicolas:
 I would like to create two classes: one generic Importer (name to be defined) 
 and one dedicated to import a workspace.

This would still be a part of the flexibility goal (E in my message to the 
mailing list). To keep things simple I'd suggest that you limit this issue to a 
patch that refactors the methods within WorkspaceImporter without introducing 
another class.

Note also that the responsibility of WorkspaceImporter is not to import a 
workspace but to import content *into* a workspace.

 [The methods of the generic Importer] are private since no other class need 
 them (this class is used with the ContentHandler).

How would a subclass modify the behaviour of the class if those methods are 
private?

 If you are OK with this approach, I will work on this and propose you soon a 
 patch implementing this refactoring. 

It looks OK, but I think the main issue is seeing how the existing code gets 
mapped to the proposed structure. A patch would be the perfect way to show 
this. :-)

 WorkspaceImporter Refactoring
 -

 Key: JCR-569
 URL: http://issues.apache.org/jira/browse/JCR-569
 Project: Jackrabbit
  Issue Type: Improvement
Reporter: Nicolas Toper
 Attachments: SysViewImporter.patch


 Hi,
 As you know, I have run into an issue with the backup tool using the 
 WorkspaceImporter. I ended up copy/pasting large body of code since the 
 current WorkspaceImporter was not flexible enough for my use (in my class 
 called SysViewImporter). This solution was perfectly valid for Google SoC (a 
 lot of time constraints) but unacceptable in the long run for any project (we 
 hate large body of duplicate code :p).
 Also, some issues have been raised with this class (i.e. jcr:root 
 importation, allowsSameNameSiblings issue). 
 Overall I feel this class  is circumvoluted and really hard to understand. 
 For instance, the current code contains at most 5 imbricated if and uses a 
 lot of different ways to pass information (stacks, objects set on null). 
 I tried to refactor my SysViewImporter and the WorkspaceImporter but it 
 implies a new code for the WorkspaceImporter and the SysViewImporter. Here is 
 its skeleton! I first wanted to gather the community feedback before stepping 
 in. I tried moving all work code away from the startNode method and 
 reorganise it for readilibility.
 Please give me your feedback.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] Resolved: (JCR-571) jackrabbit JCA pom.xml

2006-09-13 Thread Edgar Poce (JIRA)
 [ http://issues.apache.org/jira/browse/JCR-571?page=all ]

Edgar Poce resolved JCR-571.


Resolution: Fixed

thanks Darren

 jackrabbit JCA pom.xml
 --

 Key: JCR-571
 URL: http://issues.apache.org/jira/browse/JCR-571
 Project: Jackrabbit
  Issue Type: Improvement
Affects Versions: 1.1
 Environment: maven 2
Reporter: Darren Hartford
 Attachments: pom.xml


 do not see a way to add attachments, so here it is below inline.
 Note, need to move the src/rar/META-INF/ra.xml to 
 src/main/rar/META-INF/ra.xml (which is the default location with maven rar 
 packager).
 ==
 ?xml version=1.0 encoding=UTF-8?
 !--
Licensed to the Apache Software Foundation (ASF) under one or more
contributor license agreements.  See the NOTICE file distributed with
this work for additional information regarding copyright ownership.
The ASF licenses this file to You under the Apache License, Version 2.0
(the License); you may not use this file except in compliance with
the License.  You may obtain a copy of the License at
http://www.apache.org/licenses/LICENSE-2.0
Unless required by applicable law or agreed to in writing, software
distributed under the License is distributed on an AS IS BASIS,
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
See the License for the specific language governing permissions and
limitations under the License.
   --
 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
 !-- == 
 --
 !-- P R O J E C T  D E S C R I P T I O N   
 --
 !-- == 
 --
   groupIdorg.apache.jackrabbit/groupId
   artifactIdjackrabbit-jca/artifactId
   packagingrar/packaging
   nameJackrabbit JCA/name
   version1.1-SNAPSHOT/version
   !--
 Keep the description on a single line. Otherwise Maven might generate
 a corrupted MANIFEST.MF (see http://jira.codehaus.org/browse/MJAR-4)
--
   description
 A resource adapter for Jackrabbit as specified by JCA 1.0.
 /description
   urlhttp://jackrabbit.apache.org//url
   prerequisites
 maven2.0/maven
   /prerequisites
   issueManagement
 systemJira/system
 urlhttp://issues.apache.org/jira/browse/JCR/url
   /issueManagement
   inceptionYear2005/inceptionYear
 !-- == 
 --
 !-- M A I L I N G   L I S T S  
 --
 !-- == 
 --
   mailingLists
 mailingList
   nameJackrabbit Announce List/name
   subscribe[EMAIL PROTECTED]/subscribe
   unsubscribe[EMAIL PROTECTED]/unsubscribe
   
 archivehttp://mail-archives.apache.org/mod_mbox/jackrabbit-announce//archive
 /mailingList
 mailingList
   nameJackrabbit Users List/name
   subscribe[EMAIL PROTECTED]/subscribe
   unsubscribe[EMAIL PROTECTED]/unsubscribe
   postusers at jackrabbit.apache.org/post
   
 archivehttp://mail-archives.apache.org/mod_mbox/jackrabbit-users//archive
   otherArchives
 otherArchive
   http://dir.gmane.org/gmane.comp.apache.jackrabbit.user
 /otherArchive
 otherArchive
   http://www.mail-archive.com/users@jackrabbit.apache.org/
 /otherArchive
   /otherArchives
 /mailingList
 mailingList
   nameJackrabbit Development List/name
   subscribe[EMAIL PROTECTED]/subscribe
   unsubscribe[EMAIL PROTECTED]/unsubscribe
   postdev at jackrabbit.apache.org/post
   
 archivehttp://mail-archives.apache.org/mod_mbox/jackrabbit-dev//archive
   otherArchives
 otherArchive
   http://dir.gmane.org/gmane.comp.apache.jackrabbit.devel
 /otherArchive
 otherArchive
   http://www.mail-archive.com/dev@jackrabbit.apache.org/
 /otherArchive
 otherArchive
   http://www.mail-archive.com/jackrabbit-dev@incubator.apache.org/
 /otherArchive
   /otherArchives
 /mailingList
 mailingList
   nameJackrabbit Source Control List/name
   subscribe[EMAIL PROTECTED]/subscribe
   unsubscribe[EMAIL PROTECTED]/unsubscribe
   
 archivehttp://mail-archives.apache.org/mod_mbox/jackrabbit-commits//archive
 /mailingList
   /mailingLists
   licenses
 license
   nameThe Apache Software License, Version 2.0/name
   urlhttp://www.apache.org/licenses/LICENSE-2.0/url
   distributionrepo/distribution
 

[jira] Updated: (JCR-571) jackrabbit JCA pom.xml

2006-09-13 Thread Edgar Poce (JIRA)
 [ http://issues.apache.org/jira/browse/JCR-571?page=all ]

Edgar Poce updated JCR-571:
---

Component/s: jca

updating component

 jackrabbit JCA pom.xml
 --

 Key: JCR-571
 URL: http://issues.apache.org/jira/browse/JCR-571
 Project: Jackrabbit
  Issue Type: Improvement
  Components: jca
Affects Versions: 1.1
 Environment: maven 2
Reporter: Darren Hartford
 Attachments: pom.xml


 do not see a way to add attachments, so here it is below inline.
 Note, need to move the src/rar/META-INF/ra.xml to 
 src/main/rar/META-INF/ra.xml (which is the default location with maven rar 
 packager).
 ==
 ?xml version=1.0 encoding=UTF-8?
 !--
Licensed to the Apache Software Foundation (ASF) under one or more
contributor license agreements.  See the NOTICE file distributed with
this work for additional information regarding copyright ownership.
The ASF licenses this file to You under the Apache License, Version 2.0
(the License); you may not use this file except in compliance with
the License.  You may obtain a copy of the License at
http://www.apache.org/licenses/LICENSE-2.0
Unless required by applicable law or agreed to in writing, software
distributed under the License is distributed on an AS IS BASIS,
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
See the License for the specific language governing permissions and
limitations under the License.
   --
 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
 !-- == 
 --
 !-- P R O J E C T  D E S C R I P T I O N   
 --
 !-- == 
 --
   groupIdorg.apache.jackrabbit/groupId
   artifactIdjackrabbit-jca/artifactId
   packagingrar/packaging
   nameJackrabbit JCA/name
   version1.1-SNAPSHOT/version
   !--
 Keep the description on a single line. Otherwise Maven might generate
 a corrupted MANIFEST.MF (see http://jira.codehaus.org/browse/MJAR-4)
--
   description
 A resource adapter for Jackrabbit as specified by JCA 1.0.
 /description
   urlhttp://jackrabbit.apache.org//url
   prerequisites
 maven2.0/maven
   /prerequisites
   issueManagement
 systemJira/system
 urlhttp://issues.apache.org/jira/browse/JCR/url
   /issueManagement
   inceptionYear2005/inceptionYear
 !-- == 
 --
 !-- M A I L I N G   L I S T S  
 --
 !-- == 
 --
   mailingLists
 mailingList
   nameJackrabbit Announce List/name
   subscribe[EMAIL PROTECTED]/subscribe
   unsubscribe[EMAIL PROTECTED]/unsubscribe
   
 archivehttp://mail-archives.apache.org/mod_mbox/jackrabbit-announce//archive
 /mailingList
 mailingList
   nameJackrabbit Users List/name
   subscribe[EMAIL PROTECTED]/subscribe
   unsubscribe[EMAIL PROTECTED]/unsubscribe
   postusers at jackrabbit.apache.org/post
   
 archivehttp://mail-archives.apache.org/mod_mbox/jackrabbit-users//archive
   otherArchives
 otherArchive
   http://dir.gmane.org/gmane.comp.apache.jackrabbit.user
 /otherArchive
 otherArchive
   http://www.mail-archive.com/users@jackrabbit.apache.org/
 /otherArchive
   /otherArchives
 /mailingList
 mailingList
   nameJackrabbit Development List/name
   subscribe[EMAIL PROTECTED]/subscribe
   unsubscribe[EMAIL PROTECTED]/unsubscribe
   postdev at jackrabbit.apache.org/post
   
 archivehttp://mail-archives.apache.org/mod_mbox/jackrabbit-dev//archive
   otherArchives
 otherArchive
   http://dir.gmane.org/gmane.comp.apache.jackrabbit.devel
 /otherArchive
 otherArchive
   http://www.mail-archive.com/dev@jackrabbit.apache.org/
 /otherArchive
 otherArchive
   http://www.mail-archive.com/jackrabbit-dev@incubator.apache.org/
 /otherArchive
   /otherArchives
 /mailingList
 mailingList
   nameJackrabbit Source Control List/name
   subscribe[EMAIL PROTECTED]/subscribe
   unsubscribe[EMAIL PROTECTED]/unsubscribe
   
 archivehttp://mail-archives.apache.org/mod_mbox/jackrabbit-commits//archive
 /mailingList
   /mailingLists
   licenses
 license
   nameThe Apache Software License, Version 2.0/name
   urlhttp://www.apache.org/licenses/LICENSE-2.0/url