The names of the JCR workspace should correspond to the name of the workspaces at the connector level. In one of your earlier posts, you define the "nameOfDefaultWorkspace" property on the JpaSource object to be "MyRepo". This means that you should be able to use a Repository.login() that specifies a workspace name of "MyRepo", or use one of the Repository.login() methods that doesn't specify a workspace name to have the JCR Repository object consult the JpaSource for it's default workspace name.
Is this what you're doing?
And I'm very much still doing that. HOwever, my understanding is that repositories and workspaces are different things. I don't see how I configure the workspace in the JcrConfiguration.
Any progress? I've just coded a very explicit example on how to do all this, and I'll check it in shortly.
Yeah sorry I got pulled into another project the end of last week that took precedence.
I got past that hurdle after adding the predefinedWorkspaceNames property, I can now see the workspace being created in the database.
I seem to have a new issue though.
2009-09-08 10:45:10,059 WARN [org.hibernate.util.JDBCExceptionReporter] (pool-159-thread-2) SQL Error: 1400, SQLState: 23000 2009-09-08 10:45:10,108 ERROR [org.hibernate.util.JDBCExceptionReporter] (pool-159-thread-2) ORA-01400: cannot insert NULL into ("JCRPUBLIC"."DNA_NAMESPACES"."URI") 2009-09-08 10:45:10,108 WARN [org.hibernate.util.JDBCExceptionReporter] (pool-159-thread-2) SQL Error: 1400, SQLState: 23000 2009-09-08 10:45:10,108 ERROR [org.hibernate.util.JDBCExceptionReporter] (pool-159-thread-2) ORA-01400: cannot insert NULL into ("JCRPUBLIC"."DNA_NAMESPACES"."URI") 2009-09-08 10:45:10,108 ERROR [org.hibernate.event.def.AbstractFlushingEventListener] (pool-159-thread-2) Could not synchronize database state with session org.hibernate.exception.ConstraintViolationException: Could not execute JDBC batch update at org.hibernate.exception.SQLStateConverter.convert(SQLStateConverter.java:94) at org.hibernate.exception.JDBCExceptionHelper.convert(JDBCExceptionHelper.java:66) at org.hibernate.jdbc.AbstractBatcher.executeBatch(AbstractBatcher.java:275) at org.hibernate.jdbc.AbstractBatcher.prepareStatement(AbstractBatcher.java:114) at org.hibernate.jdbc.AbstractBatcher.prepareStatement(AbstractBatcher.java:109) at org.hibernate.jdbc.AbstractBatcher.prepareBatchStatement(AbstractBatcher.java:244) at org.hibernate.persister.entity.AbstractEntityPersister.insert(AbstractEntityPersister.java:2252) at org.hibernate.persister.entity.AbstractEntityPersister.insert(AbstractEntityPersister.java:2688) at org.hibernate.action.EntityInsertAction.execute(EntityInsertAction.java:79) at org.hibernate.engine.ActionQueue.execute(ActionQueue.java:279) at org.hibernate.engine.ActionQueue.executeActions(ActionQueue.java:263) at org.hibernate.engine.ActionQueue.executeActions(ActionQueue.java:167) at org.hibernate.event.def.AbstractFlushingEventListener.performExecutions(AbstractFlushingEventListener.java:321) at org.hibernate.event.def.DefaultFlushEventListener.onFlush(DefaultFlushEventListener.java:50) at org.hibernate.impl.SessionImpl.flush(SessionImpl.java:1027) at org.hibernate.impl.SessionImpl.managedFlush(SessionImpl.java:365) at org.hibernate.transaction.JDBCTransaction.commit(JDBCTransaction.java:137) at org.hibernate.ejb.TransactionImpl.commit(TransactionImpl.java:54) at org.jboss.dna.connector.store.jpa.model.basic.BasicRequestProcessor.close(BasicRequestProcessor.java:2333) at org.jboss.dna.connector.store.jpa.JpaConnection.execute(JpaConnection.java:146) at org.jboss.dna.graph.connector.federation.ForkRequestProcessor$Channel$3.call(ForkRequestProcessor.java:318) at org.jboss.dna.graph.connector.federation.ForkRequestProcessor$Channel$3.call(ForkRequestProcessor.java:314) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) at java.util.concurrent.FutureTask.run(FutureTask.java:138) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) at java.lang.Thread.run(Thread.java:619) Caused by: java.sql.BatchUpdateException: ORA-01400: cannot insert NULL into ("JCRPUBLIC"."DNA_NAMESPACES"."URI") at oracle.jdbc.driver.DatabaseError.throwBatchUpdateException(DatabaseError.java:343) at oracle.jdbc.driver.OraclePreparedStatement.executeBatch(OraclePreparedStatement.java:10768) at org.jboss.resource.adapter.jdbc.WrappedStatement.executeBatch(WrappedStatement.java:774) at org.hibernate.jdbc.BatchingBatcher.doExecuteBatch(BatchingBatcher.java:70) at org.hibernate.jdbc.AbstractBatcher.executeBatch(AbstractBatcher.java:268) ... 24 more
This stack trace appears when I call session.getRootNode().addNode("somepage") and when I do session.getRootNode().addNode("somepage","nt:unstructured");
I'm not currently using any CND's.
In addition, it looks like the programmatic approach to creating node types is broken. or i have something wrong on my classpath. should I be building against a set of the JCR apis in particular?
Oh. That error is because Oracle treats the empty string and null as equivalent. So when we try to insert the default mapping from the empty namespace prefix to the empty URI, Oracle cries foul. I'll add a bug/patch for that.
it looks like the programmatic approach to creating node types is broken.
i'll apply the patch locally as well to test.
though, i'm still not sure where it's trying to insert an empty string.
and for the programmatic node types, i'll get back to you once the patch is applied. I was following http://jboss.org/file-access/default/members/dna/freezone/docs/0.5/manuals/reference/html_single/reference-guide-en.html#d0e6301 but the code example doesn't seem to compile, so I'm not sure if I have to change a version or something somewhere. i'll go back and double check the code and import statements too.
The empty string is being stored because we store all namespace URIs, including the default namespace (used when there is no prefix) that is an empty string, as per the JCR specification (Section 4.5 of the JCR Specification, version 1.0.1).
That section is a little preview of some functionality available in the JCR 2.0 API (well, what's described in the Public Final Draft, which is the latest). And, yes, we have DNA-specific interfaces in the
org.jboss.dna.jcr.nodetypespackage that should be similar to those proposed by the JCR 2.0 API. This is required because JBoss DNA requires the JCR 1.0 API jar on the classpath, and cannot be used with the JCR 2.0 API jar file.
For some code examples that use the programmatic approach, look at the org.jboss.dna.jcr.TypeRegistrationTest  in the 'dna-jcr' project.
The empty URI mapping bug would definitely blow up that example code when this line executes.
Names with no prefix implicitly use the empty prefix to empty URI mapping. Please let us know if there are any other problems though.
There were a few typos in the example, and I'll get those fixed ASAP.
1) Change NodeTypeManager on line 2 to JcrNodeTypeManager
3) Add a boolean argument in the method call in the last line.
Ok, now I see the error in the code. Looks good.
I updated my code base to reference the new (in my opinion ambiguously defined) property autoGenerateSchema to update and dropped the tables w/ issues. Confirmed that my generation script works (populates default nodes on startup and on resetart validates the data). Confirmed the population, but everything seems to be in a blob data.
The patch works