You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@struts.apache.org by Greg Huber <gr...@gmail.com> on 2020/12/01 08:01:51 UTC

Re: java 11 error

AbstractLocalizedTextProvider


clearMap(ResourceBundle.class, null, "cacheList");

private void clearMap(Class cl, Object obj, String name)
             throws NoSuchFieldException, IllegalAccessException, 
NoSuchMethodException, InvocationTargetException {

         Field field = cl.getDeclaredField(name);
         field.setAccessible(true);

         Object cache = field.get(obj);

         synchronized (cache) {
             Class ccl = cache.getClass();
             Method clearMethod = ccl.getMethod("clear");
             clearMethod.invoke(cache);
         }
     }


When it executes the line

field.setAccessible(true);

is when it generates the warning

WARNING: An illegal reflective access operation has occurred
WARNING: Illegal reflective access by 
com.opensymphony.xwork2.util.AbstractLocalizedTextProvider 
(file:/home/ghuber/git/events/events/src/main/webapp/WEB-INF/classes/) 
to field java.util.ResourceBundle.cacheList
WARNING: Please consider reporting this to the maintainers of 
com.opensymphony.xwork2.util.AbstractLocalizedTextProvider
WARNING: Use --illegal-access=warn to enable warnings of further illegal 
reflective access operations
WARNING: All illegal access operations will be denied in a future release

On 30/11/2020 17:28, Yasser Zamani wrote:
> I remember we fixed similar issues but against ognl
> (https://issues.apache.org/jira/browse/WW-5031)
>
> I think this is a new one about `clearMap(ResourceBundle.class, null,
> "cacheList");` inside "AbstractLocalizedTextProvider" (as error message
> also mentions).
>
> Maybe it's a good idea to set `--illegal-access=deny` on our java 11
> build to discover similar issues earlier.
>
> Regards.
>
> On 11/30/2020 5:22 PM, Greg Huber wrote:
>> I had used
>>
>> <url>https://repository.apache.org/content/groups/snapshots/</url>
>>
>> <org.apache.struts.version>2.6-SNAPSHOT</org.apache.struts.version>
>>
>>
>> in my ~.m2/repository/org/apache/struts/struts2-core/2.6-SNAPSHOT there
>> are two jars both with the same internal date 11 July
>>
>>
>> struts2-core-2.6-20201128.103017-363.jar
>>
>> struts2-core-2.6-SNAPSHOT.jar
>>
>>
>> On 30/11/2020 13:32, Lukasz Lenart wrote:
>>> pon., 30 lis 2020 o 14:30 Greg Huber <gr...@gmail.com> napisał(a):
>>>> Seems still to be there,
>>>>
>>>> https://repository.apache.org/content/groups/snapshots/
>>>>
>>>> the date of the jar is July 2020.
>>> Hm... November 28
>>> https://repository.apache.org/content/groups/snapshots/org/apache/struts/struts2-core/2.6-SNAPSHOT/
>>>
>>>
>>>
>>> Regards
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>> For additional commands, e-mail: dev-help@struts.apache.org
>>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org


Re: java 11 error

Posted by Greg Huber <gr...@gmail.com>.
Sorry, retesting, its not tomcat, as it seems to work if I comment out 
the clearTomcatCache() method, its the  clearMap in reloadBundles()

reloadBundles(Map<String, Object> context) {

..

try {
                         clearMap(ResourceBundle.class, null, "cacheList");
                     } catch (NoSuchFieldException e) {
                         // happens in IBM JVM, that has a different 
ResourceBundle impl
                         // it has a 'cache' member
                         clearMap(ResourceBundle.class, null, "cache");
                     }

..

}

On 01/12/2020 14:48, Lukasz Lenart wrote:
> wt., 1 gru 2020 o 10:49 Greg Huber <gr...@gmail.com> napisał(a):
>> yes, ...dev box testing
>>
>> Although warning is only issued once.
> So either we can ignore the issue for now or remove that code - it
> won't work either as this requires to build and copy new classes/files
> into Tomcat's web folder.
>
> There are some other (and better) options how to achieve the same
> https://www.mulesoft.com/tcat/tomcat-reload
>
>
> Regards

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org


Re: java 11 error

Posted by Greg Huber <gr...@gmail.com>.
I tried removing the code, and the bundles don't reload, so its not 
crusty code.  It is cumbersome to reload the context each time 
ApplicationResources.properties changes.

Maybe I will ask this on the tomcat list as there might be an 
alternative way nowadays.

On 01/12/2020 14:48, Lukasz Lenart wrote:
> wt., 1 gru 2020 o 10:49 Greg Huber <gr...@gmail.com> napisał(a):
>> yes, ...dev box testing
>>
>> Although warning is only issued once.
> So either we can ignore the issue for now or remove that code - it
> won't work either as this requires to build and copy new classes/files
> into Tomcat's web folder.
>
> There are some other (and better) options how to achieve the same
> https://www.mulesoft.com/tcat/tomcat-reload
>
>
> Regards

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org


Re: java 11 error

Posted by James Chaplin <jc...@apache.org>.
Hi.

This discussion thread has some interesting information and points raised (thanks to Greg, Lukasz and Yasser).  :)

If the old logic discussed in the thread is replaced, it might be a good idea to try out some older and newer Tomcat versions (e.g. 7.x, 8.x, 9.x), to see if things still behave as expected.

The old comments also mention special handling for certain JVM implementations.  Even though the suggestions for replacement logic appear to use standard JDK calls, maybe running the same scenario/check on different JVM flavours (e.g. OpenJDK, OpenJ9, etc.) would be beneficial ?

The suggested logic change looks promising, in any event.  :)

Regards,

     James.

On 2020/12/02 19:50:47, Lukasz Lenart <lu...@apache.org> wrote: 
> śr., 2 gru 2020 o 10:59 Greg Huber <gr...@gmail.com> napisał(a):
> >
> > Seems we might be able to replace
> >
> >   try {
> >                          clearMap(ResourceBundle.class, null, "cacheList");
> >                      } catch (NoSuchFieldException e) {
> >                          // happens in IBM JVM, that has a different
> > ResourceBundle impl
> >                          // it has a 'cache' member
> >                          clearMap(ResourceBundle.class, null, "cache");
> >                      }
> >
> > with
> >
> > ResourceBundle.clearCache();
> >
> > Initial testing seems to work, with no error, but not sure exactly what
> > its doing???
> 
> Nice :) As far as I understand it does exactly the same thing without
> a hackish approach :) Probably it would be good to iterate over the
> hierarchy of ClassLoaders and clear the cache for each. Could you
> register a ticket in JIRA for that?
> 
> /**
>  * Removes all resource bundles from the cache that have been loaded
>  * using the given class loader.
>  *
>  * @param loader the class loader
>  * @exception NullPointerException if <code>loader</code> is null
>  * @since 1.6
>  * @see ResourceBundle.Control#getTimeToLive(String,Locale)
>  */
> public static final void clearCache(ClassLoader loader) {
>     if (loader == null) {
>         throw new NullPointerException();
>     }
>     Set<CacheKey> set = cacheList.keySet();
>     for (CacheKey key : set) {
>         if (key.getLoader() == loader) {
>             set.remove(key);
>         }
>     }
> }
> 
> 
> Regards
> -- 
> Łukasz
> + 48 606 323 122 http://www.lenart.org.pl/
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
> 
> 

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org


Re: java 11 error

Posted by Lukasz Lenart <lu...@apache.org>.
śr., 2 gru 2020 o 10:59 Greg Huber <gr...@gmail.com> napisał(a):
>
> Seems we might be able to replace
>
>   try {
>                          clearMap(ResourceBundle.class, null, "cacheList");
>                      } catch (NoSuchFieldException e) {
>                          // happens in IBM JVM, that has a different
> ResourceBundle impl
>                          // it has a 'cache' member
>                          clearMap(ResourceBundle.class, null, "cache");
>                      }
>
> with
>
> ResourceBundle.clearCache();
>
> Initial testing seems to work, with no error, but not sure exactly what
> its doing???

Nice :) As far as I understand it does exactly the same thing without
a hackish approach :) Probably it would be good to iterate over the
hierarchy of ClassLoaders and clear the cache for each. Could you
register a ticket in JIRA for that?

/**
 * Removes all resource bundles from the cache that have been loaded
 * using the given class loader.
 *
 * @param loader the class loader
 * @exception NullPointerException if <code>loader</code> is null
 * @since 1.6
 * @see ResourceBundle.Control#getTimeToLive(String,Locale)
 */
public static final void clearCache(ClassLoader loader) {
    if (loader == null) {
        throw new NullPointerException();
    }
    Set<CacheKey> set = cacheList.keySet();
    for (CacheKey key : set) {
        if (key.getLoader() == loader) {
            set.remove(key);
        }
    }
}


Regards
-- 
Łukasz
+ 48 606 323 122 http://www.lenart.org.pl/

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org


Re: java 11 error

Posted by Greg Huber <gr...@gmail.com>.
Seems we might be able to replace

  try {
                         clearMap(ResourceBundle.class, null, "cacheList");
                     } catch (NoSuchFieldException e) {
                         // happens in IBM JVM, that has a different 
ResourceBundle impl
                         // it has a 'cache' member
                         clearMap(ResourceBundle.class, null, "cache");
                     }

with

ResourceBundle.clearCache();

Initial testing seems to work, with no error, but not sure exactly what 
its doing???

On 01/12/2020 14:48, Lukasz Lenart wrote:
> wt., 1 gru 2020 o 10:49 Greg Huber <gr...@gmail.com> napisał(a):
>> yes, ...dev box testing
>>
>> Although warning is only issued once.
> So either we can ignore the issue for now or remove that code - it
> won't work either as this requires to build and copy new classes/files
> into Tomcat's web folder.
>
> There are some other (and better) options how to achieve the same
> https://www.mulesoft.com/tcat/tomcat-reload
>
>
> Regards

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org


Re: java 11 error

Posted by Lukasz Lenart <lu...@apache.org>.
wt., 1 gru 2020 o 10:49 Greg Huber <gr...@gmail.com> napisał(a):
>
> yes, ...dev box testing
>
> Although warning is only issued once.

So either we can ignore the issue for now or remove that code - it
won't work either as this requires to build and copy new classes/files
into Tomcat's web folder.

There are some other (and better) options how to achieve the same
https://www.mulesoft.com/tcat/tomcat-reload


Regards
-- 
Łukasz
+ 48 606 323 122 http://www.lenart.org.pl/

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org


Re: java 11 error

Posted by Greg Huber <gr...@gmail.com>.
yes, ...dev box testing

Although warning is only issued once.

On 01/12/2020 09:22, Lukasz Lenart wrote:
> but this happens only in devMode? or when "struts.i18n.reload" is set to true?

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org


Re: java 11 error

Posted by Lukasz Lenart <lu...@apache.org>.
wt., 1 gru 2020 o 09:02 Greg Huber <gr...@gmail.com> napisał(a):
>
> AbstractLocalizedTextProvider
>
>
> clearMap(ResourceBundle.class, null, "cacheList");
>
> private void clearMap(Class cl, Object obj, String name)
>              throws NoSuchFieldException, IllegalAccessException,
> NoSuchMethodException, InvocationTargetException {
>
>          Field field = cl.getDeclaredField(name);
>          field.setAccessible(true);
>
>          Object cache = field.get(obj);
>
>          synchronized (cache) {
>              Class ccl = cache.getClass();
>              Method clearMethod = ccl.getMethod("clear");
>              clearMethod.invoke(cache);
>          }
>      }
>
>
> When it executes the line
>
> field.setAccessible(true);
>
> is when it generates the warning
>
> WARNING: An illegal reflective access operation has occurred
> WARNING: Illegal reflective access by
> com.opensymphony.xwork2.util.AbstractLocalizedTextProvider
> (file:/home/ghuber/git/events/events/src/main/webapp/WEB-INF/classes/)
> to field java.util.ResourceBundle.cacheList
> WARNING: Please consider reporting this to the maintainers of
> com.opensymphony.xwork2.util.AbstractLocalizedTextProvider
> WARNING: Use --illegal-access=warn to enable warnings of further illegal
> reflective access operations
> WARNING: All illegal access operations will be denied in a future release

but this happens only in devMode? or when "struts.i18n.reload" is set to true?


Regards
-- 
Łukasz
+ 48 606 323 122 http://www.lenart.org.pl/

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org