[JBoss-dev] Automated JBoss Testsuite Results: 23-April-2002
Number of tests run: 566 Successful tests: 539 Errors:18 Failures: 9 [time of test: 23 April 2002 8:19 GMT] [java.version: 1.3.1] [java.vendor: Sun Microsystems Inc.] [java.vm.version: 1.3.1-b24] [java.vm.name: Java HotSpot(TM) Server VM] [java.vm.info: mixed mode] [os.name: Linux] [os.arch: i386] [os.version: 2.4.9-31] See http://lubega.com/testarchive/sun_jdk131 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! ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [AUTOMATED] JBoss org.jboss.Shutdown does not work
= ==THIS IS AN AUTOMATED EMAIL - SEE http://www.lubega.com FOR DETAILS= = JAVA VERSION DETAILS java version "1.3.1" Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.1-b24) Java HotSpot(TM) Server VM (build 1.3.1-b24, mixed mode) = HERE ARE THE LAST 50 LINES OF THE LOG FILE Hello, The org.jboss.Shutdown class does not seem to work. That is, the jboss_redhat_init.sh script called it and the jboss server did not stop... Please could we get this fixed... Or tell me what I should be calling to get the server shutdown... Now I will return to the old faithful method - "kill -9" See ya, Chris PS This is automated - just to make it really annoying... ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] RE: Distributable HttpSessions - problems...
Hello Jules, > I have recently been thinking a bit about my next iteration on > distributable HttpSessions for JBoss/Jetty. BTW, does it work?!? I haven't heard you anymore since your last troubles. > My reading of the spec is that it avoids all of these issues by only > ever allowing one copy of a session to be active at one time i.e. it > talks about migrating sessions from one server to another - but not (as > I recall) replicating them. This is what we tend to have: only one session is active at a time. (minus side effects) BTW, I think that, not only for HttpSession but for JMS, one important service is missing from the HA framework: some kind of distributed locking mechanism (i.e. the way to say "this belongs to me"). It wasn't needed until now but the distributed cache/httpsession/queues/... will heavily rely on this, I am pretty sure. > I see the following problems with replication : > > 1. create/modify/destroy session events > > > If a session is created/modified/removed on NodeA, should listeners > attached to a replicant (or the replicant's context) be notified > on NodeB ? Currently, the session is removed from the cache from NodeB. The question is: Why would you have two session active at a time? (I know: multi-frames). If we have n frames that read and 1 frame that write (which is the case in most cases IMHO), it is ok. But I agree: without a load-balancer supporting sticky session, we can have some strange behaviour. But iMHO, we have to find a mean between performance and "correctness" in this case. If you want to be sure that only one session is active at a time and this, without a sticky session LB, then it means distributed locking, no other choice. > If so, we open another nasty can of worms, since we need to guarantee > the order in which modifications arrive at NodeB from other Nodes in the > cluster. That's the issue: non sticky-session LB. Sticky => performance non-Sticky => distributed locking => bad performance I wanted to implement the locking service for a further release of JBoss. > Furthermore, code that manages distributed resources via these > notifications, and work in the webapp in non-distributed mode, may > break. e.g. code that allocates/deallocates a distributed resource on > session creation/destruction will have to reference count > creation/destruction so that the resource is allocated/deallocated at > the correct times. Even then, if a node goes down, serious problems > arise - the system begins to look very fragile. I know not enough on the servlet side to have a critical eye on this, so I trust you ;) > If not, then we assume that all resources being managed by these > listeners are distributed and not local, since notifications involving > different parts of their lifecycle may arrive on different nodes in the > cluster. distributed? no: performance would be dead. > 2. activation/passivation/distribution > --- > > The spec requires notification of the relevant listeners on the > activation/passivation of a session. Ignoring the problem in (1) another > issue still remains. Does the distribution of a session constitute a > passivation/activation cycle ? > > Let's say we start a new nodeB and deploy a webapp on it. This webapp is > already running on another nodeA. A request for this webapp somehow > arrives at nodeB. Does nodeB notify activation listeners ? If so, then > for the sake of symmetry, nodeA should have notified passivation > listeners. Pursuing this to it's logical conclusion, every 'snapshot' > and distribution of a session might need to notify first passivation > and then activation listeners. Activation/Passivation is too expensive > to do this frequently. See above. > I am interested in how others have resolved these problems, or have they > been largely ignored in other implementations ? > > In writing this I am beginning to think in the following way : > > The spec resolves all of this by only allowing one 'active' copy of the > session at any one time. I think that one way around these problems may > be to assume that only one replicant at any one time is 'active'. > Notification of change is only made on the 'active' session. The token > designating 'activity' is passed around the cluster in the form of > client requests. If we can avoid two requests accessing twin sessions on > different nodes at the same time we can adhere to the spec's model of > how this should work. Session affinity will go most of the way to > fulfilling this requirement, but there will be cases when it will fail. > In these cases, behaviour will be unpredictable - can we prevent this ? > > > OK - I'm rambling, and it's past my bedtime. > > > Does this make any sense to anyone ? Jules, you always make sense. That's probably because you know your family until 1066 ;) You have one thousand year of sh
AW: [JBoss-dev] Are these CVS modules still in use anywhere?
I would appreciate deletion of ZOAP as an evidence of my once evil programming skills ;-) CGJ -Ursprüngliche Nachricht- Von: Jason Dillon [mailto:[EMAIL PROTECTED]] Gesendet: Dienstag, 23. April 2002 04:31 An: [EMAIL PROTECTED] Betreff: [JBoss-dev] Are these CVS modules still in use anywhere? Does anyone know if the 'zoap' and 'zola' modules are still in use anywhere? --jason ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] AW: Workaround for CL stuff
As a quick work-around while I´m busy today with doing business (buaaeeeh:-( Patch the java.lang.ClassLoader class ... Either remove the synchronized keyword from loadClassInternal (should be safe) or make it protected and remove the synchronized keyword in an overriding method of UnifiedClassLoader (makes the build Depending on that patch, not that nice). Put the patched class in a patch.jar and start jboss With the option -Xbootclasspath/a:patch.jar Viola, CGJ -Ursprüngliche Nachricht- Von: marc fleury [mailto:[EMAIL PROTECTED]] Gesendet: Montag, 22. April 2002 20:04 An: Jboss-Development@Lists. Sourceforge. Net Cc: Christoph Jung; sacha labourey Betreff: Workaround for CL stuff Ok, I am sure we can find something. I would appreciate a brief description of a CL deadlock scenario due to the final loadClassInternal. Jung? Sacha? It's only software, software is dumb marcf x Marc Fleury, Ph.D President and CEO JBoss Group, LLC x ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] AW: Workaround for CL stuff
On Tue, 23 Apr 2002, Jung , Dr. Christoph wrote: > As a quick work-around while I´m busy today with doing business (buaaeeeh:-( > > Patch the java.lang.ClassLoader class ... Either remove the synchronized > keyword from loadClassInternal (should be safe) > or make it protected and remove the synchronized keyword in an overriding > method of UnifiedClassLoader (makes the build > Depending on that patch, not that nice). Put the patched class in a > patch.jar and start jboss > With the option -Xbootclasspath/a:patch.jar did you mean -Xbootclasspath/p:patch.jar ? Holger ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Change Notes-547479 ] MBeanProxy Changes
Change Notes item #547479, was opened at 2002-04-23 12:34
You can respond by visiting:
http://sourceforge.net/tracker/?func=detail&atid=381174&aid=547479&group_id=22866
Category: JBossMX
Group: None
Status: Open
Priority: 5
Submitted By: Juha Lindfors (juhalindfors)
Assigned to: Juha Lindfors (juhalindfors)
Summary: MBeanProxy Changes
Initial Comment:
The MBean proxy instances are now MBeans themselves,
and can be registered to an MBean server (implementing
DynamicMBean interface). This allows for a trivial
construction of redirects between MBean servers, for
insance:
client --> Server A (proxy) --> Server B (resource)
where the management interface of the proxy in Server A
is identical to the management interface in Server B.
In other words, a client executing
server.getMBeanInfo() on a proxy instance will return
the MBeanInfo of the target MBean (proxies are
transparent).
Additionally, the proxy can be used to invoke the MBean
either with a typed Java interface or detyped
DynamicMBean interface depending on which factory
method is used by the client:
MBeanProxy.get(Class interface, ObjectName name,
MBeanServer server)
will return a typed proxy, where as
MBeanProxy.get(ObjectName name, MBeanServer server)
will return a "detyped" DynamicMBean proxy interface.
Thirdly, the proxy allows the client access to the
MBean server instance the target MBean is registered to
by implementing a ProxyContext interface. The client
can access the proxy context by casting the created
proxy instance as follows:
Object proxy = MBeanProxy.get(...);
ProxyContext ctx = (ProxyContext)proxy;
To access the methods of the MBean server the proxy
target MBean is registered to, the client can invoke:
MBeanServer server = ctx.getMBeanServer();
server.queryMBeans(...)
to query the containing server, for instance. Later the
same context interface can be used to configure
interceptors on the proxy ("client" interceptors),
configure the connector client properties (RMI, JMS,
SOAP), or expose the proxys configuration as an MBean.
Currently, in addition to the access to the MBean
server interface, the ProxyContext interface provides
the client access to custom exception handlers via the
setExceptionHandler() method. This allows the client to
override the exception logic handling inside the proxy,
for instance, how the proxy should react to
InstanceNotFound exceptions.
--
You can respond by visiting:
http://sourceforge.net/tracker/?func=detail&atid=381174&aid=547479&group_id=22866
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Feature Requests-547494 ] allow alter-table like create-table
Feature Requests item #547494, was opened at 2002-04-23 03:43 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=376688&aid=547494&group_id=22866 Category: JBossCMP Group: v3.0 Rabbit Hole Status: Open Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: allow alter-table like create-table Initial Comment: Besides defining a create-table in the deployment descriptor jbosscmp-jdbc.xml for an entity / relation table it would be very comfortable to support also an alter-table. Especially when an existing system is changed over time "alter table" functionality simplifies deployment: For example when an entity bean is configured with remove-table=false, the data stays in the database when it is undeployed. Now the entity bean is updated with an additional field. When deploying the new version with "alter-table=true" the missing column is added automatically. At the moment the user must perfrom an alter table by hand and must "know" the table and the new column name. Something that CMP should prevent in general. Furthermore this could allow multiple entity beans to use the same table. Lets assume "creat-table=true" and "alter-table=true". Then the deployment of the first bean would then create the table, the deployment of the second bean could adds some columns. The code that must be changed is basically in org.jboss.ejb.plugins.cmp.jdbc.JDBCStartCommand.java org.jboss.ejb.plugins.cmp.jdbc.metadata.JDBCEntityMetaD ata -- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=376688&aid=547494&group_id=22866 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Re: [JBoss-user] Save the Rabbit HoleUnifiedClassLoaders - Vote and Argue at the BugParade! - Spread the Word!
Start up jboss with the -Xdebug option to the JVM. It will then show the locking. On Mon, 2002-04-22 at 21:13, marc fleury wrote: > Unfortunately this VM doesn't show what object it locks on so I can't do the > same analysis I did with Dave Smith's dump, Dave, what VM were you using??? > alarik please use the same if you can > > I will try to code this solution tonight or tomorrow morning, I am kind of > tired and down but I think I got this problem in my head, > > marcf > > > |Hi Marc -- > | > |I can't even make it through startup. If I do a thread dump, it sure looks > |like a thread deadlock. The only thing that I can think of that might be > |weird about my situation is that we are spawning another thread on the > |server during startup which then initializes some JMS publishers. We spawn > |the thread because in a clustered Weblogic environment (which we use in > |production), it is possible that during startup the JNDI context won't have > |been replicated yet to the local machine, and so we wait and try > |again until > |such time as the JNDI context is replicated. Here are the stack > |traces from > |the two relavent threads: > | > |"main" prio=5 tid=0xc7d0a0 nid=0x111 waiting for monitor entry > |[0x93fd000..0x93ffdc0] > |at java.lang.ClassLoader.loadClass(ClassLoader.java:286) > |at > |org.jboss.mx.loading.UnifiedClassLoader.loadClassLocally(UnifiedCla > |ssLoader. > |java:180) > |at > |org.jboss.mx.loading.UnifiedLoaderRepository.loadClass(UnifiedLoade > |rReposito > |ry.java:178) > |at > |org.jboss.mx.loading.UnifiedClassLoader.loadClass(UnifiedClassLoade > |r.java:21 > |7) > |at java.lang.ClassLoader.loadClass(ClassLoader.java:253) > |at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:313) > |at java.lang.ClassLoader.defineClass0(Native Method) > |at java.lang.ClassLoader.defineClass(ClassLoader.java:486) > |at > |java.security.SecureClassLoader.defineClass(SecureClassLoader.java:111) > |at java.net.URLClassLoader.defineClass(URLClassLoader.java:248) > |at java.net.URLClassLoader.access$100(URLClassLoader.java:56) > |at java.net.URLClassLoader$1.run(URLClassLoader.java:195) > |at java.security.AccessController.doPrivileged(Native Method) > |at java.net.URLClassLoader.findClass(URLClassLoader.java:188) > |at > |org.jboss.mx.loading.UnifiedClassLoader.findClass(UnifiedClassLoade > |r.java:17 > |2) > |at java.lang.ClassLoader.loadClass(ClassLoader.java:297) > |at > |org.jboss.mx.loading.UnifiedClassLoader.loadClassLocally(UnifiedCla > |ssLoader. > |java:180) > |at > |org.jboss.mx.loading.UnifiedLoaderRepository.loadClass(UnifiedLoade > |rReposito > |ry.java:156) > |at > |org.jboss.mx.loading.UnifiedClassLoader.loadClass(UnifiedClassLoade > |r.java:21 > |7) > |at java.lang.ClassLoader.loadClass(ClassLoader.java:253) > |at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:313) > |at org.jboss.ejb.EJBDeployer.create(EJBDeployer.java:338) > |at org.jboss.deployment.MainDeployer.create(MainDeployer.java:626) > |at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:506) > |at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:470) > |at java.lang.reflect.Method.invoke(Native Method) > |at > |org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMB > |eanDispat > |cher.java:284) > |at > |org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:492) > |at org.jboss.util.jmx.MBeanProxy.invoke(MBeanProxy.java:174) > |at $Proxy4.deploy(Unknown Source) > |at > |org.jboss.deployment.scanner.URLDeploymentScanner.deploy(URLDeploym > |entScanne > |r.java:350) > |at > |org.jboss.deployment.scanner.URLDeploymentScanner.scanDirectory(URL > |Deploymen > |tScanner.java:530) > |at > |org.jboss.deployment.scanner.URLDeploymentScanner.scan(URLDeploymen > |tScanner. > |java:410) > |at > |org.jboss.deployment.scanner.AbstractDeploymentScanner.startService > |(Abstract > |DeploymentScanner.java:237) > |at > |org.jboss.system.ServiceMBeanSupport.start(ServiceMBeanSupport.java:162) > |at java.lang.reflect.Method.invoke(Native Method) > |at > |org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMB > |eanDispat > |cher.java:284) > |at > |org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:492) > |at > |org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceContr > |oller.jav > |a:867) > |at $Proxy0.start(Unknown Source) > |at > |org.jboss.system.ServiceController.start(ServiceController.java:341) > |at java.lang.reflect.Method.invoke(Native Method) > |at > |org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMB > |eanDispat > |cher.java:284) > |at > |org.jboss.mx.server.MBeanSe
AW: [JBoss-dev] AW: Workaround for CL stuff
Of course, it must prepend the JDK-shit, sorry did cut&paste from the Tool-Doc ... CGJ -Ursprüngliche Nachricht- Von: Holger Engels [mailto:[EMAIL PROTECTED]] Gesendet: Dienstag, 23. April 2002 11:09 An: [EMAIL PROTECTED] Betreff: Re: [JBoss-dev] AW: Workaround for CL stuff On Tue, 23 Apr 2002, Jung , Dr. Christoph wrote: > As a quick work-around while I´m busy today with doing business > (buaaeeeh:-( > > Patch the java.lang.ClassLoader class ... Either remove the > synchronized keyword from loadClassInternal (should be safe) or make > it protected and remove the synchronized keyword in an overriding > method of UnifiedClassLoader (makes the build Depending on that patch, > not that nice). Put the patched class in a patch.jar and start jboss > With the option -Xbootclasspath/a:patch.jar did you mean -Xbootclasspath/p:patch.jar ? Holger ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
AW: [JBoss-dev] Workaround for CL stuff
Actually, it´s more complicated: Thread 1: VM detects that it needs bar, calls UCL A.loadClassInternal() and hence synchronizes on A Thread 2: VM detects that it needs foo, calls UCL B.loadClassInternal() and hence synchronizes on B Thread 1: UCL A delegates to Repository delegates to UCL B, LOCKED Thread 2: UCL B delegates to Repository delegates to UCL A, LOCKED CGJ -Ursprüngliche Nachricht- Von: lsanders [mailto:[EMAIL PROTECTED]] Gesendet: Montag, 22. April 2002 20:29 An: Jboss-Development@Lists. Sourceforge. Net Betreff: Re: [JBoss-dev] Workaround for CL stuff Though I've never experienced this, I think this is the problem scenario: The players: UnifiedClassLoader A (can load directly class foo) UnifiedClassLoader B (can load directly class bar) Thread 1 (context loader is A): Load new class bar: - synchronize on UCL A - Search UCL B - Attempt to synchronize on UCL B Thread 2 (contect loader is B): Load new class foo: - synchronize on UCL B - Search UCL A - Attempt to synchronize on UCL A Can someone verify if this is accurate? -Larry > Ok, > > I am sure we can find something. > > I would appreciate a brief description of a CL deadlock scenario due > to the > final loadClassInternal. Jung? Sacha? > > It's only software, software is dumb > > marcf > > x > Marc Fleury, Ph.D > President and CEO > JBoss Group, LLC > x > > > > ___ > Jboss-development mailing list [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-development > ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
AW: [JBoss-dev] Workaround for CL stuff
AFAIK, a thread will only release the lock in the closest synchronization scope. If you can make sure that the UCL itself is the last lock before entering ULR, then it should IMHO work. Since we are not in control of loadClassInternal, but of loadClass, there is the chance that this will do as wished. CGJ -Ursprüngliche Nachricht- Von: marc fleury [mailto:[EMAIL PROTECTED]] Gesendet: Dienstag, 23. April 2002 03:07 An: Dave Smith Cc: lsanders; Jboss-Development@Lists. Sourceforge. Net Betreff: RE: [JBoss-dev] Workaround for CL stuff Solution: When a thread goes through loadClass, in the ULR we "lock" with a field that tracks the thread. Another thread comes in, reaches ULR, we sync on the calling CL (we know it) we wait, this releases the lock, we keep track of the CL as part of this "load". The first thread will always find a CL as no CL can be locked for ever, since the thread that would reach the ULR would wait. First thread always finishes (with reentrancy so the count must go on and we track the fact that it is the same thread). When count reaches 0 we get the set of CL that were touched by this thread (i.e. the set of CLs that had threads in it) and we notifyAll on each element of the set, start this again. Done (afaict), I will try to apply it to the stack trace below. |I brought this thing back to life and passed the URL of the orginal sun |bug that they rejected. Here is a quick stack trace of the deadlock. |Note that you should start jboss with the -Xdebug options so it shows |you what objects that it is trying to lock. See below for my orginal |post | | |"CCRAPoll" prio=5 tid=0x8184f58 nid=0x64ec waiting for monitor entry |[0xbb7fe000..0xbb7ffad8] |at java.lang.ClassLoader.loadClass(ClassLoader.java:288) |- waiting to lock <43a2c508> (a |org.jboss.mx.loading.UnifiedClassLoader) |at |org.jboss.mx.loading.UnifiedClassLoader.loadClassLocally(UnifiedCla ssLoader.java:180) |at |org.jboss.mx.loading.UnifiedLoaderRepository.loadClass(UnifiedLoade rRepository.java:178) This one would reach ULR and lock the ULR, see below for lock <43a2c508> NOT being locked. |at |org.jboss.mx.loading.UnifiedClassLoader.loadClass(UnifiedClassLoade |r.java:217) |at java.lang.ClassLoader.loadClass(ClassLoader.java:255) |at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:315) |- locked <43eefa48> (a org.jboss.mx.loading.UnifiedClassLoader) |at |com.entrust.toolkit.PKCS7EncodeStream.e(PKCS7EncodeStream.java) |at |com.entrust.toolkit.PKCS7EncodeStream.f(PKCS7EncodeStream.java) |at |com.entrust.toolkit.PKCS7EncodeStream.write(PKCS7EncodeStream.java) |at com.candata.gateway.Encryption.Sign(Unknown Source) |- locked <43f0c6a0> (a com.candata.gateway.Encryption) |at com.candata.gateway.Encryption.createMsg(Unknown Source) |at com.candata.gateway.CCRAAbstract.postMsg(Unknown Source) |at com.candata.gateway.CCRAAbstract.recvMsg(Unknown Source) |at com.candata.gateway.CCRAPoll.run(Unknown Source) |at java.lang.Thread.run(Thread.java:484) | | |"Thread-20" prio=5 tid=0x81821a8 nid=0x64f9 waiting for monitor entry |[0xbe7fe000..0xbe7ffad8] |at java.lang.ClassLoader.loadClass(ClassLoader.java:288) |- waiting to lock <43eefa48> (a |org.jboss.mx.loading.UnifiedClassLoader) |at |org.jboss.mx.loading.UnifiedClassLoader.loadClassLocally(UnifiedCla ssLoader.java:180) |at |org.jboss.mx.loading.UnifiedLoaderRepository.loadClass(UnifiedLoade rRepository.java:178) thread 2 reaches here and sees a ULR under usage. It waits on the calling UCL (which we know it is passed) and THEREFORE UNLOCKS <43a2c508>. Done marcf |at |org.jboss.mx.loading.UnifiedClassLoader.loadClass(UnifiedClassLoade |r.java:217) |at java.lang.ClassLoader.loadClass(ClassLoader.java:255) |at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:315) |- locked <43a2c508> (a org.jboss.mx.loading.UnifiedClassLoader) |at java.lang.Class.forName0(Native Method) |at java.lang.Class.forName(Class.java:195) |at |javax.security.auth.login.LoginContext.invoke(LoginContext.java:626) |at |javax.security.auth.login.LoginContext.access$000(LoginContext.java:129) |at |javax.security.auth.login.LoginContext$4.run(LoginContext.java:599) |at java.security.AccessController.doPrivileged(Native Method) |at |javax.security.auth.login.LoginContext.invokeModule(LoginContext.java:596) |at |javax.security.auth.login.LoginContext.login(LoginContext.java:523) |at com.candata.util.beans.CandataClientLogin.login(Unknown |Source) |at com.candata.bbxinterface.BbxJavaInvoker.login(Unknown Source) |at com.candata.bbxinterface.BbxWrapper.run(Unknown Source) |at java.lang.Thread.run(Thread.java:484) marcf ___ Jboss-d
RE: [JBoss-dev] Workaround for CL stuff
|AFAIK, a thread will only release the lock in the closest synchronization |scope. hence my previous mail does a double synchronization on the *same* lock release both or not. marcf | |If you can make sure that the UCL itself is the last lock before entering |ULR, then it |should IMHO work. Since we are not in control of loadClassInternal, but of |loadClass, there is the chance |that this will do as wished. | |CGJ | |-Ursprüngliche Nachricht- |Von: marc fleury [mailto:[EMAIL PROTECTED]] |Gesendet: Dienstag, 23. April 2002 03:07 |An: Dave Smith |Cc: lsanders; Jboss-Development@Lists. Sourceforge. Net |Betreff: RE: [JBoss-dev] Workaround for CL stuff | | |Solution: | |When a thread goes through loadClass, in the ULR we "lock" with a |field that |tracks the thread. | |Another thread comes in, reaches ULR, we sync on the calling CL |(we know it) |we wait, this releases the lock, we keep track of the CL as part of this |"load". The first thread will always find a CL as no CL can be locked for |ever, since the thread that would reach the ULR would wait. First thread |always finishes (with reentrancy so the count must go on and we track the |fact that it is the same thread). When count reaches 0 we get the |set of CL |that were touched by this thread (i.e. the set of CLs that had threads in |it) and we notifyAll on each element of the set, start this again. | |Done (afaict), I will try to apply it to the stack trace below. | ||I brought this thing back to life and passed the URL of the orginal sun ||bug that they rejected. Here is a quick stack trace of the deadlock. ||Note that you should start jboss with the -Xdebug options so it shows ||you what objects that it is trying to lock. See below for my orginal ||post || || ||"CCRAPoll" prio=5 tid=0x8184f58 nid=0x64ec waiting for monitor entry ||[0xbb7fe000..0xbb7ffad8] ||at java.lang.ClassLoader.loadClass(ClassLoader.java:288) ||- waiting to lock <43a2c508> (a ||org.jboss.mx.loading.UnifiedClassLoader) ||at ||org.jboss.mx.loading.UnifiedClassLoader.loadClassLocally(UnifiedCla |ssLoader.java:180) ||at ||org.jboss.mx.loading.UnifiedLoaderRepository.loadClass(UnifiedLoade |rRepository.java:178) | |This one would reach ULR and lock the ULR, see below for lock |<43a2c508> NOT |being locked. | ||at ||org.jboss.mx.loading.UnifiedClassLoader.loadClass(UnifiedClassLoade ||r.java:217) ||at java.lang.ClassLoader.loadClass(ClassLoader.java:255) ||at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:315) ||- locked <43eefa48> (a org.jboss.mx.loading.UnifiedClassLoader) ||at ||com.entrust.toolkit.PKCS7EncodeStream.e(PKCS7EncodeStream.java) ||at ||com.entrust.toolkit.PKCS7EncodeStream.f(PKCS7EncodeStream.java) ||at ||com.entrust.toolkit.PKCS7EncodeStream.write(PKCS7EncodeStream.java) ||at com.candata.gateway.Encryption.Sign(Unknown Source) ||- locked <43f0c6a0> (a com.candata.gateway.Encryption) ||at com.candata.gateway.Encryption.createMsg(Unknown Source) ||at com.candata.gateway.CCRAAbstract.postMsg(Unknown Source) ||at com.candata.gateway.CCRAAbstract.recvMsg(Unknown Source) ||at com.candata.gateway.CCRAPoll.run(Unknown Source) ||at java.lang.Thread.run(Thread.java:484) || || ||"Thread-20" prio=5 tid=0x81821a8 nid=0x64f9 waiting for monitor entry ||[0xbe7fe000..0xbe7ffad8] ||at java.lang.ClassLoader.loadClass(ClassLoader.java:288) ||- waiting to lock <43eefa48> (a ||org.jboss.mx.loading.UnifiedClassLoader) ||at ||org.jboss.mx.loading.UnifiedClassLoader.loadClassLocally(UnifiedCla |ssLoader.java:180) ||at ||org.jboss.mx.loading.UnifiedLoaderRepository.loadClass(UnifiedLoade |rRepository.java:178) | |thread 2 reaches here and sees a ULR under usage. It waits on the calling |UCL (which we know it is passed) and THEREFORE UNLOCKS <43a2c508>. | |Done | |marcf | ||at ||org.jboss.mx.loading.UnifiedClassLoader.loadClass(UnifiedClassLoade ||r.java:217) | ||at java.lang.ClassLoader.loadClass(ClassLoader.java:255) ||at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:315) ||- locked <43a2c508> (a org.jboss.mx.loading.UnifiedClassLoader) ||at java.lang.Class.forName0(Native Method) ||at java.lang.Class.forName(Class.java:195) ||at ||javax.security.auth.login.LoginContext.invoke(LoginContext.java:626) ||at ||javax.security.auth.login.LoginContext.access$000(LoginContext.java:129) ||at ||javax.security.auth.login.LoginContext$4.run(LoginContext.java:599) ||at java.security.AccessController.doPrivileged(Native Method) ||at ||javax.security.auth.login.LoginContext.invokeModule(LoginContext.java:596) ||at ||javax.security.auth.login.LoginContext.login(LoginContext.java:523) ||at com.candata.util.beans.CandataClientLogin.login(Unknown ||Source) ||at com.candata.bbxinterface.BbxJavaI
Re: RE: [JBoss-dev] Workaround for CL stuff
VM Spec 8.14 Suppose that thread T has in fact performed N lock operations that have not been matched by unlock operations. The wait method then adds the current thread to the wait set for the object, disables the current thread for thread scheduling purposes, and performs N unlock operations to relinquish the lock. Regards, Adrian > |AFAIK, a thread will only release the lock in the > closest synchronization > |scope. > > hence my previous mail > > does a double synchronization on the *same* lock > release both or not. > > marcf > > | > |If you can make sure that the UCL itself is the last > lock before entering > |ULR, then it > |should IMHO work. Since we are not in control of > loadClassInternal, but of > |loadClass, there is the chance > |that this will do as wished. > | > |CGJ > | > |-Ursprüngliche Nachricht- > |Von: marc fleury [mailto:[EMAIL PROTECTED]] > |Gesendet: Dienstag, 23. April 2002 03:07 > |An: Dave Smith > |Cc: lsanders; Jboss-Development@Lists. Sourceforge. > Net > |Betreff: RE: [JBoss-dev] Workaround for CL stuff > | > | > |Solution: > | > |When a thread goes through loadClass, in the ULR we > "lock" with a > |field that > |tracks the thread. > | > |Another thread comes in, reaches ULR, we sync on the > calling CL > |(we know it) > |we wait, this releases the lock, we keep track of > the CL as part of this > |"load". The first thread will always find a CL as > no CL can be locked for > |ever, since the thread that would reach the ULR > would wait. First thread > |always finishes (with reentrancy so the count must > go on and we track the > |fact that it is the same thread). When count > reaches 0 we get the > |set of CL > |that were touched by this thread (i.e. the set of > CLs that had threads in > |it) and we notifyAll on each element of the set, > start this again. > | > |Done (afaict), I will try to apply it to the stack > trace below. > | > ||I brought this thing back to life and passed the > URL of the orginal sun > ||bug that they rejected. Here is a quick stack trace > of the deadlock. > ||Note that you should start jboss with the -Xdebug > options so it shows > ||you what objects that it is trying to lock. See > below for my orginal > ||post > || > || > ||"CCRAPoll" prio=5 tid=0x8184f58 nid=0x64ec waiting > for monitor entry > ||[0xbb7fe000..0xbb7ffad8] > ||at > java.lang.ClassLoader.loadClass(ClassLoader.java:288) > ||- waiting to lock <43a2c508> (a > ||org.jboss.mx.loading.UnifiedClassLoader) > ||at > ||org.jboss.mx.loading.UnifiedClassLoader.loadClassLoc > lly(UnifiedCla > |ssLoader.java:180) > ||at > ||org.jboss.mx.loading.UnifiedLoaderRepository.loadCla > s(UnifiedLoade > |rRepository.java:178) > | > |This one would reach ULR and lock the ULR, see below > for lock > |<43a2c508> NOT > |being locked. > | > ||at > ||org.jboss.mx.loading.UnifiedClassLoader.loadClass(Un > fiedClassLoade > ||r.java:217) > ||at > java.lang.ClassLoader.loadClass(ClassLoader.java:255) > ||at > java.lang.ClassLoader.loadClassInternal(ClassLoader.ja > a:315) > ||- locked <43eefa48> (a > org.jboss.mx.loading.UnifiedClassLoader) > ||at > ||com.entrust.toolkit.PKCS7EncodeStream.e(PKCS7EncodeS > ream.java) > ||at > ||com.entrust.toolkit.PKCS7EncodeStream.f(PKCS7EncodeS > ream.java) > ||at > ||com.entrust.toolkit.PKCS7EncodeStream.write(PKCS7Enc > deStream.java) > ||at > com.candata.gateway.Encryption.Sign(Unknown Source) > ||- locked <43f0c6a0> (a > com.candata.gateway.Encryption) > ||at > com.candata.gateway.Encryption.createMsg(Unknown > Source) > ||at > com.candata.gateway.CCRAAbstract.postMsg(Unknown > Source) > ||at > com.candata.gateway.CCRAAbstract.recvMsg(Unknown > Source) > ||at com.candata.gateway.CCRAPoll.run(Unknown > Source) > ||at java.lang.Thread.run(Thread.java:484) > || > || > ||"Thread-20" prio=5 tid=0x81821a8 nid=0x64f9 waiting > for monitor entry > ||[0xbe7fe000..0xbe7ffad8] > ||at > java.lang.ClassLoader.loadClass(ClassLoader.java:288) > ||- waiting to lock <43eefa48> (a > ||org.jboss.mx.loading.UnifiedClassLoader) > ||at > ||org.jboss.mx.loading.UnifiedClassLoader.loadClassLoc > lly(UnifiedCla > |ssLoader.java:180) > ||at > ||org.jboss.mx.loading.UnifiedLoaderRepository.loadCla > s(UnifiedLoade > |rRepository.java:178) > | > |thread 2 reaches here and sees a ULR under usage. It > waits on the calling > |UCL (which we know it is passed) and THEREFORE > UNLOCKS <43a2c508>. > | > |Done > | > |marcf > | > ||at > ||org.jboss.mx.loading.UnifiedClassLoader.loadClass(Un > fiedClassLoade > ||r.java:217) > | > ||at > java.lang.ClassLoader.loadClass(ClassLoader.java:255) > ||at > java.lang.ClassLoader.loadClassInternal(ClassLoader.ja > a:315) > ||- locked <43a2c508> (a > org.jboss.mx.loading.UnifiedClassLoader) > ||at java.lang.Class.forName0(Native Method) > ||
Re: [JBoss-dev] What should we do about SQLExceptions in BMP (3.0/3.1)
David Jencks wrote: >My understanding of Dain's cmp code is that any SQLException will result in >the tx being set rollback only, and basically all work discarded. > >In the new local jdbc wrapper, I've done something about as drastic: if >there is any SQLException from any operation, the connection is discarded >and the connection handle you get is then useless (unless you hold onto it >over a method boundary, then it can get reassociated on the next call). > I had the same questions while writting an adapter for a third party O-R mapping library. The jca spec is rather vague about how exceptions should effect the transaction state. However the intro to section 12 "Exceptions" does state that a resource can throw both system exceptions (where the transaction is rolled back) and application exceptions. > > >My interpretation of the jca spec is that this is the expected behavior for >a jca adapter. However,... > >1. This breaks at least some code in the test suite, the cts bmp unit test >basically tests for the existence of its table by looking for an exception. > The solution is to always discard a connection handle after any exception. >How much user code is likely to break? Does anyone know what the j2ee spec >says about SQLExceptions (a reference would be great) If this makes JBoss >more spec compliant, do we care if it breaks preexisting code? > This would also break code that tests integrity constraints and handles violations as application exceptions. > > >2. I wrote the wrapper so it would be easy to write an extension for a >specific database that could look at the SQLException content and only >discard the connection if it was actually unusable. If we do this, what >happens to the original SQLException? Do we turn it into a warning? Maybe >this idea of db-specific exception handling won't work. Any opinions? > Why can you not just rethrow the SQLException. It might make sense to turn all exceptions that break the connection into a runtime exception. This would mean they will always be treated as system exceptions. I haven't look at your new code, but how about the following: 1. Each SQLException is passed through a custom exception handler that's added to the adapter in the configuration. 2. The handler indicates if the connection is still good (via a callback?) and returns an exception which is rethrown. > > >thanks >david jencks > > Victor Langelo ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: RE: [JBoss-dev] Workaround for CL stuff
|VM Spec 8.14 | |Suppose that thread T has in fact performed N lock |operations that have not been matched by unlock |operations. The wait method then adds the current thread |to the wait set for the object, disables the current |thread for thread scheduling purposes, and performs N |unlock operations to relinquish the lock. then we have a fix... marcf | |Regards, |Adrian | |> |AFAIK, a thread will only release the lock in the |> closest synchronization |> |scope. |> |> hence my previous mail |> |> does a double synchronization on the *same* lock |> release both or not. |> |> marcf |> |> | |> |If you can make sure that the UCL itself is the last |> lock before entering |> |ULR, then it |> |should IMHO work. Since we are not in control of |> loadClassInternal, but of |> |loadClass, there is the chance |> |that this will do as wished. |> | |> |CGJ |> | |> |-Ursprüngliche Nachricht- |> |Von: marc fleury [mailto:[EMAIL PROTECTED]] |> |Gesendet: Dienstag, 23. April 2002 03:07 |> |An: Dave Smith |> |Cc: lsanders; Jboss-Development@Lists. Sourceforge. |> Net |> |Betreff: RE: [JBoss-dev] Workaround for CL stuff |> | |> | |> |Solution: |> | |> |When a thread goes through loadClass, in the ULR we |> "lock" with a |> |field that |> |tracks the thread. |> | |> |Another thread comes in, reaches ULR, we sync on the |> calling CL |> |(we know it) |> |we wait, this releases the lock, we keep track of |> the CL as part of this |> |"load". The first thread will always find a CL as |> no CL can be locked for |> |ever, since the thread that would reach the ULR |> would wait. First thread |> |always finishes (with reentrancy so the count must |> go on and we track the |> |fact that it is the same thread). When count |> reaches 0 we get the |> |set of CL |> |that were touched by this thread (i.e. the set of |> CLs that had threads in |> |it) and we notifyAll on each element of the set, |> start this again. |> | |> |Done (afaict), I will try to apply it to the stack |> trace below. |> | |> ||I brought this thing back to life and passed the |> URL of the orginal sun |> ||bug that they rejected. Here is a quick stack trace |> of the deadlock. |> ||Note that you should start jboss with the -Xdebug |> options so it shows |> ||you what objects that it is trying to lock. See |> below for my orginal |> ||post |> || |> || |> ||"CCRAPoll" prio=5 tid=0x8184f58 nid=0x64ec waiting |> for monitor entry |> ||[0xbb7fe000..0xbb7ffad8] |> ||at |> java.lang.ClassLoader.loadClass(ClassLoader.java:288) |> ||- waiting to lock <43a2c508> (a |> ||org.jboss.mx.loading.UnifiedClassLoader) |> ||at |> ||org.jboss.mx.loading.UnifiedClassLoader.loadClassLoc |> lly(UnifiedCla |> |ssLoader.java:180) |> ||at |> ||org.jboss.mx.loading.UnifiedLoaderRepository.loadCla |> s(UnifiedLoade |> |rRepository.java:178) |> | |> |This one would reach ULR and lock the ULR, see below |> for lock |> |<43a2c508> NOT |> |being locked. |> | |> ||at |> ||org.jboss.mx.loading.UnifiedClassLoader.loadClass(Un |> fiedClassLoade |> ||r.java:217) |> ||at |> java.lang.ClassLoader.loadClass(ClassLoader.java:255) |> ||at |> java.lang.ClassLoader.loadClassInternal(ClassLoader.ja |> a:315) |> ||- locked <43eefa48> (a |> org.jboss.mx.loading.UnifiedClassLoader) |> ||at |> ||com.entrust.toolkit.PKCS7EncodeStream.e(PKCS7EncodeS |> ream.java) |> ||at |> ||com.entrust.toolkit.PKCS7EncodeStream.f(PKCS7EncodeS |> ream.java) |> ||at |> ||com.entrust.toolkit.PKCS7EncodeStream.write(PKCS7Enc |> deStream.java) |> ||at |> com.candata.gateway.Encryption.Sign(Unknown Source) |> ||- locked <43f0c6a0> (a |> com.candata.gateway.Encryption) |> ||at |> com.candata.gateway.Encryption.createMsg(Unknown |> Source) |> ||at |> com.candata.gateway.CCRAAbstract.postMsg(Unknown |> Source) |> ||at |> com.candata.gateway.CCRAAbstract.recvMsg(Unknown |> Source) |> ||at com.candata.gateway.CCRAPoll.run(Unknown |> Source) |> ||at java.lang.Thread.run(Thread.java:484) |> || |> || |> ||"Thread-20" prio=5 tid=0x81821a8 nid=0x64f9 waiting |> for monitor entry |> ||[0xbe7fe000..0xbe7ffad8] |> ||at |> java.lang.ClassLoader.loadClass(ClassLoader.java:288) |> ||- waiting to lock <43eefa48> (a |> ||org.jboss.mx.loading.UnifiedClassLoader) |> ||at |> ||org.jboss.mx.loading.UnifiedClassLoader.loadClassLoc |> lly(UnifiedCla |> |ssLoader.java:180) |> ||at |> ||org.jboss.mx.loading.UnifiedLoaderRepository.loadCla |> s(UnifiedLoade |> |rRepository.java:178) |> | |> |thread 2 reaches here and sees a ULR under usage. It |> waits on the calling |> |UCL (which we know it is passed) and THEREFORE |> UNLOCKS <43a2c508>. |> | |> |Done |> | |> |marcf |> | |> ||at |> ||org.jboss.mx.loading.UnifiedClassLoader.loadClass(Un |> fiedClassLoade |> ||r.java:217) |> | |> ||at |> java.lang.ClassLoader.loadClass(ClassLoader.java:255) |> ||at |>
[JBoss-dev] unsuscribe
[JBoss-dev] [ jboss-Patches-547586 ] allow catalina.base
Patches item #547586, was opened at 2002-04-23 09:16 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=376687&aid=547586&group_id=22866 Category: None Group: v2.4 BETA (stable) Status: Open Resolution: None Priority: 5 Submitted By: Roland King (rolandking) Assigned to: Nobody/Anonymous (nobody) Summary: allow catalina.base Initial Comment: The current catalina connector sets the System property catalina.base equal to catalina.home. catalina.base is the place tomcat writes temporary files. Where catalina is read-only, used by lots of developers, you need to have catalina.home set to the distribution, and catalina.base set to a different, writable temporary location, specific to the user, to write files. I've modified the connector to allow an MBean attribute 'CatalinaBase' to be set. If unset, the default of whatever CatalinaHome is applies, so standard behaviour is unchanged. Expected usage is something like /home/myuser/temp I can provide a similar patch for 2.4.4 or 3.0 if required. Roland -- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=376687&aid=547586&group_id=22866 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] DTDs in binary downloads
Can we include the DTDs for a release in the binary download? I keep geting messages asking for the location of the DTDs. -dain ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-547616 ] 3.0 RC1 startup fails on NT 4.0
Bugs item #547616, was opened at 2002-04-23 15:06 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=376685&aid=547616&group_id=22866 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Ludovic Claude (ludovicc) Assigned to: Nobody/Anonymous (nobody) Summary: 3.0 RC1 startup fails on NT 4.0 Initial Comment: On Win NT, SP 6, i get the following message with JBoss3.0.0-RC1 downloaded from Sourceforge: ECHO is off. . JBoss Bootstrap Environment . JBOSS_HOME: D:\jboss-3.0.0RC1\bin\.. . JAVA: d:\jdk1.4\bin\java . JAVA_OPTS: -Dprogram.name=run.bat . CLASSPATH: ;d:\jdk1.4\lib\tools.jar;D:\jboss-3.0.0RC1\bin\run.jar . ECHO is off. . 17:04:12,062 INFO [Server] JBoss Release: JBoss-3.0.0RC1 CVSTag=JBoss_3_0_0_RC1 17:04:12,171 INFO [Server] Home Dir: D:\jboss-3.0.0RC1 17:04:12,171 INFO [Server] Home URL: file:/D:/jboss-3.0.0RC1/ 17:04:12,171 INFO [Server] Library URL: file:/D:/jboss-3.0.0RC1/lib/ 17:04:12,187 INFO [Server] Patch URL: null 17:04:12,187 INFO [Server] Server Name: default 17:04:12,187 INFO [Server] Server Home Dir: D:\jboss-3.0.0RC1\server\default 17:04:12,187 INFO [Server] Server Home URL: file:/D:/jboss-3.0.0RC1/server/default/ 17:04:12,187 INFO [Server] Server Data Dir: D:\jboss-3.0.0RC1\server\default\db 17:04:12,187 INFO [Server] Server Temp Dir: D:\jboss-3.0.0RC1\server\default\tmp 17:04:12,187 INFO [Server] Server Config URL: file:/D:/jboss-3.0.0RC1/server/default/conf/ 17:04:12,187 INFO [Server] Server Library URL: file:/D:/jboss-3.0.0RC1/server/default/lib/ 17:04:12,203 INFO [Server] Starting General Purpose Architecture (GPA)... 17:04:13,203 ERROR [Server] start failed javax.management.InstanceNotFoundException: MBeanServer cannot find MBean with ObjectName JMImplementation:service=Loade rRepository,name=Default at mx4j.server.MBeanServerImpl.findMBeanMetaData(MBeanServerImpl.java:194) at mx4j.server.MBeanServerImpl.invoke(MBeanServerImpl.java:656) at org.jboss.mx.loading.UnifiedClassLoader.(UnifiedClassLoader.java:116) at org.jboss.system.server.ServerImpl.initBootLibraries(ServerImpl.java:414) at org.jboss.system.server.ServerImpl.doStart(ServerImpl.java:257) at org.jboss.system.server.ServerImpl.start(ServerImpl.java:218) at org.jboss.Main.boot(Main.java:142) at org.jboss.Main$1.run(Main.java:375) at java.lang.Thread.run(Thread.java:536) javax.management.InstanceNotFoundException: MBeanServer cannot find MBean with ObjectName JMImplementation:service=Loade rRepository,name=Default at mx4j.server.MBeanServerImpl.findMBeanMetaData(MBeanServerImpl.java:194) at mx4j.server.MBeanServerImpl.invoke(MBeanServerImpl.java:656) at org.jboss.mx.loading.UnifiedClassLoader.(UnifiedClassLoader.java:116) at org.jboss.system.server.ServerImpl.initBootLibraries(ServerImpl.java:414) at org.jboss.system.server.ServerImpl.doStart(ServerImpl.java:257) at org.jboss.system.server.ServerImpl.start(ServerImpl.java:218) at org.jboss.Main.boot(Main.java:142) at org.jboss.Main$1.run(Main.java:375) at java.lang.Thread.run(Thread.java:536) Press any key to continue . . . -- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=376685&aid=547616&group_id=22866 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] DTDs in binary downloads
They are and always have been included in the jboss.jar: [starksm@banshee jboss-3.0.0RC1]$ jar -tf lib/jboss.jar | grep dtd org/jboss/metadata/web-app_2_3.dtd org/jboss/metadata/jboss-web.dtd org/jboss/metadata/jboss-web_3_0.dtd org/jboss/metadata/application_1_3.dtd org/jboss/metadata/jboss_2_4.dtd org/jboss/metadata/ejb-jar.dtd org/jboss/metadata/jaws_3_0.dtd org/jboss/metadata/web-app_2_2.dtd org/jboss/metadata/jboss.dtd org/jboss/metadata/ejb-jar_2_0.dtd org/jboss/metadata/connector_1_0.dtd org/jboss/metadata/application_1_2.dtd org/jboss/metadata/jaws.dtd org/jboss/metadata/jbosscmp-jdbc_3_0.dtd org/jboss/metadata/jboss_3_0.dtd org/jboss/metadata/jaws_2_4.dtd Scott Stark Chief Technology Officer JBoss Group, LLC - Original Message - From: "Dain Sundstrom" <[EMAIL PROTECTED]> To: "JBoss-dev" <[EMAIL PROTECTED]> Sent: Tuesday, April 23, 2002 8:45 AM Subject: [JBoss-dev] DTDs in binary downloads > Can we include the DTDs for a release in the binary download? > > I keep geting messages asking for the location of the DTDs. > > -dain ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-547616 ] 3.0 RC1 startup fails on NT 4.0
Bugs item #547616, was opened at 2002-04-23 15:06 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=376685&aid=547616&group_id=22866 Category: None Group: None >Status: Closed >Resolution: Rejected Priority: 5 Submitted By: Ludovic Claude (ludovicc) Assigned to: Nobody/Anonymous (nobody) Summary: 3.0 RC1 startup fails on NT 4.0 Initial Comment: On Win NT, SP 6, i get the following message with JBoss3.0.0-RC1 downloaded from Sourceforge: ECHO is off. . JBoss Bootstrap Environment . JBOSS_HOME: D:\jboss-3.0.0RC1\bin\.. . JAVA: d:\jdk1.4\bin\java . JAVA_OPTS: -Dprogram.name=run.bat . CLASSPATH: ;d:\jdk1.4\lib\tools.jar;D:\jboss-3.0.0RC1\bin\run.jar . ECHO is off. . 17:04:12,062 INFO [Server] JBoss Release: JBoss-3.0.0RC1 CVSTag=JBoss_3_0_0_RC1 17:04:12,171 INFO [Server] Home Dir: D:\jboss-3.0.0RC1 17:04:12,171 INFO [Server] Home URL: file:/D:/jboss-3.0.0RC1/ 17:04:12,171 INFO [Server] Library URL: file:/D:/jboss-3.0.0RC1/lib/ 17:04:12,187 INFO [Server] Patch URL: null 17:04:12,187 INFO [Server] Server Name: default 17:04:12,187 INFO [Server] Server Home Dir: D:\jboss-3.0.0RC1\server\default 17:04:12,187 INFO [Server] Server Home URL: file:/D:/jboss-3.0.0RC1/server/default/ 17:04:12,187 INFO [Server] Server Data Dir: D:\jboss-3.0.0RC1\server\default\db 17:04:12,187 INFO [Server] Server Temp Dir: D:\jboss-3.0.0RC1\server\default\tmp 17:04:12,187 INFO [Server] Server Config URL: file:/D:/jboss-3.0.0RC1/server/default/conf/ 17:04:12,187 INFO [Server] Server Library URL: file:/D:/jboss-3.0.0RC1/server/default/lib/ 17:04:12,203 INFO [Server] Starting General Purpose Architecture (GPA)... 17:04:13,203 ERROR [Server] start failed javax.management.InstanceNotFoundException: MBeanServer cannot find MBean with ObjectName JMImplementation:service=Loade rRepository,name=Default at mx4j.server.MBeanServerImpl.findMBeanMetaData(MBeanServerImpl.java:194) at mx4j.server.MBeanServerImpl.invoke(MBeanServerImpl.java:656) at org.jboss.mx.loading.UnifiedClassLoader.(UnifiedClassLoader.java:116) at org.jboss.system.server.ServerImpl.initBootLibraries(ServerImpl.java:414) at org.jboss.system.server.ServerImpl.doStart(ServerImpl.java:257) at org.jboss.system.server.ServerImpl.start(ServerImpl.java:218) at org.jboss.Main.boot(Main.java:142) at org.jboss.Main$1.run(Main.java:375) at java.lang.Thread.run(Thread.java:536) javax.management.InstanceNotFoundException: MBeanServer cannot find MBean with ObjectName JMImplementation:service=Loade rRepository,name=Default at mx4j.server.MBeanServerImpl.findMBeanMetaData(MBeanServerImpl.java:194) at mx4j.server.MBeanServerImpl.invoke(MBeanServerImpl.java:656) at org.jboss.mx.loading.UnifiedClassLoader.(UnifiedClassLoader.java:116) at org.jboss.system.server.ServerImpl.initBootLibraries(ServerImpl.java:414) at org.jboss.system.server.ServerImpl.doStart(ServerImpl.java:257) at org.jboss.system.server.ServerImpl.start(ServerImpl.java:218) at org.jboss.Main.boot(Main.java:142) at org.jboss.Main$1.run(Main.java:375) at java.lang.Thread.run(Thread.java:536) Press any key to continue . . . -- >Comment By: Adrian Brock (ejort) Date: 2002-04-23 15:44 Message: Logged In: YES user_id=9459 Remove MX4J from your classpath, probably in jre/lib/ext? JBoss3 now relies on the UnifiedLoaderRepository that is part of JBossMX. Regards, Adrian -- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=376685&aid=547616&group_id=22866 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Re: [JBoss-user] Save the Rabbit HoleUnifiedClassLoaders - Vote and Argue at the BugParade! - Spread the Word!
OK, ran with -Xdebug, and here are the two threads again: "main" prio=5 tid=0xc7dd80 nid=0x10b waiting for monitor entry [0x93fc000..0x93ffdc0] at java.lang.ClassLoader.loadClass(ClassLoader.java:286) - waiting to lock <32ff5d8> (a org.jboss.mx.loading.UnifiedClassLoader) at org.jboss.mx.loading.UnifiedClassLoader.loadClassLocally(UnifiedClassLoader. java:180) at org.jboss.mx.loading.UnifiedLoaderRepository.loadClass(UnifiedLoaderReposito ry.java:178) at org.jboss.mx.loading.UnifiedClassLoader.loadClass(UnifiedClassLoader.java:21 7) at java.lang.ClassLoader.loadClass(ClassLoader.java:253) at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:313) - locked <30e4010> (a org.jboss.mx.loading.UnifiedClassLoader) at java.lang.Class.forName0(Native Method) at java.lang.Class.forName(Class.java:120) at org.jboss.resource.adapter.jms.JmsManagedConnectionFactory.class$(JmsManaged ConnectionFactory.java:42) at org.jboss.resource.adapter.jms.JmsManagedConnectionFactory.(JmsManag edConnectionFactory.java:45) at java.lang.Class.newInstance0(Native Method) at java.lang.Class.newInstance(Class.java:237) at org.jboss.resource.connectionmanager.RARDeployment.startManagedConnectionFac tory(RARDeployment.java:543) at java.lang.reflect.Method.invoke(Native Method) at org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBeanDispat cher.java:284) at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:492) at org.jboss.resource.connectionmanager.BaseConnectionManager2.startService(Bas eConnectionManager2.java:286) at org.jboss.resource.connectionmanager.XATxConnectionManager.startService(XATx ConnectionManager.java:162) at org.jboss.system.ServiceMBeanSupport.start(ServiceMBeanSupport.java:162) at java.lang.reflect.Method.invoke(Native Method) at org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBeanDispat cher.java:284) at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:492) at org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceController.jav a:867) at $Proxy0.start(Unknown Source) at org.jboss.system.ServiceController.start(ServiceController.java:341) - locked <327aa68> (a org.jboss.system.ServiceController) at org.jboss.system.ServiceController.start(ServiceController.java:359) - locked <327aa68> (a org.jboss.system.ServiceController) at org.jboss.system.ServiceController.start(ServiceController.java:359) - locked <327aa68> (a org.jboss.system.ServiceController) at java.lang.reflect.Method.invoke(Native Method) at org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBeanDispat cher.java:284) at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:492) at org.jboss.util.jmx.MBeanProxy.invoke(MBeanProxy.java:174) at $Proxy9.start(Unknown Source) at org.jboss.resource.RARDeployer.start(RARDeployer.java:212) at org.jboss.deployment.MainDeployer.start(MainDeployer.java:665) at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:507) at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:470) at java.lang.reflect.Method.invoke(Native Method) at org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBeanDispat cher.java:284) at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:492) at org.jboss.util.jmx.MBeanProxy.invoke(MBeanProxy.java:174) at $Proxy4.deploy(Unknown Source) at org.jboss.deployment.scanner.URLDeploymentScanner.deploy(URLDeploymentScanne r.java:350) at org.jboss.deployment.scanner.URLDeploymentScanner.scanDirectory(URLDeploymen tScanner.java:530) at org.jboss.deployment.scanner.URLDeploymentScanner.scan(URLDeploymentScanner. java:410) - locked <36beb30> (a java.util.Collections$SynchronizedList) - locked <36be490> (a org.jboss.deployment.scanner.URLDeploymentScanner) at org.jboss.deployment.scanner.AbstractDeploymentScanner.startService(Abstract DeploymentScanner.java:237) at org.jboss.system.ServiceMBeanSupport.start(ServiceMBeanSupport.java:162) at java.lang.reflect.Method.invoke(Native Method) at org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBeanDispat cher.java:284) at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:492) at org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceController.jav a:867) at $Proxy0.start(Unknown Source) at org.jboss.system.ServiceController.start(ServiceController.java:341) - locked <327aa68> (a org.jboss.system.ServiceController) at java.lang.reflect.Method.invoke(Native Method) at org.jboss.mx.capability.ReflectedMBea
RE: [JBoss-dev] Re: [JBoss-user] Save the Rabbit HoleUnifiedClassLoaders - Vote and Argue at the BugParade! - Spread the Word!
yeah it is teh same see below |OK, ran with -Xdebug, and here are the two threads again: | |"main" prio=5 tid=0xc7dd80 nid=0x10b waiting for monitor entry |[0x93fc000..0x93ffdc0] |at java.lang.ClassLoader.loadClass(ClassLoader.java:286) |- waiting to lock <32ff5d8> (a |org.jboss.mx.loading.UnifiedClassLoader) |at |org.jboss.mx.loading.UnifiedClassLoader.loadClassLocally(UnifiedCla |ssLoader. |java:180) |at |org.jboss.mx.loading.UnifiedLoaderRepository.loadClass(UnifiedLoade |rReposito |ry.java:178) Goes through ULR, locks "monoThread". <32ff5d8> will unlock by other thread |at |org.jboss.mx.loading.UnifiedClassLoader.loadClass(UnifiedClassLoade |r.java:21 |7) | snip at java.lang.Thread.run(Thread.java:484) | |"Thread-35" prio=5 tid=0xb6c2800 nid=0x13e waiting for monitor entry |[0xb7ef000..0xb7efdc0] |at java.lang.ClassLoader.loadClass(ClassLoader.java:286) |- waiting to lock <30e4010> (a |org.jboss.mx.loading.UnifiedClassLoader) |at |org.jboss.mx.loading.UnifiedClassLoader.loadClassLocally(UnifiedCla |ssLoader. |java:180) |at |org.jboss.mx.loading.UnifiedLoaderRepository.loadClass(UnifiedLoade |rReposito |ry.java:178) Thread 2 reaches here sees the ULR under usage by thread one so thread 2 goes to sleep on the UCL which it comes from (we know it) so it realeases ... (see below) |at |org.jboss.mx.loading.UnifiedClassLoader.loadClass(UnifiedClassLoade |r.java:21 |7) |at java.lang.ClassLoader.loadClass(ClassLoader.java:253) |at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:313) |- locked <32ff5d8> (a org.jboss.mx.loading.UnifiedClassLoader) ... this lock on the unified classloader <32ff5d8> which thread one is waiting on.. done marcf PS: I am trying to get the code done but I have 3 things on my plate today, will get around to it ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Re: [JBoss-user] Save the Rabbit Hole UnifiedClassLoaders - Vote and Argue at the BugParade! - Spread the Word!
Also (and I don't know what significance this might have), but if I DON'T spawn another thread I don't get the deadlock. If I DO spawn another thread, I get the deadlock consistently. Alarik ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] DTDs in binary downloads
Yes I know they are in the jar. I mean we should include a copy in loose form. It is very useful for developers to be able to easily see the DTD files. -dain Scott M Stark wrote: > They are and always have been included in the jboss.jar: > > [starksm@banshee jboss-3.0.0RC1]$ jar -tf lib/jboss.jar | grep dtd > org/jboss/metadata/web-app_2_3.dtd > org/jboss/metadata/jboss-web.dtd > org/jboss/metadata/jboss-web_3_0.dtd > org/jboss/metadata/application_1_3.dtd > org/jboss/metadata/jboss_2_4.dtd > org/jboss/metadata/ejb-jar.dtd > org/jboss/metadata/jaws_3_0.dtd > org/jboss/metadata/web-app_2_2.dtd > org/jboss/metadata/jboss.dtd > org/jboss/metadata/ejb-jar_2_0.dtd > org/jboss/metadata/connector_1_0.dtd > org/jboss/metadata/application_1_2.dtd > org/jboss/metadata/jaws.dtd > org/jboss/metadata/jbosscmp-jdbc_3_0.dtd > org/jboss/metadata/jboss_3_0.dtd > org/jboss/metadata/jaws_2_4.dtd > > > Scott Stark > Chief Technology Officer > JBoss Group, LLC > > - Original Message - > From: "Dain Sundstrom" <[EMAIL PROTECTED]> > To: "JBoss-dev" <[EMAIL PROTECTED]> > Sent: Tuesday, April 23, 2002 8:45 AM > Subject: [JBoss-dev] DTDs in binary downloads > > > >>Can we include the DTDs for a release in the binary download? >> >>I keep geting messages asking for the location of the DTDs. >> >>-dain >> > > > > ___ > Jboss-development mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-development > ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-547616 ] 3.0 RC1 startup fails on NT 4.0
Bugs item #547616, was opened at 2002-04-23 15:06 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=376685&aid=547616&group_id=22866 Category: None Group: None Status: Closed Resolution: Rejected Priority: 5 Submitted By: Ludovic Claude (ludovicc) Assigned to: Nobody/Anonymous (nobody) Summary: 3.0 RC1 startup fails on NT 4.0 Initial Comment: On Win NT, SP 6, i get the following message with JBoss3.0.0-RC1 downloaded from Sourceforge: ECHO is off. . JBoss Bootstrap Environment . JBOSS_HOME: D:\jboss-3.0.0RC1\bin\.. . JAVA: d:\jdk1.4\bin\java . JAVA_OPTS: -Dprogram.name=run.bat . CLASSPATH: ;d:\jdk1.4\lib\tools.jar;D:\jboss-3.0.0RC1\bin\run.jar . ECHO is off. . 17:04:12,062 INFO [Server] JBoss Release: JBoss-3.0.0RC1 CVSTag=JBoss_3_0_0_RC1 17:04:12,171 INFO [Server] Home Dir: D:\jboss-3.0.0RC1 17:04:12,171 INFO [Server] Home URL: file:/D:/jboss-3.0.0RC1/ 17:04:12,171 INFO [Server] Library URL: file:/D:/jboss-3.0.0RC1/lib/ 17:04:12,187 INFO [Server] Patch URL: null 17:04:12,187 INFO [Server] Server Name: default 17:04:12,187 INFO [Server] Server Home Dir: D:\jboss-3.0.0RC1\server\default 17:04:12,187 INFO [Server] Server Home URL: file:/D:/jboss-3.0.0RC1/server/default/ 17:04:12,187 INFO [Server] Server Data Dir: D:\jboss-3.0.0RC1\server\default\db 17:04:12,187 INFO [Server] Server Temp Dir: D:\jboss-3.0.0RC1\server\default\tmp 17:04:12,187 INFO [Server] Server Config URL: file:/D:/jboss-3.0.0RC1/server/default/conf/ 17:04:12,187 INFO [Server] Server Library URL: file:/D:/jboss-3.0.0RC1/server/default/lib/ 17:04:12,203 INFO [Server] Starting General Purpose Architecture (GPA)... 17:04:13,203 ERROR [Server] start failed javax.management.InstanceNotFoundException: MBeanServer cannot find MBean with ObjectName JMImplementation:service=Loade rRepository,name=Default at mx4j.server.MBeanServerImpl.findMBeanMetaData(MBeanServerImpl.java:194) at mx4j.server.MBeanServerImpl.invoke(MBeanServerImpl.java:656) at org.jboss.mx.loading.UnifiedClassLoader.(UnifiedClassLoader.java:116) at org.jboss.system.server.ServerImpl.initBootLibraries(ServerImpl.java:414) at org.jboss.system.server.ServerImpl.doStart(ServerImpl.java:257) at org.jboss.system.server.ServerImpl.start(ServerImpl.java:218) at org.jboss.Main.boot(Main.java:142) at org.jboss.Main$1.run(Main.java:375) at java.lang.Thread.run(Thread.java:536) javax.management.InstanceNotFoundException: MBeanServer cannot find MBean with ObjectName JMImplementation:service=Loade rRepository,name=Default at mx4j.server.MBeanServerImpl.findMBeanMetaData(MBeanServerImpl.java:194) at mx4j.server.MBeanServerImpl.invoke(MBeanServerImpl.java:656) at org.jboss.mx.loading.UnifiedClassLoader.(UnifiedClassLoader.java:116) at org.jboss.system.server.ServerImpl.initBootLibraries(ServerImpl.java:414) at org.jboss.system.server.ServerImpl.doStart(ServerImpl.java:257) at org.jboss.system.server.ServerImpl.start(ServerImpl.java:218) at org.jboss.Main.boot(Main.java:142) at org.jboss.Main$1.run(Main.java:375) at java.lang.Thread.run(Thread.java:536) Press any key to continue . . . -- Comment By: Ludovic Claude (ludovicc) Date: 2002-04-23 16:50 Message: Logged In: YES user_id=254624 Bingo! That solved the problem. It would be nice to scan the classpath at startup for conflicting libraries... -- Comment By: Adrian Brock (ejort) Date: 2002-04-23 15:44 Message: Logged In: YES user_id=9459 Remove MX4J from your classpath, probably in jre/lib/ext? JBoss3 now relies on the UnifiedLoaderRepository that is part of JBossMX. Regards, Adrian -- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=376685&aid=547616&group_id=22866 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] 462 Votes for the RFE 4670071 ... We are in the Top25! ... Go ah ead ...
Could be, but the 4 above us all involve major changes to the java language or probable enormous effort over the entire jdk (excessive memory usage). At least one (generics) has been under development for years and is scheduled for 1.5. david jencks On 2002.04.23 13:29:29 -0400 Matt Humphrey wrote: > I wonder if issues classified as RFE's are less likely to be > fixed/implemented than issues classified as bugs. It seems like those > RFE's at the top of that list have been there a LONG time. > > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]] On Behalf Of Jung > , Dr. Christoph > Sent: Tuesday, April 23, 2002 8:13 AM > To: '[EMAIL PROTECTED]'; Jboss-Development > ([EMAIL PROTECTED]) > Subject: [JBoss-dev] 414 Votes for the RFE 4670071 ... We are in the > Top25! ... Go ah ead ... > > > I let it be recatecorized under RFE. Now we are in the Top25! The shown > ranking is slightly behind the actual votes (414!). We should be 6th > place now. > > http://developer.java.sun.com/developer/bugParade/top25rfes.html > > You are a great bunch of Java connaisseurs ;-) Go ahead, tell your > grandma to give her three votes! > > http://developer.java.sun.com/developer/bugParade/bugs/4670071.html > > CGJ > > > > > > > > Message > > > > size=2>I > wonder if issues classified as RFE's are less likely to be > fixed/implemented > than issues classified as bugs. It seems like those RFE's at the top of > that > list have been there a LONG time. > > > face=Tahoma size=2>-Original Message-From: > [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]] On Behalf Of > Jung , Dr. ChristophSent: Tuesday, April 23, 2002 8:13 > AMTo: '[EMAIL PROTECTED]'; Jboss-Development > ([EMAIL PROTECTED])Subject: > [JBoss-dev] 414 > Votes for the RFE 4670071 ... We are in the Top25! ... Go ah ead > ... > I let > it be > recatecorized under RFE. Now we are in the Top25! The shown > ranking is > slightly behind the actual votes (414!). We should be 6th place > now. > class=541010812-23042002> > >href="http://developer.java.sun.com/developer/bugParade/top25rfes.html";>http://developer.java.sun.com/developer/bugParade/top25rfes.html > > You are a > great > bunch of Java connaisseurs ;-) Go ahead, tell your grandma to give her > three > votes! > size=2> > >href="http://developer.java.sun.com/developer/bugParade/bugs/4670071.html";>http://developer.java.sun.com/developer/bugParade/bugs/4670071.html > > size=2>CGJ > size=2> > > ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Branch_3_0 Not Running?
That line in MainDeployer refers to a change I put in 2 days ago. I think you need a clean - or at least you need to recompile the org.jboss.deployment.DeploymentSorter class. -Larry - Original Message - From: "Hunter Hillegas" <[EMAIL PROTECTED]> To: "JBoss Dev" <[EMAIL PROTECTED]> Sent: Tuesday, April 23, 2002 11:00 AM Subject: [JBoss-dev] Branch_3_0 Not Running? > I just updated my Branch_3_0 tree and I get this on startup: > > 10:54:49,833 INFO [MainDeployer] Starting deployment of package: > file:/Users/hunter/Unix/Sources/jboss3/build/output/jboss-3.0.0RC1/lib/jboss > sx.jar > 10:54:49,991 ERROR [Server] start failed > java.lang.NoSuchMethodError > at org.jboss.deployment.MainDeployer.init(MainDeployer.java:555) > at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:495) > at java.lang.reflect.Method.invoke(Native Method) > at > org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBeanDispat > cher.java:284) > at > org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:491) > at org.jboss.util.jmx.MBeanProxy.invoke(MBeanProxy.java:174) > at $Proxy2.deploy(Unknown Source) > at > org.jboss.deployment.SARDeployer.parseXMLClasspath(SARDeployer.java:502) > at org.jboss.deployment.SARDeployer.init(SARDeployer.java:190) > at org.jboss.deployment.MainDeployer.init(MainDeployer.java:550) > at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:495) > at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:470) > at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:452) > at java.lang.reflect.Method.invoke(Native Method) > at > org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBeanDispat > cher.java:284) > at > org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:491) > at org.jboss.system.server.ServerImpl.doStart(ServerImpl.java:320) > at org.jboss.system.server.ServerImpl.start(ServerImpl.java:218) > at org.jboss.Main.boot(Main.java:142) > at org.jboss.Main$1.run(Main.java:375) > at java.lang.Thread.run(Thread.java:496) > > Am I doing something wrong or is the build fsck'd? > > Hunter > > > ___ > Jboss-development mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-development > ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] jboss-all build fails
is there anything specific we need to know about building the sources. I went through the documentation, but it says that everything should build fine. D:\Development\jboss\jboss-all\iiop\src\main\org\jboss\proxy\compiler\IIOPSt ubCo mpiler.java:252: warning: org.jboss.proxy.compiler.ProxyAssembler in org.jboss.p roxy.compiler has been deprecated new ProxyAssembler(stubClassName, ^ 4 warnings compile-rmi: [rmic] Verify has been turned on. [rmic] RMI Compiling 1 class to D:\Development\jboss\jboss-all\iiop\output\ classes [rmic] IIOP has been turned on. [rmic] error: Could not load class javax.ejb.EJBMetaData. [rmic] error: Class EJBHome contains an invalid return type. [rmic] error: Class EJBObject contains an invalid return type. [rmic] 3 errors BUILD FAILED D:\Development\jboss\jboss-all\iiop\build.xml:286: Rmic failed, messages should have been provided. Total time: 2 minutes 47 seconds ~ Namaste - I bow to the divine in you ~ Filip Hanik Software Architect [EMAIL PROTECTED] www.filip.net ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Branch_3_0 Not Running?
I just updated my Branch_3_0 tree and I get this on startup: 10:54:49,833 INFO [MainDeployer] Starting deployment of package: file:/Users/hunter/Unix/Sources/jboss3/build/output/jboss-3.0.0RC1/lib/jboss sx.jar 10:54:49,991 ERROR [Server] start failed java.lang.NoSuchMethodError at org.jboss.deployment.MainDeployer.init(MainDeployer.java:555) at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:495) at java.lang.reflect.Method.invoke(Native Method) at org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBeanDispat cher.java:284) at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:491) at org.jboss.util.jmx.MBeanProxy.invoke(MBeanProxy.java:174) at $Proxy2.deploy(Unknown Source) at org.jboss.deployment.SARDeployer.parseXMLClasspath(SARDeployer.java:502) at org.jboss.deployment.SARDeployer.init(SARDeployer.java:190) at org.jboss.deployment.MainDeployer.init(MainDeployer.java:550) at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:495) at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:470) at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:452) at java.lang.reflect.Method.invoke(Native Method) at org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBeanDispat cher.java:284) at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:491) at org.jboss.system.server.ServerImpl.doStart(ServerImpl.java:320) at org.jboss.system.server.ServerImpl.start(ServerImpl.java:218) at org.jboss.Main.boot(Main.java:142) at org.jboss.Main$1.run(Main.java:375) at java.lang.Thread.run(Thread.java:496) Am I doing something wrong or is the build fsck'd? Hunter ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Kindly Get Back To Me Please 24/04/02 21:22:29
Dear Friend, This letter may come to you as a surprise due to the fact that we have not yet met. The message could be strange but reel if you pay some attention to it. I could have notified you about it at least for the sake of your integrity. Please accept my sincere apologies. In bringing this message of goodwill to you, I have to say that I have no intentions of causing you any pains. I am Mr Bram Khumalo,son of the late rebel leader Maubane Khumalo of Angola who was killed on the 22nd of febuary 2002 . I managed to get your contact details through "The World Business Journal", a journal of the Johannesburg Chamber of Commerce in South Africa in the time I was desperately looking for a trustworthy person to assist me in this confidential business. my late father, Maubane Khumalo was able to deposit a large sum of money in differnt banks in europe My father is presently death and the movement of his family members (including me) is restricted. We are forbidden to either travel abroad or out of our localities. Presently, the US$8,500,000.00 EIGHT, MILLION, FIVE HUNDRED DOLLARS my father transfered to Netherlands is safe and is in a security firm. Before you can get access to it i have to give you the password I am therefore soliciting your help to have this money transfered into your account. before my government get wind of this fund .You know my father was a rebel leader in Angola before his death My reason for doing this is because it will be difficult for the Angolan government to trace my father's money to an individual's account, especially when such an individual has no relationship ,I decided to keep that money for my family use. At present the money is kept in a Security Company in nertherland. I am currently and temporarily living in Angola with my husband my brother has a refugee status, Moreover the political climate in Angola at the moment being so sensitive and unstable.With this password and information I will send to you, and power of attorney to the security firm, When you are ready i will give you the information needed before you can get access to the fund you will then proceed to Netherlands where the US$8,500,000.00 EIGHT, MILLION, FIVE HUNDRED DOLLARS will be given to you as payment. Alternatively, you can have the fund transferred into any account that suits you. Kindly get back to me through my email address,with all your coatacts addresses and send me your name as appear in your passport,and your Telephone and fax number.waiting to hear from you, God bless you. Yours sincerely, Bram Khumalo. ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] jboss-all build fails
I had the same problem with JDK 1.3. If you upgrade to the newest release of 1.3.1 it goes away. -dain Filip Hanik wrote: > is there anything specific we need to know about building the sources. I > went through the documentation, but it says that everything should build > fine. > > D:\Development\jboss\jboss-all\iiop\src\main\org\jboss\proxy\compiler\IIOPSt > ubCo > mpiler.java:252: warning: org.jboss.proxy.compiler.ProxyAssembler in > org.jboss.p > roxy.compiler has been deprecated > new ProxyAssembler(stubClassName, > ^ > 4 warnings > > compile-rmi: > [rmic] Verify has been turned on. > [rmic] RMI Compiling 1 class to > D:\Development\jboss\jboss-all\iiop\output\ > classes > [rmic] IIOP has been turned on. > [rmic] error: Could not load class javax.ejb.EJBMetaData. > [rmic] error: Class EJBHome contains an invalid return type. > [rmic] error: Class EJBObject contains an invalid return type. > [rmic] 3 errors > > BUILD FAILED > > D:\Development\jboss\jboss-all\iiop\build.xml:286: Rmic failed, messages > should > have been provided. > > Total time: 2 minutes 47 seconds > > > ~ > Namaste - I bow to the divine in you > ~ > Filip Hanik > Software Architect > [EMAIL PROTECTED] > www.filip.net > > > ___ > Jboss-development mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-development > ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] jboss-all build fails
This seems to be a rmic bug. I tried it yesterday and found out that rmic doesn't compile the classes if the classpath isn't identical to the output directory when the -iiop flag is set. I upgraded the jsdk from: Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.0-C) Java HotSpot(TM) Client VM (build 1.3.0-C, mixed mode) to: java version "1.4.0" Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.0-b92) Java HotSpot(TM) Client VM (build 1.4.0-b92, mixed mode) and the problem dissapeared... /d It doesn't compile -Original Message- From: Filip Hanik [mailto:[EMAIL PROTECTED]] Sent: den 23 april 2002 21:09 To: JBoss Dev Subject: [JBoss-dev] jboss-all build fails is there anything specific we need to know about building the sources. I went through the documentation, but it says that everything should build fine. D:\Development\jboss\jboss-all\iiop\src\main\org\jboss\proxy\compiler\IIOPSt ubCo mpiler.java:252: warning: org.jboss.proxy.compiler.ProxyAssembler in org.jboss.p roxy.compiler has been deprecated new ProxyAssembler(stubClassName, ^ 4 warnings compile-rmi: [rmic] Verify has been turned on. [rmic] RMI Compiling 1 class to D:\Development\jboss\jboss-all\iiop\output\ classes [rmic] IIOP has been turned on. [rmic] error: Could not load class javax.ejb.EJBMetaData. [rmic] error: Class EJBHome contains an invalid return type. [rmic] error: Class EJBObject contains an invalid return type. [rmic] 3 errors BUILD FAILED D:\Development\jboss\jboss-all\iiop\build.xml:286: Rmic failed, messages should have been provided. Total time: 2 minutes 47 seconds ~ Namaste - I bow to the divine in you ~ Filip Hanik Software Architect [EMAIL PROTECTED] www.filip.net ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] DTDs in binary downloads
The modify the build system to release them under build/output/jboss-*/etc/dtd or something. --jason Quoting Dain Sundstrom <[EMAIL PROTECTED]>: > Yes I know they are in the jar. I mean we should include a copy in > loose form. It is very useful for developers to be able to easily see > the DTD files. > > -dain > > Scott M Stark wrote: > > > They are and always have been included in the jboss.jar: > > > > [starksm@banshee jboss-3.0.0RC1]$ jar -tf lib/jboss.jar | grep dtd > > org/jboss/metadata/web-app_2_3.dtd > > org/jboss/metadata/jboss-web.dtd > > org/jboss/metadata/jboss-web_3_0.dtd > > org/jboss/metadata/application_1_3.dtd > > org/jboss/metadata/jboss_2_4.dtd > > org/jboss/metadata/ejb-jar.dtd > > org/jboss/metadata/jaws_3_0.dtd > > org/jboss/metadata/web-app_2_2.dtd > > org/jboss/metadata/jboss.dtd > > org/jboss/metadata/ejb-jar_2_0.dtd > > org/jboss/metadata/connector_1_0.dtd > > org/jboss/metadata/application_1_2.dtd > > org/jboss/metadata/jaws.dtd > > org/jboss/metadata/jbosscmp-jdbc_3_0.dtd > > org/jboss/metadata/jboss_3_0.dtd > > org/jboss/metadata/jaws_2_4.dtd > > > > > > Scott Stark > > Chief Technology Officer > > JBoss Group, LLC > > > > - Original Message - > > From: "Dain Sundstrom" <[EMAIL PROTECTED]> > > To: "JBoss-dev" <[EMAIL PROTECTED]> > > Sent: Tuesday, April 23, 2002 8:45 AM > > Subject: [JBoss-dev] DTDs in binary downloads > > > > > > > >>Can we include the DTDs for a release in the binary download? > >> > >>I keep geting messages asking for the location of the DTDs. > >> > >>-dain > >> > > > > > > > > ___ > > Jboss-development mailing list > > [EMAIL PROTECTED] > > https://lists.sourceforge.net/lists/listinfo/jboss-development > > > > > > ___ > Jboss-development mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-development > - This mail sent through IMP: http://horde.org/imp/ ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Kindly Get Back To Me Please 24/04/02 21:22:29
Hello "Dear Friends" This letter is a scam. If you give this guy any personal information, financial accounts, etc, you'll be sorry. Regards, Mac Rinehart, President Sextant Technology Consulting, Inc SEXTANT TECHNOLOGY CONSULTING is a trademark of Sextant Technology Consulting, Inc. Sextant Technology Consulting, Inc is a provider of enterprise application development services, specializing in J2EE and Oracle technologies. Mac Rinehart is the author of JavaServer Pages For Dummies and Enterprise JavaBeans For Dummies. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of brendowean Sent: Wednesday, April 24, 2002 12:22 PM To: [EMAIL PROTECTED] Subject: [JBoss-dev] Kindly Get Back To Me Please 24/04/02 21:22:29 Dear Friend, This letter may come to you as a surprise due to the fact that we have not yet met. The message could be strange but reel if you pay some attention to it. I could have notified you about it at least for the sake of your integrity. Please accept my sincere apologies. In bringing this message of goodwill to you, I have to say that I have no intentions of causing you any pains. I am Mr Bram Khumalo,son of the late rebel leader Maubane Khumalo of Angola who was killed on the 22nd of febuary 2002 . I managed to get your contact details through "The World Business Journal", a journal of the Johannesburg Chamber of Commerce in South Africa in the time I was desperately looking for a trustworthy person to assist me in this confidential business. my late father, Maubane Khumalo was able to deposit a large sum of money in differnt banks in europe My father is presently death and the movement of his family members (including me) is restricted. We are forbidden to either travel abroad or out of our localities. Presently, the US$8,500,000.00 EIGHT, MILLION, FIVE HUNDRED DOLLARS my father transfered to Netherlands is safe and is in a security firm. Before you can get access to it i have to give you the password I am therefore soliciting your help to have this money transfered into your account. before my government get wind of this fund .You know my father was a rebel leader in Angola before his death My reason for doing this is because it will be difficult for the Angolan government to trace my father's money to an individual's account, especially when such an individual has no relationship ,I decided to keep that money for my family use. At present the money is kept in a Security Company in nertherland. I am currently and temporarily living in Angola with my husband my brother has a refugee status, Moreover the political climate in Angola at the moment being so sensitive and unstable.With this password and information I will send to you, and power of attorney to the security firm, When you are ready i will give you the information needed before you can get access to the fund you will then proceed to Netherlands where the US$8,500,000.00 EIGHT, MILLION, FIVE HUNDRED DOLLARS will be given to you as payment. Alternatively, you can have the fund transferred into any account that suits you. Kindly get back to me through my email address,with all your coatacts addresses and send me your name as appear in your passport,and your Telephone and fax number.waiting to hear from you, God bless you. Yours sincerely, Bram Khumalo. ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development BEGIN:VCARD VERSION:2.1 N:Rinehart;Mac;;President FN:Mac Rinehart ORG:Sextant Technology Consulting TITLE:President TEL;WORK;VOICE:(503) 251-2855 ADR;WORK:;;7402 SE Yamhill Street;Portland;OR;97215;USA LABEL;WORK;ENCODING=QUOTED-PRINTABLE:7402 SE Yamhill Street=0D=0APortland, OR 97215=0D=0AUSA EMAIL;PREF;INTERNET:[EMAIL PROTECTED] REV:20011008T212138Z END:VCARD
Re: [JBoss-dev] DTDs in binary downloads
Jason, Do you agree that this is a good idea, or are you just suggesting a course of action for me? Does anyone dislike the idea of putting them in jboss-whatever/etc/dtd, or is some other location better? (I really don't have an opinion) -dain Jason Dillon wrote: > The modify the build system to release them under build/output/jboss-*/etc/dtd > or something. > > --jason > > > Quoting Dain Sundstrom <[EMAIL PROTECTED]>: > > >>Yes I know they are in the jar. I mean we should include a copy in >>loose form. It is very useful for developers to be able to easily see >>the DTD files. >> >>-dain >> >>Scott M Stark wrote: >> >> >>>They are and always have been included in the jboss.jar: >>> >>>[starksm@banshee jboss-3.0.0RC1]$ jar -tf lib/jboss.jar | grep dtd >>>org/jboss/metadata/web-app_2_3.dtd >>>org/jboss/metadata/jboss-web.dtd >>>org/jboss/metadata/jboss-web_3_0.dtd >>>org/jboss/metadata/application_1_3.dtd >>>org/jboss/metadata/jboss_2_4.dtd >>>org/jboss/metadata/ejb-jar.dtd >>>org/jboss/metadata/jaws_3_0.dtd >>>org/jboss/metadata/web-app_2_2.dtd >>>org/jboss/metadata/jboss.dtd >>>org/jboss/metadata/ejb-jar_2_0.dtd >>>org/jboss/metadata/connector_1_0.dtd >>>org/jboss/metadata/application_1_2.dtd >>>org/jboss/metadata/jaws.dtd >>>org/jboss/metadata/jbosscmp-jdbc_3_0.dtd >>>org/jboss/metadata/jboss_3_0.dtd >>>org/jboss/metadata/jaws_2_4.dtd >>> >>> >>>Scott Stark >>>Chief Technology Officer >>>JBoss Group, LLC >>> >>>- Original Message - >>>From: "Dain Sundstrom" <[EMAIL PROTECTED]> >>>To: "JBoss-dev" <[EMAIL PROTECTED]> >>>Sent: Tuesday, April 23, 2002 8:45 AM >>>Subject: [JBoss-dev] DTDs in binary downloads >>> >>> >>> >>> Can we include the DTDs for a release in the binary download? I keep geting messages asking for the location of the DTDs. -dain >>> >>> >>>___ >>>Jboss-development mailing list >>>[EMAIL PROTECTED] >>>https://lists.sourceforge.net/lists/listinfo/jboss-development >>> >>> >> >> >>___ >>Jboss-development mailing list >>[EMAIL PROTECTED] >>https://lists.sourceforge.net/lists/listinfo/jboss-development >> >> > > > > > - > This mail sent through IMP: http://horde.org/imp/ > > ___ > Jboss-development mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-development > ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] DTDs in binary downloads
> Do you agree that this is a good idea, or are you just suggesting a > course of action for me? Both. I would do but don't have time. > Does anyone dislike the idea of putting them in jboss-whatever/etc/dtd, > or is some other location better? (I really don't have an opinion) either etc/dtd or doc/dtd --jason - This mail sent through IMP: http://horde.org/imp/ ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Kindly Get Back To Me Please 24/04/02 21:22:29
Sorry to pollute the list but for those interested, check out. http://www.scamorama.com/ One guy was actually able to get $3 from one of the scammers! Amazing! - Anatoly Akkerman Computer Science Dept. Courant Institute of Mathematical Sciences, NYU 715 Broadway, #719 Tel: 212 998-3493 New York, NY 10003 Fax: 212 995-4123 - ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] DTDs in binary downloads
We should get the xmbean dtd in there also. Currently it is at jmx/src/resources/metadata/jboss_xmbean_1_0.dtd. If you can copy it also, great, otherwise I will try to figure it out. thanks david jencks On 2002.04.23 16:16:58 -0400 Dain Sundstrom wrote: > Jason, > > Do you agree that this is a good idea, or are you just suggesting a > course of action for me? > > Does anyone dislike the idea of putting them in jboss-whatever/etc/dtd, > or is some other location better? (I really don't have an opinion) > > -dain > > Jason Dillon wrote: > > > The modify the build system to release them under > build/output/jboss-*/etc/dtd > > or something. > > > > --jason > > > > > > Quoting Dain Sundstrom <[EMAIL PROTECTED]>: > > > > > >>Yes I know they are in the jar. I mean we should include a copy in > >>loose form. It is very useful for developers to be able to easily see > >>the DTD files. > >> > >>-dain > >> > >>Scott M Stark wrote: > >> > >> > >>>They are and always have been included in the jboss.jar: > >>> > >>>[starksm@banshee jboss-3.0.0RC1]$ jar -tf lib/jboss.jar | grep dtd > >>>org/jboss/metadata/web-app_2_3.dtd > >>>org/jboss/metadata/jboss-web.dtd > >>>org/jboss/metadata/jboss-web_3_0.dtd > >>>org/jboss/metadata/application_1_3.dtd > >>>org/jboss/metadata/jboss_2_4.dtd > >>>org/jboss/metadata/ejb-jar.dtd > >>>org/jboss/metadata/jaws_3_0.dtd > >>>org/jboss/metadata/web-app_2_2.dtd > >>>org/jboss/metadata/jboss.dtd > >>>org/jboss/metadata/ejb-jar_2_0.dtd > >>>org/jboss/metadata/connector_1_0.dtd > >>>org/jboss/metadata/application_1_2.dtd > >>>org/jboss/metadata/jaws.dtd > >>>org/jboss/metadata/jbosscmp-jdbc_3_0.dtd > >>>org/jboss/metadata/jboss_3_0.dtd > >>>org/jboss/metadata/jaws_2_4.dtd > >>> > >>> > >>>Scott Stark > >>>Chief Technology Officer > >>>JBoss Group, LLC > >>> > >>>- Original Message - > >>>From: "Dain Sundstrom" <[EMAIL PROTECTED]> > >>>To: "JBoss-dev" <[EMAIL PROTECTED]> > >>>Sent: Tuesday, April 23, 2002 8:45 AM > >>>Subject: [JBoss-dev] DTDs in binary downloads > >>> > >>> > >>> > >>> > Can we include the DTDs for a release in the binary download? > > I keep geting messages asking for the location of the DTDs. > > -dain > > > >>> > >>> > >>>___ > >>>Jboss-development mailing list > >>>[EMAIL PROTECTED] > >>>https://lists.sourceforge.net/lists/listinfo/jboss-development > >>> > >>> > >> > >> > >>___ > >>Jboss-development mailing list > >>[EMAIL PROTECTED] > >>https://lists.sourceforge.net/lists/listinfo/jboss-development > >> > >> > > > > > > > > > > - > > This mail sent through IMP: http://horde.org/imp/ > > > > ___ > > Jboss-development mailing list > > [EMAIL PROTECTED] > > https://lists.sourceforge.net/lists/listinfo/jboss-development > > > > > > ___ > Jboss-development mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-development > > ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Patches-547792 ] JNP Connection Timeout
Patches item #547792, was opened at 2002-04-23 14:26 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=376687&aid=547792&group_id=22866 Category: JBossServer Group: v2.4 (stable) Status: Open Resolution: None Priority: 5 Submitted By: Lucas McGregor (lmcgregor) Assigned to: Nobody/Anonymous (nobody) Summary: JNP Connection Timeout Initial Comment: When JNP utilizes a connection or attempts to make a connection to a server, there is no timeout value as there is with RMI. Also, the Socket class used for this connection is the standard SDK java.net.Socket, which does not have a connection timeout option as of SDK1.3. An attempt to connect to a bad address can take up to 4 minutes to timeout, and 15 minutes to timeout established connections gone dead on a default install of Solaris8. So a new SocketOpener support object is used that spawns a timer thread that will timeout connections that have not been established in a period of time. So if either a jnp.connect.timeout or jnp.sotimeout value has been set in the Context.environment (usually via the jndi.properties file), this NamingContext object will use the SocketOpener to create the socket, enforce a connect timeout, and set the soTimeout. If neither value is set, then it NamingContext will save the resources and simply call the java.net.Socket constructor. There is a patch for org.jnp.interfaces.NamingContext and a new org.jnp.interfaces.SocketOpener. Two new values can be added to the jndi.properties file: np.connect.timeout and jnp.sotimeout (both in ms). -- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=376687&aid=547792&group_id=22866 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] IIOP barfs on linux
he... did rm on the old stuff then a CLEAN CO then build (builds fine btw) then start and I get an error from IIOP. what gives? something about jacob.properties not being found Am I alone in seeing this? I want to fix the CL stuff and will try right now * * * View thread online: http://jboss.org/forums/thread.jsp?forum=66&thread=13812 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] IIOP barfs on linux
Yes, I have sent mail about this before. Does it barf or just complain? Do you see the final start message? Fransico, put in a dummy jacob.properties in default/conf when IIOP builds to avoid this mess please. --jason marc fleury wrote: >he... > >did rm on the old stuff >then a CLEAN CO >then build (builds fine btw) >then start and I get an error from IIOP. > >what gives? > >something about jacob.properties not being found > >Am I alone in seeing this? > > >I want to fix the CL stuff and will try right now >* * * > >View thread online: http://jboss.org/forums/thread.jsp?forum=66&thread=13812 > >___ >Jboss-development mailing list >[EMAIL PROTECTED] >https://lists.sourceforge.net/lists/listinfo/jboss-development > ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Re: [jetty-discuss] RE: Distributable HttpSessions - problems...
Sacha Labourey wrote: > Hello Jules, > > >>I have recently been thinking a bit about my next iteration on >>distributable HttpSessions for JBoss/Jetty. > > > BTW, does it work?!? I haven't heard you anymore since your last troubles. > I have still not been able to get two JBoss instances to recognise each other - but then I haven't tried very hard. My job finishes on th 26th, the baby is due on the 27th. I'm having a few days off, then I will be rereading all this mail and sorting out my cluster. Until then, Jules > >>My reading of the spec is that it avoids all of these issues by only >>ever allowing one copy of a session to be active at one time i.e. it >>talks about migrating sessions from one server to another - but not (as >>I recall) replicating them. > > > This is what we tend to have: only one session is active at a time. (minus side >effects) > > BTW, I think that, not only for HttpSession but for JMS, one important service is >missing from the HA framework: some kind of distributed locking mechanism (i.e. the >way to say "this belongs to me"). It wasn't needed until now but the distributed >cache/httpsession/queues/... will heavily rely on this, I am pretty sure. > > >>I see the following problems with replication : >> >>1. create/modify/destroy session events >> >> >>If a session is created/modified/removed on NodeA, should listeners >>attached to a replicant (or the replicant's context) be notified >>on NodeB ? > > > Currently, the session is removed from the cache from NodeB. The question is: Why >would you have two session active at a time? (I know: multi-frames). If we have n >frames that read and 1 frame that write (which is the case in most cases IMHO), it is >ok. But I agree: without a load-balancer supporting sticky session, we can have some >strange behaviour. > > But iMHO, we have to find a mean between performance and "correctness" in this case. >If you want to be sure that only one session is active at a time and this, without a >sticky session LB, then it means distributed locking, no other choice. > > >>If so, we open another nasty can of worms, since we need to guarantee >>the order in which modifications arrive at NodeB from other Nodes in the >>cluster. > > > That's the issue: non sticky-session LB. > > Sticky => performance > non-Sticky => distributed locking => bad performance > > I wanted to implement the locking service for a further release of JBoss. > > >>Furthermore, code that manages distributed resources via these >>notifications, and work in the webapp in non-distributed mode, may >>break. e.g. code that allocates/deallocates a distributed resource on >>session creation/destruction will have to reference count >>creation/destruction so that the resource is allocated/deallocated at >>the correct times. Even then, if a node goes down, serious problems >>arise - the system begins to look very fragile. > > > I know not enough on the servlet side to have a critical eye on this, so I trust you >;) > > >>If not, then we assume that all resources being managed by these >>listeners are distributed and not local, since notifications involving >>different parts of their lifecycle may arrive on different nodes in the >>cluster. > > > distributed? no: performance would be dead. > > >>2. activation/passivation/distribution >>--- >> >>The spec requires notification of the relevant listeners on the >>activation/passivation of a session. Ignoring the problem in (1) another >>issue still remains. Does the distribution of a session constitute a >>passivation/activation cycle ? >> >>Let's say we start a new nodeB and deploy a webapp on it. This webapp is >>already running on another nodeA. A request for this webapp somehow >>arrives at nodeB. Does nodeB notify activation listeners ? If so, then >>for the sake of symmetry, nodeA should have notified passivation >>listeners. Pursuing this to it's logical conclusion, every 'snapshot' >>and distribution of a session might need to notify first passivation >>and then activation listeners. Activation/Passivation is too expensive >>to do this frequently. > > > See above. > > >>I am interested in how others have resolved these problems, or have they >>been largely ignored in other implementations ? >> >>In writing this I am beginning to think in the following way : >> >>The spec resolves all of this by only allowing one 'active' copy of the >>session at any one time. I think that one way around these problems may >>be to assume that only one replicant at any one time is 'active'. >>Notification of change is only made on the 'active' session. The token >>designating 'activity' is passed around the cluster in the form of >>client requests. If we can avoid two requests accessing twin sessions on >>different nodes at the same time we can adhere to the spec's model of >>ho
Re: [JBoss-dev] IIOP barfs on linux
Are you using the newest version of 1.3.1 from SUN? If not, you need to upgrade. If you are using 1.4, just ignore me. Also I thought the jacob.properties was just a warning. -dain marc fleury wrote: > he... > > did rm on the old stuff > then a CLEAN CO > then build (builds fine btw) > then start and I get an error from IIOP. > > what gives? > > something about jacob.properties not being found > > Am I alone in seeing this? > > > I want to fix the CL stuff and will try right now > * * * > > View thread online: http://jboss.org/forums/thread.jsp?forum=66&thread=13812 > > ___ > Jboss-development mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-development > ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] IIOP barfs on linux
righto... I still recommend we disable IIOP by default and just turn it on with a BIG warning in the service.xml file THAT YOU SHOULD BE USING JDK1.3.1 or JDK1.4, can we keep a service.xml and sort of comment out everything? that would be useful. Francisco, can you take care of that? marcf |-Original Message- |From: [EMAIL PROTECTED] |[mailto:[EMAIL PROTECTED]]On Behalf Of Dain |Sundstrom |Sent: Tuesday, April 23, 2002 3:29 PM |To: [EMAIL PROTECTED] |Subject: Re: [JBoss-dev] IIOP barfs on linux | | |Are you using the newest version of 1.3.1 from SUN? If not, you need to |upgrade. If you are using 1.4, just ignore me. | |Also I thought the jacob.properties was just a warning. | |-dain | |marc fleury wrote: | |> he... |> |> did rm on the old stuff |> then a CLEAN CO |> then build (builds fine btw) |> then start and I get an error from IIOP. |> |> what gives? |> |> something about jacob.properties not being found |> |> Am I alone in seeing this? |> |> |> I want to fix the CL stuff and will try right now |> * * * |> |> View thread online: http://jboss.org/forums/thread.jsp?forum=66&thread=13812 > > ___ > Jboss-development mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-development > ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] IIOP barfs on linux
Can't we just require 1.3.1 or 1.4? I thought we were only going to support JDKs back one version. Also, this is only a JBoss 3.0 thing; people mostly starting to use this for development, so we can and should force users to use a more resent JDK. -dain marc fleury wrote: > righto... I still recommend we disable IIOP by default and just turn it on > with a BIG warning in the service.xml file THAT YOU SHOULD BE USING JDK1.3.1 > or JDK1.4, can we keep a service.xml and sort of comment out everything? > that would be useful. > > Francisco, can you take care of that? > > marcf > > |-Original Message- > |From: [EMAIL PROTECTED] > |[mailto:[EMAIL PROTECTED]]On Behalf Of Dain > |Sundstrom > |Sent: Tuesday, April 23, 2002 3:29 PM > |To: [EMAIL PROTECTED] > |Subject: Re: [JBoss-dev] IIOP barfs on linux > | > | > |Are you using the newest version of 1.3.1 from SUN? If not, you need to > |upgrade. If you are using 1.4, just ignore me. > | > |Also I thought the jacob.properties was just a warning. > | > |-dain > | > |marc fleury wrote: > | > |> he... > |> > |> did rm on the old stuff > |> then a CLEAN CO > |> then build (builds fine btw) > |> then start and I get an error from IIOP. > |> > |> what gives? > |> > |> something about jacob.properties not being found > |> > |> Am I alone in seeing this? > |> > |> > |> I want to fix the CL stuff and will try right now > |> * * * > |> > |> View thread online: > http://jboss.org/forums/thread.jsp?forum=66&thread=13812 > >>___ >>Jboss-development mailing list >>[EMAIL PROTECTED] >>https://lists.sourceforge.net/lists/listinfo/jboss-development >> >> > > > > ___ > Jboss-development mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-development > > > ___ > Jboss-development mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-development > ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] IIOP barfs on linux
This message "jacob.properties not found" is just a warning and can be ignored. I am about to commit some changes the will make it go away. Francisco On Tue, 23 Apr 2002, marc fleury wrote: > he... > > did rm on the old stuff > then a CLEAN CO > then build (builds fine btw) > then start and I get an error from IIOP. > > what gives? > > something about jacob.properties not being found > > Am I alone in seeing this? > > > I want to fix the CL stuff and will try right now > * * * > > View thread online: http://jboss.org/forums/thread.jsp?forum=66&thread=13812 > > ___ > Jboss-development mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-development > ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] IIOP barfs on linux
On Tue, 23 Apr 2002, Jason Dillon wrote: > Fransico, put in a dummy jacob.properties in default/conf when IIOP > builds to avoid this mess please. This doesn't work, probably because JacORB is not using the context classloader to load its resources. Wait a moment, I will commit a simple change that will make this message go away. Later on I'll look into changing JacORB so that it loads resources with the TCL. Francisco ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] IIOP barfs on linux
You may need to upgrade your JDK to build the IIOP stuff, due to an rmic bug in some older JDK versions. You should not need to upgrade you JDK to run IIOP. If it is already built then it should run. (With a "jacorb.properties not found" warning, which will go away in a few minutes...) Are you seeing something different, Marc? Francisco On Tue, 23 Apr 2002, marc fleury wrote: > righto... I still recommend we disable IIOP by default and just turn it on > with a BIG warning in the service.xml file THAT YOU SHOULD BE USING JDK1.3.1 > or JDK1.4, can we keep a service.xml and sort of comment out everything? > that would be useful. > > Francisco, can you take care of that? > > marcf > > |-Original Message- > |From: [EMAIL PROTECTED] > |[mailto:[EMAIL PROTECTED]]On Behalf Of Dain > |Sundstrom > |Sent: Tuesday, April 23, 2002 3:29 PM > |To: [EMAIL PROTECTED] > |Subject: Re: [JBoss-dev] IIOP barfs on linux > | > | > |Are you using the newest version of 1.3.1 from SUN? If not, you need to > |upgrade. If you are using 1.4, just ignore me. > | > |Also I thought the jacob.properties was just a warning. > | > |-dain > | > |marc fleury wrote: > | > |> he... > |> > |> did rm on the old stuff > |> then a CLEAN CO > |> then build (builds fine btw) > |> then start and I get an error from IIOP. > |> > |> what gives? > |> > |> something about jacob.properties not being found > |> > |> Am I alone in seeing this? > |> > |> > |> I want to fix the CL stuff and will try right now > |> * * * > |> > |> View thread online: > http://jboss.org/forums/thread.jsp?forum=66&thread=13812 > > > > ___ > > Jboss-development mailing list > > [EMAIL PROTECTED] > > https://lists.sourceforge.net/lists/listinfo/jboss-development > > > > > > ___ > Jboss-development mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-development > > > ___ > Jboss-development mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-development > ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] IIOP barfs on linux
Francisco the error that I am seeing my VM is java version "1.3.0" Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.0) Classic VM (build 1.3.0, J2RE 1.3.0 IBM build cx130-20010502 (JIT enabled: jitc) 2002-04-24 04:58:09,658 ERROR [STDERR] # 2002-04-24 04:58:09,663 ERROR [STDERR] WARNING: no properties file found! This warning can be ignored for applets. A file file called "jacorb.properties" or ".jacorb_properties" should be present in the classpath, the home directory (/home/marcf), the current directory (.) or in Javas lib directory (/opt/IBMJava2-13/jre) 2002-04-24 04:58:09,668 ERROR [STDERR] # 2002-04-24 04:58:09,692 INFO [STDOUT] JacORB V 1.4 beta 4, www.jacorb.org 2002-04-24 04:58:09,697 INFO [STDOUT] (C) Gerald Brose, FU Berlin, March 2002 2002-04-24 04:58:09,914 ERROR [org.jboss.deployment.MainDeployer] could not start deployment :file:/home/marcf/jboss-all/build/output/jboss-3.1.0alpha/server/default/deploy/iiop-service.xml org.omg.CORBA.INITIALIZE: can't instantiate default ORB implementation org.jacorb.orb.ORBSingleton minor code: 0 completed: No at org.omg.CORBA.ORB.create_impl(ORB.java:330) at org.omg.CORBA.ORB.init(ORB.java:308) at org.omg.CONV_FRAME.CodeSetComponentInfoHelper.(CodeSetComponentInfoHelper.java:12) at org.jacorb.orb.standardInterceptors.CodeSetInfoInterceptor.(CodeSetInfoInterceptor.java:41) at org.jacorb.orb.standardInterceptors.IORInterceptorInitializer.post_init(IORInterceptorInitializer.java:43) at org.jacorb.orb.ORB.interceptorInit(ORB.java:1347) at org.jacorb.orb.ORB.set_parameters(ORB.java:1262) at org.omg.CORBA.ORB.init(ORB.java:389) at org.jboss.iiop.CorbaORBService.startService(CorbaORBService.java:124) at org.jboss.system.ServiceMBeanSupport.start(ServiceMBeanSupport.java:162) at java.lang.reflect.Method.invoke(Native Method) at org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBeanDispatcher.java:284) at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:491) at org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceController.java:867) at $Proxy0.start(Unknown Source) at org.jboss.system.ServiceController.start(ServiceController.java:341) at java.lang.reflect.Method.invoke(Native Method) at org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBeanDispatcher.java:284) at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:491) at org.jboss.util.jmx.MBeanProxy.invoke(MBeanProxy.java:174) at $Proxy3.start(Unknown Source) at org.jboss.deployment.SARDeployer.start(SARDeployer.java:281) at org.jboss.deployment.MainDeployer.start(MainDeployer.java:665) at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:507) at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:470) at java.lang.reflect.Method.invoke(Native Method) at org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBeanDispatcher.java:284) at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:491) at org.jboss.util.jmx.MBeanProxy.invoke(MBeanProxy.java:174) at $Proxy4.deploy(Unknown Source) at org.jboss.deployment.scanner.URLDeploymentScanner.deploy(URLDeploymentScanner.java:405) at org.jboss.deployment.scanner.URLDeploymentScanner.scanDirectory(URLDeploymentScanner.java:586) at org.jboss.deployment.scanner.URLDeploymentScanner.scan(URLDeploymentScanner.java:465) at org.jboss.deployment.scanner.AbstractDeploymentScanner.startService(AbstractDeploymentScanner.java:237) at org.jboss.system.ServiceMBeanSupport.start(ServiceMBeanSupport.java:162) at java.lang.reflect.Method.invoke(Native Method) at org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBeanDispatcher.java:284) at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:491) at org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceController.java:867) at $Proxy0.start(Unknown Source) at org.jboss.system.ServiceController.start(ServiceController.java:341) at java.lang.reflect.Method.invoke(Native Method) at org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBeanDispatcher.java:284) at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:491) at org.jboss.util.jmx.MBeanProxy.invoke(MBeanProxy.java:174) at $Proxy3.start(Unknown Source) at org.jboss.deployment.SARDeployer.start(SARDeployer.java:281) at org.jboss.deployment.MainDeployer.start(MainDeployer.java:665) at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:507) a
RE: [JBoss-dev] IIOP barfs on linux
trust me on this... only impose VM pain on those that really want to use IIOP. marcf |-Original Message- |From: [EMAIL PROTECTED] |[mailto:[EMAIL PROTECTED]]On Behalf Of Dain |Sundstrom |Sent: Tuesday, April 23, 2002 3:59 PM |To: marc fleury |Cc: [EMAIL PROTECTED] |Subject: Re: [JBoss-dev] IIOP barfs on linux | | |Can't we just require 1.3.1 or 1.4? I thought we were only going to |support JDKs back one version. Also, this is only a JBoss 3.0 thing; |people mostly starting to use this for development, so we can and should |force users to use a more resent JDK. | |-dain | |marc fleury wrote: | |> righto... I still recommend we disable IIOP by default and just |turn it on |> with a BIG warning in the service.xml file THAT YOU SHOULD BE |USING JDK1.3.1 |> or JDK1.4, can we keep a service.xml and sort of comment out everything? |> that would be useful. |> |> Francisco, can you take care of that? |> |> marcf |> |> |-Original Message- |> |From: [EMAIL PROTECTED] |> |[mailto:[EMAIL PROTECTED]]On Behalf Of Dain |> |Sundstrom |> |Sent: Tuesday, April 23, 2002 3:29 PM |> |To: [EMAIL PROTECTED] |> |Subject: Re: [JBoss-dev] IIOP barfs on linux |> | |> | |> |Are you using the newest version of 1.3.1 from SUN? If not, you need to |> |upgrade. If you are using 1.4, just ignore me. |> | |> |Also I thought the jacob.properties was just a warning. |> | |> |-dain |> | |> |marc fleury wrote: |> | |> |> he... |> |> |> |> did rm on the old stuff |> |> then a CLEAN CO |> |> then build (builds fine btw) |> |> then start and I get an error from IIOP. |> |> |> |> what gives? |> |> |> |> something about jacob.properties not being found |> |> |> |> Am I alone in seeing this? |> |> |> |> |> |> I want to fix the CL stuff and will try right now |> |> * * * |> |> |> |> View thread online: |> http://jboss.org/forums/thread.jsp?forum=66&thread=13812 |> |>>___ |>>Jboss-development mailing list |>>[EMAIL PROTECTED] |>>https://lists.sourceforge.net/lists/listinfo/jboss-development |>> |>> |> |> |> |> ___ |> Jboss-development mailing list |> [EMAIL PROTECTED] |> https://lists.sourceforge.net/lists/listinfo/jboss-development |> |> |> ___ |> Jboss-development mailing list |> [EMAIL PROTECTED] |> https://lists.sourceforge.net/lists/listinfo/jboss-development |> | | | |___ |Jboss-development mailing list |[EMAIL PROTECTED] |https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Automated JBoss Testsuite Results: 24-April-2002
Number of tests run: 579 Successful tests: 533 Errors:30 Failures: 16 [time of test: 24 April 2002 0:37 GMT] [java.version: 1.3.0] [java.vendor: IBM Corporation] [java.vm.version: 1.3.0] [java.vm.name: Classic VM] [java.vm.info: J2RE 1.3.0 IBM build cx130-20010626 (JIT enabled: jitc)] [os.name: Linux] [os.arch: x86] [os.version: 2.4.9-31] See http://lubega.com/testarchive/ibm_jdk13_20010626 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! ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] IIOP barfs on linux
> Francisco the error that I am seeing > > > my VM is > java version "1.3.0" > Java(TM) 2 Runtime Environment, Standard Edition > (build 1.3.0) > Classic VM (build 1.3.0, J2RE 1.3.0 IBM build > cx130-20010502 (JIT enabled: jitc) > > This is a known problem in the IBM VM. Just commited some changes that deal with it. The changes implement the workaround I discussed with Jason. Could you please update your CVS tree and try again? (The warning message and all spurious JacORB output should also vanish.) Francisco * * * View thread online: http://jboss.org/forums/thread.jsp?forum=66&thread=13812 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-547831 ] JMS Redelivery doesn't work
Bugs item #547831, was opened at 2002-04-23 16:17 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=376685&aid=547831&group_id=22866 Category: JBossMQ Group: v3.0 Rabbit Hole Status: Open Resolution: None Priority: 5 Submitted By: Randy Dey-Toth (rdeytoth) Assigned to: Nobody/Anonymous (nobody) Summary: JMS Redelivery doesn't work Initial Comment: According to a posting in the forum, this is an "old bug", fixed in the 3.0 line. But it is not fixed. When using a durable persistent Topic, unacknowledged messages are only redelivered when the server is restarted. -- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=376685&aid=547831&group_id=22866 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Automated JBoss Testsuite Results: 24-April-2002
Number of tests run: 572 Successful tests: 523 Errors:32 Failures: 17 [time of test: 24 April 2002 1:40 GMT] [java.version: 1.3.0] [java.vendor: IBM Corporation] [java.vm.version: 1.3.0] [java.vm.name: Classic VM] [java.vm.info: J2RE 1.3.0 IBM build cx130-20020124 (JIT enabled: jitc)] [os.name: Linux] [os.arch: x86] [os.version: 2.4.9-31] See http://lubega.com/testarchive/ibm_jdk13_20020124 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! ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] IIOP barfs on linux
> Could you please update your CVS tree and try again? > > (The warning message and all spurious JacORB output > should also vanish.) It works, thank you marcf * * * View thread online: http://jboss.org/forums/thread.jsp?forum=66&thread=13812 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Branch_3_0 Not Running?
I can certainly do a clean CO and then build... But why wouldn't the CVS update pick it up? Hutner > From: "lsanders" <[EMAIL PROTECTED]> > Date: Tue, 23 Apr 2002 11:27:26 -0700 > To: "JBoss Dev" <[EMAIL PROTECTED]> > Subject: Re: [JBoss-dev] Branch_3_0 Not Running? > > That line in MainDeployer refers to a change I put in 2 days ago. I think > you need a clean - or at least you need to recompile the > org.jboss.deployment.DeploymentSorter class. > > -Larry > > - Original Message - > From: "Hunter Hillegas" <[EMAIL PROTECTED]> > To: "JBoss Dev" <[EMAIL PROTECTED]> > Sent: Tuesday, April 23, 2002 11:00 AM > Subject: [JBoss-dev] Branch_3_0 Not Running? > > >> I just updated my Branch_3_0 tree and I get this on startup: >> >> 10:54:49,833 INFO [MainDeployer] Starting deployment of package: >> > file:/Users/hunter/Unix/Sources/jboss3/build/output/jboss-3.0.0RC1/lib/jboss >> sx.jar >> 10:54:49,991 ERROR [Server] start failed >> java.lang.NoSuchMethodError >> at org.jboss.deployment.MainDeployer.init(MainDeployer.java:555) >> at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:495) >> at java.lang.reflect.Method.invoke(Native Method) >> at >> > org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBeanDispat >> cher.java:284) >> at >> org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:491) >> at org.jboss.util.jmx.MBeanProxy.invoke(MBeanProxy.java:174) >> at $Proxy2.deploy(Unknown Source) >> at >> org.jboss.deployment.SARDeployer.parseXMLClasspath(SARDeployer.java:502) >> at org.jboss.deployment.SARDeployer.init(SARDeployer.java:190) >> at org.jboss.deployment.MainDeployer.init(MainDeployer.java:550) >> at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:495) >> at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:470) >> at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:452) >> at java.lang.reflect.Method.invoke(Native Method) >> at >> > org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBeanDispat >> cher.java:284) >> at >> org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:491) >> at org.jboss.system.server.ServerImpl.doStart(ServerImpl.java:320) >> at org.jboss.system.server.ServerImpl.start(ServerImpl.java:218) >> at org.jboss.Main.boot(Main.java:142) >> at org.jboss.Main$1.run(Main.java:375) >> at java.lang.Thread.run(Thread.java:496) >> >> Am I doing something wrong or is the build fsck'd? >> >> Hunter >> >> >> ___ >> Jboss-development mailing list >> [EMAIL PROTECTED] >> https://lists.sourceforge.net/lists/listinfo/jboss-development >> > > > ___ > Jboss-development mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] JBoss JMS RA + SwiftMQ + Possible Problems
Hey, I have just started integrating SwiftMQ for use in my production environment at work and by doing so I have notice d that we might have some issues with the JMS RA. Clayton Wheeler responsed to a message I wrote in the SwiftMQ forums with a document he wrote about getting it to work: http://culture.iridio.com/~csw/jboss-swiftmq/ I was hoping that the JMS folks (probably Peter since he wrote it, or really anyone else familar with this stuff) could take a look at the document and see if we can nail down some of the issues (like connection.close() not closing sessions and finally drop the queue/ and topic/ prefixes from being requirements of the system). Anyone have some time to check this out and look over what needs to be done? Thanks, --jason ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] JBoss JMS RA + SwiftMQ + Possible Problems
Looking over the last bit of this doc about Xids and JBossTX... "JBossTX starts the global ID numbering from 1 each time it runs, so the global IDs are not very unique. Needless to say, this could stand some improvement." Why don't we use a org.jboss.util.id.UID or org.jboss.util.GUID here for better uniquness? Also, it refers to Tyrex, which has been integrated for a while. Does anyone know what the status of Tyrex is? Is it still being maintained? Is is a better TX manager? If so, why don't we make it the default? --jason * * * View thread online: http://jboss.org/forums/thread.jsp?forum=66&thread=13848 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Automated JBoss Testsuite Results: 24-April-2002
Number of tests run: 566 Successful tests: 542 Errors:17 Failures: 7 [time of test: 24 April 2002 3:28 GMT] [java.version: 1.3.1] [java.vendor: Blackdown Java-Linux Team] [java.vm.version: Blackdown-1.3.1_02a-FCS] [java.vm.name: Java HotSpot(TM) Client VM] [java.vm.info: mixed mode] [os.name: Linux] [os.arch: i386] [os.version: 2.4.9-31] See http://lubega.com/testarchive/blackdown_jdk131_02_native 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! ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: RE: [JBoss-dev] Re: [JBoss-user] Save the Rabbit HoleUnifiedClassLoader
OK alarik just commited the fix to CVS, please do me a favor, rm whatever you have for JBoss, cvs co jboss-all, build, run, test, let me know. thanks, hope it works for you * * * View thread online: http://jboss.org/forums/thread.jsp?forum=66&thread=13794 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [AUTOMATED] JBoss org.jboss.Shutdown does not work
= ==THIS IS AN AUTOMATED EMAIL - SEE http://www.lubega.com FOR DETAILS= = JAVA VERSION DETAILS java version "1.3.1" Java(TM) 2 Runtime Environment, Standard Edition (build Blackdown-1.3.1-02a-FCS) Java HotSpot(TM) Client VM (build Blackdown-1.3.1_02a-FCS, mixed mode) = HERE ARE THE LAST 50 LINES OF THE LOG FILE Hello, The org.jboss.Shutdown class does not seem to work. That is, the jboss_redhat_init.sh script called it and the jboss server did not stop... Please could we get this fixed... Or tell me what I should be calling to get the server shutdown... Now I will return to the old faithful method - "kill -9" See ya, Chris PS This is automated - just to make it really annoying... ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: RE: [JBoss-dev] Re: [JBoss-user] Save the Rabbit Hole UnifiedClassLoade
OK I commited the workaround for this bug. DAVE, please do me a favor and test your deployment, please let me know if it works or not. more in a separate mail. * * * View thread online: http://jboss.org/forums/thread.jsp?forum=66&thread=13431 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Diffing entire CVS branches ?
Someone (I think it might have been David) mentioned something about diffing the HEAD and 3.0 branches. Does anyone know if there is a good way todo this? I am a little concerned that some fixes are going into HEAD and are not making it into the 3.0 branch. If there is a nice tool that will do this then we can use it to send notices durring the final stages of a release. Anyone? --jason * * * View thread online: http://jboss.org/forums/thread.jsp?forum=66&thread=13850 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] [AUTOMATED] JBoss org.jboss.Shutdown does not work
Can someone look into why this started happening again. And if it is a problem on the server side can we fix it so that it accuratly reports when the server does not shutdown. Please. --jason [EMAIL PROTECTED] wrote: >= >==THIS IS AN AUTOMATED EMAIL - SEE http://www.lubega.com FOR DETAILS= >= > >JAVA VERSION DETAILS >java version "1.3.1" >Java(TM) 2 Runtime Environment, Standard Edition (build Blackdown-1.3.1-02a-FCS) >Java HotSpot(TM) Client VM (build Blackdown-1.3.1_02a-FCS, mixed mode) > >= > >HERE ARE THE LAST 50 LINES OF THE LOG FILE > >Hello, > >The org.jboss.Shutdown class does not seem to work. > >That is, the jboss_redhat_init.sh script called it and the jboss >server did not stop... > >Please could we get this fixed... > >Or tell me what I should be calling to get the server shutdown... > >Now I will return to the old faithful method - "kill -9" > >See ya, >Chris > >PS This is automated - just to make it really annoying... > >___ >Jboss-development mailing list >[EMAIL PROTECTED] >https://lists.sourceforge.net/lists/listinfo/jboss-development > ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Diffing entire CVS branches ?
Try something like this: cvs -q diff -r Branch_3_0 -r HEAD | grep RCS It's not the best, but it gets the job done. -Larry > Someone (I think it might have been David) mentioned something about diffing the HEAD and 3.0 branches. > > Does anyone know if there is a good way todo this? > > I am a little concerned that some fixes are going into HEAD and are not making it into the 3.0 branch. If there is a nice tool that will do this then we can use it to send notices durring the final stages of a release. > > Anyone? > > --jason > * * * > > View thread online: http://jboss.org/forums/thread.jsp?forum=66&thread=13850 > > ___ > Jboss-development mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-development > ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Workaround for JUNG's RFE and load deadlock
So I commited a workaround for the RFE that jung has with SUN. Essentially it all amounts to making the ULR mono-threaded and relinqueshing the locks as we go. It's pretty simple stuff since it is a subset of the locking in the container. Plus it is the kind of stuff I get off with :) Ok seriously now, the stuff boots, however *i haven't tested it*. I know there is some multithreaded loading in the server because it locked when I put a buggy "workaround" and it comes from the clustering code BUT since I didn't have a reproducible case of deadlock in my code I haven't tested. I don't know if this actually fixes anything, I just think it does. Dave, Alarik, can I ask you guys to test if you deadlock. please update from CVS for the latest JMX code. thanks please let me know on this thread if the stuff doesn't work (could very well be since, again, I haven't tested it with a real deadlock). most likely I will need a few iterations on this :) marcf PS: instructions remove your current codebase cvs co jboss-all build/sh build.sh cd output/jboss3.1... put your files in the deploy dir bin/sh run.sh report what goes on * * * View thread online: http://jboss.org/forums/thread.jsp?forum=66&thread=13851 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Workaround for JUNG's RFE and load deadlock
> > >PS: instructions >remove your current codebase >cvs co jboss-all > I think this is extreme, but certainly won't hurt > >build/sh build.sh > If you choose not to re-checkout then: build/build.sh clean most =) --jason ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Diffing entire CVS branches ?
I've been using cvs -q diff -r Branch_3_0 -r HEAD which works pretty well except that any changed file, the versions differ, so you get a lot of spurious crap. I was about to ask you if there was something we could do with cvs keyword expansion so only real differences showed up. david jencks On 2002.04.23 22:49:01 -0400 Jason Dillon wrote: > Someone (I think it might have been David) mentioned something about > diffing the HEAD and 3.0 branches. > > Does anyone know if there is a good way todo this? > > I am a little concerned that some fixes are going into HEAD and are not > making it into the 3.0 branch. If there is a nice tool that will do this > then we can use it to send notices durring the final stages of a release. > > Anyone? > > --jason > * * * > > View thread online: http://jboss.org/forums/thread.jsp?forum=66&thread=13850 > > ___ > Jboss-development mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-development > > ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Automated JBoss Testsuite Results: 24-April-2002
Number of tests run: 579 Successful tests: 555 Errors:15 Failures: 9 [time of test: 24 April 2002 5:13 GMT] [java.version: 1.3.1] [java.vendor: Blackdown Java-Linux Team] [java.vm.version: Blackdown-1.3.1-02a-FCS] [java.vm.name: Classic VM] [java.vm.info: green threads, nojit] [os.name: Linux] [os.arch: i386] [os.version: 2.4.9-31] See http://lubega.com/testarchive/blackdown_jdk131_02_green 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! ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Diffing entire CVS branches ?
Also, in Ant 1.5 there is a new task that spits out a xml formatted report. http://cvs.apache.org/viewcvs/~checkout~/jakarta-ant/docs/manual/CoreTasks/cvstagdiff.html Dave * * * View thread online: http://jboss.org/forums/thread.jsp?forum=66&thread=13850 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Jetty, Servlet Filters & url-pattern="/*"
Hey, I am not sure if this is a real problem or if I just have my webapp misconfigured... but it looks like there is a problem outside of my config. I have been trying to setup a test environemnt for SiteMesh. SiteMesh uses servlet filters to apply the decorator pattern to jsp pages... which is very, very cool. But, I am having throuble getting it to work on urls like http://localhost:8080, though it works fine when you go to http://localhost:8080. It looks like Jetty (or some component working with jetty) is not applying the filter that I have set using the following: sitemesh /* I have also tried addind an explicit filter for root: sitemesh / But it still does not work. So I checked the 2.3 spec, section 6.2.4 refernces this text: [the filter]... is applied to all the servlets and static content pages in the web application, because every request URI matches the /* URL pattern. So it seems to me that this '/*' pattern should also be applied to http://localhost:8080/. Or am I wrong? Does anyone know if this is easy to fix inside of the Jetty compnents and/or if there is a short-term fix to avoid this bug? --jason * * * View thread online: http://jboss.org/forums/thread.jsp?forum=66&thread=13857 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Diffing entire CVS branches ?
Great! So we can build web pages with xslt to make this readable. Do you know what the timeline is for the next Ant release? --jason Quoting Dave <[EMAIL PROTECTED]>: > Also, in Ant 1.5 there is a new task that spits out a xml > formatted report. > > http://cvs.apache.org/viewcvs/~checkout~/jakarta- ant/docs/manual/CoreTasks/cvstagdiff.html > > Dave > > * * * > > View thread online: > http://jboss.org/forums/thread.jsp?forum=66&thread=13850 > > ___ > Jboss-development mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-development > - This mail sent through IMP: http://horde.org/imp/ ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Re: Jetty, Servlet Filters & url-pattern="/*"
It would appear this also happens with directories under /, like http://localhost:8080:/test where http://localhost:8080:/test/index.jsp works fine. =( --jason * * * View thread online: http://jboss.org/forums/thread.jsp?forum=66&thread=13857 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Automated JBoss Testsuite Results: 24-April-2002
Number of tests run: 566 Successful tests: 540 Errors:17 Failures: 9 [time of test: 24 April 2002 7:27 GMT] [java.version: 1.3.1] [java.vendor: Sun Microsystems Inc.] [java.vm.version: 1.3.1-b24] [java.vm.name: Java HotSpot(TM) Server VM] [java.vm.info: mixed mode] [os.name: Linux] [os.arch: i386] [os.version: 2.4.9-31] See http://lubega.com/testarchive/sun_jdk131 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! ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [AUTOMATED] JBoss org.jboss.Shutdown does not work
= ==THIS IS AN AUTOMATED EMAIL - SEE http://www.lubega.com FOR DETAILS= = JAVA VERSION DETAILS java version "1.3.1" Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.1-b24) Java HotSpot(TM) Server VM (build 1.3.1-b24, mixed mode) = HERE ARE THE LAST 50 LINES OF THE LOG FILE Hello, The org.jboss.Shutdown class does not seem to work. That is, the jboss_redhat_init.sh script called it and the jboss server did not stop... Please could we get this fixed... Or tell me what I should be calling to get the server shutdown... Now I will return to the old faithful method - "kill -9" See ya, Chris PS This is automated - just to make it really annoying... ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
SV: [JBoss-dev] Re: Jetty, Servlet Filters & url-pattern="/*"
Hi Jason According to my experience it is only applied on the root of your web application like http://localhost:8080/test if your web app is deployed to '/test' and the filter set to '/*'. But the entire filter part of 2.3 in my opinion suffers from 1.0s disease it is slightly underspecified and I esspecially hate the strange way to set up chaining and load sequences in the filter. Frankly it reminds me of the servlet 2.0 state of affairs. I have however been able to map Tomcat (Not Jetty I know!) to use the root context of the application to deploy my application by fiddling with Tomcat's server configuration. I don't think it is doable from the web.xml of an web app. Best regards Mikael > -Oprindelig meddelelse- > Fra: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]]På > vegne af Jason > Dillon > Sendt: 24. april 2002 08:26 > Til: [EMAIL PROTECTED] > Emne: [JBoss-dev] Re: Jetty, Servlet Filters & url-pattern="/*" > > > It would appear this also happens with directories under /, > like http://localhost:8080:/test where > http://localhost:8080:/test/index.jsp works fine. > > =( > > --jason > > * * * > > View thread online: > http://jboss.org/forums/thread.jsp?forum=66&thread=13857 > > ___ > Jboss-development mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-development > ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
AW: [JBoss-dev] Re: [JBoss-user] Save the Rabbit Hole UnifiedClassLoaders - Vote and Argue at the BugParade! - Spread the Word!
Yes, that´s what the deadlock (hopefully) was about ... two threads loading classes simultaneously ... I think that Marc now has a promising (and ingenious, I didn´t think about the synchronized - synchronized() relation the whole time!) workaround. CGJ -Ursprüngliche Nachricht- Von: Alarik Myrin [mailto:[EMAIL PROTECTED]] Gesendet: Dienstag, 23. April 2002 19:16 An: marc fleury; [EMAIL PROTECTED] Betreff: RE: [JBoss-dev] Re: [JBoss-user] Save the Rabbit Hole UnifiedClassLoaders - Vote and Argue at the BugParade! - Spread the Word! Also (and I don't know what significance this might have), but if I DON'T spawn another thread I don't get the deadlock. If I DO spawn another thread, I get the deadlock consistently. Alarik ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: SV: [JBoss-dev] Re: Jetty, Servlet Filters & url-pattern="/*"
I just tried deploying under /foo and got the same results. =( I have alos cross posted the main thread to jetty-discuss. --jason - This mail sent through IMP: http://horde.org/imp/ ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] 414 Votes for the RFE 4670071 ... We are in the Top25! ... Go ahead ...
Title: Nachricht I let it be recatecorized under RFE. Now we are in the Top25! The shown ranking is slightly behind the actual votes (414!). We should be 6th place now. http://developer.java.sun.com/developer/bugParade/top25rfes.html You are a great bunch of Java connaisseurs ;-) Go ahead, tell your grandma to give her three votes! http://developer.java.sun.com/developer/bugParade/bugs/4670071.html CGJ
RE: [JBoss-dev] 414 Votes for the RFE 4670071 ... We are in the Top25! ... Go ah ead ...
Title: Message I wonder if issues classified as RFE's are less likely to be fixed/implemented than issues classified as bugs. It seems like those RFE's at the top of that list have been there a LONG time. -Original Message-From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Jung , Dr. ChristophSent: Tuesday, April 23, 2002 8:13 AMTo: '[EMAIL PROTECTED]'; Jboss-Development ([EMAIL PROTECTED])Subject: [JBoss-dev] 414 Votes for the RFE 4670071 ... We are in the Top25! ... Go ah ead ... I let it be recatecorized under RFE. Now we are in the Top25! The shown ranking is slightly behind the actual votes (414!). We should be 6th place now. http://developer.java.sun.com/developer/bugParade/top25rfes.html You are a great bunch of Java connaisseurs ;-) Go ahead, tell your grandma to give her three votes! http://developer.java.sun.com/developer/bugParade/bugs/4670071.html CGJ
RE: [JBoss-user] RE: [JBoss-dev] 414 Votes for the RFE 4670071 ... We are in the Top25! ... Go ah ead ...
Title: Message problem is, sun doesn't think it's a bug in the first place, so if it's classified as a bug it will never get fixed -Original Message-From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Matt HumphreySent: Tuesday, April 23, 2002 1:29 PMTo: 'Jung , Dr. Christoph'; [EMAIL PROTECTED]; 'Jboss-Development'Subject: [JBoss-user] RE: [JBoss-dev] 414 Votes for the RFE 4670071 ... We are in the Top25! ... Go ah ead ... I wonder if issues classified as RFE's are less likely to be fixed/implemented than issues classified as bugs. It seems like those RFE's at the top of that list have been there a LONG time. -Original Message-From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Jung , Dr. ChristophSent: Tuesday, April 23, 2002 8:13 AMTo: '[EMAIL PROTECTED]'; Jboss-Development ([EMAIL PROTECTED])Subject: [JBoss-dev] 414 Votes for the RFE 4670071 ... We are in the Top25! ... Go ah ead ... I let it be recatecorized under RFE. Now we are in the Top25! The shown ranking is slightly behind the actual votes (414!). We should be 6th place now. http://developer.java.sun.com/developer/bugParade/top25rfes.html You are a great bunch of Java connaisseurs ;-) Go ahead, tell your grandma to give her three votes! http://developer.java.sun.com/developer/bugParade/bugs/4670071.html CGJ
Re: [JBoss-dev] Diffing entire CVS branches ?
Shit so does XmlProperty.. but still no app level xml include? Or is it that I just can not find it? --jason * * * View thread online: http://jboss.org/forums/thread.jsp?forum=66&thread=13850 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Diffing entire CVS branches ?
CvsChangeLog also looks promising. --jason * * * View thread online: http://jboss.org/forums/thread.jsp?forum=66&thread=13850 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
