I used to use this code to serve static files from Comanche web server from within Pharo 1.2 image:
createService
| contentPath dirPath svc ma |
contentPath := 'htdocs'.
dirPath := FileDirectory default fullNameFor: contentPath.
svc := (HttpService on: self port)
name: 'seaside-' , self port greaseString.
ma := ModuleAssembly core.
ma alias: '/static' to: [
ma serverRoot: dirPath.
ma documentRoot: dirPath.
ma directoryIndex: 'index.html index.htm'.
ma serveFiles ].
ma addPlug: self.
svc plug: ma rootModule.
^ svc
The code if from http://samadhiweb.com/blog/2011.07.10.seaside.comanche.staticfiles.html
Unfortunately, this doesn't work any more on Pharo 1.3. ModuleAssembly class doesn't exist any more. So how do I setup comanche to serve static files?
Make sure that you have the full Komanche loaded. The prepared Seaside images use KomHttpServerLight which just contains the bare minimum web-server functionality Seaside requires. To get the full thing you need to load DynamicBindings, KomServices, KomHttpServer, and maybe other dependencies.
If you are running Seaside in that image, another option is to load the Seaside-Filesystem package from the Seaside30LGPL repository. You can then setup an 'external directory' handler that servers files from the disk.
We use this only for development though, so I do not know about its performance in deployment.
Related
When I run sonar-scanner on C project, it analyzes my submodules, but it also includes a "parent" configuration. What I mean:
sonar-project.properties
sonar.host.url=<host>
sonar.login=<token>
sonar.projectKey=PROJECT1
sonar.qualitygate.wait=true
sonar.sourceEncoding=UTF-8
sonar.scm.provider=git
sonar.verbose=true
sonar.modules=module1,module2
sonar.language=C
# if I enable below 3 lines it won't crash
#sonar.sources=.
#sonar.cfamily.build-wrapper-output=code_coverage_results
#sonar.cfamily.gcov.reportsPath=code_coverage_results
module1.sonar.projectName=Module1
module1.sonar.projectBaseDir=./module1
module1.sonar.sources=src
module1.sonar.tests=tests
module1.sonar.cfamily.build-wrapper-output=../code_coverage_results
module1.sonar.cfamily.gcov.reportsPath=../code_coverage_results
module1.sonar.exclusions=**/*.py,src/http-parser/**,obj/**,bin/**
module2.sonar.projectName=Module2
module2.sonar.projectBaseDir=./module2
module2.sonar.sources=src
module2.sonar.tests=tests
module2.sonar.cfamily.build-wrapper-output=../code_coverage_results
module2.sonar.cfamily.gcov.reportsPath=../code_coverage_results
sonar.cfamily.threads=10
sonar.cfamily.cache.enabled=true
sonar.cfamily.cache.path=sonar.cfamily.cache
sonar.scm.exclusions.disabled=true
code_coverage_results is a common folder for both submodules, basically can be separated.
What I see when run sonar-scanner -X:
------------- Run sensors on module Module1
... <analyzing> ...
------------- Run sensors on module Module2
... <analyzing> ...
------------- Run sensors on module PROJECT1
17:39:47.092 INFO: Sensor CFamily [cpp]
17:39:47.093 INFO: CFamily plugin version: 6.32.0.44918
17:39:47.093 ERROR:
he only way to get an accurate analysis of C/C++/Objective-C files is by using the SonarSource build-wrapper and setting the property "sonar.cfamily.build-wrapper-output" or by using Clang Compilation Database and setting the property "sonar.cfamily.compile-commands". None of these two options were specified.
If you don't want to analyze C/C++/Objective-C files, then prevent them from being analyzed by setting the following properties:
sonar.c.file.suffixes=-
sonar.cpp.file.suffixes=-
sonar.objc.file.suffixes=-
at com.sonar.cpp.plugin.CFamilySensor.process(CFamilySensor.java:236)
at com.sonar.cpp.plugin.CFamilySensor.execute(CFamilySensor.java:186)
at org.sonar.scanner.sensor.AbstractSensorWrapper.analyse(AbstractSensorWrapper.java:64)
at org.sonar.scanner.sensor.ModuleSensorsExecutor.execute(ModuleSensorsExecutor.java:85)
at org.sonar.scanner.sensor.ModuleSensorsExecutor.execute(ModuleSensorsExecutor.java:62)
at org.sonar.scanner.scan.SpringModuleScanContainer.doAfterStart(SpringModuleScanContainer.java:81)
at org.sonar.core.platform.SpringComponentContainer.startComponents(SpringComponentContainer.java:188)
at org.sonar.core.platform.SpringComponentContainer.execute(SpringComponentContainer.java:167)
at org.sonar.scanner.scan.SpringProjectScanContainer.scan(SpringProjectScanContainer.java:392)
When I uncomment the lines:
sonar.sources=.
sonar.cfamily.build-wrapper-output=code_coverage_results
sonar.cfamily.gcov.reportsPath=code_coverage_results
I am getting the error like:
File module2/src/Source.c can't be indexed twice. Please check that inclusion/exclusion patterns produce disjoint sets for main and test files
That is why I have to put
sonar.exclusions=**
in the beginning.
The question is: why it tries to analyze three modules instead of two?
I have the next structure:
root folder
Module1
Module2
CommonSources
*.sh, *.py files
sonar-project.properties
Thanks.
I try to setup Xdebug for shopware-docker without success.
VHOST_[FOLDER_NAME_UPPER_CASE]_IMAGE=ghcr.io/shyim/shopware-docker/6/nginx:php74-xdebug
After replacing your Folder Name and running swdc up Xdebug should be activated.
Which folder name should I place?
Using myname, the same name as in /var/www/html/myname, return error on swdc up myname:
swdc up myname
[+] Running 2/0
⠿ Network shopware-docker_default Created 0.0s
⠿ Container shopware-docker-mysql-1 Created 0.0s
[+] Running 1/1
⠿ Container shopware-docker-mysql-1 Started 0.3s
.database ready!
[+] Running 0/1
⠿ app_myname Error 1.7s
Error response from daemon: manifest unknown
EDIT #1
With this setup VHOST_MYNAME_IMAGE=ghcr.io/shyim/shopware-docker/6/nginx:php81-xdebug (versioned Xdebug) the app started:
// $HOME/.config/swdc/env
...
VHOST_MYNAME_IMAGE=ghcr.io/shyim/shopware-docker/6/nginx:php81-xdebug
But set a debug breakpoint (e.g. in index.php), nothing happens
EDIT #2
As #Alex recommend, i place xdebug_break() inside my code and it works.
Stopping on the breakpoint the debugger log aswers with hints/warnings like described in the manual:
...
Cannot find a local copy of the file on server /var/www/html/%my_path%
Local path is //var/www/html/%my_path%
...
click on Click to set up path mapping to open the modal
click inside modal select input Use path mapping (...)
input field File path in project response with undefined
But i have already set up the mapping like described in the manual, go to File | Settings | PHP | Servers:
Why does not work my mapping? Where failed my set up?
The path mapping needs to be between your local project path on your workstation and the path inside the docker containers. Without xDebug has a hard time mapping the breakpoints from PHPStorm to the actual code inside the container.
If mapping the path correctly does not work and if its a possibility for you, i can highly recommend switching to http://devenv.sh for your development enviroment. Shopware itself promotes this new enviroment in their documentation: https://developer.shopware.com/docs/guides/installation/devenv and provides an example on how to enable xdebug:
# devenv.local.nix File
{ pkgs, config, lib, ... }:
{
languages.php.package = pkgs.php.buildEnv {
extensions = { all, enabled }: with all; enabled ++ [ amqp redis blackfire grpc xdebug ];
extraConfig = ''
# Copy the config from devenv.nix and append the XDebug config
# [...]
xdebug.mode=debug
xdebug.discover_client_host=1
xdebug.client_host=127.0.0.1
'';
};
}
A correct path mapping should not be needed here, as your local file location is the same for XDebug and your PHPStorm.
I understand that createEJBstubs are necessary to create the stubs whenever it is accessed externally via. An Java Client (http://www-01.ibm.com/support/knowledgecenter/SSAW57_8.5.5/com.ibm.websphere.nd.doc/ae/rejb_3stubscmd2.html?lang=ko). And also, that the stubs that are created will be for the EJB3 interfaces that are available within the module. But how do they detect if a given interface/bean is of type EJB 3 and not 2.*. From the issue the I have faced below, it is not clear to me as to how this detection is done. Please help me to understand this so that I can resolve the issue that I am facing (below)-
DETAILED EXPLANATION OF MY ISSUE:
When I run createEJBStubs.bat C:\1\DEN\proj\target\proj.jar -updatefile C:\1\DEN\proj\target\proj.jar -verbose
I get the following error -
CNTR9241I: The C:\1\DEN\proj\target\proj-5.DEV-SNAPSHOT.jar Java archive (JAR) file has no level 3.0 enterprise beans with remote interfaces.
And when I run the same command using -verbose option, I get the following error -
createWarProcessingRootDir: enter
Root directory for war processing: C:\Users\w723521\AppData\Local\Temp\_tempWar_1096410607889881622
War explosion root: C:\Users\w723521\AppData\Local\Temp\_tempWar_1096410607889881622\warExpls
War primary input root: C:\Users\w723521\AppData\Local\Temp\_tempWar_1096410607889881622\warExpls\primary
War primary classpath root: C:\Users\w723521\AppData\Local\Temp\_tempWar_1096410607889881622\warExpls\primary\classPth
War primary workspace root: C:\Users\w723521\AppData\Local\Temp\_tempWar_1096410607889881622\warExpls\primary\wrkSpace
War alternate workspace root: C:\Users\w723521\AppData\Local\Temp\_tempWar_1096410607889881622\warExpls\alternate\wrkSpace
War alternate output file: C:\Users\w723521\AppData\Local\Temp\_tempWar_1096410607889881622\warExpls\alternateOutputWar.war
War embedded in ear root: C:\Users\w723521\AppData\Local\Temp\_tempWar_1096410607889881622\warExpls\embInEar
createWarProcessingRootDir: exit
Dumping input parameters:
parameter 1 = C:\1\DEN\proj\target\proj-5.DEV-SNA
PSHOT.jar
parameter 2 = -updatefile
parameter 3 = C:\1\DEN\proj\target\proj-5.DEV-SNA
PSHOT.jar
parameter 4 = -trace
Processing the C:\1\DEN\proj\target\proj-5.DEV-SNAPSHOT.jar input file.
checkEJBVersion - jar name is C:\1\DEN\proj\target\proj-5.DEV-SNAPSHOT.jar
The output file name is C:\Users\w723521\AppData\Local\Temp\ejb3093395338317385883.jar
copyArchiveEntriesAndStubs(null,C:\1\DEN\proj\target\proj-5.DEV-SNAPSHOT.jar,C:\Users\w723521\AppData\Local\Temp\ejb3093395338317385883.jar,false)
Main output archive file (no pre-existing stubs) is C:\Users\w723521\AppData\Local\Temp\ejb3093395338317385883.jar
Preexisting stubs archive file is ejb5694574801473018226.jar
Writing non-stub entry MANIFEST.MF
Writing non-stub entry TestLocal.class
Writing non-stub entry TestRemote.class
Classloader updated for -cp null
Classloader updated for jar C:\1\DEN\proj\target\proj-5.DEV-SNAPSHOT.jar
getMetaData - entry
metadataComplete setting is false
findRemoteInterfaces
List of interfaces are: null
Number of pre-existing stubs = 0
CNTR9241I: The C:\1\DEN\proj\target\proj-5.DEV-SNAPSHOT.jar Java archive (JAR) file has no level 3.0 enterprise beans with remote interfaces.
Starting process of deleting workspace files...
Done with process of deleting workspace files...
Command Successful
I am not able to understand why it says that no local and remote interfaces are of EJB3 even though the bean classes created using EJB3 annotations
#Remote
public interface TestRemote {
public void test();
}
#Remote
public interface TestRemote {
public void test();
}
How does the script detect if a given interface is EJB3 or not? (based on the output that I have obtained it is not as clear as I expected it to be)
proj-5.DEV-SNAPSHOT.jar would need to somehow specify both an EJB and its remote interface. For example, if ejb-jar.xml is used, a <session> with a <remote>pkg.TestRemote</remote>. For another example, if some class in the JAR is annotated with #Stateless and #Remote(TestRemote.class).
I want to prepare my application to be compatible with many databases types. To try it i've used H2, MySql and Postgresql. So 'ive added into build.sbt :
"mysql" % "mysql-connector-java" % "5.1.35",
"org.postgresql" % "postgresql" % "9.4-1201-jdbc41"
and i've added conf/prod.conf with all configuration without database configuration, and 3 files:
conf/h2.conf
include "prod.conf"
db.h2.driver=org.h2.Driver
db.h2.url="jdbc:h2:mem:dontforget"
db.h2.jndiName=DefaultDS
ebean.h2="fr.chklang.dontforget.business.*"
conf/mysql.conf
include "prod.conf"
db.mysql.driver=com.mysql.jdbc.Driver
db.mysql.jndiName=DefaultDS
ebean.mysql="fr.chklang.dontforget.business.*"
conf/postgresql.conf
include "prod.conf"
db.postgresql.driver=org.postgresql.Driver
db.postgresql.jndiName=DefaultDS
ebean.postgresql="fr.chklang.dontforget.business.*"
Add to it i've three folders into conf/evolutions with
evolutions/h2
evolutions/mysql
evolutions/postgresql
with these things user can start my application with this command :
-Dconfig.file=dontforget-conf.conf -DapplyEvolutions.default=true -Dhttp.port=10180 &
And this conf file is
include "postgresql.conf"
db.postgresql.url="jdbc:postgresql:dontforget"
db.postgresql.user=myUserName
db.postgresql.password=myPassword
But with this configuration, when my application try to connect to DB :
The default EbeanServer has not been defined? This is normally set via the ebean.datasource.default property. Otherwise it should be registered programatically via registerServer()]]
So i've tried to add, into my configuration :
ebean.datasource.default=postgresql
but when i add it i've :
Configuration error: Configuration error[Configuration error[]]
at play.api.Configuration$.play$api$Configuration$$configError(Configuration.scala:94)
at play.api.Configuration.reportError(Configuration.scala:743)
at play.Configuration.reportError(Configuration.java:310)
at play.db.ebean.EbeanPlugin.onStart(EbeanPlugin.java:56)
at play.api.Play$$anonfun$start$1$$anonfun$apply$mcV$sp$1.apply(Play.scala:91)
at play.api.Play$$anonfun$start$1$$anonfun$apply$mcV$sp$1.apply(Play.scala:91)
at scala.collection.immutable.List.foreach(List.scala:383)
at play.api.Play$$anonfun$start$1.apply$mcV$sp(Play.scala:91)
at play.api.Play$$anonfun$start$1.apply(Play.scala:91)
at play.api.Play$$anonfun$start$1.apply(Play.scala:91)
at play.utils.Threads$.withContextClassLoader(Threads.scala:21)
at play.api.Play$.start(Play.scala:90)
at play.core.StaticApplication.<init>(ApplicationProvider.scala:55)
at play.core.server.NettyServer$.createServer(NettyServer.scala:253)
at play.core.server.NettyServer$$anonfun$main$3.apply(NettyServer.scala:289)
at play.core.server.NettyServer$$anonfun$main$3.apply(NettyServer.scala:284)
at scala.Option.map(Option.scala:145)
at play.core.server.NettyServer$.main(NettyServer.scala:284)
at play.core.server.NettyServer.main(NettyServer.scala)
Caused by: Configuration error: Configuration error[]
at play.api.Configuration$.play$api$Configuration$$configError(Configuration.scala:94)
at play.api.Configuration.reportError(Configuration.scala:743)
at play.api.db.BoneCPApi.play$api$db$BoneCPApi$$error(DB.scala:271)
at play.api.db.BoneCPApi$$anonfun$getDataSource$3.apply(DB.scala:438)
at play.api.db.BoneCPApi$$anonfun$getDataSource$3.apply(DB.scala:438)
at scala.Option.getOrElse(Option.scala:120)
at play.api.db.BoneCPApi.getDataSource(DB.scala:438)
at play.api.db.DB$$anonfun$getDataSource$1.apply(DB.scala:142)
at play.api.db.DB$$anonfun$getDataSource$1.apply(DB.scala:142)
at scala.Option.map(Option.scala:145)
at play.api.db.DB$.getDataSource(DB.scala:142)
at play.api.db.DB.getDataSource(DB.scala)
at play.db.DB.getDataSource(DB.java:25)
at play.db.ebean.EbeanPlugin.onStart(EbeanPlugin.java:54)
So i don't understand how i can do it.
YES!!! I've found it! After debug mode (etc...)
There was 2 problems.
First problem : I must add a key into my application.conf :
ebeanconfig.datasource
For me (for exemple), postgresql.conf is modified to :
db.postgresql.driver=org.postgresql.Driver
db.postgresql.jndiName=DefaultDS
ebean.postgresql="fr.chklang.dontforget.business.*"
ebeanconfig.datasource.default=postgresql
Second problem : include into play 2.3.x don't works because conf folder isn't added into classpath (ref Load file from '/conf' directory on Cloudbees ) so we must concat prod.conf, postgresql.conf and dontforget.conf into an only single file.
I hope i have helped any other developper...
I've been unable to find any easy way of figuring out the version string for a WAR file deployed with Tomcat 7 versioned naming (ie app##version.war). You can read about it here and what it enables here.
It'd be nice if there was a somewhat more supported approach other than the usual swiss army knife of reflection powered ribcage cracking:
final ServletContextEvent event ...
final ServletContext applicationContextFacade = event.getServletContext();
final Field applicationContextField = applicationContextFacade.getClass().getDeclaredField("context");
applicationContextField.setAccessible(true);
final Object applicationContext = applicationContextField.get(applicationContextFacade);
final Field standardContextField = applicationContext.getClass().getDeclaredField("context");
standardContextField.setAccessible(true);
final Object standardContext = standardContextField.get(applicationContext);
final Method webappVersion = standardContext.getClass().getMethod("getWebappVersion");
System.err.println("WAR version: " + webappVersion.invoke(standardContext));
I think the simplest solution is using the same version (SVN revision + padding as an example) in .war, web.xml and META-INF/MANIFEST.MF properties files, so you could retrieve the version of these files later in your APP or any standard tool that read version from a JAR/WAR
See MANIFEST.MF version-number
Another solution described here uses the path name on the server of the deployed WAR. You'd extract the version number from the string between the "##" and the "/"
runningVersion = StringUtils.substringBefore(
StringUtils.substringAfter(
servletConfig.getServletContext().getRealPath("/"),
"##"),
"/");
Starting from Tomcat versions 9.0.32, 8.5.52 and 7.0.101, the webapp version is exposed as a ServletContext attribute with the name org.apache.catalina.webappVersion.
Link to the closed enhancement request: https://bz.apache.org/bugzilla/show_bug.cgi?id=64189
The easiest way would be for Tomcat to make the version available via a ServletContext attribute (org.apache.catalina.core.StandardContext.webappVersion) or similar. The patch to do that would be trivial. I'd suggest opening an enhancement request in Tomcat's Bugzilla. If you include a patch then it should get applied fairly quickly.