using CSS in JSP
Benjamin Geer
Sheets in JSP pages in a web application under Weblogic 5.1. If I use a
<link rel...> to reference the stylesheet, the contents of the CSS
intermittently appear as ordinary text in the browser (using Netscape
4.73). Reloading the page sometimes causes the CSS file to work
correctly.
So far I haven't found a way to get CSS to work reliably with WebLogic.
Has anyone else had and/or solved this problem?
Benjamin Geer
Pentacom Communications, Ltd.
Goran Knutas
I an error message when i try to include .css-files or .js-files
in the html-page;
<link rel="stylesheet" type="text/css" href="gbs.css">
<script language="javascript" src="functions.js"></script>
though the file is included and it works....it is rather anoing with the
error message....
I have deployed a web-application as a directory structure on WLS 5.1 (no
service pack)
just the WLS being to talkative ??
/goran
err. message:
fr jun 09 16:31:37 GMT+02:00 2000:<E> <ServletContext-ContextRootGBS>
Servlet failed with
Exception
java.net.SocketException: socket write error (code=10053)
at java.net.SocketOutputStream.socketWrite(Native Method)
at java.net.SocketOutputStream.write(SocketOutputStream.java,
Compiled Code)
at weblogic.servlet.internal.ChunkUtils.writeChunks(ChunkUtils.java,
Compiled Code
)
at
weblogic.servlet.internal.ServletOutputStreamImpl.flush(ServletOutputStreamI
mpl
.java, Compiled Code)
at
weblogic.servlet.internal.ServletOutputStreamImpl.writeStream(ServletOutputS
tre
amImpl.java, Compiled Code)
at weblogic.servlet.FileServlet.sendFile(FileServlet.java:199)
at weblogic.servlet.FileServlet.service(FileServlet.java:56)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:865)
at
weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java
, C
ompiled Code)
at
weblogic.servlet.internal.ServletContextImpl.invokeServlet(ServletContextImp
l.j
ava:742)
at
weblogic.servlet.internal.ServletContextImpl.invokeServlet(ServletContextImp
l.j
ava:686)
at
weblogic.servlet.internal.ServletContextManager.invokeServlet(ServletContext
Man
ager.java:247)
at
weblogic.socket.MuxableSocketHTTP.invokeServlet(MuxableSocketHTTP.java:361)
at
weblogic.socket.MuxableSocketHTTP.execute(MuxableSocketHTTP.java:261)
at weblogic.kernel.ExecuteThread.run(ExecuteThread.java, Compiled
Code)
Benjamin Geer <benj...@pentacom.co.uk> skrev i
diskussionsgruppsmeddelandet:3944DC62...@pentacom.co.uk...
Mark Griffith
reproducible test case with instructions.
mbg
In article <8i50qj$6d1$1...@newsgroups.bea.com>, goran....@environ.se
says...
--
==================================================
NewsGroup Rant
==================================================
Rant 1.
The less info you provide about your problem means
the less we can help you. Try to look at the
problem from an external perspective and provide
all the data necessary to put your problem in
perspective.
Goran Knutas
just put the csstest files/dir in the public_html catalog,
the error seems to come from the .js include file.
BUT if I change the .js file a litle bit, by removing any of the javasript
functions (one or two of them) the socket write error disapears....hmm...
its totaly weird...
anything to do with conent length ??
Mark Griffith <ma...@bea.com> skrev i
diskussionsgruppsmeddelandet:MPG.13b0be34d...@newsgroups.bea.com..
.
begin 600 Csstest.zip
<encoded_portion_removed>
John Van Pelt
were working fine when they were inline in both the JSP and HTML pages - I
moved them all out to link relationships and I'm getting the behavior
Benjamin describes.
It is as if the webserver is not properly interpreting LINK in the page
<HEAD>. This appears to be the case even when there is no .jsp calls (i.e.
straight HTML).
-John Van Pelt
(I would post this in .interest.jsp except that this existing thread was
more relevant)
John Van Pelt
The two stylesheet files (*.css) were in the site root /public-html. As such
they came under the access verification controlled by a verify.jsp and beans to
check a cookie and look up our member database. The .css files needed to listed
in weblogic.properties along with several other publicDirectories. Once we did
this all pages loaded with the proper styles.
For the heck of it, I also made sure the MIME types were listed in
weblogic.properties:
weblogic.httpd.mimeType.text/css=css
although I don't know if this made any difference.
-John VP
uli stehling
I am having the same problem and am very keen on trying your solution -
unfortunately i do not understand it: how do you list the .css files in
the weblogic properties? Do you enter them as document roots?? Can you
post an example please?
TIA, regards
uli
Paul Ackley
I too am having the same problem and did not understand the solution. I hope that some one can elaborate on the solution.
Thanks!
Paul Ackley (Qwest Communications)
Jong Lee
Can any one of you post a simple test case here please?
A problem is reported. I could not successfully reproduce the problem based on the reported test case.
I provided a work-around on sp5. If it did not work out, I will look at it once again.
If you don't want to post here, please send it to me via email.
thanks
Jong
Jesus M. Salvo Jr.
<jsp:include/> not being interpreted properly by WLS. When I changed it
to <%@include %>, the problem seem to have disappeared.
It also does not matter if its deployed in a WAR or not.
That was with WLS 5.1 + SP5. Haven't tried moving back to <jsp:include/>
with SP6.
I'll try it today and see if I can still replicate it. If I can, than
I'll post a test case.
John
--
Jesus M. Salvo, Jr.
Senior Consultant
PowerServe Pty Ltd
Level 2, 116 Miller Street
North Sydney 2060
New South Wales, Australia
Ph: (61-2) 9492 4800
Direct (61-2) 9492 4853
Fax: (61-2) 9492 4899
http://www.powerserve.com.au
Email: jsa...@powerserve.com.au
This email is from PowerServe Pty Limited (ACN 069 037 056)
The information contained in this email (including any attached files)
may be privileged and confidential intended for the use of the
person/persons named above. If you are not the intended recipient, you
are advised that any use, distribution or copying of the information is
strictly prohibited. If you have received this transmission in error,
please notify PowerServe Pty Limited immediately on (61 3) 9618 1222 or
reply by email to the sender.
PowerServe Pty Limited does not represent or warrant that this email or
any attached files are free from computer viruses or other defects. Any
attached files are provided, and may only be used, on the basis that the
user assumes all responsibility for
Jesus M. Salvo Jr.
Just tried it with SP6. It seems to have been fixed.
John
"Jesus M. Salvo Jr." wrote:
>
> For BEA, here's the test case.
>
> I just add the .war file into weblogic.properties like this:
>
> weblogic.httpd.webApp.testcase=/home/weblogic/product/wls/5.1/weblogic/myserver/jspincludebug.war
>
> ... and access it like this:
>
> http://localhost:7001/testcase
>
> ... and you'll have three JSP samples. The first 2 are samples
> demonstrates the bug with <jsp:include/>, with and without an external
> stylesheet. When you view those 2 using your browser, look at the source
> from your browser's "View HTML source", and youll notice that the
> <jsp:include/> tag is sent to the browser.
>
> The last JSP is how it should look like, but this is using <%@include %>
>
> Note that I believe that the problem is really with the jsp:include tag
>
> Linux:
>
> WLS 5.1 + SP5 / SP6
> Blackdown JDK 1.2.2-FCS
> glibc-2.1.3
> kernel 2.2.17
>
> Solaris:
>
> WLS 5.1 + SP5
> Solaris 2.7 (with all the JDK patches installed )
> JDK1.2.2_005a
> WLS 5.1 + SP5
>
> Let us know the results. I'll post this as well to the JSP forum, since
> that is where this topic should be in anycase.
>
> John Salvo
> ------------------------------------------------------------------------
> Name: jspincludebug.war
> jspincludebug.war Type: unspecified type (application/octet-stream)
> Encoding: base64
Jong Lee
I tested your test case with the latest patch line. Everything seems to be expected.
Jong