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

[TOMEE-2060] Make app naming context read only (switched on/off with property) #72

Closed
wants to merge 2 commits into from

Conversation

katya-stoycheva
Copy link
Contributor

Initial proposal (there are things to be clarified)

Copy link
Contributor

@rmannibucau rmannibucau left a comment

Choose a reason for hiding this comment

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

Good start, few "style" changes for the main PR (mainly to align on other properties style and ensure the change can be seen by the user if it breaks something)

Also would be great to test it, we already have some IvmContextTests so should be enriched to test all these changes. Also please add a test in tomee (you can use tomee embedded or arquillian tests module) since here the context federation behaves differently.

Once these changes are covered we can integrate it to the code source


//TODO: set proper default
//required by spec: EE.5.3.4, used together with tomcat#jndiExceptionOnFailedWrite
if("true".equals(SystemInstance.get().getProperty("forceReadOnlyAppNamingContext", "true"))) {
Copy link
Contributor

Choose a reason for hiding this comment

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

please prefix it openejb. (openejb.forceReadOnlyAppNamingContext)

also shouldnt the default be false to ensure it is writable by default (backward compatibility)

also think createApplication.success is not the right key yet ;)

} else if(ctx instanceof ContextHandler) {
((ContextHandler)ctx).setReadOnly();
} else {
//TODO: log only?
Copy link
Contributor

Choose a reason for hiding this comment

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

shouldn't be possible so can be ignored for now

if(ctx instanceof IvmContext) {
((IvmContext) ctx).setReadOnly(true);
} else if(ctx instanceof ContextHandler) {
((ContextHandler)ctx).setReadOnly();
Copy link
Contributor

Choose a reason for hiding this comment

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

side note on casting: on the list we got a discussion saying we prefer the ${type}.class.cast(instance) style instead of (($type) instance). Not a blocker for me but just mentionning it if you see that style in the code elsewhere.

checkReadOnly();
if(checkReadOnly()) {
//TODO: throw exception or return null? tomcat returns null
return null;
Copy link
Contributor

Choose a reason for hiding this comment

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

null is fine if there is a one time - 10 calls will log a single time - log line (warning?)

if (readOnly) {
throw new OperationNotSupportedException();
//alignment with tomcat behavior
if("true".equals(System.getProperty("jndiExceptionOnFailedWrite"))) {
Copy link
Contributor

Choose a reason for hiding this comment

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

SystemInstance.get().getProperty and openejb prefix as well, default should fail as before

}

public void setReadOnly(boolean isReadOnly) {
//TODO: should it log?
Copy link
Contributor

Choose a reason for hiding this comment

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

no need to log it until there is an issue with this being called (which is more in write methods)

@rmannibucau
Copy link
Contributor

applied, build in progress on https://ci.apache.org/builders/tomee-trunk-ubuntu/builds/778

@katya-stoycheva
Copy link
Contributor Author

Thank you for reviewing this. Three more questions/comments from my side:

  • Is there Tomee code convention documented somewhere? I tried to stick to the original format but obviously the IDE has applied some own preferences and I saw check-formatting step is failing.
  • About the arquillian tests - I have added a test to check only the default behavior since this is a config change and is applied on container start. (I didn't manage to change it via the test framework) How do you test different behavior that depends on a system property for example? I was thinking of adding new container for each config set but it would require specifying different mvn profile on build and someone has to invoke these which could be seen as overhead. Do I need to add more arquillian tests for read-only context?
  • About logging (on your request: if there is a one time - 10 calls will log a single time - log line (warning?)) It would need to propagate and synchronize a counter among nested contexts and it would be unnecessary overhead in my opinion. But if you think this would be hepful, I can add it.

@rmannibucau
Copy link
Contributor

  1. not that much, we are not that strong about it cause we all have different habits and thinking about it
  2. you can create a new surefire execution for this test with another arquillian container config, that said the embedded testing in openejb-core (which forks by test) should be enough probably
  3. you logged it was read only in the assembler, this is enough for now probably

@AndyGee
Copy link
Contributor

AndyGee commented Sep 18, 2017

@katya-stoycheva can you please close this - it was applied. Thank you very much for your contribution :-)

@asfgit asfgit closed this in 9bdc48b Dec 10, 2018
jgallimore pushed a commit to jgallimore/tomee that referenced this pull request Mar 4, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
3 participants