Re: [Solr Wiki] Update of "TaskList" by HossMan

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: [Solr Wiki] Update of "TaskList" by HossMan

Yonik Seeley-2
On 8/27/06, Apache Wiki <[hidden email]> wrote:
> +   * refactor all of the JSP pages into servlets so a JDK/JSP compiler isn't needed (the current JSPs are very sparse on presentation, and use no custom tags, so there is almost no advantage to them being JSPs)

It seems like a simpler option would be to just move to Tomcat 5.5 or
Jetty 6, both of which handle JSPs file with a JRE.

-Yonik
Reply | Threaded
Open this post in threaded view
|

Re: [Solr Wiki] Update of "TaskList" by HossMan

Chris Hostetter-3
: > + * refactor all of the JSP pages into servlets so a JDK/JSP compiler

: It seems like a simpler option would be to just move to Tomcat 5.5 or
: Jetty 6, both of which handle JSPs file with a JRE.

that solves confusion people have when running the example out of the box,
but doesn't help situations where people try using Solr in their own
Servlet Container.   I just wanted to through the idea out there since we
don't really gain that much with the current JSPs, but it has caused us
some annoyance.

(an added bonus is the entire webapp would be compiled at build time, so
there would be less risk of commiting changes to src/java that seemed
simple but actually cause compile failures in the webapp)



-Hoss

Reply | Threaded
Open this post in threaded view
|

Re: [Solr Wiki] Update of "TaskList" by HossMan

Bill Au
Leaving them as JSPs would make it easier to customize the admin pages.

Bill

On 8/28/06, Chris Hostetter <[hidden email]> wrote:

>
> : > + * refactor all of the JSP pages into servlets so a JDK/JSP compiler
>
> : It seems like a simpler option would be to just move to Tomcat 5.5 or
> : Jetty 6, both of which handle JSPs file with a JRE.
>
> that solves confusion people have when running the example out of the box,
> but doesn't help situations where people try using Solr in their own
> Servlet Container.   I just wanted to through the idea out there since we
> don't really gain that much with the current JSPs, but it has caused us
> some annoyance.
>
> (an added bonus is the entire webapp would be compiled at build time, so
> there would be less risk of commiting changes to src/java that seemed
> simple but actually cause compile failures in the webapp)
>
>
>
> -Hoss
>
>
Reply | Threaded
Open this post in threaded view
|

Re: [Solr Wiki] Update of "TaskList" by HossMan

Chris Hostetter-3

: Leaving them as JSPs would make it easier to customize the admin pages.

It depends on the customization.  CSS is still easy to do with servlet
output.  if you look at the JSPs right now, the most complicated HTML I
found is actually being created inside of scriptlet blocks that would be
*easier* to macke sense of in a Servlet.

:
: Bill
:
: On 8/28/06, Chris Hostetter <[hidden email]> wrote:
: >
: > : > + * refactor all of the JSP pages into servlets so a JDK/JSP compiler
: >
: > : It seems like a simpler option would be to just move to Tomcat 5.5 or
: > : Jetty 6, both of which handle JSPs file with a JRE.
: >
: > that solves confusion people have when running the example out of the box,
: > but doesn't help situations where people try using Solr in their own
: > Servlet Container.   I just wanted to through the idea out there since we
: > don't really gain that much with the current JSPs, but it has caused us
: > some annoyance.
: >
: > (an added bonus is the entire webapp would be compiled at build time, so
: > there would be less risk of commiting changes to src/java that seemed
: > simple but actually cause compile failures in the webapp)
: >
: >
: >
: > -Hoss
: >
: >
:



-Hoss

Reply | Threaded
Open this post in threaded view
|

Re: [Solr Wiki] Update of "TaskList" by HossMan

Bill Au
Yes, it depends on the customization.  What I had in mind was not just
formating changes, but adding additional content to the pages or adding a
new page.  With servlets it can still be done.  But then it will require
building Solr from source.  A little more involved.

Bill

On 8/29/06, Chris Hostetter <[hidden email]> wrote:

>
>
> : Leaving them as JSPs would make it easier to customize the admin pages.
>
> It depends on the customization.  CSS is still easy to do with servlet
> output.  if you look at the JSPs right now, the most complicated HTML I
> found is actually being created inside of scriptlet blocks that would be
> *easier* to macke sense of in a Servlet.
>
> :
> : Bill
> :
> : On 8/28/06, Chris Hostetter <[hidden email]> wrote:
> : >
> : > : > + * refactor all of the JSP pages into servlets so a JDK/JSP
> compiler
> : >
> : > : It seems like a simpler option would be to just move to Tomcat 5.5or
> : > : Jetty 6, both of which handle JSPs file with a JRE.
> : >
> : > that solves confusion people have when running the example out of the
> box,
> : > but doesn't help situations where people try using Solr in their own
> : > Servlet Container.   I just wanted to through the idea out there since
> we
> : > don't really gain that much with the current JSPs, but it has caused
> us
> : > some annoyance.
> : >
> : > (an added bonus is the entire webapp would be compiled at build time,
> so
> : > there would be less risk of commiting changes to src/java that seemed
> : > simple but actually cause compile failures in the webapp)
> : >
> : >
> : >
> : > -Hoss
> : >
> : >
> :
>
>
>
> -Hoss
>
>
Reply | Threaded
Open this post in threaded view
|

Re: [Solr Wiki] Update of "TaskList" by HossMan

Chris Hostetter-3

: Yes, it depends on the customization.  What I had in mind was not just
: formating changes, but adding additional content to the pages or adding a
: new page.  With servlets it can still be done.  But then it will require
: building Solr from source.  A little more involved.

are you talking about clients adding their own modifcations to the pages
(or new pages) when they install Solr? ... that would require unpacking
the WAR and at that point we might as well ask them to recompile --
letting people specify a flat HTML file to include on the admin page is
one thing, but if people want custom code in the admin pages expectingthem
to recompile doesn't seem like much of a stretch.

:
: Bill
:
: On 8/29/06, Chris Hostetter <[hidden email]> wrote:
: >
: >
: > : Leaving them as JSPs would make it easier to customize the admin pages.
: >
: > It depends on the customization.  CSS is still easy to do with servlet
: > output.  if you look at the JSPs right now, the most complicated HTML I
: > found is actually being created inside of scriptlet blocks that would be
: > *easier* to macke sense of in a Servlet.
: >
: > :
: > : Bill
: > :
: > : On 8/28/06, Chris Hostetter <[hidden email]> wrote:
: > : >
: > : > : > + * refactor all of the JSP pages into servlets so a JDK/JSP
: > compiler
: > : >
: > : > : It seems like a simpler option would be to just move to Tomcat 5.5or
: > : > : Jetty 6, both of which handle JSPs file with a JRE.
: > : >
: > : > that solves confusion people have when running the example out of the
: > box,
: > : > but doesn't help situations where people try using Solr in their own
: > : > Servlet Container.   I just wanted to through the idea out there since
: > we
: > : > don't really gain that much with the current JSPs, but it has caused
: > us
: > : > some annoyance.
: > : >
: > : > (an added bonus is the entire webapp would be compiled at build time,
: > so
: > : > there would be less risk of commiting changes to src/java that seemed
: > : > simple but actually cause compile failures in the webapp)
: > : >
: > : >
: > : >
: > : > -Hoss
: > : >
: > : >
: > :
: >
: >
: >
: > -Hoss
: >
: >
:



-Hoss