[JBoss JIRA] Created: (JBAS-4504) Container does not report invalid named query exception
by Radim Marek (JIRA)
Container does not report invalid named query exception
--------------------------------------------------------
Key: JBAS-4504
URL: http://jira.jboss.com/jira/browse/JBAS-4504
Project: JBoss Application Server
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: EJB3
Affects Versions: JBossAS-4.0.5.GA
Environment: java 5 update 11; jboss 4.0.5 GA
Reporter: Radim Marek
Assigned To: Carlo de Wolf
Priority: Minor
When entity manager is called to create non-existing named query (for example because of mistyping), container doesn't throw a persistence exception.
Code
Query query = entityManager.createNamedQuery("MarketingBatch.getBatches");
had been called from remote client and exception had appeared only on client as ClassNotFound: org.hibernate.MappingException. Other problems with named query are reported as expected.
I thought all exception not handled by session bean should be reported. It would be at least convenient.
--
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, 7 months
[JBoss JIRA] Created: (JBREM-947) ConnectionValidator hangs when server dies
by Tim Fox (JIRA)
ConnectionValidator hangs when server dies
------------------------------------------
Key: JBREM-947
URL: http://jira.jboss.com/jira/browse/JBREM-947
Project: JBoss Remoting
Issue Type: Bug
Security Level: Public (Everyone can see)
Reporter: Tim Fox
Fix For: 2.2.2.SP7
If the connection between client and server is pulled (pull the real cable) or the entire server suddenly dies, then the connection won't be closed from the server (unlike a kill -9 of the server where the OS will terminate that processses connections), so the client making the write() or read() on the socket won't receive an exception.
In the eyes of TCP the connection is still alive and the read/write will block until the socket timeout is reached.
Typically the socket timeout will be much higher than the desired failure detection time (the validation interval), but currently failure will never be detected in this situation before the socket timeout time.
Remoting should not be dependent on the socket timeout for failure detection, the connetion validation and socket timeout should be possible to be configured separately.
E.g. you might want to configure a socket timeout of 60 seconds, but a connection validation frequency (ping) of 5 seconds. Currently this is not possible.
The current implementation gives inconsistent behaviour depending on how the server died - i.e. whether the process died (e.g. kill -9) or the cable was pulled or the entire server disappeared.
--
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, 8 months
[JBoss JIRA] Created: (JBREM-949) CLONE [JBREM-947] - ConnectionValidator hangs when server dies
by Ron Sigal (JIRA)
CLONE [JBREM-947] - ConnectionValidator hangs when server dies
--------------------------------------------------------------
Key: JBREM-949
URL: http://jira.jboss.com/jira/browse/JBREM-949
Project: JBoss Remoting
Issue Type: Bug
Security Level: Public (Everyone can see)
Affects Versions: 2.2.2.SP7
Reporter: Tim Fox
Assigned To: Ron Sigal
Fix For: 2.4.0.GA
If the connection between client and server is pulled (pull the real cable) or the entire server suddenly dies, then the connection won't be closed from the server (unlike a kill -9 of the server where the OS will terminate that processses connections), so the client making the write() or read() on the socket won't receive an exception.
In the eyes of TCP the connection is still alive and the read/write will block until the socket timeout is reached.
Typically the socket timeout will be much higher than the desired failure detection time (the validation interval), but currently failure will never be detected in this situation before the socket timeout time.
Remoting should not be dependent on the socket timeout for failure detection, the connetion validation and socket timeout should be possible to be configured separately.
E.g. you might want to configure a socket timeout of 60 seconds, but a connection validation frequency (ping) of 5 seconds. Currently this is not possible.
The current implementation gives inconsistent behaviour depending on how the server died - i.e. whether the process died (e.g. kill -9) or the cable was pulled or the entire server disappeared.
--
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, 8 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
16 years, 8 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
16 years, 8 months
[JBoss JIRA] Created: (JBCLUSTER-157) Server Shutdown Latency and Session replication and Forwarding
by Shankar Pattabiraman (JIRA)
Server Shutdown Latency and Session replication and Forwarding
--------------------------------------------------------------
Key: JBCLUSTER-157
URL: http://jira.jboss.com/jira/browse/JBCLUSTER-157
Project: JBoss Clustering
Issue Type: Bug
Security Level: Public (Everyone can see)
Environment: Java 1.5.0_05, Win XP,Red Hat 3 JBoss 4.0.5 Apache
Reporter: Shankar Pattabiraman
Assigned To: Brian Stansberry
Priority: Minor
Setup a cluster with 2 nodes. Be in a session where a server is servicing.
Try to give a Control Z to kill the server while servicing. The latency involved in shutting down the server never gives a chance for the server to switch to the other.
The session in the latency period of shutdown never gets successfully switched to the other node in the cluster.
Apache-2 Node Jboss Cluster and a Trivial JEE Application.
Check this out whether it is a configuration issue or a real issue.
--
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, 8 months
[JBoss JIRA] Created: (EJBTHREE-686) Bidirectional @OneToOne with CascadeType.ALL and optional=false on the non-owning side:
by Jeremy Norris (JIRA)
Bidirectional @OneToOne with CascadeType.ALL and optional=false on the non-owning side:
---------------------------------------------------------------------------------------
Key: EJBTHREE-686
URL: http://jira.jboss.com/jira/browse/EJBTHREE-686
Project: EJB 3.0
Issue Type: Bug
Components: EJB3 Extensions
Affects Versions: EJB 3.0 RC8 - FD, EJB 3.0 RC7 - FD, EJB 3.0 RC6 - PFD
Reporter: Jeremy Norris
Consider the following two classes:
----- class X:
@Entity
@Table(name="x")
public class X
{
private Integer id;
private Y y;
public X()
{
this.y = new Y(this);
}
@Id
@GeneratedValue
@Column(name = "id", nullable=false, updatable=false)
public Integer getId()
{
return id;
}
protected void setId(Integer id)
{
this.id = id;
}
@OneToOne(cascade={CascadeType.ALL}, mappedBy="x")
public Y getY()
{
return y;
}
protected void setY(Y y)
{
this.y = y;
}
}
----- class Y:
@Entity
@Table(name="y")
public class Y
{
private Integer id;
private X x;
protected Y()
{
}
public Y(X x)
{
this.x = x;
x.setY(this);
}
@Id
@GeneratedValue
@Column(name = "id", nullable=false, updatable=false)
public Integer getId()
{
return id;
}
protected void setId(Integer id)
{
this.id = id;
}
@OneToOne
@JoinColumn(name="x_id", nullable=false)
public X getX()
{
return x;
}
protected void setX(X x)
{
this.x = x;
}
}
----- X is persisted as follows:
// Note: The constructor creates a new dependent Y instance, and hooks it up appropriately:
X x = new X();
em.persist(x);
-----
This works fine and persists as expected. However, if I add "optional=false" to the X.@OneToOne declaration, it fails with the following exception:
javax.ejb.EJBTransactionRolledbackException: javax.persistence.PersistenceException: org.hibernate.PropertyValueException: not-null property references a null or transient value: ... Y.x
Y.x definitely set. Also, "x == x.getY().getX()" is true. (Interestingly, this only happens if I put the "optional=false" on the X side. "optional=false" on the Y side is fine). This seems like a bug unless there is something I don't understand about "optional", but it seems pretty simply - The spec says the following about this attribute:
(Optional) Whether the association is optional.
If set to false then a non-null relationship must
always exist.
--
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, 8 months