Re: using jackrabbit to store email with meta-data

[robert burrell donkin]

On 8/9/06, Lars Heuer <[EMAIL PROTECTED]> wrote:

Hi Robert,

[...]
> one of the main reasons why i want to use webDAV is that it's RESTful.
> IMAP and POP3 both suck for the problems i'm interested in because
> they are not.

Yes. But I just want to create a RESTful 'view' at IMAP / POP3.
Nothing to edit / change, only view. :)


reading has some wrinkles that webDAV may have some solutions to.

returning complete mail messages as an xml document is fine when the
whole message wants to be rendered for display. it's common with email
just to want to access some limited headers or properties or that
email. for example, an email client will typically display subject,
date, sender and so on as a summary and then only the whole message
later.

returning the whole message as xml is likely to be a particular issue
when handling MIME emails with large attachments.

so, i'd say it's pretty important that the meta-data is available
without having to download and parse a complete document.


I think that is possible with the 'legacy' protocols. :)


probably so given reasonable wrappers are available for these
protocols (javamail and alternatives).


> IMHO email is basically authoring and so is a good match for webDAV.
> i'd be interested to hear your thoughts on the way you planned to map
> common email operations to RESTful operations.

Well, the RESTful email system is a long term project and I don't have
investigated much time to think about RESTful operations. Maybe Jérôme
(the deveoloper of Restlet) has investigated more thought on it.

The complete RESTful e-mail system is just an idea. I want my RESTful
views first. :)


the great thing about using webDAV is that the writing comes for free :-)


[...]
>> XML For Digital Preservation: XML Implementation Options for E-Mails
>> 

> what are the advantages of using xml?

I think it might be easier to transform XML into another format than
the plain e-mail text.


true

on of the interesting questions is the right level of granuarity...


What do you want to achive with your project?


i don't really have just one project or one goal :-)

i want to be able to add meta-data (tag in web2.0 palence) emails
(better solution to the problem most email clients now solve by
filtering). i'd also like to be able to share these tags over
internet.


Leave IMAP/POP3 completely out?


IMAP is a difficult protocol to work with and build on. it's not
RESTful. POP3 is mostly used as temporary storage. one interest is
more flexible and sophisticated email servers which are not built on
either.

that's not to say that adapter for those protocols wouldn't be useful
just that it's not my itch right now.

- robert

ItemNotFoundException while switching between workspaces

[quipere]

Hi, I am getting a strange exception while I am switching between workspaces.

I am processing a list of xml files and import them in a repository. My
repository is deployed as model3 (server) on tomcat 5.5.x, and I am using
the derbypersistence manager.
When I proces the xmlfiles, I first check whether the file already exists in
the repository, if so I am importing this file in a different workspace.

After the files have been imported I am calling a method which gets all
existing nodes. The problem appears when I have a Arraylist of files which
contains both existing as new files. So when I am saving nodes in two
different workspaces. When I call the method which gets all nodes everything
goes fine (gets it from the cache), only when I restart tomcat (repository
shutdown and startup) and call the get method afterwards I am getting an
ItemNotFoundException. This only happens with the derbypersistencemanager,
when I switch to the Filesystempersistencemanager no errors occur.
It seems like the derbypersistencemanager mixes the references to nodes
between workspaces. The cache stores them in the right way, so I am only
getting the exception after a repository (tomcat) restart.

This is my code:

 public List importBundle(List files) throws PersistencyException { 
Session sessionW1 = null; 
Session sessionW2 = null; 
List lockTokens = new ArrayList(); 
try { 
sessionW1 = getRepositorySession(WORKSPACE_1); 
sessionW2 = getRepositorySession(WORKSPACE_2); 
Iterator it = files.iterator(); 
while (it.hasNext()) { 
ImportFile file = (ImportFile) it.next(); 
importFileAsXMLDocument(file); 
} 
sessionW1.save(); 
sessionW2.save(); 
return lockTokens; 
} catch (Exception e) { 
e.printStackTrace(); 
} finally { 
if (sessionW1 != null) { 
sessionW1.logout(); 
} 
if (sessionW2 != null) { 
sessionW2.logout(); 
} 
} 
} 

public String importFileAsXMLDocument(UPloadFile file, Session
sessionW1, Session sessionW2) throws PersistencyException { 
boolean recordExists = false; 
Lock lock = null; 
String lockToken = null; 
try { 
QueryResult result =
sessionW1.getWorkspace().getQueryManager().createQuery("somequerytofindexistingfile",
Query.XPATH).execute(); 
NodeIterator nodes = result.getNodes(); 
if (nodes.getSize() > 0) { 
recordExists = true; 
Node node = nodes.nextNode(); 
lock = node.lock(true, false); 

} 
if (recordExists) { 
sessionW1.importXML("/",
file.getInputStream(), ImportUUIDBehavior.IMPORT_UUID_CREATE_NEW); 
} else { 
sessionW2.importXML("/",
file.getInputSTream(), ImportUUIDBehavior.IMPORT_UUID_CREATE_NEW); 
} 
if (lock != null) { 
lockToken = lock.getLockToken(); 
} 
return lockToken; 
} catch (Exception e) { 
e.printStackTrace(); 
}   
}

The get method:

public List getRecords() {
List records = new ArrayList();
session = getRepositorySession(WORKSPACE_MAIN); 
String executableQuery = "/*"; 

Query repositoryQuery =
session.getWorkspace().getQueryManager() 
.createQuery(executableQuery,
Query.XPATH); 
QueryResult result = repositoryQuery.execute(); 
NodeIterator it = result.getNodes(); 
while (it.hasNext()) { 
Node node = it.nextNode(); 
records.add(node); 
} 
return records; 
}

The exception is thrown at it.hasnext(). During debugging I see the
nodeiterator contains all nodes I would expect only hasnext throws this
exception:

23.08.2006 17:44:08 *ERROR* DocOrderNodeIteratorImpl: Exception while
sorting nodes in document order: javax.jcr.ItemNotFoundException: failed to
build

Re: GetPropertyNamesTest.testGetPropertyNames

[Julian Reschke]

Marcel Reutegger schrieb:

1) Why nt:base? What if "/" has a type with more properties?


If the element test is absent the type constraint defaults to the one 
that includes all node types: nt:base


OK, makes sense, but maybe this could be clarified somewhere in the spec.

If a query does not explicitly specify properties to select (in SQL this 
would be a 'select *') the properties of the node type specified by the 
type constraint are returned. in case of nt:base those properties are 
jcr:primaryType and jcr:mixinTypes.


Yep.

2) It doesn't seem to me that the query specifies a type constraint, 
so why the check at all?


this is because of the nt:base default described above.


OK.


3) I thought support for jcr:score was optional???


It is kind of optional. If an implementation is not able to provide a 
jcr:score it can always return a dummy value.


The spec says: "As well, a score column will also be included, though it 
is not required that its contents always be meaningful."


OK.

I'll re-read the spec, and if I still think it needs clarification I'll 
open an issue.


Thanks for the explanation.

Best regards, Julian

Re: GetPropertyNamesTest.testGetPropertyNames

[Marcel Reutegger]

Hi Julian,

Julian Reschke wrote:

Hi.

In this case the following query

"/jcr:root"

is executed. The test case checks the column names in the result match 
the declared (single-valued) properties on nt:base, plus jcr:path and 
jcr:score.


Questions:

1) Why nt:base? What if "/" has a type with more properties?


If the element test is absent the type constraint defaults to the one 
that includes all node types: nt:base


If a query does not explicitly specify properties to select (in SQL 
this would be a 'select *') the properties of the node type specified 
by the type constraint are returned. in case of nt:base those 
properties are jcr:primaryType and jcr:mixinTypes.


2) It doesn't seem to me that the query specifies a type constraint, so 
why the check at all?


this is because of the nt:base default described above.


3) I thought support for jcr:score was optional???


It is kind of optional. If an implementation is not able to provide a 
jcr:score it can always return a dummy value.


The spec says: "As well, a score column will also be included, though 
it is not required that its contents always be meaningful."


regards
 marcel