Where the tomcat location when running application with broadleaf - java

I am trying to run a simple demo application of broadleaf. I am perfectly running the app, but I want to access it using any PC except this. I have to change some settings in tomcat but I am not able to find where tomcat is located and where the server.xml file located so I can do any kind of changes in server in order to make it running on any PC using public IP.

The latest version of Broadleaf (broadleaf-4.0.0-GA) uses tomcat7-maven-plugin for the demo site, which will run a embedded tomcat instance. If you need a custom server.xml please refer this question.
You can find tomcat-maven config in pom.xml of site project.
<plugin>
<groupId>org.apache.tomcat.maven</groupId>
<artifactId>tomcat7-maven-plugin</artifactId>
<configuration>
<path>/</path>
<port>${httpPort}</port>
<httpsPort>${httpsPort}</httpsPort>
</configuration>
</plugin>
Update this with required changes from the link above.

Related

Running a jersey project from command line

I have created a RESTful API using jersey that serves some GET endpoints. The thing though is that now I have to ship this project as github link and provide instructions to open and run the project from the command line. I completely build the project using Eclipse and have scoured the web for resources but have no clue as to how to get this done. Could someone care to download the project into their machines and help with instructions to run it from the command line. The README has the links to the public endpoints.
Without needing to actually deploy it your Tomcat instance, you can use the tomcat maven plugin (which is meant for development). It starts an embedded tomcat instance, so you can test your webapps. Just add the following to your pom.xml file
<build>
<finalName>SimpleRestApi</finalName>
<plugins>
...
<plugin>
<groupId>org.apache.tomcat.maven</groupId>
<artifactId>tomcat7-maven-plugin</artifactId>
<version>2.2</version>
<configuration>
<path>/</path>
</configuration>
</plugin>
</plugins>
</build>
Then from the command line you can just run
mvn tomcat7:run
And a server instance will start. You can then access
http://localhost:8080/api/courses
If you want to change the context path, just use <path>/SimpleRestApi</path>. Then you can access
http://localhost:8080/SimpleRestApi/api/courses

Maven facet version issue in web application

I am trying to create a maven web app, which will be part of my maven ear application. I tried creating web app from command line as well as from option within eclipse but both ways giving me error like "Dynamic Web Module 3.1 requires Java 1.7 or newer." I tried changing build path JDK to Java 1.8 and compiler level to 1.8 and saved but this didn't resolve the issue. When I do right click on project "maven update", the JDK again getting reset to old one not sure why it's not saving my changes. Is it issue with eclipse(I tried both LUNA and MARS version of eclipse)? How to resolve this issue as it's not letting me run my application from eclipse.
Also I am getting this access restriction warning "Access restriction: The type 'XmlElement' is not API (restriction on required library 'C:\Program Files\Java\jdk1.8.0_25\jre\lib\rt.jar')". If I remove JDK from build path and add it again it disappears. But when maven update is done error reappears. Please someone suggest me how to resolve these issues ?
Add following in pom.xml and do maven update
<build>
<plugins>
<plugin>
<artifactId>maven-compiler-plugin</artifactId>
<version>3.1</version>
<configuration>
<source>1.7</source>
<target>1.7</target>
</configuration>
</plugin>
</plugins>
</build>

How to analyze startup performance when using jetty-maven-plugin:run

I'm developing a java web application using java. To develop this application I'm using jetty as application server. Up to now the following version:
<plugin>
<groupId>org.mortbay.jetty</groupId>
<artifactId>jetty-maven-plugin</artifactId>
<version>7.4.2.v20110526</version>
</plugin>
After some changes in the application, I decide to change my jetty version with the following:
<plugin>
<groupId>org.eclipse.jetty</groupId>
<artifactId>jetty-maven-plugin</artifactId>
<version>9.2.13.v20150730</version>
</plugin>
But i noticed a performance lack during the execution of jetty:run.
I noticed that it loses almost a minute on
2015-10-07 12:59:11.863:INFO:oejs.Server:main: jetty-9.2.13.v20150730
How can I understand why?
Update 1
I think that my problem could be similar at the following:
Jetty startup delay due to scanning
then I thought to solve my problem using quick-start module, is this possible using jetty-embedded?
Your problem is indeed most probably caused by scanning. The link you've found has helpful info on it.
I have also just updated the documentation for the jetty-maven-plugin to make it clear that you can also set the patterns for container and webapp jar scanning with the plugin. The page is here: https://www.eclipse.org/jetty/documentation/current/jetty-maven-plugin.html#configuring-your-webapp but it will take the CI system a little while to push out the update (look for items on setting the containerIncludeJarPattern and the webInfIncludeJarPattern).
As the document already mentions under the goal "effectiveWebXml", using quickstart explicitly with the maven plugins is not really appropriate.
Jan

Application client using #EJB annotation and Maven on Glassfish

There is an example in NetBeans site how to create Application Client using simple projects (without Maven). There are 4 projects needed (EJB, EAR, Lib, Program). This tutorial is simple and works perfectly.
I want to ask how to do the same with Maven? I can't manage to get all the dependencies correctly so when I try to call EJB method, it gives me NullPointerException. Can anyone tell me, the key steps (preffered using NetBeans) that needs to be done? Because I am confused, about how many projects needs to be created? I know, that I need Application Project, EAR and EJB projects and thats it? What special configs needs to be written in these projects pom.xml files?
EDIT1:
I don't want to explicit JNDI I want to be able to use #EJB annotations.
Here are the steps:
Create the Java Class library for holding the interface class using Maven's folder of New Project's menu. Choose Java Application under Maven folder.
Create the Enterprise Application following the NB's tutorial. The only difference is that you have to use Maven's folder of New Project's menu
Build the class library
Ensure that the class library is a dependancy in the Enterprise Application.
Run the Enterpise Application. NB will deploy it to GF server
Create the Application Client by use of Maven's folder. Don't use the insert code NB's feature for injecting the Stateless EJB here, because it crashes (at least in my version: NB 7.2). Instead simply copy and paste the code shown in the tutorial. You don't need any deployment / ejb descriptor.
Modify the application client's POM in order to use maven-assembly-plugin for obtaining a jar with dependencies. If you don't to this step, the deploy will fail because GF is not able to load the interface class. Add the following lines to the plugins tab (change the main class as appropriate):
<plugin>
<artifactId>maven-assembly-plugin</artifactId>
<version>2.4</version>
<configuration>
<descriptorRefs>
<descriptorRef>jar-with-dependencies</descriptorRef>
</descriptorRefs>
<archive>
<manifest>
<mainClass>com.entapp.entappclient.Main</mainClass>
</manifest>
</archive>
</configuration>
<executions>
<execution>
<id>make-assembly</id>
<phase>package</phase>
<goals>
<goal>single</goal>
</goals>
</execution>
</executions>
</plugin>
Build the application client project with NB
Run the application client using the GF's application client command: appclient -jar EntAppClient-1.0-SNAPSHOT-jar-with-dependencies.jar
Useful link: Java EE's Buried Treasure: the Application Client Container by Jason Lee
Important Note
In order to deploy the client to oher JVMs you have to install the appclient on each client machine and set the target-server property. The appclient seems to have a very complicated structure, which you cannot produce simply by adding these lines (plus the EclipseLink persistence artifacts):
<dependency>
<groupId>org.glassfish.appclient</groupId>
<artifactId>gf-client</artifactId>
<version>3.1.1</version>
<type>pom</type>
<scope>compile</scope>
</dependency>
Adding these artifacts to the client compiles perfectly but the jar doesn't work. And this is understandable, since the file sun-acc.xml is missing (this file is necessary because contains the target-server property). Therefore I think that the only way is using the package-appclient script as per the linked documentation.
There is a useful EJB FAQ which mention about how to use the #EJB to access the remote EJB by using the ejb-ref together with sun-web.xml or now it is a glassfish-web.xml as the following link: -
What if I have multiple instances of the Appserver running and I want to access a Remote EJB component between them?
If you would like to compare between ejb-ref and ejb-local-ref, you may see further information at What is the relationship between #EJB and ejb-ref/ejb-local-ref?
I hope this may help.

Eclipse + Maven + Tomcat: testing web apps when the WAR is built with custom options

I am using Eclipse (Helios), with the "m2eclipse" plugin. I am working on a Maven-based web application project, which I test on a local Tomcat server that is setup inside Eclipse.
Generally, this works more or less great. "m2eclipse" can sometimes be flaky... but for the most part it keeps my POM and my Eclipse project settings in sync, and likewise keeps the deployed code current in Tomcat.
However, recently I've added a wrinkle. I have one JavaScript include file that needs to be different when going from the test environment to the real production environment. The differences are too significant to be cleanly handled by Maven filtering and token substitution. What I needed was to keep two separate files in my project, and only deploy the one appropriate for the build profile.
I accomplished this with some "targetPath" trickery in my Maven POM:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-war-plugin</artifactId>
<version>2.1.1</version>
<configuration>
<webResources>
<resource>
<!-- take the stuff from a "prod" or "non-prod" subdirectory and copy it one level up -->
<directory>src/main/webapp/js/${profile.name}</directory>
<targetPath>js</targetPath>
</resource>
<resource>
<!-- now don't deploy those profile-specific subdirectories -->
<directory>src/main/webapp/js</directory>
<excludes>
<exclude>prod</exclude>
<exclude>non-prod</exclude>
</excludes>
</resource>
</webResources>
</configuration>
</plugin>
This builds a perfect WAR file, which works fine when I deploy it some external Tomcat server. However, the problem is that Eclipse does NOT use that WAR file when running Tomcat inside of Eclipse. Instead, Eclipse works with an exploded version of the application, deployed to a cryptic directory like this:
<workspace>/.metadata/.plugins/org.eclipse.wst.server.core/tmp1/wtpwebapps/MyApp
... and apparently the app's files are copied to this location PRIOR TO Maven doing the little trickery shown above. Therefore, when testing locally inside of Eclipse, no JavaScript include is present at all in the expected location.
Is there a way around this problem? Maybe an Eclipse change, or a Maven change, to pull the file from Maven's "target" directory to Eclipse's "wtpwebapps" directory? Maybe there's another approach to solving the profile-specific-include-file issue altogether?
Starting from eclipse (Helios) 3.6 , the option “Java EE Module Dependencies” is replaced by “Deployment Assembly” option . You can configure which files to be deployed to the tomcat running inside of Eclipse in this “Deployment Assembly” option (Project Properties ---> Deployment Assembly )
You could deploy to the local server using the maven-cargo-plugin instead of running from Eclipse directly. This would then use your maven generated war.
If the tests you are doing can be automated, this could then be incorporated as part of an integration test suite that would be completely run by maven.

Categories