Hi,
It seems to be a jdk13 issue - it fails with an out of memory error -
but jdk14 fails with real code errors.
But the default config seems to be 640m - is this much really needed?
I have changed my next run to be verbose to check the 640m is being
picked up - hopefully it gets displayed ;-)
Change Notes item #697894, was opened at 2003-03-05 11:08
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=381174aid=697894group_id=22866
Category: JBossServer
Group: v3.0 (Rabbit Hole)
Status: Open
Priority: 5
Submitted By: Peter Antman (pra)
Assigned to:
Bugs item #696381, was opened at 2003-03-03 06:59
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=376685aid=696381group_id=22866
Category: JBossWeb
Group: v3.2
Status: Open
Resolution: Fixed
Priority: 5
Submitted By: Scott M Stark (starksm)
Assigned to: Jules
Any preferences on when the changes should be made as to not interfere
with your work? I guess it will take about a day to make the change.
How long will it take you to complete the interception changes?
--jason
On Wednesday, March 5, 2003, at 07:00 AM, Bill Burke wrote:
I'm begging people
=
==THIS IS AN AUTOMATED EMAIL - SEE http://jboss.kimptoc.net FOR DETAILS=
=
JAVA VERSION DETAILS
java version 1.4.1_01
Java(TM) 2 Runtime Environment, Standard
Stephen Flynn
Director, JF Technology (UK) Ltd
Cell: +44 7768 003 882
Phone: +44 20 7329 6567
Fax: +44 20 7329 6543
Tech support: [EMAIL PROTECTED]
www.jftechnology.com
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On
Behalf Of Francisco Reverbel
The solution would probably be to cut the XDoclet building into 2 separate
bundles. I get this same error every time I build head from scratch and
always with XDoclet.
Bill
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Behalf Of Chris
Kimpton
Sent: Wednesday,
I really don't understand why you need to move stuff out of server/ anyways.
This is mostly EJB anyways. Why not just rename the server/ module to EJB?
I really don't see any gain in this cosmetic shit except wasting everybody's
time trying to figure out where everything is again and screwing
=
==THIS IS AN AUTOMATED EMAIL - SEE http://jboss.kimptoc.net FOR DETAILS=
=
JAVA VERSION DETAILS
java version 1.3.1_06
Java(TM) 2 Runtime Environment, Standard
Nightly build? I have never been maintaining that, short of build
system support. As for the rest of the build system fluff I am looking
into several possible solutions to resolve many of the problems which
currently exist.
The EJB stuff has been on my list of stuff todo since I separated
A protocol is associated with a reference (proxy) factory. My previous
message stressed the protocol (invoker) rather than the proxy factory.
The crucial thing is the reference factory, i.e., whether a remote
reference is a serialized proxy or an IOR.
Suppose method m of bean X returns some
I understand the need to return the correct proxy the outermost client. For
For an IIOP invocation into bean X that calls Y for its own consumption,
you are saying that the interaction between X and Y will be via IIOP because
of the possibility that a proxy obtained from Y may be returned to the
710-13
,
233
(0571) 87924071 87924072 87924073 (0571)87918976
13958106746 E_mail[EMAIL PROTECTED]
www.hzefu.comwww.hzefu.netQQ965301
---
This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger
most if not all of the stuff in server IS ejb. The invocation stuff will
slowly be migrated to AOP and JBoss Remoting. Other than that, what else is
there? I still think this is not a good idea.
Bill
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Behalf Of
I just quickly scanned the packages in server and it looks like quite a
bit is non-ejb specific.
There is just too much mingling between core system components and EJB
fluff. JBoss will be better off with these nice and cleanly separated.
JBoss... more than just and EJB container.
Not EJB
Can't seem to find jboss_3_2.dtd - I looked under
jboss/jboss/src/resources/org/jboss/metadata and found many dtds except for
3.2.
I'd be very grateful if someone could point out the location
Thanks
- Original Message -
From: Scott M Stark [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent:
Bugs item #698235, was opened at 2003-03-05 19:36
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=376685aid=698235group_id=22866
Category: JBossCMP
Group: v3.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Carl Schmidt (carlschmidt)
Assigned to:
Bugs item #698235, was opened at 2003-03-05 19:36
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=376685aid=698235group_id=22866
Category: JBossCMP
Group: v3.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Carl Schmidt (carlschmidt)
Assigned to:
Bugs item #698235, was opened at 2003-03-05 19:36
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=376685aid=698235group_id=22866
Category: JBossCMP
Group: v3.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Carl Schmidt (carlschmidt)
Assigned to:
=
==THIS IS AN AUTOMATED EMAIL - SEE http://jboss.kimptoc.net FOR DETAILS=
=
JAVA VERSION DETAILS
java version 1.3.1_06
Java(TM) 2 Runtime Environment, Standard
Its there, look again after doing an update:
metadata 776pwd
/usr/JBoss3.2/jboss-3.2/server/src/resources/org/jboss/metadata
metadata 777cvs status jboss_3_2.dtd
===
File: jboss_3_2.dtd Status: Up-to-date
Working revision:
I follow what your saying and agree with the need but I still need to drill
down into the implementation at which point I might be back. Although
this solution works for j2ee components that have the notion of a reference
to proxy semantic through ejb-refs, we really need transparent
Bugs item #693311, was opened at 2003-02-25 16:34
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=376685aid=693311group_id=22866
Category: JBossServer
Group: v3.2
Status: Closed
Resolution: Fixed
Priority: 5
Submitted By: Mike Youngstrom (youngm)
Assigned to: Scott
Bugs item #692273, was opened at 2003-02-24 07:11
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=376685aid=692273group_id=22866
Category: JBossServer
Group: v3.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Lior Kanfi (kanfil)
Assigned to: Scott M Stark
JBoss daily test results
SUMMARY
Number of tests run: 1067
Successful tests: 1062
Errors:1
Failures: 4
[time of test: 2003-03-05.13-22 GMT]
[java.version:
Bill Burke wrote:
I really don't understand why you need to move stuff out of server/ anyways.
This is mostly EJB anyways. Why not just rename the server/ module to EJB?
I really don't see any gain in this cosmetic shit except wasting everybody's
time trying to figure out where everything is
=
==THIS IS AN AUTOMATED EMAIL - SEE http://jboss.kimptoc.net FOR DETAILS=
=
JAVA VERSION DETAILS
java version 1.4.1_01
Java(TM) 2 Runtime Environment, Standard
hi all,
After deployed firstejb.jar successfully into
/opt/jboss/server/default/deploy, i complied and ran the
FirstClient.class (please view attached FirstClient.java) and got the
error message below.
am i missing any .jar in my jboss deployment?
command to run the FirstClient.class=
java
On Wednesday, March 5, 2003, at 11:56 AM, Jason Dillon wrote:
EJB specific:
./org/jboss/security ?
./org/jboss/security/plugins ?
./org/jboss/monitor ?
./org/jboss/monitor/client ?
./org/jboss/verifier/strategy ?
./org/jboss/jmx/adaptor/ejb
./org/jboss/jmx/connector/ejb
./org/jboss/metadata
./org/jboss/verifier
./org/jboss/verifier/event
./org/jboss/verifier/factory
All of these are for validation of ejb deployments so it is ejb specific.
./org/jboss/security ?
Not ejb specific.
./org/jboss/security/plugins ?
Obsolete and should be dropped.
./org/jboss/metadata
A mixture of
This is this list of packages under server that really are ejb specific
and not already under org/jboss/ejb:
./org/jboss/monitor ?
./org/jboss/monitor/client ?
./org/jboss/verifier/strategy ?
./org/jboss/jmx/adaptor/ejb
./org/jboss/jmx/connector/ejb
./org/jboss/proxy/ejb
Add jboss-common-client.jar on your path
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of hae
loong chan
Sent: Wednesday, March 05, 2003 8:36 PM
To: [EMAIL PROTECTED]
Subject: [JBoss-dev] Re: Error ..
hi all,
After deployed firstejb.jar successfully
In EntityInstanceCache.canPassivate(EnterpriseContext ctx)
there is the following statement:
else if
(m_container.getLockManager().canPassivate(((EntityEnterpriseContext)ctx).getCacheKey()))
{
return false;
}
The corresponding BeanLockManager.canPassivate(Object) code is:
public
Bugs item #692273, was opened at 2003-02-24 07:11
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=376685aid=692273group_id=22866
Category: JBossServer
Group: v3.2
Status: Closed
Resolution: Works For Me
Priority: 5
Submitted By: Lior Kanfi (kanfil)
Assigned to:
In looking a bug report on how flushing the entity cache was being prevented
by the can passivate state of a bean, I see that the flush basically appears to
be a pull the rug out from under the container type of operation. We are just
emptying the underlying data store without any regard to what
Can I register with a UnifiedClassLoader for a notification when the
class loader is dereferenced by JBoss? I'm writing an object copier
service for the new persistence engine and cache, so I'm holding on to
some metadata for each class that can be copied.
-dain
Thanks
- Original Message -
From: Scott M Stark [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Wednesday, March 05, 2003 8:08 PM
Subject: Re: [JBoss-dev] jboss_3_2.dtd updated
Its there, look again after doing an update:
metadata 776pwd
Repackaging of the EJB bits which are not under org.jboss.ejb is minor
IMO, but making the module separation is important for build
simplification and general logical separation of server components.
I think stink it is worth the effort.
--jason
On Thursday, March 6, 2003, at 09:33 AM, Scott
38 matches
Mail list logo
