Re: Jasper and parsed tree
At 11:40 AM +0800 7/13/01, John Yu wrote: Well, assuming that the JavaCC grammar is capable of dealing with all the intricacies of JSP syntax (and the license issues dealt with), it's certainly possible. But I'd be really hesitant to say let's go replace the parser without discussing and agreeing on an overall architecture first. I've just uploaded a demonstration of the feasibility of binding web applications to html, template files, properties files, and databases at pre-compile time instead of run-time as most template languages do now. The advantages are considerable; negligible run-time overhead (28kb), compile-time type checking, and so forth. The template language syntax is primitive currently. I'm thinking about modifying the Velocity parser to emit java statements for compilation at compile time instead of interpreting the AST at runtime. Comments on the desirability of this approach are welcome, particularly offers to help! ;) The feasibility demo is at http://virtualschool.edu/jwaa. Tomcat/Velocity developers; I'd be most interested in your responses to my complaints about the emphasis on properties/XML files in Tomcat and Velocity... near the end of the template language document (there's a link to this document at the very top). -- --- For industrial age goods there were checks and credit cards. For everything else there is mybank.dom at http://virtualschool.edu/mybank Brad Cox, PhD; [EMAIL PROTECTED] 703 361 4751
RE: [PRE-PROPOSAL] jakarta-tomcat-doc sub-project : WAS: [TomcatDocu mentation Redactors To Hire]
At 10:09 AM -0400 7/2/01, Rob S. wrote: 1) Developers don't write them in lieu of coding. 2) Users don't read them 3...) ? http://www.c2.com/cgi-bin/wiki has a novel way of getting at the problem. Not a panacea obviously, but what is? The one at that address is perl-based; I can provide a tomcat/mod_jk/servlet based one if there's interest. -- --- For industrial age goods there were checks and credit cards. For everything else there is mybank.dom at http://virtualschool.edu/mybank Brad Cox, PhD; [EMAIL PROTECTED] 703 361 4751
Re: tomcat gui
At 8:15 AM -0700 7/2/01, [EMAIL PROTECTED] wrote: The right thing is to use a 2-layer architecture, with the backend beeing a set of servlets/jsps in /admin, with minimal ( or no ) GUI. The frontend can be a swing GUI, a webapp ( that can run on a different container and manage a set of tomcat instances ), or a module part of one of the existing admin GUIs. Wouldn't this mean that the GUI would be ussless until the things tomcat depends on (apache to some extent (port 8080 conflicts), connectors, classloaders, jar files) are all exactly right? In my experience, these are precisely the things that most often go wrong and generate the most obscure errors. By this reasoning, the GUI should concentrate on these things first and avoid relying on tomcat-based functionality until the fundamentals are known to be right. PS: Building Java GUIs is straightforward given Visual Age or simlar. The hard part is understanding what tomcat needs to get on its feet and building this understanding into a GUI, either by implementing it independently or by catching and reporting exceptions thrown by existing tomcat code. -- --- For industrial age goods there were checks and credit cards. For everything else there is mybank.dom at http://virtualschool.edu/mybank Brad Cox, PhD; [EMAIL PROTECTED] 703 361 4751
Re: Using log4j in custom tag libraries
This looks like the same material I've seen before. Default init oesn't seem to work. Keep getting an error message unless I explicitly initialize it somewhere, which is a real problem in my multi-entry system (test cases, servlets, client aps). Just this weekend I went back to a home-brew static Log class for this very reason. On Saturday, June 9, 2001, at 11:54 AM, Ceki Gülcü wrote: Hi Goug, The user manual in the just released log4j 1.1.2 has a section on default initialization, in particular initialization under Tomcat. Be sure to read: http://jakarta.apache.org/log4j/docs/manual.html#defaultInit Hope this helps, Ceki Hi, I am trying to replace the System.out.println() logging in my custom tag library with log4j (using jakarta 3.2.1). I have added Category.getInstance() calls in each tag but I am not sure where I should add the log4j initialisation code. Do I just have a static initialisation block in one of the tags I think will get loaded quickly ? I tried this and I can see messages from the static block in the log file but not messages from other classes - I am not sure why not. But this doesn't seem a very clean way of initialising log4j but I am not sure what else I can do. Any clues to point me in the right direction would be much appreciated. What I am really aiming for is a way of logging all activity from several custom tag libraries in a single log file. Regards -- Ceki Gülcü
RE: ServerSocket not being closed properly.
At 7:19 PM -0700 04/23/2001, [EMAIL PROTECTED] wrote:
On Mon, 23 Apr 2001, Arun Katkere wrote:
In general you need to do something to unblock the accept thread, and 3.2
doesn't have this in.
Yes, I remember now. You're absolutely right. You need
serverSocket.setSoTimeout() to break the accept periodically. Here's
how I did it in my app.
Notice the comment: apparently I got this from an early version of Tomcat.
public void run()
{
if (serverSocket != null) // original is server
{
isListening = true;
while(isListening)
{
try
{
Socket clientSocket = serverSocket.accept();
SocketServer clone = (SocketServer)clone();
clone.serverSocket = null;
clone.clientSocket = clientSocket;
clone.thread = new Thread(clone, name+Clone);
clone.thread.start();
}
catch (InterruptedIOException e)
{
/**
* Ignore periodic SO_TIMEOUT interrupts
* Without this the accept call never returns when the serversocket
* is closed, and all subsequent runs fail with port 8082 busy.
* I found this in the Tomcat http server code.
*/
}
catch (Throwable e)
{ e.printStackTrace(); isListening = false; }
}
}
else run(clientSocket);
}
void startServer(int port) throws UserFault
{
if (thread == null)
{
try
{
serverSocket = new ServerSocket(port);
serverSocket.setSoTimeout(WAKEUP_INTERVAL);
}
catch (IOException e)
{
throw UserFault.errEnablerPortBusy(port);
}
thread = new Thread(this, name+Master);
isListening = true;
thread.start();
}
}
--
---
Brad Cox, Ph.D.; [EMAIL PROTECTED]
Phone: 703 361 4751 Cell: 703 919-9623
http://virtualschool.edu
RE: ServerSocket not being closed properly.
At 7:23 AM -0700 04/24/2001, [EMAIL PROTECTED] wrote: Anyway - a cleaner solution ( IMHO ) is to just set stoped and do a bogus connection. That's what I did in 3.3 - and seems to work fine. That does sound better. I really hope this gets nailed ASAP. I suspect the present configuration complexity, exacerbated by the lack of configuration validation, could be fixed with a simple gui. This might go far towards turning around the bad press Tomcat has been getting of late, but this problem is fatal to gui wrappers. -- --- Brad Cox, Ph.D.; [EMAIL PROTECTED] Phone: 703 361 4751 Cell: 703 919-9623 http://virtualschool.edu
RE: ServerSocket not being closed properly.
At 9:50 AM -0700 04/24/2001, [EMAIL PROTECTED] wrote: here are few ideas that can be used for configuration validation, and the best ( IMHO ) is to run the sanity test after every change in the config file. ( maybe watchdog too ). In 3.3 we package all the tests as self-contained wars, and the admin has a web-based runner - but it needs more polishing to make it really easy to use. That's roughly how I meant for a gui to work. A few text boxes for options every novice must touch and run the tests automatically on save. Novice-only stuff to make sure it runs out-of-box; eexperts will dicker the config files directly. Regarding the configuration complexity - the main problem is the fact that in few cases the module order is important ( this is true for Apache 1.3 also, and Apache2.0 improves a bit with the new position parameter). This may be a big problem, but its not the main one for mortals. XML validation only ensures that the configs are syntactically correct. Without semantic validation (like your test suite could provide), tomcat reports common errors, mispelling a context name, classpath problems, etc, by throwing NullPointerExceptions and the like from very low level code. Usually the stack trace provides no way of connecting the error with the config error that is causing it. I seem to get bitten by a half dozen or so variations on this theme every time I install a new release, which involves a week of frustrated guessing each time. The only solution I've found is to load the Tomcat sources into Visual Age and treating each release as a low-level debugging exercise. Most of the effort has been put into the lower-level architecure and modularity - and not in individual modules. The idea is that in time we can rewrite individual modules ( for example the mapper is a big target for optimizations, etc ), and improve various spots. That's about repairing/redesigning the bowels of the mine. I'm saying tomcat needs some work on the sales office. Its not either-or; both need work. Fact is - we do improve - and that's what matters ( for me ). I don't think anyone claims the first versions of apache were easy to install ( or even the latest ). Indeed! And thanks for listening! -- --- Brad Cox, Ph.D.; [EMAIL PROTECTED] Phone: 703 361 4751 Cell: 703 919-9623 http://virtualschool.edu
RE: ServerSocket not being closed properly.
At 12:49 PM -0700 04/24/2001, [EMAIL PROTECTED] wrote: Yes, but I can hardly find time for one. I would love to work on both - but so far I coulnd't find people to help on the /admin, and I'll not start it alone. ( well, Larry and few others helped a lot - but he seems to have even less free time than I have ). Fact is - we do improve - and that's what matters ( for me ). I don't think anyone claims the first versions of apache were easy to install ( or even the latest ). Indeed! And thanks for listening! Well, thanks for the feedback - and even more thanks if that leads to some code contributions. That's what I had in mind for the gui. Gotta stay focused on my app for now but this should be done real soon now. ;) -- --- Brad Cox, Ph.D.; [EMAIL PROTECTED] Phone: 703 361 4751 Cell: 703 919-9623 http://virtualschool.edu
ServerSocket not being closed properly.
At 7:06 PM -0500 04/23/2001, Marc Saegesser wrote:
I was just about to call the vote for the final release of Tomcat 3.2.2
...
While you're at it, could you ensure that tomcat closes its server
socket instead of relying on the system to do it when the VM exits?
This is a long-standing problem that interferes with running tomcat
inside IBM's VisualAge, or (equivalently) building java GUIs for
starting and stopping the server.
Here's what I've been using in a GUI for starting and stopping tomcat.
private void doStart(String[] args)
{
org.apache.tomcat.startup.Tomcat.main(args);
}
private void doStop()
{
String[] stopArgs = new String[] { -stop };
org.apache.tomcat.startup.Tomcat.main(stopArgs);
}
The buttons work the first time they're used. The start buttons fails
the second times (either by the same GUI or by any other means during
the same VisualAge session) because the server socket is still being
held open by the lack of an explicit close. The only way I've found
to clear the problem is to exit VisualAge altogether; a SLOOO
process.
I've seen the same problem in my own applications. The fix was to be
SURE that the ServerSocket is closed EXPLICITLY rather than leaving
it to the operating system to do when the process exits.
This session console log may help locate the problem.
2001-04-24 08:51:00 - ContextManager: Adding context Ctx( /examples )
2001-04-24 08:51:01 - ContextManager: Adding context Ctx( /admin )
2001-04-24 08:51:01 - Ctx( /svlt ): Set debug to 9
2001-04-24 08:51:01 - ContextManager: Adding context Ctx( /svlt )
Starting tomcat. Check logs/tomcat.log for error messages
2001-04-24 08:51:01 - ContextManager: Adding context Ctx( )
2001-04-24 08:51:01 - ContextManager: Adding context Ctx( /test )
2001-04-24 08:51:01 - ContextManager: Adding context Ctx( /digiprop )
2001-04-24 08:51:02 - Ctx( /svlt ): XmlReader - init /svlt /digiprop
2001-04-24 08:51:02 - Ctx( /svlt ): Reading /digiprop/WEB-INF/web.xml
2001-04-24 08:51:02 - Ctx( /svlt ): Loading -2147483646 jsp
2001-04-24 08:51:02 - Ctx( /svlt ): Loading 1 flush
2001-04-24 08:51:03 - Ctx( /svlt ): Loading 1 page
2001-04-24 08:51:03 - Ctx( /svlt ): Loading 1 login
FATAL:java.net.SocketException: Address already in use
java.net.SocketException: Address already in use
java.lang.Throwable(java.lang.String)
java.lang.Exception(java.lang.String)
java.io.IOException(java.lang.String)
java.net.SocketException(java.lang.String)
void java.net.PlainSocketImpl.socketBind(java.net.InetAddress, int)
void java.net.PlainSocketImpl.bind(java.net.InetAddress, int)
java.net.ServerSocket(int, int, java.net.InetAddress)
java.net.ServerSocket(int, int)
java.net.ServerSocket
org.apache.tomcat.net.DefaultServerSocketFactory.createSocket(int,
int)
void org.apache.tomcat.service.PoolTcpEndpoint.startEndpoint()
void org.apache.tomcat.service.PoolTcpConnector.start()
void org.apache.tomcat.core.ContextManager.start()
void org.apache.tomcat.startup.Tomcat.execute(java.lang.String [])
void org.apache.tomcat.startup.Tomcat.main(java.lang.String [])
void digiprop.site.TomcatView.doStart()
void digiprop.site.TomcatView.connEtoC2(java.awt.event.ActionEvent)
void
digiprop.site.TomcatView$IvjEventHandler.actionPerformed(java.awt.event.ActionEvent)
void java.awt.Button.processActionEvent(java.awt.event.ActionEvent)
void java.awt.Button.processEvent(java.awt.AWTEvent)
void java.awt.Component.dispatchEventImpl(java.awt.AWTEvent)
void java.awt.Component.dispatchEvent(java.awt.AWTEvent)
void java.awt.EventDispatchThread.run()
--
---
Brad Cox, Ph.D.; [EMAIL PROTECTED]
Phone: 703 361 4751 Cell: 703 919-9623
http://virtualschool.edu
RE: ServerSocket not being closed properly.
At 6:37 PM -0700 04/23/2001, Arun Katkere wrote:
In my experience (having started/stopped Tomcat engine programatically via
ContextManager API in a loop 100s of times), server socket is always closed
correctly. And looking at 3.2.2 beta 3 source code, both PoolTcpEndpoint and
SimpleTcpEndpoint close the server socket during shutdownEndpoint().
Could you provide sample code? Better yet, an explanation for the
symptoms I provided? I'm inferring the cause but the symptoms are
100% rock solid.
BTW, doesn't your doStop() below kill the VM because there is a
System.exit() in Ajp12ConnectionHandler shutdown?
It does kill the GUI, but System.exit() doesn't kill VisualAge.
Hadnn't dug into this gui problem because the gui is useless after
doStop anyway.
ps: Each invocation leaves some threads running, which is bug 1418
(http://nagoya.apache.org/bugzilla/show_bug.cgi?id=1418), resolved for 3.3
(not 3.2.2). There is also some memory leak which I haven't had a chance to
track down, yet.
-Original Message-
From: Brad Cox PhD [mailto:[EMAIL PROTECTED]]
Sent: Monday, April 23, 2001 6:04 PM
To: [EMAIL PROTECTED]
Subject: ServerSocket not being closed properly.
At 7:06 PM -0500 04/23/2001, Marc Saegesser wrote:
I was just about to call the vote for the final release of
Tomcat 3.2.2
...
While you're at it, could you ensure that tomcat closes its server
socket instead of relying on the system to do it when the VM exits?
This is a long-standing problem that interferes with running tomcat
inside IBM's VisualAge, or (equivalently) building java GUIs for
starting and stopping the server.
Here's what I've been using in a GUI for starting and stopping tomcat.
private void doStart(String[] args)
{
org.apache.tomcat.startup.Tomcat.main(args);
}
private void doStop()
{
String[] stopArgs = new String[] { -stop };
org.apache.tomcat.startup.Tomcat.main(stopArgs);
}
The buttons work the first time they're used. The start buttons fails
the second times (either by the same GUI or by any other means during
the same VisualAge session) because the server socket is still being
held open by the lack of an explicit close. The only way I've found
to clear the problem is to exit VisualAge altogether; a SLOOO
process.
I've seen the same problem in my own applications. The fix was to be
SURE that the ServerSocket is closed EXPLICITLY rather than leaving
it to the operating system to do when the process exits.
This session console log may help locate the problem.
2001-04-24 08:51:00 - ContextManager: Adding context Ctx( /examples )
2001-04-24 08:51:01 - ContextManager: Adding context Ctx( /admin )
2001-04-24 08:51:01 - Ctx( /svlt ): Set debug to 9
2001-04-24 08:51:01 - ContextManager: Adding context Ctx( /svlt )
Starting tomcat. Check logs/tomcat.log for error messages
2001-04-24 08:51:01 - ContextManager: Adding context Ctx( )
2001-04-24 08:51:01 - ContextManager: Adding context Ctx( /test )
2001-04-24 08:51:01 - ContextManager: Adding context Ctx( /digiprop )
2001-04-24 08:51:02 - Ctx( /svlt ): XmlReader - init /svlt /digiprop
2001-04-24 08:51:02 - Ctx( /svlt ): Reading /digiprop/WEB-INF/web.xml
2001-04-24 08:51:02 - Ctx( /svlt ): Loading -2147483646 jsp
2001-04-24 08:51:02 - Ctx( /svlt ): Loading 1 flush
2001-04-24 08:51:03 - Ctx( /svlt ): Loading 1 page
2001-04-24 08:51:03 - Ctx( /svlt ): Loading 1 login
FATAL:java.net.SocketException: Address already in use
java.net.SocketException: Address already in use
java.lang.Throwable(java.lang.String)
java.lang.Exception(java.lang.String)
java.io.IOException(java.lang.String)
java.net.SocketException(java.lang.String)
void
java.net.PlainSocketImpl.socketBind(java.net.InetAddress, int)
void java.net.PlainSocketImpl.bind(java.net.InetAddress, int)
java.net.ServerSocket(int, int, java.net.InetAddress)
java.net.ServerSocket(int, int)
java.net.ServerSocket
org.apache.tomcat.net.DefaultServerSocketFactory.createSocket(int,
int)
void org.apache.tomcat.service.PoolTcpEndpoint.startEndpoint()
void org.apache.tomcat.service.PoolTcpConnector.start()
void org.apache.tomcat.core.ContextManager.start()
void
org.apache.tomcat.startup.Tomcat.execute(java.lang.String [])
void org.apache.tomcat.startup.Tomcat.main(java.lang.String [])
void digiprop.site.TomcatView.doStart()
void
digiprop.site.TomcatView.connEtoC2(java.awt.event.ActionEvent)
void
digiprop.site.TomcatView$IvjEventHandler.actionPerformed(java.
awt.event.ActionEvent)
void
java.awt.Button.processActionEvent(java.awt.event.ActionEvent)
void java.awt.Button.processEvent(java.awt.AWTEvent)
void java.awt.Component.dispatchEventImpl(java.awt.AWTEvent)
void java.awt.Component.dispatchEvent(java.awt.AWTEvent)
void java.awt.EventDispatchThread.run()
--
---
Brad
Re: Just say no to JSP Re: [Fwd: Tomcat may reveal scriptsource code by URL trickery]
At 11:24 AM -0700 04/04/2001, Jon Stevens wrote: I love the article title: "Just say no to JSP" Glad that change made it in. DDJ wanted "Just say no to HTML". Arggh. I'm so happy to see that more and more people are waking up to the fact that JSP is bad. I'm also happy to see you worry about form validation issues. That is a problem that we are currently solving in Turbine right now. It is called "Intake". :-) I'll try to make some time to check that out. It is sad to me that you: #0. Apache/JServe. Can't spell the product name correctly even though it has been around for 4+ years. :-) Sigh. Yet another typo. I really thought we'd caught them all. #1. Confused "Turbine" with "add programming language features to HTML". #2. Confused "WebMacro" and thus Velocity with "add programming language features to HTML". If you spend time with the products, you would see that isn't the case and you might actually retract your statements. You've touched a nerve here. This is the amount of time that gets consumed installing web based infrastructures. Maybe Turbine is an exception and I certainly hope so. I'll pick on Tomcat here because the wounds are still fresh from spending a whole week on what should be a trivial task; porting a running webapp from a deployment server running Linux 6.2 to the server from hell; a hacked "virtual" implementation of FreeBSD at HostPro.com. I should point out at the outset that this isn't to assign blame but to point out a problem... namely, the complexity that developers must deal with to get a working infrastructure in place. My application uses Apache, JServ, Java, and the servlet engine from Tomcat. Period. No taglibs, no JSP, no XML, nothing. Yet it took a whole week to get even this on the air, even though I've been through the tomcat configuration process dozens of time by now and had working config files to start with. Much of the problem was expecting the user (me) to translate exception backtraces into what should be done to correct the error. The first problem I hit was a NullPointerException while reading request parameters. Why? I've no idea. An unfamilar JRE was preinstalled so guessing, I installed plain ol' JDK1.1.7 and that seemed to fix it. Next problem was various JServ failures, none clearly explained by the errors, and none explaining what what was wrong and how to correct it in the config files. Then most of the week worrying about why Tomcat wasn't recognizing my servlet context. I've a bunch of ideas for partial solutions but I'll hold off on those to see whether there's any agreement that there's a problem here. I have more comments, but no time right now and this probably isn't the right forum anyway... I'd be grateful to hear them when you get a moment. -- --- Brad Cox, Ph.D.; [EMAIL PROTECTED] Phone: 703 361 4751 Cell: 703 919-9623 http://superdistributed.com: A new paradigm for a new millinneum
Re: An alternative to JSP
At 11:03 AM -0800 01/25/2001, Mel Martinez wrote: That presumes the line termination character of choice for the output is a linefeed character. Good point. Will fix when I get a moment. Another issue is that the example creates catenated String literals. I would hope that the actual code produced would use appropriately initialized StringBuffers or performance could be a problem. I've been assuming that concatenation of constants is collapsed at compile time. I'm sure this is true for SOME compilers but less sure this is true across the board. Could you elaborate on this point? Concatenation of non-constants is, of course, a different matter. I do use StringBuffers for these. Just some thoughts on the implementation. On the larger issue of this thread, I don't really see the benefit of something like MLS over JSP, which potentially allows you to completely remove all Java code from the html (by using jsp tags and taglibs), but take that as an imho. I don't view "eliminating java" as automatically beneficial. My goal is more to "eliminate html"; e.g. hiding it from view within classes in a format (MLS) that can be manipulated even by nonprogrammers, without "..."+ noise in the way. In other words, I view html as a problem to be hidden away and forgotten whereas JSP uses it as the foundation of the very programming language which keeps it right in my face. Some specific gripes with html: page references (a href, form) are hard-coded into each page. There is no way to check referential integrity except by testing each and every link. More seriously, every link bypasses all url session-encoding logic, so the user's session will be lost if they ever browse to a hard-coded html page. This has really poisonous user interface implications obviously. Finally, request.getParameter() returns Strings and/or nulls instead of providing a consistent validation architecture as described in the paper. Of course such an architecture could be easily added to JSP as user-level code (I offered to do as much for Tomcat but never heard back). The complaint is that JSP leaves this up to each user by implying that fields should be managed as Strings instead of taking active steps to help users realize that Strings (and nulls) should NEVER appear in higher-levels of an application, which is the very level that JSP addresses. For those who missed it, the article we're discussing is at http://virtualschool.edu/wap -- --- Dr. Brad Cox; [EMAIL PROTECTED] Phone: 703 361 4751 Fax: 703 995 0422 Cellular: 703 919-9623 http://superdistributed.com: A new paradigm for a new millinneum PGP Signature: E194 C6E5 92D8 B8FB 20E8 8667 929A 95A0 FCB6 7C62 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: An alternative to JSP
At 11:23 AM -0500 01/26/2001, Brad Cox wrote: so the user's session will be lost if they ever browse to a hard-coded html pag I meant to say... for browsers that don't support cookies or if the user has disabled cookies. -- --- Dr. Brad Cox; [EMAIL PROTECTED] Phone: 703 361 4751 Fax: 703 995 0422 Cellular: 703 919-9623 http://superdistributed.com: A new paradigm for a new millinneum PGP Signature: E194 C6E5 92D8 B8FB 20E8 8667 929A 95A0 FCB6 7C62 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Call for volunteers
I'd be glad to help with the servlet engine code. At 5:31 PM + 01/19/2001, Andrea Barbieri wrote: Ciao a tutti, hi to you Costin: i can help for points 3. Code review/Documentation: The code is not perfect, but it should do its job. Reading the tomcat.core and making sure it's ok is essential. 5. Testing your application with tomcat :-) ( this is probably a better and more important test than our regression ) enjoy Andrea Barbieri - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] -- --- Dr. Brad Cox; [EMAIL PROTECTED] Phone: 703 361 4751 Fax: 703 995 0422 Cellular: 703 919-9623 http://superdistributed.com: A new paradigm for a new millinneum PGP Signature: E194 C6E5 92D8 B8FB 20E8 8667 929A 95A0 FCB6 7C62 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: An alternative to JSP (REVISED)
Thanks to everyone for the comments on my paper. I've tried to address them in the revised version by emphasizing the validation and site architecture and moving MLS into the supporting article. The new version is at http://virtualschool.edu/wap. I'd be interested whether the validation/site stuff would be appropriate to add to Tomcat. I'd be glad to do the work if someone would point me in the right direction. on 1/10/01 7:52 PM, "Brad Cox" [EMAIL PROTECTED] wrote: I've uploaded an early rough draft of a pair of articles that boils down to a critique of the JSP approach plus source code for a quite different approach. I'd be very interested in feedback... of the constructive variety, of course ;) The articles are at http://virtualschool.edu/wap -- --- Dr. Brad Cox; [EMAIL PROTECTED] Phone: 703 361 4751 Fax: 703 995 0422 Cellular: 703 919-9623 http://superdistributed.com: A new paradigm for a new millinneum PGP Signature: E194 C6E5 92D8 B8FB 20E8 8667 929A 95A0 FCB6 7C62 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: An alternative to JSP
Thanks. No I'm not aware of Turbine, but I am aware of the approach described in the paper. That's what the company I was consulting for took that I (perhaps inaccurately) described as "similar to WebMacro". MLS? Preprocess code? WHAT? Could you explain what you mean by this? At 9:41 PM -0800 01/10/2001, Jon Stevens wrote: on 1/10/01 7:52 PM, "Brad Cox" [EMAIL PROTECTED] wrote: I've uploaded an early rough draft of a pair of articles that boils down to a critique of the JSP approach plus source code for a quite different approach. I'd be very interested in feedback... of the constructive variety, of course ;) The articles are at http://virtualschool.edu/wap -- --- Dr. Brad Cox; [EMAIL PROTECTED] Phone: 703 361 4751 Fax: 703 995 0422 Cellular: 703 919-9623 http://superdistributed.com: A new paradigm for a new millinneum PGP Signature: E194 C6E5 92D8 B8FB 20E8 8667 929A 95A0 FCB6 7C62 MLS? Preprocess code? WHAT? Have you even looked at what we are doing in Turbine/Velocity land? Also, let me also refer you to: http://java.apache.org/turbine/pullmodel.html -jon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] -- --- Dr. Brad Cox; [EMAIL PROTECTED] Phone: 703 361 4751 Fax: 703 995 0422 Cellular: 703 919-9623 http://superdistributed.com: A new paradigm for a new millinneum PGP Signature: E194 C6E5 92D8 B8FB 20E8 8667 929A 95A0 FCB6 7C62 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: An alternative to JSP
At 11:30 AM -0500 01/11/2001, Shawn McMurdo wrote:
I agree with most of your discussion of the disadvantages of JSP/ASP/etc,
but I believe your solution does not address a fundamental problem, which
is the complete separation of presentation resources from presentation logic.
That is correct. My goal at this point is to get free of JSP so the
goal was only to duplicate what JSP does in a way I can live with.
Having the HTML embedded in a java class may be suitable for small
applications
built by engineers but does not address the vast majority of applications
where designers work on HTML using many different HTML editing tools
while developers work on the application logic in Java using various IDEs and
editors.
Perhaps I miscommunicated. The private methods that contain the
{{html}} need not be private methods in the controller class,
although that is the style I demonstrated in the paper and that I use
in my own I-do-it-all work.
Also there is nothing that requires these view methods to contain
hardcoded strings, other than the crude measurements in the
Conclusion section that makes me doubt that the space issue is a
primary concern. Each method could aim MLS at an html file at runtime
(using the doStream() method that it provides for this purpose but
which I didn't mention in the article) and let it do the executable
inclusion at runtime. But good point; I'll make this explicit in the
article.
This would also eliminate the need for the outermost enclosing {{...}}, but
the executable inclusion brackets would remain. Do you object to my
belief that html experts and their tools couldn't be trained to
ignore the {{...}} wrappers around the html? I'd be interested in
hearing more about this. After all, JSP has the same problem its %=
... % executable inclusion syntax.
Please take a look at:
http://www.enhydra.org
and
http://xmlc.enhydra.org
for more information.
Will do. Looks a lot like WebMacro at first glance.
--
---
Dr. Brad Cox; [EMAIL PROTECTED]
Phone: 703 361 4751 Fax: 703 995 0422 Cellular: 703 919-9623
http://superdistributed.com: A new paradigm for a new millinneum
PGP Signature: E194 C6E5 92D8 B8FB 20E8 8667 929A 95A0 FCB6 7C62
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
Re: An alternative to JSP
At 11:12 AM -0800 01/11/2001, Craig R. McClanahan wrote:
* I don't see any reasoning for why HTML-in-Java is better
than any of the alternatives -- just a presumptive conclusion.
The vast majority of the article is simply a description of your
recommended approach.
Good point. I'll expand on this argument in the article even though
it is most relevant in the context of JSP *AND* MLS versus the
template approaches I'm aware of. That's because both JSP and MLS use
a general purpose language for executable inclusions, whereas the
template systems I've examined closely (one at this point) do not
provide general-purpose language capabilities.
* Worse, this approach does other things:
* Embeds presentation and business logic in one class,
which is not a particularly scalable approach
* Requires a Java developer to do your page development
* Makes it difficult to leverage page authoring tools
Perhaps I miscommunicated. The private methods that contain the
{{html}} need not be private methods in the controller class,
although that is the style I demonstrated in the paper and that I use
in my own work.
Noting requires the view methods to contain hardcoded strings, other
than the crude measurements in the Conclusion section that makes me
doubt that the space issue is a primary concern. Each method could
aim MLS at an html file at runtime (using the doStream() method that
MLS provides for this purpose but which I didn't mention in the
article) and let it do the executable inclusion at runtime. But good
point; I'll make this explicit in the article.
This would also eliminate the need for the outermost enclosing {{...}}, but
the executable inclusion brackets would remain. Do you object to my
belief that html experts and their tools couldn't be trained to
ignore the {{...}} wrappers around the html? I'd be interested in
hearing more about this. After all, JSP has the same problem its %=
... % executable inclusion syntax.
* My personal preference for the presentation layer is JSP (and has
been since long before I adopted a "sun.com" email address :-), for
several reasons:
* Separation of concerns - Mixing business logic and presentation
logic in one file (no matter what the syntax) works OK for simple
applications, but is not a particularly flexible long term approach.
All of the alternatives you compare yourself to have learned (and
implemented) this lesson. Is there perhaps a message here that
you are missing?
I never advocated this. Syntactic validation is the responsibility of
each field, low-level semantic validation is the responsibility of
the controller, and high-level semantic validation is the
responsibility of the Bean, in some cases even in the DBMS (although
MySQL doesn't support this).
* Custom tags - can be used to encapsulate sophisticated
functionality in a variety of ways, including smarter generation
of HTML to configuring application functionality). See the
Struts Framework project http://jakarta.apache.org/struts
to get a feel for what's possible. (And Struts/Turbine/Barracuda
each offers an alternative approach to the organization of the
business logic as well.)
I've looked at struts but not at the others. Struts sounds like a great
improvement to JSP and I'd probably have adopted it were it not for
the base objection to the whole java-in-html approach.
* Development tools - Watch what tools like Macromedia Ultradev
do for page developers (*not* Java developers!!!) who want to
author pages that use custom tags for dynamic pages. I do
not see a big future in hand coded HTML.
See above re reading html from files through MLS.
* Alternative implementations - If Tomcat doesn't generate "good
enough" or "fast enough" code for you (and it's pretty minimally
acceptable at the moment), you've got choices of other vendors,
with a reasonable shot at your pages being portable if you take
MLS relies only on Java and the servlet API. Should be portable to
anywhere, right?
--
---
Dr. Brad Cox; [EMAIL PROTECTED]
Phone: 703 361 4751 Fax: 703 995 0422 Cellular: 703 919-9623
http://superdistributed.com: A new paradigm for a new millinneum
PGP Signature: E194 C6E5 92D8 B8FB 20E8 8667 929A 95A0 FCB6 7C62
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
Re: An alternative to JSP
I think these two quotes from the website will address your concern. There is no official release yet, but there will be one shortly. Velocity's design concept is borrowed from WebMacro. At 11:42 AM -0800 01/11/2001, Jon Stevens wrote: on 1/11/01 11:21 AM, "Brad Cox" [EMAIL PROTECTED] wrote: Please take a look at: http://www.enhydra.org and http://xmlc.enhydra.org for more information. Will do. Looks a lot like WebMacro at first glance. -- Absolutely not. XMLC is way different than WM or Velocity. Also, look at: http://jakarta.apache.org/velocity/ p.s. It is interesting that you are a PhD. yet you haven't done any research into the alternatives that are out there. Instead you just invented your own. Sigh. -jon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] -- --- Dr. Brad Cox; [EMAIL PROTECTED] Phone: 703 361 4751 Fax: 703 995 0422 Cellular: 703 919-9623 http://superdistributed.com: A new paradigm for a new millinneum PGP Signature: E194 C6E5 92D8 B8FB 20E8 8667 929A 95A0 FCB6 7C62 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
An alternative to JSP
I've uploaded an early rough draft of a pair of articles that boils down to a critique of the JSP approach plus source code for a quite different approach. I'd be very interested in feedback... of the constructive variety, of course ;) The articles are at http://virtualschool.edu/wap -- --- Dr. Brad Cox; [EMAIL PROTECTED] Phone: 703 361 4751 Fax: 703 995 0422 Cellular: 703 919-9623 http://superdistributed.com: A new paradigm for a new millinneum PGP Signature: E194 C6E5 92D8 B8FB 20E8 8667 929A 95A0 FCB6 7C62 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
