moqui deploy in a non-ROOT folder in tomcat - moqui

I'm trying to deploy moqui 1.6.3 and runtime in apache-tomcat-8.0.12 in a non-ROOT folder.
I have done below modification in build.gradle:
task deployTomcatRuntime << {
delete file(tomcatHome + '/runtime'); delete file(tomcatHome + '/webapps/myweb'); delete file(tomcatHome + '/webapps/myweb.war')
copy { from file(plusRuntimeName); into file(tomcatHome + '/webapps'); rename(plusRuntimeName, 'myweb.war') } }
After commands: gradle cleanAll, gradle buid, gradle addRuntimeTomcat, myweb.war is deployed in tomcat webapp folder successfully.
After that, I use "http://localhost:8080/myweb" to open the root page, and the login page comes "http://localhost:8080/myweb/Login".
And then I give the username and password and click login, but I'm still in login page without any error.
If I change myweb.war to ROOT.war, it will work fine to log into the system.
I put some debug in framework code, and find that system create a new ExecutionContextImpl when redirect from Login to root page. Below is the place I put the logs:
ExecutionContextImpl getEci() {
logger.debug("===========getExecutionContext:"+activeContext.get())
// the ExecutionContextImpl cast here looks funny, but avoids Groovy using a slow castToType call
ExecutionContextImpl ec = (ExecutionContextImpl) activeContext.get()
if (ec != null) return ec
if (logger.traceEnabled) logger.trace("Creating new ExecutionContext in thread
[${Thread.currentThread().id}:${Thread.currentThread().name}]")
if (!(Thread.currentThread().getContextClassLoader() instanceof StupidClassLoader))
Thread.currentThread().setContextClassLoader(cachedClassLoader)
ec = new ExecutionContextImpl(this)
this.activeContext.set(ec)
return ec
}
impl.context.ExecutionContextFactoryImpl []
===========getExecutionContext:ExecutionContext in tenant DEFAULT
--- 2016-05-02 23:02:51.176 [nio-8080-exec-4] DEBUG impl.context.ExecutionContextFactoryImpl []
===========getExecutionContext:null
--- 2016-05-02 23:02:51.177 [nio-8080-exec-4] DEBUG impl.context.ExecutionContextFactoryImpl []
===========getExecutionContext:ExecutionContext in tenant DEFAULT
It looks like ThreadLocal has problem in a non-ROOT folder in tomcat, but not sure.
Have anybody deployed moqui in a non-ROOT folder?

Related

How to Pass Application URL through Command Line with Cucumber Feature file via cucumber options?

Currently we have 9 different URLs in our requirement scope and its implemented as Config file Application URL.
Every time if I have to change Application URL, I need to manually update the URL in config file and then I can execute require scenario, which is tedious task.
I would like to pass Application URL in my command line argument.
Current configuration of Config file.
#application.url=http://node-1.nginx.portal.da-1.can.qa.aws.com
#http://node-1.nginx.portal.da-1.QA1.aws.com
#http://node-1.nginx.portal.da-1.QA2.qa.aws.com
#http://node-1.nginx.portal.da-1.QA3.qa.aws.com
#http://node-1.nginx.portal.da-1.QA4.qa.aws.com
#http://node-1.nginx.portal.da-1.QA5.qa.aws.com
#http://node-1.nginx.portal.da-1.QA6.qa.aws.com
public void LaunchApplication() {
LOG.info("Launching web application URL: " + CONFIG.getProperty("application.url"));
driver.manage().deleteAllCookies();
driver.get(CONFIG.getProperty("application.url"));
}
Gonna make the assumption that you are running your selenium cucumber tests as a maven project.
Using maven you can create as many maven system properties as you like, I do this a lot for my mvn commands for my CI/CD build pipelines using Jenkins.
Here is what I would do
Update your method by adding a system property variable:
public void LaunchApplication() {
String appUrl = System.getProperty(applicationUrl);
LOG.info("Launching web application URL: " + appUrl);
driver.manage().deleteAllCookies();
driver.get(appUrl);
}
Pass the property as your mvn command, for example:
mvn test -Pcucumber -Dcucumber.options="--tags #app-smoke-001" -Dbrowser=chrome -Dclose_browser=yes -DapplicationUrl="http://node-1.nginx.portal.da-1.can.qa.aws.com"

IntelliJ run vs running a jar, with a Springboot Kotlin, Multi module Gradle project with Social Oauth2

TL;DR: Why does everything run fine when started via IntelliJ, and why is it broken when call java -jar app.jar. And how do I fix this?
Alright, I have some issues with a backend I am trying to dockerize. I have an application created with Spring Boot (1.4.2.RELEASE) following the Spring Oauth (2.0.12.RELEASE) guide on their page. I follow the Gradle version, since I prefer Gradle over Maven. Also I am using Kotlin instead of Java. Everything is fine, I start via IntelliJ my backend with static front end, I can login via Facebook (and Google and Github), I receive a nice Principal witch holds al the information I need, and I can modify Spring Security to authorize and permit endpoints. So far so good.
Now for the bad part, when I run either ./gradlew clean build app:bootrun or ./gradlew clean build app:jar and run the jar via java -jar (like I will do in my Docker container), my backend comes up. My static front end pops up. Now I want to login via Facebook, I end up on the Facebook login page, I enter my credentials, and... nothing!
I end up back on my homepage, not logged in, no log messages that mean anything to me, just silence. The last thing I see in the log is:Getting user info from: https://graph.facebook.com/me
This Url will give me in my browser:
{
"error": {
"message": "An active access token must be used to query information about the current user.",
"type": "OAuthException",
"code": 2500,
"fbtrace_id": "GV/58H5f4fJ"
}
}
When going to this URL via an IntelliJ start, it will give me credential details. Obviously something is going wrong, but I have no clue what. Especially since a run from IntelliJ works fine. There is some difference between how the jar is started, and how IntelliJ's run config works, but I have no clue where to search for what. I could post trace logging, or all my Gradle files, but perhaps thats too much info to put in 1 question. I will defenitly update this question if someone needs some more details :)
The structure outline of this project is as follows:
root:
- api: is going to be opensourced later, contains rest definitions and DTOs.
- core: contains the meat. Also here is included in the gradle file
spring-boot-starter, -web, -security, spring-security-oauth2, and some jackson stuff.
- rest: contains versioned rest service implementations.
- app: contains angular webjars amongst others, the front end, and
my `#SpringBootApplication`, `#EnableOAuth2Client`
and the impl of `WebSecurityConfigurerAdapter`.
Why does everything run fine when started via IntelliJ, and why is it broken using bootRun or the jar artefact. And how do I fix this?
I found it, the problem was not Multi module Graldle, Spring boot, or Oauth2 related. In fact it was due to a src set config of Gradle, where Java was supposed to be in a Java src set folder, and Kotlin in a Java src set folder:
sourceSets {
main.java.srcDirs += 'src/main/java'
main.kotlin.srcDirs += 'src/main/kotlin'
}
As Will Humphreys stated in his comment above, IntelliJ takes all source sets, and runs the app. However, when building the jar via Gradle, these source sets are stricter. I had a Java file in my Kotlin src set, which is no problem for IntelliJ. But the jar created by Gradle takes into account the source sets as defined in the build.gralde file, which are stricter.
I found my missing bean issue with the code below:
#Bean
public CommandLineRunner commandLineRunner(ApplicationContext ctx) {
return args -> {
System.out.println("Let's inspect the beans provided by Spring Boot:");
String[] beanNames = ctx.getBeanDefinitionNames();
Arrays.sort(beanNames);
for (String beanName : beanNames) {
System.out.println(beanName);
}
};
}
The Bean I missed was called AuthenticationController, which is a #RestController, and kinda crucial for my authentication code.

F4 IDE gives "Invalid Uri scheme for local file" when running Fantom app

I started a very simple project using Xored's F4 IDE for Fantom. The first few times I ran it there was no error, but I started adding dependencies (fanbatis) and at some point the error below starting showing up every time I run a test or a dummy Hello World app.
[23:44:18 22-Nov-13] [err] [pathenv] Cannot parse path: C:\dev\f4workspace\auth\bin\fan
sys::ArgErr: Invalid Uri scheme for local file: c:\dev\f4workspace\auth\bin\fan/
fan.sys.LocalFile.uriToFile (LocalFile.java:64)
fan.sys.File.make (File.java:26)
util::PathEnv.parsePath (PathEnv.fan:47)
fan.sys.List.each (List.java:555)
util::PathEnv.parsePath (PathEnv.fan:43)
util::PathEnv.make$ (PathEnv.fan:22)
util::PathEnv.make (PathEnv.fan:20)
java.lang.reflect.Method.invoke (Unknown)
fan.sys.Method.invoke (Method.java:559)
fan.sys.Method$MethodFunc.callList (Method.java:198)
fan.sys.Type.make (Type.java:246)
fan.sys.ClassType.make (ClassType.java:110)
fan.sys.Type.make (Type.java:236)
fan.sys.Sys.initEnv (Sys.java:447)
fan.sys.Sys. (Sys.java:224)
fanx.tools.Fan.execute (Fan.java:28)
fanx.tools.Fan.run (Fan.java:298)
fanx.tools.Fan.main (Fan.java:336)
Hello, World!
It is more a nuisance at the moment because the tests and the dummy app still run. I created another project, copying all the source code adding class by class and testing after each change and the error never occurred. Any ideas please?
That's an interesting issue!
tl/dr: you have an empty project 'auth' in your workspace, either create some dummy class inside it or go to Run -> Run configurations, find your launch config and uncheck project without sources on 'Projects' tab.
In order to keep your Fantom installation clean from projects in a workspace, F4 puts built pods into project/bin/fan/lib/fan. When F4 launches projects from workspace, it uses PathEnv and builds FAN_ENV_PATH by joining paths to Fantom installation and bin/ folders in projects in workspace.
When Fantom runtime analyzes FAN_ENV_PATH, at first it interprets a path as native OS path, but if dir does not exist, it attempts to interpret it as file URI, here's relevant part of PathEnv source:
path.split(File.pathSep[0]).each |item|
{
if (item.isEmpty) return
dir := File.os(item).normalize
if (!dir.exists) dir = File(item.toUri.plusSlash, false).normalize
if (!dir.exists) { log.warn("Dir not found: $dir"); return }
The problem code is item.toUri – On Mac OS X and Linux this is parsed as an URI without scheme with path only, so if directory does not exist, this code just prints a warning in a console.
But on Windows, because of disk name in path, disk name is interpreted as scheme:
fansh> "C:\\Users".toUri { echo(path); echo(scheme) }
[\Users]
c
fansh> "/Users".toUri { echo(path); echo(scheme) }
[Users]
null
And then File constructor fails, because expects either 'file' scheme, or null scheme:
public static java.io.File uriToFile(Uri uri)
{
if (uri.scheme() != null && !uri.scheme().equals("file"))
throw ArgErr.make("Invalid Uri scheme for local file: " + uri);
return new java.io.File(uriToPath(uri));
}
I've created an issue here, so that F4 would automatically skip empty projects when building FAN_ENV_PATH – https://github.com/xored/f4/issues/25.
I thought the problem had something to do with the forward slash at the end of path as shown in this line of the error message
Invalid Uri scheme for local file: c:\dev\f4workspace\auth\bin\fan/
However, I found that such path didn't exist. I manually created both the bin and the fan folders and the error disappeared. To be honest I don't really know why F4 needs and checks for that folder because so far it hasn't written any file in it.

Apache Directory LDAP API - getting up and running

When I try and run a test using the Apache LDAP API, I am getting the following error. I set up a Maven project , and my pom.xml has many dependencies for the Apache Directory server and API artifacts. My code (which I copied and pasted an example, just to get up and running, so that I can explore) all builds fine. However, when I run it (as a Junit Test), I get the following....
Can anyone help me? maybe even just provide an example of where the Apache LDAP API is being used successfully, and maybe give me the pom.xml with the correct dependencies also? (The apche LDAP API documentation seems to be out of date).
I am currently starting the test using the embedded Apache Directory server, using the following...
#RunWith(FrameworkRunner.class)
#CreateLdapServer(transports =
{
#CreateTransport(protocol = "LDAP") ,
#CreateTransport(protocol = "LDAPS") })
// disable changelog, for more info see DIRSERVER-1528
#CreateDS(enableChangeLog = false, name = "PasswordPolicyTest")
public class PasswordPolicyIT extends AbstractLdapTestUnit
{ .......etc }
So, therefore, an alternative approach, is that if I tailor some of the tests to just connect to a local Directory Server instance that I have running on my machine. I assume that this would stop the error messages that I am getting below..Again, if anyone could provide a code snippet there, it would be useful..
Many Thanks
> 2013-06-20 16:05:10 ERROR FrameworkRunner:287 - Problem locating LDIF
> file in schema repository Multiple copies of resource named
> 'schema/ou=schema/cn=apachemeta/ou=matchingrules/m-oid=1.3.6.1.4.1.18060.0.4.0.1.3.ldif'
> located on classpath at urls
> jar:file:/Users/rk/.m2/repository/org/apache/directory/api/api-ldap-client-all/1.0.0-M17/api-ldap-client-all-1.0.0-M17.jar!/schema/ou%3dschema/cn%3dapachemeta/ou%3dmatchingrules/m-oid%3d1.3.6.1.4.1.18060.0.4.0.1.3.ldif
> jar:file:/Users/rk/.m2/repository/org/apache/directory/shared/shared-ldap-schema-data/1.0.0-M7/shared-ldap-schema-data-1.0.0-M7.jar!/schema/ou%3dschema/cn%3dapachemeta/ou%3dmatchingrules/m-oid%3d1.3.6.1.4.1.18060.0.4.0.1.3.ldif
> jar:file:/Users/rk/.m2/repository/org/apache/directory/server/apacheds-all/2.0.0-M12/apacheds-all-2.0.0-M12.jar!/schema/ou%3dschema/cn%3dapachemeta/ou%3dmatchingrules/m-oid%3d1.3.6.1.4.1.18060.0.4.0.1.3.ldif
You need to exclude the shared-ldap-schema-data dependency from apacheds-all. Take a look at this comment

SpecsFor.Mvc Build failed

Attempting to test out SpecsFor.Mvc, unforunitly I'm getting this strange build error when I try to run a test.
Running in both my own project and the SpecsFor latest source I get a "Build failed." ApplicationException from the IISTestRunnerAction class. The following is from the log file but its beyond my understanding.
Using visual studio 2012 pro and IIS Express 8.0
The following is from the log file:
Using "VSMSDeploy" task from assembly "C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v11.0\Web\Microsoft.Web.Publishing.Tasks.dll".
Task "VSMSDeploy"
Package/Publish task Microsoft.Web.Publishing.Tasks.VSMSDeploy load assembly Microsoft.Web.Deployment, Version=9.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35
Package/Publish task Microsoft.Web.Publishing.Tasks.VSMSDeploy load assembly Microsoft.Web.Delegation, Version=7.1.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35
Starting Web deployment task from source: manifest(C:\Users\Chris\Desktop\SpecsFor-master\SpecsFor.Mvc.Demo\obj\Test\Package\SpecsFor.Mvc.Demo.SourceManifest.xml) to Destination: package(C:\Users\Chris\Desktop\SpecsFor-master\SpecsFor.Mvc.Demo\obj\Test\Package\SpecsFor.Mvc.Demo.zip).
C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v11.0\Web\Microsoft.Web.Publishing.targets(4007,5): error : Web deployment task failed. (The type initializer for 'Microsoft.Web.Deployment.DeploymentManager' threw an exception.)
Package failed.
Done executing task "VSMSDeploy" -- FAILED.
UPDATE
Here is the AssemblyStartup
[SetUpFixture]
public class AssemblyStartup
{
private SpecsForIntegrationHost _host;
[SetUp]
public void SetupTestRun()
{
var config = new SpecsForMvcConfig();
//SpecsFor.Mvc can spin up an instance of IIS Express to host your app
//while the specs are executing.
config.UseIISExpress()
//To do that, it needs to know the name of the project to test...
.With(Project.Named("SpecsForTesting"))
//And optionally, it can apply Web.config transformations if you want
//it to.
.ApplyWebConfigTransformForConfig("Debug");
//In order to leverage the strongly-typed helpers in SpecsFor.Mvc,
//you need to tell it about your routes. Here we are just calling
//the infrastructure class from our MVC app that builds the RouteTable.
config.BuildRoutesUsing(r => SpecsForTesting.RouteConfig.RegisterRoutes(r));
//SpecsFor.Mvc can use either Internet Explorer or Firefox. Support
//for Chrome is planned for a future release.
config.UseBrowser(BrowserDriver.Chrome);
//Does your application send E-mails? Well, SpecsFor.Mvc can intercept
//those while your specifications are executing, enabling you to write
//tests against the contents of sent messages.
config.InterceptEmailMessagesOnPort(13565);
//The host takes our configuration and performs all the magic. We
//need to keep a reference to it so we can shut it down after all
//the specifications have executed.
_host = new SpecsForIntegrationHost(config);
_host.Start();
}
//The TearDown method will be called once all the specs have executed.
//All we need to do is stop the integration host, and it will take
//care of shutting down the browser, IIS Express, etc.
[TearDown]
public void TearDownTestRun()
{
_host.Shutdown();
}
}
I had this error come up, and it turned out that I had added a new project to my solution. The new project did not include the same configurations i.e. the solution was running of "Test" but my new project only had the default ones of debug and release.
Go into the Configuration Manager and check that all the projects in your solution have the same configurations in place.
If you are looking for the build log, it is outputted to Console by default. Here is how to capture Console output:
var stringWriter = new StringWriter();
try
{
// Build log is sent to console, redirect output to StringWriter
Console.SetOut(stringWriter);
_host.Start();
}
catch (ApplicationException ex)
{
throw new Exception("Build failed. Output: " + stringWriter, ex);
}
It looks like the error is actually from MSDeploy, which SpecsFor.Mvc uses internally through MSBuild to publish your site for testing. Here's the same error directly from MSDeploy: Web deployment task failed. (The type initializer for 'Microsoft.Web.Deployment.DeploymentManager' threw an exception.). Unfortunately there doesn't seem to be a resolution.
Can you try deploying your site manually? This command line should do the trick:
msbuild /p:DeployOnBuild=true;DeployTarget=Package;_PackageTempDir=;AutoParameterizationWebConfigConnectionStrings=false;Platform=AnyCPU
Let me know if that works or if it blows up with a similar error.
I had exactly the same issue trying to get SpecsForMvc working on a Bamboo remote build agent. Matt Honeycutt's answer pointed me in the right direction. I just had to install MS Web Deploy 3.5 on the VM running the agent to fix this error.
I also needed to install IIS Express 8 on the same VM to allow the SpecsForIntegrationHost to spin up a site in.
arni's answer helped me better diagnose the problem, but also caused me some issues later down the line, when I was having trouble with permissions trying to connect to a remote SQL Server from the tested app. These exceptions were not caught by the ApplicationException catch block as they were of class SystemException. They got handled by the global exception handler, bypassing the end of test cleanup which was supposed to shut down the integration host. This left the IIS Express instance for each test running in the background. (As I can't comment on arni's answer, I've added my amended code here)
var stringWriter = new StringWriter();
try
{
// Build log is sent to console, redirect output to StringWriter
Console.SetOut(stringWriter);
_host.Start();
}
catch (Exception ex)
{
_integrationHost.Shutdown();
throw new Exception("Build failed. Output: " + stringWriter, ex);
}