we are upgrading a grails 2.2.5 application to grails 3.1 and have an interesting error. What does this mean and how should it be resolved?
/myapp/grails-app/controllers/myapp/admin/AdminProjectController.groovy: -1:
The return type of java.lang.Object getGrailsApplication() in myapp.admin.AdminProjectController is incompatible with grails.core.GrailsApplication in grails.web.api.WebAttributes
. At [-1:-1] # line -1, column -1.
Thanks to burtbeckwith on this issue.
"Controllers in Grails 2 and Grails 3 already have an implicit dependency injection for GrailsApplication, so you're adding a second. In Grails 2 it's not typed (def grailsApplication) but in Grails 3 it is typed (GrailsApplication grailsApplication), so you've effectively added an override, but with a less specific return type which is invalid. Just delete your def grailsApplication and use the one that's already there."
If you just remove def grailsApplication from all controllers it will be fixed.
Related
I have been using Glide 4.11.0 and Realm 6.0.2 for some time now, and recently upgraded Android Studio 4.0.x to 4.1. All has been going fine. Today I ran the lint checker, and started doing some "clean up", nothing out of the ordinary (it would seem). One of the things I did a lot of was to replace switch statements that were testing against R.id. with if-else statements per the lint warning about what's gonna happen in Gradle 5.0.
When I did this, I did use a number of int variables I named 'id' that were to replace the value to compare - i.e. instead of a switch statement that would be:
switch (menuOpt.getId()) {
case R.id.xxx:
...
}
I would do:
int id = menuOpt.getId();
if ( id == R.id.XXX) {
} else if....
per the new guidelines.
Suddenly, on a full build AS complains that it no longer recognizes GlideApp, and I am also getting a very weird message about Realm not being able to process correctly:
C:\BLD\AndroidStudioProjects\InTouch\app\src\main\java\com\reddragon\intouch\ui\MediaPlayerActivity.java:61: error: cannot find symbol
import com.reddragon.intouch.utils.GlideApp;
^
symbol: class GlideApp
location: package com.reddragon.intouch.utils
C:\BLD\AndroidStudioProjects\InTouch\app\src\main\java\com\reddragon\intouch\ui\MediaDialogActivity.java:92: error: cannot find symbol
import com.reddragon.intouch.utils.GlideApp;
^
symbol: class GlideApp
location: package com.reddragon.intouch.utils
C:\BLD\AndroidStudioProjects\InTouch\app\src\main\java\com\reddragon\intouch\ui\MediaListActivity.java:48: error: cannot find symbol
import com.reddragon.intouch.utils.GlideApp;
^
symbol: class GlideApp
location: package com.reddragon.intouch.utils
Note: Version 10.0.0 of Realm is now available: https://static.realm.io/downloads/java/latest
Note: Processing class Album
error: Class "Album" contains illegal final field "id".
Note: [1] Wrote GeneratedAppGlideModule with: []
Class "Album" contains illegal final field "id".
4 errors
I have had the field 'id' in my Album class for about 2 years with no issues!
No manner of rebuild, invalidating cache and restarting, syncing gradle files or "reload all from disk" seems to help.
Actually, if I invalidate and restart, I don't get the red squiggle in the offending classes that are referencing GlideApp, but as soon as I start to run the app and it goes through a build process it errors out.
I Googled a bit and found one post where there seemed to be some conflict between Realm and Glide (RequestOptions), but the strange thing to me is why would this suddenly start occurring?
I have validated that the GlideAppjava class is in fact getting built - I am using the debug build variant, and I can see in the file system GlideApp.java that is in the ap_generated_sources/debug directory in the proper package where I have my class that extends AppGlideModule with the #GlideModule annotation.
So GlideApp is getting generated. It just isn't getting recognized.
One of the other new things is that I've recently created a Dynamic Feature module. This module does depend on a class that is in the base module (where GlideApp is referenced). Not sure if this is relevant (I had many, many successful builds before I started doing lint clean-up).
So frustrating! Any help appreciated.
It turns out that the answer was staring right at me, although somewhat hidden: part of the lint check that I did was accept some suggestions about making variables 'final' - including those that are used in Realm classes to define Realm objects. Realm doesn't like that - above build error output includes as a last line the statement 'Class "Album" contains illegal final field "id".'
"Album" extends RealmObject, and the "auto accept" of the lint's suggestion to make some of the fields final was the culprit.
I think this issue with Realm caused a ripple effect somehow with the other annotation processing - when I went back to all the RealmObject classes and removed the "final" declaration, build now completes smoothly.
we upgraded from HV 4.x to HV 5.4.2 and now when we have interface like following
#NotNull
List<AccountInfo> getMultiClientAccountBalances(#NotNull ClientContext clientContext, #NotNull Optional<AccountFilter> accountFilter);
I'm getting error:
javax.validation.UnexpectedTypeException: HV000186: The constraint of type 'javax.validation.constraints.NotNull' defined on 'getMultiClientAccountBalances.arg1' has multiple matching constraint validators which is due to an additional value handler of type 'org.hibernate.validator.internal.engine.valuehandling.OptionalValueUnwrapper'. It is unclear which value needs validating. Clarify configuration via #UnwrapValidatedValue.
I know it can be fixed by adding #UnwrapValidatedValue to the field, but this must be added to every method what is a lot of work for me. Is there any simpler solution (besides upgrade to HV6.x)
Unfortunately I don't see how we could change this behavior in 5.4 without breaking other use cases.
And there is no easy way to disable the optional value handler as it's added unconditionally.
So I would say you have two solutions:
a search and replace of all #Constraint Optional to add the UnwrapValidatedValue option
or move to HV 6, where we totally reworked this feature and where, I think, it should work as you expect it. I know you didn't want this answer but it is what it is...
The issue with 1. is that we removed this annotation from HV (it was experimental) in favor of a standard feature included in Bean Validation so you will have to remove it when moving to 6.
I don't know your exact environment but HV 6 is highly compatible with the previous versions so it might work very well. Just be careful about the dependencies as we changed the groupId of the artifact from org.hibernate to org.hibernate.validator. Also be aware that you need to update the validation-api from 1.1 to 2.0.
6 is already very stable and if you have any issues with it, we will fix them right away.
I was able to create an OData (v3) service with WebApiOdata and EntityFramework at server side and Breeze at client side thanks to this document.
Now I'd like to do the same with the version 4 of OData spec. but there is a problem. The EdmBuilder class provided by Breeze depends on the 'Microsoft.Data.Edm' which is related to the version 3.
In the EdmBuilder these 2 lines prevent the project from building:
using Microsoft.Data.Edm.Csdl;
using Microsoft.Data.Edm.Validation;
which is normal, because my project has a reference to 'Microsoft.OData.Edm'(for v4) instead of 'Microsoft.Data.Edm'(for v3).
So I replaced the 2 using statements, by this:
using Microsoft.OData.Edm;
using Microsoft.OData.Edm.Csdl;
using Microsoft.OData.Edm.Validation;
Now the project can build, but at runtime it throws this exception
"Encountered the following errors when parsing the EDMX document:
UnexpectedXmlElement : The element 'Edmx' was unexpected for the root
element. The root element should be Edmx. : (1, 40)"
from the EdmBuilder class at this point:
using (var reader = XmlReader.Create(stream))
{
return EdmxReader.Parse(reader);
}
Is there any way to solve this problem ??? like a new EdmBuilder class that I can download somewhere?
P.S.: I'm using code first migration and this code to configure OData route in the 'WebApiConfig' :
config.MapODataServiceRoute(
routeName: "ODataRoute",
routePrefix: "OData",
model: EdmBuilder.GetEdm<MyDbContext>(),
batchHandler: new DefaultODataBatchHandler(GlobalConfiguration.DefaultServer));
We are currently working on a breeze release that works with OData v 4.0. I will post back here when it is released, which should be in the fairly near future.
I am currently having a strange issue with an application migrated from rails 2.3.8 to rails 3 (3.0.1, 3.0.2, 3.0.3).
At random moments associations behave strangely. In some cases, an associated object will return the Relation object, instead of the corresponding model. This seems to happen mostly on polymorphic associations. For example:
class A
belongs_to :b, :polymorphic => true
end
class B
has_many :a, :as => :source
end
When invoking "a.b" this will "sometimes" return the Relation object (causing a "undefined method ... for ActiveRecord::Relation" error to raise) and some other times it will return the correct B object.
When the relation object is returned, it may sometimes be "fixed" temporarily by restarting the server, but it will eventually show up again.
Another issue i get is that when "getting" associated objects, sometimes the required filters are not automatically applied (where element id = ...). this causes the query to return the first object in the table and not the correct associated object.
This is becoming a very frustrating issue, specially since i don't seem to find anyone else with this or similar issues.
All finder methods in the application have been migrated to the new rails form, but this strange behavior remains.
The current configuration being used is:
Ubuntu 10
nginx server
passenger (3.0.2)
rails (3.0.3)
ruby 1.9.2p0 (2010-08-18 revision 29036)
After digging a bit deeper into the Active Record code, my co-worker and I found that the belongs_to_association.rb and belongs_to_polymorphic_association.rb were still using the old finder methods in the "find_target" method.
We ran a couple tests by logging the resulting objects of this method from different queries and discovered the old finders were returning the ActiveRecord::Relation at random moments (loading the same object it would sometimes return the object and other times the Relation object).
We overrode the find_target method for these 2 classes in initializer files, changing the finders used there to the new rails3 format (klass.select(...).where(...), etc). This seems to have solved the issue.
The "has_many" association files are already using the new format, so these haven't caused any issues.
We applied these "fixes" to the rails 3.0.3 and hope that they will be resolved in future releases.
Here are our initializer files in case someone else bumps into this problem:
belongs_to_polymorphic_association.rb:
#initializers/belongs_to_polymorphic_association.rb
module ActiveRecord
# = Active Record Belongs To Polymorphic Association
module Associations
class BelongsToPolymorphicAssociation < AssociationProxy #:nodoc:
private
def find_target
return nil if association_class.nil?
target =
if #reflection.options[:conditions]
association_class.select(#reflection.options[:select]).where(conditions).where(:id => #owner[#reflection.primary_key_name]).includes(#reflection.options[:include]).first
else
association_class.select(#reflection.options[:select]).where(:id => #owner[#reflection.primary_key_name]).includes(#reflection.options[:include]).first
end
set_inverse_instance(target, #owner)
target
end
end
end
end
belongs_to_association.rb:
#initializers/belongs_to_association.rb
module ActiveRecord
# = Active Record Belongs To Associations
module Associations
class BelongsToAssociation < AssociationProxy #:nodoc:
private
def find_target
key_column = (#reflection.options[:primary_key]) ? #reflection.options[:primary_key].to_sym : :id
options = #reflection.options.dup
(options.keys - [:select, :include, :readonly]).each do |key|
options.delete key
end
options[:conditions] = conditions
the_target= #reflection.klass.select(options[:select]).where(key_column => #owner[#reflection.primary_key_name]).where(options[:conditions]).includes(options[:include]).readonly(options[:readonly]).order(options[:order]).first if #owner[#reflection.primary_key_name]
set_inverse_instance(the_target, #owner)
the_target
end
end
end
end
Hope this is useful for someome
Thanks for sharing this. The problem with associations gone. But I still had this issue even with straight "find" method.
#post = Post.find(params[:id)
#post.update_attributes...
will fail with ActiveRecord::Relation error. However
#post = Post.find_by_id(params[:id])
#post.update_attributes...
will work
Seems like strange lazy loading behaviour
i seem to be having some problems with the Vector class in actionscript 3
in a Flex Project or an ActionScript Project it is possible to do this
var v:Vector.<String>;
But when i do the same thing in a Flex Library Project (to create an SWC)
then i get the following error on that line of code
1046: Type was not found or was not a compile-time constant: String.
so when using Flex Library Project it fails..., but when i compile the same thing using compc there are no problems
any idea why only the library project is complaining about Vector ?
btw this happens with all kinds off Vector declarations , not just String
var v:Vector.<String>
var v:Vector.<Number>
var v:Vector.<Object>
etc, all fail...
(i am using flex 4 sdk)
You might need the latest Player Globals SWC: http://labs.adobe.com/downloads/flashplayer10.html
Similar to this issue?
add:
"-target-player 10,0,0"
under "Properties -> Flex Library Compiler -> Additional compiler arguments !
Then it works with Flex B. 3
Check if your are publishing for a version flash >=10
ok it seems with Flex Builder 3 it is not possible to specify a minimim required flash player version for a Flex Library project , that's why it wasnt working.
i have tested the same thing in Flash Builder 4 , and now it is possible to specify that player version , which it possible to compile the Flex Library Project.
Thx for the answers Tegeril and Patrick you pushed me in the right direction.
Make sure you set the "-target-player" compiler argument to "10,0,0".
Adding "-target-player 10,0,0" in Flex Builder 3 gives an error "configuration variable 'target-player' must only be set once".
To resolve it add the following line in Project -> Properties -> Flex Library Compiler -> Additional compiler arguments
-dump-config "C:\Program Files\Adobe\Flex Builder 3\sdks\3.5(AIR 2.0)\frameworks\flex-config.xml" -target-player=10
this would dump the current configuration settings.