No files in bundle / for GateIn-3.4.0.M01-jbossas7.zip

[antoine_h]

Hi,

This bundle is just new.

(see : https://community.jboss.org/en/gatein/blog/2012/08/09/gatein-34-m1-is-here)

But it looks like there is nothing in the folder : ZIP_FILE/standalone/deployments

There is only the README.txt, that comes with JBoss AS7.

The deployments folder does not have the GateIn files.

In 3.3.0-GA, the files are :

gatein.ear

gatein.ear.deployed

gatein-sample-extension.ear

gatein-sample-extension.ear.deployed

gatein-sample-skin.war

gatein-sample-skin.war.deployed

gatein-wsrp-integration.ear.dodeploy

README.txt

I guess the process of building the bundle went wrong.

Antoine

Chercher un expert

[nscavell]

These deployments have been moved to $SERVER/gatein/deployments. Did it not properly start for you ?

[antoine_h]

Hi,

Thanks a lot !

I did not tried to start it, but directly start my custom setup and config, with the DataSources, configuration.properties, etc...

I was surprised not to see the GateIn EAR and War in the folder, where they were in version 3.3.0.

Antoine

[theute]

Antoine, now that you experienced both, what do you think is better ?

The idea was that /standalone/deployments is left empty for user applications (facilitates upgrades assuming no change was done to /gatein/deployments)

I'm actually willing to change one more time. I know that sucks, but impact should be minimal and we may need few attemps before sticking to 1 packaging.

At the moment we have AS modules and GateIn modules clearly seperated, but it doesn't give much value in the end. I'm actually considering putting them together like in 3.3 and keep gatein deployments in a seperate folder, but it may move to standalone/gatein-deployments.

Packaging would look like:

- bin

- domain

- standalone/deployments (empty for user applications)

- standalone/gatein-deployments (The GateIn apps)

- modules (merge AS7 and GateIn modules)

- ...

Another motivation for that is that to have multiple modules directory it requires an additional command line parameter when starting AS7 which is not very convenient for tools users such as Eclipse which doesn't execute "standalone.sh" to start the server.

What do you think ?

[antoine_h]

Hi Thomas,

I like JBoss AS7 modules and classloader isolation...

so I prefer "AS modules and GateIn modules clearly seperated"

I prefer the way it is now : all separated in the GateIn folder.

It is more clear, to see what is added specifically for GateIn.

For the deployment folder, it is a good thing, yes to have a clean (empty) place to add the user applications.

It is also more easy to identify the GateIn Packages.

If it is under "standalone/gatein-deployments", it is ok.

it is apart from the other applications.

But if the modules are in the .../gatein/modules specific folder, then, it is better to have the deployement there.

So, the full "every thing under the specific GateIn folder" is my preference.

************** Advantages of full separation

*** Searching in GateIn artifacts and config files

I sometime use a text search in folders, to look for a xml config item in text files, or even to find in which Jar is a java class.

(to find "where is this GateIn class comming from... which artifact for maven dependencies, etc...)

It helps for this kind of deep search, to have the GateIn stuff (module AND deployment) in a specific folders .

*** JBoss AS7 isolation

JBoss AS7 isolation is great.

It shows the way for building applications more properly.

It shows the way for running several applications and groups of application cleanly, on a single jboss Instance.

A small portal is often the integration of several groups of applications (CMS application, CRM application for sales, etc...).

In a JBoss AS for a portal, you often find the GateIn application, plus many other groups of applications.

It is a good thing to take advantage, right from the beginning, of this clean folder organization.

*** Learning from the GateIn artifacts and deployments

Looking at how GateIn is built, ... provide a good sample of how to put things in the server (modules, and applications).

It is a tutorial as itself, for anybody who wants to look a little on how the server and portals work.

*** more easy to upgrade

with the evolution of both AS7 and GateIn, the new versions comes quickly.

A portal in prod is not moved so often.

But if someone needs to upgrade only the AS, or only the GateIn,... it is much more easy with the seperate modules.

************** For Eclipse

I use it.

I always set my custom config, in the server launcher, ... because I always need my custom parameters anyway.

I take the elements from the standalone.sh file (plus my custom parameters) and add it in the Eclipse configuration of the server launcher.

Sample :

- I change the JVM memory setting, ... because when using JSF and RichFaces, It is mandatory to raise it a lot.

- I set my own applications Module folder ( the "-mp " parameter).

- I set the network interface the server listen to ("-b " parameter)

- I set the name of the "standalone.xml" server-config file, (because I use different one, when in dev, test, integration, recette, or prod).

- for the VM arguments, I set the exo properties, the user language (english, and not french like my linux), and several properties for my custom application.

I may say that most of the companies I worked for have the same needs for specific configuration, so will take the time to make their Eclipse Server Launcher configuration.

So... it is no big deal to have to add the specific GateIn Module Folder parameter.

May be keep this module appart.... and provide some explaination in the Readme file for launching GateIn.

May in a paragraph dedicated to "launching in Eclipse".

Or make a wiki to help with that : "StartGateInWithEclipse".

I may do it, when this is settled.

Thanks for all in GateIn,

Antoine

Presta-Expert, trouvez un expert.

[theute]

Thanks for the answer !

I like JBoss AS7 modules and classloader isolation...  so I prefer "AS modules and GateIn modules clearly seperated"

I agree but I don't undertand how the 2 are mutually exclusive

It is more clear, to see what is added specifically for GateIn.

What's the value for you ? I'd like to not have a frankenstein platform. (for searching you can search in modules/org/gatein, so even if the 2 directories are merged there is still a clean seperation slf4j and hsqldb will be gone (to use the version of slf4j shipped with AS7 and use H2 shipped with AS7)

But if someone needs to upgrade only the AS, or only the GateIn,... it is much more easy with the seperate modules.

It is really not something we recommend, we test GateIn + AS as a single combination, also there are config changes and AS modules could be slightly modified. That's actually a risk as it gives a false sense that you can do this kind of upgrade.

For Eclipse, my comments were based on reported issues (https://community.jboss.org/thread/201807 is one of them). When someone add parameters he finds it normal to go edit startup parameters, but to just run the project you need to start reading documents that very few like to do and need to find parameters to pass. Default startup should just work (in that direction, I'm willing to get rid of the other command line parameters that are required today). It is a real issue, an issue faced by people. I would not degrade the project just for this reason, but I'm still not convinced that seperating modules from AS7 and GateIn makes sense (in the end they need to be related somehow, we want to remove duplications of jars).

[antoine_h]

I agree but I don't undertand how the 2 are mutually exclusive

They are not.

Instead, I was just saying : let's move forward this way...

*************

What's the value for you ?

More clean organization of the artifact, on the server.

A portal agreggates and integrates several applications.

The more the things are isolated and cleanly stored on the server, the better.

Second value : identification of what belongs to GateIn, what belongs to AS (or other "stuff").

when a newbe start looking at the artifacts on the server... it is far much easy this way.

With JBoss AS7, I did it also as a newbe... asking to myself : where is this, ... ho ho, they've put this this way... interesting... etc...

*************

I'd like to not have a frankenstein platform.

GateIn is nice ! ;-)

No risk of a frankentstein !...

Anyway, a portal projet, and the result, the portal server, is about integration.

Sample I've just been working on, at a subsidiary of a big international (french) bank :

- the IDM is done with a Web Service, encapsulating the connection to the LDAP

- the Users and Groups are manage with the Web Service, plus a dedicated application that is not in the portal, but run asides.

(by the way :the portal uses the IDM WebService only for read only on the Users and Groups).

- the application are made mainly with some Convertigo gadgets, that mean a Convertigo "connector" instance is also running on the server, to connect to the Convertigo server.

- may be, soon, there will be some JSF webapps

- and at least, some few "background services" (such as for config, for monitoring, etc...) are running is some Sar artifact

all these are on the same server...

so anyway... frankenstein is not so far...

but at leasts, some nice drawers, to tidy up all this is better,...

*************

in modules/org/gatein, so even if the 2 directories are merged there is still a clean seperation

yes...

you know that there is a clean separation.

many have a deep understanding of what is for GateIn, what is from AS, etc...

for a newbe, having a dedicated folder makes it far more easy to identify where things are, who they belong to, etc...

It is more simple.

Also : what about the javax/jcr/api module ?

It is for GateIn, but it is not under org/gateIn, no ?.

I like to see it under JBOSS_HOME/gatein/modules/javax/....

*************

about upgrades : yes, that's true... it is not recommended.

I toadly agree

I have seen in the pakaging mechanism that there are some tricky thing to make things work on all the proposed bundled versions.

Some companies start their plateform build from a customized JBoss AS (their own "socle").

Then, they add GateIn on it.

Same versions of the AS and GateIn than in the bundle.

For this kind of "manipulations", it is a bit more easy to "move things" to build the plateform.

It's true that at this level of organization, if the modules are mixed with the JBoss AS modules, it is not really a problem to also handle this.

*************

about Eclipse.

I understand the thing.

A nice "start out of the box" is required.

by the way, it is always the same thing : trying to make a product for heavy portal, that also start like a simple software with no setup...

I have often proposed to think about making two (or three ?) products, to answer more properly the needs of these two (or three) differents needs.

It could be done with the same "base materials", and some adaptation, like it is done for the several bundles and version (tomcat, jetty, jboss AS5-6-7).

but that is another debate,...

For the solutions I see :

- Ask Eclipse and JBoss Tools to provide a way to launch the server using the standalone.sh (or .bat) file.

- or... make it all the way around :

      - mix the modules

      - make a wiki to explain how to separate it... for the ones who like this flavour... with tidy clean folders...

      - in the wiki, make a chapter about starting the server from Eclipse.

This will allow to have nice server artifacts for big projects and heavy portals... for the one that want it.

As you say, this will be for the people who have heavy portal with prod environment, and then read the config documents and make a lot of custom configuration, like defining their own modules folders for their apps, etc...

*************

All that is only my humble opinion, based on my experience of the portal when helping companies to set and run their's.

I hope it helps, and fell free to ask more question if I am not clear.

Antoine

[mstruk]

Antoine Herzog wrote:

in modules/org/gatein, so even if the 2 directories are merged there is still a clean seperation

yes...

you know that there is a clean separation.

many have a deep understanding of what is for GateIn, what is from AS, etc...

for a newbe, having a dedicated folder makes it far more easy to identify where things are, who they belong to, etc...

It is more simple.

Also : what about the javax/jcr/api module ?

It is for GateIn, but it is not under org/gateIn, no ?.

I like to see it under JBOSS_HOME/gatein/modules/javax/....

From the point of view of making it clear what's OOTB AS7, and what's GateIn put on top of it I also prefer the current approach with gatein/modules + gatein/deployments.

Like you say - it's immediately clear where to look for configurations, and what belongs to what.

But like Thomas mentioned, there is this ergonomics issue - AS7 startup scripts can't be used as-is, they have to be modified for GateIn.

It's not entirely clear to me why JBoss Tools can't add a custom Launcher configuration for GateIn. Or maybe a better approach would be to add custom server type - besides AS7 there could be AS7 + GateIn 3.4.0.Final. I suppose doing that with gatein is too much of a moving target, as probably there are no AS 7.1.0.Final, AS 7.1.1.Final ... version specific server definitions, and adding GateIn to that would just multiply everything. From this point of view it's really unfortunate that we have to be resorting to patched up scripts.

There is a way to still make it clear enough what is added by GateIn, even if using default modules root, and that is by assigning all of our modules to a 'gatein' slot. In terms of directory structure that would then make javax/jcr/api/main into javax/jsr/api/gatein.

You can then identify gatein modules simply by looking for directories named 'gatein'.

This way we could avoid patching the standalone.sh by having all the modules in default modules directory.

Another way would be if we could programmatically add another modules root. I have no idea if this is possible, or how much work it would be - as it would require bootstrapping from gatein extension I suppose. Or if another subsystem existed, let's call it 'org.jboss.modules.roots' that could be configured with additional roots.

As far as deployments directory is concerned, one plus of having it separate is that it makes it clear to users that this one is not to be touched while it's running. Hot redeploy does not work for gatein-* deployment archives so it should not be attempted. So, besides reducing clutter, hiding it away from default deployments also prevents accidentally touching it.

There is one issue I encountered and have to explore where a managed datasource lookup fails from alternative deployment location. I still have to create an issue for it and look for workaround. Without a solution to that, we would have no choice but to move gatein-* archives back to default deployments directory ...

[antoine_h]

I wonder why the modules folder to use in the AS are not defined in the standalone.xml file.

or may be this is possible.

It sounds logical that a subsystem is taking care of the modules.

And the folders to use shall be defined there.

I also guess that the "-mp" parameter value is given to that subsystem.

It should be only one way among other to define where to take the modules.

Anyone has info or ideas about that ?

Antoine

[theute]

JBoss Tools today has smart code to add parameters, but it's a pain to maintain the multiple combinations and also it is just for JBoss Tools users. So it's only part of the issue.

For me merging the modules is to make things clearer, the package is a full portal platform with a set of services (some are provided by AS some by GateIn). I don't see the added value to clearly state what is a GateIn dependency vs what is an AS dependency (as a user I couldn't care less if apache-fileupload is used for gatein or for as).

At least we agree on a seperate deployment directory

[bdaw]

I agree with thomas. Clear separation of added dependencies is important however I think that until we put everything under something like modules/org/gatein we should be fine.

[mstruk]

Antoine Herzog wrote:

I wonder why the modules folder to use in the AS are not defined in the standalone.xml file.

or may be this is possible.

It sounds logical that a subsystem is taking care of the modules.

And the folders to use shall be defined there.

I also guess that the "-mp" parameter value is given to that subsystem.

It should be only one way among other to define where to take the modules.

Command line argument -mp is handled by jboss-modules.jar. That's the lowest layer that performs AS7 startup procedure. It's a modular classloading implementation that provides the concept of modules. The notion of AS7 subsystems is introduced much later. First org.jboss.msc is started which provides a service kernel with automatic dependencies-based parallel execution, and on top of that org.jboss.as.standalone module is booted up. It is that last one that introduces the notion of AS7 subsystems. So you can see why modules root location has to be specified as a command line argument, and how working from a subsystem back to jboss-modules layer has to be something performed afterwards.

Deployments work that way but are registered as some kind of 'dynamic' modules which require custom descriptions ... a more verbose API compared to filesystem root for 'static' modules. Having a subsystem that could add static modules filesystem rotos post-festum might be a useful feature. It would help with our problem here ...

[mstruk]

Thomas Heute wrote:

For me merging the modules is to make things clearer, the package is a full portal platform with a set of services (some are provided by AS some by GateIn). I don't see the added value to clearly state what is a GateIn dependency vs what is an AS dependency (as a user I couldn't care less if apache-fileupload is used for gatein or for as).

At least we agree on a seperate deployment directory

I agree that the value of clearly stating what is added by GateIn and what not is debatable. Having it cleanly separated may actually encourage attempts to manually update AS7 which as was stated is not a good idea. One should checkout gatein-portal project from github, and perform packaging using maven build, directing the build to use specific AS7 instance which has to be compatible with one of the supported versions, which are clearly identifiable via maven build profiles.

For searching through dirs, that should still work, it will just have to process more modules. But since modules are static and should not be fiddled with one can always use an IDE with properly configured gatein-portal project and find files of interest that way.

So, I buy into the argument that avoiding the need to patch startup scripts outweighs a less obvious separation of libs.

[mstruk]

Boleslaw Dawidowicz wrote:

I agree with thomas. Clear separation of added dependencies is important however I think that until we put everything under something like modules/org/gatein we should be fine.

You should define 'everything'

I'm not sure if you also mean to put portlet-api.jar which is now in javax/portlet/api under modules/org/gatein. That would mean getting rid of logically named standard third-party portlet api module and moving it under what seems like gatein codebase.

But ATM we have such solution in org.gatein.lib which could use some more fine-graining as it's full of third party libs. Or we can keep them there. Classloading works faster when modules contain less stuff. In that respect it makes sense to fine-grain the modules. But if we have a need to provide visibility of all of these modules to extensions for example, then automatically exporting dependencies nullifies such gains. Alternatively there is more work to manually explicitly add every little dependency to your portal extension.

[antoine_h]

Hi,

Thanks Marko, for these nice explaination...

Antoine