Name: krC82822 Date: 01/23/2001


23 Jan 2001, eval1127@eng -- see also # 4383394, 4276908
----------
java version "1.3.0"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.0-C)
Java HotSpot(TM) Client VM (build 1.3.0-C, mixed mode)

Given the IDL below, and compiling with
idlj -verbose -fserver -pkgPrefix workflowx ourdomain.lws -td ..\..\..\..\..
WorkflowService.idl

a file called _WorkflowServiceImplBase.java will be created that tries to call
read and write methods in the class NodeServiceHelper. Unfortunately, idlj
doesn't create such a class, so it won't compile.

The compiler error is "NodeServiceHelper: no such class", or something like
that -- indeed, there is no NodeServiceHelper class, and it's trying to call a
static read() method on it.

The full IDL for WorkflowService.idl is:

#ifndef _WorkflowService_idl
#define _WorkflowService_idl

/*************************************************************************
Copyright (c) 2000 Cimarron Software, Inc.
*************************************************************************/

#include "../../../basicservicesx/corba/idl/TaggedObject.idl"

module workflowx
{
  module corba
  {
    struct NodeValue
    {
    unsigned long id;
    string name;
    unsigned long readyWorkItems;
    };
    
    struct WorkflowValue
    {
    string name;
    sequence < NodeValue > nodes;
    };
    
    struct WorkItemValue
    {
        unsigned long id;
        unsigned long nodeId;
        string name;
        string statusCode;
        string statusState;
        string priority;
        string insertionDateTime;
        string readyDateTime;
// This is for selecting by barcode
        sequence< string > elementLabels;
    };

    typedef sequence < WorkItemValue > WorkItemSequence;

    enum QueueItemState
    {
QS_ANY,
QS_NOTREADY,
QS_READY,
QS_WORK_IN_PROGRESS,
QS_HOLD,
QS_ERROR,
QS_FAILED_QC,
QS_RESERVED
    };

    interface NodeService
    {
        WorkItemSequence getReadyWorkList();
        
    };
    
    typedef sequence< WorkflowValue > WorkflowValueSequence;
    interface WorkflowService
    {
        WorkflowValueSequence getSummaries();
        NodeService getNode( in string workflowName, in string nodeName );
    };
    
  }; //corba module
}; //workflowx module

#endif


and the IDL for TaggedObject.idl (which it includes) is:

#ifndef _TaggedObject_idl
#define _TaggedObject_idl

/*************************************************************************
TaggedObject.idl
Copyright (c) 2000 Cimarron Software, Inc.
*************************************************************************/

module basicservicesx
{
    module corba
    {
        // Unique ID for all objects. Generated server-side. Note that this
        // is *not* the same as the opaque data type "OID"
        typedef unsigned long Id;

        typedef sequence< Id > IdSequence;

        // Type for defining values of objects. The value can be any
        // CORBA data type.
        struct TagValuePair
        {
string name;
any value;
        };

        typedef sequence< TagValuePair > TagValueSequence;

        // All remote objects have this fundamental structure; normally this
        // is hidden inside a wrapper class that provides convenience functions.
        // Note that we are pulling some basic attributes like id and type
        // out of the tagged values and up into the structure, for speed and
        // convenience on the client.
        struct TaggedObject
        {
Id idee;
string type;
string name;
string label;
TagValueSequence values;
        };

        typedef sequence< TaggedObject > TaggedObjectSequence;

    }; //corba module
}; //basicservicesx module

#endif

----------

user notes in follow-up mail:

"I don't believe this is the same problem as bug 4383394. That bug
is dealing with nesting typedef's inside a valuetype -- the helper class for
the nested typedef isn't generated. However, with this bug, it is an
interface whose helper class is not generated, and that interface is not
nested inside anything (except modules, which according to the workaround for
4383394, is okay).

Inside the idlj source, it may be the same problem as bug 4383394 (i.e. same
root cause), but the idl is different."
(Review ID: 105785)
======================================================================