That is OK too.
Thx,
Harry
Op 22 dec. 2013 21:36 schreef "Juan Pablo Santos Rodríguez" <
juanpablo.san...@gmail.com>:
> Hi Harry,
>
> I think I've come up with what's causing the stacktrace, I've tried with
> $svn/tags/jspwiki_2_9_1_rc2 and, the class being basically the same, these
> stacktrace
Hi Harry,
I think I've come up with what's causing the stacktrace, I've tried with
$svn/tags/jspwiki_2_9_1_rc2 and, the class being basically the same, these
stacktraces don't show up. However, there's one significant difference on
.check():
catch( EmptyStackException e )
{
// FIXME: Do somethi
Juan Pablo,
I had a further look at the WatchDog issue.
First, the overhead is quite minimal, we have just one extra thread, that
regularly "opens the kennel" and checks the WatchDogs.
Now, the EmptyStackException is just a simple bug in WatchDog.check(), I'd
like to fix it with a simple extra che
Hi,
I'm moving open issues on JIRA scheduled for 2.10 version to 2.10.1 and
calling the vote in a few minutes. Regarding the staging repo, I've opened
https://issues.apache.org/jira/browse/INFRA-7125 to track what's happening
with it. We'll have the old-good fashioned convenience binaries meanwhil
+1
Checks for long running threads are made by the appserver.
Jürgen
Am 19.12.2013 06:54 schrieb "Harry Metske" :
> Also, I was wondering why we need this WatchDog thing altogether.
> I understand that it should notify (log a message) when a Thread takes too
> long to end, but to be honest I hav
Also, I was wondering why we need this WatchDog thing altogether.
I understand that it should notify (log a message) when a Thread takes too
long to end, but to be honest I have never seen such a warning.
The cons are :
* it clutters up our code
* leaves running threads behing when the webapp is st
Hi Harry,
I had a lot of those while testing before r1551702, due to
o.a.w.tags.SearchResultIteratorInfo containing a String with an incorrect
classname. I'm currently re-trying to close the repo*, but I'll recheck on
that too to make sure everything is ok in order to proceed with voting
br,
jua
Juan Pablo,
first, thanks for all your efforts, I too appreciate !
I have been testing the trunk, the only thing I could find until now is
every 30 seconds a couple of these in the jspwiki.log:
2013-12-18 20:44:11,954 ERROR org.apache.wiki.WatchDog - Stack is empty!
java.util.EmptyStackException
Juan Pablo,
I'm sure your dedication is much appreciated by many. While I
don't have a vote any move to 2.10.0 would get a +1 from me.
In terms of the upcoming vote, I thought to add that as an added
incentive, once JSPWiki 2.10.0 stabilises, we hope to release a
WikiProvider implementation calle
Hi,
quick note, as it's nearly 2.00am here; done almost all steps required to
publish all artifacts on a staging repo, which the vote is going to be run
against. Currently blocked by a nexus timeout on closing the staging repo,
progress can be followed at https://issues.apache.org/jira/browse/INFR
Hi Juan Pablo,
I will play around with the current trunk :-)
Cheers,
Siegfried Goeschl
On 16 Dec 2013, at 22:03, Juan Pablo Santos Rodríguez
wrote:
> Hi,
>
> just finished doing a big bunch of pending refactors prior to releasing
> 2.10. We should be able to end up with all the artifacts o
Hi,
just finished doing a big bunch of pending refactors prior to releasing
2.10. We should be able to end up with all the artifacts on maven central
too (once the vote+release passes), and use a staged repository[#1] to vote
instead of uploading to somewhere at people.a.o
There are only a couple
Hi folks,
IMHO it is important to get the release out
* users are looking at project activity - there are many different wikis
out there ...
* are there bugfixes in 2.9.1 the users would appreciate? Better have a
small bugfix release now than the latest and greatest release 9 months
down th
Hi,
about 2.9 vs 2.10, I was having in mind releasing trunk in any case, the
version numbers were just to note binary compatibility. If we release
current trunk as it is, it isn't binary compatible with latest release,
because of 2.10.0-svn-8 and 2.10.0-svn-26. We could copy those classes back
to
Yes, I don't see any need to release the same 2.9.1 product just without
"incubator" in its version name, that's not a very Apache-esque way of
doing things (the "incubator" in version release is not an indicator of
software quality, as Apache stresses over and over.) If none of us
right now
No, not if we have nothing significant to add. Volunteers can't afford
to be engaging in busywork. And, yes, projects are allowed to go on
snooze between releases.
Glen
On 11/08/2013 03:08 PM, Jürgen Weber wrote:
no difference, but it should be soon. Last incubating is from May, so it
looks
no difference, but it should be soon. Last incubating is from May, so it
looks like not a lot happens. An project should be alive and kicking and
release often.
Juergen
2013/11/8 Harry Metske
> what would be reasons to release 2.9.x versus 2.10.x ?
> The latter has more issues fixed...
>
> reg
what would be reasons to release 2.9.x versus 2.10.x ?
The latter has more issues fixed...
regards,
Harry
On 8 November 2013 08:41, Jürgen Weber wrote:
> +1
> Am 07.11.2013 19:33 schrieb "Juan Pablo Santos Rodríguez" <
> juanpablo.san...@gmail.com>:
>
> > +1 too
> >
> > In order to remain 2.9
+1
Am 07.11.2013 19:33 schrieb "Juan Pablo Santos Rodríguez" <
juanpablo.san...@gmail.com>:
> +1 too
>
> In order to remain 2.9.x, we should get back o.a.w.WikiException (deleted
> in favour of o.a.w.api.WikiException) and maybe one or two similar changes,
> have to check svn to be sure.. Otherwis
+1 too
In order to remain 2.9.x, we should get back o.a.w.WikiException (deleted
in favour of o.a.w.api.WikiException) and maybe one or two similar changes,
have to check svn to be sure.. Otherwise we should release 2.10.0
I'm thinking we could also use this release to publish the release on ASF'
Hi Siegfried,
mvn clean install should be enough. I ran across a similar OOME, turned out
it was caused b/c I didn't had access to a tmp folder generated by a test.
But I think that shouldn't happen anymore on current trunk..
Would you mind running an mvn clean install -Dtest= JSPWikiMarkupParser
mvn package
works for me:
[INFO] Total time: 5:32.174s
[INFO] Finished at: Wed Nov 06 10:18:16 CET 2013
[INFO] Final Memory: 31M/223M
ll jspwiki-war/target/
total 12048
-rw-r--r-- 1 weberjn users 11182025 Nov 6 10:18 JSPWiki.war
But this builds 2.10,
whereas in http://www.apache.org/dist
Hi folks,
sort of confused - the M2 build is actually 2.10.0-SNAPSHOT and not 2.9.1
For the records
MAVEN_OPTS=-XX:MaxPermSize=256m -Xmx768m
trunk> mvn -v
Apache Maven 3.0.4 (r1232337; 2012-01-17 09:44:56+0100)
Maven home: /Applications/Java/apache-maven-3.0.4
Java version: 1.6.0_31, vendor: A
Hi folks,
had a look at trunk but I'm unable to run the tests
> mvn clean install
Anything I do wrong?
Thanks in advance
Siegfried Goeschl
Tests run: 188, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 58.537
sec <<< FAILURE! - in org.apache.wiki.parser.JSPWikiMarkupParserTest
org.apache
+1
On 5 November 2013 16:50, Jürgen Weber wrote:
> Currently the dev mailing list is a bit lonely, there seems not a lot be
> going on.
> I suggest that JSPWiki 2.9.1 come out from incubator.
> Actually 2.9.1 looks good. Why not release it?
>
> http://en.wikipedia.org/wiki/Release_early,_releas
Currently the dev mailing list is a bit lonely, there seems not a lot be
going on.
I suggest that JSPWiki 2.9.1 come out from incubator.
Actually 2.9.1 looks good. Why not release it?
http://en.wikipedia.org/wiki/Release_early,_release_often
Cheers,
Juergen
26 matches
Mail list logo
