Hi devs,
I was trying to make XEM work with HSQLDB and... I have succeeded :)
The only problem I have is that DBCP doesn't seem to work with Hibernate. For some weird reasons when we do a SET SCHEMA it makes calls to fail afterwards. In any case if I configure Hibernate to not use DBCP all work just fine.
I've googled around and found that there are lots of people complaining about DBCP.
I've googled for what connection pooling library to use and I've found that most people are recommending BoneCP (http://jolbox.com/).
See:
* http://stackoverflow.com/questions/5640146/java-jdbc-connection-pool-librar…
* http://www.jorambarrez.be/blog/2012/04/30/dbcp_vs_c3p0_bonecp/
* http://stackoverflow.com/questions/8057110/java-database-connection-pool-bo…
The other thing is that we currently have some 300 line of code that we shouldn't have at all and that we need in XWiki just for handling DBCP (see com.xpn.xwiki.store.DBCPConnectionProvider).
The pro of BoneCP is that it seems to be the fastest, see http://jolbox.com/benchmarks.html
So here's what I'd like to propose:
* We move DBCPConnectionProvider to a legacy module
* We bundle the bonecp jar by default
* We configure our hibernate.cfg.xml by default to use boneCP:
<property name="bonecp.idleMaxAge">240</property>
<property name="bonecp.idleConnectionTestPeriod">60</property>
<property name="bonecp.partitionCount">3</property>
<property name="bonecp.acquireIncrement">10</property>
<property name="bonecp.maxConnectionsPerPartition">60</property>
<property name="bonecp.minConnectionsPerPartition">20</property>
<property name="bonecp.statementsCacheSize">50</property>
<property name="bonecp.releaseHelperThreads">3</property>
<property name="connection.provider_class">com.jolbox.bonecp.provider.BoneCPConnectionProvider</property>
What this means:
* Existing users of XWiki will not have to change anything, it'll still work
* New users will use bonecp without knowing
* Existing users can migrate to bonecp just by changing one line in their hibernate.cfg.xml file
I'd love to do this for 4.3 but we're already quite advanced in the 4.x cycle. That said it's just a one line change in hibernate.cfg.xml in case of problem to go back to DBCP so we could do this for 4.3 which leaves us 4.3, 4.4 and 4.5 to test this out. And if later on we find an issue we'll always be able to release a 4.5.1 that has this one line change to go back to DBCP.
WDYT?
Here's my +1 for this action plan.
Thanks
-Vincent
Hi devs,
Current situation:
* on http://www.xwiki.org/xwiki/bin/view/ReleaseNotes/ we have separated the RN into 2 parts: XE and XEM.
* in the RN for XE we put all platform release notes, even release notes for modules in platform that are not bundled with XE (IRC Bot for ex).
* It's normal to have release notes for everything we release, not just XE or XEM
Proposal:
* Have only a single release note page for each release (ie no more specific XEM release notes + always make sure to document all releases modules in the RN, not just what is bundled with XE). I propose to name this "XWiki" instead of "XWiki Enterprise". So we would have "XWiki 4.3" for ex.
* The URL for 4.3M1 would be (for ex): http://www.xwiki.org/xwiki/bin/view/ReleaseNotes/ReleaseNotesXWiki43M1
I propose to do this ASAP for 4.2 final (I can do the refactoring).
Here's my +1
Thanks
-Vincent
Hi devs,
It's a best practice that unit tests must not output anything to the console. Rationale:
* It pollutes the maven logs unnecessarily. For example imagine that you're expecting an error in your test and that the stacktrace is logged to the console. When looking at the maven console logs the reader will wonder if there was an error or if it was expected.
* The test must assert whatever it needs to validate the code under test. So if it expects a log to be printed it should assert it.
In order to make this easy I've just added JUnit LogRule to our commons test framework.
Here's a usage example:
public class RestrictParseLocationEventHandlerTest
{
private RestrictParseLocationEventHandler handler = new RestrictParseLocationEventHandler();
/**
* Capture logs with WARN or higher severity to assert them.
*/
@Rule public LogRule logRule = new LogRule() {{
record(LogLevel.WARN);
recordLoggingForType(RestrictParseLocationEventHandler.class);
}};
@Test
public void includeEventWhenIllegalPath()
{
Assert.assertNull("Template shouldn't have been returned",
this.handler.includeEvent("../WEB-INF/xwiki.cfg", "xwiki:Main.WebHome", "parse"));
Assert.assertEquals(1, this.logRule.size());
Assert.assertTrue(this.logRule.contains(
"Direct access to template file [/WEB-INF/xwiki.cfg] refused. Possible break-in attempt!"));
}
}
So this is a vote to agree on this best practice and to document it on dev.xwiki.org.
Here's my +1
If you agree then please make sure your tests don't output anything from now on and please try fixing the tests you wrote that do...
Thanks
-Vincent
The XWiki development team is proud to announce the availability of XWiki
Enterprise 4.2 Release Candidate 1.
This is the first and hopefully final release candidate of the 4.2 release
cycle. Being a release candidate, this release contains bugfixes and
polishing, most of them focused on the new distribution wizard.
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/ReleaseNotesXWikiEnterpris…
Thanks
-The XWiki dev team
Hello,
Since XWiki support user accounts, enabling visitors to create an account
and sign in to the site, Can you tell me if It's possible with a little bit
of effort track the activity of logged users? This can include recording
activities such as what pages were visited as well as what actions were
performed. May be it is possible implementing a plugin with Velocity or
extracting the data from database. Have any idea how to do it?
Thanks!!
--
*Ezequiel Scott**
*
ezequielscott(a)gmail.com
Hello developers,
I've been experimenting a little bit into running things in the background on our xwiki 3.5: as part of a velocity delivered page, I am calling groovy code. That code launches a thread in the background which runs for 1000 seconds checking if it can:
- use the context's toString
- call context.getContext()
- use the xwiki object that was passed around
My current conclusion is that context.getContext() fails (with an NPE trying to check programming rights) but others work.
Is this the intended behavior?
Is there a way for me to get another context to run in the background?
thanks in advance
Paul
:D
I left off with Xwiki/Solr a few weeks ago.
Are there plans to move it into the main project any time soon?
________________________________
This communication (including all attachments) is intended solely for
the use of the person(s) to whom it is addressed and should be treated
as a confidential AAA communication. If you are not the intended
recipient, any use, distribution, printing, or copying of this email is
strictly prohibited. If you received this email in error, please
immediately delete it from your system and notify the originator. Your
cooperation is appreciated.