JBoss daily test results
SUMMARY
Number of tests run: 501
Successful tests: 492
Errors:4
Failures: 5
[time of test: 26 February 2002 5:11 GMT]
[java.version:
User: d_jencks
Date: 02/02/25 21:15:02
Modified:src/main/org/jboss/system/server ServerImpl.java
Log:
Changed shutdown procedure to first undeploy all packages, then stop, destroy, and
remove all remaining registered mbeans
Revision ChangesPath
1.4 +47 -11
Hi Scott
Great but I did the same for the stand alone EJB
modules as well.
Please can you send me a patch as soon as possible to avoid conflicts
when code is updated in CVS.
I send this email to the developer list. Can you send them also to
the developer list as well.
Thanx - Andy
-
On 2002.02.25 03:47:06 -0500 Sacha Labourey wrote:
Hello,
In the MainDeployer code, when you deploy a package containing
sub-packages:
- init will be called on the wrapping package first, then on the
inside
packages
- create will be called on the inside packages first, then
I don't get it.. With the Boot class that I commit you can load all of
JBoss's jar's off the network. If footprint is all you care about, you wont
be able to beat the 7k boot.jar (unoptimized with debug).
I just tested the Boot class out, and it can even boot JBoss 2.4.4
So I don't know why
Well, my idea was that since Containers are mbeans already, why not
transform the dd's to mbean config. I'm still thinking about how to best
deal with subsidiary objects. I'm thinking if all the subsidiary objects
are javabeans they can be constructed easily from xml, through jaxb or
other
Seems like a hack. What if the class never gets loaded? Does the
client which wants to use it hang forever? If not how long do you wait
for a class to load?
--jason
marc fleury wrote:
ok,
still jet lagged... (australia!)
So let's imagine that we multi-thread the MainDeployer, each
I don't have it.
From: Jason Dillon [EMAIL PROTECTED]
To: Hiram Chirino [EMAIL PROTECTED]
CC: [EMAIL PROTECTED], [EMAIL PROTECTED]
Subject: Re: [JBoss-dev] 57 words... and a signature
Date: Mon, 25 Feb 2002 21:35:24 -0800
Please read the email I sent Embedable, ServerLoader, jboss-boor.jar,
Again for those that missed it...
--jason
Original Message
Subject: Embedable, ServerLoader, jboss-boot.jar, logging and more...
Date: Sun, 24 Feb 2002 03:37:31 -0800
From: Jason Dillon [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
With the seperation changes also come the first
|I don't get it.. With the Boot class that I commit you can load all
|of JBoss's jar's off the network. If footprint is all you care about,
|you wont be able to beat the 7k boot.jar (unoptimized with debug).
|
|I just tested the Boot class out, and it can even boot JBoss 2.4.4
|
|So I don't
On 2002.02.26 00:37:21 -0500 Jason Dillon wrote:
Seems like a hack. What if the class never gets loaded? Does the
client which wants to use it hang forever? If not how long do you wait
for a class to load?
I don't think this is a problem. The client is most likely a thread started
by
On 2002.02.26 00:29:03 -0500 Jason Dillon wrote:
Well, my idea was that since Containers are mbeans already, why not
transform the dd's to mbean config. I'm still thinking about how to
best
deal with subsidiary objects. I'm thinking if all the subsidiary
objects
are javabeans they can
|THERE IS ***ONE*** SEAT LEFT
Good news: we are SOLD OUT. :) I like Europe.
Good news: we will put a couple more seats as we might have some extra room
and there are always cancelations. Come it will be the last show of its
kind. Come!
|And you got 2 weeks to register.
this is still true,
Yes, I appoligize if sounded harsh.. I just was not seeing the big picture.
All I was hearing was the get it to boot off the network story which is
WAY different from what you need in the embed in an application case.
Regards,
Hiram
From: marc fleury [EMAIL PROTECTED]
To: Hiram Chirino
ok,
you kids chill, drop E, come back high as kites and tell each other,
you are a wonderful human being
no, *you* are a wonderful being
I love you man I love you too
oka? sour pusses
etc etc
|-Original Message-
|From: [EMAIL PROTECTED]
|[mailto:[EMAIL PROTECTED]]On Behalf Of
User: schaefera
Date: 02/02/25 22:14:46
Modified:src/main/org/jboss/management/j2ee J2EEDeployedObject.java
Log:
Added the creation of a default J2EEApplication when a standalone EJB
archive (JAR) is deployed because this is required by JSR-77.
Revision ChangesPath
Frustrated might be a better word...
Just keeping things in check. I don't understand all that cl magic anyways.
--jason
marc fleury wrote:
|Seems like a hack.
Hee hee, the kid's pissed off.
RELAX!!! Go snowboard... with Scott... he is older, trust him...
|What if the class never gets
|Well, getRemote and invokeHome aren't exactly admin interfaces on a
|container, but they are there today. I think using the xmbean/modelmbean
|facilities to either supply 2 interfaces to one object or indicate which
|things are human administratable and which are internal will be useful.
oh...
Hey, van you fix the managment test that is bust when you have time? I
looked it over briefly but did not see any obvious/simple way to fix it.
--jason
Andreas Schaefer wrote:
User: schaefera
Date: 02/02/25 22:14:46
Modified:src/main/org/jboss/management/j2ee
|I don't think this is a problem. The client is most likely a thread started
|by noticing a new package. Anyway, I think we need anyway a list of
|waiting deployments -- partly deployed stuff that is waiting. Now we
Yes, I am afraid of the verbosity of it.
|have mbeans that can be waiting for
Hi Jason
I saw it when I ran the testsuite but I don't know what causes the problem ?
Will look into it tomorrow.
Andy
- Original Message -
From: Jason Dillon [EMAIL PROTECTED]
To: Andreas Schaefer [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Sent: Monday, February 25, 2002 10:23 PM
On Tue, 26 Feb 2002, marc fleury wrote:
ok,
still jet lagged... (australia!)
So let's imagine that we multi-thread the MainDeployer, each deployment gets
a thread.
Each time a thread wants a class the ServiceLibraries tries and if it is a
CNFE waits.
when a class is registered in the
User: user57
Date: 02/02/25 23:24:52
Modified:jbossbuild.xml
Log:
o removed install-dependencies, each module hook will copy the
required thiordparty bits it requires unless a dependent module
already copied it
Revision ChangesPath
1.94 +118 -86
David,
one wish you had is going to become true, the MCL is no longer useful in the
face of unified deployments with UCL.
for a cycling URL - We can ask for what classloader (UCL in
MainDeployer) - what deployment info for the UCL (we miss that map, but we
can do it at the deployment info
There is a fundamental weakness we carry in our design since 2.0 days
the jboss.jcml/service.xml files
we mix in SAR/jcml
existence of the bean
configuration of the bean
classes for the bean
If we change the configuration of the service we are requiring that we
restart the service. Only
Bugs item #522617, was opened at 2002-02-25 12:15
You can respond by visiting:
http://sourceforge.net/tracker/?func=detailatid=376685aid=522617group_id=22866
Category: JBossServer
Group: v3.0 Rabbit Hole
Status: Open
Resolution: None
Priority: 7
Submitted By: Scott M Stark (starksm)
Assigned
101 - 126 of 126 matches
Mail list logo
