I don't remember where I've red that, for gwt 2.7.0 sdk maven module must consist of 3 submodules: server, shared and client.
But on github I've seen different projects for 2.7
Can any one can answer me this question?
Code in server - runs in servlet container (for example access to DB)
Code in shared - can be used in client and in server codebase (for example DTOs - data transfer objects)
Code in client - will be compiled to JavaScript and runs in browser
So you must decide yourself how much modules you need. If you code is a simple widget that does not communicate with server, you need only client module
Related
I have three distinct heavily coded web-projects; two of them (new) is newly developed with Java/Script, the other (old) one with PHP. All of these three project has some common resources like HTML containers, Element classes etc. Moreover, one of the Java project is Main Project that call the other two projects.
The issue is that Java projects run on a Tomcat Server, PHP needs to run on Apache Server. And PHP project has some location paths for resources like "../SomeResourceFolder/somePage.php". However, when I run Main Project (Java) on Tomcat Server which has "localhost:8080" I could not reach PHP project which is run on Apache Server with "localhost:80", even if I accomplish to reach PHP project, PHP one fails to reach common resources in Tomcat.
I solve the issue a little bit unconvincing way with JavaBridge and Quercus; they help to run PHP on Tomcat Server. However, again I have some path problems.
Actually these projects runs on production with load-balancer which direct request to related server. I try to simulate this or at least run PHP on Apache, Java on Tomcat and connect them somehow. How can I construct this kind of structure without cross domain problems?
I solve the issue by using "Tomcat Connector". It connect Apache and Tomcat by defining Tomcat as worker, and send HTTP request with given path configuration.
You can follow guide given by Nanyang University. In guide Tomcat 6 and Apache 2.2 are used but I used Tomcat 7 and Apache 2.4 with the same directions.
I want to add a mule flow developed in one project to another project i.e wanted to use the flow created in one project in another project like flow reference.
If I am understood your requirement correctly, Your trying to access one mule flow that resides in one project from another project mule flow.
If yes, then you can't use mule flow reference component to achieve this instead you can VM component.
Mule introduced concept of Domains in mule run time version 3.5 and mule anypoint studio with run time version 3.6.
With Domains concept you can access flows across projects using VM component. Go through the below Mule documentation link that will clearly tell you on how to
https://docs.mulesoft.com/mule-user-guide/v/3.7/shared-resources
1) How to create Domain application.
2) How to create Shared components in Domain.
3) Creating application that uses shared components in Domains.
4) Deployment of Domains etc ..
You can manage your projects via Maven and package reusable flows. Mule can then use any of these flows imported on the classpath: https://docs.mulesoft.com/mule-user-guide/v/3.5/modularizing-your-configuration-files-for-team-development
TL;DR
Is it necessary to have an HTTP router module when deploying an EJB module containing web service implementations to WebSphere 7?
If so, is there a way to create/manage it without relying on IBM-specific files?
I have an application that is being restructured so that it can be built Maven. Currently, I am using was6-maven-plugin's endptEnabler goal to build an HTTP router module for an EJB module that contains some web services. This works well, but I just found out that the build machine we'll get to use won't actually have WebSphere installed on it. In the past this wouldn't have been a problem, since the router module had been developed manually by someone clicking a "Generate Router Module" button in RAD and then actually checking in the generated code into source control. With the Maven-centric build process, we thought it would be better to generate the module during the build process.
So now I am stuck: generating the router module via Maven seems a much cleaner approach but won't work on the build machine. I have a few options:
Extract the generated WAR and add it to our enterprise repository and then create a dependency from my EJB to the WAR. I really don't like this, but it would probably work.
Go back to having a realized HttpRouterModule project in the workspace. The problem with this is that the IBM-specific binding files have valid module IDs for my server, but I don't know if they'd cause problems on someone else's which is why I'd rather generate these files from Maven.
Keep generating the router module with Maven, but find a way to generate it in a way such that there is no WebSphere dependency.
I'd prefer to go with the third option, but I'm not sure how I can generate the module and the binding files in generic way such that it will still be recognized by WebSphere.
I'm open to hearing about other options too...
As far as I know you need http router module. From my experience I was also unable to create the module manually. Is there no way you could install was7 dev server on your build machine? I believe it is free download from IBM.
All my research so far indicates that this is necessary in WebSphere 7, and in earlier versions. It looks like WebSphere 8 does not require HTTP router modules. We're going with the second option, as the build server won't be able to generate the router modules on its own.
Not ideal, but once we move to WAS8 this won't be necessary.
I was looking for similar problems and, of course, there exists many but I would like to know if someone uses a similar project like us and how you have deal with it.
We are working on a project where:
- Client side is completely based on JavaScript, with Dojo Toolkit framework, which makes AJAX request to our server side.
- Server side based on Java+Spring+Hibernate which implements some REST API.
We are managin the two parts as different projects, that is, for the server side we are using maven and for each change our CI server runs tests.
The important step here is we can configura maven with profiles so the CI can create a package ready for pre-production or production environments using different property files.
The client side is a bunch (with a nice structure) of HTML, CSS and JavaScript files. Like the server side, on the client side we have property file to point the client to the right place (like the development server side).
The question is: which could be the best way on this scenario to automate the client side?development? I mean, run JavaScript tests on CI and autodeploy to the right environment using the appropriate property file.
Thanks.
While someone gives you a proper and complete answer you might want to have a look at a similar question I did. Javascript web app and Java server, build all in Maven or use Grunt for web app?
I am trying different options out there but most probably we will finish using Grunt for the client side. Maven exec to call it and build everything (client + server) with different profiles.
I am currently developing an application for some researchers in my university.It's a small java program that you can use by command line. The next step is to package that program and deploy it to an application server. Some clients program will submit requests to the server who will call the tool that I wrote. Lately, we will add more tools to the server and he has to dispatch the requests to the right tool.
Which application server fits my needs ? I have looked for Tomcat, Jetty and Glassfish but it seems that they are only used for web application.
Is it possible to use those servers in some context different from web context? Which package archive should i use (jar, war) ?
Any advice?
Some clients program will submit requests to the server who will call the tool that I wrote.
The big question is what server-side technology and what communication protocol can you use between the clients and the server. You basically have two major options: HTTP and web services (in that case, consider using either JAX-WS or JAX-RS) or RMI-IIOP and EJBs (in that case, you'll have to use a Java EE compliant server like GlassFish).
I have looked for Tomcat, Jetty and Glassfish but it seems that they are only used for web application.
Not really. As I said, they can also be used for web services oriented applications. And GlassFish can be used for EJBs applications.
Which package archive should i use (jar, war)
The packaging will depend on the type of application you'll write, it's not something that you choose upfront, it's just a consequence. EJBs are packaged in an EJB JAR and typically deployed inside an EAR; Servlet based web services are deployed inside a WAR.
You really need to think about what technology to use first (with the current level of detail, I can't provide more guidance).
Do you even need an application server? There's nothing stopping you from adding the necessary network bindings and deploying it on its own.
Of the servers you mention, you've got 2 different categories: servlet containers and full-stack Java EE servers
Tomcat and Jetty are servlet containers. That doesn't mean that you can only do web stuff with them and you could manually add the required libraries to get a full Java EE server.
Glassfish is a full-stack Java EE server and can be compared with JBoss (both are open source) or the commercial rivals Weblogic and Websphere.
Sometimes this question is simple as the environment you are working in mandates a particular flavour of app server. You should check this first.
If you're not forced to use an app server, I'd ask why you think you need to use an app server?
I don't see why you would want to use tomcat, glassfish or jetty for a command line program.
If it's command-line based, and you want it to run server-side, you could write a little program that allows users to, for instance, telnet to your server, which in turn starts the CLI-application in question, and relays input / output to the client.
You may also want to look into Java Webstart, which makes deployment of new versions a breeze.
Actually we can't answer with so few elements.
- What are you planning to do
- With what technologies
- Where are you planning to host your application (have you got budget?)
- In which language are written the clients (even the future ones)?
- Could clients be on mobile phones (add some technlogy constraints...)
....
It would also be great to know what kind of request the clients will do, and what kind of response the server will provide...
Actually with what you tell us, all those application servers can do what you want...
I have looked for Tomcat, Jetty and
Glassfish but it seems that they are
only used for web application
You could even make a webapplication (servlet) and on the clientside use a httpclient to call that servlet... there are so many options :)
vive Paris!