Hi (Marius),
With the new powerful sheet system it's now very hard to know where is located the sheet used to display the page (it's magical now ;)).
Thus I think that when editing a page in wiki/wysiwyg edit modes we need to display a link to edit the sheet used to display the page, in the Document Information panel.
WDYT?
Thanks
-Vincent
Hi guys,
I'm trying to reduce the enormous number of lock done by the current
implementation of Embedded Component Manager and I could use some more
brains to check what I did.
You can find the new version on
https://github.com/xwiki/xwiki-commons/blob/feature-improvecm/xwiki-commons…
Quick comparison with the current one:
* removed all "synchronized (this)" that was in pretty much all the
methods and which made the CM block everything whenever anyone was
using it
* used ConcurrentHashMap to securize the insertion/search of components
* basically the only remaining explicit lock is on singleton component
initialization mostly to make sure we don't initialize the same
component at the same time
If you find some small modification to improve a bit the speed don't
hesitate too. There is possible improvements to speed up lookuplist
and lookupmap (not going though the whole map basically) but it
require important refactoring and I would prefer not doing too much
things at once since it's a pretty critical peace of code and locking
is the main issue right now.
Thanks,
--
Thomas Mortagne
Hi devs,
Summary:
========
I'd like to add the notion of Priority to Event Listeners. The reason is that in some cases it's important that some listeners execute before others.
The problem at hand:
=================
Here's a typical use case: When receiving the ApplicationStartedEvent, we have lot of code that needs to initialize. Initialization order is important (you can compare it to run levels in OS): for example some init must happen after the Database initialization has happened.
Note that another solution exists for this use case: some initializations could introduce their own events (such as a DatabaseStartedEvent) and other init could listen on those events instead of the generic ApplicationStartedEvent. However I can see several drawbacks to this:
* it's less generic than the priority solution
* it means creating more events
* but more importantly it means that modules will have strong dependencies (at maven level) on each other whereas it's not necessary and shouldn't be the case. In our example use case: it means that inits that must happen after database is started will need to depend on oldcore (which is where DB is started ATM)
Proposal:
========
* Don't break backward compat in Observation module
* Introduce a PrioritizedEventListener interface that adds a getPriority() method
* Modify ObservationManager implementation to take into account priorities
* In order to make it simple I propose to have only a single priority per Listener and not a priority per event supported by a given listener
General Context
=============
To give some context here's what I'd like to do on the medium term:
* Step 1: Introduce notion of priority in EventListeners
* Step 2: Refactor XWiki init to use an EventListener on AppStarted with low priority
* Step 3: Refactor wiki macros to use an EventListener on AppStarted with priority value lower than at step2
* Step 4: Write an EventListener for the new UI Extensions with a priority value higher than the one of step2 <-- this is the initial goal that led me to make this proposal ;)
WDYT?
Thanks
-Vincent
Hi Everyone!
I have read this document "Writing GWT applications in XWiki" (
http://dev.xwiki.org/xwiki/bin/view/Drafts/WritingGWTApplicationsInXWiki)
And I know how to develop GWT module for xwiki now. I also have read the
document "WYSIWYG Editor Module" (
http://code.xwiki.org/xwiki/bin/view/Modules/WysiwygEditorModule). I
followed the instruction which tried to integrate the WYSIWYG editor(GWT
application) in wiki pages, and I put the following code in my wiki editor:
"{{html}}
<script type="text/javascript" src="XWikiWysiwyg.js"> alert('WYSIWYG code is
loaded!'); </script> <textarea id="demo"></textarea> <script
type="text/javascript"> Wysiwyg.onModuleLoad(function() { new
WysiwygEditor({hookId:'demo'}); alert('WYSIWYG code is loaded!'); });
Wysiwyg.onModuleLoad(function() { editor = new WysiwygEditor({hookId:
'demo'}); }); }); </script> {{/html}}"
After saved, it only display a blank text area without any sign of WYSIWYG
editor, also there is no alart 'WYSIWYG code is loaded!' popup. Can you help
me figure it out what is wrong with it?
I am planing to develop a tree view using GWT to display Design Rationale
Element. Could you give me some ideas of after my development, how can I
embeded the GWT application into Xwiki pages and interact with the GWT
application?
Thank you very much!
Leon
Hi devs,
Since Eduard has developed the workspaces module (see http://extensions.xwiki.org/xwiki/bin/view/Extension/Workspace+Application) I'd like to push for using it in our XEM distribution.
However there are 2 valid uses cases that exist:
1) Using XE + workspaces, for creating workspaces (technically each workspace being a wiki)
2) Using XE as a wiki farm
I think that use case 1) is the main use case for most people and this vote is about keeping the XEM packaging/branding but repurposing so that XEM implements use case 1). Use case 2) exists but it's less frequent and for more technically advanced users.
So here's my proposal (and what you should vote on):
A) XEM = app manager module + wiki manager module + workspaces module(s). XEM home page becomes the workspaces app home page. We update manager.xwiki.org to align it with the fact that it now boasts the workspaces features.
B) On http://platform.xwiki.org/xwiki/bin/view/AdminGuide/Virtualization we keep documenting how to transform XE into a wiki farm
C) We create an application in xwiki-platform-core/ that contains the current pages located in XEM (home page + the other pages). We could call it xwiki-platform-multiwiki
D) Users who want to install xwiki-platform-multiwiki easily will use the Extension Manager UI when it's ready for general consumption
E) Users who want to install xwiki-platform-workspace easily will use the Extension Manager UI when it's ready for general consumption. At this point we'll decide if we want to drop the XEM distribution or keep both ways of installing it.
Here'd my +1
Thanks
-Vincent
The XWiki development team is proud to announce the availability of
XWiki Commons, XWiki Rendering, XWiki Platform, XWiki Enterprise and
XWiki Enterprise Manager 3.3 Milestone 2. The highlights of this release
are:
* a new user interface for the extension manager
* new features for the Application Within Minutes aspect
* a new and improved FAQ application has been committed in the platform,
although it's not bundled by default in XE
* support for exporting PDF documents for CJK languages
* a new rendering transformation that can be used to check the status of
any link encountered in the wiki
And on the developers' front:
* support for dependency Providers, as defined in JSR330
* a Disposable interface for singleton components which can be used to
release resources when a component is being unregistered
See the full release notes at
http://www.xwiki.org/xwiki/bin/ReleaseNotes/ReleaseNotesXWikiEnterprise33M2
for more details.
--
Sergiu Dumitriu
http://purl.org/net/sergiu/
Hi devs,
Some methods must be captured so that they don't create output when
called from velocity, usually with something like:
#set ($var = $obj.doSomething())
Where $var is a variable whose content isn't needed and won't be used.
And everyone seems to have his favorite name for it: $discard, $ok,
$ignore...
I'd like to have a single variable name, so that in the end we don't end
up creating 5 different variables for the same goal. So, which one do
you prefer:
1. $discard
2. $discarded
3. $ignore
4. $ignored
5. $ok
6. $output
$ok is the shortest, thus easier to type, faster to parse, and lighter
on the total size of the wiki. On the other hand, I prefer $discard
since it's more meaningful, it conveys exactly what that line does:
"$discard the output of this method call".
--
Sergiu Dumitriu
http://purl.org/net/sergiu/
Hi,
I'd like to get the XWiki on Cassandra project to be in contrib and get it building on Jenkins as soon as possible.
Unfortunately the Jenkins build requires integrating some changes into xwiki-store-filesystem-attachments which are now in the xwiki-store-legacy branch.
Todd Nine's Datanucleus-Cassandra-Plugin is nolonger being maintained by him, it is the only existing Datanucleus Cassandra plugin and my fork contains extensive changes.
It is licensed under the Apache 2 license and I would like to include it as well.
I would like to do this:
1. Move the repositories into contrib.
2. Bring the changes in the xwiki-store-legacy branch up to date and merge them into the trunk.
3. Start automated builds of Datanucleus-Cassandra-Plugin, and xwiki-store-datanucleus.
WDYT?
Caleb
Hi,
I remember once there was a contest for new XWiki logo but due to
elections fail (there would have been too many unsatisfied people if any of
newly suggested logos had been approved) the process has gracefully ended
(which, in my opinion, was a good decision)
I also think that it would be worthless to conduct another
competition/election amongst users because as the saying goes - tastes
differ. The only thing users can contribute are their ideas (which might be
accepted or might not which is fair) regarding shapes and symbols to use.
Decision about visual design should be made within very very small circle of
visual designers probably with one or two people involved in the project to
chill down designers' burning imagination :)
Having all of the above said, I would suggest to collect a set of shapes
and symbols for new XWiki logo each supplied with description of underlying
meaning. And then (having revised all of the comments in some of the former
posts regarding what new logo should be: symmetric/asymmetric,
complex/simple, round/firm) provide all that to a designer to draw several
sketches. And then by internal vote (at maximum the development team members
involved) choose the new logo.
This thread is for storing all of the ideas on the new XWiki logo. At
least that's what I (as a user) will be using it for may any ideas to come.
Join :)
Regards,
Roman
--
View this message in context: http://xwiki.475771.n2.nabble.com/XWiki-logo-around-tp6074956p6074956.html
Sent from the XWiki- Dev mailing list archive at Nabble.com.
Hi devs,
I've been finding that Jetty takes a lot of time to start lately. So I've run some profiling on it.
Starting Jetty (till the STARTING message) takes 15 seconds on my machine (in debug mode, we win 3 seconds, ie 12s start time), split like this:
* 50% of the time spent scanning jars in WEB-INF/lib (JarInputStream.getNextJar()) - 7s
* 10% in Jetty itself - 2s
* 40% in our code in Extension Manager init (2.5s) and in Component registration from their annotations (2.5s) - 5s
If I remove the start of the EM in XWikiServletContextListener, we start in 7 seconds (instead of 15s)
If I try to start Jetty without any webapp, it starts in 500ms.
If I remove the oldcore legacy jar (2.5MB) we win 1 second in start up time.
Note: This is all before XWiki.init() is called on the first request.
Analysis of ComponentAnnotationLoader (2.5s):
* 1.2s just loading classes from the CL
* 1s getDeclaredFields (reflection API)
* 800ms initializing SLF4J
Analysis of Extension Manager init (2.5s):
* In DefaultCoreExtensionScanner.loadExtensions():
** 500ms URL.toURI()
** 500ms MavenXpp3Reader.read() - POM reading
** 150ms org.Reflections scanning
** 150ms resource loading from CL (getResourceAsStream())
* In DefaultExtensionLicenseManager.initialize()
** 314ms in org.Reflections
* 130ms of loading xwiki.properties
Conclusion
=========
* XWiki's size in number of JARs and their sizes makes it long to start Jetty.
* We could make some small optimizations in EM and Component loading but we wouldn't win that much, on the order of 2s in total (i.e. 15% of total load time)
Thanks
-Vincent
Hi devs,
The 3.3 Milestone 2 release was supposed to happen this past Monday, but
the codebase hasn't been stable enough for a release (failing tests, hot
commits triggering comments, unmerged branches).
Proposal 1: Release 3.3 RC 1 next Monday, 21 November, effectively
dropping Milestone 2. This respects the initial schedule, although some
of the targeted features won't be fully usable. This means that everyone
should try to get their code stabilized.
Proposal 2: Lengthen the release by another week, releasing:
- Milestone 2 next Monday, November 21
- RC1 on November 28
- Final on December 5
I'm fine with either one, if the codebase is stable enough for a RC by
next Monday.
--
Sergiu Dumitriu
http://purl.org/net/sergiu/
Hi devs,
Since we're going to use Maven POM metadata to display extensions in the Extension Manager UI it's important that we have all data filled and with correct value.
Sergiu pointed to me that currently our website <url> are wrong.
This is because the top level POM has <url>http://xwiki.org</url> and Maven automatically suffixes it with artifact Ids.
For example for Commons Component API this gives us:
<url>http://xwiki.org/xwiki-commons-pom/xwiki-commons-core/xwiki-commons-compone…</url>
which is not pointing to anything valid.
I see 2 ways of fixing this:
Solution 1
========
Do as I started this morning, i.e. set the <url> explicitly. For example I've set PHP Macro module URL this morning to <url>http://extensions.xwiki.org/xwiki/bin/view/Extension/PHP+Macro</url> and Commons Observation API (the 3 modules: parent + api + local) to <url>http://extensions.xwiki.org/xwiki/bin/view/Extension/Observation+Module</url>.
Pros:
- Easy and we can point to wherever the documentation is located
Cons:
- Tedious
- Fragile. If we rename a page on the wiki then the link is broken
Solution 2
========
Set the top level URL to something like:
<url>http://xwiki.org/documentation?id=</url>
For example for Commons Component API this will generate:
<url>http://xwiki.org/documenation?id=/xwiki-commons-pom/xwiki-commons-core/xwik…</url>
Then:
* Have an apache redirection for /documentation to some wiki page such as http://xwiki.org/xwiki/bin/view/Main/ModuleDocumentation
* Have the logic inside that page to transform paths (such as "/xwiki-commons-pom/xwiki-commons-core/xwiki-commons-component/xwiki-commons-component-api" into proper URLs). Since I don't think we can have a generic logic, I'd simply put a big hashtable to start with.
Pros:
- Simple, no need to modify all poms. We only need to change the top level pom <url> value
- Much easier to keep up to date since when we rename pages all we need to do is edit the ModuleDocumentation page. Actually when we support page renames across wikis we could have the links in that page be automatically renamed ;) With Solution 1, when you rename the URL you need to re-release the module which is a big pain.
Cons:
- I can't see any really :) We just need to be sure that http://xwiki.org/documentation is available.
So I'm definitely for 2, WDYT?
Thanks
-Vincent
Hi
Today I tried to create a custom mapping for a class. One field of the
class is a DBList with the "Multiple Select" option activated. To save
the values to the DB I wanted to use a string field like I'm used to
with static lists and non multi select DB lists. Now I get the
following exception when trying to save a Document with an object
attached: "java.util.ArrayList cannot be cast to java.lang.String"
How could I custom map a DBList field if String ist not possible? or
is there even a simple Solution I missed?
A hint in the right direction would be appreciated
Edo
Hi Devs,
I've created a new FAQ application currently located at http://www.xwiki.org/xwiki/bin/view/FAQ/WebHomeNew
I'd like to publish it in platform since we need to maintain it anyway for xwiki.org (I'm also ok to maintain it).
Here's my +1
Thanks
-Vincent
Hi Denis,
Just looked at the merged code (btw I can't find how to comment on it on github, it's a big mess), so I'm commenting here:
I noticed 2 issues:
* One is that even though I said in the vote mail that I didn't agree about keeping parameters in EntityReferences you've still kept them. Again I think we shouldn't keep them because we don't have an agreement about them ATM (Caleb is against them). Also you've exposed them with a protected method which means users can extend EntityReference and use them. As I said FTM I think you should move the notion of Locale **only** in DocumentReference since this is the only thing we've agreed about so far.
* You have some comments in DocumentReference like this:
* @param locale the new locale for this reference, if null, locale is removed
I don't understand what this means. How can it be removed since they are immutable and it's in a constructor :)
Also looking at setLocale I see:
protected void setLocale(Locale locale)
{
if (locale != null) {
setParameter(LOCALE, locale);
}
}
I don't see any removal.
Is it a leftover/typo?
Thanks
-Vincent
Hi devs,
I made some progress on the AppWithinMinutes and I'd like to get your
feedback. If you download the latest 3.3 snapshot and visit the
AppWithinMinutes.WebHome page you'll be able to test the class editor
and the live table generator. Here's a list of things that you should
check:
* on the class editor
** the field display is updated when the configuration panel is collapsed
** Save&Continue is available
** StaticList values editor
** Date picker
* on the live table generator
** the live table edit sheet
*** how the deprecated class fields are handled (you can edit in
object mode and add a column for a field that doesn't exist)
** the live table view sheet (this is how the application home page
will look like)
*** the Actions pane
** the generated code (edit in wiki mode the generated page)
The things that are left to do before the 3.3 final are:
* custom display (suggest input) for User, Group and Database List
field types (class editor)
* AppWithinMinutes wizard (integrating the class editor and the live
table generator)
* cross-browser testing (your help is welcome)
* i18n
* functional tests (I need more feedback on the UI first)
Regarding the LiveTable generator, I'm not happy with the i18n hack. I
adapted the code from
http://extensions.xwiki.org/xwiki/bin/view/Extension/Livetable+Macro+2.0
which "overwrites" the $msg variable with a map before rendering the
live table and restores it afterwards. Is there a better way?
Thanks,
Marius
Hi Jeremie,
It seems this is a regression I introduced in 3.2 when I refactored
the XWikiDocument class to use the new display module. The problem is
that the title is parsed as HTML which shouldn't be the case because
the title is plain text + Velocity script.
The title was parsed as HTML before my changes, but only if the output
syntax wasn't HTML (rare, since most of the time wiki pages are
rendered as HTML to be displayed in a browser).
Devs, do you see any issues with parsing the (specified) document
title as plain text (after the Velocity script has been evaluated)?
Thanks,
Marius
On Mon, Nov 14, 2011 at 3:58 PM, jerem <jeremie.bousquet(a)gmail.com> wrote:
> Hi,
>
> - There seem to be some bad displays when a page title contains '<' or '>'.
>
> Display is correct in browser title bar, it is also correct in main content
> area, in hierarchy, but not in page title. For a page with title "TestTest >
> test", generated html looks like this :
>
> <div id="hierarchy">
> TestTest > test
> </div>
> <div id="document-title">
> TestTest* &*gt; test
>
> </div>
>
> The bad trick is that the "&" of ">" gets replaced by "&" ...
>
> - as a side question, is there a way to easily do the equivalent of velocity
> "$escapetool.html($text)", but in {{groovy}} ? I use mainly groovy in my
> pages, and would like to avoid passing parameters between groovy and
> velocity just for this one use-case ...
>
> Thanks,
> Jeremie
>
> --
> View this message in context: http://xwiki.475771.n2.nabble.com/Characters-or-bad-display-in-page-title-t…
> Sent from the XWiki- Users mailing list archive at Nabble.com.
> _______________________________________________
> users mailing list
> users(a)xwiki.org
> http://lists.xwiki.org/mailman/listinfo/users
>
Hi devs,
After much brainstorming with Thomas and with the implementation of the new model I'm doing, we've come to the conclusion that it would be better to add the notions of Locale and Version in EntityReference.
The main reasons are:
* otherwise we need to introduce a notion of UniqueEntityReference in the model and it makes it very awkward at an API level (user need to constuct a UniqueEntityReference from an EntityReference depending on the APIs used)
* it makes APIs more complex than what they could be.
For example:
- getDocument(EntityReference)
- getDocument(EntityReference, Locale)
- getDocument(EntityReference, Version)
- getDocument(EntityReference, Locale, Version)
vs
- getDocument(EntityReference)
(subnote: this is why I introduced UniqueEntityReference in the model)
* It'll mean that anywhere we use an entity reference we'll be able to reference a specific version of that entity and/or a specific language. Some example: including a specific version of a page, referencing a specific version of an attachment in wiki syntax, etc.
In a first version I'd like to only introduce a generic get/setAttributes (to allow extensibility) in EntityReference + get/setLocale/Version (for easiness of access).
ATM I'm not planning to define a textual syntax for attributes (but it could something like: wiki:space.page[name1=value1, … nameN=valueN]). I'm not asking to vote on this.
Here's my +1
Thanks
-Vincent
Hi all.
Short version of my question: Can anyone point me to an example of
adding object of a custom class to a page via the ReSTful API?
And now for the long version of my question:
I can successfully create a page using REST, but can't add an object.
Here is the problem step by step.
1) Using this XML definition in a file called AlinaPage.xml:
<?xml version="1.0" encoding="UTF-8"?>
<xwiki:page xmlns:xwiki="http://www.xwiki.org"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.xwiki.org C:\Users\mwallace\
Desktop\xwiki_rest_model.xsd">
<xwiki:link
href="http://localhost:8080/xwiki/rest/wikis/xwiki/spaces/Main/pages/Alina+Frey/o…"
rel="http://www.xwiki.org/rel/o
bject"></xwiki:link>
<xwiki:id/>
<xwiki:fullName/>
<xwiki:wiki/>
<xwiki:space>Main</xwiki:space>
<xwiki:name>Alina Frey</xwiki:name>
<xwiki:title/>
<xwiki:parent/>
<xwiki:parentId/>
<xwiki:xwikiRelativeUrl/>
<xwiki:xwikiAbsoluteUrl/>
<xwiki:translations/>
<xwiki:syntax/>
<xwiki:language/>
<xwiki:version/>
<xwiki:majorVersion>1</xwiki:majorVersion>
<xwiki:minorVersion>0</xwiki:minorVersion>
<xwiki:created>2011-07-02T12:32:00-04:00</xwiki:created>
<xwiki:creator>XWiki.mwallace</xwiki:creator>
<xwiki:modified>2011-07-02T12:32:00-04:00</xwiki:modified>
<xwiki:modifier/>
<xwiki:content>{{include document="XWiki.PersonSheet"/}}</xwiki:content>
</xwiki:page>
2) I do the following command, which adds the page successfully:
C> curl -u mwallace:password -X PUT --data-binary "@AlinaPage.xml" -H
"Content-Type: application/xml"
http://localhost:8080/xwiki/rest/wikis/xwiki/spaces/Main/pages/Alina+Frey
3) The resulting page from a HTTP GET is:
<?xml version="1.0" encoding="UTF-8"?>
<page xmlns="http://www.xwiki.org">
<link href="http://localhost:8080/xwiki/rest/wikis/xwiki/spaces/Main"
rel="http://www.xwiki.org/rel/space"/>
<link
href="http://localhost:8080/xwiki/rest/wikis/xwiki/spaces/Main/pages/Alina%20Frey…"
rel="http://www.xwiki.org/rel/history"/>
<link href="http://localhost:8080/xwiki/rest/syntaxes"
rel="http://www.xwiki.org/rel/syntaxes"/>
<link
href="http://localhost:8080/xwiki/rest/wikis/xwiki/spaces/Main/pages/Alina+Frey"
rel="self"/>
<link
href="http://localhost:8080/xwiki/rest/wikis/xwiki/classes/Main.Alina%20Frey"
rel="http://www.xwiki.org/rel/class"/>
<id>xwiki:Main.Alina Frey</id>
<fullName>Main.Alina Frey</fullName>
<wiki>xwiki</wiki>
<space>Main</space>
<name>Alina Frey</name>
<title>Alina Frey</title>
<parent/>
<parentId/>
<xwikiRelativeUrl>http://localhost:8080/xwiki/bin/view/Main/Alina+Frey</xwikiRelativeUrl>
<xwikiAbsoluteUrl>http://localhost:8080/xwiki/bin/view/Main/Alina+Frey</xwikiAbsoluteUrl>
<translations/>
<syntax>xwiki/2.0</syntax>
<language/>
<version>4.1</version>
<majorVersion>4</majorVersion>
<minorVersion>1</minorVersion>
<created>2011-07-02T12:45:12-04:00</created>
<creator>XWiki.mwallace</creator>
<modified>2011-07-02T21:33:48-04:00</modified>
<modifier>XWiki.mwallace</modifier>
<content>{{include document="XWiki.PersonSheet"/}}</content>
</page>
4) But then, using this definition of an object in file AlenaObject.xml:
<?xml version="1.0" encoding="UTF-8"?>
<xwiki:object xmlns:xwiki="http://www.xwiki.org"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.xwiki.org C:\Users\mwallac
e\Desktop\xwiki_rest_model.xsd">
<xwiki:id/>
<xwiki:guid/>
<xwiki:pageId>Main.Alina Frey</xwiki:pageId>
<xwiki:wiki/>
<xwiki:space>Main</xwiki:space>
<xwiki:pageName>Alina Frey</xwiki:pageName>
<xwiki:className>XWiki.PersonClass</xwiki:className>
<xwiki:number>0</xwiki:number>
<xwiki:headline/>
<xwiki:property name="_knows">
<xwiki:value>Main.Alena</xwiki:value>
</xwiki:property>
<xwiki:property name="_knows">
<xwiki:value>Main.Judi Wallace</xwiki:value>
</xwiki:property>
<xwiki:property name="name">
<xwiki:value>Alina Frey</xwiki:value>
</xwiki:property>
</xwiki:object>
5) I try the following command, which does NOT insert the object properly:
C> curl -u mwallace:password -X PUT --data-binary "@AlinaObject.xml" -H
"Content-Type: application/xml"
http://localhost:8080/xwiki/rest/wikis/xwiki/spaces/Main/pages/Alina+Frey/o…
6) Rather, I get this error message:
<html>
<head>
<title>Status page</title>
</head>
<body>
<h3>The server has not found anything matching the request
URI</h3><p>You can get technical details <a
href="http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.4.5">here</a>.<br>
Please continue your visit at our <a href="/">home page</a>.
</p>
</body>
</html>
What am I doing wrong?
--
Mark Wallace
Principal Engineer, Semantic Applications
Modus Operandi, Melbourne, FL, USA
Hi Team,
I am unable to resolve "outOfMemory" issue.I have already increased heap
size to 4000M but still getting the same error even on fresh installation.
Can someone from xwiki team help me to resolve this issue?
Thanks
Karamjit