I have a plugin with domain, controller and view pages. (Using grails 1.3.6)
I run the plugin as standalone, the views work fine. URL: http://localhost:8080/sample-plugin/gp/list. I am able to view the list page.
I installed the plugin into a main application i.e. plugin-test. Start as run-app within STS and browse to http://localhost:8080/plugin-test/gp/list. I am able to view the list page.
I bundle the application as war i.e. plugin-test.war and deploy to tomcat. When I browse to http://localhost:8181/plugin-test/gp/list I get a 404 error! I am not sure what I am doing wrong.
I have been trying to resolve it for quite sometime now and still no luck. The same main application works fine in STS but not in tomcat.
HTTP Status 404 - /plugin-test/WEB-INF/grails-app/views/gp/list.jsp
type Status report
message /plugin-test/WEB-INF/grails-app/views/gp/list.jsp
description The requested resource (/plugin-test/WEB-INF/grails-app/views/gp/list.jsp) is not available.
Please help.
Thank you.
Jay Chandran.
This sounds worryingly familiar, as I spent a while figuring out this (or a very similar) issue. I ended up raising this Grails bug report:
Plugin layout not found in war when installed from BuildConfig.groovy
Have you installed the plugin as using the new BuidConfig dependency technique? The JIRA documents my workaround.
Sharing some of my lessons learned after experiencing the same exact issue (1.3.7):
Double check your HTML source to make sure that your template really isn't being included. Mine was being included, but my CSS/image URLs were wrong (only while running as a war)...so I wrongly assumed that my template wasn't there.
Don't use the ui performance tags for referencing your static content...doesn't appear to work, even if the plugin attribute is specified.
Don't name your layout main.gsp. You're guaranteed to have conflicts.
Don't use absolute=true on your g:resource tags. This doesn't appear to append the pluginContextPath to the absolute url, even if you specify dir="${pluginContextPath}"
Don't use pluginContextPath, as it's no longer required: http://grails.org/doc/latest/guide/single.html#6.3%20Tag%20Libraries (search "Plugin Paths")
In your g:resource tags in your plugin layout, make sure you specify the plugin attribute. Set it to the name of your plugin.
Move your static images/css from your plugin to a web server. If each application using your plugin has its own copy, your users aren't going to benefit from caching when bouncing between apps.
Note that all of the above applies to the layout gsp in your plugin project, not your consuming application.
Related
Setup:
I am using the Java library springdoc-openapi-ui in version 1.4.0 (via Maven) without any customization in a simple spring-boot project.
The Swagger page is generated under
https://my-url.com/my-context-path/swagger-ui/index.html
and the api-docs under
https://my-url.com/my-context-path/v3/api-docs/
both of these work and I can reach them. So far so good!
Now the problem:
When simply navigating to https://my-url.com/my-context-path/swagger-ui.html I am getting a HTTP Status 302 and a location attribute set in the response header that is supposed to redirect me to the swagger page from above (I assume).
However, the URL in the location attribute misses the context path! It looks like this:
https://my-url.com/swagger-ui/index.html?configUrl=/v3/api-docs/swagger-config
It redirects to a page that does not exist and I am getting a 404 error code. Note, that the configUrl also seems to be missing the context-path.
Any ideas why this occurs and how it can be fixed?
This Github Issue seemed to be the same problem, but in the end it is stated that the problem is fixed: https://github.com/springdoc/springdoc-openapi/issues/37 and that is for a previous version than mine.
Okay so the issue is that springdoc-openapi-ui is unaware of your app context path unless it is defined in spring boot, which may not be possible for everybody.
Hopefull it does support the non-standard header X-Forwarded-Prefix that can be sent by your gateway.
I my case (Kubernetes), the Ingress can be configured in your chart by simply adding nginx.ingress.kubernetes.io/x-forwarded-prefix: "true"
And in your application config you also need to specify
server:
forward-headers-strategy: framework
to use Spring's support for handling forwarded headers.
Sources:
https://github.com/kubernetes/ingress-nginx/issues/3670
https://kubernetes.github.io/ingress-nginx/user-guide/nginx-configuration/annotations/#x-forwarded-prefix-header
https://github.com/springdoc/springdoc-openapi/issues/607
There are no know issues about context-path usage. As you can #37 is resolved and that reported it has confirmed that!
Just make sure you follow the instructions of setting context-path on standard spring-boot application.
You can test the configuration of your context path, in the different demos samples:
https://github.com/springdoc/springdoc-openapi-demos
If you have any problem, you can log an issue by provinding a minimal/reproducible sample or with unit tests that reproduces the problem.
In order to configure a swagger-ui correctly when an external context-path is configured use the follow configuration.
springdoc.swagger-ui.config-url=/context-path/api-docs/swagger-config
springdoc.swagger-ui.url=/context-path/api-docs
springdoc.api-docs.path=/api-docs
I have a fairly complicated grails plugin dependency structure within my project and I am having problems overriding classes from the security plugin.
My structure is a little something like this:
Web App
|_ Audit Plugin
|_ Spring Security Core Plugin
|_ Security Wrapper Plugin
|_ Audit Plugin
|_ Spring Security Core Plugin
The reason it is like this is audit is shared between some apps which have the security wrapper, and some what don't, which is why it pulls in Security-Core (it needs at least the ability to get the current principal).
Similarly the wrapper is shared between multiple web apps therefore we put it in a plugin. My problem comes after upgrading Spring-Security-Core to version 2.
My wrapper has a customer auth.gsp and LoginController.groovy. In the older version of security this was fine, as the plugin templated those and made them available in the source of the installing plugin.
However now these files are internal to the plugin, and although I know you can override them within the main app, when trying to override them within another plugin I get some bizarre results.
The Spring-Security-Core version of the login page always overrides my custom login page. I cannot get mine to take precedence.
The second problem is that the LoginController.groovy from the Spring-Security-Core plugin sometimes takes precedence over my one from the wrapper. It seems almost random between builds as to which one will be in use.
Is there any correct way to go about making sure my views and controllers take precedence?
OK playing around with things I found a solution that seems to work for me:
Firstly I couldn't change the order in which the plugins load because the security wrapper does a lot with spring beans and it has to load after the core plugin for this to work. So after a bit of digging in the (DefaultSecurityConfig.groovy) I noticed that you can set the following properties:
grails.plugin.springsecurity.failureHandler.defaultFailureUrl = '/login/authfail? login_error=1'
grails.plugin.springsecurity.failureHandler.ajaxAuthFailUrl = '/login/authfail?ajax=true'
grails.plugin.springsecurity.auth.loginFormUrl = '/login/auth'
So I created a custom controller and login page which have a different name to the ones use in the core plugin and changed these properties to point to my locations.
To neaten this up, in the UrlMappings for the wrapper (named: SecWrapperUrlMappings) I put a mapping from /login/** to /seclogin/**.
Make sure that these new locations aren't locked down so that people can access them and that seems to work well. I now reliable know, whichever order they load in my login page and login controller are used.
In Grails-4.013 and spring-security-core-4.0.4, I did the following trick.
In my custom plugin instead of LoginController and LogoutController I named them as SigninController and SignoutController respectively. And in UrlMappings.groovy of App mapped them like..
static mappings = {
"/login/$action?"(controller: "signin")
"/logout/$action?"(controller: "signout")
....
....
}
i am evaluating Apache Sling as a potential backend CMS. I like how easy it is to push / get new content via rest. However, I also need to be able to search the content via REST. I compiled all the source code and am running their standalone jar. There are like 100 bundles installed, but I can't find a single rest query.
Some old documentation says you can do /content/mynode.query.json?
But this is not working, and there is no help on whether its supported or not. Honestly the only search option I found was in the console via /.explore.search.html/ which returns web pages.
How can you do restful search using sling?
The JsonQueryServlet, which provides an HTTP search interface was moved to a separate bundle as part of SLING-2226. See that issue's page for how to use it, and there's a related blog post at http://in-the-sling.blogspot.ch/2008/09/how-to-use-json-query-servlet.html
I had a problem with part 3 of an orchard tutorial...
so I was attempting to download the source code for part 4 and continue on from there (which can be found about 3/4 of the way down at the end of the tutorial on the page http://skywalkersoftwaredevelopment.net/blog/writing-an-orchard-webshop-module-from-scratch-part-4
However when I run part 4 from webmatrix I get the error(see below)
im guessing this is because iv only downloaded the code but i need to put it inside a seperate project? is this correct? can someone advise me how to do this?
thanks for any replies
The error states that there is no default document configured in IIS. Attempt to access the document using the full URL.
For instance http://localhost:28266/default.aspx (or similar)
You can then adjust IIS to have the correct default document (if desired)
Edit: After reviewing the referenced ZIP archive.
This looks like a changed file zip for the application. This isn't a complete ASP.NET MVC application by itself and, as such, isn't viewable stand alone. I don't have the time to parse the exact steps required to make this application work alongside the demos provided, but be sure you're either combining all of the previous files and folders in order or follow the instructions detailed by the author.
As referenced, this is not a complete ASP.NET MVC application and isn't ready to be immediately rendered by IIS.
The problem is probably that the application can't start for some reason, which causes IIS to attempt to respond to the request with other handlers. Because there is no default document defined (and there shouldn't), it tries to do a directory listing, which is not allowed in your configuration. Do not focus on what IIS is telling you but rather on why your application doesn't run.
Things to check:
you have built the application
you are running in full trust
you are running in integrated mode
there is no exception in app_data/logs
you added the module to a working Orchard instance, in its Modules directory
Wonder if anyone has come accross this problem. I have created a demo portlet using the grails portlet and liferay plugins.
After installing the grails plugins in a project i simply ran the following commands
grails create-portlet MyFirst
grails generate-portlet-views MyFirst
grails liferay-deploy
The portlet deploys fine. However when i try to add the portlet to a page then i get the following stacktrace. Anyone have any ideas ?
23:04:52,134 ERROR [jsp:165] javax.servlet.ServletException: File "/WEB-INF/grails-app/views/myfirst/render.jsp" not found
I am running liferay version 5.2.3 that has tomcat version 6.0.18 embedded. I am also using JVM 1.6
thanks in advance.
The current versjon of the Grails portlet plugin (0.7) doesn't support portletnames with capital cases. Change MyFirst to myfirst and it will work like a charm (well, almost ;)
Regards
Armaz
It looks like it's not able to find render.gsp (the default gsp for a porltet if no mode specific view is found).
What did generate-portlet-views generate for you?
Take a closer look to your stacktrace - it attempts to look for render.jsp, not gsp. render.jsp is the default template LR attempts to find if it does not find what it is looking for depending on the action.
Read Armaz's answer, he is correct. You must change template folder name to lower case: myFirst => myfirst.
The next problem you might experience is solved here: Grails Liferay portlet not invoking action ;)