Of Scott M Stark
Sent: 16 March, 2006 21:12
To: jboss-development@lists.sourceforge.net; Francisco Reverbel
Subject: RE: [JBoss-dev] FW: [jboss-cvs] build/jboss ...
Yes.
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
Ryan Campbell
+1
I ran into the very same issue while working on the DTM. See
http://jira.jboss.com/jira/browse/JBAS-2190
Regards,
Francisco
On Mon, 2006-02-27 at 15:26 -0600, Scott M Stark wrote:
We have a number of org.jnp.interfaces.NamingContextFactory subclasses
that are in the server module
.
__
From:[EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
Rajesh Rajasekaran
Sent: Monday, February 13, 2006 5:04 PM
To: jboss-development@lists.sourceforge.net
Cc: Francisco Reverbel
Subject: [JBoss-dev] FW: Could not run jacorb on 64 bit jdk
[ http://jira.jboss.com/jira/browse/JBAS-1646?page=history ]
Francisco Reverbel closed JBAS-1646:
Define OTS-like interfaces for the DTM
--
Key: JBAS-1646
URL: http://jira.jboss.com/jira
[ http://jira.jboss.com/jira/browse/JBAS-1655?page=history ]
Francisco Reverbel closed JBAS-1655:
Resolution: Done
Add to TransactionImpl a method that enlists a DTM Resource
[ http://jira.jboss.com/jira/browse/JBAS-1654?page=history ]
Francisco Reverbel closed JBAS-1654:
Resolution: Done
Extend TransactionImpl
--
Key: JBAS-1654
URL: http://jira.jboss.com/jira/browse/JBAS
[ http://jira.jboss.com/jira/browse/JBAS-1653?page=history ]
Francisco Reverbel closed JBAS-1653:
Resolution: Done
Review TransactionImpl
--
Key: JBAS-1653
URL: http://jira.jboss.com/jira/browse/JBAS
[ http://jira.jboss.com/jira/browse/JBAS-1649?page=history ]
Francisco Reverbel closed JBAS-1649:
Write OTS wrappers
--
Key: JBAS-1649
URL: http://jira.jboss.com/jira/browse/JBAS-1649
Project: JBoss
[ http://jira.jboss.com/jira/browse/JBAS-1648?page=history ]
Francisco Reverbel closed JBAS-1648:
Complete the existing implementation of the OTS interfaces
--
Key: JBAS-1648
[ http://jira.jboss.com/jira/browse/JBAS-1647?page=history ]
Francisco Reverbel closed JBAS-1647:
Provide JBoss remoting-based implementations of the DTM interfaces
--
Key
Reporter: Francisco Reverbel
Assigned to: Francisco Reverbel
Define OTS-like interfaces for the following DTM objects associated with a
given transaction: Terminator, Coordinator, Resource, Synchronization, and
RecoveryCoordinator. These interfaces allow those objects
: Transaction Manager service
Versions: JBossAS-5.0 Alpha
Reporter: Francisco Reverbel
The implementations will delegate the actual work to TransactionImpl instances.
Besides the similarity in their interfaces, remoting-based DTM objects
(Resource, Coordinator, etc.) must be similar
[ http://jira.jboss.com/jira/browse/JBAS-1647?page=history ]
Francisco Reverbel updated JBAS-1647:
-
Assign To: Francisco Reverbel
Security Level: (was: Public)
Provide JBoss remoting-based implementations of the DTM interfaces
Write OTS wrappers
--
Key: JBAS-1649
URL: http://jira.jboss.com/jira/browse/JBAS-1649
Project: JBoss Application Server
Type: Sub-task
Reporter: Francisco Reverbel
Assigned to: Francisco Reverbel
--
This message is automatically generated
[ http://jira.jboss.com/jira/browse/JBAS-1649?page=history ]
Francisco Reverbel updated JBAS-1649:
-
Description: Write some trivial OTS wrappers that implement the DTM
interfaces by delegating the work to OTS objects.
Environment
Manager service
Versions: JBossAS-5.0 Alpha
Reporter: Francisco Reverbel
Assigned to: Francisco Reverbel
Enlarge the transaction context propagated along with JBoss remoting
invocations. The current context has only a GlobalId/Xid, it must include also
a Coordinator reference
Versions: JBossAS-5.0 Alpha
Reporter: Francisco Reverbel
Make the TPC factory/importer/exporter configurable so that the full context
(GlobalId + Coordinator reference) is propagated only if the DTM is actually
used (no additional overhead for DTMless server configs).
--
This message
Manager service
Versions: JBossAS-5.0 Alpha
Reporter: Francisco Reverbel
Assigned to: Francisco Reverbel
Propagate the OTS context along with invocations issued by the JBoss server.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly
[ http://jira.jboss.com/jira/browse/JBAS-1651?page=history ]
Francisco Reverbel updated JBAS-1651:
-
Assign To: Francisco Reverbel
Security Level: (was: Public)
Make the TPC factory/importer/exporter configurable
Reverbel
Assigned to: Francisco Reverbel
Review TransactionImpl with respect to LocalId/GlobalId association and
transaction importing. An imported transaction should have a LocalId just like
a non-imported one. (The local id
is embedded into the CORBA references or into the JBoss remoting-based
Reverbel
Assigned to: Francisco Reverbel
Extend TransactionImpl so that it knows about the following DTM objects:
Coordinator, Resource, and RecoveryCoordinator. Besides having a list of XA
resources, a TransactionImpl instance will have a list of DTM Resources, each
of which represents either
Manager service
Versions: JBossAS-5.0 Alpha
Reporter: Francisco Reverbel
Assigned to: Francisco Reverbel
Ensure that TransactionImpl has methods that do the actual work for all OTS/DTM
objects and for XATerminator. Most of the needed methods already are in place,
but some need
: JBossAS-5.0 Alpha
Reporter: Francisco Reverbel
Assigned to: Francisco Reverbel
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.jboss.com/jira/secure/Administrators.jspa
-
If you want more
Alpha
Reporter: Francisco Reverbel
Assigned to: Francisco Reverbel
Preliminary tests, still with no logging/recovery.
Test UserTransaction over JBoss remoting. (UserTransaction over IIOP is already
in place and has its own testcase.)
Test 2PC across DTM Resources (either remoting
Reporter: Francisco Reverbel
Assigned to: Francisco Reverbel
Change the LocalId/GlobalId/Xid generation strategy so that the nextLocalId is
not reset to 0 at server startup.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one
Versions: JBossAS-5.0 Alpha
Reporter: Francisco Reverbel
Assigned to: Francisco Reverbel
Resource and RecoveryCoordinator references must be logged.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators
-5.0 Alpha
Reporter: Francisco Reverbel
Assigned to: Francisco Reverbel
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.jboss.com/jira/secure/Administrators.jspa
-
If you want more information
Test recovery
-
Key: JBAS-1661
URL: http://jira.jboss.com/jira/browse/JBAS-1661
Project: JBoss Application Server
Type: Sub-task
Components: Transaction Manager service
Versions: JBossAS-5.0 Alpha
Reporter: Francisco Reverbel
Assigned
[ http://jira.jboss.com/jira/browse/JBAS-1647?page=history ]
Francisco Reverbel resolved JBAS-1647:
--
Resolution: Done
Provide JBoss remoting-based implementations of the DTM interfaces
[ http://jira.jboss.com/jira/browse/JBAS-1646?page=history ]
Francisco Reverbel resolved JBAS-1646:
--
Resolution: Done
Define OTS-like interfaces for the DTM
--
Key: JBAS-1646
URL: http
[ http://jira.jboss.com/jira/browse/JBAS-1648?page=history ]
Francisco Reverbel resolved JBAS-1648:
--
Resolution: Done
Complete the existing implementation of the OTS interfaces
[ http://jira.jboss.com/jira/browse/JBAS-1649?page=history ]
Francisco Reverbel resolved JBAS-1649:
--
Resolution: Done
Write OTS wrappers
--
Key: JBAS-1649
URL: http://jira.jboss.com/jira/browse/JBAS-1649
[ http://jira.jboss.com/jira/browse/JBAS-1617?page=history ]
Francisco Reverbel resolved JBAS-1617:
--
Resolution: Done
The JacORB libraries have been updated to a patched version of JacORB 2.2.1,
which identifies itself as JacORB V 2.2.1
[ http://jira.jboss.com/jira/browse/JBAS-1617?page=history ]
Francisco Reverbel closed JBAS-1617:
Merge fixes for JacORB bugs #562 and #568 into the JacORB lib shipped w/ JBoss
Components: IIOP service
Versions: JBossAS-4.0.2RC1, JBossAS-4.0.1 SP1, JBossAS-4.0.1 Final,
JBossAS-3.2.7 Final, JBossAS-3.2.6 Final, JBossAS-4.0.1RC1, JBossAS-4.0.0
Final, JBossAS-3.2.5 Final
Reporter: Francisco Reverbel
Assigned to: Francisco Reverbel
Fix
I have removed from CVS HEAD all the stuff under thirdparty/sun-jts.
File thirdparty/sun-jts/lib/jts.jar contained a bogus implementation
of the standard class org.omg.CosTransactions.PropagationContextHelper.
It had hardwired references to the Exolab class org.openorb.CORBA.Any.
This is
In order to support IIOP over SSL I have made (still uncommitted)
changes to a couple of classes in the security module:
- org.jboss.security.ssl.DomainServerSocketFactory
Work currently performed within private method initSSLContext() factored
out to an utility class, in order to be
] On Behalf Of
Francisco Reverbel
Sent: Saturday, December 27, 2003 9:34 AM
To: [EMAIL PROTECTED]
Subject: [JBoss-dev] CVS problem
jboss-head, fresh checkout:
$ cd jboss-head/thirdparty
$ mkdir apache-avalon
$ cvs -z3 add apache-avalon
cvs [add aborted]: cannot add to /cvsroot/jboss
jboss-head, fresh checkout:
$ cd jboss-head/thirdparty
$ mkdir apache-avalon
$ cvs -z3 add apache-avalon
cvs [add aborted]: cannot add to /cvsroot/jboss/CVSROOT/Emptydir
$ cat CVS/Repository
CVSROOT/Emptydir
$ echo $CVSROOT
:ext:[EMAIL PROTECTED]:/cvsroot/jboss
What is this?
Cheers,
Me too, just updated jacorb.jar in thirdparty.
Francisco
On Sat, 8 Nov 2003, Alexey Loubyansky wrote:
I am done for this RC.
Scott M Stark wrote:
When can these be committed?
---
This SF.Net email sponsored by: ApacheCon
] On
Behalf Of Francisco Reverbel
Sent: jeudi, 6. novembre 2003 23:25
To: [EMAIL PROTECTED]
Subject: Re: [JBoss-dev] 3.2.3RC1
When will you get 3.2.3.RC1 from CVS?
There has been a JacORB bug fix (for Arjuna) that is not in
our CVS yet. I´d generate a patched version of jacorb.jar
WRT csiv2?
Cheers,
sacha
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On
Behalf Of Francisco Reverbel
Sent: vendredi, 7. novembre 2003 12:34
To: [EMAIL PROTECTED]
Subject: RE: [JBoss-dev] 3.2.3RC1
I am not aware of such problem
When will you get 3.2.3.RC1 from CVS?
There has been a JacORB bug fix (for Arjuna) that is not in
our CVS yet. I´d generate a patched version of jacorb.jar
with the fix.
Cheers,
Francisco
On Wed, 5 Nov 2003, Scott M Stark wrote:
I'm putting together a 3.2.3RC1 release to pickup some recent
Of
Francisco Reverbel
Sent: Monday, October 20, 2003 4:21 PM
To: [EMAIL PROTECTED]
Subject: Re: [JBoss-dev] JMX DR3 rollback commit
Guys,
The test results Tom posted show IIOP tests failing on HEAD.
I understand
this is not his fault, as his changes were not yet merged
into HEAD when
is not an objection to the commit, but a well
founded rant.
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Behalf Of
Francisco Reverbel
Sent: Monday, October 20, 2003 4:21 PM
To: [EMAIL PROTECTED]
Subject: Re: [JBoss-dev] JMX DR3 rollback commit
Guys
Guys,
The test results Tom posted show IIOP tests failing on HEAD. I understand
this is not his fault, as his changes were not yet merged into HEAD when
the tests were run. Anyway, I've fixed IIOP in HEAD less than a month ago.
All IIOP tests were running with no errors back then.
rant
I'm
IIOP tests are currently broken in HEAD.
The RMI/IIOP analysis and stub generation code calls cls.getPackage().
The tests break because getPackage() is returning null on
application-defined classes. If I print out the class and the package
of an application class, I get something like
cls =
:
The defineClass() is missing a definePackage()
see the hack in AOP's standalone system classloader.
I can fix it later if it isn't urgent.
This needs improving as it does not retrieve manifest
information.
Regards,
Adrian
On Fri, 2003-09-19 at 22:49, Francisco Reverbel wrote:
IIOP tests
Fresh checkout. The build.sh script fails with this error:
compile-classes:
[javac] Compiling 584 source files to
/usr/local/reverbel/jboss-3.2/server/output/classes
/usr/local/reverbel/jboss-3.2/server/output/gen-src/org/jboss/invocation/local/LocalInvokerMBean.java:10:
'}'
expected
^
1
2001 i686 unknown
Francisco
On Wed, 10 Sep 2003, Scott M Stark wrote:
No, I just did a checkout and build of 3.2 using 1.4.2 on RH9. What compiler and
OS are you using?
Francisco Reverbel wrote:
Fresh checkout. The build.sh script fails with this error:
compile-classes:
[javac
did a checkout and build of 3.2 using 1.4.2 on RH9. What compiler and
OS are you using?
Francisco Reverbel wrote:
Fresh checkout. The build.sh script fails with this error:
compile-classes:
[javac] Compiling 584 source files to
/usr/local/reverbel/jboss-3.2/server/output/classes
, Adrian Brock wrote:
Hi Francisco,
It looks like xdoclet screwed up at some point.
This is generated source.
Do you get the same error if you ./build.sh clean
before rebuilding?
Regards,
Adrian
On Wed, 2003-09-10 at 16:14, Francisco Reverbel wrote:
Java 1.4.2 on Debian 3.0 (woody
Hi Adam,
On Mon, 11 Aug 2003, Adam Wasserman wrote:
Hello all,
I am using JBoss 3.2.1 and would like to deploy a stateless session bean
using the iiop invoker. The remote interface of this bean makes use of an
object with a reference to an array of java.util.Map objects. During
,
Francisco
On Wed, 13 Aug 2003, Francisco Reverbel wrote:
Hi Adam,
On Mon, 11 Aug 2003, Adam Wasserman wrote:
Hello all,
I am using JBoss 3.2.1 and would like to deploy a stateless session bean
using the iiop invoker. The remote interface of this bean makes use of an
object
All IIOP tests fail in the 4.0 branch. Does anybody know why?
I thought there were no IIOP changes in head since it was branched
off 3.x.
There are some IIOP fixes in 3.2 that need to be merged into head.
Following the usual test before, test after procedure, I run
the tests before doing it,
The 3.2 branch (fresh check out just taken from CVS) is giving me
the exception below with IBM's VM on Linux.
Shouldn't we fix this before 3.2 goes final?
Cheers,
Francisco
-
$ uname -a
Linux pong 2.2.19 #1 SMP Wed Oct 17 08:56:33
: Francisco Reverbel [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Sent: Tuesday, March 04, 2003 10:01 PM
Subject: Re: [JBoss-dev] jboss_3_2.dtd updated
These ejb-refs could have been defined outside of the invoker element.
Invoker-specific ejb-refs make sense when you
On Tue, 4 Mar 2003, Scott M Stark wrote:
The jboss_3_2.dtd was way out of date with respect to the container
invoker configuration so I updated it and checked it in. Take a look
at this and see if there are other missing elements or elements that
should be dropped.
One construct that I
You won't find this in the servlet spec.
SomeClassName[some/object/id]/some/file/path is a JBoss convention
for specifying Java classes and resources dynamically downloaded by
clients. It is used by org.jboss.web.WebClassLoader and by
org.jboss.iiop.WebCL. See comments in
The IIOP tests also rely on remote class loading. They should
still work after the simple web server is replaced by a servlet.
(The *-iiop tests run on a server with configuration 'all'.)
Cheers,
Francisco
On Fri, 7 Feb 2003, Scott M Stark wrote:
There is a dynamic class loading unit test:
On Tue, 21 Jan 2003, marc fleury wrote:
And, finally, why did you tightly couple distributed tx logic with
invoker's implementation? Why is not it possible to write an
interceptor
that does distributed tx stuff that you've described but in invoker
independent way?
If only ole
On Tue, 21 Jan 2003, David Jencks wrote:
On Tuesday, January 21, 2003, at 09:43 AM, Francisco Reverbel wrote:
On Tue, 21 Jan 2003, marc fleury wrote:
And, finally, why did you tightly couple distributed tx logic with
invoker's implementation? Why is not it possible to write
The one-test target does not work for IIOP tests, which require
IIOP-related arguments to be passed to the JVM.
To run IIOP tests, use the iiop-test target (runs all IIOP tests in a
given directory) or the tests-iiop-stress target (runs all IIOP tests):
testsuite/build.sh -Dtest=helloiiop
I looked for Scott's HttpInvoker in HEAD and didn't find it there.
Where is it?
Cheers,
Francisco
---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
Well, if you are pooling fine grained objects you should not
use java.util.LinkedList to implement the pool. Whenever you
add an element to a LinkedList you are creating an auxiliary
Entry object, with fields `element', `next', and `previous'.
To do pooling of fine grained objects you should
Hi,
I am also playing with a new invoker. Well, not really new... It is
actually the JRMP invoker code, with just a few changes to sent the
Invocation over IIOP rather than JRMP. In the lack of a better name,
I am calling it JavaIIOPInvoker.
JavaIIOPInvoker is quite different from the plain
So far we have been using port 8683 for IIOP. We picked the well
know port number assigned to IIOP (which is 683) and added 8000
just to get out of the system port range.
However, 8683 is not an officially assigned user port for IIOP
(there is no such a thing), but simply an unassigned port
Did a fresh checkout, but the server refuses to run. A stack trace
is included below. Switching JDK does not make a difference: tried
Sun 1.3.1_03, Sun 1.4.0, and IBM 1.3.1 (all on Linux).
Is anybody else seeing this?
Cheers,
Francisco
This is pretty much what we have in 3.1. Look at the jboss.xml file of
the hellojrmpiiop test:
http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/jboss/jbosstest/src/resources/hellojrmpiiop/META-INF/jboss.xml?rev=1.1content-type=text/vnd.viewcvs-markup
Cheers,
Francisco
On Sun, 14 Jul 2002, Scott
Great, we're back in business. The testsuite runs again. Thanks,
Francisco
On Sun, 9 Jun 2002, Scott M Stark wrote:
I updated the build file with some changes that were missing for the
multi-config
build output. The all config is now populated correctly.
- Original Message -
Thanks for your reply, Jason.
Eventually we will have everything listed... in fact we have a similar include
for the javac task, so perhaps XDoclet needs to be fixed to not cache so much
data at one (or whatever).
Yes.
Have you tried increasing the heap for the vm used to build? I would
On Sun, 26 May 2002, Matthew Tippett wrote:
Technically speaking the docset is not 'too big', it is simply causes
too many native threads to be created for most 'default' Linux
distributions.
Run the sample program and you should with a Linux 2.4 system get around
220ish threads. The
Help!
I am running build/build.sh on HEAD and Branch_3_0 trees just
checked out from CVS. On both trees build fails within xdoclet:
java.lang.OutOfMemoryError: unable to create new native thread
(Branch 3.0 error included below.)
Both Sun and IBM JDKs are giving me the same error. My
: xdoclet barfed on the big
fileset. Maybe there is something in my Linux environment that made
me run out of memory before anybody else.
Cheers,
Francisco
On Sat, 25 May 2002, Francisco Reverbel wrote:
Help!
I am running build/build.sh on HEAD and Branch_3_0 trees just
checked out from CVS
Did you buid JBoss with JDK 1.4 and attempted to start the server with
IBM's 1.3 or 1.3.1 VM for Linux, by any chance? I had trouble in this
case.
It appears that a 1.4-generated server barfs with IBM's 1.3.x VMs for
Linux. Do not ask me why... ;-(
Best,
Francisco
On Tue, 21 May 2002, Dain
are now working in 3.1 (CVS HEAD). Marc: your vision is real!!! Even
concurrent JRMP and IIOP invocations appear to be working fine. I have
committed yet another version of the hello test (hellojrmpiiop) to
demonstrate this.
Here is a summary of the recent changes on the IIOP stuff in 3.1:
-
For those in South America this coming week: on May 23 (4:30PM) I will
be an invited speaker at the Objetos 6006 conference, in Sao Paulo,
Brazil. This event is jointly organized by three Sao Paulo user groups
-- the OO/UML user group, the Java user group, and the CORBA user group.
More info
On Sun, 12 May 2002, Jason Dillon wrote:
Currently we are binding to jmx:hostname:rmi which is fine when you are
working with the localhost, but will start to cause problems once used in a
multi-host environment.
...
So for a client on a remote host to correctly make use of the deployer.sh
Hello,
I am running Debian Linux 3.0, kernel 2.4.10.
Built JBoss 3.1 (CVS HEAD) with Sun JDK 1.4. The server barfs with IBM
VMs 1.3 and 1.3.1. A stack trace is included below. The same 1.4-built
server runs fine with Sun VMs 1.3.1_02, 1.3.1_03, and 1.4.
Rebuilt the server from scratch, now
Francisco Reverbel wrote:
Is anybody else getting this? I am using jdk1.4 on linux.
Francisco
-
...
[xdoclet] Running deploymentDescriptor/
[xdoclet] Running jboss/
[execmodules] Running
Is anybody else getting this? I am using jdk1.4 on linux.
Francisco
-
...
[xdoclet] Running deploymentDescriptor/
[xdoclet] Running jboss/
[execmodules] Running xdoclet.XDocletMain loaded by
On Wed, 1 May 2002, Theo Harper wrote:
Thanks for the help regarding the IIOP hang, after changing the port to 8683
JBoss starts up okay. Will Branch_3_0_0 be updated with this fix?
The default IIOP port is already 8683 in HEAD, Branch_3_0_0, and 3.0.0RC2.
Francisco
As Adrian pointed out some time ago, the IIOP port in the
default config in HEAD and branch 3.0 (port 5000) conflicts
with a Windows XP service (SSDP Discovery Service, used for
Universal Plug and Play).
I considered changing the default config and moving IIOP to the
port officially reserved
Will do it. Just checked at www.iana.org and 8683 is unassigned,
so it should be better than our current port.
Thanks,
Francisco
On Tue, 30 Apr 2002, Jason Dillon wrote:
Why not change it to 8683 by default then?
--jason
Francisco Reverbel wrote:
As Adrian pointed out some time
On Wed, 24 Apr 2002, Anatoly Akkerman wrote:
It is a big and complex beast. I remember digging through it when I
found some bugs, shrug ... It implements all the CORBA JTA stuff for
distributed TXs. I just wrote a hack to propagate the transaction context
together with JBoss
This message jacob.properties not found is just a warning
and can be ignored. I am about to commit some changes the will
make it go away.
Francisco
On Tue, 23 Apr 2002, marc fleury wrote:
he...
did rm on the old stuff
then a CLEAN CO
then build (builds fine btw)
then start and I get
On Tue, 23 Apr 2002, Jason Dillon wrote:
Fransico, put in a dummy jacob.properties in default/conf when IIOP
builds to avoid this mess please.
This doesn't work, probably because JacORB is not using the context
classloader to load its resources. Wait a moment, I will commit a
simple change
You may need to upgrade your JDK to build the IIOP stuff, due to an
rmic bug in some older JDK versions. You should not need to upgrade
you JDK to run IIOP. If it is already built then it should run.
(With a jacorb.properties not found warning, which will go away
in a few minutes...)
Are you
Francisco the error that I am seeing
my VM is
java version 1.3.0
Java(TM) 2 Runtime Environment, Standard Edition
(build 1.3.0)
Classic VM (build 1.3.0, J2RE 1.3.0 IBM build
cx130-20010502 (JIT enabled: jitc)
This is a known problem in the IBM VM.
Just commited some changes
Sorry for the trouble. Port 5000 was just a random (and poor) choice I
have made when implementing the IIOP stuff.
I will change the default config and move IIOP to the port officially
reserved for IIOP, whatever such port is (do not have the OMG docs at
hand right now).
As for the warning
from 24264
bytes to 27211 bytes. A lame workaround (which does not work for netboot)
would be to add jacorb.jar to the system classpath.
Best,
Francisco
--jason
Quoting Francisco Reverbel [EMAIL PROTECTED]:
Sorry for the trouble. Port 5000 was just a random (and poor) choice I
User: reverbel
Date: 02/04/20 12:31:05
Modified:.build.xml
Log:
- IIOP tests excluded from tests-standard-stress.
- Created target tests-iiop-stress.
- Targets tests and tests-stress now depend on tests-iiop-stress.
Revision ChangesPath
1.110
User: reverbel
Date: 02/04/19 05:46:28
Modified:iiop/src/main/org/jboss/iiop Tag: Branch_3_0 WebCL.java
Log:
Change merged from HEAD: use UnifiedClassLoader from org.jboss.mx.loading.
Revision ChangesPath
No revision
No
User: reverbel
Date: 02/04/19 05:58:44
Added: iiop/src/etc Tag: Branch_3_0 iiop-service.xml
Log:
Merged from HEAD: IIOP MBean moved to a separate service.
Revision ChangesPath
No revision
No revision
1.1.2.1 +0 -0
User: reverbel
Date: 02/04/19 05:52:40
Modified:iiop/src/main/org/jboss/iiop Tag: Branch_3_0
CorbaORBService.java
Log:
Merged changes from HEAD:
- CorbaORBService now sets the system properties org.omg.CORBA.ORBClass and
User: reverbel
Date: 02/04/19 06:05:15
Modified:jacorb/jacorb/lib Tag: Branch_3_0 README jacorb.jar
Log:
Change merged from HEAD:
Patched jacorb.jar to be compatible with org.omg.* stubs in JDK 1.4.
Before this change we needed the Xbootclasspath switch to avoid loading
User: reverbel
Date: 02/04/19 06:10:04
Modified:src/etc/conf/default Tag: Branch_3_0 jboss-service.xml
Log:
Merged change from HEAD: IIOP MBean moved to a separate service.
Revision ChangesPath
No revision
No revision
User: reverbel
Date: 02/04/19 06:24:58
Modified:jbossTag: Branch_3_0 build.xml
Log:
Merged change from HEAD: copy iiop-service.xml to deploy dir.
Revision ChangesPath
No revision
No revision
1.117.2.2 +10 -1
Hi Jason,
Just noticed that the iiop stuff is not in the default build of
Branch_3_0. Could you change this?
Cheers,
Francisco
On Fri, 19 Apr 2002, Vesco Claudio wrote:
OK,
Claudio
PS: I can do it now... :-)
-Original Message-
From: Francisco Reverbel [SMTP
I want to make iiop tests run sucessfully at lubega.
They must be removed from tests-standard-stress and placed
in a new target, tests-iiop-stress. (Claudio: you did this
already, right?)
Then I guess we should make the tests-stress target depend on
tests-iiop-stress. Is this right? I don't
1 - 100 of 320 matches
Mail list logo
