After user logout from the XWiki, following exception occurs:
2013-07-11 12:38:47,440
[http://localhost:8080/xwiki/bin/logout/XWiki/XWikiLogout?xredirect=/xwiki/b…] ERROR c.x.x.w.XWikiAction - Cannot send action notifications for document [XWiki.XWikiLogout using action [logout]
java.lang.StackOverflowError: null
at
java.net.AbstractPlainSocketImpl.available(AbstractPlainSocketImpl.java:455) ~[na:1.6.0_27]
at java.net.SocketInputStream.available(SocketInputStream.java:234)
~[na:1.6.0_27]
at
com.mysql.jdbc.util.ReadAheadInputStream.fill(ReadAheadInputStream.java:72) ~[mysql-connector-java-5.1.25-bin.jar:na]
at
com.mysql.jdbc.util.ReadAheadInputStream.readFromUnderlyingStreamIfNecessary(ReadAheadInputStream.java:161) ~[mysql-connector-java-5.1.25-bin.jar:na]
at
com.mysql.jdbc.util.ReadAheadInputStream.read(ReadAheadInputStream.java:189) ~[mysql-connector-java-5.1.25-bin.jar:na]
at com.mysql.jdbc.MysqlIO.readFully(MysqlIO.java:3116)
~[mysql-connector-java-5.1.25-bin.jar:na]
at com.mysql.jdbc.MysqlIO.reuseAndReadPacket(MysqlIO.java:3570)
~[mysql-connector-java-5.1.25-bin.jar:na]
at com.mysql.jdbc.MysqlIO.reuseAndReadPacket(MysqlIO.java:3559)
~[mysql-connector-java-5.1.25-bin.jar:na]
at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:4110)
~[mysql-connector-java-5.1.25-bin.jar:na]
at com.mysql.jdbc.MysqlIO.sendCommand(MysqlIO.java:2570)
~[mysql-connector-java-5.1.25-bin.jar:na]
at com.mysql.jdbc.MysqlIO.sqlQueryDirect(MysqlIO.java:2731)
~[mysql-connector-java-5.1.25-bin.jar:na]
at com.mysql.jdbc.ConnectionImpl.execSQL(ConnectionImpl.java:2809)
~[mysql-connector-java-5.1.25-bin.jar:na]
at
com.mysql.jdbc.ConnectionImpl.rollbackNoChecks(ConnectionImpl.java:5165)
~[mysql-connector-java-5.1.25-bin.jar:na]
at com.mysql.jdbc.ConnectionImpl.rollback(ConnectionImpl.java:5048)
~[mysql-connector-java-5.1.25-bin.jar:na]
at
org.apache.commons.dbcp.DelegatingConnection.rollback(DelegatingConnection.java:368) ~[commons-dbcp-1.3.jar:1.3]
at
org.apache.commons.dbcp.DelegatingConnection.rollback(DelegatingConnection.java:368) ~[commons-dbcp-1.3.jar:1.3]
at
org.apache.commons.dbcp.PoolableConnectionFactory.passivateObject(PoolableConnectionFactory.java:685) ~[commons-dbcp-1.3.jar:1.3]
at
org.apache.commons.pool.impl.GenericObjectPool.addObjectToPool(GenericObjectPool.java:1379) ~[commons-pool-1.5.4.jar:1.5.4]
at
org.apache.commons.pool.impl.GenericObjectPool.returnObject(GenericObjectPool.java:1342) ~[commons-pool-1.5.4.jar:1.5.4]
at
org.apache.commons.dbcp.PoolableConnection.close(PoolableConnection.java:90) ~[commons-dbcp-1.3.jar:1.3]
at org.apache.commons.dbcp.PoolingDataSource
$PoolGuardConnectionWrapper.close(PoolingDataSource.java:191)
~[commons-dbcp-1.3.jar:1.3]
at
com.xpn.xwiki.store.DBCPConnectionProvider.closeConnection(DBCPConnectionProvider.java:236) ~[xwiki-platform-legacy-oldcore-4.5.3.jar:na]
at
org.hibernate.jdbc.ConnectionManager.closeConnection(ConnectionManager.java:474) ~[hibernate-core-3.6.9.Final.jar:3.6.9.Final]
at
org.hibernate.jdbc.ConnectionManager.cleanup(ConnectionManager.java:408)
~[hibernate-core-3.6.9.Final.jar:3.6.9.Final]
at
org.hibernate.jdbc.ConnectionManager.close(ConnectionManager.java:347)
~[hibernate-core-3.6.9.Final.jar:3.6.9.Final]
at org.hibernate.impl.SessionImpl.close(SessionImpl.java:343)
~[hibernate-core-3.6.9.Final.jar:3.6.9.Final]
at
com.xpn.xwiki.store.XWikiHibernateBaseStore.closeSession(XWikiHibernateBaseStore.java:993) ~[xwiki-platform-legacy-oldcore-4.5.3.jar:na]
at
com.xpn.xwiki.store.XWikiHibernateBaseStore.endTransaction(XWikiHibernateBaseStore.java:954) ~[xwiki-platform-legacy-oldcore-4.5.3.jar:na]
at
com.xpn.xwiki.store.XWikiHibernateStore.releaseAllLocksForCurrentUser(XWikiHibernateStore.java:1749) ~[xwiki-platform-legacy-oldcore-4.5.3.jar:na]
... few hundred lines here ...
at
com.xpn.xwiki.store.XWikiHibernateStore.releaseAllLocksForCurrentUser(XWikiHibernateStore.java:1768) ~[xwiki-platform-legacy-oldcore-4.5.3.jar:na]
Maybe there is something wrong with used SAML STS authentcation
(suspected code can be found at
https://github.com/ValdisVitolins/munixwiki/blob/master/tools/xwiki-authent…
) though I didn't find any reasonable differences from
https://github.com/xwiki-contrib/sandbox/blob/master/authenticators/xwiki-a…
...
Thanks in advance for any idea!
Valdis
Hi devs,
Today I needed to see all the features that were added since XWiki 2.4 and that got me thinking about how to document new feature or improvements on xwiki.org.
I started imagining the following:
* To have an xclass representing an improvement or feature, with several properties:
- the version in which the feature or improvement was added
- whether it's an improvement or a feature
- the description of the improvement or feature (textarea), in wiki syntax
* On a given page, add as many xobjects that there are features or improvements
* Create a wiki macro to include the xobject's content in the page content so that the user can see it when viewing the page
Pros:
* This would allow to be able to query the full wiki to see all the features/improvements added in a given version
* This would allow to auto generate the release notes :) We wouldn't need to duplicate the content in both the release notes and in the reference document.
* This would allow to automatically add some "new" icons when the version corresponding to the improvement/new feature is newer than the baseline version (for example, if we're developing version N we can say that on xwiki.org we consider a feature/improvement to be "new" when its corresponding version is >= N-2)
Cons:
* A lot of work to convert the existing xwiki.org content to this but we don't need to do that upfront. We can start by agreeing that any new feature/improvement would go through this mechanism for example.
* A bit more complex to add new content for users but this mechanism doesn't preclude using the current way (ie unstructured content) as it'll still work.
WDYT? Do you think this could be useful?
Thanks
-Vincent
The XWiki development team is proud to announce the availability of XWiki 5.1.
This release comes with Solr search enabled by default. The search UI
has been redesigned and the search backend has been greatly improved.
A new Menu application is now avaible to help you create navigation
menus that ca be placed after the header or in a side panel. Beside
this, a lot of bug fixes (124) and small improvements (53) make this
release worth trying.
You can download it here: http://www.xwiki.org/xwiki/bin/view/Main/Download
Make sure to review the release notes:
http://www.xwiki.org/xwiki/bin/view/ReleaseNotes/ReleaseNotesXWiki51
Thanks
-The XWiki dev team
Hi,
Would it be possible to reactivate xeclipse build on jenkins.xwiki.org, or
at least force a build with the current code ? This would allow to get some
snapshot of the current 2.0 status.
Thanks
Ludovic
--
Ludovic Dubost
Founder and CEO
Blog: http://blog.ludovic.org/
XWiki: http://www.xwiki.com
Skype: ldubost GTalk: ldubost
Hi devs,
I know XWiki 5.1 is going to be released today. Sorin and me are currently
testing Solr and I already tested most of the Jira Tickets Marked as Fixed
in the Release Notes<http://www.xwiki.org/xwiki/bin/view/TestReports/ManualTestReportXWiki51#HJi…>.
Is there anything else you want us to test ?
Thanks,
Manuel
Hi devs,
I saw that Marius and Thomas put as assignee the contributor who created the PR today:
* http://jira.xwiki.org/browse/XWIKI-9316
* http://jira.xwiki.org/browse/XWIKI-9232
Thus I've done the same for:
* http://jira.xwiki.org/browse/XWIKI-7403
I was under the impression that till now we were always using a committer as the assignee in JIRA. The main reason we were doing this is that it's the committed code becomes the committer's responsibility in case the code causes some issues.
The cons are:
* Less recognition of the contributor (even though he appears in the SCM thanks to GitHub's PR).
* He won't appear in the BFD reports. For example: http://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=11604
I'm fine either way but it would be good to have an agreement on what strategy we wish to follow.
Thanks
-Vincent
Hi Devs,
Passing CLIRR is far from sufficient to stay backward compatible or
document incompatible changes !
I know that you know that already, but I want you to remind it once more
because while I was on the road showcasing a site, I had to discover that a
major feature of the site got broken, and it was silently true for a while
apparently. I missed some potential leads, which get me really upset, so I
waited a while before writing.
The cause was a very simple incompatible change introduced in 4.3M2 !
But tracking it down was not easy since this API breakage was not reported
in the RN.
Here it is:
com.xpn.xwiki.objects.classes.PropertyClass#getClassType is no more
reporting the full classname of the type, but now drop the "Class" suffix.
So, "com.xpn.xwiki.objects.classes.StringClass" become "String",
"com.xpn.xwiki.objects.classes.NumberClass" become "Number"... and so on.
The unprivileged API com.xpn.xwiki.api.PropertyClass#getClassType() was
also impacted since "StringClass" become "String", "NumberClass" become
"Number" and so on.
The javadoc of the latter function get updated, meaning that we were really
conscious a breakage was done here. Even more conscious, the following was
applied in the toXML() method:
String classType = getClassType();
if (this.getClass().getSimpleName().equals(classType + "Class")) {
// Keep exporting the full Java class name for old/default property
types to avoid breaking the XAR format
// (to allow XClasses created with the current version of XWiki to be
imported in an older version).
classType = this.getClass().getName();
}
The com.xpn.xwiki.objects.meta.MetaClass was also, since it was using those
name as property names. Some compatibility change was applied as well, with
explicit comments.
But apparently, no one notice (including myself !), and this incompatible
change goes through without even a mention in the RN, nor in the the jira
issue (XWIKI-8355).
So guys, I have no intend to blame anyone here, but I couldn't warn you
more about potential consequence of incompatible changes. These need to be
discuss, or at least clearly mentioned in the RN. Do not rely on CLIRR for
doing the job, it don't.
Probably adding a mention about those changes in the RN of 4.3 is better
now than never, Marius, could you take care of it ?
Thanks for your attention,
--
Denis Gervalle
SOFTEC sa - CEO
eGuilde sarl - CTO