[JBoss-dev] [ jboss-Bugs-574130 ] Remote UserTransaction fails name lookup

2002-11-06 Thread noreply
Bugs item #574130, was opened at 2002-06-26 15:29
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detailatid=376685aid=574130group_id=22866

Category: JBossTX
Group: v3.0 Rabbit Hole
Status: Open
Resolution: Rejected
Priority: 5
Submitted By: Jon Swinth (jswinth)
Assigned to: Nobody/Anonymous (nobody)
Summary: Remote UserTransaction fails name lookup

Initial Comment:
When using a UserTransaction from a remote client (i.e.
standalone Tomcat) in which JBoss is not on the same
server results in an exception when begin() is called.
 This happens specifically when new
InitialContext(Properties) is used to connect to the
JBoss server.  Traced the issue to
org.jboss.tm.usertx.client.ClientUserTransaction.createSession().
 In this method new
InitialContext().lookup(UserTransactionSessionFactory)
is called.  Since there are no jndi.properties, the
InitialContext defaults to 127.0.0.1 which fails.

--

Comment By: Ole Husgaard (sparre)
Date: 2002-11-06 07:59

Message:
Logged In: YES 
user_id=175257

This Remote UT implementation only controls transactions
on a single JBoss server. It has to find that server, and
that is done through jndi.
The fix is simple: Create a client jndi.properties file.

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detailatid=376685aid=574130group_id=22866


---
This sf.net email is sponsored by: See the NEW Palm 
Tungsten T handheld. Power  Color in a compact size!
http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development



[JBoss-dev] [ jboss-Bugs-634362 ] Failure if EntityBean overrides hashCode

2002-11-06 Thread noreply
Bugs item #634362, was opened at 2002-11-06 11:55
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detailatid=376685aid=634362group_id=22866

Category: None
Group: v3.0 Rabbit Hole
Status: Open
Resolution: None
Priority: 5
Submitted By: Michael Lipp (mlipp)
Assigned to: Nobody/Anonymous (nobody)
Summary: Failure if EntityBean overrides hashCode

Initial Comment:
This is a follow on to #595738 which has not been fixed
properly.

The CachedConnectionManager uses an entity beans equals
and hashCode method to manage  EJB containers. This
fails if the EJB itself overrides equals/hashCode (see
#595738 for a detailed description).

The proper solution to the problem are collection/map
implementations that use == instead of equals and
System.identityHashCode instead of hashCode.

The class IdentityWrapper which now exists in 3.0.4
does not solve the problem. It still calls hashCode on
the EJB and (as explained in the previous bug report) a
an EJB's hashCode implementation may fail if the EJB is
in the pooled state.

Worse, the current implementation actually disables
connection caching. As every object is wrapped with a
new IdentityWrapper (key = new
IdentityWrapper(rawKey)), the stack.contains(key)
will *always* fail.


--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detailatid=376685aid=634362group_id=22866


---
This sf.net email is sponsored by: See the NEW Palm 
Tungsten T handheld. Power  Color in a compact size!
http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development



[JBoss-dev] [ jboss-Bugs-634362 ] Failure if EntityBean overrides hashCode

2002-11-06 Thread noreply
Bugs item #634362, was opened at 2002-11-06 11:55
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detailatid=376685aid=634362group_id=22866

Category: None
Group: v3.0 Rabbit Hole
Status: Open
Resolution: None
Priority: 7
Submitted By: Michael Lipp (mlipp)
Assigned to: Nobody/Anonymous (nobody)
Summary: Failure if EntityBean overrides hashCode

Initial Comment:
This is a follow on to #595738 which has not been fixed
properly.

The CachedConnectionManager uses an entity beans equals
and hashCode method to manage  EJB containers. This
fails if the EJB itself overrides equals/hashCode (see
#595738 for a detailed description).

The proper solution to the problem are collection/map
implementations that use == instead of equals and
System.identityHashCode instead of hashCode.

The class IdentityWrapper which now exists in 3.0.4
does not solve the problem. It still calls hashCode on
the EJB and (as explained in the previous bug report) a
an EJB's hashCode implementation may fail if the EJB is
in the pooled state.

Worse, the current implementation actually disables
connection caching. As every object is wrapped with a
new IdentityWrapper (key = new
IdentityWrapper(rawKey)), the stack.contains(key)
will *always* fail.


--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detailatid=376685aid=634362group_id=22866


---
This sf.net email is sponsored by: See the NEW Palm 
Tungsten T handheld. Power  Color in a compact size!
http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development



Re: [JBoss-dev] HEAD - testsuite problems...

2002-11-06 Thread Chris Kimpton
Hi,

Still not completing - although it seemed to have got to the stress
tests today - but I did let it run for around 11 hours this time...

Has anyone else run the full testsuite on HEAD recently?  How long
did it take - on what machine?  I am using a 600mhz P3, redhat7.1
box.

Thanks,
Chris


--- Chris Kimpton [EMAIL PROTECTED] wrote:
 Hi,
 
 Perhaps I spoke too soon - the testsuite does not seem to complete
 (or at least, I give up after 9 hours...)
 
 The last entries in the test logs are:
 
 [junit] Running
 org.jboss.test.invokers.test.MultiInvokersUnitTestCase
 [junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed:
 9.392
 sec
 [junit] Running
 org.jboss.test.jbossmq.test.ConnectionUnitTestCase
 [junit] Tests run: 8, Failures: 0, Errors: 0, Time elapsed:
 7.219
 sec
 [junit] Running org.jboss.test.jbossmq.test.JBossMQUnitTestCase
 [junit] Tests run: 32, Failures: 0, Errors: 3, Time elapsed:
 31,954.962 sec
 [junit] TEST org.jboss.test.jbossmq.test.JBossMQUnitTestCase
 FAILED (timeout)
 [junit] Running
 org.jboss.test.jbossmq.test.JBossSessionRecoverUnitTestCase
 
 
 
 The server log has been filled with this stuff:
 
 
 DEBUG [org.jboss.mq.sm.file.DynamicStateManager] Saving config to:

/disk/orig/home/lubega/jbossro/jboss-all/build/output/testbuild/server/all/conf/jbossmq-state.xml
 2002-11-05 00:30:34,101 DEBUG [org.javagroups.DefaultPartition]
 [Tue
 Nov 5 00:30:34 GMT 2002] [INFO] PING.down(): FIND_INITIAL_MBRS
 2002-11-05 00:30:34,103 DEBUG [org.javagroups.DefaultPartition]
 [Tue
 Nov 5 00:30:34 GMT 2002] [INFO] PING.up(): received GET_MBRS_REQ
 from
 kimptoc:34521, returning [PING: type=GET_MBRS_RSP,
 arg=[own_addr=kimptoc:34521, coord_addr=kimptoc:34521]]
 2002-11-05 00:30:34,104 DEBUG [org.javagroups.DefaultPartition]
 [Tue
 Nov 5 00:30:34 GMT 2002] [INFO] PING.up(): received
 FIND_INITAL_MBRS_RSP, rsp=[own_addr=kimptoc:34521,
 coord_addr=kimptoc:34521]
 2002-11-05 00:30:36,105 DEBUG [org.javagroups.DefaultPartition]
 [Tue
 Nov 5 00:30:36 GMT 2002] [INFO] PING.down(): initial mbrs are
 [[own_addr=kimptoc:34521, coord_addr=kimptoc:34521]]
 2002-11-05 00:30:36,106 DEBUG [org.javagroups.DefaultPartition]
 [Tue
 Nov 5 00:30:36 GMT 2002] [INFO] MERGE2.FindSubgroups.run():
 initial_mbrs=[[own_addr=kimptoc:34521, coord_addr=kimptoc:34521]]
 2002-11-05 00:30:38,060 WARN 
 [org.jboss.mq.security.SecurityManager]
 No SecurityMetadadata was available for JMS_TQ4 adding default
 security conf
 2002-11-05 00:30:45,464 DEBUG [org.javagroups.DefaultPartition]
 [Tue
 Nov 5 00:30:45 GMT 2002] [INFO] PING.down(): FIND_INITIAL_MBRS
 2002-11-05 00:30:45,467 
 
 
 
 [ snip ]
 
 
 DEBUG [org.javagroups.DefaultPartition] [Tue Nov 5 09:21:50 GMT
 2002]
 [INFO] PING.up(): received GET_MBRS_REQ from kimptoc:34521,
 returning
 [PING: type=GET_MBRS_RSP, arg=[own_addr=kimptoc:34521,
 coord_addr=kimptoc:34521]]
 2002-11-05 09:21:50,622 DEBUG [org.javagroups.DefaultPartition]
 [Tue
 Nov 5 09:21:50 GMT 2002] [INFO] PING.up(): received
 FIND_INITAL_MBRS_RSP, rsp=[own_addr=kimptoc:34521,
 coord_addr=kimptoc:34521]
 2002-11-05 09:21:52,621 DEBUG [org.javagroups.DefaultPartition]
 [Tue
 Nov 5 09:21:52 GMT 2002] [INFO] PING.down(): initial mbrs are
 [[own_addr=kimptoc:34521, coord_addr=kimptoc:34521]]
 2002-11-05 09:21:52,622 DEBUG [org.javagroups.DefaultPartition]
 [Tue
 Nov 5 09:21:52 GMT 2002] [INFO] MERGE2.FindSubgroups.run():
 initial_mbrs=[[own_addr=kimptoc:34521, coord_addr=kimptoc:34521]]
 2002-11-05 09:22:02,613 DEBUG [org.javagroups.DefaultPartition]
 [Tue
 Nov 5 09:22:02 GMT 2002] [INFO] PING.down(): FIND_INITIAL_MBRS
 2002-11-05 09:22:02,615 DEBUG [org.javagroups.DefaultPartition]
 [Tue
 Nov 5 09:22:02 GMT 2002] [INFO] PING.up(): received GET_MBRS_REQ
 from
 kimptoc:34521, returning [PING: type=GET_MBRS_RSP,
 arg=[own_addr=kimptoc:34521, coord_addr=kimptoc:34521]]
 2002-11-05 09:22:02,616 DEBUG [org.javagroups.DefaultPartition]
 [Tue
 Nov 5 09:22:02 GMT 2002] [INFO] PING.up(): received
 FIND_INITAL_MBRS_RSP, rsp=[own_addr=kimptoc:34521,
 coord_addr=kimptoc:34521]
 2002-11-05 09:22:04,615 DEBUG [org.javagroups.DefaultPartition]
 [Tue
 Nov 5 09:22:04 GMT 2002] [INFO] PING.down(): initial mbrs are
 [[own_addr=kimptoc:34521, coord_addr=kimptoc:34521]]
 2002-11-05 09:22:04,616 DEBUG [org.javagroups.DefaultPartition]
 [Tue
 Nov 5 09:22:04 GMT 2002] [INFO] MERGE2.FindSubgroups.run():
 initial_mbrs=[[own_addr=kimptoc:34521, coord_addr=kimptoc:34521]]
 
 
 Hope this helps,
 Chris
 
 
 
 =
 
 
 __
 Do you Yahoo!?
 HotJobs - Search new jobs daily now
 http://hotjobs.yahoo.com/
 
 
 ---
 This sf.net email is sponsored by: See the NEW Palm 
 Tungsten T handheld. Power  Color in a compact size!
 http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en
 ___
 Jboss-development mailing list
 [EMAIL PROTECTED]
 

Re: [JBoss-dev] HEAD - testsuite problems...

2002-11-06 Thread Adrian Brock
Hi Chris,

I ran head tests yesterday, there are still
time-outs relating to the trunk invokers,
but it does complete.

Windows XP 1Ghz P3 java 1.4
Mandrake 8.1 450Mhz P2 java 1.3

Have you tried a thread-dump to see whether
there is a deadlock?

Regards,
Adrian


From: Chris Kimpton [EMAIL PROTECTED]
Reply-To: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: Re: [JBoss-dev] HEAD - testsuite problems...
Date: Wed, 6 Nov 2002 03:35:18 -0800 (PST)

Hi,

Still not completing - although it seemed to have got to the stress
tests today - but I did let it run for around 11 hours this time...

Has anyone else run the full testsuite on HEAD recently?  How long
did it take - on what machine?  I am using a 600mhz P3, redhat7.1
box.

Thanks,
Chris


--- Chris Kimpton [EMAIL PROTECTED] wrote:
 Hi,

 Perhaps I spoke too soon - the testsuite does not seem to complete
 (or at least, I give up after 9 hours...)

 The last entries in the test logs are:

 [junit] Running
 org.jboss.test.invokers.test.MultiInvokersUnitTestCase
 [junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed:
 9.392
 sec
 [junit] Running
 org.jboss.test.jbossmq.test.ConnectionUnitTestCase
 [junit] Tests run: 8, Failures: 0, Errors: 0, Time elapsed:
 7.219
 sec
 [junit] Running org.jboss.test.jbossmq.test.JBossMQUnitTestCase
 [junit] Tests run: 32, Failures: 0, Errors: 3, Time elapsed:
 31,954.962 sec
 [junit] TEST org.jboss.test.jbossmq.test.JBossMQUnitTestCase
 FAILED (timeout)
 [junit] Running
 org.jboss.test.jbossmq.test.JBossSessionRecoverUnitTestCase



 The server log has been filled with this stuff:


 DEBUG [org.jboss.mq.sm.file.DynamicStateManager] Saving config to:

/disk/orig/home/lubega/jbossro/jboss-all/build/output/testbuild/server/all/conf/jbossmq-state.xml
 2002-11-05 00:30:34,101 DEBUG [org.javagroups.DefaultPartition]
 [Tue
 Nov 5 00:30:34 GMT 2002] [INFO] PING.down(): FIND_INITIAL_MBRS
 2002-11-05 00:30:34,103 DEBUG [org.javagroups.DefaultPartition]
 [Tue
 Nov 5 00:30:34 GMT 2002] [INFO] PING.up(): received GET_MBRS_REQ
 from
 kimptoc:34521, returning [PING: type=GET_MBRS_RSP,
 arg=[own_addr=kimptoc:34521, coord_addr=kimptoc:34521]]
 2002-11-05 00:30:34,104 DEBUG [org.javagroups.DefaultPartition]
 [Tue
 Nov 5 00:30:34 GMT 2002] [INFO] PING.up(): received
 FIND_INITAL_MBRS_RSP, rsp=[own_addr=kimptoc:34521,
 coord_addr=kimptoc:34521]
 2002-11-05 00:30:36,105 DEBUG [org.javagroups.DefaultPartition]
 [Tue
 Nov 5 00:30:36 GMT 2002] [INFO] PING.down(): initial mbrs are
 [[own_addr=kimptoc:34521, coord_addr=kimptoc:34521]]
 2002-11-05 00:30:36,106 DEBUG [org.javagroups.DefaultPartition]
 [Tue
 Nov 5 00:30:36 GMT 2002] [INFO] MERGE2.FindSubgroups.run():
 initial_mbrs=[[own_addr=kimptoc:34521, coord_addr=kimptoc:34521]]
 2002-11-05 00:30:38,060 WARN
 [org.jboss.mq.security.SecurityManager]
 No SecurityMetadadata was available for JMS_TQ4 adding default
 security conf
 2002-11-05 00:30:45,464 DEBUG [org.javagroups.DefaultPartition]
 [Tue
 Nov 5 00:30:45 GMT 2002] [INFO] PING.down(): FIND_INITIAL_MBRS
 2002-11-05 00:30:45,467



 [ snip ]


 DEBUG [org.javagroups.DefaultPartition] [Tue Nov 5 09:21:50 GMT
 2002]
 [INFO] PING.up(): received GET_MBRS_REQ from kimptoc:34521,
 returning
 [PING: type=GET_MBRS_RSP, arg=[own_addr=kimptoc:34521,
 coord_addr=kimptoc:34521]]
 2002-11-05 09:21:50,622 DEBUG [org.javagroups.DefaultPartition]
 [Tue
 Nov 5 09:21:50 GMT 2002] [INFO] PING.up(): received
 FIND_INITAL_MBRS_RSP, rsp=[own_addr=kimptoc:34521,
 coord_addr=kimptoc:34521]
 2002-11-05 09:21:52,621 DEBUG [org.javagroups.DefaultPartition]
 [Tue
 Nov 5 09:21:52 GMT 2002] [INFO] PING.down(): initial mbrs are
 [[own_addr=kimptoc:34521, coord_addr=kimptoc:34521]]
 2002-11-05 09:21:52,622 DEBUG [org.javagroups.DefaultPartition]
 [Tue
 Nov 5 09:21:52 GMT 2002] [INFO] MERGE2.FindSubgroups.run():
 initial_mbrs=[[own_addr=kimptoc:34521, coord_addr=kimptoc:34521]]
 2002-11-05 09:22:02,613 DEBUG [org.javagroups.DefaultPartition]
 [Tue
 Nov 5 09:22:02 GMT 2002] [INFO] PING.down(): FIND_INITIAL_MBRS
 2002-11-05 09:22:02,615 DEBUG [org.javagroups.DefaultPartition]
 [Tue
 Nov 5 09:22:02 GMT 2002] [INFO] PING.up(): received GET_MBRS_REQ
 from
 kimptoc:34521, returning [PING: type=GET_MBRS_RSP,
 arg=[own_addr=kimptoc:34521, coord_addr=kimptoc:34521]]
 2002-11-05 09:22:02,616 DEBUG [org.javagroups.DefaultPartition]
 [Tue
 Nov 5 09:22:02 GMT 2002] [INFO] PING.up(): received
 FIND_INITAL_MBRS_RSP, rsp=[own_addr=kimptoc:34521,
 coord_addr=kimptoc:34521]
 2002-11-05 09:22:04,615 DEBUG [org.javagroups.DefaultPartition]
 [Tue
 Nov 5 09:22:04 GMT 2002] [INFO] PING.down(): initial mbrs are
 [[own_addr=kimptoc:34521, coord_addr=kimptoc:34521]]
 2002-11-05 09:22:04,616 DEBUG [org.javagroups.DefaultPartition]
 [Tue
 Nov 5 09:22:04 GMT 2002] [INFO] MERGE2.FindSubgroups.run():
 initial_mbrs=[[own_addr=kimptoc:34521, coord_addr=kimptoc:34521]]


 Hope this helps,
 Chris



 =


 __
 Do you 

[JBoss-dev] [ jboss-Bugs-634286 ] Bug in the transactional locking code

2002-11-06 Thread noreply
Bugs item #634286, was opened at 2002-11-06 02:43
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detailatid=376685aid=634286group_id=22866

Category: JBossServer
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Ole Husgaard (sparre)
Assigned to: Bill Burke (patriot1burke)
Summary: Bug in the transactional locking code

Initial Comment:
I discovered this using Branch_3_2, but I think this
bug is present in all branches.

With multiple clients using UserTransaction, and the
queued pessimistic locking strategy, I see the
following problem in the locking code:

Client1: ut.begin()
  This calls the server, and returns the TPC for tx1
  to the client.

Client1: obj.invoke()
  This invokes a non-readonly method on an entity bean.
  In the server thread1 is selected for doing the work.
  In the bean lock, the holding transaction is set to
  tx1, and the holding thread is set to thread1.
  After doing the invocation, thread1 is put back into
  the RMI thread pool.
Client2: ut.begin()
  This calls the server, and returns the TPC for tx2
  to the client.
Client2: obj.invoke()
  This invokes the same bean as Client1 just invoked.
  In the server thread1 is selected (reused from the
  RMI pool) for doing the work.
  When invoking the locking code, thread1 should wait
  until the transaction tx1 started by Client1 is
  committed.
  However, that does not happen.
  In
org.jboss.ejb.plugins.lock.BeanLockSupport.deadlockDetection(),
  it is detected that the calling thread equals the
  holding thread, and an ApplicationDeadlockException
  is thrown.

I'm not sure that I completely understand this locking
code, so I'd rather not fix this myself.

However, it looks to me like the
BeanLockSupport.holdingThread instance variable
should be cleared before the transaction is committed.
But simply clearing holdingThread in the
endInvocation() method may cause problems with
reentrant calls.

Best Regards,

Ole Husgaard.



--

Comment By: Bill Burke (patriot1burke)
Date: 2002-11-06 10:17

Message:
Logged In: YES 
user_id=176497

Good catch.  It's definately a bug.  HOlding you up?

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detailatid=376685aid=634286group_id=22866


---
This sf.net email is sponsored by: See the NEW Palm 
Tungsten T handheld. Power  Color in a compact size!
http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development



Re: [JBoss-dev] HEAD - testsuite problems...

2002-11-06 Thread Chris Kimpton
Hi Adrian,

How long did it take on your Mandrake machine?  Less than 11hours, I
bet.

I presume I can send a kill signal (SIGHUP) to the jvm to get a
thread-dump?

Are you running them all at once, or individual tests?  

I am just running the tests target from the testsuite module.

Regards,
Chris

--- Adrian Brock [EMAIL PROTECTED] wrote:
 Hi Chris,
 
 I ran head tests yesterday, there are still
 time-outs relating to the trunk invokers,
 but it does complete.
 
 Windows XP 1Ghz P3 java 1.4
 Mandrake 8.1 450Mhz P2 java 1.3
 
 Have you tried a thread-dump to see whether
 there is a deadlock?
 
 Regards,
 Adrian
 
 From: Chris Kimpton [EMAIL PROTECTED]
 Reply-To: [EMAIL PROTECTED]
 To: [EMAIL PROTECTED]
 Subject: Re: [JBoss-dev] HEAD - testsuite problems...
 Date: Wed, 6 Nov 2002 03:35:18 -0800 (PST)
 
 Hi,
 
 Still not completing - although it seemed to have got to the
 stress
 tests today - but I did let it run for around 11 hours this
 time...
 
 Has anyone else run the full testsuite on HEAD recently?  How long
 did it take - on what machine?  I am using a 600mhz P3, redhat7.1
 box.
 
 Thanks,
 Chris
 
 
 --- Chris Kimpton [EMAIL PROTECTED] wrote:
   Hi,
  
   Perhaps I spoke too soon - the testsuite does not seem to
 complete
   (or at least, I give up after 9 hours...)
  
   The last entries in the test logs are:
  
   [junit] Running
   org.jboss.test.invokers.test.MultiInvokersUnitTestCase
   [junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed:
   9.392
   sec
   [junit] Running
   org.jboss.test.jbossmq.test.ConnectionUnitTestCase
   [junit] Tests run: 8, Failures: 0, Errors: 0, Time elapsed:
   7.219
   sec
   [junit] Running
 org.jboss.test.jbossmq.test.JBossMQUnitTestCase
   [junit] Tests run: 32, Failures: 0, Errors: 3, Time
 elapsed:
   31,954.962 sec
   [junit] TEST
 org.jboss.test.jbossmq.test.JBossMQUnitTestCase
   FAILED (timeout)
   [junit] Running
   org.jboss.test.jbossmq.test.JBossSessionRecoverUnitTestCase
  
  
  
   The server log has been filled with this stuff:
  
  
   DEBUG [org.jboss.mq.sm.file.DynamicStateManager] Saving config
 to:
  

/disk/orig/home/lubega/jbossro/jboss-all/build/output/testbuild/server/all/conf/jbossmq-state.xml
   2002-11-05 00:30:34,101 DEBUG [org.javagroups.DefaultPartition]
   [Tue
   Nov 5 00:30:34 GMT 2002] [INFO] PING.down(): FIND_INITIAL_MBRS
   2002-11-05 00:30:34,103 DEBUG [org.javagroups.DefaultPartition]
   [Tue
   Nov 5 00:30:34 GMT 2002] [INFO] PING.up(): received
 GET_MBRS_REQ
   from
   kimptoc:34521, returning [PING: type=GET_MBRS_RSP,
   arg=[own_addr=kimptoc:34521, coord_addr=kimptoc:34521]]
   2002-11-05 00:30:34,104 DEBUG [org.javagroups.DefaultPartition]
   [Tue
   Nov 5 00:30:34 GMT 2002] [INFO] PING.up(): received
   FIND_INITAL_MBRS_RSP, rsp=[own_addr=kimptoc:34521,
   coord_addr=kimptoc:34521]
   2002-11-05 00:30:36,105 DEBUG [org.javagroups.DefaultPartition]
   [Tue
   Nov 5 00:30:36 GMT 2002] [INFO] PING.down(): initial mbrs are
   [[own_addr=kimptoc:34521, coord_addr=kimptoc:34521]]
   2002-11-05 00:30:36,106 DEBUG [org.javagroups.DefaultPartition]
   [Tue
   Nov 5 00:30:36 GMT 2002] [INFO] MERGE2.FindSubgroups.run():
   initial_mbrs=[[own_addr=kimptoc:34521,
 coord_addr=kimptoc:34521]]
   2002-11-05 00:30:38,060 WARN
   [org.jboss.mq.security.SecurityManager]
   No SecurityMetadadata was available for JMS_TQ4 adding default
   security conf
   2002-11-05 00:30:45,464 DEBUG [org.javagroups.DefaultPartition]
   [Tue
   Nov 5 00:30:45 GMT 2002] [INFO] PING.down(): FIND_INITIAL_MBRS
   2002-11-05 00:30:45,467
  
  
  
   [ snip ]
  
  
   DEBUG [org.javagroups.DefaultPartition] [Tue Nov 5 09:21:50 GMT
   2002]
   [INFO] PING.up(): received GET_MBRS_REQ from kimptoc:34521,
   returning
   [PING: type=GET_MBRS_RSP, arg=[own_addr=kimptoc:34521,
   coord_addr=kimptoc:34521]]
   2002-11-05 09:21:50,622 DEBUG [org.javagroups.DefaultPartition]
   [Tue
   Nov 5 09:21:50 GMT 2002] [INFO] PING.up(): received
   FIND_INITAL_MBRS_RSP, rsp=[own_addr=kimptoc:34521,
   coord_addr=kimptoc:34521]
   2002-11-05 09:21:52,621 DEBUG [org.javagroups.DefaultPartition]
   [Tue
   Nov 5 09:21:52 GMT 2002] [INFO] PING.down(): initial mbrs are
   [[own_addr=kimptoc:34521, coord_addr=kimptoc:34521]]
   2002-11-05 09:21:52,622 DEBUG [org.javagroups.DefaultPartition]
   [Tue
   Nov 5 09:21:52 GMT 2002] [INFO] MERGE2.FindSubgroups.run():
   initial_mbrs=[[own_addr=kimptoc:34521,
 coord_addr=kimptoc:34521]]
   2002-11-05 09:22:02,613 DEBUG [org.javagroups.DefaultPartition]
   [Tue
   Nov 5 09:22:02 GMT 2002] [INFO] PING.down(): FIND_INITIAL_MBRS
   2002-11-05 09:22:02,615 DEBUG [org.javagroups.DefaultPartition]
   [Tue
   Nov 5 09:22:02 GMT 2002] [INFO] PING.up(): received
 GET_MBRS_REQ
   from
   kimptoc:34521, returning [PING: type=GET_MBRS_RSP,
   arg=[own_addr=kimptoc:34521, coord_addr=kimptoc:34521]]
   2002-11-05 09:22:02,616 DEBUG [org.javagroups.DefaultPartition]
   [Tue
   Nov 5 09:22:02 GMT 2002] [INFO] 

[JBoss-dev] [ jboss-Patches-634495 ] Poor Error message in EJB deployer

2002-11-06 Thread noreply
Patches item #634495, was opened at 2002-11-06 15:58
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detailatid=376687aid=634495group_id=22866

Category: JBossCMP
Group: v3.0 Rabbit Hole
Status: Open
Resolution: None
Priority: 5
Submitted By: Steinar Hansen (shansen5)
Assigned to: Nobody/Anonymous (nobody)
Summary: Poor Error message in EJB deployer

Initial Comment:
When deploying an EJB, I lacked a matching cmp-field 
in the ejb-jar.xml file for a field-name in the jbosscmp-
jdbc.xml.  The error message produced was: CMP field 
not found : fieldName=  

This error message doesn't tell anything about why the 
fieldName is not found or in which entitybean the error 
occurs.

The DeploymentException produced is generated in 
org.jboss.ejb.plugins.cmp.jdbc.metadata.JDBCEntityMet
aData.java.  The code is: throw new 
DeploymentException(CMP field not found : 
fieldName= +
  fieldName);

I suggest changing this to:
throw new DeploymentException(CMP field not found in 
ejb-jar.xml: fieldName= +fieldName+
for entitybean: +entityName);



--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detailatid=376687aid=634495group_id=22866


---
This sf.net email is sponsored by: See the NEW Palm 
Tungsten T handheld. Power  Color in a compact size!
http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development



Re: [JBoss-dev] HEAD - testsuite problems...

2002-11-06 Thread Adrian Brock
Answers in line.

Regards,
Adrian


From: Chris Kimpton [EMAIL PROTECTED]
Reply-To: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: Re: [JBoss-dev] HEAD - testsuite problems...
Date: Wed, 6 Nov 2002 07:41:55 -0800 (PST)

Hi Adrian,

How long did it take on your Mandrake machine?  Less than 11hours, I
bet.


About 2 hours including the time-outs. That machine is
seriously short of memory :-(



I presume I can send a kill signal (SIGHUP) to the jvm to get a
thread-dump?


Yep



Are you running them all at once, or individual tests?

I am just running the tests target from the testsuite module.


./build.sh tests



Regards,
Chris

--- Adrian Brock [EMAIL PROTECTED] wrote:
 Hi Chris,

 I ran head tests yesterday, there are still
 time-outs relating to the trunk invokers,
 but it does complete.

 Windows XP 1Ghz P3 java 1.4
 Mandrake 8.1 450Mhz P2 java 1.3

 Have you tried a thread-dump to see whether
 there is a deadlock?

 Regards,
 Adrian

 From: Chris Kimpton [EMAIL PROTECTED]
 Reply-To: [EMAIL PROTECTED]
 To: [EMAIL PROTECTED]
 Subject: Re: [JBoss-dev] HEAD - testsuite problems...
 Date: Wed, 6 Nov 2002 03:35:18 -0800 (PST)
 
 Hi,
 
 Still not completing - although it seemed to have got to the
 stress
 tests today - but I did let it run for around 11 hours this
 time...
 
 Has anyone else run the full testsuite on HEAD recently?  How long
 did it take - on what machine?  I am using a 600mhz P3, redhat7.1
 box.
 
 Thanks,
 Chris
 
 
 --- Chris Kimpton [EMAIL PROTECTED] wrote:
   Hi,
  
   Perhaps I spoke too soon - the testsuite does not seem to
 complete
   (or at least, I give up after 9 hours...)
  
   The last entries in the test logs are:
  
   [junit] Running
   org.jboss.test.invokers.test.MultiInvokersUnitTestCase
   [junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed:
   9.392
   sec
   [junit] Running
   org.jboss.test.jbossmq.test.ConnectionUnitTestCase
   [junit] Tests run: 8, Failures: 0, Errors: 0, Time elapsed:
   7.219
   sec
   [junit] Running
 org.jboss.test.jbossmq.test.JBossMQUnitTestCase
   [junit] Tests run: 32, Failures: 0, Errors: 3, Time
 elapsed:
   31,954.962 sec
   [junit] TEST
 org.jboss.test.jbossmq.test.JBossMQUnitTestCase
   FAILED (timeout)
   [junit] Running
   org.jboss.test.jbossmq.test.JBossSessionRecoverUnitTestCase
  
  
  
   The server log has been filled with this stuff:
  
  
   DEBUG [org.jboss.mq.sm.file.DynamicStateManager] Saving config
 to:
  

/disk/orig/home/lubega/jbossro/jboss-all/build/output/testbuild/server/all/conf/jbossmq-state.xml
   2002-11-05 00:30:34,101 DEBUG [org.javagroups.DefaultPartition]
   [Tue
   Nov 5 00:30:34 GMT 2002] [INFO] PING.down(): FIND_INITIAL_MBRS
   2002-11-05 00:30:34,103 DEBUG [org.javagroups.DefaultPartition]
   [Tue
   Nov 5 00:30:34 GMT 2002] [INFO] PING.up(): received
 GET_MBRS_REQ
   from
   kimptoc:34521, returning [PING: type=GET_MBRS_RSP,
   arg=[own_addr=kimptoc:34521, coord_addr=kimptoc:34521]]
   2002-11-05 00:30:34,104 DEBUG [org.javagroups.DefaultPartition]
   [Tue
   Nov 5 00:30:34 GMT 2002] [INFO] PING.up(): received
   FIND_INITAL_MBRS_RSP, rsp=[own_addr=kimptoc:34521,
   coord_addr=kimptoc:34521]
   2002-11-05 00:30:36,105 DEBUG [org.javagroups.DefaultPartition]
   [Tue
   Nov 5 00:30:36 GMT 2002] [INFO] PING.down(): initial mbrs are
   [[own_addr=kimptoc:34521, coord_addr=kimptoc:34521]]
   2002-11-05 00:30:36,106 DEBUG [org.javagroups.DefaultPartition]
   [Tue
   Nov 5 00:30:36 GMT 2002] [INFO] MERGE2.FindSubgroups.run():
   initial_mbrs=[[own_addr=kimptoc:34521,
 coord_addr=kimptoc:34521]]
   2002-11-05 00:30:38,060 WARN
   [org.jboss.mq.security.SecurityManager]
   No SecurityMetadadata was available for JMS_TQ4 adding default
   security conf
   2002-11-05 00:30:45,464 DEBUG [org.javagroups.DefaultPartition]
   [Tue
   Nov 5 00:30:45 GMT 2002] [INFO] PING.down(): FIND_INITIAL_MBRS
   2002-11-05 00:30:45,467
  
  
  
   [ snip ]
  
  
   DEBUG [org.javagroups.DefaultPartition] [Tue Nov 5 09:21:50 GMT
   2002]
   [INFO] PING.up(): received GET_MBRS_REQ from kimptoc:34521,
   returning
   [PING: type=GET_MBRS_RSP, arg=[own_addr=kimptoc:34521,
   coord_addr=kimptoc:34521]]
   2002-11-05 09:21:50,622 DEBUG [org.javagroups.DefaultPartition]
   [Tue
   Nov 5 09:21:50 GMT 2002] [INFO] PING.up(): received
   FIND_INITAL_MBRS_RSP, rsp=[own_addr=kimptoc:34521,
   coord_addr=kimptoc:34521]
   2002-11-05 09:21:52,621 DEBUG [org.javagroups.DefaultPartition]
   [Tue
   Nov 5 09:21:52 GMT 2002] [INFO] PING.down(): initial mbrs are
   [[own_addr=kimptoc:34521, coord_addr=kimptoc:34521]]
   2002-11-05 09:21:52,622 DEBUG [org.javagroups.DefaultPartition]
   [Tue
   Nov 5 09:21:52 GMT 2002] [INFO] MERGE2.FindSubgroups.run():
   initial_mbrs=[[own_addr=kimptoc:34521,
 coord_addr=kimptoc:34521]]
   2002-11-05 09:22:02,613 DEBUG [org.javagroups.DefaultPartition]
   [Tue
   Nov 5 09:22:02 GMT 2002] [INFO] PING.down(): FIND_INITIAL_MBRS
   2002-11-05 09:22:02,615 DEBUG 

[JBoss-dev] [ jboss-Bugs-634286 ] Bug in the transactional locking code

2002-11-06 Thread noreply
Bugs item #634286, was opened at 2002-11-06 07:43
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detailatid=376685aid=634286group_id=22866

Category: JBossServer
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Ole Husgaard (sparre)
Assigned to: Bill Burke (patriot1burke)
Summary: Bug in the transactional locking code

Initial Comment:
I discovered this using Branch_3_2, but I think this
bug is present in all branches.

With multiple clients using UserTransaction, and the
queued pessimistic locking strategy, I see the
following problem in the locking code:

Client1: ut.begin()
  This calls the server, and returns the TPC for tx1
  to the client.

Client1: obj.invoke()
  This invokes a non-readonly method on an entity bean.
  In the server thread1 is selected for doing the work.
  In the bean lock, the holding transaction is set to
  tx1, and the holding thread is set to thread1.
  After doing the invocation, thread1 is put back into
  the RMI thread pool.
Client2: ut.begin()
  This calls the server, and returns the TPC for tx2
  to the client.
Client2: obj.invoke()
  This invokes the same bean as Client1 just invoked.
  In the server thread1 is selected (reused from the
  RMI pool) for doing the work.
  When invoking the locking code, thread1 should wait
  until the transaction tx1 started by Client1 is
  committed.
  However, that does not happen.
  In
org.jboss.ejb.plugins.lock.BeanLockSupport.deadlockDetection(),
  it is detected that the calling thread equals the
  holding thread, and an ApplicationDeadlockException
  is thrown.

I'm not sure that I completely understand this locking
code, so I'd rather not fix this myself.

However, it looks to me like the
BeanLockSupport.holdingThread instance variable
should be cleared before the transaction is committed.
But simply clearing holdingThread in the
endInvocation() method may cause problems with
reentrant calls.

Best Regards,

Ole Husgaard.



--

Comment By: Ole Husgaard (sparre)
Date: 2002-11-06 17:22

Message:
Logged In: YES 
user_id=175257

This doesn't hold me up. I currently do not have reentrant
beans, so I simply hacked the source to clear holdingThread
in endInvocation().

--

Comment By: Bill Burke (patriot1burke)
Date: 2002-11-06 15:17

Message:
Logged In: YES 
user_id=176497

Good catch.  It's definately a bug.  HOlding you up?

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detailatid=376685aid=634286group_id=22866


---
This sf.net email is sponsored by: See the NEW Palm 
Tungsten T handheld. Power  Color in a compact size!
http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development



[JBoss-dev] [ jboss-Bugs-621664 ] test hangs with 3.0.3 but passes 3.0.2

2002-11-06 Thread noreply
Bugs item #621664, was opened at 2002-10-10 21:18
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detailatid=376685aid=621664group_id=22866

Category: JBossServer
Group: None
Status: Open
Resolution: None
Priority: 7
Submitted By: Joe Simone (jsimone)
Assigned to: Nobody/Anonymous (nobody)
Summary: test hangs with 3.0.3 but passes 3.0.2

Initial Comment:
OS:  Win XP Pro, SP1
JDK 1.3.1_05

I have a test that creates sample data in my DB2 
database.  Using DB2 EE 7.2 with fixpack 7 applied.

If I run the data creator under 3.0.2/4.0.4 then it runs to 
completion.

If I run the data creator under 3.0.3/4.1.12 then my 
console client just stops midway.   I'll get a WARN 
about timeout with STATUS_ACTIVE.

How can I enable debug so I can provide more info?

P.S. didn't know which component to open under so I 
just picked JBossTX



--

Comment By: Joe Simone (jsimone)
Date: 2002-11-06 13:51

Message:
Logged In: YES 
user_id=586242

Still happens with latest 3.0.4 Jboss.

System just freezes.  After a while I get this in the console:

12:55:25,059 INFO  [Server] JBoss (MX MicroKernel) [3.0.4 
Date:200211021607] Started in 0m:32s:287ms
13:11:30,237 WARN  [TxCapsule] Transaction XidImpl 
[FormatId=257, GlobalId=BJSLAP//4359, BranchQual=] 
timed out. status=
STATUS_ACTIVE




--

Comment By: Joe Simone (jsimone)
Date: 2002-10-23 09:43

Message:
Logged In: YES 
user_id=586242

can you tell me how to turn on full debug in server.log so I 
can see what is going on and report back.

Thanks.

--

Comment By: David Jencks (d_jencks)
Date: 2002-10-22 11:33

Message:
Logged In: YES 
user_id=60525

Your thread dump makes it look like db2 is hung on the fetch
entity command.  Can you investigate this and determine what
the sql is and what db2 has to say about it?

This would be consistent with a db2 process becoming unusable...

--

Comment By: Joe Simone (jsimone)
Date: 2002-10-22 10:30

Message:
Logged In: YES 
user_id=586242

Has there been any action on this problem?  I have stopped 
using 3.0.3 and gone back to 3.0.2 since this occurred.

BTW, when the server/app freezes and I close down the 
JBoss server, one or more of my DB2 processes are toast!  
This is the first time I have seen JBoss killing my database 
server!



--

Comment By: Joe Simone (jsimone)
Date: 2002-10-14 17:40

Message:
Logged In: YES 
user_id=586242

CTRL-BREAK results in ...

17:27:35,505 INFO  [Server] JBoss (MX MicroKernel) [3.0.3 
Date:200209301503] Started in 0m:20s:459ms
Full thread dump:

SeedGenerator Thread daemon prio=2 tid=0x164b4478 
nid=0x8c8 waiting on monitor [0x1753f000..0x1753fdbc]
at java.lang.Object.wait(Native Method)
at java.lang.Object.wait(Object.java:415)
at sun.security.provider.SeedGenerator.run
(SeedGenerator.java:100)
at java.lang.Thread.run(Thread.java:479)

RMI TCP Connection(4)-192.168.2.35 daemon prio=5 
tid=0x15b60eb0 nid=0x310 runnable [0x174fe000..0x174ffdbc]
at 
COM.ibm.db2.jdbc.app.DB2PreparedStatement.SQLExecute
(Native Method)
at 
COM.ibm.db2.jdbc.app.DB2PreparedStatement.execute2
(DB2PreparedStatement.java:2065)
at 
COM.ibm.db2.jdbc.app.DB2PreparedStatement.executeQuer
y(DB2PreparedStatement.java:1596)
at 
org.jboss.resource.adapter.jdbc.local.LocalPreparedStatemen
t.executeQuery(LocalPreparedStatement.java:289)
at 
org.jboss.ejb.plugins.cmp.jdbc.JDBCLoadEntityCommand.ex
ecute(JDBCLoadEntityCommand.java:122)
at 
org.jboss.ejb.plugins.cmp.jdbc.JDBCLoadEntityCommand.ex
ecute(JDBCLoadEntityCommand.java:62)
at 
org.jboss.ejb.plugins.cmp.jdbc.JDBCStoreManager.loadEntity
(JDBCStoreManager.java:572)
at 
org.jboss.ejb.plugins.CMPPersistenceManager.loadEntity
(CMPPersistenceManager.java:410)
at 
org.jboss.resource.connectionmanager.CachedConnectionInte
rceptor.loadEntity(CachedConnectionInterceptor.java:
353)
at 
org.jboss.ejb.plugins.EntitySynchronizationInterceptor.invoke
(EntitySynchronizationInterceptor.java:262)
at 
org.jboss.resource.connectionmanager.CachedConnectionInte
rceptor.invoke(CachedConnectionInterceptor.java:186)

at 
org.jboss.ejb.plugins.EntityReentranceInterceptor.invoke
(EntityReentranceInterceptor.java:90)
at org.jboss.ejb.plugins.EntityInstanceInterceptor.invoke
(EntityInstanceInterceptor.java:152)
at org.jboss.ejb.plugins.EntityLockInterceptor.invoke
(EntityLockInterceptor.java:107)
at org.jboss.ejb.plugins.EntityCreationInterceptor.invoke
(EntityCreationInterceptor.java:69)
at 
org.jboss.ejb.plugins.AbstractTxInterceptor.invokeNext
(AbstractTxInterceptor.java:107)
at 

[JBoss-dev] [ jboss-Bugs-634591 ] netboot failure

2002-11-06 Thread noreply
Bugs item #634591, was opened at 2002-11-06 19:06
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detailatid=376685aid=634591group_id=22866

Category: None
Group: v3.0 Rabbit Hole
Status: Open
Resolution: None
Priority: 5
Submitted By: ryan sonnek (wireframe6464)
Assigned to: Nobody/Anonymous (nobody)
Summary: netboot failure

Initial Comment:
server specs:
suse linux 7.3
sun 1.3.1 jdk
apache web server 2.x
jboss 3.0.2 config files

client specs:
win2k
sun 1.4.0 jdk
jboss 3.0.2 netboot files.

can view the files correctly through a webbrowser, but
when client executes run.bat, no files are pulled down.
 apache's server log shows the client trying to
download crimson.jar.  both the server and client are
unresponsive, and no error messages are thrown.

run.bat -netboot http://servername -c custom


--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detailatid=376685aid=634591group_id=22866


---
This sf.net email is sponsored by: See the NEW Palm 
Tungsten T handheld. Power  Color in a compact size!
http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development



[JBoss-dev] [ jboss-Bugs-634646 ] ejb-ql - LIKE

2002-11-06 Thread noreply
Bugs item #634646, was opened at 2002-11-06 15:48
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detailatid=376685aid=634646group_id=22866

Category: JBossCMP
Group: v3.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Calvin (cwu9t9)
Assigned to: Nobody/Anonymous (nobody)
Summary: ejb-ql - LIKE

Initial Comment:
Operating System: Suse Linux 7.3
JDK: jdk1.3.1
jboss version: 3.0.4

 I have a question in regards to the finders method
that involves the LIKE command. In my ejb-jar.xml, i
have a query as below (i.e.):

query
query-method
method-namefindByVendor/method-name
method-params
method-paramjava.lang.String/method-param
/method-params
/query-method
ejb-ql
![CDATA[SELECT OBJECT(i) FROM T_Item i WHERE
i.vendor.name LIKE '%?1%']]
/ejb-ql
/query

Assuming 2 rows of data should be returned:

The above query would return nothing.  However,
![CDATA[SELECT OBJECT(i) FROM T_Item i WHERE
i.vendor.name LIKE '%Sony%']] works fine.  I noticed
from the forum of a similar question in regards to
3.0.1 that LIKE query would not work with any method
parameters.   Apparanlty, it didn't work for 3.0.4 as
well.  Is this still a bug or have I used it in a wrong
way??

Thanks,  

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detailatid=376685aid=634646group_id=22866


---
This sf.net email is sponsored by: See the NEW Palm 
Tungsten T handheld. Power  Color in a compact size!
http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development



Re: [JBoss-dev] Upcoming releases

2002-11-06 Thread Jules Gosnell
What has happened to the 3.2beta release ?

I have some stuff to put in - am I to late ?


Jules



Scott M Stark wrote:

I'm planning on the following releases so time your work accordingly:

2002-10-25jboss-2.4.10
2002-10-27jboss-3.0.4
2002-11-03jboss-3.0.2beta2
2002-12-22jboss-4.0alpha


Scott Stark
Chief Technology Officer
JBoss Group, LLC



---
This sf.net email is sponsored by:
Access Your PC Securely with GoToMyPC. Try Free Now
https://www.gotomypc.com/s/OSND/DD
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development






---
This sf.net email is sponsored by: See the NEW Palm 
Tungsten T handheld. Power  Color in a compact size!
http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development


[JBoss-dev] Automated JBoss(Branch_3_0) Testsuite Results: 6-November-2002

2002-11-06 Thread scott . stark

Number of tests run:   989



Successful tests:  985
Errors:4
Failures:  0



[time of test: 6 November 2002 12:51 GMT]
[java.version: 1.3.1]
[java.vendor: Apple Computer, Inc.]
[java.vm.version: 1.3.1_03-69]
[java.vm.name: Java HotSpot(TM) Client VM]
[java.vm.info: mixed mode]
[os.name: Mac OS X]
[os.arch: ppc]
[os.version: 10.2.1]

See http://lubega.com/testarchive/${build.uid} for details of this test.

See http://lubega.com for general test information.

NOTE: If there are any errors shown above - this mail is only highlighting 
them - it is NOT indicating that they are being looked at by anyone.
Remember - if a test becomes broken after your changes - fix it or fix the test!





Oh dear - still got some errors!



Thanks for all your effort - we really do love you!




---
This sf.net email is sponsored by: See the NEW Palm 
Tungsten T handheld. Power  Color in a compact size!
http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development



[JBoss-dev] [ jboss-Bugs-634677 ] EJB in ja in server lib dir auto-deploys

2002-11-06 Thread noreply
Bugs item #634677, was opened at 2002-11-06 21:58
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detailatid=376685aid=634677group_id=22866

Category: JBossServer
Group: v3.0 Rabbit Hole
Status: Open
Resolution: None
Priority: 5
Submitted By: Colin Sampaleanu (colins)
Assigned to: Nobody/Anonymous (nobody)
Summary: EJB in ja in server lib dir auto-deploys

Initial Comment:
If a jar is added to the server lib dir (e.g.
server/default/lib), to make use of some classes in
that jar, and that jar also contains one or more EJBs,
those EJBs are automaticallly deployed as the server is
started.

This is quite problematic. Even if deployment of the
EJBs was desired, the auto-deployment at this time
happens before some other resources have been deployed
(such as datasources, etfc.) that the EJBs may need.

Ideally EJBs are packaged standalone, separate from
other java classes. However, it is quite legal to put
them together with  other code. OSUser, from
OpenSymphony, for example, is packaged in this fashion.
Inside the jar file is a JBoss login module, which to
be available to used by JBoss requires the osuser.jar
to be added to the server lib dir. Inside OSUser.jar
are also some EJBs, useful in other osusr usage
scenarios. Those EJBs then (erronously) automatically
get deployed at server startup.

This bug is somewhat similar to the (resolved) bug #
589808 (EJB Jars already deployed by MANIFEST.MF), and
a resolution should be similar.


--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detailatid=376685aid=634677group_id=22866


---
This sf.net email is sponsored by: See the NEW Palm 
Tungsten T handheld. Power  Color in a compact size!
http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development



[JBoss-dev] Customizing JBoss server configurations

2002-11-06 Thread Igor Fedorenko
Hi,

I've created an ant script that allows easy creation of custom jboss 
server configurations (other then all, default and minimal). Basically, 
it defines a bunch of targets like jbossmq, transaction-manager and 
alike from which you can assemble your own unique server. I am using 
this script to reduce amount of resource used by jboss by removing 
services that are not used to my app but I can see other usages as well.

Of course, this script is far from being complete but if it sounds like 
a good idea I can put it somewhere so people can start using/improving 
it. Thoughts?

--
Igor Fedorenko
Think smart. Think automated. Think Dynamics.
www.thinkdynamics.com



---
This sf.net email is sponsored by: See the NEW Palm 
Tungsten T handheld. Power  Color in a compact size!
http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development


[JBoss-dev] [ jboss-Bugs-634646 ] ejb-ql - LIKE

2002-11-06 Thread noreply
Bugs item #634646, was opened at 2002-11-06 14:48
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detailatid=376685aid=634646group_id=22866

Category: JBossCMP
Group: v3.0 Rabbit Hole
Status: Closed
Resolution: Invalid
Priority: 5
Submitted By: Calvin (cwu9t9)
Assigned to: Dain Sundstrom (dsundstrom)
Summary: ejb-ql - LIKE

Initial Comment:
Operating System: Suse Linux 7.3
JDK: jdk1.3.1
jboss version: 3.0.4

 I have a question in regards to the finders method
that involves the LIKE command. In my ejb-jar.xml, i
have a query as below (i.e.):

query
query-method
method-namefindByVendor/method-name
method-params
method-paramjava.lang.String/method-param
/method-params
/query-method
ejb-ql
![CDATA[SELECT OBJECT(i) FROM T_Item i WHERE
i.vendor.name LIKE '%?1%']]
/ejb-ql
/query

Assuming 2 rows of data should be returned:

The above query would return nothing.  However,
![CDATA[SELECT OBJECT(i) FROM T_Item i WHERE
i.vendor.name LIKE '%Sony%']] works fine.  I noticed
from the forum of a similar question in regards to
3.0.1 that LIKE query would not work with any method
parameters.   Apparanlty, it didn't work for 3.0.4 as
well.  Is this still a bug or have I used it in a wrong
way??

Thanks,  

--

Comment By: Dain Sundstrom (dsundstrom)
Date: 2002-11-06 17:30

Message:
Logged In: YES 
user_id=251431

Did you even take a look at the spec?  Have you read any
books on EJB-QL?  

The spec doesn't allow parameters in the like clause, and it
definately doesn't support them inside of a string literal.
 If you want to create this type of query you will have to
use JBossQL in 3.0.4 and either preprocess the argument to
include the % signs on either side, or you will have to use
the concat function to build it in the JBossQL statement.

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detailatid=376685aid=634646group_id=22866


---
This sf.net email is sponsored by: See the NEW Palm 
Tungsten T handheld. Power  Color in a compact size!
http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development



RE: [JBoss-dev] Customizing JBoss server configurations

2002-11-06 Thread Bill Burke
Yes that is a great idea.  What kind of script?  sh, perl, python, java, ??

I've done the same for the CD subscription but using InstallAnywhere.

 -Original Message-
 From: [EMAIL PROTECTED]
 [mailto:jboss-development-admin;lists.sourceforge.net]On Behalf Of Igor
 Fedorenko
 Sent: Wednesday, November 06, 2002 5:07 PM
 To: jboss-development
 Subject: [JBoss-dev] Customizing JBoss server configurations
 
 
 Hi,
 
 I've created an ant script that allows easy creation of custom jboss 
 server configurations (other then all, default and minimal). Basically, 
 it defines a bunch of targets like jbossmq, transaction-manager and 
 alike from which you can assemble your own unique server. I am using 
 this script to reduce amount of resource used by jboss by removing 
 services that are not used to my app but I can see other usages as well.
 
 Of course, this script is far from being complete but if it sounds like 
 a good idea I can put it somewhere so people can start using/improving 
 it. Thoughts?
 
 -- 
 Igor Fedorenko
 Think smart. Think automated. Think Dynamics.
 www.thinkdynamics.com
 
 
 
 ---
 This sf.net email is sponsored by: See the NEW Palm 
 Tungsten T handheld. Power  Color in a compact size!
 http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en
 ___
 Jboss-development mailing list
 [EMAIL PROTECTED]
 https://lists.sourceforge.net/lists/listinfo/jboss-development


---
This sf.net email is sponsored by: See the NEW Palm 
Tungsten T handheld. Power  Color in a compact size!
http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development



Re: [JBoss-dev] Upcoming releases

2002-11-06 Thread Scott M Stark
Go ahead.


Scott Stark
Chief Technology Officer
JBoss Group, LLC


- Original Message - 
From: Jules Gosnell [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Wednesday, November 06, 2002 1:09 PM
Subject: Re: [JBoss-dev] Upcoming releases


 What has happened to the 3.2beta release ?
 
 I have some stuff to put in - am I to late ?
 
 
 Jules
 
 
 
 Scott M Stark wrote:
  I'm planning on the following releases so time your work accordingly:
  
  2002-10-25jboss-2.4.10
  2002-10-27jboss-3.0.4
  2002-11-03jboss-3.0.2beta2
  2002-12-22jboss-4.0alpha
  
  
  Scott Stark
  Chief Technology Officer
  JBoss Group, LLC
  
  
  
  ---
  This sf.net email is sponsored by:
  Access Your PC Securely with GoToMyPC. Try Free Now
  https://www.gotomypc.com/s/OSND/DD
  ___
  Jboss-development mailing list
  [EMAIL PROTECTED]
  https://lists.sourceforge.net/lists/listinfo/jboss-development
 
 
 
 
 
 ---
 This sf.net email is sponsored by: See the NEW Palm 
 Tungsten T handheld. Power  Color in a compact size!
 http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en
 ___
 Jboss-development mailing list
 [EMAIL PROTECTED]
 https://lists.sourceforge.net/lists/listinfo/jboss-development
 


---
This sf.net email is sponsored by: See the NEW Palm 
Tungsten T handheld. Power  Color in a compact size!
http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development



RE: [JBoss-dev] Upcoming releases

2002-11-06 Thread James Higginbotham
Scott,

Can you or someone on the team tell me which version I should upgrade
our product to - 3.0.x or 3.2? I'm about to move from 3.0.0 and want to
make sure I'm on the right branch to make migration to 4.0 easier in the
future while remaining stable for our product release that will occur by
the EOY. 

Thanks,
James

 -Original Message-
 From: Scott M Stark [mailto:scottmstark;attbi.com] 
 Sent: Wednesday, November 06, 2002 8:17 PM
 To: [EMAIL PROTECTED]
 Subject: Re: [JBoss-dev] Upcoming releases
 
 
 Go ahead.
 
 
 Scott Stark
 Chief Technology Officer
 JBoss Group, LLC
 
 
 - Original Message - 
 From: Jules Gosnell [EMAIL PROTECTED]
 To: [EMAIL PROTECTED]
 Sent: Wednesday, November 06, 2002 1:09 PM
 Subject: Re: [JBoss-dev] Upcoming releases
 
 
  What has happened to the 3.2beta release ?
  
  I have some stuff to put in - am I to late ?
  
  
  Jules
  
  
  
  Scott M Stark wrote:
   I'm planning on the following releases so time your work 
   accordingly:
   
   2002-10-25jboss-2.4.10
   2002-10-27jboss-3.0.4
   2002-11-03jboss-3.0.2beta2
   2002-12-22jboss-4.0alpha
   
   
   Scott Stark
   Chief Technology Officer
   JBoss Group, LLC
   
   
   
   ---
   This sf.net email is sponsored by:
   Access Your PC Securely with GoToMyPC. Try Free Now 
   https://www.gotomypc.com/s/OSND/DD
   ___
   Jboss-development mailing list 
   [EMAIL PROTECTED]
   https://lists.sourceforge.net/lists/listinfo/jboss-development
  
  
  
  
  
  ---
  This sf.net email is sponsored by: See the NEW Palm
  Tungsten T handheld. Power  Color in a compact size!
  http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en
  ___
  Jboss-development mailing list
  [EMAIL PROTECTED]
  https://lists.sourceforge.net/lists/listinfo/jboss-development
  
 
 
 ---
 This sf.net email is sponsored by: See the NEW Palm 
 Tungsten T handheld. Power  Color in a compact size!
 http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en
 ___
 Jboss-development mailing list
 [EMAIL PROTECTED]
 https://lists.sourceforge.net/lists/listinfo/jboss-development
 


---
This sf.net email is sponsored by: See the NEW Palm
Tungsten T handheld. Power  Color in a compact size!
http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development



RE: [JBoss-dev] Upcoming releases

2002-11-06 Thread Bill Burke
Personally I'd stay with 3.0.x series.  New functionality will not be added
to it while it will with 3.2.

 -Original Message-
 From: [EMAIL PROTECTED]
 [mailto:jboss-development-admin;lists.sourceforge.net]On Behalf Of James
 Higginbotham
 Sent: Wednesday, November 06, 2002 9:47 PM
 To: [EMAIL PROTECTED]
 Subject: RE: [JBoss-dev] Upcoming releases


 Scott,

 Can you or someone on the team tell me which version I should upgrade
 our product to - 3.0.x or 3.2? I'm about to move from 3.0.0 and want to
 make sure I'm on the right branch to make migration to 4.0 easier in the
 future while remaining stable for our product release that will occur by
 the EOY.

 Thanks,
 James

  -Original Message-
  From: Scott M Stark [mailto:scottmstark;attbi.com]
  Sent: Wednesday, November 06, 2002 8:17 PM
  To: [EMAIL PROTECTED]
  Subject: Re: [JBoss-dev] Upcoming releases
 
 
  Go ahead.
 
  
  Scott Stark
  Chief Technology Officer
  JBoss Group, LLC
  
 
  - Original Message -
  From: Jules Gosnell [EMAIL PROTECTED]
  To: [EMAIL PROTECTED]
  Sent: Wednesday, November 06, 2002 1:09 PM
  Subject: Re: [JBoss-dev] Upcoming releases
 
 
   What has happened to the 3.2beta release ?
  
   I have some stuff to put in - am I to late ?
  
  
   Jules
  
  
  
   Scott M Stark wrote:
I'm planning on the following releases so time your work
accordingly:
   
2002-10-25jboss-2.4.10
2002-10-27jboss-3.0.4
2002-11-03jboss-3.0.2beta2
2002-12-22jboss-4.0alpha
   

Scott Stark
Chief Technology Officer
JBoss Group, LLC

   
   
---
This sf.net email is sponsored by:
Access Your PC Securely with GoToMyPC. Try Free Now
https://www.gotomypc.com/s/OSND/DD
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
  
  
  
  
  
   ---
   This sf.net email is sponsored by: See the NEW Palm
   Tungsten T handheld. Power  Color in a compact size!
   http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en
   ___
   Jboss-development mailing list
   [EMAIL PROTECTED]
   https://lists.sourceforge.net/lists/listinfo/jboss-development
  
 
 
  ---
  This sf.net email is sponsored by: See the NEW Palm
  Tungsten T handheld. Power  Color in a compact size!
  http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en
  ___
  Jboss-development mailing list
  [EMAIL PROTECTED]
  https://lists.sourceforge.net/lists/listinfo/jboss-development
 


 ---
 This sf.net email is sponsored by: See the NEW Palm
 Tungsten T handheld. Power  Color in a compact size!
 http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en
 ___
 Jboss-development mailing list
 [EMAIL PROTECTED]
 https://lists.sourceforge.net/lists/listinfo/jboss-development



---
This sf.net email is sponsored by: See the NEW Palm 
Tungsten T handheld. Power  Color in a compact size!
http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development



[JBoss-dev] [ jboss-Change Notes-634830 ] Added Unicast Detector

2002-11-06 Thread noreply
Change Notes item #634830, was opened at 2002-11-07 01:04
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detailatid=381174aid=634830group_id=22866

Category: JBossMX
Group: v3.0 (Rabbit Hole)
Status: Open
Priority: 5
Submitted By: Jeff Haynie (jhaynie)
Assigned to: Nobody/Anonymous (nobody)
Summary: Added Unicast Detector

Initial Comment:
Added a JMX Remoting unicast detector that will do 
unicast detection of remote connectors using 1..n of 
known ipaddress:ports

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detailatid=381174aid=634830group_id=22866


---
This sf.net email is sponsored by: See the NEW Palm 
Tungsten T handheld. Power  Color in a compact size!
http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development



[JBoss-dev] [ jboss-Change Notes-634831 ] Added remote class loading

2002-11-06 Thread noreply
Change Notes item #634831, was opened at 2002-11-07 01:06
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detailatid=381174aid=634831group_id=22866

Category: JBossMX
Group: v3.0 (Rabbit Hole)
Status: Open
Priority: 5
Submitted By: Jeff Haynie (jhaynie)
Assigned to: Nobody/Anonymous (nobody)
Summary: Added remote class loading

Initial Comment:
Added ability for a connector to remotely pull down the 
remote class bytes if a connector doesn't have them 
locally for JMX Remoting.  This is specific to the 
Connector implementation.  Created a generic 
ClassBytesClassloader that all connectors can use for 
adding classbytes from remote MBeanServers.

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detailatid=381174aid=634831group_id=22866


---
This sf.net email is sponsored by: See the NEW Palm 
Tungsten T handheld. Power  Color in a compact size!
http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development



[JBoss-dev] JBoss Clustering problem

2002-11-06 Thread Vishal Shukla
Hello,

I am facing problem in JBoss Clustering.I am having Two nodes in cluster.When One node 
is down.Client Automatically send request to other node.But if any node is getting the 
 exception like..

 Could not create entity:org.jboss.util.NestedSQLException: No ManagedConnections 
Available!; - nested throwable: (javax.resource.ResourceException: No 
ManagedConnections Available!)
at 
sun.rmi.transport.StreamRemoteCall.exceptionReceivedFromServer(StreamRemoteCall.java:240)
at sun.rmi.transport.StreamRemoteCall.executeCall(StreamRemoteCall.java:215)
at sun.rmi.server.UnicastRef.invoke(UnicastRef.java:117)
at org.jboss.invocation.jrmp.server.JRMPInvoker_Stub.invoke(Unknown Source)
at 
org.jboss.invocation.jrmp.interfaces.JRMPInvokerProxy.invoke(JRMPInvokerProxy.java:128)
at org.jboss.invocation.InvokerInterceptor.invoke(InvokerInterceptor.java:108)
at 
org.jboss.proxy.TransactionInterceptor.invoke(TransactionInterceptor.java:73)
at org.jboss.proxy.SecurityInterceptor.invoke(SecurityInterceptor.java:76)
at org.jboss.proxy.ejb.HomeInterceptor.invoke(HomeInterceptor.java:185)
at org.jboss.proxy.ClientContainer.invoke(ClientContainer.java:76)
at $Proxy6.create(Unknown Source)
at 
net4nuts.usermanagement.UserManagementServlet.processUserData(UserManagementServlet.java:330)
at 
net4nuts.usermanagement.UserManagementServlet.authenticate(UserManagementServlet.java:175)
at 
net4nuts.usermanagement.UserManagementServlet.doPost(UserManagementServlet.java:95)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:760)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
at org.apache.tomcat.core.ServletWrapper.doService(ServletWrapper.java:405)
at org.apache.tomcat.core.Handler.service(Handler.java:287)
at org.apache.tomcat.core.ServletWrapper.service(ServletWrapper.java:372)
at 
org.apache.tomcat.core.ContextManager.internalService(ContextManager.java:806)
at org.apache.tomcat.core.ContextManager.service(ContextManager.java:752)
at 
org.apache.tomcat.service.connector.Ajp12ConnectionHandler.processConnection(Ajp12ConnectionHandler.java:166)
at org.apache.tomcat.service.TcpWorkerThread.runIt(PoolTcpEndpoint.java:416)
at org.apache.tomcat.util.ThreadPool$ControlRunnable.run(ThreadPool.java:501)
at java.lang.Thread.run(Thread.java:479)

Second request again goes to same nodeI mean the node which is getting 
exception.So please elaborate on this ASAP

thanks
vishal


---
This sf.net email is sponsored by: See the NEW Palm
Tungsten T handheld. Power  Color in a compact size!
http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development



RE: [JBoss-dev] JBoss Clustering problem

2002-11-06 Thread Bill Burke
Only communication exceptions will cause a failover.  If the client proxies
know that the request was delivered, the clustering code will never
failover.  This is to avoid duplicate invocations and also the client
proxies really have no way of knowing what you want to do with a request.

 -Original Message-
 From: [EMAIL PROTECTED]
 [mailto:jboss-development-admin;lists.sourceforge.net]On Behalf Of
 Vishal Shukla
 Sent: Thursday, November 07, 2002 1:14 AM
 To: [EMAIL PROTECTED]
 Subject: [JBoss-dev] JBoss Clustering problem


 Hello,

 I am facing problem in JBoss Clustering.I am having Two nodes in
 cluster.When One node is down.Client Automatically send request
 to other node.But if any node is getting the  exception like..

  Could not create entity:org.jboss.util.NestedSQLException: No
 ManagedConnections Available!; - nested throwable:
 (javax.resource.ResourceException: No ManagedConnections Available!)
 at
 sun.rmi.transport.StreamRemoteCall.exceptionReceivedFromServer(Str
 eamRemoteCall.java:240)
 at
 sun.rmi.transport.StreamRemoteCall.executeCall(StreamRemoteCall.java:215)
 at sun.rmi.server.UnicastRef.invoke(UnicastRef.java:117)
 at
 org.jboss.invocation.jrmp.server.JRMPInvoker_Stub.invoke(Unknown Source)
 at
 org.jboss.invocation.jrmp.interfaces.JRMPInvokerProxy.invoke(JRMPI
 nvokerProxy.java:128)
 at
 org.jboss.invocation.InvokerInterceptor.invoke(InvokerInterceptor.
 java:108)
 at
 org.jboss.proxy.TransactionInterceptor.invoke(TransactionIntercept
 or.java:73)
 at
 org.jboss.proxy.SecurityInterceptor.invoke(SecurityInterceptor.java:76)
 at
 org.jboss.proxy.ejb.HomeInterceptor.invoke(HomeInterceptor.java:185)
 at org.jboss.proxy.ClientContainer.invoke(ClientContainer.java:76)
 at $Proxy6.create(Unknown Source)
 at
 net4nuts.usermanagement.UserManagementServlet.processUserData(User
 ManagementServlet.java:330)
 at
 net4nuts.usermanagement.UserManagementServlet.authenticate(UserMan
 agementServlet.java:175)
 at
 net4nuts.usermanagement.UserManagementServlet.doPost(UserManagemen
 tServlet.java:95)
 at javax.servlet.http.HttpServlet.service(HttpServlet.java:760)
 at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
 at
 org.apache.tomcat.core.ServletWrapper.doService(ServletWrapper.java:405)
 at org.apache.tomcat.core.Handler.service(Handler.java:287)
 at
 org.apache.tomcat.core.ServletWrapper.service(ServletWrapper.java:372)
 at
 org.apache.tomcat.core.ContextManager.internalService(ContextManag
 er.java:806)
 at
 org.apache.tomcat.core.ContextManager.service(ContextManager.java:752)
 at
 org.apache.tomcat.service.connector.Ajp12ConnectionHandler.process
 Connection(Ajp12ConnectionHandler.java:166)
 at
 org.apache.tomcat.service.TcpWorkerThread.runIt(PoolTcpEndpoint.java:416)
 at
 org.apache.tomcat.util.ThreadPool$ControlRunnable.run(ThreadPool.java:501)
 at java.lang.Thread.run(Thread.java:479)

 Second request again goes to same nodeI mean the node which
 is getting exception.So please elaborate on this ASAP

 thanks
 vishal


 ---
 This sf.net email is sponsored by: See the NEW Palm
 Tungsten T handheld. Power  Color in a compact size!
 http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en
 ___
 Jboss-development mailing list
 [EMAIL PROTECTED]
 https://lists.sourceforge.net/lists/listinfo/jboss-development



---
This sf.net email is sponsored by: See the NEW Palm 
Tungsten T handheld. Power  Color in a compact size!
http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development