[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=detailatid=376685aid=501972group_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=48thread=3789message=254709 However, subsequent build of the system, including the JBoss 2.4.4-Catalina distribution, continue to have this problem. -- Comment By: Peter Antman (pra) Date: 2002-01-11 00:03 Message: Logged In: YES user_id=84651 This was (and is fixed) in the main trunk of JBossMQ (http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/jboss/jbossmq/src/main/org/jboss/mq/SpyMessage.java.diff?r1=1.3r2=1.4), but has never been backported to the 2.4 version of JBossMQ. Therefore: it works in 3.0, but the 2.4.4 is broken. -- You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=376685aid=501972group_id=22866 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Autogenerated primary keys etc
Is this a feature supported by other J2EE servers? If so, we should have it also. If not, should we be first? I'm now in a situation that i actually myself would like to have that feature, but can't cover all the pros and cons with it. Any comments from others already been this way, i mean there has been plenty of discussions... /Lennart Den 2002-01-11 08:27:02 skrev Alexey Yudichev [EMAIL PROTECTED]: 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. Best wishes, Alexei Yudichev mailto:[EMAIL PROTECTED] ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
FW: [JBoss-dev] Autogenerated primary keys etc
I can't check which J2EE servers support this feature but as Richard Monson-Haefel said in his Enterprise Javabeans (O'Reilly), this feature is supported by MOST application servers. Maybe I haven't enough experience but I suppose how much effort would be made and extra problems would be caused to generate a unique primary key at EJB side. A long thread at theserverside.com was devoted to this problem . http://sf.net/projects/ejbutils does this but these long 55-chars length pk's... Best wishes, Alexei Yudichev mailto:[EMAIL PROTECTED] -Original Message- From: Lennart Petersson [mailto:[EMAIL PROTECTED]] Sent: Friday, January 11, 2002 11:41 AM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] Autogenerated primary keys etc Is this a feature supported by other J2EE servers? If so, we should have it also. If not, should we be first? I'm now in a situation that i actually myself would like to have that feature, but can't cover all the pros and cons with it. Any comments from others already been this way, i mean there has been plenty of discussions... /Lennart Den 2002-01-11 08:27:02 skrev Alexey Yudichev [EMAIL PROTECTED]: 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. Best wishes, Alexei Yudichev mailto:[EMAIL PROTECTED] ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Autogenerated primary keys etc
Hi This feature is difficult to implement because there is no standard in the DBs. Some do like Oracle, PostgreSQL, some do it differentely like M$ SQL-Server and Sybase with the Identity table attribute and some do not provide anything like M$ Access. It becomes more difficult if you need autogeneraed PK spawning over more than one DB. AFAIK there is a EJB around in JBoss generating PKs but I did not use it. I don't think there is a general solution possible but I would suggest that you create a SLSB delivering the generated PK and encapsulate the implementation in this EJB to separate DB specific details from your application. Andy - Original Message - From: Lennart Petersson [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, January 11, 2002 1:41 AM Subject: Re: [JBoss-dev] Autogenerated primary keys etc Is this a feature supported by other J2EE servers? If so, we should have it also. If not, should we be first? I'm now in a situation that i actually myself would like to have that feature, but can't cover all the pros and cons with it. Any comments from others already been this way, i mean there has been plenty of discussions... /Lennart Den 2002-01-11 08:27:02 skrev Alexey Yudichev [EMAIL PROTECTED]: 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. Best wishes, Alexei Yudichev mailto:[EMAIL PROTECTED] ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ___ 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=detailatid=376685aid=501972group_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=48thread=3789message=254709 However, subsequent build of the system, including the JBoss 2.4.4-Catalina distribution, continue to have this problem. -- Comment By: Christian Riege (lqd) Date: 2002-01-11 03:32 Message: Logged In: YES user_id=176671 pls. see attached patch file which is versus the Branch_2_4 CVS. This is the 2.4 backport of the fix from HEAD. Corby, can you apply the patch and give us feedback of whether this solves your problem? if you don't have JBoss 2.4.4 CVS sources drop me a note and I will send the MQ .jar files. -- Comment By: Peter Antman (pra) Date: 2002-01-11 00:03 Message: Logged In: YES user_id=84651 This was (and is fixed) in the main trunk of JBossMQ (http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/jboss/jbossmq/src/main/org/jboss/mq/SpyMessage.java.diff?r1=1.3r2=1.4), but has never been backported to the 2.4 version of JBossMQ. Therefore: it works in 3.0, but the 2.4.4 is broken. -- You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=376685aid=501972group_id=22866 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] standard for obtaining an org.jboss.logging.Logger instance
hi, is there a standard way of getting the Logger instance in JBoss? the code is sprinkled with at least 4 different ways of doing so, i.e. sometimes its a private variable, sometimes its protected, sometimes its on a package level access, sometimes its declared as 'final', etc ... how about agreeing on a standard way; that would clean up some confusion. regards, christian ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jbossmq/src/main/org/jboss/mq GenericConnectionFactory.java
User: lqd
Date: 02/01/11 04:27:33
Modified:src/main/org/jboss/mq GenericConnectionFactory.java
Log:
- use org.jboss.logging.Logger instead of log4j
- add debug level message when handing out a ClientIL
- bump log level of can't connect to server from debug to error
Revision ChangesPath
1.6 +10 -3 jbossmq/src/main/org/jboss/mq/GenericConnectionFactory.java
Index: GenericConnectionFactory.java
===
RCS file:
/cvsroot/jboss/jbossmq/src/main/org/jboss/mq/GenericConnectionFactory.java,v
retrieving revision 1.5
retrieving revision 1.6
diff -u -r1.5 -r1.6
--- GenericConnectionFactory.java 2001/11/12 05:27:35 1.5
+++ GenericConnectionFactory.java 2002/01/11 12:27:32 1.6
@@ -14,15 +14,18 @@
import org.jboss.mq.il.ServerIL;
import org.jboss.mq.il.ServerILFactory;
+import org.jboss.logging.Logger;
+
/**
* The RMI implementation of the DistributedConnectionFactory object
*
* @author Hiram Chirino ([EMAIL PROTECTED])
* @createdAugust 16, 2001
- * @version$Revision: 1.5 $
+ * @version$Revision: 1.6 $
*/
public class GenericConnectionFactory implements java.io.Serializable {
- static org.apache.log4j.Category cat = org.apache.log4j.Category.getInstance(
GenericConnectionFactory.class );
+
+ static Logger log = Logger.getLogger( GenericConnectionFactory.class );
// An instance of the ServerIL, once it is setup, we make clones every
// time a new connection is needed.
@@ -67,6 +70,10 @@
String clientILServiceCN = connectionProperties.getProperty(
ServerILFactory.CLIENT_IL_SERVICE_KEY );
ClientILService service = ( ClientILService )Class.forName( clientILServiceCN
).newInstance();
service.init( connection, connectionProperties );
+
+ if ( log.isDebugEnabled() )
+ log.debug(Handing out ClientIL: + clientILServiceCN);
+
return service;
}
@@ -96,7 +103,7 @@
// used to produce multiple connections.
return server.cloneServerIL();
} catch ( Exception e ) {
- cat.debug( Could not connect to the server, e );
+ log.error( Could not connect to the server, e );
throw new SpyJMSException( Could not connect to the server, e );
}
}
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jbossmq/src/main/org/jboss/mq GenericConnectionFactory.java
User: lqd
Date: 02/01/11 04:31:05
Modified:src/main/org/jboss/mq Tag: Branch_2_4
GenericConnectionFactory.java
Log:
Backport of HEAD changes to Branch_2_4:
- use org.jboss.logging.Logger instead of log4j
- add debug level message when handing out a ClientIL
- bump log level of can't connect to server from debug to error
Revision ChangesPath
No revision
No revision
1.2.2.3 +17 -10jbossmq/src/main/org/jboss/mq/GenericConnectionFactory.java
Index: GenericConnectionFactory.java
===
RCS file:
/cvsroot/jboss/jbossmq/src/main/org/jboss/mq/GenericConnectionFactory.java,v
retrieving revision 1.2.2.2
retrieving revision 1.2.2.3
diff -u -r1.2.2.2 -r1.2.2.3
--- GenericConnectionFactory.java 2001/11/28 06:15:27 1.2.2.2
+++ GenericConnectionFactory.java 2002/01/11 12:31:05 1.2.2.3
@@ -14,12 +14,14 @@
import org.jboss.mq.il.ServerIL;
import org.jboss.mq.il.ServerILFactory;
+import org.jboss.logging.Logger;
+
/**
* The RMI implementation of the DistributedConnectionFactory object
*
* @author Hiram Chirino ([EMAIL PROTECTED])
* @createdAugust 16, 2001
- * @version$Revision: 1.2.2.2 $
+ * @version$Revision: 1.2.2.3 $
*/
public class GenericConnectionFactory implements java.io.Serializable
{
@@ -35,18 +37,19 @@
// These are the keys we look for in the connection properties
public final static String SERVER_IL_FACTORY_KEY = ServerILFactory;
public final static String CLIENT_IL_SERVICE_KEY = ClientILService;
-
- static org.apache.log4j.Category cat = org.apache.log4j.Category.getInstance(
GenericConnectionFactory.class );
+ static Logger log = Logger.getLogger( GenericConnectionFactory.class );
/**
* The constructor takes a ServerIL and the Connection Properties
-* parameters, The connection properties are allways required since they are
-* used to setup the ClientIL, but the ServerIL can be null if the
-* connection properties defines a ServerILFactory so that the SeverIL can
-* be created on the client side. The ServerIL paramter is usefull for IL
-* such as RMI or the JVM IL since trying to explicity create a connection
-* to them is not strait forward.
+* parameters, The connection properties are allways required since
+* they are used to setup the ClientIL, but the ServerIL can be null
+* if the connection properties defines a ServerILFactory so that
+* the SeverIL can be created on the client side.
+* p
+* The ServerIL parameter is useful for ILs such as RMI or the JVM
+* IL since trying to explicity create a connection to them is not
+* straight forward.
*
* @param server Description of Parameter
* @param props Description of Parameter
@@ -68,6 +71,10 @@
String clientILServiceCN = connectionProperties.getProperty(
CLIENT_IL_SERVICE_KEY );
ClientILService service = ( ClientILService )Class.forName( clientILServiceCN
).newInstance();
service.init( connection, connectionProperties );
+
+ if ( log.isDebugEnabled() )
+ log.debug(Handing out ClientIL: + clientILServiceCN);
+
return service;
}
@@ -97,7 +104,7 @@
// used to produce multiple connections.
return server.cloneServerIL();
} catch ( Exception e ) {
- cat.debug( Could not connect to the server, e );
+ log.error( Could not connect to the server, e );
throw new SpyJMSException( Could not connect to the server, e );
}
}
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] standard for obtaining an org.jboss.logging.Logger instance
extends org.jboss.system.ServiceMBeanSupport :-) It's protected there. Regards, Adrian __ View this jboss-dev thread in the online forums: http://jboss.org/forums/thread.jsp?forum=66thread=6964 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] ejbCreatemethod
ejbCreatemethod and ejbPostCreatemethod Is anybody working on this? It's part of ejb-2.0. It's reported in bugs on sourceforge and there's quite a few questions in the forums. Should be quite simple, but then I haven't too gone too far into the rabbit hole yet :-) Regards, Adrian __ View this jboss-dev thread in the online forums: http://jboss.org/forums/thread.jsp?forum=66thread=6979 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Re: ejbCreatemethod
I can't find ejbHomemethod either. I didn't look that hard though :-) Regards, Adrian __ View this jboss-dev thread in the online forums: http://jboss.org/forums/thread.jsp?forum=66thread=6979 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] ejbCreatemethod
It looked like something simple enough for even a rookie like me to handle, but then I also recall seeing a patch on Sourceforge that already addresses this issue. I think it was patch 493604 or something like that. If it's not being dealt with, I'm happy to give it a shot. ;) -Original Message- From: Adrian Brock [mailto:[EMAIL PROTECTED]] Sent: Friday, January 11, 2002 10:54 AM To: [EMAIL PROTECTED] Subject: [JBoss-dev] ejbCreatemethod ejbCreatemethod and ejbPostCreatemethod Is anybody working on this? It's part of ejb-2.0. It's reported in bugs on sourceforge and there's quite a few questions in the forums. Should be quite simple, but then I haven't too gone too far into the rabbit hole yet :-) Regards, Adrian __ View this jboss-dev thread in the online forums: http://jboss.org/forums/thread.jsp?forum=66thread=6979 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Re: ejbCreatemethod
Rhett Aultman wrote: It looked like something simple enough for even a rookie like me to handle, but then I also recall seeing a patch on Sourceforge that already addresses this issue. I think it was patch 493604 or something like that. If it's not being dealt with, I'm happy to give it a shot. That patch doesn't look very complete :-( Looks like he was Stateful Session Beans :-) Regards, Adrian __ View this jboss-dev thread in the online forums: http://jboss.org/forums/thread.jsp?forum=66thread=6979 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Re: ejbCreatemethod
uhmm if I recall. again the source is not at hand. There were some changes made in container that should work for entity and session. I recall the patch really addressing a bug in session beans though although I think I tested it against entity beans... its been so long ago. Ill look at the source tonight when i get home from work. Al [EMAIL PROTECTED] wrote: Rhett Aultman wrote: It looked like something simple enough for even a rookie like me to handle, but then I also recall seeing a patch on Sourceforge that already addresses this issue. I think it was patch 493604 or something like that. If it's not being dealt with, I'm happy to give it a shot. That patch doesn't look very complete :-(Looks like he was Stateful Session Beans :-)Regards,Adrian__View this jboss-dev thread in the online forums:http://jboss.org/forums/thread.jsp?forum=66thread=6979___Jboss-development mailing list[EMAIL PROTECTED]https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Re: ejbCreatemethod
Oh, well then it looks like there might actually be something simple enough for me to cut my teeth on after all. Wonderful! I'd be happy to give this a shot during one of my Sunday coding sessions unless one of the more seasoned people on here would prefer to do it instead of waiting on me. -Original Message- From: Adrian Brock [mailto:[EMAIL PROTECTED]] Sent: Friday, January 11, 2002 12:11 PM To: [EMAIL PROTECTED] Subject: [JBoss-dev] Re: ejbCreatemethod Rhett Aultman wrote: It looked like something simple enough for even a rookie like me to handle, but then I also recall seeing a patch on Sourceforge that already addresses this issue. I think it was patch 493604 or something like that. If it's not being dealt with, I'm happy to give it a shot. That patch doesn't look very complete :-( Looks like he was Stateful Session Beans :-) Regards, Adrian __ View this jboss-dev thread in the online forums: http://jboss.org/forums/thread.jsp?forum=66thread=6979 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Autogenerated primary keys etc
Here is the scoop. Last I checked Oleg was working on this for EJB 2.0, but I have trouble contacting him (our email servers don't like each other). The way it will be implemented is with a lookup in JNDI that returns an object that implements some yet to be defined AutoNumber interface. I think the initial revision uses a sequence table. I don't think we will be able to support auto-generated columns, as this requires special sql in the insert statement or special handling of the prepared statement object. When we start seeing JDBC 3.0 drivers, which support auto-generated columns, we will be able to add generic support. To make a long story short, it should be in JBoss 3.0 final. -dain -Original Message- From: Andreas Schaefer [mailto:[EMAIL PROTECTED]] Sent: Friday, January 11, 2002 4:50 AM To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: [JBoss-dev] Autogenerated primary keys etc Hi This feature is difficult to implement because there is no standard in the DBs. Some do like Oracle, PostgreSQL, some do it differentely like M$ SQL-Server and Sybase with the Identity table attribute and some do not provide anything like M$ Access. It becomes more difficult if you need autogeneraed PK spawning over more than one DB. AFAIK there is a EJB around in JBoss generating PKs but I did not use it. I don't think there is a general solution possible but I would suggest that you create a SLSB delivering the generated PK and encapsulate the implementation in this EJB to separate DB specific details from your application. Andy - Original Message - From: Lennart Petersson [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, January 11, 2002 1:41 AM Subject: Re: [JBoss-dev] Autogenerated primary keys etc Is this a feature supported by other J2EE servers? If so, we should have it also. If not, should we be first? I'm now in a situation that i actually myself would like to have that feature, but can't cover all the pros and cons with it. Any comments from others already been this way, i mean there has been plenty of discussions... /Lennart Den 2002-01-11 08:27:02 skrev Alexey Yudichev [EMAIL PROTECTED]: 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. Best wishes, Alexei Yudichev mailto:[EMAIL PROTECTED] ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] HTTPSession Clustering: howto
Hey,
On Mon, 31 Dec 2001, Sacha Labourey wrote:
Servlet container implications
==
As we exchange an HttpSession object between the servlet container and the
EJB, it needs to be Serializable. Consequently, a new interface has been
defined:
public interface SerializableHttpSession
extends javax.servlet.http.HttpSession,
java.io.Serializable
{
public boolean areAttributesModified (SerializableHttpSession
previousVersion);
}
This interface makes sure we have a HttpSession compatible interface that is
Serializable. Furthermore, a method has been introduce that ask the
HttpSession to decide when 2 sessions are differents. As indicated in the
Javadoc, this method should *not* check all data (such as the last access
time). This in order to reduce the cluster communication (more on this in
the JavaDoc comments of the JMX Service)
Are you going to use this interface to decide if you need to re-replicate
the httpsession on other nodes? If this is the case consider having a
method that returns a list of modified attributes keys, thus enabling you
to replicate only what you actually need to replicate rather then
replicating whole httpsession again. You can also I guess use the method
to check if httpsession is changed i.e:
((changed == true) == attributeChanged.size()0)
Cheers,
Vladimir
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Re: multiple components using log4j causes problems
Hi log4j-user, I was pointed by Aron Kramlik to this mailing list. I'm looking at implementing the RepositorySelector into JBoss. I only found out about this class and 1.2 about 1 hour ago, so apologies if my questions sound naive. I've looked at the javadocs, I don't think this is in the manual yet:-) I like the comment in the javadocs about JBoss/Tomcat, are you making sure we are paying attention? As far as I understand this, we implement RepositorySelector and add this to the LogManager. Our RepositorySelector can then use one repository inside the container and an application configured one when we invoke its methods. Is this correct? We do something like: jbossSelector.setContext(application.getRepository()); invokeApplicationMethod(); jbossSelector.setContext(jbossRepository); Then we need to supply a means to configure application.getRepository() which will probably be jbossRepository when not configured. Do we need to provide a configuration mechanism or is there another way? Final question. I scanned the December/January mail archive but didn't spot this. 1.2 when? Regards, Adrian _ MSN Photos is the easiest way to share and print your photos: http://photos.msn.com/support/worldwide.aspx ___ 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 OILConstants.java OILClientIL.java OILClientILService.java OILServerIL.java OILServerILService.java
User: weave
Date: 02/01/11 12:18:57
Modified:src/main/org/jboss/mq/il/oil OILClientIL.java
OILClientILService.java OILServerIL.java
OILServerILService.java
Added: src/main/org/jboss/mq/il/oil OILConstants.java
Log:
Created a new constants file so that there is only one definition
of the bytecodes for the object communications.
Reworked the OILServerILService class and defined a new inner class
that is used to process client transactions. It makes the logic
in the OILServerILService's run() method easier to follow. The
server logic is in one run() method, the client processing logic
is in another run() method encapsulated in the original class.
Also, added 'vim' tag comments at the end of the files so that vim
will automagically set the appropriate options for editing JBoss
source files
Will propagate the changes to the UIL files when time permits.
Revision ChangesPath
1.6 +7 -13 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.5
retrieving revision 1.6
diff -u -r1.5 -r1.6
--- OILClientIL.java 2002/01/10 13:38:17 1.5
+++ OILClientIL.java 2002/01/11 20:18:57 1.6
@@ -31,20 +31,13 @@
*
* @authorNorbert Lataille ([EMAIL PROTECTED])
* @authorHiram Chirino ([EMAIL PROTECTED])
- * @version $Revision: 1.5 $
+ * @version $Revision: 1.6 $
* @created August 16, 2001
*/
public final class OILClientIL
implements ClientIL,
java.io.Serializable
{
- 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;
@@ -68,7 +61,7 @@
throws Exception
{
checkSocket();
- out.writeByte(CLOSE);
+ out.writeByte(OILConstants.CLOSE);
waitAnswer();
try
{
@@ -93,7 +86,7 @@
throws Exception
{
checkSocket();
- out.writeByte(DELETE_TEMPORARY_DESTINATION);
+ out.writeByte(OILConstants.DELETE_TEMPORARY_DESTINATION);
out.writeObject(dest);
waitAnswer();
}
@@ -108,7 +101,7 @@
throws Exception
{
checkSocket();
- out.writeByte(PONG);
+ out.writeByte(OILConstants.PONG);
out.writeLong(serverTime);
waitAnswer();
}
@@ -128,7 +121,7 @@
checkSocket();
if( trace )
log.trace(Writing request);
- out.writeByte(RECEIVE);
+ out.writeByte(OILConstants.RECEIVE);
out.writeInt(messages.length);
for (int i = 0; i messages.length; ++i)
{
@@ -194,7 +187,7 @@
int val = in.readByte();
switch (val)
{
-case EXCEPTION_CODE:
+case OILConstants.EXCEPTION:
Exception e = (Exception)in.readObject();
throwException = new RemoteException(, e);
break;
@@ -211,3 +204,4 @@
}
}
}
+// vim:expandtab:tabstop=3:shiftwidth=3
1.7 +9 -13 jbossmq/src/main/org/jboss/mq/il/oil/OILClientILService.java
Index: OILClientILService.java
===
RCS file:
/cvsroot/jboss/jbossmq/src/main/org/jboss/mq/il/oil/OILClientILService.java,v
retrieving revision 1.6
retrieving revision 1.7
diff -u -r1.6 -r1.7
--- OILClientILService.java 2002/01/10 13:38:17 1.6
+++ OILClientILService.java 2002/01/11 20:18:57 1.7
@@ -30,7 +30,7 @@
*
* @authorNorbert Lataille ([EMAIL PROTECTED])
* @authorHiram Chirino ([EMAIL PROTECTED])
- * @version $Revision: 1.6 $
+ * @version $Revision: 1.7 $
* @created August 16, 2001
*/
public final class OILClientILService
@@ -39,11 +39,6 @@
{
private final static org.jboss.logging.Logger cat =
org.jboss.logging.Logger.getLogger(OILClientILService.class);
- 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;
-
//the client IL
private OILClientIL clientIL;
@@ -185,7 +180,7 @@
switch (code)
{
- case RECEIVE:
+ case OILConstants.RECEIVE:
int numReceives = in.readInt();
RE: [JBoss-dev] standard for obtaining an org.jboss.logging.Logger instance
It really depends on the class it will be used in. For classes which you expect to be subclasses and where the base class should use the derived classes category, then a protected final Logger created on construction would be used. If you want the base class and the derived class to have separate logging, or rather logging for that class only, then a private static final Logger would be used. The private keeps other classes from using it unintentionally and the final keeps it from being replaced (which you almost never want to do to one of these). The difference between package private and private could be laziness on the coders part, or could be that the logging data is shared between subclasses in the given package only. I would guess it was laziness. The usage of final is debatable, but I feel that it is useful to avoid simple assignment errors and to have a bit more insurance that Loggers won't get null'd or re-categorized. In short, there are a several different ways to get a Logger because the Logger usage varies slightly from class to class. Use the appropriate method for the logging your class needs. --jason -Original Message- From: [EMAIL PROTECTED] [mailto:jboss- [EMAIL PROTECTED]] On Behalf Of Christian Riege Sent: Friday, January 11, 2002 3:54 AM To: [EMAIL PROTECTED] Subject: [JBoss-dev] standard for obtaining an org.jboss.logging.Logger instance hi, is there a standard way of getting the Logger instance in JBoss? the code is sprinkled with at least 4 different ways of doing so, i.e. sometimes its a private variable, sometimes its protected, sometimes its on a package level access, sometimes its declared as 'final', etc ... how about agreeing on a standard way; that would clean up some confusion. regards, christian ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-developmen ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: RE: [JBoss-dev] standard for obtaining an org.jboss.logging.Logger instance
final is good, it gives the hint to the JIT that it won't change, so log.info() can be inlined private helps with this as well, no need for polymorphism! Regards, Adrian __ View this jboss-dev thread in the online forums: http://jboss.org/forums/thread.jsp?forum=66thread=6964 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Autogenerated primary keys etc
JDBC 3.0 is supposed to expose an api for the auto-generated fields in a table. For JAWS integration, it will prob. be better to wait for this. - jim ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Re: multiple components using log4j causes problems
Hi, Does anybody have any comments on this? The idea is to allow applications to different log4j configurations to JBoss. Assuming my analysis is correct. We should be able to do this as an interceptor, just before the relevant ContainerInterceptor. But this means the ContainerInterceptors can't log into the JBoss LoggerRepository. It also means no hit for applications that don't need it. The hard part is getting rid of Category from the codebase so we can use log4j 1.2 which is alpha by the way :-( Regards, Adrian Hi log4j-user, I was pointed by Aron Kramlik to this mailing list. I'm looking at implementing the RepositorySelector into JBoss. I only found out about this class and 1.2 about 1 hour ago, so apologies if my questions sound naive. I've looked at the javadocs, I don't think this is in the manual yet:-) I like the comment in the javadocs about JBoss/Tomcat, are you making sure we are paying attention? As far as I understand this, we implement RepositorySelector and add this to the LogManager. Our RepositorySelector can then use one repository inside the container and an application configured one when we invoke its methods. Is this correct? We do something like: jbossSelector.setContext(application.getRepository()); invokeApplicationMethod(); jbossSelector.setContext(jbossRepository); Then we need to supply a means to configure application.getRepository() which will probably be jbossRepository when not configured. Do we need to provide a configuration mechanism or is there another way? Final question. I scanned the December/January mail archive but didn't spot this. 1.2 when? Regards, Adrian __ __ MSN Photos is the easiest way to share and print your photos: http://photos.msn.com/support/worldwide.aspx ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-dev lopment __ View this jboss-dev thread in the online forums: http://jboss.org/forums/thread.jsp?forum=66thread=6989 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Feature Requests-502573 ] automation
Feature Requests item #502573, was opened at 2002-01-11 17:10 You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=376688aid=502573group_id=22866 Category: JBossServer Group: v2.4.x Status: Open Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: automation Initial Comment: I'd like to have a way to stop and start the jboss server from cron. It would be very helpful to destroy the application and stop the server just before the database is shut down for nightly backup and maintenance. I would also truncate the server.log while the server is down. After the database comes backup, the a script would start the jboss server again. -- You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=376688aid=502573group_id=22866 ___ 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: 231 Successful tests: 39 Errors:184 Failures: 8 [time of test: 12 January 2002 2:44 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] Automated JBoss Testsuite Results
JBoss daily test results SUMMARY Number of tests run: 231 Successful tests: 39 Errors:184 Failures: 8 [time of test: 12 January 2002 3:2 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: 231 Successful tests: 39 Errors:184 Failures: 8 [time of test: 12 January 2002 3:30 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: 231 Successful tests: 39 Errors:184 Failures: 8 [time of test: 12 January 2002 3: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
