JRun behavior is VERY different than ServletExec ones
JRun 2.3.1 (just upgraded)
RedHat Linux 5.2 with kernel 2.2.6
Apache 1.3.3
JDK1.2
JRun has a couple of feature (bugs?, spec 0.92 misundertanding?) that
there aren't in Sun's ServletExec:
1) ServletExec parse the JSP page and generate the servlet in sequence,
e.g., if you
have some Java code % % between some tags like LOOP .. etc,
you get what you expect:
the order of the method calls to the bean is the order of you see in
the JSP page.
JRun, instead seems to me to parse FIRST all the component centric
tags (LOOP, DISPLAY etc.) and
THEN, and only then execute the Java code between the % %.
So, if you have the LOOP tags to modify the state of your bean, this
state is not granted in % % tags.
2) Indexed property does not adhere to 0.92 specification:
a property like:
...
String getFoo() {
return some_what;
}
int getFooSize() {
return the_size_of_foo;
}
...
used in a LOOP tags gives you an:
"[] can only be applied to arrays" ...
error.
Anyone of you had the same problems?
Any workarounds?
--
Roberto Torresani
---
Informatica e Statistica Applicate
Istituto Agrario di S.Michele all'Adige
Via E.Mach, 1
38010 S.Michele a/Adige - TN - ITALY
---
Tel. 0461/615230 - Fax. 0461/650872
===
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff JSP-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
JSP tools
Could you give me, please, a list of JSP modules for Apache? What about GNUJSP? When will it adhere to 0.92 spec? -- Roberto Torresani --- Informatica e Statistica Applicate Istituto Agrario di S.Michele all'Adige Via E.Mach, 1 38010 S.Michele a/Adige - TN - ITALY --- Tel. 0461/615230 - Fax. 0461/650872 === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message "signoff JSP-INTEREST". For general help, send email to [EMAIL PROTECTED] and include in the body of the message "help".
Re: Pagelets Proposal
I've enjoyed reading the thread on Pagelets, but I'm not convinced the whole of the Pagelet proposal is needed. But I could well be missing something here (all clues appreciated!) From what I can gather, all you require is for a bean to have a destroy() method called, if it has one. I.e., if the bean scope is "page" and it has a destroy method, call that method at the end of the page. You can extend this to calling destroy at the end of the request if the scope was request and so on. (Hold on... in what order would you destroy them? Would it matter?) The rest of the aims -- I *think* --- are already handled in the servlet/JSP specs. For example, the beans can be initialized via the Method 2 way of doing things: you write a servlet to create the beans, and then setAttribute() them before calling the dispatcher to forward to a JSP page. In the jdbcConnection/allUsers/allGroups example, you would do all the work (SQL etc) in the servlet and forward the populated beans on for display in the JSP. Richard __ Get Your Private, Free Email at http://www.hotmail.com === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message "signoff JSP-INTEREST". For general help, send email to [EMAIL PROTECTED] and include in the body of the message "help".
Re: JSP tools
And when will it be released? Vincent Partington wrote: Hi Roberto, Roberto Torresani wrote: What about GNUJSP? When will it adhere to 0.92 spec? GNUJSP will never adhere to the JSP 0.92 spec. However I am currently reading the draft of the 1.0 spec and plan to implement that as soon as possible. Regards, Vincent. -- Roberto Torresani --- Informatica e Statistica Applicate Istituto Agrario di S.Michele all'Adige Via E.Mach, 1 38010 S.Michele a/Adige - TN - ITALY --- Tel. 0461/615230 - Fax. 0461/650872 === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message "signoff JSP-INTEREST". For general help, send email to [EMAIL PROTECTED] and include in the body of the message "help".
web hosts?
Hi, Does anyone know about web hosting companies that support JSP? Thanks in advance, Ferenc Csizmadia === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message "signoff JSP-INTEREST". For general help, send email to [EMAIL PROTECTED] and include in the body of the message "help".
Test
Test (with apologies) - I did not get a confirmation from [EMAIL PROTECTED] for subscription === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message "signoff JSP-INTEREST". For general help, send email to [EMAIL PROTECTED] and include in the body of the message "help".
Re: A Compatibility Proposal
why not say: A portable Tag Extension Mechanism will be available in JSP 1.1. The following extension tags must be implemented in 1.1 compliant servers jsp:loop jsp:includeif jsp:excludeif. Implementing these tags (albeit non-portably) is optional for JSP 1.0 servers. Orion does just that in it's 1.0 implementation. We have not removed the 0.92 tags, but rather moved them to jsp: as you suggested, we use jsp:includeIf/jsp:excludeIf though (note the casing, tags are case sensitive in the 1.0 spec). /Magnus Stenman Orion WebServer - http://orion.evermind.net === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message "signoff JSP-INTEREST". For general help, send email to [EMAIL PROTECTED] and include in the body of the message "help".
Re: A Compatibility Proposal
We made the decision to retain the 0.92 tags in our current 1.0 implementation for the reason that this is an 1.0 preliminary release, not the final release, and as strong members of the "anti scriptlet when not needed" camp we would very much like to see the loop etc tags included in the 1.0 spec. Sure, 1.1 will have the extensible tags library functionality (which is a *great* idea by the way), but we think the loop, includeIf etc tags should be "core" anyways - not an extension. /Magnus Stenman Orion WebServer - http://orion.evermind.net -Original Message- From: A mailing list about Java Server Pages specification and reference [mailto:[EMAIL PROTECTED]] On Behalf Of Foster Bob Sent: den 8 maj 1999 06:36 To: [EMAIL PROTECTED] Subject:Re: A Compatibility Proposal Why have a taglib directive if there is no standard for tag extensions? Obviously it's there because some JSP implementors were planning to introduce their own non-standard tags (heck, they already have) and/or wanted to jump the gun on extendable tag libraries. This is a tricky situation, standards-wise. Given the thirst frequently expressed here for more HTML-writer-friendly JSP pages, I'd guess people will use these vendor-specific tags. Which could easily mean that pages written for one implementation won't run on another, which is no standard at all. It is way more important to ensure this doesn't happen than to squeeze a few more tags into JSP 1.0. Given that everything can't happen overnight, Sun has chosen a sensible middle ground. The taglib directive, together with the set of guidelines for tags (rather quietly blended into the 1.0 spec) makes it at least possible that pages using extended tags won't have to be rewritten to work with JSP 1.1. I'd expect Sun to be working closely with implementors to ensure that "pre-release" tag extension mechanisms can work in other vendors' implementations, and can easily conform to the eventual 1.1 standard. Meanwhile, the right short term answer for friendly coexistence with HTML designers is to develop a programming style that minimizes the amount of raw Java in JSP files and makes maximal use of the standard tags that _do_ exist in 1.0. Bob Foster Symantec Internet Tools http://www.visualcafe.com/ __ Reply Separator _ Subject: Re: A Compatibility Proposal Author: Scott Ferguson [EMAIL PROTECTED] at Internet Date:5/7/99 5:30 PM 1.0 already has this. That's the point of the taglib directive. JSP Implementations are perfectly free to implement their own tag extensions. Granted, it's not standardized yet, but I'd rather the JSP team focus on cleaning 1.0 up, shipping it, and then focusing on standard tags. We've already waited far too long to get 1.0. I really don't want to delay 1.0 until everyone gets their favorite feature added. 2.8.4 the taglib directive "This directive declares that the page uses custom tags, ..." Scott Ferguson Caucho Technology Ben Engber wrote: Optional support in 1.0 is an excellent idea. As with a lot of people on this list, the non-scripting tags were THE selling point of JSP for me. Instead of saying something like: LOOP, EXLUDEIF, INCLUDEIF are postponed until when a Tag Extension Mechanism is made available... why not say: A portable Tag Extension Mechanism will be available in JSP 1.1. The following extension tags must be implemented in 1.1 compliant servers jsp:loop jsp:includeif jsp:excludeif. Implementing these tags (albeit non-portably) is optional for JSP 1.0 servers. At least then we'll have the stubs to design pages without scriptlet code all over. In fact, it's not even necessary to define the names or formats of those three tags. Even this would be fine: JSP 1.0 compliant servers should implement these three functions ... These functions will be formalized as part of a Tag Extension Mechanism in JSP 1.1. My reasoning here is that it will probably be less intrusive to port from one extension tag syntax to another than it would be to port from a scriptlet-based page to a tag-based page. Not to mention making planning ahead easier. -Ben At 09:13 AM 5/7/99 -0500, Mark A. Kolb wrote: I predict, however, that as soon as 1.1 becomes available, someone is going to write and release a tag library that implements the 0.92 tags (it might even be me :). To save much anguish in the meantime, then, I would like to suggest that the 1.0 spec include optional support for such a tag library, now. === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message "signoff JSP-INTEREST". For general help, send email to [EMAIL PROTECTED] and include in the body of the message "help". === To unsubscribe, send email to [EMAIL
Re: A Compatibility Proposal
Whether to retain the tags is your decision, but moving them to the jsp namespace is questionable. Unless you have advance knowledge these tags will appear in a future version of JSP, you should put them in your own namespace and allow developers to include a taglib directive specifying your namespace. This way, your tags will work in 1.1 and developers won't have to rewrite the pages that use your tags. Bob Foster Symantec Internet Tools http://www.visualcafe.com/ __ Reply Separator _ Subject: Re: A Compatibility Proposal Author: Magnus Stenman [EMAIL PROTECTED] at Internet Date:5/8/99 6:44 PM why not say: A portable Tag Extension Mechanism will be available in JSP 1.1. The following extension tags must be implemented in 1.1 compliant servers jsp:loop jsp:includeif jsp:excludeif. Implementing these tags (albeit non-portably) is optional for JSP 1.0 servers. Orion does just that in it's 1.0 implementation. We have not removed the 0.92 tags, but rather moved them to jsp: as you suggested, we use jsp:includeIf/jsp:excludeIf though (note the casing, tags are case sensitive in the 1.0 spec). /Magnus Stenman Orion WebServer - http://orion.evermind.net === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message "signoff JSP-INTEREST". For general help, send email to [EMAIL PROTECTED] and include in the body of the message "help". === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message "signoff JSP-INTEREST". For general help, send email to [EMAIL PROTECTED] and include in the body of the message "help".
Re: Another configuration question...
Hi Michael, I couldn't see a reply on the list to your question, so I thought I would give it a shot Do you realise that the Sun 1.0 reference implementation is a complete web sever, servlet runner and JSP engine ? Many people seem to think it's something you need to plug into an existing web server and/or servlet runner, but it's not. Once configured correctly, you run the script/bat file and it starts listening on port 8080 (by default) for http requests. You don't need Apache and JServ to use it. This may not be ideal if you want all requests to run through your Apache server. I have seen posts on this list, or maybe the servlet one, with people talking about how to setup Apache so that it forwards requests to the reference implementation based on the URL path, I think. I would recommed checking the list archives. Hope this helps. Regards Drew Cox -Original Message- From: Michael Rumpf [SMTP:[EMAIL PROTECTED]] Sent: Friday, 7 May 1999 18:34 To: [EMAIL PROTECTED] Subject: Another configuration question... Hi ! Maybe the problem is already solved, if so, please someone give me a hint ! I have the following configuration running: Sun Solaris 2.6 Apache 1.3.6/PHP3/JServ1.0b4 JSDK 2.0 JDK 1.2.1_02 ( or JDK 1.1.8) I would like to set up Apache to make Sun's JSP1.0 reference implementation work on the configuration above. Is this possible or not ? And if not what do I have to change to get it running. If this is not working I would like to use GNUJSP but I could not find the 0.91 specification for JSP to find out what exactly GJSP 0.9.9 supports. I am trying for one week now and I did not manage to get any other system running PLEASE HELP !!! Michael Rumpf == = To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message "signoff JSP-INTEREST". For general help, send email to [EMAIL PROTECTED] and include in the body of the message "help". === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message "signoff JSP-INTEREST". For general help, send email to [EMAIL PROTECTED] and include in the body of the message "help".
Re: JSP SQL Stores Procedures
Hi Brian, I can give a general opinion on the use of database stored procedures, unfortunately from traditional client-server experience, rather than JSP, although I think some similar issues apply. We investigated the use of stored procedures for any of the core database transactions that we could easily package into the procedure 4GL language provided by the DBMS, in this case OpenIngres. This would provided the performance advantage of sending only a procedure trigger and parameters to the DBMS, rather than a sequence of SQL statements. This makes more sense the lower the bandwidth of your connection between the client and DBMS server. Also, the stored procedures were precompiled and the SQLs in them used stored query plans (like JDBC prepared statements) for further performance improvements. But, we decided against them. The problem was with maintainability and cohesiveness of the system. Our product is installed all over the country and we regularly (too regularly if you ask our customers :-) distribute patches and updates. It's a lot easier to change SQL statements in the source code and distribute a new version of the program, than to write scripts to unload and reload stored procedures in the database. Also, if you want to understand how a particular process works, you just look at the source, rather than chasing all over the system extracting stored procedures and reformatting them so you can read them. Also, we found that individual clients had a habit of playing (well, trying to administer...) their DBMS server and regularly loosing the stored procedures. We could distribute the code, but we couldn't easily ensure the Database had everything in it it needed. One idea was to have the client code actually (re)create the stored procedures at runtime if required, either because they were missing or out of date. This would make all the functionaly visible in the source too. Maybe the OpenIngres tools for stored procedures aren't up to scratch and with some other DBMS all this would not be a big issue ? Which brings the point of portability amoung DBMS vendors. In my limited experience, SQL may be somewhat standardised (in 26 exciting flavours), but stored procedures are not. Just my AUS$0.02 (which is about US$0.012) Drew -Original Message- From: Brian Burridge [SMTP:[EMAIL PROTECTED]] Sent: Saturday, 8 May 1999 0:47 To: [EMAIL PROTECTED] Subject: JSP SQL Stores Procedures I just wanted to get some of your opinions on this. We are having an internal discussion about whether or not to use stored procedures for our SQL, or to put the SQL in the bean or JSP page. Does anyone have any recommendations either way? Suggestions? Brian N. Burridge Web Analyst Cox Target Media == = To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message "signoff JSP-INTEREST". For general help, send email to [EMAIL PROTECTED] and include in the body of the message "help". === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message "signoff JSP-INTEREST". For general help, send email to [EMAIL PROTECTED] and include in the body of the message "help".
Re: Pagelets Proposal
Hi Chris, The base bean is really a bean, because it has properties related to its underlying database entity. I understand your architecture, although I guess it comes down to what we mean when we say "bean"And I think we would have to defer to Sun for the official definition of that. I see that various JavaBeans as a software component standard. You may see you "data-model" classes in that scope too ? I am a little reluctant to call something bean just because we create getter and setter method on the instance variables ;-) I am curious though (and to try to bring this thread back to JSP), do you find you use this distinct model-view-controlled class demarcation scheme for all your JSP developments, or is it only worthwhile on projects over a certain threshold of complexity ? Regards Drew Cox Barrack Consulting -Original Message- From: Christopher Cobb [SMTP:[EMAIL PROTECTED]] Sent: Saturday, 8 May 1999 3:44 To: Drew Cox Cc: [EMAIL PROTECTED] Subject: Re: Pagelets Proposal Drew Cox wrote: ... I firmly believe your "model" classes should not be tied to a particular presentation format (JSP, GUI, ??). But remember, this is just a class, not a bean. This "model" class can be composited into, or inherited from, in a JSP-aware bean that handles creating a HTML-(XML) based view of that model. I usually ended up having two beans: * a "pure" bean which had zero knowledge of presentation issues (and is often closely bound to a database entity), and * a derived bean which had presentation support for a particular context. The derived bean uses the properties but adds presentation support. My point is that what you are calling "just a class, not a bean", I find definitely *should* be a bean, but a "pure" bean, not a "JSP bean". cc File: Card for Christopher Cobb === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message "signoff JSP-INTEREST". For general help, send email to [EMAIL PROTECTED] and include in the body of the message "help".
