; -Original Message-
> From: Howard Lewis Ship [mailto:hls...@gmail.com]
> Sent: 28 June 2012 19:28
> To: Tapestry users
> Subject: Re: Tapestry 5.3.4-rc-7
>
> I've been having problems with even with YUICompressor 2.4.7 in a production
> app.
>
> On Thu, Jun 28
riginal Message-
From: Howard Lewis Ship [mailto:hls...@gmail.com]
Sent: 28 June 2012 19:28
To: Tapestry users
Subject: Re: Tapestry 5.3.4-rc-7
I've been having problems with even with YUICompressor 2.4.7 in a production
app.
On Thu, Jun 28, 2012 at 10:05 AM, Jochen Frey wrote:
> +1
On Sat, Aug 11, 2012 at 7:20 AM, Stephan Windmüller wrote:
> On 11.08.2012 02:00, David Rees wrote:
>
>> I'm confused - so what's the proper fix to get the yuicompressor
>> dependency downloaded when one is using a maven proxy?
>
> Configure your maven proxy to access the mentioned repository.
Du
I am a bit behind, using plain of ways of copy and paste into lib/. Works
happily on GAEJ. :)
--
View this message in context:
http://tapestry.1045711.n5.nabble.com/Tapestry-5-3-4-tp5714512p5715312.html
Sent from the Tapestry - User mailing list archive at Nabble.com.
-
On 11.08.2012 02:00, David Rees wrote:
> I'm confused - so what's the proper fix to get the yuicompressor
> dependency downloaded when one is using a maven proxy?
Configure your maven proxy to access the mentioned repository.
- Stephan
signature.asc
Description: OpenPGP digital signature
On 11.08.2012 02:00, David Rees wrote:
> I'm confused - so what's the proper fix to get the yuicompressor
> dependency downloaded when one is using a maven proxy?
Configure your maven proxy to access the mentioned repository.
- Stephan
signature.asc
Description: OpenPGP digital signature
On Fri, Jul 20, 2012 at 10:11 AM, Kalle Korhonen
wrote:
> Yes, the pom looks correct:
> http://central.maven.org/maven2/org/apache/tapestry/tapestry-yuicompressor/5.3.4/tapestry-yuicompressor-5.3.4.pom
>
> You are instructing Maven to use a proxy exactly so that it wouldn't
> generate requests to
I have created dzone link
http://www.dzone.com/links/new_release_apache_tapestry_534.html vote it up!
Denis
On 25.7.2012, at 2:12, Howard Lewis Ship wrote:
> Just a reminder; I'd still like to see a show of support on the
> JavaLobby announcement page.
>
> On Wed, Jul 18, 2012 at 2:45 PM, Howa
Just a reminder; I'd still like to see a show of support on the
JavaLobby announcement page.
On Wed, Jul 18, 2012 at 2:45 PM, Howard Lewis Ship wrote:
> As always, these release announcements are a good time to show your
> love in a visible way.
>
> http://java.dzone.com/announcements/apache-tape
Yes, the pom looks correct:
http://central.maven.org/maven2/org/apache/tapestry/tapestry-yuicompressor/5.3.4/tapestry-yuicompressor-5.3.4.pom
You are instructing Maven to use a proxy exactly so that it wouldn't
generate requests to unknown locations on open internet, so proxy
configurations certai
It's good to know, I hope, that this hiccup won't affect every user.
I did some testing but, alas, tested using Gradle and not Maven, so
I'm not 100% certain it will work for Maven.
On Fri, Jul 20, 2012 at 12:16 AM, Stephan Windmüller
wrote:
> On 19.07.2012 23:29, Alex Kotchnev wrote:
>
>> did y
On 19.07.2012 23:29, Alex Kotchnev wrote:
> did you figure out what the issue was with the missing bizarre missing
> dependency problem ? I switched the version in my POM and I see the same
> problem.
Yes, I have.
This artifact
| org.apache.tapestry
| tapestry-yuicompressor
| 5.3.4
is specify
Stephan / George,
did you figure out what the issue was with the missing bizarre missing
dependency problem ? I switched the version in my POM and I see the same
problem.
Cheers,
Alex K
On Wed, Jul 18, 2012 at 6:37 PM, Angelo C. wrote:
> congrats! any breaking feature from 5.3.3 to 5.3.4?
congrats! any breaking feature from 5.3.3 to 5.3.4?
--
View this message in context:
http://tapestry.1045711.n5.nabble.com/Tapestry-5-3-4-tp5714512p5714584.html
Sent from the Tapestry - User mailing list archive at Nabble.com.
-
Stephan, I'm having the same issue with yuicompressor
--
View this message in context:
http://tapestry.1045711.n5.nabble.com/Tapestry-5-3-4-tp5714512p5714563.html
Sent from the Tapestry - User mailing list archive at Nabble.com.
---
On 17.07.2012 18:09, Howard Lewis Ship wrote:
> Following a successful vote, we're happy to announce the release of
> Tapestry 5.3.4.
Am I the only one having problems with the maven dependencies?
| [WARNING] The POM for
com.google.code.maven-play-plugin.com.yahoo.platform.yui:yuicompressor:jar:
On Tue, Jul 17, 2012 at 9:26 AM, Lenny Primak wrote:
> Congratulations!
>
> Is javassist dependency removed in this release?
No, that's 5.4 (currently very alpha).
>
>
>
> On Jul 17, 2012, at 11:09 AM, Howard Lewis Ship wrote:
>
>> Following a successful vote, we're happy to announce the releas
Yep, I caught that, just taking Confluence a while to update.
On Tue, Jul 17, 2012 at 9:30 AM, Steve Eynon
wrote:
> Just to say the 'Release Notes' link on Announcing Tapestry 5.3.4
> links to 5.3.3 and not 5.3.4.
>
> Steve.
>
>
> On 18 July 2012 00:09, Howard Lewis Ship wrote:
>> Following a su
The Release Notes say:
Breaking Features
Tapestry's use of the Javassist bytecode library has been completely
removed, along with many related services, such as ClassFactory, that
were deprecated in 5.3. Use PlasticProxyFactory instead.
On 18 July 2012 00:34, Kalle Korhonen wrote:
> On Tue, J
On Tue, Jul 17, 2012 at 9:26 AM, Lenny Primak wrote:
> Congratulations!
> Is javassist dependency removed in this release?
No, still a dependency of tapestry-ioc.
Kalle
> On Jul 17, 2012, at 11:09 AM, Howard Lewis Ship wrote:
>
>> Following a successful vote, we're happy to announce the relea
Just to say the 'Release Notes' link on Announcing Tapestry 5.3.4
links to 5.3.3 and not 5.3.4.
Steve.
On 18 July 2012 00:09, Howard Lewis Ship wrote:
> Following a successful vote, we're happy to announce the release of
> Tapestry 5.3.4.
>
> 5.3.4 includes further performance improvements for
Congratulations!
Is javassist dependency removed in this release?
On Jul 17, 2012, at 11:09 AM, Howard Lewis Ship wrote:
> Following a successful vote, we're happy to announce the release of
> Tapestry 5.3.4.
>
> 5.3.4 includes further performance improvements for heavily loaded
> servers, a
At this point, I'm thinking 5.3.5 will fix yuicompressor. I just want
to get 5.3.4 out the door
On Wed, Jul 4, 2012 at 6:51 AM, Jochen Berger wrote:
> Am 04.07.2012 10:55, schrieb Lenny Primak:
>
>> I don't think there is a 'clean' solution.
>
>
> Hopefully, requirejs/uglifyjs will be able to mak
Hi,
Am 05.07.2012 02:39, schrieb Bob Harner:
I'm trying to follow what was done with YUICompressor in Tapestry
5.3.4-rc-9, somebody tell me if I have it right: To get YUICompressor
to work more reliably, Tapestry 5.3.4-rc-9 includes a version of the
YUICompressor that the maven-play-plugin proje
Sounds reasonable. I don't know what play project did though.
On Jul 4, 2012, at 8:39 PM, Bob Harner wrote:
> I'm trying to follow what was done with YUICompressor in Tapestry
> 5.3.4-rc-9, somebody tell me if I have it right: To get YUICompressor
> to work more reliably, Tapestry 5.3.4-rc-9
I'm trying to follow what was done with YUICompressor in Tapestry
5.3.4-rc-9, somebody tell me if I have it right: To get YUICompressor
to work more reliably, Tapestry 5.3.4-rc-9 includes a version of the
YUICompressor that the maven-play-plugin project built (at
http://maven-play-plugin.googlecode
Am 04.07.2012 10:55, schrieb Lenny Primak:
I don't think there is a 'clean' solution.
Hopefully, requirejs/uglifyjs will be able to make all this obsolete by
the end of this year. :-)
-
To unsubscribe, e-mail: users-unsubsc
I have solved this problem by repackaging
yuicompressor, rhino and tap-yuicompressor into a single .jar file
using jarjar, which solves all problems.
I don't think there is a 'clean' solution.
---
Combine yucompressor-2.4.6 and rhino-1.6R7 into src file (via jar)
$ mkdir work; cd work
howard,
i encountered problems with yuicompressor too (in the rc5 release i
think). i deactivated the yuicompressor tap5 module to fix it. the
problem for me was this:
http://yuilibrary.com/projects/yuicompressor/ticket/2528056
the yuicompressor has its own version of the rhino classes, but in t
I've just released rc-9, that corrects the POM issue in tapestry-yuicompressor.
On Tue, Jul 3, 2012 at 8:13 AM, Howard Lewis Ship wrote:
> That's odd about the POM; you are correct, but I had made changes to
> ensure that the POM had the in place.
>
> I've also had trouble with even the lastest
That's odd about the POM; you are correct, but I had made changes to
ensure that the POM had the in place.
I've also had trouble with even the lastest tapestry-yuicompressor;
I'm concerned that it has a conflict with the Rhino built into JDK
1.7.
It's frustrating; the YUICompressor people should
Looks fine upon first glance.
Everything seems to work well apart from yuicompressor:
First, the Maven Play Plugin repository is not included in the pom [1].
Second, it causes issues when used together with t5conduit due to the
modified classes that it ships with the original package structure.
T
@Howard:
Ok, I see still one problem with 2.4.7. The 'use strict'; hint is causing
warnings/erros in the logs. The app is working fine but maybe you're right :-/
Maybe it's worth putting some into a google closure integration?
Am 28.06.2012 um 20:27 schrieb Howard Lewis Ship:
> I've been hav
I've been running in production for a while, with a combined "jarjar"-combined
yuicompressor, rhino and tapestry-yuicompressor with no problems for months now.
I was the only viable solution I could find with the duplication of libraries
and the "customized" rhino library
problem that yuicompresso
I've been having problems with even with YUICompressor 2.4.7 in a
production app.
On Thu, Jun 28, 2012 at 10:05 AM, Jochen Frey wrote:
> +1 for the YUI compressor. It really looks broken in production
> environments, and it's an easy fix.
>
> On Jun 28, 2012, at 7:51 AM, Christian Riedel wrote:
+1 for the YUI compressor. It really looks broken in production environments,
and it's an easy fix.
On Jun 28, 2012, at 7:51 AM, Christian Riedel wrote:
> Ok, one thing could also be quickly done: upgrading the yuicompressor lib to
> 2.4.7 like suggested in TAP5-1729.
> Minification/Resource c
Ok, one thing could also be quickly done: upgrading the yuicompressor lib to
2.4.7 like suggested in TAP5-1729.
Minification/Resource combination with tapestry-yuicompressor is really broken
without that and it's quite easy to fix.
https://issues.apache.org/jira/browse/TAP5-1729
Am 28.06.2012
Hi,
can someone fix TAP5-1926 and have a look at the problem I reported on
BeanEditor and BeanValidation [1]?
And yes, Everything's stable with rc-7!
[1]
http://tapestry.1045711.n5.nabble.com/BeanEditor-should-always-provide-a-new-BeanValidationContext-JSR-303-tp5713975.html
- Original
Everything's stable with rc-7!
I'd +1 a vote on this release.
Am 25.06.2012 um 19:44 schrieb Howard Lewis Ship:
> I've just uploaded Tapestry 5.3.4-rc-7. Key improvements:
>
> * More (minor) speed improvements
> * TAP5-1873: JavaScript execution exception is not logged
> * Fixes the Hibernate
I straightened out a number of startup deadlock issues for 5.2. They can
be very challenging to root out.
On Thu, Jun 14, 2012 at 9:47 PM, Jens Breitenstein TOC <
jens.breitenst...@t-o-c.biz> wrote:
> Hi Howard,
>
> In the past we had severe problems with T5 when a tomcat was started under
> hea
Hi Howard,
In the past we had severe problems with T5 when a tomcat was started under
heavy load. It deadlocked reproduceble in the classloader / bytecode
instrumentation area. Thus we workaround this issue but clicking the index page
manually ones before adding the tomcat to the loadbalancer (
Right, I should known that it will not lock when there are some readers.
Denis
Jun 14, 2012 v 7:28 PM, Howard Lewis Ship:
> I'm already somewhat unhappy at the complexity of the code; I'd prefer not
> to make it any more complicated. I think race conditions on the write lock
> are going to be p
I'm already somewhat unhappy at the complexity of the code; I'd prefer not
to make it any more complicated. I think race conditions on the write lock
are going to be pretty rare and probably only occur on a somewhat saturated
server at initial startup. I think twisting the code ever further.
In
Concurrency topic:
Would it be possible to change the lazy init to check if write lock is already
locked? It will eliminate the posibility of locking the write lock by more then
one thread.
try {
readLock.lock();
if(is need to init)
{
boolean hasWriteLock = false;
try {
Thanks!
2012/6/12 Howard Lewis Ship
> The change of Hibernate dependency was a mistake made while
> converting over the Gradle build script changes from master to the 5.3
> branch. This occured in 5.3.4-rc-3 (I believe). It has been
> corrected. Sorry about the trouble!
>
> On Tue, Jun 12, 201
The change of Hibernate dependency was a mistake made while
converting over the Gradle build script changes from master to the 5.3
branch. This occured in 5.3.4-rc-3 (I believe). It has been
corrected. Sorry about the trouble!
On Tue, Jun 12, 2012 at 8:52 AM, Felix Scheffer wrote:
> Hi,
>
> in
Could be https://issues.apache.org/jira/browse/TAP5-1873 fixed? There is a
missing parameter in a call and improved exception logging.
Thanks,
Denis
Jun 11, 2012 v 8:36 PM, Howard Lewis Ship:
> On Wed, Jun 6, 2012 at 5:37 PM, Cezary Biernacki wrote:
>> On Thu, Jun 7, 2012 at 1:27 AM, H
On Wed, Jun 6, 2012 at 5:37 PM, Cezary Biernacki wrote:
> On Thu, Jun 7, 2012 at 1:27 AM, Howard Lewis Ship wrote:
>
>> You can even omit synchronized and volatile IFF:
>> - only a single shared field is updated
>> - it is ok for a race condition to exist that would create the value
>> on multipl
Thanks for the feedback!
On Mon, Jun 11, 2012 at 10:58 AM, Christian Riedel
wrote:
> Testing Tapestry 5.3.4-rc-5 and now Tapestry 5.3.4-rc-6 without any problems!
> Site looks good, page response times dropped a bit but we don't have
> thousands of concurrent users… yet! ;-)
>
>
> Am 06.06.2012
Testing Tapestry 5.3.4-rc-5 and now Tapestry 5.3.4-rc-6 without any problems!
Site looks good, page response times dropped a bit but we don't have thousands
of concurrent users… yet! ;-)
Am 06.06.2012 um 19:32 schrieb Howard Lewis Ship:
> For those that are interested, I just committed some fu
On Thu, Jun 7, 2012 at 3:26 AM, Martin Strand <
do.not.eat.yellow.s...@gmail.com> wrote:
> On Thu, 07 Jun 2012 02:24:35 +0200, Cezary Biernacki
> wrote:
>
> "* The semantics of volatile variables have been strengthened to have
>> acquire and release semantics. In the original specification, acces
On Thu, 07 Jun 2012 02:24:35 +0200, Cezary Biernacki
wrote:
"* The semantics of volatile variables have been strengthened to have
acquire and release semantics. In the original specification, accesses to
volatile and non-volatile variables could be
freely ordered.
Aha, so does this mean that
On Thu, Jun 7, 2012 at 1:27 AM, Howard Lewis Ship wrote:
> You can even omit synchronized and volatile IFF:
> - only a single shared field is updated
> - it is ok for a race condition to exist that would create the value
> on multiple threads
> - (I learned this by getting schooled on the subject
>
> If I'm not mistaken, JSR-133 only affects final fields so we still have
> the same problem for non-final fields.
> i.e any non-final fields in Messages might still be uninitialized even if
> the *reference* is visible to other threads (messages != null)
>
>
Actually, JSR-133 guarantees that fi
On Wed, Jun 6, 2012 at 1:51 PM, Cezary Biernacki wrote:
> On 06 June 2012 21:20:02 +0200 Howard Lewis Ship wrote:
>>
>>
>> http://tapestryjava.blogspot.com/2012/06/synchronized-considered-harmful.html
>
> I am curious is there a reason to not use 'double-checked locking' pattern?
> I know that it
On Wed, 06 Jun 2012 23:29:52 +0200, Kalle Korhonen
wrote:
On Wed, Jun 6, 2012 at 1:51 PM, Cezary Biernacki wrote:
On 06 June 2012 21:20:02 +0200 Howard Lewis Ship wrote:
http://tapestryjava.blogspot.com/2012/06/synchronized-considered-harmful.html
I am curious is there a reason to not use
On Wed, Jun 6, 2012 at 1:51 PM, Cezary Biernacki wrote:
> On 06 June 2012 21:20:02 +0200 Howard Lewis Ship wrote:
>> http://tapestryjava.blogspot.com/2012/06/synchronized-considered-harmful.html
> I am curious is there a reason to not use 'double-checked locking' pattern?
> I know that it was bro
On 06 June 2012 21:20:02 +0200 Howard Lewis Ship wrote:
http://tapestryjava.blogspot.com/2012/06/synchronized-considered-harmful.html
I am curious is there a reason to not use 'double-checked locking' pattern? I
know that it was broken in Java 1.4 and earlier, but Java Memory Model was
change
http://tapestryjava.blogspot.com/2012/06/synchronized-considered-harmful.html
Like everything else that's good in Tapestry: no magic bullet, just
discipline and determination.
On Wed, Jun 6, 2012 at 10:52 AM, Thiago H de Paula Figueiredo
wrote:
> On Wed, 06 Jun 2012 14:32:02 -0300, Howard Lewis
On Wed, 06 Jun 2012 14:32:02 -0300, Howard Lewis Ship
wrote:
For those that are interested, I just committed some further speed
boosts to Tapestry, and generated a new preview release.
The client who I'm doing this for saw the throughput on their load
test go from 450 req/sec to 2000 req/sec
60 matches
Mail list logo
