Is this a bug in VisiBroker v3.1 ? (for Java)
Frederic Desjarlais
Hi,
I sent the operation '_interface' to an object located in a Visigenic
3.1 ORB using IIOP, and I got back:
"Reply Body System Exception ID = IDL:omg.org/CORBA/UNKNOWN:1.0"
on the client side. This is ok, since the error is a Java error (see
below) and according to the spec, the ORB is suppose to return this error if
it receives a non-standard error (p.12-18 in CORBA v2.1).
However, on the server side, I got the dump that is appended below. I
made sure that the IR server was up and that the IDL definition was added to
it (idl2ir). What bothers me is the first line in the dump:
"java.lang.NoSuchFieldError: org.omg.CORBA.TCKind: field tk_estruct not
found"
Shouldn't the TCKind field be tk_struct and not tk_estruct?
----- CUT HERE -----
C:\java\classes\corbatest>java corbatest.DummyServer
implementation is ready.
java.lang.NoSuchFieldError: org.omg.CORBA.TCKind: field tk_estruct not found
at com.visigenic.vbroker.orb.AnyImpl.toString(AnyImpl.java:851)
at
com.visigenic.vbroker.IOP.TaggedProfile.toString(TaggedProfile.java:3
5)
at java.lang.String.valueOf(String.java:1305)
at java.lang.StringBuffer.append(StringBuffer.java:315)
at
com.visigenic.vbroker.orb.IiopProtocolImpl.profileBody(IiopProtocolIm
pl.java:89)
at
com.visigenic.vbroker.orb.IiopAdapter.getObject(IiopAdapter.java:90)
at
com.visigenic.vbroker.orb.AdapterManagerImpl.getObject(AdapterManager
Impl.java:98)
at com.visigenic.vbroker.orb.ORB.iorToObject(ORB.java:1308)
at
com.visigenic.vbroker.orb.GiopInputStreamImpl.read_Object(GiopInputSt
reamImpl.java:67)
at org.omg.CORBA.ContainedHelper.read(ContainedHelper.java:69)
at org.omg.CORBA._st_Repository.lookup_id(_st_Repository.java:71)
at
com.visigenic.vbroker.orb.dynamic.OrbHelperImpl.get_interface(OrbHelp
erImpl.java:20)
at com.visigenic.vbroker.orb.ORB.get_interface(ORB.java:510)
at
com.visigenic.vbroker.orb.SkeletonDelegateImpl.get_interface(Skeleton
DelegateImpl.java:242)
at
org.omg.CORBA.portable.ObjectImpl._get_interface(ObjectImpl.java:27)
at
com.visigenic.vbroker.orb.SkeletonDelegateImpl.execute(SkeletonDelega
teImpl.java:138)
at
com.visigenic.vbroker.orb.GiopAdapterThread.doRequest(GiopAdapterThre
ad.java:258)
at
com.visigenic.vbroker.orb.GiopAdapterThread.dispatch(GiopAdapterThrea
d.java:409)
at
com.visigenic.vbroker.orb.ThreadPoolDispatcher$1.run(ThreadPoolDispat
cher.java:49)
at com.visigenic.vbroker.util.ThreadPool.run(ThreadPool.java:49)
at java.lang.Thread.run(Thread.java:474)
VisiBroker for Java runtime throwing: org.omg.CORBA.UNKNOWN[completed=MAYBE,
rea
son=Exception: java.lang.NoSuchFieldError: org.omg.CORBA.TCKind: field
tk_estruc
t not found]
----- CUT HERE -----
Thanks,
Frederic Desjarlais
fdes...@nospam.chat.carleton.ca // remove nospam to email
Andreas Vogel
Frederic Desjarlais wrote:
> Hi,
>
> I sent the operation '_interface' to an object located in a Visigenic
> 3.1 ORB using IIOP, and I got back:
Call either public abstract org.omg.CORBA.InterfaceDef _get_interface();
or
public abstract java.lang.String _repository_id();
These are methods on org.omg.CORBA.Object.
Hope that helps,
Andreas
--
Stay tuned for the 2nd, completely revised and significantly extended edition of
"Java Programming with CORBA", www.wiley.com/compbooks/vogel,
by Andreas Vogel and Keith Duddy, J.Wiley & Sons, New York, 2nd edition, 2/98
Frederic Desjarlais
Andreas,
I agree that _get_interface is the correct call - but this only when you
are using the stubs generated by idl2java.
However, I am using a custom-made CORBA v2.1 compliant IIOP engine
designed for a special purpose. The CORBA v2.1 spec on page 12-23 says that
the operation to get the interface is _interface - and so this is what I'm
sending. I can correctly send the operations defined in the interface, but
not all the one's it inherits (_interface in particular - since I want to
introspect the object the IOR references).
What worries me is that the there might be an error in the ORB deamon or
whatever process generates the following (part of dumping shown earlier):
java.lang.NoSuchFieldError: org.omg.CORBA.TCKind: field tk_estruct not found
at com.visigenic.vbroker.orb.AnyImpl.toString(AnyImpl.java:851)
at
com.visigenic.vbroker.IOP.TaggedProfile.toString(TaggedProfile.java:3
5)
Since the VM can't find the field tk_estruct, it throws an exception -
this is why I get an UNKNOWN exception back on the client side (page 12-18
of the spec says that the ORB should throw that exception if it receives a
non-standard system exception, which it would be in this case). I beleive
the correct field in TCKind is tk_struct - not tk_estruct. Maybe it's a
programmer typo since 'e' and 's' are close together - it happens.
If the operation was truly not the proper one, I would have received
BAD_OPERATION instead (I've received this when trying to send an operation
that a interface does not define or when the IR was not running). However,
I made sure the IR was running and that the interface was published in it.
Thanks,
Frederic Desjarlais
Carleton Univeristy
Honours Comp.Sci Year IV
Andreas Vogel wrote in message <34F89757...@visigenic.com>...
George Scott
Frederic Desjarlais wrote:
> Hi,
>
> I sent the operation '_interface' to an object located in a Visigenic
> 3.1 ORB using IIOP, and I got back:
>
> "Reply Body System Exception ID = IDL:omg.org/CORBA/UNKNOWN:1.0"
>
> on the client side. This is ok, since the error is a Java error (see
> below) and according to the spec, the ORB is suppose to return this error if
> it receives a non-standard error (p.12-18 in CORBA v2.1).
>
> However, on the server side, I got the dump that is appended below. I
> made sure that the IR server was up and that the IDL definition was added to
> it (idl2ir). What bothers me is the first line in the dump:
>
> "java.lang.NoSuchFieldError: org.omg.CORBA.TCKind: field tk_estruct not
> found"
>
> Shouldn't the TCKind field be tk_struct and not tk_estruct?
VisiBroker for Java supports passing objects-by-value, in a new data type wecall
"extensible structs". This is a vendor feature and is supported by code
in both the org.omg.* packages as well as the com.visigenic.vbroker.* packages.
I suspect the problem you are seeing is that you are not using the VisiBroker
org.omg.* package perhaps because you have written your own or you are using
JDK 1.2. However, this problem was corrected in VisiBroker 3.1, so I am
surprised
that you are seeing this particular problem. Here are my suggestions:
1. If you are using JDK 1.2 Beta, do not put the JDK 1.2 classes in your
CLASSPATH
as they are not needed and the Java VM will add them automatically.
2. If you are using VBJ 3.1, then I would recommend verifying your installation
by
running "vbj -version" to verify the version is 3.1. VBJ 3.1 changed the
organization
of the JAR files which compose the product and you may be picking up an old
version,
if your CLASSPATH contains the old files.
3. VBJ 3.2 has been released, and has many major improvements over VBJ 3.1. I
would
recommend uninstalling VBJ 3.1, and upgrading to VBJ 3.2 to take advantage of
the
new features and performance enhancements.
George
Stephen Crawley
In article <6daf9t$q8m$1...@bertrand.ccs.carleton.ca>,
Frederic Desjarlais <fdes...@chat.carleton.ca> wrote:
>Andreas,
>
> I agree that _get_interface is the correct call - but this only when you
>are using the stubs generated by idl2java.
>
> However, I am using a custom-made CORBA v2.1 compliant IIOP engine
>designed for a special purpose. The CORBA v2.1 spec on page 12-23 says that
>the operation to get the interface is _interface - and so this is what I'm
>sending. I can correctly send the operations defined in the interface, but
>not all the one's it inherits (_interface in particular - since I want to
>introspect the object the IOR references).
I believe that your interpretation of the CORBA spec is correct. If
VisiBroker is giving you "BAD_OPERATION" in response to a "_interface"
request on any object, it is not CORBA v2.1 compliant.
VisiBroker is not the only ORB with problems in this area - Orbix gets
it wrong too.
-- Steve
Bill Janssen
I believe that your interpretation of the CORBA spec is correct. If
VisiBroker is giving you "BAD_OPERATION" in response to a "_interface"
request on any object, it is not CORBA v2.1 compliant.
Not in this respect, anyway.
VisiBroker is not the only ORB with problems in this area - Orbix gets
it wrong too.
So does ILU, and we don't intend to fix that. ORBs get much simpler when
you can discard the IR and DII, or at least make them optional.
Bill
--
Bill Janssen <jan...@parc.xerox.com> (650) 812-4763 FAX: (650) 812-4777
Xerox Palo Alto Research Center, 3333 Coyote Hill Rd, Palo Alto, CA 94304
URL: ftp://ftp.parc.xerox.com/pub/ilu/misc/janssen.html
Roland Turner
George Scott wrote:
> VisiBroker for Java supports passing objects-by-value, in a new data type wecall
> "extensible structs". This is a vendor feature and is supported by code
> in both the org.omg.* packages as well as the com.visigenic.vbroker.* packages.
!!!
Are you saying that you've ALTERED the org.omg.* interface?
> I suspect the problem you are seeing is that you are not using the VisiBroker
> org.omg.* package perhaps because you have written your own or you are using
> JDK 1.2. However, this problem was corrected in VisiBroker 3.1, so I am
> surprised
> that you are seeing this particular problem.
By corrected do you mean that the extensions were removed from the
org.omg.* interface?
To get at your vendor extensions should REQUIRE the use of classes in
com.visigenic.vbroker.* hierachy.
If not, you have a situation exactly akin to Microsoft's extending the
Java standard library - you've added your own extensions so that code
written/compiled against your delivered version of the standard
org.omg.* interface looks as though it is using the standard interface,
but won't run against anyone else's delivered version.
The IDL->Java mapping goes out of its way to ensure the ORBs can
co-exist by removing all vendor specific stuff from the org.omg.*
interface (apart from comments and two defaults for ORB
initiailisation).
The moment vendor A says "you can only run our ORB with our extended
org.omg.* interface" and vendor B says the same about their extended
org.omg.* interface, all of that work goes out of the window.
Say it ain't so!
- Raz
Michi Henning
On Fri, 6 Mar 1998, Roland Turner wrote:
> Are you saying that you've ALTERED the org.omg.* interface?
Wouldn't be the first time. Just look at the CORBA module of some vendors.
Lots of stuff that is completely proprietary, happily piled into the
CORBA module...
Cheers,
Michi.
--
Michi Henning +61 7 33654310
DSTC Pty Ltd +61 7 33654311 (fax)
University of Qld 4072 mi...@dstc.edu.au
AUSTRALIA http://www.dstc.edu.au/BDU/staff/michi-henning.html
Michi Henning
On 5 Mar 1998, Bill Janssen wrote:
> In article <6dl7d0$p...@azure.dstc.edu.au> cra...@dstc.edu.au (Stephen Crawley) writes:
>
> I believe that your interpretation of the CORBA spec is correct. If
> VisiBroker is giving you "BAD_OPERATION" in response to a "_interface"
> request on any object, it is not CORBA v2.1 compliant.
>
> Not in this respect, anyway.
>
> VisiBroker is not the only ORB with problems in this area - Orbix gets
> it wrong too.
>
> So does ILU, and we don't intend to fix that. ORBs get much simpler when
> you can discard the IR and DII, or at least make them optional.
I believe a compliant way to handle IFR non-existence would be to return
a nil reference in response to an _interface request. This means the
operation is supported, but no IFR was available.
Cheers,
Michi.
Copyright 1998 Michi Henning. All rights reserved.
Stephen Crawley
In article <y1a7m68...@holmes.parc.xerox.com>,
Bill Janssen <jan...@parc.xerox.com> wrote:
>In article <6dl7d0$p...@azure.dstc.edu.au> cra...@dstc.edu.au (Stephen Crawley) writes:
>
> I believe that your interpretation of the CORBA spec is correct. If
> VisiBroker is giving you "BAD_OPERATION" in response to a "_interface"
> request on any object, it is not CORBA v2.1 compliant.
>
>Not in this respect, anyway.
>
> VisiBroker is not the only ORB with problems in this area - Orbix gets
> it wrong too.
>
>So does ILU, and we don't intend to fix that. ORBs get much simpler when
>you can discard the IR and DII, or at least make them optional.
I do not like this approach at all. It is against the letter of the
spec, and it violates the purpose of IIOP which is to allow ORBs to
interoperate.
What you are (in effect) doing is subsetting IIOP to simplify your
implementation. This will cause ILU users problems when they try to
use ORBs that assume that you CAN call "_interface" on an object.
The reason that I discovered that Orbix is deficient in this area was
that we were trying to use a JDK1.2 client to call an Orbix C++
server. The JDK1.2 client, as part of some stub code generated by the
IDL compiler, was trying to send an "_is_a" operation. The Orbix
server stubs did not recognise this. Our only solution was to change
to using OrbixWeb as the client side ORB. Fortunately, we discovered
this soon enough that it wasn't too painful to make the switch.
If you really want to make the requirement to implement "_interface",
"_implementation", "_is_a", etc optional, then you should get together
with other ORB vendors and propose this change through the standard
OMG processes and procedures. Making this sort of change by stealth
is doing the CORBA community a major disservice!
I'll be glad when OMG's compliance testing and badging initiatives
start to show results ...
-- Steve
George M. Scott
Roland Turner wrote:
> George Scott wrote:
>
> > VisiBroker for Java supports passing objects-by-value, in a new data type wecall
> > "extensible structs". This is a vendor feature and is supported by code
> > in both the org.omg.* packages as well as the com.visigenic.vbroker.* packages.
>
> !!!
>
> Are you saying that you've ALTERED the org.omg.* interface?
It depends on your definition of altered. We added vendor hooks whichdo not break binary
compatibility with other ORB vendors when they use
our implementation of org.omg.*. No methods were modified, we only
added additional API hooks, for compatibility with our previous releases.
> > I suspect the problem you are seeing is that you are not using the VisiBroker
> > org.omg.* package perhaps because you have written your own or you are using
> > JDK 1.2. However, this problem was corrected in VisiBroker 3.1, so I am
> > surprised
> > that you are seeing this particular problem.
>
> By corrected do you mean that the extensions were removed from the
> org.omg.* interface?
Some were, but really what I mean by corrected, is our ORB runtime(com.visigenic.vbroker.*) does not
assume that we are using our
org.omg.* package, which was previously (versions prior to VBJ 3.1) assumed.
This change was made primarily to support JDK 1.2. which provides an
org.omg.* package.
> To get at your vendor extensions should REQUIRE the use of classes in
> com.visigenic.vbroker.* hierachy.
It does, there is no implementation code in the org.omg.* package.
> If not, you have a situation exactly akin to Microsoft's extending the
> Java standard library - you've added your own extensions so that code
> written/compiled against your delivered version of the standard
> org.omg.* interface looks as though it is using the standard interface,
> but won't run against anyone else's delivered version.
The Java language mapping currently does not specify where vendorextensions may be placed, nor does
it prohibit vendor extensions from
being placed in the org.omg.* package. We have submitted a revised
language mapping which does state that vendor extensions are prohibted
from being placed in the org.omg.* package, and when that submission
is adopted we will be making the corresponding changes to our product.
It is quite common for CORBA vendors to add vendor features into the
CORBA module. In fact, I doubt you can find a C++ CORBA vendor
who has not done this. In Java, we have a slightly different situation
in that we may share org.omg.* packages, so we are taking steps to
address the problem, but it won't solve it completely. For instance, the
OMG may add 10 new methods to CORBA::Object. Our product may
support all 10, so we will make the corresponding modifications to our
org.omg.* package, but another vendor may be slow to adopt and only
support 5 new methods. Incompatibilties and problems can still result.
The org.omg.* package is in no way a "frozen" API, the OMG frequently
adds new features to CORBA, which at times require modification to
classes in these packages.
> The IDL->Java mapping goes out of its way to ensure the ORBs can
> co-exist by removing all vendor specific stuff from the org.omg.*
> interface (apart from comments and two defaults for ORB
> initiailisation).
As I said above, this was not explicit in the mapping. We made a decisionto be as compatible as
possible with our prior mapping (VisiBroker for Java 1.2)
which meant that some vendor extensions are present in the org.omg.*
package, most are not. This was the best decision for our customers, and
provided the simplest migration path from VBJ 1.2 -> VBJ 2.5/3.x for our
customers.
> The moment vendor A says "you can only run our ORB with our extended
> org.omg.* interface" and vendor B says the same about their extended
> org.omg.* interface, all of that work goes out of the window.
As I said, there will be problems in this area anyway because of changesto the CORBA spec by the
OMG.
George
Bill Janssen
I believe a compliant way to handle IFR non-existence would be to return
a nil reference in response to an _interface request. This means the
operation is supported, but no IFR was available.
Hmmm... sneaky, that, but valid, since any object reference parameter is allowed
to be the NIL object (another bad idea).
Jonathan Biggar
Bill Janssen wrote:
>
> In article <Pine.OSF.3.95.980306...@tigger.dstc.edu.au> Michi Henning <mi...@dstc.edu.au> writes:
>
> I believe a compliant way to handle IFR non-existence would be to return
> a nil reference in response to an _interface request. This means the
> operation is supported, but no IFR was available.
>
> Hmmm... sneaky, that, but valid, since any object reference parameter is allowed
> to be the NIL object (another bad idea).
Wouldn't it be better to throw an INTF_REPOS system exception with a
minor code that indicated that the IR wasn't available?
--
Jon Biggar
Floorboard Software
j...@floorboard.com
j...@biggar.org
Michi Henning
On Fri, 6 Mar 1998, Jonathan Biggar wrote:
> Bill Janssen wrote:
> >
> > In article <Pine.OSF.3.95.980306...@tigger.dstc.edu.au> Michi Henning <mi...@dstc.edu.au> writes:
> >
> > I believe a compliant way to handle IFR non-existence would be to return
> > a nil reference in response to an _interface request. This means the
> > operation is supported, but no IFR was available.
> >
> > Hmmm... sneaky, that, but valid, since any object reference parameter is allowed
> > to be the NIL object (another bad idea).
>
> Wouldn't it be better to throw an INTF_REPOS system exception with a
> minor code that indicated that the IR wasn't available?
Yes, possibly. Of course, there is no standard representation for minor
code values, so I'd still be writing non-portable code when I test the
value (the recent change that partitions the minor code into vendor
namespaces doesn't help - it's still impossible to write portable code
that looks at the minor field of a standard exception).
Maybe the very best thing of all would be if the spec actually *stated*
how an _interface request should be replied to if an ORB doesn't
provide an IFR or can't find the definition for the object in there?