> 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:
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
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 missin
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
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 ;)
>
>
> compile-classes-only:
> [mkdir] Created dir:
> /home/jason/ws/jboss/jboss-all/testsuite/output/classes
> [javac] Co
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. If
which is making it difficult to compile the testsuite ;)
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]
/home/jason/ws/jboss/jb
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"
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 PR
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.
>
> xxx
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 Stark
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 c
Bugs item #506914, was opened at 2002-01-22 06:36
You can respond by visiting:
http://sourceforge.net/tracker/?func=detail&atid=376685&aid=506914&group_id=22866
Category: JBossMQ
Group: v2.4 (stable)
>Status: Pending
Resolution: None
Priority: 5
Submitted By: Cesar Hernandez Fuente (chfuente)
As
Bugs item #501820, was opened at 2002-01-10 09:40
You can respond by visiting:
http://sourceforge.net/tracker/?func=detail&atid=376685&aid=501820&group_id=22866
Category: JBossMQ
Group: v2.4 (stable)
>Status: Closed
>Resolution: Invalid
Priority: 5
Submitted By: Corby (corby)
Assigned to: Nobody
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: Thur
I just re-ran my tests with my wrapper object synchronized on all methods
which call the SFSB and I still see invalid tx id exceptions. Which makes me
think this isn't a problem with reentrance into the SFSB, but something with
the JMS RA Connection/Session pooling.
--jason
On Thursday 23 M
He who codes wins the vote. This issue does not bother me enough to change
anything.
Regards,
Hiram
>From: David Maplesden <[EMAIL PROTECTED]>
>Reply-To: [EMAIL PROTECTED]
>To: "'[EMAIL PROTECTED]'"
><[EMAIL PROTECTED]>
>Subject: RE: [JBoss-dev] Seeing occasional Invalid tx id with JMS RA
>
No, unfortunately not because the JMX server just casts the
mbean for the class loader into a ClassLoader instance. I can
make the DeploymentInfo an MBean that exposes the UCL
for one stop shopping while I'm mucking around in here, but
the UCL mbean for the service still needs to be registered
ind
> 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 server.log)
Log4jService has no references to other mbeans. It was doing
this in the low level preRegister callback before so its safe.
Scott Stark
Chief Technology Officer
JBoss Group, LLC
- Original Message -
From: "David Jencks" <[EMAIL PROTECTED]
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
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 co
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 2
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
Su
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 want?
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
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
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]>
Se
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 eac
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
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 M
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 reso
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
___
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
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
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 Co
> 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 fact that 2 threads are trying to access a single
> session object simulatiously.
That was what I was leaning twords... an
> 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 st
Bugs item #559018, was opened at 2002-05-22 13:57
You can respond by visiting:
http://sourceforge.net/tracker/?func=detail&atid=376685&aid=559018&group_id=22866
Category: JBossCMP
Group: v3.0 Rabbit Hole
Status: Open
Resolution: None
Priority: 5
Submitted By: Vincent Zhao (vincentzhao)
Assigned
I hate to disagree with Scott and Hiram but I feel that just because the
spec says Sessions should only be used in 1 thread does not neccessarily
mean that we should restrict their usage as such.
I know a Session only makes sense in the context of a single process, but
this might still entail t
> 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...
Right, which is where I screwed up.
So, the question now is, should we put in so
yes. no sharing. JMS session are used to demarcate transactions. Having 2
threads demarcating transactions would not be good.
Regards,
Hiram
>From: David Maplesden <[EMAIL PROTECTED]>
>Reply-To: [EMAIL PROTECTED]
>To: "'[EMAIL PROTECTED]'"
><[EMAIL PROTECTED]>
>Subject: RE: [JBoss-dev] Se
>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
> 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 excepti
> 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
>
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: T
I'm not sure about best solution to the SFSB stuff.
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 it
myself.
David.
> 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
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.
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'
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
__
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 mo
=
==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 Edi
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]
[java.v
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 th
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 ha
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.]
[ja
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 Fi
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 clo
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 specialize
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 ba
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
>
>
>
>
> _
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 Dev
> 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 m
Bugs item #559628, was opened at 2002-05-23 08:43
You can respond by visiting:
http://sourceforge.net/tracker/?func=detail&atid=376685&aid=559628&group_id=22866
Category: JBossServer
Group: v2.4 (stable)
Status: Open
Resolution: None
Priority: 5
Submitted By: Michael Hussey (mhussey)
Assigned to
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 lik
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.]
[jav
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 -
Fro
> 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
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-
It seems to indicate that you are not using JNDI on port 1099 but HA-JNDI on
port 1100.
> -Message d'origine-
> De : [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]De la part de
> Scott M Stark
> Envoyé : jeudi, 23 mai 2002 09:20
> À : [EMAIL PROTECTED]
> Objet : [JBoss-dev] Why is this be
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.]
[j
72 matches
Mail list logo
