This issue is something that is addressed in TSOA's official docs, where if you have multiple models that share the same name, you have to either change the name of one model or declare one of the duplicates of the "real" model.
The issue comes after someone on the team ran an update to Sentry. Now tsoa is finding a duplicate model between Sentry's "Logger" and TypeORM's "Logger".
In the config, "skipLibCheck" is true and I have multiple variations of the node_modules folder in the "exclude" list, hoping that maybe I could just ignore them. Nothing has helped so far, so I'm curious of anyone has solved this? (I've only found people parroting the official answer or rewriting their answer verbatim. This is a difference scenario - I cannot declare I canonical model with installed node_modules from what I can tell.)
Related
PLEASE NOTE: None of the answers in the link above (which I don't seem to be able to remove) helped me. As I explain below, I had already tried all that stuff
I have a web site, developed in VS2013 using ASP.NET MVC5/WebAPI2, which has several related projects such as a service layer, repository layer, etc. Down at the bottom of the stack is a class library that holds an EF model. I have separated the actual entities into another class library, to allow them to be reused without requiring the model library.
All of this has been working fine. The web site was running, and I could make calls to the WebAPI methods as well.
I just uploaded the latest version to the production server, and all is working fine there. Then came back to VS to carry on work, and when I try to run up the web site, I get an exception
Unable to load the specified metadata resource
Searching around, it seems that the cure for this is to modify the connection string to point to the actual assembly name instead of using the default . I have two problems with this, first is that none of the config files in the solution have been touched today (by me at least, and the file history form source control confirms this), so there's no reason why it should suddenly stop working after being deployed, and second, even if I add the assembly name, I get the same exception.
Anyone any ideas what I can do? I'm completely stuffed now. Can't do anything.
Edit: I tried again to specify the assembly in the connection string, and now get the exception Unable to resolve assembly. I have checked the assembly name in a decompiler, and I'm pretty sure got it right.
Edit again: I just pulled the version that I deployed from source control, and that gives the same exception, so I'm sure this is nothing to do with any files I've changed (or even that have been changed by VS). The version on the production server is still working, but the source code that drives that exact same version gives the exception. So, I'm certain that the answer is NOT to be found in the myriad other versions of this question, but is somewhere else.
Found the problem, and am posting it here in the hope that it will help someone else, as I don't think this was clear in any of the other posts on this issue.
I have a layered solution, with the web project referencing a service layer, which references a repository layer which in turn references the model project. It seems to for EF to work, whichever layer actually causes the database to be accessed requires a reference to the model project. My service layer project, which was where ToList() was being called (thus enumerating the query, and causing the database to be hit) didn't have a reference to the model project, so was failing to load the assembly.
I didn't need to alter the metadata part of the connection string either, as once the service layer had a reference to the model project, it was able to find the resources by itself. Having said that, one thing I did learn from all of this is that you can speed up the creation of the model (slightly) by specifying the assembly containing the resources explicitly, as this saves the framework having to search through all loaded assemblies to find them. I'm not sure if this will make any noticeable difference, but it can't harm.
I still can't explain how this had been working up until now, and suddenly stopped, as I hadn't changed any references, nor the way I was doing the data access. Still, it seems to be working now, which is all that matters.
Hope this helps someone.
For some time we are able to declare behaviour callback using -callback attribute instead of behaviour_info/1 (which in my opinion is more convenient). But, the edoc application seems to be unable to discover such attribute. Still, release notes suggested, that this issue was already fixed in version 0.7.10 (http://www.erlang.org/doc/apps/edoc/notes.html). Did anyone encounter similar problem and was able to overcome it?
I think the open issue 3211 is talking about a similar issue.
There is a comment mentioning that commit 715bb80 enables edocs to identify callbacks, but I am also seeing this functionality in the brod project -- hexdocs.
The following is the repository for redmine.
https://github.com/redmine/redmine
And the following is the repository for redmine-my-widgets-plugin
if we look at the file structure app/views/my
https://github.com/redmine/redmine/tree/master/app/views/my
there is a folder blocks which contains the partial which are widgets and displayed when added from select list.
similarly for redmine-my-widgets-plugin there is similar file directory structure
https://github.com/bradbeattie/redmine-my-widgets-plugin/tree/master/app/views/my
when i install this plugin the partials mentioned in this /my/block gets added in the my page -> select list so as to be added
When we add one of the plugins select list value then it displays 404 error
By looking at the structure the plugin, it looks like the plugin is overrided.
Also there are no others config files, or lib files present in the plugin(except en.yml)
So, what can be done that the plugin will be able to atleast find those partials.
Basically, redmine is able to find the partial files as the names are displayed in the my page -> select list but when added it throws 404 error
I know, I'm rather late to the party, but maybe this answer helps somebody else in the future.
The underlying problem was already covered at this question on SO. The plugin directory needs to have the exact same name as the symbol that is passed to Redmine::Plugin.register. In the case of this plugin: redmine_my_widgets. Changing the directory name will fix the 404.
On the other hand, the plugin was not updated for a long time and it is very likely, that most, if not all of the widgets, will no longer work because of changes to Redmine's internals.
Perhaps a bit anal, but when testing the tag functionality of TFS2012, I created some test tags that I'm not interested in using.
Despite removing these tags from all work items, they still show up in the "autosuggest" dropdown. Is there any way to remove them from that?
While probably not supported, I was able to do this with no obvious ill effects by going into the Tfs_{ProjectCollectionId} database and deleting the records found in tbl_TagDefinition.
How to configure JIRA_HOME? I'm getting an error:
Configured jira.home '/Users/codedroid/Downloads/atlassian-jira-5.1-standalone' must not be a parent directory of the webapp servlet path '/Users/codedroid/Downloads/atlassian-jira-5.1-standalone/atlassian-jira'
Changed it and now I get this:
Configured jira.home '/Users/codedroid/Downloads/atlassian-jira-5.1-standalone/atlassian-jira' must not be the same as the webapp servlet path '/Users/codedroid/Downloads/atlassian-jira-5.1-standalone/atlassian-jira'
Have a look in here, if you're still having troubles please write what did you set JIRA_HOME to be and where did you defined it, thanks.
EDIT
Yea, that documentation is more of 'how to' instead of 'what'. A better explanation of what the JIRA_HOME should be is writen in more details here.
Anyway, if you feel that the documentation are confusing or just bad, you could do everyone a favour and write it at the bottom of the page, under comments, so other could see it easily.
The JIRA documentation does NOT! make it clear even to a seasoned programmer that this JIRA_HOME directory is referring to a data directory and not the installation directory. If there are any JIRA folks out there please fix this outragious misunderstanding in your documentation. JAVA_HOME refers to you guessed it the installation location of java. Its called a 'convention' if you want to invent some other meaning please say so it your documentation and don't wast valuable developer time on installing your productivity tool. Think its not a problem? Google 'must not be the same as the webapp servlet path' and see what you get back. Thanks for wasting my afternoon, and no doubt the time of many others.
(warning) However, avoid locating the JIRA Home Directory inside the JIRA Installation Directory.
This appears in only documentation point and is not the first place people look as noted above
Just create a folder named JIRA, then set the environment variable JIRA_HOME as D:\JIRA, as well as the application properties file.
# jira-application.properties
jira.home = D:\\JIRA
Don't be confused with the JAVA_HOME, JIRA_HOME has absolutely nothing to do with the folder of your zip ball downloaded from official website.
JIRA_HOME is an empty folder where JIRA will create everything it needs in a RUNTIME.
It is NOT a folder where your unpacked JIRA distribution resides.
P.S. yes it is confusing still in 2021