[jira] Updated: (JCR-1861) Support classpath config

[Stephane Landelle (JIRA)]

 [ 
https://issues.apache.org/jira/browse/JCR-1861?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Stephane Landelle updated JCR-1861:
---

Attachment: jackrabbit.patch

Hello,

Here is a new patch.
I've refactored out the code into a ResourceResolver. It's currenlty being used 
by JCARepositoryManager and SearchIndex but might be used for other needs too 
(just that I don't know Jackrabbit deep enough so I can identify where...).

Could this be committed?

Best Regards,

Stéphane Landelle

> Support classpath config
> 
>
> Key: JCR-1861
> URL: https://issues.apache.org/jira/browse/JCR-1861
> Project: Jackrabbit
>  Issue Type: Improvement
>  Components: config
>Reporter: Stephane Landelle
> Fix For: 1.6.0
>
> Attachments: classpathresolvingsearchindex.patch, jackrabbit.patch
>
>   Original Estimate: 0.5h
>  Remaining Estimate: 0.5h
>
> It's possible (and even handy) not to have config resources as Files but as 
> classpath resources, so they can be bundled into the binaries.
> For example, org.apache.jackrabbit.jca.JCARepositoryManager is able to 
> resolve the repository config file as a classpath resource if it's prefixed 
> with "classpath:".
> However, other config files such as the indexing configuration can't 
> currently be resolved this way. IMHO, this is particularly a problem when 
> using a connector, which should operate as a standalone bundle without 
> requiring deploying additional resources on the filesystem.
> Concerning the indexing configuration, I've modified 
> org.apache.jackrabbit.core.query.lucene.SearchIndex.getIndexingConfigurationDOM()
>  so it resolves indexingConfiguration as a classpath resource if it's 
> prefixed with "classpath:":
>protected Element getIndexingConfigurationDOM() {
> if (indexingConfiguration != null) {
> return indexingConfiguration;
> }
> if (indexingConfigPath == null) {
> return null;
> }
> try {
>DocumentBuilderFactory factory =
>  DocumentBuilderFactory.newInstance();
>DocumentBuilder builder = factory.newDocumentBuilder();
>builder.setEntityResolver(new 
> IndexingConfigurationEntityResolver());
>   if (indexingConfigPath.startsWith(CLASSPATH_CONFIG_PREFIX)) {
> ClassLoader cl = 
> Thread.currentThread().getContextClassLoader();
> if (cl == null) {
> cl = this.getClass().getClassLoader();
> }
>   InputStream config = 
> cl.getResourceAsStream(indexingConfigPath.substring(CLASSPATH_CONFIG_PREFIX.length()));
>   if (config == null) {
>   log.warn("Classpath resource does not exist: {}", 
> indexingConfigPath);
>   return null;
>   }
>   indexingConfiguration = 
> builder.parse(config).getDocumentElement();
>   log.info("indexingConfigPath '{}' resolved as classpath 
> resource", indexingConfigPath);
>   } else {
>   File config = new File(indexingConfigPath);
>   if (!config.exists()) {
>   log.warn("File does not exist: {}", 
> indexingConfigPath);
>   return null;
>   } else if (!config.canRead()) {
>   log.warn("Cannot read file: {}", 
> indexingConfigPath);
>   return null;
>   }
>   indexingConfiguration = 
> builder.parse(config).getDocumentElement();
>   }
>
> 
> } catch (ParserConfigurationException e) {
> log.warn("Unable to create XML parser", e);
> } catch (IOException e) {
> log.warn("Exception parsing " + indexingConfigPath, e);
> } catch (SAXException e) {
> log.warn("Exception parsing " + indexingConfigPath, e);
> }
> return indexingConfiguration;
> }
> Would it be possible to commit this in the trunk?
> Best regards,
> Stéphane Landelle

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (JCR-1893) incorrect node type use for frozenNode in ObjectConverterImpl

[Stephane Landelle (JIRA)]

[ 
https://issues.apache.org/jira/browse/JCR-1893?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12655711#action_12655711
 ] 

Stephane Landelle commented on JCR-1893:


I have the same issue.

ObjectConverterImpl.getObject(Session session, Class clazz, String path) indeed 
fails on a frozen node because on contrary to getObject(Session session, String 
path) it doesn't fall back to the jcr:frozenPrimaryType when the primary type 
is nt:frozenNode.

The correction is very simple : just add the following test at line 446 in 
ObjectConverterImpl:

if (nodeType.equals(ManagerConstant.FROZEN_NODE_TYPE)) {
nodeType = 
node.getProperty(ManagerConstant.FROZEN_PRIMARY_TYPE_PROPERTY).getString();
}

Could the trunk be patched with this?

Best regards,

Stéphane Landelle



> incorrect node type use for frozenNode in ObjectConverterImpl
> -
>
> Key: JCR-1893
> URL: https://issues.apache.org/jira/browse/JCR-1893
> Project: Jackrabbit
>  Issue Type: Bug
>  Components: jackrabbit-ocm
>Affects Versions: 1.6.0
>Reporter: Sandrine Raffalli
>
> The class ObjectConverterImpl provides two methods :
> public Object getObject(Session session, String path);
> public Object getObject(Session session, Class clazz, String path);
> In the first method, if the current node has not a discriminator class name 
> property, the class descriptor is found with the primaryNodeType or in case 
> of frozen node, with the frozen primary node type .
> In the second method, the class descriptor is retrieved with the given class 
> and next an alternative descriptor is tried to find, first with a class name 
> discriminator and next with the node type of the current node. But if the 
> current node is a frozen node, a class descriptor is search for the node type 
> "nt:frozenNode" that have no sense.
> A check must be added in the second method if the current node is a frozen 
> node and retrieve the frozen primary node type and not the primary node type 
> that is "nt:frozenNode" in this case.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (JCR-1861) Support classpath config

[Stephane Landelle (JIRA)]

[ 
https://issues.apache.org/jira/browse/JCR-1861?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12650588#action_12650588
 ] 

Stephane Landelle commented on JCR-1861:


Yes, I totally agree, it would be nice to have a resource resolver that
would look up for resources on the filesystem or in the classpath and that
would be used for all the config files (repository.xml, indexing-config,
security-config, etc...).

Maybe we can have something similar to Spring Resource?

Sorry, for the patch format, I guess the linebreaks pb comes from the fact I
work on mac in UTF-8...

2008/11/25 Jukka Zitting (JIRA) <[EMAIL PROTECTED]>



> Support classpath config
> 
>
> Key: JCR-1861
> URL: https://issues.apache.org/jira/browse/JCR-1861
> Project: Jackrabbit
>  Issue Type: Improvement
>  Components: config
>Reporter: Stephane Landelle
> Fix For: 1.6.0
>
> Attachments: classpathresolvingsearchindex.patch
>
>   Original Estimate: 0.5h
>  Remaining Estimate: 0.5h
>
> It's possible (and even handy) not to have config resources as Files but as 
> classpath resources, so they can be bundled into the binaries.
> For example, org.apache.jackrabbit.jca.JCARepositoryManager is able to 
> resolve the repository config file as a classpath resource if it's prefixed 
> with "classpath:".
> However, other config files such as the indexing configuration can't 
> currently be resolved this way. IMHO, this is particularly a problem when 
> using a connector, which should operate as a standalone bundle without 
> requiring deploying additional resources on the filesystem.
> Concerning the indexing configuration, I've modified 
> org.apache.jackrabbit.core.query.lucene.SearchIndex.getIndexingConfigurationDOM()
>  so it resolves indexingConfiguration as a classpath resource if it's 
> prefixed with "classpath:":
>protected Element getIndexingConfigurationDOM() {
> if (indexingConfiguration != null) {
> return indexingConfiguration;
> }
> if (indexingConfigPath == null) {
> return null;
> }
> try {
>DocumentBuilderFactory factory =
>  DocumentBuilderFactory.newInstance();
>DocumentBuilder builder = factory.newDocumentBuilder();
>builder.setEntityResolver(new 
> IndexingConfigurationEntityResolver());
>   if (indexingConfigPath.startsWith(CLASSPATH_CONFIG_PREFIX)) {
> ClassLoader cl = 
> Thread.currentThread().getContextClassLoader();
> if (cl == null) {
> cl = this.getClass().getClassLoader();
> }
>   InputStream config = 
> cl.getResourceAsStream(indexingConfigPath.substring(CLASSPATH_CONFIG_PREFIX.length()));
>   if (config == null) {
>   log.warn("Classpath resource does not exist: {}", 
> indexingConfigPath);
>   return null;
>   }
>   indexingConfiguration = 
> builder.parse(config).getDocumentElement();
>   log.info("indexingConfigPath '{}' resolved as classpath 
> resource", indexingConfigPath);
>   } else {
>   File config = new File(indexingConfigPath);
>   if (!config.exists()) {
>   log.warn("File does not exist: {}", 
> indexingConfigPath);
>   return null;
>   } else if (!config.canRead()) {
>   log.warn("Cannot read file: {}", 
> indexingConfigPath);
>   return null;
>   }
>   indexingConfiguration = 
> builder.parse(config).getDocumentElement();
>   }
>
> 
> } catch (ParserConfigurationException e) {
> log.warn("Unable to create XML parser", e);
> } catch (IOException e) {
> log.warn("Exception parsing " + indexingConfigPath, e);
> } catch (SAXException e) {
> log.warn("Exception parsing " + indexingConfigPath, e);
> }
> return indexingConfiguration;
> }
> Would it be possible to commit this in the trunk?
> Best regards,
> Stéphane Landelle

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (JCR-1861) Support classpath config

[Stephane Landelle (JIRA)]

 [ 
https://issues.apache.org/jira/browse/JCR-1861?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Stephane Landelle updated JCR-1861:
---

Attachment: classpathresolvingsearchindex.patch

Here is an eclipse patch. Patch root is jackrabbit-core.

Best Regards,

Stephane Landelle

> Support classpath config
> 
>
> Key: JCR-1861
> URL: https://issues.apache.org/jira/browse/JCR-1861
> Project: Jackrabbit
>  Issue Type: Improvement
>  Components: config
>Reporter: Stephane Landelle
> Fix For: 1.6.0
>
> Attachments: classpathresolvingsearchindex.patch
>
>   Original Estimate: 0.5h
>  Remaining Estimate: 0.5h
>
> It's possible (and even handy) not to have config resources as Files but as 
> classpath resources, so they can be bundled into the binaries.
> For example, org.apache.jackrabbit.jca.JCARepositoryManager is able to 
> resolve the repository config file as a classpath resource if it's prefixed 
> with "classpath:".
> However, other config files such as the indexing configuration can't 
> currently be resolved this way. IMHO, this is particularly a problem when 
> using a connector, which should operate as a standalone bundle without 
> requiring deploying additional resources on the filesystem.
> Concerning the indexing configuration, I've modified 
> org.apache.jackrabbit.core.query.lucene.SearchIndex.getIndexingConfigurationDOM()
>  so it resolves indexingConfiguration as a classpath resource if it's 
> prefixed with "classpath:":
>protected Element getIndexingConfigurationDOM() {
> if (indexingConfiguration != null) {
> return indexingConfiguration;
> }
> if (indexingConfigPath == null) {
> return null;
> }
> try {
>DocumentBuilderFactory factory =
>  DocumentBuilderFactory.newInstance();
>DocumentBuilder builder = factory.newDocumentBuilder();
>builder.setEntityResolver(new 
> IndexingConfigurationEntityResolver());
>   if (indexingConfigPath.startsWith(CLASSPATH_CONFIG_PREFIX)) {
> ClassLoader cl = 
> Thread.currentThread().getContextClassLoader();
> if (cl == null) {
> cl = this.getClass().getClassLoader();
> }
>   InputStream config = 
> cl.getResourceAsStream(indexingConfigPath.substring(CLASSPATH_CONFIG_PREFIX.length()));
>   if (config == null) {
>   log.warn("Classpath resource does not exist: {}", 
> indexingConfigPath);
>   return null;
>   }
>   indexingConfiguration = 
> builder.parse(config).getDocumentElement();
>   log.info("indexingConfigPath '{}' resolved as classpath 
> resource", indexingConfigPath);
>   } else {
>   File config = new File(indexingConfigPath);
>   if (!config.exists()) {
>   log.warn("File does not exist: {}", 
> indexingConfigPath);
>   return null;
>   } else if (!config.canRead()) {
>   log.warn("Cannot read file: {}", 
> indexingConfigPath);
>   return null;
>   }
>   indexingConfiguration = 
> builder.parse(config).getDocumentElement();
>   }
>
> 
> } catch (ParserConfigurationException e) {
> log.warn("Unable to create XML parser", e);
> } catch (IOException e) {
> log.warn("Exception parsing " + indexingConfigPath, e);
> } catch (SAXException e) {
> log.warn("Exception parsing " + indexingConfigPath, e);
> }
> return indexingConfiguration;
> }
> Would it be possible to commit this in the trunk?
> Best regards,
> Stéphane Landelle

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (JCR-1869) Make lazy loading proxy callback Serializable

[Stephane Landelle (JIRA)]

 [ 
https://issues.apache.org/jira/browse/JCR-1869?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Stephane Landelle updated JCR-1869:
---

Attachment: BeanLazyLoader.java

> Make lazy loading proxy callback Serializable
> -
>
> Key: JCR-1869
> URL: https://issues.apache.org/jira/browse/JCR-1869
> Project: Jackrabbit
>  Issue Type: Improvement
>  Components: jackrabbit-ocm
>Reporter: Stephane Landelle
> Attachments: AbstractLazyLoader.java, BeanLazyLoader.java, 
> CollectionLazyLoader.java
>
>
> Hello (probably Christophe :) ),
> It would be nice to have the CGLib callbacks Serializable, because if they're 
> not, the proxies are not either, even if the target is.
> I've seen that you've made BeanLazyLoader Serializable. Wouldn't be better to 
> have AbstractLazyLoader Serializable, so CollectionLazyLoader is too?
> What I've done is :
> *) declaring AbstractLazyLoader as Serializable
> *) declaring non-Serializable resources such as Session as volatile
> *) throwing an IllegalStateException in BeanLazyLoader.fetch and 
> CollectionLazyLoader.fetch if the Session is null. This case can only happen 
> if the proxy has been serialized without the volatile Session, and it doesn't 
> make sense to lazy load the target then.
> BTW, I realized I didn't clean up the beanClassDescriptor in 
> BeanLazyLoader.cleanUp, so I corrected this.
> I'll attach the modified classes.
> Sincerely,
> Stéphane Landelle

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (JCR-1869) Make lazy loading proxy callback Serializable

[Stephane Landelle (JIRA)]

 [ 
https://issues.apache.org/jira/browse/JCR-1869?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Stephane Landelle updated JCR-1869:
---

Attachment: CollectionLazyLoader.java

> Make lazy loading proxy callback Serializable
> -
>
> Key: JCR-1869
> URL: https://issues.apache.org/jira/browse/JCR-1869
> Project: Jackrabbit
>  Issue Type: Improvement
>  Components: jackrabbit-ocm
>Reporter: Stephane Landelle
> Attachments: AbstractLazyLoader.java, BeanLazyLoader.java, 
> CollectionLazyLoader.java
>
>
> Hello (probably Christophe :) ),
> It would be nice to have the CGLib callbacks Serializable, because if they're 
> not, the proxies are not either, even if the target is.
> I've seen that you've made BeanLazyLoader Serializable. Wouldn't be better to 
> have AbstractLazyLoader Serializable, so CollectionLazyLoader is too?
> What I've done is :
> *) declaring AbstractLazyLoader as Serializable
> *) declaring non-Serializable resources such as Session as volatile
> *) throwing an IllegalStateException in BeanLazyLoader.fetch and 
> CollectionLazyLoader.fetch if the Session is null. This case can only happen 
> if the proxy has been serialized without the volatile Session, and it doesn't 
> make sense to lazy load the target then.
> BTW, I realized I didn't clean up the beanClassDescriptor in 
> BeanLazyLoader.cleanUp, so I corrected this.
> I'll attach the modified classes.
> Sincerely,
> Stéphane Landelle

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Created: (JCR-1869) Make lazy loading proxy callback Serializable

[Stephane Landelle (JIRA)]

Make lazy loading proxy callback Serializable
-

 Key: JCR-1869
 URL: https://issues.apache.org/jira/browse/JCR-1869
 Project: Jackrabbit
  Issue Type: Improvement
  Components: jackrabbit-ocm
Reporter: Stephane Landelle
 Attachments: AbstractLazyLoader.java

Hello (probably Christophe :) ),

It would be nice to have the CGLib callbacks Serializable, because if they're 
not, the proxies are not either, even if the target is.

I've seen that you've made BeanLazyLoader Serializable. Wouldn't be better to 
have AbstractLazyLoader Serializable, so CollectionLazyLoader is too?

What I've done is :
*) declaring AbstractLazyLoader as Serializable
*) declaring non-Serializable resources such as Session as volatile
*) throwing an IllegalStateException in BeanLazyLoader.fetch and 
CollectionLazyLoader.fetch if the Session is null. This case can only happen if 
the proxy has been serialized without the volatile Session, and it doesn't make 
sense to lazy load the target then.

BTW, I realized I didn't clean up the beanClassDescriptor in 
BeanLazyLoader.cleanUp, so I corrected this.

I'll attach the modified classes.

Sincerely,

Stéphane Landelle

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (JCR-1869) Make lazy loading proxy callback Serializable

[Stephane Landelle (JIRA)]

 [ 
https://issues.apache.org/jira/browse/JCR-1869?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Stephane Landelle updated JCR-1869:
---

Attachment: AbstractLazyLoader.java

> Make lazy loading proxy callback Serializable
> -
>
> Key: JCR-1869
> URL: https://issues.apache.org/jira/browse/JCR-1869
> Project: Jackrabbit
>  Issue Type: Improvement
>  Components: jackrabbit-ocm
>Reporter: Stephane Landelle
> Attachments: AbstractLazyLoader.java
>
>
> Hello (probably Christophe :) ),
> It would be nice to have the CGLib callbacks Serializable, because if they're 
> not, the proxies are not either, even if the target is.
> I've seen that you've made BeanLazyLoader Serializable. Wouldn't be better to 
> have AbstractLazyLoader Serializable, so CollectionLazyLoader is too?
> What I've done is :
> *) declaring AbstractLazyLoader as Serializable
> *) declaring non-Serializable resources such as Session as volatile
> *) throwing an IllegalStateException in BeanLazyLoader.fetch and 
> CollectionLazyLoader.fetch if the Session is null. This case can only happen 
> if the proxy has been serialized without the volatile Session, and it doesn't 
> make sense to lazy load the target then.
> BTW, I realized I didn't clean up the beanClassDescriptor in 
> BeanLazyLoader.cleanUp, so I corrected this.
> I'll attach the modified classes.
> Sincerely,
> Stéphane Landelle

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Created: (JCR-1861) Support classpath config

[Stephane Landelle (JIRA)]

Support classpath config


 Key: JCR-1861
 URL: https://issues.apache.org/jira/browse/JCR-1861
 Project: Jackrabbit
  Issue Type: Improvement
  Components: config
Reporter: Stephane Landelle
 Fix For: 1.5.0


It's possible (and even handy) not to have config resources as Files but as 
classpath resources, so they can be bundled into the binaries.
For example, org.apache.jackrabbit.jca.JCARepositoryManager is able to resolve 
the repository config file as a classpath resource if it's prefixed with 
"classpath:".

However, other config files such as the indexing configuration can't currently 
be resolved this way. IMHO, this is particularly a problem when using a 
connector, which should operate as a standalone bundle without requiring 
deploying additional resources on the filesystem.

Concerning the indexing configuration, I've modified 
org.apache.jackrabbit.core.query.lucene.SearchIndex.getIndexingConfigurationDOM()
 so it resolves indexingConfiguration as a classpath resource if it's prefixed 
with "classpath:":

   protected Element getIndexingConfigurationDOM() {
if (indexingConfiguration != null) {
return indexingConfiguration;
}
if (indexingConfigPath == null) {
return null;
}
try {
 DocumentBuilderFactory factory =
 DocumentBuilderFactory.newInstance();
 DocumentBuilder builder = factory.newDocumentBuilder();
 builder.setEntityResolver(new 
IndexingConfigurationEntityResolver());

if (indexingConfigPath.startsWith(CLASSPATH_CONFIG_PREFIX)) {
ClassLoader cl = Thread.currentThread().getContextClassLoader();
if (cl == null) {
cl = this.getClass().getClassLoader();
}
InputStream config = 
cl.getResourceAsStream(indexingConfigPath.substring(CLASSPATH_CONFIG_PREFIX.length()));
if (config == null) {
log.warn("Classpath resource does not exist: {}", 
indexingConfigPath);
return null;
}
indexingConfiguration = 
builder.parse(config).getDocumentElement();
log.info("indexingConfigPath '{}' resolved as classpath 
resource", indexingConfigPath);

} else {
File config = new File(indexingConfigPath);
if (!config.exists()) {
log.warn("File does not exist: {}", 
indexingConfigPath);
return null;
} else if (!config.canRead()) {
log.warn("Cannot read file: {}", 
indexingConfigPath);
return null;
}
indexingConfiguration = 
builder.parse(config).getDocumentElement();
}
   

} catch (ParserConfigurationException e) {
log.warn("Unable to create XML parser", e);
} catch (IOException e) {
log.warn("Exception parsing " + indexingConfigPath, e);
} catch (SAXException e) {
log.warn("Exception parsing " + indexingConfigPath, e);
}
return indexingConfiguration;
}

Would it be possible to commit this in the trunk?

Best regards,

Stéphane Landelle

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (JCR-1813) Invalid journal records during XATransactions

[Stephane Landelle (JIRA)]

[ 
https://issues.apache.org/jira/browse/JCR-1813?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12640844#action_12640844
 ] 

Stephane Landelle commented on JCR-1813:


Hello Jukka,

Are you sure the problem is specific to XA transactions?

I guess the same problem happens with local transactions. One might not have
actual updates to commit, depending on the business code executed inside the
transaction.

So I think every SharedItemStateManager is impacted and that testing if the
ChangeLog has actual updates should be done in the core methods.

Am I wrong somewhere?

Best regards,

Stephane Landelle

2008/10/19 Jukka Zitting (JIRA) <[EMAIL PROTECTED]>



> Invalid journal records during XATransactions
> -
>
> Key: JCR-1813
> URL: https://issues.apache.org/jira/browse/JCR-1813
> Project: Jackrabbit
>  Issue Type: Bug
>  Components: clustering, jackrabbit-core
>Reporter: Stephane Landelle
>Assignee: Jukka Zitting
>Priority: Critical
> Fix For: 1.5.0
>
>
> During the prepare phase of a XATransaction, XAItemStateManager.prepare calls 
> ShareItemStageManager.beginUpdate that, in case of a ClusterNode, calls 
> ClusterNode.updatePrepared that does a ChangeLogRecord.write().
> This last method is located in ClusterRecord and systematically write the 
> begin and the end of the journal record.
> As a consequence, useless corrupted records are written in the journal 
> everytime a transaction ends without jackrabbit update! This causes polution 
> of the journal, as other cluster nodes try to sync with the corrupted updates 
> and fail doing so as ClusterRecordDeserializer can't deserialize it (the 
> record identifier is empty).
> ChangeLogRecord (and even other ClusterRecord implementations too) should 
> only write if there's effective updates.
> I propose the following solution:
> *) add the following method in Changelog so clients can know if there's 
> effective updates:
> public boolean hasUpdates() {
>   return !(addedStates.isEmpty() && modifiedStates.isEmpty() && 
> deletedStates.isEmpty() && modifiedRefs.isEmpty());
> }
> *) change ClusterRecord with:
> public final void write() throws JournalException {
>   
>   if (hasUpdates()) {
>   record.writeString(workspace);
>   doWrite();
>   record.writeChar(END_MARKER);
>   }
> }
> 
> protected abstract boolean hasUpdates();
> *) implement hasUpdates for every ClusterRecord implementation:
>  > ChangeLogRecord:
> protected boolean hasUpdates() {
>   return changes.hasUpdates() || !events.isEmpty();
> }
>  > LockRecord and NamespaceRecord:
> protected boolean hasUpdates() {
>   return true;
> }
>  > NodeTypeRecord:
> protected boolean hasUpdates() {
>   return !collection.isEmpty();
> }
> Best regards,
> Stephane Landelle

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (JCR-1813) Invalid journal records during XATransactions

[Stephane Landelle (JIRA)]

[ 
https://issues.apache.org/jira/browse/JCR-1813?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12639880#action_12639880
 ] 

Stephane Landelle commented on JCR-1813:


My bad, my patch writes null records instead of not writing them.

A better solution would consist in:

   - adding the hasUpdates method to ChangeLog
   - skipping begin and end in
   org.apache.jackrabbit.core.state.SharedItemStateManager$Update if local has
   no updates with somehing like:

if (!local.hasUpdates()) {
return;
}

Sincerely,

Stephane Landelle

2008/10/15 Stephane Landelle (JIRA) <[EMAIL PROTECTED]>



> Invalid journal records during XATransactions
> -
>
> Key: JCR-1813
> URL: https://issues.apache.org/jira/browse/JCR-1813
> Project: Jackrabbit
>  Issue Type: Bug
>  Components: clustering
>Reporter: Stephane Landelle
>Priority: Critical
>
> During the prepare phase of a XATransaction, XAItemStateManager.prepare calls 
> ShareItemStageManager.beginUpdate that, in case of a ClusterNode, calls 
> ClusterNode.updatePrepared that does a ChangeLogRecord.write().
> This last method is located in ClusterRecord and systematically write the 
> begin and the end of the journal record.
> As a consequence, useless corrupted records are written in the journal 
> everytime a transaction ends without jackrabbit update! This causes polution 
> of the journal, as other cluster nodes try to sync with the corrupted updates 
> and fail doing so as ClusterRecordDeserializer can't deserialize it (the 
> record identifier is empty).
> ChangeLogRecord (and even other ClusterRecord implementations too) should 
> only write if there's effective updates.
> I propose the following solution:
> *) add the following method in Changelog so clients can know if there's 
> effective updates:
> public boolean hasUpdates() {
>   return !(addedStates.isEmpty() && modifiedStates.isEmpty() && 
> deletedStates.isEmpty() && modifiedRefs.isEmpty());
> }
> *) change ClusterRecord with:
> public final void write() throws JournalException {
>   
>   if (hasUpdates()) {
>   record.writeString(workspace);
>   doWrite();
>   record.writeChar(END_MARKER);
>   }
> }
> 
> protected abstract boolean hasUpdates();
> *) implement hasUpdates for every ClusterRecord implementation:
>  > ChangeLogRecord:
> protected boolean hasUpdates() {
>   return changes.hasUpdates() || !events.isEmpty();
> }
>  > LockRecord and NamespaceRecord:
> protected boolean hasUpdates() {
>   return true;
> }
>  > NodeTypeRecord:
> protected boolean hasUpdates() {
>   return !collection.isEmpty();
> }
> Best regards,
> Stephane Landelle

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Created: (JCR-1814) Update maven-eclipse-plugin to 1.4 source evel

[Stephane Landelle (JIRA)]

Update maven-eclipse-plugin to 1.4 source evel
--

 Key: JCR-1814
 URL: https://issues.apache.org/jira/browse/JCR-1814
 Project: Jackrabbit
  Issue Type: Bug
Reporter: Stephane Landelle
Priority: Trivial


org.apache.jackrabbit.core.data.FileDataRecord uses assertions.
Please update maven-eclipse-plugin configuration so projects are not configured 
with 1.3 compilation:

maven-eclipse-plugin

1.4
1.4
  true

  

Sincerely,

Stephane Landelle

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Created: (JCR-1813) Invalid journal records during XATransactions

[Stephane Landelle (JIRA)]

Invalid journal records during XATransactions
-

 Key: JCR-1813
 URL: https://issues.apache.org/jira/browse/JCR-1813
 Project: Jackrabbit
  Issue Type: Bug
  Components: clustering
Reporter: Stephane Landelle
Priority: Critical


During the prepare phase of a XATransaction, XAItemStateManager.prepare calls 
ShareItemStageManager.beginUpdate that, in case of a ClusterNode, calls 
ClusterNode.updatePrepared that does a ChangeLogRecord.write().

This last method is located in ClusterRecord and systematically write the begin 
and the end of the journal record.

As a consequence, useless corrupted records are written in the journal 
everytime a transaction ends without jackrabbit update! This causes polution of 
the journal, as other cluster nodes try to sync with the corrupted updates and 
fail doing so as ClusterRecordDeserializer can't deserialize it (the record 
identifier is empty).

ChangeLogRecord (and even other ClusterRecord implementations too) should only 
write if there's effective updates.

I propose the following solution:
*) add the following method in Changelog so clients can know if there's 
effective updates:
public boolean hasUpdates() {
return !(addedStates.isEmpty() && modifiedStates.isEmpty() && 
deletedStates.isEmpty() && modifiedRefs.isEmpty());
}

*) change ClusterRecord with:
public final void write() throws JournalException {

if (hasUpdates()) {
record.writeString(workspace);
doWrite();
record.writeChar(END_MARKER);
}
}

protected abstract boolean hasUpdates();

*) implement hasUpdates for every ClusterRecord implementation:
 > ChangeLogRecord:
protected boolean hasUpdates() {
return changes.hasUpdates() || !events.isEmpty();
}
 > LockRecord and NamespaceRecord:
protected boolean hasUpdates() {
return true;
}

 > NodeTypeRecord:
protected boolean hasUpdates() {
return !collection.isEmpty();
}

Best regards,

Stephane Landelle

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (JCR-1788) Maven variable collision

[Stephane Landelle (JIRA)]

[ 
https://issues.apache.org/jira/browse/JCR-1788?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12637493#action_12637493
 ] 

Stephane Landelle commented on JCR-1788:


Possible an old bug in maven is back:
http://jira.codehaus.org/browse/MRESOURCES-20?focusedCommentId=74186


2008/10/7 Thomas Mueller (JIRA) <[EMAIL PROTECTED]>



> Maven variable collision
> 
>
> Key: JCR-1788
> URL: https://issues.apache.org/jira/browse/JCR-1788
> Project: Jackrabbit
>  Issue Type: Bug
>  Components: config
> Environment: maven 2.0.9, 2.1.0-M1
>Reporter: Stephane Landelle
> Attachments: maven-filtering-test.zip
>
>   Original Estimate: 0.08h
>  Remaining Estimate: 0.08h
>
> The jackrabbit config file uses a variable ${wsp.name}.
> This variable name is already used by maven during filtering and holds the 
> project name.
> As a consequence, when trying to filter the file in order for example to 
> change the Cluster Node Id, the file gets corrupted.
> Please find test project enclosed.
> Patch is very simple : you can keep old variables for compatibility, just 
> duplicate variable with a jackrabbit specific name such as "jr.wsp.name" and 
> add in org.apache.jackrabbit.core.config.RepositoryConfigurationParser:
> line 62:
> /** Name of the repository name parser variable. */
> public static final String MAVEN_SUPPORTING_WORKSPACE_NAME_VARIABLE = 
> "jr.wsp.name";
> line 420:
> // add a dupplicate that supports maven filtering
> tmpVariables.put(MAVEN_SUPPORTING_WORKSPACE_NAME_VARIABLE, name);
> This should even be done for other variables to avoid possible later 
> collisions.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (JCR-1788) Maven variable collision

[Stephane Landelle (JIRA)]

[ 
https://issues.apache.org/jira/browse/JCR-1788?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12637460#action_12637460
 ] 

Stephane Landelle commented on JCR-1788:


Hi Thomas,

I haven't found anything in the official documentation yet, but that's no
surprise, it's not really up-to-date...

If you install the attached project, you'll see that ${wsp.name} has indeed
been replaced by "Maven Filtering Test Project Name" which is the name
declared in the pom.

I'll try to find a reference in the documentation or even the code, but I'm
quite pessimistic...

Sincererly,

Stephane

2008/10/7 Thomas Mueller (JIRA) <[EMAIL PROTECTED]>



> Maven variable collision
> 
>
> Key: JCR-1788
> URL: https://issues.apache.org/jira/browse/JCR-1788
> Project: Jackrabbit
>  Issue Type: Bug
>  Components: config
> Environment: Leopard, maven 2.1.0-M1
>Reporter: Stephane Landelle
> Attachments: maven-filtering-test.zip
>
>   Original Estimate: 0.08h
>  Remaining Estimate: 0.08h
>
> The jackrabbit config file uses a variable ${wsp.name}.
> This variable name is already used by maven during filtering and holds the 
> project name.
> As a consequence, when trying to filter the file in order for example to 
> change the Cluster Node Id, the file gets corrupted.
> Please find test project enclosed.
> Patch is very simple : you can keep old variables for compatibility, just 
> duplicate variable with a jackrabbit specific name such as "jr.wsp.name" and 
> add in org.apache.jackrabbit.core.config.RepositoryConfigurationParser:
> line 62:
> /** Name of the repository name parser variable. */
> public static final String MAVEN_SUPPORTING_WORKSPACE_NAME_VARIABLE = 
> "jr.wsp.name";
> line 420:
> // add a dupplicate that supports maven filtering
> tmpVariables.put(MAVEN_SUPPORTING_WORKSPACE_NAME_VARIABLE, name);
> This should even be done for other variables to avoid possible later 
> collisions.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Created: (JCR-1788) Maven variable collision

[Stephane Landelle (JIRA)]

Maven variable collision


 Key: JCR-1788
 URL: https://issues.apache.org/jira/browse/JCR-1788
 Project: Jackrabbit
  Issue Type: Bug
  Components: config
 Environment: Leopard, maven 2.1.0-M1
Reporter: Stephane Landelle
 Attachments: maven-filtering-test.zip

The jackrabbit config file uses a variable ${wsp.name}.
This variable name is already used by maven during filtering and holds the 
project name.

As a consequence, when trying to filter the file in order for example to change 
the Cluster Node Id, the file gets corrupted.

Please find test project enclosed.

Patch is very simple : you can keep old variables for compatibility, just 
duplicate variable with a jackrabbit specific name such as "jr.wsp.name" and 
add in org.apache.jackrabbit.core.config.RepositoryConfigurationParser:
line 62:
/** Name of the repository name parser variable. */
public static final String MAVEN_SUPPORTING_WORKSPACE_NAME_VARIABLE = 
"jr.wsp.name";

line 420:
// add a dupplicate that supports maven filtering
tmpVariables.put(MAVEN_SUPPORTING_WORKSPACE_NAME_VARIABLE, name);

This should even be done for other variables to avoid possible later collisions.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (JCR-1788) Maven variable collision

[Stephane Landelle (JIRA)]

 [ 
https://issues.apache.org/jira/browse/JCR-1788?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Stephane Landelle updated JCR-1788:
---

Attachment: maven-filtering-test.zip

> Maven variable collision
> 
>
> Key: JCR-1788
> URL: https://issues.apache.org/jira/browse/JCR-1788
> Project: Jackrabbit
>  Issue Type: Bug
>  Components: config
> Environment: Leopard, maven 2.1.0-M1
>Reporter: Stephane Landelle
> Attachments: maven-filtering-test.zip
>
>   Original Estimate: 0.08h
>  Remaining Estimate: 0.08h
>
> The jackrabbit config file uses a variable ${wsp.name}.
> This variable name is already used by maven during filtering and holds the 
> project name.
> As a consequence, when trying to filter the file in order for example to 
> change the Cluster Node Id, the file gets corrupted.
> Please find test project enclosed.
> Patch is very simple : you can keep old variables for compatibility, just 
> duplicate variable with a jackrabbit specific name such as "jr.wsp.name" and 
> add in org.apache.jackrabbit.core.config.RepositoryConfigurationParser:
> line 62:
> /** Name of the repository name parser variable. */
> public static final String MAVEN_SUPPORTING_WORKSPACE_NAME_VARIABLE = 
> "jr.wsp.name";
> line 420:
> // add a dupplicate that supports maven filtering
> tmpVariables.put(MAVEN_SUPPORTING_WORKSPACE_NAME_VARIABLE, name);
> This should even be done for other variables to avoid possible later 
> collisions.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (JCR-1751) Update slf4j

[Stephane Landelle (JIRA)]

[ 
https://issues.apache.org/jira/browse/JCR-1751?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12633796#action_12633796
 ] 

Stephane Landelle commented on JCR-1751:


I agree, jackrabbit shouldn't in any way depend on jcl104-over-slf4j with a
compile scope.

Currently, only jackrabbit-webapp and jackrabbit-text-extractor depend on
jcl104-over-slf4j (both with compile scope).

Concerning jackrabbit-webapp, scope should be runtime, not compile as it is
now.
Concerning jackrabbit-text-extractor, I don't understand why it depends on
jcl104-over-slf4j in the first place. Should it be remove? Should scope be
changed to test?

Sincerely,

Stephane Landelle

2008/9/23 Jukka Zitting (JIRA) <[EMAIL PROTECTED]>



> Update slf4j
> 
>
> Key: JCR-1751
> URL: https://issues.apache.org/jira/browse/JCR-1751
> Project: Jackrabbit
>  Issue Type: Improvement
>  Components: maven
>Reporter: Stephane Landelle
>Assignee: Jukka Zitting
>Priority: Minor
> Fix For: 1.5
>
>   Original Estimate: 0.08h
>  Remaining Estimate: 0.08h
>
> Please update slf4j from 1.3.0 to 1.5.2.
> jcl104-over-slf4j has been renamed as jcl-over-slf4j, so if one uses a recent 
> version, he has to exclude jcl104-over-slf4j for every jackrabbit dependency, 
> which is quite a pain...
> No impact observed.
> Best regards,
> Stephane Landelle

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (JCR-1752) Allow users to disable validation

[Stephane Landelle (JIRA)]

[ 
https://issues.apache.org/jira/browse/JCR-1752?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12633494#action_12633494
 ] 

Stephane Landelle commented on JCR-1752:


Great, thanks!

2008/9/22 Christophe Lombart (JIRA) <[EMAIL PROTECTED]>



> Allow users to disable validation
> -
>
> Key: JCR-1752
> URL: https://issues.apache.org/jira/browse/JCR-1752
> Project: Jackrabbit
>  Issue Type: Improvement
>  Components: jackrabbit-ocm
>Reporter: Stephane Landelle
>Assignee: Christophe Lombart
>Priority: Minor
> Fix For: 1.5
>
>   Original Estimate: 0.08h
>  Remaining Estimate: 0.08h
>
> DigesterMapperImpl leaves validating set to default true when creating a 
> DigesterDescriptorReader.
> But as the dtd is not available anywhere (published or in the source), it is 
> usually not declared in mapping files, and DigesterDescriptorReader complains 
> about it.
> Could it be possible to leave the user a way to configure the validation? The 
> simpliest way would be to add this constructor to DigesterMapperImpl :
> public DigesterMapperImpl(InputStream[] streams, boolean validate) {
> descriptorReader = new DigesterDescriptorReader(streams);
> 
> DigesterDescriptorReader.class.cast(descriptorReader).setValidating(validate);
> this.buildMapper();
> }
> Best regard,
> Stephane Landelle

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (JCR-1751) Update slf4j

[Stephane Landelle (JIRA)]

[ 
https://issues.apache.org/jira/browse/JCR-1751?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12633478#action_12633478
 ] 

Stephane Landelle commented on JCR-1751:


I just hadn't noticed that a new release was made 10 days ago. So 1.5.3 it
is! :)

If you have a look at the jcl104-over-slf4j
POM,
you'll see that it's deprecated and relocated to jcl-over-slf4j. So it would
be cleaner to update the dependency and not only the version.

Sincerely,

Stephane


2008/9/22 Micah Whitacre (JIRA) <[EMAIL PROTECTED]>



> Update slf4j
> 
>
> Key: JCR-1751
> URL: https://issues.apache.org/jira/browse/JCR-1751
> Project: Jackrabbit
>  Issue Type: Improvement
>Reporter: Stephane Landelle
>Priority: Minor
>   Original Estimate: 0.08h
>  Remaining Estimate: 0.08h
>
> Please update slf4j from 1.3.0 to 1.5.2.
> jcl104-over-slf4j has been renamed as jcl-over-slf4j, so if one uses a recent 
> version, he has to exclude jcl104-over-slf4j for every jackrabbit dependency, 
> which is quite a pain...
> No impact observed.
> Best regards,
> Stephane Landelle

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Created: (JCR-1752) Allow users to disable validation

[Stephane Landelle (JIRA)]

Allow users to disable validation
-

 Key: JCR-1752
 URL: https://issues.apache.org/jira/browse/JCR-1752
 Project: Jackrabbit
  Issue Type: Improvement
  Components: jackrabbit-ocm
Reporter: Stephane Landelle
Priority: Minor


DigesterMapperImpl leaves validating set to default true when creating a 
DigesterDescriptorReader.

But as the dtd is not available anywhere (published or in the source), it is 
usually not declared in mapping files, and DigesterDescriptorReader complains 
about it.

Could it be possible to leave the user a way to configure the validation? The 
simpliest way would be to add this constructor to DigesterMapperImpl :

public DigesterMapperImpl(InputStream[] streams, boolean validate) {
descriptorReader = new DigesterDescriptorReader(streams);

DigesterDescriptorReader.class.cast(descriptorReader).setValidating(validate);
this.buildMapper();
}

Best regard,

Stephane Landelle

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Created: (JCR-1751) Update slf4j

[Stephane Landelle (JIRA)]

Update slf4j


 Key: JCR-1751
 URL: https://issues.apache.org/jira/browse/JCR-1751
 Project: Jackrabbit
  Issue Type: Improvement
Reporter: Stephane Landelle
Priority: Minor


Please update slf4j from 1.3.0 to 1.5.2.

jcl104-over-slf4j has been renamed as jcl-over-slf4j, so if one uses a recent 
version, he has to exclude jcl104-over-slf4j for every jackrabbit dependency, 
which is quite a pain...

No impact observed.

Best regards,

Stephane Landelle

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Created: (JCR-1725) DbDataStore init fails if tablePrefix specified

[Stephane Landelle (JIRA)]

DbDataStore init fails if tablePrefix specified
---

 Key: JCR-1725
 URL: https://issues.apache.org/jira/browse/JCR-1725
 Project: Jackrabbit
  Issue Type: Bug
Affects Versions: core 1.4.5
Reporter: Stephane Landelle


In DbDataStore, init method checks if the table exists and otherwise creates it.
However, the test only take the table name and not the optional table name 
prefix.

Please modify :
ResultSet rs = meta.getTables(null, null, tableSQL, null);
as :
ResultSet rs = meta.getTables(null, null, tablePrefix + tableSQL, null);

Sincerely,

Stephane Landelle

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (JCR-1703) Oracle JNDI DataSource support

[Stephane Landelle (JIRA)]

[ 
https://issues.apache.org/jira/browse/JCR-1703?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12623746#action_12623746
 ] 

Stephane Landelle commented on JCR-1703:


Hello,

Here is my repository config :

































































































My problem is actually with the
org.apache.jackrabbit.core.persistence.db.OraclePersistenceManager, not the
bundle one.

I just saw a close ticket (JCR-1562) with similar problem. Would it be
possible to apply the same kind of patch?

Sincerely,

Stéphane


2008/8/18 Thomas Mueller (JIRA) <[EMAIL PROTECTED]>



> Oracle JNDI DataSource support
> --
>
> Key: JCR-1703
> URL: https://issues.apache.org/jira/browse/JCR-1703
> Project: Jackrabbit
>  Issue Type: Bug
>  Components: jackrabbit-core
>Affects Versions: core 1.4.5
>Reporter: Stephane Landelle
>   Original Estimate: 0.08h
>  Remaining Estimate: 0.08h
>
> When org.apache.jackrabbit.core.persistence.bundle.util.ConnectionFactory 
> tries to get a connection from a JNDI Datasource without login and pasword, 
> if no user/password are specified, they re retrieved as empty strings, not 
> null, so it tries to do a ds.getConnection(user, password), which fails. 
> Please complete the test line 66 as :
> if ((user == null || user.length() > 0) && (password == null || 
> password.length() > 0)) {
> Sincerely,
> Stéphane Landelle

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (JCR-1703) Oracle JNDI DataSource support

[Stephane Landelle (JIRA)]

[ 
https://issues.apache.org/jira/browse/JCR-1703?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12619862#action_12619862
 ] 

Stephane Landelle commented on JCR-1703:


Oups, I meant :
if ((user == null || user.length() == 0) && (password == null || 
password.length() == 0)) {

> Oracle JNDI DataSource support
> --
>
> Key: JCR-1703
> URL: https://issues.apache.org/jira/browse/JCR-1703
> Project: Jackrabbit
>  Issue Type: Bug
>  Components: jackrabbit-core
>Affects Versions: core 1.4.5
>Reporter: Stephane Landelle
>   Original Estimate: 0.08h
>  Remaining Estimate: 0.08h
>
> When org.apache.jackrabbit.core.persistence.bundle.util.ConnectionFactory 
> tries to get a connection from a JNDI Datasource without login and pasword, 
> if no user/password are specified, they re retrieved as empty strings, not 
> null, so it tries to do a ds.getConnection(user, password), which fails. 
> Please complete the test line 66 as :
> if ((user == null || user.length() > 0) && (password == null || 
> password.length() > 0)) {
> Sincerely,
> Stéphane Landelle

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (JCR-1704) Indexing rules inheritance doesn't work

[Stephane Landelle (JIRA)]

[ 
https://issues.apache.org/jira/browse/JCR-1704?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12619537#action_12619537
 ] 

Stephane Landelle commented on JCR-1704:


Great, thank you!

2008/8/4 Marcel Reutegger (JIRA) <[EMAIL PROTECTED]>



> Indexing rules inheritance doesn't work
> ---
>
> Key: JCR-1704
> URL: https://issues.apache.org/jira/browse/JCR-1704
> Project: Jackrabbit
>  Issue Type: Bug
>  Components: indexing
>Affects Versions: core 1.4.5
>Reporter: Stephane Landelle
> Fix For: 1.5
>
> Attachments: IndexingConfigurationImpl.java
>
>   Original Estimate: 0.17h
>  Remaining Estimate: 0.17h
>
> Indexing rules are supposed to be inherited by children node types.
> In org.apache.jackrabbit.core.query.lucene.IndexingConfigurationImpl.init, 
> rules are registered for the declared node type and all its children. 
> However, as the rule's node type is still the original one, the rule gets 
> rejected in 
> org.apache.jackrabbit.core.query.lucene.IndexingConfigurationImpl$IndexingRule.appliesTo.
> One simple solution would be to register not the original rule, but a copy 
> where the original node type has been replaced by the child one.
> Please find corrected class attached.
> Sincerely,
> Stéphane

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (JCR-1704) Indexing rules inheritance doesn't work

[Stephane Landelle (JIRA)]

 [ 
https://issues.apache.org/jira/browse/JCR-1704?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Stephane Landelle updated JCR-1704:
---

Attachment: IndexingConfigurationImpl.java

> Indexing rules inheritance doesn't work
> ---
>
> Key: JCR-1704
> URL: https://issues.apache.org/jira/browse/JCR-1704
> Project: Jackrabbit
>  Issue Type: Bug
>  Components: indexing
>Affects Versions: core 1.4.5
>Reporter: Stephane Landelle
> Attachments: IndexingConfigurationImpl.java
>
>   Original Estimate: 0.17h
>  Remaining Estimate: 0.17h
>
> Indexing rules are supposed to be inherited by children node types.
> In org.apache.jackrabbit.core.query.lucene.IndexingConfigurationImpl.init, 
> rules are registered for the declared node type and all its children. 
> However, as the rule's node type is still the original one, the rule gets 
> rejected in 
> org.apache.jackrabbit.core.query.lucene.IndexingConfigurationImpl$IndexingRule.appliesTo.
> One simple solution would be to register not the original rule, but a copy 
> where the original node type has been replaced by the child one.
> Please find corrected class attached.
> Sincerely,
> Stéphane

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Created: (JCR-1704) Indexing rules inheritance doesn't work

[Stephane Landelle (JIRA)]

Indexing rules inheritance doesn't work
---

 Key: JCR-1704
 URL: https://issues.apache.org/jira/browse/JCR-1704
 Project: Jackrabbit
  Issue Type: Bug
  Components: indexing
Affects Versions: core 1.4.5
Reporter: Stephane Landelle


Indexing rules are supposed to be inherited by children node types.
In org.apache.jackrabbit.core.query.lucene.IndexingConfigurationImpl.init, 
rules are registered for the declared node type and all its children. However, 
as the rule's node type is still the original one, the rule gets rejected in 
org.apache.jackrabbit.core.query.lucene.IndexingConfigurationImpl$IndexingRule.appliesTo.

One simple solution would be to register not the original rule, but a copy 
where the original node type has been replaced by the child one.

Please find corrected class attached.

Sincerely,

Stéphane

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Created: (JCR-1703) Oracle JNDI DataSource support

[Stephane Landelle (JIRA)]

Oracle JNDI DataSource support
--

 Key: JCR-1703
 URL: https://issues.apache.org/jira/browse/JCR-1703
 Project: Jackrabbit
  Issue Type: Bug
  Components: jackrabbit-core
Affects Versions: core 1.4.5
Reporter: Stephane Landelle


When org.apache.jackrabbit.core.persistence.bundle.util.ConnectionFactory tries 
to get a connection from a JNDI Datasource without login and pasword, if no 
user/password are specified, they re retrieved as empty strings, not null, so 
it tries to do a ds.getConnection(user, password), which fails. Please complete 
the test line 66 as :
if ((user == null || user.length() > 0) && (password == null || 
password.length() > 0)) {

Sincerely,

Stéphane Landelle

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (JCR-1470) NPE in BeanReferenceCollectionConverterImpl on update on empty collection

[Stephane Landelle (JIRA)]

[ 
https://issues.apache.org/jira/browse/JCR-1470?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12599354#action_12599354
 ] 

Stephane Landelle commented on JCR-1470:


I can no longer reproduce it either. It might have been corrected somehow...
Please consider this case closed.

Sincerely,

Stéphane Landelle




> NPE in BeanReferenceCollectionConverterImpl on update on empty collection
> -
>
> Key: JCR-1470
> URL: https://issues.apache.org/jira/browse/JCR-1470
> Project: Jackrabbit
>  Issue Type: Bug
>  Components: jackrabbit-ocm
>Affects Versions: 1.5
> Environment: mac os leopard, java5
>Reporter: Stephane Landelle
>Assignee: Christophe Lombart
>
> use case :
> in the same transaction :
> *) retrieve an object that has a collection of references, yet empty
> *) add an element in the collection
> *) update the object
> consequence :
> org.apache.jackrabbit.ocm.exception.ObjectContentManagerException: Cannot 
> insert collection field : authors of class com.weka.content.api.model.Folder; 
> nested exception is java.lang.NullPointerException: null
> java.lang.NullPointerException
>   at 
> org.apache.jackrabbit.ocm.manager.collectionconverter.impl.ManageableArrayList$$EnhancerByCGLIB$$8f15dde4.getSize()
>   at 
> org.apache.jackrabbit.ocm.manager.collectionconverter.impl.BeanReferenceCollectionConverterImpl.addUuidProperties(BeanReferenceCollectionConverterImpl.java:154)
>   at 
> org.apache.jackrabbit.ocm.manager.collectionconverter.impl.BeanReferenceCollectionConverterImpl.doUpdateCollection(BeanReferenceCollectionConverterImpl.java:101)
> The failing line is in addUuidProperties :
> Value[] values = new Value[collection.getSize()];
> It seems the CGlib enhanced collection fails and needs to be initialized 
> before.
> For example, in doUpdateCollection, if I code :
>   // Delete existing values
>   if (parentNode.hasProperty(jcrName)) {
>   parentNode.setProperty(jcrName, (Value[]) null);
>   }
>   
>   if (collection != null) {
>   collection.getSize(); <<
>   }
> I get a NPE on collection.getSize();
> but if I code :
>   if (collection != null) {
>   collection.getSize();
>   }
>   // Delete existing values
>   if (parentNode.hasProperty(jcrName)) {
>   parentNode.setProperty(jcrName, (Value[]) null);
>   }
> everything runs fine?!

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (JCR-1624) Proxies improvement

[Stephane Landelle (JIRA)]

 [ 
https://issues.apache.org/jira/browse/JCR-1624?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Stephane Landelle updated JCR-1624:
---

Attachment: ocm-proxy.patch.rtf

> Proxies improvement
> ---
>
> Key: JCR-1624
> URL: https://issues.apache.org/jira/browse/JCR-1624
> Project: Jackrabbit
>  Issue Type: Improvement
>  Components: jackrabbit-ocm
>Affects Versions: 1.5
> Environment: Mac OS X, Java 5
>Reporter: Stephane Landelle
> Attachments: ocm-proxy.patch.rtf
>
>   Original Estimate: 1h
>  Remaining Estimate: 1h
>
> 1) Improvement :
> I need to be able to detect when a bean is an OCM proxy and if it has already 
> been loaded. This kind of functionnality is for example on Hibernate with 
> Hibernate.isInitialized(Object proxy).
> I have developped something similar : I have modified ProxyManagerImpl so it 
> uses an InvocationHandler instead of a LazyLoader. This way, I make my 
> proxies implement a special interface whose methods are intercepted.
> 2) Bug :
> If a BeanConverter is specified, ObjectConverterImpl should pass it to the 
> proxy CallBack instead letting BeanLazyLoader use the default 
> ObjectConverter. I think this is a bug, as the behavior is different is bean 
> property is proxified or not.
> 3) Improvement :
> If a jcrType mapped on a java type is specified, ObjectConverterImpl should 
> make a proxy of this type, and not use the the bean property type. This is 
> particularly useful when the bean property type is an interface.
> Sorry for reporting this as a bundle instead of seperate items, but I 
> developped my patch as a whole.  
> Let me know if you need help on the enclosing patch.
> Sincerely,
> Stéphane Landelle

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Created: (JCR-1624) Proxies improvement

[Stephane Landelle (JIRA)]

Proxies improvement
---

 Key: JCR-1624
 URL: https://issues.apache.org/jira/browse/JCR-1624
 Project: Jackrabbit
  Issue Type: Improvement
  Components: jackrabbit-ocm
Affects Versions: 1.5
 Environment: Mac OS X, Java 5
Reporter: Stephane Landelle


1) Improvement :
I need to be able to detect when a bean is an OCM proxy and if it has already 
been loaded. This kind of functionnality is for example on Hibernate with 
Hibernate.isInitialized(Object proxy).
I have developped something similar : I have modified ProxyManagerImpl so it 
uses an InvocationHandler instead of a LazyLoader. This way, I make my proxies 
implement a special interface whose methods are intercepted.

2) Bug :
If a BeanConverter is specified, ObjectConverterImpl should pass it to the 
proxy CallBack instead letting BeanLazyLoader use the default ObjectConverter. 
I think this is a bug, as the behavior is different is bean property is 
proxified or not.

3) Improvement :
If a jcrType mapped on a java type is specified, ObjectConverterImpl should 
make a proxy of this type, and not use the the bean property type. This is 
particularly useful when the bean property type is an interface.

Sorry for reporting this as a bundle instead of seperate items, but I 
developped my patch as a whole.  
Let me know if you need help on the enclosing patch.

Sincerely,

Stéphane Landelle

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (JCR-1537) ClassDescriptor.hasIdField() fails if id is declared in upper class

[Stephane Landelle (JIRA)]

[ 
https://issues.apache.org/jira/browse/JCR-1537?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12599344#action_12599344
 ] 

Stephane Landelle commented on JCR-1537:


All good!




> ClassDescriptor.hasIdField() fails if id is declared in upper class
> ---
>
> Key: JCR-1537
> URL: https://issues.apache.org/jira/browse/JCR-1537
> Project: Jackrabbit
>  Issue Type: Bug
>  Components: jackrabbit-ocm
>Affects Versions: 1.5
> Environment: Mac OS X, JVM 1.5
>Reporter: Stephane Landelle
>Assignee: Christophe Lombart
> Fix For: 1.5
>
> Attachments: jackrabbit-ocm.patch
>
>   Original Estimate: 0.02h
>  Remaining Estimate: 0.02h
>
> org.apache.jackrabbit.ocm.mapper.model.ClassDescriptor.hasIdField() looks up 
> only current class and not the whole hierarchy, so it fails when the id field 
> is declared in a upper class.
> hasIdField should use getIdFieldDescriptor and not access idFieldDescriptor 
> field directly, as follows :
> public boolean hasIdField() {
>   return (this.getIdFieldDescriptor() != null && this
>   .getIdFieldDescriptor().isId());
> }
> Please find patch enclosed.
> Sincerely yours,
> Stéphane Landelle

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (JCR-1548) Several bugs in last SVN commit

[Stephane Landelle (JIRA)]

[ 
https://issues.apache.org/jira/browse/JCR-1548?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12591426#action_12591426
 ] 

Stephane Landelle commented on JCR-1548:


There's still a "throw" missing on line 69 in
org.apache.jackrabbit.ocm.manager.collectionconverter.ManageableObjectsUtil.getManageableObjects...
:)

Stéphane




> Several bugs in last SVN commit
> ---
>
> Key: JCR-1548
> URL: https://issues.apache.org/jira/browse/JCR-1548
> Project: Jackrabbit
>  Issue Type: Bug
>  Components: jackrabbit-ocm
>Reporter: Stephane Landelle
>Assignee: Christophe Lombart
> Fix For: 1.5
>
>   Original Estimate: 0.08h
>  Remaining Estimate: 0.08h
>
> Just a few bugs in the last SVN commit, but since I work with it, i thought 
> useful to mention them :
> 1) org.apache.jackrabbit.ocm.reflection.ReflectionUtils should handle Set --> 
> just add it in defaultImplementation
> 2) in 
> org.apache.jackrabbit.ocm.manager.collectionconverter.ManageableObjectsUtil.getManageableObjects,
>  correct defaultImplementation test :
>   if (defaultImplementation == null)
>   {
>   throw new JcrMappingException("No default 
> implementation for the interface " + manageableObjectsClass);
> Thank you and keep up the good work!
> Sincerely yours,
> Stephane

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Reopened: (JCR-1548) Several bugs in last SVN commit

[Stephane Landelle (JIRA)]

 [ 
https://issues.apache.org/jira/browse/JCR-1548?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Stephane Landelle reopened JCR-1548:



There's still a "throw" missing on line 69 in 
org.apache.jackrabbit.ocm.manager.collectionconverter.ManageableObjectsUtil.getManageableObjects...
 :)

Stéphane

> Several bugs in last SVN commit
> ---
>
> Key: JCR-1548
> URL: https://issues.apache.org/jira/browse/JCR-1548
> Project: Jackrabbit
>  Issue Type: Bug
>  Components: jackrabbit-ocm
>Reporter: Stephane Landelle
>Assignee: Christophe Lombart
> Fix For: 1.5
>
>   Original Estimate: 0.08h
>  Remaining Estimate: 0.08h
>
> Just a few bugs in the last SVN commit, but since I work with it, i thought 
> useful to mention them :
> 1) org.apache.jackrabbit.ocm.reflection.ReflectionUtils should handle Set --> 
> just add it in defaultImplementation
> 2) in 
> org.apache.jackrabbit.ocm.manager.collectionconverter.ManageableObjectsUtil.getManageableObjects,
>  correct defaultImplementation test :
>   if (defaultImplementation == null)
>   {
>   throw new JcrMappingException("No default 
> implementation for the interface " + manageableObjectsClass);
> Thank you and keep up the good work!
> Sincerely yours,
> Stephane

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Created: (JCR-1548) Several bugs in last SVN commit

[Stephane Landelle (JIRA)]

Several bugs in last SVN commit
---

 Key: JCR-1548
 URL: https://issues.apache.org/jira/browse/JCR-1548
 Project: Jackrabbit
  Issue Type: Bug
  Components: security
Reporter: Stephane Landelle
 Fix For: 1.5


Just a few bugs in the last SVN commit, but since I work with it, i thought 
useful to mention them :
1) org.apache.jackrabbit.ocm.reflection.ReflectionUtils should handle Set --> 
just add it in defaultImplementation
2) in 
org.apache.jackrabbit.ocm.manager.collectionconverter.ManageableObjectsUtil.getManageableObjects,
 correct defaultImplementation test :
if (defaultImplementation == null)
{
throw new JcrMappingException("No default 
implementation for the interface " + manageableObjectsClass);

Thank you and keep up the good work!

Sincerely yours,

Stephane

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (JCR-1537) ClassDescriptor.hasIdField() fails if id is declared in upper class

[Stephane Landelle (JIRA)]

 [ 
https://issues.apache.org/jira/browse/JCR-1537?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Stephane Landelle updated JCR-1537:
---

Attachment: jackrabbit-ocm.patch

> ClassDescriptor.hasIdField() fails if id is declared in upper class
> ---
>
> Key: JCR-1537
> URL: https://issues.apache.org/jira/browse/JCR-1537
> Project: Jackrabbit
>  Issue Type: Bug
>  Components: jackrabbit-ocm
>Affects Versions: 1.5
> Environment: Mac OS X, JVM 1.5
>Reporter: Stephane Landelle
> Attachments: jackrabbit-ocm.patch
>
>   Original Estimate: 0.02h
>  Remaining Estimate: 0.02h
>
> org.apache.jackrabbit.ocm.mapper.model.ClassDescriptor.hasIdField() looks up 
> only current class and not the whole hierarchy, so it fails when the id field 
> is declared in a upper class.
> hasIdField should use getIdFieldDescriptor and not access idFieldDescriptor 
> field directly, as follows :
> public boolean hasIdField() {
>   return (this.getIdFieldDescriptor() != null && this
>   .getIdFieldDescriptor().isId());
> }
> Please find patch enclosed.
> Sincerely yours,
> Stéphane Landelle

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Created: (JCR-1537) ClassDescriptor.hasIdField() fails if id is declared in upper class

[Stephane Landelle (JIRA)]

ClassDescriptor.hasIdField() fails if id is declared in upper class
---

 Key: JCR-1537
 URL: https://issues.apache.org/jira/browse/JCR-1537
 Project: Jackrabbit
  Issue Type: Bug
  Components: jackrabbit-ocm
Affects Versions: 1.5
 Environment: Mac OS X, JVM 1.5
Reporter: Stephane Landelle


org.apache.jackrabbit.ocm.mapper.model.ClassDescriptor.hasIdField() looks up 
only current class and not the whole hierarchy, so it fails when the id field 
is declared in a upper class.

hasIdField should use getIdFieldDescriptor and not access idFieldDescriptor 
field directly, as follows :

public boolean hasIdField() {
return (this.getIdFieldDescriptor() != null && this
.getIdFieldDescriptor().isId());
}

Please find patch enclosed.

Sincerely yours,

Stéphane Landelle

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Created: (JCR-1498) ManageableCollectionUtil should support Map and HashMap

[Stephane Landelle (JIRA)]

ManageableCollectionUtil should support Map and HashMap
---

 Key: JCR-1498
 URL: https://issues.apache.org/jira/browse/JCR-1498
 Project: Jackrabbit
  Issue Type: Bug
  Components: jackrabbit-ocm
Affects Versions: 1.5
Reporter: Stephane Landelle


ManageableCollectionUtil doesn't supports Map and HashMap.

just add :

if (collectionClass.equals(Map.class) || collectionClass.equals(HashMap.class)) 
{
return new ManagedHashMap();
}

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Created: (JCR-1470) NPE in BeanReferenceCollectionConverterImpl on update on empty collection

[Stephane Landelle (JIRA)]

NPE in BeanReferenceCollectionConverterImpl on update on empty collection
-

 Key: JCR-1470
 URL: https://issues.apache.org/jira/browse/JCR-1470
 Project: Jackrabbit
  Issue Type: Bug
  Components: observation
Affects Versions: 1.5
 Environment: mac os leopard, java5
Reporter: Stephane Landelle


use case :
in the same transaction :
*) retrieve an object that has a collection of references, yet empty
*) add an element in the collection
*) update the object

consequence :
org.apache.jackrabbit.ocm.exception.ObjectContentManagerException: Cannot 
insert collection field : authors of class com.weka.content.api.model.Folder; 
nested exception is java.lang.NullPointerException: null
java.lang.NullPointerException
at 
org.apache.jackrabbit.ocm.manager.collectionconverter.impl.ManageableArrayList$$EnhancerByCGLIB$$8f15dde4.getSize()
at 
org.apache.jackrabbit.ocm.manager.collectionconverter.impl.BeanReferenceCollectionConverterImpl.addUuidProperties(BeanReferenceCollectionConverterImpl.java:154)
at 
org.apache.jackrabbit.ocm.manager.collectionconverter.impl.BeanReferenceCollectionConverterImpl.doUpdateCollection(BeanReferenceCollectionConverterImpl.java:101)

The failing line is in addUuidProperties :
Value[] values = new Value[collection.getSize()];

It seems the CGlib enhanced collection fails and needs to be initialized before.

For example, in doUpdateCollection, if I code :
// Delete existing values
if (parentNode.hasProperty(jcrName)) {
parentNode.setProperty(jcrName, (Value[]) null);
}

if (collection != null) {
collection.getSize(); <<
}
I get a NPE on collection.getSize();

but if I code :
if (collection != null) {
collection.getSize();
}

// Delete existing values
if (parentNode.hasProperty(jcrName)) {
parentNode.setProperty(jcrName, (Value[]) null);
}
everything runs fine?!




-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Created: (JCR-1446) Local transactions support

[Stephane Landelle (JIRA)]

Local transactions support
--

 Key: JCR-1446
 URL: https://issues.apache.org/jira/browse/JCR-1446
 Project: Jackrabbit
  Issue Type: Improvement
  Components: jackrabbit-jca
Affects Versions: 1.5
Reporter: Stephane Landelle


JCAManagedConnectionFactory doesn't currently support LocalTransaction. 
Wouldn't it be simple to provide a simple implemetation like the following 
(inspired of JR test suite):
package com.weka.jackrabbit.jca;

import javax.jcr.Session;
import javax.resource.ResourceException;
import javax.resource.spi.LocalTransaction;
import javax.transaction.xa.XAException;
import javax.transaction.xa.XAResource;
import javax.transaction.xa.Xid;

import org.apache.jackrabbit.api.XASession;

/**
 * JackRabbit Local transaction (based on the XA Resource returned by
 * JackRabbit).  Inspired from JackRabbit test suite.
 * 
 * Internal [EMAIL PROTECTED] javax.transaction.LocalTransaction} 
implementation.
 * 
 */
public class JackRabbitLocalTransaction implements LocalTransaction {

/**
 * Global transaction id counter. TODO: remove the static attribute
 */
private static byte counter = 0;

/**
 * XASession
 */
private XASession session;

/**
 * XAResource
 */
private final XAResource xares;

/**
 * Xid
 */
private Xid xid;

/**
 * Create a new instance of this class. Takes a session as parameter.
 * 
 * @param session
 *session. If session is not of type [EMAIL PROTECTED] 
XASession}, an
 *IllegalArgumentException is thrown
 */
public JackRabbitLocalTransaction(Session session) {
if (session instanceof XASession) {
this.session = (XASession) session;
xares = this.session.getXAResource();
} else {
throw new IllegalArgumentException("Session not of type 
XASession");
}
}

/**
 * @see javax.transaction.LocalTransaction#begin
 */
public void begin() throws ResourceException {

try {
xid = new XidImpl(counter++);
xares.start(xid, XAResource.TMNOFLAGS);

} catch (XAException e) {
throw new ResourceException("Unable to begin 
transaction: " + "XA_ERR=" + e.errorCode);
}
}

/**
 * @see javax.transaction.LocalTransaction#commit
 */
public void commit() throws ResourceException {

try {
xares.end(xid, XAResource.TMSUCCESS);
xares.prepare(xid);
xares.commit(xid, false);
session.logout();

} catch (XAException e) {

if (e.errorCode >= XAException.XA_RBBASE && e.errorCode 
<= XAException.XA_RBEND) {
throw new ResourceException(e.toString());
}

throw new ResourceException("Unable to commit 
transaction: " + "XA_ERR=" + e.errorCode);
}
}

/**
 * @see javax.transaction.LocalTransaction#rollback
 */
public void rollback() throws ResourceException {

try {
xares.end(xid, XAResource.TMFAIL);
xares.rollback(xid);
session.logout();

} catch (XAException e) {

throw new ResourceException("Unable to rollback 
transaction: " + "XA_ERR=" + e.errorCode);
}
}

/**
 * Internal [EMAIL PROTECTED] Xid} implementation.
 */
class XidImpl implements Xid {

/** Global transaction id */
private final byte[] globalTxId;

/**
 * Create a new instance of this class. Takes a global 
transaction
 * number as parameter
 * 
 * @param globalTxNumber
 *global transaction number
 */
public XidImpl(byte globalTxNumber) {
this.globalTxId = new byte[] { globalTxNumber };
}

/**
 * @see javax.transaction.xa.Xid#getFormatId()
 */
public int getFormatId() {
return 0;
}

/**
 * @see javax.transaction.xa.Xid#getBranchQualifier()
 */
public byte[] getBranchQualifier() {
return new byte[0];
}

/**
 * @see javax.transaction.

[jira] Created: (JCR-1443) Make JCAManagedConnectionFactory non final, so it can be extended

[Stephane Landelle (JIRA)]

Make JCAManagedConnectionFactory non final, so it can be extended
-

 Key: JCR-1443
 URL: https://issues.apache.org/jira/browse/JCR-1443
 Project: Jackrabbit
  Issue Type: Improvement
  Components: jackrabbit-jca
Reporter: Stephane Landelle
Priority: Minor


Hello,

Is there a reason why JCAManagedConnectionFactory is final?
I need to build my own one and I'd rather reuse some code of yours.


-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Created: (JCR-1430) mvn eclipse:eclipse inconsistent

[Stephane Landelle (JIRA)]

mvn eclipse:eclipse inconsistent


 Key: JCR-1430
 URL: https://issues.apache.org/jira/browse/JCR-1430
 Project: Jackrabbit
  Issue Type: Bug
  Components: jackrabbit-core, jackrabbit-spi-commons
Affects Versions: 1.5
 Environment: mac os
europa
javacc-maven-plugin v2.4
Reporter: Stephane Landelle
Priority: Trivial


mvn eclipse:eclipse result is inconsistent, due to deprecated 
avacc-maven-plugin usage.
should use piped "jjtree-javacc" goal.
core :
  
fulltext-jjtree

  
${basedir}/src/main/javacc/fulltext
  
${project.build.directory}/generated-src/main/java
  
${project.build.directory}/generated-src/javacc-timestamp
  
org.apache.jackrabbit.core.query.lucene.fulltext


  jjtree-javacc

  

spi-commons:

sql-jjtree-javacc


${basedir}/src/main/javacc/sql

${project.build.directory}/generated-src/main/java

${project.build.directory}/generated-src/javacc-timestamp

org.apache.jackrabbit.spi.commons.query.sql



jjtree-javacc



xpath-jjtree-javacc


${basedir}/src/main/javacc/xpath

${project.build.directory}/generated-src/main/java

${project.build.directory}/generated-src/javacc-timestamp

org.apache.jackrabbit.spi.commons.query.xpath



jjtree-javacc



-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.