Re: ldap configuration
Hello Miguel,
I'm also working with the JNDIPrincipalStore. I think the problem is the way the file
based stores are implemented. You have set the security and lock store to be a file
based store. Earlier I've tried to separate data of an ExtendedStore by spreading it
over 6 file based stores each using different directories. It didn't work.
The error could lie in AbstractXMLResourceDescriptor.encodeObject() (if you don't use
an old version of Slide):
Element aElementObjectNode = new Element("objectnode");
if (object != null) {
aElementObjectNode.setAttribute("classname", object.getClass().getName());
aElementObjectNode.setAttribute("uri", object.getUri());
if (object instanceof LinkNode) {
aElementObjectNode.setAttribute("linkTo", ((LinkNode) object).getLinkedUri());
}
} else {
// for null locks
aElementObjectNode.setAttribute("classname", "null");
aElementObjectNode.setAttribute("uri", uri.toString());
}
aElementObjectNode.addContent(createBindings("children", "child",
object.enumerateBindings()));
aElementObjectNode.addContent(createBindings("parents", "parent",
object.enumerateParentBindings()));
aElementObjectNode.addContent(createElements("links", "link",
object.enumerateLinks()));
return aElementObjectNode;
First there is distinguished between an object being null or not. After that there is
always tried to access the child bindings of object - even if it's null.
Try replacing your security and lock store by a JDBCStore. For me it works that way.
Stefan
Am Tue, 14 Sep 2004 11:42:17 +0100 schrieb Miguel Figueiredo <[EMAIL PROTECTED]>:
Hello folks,
I've been trying to configure slide to use an ldap server for authentication
purposes.
I've been successful at that, but with a cost of an annoying null pointer
exception when tomcat is starting up:
org.apache.slide.common.ServiceAccessException: Service
TxXMLFileDescriptorsStore at users/store/metadata working on us
ers/work/metadata access error : java.lang.NullPointerException
at
org.apache.slide.store.txfile.AbstractXMLResourceDescriptor.encodeObje
ct(AbstractXMLResourceDescriptor.java:662)
My current setup is the tomcat 5.0.19 / slide 2.1b1 bundle with the attached
domain.xml file.
I suspect that it works well because JNDIPrincipalStore is read-only, so,
maybe it wouldn't need it's corresponding working directory, to witch this
exception relates to. Or perhaps I still didn't found any problem witch
shall occur more soon than later...
Does slide use the 'users working directory' in any of its use-cases? Am I
doing something wrong in the Domain.xml file?
Thanks in advance,
Miguel Figueiredo
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: ldap configuration
Thank you Stefan!
I'll configure a JDBC store has the security & lock store (anyway, I wanted
to play with JDBC in my next experience set ;))
Best regards,
Miguel
__
Hello Miguel,
I'm also working with the JNDIPrincipalStore. I think the problem is the way
the file based stores are implemented. You have set the security and lock
store to be a file based store. Earlier I've tried to separate data of an
ExtendedStore by spreading it over 6 file based stores each using different
directories. It didn't work.
The error could lie in AbstractXMLResourceDescriptor.encodeObject() (if you
don't use an old version of Slide):
Element aElementObjectNode = new Element("objectnode");
if (object != null) {
aElementObjectNode.setAttribute("classname",
object.getClass().getName());
aElementObjectNode.setAttribute("uri", object.getUri());
if (object instanceof LinkNode) {
aElementObjectNode.setAttribute("linkTo", ((LinkNode)
object).getLinkedUri());
}
} else {
// for null locks
aElementObjectNode.setAttribute("classname", "null");
aElementObjectNode.setAttribute("uri", uri.toString());
}
aElementObjectNode.addContent(createBindings("children", "child",
object.enumerateBindings()));
aElementObjectNode.addContent(createBindings("parents", "parent",
object.enumerateParentBindings()));
aElementObjectNode.addContent(createElements("links", "link",
object.enumerateLinks()));
return aElementObjectNode;
First there is distinguished between an object being null or not. After that
there is always tried to access the child bindings of object - even if it's
null.
Try replacing your security and lock store by a JDBCStore. For me it works
that way.
Stefan
Am Tue, 14 Sep 2004 11:42:17 +0100 schrieb Miguel Figueiredo
<[EMAIL PROTECTED]>:
>
> Hello folks,
>
> I've been trying to configure slide to use an ldap server for
authentication
> purposes.
> I've been successful at that, but with a cost of an annoying null pointer
> exception when tomcat is starting up:
>
> org.apache.slide.common.ServiceAccessException: Service
> TxXMLFileDescriptorsStore at users/store/metadata working on us
> ers/work/metadata access error : java.lang.NullPointerException
> at
> org.apache.slide.store.txfile.AbstractXMLResourceDescriptor.encodeObje
> ct(AbstractXMLResourceDescriptor.java:662)
>
> My current setup is the tomcat 5.0.19 / slide 2.1b1 bundle with the
attached
> domain.xml file.
>
> I suspect that it works well because JNDIPrincipalStore is read-only, so,
> maybe it wouldn't need it's corresponding working directory, to witch this
> exception relates to. Or perhaps I still didn't found any problem witch
> shall occur more soon than later...
>
> Does slide use the 'users working directory' in any of its use-cases? Am I
> doing something wrong in the Domain.xml file?
>
>
> Thanks in advance,
> Miguel Figueiredo
>
>
>
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: ldap configuration
Hello Stefan,
Using the JBDC store did not solve the problem. Instead of a null pointer
exception, I get the following errors:
org.apache.slide.store.impl.rdbms.StandardRDBMSAdapter - ERROR - Failed to
insert permission (/roles,self,all)
org.apache.slide.store.impl.rdbms.StandardRDBMSAdapter - ERROR - Failed to
insert permission (/roles,/roles/projector,all)
org.apache.slide.store.impl.rdbms.StandardRDBMSAdapter - ERROR - Failed to
insert permission (/roles,unauthenticated,all)
I've re-examined the null pointer exception stack of the txfile store, and
found out that the error also occurs when setting some kind of permissions.
Removing the tag from the domain.xml prevents the error. I've
concluded that the error occurs only on the security and lock stores
configured inside the JNDIPrincipalStore, for roles and users alike (I get a
similar error but for the /users path), and when slide is trying to execute
the following directives of the domain.xml file:
...
Anyway, the good news is that, when examining the ACL permissions with a
IExplorer (with directory-browsing-hide-acl = false), those same paths are
correctly configured with the presented domain.xml directives... weird...
Everything else seems to be working well.
Best regards,
Miguel
_
Thank you Stefan!
I'll configure a JDBC store has the security & lock store (anyway, I wanted
to play with JDBC in my next experience set ;))
Best regards,
Miguel
__
Hello Miguel,
I'm also working with the JNDIPrincipalStore. I think the problem is the way
the file based stores are implemented. You have set the security and lock
store to be a file based store. Earlier I've tried to separate data of an
ExtendedStore by spreading it over 6 file based stores each using different
directories. It didn't work.
The error could lie in AbstractXMLResourceDescriptor.encodeObject() (if you
don't use an old version of Slide):
Element aElementObjectNode = new Element("objectnode");
if (object != null) {
aElementObjectNode.setAttribute("classname",
object.getClass().getName());
aElementObjectNode.setAttribute("uri", object.getUri());
if (object instanceof LinkNode) {
aElementObjectNode.setAttribute("linkTo", ((LinkNode)
object).getLinkedUri());
}
} else {
// for null locks
aElementObjectNode.setAttribute("classname", "null");
aElementObjectNode.setAttribute("uri", uri.toString());
}
aElementObjectNode.addContent(createBindings("children", "child",
object.enumerateBindings()));
aElementObjectNode.addContent(createBindings("parents", "parent",
object.enumerateParentBindings()));
aElementObjectNode.addContent(createElements("links", "link",
object.enumerateLinks()));
return aElementObjectNode;
First there is distinguished between an object being null or not. After that
there is always tried to access the child bindings of object - even if it's
null.
Try replacing your security and lock store by a JDBCStore. For me it works
that way.
Stefan
Am Tue, 14 Sep 2004 11:42:17 +0100 schrieb Miguel Figueiredo
<[EMAIL PROTECTED]>:
>
> Hello folks,
>
> I've been trying to configure slide to use an ldap server for
authentication
> purposes.
> I've been successful at that, but with a cost of an annoying null pointer
> exception when tomcat is starting up:
>
> org.apache.slide.common.ServiceAccessException: Service
> TxXMLFileDescriptorsStore at users/store/metadata working on us
> ers/work/metadata access error : java.lang.NullPointerException
> at
> org.apache.slide.store.txfile.AbstractXMLResourceDescriptor.encodeObje
> ct(AbstractXMLResourceDescriptor.java:662)
>
> My current setup is the tomcat 5.0.19 / slide 2.1b1 bundle with the
attached
> domain.xml file.
>
> I suspect that it works well because JNDIPrincipalStore is read-only, so,
> maybe it wouldn't need it's corresponding working directory, to witch this
> exception relates to. Or perhaps I still didn't found any problem witch
> shall occur more soon than later...
>
> Does slide use the 'users working directory' in any of its use-cases? Am I
> doing something wrong in the Domain.xml file?
>
>
> Thanks in advance,
> Miguel Figueiredo
>
>
>
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: ldap configuration
Hello Stefan,
Using the JBDC store did not solve the problem. Instead of a null pointer
exception, I get the following errors:
org.apache.slide.store.impl.rdbms.StandardRDBMSAdapter - ERROR - Failed to
insert permission (/roles,self,all)
org.apache.slide.store.impl.rdbms.StandardRDBMSAdapter - ERROR - Failed to
insert permission (/roles,/roles/projector,all)
org.apache.slide.store.impl.rdbms.StandardRDBMSAdapter - ERROR - Failed to
insert permission (/roles,unauthenticated,all)
I've re-examined the null pointer exception stack of the txfile store, and
found out that the error also occurs when setting some kind of permissions.
Removing the tag from the domain.xml prevents the error. I've
concluded that the error occurs only on the security and lock stores
configured inside the JNDIPrincipalStore, for roles and users alike (I get a
similar error but for the /users path), and when slide is trying to execute
the following directives of the domain.xml file, inside the element:
...
Anyway, the good news is that, when examining the ACL permissions with a
IExplorer (with directory-browsing-hide-acl = false), those same paths are
correctly configured with the presented domain.xml directives... weird...
Everything else seems to be working well.
Best regards,
Miguel
_
Thank you Stefan!
I'll configure a JDBC store has the security & lock store (anyway, I wanted
to play with JDBC in my next experience set ;))
Best regards,
Miguel
__
Hello Miguel,
I'm also working with the JNDIPrincipalStore. I think the problem is the way
the file based stores are implemented. You have set the security and lock
store to be a file based store. Earlier I've tried to separate data of an
ExtendedStore by spreading it over 6 file based stores each using different
directories. It didn't work.
The error could lie in AbstractXMLResourceDescriptor.encodeObject() (if you
don't use an old version of Slide):
Element aElementObjectNode = new Element("objectnode");
if (object != null) {
aElementObjectNode.setAttribute("classname",
object.getClass().getName());
aElementObjectNode.setAttribute("uri", object.getUri());
if (object instanceof LinkNode) {
aElementObjectNode.setAttribute("linkTo", ((LinkNode)
object).getLinkedUri());
}
} else {
// for null locks
aElementObjectNode.setAttribute("classname", "null");
aElementObjectNode.setAttribute("uri", uri.toString());
}
aElementObjectNode.addContent(createBindings("children", "child",
object.enumerateBindings()));
aElementObjectNode.addContent(createBindings("parents", "parent",
object.enumerateParentBindings()));
aElementObjectNode.addContent(createElements("links", "link",
object.enumerateLinks()));
return aElementObjectNode;
First there is distinguished between an object being null or not. After that
there is always tried to access the child bindings of object - even if it's
null.
Try replacing your security and lock store by a JDBCStore. For me it works
that way.
Stefan
Am Tue, 14 Sep 2004 11:42:17 +0100 schrieb Miguel Figueiredo
<[EMAIL PROTECTED]>:
>
> Hello folks,
>
> I've been trying to configure slide to use an ldap server for
authentication
> purposes.
> I've been successful at that, but with a cost of an annoying null pointer
> exception when tomcat is starting up:
>
> org.apache.slide.common.ServiceAccessException: Service
> TxXMLFileDescriptorsStore at users/store/metadata working on us
> ers/work/metadata access error : java.lang.NullPointerException
> at
> org.apache.slide.store.txfile.AbstractXMLResourceDescriptor.encodeObje
> ct(AbstractXMLResourceDescriptor.java:662)
>
> My current setup is the tomcat 5.0.19 / slide 2.1b1 bundle with the
attached
> domain.xml file.
>
> I suspect that it works well because JNDIPrincipalStore is read-only, so,
> maybe it wouldn't need it's corresponding working directory, to witch this
> exception relates to. Or perhaps I still didn't found any problem witch
> shall occur more soon than later...
>
> Does slide use the 'users working directory' in any of its use-cases? Am I
> doing something wrong in the Domain.xml file?
>
>
> Thanks in advance,
> Miguel Figueiredo
>
>
>
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: ldap configuration
Sorry for the spam, my mail client was unsynchronized.
-Original Message-
From: Miguel Figueiredo [mailto:[EMAIL PROTECTED]
Sent: quarta-feira, 15 de Setembro de 2004 17:32
To: 'Slide Users Mailing List'
Subject: RE: ldap configuration
Hello Stefan,
Using the JBDC store did not solve the problem. Instead of a null pointer
exception, I get the following errors:
org.apache.slide.store.impl.rdbms.StandardRDBMSAdapter - ERROR - Failed to
insert permission (/roles,self,all)
org.apache.slide.store.impl.rdbms.StandardRDBMSAdapter - ERROR - Failed to
insert permission (/roles,/roles/projector,all)
org.apache.slide.store.impl.rdbms.StandardRDBMSAdapter - ERROR - Failed to
insert permission (/roles,unauthenticated,all)
I've re-examined the null pointer exception stack of the txfile store, and
found out that the error also occurs when setting some kind of permissions.
Removing the tag from the domain.xml prevents the error. I've
concluded that the error occurs only on the security and lock stores
configured inside the JNDIPrincipalStore, for roles and users alike (I get a
similar error but for the /users path), and when slide is trying to execute
the following directives of the domain.xml file, inside the element:
...
Anyway, the good news is that, when examining the ACL permissions with a
IExplorer (with directory-browsing-hide-acl = false), those same paths are
correctly configured with the presented domain.xml directives... weird...
Everything else seems to be working well.
Best regards,
Miguel
_
Thank you Stefan!
I'll configure a JDBC store has the security & lock store (anyway, I wanted
to play with JDBC in my next experience set ;))
Best regards,
Miguel
__
Hello Miguel,
I'm also working with the JNDIPrincipalStore. I think the problem is the way
the file based stores are implemented. You have set the security and lock
store to be a file based store. Earlier I've tried to separate data of an
ExtendedStore by spreading it over 6 file based stores each using different
directories. It didn't work.
The error could lie in AbstractXMLResourceDescriptor.encodeObject() (if you
don't use an old version of Slide):
Element aElementObjectNode = new Element("objectnode");
if (object != null) {
aElementObjectNode.setAttribute("classname",
object.getClass().getName());
aElementObjectNode.setAttribute("uri", object.getUri());
if (object instanceof LinkNode) {
aElementObjectNode.setAttribute("linkTo", ((LinkNode)
object).getLinkedUri());
}
} else {
// for null locks
aElementObjectNode.setAttribute("classname", "null");
aElementObjectNode.setAttribute("uri", uri.toString());
}
aElementObjectNode.addContent(createBindings("children", "child",
object.enumerateBindings()));
aElementObjectNode.addContent(createBindings("parents", "parent",
object.enumerateParentBindings()));
aElementObjectNode.addContent(createElements("links", "link",
object.enumerateLinks()));
return aElementObjectNode;
First there is distinguished between an object being null or not. After that
there is always tried to access the child bindings of object - even if it's
null.
Try replacing your security and lock store by a JDBCStore. For me it works
that way.
Stefan
Am Tue, 14 Sep 2004 11:42:17 +0100 schrieb Miguel Figueiredo
<[EMAIL PROTECTED]>:
>
> Hello folks,
>
> I've been trying to configure slide to use an ldap server for
authentication
> purposes.
> I've been successful at that, but with a cost of an annoying null pointer
> exception when tomcat is starting up:
>
> org.apache.slide.common.ServiceAccessException: Service
> TxXMLFileDescriptorsStore at users/store/metadata working on us
> ers/work/metadata access error : java.lang.NullPointerException
> at
> org.apache.slide.store.txfile.AbstractXMLResourceDescriptor.encodeObje
> ct(AbstractXMLResourceDescriptor.java:662)
>
> My current setup is the tomcat 5.0.19 / slide 2.1b1 bundle with the
attached
> domain.xml file.
>
> I suspect that it works well because JNDIPrincipalStore is read-only, so,
> maybe it wouldn't need it's corresponding working directory, to witch this
> exception relates to. Or perhaps I still didn't found any problem witch
> shall occur more soon than later...
>
> Does slide use the 'users working directory' in any of its use-cases? Am I
> doing something wrong in the Domain.xml file?
>
>
> Thanks in advance,
> Miguel Figueiredo
>
>
>
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTE
Re: ldap configuration
Miguel, This problem cropped up in 2.1b1. I'm not sure what causes it (something changed with the TxFile stores) and I was too lazy to track it down :). If you grab the latest code from CVS the JNDIPrincipalStore now implements SecurityStore and LockStore so that you don't have configure a separate store. The implementations are empty, so you can't actually set ACLs or LOCK resources inside the Store. With your current version you might try using the Memory stores for security and locks. That would be a quicker fix and should work fine. -James Miguel Figueiredo wrote: Hello folks, I've been trying to configure slide to use an ldap server for authentication purposes. I've been successful at that, but with a cost of an annoying null pointer exception when tomcat is starting up: org.apache.slide.common.ServiceAccessException: Service TxXMLFileDescriptorsStore at users/store/metadata working on us ers/work/metadata access error : java.lang.NullPointerException at org.apache.slide.store.txfile.AbstractXMLResourceDescriptor.encodeObje ct(AbstractXMLResourceDescriptor.java:662) My current setup is the tomcat 5.0.19 / slide 2.1b1 bundle with the attached domain.xml file. I suspect that it works well because JNDIPrincipalStore is read-only, so, maybe it wouldn't need it's corresponding working directory, to witch this exception relates to. Or perhaps I still didn't found any problem witch shall occur more soon than later... Does slide use the 'users working directory' in any of its use-cases? Am I doing something wrong in the Domain.xml file? Thanks in advance, Miguel Figueiredo 120 main/store/metadata main/work/metadata true 120 main/store/sequence main/store/content main/work/content true 120 ou=people,dc=dominio,dc=pt uid (objectClass=inetOrgPerson) ONELEVEL_SCOPE postalCode,initials,givenName,uid,mail,fullName,telephoneNumber,title,facsimileTelephoneNumber,groupMembership,l,sn,cn ldap://miguel-desktop:389 com.sun.jndi.ldap.LdapCtxFactory cn=Manager,dc=dominio,dc=pt simple segredo 15 800 15000 users/store/metadata users/work/metadata ou=groups,dc=dominio,dc=pt cn uniqueMember (objectClass=groupOfUniqueNames) ONELEVEL_SCOPE cn ldap://miguel-desktop:389 com.sun.jndi.ldap.LdapCtxFactory cn=Manager,dc=dominio,dc=pt simple segredo 15 800 15000 roles/store/metadata roles/work/metadata true /actions/read /actions/write /actions/write /actions/write-acl /actions/write-acl /actions/read-acl /actions/read-current-user-privilege-set /actions/write /actions/unlock /actions/read /actions/read /actions/write-properties /actions/write-properties /actions/write-properties /actions/read /actions/write-content /actions/write-content /actions/write-content /actions/bind /actions/unbind /users /roles /actions /files true true path 0 full true http://jakarta.apache.org/slide/"; name="password">root http://jakarta.apache.org/slide/"; name="password">john
RE: ldap configuration
Thanx James, I'll try that :) Regards, Miguel _ Miguel, This problem cropped up in 2.1b1. I'm not sure what causes it (something changed with the TxFile stores) and I was too lazy to track it down :). If you grab the latest code from CVS the JNDIPrincipalStore now implements SecurityStore and LockStore so that you don't have configure a separate store. The implementations are empty, so you can't actually set ACLs or LOCK resources inside the Store. With your current version you might try using the Memory stores for security and locks. That would be a quicker fix and should work fine. -James Miguel Figueiredo wrote: > Hello folks, > > I've been trying to configure slide to use an ldap server for authentication > purposes. > I've been successful at that, but with a cost of an annoying null pointer > exception when tomcat is starting up: > > org.apache.slide.common.ServiceAccessException: Service > TxXMLFileDescriptorsStore at users/store/metadata working on us > ers/work/metadata access error : java.lang.NullPointerException > at > org.apache.slide.store.txfile.AbstractXMLResourceDescriptor.encodeObje > ct(AbstractXMLResourceDescriptor.java:662) > > My current setup is the tomcat 5.0.19 / slide 2.1b1 bundle with the attached > domain.xml file. > > I suspect that it works well because JNDIPrincipalStore is read-only, so, > maybe it wouldn't need it's corresponding working directory, to witch this > exception relates to. Or perhaps I still didn't found any problem witch > shall occur more soon than later... > > Does slide use the 'users working directory' in any of its use-cases? Am I > doing something wrong in the Domain.xml file? > > > Thanks in advance, > Miguel Figueiredo > > > > > > > > > > > > > 120 > > main/store/metadata > main/work/metadata > true > 120 > > > main/store/sequence > > > > > > > > > > > > > > > main/store/content > main/work/content > true > 120 > > > > > > > > > > ou=people,dc=dominio,dc=pt > uid > (objectClass=inetOrgPerson) > ONELEVEL_SCOPE > postalCode,initials,givenName,uid,mail,fullNam e,telephoneNumber,title,facsimileTelephoneNumber,groupMembership,l,sn,cn > ldap://miguel-desktop:389 > com.sun.jndi.ldap.LdapCtxFactory > cn=Manager,dc=dominio,dc=pt > simple > segredo > > > 15 > 800 > 15000 > > > > > > > > users/store/metadata > users/work/metadata > > > > > > > > > > > > > > > > > > > ou=groups,dc=dominio,dc=pt > cn > uniqueMember > (objectClass=groupOfUniqueNames) > ONELEVEL_SCOPE > cn > ldap://miguel-desktop:389 > com.sun.jndi.ldap.LdapCtxFactory > cn=Manager,dc=dominio,dc=pt > simple > segredo > > > > 15 >
Re: ldap configuration
Hi James! Could you describe how I can reproduce the problem? I would take care of it then... Oliver This problem cropped up in 2.1b1. I'm not sure what causes it (something changed with the TxFile stores) and I was too lazy to track it down :). - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: ldap configuration
Oliver, I don't know if it's really a problem or not. With 2.1M1 I configured JNDIPrincipalStore to use a TxXMLFileDescriptorStore for the SecurityStore and LockStore implementations. When I upgraded to 2.1b1 I started getting errors with this configuration. I think it was the same error that Miguel reported. For reproducing I suppose you could try using the memory stores for everything but security and locks. If you can't reproduce it that way than the problem is probably obscure enough not worry about. -James Oliver Zeigermann wrote: Hi James! Could you describe how I can reproduce the problem? I would take care of it then... Oliver This problem cropped up in 2.1b1. I'm not sure what causes it (something changed with the TxFile stores) and I was too lazy to track it down :). - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: ldap configuration
Hi James! I see. I will try it ASAP. Oliver James Mason wrote: Oliver, I don't know if it's really a problem or not. With 2.1M1 I configured JNDIPrincipalStore to use a TxXMLFileDescriptorStore for the SecurityStore and LockStore implementations. When I upgraded to 2.1b1 I started getting errors with this configuration. I think it was the same error that Miguel reported. For reproducing I suppose you could try using the memory stores for everything but security and locks. If you can't reproduce it that way than the problem is probably obscure enough not worry about. -James Oliver Zeigermann wrote: Hi James! Could you describe how I can reproduce the problem? I would take care of it then... Oliver This problem cropped up in 2.1b1. I'm not sure what causes it (something changed with the TxFile stores) and I was too lazy to track it down :). - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: ldap configuration
Hi James, there really was a pretty obvious bug in AbstractXMLResourceDescriptor. It should have shown up everytime the TxXMLFileDescriptorStore tried to create a new descriptor without the real object stored into it and later trying to re-read it. Nothing has changed for ages in AbstractXMLResourceDescriptor so I am wondering why this error did not show up earlier. Anyway, it should be fixed now both in the HEAD as well as the release branch. Can anyone check, please? Thanks, Oliver James Mason wrote: Oliver, I don't know if it's really a problem or not. With 2.1M1 I configured JNDIPrincipalStore to use a TxXMLFileDescriptorStore for the SecurityStore and LockStore implementations. When I upgraded to 2.1b1 I started getting errors with this configuration. I think it was the same error that Miguel reported. For reproducing I suppose you could try using the memory stores for everything but security and locks. If you can't reproduce it that way than the problem is probably obscure enough not worry about. -James Oliver Zeigermann wrote: Hi James! Could you describe how I can reproduce the problem? I would take care of it then... Oliver This problem cropped up in 2.1b1. I'm not sure what causes it (something changed with the TxFile stores) and I was too lazy to track it down :). - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: ldap configuration
Hello Oliver, James, I can test it for you... I'll be back with a 'report' in a few minutes. BRB, Miguel -Original Message- From: Oliver Zeigermann [mailto:[EMAIL PROTECTED] Sent: quarta-feira, 22 de Setembro de 2004 15:16 To: Slide Users Mailing List Subject: Re: ldap configuration Hi James, there really was a pretty obvious bug in AbstractXMLResourceDescriptor. It should have shown up everytime the TxXMLFileDescriptorStore tried to create a new descriptor without the real object stored into it and later trying to re-read it. Nothing has changed for ages in AbstractXMLResourceDescriptor so I am wondering why this error did not show up earlier. Anyway, it should be fixed now both in the HEAD as well as the release branch. Can anyone check, please? Thanks, Oliver James Mason wrote: > Oliver, > > I don't know if it's really a problem or not. With 2.1M1 I configured > JNDIPrincipalStore to use a TxXMLFileDescriptorStore for the > SecurityStore and LockStore implementations. When I upgraded to 2.1b1 I > started getting errors with this configuration. I think it was the same > error that Miguel reported. > > For reproducing I suppose you could try using the memory stores for > everything but security and locks. If you can't reproduce it that way > than the problem is probably obscure enough not worry about. > > -James > > Oliver Zeigermann wrote: > >> Hi James! >> >> Could you describe how I can reproduce the problem? I would take care >> of it then... >> >> Oliver >> >>> This problem cropped up in 2.1b1. I'm not sure what causes it >>> (something changed with the TxFile stores) and I was too lazy to >>> track it down :). >> >> >> >> >> - >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] >> >> >> > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: ldap configuration
at org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:287) at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:425) 22 Sep 2004 18:22:06 - org.apache.slide.common.Namespace - INFO - Namespace base configuration was already done before 22 Sep 2004 18:22:06 - org.apache.slide.common.Namespace - INFO - Loading namespace slide configuration 22 Sep 2004 18:22:07 - org.apache.slide.common.Domain - INFO - Namespace configuration complete 22/Set/2004 18:22:07 org.apache.catalina.core.StandardHostDeployer install INFO: Installing web application at context path /jsp-examples from URL file:E:\servers\jakarta-tomcat-5.0.28\webapps\jsp-examples 22/Set/2004 18:22:07 org.apache.catalina.core.StandardHostDeployer install INFO: Installing web application at context path from URL file:E:\servers\jakarta-tomcat-5.0.28\webapps\ROOT 22/Set/2004 18:22:07 org.apache.catalina.core.StandardHostDeployer install INFO: Installing web application at context path /servlets-examples from URL file:E:\servers\jakarta-tomcat-5.0.28\webapps\servlets-examples 22/Set/2004 18:22:07 org.apache.catalina.core.StandardHostDeployer install INFO: Installing web application at context path /tomcat-docs from URL file:E:\servers\jakarta-tomcat-5.0.28\webapps\tomcat-docs 22/Set/2004 18:22:07 org.apache.catalina.core.StandardHostDeployer install INFO: Installing web application at context path /webdav from URL file:E:\servers\jakarta-tomcat-5.0.28\webapps\webdav 22/Set/2004 18:22:07 org.apache.coyote.http11.Http11Protocol start INFO: Starting Coyote HTTP/1.1 on http-8080 22/Set/2004 18:22:08 org.apache.jk.common.ChannelSocket init INFO: JK2: ajp13 listening on /0.0.0.0:8009 22/Set/2004 18:22:08 org.apache.jk.server.JkMain start INFO: Jk running ID=0 time=0/47 config=E:\servers\jakarta-tomcat-5.0.28\conf\jk2.properties 22/Set/2004 18:22:08 org.apache.catalina.startup.Catalina start INFO: Server startup in 7750 ms Also, slide is NOT working!... Miguel _ Hello Oliver, James, I can test it for you... I'll be back with a 'report' in a few minutes. BRB, Miguel -Original Message- From: Oliver Zeigermann [mailto:[EMAIL PROTECTED] Sent: quarta-feira, 22 de Setembro de 2004 15:16 To: Slide Users Mailing List Subject: Re: ldap configuration Hi James, there really was a pretty obvious bug in AbstractXMLResourceDescriptor. It should have shown up everytime the TxXMLFileDescriptorStore tried to create a new descriptor without the real object stored into it and later trying to re-read it. Nothing has changed for ages in AbstractXMLResourceDescriptor so I am wondering why this error did not show up earlier. Anyway, it should be fixed now both in the HEAD as well as the release branch. Can anyone check, please? Thanks, Oliver James Mason wrote: > Oliver, > > I don't know if it's really a problem or not. With 2.1M1 I configured > JNDIPrincipalStore to use a TxXMLFileDescriptorStore for the > SecurityStore and LockStore implementations. When I upgraded to 2.1b1 I > started getting errors with this configuration. I think it was the same > error that Miguel reported. > > For reproducing I suppose you could try using the memory stores for > everything but security and locks. If you can't reproduce it that way > than the problem is probably obscure enough not worry about. > > -James > > Oliver Zeigermann wrote: > >> Hi James! >> >> Could you describe how I can reproduce the problem? I would take care >> of it then... >> >> Oliver >> >>> This problem cropped up in 2.1b1. I'm not sure what causes it >>> (something changed with the TxFile stores) and I was too lazy to >>> track it down :). >> >> >> >> >> - >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] >> >> >> > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] store/metadata work/metadata store/con
Re: ldap configuration
t.Method.invoke(Method.java:324) at org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:287) at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:425) 22 Sep 2004 18:22:06 - org.apache.slide.common.Namespace - INFO - Namespace base configuration was already done before 22 Sep 2004 18:22:06 - org.apache.slide.common.Namespace - INFO - Loading namespace slide configuration 22 Sep 2004 18:22:07 - org.apache.slide.common.Domain - INFO - Namespace configuration complete 22/Set/2004 18:22:07 org.apache.catalina.core.StandardHostDeployer install INFO: Installing web application at context path /jsp-examples from URL file:E:\servers\jakarta-tomcat-5.0.28\webapps\jsp-examples 22/Set/2004 18:22:07 org.apache.catalina.core.StandardHostDeployer install INFO: Installing web application at context path from URL file:E:\servers\jakarta-tomcat-5.0.28\webapps\ROOT 22/Set/2004 18:22:07 org.apache.catalina.core.StandardHostDeployer install INFO: Installing web application at context path /servlets-examples from URL file:E:\servers\jakarta-tomcat-5.0.28\webapps\servlets-examples 22/Set/2004 18:22:07 org.apache.catalina.core.StandardHostDeployer install INFO: Installing web application at context path /tomcat-docs from URL file:E:\servers\jakarta-tomcat-5.0.28\webapps\tomcat-docs 22/Set/2004 18:22:07 org.apache.catalina.core.StandardHostDeployer install INFO: Installing web application at context path /webdav from URL file:E:\servers\jakarta-tomcat-5.0.28\webapps\webdav 22/Set/2004 18:22:07 org.apache.coyote.http11.Http11Protocol start INFO: Starting Coyote HTTP/1.1 on http-8080 22/Set/2004 18:22:08 org.apache.jk.common.ChannelSocket init INFO: JK2: ajp13 listening on /0.0.0.0:8009 22/Set/2004 18:22:08 org.apache.jk.server.JkMain start INFO: Jk running ID=0 time=0/47 config=E:\servers\jakarta-tomcat-5.0.28\conf\jk2.properties 22/Set/2004 18:22:08 org.apache.catalina.startup.Catalina start INFO: Server startup in 7750 ms Also, slide is NOT working!... Miguel _ Hello Oliver, James, I can test it for you... I'll be back with a 'report' in a few minutes. BRB, Miguel -Original Message- From: Oliver Zeigermann [mailto:[EMAIL PROTECTED] Sent: quarta-feira, 22 de Setembro de 2004 15:16 To: Slide Users Mailing List Subject: Re: ldap configuration Hi James, there really was a pretty obvious bug in AbstractXMLResourceDescriptor. It should have shown up everytime the TxXMLFileDescriptorStore tried to create a new descriptor without the real object stored into it and later trying to re-read it. Nothing has changed for ages in AbstractXMLResourceDescriptor so I am wondering why this error did not show up earlier. Anyway, it should be fixed now both in the HEAD as well as the release branch. Can anyone check, please? Thanks, Oliver James Mason wrote: Oliver, I don't know if it's really a problem or not. With 2.1M1 I configured JNDIPrincipalStore to use a TxXMLFileDescriptorStore for the SecurityStore and LockStore implementations. When I upgraded to 2.1b1 I started getting errors with this configuration. I think it was the same error that Miguel reported. For reproducing I suppose you could try using the memory stores for everything but security and locks. If you can't reproduce it that way than the problem is probably obscure enough not worry about. -James Oliver Zeigermann wrote: Hi James! Could you describe how I can reproduce the problem? I would take care of it then... Oliver This problem cropped up in 2.1b1. I'm not sure what causes it (something changed with the TxFile stores) and I was too lazy to track it down :). - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] store/metadata work/metadata
Re: ldap configuration
313) at org.apache.catalina.startup.Catalina.start(Catalina.java:556) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39 ) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl .java:25) at java.lang.reflect.Method.invoke(Method.java:324) at org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:287) at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:425) 22 Sep 2004 18:22:06 - org.apache.slide.common.Namespace - INFO - Namespace base configuration was already done before 22 Sep 2004 18:22:06 - org.apache.slide.common.Namespace - INFO - Loading namespace slide configuration 22 Sep 2004 18:22:07 - org.apache.slide.common.Domain - INFO - Namespace configuration complete 22/Set/2004 18:22:07 org.apache.catalina.core.StandardHostDeployer install INFO: Installing web application at context path /jsp-examples from URL file:E:\servers\jakarta-tomcat-5.0.28\webapps\jsp-examples 22/Set/2004 18:22:07 org.apache.catalina.core.StandardHostDeployer install INFO: Installing web application at context path from URL file:E:\servers\jakarta-tomcat-5.0.28\webapps\ROOT 22/Set/2004 18:22:07 org.apache.catalina.core.StandardHostDeployer install INFO: Installing web application at context path /servlets-examples from URL file:E:\servers\jakarta-tomcat-5.0.28\webapps\servlets-examples 22/Set/2004 18:22:07 org.apache.catalina.core.StandardHostDeployer install INFO: Installing web application at context path /tomcat-docs from URL file:E:\servers\jakarta-tomcat-5.0.28\webapps\tomcat-docs 22/Set/2004 18:22:07 org.apache.catalina.core.StandardHostDeployer install INFO: Installing web application at context path /webdav from URL file:E:\servers\jakarta-tomcat-5.0.28\webapps\webdav 22/Set/2004 18:22:07 org.apache.coyote.http11.Http11Protocol start INFO: Starting Coyote HTTP/1.1 on http-8080 22/Set/2004 18:22:08 org.apache.jk.common.ChannelSocket init INFO: JK2: ajp13 listening on /0.0.0.0:8009 22/Set/2004 18:22:08 org.apache.jk.server.JkMain start INFO: Jk running ID=0 time=0/47 config=E:\servers\jakarta-tomcat-5.0.28\conf\jk2.properties 22/Set/2004 18:22:08 org.apache.catalina.startup.Catalina start INFO: Server startup in 7750 ms Also, slide is NOT working!... Miguel _ Hello Oliver, James, I can test it for you... I'll be back with a 'report' in a few minutes. BRB, Miguel -Original Message- From: Oliver Zeigermann [mailto:[EMAIL PROTECTED] Sent: quarta-feira, 22 de Setembro de 2004 15:16 To: Slide Users Mailing List Subject: Re: ldap configuration Hi James, there really was a pretty obvious bug in AbstractXMLResourceDescriptor. It should have shown up everytime the TxXMLFileDescriptorStore tried to create a new descriptor without the real object stored into it and later trying to re-read it. Nothing has changed for ages in AbstractXMLResourceDescriptor so I am wondering why this error did not show up earlier. Anyway, it should be fixed now both in the HEAD as well as the release branch. Can anyone check, please? Thanks, Oliver James Mason wrote: Oliver, I don't know if it's really a problem or not. With 2.1M1 I configured JNDIPrincipalStore to use a TxXMLFileDescriptorStore for the SecurityStore and LockStore implementations. When I upgraded to 2.1b1 I started getting errors with this configuration. I think it was the same error that Miguel reported. For reproducing I suppose you could try using the memory stores for everything but security and locks. If you can't reproduce it that way than the problem is probably obscure enough not worry about. -James Oliver Zeigermann wrote: Hi James! Could you describe how I can reproduce the problem? I would take care of it then... Oliver This problem cropped up in 2.1b1. I'm not sure what causes it (something changed with the TxFile stores) and I was too lazy to track it down :). - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: ldap configuration
Oliver Zeigermann wrote: Miguel, I have tried deleting the old meta-data... Sorry, getting a little bit tired, read "Miguel, have you tried deleting the old meta-data..." Oliver - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: ldap configuration
Hello Oliver, sorry for taking so long, had wife and kids waiting :) Well, if I remove the old metadata and start tomcat all goes well. The problem occurs if I restart tomcat: that's when that error occurs. I'm using the default Domain.xml configuration with the TxXMLFileDescriptorsStore for nodestore and TxFileContentStore for content. Miguel Oliver Zeigermann wrote: > Miguel, I have tried deleting the old meta-data... Sorry, getting a little bit tired, read "Miguel, have you tried deleting the old meta-data..." Oliver - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: ldap configuration
Oooops, you were just right. I will have a look at it... Oliver Miguel Figueiredo wrote: Hello Oliver, sorry for taking so long, had wife and kids waiting :) Well, if I remove the old metadata and start tomcat all goes well. The problem occurs if I restart tomcat: that's when that error occurs. I'm using the default Domain.xml configuration with the TxXMLFileDescriptorsStore for nodestore and TxFileContentStore for content. Miguel Oliver Zeigermann wrote: Miguel, I have tried deleting the old meta-data... Sorry, getting a little bit tired, read "Miguel, have you tried deleting the old meta-data..." Oliver - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: ldap configuration
Fixed. Was in Namespace and due to a patch I applied before. So, it was all my fault :( Release branch was not affected... Oliver Oliver Zeigermann wrote: Oooops, you were just right. I will have a look at it... Oliver Miguel Figueiredo wrote: Hello Oliver, sorry for taking so long, had wife and kids waiting :) Well, if I remove the old metadata and start tomcat all goes well. The problem occurs if I restart tomcat: that's when that error occurs. I'm using the default Domain.xml configuration with the TxXMLFileDescriptorsStore for nodestore and TxFileContentStore for content. Miguel Oliver Zeigermann wrote: Miguel, I have tried deleting the old meta-data... Sorry, getting a little bit tired, read "Miguel, have you tried deleting the old meta-data..." Oliver - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
