Error running jetty

[billerby]

Hello,

We are about to start our first Alfresco project, and I thought the
best is to adapt the maven-alfresco-lifecycle immediatly. I'm pretty
new to both Maven and Alfresco. Now I'm trying to set up Eclipse to
work with the embedded jetty-run for an amp-project. I'm running my
environment on a Windows7 x64-box.

I have made the following. Installed Eclipse (Galileo 3.5), installed
m2eclipse plugin, created new maven using the "Maven Alfresco AMP
Archetype".

I have created a mysql database named "alf_jetty" with user and pwd
"alfresco", the database is running (I can connect with those
credentials using jdbc).

Now I run:
mvn clean integration-test -P webapp"

The excution works well, the myamp-webapp gets packaged in the target-
directory, however something goes wrong in the step when jetty should
start, it looks that the database connection fails:

2009-12-08 09:35:47.644:WARN::Configuration problem at <resource-
ref><description>The Alfresco database connection</description><res-
ref-name>jdbc/dataSource</res-ref-name><res-type>javax.sql.DataSource</
res-type><res-auth>Container</res-auth><res-sharing-scope>Unshareable</
res-sharing-scope></resource-ref>: java.lang.IllegalStateException:
Nothing to bind for name javax.sql.DataSource/default
2009-12-08 09:35:47.664:WARN::Failed startup of context
org.mortbay.jetty.plugin.Jetty6PluginWebAppContext@f92cc8{/myamp-
webapp,C:\projekt\workspaces\mvn-alfresco\myamp\target\myamp-webapp}
javax.servlet.UnavailableException: Configuration problem

I have double-checked the pom.xml, the database credentials are
correct.

Thing noticed (dont now if it matters):
No alfresco-global.properties gets created in WEB-INF/classes
No alf_data_jetty directory gets created in the base folder (I guess
that happens after the database connection).
Jetty is running on port 8080 (I heard something about port 8081 in
last fridays webcast?), but just displays an error 503
SERVICE_UNAVAILABLE

Does anyone have a clue that would help me get this thing running?

Regards!
/Erik

[Tibor Gemes]

In the maven-extension archetype there is a web.xml which overrides the original alfresco one. I copied this into the amp project and it works now. Maybe this should be included in the amp archetype as well.

Tib
CodWell Kft
+3630-3430856

2009/12/8 billerby <bill...@gmail.com>

--

You received this message because you are subscribed to the Google Groups "Maven Alfresco Lifecycle Discussion Group" group.
To post to this group, send email to maven-a...@googlegroups.com.
To unsubscribe from this group, send email to maven-alfresc...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/maven-alfresco?hl=en.

[Gabriele Columbro]

Hi Erik,
actually the

"webapp"

profile for the AMP plugin is sort of deprecated as I did not maintain
it throughout versions as I thought it was not an useful feature
(making the AMP pom.xml unnecessarily complex). Please open a
regression issue (http://code.google.com/p/maven-alfresco-archetypes/issues/list
) and we'll take care of it.

BTW, the error is due to the fact that as of Alfresco 3.2 by default
the JNDI resource-ref to the database is searched by the web.xml and
as we did not define any resource in Jetty, it of course bombs out
with that exception.
This has been fixed in the maven-alfresco-extension-archetype by
adding a custom web.xml. I see then 2 solutions for "running your AMP" :


1. Fix the "webapp" profile by adding a custom web.xml (which you find
in the generated maven-alfresco-extension project) in the src/test/
webapp/WEB-INF folder of the AMP structure. This should automatically
overlay the unpacked Alfresco WAR with the custom web.xml. If this
works I suggest you comment in the issue, so that we can fix this in
the code.

2. More simply, create an AMP project and run 'mvn install'. Then
create a maven-alfresco-extension-project and add the dependency on
the installed AMP. Then run mvn install -Prun under the generated
extension project and you'll be able to run a custom Alfresco WAR with
the AMP already installed (by Maven dependency management).


HTH,
Gab

> --
>
> You received this message because you are subscribed to the Google
> Groups "Maven Alfresco Lifecycle Discussion Group" group.
> To post to this group, send email to maven-a...@googlegroups.com.
> To unsubscribe from this group, send email to maven-alfresc...@googlegroups.com
> .
> For more options, visit this group at http://groups.google.com/group/maven-alfresco?hl=en
> .
>
>

--

Eng. Gabriele Columbro
Alfresco Software, Ltd.

M: +31 (0)627 565 103
P: +39 320 161 28 46
D: +44 (0)1628 876 654
Skype: gabrielecolumbro
Blog: http://www.mindthegab.com

[Gabriele Columbro]

Hi folks,
follows an email requesting clarifications about the "bigger picture"
on the Maven Alfresco Lifecycle.
I'm forwarding this mail to the list, as it's very educative and I'll
be happy to answer (thanks Erik :)

See my answers below:


On Dec 8, 2009, at 1:33 PM, Erik Billerby wrote:

> Hi Gabriele,
>
> Thanks for your quick reply.
>
>
<snip/>
> I attended the "Alfresco intensive training for Developers" last week
> in Copenhagen. At the course we learned that the best way to extend
> Alfresco is by developing AMP:s that you at the time of deploy merges
> into the alfresco.war with the MMT-tool.
>
> The documentation from the education states "As a general rule of
> thumb, anything that is considered to be an "installable" extension to
> the Alfresco repository should be called a module and packaged as an
> AMP file".

Make sense. Example to think:
- you can install/uninstall a custom dashlet and you can install/
uninstall it (if compatible) on different instances of Alfresco -->
make an AMP out of it
- you CAN NOT install/uninstall a custom alfresco-global.properties -
or any other Spring configuration context - which configures your
Alfresco for your environment (e.g. it won't work on any other
environment) --> do a custom WAR build of Alfresco

>
> Now, when digging into these maven archetypes I get a little confused.
> How do I know which archetype to use?

You first have to understand yourself if what you're doing is a
"software module" (e.g. self contained, relocable, add features, can
be used across versions, etc.) and in that case use an AMP (so the
maven-alfresco-amp-archetype).
If otherwise your doing a configuration or an "alfresco custom
build" (which might be environment dependent, e.g. db/alf_data, or
that requires modifications to "shared" resources in the Alfresco WAR,
e.g. the web.xml) then go for the maven-alfresco-extension archetype.

You can and should of course mix and match AMPs with extensions.

>
> My guess at this point (correct me if I am wrong), is that the
> extension archetype results in a full alfresco.war to be deployed and
> that the amp archetype results in an AMP, that you later have to merge
> into an existing war? To merge it I need to use the Maven AMP plugin
> (If not using the old MMT-tool).


You got completely the point. Just adding an AMP dependency will do
what the MMT does (see http://maven.alfresco.com/nexus/content/repositories/alfresco-docs/maven-alfresco-lifecycle/maven-alfresco-archetypes/maven-alfresco-extension-archetype/profiles.html)
.


>
> Are there any "best practices" for which archetype to use in different
> development scenarios?

See what t I did at a previous client (NXP) : http://www.slideshare.net/guest67a9ba/maven-application-lifecycle-management-for-alfresco
for a highly distributed and complex development process.
This complex scenario (with Jira, Hudson and Nexus integrations) uses
a typical pattern:
- N maven-alfresco-amp - gathering functional customizations for
every single department or application
- 1 maven-alfresco-extension - for building the main Alfresco WAR,
configure it for the environments, deploy it and test it in CI,
version centrally and depend on all the business AMPs to aggregate all-
in-one WAR

Hope this clarifies the design a bit,
ciao!

Gab


>
> Thanks.
> /Erik

HTH,
Gab

[billerby]

Hi Gabriele!

Thank you very much for your very educative answers, they will help a
lot. I have one other question (this one is not about "the bigger
picture" though).

I have now set up one extension project which I intend just to use
just as it is without modifications. This extension project will have
dependencies to the amps we will develop. When invoking jetty with mvn
install -Prun, everything works well. However reading through the log-
file raises one question:

Shall I create the alfresco-global.properties to hold the paths to
ImgMagick, pdf2swf and soffice? Could this file be created on the fly
reading properties from settings.xml (Since every developer probably
got different paths)? Maybe every developer just should create it and
add it to the svn:ignore?

Thanks!
/Erik

> what the MMT does (seehttp://maven.alfresco.com/nexus/content/repositories/alfresco-docs/ma...)

> .
>
>
>
> > Are there any "best practices" for which archetype to use in different
> > development scenarios?
>

> See what t I did at a previous client (NXP) :http://www.slideshare.net/guest67a9ba/maven-application-lifecycle-man...

[Gabriele Columbro]

Hey Billerby,
nice question as well but more Maven than Alfresco related, and
touches a point where I'm very focused on.

See my answers interleaved:

> Hi Gabriele!
>
> Thank you very much for your very educative answers, they will help a
> lot. I have one other question (this one is not about "the bigger
> picture" though).
>
> I have now set up one extension project which I intend just to use
> just as it is without modifications. This extension project will have
> dependencies to the amps we will develop. When invoking jetty with mvn
> install -Prun, everything works well. However reading through the log-
> file raises one question:
>
> Shall I create the alfresco-global.properties to hold the paths to
> ImgMagick, pdf2swf and soffice? Could this file be created on the fly
> reading properties from settings.xml (Since every developer probably
> got different paths)? Maybe every developer just should create it and
> add it to the svn:ignore?

In my view, in any build process there are offer two sets of properties:

__ Build Time properties (build system dependent)
Environment dependent (e.g. developer dependent or depending on the
environment in general where the application is running). Typically
those properties are filtered in your project resources by the build
system.
Maven provides the <filters> tag in the POM to accomplish that
filtering all specified resources with the specified properties file
and with all POM properties (meaning POM + settings + any command line
property.
Specifically those properties which are developer dependent should be
*not* stored under the project root, but in external profiles
(possibly always active) stored in the per user (~/.m2/settings.xml)
or per system ($M2_HOME/conf/settings.xml) settings file so not to
taint the "independency" of the build. See [7].
Ant used to do so with the build.properties and project.properties file.

__RunTime or functional properties (webapp runtime dependent)
Properties which affect the functional behavior of the application and
are loaded (and possibly modified) by the application runtime but they
don't depend on the environment. These are heavily dependent on the
specific application runtime and often aggregated in a simple
java.lang.Properties file.
In standard Alfresco < 3.2 this used to be done by having a number of
*.properties files loaded by different Spring contexts, in Alfresco
3.2+ there's an alfresco-global.properties which gets loaded by
default providing the same functionalitiy.

In this sense in the Maven Alfresco Lifecycle, before Alfresco
introduced alfresco-global.properties, I added the concept of
application.properties (src/main/properties/<env>/
application.properties), a single runtime application properties file
gathering all properties that can be switched (per environment) by
just a -Denv=<yourEnv> property ( see[1] ).
ATM the latest 1.1.0 version of Maven Alfresco Lifecycle still has the
dicotomy application.prroperties / alfresco-global.properties (you can
decide to put your properties in either of the files) which needs very
few effort to be fixed (see [2])


Now customizing Alfresco, this distinction is not so strong (or better
there are no build time properties as all configuration can be loaded
at runtime). If you think at alf_data and the DB DSN you see how they
are both runtime properties but heavily environment dependent.
So to have a single configuration point there's an additional
(questionable as adds black magic) improvement I did: I configured
the default application.properties file to filter in (at build time)
some POM properties (see src/main/local/application.properties) so
that all more common properties (e.g alf_data and db name) could even
more simply be configured directly via POM properties (or settings as
described above).

Based on this considerations, there are a few options to achieve the
original goal of the post (how to manage environment dependent
properties):

1__
All developers keep on using the default env=local
application.properties file (which has $ placeholders in it) and
environment dependent properties are configured in an activeByDefault
profile [6] which filters in the environment dependent properties,.
E.g. each developer's ~/.m2/settings.xml (or $PROJECT_HOME/
profiles.xml with svn:ignore)
should contain something like:

<profiles>
...
<profile>
<id>alfresco-conf</id>
<properties>
<alfresco.data.location>./alf_data_jetty</alfresco.data.location>
<alfresco.db.name>alf_jetty</alfresco.db.name>
<alfresco.db.username>alfresco</alfresco.db.username>
<alfresco.db.password>alfresco</alfresco.db.password>
<alfresco.version>3.2r</alfresco.version>
</properties>
<activation>
<activeByDefault>true</activeByDefault>
</activation>
</profile>
</profiles>


2__
Each developer uses his own application properties file (one folder
per developer under src/main/properties). These folders are added to
svn:ignore. In this case all properties gets directly configured in
the application.properties file (without any need for build time ->
runtime piping).
Drawback is that each developer will have then to run his build with a
specific command line (not really Maven friendly):

mvn install -Denv=<developerId>


3__
As a more definitive improvement to the approach, we tried to find a
neater way (than having $ placeholders in the properties files, which
is paranoid enough) to pipe build time -> run time properties: If you
look at Maven Calm [3], which is used by the 3.x branches [5] of our
archetype, it uses the maven-properties-plugin [4] to "write"
build time (POM) properties into a property file during the first
phases of the build, so that the very same property file can be used
(or better merged) with the application.properties/alfresco-
global.properties and later loaded at runtime. @Maoo: anything to add
here ? :)


I hope I could make something clear about this not so simple topic,
and I'd be really glad to have some feedback on which solution you
like best based on your specific requirement/use case.
Provided we stick as much as possible to Alfresco's approach, offering
super duper easy configurability is the 1st priority and added value
for a maven archetype IMHO.

WDYT?

HTH,
ciao!
Gab



[1] http://maven.alfresco.com/nexus/content/repositories/alfresco-docs/maven-alfresco-lifecycle/maven-alfresco-archetypes/maven-alfresco-extension-archetype/profiles.html
[2] http://code.google.com/p/maven-alfresco-archetypes/issues/detail?id=37
[3] http://code.google.com/p/maven-calm
[4] http://haroon.sis.utoronto.ca/zarar/properties-maven-plugin/
[5] http://maven-alfresco-archetypes.googlecode.com/svn/branches/
[6] http://maven.apache.org/settings.html#Profiles
[7] http://maven.apache.org/guides/introduction/introduction-to-profiles.html

> --
>
> You received this message because you are subscribed to the Google
> Groups "Maven Alfresco Lifecycle Discussion Group" group.
> To post to this group, send email to maven-a...@googlegroups.com.
> To unsubscribe from this group, send email to maven-alfresc...@googlegroups.com
> .
> For more options, visit this group at http://groups.google.com/group/maven-alfresco?hl=en
> .
>
>

[Erik Billerby]

Gabriele,

I my last project (which was not an Alfresco one) the company had some
SOX (Sarbanes-Oxley) requirements which we had to consider. One of the
requirements was that the version they had accepted after test (which
was deployed to the test environment), was the version to be deployed
in production. To ensure the same version was used we added checksums
to the EAR-files, this way we could prove that no modifications had
been made between deployments. Another requirement was that the same
person who installed in test were not allowed to deploy into
production, in fact he was not allowed to know the passwords of the
production environment.

Following the same approach in this project (which really isn't needed
- but I'm kind of used to it now :) would only really give me one
option as I see it regarding environment properties like db-name,
datastore and passwords. Those properties can not be distributed with
the build, they have to reside in the target environment. Either
loaded by Spring or with a -D to my Tomcat jvm.

Maybe we are going very Alfresco-off-topic here, but its an
interesting thing to discuss.

Thanks!
/Erik