I realize that this is NOT a fix, but it is a temporary work around and 
provides some more information about the problem.  The NamespaceConfig object 
associated with the provided namespace parameter exists, but appears to be 
empty.  Even the name of the namespace is null within the configuration.  I 
suspect that this is actually a temporary namespace which is used during 
initialization, which will be replaced later in the startup sequence.  
Perhaps this temporary namespace configuration needs to have some explicitly 
defined default "acl_semantics"?

cvs diff -u src/share/org/apache/slide/common/NamespaceAccessTokenImpl.java
Index: src/share/org/apache/slide/common/NamespaceAccessTokenImpl.java
===================================================================
RCS file: 
/home/cvspublic/jakarta-slide/src/share/org/apache/slide/common/NamespaceAccessTokenImpl.java,v
retrieving revision 1.23
diff -u -r1.23 NamespaceAccessTokenImpl.java
--- src/share/org/apache/slide/common/NamespaceAccessTokenImpl.java     5 Nov 
2003 14:24:36 -0000       1.23
+++ src/share/org/apache/slide/common/NamespaceAccessTokenImpl.java     19 Nov 
2003 18:58:11 -0000
@@ -135,6 +135,12 @@
                     e.printStackTrace();
                 }
             }
+           // svaughan: Added check for special case since initialization
+           // hasn't occured yet.
+           else if (config.toString() == null) {
+                getLogger().log("This is a complete hack!", Logger.WARNING);
+                securityHelper = new SecurityImplAllGrant(namespace, config);
+           }
         }
         if (securityHelper == null) {
             securityHelper = new ACLSecurityImpl(namespace, 
namespace.getConfig());

- Steve

On Wednesday 19 November 2003 12:56 pm, Steve Vaughan wrote:
> I think the problem has to do with a store being used before it is
> initialized.  The same thing occurs when using the MemoryDescriptorsStore
> (or the DefaultStore).  The call to initialize the service is preceded by
> the construction of a NamespaceAccessTokenImpl, which eventually attempts
> to use the uninitialized store.
>
>       at
> org.apache.slide.common.NamespaceAccessTokenImpl.<init>(NamespaceAccessToke
>nImpl.java:140) at
> org.apache.slide.common.Namespace.initializeServices(Namespace.java:497)
>
> - Steve
>
> On Wednesday 19 November 2003 12:22 pm, Martin Holz wrote:
> > Hello,
> >
> > I tried to run the slidestore.reference.JDBCDescriptorsStore with the
> > recent cvs and got problems with cyclic dependencies in initialzation.
> >
> > The JDBCDescriptorsStore expects that initialize is called before
> > connect. Is this a valid assumption for a service? The documentation
> > is spare here. However Namespace tries to access the
> > store during initialization. For details see stacktrace.
> >
> >
> > WARN [apache.slide.common.Domain]  Service
> > [EMAIL PROTECTED] connection failed :
> > No suitable driver 5294 [main] WARN org.apache.slide.common.Domain  -
> > Service [EMAIL PROTECTED] connection
> > failed : No suitable driver 5304 [main] DEBUG
> > org.apache.slide.common.SlideException  -
> > org.apache.slide.common.ServiceConnectionFailedException: Service
> > [EMAIL PROTECTED] connection failed :
> > No suitable driver at
> > slidestore.reference.JDBCDescriptorsStore.connect(JDBCDescriptorsStore.ja
> >va
> >
> >:320) at
> >
> > org.apache.slide.common.AbstractServiceBase.connect(AbstractServiceBase.j
> >av a:162) at
> > org.apache.slide.store.AbstractStore.connect(AbstractStore.java:240) at
> > org.apache.slide.common.AbstractServiceBase.connectIfNeeded(AbstractServi
> >ce Base.java:234) at
> > org.apache.slide.common.Namespace.connectService(Namespace.java:533) at
> > org.apache.slide.common.Namespace.retrieveStore(Namespace.java:632) at
> > org.apache.slide.common.Uri.parseUri(Uri.java:379)
> >     at org.apache.slide.common.Uri.<init>(Uri.java:106)
> >     at org.apache.slide.common.Namespace.getUri(Namespace.java:680)
> >     at org.apache.slide.common.Namespace.getUri(Namespace.java:660)
> >     at org.apache.slide.common.Namespace.getUri(Namespace.java:648)
> >     at
> > org.apache.slide.security.ACLSecurityImpl.loadActionsCache(ACLSecurityImp
> >l. java:148) at
> > org.apache.slide.security.ACLSecurityImpl.init(ACLSecurityImpl.java:123)
> > at org.apache.slide.security.SecurityImpl.<init>(SecurityImpl.java:113)
> > at
> > org.apache.slide.security.ACLSecurityImpl.<init>(ACLSecurityImpl.java:109
> >) at
> > org.apache.slide.common.NamespaceAccessTokenImpl.<init>(NamespaceAccessTo
> >ke nImpl.java:140) at
> > org.apache.slide.common.Namespace.initializeServices(Namespace.java:497)
> > at org.apache.slide.common.Namespace.loadDefinition(Namespace.java:762)
> > at org.apache.slide.common.Domain.initNamespace(Domain.java:852)
> >     at org.apache.slide.common.Domain.init(Domain.java:476)
> >     at org.apache.slide.common.Domain.init(Domain.java:410)
> >     at org.apache.slide.common.Domain.init(Domain.java:373)
> >     at org.apache.slide.webdav.WebdavServlet.init(WebdavServlet.java:292)
> >     at javax.servlet.GenericServlet.init(GenericServlet.java:256)
> >     at org.apache.slide.webdav.WebdavServlet.init(WebdavServlet.java:234)
> >
> >
> > ---------------------------------------------------------------------
> > 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]

Reply via email to