You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomee.apache.org by Rick McGuire <ri...@gmail.com> on 2006/07/20 13:07:40 UTC

CorbaBean listener port configuration.

I'm still trying to make some sense out of what's happening with the 
initial listener set ups with CorbaBean.  I'd like to define a 
consistent set of rules and also replace ORB-specific mechanisms like 
the -ORBPort argument with hostname and port attributes on the CorbaBean 
itself.  CorbaBean has a getListenAddress() method that is mostly broken 
currently.  If possible, I'd like to fix this up so it returns something 
meaningful. 

Here's the current situation with respect to different methods of 
setting the initial listening port and what gets returned by 
getListenAddress().

   1. Nothing configured (no -ORBPort argument, no tssConfig
      specified):  Listener is created on port 6882, getListenAddress()
      reports the same.
   2. Initial port configured using "-ORBPort xxxx", no tssConfig
      specified):  Listener is created on port "xxxx",
      getListenAddress() reports the that 6882 is being used.
   3. No -ORBPort, tssConfig is specified, but no SSL port and host name
      values are given:  Listener is created on any available port,
      getListenAddress() returns null.
   4. No -ORBPort, tssConfig is specified, AND the SSL port and host
      name values are given:  Listener is created on the specified port,
      getListenAddress() returns the same information.


I'd like to clean this up and have a port and hostname property on 
CorbaBean to replace the use of -ORBport in the plans.  This still 
leaves us with two ways to specify the port and host information 1)  the 
CorbaBean attributes and 2)  The transport config values.  I believe, 
that 2), if specified, should override 1).  But what should be the 
behavior if neither is specified?  Here are some of the options:

   1. Make it a requirement that a valid port (>0) be specified.
   2. Use a default (e.g., the existing 6882).  This will cause
      conflicts if multiple ORBs are getting configured on same server.
   3. Allow the ORB to use any available port.  This works ok, but I've
      not found a means to ask the ORB what port is getting used. 
      getListenAddress() will not be able to provide the information.

What we have now is largely broken, but fixable if we can decide on what 
the rules need to be.

Rick