[JBoss JIRA] Assigned: (JBAS-1820) JCA 1.5 compliance bug
by Dimitris Andreadis (JIRA)
[ http://jira.jboss.com/jira/browse/JBAS-1820?page=all ]
Dimitris Andreadis reassigned JBAS-1820:
----------------------------------------
Assignee: Weston Price
Probably outdated.
> JCA 1.5 compliance bug
> ----------------------
>
> Key: JBAS-1820
> URL: http://jira.jboss.com/jira/browse/JBAS-1820
> Project: JBoss Application Server
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: JCA service
> Affects Versions: JBossAS-4.0.2 Final
> Environment: Windows 2000
> Reporter: guillaume holler
> Assigned To: Weston Price
> Priority: Minor
> Attachments: jcasample.zip
>
>
> This is a deployment bug that affects inflow messages.
> JCA 1.5 specification states states that "Before a rsource adapter is undeployed, the application server must deactivate all active enpoints consuming messages from that specific resource adapter". This doesn't seem to be the case:
> 1 - start the server with a RAR and an MDB endpoint setup (the test connector accept messages from network and the mdb merely print them on the console after wainting 10s to easealy test enpoint concurrency issues).
> OK: I see the start() and endpointActivation(...) callback called
> 2 - run the client test several times (in a way that enables concurrent message consumption): OK (client OK, console prints all messages)
> 3 - undeploy RAR: I can see the stop callback, but no MDB undeploy or endpointDeactivation(...) callback on resource adapter.
> 4 - deploy RAR again: deployment OK, I can see the start() callback but no endpointActivation(...) callback called
> 5 - run the client test again: client OK, demonstrating the network endpoint is working, but no message printed on the console (no endpoint consumption).
> 6 - undeploy/deploy MDB: everything works again as in 2 (plus, messages pending from step 5 are obviously consumed)
> I think we should have, according to spec, an undeployment of MDBs that depend on the RAR service when the service is undeployed, and a furter restart should trigger a new endpointActivation callback.
--
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
19 years, 1 month
[JBoss JIRA] Updated: (JBAS-2910) minor try-finally changes to make sure that some streams and JDBC objects are always closed
by Dimitris Andreadis (JIRA)
[ http://jira.jboss.com/jira/browse/JBAS-2910?page=all ]
Dimitris Andreadis updated JBAS-2910:
-------------------------------------
Fix Version/s: JBossAS-4.2.0.GA
> minor try-finally changes to make sure that some streams and JDBC objects are always closed
> -------------------------------------------------------------------------------------------
>
> Key: JBAS-2910
> URL: http://jira.jboss.com/jira/browse/JBAS-2910
> Project: JBoss Application Server
> Issue Type: Patch
> Security Level: Public(Everyone can see)
> Components: Web (Tomcat) service, CMP service
> Reporter: Westley Weimer
> Priority: Minor
> Fix For: JBossAS-4.2.0.GA
>
> Original Estimate: 20 minutes
> Remaining Estimate: 20 minutes
>
> Attached are minor candidate patches for jboss (against a CVS checkout of the sources on 2006 03 08) that ensure that resources are closed properly in some unlikely exceptional cases. These changse should not affect jboss functionality at all aside from ensuring that resources are closed in a few more cases.
> This is hardly the most exciting sort of bugfix in the world, but jboss does seem to be concerned with leaks and being ironclad in these situations. The patches all have the general flavor of changing "open; work; close" to "try { open; work; } finally { close; }". It should take a knowledgeable dev at most a few minutes to eyeball them and accept or reject them.
> I'm not sure how to attach the patch file, so I'm copying it here. My apologies if this is the wrong place for this sort of thing.
> --- jboss-20060308-orig/src/main/org/jboss/ejb/plugins/CMPInMemoryPersistenceManager.java 2006-03-08 16:29:45.917109700 -0500
> +++ jboss-20060308/src/main/org/jboss/ejb/plugins/CMPInMemoryPersistenceManager.java 2006-03-08 16:34:15.141058700 -0500
> @@ -355,11 +355,12 @@
> */
> public void loadEntity (EntityEnterpriseContext ctx)
> {
> + java.io.ObjectInputStream in = null;
> try
> {
> // Read fields
>
> - java.io.ObjectInputStream in = new CMPObjectInputStream
> + in = new CMPObjectInputStream
> (new java.io.ByteArrayInputStream ((byte[])this.beans.get (ctx.getId ())));
>
> Object obj = ctx.getInstance ();
> @@ -370,12 +371,15 @@
> f[i].set (obj, in.readObject ());
> }
>
> - in.close ();
> }
> catch (Exception e)
> {
> throw new EJBException ("Load failed", e);
> }
> + finally
> + {
> + if (in != null) { try { in.close(); } catch (Exception e) { } }
> + }
> }
>
> /**
> --- jboss-20060308-orig/src/main/org/jboss/invocation/http/interfaces/Util.java 2006-03-08 16:29:47.899706700 -0500
> +++ jboss-20060308/src/main/org/jboss/invocation/http/interfaces/Util.java 2006-03-08 17:32:40.259780600 -0500
> @@ -158,7 +158,9 @@
> conn.setRequestProperty("ContentType", REQUEST_CONTENT_TYPE);
> conn.setRequestMethod("POST");
> OutputStream os = conn.getOutputStream();
> + ObjectInputStream ois = null;
> ObjectOutputStream oos = new ObjectOutputStream(os);
> + try {
> try
> {
> oos.writeObject(mi);
> @@ -173,12 +175,14 @@
>
> // Get the response MarshalledValue object
> InputStream is = conn.getInputStream();
> - ObjectInputStream ois = new ObjectInputStream(is);
> + ois = new ObjectInputStream(is);
> MarshalledValue mv = (MarshalledValue) ois.readObject();
> // A hack for jsse connection pooling (see patch ).
> ois.read();
> - ois.close();
> - oos.close();
> + } finally {
> + if (ois != null) { try { ois.close(); } catch (Exception e) { } }
> + if (oos != null) { try { oos.close(); } catch (Exception e) { } }
> + }
>
> // If the encoded value is an exception throw it
> Object value = mv.get();
> --- jboss-20060308-orig/src/main/org/jboss/invocation/MarshalledValue.java 2006-03-08 16:29:48.008983700 -0500
> +++ jboss-20060308/src/main/org/jboss/invocation/MarshalledValue.java 2006-03-08 17:30:01.198298600 -0500
> @@ -89,9 +89,12 @@
>
> ByteArrayInputStream bais = new ByteArrayInputStream(serializedForm);
> MarshalledValueInputStream mvis = new MarshalledValueInputStream(bais);
> + try {
> Object retValue = mvis.readObject();
> - mvis.close();
> return retValue;
> + } finally {
> + mvis.close();
> + }
> }
>
> public byte[] toByteArray()
> --- jboss-20060308-orig/src/main/org/jboss/invocation/pooled/interfaces/PooledMarshalledValue.java 2006-03-08 16:29:48.055816700 -0500
> +++ jboss-20060308/src/main/org/jboss/invocation/pooled/interfaces/PooledMarshalledValue.java 2006-03-08 17:34:20.946787700 -0500
> @@ -90,9 +90,12 @@
>
> ByteArrayInputStream bais = new ByteArrayInputStream(serializedForm);
> ObjectInputStream mvis = new OptimizedObjectInputStream(bais);
> + try {
> Object retValue = mvis.readObject();
> - mvis.close();
> return retValue;
> + } finally {
> + try { mvis.close(); } catch (Exception e) { }
> + }
> }
>
> public byte[] toByteArray()
> --- jboss-20060308-orig/src/main/org/jboss/naming/HttpNamingContextFactory.java 2006-03-08 16:29:48.914421700 -0500
> +++ jboss-20060308/src/main/org/jboss/naming/HttpNamingContextFactory.java 2006-03-08 17:35:39.213414500 -0500
> @@ -132,8 +132,12 @@
>
> InputStream is = conn.getInputStream();
> ObjectInputStream ois = new ObjectInputStream(is);
> - MarshalledValue mv = (MarshalledValue) ois.readObject();
> - ois.close();
> + MarshalledValue mv = null;
> + try {
> + mv = (MarshalledValue) ois.readObject();
> + } finally {
> + try { ois.close(); } catch (Exception e) { }
> + }
>
> Object obj = mv.get();
> if( (obj instanceof Naming) == false )
> --- jboss-20060308-orig/src/main/org/jboss/web/AbstractWebContainer.java 2006-03-08 16:29:49.413973700 -0500
> +++ jboss-20060308/src/main/org/jboss/web/AbstractWebContainer.java 2006-03-08 17:37:40.449341300 -0500
> @@ -322,8 +322,11 @@
> throw new DeploymentException("Was unable to mkdir: "+expWarFile);
> log.debug("Unpacking war to: "+expWarFile);
> FileInputStream fis = new FileInputStream(warFile);
> + try {
> JarUtils.unjar(fis, expWarFile);
> - fis.close();
> + } finally {
> + try { fis.close(); } catch (Exception e) { }
> + }
> log.debug("Replaced war with unpacked contents");
> if (warFile.delete() == false)
> log.debug("Was unable to delete war file");
> @@ -416,6 +419,7 @@
>
> FileInputStream fis = new FileInputStream(warFile);
> JarInputStream jin = new JarInputStream(fis);
> + try {
> ZipEntry entry = jin.getNextEntry();
> while (entry != null)
> {
> @@ -426,8 +430,9 @@
> }
> entry = jin.getNextEntry();
> }
> - jin.close();
> -
> + } finally {
> + try { jin.close(); } catch (Exception e) { }
> + }
> URL[] urlArr = new URL[urlList.size()];
> urlList.toArray(urlArr);
> di.annotationsCl = new URLClassLoader(urlArr, di.ucl);
> @@ -706,6 +711,7 @@
> // First check for a WEB-INF/web.xml and a WEB-INF/jboss-web.xml
> InputStream warIS = warURL.openStream();
> java.util.zip.ZipInputStream zipIS = new java.util.zip.ZipInputStream(warIS);
> + try {
> java.util.zip.ZipEntry entry;
> byte[] buffer = new byte[512];
> int bytes;
> @@ -730,7 +736,9 @@
> jbossWebIS = new ByteArrayInputStream(baos.toByteArray());
> }
> }
> - zipIS.close();
> + } finally {
> + try { zipIS.close(); } catch (Exception e) { }
> + }
> }
>
> XmlFileLoader xmlLoader = new XmlFileLoader();
> --- jboss-20060308-orig/src/main/org/jboss/web/WebServer.java 2006-03-08 16:29:49.445195700 -0500
> +++ jboss-20060308/src/main/org/jboss/web/WebServer.java 2006-03-08 17:38:28.403080100 -0500
> @@ -1,4 +1,4 @@
> -/*
> +/* } catch (Exception e) { }
> * JBoss, Home of Professional Open Source
> * Copyright 2005, JBoss Inc., and individual contributors as indicated
> * by the @authors tag. See the copyright.txt in the distribution for a
> @@ -521,6 +521,7 @@
> protected byte[] getBytes(URL url) throws IOException
> {
> InputStream in = new BufferedInputStream(url.openStream());
> + try {
> log.debug("Retrieving " + url);
> ByteArrayOutputStream out = new ByteArrayOutputStream();
> byte[] tmp = new byte[1024];
> @@ -529,8 +530,10 @@
> {
> out.write(tmp, 0, bytes);
> }
> - in.close();
> return out.toByteArray();
> + } finally {
> + try { in.close(); } catch (Exception e) { }
> + }
> }
>
> /**
> --- jboss-20060308-orig/src/main/org/jboss/ejb/plugins/cmp/jdbc/keygen/JDBCDB2IdentityValLocalCreateCommand.java 2006-03-08 16:29:45.323891700 -0500
> +++ jboss-20060308/src/main/org/jboss/ejb/plugins/cmp/jdbc/keygen/JDBCDB2IdentityValLocalCreateCommand.java 2006-03-08 17:19:47.443491800 -0500
> @@ -44,8 +44,9 @@
> protected int executeInsert(int paramIndex, PreparedStatement ps, EntityEnterpriseContext ctx ) throws SQLException {
> int rows = ps.executeUpdate();
> ResultSet results = null;
> + Connection conn = null;
> try {
> - Connection conn = ps.getConnection();
> + conn = ps.getConnection();
> results = conn.prepareStatement( SQL ).executeQuery();
> if( !results.next() ) {
> throw new EJBException( "identity_val_local() returned an empty ResultSet" );
> @@ -58,6 +59,7 @@
> throw new EJBException( "Error extracting identity_val_local()", e );
> } finally {
> JDBCUtil.safeClose( results );
> + JDBCUtil.safeClose(con);
> }
> return rows;
> }
> --- jboss-20060308-orig/src/main/org/jboss/ejb/plugins/cmp/jdbc/keygen/JDBCPostgreSQLCreateCommand.java 2006-03-08 16:29:45.355113700 -0500
> +++ jboss-20060308/src/main/org/jboss/ejb/plugins/cmp/jdbc/keygen/JDBCPostgreSQLCreateCommand.java 2006-03-08 17:22:01.854042800 -0500
> @@ -74,11 +74,12 @@
>
> Statement s = null;
> ResultSet rs = null;
> + Connection c = null;
> try {
> if (trace) {
> log.trace("Executing SQL :"+sequenceSQL);
> }
> - Connection c = ps.getConnection();
> + c = ps.getConnection();
> s = c.createStatement();
> rs = s.executeQuery(sequenceSQL);
> if (!rs.next()) {
> @@ -93,6 +94,7 @@
> } finally {
> JDBCUtil.safeClose(rs);
> JDBCUtil.safeClose(s);
> + JDBCUtil.safeClose(c);
> }
>
> return rows;
> --- jboss-20060308-orig/src/main/org/jboss/ejb/plugins/cmp/jdbc/keygen/JDBCSQLServerCreateCommand.java 2006-03-08 16:29:45.355113700 -0500
> +++ jboss-20060308/src/main/org/jboss/ejb/plugins/cmp/jdbc/keygen/JDBCSQLServerCreateCommand.java 2006-03-08 17:23:29.513540100 -0500
> @@ -61,10 +61,10 @@
>
> protected int executeInsert(int index, PreparedStatement ps, EntityEnterpriseContext ctx) throws SQLException
> {
> - ps.execute();
> ResultSet rs = null;
> try
> {
> + ps.execute();
> int rows = ps.getUpdateCount();
> if(rows != 1)
> {
> @@ -95,6 +95,7 @@
> finally
> {
> JDBCUtil.safeClose(rs);
> + JDBCUtil.safeClose(ps);
> }
> }
> }
--
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
19 years, 1 month
[JBoss JIRA] Updated: (JBAS-2617) ej3.deployer contains too many jars
by Dimitris Andreadis (JIRA)
[ http://jira.jboss.com/jira/browse/JBAS-2617?page=all ]
Dimitris Andreadis updated JBAS-2617:
-------------------------------------
Component/s: EJB3
(was: EJB2)
(was: Build System)
Assignee: Carlo de Wolf (was: Bill Burke)
Assign to Carlo.
> ej3.deployer contains too many jars
> -----------------------------------
>
> Key: JBAS-2617
> URL: http://jira.jboss.com/jira/browse/JBAS-2617
> Project: JBoss Application Server
> Issue Type: Task
> Security Level: Public(Everyone can see)
> Components: EJB3
> Reporter: Scott M Stark
> Assigned To: Carlo de Wolf
>
> There are numerous duplicate and seemingly unused jars in the current ejb3.deployer:
> [starksm@banshee9100 jboss-4.0]$ ls build/output/jboss-4.0.4beta/server/default
> /deploy/ejb3.deployer/
> META-INF/ commons-lang-1.0.jar*
> antlr-2.7.5H3.jar* commons-logging.jar*
> asm-attrs.jar* commons-pool.jar*
> asm.jar* dom4j.jar*
> cglib-2.1.1.jar* ejb3-persistence.jar*
> commons-beanutils.jar* hibernate-annotations.jar*
> commons-codec-1.2.jar* hibernate-entitymanager.jar*
> commons-collections.jar* hibernate3.jar*
> commons-digester-1.6.jar* jaxen-1.1-beta-4.jar*
> commons-discovery.jar* jboss-annotations-ejb3.jar*
> commons-fileupload.jar* jboss-ejb3.jar*
> commons-httpclient.jar* jboss-ejb3x.jar*
> Why all these are needed and which ones should be factored out into the server lib directory need to be defined. There needs to be a distinction between the ejb3.deployer bundled in the app server vs a standalone bundle for installing into earlier releases.
--
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
19 years, 1 month
[JBoss JIRA] Created: (JBAS-3894) shutdown.sh script throws java.lang.NoClassDefFoundError
by Michal Mocnak (JIRA)
shutdown.sh script throws java.lang.NoClassDefFoundError
--------------------------------------------------------
Key: JBAS-3894
URL: http://jira.jboss.com/jira/browse/JBAS-3894
Project: JBoss Application Server
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: System service
Affects Versions: JBossAS-5.0.0.Beta1
Environment: Debian Linux 4.0 (sid)
Reporter: Michal Mocnak
Assigned To: Dimitris Andreadis
Priority: Critical
Fix For: JBossAS-5.0.0.Beta2
1. start jboss as 5.0
2. try to shutdown server by command -> shutdown.sh -S
-> it is not possible due to java.lang.NoClassDefFoundError exception which is thrown. Only way how to shutdown the server is to kill the server process
Error log:
Exception in thread "main" java.lang.NoClassDefFoundError: org/jboss/system/server/ServerImplMBean
at org.jboss.Shutdown.main(Shutdown.java:116)
--
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
19 years, 1 month
[JBoss JIRA] Moved: (JBAS-3924) InvlidationManager$InvlidationGroupImpl produces incorrect log4j DEBGU level setting
by Dimitris Andreadis (JIRA)
[ http://jira.jboss.com/jira/browse/JBAS-3924?page=all ]
Dimitris Andreadis moved JBCACHE-897 to JBAS-3924:
--------------------------------------------------
Project: JBoss Application Server (was: JBoss Cache)
Key: JBAS-3924 (was: JBCACHE-897)
> InvlidationManager$InvlidationGroupImpl produces incorrect log4j DEBGU level setting
> ------------------------------------------------------------------------------------
>
> Key: JBAS-3924
> URL: http://jira.jboss.com/jira/browse/JBAS-3924
> Project: JBoss Application Server
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Clustering
> Reporter: Ben Wang
> Assigned To: Manik Surtani
> Priority: Minor
> Fix For: JBossAS-4.2.0.CR1, JBossAS-5.0.0.Beta2
>
> Original Estimate: 1 hour
> Remaining Estimate: 1 hour
>
> This is reported from a cusomter. The org.jboss.cache.InvalidationManager$InvalidationGroupImpl has log level tracing. However, log4j has problem to handle the InvalidationGroupImpl.getClass() since it has "$" sign to it. As a result, all the log are output as DEBUG even when the category is set as "INFO".
> Fix is not to use that. Instead, code it manually.
--
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
19 years, 1 month
[JBoss JIRA] Created: (JBAS-3481) Error accessing EJB from Servlet: "Unable to activate POA"
by Peter Rasbora (JIRA)
Error accessing EJB from Servlet: "Unable to activate POA"
----------------------------------------------------------
Key: JBAS-3481
URL: http://jira.jboss.com/jira/browse/JBAS-3481
Project: JBoss Application Server
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Components: IIOP service, Naming, Web (Tomcat) service
Affects Versions: JBossAS-4.0.4.GA, JBossAS-4.0.3 SP1, JBossAS-4.0.1 SP1
Environment: JBoss: 4.0.0, 4.0.1SP1, 4.0.3SP1, 4.0.4GA ( each "out of the box")
Java: 1.5.0_06 (build 1.5.0_06-b05)
OS: Windows XP SP2
Reporter: Peter Rasbora
Assigned To: Francisco Reverbel
Priority: Minor
When trying to access Stateless SessionBean (JNDI: "vfmcontroller/VFMController") from within a Servlet,
it's service() throws a "java.lang.Error: POA: not configured!"
JBoss Log warns: "(IIOPListener) Address already in use: JVM_Bind",
"org.jboss.corba.ORBFactory:87) Unable to activate POA" and
"org.omg.CORBA.INITIALIZE: Could not create server socket"
Following to netstat no other processes are bound to specific ports (8080, 1098, 1099, 3528).
For further Details (Source, DD, Log-Output) please refer to the following ressources:
Stateless SessionBean:
http://pastebin.ca/118516
Servlet "Test.java":
http://pastebin.ca/118535
jboss.xml:
http://pastebin.ca/118520
JBoss Log (Console):
http://pastebin.ca/118529 (Hint: Log-Level is DEBUG)
Caught Exception in Servlet "Test":
http://pastebin.ca/118532
--
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
19 years, 1 month
[JBoss JIRA] Moved: (JBCACHE-897) InvlidationManager$InvlidationGroupImpl produces incorrect log4j DEBGU level setting
by Dimitris Andreadis (JIRA)
[ http://jira.jboss.com/jira/browse/JBCACHE-897?page=all ]
Dimitris Andreadis moved JBAS-3197 to JBCACHE-897:
--------------------------------------------------
Project: JBoss Cache (was: JBoss Application Server)
Key: JBCACHE-897 (was: JBAS-3197)
Component/s: (was: JBoss Cache)
Fix Version/s: (was: JBossAS-4.2.0.CR1)
> InvlidationManager$InvlidationGroupImpl produces incorrect log4j DEBGU level setting
> ------------------------------------------------------------------------------------
>
> Key: JBCACHE-897
> URL: http://jira.jboss.com/jira/browse/JBCACHE-897
> Project: JBoss Cache
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Reporter: Ben Wang
> Assigned To: Ben Wang
> Priority: Minor
> Original Estimate: 1 hour
> Remaining Estimate: 1 hour
>
> This is reported from a cusomter. The org.jboss.cache.InvalidationManager$InvalidationGroupImpl has log level tracing. However, log4j has problem to handle the InvalidationGroupImpl.getClass() since it has "$" sign to it. As a result, all the log are output as DEBUG even when the category is set as "INFO".
> Fix is not to use that. Instead, code it manually.
--
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
19 years, 1 month