Hours later I give up and just fixed my app to connection and disconnect from
the session for each method call... which actually simplifies things for me
alot. Anyways... now I am getting this baby:
snip
java.rmi.ServerException: Application Error: tried to enter Stateful bean with
different
I was just thinking, waiting for tests to complete (they take hours to hit the
error scenerio)... and while I wait I get back to the meaningful work.
So, It occured to me that the classpath element really does not do too much
except deploy urls for archives which it has found, or has an
From looking over ServiceController and SARDeployer, it looks like this
would work, but the service would have to perform its work in create()...
though I am not sure about that.
Is there any reason why we don't start a serivce after it has been created if
it does not depend on anything?
It's broken :-(
After 10 mins of clicking I get an error at the end (see below).
I notified them and let you guys know when it works again.
Ciao,
Tobias
Error Occurred While Processing Request
Error Diagnostic Information
An error occurred while evaluating the expression:
#form.email# is
(tests still running) Well, it looks like with the current system this simply
will not work, as there is no hook to tell the mean it has been configured...
which is what I expect create is for, but this will not get invoked until all
of the mbeans from the current service descriptor have been
Bugs item #534542, was opened at 2002-03-24 21:50
You can respond by visiting:
http://sourceforge.net/tracker/?func=detailatid=376685aid=534542group_id=22866
Category: CatalinaBundle
Group: v2.4 (stable)
Status: Closed
Resolution: Invalid
Priority: 5
Submitted By: Moses Wang (mwang)
Assigned
Hay ,
I am running BMP Client but when i lookup by JNDI name i got an exception
Exception in thread main java.lang.NoClassDefFoundError: Ljavax/transaction/Transacti
at java.lang.Class.getDeclaredFields0(Native Method)
at
Hello,
This is not a question for JBoss-dev. Please post-it to the online forums.
Cheers,
Sacha
As for your questions, one of the JAR in JBOSS_HOME/client is missing from
your client application classpath.
-Message d'origine-
De : [EMAIL PROTECTED]
It wasn't working for me either but I just tried again and seems to be
working fine now.
Mike
On Sat, 2002-05-25 at 03:01, Tobias Frech wrote:
It's broken :-(
After 10 mins of clicking I get an error at the end (see below).
I notified them and let you guys know when it works again.
Ciao,
Does anyone care if I drop the org.jboss.ejb.FinderResults object? It
simply carries the results of a finder + some extra data, which is
always null. It is poorly implemented (no equals, or hashCode) and just
gets in my way.
Unless someone objects (quickly), it will be gone.
-dain
Help!
I am running build/build.sh on HEAD and Branch_3_0 trees just
checked out from CVS. On both trees build fails within xdoclet:
java.lang.OutOfMemoryError: unable to create new native thread
(Branch 3.0 error included below.)
Both Sun and IBM JDKs are giving me the same error. My
Hello,
I am looking at contributing to the Jboss project, and I would be
interested to know if there is any outstanding task/bug that would be a
good one to cut my teeth on.
Looking forward to replies.
Matthew
___
Don't miss the
A run of the test-suite of the current head revision
produces the JDOMException
2002-05-26 00:27:39,875 INFO [org.jboss.deployment.SARDeployer] Created
ServiceModule:
jboss.management.single:J2EEServer=Single,j2eeType=ServiceModule,name=user-xmbean.sar
2002-05-26 00:27:42,890 ERROR [STDERR]
I was finially able to get my tests to pass with insainly huge jobs, which
would have failed for sure before. After I added more trace logging to
JBossMQ SpySession and friends, it looks like one tx was ending, while the
other was trying to add a message, but because of my misuse the session
I'm running the test suite for CVS head (200205252357)
on W2K / Sun JDK 1.4.
The exceptions in the report say that a message could not
be removed due to not being able to delete the record in the database (0 rows
affected), but the log shows that
a CCE occured:
2002-05-26 00:26:51,234 WARN
Number of tests run: 750
Successful tests: 726
Errors:19
Failures: 5
[time of test: 26 May 2002 0:46 GMT]
[java.version: 1.3.0]
[java.vendor: IBM Corporation]
Number of tests run: 748
Successful tests: 724
Errors:19
Failures: 5
[time of test: 26 May 2002 2:0 GMT]
[java.version: 1.3.0]
[java.vendor: IBM Corporation]
It is gone and all the code that referenced it has been updated.
-dain
Dain Sundstrom wrote:
Does anyone care if I drop the org.jboss.ejb.FinderResults object? It
simply carries the results of a finder + some extra data, which is
always null. It is poorly implemented (no equals, or
Bugs item #551533, was opened at 2002-05-02 13:40
You can respond by visiting:
http://sourceforge.net/tracker/?func=detailatid=376685aid=551533group_id=22866
Category: JBossCMP
Group: v3.0 Rabbit Hole
Status: Open
Resolution: None
Priority: 5
Submitted By: Alexei Guevara (aguevara)
Assigned to:
Bugs item #545974, was opened at 2002-04-19 01:46
You can respond by visiting:
http://sourceforge.net/tracker/?func=detailatid=376685aid=545974group_id=22866
Category: JBossCMP
Group: v3.0 Rabbit Hole
Status: Open
Resolution: None
Priority: 5
Submitted By: Marco Ladermann (mpl)
Assigned to:
Bugs item #555070, was opened at 2002-05-12 05:49
You can respond by visiting:
http://sourceforge.net/tracker/?func=detailatid=376685aid=555070group_id=22866
Category: JBossCMP
Group: v3.0 Rabbit Hole
Status: Open
Resolution: None
Priority: 5
Submitted By: Dylan van Iersel (dviersel)
Assigned
Bugs item #557699, was opened at 2002-05-18 12:12
You can respond by visiting:
http://sourceforge.net/tracker/?func=detailatid=376685aid=557699group_id=22866
Category: JBossCMP
Group: v3.0 Rabbit Hole
Status: Open
Resolution: None
Priority: 5
Submitted By: Julien Viet (cooperfbi)
Assigned to:
Bugs item #559018, was opened at 2002-05-22 00: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
Bugs item #559024, was opened at 2002-05-22 01:13
You can respond by visiting:
http://sourceforge.net/tracker/?func=detailatid=376685aid=559024group_id=22866
Category: JBossCMP
Group: v3.0 Rabbit Hole
Status: Open
Resolution: None
Priority: 5
Submitted By: Henk Laracker (hlaracker)
Assigned to:
Bugs item #554535, was opened at 2002-05-10 10:14
You can respond by visiting:
http://sourceforge.net/tracker/?func=detailatid=376685aid=554535group_id=22866
Category: JBossCMP
Group: v2.4 (stable)
Status: Open
Resolution: None
Priority: 5
Submitted By: Niall O'Sullivan (nosullivan)
Assigned
Confirmed. It's working again.
You know what to do ... :)
Ciao,
Tobias
Mike Heath wrote:
It wasn't working for me either but I just tried again and seems to be
working fine now.
Mike
On Sat, 2002-05-25 at 03:01, Tobias Frech wrote:
It's broken :-(
After 10 mins of clicking I get
Any reason why we are putting dtd files in the root of the release instead of
under docs?
--jason
___
Don't miss the 2002 Sprint PCS Application Developer's Conference
August 25-28 in Las Vegas --
Found the cause: a recent change on server/build.xml made xdoclet
to be called on a fileset too big (name=**/*.java).
I will revert the change. But it is strange that nobody else saw
this... I have tried two Linux machines (a laptop with 128M and a
box with 384M) with the same result:
I have had no problems building on Linux with 1.3.1 and 1.4, though my laptop
has 512, but that should not matter really.
Eventually we will have everything listed... in fact we have a similar include
for the javac task, so perhaps XDoclet needs to be fixed to not cache so much
data at one
Technically speaking the docset is not 'too big', it is simply causes
too many native threads to be created for most 'default' Linux
distributions.
Run the sample program and you should with a Linux 2.4 system get around
220ish threads. The options without the change are as follows.
- Original Message -
From: Matthew Tippett [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Saturday, May 25, 2002 9:30 PM
Subject: Re: [JBoss-dev] Build not working on Linux?
So the 'fix' is a workaround. (Probably is the best solution for the
moment, but it isn't a bug in the code,
Maybe this is the reason that the build has been barfing on MacOS X as
well.
I've been getting the same problem that Scott Stark mentioned yesterday,
but it is not very deterministic.
ie. yesterday's CVS checkout stops in a different place to today's CVS
checkout.
It's not difficult to
What is XDoclet doing with so many threads?
--jason
On Saturday 25 May 2002 09:30 pm, Matthew Tippett wrote:
Technically speaking the docset is not 'too big', it is simply causes
too many native threads to be created for most 'default' Linux
distributions.
Run the sample program and you
Number of tests run: 599
Successful tests: 599
Errors:0
Failures: 0
[time of test: 25 May 2002 21:49 GMT]
[java.version: 1.3.1]
[java.vendor: Apple Computer, Inc.]
Good. Do they also know about the problem parsing '\u' ? Or that when a
parse problem occurs it hangs the build... which sucks, as the compiler can
*sometimes* do a better job of informing where the problem was.
--jason
On Saturday 25 May 2002 10:01 pm, Andreas Schaefer wrote:
Hi
Hi Jason
On the XDoclet dev mailing list they are already talking
about this problem. Didn't follow this discussion but
I think they are aware of that problem.
Andy
- Original Message -
From: Jason Dillon [EMAIL PROTECTED]
To: [EMAIL PROTECTED]; Matthew Tippett
[EMAIL PROTECTED]
Sent:
36 matches
Mail list logo
