Problem during classloading on certain classloaders
---
Key: JBREM-53
URL: http://jira.jboss.com/jira/browse/JBREM-53
Project: JBoss Remoting
Type: Bug
Reporter: Jeff Haynie
Assigned to: Jeff Haynie
Problem
[ http://jira.jboss.com/jira/browse/JBREM-49?page=history ]
Jeff Haynie closed JBREM-49:
Resolution: Done
Committed to Branch_3_2
Problem with loading an array class remotely
Key: JBREM-49
Problem with loading an array class remotely
Key: JBREM-49
URL: http://jira.jboss.com/jira/browse/JBREM-49
Project: JBoss Remoting
Type: Bug
Reporter: Jeff Haynie
Assigned to: Tom Elrod
Problem when you try
://sourceforge.net/tracker/?func=detailatid=376685aid=871649group_id=22866
Category: JBossMX
Group: v3.2
Status: Closed
Resolution: Fixed
Priority: 5
Submitted By: Jeff Haynie (jhaynie)
Assigned to: Jeff Haynie (jhaynie)
Summary: Problem with source of JMX Notifications
Initial Comment
Scott M Stark eloquently wrote the following on 1/6/2004 1:44 PM:
The MBeanTracker appears to be a composite of the proxy factory and
lookup
services currently used and is where the NAT configuration would have to
be I would guess. Does this layer support:
- A client side interceptor stack
-
We use http://wrapper.tanukisoftware.org/doc/english/ with JBoss on both
Windows and Linux and it handles all of this out-of-the-box (restart
failure, retry logic, etc.)
I would recommend it instead of rolling your own. They've even got a
MBean for managing restarts, etc.
I'll be glad to
We also have written a native (via JNI) library for getting all the
system level information such as CPU load, handles, threads, memory,
etc. and we have a framework that fires JMX snapshot notifications
(configurable). Our management server then monitors these snapshots and
our analytics
you're ignoring him.
Jeff
Ivelin Ivanov wrote:
Would it use native code to restart the JBoss services
or would it just ask the deployers to undeploy and
redeploy all services?
Ivelin
--- Jeff Haynie [EMAIL PROTECTED] wrote:
We use
http://wrapper.tanukisoftware.org/doc/english/ with
JBoss
We have a customer that needs to use JBoss Remoting / JMX Remoting in a
fairly complex, although not unusual, network configuration.
Right now, we don't well support dynamic / NAT traversals for remoting
either in detection or transport. We basically send the local machines
address (which
C:\cvs\jboss-3.2\buildant
Buildfile: build.xml
_buildmagic:init:
BUILD FAILED
C:\cvs\jboss-3.2\tools\etc\buildmagic\buildmagic.ent:25:
Unsupported Ant version:
Apache Ant version 1.6.0 compiled on December 18 2003
Please install a version which is compatible with Ant 1.5.
Total time: 1
version:
${ant.version}
Please install a version which is compatible with Ant
${buildmagic.ant.baseversion}.
/fail
Regards,
Adrian
On Mon, 2004-01-05 at 22:59, Jeff Haynie wrote:
C:\cvs\jboss-3.2\buildant
Buildfile: build.xml
_buildmagic:init:
BUILD FAILED
C:\cvs\jboss-3.2\tools\etc
.
Scott Stark
Chief Technology Officer
JBoss Group, LLC
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Jeff
Haynie
Sent: Monday, January 05, 2004 2:04 PM
To: [EMAIL PROTECTED]
Subject: [JBoss-dev] Remoting and NAT
Obscure question:
Is there a way to instruct the ServiceController to unload an MBean (as
near) at the end of the lifecycle of all the other mbeans?
Use case:
In remoting, ideally you want to have the remoting framework load at the
last possible minute so that notifications from all the other
I've commited a handful of fixes/improvements to remoting and
jmx-remoting I've found during testing and profiling our application
related to memory growth and dangling threads.
- I've added a slight improvement to the multicast detector for caching
the detection notification and
Tom/Scott,
The modules remoting and jmx-remoting weren't integrated into the main
build and weren't being built into the main distribution. I fixed this
and also setup the default detector/connectors to be automatically
deployed as part of the default jboss-service.xml.
I've committed this
to be a seperate sar in deploy for easy removal if
they are not wanted.
Scott Stark
Chief Technology Officer
JBoss Group, LLC
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Jeff
Haynie
Sent: Saturday, January 03
need to be a seperate sar in deploy for easy removal if
they are not wanted.
Scott Stark
Chief Technology Officer
JBoss Group, LLC
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Jeff
Haynie
Sent: Saturday
It would be nice to be configurable as well.
I.E.
Apache Coyote/1.0 JBoss/3.2.3 OEM/ISV/1.0
Jeff
- Original Message -
From: SourceForge.net [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Wednesday, December 10, 2003 11:31 PM
Subject: [JBoss-dev] [ jboss-Feature Requests-858049 ] JBoss
I thought we were using the doug lea's concurrent ThreadPool
(PooledExecutor) in most places?
- Original Message -
From: Tom Elrod [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Monday, December 01, 2003 2:04 AM
Subject: [JBoss-dev] several ThreadPool classes
I need a thread pool and
JSR160 is partially implemented in HEAD and talks to Jboss Remoting API.
It shouldn't be too much longer to have a full implementation working.
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Luke
Taylor
Sent: Tuesday, June 17, 2003 2:44 PM
To: [EMAIL
the other way like you had
mentioned?
Secondly, what is really going to be cool when we expose
this via AOP
remoting... Bill, what are your plans for that?
Thanks,
Nathan
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
Jeff Haynie
Jboss Remoting callbacks are in - I wil commit in the next day or so
when tom and I finish testing.
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Bill
Burke
Sent: Thursday, April 03, 2003 6:06 PM
To: [EMAIL PROTECTED]
Subject: RE: [JBoss-dev] JB4DR1
... Bill, what are your plans for that?
Thanks,
Nathan
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Jeff
Haynie
Sent: Thursday, April 03, 2003 8:21 PM
To: [EMAIL PROTECTED]
Subject: RE: [JBoss-dev] JB4DR1 Deadline MAY 26
Jboss Remoting callbacks
I'm not sure...The problem with Versioning and Remoting is that a proxy
object is required. You have to return a different object than the one
actually constructed.
You getting me? I'm not sure if this can be done within bytecode
manipulation. I'll have to ask the Javassist guys.
Why?
On IE6.0 on W2K, the drop downs on the front page, such as
Forums...Development, doesn't do anything. However, if I click on
Forums... It goes to the main forums page.
Also, when I try and login, I get a Logging you in, hang tight! and
the page never returns The IE globe spins to infinity
Bill,
This is fabulous stuff. Good job.
Is there a way we might be able to use the AOP xml to dynamically do
your example below (as well as the clustered and remoting) for POJOs
during construction time? In other words, could you not have an
interceptor on a constructor pointcut that would do
Famous quote from Sun on News.com:
http://news.com.com/2100-1013-993471.html?tag=fd_top
'Phipps said Wednesday that making the compliance test available will
make it clear that Sun does not want to intentionally obstruct JBoss
Group's efforts to gain J2EE compliance.
However, Phipps said he
Compression level on the cvs server
-z9 is the max
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
Nathan Phelps
Sent: Tuesday, March 18, 2003 12:19 PM
To: [EMAIL PROTECTED]
Subject: RE: Re[2]: [JBoss-dev] JBoss-3.2 build issues
I've never been able
You're on fire! Go go Bill
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Bill
Burke
Sent: Tuesday, March 18, 2003 7:15 PM
To: Jboss-Dev
Subject: [JBoss-dev] AOP Clustering 1st iteration
Again, either an AOP instrumented or non-AOP instrumented pojo
There's a difference between build-time dependencies and run-time
dependencies.
To build the SOAP connector, it requires Axis to build remoting.
However, during execution, if you don't have Axis on your classpath, it
won't be available, and won't cause a run-time dependencies.
The intent is
No, this just allows remote jboss servers to be discovered by browsing
the JNDI tree instead of multicast.
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
David Jencks
Sent: Saturday, March 08, 2003 7:59 AM
To: [EMAIL PROTECTED]
Subject: RE: [JBoss-dev]
Tom did this the other day when he integrated the JNDI detector into
remoting, but just for source build dependencies only.
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
Jason Dillon
Sent: Saturday, March 08, 2003 4:12 PM
To: [EMAIL PROTECTED]
Subject:
Is there any reason we need to hardcode the jars that are included in
the lib directory? (in org.jboss.Main)
Can't we just put all the *.jars under root/lib into the class loader
on boot?
Jeff
---
This SF.net email is sponsored by: Etnus,
, March 8, 2003, at 05:02 AM, Jeff Haynie wrote:
Ok, this makes sense ..
can't we list even if remote using WebDav?
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
Jason Dillon
Sent: Friday, March 07, 2003 4:07 PM
To: [EMAIL PROTECTED]
Subject: Re
-dev] Jboss Boot lib jars
Is jboss-cache required to boot the server?
--jason
On Saturday, March 8, 2003, at 05:21 AM, Jeff Haynie wrote:
Because bela's jboss-cache is in lib/ on the build, but not configured
in Main. So, I had to chase that down a bit before looking at the
source
I'm working on this ... Should have something sometime soon.
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of marc
fleury
Sent: Friday, March 07, 2003 4:21 PM
To: [EMAIL PROTECTED]
Subject: RE: [JBoss-dev] jboss remoting
I'm not sure if it so much of
Add jboss-common-client.jar on your path
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of hae
loong chan
Sent: Wednesday, March 05, 2003 8:36 PM
To: [EMAIL PROTECTED]
Subject: [JBoss-dev] Re: Error ..
hi all,
After deployed firstejb.jar successfully
: Tuesday, March 04, 2003 10:32 AM
To: Jboss-Dev
Subject: [JBoss-dev] jboss remoting
Hey all,
I can see why David was so excited about the new JBoss Remoting
framework that Jeff Haynie and Tom Elrod wrote. I had dinner with Jeff
in Boston last night and over a few beers he discussed in detail
What's the reason to support JDK1.3 -- just asking, not against it.
We've been using 1.4.1 for a good while now and it seems to be much
better in performance and stability.
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
danch
Sent: Friday, February
The problem really is with me - I fess up. Bill's mad because I broke
the build twice this week by inadvertantly checking in code (throwing an
exception that is the new overloaded version in 1.4) that only compiles
on 1.4. Unfortunately, my whole work and home environment *DO* require
1.4 and
If you like Eclipse, IntelliJ blows it away. It's not free, but cheap
and much more mature than Eclipse. I used Eclipse, but enjoy IntelliJ
much more. (Not trying to start a holy war, just giving you another
option to look at it you enjoy Eclipse...)
-Original Message-
From: [EMAIL
I'm getting a bunch of these errors while building
fresh checkout of jboss-mx from HEAD. Anyone have any ideas?
[execmodules]
C:\cvs-jboss-head\jboss-mx\jmx\src\main\org\jboss\mx\metadata\JBossXMBean10.java:37:
package org.dom4j does not exist[execmodules] import
Title: Message
OK,
this is fixed.
-Original Message-From:
[EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
Jeff HaynieSent: Friday, February 21, 2003 12:54
PMTo: [EMAIL PROTECTED]Subject:
RE: [JBoss-dev] Jboss-mx errors
i
did a brand new checkout into
I think AOP has a separate functional requirement from Remoting and
should be separated.
Remoting depends (potentially) on AOP.
AOP should be the instrumenting, invocation and interception framework.
Remoting should then add any semantics for transport and discovery.
Individual subsystems
Yes - but you guys don't seem to buy into it otherwise you won't be
talking about where and how tx or remoting should go into AOP.
Maybe I'm missing something.
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Bill
Burke
Sent: Friday, February 21, 2003
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Behalf Of
Jeff Haynie
Sent: Friday, February 21, 2003 6:15 PM
To: [EMAIL PROTECTED]
Subject: RE: [JBoss-dev] TxInterceptor split is really really bad
Yes - but you guys don't seem to buy into it otherwise you
jencks
On 2003.02.19 00:54 Jeff Haynie wrote:
I commited the jboss-remoting code tonight. There is now a separate
module named jboss-remoting, and it is aliased in jboss-mx and
jboss-head (because mx needs it).
It looks like all 3 modules are compiling fine. There is more work
Yes, this is my fault and will resolve.
My IDE automatically puts those at the top of every new class and I have
to remember to delete them and replace for JBOSS code.
This code is part of JBOSS and not part of Vocalocity.
I will remove ASAP.
Jeff
-Original Message-
From: [EMAIL
Title: Message
I commited the
jboss-remoting code tonight. There is now a separate module named
jboss-remoting, and it is aliased in jboss-mx and jboss-head (because mx needs
it).
It looks like all 3
modules are compiling fine. There is more work that Tom and I are doing
this week to try
Why don't we just create on enter and then clear thread locals in the
finally of the run in the threadpool? If there's any thread local
variables in the executing thread, they could then be set in the
executing thread pool thread, and then the thread pool thread could
remove them upon exiting?
What happens in the case the executing thread doesn't know he's
executing on a thread pool thread - such as that another caller is
calling a method on an object via a thread pool? In this case, you
thread local variables wouldn't work -- in which case, thread locals are
pointless, no?
Is this is JOKE? I think I'd prefer to spend my time on AOP / JB4.
geez.. ... ;)
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]] On Behalf Of
SourceForge.net
Sent: Wednesday, January 15, 2003 3:27 PM
To: [EMAIL PROTECTED]
Subject: [JBoss-dev] [ jboss-Bugs-668710 ]
52 matches
Mail list logo
