On 10 July 2013 15:52, Ron Wheeler <[email protected]
<mailto:[email protected]>> wrote:
On 10/07/2013 10:06 AM, Stephen Connolly wrote:
Well if it is an interactive installer then it can do the
configuration for you...
It needs to be interactive in some way if you want to handle a
variety of environments.
./configure
make
install
(you hope that you don't end up with something this complex!!!)
or questions during msi or rpm installs.
But with a JavaEE application you don't know:
1. What application container they have
2. What database they have
3. Where the application container picks up deployed apps
4. How the user wants the app deployed in the application container
...
These are all questions that can be asked and are somewhat limited
by the configurations that your application supports.
I would think that the answer to question 1 limits the possible
responses to 3 and 4.
The application designer usually limits the supported
configurations in some way so that they do not have to create and
distribute a lot of configuration files if they are using Maven to
build the final war file that has to handle the whole range of
deployment environments.
Well getting back to the OP, they were saying that they are expanding
the supported list of platforms... so it looks like their designer is
getting more fast and loose with QA (because QA will only be doing
touchstone testing on the entire matrix of combinations)
As a frequent deployer and a less frequent developer, I prefer an
installer that encapsulates the developers supported tweaking
rather than a complex process that requires me to manually modify
configuration files based on my understanding of the developers
documentation.
I am not saying you're wrong... I am saying that the JavaEE spec does
not share your point of view...
The ideal Maven way is one .ear that works for everyone without
modification. The JavaEE spec and the way application containers are
implemented makes that harder to achieve for some scopes (e.g.
persistence.xml)
I generally have very little idea about the internal architecture
since I might have to install 50 packages to get a server set up
and don't have the time to learn each one and read the code and
configuration file documentation to find the things to change.
Take it up with the JCP ;-)
I want to get something that the programmer has tested and will
install on the supported configuration with as few places for me
to make mistakes, as possible.
Which is why I recommended having Maven do the repacking for them...
just using one module for each target platform...
Note that this may mean that they have 20 or 30 repack modules... so
be it!!! Following the Maven way typically results in discovering pain
at things which are not best practice... the need to have NxM
repack-ear modules highlights the pain introduced by poor application
server spec design
I can go on.
The less Windows centric world has installers that basically are
non-interactive, e.g. RPM, DEB, etc
This type of installer typically would be installing both the
application and container... thus the question is moot.
An example of this is the various ways you can install Jenkins:
1. Jenkins.war (as self-executing war file)
2. Jenkins.war in your container of choice
3. RPM
4. DEB
5. PKG
6. Windows installer
7. Mac installer
All except the .WAR based distributions make assumptions about
how to deploy the application.
If you want to install Jenkins on RedHat, you grab the RPM and
install that... but if you don't like the way that configures
Jenkins, then you can grab your container of choice, grab the
.war and deploy that in your container using your container's
deployment toolchain.
Installers are not the solution to this problem... in fact to my
mind, other than windows, they are often an anti-pattern...
Though with puppet/chef what you typically do is wrap up the
application you want in an installer that depends on an installer
you created for your container of choice and then drops the
application into the correct directory... that simplifies your
puppet/chef scripts as they just interact with the platform's
package management infrastructure... but you are still back to
the Ops team creating the installer not the dev team
On 10 July 2013 14:39, Ron Wheeler
<[email protected]
<mailto:[email protected]>> wrote:
Where does an installer fit in this vision?
It seems to me, having installed thousands of programs as a
Windows user and Linux system administrator, that a lot of
the discussion about deployment issues seem to ignore the
role of installers (rpm, msi, izPack, etc.).
They are specifically designed to tweak packages during
deployment.
They can be set up very easily to be very smart about using
input from the Application Deployer and Administrator or from
the environment directly, to customize the installed application.
Ron
On 10/07/2013 4:23 AM, Stephen Connolly wrote:
Well the first thing I would look towards is whether you
can use an
application server specific deployment descriptor to
tweak the effective
persistence.xml at deployment time.
I am not saying that the above is possible, but if it is,
then that is
obviously "the way to go" as you then can just bundle all
the application
server specific deployment descriptors into the .ear and
you have one .ear
that works for everyone.
I have a constant battle with people in work who feel
that application
server specific deployment descriptors are an
anti-pattern... and if you
think it is ok to follow the JavaEE spec's vision of the
deployment
process, then that may indeed be a valid view... but the
real world does
not work that way... and hence you need the application
server specific
deployment descriptors.
Ok let's take a step back, and look at where I am coming
from.
The JavaEE spec lists a role of application deployer:
*# Application Deployer and Administrator
*The application deployer and administrator is the
company or person who
configures and deploys application clients, web
applications, Enterprise
JavaBeans components, and Java EE applications,
administers the computing
and networking infrastructure where Java EE
components and applications
run, and oversees the runtime environment. Duties
include setting
transaction controls and security attributes and
specifying connections to
databases.
During configuration, the deployer follows
instructions supplied by the
application component provider to resolve external
dependencies, specify
security settings, and assign transaction attributes.
During installation,
the deployer moves the application components to the
server and generates
the container-specific classes and interfaces.
A deployer or system administrator performs the
following tasks to install
and configure a Java EE application or components:
* Configures the Java EE application or components
for the operational
environment
* Verifies that the contents of the EAR, JAR, and/or
WAR files are well
formed and comply with the Java EE specification
* Deploys (installs) the Java EE application or
components into the Java
EE server
*Source:
http://docs.oracle.com/javaee/6/tutorial/doc/bnaca.html*
*
*
Now the "vision" is thus that whoever is deploying the
application will
essentially "crack open" the .ear, tweak the deployment
descriptors and
then seal it back up again (that is meaning of the
"Configures the Java EE
application or components for the operational
environment" step which comes
*before* deploying to the JavaEE server)
Of course where we hit issues is that we all view letting
a human "crack
open", "tweak", and "seal up again" a .ear as error
prone, plus the people
we are shipping the application to also view this as scary.
Now if I were the admin for such an app, I would use
something like puppet
or chef, etc to automate the open-tweak-seal process...
but the biggest
issue is tracablility.
If you have a .ear that is never the same as that shipped
from the vendor
(or from the release process) how do you know that it was
the one that QA
tested?
Instead of being able to do
sha1sum application.ear
you now have to open up the ear and do a diff of the
contents against the
reference .ear and potentially resolve differences in
files that are
permitted to have differences.
TL;DR the JavaEE spec vision is not something that you want
So then you decide that you want to release the app
pre-configured for each
deployment environment and all the remaining
configuration should be picked
up via JNDI or via files deployed to the classpath of the
container (or
maybe system properties or environment variables)
In an ideal world you can do it all from JNDI or system
properties (JNDI
being better as you do not pollute a global name space)
In the non-ideal world what you do is have your build
system take on some
of the roles of application deployer.
You have a module that produces the generic .ear
And then you have modules that unpack-tweak-repack the
.ear targetting each
app server/database
That is "the maven way" *but* it is not the way Maven
wants you to work...
Maven wants you to only have one .ear that works for
all... the app servers
are letting you down, and Maven is delivering pain for
not following the
best practice way of working.
On 10 July 2013 08:33, John Patrick
<[email protected] <mailto:[email protected]>>
wrote:
On 10 Jul 2013, at 06:05, Baptiste MATHUS
<[email protected] <mailto:[email protected]>> wrote:
If those properties are specific to eclipselink,
then I think it's ok and
simpler to just leave them in the persistence.xml
even if they're
actually
not used when EclipseLink isn't the provider.
Then package only one ear.
Cheers
2013/7/9 John Patrick <[email protected]
<mailto:[email protected]>>
I'm working on a project that uses JPA
EclipseLink, everything started
of
fine with Jetty for developers development
and WebLogic and Oracle
proper
ear deployments.
EclipseLink has two values that need to be
set in persistence.xml
depending
upon your Application Server and Database;
eclipselink.target-server
eclipselink.target-database
This mean we have two profiles, Jetty and
Release.
Now we support WebSphere and DB2, so have
gone to 5 profiles and the
need
to rebuild the ear 4 times which each profile.
Profiles
Jetty
WLSOracle
WLSDB2
WASOracle
WASDB2
I feel I'm doing something wrong...
Does someone have any suggestions on what to
look at so i could
potentially
build it once and get all the 4 ears build in
one command? I've thought
about types or classifiers but unsure if that
is just another hack...
Thoughts? As we soon might also need to
support MySQL and Glassfish so
their is another 5 profiles and 5 more builds
for a release.
John
--
Baptiste <Batmat> MATHUS - http://batmat.net
Sauvez un arbre,
Mangez un castor !
Mathus I think you miss understood my point. I need
to build 4
different ears currently as eclipselink auto
detections fails about
once a week and we can reproduce on demand.
each ear has a different combination of values.
ear 1 = WebLogic / Oracle
ear 2 = WebLogic / DB2
ear 3 = WebSphere / Oracle
ear 4 = WebSphere / DB2
I can't build one ear, say ear 1 as the value for the
database setting
would be wrong when DB2 is the backend. Also the
value for the
application server would be wrong when deployed to
WebSphere.
If eclipselink auto detect worked 100% I could create
one ear but a
few issues in production which we can't reproduce in
test on demand
mean we need to explicitly define application server
and database
server.
From the off list replies it looks like others are
having similar
issues and doing similar things.
cheers,
John
