Re: Suggestion to improve packaging of ejb-jars
djencks wrote: I'm generally against these nested packagings. I think they were dreamed up in the dark ages before people realized that their software was part of the worldwide software ecosystem and that you need to document explicitly how your software relates to other stuff. This is the kind of problem maven tries to solve. People who still use ant IMO still haven't recognized that this is something they can think about. I think this is true for Open Source software. But companies (and especially banks) like ear files which developers can give to IT operations (who don't want to download libraries from the web while putting banking software into production). Greetings, Juergen -- View this message in context: http://www.nabble.com/Suggestion-to-improve-packaging-of-ejb-jars-tp22588998s134p22599300.html Sent from the Apache Geronimo - Users mailing list archive at Nabble.com.
Re: Suggestion to improve packaging of ejb-jars
On Mar 19, 2009, at 9:27 AM, Olaf Bergner wrote: Thanks for your pointer, I will have a closer look at the maven-car- plugin. Last time I checked, however, I had to write the list of required dependencies by hand, a task that should be offloaded to maven/the maven-car-plugin, IMO. Using plugins is much easier in trunk there we do (by default) follow maven transitive dependencies, and track if they've changed with src/history/dependency.xml files, and we also have the framework plugin group which makes assembling a server very easy. I wish we could get 2.2 out really soon. :-((( As to your question: it is true that my solution for building an ear is not totally automatic, i.e. I have to decide up front which dependencies are to be shared between all modules. By putting those into a separate pom, however, and referencing that pom in scope provided from all jee modules, in scope runtime from my ear module maven more or less automatically produces a correctly packaged ear. I don't think I've fought with this recently :-) I have some recollection that some of the maven plugins could use some more configuration about whether they package jars into the ear/war/rar automatically depending on the dependency scope. For geronimo I think we'd like a flag that would let the dependencies be normal scope so geronimo would see them but maven would not include them in the ee artifact. I think I saw that there were some changes recently but I don't know if this is supported yet. Anyway your ear-building seems like it will work. How important do you see separate classloaders for each ejb jar and rar? Do you expect any actual problems from a shared classloader or does it just seem inelegant? thanks david jencks Thx, Olaf djencks wrote: On Mar 18, 2009, at 3:23 PM, Olaf Bergner wrote: Obviously, adopting the Geronimo way of explicitly declaring a module's dependencies as references to jars contained in Geronimo's repository is the most explicit way of making that module's needs known to the world. On the other hand, it may be argued that packaging dependencies that are only needed by one module inside that module is still closer to the truth than throwing them all indifferently into the enclosing ear's lib directory. I tend to agree that the classloader structure of javaee applications is not well defined and very likely it would be pretty handy to have classloader-per-module for ejb apps and rars as well as the ear classloader from the lib directory. In current geronimo, it's only going to be a notation of what you'd prefer in a more ideal world. For wars in an ear, you can indeed specify geronimo dependencies for the war alone referencing the g. repo rather than (and equivalent to) including the jars in the war's WEB-INF/lib. Moreover, it is precisely my use of maven and my meticulously managing my dependencies that led to this suggestion. I rely on maven's dependency management capabilities to automatically compute each module's classpath, leading to the scenario I described in my original post. Anyway: is there a maven plugin that allows me to convert my ear into a Geronimo plugin, using maven's knowledge about the required dependencies to automatically build the required environment entries? I don't entirely understand what you are asking for once you've built an ear or war that includes some jars, you have to do some work with the dependency plugin to take them out again. On the other hand if you assemble an ear that does not include a bunch of jars in the lib directory but the modules have maven dependencies that you need, you can use the car-maven-plugin to build the ear into a geronimo plugin that references the jars as (geronimo) dependencies. When you install the plugin, it will pull the jars into geronimo also. thanks david jencks Thanks, Olaf djencks wrote: On Mar 18, 2009, at 2:33 PM, Olaf Bergner wrote: I have several ejb-jar packaged inside an ear. Libraries to be shared between some or all of these ejb-jars are placed inside the encompassing ear's lib directory, as decreed by the standard. Some libraries, however, are local to the using ejb-jar, i.e. they don't need to be shared. I tried to package these libraries inside the using ejb-jar, creating appropriate Class-Path entries in that ejb-jar's manifest file. This, however, leads to a deployment error as obviously the Class-Path entries in the ejb-jar's manifest file are resolved relative to the enclosing ear and are therefore not found. Suggestion: make Geronimo resolve those dependencies relative to the ejb-jar declaring them. Same goes for rars. What do you think? rars already have a nested structure, anything inside has to be in a jar. Or are you suggesting we support infinitely nested jars? In geronimo everything in all the ejb jars and rars ends up in the same classloader so you won't get any difference in behavior by
Re: Suggestion to improve packaging of ejb-jars
On Mar 19, 2009, at 5:39 AM, Juergen Weber wrote: djencks wrote: I'm generally against these nested packagings. I think they were dreamed up in the dark ages before people realized that their software was part of the worldwide software ecosystem and that you need to document explicitly how your software relates to other stuff. This is the kind of problem maven tries to solve. People who still use ant IMO still haven't recognized that this is something they can think about. I think this is true for Open Source software. But companies (and especially banks) like ear files which developers can give to IT operations (who don't want to download libraries from the web while putting banking software into production). Sure, but the bank is almost certainly using some software from the outside world such as the app server, db driver, etc. So it needs a way to provide the required software to the developers (and qa, production, etc) and audit what is made available. And it still needs to document the relationship of artifacts to each other. IIUC the maven solution to this is to use a corporate repository manager such as nexus that lets you specify exactly what is available inside the company. The geronimo solution built on this is to assemble a custom server from bits in the repo manager and give that to IT operations all they have to do is unpack and start it. thanks david jencks Greetings, Juergen -- View this message in context: http://www.nabble.com/Suggestion-to-improve-packaging-of-ejb-jars-tp22588998s134p22599300.html Sent from the Apache Geronimo - Users mailing list archive at Nabble.com.
GBean documentation improvement
I have some suggestions about improving following document: http://cwiki.apache.org/GMOxDOC22/developing-and-deploying-a-geronimo-gbean.html 1. GBean Lifecycle section what is doFail() method expected to do? Shutdown gbean and make it sure that calling doStart() will do nothing? 2. GBean attributes SimpleServerGBean doesn't have get/set methods for its attributes `name` and `port`. I would like to see and example handling of invalid input. for example setPort(-1). Should gbean just ignore attribute change or throw IllegalArgument exception? 3. Make some example Gbean using references 4. Deploy What should i do if gbean itself needs another library to work? Deploy both .jars into jars repository and list both as dependencies when we are about to create gbean instance by deploying simpleServer_deployment_plan.xml ? -- View this message in context: http://www.nabble.com/GBean-documentation-improvement-tp22607392s134p22607392.html Sent from the Apache Geronimo - Users mailing list archive at Nabble.com.
Re: Problem: WSDL generation for JPA enhanced classes
Hmm... can you attach some sample ear or war file that replicates this problem? There are a couple of work-arounds. One easy thing to do is the pre-generate the wsdl (using the jaxws-tools command line tool) and attach the wsdl to your service. That way the server won't need to generate the wsdl during deployment. Another things to try (if possible of course) is to switch to CXF. It uses a different way to generate the wsdl and I'm pretty sure it will avoid the problem you see with Axis2. Jarek On Mon, Mar 16, 2009 at 9:35 AM, Phili geron...@annee.de wrote: Hi, I'm trying to deliver jpa entity classes through a web-service. It works fine unless I use build-time enhanced classes: The WSDL generation fails at deploy-time because of missing jpa-classes: 14:22:00,743 ERROR [WsdlGenerator] WSDL generation process failed 14:22:00,743 ERROR [WsdlGenerator] Problem encountered during annotation processing; see stacktrace below for more information. com.sun.tools.javac.code.Symbol$CompletionFailure: class file for org.apache.openjpa.enhance.PersistenceCapable not found Exception in thread main java.lang.NoClassDefFoundError: org/apache/openjpa/enhance/PersistenceCapable at java.lang.ClassLoader.defineClass1(Native Method) [...] How can I add the required (open)jpa jars for the wsgen-tool - i've tried to add an dep:dependency to the deployment plan but that doesn't seem to be the correct way. Thx in advance kind regards Phil -- View this message in context: http://www.nabble.com/Problem%3A-WSDL-generation-for-JPA-enhanced-classes-tp22538378s134p22538378.html Sent from the Apache Geronimo - Users mailing list archive at Nabble.com.
Re: your current Geronimo evaluation
U need to use any group communication service software (build on top
on JGroup, ActiveCluster, and so on). Take a look at Group
Communication Services built in WADI (*), or integrate shoal (**) by
your own.
(*) http://docs.codehaus.org/display/WADI/Home,
http://docs.codehaus.org/pages/viewpage.action?pageId=9764983
(**) https://shoal.dev.java.net/
On Mon, Mar 16, 2009 at 3:04 PM, Aldian_00 aldian...@gmail.com wrote:
Aldian_00 wrote:
Ok Thank you very much everyone for the reply. I would still have a tough
question to ask you:
About Geronimo's load balancing / failover capacities. Is it only based on
apache's ones, or is there a functionality specific to Geronimo about
this?
I am asking this because it seems that apache's load balancing only bother
of front-end aspects: severals servers with thousands of clients
(web-browsers or desktop applications). And in our case we plan to
developp an application of type Operations Support Systems which will be
interfaced to an existant Network Management System, and we will need to
use back-end type load-balancing between all our thousands of equipements.
As for our client applications, we won't have many.
So here is the question: Is Geronimo able to perform load-balancing of
back-end type?
Aldian
Aldian_00 wrote:
Xasima Xirohata wrote:
Sorry,
and we will need to use back-end type load-balancing
is it on the topic of Group Communication Management System, means
1) load balancing to propagate requests to the certain instance of
Network Management System (equipment)
2) automatic determining of inclusion / exclusion certain instance
(equipment) to/from the group
3) determining fail overs in request propagation or instance (equipment)
live.
So you want to use Geronimo in scope of Clients - Geronimo -
GROUP {equipment}, don't you?
Yes this is exactly what I want
regards
Aldian
Now that we know exactly what I would like, could you please answer the
original question? Thank you very much!
--
View this message in context:
http://www.nabble.com/your-current-Geronimo-evaluation-tp22329850s134p22537712.html
Sent from the Apache Geronimo - Users mailing list archive at Nabble.com.
--
Best regards,
~ Xasima Xirohata ~
Re: Starting from framework
On Mar 19, 2009, at 3:46 PM, Derek Potts wrote: djencks wrote: very roughly speaking you run ./bin/gsh deploy/list-modules pick the geronimo plugin repository you want (gshell will list the available plugins, including the jetty6 plugin and you probably want the jetty6-deployer plugin too and maybe even the console-jetty) pick the ones you want by number they will get installed. I'm afraid I haven't personally checked what happens with released versions of g. There's supposed to be a plugin catalog configured for each version and the location inserted into g. before release, but since I'm always working with trunk I rely on my local maven repo. I do know I've seen commits for these plugin catalogs and you can tell geronimo about them if they aren't already configured. hope this helps david jencks When I run deploy/list-modules, I only get a list of 14. If I understand you correctly, this is due to a lack of a repository configuration? How do I set one up? I gave you some bad information. I just tried with a copy of 2.1.4- SNAPSHOT of some age I have here 1. edit var/config/config.xml to look like this: attribute name=userRepositories~/.m2/repository,http://geronimo.apache.org/plugins/geronimo-2.1.4 /attribute 2. The correct gshell command is deploy/list-plugins After the above edit you should get a choice of repos -- the non-local one should have the 2.1.4 plugins. The list-modules command just shows what is installed in the server already. However I'm afraid there may be bugs in the 2.1.4 server. When I try to install jetty6 (#70 in the listing I got) I got a message about a 2.1.3-only plugin (unidentified). When I tried to install plugin 1 (jetty console) a lot got downloaded but there was a problem apparently due to a missing version for org.apache.geronimo.modules/geronimo-jetty6//jar I checked with local snapshot plugins in trunk and installing the console onto the framework using plugins works fine. I guess we should try to figure out what's wrong in 2.1.4 before the release is final thanks david jencks -- View this message in context: http://www.nabble.com/Starting-from-framework-tp22571384s134p22610568.html Sent from the Apache Geronimo - Users mailing list archive at Nabble.com.
Re: Starting from framework
djencks wrote: 1. edit var/config/config.xml to look like this: attribute name=userRepositories~/.m2/repository,http://geronimo.apache.org/plugins/geronimo-2.1.4 /attribute Since I'm working with the 2.1.3 framework distribution, I made my config.xml look like this: attribute name=userRepositorieshttp://geronimo.apache.org/plugins/geronimo-2.1.3/attribute I dropped ~/.m2/repository since I don't have anything in my local repo. deploy/list-plugins then listed 114 plugins. But I also ran into problems attempting to install Jetty or the console. When I tried 1: Geronimo Plugins, Console :: Jetty (2.1.3) this was the output: Downloading org.apache.geronimo.plugins/pluto-support/2.1.3/car Downloading org.apache.pluto/pluto-portal-driver/1.1.6-G643117/jar Installation FAILED: Could not find org.apache.pluto/pluto-portal-driver/1.1.6-G643117/jar in any repo When I tried 71: Geronimo Plugins, Jetty :: Jetty 6 (2.1.3) this was the output: Copying org.apache.geronimo.configs/j2ee-server//car to the repository Installation FAILED: Artifact org.apache.geronimo.configs/j2ee-server//car is not fully resolved Next, I'll see if I can attain my desired setup starting from Little-G. -- View this message in context: http://www.nabble.com/Starting-from-framework-tp22571384s134p22612670.html Sent from the Apache Geronimo - Users mailing list archive at Nabble.com.
Re: Starting from framework
On Mar 19, 2009, at 6:11 PM, Derek Potts wrote: djencks wrote: 1. edit var/config/config.xml to look like this: attribute name=userRepositories~/.m2/repository,http://geronimo.apache.org/plugins/geronimo-2.1.4 /attribute Since I'm working with the 2.1.3 framework distribution, I made my config.xml look like this: attribute name=userRepositorieshttp://geronimo.apache.org/plugins/geronimo-2.1.3 /attribute I dropped ~/.m2/repository since I don't have anything in my local repo. deploy/list-plugins then listed 114 plugins. But I also ran into problems attempting to install Jetty or the console. When I tried 1: Geronimo Plugins, Console :: Jetty (2.1.3) this was the output: Downloading org.apache.geronimo.plugins/pluto-support/2.1.3/car Downloading org.apache.pluto/pluto-portal-driver/1.1.6-G643117/jar Installation FAILED: Could not find org.apache.pluto/pluto-portal-driver/1.1.6-G643117/jar in any repo When I tried 71: Geronimo Plugins, Jetty :: Jetty 6 (2.1.3) this was the output: Copying org.apache.geronimo.configs/j2ee-server//car to the repository Installation FAILED: Artifact org.apache.geronimo.configs/j2ee- server//car is not fully resolved Next, I'll see if I can attain my desired setup starting from Little- G. I forgot about the private-versions-of-pluto/tomcat/etc problem. I'm afraid we are unlikely to solve it for 2.1.4. It will still prevent you from installing the console from little-g. Basically I think you will need to check out svn co https://svn.apache.org/repos/asf/geronimo/server/tags/2.1.3/repository/ cd repository mvn clean install this will install all the private artifacts we should be publishing under our own groupIds to your local maven repo and then I think the console should install OK. I'm going to look at the missing-version problem in 2.1.4 maybe there will be something we can fix for the release I guess we need integration tests for this somehow... but we really need to actually release these private artifacts. david jencks -- View this message in context: http://www.nabble.com/Starting-from-framework-tp22571384s134p22612670.html Sent from the Apache Geronimo - Users mailing list archive at Nabble.com.
Re: GBean documentation improvement
Hi Radiim, Thanks a lot for your suggestion. We will get down to the improvement. Best Regards, Ying Tang (Sophia) 2009/3/20 Radim Kolar h...@sendmail.cz I have some suggestions about improving following document: http://cwiki.apache.org/GMOxDOC22/developing-and-deploying-a-geronimo-gbean.html 1. GBean Lifecycle section what is doFail() method expected to do? Shutdown gbean and make it sure that calling doStart() will do nothing? 2. GBean attributes SimpleServerGBean doesn't have get/set methods for its attributes `name` and `port`. I would like to see and example handling of invalid input. for example setPort(-1). Should gbean just ignore attribute change or throw IllegalArgument exception? 3. Make some example Gbean using references 4. Deploy What should i do if gbean itself needs another library to work? Deploy both .jars into jars repository and list both as dependencies when we are about to create gbean instance by deploying simpleServer_deployment_plan.xml ? -- View this message in context: http://www.nabble.com/GBean-documentation-improvement-tp22607392s134p22607392.html Sent from the Apache Geronimo - Users mailing list archive at Nabble.com.
Re: startup geronimo jetty on AIX fails
Which version of AIX did you use ? If 6+, shall you run ulimt -a to check the value of threads(per process) is unlimited or big enough. Wish it could help you. Thanks ! 2009/3/19 MarcoLaponder marco.lapon...@kewill.com I tried your suggestions but the error is still there. Do you have any other suggestions or items I can try and/or check to solve this problem ? Kind regards, Marco MarcoLaponder wrote: When I try to start geronimo with jetty on AIX it gives me the following message: Module 24/67 org.apache.geronimo.configs/j2ee-corba-yoko/2.1.3/car started in 1.910s Module 25/67 org.apache.geronimo.configs/jetty6/2.1.3/car 12:16:48,589 ERROR [log] failed ajp13socketconnec...@0.0.0.0:8009 java.lang.OutOfMemoryError: unable to create new native thread at java.lang.Thread.start0(Native Method) at java.lang.Thread.start(Thread.java:597) at java.util.concurrent.ThreadPoolExecutor.addIfUnderCorePoolSize(ThreadPoolExecutor.java:703) at java.util.concurrent.ThreadPoolExecutor.execute(ThreadPoolExecutor.java:652) at org.apache.geronimo.pool.ThreadPool.execute(ThreadPool.java:232) at org.apache.geronimo.jetty6.connector.JettyThreadPool.dispatch(JettyThreadPool.java:47) at org.mortbay.jetty.AbstractConnector.doStart(AbstractConnector.java:266) I also tried : JAVA_OPTS=-Xmx256m -XX:MaxPermSize=128m and JAVA_OPTS=-Xmx512m -XX:MaxPermSize=256m but still no luck. When I use geronimo with tomcat I got no problems. Anyone got an idea what to do to solve this problem ? Kind regards, Marco -- View this message in context: http://www.nabble.com/startup-geronimo-jetty-on-AIX-fails-tp22558472s134p22599099.html Sent from the Apache Geronimo - Users mailing list archive at Nabble.com. -- Ivan
