Re: Using web server to restrict JSP access
Dave, I believe this was once brought up on the Live Software newsgroup. I had a similar problem with JRun and servlets. I do believe that it has something to do with running the ISAPI filter jrun.dll as a global filter. I'd go to Allaire (where Live Software now resides) and start poking around. -- chris -- > -Original Message- > From: A mailing list about Java Server Pages specification and reference > [mailto:[EMAIL PROTECTED]]On Behalf Of Dave Ferguson > Sent: Monday, August 16, 1999 4:57 PM > To: [EMAIL PROTECTED] > Subject: Using web server to restrict JSP access > > > We're running IIS 4.0 on NT and using JRun 2.3 as our JSP/servlet > engine. I have a set of JSP's that I'm using in a "Model 1" > configuration. I need to restrict access to these JSP's, so my > thinking was just to use the authentication control options in > the IIS web server. > > Unfortunately, no matter what kind of restrictions I set up, the > JSP's display normally. This is true even when I deny annonymous > access. In contrast to JSP's, pure HTML files are restricted > correctly. I also tried setting up IIS to deny access to the JSP > files for all but certain IP addresses. Again, these > restrictions were ignored and the JSP's displayed normally. > > It seems as though JRun (an ISAPI "plug-in") is circumventing the > restrictions placed on a resource by the web server. This is my > guess as to what's happening: JRun intercepts the http request > before IIS restrictions are processed. It sees the ".jsp" > extension on the resource requested, runs the generated servlet, > and pushes the HTML back to the web server. The web server then > sends the response to the requesting client, no questions asked. > > Anyone have any experience or have any ideas how to make this > work? I realize that I could build the username/password > functionality into the JSP's themselves, but it seems like a bad > use of time and resources for something a web server is designed > to do.. It just makes more sense to do it from the web server > for our situation. > > Thanks, > Dave F. > > P.S. We also tried to set up username/password access to the > JSP's using a 3rd party tool called "AuthentiX". The result was > amusing. When an invalid UN/PW was entered, the "invalid" > message was shown properly, but right below that the restricted > JSP was displayed! I guess strange things happen when two ISAPI > products don't work together. > > == > = > 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". > For JSP FAQ, http://www.esperanto.org.nz/jsp/jspfaq.html > === 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". For JSP FAQ, http://www.esperanto.org.nz/jsp/jspfaq.html
Re: Questions on JSP Techniques for limiting java within the JSP (tms)
It may have been mentioned here before, but O'Reilly has put out a book on EJB. Richard Monson-Haefel authored it and it's a good read (as are most O'Reilly books). Just a thought. -- chris -- > -Original Message- > From: A mailing list about Java Server Pages specification and reference > [mailto:[EMAIL PROTECTED]]On Behalf Of Pankaj Malviya > Sent: Friday, August 13, 1999 3:03 AM > To: [EMAIL PROTECTED] > Subject: Questions on JSP Techniques for limiting java within the JSP > (tms) > > > Chris, > > My doubts: > 1) To avoid writing any HTML code inside java bean, > one will send results in form of Vector,Strings and > then it will be used inside JSP to present into HTML > format. This may be a complicated table too. Whether > this will have effect on performance ? Also, Since > this is a dynamic generated table, The presentation > designer won't be able to do much. So does it make > sense to generate such tables inside bean. > 2) You said application server is used to provide > business logic and DB connectivity. what is the cost > involved in locating remote objects thru ORB. Do you > keep objects in any pool to use later, or locate > objects everytime. > > Pankaj > --- Chris Bartling <[EMAIL PROTECTED]> > wrote: > > Hi, > > > > I've been converting our Web application from > > servlets to JSPs and I've made > > sure that my JSPs are dealing only with business > > objects implementing > > standard interfaces. We have a requirement that our > > persistent business > > objects be able to work with a number of RDBMSs, so > > my JSPs only "know" > > about the business object interfaces and the methods > > these interfaces > > support. I don't do any sort of JDBC access from my > > JSPs, deferring this > > responsibility to an app server (we're currently > > using Objectspace's Voyager > > product for ORB communications, but we'll be moving > > over to EJB very soon > > now). I've also created a bean which acts as a > > client on the ORB and pass > > this between JSPs through the Session object. This > > design is working great > > for us. I've noticed a huge improvement in > > productivity with JSPs over > > servlets, and I was one of these people who used > > regular expressions and > > token replacement within servlets and poo-pooed JSPs > > initially. > > > > I feel the more functionality that you can > > encapsulated into beans (whether > > in the JSP/servlet engine or in an app server), the > > better. EJB with the > > interactions of Session beans and Entity beans > > should really further this > > along. JSPs become purely presentation vehicles; > > the task at hand is dealt > > with by Session beans and their interactions with > > Entity beans. By > > encapsulating functionality at the app server, you > > can reuse your beans in > > other presentation mediums (for our situation, we > > are using Java Plugin > > applets alongside our JSPs for more complex UIs, and > > the Voyager 3.1 ORB > > allows us to communciate with COM/DCOM applications, > > dare I say it). > > > > Overall, I've been very, very pleased with the JSP > > 1.0 implementation (in > > particular Live Software's JRun implementation). > > > > > > -- chris -- > > > > > > > > > -Original Message- > > > From: A mailing list about Java Server Pages > > specification and reference > > > [mailto:[EMAIL PROTECTED]]On Behalf Of > > Frank Starsinic > > > Sent: Thursday, August 12, 1999 3:10 PM > > > To: [EMAIL PROTECTED] > > > Subject: JSP Techniques for limiting java within > > the JSP (tms) > > > > > > > > > One issue that keeps coming up is the combination > > of java code > > > and HTML being > > > put in the same > > > place, i..e., the JSP page. > > > > > > What techniques are people using to limit the > > amount of java within a JSP. > > > > > > I realize that the use of the Bean can do just > > that; allowing the use of > > > <%=bean.getValue()%> > > > That is clear. > > > > > > What are other techniques that are being used to > > help the JSP > > > developer not > > > worry about the back end. Are Beans being > > designed in a > > > particular way to > > > make it easier for the JSP developer. It seems > > they could be and
Re: Questions on JSP Techniques for limiting java within the JSP (tms)
Pankaj, Regarding your doubts > -Original Message- > From: A mailing list about Java Server Pages specification and reference > [mailto:[EMAIL PROTECTED]]On Behalf Of Pankaj Malviya > Sent: Friday, August 13, 1999 3:03 AM > To: [EMAIL PROTECTED] > Subject: Questions on JSP Techniques for limiting java within the JSP > (tms) > > > Chris, > > My doubts: > 1) To avoid writing any HTML code inside java bean, > one will send results in form of Vector,Strings and > then it will be used inside JSP to present into HTML > format. This may be a complicated table too. Whether > this will have effect on performance ? Also, Since > this is a dynamic generated table, The presentation > designer won't be able to do much. So does it make > sense to generate such tables inside bean. Someone else remarked about having beans generate HTML. I see the utility in this, but I personally am going to avoid its use. What if I want to use XML with XSL, or whatever the stylesheet standard will be? The HTML generator bean won't do much good now. I think its safe to say that JSP will be intimately tied to XML (I know that the JRun implementation already uses XML tools heavily). I also do a lot with transforming business objects into Javascript objects and collections. > 2) You said application server is used to provide > business logic and DB connectivity. what is the cost > involved in locating remote objects thru ORB. Do you > keep objects in any pool to use later, or locate > objects everytime. Currently I use our app server in the following way: I locate the servant which handles all the requests for persistent business objects. The servant, lets call it DBServant, encapsulates the functionality of externalizing and internalizing business objects. For our situation, we're using Objectmattter's VBSF 2.03, but I've also used Watershed Technologies' Relational Object Framework with similar success. These two tools map relational tables, subset of tables, and supersets of two or more tables to Java objects. Now, if one wants to do some sort of object caching within the DBServant, that requirement can be satisfied through the use of these OR mapping tools (to varying degrees). I'm fairly sure there are other OR mapping tools that do this same sort of thing. When I locate an object, I'm locating the service object, DBServant, which handles the business object externalization and internalization. I don't currently locate each business object on the ORB. My DBServant is acting much the same as an EJB home interface. I believe that in EJB, you locate the busines object container first before locating the actual business object (the EntityBean or SessionBean). I keep a reference to the DBServant in a session lifecycled JSP bean, so I'm not locating it everytime I want to use it. Note that this situation of every session keeping a reference to the DBServant may change in the future to some sort of DBServant reference pooling. I originally thought that I would take a significant performance hit using the ORB. In reality, the only real perceivable performance hit is the initial lookup of the servant. For our situation, the performance degradation that we seen is satisfactory to us, as we need the flexibility of accessing our business logic from other presentation vehicles besides JSP and servlets. If there's one thing you can count on, it's that your UI will change over time. The UI is a **paper cup**, so make it easy to change without rippling changes through the rest of your applications dependent on shared business logic. We'll see how all this turns out; it seems like we're always learning ways to do things better and this project is no exception. Hope this helps. -- chris -- > > Pankaj > --- Chris Bartling <[EMAIL PROTECTED]> > wrote: > > Hi, > > > > I've been converting our Web application from > > servlets to JSPs and I've made > > sure that my JSPs are dealing only with business > > objects implementing > > standard interfaces. We have a requirement that our > > persistent business > > objects be able to work with a number of RDBMSs, so > > my JSPs only "know" > > about the business object interfaces and the methods > > these interfaces > > support. I don't do any sort of JDBC access from my > > JSPs, deferring this > > responsibility to an app server (we're currently > > using Objectspace's Voyager > > product for ORB communications, but we'll be moving > > over to EJB very soon > > now). I've also created a bean which acts as a > > client on the ORB and pass > > this between JSPs through the Session object. This > > design is working great > >
Re: JSP Techniques for limiting java within the JSP (tms)
Hi,
I've been converting our Web application from servlets to JSPs and I've made
sure that my JSPs are dealing only with business objects implementing
standard interfaces. We have a requirement that our persistent business
objects be able to work with a number of RDBMSs, so my JSPs only "know"
about the business object interfaces and the methods these interfaces
support. I don't do any sort of JDBC access from my JSPs, deferring this
responsibility to an app server (we're currently using Objectspace's Voyager
product for ORB communications, but we'll be moving over to EJB very soon
now). I've also created a bean which acts as a client on the ORB and pass
this between JSPs through the Session object. This design is working great
for us. I've noticed a huge improvement in productivity with JSPs over
servlets, and I was one of these people who used regular expressions and
token replacement within servlets and poo-pooed JSPs initially.
I feel the more functionality that you can encapsulated into beans (whether
in the JSP/servlet engine or in an app server), the better. EJB with the
interactions of Session beans and Entity beans should really further this
along. JSPs become purely presentation vehicles; the task at hand is dealt
with by Session beans and their interactions with Entity beans. By
encapsulating functionality at the app server, you can reuse your beans in
other presentation mediums (for our situation, we are using Java Plugin
applets alongside our JSPs for more complex UIs, and the Voyager 3.1 ORB
allows us to communciate with COM/DCOM applications, dare I say it).
Overall, I've been very, very pleased with the JSP 1.0 implementation (in
particular Live Software's JRun implementation).
-- chris --
> -Original Message-
> From: A mailing list about Java Server Pages specification and reference
> [mailto:[EMAIL PROTECTED]]On Behalf Of Frank Starsinic
> Sent: Thursday, August 12, 1999 3:10 PM
> To: [EMAIL PROTECTED]
> Subject: JSP Techniques for limiting java within the JSP (tms)
>
>
> One issue that keeps coming up is the combination of java code
> and HTML being
> put in the same
> place, i..e., the JSP page.
>
> What techniques are people using to limit the amount of java within a JSP.
>
> I realize that the use of the Bean can do just that; allowing the use of
> <%=bean.getValue()%>
> That is clear.
>
> What are other techniques that are being used to help the JSP
> developer not
> worry about the back end. Are Beans being designed in a
> particular way to
> make it easier for the JSP developer. It seems they could be and
> i'm wondering
> about any good rules of thumb, etc.
>
> Looping thru a vector of objects and then hashtables of stuff within each
> object, and having to turn it all into strings and pump it all
> thru html etc.
> can require a lot of java withing a JSP page. This is what i'd
> like to prevent
> if possible. What are other people doing here?
>
> We do Swing development and very little Web development right now
> and it seems
> to me that our Beans could/should be designed a bit differently
> if we were to
> use JSP, for instance, having all the getters return strings (to
> keep the JSP
> developer from having to convert everything to strings before
> displaying them
> on a web page, hence, cutting down on java code in the JSP)
>
> I hope this is somewhat clear...
>
> thanks,
> frank
>
>
> Craig McClanahan wrote:
>
> > Several people have asked questions about writing internationalized apps
> > with JSP. Having just done so (only with Western European languages so
> > far), I have learned some things that may be interesting to others in
> > the same situation. The basic components of my approach were as
> > follows:
> >
> > (1) All internationalized strings are stored in resource bundles
> >
> > I used property resource files named Resources.properties (the default
> > translation, which was English), and Resources_xx.properties (where "xx"
> > is the ISO code of the language), following the ResourceBundle naming
> > conventions. I heavily used the parameter replacement features like {0}
> > to synthesize internationalized messages that contained elements that
> > originated in the database.
> >
> > (2) Accessing the resource bundles from the web application
> >
> > I created a JavaBean called "BundleBean" that had a series of methods
> > with calling sequences like this:
> >
> > String message = bundleBean.getMessage(locale, "label.username");
> >
> > and it looked in the correct resource bundle for the language of this
> > locale. The bundle bean is stored in the application context in a
> > startup servlet, by calling:
> >
> > getServletContext().setAttribute("bundleBean", bundleBean);
> >
> > to make it available to both servlets and JSP pages.
> >
> > (3) Internationalize the business logic
> >
> > We had to deal with things like the fact that many European cities have
> > different names in different languages, so our business object
Re: Can you run JSP on PWS?
JRun 2.32 build 152 works great on PWS 4.0. We use it all the time for development. -- chris -- > -Original Message- > From: A mailing list about Java Server Pages specification and reference > [mailto:[EMAIL PROTECTED]]On Behalf Of Jeff Vaccaro > Sent: Monday, July 12, 1999 9:55 AM > To: [EMAIL PROTECTED] > Subject: Can you run JSP on PWS? > > > I was reading the post : > "JSP on IIS" > > then I was wondering if I could run JSP on PWS. > > Does anyone know? > > JeffV > [EMAIL PROTECTED] > > == > = > 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 under IIS or PWS
Go get JRun 2.32 (http://www.livesoftware.com). Follow the InstallShield install. Read the directions on how to configure IIS to properly work with JRun and its JSP implementation. Add the jsp extension mapping to IIS/PWS using the MMC console for IIS/PWS. Apply Build 152 patch (including copying the jrun.dll from the %JRUN%\connectors\isapi\intel-win directory to the %IIS%\scripts directory. Restart the JRun server. Viola, it works. I have had great success with the JRun product running with IIS 4.0 and PWS 4.0. Further configuration of the servlet engine is done through the JRun administration tool. Hope this helps. -- chris -- -Original Message-From: A mailing list about Java Server Pages specification and reference [mailto:[EMAIL PROTECTED]]On Behalf Of Audrey W MboghoSent: Monday, July 12, 1999 11:10 PMTo: [EMAIL PROTECTED]Subject: JSP under IIS or PWS Sun claims jsp runs under Microsoft's IIS, but does it? Without half a dozen plugins? Anyone out there had any success with this? If you have, please don't just say "Yes". Give some detail. Thanks!
Re: Severe bug JRUN 2.3.2 build 151 (IIS 4.0)
This bug seems to have been fixed in Build 152. Fetch the patch from http://www.livesoftware.com/products/jrun/updates.html. Note that you need to copy the jrun.dll from the JRun\connectors\isapi\intel-win to InetPub\scripts. Note that this is specific for the Intel version (the Alpha version of this would get the new DLL from the JRun\connectors\isapi\alpha-win). -- chris -- > -Original Message- > From: A mailing list about Java Server Pages specification and reference > [mailto:[EMAIL PROTECTED]]On Behalf Of Robert Glover > Sent: Friday, June 25, 1999 2:59 PM > To: [EMAIL PROTECTED] > Subject: Severe bug JRUN 2.3.2 build 151 (IIS 4.0) > > > Note: This Severe bug has only been verified to > occur on the MS IIS 4.0 server. It does NOT occur > when using the native JRUN Web server via port 8000. >Using JSP 1.0 support in build 151 of JRUN 2.3.2, > the following causes a "SAVE AS" dialog box to > pop up in the browser: > > "". > Note however that the following works fine: > "" > > Similarly, the following does not work: > will not work > but the following DOES work: > will work > >Apparantly no one has noticed this bug yet because > build 151 is so recent. >If anyone knows a fix, please, please email me. > Tx. > > > _ > Do You Yahoo!? > Get your free @yahoo.com address at http://mail.yahoo.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". > === 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: JRUN build 151 Serious Error with IIS 4.0
This is supposedly fixed in Build 152. > -Original Message- > From: A mailing list about Java Server Pages specification and reference > [mailto:[EMAIL PROTECTED]]On Behalf Of Kevin Jones > Sent: Monday, June 28, 1999 10:28 AM > To: [EMAIL PROTECTED] > Subject: Re: JRUN build 151 Serious Error with IIS 4.0 > > > Hmm - if I use fully qualified names I don't get this problem > > so http://localhost/loc/somejsp.jsp is fine but just somejsp.jsp fails, > > I get odd results for "POST" as well if I don't supply a full URL > > Kevin > > -Original Message- > From: A mailing list about Java Server Pages specification and reference > [mailto:[EMAIL PROTECTED]]On Behalf Of John Malloy > Sent: 28 June 1999 15:29 > To: [EMAIL PROTECTED] > Subject: JRUN build 151 Serious Error with IIS 4.0 > > > I upgraded from a JRUN that used JSP .92, up to the > latest JRUN (build 151) that supports JSP 1.0. >Now, the following no longer works although it > worked with the older JRUN: > > > >Using the new JRUN (and IIS 4.0) this causes a > "SAVE AS" dialog box to appear in the client > browser. >Another way to recreate this problem is to > type this URL: http://localhost/foo.jsp?bar=x >Note that either of these would work perfectly > using the builtin JRUN server, i.e., > "http://localhost:8000/..some path../foo.jsp?bar=x >I've recreated this problem on two different > Win NT 4.0 computers using IIS 4.0. > I have not seen anyone else report this, but > I am convinced it is a true bug and will bite others > as more convert to JRUN with JSP 1.0 support. I > called JRUN but have not had my phone call returned. >Please, could someone else using IIS 4.0 and JRUN > build 151 try to recreate this and report back to us? > Thank you. > > _ > Do You Yahoo!? > Get your free @yahoo.com address at http://mail.yahoo.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". > > == > = > 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 include question
I have found that URL encoding parameters to the JSP URL will hose up the JSP mapping with IIS. Basically IIS does not see the URL as a JSP URL and will not pass the URL to JRun. I haven't tested this extensively, but I hit upon this yesterday myself. Definitely something that needs to be addressed. If someone has some other information pertaining to URL encoded query strings and making this work with JRun, please speak up. -- chris -- > -Original Message- > From: A mailing list about Java Server Pages specification and reference > [mailto:[EMAIL PROTECTED]]On Behalf Of Wine Vaughn > Sent: Thursday, July 01, 1999 12:40 PM > To: [EMAIL PROTECTED] > Subject: JSP include question > > > My question is about how works (with JSP 1.0). > (I'm using > JRun 2.3.2 on NT w/IIS.) Here's my scenario: I've got three JSPs. > Main.jsp includes either A.jsp or B.jsp, depending on some information > retrieved from our back end. So Main.jsp has some code in it that looks > like this: > > /> > > Now, this works okay and as expected. However, I want to do more > than this. > I want to send particular parameters to each include JSP, like this: > > + "?param1=value1¶m2=value2" %> > /> > > Unfortunately, this does work. Everything compiles, but at runtime the > included JSP cannot retrieve these parameters. Is this because > I'm reusing > the original request? > > Is there some other way to accomplish this? Basically, I need a > way to pass > dynamic information to an included JSP. > > Do you have some insight on this? I couldn't figure out if this > is illegal > or not from reading the specs and JavaDocs > > > Vaughn Wine > > == > = > 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 & Regular Expressions
I've used ORO, Inc.'s (now defunct, but Daniel Savarese is still maintaining the products) PerlTools extensively in servlets. Check it out at http://www.savarese.org. Also mentionable is their NetComponents package. -- chris -- > -Original Message- > From: A mailing list about Java Server Pages specification and reference > [mailto:[EMAIL PROTECTED]]On Behalf Of Lance Lavandowska > Sent: Tuesday, June 08, 1999 3:47 PM > To: [EMAIL PROTECTED] > Subject: Re: JSP & Regular Expressions > > > try http://javaregex.com > > its a nice little package, more powerful than it may at first appear. > > Lance Lavandowska > Software Engineer > http://www.AgDomain.Com > -Original Message- > From: Lukin Konstantin <[EMAIL PROTECTED]> > To: [EMAIL PROTECTED] <[EMAIL PROTECTED]> > Date: Tuesday, June 08, 1999 3:21 PM > Subject: JSP & Regular Expressions > > > >Hey all > > > >Has anybody tried to use perl with JSP? > >Wouldn't it be cool to use regular expressions in > >servlets!?! > > > >Thanks > > > >- Kostik > > > >= > == > >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". > === 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".
JavaOne BOFs (was RE: JavaOne JSP Attendees)
The only reservation I have about BOFs at JavaOne is the event planners usually schedule the BOF in a small conference room. The BOFs are very popular and well attended, since they usually contain a wealth of information. Due to their popularity, overflows of attendees into the corridor result. This was a common problem at JavaOne '98 and it will be interesting to see how the conference planners deal with this problem this year. I think the BOF idea is a good one, I just hope that the conference planners cooperate with us on the facilities end of it. Chris Bartling Analytical Solutions, Inc. > -Original Message- > From: A mailing list about Java Server Pages specification and reference > [mailto:[EMAIL PROTECTED]]On Behalf Of Brian Burridge > Sent: Monday, April 26, 1999 7:53 AM > To: [EMAIL PROTECTED] > Subject: Re: JavaOne JSP Attendees > > > It sounds good to me. I'm interested to hear what others have to > say. Are there > any downsides to this? Will we be more restricted from open > discussion? I've > never sat in on a BOF so I don't know how they go. > > Brian N. Burridge > Web Specialist > Cox Target Media > http://www.burridge.net/jsp > > Jason Hunter wrote: > > > Brian Burridge wrote: > > > > > > I have posted a list of all those that have sent me name, email, > > > company, etc. If you want to be added to the list, please send me > > > email. > > > Once the list is a little bigger I will try to direct it to someone at > > > Sun, unless someone from Sun's JSP development group is watching this > > > list anyway. > > > > > > http://www.burridge.net/jsp/javaone.html > > > > > > Brian N. Burridge > > > Web Specialist > > > Cox Target Media > > > http://www.burridge.net/jsp > > > > I just received confirmation that I'll be heading up two official BOF > > sessions at JavaOne this year. I'd like to devote one primarily to > > servlets, and one primarily to JSP. If you'd like, we can make this > > proposed unofficial JSP gathering an official BOF, with benefits such > > as an actual room and advertizing outside this mailing list. > > > > I plean see if I can twist an arm or two in the JSP group at Sun. > > I'll encourage the presence of other vendors as well. > > > > Let me know. > > > > -jh- > > > > -- > > Jason Hunter > > [EMAIL PROTECTED] > > Book:http://www.servlets.com/book > > Article: http://www.javaworld.com/jw-12-1998/jw-12-servletapi.html > > > > > == > = > > 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". > === 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".
