On Jan 27, 2005, at 11:35 AM, Sandip Ghayal wrote:
Hi David,
I think now I might know the reason for confusion from my side and your side.
Guess it might not be an issue actually.
I was trying to use server.jar to load J2EEDeployment configuration. So trying to bring up server with J2EEDeployment. So guess the fix is not required then.
For the server.jar you should be using the org/apache/geronimo/RuntimeDeployer. Even if you could load J2EEDeployer I think it might have problems with duplicate classes in different classloaders and object names, although I haven't tried it.
Sorry to create this confusion.
no problem. It is very confusing to have 2 nearly identical plans for deployers, and I would certainly like to get to the point of only needing one. We have a vague plan about how to do this but it is somewhat complicated, involving creating for each package you deploy, a special deployer package that is a child of the parent of the package you are deploying (IIRC). I'm hoping we can come up with a simpler system.
Many thanks, david jencks
For JTA Specs I don't have his/her contact information. I have never talked to the spec lead directly, may be some one on this list might know ?
Cheers,
Sandip
--- David Jencks <[EMAIL PROTECTED]> wrote:
-----------------------------------------------------Hi Sandip,
I'm really confused about what might be happening because it's been working for me for a long time on os x and linux without your patch, and similar problems happened to a lot of people when the class moved to the common package. For a very long time there weren't any downloadable jars with the class in geronimo-common. I'm not entirely sure how that happened, I try to stay out of the build/distribution process. In fact, I think for a while some incorrect jars kept getting refreshed. I always build geronimo, openejb, tranql, tranql-connector, and howl, and sometimes activemq, myself to avoid these problems. Currently there is a really nasty circular dependency between geronimo and several of these other projects which more or less prevents building them individually. However, if you build geronimo, then the other projects, then geronimo again, the dependencies should work out ok. The "m:" build targets help to some extent also. There's supposed to be someone trying to fix this situation this week, I can only hope he succeeds :-)
I'll try to explain what is (supposed) to be happening with classpaths in assembly.
In project.xml, we list all the jars we're going to use. There are properties to indicate how we will use them. repository >> copied into geronimo repository, available for <dependency> elements in plans lib >> copied into lib directory, available to startup classpaths deploy >> added to "bootstrap" deployer.jar manifest classpath server >> added to server.jar manifest classpath client >> added to client.jar manifest classpath
So...
<dependency> <groupId>geronimo</groupId>
<artifactId>geronimo-common</artifactId>
<version>${pom.currentVersion}</version> <properties> <lib>true</lib> <deploy>true</deploy> <repository>true</repository> </properties> </dependency>
puts the jar in both lib and the repo, and adds it to the deployer.jar manifest classpath
Can you check that the copy in lib actually has the DeploymentException class in it and that the jar is in the deployer.jar manifest classpath?
----------------
Thanks for nudging me about the transaction timeout issue. I'd like to ping the jta spec lead with some related questions. I'm having a little trouble figuring out who that is:-) Could you send me their email address if you have it handy?
many thanks!
let me know if I can help with anything, david jencks
On Jan 27, 2005, at 10:35 AM, Sandip Ghayal wrote:
downloadedHi David,
I cleaned up my old geronimo directory andinthe entire directory today.
So it can't be old code.
Also I found that once I put the common's jar fileDeployment. Ithe plan then it works properly.
So for some reason common's jar is not in the classpath when starting server with J2EEdoesalso looked at parent plan for J2EE Deployment and i.e. deployment-system-plan and this plan alsoputnot have common's jar file in the classpath.
My knowledge about Maven is limited. So when youup the dependecy in maven does it mean its goingto be<[EMAIL PROTECTED]>put in the final plan too ?
Cheers,
Sandip --- "David Jencks (JIRA)"wrote:
http://issues.apache.org/jira/browse/GERONIMO-554?[
page=comments#action_58173startup]
David Jencks commented on GERONIMO-554: ---------------------------------------
I think that there is a different problem in your setup.
The geronimo-common jar is already on the j2ee-deployer classpath because it is in thebootstrapclasspath of the parent configuration.
See assembly maven.xml lines 218ff wheremovedis using ${deploy.classpath}
In maven.xml lines 95ff deploy.classpath is constructed using the project.xml dependencies marked with "deploy"
in project.xml line 105 geronimo-common is marked with deploy.
Is it possible that you had an old copy of geronimo-common? When DeploymentException wasthere it caused a lot of problems like this.
Cannot start Geronimo Server with J2EEDeploymentplan
ules/assembly/target/geronimo-1.0-SNAPSHOT/repository/Repositoryhttp://issues.apache.org/jira/browse/GERONIMO-554
Key: GERONIMO-554 URL:plan Server crashes with following exceptionProject: Apache Geronimo Type: Bug Components: general Environment: Windows XP Reporter: Sandip Ghayal Attachments: j2eeDeployerPlan.patch
When trying to start Geronimo with J2EEDeployer11:39:55,217 INFO [ReadOnlyRepository]root is file:/F:/geronimo/mod
java.lang.Class.privateGetDeclaredMethods(Class.java:1647)Method)Exception in thread "main"java.lang.NoClassDefFoundError: org/apache/geronimo/cjava.lang.Class.getDeclaredMethods0(Nativeommon/DeploymentException atat
atjava.lang.Class.getMethod0(Class.java:1893)
=== message truncated ===
__________________________________ Do you Yahoo!? Read only the mail you want - Yahoo! Mail SpamGuard. http://promotions.yahoo.com/new_mail
