Comments on Tapestry Central: Servlet 2.5: Where's the regexp?

"January 2006: Where's Tapestry 4.0 Final?" should...

2006-01-06T08:43:00.000-08:00

"January 2006: Where's Tapestry 4.0 Final?" should be the question :D

now seriously: wouldnt it be better to bind tapestry to / like anonymous said before ? - why not let tapestry itself decide... this means we also could have different ways for handling images, special deeplinks etc as they could all be defined within the java part !

And another Question: When will Tapestry support SSL native ? - i mean, we have the way of using direct-link to send the visitor to a page over SSL but this still means that this page is not yet protected for non SSL calls - otherweise we could define in the .page file sth. like SSL=TRue that is must be access over an encrypted connection, else it would send a redirect to the encrypted page... would be really blazing and boosting security as well...

just a small thought,

regards

K

My opinion is the bind a servlet to "/" and be don...

2006-01-05T08:18:00.000-08:00

My opinion is the bind a servlet to "/" and be done with it. Then you are free to do whatever. The whole servlet thing is a mess.

Howard, wouldn't a Servlet Listener implementing j...

2006-01-05T03:03:00.000-08:00

Howard, wouldn't a Servlet Listener implementing javax.servlet.http.HttpSessionActivationListener be enought? This would give you sessionWillPassivate() and sessionDidActivate() hooks.
Yes, it requires one more line in web.xml, but it is worth it IMHO.

readObject() is quite insufficient for my purposes...

2006-01-04T20:56:00.000-08:00

readObject() is quite insufficient for my purposes; this is about HiveMind and hooking serialized proxies back into the Registry ... and, of course, there may be more than one Registry, so you can't base this on a static field, either. Worse, you can't even base it on a customized ObjectInputStream, since the servlet container, not your code, creates the stream. So I rely on ThreadLocal wrapper around a WeakReference, but I'm not 100% sure it will work, because there's no guarantee the right Registry instance will have been stored into the ThreadLocal before the service proxies are deserialized. This is what I get for writing a framework and not a server, where I would have control over that stuff :-)

You can hook deserialization by implementing a rea...

2006-01-04T17:08:00.000-08:00

You can hook deserialization by implementing a readObject() method.

What the hell is "heh heh."?I actually provided th...

2006-01-04T14:36:00.000-08:00

What the hell is "heh heh."?

I actually provided this feedback to Ed Burns who did pass it on to the group.

It should not be necessary to be on the group to get common-sense changes made to the spec. But I'll keep my eyes open for the 2.6 spec ... in my spare time :-).

It seems silly to expose the shortcomings of the n...

2006-01-04T14:25:00.000-08:00

It seems silly to expose the shortcomings of the new servlet specification after it has been through the whole review process.

There have been public review copies available since 26 Feb, 2004

Get involved! ;-)

heh heh.

The annotation is on a field. There may or may not...

2006-01-04T12:28:00.000-08:00

The annotation is on a field. There may or may not be a setter method for that field. This implies that the field's value is being set via a constructor ... but not one you write. This implies that the bytecode of your class is being modified, to provide the setter method, or a constructor. Unless they went the cheesey route, and required that the field be public.

I don't see why @Resource would require bytecode p...

2006-01-04T12:06:00.000-08:00

I don't see why @Resource would require bytecode processing.