Archived

This forum has been archived. Please start a new discussion on GitHub.

Setting a default configuration file

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

  • Try the following:
    Ice::InitializationData initdata;
    initdata.properties = Ice::createProperties(argc, argv);
    initdata.properties->load("Foo.conf");
    
    ice = Ice::initialize(initdata);
    
  • mes
    mes California
    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
  • 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"
    
  • bernard
    bernard Jupiter, FL
    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
  • Great! This seems to be more appropriate.
  • 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.
  • 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.
  • 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:)
  • benoit
    benoit Rennes, France
    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.
  • 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.
  • benoit
    benoit Rennes, France
    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.
  • 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.
  • You can do this already. See "Parsing Properties" in the Properties chapter of the manual.

    Cheers,

    Michi.
  • 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.