===
==THIS IS AN AUTOMATED EMAIL - SEE http://jboss.kimptoc.net/ FOR DETAILS==
===
===
==THIS IS AN AUTOMATED EMAIL - SEE http://jboss.kimptoc.net/ FOR DETAILS==
===
===
==THIS IS AN AUTOMATED EMAIL - SEE http://jboss.kimptoc.net/ FOR DETAILS==
===
===
==THIS IS AN AUTOMATED EMAIL - SEE http://jboss.kimptoc.net/ FOR DETAILS==
===
===
==THIS IS AN AUTOMATED EMAIL - SEE http://jboss.kimptoc.net/ FOR DETAILS==
===
===
==THIS IS AN AUTOMATED EMAIL - SEE http://jboss.kimptoc.net/ FOR DETAILS==
===
===
==THIS IS AN AUTOMATED EMAIL - SEE http://jboss.kimptoc.net/ FOR DETAILS==
===
===
==THIS IS AN AUTOMATED EMAIL - SEE http://jboss.kimptoc.net/ FOR DETAILS==
===
===
==THIS IS AN AUTOMATED EMAIL - SEE http://jboss.kimptoc.net/ FOR DETAILS==
===
===
==THIS IS AN AUTOMATED EMAIL - SEE http://jboss.kimptoc.net/ FOR DETAILS==
===
===
==THIS IS AN AUTOMATED EMAIL - SEE http://jboss.kimptoc.net/ FOR DETAILS==
===
===
==THIS IS AN AUTOMATED EMAIL - SEE http://jboss.kimptoc.net/ FOR DETAILS==
===
===
==THIS IS AN AUTOMATED EMAIL - SEE http://jboss.kimptoc.net/ FOR DETAILS==
===
===
==THIS IS AN AUTOMATED EMAIL - SEE http://jboss.kimptoc.net/ FOR DETAILS==
===
===
==THIS IS AN AUTOMATED EMAIL - SEE http://jboss.kimptoc.net/ FOR DETAILS==
===
===
==THIS IS AN AUTOMATED EMAIL - SEE http://jboss.kimptoc.net/ FOR DETAILS==
===
===
==THIS IS AN AUTOMATED EMAIL - SEE http://jboss.kimptoc.net/ FOR DETAILS==
===
===
==THIS IS AN AUTOMATED EMAIL - SEE http://jboss.kimptoc.net/ FOR DETAILS==
===
===
==THIS IS AN AUTOMATED EMAIL - SEE http://jboss.kimptoc.net/ FOR DETAILS==
===
===
==THIS IS AN AUTOMATED EMAIL - SEE http://jboss.kimptoc.net/ FOR DETAILS==
===
===
==THIS IS AN AUTOMATED EMAIL - SEE http://jboss.kimptoc.net/ FOR DETAILS==
===
===
==THIS IS AN AUTOMATED EMAIL - SEE http://jboss.kimptoc.net/ FOR DETAILS==
===
===
==THIS IS AN AUTOMATED EMAIL - SEE http://jboss.kimptoc.net/ FOR DETAILS==
===
===
==THIS IS AN AUTOMATED EMAIL - SEE http://jboss.kimptoc.net/ FOR DETAILS==
===
===
==THIS IS AN AUTOMATED EMAIL - SEE http://jboss.kimptoc.net/ FOR DETAILS==
===
===
==THIS IS AN AUTOMATED EMAIL - SEE http://jboss.kimptoc.net/ FOR DETAILS==
===
===
==THIS IS AN AUTOMATED EMAIL - SEE http://jboss.kimptoc.net/ FOR DETAILS==
===
===
==THIS IS AN AUTOMATED EMAIL - SEE http://jboss.kimptoc.net/ FOR DETAILS==
===
===
==THIS IS AN AUTOMATED EMAIL - SEE http://jboss.kimptoc.net/ FOR DETAILS==
===
===
==THIS IS AN AUTOMATED EMAIL - SEE http://jboss.kimptoc.net/ FOR DETAILS==
===
3.2 requires JDK 1.3 to compile so do not use JDK 1.4 specific
features like RuntimeException(Error resolving methods, e);
Use the org.jboss.util.NestedRuntimeException.
Scott Stark
Chief Technology Officer
JBoss Group, LLC
-Original
Automated JBoss(Branch_3_2 WonderLand) Testsuite Results: 6-January-2004
JBoss daily test results
SUMMARY
Number of tests run: 1626
Successful tests: 1589
Errors:22
Failures: 15
From http://java.sun.com/j2se/1.4.1/download.html:
quote
Products listed on this page have begun the Sun End of Life (EOL)
process. The EOL transition period is from July 15, 2003 until January
15, 2004. With this notice, customers should now begin to move to
current product versions.
It passes for me with yesterday's clean check out.
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On
Behalf Of Scott M Stark
Sent: Monday, January 05, 2004 4:32 PM
To: [EMAIL PROTECTED]
Subject: RE: [JBoss-dev] Automated JBoss(Branch_3_2
WonderLand)
===
==THIS IS AN AUTOMATED EMAIL - SEE http://jboss.kimptoc.net/ FOR DETAILS==
===
Every service would have to have a dependency on the remoting service in
order for it to be the last to be shutdown. Otherwise, you can create
your own java.util.Comparator impl using the URLDeploymentScanner
URLComparator attribute to order the content of deploy
however you want to ensure
===
==THIS IS AN AUTOMATED EMAIL - SEE http://jboss.kimptoc.net/ FOR DETAILS==
===
Bugs item #871649, was opened at 2004-01-06 08:16
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=376685aid=871649group_id=22866
Category: JBossMX
Group: v3.2
Status: Open
Resolution: None
Bugs item #871649, was opened at 2004-01-06 13:16
Message generated for change (Comment added) made by ejort
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=376685aid=871649group_id=22866
Category: JBossMX
Group: v3.2
Status: Open
Resolution: None
Priority: 5
Bugs item #871649, was opened at 2004-01-06 08:16
Message generated for change (Comment added) made by jhaynie
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=376685aid=871649group_id=22866
Category: JBossMX
Group: v3.2
Status: Open
Resolution: None
Priority: 5
Bugs item #871649, was opened at 2004-01-06 13:16
Message generated for change (Comment added) made by ejort
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=376685aid=871649group_id=22866
Category: JBossMX
Group: v3.2
Status: Open
Resolution: Accepted
Priority: 5
See:
http://www.kb.cert.org/vuls/id/867593
Are we affected with tomcat/jetty as well?
Heiko
===
==THIS IS AN AUTOMATED EMAIL - SEE http://jboss.kimptoc.net/ FOR DETAILS==
===
Bugs item #871649, was opened at 2004-01-06 08:16
Message generated for change (Comment added) made by jhaynie
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=376685aid=871649group_id=22866
Category: JBossMX
Group: v3.2
Status: Closed
Resolution: Fixed
Priority: 5
Hi Jeff,
You cannot implement it like this:
// make a copy of the notification, replacing with the real
source of the event
Notification n = new
Notification(notification.getType(),source,notification.getSequenceNumber(),notification.getTimeStamp(),notification.getMessage());
OK, good catch. If you extended the Notification object it would fail.
I was trying to avoid modifying the real source - but I guess there's no
choice.
Fix is in.
Jeff
Adrian Brock wrote:
Hi Jeff,
You cannot implement it like this:
// make a copy of the notification, replacing
Bugs item #870942, was opened at 2004-01-05 08:54
Message generated for change (Comment added) made by swolfangel
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=376685aid=870942group_id=22866
Category: JBossMX
Group: v3.2
Status: Open
Resolution: None
Priority: 5
===
==THIS IS AN AUTOMATED EMAIL - SEE http://jboss.kimptoc.net/ FOR DETAILS==
===
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
-
Well done Bill, this is good stuff:)
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Bill
Burke
Sent: Friday, December 12, 2003 4:24 PM
To: Jboss-Dev; JBoss 2; [EMAIL PROTECTED]
Subject: [JBoss-dev] New JBoss Monitoring services
This will be released
agreed - i can't wait to start playing w/ it.
any proposed ETA for 3.2.4?
-jae
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Ben
Sabrin
Sent: Tuesday, January 06, 2004 3:00 PM
To: [EMAIL PROTECTED]
Subject: RE: [JBoss-dev] New JBoss Monitoring
===
==THIS IS AN AUTOMATED EMAIL - SEE http://jboss.kimptoc.net/ FOR DETAILS==
===
Feature Requests item #871916, was opened at 2004-01-06 20:36
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=376688aid=871916group_id=22866
Category: JBoss-IDE
Group: None
Status: Open
Automated JBoss(Branch_3_2 WonderLand) Testsuite Results: 6-January-2004
JBoss daily test results
SUMMARY
Number of tests run: 1606
Successful tests: 1571
Errors:27
Failures: 8
Currently the default entity bean locking strategy is Commit 'B' plus
pessimistic. If we're going to default to 'B', can we default to multi
instance?
Bill
--
Bill Burke
Chief Architect
JBoss Group LLC.
On Tue, 2004-01-06 at 22:19, Bill Burke wrote:
Currently the default entity bean locking strategy is Commit 'B' plus
pessimistic. If we're going to default to 'B', can we default to multi
instance?
+1 from me
It doesn't make sense to serialize access to a shared instance
whose data
Adrian Brock wrote:
On Tue, 2004-01-06 at 22:19, Bill Burke wrote:
Currently the default entity bean locking strategy is Commit 'B' plus
pessimistic. If we're going to default to 'B', can we default to multi
instance?
+1 from me
It doesn't make sense to serialize access to a shared
If JSR-77 stats were mbeans then we could use all the monitoring,
snapshotting and graphing features. Is it feasible to make current
MBeans that manage EJBs, JMS, etc... implement the JSR-77 interfaces and
expose these stats as JMX attributes? Just a thought and I haven't put
any research at
But it is already like that, no?!?
- Original Message -
From: Bill Burke [EMAIL PROTECTED]
To: Jboss-Dev [EMAIL PROTECTED]
Sent: Tuesday, January 06, 2004 11:52 PM
Subject: [JBoss-dev] If JSR-77 stats were mbeans...
If JSR-77 stats were mbeans then we could use all the monitoring,
===
==THIS IS AN AUTOMATED EMAIL - SEE http://jboss.kimptoc.net/ FOR DETAILS==
===
I am not sure but I don't think all the stats for JMS have been
implemented.
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
Sacha Labourey
Sent: 06 January 2004 23:05
To: [EMAIL PROTECTED]
Subject: Re: [JBoss-dev] If JSR-77 stats were mbeans...
But it
===
==THIS IS AN AUTOMATED EMAIL - SEE http://jboss.kimptoc.net/ FOR DETAILS==
===
===
==THIS IS AN AUTOMATED EMAIL - SEE http://jboss.kimptoc.net/ FOR DETAILS==
===
===
==THIS IS AN AUTOMATED EMAIL - SEE http://jboss.kimptoc.net/ FOR DETAILS==
===
===
==THIS IS AN AUTOMATED EMAIL - SEE http://jboss.kimptoc.net/ FOR DETAILS==
===
===
==THIS IS AN AUTOMATED EMAIL - SEE http://jboss.kimptoc.net/ FOR DETAILS==
===
Cool.
I assume this is a feature of the web console, not the
jmx console?
BTW, how did you make the decision to use a java
applet in the web console vs. dhtml?
Ivelin
--- Bill Burke [EMAIL PROTECTED] wrote:
Hi all,
I just committed the ability to do snapshot
recordings of any JMX
Very nice, Bill.
Email notifications when memoty is low will be very
useful.
Is there a CPU utilization monitor as well?
Scott and I talked some time ago about a heart watch
service which will restart the server when the memory
is too low or the CPU is pegged for too long.
Your work will be
Very nice, Bill.
Email notifications when memoty is low will be very
useful.
Is there a CPU utilization monitor as well?
Scott and I talked some time ago about a heart watch
service which will restart the server when the memory
is too low or the CPU is pegged for too long.
Your work will be
===
==THIS IS AN AUTOMATED EMAIL - SEE http://jboss.kimptoc.net/ FOR DETAILS==
===
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
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 on both
Windows and Linux and it handles all
Hi all,
I just committed the ability to do snapshot recordings of any JMX
attribute within the web-console.
To use it, you right-click a JMX attribute and choose the create
snapshot item.
From there you can start/stop snapshotting. Review the dataset and
Graph the dataset.
This is
The java wrapper uses native code to start the JVM and handles natively
restart, etc. You basically implement simple Java class that has a
start and stop method and we just then call the appropriate method in
Server to control jboss - which then goes through the normal lifecycle.
The trick,
The web-console framework is Sacha's baby. I've just added shit.
Ivelin Ivanov wrote:
Cool.
I assume this is a feature of the web console, not the
jmx console?
BTW, how did you make the decision to use a java
applet in the web console vs. dhtml?
Ivelin
--- Bill Burke [EMAIL PROTECTED] wrote:
No, they are available as datastructure I thought?
Sacha Labourey wrote:
But it is already like that, no?!?
- Original Message -
From: Bill Burke [EMAIL PROTECTED]
To: Jboss-Dev [EMAIL PROTECTED]
Sent: Tuesday, January 06, 2004 11:52 PM
Subject: [JBoss-dev] If JSR-77 stats were
Does it have threshold and alert notification as well? Tom was telling
me about your stuff. Let us know what you want to contribute and how it
can/would fit.
FYI, the graphing stuff was butt easy to do. www.jfree.org
Thanks,
Bill
Jeff Haynie wrote:
We also have written a native (via JNI)
===
==THIS IS AN AUTOMATED EMAIL - SEE http://jboss.kimptoc.net/ FOR DETAILS==
===
Scott, Bill,
what do you guys think?
Does a native wrapper make sense for restart or it is
better to keep it pure java and get away without
restarting the vm?
Jeff's reasoning makes sense to me.
On the other hand though a native ingredient may
reduce the overall perception that JBoss is
Hi,
I saw some updates here to the web clustering code from Thomas:
User: tpeuss
Date: 04/01/04 03:54:01
Modified:src/main/org/jboss/web/tomcat/session Tag: Branch_3_2
ClusterManager.java ClusteredSession.java
Log:
Change for bug #863113.
This patch adds a
Sacha, do you remember what drove your decision to use
Swing for the management tree in the web console?
The reason why I am asking is because we (in our
company) had to go through a long and painful round of
experiments and prototypes comparing the feasibility
of DHTML vs Swing for a big
82 matches
Mail list logo
