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
MODE-1791 - Added the "readonly" attribute to the connector hierarchy and implemented support for it in the base connector class #688
Closed
Closed
Changes from all commits
Commits
Show all changes
2 commits
Select commit
Hold shift + click to select a range
File filter
Filter by extension
Conversations
Failed to load comments.
Jump to
Jump to file
Failed to load files.
Diff view
Diff view
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
46 changes: 46 additions & 0 deletions
46
modeshape-jcr/src/main/java/org/modeshape/jcr/federation/spi/WritableConnector.java
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,46 @@ | ||
/* | ||
* ModeShape (http://www.modeshape.org) | ||
* See the COPYRIGHT.txt file distributed with this work for information | ||
* regarding copyright ownership. Some portions may be licensed | ||
* to Red Hat, Inc. under one or more contributor license agreements. | ||
* See the AUTHORS.txt file in the distribution for a full listing of | ||
* individual contributors. | ||
* | ||
* ModeShape is free software. Unless otherwise indicated, all code in ModeShape | ||
* is licensed to you under the terms of the GNU Lesser General Public License as | ||
* published by the Free Software Foundation; either version 2.1 of | ||
* the License, or (at your option) any later version. | ||
* | ||
* ModeShape is distributed in the hope that it will be useful, | ||
* but WITHOUT ANY WARRANTY; without even the implied warranty of | ||
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU | ||
* Lesser General Public License for more details. | ||
* | ||
* You should have received a copy of the GNU Lesser General Public | ||
* License along with this software; if not, write to the Free | ||
* Software Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA | ||
* 02110-1301 USA, or see the FSF site: http://www.fsf.org. | ||
*/ | ||
|
||
package org.modeshape.jcr.federation.spi; | ||
|
||
/** | ||
* A specialized abstract {@link Connector} class that is support both reads and writes. In addition, this class has a {@code readonly} | ||
* flag allowing clients to configure a writable connector (external source) as read-only. In this case, all of the write operations | ||
* will throw an exception. | ||
|
||
* @author Horia Chiorean (hchiorea@redhat.com) | ||
*/ | ||
public abstract class WritableConnector extends Connector { | ||
|
||
/** | ||
* A flag which indicates whether a connector allows both write & read operations, or only read operations. If a connector | ||
* is read-only, any attempt to write content (add/update/delete etc) will result in an exception being raised. | ||
*/ | ||
private boolean readonly = false; | ||
|
||
@Override | ||
public boolean isReadonly() { | ||
return readonly; | ||
} | ||
} |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I originally chose default value of "true" (meaning read-only) so that the connector was safe by default, and would not modify any of the files under the location. Because connectors are used only for federation, preventing modification seemed at the time to be a prudent and not terribly inappropriate default.
Do we not want that "safe-by-default" behavior?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm fine with the safe-by-default being true. However, if that is the case, each connector implementation that supports writes, will have to make sure to change the default value from the base class to "false", as long as it's using the checkConnectorWritable method which will throw an exception if the connector is read-only.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I guess this is the downside of making it generic - it might be difficult to decide what should be the default. And once the default has been coded in the JSON Schema and AS7 XSD, then won't all connector configurations that want to support writes have to use
readonly="false"
?The other option is to have the default for
readonly
befalse
like you have it here. Perhaps that is best, even though it's not "safest".There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
My original thought behind making it "false" as default, was that because of the existence of the ReadonlyConnector abstract class, it would be much easier for read-only connectors to be implemented,
as opposed to making sure a writable connector overrides the flag somehow.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Right. But this is dealing with writable connectors that are to be configured as read-only. I think this boils down to whether writeable connectors should be writable by default or read-only by default. I can certainly imagine that some writeable connectors (e.g., JCR) would be frequently used in a writable manner. My thinking, however, was that people configuring them should explicitly make the choice to allow ModeShape to update content in another system. I guess I'm still leaning in that direction but am by no means certain.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fair enough (I'm fine with either setting being the default)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actually, the more I think about this, the more I think we're overcomplicating things with the "read-only" flag. If a connector is writable, what are the chances/cases when a client would want it configured in "read-only" mode ? (I'm starting to doubt the usefulness of this flag I think)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I still think it's very worthwhile - I absolutely think it should be possible to prevent ModeShape from modifying content in external systems. For example, imagine a web application exposing some files on the file system but not wanting to allow any modification/changes to those files. (This is actually done on JBoss.org, though using 2.x.)
Now, I might be able to be convinced that this shouldn't be built-into all connectors, but instead built into those connectors that make sense. If that's what we want, then I would push for it to be added to the FileSystemConnector.
Perhaps we need additional feedback. I'll post to the forums.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's worth mentioning that the FS connector has/had this flag. This PR removed it and moved it upwards.
But I think you're right: the fact that we support custom properties, means that any time a connector would need such a flag, it would just add it and implement it in whatever way it sees fit. The configuration/setting mechanism would set it on the connector if present.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
See this forum thread.