[JBoss-dev] Autogenerated primary keys etc

2002-01-10 Thread Alexey Yudichev

  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?

2002-01-10 Thread David Jencks

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

2002-01-10 Thread chris



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

2002-01-10 Thread chris



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

2002-01-10 Thread chris



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

2002-01-10 Thread chris



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

2002-01-10 Thread noreply

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

2002-01-10 Thread noreply

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

2002-01-10 Thread noreply

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

2002-01-10 Thread Adrian Brock

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

2002-01-10 Thread noreply

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

2002-01-10 Thread marc fleury

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

2002-01-10 Thread Hiram Chirino


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

2002-01-10 Thread noreply

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

2002-01-10 Thread noreply

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

2002-01-10 Thread Dave Smith

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

2002-01-10 Thread Brian Weaver

  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

2002-01-10 Thread Coetmeur, Alain


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