I have added a new module called jboss-jmx-remoting32 to CVS in order to
make it a little easier to work on jmx, remoting and jmx-remoting
(without having to get and build the whole jboss tree). This is only
for the 3.2 branch, so will have to use the following for checkout:
cvs checkout -r
The class loading failure is due the associated deployment being
destroyed and the class loader removed from the repository. The
class loader reference is invalid, so look into why the class
loader is being used after its deployment is destroyed.
We need to get the web integration tests running
Just have the JSR77 mbeans expose a flattened version of a
subset of the stats as an mbean. The JSR77 stats interfaces
will not map to usable mbean attributes because they are aggregate
objects like:
javax.management.j2ee.statistics.RangeStatistic extends Statistic
{
public String getName();
Hello Rémy,
Would it be possible to switch to TC 5 for JB 3.2.4 (assuming there's
someone to test and bugfix the clustering code) ? I did add the JSR 77
stats, so the web console works and has the same stats as with TC 4.1 now.
It is not my decision but in a recent e-mail (virtual hosting)
Yes, I remember exactly:
- I know Java
- I don't know DHTML
:)
If you want to reimplement it in DTHML and check on the server side if the
browser supports it and send the appropriate version of the tree, fine!
Cheers,
sacha
- Original Message -
From: Ivelin Ivanov [EMAIL
Scott M Stark wrote:
The class loading failure is due the associated deployment being
destroyed and the class loader removed from the repository. The
class loader reference is invalid, so look into why the class
loader is being used after its deployment is destroyed.
This was working before the
Something wrong with /cvsroot/jboss/build/jboss/etc/root ???
cvs update -P -d (in directory X:\jboss\jboss-3.2\)
cvs server: Updating .
cvs server: cannot open directory /cvsroot/jboss/build/jboss/etc/root: No
such file or directory
cvs server: skipping directory
*CVS exited normally with
You need to do a fresh checkout.
-- Juha
On Wed, 7 Jan 2004, Dimitris Andreadis wrote:
Something wrong with /cvsroot/jboss/build/jboss/etc/root ???
cvs update -P -d (in directory X:\jboss\jboss-3.2\)
cvs server: Updating .
cvs server: cannot open directory
Sacha Labourey wrote:
Hello Rémy,
Would it be possible to switch to TC 5 for JB 3.2.4 (assuming there's
someone to test and bugfix the clustering code) ? I did add the JSR 77
stats, so the web console works and has the same stats as with TC 4.1 now.
It is not my decision but in a recent e-mail
I would qualify JMX 1.2 as a major addition, so maybe it
would be a good
idea to change the numbering scheme (3.2.3 was a minor update, 3.2.2
wasn't, and 3.2.4 isn't going to be one either).
I agree, I didn't expected the JMX 1.2 migration, that was quite a big move,
I was impressed by so
Hello!
Am Mit, den 07.01.2004 schrieb Remy Maucherat um 07:01:
IMO, the TC 5 code which I ported should be kept in sync (it's in
src/main/org/jboss/web/tomcat/tc5/session). Also, would it be possible
to test it so that the TC 5 integration has the same features as TC 4.1
? I don't quite
And, no Marc, this isn't relegated to just JMX as Bill
demonstrates with AOP Remoting. This should be used for JMS,
EJB and all the other subsystem layers. ;)
That is great, the AOP remoting part is the future. But the best of
this will come as the invoker layer for proxies of EJB
Was my fault for not giving more notice. I e-mailed a few people
directly before the commit, but should have notified the list before hand.
Will be working on the classloader problem later today (sorry for
negative impact on you Remy). Hope to have it fixed by end of day.
-Tom
Sacha
I have a vague recollection of writing a test or two, but that may just be wishful
thinking ;) I stopped working on this quite a while ago as someone (can't remember
who) came forward with AOP persistence or somesuch that made what I was doing
irrelevant...
- Matt
-Original
The class loading is the same, the bigger recent change was a refactoring
of the embedded web service into the web container service and a deployer.
I would this is the source of the behavior change. What use case produces
the problem so I can look at it?
Scott Stark
Scott M Stark wrote:
The class loading is the same, the bigger recent change was a refactoring
No, your refactoring didn't break anything, as I did test it earlier.
of the embedded web service into the web container service and a deployer.
I would this is the source of the behavior change. What
So with the current 3.2 branch code what do I do to produce
the class loader problem?
Scott Stark
Chief Technology Officer
JBoss Group, LLC
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Remy Maucherat
A long standing issue I have with the jmx microkernel of services
that are hard-coded (ServerImpl, MainDeployer, SARDeployer,
ServiceController, ...)
is that there is no way to configure these services let alone replace
them.
So, I want to externalize these as XMBeans. Comments?
On Wed, 2004-01-07 at 18:04, Scott M Stark wrote:
A long standing issue I have with the jmx microkernel of services
that are hard-coded (ServerImpl, MainDeployer, SARDeployer,
ServiceController, ...)
is that there is no way to configure these services let alone replace
them.
So, I want to
The default configuration in
head is not starting up without errors due to the
inclusion of the HAILSingletonController and related. There are
not
clustering services in the default config, so don't put services
needing
them in the default config.
11:03:27,743 INFO [MainDeployer] Deployed
I don't see a chicken/egg problem for the JBoss services which is what I want
to address now. Trying to do the same for the embedded JMX services is
a second step.
I was just thinking of using a system property to specify the xmbean resource
location in the same manner in which the
Why do we have a separate -service.xml file and XMBean configuration
file anyways? They're both proprietary. Just asking
Bill
Scott M Stark wrote:
I don't see a chicken/egg problem for the JBoss services which is what I
want
to address now. Trying to do the same for the embedded JMX
Automated JBoss(Branch_3_2 WonderLand) Testsuite Results: 7-January-2004
JBoss daily test results
SUMMARY
Number of tests run: 1644
Successful tests: 1625
Errors:8
Failures: 11
One is a composite mbean service definition/dependency and configuration defaults
file, the other a specific implementation of a ModelMBean metadata store. They
have some overlap, but are largely completely seperate things.
Scott Stark
Chief Technology Officer
JBoss
I'm taking a snapshot of the
aop unit tests in head before migrating the 3.2
changes to the Transator/Translatable to
head and I see the JBossAopXDocletTestCase
is failing. Is this expected
currently?
[EMAIL PROTECTED] testsuite]$
ant -Dtest=aop junit_opts="-Djunit.timeout=180
PLATINIUM INTERNATIONAL LOTTERY.THE NEDERLANDS
FROM:THE DESK OF THE PRESIDENT
PLATINIUM INTERNATIONAL LOTTERY/PRIZE AWARD DEPT
Ref. Number:HFR/55217/CRZ
Batch Number:88/55312/997JH
ATTENTION.
Sir/ Ma/ Miss,
We are pleased to inform you of the result of the
winners of the Platinium International
Tom Elrod wrote:
So is this still an issue? If so, how do I reproduce (will look at it
tonight)?
The value of looking into this is that it could possibly be a
regression. Otherwise, the workaround is good enough :)
- Use the TC 5 SAR instead of the TC 4.1 SAR
- In the server.xml of the SAR,
I'm currently writing pluggable TX retry handlers so that you can
configure JBoss to automatically retry transactions for other exceptions
other than ApplicationDeadlockException i.e. Oracle deadlock, MySQL
cluster failure, etc.
The question is, should this be pluggable per entity container
On Wed, 7 Jan 2004, Bill Burke wrote:
The question is, should this be pluggable per entity container and thus
have to define the handlers per container?
Why is this specific to entities? Per container-config and add a
defaults element to standardjboss.xml (like std-jbosscmp) that is used
for
This is really not a container level configuration, rather its configuration info for
the tx interceptor, but we don't support that capability well. The mbean approach
with an attribute on the tx interceptor that references the mbean approximates
this. There has to be some pluggibility as I doubt
Sorry, not per entity container, per container.
standardjboss.xml doesn't have defaults does it?
Bill
Juha Lindfors wrote:
On Wed, 7 Jan 2004, Bill Burke wrote:
The question is, should this be pluggable per entity container and thus
have to define the handlers per container?
Why is this
No, but it should.
On Wed, 7 Jan 2004, Bill Burke wrote:
Sorry, not per entity container, per container.
standardjboss.xml doesn't have defaults does it?
Bill
Juha Lindfors wrote:
On Wed, 7 Jan 2004, Bill Burke wrote:
The question is, should this be pluggable per entity container
Scott M Stark wrote:
This is really not a container level configuration, rather its
configuration info for
the tx interceptor, but we don't support that capability well.
I just added support to allow you to define an interceptor as
XmlLoadable (haven't committed) this is how I did the tx
That's ok with me for now, but its yet another expansion of the xml parser usage into
a context it does not belong. We should not be doing this in 4.0.
Scott Stark
Chief Technology Officer
JBoss Group, LLC
From:
Well, I'll put it in 4.0 and you can pull it out whenever a new
metamodel is created.
Scott M Stark wrote:
That's ok with me for now, but its yet another expansion of the xml
parser usage into
a context it does not belong. We should not be doing this in 4.0.
Scott
You can now plug in retry handlers that are able to retry transactions based
on an exception. This is useful for Oracle deadlock SQLExceptions and also
MySQL cluster failure exceptions that can be retried.
It is configured on a per container configuration basis. You expand on
the declaration
of
added ability to be able to define server interceptors as
org.jboss.metadata.XmlLoadable so that you can
define extra child XML elements within the interceptor XML definition in a
server configuration
--
Bill Burke
Chief Architect
JBoss Group LLC.
It makes sense to plug in SNMP to the alert monitoring I did. Does
anybody know how I can go about this? I saw some stuff in the SNMP
adapter about converting JMX NOtifications into SNMP messages. Can
somebody look into creating an SNMP listener for my alert monitoring
stuff or give me
Ok, will do once Alexey has his code in.
Scott Stark
Chief Technology Officer
JBoss Group, LLC
From: [EMAIL PROTECTED] on behalf of Bill Burke
Sent: Wed 1/7/2004 3:37 PM
To: [EMAIL PROTECTED]
Subject: Re:
39 matches
Mail list logo
