During webapp startup on Weblogic, I'm getting the following warnings in my console about variables that have been deprecated. I'm not using any of these 4 variables.
There were several other warnings from properties that I did have in my Configuration File (upgrading from 1.7 to 2.3), so I updated those and no longer get the warnings about them.
But these 4 are a mystery to me.
https://velocity.apache.org/engine/2.3/configuration.html#configuration-summary-tree
org.apache.velocity.util.DeprecationAwareExtProperties warnDeprecated
WARNING: configuration key 'resource.loader' has been deprecated in
favor of 'resource.loaders'
org.apache.velocity.util.DeprecationAwareExtProperties warnDeprecated
WARNING: configuration key 'webapp.resource.loader.class' has been
deprecated in favor of 'resource.loader.webapp.class'
org.apache.velocity.util.DeprecationAwareExtProperties warnDeprecated
WARNING: configuration key 'string.resource.loader.class' has been
deprecated in favor of 'resource.loader.string.class'
org.apache.velocity.util.DeprecationAwareExtProperties warnDeprecated
WARNING: configuration key 'runtime.introspector.uberspect' has been
deprecated in favor of 'introspector.uberspect.class'
How do I get rid of these warnings considering I'm not even using these 4 properties?
The warnings do show up because the file containing the default properties for Velocity Tools View, packaged within the velocity-tools-view jar, still uses the old syntax to be compatible with older engines.
It's possible to override configure() or getProperties() in a custom VelocityView class, but maybe not worth the effort. They can safely be ignored.
Related
While building the code getting package sun.security.action is not visible
Package sun.security.action is declared on module java.base, which does not export it to the unnamed module.
What should I do.
Kindly advice, Thanks in advance
Java 8 had no module system - everything is visible or just needs to get imported by archives in jdk (f.e. tools.jar).
Java 9 brought JMS and encapsulated some jdk classes.
In your case, see <JAVA_HOME>/lib/src.zip!/java.base/module-info.class:
exports sun.security.action to
java.desktop,
java.security.jgss,
jdk.crypto.ec,
jdk.incubator.foreign;
Your package isn't public but restricted to some other internal packages/modules.
There was a workaround by adding compiler option --add-exports=java.base/sun.security.action=ALL-UNNAMED at compile time to fix this limitation until version 16.
With version 17 and JEP 403 forget all hope:
It is not a goal to define new standard APIs to replace internal elements for which standard replacements do not yet exist, though such APIs could be suggested in response to this JEP.
Backwards compatibility and important frameworks have lower priority than jdk security - JCP makes strange decisions and works against the community sometimes -.-
I get this error trying to use a github repository as a dependency using elm-install
Problem in dependency repo_name/package_name 1.0.0
The elm-package.json constraints of 'repo_name/package_name' are probably
letting too much stuff through.
What does this exactly mean?
(This answer courtesy of #ilias at Elm Slack channel)
It means that Elm couldn't compile the sources for that package in the context of your package.
Imagine for a minute I'm making a package my-fancy-package, and I have a dependency on a package foo/bar. So in my-fancy-package/elm-package.json, I could have a dependency like "foo/bar": "1.0.0 <= v < 2.0.0". Now, perhaps the most recent version of foo/bar while I'm developing my-fancy-package is 1.5.0. And in version 1.5.0, a new function was added that does exactly what I need in my-fancy-package, so I start using that function. The core issue is that there currently is no automated way to test that a package actually works with all the allowed versions of its dependencies. So now my-fancy-package says it depends on foo/bar at any version between 1.0.0 and 2.0.0, while in reality, it really needs to be at least 1.5.0 because I'm using a function from that package.
Now, imagine you're developing an application, and you're using foo/bar at version 1.2.3. According to the semver ranges of my-fancy-package, that means you should be able to use it, but if you were to actually try it, you'd receive this error: my-fancy-package is stating it is compatible with foo/bar#1.2.3 while it really needs 1.5.0.
The reason the error message doesn't simply say "it failed to compile" is because all the published packages are compiled before publishing. The most common reason for a package failing to compile in some context is that its dependencies aren't "accurate": they're letting too much stuff through.
In case of elm-install and packages from github, it's harder to say - it could actually be broken package.
Another common cause for this error is a rather silly one - conflicting definitions of infix operators. The associativity and precedence of infix ops can only be defined "globally", so if there are 2 packages that define the same infix operator, that could become a problem
Validation framework which has been rolled up as part of the JEE6 spec (WL12). Both the WL10 and WL12 versions of our application were deployed with the following open source libraries:
JSR-303 / validation-api.jar (version 1.0)
Hibernate Validator (version 4.2.0)
However, the libraries are also bundled with WL 12 (modules directory). Note that the Hibernate Validator version is slightly different.
modules.javax.validation_1.0.0.jar
hibernate.validator_4.1.0.jar
With our WL12 run we are getting below exception:
javax.validation.ValidationException: Unable to get available provider
Attempted Solutions
Our next attempt was to use the WebLogic FilteringClassLoader to prefer the libraries from our application (APP-INF/lib directory) by specifying them in the weblogic-application.xml file (i.e. choose our versions over WebLogic’s). We were already doing this for several other open source libraries in WL10:
<prefer-application-packages>
<package-name>com.google.common.*</package-name>
<package-name>org.apache.commons.lang.*</package-name>
<package-name>org.apache.commons.logging.*</package-name>
<package-name>org.apache.commons.beanutils.*</package-name>
<package-name>org.apache.commons.collections.*</package-name>
<package-name>antlr.*</package-name>
<package-name>javax.validation.*</package-name>
<package-name>org.hibernate.validator.*</package-name>
</prefer-application-packages>
After making that change, our application experienced the following run-time error trying to process any request that makes use of the validation framework:
javax.validation.ValidationException: Unable to get available provider resolvers.
at javax.validation.Validation$GenericBootstrapImpl.configure(Validation.java:259)
at web20.hibernate.validation.ValidatorFactoryConfigurator.getValidatorFactory(ValidatorFactoryConfigurator.java:39)
at web20.hibernate.validation.ValidationHandlerImpl.handleHibernateValidations(ValidationHandlerImpl.java:180)
at web20.hibernate.validation.ValidationHandlerImpl.performValidation(ValidationHandlerImpl.java:255)
at web20.hibernate.validation.ValidationHandlerImpl.validateAndFormatMessages(ValidationHandlerImpl.java:302)
at web20.hibernate.validation.ValidationHandlerImpl.validateUsingHibernateGroups(ValidationHandlerImpl.java:113)
at service.serviceapp.performValidations(serviceapp.java:392)
at service.serviceapp.performValidations(serviceapp.java:379)
at service.TransactionalServiceImpl.search(TransactionalServiceImpl.java:300)
Given that Bean Validation is part of the EE standard, I assume there is some code Bean Validation integration code which causes the problem. I see two potential solutions:
Patch the WL instance and upgrade to the Validator version you want to use
Try writing your own ValidationProvider. Internally it could just delegate to the Hibernate Validator classes. If you then add a validation.xml to your application, specifying your custom provider, WL should bootstrap this one. TBH, I don't know whether this will work. There are many unknowns and I don't know enough about the integration of WL and Bean Validation.
Personally, I think I would just try to upgrade the Validator version used in WL.
What is the recommended way to include a grails plugin for in a 2.1.0 project?
1: Add it to the application.properties?
app.grails.version=2.1.0
app.name=testapp-local
app.version=0.1
plugins.build-test-data=2.0.3
plugins.fixtures=1.1
plugins.hibernate=2.1.0
plugins.pretty-time=0.3
plugins.mail=1.0
plugins.quartz=0.4.2
plugins.spring-security-core=1.2.7.3
plugins.tomcat=2.1.0
2: Specify it in buildConfig.groovy?
plugins {
runtime ":hibernate:$grailsVersion"
runtime ":jquery:1.7.2"
runtime ":resources:1.1.6"
// Uncomment these (or add new ones) to enable additional resources capabilities
//runtime ":zipped-resources:1.0"
//runtime ":cached-resources:1.0"
//runtime ":yui-minify-resources:0.1.4"
build ":tomcat:$grailsVersion"
runtime ":database-migration:1.1"
compile ':cache:1.0.0'
}
Thanks
I would always put it in buildConfig.groovy since this allows
to define the scope of the dependency
exclude unwanted dependencies, which can save you a lot of trouble
Btw: found an interesting thread on this here, that actually treats the exact same question:
http://grails.1312388.n4.nabble.com/Plugins-application-properties-vs-BuildConfig-groovy-td4313370.html
HTH
I get errors from both build and website precompile on App Harbor that seem to originate from multiple versions of the C# dynamic assemblies. They both start with warnings that look like:
2>CSC : warning CS1685: The predefined type 'System.Runtime.CompilerServices.CallSite' is defined in multiple assemblies in the global alias; using definition from 'd:\temp\qb3ydb5o.xoq\input\packages\IronJS.Core.0.2.0.1\lib\net40\Microsoft.Scripting.Core.dll' [D:\temp\qb3ydb5o.xoq\input\...csproj]
The build passes, but website precompile has these warnings but fails:
(0): error CS0656: Missing compiler required member 'Microsoft.CSharp.RuntimeBinder.Binder.InvokeMember'
d:\temp\qb3ydb5o.xoq\output\_PublishedWebsites\...cshtml(4): error CS1969: One or more types required to compile a dynamic expression cannot be found. Are you missing a reference?
I wonder if it has anything to do with how IronJS is packaged? Can someone help me troubleshoot this error?
I fixed this by removing references to Microsoft.Scripting.Core and Microsoft.Scripting.ExtensionAttribute. These were added by the IronJS NuGet package. I still have AppHarbor build errors, but those are because AppHarbor isn't doing a clean build (different problem).
Edit: I submitted an issue with IronJS: https://github.com/fholm/IronJS/issues/92