; [mailto:[EMAIL PROTECTED] On
> > Behalf 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.
> >
> > > -O
+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 wh
you patch this? We aren’t getting a response from the jacorb
> list.
>
>
>
>
> __
> From:[EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of
> Rajesh Rajasekaran
> Sent: Monday, February 13, 2006 5:04 PM
> To: jbos
[ 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.
[ 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 Resou
[ 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:/
[ http://jira.jboss.com/jira/browse/JBAS-1647?page=history ]
Francisco Reverbel closed JBAS-1647:
> Provide JBoss remoting-based implementations of the DTM interfa
[ http://jira.jboss.com/jira/browse/JBAS-1648?page=history ]
Francisco Reverbel closed JBAS-1648:
> Complete the existing implementation of the OTS interfaces
> --
>
> Ke
[ 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
[ 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.
[ 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/j
[ http://jira.jboss.com/jira/browse/JBAS-1648?page=history ]
Francisco Reverbel resolved JBAS-1648:
--
Resolution: Done
> Complete the existing implementation of the OTS interfa
[ 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 interfa
[ 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
&g
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 to
-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
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
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 of the
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
: 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
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 to
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 a
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
[ 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 configura
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
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 is
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
[ 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
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
service
Versions: JBossAS-5.0 Alpha
Reporter: Francisco Reverbel
Assigned to: Francisco Reverbel
The existing OTS servant does not yet implements register_resource, recreate,
and replay_completion. The implementation of those methods will delegate the
actual work to the
[ 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 interfa
: 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 to
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 to be
[ 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/ JB
[ 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
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 For
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 nonsense.
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 availab
xx
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] 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 jbos
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,
Francis
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
w what is the status of Jacorb WRT csiv2?
>
> Cheers,
>
>
> sacha
>
> > -Original Message-
> > From: [EMAIL PROTECTED]
> > [mailto:[EMAIL PROTECTED] On
> > Behalf Of Francisco Reverbel
> > Sent: vendredi, 7. novembre 2003 12:34
> >
]
> > [mailto:[EMAIL PROTECTED] 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
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
st below 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 PRO
m: [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,
> >
> > The test result
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.
I'm tired o
> 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
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 =
2003, 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 Re
ust 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
&
56:33 BRST 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
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 erro
heers,
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. Th
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
Replying to my own message before anybody else spends time on this...
On Wed, 28 May 2003, Francisco Reverbel wrote:
> 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.
This was the problem. The
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, o
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
We have no stub files at all, so there is no way our iiop test clients
could pick stubs from the classpath.
Which ORB are you using at the client side?
Francisco
On Thu, 20 Mar 2003, Scott M Stark wrote:
> So are the current iiop tests picking up the stubs from the classpath rather
> than down
I'll try to be more precise. In order to interact with Y, X must use a
reference to Y. This reference determines the protocol over which the
interaction will take place.
If X calls Y for its own consumption, without obtaining from Y any
reference that may be returned to the caller of X, then X i
Boss Group, LLC
> xxxx
>
> - Original Message -
> From: "Francisco Reverbel" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Cc: <[EMAIL PROTECTED]>
> Sent: Tuesday, March 04, 2003 10:01 PM
> Subject: Re: [JBoss-dev] jboss
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
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
server/src/main/or
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, 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
> >>> invoke
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 o
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 -Dno
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 I
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.1&content-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 -
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.
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 wo
ame result: 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
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 config
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
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
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:
-
On Sun, 12 May 2002, Jason Dillon wrote:
> Currently we are binding to "jmx::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 w
you have an old
> xdoclet or an version mismatch between ant and xdoclet?
>
> -danch
>
> Francisco Reverbel wrote:
> > Is anybody else getting this? I am using jdk1.4 on linux.
> >
> > Francisco
> >
> >
Is anybody else getting this? I am using jdk1.4 on linux.
Francisco
-
...
[xdoclet] Running
[xdoclet] Running
[execmodules] Running xdoclet.XDocletMain loaded by
sun.misc.Launcher$AppClassLoader. Forked:true
[xdocl
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
_
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 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 f
See this thread:
http://www.jboss.org/forums/thread.jsp?forum=66&thread=13521
Either disable the SSDP Discovery Service on Windows XP or change
the IIOP port (OAPort) in server/default/conf/jacorb.properties.
Will send another message on this issue right now.
Regards,
Francisco
On Tue, 3
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 MethodInvocat
> 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
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 s
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
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
implemented
(but did not commit) this. Works perfectly, but run.jar grows 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 <
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 co
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 +56
On Sat, 20 Apr 2002, Chris Kimpton wrote:
> Lubega runs the "run-testsuite" target in the build/build.xml
>
> This runs the "tests" target in testsuite/build.xml
>
> This runs various tests - but not the tests-stress target - but they should
> both have the same dependencies. So add tests-iiop
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 k
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-
&
1 - 100 of 341 matches
Mail list logo
