This is not very likly to work when the DeploymentCache is in play... unless
the Deployer interface is changed to include the method getWatchURL()... but
that would not make much sence, since this is more of a SubDeployer related
item and does not belong in the Deployer interface.
Anyways,
There should be a java.rmi.NoSuchObjectException:
ejb-2.0-spec, page 79
When the client calls remove on the home or component interface to remove
the session
object, the container issues ejbRemove() on the bean instance. This ends the
life of the session
bean instance and the associated session
The container would then have to know how to create unique
session keys for the store which is something it should not have
to know how to do.
Scott Stark
Chief Technology Officer
JBoss Group, LLC
- Original Message -
From: Jason Dillon
I spoke about it two days ago with Bill and I think we have different
problems with remove methods.
Take the home.remove call on EB: This is transformed in a remote.remove call
*inside* the client proxy (trick)! This has two problems:
- anyone implementing server side interceptors won't
I have 3.0 server running on my w2k box and by osx box started
up its nightly testsuite run. Suddenly is start seeing these errors
being dumped out on the w2k box:
00:15:13,515 ERROR [HAJNDI] lookupLocally failed for ejb/EJBTestRunner
javax.naming.NameNotFoundException: EJBTestRunner not bound
Number of tests run: 551
Successful tests: 247
Errors:303
Failures: 1
[time of test: 23 May 2002 0:15 GMT]
[java.version: 1.3.1]
[java.vendor: Apple Computer, Inc.]
I'm running the default configuration so I doubt it unless the presence
of a cluster dictates this. This totally screwed up the testsuite run.
- Original Message -
From: Sacha Labourey [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Thursday, May 23, 2002 12:24 AM
Subject: RE: [JBoss-dev]
I'm running the default configuration so I doubt it unless the presence
of a cluster dictates this. This totally screwed up the testsuite run.
It could also happen if your client JNDI config is wrong (host not
resolvable, etc.). In this case, if no JNDI service is found, a multicast
discovery
Ok, a bad local config must have been that case because
after a clean build and check of the jndi.properties the test
is running fine with the cluster present.
Scott Stark
Chief Technology Officer
JBoss Group, LLC
- Original Message -
Number of tests run: 593
Successful tests: 593
Errors:0
Failures: 0
[time of test: 23 May 2002 1:21 GMT]
[java.version: 1.3.1]
[java.vendor: Apple Computer, Inc.]
On Wed, May 22, 2002 at 06:19:07PM -0700, Andreas Schaefer wrote:
Hi Geeks
Alex Loubyansky wrote the WebLogic Convertor this
weekend and I incorporated it today. It already contains
support for other application servers (see Convertor).
That was fast. Well done on getting something like
Bugs item #559628, was opened at 2002-05-23 08:43
You can respond by visiting:
http://sourceforge.net/tracker/?func=detailatid=376685aid=559628group_id=22866
Category: JBossServer
Group: v2.4 (stable)
Status: Open
Resolution: None
Priority: 5
Submitted By: Michael Hussey (mhussey)
Assigned to:
right...
it costs $1000 per year,
The CD subscription is a very good idea! That's a really good business model. RH,
Suse, all the Linux distributors are getting their main revenue stream out of CD
subscriptions (at least Suse). However, you must face the mass market. $1000 is just
too
Number of tests run: 593
Successful tests: 593
Errors:0
Failures: 0
[time of test: 23 May 2002 12:28 GMT]
[java.version: 1.3.1]
[java.vendor: Apple Computer, Inc.]
Microsoft tries to squelch Open Source at the pentagon, but apparently many
at the pentagon are seeing the light.
http://www.washingtonpost.com/wp-dyn/articles/A60050-2002May22.html
___
Don't miss the 2002 Sprint PCS Application
Don't the DOD and State Department already use JBoss?
-dain
Scott M Stark wrote:
Microsoft tries to squelch Open Source at the pentagon, but apparently many
at the pentagon are seeing the light.
http://www.washingtonpost.com/wp-dyn/articles/A60050-2002May22.html
Hi Geeks
I funny to see that the more M$ is bitching about open-source the more
people notice open-source and at starting to evaluate it.
Most people, I think, realized that M$ with its history of buggy and un-
secure software is not reliable or at least giving the impression of the
need for a
They are so cute when they try to convince the world their platforms are
more secure
I thought I'd share my favorites:
I've never seen a systematic study that showed open source to be more
secure, said Dorothy Denning, a professor of computer science at Georgetown
University who specializes
Mike Finn wrote:
Microsoft also said open-source software is inherently less secure because
the code is available for the world to examine for flaws, making it possible
for hackers or criminals to exploit them. Proprietary software, the company
argued, is more secure because of its closed
I suppose they must be using data from that new study that shows that security through
obscurity actually works...ha ha
From: Mike Finn [EMAIL PROTECTED]
Date: 2002/05/23 Thu PM 02:14:21 EDT
To: [EMAIL PROTECTED],
[EMAIL PROTECTED]
Subject: RE: [JBoss-dev] Open-Source Fight Flares At
The container can create a unique key, then the PM can tranlsate it as
needed/if needed. Or the PM could expose a createID() instead of
createSession(), letting the container do the rest of the work.
--jason
On Thursday 23 May 2002 12:04 am, Scott M Stark wrote:
The container would then
So is there an easy solution to this? I was thinking that my problem could be
resolved in an interceptor, where if any call comes through on an EJBObject
after EJBObject.remove() has been called then a
java.rmi.NoSuchObjectException could be thrown.
Or perhaps there is also something like
Number of tests run: 737
Successful tests: 576
Errors:155
Failures: 6
[time of test: 23 May 2002 0:44 GMT]
[java.version: 1.3.0]
[java.vendor: IBM Corporation]
=
==THIS IS AN AUTOMATED EMAIL - SEE http://www.lubega.com FOR DETAILS=
=
JAVA VERSION DETAILS
java version 1.3.0
Java(TM) 2 Runtime Environment, Standard
I spent the last week upgrading my service to JBoss3, which made the
configuration much easier for me to managed (no more hacks in jboss.conf for
extra classpaths and such), but I am still seeing an occasional Invalid
Invalid transaction id. when using the JMS RA and JBossMQ.
I changed my
How do I get assigned a task? I'm trying to take a swag at #51309. Thank you.
Fred.
___
Don't miss the 2002 Sprint PCS Application Developer's Conference
August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm
What section is it in, or what is the url to the task.
--jason
On Thursday 23 May 2002 04:57 pm, Frederick N. Brier wrote:
How do I get assigned a task? I'm trying to take a swag at #51309. Thank
you.
Fred.
___
Don't miss
Nothing like a cry for help to get me interested.
From a brief look at the source and from what I can remember from my work on
this stuff the problem is in JBossMQ SpySession class. From what I can see
the sendMessage method needs to be synchronized and I think that will solve
your problem.
Nothing like a cry for help to get me interested.
=)
So you either need to patch SpySession sendMessage so that it is
synchronized or patch the client code (the code calling the JBossMQ stuff)
so that it doesn't have threads calling commit on the session at the same
time other threads are
And another thing, I can't 100% remember because its been a while since I
read it but I think the JMS spec says that Sessions should not be shared by
multiple threads. Crazy in my opinion but there you go...
-Original Message-
From: Jason Dillon [mailto:[EMAIL PROTECTED]]
Sent:
I'm not sure about best solution to the SFSB stuff.
Nor i... =(
There shouldn't be any problem synchronizing SpySession.sendMessage(), but
I can't guarantee it and since I don't have time to completely update my
CVS (last done over a month ago!) and test the change I'm not that keen to
do
So, this does indeed get interesting... my client code is calling a SFSB
which
has a JMS RA, which has the SpySession.
I do have a timer thread sending back periodic stats with the same SFSB
(my
bad) which the main thread uses... but shouldn't the SFSB detect this and
throw an exception
From: Jason Dillon [EMAIL PROTECTED]
...
And is there any reason why SpySession.sendMessage() should NOT be
synchronized?
If anything SpySession.sendMessage() should try to detect the concurrent
access from 2 threads and throw an exception stating that the JMS spec is
being violated by the
Bugs item #559018, was opened at 2002-05-22 13:57
You can respond by visiting:
http://sourceforge.net/tracker/?func=detailatid=376685aid=559018group_id=22866
Category: JBossCMP
Group: v3.0 Rabbit Hole
Status: Open
Resolution: None
Priority: 5
Submitted By: Vincent Zhao (vincentzhao)
Assigned
Yes it should. We have a testcase for this, but how is the timer
interacting with the SFSB, through its remote/local interface?
I have a wrapper object that connects to the SFSB (home.create()) which the
main thread uses to send JMS messages, which a timer also uses to send back
periodic
Should we move the config thread into create() so it will startup and
re-config the logging system as specifided by log4j.xml so that we get
persisted logs sooner?
--jason
___
Don't miss the 2002 Sprint PCS Application Developer's
Right now services have no mechanism to uniquely load resources
located in their sar because the UCL of the sar is not specified
as the loader in the JMX createMBean call. To do this the UCLs
would have to be made MBeans as that is what is required by
the createMBean call signature. It seems like
Yes, that would help. It would also help to get the jndi.properties
console format in synch with the log4j.xml as currently it seems
to be discontinous when the reconfig occurs.
Scott Stark
Chief Technology Officer
JBoss Group, LLC
- Original
I enabled DEBUG for org.jboss.mq, and I see logs like:
Andy, a message just got queued in org.jboss.mq.server.PersistentQueue@c7e8a7,
queue size is: 0
I have not even looked at the code, but after you add something to a queue,
the size should be 0 right?
--jason
I don't think number of MBeans should be an issue... we will just get more and
more. The only downside is that until we have a better GUI to nav these it
will be messy.
--jason
On Thursday 23 May 2002 07:10 pm, Scott M Stark wrote:
Right now services have no mechanism to uniquely load
log4j.properties you mean ;)
I did not realize they were not in sync...
Branch_3_0 shows system/src/resources/log4j.properties and
server/src/etc/conf/default/log4j.xml both use:
%d{ABSOLUTE} %-5p [%c{1}] %m%n
Where do you see them differ?
--jason
On Thursday 23 May 2002 07:11 pm, Scott
The last thing to clarify is are your JMS transactions spanning
multiple SFSB method calls? If they are you can be violating
the single-thread use of the session without multiple threads
being active in the SFSB because you could be commiting
from the wrong thread.
Scott
Think about it this way... somebody creates a simple servlet that creates a
unit of work by sending 2 messages and then commits the work. Somebody that
does not know the spec to will might cache that session in a instance
variable. If 2 requests come in at the same time, they will screw
Yes, log4j.properties. Looking it it closer it is consistent. Its just
the line wrapping from the MainDeployer suddenly changing to
single lines that threw me off.
- Original Message -
From: Jason Dillon [EMAIL PROTECTED]
To: [EMAIL PROTECTED]; Scott M Stark
[EMAIL PROTECTED]
Sent:
I would like to fix this... so either let the container make the unique key
and let the PM translate as needed, or expose a createID on the SFSBPM
interface... any preferences?
--jason
On Thursday 23 May 2002 12:04 am, Scott M Stark wrote:
The container would then have to know how to create
I understand the pros and cons, I am just saying what I feel. You can
outvote me if you wish.
David
-Original Message-
From: Hiram Chirino [mailto:[EMAIL PROTECTED]]
Sent: Friday, May 24, 2002 2:14 PM
To: [EMAIL PROTECTED]
Subject: RE: [JBoss-dev] Seeing occasional Invalid tx id
create() of what???
create methods aren't supposed to reference anything outside the current
mbean, there is no reason to suppose it is there.
Is this going to involve using an mbean before it has gone through the
start lifecycle event? If so, is there some other way to get the effect
you
createID on the SFSBPM
Scott Stark
Chief Technology Officer
JBoss Group, LLC
- Original Message -
From: Jason Dillon [EMAIL PROTECTED]
To: [EMAIL PROTECTED]; Scott M Stark
[EMAIL PROTECTED]
Sent: Thursday, May 23, 2002 7:30 PM
Subject:
It's ok. The message was being displayed before the message was added.
From: Jason Dillon [EMAIL PROTECTED]
Reply-To: [EMAIL PROTECTED]
To: '[EMAIL PROTECTED]'
[EMAIL PROTECTED]
Subject: [JBoss-dev] JMS related; not sure if this is a problem, but it is
odd...
Date: Thu, 23 May 2002 19:10:48
On Thursday 23 May 2002 07:24 pm, Scott M Stark wrote:
The last thing to clarify is are your JMS transactions spanning
multiple SFSB method calls? If they are you can be violating
the single-thread use of the session without multiple threads
being active in the SFSB because you could be
The UCL are in almost 1-1 correspondence with DeploymentInfo, which also
needs to be an mbean IMO for various reasons. Is there some way we could
make both into the same mbean?
david jencks
On 2002.05.23 22:10:01 -0400 Scott M Stark wrote:
Right now services have no mechanism to uniquely load
create() of what???
start() currently creates and starts the thread which handles detection of
changes in the log4j.xml file (or whatever it is configured to use) and
reconfiguring Log4j.
Since we call create() on everything before start(), customized logging (such
as logging to
I don't see sufficient justification to go beyond the spec here so
let's just leave it.
Scott Stark
Chief Technology Officer
JBoss Group, LLC
- Original Message -
From: Hiram Chirino [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Thursday,
Bugs item #501820, was opened at 2002-01-10 09:40
You can respond by visiting:
http://sourceforge.net/tracker/?func=detailatid=376685aid=501820group_id=22866
Category: JBossMQ
Group: v2.4 (stable)
Status: Closed
Resolution: Invalid
Priority: 5
Submitted By: Corby (corby)
Assigned to:
OK, now I finally read the subject. This should be fine. Sorry for the
noise.
david
On 2002.05.23 22:44:10 -0400 Jason Dillon wrote:
create() of what???
start() currently creates and starts the thread which handles detection
of
changes in the log4j.xml file (or whatever it is
I think I need to think about this some more... couldn't we make
DeploymentInfo extend UCL instead of having a reference to it? Anyway, I
think the need to have DeploymentInfo an mbean is not all that pressing, I
will worry about it later.
david jencks
On 2002.05.23 22:55:15 -0400 Scott M
Does this mean we should not try to produce more meaningful error messages
when this does happen... or just leave it as is?
--jason
On Thursday 23 May 2002 08:00 pm, Scott M Stark wrote:
I don't see sufficient justification to go beyond the spec here so
let's just leave it.
If the only cause of this can be use by multiple threads, then updating
the error message to indicate incorrect usage would be good.
Scott Stark
Chief Technology Officer
JBoss Group, LLC
- Original Message -
From: Jason Dillon [EMAIL
No, because we currently seperate the creation of the DeploymentInfo
from the creation of its UCL. I'll leave the DeploymentInfo as is for
now.
Scott Stark
Chief Technology Officer
JBoss Group, LLC
- Original Message -
From: David Jencks
which is making it difficult to compile the testsuite ;)
snip
compile-classes-only:
[mkdir] Created dir:
/home/jason/ws/jboss/jboss-all/testsuite/output/classes
[javac] Compiling 728 source files to
/home/jason/ws/jboss/jboss-all/testsuite/output/classes
[javac]
I am wondering if this is the case, if an EJB's name will be unique across all
other bean's deployed in the vm... or if the name only has to be unique
inside of a ejb-jar deployment.
The current file-based SFSBPM uses the bean's name to determine the directory
to store session state files.
This is not unique across all beans in a vm, only within the ejb-jar.
Scott Stark
Chief Technology Officer
JBoss Group, LLC
- Original Message -
From: Jason Dillon [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Thursday, May 23, 2002 9:44
It's a string. I'll check in the fix. Annoying.
david
On 2002.05.24 00:19:44 -0400 Jason Dillon wrote:
which is making it difficult to compile the testsuite ;)
snip
compile-classes-only:
[mkdir] Created dir:
/home/jason/ws/jboss/jboss-all/testsuite/output/classes
[javac]
Hi Jason
This class is generated by XDoclet. Do you have any idea why it is
not generated by XDoclet ?
Thanx - Andy
- Original Message -
From: Jason Dillon [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Thursday, May 23, 2002 9:19 PM
Subject: [JBoss-dev] HEAD jboss/testsuite missing:
Hehe, I just didn't build it with
-Djavac.excludes='org/jboss/test/foedeployer/**'
Thanks though.
--jason
On Thursday 23 May 2002 10:02 pm, David Jencks wrote:
It's a string. I'll check in the fix. Annoying.
david
On 2002.05.24 00:19:44 -0400 Jason Dillon wrote:
which is making it
This class is generated by XDoclet. Do you have any idea why it is
not generated by XDoclet ?
Nope... I am still getting used to XDoclet... had a painful time trying to get
merge files to work a few days ago (unsuccessfully).
--jason
Thanx - Andy
- Original Message -
From:
66 matches
Mail list logo
