[JBoss JIRA] Created: (JBAS-3417) SocketException during minimal tests
by Jaroslaw Kijanowski (JIRA)
SocketException during minimal tests
------------------------------------
Key: JBAS-3417
URL: http://jira.jboss.com/jira/browse/JBAS-3417
Project: JBoss Application Server
Issue Type: Bug
Security Level: Public (Everyone can see)
Affects Versions: JBossAS-5.0.0.Beta
Environment: win xp, fedora core 5
Reporter: Jaroslaw Kijanowski
while running the first test of the testsuite (jboss-minimal-tests), get a java.net.SocketException.
server.log:
2006-07-22 17:05:55,046 DEBUG [org.jboss.deployment.MainDeployer] End deployment start on package: jboss-service.xml
2006-07-22 17:05:55,046 DEBUG [org.jboss.deployment.MainDeployer] Deployed package: file:/D:/jboss3/jboss-head/build/output/jboss-5.0.0.Beta/server/minimal/conf/jboss-service.xml
2006-07-22 17:05:55,046 INFO [org.jboss.system.server.Server] JBoss (MX MicroKernel) [5.0.0.Beta (build: CVSTag=HEAD date=200607220701)] Started in 3s:359ms
2006-07-22 17:05:55,281 DEBUG [org.jboss.naming.NamingService] Error writing response to /127.0.0.1
java.net.SocketException: Software caused connection abort: socket write error
at java.net.SocketOutputStream.socketWrite0(Native Method)
at java.net.SocketOutputStream.socketWrite(SocketOutputStream.java:92)
at java.net.SocketOutputStream.write(SocketOutputStream.java:136)
at java.io.ObjectOutputStream$BlockDataOutputStream.drain(ObjectOutputStream.java:1676)
at java.io.ObjectOutputStream$BlockDataOutputStream.setBlockDataMode(ObjectOutputStream.java:1585)
at java.io.ObjectOutputStream.writeNonProxyDesc(ObjectOutputStream.java:1167)
at java.io.ObjectOutputStream.writeClassDesc(ObjectOutputStream.java:1121)
at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1278)
at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1073)
at java.io.ObjectOutputStream.writeFatalException(ObjectOutputStream.java:1392)
at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:294)
at org.jnp.server.Main$BootstrapRequestHandler.run(Main.java:476)
at org.jboss.util.threadpool.RunnableTaskWrapper.run(Unknown Source)
at EDU.oswego.cs.dl.util.concurrent.PooledExecutor$Worker.run(PooledExecutor.java:743)
at java.lang.Thread.run(Thread.java:595)
--
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
14 years, 3 months
[JBoss JIRA] Created: (JBPORTAL-1287) enabling prepare-statement-cache throws error during startup
by Prabhat Jha (JIRA)
enabling prepare-statement-cache throws error during startup
------------------------------------------------------------
Key: JBPORTAL-1287
URL: http://jira.jboss.com/jira/browse/JBPORTAL-1287
Project: JBoss Portal
Issue Type: Bug
Security Level: Public (Everyone can see)
Affects Versions: 2.6.Alpha2
Environment: QA: jboss running on cluster01, mysql5 running on cluster08, jdk1.4, jboss-portal.sar as of 2007 Feb, 21.
Reporter: Prabhat Jha
This happens on my end when prepared-statement-cache is on. Here is my portal-mysql5-ds.xml:
<datasources>
<local-tx-datasource>
<jndi-name>PortalDS</jndi-name>
<connection-url>jdbc:mysql://10.16.0.103:3306/portal?jdbcCompliantTruncation=false</connection-url>
<driver-class>com.mysql.jdbc.Driver</driver-class>
<user-name>portal</user-name>
<password></password>
<min-pool-size>20</min-pool-size>
<max-pool-size>40</max-pool-size>
<prepared-statement-cache-size>100</prepared-statement-cache-size>
</local-tx-datasource>
</datasources>
Once I comment out the prepared-statement-cache-size, then it starts fine.
Given that Julien has not been able to reproduced on his end, he probably needs to have access to this environment or I have to see if I can reproduce in his environment.
--
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
14 years, 3 months
[JBoss JIRA] Created: (JBAS-4022) EJB security-domain tag in jboss.xml for a domain defined in login-config.xml only works if java:/jaas/ prefix is absent, contrary to the documentation.
by Erica Kane (JIRA)
EJB security-domain tag in jboss.xml for a domain defined in login-config.xml only works if java:/jaas/ prefix is absent, contrary to the documentation.
--------------------------------------------------------------------------------------------------------------------------------------------------------
Key: JBAS-4022
URL: http://jira.jboss.com/jira/browse/JBAS-4022
Project: JBoss Application Server
Issue Type: Bug
Security Level: Public (Everyone can see)
Affects Versions: JBossAS-4.0.4.GA
Environment: Clustered
Reporter: Erica Kane
I created a security domain in the the JBoss server login-config.xml:
<application-policy name = "webappDomain">
<authentication>
<login-module code = "org.jboss.security.auth.spi.DatabaseServerLoginModule"
flag = "required">
<module-option name = "dsJndiName">java:jdbc/web</module-option>
<module-option name = "principalsQuery">select password from Users where username=?</module-option>
<module-option name = "rolesQuery">select Role, 'Roles' from Roles where username=?</module-option>
<module-option name = "unauthenticatedIdentity">guest</module-option>
</login-module>
</authentication>
</application-policy>
In jboss-web.xml, I have
<?xml version="1.0" encoding="UTF-8"?>
<jboss-web>
<security-domain flushOnSessionInvalidation="true">java:/jaas/webappDomain</security-domain>
<context-root>/web</context-root>
</jboss-web>
and this works perfectly for securing web pages. However, if I put the following tag in jboss.xml:
<security-domain>java:/jaas/webappDomain</security-domain>
I find that protected EJBs default to using the "other" security domain, as shown by error messages complaining about the missing user.properties file and so on (I have left "other" on the default setting of UsersRolesLoginModule).
What DOES work is to put:
<security-domain>webappDomain</security-domain>
in jboss.xml without the java:/jaas/ prefix. However, this does not match the documentation. See
http://docs.jboss.org/jbossas/jboss4guide/r4/html/ch8.chapter.html
example 8.8. Of course there the tag is set to java:/jaas/other, which for this bug would default to "other" anyway.
I think it is terribly confusing to have jboss.xml and jboss-web.xml using different forms for the security-domain, but even if this is necessary for some reason it should be corrected in the documentation. Other people appear to have run into this as well:
http://forum.java.sun.com/thread.jspa?threadID=773530
--
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
14 years, 4 months
[JBoss JIRA] Created: (JBAS-3942) twiddle.sh should read run.conf - and other small ehancements
by Paul Jenner (JIRA)
twiddle.sh should read run.conf - and other small ehancements
-------------------------------------------------------------
Key: JBAS-3942
URL: http://jira.jboss.com/jira/browse/JBAS-3942
Project: JBoss Application Server
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Components: Other
Affects Versions: JBossAS-4.0.5.GA
Reporter: Paul Jenner
The twiddle.sh script should read environment variables from run.conf in the same way as the startup and shutdown scripts do - e.g. JAVA_HOME and JAVA.
Additionally twiddle.sh should honous the JAVA environment variable instead of overwriting it with $JAVA_HOME/bin/java or "java". This makes it consistent with startup and shutdown which do honour JAVA.
Finally the header should be changed from JBoss Shutdown script to JBoss twiddle script :-)
--
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
14 years, 4 months
[JBoss JIRA] Created: (JBAS-3773) Empty baseCtxDN and rolesCtxDN adds a comma to the userDn and user roles
by Eric van Lydegraf (JIRA)
Empty baseCtxDN and rolesCtxDN adds a comma to the userDn and user roles
------------------------------------------------------------------------
Key: JBAS-3773
URL: http://jira.jboss.com/jira/browse/JBAS-3773
Project: JBoss Application Server
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Security
Affects Versions: JBossAS-4.0.5.CR1
Reporter: Eric van Lydegraf
Assigned To: Scott M Stark
The LDAP server (Lotus Domino) has users organized along different CtxDN contexts, so for JNDI empty contexts are used and the filter sorts out the users and groups.
When Using LoginExtLoginModule, a sucessful retrieval of a User, has a full userDN but the code will append a comma expecting BaseCtxDN used in the search.
The same is true for group membership.
The solution I came up with is if the context is empty, no Ctx is appended and only the search result is preserved.
--
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
14 years, 5 months
[JBoss JIRA] Created: (JBAS-4005) Error reading web.xml with external entities when taglib is used
by Angela Roberts (JIRA)
Error reading web.xml with external entities when taglib is used
----------------------------------------------------------------
Key: JBAS-4005
URL: http://jira.jboss.com/jira/browse/JBAS-4005
Project: JBoss Application Server
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Web (Tomcat) service
Affects Versions: JBossAS-4.0.5.GA
Environment: MacOsX, JBossAS-4.0.5
Reporter: Angela Roberts
Assigned To: Remy Maucherat
See the sample application attached.
It contains a web.xml that uses an external entity:
<?xml version="1.0" encoding="ISO-8859-1"?>
<!DOCTYPE web-app [ <!ENTITY inc SYSTEM "web-include.xml">]>
<web-app xmlns="http://java.sun.com/xml/ns/j2ee"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd"
version="2.4">
&inc;
</web-app>
When the first JSP of this application is called, if this JSP declares a taglib, JBoss can't find the included xml file.
This is the stack trace:
18:36:57,289 ERROR [MyEntityResolver] Invalid PUBLIC ID: null
18:36:57,351 ERROR [MyEntityResolver] Invalid PUBLIC ID: null
18:36:57,358 ERROR [[jsp]] Servlet.service() for servlet jsp threw exception
java.io.FileNotFoundException: /Applications/jboss-4.0.5.GA/bin/web-include.xml
at org.jboss.net.protocol.file.FileURLConnection.connect(FileURLConnection.java:94)
at org.jboss.net.protocol.file.FileURLConnection.getInputStream(FileURLConnection.java:103)
at org.apache.xerces.impl.XMLEntityManager.setupCurrentEntity(Unknown Source)
at org.apache.xerces.impl.XMLEntityManager.startEntity(Unknown Source)
at org.apache.xerces.impl.XMLEntityManager.startEntity(Unknown Source)
at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanEntityReference(Unknown Source)
at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.dispatch(Unknown Source)
at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unknown Source)
at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source)
at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source)
at org.apache.xerces.parsers.XMLParser.parse(Unknown Source)
at org.apache.xerces.parsers.DOMParser.parse(Unknown Source)
at org.apache.xerces.jaxp.DocumentBuilderImpl.parse(Unknown Source)
at org.apache.jasper.xmlparser.ParserUtils.parseXMLDocument(ParserUtils.java:95)
at org.apache.jasper.xmlparser.ParserUtils.parseXMLDocument(ParserUtils.java:132)
at org.jboss.web.tomcat.tc5.jasper.TagLibCache.processWebDotXml(TagLibCache.java:162)
at org.jboss.web.tomcat.tc5.jasper.TagLibCache.init(TagLibCache.java:99)
at org.jboss.web.tomcat.tc5.jasper.TagLibCache.getLocation(TagLibCache.java:83)
at org.apache.jasper.JspCompilationContext.getTldLocation(JspCompilationContext.java:526)
at org.apache.jasper.compiler.Parser.parseTaglibDirective(Parser.java:422)
at org.apache.jasper.compiler.Parser.parseDirective(Parser.java:492)
at org.apache.jasper.compiler.Parser.parseElements(Parser.java:1556)
at org.apache.jasper.compiler.Parser.parse(Parser.java:126)
at org.apache.jasper.compiler.ParserController.doParse(ParserController.java:211)
at org.apache.jasper.compiler.ParserController.parse(ParserController.java:100)
at org.apache.jasper.compiler.Compiler.generateJava(Compiler.java:155)
at org.apache.jasper.compiler.Compiler.compile(Compiler.java:295)
at org.apache.jasper.compiler.Compiler.compile(Compiler.java:276)
at org.apache.jasper.compiler.Compiler.compile(Compiler.java:264)
at org.apache.jasper.JspCompilationContext.compile(JspCompilationContext.java:563)
at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:305)
at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:314)
at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:264)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:810)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:178)
at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:175)
at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:74)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105)
at org.jboss.web.tomcat.tc5.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:156)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148)
at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:869)
at org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection(Http11BaseProtocol.java:664)
at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:527)
at org.apache.tomcat.util.net.MasterSlaveWorkerThread.run(MasterSlaveWorkerThread.java:112)
at java.lang.Thread.run(Thread.java:613)
The same application works ok on Tomcat 5.5.
I believe this is related to Bug http://issues.apache.org/bugzilla/show_bug.cgi?id=34034 . This bug is already fixed on Tomcat, but the way class org.jboss.web.tomcat.tc5.jasper.TagLibCache deals with entities may be the problem.
--
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
14 years, 5 months
[JBoss JIRA] Created: (JBAS-3841) Occasional NPE in org.apache.commons.modeler.Registry during startup
by Rolf Arne Corneliussen (JIRA)
Occasional NPE in org.apache.commons.modeler.Registry during startup
--------------------------------------------------------------------
Key: JBAS-3841
URL: http://jira.jboss.com/jira/browse/JBAS-3841
Project: JBoss Application Server
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Web (Tomcat) service
Affects Versions: JBossAS-4.0.3 SP1
Reporter: Rolf Arne Corneliussen
Assigned To: Remy Maucherat
Sometimes (but less than half the times), I get the following in the log when JBoss is started:
2006-11-09 17:38:14,453 INFO [org.apache.coyote.http11.Http11Protocol] Starting Coyote HTTP/1.1 on http-0.0.0.0-8080
2006-11-09 17:38:14,468 INFO [org.apache.coyote.http11.Http11Protocol] Starting Coyote HTTP/1.1 on http-0.0.0.0-8443
2006-11-09 17:38:14,468 INFO [org.apache.coyote.http11.Http11Protocol] Starting Coyote HTTP/1.1 on http-0.0.0.0-9443
2006-11-09 17:38:14,484 INFO [org.jboss.system.server.Server] JBoss (MX MicroKernel) [4.0.3SP1 (build: CVSTag=JBoss_4_0_3_SP1 date=200510231054)] Started in 19s:531ms
2006-11-09 17:38:14,500 WARN [org.apache.commons.modeler.Registry] No metadata found for org.apache.coyote.RequestInfo
2006-11-09 17:38:14,500 ERROR [org.apache.commons.modeler.Registry] Error registering jboss.web:type=RequestProcessor,worker=http-0.0.0.0-8443,name=HttpRequest2
java.lang.NullPointerException
at org.apache.commons.modeler.Registry.registerComponent(Registry.java:862)
at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.init(Http11Protocol.java:709)
at org.apache.tomcat.util.net.LeaderFollowerWorkerThread.getInitData(LeaderFollowerWorkerThread.java:48)
at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:673)
at java.lang.Thread.run(Thread.java:595)
2006-11-09 17:38:14,500 WARN [org.apache.coyote.http11.Http11Protocol] Error registering request
--
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
14 years, 5 months