I am in the process of upgrading my Grails 1.3.7 app to 2.0.3 and I have fixed most issues. However, I have code that used to work that creates a user and saves them to the database. The code should NOT pass validation as I am reusing a username that is already taken and there is a unique constraint on username. .validate() returns true, but then the code actually bombs when user.save() is called with a MySql unique constraint error.
Should throw an error:
def submitSignup = {
def user = new User(params)
user.validate()
if (!user.hasErrors()) {
...
// This line bombs with the MySql unique constraint I would have expected .validate() to get
user.save()
}
}
In User.groovy:
static constraints = {
username(blank: false, unique: true);
...
}
Any ideas?
EDIT: I am also upgrading to the Spring Security plugin from Acegi. I don't think this would be relevant, but I figured I would mention it.
I put up a sample that suffers from the problem at: https://github.com/skazzaks/Grails-Unique-Test This makes it definitely look like a bug.
I was experiencing a similar weird validation issue a couple of days ago while upgrading from 1.3.7 to 2.0.3.
What did the trick for me was a manual clearing of my target dir. Apparently recompiling of all the classes put the application back on track.
Don't know if it will work in your case though, but might be worth a try.
I believe this is a bug due to the fact that my Domain classes are in src/groovy.
Related
I'm using VS 2022, ASP.NET Core 6 MVC and Microsoft SQL Server 2019 (v15).
Git project: [https://github.com/Wizmi24/MVC_BookStore]
I'm trying to add --> new scaffolded item --> identity.
Default layout page, override all files and mine Data context
when I click add, I get this error:
There was an error running the selected code generator:
'Package restore failed. Rolling back package changes for 'MyProjectName'
I cleared NuGet Package cache as I saw it may help, but all it do is just prolong and this same error is visible after trying to install Microsoft.EntityFrameworkCore.SqlServer, which is installed. I checked the packages and made sure they are the same version (6.0.11).
I cloned your project to test, and the problem you mentioned did appear. Not sure why, but I finally got it working by updating the NuGet package:
I updated the two packages Microsoft.EntityFrameworkCore and Microsoft.EntityFrameworkCore.Relational to version 7.0.1 (you need to pay attention to the sequence when updating), then add scaffolded Identity, and I succeeded.
You can try my method, if the Identity is successfully added, but the following exception is encountered at runtime:
You need to add builder.Services.AddDbContext<MyBookContext>(); before
builder.Services.AddDefaultIdentity<IdentityUser>(options => options.SignIn.RequireConfirmedAccount = true)
.AddEntityFrameworkStores<MyBookContext>();
MyBookContext is the Data context class selected when you add Identity:
In addition, if there is a 404 error in your area routing, you can refer to this document to modify it.
Hope this can help you.
Edit1:
I think it might be a problem caused by naming duplication. Please try to change the name of the context generated by Identity.
As you can see, the ApplicationDbContext generated by Identity is consistent with the ApplicationDbContext namespace in your MyBook.DataAccess:
So naming the same will cause conflict:
So you need to change the naming to avoid conflicts. For example:
builder.Services.AddDbContext<ApplicationDbContext>(options => options.UseSqlServer(
builder.Configuration.GetConnectionString("DefaultConnection")
));
builder.Services.AddDbContext<ApplicationDbContextIdentity>();
builder.Services.AddDefaultIdentity<IdentityUser>(options => options.SignIn.RequireConfirmedAccount = true)
.AddEntityFrameworkStores<ApplicationDbContextIdentity>();
Edit2:
As I mentioned in the original answer, if you get a 404 error, you can try to refer to this link to fix the area routing.
The easiest way is to directly change the routing settings in Program.cs:
app.MapAreaControllerRoute(
name: "Customer",
areaName: "Customer",
pattern: "{area:exists}/{controller=Home}/{action=Index}/{id?}");
Then add the Area property to the controller:
[Area("Customer")]
public class HomeController : Controller{}
There seems to be a problem with your Repository.cs, so I changed the Index to only output a string to test the result.
public string Index()
{
return "success";
}
Test Result:
If your Repository.cs also has problems when you test it, you can make a new post for everyone to help you fix this problem(Because this question strays so far from your original question, one post is better off addressing only one question).
Good Luck.
I've been tasked with maintaining a Xamarin native project using MvvmCross 5.6.2. Not knowing exactly how to approach this, I've decided to update to one major version at a time (6 first, then 7 and 8). I'm not sure why I specifically have chosen 6.4.2, but it was maybe because this was the latest version of the majority of the plugins I was using on Nuget.
So far, the update has been a success and I have been able to fix all build errors. However, when running the application, I've been getting a null reference exception which I can't fully trace.
Based on the limited application output, I've been able to determine that the problem lies somewhere in my Android's setup.cs class (I think). I've been following Nick's .NET Travels advice on MvvmCross debugging. From viewing the MvvmCross 6.4.2. source and pasting in the following code in my own overrides:
public virtual void LoadPlugins(IMvxPluginManager pluginManager)
{
Type pluginAttribute = typeof(MvxPluginAttribute);
IEnumerable<Assembly> pluginAssemblies = GetPluginAssemblies();
foreach (Assembly item in pluginAssemblies)
{
IEnumerable<Type> enumerable = item.ExceptionSafeGetTypes();
foreach (Type item2 in enumerable)
{
if (TypeContainsPluginAttribute(item2))
{
pluginManager.EnsurePluginLoaded(item2);
}
}
}
bool TypeContainsPluginAttribute(Type type)
{
object[] customAttributes = type.GetCustomAttributes(pluginAttribute, inherit: false);
return ((customAttributes != null && customAttributes.Length != 0) ? 1 : 0) > (false ? 1 : 0);
}
}
public virtual IEnumerable<Assembly> GetPluginAssemblies()
{
string mvvmCrossAssemblyName = typeof(MvxPluginAttribute).Assembly.GetName().Name;
Assembly[] assemblies = AppDomain.CurrentDomain.GetAssemblies();
var test = from asmb in assemblies.AsParallel()
where AssemblyReferencesMvvmCross(asmb, mvvmCrossAssemblyName)
select asmb;
return test;
}
I'm able to see that GetPluginAssemblies doesn't return any enumerable, and the LoadPlugins method then produces the NullReferenceException. But I can't see what this NullReference actually is.
I followed the upgrading from 5 to 6 guide https://www.mvvmcross.com/documentation/upgrading/upgrade-to-mvvmcross-60.
I looked at the MvvmCross 6 and 6.4.0 release pages:
https://www.mvvmcross.com/mvvmcross-6.0.0-release/
https://www.mvvmcross.com/mvvmcross-6.4.0-release/
And I followed Benjamin Mayrargue's guide: https://medium.com/#bigoudi/upgrading-from-mvvmcross-5-to-mvvmcross-6-7ded83ecb69d
But I have been unable to load my plugins (previously they were bootstraps, but most of the guides say these can be discarded now and that loading plugins is easier).
I also attempted the answer suggested in this question How to use an mvvmcross plugin such as the file plugin.
But to no avail.
So I am asking if anyone knows a good guide or how to use plugins in MvvmCross 6.4.2.
Thank you.
Plugins are just a way to register things in the IoC Container. This is done by MvvmCross during startup using the LoadPlugins method in your Setup file.
Most of the time it should just work. However, there are some caveats.
If the Linker has gone ahead and linked away some of the plugins code, you will have a bad time. What you can do about that is to hint the mono linker to not strip the code away.
Add a LinkerPleaseInclude class and add a Include method in it that looks something like:
new MvvmCross.Plugin.Color.Platforms.Ios.Plugin().Load();
You can do that for every plugin you may want to use.
If LoadPlugins doesn't find the entry Assembly, sometimes it also does not register the plugins. You can override LoadPlugins in your Setup class and just call EnsurePluginLoaded:
public override void LoadPlugins(IMvxPluginManager pluginManager)
{
base.LoadPlugins(pluginManager);
pluginManager.EnsurePluginLoaded<MvvmCross.Plugin.Color.Platforms.Ios.Plugin>();
}
I want to thank Cheesebaron for his plugin support. I think I've fixed my issue and as it turned out, I don't think there is a plugin issue after all (yet).
Thanks to Toolmakersteve also. His suggestion for using a try catch in the OnCreate of my overridden MvxSplashScreenAppCompatActivity surfaced an issue with setting a theme for this activity. In actuality, this class was initially a MvxSplashScreenActivity.
Reverting this line, I then started getting NullReferenceExceptions on specific lines, all relating to IoC and lazy construction of singletons. The class Mvx seemed to be throwing up this error. On a sort of hunch from previous experience with my updating, I removed the MvvmCross.Platform using statement and checked what suggestions Mvx had available to it. It suggested MvvmCross and MvvmCross.Platform, so I tried the former instead. Sure enough, this moved my execution further, throwing up more Null Reference Exceptions. I also encountered one instance of failing to resolve IMvxResourceLoader from MvvmCross.Platform.Platform. Switching that to MvvmCross.Base did the trick.
This was only a chance fix through a bit of guess work. #CheeseBaron, should I add this as a note to this bit of documentation https://www.mvvmcross.com/documentation/upgrading/upgrade-to-mvvmcross-60? As mentioned, I'm as far as 6.4.2 now, so I'm not certain this is the right place for it.
I've got a few bugs with embedded resources to fix now, but if I encounter any more that are relevant to my question, I'll list them here.
I'm trying to do authentication on my Android application using Xamarin.Auth. Some time ago, Google made the policy that you cannot do this in an embedded web view (for totally valid reasons).
I'm trying to open the account authentication page in a browser, but keep getting the embedded web view. I understand that isUsingNativeUI needs to be true in the following code:
_auth = new OAuth2Authenticator(clientId, string.Empty, scope,
new Uri(Constant.AuthorizeUrl),
new Uri(redirectUrl),
new Uri(Constant.AccessTokenUrl),
null,
isUsingNativeUI = true);
At every point in my application, this always equals true.
Elsewhere, I have code that redirects to what should be a browser:
var authenticator = Auth.GetAuthenticator();
Intent intent = authenticator.GetUI(this);
this.StartActivity(intent);
Regardless, I keep getting a dreaded 403 disallowed_useragent error whenever I try to run the project. Is there another element to this that I'm missing?
To my knowledge, setting auth.IsUsingNativeUI = true in the constructor should dictate that it must open in a browser. I've been following this example to try and debug with no success. I even pulled the guy's repo down to my machine and ran it - the Intent variable at the moment of redirection is almost identical.
Could there be something stupid that I'm missing? What else might be going wrong?
I realize this is an old question, but I had the same issue.
You have to install version 1.5.0.3 of the Xamarin.Auth Nuget package. The newest one (version 1.7.0 right now) doesn't work. You'll have to also install the PCLCrypto nuget package in order to get that version to work.
I'm trying to use express-stormpath on my Heroku app. I'm following the docs here, and my code is super simple:
var express = require('express');
var app = express();
var stormpath = require('express-stormpath');
app.use(stormpath.init(app, {
website: true
}));
app.on('stormpath.ready', function() {
app.listen(3000);
});
I've already looked at this question and followed the Heroku devcenter docs. The docs say that for an Heroku app, it's not necessary to pass in options, but I've still tried passing in options and nothing works. For example, I've tried this:
app.use(stormpath.init(app, {
// client: {
// file: './xxx.properties'
// },
client: {
apiKey: {
file: './xxx.properties',
id: process.env.STORMPATH_API_KEY_ID || 'xxx',
secret: process.env.STORMPATH_API_KEY_SECRET || 'xxx'
}
},
application: {
href: 'https://api.stormpath.com/v1/applications/blah'
},
}));
To try and see what's going on, I added a console.log line to the stormpath-config strategy valdiator to print the client object, and it gives me this:
{ file: './apiKey-xxx.properties',
id: 'xxx',
secret: 'xxx' }
{ file: null, id: null, secret: null }
Error: API key ID and secret is required.
Why is it getting called twice, and the second time around, why does the client object have null values for the file, id and secret?
When I run heroku config | grep STORMPATH, I get
STORMPATH_API_KEY_ID: xxxx
STORMPATH_API_KEY_SECRET: xxxx
STORMPATH_URL: https://api.stormpath.com/v1/applications/[myappurl]
I'm the original author of the express-stormpath library, and also wrote the Heroku documentation for Stormpath.
This is 100% my fault, and is a documentation / configuration bug on Stormpath's side of things.
Back in the day, all of our libraries looked for several environment variables by default:
STORMPATH_URL (your Application URL)
STORMPATH_API_KEY_ID
STORMPATH_API_KEY_SECRET
However, a while ago, we started upgrading our libraries, and realized that we wanted to go with a more standard approach across all of our supported languages / frameworks / etc. In order to make things more explicit, we essentially renamed the variables we look for by default, to:
STORMPATH_APPLICATION_HREF
STORMPATH_CLIENT_APIKEY_ID
STORMPATH_CLIENT_APIKEY_SECRET
Unfortunately, we did not yet update our Heroku integration or documentation to reflect these changes, which is why you just ran into this nasty issue.
I just submitted a ticket to our Engineering team to fix the names of the variables that our Heroku addon provisions by default to include our new ones, and I'm going to be updating our Heroku documentation later this afternoon to fix this for anyone else in the future.
I'm sincerely sorry about all the confusion / frustration. Sometimes these things slip through the cracks, and experiences like this make me realize we need better testing in place to catch this stuff earlier.
I'll be working on some changes internally to make sure we have a better process around rolling out updates like this one.
If you want a free Stormpath t-shirt, hit me up and I'll get one shipped out to you as a small way to say 'thanks' for putting up with the annoyance: randall#stormpath.com
After endless hours, I managed to finally get it working by removing the add-on entirely and re-installing it via the Heroku CLI and then exporting variables STORMPATH_CLIENT_APIKEY_ID and STORMPATH_CLIENT_APIKEY_SECRET. For some reason, installing it via the Heroku Dashboard causes express-stormpath to not find the apiKey and secret fields (even if you export variables).
I am facing the same problem as descripted in this other question but the solution does not work for me. I am using Doctrine 2.1 with CodeIgniter 2 downloaded as package from wildlyinaccurate. As you can see on the page the ClassLoader is called:
$entitiesClassLoader = new \Doctrine\Common\ClassLoader('models', rtrim(APPPATH, '/'));
$entitiesClassLoader->register();
I made sure the path is right. I even tried setting the full path.
Strange for me is that $user = new models\User(); is working. Calling $this->em->find('User', 8); I get the error User does not exists.
Any thoughts about that?
Just a wild guess but don't you have to call find('models\User', 8) ? Because your User object is properly in the 'models' namespace?