`cvs diff` in the
jboss/src/main/ejb/plugins/jaws directory. Can a comitter please commit
this, or tell me how to produce a more acceptable patch? (or tell me to
go away, that's fine too)
thanks,
danch
Index: jdbc/JDBCCommand.java
This patch has been committed
danch wrote:
A while back there was a thread on the 'debug' variable within JAWS. I
was quite vocal in saying that it should not be static final and that it
should be mutable at run time. I've made this configurable through
jaws.xml
User: danch
Date: 01/03/26 07:55:43
Modified:src/main/org/jboss/ejb/plugins/jaws/metadata
JawsEntityMetaData.java
Log:
Bill Burke's patch to do sql 'select ... for update' for smoother locking at the DB
level
Revision ChangesPath
1.7
production applications.
Right now, it's all in the org.jboss.util package. Should I leave it
there or move it?
thanks,
danch
marc fleury wrote:
|
|
||I've spent the day running some test similiar to Paul's.
||
||My environment is Linux on a PIII 500, running Sun's 1.3 and
||1.3.1beta JDKs
User: danch
Date: 01/04/03 21:49:52
Added: src/main/org/jboss/util CounterInterceptor.java
CounterService.java CounterServiceMBean.java
Log:
MBean and interceptor to allow statistics gathering on time spent in EJB methods
Revision ChangesPath
I've moved this over to jboss-dev, where this bit will seem more
appropriate.
danch wrote:
For what it's worth, I've seen similiar behavior under heavy threading
(see archives under JBoss vs. Orion or Performance). I'm suspicious of
the transaction interceptor (just because it seems to take
Replying to dev.
Should we have separate Unix vs. Windows binaries, just to ensure that
we get things like this (and the line ending thing) right?
-danch
[EMAIL PROTECTED] wrote:
Should I post this here or to dev?
run.sh doesn't default to have execute permissions which is easy to fix
Have you tried putting the jetty mbean stuff in jboss.conf rather than
jboss.jcml? I believe (but I'm not a JMX expert) that the Service
(init,start,stop,destroy) only applies to mbeans listed in jboss.jcml,
not those in jboss.conf.
Julian Gosnell wrote:
Greg has released JettyJMX, a packaged
In the short term, I'll send you a patch. Probably there would be a
JBoss 2.2.1 release at some point, as well.
Bear in mind, however, that I really don't think we've found the bug
that you're seeing: the race I found really only (as far as I can tell)
effected cases where a Hueristic exception
so that we have real-world(ish) test cases.
-danch
___
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
off on a release until tommorrow?
thanks,
danch
___
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
User: danch
Date: 01/04/16 18:28:41
Modified:src/main/org/jboss/tm Tag: Branch_2_2 TxCapsule.java
Log:
prevent race condition and lock contention
Revision ChangesPath
No revision
No revision
1.24.2.1 +9 -4
User: danch
Date: 01/04/16 18:29:06
Modified:src/main/org/jboss/tm TxCapsule.java
Log:
prevent race condition and lock contention
Revision ChangesPath
1.25 +9 -4 jboss/src/main/org/jboss/tm/TxCapsule.java
Index: TxCapsule.java
Yes. Scott was planning on packaging that up tommorrow or so.
Jim Archer wrote:
Hi Dan...
--On Monday, April 16, 2001 6:49 PM -0700 [EMAIL PROTECTED] wrote:
Group: v2.2.1
Does this mean that this fix will be released with the 2.2.1 bug fix
release this week?
Thanks!
Jim
Is it possible that people upgrading will need to put the 'java:' back
into their res-jndi-names where appropriate?
[EMAIL PROTECTED] wrote:
Change Notes item #416812, was updated on 2001-04-17 12:47
You can respond by visiting:
Your code itself shouldn't change. I believe that it will just be places
where you're mapping resource references in jboss.xml that would change,
or have I misinterpreted, Scott?
Jim Archer wrote:
Can this change be postponed? Some of us are using code generators and it
would be more than a
Maybe support the java:/ defaulting in 2.2.1 but issue a deprecation
warning?
Scott M Stark wrote:
I don't have a strong opinion on its inclusion so if in general this is going to
cause more problems then it solves it can be left out of the 2.2.1 release.
An ApplicationMetaData level
You Rock!
[EMAIL PROTECTED] wrote:
User: juhalindfors
Date: 01/04/18 08:25:51
Modified:src/main/org/jboss/ejb/plugins MetricsInterceptor.java
Log:
Reimplemented to move msg.publish() overhead out of the invocation thread.
Confidential e-mail for addressee only. Access to
the documentation of
jaws/standardjaws.xml has been on my plate for a while now.
-danch
Linda Hagedorn wrote:
Hello,
Can anyone tell me if jaws can generate Oracle create syntax similar to the
following examples? I'm an Oracle DBA and new to the jaws product. I need
to create indexes
).
If this seems like a good idea, should this setting be in jboss.xml (and
cover BMP and CMP entities as well as sessions), or in jaws.xml
(covering _only_ CMP entities, since others are free to call the
resource manager's APIs)?
thanks,
danch
___
Jboss
I was about to tackle the most significant performance related problem
in JAWS (see the discussion and feature request on CMP and finders:
optimized and optimize collection finders, respectively)
I've been building database applications for quite a while now (damn
near the only thing i've
marc fleury wrote:
Ok is the patchdir stuff used at all?
I've used that a couple of times.
marc
_
Marc Fleury, Ph.D
[EMAIL PROTECTED]
_
___
Jboss-development mailing list
[EMAIL PROTECTED]
it yourself. Please describe
marc
|-Original Message-
|From: [EMAIL PROTECTED]
|[mailto:[EMAIL PROTECTED]]On Behalf Of danch
|Sent: Monday, May 07, 2001 10:27 PM
|To: [EMAIL PROTECTED]
|Subject: Re: [JBoss-dev] Main.java, let's clean it up
|
|
|marc fleury wrote:
|
| Ok
Note that I've already a feature request for the optimization of finders.
Bordet, Simone wrote:
H,
our grumpy JBoss is back, and what a comeback !!!
Marc, I'll suggest you to add TODO tasks on the sourceforge site, so that
it's easier to keep track of them, I would have added
Somewhere on the sourceforge site there's a page on enabling key based
authentication for ssh. This should do what you need.
Julian Gosnell wrote:
Every time I interact with JBoss CVS I am asked for a
password. My Emacs does not seem to know how to deal
with this. (I'm using vc on top of
with no new features, or is it also
low-risk new features?
My personal opinion would be bug fixes only.
-danch
___
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
User: danch
Date: 01/05/26 17:49:16
Added: src/main/org/jboss/util FinderResults.java
Log:
added 'read-ahead' option for finders in JAWS
Revision ChangesPath
1.1 jboss/src/main/org/jboss/util/FinderResults.java
Index: FinderResults.java
User: danch
Date: 01/05/26 17:49:15
Modified:src/main/org/jboss/ejb/plugins/jaws/bmp
CustomFindByEntitiesCommand.java
Log:
added 'read-ahead' option for finders in JAWS
Revision ChangesPath
1.3 +9 -6
jboss/src/main/org/jboss/ejb
User: danch
Date: 01/05/26 17:49:15
Modified:src/main/org/jboss/ejb/plugins/jaws
JAWSPersistenceManager.java JPMCommandFactory.java
JPMFindEntitiesCommand.java
Added: src/main/org/jboss/ejb/plugins/jaws
User: danch
Date: 01/05/26 17:49:14
Modified:src/main/org/jboss/ejb EntityPersistenceManager.java
EntityPersistenceStore.java
Log:
added 'read-ahead' option for finders in JAWS
Revision ChangesPath
1.5 +3 -1 jboss/src/main/org/jboss
User: danch
Date: 01/05/26 17:49:17
Modified:src/resources/org/jboss/metadata jaws.dtd
Log:
added 'read-ahead' option for finders in JAWS
Revision ChangesPath
1.3 +18 -4 jboss/src/resources/org/jboss/metadata/jaws.dtd
Index: jaws.dtd
User: danch
Date: 01/05/26 17:49:15
Modified:src/main/org/jboss/ejb/plugins
CMPFilePersistenceManager.java
CMPPersistenceManager.java
Log:
added 'read-ahead' option for finders in JAWS
Revision ChangesPath
1.9 +10
User: danch
Date: 01/05/26 17:49:16
Modified:src/main/org/jboss/ejb/plugins/jaws/jdbc
JDBCCommandFactory.java JDBCFindAllCommand.java
JDBCFindEntitiesCommand.java
JDBCFindEntityCommand.java
User: danch
Date: 01/05/27 10:59:00
Modified:src/main/org/jboss/ejb/plugins/jaws/jdbc
JDBCCommandFactory.java
JDBCDefinedFinderCommand.java
JDBCFindByCommand.java
Log:
Fixed build errors I introduced
It's in. Sorry for the delay - I was unable to test myself due to
problems with Postgres and blobs.
thanks,
danch
Scott M Stark wrote:
No, I have not created the JBoss_2_2_2 tag because I'm waiting for a jaws update.
I will merge the change.
- Original Message -
From: Juha
User: danch
Date: 01/05/30 16:00:42
Modified:src/main/org/jboss/ejb/plugins/jaws/jdbc JDBCCommand.java
Log:
Fixed bug #424059 CMP field of type Object is broken
Revision ChangesPath
1.31 +27 -23jboss/src/main/org/jboss/ejb/plugins/jaws/jdbc/JDBCCommand.java
User: danch
Date: 01/05/30 15:47:49
Modified:src/main/org/jboss/ejb/plugins/jaws/jdbc Tag: Branch_2_2
JDBCCommand.java
Log:
Fixed bug #424059 - CMP field of type object fails
Revision ChangesPath
No revision
James Cook wrote:
I assume that tests are run from the HEAD branch? If so, I would also assume
that the current 2.2.2 (stable?) release also suffered quite a few
errors/failures?
Why would you assume that? HEAD and 2.2.2 are quite distinctly different
branches.
datasets and large
numbers of concurrent users.
-danch
___
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
Georg Rehfeld wrote:
Hi Ole,
I could easily commit that change, but:
Am I the only one who has seen this problem?
Might be, you are the only one testing? :-)
I think the problem was only on Unix systems.
___
Jboss-development mailing
danch (Dan Christopherson) wrote:
Scott M Stark wrote:
But your change works fine in the 2.2.2 codebase as I ran the same
testsuite
against it before making the release and I reran it today and it does
not show
the same errors. Is there a difference in the code comitted to the
2.2.2
User: danch
Date: 01/06/05 18:07:40
Modified:src/main/org/jboss/ejb/plugins/jaws/metadata
JawsEntityMetaData.java
Log:
Fixed bug caused by change in load operation associated with finder optimization.
Revision ChangesPath
1.9 +3 -1
User: danch
Date: 01/06/05 18:07:40
Modified:src/main/org/jboss/ejb/plugins/jaws/jdbc JDBCCommand.java
JDBCLoadEntityCommand.java
Log:
Fixed bug caused by change in load operation associated with finder optimization.
Revision ChangesPath
1.32
As of about 3 minutes ago, the 'bank' test is green in JUnit again.
___
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
OK, I think we're talking about the same sort of thing. This looks good.
Bill Burke wrote:
Sorry my pseudo code was sooo confusing.
Here's something better
synchronized(ctx)
{
while (ctx.isLocked()) {
ctx.wait(5000);
if (ctx.isLocked())
K.V. Vinay Menon wrote:
To be honest if the response time for a lookup is 5 seconds your clients
would go shopping elsewhere!
5 seconds is the worst case: normally you'll be notified long before
that happens. Actually 5 seconds is so much worst case that that's
probably about the point
I tried to send this out earlier today, but it never showed up (trouble
on my end)
The reason I was suggesting an oracle specific option name was because I
really think that we need to use the Oracle specific syntax to return
the rowid value on inserts.
Georg Rehfeld wrote:
Dear Vinay,
-for-update feature(CMP) or make the BMP developers handle
the locking.
That will require multiple instances of each bean to be spec compliant.
-danch
___
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss
User: danch
Date: 01/06/12 23:52:17
Modified:src/main/org/jboss/ejb/plugins/jaws
JPMLoadEntitiesCommand.java
Log:
second pass at collection finder optimization - this fixes problem with defined
finders doing joins
Revision ChangesPath
1.2
User: danch
Date: 01/06/15 16:59:07
Modified:src/main/org/jboss/ejb/plugins CMPPersistenceManager.java
Log:
Clean up of stuff left over in CMPPersistenceManager from 1st round finder
optimization: my test (1000 entities) now completes in about 8.7 seconds - cached was
6.4
User: danch
Date: 01/06/15 16:59:07
Modified:src/main/org/jboss/ejb/plugins/jaws/jdbc
JDBCLoadEntitiesCommand.java
Log:
Clean up of stuff left over in CMPPersistenceManager from 1st round finder
optimization: my test (1000 entities) now completes
User: danch
Date: 01/06/15 17:49:32
Modified:src/docs customizingjaws.xml
Log:
added doc for read-ahead option
Revision ChangesPath
1.8 +42 -0 manual/src/docs/customizingjaws.xml
Index: customizingjaws.xml
Ya, I realized I'd missed that right after I committed. If you want to
get that in there, go ahead.
thanks,
danch
Bill Burke wrote:
Danch,
Great work on the finder optimization stuff. Our project really needs
this feature for performance tuning. One thing you forgot I think
of the embedded finder to finderDelegate: I think
that's more descriptive now.
I'm going to test that a bit more, then check in.
-danch
[EMAIL PROTECTED] wrote:
User: patriot1burke
Date: 01/06/21 14:57:22
___
Jboss-development mailing list
Chris' nightly test runs have only been failing with these OutOfMemory
exceptions for the last couple of nights. Either it was a recent change
that caused this or a recently added test that brought it into the open
-danch
Hiram Chirino wrote:
I'm embarased.
I'll look into it right away
User: danch
Date: 01/06/21 20:24:49
Modified:src/main/org/jboss/ejb/plugins/jaws/jdbc JDBCCommand.java
JDBCCommandFactory.java
JDBCPreloadFinderCommand.java
Log:
extended Bill's earlier work to work on findAll and findBy commands
User: danch
Date: 01/06/21 20:47:40
Modified:src/docs customizingjaws.xml
Log:
added brief/terse explanation of the interaction between read-ahead option and
transactions
Revision ChangesPath
1.9 +267 -259 manual/src/docs/customizingjaws.xml
Index
User: danch
Date: 01/06/21 22:04:23
Modified:src/main/org/jboss/ejb/plugins/jaws/jdbc JDBCCommand.java
JDBCInitCommand.java
Log:
merged patch 424409 - not null constraint for columns (thanks to David Jencks) also
fixed a bug where remapping the name
User: danch
Date: 01/06/21 22:04:24
Modified:src/main/org/jboss/ejb/plugins/jaws/metadata
CMPFieldMetaData.java
Log:
merged patch 424409 - not null constraint for columns (thanks to David Jencks) also
fixed a bug where remapping the name of a primary key
User: danch
Date: 01/06/21 22:41:05
Modified:src/main/org/jboss/ejb/plugins/jaws/jdbc Tag: Branch_2_4
JDBCInitCommand.java
Log:
fix bug when PK field != columnname
Revision ChangesPath
No revision
No reason, really. Enter it as a feature request. If you've time, post a
patch, but look at Dain's 2.0 CMP stuff first
-danch
Vinay Menon wrote:
Hello,
Is there any specific reason why the datasource tag needs to be
applicable to the entire JAWS xml? This would mean that all
that are in different
databases are in different transactions. But then there'd be no reason
not to split them into different ejb-jar files.
-danch
___
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss
so far.
-danch
___
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
is changed by another
transaction in JBoss, it will go through JAWS load code first, so the
data will be taken out of the read-ahead before it is modified. Have I
missed something?
thanks,
danch
___
Jboss-development mailing list
[EMAIL PROTECTED
as an attribute of the
transaction itself.
-danch
___
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
, then I can certainly agree with your
'theoretical' case.
-danch
___
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
User: danch
Date: 01/06/29 21:32:32
jbosstest/src/main/org/jboss/test/readahead/interfaces - New directory
___
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
User: danch
Date: 01/06/29 21:33:31
jbosstest/src/resources/readahead - New directory
___
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
User: danch
Date: 01/06/29 21:34:16
jbosstest/src/resources/readahead/META-INF - New directory
___
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
User: danch
Date: 01/06/29 21:38:05
Added: src/build/subprojects build-readahead.xml
Log:
Added tests for readahead functionality. Note that this only checks to see if they
work: it doesn't verify that it's actually performing well
Revision ChangesPath
1.1
User: danch
Date: 01/06/29 21:38:05
Modified:src/build build.xml
Log:
Added tests for readahead functionality. Note that this only checks to see if they
work: it doesn't verify that it's actually performing well
Revision ChangesPath
1.37 +7 -2 jbosstest
User: danch
Date: 01/06/29 21:38:06
Added: src/main/org/jboss/test/readahead/interfaces
AddressHome.java AddressPK.java AddressRemote.java
CMPFindTestEntityHome.java
CMPFindTestEntityRemote.java
User: danch
Date: 01/06/29 21:38:06
Added: src/resources/readahead client.policy jndi.properties
Log:
Added tests for readahead functionality. Note that this only checks to see if they
work: it doesn't verify that it's actually performing well
Revision ChangesPath
User: danch
Date: 01/06/29 21:38:06
Added: src/resources/readahead/META-INF ejb-jar.xml jaws.xml
Log:
Added tests for readahead functionality. Note that this only checks to see if they
work: it doesn't verify that it's actually performing well
Revision ChangesPath
User: danch
Date: 01/06/29 21:38:05
Added: src/bin readaheadtest.bat readaheadtest.sh
Log:
Added tests for readahead functionality. Note that this only checks to see if they
work: it doesn't verify that it's actually performing well
Revision ChangesPath
1.1
User: danch
Date: 01/06/29 21:38:06
Added: src/main/org/jboss/test/readahead/test Main.java
Log:
Added tests for readahead functionality. Note that this only checks to see if they
work: it doesn't verify that it's actually performing well
Revision ChangesPath
1.1
User: danch
Date: 01/06/29 21:32:14
jbosstest/src/main/org/jboss/test/readahead - New directory
___
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
is bad - you could be taking 20 applications down just
because 1 has a database that went down. This like inability to connect
should also be logged at error level.
If nobody objects, I'll take this on and add this feature for 3.0.
-danch.
Ferguson, Doug wrote:
Hi,
This is a thread that I
User: danch
Date: 01/07/01 20:20:08
Modified:src/main/org/jboss/pool/jdbc/xa XAPoolDataSource.java
Log:
Added timeout parameter for blocking
Revision ChangesPath
1.2 +6 -0 jbosspool/src/main/org/jboss/pool/jdbc/xa/XAPoolDataSource.java
Index
User: danch
Date: 01/07/01 20:29:14
Modified:src/lib jbosspool.jar
Log:
allow specification of a timeout in JDBC connection pools when blocking is enabled
Revision ChangesPath
1.2 +356 -359 jboss/src/lib/jbosspool.jar
Binary file
in an unusual order? Just guessing.
-danch
Bordet, Simone wrote:
Yo,
I'm back to real life !
I'd suggest not to use HEAD tag, it's used by CVS and does not reflect the
most recent code on the main trunk. If I remember well, just deleted files
have HEAD tag, so you will checkout them even
Does anybody know what databases are case sensitive WRT column and table
names (or even keywords). I've never run into case sensitive SQL
databases before.
[EMAIL PROTECTED] wrote:
Bugs item #438115, was opened at 2001-07-02 19:50
You can respond by visiting:
query. Do you want me to fix it?
D'Oh! That one I expect to not work - SQL is usually case sensitive with
the _contents_ of columns. Go ahead and fix, if you've the time.
thanks much,
danch
___
Jboss-development mailing list
[EMAIL PROTECTED]
http
, but
of the particular query you're executing.
2. For any finder method add a fetch-size deployment descriptor in jaws.
Comments ?
This makes sense to me.
It also fits in with my evil plot to do 'cursor' type things on finders.
-danch
___
Jboss-development
still wrote:
hi,everybody:
i use MS Access
You probably shouldn't do that.
.and i have 2 tables to work with.and i successfully load
the sun's jdbc:odbc database driver
That's probably bad too. ODBC driver (used to, anyway, when I had to use
them) be really non-threadable in a bad
transaction.
Also, if it can never happen, why ignore it?
I agree - at the very least freak out into the log, so that we know that something
'impossible' has happened.
-danch (friend of Murphy)
___
Jboss-development mailing list
[EMAIL PROTECTED]
http
equivalent.
-danch
___
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
Bill Burke wrote:
Man you crack me up sometimes :)
We used to have a running joke about support calls for O2K. I'm sorry, but
you're just too stupid to use our product. Please cd to /usr/local and
rm -rf o2k.
Bill
I think we've _all_ wanted to say that one time or another!
-danch
' edition, which is available only at cost.
Another thing that bothered me about the article was the apparent lack
of cluefulness about what open source _is_: they didn't mention the
difference in license terms or the fact that JBoss can be used by and
contributed to by anyone.
-danch
On Wed, Aug
for each
EJB, and Web war. See the documentation on jboss.xml and jboss-web.xml
for how to map the 'java:/xxx' datasource entry into the java:comp/env
namespace for a component.
-danch
___
Jboss-development mailing list
[EMAIL PROTECTED]
http
this optimization.
-danch
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
CMP just shouldn't update primary keys.
- Original Message -
From: Bill Burke [EMAIL PROTECTED]
To: Jboss-Development@Lists. Sourceforge. Net
[EMAIL PROTECTED]
Cc: Jaws@Kpi. Com. Au [EMAIL PROTECTED]
Sent: Thursday, October 18, 2001 11:17 AM
Subject: [JBossCMP] RE: [JBoss-dev]
On the current CVS, I'm getting errors like the following.
Method disassociateThread() not found in interface
javax.transaction.TransactionManager.
[javac] Transaction t1 = tm.disassociateThread();
So what am I missing?
thanks all,
danch
this kind of problem less likely at the
cost of slightly slower builds?
Thanks
David Jencks
On 2001.10.25 21:16:27 -0400 danch wrote:
On the current CVS, I'm getting errors like the following.
Method disassociateThread() not found in interface
javax.transaction.TransactionManager
FWIW, Bluestone did this. I tried to get them to stop.
Aaron Mulder wrote:
How do you compile the client code if the home/remote exists only
in the VM of the running server?
Aaron
On Mon, 12 Nov 2001, marc fleury wrote:
I know there are many tools out there that do almost what
When we talk about 'stateless' interceptors, do we really mean
stateless, or do we merely mean stateless with regard to bean instance
and client?
-danch
Scott M Stark wrote:
Any of the interceptors can be made stateless, its a question of the cost
of reassociating the state from
, but at
the same time it's all the same. It's a nice illusion though.
Very cool, indeed. But don't knock practicality 8^})
-danch
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
Rickard Öberg wrote:
That's much better, assuming I know where the tmp directory is. And I
don't, since the name keeps changing for each deployment. :-(
Something people have been compaining about roughly forever.
___
Jboss-development
in a lot of companies where the production environment was
that separated from development - the simpler the package you can hand
over the better, since the people who support production environments
tend to be on a different planet.
-danch
___
Jboss
. Unless I'm missing something big.
-danch
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
1 - 100 of 198 matches
Mail list logo
