[JBoss-dev] Autogenerated primary keys etc
Is somebody going to integrate autogenerated primary key support to jaws like patch #473280? A very useful feature, I wonder why jboss still doesn't have one. Where can I find information about which the EJB 2.0 features does jboss 2.4.4 support? How about that redeploying problem on Red Hat I've reported (see my last posting here)? I'm ready to help with everything I can just tell me what you need. Best wishes, Alexei Yudichev mailto:[EMAIL PROTECTED] ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Where to put Principal Mappings for resource adapters?
Ok, I finally read about jbosssx. I now think the ConnectionFactoryLoader needs a SecurityDomainJNDIName attribute, hooked up to a org.jboss.security.SecurityDomain instance. When the ConnectionManager needs a Subject, it will call getActiveSubject() on this instance. If the jndi name is not set, that means we expect to use component-managed security (i.e. bmp with people calling cf.getConnection(user, pw) ) The current PrincipalMappingClass and PrincipalMappingProperties can be removed. There are 3 scenarios named thusly in the recent jca book: configured identity. This is what we have now with the ManyToOnePrincipalMapping. I think it can be replaced with a simple extension of the IdentityLoginModule that also supplies a password. principal mapping. This is where the principal and credentials are determined by the user's identity (and connection factory instance), but is not the same. I think this will require a new implementation. caller impersonation. The caller's identity and credentials are passed to the resource adapter. I think this could use the same SecurityDomain that the ejb's use. You'd pick which of these policies you wished by setting the security domain name in the connectionfactoryloader properties, to a separately configured SecurityDomain. Is this reasonably close to a sensible approach? Note that it is often possible to configure a default username and password for ManagedConnectionFactories in their properties: this is supposed to be used only if no subject or ConnectionRequestInfo is supplied. At this time I don't see the need to try to obtain these values from a SecurityDomain since they are supposed to be optional. __ View this jboss-dev thread in the online forums: http://jboss.org/forums/thread.jsp?forum=66&thread=6703 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Automated JBoss Testsuite Results
JBoss daily test results SUMMARY Number of tests run: 268 Successful tests: 267 Errors:0 Failures: 1 [time of test: 11 January 2002 4:57 GMT] [java.version: 1.3.1] [java.vendor: Sun Microsystems Inc.] [java.vm.version: 1.3.1-b24] [java.vm.name: Java HotSpot(TM) Server VM] [java.vm.info: mixed mode] [os.name: Linux] [os.arch: i386] [os.version: 2.4.9-12] See http://lubega.com for full details NOTE: If there are any errors shown above - this mail is only highlighting them - it is NOT indicating that they are being looked at by anyone. It is assumed that whoever makes change(s) to jboss that break the test will be fixing the test or jboss, as appropriate! DETAILS OF ERRORS [details not shown - as this makes the mail too big to reach the sf mailing list] PS BEFORE you commit, run the test suite. Its easy, just run the target 'run-basic-testsuite' from the main build.xml. PPS Come on people - there were a few days back in July 2001 when we had ZERO tests failing! Oh, and thanks - remember we love you too! ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Automated JBoss Testsuite Results
JBoss daily test results SUMMARY Number of tests run: 268 Successful tests: 267 Errors:0 Failures: 1 [time of test: 11 January 2002 4:8 GMT] [java.version: 1.3.1] [java.vendor: Blackdown Java-Linux Team] [java.vm.version: Blackdown-1.3.1-FCS] [java.vm.name: Classic VM] [java.vm.info: green threads, nojit] [os.name: Linux] [os.arch: i386] [os.version: 2.4.9-12] See http://lubega.com for full details NOTE: If there are any errors shown above - this mail is only highlighting them - it is NOT indicating that they are being looked at by anyone. It is assumed that whoever makes change(s) to jboss that break the test will be fixing the test or jboss, as appropriate! DETAILS OF ERRORS [details not shown - as this makes the mail too big to reach the sf mailing list] PS BEFORE you commit, run the test suite. Its easy, just run the target 'run-basic-testsuite' from the main build.xml. PPS Come on people - there were a few days back in July 2001 when we had ZERO tests failing! Oh, and thanks - remember we love you too! ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Automated JBoss Testsuite Results
JBoss daily test results SUMMARY Number of tests run: 268 Successful tests: 267 Errors:0 Failures: 1 [time of test: 11 January 2002 3:21 GMT] [java.version: 1.3.1] [java.vendor: Blackdown Java-Linux Team] [java.vm.version: Blackdown-1.3.1-FCS] [java.vm.name: Java HotSpot(TM) Client VM] [java.vm.info: mixed mode] [os.name: Linux] [os.arch: i386] [os.version: 2.4.9-12] See http://lubega.com for full details NOTE: If there are any errors shown above - this mail is only highlighting them - it is NOT indicating that they are being looked at by anyone. It is assumed that whoever makes change(s) to jboss that break the test will be fixing the test or jboss, as appropriate! DETAILS OF ERRORS [details not shown - as this makes the mail too big to reach the sf mailing list] PS BEFORE you commit, run the test suite. Its easy, just run the target 'run-basic-testsuite' from the main build.xml. PPS Come on people - there were a few days back in July 2001 when we had ZERO tests failing! Oh, and thanks - remember we love you too! ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Automated JBoss Testsuite Results
JBoss daily test results SUMMARY Number of tests run: 268 Successful tests: 266 Errors:0 Failures: 2 [time of test: 11 January 2002 2:53 GMT] [java.version: 1.3.0] [java.vendor: IBM Corporation] [java.vm.version: 1.3.0] [java.vm.name: Classic VM] [java.vm.info: J2RE 1.3.0 IBM build cx130-20010626 (JIT enabled: jitc)] [os.name: Linux] [os.arch: x86] [os.version: 2.4.9-12] See http://lubega.com for full details NOTE: If there are any errors shown above - this mail is only highlighting them - it is NOT indicating that they are being looked at by anyone. It is assumed that whoever makes change(s) to jboss that break the test will be fixing the test or jboss, as appropriate! DETAILS OF ERRORS [details not shown - as this makes the mail too big to reach the sf mailing list] PS BEFORE you commit, run the test suite. Its easy, just run the target 'run-basic-testsuite' from the main build.xml. PPS Come on people - there were a few days back in July 2001 when we had ZERO tests failing! Oh, and thanks - remember we love you too! ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-502025 ] JBoss fail to start
Bugs item #502025, was opened at 2002-01-10 12:37 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=376685&aid=502025&group_id=22866 Category: JBossServer Group: v2.4 (stable) Status: Open Resolution: None Priority: 5 Submitted By: Ronan-Yann Lorin (ryl) Assigned to: Nobody/Anonymous (nobody) Summary: JBoss fail to start Initial Comment: It appears that when an XA/JDBC connection can't be established at startup, the server "hang" and never starts. I guess this is due to a connection test just atfer binding the name in JNDI. Code looks like that: datasource.getConnection().close(); It seems that the exception is not correctly catched. -- Comment By: David Jencks (d_jencks) Date: 2002-01-10 14:30 Message: Logged In: YES user_id=60525 Is this line of code actually throwing an exception? Normally it does not, it just hangs. Set BlockingTimeout to a nonzero value and you will get an exception instead. Blocking timeout is nonzero by default in jboss 3. -- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=376685&aid=502025&group_id=22866 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-502025 ] JBoss fail to start
Bugs item #502025, was opened at 2002-01-10 12:37 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=376685&aid=502025&group_id=22866 Category: JBossServer Group: v2.4 (stable) Status: Open Resolution: None Priority: 5 Submitted By: Ronan-Yann Lorin (ryl) Assigned to: Nobody/Anonymous (nobody) Summary: JBoss fail to start Initial Comment: It appears that when an XA/JDBC connection can't be established at startup, the server "hang" and never starts. I guess this is due to a connection test just atfer binding the name in JNDI. Code looks like that: datasource.getConnection().close(); It seems that the exception is not correctly catched. -- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=376685&aid=502025&group_id=22866 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-501972 ] Messages can not be resent
Bugs item #501972, was opened at 2002-01-10 11:04 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=376685&aid=501972&group_id=22866 >Category: JBossMQ Group: v2.4 (stable) Status: Open Resolution: None Priority: 5 Submitted By: Corby (corby) >Assigned to: Nobody/Anonymous (nobody) Summary: Messages can not be resent Initial Comment: When a message is received from a queue, if it is placed in another queue, acknowledgement of the message will fail. This occurs in JBoss 2.4.4-Catalina on Windows 2000. The following code fragment replicates the problem. mapMessage is a message that was received from a queue. queueConnection = JMSHelper.getQueueConnection( JMSHelper.NONXA_CONNECTION_FACTORY ); queueSession = JMSHelper.getQueueSession( queueConnection ); queueSender = JMSHelper.getQueueSender( queueSession, JMSHelper.FAILED_ALLOCATIONS_QUEUE ); queueConnection.start(); queueSender.send( mapMessage ); With this code, the message is forwarded into the new queue, but acknowledgement fails. When JBoss is restarted, the message will be delivered. Acknowlegement will succeed when I manually copy the message, like so: queueConnection = JMSHelper.getQueueConnection( JMSHelper.NONXA_CONNECTION_FACTORY ); queueSession = JMSHelper.getQueueSession( queueConnection ); queueSender = JMSHelper.getQueueSender( queueSession, JMSHelper.FAILED_ALLOCATIONS_QUEUE ); // NOTE: I am copying this message because of a bug in the current version // of JBossMQ. In future versions, we should be able to forward the message // without copying it. MapMessage sentMessage = JMSHelper.createMapMessage( queueSession ); sentMessage.setString( ACCOUNTING_LOCATION_NUMBER, mapMessage.getString( ACCOUNTING_LOCATION_NUMBER )); sentMessage.setString( DIRECTION_OF_FLOW, mapMessage.getString( DIRECTION_OF_FLOW )); sentMessage.setLong( BEGIN_PRODUCTION_TIME, mapMessage.getLong( BEGIN_PRODUCTION_TIME )); sentMessage.setLong( END_PRODUCTION_TIME, mapMessage.getLong( END_PRODUCTION_TIME )); queueConnection.start(); queueSender.send( sentMessage ); Peter claimed at the beginning of November that this problem had been fixed in CVS: http://www.jboss.org/forums/thread.jsp? forum=48&thread=3789&message=254709 However, subsequent build of the system, including the JBoss 2.4.4-Catalina distribution, continue to have this problem. -- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=376685&aid=501972&group_id=22866 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Re: Auto Deployer
This is good news. The more I've dug into this the more problems I've discovered. e.g. ra.xml in the j2eedeployer file list. I've fixed a couple of 'em. I guess that's why it called the rabbit hole. Real Alice in Wonderland for me :-) On a completely unrelated point. Any chance of changing the forums to have FAQ at the top and with lettering twice as big. I'm pretty sure nobody bothers paging up, or using search for that matter :-) Regards, Adrian __ View this jboss-dev thread in the online forums: http://jboss.org/forums/thread.jsp?forum=66&thread=6902 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-501972 ] Messages can not be resent
Bugs item #501972, was opened at 2002-01-10 11:04 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=376685&aid=501972&group_id=22866 Category: JBossMX Group: v2.4 (stable) Status: Open Resolution: None Priority: 5 Submitted By: Corby (corby) Assigned to: Juha Lindfors (juhalindfors) Summary: Messages can not be resent Initial Comment: When a message is received from a queue, if it is placed in another queue, acknowledgement of the message will fail. This occurs in JBoss 2.4.4-Catalina on Windows 2000. The following code fragment replicates the problem. mapMessage is a message that was received from a queue. queueConnection = JMSHelper.getQueueConnection( JMSHelper.NONXA_CONNECTION_FACTORY ); queueSession = JMSHelper.getQueueSession( queueConnection ); queueSender = JMSHelper.getQueueSender( queueSession, JMSHelper.FAILED_ALLOCATIONS_QUEUE ); queueConnection.start(); queueSender.send( mapMessage ); With this code, the message is forwarded into the new queue, but acknowledgement fails. When JBoss is restarted, the message will be delivered. Acknowlegement will succeed when I manually copy the message, like so: queueConnection = JMSHelper.getQueueConnection( JMSHelper.NONXA_CONNECTION_FACTORY ); queueSession = JMSHelper.getQueueSession( queueConnection ); queueSender = JMSHelper.getQueueSender( queueSession, JMSHelper.FAILED_ALLOCATIONS_QUEUE ); // NOTE: I am copying this message because of a bug in the current version // of JBossMQ. In future versions, we should be able to forward the message // without copying it. MapMessage sentMessage = JMSHelper.createMapMessage( queueSession ); sentMessage.setString( ACCOUNTING_LOCATION_NUMBER, mapMessage.getString( ACCOUNTING_LOCATION_NUMBER )); sentMessage.setString( DIRECTION_OF_FLOW, mapMessage.getString( DIRECTION_OF_FLOW )); sentMessage.setLong( BEGIN_PRODUCTION_TIME, mapMessage.getLong( BEGIN_PRODUCTION_TIME )); sentMessage.setLong( END_PRODUCTION_TIME, mapMessage.getLong( END_PRODUCTION_TIME )); queueConnection.start(); queueSender.send( sentMessage ); Peter claimed at the beginning of November that this problem had been fixed in CVS: http://www.jboss.org/forums/thread.jsp? forum=48&thread=3789&message=254709 However, subsequent build of the system, including the JBoss 2.4.4-Catalina distribution, continue to have this problem. -- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=376685&aid=501972&group_id=22866 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Re: Auto Deployer
Adrian, all this is going away in a couple of hours (as soon as I commit which in my case always is slow). So don't spend cycle fixing this in the current deployer, the problem you raise can be fixed then, just hold on for a couple of hours, I am going as fast as I can... Classloader integration was never trivial, marcf __ View this jboss-dev thread in the online forums: http://jboss.org/forums/thread.jsp?forum=66&thread=6902 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] CVS update: jbossmq/src/main/org/jboss/mq/il/oilOILClientIL.java OILClientILService.java OILServerIL.javaOILServerILFactory.java OILServerILService.java
Good work... Could you apply the same chanages to the UIL also?? Since they are almost identical, it would be nice if they were kept in synch. Regards, Hiram >From: Brian Weaver <[EMAIL PROTECTED]> >To: [EMAIL PROTECTED] >Subject: [JBoss-dev] CVS update: jbossmq/src/main/org/jboss/mq/il/oil >OILClientIL.java OILClientILService.java OILServerIL.java >OILServerILFactory.java OILServerILService.java >Date: Thu, 10 Jan 2002 05:38:18 -0800 > > User: weave > Date: 02/01/10 05:38:17 > > Modified:src/main/org/jboss/mq/il/oil OILClientIL.java > OILClientILService.java OILServerIL.java > OILServerILFactory.java OILServerILService.java > Log: > Changed the constants in the file to be all upper case words, without > having the 'm_' prepended to each constant. > > Added some fixes to make the code behave better under linux, which has > problems with non-preemptable I/O. See the java bug database and search > on 'J2SE_PREEMPTCLOSE' for more information on the linux problem. > > Synchronized the close() method of the OILClientIL.java file to prevent > concurrent access in the checkSocket() method which was not > synchronized. > > Also, changed many of the 'protected' and 'package' level variables and > method to private. This allows JIT compilers to 'trivially' optimize > those sections of code since access is at most restrictive levels. This > did not cause any compile or runtime issues with the testsuite since > none of the members were referenced from other classes. > > Finally, marked some of the classes final to allow JIT compilers >additional > hints for optimizations. Since the classes are not extended in JBoss > this does not appear to be a problem [I could be wrong, it wouldn't be > the first time! If so then I'm sure someone will joyfully revert my > changes and inform me of my erronous assumptions. Cheers!] > > Revision ChangesPath > 1.5 +34 -18 >jbossmq/src/main/org/jboss/mq/il/oil/OILClientIL.java > > Index: OILClientIL.java > === > RCS file: >/cvsroot/jboss/jbossmq/src/main/org/jboss/mq/il/oil/OILClientIL.java,v > retrieving revision 1.4 > retrieving revision 1.5 > diff -u -r1.4 -r1.5 > --- OILClientIL.java2001/11/26 06:33:12 1.4 > +++ OILClientIL.java2002/01/10 13:38:17 1.5 > @@ -31,21 +31,26 @@ > * > * @authorNorbert Lataille ([EMAIL PROTECTED]) > * @authorHiram Chirino ([EMAIL PROTECTED]) > - * @version $Revision: 1.4 $ > + * @version $Revision: 1.5 $ > * @created August 16, 2001 > */ > -public class OILClientIL implements ClientIL, java.io.Serializable > +public final class OILClientIL > + implements ClientIL, > + java.io.Serializable >{ > - static Logger log = Logger.getLogger(OILClientIL.class); > - final static int m_close = 2; > - final static int m_deleteTemporaryDestination = 1; > - final static int m_receive = 3; > - final static int m_pong = 4; > + private final static int DELETE_TEMPORARY_DESTINATION = 1; > + private final static int CLOSE = 2; > + private final static int RECEIVE= 3; > + private final static int PONG = 4; > > + private final static int EXCEPTION_CODE = 1; > + > + private final static Logger log = >Logger.getLogger(OILClientIL.class); > + > private InetAddress addr; > + private int port; > private transient ObjectInputStream in; > private transient ObjectOutputStream out; > - private int port; > private transient Socket socket; > > OILClientIL(InetAddress addr, int port) > @@ -59,12 +64,23 @@ >* >* @exception Exception Description of Exception >*/ > - public void close() > + public synchronized void close() > throws Exception > { > checkSocket(); > - out.writeByte(m_close); > + out.writeByte(CLOSE); > waitAnswer(); > + try > + { > + socket.close(); > + in.close(); > + out.close(); > + } > + catch(Exception e) > + { > + if(log.isDebugEnabled()) > +log.debug("Error closing the socket connection", e); > + } > } > > /** > @@ -77,7 +93,7 @@ > throws Exception > { > checkSocket(); > - out.writeByte(m_deleteTemporaryDestination); > + out.writeByte(DELETE_TEMPORARY_DESTINATION); > out.writeObject(dest); > waitAnswer(); > } > @@ -92,7 +108,7 @@ > throws Exception > { > checkSocket(); > - out.writeByte(m_pong); > + out.writeByte(PONG); > out.writeLong(serverTime); > waitAnswer(); > } > @@ -112,7 +128,7
[JBoss-dev] [ jboss-Bugs-501826 ] Can't Stop the Queues
Bugs item #501826, was opened at 2002-01-10 06:44 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=376685&aid=501826&group_id=22866 Category: JBossMQ Group: v2.4 (stable) Status: Open Resolution: None Priority: 5 Submitted By: Corby (corby) Assigned to: Nobody/Anonymous (nobody) Summary: Can't Stop the Queues Initial Comment: Queues can not be stopped in JBoss as per the JMS spec. This bug is acknowledged by Hiram in this thread: http://www.jboss.org/forums/thread.jsp? forum=48&thread=6341 -- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=376685&aid=501826&group_id=22866 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-501820 ] Inconsistent behavior for non-tx queues
Bugs item #501820, was opened at 2002-01-10 06:40 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=376685&aid=501820&group_id=22866 Category: JBossMQ Group: v2.4 (stable) Status: Open Resolution: None Priority: 5 Submitted By: Corby (corby) Assigned to: Nobody/Anonymous (nobody) Summary: Inconsistent behavior for non-tx queues Initial Comment: I have observed this problem in JBoss 2.4.4-Catalina, running on Windows 2000. I have an MDB that receives messages from a queue, Q1, for messages. It attempts to process the message, and this processing involves numerous database writes. If something goes wrong with the processing, then I wish to rollback my database updates, and copy the message into a second queue, Q2. I never want to rollback operations on Q1 or Q2. So I declare my database to be a managed resource for my MDB, but I do not declare Q1 or Q2 to be managed resources. And I use a non-XA connection factory to retrieve my queue connections. When my MDB uses bean-managed transactions, it behaves exactly as I expect. That is, committing or rolling back the transaction will determine whether or not writes occur to the database, but it has no effect on whether a message is pulled out of Q1 or sent into Q2. But when my MDB uses container-managed transactions, the behavior is inconsistent. Committing the transaction causes it to behave as expected. But if I call setRollbackOnly() on the MessageDrivenContext, it rolls back the datasource AND Q1, but not Q2. (Of course, this causes the message to infinitely redeliver, process with error, and successfully forward on to Q2). I think this is a bug, and that the bean should not rollback Q1 when it is CMT, just like it doesn't when it is BMT. -- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=376685&aid=501820&group_id=22866 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] more standardjboss-cmp.xml
For postgresql the Boolean mapping is wrong. Should be java.lang.Boolean BIT BOOLEAN ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jbossmq/src/main/org/jboss/mq/il/oil OILClientIL.java OILClientILService.java OILServerIL.java OILServerILFactory.java OILServerILService.java
User: weave Date: 02/01/10 05:38:17 Modified:src/main/org/jboss/mq/il/oil OILClientIL.java OILClientILService.java OILServerIL.java OILServerILFactory.java OILServerILService.java Log: Changed the constants in the file to be all upper case words, without having the 'm_' prepended to each constant. Added some fixes to make the code behave better under linux, which has problems with non-preemptable I/O. See the java bug database and search on 'J2SE_PREEMPTCLOSE' for more information on the linux problem. Synchronized the close() method of the OILClientIL.java file to prevent concurrent access in the checkSocket() method which was not synchronized. Also, changed many of the 'protected' and 'package' level variables and method to private. This allows JIT compilers to 'trivially' optimize those sections of code since access is at most restrictive levels. This did not cause any compile or runtime issues with the testsuite since none of the members were referenced from other classes. Finally, marked some of the classes final to allow JIT compilers additional hints for optimizations. Since the classes are not extended in JBoss this does not appear to be a problem [I could be wrong, it wouldn't be the first time! If so then I'm sure someone will joyfully revert my changes and inform me of my erronous assumptions. Cheers!] Revision ChangesPath 1.5 +34 -18jbossmq/src/main/org/jboss/mq/il/oil/OILClientIL.java Index: OILClientIL.java === RCS file: /cvsroot/jboss/jbossmq/src/main/org/jboss/mq/il/oil/OILClientIL.java,v retrieving revision 1.4 retrieving revision 1.5 diff -u -r1.4 -r1.5 --- OILClientIL.java 2001/11/26 06:33:12 1.4 +++ OILClientIL.java 2002/01/10 13:38:17 1.5 @@ -31,21 +31,26 @@ * * @authorNorbert Lataille ([EMAIL PROTECTED]) * @authorHiram Chirino ([EMAIL PROTECTED]) - * @version $Revision: 1.4 $ + * @version $Revision: 1.5 $ * @created August 16, 2001 */ -public class OILClientIL implements ClientIL, java.io.Serializable +public final class OILClientIL + implements ClientIL, + java.io.Serializable { - static Logger log = Logger.getLogger(OILClientIL.class); - final static int m_close = 2; - final static int m_deleteTemporaryDestination = 1; - final static int m_receive = 3; - final static int m_pong = 4; + private final static int DELETE_TEMPORARY_DESTINATION = 1; + private final static int CLOSE = 2; + private final static int RECEIVE= 3; + private final static int PONG = 4; + private final static int EXCEPTION_CODE = 1; + + private final static Logger log = Logger.getLogger(OILClientIL.class); + private InetAddress addr; + private int port; private transient ObjectInputStream in; private transient ObjectOutputStream out; - private int port; private transient Socket socket; OILClientIL(InetAddress addr, int port) @@ -59,12 +64,23 @@ * * @exception Exception Description of Exception */ - public void close() + public synchronized void close() throws Exception { checkSocket(); - out.writeByte(m_close); + out.writeByte(CLOSE); waitAnswer(); + try + { + socket.close(); + in.close(); + out.close(); + } + catch(Exception e) + { + if(log.isDebugEnabled()) +log.debug("Error closing the socket connection", e); + } } /** @@ -77,7 +93,7 @@ throws Exception { checkSocket(); - out.writeByte(m_deleteTemporaryDestination); + out.writeByte(DELETE_TEMPORARY_DESTINATION); out.writeObject(dest); waitAnswer(); } @@ -92,7 +108,7 @@ throws Exception { checkSocket(); - out.writeByte(m_pong); + out.writeByte(PONG); out.writeLong(serverTime); waitAnswer(); } @@ -112,7 +128,7 @@ checkSocket(); if( trace ) log.trace("Writing request"); - out.writeByte(m_receive); + out.writeByte(RECEIVE); out.writeInt(messages.length); for (int i = 0; i < messages.length; ++i) { @@ -130,8 +146,8 @@ * * @exception Exception Description of Exception */ - protected void checkSocket() - throws Exception + private void checkSocket() + throws RemoteException { if (socket == null) { @@ -144,7 +160,7 @@ * * @exception RemoteException Description of Exception */ - protected void createConnect
RE: [JBoss-dev] RH docs
note that for some organisation, paying through credit card and internet billing is not accepted... I've bought the doc on my own money, with no hope get it back, whatever I show as a proof... the only thing accepted is an official bill on paper with a company stamp. for 10$ I've accepted, 30$ became annoying and impose even much motivation regular subscription fee of 30$ is above professional involvement... passion may justify it, but it's private. I'm not sure that people that are already doubtful will accept to pay for their work, and this may limit jboss market development, out of a small community of passionate people. so, whatever is the price, there should be an alternative "B2B" billing system compatible with foreign customs, tax laws, and narrow minded account managers. making a bill with 10$ doc, 30$ subscription, and 50$ billing cost would be OK, given the fact that the bill is accepted officialy in my company. another idea could be to organize a way for intermediate (bookstores, IT resalers...) to sell the PDF or printed version... > -Message d'origine- > De: marc fleury [mailto:[EMAIL PROTECTED]] > Date: mercredi 9 janvier 2002 21:03 > À: [EMAIL PROTECTED] > Objet: Re: [JBoss-dev] RH docs > > > we are trying to set up a program with Flashline where we > would offer a subscription service that gives you access to > all the documentation for a flat fee. > The "upgrade" to the 2.4 documentation is just too much > infrastructure for flashline it seems that for the next > iteration already they have problems given the number of > individual updates they need to do. > > The subscription would be simpler but we are not sure they > can take care of the billing for this, we will keep you posted. > > It would be reasonably priced like $30 for 6 month something > like that, with content and all documentation included. It > seems that when people buy the documentation they buy $30 > buck anyway (buy all 3) so for that price you will have all > updates to it. ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development