Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Make (some) Ice properties opt-in (C++ only) #2983

Merged
merged 15 commits into from
Oct 30, 2024

Conversation

externl
Copy link
Member

@externl externl commented Oct 28, 2024

This PR updates the generated PropertyNames to indicate if a property array belongs to a service. Properties which belong to a service can now no longer be set unless the corresponding Property object is constructed to enable the service's prefix.

I've also renamed UnknownPropertyException to PropertyException so we can use it for a few more things.

See #2855

@externl externl changed the title 2855 limit property scope Add service properties in C++ Oct 28, 2024
* A node is the main DataStorm object. It is required to construct topics. The constructor initializes
* the Ice communicator using the given arguments. If the communicator creation fails, an Ice exception is
* raised.
* A node is the main DataStorm object. It is required to construct topics. The node uses the given Ice
Copy link
Member Author

@externl externl Oct 28, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We needed to be able to intercept the construction of the Node's communicator to create a Property set with the "DataStorm" service prefix. So we can no longer just forward everything. @bernardnormier suggested we just offer a few constructors. This also means we can now always have the custom executor as a trailing parameter.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The alternative is to not consider DataStorm a service, which is not really one. It is a user library given that you have to programmatically construct the node.

In theory any servers communicator can be shared with the node and pass to its constructor.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd prefer making DataStorm an opt-in reserved prefix, as opposed to allowing it all the time like the plugins.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Isn't this the same as IceDiscovery and IceLocatorDiscovery which are marked with service-prefix=false.?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

All the plugins (IceDiscovery etc.) are treated like Ice - always enabled.

Comment on lines +861 to +862
// Inherit all except IceBox. and Ice.Admin. properties
if (p.first.find("IceBox.") != 0 && p.first.find("Ice.Admin.") != 0)
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We now also filter out IceBox. properties.

@externl externl requested review from pepone and bernardnormier and removed request for pepone October 29, 2024 12:41
@externl externl marked this pull request as ready for review October 29, 2024 13:30
Comment on lines 324 to 326
if (propertyArray->isServicePrefix &&
(_servicePrefix != propertyArray->name && propertyArray->name != string{"IceStorm"}))
{
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can't we have multiple servicePrefixes, instead of hardcoding IceStorm here?

Copy link
Member Author

@externl externl Oct 29, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Right now we only need one. And this hardcoding of IceStorm will go away one we remove it as an IceBox service.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ins't it also required for IceStorm instance run by IceGrid?

Copy link
Member Author

@externl externl Oct 29, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

IceGrid doesn't set any IceStorm properties AFAICT.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm going to update to a list.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've updated to take list and removed the hard-coded "IceStorm".

* A node is the main DataStorm object. It is required to construct topics. The constructor initializes
* the Ice communicator using the given arguments. If the communicator creation fails, an Ice exception is
* raised.
* A node is the main DataStorm object. It is required to construct topics. The node uses the given Ice
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The alternative is to not consider DataStorm a service, which is not really one. It is a user library given that you have to programmatically construct the node.

In theory any servers communicator can be shared with the node and pass to its constructor.

/**
* Construct a DataStorm node.
*
* A node is the main DataStorm object. It is required to construct topics. The node uses the given Ice
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This constructor (like most Node constructors) does not accept a communicator. So:

The node uses the given Ice communicator.

is not correct.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fixed.

@@ -133,7 +201,10 @@ namespace DataStorm
Ice::ConnectionPtr getSessionConnection(const std::string& ident) const noexcept;

private:
void init(const Ice::CommunicatorPtr&, std::function<void(std::function<void()> call)> customExecutor);
Node(
const Ice::CommunicatorPtr&,
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should be an Ice::CommunicatorPtr.

* A node is the main DataStorm object. It is required to construct topics. The constructor initializes
* the Ice communicator using the given arguments. If the communicator creation fails, an Ice exception is
* raised.
* A node is the main DataStorm object. It is required to construct topics. The node uses the given Ice
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd prefer making DataStorm an opt-in reserved prefix, as opposed to allowing it all the time like the plugins.

@externl externl changed the title Add service properties in C++ Make (some) Ice properties opt-in (C++ only) Oct 29, 2024
Ice::InitializationData initData;
initData.properties = properties;

return Ice::initialize(argc, argv, initData);
Copy link
Member

@pepone pepone Oct 29, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can't we instead add an extra opt-in prefixes to Ice::initialize, and use that?

Copy link
Member Author

@externl externl Oct 29, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If I understand correctly, you're thinking an extra overload of args, argv, optInPrefixes?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We already have too many initialize.

The opt-in prefixes are primarily for services that we write. It will be extremely rare for a user to opt-in "IceStorm" or "DataStorm". So I'd rather not provide a more overloads to make this more convenient.

cpp/include/Ice/Properties.h Outdated Show resolved Hide resolved
@externl externl merged commit 6499167 into zeroc-ice:main Oct 30, 2024
17 checks passed
InsertCreativityHere pushed a commit to InsertCreativityHere/compiler-comparison that referenced this pull request Jan 1, 2025
…+ only) (zeroc-ice/ice#2983)

Updates the generated PropertyNames to indicate if a property array is opt-in. Properties whose prefix is opt-in can now no longer be set unless the corresponding Property object is constructed with an opt-in list containing its prefix.

I've also renamed UnknownPropertyException to PropertyException so we can use it for a few more things.

Part of zeroc-ice/ice#2855
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants