On 24 Jul, Jason Dillon wrote:
> On Tue, 24 Jul 2001, Peter Antman wrote:
>
>> On 24 Jul, Jason Dillon wrote:
>> >> Well, that depends on taste. When the JMS RA was written it was mean to
>> >> not be dependant on JBoss at all, but should be possible to use in any
>> >> App server. There was one
hi,everybody:
i use MS Access .and i have 2 tables to work with.and i successfully load
the sun's jdbc:odbc database driver in the jboss.jcml
org.hsql.jdbcDriver,org.enhydra.instantdb
jdbc.idbDriver,sun.jdbc.odbc.JdbcOdbcDriver
and I can add a datasource in it:
org.opentools.mi
User: deerwood
Date: 01/07/24 21:56:51
Modified:src/main/org/jboss/ejb/plugins/jaws/metadata
JawsEntityMetaData.java
Log:
o Indentation and formatting according to project standards.
One spot found, where indentation does not match parser, possible Bug?
Feature Requests item #444343, was opened at 2001-07-24 21:46
You can respond by visiting:
http://sourceforge.net/tracker/?func=detail&atid=376688&aid=444343&group_id=22866
Category: None
Group: None
Status: Open
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (
User: user57
Date: 01/07/24 19:08:28
Modified:.modules
Log:
o place holder for a generic plugin module
Revision ChangesPath
1.7 +2 -0 CVSROOT/modules
Index: modules
===
RCS fil
Sorry about the empty log, I tend to do that when using CVS from emacs. I
will try not to do it again. This change adds the admin module and fixes
the name of jbosstest.
--jason
On Tue, 24 Jul 2001, Jason Dillon wrote:
> User: user57
> Date: 01/07/24 18:45:26
>
> Modified:.
JBoss daily test results
SUMMARY
Number of tests run: 145
Successful tests: 144
Errors:0
Failures: 1
[time of test: 25 July 2001 2:54 GMT]
[java.version: 1.3.0]
[
User: user57
Date: 01/07/24 18:45:26
Modified:.modules
Log:
*** empty log message ***
Revision ChangesPath
1.6 +3 -1 CVSROOT/modules
Index: modules
===
RCS file: /cvsroot/jboss/
User: user57
Date: 01/07/24 18:42:25
Modified:.modules
Log:
o changed the target directory of jboss-bm to jboss-bm (from jboss)
o forgot the add a change log for the first, so here it is:
o adding a test module called jboss-bm (for buildmagic) to create the
req
User: user57
Date: 01/07/24 18:39:33
Modified:.modules
Log:
*** empty log message ***
Revision ChangesPath
1.4 +46 -0 CVSROOT/modules
Index: modules
===
RCS file: /cvsroot/jboss/
Sounds like a good idea, I'll see about writing the adapters and submitting
a patch.
I'm not sure I understand what you mean about "more jmcl blocks" for the
jca version. Aren't there 3 "universal" mbeans for no, local, and xa
transactions, + the rar deployer, and then each datasource gets one m
User: jules_gosnell
Date: 01/07/24 18:35:53
Added: .JBoss-2.4.0.23_BETA-Jetty-3.1.RC6-1.zip
Log:
upgrade to latest available versions of JBoss and Jetty
only ship JMX support, rather than whole of Jetty3Extra to cut down size
Revision ChangesPath
1.1
Bugs item #444307, was opened at 2001-07-24 17:32
You can respond by visiting:
http://sourceforge.net/tracker/?func=detail&atid=376685&aid=444307&group_id=22866
Category: None
Group: v2.2.2 (stable)
Status: Open
Resolution: None
Priority: 5
Submitted By: Mike Williams (mdub)
Assigned to: Nobody/
User: jules_gosnell
Date: 01/07/24 17:08:01
Modified:jetty/src/build build.sh build.xml
Log:
upgrade to latest versions of JBoss and Jetty for new release
only include JMX support from Jetty3Extra to cut down on release size
Revision ChangesPath
1.5 +6 -6 co
User: jules_gosnell
Date: 01/07/24 17:08:00
Modified:jetty/etc README
Log:
upgrade to latest versions of JBoss and Jetty for new release
only include JMX support from Jetty3Extra to cut down on release size
Revision ChangesPath
1.2 +16 -1 contrib/jetty/etc/RE
User: jules_gosnell
Date: 01/07/24 17:08:00
Modified:jettyTODO
Log:
upgrade to latest versions of JBoss and Jetty for new release
only include JMX support from Jetty3Extra to cut down on release size
Revision ChangesPath
1.3 +11 -3 contrib/jetty/TODO
On Tue, 24 Jul 2001, David Jencks wrote:
> When Toby Allsop was developing the jca stuff in jbosscx he often wrote
> that all resource access would be moved to the jca framework soon ( I hope
> I'm not misquoting).
>
> I think this means rabbit hole, and I think this is a good idea.
>
> I think th
Feature Requests item #444258, was opened at 2001-07-24 13:42
You can respond by visiting:
http://sourceforge.net/tracker/?func=detail&atid=376688&aid=444258&group_id=22866
Category: None
Group: None
Status: Open
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (
I thought the JBossPool stuff would still be used and JCA is just a wrapper
for it?
Bill
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On Behalf Of David
> Jencks
> Sent: Tuesday, July 24, 2001 4:32 PM
> To: jboss-dev
> Subject: [JBoss-dev] Timeline for using
Well, I'm running out of ideas. One more... even less likely... and
assuming postrgres has essentially the same versioning/snapshot machinery
as firebird...
At one point running the banktest I was getting deadlocks with read
committed transaction isolation which went away when I changed to snaps
When Toby Allsop was developing the jca stuff in jbosscx he often wrote
that all resource access would be moved to the jca framework soon ( I hope
I'm not misquoting).
I think this means rabbit hole, and I think this is a good idea.
I think the time is NOW. Lets get everyone experimenting w
I thought maybe you had hit it ... but it turns out that it still gets stuck
... I added code to issue an explicit commit() before closing the Connection
but it still hung ... (took it a couple of hours, but it hung at the exact
same spot) ...
btw, this happens with other blocks of code in the sa
I say keep it simple and working with jboss- use log4j directly. If
someone wants to use it elsewhere we can deal with that later. After all,
the spec doesn't specify that anything in particular needs to be logged,
does it?
presumably we could bundle log4j into the jar if someone wanted to depl
Bugs item #444220, was opened at 2001-07-24 12:20
You can respond by visiting:
http://sourceforge.net/tracker/?func=detail&atid=376685&aid=444220&group_id=22866
Category: JBossCX
Group: v2.5 Rabbit Hole (unstable)
Status: Open
Resolution: None
Priority: 5
Submitted By: David Jencks (d_jencks)
As
Patches item #444219, was opened at 2001-07-24 12:16
You can respond by visiting:
http://sourceforge.net/tracker/?func=detail&atid=376687&aid=444219&group_id=22866
Category: JBossCX
Group: v2.5 Rabbit Hole (unstable)
Status: Open
Resolution: None
Priority: 5
Submitted By: David Jencks (d_jencks)
On Tue, 24 Jul 2001, Peter Antman wrote:
> On 24 Jul, Jason Dillon wrote:
> >> Well, that depends on taste. When the JMS RA was written it was mean to
> >> not be dependant on JBoss at all, but should be possible to use in any
> >> App server. There was one (easy to fix dependancy then). Changes
All,
What's the status of JBossTX? Is there anyone working on it? Is there
a schedule? Plan?
Thanks,
drob
___
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
Hi Bill,
just now I'll only pick up your table and complete what I can.
> Select for update supported
> ---
> Oracle YES 0)
> Sybase ?
> Informix ?
> DB2?
> Postgres ?
> mySQL ?
> BerkelyDB
Hello,
> AFAIK, file locks are new to JDK 1.4 and the behivor can vary slightly on
> different platforms.
Yes, but you can use a fake file locking mechanism as long as the JBoss
server is the only one to use these files.
> As I understand it, select for update is used to get an exclusive lock o
Looks good to me
Firebird/interbase supports select for update
david jencks
On 2001.07.24 11:28:04 -0400 Bill Burke wrote:
> As far as locking mechanimsms go, I really don't think one size fits all.
> I
> think it would be very useful for JBoss to have different pluggable
> locking
> mechanism
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On Behalf Of Dain
> Sundstrom
> Sent: Tuesday, July 24, 2001 11:44 AM
> To: [EMAIL PROTECTED]
> Subject: Re: [JBoss-dev] ditch entity locking in favor of
>
>
>
> AFAIK, file locks are new to JDK 1.4 and the behiv
AFAIK, file locks are new to JDK 1.4 and the behivor can vary slightly on
different platforms.
As I understand it, select for update is used to get an exclusive lock on
the data selected for the term of the transaction. This behivor is not
always desireable. There are certain application that do
As far as locking mechanimsms go, I really don't think one size fits all. I
think it would be very useful for JBoss to have different pluggable locking
mechanisms for entity beans and a well documented cookbook on when to use
each one. This email is my first stab at establishing some requirement
Why not just put a lock on the file? Same thing. I was thinking of
more in the abstract. The CMP mechanism or the database
type-mapping could define what actually meant.
Bill
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On Behalf Of
> Rickard Öberg
> Se
User: kimptoc
Date: 01/07/24 07:26:38
Modified:src/build/stylesheets summary2.xsl
Log:
highlight errors even more...
Revision ChangesPath
1.7 +9 -1 jbosstest/src/build/stylesheets/summary2.xsl
Index: summary2.xsl
===
Hm, this was not a nice one, and I am totally to blame. Looking into my
old EJB 2.0 spec from june 2000 I see it was optional then and still is.
Its only an "advice to the deployer". That is probably good if message
driven beans are to be used with something else than JMS, but it is NOT
god with J
User: kimptoc
Date: 01/07/24 06:37:46
Modified:src/build/stylesheets summary1.xsl summary2.xsl
Log:
add more info to the test report
Revision ChangesPath
1.8 +3 -0 jbosstest/src/build/stylesheets/summary1.xsl
Index: summary1.xsl
===
User: kimptoc
Date: 01/07/24 06:37:46
Modified:src/build build.sh run_tests.xml
Log:
add more info to the test report
Revision ChangesPath
1.6 +2 -2 jbosstest/src/build/build.sh
Index: build.sh
==
User: kimptoc
Date: 01/07/24 06:25:33
Modified:src/build/stylesheets summary1.xsl
Log:
xsl if test was broken - it now works
Revision ChangesPath
1.7 +1 -1 jbosstest/src/build/stylesheets/summary1.xsl
Index: summary1.xsl
===
Unfortunately, it doesn't suggest anything to me. Are you committing
before closing the connection? I know it's read only, but if postgres
works like firebird/interbase and the driver doesn't check enough for open
transactions when it closes a connection it may conceivably make a
difference.
da
Oops - sounds like an oversite on (perhaps my part). These jar files just
go too many places and it's all by hand.
I'm several days behind in my e-mail has anybody fixed this since it was
posted? I think there might also be some issues with the JBossCX versions
of the j2ee jar files.
Cheers
-
getSalesRank opens the JDBC connection, creates a PreparedStatement,
executes it, then takes the ResultSet and copies the data out into an
ArrayList of HashMaps... it then closes the ResultSet, followed by the
Statement, followed by the Connection ... It only returns the ArrayList to
the caller af
User: kimptoc
Date: 01/07/24 05:17:26
Modified:src/bin run.sh
Log:
added some info statements and don't try to guess HOTSPOT setting if JAVA_OPTS is
supplied
Revision ChangesPath
1.22 +13 -1 jboss/src/bin/run.sh
Index: run.sh
==
User: kimptoc
Date: 01/07/24 03:33:10
Modified:src/bin run.bat run.sh
Log:
add facility pass in options to the java vm - by defining the environment variable
JAVA_OPTS
Revision ChangesPath
1.22 +1 -1 jboss/src/bin/run.bat
Index: run.bat
==
On 24 Jul, Jason Dillon wrote:
>> Well, that depends on taste. When the JMS RA was written it was mean to
>> not be dependant on JBoss at all, but should be possible to use in any
>> App server. There was one (easy to fix dependancy then). Changes done
>> since then has tied it more closely to JBo
User: kimptoc
Date: 01/07/24 01:49:44
Modified:src/build/stylesheets summary1.xsl summary2.xsl
Log:
added some environment info to the test report
Revision ChangesPath
1.6 +9 -0 jbosstest/src/build/stylesheets/summary1.xsl
Index: summary1.xsl
=
User: kimptoc
Date: 01/07/24 01:49:44
Modified:src/build run_tests.xml
Log:
added some environment info to the test report
Revision ChangesPath
1.23 +19 -1 jbosstest/src/build/run_tests.xml
Index: run_tests.xml
===
> Well, that depends on taste. When the JMS RA was written it was mean to
> not be dependant on JBoss at all, but should be possible to use in any
> App server. There was one (easy to fix dependancy then). Changes done
> since then has tied it more closely to JBoss. I guess it would therefore
> be
Hi,
>
> /home/lubega/jbossro/jbosstest/src/build/run_tests.xml:112: Process
> fork failed.
> --- Nested Exception ---
> java.io.IOException: Resource temporarily unavailable
> at java.lang.UNIXProcess.forkAndExec(Native Method)
> at java.lang.UNIXProcess.(UNIXProcess.java:139)
This
=
==THIS IS AN AUTOMATED EMAIL - SEE http://www.lubega.com FOR DETAILS=
=
Buildfile: run_tests.xml
build:
prepare:
compile:
jar:
prepare:
bank-subproject:
50 matches
Mail list logo
