Hello,
We have a problem with "mvn install -Pjettyrun". Trying to open any
produces a "The requested document could not be found" and the console
displays the error given below. It seems it's not able to find the
version.properties file.
I was able to reproduce this on more than one machine. Can somebody
please look into this?
Regards,
Catalin
catalin:~/JavaApps/xwiki-trunks-devs/xwiki-platform-web/standard
hritcu$ mvn install -Pjettyrun
[INFO] Scanning for projects...
[INFO] ----------------------------------------------------------------------------
[INFO] Building XWiki Platform - Web - Standard
[INFO] task-segment: [install]
[INFO] ----------------------------------------------------------------------------
Downloading: http://maven.xwiki.org/externals/groovy/groovy-all-1.0-jsr/06/groovy-all-1.…
Downloading: http://maven.xwiki.org/releases/groovy/groovy-all-1.0-jsr/06/groovy-all-1.0…
Downloading: http://repo1.maven.org/maven2/groovy/groovy-all-1.0-jsr/06/groovy-all-1.0-j…
[INFO] Setting property: classpath.resource.loader.class =>
'org.codehaus.plexus.velocity.ContextClassLoaderResourceLoader'.
[INFO] Setting property: velocimacro.messages.on => 'false'.
[INFO] Setting property: resource.loader => 'classpath'.
[INFO] Setting property: resource.manager.logwhenfound => 'false'.
[INFO] [remote-resources:process]
[WARNING] Attempting to build MavenProject instance for Artifact of
type: jar; constructing POM artifact instead.
[WARNING] Attempting to build MavenProject instance for Artifact of
type: jar; constructing POM artifact instead.
[WARNING] Attempting to build MavenProject instance for Artifact of
type: jar; constructing POM artifact instead.
[WARNING] Attempting to build MavenProject instance for Artifact of
type: jar; constructing POM artifact instead.
[INFO] [site:attach-descriptor]
[INFO] [assembly:single]
[INFO] Reading assembly descriptor:
/Users/hritcu/JavaApps/xwiki-trunks-devs/xwiki-platform-web/standard/src/assemble/jetty.xml
[INFO] Initializing assembly filters...
[INFO] Copying 3 files to
/Users/hritcu/JavaApps/xwiki-trunks-devs/xwiki-platform-web/standard/target/xwiki-web-standard-1.2-SNAPSHOT-hsqldb.dir
[INFO] [jetty:run]
[INFO] Configuring Jetty for project: XWiki Platform - Web - Standard
[INFO] Webapp source directory =
/Users/hritcu/JavaApps/xwiki-trunks-devs/xwiki-platform-web/standard/src/main/webapp
[INFO] web.xml file =
/Users/hritcu/JavaApps/xwiki-trunks-devs/xwiki-platform-web/standard/src/main/webapp/WEB-INF/web.xml
[INFO] Classes =
/Users/hritcu/JavaApps/xwiki-trunks-devs/xwiki-platform-web/standard/target/xwiki-web-standard-1.2-SNAPSHOT-hsqldb.dir/WEB-INF
2007-08-26 19:19:47.172::INFO: Logging to STDERR via org.mortbay.log.StdErrLog
[INFO] Context path = /xwiki
[INFO] Tmp directory =
/Users/hritcu/JavaApps/xwiki-trunks-devs/xwiki-platform-web/standard/target/work
[INFO] Web defaults = jetty default
[INFO] Web overrides = none
[INFO] Webapp directory =
/Users/hritcu/JavaApps/xwiki-trunks-devs/xwiki-platform-web/standard/src/main/webapp
[INFO] Starting jetty 6.1.5 ...
2007-08-26 19:19:48.294::INFO: jetty-6.1.5
2007-08-26 19:19:48.594::INFO: No Transaction manager found - if your
webapp requires one, please configure one.
2007-08-26 19:19:50.153::INFO: Started SelectChannelConnector@0.0.0.0:8080
[INFO] Started Jetty Server
19:20:02,814 WARN btpool0-1
http://localhost:8080/xwiki/bin/view/Main/WebHome XWiki:getVersion:727
- Failed to retrieve XWiki's version from
[/WEB-INF/version.properties], using the [version] property.
java.lang.NullPointerException
at java.util.Properties$LineReader.readLine(Properties.java:365)
at java.util.Properties.load(Properties.java:293)
at com.xpn.xwiki.XWikiConfig.loadConfig(XWikiConfig.java:58)
at com.xpn.xwiki.XWikiConfig.<init>(XWikiConfig.java:53)
at com.xpn.xwiki.XWiki.getVersion(XWiki.java:723)
at com.xpn.xwiki.api.XWiki.getVersion(XWiki.java:84)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at org.apache.velocity.runtime.parser.node.PropertyExecutor.execute(PropertyExecutor.java:137)
at org.apache.velocity.util.introspection.UberspectImpl$VelGetterImpl.invoke(UberspectImpl.java:350)
at org.apache.velocity.runtime.parser.node.ASTIdentifier.execute(ASTIdentifier.java:180)
at org.apache.velocity.runtime.parser.node.ASTReference.execute(ASTReference.java:203)
at org.apache.velocity.runtime.parser.node.ASTReference.render(ASTReference.java:294)
at org.apache.velocity.runtime.parser.node.ASTBlock.render(ASTBlock.java:74)
at org.apache.velocity.runtime.parser.node.ASTIfStatement.render(ASTIfStatement.java:88)
at org.apache.velocity.runtime.parser.node.SimpleNode.render(SimpleNode.java:318)
at com.xpn.xwiki.render.XWikiVelocityRenderer.evaluate(XWikiVelocityRenderer.java:240)
at com.xpn.xwiki.render.XWikiVelocityRenderer.evaluate(XWikiVelocityRenderer.java:143)
at com.xpn.xwiki.XWiki.parseTemplate(XWiki.java:1268)
at com.xpn.xwiki.XWiki.parseTemplate(XWiki.java:1229)
at com.xpn.xwiki.api.XWiki.parseTemplate(XWiki.java:545)
at sun.reflect.GeneratedMethodAccessor18.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at org.apache.velocity.util.introspection.UberspectImpl$VelMethodImpl.invoke(UberspectImpl.java:295)
at org.apache.velocity.runtime.parser.node.ASTMethod.execute(ASTMethod.java:245)
at org.apache.velocity.runtime.parser.node.ASTReference.execute(ASTReference.java:203)
at org.apache.velocity.runtime.parser.node.ASTReference.render(ASTReference.java:294)
at org.apache.velocity.runtime.parser.node.SimpleNode.render(SimpleNode.java:318)
at org.apache.velocity.runtime.directive.VelocimacroProxy.render(VelocimacroProxy.java:194)
at org.apache.velocity.runtime.parser.node.ASTDirective.render(ASTDirective.java:170)
at org.apache.velocity.runtime.parser.node.SimpleNode.render(SimpleNode.java:318)
at com.xpn.xwiki.render.XWikiVelocityRenderer.evaluate(XWikiVelocityRenderer.java:240)
at com.xpn.xwiki.render.XWikiVelocityRenderer.evaluate(XWikiVelocityRenderer.java:143)
at com.xpn.xwiki.XWiki.parseTemplate(XWiki.java:1268)
at com.xpn.xwiki.XWiki.parseTemplate(XWiki.java:1229)
at com.xpn.xwiki.api.XWiki.parseTemplate(XWiki.java:545)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at org.apache.velocity.util.introspection.UberspectImpl$VelMethodImpl.invoke(UberspectImpl.java:295)
at org.apache.velocity.runtime.parser.node.ASTMethod.execute(ASTMethod.java:245)
at org.apache.velocity.runtime.parser.node.ASTReference.execute(ASTReference.java:203)
at org.apache.velocity.runtime.parser.node.ASTReference.render(ASTReference.java:294)
at org.apache.velocity.runtime.parser.node.SimpleNode.render(SimpleNode.java:318)
at org.apache.velocity.runtime.directive.VelocimacroProxy.render(VelocimacroProxy.java:194)
at org.apache.velocity.runtime.parser.node.ASTDirective.render(ASTDirective.java:170)
at org.apache.velocity.runtime.parser.node.SimpleNode.render(SimpleNode.java:318)
at com.xpn.xwiki.render.XWikiVelocityRenderer.evaluate(XWikiVelocityRenderer.java:240)
at com.xpn.xwiki.render.XWikiVelocityRenderer.evaluate(XWikiVelocityRenderer.java:143)
at com.xpn.xwiki.XWiki.parseTemplate(XWiki.java:1268)
at com.xpn.xwiki.XWiki.parseTemplate(XWiki.java:1229)
at com.xpn.xwiki.web.Utils.parseTemplate(Utils.java:94)
at com.xpn.xwiki.web.Utils.parseTemplate(Utils.java:48)
at com.xpn.xwiki.web.XWikiAction.execute(XWikiAction.java:155)
at org.apache.struts.action.RequestProcessor.processActionPerform(RequestProcessor.java:431)
at org.apache.struts.action.RequestProcessor.process(RequestProcessor.java:236)
at org.apache.struts.action.ActionServlet.process(ActionServlet.java:1196)
at org.apache.struts.action.ActionServlet.doGet(ActionServlet.java:414)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:707)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:820)
at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:487)
at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1093)
at com.xpn.xwiki.web.SetCharacterEncodingFilter.doFilter(SetCharacterEncodingFilter.java:117)
at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1084)
at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:360)
at org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java:216)
at org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:181)
at org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:712)
at org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:405)
at org.mortbay.jetty.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:211)
at org.mortbay.jetty.handler.HandlerCollection.handle(HandlerCollection.java:114)
at org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:139)
at org.mortbay.jetty.Server.handle(Server.java:313)
at org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:506)
at org.mortbay.jetty.HttpConnection$RequestHandler.headerComplete(HttpConnection.java:830)
at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:514)
at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:211)
at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:381)
at org.mortbay.io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.java:396)
at org.mortbay.thread.BoundedThreadPool$PoolThread.run(BoundedThreadPool.java:442)
While working on the new diff interface I've hit this bug
http://jira.xwiki.org/jira/browse/XWIKI-1468
with the numbering on versions in the RCS file which does not correspond
to the version of the real documents.
There are different ways to fix this, but maybe it's not worth to do the
"perfrect fix" with Artem's work on versioning storage that coult not
make use of RCS.
So the problem is that in the RCS file you have
1.3 -> $doc.version = 1.4
1.2 -> $doc.version = 1.3
1.1 -> $doc.version = 1.2
This actually is visible in the UI when you request the version list of
the document that is in version 1.4 you will be shown version
1.3,1.2,1.1 but no 1.4.
If you click on 1.3 then you will see document in the latest version. If
you make a diff between 1.3 and 1.2 then you will see in the UI "From
1.4 to 1.3".
I found that this problem depends on the initial version of the document
when it is first saved. This means that we should be able to detect the
issue for fixing the view as well as migrate the version file on save
when we see the problem.
Fix 1: change the UI to acknowledge this mistake (make only changes in
vm files) but no fix to saving
Fix 2: change $xwiki.getDocument(doc, version) and $doc.getRevisions
(and related) to send back the right data but no fix to saving
Fix 3: fix the problem in saving (move all versions by one if we detect
the problem), detect the issue (last RCS version not equal to current
doc version) to apply fix1 and fix2 for the display (probably easier to
do with fix 2)
I'm more favorable to fix 3 combined with fix 2.
WDYT ?
Ludovic
--
Ludovic Dubost
Blog: http://www.ludovic.org/blog/
XWiki: http://www.xwiki.com
Skype: ldubost GTalk: ldubost
AIM: nvludo Yahoo: ludovic
Hello all,
I have some features for which I need to write unit tests but it imply
HQL request difficult to cleanly emulate with jmock. Is there an over
way to tests theses ?
Ludovic talk to me about integrations tests that use the complete
platform with real database but he was not sure of this so I ask :)
Regards
--
Thomas Mortagne
Hi all,
I'd like to change the generated HTML markup in order to eliminate redundancy.
Currently, we're using too many class attributes for the generated
markup from the wiki syntax, and we're doing this in a bad manner. For
example:
- p class="paragraph"
- h2 class="heading-1"
- strong class="strong"
- del class="strike"
The class attribute should only be used with semantics in mind, and
saying that all p-s are paragraphs, and all strong-s are strong, this
adds no semantics whatsoever, but does increase the size of the
transfered files (and the page loading time), the rendering time, the
cache size and the size and complexity of the CSS files.
We might have to rewrite some CSS rules, as a downside, but I think it
is for the good. And it will also break some badly designed skins.
Sergiu
--
http://purl.org/net/sergiu
Hi I was using 1.1M3 successfully with AD Authentication. However, once i have upgraded to 1.1M4, i get an NPE. The LDAP config in xwiki.cfg is identical in both versions, and are as per documentation on xwiki.org.Regards Shiva ------------------------------------------------------------------------------------------------------ java.lang.NullPointerException at com.xpn.xwiki.user.impl.LDAP.LDAPAuthServiceImpl.authenticate(LDAPAuthServiceImpl.java:51) at com.xpn.xwiki.user.impl.xwiki.MyFormAuthenticator.authenticate(MyFormAuthenticator.java:195) at com.xpn.xwiki.user.impl.xwiki.MyFormAuthenticator.processLogin(MyFormAuthenticator.java:95) at com.xpn.xwiki.user.impl.xwiki.XWikiAuthServiceImpl.checkAuth(XWikiAuthServiceImpl.java:211) at com.xpn.xwiki.XWiki.checkAuth(XWiki.java:3000) at com.xpn.xwiki.user.impl.xwiki.XWikiRightServiceImpl.checkAccess(XWikiRightServiceImpl.java:112) at com.xpn.xwiki.XWiki.checkAccess(XWiki.java:3008) at com.xpn.xwiki.XWiki.prepareDocuments(XWiki.java:3881) at com.xpn.xwiki.web.XWikiAction.execute(XWikiAction.java:132) at org.apache.struts.action.RequestProcessor.processActionPerform(RequestProcessor.java:431) at org.apache.struts.action.RequestProcessor.process(RequestProcessor.java:236) at org.apache.struts.action.ActionServlet.process(ActionServlet.java:1196) at org.apache.struts.action.ActionServlet.doPost(ActionServlet.java:432) at javax.servlet.http.HttpServlet.service(HttpServlet.java:710) at javax.servlet.http.HttpServlet.service(HttpServlet.java:803) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:269) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:188) at com.xpn.xwiki.web.SetCharacterEncodingFilter.doFilter(SetCharacterEncodingFilter.java:117) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:215) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:188) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:210) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:174) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:117) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:108) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:151) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:870) at org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection(Http11BaseProtocol.java:665) at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:528) at org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(LeaderFollowerWorkerThread.java:81) at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:685) at java.lang.Thread.run(Unknown Source)
_________________________________________________________________
Express yourself instantly with MSN Messenger! Download today it's FREE!
http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/
I had no problem to install Xwiki on local computer under Tomcat.
But when I have deployed Xwiki under OC4J according to OC4J Installation
instructions
("http://www.xwiki.org/xwiki/bin/view/AdminGuide/InstallationOC4J"),
it seems javascript does not work properly – it looks like the path to
external .js-files cannot be found.
Both IE and Firefox show javascript errors nearly on each page, although
JavaScript is not deactivated.
For example, I can open the home page, go to
xwiki/bin/admin/XWiki/XWikiPreferences,
upload xwiki-enterprise-wiki-1.1~.xar, but cannot expand it to choose the
files I want to import.
I have tried to include some JavaScript functions from import.js direct in
the importinline.vm - source – it works fine.
What's the difference between:
<script type="text/javascript"
src="$xwiki.getSkinFile("import.js")"></script> - it generates path to
/xwiki/skins/albatross/import.js
and
<script type="text/javascript" src="$xwiki.getSkinFile("import.js",
true)"></script> - generates path to
/xwiki/bin/skin/skins/albatross/import.js
Why some paths to js- and css files are defined with the parameter “true”,
and some – without?
Is there something specific to keep in mind concerning path under OC4J?
Should I make additional entries in some xml-files?
Any help, please
Regards,
adoro
--
View this message in context: http://www.nabble.com/JavaScript-under-OC4J-tf4305991.html#a12257241
Sent from the XWiki- Dev mailing list archive at Nabble.com.
Hello,
There are only a few weeks left before the final 1.1 release. There
has been a lot of work put in this release (although even more work
was needed), and we've already started working on the first 1.2
milestone.
Past
A short summary of the closed issues thus far:
- 215 issues in xwiki-platform (102 bugs, 81 improvements, 15 new features)
- 32 issues in xwiki-enterprise
- 15 issues in panels-application
So this was mainly a bugfixing release, which means that now we have a
more stable platform, and an enjoyable default wiki. There have been
very few new features, as there was not enough manpower. The best
achievement in my opinion is the new build architecture, with the
platform separated from the default wiki, and internally separated
into several modules (core, web, plugins...).
Present
If everything goes right, we still have two more RC releases before
the final 1.1. These should not contain any changes (
http://en.wikipedia.org/wiki/Release_candidate#Release_candidate ),
but only critical fixes. That's why we should stop committing things
in the 1.1 branch, unless it is a critical bug fix.
In order to be able to make a proper release on the 27th, I'd propose
a code freeze on the 1.1 branch at 6 A.M. GMT 26th of August, with
everybody giving a hand on testing on sunday, and a quick release on
monday.
Future
We started with a list of expectations (
http://www.xwiki.org/xwiki/bin/view/Idea/FeaturesFor11 ) which was
only in very small parts covered, mostly because we concentrated on
bufixes. The good news is that we'll be able to concentrate on new
features from now on, and we can hope that most of these goals will be
covered in the 1.2 release.
However, there are still 162 issues marked as bugs in the platform (of
which 39 in the core), so there's still work on bugfixing.
The current WYSIWYG editor is cracking; every new fix/feature causes
another thing that was working before to fail, and we don't have
enough tests for the moment to automatically detect this. The
complexity is increasing, which makes the editor unusable on slow
systems or for large documents. With Nam leaving, we won't have a
person that knows the code well to take his place. This is why we must
concentrate on the new GWT-based editor (
http://www.xwiki.org/xwiki/bin/view/Idea/WikiModel+and+GWT+Wyswiyg+Architec…
) and hope that in 3 months we'll have a fully functional editor.
Another direction would be the component-based architecture. Vincent
already committed a proof-of-concept in
xwiki-sandbox/xwiki-components, which looks good, but contains very
few things. It seems easy to write in this manner, so we should try
and have a working core based on this architecture.
Thanks to all that contributed to the 1.1 release,
Sergiu
--
http://purl.org/net/sergiu
Hi Catalin,
On 8/18/07, Catalin Hritcu <catalin.hritcu(a)gmail.com> wrote:
>
> Asiri,
>
> I would go with 1, or 3 but done on the client instead of wasting time
> writing emails. The xml-rpc interface is not only for XEclipse to use
> and it will stay as general and clear as possible.
Hmmmm... That sounds like a good idea.
I think we could go with the third option but still on the client side. And
the amount of work to be done would be really less. I didn't think about
this before, thanks.... (still, i need to check what needs to be changed).
But anyway, I'm waiting for Vincent's confirmation.
Regards,
- Asiri
Catalin
>
> On 8/17/07, Asiri Rathnayake <asiri.rathnayake(a)gmail.com> wrote:
> > Hi Catalin,
> >
> >
> > On 8/17/07, Catalin Hritcu <catalin.hritcu(a)gmail.com> wrote:
> > > Hi Asiri,
> > >
> > > On 8/17/07, Asiri Rathnayake <asiri.rathnayake(a)gmail.com> wrote:
> > > > Hi Catalin and all,
> > > >
> > > > On 8/17/07, Catalin Hritcu < catalin.hritcu(a)gmail.com> wrote:
> > > > > Hi Asiri,
> > > > >
> > > > > Why don't you use the space key? It used to be that the title was
> > > > > always set to this key. If you were setting a title different then
> the
> > > > > key then this title was just discarded and the key was returned.
> That
> > > > > was not normal.
> > > > >
> > > > > Now about space titles being empty, this is a possible situation
> in
> > > > > XWiki (document titles can also be empty). If you want to treat
> this
> > > > > situation differently why not do it on the client side ? And if
> you
> > > > > need to use the space key, then just use the space key and forget
> > > > > about the title.
> > > >
> > > > This is the issue, at the beginning of XEclipse, we thought a key
> was
> > > > something that should be used to refer to documents within programs
> (not
> > > > displayed to users) - This is the purpose of a key (a unique
> > identifier). I
> > > > think it is necessary we keep this terminology since otherwise we'll
> > violate
> > > > the whole purpose of a key (please someone correct me if this is not
> the
> > > > purpose of a key).
> > > >
> > > Yes, a key does identify a space, but it is not cryptic like the IDs
> > > used in the API (the IDs are numbers in confluence, and opaque strings
> > > in XWiki). You can display a key to an user without problems. So yes,
> > > keys are identifiers, and no keys are not supposed to be hidden from
> > > the user like the PageID, CommentID etc.
> >
> > Isn't the whole point of having a space name / title is to display it
> > whenever possible ? I mean, if we use space keys in XEclipse, that means
> > we're not being user friendly - assuming titles are more expressive than
> > keys.
> >
> > > > Now titles on the other hand are what users understand
> > > > (what we should display to them) and I think we should not allow
> them to
> > be
> > > > empty - but in case if a title is not available, we can use the key
> > (since
> > > > there is no other option).
> > > >
> > > Yes, titles (or space names) can be more expressive. In particular
> > > they can contain spaces, be longer etc. In XWiki they are displayed in
> > > a special field on top of the edit box (which btw is empty by
> > > default).
> > >
> > > Most important these two properties of a space can be changed
> > > independently, and the value of one should not influence the value of
> > > the other. This is what the current implementation does.
> >
> > Agreed.
> >
> > > > So in summary, XEclipse was developed with the assumptions,
> > > >
> > > > 1. Keys should be used whenever we refer to documents within
> programs
> > (like
> > > > when invoking XMLRPCs).
> > > >
> > > > 2. Keys should be mapped into titles (or names) when a document is
> > presented
> > > > to a user.
> > > >
> > > I think you make a major confusion between space keys and IDs. They
> > > are not the same, see above. Your statements here are true only for
> > > IDs not for space keys.
> >
> > Ok, didn't know about this. The word "key" always brings a cryptic
> > identifier to my mind....
> >
> > > > We can change XEclipse to use keys only and forget about titles, but
> > that
> > > > will take some more time. And most importantly, this might affect
> > XEclipse
> > > > on XWiki 1.1.
> > > >
> > > Not true. On XWiki 1.1 the title/name was always equal to the key, so
> > > whenever you thought you were using the title/name you were actually
> > > using the key. Now you would use the key explicitly.
> > > > Anyway, in my personal opinion, i think it's necessary we keep the
> > > > distinction between keys and titles intact.
> > > >
> > > This is exactly what i did. They used to be the same, now there is a
> > > clear distinction between the two.
> >
> > I too thought of them separately and expected them to be different.
> Anyway,
> > with the current scheme, we cannot use space names / titles alone on
> > XEclipse since some names can be empty (as you said). So now there are
> three
> > possibilities,
> >
> > 1. Use space keys only in client (for everything) - Then what is the
> use
> > of space names / titles ? <-- have to answer if we are to go with this
> > option. And this requires XEclipse to be changed.
> >
> > 2. Enforce spaces to have a title ( a.k.a not ""). <-- Ideal scenario.
> >
> > 3. Use titles / names whenever they are available and switch to space
> keys
> > otherwise - this should be done on server (see my patch). <-- This is
> > possible since space keys and titles / names can be changed
> independently.
> > The only disadvantage of this scheme is that sometimes users get to see
> a
> > title / name of a space which is not the actual title (when actual title
> is
> > "").
> >
> > I would go with the third option.
> >
> > What would you think ?
> >
> > Regards,
> >
> > - Asiri
> >
> >
> > > Regards,
> > > Catalin
> > >
> > > > > On 8/17/07, Asiri Rathnayake <asiri.rathnayake(a)gmail.com> wrote:
> > > > > > Hi All,
> > > > > >
> > > > > > Sorry about the late response. Busy with academic work :(
> > > > > >
> > > > > > The patch attached will fix the XMLRPC issue related to
> XEclipse.
> > Please
> > > > > > verify it and let me know what you think.
> > > > > > I tested XEclipse with this patch and everything is normal now.
> > > > > >
> > > > > > Regards,
> > > > > >
> > > > > > - Asiri
> > > > > >
> > > > > >
> > > > > > On 8/16/07, Catalin Hritcu <catalin.hritcu(a)gmail.com > wrote:
> > > > > > > Hi,
> > > > > > >
> > > > > > > I updated the xml-rpc implementation on trunk. There are big
> > changes
> > > > > > > so be careful when updating since some of the changes are
> > > > > > > incompatible.
> > > > > > > - all non-string primitive types (like date and int) are now
> > encoded
> > > > to
> > > > > > strings
> > > > > > > the easiest to adapt to this is to start using swizzle which
> makes
> > the
> > > > > > > translation automatic
> > > > > > > - the way all identifiers are built has changed
> > > > > > > anyway, ids should be treated as opaque handlers, so if you
> ever
> > find
> > > > > > > yourself parsing them then you are doing something wrong.
> > > > > > > - the way the page history is different now
> > > > > > > only old versions of the page are considered, and they can be
> > accessed
> > > > > > > like regular pages
> > > > > > >
> > > > > > > There are other smaller fixes, but these are the most
> important
> > ones.
> > > > > > >
> > > > > > > Regards,
> > > > > > > Catalin
> > > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > >
> > > >
> > > >
> > >
> >
> >
>
Hi,
I updated the xml-rpc implementation on trunk. There are big changes
so be careful when updating since some of the changes are
incompatible.
- all non-string primitive types (like date and int) are now encoded to strings
the easiest to adapt to this is to start using swizzle which makes the
translation automatic
- the way all identifiers are built has changed
anyway, ids should be treated as opaque handlers, so if you ever find
yourself parsing them then you are doing something wrong.
- the way the page history is different now
only old versions of the page are considered, and they can be accessed
like regular pages
There are other smaller fixes, but these are the most important ones.
Regards,
Catalin
Hi Vincent,
We have completed the documentation for XEclipse. Please verify it and let
us know if there's anything else need to be done.
http://www.xwiki.org/xwiki/bin/view/Code/XEclipseExtension
Also, what else do we need in order to make an XEclipse release ?
Waiting your reply.
- Tharindu & Asiri
On 8/17/07, Vincent Massol <vincent(a)massol.net> wrote:
>
>
> On Aug 16, 2007, at 6:58 PM, tharindu jayasuriya wrote:
>
> Hi Vincent,
>
> On 8/16/07, Vincent Massol <vincent(a)massol.net> wrote:
> >
> > fyi-Vincent
> >
> > Begin forwarded message:
> >
> > *From: * Vincent Massol <vincent(a)massol.net>
> > *Date: * August 16, 2007 8:52:12 AM CEDT
> > *To: * xwiki-dev(a)objectweb.org
> > *Subject: * *Re: [xwiki-dev] XEclipse Documentation*
> >
> >
> > On Aug 14, 2007, at 10:14 PM, Guillaume Lerouge wrote:
> >
> > What about going to (direct address bar typing) http://www.xwiki.org/xwiki/bin/view/Code/XEclipseExtensionDocumentation
> >
> > -> you will be offered to create the page from a blank template, without
> > the usual table. Then you can link to it from the XEclipse Extension usual
> > ExtensionClass page...
> >
> > 1. You keep the page in the same space
> > 2. You get all the freedom you want
> >
> > WDYT?
> >
> > Vincent, is there any problems about doing this?
> >
> >
> > I'm pretty convinced we might need more than one documentation page for
> > some stuff in the future but the need hasn't arisen yet. I'm not sure this
> > is required yet for the XEClipse extension as one page should be good enough
> > to start with.
> >
> > What we do need is to improve Extension style sheet as I've done for the
> > Application style sheet.
> >
> > Asiri, can you check an application page and tell me if you like it
> > more?
> >
> >
> Ok, just saw this mail. This is suitable for the documentation. Shall I
> add an Application page and remove the Extension page for XEclipse ?
>
>
> Nope... This is an extension not an application.
>
> This is what I meant:
> http://www.xwiki.org/xwiki/bin/view/Code/XEclipseExtension
>
> Now you can edit and finish the documentation.
>
> Thanks
> -Vincent
>
>
Hi (Catalin),
I think the XMLRPC API has been modified in XWiki 1.1M4. Is that
correct?
If so, we really must specify in the release notes what has been
changed as otherwise users who had XMLRPC code will see their code
failing.
In addition, XMLRPC in xwiki core 1.2-snapshot seem to have broken
lots of APIs too.
I think we need to:
1) slowly review each modification/breakage and decide if we want it.
Also we need to decide if we can avoid breaks by deprecating existing
APIs instead.
2) document each single API break in the release notes for XWiki 1.2M1
Last, because of this I believe the XEclipse plugin doesn't work
anymore... :-(
I wanted to release the Eclipse plugin today but I can't. We need to
decide if we want XWiki 1.1 compatibility and/or XWiki 1.2
compatibility.
2 solution if we want compatibility with both:
- XWiki 1.2 doesn't break compatibility
- XEclipse has logic to make it work with both
WDYT?
Thanks
-Vincent
Hi Tharindu/Asiri,
I'm trying to create a m2 build for xeclipse. I think I have it
almost done.
However when I open the xeclipse project in Eclipse Europa, when I
open the plugin.xml file, if I click on "launch an eclipse
application" in the overview tab, I don't see the xeclipse
perspective. The plugin is loaded correctly though.
Have you tried it with Eclipse Europa?
Thanks
-Vincent
Hi All,
Tharindu has prepared initial documentation for XEclipse which is available
at,
http://www.xwiki.org/xwiki/bin/view/Code/XEclipseExtention
I thought it would be better if we remove the attached msword doc file and
put all the stuff in the wiki document itself.
WDYT ?
Regards,
- Asiri
Hi
I was using 1.1M3 successfully with AD Authentication. However, once i have
upgraded to 1.1M4, i get an NPE. The LDAP config in xwiki.cfg is identical
in both versions.
Regards
Shiva
------------------------------------------------------------------------------------------------------
java.lang.NullPointerException
at
com.xpn.xwiki.user.impl.LDAP.LDAPAuthServiceImpl.authenticate(LDAPAuthServiceImpl.java:51)
at
com.xpn.xwiki.user.impl.xwiki.MyFormAuthenticator.authenticate(MyFormAuthenticator.java:195)
at
com.xpn.xwiki.user.impl.xwiki.MyFormAuthenticator.processLogin(MyFormAuthenticator.java:95)
at
com.xpn.xwiki.user.impl.xwiki.XWikiAuthServiceImpl.checkAuth(XWikiAuthServiceImpl.java:211)
at com.xpn.xwiki.XWiki.checkAuth(XWiki.java:3000)
at
com.xpn.xwiki.user.impl.xwiki.XWikiRightServiceImpl.checkAccess(XWikiRightServiceImpl.java:112)
at com.xpn.xwiki.XWiki.checkAccess(XWiki.java:3008)
at com.xpn.xwiki.XWiki.prepareDocuments(XWiki.java:3881)
at com.xpn.xwiki.web.XWikiAction.execute(XWikiAction.java:132)
at
org.apache.struts.action.RequestProcessor.processActionPerform(RequestProcessor.java:431)
at
org.apache.struts.action.RequestProcessor.process(RequestProcessor.java:236)
at org.apache.struts.action.ActionServlet.process(ActionServlet.java:1196)
at org.apache.struts.action.ActionServlet.doPost(ActionServlet.java:432)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:710)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:803)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:269)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:188)
at
com.xpn.xwiki.web.SetCharacterEncodingFilter.doFilter(SetCharacterEncodingFilter.java:117)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:215)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:188)
at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:210)
at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:174)
at
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
at
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:117)
at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:108)
at
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:151)
at
org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:870)
at
org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection(Http11BaseProtocol.java:665)
at
org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:528)
at
org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(LeaderFollowerWorkerThread.java:81)
at
org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:685)
at java.lang.Thread.run(Unknown Source)
--
View this message in context: http://www.nabble.com/1.1M4%3A-NPE-IN-LDAP-Authentication-tf4278846.html#a1…
Sent from the XWiki- Dev mailing list archive at Nabble.com.
The XWiki development team team is pleased to announce the
availability of the 1.1 Milestone 4 release of XWiki Enterprise
Go grab it on http://www.xwiki.org/xwiki/bin/view/Main/Download
Main changes:
* New experimental Lucene Search page. It adds scoring,
searching into attachments (including Office documents), search
paging and more (performance improvements, more customizable search
results, etc). This search page is meant to become the default in the
near future. It's currently experimental as we want to ensure it
fully works as well as the old search. We need your help. Please let
us know on the XWiki mailing list, on IRC, or on this wiki if you
have any comments (positive or negative about it). This new page is
located in Main.LuceneSearch. You can also edit the Panels.Search
page so that the search is done with the Lucene search by default.
* Diff improvements. Diffs are now shown at the level of words.
* Added an option to open external link to new window. Default
is in the same window.
* When deleting a page, the list of pages that will be orphaned
are displayed
* Added a wiki text mode in the WYSIWYG editor
* Code macro now escapes everything (wiki syntax, HTML, Groovy,
Velocity, other Radeox macros)
* New option to preserve previous version during document import
* Several XMLRPC fixes and improvements
* MacroMapping renderer is enabled by default
* Added plaincode template allowing to access the source of a
page without any encoding
* Option not to display the login screen
* Allow {style} macros to be nested
* Fullscreen editing in both wiki and WYSIWYG editors
* Scheduler plugin added (but no UI yet)
* New XMLRPC removeSpace() API
* New Quick Links Panel with links to common useful pages
* New "My Recent Modifications" Panel
* Moved Orphaned Pages inside the AllDocs page as a new tab
* Improved navigation by adding the Quick Links Panel + My
Recent Modifications Panel to the side menu and removed the
Navigation panel from the default layout
* Improved the Tag page
* Search also searches on page names now
* Added new RSS Feeds page to list all feeds available on the wiki
+ lot more (over a 100 in total)
See the full release notes on http://www.xwiki.org/xwiki/bin/view/
Main/ReleaseNotesXWikiEnterprise11M4
Enjoy
-The XWiki development team
Hello.
I would like to discuss about some aspect of my work on XWIKI-543
(recycle bin) and XWIKI-1459 (new history storage).
1. [Proposal] Use common.lang.builders & AbstractSimpleClass
When i write simple entity classes (POJO), i wouldn't like to implement
equals, hashcode, toString by hand for first time (it has too much
duplication). commons.lang.builders has fine builders for this. These
builders can do these tasks via reflections.
http://commons.apache.org/lang/api-release/org/apache/commons/lang/builder/…
Can i create class "com.xpn.xwiki.util.AbstractSimpleClass" (maybe
another name?) with these methods implemented via common.lang.builders
(via reflections) for extending in my entities? I think it will be
useful for others too.
Implementation: http://rafb.net/p/G0OcJ427.html
as +:
+ we will get equals(), hashCode() and nice toString() for free :).
+ we can always override these methods later if we will have some issues
+ we can easy switch toString() style in all extended classes
- note: it is only for simple entities with no not-store specific
fields. (So XWikiDocument is inapplicable i think)
WDYT?
2. While i designed how to store history and recycle bin entities i
found similar problems.
I have following data in my entities:
- id
- metadata (several fields)
- content (one field)
One use case is fetch many metadatas for display. (i.e. history summary)
Another use case is load one or several content to some hard work. (i.e.
load old document from history, restore document from recycle bin)
So problems is separate fetching metadata and content. How can i do it?
1) If i put all data in one class, i have to fetch all data via
session.load and hql query.
2) It is possible to configure hibernate with 2 separate entity-name for
one class and one table. So if we use specific entity-name, we fetch
only metadata and content will be null. But i haven't tested it yet. It
looks like hack.
3) solution i have for now is following:
divide entity to EntityInfo and EntityContent. Both has id. You can
see my solution it in patches at XWIKI-1459.
Only defect is increase number of entities.
Maybe there is another way? Or another design?
--
Artem Melentyev
Hi devs,
As previously agreed, I have created a branch for work on 1.1RC1/RC2
in the following modules:
* platform/core
* platform/web
* products/enterprise
* platform/applications/panels
For all those modules trunk becomes 1.2-SNAPSHOT.
This means that if you make a change to the 1.1 branch you MUST also
merge that change to the trunk or it'll be lost forever...
Thanks
-Vincent
Hi,
We have delayed the 1.1M4 release so the 1.1RC1 release is now too
close I think (planned for the 20th).
I propose we move it to the 27th. We'll then see if we have many more
bugs to fix for RC2 and take a call then if we have to delay the
final release by a few day or not.
WDYT?
Thanks
-Vincent