[JBoss-dev] [ jboss-Bugs-634910 ] arbitrary Exception: iterator of a CMR..
Bugs item #634910, was opened at 2002-11-07 13:03
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=376685&aid=634910&group_id=22866
Category: JBossCMP
Group: v3.0 Rabbit Hole
Status: Open
Resolution: None
Priority: 5
Submitted By: Alexei Yudichev (sflexus)
Assigned to: Nobody/Anonymous (nobody)
Summary: arbitrary Exception: iterator of a CMR..
Initial Comment:
Jboss 3.0.4, CMP2.0 bean, simple business method is called by
remote client. Method declaration is:
public String
getSizeAsString(Locale locale) {
try {
int size = 0;
316:
for (Iterator i = getSlides().iterator(); i.hasNext(); )
{
size+=((Slide)i.next()).getSize();
}
size+=getXml(false,
false, -1, locale).toString().getBytes("UTF-8").length;
return
new
DecimalFormat("0.00").format((double)size/1024D);
}catch
(UnsupportedEncodingException ex) {
throw new
EJBException(ex);
}
}
>From time to time (not every
time, approx one time for 20 invocations) I get the exception below.
All transaction attributes for all beans in application declared
as:
SMIL
*
Required
Looks pretty
much like a bug with instable reproduce. I cannot provide a
testcase as well because it happens rarely. What can be the
cause? Can I help somehow else?
2002-11-05
17:54:20,987 ERROR [org.jboss.ejb.plugins.LogInterceptor]
RuntimeException:
java.lang.IllegalStateException: The
iterator of a CMR collection may only be used within the transction
in which it was created
at
org.jboss.ejb.plugins.cmp.jdbc.bridge.RelationSet$1.verifyIteratorIsValid(RelationSet.java:309)
at
org.jboss.ejb.plugins.cmp.jdbc.bridge.RelationSet$1.hasNext(RelationSet.java:269)
at
com.tw.mms.ejb.SMILBean.getSizeAsString(SMILBean.java:316)
at
sun.reflect.GeneratedMethodAccessor75.invoke(Unknown
Source)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at
java.lang.reflect.Method.invoke(Method.java:324)
at
org.jboss.ejb.EntityContainer$ContainerInterceptor.invoke(EntityContainer.java:1194)
at
org.jboss.ejb.plugins.cmp.jdbc.JDBCRelationInterceptor.invoke(JDBCRelationInterceptor.java:95)
at
org.jboss.ejb.plugins.EntitySynchronizationInterceptor.invoke(EntitySynchronizationInterceptor.java:297)
at
org.jboss.resource.connectionmanager.CachedConnectionInterceptor.invoke(CachedConnectionInterceptor.java:186)
at
org.jboss.ejb.plugins.EntityReentranceInterceptor.invoke(EntityReentranceInterceptor.java:90)
at
org.jboss.ejb.plugins.EntityInstanceInterceptor.invoke(EntityInstanceInterceptor.java:163)
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
org.jboss.ejb.plugins.TxInterceptorCMT.runWithTransactions(TxInterceptorCMT.java:178)
at
org.jboss.ejb.plugins.TxInterceptorCMT.invoke(TxInterceptorCMT.java:60)
at
org.jboss.ejb.plugins.SecurityInterceptor.invoke(SecurityInterceptor.java:130)
at
org.jboss.ejb.plugins.LogInterceptor.invoke(LogInterceptor.java:204)
at
org.jboss.ejb.EntityContainer.invoke(EntityContainer.java:493)
at
org.jboss.ejb.Container.invoke(Container.java:712)
at
org.jboss.ejb.EntityContainer.invoke(EntityContainer.java:1058)
at
org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:517)
at
org.jboss.invocation.jrmp.server.JRMPInvoker.invoke(JRMPInvoker.java:382)
at
sun.reflect.GeneratedMethodAccessor59.invoke(Unknown
Source)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at
java.lang.reflect.Method.invoke(Method.java:324)
at
sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:261)
at
sun.rmi.transport.Transport$1.run(Transport.java:148)
at
java.security.AccessController.doPrivileged(Native
Method)
at
sun.rmi.transport.Transport.serviceCall(Transport.java:144)
at
sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:460)
at
sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:701)
at
java.lang.Thread.run(Thread.java:536)
--
>Comment By: Alexei Yudichev (sflexus)
Date: 2002-11-11 09:34
Message:
Logged In: YES
user_id=345880
Today I saw exception of this kind at the point where it never happened
before. Something is really wrong with RelationSet transaction check. It
cannot be in a different transaction when I directly invoke new
ArrayList(getSlides()) where getSlides() is a cmr getter.
In the
stacktace getXml() and getOrderedSlideList() are private bean
methods.
BTW I overcame the problem I described in the original
comment (at least it never happened since I did that) simply by invoking
new ArrayList(getSlides()).iterator() instead of getSlides().iterator()
by this bypassing direct iterator() call on CMR collection.
Here's
the new exception:
2002-11-09 18:11:49,993 ERROR
[org.jbos
[JBoss-dev] [AUTOMATED] (HEAD) JBoss compilation failed
= ==THIS IS AN AUTOMATED EMAIL - SEE http://www.lubega.com FOR DETAILS= = JAVA VERSION DETAILS java version "1.4.1_01" Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.1_01-b01) Java HotSpot(TM) Client VM (build 1.4.1_01-b01, mixed mode) = HERE ARE THE LAST 50 LINES OF THE LOG FILE symbol : class ManagedAspectFactoryMBean location: class org.jboss.aspect.jmx.ManagedAspectFactory public class ManagedAspectFactory extends JMXRegistered implements ManagedAspectFactoryMBean ^ /disk/orig/home/lubega/jbossro/jboss-all/server/src/main/org/jboss/ejb/EnterpriseContext.java:11: warning: java.security.Identity in java.security has been deprecated import java.security.Identity; ^ /disk/orig/home/lubega/jbossro/jboss-all/server/src/main/org/jboss/ejb/EnterpriseContext.java:243: warning: java.security.Identity in java.security has been deprecated public Identity getCallerIdentity() ^ /disk/orig/home/lubega/jbossro/jboss-all/server/src/main/org/jboss/ejb/EnterpriseContext.java:369: warning: java.security.Identity in java.security has been deprecated public boolean isCallerInRole(Identity id) ^ /disk/orig/home/lubega/jbossro/jboss-all/server/src/main/org/jboss/invocation/http/interfaces/AnyhostVerifier.java:10: warning: com.sun.net.ssl.HostnameVerifier in com.sun.net.ssl has been deprecated import com.sun.net.ssl.HostnameVerifier; ^ /disk/orig/home/lubega/jbossro/jboss-all/server/src/main/org/jboss/invocation/http/interfaces/AnyhostVerifier.java:20: warning: com.sun.net.ssl.HostnameVerifier in com.sun.net.ssl has been deprecated public class AnyhostVerifier implements HostnameVerifier ^ /disk/orig/home/lubega/jbossro/jboss-all/server/src/main/org/jboss/security/SecurityDomain.java:12: warning: com.sun.net.ssl.KeyManagerFactory in com.sun.net.ssl has been deprecated import com.sun.net.ssl.KeyManagerFactory; ^ /disk/orig/home/lubega/jbossro/jboss-all/server/src/main/org/jboss/security/SecurityDomain.java:13: warning: com.sun.net.ssl.TrustManagerFactory in com.sun.net.ssl has been deprecated import com.sun.net.ssl.TrustManagerFactory; ^ /disk/orig/home/lubega/jbossro/jboss-all/server/src/main/org/jboss/security/SecurityDomain.java:32: warning: com.sun.net.ssl.KeyManagerFactory in com.sun.net.ssl has been deprecated public KeyManagerFactory getKeyManagerFactory() throws SecurityException; ^ /disk/orig/home/lubega/jbossro/jboss-all/server/src/main/org/jboss/security/SecurityDomain.java:38: warning: com.sun.net.ssl.TrustManagerFactory in com.sun.net.ssl has been deprecated public TrustManagerFactory getTrustManagerFactory() throws SecurityException; ^ /disk/orig/home/lubega/jbossro/jboss-all/server/src/main/org/jboss/ejb/EnterpriseContext.java:369: warning: java.security.Identity in java.security has been deprecated public boolean isCallerInRole(Identity id) ^ /disk/orig/home/lubega/jbossro/jboss-all/server/src/main/org/jboss/invocation/http/interfaces/Util.java:63: warning: com.sun.net.ssl.HttpsURLConnection in com.sun.net.ssl has been deprecated if( conn instanceof com.sun.net.ssl.HttpsURLConnection ) ^ /disk/orig/home/lubega/jbossro/jboss-all/server/src/main/org/jboss/invocation/http/interfaces/Util.java:68: warning: com.sun.net.ssl.HttpsURLConnection in com.sun.net.ssl has been deprecated com.sun.net.ssl.HttpsURLConnection sconn = (com.sun.net.ssl.HttpsURLConnection) conn; ^ /disk/orig/home/lubega/jbossro/jboss-all/server/src/main/org/jboss/invocation/http/interfaces/Util.java:68: warning: com.sun.net.ssl.HttpsURLConnection in com.sun.net.ssl has been deprecated com.sun.net.ssl.HttpsURLConnection sconn = (com.sun.net.ssl.HttpsURLConnection) conn; ^ 2 errors 13 warnings BUILD FAILED file:/disk/orig/home/lubega/jbossro/jboss-all/server/build.xml:277: Compile failed; see the compiler error output for details. Total time: 2 minutes 56 seconds --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] JMX on the client side?
On Mon, 2002-11-11 at 07:13, Dain Sundstrom wrote: > Hiram Chirino wrote: > >>Hiram, I think you missed the point. Of course we could do this with > >>out requiring JMX; anything is possible. The point is if we agree that > >>JMX is always on the client side then entire system is simplified. > > > > I guess the disconnect is happening right here. IMO JMX does not always > > make things easier. What do you think JMX provides that would simplify "the > > entire system"? Is it: > > (1) Runtime server administration > > (2) Service creation/configuration/lookup. > > > > Even though those are super important on the server side, I just don't see > > how important those would be on the client side. Am I missing something > > else? > > Yes. The microkernel, but more importantly only one system to > understand. The reuse is huge, and not just code reuse; we get reuse of > understanding and design. > > As for specifics on what I think is most important about JMS, I would > say detyped invocation, lifecycle management and lookup. The management > stuff is useful too ;) Without even understanding, what the specifics of detyped invocation, .. are, I _can_ say, that using the microkernel on the client side is the way to go. It's aspect oriented programming, what the EJB spec is all about (although most people seem to ignore it). Only the notation of aspects isn't as smooth as can get yet. We need services, we need containers, we need interceptors and we need aspects everywhere. BTW: jboss architecture must support calls between different jboss jvms with proper transaction handling anyway. So beside an application-client deployer, the requirements of a jboss client are a subset of the requirements of the server. just my 2 cents, Holger --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-537152 ] MAPPING Configuration error for request
Bugs item #537152, was opened at 2002-03-31 02:10 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=537152&group_id=22866 Category: CatalinaBundle Group: v3.0 Rabbit Hole Status: Closed Resolution: Duplicate Priority: 8 Submitted By: Pravin Pillai (pravinp2000) Assigned to: Scott M Stark (starksm) Summary: MAPPING Configuration error for request Initial Comment: Windows 2000 JDK1.3 Unpacked deployment doesn't work in JBoss3.0-Tomcat4.0. Steps to reproduce: 1) Create a directory called ".war" or "ROOT.war". 2) Add a file called index.html 3) Add a sub-directory called WEB-INF 4) In WEB-INF create a web.xml with the following content http://java.sun.com/dtd/web- app_2_3.dtd"> 5) Copy the directory to jboss/deploy 6) Use http://localhost:8080/ -- Comment By: Eusoon Ong (eusoon) Date: 2002-11-11 14:44 Message: Logged In: YES user_id=608175 The above problem can be avoid if the java classes is seperated from the war file, and compile as a seperate jar file, to be use as a lib for the web application -- Comment By: Juan Garcia (jcgg2002) Date: 2002-05-12 01:53 Message: Logged In: YES user_id=541887 What happened to this defect? was it ever fixed? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=537152&group_id=22866 --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] JMX on the client side?
Ok.. i buy into that. I think running a JMX server on the client side should be a piece of cake. The hard part is figuring out how the client-side deployment system going to work. > -Original Message- > From: [EMAIL PROTECTED] > [mailto:jboss-development-admin@;lists.sourceforge.net]On Behalf Of David > Jencks > Sent: Monday, November 11, 2002 12:45 AM > To: [EMAIL PROTECTED] > Subject: Re: [JBoss-dev] JMX on the client side? > > > Let me give you my example of why I want it. > > I worked over the trunk invoker so it would do distributed transactions. > This requires at least a source of xid's on the calling side, and > preferably a TransactionManager. Well, they are already there if the > calling side is a jboss instance. If it's a client, the only way you will > be propagating a transaction is if you have a UserTransaction. So, I'd > like to implement the client-side UserTransaction to use the same > mechanism, based on at least an XidFactory and perhaps a > TransactionManager. These are pretty much dependent on the jmx > framework. > If the jmx framework is on the client, I just register the mbeans and I'm > done. If not, I have to rewrite a bunch of the code to be independent of > the jmx framework. Incidently, I think the client end of the > trunk invoker > would also be simpler if it were an mbean: in fact I think there > could be a > lot more code sharing between the two ends. > > david jencks > --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] JMX on the client side?
Hiram Chirino wrote: Hiram, I think you missed the point. Of course we could do this with out requiring JMX; anything is possible. The point is if we agree that JMX is always on the client side then entire system is simplified. I guess the disconnect is happening right here. IMO JMX does not always make things easier. What do you think JMX provides that would simplify "the entire system"? Is it: (1) Runtime server administration (2) Service creation/configuration/lookup. Even though those are super important on the server side, I just don't see how important those would be on the client side. Am I missing something else? Yes. The microkernel, but more importantly only one system to understand. The reuse is huge, and not just code reuse; we get reuse of understanding and design. As for specifics on what I think is most important about JMS, I would say detyped invocation, lifecycle management and lookup. The management stuff is useful too ;) -dain --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] JMX on the client side?
Let me give you my example of why I want it. I worked over the trunk invoker so it would do distributed transactions. This requires at least a source of xid's on the calling side, and preferably a TransactionManager. Well, they are already there if the calling side is a jboss instance. If it's a client, the only way you will be propagating a transaction is if you have a UserTransaction. So, I'd like to implement the client-side UserTransaction to use the same mechanism, based on at least an XidFactory and perhaps a TransactionManager. These are pretty much dependent on the jmx framework. If the jmx framework is on the client, I just register the mbeans and I'm done. If not, I have to rewrite a bunch of the code to be independent of the jmx framework. Incidently, I think the client end of the trunk invoker would also be simpler if it were an mbean: in fact I think there could be a lot more code sharing between the two ends. david jencks On 2002.11.10 23:25:50 -0500 Hiram Chirino wrote: > > > > Hiram, I think you missed the point. Of course we could do this with > > out requiring JMX; anything is possible. The point is if we agree that > > JMX is always on the client side then entire system is simplified. > > > > I guess the disconnect is happening right here. IMO JMX does not always > make things easier. What do you think JMX provides that would simplify > "the > entire system"? Is it: > (1) Runtime server administration > (2) Service creation/configuration/lookup. > > Even though those are super important on the server side, I just don't > see > how important those would be on the client side. Am I missing something > else? > > Regards, > Hiram > > > > --- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > ___ > Jboss-development mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-development > > --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] JMX on the client side?
> > Hiram, I think you missed the point. Of course we could do this with > out requiring JMX; anything is possible. The point is if we agree that > JMX is always on the client side then entire system is simplified. > I guess the disconnect is happening right here. IMO JMX does not always make things easier. What do you think JMX provides that would simplify "the entire system"? Is it: (1) Runtime server administration (2) Service creation/configuration/lookup. Even though those are super important on the server side, I just don't see how important those would be on the client side. Am I missing something else? Regards, Hiram --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] JMX on the client side?
Hiram Chirino wrote: What I would like to know, is: what are the features that JMX provides that you need on the client side?? (1) Is it the interceptor architecture built around JMX? (2) Is it the ability to look up other services via JMX? I want to know because I think that we can provide client side container without having to use JMX. I think that stuff will actually get simpler if we do not FORCE jmx on the client side. Our Aspect API is all about that. It's about providing at least #1 in a clean generic fashion. But for it successfully use for client side containers, I need to understand what all the requirements will be. Bill, I know you started doing some work on client side interceptors using the aspect stuff. What JMX features were you wishing you had on the client side?? Hiram, I think you missed the point. Of course we could do this with out requiring JMX; anything is possible. The point is if we agree that JMX is always on the client side then entire system is simplified. In the end it is a trade off between a simpler and easier to understand code for the very small overhead of JMX (I bet is is under 1k in memory). -dain --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] J2EE Timer Service
Hi Jason Quartz is something similar than our Scheduler but with the focus on Enterprise-ready timers whereas the Scheduler was only designed to serve as JBoss utility. But the J2EE timer service needs to be incorporated into JBoss like MDB invocation when a message arrives. I will create a embedded timer like Web-containers so that users can plug-in any timer service they like. So a user can use Quartz if they like to. Andy - Original Message - From: "Jason Dillon" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Sunday, November 10, 2002 12:33 PM Subject: Re: [JBoss-dev] J2EE Timer Service > What about Quartz? Lets integrate instead of invent where we can. > > --jason > > > > what do you guys think of a new scheduler? > > marc f > > > -Original Message- > > From: Ben Sabrin [mailto:ben@;jboss.org] > > Sent: Monday, November 04, 2002 3:58 AM > > To: Marc Fleury > > Subject: FW: Quartz J2EE Scheduler > > > > for your consumption. > > > Ben Sabrin > > Director of Sales and Business Development > > JBoss Group, LLC > > > > -Original Message- > > From: Nathan Phelps [mailto:nphelps@;solarc.com] > > Sent: Wednesday, October 30, 2002 9:20 PM > > To: 'Ben Sabrin' > > Subject: Quartz J2EE Scheduler > > > > Here is the link to the Scheduler I was talking about today: > > http://quartz.sourceforge.net > > > Again, thanks for your visit. > > I've already gotten feedback about how much everyone enjoyed it. > > > Thanks, > > > Nathan > > > > > On Sunday, November 10, 2002, at 11:15 AM, Scott M Stark wrote: > > > I have not seen anyone mention this so go ahead. > > > > > > Scott Stark > > Chief Technology Officer > > JBoss Group, LLC > > > > > > - Original Message - > > From: "Andy" <[EMAIL PROTECTED]> > > To: <[EMAIL PROTECTED]> > > Sent: Sunday, November 10, 2002 10:18 AM > > Subject: [JBoss-dev] J2EE Timer Service > > > > > >> Hi Geeks > >> > >> Did anyone started to develop the EJB 2.1 Timer Service ? > >> > >> Otherwise I will have a look into it because I think we could > >> use the Scheduler. > >> > >> Have fun - Andy > > > > > > > > --- > > This sf.net email is sponsored by:ThinkGeek > > Welcome to geek heaven. > > http://thinkgeek.com/sf > > ___ > > Jboss-development mailing list > > [EMAIL PROTECTED] > > https://lists.sourceforge.net/lists/listinfo/jboss-development > > > > --- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > ___ > Jboss-development mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-development > --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Change Notes-636418 ] JBossMQ MessageCache changes
Change Notes item #636418, was opened at 2002-11-11 01:00 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=381174&aid=636418&group_id=22866 Category: JBossMQ Group: v4.0 Status: Open Priority: 5 Submitted By: Adrian Brock (ejort) Assigned to: Nobody/Anonymous (nobody) Summary: JBossMQ MessageCache changes Initial Comment: Applies to 4.0 only for now. The global locking on the MessageCache is gone. Locks are now on the message and the LRUCache when required. Softening is now done by the softening thread, except addMessage which will soften one message when required to make room for the new message. Some fixes to the message cache processing under stress, mostly for the joint CacheStore/PersistenceManager jdbc2. Some fixes for jdbc2. Including changes to the SQL in jbossmq-service.xml to correct the recovery process. Added an update operation to the persistence managers so that the redelivered flag is persisted across server reboots. Removed the linear traversal of unacknowledgedMessages in BasicQueue, Rollback the message cache entry when an addMessage transaction fails. Fixed problems with rollingback when a transaction timeout interrupts the thread for jdbc2. Fixed the testsuite to clear undelivered messages and remove durable subscriptions, making it easier to spot a message cache leak in future. Regards, Adrian -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=381174&aid=636418&group_id=22866 --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-604085 ] Jetty is not deploying packed wars
Bugs item #604085, was opened at 2002-09-03 18:34 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=604085&group_id=22866 Category: JBossServer Group: v3.0 Rabbit Hole Status: Closed Resolution: Fixed Priority: 5 Submitted By: Scott M Stark (starksm) Assigned to: Nobody/Anonymous (nobody) Summary: Jetty is not deploying packed wars Initial Comment: I am seeing a problem with Jetty not deploying wars from the deploy directory in the current 3.0 and 3.2 branches. If you take the default/deploy/jmx-console.war and repack this: deploy 414>ls -l jmx-console.war -rw-r--r--1 starksm None58165 Sep 3 13:17 jmx-console.war deploy 415>jar -tf jmx-console.war META-INF/ META-INF/MANIFEST.MF WEB-INF/ WEB-INF/classes/ WEB-INF/classes/org/ WEB-INF/classes/org/jboss/ WEB-INF/classes/org/jboss/jmx/ WEB-INF/classes/org/jboss/jmx/adaptor/ WEB-INF/classes/org/jboss/jmx/adaptor/control/ WEB- INF/classes/org/jboss/jmx/adaptor/control/AttrResultInfo. class WEB- INF/classes/org/jboss/jmx/adaptor/control/OpResultInfo. class WEB- INF/classes/org/jboss/jmx/adaptor/control/Server.class WEB-INF/classes/org/jboss/jmx/adaptor/html/ WEB- INF/classes/org/jboss/jmx/adaptor/html/HtmlAdaptorServ let.class WEB-INF/classes/org/jboss/jmx/adaptor/model/ WEB- INF/classes/org/jboss/jmx/adaptor/model/DomainData.cl ass WEB- INF/classes/org/jboss/jmx/adaptor/model/MBeanData.cl ass WEB-INF/classes/roles.properties WEB-INF/classes/users.properties WEB-INF/web.xml displayMBeans.jsp displayOpResult.jsp images/ images/head_blue.gif index.jsp inspectMBean.jsp style_master.css Startup the default config and although Jetty says the war was deployed: 13:18:20,769 INFO [MainDeployer] Starting deployment of package: file:/C:/usr/J Boss3.2/jboss-all/build/output/jboss- 3.2.0RC1/server/default/deploy/jmx-console. war 13:18:21,340 INFO [jbossweb] Registered jboss.web:Jetty=0,JBossWebApplicationCo ntext=0,context=/jmx-console 13:18:21,390 INFO [jbossweb] Checking Resource aliases 13:18:21,490 INFO [jbossweb] Extract jar:file:/C:/usr/JBoss3.2/jboss-all/build/ output/jboss- 3.2.0RC1/server/default/tmp/deploy/server/default/deploy/ jmx-consol e.war/61.jmx-console.war!/ to C:\DOCUME~1 \starksm\LOCALS~1\Temp\Jetty_0_0_0_0_80 80__jmx-console\webapp 13:18:22,312 INFO [jbossweb] Started WebApplicationContext[/jmx-console,jar:fil e:/C:/usr/JBoss3.2/jboss-all/build/output/jboss- 3.2.0RC1/server/default/tmp/depl oy/server/default/deploy/jmx-console.war/61.jmx- console.war!/] 13:18:22,392 INFO [jbossweb] successfully deployed file:/C:/usr/JBoss3.2/jboss- all/build/output/jboss- 3.2.0RC1/server/default/tmp/deploy/server/default/deploy/ jmx-console.war/61.jmx-console.war to /jmx-console 13:18:22,392 INFO [MainDeployer] Deployed package: file:/C:/usr/JBoss3.2/jboss- all/build/output/jboss-3.2.0RC1/server/default/deploy/jmx- console.war 13:18:22,402 INFO [URLDeploymentScanner] Started It is in fact not accessible: security 409>wget http://localhost:8080/jmx-console --13:21:08-- http://localhost:8080/jmx-console => `jmx-console' Resolving localhost... done. Connecting to localhost[127.0.0.1]:8080... connected. HTTP request sent, awaiting response... 302 Moved Temporarily Location: http://localhost:8080/jmx-console/ [following] --13:21:08-- http://localhost:8080/jmx-console/ => `index.html' Connecting to localhost[127.0.0.1]:8080... connected. HTTP request sent, awaiting response... 404 /jmx- console/ Not Found 13:21:08 ERROR 404: /jmx-console/ Not Found. If the jmx-console.war is unpacked then the content is accessible: security 410>wget http://localhost:8080/jmx-console --13:25:25-- http://localhost:8080/jmx-console => `jmx-console' Resolving localhost... done. Connecting to localhost[127.0.0.1]:8080... connected. HTTP request sent, awaiting response... 302 Moved Temporarily Location: http://localhost:8080/jmx-console/ [following] --13:25:25-- http://localhost:8080/jmx-console/ => `index.html' Connecting to localhost[127.0.0.1]:8080... connected. HTTP request sent, awaiting response... 200 OK Length: unspecified [text/html] [ <=> ] 46,675 735.18K/s 13:25:30 (735.18 KB/s) - `index.html' saved [46675] These messages are for the current 3.2 build. The 3.0 build actually displays an info message with a "Internal Error..." msg during deployment of the war: 12:57:23,161 INFO [MainDeployer] Starting deployment of package: file:/C:/usr/S akonnet/jboss-3.0.3RC1/server/default/deploy/jmx- console.war 12:57:23,442 INFO [jbossweb] Registered jboss.web:Jetty=0,JBossWebApplicationCo ntext=1,context=/jmx-console 12:57:23,472 INFO [jbossweb] Extract jar:file:/C:/usr/Sakonnet/jboss-3.0.3RC1/s erver/default/tmp/deploy/server/default/deploy/jmx- console.war/61.jmx-console.wa r!/ to C:\DOCUME~1\starksm\LOCALS~1 \Temp\Jetty_0_0_0_0_8080__jmx-console\webapp 12:57:23,942 INFO [jbossweb] Started WebApplicationContext[
[JBoss-dev] [ jboss-Bugs-604085 ] Jetty is not deploying packed wars
Bugs item #604085, was opened at 2002-09-03 18:34 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=604085&group_id=22866 Category: JBossServer Group: v3.0 Rabbit Hole Status: Closed Resolution: Fixed Priority: 5 Submitted By: Scott M Stark (starksm) Assigned to: Nobody/Anonymous (nobody) Summary: Jetty is not deploying packed wars Initial Comment: I am seeing a problem with Jetty not deploying wars from the deploy directory in the current 3.0 and 3.2 branches. If you take the default/deploy/jmx-console.war and repack this: deploy 414>ls -l jmx-console.war -rw-r--r--1 starksm None58165 Sep 3 13:17 jmx-console.war deploy 415>jar -tf jmx-console.war META-INF/ META-INF/MANIFEST.MF WEB-INF/ WEB-INF/classes/ WEB-INF/classes/org/ WEB-INF/classes/org/jboss/ WEB-INF/classes/org/jboss/jmx/ WEB-INF/classes/org/jboss/jmx/adaptor/ WEB-INF/classes/org/jboss/jmx/adaptor/control/ WEB- INF/classes/org/jboss/jmx/adaptor/control/AttrResultInfo. class WEB- INF/classes/org/jboss/jmx/adaptor/control/OpResultInfo. class WEB- INF/classes/org/jboss/jmx/adaptor/control/Server.class WEB-INF/classes/org/jboss/jmx/adaptor/html/ WEB- INF/classes/org/jboss/jmx/adaptor/html/HtmlAdaptorServ let.class WEB-INF/classes/org/jboss/jmx/adaptor/model/ WEB- INF/classes/org/jboss/jmx/adaptor/model/DomainData.cl ass WEB- INF/classes/org/jboss/jmx/adaptor/model/MBeanData.cl ass WEB-INF/classes/roles.properties WEB-INF/classes/users.properties WEB-INF/web.xml displayMBeans.jsp displayOpResult.jsp images/ images/head_blue.gif index.jsp inspectMBean.jsp style_master.css Startup the default config and although Jetty says the war was deployed: 13:18:20,769 INFO [MainDeployer] Starting deployment of package: file:/C:/usr/J Boss3.2/jboss-all/build/output/jboss- 3.2.0RC1/server/default/deploy/jmx-console. war 13:18:21,340 INFO [jbossweb] Registered jboss.web:Jetty=0,JBossWebApplicationCo ntext=0,context=/jmx-console 13:18:21,390 INFO [jbossweb] Checking Resource aliases 13:18:21,490 INFO [jbossweb] Extract jar:file:/C:/usr/JBoss3.2/jboss-all/build/ output/jboss- 3.2.0RC1/server/default/tmp/deploy/server/default/deploy/ jmx-consol e.war/61.jmx-console.war!/ to C:\DOCUME~1 \starksm\LOCALS~1\Temp\Jetty_0_0_0_0_80 80__jmx-console\webapp 13:18:22,312 INFO [jbossweb] Started WebApplicationContext[/jmx-console,jar:fil e:/C:/usr/JBoss3.2/jboss-all/build/output/jboss- 3.2.0RC1/server/default/tmp/depl oy/server/default/deploy/jmx-console.war/61.jmx- console.war!/] 13:18:22,392 INFO [jbossweb] successfully deployed file:/C:/usr/JBoss3.2/jboss- all/build/output/jboss- 3.2.0RC1/server/default/tmp/deploy/server/default/deploy/ jmx-console.war/61.jmx-console.war to /jmx-console 13:18:22,392 INFO [MainDeployer] Deployed package: file:/C:/usr/JBoss3.2/jboss- all/build/output/jboss-3.2.0RC1/server/default/deploy/jmx- console.war 13:18:22,402 INFO [URLDeploymentScanner] Started It is in fact not accessible: security 409>wget http://localhost:8080/jmx-console --13:21:08-- http://localhost:8080/jmx-console => `jmx-console' Resolving localhost... done. Connecting to localhost[127.0.0.1]:8080... connected. HTTP request sent, awaiting response... 302 Moved Temporarily Location: http://localhost:8080/jmx-console/ [following] --13:21:08-- http://localhost:8080/jmx-console/ => `index.html' Connecting to localhost[127.0.0.1]:8080... connected. HTTP request sent, awaiting response... 404 /jmx- console/ Not Found 13:21:08 ERROR 404: /jmx-console/ Not Found. If the jmx-console.war is unpacked then the content is accessible: security 410>wget http://localhost:8080/jmx-console --13:25:25-- http://localhost:8080/jmx-console => `jmx-console' Resolving localhost... done. Connecting to localhost[127.0.0.1]:8080... connected. HTTP request sent, awaiting response... 302 Moved Temporarily Location: http://localhost:8080/jmx-console/ [following] --13:25:25-- http://localhost:8080/jmx-console/ => `index.html' Connecting to localhost[127.0.0.1]:8080... connected. HTTP request sent, awaiting response... 200 OK Length: unspecified [text/html] [ <=> ] 46,675 735.18K/s 13:25:30 (735.18 KB/s) - `index.html' saved [46675] These messages are for the current 3.2 build. The 3.0 build actually displays an info message with a "Internal Error..." msg during deployment of the war: 12:57:23,161 INFO [MainDeployer] Starting deployment of package: file:/C:/usr/S akonnet/jboss-3.0.3RC1/server/default/deploy/jmx- console.war 12:57:23,442 INFO [jbossweb] Registered jboss.web:Jetty=0,JBossWebApplicationCo ntext=1,context=/jmx-console 12:57:23,472 INFO [jbossweb] Extract jar:file:/C:/usr/Sakonnet/jboss-3.0.3RC1/s erver/default/tmp/deploy/server/default/deploy/jmx- console.war/61.jmx-console.wa r!/ to C:\DOCUME~1\starksm\LOCALS~1 \Temp\Jetty_0_0_0_0_8080__jmx-console\webapp 12:57:23,942 INFO [jbossweb] Started WebApplicationContext[
Re: [JBoss-dev] Problem compiling 3.2 beta testsuite
This is fixed. Scott Stark Chief Technology Officer JBoss Group, LLC - Original Message - From: "Juha-P Lindfors" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Sunday, November 10, 2002 1:50 PM Subject: [JBoss-dev] Problem compiling 3.2 beta testsuite > > Can't get 3.2 testsuite to compile due to the errors below > > compile-classes-only: > [javac] Compiling 932 source files to > C:\work\mletpatch\HEAD\jboss3.2beta\testsuite\output\classes > [execmodules] > >C:\work\mletpatch\HEAD\jboss3.2beta\testsuite\src\main\org\jboss\test\jca\ejb\LocalWrapperCleanupTestSessi > onBean.java:23: cannot resolve symbol > [execmodules] symbol : class LocalConnection > [execmodules] location: package local > [execmodules] import > org.jboss.resource.adapter.jdbc.local.LocalConnection; > [execmodules] ^ > [execmodules] > >C:\work\mletpatch\HEAD\jboss3.2beta\testsuite\output\gen-src\org\jboss\test\jca\interfaces\LocalWrapperCle > anupTestSessionHome.java:16: cannot resolve symbol > [execmodules] symbol : class LocalConnection > [execmodules] location: package local > [execmodules] import > org.jboss.resource.adapter.jdbc.local.LocalConnection; > [execmodules] ^ > [execmodules] > >C:\work\mletpatch\HEAD\jboss3.2beta\testsuite\output\gen-src\org\jboss\test\jca\interfaces\LocalWrapperCle > anupTestSession.java:16: cannot resolve symbol > [execmodules] symbol : class LocalConnection > [execmodules] location: package local > [execmodules] import > org.jboss.resource.adapter.jdbc.local.LocalConnection; > [execmodules] ^ > [execmodules] > >C:\work\mletpatch\HEAD\jboss3.2beta\testsuite\src\main\org\jboss\test\jbossmq\stress\ClientFailTest.java:1 > 13: warning: stop() in java.lang.Thread has been deprecated > [execmodules] t.stop(); > [execmodules] ^ > [execmodules] > >C:\work\mletpatch\HEAD\jboss3.2beta\testsuite\src\main\org\jboss\test\jbossmq\stress\DurableSubscriberTest > .java:77: warning: stop() in java.lang.Thread has been deprecated > [execmodules] t1.stop(); > [execmodules]^ > [execmodules] > >C:\work\mletpatch\HEAD\jboss3.2beta\testsuite\src\main\org\jboss\test\jbossmq\stress\DurableSubscriberTest > .java:121: warning: stop() in java.lang.Thread has been deprecated > [execmodules] t2.stop(); > [execmodules]^ > [execmodules] > >C:\work\mletpatch\HEAD\jboss3.2beta\testsuite\src\main\org\jboss\test\jbossmq\stress\DurableSubscriberTest > .java:143: warning: stop() in java.lang.Thread has been deprecated > [execmodules] t1.stop(); > [execmodules] ^ > [execmodules] > >C:\work\mletpatch\HEAD\jboss3.2beta\testsuite\src\main\org\jboss\test\jbossmq\stress\DurableSubscriberTest > .java:161: warning: stop() in java.lang.Thread has been deprecated > [execmodules] t1.stop(); > [execmodules] ^ > [execmodules] > >C:\work\mletpatch\HEAD\jboss3.2beta\testsuite\src\main\org\jboss\test\jbossmq\stress\ExceptionListenerTest > .java:63: warning: stop() in java.lang.Thread has been deprecated > [execmodules] t1.stop(); > [execmodules] ^ > [execmodules] > >C:\work\mletpatch\HEAD\jboss3.2beta\testsuite\src\main\org\jboss\test\jbossmq\stress\MassiveTest.java:75: > warning: stop() in java.lang.Thread has been deprecated > [execmodules] t1.stop(); > [execmodules]^ > [execmodules] > >C:\work\mletpatch\HEAD\jboss3.2beta\testsuite\src\main\org\jboss\test\jbossmq\stress\MassiveTest.java:129: > warning: stop() in java.lang.Thread has been deprecated > [execmodules] t1.stop(); > [execmodules]^ > [execmodules] > >C:\work\mletpatch\HEAD\jboss3.2beta\testsuite\src\main\org\jboss\test\jbossmq\stress\MassiveTest.java:133: > warning: stop() in java.lang.Thread has been deprecated > [execmodules] tf.stop(); > [execmodules]^ > [execmodules] > >C:\work\mletpatch\HEAD\jboss3.2beta\testsuite\src\main\org\jboss\test\jbossmq\stress\MultipleDurableSubscr > ibers.java:111: warning: stop() in java.lang.Thread has been deprecated > [execmodules] t1.stop(); > [execmodules]^ > [execmodules] > >C:\work\mletpatch\HEAD\jboss3.2beta\testsuite\src\main\org\jboss\test\jbossmq\stress\MultipleDurableSubscr > ibers.java:113: warning: stop() in java.lang.Thread has been deprecated > [execmodules] t2.stop(); > [execmodules]^ > [execmodules] > >C:\work\mletpatch\HEAD\jboss3.2beta\testsuite\src\main\org\jboss\test\jbossmq\stress\MultipleDurableSubscr > ibers.java:168: warning: stop() in java.lang.Thread has been deprecated > [execmodules] t1.stop(); > [execmodules]^ > [execmodules] > >C:\work\mletpatch\HEAD\jboss3.2beta\testsuite\src\main\org\jboss\test\jbossmq\stress\MultipleDurableSubscr > ibers.java:170: warning: stop() in java.lang.Thread
[JBoss-dev] [ jboss-Bugs-636227 ] testsuite generally fails to complete
Bugs item #636227, was opened at 2002-11-10 16:05 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=636227&group_id=22866 Category: JBossTest Group: CVS HEAD Status: Open Resolution: None Priority: 5 Submitted By: Chris Kimpton (kimptoc) >Assigned to: Adrian Brock (ejort) Summary: testsuite generally fails to complete Initial Comment: Hi, I have run the full testsuite (testsuite/build.xml, target test) several times but it rarely completes. The machine is doing nothing else - 2 x 1.3GHZ cpu, 1GB ram - left run for 15 hours plus. Redhat 7.2, sun jdk1.3.1_06 Tried using kill -SIGHUP, but it seemed to kill the JVM rathing giving a thread dump. Regards, Chris -- >Comment By: Adrian Brock (ejort) Date: 2002-11-10 23:05 Message: Logged In: YES user_id=9459 Hi Chris, Can you attach testsuite/output/log/test.log from the hanging test. Regards, Adrian -- Comment By: Chris Kimpton (kimptoc) Date: 2002-11-10 22:31 Message: Logged In: YES user_id=39204 Hi, I just tried running the tests-unit target on a freshly checked out set of code and still it hangs... I tried SIGQUIT - on several main java processes - but still did not see any thread dump in the server.log - or does it go to the console log? Thanks, Chris -- Comment By: Scott M Stark (starksm) Date: 2002-11-10 17:05 Message: Logged In: YES user_id=175228 SIGQUIT is the correct signal to use to generate a thread dump. -- Comment By: Adrian Brock (ejort) Date: 2002-11-10 16:42 Message: Logged In: YES user_id=9459 Hi Chris, Can you try it again? I saw a deadlock with OIL yesterday, it was actually a deadlock across two VMs during the connection close. I saw it as a timeout rather than a permenant hang though. I also found a problem where the dead letter queue wasn't being used because of incorrect xml parsing. This led to infinite redelivery of messages to MDBs. I've committed these fixes now. Regards, Adrian -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=636227&group_id=22866 --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-636227 ] testsuite generally fails to complete
Bugs item #636227, was opened at 2002-11-10 16:05 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=636227&group_id=22866 Category: JBossTest Group: CVS HEAD Status: Open Resolution: None Priority: 5 Submitted By: Chris Kimpton (kimptoc) Assigned to: Nobody/Anonymous (nobody) Summary: testsuite generally fails to complete Initial Comment: Hi, I have run the full testsuite (testsuite/build.xml, target test) several times but it rarely completes. The machine is doing nothing else - 2 x 1.3GHZ cpu, 1GB ram - left run for 15 hours plus. Redhat 7.2, sun jdk1.3.1_06 Tried using kill -SIGHUP, but it seemed to kill the JVM rathing giving a thread dump. Regards, Chris -- >Comment By: Chris Kimpton (kimptoc) Date: 2002-11-10 22:31 Message: Logged In: YES user_id=39204 Hi, I just tried running the tests-unit target on a freshly checked out set of code and still it hangs... I tried SIGQUIT - on several main java processes - but still did not see any thread dump in the server.log - or does it go to the console log? Thanks, Chris -- Comment By: Scott M Stark (starksm) Date: 2002-11-10 17:05 Message: Logged In: YES user_id=175228 SIGQUIT is the correct signal to use to generate a thread dump. -- Comment By: Adrian Brock (ejort) Date: 2002-11-10 16:42 Message: Logged In: YES user_id=9459 Hi Chris, Can you try it again? I saw a deadlock with OIL yesterday, it was actually a deadlock across two VMs during the connection close. I saw it as a timeout rather than a permenant hang though. I also found a problem where the dead letter queue wasn't being used because of incorrect xml parsing. This led to infinite redelivery of messages to MDBs. I've committed these fixes now. Regards, Adrian -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=636227&group_id=22866 --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Problem compiling 3.2 beta testsuite
Can't get 3.2 testsuite to compile due to the errors below compile-classes-only: [javac] Compiling 932 source files to C:\work\mletpatch\HEAD\jboss3.2beta\testsuite\output\classes [execmodules] C:\work\mletpatch\HEAD\jboss3.2beta\testsuite\src\main\org\jboss\test\jca\ejb\LocalWrapperCleanupTestSessi onBean.java:23: cannot resolve symbol [execmodules] symbol : class LocalConnection [execmodules] location: package local [execmodules] import org.jboss.resource.adapter.jdbc.local.LocalConnection; [execmodules] ^ [execmodules] C:\work\mletpatch\HEAD\jboss3.2beta\testsuite\output\gen-src\org\jboss\test\jca\interfaces\LocalWrapperCle anupTestSessionHome.java:16: cannot resolve symbol [execmodules] symbol : class LocalConnection [execmodules] location: package local [execmodules] import org.jboss.resource.adapter.jdbc.local.LocalConnection; [execmodules] ^ [execmodules] C:\work\mletpatch\HEAD\jboss3.2beta\testsuite\output\gen-src\org\jboss\test\jca\interfaces\LocalWrapperCle anupTestSession.java:16: cannot resolve symbol [execmodules] symbol : class LocalConnection [execmodules] location: package local [execmodules] import org.jboss.resource.adapter.jdbc.local.LocalConnection; [execmodules] ^ [execmodules] C:\work\mletpatch\HEAD\jboss3.2beta\testsuite\src\main\org\jboss\test\jbossmq\stress\ClientFailTest.java:1 13: warning: stop() in java.lang.Thread has been deprecated [execmodules] t.stop(); [execmodules] ^ [execmodules] C:\work\mletpatch\HEAD\jboss3.2beta\testsuite\src\main\org\jboss\test\jbossmq\stress\DurableSubscriberTest .java:77: warning: stop() in java.lang.Thread has been deprecated [execmodules] t1.stop(); [execmodules]^ [execmodules] C:\work\mletpatch\HEAD\jboss3.2beta\testsuite\src\main\org\jboss\test\jbossmq\stress\DurableSubscriberTest .java:121: warning: stop() in java.lang.Thread has been deprecated [execmodules] t2.stop(); [execmodules]^ [execmodules] C:\work\mletpatch\HEAD\jboss3.2beta\testsuite\src\main\org\jboss\test\jbossmq\stress\DurableSubscriberTest .java:143: warning: stop() in java.lang.Thread has been deprecated [execmodules] t1.stop(); [execmodules] ^ [execmodules] C:\work\mletpatch\HEAD\jboss3.2beta\testsuite\src\main\org\jboss\test\jbossmq\stress\DurableSubscriberTest .java:161: warning: stop() in java.lang.Thread has been deprecated [execmodules] t1.stop(); [execmodules] ^ [execmodules] C:\work\mletpatch\HEAD\jboss3.2beta\testsuite\src\main\org\jboss\test\jbossmq\stress\ExceptionListenerTest .java:63: warning: stop() in java.lang.Thread has been deprecated [execmodules] t1.stop(); [execmodules] ^ [execmodules] C:\work\mletpatch\HEAD\jboss3.2beta\testsuite\src\main\org\jboss\test\jbossmq\stress\MassiveTest.java:75: warning: stop() in java.lang.Thread has been deprecated [execmodules] t1.stop(); [execmodules]^ [execmodules] C:\work\mletpatch\HEAD\jboss3.2beta\testsuite\src\main\org\jboss\test\jbossmq\stress\MassiveTest.java:129: warning: stop() in java.lang.Thread has been deprecated [execmodules] t1.stop(); [execmodules]^ [execmodules] C:\work\mletpatch\HEAD\jboss3.2beta\testsuite\src\main\org\jboss\test\jbossmq\stress\MassiveTest.java:133: warning: stop() in java.lang.Thread has been deprecated [execmodules] tf.stop(); [execmodules]^ [execmodules] C:\work\mletpatch\HEAD\jboss3.2beta\testsuite\src\main\org\jboss\test\jbossmq\stress\MultipleDurableSubscr ibers.java:111: warning: stop() in java.lang.Thread has been deprecated [execmodules] t1.stop(); [execmodules]^ [execmodules] C:\work\mletpatch\HEAD\jboss3.2beta\testsuite\src\main\org\jboss\test\jbossmq\stress\MultipleDurableSubscr ibers.java:113: warning: stop() in java.lang.Thread has been deprecated [execmodules] t2.stop(); [execmodules]^ [execmodules] C:\work\mletpatch\HEAD\jboss3.2beta\testsuite\src\main\org\jboss\test\jbossmq\stress\MultipleDurableSubscr ibers.java:168: warning: stop() in java.lang.Thread has been deprecated [execmodules] t1.stop(); [execmodules]^ [execmodules] C:\work\mletpatch\HEAD\jboss3.2beta\testsuite\src\main\org\jboss\test\jbossmq\stress\MultipleDurableSubscr ibers.java:170: warning: stop() in java.lang.Thread has been deprecated [execmodules] t2.stop(); [execmodules]^ [execmodules] C:\work\mletpatch\HEAD\jboss3.2beta\testsuite\src\main\org\jboss\test\jbossmq\stress\QueueTest.java:74: wa rning: stop() in java.lang.Thread has been deprecated [execmodules] t1.stop(); [execmodules]^ [execmodules] C:\work\mletpatch\HEAD\jboss3.2beta\testsuite\src\main\org\jboss\test\jbossmq\stress\QueueTest.java:116: w arning: stop() in java.lang.Thread has been deprecated [execmodules] t2.stop(); [execmodu
[JBoss-dev] Automated JBoss(Branch_3_0) Testsuite Results: 10-November-2002
Number of tests run: 991
Successful tests: 986
Errors:5
Failures: 0
[time of test: 10 November 2002 12:48 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:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] J2EE Timer Service
What about Quartz? Lets integrate instead of invent where we can. --jason what do you guys think of a new scheduler? marc f > -Original Message- > From: Ben Sabrin [mailto:ben@;jboss.org] > Sent: Monday, November 04, 2002 3:58 AM > To: Marc Fleury > Subject: FW: Quartz J2EE Scheduler > > > for your consumption. > > Ben Sabrin > Director of Sales and Business Development > JBoss Group, LLC > > > -Original Message- > From: Nathan Phelps [mailto:nphelps@;solarc.com] > Sent: Wednesday, October 30, 2002 9:20 PM > To: 'Ben Sabrin' > Subject: Quartz J2EE Scheduler > > > Here is the link to the Scheduler I was talking about today: > http://quartz.sourceforge.net > > Again, thanks for your visit. > I've already gotten feedback about how much everyone enjoyed it. > > Thanks, > > Nathan > On Sunday, November 10, 2002, at 11:15 AM, Scott M Stark wrote: I have not seen anyone mention this so go ahead. Scott Stark Chief Technology Officer JBoss Group, LLC - Original Message - From: "Andy" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Sunday, November 10, 2002 10:18 AM Subject: [JBoss-dev] J2EE Timer Service Hi Geeks Did anyone started to develop the EJB 2.1 Timer Service ? Otherwise I will have a look into it because I think we could use the Scheduler. Have fun - Andy --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Files looked on my fs from clean co
I have not seen any issue with permissioning of the checked out files. Scott Stark Chief Technology Officer JBoss Group, LLC - Original Message - From: "Peter Fagerlund" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Saturday, November 09, 2002 4:41 AM Subject: Re: [JBoss-dev] Files looked on my fs from clean co lördagen den 9 november 2002 kl 10.03 skrev Chris Kimpton: > It varies - usually none - but sometimes the cvs command spits out > some lock messages - but then carries on... um ... I am nor as clear as I need to be in my written english ... When I do a clean co, then build will fail, becouse of no write permission in the newly dloaded jboss.head folder. It just recently happened so I wanted to ask if this was simular for others ? ... maybe I just been using a shell with somebodyelses role ? ;-) --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] JMX on the client side?
No details as yet. I'm just directing the jmx on the client discussion towards a generalization of the notions of the server jmx microkernel. JavaGroups does not assume a multicast enabled network. Look at its architecture and you will see that protocols is abstracted away from messaging such that groups can run on top of point-point links. Scott Stark Chief Technology Officer JBoss Group, LLC - Original Message - From: "James Higginbotham" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Saturday, November 09, 2002 12:00 PM Subject: RE: [JBoss-dev] JMX on the client side? Scott, Interesting.. Do you have this scoped in your mind yet? I mean, Jboss (I hate how outlook "fixes" the b in jboss) currently uses JavaGroups, which assumes a multicast-enabled network. When you get to true peer-to-peer, you may have a double firewall situation where multicast doesn't work outside your LAN. In which case, you need concepts of superpeers on your local network that all register with public directory services to create a web of superpeers bridging private networks. This is (sortof) what JXTA does best (cough). In the past, I've seen discussions of JXTA + Jboss but haven't seen many thoughtful proposals, just "it would be cool ifs". Am I taking this vision of yours too far, not far enough, or missing you completely? The architecture of your dynamic proxies and JavaGroup networking seems to work great for local networks, so you must be envisioning more? James --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] J2EE Timer Service
I have not seen anyone mention this so go ahead. Scott Stark Chief Technology Officer JBoss Group, LLC - Original Message - From: "Andy" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Sunday, November 10, 2002 10:18 AM Subject: [JBoss-dev] J2EE Timer Service > Hi Geeks > > Did anyone started to develop the EJB 2.1 Timer Service ? > > Otherwise I will have a look into it because I think we could > use the Scheduler. > > Have fun - Andy --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] J2EE Timer Service
Hi Geeks Did anyone started to develop the EJB 2.1 Timer Service ? Otherwise I will have a look into it because I think we could use the Scheduler. Have fun - Andy --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-636227 ] testsuite generally fails to complete
Bugs item #636227, was opened at 2002-11-10 08:05 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=636227&group_id=22866 Category: JBossTest Group: CVS HEAD Status: Open Resolution: None Priority: 5 Submitted By: Chris Kimpton (kimptoc) Assigned to: Nobody/Anonymous (nobody) Summary: testsuite generally fails to complete Initial Comment: Hi, I have run the full testsuite (testsuite/build.xml, target test) several times but it rarely completes. The machine is doing nothing else - 2 x 1.3GHZ cpu, 1GB ram - left run for 15 hours plus. Redhat 7.2, sun jdk1.3.1_06 Tried using kill -SIGHUP, but it seemed to kill the JVM rathing giving a thread dump. Regards, Chris -- >Comment By: Scott M Stark (starksm) Date: 2002-11-10 09:05 Message: Logged In: YES user_id=175228 SIGQUIT is the correct signal to use to generate a thread dump. -- Comment By: Adrian Brock (ejort) Date: 2002-11-10 08:42 Message: Logged In: YES user_id=9459 Hi Chris, Can you try it again? I saw a deadlock with OIL yesterday, it was actually a deadlock across two VMs during the connection close. I saw it as a timeout rather than a permenant hang though. I also found a problem where the dead letter queue wasn't being used because of incorrect xml parsing. This led to infinite redelivery of messages to MDBs. I've committed these fixes now. Regards, Adrian -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=636227&group_id=22866 --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-636227 ] testsuite generally fails to complete
Bugs item #636227, was opened at 2002-11-10 16:05 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=636227&group_id=22866 Category: JBossTest Group: CVS HEAD Status: Open Resolution: None Priority: 5 Submitted By: Chris Kimpton (kimptoc) Assigned to: Nobody/Anonymous (nobody) Summary: testsuite generally fails to complete Initial Comment: Hi, I have run the full testsuite (testsuite/build.xml, target test) several times but it rarely completes. The machine is doing nothing else - 2 x 1.3GHZ cpu, 1GB ram - left run for 15 hours plus. Redhat 7.2, sun jdk1.3.1_06 Tried using kill -SIGHUP, but it seemed to kill the JVM rathing giving a thread dump. Regards, Chris -- >Comment By: Adrian Brock (ejort) Date: 2002-11-10 16:42 Message: Logged In: YES user_id=9459 Hi Chris, Can you try it again? I saw a deadlock with OIL yesterday, it was actually a deadlock across two VMs during the connection close. I saw it as a timeout rather than a permenant hang though. I also found a problem where the dead letter queue wasn't being used because of incorrect xml parsing. This led to infinite redelivery of messages to MDBs. I've committed these fixes now. Regards, Adrian -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=636227&group_id=22866 --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-636227 ] testsuite generally fails to complete
Bugs item #636227, was opened at 2002-11-10 16:05 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=636227&group_id=22866 Category: JBossTest Group: CVS HEAD Status: Open Resolution: None Priority: 5 Submitted By: Chris Kimpton (kimptoc) Assigned to: Nobody/Anonymous (nobody) Summary: testsuite generally fails to complete Initial Comment: Hi, I have run the full testsuite (testsuite/build.xml, target test) several times but it rarely completes. The machine is doing nothing else - 2 x 1.3GHZ cpu, 1GB ram - left run for 15 hours plus. Redhat 7.2, sun jdk1.3.1_06 Tried using kill -SIGHUP, but it seemed to kill the JVM rathing giving a thread dump. Regards, Chris -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=636227&group_id=22866 --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] JMX on the client side?
> > > JMX on the client side and JBoss on the client side are two different > > > things, right? AFAIK, MBeanServerFactory.createMBeanServer() doesn't > > > require the service deployer. If it does, that's another thing... > > > > Agreed. All I am talking about is an MBean server. If someone wants > > more JBoss services on the client side they can do that, but it > > shouldn't be required. > > Conceptually I like this, but... > > Are you thinking that these mbeans won't have any attributes? Or do you > plan to set them hardcoded in code? Or where does the configuration come > from? Can we serialize a prototype from the server and register the > deserialized copy on the client? Is there some way to use the new remote > jmx stuff for something like this? > > david > Could all of this MBean server configuration happen in a client-side interceptor?? So the first client-side interceptor might initialize the MBean server. Then the rest of the interceptors in the client chain can use the interceptor (register services or lookup other services). This approach would allow you to choose if you use JMX on the client or not. Regards, Hiram --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] JMX on the client side?
> +1. This all came about because I was thinking about client side caches > with server invalidation. Without the JMX kernel it is a pain because > we have invent a totally new architecture to handle server to client > invocations. If we have the kernel, we quickly prototype this by > reusing the server invokers. Of course our existing invokers won't work > for a real deployment with clients behind a firewall, but it is a good > start. > > -dain > What I would like to know, is: what are the features that JMX provides that you need on the client side?? (1) Is it the interceptor architecture built around JMX? (2) Is it the ability to look up other services via JMX? I want to know because I think that we can provide client side container without having to use JMX. I think that stuff will actually get simpler if we do not FORCE jmx on the client side. Our Aspect API is all about that. It's about providing at least #1 in a clean generic fashion. But for it successfully use for client side containers, I need to understand what all the requirements will be. Bill, I know you started doing some work on client side interceptors using the aspect stuff. What JMX features were you wishing you had on the client side?? Regards, Hiram --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
