Dain,
I've moved this to the dev list because I think it's more appropriate.
I have now run the benchmark on 4.0. Initial results were disappointing
until I realised that debug log output is on in a HEAD build and off in
a Branch_3_0 build. Each time, the test was run three times:
1) Create
Hi,
I've attached a memory profile (which your email client may expand
inline - it's html) of JBoss in action.
This is a picture of our application importing several thousand phone
numbers from a text file, which are stored as new entity beans in a
single transaction. A NumbersBean has
3.2 HEAD contain additional synchronization fixes (courtesy of David
Jencks).
It smells like this sort of problem, so I'll backport these over the
weekend.
Steve Coy
On Friday, December 6, 2002, at 09:07 AM, Scott M Stark wrote:
I'm seeing sporadic NPEs like the following in the
Hi,
At some point during the evolution of JBoss 3.0.x, support for
declaring method-attributes was added into the jboss.xml deployment
descriptor.
However, the DTD (jboss_3_0.dtd) has not been updated.
If someone can confirm that this is just an oversight, I'll fix it up.
We just encountered
The fix certainly allows xdoclet to build itself, whereas it was
failing with the same problem we have in JBoss HEAD.
I can't check against JBoss HEAD until I get home tonight (its AM
here), but I'm a happy camper for my dev work now.
Steve Coy
On Thursday, March 13, 2003, at 04:15 AM,
I keep this on a Stickies note:
JBoss CVS
cvs -q -z3 co jboss-head
cvs -q -z3 co -r Branch_3_2 jboss-3.2
cvs -q -z3 co -r Branch_3_0 jboss-3.0
cvs -q -z3 co -r Branch_3_0 jboss-all
As far as I am aware, the last two are the same.
Steve Coy
On Thursday, March 13, 2003, at 04:43 PM,
A clean checkout of jboss-head is now building and running for me on
MacOS X and Java 1.4.1.
On Friday, March 14, 2003, at 05:41 AM, Dain Sundstrom wrote:
So how is it coming?
-dain
On Wednesday, March 12, 2003, at 06:02 PM, Stephen Coy wrote:
The fix certainly allows xdoclet to build
Unfortunately, all versions of xdoclet (except the one David J fixed)
have the same bug - using InputStream.available() to see how many bytes
are left in the file.
I'm part way thru getting JBoss 3.0.x to build with Apple's 1.4.1, but
I had to migrate HEAD's xdoclet into the source base and
e being stupid... but this wont help me anyway :(
When building with -verbose flag it correctly reports that it has detected a 1.3.1 jvm but then it still craches when it's time for the xdoclet task. Any ideas? Has it anything to do with the fact that it is forking the xdocletXDocletMain?
/L
tisd
I just got Branch_3_2 to build using this trick and with JAVA_HOME set to /System/Library/Frameworks/JavaVM.framework/Versions/1.3.1/Home rather than the /Library/Java/Home that I have below.
On Tuesday, March 18, 2003, at 10:27 PM, Stephen Coy wrote:
It's not you. I should have tested
I was about to send almost the same message.
Making this change works for me.
I'll check it in soon unless someone beats me to it, because I suspect
the culprit is asleep right now.
Steve Coy
On Thursday, March 20, 2003, at 10:44 PM, Bernd Koecke wrote:
Hi,
I'm using jboss-3.2 Branch_3_2
It's nearly done - I've been doing a fair amount of sanity checking
before I commit it.
One thing I noticed is that the test suite has many, many more failures
when run under Java 1.4.1, so I've had to rebuild and retest under
1.3.1 to make sure that I haven't broken anything.
Steve Coy
On
Hi,
Is it reasonable to assume that the jboss.net xdoclet subtask that was
being worked on nearly a year ago is currently not used in anger
anywhere? I can see a couple of flavours of the code (in
org.jboss.net.xdoclet and also thirdparty/xdoclet/jboss.net) in
Branch_3_2, but I can't see any
I've updated the build.xml files to use xdoclet 1.2 (pre b3).
It has the same jars as HEAD, although with correspondingly different
names.
I suspect that we should change these at some point to include version
info like a lot of the other jars.
i will tackle Branch_3_0 next, unless anyone has
Hi,
Is it reasonable to assume that the jboss.net xdoclet subtask that was
being worked on nearly a year ago is currently not used in anger
anywhere? I can see a couple of flavours of the code (in
org.jboss.net.xdoclet and also thirdparty/xdoclet/jboss.net) in
Branch_3_2, but I can't see any
Hi,
Have you tried this on any unix boxes recently?
Both my Mac and Linux boxes yield over 150 errors using 1.4.1 and over
50 using 1.3.1.
I run the all configuration.
Most of the errors seem to be deployment related in one way or another.
For example, the bank and bankiiop tests fail en
xdoclet stuff.
The stuff is used by the jboss.net testsuite (and some web-service
end-users
out there).
CGJ
-Ursprüngliche Nachricht-
Von: Stephen Coy [mailto:[EMAIL PROTECTED]
Gesendet: Donnerstag, 20. März 2003 23:45
An: [EMAIL PROTECTED]
Betreff: [JBoss-dev] jboss.net xdoclet subtask
Hi
Just mail them to me - I'm cleaning this up now. A couple of the
xdoclet todo's must have slipped through my screen.
The xdoclet upgrade was somewhat tedious :-)
Steve Coy
On Tuesday, March 25, 2003, at 09:26 PM, Bernd Koecke wrote:
Hi,
I found three minor bugs in the build.xml-files for
On Tuesday, March 25, 2003, at 09:26 PM, Bernd Koecke wrote:
The third is in connector/build.xml in target 'docs-javadocs'. I
changed 'sourcepath' from '${source.java}' to '${build.gen-src}'.
Why did you need to do this?
Running
[EMAIL PROTECTED] connector]$ ./build.sh docs
works fine for
Have you tried the equivalent of this sort of thing in your script?
[EMAIL PROTECTED] jboss-3.2]$ ANT_OPTS=-Xmx256M build/build.sh
Steve Coy
On Wednesday, March 26, 2003, at 01:11 AM, Chris Kimpton wrote:
--- Chris Kimpton [EMAIL PROTECTED] wrote:
Hi,
Does anyone get problems compiling HEAD
As in just running the all config, or are you actually clustering
with something else?
Running all certainly works in 3.2 - I've not tried HEAD in a while.
In fact, I've run all on a Mac and linux box together without
problems using JDK 1.4.1.
Steve Coy
On Thursday, April 3, 2003, at 04:32
Initial testing in Oracle 9i was not promising (using the latest driver
(Oracle JDBC Driver version - 9.0.2.0.0):
2002-06-18 23:39:05,843 DEBUG
[org.jboss.ejb.plugins.cmp.jdbc.JDBCStoreEntityCommand.SimpleEJB]
Executing SQL: UPDATE SIMPLE SET booleanPrimitive=?, booleanObject=?,
I've done some more poking at this, and modified JDBCUtil.setParameter
as follows:
//
// Binary types need to be converted to a byte array and set
//
if(isBinaryJDBCType(jdbcType))
{
byte[] bytes = convertObjectToByteArray(value);
if
Doh!
which fails completely because there is *no* t6_rs_role in the FROM
clause.
The relationships are:
Privs
*^
|
Roles
^
*|
UserRoleSeq
*^
|
Users
(best viewed in a fixed width font!)
On Monday, July 1, 2002, at 08:19 PM, [EMAIL PROTECTED] wrote:
which fails completely
Hi
Did this get fixed in Branch_3_0?
If it did, then it is still happening, because I've just encountered it
in a fresh build today.
If it's not in this branch yet, I think it's kind of important that it
goes in for 3.0.2, as it makes JBoss unreliable.
Full exception trace below.
Stephen
I think so too, because it's a real pain to do retrying from client code
We spent a great deal of time eliminating deadlocks in our application.
For what it's worth, my fix for bug #601097 eliminated many of them.
On Thursday, September 12, 2002, at 08:02 AM, Bill Burke wrote:
Great
Hi Dain,
I've been doing some work on making the binary data support more
portable in JDBCUtil.java.
In particular, I wanted to get all use cases of this working with
Oracle, where (despite what I may have said before) there are still
issues with BLOBS.
Current Oracle JDBC drivers
Hi David,
I'm currently working in Branch_3_2, trying to get our app running
under it, amongst other things.
We set up a number of different datasources, all pointing at various
Oracle databases, using the -service.xml style of configuration, and
also using security domains set up in
instance
not to
be equal since they have different classes...
Thanks again... I should have written a test...
david jencks
On 2002.09.30 04:57:05 -0400 Stephen Coy wrote:
Hi David,
I'm currently working in Branch_3_2, trying to get our app running
under it, amongst other things.
We set
Hi,
Currently, if the jdbctype of a database column is one of the above
types, the data is explicitly serialized by JBoss 3.x.
I've been researching this over the last few days and it seems to me
that the materialisation/dematerialisation of these types is really in
the domain of the JDBC
I suspected that something like that was a possibility. If that is the
case, then you may as well use one of the binary types, because using
JAVA_OBJECT doesn't get you anything at all.
On Wednesday, October 2, 2002, at 07:21 PM, Michael Bartmann wrote:
Stephen Coy wrote:
Hi,
Currently
You need to check the result of your checkout because you still don't
seem to have everything.
Also confirm that you checked out the right module:
cvs -z9 -q checkout -P jboss-head
This worked for me on the same platform as you.
Steve Coy
On Wednesday, October 23, 2002, at 04:39 PM, Robert
Did you do a clean build?
I've got:
12:07:09,229 INFO [Server] JBoss (MX MicroKernel) [3.0.4
Date:200211041046] Started in 0m:51s:0ms
Note the date in your build.
Steve Coy
On Tuesday, November 5, 2002, at 11:45 AM, Robert Nicholson wrote:
My Release id under output is now jboss-3.0.4 but
Hi Jason!
I noticed when I was running the CMP2 test suite against mysql that the
JDBC drivers prior to the latest had a time zone bug. The effect was
that a timestamp that was read back from the database would be an hour
or so different from what was stored.
This problem goes away with
This is one of my tests, which was working a few of weeks ago when I
checked it in.
I'll look into it tonight (ie. in about ten hours time) and try and
figure out what has happened to it.
Have any of the other cmp2 tests been changed recently?
Steve Coy
On Friday, November 15, 2002, at
In my experience, shutdown hooks don't work reliably on *any* version
of unix.
I was building a command line driven server style of app in java about
a year ago and discovered this.
Tried it on MacOS X (first), and then thinking it was just the Mac,
tried it on solaris (the deployment
I'd just like to add that I had to do a completely clean checkout before I could build
too. That's from CVS just a few minutes before this post.
No combination of clean or clobber would allow a build from a cvs update -dP.
_
View thread
The function [i]tableExists[/i] in this class makes the following jdbc call:
rs = dmd.getTables(con.getCatalog(), null, tableName, null);
This call seems to return a result if tableName exists in [i]any[/i] schema in the
database.
This is causing us some problems because we have each of our
Probably because I posted from the forum. It seems to be available there.
_
View thread online: http://main.jboss.org/thread.jsp?forum=66thread=12301
___
Jboss-development mailing list
[EMAIL
On Monday, April 8, 2002, at 05:35 PM, Georg Schmid wrote:
so one could use getSchema() instead of getCatalog() (and don't forget
to
use getSchemaTerm() :-)).
I agree that getSchema() would be handy here. Unfortunately, I don't
believe that it exists. There is a getSchemas(), but that's
I'm experiencing similar symptoms on MacOS X 10.1.3. The JVM behaves a
bit better though, because JBoss is the only impacted process.
Anyway, multiple successive deploys seems to consume memory. At some
point I start getting:
11:08:28,432 ERROR [STDERR] java.lang.OutOfMemoryError
11:08:28,433
the
time
to run your app through it and see what is leaking?
--jason
Quoting Hunter Hillegas [EMAIL PROTECTED]:
These exact symptoms occurred for me today for the first time...
I'm on OS X 10.1.3 also...
From: Stephen Coy [EMAIL PROTECTED]
Date: Fri, 12 Apr 2002 11:23:17 +1000
To: Mark
[execmodules] /Users/steve/Development/jboss-
all/testsuite/src/main/org/jboss/test/security/service/SecurityConfig.java:
91: cannot resolve symbol
[execmodules] symbol : method setConfig (java.net.URL)
[execmodules] location: class
org.jboss.security.auth.login.XMLLoginConfig
[execmodules]
I think that adding a schema name element as described below would be a
great idea. At the present moment, I am hacking
JDBCStartCommand.tableExists:
DatabaseMetaData dmd = con.getMetaData();
rs = dmd.getTables(con.getCatalog(), dmd.getUserName(),
tableName, null);
But I
On 2002.04.15 20:16:43 -0400 Stephen Coy wrote:
I think that adding a schema name element as described below would be a
great idea. At the present moment, I am hacking
JDBCStartCommand.tableExists:
DatabaseMetaData dmd = con.getMetaData();
rs = dmd.getTables(con.getCatalog
would tackle fixing this myself, but I don't yet know my way around
inside the guts of JBoss well enough yet. Maybe one of the gurus can
spend ten or fifteen minutes describing how to go about it - and then
I'll be happy to write and test the implementation.
Stephen Coy
together with their remote brethren in
SessionObjectOutputStream.replaceObject, not to mention the
corresponding activation code in SessionObjectInputStream.
On Wednesday, April 17, 2002, at 10:41 AM, Jason Dillon wrote:
Any clue why they fail?
--jason
Quoting Stephen Coy [EMAIL
is not marked as serializable...
From: Jason Dillon [EMAIL PROTECTED]
Date: Tue, 16 Apr 2002 17:41:19 -0700
To: Stephen Coy [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Subject: Re: [JBoss-dev] Stateful Session Beans are not EJB2.0 yet
Any clue why they fail?
--jason
Quoting Stephen Coy [EMAIL
version this applied to and no example
demonstrating the problem. Start with a testcase that uses a
custom container configuration to set a short passivation timeout.
- Original Message -
From: Stephen Coy [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Tuesday, April 16, 2002 5:23 PM
: v3.0 Rabbit Hole
Status: Closed
Resolution: Fixed
Priority: 6
Submitted By: Stephen Coy (scoy)
Assigned to: Scott M Stark (starksm)
Summary: Passivation of stateful sess beans fails
Initial Comment:
Section 7.4.1 of the EJB2.0 spec says that
EJBLocalHome and EJBLocalObject (amongst
others
I'm also running into a problem that may be related to this.
I have a .war (or the .war embedded in a .ear properly referenced in
application.xml.
Essentially, I have some .properties files jarred into the .war:
WEB-INF/
classes/
com/
1. The resource is being accessed from a struts taglib. So I guess
that means it is being accessed from a jar installed in WEB-INF/lib
2. It has been working for sometime (weeks) in JBoss HEAD up until a
day or two ago.
3. I would not expect .war classes to be able to see
Hi,
By looking for usage of jaws.xml files, I think I've uncovered some
holes in the test suite:
[steve@ws102 src]$ find . -name jaws.xml
./resources/bank/META-INF/jaws.xml
./resources/bankiiop/META-INF/jaws.xml
./resources/bench/ejb/META-INF/jaws.xml
./resources/dbtest/META-INF/jaws.xml
got to busy. Do
you want to try to get them running under JAWS and JBossCMP?
-dain
Stephen Coy wrote:
Hi,
By looking for usage of jaws.xml files, I think I've uncovered some
holes in the test suite:
[steve@ws102 src]$ find . -name jaws.xml
./resources/bank/META-INF/jaws.xml
, David Jencks wrote:
On 2002.04.29 23:35:20 -0400 Dain Sundstrom wrote:
Stephen Coy wrote:
I'm willing to tackle this. Do you have any idea what shape you would
like?
Not sure what that means.
Particular areas to cover?
To start the I'd just like to see the CMP 1.1 tests running under
I'm running the current Branch_3_0 code and the above message has
started appearing in the last few days when deploying my ejb jar file.
I have an Oracle DS setup as per the example in jboss-
all/connector/src/etc/example-config/oracle-service.xml and the
appropriate security realm set up in
, 2002, at 01:40 PM, Stephen Coy wrote:
I'm running the current Branch_3_0 code and the above message has
started appearing in the last few days when deploying my ejb jar file.
I have an Oracle DS setup as per the example in jboss-
all/connector/src/etc/example-config/oracle-service.xml
Stephen Coy wrote:
Futher investigation reveals the following code in jboss-
all/connector/src/main/org/jboss/resource/adapter/jdbc/local/LocalManagedConnection.
java:
private void checkIdentity(Subject subject, ConnectionRequestInfo
cri)
throws ResourceException
Your change below fixes the problem. I checked out clean copies of these
files to make sure.
On Wednesday, May 1, 2002, at 03:07 PM, David Jencks wrote:
On 2002.05.01 00:54:02 -0400 Stephen Coy wrote:
I was beginning to think that I was talking to myself here :-)
It looks like
Begin forwarded message:
Hi All,
I think I have found a bug when specifying your own finder method with EJB QL and Oracle.
The problem is that in EJB QL any comparisons to a boolean field must be made using the keywords TRUE or FALSE. When I do this I get an exception come back fromOracle
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
One of our guys came up with this target in our build file:
!-- Generate java from Jsp files and compile them --
target name=jsp-precompile
depends=prepare,compile,dummy_webdoclet unless=no-jsp-precompile
java classname=org.apache.jasper.JspC fork=true
I'm running the MacOS X 1.3.1 VM
Here's a thread dump, with a bit of log context around it:
11:40:53,918 INFO [Server] JBoss (MX MicroKernel) [3.0.0RC4
Date:200205301431] Started in 1m:26s:143ms
11:41:29,704 INFO [RefNumBean] Next refNum is: 2644
Full thread dump:
RMI TCP
Scott,
Have you noticed that this URL is broken?
On Monday, June 3, 2002, at 05:37 AM, [EMAIL PROTECTED] wrote:
See http://lubega.com/testarchive/${build.uid} for details of this test.
___
Don't miss the 2002 Sprint PCS
64 matches
Mail list logo
