Re: apache ignite contribution
Hi Vladimir, Welcome to the Apache Ignite community. Is it your JIRA username? Sincerely, Dmitriy Pavlov пт, 5 июл. 2019 г. в 16:10, Владимир Белов-Федоров < belovfedorov.vladi...@gmail.com>: > Hi devs, > > My name is Vladimir Belov-Fedorov. > Please register me as Apache Ignite contributor. > > Thank you! >
Re: Migration to JUnit 5
Ivan, thank you for clarification.
If nobody is against I can uncomment them in the context of IGNITE-711.
пт, 5 июл. 2019 г. в 11:33, Павлухин Иван :
> Ivan,
>
> I think that it is a really good that you found those not tested
> examples. Thank you!
>
> пт, 5 июл. 2019 г. в 11:31, Павлухин Иван :
> >
> > Ivan,
> >
> > I uncommented all tests referring to IGNITE-711 [1] in
> > BasicExamplesSelfTest and all they passed.
> >
> > Generally, example tests are needed to be sure that our examples
> > launch. And commented tests refer to existing examples. So, an ideal
> > way here is to uncomment them in scope of IGNITE-711 [1], removal is
> > not a good option. And I do not expect much problems here because we
> > fully support Java 8 for a long time.
> >
> > [1] https://issues.apache.org/jira/browse/IGNITE-711
> >
> > пн, 1 июл. 2019 г. в 17:10, Ivan Fedotov :
> > >
> > > Hi, Igniters
> > >
> > > During work on IEP-30, which is about JUnit migration, I found that
> some
> > > tests in examples module were commented [1] with the remark, that they
> > > should be fixed in the ticket IGNITE-711 [2] which is about the
> > > implementation of Java 8 examples.
> > >
> > > In the context of the ticket IGNITE-10973 [3] I want to uncomment them
> and
> > > mark as @Disabled. Is it really need to disable mentioned tests or I
> can
> > > just remove them as outdated?
> > >
> > > [1]
> > >
> https://github.com/apache/ignite/pull/6606/files#diff-ed48193d25d777a2c30c187fa20a1a65L65
> > > [2] https://issues.apache.org/jira/browse/IGNITE-711
> > > [3] https://issues.apache.org/jira/browse/IGNITE-10973
> > >
> > >
> > > вт, 26 февр. 2019 г. в 18:51, Ivan Fedotov :
> > >
> > > > Ivan,
> > > > I will investigate GridAbstractTest refactoring issue more precisely
> when
> > > > I finish with JUnit3Legacy classes. Anyway, I will keep in touch
> with you
> > > > and the community on the most significant moments.
> > > >
> > > > JUnit5 docs say that functionality is not full "especially with
> regard to
> > > > reporting". On the other hand, I also agree with docs that it is the
> > > > easiest way that does not require to touch CI infrastructure. I am
> going to
> > > > try @RunWith(JUnitPlatform.class) construction with features from
> IEP to
> > > > make sure that we will have the full support of them. The
> alternative way
> > > > is dynamic tests [1], but the problem is that we add methods to
> suites
> > > > manually, not via @Test annotation. It is some kind of rollback to
> JUnit3
> > > > syntax.
> > > >
> > > > Anton,
> > > > thank you for the reminder, I will update IEP according to the
> > > > conversation.
> > > >
> > > > [1] https://www.baeldung.com/junit5-dynamic-tests
> > > >
> > > > вт, 26 февр. 2019 г. в 17:56, Anton Vinogradov :
> > > >
> > > >> Folks,
> > > >>
> > > >> Please make sure you keep IEP updated and each issue mentioned.
> > > >>
> > > >> On Tue, Feb 26, 2019 at 4:28 PM Павлухин Иван
> > > >> wrote:
> > > >>
> > > >> > Ivan,
> > > >> >
> > > >> > Thank you for detailed answers! I would put a great care to
> > > >> > @RunWith(JUnitPlatform.class) construction. As stated in junit5
> docs
> > > >> > [1] it does not support all features and unfortunately it is not
> clear
> > > >> > how limited it is. Also, it is some kind of transitional mechanism
> > > >> > which was not designed for being a long term solution.
> > > >> >
> > > >> > And I fully support an idea of refactoring GridAbstractTest. I
> think
> > > >> > it is possible to make a significant improvement here.
> > > >> >
> > > >> > [1]
> > > >> >
> > > >>
> https://junit.org/junit5/docs/current/user-guide/#running-tests-junit-platform-runner
> > > >> >
> > > >> > пн, 25 февр. 2019 г. в 17:41, Ivan Fedotov :
> > > >> > >
> > > >> > > Hello Nikolay.
> > > >> > >
> > > >> > > The prime benefits are more comfortable work with flaky tests,
> Java 8
> > > >> > tests
> > > >> > > compatibility, user-friendly syntaxis in parametrized tests and
> > > >> others.
> > > >> > > The most significant features list you can find in IEP-30
> Motivation
> > > >> > > section.
> > > >> > >
> > > >> > > If you have any specific questions about JUnit5 feel free to
> ask me.
> > > >> > >
> > > >> > > пн, 25 февр. 2019 г. в 16:55, Nikolay Izhikov <
> nizhi...@apache.org>:
> > > >> > >
> > > >> > > > Hello, Ivan.
> > > >> > > >
> > > >> > > > May be I miss some mail - if yes, can you repeat it.
> > > >> > > > What is advantages of migration from junit 4 to 5?
> > > >> > > > Why we should do it?
> > > >> > > >
> > > >> > > >
> > > >> > > > пн, 25 февр. 2019 г. в 16:33, Ivan Fedotov <
> ivanan...@gmail.com>:
> > > >> > > >
> > > >> > > > > Ivan,
> > > >> > > > > That is my thoughts according to your questions.
> > > >> > > > >
> > > >> > > > > 1. I tried to implement test suits with JUnit4 compatibility
> > > >> layer.
> > > >> > The
> > > >> > > > > basic concept is to use @RunWith(JUnitPlatform.class)
> > > >> @SelectClasses
> > > >> > > > > ({...})[1] and on
> > > >> >
apache ignite contribution
Hi devs, My name is Vladimir Belov-Fedorov. Please register me as Apache Ignite contributor. Thank you!
Re: [DISCUSSION][IEP-35] Metrics configuration
Igniters, One more question on topic. Should we preserve metrics configuration on restart? (I think we should) If so, which configuration use after restart? Defined in config file or saved in config storage? (I guess, saved configuration should have a priority) So, how to tell users that any changes in configuration file have no effect on Ignite configuration after first start? I think there are too many open questions and (at least at now) we should provide only JMX API until all of the questions are clarified. Regards, Igor > 4 июля 2019 г., в 19:55, Nikolay Izhikov написал(а): > > Hello, Andrey. > >> 3. I can't imagine that adequate values will be chosen on project >> setup stage. > > Configuration file required in the case we adds new node or replace existing > to the cluster. > Use can have parameters similar to Ignite configuration, log configuration > files. > >> My proposal is adding API for boundaries configuration to the metrics >> framework and expose it via JMX > > Agree. I think we should have both: > > 1. Configuration file. > 2. JMX API to change bounaries of histogram *and HitRateMetric params*. > > But, if you and other community member are against config file, let's have > only JMX. > Seems, JMX will provide required level of configurability for metrics. > > > В Чт, 04/07/2019 в 17:53 +0300, Andrey Gura пишет: >> Igniters, >> >> I rethought the issue and I see some problems: >> >> 1. It seems that in most cases bucket boundaries configuration will be >> problem for user. Absolute values for latency boundaries it is very >> odd choice. >> 2. Also seems that latency for most caches (if we configure cache >> metrics fro example) will be similar. >> 3. I can't imagine that adequate values will be chosen on project >> setup stage. So chosen values should be changed in the future. >> >> Solution with configuration file looks unnatural and creates more >> problems than could solve. >> >> My proposal is adding API for boundaries configuration to the metrics >> framework and expose it via JMX (at this step). It still provides >> configuration possibility but don't force user to do it. >> >> Also we should chose default values for bucket boundaries. And it is >> most complex problem at the moment :) Let's discuss it. >> >> >> >> >> >> On Wed, Jul 3, 2019 at 4:49 PM Andrey Gura wrote: >>> >>> Nikolai, >>> >>> Metric is disabled if it doesn't allocate any memory and doesn't >>> update any variable because doesn't have any value. Ideally disabling >>> metrics for some cache should be equal to cache stopping. >>> >>> On Fri, Jun 28, 2019 at 1:02 PM Nikolay Izhikov wrote: Hello, Alexey. Thanks for the feedback! > My only concert is that we should have the metrics framework configuration > as the first-citizen of the framework itself Yes. I planned to add `void configure(String param)` method to the metric API. > but change the metrics parameters in > runtime from JMX or command-line, etc. I've add requirement of JMX method to the ticket: https://issues.apache.org/jira/browse/IGNITE-11927 > Another concern is to have an > ability to disable/enable metrics per metrics group/prefix. Yes, we discusss it. But, let's make it clear: *What is disabling metric?* Looks like exporter filter solve this task. В Чт, 27/06/2019 в 16:24 +0300, Alexey Goncharuk пишет: > Nikolay, > > My only concert is that we should have the metrics framework configuration > as the first-citizen of the framework itself. This way, we can configure > the metrics not only from file, but change the metrics parameters in > runtime from JMX or command-line, etc. Another concern is to have an > ability to disable/enable metrics per metrics group/prefix. > > The logger-like configuration meets these suggestions given that the > configuration is generalized into the metrics framework. > > What do you think? > > чт, 27 июн. 2019 г. в 12:30, Nikolay Izhikov : > >> Hello, Igniters. >> >> As you may know, I've contributed Phase1 [1] for IEP-35 [2]. >> Now we have metrics subsystem and can create and export any metrics from >> Ignite. >> >> I think user(administrator of Ignite) should be able to configure some >> metrics params in a common way [3] >> >> I propose to use the same way from logging frameworks. >> We should define some file format Ignite can understand. >> An administrator fills configuration file to configure one or several >> metrics. >> Ignite will analyze the file and use provided params during metrics >> creation. >> >> For now, we have 2 types of metrics that should be configured: >> >>* HistrogramMetric [4] >>This metric is a count of measurement that falls into
Re: Migration to JUnit 5
Ivan,
I think that it is a really good that you found those not tested
examples. Thank you!
пт, 5 июл. 2019 г. в 11:31, Павлухин Иван :
>
> Ivan,
>
> I uncommented all tests referring to IGNITE-711 [1] in
> BasicExamplesSelfTest and all they passed.
>
> Generally, example tests are needed to be sure that our examples
> launch. And commented tests refer to existing examples. So, an ideal
> way here is to uncomment them in scope of IGNITE-711 [1], removal is
> not a good option. And I do not expect much problems here because we
> fully support Java 8 for a long time.
>
> [1] https://issues.apache.org/jira/browse/IGNITE-711
>
> пн, 1 июл. 2019 г. в 17:10, Ivan Fedotov :
> >
> > Hi, Igniters
> >
> > During work on IEP-30, which is about JUnit migration, I found that some
> > tests in examples module were commented [1] with the remark, that they
> > should be fixed in the ticket IGNITE-711 [2] which is about the
> > implementation of Java 8 examples.
> >
> > In the context of the ticket IGNITE-10973 [3] I want to uncomment them and
> > mark as @Disabled. Is it really need to disable mentioned tests or I can
> > just remove them as outdated?
> >
> > [1]
> > https://github.com/apache/ignite/pull/6606/files#diff-ed48193d25d777a2c30c187fa20a1a65L65
> > [2] https://issues.apache.org/jira/browse/IGNITE-711
> > [3] https://issues.apache.org/jira/browse/IGNITE-10973
> >
> >
> > вт, 26 февр. 2019 г. в 18:51, Ivan Fedotov :
> >
> > > Ivan,
> > > I will investigate GridAbstractTest refactoring issue more precisely when
> > > I finish with JUnit3Legacy classes. Anyway, I will keep in touch with you
> > > and the community on the most significant moments.
> > >
> > > JUnit5 docs say that functionality is not full "especially with regard to
> > > reporting". On the other hand, I also agree with docs that it is the
> > > easiest way that does not require to touch CI infrastructure. I am going
> > > to
> > > try @RunWith(JUnitPlatform.class) construction with features from IEP to
> > > make sure that we will have the full support of them. The alternative way
> > > is dynamic tests [1], but the problem is that we add methods to suites
> > > manually, not via @Test annotation. It is some kind of rollback to JUnit3
> > > syntax.
> > >
> > > Anton,
> > > thank you for the reminder, I will update IEP according to the
> > > conversation.
> > >
> > > [1] https://www.baeldung.com/junit5-dynamic-tests
> > >
> > > вт, 26 февр. 2019 г. в 17:56, Anton Vinogradov :
> > >
> > >> Folks,
> > >>
> > >> Please make sure you keep IEP updated and each issue mentioned.
> > >>
> > >> On Tue, Feb 26, 2019 at 4:28 PM Павлухин Иван
> > >> wrote:
> > >>
> > >> > Ivan,
> > >> >
> > >> > Thank you for detailed answers! I would put a great care to
> > >> > @RunWith(JUnitPlatform.class) construction. As stated in junit5 docs
> > >> > [1] it does not support all features and unfortunately it is not clear
> > >> > how limited it is. Also, it is some kind of transitional mechanism
> > >> > which was not designed for being a long term solution.
> > >> >
> > >> > And I fully support an idea of refactoring GridAbstractTest. I think
> > >> > it is possible to make a significant improvement here.
> > >> >
> > >> > [1]
> > >> >
> > >> https://junit.org/junit5/docs/current/user-guide/#running-tests-junit-platform-runner
> > >> >
> > >> > пн, 25 февр. 2019 г. в 17:41, Ivan Fedotov :
> > >> > >
> > >> > > Hello Nikolay.
> > >> > >
> > >> > > The prime benefits are more comfortable work with flaky tests, Java 8
> > >> > tests
> > >> > > compatibility, user-friendly syntaxis in parametrized tests and
> > >> others.
> > >> > > The most significant features list you can find in IEP-30 Motivation
> > >> > > section.
> > >> > >
> > >> > > If you have any specific questions about JUnit5 feel free to ask me.
> > >> > >
> > >> > > пн, 25 февр. 2019 г. в 16:55, Nikolay Izhikov :
> > >> > >
> > >> > > > Hello, Ivan.
> > >> > > >
> > >> > > > May be I miss some mail - if yes, can you repeat it.
> > >> > > > What is advantages of migration from junit 4 to 5?
> > >> > > > Why we should do it?
> > >> > > >
> > >> > > >
> > >> > > > пн, 25 февр. 2019 г. в 16:33, Ivan Fedotov :
> > >> > > >
> > >> > > > > Ivan,
> > >> > > > > That is my thoughts according to your questions.
> > >> > > > >
> > >> > > > > 1. I tried to implement test suits with JUnit4 compatibility
> > >> layer.
> > >> > The
> > >> > > > > basic concept is to use @RunWith(JUnitPlatform.class)
> > >> @SelectClasses
> > >> > > > > ({...})[1] and on
> > >> > > > > CI Ignite it works fine.
> > >> > > > >
> > >> > > > > 2. According to @Rules, there are several ways to solve it:
> > >> > > > > 2.1 Leave JUnit4 code without changes. It will work because
> > >> > > > > of
> > >> > > > Vintage
> > >> > > > > module
> > >> > > > > 2.2 Rewrite the @Rule as an Extension. The work of extension
> > >> is
> > >> > > > similar
> > >> > > > > to the @Rules work, but it is extracted in an Extension class.
> > >> > > > >
Re: Migration to JUnit 5
Ivan,
I uncommented all tests referring to IGNITE-711 [1] in
BasicExamplesSelfTest and all they passed.
Generally, example tests are needed to be sure that our examples
launch. And commented tests refer to existing examples. So, an ideal
way here is to uncomment them in scope of IGNITE-711 [1], removal is
not a good option. And I do not expect much problems here because we
fully support Java 8 for a long time.
[1] https://issues.apache.org/jira/browse/IGNITE-711
пн, 1 июл. 2019 г. в 17:10, Ivan Fedotov :
>
> Hi, Igniters
>
> During work on IEP-30, which is about JUnit migration, I found that some
> tests in examples module were commented [1] with the remark, that they
> should be fixed in the ticket IGNITE-711 [2] which is about the
> implementation of Java 8 examples.
>
> In the context of the ticket IGNITE-10973 [3] I want to uncomment them and
> mark as @Disabled. Is it really need to disable mentioned tests or I can
> just remove them as outdated?
>
> [1]
> https://github.com/apache/ignite/pull/6606/files#diff-ed48193d25d777a2c30c187fa20a1a65L65
> [2] https://issues.apache.org/jira/browse/IGNITE-711
> [3] https://issues.apache.org/jira/browse/IGNITE-10973
>
>
> вт, 26 февр. 2019 г. в 18:51, Ivan Fedotov :
>
> > Ivan,
> > I will investigate GridAbstractTest refactoring issue more precisely when
> > I finish with JUnit3Legacy classes. Anyway, I will keep in touch with you
> > and the community on the most significant moments.
> >
> > JUnit5 docs say that functionality is not full "especially with regard to
> > reporting". On the other hand, I also agree with docs that it is the
> > easiest way that does not require to touch CI infrastructure. I am going to
> > try @RunWith(JUnitPlatform.class) construction with features from IEP to
> > make sure that we will have the full support of them. The alternative way
> > is dynamic tests [1], but the problem is that we add methods to suites
> > manually, not via @Test annotation. It is some kind of rollback to JUnit3
> > syntax.
> >
> > Anton,
> > thank you for the reminder, I will update IEP according to the
> > conversation.
> >
> > [1] https://www.baeldung.com/junit5-dynamic-tests
> >
> > вт, 26 февр. 2019 г. в 17:56, Anton Vinogradov :
> >
> >> Folks,
> >>
> >> Please make sure you keep IEP updated and each issue mentioned.
> >>
> >> On Tue, Feb 26, 2019 at 4:28 PM Павлухин Иван
> >> wrote:
> >>
> >> > Ivan,
> >> >
> >> > Thank you for detailed answers! I would put a great care to
> >> > @RunWith(JUnitPlatform.class) construction. As stated in junit5 docs
> >> > [1] it does not support all features and unfortunately it is not clear
> >> > how limited it is. Also, it is some kind of transitional mechanism
> >> > which was not designed for being a long term solution.
> >> >
> >> > And I fully support an idea of refactoring GridAbstractTest. I think
> >> > it is possible to make a significant improvement here.
> >> >
> >> > [1]
> >> >
> >> https://junit.org/junit5/docs/current/user-guide/#running-tests-junit-platform-runner
> >> >
> >> > пн, 25 февр. 2019 г. в 17:41, Ivan Fedotov :
> >> > >
> >> > > Hello Nikolay.
> >> > >
> >> > > The prime benefits are more comfortable work with flaky tests, Java 8
> >> > tests
> >> > > compatibility, user-friendly syntaxis in parametrized tests and
> >> others.
> >> > > The most significant features list you can find in IEP-30 Motivation
> >> > > section.
> >> > >
> >> > > If you have any specific questions about JUnit5 feel free to ask me.
> >> > >
> >> > > пн, 25 февр. 2019 г. в 16:55, Nikolay Izhikov :
> >> > >
> >> > > > Hello, Ivan.
> >> > > >
> >> > > > May be I miss some mail - if yes, can you repeat it.
> >> > > > What is advantages of migration from junit 4 to 5?
> >> > > > Why we should do it?
> >> > > >
> >> > > >
> >> > > > пн, 25 февр. 2019 г. в 16:33, Ivan Fedotov :
> >> > > >
> >> > > > > Ivan,
> >> > > > > That is my thoughts according to your questions.
> >> > > > >
> >> > > > > 1. I tried to implement test suits with JUnit4 compatibility
> >> layer.
> >> > The
> >> > > > > basic concept is to use @RunWith(JUnitPlatform.class)
> >> @SelectClasses
> >> > > > > ({...})[1] and on
> >> > > > > CI Ignite it works fine.
> >> > > > >
> >> > > > > 2. According to @Rules, there are several ways to solve it:
> >> > > > > 2.1 Leave JUnit4 code without changes. It will work because of
> >> > > > Vintage
> >> > > > > module
> >> > > > > 2.2 Rewrite the @Rule as an Extension. The work of extension
> >> is
> >> > > > similar
> >> > > > > to the @Rules work, but it is extracted in an Extension class.
> >> > > > > For more information about extensions, please, follow the IEP
> >> > [2].
> >> > > > > In my opinion, the easiest and the most understandable way is to
> >> > leave
> >> > > > > GridAbstractTest in current form. It will work with JUnit5
> >> > > > > syntaxis and abilities.
> >> > > > >
> >> > > > > 3. I faced a couple of problems during dealing with dynamic and
> >> > static
> >> > > > > tests in
Re: Unable to get the security context
Hi, Radha Jai!
You should update your master branch AI.
Today we don't have the SecurityContextHolder class, but we have a
guaranty, that SecurityContext argument in the authorize method will not be
null.
Good luck!
ср, 29 мая 2019 г. в 08:00, radha jai :
> Hi,
> I have implemented the grid security processor and setting the
> securityconext holder in the authenticate function as below,
>
> public class MySecurityProcessor extends GridProcessorAdapter implements
> DiscoverySpiNodeAuthenticator, GridSecurityProcessor, IgnitePlugin
> {
>
>
> public SecurityContext authenticate(AuthenticationContext
> authenticationContext) throws IgniteCheckedException
> {
>SecuritySubject secureSecuritySubject = new SecuritySubject(
> authenticationContext.subjectId(),
> authenticationContext.subjectType(),
> authenticationContext.credentials().getLogin(),
> authenticationContext.address()
> );
> SecurityContext securityContext = new
> MySecurityContext(secureSecuritySubject, accessToken);
> SecurityContextHolder.set(securityContext);
> return securityContext;
> }
> public void authorize(String name, SecurityPermission perm, SecurityContext
> securityCtx) throws SecurityException {
> System.out.println( SecurityContextHolder.get());
> System.out.println( securityCtx );
> //do some authorization
> .
> }
>
> public boolean isGlobalNodeAuthentication() {
> // TODO Auto-generated method stub
> return false;
> }
> ..
> }
> In plugin provider i am creating the component : GridSecurityProcessor.
> During Rest api call:
> -> when rest call is made authorise function in the security processor is
> getting called twice one by the GridRestProcessor and another
> GridCacheProcessor, is it mandatory to call that twice? When authorise
> function is called by the GridRestProcessor security context is available
> but when the GridCacheProcessor is called security context is coming as
> null always. Hence the security context is not available in the authorise
> function. So i used the SecurityContextHolder.get() to get the security
> context.
> But for some of the commands SecurityContextHolder.get() is not working
> like prepend and append.
>
> -> When cache create and cache destroy is made, authorise function is
> receiving the name as NULL. Why is it so? Because based on the name i am
> trying to validate wheather the user is allowed to perform this action
>
> During Sqlline access:
> -> authorise function receive the security context as NULL always . So used
> the SecurityContextHolder.get() , but still getting NULL. How do i get the
> context?
>-> While performing create table and drop table, the authorise function
> is receiving the name as NULL.
>
> One last question: when the security context is null(during rest call or
> sqlline access), can we use the local node context in the authorise
> function?
>
>
> Regards
> Radha
>
Re: Unable to get the security context
Hi radha!
Regarding your question about SecurityContext as null, you should update
your master branch. Today
ср, 29 мая 2019 г. в 08:00, radha jai :
> Hi,
> I have implemented the grid security processor and setting the
> securityconext holder in the authenticate function as below,
>
> public class MySecurityProcessor extends GridProcessorAdapter implements
> DiscoverySpiNodeAuthenticator, GridSecurityProcessor, IgnitePlugin
> {
>
>
> public SecurityContext authenticate(AuthenticationContext
> authenticationContext) throws IgniteCheckedException
> {
>SecuritySubject secureSecuritySubject = new SecuritySubject(
> authenticationContext.subjectId(),
> authenticationContext.subjectType(),
> authenticationContext.credentials().getLogin(),
> authenticationContext.address()
> );
> SecurityContext securityContext = new
> MySecurityContext(secureSecuritySubject, accessToken);
> SecurityContextHolder.set(securityContext);
> return securityContext;
> }
> public void authorize(String name, SecurityPermission perm, SecurityContext
> securityCtx) throws SecurityException {
> System.out.println( SecurityContextHolder.get());
> System.out.println( securityCtx );
> //do some authorization
> .
> }
>
> public boolean isGlobalNodeAuthentication() {
> // TODO Auto-generated method stub
> return false;
> }
> ..
> }
> In plugin provider i am creating the component : GridSecurityProcessor.
> During Rest api call:
> -> when rest call is made authorise function in the security processor is
> getting called twice one by the GridRestProcessor and another
> GridCacheProcessor, is it mandatory to call that twice? When authorise
> function is called by the GridRestProcessor security context is available
> but when the GridCacheProcessor is called security context is coming as
> null always. Hence the security context is not available in the authorise
> function. So i used the SecurityContextHolder.get() to get the security
> context.
> But for some of the commands SecurityContextHolder.get() is not working
> like prepend and append.
>
> -> When cache create and cache destroy is made, authorise function is
> receiving the name as NULL. Why is it so? Because based on the name i am
> trying to validate wheather the user is allowed to perform this action
>
> During Sqlline access:
> -> authorise function receive the security context as NULL always . So used
> the SecurityContextHolder.get() , but still getting NULL. How do i get the
> context?
>-> While performing create table and drop table, the authorise function
> is receiving the name as NULL.
>
> One last question: when the security context is null(during rest call or
> sqlline access), can we use the local node context in the authorise
> function?
>
>
> Regards
> Radha
>
