Re: [JBoss-dev] Improving MDB behavior in the presence of delivery failures
Maybe it should be handled by JBossMQ. The downside to this is that were
relying on non-spec defined behavior at the JMS provider level to ensure
that
the JBoss MDBs behave well.
- Original Message -
From: "Peter Antman" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Thursday, August 16, 2001 11:30 PM
Subject: Re: [JBoss-dev] Improving MDB behavior in the presence of delivery
failures
>
>
> Hi,
> MDB:s may throw execeptions. They may throw spec compliant exception, if
> I understand the spec correct, that is: an MDB should not thow
> application exception or runtime exceptions, but it may throw system
> exceptions, for example: EJBException.
>
> They may ofcourse throw the not spec compliant exceptions to, even if
> this is a bug it is still something we have to handle.
>
> Two things will basically happen today:
>
> - If container managed the container transaction will be marked for
> rollback.
> - The message will not be acked.
>
> I do agree with the view that we should have some sort of dead queue,
> where faulty messages is everually placed, but I am not that shure that
> this is a MDB thing, to mee it more seems like a JMSProvider thing.
>
> This could be done it two ways (which might be combined)
>
> - JBossMQ has a default dead queue where it places messages that are not
> acked after a configurable amount of tries.
>
> - Each destination may have a configurable dead queue.
>
> It also sees easier for the provider to keep a record of how many times
> it has tried a particular message, than to build that feature into the
> StdServerSession (because that is where the dead queue stuff would have
> to go, because that is where we handle message receipt - to place
> something a a dead queu for the JMSContainerInvoker will mean that it
> have to acknowledge the message, inspite of the transaction beeing
> marked for rollback, but without effecting any other beans that are also
> dependant on the transaction.)
>
> Or does this defeat reliability contract of JMS?
>
> (From the Oreilly Java Messaging Service book, page 125 I get it that
> the normal solution is that the provider provides a "Dead Letter Queue",
> where messages that have expired, or "viewed by the provider as
> udeliverable due to some other reason".
>
> To me this suggests that this is a JBossMQ problem. One way to ease the
> burden on the server would be if messages marked for redelivery would
> first go into an algorithm that slows down delivery. Wait one second,
> try, wiat 10, try, wait 20, try... and eventually place it in a "Dead
> Letter Queue".
>
> Or am I totally of here?
>
> //Peter
>
>
> On 16 Aug, Scott M Stark wrote:
> > The mdb does not have to thrown an exception to cause this behavior. If
it
> > interacts with another ejb that is transacted and that bean rolls the
> > transaction
> > back the msg will get redeliverd. I have a trivally test case that
causes
> > the problem:
> >
> > public void onMessage(Message m)
> > {
> > try
> > {
> > IHome home = ...;
> > home.findByPrimaryKey(null);
> > }
> > catch(Throwable t)
> > {
> > }
> > }
> >
> > The tx will be rolled back by the failed findByPrimaryKey() call which
will
> > cause the msg
> > to be redelivered and were spinning.
> >
> > - Original Message -
> > From: "Hiram Chirino" <[EMAIL PROTECTED]>
> > To: <[EMAIL PROTECTED]>
> > Sent: Thursday, August 16, 2001 6:28 PM
> > Subject: Re: [JBoss-dev] Improving MDB behavior in the presence of
delivery
> > failures
> >
> >
> >>
> >> Per spec the MDB should not be throwing any exceptions.. This would
mean
> >> that it's thier responsibility to put the message to a 'rejected'
queue.
> >>
> >> But I think that is the best solution would be to allow the MDB to be
> >> configured with the 'rejected' queue in it's deployment descriptor. I
> > know
> >> that not everybody will enclose thier MDB code in try { } catch
(Throable
> > e)
> >> {}
> >>
> >>
> >> Regards,
> >> Hiarm
> >>
> >> >From: "Scott M Stark" <[EMAIL PROTECTED]>
> >> >Reply-To: [EMAIL PROTECTED]
> >> >To: <[EMAIL PROTECTED]>
> >> >Subject: [JBoss-dev] Improving MDB behavior in the presence of
delivery
> >> >failures
> >> >Date: Thu, 16 Aug 2001 18:22:23 -0700
> >> >
> >> >Right now there are any number of ways to cause JBoss to spin in a
tight
> >> >loop
> >> >trying to deliver a transacted msg to an mdb due to a problem with
either
> >> >the msg or mdb code that either causes an exception thrown from
> > onMessage()
> >> >or the tx to be rolled back. A trivial example of the latter is to
have
> > an
> >> >mdb
> >> >do a findByPrimaryKey() using a key from the msg that happens to be
null.
> >> >
> >> >One solution would be to have the mdb container fail such msgs after
so
> >> >many delivery attempts. On failure, the msg along with the exception
> > would
> >> >be placed into a error queue associated with the container. An admin
> > would
> >> >have to pull the msg off, fix any data problems and then place
[JBoss-dev] [ jboss-Bugs-451978 ] typo in encoding
Bugs item #451978, was opened at 2001-08-16 23:48 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=376685&aid=451978&group_id=22866 Category: JBossMQ Group: v2.4 BETA (stable) Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: typo in encoding Initial Comment: JBossMQ don't start up with xerces because encoding was set to UTF8 insted of UTF-8. error trace: [JBossMQService] Starting [Default] Cannot start the JMS server ! Parse Error: org.xml.sax.SAXParseException: The encoding "UTF8" is not supported. [Default] org.jbossmq.xml.XElementException: Parse Error: org.xml.sax.SAXParseException: The encoding "UTF8" is not supported. [Default] at org.jbossmq.xml.XElement.createFrom XElement.java:536) [Default] at org.jbossmq.server.StartServer.run (StartServer.java:151) [Default] at org.jbossmq.server.StartServer.start (StartServer.java:72) [Default] at org.jbossmq.server.JBossMQService.startService (JBossMQService.java:66) [Default] at org.jboss.util.ServiceMBeanSupport.start (ServiceMBeanSupport.java:106) [Default] at java.lang.reflect.Method.invoke(Native Method) [Default] at com.sun.management.jmx.MBeanServerImpl.invoke (MBeanServerImpl.java:1628) [Default] at com.sun.management.jmx.MBeanServerImpl.invoke (MBeanServerImpl.java:1523) [Default] at org.jboss.configuration.ConfigurationService$ServicePro xy.invoke(ConfigurationService.java:836) [Default] at $Proxy0.start(Unknown Source) [Default] at org.jboss.util.ServiceControl.start (ServiceControl.java:81) [Default] at java.lang.reflect.Method.invoke(Native Method) [Default] at com.sun.management.jmx.MBeanServerImpl.invoke (MBeanServerImpl.java:1628) [Default] at com.sun.management.jmx.MBeanServerImpl.invoke (MBeanServerImpl.java:1523) [Default] at org.jboss.Main.(Main.java:210) [Default] at org.jboss.Main$1.run(Main.java:116) [Default] at java.security.AccessController.doPrivileged(Native Method) [Default] at org.jboss.Main.main(Main.java:112) [JBossMQService] Started -- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=376685&aid=451978&group_id=22866 ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Improving MDB behavior in the presence of delivery failures
Hi,
MDB:s may throw execeptions. They may throw spec compliant exception, if
I understand the spec correct, that is: an MDB should not thow
application exception or runtime exceptions, but it may throw system
exceptions, for example: EJBException.
They may ofcourse throw the not spec compliant exceptions to, even if
this is a bug it is still something we have to handle.
Two things will basically happen today:
- If container managed the container transaction will be marked for
rollback.
- The message will not be acked.
I do agree with the view that we should have some sort of dead queue,
where faulty messages is everually placed, but I am not that shure that
this is a MDB thing, to mee it more seems like a JMSProvider thing.
This could be done it two ways (which might be combined)
- JBossMQ has a default dead queue where it places messages that are not
acked after a configurable amount of tries.
- Each destination may have a configurable dead queue.
It also sees easier for the provider to keep a record of how many times
it has tried a particular message, than to build that feature into the
StdServerSession (because that is where the dead queue stuff would have
to go, because that is where we handle message receipt - to place
something a a dead queu for the JMSContainerInvoker will mean that it
have to acknowledge the message, inspite of the transaction beeing
marked for rollback, but without effecting any other beans that are also
dependant on the transaction.)
Or does this defeat reliability contract of JMS?
(From the Oreilly Java Messaging Service book, page 125 I get it that
the normal solution is that the provider provides a "Dead Letter Queue",
where messages that have expired, or "viewed by the provider as
udeliverable due to some other reason".
To me this suggests that this is a JBossMQ problem. One way to ease the
burden on the server would be if messages marked for redelivery would
first go into an algorithm that slows down delivery. Wait one second,
try, wiat 10, try, wait 20, try... and eventually place it in a "Dead
Letter Queue".
Or am I totally of here?
//Peter
On 16 Aug, Scott M Stark wrote:
> The mdb does not have to thrown an exception to cause this behavior. If it
> interacts with another ejb that is transacted and that bean rolls the
> transaction
> back the msg will get redeliverd. I have a trivally test case that causes
> the problem:
>
> public void onMessage(Message m)
> {
> try
> {
> IHome home = ...;
> home.findByPrimaryKey(null);
> }
> catch(Throwable t)
> {
> }
> }
>
> The tx will be rolled back by the failed findByPrimaryKey() call which will
> cause the msg
> to be redelivered and were spinning.
>
> - Original Message -
> From: "Hiram Chirino" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Thursday, August 16, 2001 6:28 PM
> Subject: Re: [JBoss-dev] Improving MDB behavior in the presence of delivery
> failures
>
>
>>
>> Per spec the MDB should not be throwing any exceptions.. This would mean
>> that it's thier responsibility to put the message to a 'rejected' queue.
>>
>> But I think that is the best solution would be to allow the MDB to be
>> configured with the 'rejected' queue in it's deployment descriptor. I
> know
>> that not everybody will enclose thier MDB code in try { } catch (Throable
> e)
>> {}
>>
>>
>> Regards,
>> Hiarm
>>
>> >From: "Scott M Stark" <[EMAIL PROTECTED]>
>> >Reply-To: [EMAIL PROTECTED]
>> >To: <[EMAIL PROTECTED]>
>> >Subject: [JBoss-dev] Improving MDB behavior in the presence of delivery
>> >failures
>> >Date: Thu, 16 Aug 2001 18:22:23 -0700
>> >
>> >Right now there are any number of ways to cause JBoss to spin in a tight
>> >loop
>> >trying to deliver a transacted msg to an mdb due to a problem with either
>> >the msg or mdb code that either causes an exception thrown from
> onMessage()
>> >or the tx to be rolled back. A trivial example of the latter is to have
> an
>> >mdb
>> >do a findByPrimaryKey() using a key from the msg that happens to be null.
>> >
>> >One solution would be to have the mdb container fail such msgs after so
>> >many delivery attempts. On failure, the msg along with the exception
> would
>> >be placed into a error queue associated with the container. An admin
> would
>> >have to pull the msg off, fix any data problems and then place the msg
>> >back onto the mdb queue/topic for redelivery.
>> >
>> >Are there any better ways to handle this?
>> >
>> >
>> >
>> >___
>> >Jboss-development mailing list
>> >[EMAIL PROTECTED]
>> >http://lists.sourceforge.net/lists/listinfo/jboss-development
>>
>>
>> _
>> Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp
>>
>>
>> ___
>> Jboss-development mailing list
>> [EMAIL PROTECTED]
>> http://lists.sourceforge.net/lists/listinfo/jboss-developmen
Re: [JBoss-dev] jca changes & loaders
I'll retry with these changes. I'm on a w2k 2x500 P3 with 512Mb memory using the sun jdk 1.3.1 Its probably just a windows/console logging slow down. - Original Message - From: "David Jencks" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Thursday, August 16, 2001 11:03 PM Subject: Re: [JBoss-dev] jca changes & loaders > Hmmm, > > I cleaned up the logging a bit, now there are no messages (except a > "invocation # x" that I haven't found the source of), and checked in > changes. Removing the logging had no effect on the time here. I've run it > 2 1/2 times without deadlock, both completions around 2800 sec. (last one > is still running). > > What kind of system are you on? > > I have rh 7.1, sun jdk 1.3.1, one intel p3 600 mhz, 256 mb memory, and I'm > using Hypersonic. > > Any ideas where to look for the deadlock? > > david jencks > > > > On 2001.08.17 01:07:11 -0400 Scott M Stark wrote: > > By deadlock all I mean is that it is not completing in the time alloted > > for > > the > > test. It was sitting at: > > [junit] 5678.Marc.998012741906:50.0 > > [junit] 5678.Rickard.998012741907:0.0 > > [junit] Time:13266 > > [junit] Avg. time/call(ms):22 > > [junit] Acquire customers > > [junit] Start test. 50 threads, 100 iterations > > > > until the test timed out. With a version of main as of Monday at 23:00 > > obtained using: > > cvs co -D '2001-08-13 23:00' jboss-all > > > > The test runs in 2912 seconds. Maybe its just the logging. > > I can't tell until that is cleaned up. Sure 10,000 tx is a reasonable > > test. > > Stress > > is good. > > > > - Original Message - > > From: "David Jencks" <[EMAIL PROTECTED]> > > To: <[EMAIL PROTECTED]> > > Sent: Thursday, August 16, 2001 8:43 PM > > Subject: Re: [JBoss-dev] jca changes & loaders > > > > > > > I can't argue with the idea that Aaron might possibly have logged > > things a > > > bit heavily, however my banktest completed successfully after 2860.064 > > > seconds. What form did this deadlock take? Is running 50 threads > > through > > > 10 connections with ~10,000 transactions a reasonable unit test? > > > > > > david jencks > > > > > > > > > > > ___ > > Jboss-development mailing list > > [EMAIL PROTECTED] > > http://lists.sourceforge.net/lists/listinfo/jboss-development > > > > > > ___ > Jboss-development mailing list > [EMAIL PROTECTED] > http://lists.sourceforge.net/lists/listinfo/jboss-development > ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Why is SpyMessage throwing NPEs?
Boolean.getBoolean(String x) returns the value of the system property x as a Boolean: new Boolean(System.getProperty(x)) Not very useful for a message property. - Original Message - From: "Jason Dillon" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Thursday, August 16, 2001 10:33 PM Subject: RE: [JBoss-dev] Why is SpyMessage throwing NPEs? > > I haven't looked at that bit of code before, incidentally the method > > Boolean.getBoolean(String s) doesn't do what whoever wrote that piece of > > code thought it did... > > What do you think it is supposed to do? > > --jason > > > ___ > Jboss-development mailing list > [EMAIL PROTECTED] > http://lists.sourceforge.net/lists/listinfo/jboss-development > ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] jca changes & loaders
Hmmm, I cleaned up the logging a bit, now there are no messages (except a "invocation # x" that I haven't found the source of), and checked in changes. Removing the logging had no effect on the time here. I've run it 2 1/2 times without deadlock, both completions around 2800 sec. (last one is still running). What kind of system are you on? I have rh 7.1, sun jdk 1.3.1, one intel p3 600 mhz, 256 mb memory, and I'm using Hypersonic. Any ideas where to look for the deadlock? david jencks On 2001.08.17 01:07:11 -0400 Scott M Stark wrote: > By deadlock all I mean is that it is not completing in the time alloted > for > the > test. It was sitting at: > [junit] 5678.Marc.998012741906:50.0 > [junit] 5678.Rickard.998012741907:0.0 > [junit] Time:13266 > [junit] Avg. time/call(ms):22 > [junit] Acquire customers > [junit] Start test. 50 threads, 100 iterations > > until the test timed out. With a version of main as of Monday at 23:00 > obtained using: > cvs co -D '2001-08-13 23:00' jboss-all > > The test runs in 2912 seconds. Maybe its just the logging. > I can't tell until that is cleaned up. Sure 10,000 tx is a reasonable > test. > Stress > is good. > > - Original Message - > From: "David Jencks" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Sent: Thursday, August 16, 2001 8:43 PM > Subject: Re: [JBoss-dev] jca changes & loaders > > > > I can't argue with the idea that Aaron might possibly have logged > things a > > bit heavily, however my banktest completed successfully after 2860.064 > > seconds. What form did this deadlock take? Is running 50 threads > through > > 10 connections with ~10,000 transactions a reasonable unit test? > > > > david jencks > > > > > > ___ > Jboss-development mailing list > [EMAIL PROTECTED] > http://lists.sourceforge.net/lists/listinfo/jboss-development > > ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jbosspool/src/main/org/jboss/pool/connector/jdbc XAManagedConnectionFactory.java
User: d_jencks
Date: 01/08/16 22:37:35
Modified:src/main/org/jboss/pool/connector/jdbc
XAManagedConnectionFactory.java
Log:
preliminary fix of logging: more logging cleanup soon
Revision ChangesPath
1.3 +23 -22
jbosspool/src/main/org/jboss/pool/connector/jdbc/XAManagedConnectionFactory.java
Index: XAManagedConnectionFactory.java
===
RCS file:
/cvsroot/jboss/jbosspool/src/main/org/jboss/pool/connector/jdbc/XAManagedConnectionFactory.java,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- XAManagedConnectionFactory.java 2001/08/16 03:05:45 1.2
+++ XAManagedConnectionFactory.java 2001/08/17 05:37:35 1.3
@@ -20,6 +20,8 @@
import javax.sql.XADataSource;
import java.sql.Connection; //for transaction isolation constants
+import org.jboss.logging.log4j.JBossCategory;
+
/**
* ManagedConnectionFactory implementation for XADataSource connections. You
* give it an XADataSource, user, and password and it generated connections.
@@ -44,10 +46,15 @@
*
*
* @author Aaron Mulder <[EMAIL PROTECTED]>
- * @version $Revision: 1.2 $
+ * @version $Revision: 1.3 $
*/
public class XAManagedConnectionFactory implements ManagedConnectionFactory {
-private transient PrintWriter logger;
+
+private JBossCategory log =
(JBossCategory)JBossCategory.getInstance(XAManagedConnectionFactory.class);
+
+
+
+//private transient PrintWriter logger; fuggeddaboudit
private transient XADataSource xads;
private String username;
private String password;
@@ -61,11 +68,12 @@
}
public Object createConnectionFactory(ConnectionManager mgr) throws
javax.resource.ResourceException {
DataSource ds = new JDBCDataSource(mgr, this);
-if(logger != null) {
+//ds.setCategory(log);
+/*if(logger != null) {
try {
ds.setLogWriter(logger);
} catch(SQLException e) {}
-}
+}*/
return ds;
}
public Object createConnectionFactory() throws javax.resource.ResourceException
{
@@ -98,7 +106,8 @@
try {
XAConnection con = getXADS().getXAConnection(user, pw);
ManagedConnection mc = new XAManagedConnection(xads, con, user,
transactionIsolation);
-mc.setLogWriter(logger);
+//mc.setCategory();???
+//mc.setLogWriter(logger);
return mc;
} catch(SQLException e) {
throw new ResourceException("Unable to create DB XAConnection: "+e);
@@ -145,10 +154,10 @@
}
public void setLogWriter(PrintWriter writer) throws
javax.resource.ResourceException {
-logger = writer;
+//logger = writer;
}
public PrintWriter getLogWriter() throws javax.resource.ResourceException {
-return logger;
+return null;//logger;
}
private XADataSource getXADS() {
@@ -156,10 +165,10 @@
return xads;
if(xaDataSourceClass != null) {
try {
-logger.println("xaDatasourceClass: " + xaDataSourceClass);
+log.trace("XADatasourceClass: " + xaDataSourceClass);
Class cls = Class.forName(xaDataSourceClass);
xads = (XADataSource)cls.newInstance();
-logger.println("got ds instance");
+log.trace("got DataSource instance");
Properties props = parseProperties();
Iterator it = props.keySet().iterator();
@@ -172,18 +181,13 @@
new Class[]{String.class});
meth.invoke(xads, new Object[]{value});
} catch(Exception e) {
-if(logger != null) {
-logger.println("Unable to set XADataSource property
"+name+"="+value+":");
-}
+log.warn("Unable to set XADataSource property
"+name+"="+value+":");
}
}
return xads;
} catch(Exception e) {
xads = null;
-if(logger != null) {
-logger.println("Unable to create and initialize XADataSource:");
-e.printStackTrace(logger);
-}
+log.warn("Unable to create and initialize XADataSource:", e);
}
} else if(xaDataSourceName != null) {
try {
@@ -192,10 +196,7 @@
return xads;
} catch(Exception e) {
xads = null;
-if(logger != null) {
-logger.println("Unable to
[JBoss-dev] CVS update: jbosspool/src/main/org/jboss/pool/connector BaseConnectionManager.java XAConnectionManager.java
User: d_jencks
Date: 01/08/16 22:37:35
Modified:src/main/org/jboss/pool/connector BaseConnectionManager.java
XAConnectionManager.java
Log:
preliminary fix of logging: more logging cleanup soon
Revision ChangesPath
1.4 +24 -19
jbosspool/src/main/org/jboss/pool/connector/BaseConnectionManager.java
Index: BaseConnectionManager.java
===
RCS file:
/cvsroot/jboss/jbosspool/src/main/org/jboss/pool/connector/BaseConnectionManager.java,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- BaseConnectionManager.java2001/08/16 03:05:45 1.3
+++ BaseConnectionManager.java2001/08/17 05:37:35 1.4
@@ -23,6 +23,8 @@
import org.jboss.pool.ObjectPool;
import org.jboss.pool.PoolParameters;
+import org.jboss.logging.log4j.JBossCategory;
+
/**
* Abstract base class for ConnectionManager implementations. This
* handles connection pools, and provides listener implementations
@@ -39,8 +41,10 @@
protected transient Map handles;
protected transient TransactionManager tm;
protected transient ServerSecurityManager sec;
-protected transient PrintWriter logger;
+private JBossCategory log =
(JBossCategory)JBossCategory.getInstance(BaseConnectionManager.class);
+
+
public BaseConnectionManager() {
pools = new PoolManager();
handles = new HashMap();
@@ -78,14 +82,13 @@
* Sets the logger to use for this ConnectionManager.
*/
public void setLogWriter(PrintWriter logger) {
-this.logger = logger;
}
/**
* Gets the logger used by this ConnectionManager.
*/
public PrintWriter getLogWriter() {
-return logger;
+return null;
}
/**
@@ -138,8 +141,8 @@
handles = null;
tm = null;
sec = null;
-logger.println(getClass().getName()+" shut down.");
-logger = null;
+log.info(getClass().getName()+" shut down.");
+log = null;
}
/**
@@ -248,6 +251,7 @@
// Probably won't be shared, since you usually share based on TX,
// but who knows?
protected class NoTransactionListener extends ConnectionListener {
+private JBossCategory log =
(JBossCategory)JBossCategory.getInstance(NoTransactionListener.class);
public NoTransactionListener(ObjectPool pool, ManagedConnection con) {
super(pool, con);
@@ -303,7 +307,7 @@
try {
con.destroy();
} catch(ResourceException e) {
-e.printStackTrace();
+log.error(e);
}
}
}
@@ -324,6 +328,8 @@
private Transaction trans;
private LocalTransaction local;
+private JBossCategory log =
(JBossCategory)JBossCategory.getInstance(SharedLocalConnectionListener.class);
+
public SharedLocalConnectionListener(ObjectPool pool, ManagedConnection
con, Transaction trans, LocalTransaction local) {
super(pool, con);
this.trans = trans;
@@ -378,10 +384,10 @@
try {
if(status == Status.STATUS_COMMITTED) {
local.commit();
-System.out.println("local transaction committed");
+log.trace("local transaction committed");
} else {
local.rollback();
-System.out.println("local transaction rolled back");
+log.trace("local transaction rolled back");
}
} catch(ResourceException e) {
// Dispose of the connection
@@ -405,9 +411,7 @@
* the connection is destroyed and this listener is cleared.
*/
public void connectionErrorOccurred(ConnectionEvent evt) {
- System.out.println("===");
- System.out.println("Connection Error Occurred");
- System.out.println("===");
+ log.trace("Connection Error Occurred");
try {
local.rollback();
} catch(Exception e) {}
@@ -448,7 +452,7 @@
try {
con.destroy();
} catch(ResourceException e) {
-e.printStackTrace();
+log.error(e);
}
}
}
@@ -473,7 +477,7 @@
try {
con.destroy();
} catch(ResourceException e) {
-e.printStackTrace();
+log.error(e);
}
[JBoss-dev] CVS update: jbosspool/src/main/org/jboss/pool ObjectPool.java
User: d_jencks
Date: 01/08/16 22:37:35
Modified:src/main/org/jboss/pool ObjectPool.java
Log:
preliminary fix of logging: more logging cleanup soon
Revision ChangesPath
1.3 +64 -34jbosspool/src/main/org/jboss/pool/ObjectPool.java
Index: ObjectPool.java
===
RCS file: /cvsroot/jboss/jbosspool/src/main/org/jboss/pool/ObjectPool.java,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- ObjectPool.java 2001/07/02 03:20:08 1.2
+++ ObjectPool.java 2001/08/17 05:37:35 1.3
@@ -9,6 +9,8 @@
import java.util.HashSet;
import java.util.Iterator;
+import org.jboss.logging.log4j.JBossCategory;
+
/**
* A generic object pool. You must provide a PoolObjectFactory (or the class
* of a Java Bean) so the pool knows what kind of objects to create. It has
@@ -38,6 +40,8 @@
static {
collector.start();
}
+ private JBossCategory log =
(JBossCategory)JBossCategory.getInstance(ObjectPool.class);
+
private PoolObjectFactory factory;
private String poolName;
@@ -57,7 +61,7 @@
private int blockingTimeout = -1;// meaning forever
private boolean trackLastUsed = false;
private boolean invalidateOnError = false;
-private PrintWriter logWriter = null;
+// private PrintWriter logWriter = null;
private Object resizeLock = new Object();
/**
@@ -156,7 +160,8 @@
* Gets a log writer used to record pool events.
*/
public PrintWriter getLogWriter() {
-return logWriter;
+return null;
+// return logWriter;
}
/**
@@ -166,9 +171,9 @@
*initialized.
*/
public void setLogWriter(PrintWriter writer) {
-if(objects != null)
+/*if(objects != null)
throw new IllegalStateException(INITIALIZED);
-logWriter = writer;
+logWriter = writer;*/ // ignored
}
/**
@@ -185,7 +190,7 @@
minSize = size;
if(maxSize != 0 && minSize > maxSize) {
maxSize = minSize;
-log("WARNING: pool max size set to "+maxSize+" to stay >= min size");
+log.warn("WARNING: pool max size set to "+maxSize+" to stay >= min
size");
}
}
@@ -215,7 +220,7 @@
maxSize = size;
if(maxSize != 0 && minSize > maxSize) {
minSize = maxSize;
-log("WARNING: pool min size set to "+minSize+" to stay <= max size");
+log.warn("WARNING: pool min size set to "+minSize+" to stay <= max
size");
}
}
@@ -493,7 +498,7 @@
throw new IllegalStateException("Cannot initialize more than once!");
deadObjects = new HashSet();
objects = new HashMap();
-factory.poolStarted(this, logWriter);
+factory.poolStarted(this, null);//logWriter);
lastGC = System.currentTimeMillis();
int max = maxSize <= 0 ? minSize : Math.min(minSize, maxSize);
for(int i=0; i 0) {
@@ -604,8 +616,9 @@
break;
}
}
-
-log("Pool "+this+" couldn't find an object to return!");
+if (log.isTraceEnabled()) {
+log.trace("Pool "+this+" couldn't find an object to return!");
+}
return result;
}
@@ -687,7 +700,7 @@
try {
factory.deleteObject(pooled);
} catch(Exception e) {
-log("Pool "+this+" factory ("+factory.getClass().getName()+"
delete error: "+e);
+log.error("Pool "+this+" factory
("+factory.getClass().getName()+" delete error: "+e);
}
rec.close();
deadObjects.remove(object);
@@ -699,10 +712,14 @@
removed = false;
}
}
-if(removed)
-log("Pool "+this+" destroyed object "+object+".");
-else
-log("Pool "+this+" returned object "+object+" to the pool.");
+if (log.isTraceEnabled()) {
+if(removed) {
+log.trace("Pool "+this+" destroyed object "+object+".");
+}
+else {
+log.trace("Pool "+this+" returned object "+object+" to the pool.");
+}
+}
if(blocking) {
synchronized(this) {
notify();
@@ -802,7 +819,7 @@
try {
factory.deleteObject(pooled);
} catch(Exception e) {
-log("Pool "+this+" factory
("+factory.getClass().getName()+" delete error: "+e);
+log.error("Pool "+this+" factory
("+factory.getClass().getName()
RE: [JBoss-dev] Why is SpyMessage throwing NPEs?
> I haven't looked at that bit of code before, incidentally the method > Boolean.getBoolean(String s) doesn't do what whoever wrote that piece of > code thought it did... What do you think it is supposed to do? --jason ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] CVS update: jbossmq build.xml
Why not? You probably need to create a path and then taskdef it from config.xml (in the configure-hook). --jason On Thu, 16 Aug 2001, Hiram Chirino wrote: > User: chirino > Date: 01/08/16 21:24:58 > > Modified:.build.xml > Log: > jboss-all build did not like the pretty task > > Revision ChangesPath > 1.6 +3 -1 jbossmq/build.xml > > Index: build.xml > === > RCS file: /cvsroot/jboss/jbossmq/build.xml,v > retrieving revision 1.5 > retrieving revision 1.6 > diff -u -r1.5 -r1.6 > --- build.xml 2001/08/17 03:04:01 1.5 > +++ build.xml 2001/08/17 04:24:58 1.6 > @@ -10,7 +10,7 @@ > > > > - > + > > > > @@ -199,12 +199,14 @@ > JavaStyle.jar is from http://plugins.jedit.org/plugins/JavaStyle > *--> > > + > > > > > > > > ___ > Jboss-development mailing list > [EMAIL PROTECTED] > http://lists.sourceforge.net/lists/listinfo/jboss-development > ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Why is SpyMessage throwing NPEs?
I'll do it, and yes, returning the system property for the string value of
the
msg property is not partcularly helpful.
- Original Message -
From: "David Maplesden" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Thursday, August 16, 2001 9:51 PM
Subject: RE: [JBoss-dev] Why is SpyMessage throwing NPEs?
> You are right, it needs to be changed. I can't do it right now (Hiram can
> you??) but if it ain't done by Monday morning I'll fix it up.
>
> I haven't looked at that bit of code before, incidentally the method
> Boolean.getBoolean(String s) doesn't do what whoever wrote that piece of
> code thought it did...
>
> Cheers,
> David Maplesden.
>
> > -Original Message-
> > From: Scott M Stark [mailto:[EMAIL PROTECTED]]
> > Sent: Friday, August 17, 2001 4:53 PM
> > To: [EMAIL PROTECTED]
> > Subject: [JBoss-dev] Why is SpyMessage throwing NPEs?
> >
> >
> > org.jboss.mq.SpyMessage is throwing NPE for null properties:
> >
> >public boolean getBooleanProperty( String name )
> > throws JMSException {
> > Object value = prop.get( name );
> > if ( value == null ) {
> > throw new NullPointerException();
> > }
> >
> > if ( value instanceof Boolean ) {
> > return ( ( Boolean )value ).booleanValue();
> > } else if ( value instanceof String ) {
> > return Boolean.getBoolean( ( String )value );
> > } else {
> > throw new MessageFormatException( "Invalid conversion" );
> > }
> >}
> >
> > Not only is this a pain in the ass, it also is not compliant
> > with my reading
> > of the 1.0.2 spec:
> >
> >
> > 3.5.4 Property Value Conversion
> > Properties support the following conversion table. The marked
> > cases must be
> > supported. The unmarked cases must throw the JMS
> > MessageFormatException.
> > The String to numeric conversions must throw the
> > java.lang.NumberFormatException if the numeric's valueOf()
> > method does not
> > accept the String value as a valid representation. Attempting
> > to read a null
> > value as a Java primitive type must be treated as calling the
> > primitive's
> > corresponding valueOf(String) conversion method with a null value.
> >
> > 3.5.8 Non-existent Properties
> > Getting a property value for a name which has not been set is
> > handled as if
> > the
> > the property exists with a null value.
> >
> >
> >
> >
> > ___
> > Jboss-development mailing list
> > [EMAIL PROTECTED]
> > http://lists.sourceforge.net/lists/listinfo/jboss-development
> >
>
> ___
> Jboss-development mailing list
> [EMAIL PROTECTED]
> http://lists.sourceforge.net/lists/listinfo/jboss-development
>
___
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] jca changes & loaders
By deadlock all I mean is that it is not completing in the time alloted for the test. It was sitting at: [junit] 5678.Marc.998012741906:50.0 [junit] 5678.Rickard.998012741907:0.0 [junit] Time:13266 [junit] Avg. time/call(ms):22 [junit] Acquire customers [junit] Start test. 50 threads, 100 iterations until the test timed out. With a version of main as of Monday at 23:00 obtained using: cvs co -D '2001-08-13 23:00' jboss-all The test runs in 2912 seconds. Maybe its just the logging. I can't tell until that is cleaned up. Sure 10,000 tx is a reasonable test. Stress is good. - Original Message - From: "David Jencks" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Thursday, August 16, 2001 8:43 PM Subject: Re: [JBoss-dev] jca changes & loaders > I can't argue with the idea that Aaron might possibly have logged things a > bit heavily, however my banktest completed successfully after 2860.064 > seconds. What form did this deadlock take? Is running 50 threads through > 10 connections with ~10,000 transactions a reasonable unit test? > > david jencks > ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Why is SpyMessage throwing NPEs?
You are right, it needs to be changed. I can't do it right now (Hiram can
you??) but if it ain't done by Monday morning I'll fix it up.
I haven't looked at that bit of code before, incidentally the method
Boolean.getBoolean(String s) doesn't do what whoever wrote that piece of
code thought it did...
Cheers,
David Maplesden.
> -Original Message-
> From: Scott M Stark [mailto:[EMAIL PROTECTED]]
> Sent: Friday, August 17, 2001 4:53 PM
> To: [EMAIL PROTECTED]
> Subject: [JBoss-dev] Why is SpyMessage throwing NPEs?
>
>
> org.jboss.mq.SpyMessage is throwing NPE for null properties:
>
>public boolean getBooleanProperty( String name )
> throws JMSException {
> Object value = prop.get( name );
> if ( value == null ) {
> throw new NullPointerException();
> }
>
> if ( value instanceof Boolean ) {
> return ( ( Boolean )value ).booleanValue();
> } else if ( value instanceof String ) {
> return Boolean.getBoolean( ( String )value );
> } else {
> throw new MessageFormatException( "Invalid conversion" );
> }
>}
>
> Not only is this a pain in the ass, it also is not compliant
> with my reading
> of the 1.0.2 spec:
>
>
> 3.5.4 Property Value Conversion
> Properties support the following conversion table. The marked
> cases must be
> supported. The unmarked cases must throw the JMS
> MessageFormatException.
> The String to numeric conversions must throw the
> java.lang.NumberFormatException if the numeric's valueOf()
> method does not
> accept the String value as a valid representation. Attempting
> to read a null
> value as a Java primitive type must be treated as calling the
> primitive's
> corresponding valueOf(String) conversion method with a null value.
>
> 3.5.8 Non-existent Properties
> Getting a property value for a name which has not been set is
> handled as if
> the
> the property exists with a null value.
>
>
>
>
> ___
> Jboss-development mailing list
> [EMAIL PROTECTED]
> http://lists.sourceforge.net/lists/listinfo/jboss-development
>
___
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Why is SpyMessage throwing NPEs?
org.jboss.mq.SpyMessage is throwing NPE for null properties:
public boolean getBooleanProperty( String name )
throws JMSException {
Object value = prop.get( name );
if ( value == null ) {
throw new NullPointerException();
}
if ( value instanceof Boolean ) {
return ( ( Boolean )value ).booleanValue();
} else if ( value instanceof String ) {
return Boolean.getBoolean( ( String )value );
} else {
throw new MessageFormatException( "Invalid conversion" );
}
}
Not only is this a pain in the ass, it also is not compliant with my reading
of the 1.0.2 spec:
3.5.4 Property Value Conversion
Properties support the following conversion table. The marked cases must be
supported. The unmarked cases must throw the JMS MessageFormatException.
The String to numeric conversions must throw the
java.lang.NumberFormatException if the numeric's valueOf() method does not
accept the String value as a valid representation. Attempting to read a null
value as a Java primitive type must be treated as calling the primitive's
corresponding valueOf(String) conversion method with a null value.
3.5.8 Non-existent Properties
Getting a property value for a name which has not been set is handled as if
the
the property exists with a null value.
___
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jbossmq build.xml
User: chirino Date: 01/08/16 21:24:58 Modified:.build.xml Log: jboss-all build did not like the pretty task Revision ChangesPath 1.6 +3 -1 jbossmq/build.xml Index: build.xml === RCS file: /cvsroot/jboss/jbossmq/build.xml,v retrieving revision 1.5 retrieving revision 1.6 diff -u -r1.5 -r1.6 --- build.xml 2001/08/17 03:04:01 1.5 +++ build.xml 2001/08/17 04:24:58 1.6 @@ -10,7 +10,7 @@ - + @@ -199,12 +199,14 @@ JavaStyle.jar is from http://plugins.jedit.org/plugins/JavaStyle *--> + ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] CVS Tagging for MQ
Might be a good idea to change the Rel* stuff to JBoss* or jboss_ so that case is predictable. Then other modules and projects could follow suite. Just my opinion though. --jason On Thu, 16 Aug 2001, Scott M Stark wrote: > Releases are .. so it is a 1.0.0 release. Only the > internal tags use 4 digits: Rel_... > > You can't use Rel_xxx tags as these will conflict with the JBoss use of > them so it would have to be RelMQ_1_0_0_0. The final 1.0.0 release > should be tagged with something like JBossMQ_1_0_0 > > - Original Message - > From: "Hiram Chirino" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Sent: Thursday, August 16, 2001 8:22 PM > Subject: [JBoss-dev] CVS Tagging for MQ > > > > Scott... > > > > I wanted to know how I should handle tagging the CVS for the upcomming > > versioning of the MQ module to 1.0 beta. > > > > First of all if I go by the admin howto on the website it would have to be > > 1.0.0.0 beta right?? > > > > And would I tag with Rel_1_0_0_0??? or should I use a RelMQ_1_0_0_0 or > > something like that? > > > > Regards. > > Hiram > > > > > > _ > > Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp > > > > > > ___ > > Jboss-development mailing list > > [EMAIL PROTECTED] > > http://lists.sourceforge.net/lists/listinfo/jboss-development > > > > > ___ > Jboss-development mailing list > [EMAIL PROTECTED] > http://lists.sourceforge.net/lists/listinfo/jboss-development > ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] CVS Tagging for MQ
Releases are .. so it is a 1.0.0 release. Only the internal tags use 4 digits: Rel_... You can't use Rel_xxx tags as these will conflict with the JBoss use of them so it would have to be RelMQ_1_0_0_0. The final 1.0.0 release should be tagged with something like JBossMQ_1_0_0 - Original Message - From: "Hiram Chirino" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Thursday, August 16, 2001 8:22 PM Subject: [JBoss-dev] CVS Tagging for MQ > Scott... > > I wanted to know how I should handle tagging the CVS for the upcomming > versioning of the MQ module to 1.0 beta. > > First of all if I go by the admin howto on the website it would have to be > 1.0.0.0 beta right?? > > And would I tag with Rel_1_0_0_0??? or should I use a RelMQ_1_0_0_0 or > something like that? > > Regards. > Hiram > > > _ > Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp > > > ___ > Jboss-development mailing list > [EMAIL PROTECTED] > http://lists.sourceforge.net/lists/listinfo/jboss-development > ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] jca changes & loaders
I can't argue with the idea that Aaron might possibly have logged things a bit heavily, however my banktest completed successfully after 2860.064 seconds. What form did this deadlock take? Is running 50 threads through 10 connections with ~10,000 transactions a reasonable unit test? david jencks On 2001.08.16 21:57:21 -0400 Scott M Stark wrote: > Start with the fact that the bank unit test deadlocks and the server is > spewing tons > of messages at info level to the console: > > [DefaultDS] Pool > org.jboss.pool.connector.jdbc.JDBCManagedConnectionFactory-1 is full > (10/10)! > [DefaultDS] Pool > org.jboss.pool.connector.jdbc.JDBCManagedConnectionFactory-1 is full > (10/10)! > [DefaultDS] Pool > org.jboss.pool.connector.jdbc.JDBCManagedConnectionFactory-1 [10/10/10] > waiting for a free object > [DefaultDS] Pool > org.jboss.pool.connector.jdbc.JDBCManagedConnectionFactory-1 [10/10/10] > waiting for a free object > [DefaultDS] Pool > org.jboss.pool.connector.jdbc.JDBCManagedConnectionFactory-1 [9/10/10] > returned object org.jboss.pool.connector.jdbc.JDBCManagedConnection@7124 > af to the pool. > [DefaultDS] Pool > org.jboss.pool.connector.jdbc.JDBCManagedConnectionFactory-1 [8/10/10] > gave > out pooled object: org.jboss.pool.connector.jdbc.JDBCManagedConnect > ion@7124af > [DefaultDS] Pool > org.jboss.pool.connector.jdbc.JDBCManagedConnectionFactory-1 [8/10/10] > returned object org.jboss.pool.connector.jdbc.JDBCManagedConnection@44cb > be to the pool. > [Default] local transaction committed > > Now its not clear if the test is failing because it is taking to long to > run > due this absurd level > of logging or there is another problem. David, look at the bank test and > fix > the logging. > > - Original Message - > From: "Jason Dillon" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Sent: Thursday, August 16, 2001 6:01 PM > Subject: [JBoss-dev] jca changes & loaders > > > > It looks like the recent jca & datasource loaders have introduced > > inconsistency in the transaction integrety of the entity system. > > > > I have not yet been able to track this down, but based on an > application > > that was working the day before yesterday, which is now non-functional > after > > more than one run, I would guess that there was a change between now > and > > then that has broken something. > > > > I am seeing problems commiting transactions that invole entity beans. > Where > > a client calls a method, which updates a field, sets a modified flag. > > Sometimes the isModified() method will be called, sometimes it won't. > There > > are a few different beans getting called in a specific order, but I am > not > > seeing some of the latter JDBCCommand* logs showing that the database > is > > actually getting updated. > > > > My application has not changed and will appear to function with small > > message quantities (1) the first time. After running it again it will > not > > work, even though the functionality is performed, the database just > never > > gets up dated and thus my clients are left in the dark (pooling, > waiting > for > > the dogs...). > > > > I think it would be a really good idea if we could stabale and branch a > 2.6 > > before any other changes are added. 2.5 (or pre-3.0 as it is called) > is > > much, much better than 2.4... if we would stop breaking things trying > to > > make it even better. > > > > Personally I would like to see this happen... so I could stop chasing > > around bugs that break my app and actually start working on other JBoss > > bits (like documentation of the build system, integration of the > testsuite > > and other such things). > > > > JBossMQ has come leaps and bounds, so has the locking system. Lets > tidy > up > > what we have then branch and keep going for full RH in 3.0! > > > > It is nice to troll through the code, but I ernestly just want > something > > working. I have been playing "chase the bug" for over a month now. It > is > > getting closer... > > > > If someone knows what is wrong with the tx stuff please let me know. > My > > guess is that David might have a clue =P Or I guess I could have > broken > > something, but I don't think I did. > > > > =| > > > > --jason > > > > > > ___ > > Jboss-development mailing list > > [EMAIL PROTECTED] > > http://lists.sourceforge.net/lists/listinfo/jboss-development > > > > > ___ > Jboss-development mailing list > [EMAIL PROTECTED] > http://lists.sourceforge.net/lists/listinfo/jboss-development > > ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS Tagging for MQ
Scott... I wanted to know how I should handle tagging the CVS for the upcomming versioning of the MQ module to 1.0 beta. First of all if I go by the admin howto on the website it would have to be 1.0.0.0 beta right?? And would I tag with Rel_1_0_0_0??? or should I use a RelMQ_1_0_0_0 or something like that? Regards. Hiram _ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jbossmq/src/main/org/jboss/mq/il/uil/multiplexor DemuxInputStream.java MultiplexorTest.java MuxOutputStream.java SocketMultiplexor.java StreamDemux.java StreamMux.java
User: chirino
Date: 01/08/16 20:04:04
Modified:src/main/org/jboss/mq/il/uil/multiplexor
DemuxInputStream.java MultiplexorTest.java
MuxOutputStream.java SocketMultiplexor.java
StreamDemux.java StreamMux.java
Log:
Used the ejbdoclet pretty task to auto-indent the source files to
the 3 space standard.
Revision ChangesPath
1.2 +131 -126
jbossmq/src/main/org/jboss/mq/il/uil/multiplexor/DemuxInputStream.java
Index: DemuxInputStream.java
===
RCS file:
/cvsroot/jboss/jbossmq/src/main/org/jboss/mq/il/uil/multiplexor/DemuxInputStream.java,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- DemuxInputStream.java 2001/08/11 20:59:14 1.1
+++ DemuxInputStream.java 2001/08/17 03:04:04 1.2
@@ -5,137 +5,142 @@
* See terms of license at gnu.org.
*/
package org.jboss.mq.il.uil.multiplexor;
-
-import java.io.InterruptedIOException;
import java.io.IOException;
import java.io.InputStream;
+import java.io.InterruptedIOException;
+
/**
- * Objects of this class provide and an InputStream
- * from a StreamDemux.
+ * Objects of this class provide and an InputStream from a StreamDemux. Objects
+ * of this class are created by a StreamDemux object.
*
- * Objects of this class are created by a StreamDemux object.
- *
- * @author Hiram Chirino ([EMAIL PROTECTED])
- *
- * @version $Revision: 1.1 $
+ * @author Hiram Chirino ([EMAIL PROTECTED])
+ * @createdAugust 16, 2001
+ * @version$Revision: 1.2 $
*/
class DemuxInputStream extends InputStream {
+
+ StreamDemux streamDemux;
+ shortstreamId;
+ boolean atEOF = false;
+
+ Object bufferMutex = new Object();
+ byte buffer[];
+ shortbufferEndPos;
+ shortbufferStartPos;
+
+ DemuxInputStream( StreamDemux demux, short id ) {
+ streamDemux = demux;
+ streamId = id;
+ buffer = new byte[1000];
+ bufferStartPos = 0;
+ bufferEndPos = 0;
+ }
+
+ public int available()
+ throws IOException {
+ return getBufferFillSize();
+ }
+
+ public void close()
+ throws IOException {
+ streamDemux.closeStream( streamId );
+ }
+
+ public void loadBuffer( byte data[], short dataLength )
+ throws IOException {
+ int freeSize = 0;
+ int dataPos = 0;
+ while ( dataPos < dataLength ) {
+ synchronized ( bufferMutex ) {
+while ( ( freeSize = getBufferFreeSize() ) == 0 ) {
+ try {
+ // Wait till the consumer notifies us he has
+ // removed some data from the buffer.
+ bufferMutex.wait();
+ } catch ( InterruptedException e ) {
+ throw new InterruptedIOException( e.getMessage() );
+ }
+}
+// the buffer should have free space now.
+freeSize = Math.min( freeSize, dataLength - dataPos );
+for ( int i = 0; i < freeSize; i++ ) {
+ buffer[bufferEndPos++] = data[dataPos + i];
+ bufferEndPos = bufferEndPos == buffer.length ? 0 : bufferEndPos;
+}
+ }
+ dataPos += freeSize;
+ // the consumer might be waiting for bytes to come in
+ synchronized ( bufferMutex ) {
+bufferMutex.notify();
+ }
+ }
+ }
+
+ public int read()
+ throws IOException {
+ if ( bufferStartPos == bufferEndPos && atEOF ) {
+ return -1;
+ }
+ synchronized ( bufferMutex ) {
+ // Wait till the buffer has data
+ while ( !atEOF && bufferStartPos == bufferEndPos && !streamDemux.pumpData(
this ) ) {
+try {
+ // Wait till the producer notifies us he has
+ // put some data in the buffer.
+ bufferMutex.wait();
+} catch ( InterruptedException e ) {
+ throw new InterruptedIOException( e.getMessage() );
+}
+ }
+ }
+ // We might break out due to EOF
+ if ( bufferStartPos == bufferEndPos ) {
+ return -1;
+ }
+ // the buffer should have data now.
+ byte result = buffer[bufferStartPos++];
+ bufferStartPos = bufferStartPos == buffer.length ? 0 : bufferStartPos;
+ // the producer might be waiting for free space in the
+ // buffer, we have to notify him.
+ synchronized ( bufferMutex ) {
+ bufferMutex.notify();
+ }
+ return result & 0xff;
+ }
+
+ public int read( byte b[], int off, int len )
+ throws IOException {
+ if ( b
[JBoss-dev] CVS update: jbossmq/src/main/org/jboss/mq/pm PersistenceManager.java Tx.java TxManager.java
User: chirino
Date: 01/08/16 20:04:05
Modified:src/main/org/jboss/mq/pm PersistenceManager.java Tx.java
TxManager.java
Log:
Used the ejbdoclet pretty task to auto-indent the source files to
the 3 space standard.
Revision ChangesPath
1.2 +86 -91jbossmq/src/main/org/jboss/mq/pm/PersistenceManager.java
Index: PersistenceManager.java
===
RCS file: /cvsroot/jboss/jbossmq/src/main/org/jboss/mq/pm/PersistenceManager.java,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- PersistenceManager.java 2001/08/11 20:59:14 1.1
+++ PersistenceManager.java 2001/08/17 03:04:04 1.2
@@ -6,108 +6,103 @@
*/
package org.jboss.mq.pm;
-import javax.jms.JMSException;
-
import java.util.HashMap;
import java.util.Iterator;
import java.util.LinkedList;
-
-
-
-
-
-
+import javax.jms.JMSException;
+import org.jboss.mq.ConnectionToken;
import org.jboss.mq.SpyDestination;
-import org.jboss.mq.xml.XElement;
-import org.jboss.mq.ConnectionToken;
import org.jboss.mq.SpyMessage;
+import org.jboss.mq.xml.XElement;
/**
- * This class allows provides the base for user supplied persistence packages.
- *
- * @author Hiram Chirino ([EMAIL PROTECTED])
- * @author Paul Kendall ([EMAIL PROTECTED])
+ * This class allows provides the base for user supplied persistence packages.
*
- * @version $Revision: 1.1 $
+ * @author Hiram Chirino ([EMAIL PROTECTED])
+ * @author Paul Kendall ([EMAIL PROTECTED])
+ * @createdAugust 16, 2001
+ * @version$Revision: 1.2 $
*/
public interface PersistenceManager {
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- /**
- * Create and return a unique transaction id.
- */
- public abstract Tx createPersistentTx() throws javax.jms.JMSException;
-
- /**
- * Commit the transaction to the persistent store.
- */
- public abstract void commitPersistentTx(Tx txId) throws javax.jms.JMSException;
-
- /**
- * Rollback the transaction.
- */
- public abstract void rollbackPersistentTx(Tx txId) throws
javax.jms.JMSException;
-
-
-
-
-
-
-
-
-
- public TxManager getTxManager();
-
-
-
- /**
- * Remove message from the persistent store.
- * If the message is part of a transaction, txId is not null.
- */
- public abstract void add(SpyMessage message, Tx txId) throws
javax.jms.JMSException;
-
- /**
- * Remove the queue, and all messages in it, from the persistent store
- */
- public abstract void destroyQueue( SpyDestination dest ) throws
javax.jms.JMSException;
-
- /**
- * Initialize the queue.
- */
- public abstract void initQueue( SpyDestination dest ) throws
javax.jms.JMSException;
-
- /**
- * Remove message from the persistent store.
- * If the message is part of a transaction, txId is not null.
- */
- public abstract void remove(SpyMessage message, Tx txId) throws
javax.jms.JMSException;
-
-/**
- *
- * @param server org.jboss.mq.server.JMSServer
- * @exception javax.jms.JMSException The exception description.
- */
-void restore(org.jboss.mq.server.JMSServer server) throws javax.jms.JMSException;
-}
\ No newline at end of file
+ /**
+* Create and return a unique transaction id.
+*
+* @return Description of the Returned Value
+* @exception javax.jms.JMSException Description of Exception
+*/
+ public abstract Tx createPersistentTx()
+ throws javax.jms.JMSException;
+
+ /**
+* Commit the transaction to the persistent store.
+*
+* @param txIdDescription of Parameter
+* @exception javax.jms.JMSException Description of Exception
+*/
+ public abstract void commitPersistentTx( Tx txId )
+ throws javax.jms.JMSException;
+
+ /**
+* Rollback the transaction.
+*
+* @param txIdDescription of Parameter
+* @exception javax.jms.JMSException Description of Exception
+*/
+ public abstract void rollbackPersistentTx( Tx txId )
+ throws javax.jms.JMSException;
+
+
+ public TxManager getTxManager();
+
+
+ /**
+* Remove message from the persistent store. If the message is part of a
+* transaction, txId is not null.
+*
+* @param message Description of Parameter
+* @param txIdDescription of Parameter
+* @exception javax.jms.JMSException Description of Exception
+*/
+ public abstract void add( SpyMessage message, Tx txId )
+ throws javax.jms.JMSException;
+
+ /**
+* Remove the q
[JBoss-dev] CVS update: jbossmq/src/main/org/jboss/mq/referenceable ObjectRefAddr.java SpyConnectionFactoryObjectFactory.java SpyDestinationObjectFactory.java
User: chirino
Date: 01/08/16 20:04:06
Modified:src/main/org/jboss/mq/referenceable ObjectRefAddr.java
SpyConnectionFactoryObjectFactory.java
SpyDestinationObjectFactory.java
Log:
Used the ejbdoclet pretty task to auto-indent the source files to
the 3 space standard.
Revision ChangesPath
1.2 +71 -60jbossmq/src/main/org/jboss/mq/referenceable/ObjectRefAddr.java
Index: ObjectRefAddr.java
===
RCS file:
/cvsroot/jboss/jbossmq/src/main/org/jboss/mq/referenceable/ObjectRefAddr.java,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- ObjectRefAddr.java2001/08/11 20:59:15 1.1
+++ ObjectRefAddr.java2001/08/17 03:04:06 1.2
@@ -5,71 +5,82 @@
* See terms of license at gnu.org.
*/
package org.jboss.mq.referenceable;
-
-import javax.naming.RefAddr;
-
-import java.rmi.MarshalledObject;
-import java.io.ObjectOutputStream;
import java.io.ByteArrayInputStream;
-import java.lang.ref.Reference;
-import java.io.ObjectInputStream;
import java.io.ByteArrayOutputStream;
+import java.io.ObjectInputStream;
+import java.io.ObjectOutputStream;
+import java.lang.ref.Reference;
+
+import java.rmi.MarshalledObject;
+import javax.naming.RefAddr;
+
/**
- * This class is used to store a serializable object in
- * a RefAddr object.
- *
- * @author Scott M Stark ([EMAIL PROTECTED])
- * @author Hiram Chirino ([EMAIL PROTECTED])
- *
- * @version $Revision: 1.1 $
+ * This class is used to store a serializable object in a RefAddr object.
+ *
+ * @author Scott M Stark ([EMAIL PROTECTED])
+ * @author Hiram Chirino ([EMAIL PROTECTED])
+ * @createdAugust 16, 2001
+ * @version$Revision: 1.2 $
*/
public class ObjectRefAddr extends RefAddr {
+ private byte[] serialContent;
+
+
+ /**
+* ObjectRefAddr constructor comment.
+*
+* @param arg1 java.lang.String
+* @param content Description of Parameter
+* @exception javax.naming.NamingException Description of Exception
+*/
+ public ObjectRefAddr( String arg1, Object content )
+ throws javax.naming.NamingException {
+ super( arg1 );
+
+ try {
+ java.rmi.MarshalledObject mo = new MarshalledObject( content );
+ ByteArrayOutputStream baos = new ByteArrayOutputStream();
+ ObjectOutputStream oos = new ObjectOutputStream( baos );
+ oos.writeObject( mo );
+ serialContent = baos.toByteArray();
+ } catch ( java.io.IOException e ) {
+ e.printStackTrace();
+ throw new javax.naming.NamingException( "Could not create a reference: " +
e.getMessage() );
+ }
+ }
+
+ /**
+* getContent method comment.
+*
+* @returnThe Content value
+*/
+ public Object getContent() {
+ return serialContent;
+ }
+
+ /**
+* getContent method comment.
+*
+* @param ref Description of Parameter
+* @param arg1 Description of Parameter
+* @return Description of the Returned
+* Value
+* @exception javax.naming.NamingException Description of Exception
+*/
+ public static Object extractObjectRefFrom( javax.naming.Reference ref, String
arg1 )
+ throws javax.naming.NamingException {
+
+ try {
+ byte[] serialContent = ( byte[] )ref.get( arg1 ).getContent();
+ ByteArrayInputStream bais = new ByteArrayInputStream( serialContent );
+ ObjectInputStream ois = new ObjectInputStream( bais );
+ java.rmi.MarshalledObject mo = ( java.rmi.MarshalledObject
)ois.readObject();
+ return mo.get();
+ } catch ( Exception e ) {
+ throw new javax.naming.NamingException( "Invalid reference. Error: " +
e.getMessage() );
+ }
-
- /**
- * ObjectRefAddr constructor comment.
- * @param arg1 java.lang.String
- */
- public ObjectRefAddr(String arg1, Object content) throws
javax.naming.NamingException {
- super(arg1);
-
- try {
- java.rmi.MarshalledObject mo= new MarshalledObject(content);
- ByteArrayOutputStream baos= new ByteArrayOutputStream();
- ObjectOutputStream oos= new ObjectOutputStream(baos);
- oos.writeObject(mo);
- serialContent= baos.toByteArray();
- } catch ( java.io.IOException e ) {
- e.printStackTrace();
- throw new javax.naming.NamingException("Could not create a
reference: "+e.getMessage());
- }
- }
[JBoss-dev] CVS update: jbossmq/src/main/org/jboss/mq/il ClientIL.java ClientILService.java ServerIL.java ServerILFactory.java ServerILJMXService.java ServerILJMXServiceMBean.java
User: chirino
Date: 01/08/16 20:04:03
Modified:src/main/org/jboss/mq/il ClientIL.java ClientILService.java
ServerIL.java ServerILFactory.java
ServerILJMXService.java
ServerILJMXServiceMBean.java
Log:
Used the ejbdoclet pretty task to auto-indent the source files to
the 3 space standard.
Revision ChangesPath
1.2 +21 -20jbossmq/src/main/org/jboss/mq/il/ClientIL.java
Index: ClientIL.java
===
RCS file: /cvsroot/jboss/jbossmq/src/main/org/jboss/mq/il/ClientIL.java,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- ClientIL.java 2001/08/11 20:59:13 1.1
+++ ClientIL.java 2001/08/17 03:04:03 1.2
@@ -6,29 +6,30 @@
*/
package org.jboss.mq.il;
-
-
-
import org.jboss.mq.ReceiveRequest;
import org.jboss.mq.SpyDestination;
/**
- * This interface defines the methods that the server can make
- * asynchronouly to a client. (ie. to deliver messages)
+ * This interface defines the methods that the server can make asynchronouly to
+ * a client. (ie. to deliver messages)
*
- * @author Hiram Chirino ([EMAIL PROTECTED])
- * @author Norbert Lataille ([EMAIL PROTECTED])
- *
- * @version $Revision: 1.1 $
+ * @author Hiram Chirino ([EMAIL PROTECTED])
+ * @author Norbert Lataille ([EMAIL PROTECTED])
+ * @createdAugust 16, 2001
+ * @version$Revision: 1.2 $
*/
-public interface ClientIL
-{
-
- //One TemporaryDestination has been deleted
- public void deleteTemporaryDestination(SpyDestination dest) throws Exception;
- //The connection is closed
- public void close() throws Exception;
- //A message has arrived for the Connection
- public void receive(ReceiveRequest messages[]) throws Exception;
-
-}
\ No newline at end of file
+public interface ClientIL {
+
+ //One TemporaryDestination has been deleted
+ public void deleteTemporaryDestination( SpyDestination dest )
+ throws Exception;
+
+ //The connection is closed
+ public void close()
+ throws Exception;
+
+ //A message has arrived for the Connection
+ public void receive( ReceiveRequest messages[] )
+ throws Exception;
+
+}
1.2 +49 -44jbossmq/src/main/org/jboss/mq/il/ClientILService.java
Index: ClientILService.java
===
RCS file: /cvsroot/jboss/jbossmq/src/main/org/jboss/mq/il/ClientILService.java,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- ClientILService.java 2001/08/11 20:59:13 1.1
+++ ClientILService.java 2001/08/17 03:04:03 1.2
@@ -6,54 +6,59 @@
*/
package org.jboss.mq.il;
-
-
import org.jboss.mq.Connection;
/**
- * This class manages the lifecycle of an instance of the ClientIL
- *
- * Implementations of this class should have a default constructor.
+ * This class manages the lifecycle of an instance of the ClientIL
+ * Implementations of this class should have a default constructor.
*
- * @author Hiram Chirino ([EMAIL PROTECTED])
- * @version $Revision: 1.1 $
+ * @author Hiram Chirino ([EMAIL PROTECTED])
+ * @createdAugust 16, 2001
+ * @version$Revision: 1.2 $
*/
public interface ClientILService {
- /**
- * After construction, the ClientILService is initialized with
- * a reference to the Connection object and the connection properties.
- *
- */
- public void init(Connection connection, java.util.Properties props) throws
Exception;
-
- /**
- * After initialization, this method may be called to obtain
- * a reference to a ClientIL object. This object will
- * eventually be serialized and sent to the server so that he
- * can invoke methods on connection it was initialized with.
- *
- */
- public ClientIL getClientIL() throws Exception;
-
-
- /**
- * Once started, the ClientIL instance should process all server requests.
- *
- */
- public void start() throws Exception;
-
- /**
- * Once stopped, the ClientIL instance stop processing all server requests.
- *
- if( cr_server != null )
- cr_server.close();
-
- if (cr!=null && cr instanceof java.rmi.Remote) {
-
java.rmi.server.UnicastRemoteObject.unexportObject((java.rmi.Remote)cr, true);
- }
-
- */
-
- public void stop() throws Exception;
-}
\ No newline at end of file
+ /**
+* After construction, the ClientILService is initialized with a reference
+* to the Connection
[JBoss-dev] CVS update: jbossmq/src/main/org/jboss/mq/cluster/transport InvalidConfigurationException.java InvalidStateException.java NodeId.java SerializerUtil.java Transport.java TransportListener.java
User: chirino
Date: 01/08/16 20:04:03
Modified:src/main/org/jboss/mq/cluster/transport
InvalidConfigurationException.java
InvalidStateException.java NodeId.java
SerializerUtil.java Transport.java
TransportListener.java
Log:
Used the ejbdoclet pretty task to auto-indent the source files to
the 3 space standard.
Revision ChangesPath
1.2 +18 -17
jbossmq/src/main/org/jboss/mq/cluster/transport/InvalidConfigurationException.java
Index: InvalidConfigurationException.java
===
RCS file:
/cvsroot/jboss/jbossmq/src/main/org/jboss/mq/cluster/transport/InvalidConfigurationException.java,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- InvalidConfigurationException.java2001/08/11 20:59:12 1.1
+++ InvalidConfigurationException.java2001/08/17 03:04:03 1.2
@@ -9,24 +9,25 @@
import java.lang.Exception;
/**
- * @author Hiram Chirino ([EMAIL PROTECTED])
- *
- * @version $Revision: 1.1 $
+ * @author Hiram Chirino ([EMAIL PROTECTED])
+ * @createdAugust 16, 2001
+ * @version$Revision: 1.2 $
*/
public class InvalidConfigurationException extends Exception {
- /**
- * InvalidConfigurationException constructor comment.
- */
- public InvalidConfigurationException() {
- super();
- }
+ /**
+* InvalidConfigurationException constructor comment.
+*/
+ public InvalidConfigurationException() {
+ super();
+ }
- /**
- * InvalidConfigurationException constructor comment.
- * @param s java.lang.String
- */
- public InvalidConfigurationException(String s) {
- super(s);
- }
-}
\ No newline at end of file
+ /**
+* InvalidConfigurationException constructor comment.
+*
+* @param s java.lang.String
+*/
+ public InvalidConfigurationException( String s ) {
+ super( s );
+ }
+}
1.2 +18 -17
jbossmq/src/main/org/jboss/mq/cluster/transport/InvalidStateException.java
Index: InvalidStateException.java
===
RCS file:
/cvsroot/jboss/jbossmq/src/main/org/jboss/mq/cluster/transport/InvalidStateException.java,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- InvalidStateException.java2001/08/11 20:59:12 1.1
+++ InvalidStateException.java2001/08/17 03:04:03 1.2
@@ -9,24 +9,25 @@
import java.lang.Exception;
/**
- * @author Hiram Chirino ([EMAIL PROTECTED])
- *
- * @version $Revision: 1.1 $
+ * @author Hiram Chirino ([EMAIL PROTECTED])
+ * @createdAugust 16, 2001
+ * @version$Revision: 1.2 $
*/
public class InvalidStateException extends Exception {
- /**
- * InvalidConfigurationException constructor comment.
- */
- public InvalidStateException() {
- super();
- }
+ /**
+* InvalidConfigurationException constructor comment.
+*/
+ public InvalidStateException() {
+ super();
+ }
- /**
- * InvalidConfigurationException constructor comment.
- * @param s java.lang.String
- */
- public InvalidStateException(String s) {
- super(s);
- }
-}
\ No newline at end of file
+ /**
+* InvalidConfigurationException constructor comment.
+*
+* @param s java.lang.String
+*/
+ public InvalidStateException( String s ) {
+ super( s );
+ }
+}
1.2 +4 -5 jbossmq/src/main/org/jboss/mq/cluster/transport/NodeId.java
Index: NodeId.java
===
RCS file:
/cvsroot/jboss/jbossmq/src/main/org/jboss/mq/cluster/transport/NodeId.java,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- NodeId.java 2001/08/11 20:59:12 1.1
+++ NodeId.java 2001/08/17 03:04:03 1.2
@@ -3,10 +3,9 @@
import java.lang.Object;
/**
- *
- * @author Hiram Chirino ([EMAIL PROTECTED])
- *
- * @version $Revision: 1.1 $
+ * @author Hiram Chirino ([EMAIL PROTECTED])
+ * @createdAugust 16, 2001
+ * @version$Revision: 1.2 $
*/
public interface NodeId {
-}
\ No newline at end of file
+}
1.2 +87 -86
jbossmq/src/main/org/jboss/mq/cluster/transport/SerializerUtil.java
Index: SerializerUtil.java
===
RCS file:
/cvsroot/jboss/jbossmq/src/main/org/jboss/mq/cluster/transport/SerializerUtil.java,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- SerializerUtil
[JBoss-dev] CVS update: jbossmq/src/main/org/jboss/mq/il/rmi RMIClientIL.java RMIClientILRemote.java RMIClientILService.java RMIServerIL.java RMIServerILRemote.java RMIServerILService.java RMIServerILServiceMBean.java
User: chirino
Date: 01/08/16 20:04:04
Modified:src/main/org/jboss/mq/il/rmi RMIClientIL.java
RMIClientILRemote.java RMIClientILService.java
RMIServerIL.java RMIServerILRemote.java
RMIServerILService.java
RMIServerILServiceMBean.java
Log:
Used the ejbdoclet pretty task to auto-indent the source files to
the 3 space standard.
Revision ChangesPath
1.2 +43 -41jbossmq/src/main/org/jboss/mq/il/rmi/RMIClientIL.java
Index: RMIClientIL.java
===
RCS file: /cvsroot/jboss/jbossmq/src/main/org/jboss/mq/il/rmi/RMIClientIL.java,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- RMIClientIL.java 2001/08/11 20:59:13 1.1
+++ RMIClientIL.java 2001/08/17 03:04:04 1.2
@@ -8,52 +8,54 @@
import javax.jms.Destination;
import javax.jms.JMSException;
-
-
-
-
-
+import org.jboss.mq.Connection;
+import org.jboss.mq.ReceiveRequest;
import org.jboss.mq.SpyDestination;
-import org.jboss.mq.ReceiveRequest;
import org.jboss.mq.il.ClientIL;
-import org.jboss.mq.Connection;
/**
- * The RMI implementation of the ConnectionReceiver object
- *
- * @author Norbert Lataille ([EMAIL PROTECTED])
- * @author Hiram Chirino ([EMAIL PROTECTED])
- *
- * @version $Revision: 1.1 $
+ * The RMI implementation of the ConnectionReceiver object
+ *
+ * @author Norbert Lataille ([EMAIL PROTECTED])
+ * @author Hiram Chirino ([EMAIL PROTECTED])
+ * @createdAugust 16, 2001
+ * @version$Revision: 1.2 $
*/
public class RMIClientIL extends java.rmi.server.UnicastRemoteObject implements
RMIClientILRemote {
- // A reference to the connection
- Connection connection;
- // Are we running
- boolean stopped= true;
-
- RMIClientIL(Connection c) throws java.rmi.RemoteException {
- connection= c;
- }
-
- public void close() throws Exception {
- if (stopped)
- throw new IllegalStateException("The client IL is stopped");
- connection.asynchClose();
- }
-
- //One TemporaryDestination has been deleted
- public void deleteTemporaryDestination(SpyDestination dest) throws
JMSException {
- if (stopped)
- throw new IllegalStateException("The client IL is stopped");
- connection.asynchDeleteTemporaryDestination(dest);
- }
-
- public void receive(ReceiveRequest messages[]) throws Exception {
- if (stopped)
- throw new IllegalStateException("The client IL is stopped");
- connection.asynchDeliver(messages);
- }
-}
\ No newline at end of file
+ // A reference to the connection
+ Connection connection;
+ // Are we running
+ boolean stopped = true;
+
+ RMIClientIL( Connection c )
+ throws java.rmi.RemoteException {
+ connection = c;
+ }
+
+ public void close()
+ throws Exception {
+ if ( stopped ) {
+ throw new IllegalStateException( "The client IL is stopped" );
+ }
+ connection.asynchClose();
+ }
+
+ //One TemporaryDestination has been deleted
+ public void deleteTemporaryDestination( SpyDestination dest )
+ throws JMSException {
+ if ( stopped ) {
+ throw new IllegalStateException( "The client IL is stopped" );
+ }
+ connection.asynchDeleteTemporaryDestination( dest );
+ }
+
+ public void receive( ReceiveRequest messages[] )
+ throws Exception {
+ if ( stopped ) {
+ throw new IllegalStateException( "The client IL is stopped" );
+ }
+ connection.asynchDeliver( messages );
+ }
+}
1.2 +17 -24jbossmq/src/main/org/jboss/mq/il/rmi/RMIClientILRemote.java
Index: RMIClientILRemote.java
===
RCS file:
/cvsroot/jboss/jbossmq/src/main/org/jboss/mq/il/rmi/RMIClientILRemote.java,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- RMIClientILRemote.java2001/08/11 20:59:13 1.1
+++ RMIClientILRemote.java2001/08/17 03:04:04 1.2
@@ -8,36 +8,29 @@
import javax.jms.Destination;
import javax.jms.JMSException;
-
-
-
-
-
+import org.jboss.mq.Connection;
+import org.jboss.mq.ReceiveRequest;
import org.jboss.mq.SpyDestination;
-import org.jboss.mq.ReceiveRequest;
import org.jboss.mq.il.ClientIL;
-import org.jboss.mq.Connection;
/**
- * The RMI implementation of the ConnectionReceiver object
- *
- * @author Norbert Lataille ([EMAIL PROTECTED])
- * @author Hiram Chirino ([EMAIL PROTECTED])
- *
[JBoss-dev] CVS update: jbossmq build.xml
User: chirino Date: 01/08/16 20:04:01 Modified:.build.xml Log: Used the ejbdoclet pretty task to auto-indent the source files to the 3 space standard. Revision ChangesPath 1.5 +14 -1 jbossmq/build.xml Index: build.xml === RCS file: /cvsroot/jboss/jbossmq/build.xml,v retrieving revision 1.4 retrieving revision 1.5 diff -u -r1.4 -r1.5 --- build.xml 2001/08/12 15:40:44 1.4 +++ build.xml 2001/08/17 03:04:01 1.5 @@ -10,7 +10,7 @@ - + @@ -193,6 +193,19 @@ + + + + + + + + + ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jbossmq/src/etc/.Refactory pretty.settings
User: chirino
Date: 01/08/16 20:04:01
Added: src/etc/.Refactory pretty.settings
Log:
Used the ejbdoclet pretty task to auto-indent the source files to
the 3 space standard.
Revision ChangesPath
1.1 jbossmq/src/etc/.Refactory/pretty.settings
Index: pretty.settings
===
run.descr=Main processing method for the {1} {2}
junit.suite.return.descr=The test suite
main.param.descr=The command line arguments
reformat.comments=true
keyword.space=true
block.style=C
field.descr=
singleline.comment.ownline=true
javadoc.id.lineup=true
method.descr=
junit.test.descr=A unit test for JUnit
catch.start.line=false
setter.param.descr=The new {0} value
class.descr=
field.minimum=none
getter.descr=Gets the {0} attribute of the {1} {2}
indent=3
singleline.comment.incrementalindent=0
singleline.comment.absoluteindent=0
method.block.style=C
end.line=NL
getter.return.descr=The {0} value
sort.top=true
main.descr=The main program for the {1} {2}
surprise.return=double
javadoc.indent=2
interface.descr=
param.descr=Description of Parameter
javadoc.wordwrap.min=60
indent.char=space
junit.setUp.descr=The JUnit setup method
junit.suite.descr=A unit test suite for JUnit
lines.between=1
adder.param.descr=The feature to be added to the {0} attribute
space.before.javadoc=true
return.descr=Description of the Returned Value
constructor.descr=Constructor for the {0} object
created.descr={1}
field.tags=
field.name.indent=20
junit.tearDown.descr=The teardown method for JUnit
throws.newline=true
setter.descr=Sets the {0} attribute of the {1} {2}
class.tags=author,created
sort.4=Method(setter,getter,other)
expr.space=true
sort.3=Protection(public)
sort.2=Class(Instance,Static)
exception.descr=Description of Exception
sort.1=Type(Field,Constructor,Method,NestedClass,NestedInterface,Initializer)
cast.space=false
singleline.comment.indentstyle.shared=incremental
javadoc.star=2
since.descr=0.95
version=2.8
singleline.comment.indentstyle.ownline=code
class.minimum=all
adder.descr=Adds a feature to the {0} attribute of the {1} {2}
date.required=true
keep.all.javadoc=false
method.minimum=none
javadoc.wordwrap.max=80
method.tags=param,return,exception
___
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jbossmq/src/main/org/jboss/mq/il/jvm JVMClientIL.java JVMClientILService.java JVMServerIL.java JVMServerILFactory.java JVMServerILService.java JVMServerILServiceMBean.java
User: chirino
Date: 01/08/16 20:04:04
Modified:src/main/org/jboss/mq/il/jvm JVMClientIL.java
JVMClientILService.java JVMServerIL.java
JVMServerILFactory.java JVMServerILService.java
JVMServerILServiceMBean.java
Log:
Used the ejbdoclet pretty task to auto-indent the source files to
the 3 space standard.
Revision ChangesPath
1.2 +42 -41jbossmq/src/main/org/jboss/mq/il/jvm/JVMClientIL.java
Index: JVMClientIL.java
===
RCS file: /cvsroot/jboss/jbossmq/src/main/org/jboss/mq/il/jvm/JVMClientIL.java,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- JVMClientIL.java 2001/08/11 20:59:13 1.1
+++ JVMClientIL.java 2001/08/17 03:04:03 1.2
@@ -8,52 +8,53 @@
import javax.jms.Destination;
import javax.jms.JMSException;
-
-
-
-
-
+import org.jboss.mq.Connection;
+import org.jboss.mq.ReceiveRequest;
import org.jboss.mq.SpyDestination;
-import org.jboss.mq.ReceiveRequest;
import org.jboss.mq.il.ClientIL;
-import org.jboss.mq.Connection;
/**
- * The RMI implementation of the ConnectionReceiver object
- *
- * @author Norbert Lataille ([EMAIL PROTECTED])
- * @author Hiram Chirino ([EMAIL PROTECTED])
- *
- * @version $Revision: 1.1 $
+ * The RMI implementation of the ConnectionReceiver object
+ *
+ * @author Norbert Lataille ([EMAIL PROTECTED])
+ * @author Hiram Chirino ([EMAIL PROTECTED])
+ * @createdAugust 16, 2001
+ * @version$Revision: 1.2 $
*/
public class JVMClientIL implements ClientIL {
- // A reference to the connection
- Connection connection;
- // Are we running
- boolean stopped= true;
-
- JVMClientIL(Connection c) {
- connection= c;
- }
-
- public void close() throws Exception {
- if (stopped)
- throw new IllegalStateException("The client IL is stopped");
- connection.asynchClose();
- }
-
- //One TemporaryDestination has been deleted
- public void deleteTemporaryDestination(SpyDestination dest) throws
JMSException {
- if (stopped)
- throw new IllegalStateException("The client IL is stopped");
- connection.asynchDeleteTemporaryDestination(dest);
- }
-
- public void receive(ReceiveRequest messages[]) throws Exception {
- if (stopped)
- throw new IllegalStateException("The client IL is stopped");
- connection.asynchDeliver(messages);
- }
-}
\ No newline at end of file
+ // A reference to the connection
+ Connection connection;
+ // Are we running
+ boolean stopped = true;
+
+ JVMClientIL( Connection c ) {
+ connection = c;
+ }
+
+ public void close()
+ throws Exception {
+ if ( stopped ) {
+ throw new IllegalStateException( "The client IL is stopped" );
+ }
+ connection.asynchClose();
+ }
+
+ //One TemporaryDestination has been deleted
+ public void deleteTemporaryDestination( SpyDestination dest )
+ throws JMSException {
+ if ( stopped ) {
+ throw new IllegalStateException( "The client IL is stopped" );
+ }
+ connection.asynchDeleteTemporaryDestination( dest );
+ }
+
+ public void receive( ReceiveRequest messages[] )
+ throws Exception {
+ if ( stopped ) {
+ throw new IllegalStateException( "The client IL is stopped" );
+ }
+ connection.asynchDeliver( messages );
+ }
+}
1.2 +52 -48jbossmq/src/main/org/jboss/mq/il/jvm/JVMClientILService.java
Index: JVMClientILService.java
===
RCS file:
/cvsroot/jboss/jbossmq/src/main/org/jboss/mq/il/jvm/JVMClientILService.java,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- JVMClientILService.java 2001/08/11 20:59:13 1.1
+++ JVMClientILService.java 2001/08/17 03:04:03 1.2
@@ -8,61 +8,65 @@
import javax.jms.Destination;
import javax.jms.JMSException;
-
-
-
-
-
-
+import org.jboss.mq.Connection;
+import org.jboss.mq.ReceiveRequest;
import org.jboss.mq.SpyDestination;
-import org.jboss.mq.ReceiveRequest;
import org.jboss.mq.il.ClientIL;
-import org.jboss.mq.Connection;
import org.jboss.mq.il.ClientILService;
/**
- * The RMI implementation of the ConnectionReceiver object
- *
- * @author Norbert Lataille ([EMAIL PROTECTED])
- * @author Hiram Chirino ([EMAIL PROTECTED])
- *
- * @version $Revision: 1.1 $
+ * The RMI implementation of the ConnectionReceiver object
+ *
+ * @author Nor
[JBoss-dev] CVS update: jbossmq/src/etc/.Refactory - New directory
User: chirino Date: 01/08/16 20:02:40 jbossmq/src/etc/.Refactory - New directory ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] jca changes & loaders
Hi, Sorry I broke your app, I was kind of worried when I realized the xa rar had never been assembled, but noone said "no". Is there some usable or automatic way to mark in cvs all the changes that go together like the ones I made? Can you provide any more details of what's going on? Did you get the Oracle XA driver to work? Are you using mdb? Is 2pc happening? One difference between the XADataSourceLoader connection management and the xa-rar management is that the old way routed all work on one transaction to the same managed connection, no matter how many beans were in the transaction. The jca stuff does not do this, whenever you need to do some work it gets a random connection, calls start (on the XAResource), does the work, calls end. This for instance breaks the XADataSourceImpl which has a check that when you call start, and the connection has done work on some transaction, you need to be supplying that same xid. The last time I looked I couldn't find the spec saying we can be calling start(xid) with any xid, but I did find a part saying the tm can call commit on any xaresource, not necessarily one any work was done on. I found this problem trying the banktest with the xa-rar using XADataSourceImpl as the "xa" driver. The problem occurred in testMultiThread and TestMultiTest2 after some time, but for me pretty consistently in each run. What happens when you run banktest with your Oracle driver? Maybe it has a similar problem. Dr. Jung was proposing a ConnectionManager to provide 2pc but send all work in one transaction to one ManagedConnection, maybe that would help here too. If there's any other way I can help let me know. david jencks On 2001.08.16 21:01:52 -0400 Jason Dillon wrote: > It looks like the recent jca & datasource loaders have introduced > inconsistency in the transaction integrety of the entity system. > > I have not yet been able to track this down, but based on an application > that was working the day before yesterday, which is now non-functional > after > more than one run, I would guess that there was a change between now and > then that has broken something. > > I am seeing problems commiting transactions that invole entity beans. > Where > a client calls a method, which updates a field, sets a modified flag. > Sometimes the isModified() method will be called, sometimes it won't. > There > are a few different beans getting called in a specific order, but I am > not > seeing some of the latter JDBCCommand* logs showing that the database is > actually getting updated. > > My application has not changed and will appear to function with small > message quantities (1) the first time. After running it again it will > not > work, even though the functionality is performed, the database just never > gets up dated and thus my clients are left in the dark (pooling, waiting > for > the dogs...). > > I think it would be a really good idea if we could stabale and branch a > 2.6 > before any other changes are added. 2.5 (or pre-3.0 as it is called) is > much, much better than 2.4... if we would stop breaking things trying to > make it even better. > > Personally I would like to see this happen... so I could stop chasing > around bugs that break my app and actually start working on other JBoss > bits (like documentation of the build system, integration of the > testsuite > and other such things). > > JBossMQ has come leaps and bounds, so has the locking system. Lets tidy > up > what we have then branch and keep going for full RH in 3.0! > > It is nice to troll through the code, but I ernestly just want something > working. I have been playing "chase the bug" for over a month now. It > is > getting closer... > > If someone knows what is wrong with the tx stuff please let me know. My > guess is that David might have a clue =P Or I guess I could have broken > something, but I don't think I did. > > =| > > --jason > > > ___ > Jboss-development mailing list > [EMAIL PROTECTED] > http://lists.sourceforge.net/lists/listinfo/jboss-development > > ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Improving MDB behavior in the presence of delivery failures
Scott M Stark wrote: > Right now there are any number of ways to cause JBoss to spin in a tight > loop > trying to deliver a transacted msg to an mdb due to a problem with either > the msg or mdb code that either causes an exception thrown from onMessage() > or the tx to be rolled back. A trivial example of the latter is to have an > mdb > do a findByPrimaryKey() using a key from the msg that happens to be null. > > One solution would be to have the mdb container fail such msgs after so > many delivery attempts. On failure, the msg along with the exception would > be placed into a error queue associated with the container. An admin would > have to pull the msg off, fix any data problems and then place the msg > back onto the mdb queue/topic for redelivery. > > Are there any better ways to handle this? a 'dead-letter' queue is a pretty usual way of handling this (that's what MQ-Series does, IIRC). Hiram's suggestion to make the queue configurable is a good one, too. -danch ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] resource logging
For the Minerva resource adapter jdbc wrappers, I think this is an
excellent idea.
You've replaced way more logging code than I have, I'll be happy to do it
especially if you can give me a model to copy, otherwise if you want to
that's fine too.
There is no doubt about the need to replace logging in the actual jboss
framework components with log4j also, I guess I should have done it earlier
this week. Again - you or me?
david jencks
On 2001.08.16 21:16:51 -0400 Jason Dillon wrote:
> What are we going todo about logging from resource adapters and such? It
> looks like there is alot of stuff that:
>
> if (logger != null) {
> // some use full message
> }
>
> Or it will not log anything at all... even error conditions. It also
> looks
> like there is alot of System. usage too, which just plain sucks.
>
> There was some email with Peter a while ago on the jms ra and logging,
> which
> we concluded that we should log4j and more or less ignore the
> javax.resource.* PrintWriter logging crap.
>
> I have not done anything about that yet, since I have been on this bug
> hunt, which lead me to find even more cases like this.
>
> The issues as I see them are:
>
> 1) The current javax.resource.* logging usage of a PrintWriter sucks,
> really, really, really sucks.
>
> 2) Such a crappy loging mechanism is forcing folks to use adhoc logging
> semantics, which is making it hard to debug problems when they arise.
> Worse yet it is "hiding" problems by some code simply not logging
> anything if it doesn't have a PrintWriter.
>
> 3) Did I mention that PrintWriter for logging sucks... oh ya I did...
> but
> it is so bad that I want to list it again.
>
> I am sure there are more issues, but these suffice for the question at
> hand,
> which is what are we going to do about this?
>
> I suggest dropping the PrintWriter Logger() fluff (replaced by
> empty methods) and implement all logging with Log4j. I think that this
> is the best bet in the shortterm to get a really stable and functional
> product out there. It will limit how the ra stuff will plug into other
> servers, but we really want folks to use JBoss, not just canabalize the
> components.
>
> Long term we want to be spec compliant, and perhaps the spec will be
> improvded with respect to logging in the next release.
>
> My conclusion is that being spec compliant and using PrintWriters for
> logging is more harmful than anything else with respect to the rapid
> growth,
> stability and feature set of JBoss.
>
> Let us drop it and use Log4j.
>
> --jason
>
>
> ___
> Jboss-development mailing list
> [EMAIL PROTECTED]
> http://lists.sourceforge.net/lists/listinfo/jboss-development
>
>
___
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] resource logging
Well, the current level of logging coming from the datasource layer is
absurd. If this is
due to PrintWriter interface screw the spec. Unless someone has called
setLogger the
JBoss RAs should be defaulting to log4j.
- Original Message -
From: "Jason Dillon" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Thursday, August 16, 2001 6:16 PM
Subject: [JBoss-dev] resource logging
> What are we going todo about logging from resource adapters and such? It
> looks like there is alot of stuff that:
>
> if (logger != null) {
> // some use full message
> }
>
> Or it will not log anything at all... even error conditions. It also
looks
> like there is alot of System. usage too, which just plain sucks.
>
> There was some email with Peter a while ago on the jms ra and logging,
which
> we concluded that we should log4j and more or less ignore the
> javax.resource.* PrintWriter logging crap.
>
> I have not done anything about that yet, since I have been on this bug
> hunt, which lead me to find even more cases like this.
>
> The issues as I see them are:
>
> 1) The current javax.resource.* logging usage of a PrintWriter sucks,
> really, really, really sucks.
>
> 2) Such a crappy loging mechanism is forcing folks to use adhoc logging
> semantics, which is making it hard to debug problems when they arise.
> Worse yet it is "hiding" problems by some code simply not logging
> anything if it doesn't have a PrintWriter.
>
> 3) Did I mention that PrintWriter for logging sucks... oh ya I did... but
> it is so bad that I want to list it again.
>
> I am sure there are more issues, but these suffice for the question at
hand,
> which is what are we going to do about this?
>
> I suggest dropping the PrintWriter Logger() fluff (replaced by
> empty methods) and implement all logging with Log4j. I think that this
> is the best bet in the shortterm to get a really stable and functional
> product out there. It will limit how the ra stuff will plug into other
> servers, but we really want folks to use JBoss, not just canabalize the
> components.
>
> Long term we want to be spec compliant, and perhaps the spec will be
> improvded with respect to logging in the next release.
>
> My conclusion is that being spec compliant and using PrintWriters for
> logging is more harmful than anything else with respect to the rapid
growth,
> stability and feature set of JBoss.
>
> Let us drop it and use Log4j.
>
> --jason
>
>
> ___
> Jboss-development mailing list
> [EMAIL PROTECTED]
> http://lists.sourceforge.net/lists/listinfo/jboss-development
>
___
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jbossmq/src/main/org/jboss/mq SpyMessageConsumer.java
User: pkendall
Date: 01/08/16 18:52:33
Modified:src/main/org/jboss/mq SpyMessageConsumer.java
Log:
Handle runtime exceptions in message listener code
Revision ChangesPath
1.5 +53 -46jbossmq/src/main/org/jboss/mq/SpyMessageConsumer.java
Index: SpyMessageConsumer.java
===
RCS file: /cvsroot/jboss/jbossmq/src/main/org/jboss/mq/SpyMessageConsumer.java,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -r1.4 -r1.5
--- SpyMessageConsumer.java 2001/08/17 01:29:34 1.4
+++ SpyMessageConsumer.java 2001/08/17 01:52:33 1.5
@@ -29,7 +29,7 @@
* @author Hiram Chirino ([EMAIL PROTECTED])
* @author David Maplesden ([EMAIL PROTECTED])
*
- * @version $Revision: 1.4 $
+ * @version $Revision: 1.5 $
*/
public class SpyMessageConsumer implements MessageConsumer, SpyConsumer, Runnable {
@@ -308,60 +308,67 @@
SpyMessage mes = null;
try{
outer: while(true){
- //get Message
- while(mes == null){
- mes = session.connection.receive(subscription,0);
- if(mes == null){
- synchronized(messages){
- waitingForMessage = true;
- while(messages.isEmpty() && !closed){
- try{ messages.wait(); }catch(InterruptedException e){}
+ //get Message
+ while(mes == null){
+ mes = session.connection.receive(subscription,0);
+ if(mes == null){
+ synchronized(messages){
+ waitingForMessage = true;
+ while(messages.isEmpty() && !closed){
+ try{ messages.wait();
}catch(InterruptedException e){}
+ }
+ if(closed){
+ waitingForMessage = false;
+ break outer;
+ }
+ mes =
(SpyMessage)messages.removeFirst();
+ waitingForMessage = false;
+ }
}
- if(closed){
- waitingForMessage = false;
- break outer;
+ mes.session = session;
+ if (mes.isOutdated()) {
+ //Drop message (it has expired)
+ mes.doAcknowledge();
+ mes = null;
}
- mes = (SpyMessage)messages.removeFirst();
- waitingForMessage = false;
- }
}
- mes.session = session;
- if (mes.isOutdated()) {
- //Drop message (it has expired)
- mes.doAcknowledge();
- mes = null;
- }
- }
- MessageListener thisListener;
- synchronized(stateLock){
- if(!isListening()){
- //send NACK cause we have closed listener
- if(mes != null){
- session.connection.send(
mes.getAcknowledgementRequest(false) );
+ MessageListener thisListener;
+ synchronized(stateLock){
+ if(!isListening()){
+ //send NACK cause we have closed listener
+ if(mes != null){
+ session.connection.send(
mes.getAcknowledgementRequest(false) );
+ }
+ //this thread is about to die, so we will need
a new one if a new listener is added
+ listenerThread = null;
+ mes = null;
+ break;
+ }
+ thisListener = messageListener;
}
- //this thread is about to die, so we will need a new one if a
new listener is added
- listenerThread = null;
- mes = null;
- break;
+ Message me
Re: [JBoss-dev] Improving MDB behavior in the presence of delivery failures
The mdb does not have to thrown an exception to cause this behavior. If it
interacts with another ejb that is transacted and that bean rolls the
transaction
back the msg will get redeliverd. I have a trivally test case that causes
the problem:
public void onMessage(Message m)
{
try
{
IHome home = ...;
home.findByPrimaryKey(null);
}
catch(Throwable t)
{
}
}
The tx will be rolled back by the failed findByPrimaryKey() call which will
cause the msg
to be redelivered and were spinning.
- Original Message -
From: "Hiram Chirino" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Thursday, August 16, 2001 6:28 PM
Subject: Re: [JBoss-dev] Improving MDB behavior in the presence of delivery
failures
>
> Per spec the MDB should not be throwing any exceptions.. This would mean
> that it's thier responsibility to put the message to a 'rejected' queue.
>
> But I think that is the best solution would be to allow the MDB to be
> configured with the 'rejected' queue in it's deployment descriptor. I
know
> that not everybody will enclose thier MDB code in try { } catch (Throable
e)
> {}
>
>
> Regards,
> Hiarm
>
> >From: "Scott M Stark" <[EMAIL PROTECTED]>
> >Reply-To: [EMAIL PROTECTED]
> >To: <[EMAIL PROTECTED]>
> >Subject: [JBoss-dev] Improving MDB behavior in the presence of delivery
> >failures
> >Date: Thu, 16 Aug 2001 18:22:23 -0700
> >
> >Right now there are any number of ways to cause JBoss to spin in a tight
> >loop
> >trying to deliver a transacted msg to an mdb due to a problem with either
> >the msg or mdb code that either causes an exception thrown from
onMessage()
> >or the tx to be rolled back. A trivial example of the latter is to have
an
> >mdb
> >do a findByPrimaryKey() using a key from the msg that happens to be null.
> >
> >One solution would be to have the mdb container fail such msgs after so
> >many delivery attempts. On failure, the msg along with the exception
would
> >be placed into a error queue associated with the container. An admin
would
> >have to pull the msg off, fix any data problems and then place the msg
> >back onto the mdb queue/topic for redelivery.
> >
> >Are there any better ways to handle this?
> >
> >
> >
> >___
> >Jboss-development mailing list
> >[EMAIL PROTECTED]
> >http://lists.sourceforge.net/lists/listinfo/jboss-development
>
>
> _
> Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp
>
>
> ___
> Jboss-development mailing list
> [EMAIL PROTECTED]
> http://lists.sourceforge.net/lists/listinfo/jboss-development
>
___
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] jca changes & loaders
Start with the fact that the bank unit test deadlocks and the server is spewing tons of messages at info level to the console: [DefaultDS] Pool org.jboss.pool.connector.jdbc.JDBCManagedConnectionFactory-1 is full (10/10)! [DefaultDS] Pool org.jboss.pool.connector.jdbc.JDBCManagedConnectionFactory-1 is full (10/10)! [DefaultDS] Pool org.jboss.pool.connector.jdbc.JDBCManagedConnectionFactory-1 [10/10/10] waiting for a free object [DefaultDS] Pool org.jboss.pool.connector.jdbc.JDBCManagedConnectionFactory-1 [10/10/10] waiting for a free object [DefaultDS] Pool org.jboss.pool.connector.jdbc.JDBCManagedConnectionFactory-1 [9/10/10] returned object org.jboss.pool.connector.jdbc.JDBCManagedConnection@7124 af to the pool. [DefaultDS] Pool org.jboss.pool.connector.jdbc.JDBCManagedConnectionFactory-1 [8/10/10] gave out pooled object: org.jboss.pool.connector.jdbc.JDBCManagedConnect ion@7124af [DefaultDS] Pool org.jboss.pool.connector.jdbc.JDBCManagedConnectionFactory-1 [8/10/10] returned object org.jboss.pool.connector.jdbc.JDBCManagedConnection@44cb be to the pool. [Default] local transaction committed Now its not clear if the test is failing because it is taking to long to run due this absurd level of logging or there is another problem. David, look at the bank test and fix the logging. - Original Message - From: "Jason Dillon" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Thursday, August 16, 2001 6:01 PM Subject: [JBoss-dev] jca changes & loaders > It looks like the recent jca & datasource loaders have introduced > inconsistency in the transaction integrety of the entity system. > > I have not yet been able to track this down, but based on an application > that was working the day before yesterday, which is now non-functional after > more than one run, I would guess that there was a change between now and > then that has broken something. > > I am seeing problems commiting transactions that invole entity beans. Where > a client calls a method, which updates a field, sets a modified flag. > Sometimes the isModified() method will be called, sometimes it won't. There > are a few different beans getting called in a specific order, but I am not > seeing some of the latter JDBCCommand* logs showing that the database is > actually getting updated. > > My application has not changed and will appear to function with small > message quantities (1) the first time. After running it again it will not > work, even though the functionality is performed, the database just never > gets up dated and thus my clients are left in the dark (pooling, waiting for > the dogs...). > > I think it would be a really good idea if we could stabale and branch a 2.6 > before any other changes are added. 2.5 (or pre-3.0 as it is called) is > much, much better than 2.4... if we would stop breaking things trying to > make it even better. > > Personally I would like to see this happen... so I could stop chasing > around bugs that break my app and actually start working on other JBoss > bits (like documentation of the build system, integration of the testsuite > and other such things). > > JBossMQ has come leaps and bounds, so has the locking system. Lets tidy up > what we have then branch and keep going for full RH in 3.0! > > It is nice to troll through the code, but I ernestly just want something > working. I have been playing "chase the bug" for over a month now. It is > getting closer... > > If someone knows what is wrong with the tx stuff please let me know. My > guess is that David might have a clue =P Or I guess I could have broken > something, but I don't think I did. > > =| > > --jason > > > ___ > Jboss-development mailing list > [EMAIL PROTECTED] > http://lists.sourceforge.net/lists/listinfo/jboss-development > ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] jbossmq module alias breaks access to previous branches
Ok I've changed the standalone MQ module name to 'jboss-qm'. So to all you mq folks working on the head branch... checkout the standalone server using the jboss-mq modules name... The jbossmq module only contains the sources... no build system is included. This should also fix Scott's problem. Regards, Hiram >From: Jason Dillon <[EMAIL PROTECTED]> >Reply-To: [EMAIL PROTECTED] >To: <[EMAIL PROTECTED]> >Subject: Re: [JBoss-dev] jbossmq module alias breaks access to previous >branches >Date: Thu, 16 Aug 2001 15:36:08 -0700 (PDT) > >On Thu, 16 Aug 2001, Scott M Stark wrote: > > Due to the changes to the CVSROOT/modules file one can't checkout the >2.4 branch > > of the jbossmq source using the previous syntax. The 2.4 branch needs to >be checked > > out using: > > cvs co -r Branch_2_4 -P _jboss_messaging > > which creates a messaging rather than jbossmq directory. > > > > Why not leave jbossmq as the legacy cvs module and introduce a new >jboss-mq > > module so as not to confuse the issue of accessing previous branches. > >It is fine with me, though I would suggest that such usage should be >discoruaged. If folks want to work on just jbossmq, then get the >standalone >server. Perhaps if folks are only interested in working on one module at a >time and don't really need the server to startup we could provide more >jboss-* modules that provide the correct tools and thirdparty. That seems >a >bit excessive for the moment. > >A better long term solution would be to clean up the cvs namespace directly >so that it was better support for CVSROOT/modules magic which does not >interfer with vanilla cvs module checkouts. > >--jason > > >___ >Jboss-development mailing list >[EMAIL PROTECTED] >http://lists.sourceforge.net/lists/listinfo/jboss-development _ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] connection loaders and resource adapter bindings
Hi, Unfortunately it doesn't seem to be possible to issue a warning if you supply the wrong resource adapter name, since the way it works is: ConnectionFactoryLoader mbean gets its ResourceAdapterName and registers as a NotificationListener with the jmx server, filtering on Deployment events with message = ResourceAdapterName When the RARDeployer finds a .rar to deploy, it does so, and sends a Deployment notification with message = resource adapter name. The ConnectionFactoryLoader gets this message, checks to see if it is the resource adapter it is expecting, and if so sets up the ConnectionFactory, ManagedConnectionFactory So if you put in the wrong name, it will happily wait forever until a rar with that name is deployed. I don't see a way to determine (automatically) that a ResourceAdapterName is wrong - ever. Do you? Regarding your earlier problem with jars deploying before rars, it seems as if we _could_ implement a similar notification mechanism for ejb deployment: if say the DataSource isn't ready when the bean is deployed, it could register a listener waiting for it, and when the DataSource is deployed, it could notify waiting ejbs (or their persistence managers I guess?) Would this be worthwhile/ a more robust solution than trying to be sure to deploy in the right order? david jencks On 2001.08.16 19:19:34 -0400 Jason Dillon wrote: > It looks like ResourceAdapterName is used to bind a connection factory > loader to a deployed adapter's (as david mentioned). It > also > looks like if the connection factory specifies an invalid name (one that > does not match up with the one in the ra.xml), that it will not complain > and > will not bind anything into JNDI. > > I found this out due to a typo in one of my JmsXA configurations. > > It should really complain about something in this case. > > --jason > > > ___ > Jboss-development mailing list > [EMAIL PROTECTED] > http://lists.sourceforge.net/lists/listinfo/jboss-development > > ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: CVSROOT modules
User: chirino Date: 01/08/16 18:35:35 Modified:.modules Log: To checkout the standalone JBossMQ server you should now use the jboss-mq module. Revision ChangesPath 1.48 +4 -3 CVSROOT/modules Index: modules === RCS file: /cvsroot/jboss/CVSROOT/modules,v retrieving revision 1.47 retrieving revision 1.48 diff -u -r1.47 -r1.48 --- modules 2001/08/17 00:00:55 1.47 +++ modules 2001/08/17 01:35:35 1.48 @@ -146,7 +146,7 @@ ## The jbossmq standalone server ## -jbossmq -d jbossmq \ +jboss-mq -d jboss-mq \ build/jbossmq/etc/root \ &_jbossmq_tools \ &_jbossmq_thirdparty \ @@ -167,7 +167,7 @@ thirdparty/sun jbossmq-modules -a \ - _jbossmq_build \ + _jbossmq_build \ _jboss_j2ee \ _jboss_naming \ _jboss_server \ @@ -195,6 +195,7 @@ ## jbossjboss +jbossmq jbossmq jnp jnp jbosscx jbosscx manual manual @@ -222,4 +223,4 @@ ## Name-space migration aliases. ## -website -d website newsite \ No newline at end of file +website -d website newsite ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Improving MDB behavior in the presence of delivery failures
Per spec the MDB should not be throwing any exceptions.. This would mean
that it's thier responsibility to put the message to a 'rejected' queue.
But I think that is the best solution would be to allow the MDB to be
configured with the 'rejected' queue in it's deployment descriptor. I know
that not everybody will enclose thier MDB code in try { } catch (Throable e)
{}
Regards,
Hiarm
>From: "Scott M Stark" <[EMAIL PROTECTED]>
>Reply-To: [EMAIL PROTECTED]
>To: <[EMAIL PROTECTED]>
>Subject: [JBoss-dev] Improving MDB behavior in the presence of delivery
>failures
>Date: Thu, 16 Aug 2001 18:22:23 -0700
>
>Right now there are any number of ways to cause JBoss to spin in a tight
>loop
>trying to deliver a transacted msg to an mdb due to a problem with either
>the msg or mdb code that either causes an exception thrown from onMessage()
>or the tx to be rolled back. A trivial example of the latter is to have an
>mdb
>do a findByPrimaryKey() using a key from the msg that happens to be null.
>
>One solution would be to have the mdb container fail such msgs after so
>many delivery attempts. On failure, the msg along with the exception would
>be placed into a error queue associated with the container. An admin would
>have to pull the msg off, fix any data problems and then place the msg
>back onto the mdb queue/topic for redelivery.
>
>Are there any better ways to handle this?
>
>
>
>___
>Jboss-development mailing list
>[EMAIL PROTECTED]
>http://lists.sourceforge.net/lists/listinfo/jboss-development
_
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp
___
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jbossmq/src/main/org/jboss/mq SpyMessageConsumer.java
User: pkendall
Date: 01/08/16 18:29:34
Modified:src/main/org/jboss/mq SpyMessageConsumer.java
Log:
Fix message listener acknowledgements
Revision ChangesPath
1.4 +2 -2 jbossmq/src/main/org/jboss/mq/SpyMessageConsumer.java
Index: SpyMessageConsumer.java
===
RCS file: /cvsroot/jboss/jbossmq/src/main/org/jboss/mq/SpyMessageConsumer.java,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- SpyMessageConsumer.java 2001/08/17 01:21:38 1.3
+++ SpyMessageConsumer.java 2001/08/17 01:29:34 1.4
@@ -29,7 +29,7 @@
* @author Hiram Chirino ([EMAIL PROTECTED])
* @author David Maplesden ([EMAIL PROTECTED])
*
- * @version $Revision: 1.3 $
+ * @version $Revision: 1.4 $
*/
public class SpyMessageConsumer implements MessageConsumer, SpyConsumer, Runnable {
@@ -358,7 +358,7 @@
thisListener.onMessage(message);
- if (!session.transacted && session.acknowledgeMode ==
session.AUTO_ACKNOWLEDGE || session.acknowledgeMode == session.DUPS_OK_ACKNOWLEDGE) {
+ if (!session.transacted && (session.acknowledgeMode ==
session.AUTO_ACKNOWLEDGE || session.acknowledgeMode == session.DUPS_OK_ACKNOWLEDGE)) {
mes.doAcknowledge();
}
mes = null;
___
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jbossmq/src/main/org/jboss/mq SpyMessageConsumer.java
User: pkendall
Date: 01/08/16 18:21:38
Modified:src/main/org/jboss/mq SpyMessageConsumer.java
Log:
Fix message listener acknowledgements
Revision ChangesPath
1.3 +6 -3 jbossmq/src/main/org/jboss/mq/SpyMessageConsumer.java
Index: SpyMessageConsumer.java
===
RCS file: /cvsroot/jboss/jbossmq/src/main/org/jboss/mq/SpyMessageConsumer.java,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- SpyMessageConsumer.java 2001/08/16 04:04:40 1.2
+++ SpyMessageConsumer.java 2001/08/17 01:21:38 1.3
@@ -29,7 +29,7 @@
* @author Hiram Chirino ([EMAIL PROTECTED])
* @author David Maplesden ([EMAIL PROTECTED])
*
- * @version $Revision: 1.2 $
+ * @version $Revision: 1.3 $
*/
public class SpyMessageConsumer implements MessageConsumer, SpyConsumer, Runnable {
@@ -351,11 +351,14 @@
if( mes instanceof SpyEncapsulatedMessage ) {
message = ((SpyEncapsulatedMessage)mes).getMessage();
}
- thisListener.onMessage(message);
- if (session.transacted) {
+ if(session.transacted){
session.connection.spyXAResourceManager.ackMessage(session.currentTransactionId, mes);
- } else if (session.acknowledgeMode == session.AUTO_ACKNOWLEDGE ||
session.acknowledgeMode == session.DUPS_OK_ACKNOWLEDGE) {
+ }
+
+ thisListener.onMessage(message);
+
+ if (!session.transacted && session.acknowledgeMode ==
session.AUTO_ACKNOWLEDGE || session.acknowledgeMode == session.DUPS_OK_ACKNOWLEDGE) {
mes.doAcknowledge();
}
mes = null;
___
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Improving MDB behavior in the presence of delivery failures
Right now there are any number of ways to cause JBoss to spin in a tight loop trying to deliver a transacted msg to an mdb due to a problem with either the msg or mdb code that either causes an exception thrown from onMessage() or the tx to be rolled back. A trivial example of the latter is to have an mdb do a findByPrimaryKey() using a key from the msg that happens to be null. One solution would be to have the mdb container fail such msgs after so many delivery attempts. On failure, the msg along with the exception would be placed into a error queue associated with the container. An admin would have to pull the msg off, fix any data problems and then place the msg back onto the mdb queue/topic for redelivery. Are there any better ways to handle this? ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] How to get MBeans to describe it's fields like a DynamicMBean does
> > >But once there is a common abstract to sub-class or a concreate wrapper
> > >(that would proxy to an object), that seems like it would be easier
>than
> > >the
> > >interface as well as provide more functionality.
> >
> > No, I think that the easiest way to expose attributes and functions is
>to
> > list them in a interface file. The interface file has the minimum info
>for
> > the Wrapper DynamicMBean to function. It's just that if that wrapper
>MBean
> > finds an associated property file to use to add to interface it would be
> > nice too.
>
>I still think that it would be easier to
>
>
>public class MyClass extends AbstractDynamicMBean
>{
> public MyClass() {
> ...
> }
>
> protected String[] getAttributeNames() {
> return new String[] { "name" };
> }
>
> public String getName() {
> ...
> }
>
> public void setName(String name) {
> ...
> }
>}
>
>
>By doing this we could create a subclass which would use introspection to
>list all attributes and operations, for objects that want to be beans and
>just what to expose all publics.
>
I see how this could be simpler in some cases... But in cases where you are
using interface Inheritance, MBean interface files really shine. By
extending another interface you are exposing those managment methods too.
Plus it seems like you better compile time checking since the compiler will
let you know if you miss typed something in the MBean interface file. Whith
your approach above, you would not know if you missed typed anything until
runtime.
>
>Dealing with the interface reminds me of c header files. In most cases the
>MBean that I write want to expose all public methods, so when I add a new
>one, update the sig or whatever, I have to keep the *MBean iterface upto
>date. Note a big deal, but kinda tedious. If we are going to move to
>dynamic mbeans to make better use of jmx (which I think is a great idea)
>then why not expliot it to the fullest and make JBoss more maintainable and
>easier to extend...
>
I don't think that going one way or another will make a real impact on the
maintanance or extensability of JBoss... If anything doing it either way
will make it less understandable since we will be diverging from standard
MBean type code in DynamicMBean code.
>
> > So what do you think... Should I commit the code and see if anybody
>uses
> > it??
>
>Sure, commit it.
>
ok.. will do in a few days...
Regards,
Hiram
_
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp
___
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] resource logging
What are we going todo about logging from resource adapters and such? It
looks like there is alot of stuff that:
if (logger != null) {
// some use full message
}
Or it will not log anything at all... even error conditions. It also looks
like there is alot of System. usage too, which just plain sucks.
There was some email with Peter a while ago on the jms ra and logging, which
we concluded that we should log4j and more or less ignore the
javax.resource.* PrintWriter logging crap.
I have not done anything about that yet, since I have been on this bug
hunt, which lead me to find even more cases like this.
The issues as I see them are:
1) The current javax.resource.* logging usage of a PrintWriter sucks,
really, really, really sucks.
2) Such a crappy loging mechanism is forcing folks to use adhoc logging
semantics, which is making it hard to debug problems when they arise.
Worse yet it is "hiding" problems by some code simply not logging
anything if it doesn't have a PrintWriter.
3) Did I mention that PrintWriter for logging sucks... oh ya I did... but
it is so bad that I want to list it again.
I am sure there are more issues, but these suffice for the question at hand,
which is what are we going to do about this?
I suggest dropping the PrintWriter Logger() fluff (replaced by
empty methods) and implement all logging with Log4j. I think that this
is the best bet in the shortterm to get a really stable and functional
product out there. It will limit how the ra stuff will plug into other
servers, but we really want folks to use JBoss, not just canabalize the
components.
Long term we want to be spec compliant, and perhaps the spec will be
improvded with respect to logging in the next release.
My conclusion is that being spec compliant and using PrintWriters for
logging is more harmful than anything else with respect to the rapid growth,
stability and feature set of JBoss.
Let us drop it and use Log4j.
--jason
___
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] jca changes & loaders
It looks like the recent jca & datasource loaders have introduced inconsistency in the transaction integrety of the entity system. I have not yet been able to track this down, but based on an application that was working the day before yesterday, which is now non-functional after more than one run, I would guess that there was a change between now and then that has broken something. I am seeing problems commiting transactions that invole entity beans. Where a client calls a method, which updates a field, sets a modified flag. Sometimes the isModified() method will be called, sometimes it won't. There are a few different beans getting called in a specific order, but I am not seeing some of the latter JDBCCommand* logs showing that the database is actually getting updated. My application has not changed and will appear to function with small message quantities (1) the first time. After running it again it will not work, even though the functionality is performed, the database just never gets up dated and thus my clients are left in the dark (pooling, waiting for the dogs...). I think it would be a really good idea if we could stabale and branch a 2.6 before any other changes are added. 2.5 (or pre-3.0 as it is called) is much, much better than 2.4... if we would stop breaking things trying to make it even better. Personally I would like to see this happen... so I could stop chasing around bugs that break my app and actually start working on other JBoss bits (like documentation of the build system, integration of the testsuite and other such things). JBossMQ has come leaps and bounds, so has the locking system. Lets tidy up what we have then branch and keep going for full RH in 3.0! It is nice to troll through the code, but I ernestly just want something working. I have been playing "chase the bug" for over a month now. It is getting closer... If someone knows what is wrong with the tx stuff please let me know. My guess is that David might have a clue =P Or I guess I could have broken something, but I don't think I did. =| --jason ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] MDB has stopped working
On Thu, 16 Aug 2001, Hiram Chirino wrote: > I could run a code beautifier on it.. Ok. =) --jason ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jboss/src/main/org/jboss/ejb AutoDeployer.java
User: user57
Date: 01/08/16 17:19:23
Modified:src/main/org/jboss/ejb AutoDeployer.java
Log:
o log an info message when scanDirectory finds a file to deploy
Revision ChangesPath
1.23 +2 -1 jboss/src/main/org/jboss/ejb/AutoDeployer.java
Index: AutoDeployer.java
===
RCS file: /cvsroot/jboss/jboss/src/main/org/jboss/ejb/AutoDeployer.java,v
retrieving revision 1.22
retrieving revision 1.23
diff -u -r1.22 -r1.23
--- AutoDeployer.java 2001/08/16 21:24:48 1.22
+++ AutoDeployer.java 2001/08/17 00:19:23 1.23
@@ -47,7 +47,7 @@
* @author mailto:[EMAIL PROTECTED]";>Rickard Öberg
* @author mailto:[EMAIL PROTECTED]";>Toby Allsopp
* @author mailto:[EMAIL PROTECTED]";>Jason Dillon
- * @version $Revision: 1.22 $
+ * @version $Revision: 1.23 $
*/
public class AutoDeployer
extends ServiceMBeanSupport
@@ -411,6 +411,7 @@
// Add to list of files to deploy automatically
watchedURLs.add(new Deployment(fileUrl));
deployedURLs.put(fileUrl, fileUrl);
+ log.info("Auto-deploying " + fileUrl);
}
}
}
___
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] MDB has stopped working
I could run a code beautifier on it.. Regards, Hiram >From: Jason Dillon <[EMAIL PROTECTED]> >Reply-To: [EMAIL PROTECTED] >To: "'[EMAIL PROTECTED]'" ><[EMAIL PROTECTED]> >Subject: RE: [JBoss-dev] MDB has stopped working >Date: Thu, 16 Aug 2001 16:55:01 -0700 (PDT) > > > It doesn't help that jboss server is using 3 spaces and jboss mq > > uses tabs... > >jbossmq should be using 3 spaces too... but the task of changing this over >is daunting. > >--jason > > >___ >Jboss-development mailing list >[EMAIL PROTECTED] >http://lists.sourceforge.net/lists/listinfo/jboss-development _ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: build/jboss config.xml
User: user57 Date: 01/08/16 17:01:47 Modified:jbossconfig.xml Log: o made plugings/jetty a memeber of the standard-plugins group (part of the default build of jboss-all) Revision ChangesPath 1.2 +3 -3 build/jboss/config.xml Index: config.xml === RCS file: /cvsroot/jboss/build/jboss/config.xml,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- config.xml2001/08/11 22:33:40 1.1 +++ config.xml2001/08/17 00:01:47 1.2 @@ -7,7 +7,7 @@ - + @@ -139,11 +139,11 @@ - + - + ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: CVSROOT modules
User: user57 Date: 01/08/16 17:00:56 Modified:.modules Log: o added plugins/jetty to jboss-all-plugins module (which is part of jboss-all) Revision ChangesPath 1.47 +2 -4 CVSROOT/modules Index: modules === RCS file: /cvsroot/jboss/CVSROOT/modules,v retrieving revision 1.46 retrieving revision 1.47 diff -u -r1.46 -r1.47 --- modules 2001/08/14 03:55:41 1.46 +++ modules 2001/08/17 00:00:55 1.47 @@ -84,10 +84,8 @@ jboss-all-plugins-d plugins \ build/_emptydir \ - &_plugins_varia - -# Needs more help before they can be integrated -#&_plugins_jetty + &_plugins_varia \ + &_plugins_jetty ## ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: contrib/jetty/src/etc README
User: user57 Date: 01/08/16 16:57:27 Modified:jetty/src/etc README Log: o Updated README for head, this file was moved. Revision ChangesPath 1.3 +29 -30contrib/jetty/src/etc/README Index: README === RCS file: /cvsroot/jboss/contrib/jetty/src/etc/README,v retrieving revision 1.2 retrieving revision 1.3 diff -u -r1.2 -r1.3 --- README2001/08/16 23:53:15 1.2 +++ README2001/08/16 23:57:27 1.3 @@ -1,44 +1,43 @@ +JBoss-Jetty. +--- -Un*x users: +This is a module that integrates intra-vm JBoss CVS with Jetty3 CVS +(jetty.mortbay.com). -run ./run.sh in this dir. +Jetty is then able to provide JBoss with the services of Servlet +Container and HTTP Server. -MS Users: +To INSTALL : (I'm assuming Un*x - Windows later..) -cd to ./jboss/bin and 'run.bat jetty' +cd contrib/jetty/src/build +(set up JBOSS_HOME and JETTY_HOME) +sh ./build.sh install (installs jetty-service.jar in jboss tree) +sh ./build.sh client (builds contrib/jetty/tomcat-test.ear) -(please send me the equiv run.bat for this dir) +Uncomment the necessary Jetty stuff in +$JBOSS_HOME/conf/default/jboss.conf and jboss.jcml - ensuring that you +set up a ClassPathExtension pointing to Jetty's lib directory, +org.jboss.deployment.J2eeDeployer's WarDeployerName Arg is changed to +: :service=Jetty and that you set the Attribute url for JettyService +as suggested in the comment. +To TEST : -For some Jetty doc and Demos run up JBoss-Jetty and hit: +Follow the instructions in contrib/tomcat to deploy and run the +tomcat-test.ear (WebApp and EJBs). -http://my-jboss-host:8080 +To further test Jetty try hitting :8080/ (If you haven't +altered the port Jetty is configured to run on). This will run the +Jetty web-application, giving you access to the Jetty demo test-suite. -You can look around the MBeans running within Jetty by hitting : +PROBLEMS : -http://my-jboss-host:8082 +Jetty questions should be directed to [EMAIL PROTECTED] +JBoss questions should be directed to [EMAIL PROTECTED] +I shall be happy to answer questions about the integration. -and looking at the 'Jetty' links... +Enjoy. -Please post problems accordingly : - -Jetty (i.e. WAR, JSDK, HTTP) related -> [EMAIL PROTECTED] - -JBoss/Jetty Integration (Deployment etc...) related -> [EMAIL PROTECTED] (put 'Jetty' in your subject -line) - -JBoss (everything else) related -> [EMAIL PROTECTED] - - - -Thanks for using JBoss-Jetty, - - -Jules (JBoss-Jetty maintainer) - [EMAIL PROTECTED] +Jules ([EMAIL PROTECTED]) - 11/11/2000 ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jboss/src/resources/org/jboss/jms/ra/META-INF ra.xml
User: user57 Date: 01/08/16 16:57:48 Modified:src/resources/org/jboss/jms/ra/META-INF ra.xml Log: o updated doctype to reflect the dtd's location on java.sun.com Revision ChangesPath 1.4 +28 -24jboss/src/resources/org/jboss/jms/ra/META-INF/ra.xml Index: ra.xml === RCS file: /cvsroot/jboss/jboss/src/resources/org/jboss/jms/ra/META-INF/ra.xml,v retrieving revision 1.3 retrieving revision 1.4 diff -u -r1.3 -r1.4 --- ra.xml2001/07/18 14:40:14 1.3 +++ ra.xml2001/08/16 23:57:48 1.4 @@ -1,27 +1,31 @@ -http://java.sun.com/j2ee/dtds/connector_1_0.dtd'> + +http://java.sun.com/dtd/connector_1_0.dtd";> + -JMS Adapter -JBoss org -1.0 -1.0 -JMS - - org.jboss.jms.ra.JmsManagedConnectionFactory - org.jboss.jms.ra.client.JmsConnectionFactory - org.jboss.jms.ra.JmsConnectionFactoryImp -javax.jms.Session -org.jboss.jms.ra.JmsSession -XATransaction - -JmsProviderAdapterJNDI -java.lang.String -java:DefaultJMSProvider - - - BasicPassword - javax.resource.security.PasswordCredential - -false - + JMS Adapter + JBoss org + 1.0 + 1.0 + JMS + + org.jboss.jms.ra.JmsManagedConnectionFactory + org.jboss.jms.ra.client.JmsConnectionFactory + org.jboss.jms.ra.JmsConnectionFactoryImp + javax.jms.Session + org.jboss.jms.ra.JmsSession + XATransaction + + JmsProviderAdapterJNDI + java.lang.String + java:DefaultJMSProvider + + + BasicPassword + javax.resource.security.PasswordCredential + + false + ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: contrib/jetty/etc README
User: user57 Date: 01/08/16 16:57:27 Removed: jetty/etc README Log: o Updated README for head, this file was moved. ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jbosspool/src/resources/xa-rar/META-INF ra.xml
User: user57 Date: 01/08/16 16:54:15 Modified:src/resources/xa-rar/META-INF ra.xml Log: o updated DOCTYPE to reflect the actually location of the dtd on java.sun.com Revision ChangesPath 1.2 +69 -63jbosspool/src/resources/xa-rar/META-INF/ra.xml Index: ra.xml === RCS file: /cvsroot/jboss/jbosspool/src/resources/xa-rar/META-INF/ra.xml,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- ra.xml2001/08/16 03:05:46 1.1 +++ ra.xml2001/08/16 23:54:15 1.2 @@ -1,15 +1,19 @@ -http://java.sun.com/j2ee/dtds/connector_1_0.dtd";> + +http://java.sun.com/dtd/connector_1_0.dtd";> + -Minerva JDBC XATransaction ResourceAdapter -Minerva Resource Adapter for JDBC 2 XA drivers -JBoss.org -1.0 -JDBC 2 XA drivers -1.0b3 - -true -COPYRIGHT AND PERMISSION NOTICE + Minerva JDBC XATransaction ResourceAdapter + Minerva Resource Adapter for JDBC 2 XA drivers + JBoss.org + 1.0 + JDBC 2 XA drivers + 1.0b3 + + true + COPYRIGHT AND PERMISSION NOTICE Copyright (c) 2001 OpenTools.org @@ -39,57 +43,59 @@ shall not be used in advertising or otherwise to promote the sale, use or other dealings in this Software without prior written authorization of the copyright holder. - - - org.jboss.pool.connector.jdbc.XAManagedConnectionFactory - javax.sql.DataSource - org.jboss.pool.connector.jdbc.JDBCDataSource -java.sql.Connection - -java.sql.Connection -XATransaction - -The default user name used to create JDBC -connections. -UserName -java.lang.String - - -The default password used to create JDBC - connections. -Password -java.lang.String - - -The properties to set up the XA driver. -XADataSourceProperties -java.lang.String - - -The class name of the JDBC XA driver that handles -this JDBC URL. Not necessary if the driver has already -been initialized by other means. -XADataSourceClass -java.lang.String - - -The jndi name of the JDBC XA driver that handles -this JDBC URL. Not necessary if the driver has already -been initialized by other means. -XADataSourceJNDIName -java.lang.String - - -The transaction isolation for new connections. - Not necessary: the driver default will be used if ommitted. -TransactionIsolation -java.lang.String - - - BasicPassword - javax.resource.security.PasswordCredential - -false - + + + org.jboss.pool.connector.jdbc.XAManagedConnectionFactory + javax.sql.DataSource + org.jboss.pool.connector.jdbc.JDBCDataSource + java.sql.Connection + + java.sql.Connection + XATransaction + + The default user name used to create JDBC + connections. + UserName + java.lang.String + + + The default password used to create JDBC + connections. + Password + java.lang.String + + + The properties to set up the XA driver. + XADataSourceProperties + java.lang.String + + + The class name of the JDBC XA driver that handles + this JDBC URL. Not necessary if the driver has already + been initialized by other means. + XADataSourceClass + java.lang.String + + + The jndi name of the JDBC XA driver that handles + this JDBC URL. Not necessary if the driver has already + been initialized by other means. + XADataSourceJNDIName + java.lang.String + + + The transaction isolation for new connections. + Not necessary: the driver default will be used if ommitted. + TransactionIsolation + java.lang.String + + + BasicPassword + javax.resource.security.PasswordCredential + + false + ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jbosspool/src/resources/jdbc-rar/META-INF ra.xml
User: user57 Date: 01/08/16 16:54:14 Modified:src/resources/jdbc-rar/META-INF ra.xml Log: o updated DOCTYPE to reflect the actually location of the dtd on java.sun.com Revision ChangesPath 1.4 +53 -49jbosspool/src/resources/jdbc-rar/META-INF/ra.xml Index: ra.xml === RCS file: /cvsroot/jboss/jbosspool/src/resources/jdbc-rar/META-INF/ra.xml,v retrieving revision 1.3 retrieving revision 1.4 diff -u -r1.3 -r1.4 --- ra.xml2001/07/18 14:38:23 1.3 +++ ra.xml2001/08/16 23:54:14 1.4 @@ -1,15 +1,19 @@ -http://java.sun.com/j2ee/dtds/connector_1_0.dtd";> + +http://java.sun.com/dtd/connector_1_0.dtd";> + -Minerva JDBC LocalTransaction ResourceAdapter -Minerva Resource Adapter for JDBC 1/2 drivers -JBoss.org -1.0 -JDBC 1/2 drivers -1.0b3 - -true -COPYRIGHT AND PERMISSION NOTICE + Minerva JDBC LocalTransaction ResourceAdapter + Minerva Resource Adapter for JDBC 1/2 drivers + JBoss.org + 1.0 + JDBC 1/2 drivers + 1.0b3 + + true + COPYRIGHT AND PERMISSION NOTICE Copyright (c) 2001 OpenTools.org @@ -39,43 +43,43 @@ shall not be used in advertising or otherwise to promote the sale, use or other dealings in this Software without prior written authorization of the copyright holder. - - - org.jboss.pool.connector.jdbc.JDBCManagedConnectionFactory - javax.sql.DataSource - org.jboss.pool.connector.jdbc.JDBCDataSource -java.sql.Connection - org.jboss.pool.jdbc.ConnectionInPool -LocalTransaction - -The default user name used to create JDBC -connections. -UserName -java.lang.String - - -The default password used to create JDBC - connections. -Password -java.lang.String - - -The JDBC URL used to create JDBC - connections. -ConnectionURL -java.lang.String - - -The class name of the JDBC driver that handles -this JDBC URL. Not necessary if the driver has already -been initialized by other means. -Driver -java.lang.String - - - BasicPassword - javax.resource.security.PasswordCredential - -false - + + + org.jboss.pool.connector.jdbc.JDBCManagedConnectionFactory + javax.sql.DataSource + org.jboss.pool.connector.jdbc.JDBCDataSource + java.sql.Connection + org.jboss.pool.jdbc.ConnectionInPool + LocalTransaction + + The default user name used to create JDBC + connections. + UserName + java.lang.String + + + The default password used to create JDBC + connections. + Password + java.lang.String + + + The JDBC URL used to create JDBC + connections. + ConnectionURL + java.lang.String + + + The class name of the JDBC driver that handles + this JDBC URL. Not necessary if the driver has already + been initialized by other means. + Driver + java.lang.String + + + BasicPassword + javax.resource.security.PasswordCredential + + false + ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: contrib/jetty/etc local.properties-example VERSION demo.xml jboss.conf jetty.properties jetty.xml run.sh
User: user57 Date: 01/08/16 16:53:15 Added: jetty/etc local.properties-example Removed: jetty/etc VERSION demo.xml jboss.conf jetty.properties jetty.xml run.sh Log: o integrating plugins/jetty with buildmagic Revision ChangesPath 1.2 +43 -0 contrib/jetty/etc/local.properties-example ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: contrib/jetty/docs README TODO
User: user57 Date: 01/08/16 16:53:15 Added: jetty/docs README TODO Log: o integrating plugins/jetty with buildmagic Revision ChangesPath 1.2 +45 -0 contrib/jetty/docs/README 1.2 +18 -0 contrib/jetty/docs/TODO ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: contrib/jetty build.sh build.xml config.xml README TODO
User: user57 Date: 01/08/16 16:53:14 Added: jettybuild.sh build.xml config.xml Removed: jettyREADME TODO Log: o integrating plugins/jetty with buildmagic Revision ChangesPath 1.2 +131 -0contrib/jetty/build.sh 1.2 +490 -0contrib/jetty/build.xml 1.2 +228 -0contrib/jetty/config.xml ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: contrib/jetty/src/etc README VERSION demo.xml jetty.properties jetty.xml
User: user57 Date: 01/08/16 16:53:15 Added: jetty/src/etc README VERSION demo.xml jetty.properties jetty.xml Log: o integrating plugins/jetty with buildmagic Revision ChangesPath 1.2 +44 -0 contrib/jetty/src/etc/README 1.2 +149 -0contrib/jetty/src/etc/VERSION 1.2 +179 -0contrib/jetty/src/etc/demo.xml 1.2 +10 -0 contrib/jetty/src/etc/jetty.properties 1.2 +214 -0contrib/jetty/src/etc/jetty.xml ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: contrib/jetty/src/build build.bat build.sh
User: user57 Date: 01/08/16 16:53:15 Removed: jetty/src/build build.bat build.sh Log: o integrating plugins/jetty with buildmagic ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] MDB has stopped working
> It doesn't help that jboss server is using 3 spaces and jboss mq > uses tabs... jbossmq should be using 3 spaces too... but the task of changing this over is daunting. --jason ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Stateful bean with different transaction context
Weird. If you can set me straight on what needs to be done it would be a huge, huge, massive, did I mention huge... help! --jason On Thu, 16 Aug 2001, David Jencks wrote: > Hi, > > Ill look at this more later... > > I think you also need > in properties > > DataSourceClass= > and maybe ConnectionURL=url=jdbc > > weird but maybe right. > > I'll try some things out later this evening. > > david jencks > > On 2001.08.16 18:04:28 -0400 Jason Dillon wrote: > > I am using something like this: > > > > > > ../deploy/lib, > > ../deploy/bean1.jar, > > ../deploy/bean2.jar > > > > > > Since the beans are already urls ready for deploying they are added to > > the > > list right away. The lib directory is only scanned once a pass is made > > on > > run(), which will find some files, but append them after the urls that > > are > > explict. > > > > I fixed this by simply scanning the directories after adding the > > directory > > url to the watch list. > > > > It seems to work fine. > > > > I am having another problem with a NPE when trying to get a connection > > from > > the datasource, perhaps my config is wrong... but the logs do not really > > tell me what is wrong, which I was looking into fixing. Below is my > > config > > if you could tell me what is wrong with it that would be swell: > > > > > > > name="DefaultDomain:service=ConnectionFactoryLoader,name=SharedDS"> > > > > ConnectionURL=jdbc:oracle:thin:@bendev:1521:BENDV > > JDBCUser=jason > > Password=jason > > > > > > SharedDS > > > > > > java:/TransactionManager > > > > > > Minerva JDBC XATransaction ResourceAdapter > > > > JCA:service=RARDeployer > > > > MinervaXACMFactory > > > > > > InvalidateOnError=false > > Blocking=true > > IdleTimeoutMillis=180 > > MaxSize=10 > > TimestampUsed=false > > IdleTimeoutEnabled=false > > GCIntervalMillis=12 > > MinSize=0 > > GCMinIdleMillis=120 > > GCEnabled=false > > MaxIdleTimeoutPercent=1.0 > > > > > > org.jboss.resource.security.ManyToOnePrincipalMapping > > > > > > > > > > > > --jason > > > > > > On Thu, 16 Aug 2001, David Jencks wrote: > > > > > Hi jason, I forgot about this problem. > > > > > > AutoDeploy works ok for me if the autodeployer conf looks like this: > > > > > >> name="EJB:service=AutoDeployer"> > > > > > > JCA:service=RARDeployer; > > > J2EE:service=J2eeDeployer > > > > > > > > > ../deploy/lib, > > > ../deploy > > > > > > > > > 3000 > > > > > > > > > > > > Note that I reversed RARDeployer and J2eeDeployer as well as the > > directory > > > order. (For me just having ../deploy.lib before ../deploy worked, maybe > > > reversing both will fix it for you). > > > > > > If this doesn't fix it for you could you send me your AutoDeployer > > conf? > > > > > > thanks > > > david > > > > > > On 2001.08.16 15:08:58 -0400 Jason Dillon wrote: > > > > I just switched over and found one rather large problem, that is that > > my > > > > beans deploy before the resource adapters. It could be that I am > > > > explicitly > > > > listing the .jars to deploy, but I have the deploy/lib directory > > listed > > > > before it, so I expected that it would do the right thing. > > > > > > > > I think it will work if I touch all the files and force the auto > > deployer > > > > to > > > > re-deploy once the datasources have been bound to jndi. > > > > > > > > Do you (or anyone else) have any ideas on how to fix this, or should > > I > > > > look > > > > into it? > > > > > > > > --jason > > > > > > > > > > > > On Wed, 15 Aug 2001, David Jencks wrote: > > > > > > > > > Hi Jason, could you try converting to the jca version of db access > > and > > > > see > > > > > if the problem persists? I recently found a race condition in (the > > jca > > > > > versions) of the code that releases connections back to the pool > > after > > > > > transactions complete that was allowing several transactions to > > access > > > > the > > > > > same connection. Maybe a similar bug is present in the non-jca > > code. > > > > I'm > > > > > hoping to check in my "auto-converting-to-jca" XADatasourceLoader > > later > > > > > today, in case you don't want to try the conversion by hand. (this > > race > > > > fix > > > > > is only in rabbit hole). > > > > > > > > > > Thanks > > > > > david jencks > > > > > > > > > > On 2001.08.14 19:07:43 -0400 Jason Dillon wrote: > > > > > > I was trying to track down a concurrency problem which would show > > up > > > > as > > > > > > an > > > > > > Oracle deadlock exception. It looks like that exception was > > > > happening > > > > > > due > > > > > > to some fk constraints causing parent tables to lock and such. > > Any > > > > ways, > > > > > > after I got that deadlock
Re: [JBoss-dev] DataSourceLoader...
I did briefly, but what I really want is a conversion guide. I did not have
much luck with taking bist from jboss-auto.jcml. I could try again though.
I am using the loader in the time being.
--jason
On Thu, 16 Aug 2001, David Jencks wrote:
> Did you try the autoconverter XADataSOurceLoader? it worked for
> XADataSourceImpl (won't work now, had to jimmy the config).
>
> Will look more later
> david
>
> On 2001.08.16 18:25:18 -0400 Jason Dillon wrote:
> > In XAManagedConnectionFactory.getXADS() is returning null due to the
> > return
> > null at the bottom of the method. It looks like this wants either an
> > xaDataSourceClass or xaDataSourceName to be set, if not it returns null.
> > Which then causes the pooling stuff to hang indefinently.
> >
> > This is confusing me a little. Where do I specify these values? The
> > examples you gave were both based on the local tx stuff, but I want to
> > use
> > the xa tx stuff.
> >
> > Any advise? I am stuck in the water until I can get the DS back online.
> >
> > --jason
> >
> >
> > On Thu, 16 Aug 2001, David Jencks wrote:
> >
> > > ResourceAdapterName identifies which resource adapter supplies the
> > > ConnectionFactory (and ManagedConnectionFactory etc etc) for the
> > > ConnectionFactoryLoader to load. (It's the display-name tag in ra.xml)
> > If
> > > you were using firebird as your database, this could be the firebird
> > > jca/jdbc driver. Since we are mostly stuck with jdbc only drivers,
> > this is
> > > typically one of the 2 Minerva wrapper adapters. With the jdbc (local
> > > transaction) wrapper, the "Properties" attribute, which is for
> > configuring
> > > the Resource Adapter, contains the db url which is enough to figure out
> > > which db driver we are using. With enough luck, mainstream db vendors
> > will
> > > decide to supply jca .rar versions of their drivers soon so we don't
> > always
> > > need the Minerva wrappers.
> > >
> > > david jencks
> > >
> > > On 2001.08.16 14:35:00 -0400 Jason Dillon wrote:
> > > > What is ResourceAdapterName used for?
> > > >
> > > > --jason
> > > >
> > > >
> > > > On Wed, 15 Aug 2001, David Jencks wrote:
> > > >
> > > > > Hi,
> > > > >
> > > > > This discussion comes up in various places on various lists. Since
> > you
> > > > > don't mention otherwise I assume you are planning to decrypt in
> > code
> > > > > without manual intervention. As I understand the consensus is,
> > Don't
> > > > do
> > > > > this. You need some code to unencrypt the password to send it to
> > the
> > > > db,
> > > > > if someone can find your jboss.jcml file they can find the
> > unencryption
> > > > > code. Thus you have implemented only security by obscurity and
> > only
> > > > > succeeded in making life harder for the users and probably given
> > them a
> > > > > false sense of security, encouraging carelessness that a determined
> > > > hacker
> > > > > can exploit.
> > > > >
> > > > > Secrets and Lies by Bruce Schneier is fun to read and explains this
> > > > really
> > > > > well.
> > > > >
> > > > > If you want more security yet don't want to give each user their
> > own
> > > > > password and have per-subject pools, how about writing a
> > > > > ConnectionFactoryLoader that pops up a password dialog on startup (
> > in
> > > > > initService). It's inconvenient, but at least it doesn't try to
> > fool
> > > > > people into thinking their passwords are hidden. Of course, it
> > could
> > > > be
> > > > > hard to figure out where to pop up the dialog...
> > > > >
> > > > > How about simply encrypting all of jboss.jcml say using pgp and
> > > > requiring a
> > > > > manually entered password to unencrypt to start jboss?
> > > > >
> > > > > In any case if you wish to modify the datasource loading procedure
> > I
> > > > > suggest you work on the jca resource adapter version since
> > > > > {XA|JDBC}DataSourceLoader will not really exist in rh. (they will
> > set
> > > > up
> > > > > connectionFactoryLoader mbeans).
> > > > >
> > > > > david jencks
> > > > >
> > > > > On 2001.08.14 19:12:14 -0400 "Ferguson, Doug" wrote:
> > > > > > What do you guys think about implemented a version of the
> > DataSource
> > > > > > loader
> > > > > > that
> > > > > > allows for encrypted passwords?
> > > > > >
> > > > > > I am required to use encrypted db passwords..
> > > > > > And I was thinking that even if I encrypt once I write the
> > jboss.jcml
> > > > > > It is now clear text again..
> > > > > >
> > > > > > d.
> > > > > >
> > > > > > ___
> > > > > > Jboss-development mailing list
> > > > > > [EMAIL PROTECTED]
> > > > > > http://lists.sourceforge.net/lists/listinfo/jboss-development
> > > > > >
> > > > > >
> > > > >
> > > > > ___
> > > > > Jboss-development mailing list
> > > > > [EMAIL PROTECTED]
> > > > > http://lists.sourceforge.net/lists/listinfo/jboss-development
> > > > >
> > > >
> > > >
> > > >
Re: [JBoss-dev] How to get MBeans to describe it's fields like aDynamicMBean does
> >But once there is a common abstract to sub-class or a concreate wrapper
> >(that would proxy to an object), that seems like it would be easier than
> >the
> >interface as well as provide more functionality.
>
> No, I think that the easiest way to expose attributes and functions is to
> list them in a interface file. The interface file has the minimum info for
> the Wrapper DynamicMBean to function. It's just that if that wrapper MBean
> finds an associated property file to use to add to interface it would be
> nice too.
I still think that it would be easier to
public class MyClass extends AbstractDynamicMBean
{
public MyClass() {
...
}
protected String[] getAttributeNames() {
return new String[] { "name" };
}
public String getName() {
...
}
public void setName(String name) {
...
}
}
By doing this we could create a subclass which would use introspection to
list all attributes and operations, for objects that want to be beans and
just what to expose all publics.
An adapter bean based on this could also take an random object and do the
same thing, or perhaps take some limiters. Regex could also be used or
Globing, were with an interface you are forced to make these choices at
compile time, or you have to get into byte code magic... which I personnally
don't want to start doing anytime soon.
Dealing with the interface reminds me of c header files. In most cases the
MBean that I write want to expose all public methods, so when I add a new
one, update the sig or whatever, I have to keep the *MBean iterface upto
date. Note a big deal, but kinda tedious. If we are going to move to
dynamic mbeans to make better use of jmx (which I think is a great idea)
then why not expliot it to the fullest and make JBoss more maintainable and
easier to extend...
I think this makes sence.
> So what do you think... Should I commit the code and see if anybody uses
> it??
Sure, commit it.
--jason
___
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Re: plugins/jetty integration with jboss-all
> Hm ! > > I noticed your checkins on jboss-dev and wondered what > you were up to Making life better I hope. > There are plans afoot to merge a repackaged version of > Jetty into the main JBoss tree and use it as the > default web container with JBoss. i.e. my > understanding is that unless you explicitly download a > JBoss-Tomcat package you will end up with a > JBoss/Jetty one. Cool. The entire source? Or as a dependency lib with JBoss specific adapters? > Marc is driving this. I shall be sitting between the > JBoss and Jetty communities and trying to maintain the > code. So I guess source then. Why? Sounds like it might be maintenance headache. > I haven't been following build-magic too closely, but > as I figure it, it makes the intra-module dependencies > in JBoss more explicit so it is easier to build a > complete and up-to-date distribution Exactly. No more binary integrations for modules, they are all built from sources. > In this case you should bear in mind the forthcoming > changes to the Jetty codebase, since the whole tree > may suddenly move from contrib into jboss, a number of > directories will change names and pretty much every > source file will be altered. I don't know how heavily > this will impact on you - but we should coordinate our > efforts here... Well, right now the contrib/jetty module is integrated in the jboss-all supermodule as plugins/jetty in the jboss_buildmagic branch. This is basically just the stuff from HEAD in contrib/jetty with its build system modified for buildmagic. Note, that jboss/plugins/jetty and contrib/jetty are the exact same CVS module. The namespace changes due to some magic in CVSROOT/modules. I suggest that anyone having troubles with this concept should checkout CVSROOT and read the comments in the modules file. I will get to adding a web page for this soon, but until then take a look a the source. > > First, I added the Jetty 3.1 rc7 & Jetty3Extra > > v0.0.5 (which I just > > downloaded from SF) into thirdparty/mortbay/... > > You should talk to Marc about this. The issues that I > have mentioned above may mean that we will have to > change this directory... If we are actually thinking of (or activly planning) to import the whole of jetty sources then this can go away. Otherwise the general model is to check in thridparty stuff that is required to make things work into cvs in the thirdparty module. I will eventually figure out a nice way to limit what gets pulled from cvs from module to module, but for now all modules share it. > > The Jetty support jars are small, so for now I just > > added them. I would > > like to have a general solution to this problem > > though. It might be > > including per module specific jars in a local lib > > directory, or it might be > > defining thirdparty includes for each module, which > > would mean that each > > module would have copies of each jar that it > > depeneds on, but there would > > really be only one version in the repository. Not > > sure what is best at the > > moment. > > I'll leave that all to you - sounds like an > interesting can of worms. If each plugin keeps it's > own copy of it's consumables, but ultimately they all > share the same copy in the distrib, then I assume they > are built against the local copy and run against the > shared one. We'll need to be very careful about having > different versions of popular jars flying around (have > I missed the point here?). I think it would be much That is what the thirdparty modules solves. Only one copy is ever checked in. But all modules share it so, if you wanted to just built module x which had one dependency from thirdparty, you will still have the check then entire beast out. > safer to build and run against the same platform - > i.e. do the sharing of these resources in the build > tree as well as the runtime. It is a trade of between sharing and avoiding duplication, as well as working around the problem with CVSROOT/modules and `cvs update`. I is possible to selectivly include thirdparty directories on a per-module basis at the cost of duplicating files which are common between modules. Note sure which is the lesser of the two evils. For now one directory is, cause it is already working like that. > > Second, I think that it would make life easier for > > releasing the jboss-jetty > > distribution, but setting up a new jboss-jetty > > module, which would compile > > and create the proper jboss-jetty-xxx.zip. This is > > currently possible, as > > was done for the standalone JBossMQ, but there are > > some minor problems. > > One is that since modules "export" files into a > > rather static namespace, it > > is mostly an all or nothing when it comes to > > including released files from a > > module into a project release. > > > > The stuff I mentioned above will also impact on this. > I figure I will be excused release duties once it is > done, since Jetty will be going out in every JBos
Re: [JBoss-dev] persistance scheme
Depends on your data model and expected usage. Take it to jboss-user for more information. --jason On Thu, 16 Aug 2001, Tony wrote: > Hi, > > I want to know what persistance scheme is preferred these days. I am going to start >a new project and evaluating > Entity Bean, JDO, Castor etc. Its going to be a heavy-load site with lots of >concurrent users. > > I will appreciate Pros and Cons of above options. > > Tony Grey > ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] connection loaders and resource adapter bindings
It looks like ResourceAdapterName is used to bind a connection factory loader to a deployed adapter's (as david mentioned). It also looks like if the connection factory specifies an invalid name (one that does not match up with the one in the ra.xml), that it will not complain and will not bind anything into JNDI. I found this out due to a typo in one of my JmsXA configurations. It should really complain about something in this case. --jason ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] persistance scheme
Hi, Â I want to know what persistance scheme is preferred these days. I am going to start a new project and evaluating Entity Bean, JDO, Castor etc. Its going to be a heavy-load site with lots of concurrent users. Â I will appreciate Pros and Cons of above options. Â Tony Grey
Re: [JBoss-dev] Stateful bean with different transaction context
Hi, Ill look at this more later... I think you also need in properties DataSourceClass= and maybe ConnectionURL=url=jdbc weird but maybe right. I'll try some things out later this evening. david jencks On 2001.08.16 18:04:28 -0400 Jason Dillon wrote: > I am using something like this: > > > ../deploy/lib, > ../deploy/bean1.jar, > ../deploy/bean2.jar > > > Since the beans are already urls ready for deploying they are added to > the > list right away. The lib directory is only scanned once a pass is made > on > run(), which will find some files, but append them after the urls that > are > explict. > > I fixed this by simply scanning the directories after adding the > directory > url to the watch list. > > It seems to work fine. > > I am having another problem with a NPE when trying to get a connection > from > the datasource, perhaps my config is wrong... but the logs do not really > tell me what is wrong, which I was looking into fixing. Below is my > config > if you could tell me what is wrong with it that would be swell: > > > name="DefaultDomain:service=ConnectionFactoryLoader,name=SharedDS"> > >ConnectionURL=jdbc:oracle:thin:@bendev:1521:BENDV > JDBCUser=jason > Password=jason > > >SharedDS > > >java:/TransactionManager > > >Minerva JDBC XATransaction ResourceAdapter > > JCA:service=RARDeployer > >MinervaXACMFactory > > >InvalidateOnError=false >Blocking=true >IdleTimeoutMillis=180 >MaxSize=10 >TimestampUsed=false >IdleTimeoutEnabled=false >GCIntervalMillis=12 >MinSize=0 >GCMinIdleMillis=120 >GCEnabled=false >MaxIdleTimeoutPercent=1.0 > > >org.jboss.resource.security.ManyToOnePrincipalMapping > > > > > > --jason > > > On Thu, 16 Aug 2001, David Jencks wrote: > > > Hi jason, I forgot about this problem. > > > > AutoDeploy works ok for me if the autodeployer conf looks like this: > > > >name="EJB:service=AutoDeployer"> > > > > JCA:service=RARDeployer; > > J2EE:service=J2eeDeployer > > > > > > ../deploy/lib, > > ../deploy > > > > > > 3000 > > > > > > > > Note that I reversed RARDeployer and J2eeDeployer as well as the > directory > > order. (For me just having ../deploy.lib before ../deploy worked, maybe > > reversing both will fix it for you). > > > > If this doesn't fix it for you could you send me your AutoDeployer > conf? > > > > thanks > > david > > > > On 2001.08.16 15:08:58 -0400 Jason Dillon wrote: > > > I just switched over and found one rather large problem, that is that > my > > > beans deploy before the resource adapters. It could be that I am > > > explicitly > > > listing the .jars to deploy, but I have the deploy/lib directory > listed > > > before it, so I expected that it would do the right thing. > > > > > > I think it will work if I touch all the files and force the auto > deployer > > > to > > > re-deploy once the datasources have been bound to jndi. > > > > > > Do you (or anyone else) have any ideas on how to fix this, or should > I > > > look > > > into it? > > > > > > --jason > > > > > > > > > On Wed, 15 Aug 2001, David Jencks wrote: > > > > > > > Hi Jason, could you try converting to the jca version of db access > and > > > see > > > > if the problem persists? I recently found a race condition in (the > jca > > > > versions) of the code that releases connections back to the pool > after > > > > transactions complete that was allowing several transactions to > access > > > the > > > > same connection. Maybe a similar bug is present in the non-jca > code. > > > I'm > > > > hoping to check in my "auto-converting-to-jca" XADatasourceLoader > later > > > > today, in case you don't want to try the conversion by hand. (this > race > > > fix > > > > is only in rabbit hole). > > > > > > > > Thanks > > > > david jencks > > > > > > > > On 2001.08.14 19:07:43 -0400 Jason Dillon wrote: > > > > > I was trying to track down a concurrency problem which would show > up > > > as > > > > > an > > > > > Oracle deadlock exception. It looks like that exception was > > > happening > > > > > due > > > > > to some fk constraints causing parent tables to lock and such. > Any > > > ways, > > > > > after I got that deadlock exception, I got a ton of these session > > > bean > > > > > context errors. > > > > > > > > > > I think that I have fixed the deadlock problem by removing some > of > > > the fk > > > > > constraints (which I don't like too much, but it stopped the > > > exception > > > > > from > > > > > being thrown), but I am still getting these errors. > > > > > > > > > > I thought they were caused by the oracle problem, but now I think > > > there > > > > > might be something else going on.
Re: [JBoss-dev] jbossmq module alias breaks access to previousbranches
On Thu, 16 Aug 2001, Scott M Stark wrote: > Due to the changes to the CVSROOT/modules file one can't checkout the 2.4 branch > of the jbossmq source using the previous syntax. The 2.4 branch needs to be checked > out using: > cvs co -r Branch_2_4 -P _jboss_messaging > which creates a messaging rather than jbossmq directory. > > Why not leave jbossmq as the legacy cvs module and introduce a new jboss-mq > module so as not to confuse the issue of accessing previous branches. It is fine with me, though I would suggest that such usage should be discoruaged. If folks want to work on just jbossmq, then get the standalone server. Perhaps if folks are only interested in working on one module at a time and don't really need the server to startup we could provide more jboss-* modules that provide the correct tools and thirdparty. That seems a bit excessive for the moment. A better long term solution would be to clean up the cvs namespace directly so that it was better support for CVSROOT/modules magic which does not interfer with vanilla cvs module checkouts. --jason ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] How to get MBeans to describe it's fields like aDynamicMBean does
> >Why not? Aren't DynamicMBeans easier to work with? I am actually a little > >confused about the different types, short of the basic MBean that > >implements a mgmt interface. > > > > NO they are harder to implement. A dynamic MBean has to explicitly export > all of it's managment interface. There is no *MBean interface class > required. But this means you have to code in all that info that would have > gone into the *MBean interface. How about writing a simple abstract DynamicMBean which would use reflection to get the mgmt interface. Or I think the Jetty JMX stuff exposes methods to the subclass which allow it to specify arrays of strings for attributes and operations, which the superclass would then use with reflection to generate the correct information. Or am I way off? > >Why do you need the interface for dynamic? > > Because writing the MBean interface file is easier than implementing a > DynamicMBean. This aproach though alows me to allso add description info to > my MBean interface (only available with DynamicMBeans). But once there is a common abstract to sub-class or a concreate wrapper (that would proxy to an object), that seems like it would be easier than the interface as well as provide more functionality. --jason ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jboss/src/main/org/jboss/ejb/plugins/jaws/jdbc JDBCFinderCommand.java
User: user57
Date: 01/08/16 15:23:30
Modified:src/main/org/jboss/ejb/plugins/jaws/jdbc
JDBCFinderCommand.java
Log:
o When execute() failes, log an error (instead of a debug) and throw
FinderException with more detail about the problem.
Revision ChangesPath
1.15 +14 -11
jboss/src/main/org/jboss/ejb/plugins/jaws/jdbc/JDBCFinderCommand.java
Index: JDBCFinderCommand.java
===
RCS file:
/cvsroot/jboss/jboss/src/main/org/jboss/ejb/plugins/jaws/jdbc/JDBCFinderCommand.java,v
retrieving revision 1.14
retrieving revision 1.15
diff -u -r1.14 -r1.15
--- JDBCFinderCommand.java2001/08/12 10:46:22 1.14
+++ JDBCFinderCommand.java2001/08/16 22:23:30 1.15
@@ -38,7 +38,7 @@
* @author mailto:[EMAIL PROTECTED]";>Joe Shevland
* @author mailto:[EMAIL PROTECTED]";>Justin Forder
* @author mailto:[EMAIL PROTECTED]";>Bill Burke
- * @version $Revision: 1.14 $
+ * @version $Revision: 1.15 $
*
* Revisions:
*
@@ -81,20 +81,23 @@
}
- /** This method must be overridden to return the where clause used in
-* this query. This must start with the keyword 'WHERE' and include all
-* conditions needed to execute the query properly.
+ /**
+* This method must be overridden to return the where clause used in
+* this query. This must start with the keyword 'WHERE' and include all
+* conditions needed to execute the query properly.
*/
public abstract String getWhereClause();
- /** This method must be ovverridden to return the full table list for
-* the query, including any join statements. This must start with the
-* keyword 'FROM' and include all tables needed to execute the query properly.
+ /**
+* This method must be ovverridden to return the full table list for
+* the query, including any join statements. This must start with the
+* keyword 'FROM' and include all tables needed to execute the query properly.
*/
public abstract String getFromClause();
- /** This method must be ovverridded to return the full order by clause for
-* the query, including the 'ORDER BY' keyword.
+ /**
+* This method must be ovverridded to return the full order by clause for
+* the query, including the 'ORDER BY' keyword.
*/
public abstract String getOrderByClause();
@@ -113,8 +116,8 @@
result = new FinderResults(keys, null, null, null);
} catch (Exception e)
{
- if (log.isDebugEnabled()) log.debug("Exception", e);
- throw new FinderException("Find failed");
+ log.error("Failed to create finder results", e);
+ throw new FinderException("Find failed: " + e);
}
return result;
___
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] DataSourceLoader...
In XAManagedConnectionFactory.getXADS() is returning null due to the return
null at the bottom of the method. It looks like this wants either an
xaDataSourceClass or xaDataSourceName to be set, if not it returns null.
Which then causes the pooling stuff to hang indefinently.
This is confusing me a little. Where do I specify these values? The
examples you gave were both based on the local tx stuff, but I want to use
the xa tx stuff.
Any advise? I am stuck in the water until I can get the DS back online.
--jason
On Thu, 16 Aug 2001, David Jencks wrote:
> ResourceAdapterName identifies which resource adapter supplies the
> ConnectionFactory (and ManagedConnectionFactory etc etc) for the
> ConnectionFactoryLoader to load. (It's the display-name tag in ra.xml) If
> you were using firebird as your database, this could be the firebird
> jca/jdbc driver. Since we are mostly stuck with jdbc only drivers, this is
> typically one of the 2 Minerva wrapper adapters. With the jdbc (local
> transaction) wrapper, the "Properties" attribute, which is for configuring
> the Resource Adapter, contains the db url which is enough to figure out
> which db driver we are using. With enough luck, mainstream db vendors will
> decide to supply jca .rar versions of their drivers soon so we don't always
> need the Minerva wrappers.
>
> david jencks
>
> On 2001.08.16 14:35:00 -0400 Jason Dillon wrote:
> > What is ResourceAdapterName used for?
> >
> > --jason
> >
> >
> > On Wed, 15 Aug 2001, David Jencks wrote:
> >
> > > Hi,
> > >
> > > This discussion comes up in various places on various lists. Since you
> > > don't mention otherwise I assume you are planning to decrypt in code
> > > without manual intervention. As I understand the consensus is, Don't
> > do
> > > this. You need some code to unencrypt the password to send it to the
> > db,
> > > if someone can find your jboss.jcml file they can find the unencryption
> > > code. Thus you have implemented only security by obscurity and only
> > > succeeded in making life harder for the users and probably given them a
> > > false sense of security, encouraging carelessness that a determined
> > hacker
> > > can exploit.
> > >
> > > Secrets and Lies by Bruce Schneier is fun to read and explains this
> > really
> > > well.
> > >
> > > If you want more security yet don't want to give each user their own
> > > password and have per-subject pools, how about writing a
> > > ConnectionFactoryLoader that pops up a password dialog on startup ( in
> > > initService). It's inconvenient, but at least it doesn't try to fool
> > > people into thinking their passwords are hidden. Of course, it could
> > be
> > > hard to figure out where to pop up the dialog...
> > >
> > > How about simply encrypting all of jboss.jcml say using pgp and
> > requiring a
> > > manually entered password to unencrypt to start jboss?
> > >
> > > In any case if you wish to modify the datasource loading procedure I
> > > suggest you work on the jca resource adapter version since
> > > {XA|JDBC}DataSourceLoader will not really exist in rh. (they will set
> > up
> > > connectionFactoryLoader mbeans).
> > >
> > > david jencks
> > >
> > > On 2001.08.14 19:12:14 -0400 "Ferguson, Doug" wrote:
> > > > What do you guys think about implemented a version of the DataSource
> > > > loader
> > > > that
> > > > allows for encrypted passwords?
> > > >
> > > > I am required to use encrypted db passwords..
> > > > And I was thinking that even if I encrypt once I write the jboss.jcml
> > > > It is now clear text again..
> > > >
> > > > d.
> > > >
> > > > ___
> > > > Jboss-development mailing list
> > > > [EMAIL PROTECTED]
> > > > http://lists.sourceforge.net/lists/listinfo/jboss-development
> > > >
> > > >
> > >
> > > ___
> > > Jboss-development mailing list
> > > [EMAIL PROTECTED]
> > > http://lists.sourceforge.net/lists/listinfo/jboss-development
> > >
> >
> >
> > ___
> > Jboss-development mailing list
> > [EMAIL PROTECTED]
> > http://lists.sourceforge.net/lists/listinfo/jboss-development
> >
> >
>
> ___
> Jboss-development mailing list
> [EMAIL PROTECTED]
> http://lists.sourceforge.net/lists/listinfo/jboss-development
>
___
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Stateful bean with different transaction context
I am using something like this: ../deploy/lib, ../deploy/bean1.jar, ../deploy/bean2.jar Since the beans are already urls ready for deploying they are added to the list right away. The lib directory is only scanned once a pass is made on run(), which will find some files, but append them after the urls that are explict. I fixed this by simply scanning the directories after adding the directory url to the watch list. It seems to work fine. I am having another problem with a NPE when trying to get a connection from the datasource, perhaps my config is wrong... but the logs do not really tell me what is wrong, which I was looking into fixing. Below is my config if you could tell me what is wrong with it that would be swell: ConnectionURL=jdbc:oracle:thin:@bendev:1521:BENDV JDBCUser=jason Password=jason SharedDS java:/TransactionManager Minerva JDBC XATransaction ResourceAdapter JCA:service=RARDeployer MinervaXACMFactory InvalidateOnError=false Blocking=true IdleTimeoutMillis=180 MaxSize=10 TimestampUsed=false IdleTimeoutEnabled=false GCIntervalMillis=12 MinSize=0 GCMinIdleMillis=120 GCEnabled=false MaxIdleTimeoutPercent=1.0 org.jboss.resource.security.ManyToOnePrincipalMapping --jason On Thu, 16 Aug 2001, David Jencks wrote: > Hi jason, I forgot about this problem. > > AutoDeploy works ok for me if the autodeployer conf looks like this: > > > > JCA:service=RARDeployer; > J2EE:service=J2eeDeployer > > > ../deploy/lib, > ../deploy > > > 3000 > > > > Note that I reversed RARDeployer and J2eeDeployer as well as the directory > order. (For me just having ../deploy.lib before ../deploy worked, maybe > reversing both will fix it for you). > > If this doesn't fix it for you could you send me your AutoDeployer conf? > > thanks > david > > On 2001.08.16 15:08:58 -0400 Jason Dillon wrote: > > I just switched over and found one rather large problem, that is that my > > beans deploy before the resource adapters. It could be that I am > > explicitly > > listing the .jars to deploy, but I have the deploy/lib directory listed > > before it, so I expected that it would do the right thing. > > > > I think it will work if I touch all the files and force the auto deployer > > to > > re-deploy once the datasources have been bound to jndi. > > > > Do you (or anyone else) have any ideas on how to fix this, or should I > > look > > into it? > > > > --jason > > > > > > On Wed, 15 Aug 2001, David Jencks wrote: > > > > > Hi Jason, could you try converting to the jca version of db access and > > see > > > if the problem persists? I recently found a race condition in (the jca > > > versions) of the code that releases connections back to the pool after > > > transactions complete that was allowing several transactions to access > > the > > > same connection. Maybe a similar bug is present in the non-jca code. > > I'm > > > hoping to check in my "auto-converting-to-jca" XADatasourceLoader later > > > today, in case you don't want to try the conversion by hand. (this race > > fix > > > is only in rabbit hole). > > > > > > Thanks > > > david jencks > > > > > > On 2001.08.14 19:07:43 -0400 Jason Dillon wrote: > > > > I was trying to track down a concurrency problem which would show up > > as > > > > an > > > > Oracle deadlock exception. It looks like that exception was > > happening > > > > due > > > > to some fk constraints causing parent tables to lock and such. Any > > ways, > > > > after I got that deadlock exception, I got a ton of these session > > bean > > > > context errors. > > > > > > > > I think that I have fixed the deadlock problem by removing some of > > the fk > > > > constraints (which I don't like too much, but it stopped the > > exception > > > > from > > > > being thrown), but I am still getting these errors. > > > > > > > > I thought they were caused by the oracle problem, but now I think > > there > > > > might be something else going on. > > > > > > > > Does anyone have any ideas on why this might happen, and or how I > > might > > > > go > > > > about fixing it? The TX stuff is still a bit of a mystery to me. > > Any > > > > help > > > > would be appreciated. > > > > > > > > Below is the log of the exception thrown. > > > > > > > > --jason > > > > > > > > > > > > 2001-08-14 15:59:52,726 org.jboss.ejb.plugins.LogInterceptor [Thread > > Pool > > > > Worker] ERROR - TRANSACTION ROLLBACK EXCEPTION: Application Error: > > tried > > > > to > > > > enter Stateful bean with different transaction context; nested > > exception > > > > is: > > > > java.rmi.RemoteException: Application Error: tried to enter > > > > St
[JBoss-dev] CVS update: jbosscx/src/main/org/jboss/resource RARDeployer.java
User: user57
Date: 01/08/16 14:49:11
Modified:src/main/org/jboss/resource RARDeployer.java
Log:
o use mkdirs() instead of mkdir() when creating the temp directory to avoid
exceptions when the base directory does not exist.
Revision ChangesPath
1.5 +6 -4 jbosscx/src/main/org/jboss/resource/RARDeployer.java
Index: RARDeployer.java
===
RCS file: /cvsroot/jboss/jbosscx/src/main/org/jboss/resource/RARDeployer.java,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -r1.4 -r1.5
--- RARDeployer.java 2001/07/25 09:47:46 1.4
+++ RARDeployer.java 2001/08/16 21:49:10 1.5
@@ -46,7 +46,7 @@
* service.
*
* @author Toby Allsopp ([EMAIL PROTECTED])
- * @version $Revision: 1.4 $
+ * @version $Revision: 1.5 $
*
* @see org.jboss.resource.ConnectionFactoryLoader
*
@@ -67,8 +67,10 @@
/** The directory that will contain local copies of deployed RARs */
private File rarTmpDir;
- /** The next sequence number to be used in notifications about
- (un)deployment */
+ /**
+* The next sequence number to be used in notifications about
+* (un)deployment
+*/
private int nextMessageNum = 0;
// Static
@@ -131,7 +133,7 @@
"the previous run. This might cause problems.");
}
}
- if (!rarTmpDir.exists() && !rarTmpDir.mkdir())
+ if (!rarTmpDir.exists() && !rarTmpDir.mkdirs())
{
throw new DeploymentException("Can't create temp directory '" +
rarTmpDir + "'");
___
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] For you license fanatics
-Original Message- From: Jamie Orchard-Hays [mailto:[EMAIL PROTECTED]] Sent: Thursday, August 16, 2001 5:24 PM To: Bill Burke; Francis Tilney Subject: Richard Stallman, control freak skip to "And now for some not so nice things." http://news.linuxprogramming.com/news_story.php3?ltsn=2001-08-16-002-06-LT ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] MDB has stopped working
I must apologise to all for my IDE's total lack of proper auto formating... Maybe Visual Age for Java 4.5 will get it right Regards, Hiram >From: David Maplesden <[EMAIL PROTECTED]> >Reply-To: [EMAIL PROTECTED] >To: "'[EMAIL PROTECTED]'" ><[EMAIL PROTECTED]> >Subject: RE: [JBoss-dev] MDB has stopped working >Date: Fri, 17 Aug 2001 08:46:01 +1200 > >Aww shucks, it was nothing... > >I must apologise to all and sundry re: my indenting. I have had my IDE set >up incorrectly and didn't realise I was confusing the files until just >recently. It doesn't help that jboss server is using 3 spaces and jboss mq >uses tabs... > >Cheers >david > > > -Original Message- > > From: Peter Antman [mailto:[EMAIL PROTECTED]] > > Sent: Thursday, August 16, 2001 8:24 PM > > To: [EMAIL PROTECTED] > > Cc: [EMAIL PROTECTED] > > Subject: Re: [JBoss-dev] MDB has stopped working > > > > > > Yea, your my man ;-) > > > > It's working really fine. I do think we now have a killer JBossMQ/MDB > > product. Great! > > > > I could not see any problems with the commits in the code I know any > > thing about (the JBoss server stuff), except the indentation in > > JMSContainerInvoker (which I will fix). > > > > //Peter > > > > > > On 16 Aug, David Maplesden wrote: > > > I ran things again this morning through JBuilder in debug > > mode and (although > > > I got the same ClassNotFoundExceptions ??) I did find a > > problem with the > > > undeploy. > > > > > > My system hung in the StdServerSessionPool.clear() method > > because it was > > > inside a synchronized(sessionPool) block when it called > > > executor.shutdownAfterProcessingCurrentlyQueuedTasks() > > which was waiting for > > > a number of WorkerThreads which were all trying to call > > > ServerSessionPool.recycle() and were blocked waiting for > > the sessionPool > > > monitor. Hence deadlock. So I introduced the closing flag > > in the clear > > > method. > > > > > > I also changed the order of closing things in the > > > JMSContainerInvoker.destroy() so that the > > ConnectionConsumer is closed > > > before the serverSessionPool is cleaned up. This is > > primarily because the > > > code I wrote for ConnectionConsumer assumes that > > serverSessions will always > > > be available from the pool if it waits long enough. If the > > serversession > > > pool is cleaned up before its close method is called then > > it might get > > > confused as to why it can't get a valid server session from > > the pool. > > > > > > A side effect of this second change is that it is 100% > > guaranteed that no > > > messages will be delivered to the server sessions in the > > pool after the > > > connection consumer is closed so it is no longer neccessary > > to stop the > > > connection before doing the other cleanup. Since it > > appears we only have 1 > > > connection per connectionConsumer in this set up this > > doesn't make much > > > difference here but if we were to have multiple consumers > > on a connection > > > you can close one of them down without affecting the others > > simply by > > > calling its close method and then cleaning up the server > > session pool. > > > > > > I also changed the clear() method to block until all > > ServerSessions had > > > returned to prevent the connection being closed (which > > closes the individual > > > sessions) before the sessions have finished executing. > > > > > > Essentially all these changes fell into the same category, > > race conditions > > > between the main thread which is cleaning up the mdb and > > the worker threads > > > processing the messages inside the ServerSessions and sessions. > > > > > > Since I made these changes to code I am not familiar I > > would appreciate it > > > if you would check I haven't overlooked anything in the > > changes I made. > > > > > > Again I hope these changes have fixed the bug. As far as I can tell > > > everything seems to work fine for me now. > > > > > > Cheers > > > david > > > > > > PS: I thought I'd take this off list as it seems like we > > two were the only > > > ones interested. > > > > > > > > >> -Original Message- > > >> From: Peter Antman [mailto:[EMAIL PROTECTED]] > > >> Sent: Thursday, August 16, 2001 1:26 AM > > >> To: [EMAIL PROTECTED] > > >> Subject: Re: [JBoss-dev] MDB has stopped working > > >> > > >> > > >> On 15 Aug, David Maplesden wrote: > > >> > Ok I have had a look at the Connection stopping process and > > >> have fixed a > > >> > loophole that could have resulted in messages being > > delivered after > > >> > connection.stop() had been called in certain circumstances. > > >> > > >> Hi, I am happy that you are trying to fix it. But the latest > > >> suff in CVS > > >> does not seem to fix the problem. > > >> > > >> > > > >> > I hope this fixes the MDB problem but as I have been unable > > >> to successfully > > >> > run the mdbtest (I keep getting ClassNotFoundExceptions from the > > >> > ObjectMessageBean) I can't say for sure if it has. I am > > >> n
Re: [JBoss-dev] Stateful bean with different transaction context
Hi jason, I forgot about this problem. AutoDeploy works ok for me if the autodeployer conf looks like this: JCA:service=RARDeployer; J2EE:service=J2eeDeployer ../deploy/lib, ../deploy 3000 Note that I reversed RARDeployer and J2eeDeployer as well as the directory order. (For me just having ../deploy.lib before ../deploy worked, maybe reversing both will fix it for you). If this doesn't fix it for you could you send me your AutoDeployer conf? thanks david On 2001.08.16 15:08:58 -0400 Jason Dillon wrote: > I just switched over and found one rather large problem, that is that my > beans deploy before the resource adapters. It could be that I am > explicitly > listing the .jars to deploy, but I have the deploy/lib directory listed > before it, so I expected that it would do the right thing. > > I think it will work if I touch all the files and force the auto deployer > to > re-deploy once the datasources have been bound to jndi. > > Do you (or anyone else) have any ideas on how to fix this, or should I > look > into it? > > --jason > > > On Wed, 15 Aug 2001, David Jencks wrote: > > > Hi Jason, could you try converting to the jca version of db access and > see > > if the problem persists? I recently found a race condition in (the jca > > versions) of the code that releases connections back to the pool after > > transactions complete that was allowing several transactions to access > the > > same connection. Maybe a similar bug is present in the non-jca code. > I'm > > hoping to check in my "auto-converting-to-jca" XADatasourceLoader later > > today, in case you don't want to try the conversion by hand. (this race > fix > > is only in rabbit hole). > > > > Thanks > > david jencks > > > > On 2001.08.14 19:07:43 -0400 Jason Dillon wrote: > > > I was trying to track down a concurrency problem which would show up > as > > > an > > > Oracle deadlock exception. It looks like that exception was > happening > > > due > > > to some fk constraints causing parent tables to lock and such. Any > ways, > > > after I got that deadlock exception, I got a ton of these session > bean > > > context errors. > > > > > > I think that I have fixed the deadlock problem by removing some of > the fk > > > constraints (which I don't like too much, but it stopped the > exception > > > from > > > being thrown), but I am still getting these errors. > > > > > > I thought they were caused by the oracle problem, but now I think > there > > > might be something else going on. > > > > > > Does anyone have any ideas on why this might happen, and or how I > might > > > go > > > about fixing it? The TX stuff is still a bit of a mystery to me. > Any > > > help > > > would be appreciated. > > > > > > Below is the log of the exception thrown. > > > > > > --jason > > > > > > > > > 2001-08-14 15:59:52,726 org.jboss.ejb.plugins.LogInterceptor [Thread > Pool > > > Worker] ERROR - TRANSACTION ROLLBACK EXCEPTION: Application Error: > tried > > > to > > > enter Stateful bean with different transaction context; nested > exception > > > is: > > > java.rmi.RemoteException: Application Error: tried to enter > > > Stateful > > > bean with different transaction context > > > > > > ... > > > > > > 2001-08-14 15:59:52,842 org.jboss.ejb.plugins.LogInterceptor [Thread > Pool > > > Worker] ERROR - Detail > > > java.rmi.RemoteException: Application Error: tried to enter Stateful > bean > > > with different transaction context > > > at > > > >org.jboss.ejb.plugins.StatefulSessionInstanceInterceptor.invoke(StatefulSessionInstanceInterceptor.java:207) > > > at > > > >org.jboss.ejb.plugins.AbstractTxInterceptor.invokeNext(AbstractTxInterceptor.java:97) > > > at > > > >org.jboss.ejb.plugins.TxInterceptorCMT.runWithTransactions(TxInterceptorCMT.java:154) > > > at > > > org.jboss.ejb.plugins.TxInterceptorCMT.invoke(TxInterceptorCMT.java:63) > > > at > > > org.jboss.ejb.plugins.LogInterceptor.invoke(LogInterceptor.java:168) > > > at > > > org.jboss.ejb.StatefulSessionContainer.invoke(StatefulSessionContainer.java:354) > > > at > > > >org.jboss.ejb.plugins.jrmp.server.JRMPContainerInvoker.invoke(JRMPContainerInvoker.java:445) > > > at > > > >org.jboss.ejb.plugins.jrmp.interfaces.GenericProxy.invokeContainer(GenericProxy.java:339) > > > at > > > >org.jboss.ejb.plugins.jrmp.interfaces.StatefulSessionProxy.invoke(StatefulSessionProxy.java:136) > > > at $Proxy28.handle(Unknown Source) > > > at > > > >com.boldfish.does.job.service.internal.ResponseProcessorEJB.process(ResponseProcessorEJB.java:152) > > > at > > > >com.boldfish.ejb.AbstractMessageDrivenBean.onMessage(AbstractMessageDrivenBean.java:132) > > > at java.lang.reflect.Method.invoke(Native Method) > > > at > > > >org.jboss.ejb.MessageDrivenContainer$ContainerInterceptor.invoke(MessageDrivenContainer.java:410) > > >
Re: [JBoss-dev] How to get MBeans to describe it's fields like a DynamicMBean does
>From: Jason Dillon <[EMAIL PROTECTED]> >Reply-To: [EMAIL PROTECTED] >To: <[EMAIL PROTECTED]> >Subject: Re: [JBoss-dev] How to get MBeans to describe it's fields like a >DynamicMBean does >Date: Thu, 16 Aug 2001 09:29:01 -0700 (PDT) > >On Tue, 14 Aug 2001, Hiram Chirino wrote: > > I was looking for a way to fill in those description fields that > > DynamicMBeans can fill out. But I did not want to have to replace all >the > > JBossMQ MBeans with DynamicMBeans. So this is what I did: > >Why not? Aren't DynamicMBeans easier to work with? I am actually a little >confused about the different types, short of the basic MBean that >implements a mgmt interface. > NO they are harder to implement. A dynamic MBean has to explicitly export all of it's managment interface. There is no *MBean interface class required. But this means you have to code in all that info that would have gone into the *MBean interface. > > I created a new class called WrapperMBean and it extends > > NotificationBroadcasterSupport and implements DynamicMBean. > > I changed ServiceMBeanSupport so that it extends this new WrapperMBean. > > > > The WrapperMBean uses reflection to build the basic MBeanInfo object >using > > the MBean interface classes. But it arguments it will the description > > information it finds a MBeanInfo.properties resource file. > >Cool. > > > I was aming at not having to change how service classes defined thier >MBean > > interface (But if you optionaly includes a the MBeanInfo.properties >file > > it would be used). Well.. it almost worked out that way.. but because >JMX > > gets a little confused trying to determin if a bean is MBean or a > > DynamicMBean, the reality is that I had to rename my service's MBean > > interface to EMBean and also had to add a 'implements DynamicMBean' >to > > my service class. This was a real bummer (not so clean) > >Why do you need the interface for dynamic? > Because writing the MBean interface file is easier than implementing a DynamicMBean. This aproach though alows me to allso add description info to my MBean interface (only available with DynamicMBeans). Regards, Hiram _ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] jbossmq module alias breaks access to previous branches
Due to the changes to the CVSROOT/modules file one can't checkout the 2.4 branch of the jbossmq source using the previous syntax. The 2.4 branch needs to be checked out using:    cvs co -r Branch_2_4 -P _jboss_messaging which creates a messaging rather than jbossmq directory.  Why not leave jbossmq as the legacy cvs module and introduce a new jboss-mq module so as not to confuse the issue of accessing previous branches. Â
Re: [JBoss-dev] Stateful bean with different transaction context
On Thu, 16 Aug 2001, David Jencks wrote: > Yes, as far as I can tell the user and password go into the > PrincipalMappingProperties. There is probably some way to get them into > somewhere else but I haven't figured it out yet. They are certainly used > if in the PrincipalMappingProperties. I will try that, do I need any other config? > btw. thanks for cleaning up my xml. Do you have a tool or are you a very > neat typist? I am anal. =) --jason ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jboss/src/main/org/jboss/ejb AutoDeployer.java
User: user57
Date: 01/08/16 14:24:48
Modified:src/main/org/jboss/ejb AutoDeployer.java
Log:
o changed Category to JBossCategory and the "Wait for..." message priority to
trace.
o factored directory scanning out of run() into scanDirectories() and
scanDirectory().
o changed startService() to scanDirectory() on each watched directory, so
that deployments can be ordered (at least with respect to other urls
that are specified).
Revision ChangesPath
1.22 +95 -56jboss/src/main/org/jboss/ejb/AutoDeployer.java
Index: AutoDeployer.java
===
RCS file: /cvsroot/jboss/jboss/src/main/org/jboss/ejb/AutoDeployer.java,v
retrieving revision 1.21
retrieving revision 1.22
diff -u -r1.21 -r1.22
--- AutoDeployer.java 2001/08/15 15:13:45 1.21
+++ AutoDeployer.java 2001/08/16 21:24:48 1.22
@@ -25,9 +25,8 @@
import javax.management.RuntimeErrorException;
import javax.management.RuntimeMBeanException;
-import org.apache.log4j.Category;
-
import org.jboss.util.ServiceMBeanSupport;
+import org.jboss.logging.log4j.JBossCategory;
/**
* The AutoDeployer is used to automatically deploy applications or
@@ -44,10 +43,11 @@
*configured deployer to deploy it.
*
* @see org.jboss.deployment.J2eeDeployer
+ *
* @author mailto:[EMAIL PROTECTED]";>Rickard Öberg
* @author mailto:[EMAIL PROTECTED]";>Toby Allsopp
* @author mailto:[EMAIL PROTECTED]";>Jason Dillon
- * @version $Revision: 1.21 $
+ * @version $Revision: 1.22 $
*/
public class AutoDeployer
extends ServiceMBeanSupport
@@ -58,42 +58,46 @@
// Attributes
/** Instance logger. */
- private Category log = Category.getInstance(this.getClass());
+ private JBossCategory log = (JBossCategory)
+ JBossCategory.getInstance(this.getClass());
- // Callback to the JMX agent
+ /** Callback to the JMX agent. */
MBeanServer server;
- // in case more then one J2eeDeployers are available
+ /** In case more then one J2eeDeployers are available. */
String deployerList = "";
/** JMX names of the configured deployers */
ObjectName[] deployerNames;
- // The watch thread
+ /** The watch thread. */
boolean running = false;
- // Watch these directories for new files
+ /** Watch these directories for new files. */
ArrayList watchedDirectories = new ArrayList();
- // These URL's have been deployed. Check for new timestamp
+ /** These URL's have been deployed. Check for new timestamp. */
HashMap deployedURLs = new HashMap();
- // These URL's are being watched
+ /** These URL's are being watched. */
ArrayList watchedURLs = new ArrayList();
- // URL list
+ /** URL list. */
String urlList = "";
- // TimeOut that in case of big ears to deploy should be set high enough
+ /** TimeOut that in case of big ears to deploy should be set high enough. */
int timeout = 3000;
- /** Filters, one per configured deployer, to decide which files are
- deployable and which should be ignored */
- FilenameFilter[] deployableFilters = null;
+ /**
+* Filters, one per configured deployer, to decide which files are
+* deployable and which should be ignored.
+*/
+ FilenameFilter[] deployableFilters; // = null;
// Static
// Constructors --
+
public AutoDeployer()
{
this("");
@@ -101,7 +105,7 @@
public AutoDeployer(String urlList)
{
- this ("J2EE:service=J2eeDeployer", urlList);
+ this("J2EE:service=J2eeDeployer", urlList);
}
public AutoDeployer(String _namedDeployer, String urlList)
@@ -141,6 +145,7 @@
}
// Public
+
public void run()
{
do
@@ -150,41 +155,21 @@
{
try
{
- if (log.isDebugEnabled()) log.debug("Wait for "+timeout / 1000 +"
seconds");
+ if (log.isTraceEnabled()) {
+ log.trace("Wait for "+timeout / 1000 +" seconds");
+ }
Thread.sleep(timeout);
-} catch (InterruptedException e) {}
+} catch (InterruptedException e) {
+ log.debug("interrupted; ignoring", e);
+}
}
try
{
// Check directories - add new entries to list of files
-for (int i = 0; i < watchedDirectories.size(); i++)
-{
- File dir = (File)watchedDirectories.get(i);
-
Re: [JBoss-dev] DataSourceLoader...
ResourceAdapterName identifies which resource adapter supplies the
ConnectionFactory (and ManagedConnectionFactory etc etc) for the
ConnectionFactoryLoader to load. (It's the display-name tag in ra.xml) If
you were using firebird as your database, this could be the firebird
jca/jdbc driver. Since we are mostly stuck with jdbc only drivers, this is
typically one of the 2 Minerva wrapper adapters. With the jdbc (local
transaction) wrapper, the "Properties" attribute, which is for configuring
the Resource Adapter, contains the db url which is enough to figure out
which db driver we are using. With enough luck, mainstream db vendors will
decide to supply jca .rar versions of their drivers soon so we don't always
need the Minerva wrappers.
david jencks
On 2001.08.16 14:35:00 -0400 Jason Dillon wrote:
> What is ResourceAdapterName used for?
>
> --jason
>
>
> On Wed, 15 Aug 2001, David Jencks wrote:
>
> > Hi,
> >
> > This discussion comes up in various places on various lists. Since you
> > don't mention otherwise I assume you are planning to decrypt in code
> > without manual intervention. As I understand the consensus is, Don't
> do
> > this. You need some code to unencrypt the password to send it to the
> db,
> > if someone can find your jboss.jcml file they can find the unencryption
> > code. Thus you have implemented only security by obscurity and only
> > succeeded in making life harder for the users and probably given them a
> > false sense of security, encouraging carelessness that a determined
> hacker
> > can exploit.
> >
> > Secrets and Lies by Bruce Schneier is fun to read and explains this
> really
> > well.
> >
> > If you want more security yet don't want to give each user their own
> > password and have per-subject pools, how about writing a
> > ConnectionFactoryLoader that pops up a password dialog on startup ( in
> > initService). It's inconvenient, but at least it doesn't try to fool
> > people into thinking their passwords are hidden. Of course, it could
> be
> > hard to figure out where to pop up the dialog...
> >
> > How about simply encrypting all of jboss.jcml say using pgp and
> requiring a
> > manually entered password to unencrypt to start jboss?
> >
> > In any case if you wish to modify the datasource loading procedure I
> > suggest you work on the jca resource adapter version since
> > {XA|JDBC}DataSourceLoader will not really exist in rh. (they will set
> up
> > connectionFactoryLoader mbeans).
> >
> > david jencks
> >
> > On 2001.08.14 19:12:14 -0400 "Ferguson, Doug" wrote:
> > > What do you guys think about implemented a version of the DataSource
> > > loader
> > > that
> > > allows for encrypted passwords?
> > >
> > > I am required to use encrypted db passwords..
> > > And I was thinking that even if I encrypt once I write the jboss.jcml
> > > It is now clear text again..
> > >
> > > d.
> > >
> > > ___
> > > Jboss-development mailing list
> > > [EMAIL PROTECTED]
> > > http://lists.sourceforge.net/lists/listinfo/jboss-development
> > >
> > >
> >
> > ___
> > Jboss-development mailing list
> > [EMAIL PROTECTED]
> > http://lists.sourceforge.net/lists/listinfo/jboss-development
> >
>
>
> ___
> Jboss-development mailing list
> [EMAIL PROTECTED]
> http://lists.sourceforge.net/lists/listinfo/jboss-development
>
>
___
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Stateful bean with different transaction context
Yes, as far as I can tell the user and password go into the PrincipalMappingProperties. There is probably some way to get them into somewhere else but I haven't figured it out yet. They are certainly used if in the PrincipalMappingProperties. btw. thanks for cleaning up my xml. Do you have a tool or are you a very neat typist? Thanks david On 2001.08.16 15:12:01 -0400 Jason Dillon wrote: > Where should I put JDBCUser and Password now? Should they go into > PrincipalMappingProperties? Do I need to do anything else to make that > work. I have been ignoring the security stuff for the most part, since I > do > not really understand it, and it is not currently required. > > Any ways, I tried just dropping those into Properties and I *think* it > works. Just curious. > > --jason > > On Wed, 15 Aug 2001, David Jencks wrote: > > > Hi Jason, could you try converting to the jca version of db access and > see > > if the problem persists? I recently found a race condition in (the jca > > versions) of the code that releases connections back to the pool after > > transactions complete that was allowing several transactions to access > the > > same connection. Maybe a similar bug is present in the non-jca code. > I'm > > hoping to check in my "auto-converting-to-jca" XADatasourceLoader later > > today, in case you don't want to try the conversion by hand. (this race > fix > > is only in rabbit hole). > > > > Thanks > > david jencks > > > > On 2001.08.14 19:07:43 -0400 Jason Dillon wrote: > > > I was trying to track down a concurrency problem which would show up > as > > > an > > > Oracle deadlock exception. It looks like that exception was > happening > > > due > > > to some fk constraints causing parent tables to lock and such. Any > ways, > > > after I got that deadlock exception, I got a ton of these session > bean > > > context errors. > > > > > > I think that I have fixed the deadlock problem by removing some of > the fk > > > constraints (which I don't like too much, but it stopped the > exception > > > from > > > being thrown), but I am still getting these errors. > > > > > > I thought they were caused by the oracle problem, but now I think > there > > > might be something else going on. > > > > > > Does anyone have any ideas on why this might happen, and or how I > might > > > go > > > about fixing it? The TX stuff is still a bit of a mystery to me. > Any > > > help > > > would be appreciated. > > > > > > Below is the log of the exception thrown. > > > > > > --jason > > > > > > > > > 2001-08-14 15:59:52,726 org.jboss.ejb.plugins.LogInterceptor [Thread > Pool > > > Worker] ERROR - TRANSACTION ROLLBACK EXCEPTION: Application Error: > tried > > > to > > > enter Stateful bean with different transaction context; nested > exception > > > is: > > > java.rmi.RemoteException: Application Error: tried to enter > > > Stateful > > > bean with different transaction context > > > > > > ... > > > > > > 2001-08-14 15:59:52,842 org.jboss.ejb.plugins.LogInterceptor [Thread > Pool > > > Worker] ERROR - Detail > > > java.rmi.RemoteException: Application Error: tried to enter Stateful > bean > > > with different transaction context > > > at > > > >org.jboss.ejb.plugins.StatefulSessionInstanceInterceptor.invoke(StatefulSessionInstanceInterceptor.java:207) > > > at > > > >org.jboss.ejb.plugins.AbstractTxInterceptor.invokeNext(AbstractTxInterceptor.java:97) > > > at > > > >org.jboss.ejb.plugins.TxInterceptorCMT.runWithTransactions(TxInterceptorCMT.java:154) > > > at > > > org.jboss.ejb.plugins.TxInterceptorCMT.invoke(TxInterceptorCMT.java:63) > > > at > > > org.jboss.ejb.plugins.LogInterceptor.invoke(LogInterceptor.java:168) > > > at > > > org.jboss.ejb.StatefulSessionContainer.invoke(StatefulSessionContainer.java:354) > > > at > > > >org.jboss.ejb.plugins.jrmp.server.JRMPContainerInvoker.invoke(JRMPContainerInvoker.java:445) > > > at > > > >org.jboss.ejb.plugins.jrmp.interfaces.GenericProxy.invokeContainer(GenericProxy.java:339) > > > at > > > >org.jboss.ejb.plugins.jrmp.interfaces.StatefulSessionProxy.invoke(StatefulSessionProxy.java:136) > > > at $Proxy28.handle(Unknown Source) > > > at > > > >com.boldfish.does.job.service.internal.ResponseProcessorEJB.process(ResponseProcessorEJB.java:152) > > > at > > > >com.boldfish.ejb.AbstractMessageDrivenBean.onMessage(AbstractMessageDrivenBean.java:132) > > > at java.lang.reflect.Method.invoke(Native Method) > > > at > > > >org.jboss.ejb.MessageDrivenContainer$ContainerInterceptor.invoke(MessageDrivenContainer.java:410) > > > at > > > >org.jboss.ejb.plugins.MessageDrivenInstanceInterceptor.invoke(MessageDrivenInstanceInterceptor.java:79) > > > at > > > >org.jboss.ejb.plugins.AbstractTxInterceptor.invokeNext(AbstractTxInterceptor.java:97) > > > at > > > >org.jboss.ejb.plugins.TxInterceptorCMT.runWithTransactions(TxInterc
Re: [JBoss-dev] [ jboss-Feature Requests-451610 ] JavaSpaces implementation
On 2001.08.16 15:35:22 -0400 Jason Dillon wrote: > > I've been thinking a little bit about a jca adapter to a javaspace, set > up > > Wouldn't you have to make an adapter to the jini tx service? or would > the > jca adapter to a space deal with all the tx under the covers (and ignore > client requests to do it). thinking about this a little more... I think there are 2 options: 1. javaspaces as essentially mom. Here the "ejb" transaction is tied to the jini transaction, so commit in the ejb container commits the put or take to the javaspace. Someone else in a different transaction is responsible for the other operation. 2. javaspaces as a more or less transparent or invisible way of doing clustering/distributed computing, with something like rpc semantics. Here ejb1 calls a method on ejb2 within transaction t1. ejb2 is on a different server(s), say server2 connected by a javaspace balancing the load. The container packs up the ejb transaction t1 with the method invocation info into an entry, and puts it in the javaspace with a jini transaction that completes immediately. (well, you could pack up several method calls and do them all at once within the same transaction... although how you'd specify this I have no idea). Some invoker on server2 is always trying to take appropriate entries from the space, when it gets one it unpacks the transaction and method invocation and does it. The return value follows a similar route back to ejb1. Here there is one (t1) ejb transaction but 3 jini transactions: -ejb1 puts entry -ejb2 takes entry and puts method return value -ejb1 takes return value. I'm not quite sure how committing t1 is transmitted to all necessary servers in this scheme. This scheme does supply good failover characteristics, if ejb2 crashes in the midst of its method invocation its jini transaction taking the method invocation entry will expire, so someone else can try. > > > so you can use JAWS, with entity bean <--> entry. I'm not entirely > sure > > I am not sure that you would want to use javaspaces for persistent entity > storage, but perhaps someone does... not sure. I wasn't thinking of persistent entity storage, I was looking for a declarative code-free way of inserting entries into a javaspace. I wonder how this would work with jms also. > > > yet what advantages this would have over jms. I'm also not clear about > what > > would fetch entries out of the javaspace. > > javaspaces are a different kind of animal than jms. the looks semantics > of > entries are vastly different. whiteboard-like apps are much better > adapted > for a space design than with queued messages, but either would work. > > I think it is all about options. If it is easy to do and or you have > sufficient motivation to do it... then by all means =) I am positive > that > if there were javaspaces and other jini service plugins to jboss that > people > would use them. I sure would. > > > Maybe jca 2 will help, I think it is supposed to have "push" events. > > When is this due to enter reality? Dont know -- it looks to me as if bea is designing the spec themselves and releasing their implementation before the spec is released. This is only my guess, I have no real evidence for this, but their jca stuff appears to include some features from what jca 2 is supposed to cover. > > --jason > > > ___ > Jboss-development mailing list > [EMAIL PROTECTED] > http://lists.sourceforge.net/lists/listinfo/jboss-development > > ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] MDB has stopped working
Aww shucks, it was nothing... I must apologise to all and sundry re: my indenting. I have had my IDE set up incorrectly and didn't realise I was confusing the files until just recently. It doesn't help that jboss server is using 3 spaces and jboss mq uses tabs... Cheers david > -Original Message- > From: Peter Antman [mailto:[EMAIL PROTECTED]] > Sent: Thursday, August 16, 2001 8:24 PM > To: [EMAIL PROTECTED] > Cc: [EMAIL PROTECTED] > Subject: Re: [JBoss-dev] MDB has stopped working > > > Yea, your my man ;-) > > It's working really fine. I do think we now have a killer JBossMQ/MDB > product. Great! > > I could not see any problems with the commits in the code I know any > thing about (the JBoss server stuff), except the indentation in > JMSContainerInvoker (which I will fix). > > //Peter > > > On 16 Aug, David Maplesden wrote: > > I ran things again this morning through JBuilder in debug > mode and (although > > I got the same ClassNotFoundExceptions ??) I did find a > problem with the > > undeploy. > > > > My system hung in the StdServerSessionPool.clear() method > because it was > > inside a synchronized(sessionPool) block when it called > > executor.shutdownAfterProcessingCurrentlyQueuedTasks() > which was waiting for > > a number of WorkerThreads which were all trying to call > > ServerSessionPool.recycle() and were blocked waiting for > the sessionPool > > monitor. Hence deadlock. So I introduced the closing flag > in the clear > > method. > > > > I also changed the order of closing things in the > > JMSContainerInvoker.destroy() so that the > ConnectionConsumer is closed > > before the serverSessionPool is cleaned up. This is > primarily because the > > code I wrote for ConnectionConsumer assumes that > serverSessions will always > > be available from the pool if it waits long enough. If the > serversession > > pool is cleaned up before its close method is called then > it might get > > confused as to why it can't get a valid server session from > the pool. > > > > A side effect of this second change is that it is 100% > guaranteed that no > > messages will be delivered to the server sessions in the > pool after the > > connection consumer is closed so it is no longer neccessary > to stop the > > connection before doing the other cleanup. Since it > appears we only have 1 > > connection per connectionConsumer in this set up this > doesn't make much > > difference here but if we were to have multiple consumers > on a connection > > you can close one of them down without affecting the others > simply by > > calling its close method and then cleaning up the server > session pool. > > > > I also changed the clear() method to block until all > ServerSessions had > > returned to prevent the connection being closed (which > closes the individual > > sessions) before the sessions have finished executing. > > > > Essentially all these changes fell into the same category, > race conditions > > between the main thread which is cleaning up the mdb and > the worker threads > > processing the messages inside the ServerSessions and sessions. > > > > Since I made these changes to code I am not familiar I > would appreciate it > > if you would check I haven't overlooked anything in the > changes I made. > > > > Again I hope these changes have fixed the bug. As far as I can tell > > everything seems to work fine for me now. > > > > Cheers > > david > > > > PS: I thought I'd take this off list as it seems like we > two were the only > > ones interested. > > > > > >> -Original Message- > >> From: Peter Antman [mailto:[EMAIL PROTECTED]] > >> Sent: Thursday, August 16, 2001 1:26 AM > >> To: [EMAIL PROTECTED] > >> Subject: Re: [JBoss-dev] MDB has stopped working > >> > >> > >> On 15 Aug, David Maplesden wrote: > >> > Ok I have had a look at the Connection stopping process and > >> have fixed a > >> > loophole that could have resulted in messages being > delivered after > >> > connection.stop() had been called in certain circumstances. > >> > >> Hi, I am happy that you are trying to fix it. But the latest > >> suff in CVS > >> does not seem to fix the problem. > >> > >> > > >> > I hope this fixes the MDB problem but as I have been unable > >> to successfully > >> > run the mdbtest (I keep getting ClassNotFoundExceptions from the > >> > ObjectMessageBean) I can't say for sure if it has. I am > >> not actually 100% > >> > clear on what the expected output of the test is, there > >> seems to be one Bean > >> > (ExQueueBean) that throws Exceptions on purpose, yes? > >> > > >> > I am confused as to why I can't run the mdbtest correctly. > >> I built the > >> > jboss source from scratch and then the testsuite. I have > >> checked the > >> > mdbtest.jar and mdb.jar files to see that they contain the > >> same version of > >> > the CustomMessage class that is used in the mdbtest so why > >> the server can't > >> > find the CustomMessag
Re: [JBoss-dev] Container.java
True, I did not remeber that. Any ways I think you get my point. --jason On Thu, 16 Aug 2001, Andreas Schaefer wrote: > I personally think that the domain should be structured but for your > example a colon (:) is not possible because it is reserved for the JMX > Object Name. > > Andy > > - Original Message - > From: "Jason Dillon" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Sent: Thursday, August 16, 2001 12:17 PM > Subject: Re: [JBoss-dev] Container.java > > > > Can you provide an example for what this might look like? I am thinking > > something url like, but I am not sure what the spec will allow for a > domain > > name. So the domain for the jms stuff might look like this: > > > > myhost.mydomain.com:/supercluster/jboss/jms > > ^^^ ^ > > hostname cluster group > > > > Where cluster and group are rather arbitrary, but allow for a hierarchy of > > stuff on each machine. > > > > Just a thought. > > > > --jason > > > > > > On Thu, 16 Aug 2001, Andreas Schaefer wrote: > > > > > Hi Jasson > > > > > > Yes, I plan to reorganize the MBean Object Names for the implementation > > > of the server-side JBossMGT. > > > According to their spec it would be maybe good to have something like > this: > > > - domain: is the JBoss server instance which can be default be the host > > > computer > > >name but should be able to renamed > > > - properties: > > > - group: where this component belongs to > > > - type: type of component > > > - name: name of the component > > > > > > The domain should keep an unique name on the network / management domain > > > because we maybe use a federation to access MBeans and then it is > important > > > to have this. > > > > > > Andy > > > > > > - Original Message - > > > From: "Jason Dillon" <[EMAIL PROTECTED]> > > > To: <[EMAIL PROTECTED]> > > > Sent: Thursday, August 16, 2001 9:42 AM > > > Subject: Re: [JBoss-dev] Container.java > > > > > > > > > > Is there a general guide line for domain usage under jmx? Are there > any > > > > plans to exploit this in a more organized manner? Should domain refer > to > > > > components on a single agent, or cross multiple agents? For example > in a > > > > clustered environment, domain could refer to a particular node group, > or > > > > could simply refer to a group of components on a single node. > > > > > > > > I am thinking that the jmx domain fluff might bet best left as a node > > > > component grouping tools, and leave node grouping up to higher level > > > > organizations (like jini and such). > > > > > > > > Any ways, this is going to be important for the upcoming RH stuff to > > > provide > > > > a consistent and rich configuration of JBoss nodes in a farm or > clustered > > > > environment. > > > > > > > > --jason > > > > > > > > > > > > ___ > > > Jboss-development mailing list > > > [EMAIL PROTECTED] > > > http://lists.sourceforge.net/lists/listinfo/jboss-development > > > > > > > > > ___ > > Jboss-development mailing list > > [EMAIL PROTECTED] > > http://lists.sourceforge.net/lists/listinfo/jboss-development > > > > > ___ > Jboss-development mailing list > [EMAIL PROTECTED] > http://lists.sourceforge.net/lists/listinfo/jboss-development > ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Container.java
I personally think that the domain should be structured but for your example a colon (:) is not possible because it is reserved for the JMX Object Name. Andy - Original Message - From: "Jason Dillon" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Thursday, August 16, 2001 12:17 PM Subject: Re: [JBoss-dev] Container.java > Can you provide an example for what this might look like? I am thinking > something url like, but I am not sure what the spec will allow for a domain > name. So the domain for the jms stuff might look like this: > > myhost.mydomain.com:/supercluster/jboss/jms > ^^^ ^ > hostname cluster group > > Where cluster and group are rather arbitrary, but allow for a hierarchy of > stuff on each machine. > > Just a thought. > > --jason > > > On Thu, 16 Aug 2001, Andreas Schaefer wrote: > > > Hi Jasson > > > > Yes, I plan to reorganize the MBean Object Names for the implementation > > of the server-side JBossMGT. > > According to their spec it would be maybe good to have something like this: > > - domain: is the JBoss server instance which can be default be the host > > computer > >name but should be able to renamed > > - properties: > > - group: where this component belongs to > > - type: type of component > > - name: name of the component > > > > The domain should keep an unique name on the network / management domain > > because we maybe use a federation to access MBeans and then it is important > > to have this. > > > > Andy > > > > - Original Message - > > From: "Jason Dillon" <[EMAIL PROTECTED]> > > To: <[EMAIL PROTECTED]> > > Sent: Thursday, August 16, 2001 9:42 AM > > Subject: Re: [JBoss-dev] Container.java > > > > > > > Is there a general guide line for domain usage under jmx? Are there any > > > plans to exploit this in a more organized manner? Should domain refer to > > > components on a single agent, or cross multiple agents? For example in a > > > clustered environment, domain could refer to a particular node group, or > > > could simply refer to a group of components on a single node. > > > > > > I am thinking that the jmx domain fluff might bet best left as a node > > > component grouping tools, and leave node grouping up to higher level > > > organizations (like jini and such). > > > > > > Any ways, this is going to be important for the upcoming RH stuff to > > provide > > > a consistent and rich configuration of JBoss nodes in a farm or clustered > > > environment. > > > > > > --jason > > > > > > > > ___ > > Jboss-development mailing list > > [EMAIL PROTECTED] > > http://lists.sourceforge.net/lists/listinfo/jboss-development > > > > > ___ > Jboss-development mailing list > [EMAIL PROTECTED] > http://lists.sourceforge.net/lists/listinfo/jboss-development > ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] AutoDeployer [Auto deploy] DEBUG - Wait for 3 seconds
This was just added by vharcq so I was not seeing it because I did not have the latest code. Messages like this should be using trace level priorities through the custom JBossCategory which will become Logger next week. - Original Message - From: "Jason Dillon" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Thursday, August 16, 2001 11:53 AM Subject: Re: [JBoss-dev] AutoDeployer [Auto deploy] DEBUG - Wait for 3 seconds > Do you have debug enabled? I currently have org.jboss = debug, which > produces a lot of stuff, but this is a bit excessive I believe. > > --jason > > > On Thu, 16 Aug 2001, Scott M Stark wrote: > > > There is no such msg in main. Where are you seeing this? > > > > - Original Message - > > From: "Jason Dillon" <[EMAIL PROTECTED]> > > To: <[EMAIL PROTECTED]> > > Sent: Thursday, August 16, 2001 11:17 AM > > Subject: [JBoss-dev] AutoDeployer [Auto deploy] DEBUG - Wait for 3 seconds > > > > > > > Can we not be this verbose here... it is very distracting. > > > > > > --jason > > > > > > > > > > > > ___ > > > Jboss-development mailing list > > > [EMAIL PROTECTED] > > > http://lists.sourceforge.net/lists/listinfo/jboss-development > > > > > > > > > ___ > > Jboss-development mailing list > > [EMAIL PROTECTED] > > http://lists.sourceforge.net/lists/listinfo/jboss-development > > > > > ___ > Jboss-development mailing list > [EMAIL PROTECTED] > http://lists.sourceforge.net/lists/listinfo/jboss-development > ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Container.java
Let's not worry about micro-management level details in main that are going to change. - Original Message - From: "Jason Dillon" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Thursday, August 16, 2001 12:26 PM Subject: Re: [JBoss-dev] Container.java > Is there any reason why we are explicitly use DefaultDomain:XXX and > implicily with :XXX in several places now? How about using :XXX everywhere > instead of DefaultDomain:XXX since it just takes up more space. > > --jason > > > On Thu, 16 Aug 2001, Andreas Schaefer wrote: > > > Hi Jasson > > > > Yes, I plan to reorganize the MBean Object Names for the implementation > > of the server-side JBossMGT. > > According to their spec it would be maybe good to have something like this: > > - domain: is the JBoss server instance which can be default be the host > > computer > >name but should be able to renamed > > - properties: > > - group: where this component belongs to > > - type: type of component > > - name: name of the component > > > > The domain should keep an unique name on the network / management domain > > because we maybe use a federation to access MBeans and then it is important > > to have this. > > > > Andy > > ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] [ jboss-Feature Requests-451610 ] JavaSpacesimplementation
> I've been thinking a little bit about a jca adapter to a javaspace, set up Wouldn't you have to make an adapter to the jini tx service? or would the jca adapter to a space deal with all the tx under the covers (and ignore client requests to do it). > so you can use JAWS, with entity bean <--> entry. I'm not entirely sure I am not sure that you would want to use javaspaces for persistent entity storage, but perhaps someone does... not sure. > yet what advantages this would have over jms. I'm also not clear about what > would fetch entries out of the javaspace. javaspaces are a different kind of animal than jms. the looks semantics of entries are vastly different. whiteboard-like apps are much better adapted for a space design than with queued messages, but either would work. I think it is all about options. If it is easy to do and or you have sufficient motivation to do it... then by all means =) I am positive that if there were javaspaces and other jini service plugins to jboss that people would use them. I sure would. > Maybe jca 2 will help, I think it is supposed to have "push" events. When is this due to enter reality? --jason ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Container.java
Is there any reason why we are explicitly use DefaultDomain:XXX and implicily with :XXX in several places now? How about using :XXX everywhere instead of DefaultDomain:XXX since it just takes up more space. --jason On Thu, 16 Aug 2001, Andreas Schaefer wrote: > Hi Jasson > > Yes, I plan to reorganize the MBean Object Names for the implementation > of the server-side JBossMGT. > According to their spec it would be maybe good to have something like this: > - domain: is the JBoss server instance which can be default be the host > computer >name but should be able to renamed > - properties: > - group: where this component belongs to > - type: type of component > - name: name of the component > > The domain should keep an unique name on the network / management domain > because we maybe use a federation to access MBeans and then it is important > to have this. > > Andy > > - Original Message - > From: "Jason Dillon" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Sent: Thursday, August 16, 2001 9:42 AM > Subject: Re: [JBoss-dev] Container.java > > > > Is there a general guide line for domain usage under jmx? Are there any > > plans to exploit this in a more organized manner? Should domain refer to > > components on a single agent, or cross multiple agents? For example in a > > clustered environment, domain could refer to a particular node group, or > > could simply refer to a group of components on a single node. > > > > I am thinking that the jmx domain fluff might bet best left as a node > > component grouping tools, and leave node grouping up to higher level > > organizations (like jini and such). > > > > Any ways, this is going to be important for the upcoming RH stuff to > provide > > a consistent and rich configuration of JBoss nodes in a farm or clustered > > environment. > > > > --jason > > > > ___ > Jboss-development mailing list > [EMAIL PROTECTED] > http://lists.sourceforge.net/lists/listinfo/jboss-development > ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Container.java
Can you provide an example for what this might look like? I am thinking something url like, but I am not sure what the spec will allow for a domain name. So the domain for the jms stuff might look like this: myhost.mydomain.com:/supercluster/jboss/jms ^^^ ^ hostname cluster group Where cluster and group are rather arbitrary, but allow for a hierarchy of stuff on each machine. Just a thought. --jason On Thu, 16 Aug 2001, Andreas Schaefer wrote: > Hi Jasson > > Yes, I plan to reorganize the MBean Object Names for the implementation > of the server-side JBossMGT. > According to their spec it would be maybe good to have something like this: > - domain: is the JBoss server instance which can be default be the host > computer >name but should be able to renamed > - properties: > - group: where this component belongs to > - type: type of component > - name: name of the component > > The domain should keep an unique name on the network / management domain > because we maybe use a federation to access MBeans and then it is important > to have this. > > Andy > > - Original Message - > From: "Jason Dillon" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Sent: Thursday, August 16, 2001 9:42 AM > Subject: Re: [JBoss-dev] Container.java > > > > Is there a general guide line for domain usage under jmx? Are there any > > plans to exploit this in a more organized manner? Should domain refer to > > components on a single agent, or cross multiple agents? For example in a > > clustered environment, domain could refer to a particular node group, or > > could simply refer to a group of components on a single node. > > > > I am thinking that the jmx domain fluff might bet best left as a node > > component grouping tools, and leave node grouping up to higher level > > organizations (like jini and such). > > > > Any ways, this is going to be important for the upcoming RH stuff to > provide > > a consistent and rich configuration of JBoss nodes in a farm or clustered > > environment. > > > > --jason > > > > ___ > Jboss-development mailing list > [EMAIL PROTECTED] > http://lists.sourceforge.net/lists/listinfo/jboss-development > ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] new: entity instance per transaction interceptorsand locks
Let me know if this turns out to be a bug/problem with the bean handle and the InitialContextHandle stuff. --jason On Thu, 16 Aug 2001, Bill Burke wrote: > Nope, I haven't had a chance to look at it. Although, right now, I'm in the > JNDI code, I can probably investigate it. > > Bill > > > -Original Message- > > From: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED]]On Behalf Of Jason > > Dillon > > Sent: Thursday, August 16, 2001 12:23 PM > > To: [EMAIL PROTECTED] > > Subject: Re: [JBoss-dev] new: entity instance per transaction > > interceptors and locks > > > > > > Was this ever resolved? > > > > --jason > > > > > > On Sun, 12 Aug 2001, Scott M Stark wrote: > > > > > The profile shows two traces from > > > org.jboss.ejb.plugins.jrmp.interfaces.EntityHandleImpl.getEJBObject() > > > into JNDI. The first takes 1600 ms, the second 100 ms. The only > > > difference between the two calls > > > is the order in which NamingContext.checkRef() is called. How is the > > > entity being created? > > > > > > Bill Burke wrote: > > > > > > >I've made a first stab at implementing multiple instances. That is an > > > >entity instance per transaction and no shared entity instances between > > > >transactions. This code may be naive, but it seems to pass locktest, > > > >banktest, and the mbean(threads) test. It will only work with > > commit option > > > >B and C and will throw an exception if you try to run it with > > commit option > > > >A. > > > > > > > >The weird thing is is that locktest runs much slower with > > multi instance > > > >than with regular when I thought it would run much faster. > > Attached is the > > > >Optimizeit output if anyone is interested. It seems to slow > > down trying to > > > >getEJBHome in loadEntity? > > > > > > > >So, what are the benefits of this checkin? I thought it would increase > > > >performance/throughput for commit options B and C since beans > > are not locked > > > >into a transaction. > > > > > > > >To try it out: > > > > > > > >in standardjboss.xml, replace > > > > > > > >EntityInstanceInterceptor with EntityMultiInstanceInterceptor > > > >EntitySynchronizationInterceptor with > > > >EntityMultiInstanceSynchronizationInterceptor > > > > > > > >your lock-policy should be MethodOnlyEJBLock. > > > > > > > >Look at jbosstest/src/resources/lock/META-INF/jboss.xml for > > configuration > > > >examples. EntityBean_B_Multi > > > > > > > > > > > >Regards, > > > > > > > >Bill > > > > > > > > > > > > > > > > > > > > > > > > > > Profiler output and hot spots for thread RMI TCP > > > > Connection(271)-192.168.0.152 . application org.jboss.Main (CPU > > > > profiler output - Sampler / Methods) > > > > > > > > > > > > Backtrace > > > > > > > > Description of CPU usage for thread RMI TCP > > > > Connection(271)-192.168.0.152 > > > >100.0% - 5862 ms - java.lang.Thread.run() > > > >100.0% - 5862 ms - > > > > sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run() > > > >100.0% - 5862 ms - > > > > sun.rmi.transport.tcp.TCPTransport.handleMessages() > > > >64.48% - 3780 ms - > > > > sun.rmi.transport.Transport.serviceCall() > > > >64.48% - 3780 ms - > > > > java.security.AccessController.doPrivileged() > > > >64.48% - 3780 ms - > > > > sun.rmi.transport.Transport$1.run() > > > >64.48% - 3780 ms - > > > > sun.rmi.server.UnicastServerRef.dispatch() > > > >63.59% - 3728 ms - > > > > java.lang.reflect.Method.invoke() > > > >63.59% - 3728 ms - > > > > org.jboss.ejb.plugins.jrmp.server.JRMPContainerInvoker.invoke() > > > >61.87% - 3627 > > > > ms - org.jboss.ejb.EntityContainer.invoke() > > > >61.87% - > > > > 3627 ms - org.jboss.ejb.plugins.LogInterceptor.invoke() > > > >61.87% > > > > - 3627 ms - org.jboss.ejb.plugins.SecurityInterceptor.invoke() > > > > > > > > 61.87% - 3627 ms - org.jboss.ejb.plugins.TxInterceptorCMT.invoke() > > > > > > > > 61.87% - 3627 ms - > > > > org.jboss.ejb.plugins.TxInterceptorCMT.runWithTransactions() > > > > > > > > 32.13% - 1884 ms - org.jboss.tm.TransactionImpl.commit() > > > > > > > > 29.73% - 1743 ms - > > > > org.jboss.ejb.plugins.AbstractTxInterceptor.invokeNext() > > > > > > > > 29.73% - 1743 ms - > > > > org.jboss.ejb.plugins.EntityLockInterceptor.invoke() > > > > > > > > 28.02% - 1643 ms - > > > > org.jboss.ejb.plugins.EntityMultiInstanceInterceptor.invoke() > > > > > > > > 28.02% - 1643 ms - > > > > org.jboss.ejb.plugins.EntitySynchronizationInterceptor.invoke()
Re: [JBoss-dev] Stateful bean with different transaction context
Where should I put JDBCUser and Password now? Should they go into PrincipalMappingProperties? Do I need to do anything else to make that work. I have been ignoring the security stuff for the most part, since I do not really understand it, and it is not currently required. Any ways, I tried just dropping those into Properties and I *think* it works. Just curious. --jason On Wed, 15 Aug 2001, David Jencks wrote: > Hi Jason, could you try converting to the jca version of db access and see > if the problem persists? I recently found a race condition in (the jca > versions) of the code that releases connections back to the pool after > transactions complete that was allowing several transactions to access the > same connection. Maybe a similar bug is present in the non-jca code. I'm > hoping to check in my "auto-converting-to-jca" XADatasourceLoader later > today, in case you don't want to try the conversion by hand. (this race fix > is only in rabbit hole). > > Thanks > david jencks > > On 2001.08.14 19:07:43 -0400 Jason Dillon wrote: > > I was trying to track down a concurrency problem which would show up as > > an > > Oracle deadlock exception. It looks like that exception was happening > > due > > to some fk constraints causing parent tables to lock and such. Any ways, > > after I got that deadlock exception, I got a ton of these session bean > > context errors. > > > > I think that I have fixed the deadlock problem by removing some of the fk > > constraints (which I don't like too much, but it stopped the exception > > from > > being thrown), but I am still getting these errors. > > > > I thought they were caused by the oracle problem, but now I think there > > might be something else going on. > > > > Does anyone have any ideas on why this might happen, and or how I might > > go > > about fixing it? The TX stuff is still a bit of a mystery to me. Any > > help > > would be appreciated. > > > > Below is the log of the exception thrown. > > > > --jason > > > > > > 2001-08-14 15:59:52,726 org.jboss.ejb.plugins.LogInterceptor [Thread Pool > > Worker] ERROR - TRANSACTION ROLLBACK EXCEPTION: Application Error: tried > > to > > enter Stateful bean with different transaction context; nested exception > > is: > > java.rmi.RemoteException: Application Error: tried to enter > > Stateful > > bean with different transaction context > > > > ... > > > > 2001-08-14 15:59:52,842 org.jboss.ejb.plugins.LogInterceptor [Thread Pool > > Worker] ERROR - Detail > > java.rmi.RemoteException: Application Error: tried to enter Stateful bean > > with different transaction context > > at > > >org.jboss.ejb.plugins.StatefulSessionInstanceInterceptor.invoke(StatefulSessionInstanceInterceptor.java:207) > > at > > >org.jboss.ejb.plugins.AbstractTxInterceptor.invokeNext(AbstractTxInterceptor.java:97) > > at > > >org.jboss.ejb.plugins.TxInterceptorCMT.runWithTransactions(TxInterceptorCMT.java:154) > > at > > org.jboss.ejb.plugins.TxInterceptorCMT.invoke(TxInterceptorCMT.java:63) > > at > > org.jboss.ejb.plugins.LogInterceptor.invoke(LogInterceptor.java:168) > > at > > org.jboss.ejb.StatefulSessionContainer.invoke(StatefulSessionContainer.java:354) > > at > > >org.jboss.ejb.plugins.jrmp.server.JRMPContainerInvoker.invoke(JRMPContainerInvoker.java:445) > > at > > >org.jboss.ejb.plugins.jrmp.interfaces.GenericProxy.invokeContainer(GenericProxy.java:339) > > at > > >org.jboss.ejb.plugins.jrmp.interfaces.StatefulSessionProxy.invoke(StatefulSessionProxy.java:136) > > at $Proxy28.handle(Unknown Source) > > at > > >com.boldfish.does.job.service.internal.ResponseProcessorEJB.process(ResponseProcessorEJB.java:152) > > at > > >com.boldfish.ejb.AbstractMessageDrivenBean.onMessage(AbstractMessageDrivenBean.java:132) > > at java.lang.reflect.Method.invoke(Native Method) > > at > > >org.jboss.ejb.MessageDrivenContainer$ContainerInterceptor.invoke(MessageDrivenContainer.java:410) > > at > > >org.jboss.ejb.plugins.MessageDrivenInstanceInterceptor.invoke(MessageDrivenInstanceInterceptor.java:79) > > at > > >org.jboss.ejb.plugins.AbstractTxInterceptor.invokeNext(AbstractTxInterceptor.java:97) > > at > > >org.jboss.ejb.plugins.TxInterceptorCMT.runWithTransactions(TxInterceptorCMT.java:154) > > at > > org.jboss.ejb.plugins.TxInterceptorCMT.invoke(TxInterceptorCMT.java:63) > > at > > org.jboss.ejb.plugins.SecurityInterceptor.invoke(SecurityInterceptor.java:128) > > at > > org.jboss.ejb.plugins.LogInterceptor.invoke(LogInterceptor.java:168) > > at > > org.jboss.ejb.MessageDrivenContainer.invoke(MessageDrivenContainer.java:285) > > at > > org.jboss.ejb.plugins.jms.JMSContainerInvoker.invoke(JMSContainerInvoker.java:165) > > at > > >org.jboss.ejb.plugins.jms.JMSContainerInvoker$MessageListenerImpl.onMessage(JMSContainerInvoker.java:644) > >
Re: [JBoss-dev] Stateful bean with different transaction context
I just switched over and found one rather large problem, that is that my beans deploy before the resource adapters. It could be that I am explicitly listing the .jars to deploy, but I have the deploy/lib directory listed before it, so I expected that it would do the right thing. I think it will work if I touch all the files and force the auto deployer to re-deploy once the datasources have been bound to jndi. Do you (or anyone else) have any ideas on how to fix this, or should I look into it? --jason On Wed, 15 Aug 2001, David Jencks wrote: > Hi Jason, could you try converting to the jca version of db access and see > if the problem persists? I recently found a race condition in (the jca > versions) of the code that releases connections back to the pool after > transactions complete that was allowing several transactions to access the > same connection. Maybe a similar bug is present in the non-jca code. I'm > hoping to check in my "auto-converting-to-jca" XADatasourceLoader later > today, in case you don't want to try the conversion by hand. (this race fix > is only in rabbit hole). > > Thanks > david jencks > > On 2001.08.14 19:07:43 -0400 Jason Dillon wrote: > > I was trying to track down a concurrency problem which would show up as > > an > > Oracle deadlock exception. It looks like that exception was happening > > due > > to some fk constraints causing parent tables to lock and such. Any ways, > > after I got that deadlock exception, I got a ton of these session bean > > context errors. > > > > I think that I have fixed the deadlock problem by removing some of the fk > > constraints (which I don't like too much, but it stopped the exception > > from > > being thrown), but I am still getting these errors. > > > > I thought they were caused by the oracle problem, but now I think there > > might be something else going on. > > > > Does anyone have any ideas on why this might happen, and or how I might > > go > > about fixing it? The TX stuff is still a bit of a mystery to me. Any > > help > > would be appreciated. > > > > Below is the log of the exception thrown. > > > > --jason > > > > > > 2001-08-14 15:59:52,726 org.jboss.ejb.plugins.LogInterceptor [Thread Pool > > Worker] ERROR - TRANSACTION ROLLBACK EXCEPTION: Application Error: tried > > to > > enter Stateful bean with different transaction context; nested exception > > is: > > java.rmi.RemoteException: Application Error: tried to enter > > Stateful > > bean with different transaction context > > > > ... > > > > 2001-08-14 15:59:52,842 org.jboss.ejb.plugins.LogInterceptor [Thread Pool > > Worker] ERROR - Detail > > java.rmi.RemoteException: Application Error: tried to enter Stateful bean > > with different transaction context > > at > > >org.jboss.ejb.plugins.StatefulSessionInstanceInterceptor.invoke(StatefulSessionInstanceInterceptor.java:207) > > at > > >org.jboss.ejb.plugins.AbstractTxInterceptor.invokeNext(AbstractTxInterceptor.java:97) > > at > > >org.jboss.ejb.plugins.TxInterceptorCMT.runWithTransactions(TxInterceptorCMT.java:154) > > at > > org.jboss.ejb.plugins.TxInterceptorCMT.invoke(TxInterceptorCMT.java:63) > > at > > org.jboss.ejb.plugins.LogInterceptor.invoke(LogInterceptor.java:168) > > at > > org.jboss.ejb.StatefulSessionContainer.invoke(StatefulSessionContainer.java:354) > > at > > >org.jboss.ejb.plugins.jrmp.server.JRMPContainerInvoker.invoke(JRMPContainerInvoker.java:445) > > at > > >org.jboss.ejb.plugins.jrmp.interfaces.GenericProxy.invokeContainer(GenericProxy.java:339) > > at > > >org.jboss.ejb.plugins.jrmp.interfaces.StatefulSessionProxy.invoke(StatefulSessionProxy.java:136) > > at $Proxy28.handle(Unknown Source) > > at > > >com.boldfish.does.job.service.internal.ResponseProcessorEJB.process(ResponseProcessorEJB.java:152) > > at > > >com.boldfish.ejb.AbstractMessageDrivenBean.onMessage(AbstractMessageDrivenBean.java:132) > > at java.lang.reflect.Method.invoke(Native Method) > > at > > >org.jboss.ejb.MessageDrivenContainer$ContainerInterceptor.invoke(MessageDrivenContainer.java:410) > > at > > >org.jboss.ejb.plugins.MessageDrivenInstanceInterceptor.invoke(MessageDrivenInstanceInterceptor.java:79) > > at > > >org.jboss.ejb.plugins.AbstractTxInterceptor.invokeNext(AbstractTxInterceptor.java:97) > > at > > >org.jboss.ejb.plugins.TxInterceptorCMT.runWithTransactions(TxInterceptorCMT.java:154) > > at > > org.jboss.ejb.plugins.TxInterceptorCMT.invoke(TxInterceptorCMT.java:63) > > at > > org.jboss.ejb.plugins.SecurityInterceptor.invoke(SecurityInterceptor.java:128) > > at > > org.jboss.ejb.plugins.LogInterceptor.invoke(LogInterceptor.java:168) > > at > > org.jboss.ejb.MessageDrivenContainer.invoke(MessageDrivenContainer.java:285) > > at > > org.jboss.ejb.plugins.jms.JMSContainerInvoker.invoke(JMSContainerInvoker.java:165) > >
Re: [JBoss-dev] Stateful bean with different transaction context
You have been free to convert all your db access to the jca framework for the last 6 months, it appears noone has. The XADataSourceLoader change more or less converts it for you. If you don't want to run on rabbithole you could just use it for the conversion and copy the ConnectionFactoryLoader config back to your normal 2.4 jboss. Note that the race condition bug fix I mention is only applied to rh, and is almost certainly present in 2.4. So you'd want the BaseConnectionManager from rh. ;-)) new frontiers in earning money from jboss -- "will convert your XADataSourceLoaders for $$$" ;-))) Try it, its pretty easy. And I'd like to know if it works for anyone other than me. david jencks On 2001.08.16 11:27:06 -0400 Jason Dillon wrote: > Is there a more prefered way short of the loaders? > > --jason > > > On Thu, 16 Aug 2001, David Jencks wrote: > > > Ok, I finally got the rewritten XADataSourceLoader into cvs. All you > need > > to do to try with jca should be to use latest cvs rabbithole. The > > XADataSourceLoader should do the conversion for you. > > > > It worked great for me, I'm waiting for the storm of protest if it > breaks > > something I didn't test. > > > > david jencks > > > > On 2001.08.15 14:40:42 -0400 Jason Dillon wrote: > > > Could you explain what I need to do? > > > > > > --jason > > > > > > > > > On Wed, 15 Aug 2001, David Jencks wrote: > > > > > > > Hi Jason, could you try converting to the jca version of db access > and > > > see > > > > if the problem persists? I recently found a race condition in (the > jca > > > > versions) of the code that releases connections back to the pool > after > > > > transactions complete that was allowing several transactions to > access > > > the > > > > same connection. Maybe a similar bug is present in the non-jca > code. > > > I'm > > > > hoping to check in my "auto-converting-to-jca" XADatasourceLoader > later > > > > today, in case you don't want to try the conversion by hand. (this > race > > > fix > > > > is only in rabbit hole). > > > > > > > > Thanks > > > > david jencks > > > > > > > > On 2001.08.14 19:07:43 -0400 Jason Dillon wrote: > > > > > I was trying to track down a concurrency problem which would show > up > > > as > > > > > an > > > > > Oracle deadlock exception. It looks like that exception was > > > happening > > > > > due > > > > > to some fk constraints causing parent tables to lock and such. > Any > > > ways, > > > > > after I got that deadlock exception, I got a ton of these session > > > bean > > > > > context errors. > > > > > > > > > > I think that I have fixed the deadlock problem by removing some > of > > > the fk > > > > > constraints (which I don't like too much, but it stopped the > > > exception > > > > > from > > > > > being thrown), but I am still getting these errors. > > > > > > > > > > I thought they were caused by the oracle problem, but now I think > > > there > > > > > might be something else going on. > > > > > > > > > > Does anyone have any ideas on why this might happen, and or how I > > > might > > > > > go > > > > > about fixing it? The TX stuff is still a bit of a mystery to me. > > > Any > > > > > help > > > > > would be appreciated. > > > > > > > > > > Below is the log of the exception thrown. > > > > > > > > > > --jason > > > > > > > > > > > > > > > 2001-08-14 15:59:52,726 org.jboss.ejb.plugins.LogInterceptor > [Thread > > > Pool > > > > > Worker] ERROR - TRANSACTION ROLLBACK EXCEPTION: Application > Error: > > > tried > > > > > to > > > > > enter Stateful bean with different transaction context; nested > > > exception > > > > > is: > > > > > java.rmi.RemoteException: Application Error: tried to > enter > > > > > Stateful > > > > > bean with different transaction context > > > > > > > > > > ... > > > > > > > > > > 2001-08-14 15:59:52,842 org.jboss.ejb.plugins.LogInterceptor > [Thread > > > Pool > > > > > Worker] ERROR - Detail > > > > > java.rmi.RemoteException: Application Error: tried to enter > Stateful > > > bean > > > > > with different transaction context > > > > > at > > > > > >org.jboss.ejb.plugins.StatefulSessionInstanceInterceptor.invoke(StatefulSessionInstanceInterceptor.java:207) > > > > > at > > > > > >org.jboss.ejb.plugins.AbstractTxInterceptor.invokeNext(AbstractTxInterceptor.java:97) > > > > > at > > > > > >org.jboss.ejb.plugins.TxInterceptorCMT.runWithTransactions(TxInterceptorCMT.java:154) > > > > > at > > > > > org.jboss.ejb.plugins.TxInterceptorCMT.invoke(TxInterceptorCMT.java:63) > > > > > at > > > > > org.jboss.ejb.plugins.LogInterceptor.invoke(LogInterceptor.java:168) > > > > > at > > > > > >org.jboss.ejb.StatefulSessionContainer.invoke(StatefulSessionContainer.java:354) > > > > > at > > > > > >org.jboss.ejb.plugins.jrmp.server.JRMPContainerInvoker.invoke(JRMPContainerInvoker.java:445) > > > > > at > > > > > >org.jboss.ejb.plugins.jrmp.interfaces.GenericProxy.invokeContainer(GenericProx
Re: [JBoss-dev] AutoDeployer [Auto deploy] DEBUG - Wait for 3 seconds
Do you have debug enabled? I currently have org.jboss = debug, which produces a lot of stuff, but this is a bit excessive I believe. --jason On Thu, 16 Aug 2001, Scott M Stark wrote: > There is no such msg in main. Where are you seeing this? > > - Original Message - > From: "Jason Dillon" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Sent: Thursday, August 16, 2001 11:17 AM > Subject: [JBoss-dev] AutoDeployer [Auto deploy] DEBUG - Wait for 3 seconds > > > > Can we not be this verbose here... it is very distracting. > > > > --jason > > > > > > > > ___ > > Jboss-development mailing list > > [EMAIL PROTECTED] > > http://lists.sourceforge.net/lists/listinfo/jboss-development > > > > > ___ > Jboss-development mailing list > [EMAIL PROTECTED] > http://lists.sourceforge.net/lists/listinfo/jboss-development > ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
