[JBoss JIRA] Created: (JBAS-4616) NamingContext lookupLink() does not acquire stub to server Naming service
by Brian Stansberry (JIRA)
NamingContext lookupLink() does not acquire stub to server Naming service
-------------------------------------------------------------------------
Key: JBAS-4616
URL: http://jira.jboss.com/jira/browse/JBAS-4616
Project: JBoss Application Server
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Naming
Affects Versions: JBossAS-4.2.1.GA, JBossAS-4.2.0.GA, JBossAS-5.0.0.Beta2, JBossAS-4.0.5.GA
Reporter: Brian Stansberry
Assigned To: Brian Stansberry
Fix For: JBossAS-5.0.0.Beta3
org.jnp.interfaces.NamingContext.lookupLink(Name) does not invoke the checkRef() method before invoking on the stub to the server-side Naming object. The checkRef() method is what actually contacts the JNDI server to download the stub.. Result of this is an NPE will be thrown if an earlier call hasn't downloaded the stub before lookupLink() is called.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
16 years, 5 months
[JBoss JIRA] Created: (JBWEB-87) JasperException for JSP page using generics
by David Ward (JIRA)
JasperException for JSP page using generics
-------------------------------------------
Key: JBWEB-87
URL: http://jira.jboss.com/jira/browse/JBWEB-87
Project: JBoss Web
Issue Type: Bug
Security Level: Public (Everyone can see)
Environment: Customer submitted using AS 4.2.0.GA and Sun JDK 1.5.0_11. I verified using AS 4.2.0.GA and AS 4.2.1.GA and Sun JDK 1.6.0_02.
Reporter: David Ward
Assigned To: Mladen Turk
I am submitting this as a JBoss Web bug; not sure if it should have been submitted as an AS bug instead...
This test.jsp page does not compile in AS 4.2.0 or AS 4.2.1:
<%@page contentType="text/html" import="java.util.*" %>
<html><head><title>test</title></head><body>
<%
Vector<String> v = (Vector<String>)request.getSession().getAttribute("v");
out.println("v: " + v);
%>
</body></html>
However, it does with a workaround (please see "Workaround Description" below).
I believe that this is a bug since we require a 1.5 JVM for AS 4.2.x.
Here is the error without using the workaround:
15:41:21,960 ERROR [[jsp]] Servlet.service() for servlet jsp threw exception
org.apache.jasper.JasperException: Unable to compile class for JSP:
An error occurred at line: 4 in the jsp file: /test.jsp
The type Vector is not generic; it cannot be parameterized with arguments <String>
1: <%@page contentType="text/html" import="java.util.*" %>
2: <html><head><title>test</title></head><body>
3: <%
4: Vector<String> v = (Vector<String>)request.getSession().getAttribute("v");
5: out.println("v: " + v);
6: %>
7: </body></html>
An error occurred at line: 4 in the jsp file: /test.jsp
Syntax error, parameterized types are only available if source level is 5.0
1: <%@page contentType="text/html" import="java.util.*" %>
2: <html><head><title>test</title></head><body>
3: <%
4: Vector<String> v = (Vector<String>)request.getSession().getAttribute("v");
5: out.println("v: " + v);
6: %>
7: </body></html>
An error occurred at line: 4 in the jsp file: /test.jsp
The type Vector is not generic; it cannot be parameterized with arguments <String>
1: <%@page contentType="text/html" import="java.util.*" %>
2: <html><head><title>test</title></head><body>
3: <%
4: Vector<String> v = (Vector<String>)request.getSession().getAttribute("v");
5: out.println("v: " + v);
6: %>
7: </body></html>
An error occurred at line: 4 in the jsp file: /test.jsp
Syntax error, parameterized types are only available if source level is 5.0
1: <%@page contentType="text/html" import="java.util.*" %>
2: <html><head><title>test</title></head><body>
3: <%
4: Vector<String> v = (Vector<String>)request.getSession().getAttribute("v");
5: out.println("v: " + v);
6: %>
7: </body></html>
Stacktrace:
at org.apache.jasper.compiler.DefaultErrorHandler.javacError(DefaultErrorHandler.java:92)
at org.apache.jasper.compiler.ErrorDispatcher.javacError(ErrorDispatcher.java:330)
at org.apache.jasper.compiler.JDTCompiler.generateClass(JDTCompiler.java:415)
at org.apache.jasper.compiler.Compiler.compile(Compiler.java:308)
at org.apache.jasper.compiler.Compiler.compile(Compiler.java:286)
at org.apache.jasper.compiler.Compiler.compile(Compiler.java:273)
at org.apache.jasper.JspCompilationContext.compile(JspCompilationContext.java:566)
at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:311)
at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:320)
at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:266)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:803)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:230)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175)
at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:179)
at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:84)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:104)
at org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:157)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:241)
at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:844)
at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:580)
at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447)
at java.lang.Thread.run(Thread.java:619)
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
16 years, 5 months
[JBoss JIRA] Created: (JBAS-4282) Can't create a root context web app
by Stan Silvert (JIRA)
Can't create a root context web app
-----------------------------------
Key: JBAS-4282
URL: http://jira.jboss.com/jira/browse/JBAS-4282
Project: JBoss Application Server
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Web (Tomcat) service
Affects Versions: JBossAS-5.0.0.Beta2
Reporter: Stan Silvert
Assigned To: Remy Maucherat
I am unable to deploy a web app as root context using the instructions here:
http://wiki.jboss.org/wiki/Wiki.jsp?page=SetupARootContextApp
One thing that is unclear is if ROOT.war "must" be removed from /deploy. In 4.2, root context web apps do not require removal of ROOT.war. IMHO, this is how it should work. If you deploy a WAR as the root context, it should simply override whatever was there before.
If ROOT.war is removed, 5.0 will allow a root context web app as long as it is deployed from an EAR and specified as such in application.xml. Otherwise, it will fail.
If you choose to deploy a stand-alone WAR and specify it as root context using jboss-web.xml, it will always fail - regardless of whether or not you remove ROOT.war.
I have committed a test for root deployment in both 4.2 and 5.0. The test passes in 4.2, but not in 5.0. You can run it with:
build one-test -Dtest=org.jboss.test.web.test.RootContextUnitTestCase
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
16 years, 5 months
[JBoss JIRA] Created: (JGRP-494) Investigate marshalling format to simplify wireshark / ethereal plugin
by Bela Ban (JIRA)
Investigate marshalling format to simplify wireshark / ethereal plugin
-----------------------------------------------------------------------
Key: JGRP-494
URL: http://jira.jboss.com/jira/browse/JGRP-494
Project: JGroups
Issue Type: Feature Request
Reporter: Bela Ban
Assigned To: Bela Ban
Fix For: 2.5
Currently, parsing JGroups network data via wireshark is difficult:
- message lists don't have (a) total number of bytes and (b) bytes/message and
- headers don't have (a) total bytes for all headers and (b) bytes / header
Investigate whether we can change the marshalling format to accommodate the wireshark plugin. This has the nice side effect that the JGroups wire format becomes standardized, ie. each header has the same format. This allows us to display a header even if we don't know how to parse it. In this case, we'd simply display the name and number of bytes.
Caveat: we want to avoid having to make messages bigger when marshalled.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
16 years, 5 months