Hi devs,
I'd need to access an instance of ExecutionContext from a Servlet within
XWiki in order to perform XWiki operations from there (query, storage
etc.). So far I tried to follow the same approach as the one I found in
the XWikiRestetServlet :
- XWikiRestletServlet.java http://bit.ly/TDcoQz
- Utils.java http://bit.ly/UfNWa6
i.e. something like this:
ComponentManager componentManager = (ComponentManager)
getServletContext().getAttribute("org.xwiki.component.manager.ComponentManager");
Execution execution = componentManager.getInstance(Execution.class);
ExecutionContext ec = execution.getContext();
XWikiContext xwikiContext = (XWikiContext) ec.getProperty("xwikicontext");
XWiki xwiki = xwikiContext.getWiki();
Unfortunately, while a proper Execution object is obtained indeed, the
returned ExecutionContext remains desperately null. Do you see any
configuration or annotation that may be missing ?
Another option I guess would be to lookup dedicated components for
performing the queries and storage directly without going through an
XWikiContext instance, but then what would be the proper way to discover
all the components that are available from the ComponentManager (esp.
query / storage) ?
Regards,
Stéphane
--
Ubimix - Give a new life to your content!
http://ubimix.com
Twitter: @ubimix
Hi devs,
We've identified yesterday one scenario when the doc cache can become corrupted. By corrupted I mean having a document in it which is empty and has isNew set to true.
Here it is:
* Imagine we're doing a hibernate query calling XHS.execute() (executeRead()/executeWrite()). We're thus in a hibernate session/transaction
* Now imagine that in the doInHibernate callback we start another request.
* Also imagine that the first query was executed in the "wiki1" wiki (setDatabase has been called and the DB is positionned in this wiki)
* Now imagine that the second nested query is done on a different wiki (for example asking to get the user doc from the main wiki)
* The result will be that the doc will not be found by hibernate and loadXWikiDoc will return a new doc with isNew set to true
* The doc cache will save this new doc in the cache
* Subsequent calls for this document will return the invalid document (with isNew = true)
This is what was happening for http://jira.xwiki.org/browse/XWIKI-8160, the problem being that HqlQueryExecutor was doing 2 nested queries. JV is fixing this today.
I'm reporting this here because it's important not to do nested queries like. We're going to generate an exception when we do to try to locate them if there are any more.
Thanks
-Vincent
Hi devs,
I need to have some Velocity macros in the file system because one use
case where I need them is when the database is empty. So I put them in
a new Velocity template file under /templates folder. I didn't want to
add them to macros.vm because they are very specific and not used very
often. Plus, I don't like the idea of putting all the macros in one
single file.
I then tried to include these macros in my other template and some
wiki page using #template. It didn't work. Surprisingly, when I
attached the template with the macros to the skin it worked.
By looking at the code I noticed that #template calls
XWiki#evaluateTemplate which (if I understood correctly) registers the
Velocity macros under
* '' (global) namespace if the template is part of a skin
* template name namespace if the template is not part of the skin.
Both seem wrong:
* in the first case, once you include the template the Velocity macros
become available globally
Hi Savitha,
I've started reviewing quickly the SOLR code in preparation for an integration in the platform and I have some questions which I have jotted down below as I was reviewing the code. Sorry for the terse format, I actually wrote the questions to myself and then decide to send them as is :)
General:
* Need an architecture diagram showing the main modules and threads and how they interact with the platform
Search-api:
* Is the Search API supposed to be independent of SOLR?
* Search interface is strange, it has implementation details such as: getImplementation(), initialize(),
* It also has other concerns such as getStatus(), getStatusAsJson(), getVelocityUtils(), getSearchRequest()
* Why do we need a Search interface? Why not instead use the Query module and introduce a new query type? (note return List from Query.execute() probably needs to be clarified). Replace SearchRequest with Query impl
* Naming of interfaces are a bit strange. For example: BuildIndex; should it be IndexBuilder instead? What about DeleteIndex, should it be IndexDeleter?
* I don't think we need deleteDocumentIndex(), deleteWikiIndex(), deleteSpaceIndex(), etc. We need a single deleteEntity(EntityReference reference, EntityType type). Same for IndexBuilder.
* Why is there a DocumentIndexer interface? Why is a Document different from other entities? For ex I can see DocumentIndexer.deleteIndex() why not IndexDeleter.deleteEntity(documentRef)?
* Why is there a need for RebuildIndex (which I assume is IndexRebuilder) and why cannot we use the IndexBuilder?
* Why the need for SearchIndex?
Search-solrj:
* solrj server in embedded mode is used.
* Shouldn't use system property but the xwiki configuration instead for the solrj home (see below in misc)
* EmbeddedSolrServer depends on Servlet API? "Also, if using EmbeddedSolrServer, keep in mind that Solr depends on the Servlet API. " from http://wiki.apache.org/solr/Solrj
* EmbeddedSolrServer should be started by listening to the app started event instead of lazily in Initializable IMO
* Since we use EmbeddedSolrServer how do we handle clustering? One instance per wiki instance? How do they reconcile their indexes? Need an architecture diagram for our solution for heavy loads.
Misc:
* all API to review and improve/stabilize
* typos to fix
* licenses to fix
* pom to fix
* missing class javadoc (eg BuildIndex, DeleteIndex, etc)
* exception handling to verify (ex: SolrjSearchEngine)
* Remove unneeded javadoc when @override
* Need to use the XWiki Permanent Directory for storing SOLR configuration data (the solr home) - Need to move data currenty in solr/ in a solr-configuration jar module which gets used as a fallback if the data doesn't exist in the solr home dir.
* Idea: use solr JMX to provide admin features (http://wiki.apache.org/solr/SolrJmx)
* TODO: Think about how to migrate users to use SOLR instead of Lucene or DB Searches. Need a plan.
Thanks!
-Vincent
Hello to everyone,
My company has been using XWiki for a while and we have always been able
to solve all problems by ourselves.
This time, it's a bug so weird we need some help from you.
Unfortunately, it is also quite urgent.
Let's begin with a short description of the problem:
- We use the latest XWiki development release, 4.2-milestone-2.
- We use Basic Authentication.
- We connect with a particular administrator to a particular subwiki (it
does not happen with other admiministrators or in other subwikis).
- We open XWikiPreferences once, all is fine.
- We open XWikiPreferences once again, we get a login prompt.
- Any subsequent call to any page gets us a login prompt.
As you may know, with Basic Authentication, a login prompt is an
impossible situation unless the user has been deactivated/removed or the
server does not receive the logged-in username.
But we dumped the JVM heap, and we found that the user object is still
there and the server receives the logged-in username.
After a lot of debugging, we discovered that the user document object
used to retrieve the user object has no references to its objects.
In other words, xObjects is an empty collection within the used instance
of XWikiDocument.
If you would like to help us just read the whole JIRA issue, it contains
much more information. And thank you very much!
http://jira.xwiki.org/browse/XWIKI-8160
--
Martino Dell'Ambrogio
Security Auditor
Web: http://www.tillo.ch/
Email: tillo(a)tillo.ch
Hi devs,
The {{velocity}} macro has a nice filter that removes the whitespace
from the start of each line. This allows us to format (indent) the
Velocity code without generating whitespace garbage.
Recently I had to move some Velocity macros from a wiki page to a
Velocity template file and the absence of this filter turned out to be
a pita. Even if my macros were generating HTML, consecutive
whitespaces were collapsed into a single one which was still visible,
breaking my layout a little. Some of my macros were generating Strings
which now contained a lot of whitespace. I had to update my functional
tests to trim the actual text taken from the UI whenever asserting
something.
WDYT about applying the same filter when parsing Velocity templates?
Do you see any problems with ignoring the whitespace at the start of
the line?
Thanks,
Marius
Hi guys,
I would like to modify a bit the Maven XAR plugin to add in the
package.xml some extension related informations like the extension id
and version at the very least.
The idea is to be able to know what a XAR is exactly like we have the
pom.xml packaged with the jar file for example.
Among other things it will cover the following use cases:
* when someone import a XAR with the standard UI, automatically
register it in the extension index if it happen to be an extension
(i.e. if we find extension informations in its package.xml)
* wiki manager and workspaces can properly register actual extension
when creating their default template from a XAR the first time (this
is for example required to be able to upgrade a farm with EM where
pretty much all the wiki as been created from this default template)
In both cases the idea is to support as much current behaviours as we
can and still be able to use the full power of Extension Manager.
There should not be any backward compatibility issue here since it
does not really change anything in the XAR structure.
WDYT ?
Here is my +1
Thanks,
--
Thomas Mortagne
Hi,
I have received numerous complains that simple users have problems in
editing the content and title of the Welcome block ("Welcome to you wiki"
gadget) from the homepage.
There are multiple factors that influence the editing of that particular
gadget and that make the job especially harder for beginners.
One of these factors is that the gadget used to display the Welcome content
is an "include" gadget. Without some custom actions for the gadget that
would let the user navigate to the included page or without some
auto-redirect mechanism, the simple users have difficulties in
understanding where the welcome content is coming from and what actions
they need to do in order to edit that content.
Also the "include" macro has a lot of advanced properties that can be scary
and confusing for users (context, reference, section, type, etc.).
My proposal is to create a new "text" gadget. This gadget will be very-very
simple and will contain just the gadget's title and the gadget's content.
Its only purpose will be to let users add textual information inside a
dashboard.
http://incubator.myxwiki.org/xwiki/bin/view/Improvements/EditingWelcomeMess…
Right now we have specialized gadgets for HTML content, velocity content,
code in general, boxes, success messages, etc. but no way to put just a
simple text inside the dashboard.
Let me know what you think.
Thanks,
Caty
Hi devs,
Me and Thomas are late on the work for making an XWiki farm upgradable
through the Extension Manager in a few minutes and JV just committed
two new modules, wiki components and UI extensions, in the platform
and they need some time to be tested and stabilised. Thus I'm
proposing to delay the 4.2M3 release by one week and reduce the 4.2RC1
by one week so that the final release date for 4.2 stays the same:
* 4.2M3: 3 September
* 4.2RC1: 10 September
* 4.2 final: 17 September
Here's my +1.
Thanks,
Marius