I have a need where I would like to get access to data provided via GEOSERVER_NODE_OPTS but in a module that doesn’t depend on the UI modules. Currently it looks like all the infrastructure for parsing and representing the parameter lives in the web modules. While I could just add a dependency on web-core I was thinking it potentially made sense to move some of that stuff info main.
What I am thinking is this:
Introduce an interface named something like GeoServerNodeData that would be the “data object” for the properties stored in the node opts parameter. It would also come with a default implementation that does all the non-UI bits of what DefaultGeoServerNodeInfo does now.
Update GeoServerNodeInfo adding an accessor to get at the “node data”. Something like:
Does that make sense? If folks are ok with the idea I’ll whip up a patch. I am happy to do a proposal as well but I think the changes for this one should be pretty minimal and non-distruptive.
I have a need where I would like to get access to data provided via GEOSERVER_NODE_OPTS but in a module that doesn’t depend on the UI modules. Currently it looks like all the infrastructure for parsing and representing the parameter lives in the web modules. While I could just add a dependency on web-core I was thinking it potentially made sense to move some of that stuff info main.
What I am thinking is this:
Introduce an interface named something like GeoServerNodeData that would be the “data object” for the properties stored in the node opts parameter. It would also come with a default implementation that does all the non-UI bits of what DefaultGeoServerNodeInfo does now.
Update GeoServerNodeInfo adding an accessor to get at the “node data”. Something like:
Does that make sense? If folks are ok with the idea I’ll whip up a patch. I am happy to do a proposal as well but I think the changes for this one should be pretty minimal and non-distruptive.
I have a need where I would like to get access to data provided via GEOSERVER_NODE_OPTS but in a module that doesn’t depend on the UI modules. Currently it looks like all the infrastructure for parsing and representing the parameter lives in the web modules. While I could just add a dependency on web-core I was thinking it potentially made sense to move some of that stuff info main.
What I am thinking is this:
Introduce an interface named something like GeoServerNodeData that would be the “data object” for the properties stored in the node opts parameter. It would also come with a default implementation that does all the non-UI bits of what DefaultGeoServerNodeInfo does now.
Update GeoServerNodeInfo adding an accessor to get at the “node data”. Something like:
Does that make sense? If folks are ok with the idea I’ll whip up a patch. I am happy to do a proposal as well but I think the changes for this one should be pretty minimal and non-distruptive.
I have a need where I would like to get access to data provided via GEOSERVER_NODE_OPTS but in a module that doesn’t depend on the UI modules. Currently it looks like all the infrastructure for parsing and representing the parameter lives in the web modules. While I could just add a dependency on web-core I was thinking it potentially made sense to move some of that stuff info main.
What I am thinking is this:
Introduce an interface named something like GeoServerNodeData that would be the “data object” for the properties stored in the node opts parameter. It would also come with a default implementation that does all the non-UI bits of what DefaultGeoServerNodeInfo does now.
Update GeoServerNodeInfo adding an accessor to get at the “node data”. Something like:
Does that make sense? If folks are ok with the idea I’ll whip up a patch. I am happy to do a proposal as well but I think the changes for this one should be pretty minimal and non-distruptive.
I have a need where I would like to get access to data provided via GEOSERVER_NODE_OPTS but in a module that doesn’t depend on the UI modules. Currently it looks like all the infrastructure for parsing and representing the parameter lives in the web modules. While I could just add a dependency on web-core I was thinking it potentially made sense to move some of that stuff info main.
What I am thinking is this:
Introduce an interface named something like GeoServerNodeData that would be the “data object” for the properties stored in the node opts parameter. It would also come with a default implementation that does all the non-UI bits of what DefaultGeoServerNodeInfo does now.
Update GeoServerNodeInfo adding an accessor to get at the “node data”. Something like:
Does that make sense? If folks are ok with the idea I’ll whip up a patch. I am happy to do a proposal as well but I think the changes for this one should be pretty minimal and non-distruptive.
