If there is any logging api other than System.out, then its log4j as
far as I'm concerned. We can provide a null config if they want
to disregard any JBoss generated client side logging.
- Original Message -
From: "Jason Dillon" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Monday, Ju
> Before you go crazy on that log system clean up... I'm working on a major
> re-org of the jbossmq module. It's so major that everything is broken right
> now on my development box :) I'm making all subsytems in jbossmq a JMX
> service. This will be good since jbossmq.xml will then be able to
I got this one also.
It disappeared.
I think (not sure) it was because of my bloody hashCode() method.
Maybe it is linked to recent changes on cvs version through.
> -Message d'origine-
> De : [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]De la part de
> Hiram Chirino
> Envoyé : mardi 10
Hi,
I want to add a feature that will allow to set the FetchSize associated with
Statement in Jaws/JBossPool.
The default FetchSize is in fact dependant of the driver (and is not always
0, meaning get all records), that's an hazardous thing imho.
1. A bit like IsolationLevel that we can specify on
I would say that in the short term that it would be better to have the
client code using Log4j, so we can better debug things. In the long term we
need to have a way to let the client side logging either automatically
disable (perhaps enable with a system property), but either way make use of
the
User: schaefera
Date: 01/07/09 23:42:28
Modified:src/docs howtotimer.xml
Log:
Fixed some spelling errors and code problems thanx to the feedback
of [EMAIL PROTECTED]
Revision ChangesPath
1.7 +7 -7 manual/src/docs/howtotimer.xml
Index: howtotimer.xml
=
Before you go crazy on that log system clean up... I'm working on a major
re-org of the jbossmq module. It's so major that everything is broken right
now on my development box :) I'm making all subsytems in jbossmq a JMX
service. This will be good since jbossmq.xml will then be able to go
Hi Geeks
Look out my article about JBoss gets published. Hope you
like it.
Mad Andy
- Original Message -
From: "Steve Anglin" <[EMAIL PROTECTED]>
To: "Andreas Schaefer" <[EMAIL PROTECTED]>
Sent: Monday, July 09, 2001 4:29 PM
Subject: Re: "Using JBoss.org: A Java 2 Enterprise Edition-bas
I am not so sure that is a safe assumption. For example, the testsuite does
not currently setup any logging on the clients. So if JBossMQ used Log4j in
its client code, the current testsuite will produce a lot of garbage
messages about needing some configuration.
There is also the issue of seri
That makes sense, but the current MessageDrivenContainer is the one that
does implement the ContainerInvokerContainer interface and then decides
to void the contract by throwing Errors.
- Original Message -
From: "Rickard Öberg" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Monday, Ju
Sorry, let me rephrase... Can I assume the a client VM will be on it's own
to figure out how to configure lo4j??
Regards,
HIram
>From: "Scott M Stark" <[EMAIL PROTECTED]>
>Reply-To: [EMAIL PROTECTED]
>To: <[EMAIL PROTECTED]>
>Subject: Re: [JBoss-dev] JBossMQ and Log4j
>Date: Mon, 9 Jul 2001 2
Yes, but what about on the client side??? Can my client side code also use
log4j??
Regards,
Hiram
>From: "Scott M Stark" <[EMAIL PROTECTED]>
>Reply-To: [EMAIL PROTECTED]
>To: <[EMAIL PROTECTED]>
>Subject: Re: [JBoss-dev] JBossMQ and Log4j
>Date: Mon, 9 Jul 2001 23:16:44 -0700
>
>Log4j will be
Hi!
Scott M Stark wrote:
> That makes sense, but the current MessageDrivenContainer is the one that
> does implement the ContainerInvokerContainer interface and then decides
> to void the contract by throwing Errors.
That is one way to do it to. If you let MessageDrivenContainer implement
CIC, t
Log4j will be configured as a service of JBoss.
- Original Message -
From: "Hiram Chirino" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Monday, July 09, 2001 10:34 PM
Subject: Re: [JBoss-dev] JBossMQ and Log4j
>
> Ah... I did not know that! I've allready moved most of the server
Scott M Stark wrote:
> Another issue is why doesn't the Container class implement
> ContainerInvokerContainer? This
> is the assumed behavior as evidenced by the prevelance of unsafe downcasts
> scattered
> throughout the container invoker code:
The reason for the separation is(was at least) that
Ah... I did not know that! I've allready moved most of the server over to
log4j. Can I just assume that log4j will be confiurged for me by the
client??
Regards,
Hiram
>From: "Scott M Stark" <[EMAIL PROTECTED]>
>Reply-To: [EMAIL PROTECTED]
>To: <[EMAIL PROTECTED]>
>Subject: Re: [JBoss-dev]
Yes that is intentional. That class loader is for RMI class loading. There
was a change recently made to allow for general class loading when the
format of the requested class does not include class loader key. See
the latest cvs code.
- Original Message -
From: "David Green" <[EMAIL PROT
I've noticed in the docs that the official jboss chat area is on
openprojects.net #jboss... Everytime I've been in there it's been empty.
Might I suggest that you use my Java chat room instead? It would provide
access to the chat room from a link on your home page without the chatter
having to do
You might have noticed that I have commit a lot of changed recently. I am
trying to eliminate the usage of Throwable.printStackTrace() but replacing
them with valid Log4j logging calls. The point is to help debugging by
properly logging exceptions. I have run into a few places where it was
uncl
User: user57
Date: 01/07/09 22:06:40
Modified:src/main/org/jboss/ejb/plugins
StatefulSessionInstanceInterceptor.java
Log:
o using log4j to report errors
o throwing a ExceptionInInitializerError rather than leave the system in
an unstable state at t
Talking about spooky cache problems, I've run into this problem:
I disable the cache by using the 'NoPassivationCachePolicy' and Commit
option 'C'. I create a new bean instance. Later I try to remove it but I
fail (If you guys want, I'll get you guys a stack trace). I am workin
around the
User: user57
Date: 01/07/09 22:10:54
Modified:src/main/org/jboss/ejb Container.java
Log:
o changed logging to log4j
o changed some comments to javadocs
Revision ChangesPath
1.47 +212 -195 jboss/src/main/org/jboss/ejb/Container.java
Index: Container.java
User: user57
Date: 01/07/09 22:09:20
Modified:src/main/org/jboss/ejb EnterpriseContext.java
Log:
o using log4j
o updated comments to be javadocs
Revision ChangesPath
1.37 +170 -166 jboss/src/main/org/jboss/ejb/EnterpriseContext.java
Index: EnterpriseCont
User: user57
Date: 01/07/09 22:08:04
Modified:src/main/org/jboss/ejb/plugins
LRUEnterpriseContextCachePolicy.java
Log:
o reformat
Revision ChangesPath
1.10 +553 -491
jboss/src/main/org/jboss/ejb/plugins/LRUEnterpriseContextCachePolicy.ja
User: user57
Date: 01/07/09 22:03:17
Modified:src/main/org/jboss/ejb/plugins AbstractInterceptor.java
SecurityProxyInterceptor.java
Log:
o documented AbstractInterceptor a bit more.
o changed logging in SecurityProxyInterceptor to log4j
Revision C
User: user57
Date: 01/07/09 22:01:47
Modified:src/main/org/jboss/test/perf/test TestProbe.java
Log:
o forgot about this one, changed deployment to a test
Revision ChangesPath
1.3 +96 -97jbosstest/src/main/org/jboss/test/perf/test/TestProbe.java
Index: T
I don't know if this is possibly relevant,
While working on my jca/jdbc Firebird driver I experienced:
with read committed isolation, got a very similar error (couldn't transfer
-50.0), caused by deadlock exception in database. It occured 2 times,
once/ multithreaded test.
with snapshot (more
User: user57
Date: 01/07/09 21:46:30
Modified:src/main/org/jboss/ejb Interceptor.java
Log:
o added some javadocs
Revision ChangesPath
1.6 +34 -15jboss/src/main/org/jboss/ejb/Interceptor.java
Index: Interceptor.java
Is this intentional?
int separator = rawPath.indexOf('/');
String filePath = rawPath.substring(separator+1);
String loaderKey = rawPath.substring(0, separator+1);
ClassLoader loader = (ClassLoader) loaderMap.get(loaderKey);
Ac
User: user57
Date: 01/07/09 21:42:58
Modified:src/main/org/jboss/ejb CacheKey.java
Log:
o using log4j when initalization failes, this is not a field so it will not
affect serialization... but it should probably be replaced by a nested
runtime exception.
Revision C
User: user57
Date: 01/07/09 21:41:29
Modified:src/main/org/jboss/ejb AutoDeployer.java
Log:
o using log4j
Revision ChangesPath
1.19 +36 -34jboss/src/main/org/jboss/ejb/AutoDeployer.java
Index: AutoDeployer.java
=
User: user57
Date: 01/07/09 21:40:29
Modified:src/main/org/jboss/ejb/plugins/jrmp/interfaces
BeanProxy.java
Log:
o reformat to 3 spaces
Revision ChangesPath
1.3 +94 -94
jboss/src/main/org/jboss/ejb/plugins/jrmp/interfaces/BeanProxy.ja
I have changed the MessageDrivenContainer implementation of
ContainerInvokerContainer
to return null rather than throwing an Error. The three tests below now
succeed.
- Original Message -
From: "Jason Dillon" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Monday, July 09, 2001 7:42 PM
User: starksm
Date: 01/07/09 21:11:24
Modified:src/main/org/jboss/ejb MessageDrivenContainer.java
Log:
Implement the ContainerInvokerContainer interface methods to return null
rather than throwing an Error.
Revision ChangesPath
1.9 +8 -4 jboss/src/main/org/
That fine, I was just wondering.
--jason
On Mon, 9 Jul 2001, James Cook wrote:
> Not sure. I am not an active developer on jBoss and I haven't built it in
> some time. I was using the 2.4 Beta binary.
>
> jim
>
> > -Original Message-
> > From: [EMAIL PROTECTED]
> > [mailto:[EMAIL PROTE
Not currently but that is the design. I don't know what the driving
use case for this seperation is though.
- Original Message -
From: "Jason Dillon" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Monday, July 09, 2001 7:31 PM
Subject: Re: [JBoss-dev] Why doesn't Container implment
Con
Not sure. I am not an active developer on jBoss and I haven't built it in
some time. I was using the 2.4 Beta binary.
jim
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On Behalf Of Jason
> Dillon
> Sent: Monday, July 09, 2001 10:59 PM
> To: [EMAIL PROTECTED]
Yes, I think something is broken there. Do you know if the same will happen
(no default ds & null pointer) in the main cvs branch?
--jason
On Mon, 9 Jul 2001, James Cook wrote:
> I was experiencing a similar issue with 2.4. If I didn't specify a default
> datasource in standardjaws.xml, I was
The standardjaws.xml & jaws.xml files will deploy under the latest cvs
unchanged, so I do not believe there is a typo. I would look into it more,
but I have bigger fish to fry, it looks like this has been fixed in later
releases.
My concern is that folks will try to download a 2.4 build and atte
User: user57
Date: 01/07/09 19:34:03
Modified:src/main/org/jboss/test/cts/test AllJUnitTests.java
Main.java
Log:
o changed all deploy tests to deploy as a test and to not call System.exit().
this should allow reports to be generated for tests that fai
User: user57
Date: 01/07/09 19:34:04
Modified:src/main/org/jboss/test/jmsra/test AllJUnitTests.java
Log:
o changed all deploy tests to deploy as a test and to not call System.exit().
this should allow reports to be generated for tests that fail to deploy.
o modified run_t
I was experiencing a similar issue with 2.4. If I didn't specify a default
datasource in standardjaws.xml, I was getting a null pointer exception. I
*did* specify a valid datasource in my jaws.xml.
jim
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On Behalf O
I think I got something like this before when i had a typo in
standardjaws.xml or jaws.xml. Are you sure that's not the case? I thought
I put some better error messages when a parsing error happens. Check
server.log or something.
Regards,
Bill
> -Original Message-
> From: [EMAIL PROTE
All tests will now deploy as a test. This should fix the problem of reports
not being generated due to deployment failures. I think that I have gotten
all of the deploy tests, but I am not 100% sure. I just re-ran the suite
and these tests will fail:
jmsra
mdb
security (TestEJBSpec)
All
User: user57
Date: 01/07/09 19:34:04
Modified:src/main/org/jboss/test/hello/test Main.java
Log:
o changed all deploy tests to deploy as a test and to not call System.exit().
this should allow reports to be generated for tests that fail to deploy.
o modified run_tests.xml
User: user57
Date: 01/07/09 19:34:04
Modified:src/main/org/jboss/test/idgen/test Main.java
Log:
o changed all deploy tests to deploy as a test and to not call System.exit().
this should allow reports to be generated for tests that fail to deploy.
o modified run_tests.xml
User: user57
Date: 01/07/09 19:35:17
Modified:src/main/org/jboss/ejb ContainerInvokerContainer.java
Log:
o added dummy comments (someone who knows what they are for should fill
in the ???). all public interface should really be javadoc'd.
Revision ChangesPath
1.
User: user57
Date: 01/07/09 19:34:03
Modified:src/build run_tests.xml
Log:
o changed all deploy tests to deploy as a test and to not call System.exit().
this should allow reports to be generated for tests that fail to deploy.
o modified run_tests.xml basic-security-tests
User: user57
Date: 01/07/09 19:34:05
Modified:src/main/org/jboss/test/testbean/test Main.java
Log:
o changed all deploy tests to deploy as a test and to not call System.exit().
this should allow reports to be generated for tests that fail to deploy.
o modified run_tests.x
User: user57
Date: 01/07/09 19:34:04
Modified:src/main/org/jboss/test/jrmp/test TestCustomSockets.java
TestDynLoading.java
Log:
o changed all deploy tests to deploy as a test and to not call System.exit().
this should allow reports to be generated for
User: user57
Date: 01/07/09 19:34:04
Modified:src/main/org/jboss/test/naming/test TestENC.java
Log:
o changed all deploy tests to deploy as a test and to not call System.exit().
this should allow reports to be generated for tests that fail to deploy.
o modified run_tests.
User: user57
Date: 01/07/09 19:34:05
Modified:src/main/org/jboss/test/readahead/test Main.java
Log:
o changed all deploy tests to deploy as a test and to not call System.exit().
this should allow reports to be generated for tests that fail to deploy.
o modified run_tests.
User: user57
Date: 01/07/09 19:34:05
Modified:src/main/org/jboss/test/web/test TestWebIntegration.java
Log:
o changed all deploy tests to deploy as a test and to not call System.exit().
this should allow reports to be generated for tests that fail to deploy.
o modified ru
User: user57
Date: 01/07/09 19:34:04
Modified:src/main/org/jboss/test/lock/test Main.java
Log:
o changed all deploy tests to deploy as a test and to not call System.exit().
this should allow reports to be generated for tests that fail to deploy.
o modified run_tests.xml b
User: user57
Date: 01/07/09 19:34:03
Modified:src/main/org/jboss/test/bank/test Main.java
Log:
o changed all deploy tests to deploy as a test and to not call System.exit().
this should allow reports to be generated for tests that fail to deploy.
o modified run_tests.xml b
User: user57
Date: 01/07/09 19:34:03
Modified:src/main/org/jboss/test/bmp/test Main.java
Log:
o changed all deploy tests to deploy as a test and to not call System.exit().
this should allow reports to be generated for tests that fail to deploy.
o modified run_tests.xml ba
User: user57
Date: 01/07/09 19:34:04
Modified:src/main/org/jboss/test/jbossmq/test Main.java
Log:
o changed all deploy tests to deploy as a test and to not call System.exit().
this should allow reports to be generated for tests that fail to deploy.
o modified run_tests.xm
User: user57
Date: 01/07/09 19:34:05
Modified:src/main/org/jboss/test/security/test TestEJBAccess.java
TestEJBSpec.java TestProjRepository.java
TestSecurityProxy.java
Log:
o changed all deploy tests to deploy as a test and to not ca
User: user57
Date: 01/07/09 19:34:05
Modified:src/main/org/jboss/test/util Deploy.java
Log:
o changed all deploy tests to deploy as a test and to not call System.exit().
this should allow reports to be generated for tests that fail to deploy.
o modified run_tests.xml basi
User: user57
Date: 01/07/09 19:34:03
Modified:src/main/org/jboss/test/dbtest/test Main.java
Log:
o changed all deploy tests to deploy as a test and to not call System.exit().
this should allow reports to be generated for tests that fail to deploy.
o modified run_tests.xml
User: user57
Date: 01/07/09 19:34:05
Modified:src/main/org/jboss/test/xa/test Main.java
Log:
o changed all deploy tests to deploy as a test and to not call System.exit().
this should allow reports to be generated for tests that fail to deploy.
o modified run_tests.xml bas
Instead of performing the deploy in the construction of the TestSuite, wrap
the
TestSuite in a junit.extensions.TestSetup Object:
public static Test suite() {
TestSuite suite= new TestSuite();
// Add tests and suites...
TestSetup wrapper= new TestSetup(suite) {
protected void setUp() th
Are there any containers which do not use a ContainerInvoker? If not why
seperate the interface? If there are, is there a better name for
ContainerInvokerContainer? It is just confusing. =(
--jason
On Mon, 9 Jul 2001, Scott M Stark wrote:
> Another issue is why doesn't the Container class i
Another issue is why doesn't the Container class implement
ContainerInvokerContainer? This
is the assumed behavior as evidenced by the prevelance of unsafe downcasts
scattered
throughout the container invoker code:
jboss 713>grep -nr '(ContainerInvokerContainer)container' .
./ejb/plugins/jrmp/ser
This is fixed... sorry about that. =|
--jason
On Tue, 10 Jul 2001 [EMAIL PROTECTED] wrote:
>
> =
> ==THIS IS AN AUTOMATED EMAIL - SEE http://www.lubega.com FOR DETAILS=
> =
User: user57
Date: 01/07/09 19:04:58
Modified:src/main/org/jboss/test/mdb/test Main.java
Log:
o fixed compile problem (oops)
Revision ChangesPath
1.8 +3 -3 jbosstest/src/main/org/jboss/test/mdb/test/Main.java
Index: Main.java
Since the notion of local interfaces was introduced at the Container
base class level, why is the MessageDrivenContainer throwing a runtime
exception instead of simply returning null? This is not a valid
implementation
of the ContainerInvokerContainer contract because no exceptions are
declared in
=
==THIS IS AN AUTOMATED EMAIL - SEE http://www.lubega.com FOR DETAILS=
=
Buildfile: run_tests.xml
build:
prepare:
compile:
[javac] Compiling 1 source fi
=
==THIS IS AN AUTOMATED EMAIL - SEE http://www.lubega.com FOR DETAILS=
=
Buildfile: build.xml
prepare:
[mkdir] Created dir: /home/lubega/jbossro/jbosstest
User: user57
Date: 01/07/09 18:02:44
Modified:src/main/org/jboss/deployment J2eeDeployer.java
Log:
o fixed log name to not use an extra space before the name... what is this
for anyways?
Revision ChangesPath
1.37 +9 -7 jboss/src/main/org/jboss/deploymen
It looks like the 2.4 releases (I just tested the ones with just JBoss) are
not paying attention to the jaws.xml in deployed files. I am using an
Oracle8 database, and specifing the datasource and type-map in each jaws.xml
file (which works fine under MAIN and previous versions).
It complains ab
I have (finally) committed the code for EJB 2.0 CMR fields. It took longer
than I thought mainly because Marc's update of the entity interceptor code
showed me a major flaw in my implementation when there is more then one
concurrent transaction. Anyway, it's in and you can start to play with it
n
User: user57
Date: 01/07/09 17:30:45
Modified:src/main/org/jboss/deployment InstallerFactory.java
Log:
o reformat
Revision ChangesPath
1.5 +246 -253 jboss/src/main/org/jboss/deployment/InstallerFactory.java
Index: InstallerFactory.java
==
User: user57
Date: 01/07/09 17:12:12
Modified:src/main/org/jboss/test/mdb/test Main.java
Log:
o changed deployment to a test, removed System.exit() call
Revision ChangesPath
1.7 +146 -148 jbosstest/src/main/org/jboss/test/mdb/test/Main.java
Index: Main.jav
It looks like the errors are not being reported because the deployement
happens in the suite() method, then System.exit()'s after a failure. If we
move the deployment to a test (like undeploy), then the failure shows up,
but for some reason the actual tests will succeed even if the deployement
fa
User: dsundstrom
Date: 01/07/09 17:04:56
Modified:src/etc/conf/default standardjboss.xml
Log:
Added JDBC relation interceptor for EJB 2.0 CMP.
Revision ChangesPath
1.11 +2 -1 jboss/src/etc/conf/default/standardjboss.xml
Index: standardjboss.xml
=
User: dsundstrom
Date: 01/07/09 16:59:58
Modified:src/main/org/jboss/ejb/plugins/cmp CMPStoreManager.java
Log:
Added container managed relationships.
Revision ChangesPath
1.2 +1 -3 jboss/src/main/org/jboss/ejb/plugins/cmp/CMPStoreManager.java
Index: CMPSt
User: dsundstrom
Date: 01/07/09 16:59:58
Modified:src/main/org/jboss/ejb/plugins/cmp/bridge
CMPFieldBridge.java CMRFieldBridge.java
EntityBridgeInvocationHandler.java
Log:
Added container managed relationships.
Revision Changes
It looks like the recent modification of BaseLocalContainerInvoker has
broken the MDB testsuite (as well as other MDB applications). It trys to
call getLocalHomeClass(), which will throw an Error directly from
MessageDrivenContainer.
What is even more disturbing is that the jbosstest output does
Same here.
I use 8.1.7 drivers on both RedHat 6.2/7.1 and Win2k and with JBoss 2.2,
2.4, and 2.5(mainline). Please post your jboss.jcml
Bill
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On Behalf Of Vinay
> Menon
> Sent: Monday, July 09, 2001 6:20 PM
> To:
User: user57
Date: 01/07/09 16:23:21
Modified:src/main/org/jboss/deployment J2eeDeployer.java
Log:
o specifing full name + tag for logging
o changed exception handling to use log.exception() instead of
Throwable.printStackTrace()
Revision ChangesPath
1.36
User: user57
Date: 01/07/09 16:21:28
Modified:src/main/org/jboss/ejb/plugins/jaws
JAWSPersistenceManager.java
Log:
o using full name for logger.
Revision ChangesPath
1.29 +4 -3
jboss/src/main/org/jboss/ejb/plugins/jaws/JAWSPersistenc
User: user57
Date: 01/07/09 16:22:08
Modified:src/main/org/jboss/web WebService.java
Log:
o using full name for logging, with a # tag
Revision ChangesPath
1.7 +2 -2 jboss/src/main/org/jboss/web/WebService.java
Index: WebService.java
=
User: user57
Date: 01/07/09 15:58:59
Modified:src/main/org/jboss/util Info.java
Log:
o added a simple log message before running the gc(), should probably also
log the before/after memory stats.
Revision ChangesPath
1.12 +4 -1 jboss/src/main/org/jboss/u
User: user57
Date: 01/07/09 15:55:07
Modified:src/main/org/jboss/util Info.java InfoMBean.java
Log:
o added runGarbageCollector, should probably be in another place, but for
now this will work.
Revision ChangesPath
1.11 +11 -1 jboss/src/main/org/jboss/ut
Can confirm that I use JBoss with both the thin and the OCI driver and have
not had problems.
- Original Message -
From: <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Monday, July 09, 2001 10:48 PM
Subject: [JBoss-dev] [ jboss-Bugs-439861 ] JBOSS 2.4 problem
> Bugs item #439861, was
Feature Requests item #439865, was opened at 2001-07-09 15:14
You can respond by visiting:
http://sourceforge.net/tracker/?func=detail&atid=376688&aid=439865&group_id=22866
Category: None
Group: None
Status: Open
Priority: 5
Submitted By: Scott M Stark (starksm)
Assigned to: Scott M Stark (stark
User: dsundstrom
Date: 01/07/09 14:47:26
Added: src/main/org/jboss/ejb/plugins/cmp/jdbc/metadata
JDBCRelationMetaData.java
Log:
Represents one ejb-relation element found in the ejb-jar.xml
file's relationships elements.
Revision ChangesPath
1.
User: dsundstrom
Date: 01/07/09 14:49:23
Modified:src/main/org/jboss/ejb/plugins/cmp/jdbc/metadata
JDBCApplicationMetaData.java
JDBCEntityMetaData.java
Log:
Added relationship metadata.
Revision ChangesPath
1.5 +53 -1
Bugs item #439861, was opened at 2001-07-09 14:48
You can respond by visiting:
http://sourceforge.net/tracker/?func=detail&atid=376685&aid=439861&group_id=22866
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonym
User: dsundstrom
Date: 01/07/09 14:45:59
Added: src/main/org/jboss/ejb/plugins/cmp/jdbc/metadata
JDBCRelationshipRoleMetaData.java
Log:
Represents one ejb-relationship-role element found in the ejb-jar.xml
file's ejb-relation elements.
Revision Chan
User: user57
Date: 01/07/09 14:14:28
Modified:src/main/org/jboss/ejb/plugins/jms JMSContainerInvoker.java
Log:
o using Log4j for logging
Revision ChangesPath
1.17 +516 -447
jboss/src/main/org/jboss/ejb/plugins/jms/JMSContainerInvoker.java
Index: JMSContain
User: dsundstrom
Date: 01/07/09 14:09:21
Modified:src/main/org/jboss/ejb/plugins/local
BaseLocalContainerInvoker.java
Log:
Added code which binds local home interface into jndi.
Revision ChangesPath
1.8 +67 -3
jboss/src/main/org/jboss/e
CVS bites me again.
Sorry Scott - too many years working with ClearCase.
Thanks,
Jules
Scott M Stark wrote:
> Its checked in. You have to do a 'cvs update -d -r Branch_2_4' to bring down
> new
> directories and content.
>
> lib 687>cvs status soap-2_2.jar
> =
User: dsundstrom
Date: 01/07/09 14:04:25
Modified:src/main/org/jboss/ejb/plugins CMPPersistenceManager.java
Log:
Added a method to get the entity persistence store.
Revision ChangesPath
1.26 +7 -1 jboss/src/main/org/jboss/ejb/plugins/CMPPersistenceManager.java
User: dsundstrom
Date: 01/07/09 13:52:19
Modified:src/main/org/jboss/metadata BeanMetaData.java
Log:
Added local jndi name, which is the jndi name to which the local home is bound.
Revision ChangesPath
1.26 +19 -1 jboss/src/main/org/jboss/metadata/BeanMetaData.j
User: dsundstrom
Date: 01/07/09 13:50:25
Added: src/main/org/jboss/metadata RelationMetaData.java
Log:
Represents one ejb-relation element found in the ejb-jar.xml
file's relationships elements.
Revision ChangesPath
1.1 jboss/src/main/org/jboss/metad
User: dsundstrom
Date: 01/07/09 13:49:00
Added: src/main/org/jboss/metadata RelationshipRoleMetaData.java
Log:
Represents one ejb-relationship-role element found in the ejb-jar.xml
file's ejb-relation elements.
Revision ChangesPath
1.1 jboss/src/main
User: dsundstrom
Date: 01/07/09 13:53:07
Modified:src/main/org/jboss/metadata ApplicationMetaData.java
Log:
Added code to load relation ship metadata.
Revision ChangesPath
1.21 +33 -2 jboss/src/main/org/jboss/metadata/ApplicationMetaData.java
Index: Applica
Its checked in. You have to do a 'cvs update -d -r Branch_2_4' to bring down
new
directories and content.
lib 687>cvs status soap-2_2.jar
===
File: soap-2_2.jar Status: Up-to-date
Working revision:1.1
Repository revis
1 - 100 of 139 matches
Mail list logo
