Home Help Center

Setting a default configuration file

eric.hilleric.hill Member Eric HillOrganization: Pioneer Balloon Co.Project: Internal Research
What is the right way to set a default configuration file for a client so one doesn't have to be specified on the command line?

I tried this but it doesn't seem to be loading the config file.
Ice::InitializationData initdata;
initdata.properties = Ice::createProperties(argc, argv);
initdata.properties->setProperty("Ice.Config", "Foo.conf");

ice = Ice::initialize(initdata);

When I try to get a proxy from the communicator, I get the following error.
.\Reference.cpp:1124: Ice::NoEndpointException:
no suitable endpoint available for proxy `Foo -t'

If I specify the --Ice.Config on the command line and use this code, all works as expected.
ice = Ice::initialize(argc, argv);

Comments

  • marcmarc FloridaAdministrators, ZeroC Staff Marc LaukienOrganization: ZeroC, Inc.Project: The Internet Communications Engine ZeroC Staff
    Try the following:
    Ice::InitializationData initdata;
    initdata.properties = Ice::createProperties(argc, argv);
    initdata.properties->load("Foo.conf");
    
    ice = Ice::initialize(initdata);
    
  • mesmes CaliforniaAdministrators, ZeroC Staff Mark SpruiellOrganization: ZeroC, Inc.Project: Ice Developer ZeroC Staff
    Hi Eric,

    The Ice.Config property is only processed during the call to createProperties (which may also be called internally by Ice::initialize), so if you want to define it programmatically, you need to add it to the argument list that you pass to createProperties or initialize.

    If you don't want to deal with the hassle of modifying a native C array to append an --Ice.Config option, you can also do something like this:
    Ice::StringSeq seq = Ice::argsToStringSeq(argc, argv);
    seq.push_back("--Ice.Config=Foo.conf");
    ice = Ice::initialize(seq);
    
    Take care,
    - Mark
  • rc_hzrc_hz Member Eric RCOrganization: www.genband.comProject: No project yet ✭✭✭
    Hi,

    Another topic:)

    As Ice manul implicitly says, only command options prefixed with "--Ice, --IceBox, --IceGrid, --IcePatch2, --IceSSL, --IceStorm, --Freeze, --Glacier2" can be parsed as properties and others are ignored.

    That means, all Ice Object Adapter properties:
    name.AdapterId=id
    name.ReplicaGroupId=id
    name.Endpoints=
    name.PublishedEndpoints
    name.Locator
    name.RegisterProcess
    name.Router
    name.ThreadPool.Size
    name.ThreadPool.SizeWarn
    name.ThreadPool.SizeMax
    name.ThreadPool.StackSize
    name.PrintAdapterReady
    

    If we want to use these properties and don't what to hardcode them in source file, we have to config them in a seperate file and then use --Ice.Config to load them. I think I understand the reason of this design. However, this is sometimes very inconvenient. I think this can be improved: if another property such as Ice.Adapters can be added, then we can do:
    java Server --Ice.Adapters="OA1 OA2" --OA1.Endpoints="tcp -p 10000" --OA2.Endpoints="tcp -p 10001"
    
  • bernardbernard Jupiter, FLAdministrators, ZeroC Staff Bernard NormierOrganization: ZeroC, Inc.Project: Ice ZeroC Staff
    Yes. We're actually considering another slightly different solution: instead of using <adapter>.XXX properties to configure an adapter, we'd switch to Ice.OA.<adapter>.XXX properties. This would allow command-line arguments and checks with our property-name checking mechanism.

    Cheers,
    Bernard
  • rc_hzrc_hz Member Eric RCOrganization: www.genband.comProject: No project yet ✭✭✭
    Great! This seems to be more appropriate.
  • rc_hzrc_hz Member Eric RCOrganization: www.genband.comProject: No project yet ✭✭✭
    One more comment about adapter name and adapter id:)

    Currently if we want to register an ObjectAdapter to IceGrid, we have to config XXX.AdapterId or XXX.ReplicaGroupId (XXX is the adapter name). I think it would be better if adapter name can be the default adapter id when XXX.AdapterId and XXX.ReplicaGroupId are missing.
  • michimichi Member Michi HenningOrganization: Triodia TechnologiesProject: I have a passing interest in Ice :-) ✭✭✭
    We can't do this because the AdapterId property controls whether the server attempts to register itself with IceGrid. (See my article Teach Yourself IceGrid in 10 Minutes in Issue 19 of Connections.) If we were to default AdapterId to the adapter name, all servers would attempt to register with IceGrid (provided that Ice.Default.Locator is set). But that would be incorrect for a server thats acts as a client and uses indirect binding for the objects it contacts: dynamic registration may not be wanted for that server.

    Cheers,

    Michi.
  • rc_hzrc_hz Member Eric RCOrganization: www.genband.comProject: No project yet ✭✭✭
    Thanks, Michi. I understand you. I think this is a design question. However, using another name(XXX.AdapterId=...) to control whether to register with IceGrid maybe not the best way:)
  • benoitbenoit Rennes, FranceAdministrators, ZeroC Staff Benoit FoucherOrganization: ZeroC, Inc.Project: Ice ZeroC Staff
    Also, using the adapter name for the adapter ID isn't a good idea because it's not unique (if you deploy the same instance of a server several times for example.)

    Cheers,
    Benoit.
  • rc_hzrc_hz Member Eric RCOrganization: www.genband.comProject: No project yet ✭✭✭
    Frankly, I think all adapters should be inherently replica-able. That is, every object adapter name can be seen as a ReplicaGroupId(It also means that both XXX.AdapterId and XXX.ReplicaGroupId can be missing). So if you deploy the same instance of a server several times, they are just a replica group.
  • benoitbenoit Rennes, FranceAdministrators, ZeroC Staff Benoit FoucherOrganization: ZeroC, Inc.Project: Ice ZeroC Staff
    Sorry but this wouldn't work. You need a unique identifier to identify each replicated object adapter, which value would you use if you don't set the AdapterId? In general, you can't use a UUID because it would be different each time the server is restarted...

    If you don't want to explicitly configure the AdapterId and ReplicaGroupId properties for your servers, why don't you set them programmatically to values that suite your needs before creating the object adapter?

    Cheers,
    Benoit.
  • joshmoorejoshmoore GermanyMember Josh MooreOrganization: Glencoe Software, Inc.Project: OME, http://openmicroscopy.org
    Picking up on a somewhat old thread, it still seems like there would be uses for a name space which would be usable from the command-line, even if not so for adapters:
      ./myapp --IceUser.password=...
      ./myapp --IceCustom.host=...
      # etc
    

    in which the "IceUser", "IceCustom", or whatever would possibly get stripped and the rest passed to the properties for use by the client developer, which would be even more useful with something like:

    http://www.zeroc.com/forums/comments/3774-minor-rfe-property-expansion.html

    Just a thought.

    Cheers,
    ~Josh.
  • michimichi Member Michi HenningOrganization: Triodia TechnologiesProject: I have a passing interest in Ice :-) ✭✭✭
    You can do this already. See "Parsing Properties" in the Properties chapter of the manual.

    Cheers,

    Michi.
  • joshmoorejoshmoore GermanyMember Josh MooreOrganization: Glencoe Software, Inc.Project: OME, http://openmicroscopy.org
    For reference.
        // Create an empty property set.
        //
        Ice::PropertiesPtr props = Ice::createProperties();
    
        // Convert argc/argv to a string sequence.
        //
        Ice::StringSeq args = Ice::argsToStringSeq(argc, argv);
    
        // Strip out all options beginning with &#8209;&#8209;Filesystem.
        //
        args = props&#8209;>parseCommandLineOptions("Filesystem", args);
    
        // args now contains only those options that were not
        // stripped. Any options beginning with &#8209;&#8209;Filesystem have
        // been converted to properties.
    

    Wonderful. Thanks, Michi.
    ~J.
Sign In or Register to comment.