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: [JBoss-
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 point
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 XML definition in a
server configuration
--
Bill Burke
Chief Architect
JBoss Group LLC.
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 Sta
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:
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 retry
No, but it should.
On Wed, 7 Jan 2004, Bill Burke wrote:
> Sorry, not per entity container, per container.
>
> standardjboss.xml doesn't have does it?
>
> Bill
>
> Juha Lindfors wrote:
>
> > On Wed, 7 Jan 2004, Bill Burke wrote:
> >
> >>The question is, should this be pluggable per entity conta
Sorry, not per entity container, per container.
standardjboss.xml doesn't have 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 specific to
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 e
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
element to standardjboss.xml (like std-jbosscmp) that is used
for all confi
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 and
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, rep
So is this still an issue? If so, how do I reproduce (will look at it
tonight)?
Scott M Stark wrote:
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
--
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 Lo
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 -Dnojars=
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 Gr
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
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 servi
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 conf/jboss-ser
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 p
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 wa
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?
x
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
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 us
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
Chi
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 Message-
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 Labourey
> 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 (
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
> 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
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 (vi
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 /cvsroot/jboss/build/jboss
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 co
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 JMX
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 PROTECT
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)
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();
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 be
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 Br
40 matches
Mail list logo