I have an application in which I'm trying to implement external configs. This part is working fine. However, now it seems like some of the config settings are being lost.
I am using this setting:
grails.app.context = "/${appName}"
appName is defined in the application.properties file, and was working fine.
as stated above I extenalized my datasource and grails.serverURL settings.
Now when I click my logout link I get redirected to http://myapplication/[:]/j_spring_security_logout
I can replace the [:] with the context and it takes me to the correct url (post logout) but then when trying to log back into the application I get this url.
http://myapplication/[:] in place of the default login url.
EDIT
having added some println statements to my Config.groovy file. It appears to load the Config.groovy file 3 times. The first two times I see what I'm expecting to see, the third time is when it setts the context to [:].
Why is it loading the config three times, and what is it about the third time that is loosing my settings?
To answer my own question. After much debugging and hair pulling I found my answer. It wasn't that the context was being lost after logout. The application was never truly getting the correct settings. (in a sense). There are several plugins that call to the config.groovy file during start up. One of those happened to be multiTenant. When accessing the config.groovy and subsequent external config files ${appName} was no longer in scope, thus tomcat loaded application without trouble using its default conventions. The spring logout then tried to redirect after logout to ${appName} which at the time was an empty or [:].
The solution I found was in the external config file to change my grails.serverURL from
grails.serverURL = "http://myApplication.com/${appName}"
to
grails.serverURL = "http://myApplication.com" + grails.app.name
This allows for the application.properties file to contain the app.name variable and the external config file to use the correct property that I need for the different deployments of the war file.
It may not be the most elegant solution but it solve the issue with the spring logout.
Related
I am currently using the Marklogic spring boot demo. So far I have been able to add indexes, facets, front-end logic etc just fine.
Right now, I am trying to layer in some semantic logic into a rest endpoint.
I wrote a simple query into the query console, and attempted to add it to the src/main/ext folder so that it would get deployed by the ml-gradle bootrun.
Right now. This file will get deployed to the test-modules database, and is visible once saved (I can see it in explorer under URI /ext/my-endpoint. I also tried adding a folder named rest-api but that just adds it to /ext/rest-api/my-endpoint
At the top of the endpoint I have it declared as
`module namespace ext = "http://marklogic.com/rest-api/resource/my-endpoint";
However when I navigate to the URL it should be living at http://localhost:8090/LATEST/resources/my-endpoint?
It tells me it does not exist.
So I can see it in the modules database, but I can't use it on HTTP. the Query works in the query console (and is rather trivial, and-query of json-property-word-queries)
My question is:
How can I properly update the marklogic-spring-boot framework to properly deploy rest endpoints.
So I figured it out it seems.
Manually creating the file isn't registering the distribution workflow properly.
Instead I create the resource using ml-gradle
gradle mlCreateResource -PresourceName=my_endpoint
This will create a new folder called services, and create the endpoint for me, which can then have code over written.
Still not sure what gradle is doing special, so I can know what the proper way to do this manually would be, but at least it works.
I'm using this URL to go directly to my document in SpagoBI but it does not work:
http://localhost:8080/SpagoBI/servlet/AdapterHTTP?
PAGE=LoginPage&NEW_SESSION=TRUE&OBJECT_LABEL=DocumentName
It gives me the message that I should log in but i'm already logged in.
Download SpagoBIQbeEngine separately from Downloads page (http://forge.ow2.org/project/showfiles.php?group_id=204) and deploy war file to webapps folder of your SpagoBI installation.
Wait till Tomcat automatically deploys war file and refresh the page
Good luck
use url like one mentioned below
you need to pass username and password along with url
as you can see username and password is visible in URL for security
you can use intermediate servlet to build this url and then url.
http://localhost:8080/SpagoBI/servlet/AdapterHTTP?PAGE=LoginPage&NEW_SESSION=TRUE&OBJECT_LABEL=REPORT_NAME&userId=biadmin&password=biadmin
(only login)
if report contains filter u need to pass filter parameter as well in URL
please see url structure of GET method for better understanding for passing multiple parameters.
&PARAMETERS=report parameters
Hope this helps
so I am working on a school project in which we have designed a web application that takes in much user info and creates a pdf then should display that pdf to the user so they can print it off or save it. We are using Play! Framework 2.1.3 as our framework and server and Java for the server side. I create the pdf with Apache's PDFbox library. Every thing works as it should in development mode ie launching it on a localhost with plays run command. the issue is when we put it up to the server and launch with plays start command I it seems to take a snapshot of the directory (or at least the assets/public folder) which is where I am housing the output.pdf file/s (i have attempted to move the file elsewhere but that still seems to result in a 404 error). Initially I believed this to be something with liunx machine we were deploying to which was creating a caching problem and have tried many of the tricks to defeat the browser from caching the pdf
like using javascript to append on a time stamp to the filename,
using this cache-control directive in the play! documentation,
"assets.cache./public/stylesheets/output.pdf"="max-age=0",
then I tried to just save the pdf as a different filename each time and pass back the name of that file and call it directly through the file structure in the HTML
which also works fine with the run command but not the start.
finally I came to the conclusion that when the start command is issued it balls up the files so only the files that are there when the start command is issued can be seen.
I read the documentation here
http://www.playframework.com/documentation/2.1.x/Production
which then I noticed this part
When you run the start command, Play forks a new JVM and runs the
default Netty HTTP server. The standard output stream is redirected to
the Play console, so you can monitor its status.
so it looks like the fact that it forks a new JVM is what is causing my pain.
so my question really is can this be gotten around in some way that a web app can create and display a pdf form? (if I cannot get this to work my only solution
that I can see is that I will have to simulate the form with HTML and fill it out from there) --which I really think is a bad way to do this.
this seems like something that should have a solution but I cannot seem to find or come up with one please help.
i have looked here:
http://www.playframework.com/documentation/2.1.x/JavaStream
the answer may be in there but Im not getting it to work I am pretty novice with this Play! Framework still
You are trying to deliver the generated PDF file to the user by placing it in the assets directory, and putting a link to it in the HTML. This works in development mode because Play finds the assets in the directory. It won't work in production because the project is wrapped up into a jar file when you do play dist, and the contents of the jar file can't be modified by the Play application. (In dev mode, Play has a classpath entry for the directory. In production, the classpath points to the jar file).
You are on the right lines with JavaStream. The way forward is:
Generate the PDF somewhere in your local filesystem (I recommend the temp directory).
Write a new Action in your Application object that opens the file you generated, and serves it instead of a web page.
Check out the Play docs for serving files. This approach also has the advantage that you can specify the filename that the user sees. There is an overloaded function Controller.ok(File file, String filename) for doing this. (When you generate the file, you should give it a unique name, otherwise each request will overwrite the file from a previous request. But you don't want the user to see the unique name).
I am developing an application in ServiceStack and am trying to sort out deployment on AppHarbor, however for some reason my web.config transforms are not being applied.
I had originally a Web.AppHarbor.config file and changed the Environment Setting to "AppHarbor" - once this failed to work after several updates, I gave up and changed the Environment setting to "Release" and copied the desired transformations into the Web.Release.Config file.
App gets deployed OK but config settings do not reflect the values in the transform file (I verify this by login on with twitter and seeing the callback url for Twitter Auth still tries to redirect me to localhost, which is one of the settings I change in my transform file)
I have also tried the transform tester tool and all works as expected.
Manually publishing the web application to a local folder correctly applies the transformations according to the selected configuration
Does anyone have this working? Is there something obvious I'm missing?
Thanks
It sounds like the Web.Release.config file is not included in the build output. You need to set the Build Action attribute to Content to include it in the build output.
You can confirm whether the file is included in the output by downloading the build from the log page.
I stumbled across this post because I was seeing the same lack of action myself. Upon closer inspection (about 15 times that is) of my Web.Release.config I realized one of the nodes in my config file was not marked xdt:Transform="Replace". Unsurprisingly it did nothing when deployed.
I'm currently editing my portal_normal.vm (server/tomcat/webapps/mytheme-theme/templates) testing if I can write on the file and see it on my browser. I tried putting a test comment "<!-- test -->" just to see if I can really write on the file. So I refreshed the file and hope I can see the comment I've added, but there we're none. So I continued refreshing (ctrl+r),\ and viewing the source code for almost an twenty minutes. After a while when I tried viewing it again it reflected in my source code. So I thought it was cached by either Liferay or my browser.
So I tried tweaking the comment adding version on it ("<!-- test v2 -->"), hoping to see changes. I checked it on another browser and the comment didn't update or include my added version. So I think Liferay is responsible for the issue.
this is what my portal-ext.properties contain:
auth.token.check.enabled=false
# Database settings
jdbc.default.jndi.name=jdbc/LiferayPool
#For removing captch
captcha.check.portal.create_account=false
session.enable.phishing.protection=false
default.regular.theme.id=my_site_WAR_my_theme
#Delete cookies while deleting session
session.enable.persistent.cookies=false
#redirecting null problem.
redirect.url.security.mode=mysite.com
journal.template.velocity.restricted.variables=
admin.email.from.name=Market.Travel Team
admin.email.from.address=admin#mysite.com
# Added because of the Error - No Hibernate Session bound to thread, and configuration does not allow creation of non-transactional one here
hibernate.current_session_context_class=thread
session.enable.url.with.session.id=false
and my portal-developer.properties
theme.css.fast.load=false
theme.images.fast.load=false
javascript.fast.load=true
javascript.log.enabled=true
layout.template.cache.enabled=false
browser.launcher.url=
combo.check.timestamp=true
freemarker.engine.cache.storage=soft:1
freemarker.engine.modification.check.interval=0
openoffice.cache.enabled=false
velocity.engine.resource.manager.cache.enabled=false
com.liferay.portal.servlet.filters.cache.CacheFilter=false
com.liferay.portal.servlet.filters.themepreview.ThemePreviewFilter=true
Addition: When I tried editing the css files I can see the changes fast. Just one reload the the changes appear. I think it is just in my velocity template that take some time or there's something wrong.
Liferay version: Liferay Portal Community Edition 6.0.6 CE
Thank You!
There is really no need to define your own portal-developer.properties. By adding -Dexternal-properties=portal-developer.properties to your JAVA_OPTS in tomcat/bin/setenv.(sh|bat) Liferay will use it's default developer settings, which are almost identical to what you have provided. However, I do not believe this is contributes to (or could resolve) your problem. More details here.
The developer properties do allow you to make live changes to the templates provided you are changing the right file. Due to the default context.xml Liferay provides to the deployed webapps, the webapps are copied/cached in tomcat/temp/{id}-webapp-name. This means if you change the template in webapp/mytheme then it may take tomcat a while to pick up on the change, if it notices the change at all (this will depend on the tomcat configuration). On the other hand, if you make a change in temp/1-mytheme it will show up immediately. Editing the files in the temp folder is probably not ideal, so...
How to fix this: (no specific order)
Prevent Tomcat from using the temp directory for your theme. Create a context.xml file for your theme.
<Context cachingAllowed="false"/>
This file should be placed in the META-INF folder of your
theme. If you are using the Liferay auto-deploy feature the
context.xml file may be clobbered, here, and here. If this
is the case you will need to find a work around that best suits your
needs, such as modifying the context.xml after the theme is deployed.
If you are using the Liferay Plugin-SDK the you can follow the fast plugin development guide for setting up your development environment.