Tapestry 5.4-alpha-3

2013-04-06 Thread Howard Lewis Ship
Hot off the presses!  The latest preview release of Tapestry, 5.4-alpha-3,
is now available.

Point your build tool of choice at the Maven repository:

https://repository.apache.org/content/repositories/orgapachetapestry-072/

Binary and source archives:

http://people.apache.org/~hlship/tapestry-releases/

What's new?

So much, I've kind of lost track; the main changes are:

Most assets are now accessed using a URL that incorporates a Adler32
checksum of the asset content.  Prior versions of Tapestry incorporated the
application version number into the URL.

What does this mean?  When you redeploy your web application, most assets
will have not changed: same content, same path, same checksum, therefore,
same URL. This means that client browsers will not have to re-download all
those assets again just because the application version number has changed.

Assets that have changed will have a different content hash, and therefore,
a different asset URL. Browsers will be sure to pull down those new
versions.

Modules are slightly different; because all JavaScript modules are expected
to start in a common root URL, there is no reasonable way to generate a
unique content hash for each; module URLs still use the application version
number. However, modules and all assets now also send an ETag header; this
means that module requests will still be sent, but will often get a 304
(resource not modified) response.

Obviously, this is a big change, and we're welcoming feedback.

Next up; we have first class support for jQuery.A little bit of symbol
tweaking, and Prototype and Scriptaculous are simply gone for good.

There's also been improvements to operation tracking, with more operations
performed during a request being tracked. This is useful for the part of
the exception report page that discusses what Tapestry did during a
request, leading up to the actual exception.

There's been big improvements, c/o Kalle, in terms of how exceptions are
reported, with finer control over what gets the full exception page, and
what doesn't.

For the rare places where public interfaces changed in incompatible ways,
there's now an @IncompatibleChange annotation for methods that have changed.


A few informational pages such as PageCatalog, ServiceStatus, and Hibernate
Statistics have been merged into a new single (extensible) page,
T5Dashboard.

... and lots more little changes, fixes, and improvements.

There's still a lot more to come, however.  Two principle improvements I'm
targeting for 5.4:

Proper server-side push/websocket support.

Built-in performance monitoring and reporting.

-- 
Howard M. Lewis Ship

Creator of Apache Tapestry

The source for Tapestry training, mentoring and support. Contact me to
learn how I can get you up and productive in Tapestry fast!

(971) 678-5210
http://howardlewisship.com


Re: [T5] Avoid logs in error for wrong urls and missing components ?

2013-04-06 Thread Nicolas Bouillon
Thanks for your thoughts, and that leads me to the following suggestion to
resolve my problem:

I've already contributed a custom RequestExceptionHandler using
binder.bind(RequestExceptionHandler.class,
CustomRequestExceptionHandler.class)
  .withId("CustomRequestExceptionHandler");

That is this service which is responsible of my log error message
(org.apache.tapestry5.internal.services.DefaultRequestExceptionHandler#handleRequestException).

In my Custom RequestExceptionHandler, I could check the user agent to match
against bots, and then instead of rendering the exception page, give them a
404 response code so they could stop crawling the page (and me skipping
logger.error at the top of the handleRequestException method).

Best regards.



2013/4/6 Muhammad Gelbana 

> When you create a tapestry project using maven's archtype, it creates the
> below request filter (slightly modified) to log how much time each request
> consumed.
>
> // Service building
> public RequestFilter buildTimingFilter(final Logger log) {
> return new RequestFilter() {
> @Override
> public boolean service(Request request, Response response,
> RequestHandler handler) throws IOException {
> long startTime = System.currentTimeMillis();
> try {
> // The responsibility of a filter is to invoke the
> corresponding method
> // in the handler. When you chain multiple filters
> together, each filter
> // received a handler that is a bridge to the next filter.
> return handler.service(request, response);
> } finally {
> long elapsed = System.currentTimeMillis() - startTime;
> if (TimeUnit.MILLISECONDS.toSeconds(elapsed) >= 10) {
> log.warn(String.format("Request time: %d ms",
> elapsed));
>  }
> }
> }
> };
> }
>
> // Service contribution
> public void contributeRequestHandler(OrderedConfiguration
> configuration, @Local RequestFilter filter) {
> // Each contribution to an ordered configuration has a name, When
> necessary, you may
> // set constraints to precisely control the invocation order of the
> contributed filter
> // within the pipeline.
> configuration.add("Timing", filter);
> }
>
> From there, if you find a pattern for requests coming from bots, you can
> drop these requests if that suits you. This way these bots will also learn
> that the links they are requesting doesn't exists anymore and will
> eventually stop bothering you, if they are smart enough !
>
> Regards
>
>
> On Fri, Apr 5, 2013 at 10:08 PM, Nicolas Bouillon  >wrote:
>
> > Dear all,
> >
> > I'm working on a e-commerce website in Tapestry 5 since a couple of years
> > and we are making our website evolving constantly, adding some features
> and
> > changing stuff here and there.
> >
> > I'm closely monitoring application logs but i'm very annoyed by robots
> who
> > reminds some URLs that are not valid anymore.
> >
> > For example, they remind (or follow old links) to webpages that used to
> be
> > coded in PHP and where the URL contained special chars, not allowed in
> > Tapestry URLs. Or those spiders try to access an URL of a grid pager
> event,
> > but the Grid component is not there anymore (or has a different name).
> Each
> > of those hit generate a log.error message, and that hide the important
> > errors messages inside many noise. (I know, "Cool URI don't change", but
> > for page events, it could be quite had to keep old URLs...)
> >
> > The error log is something like that :
> > org.apache.tapestry5.ioc.util.UnknownValueException: Component
> > product/domain/PriceList does not contain embedded component 'v3grid'.
> >
> > It's seems to be too wide to ignore totally "UnknownValueException" log
> > appender, because it might hide real mistakes in the web application.
> >
> > Is there a way to avoid this kind of behavior ? How do you treat error
> logs
> > from your applications ?
> >
> > Thanks.
> >
> > Nicolas.
> >
>


Re: [T5] Avoid logs in error for wrong urls and missing components ?

2013-04-06 Thread Muhammad Gelbana
When you create a tapestry project using maven's archtype, it creates the
below request filter (slightly modified) to log how much time each request
consumed.

// Service building
public RequestFilter buildTimingFilter(final Logger log) {
return new RequestFilter() {
@Override
public boolean service(Request request, Response response,
RequestHandler handler) throws IOException {
long startTime = System.currentTimeMillis();
try {
// The responsibility of a filter is to invoke the
corresponding method
// in the handler. When you chain multiple filters
together, each filter
// received a handler that is a bridge to the next filter.
return handler.service(request, response);
} finally {
long elapsed = System.currentTimeMillis() - startTime;
if (TimeUnit.MILLISECONDS.toSeconds(elapsed) >= 10) {
log.warn(String.format("Request time: %d ms", elapsed));
 }
}
}
};
}

// Service contribution
public void contributeRequestHandler(OrderedConfiguration
configuration, @Local RequestFilter filter) {
// Each contribution to an ordered configuration has a name, When
necessary, you may
// set constraints to precisely control the invocation order of the
contributed filter
// within the pipeline.
configuration.add("Timing", filter);
}

>From there, if you find a pattern for requests coming from bots, you can
drop these requests if that suits you. This way these bots will also learn
that the links they are requesting doesn't exists anymore and will
eventually stop bothering you, if they are smart enough !

Regards


On Fri, Apr 5, 2013 at 10:08 PM, Nicolas Bouillon wrote:

> Dear all,
>
> I'm working on a e-commerce website in Tapestry 5 since a couple of years
> and we are making our website evolving constantly, adding some features and
> changing stuff here and there.
>
> I'm closely monitoring application logs but i'm very annoyed by robots who
> reminds some URLs that are not valid anymore.
>
> For example, they remind (or follow old links) to webpages that used to be
> coded in PHP and where the URL contained special chars, not allowed in
> Tapestry URLs. Or those spiders try to access an URL of a grid pager event,
> but the Grid component is not there anymore (or has a different name). Each
> of those hit generate a log.error message, and that hide the important
> errors messages inside many noise. (I know, "Cool URI don't change", but
> for page events, it could be quite had to keep old URLs...)
>
> The error log is something like that :
> org.apache.tapestry5.ioc.util.UnknownValueException: Component
> product/domain/PriceList does not contain embedded component 'v3grid'.
>
> It's seems to be too wide to ignore totally "UnknownValueException" log
> appender, because it might hide real mistakes in the web application.
>
> Is there a way to avoid this kind of behavior ? How do you treat error logs
> from your applications ?
>
> Thanks.
>
> Nicolas.
>