You are viewing a plain text version of this content. The canonical link for it is here.
Posted to oak-commits@jackrabbit.apache.org by th...@apache.org on 2012/03/28 11:11:40 UTC
svn commit: r1306222 - in /jackrabbit/oak/trunk/oak-jcr/src:
main/java/org/apache/jackrabbit/oak/jcr/
main/java/org/apache/jackrabbit/oak/jcr/query/
test/java/org/apache/jackrabbit/oak/jcr/
test/java/org/apache/jackrabbit/oak/jcr/query/
Author: thomasm
Date: Wed Mar 28 09:11:39 2012
New Revision: 1306222
URL: http://svn.apache.org/viewvc?rev=1306222&view=rev
Log:
OAK-28 Query implementation (initial implementation of the relevant oak-jcr part)
Added:
jackrabbit/oak/trunk/oak-jcr/src/main/java/org/apache/jackrabbit/oak/jcr/query/QueryImpl.java
jackrabbit/oak/trunk/oak-jcr/src/main/java/org/apache/jackrabbit/oak/jcr/query/QueryManagerImpl.java
jackrabbit/oak/trunk/oak-jcr/src/main/java/org/apache/jackrabbit/oak/jcr/query/QueryResultImpl.java
jackrabbit/oak/trunk/oak-jcr/src/main/java/org/apache/jackrabbit/oak/jcr/query/RowImpl.java
jackrabbit/oak/trunk/oak-jcr/src/main/java/org/apache/jackrabbit/oak/jcr/query/ValueConverter.java
jackrabbit/oak/trunk/oak-jcr/src/test/java/org/apache/jackrabbit/oak/jcr/query/QueryTest.java
Modified:
jackrabbit/oak/trunk/oak-jcr/src/main/java/org/apache/jackrabbit/oak/jcr/WorkspaceImpl.java
jackrabbit/oak/trunk/oak-jcr/src/test/java/org/apache/jackrabbit/oak/jcr/AbstractRepositoryTest.java
Modified: jackrabbit/oak/trunk/oak-jcr/src/main/java/org/apache/jackrabbit/oak/jcr/WorkspaceImpl.java
URL: http://svn.apache.org/viewvc/jackrabbit/oak/trunk/oak-jcr/src/main/java/org/apache/jackrabbit/oak/jcr/WorkspaceImpl.java?rev=1306222&r1=1306221&r2=1306222&view=diff
==============================================================================
--- jackrabbit/oak/trunk/oak-jcr/src/main/java/org/apache/jackrabbit/oak/jcr/WorkspaceImpl.java (original)
+++ jackrabbit/oak/trunk/oak-jcr/src/main/java/org/apache/jackrabbit/oak/jcr/WorkspaceImpl.java Wed Mar 28 09:11:39 2012
@@ -16,6 +16,7 @@
*/
package org.apache.jackrabbit.oak.jcr;
+import org.apache.jackrabbit.oak.jcr.query.QueryManagerImpl;
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
import org.xml.sax.ContentHandler;
@@ -45,6 +46,7 @@ public class WorkspaceImpl implements Wo
private static final Logger log = LoggerFactory.getLogger(WorkspaceImpl.class);
private final SessionContext<SessionImpl> sessionContext;
+ private QueryManagerImpl queryManager;
public WorkspaceImpl(SessionContext<SessionImpl> sessionContext) {
this.sessionContext = sessionContext;
@@ -113,9 +115,10 @@ public class WorkspaceImpl implements Wo
@Override
public QueryManager getQueryManager() throws RepositoryException {
getSessionImpl().checkIsAlive();
-
- // TODO
- return null;
+ if (queryManager == null) {
+ queryManager = new QueryManagerImpl(this, sessionContext);
+ }
+ return queryManager;
}
@Override
Added: jackrabbit/oak/trunk/oak-jcr/src/main/java/org/apache/jackrabbit/oak/jcr/query/QueryImpl.java
URL: http://svn.apache.org/viewvc/jackrabbit/oak/trunk/oak-jcr/src/main/java/org/apache/jackrabbit/oak/jcr/query/QueryImpl.java?rev=1306222&view=auto
==============================================================================
--- jackrabbit/oak/trunk/oak-jcr/src/main/java/org/apache/jackrabbit/oak/jcr/query/QueryImpl.java (added)
+++ jackrabbit/oak/trunk/oak-jcr/src/main/java/org/apache/jackrabbit/oak/jcr/query/QueryImpl.java Wed Mar 28 09:11:39 2012
@@ -0,0 +1,108 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements. See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership. The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance
+ * with the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing,
+ * software distributed under the License is distributed on an
+ * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+ * KIND, either express or implied. See the License for the
+ * specific language governing permissions and limitations
+ * under the License.
+ */
+package org.apache.jackrabbit.oak.jcr.query;
+
+import java.util.HashMap;
+import java.util.List;
+import javax.jcr.Node;
+import javax.jcr.RepositoryException;
+import javax.jcr.Value;
+import javax.jcr.query.InvalidQueryException;
+import javax.jcr.query.Query;
+import javax.jcr.query.QueryResult;
+
+/**
+ * The implementation of the corresponding JCR interface.
+ */
+public class QueryImpl implements Query {
+
+ private final QueryManagerImpl manager;
+ private final HashMap<String, Value> bindVariableMap = new HashMap<String, Value>();
+ private final String language;
+ private final String statement;
+ private long limit, offset;
+ private boolean parsed;
+
+ QueryImpl(QueryManagerImpl manager, String statement, String language) {
+ this.manager = manager;
+ this.statement = statement;
+ this.language = language;
+ }
+
+ @Override
+ public void bindValue(String varName, Value value) {
+ bindVariableMap.put(varName, value);
+ }
+
+ private void parse() throws InvalidQueryException {
+ if (parsed) {
+ return;
+ }
+ List<String> names = manager.parse(statement, language);
+ for (String n : names) {
+ bindVariableMap.put(n, null);
+ }
+ }
+
+ @Override
+ public QueryResult execute() throws RepositoryException {
+ return manager.executeQuery(statement, language, bindVariableMap, limit, offset);
+ }
+
+ @Override
+ public String[] getBindVariableNames() throws RepositoryException {
+ parse();
+ String[] names = new String[bindVariableMap.size()];
+ bindVariableMap.keySet().toArray(names);
+ return names;
+ }
+
+ @Override
+ public String getLanguage() {
+ return language;
+ }
+
+ @Override
+ public String getStatement() {
+ return statement;
+ }
+
+ @Override
+ public String getStoredQueryPath() throws RepositoryException {
+ // TODO not implemented yet
+ return null;
+ }
+
+ @Override
+ public void setLimit(long limit) {
+ this.limit = limit;
+ }
+
+ @Override
+ public void setOffset(long offset) {
+ this.offset = offset;
+ }
+
+ @Override
+ public Node storeAsNode(String absPath) throws RepositoryException {
+ // TODO not implemented yet
+ return null;
+ }
+
+}
Added: jackrabbit/oak/trunk/oak-jcr/src/main/java/org/apache/jackrabbit/oak/jcr/query/QueryManagerImpl.java
URL: http://svn.apache.org/viewvc/jackrabbit/oak/trunk/oak-jcr/src/main/java/org/apache/jackrabbit/oak/jcr/query/QueryManagerImpl.java?rev=1306222&view=auto
==============================================================================
--- jackrabbit/oak/trunk/oak-jcr/src/main/java/org/apache/jackrabbit/oak/jcr/query/QueryManagerImpl.java (added)
+++ jackrabbit/oak/trunk/oak-jcr/src/main/java/org/apache/jackrabbit/oak/jcr/query/QueryManagerImpl.java Wed Mar 28 09:11:39 2012
@@ -0,0 +1,122 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements. See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership. The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance
+ * with the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing,
+ * software distributed under the License is distributed on an
+ * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+ * KIND, either express or implied. See the License for the
+ * specific language governing permissions and limitations
+ * under the License.
+ */
+package org.apache.jackrabbit.oak.jcr.query;
+
+import java.text.ParseException;
+import java.util.HashMap;
+import java.util.List;
+import java.util.Map.Entry;
+import javax.jcr.Node;
+import javax.jcr.RepositoryException;
+import javax.jcr.Value;
+import javax.jcr.query.InvalidQueryException;
+import javax.jcr.query.Query;
+import javax.jcr.query.QueryManager;
+import javax.jcr.query.QueryResult;
+import javax.jcr.query.qom.QueryObjectModelFactory;
+import org.apache.jackrabbit.mk.api.MicroKernel;
+import org.apache.jackrabbit.oak.jcr.SessionContext;
+import org.apache.jackrabbit.oak.jcr.SessionImpl;
+import org.apache.jackrabbit.oak.jcr.WorkspaceImpl;
+import org.apache.jackrabbit.oak.jcr.query.qom.QueryObjectModelFactoryImpl;
+import org.apache.jackrabbit.oak.query.CoreValue;
+import org.apache.jackrabbit.oak.query.QueryEngine;
+import org.apache.jackrabbit.oak.query.Result;
+
+/**
+ * The implementation of the corresponding JCR interface.
+ */
+public class QueryManagerImpl implements QueryManager {
+
+ private final QueryObjectModelFactoryImpl qomFactory = new QueryObjectModelFactoryImpl();
+ private final QueryEngine qe;
+
+ public QueryManagerImpl(WorkspaceImpl workspace, SessionContext<SessionImpl> sessionContext) {
+ MicroKernel mk = sessionContext.getGlobalContext().getInstance(MicroKernel.class);
+ qe = new QueryEngine(mk);
+ }
+
+ @Override
+ public Query createQuery(String statement, String language) throws RepositoryException {
+ return new QueryImpl(this, statement, language);
+ }
+
+ @Override
+ public QueryObjectModelFactory getQOMFactory() {
+ return qomFactory;
+ }
+
+ @Override
+ public Query getQuery(Node node) throws RepositoryException {
+ // TODO getQuery(Node node): is it needed?
+ throw new RepositoryException("Feature not implemented");
+ }
+
+ @Override
+ public String[] getSupportedQueryLanguages() throws RepositoryException {
+ @SuppressWarnings("deprecation")
+ // create a new instance each time because the array is mutable
+ // (the caller could modify it)
+ String[] s = {
+ Query.JCR_JQOM,
+ Query.JCR_SQL2,
+ Query.XPATH
+ };
+ return s;
+ }
+
+ public List<String> parse(String statement, String language) throws InvalidQueryException {
+ try {
+ return qe.parse(statement, convertLanguage(language));
+ } catch (ParseException e) {
+ throw new InvalidQueryException(e);
+ }
+ }
+
+ public QueryResult executeQuery(String statement, String language,
+ HashMap<String, Value> bindVariableMap, long limit, long offset) throws RepositoryException {
+ try {
+ HashMap<String, CoreValue> bindMap = convertMap(bindVariableMap);
+ Result r = qe.executeQuery(statement, convertLanguage(language), bindMap);
+ return new QueryResultImpl(r);
+ } catch (ParseException e) {
+ throw new InvalidQueryException(e);
+ }
+ }
+
+ @SuppressWarnings("deprecation")
+ private static String convertLanguage(String jcrLanguage) throws InvalidQueryException {
+ if (jcrLanguage.equals(Query.JCR_SQL2)) {
+ return QueryEngine.SQL2;
+ } else if (jcrLanguage.equals(Query.XPATH)) {
+ return QueryEngine.XPATH;
+ } else {
+ throw new InvalidQueryException("Unsupported language: " + jcrLanguage);
+ }
+ }
+
+ private HashMap<String, CoreValue> convertMap(HashMap<String, Value> bindVariableMap) throws RepositoryException {
+ HashMap<String, CoreValue> map = new HashMap<String, CoreValue>();
+ for (Entry<String, Value> e : bindVariableMap.entrySet()) {
+ map.put(e.getKey(), ValueConverter.convert(e.getValue()));
+ }
+ return map;
+ }
+
+}
Added: jackrabbit/oak/trunk/oak-jcr/src/main/java/org/apache/jackrabbit/oak/jcr/query/QueryResultImpl.java
URL: http://svn.apache.org/viewvc/jackrabbit/oak/trunk/oak-jcr/src/main/java/org/apache/jackrabbit/oak/jcr/query/QueryResultImpl.java?rev=1306222&view=auto
==============================================================================
--- jackrabbit/oak/trunk/oak-jcr/src/main/java/org/apache/jackrabbit/oak/jcr/query/QueryResultImpl.java (added)
+++ jackrabbit/oak/trunk/oak-jcr/src/main/java/org/apache/jackrabbit/oak/jcr/query/QueryResultImpl.java Wed Mar 28 09:11:39 2012
@@ -0,0 +1,81 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements. See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership. The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance
+ * with the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing,
+ * software distributed under the License is distributed on an
+ * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+ * KIND, either express or implied. See the License for the
+ * specific language governing permissions and limitations
+ * under the License.
+ */
+package org.apache.jackrabbit.oak.jcr.query;
+
+import java.util.Iterator;
+import javax.jcr.NodeIterator;
+import javax.jcr.RepositoryException;
+import javax.jcr.query.QueryResult;
+import javax.jcr.query.RowIterator;
+import org.apache.jackrabbit.commons.iterator.RowIteratorAdapter;
+import org.apache.jackrabbit.oak.query.Result;
+import org.apache.jackrabbit.oak.query.ResultRow;
+
+/**
+ * The implementation of the corresponding JCR interface.
+ */
+public class QueryResultImpl implements QueryResult {
+
+ final Result result;
+
+ public QueryResultImpl(Result result) {
+ this.result = result;
+ }
+
+ @Override
+ public String[] getColumnNames() throws RepositoryException {
+ return result.getColumnNames();
+ }
+
+ @Override
+ public String[] getSelectorNames() throws RepositoryException {
+ return result.getSelectorNames();
+ }
+
+ @Override
+ public RowIterator getRows() throws RepositoryException {
+ Iterator<RowImpl> it = new Iterator<RowImpl>() {
+
+ private Iterator<ResultRow> it = result.getRows();
+
+ @Override
+ public boolean hasNext() {
+ return it.hasNext();
+ }
+
+ @Override
+ public RowImpl next() {
+ return new RowImpl(it.next());
+ }
+
+ @Override
+ public void remove() {
+ it.remove();
+ }
+
+ };
+ return new RowIteratorAdapter(it);
+ }
+
+ @Override
+ public NodeIterator getNodes() throws RepositoryException {
+ return null;
+ }
+
+}
Added: jackrabbit/oak/trunk/oak-jcr/src/main/java/org/apache/jackrabbit/oak/jcr/query/RowImpl.java
URL: http://svn.apache.org/viewvc/jackrabbit/oak/trunk/oak-jcr/src/main/java/org/apache/jackrabbit/oak/jcr/query/RowImpl.java?rev=1306222&view=auto
==============================================================================
--- jackrabbit/oak/trunk/oak-jcr/src/main/java/org/apache/jackrabbit/oak/jcr/query/RowImpl.java (added)
+++ jackrabbit/oak/trunk/oak-jcr/src/main/java/org/apache/jackrabbit/oak/jcr/query/RowImpl.java Wed Mar 28 09:11:39 2012
@@ -0,0 +1,82 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements. See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership. The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance
+ * with the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing,
+ * software distributed under the License is distributed on an
+ * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+ * KIND, either express or implied. See the License for the
+ * specific language governing permissions and limitations
+ * under the License.
+ */
+package org.apache.jackrabbit.oak.jcr.query;
+
+import javax.jcr.ItemNotFoundException;
+import javax.jcr.Node;
+import javax.jcr.RepositoryException;
+import javax.jcr.Value;
+import javax.jcr.query.Row;
+import org.apache.jackrabbit.oak.query.CoreValue;
+import org.apache.jackrabbit.oak.query.ResultRow;
+
+/**
+ * The implementation of the corresponding JCR interface.
+ */
+public class RowImpl implements Row {
+
+ private final ResultRow row;
+
+ public RowImpl(ResultRow row) {
+ this.row = row;
+ }
+
+ public Node getNode() throws RepositoryException {
+ // TODO row node
+ return null;
+ }
+
+ public Node getNode(String selectorName) throws RepositoryException {
+ // TODO row node
+ return null;
+ }
+
+ public String getPath() throws RepositoryException {
+ return row.getPath();
+ }
+
+ public String getPath(String selectorName) throws RepositoryException {
+ return row.getPath(selectorName);
+ }
+
+ public double getScore() throws RepositoryException {
+ // TODO row score
+ return 0;
+ }
+
+ public double getScore(String selectorName) throws RepositoryException {
+ // TODO row score
+ return 0;
+ }
+
+ public Value getValue(String columnName) throws ItemNotFoundException, RepositoryException {
+ return ValueConverter.convert(row.getValue(columnName));
+ }
+
+ public Value[] getValues() throws RepositoryException {
+ CoreValue[] values = row.getValues();
+ int len = values.length;
+ Value[] v2 = new Value[values.length];
+ for (int i = 0; i < len; i++) {
+ v2[i] = ValueConverter.convert(values[i]);
+ }
+ return v2;
+ }
+
+}
Added: jackrabbit/oak/trunk/oak-jcr/src/main/java/org/apache/jackrabbit/oak/jcr/query/ValueConverter.java
URL: http://svn.apache.org/viewvc/jackrabbit/oak/trunk/oak-jcr/src/main/java/org/apache/jackrabbit/oak/jcr/query/ValueConverter.java?rev=1306222&view=auto
==============================================================================
--- jackrabbit/oak/trunk/oak-jcr/src/main/java/org/apache/jackrabbit/oak/jcr/query/ValueConverter.java (added)
+++ jackrabbit/oak/trunk/oak-jcr/src/main/java/org/apache/jackrabbit/oak/jcr/query/ValueConverter.java Wed Mar 28 09:11:39 2012
@@ -0,0 +1,102 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements. See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership. The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance
+ * with the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing,
+ * software distributed under the License is distributed on an
+ * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+ * KIND, either express or implied. See the License for the
+ * specific language governing permissions and limitations
+ * under the License.
+ */
+package org.apache.jackrabbit.oak.jcr.query;
+
+import javax.jcr.PropertyType;
+import javax.jcr.RepositoryException;
+import javax.jcr.Value;
+import javax.jcr.ValueFactory;
+import javax.jcr.ValueFormatException;
+import org.apache.jackrabbit.commons.SimpleValueFactory;
+import org.apache.jackrabbit.oak.query.CoreValue;
+import org.apache.jackrabbit.oak.query.CoreValueFactory;
+
+/**
+ * Convert values to the jcr-core flavor.
+ */
+public class ValueConverter {
+
+ private static final CoreValueFactory coreValueFactory = new CoreValueFactory();
+ private static final ValueFactory jcrValueFactory = new SimpleValueFactory();
+
+ public static CoreValue convert(Value v) throws RepositoryException {
+ switch (v.getType()) {
+ case PropertyType.BINARY:
+ // TODO convert binary to data store entry
+ throw new UnsupportedOperationException();
+ case PropertyType.BOOLEAN:
+ return coreValueFactory.createValue(v.getBoolean());
+ case PropertyType.DATE:
+ // TODO convert date
+ throw new UnsupportedOperationException();
+ case PropertyType.DECIMAL:
+ return coreValueFactory.createValue(v.getDecimal());
+ case PropertyType.DOUBLE:
+ return coreValueFactory.createValue(v.getDouble());
+ case PropertyType.LONG:
+ return coreValueFactory.createValue(v.getLong());
+ case PropertyType.NAME:
+ // TODO possibly do name space mapping here
+ return coreValueFactory.createValue(v.getString(), CoreValue.NAME);
+ case PropertyType.PATH:
+ // TODO possibly do name space mapping here
+ return coreValueFactory.createValue(v.getString(), CoreValue.PATH);
+ case PropertyType.REFERENCE:
+ // TODO possibly do name space mapping here
+ return coreValueFactory.createValue(v.getString(), CoreValue.REFERENCE);
+ case PropertyType.STRING:
+ return coreValueFactory.createValue(v.getString());
+ default:
+ throw new IllegalArgumentException("Unsupported property type " + v.getType());
+ }
+ }
+
+ public static Value convert(CoreValue v) throws ValueFormatException {
+ switch (v.getType()) {
+ case CoreValue.BINARY:
+ // TODO convert binary to data store entry
+ throw new UnsupportedOperationException();
+ case CoreValue.BOOLEAN:
+ return jcrValueFactory.createValue(v.getBoolean());
+ case CoreValue.DATE:
+ // TODO convert date
+ throw new UnsupportedOperationException();
+ case CoreValue.DECIMAL:
+ return jcrValueFactory.createValue(v.getDecimal());
+ case CoreValue.DOUBLE:
+ return jcrValueFactory.createValue(v.getDouble());
+ case CoreValue.LONG:
+ return jcrValueFactory.createValue(v.getLong());
+ case CoreValue.NAME:
+ // TODO possibly do name space mapping here
+ return jcrValueFactory.createValue(v.getString(), CoreValue.NAME);
+ case CoreValue.PATH:
+ // TODO possibly do name space mapping here
+ return jcrValueFactory.createValue(v.getString(), CoreValue.PATH);
+ case CoreValue.REFERENCE:
+ // TODO possibly do name space mapping here
+ return jcrValueFactory.createValue(v.getString(), CoreValue.REFERENCE);
+ case CoreValue.STRING:
+ return jcrValueFactory.createValue(v.getString());
+ default:
+ throw new IllegalArgumentException("Unsupported property type " + v.getType());
+ }
+ }
+
+}
Modified: jackrabbit/oak/trunk/oak-jcr/src/test/java/org/apache/jackrabbit/oak/jcr/AbstractRepositoryTest.java
URL: http://svn.apache.org/viewvc/jackrabbit/oak/trunk/oak-jcr/src/test/java/org/apache/jackrabbit/oak/jcr/AbstractRepositoryTest.java?rev=1306222&r1=1306221&r2=1306222&view=diff
==============================================================================
--- jackrabbit/oak/trunk/oak-jcr/src/test/java/org/apache/jackrabbit/oak/jcr/AbstractRepositoryTest.java (original)
+++ jackrabbit/oak/trunk/oak-jcr/src/test/java/org/apache/jackrabbit/oak/jcr/AbstractRepositoryTest.java Wed Mar 28 09:11:39 2012
@@ -17,10 +17,10 @@ import javax.jcr.Session;
* Users of this class must call clear to close the session associated with
* this instance and clean up the repository when done.
*/
-abstract class AbstractRepositoryTest {
+public abstract class AbstractRepositoryTest {
private Repository repository;
private Session session;
-
+
public void logout() throws RepositoryException {
Session session = getRepository().login();
try {
Added: jackrabbit/oak/trunk/oak-jcr/src/test/java/org/apache/jackrabbit/oak/jcr/query/QueryTest.java
URL: http://svn.apache.org/viewvc/jackrabbit/oak/trunk/oak-jcr/src/test/java/org/apache/jackrabbit/oak/jcr/query/QueryTest.java?rev=1306222&view=auto
==============================================================================
--- jackrabbit/oak/trunk/oak-jcr/src/test/java/org/apache/jackrabbit/oak/jcr/query/QueryTest.java (added)
+++ jackrabbit/oak/trunk/oak-jcr/src/test/java/org/apache/jackrabbit/oak/jcr/query/QueryTest.java Wed Mar 28 09:11:39 2012
@@ -0,0 +1,75 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements. See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership. The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance
+ * with the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing,
+ * software distributed under the License is distributed on an
+ * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+ * KIND, either express or implied. See the License for the
+ * specific language governing permissions and limitations
+ * under the License.
+ */
+package org.apache.jackrabbit.oak.jcr.query;
+
+import static junit.framework.Assert.assertEquals;
+import static junit.framework.Assert.assertTrue;
+import static org.junit.Assert.assertFalse;
+import javax.jcr.Node;
+import javax.jcr.Repository;
+import javax.jcr.RepositoryException;
+import javax.jcr.Session;
+import javax.jcr.ValueFactory;
+import javax.jcr.query.Query;
+import javax.jcr.query.QueryManager;
+import javax.jcr.query.QueryResult;
+import javax.jcr.query.Row;
+import javax.jcr.query.RowIterator;
+import org.apache.jackrabbit.oak.jcr.AbstractRepositoryTest;
+import org.junit.After;
+import org.junit.Test;
+
+/**
+ * Tests the query feature.
+ */
+public class QueryTest extends AbstractRepositoryTest {
+
+ @After
+ public void tearDown() throws RepositoryException {
+ logout();
+ }
+
+ @Test
+ public void simple() throws RepositoryException {
+ Repository repository = getRepository();
+ Session session = repository.login();
+ try {
+ Node hello = session.getRootNode().addNode("hello");
+ hello.setProperty("id", "1");
+ hello.setProperty("text", "hello world");
+ session.save();
+
+ ValueFactory vf = session.getValueFactory();
+
+ QueryManager qm = session.getWorkspace().getQueryManager();
+ Query q = qm.createQuery("select text from [nt:base] where id = $id", Query.JCR_SQL2);
+ q.bindValue("id", vf.createValue("1"));
+ QueryResult r = q.execute();
+ RowIterator it = r.getRows();
+ assertTrue(it.hasNext());
+ Row row = it.nextRow();
+ assertEquals("hello world", row.getValue("text").getString());
+ assertFalse(it.hasNext());
+
+ } finally {
+ session.logout();
+ }
+ }
+
+}
Re: oak api : initial draft
Posted by Michael Dürig <mi...@gmail.com>.
On Mar 28, 2012 8:52 PM, "Jukka Zitting" <ju...@gmail.com> wrote:
>
> Hi,
>
> On Wed, Mar 28, 2012 at 9:13 PM, Michael Dürig <md...@apache.org> wrote:
> > - Is it possible to open multiple Connection instances with one
SessionInfo?
> > What would be the purpose of this? Can I commit a NodeState created
with a
> > NodeBuilder from one Connection into another Connection?
> >
> > - Wouldn't it be simpler and sufficient to have a 1:1 relationship
between
> > SessionInfo and Connection? Again: can I commit a NodeState created
with a
> > NodeBuilder from one Connection into another Connection (from another
> > SessionInfo in this case)?
>
> I think it would make sense to merge SessionInfo and Connection to a
> singe interface. The main reason we didn't do that yet is the handling
> of credentials and session attributes (i.e. as a way for custom
> authentication components to pass information back and forth across
> the API) that felt out of place in Connection. I'd rather get rid of
> session attributes entirely at this level (and use the JAAS model for
> any across-the-stack communcation), but I think we need to keep it for
> now for compatibility with existing authentication components designed
> for Jackrabbit 2.x.
>
> Anyway, having thought about this a bit more, I'd support merging
> SessionInfo and Connection to a single Connection (or some other
> similarly named) interface.
Connection seems like a good name to me. Re. Session attributes: we could
encapsulate these and other information regarding authentication in a
AuthInfo class which can be retrieved from the connection.
> > - Do we want to make any guarantees wrt. thread safety on Connection?
>
> I don't see a strong use case where we'd need thread-safety at this
> level. Unless we come up with one, I suggest we don't make such
> guarantees on Connection level.
+1. Let's state this explicitly in the javadoc.
> > - Having NodeState and NodeBuilder in the oak-core API currently
introduces
> > a dependency on oak-mk for clients of that API. We should probably move
the
> > interfaces which are used across the stack to some common location.
>
> Right. This would be a non-issue if we hadn't split oak-core apart...
;-)
> Anyway, I'd rather keep the oak-mk reference as is for now until we
> encounter a case of why we'd truly need a different tree model on the
> oak-core level. For example the CoreValue class that Thomas now has
> for the query code might well be something that we need to consider
> also from an API perspective.
Ok ack. Afaics we might need a different tree model anyway at some point.
1. Since we probably want to return CoreValue instances instead if Scalar.
And 2. Since the tree builder needs to expose additional information for
transient nodes (e.g. isNew, isModified).
Michael
> BR,
>
> Jukka Zitting
Re: oak api : initial draft
Posted by Thomas Mueller <mu...@adobe.com>.
Hi,
>>>- Having NodeState and NodeBuilder in the oak-core API currently
>>>introduces
>>> a dependency on oak-mk for clients of that API.
>>
>> Right. This would be a non-issue if we hadn't split oak-core apart...
>
>imo we need a separate api at the oak-core (SPI) level without
>any dependency to MK.
>it's a different level of abstraction [...] from my point of view
>the MK is the replacement for the former persistence layer just
>being in charge of the storage.
I agree with Angela here.
For example, PropertyState (used in NodeState) currently doesn't know the
JCR property type. Of course we can change that to include that
information (an integer for example), but this information shouldn't
concern the MK layer. It would add concerns of oak-jcr into the storage
level, which feels illogical to me. Also, PropertyState currently has a
method "String getEncodedValue()" which returns the JSON encoded value.
This is something that shouldn't concern oak-jcr. But it's not such a big
problem as to expose oak-jcr concerns in oak-mk.
I kind of see the advantage to only have one NodeState / NodeBuilder
abstraction, but I'm not sure if that's the right solution. A workaround
would be to use generics: NodeState<T> / NodeBuilder<T> /
PropertyState<T>, and then in oak-mk use PropertyState<Json>. And in
oak-jcr and oak-core use PropertyState<CoreValue> (and/or possibly use
PropertyState<Value> in oak-jcr).
>>Anyway, I'd rather keep the oak-mk reference as is for now [...]
Yes, we need to come up with an abstraction.
Regards,
Thomas
Re: oak api : initial draft
Posted by Angela Schreiber <an...@adobe.com>.
hi jukka
>> - Having NodeState and NodeBuilder in the oak-core API currently introduces
>> a dependency on oak-mk for clients of that API. We should probably move the
>> interfaces which are used across the stack to some common location.
>
> Right. This would be a non-issue if we hadn't split oak-core apart...
imo we need a separate api at the oak-core (SPI) level without
any dependency to MK. it's a different level of abstraction and
it has a completely different purpose. from my point of view
the MK is the replacement for the former persistence layer just
being in charge of the storage.
oak-core on the other hand is our main validation and consistency
layer that asserts that modifications made through the JCR API
or directly on the SPI layer (remember that we may have other
non-JCR clients on top of it)... this includes the ability to
distinguish workspaces, node types, different types of items
such as ac-data, regular content, user-related content an so
forth even if in the persistent layer they just all look like
the same.
> Anyway, I'd rather keep the oak-mk reference as is for now [...]
i'd rather like to get rid of it as soon as possible.
the longer we keep oak-mk on the higher levels the hard it
will be to come up with a reasonable abstraction.
kind regards
angela
Re: oak api : initial draft
Posted by Jukka Zitting <ju...@gmail.com>.
Hi,
On Wed, Mar 28, 2012 at 9:13 PM, Michael Dürig <md...@apache.org> wrote:
> - Is it possible to open multiple Connection instances with one SessionInfo?
> What would be the purpose of this? Can I commit a NodeState created with a
> NodeBuilder from one Connection into another Connection?
>
> - Wouldn't it be simpler and sufficient to have a 1:1 relationship between
> SessionInfo and Connection? Again: can I commit a NodeState created with a
> NodeBuilder from one Connection into another Connection (from another
> SessionInfo in this case)?
I think it would make sense to merge SessionInfo and Connection to a
singe interface. The main reason we didn't do that yet is the handling
of credentials and session attributes (i.e. as a way for custom
authentication components to pass information back and forth across
the API) that felt out of place in Connection. I'd rather get rid of
session attributes entirely at this level (and use the JAAS model for
any across-the-stack communcation), but I think we need to keep it for
now for compatibility with existing authentication components designed
for Jackrabbit 2.x.
Anyway, having thought about this a bit more, I'd support merging
SessionInfo and Connection to a single Connection (or some other
similarly named) interface.
> - Do we want to make any guarantees wrt. thread safety on Connection?
I don't see a strong use case where we'd need thread-safety at this
level. Unless we come up with one, I suggest we don't make such
guarantees on Connection level.
> - Having NodeState and NodeBuilder in the oak-core API currently introduces
> a dependency on oak-mk for clients of that API. We should probably move the
> interfaces which are used across the stack to some common location.
Right. This would be a non-issue if we hadn't split oak-core apart...
Anyway, I'd rather keep the oak-mk reference as is for now until we
encounter a case of why we'd truly need a different tree model on the
oak-core level. For example the CoreValue class that Thomas now has
for the query code might well be something that we need to consider
also from an API perspective.
BR,
Jukka Zitting
Re: oak api : initial draft
Posted by Michael Dürig <md...@apache.org>.
Hi,
Some more things that crossed my mind:
- Is it possible to open multiple Connection instances with one
SessionInfo? What would be the purpose of this? Can I commit a NodeState
created with a NodeBuilder from one Connection into another Connection?
- Wouldn't it be simpler and sufficient to have a 1:1 relationship
between SessionInfo and Connection? Again: can I commit a NodeState
created with a NodeBuilder from one Connection into another Connection
(from another SessionInfo in this case)?
- Do we want to make any guarantees wrt. thread safety on Connection?
- Having NodeState and NodeBuilder in the oak-core API currently
introduces a dependency on oak-mk for clients of that API. We should
probably move the interfaces which are used across the stack to some
common location.
- ... probably more to come ;-)
Michael
On 28.3.12 15:11, Angela Schreiber wrote:
> hi all
>
> jukka and myself just were sitting together to define an very
> first draft of the oak-api just to have something to start with
> and to have a basis for further discussions.
>
> i will commit it as soon as i run the build without error.
>
> it will consist of an initial Service that provides
> - login providing a sessioninfo
> - ability to retrieve a Connection for that sessioninfo
>
> the Connection (still to be defined it this represent a workspace
> or the whole repository) would then give access to node states (based
> on permissions for the session associated with it), be in charge
> of validating changes to be committed and executing queries.
>
> will doing so we still had a lot of open questions some of which
> are marked as todos in the interfaces.
>
> feedback is welcome
>
> regards
> angela
>
> On 3/28/12 3:50 PM, Michael Dürig wrote:
>>
>>
>> On 28.3.12 14:27, Thomas Mueller wrote:
>>> Hi,
>>>
>>>> Could you come up with an implementation which does not directly depend
>>>> on the Microkernel but rather uses a (to be defined) API on oak-core?
>>>
>>> Sure, let's define such an API.
>>
>> I'll try to come up with some ideas later today. Need to get a clearer
>> picture for myself first.
>>
>>>
>>>> I'm in the process of removing all dependencies from oak-jcr to oak-mk
>>>> (OAK-20) so this will ultimately break.
>>>
>>> Sure. What I used is a temporary workaround, this is not meant to
>>> stay as
>>> it is.
>>
>> Ok great.
>>
>> Michael
>>
>>>
>>> Regards,
>>> Thomas
>>>
Re: oak api : initial draft
Posted by Angela Schreiber <an...@adobe.com>.
hi michi
just as an additional side note:
the conversation between jukka and myself also included some
first ideas on how a given repository is being created,
who is being in charge of the initial setup and creating the
mk and the service instance and how once the repository
exists a new instance of the JCR repository is being retrieved
from the factory.
jukka promised to work on this such that we will soon be able
to get a clearer picture here as this basically has an impact
on everything related to oak-jcr and oak-core.
kind regards
angela
On 3/28/12 4:58 PM, Michael Dürig wrote:
>
> Great! I was just about to start working on this since this is also a
> prerequisite for getting OAK-20 resolved. I'll have a look at the draft
> and let you know.
>
> Michael
>
> On 28.3.12 15:11, Angela Schreiber wrote:
>> hi all
>>
>> jukka and myself just were sitting together to define an very
>> first draft of the oak-api just to have something to start with
>> and to have a basis for further discussions.
>>
>> i will commit it as soon as i run the build without error.
>>
>> it will consist of an initial Service that provides
>> - login providing a sessioninfo
>> - ability to retrieve a Connection for that sessioninfo
>>
>> the Connection (still to be defined it this represent a workspace
>> or the whole repository) would then give access to node states (based
>> on permissions for the session associated with it), be in charge
>> of validating changes to be committed and executing queries.
>>
>> will doing so we still had a lot of open questions some of which
>> are marked as todos in the interfaces.
>>
>> feedback is welcome
>>
>> regards
>> angela
>>
>> On 3/28/12 3:50 PM, Michael Dürig wrote:
>>>
>>>
>>> On 28.3.12 14:27, Thomas Mueller wrote:
>>>> Hi,
>>>>
>>>>> Could you come up with an implementation which does not directly depend
>>>>> on the Microkernel but rather uses a (to be defined) API on oak-core?
>>>>
>>>> Sure, let's define such an API.
>>>
>>> I'll try to come up with some ideas later today. Need to get a clearer
>>> picture for myself first.
>>>
>>>>
>>>>> I'm in the process of removing all dependencies from oak-jcr to oak-mk
>>>>> (OAK-20) so this will ultimately break.
>>>>
>>>> Sure. What I used is a temporary workaround, this is not meant to
>>>> stay as
>>>> it is.
>>>
>>> Ok great.
>>>
>>> Michael
>>>
>>>>
>>>> Regards,
>>>> Thomas
>>>>
Re: oak api : initial draft
Posted by Michael Dürig <md...@apache.org>.
Great! I was just about to start working on this since this is also a
prerequisite for getting OAK-20 resolved. I'll have a look at the draft
and let you know.
Michael
On 28.3.12 15:11, Angela Schreiber wrote:
> hi all
>
> jukka and myself just were sitting together to define an very
> first draft of the oak-api just to have something to start with
> and to have a basis for further discussions.
>
> i will commit it as soon as i run the build without error.
>
> it will consist of an initial Service that provides
> - login providing a sessioninfo
> - ability to retrieve a Connection for that sessioninfo
>
> the Connection (still to be defined it this represent a workspace
> or the whole repository) would then give access to node states (based
> on permissions for the session associated with it), be in charge
> of validating changes to be committed and executing queries.
>
> will doing so we still had a lot of open questions some of which
> are marked as todos in the interfaces.
>
> feedback is welcome
>
> regards
> angela
>
> On 3/28/12 3:50 PM, Michael Dürig wrote:
>>
>>
>> On 28.3.12 14:27, Thomas Mueller wrote:
>>> Hi,
>>>
>>>> Could you come up with an implementation which does not directly depend
>>>> on the Microkernel but rather uses a (to be defined) API on oak-core?
>>>
>>> Sure, let's define such an API.
>>
>> I'll try to come up with some ideas later today. Need to get a clearer
>> picture for myself first.
>>
>>>
>>>> I'm in the process of removing all dependencies from oak-jcr to oak-mk
>>>> (OAK-20) so this will ultimately break.
>>>
>>> Sure. What I used is a temporary workaround, this is not meant to
>>> stay as
>>> it is.
>>
>> Ok great.
>>
>> Michael
>>
>>>
>>> Regards,
>>> Thomas
>>>
Re: oak api : initial draft
Posted by Michael Dürig <md...@apache.org>.
On 29.3.12 11:09, Angela Schreiber wrote:
> hi michi
>
>>> furthermore, having slept over the 'Connection' interface i am not
>>> so confident any more that it's name really fits the purpose
>>> that i was looking for... for me 'Connection' sounds very
>>> vague. i am fine with that for the time being as we are still
>>> very vague and just need something to get started. but i in the
>>> long run this may need some refinement.
>>
>> I quite like the name Connection and the idea of merging it with
>> SessionInfo and have the Connection provide access to some AuthInfo. To
>> me SessionInfo sounds vague ;-) Anyhow, I attached a patch to OAK-18
>> demonstrating my line of thinking.
>
> AuthInfo or SessionInfo... both fine with me.
> similarly i can live with that info being exposed from the Connection
> and that latter being Closeable.
>
> feel free to apply the patch. i think it's important that we play
> around with draft code, get a feeling if the pros and cons while using
> it. and last but not least changing each others draft code will help
> us become familiar with each others code and reach consensus on
> how to built that oak-api (that's my feeling).
Ok, I committed the patch at revision 1306779. I think this resolves the
question regarding multiple connections since now you need to do a login
on RepositoryService to obtain a Connection whereas before you could
obtain as many connections as you wanted from a SessionInfo.
Michael
Re: oak api : initial draft
Posted by Angela Schreiber <an...@adobe.com>.
hi michi
>> furthermore, having slept over the 'Connection' interface i am not
>> so confident any more that it's name really fits the purpose
>> that i was looking for... for me 'Connection' sounds very
>> vague. i am fine with that for the time being as we are still
>> very vague and just need something to get started. but i in the
>> long run this may need some refinement.
>
> I quite like the name Connection and the idea of merging it with
> SessionInfo and have the Connection provide access to some AuthInfo. To
> me SessionInfo sounds vague ;-) Anyhow, I attached a patch to OAK-18
> demonstrating my line of thinking.
AuthInfo or SessionInfo... both fine with me.
similarly i can live with that info being exposed from the Connection
and that latter being Closeable.
feel free to apply the patch. i think it's important that we play
around with draft code, get a feeling if the pros and cons while using
it. and last but not least changing each others draft code will help
us become familiar with each others code and reach consensus on
how to built that oak-api (that's my feeling).
kind
regards
angela
Re: oak api : initial draft
Posted by Michael Dürig <md...@apache.org>.
>> Assuming we merge SessionInfo and Connection together
>
> for the time being i would like to keep it separated as
> from my point of view the result of login to the repository
> was something different than operating on the data
> contained therein.
>
> furthermore, having slept over the 'Connection' interface i am not
> so confident any more that it's name really fits the purpose
> that i was looking for... for me 'Connection' sounds very
> vague. i am fine with that for the time being as we are still
> very vague and just need something to get started. but i in the
> long run this may need some refinement.
I quite like the name Connection and the idea of merging it with
SessionInfo and have the Connection provide access to some AuthInfo. To
me SessionInfo sounds vague ;-) Anyhow, I attached a patch to OAK-18
demonstrating my line of thinking.
Michael
Re: oak api : initial draft
Posted by Michael Dürig <md...@apache.org>.
On 29.3.12 11:20, Angela Schreiber wrote:
> hi michi
>
>>> i am not sure if we can really easily implement things like workspace
>>> management: for example creating a new workspace needs some initial
>>> workspace setup (creating the root node, initial permissions, users) and
>>> i doubt that oak-jcr was the right place to do that.
>>>
>> What about an solution which covers both, workspace bound connections
>> and repository bound connections? In such a setup you'd get a workspace
>> bound connection from the RepositoryService and you could get a
>> Repository bound connection from the a given Connection. The latter
>> could then be used for cross workspace operations.
>
> why not... let's give it a try.
> but let's keep the following aspects in mind:
I added this in revision 1306786 and 1306787. However we might want to
further refine this into a WorkspaceConnection and a
RepositoryConnection in case it turns out that too many of the methods
on Connection don't make sense for both. But for the time being let of
with this and see if it works at all.
Michael
>
> - the oak-api boundary has to offer the ability for remoting in
> some way or the other.
> - the oak-api implementation (oak-core) should be responsible for
> all the consistency checks and overall system security.
> - how does it feel from a API design perspective that the oak-api
> will expose versioning methods, query, possibly locking. there
> needs also be some sort of 'hasPermission' check...
>
> we will hopefully see pretty soon if that works and if the API
> looks consistent and complete.
>
> regards
> angela
>
Re: oak api : initial draft
Posted by Angela Schreiber <an...@adobe.com>.
hi michi
>> i am not sure if we can really easily implement things like workspace
>> management: for example creating a new workspace needs some initial
>> workspace setup (creating the root node, initial permissions, users) and
>> i doubt that oak-jcr was the right place to do that.
>>
> What about an solution which covers both, workspace bound connections
> and repository bound connections? In such a setup you'd get a workspace
> bound connection from the RepositoryService and you could get a
> Repository bound connection from the a given Connection. The latter
> could then be used for cross workspace operations.
why not... let's give it a try.
but let's keep the following aspects in mind:
- the oak-api boundary has to offer the ability for remoting in
some way or the other.
- the oak-api implementation (oak-core) should be responsible for
all the consistency checks and overall system security.
- how does it feel from a API design perspective that the oak-api
will expose versioning methods, query, possibly locking. there
needs also be some sort of 'hasPermission' check...
we will hopefully see pretty soon if that works and if the API
looks consistent and complete.
regards
angela
Re: oak api : initial draft
Posted by Michael Dürig <md...@apache.org>.
>>>> in this case the session info was already bound to a given workspace
>>>> and subsequently the Connection was bound to that workspace as well.
>>>
>>> Yes that was my initial thinking too. That would mean the connections
>>> are
>>> bound to a workspace. And workspaces (and workspace management) would
>>> have
>>> to be exposed somehow through the oak API.
>
> yes... somehow that was my idea as well. and i am not convinced
> that mixing the repository-workspace concept on the oak-api was
> the right way to go... currently this is more of a gut feeling
> with some individual concerns popping up here and there.
>
>> I'm a bit hesitant about this. It basically means that all
>> cross-workspace operations will need custom API calls. If we make the
>> login call per-repository and treat workspaces more or less just as a
>> convention on the content structure, then oak-jcr can easily implement
>> things like workspace management, etc. with no extra API or support
>> from the oak-core level.
>
> i am not sure if we can really easily implement things like workspace
> management: for example creating a new workspace needs some initial
> workspace setup (creating the root node, initial permissions, users) and
> i doubt that oak-jcr was the right place to do that.
>
What about an solution which covers both, workspace bound connections
and repository bound connections? In such a setup you'd get a workspace
bound connection from the RepositoryService and you could get a
Repository bound connection from the a given Connection. The latter
could then be used for cross workspace operations.
Michael
Re: oak api : initial draft
Posted by Jukka Zitting <ju...@gmail.com>.
Hi,
On Thu, Mar 29, 2012 at 11:00 AM, Angela Schreiber <an...@adobe.com> wrote:
> furthermore, having slept over the 'Connection' interface i am not
> so confident any more that it's name really fits the purpose
> that i was looking for... for me 'Connection' sounds very
> vague. i am fine with that for the time being as we are still
> very vague and just need something to get started. but i in the
> long run this may need some refinement.
Agreed. "Connection" is just something I borrowed from JDBC for lack
of a better term. I think we should avoid overloading the "Session"
term to prevent confusion with the JCR interface, so something else
that indicates an authenticated repository (or workspace) access point
would be nice. "(Repository)Handle"?
BR,
Jukka Zitting
Re: oak api : initial draft
Posted by Angela Schreiber <an...@adobe.com>.
hi
> Assuming we merge SessionInfo and Connection together
for the time being i would like to keep it separated as
from my point of view the result of login to the repository
was something different than operating on the data
contained therein.
furthermore, having slept over the 'Connection' interface i am not
so confident any more that it's name really fits the purpose
that i was looking for... for me 'Connection' sounds very
vague. i am fine with that for the time being as we are still
very vague and just need something to get started. but i in the
long run this may need some refinement.
>>> in this case the session info was already bound to a given workspace
>>> and subsequently the Connection was bound to that workspace as well.
>>
>> Yes that was my initial thinking too. That would mean the connections are
>> bound to a workspace. And workspaces (and workspace management) would have
>> to be exposed somehow through the oak API.
yes... somehow that was my idea as well. and i am not convinced
that mixing the repository-workspace concept on the oak-api was
the right way to go... currently this is more of a gut feeling
with some individual concerns popping up here and there.
> I'm a bit hesitant about this. It basically means that all
> cross-workspace operations will need custom API calls. If we make the
> login call per-repository and treat workspaces more or less just as a
> convention on the content structure, then oak-jcr can easily implement
> things like workspace management, etc. with no extra API or support
> from the oak-core level.
i am not sure if we can really easily implement things like workspace
management: for example creating a new workspace needs some initial
workspace setup (creating the root node, initial permissions, users) and
i doubt that oak-jcr was the right place to do that.
> If the only reason why we need to expose the workspace concept at this
> level is to support potentially separate users per each workspace,
> then I'd rather handle that with a virtual repository mechanism that
> just connects to a separate underlying repository instance for each
> requested workspace.
well, didn't we decide at the last f2f that we are not going to
implement a virtual repository mechanism? for me that proposal
generates quite some question marks. having users being represented
as regular items in a given workspace feels very natural to me and
it has proven to fit our needs very well.
kind regards
angela
Re: oak api : initial draft
Posted by Thomas Mueller <mu...@adobe.com>.
Hi,
>>Commit failure is an "expected" error condition in the sense that I
>> can write client code that I can expect to always produce a failed
>> commit.
Just for completeness, could you give an example?
>For this reason l would prefer to extend from RuntimeException only.
Me too.
Regards,
Thomas
Re: oak api : initial draft
Posted by Michael Dürig <mi...@gmail.com>.
On Mar 28, 2012 9:27 PM, "Jukka Zitting" <ju...@gmail.com> wrote:
>
> Hi,
>
> On Wed, Mar 28, 2012 at 8:52 PM, Michael Dürig <md...@apache.org> wrote:
> >> well, i am quite sure that i need it once i have a real
> >> authentication mechanism associated with it. and once a session
> >> is logged out i would like to make sure that the session info
> >> associated with it is aware of this.
> >
> > Ok that makes send. Let's keep it then.
>
> Assuming we merge SessionInfo and Connection together, I suggest we
> make the resulting interface extend Closeable instead of having a
> custom dispose() method.
>
> >> may take on this was the following: right now i plan to have
> >> the RepositoryService#login to take the workspace name into account
> >> as imo the user/groups should continue to be defined on a workspace
> >> level (or at least that should be possible).
> >>
> >> in this case the session info was already bound to a given workspace
> >> and subsequently the Connection was bound to that workspace as well.
> >
> > Yes that was my initial thinking too. That would mean the connections
are
> > bound to a workspace. And workspaces (and workspace management) would
have
> > to be exposed somehow through the oak API.
>
> I'm a bit hesitant about this. It basically means that all
> cross-workspace operations will need custom API calls. If we make the
> login call per-repository and treat workspaces more or less just as a
> convention on the content structure, then oak-jcr can easily implement
> things like workspace management, etc. with no extra API or support
> from the oak-core level.
>
> If the only reason why we need to expose the workspace concept at this
> level is to support potentially separate users per each workspace,
> then I'd rather handle that with a virtual repository mechanism that
> just connects to a separate underlying repository instance for each
> requested workspace. I don't think we have too many existing
> deployments where different workspaces are a) used in the first place,
> or b) have separate sets of associated user accounts.
>
> > If we can live with the JCR dependency in oak-core, then I'm fine with
the
> > first approach. That is, use a nested jcr exception. However, I think we
> > should not make CommitFailedException extend RepositoryException but
rather
> > make it extend RuntimeException.
>
> Commit failure is an "expected" error condition in the sense that I
> can write client code that I can expect to always produce a failed
> commit. There are also cases where a client can be expected to recover
> from a failed commit, for example by using some application-level
> algorithm to resolve merge conflicts or constraint violations. Thus I
> think this situation should be handled either as an explicit return
> value or a checked exception. In this case (the commit() signature as
> drafted) a checked exception seems to me like the most natural choice.
Yes I know this has been standard Java practise for long. However it
introduces more troubles than its worth: some methods on the call tree
might neither be able to meaningfully handle nor throw an exception. In
these cases you are left with two options: wrap into a RuntimeException
which makes the whole thing pointless or log and ignore which might not
even be possible if you have to return a value.
For this reason l would prefer to extend from RuntimeException only.
Michael
> In contrast I'd reserve RuntimeExceptions to unexpected conditions
> that only occur at runtime. In other words I shouldn't be able to
> write an otherwise valid client application (i.e. no null arguments to
> methods that don't allow nulls) that I know in advance will cause an
> unchecked exception to be thrown from within the repository
> implementation.
>
> BR,
>
> Jukka Zitting
Re: oak api : initial draft
Posted by Jukka Zitting <ju...@gmail.com>.
Hi,
On Wed, Mar 28, 2012 at 8:52 PM, Michael Dürig <md...@apache.org> wrote:
>> well, i am quite sure that i need it once i have a real
>> authentication mechanism associated with it. and once a session
>> is logged out i would like to make sure that the session info
>> associated with it is aware of this.
>
> Ok that makes send. Let's keep it then.
Assuming we merge SessionInfo and Connection together, I suggest we
make the resulting interface extend Closeable instead of having a
custom dispose() method.
>> may take on this was the following: right now i plan to have
>> the RepositoryService#login to take the workspace name into account
>> as imo the user/groups should continue to be defined on a workspace
>> level (or at least that should be possible).
>>
>> in this case the session info was already bound to a given workspace
>> and subsequently the Connection was bound to that workspace as well.
>
> Yes that was my initial thinking too. That would mean the connections are
> bound to a workspace. And workspaces (and workspace management) would have
> to be exposed somehow through the oak API.
I'm a bit hesitant about this. It basically means that all
cross-workspace operations will need custom API calls. If we make the
login call per-repository and treat workspaces more or less just as a
convention on the content structure, then oak-jcr can easily implement
things like workspace management, etc. with no extra API or support
from the oak-core level.
If the only reason why we need to expose the workspace concept at this
level is to support potentially separate users per each workspace,
then I'd rather handle that with a virtual repository mechanism that
just connects to a separate underlying repository instance for each
requested workspace. I don't think we have too many existing
deployments where different workspaces are a) used in the first place,
or b) have separate sets of associated user accounts.
> If we can live with the JCR dependency in oak-core, then I'm fine with the
> first approach. That is, use a nested jcr exception. However, I think we
> should not make CommitFailedException extend RepositoryException but rather
> make it extend RuntimeException.
Commit failure is an "expected" error condition in the sense that I
can write client code that I can expect to always produce a failed
commit. There are also cases where a client can be expected to recover
from a failed commit, for example by using some application-level
algorithm to resolve merge conflicts or constraint violations. Thus I
think this situation should be handled either as an explicit return
value or a checked exception. In this case (the commit() signature as
drafted) a checked exception seems to me like the most natural choice.
In contrast I'd reserve RuntimeExceptions to unexpected conditions
that only occur at runtime. In other words I shouldn't be able to
write an otherwise valid client application (i.e. no null arguments to
methods that don't allow nulls) that I know in advance will cause an
unchecked exception to be thrown from within the repository
implementation.
BR,
Jukka Zitting
Re: oak api : initial draft
Posted by Michael Dürig <md...@apache.org>.
>> SessionInfo.dispose(): do we need this? To me SessionInfo looks like a
>> state less data object (i.e. a value) carrying information related to a
>> user's session.
>
> well, i am quite sure that i need it once i have a real
> authentication mechanism associated with it. and once a session
> is logged out i would like to make sure that the session info
> associated with it is aware of this.
Ok that makes send. Let's keep it then.
>> Whether a Connection is repository bound or bound to a single workspace
>> depends on whether we want to expose the concept of a workspace through
>> the oak API or whether the oak API should rather expose a tree and we
>> decorate workspaces on top in oak-jcr. Maybe thinking of the other
>> bindings for the oak API gives us a better clue.
>
> may take on this was the following: right now i plan to have
> the RepositoryService#login to take the workspace name into account
> as imo the user/groups should continue to be defined on a workspace
> level (or at least that should be possible).
>
> in this case the session info was already bound to a given workspace
> and subsequently the Connection was bound to that workspace as well.
Yes that was my initial thinking too. That would mean the connections
are bound to a workspace. And workspaces (and workspace management)
would have to be exposed somehow through the oak API.
> similarly i don't think that oak-jcr should be in charge of defining
> what the default workspace name was. imo that was the responsibility
> of the overall repository setup process that would imo reside somewhere
> in oak-core.
Right.
>
>> CommitFailedException (mechanism to inform the oak-jcr level about the
>> specific type of exception):
>> - nested jcr exception: this would create a dependency of oak-core on
>> jcr which we might want to avoid.
>
> well, yes. but i am not yet totally sure if we can avoid it.
>
>> - extends RepositoryException: same as above but much worse: checked
>> exceptions don't compose. That is, we'll get into lot of problems being
>> forced to handle these exceptions in implementations of interfaces which
>> do not allow exceptions to be thrown (Iterator.next, Comperator.compare,
>> ...).
>> - Status code: I think this is the way to go. I'd include the status
>> code as an enum in the exception.
>
> as far as i am concerned i dislike using a status code when in fact
> i encounter an exceptional state. why shouldn't i throw
> AccessDeniedException right away when i find a permission violation
> upon validating a given write operation in oak-core? having a status
> code and then relying that oak-jcr is making the right lookup and
> really is raising the exception looks a bit odd and error-prone to me.
If we can live with the JCR dependency in oak-core, then I'm fine with
the first approach. That is, use a nested jcr exception. However, I
think we should not make CommitFailedException extend
RepositoryException but rather make it extend RuntimeException.
Michael
>
> kind regards
> angela
>
Re: oak api : initial draft
Posted by Angela Schreiber <an...@adobe.com>.
hi michi
ui, that was fast :)
> SessionInfo.dispose(): do we need this? To me SessionInfo looks like a
> state less data object (i.e. a value) carrying information related to a
> user's session.
well, i am quite sure that i need it once i have a real
authentication mechanism associated with it. and once a session
is logged out i would like to make sure that the session info
associated with it is aware of this.
> Whether a Connection is repository bound or bound to a single workspace
> depends on whether we want to expose the concept of a workspace through
> the oak API or whether the oak API should rather expose a tree and we
> decorate workspaces on top in oak-jcr. Maybe thinking of the other
> bindings for the oak API gives us a better clue.
may take on this was the following: right now i plan to have
the RepositoryService#login to take the workspace name into account
as imo the user/groups should continue to be defined on a workspace
level (or at least that should be possible).
in this case the session info was already bound to a given workspace
and subsequently the Connection was bound to that workspace as well.
similarly i don't think that oak-jcr should be in charge of defining
what the default workspace name was. imo that was the responsibility
of the overall repository setup process that would imo reside somewhere
in oak-core.
> CommitFailedException (mechanism to inform the oak-jcr level about the
> specific type of exception):
> - nested jcr exception: this would create a dependency of oak-core on
> jcr which we might want to avoid.
well, yes. but i am not yet totally sure if we can avoid it.
> - extends RepositoryException: same as above but much worse: checked
> exceptions don't compose. That is, we'll get into lot of problems being
> forced to handle these exceptions in implementations of interfaces which
> do not allow exceptions to be thrown (Iterator.next, Comperator.compare,
> ...).
> - Status code: I think this is the way to go. I'd include the status
> code as an enum in the exception.
as far as i am concerned i dislike using a status code when in fact
i encounter an exceptional state. why shouldn't i throw
AccessDeniedException right away when i find a permission violation
upon validating a given write operation in oak-core? having a status
code and then relying that oak-jcr is making the right lookup and
really is raising the exception looks a bit odd and error-prone to me.
kind regards
angela
Re: oak api : initial draft
Posted by Michael Dürig <md...@apache.org>.
Hi,
Some initial comments to the API draft below:
SessionInfo.dispose(): do we need this? To me SessionInfo looks like a
state less data object (i.e. a value) carrying information related to a
user's session. I think we should try to not associate any resources to
be disposed with this. These should go into Connection. That is, I'd
remove the dispose() method initially and add them back later on when we
have a compelling reason to do so.
Whether a Connection is repository bound or bound to a single workspace
depends on whether we want to expose the concept of a workspace through
the oak API or whether the oak API should rather expose a tree and we
decorate workspaces on top in oak-jcr. Maybe thinking of the other
bindings for the oak API gives us a better clue.
CommitFailedException (mechanism to inform the oak-jcr level about the
specific type of exception):
- nested jcr exception: this would create a dependency of oak-core on
jcr which we might want to avoid.
- extends RepositoryException: same as above but much worse: checked
exceptions don't compose. That is, we'll get into lot of problems being
forced to handle these exceptions in implementations of interfaces which
do not allow exceptions to be thrown (Iterator.next, Comperator.compare,
...).
- Status code: I think this is the way to go. I'd include the status
code as an enum in the exception.
Michael
On 28.3.12 15:11, Angela Schreiber wrote:
> hi all
>
> jukka and myself just were sitting together to define an very
> first draft of the oak-api just to have something to start with
> and to have a basis for further discussions.
>
> i will commit it as soon as i run the build without error.
>
> it will consist of an initial Service that provides
> - login providing a sessioninfo
> - ability to retrieve a Connection for that sessioninfo
>
> the Connection (still to be defined it this represent a workspace
> or the whole repository) would then give access to node states (based
> on permissions for the session associated with it), be in charge
> of validating changes to be committed and executing queries.
>
> will doing so we still had a lot of open questions some of which
> are marked as todos in the interfaces.
>
> feedback is welcome
>
> regards
> angela
>
> On 3/28/12 3:50 PM, Michael Dürig wrote:
>>
>>
>> On 28.3.12 14:27, Thomas Mueller wrote:
>>> Hi,
>>>
>>>> Could you come up with an implementation which does not directly depend
>>>> on the Microkernel but rather uses a (to be defined) API on oak-core?
>>>
>>> Sure, let's define such an API.
>>
>> I'll try to come up with some ideas later today. Need to get a clearer
>> picture for myself first.
>>
>>>
>>>> I'm in the process of removing all dependencies from oak-jcr to oak-mk
>>>> (OAK-20) so this will ultimately break.
>>>
>>> Sure. What I used is a temporary workaround, this is not meant to
>>> stay as
>>> it is.
>>
>> Ok great.
>>
>> Michael
>>
>>>
>>> Regards,
>>> Thomas
>>>
Re: oak api : initial draft
Posted by Jukka Zitting <ju...@gmail.com>.
Hi,
On Tue, Apr 10, 2012 at 12:20 PM, Felix Meschberger <fm...@adobe.com> wrote:
> Am 30.03.2012 um 16:15 schrieb Jukka Zitting:
>> Do you have a concrete example in mind?
>
> When using the Jackrabbit file based API to load node types from CND files, there is
> generic exception thrown in most cases. This is nasty since I want to handle the case
> of missing required node type (e.g. an extended base type) and duplicate node type
> differently -- maybe even ignoring them in some cases.
Hmm, when you said "there should be a root exception" in the thread
earlier, were you referring to using the "root cause" exception as a
part of the API or a "base class" exception like the
RepositoryException in JCR? The above case sounds more like the
former, while my original interpretation of your words was the latter.
BR,
Jukka Zitting
Re: oak api : initial draft
Posted by Felix Meschberger <fm...@adobe.com>.
Hi,
Am 30.03.2012 um 16:15 schrieb Jukka Zitting:
> Hi,
>
> On Thu, Mar 29, 2012 at 6:24 PM, Felix Meschberger <fm...@adobe.com> wrote:
>> Well, if I cannot do anything about the exception, this is a sure sign
>> for a RuntimeException. But I might still want to catch them regardless
>> of the actual detail and do something about it.
>
> Do you have a concrete example in mind?
When using the Jackrabbit file based API to load node types from CND files, there is generic exception thrown in most cases. This is nasty since I want to handle the case of missing required node type (e.g. an extended base type) and duplicate node type differently -- maybe even ignoring them in some cases.
The only solution in this case was to analze the actual exception message ...
Regards
Felix
Re: oak api : initial draft
Posted by Jukka Zitting <ju...@gmail.com>.
Hi,
On Thu, Mar 29, 2012 at 6:24 PM, Felix Meschberger <fm...@adobe.com> wrote:
> Well, if I cannot do anything about the exception, this is a sure sign
> for a RuntimeException. But I might still want to catch them regardless
> of the actual detail and do something about it.
Do you have a concrete example in mind?
BR,
Jukka Zitting
Re: oak api : initial draft
Posted by Felix Meschberger <fm...@adobe.com>.
Hi,
Am 29.03.2012 um 11:55 schrieb Jukka Zitting:
>> (6) CommitFailedException is a checked exception. Do we really want this?
>
> I do, but others disagree. To be discussed.
>
>> In addition, we said, there should be a root exception, right ?
>
> Why? This is a specific, strongly typed part of the commit() signature
> as drafted. I don't (yet) see a need for it to be related to any other
> exception in the API.
>
> Most notably I don't see much need for a generic "Oak-" or
> "RepositoryException" that a client can't do anything reasonable with.
> Let's just use RuntimeException for such cases.
Well, if I cannot do anything about the exception, this is a sure sign for a RuntimeException. But I might still want to catch them regardless of the actual detail and do something about it. Having a common root exception here helps tremendously. Otherwise I would have to catch all sorts of exceptions and replicate the same actions.
Having a common root exception does not hurt the implementation but helps the user.
Regards
Felix
Re: oak api : initial draft
Posted by Jukka Zitting <ju...@gmail.com>.
Hi,
On Thu, Mar 29, 2012 at 5:38 PM, Felix Meschberger <fm...@adobe.com> wrote:
> (0) I assume the API is just the 4 classes in the oak.api package, right ?
.oak.api is the place, yes. As you noticed, the API currently
references also interfaces in .mk.model, but that's to be fixed.
> (2) The credentials to the RepositoryService (or ConnectionFactory) are a
> plain Object. I understand that this is just slightly lighter than the JCR
> Credentials. But since all credentials will probably always come with at
> least a User name we might want to create a proper Object to supply the
> user name and stipulate more credential detail.
>
> (3) The connection factory method in the RepositoryService (or
> ConnectionFactory) is not usable for multi-factor authentication where
> a challenge may be sent to the client to be replied to. Is this by intent?
> Do we want to support such multi-step authentication on this level or
> not? I understand the JCR spec does not support it either and pushing
> such a challenge back from Oak through the JCR API is a challenge
> in itself.
All that stuff should IMHO be handled through the standard JAAS
mechanism. As mentioned in my earlier email, I dislike even passing
explicit credentials objects or session attributes across the Oak API
(that should all be handled by JAAS), but for compatibility with
existing authentication components based on Jackrabbit 2.x we probably
need to keep credentials and session attributes as opaque Objects in
the API.
> (4) The Connection provides access to o.a.j.mk.model objects
> (NodeState, NodeBuilder).
As discussed, this is a topic that still needs to be resolved. We're
using the .mk.model interfaces for now to avoid simply duplicating
them.
> (6) CommitFailedException is a checked exception. Do we really want this?
I do, but others disagree. To be discussed.
> In addition, we said, there should be a root exception, right ?
Why? This is a specific, strongly typed part of the commit() signature
as drafted. I don't (yet) see a need for it to be related to any other
exception in the API.
Most notably I don't see much need for a generic "Oak-" or
"RepositoryException" that a client can't do anything reasonable with.
Let's just use RuntimeException for such cases.
BR,
Juka Zitting
Re: oak api : initial draft
Posted by Felix Meschberger <fm...@adobe.com>.
Hi
Thanks for this.
Some notes from my part:
(0) I assume the API is just the 4 classes in the oak.api package, right ?
(1) I understand the RepositoryService is the single access point into Oak "from the outside" which is fine. Still I think the name "RepositoryService" sounds wrong to me. Rather it looks like a ConnectionFactory: You feed some credentials and you get back a connection.
(2) The credentials to the RepositoryService (or ConnectionFactory) are a plain Object. I understand that this is just slightly lighter than the JCR Credentials. But since all credentials will probably always come with at least a User name we might want to create a proper Object to supply the user name and stipulate more credential detail.
(3) The connection factory method in the RepositoryService (or ConnectionFactory) is not usable for multi-factor authentication where a challenge may be sent to the client to be replied to. Is this by intent ? Do we want to support such multi-step authentication on this level or not ? I understand the JCR spec does not support it either and pushing such a challenge back from Oak through the JCR API is a challenge in itself.
(4) The Connection provides access to o.a.j.mk.model objects (NodeState, NodeBuilder). This is not wrong per-se. In an OSGi environment where core and mk may be deployed as separate bundles, this means the mk.model package must be exported but this should not be exposing mk implementation detail.
(5) The AuthInfo returned form the Connection implies getting some information about the user. How about also using this AuthInfo actually as the credentials used to create the connection (along the lines of #3 above) ?
(6) CommitFailedException is a checked exception. Do we really want this ? In addition, we said, there should be a root exception, right ?
Regards
Felix
Am 28.03.2012 um 10:11 schrieb Angela Schreiber:
> hi all
>
> jukka and myself just were sitting together to define an very
> first draft of the oak-api just to have something to start with
> and to have a basis for further discussions.
>
> i will commit it as soon as i run the build without error.
>
> it will consist of an initial Service that provides
> - login providing a sessioninfo
> - ability to retrieve a Connection for that sessioninfo
>
> the Connection (still to be defined it this represent a workspace
> or the whole repository) would then give access to node states (based
> on permissions for the session associated with it), be in charge
> of validating changes to be committed and executing queries.
>
> will doing so we still had a lot of open questions some of which
> are marked as todos in the interfaces.
>
> feedback is welcome
>
> regards
> angela
>
> On 3/28/12 3:50 PM, Michael Dürig wrote:
>>
>>
>> On 28.3.12 14:27, Thomas Mueller wrote:
>>> Hi,
>>>
>>>> Could you come up with an implementation which does not directly depend
>>>> on the Microkernel but rather uses a (to be defined) API on oak-core?
>>>
>>> Sure, let's define such an API.
>>
>> I'll try to come up with some ideas later today. Need to get a clearer
>> picture for myself first.
>>
>>>
>>>> I'm in the process of removing all dependencies from oak-jcr to oak-mk
>>>> (OAK-20) so this will ultimately break.
>>>
>>> Sure. What I used is a temporary workaround, this is not meant to stay as
>>> it is.
>>
>> Ok great.
>>
>> Michael
>>
>>>
>>> Regards,
>>> Thomas
>>>
oak api : initial draft
Posted by Angela Schreiber <an...@adobe.com>.
hi all
jukka and myself just were sitting together to define an very
first draft of the oak-api just to have something to start with
and to have a basis for further discussions.
i will commit it as soon as i run the build without error.
it will consist of an initial Service that provides
- login providing a sessioninfo
- ability to retrieve a Connection for that sessioninfo
the Connection (still to be defined it this represent a workspace
or the whole repository) would then give access to node states (based
on permissions for the session associated with it), be in charge
of validating changes to be committed and executing queries.
will doing so we still had a lot of open questions some of which
are marked as todos in the interfaces.
feedback is welcome
regards
angela
On 3/28/12 3:50 PM, Michael Dürig wrote:
>
>
> On 28.3.12 14:27, Thomas Mueller wrote:
>> Hi,
>>
>>> Could you come up with an implementation which does not directly depend
>>> on the Microkernel but rather uses a (to be defined) API on oak-core?
>>
>> Sure, let's define such an API.
>
> I'll try to come up with some ideas later today. Need to get a clearer
> picture for myself first.
>
>>
>>> I'm in the process of removing all dependencies from oak-jcr to oak-mk
>>> (OAK-20) so this will ultimately break.
>>
>> Sure. What I used is a temporary workaround, this is not meant to stay as
>> it is.
>
> Ok great.
>
> Michael
>
>>
>> Regards,
>> Thomas
>>
Re: svn commit: r1306222 - in /jackrabbit/oak/trunk/oak-jcr/src:
main/java/org/apache/jackrabbit/oak/jcr/ main/java/org/apache/jackrabbit/oak/jcr/query/
test/java/org/apache/jackrabbit/oak/jcr/ test/java/org/apache/jackrabbit/oak/jcr/query/
Posted by Michael Dürig <md...@apache.org>.
On 28.3.12 14:27, Thomas Mueller wrote:
> Hi,
>
>> Could you come up with an implementation which does not directly depend
>> on the Microkernel but rather uses a (to be defined) API on oak-core?
>
> Sure, let's define such an API.
I'll try to come up with some ideas later today. Need to get a clearer
picture for myself first.
>
>> I'm in the process of removing all dependencies from oak-jcr to oak-mk
>> (OAK-20) so this will ultimately break.
>
> Sure. What I used is a temporary workaround, this is not meant to stay as
> it is.
Ok great.
Michael
>
> Regards,
> Thomas
>
Re: svn commit: r1306222 - in /jackrabbit/oak/trunk/oak-jcr/src:
main/java/org/apache/jackrabbit/oak/jcr/
main/java/org/apache/jackrabbit/oak/jcr/query/
test/java/org/apache/jackrabbit/oak/jcr/
test/java/org/apache/jackrabbit/oak/jcr/query/
Posted by Thomas Mueller <mu...@adobe.com>.
Hi,
>Could you come up with an implementation which does not directly depend
>on the Microkernel but rather uses a (to be defined) API on oak-core?
Sure, let's define such an API.
>I'm in the process of removing all dependencies from oak-jcr to oak-mk
>(OAK-20) so this will ultimately break.
Sure. What I used is a temporary workaround, this is not meant to stay as
it is.
Regards,
Thomas
Re: svn commit: r1306222 - in /jackrabbit/oak/trunk/oak-jcr/src:
main/java/org/apache/jackrabbit/oak/jcr/ main/java/org/apache/jackrabbit/oak/jcr/query/
test/java/org/apache/jackrabbit/oak/jcr/ test/java/org/apache/jackrabbit/oak/jcr/query/
Posted by Michael Dürig <md...@apache.org>.
Hi Tom,
On 28.3.12 10:11, thomasm@apache.org wrote:
> Author: thomasm
> Date: Wed Mar 28 09:11:39 2012
> New Revision: 1306222
>
> URL:http://svn.apache.org/viewvc?rev=1306222&view=rev
> Log:
> OAK-28 Query implementation (initial implementation of the relevant oak-jcr part)
[...]
> +/**
> + * The implementation of the corresponding JCR interface.
> + */
> +public class QueryManagerImpl implements QueryManager {
> +
> + private final QueryObjectModelFactoryImpl qomFactory = new QueryObjectModelFactoryImpl();
> + private final QueryEngine qe;
> +
> + public QueryManagerImpl(WorkspaceImpl workspace, SessionContext<SessionImpl> sessionContext) {
> + MicroKernel mk = sessionContext.getGlobalContext().getInstance(MicroKernel.class);
> + qe = new QueryEngine(mk);
> + }
> +
Could you come up with an implementation which does not directly depend
on the Microkernel but rather uses a (to be defined) API on oak-core?
I'm in the process of removing all dependencies from oak-jcr to oak-mk
(OAK-20) so this will ultimately break.
Michael