JBoss-3.0.5 release test results
SUMMARY
Number of tests run: 1010
Successful tests: 1007
Errors:2
Failures: 1
[time of test: 2003-01-13.02-11 GMT]
I am investingating the problem with inability remove deployed files.
First, I've found that URLDeploymentScanner uses
sun.net.www.protocol.file.FileURLConnection. For example here:
URLConnection connection;
if (watchUrl != null)
{
connection = watchUrl.openConnection();
}
else
{
connection
I quickly searched the source for opening files with
FileInputStream. I fixed closing it after reading is done in several
places.
I want to warn. The common, I think mistake, in loading properties is
Properties props = new Properties();
props.load(new FileInputStream(new File(filename)));
After
Forgot to add. This is for JBoss-3.2.
But in HEAD I can't remove deployed/watching files on windows either.
So, I guess, HEAD has the same problem.
alex
Monday, January 13, 2003, 2:10:51 PM, you wrote:
AL I am investingating the problem with inability remove deployed files.
AL First, I've
Bugs item #667151, was opened at 2003-01-13 15:38
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=376685aid=667151group_id=22866
Category: JBossWeb
Group: v3.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Mikko Koponen (mtkopone)
Assigned to:
Bugs item #667151, was opened at 2003-01-13 15:38
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=376685aid=667151group_id=22866
Category: JBossWeb
Group: v3.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Mikko Koponen (mtkopone)
Assigned to:
Will this fix also be back ported to the 3.x series as well? This is a huge
issue for those of us who are or plan to use more then one jboss node in our
applications.
Dustin
-Original Message-
From: Scott M Stark [mailto:[EMAIL PROTECTED]]
Sent: Sunday, January 12, 2003 4:19 AM
To:
Stefan,
Could you please clarify? What is an eclipse property sheet? What is a primitive
in this gui? What is an over scaled complex object?
If by complex object, you mean a Java Collection, and the ability to inspect / edit
it in the gui, then I guess I prefer b, but a
Bugs item #665067, was opened at 2003-01-09 16:12
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=376685aid=665067group_id=22866
Category: JBossCX
Group: v3.0 Rabbit Hole
Status: Open
Resolution: None
Priority: 5
Submitted By: Michael Ukpong (michaelukpong)
Assigned
Dain,
What is going on with MBean persistence?
Not much, as far as I can tell.
Can we do this today?
Yes, but only by persisting to ObjectOutputStream files. XML / JDBC persistence
engines have yet to be written.
If not is anyone working on it?
I origionally wrote
---
This SF.NET email is sponsored by: FREE SSL Guide from Thawte
are you planning your Web Server Security? Click here to get a FREE
Thawte SSL guide and find the answers to all your SSL security issues.
So Matt are you interested in working on the XML persistence?
-dain
On Monday, January 13, 2003, at 08:32 AM, Matt Munz wrote:
Dain,
What is going on with MBean persistence?
Not much, as far as I can tell.
Can we do this today?
Yes, but only by persisting to ObjectOutputStream files.
Hi,
I've isolated the hanging behavior to the writer threads in multiplexor
test. I re-wrote the tests to run over a socket and use a client and a
server.
When I run the test with the server configured to:
Write on channel 1
Write on channel 2
Read from channel 1
And the client configured to:
I am I blind? I see 3.2 beta and 3.0.4 but no 3.0.5?
On Mon, 2003-01-13 at 06:40, Scott M Stark wrote:
The 3.0.5 release of JBoss is available from SourceForge here:
https://sourceforge.net/project/showfiles.php?group_id=22866
Detailed change notes are available here:
Hello,
The code for TransactionInterceptor (client side) in HEAD does this at one
point (in the invoke):
transactionManagerServiceName =
new ObjectName (DEFAULT_CLIENT_TM_NAME_STUB) +
invoker.getServerID().toObjectNameClause());
In the standard scenario, that is
Dain,
So Matt are you interested in working on the XML persistence?
Yeah, I suppose I could put some more time into it. It sounds like you know a few
people that might actually be users of this feature. Do you have a use case in mind?
- Matt
-Original Message-
Title: Re: [JBoss-dev] MBean persistence?
Matt,
I
think we want seemless integration here. If the MBean is packaged within a
SAR, the SAR should be exploded, the XML file modified and the SAR
re-jared. Same goes withstraight XML files or SARS embedded
withinSARs (russian doll).
I'm in
Hi,
scroll down, you will find JBoss 3.0.5 released on 13.January 2002
not in January 2003 ;)
Hans
Message: 5
Subject: Re: [JBoss-dev] [JBoss-user] JBoss-3.0.5 release available
From: Dave Smith [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Date: 13 Jan 2003 10:36:29 -0500
Reply-To: [EMAIL
Yes basically.
Here is what I have in mind: as each attribute is loaded from the
source xml the location from where it was loaded is remembered. When
an attribute is changed that was loaded from the xml, the persistence
manager overwrites the existing XML. I don't think you have to explode
(copied from a message I sent direct to Bill)
Bill,
I couldn't figure out how to add a comment to the task, so I'm just emailing you.
I think we want seemless integration here
I think you're integrating apples and oranges ;)
What you've described does not match the
it's there, i just dl'd it.
it's far down on the page; somethings not quite right with sourceforge.
-Original Message-
From: Dave Smith [mailto:[EMAIL PROTECTED]]
Sent: Monday, January 13, 2003 9:36 AM
To: [EMAIL PROTECTED]
Subject: Re: [JBoss-dev] [JBoss-user] JBoss-3.0.5 release
Dain,
Please see my recent email in response to Bill.
I origionally started with this approach, but the more I thought about it, the more
untenable it seemed. Based on my experience so far, I just don't want the server
mucking with my deployment descriptors.
I'm sure I can
Matt,
I have meet with many system administrators over the past few months,
so I'll try to support their opinion. If there are any admins on this
list, please speak up.
Simpler console for common tasks
The administrator the power of the JMX console, and think
Our FileURLConnection should be picked due to the org.jboss.net.protocol
package being placed into the java.protocol.handler.pkgs by thiscode in
org.jboss.system.server.ServerImpl.doInit:
// Include the default JBoss protocol handler package
String handlerPkgs =
Title: Re: [JBoss-dev] MBean persistence?
Like
Matt, I have concerns about modifying the files in the deployment as well. I
think his concerns about division of roles are valid - I'd go further and say
this needs to be able to handle a split between 'deployer' and 'operator/sys
admin' as
On Monday, January 13, 2003, at 11:26 AM, Matt Munz wrote:
Dain,
Please see my recent email in response to Bill.
Yes. I think sf is creating a big lag between our emails.
I origionally started with this approach, but the more I thought
about it, the more untenable it seemed. Based on
Simpler console for common tasks
The administrator the power of the JMX console, and think it is cool
they can change the behavior of the entire system. On the other hand
they are overwhelmed by the options. Most would like a very simple
static interface
I love you sacha!
I can't seem to find the screen shot. I'll see if I can get this
working on my apple.
-dain
On Monday, January 13, 2003, at 11:39 AM, Sacha Labourey wrote:
Simpler console for common tasks
The administrator the power of the JMX console, and
The new forum software doesn't support attachements, which is why.
Try again: I've added it as an img link.
http://www.jboss.org/modules.php?op=modloadname=phpBB_14file=indexaction=
viewtopictopic=26785
-Message d'origine-
De : [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]De la part
Jeremy,
Specific comments are inline...
On Monday, January 13, 2003, at 11:33 AM, Jeremy Boynes wrote:
Like Matt, I have concerns about modifying the files in the deployment
as well. I think his concerns about division of roles are valid - I'd
go further and say this needs to be able to
Our admin here thinks that Dain is spot on with this analysis.
From: Dain Sundstrom [EMAIL PROTECTED]
Reply-To: [EMAIL PROTECTED]
Date: Mon, 13 Jan 2003 11:27:07 -0600
To: [EMAIL PROTECTED]
Subject: Re: [JBoss-dev] MBean persistence?
Matt,
I have meet with many system administrators
Bugs item #667341, was opened at 2003-01-13 13:24
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=376685aid=667341group_id=22866
Category: JBossWeb
Group: v3.0 Rabbit Hole
Status: Open
Resolution: None
Priority: 5
Submitted By: Peter Luttrell (objec)
Assigned to:
Dain,
First off, thank you for providing much-needed field data for this work.
Your comments on Persistence in general are identical to my reasons for working on
MBean Persistence in the first place.
When I suggest that we could write out a new different
xml file that has the
Thanks for pointing to this, but I think the problem is not there.
I suspect the classes are somehow not getting to the classpath.
I'm running jdk1.3.1_05. Note, earlier I ran JBoss w/o these problems
on this same VM.
Please, let me know whether it's only me watching it.
Thanks,
alex
Monday,
On Monday, January 13, 2003, at 01:26 PM, Matt Munz wrote:
Dain,
First off, thank you for providing much-needed field data for this
work.
Your comments on Persistence in general are identical to my reasons
for working on MBean Persistence in the first place.
When I suggest that we could
Title: [JBoss-dev] Jboss JMX View Attributes
Hi Matt,
Thanks
for your replay.
Could you please clarify?
Sure.
What is an eclipse property sheet?
take a look on the screenshoot I took for you:
http://jbossadmingui.sourceforge.net/
What is a primitive in this gui?
What is an
The 3.0.5 release of JBoss is available from SourceForge here:
https://sourceforge.net/project/showfiles.php?group_id=22866
Detailed change notes are available here:
https://sourceforge.net/project/shownotes.php?release_id=129789
The 3.2.0RC1 release will be done tomorrow.
On Mon, 13 Jan 2003, Scott M Stark wrote:
Our FileURLConnection should be picked due to the org.jboss.net.protocol
package being placed into the java.protocol.handler.pkgs by thiscode in
org.jboss.system.server.ServerImpl.doInit:
// Include the default JBoss protocol handler package
Dain,
I like your give-them-what-they-want attitude. Rest assured that I am *very* aware
of config file hell and am likewise motivated to avoid complexity.
Please note that the current XMBean deployment involves at least *two* config files
already. If the goal is to have only one,
Bugs item #665183, was opened at 2003-01-09 11:09
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=376685aid=665183group_id=22866
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Matt Cleveland (groovesoftware)
Assigned to:
No, then you have no way to override it.
Scott Stark
Chief Technology Officer
JBoss Group, LLC
- Original Message -
From: Adam Heath [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Monday, January 13, 2003 1:31 PM
Subject: Re: [JBoss-dev]
This should not be a black and white option. We need a logical seperation from
configuration from the deployment at the JBoss core layer. If someone wants
to persist configuration with the deployment, including runtime mods let them.
If someone wants to access webdav, jdbc, jndi, etc. for the
They are definitely in the classpath in the lib/jboss-common.jar, but may not
be available to the class loader being used. What version of JBoss are we
talking about here?
Scott Stark
Chief Technology Officer
JBoss Group, LLC
- Original
Scott,
Thanks. I think the common point to both strategies is the MBean - XML serializer.
I'll get started on that.
For what date is the 3.2 release planned?
- Matt
-Original Message-
From: Scott M Stark [mailto:[EMAIL PROTECTED]]
Sent: Mon
Bugs item #667341, was opened at 2003-01-13 19:24
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=376685aid=667341group_id=22866
Category: JBossWeb
Group: v3.0 Rabbit Hole
Status: Open
Resolution: None
Priority: 5
Submitted By: Peter Luttrell (objec)
Assigned to:
I got nuked by postnuke.
The stuff just doesn't scale. Either that or we are doing something
really wrong. In any case the site is UN-USABLE. We will continue with
our port of postnuke and see if we can come with a real forums/nukes on
jboss project.
My bad. I make mistakes, I should have
You guys thought of doing:
wget --recursive http://www.jboss.org, publish the static files every 15
min, and only use the PHP for processing submission forms? Just a
thought to quickly reduce your PHP dependence except for new forum
posts.. Dunno if you would have to pipe each file to a sed
When it looks worth putting out. I was thinking the end of the month but
given that I'm training the entire last week it won't be until the first week
of Feb.
Scott Stark
Chief Technology Officer
JBoss Group, LLC
- Original Message -
I think we should freeze functionality for the 3.0 and 3.2 series. Let's
start focusing on getting 3.2 stable and bug-free and move our functionality
development into 4.0
Scott, what do you think?
Bill Burke
Chief Architect
JBoss Group, LLC
It should be developed in 4.0 and migrated to 3.2. It does not need to be in the
initial
release. It does need to be migrated into 3.2.
Scott Stark
Chief Technology Officer
JBoss Group, LLC
- Original Message -
From: Bill Burke [EMAIL
3.0 is transiation to bug fixes as soon as 3.2.0 is out. I want to release stable
development from 4.0 into 3.2 as soon as possible as I don't want 4.0.0
coming out 5 months down the road to be something that has seen no
realistic use.
Scott Stark
Chief Technology Officer
Bugs item #667151, was opened at 2003-01-13 13:38
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=376685aid=667151group_id=22866
Category: JBossWeb
Group: v3.2
Status: Closed
Resolution: Fixed
Priority: 5
Submitted By: Mikko Koponen (mtkopone)
Assigned to: Jules
Just validates that J2EE is the way to go and scales and this kiddy(your
words Marc) PHP crap although looks sexy, just doesn't scale.
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of James
Higginbotham
Sent: Monday, January 13, 2003 6:20 PM
To:
Bugs item #667492, was opened at 2003-01-13 18:40
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=376685aid=667492group_id=22866
Category: JBossCX
Group: v3.0 Rabbit Hole
Status: Open
Resolution: None
Priority: 5
Submitted By: Dave Marquard (lurp)
Assigned to:
Bugs item #667341, was opened at 2003-01-13 11:24
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=376685aid=667341group_id=22866
Category: JBossWeb
Group: v3.0 Rabbit Hole
Status: Open
Resolution: None
Priority: 5
Submitted By: Peter Luttrell (objec)
Assigned to:
Do we need to start a counseling fund for Julien after all the written
by a 12-year-old PHP that will have to be seen, reversed, and cried
over?
-Original Message-
From: Hunter Hillegas [mailto:[EMAIL PROTECTED]]
Sent: Monday, January 13, 2003 8:25 PM
To: JBoss Dev; marc fleury
Just think of this as an opportunity to write a really good case study on
the advantages of J2EE/EJB/Caches.
From: marc fleury [EMAIL PROTECTED]
Reply-To: [EMAIL PROTECTED]
Date: Mon, 13 Jan 2003 17:53:48 -0500
To: Jboss-Development@Lists. Sourceforge. Net
[EMAIL PROTECTED]
Cc: 'JBoss
What if changes to the DeploymentScanner was made to reflect :
file - DeploymentScanner - Mbean
jmx-console - DeploymentScanner - Mbean and file
Then adding writes inside russian dolls could/should also revolve
around the DeploymentScanner as hub.
I wouldn't go that far. The php guys could have written something that
has the same performance as our J2EE implementation, but they didn't.
It isn't a language, spec or platform issue, it is pure issue if
implementation.
-dain
On Monday, January 13, 2003, at 06:28 PM, Bill Burke wrote:
I'm not sure if you agree with my proposal or not. Do you think we
should add the feature to persist the changes back out to the
deployment descriptors?
-dain
On Monday, January 13, 2003, at 04:07 PM, Scott M Stark wrote:
This should not be a black and white option. We need a logical
I'm saying this should be supported, but not the only mechanism for
persisting configuration. The configuration could be completely outside
of the deployment and loaded through an external store.
Scott Stark
Chief Technology Officer
JBoss Group, LLC
for those who want to cut and past and repost the posts you made over the
past week. Sorry for the scalability problems we've switched back to good
old scalable J2EE.
Postnuke:
http://www.jboss.org:8080
---
This SF.NET email is sponsored
I meet it in JBoss-3.2 and HEAD. I am afraid if I update JBoss-3.0
it'll get infected too. I'll try to figure it out.
alex
Tuesday, January 14, 2003, 12:18:41 AM, you wrote:
SMS They are definitely in the classpath in the lib/jboss-common.jar, but may not
SMS be available to the class loader
63 matches
Mail list logo
