Hi, devs.
I would like to propose new QueryManager which will deprecate our
store.search(* methods
This proposal is based on Vincent ideas at
http://markmail.org/message/mjgg52coupsmfomg
and QueryManager from JCR v2
QueryManager is designed for low-level querying in Java code.
(QueryPlugin for high-level and velocity)
The main idea is support of multiple languages and easy to add new
languages. This is needed for JCRStore.
Here is interfaces:
public interface QueryManager {
Query createQuery(String statement, String language);
Query getNamedQuery(String qname);
String[] getLanguages();
boolean hasLanguage(String language);
}
public interface Query {
enum Language {
HQL,
XPATH,
JCRSQL
}
<T> List<T> execute();
Query bindValue(String var, Object val);
Query setLimit(int limit);
Query setOffset(int offset);
}
Here is abstract usecase:
QueryManager qm = xwiki.getStore().getQueryManager();
Query q = qm.getNamedQuery("SomeNameOfQuery");
if (q==null && qm.hasLanguage(Query.Language.HQL.name())) {
q = qm.createQuery("from XWikiDocument where author=:var",
Language.HQL.name());
} else if (q==null && qm.hasLanguage(Language.XPATH.name())) {
q = qm.createQuery("/*/*[@author=:var]", Language.XPATH.name());
} else
throw new RuntimeException();
List<XWikiDocument> res = q.setLimit(10).setOffset(10)
.bindValue("var", "Some.Author").execute();
notes:
I'm not sure we need getNamedQuery right now. But it can be useful for
move some complicated queries to store level (to some QueryHolders) or
overriding queries.
Queries are detached from store session. So session isn't opened until
Query#execute().
WDYT?
--
Artem Melentyev
Thomas, does this mean it's now set in 2 places?
If so I think that's not correct.
Thanks
-Vincent
On May 27, 2008, at 10:58 PM, tmortagne (SVN) wrote:
> Author: tmortagne
> Date: 2008-05-27 22:58:40 +0200 (Tue, 27 May 2008)
> New Revision: 9956
>
> Modified:
> xwiki-platform/core/trunk/xwiki-core/src/main/java/com/xpn/xwiki/
> XWiki.java
> Log:
> XWIKI-2367: Makes ComponentManager getable without the XWikiContext
> * Reset ComponentManager in XWiki.initXWiki as shared-test can't
> call Utils.setComponentManager
>
> Modified: xwiki-platform/core/trunk/xwiki-core/src/main/java/com/xpn/
> xwiki/XWiki.java
> ===================================================================
> --- xwiki-platform/core/trunk/xwiki-core/src/main/java/com/xpn/xwiki/
> XWiki.java 2008-05-27 19:37:05 UTC (rev 9955)
> +++ xwiki-platform/core/trunk/xwiki-core/src/main/java/com/xpn/xwiki/
> XWiki.java 2008-05-27 20:58:40 UTC (rev 9956)
> @@ -737,6 +737,11 @@
> public void initXWiki(XWikiConfig config, XWikiContext context,
> XWikiEngineContext engine_context, boolean noupdate) throws
> XWikiException
> {
> + // Statically store the component manager in {@link Utils}
> to be able to access it without
> + // the context.
> + Utils.setComponentManager((ComponentManager) context
> + .get(ComponentManager.class.getName()));
> +
> setEngineContext(engine_context);
> context.setWiki(this);
Hi Devs,
I've gone through xwiki-core JIRA list and i selected following three issues
out of which i wish to pick a one. But before jumping in, i need some
guidance on which one to select. I thought it's best to ask from the list
since i might not be aware of the severity of these issues.
* XWIKI-2191 <http://jira.xwiki.org/jira/browse/XWIKI-2191> - (When user
logout, his pages locks should be removed - Reported by Thomas Mortagne)
* XWIKI-1538 <http://jira.xwiki.org/jira/browse/XWIKI-1538> - (Improve
performance by efficiently using synchronized code - Reported by Sergiu
Dumitriu)
* XWIKI-671 <http://jira.xwiki.org/jira/browse/XWIKI-671> - (Refactor the
code using deprecated API - Reported by Sergiu Dumitriu)
Thank you very much for your time.
- Asiri
Hi guys,
Some days ago may server got some high CPU load and was unavailable to any
web-request. When I checked what causes it I found out it was Tomcat5.5. So
I did run some benchmark tests with ab (Apache Benchmark) and found out that
I can repeatedly crash Tomcat5.5 with some 'high' concurrent values (ab -n
400 -c 100 http://domain.com/xwiki/bin/view/Main/).
In some posts it was hinted that not Tomcat itself crashs, but the webapp
itself and the developers may be able to track what causes the loop.
Are you able to reproduce that? Is it really a XWiki issue or is it indeed a
Java/Tomcat issue? Can I help in someway?
Cheers
My system
----------------
Dedicated Server running Debian 4
1024MB RAM
100Mbit/s
Tomcat5.5
Java JDK 1.5
Apache2
XWiki 1.3.1.8931
Hi Fabio,
In the new instructions below I don't see how we can build the RCP
version.
Thanks
-Vincent
On May 27, 2008, at 5:25 PM, fmancinelli (SVN) wrote:
> Author: fmancinelli
> Date: 2008-05-27 17:25:07 +0200 (Tue, 27 May 2008)
> New Revision: 9945
>
> Modified:
> xwiki-extensions/xwiki-eclipse/trunk/README
> Log:
> Updated build instructions
>
> Modified: xwiki-extensions/xwiki-eclipse/trunk/README
> ===================================================================
> --- xwiki-extensions/xwiki-eclipse/trunk/README 2008-05-27 15:07:43
> UTC (rev 9944)
> +++ xwiki-extensions/xwiki-eclipse/trunk/README 2008-05-27 15:25:07
> UTC (rev 9945)
> @@ -1,6 +1,39 @@
> The directory structure may appear strange but it's required by the
> Maven PDE plugin.
> See http://mojo.codehaus.org/pde-maven-plugin/usage.html for more
> details.
>
> +A new, refactored and improved version of XWiki Eclipse is now
> available in the repository.
> +This version has a new architecture and a better integration with
> the Eclipse platform.
> +
> +This new version is made of the following plugins and features:
> + * org.xwiki.eclipse.core
> + * org.xwiki.eclipse.ui
> + * org.xwiki.eclipse.xmlrpc
> + * org.xwiki.eclipse.feature
> +
> +In order to build:
> +
> +1) Checkout the trunk: "svn co http://svn.xwiki.org/svnroot/xwiki/xwiki-extensions/xwiki-eclipse/trunk/
> "
> +2) cd to trunk/features/org.xwiki.eclipse.feature.
> +3) Do a "mvn -DeclipseInstall=/AbsolutePath/To/Your/Eclipse/
> Installation" compile.
> +4) You should now have a
> org.xwiki.eclipse.feature_1.2.0.SNAPSHOT.bin.dist.zip file in this
> directory.
> +
> +In order to install:
> +
> +1) Unzip org.xwiki.eclipse.feature_1.2.0.SNAPSHOT.bin.dist.zip into
> your Eclipse directory.
> +2) Run Eclipse.
> +2.1) If XWiki Eclipse doesn't show up anywhere (for example when
> you open the Window->Show view->Other... dialog)
> + then you might need to re-run Eclipse by specifying the -clean
> switch on the command line.
> +
> +You can start using XWiki Eclipse by creating a connection using
> the File->New->Other... menu command.
> +XWiki connections will be accessible from the Project Explorer and
> XWiki Navigator.
> +
> +Enjoy.
> +
> +
> +
> +
> ------------------------------------------------------------------------------------------------------------------------
> +* This refers to the previous version of XWiki Eclipse still
> available on the SVN but deprecated.
> +
> ------------------------------------------------------------------------------------------------------------------------
> There are 2 builds:
>
> * The plugin build which generates an Eclipse plugin for XEclipse.
> It's located in plugins/org.xwiki.eclipse
Dear all,
I have just committed the new XEclipse infrastructure to the trunk.
For building and installation instruction you can go to
http://svn.xwiki.org/svnroot/xwiki/xwiki-extensions/xwiki-eclipse/trunk/REA…
As I have said in a previous message this version has a new
architecture and a better integration with the Eclipse platform and
has a more stable and flexible caching system that can be easily
extended. It is almost feature equivalent with the previous one: I
only need to figure out how to integrate Eclipse working sets and to
re-integrate RCP (so at the moment the new XEclipse is only available
as a platform plugin). I am working on this.
The most important new feature, though, is object edition.
XEclipse works fine with both Eclipse 3.3.x and 3.4Mx and can be
compiled with one of these two platforms.
I encourage you to install and try it.
For GSoCers:
1) Malaka, editors are located in the org.xwiki.eclipse.ui plugins in
the org.xwiki.eclipse.ui.editors.* packages. As you will notice these
are full fledged editors that are not configured for any content-
assist, syntax highlighting support (which you are going to write
soon :)) At some point you will need to plug your infrastructure to
the org.xwiki.eclipse.ui.editors.PageEditor and
org.xwiki.eclipse.ui.editors.propertyEditors.TextAreaPropertyEditor.
We will talk about this later.
2) As far as I understood, Enygma is working on the Eclipse-offline
project that eventually will be integrated into XWiki Eclipse.
It could be interesting for him to have a look at the
org.xwiki.eclipse.core.storage.IDataStorage interface. This is an
interface that is currently used by the DataManager for handling data
exchange between a "master" and "slave" XWiki storages (i.e., a remote
XWiki and a local Cache). The DataManager should be fully configurable
so, for example, it should be possible to use two remote XWikis as
master and slave. The only problem, right now, is that the slave data
storage semantics should preserve the version number at each save, and
the RemoteXWikiDataStorage does not have such a semantics right now.
Cheers,
Fabio