[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
15 years, 9 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
15 years, 10 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
15 years, 10 months
[JBoss JIRA] Created: (EJBTHREE-941) merge issue when removing from OneToMany in detached state (layered architecture)
by Rico Apfelbeck (JIRA)
merge issue when removing from OneToMany in detached state (layered architecture)
---------------------------------------------------------------------------------
Key: EJBTHREE-941
URL: http://jira.jboss.com/jira/browse/EJBTHREE-941
Project: EJB 3.0
Issue Type: Bug
Affects Versions: AS 4.2.0 CR1
Environment: 13:37:59,625 INFO [ServerInfo] Java version: 1.5.0_09,Sun Microsystems Inc.
13:37:59,625 INFO [ServerInfo] Java VM: Java HotSpot(TM) Server VM 1.5.0_09-b01,Sun Microsystems Inc.
13:37:59,625 INFO [ServerInfo] OS-System: Windows XP 5.1,x86
Reporter: Rico Apfelbeck
We work on a client-server environment with a webstart-client with an own JVM. Only the server has access to the JPA. POJOs are transfered from client to server and back.
Our Issue occurs in the following workflow:
- We get an Object A on the server from the Entitymanager and transfer it to the client.
- This Object has a OneToMany-relation to some Objects B (fetchtype: EAGER, cascade: ALL). In B we have a reference to A.
- On the client we remove in A some B from the Set, for example with clean() and transfer A back to the server.
- We merge A on the server.
- There is no exception thrown.
The returned A from the merge-call does not contain any B, reloading A by Id results in a restored list containing the removed Bs.
While added new Bs to A are stored correctly, removing them doesn't result in the deletion of the removed Bs from the database.
Updating B in the List in A results in updated Bs when merging A.
Only the removal causes problems. We assume that the problem comes from checking the now empty list against the database.
Reloading A before merging in the server and manually compare the List of Bs, using EntityManager.remove() when neccesary. helps our case, but that's not the way it shoud be. :)
--
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
15 years, 10 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
15 years, 11 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
15 years, 11 months