[jira] Assigned: (GERONIMODEVTOOLS-283) Refactoring a Dynamic Web Project's name doesn't refactor it's artifact id & context root
[ https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-283?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shiva Kumar H R reassigned GERONIMODEVTOOLS-283: Assignee: (was: Shiva Kumar H R) > Refactoring a Dynamic Web Project's name doesn't refactor it's artifact id & > context root > - > > Key: GERONIMODEVTOOLS-283 > URL: > https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-283 > Project: Geronimo-Devtools > Issue Type: Wish > Components: eclipse-plugin >Reporter: Shiva Kumar H R >Priority: Minor > Fix For: 2.2.0 > > > When a Dynamic Web Project with name say "tt" is created, a Geronimo > deployment plan "geronimo-web.xml" will get created with module-id as > "default/tt-1.0.car" and context-root as "/tt". > When this project is re-factored to say "tz", the module-id will still be the > same "default/tt-1.0.car" (note that artifact id is not re-factored from "tt" > to "tz"). The context-root also remains the same "/tt". > Although this doesn't pose any problem, wouldn't it be better to refactor the > artifact-id & context-root to match the project name? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMODEVTOOLS-283) Refactoring a Dynamic Web Project's name doesn't refactor it's artifact id & context root
[ https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-283?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12718308#action_12718308 ] Shiva Kumar H R commented on GERONIMODEVTOOLS-283: -- Or how about the below option? If module-id and context-root have the same values as project-name (i.e. the user has not changed them from their default values or has intentionally kept all of them same) then provide an user option (say a check box) during refactoring that allows the user to select "renaming module-id and context-root to match the new project name". > Refactoring a Dynamic Web Project's name doesn't refactor it's artifact id & > context root > - > > Key: GERONIMODEVTOOLS-283 > URL: > https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-283 > Project: Geronimo-Devtools > Issue Type: Wish > Components: eclipse-plugin >Reporter: Shiva Kumar H R >Assignee: Shiva Kumar H R >Priority: Minor > Fix For: 2.2.0 > > > When a Dynamic Web Project with name say "tt" is created, a Geronimo > deployment plan "geronimo-web.xml" will get created with module-id as > "default/tt-1.0.car" and context-root as "/tt". > When this project is re-factored to say "tz", the module-id will still be the > same "default/tt-1.0.car" (note that artifact id is not re-factored from "tt" > to "tz"). The context-root also remains the same "/tt". > Although this doesn't pose any problem, wouldn't it be better to refactor the > artifact-id & context-root to match the project name? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Unsubscribe
[jira] Commented: (GERONIMO-4682) Unique snapshots does not work
[ https://issues.apache.org/jira/browse/GERONIMO-4682?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12718206#action_12718206 ] David Jencks commented on GERONIMO-4682: donald we are now using the nexus snapshot repo which automatically cleans up timestamped snapshots and I think only accepts timestamped snapshots. Anyway the config for it is in the apache 6 pom with unique snapshots turned on so we are now building with timestamped snapshots. > Unique snapshots does not work > -- > > Key: GERONIMO-4682 > URL: https://issues.apache.org/jira/browse/GERONIMO-4682 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: car-maven-plugin >Affects Versions: 2.2 > Environment: OS X 10.5.7, Java 6, Maven 2.1.0 or 2.0.9 >Reporter: Trygve Hardersen >Priority: Minor > > When we deploy Geronimo to our local Maven repository using unique snapshots > we're unable to build our server later. The car-maven-plugin fails with > errors like this: > Cound not find parent configuration: > org.apache.geronimo.configs/openejb-deployer/2.2-20090609.071606-2/car > When Geronimo is deployed using non-unique snapshots, or when we build our > server on a box that also has Geronimo built on it locally, the error does > not occur. Here's the full trace of the error: > [INFO] > > [ERROR] BUILD ERROR > [INFO] > > [INFO] could not package plugin > Embedded error: Unable to create configuration for deployment > Cound not find parent configuration: > org.apache.geronimo.configs/openejb-deployer/2.2-20090609.071606-2/car > [INFO] > > [INFO] Trace > org.apache.maven.lifecycle.LifecycleExecutionException: could not package > plugin > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:703) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:540) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:519) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:371) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:332) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:181) > at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:356) > at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:137) > at org.apache.maven.cli.MavenCli.main(MavenCli.java:356) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:597) > at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) > at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) > at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) > at org.codehaus.classworlds.Launcher.main(Launcher.java:375) > Caused by: org.apache.maven.plugin.MojoExecutionException: could not package > plugin > at > org.apache.geronimo.mavenplugins.car.PackageMojo.execute(PackageMojo.java:212) > at > org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:483) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:678) > ... 16 more > Caused by: org.apache.geronimo.common.DeploymentException: Unable to create > configuration for deployment > at > org.apache.geronimo.deployment.DeploymentContext.createTempConfiguration(DeploymentContext.java:151) > at > org.apache.geronimo.deployment.DeploymentContext.(DeploymentContext.java:131) > at > org.apache.geronimo.deployment.DeploymentContext.(DeploymentContext.java:111) > at > org.apache.geronimo.deployment.service.ServiceConfigBuilder.buildConfiguration(ServiceConfigBuilder.java:227) > at > org.apache.geronimo.deployment.service.ServiceConfigBuilder.buildConfiguration(ServiceConfigBuilder.java:199) > at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:256) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMeth
[jira] Commented: (GERONIMO-4683) Transaction.commit method signature isn't entirely correctly
[ https://issues.apache.org/jira/browse/GERONIMO-4683?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12718204#action_12718204 ] David Jencks commented on GERONIMO-4683: IIUC IllegalStateException is an unchecked exception so you don't need to list it in method signatures. The binary jar pases the signature tests which definitely check for the correct exceptions. > Transaction.commit method signature isn't entirely correctly > > > Key: GERONIMO-4683 > URL: https://issues.apache.org/jira/browse/GERONIMO-4683 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: specs >Affects Versions: 2.1.4 >Reporter: Lin Sun > > I found out the Transaction.commit method signature isn't entirely correct. > Per JTA 1.1 for the Transaction interface: > commit > public void commit() throws RollbackException, > HeuristicMixedException, HeuristicRollbackException, > IllegalStateException, SecurityException, SystemException > geronimo-jta_1.1_spec has: > void commit() throws HeuristicMixedException, HeuristicRollbackException, > RollbackException, SecurityException, SystemException; > which is missing the IllegalStateException. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-4679) many [ERROR] "The protocol for the JAR file's URL is not supported" in the build log when building geronimo on windows
[
https://issues.apache.org/jira/browse/GERONIMO-4679?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12718200#action_12718200
]
David Jencks commented on GERONIMO-4679:
Since you have a windows system to develop on can you figure out how to
construct a correct jar url and avoid the error in the first place?
> many [ERROR] "The protocol for the JAR file's URL is not supported" in the
> build log when building geronimo on windows
> ---
>
> Key: GERONIMO-4679
> URL: https://issues.apache.org/jira/browse/GERONIMO-4679
> Project: Geronimo
> Issue Type: Improvement
> Security Level: public(Regular issues)
> Components: kernel
>Affects Versions: 2.1.1, 2.1.2, 2.1.3, 2.1.4
> Environment: windows + trunk
>Reporter: Shawn Jiang
>Assignee: Shawn Jiang
>Priority: Minor
> Fix For: 2.1.5, 2.2
>
> Attachments: G4679.patch
>
>
> When building the Geronimo from source code on windows. There are
> many [ERROR] "The protocol for the JAR file's URL is not supported" in
> the build log like following.
> -
> [ERROR] The protocol for the JAR file's URL is not supported
> java.lang.UnsupportedOperationException: Only local file jars are
> supported jar:file:/D:/ws/gtrunck/
> server_repo/org/apache/geronimo/configs/system-database/2.2-SNAPSHOT/
> system-database-2.2-SNAPSHOT.ca
> r!/rar/tranql-connector-1.4.jar
>
> org.apache.geronimo.kernel.classloader.UrlResourceFinder.cacheUrl(UrlResourceFinder.java:231)
>
> org.apache.geronimo.kernel.classloader.UrlResourceFinder.rebuildClassPath(UrlResourceFinder.java
> :188)
>
> org.apache.geronimo.kernel.classloader.UrlResourceFinder.addUrls(UrlResourceFinder.java:142)
>
> org.apache.geronimo.kernel.classloader.UrlResourceFinder.addUrls(UrlResourceFinder.java:127)
>
> org.apache.geronimo.kernel.classloader.JarFileClassLoader$2.run(JarFileClassLoader.java:153)
>
> This message was thrown in UrlResourceFinder.cacheUrl() and logged as
> ERROR in UrlResourceFinder.rebuildClassPath().
> --
> } catch (UnsupportedOperationException ex) {
>// the protocol for the JAR file's URL is not
> supported. This can occur when
>// the jar file is embedded in an EAR or CAR
> file. Proceed but log the message.
>log.error("The protocol for the JAR file's URL
> is not supported", ex);
>continue;
>}
> -
> We'd better to log this as INFO or DEBUG instead of an ERROR so that the user
> will not be mislead by a lot of ERRORs in the build log.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: jta spec bundle issue in felix
First of all I think we should lean on felix to provide a 1.0 package version for their tx classes. Second without the split-bundle lin suggests wont' there be this problem anyway since the system bundle will have used up the packages and ours will be ignored? thanks david jencks On Jun 10, 2009, at 10:58 AM, Jarek Gawor wrote: Hey all, I'm experimenting with JPA (OpenJPA specifically) in osgi environment and I ran into an interesting issue with the transaction API. The root of the problem is that the JDK provides a *subset* of the javax.transaction classes that the JTA specification defines. And that creates problems (i.e. java.lang.NoClassDefFoundError) at runtime depending on which bundle is used to wire in the transaction packages. The JVM transaction packages are exported via the system bundle (just like any other JVM package). On Felix, the JVM packages are exported with the version of the JVM you are running on (e.g. if you are running Java 5, the version attribute is set to 1.5.0). Our JTA spec bundle (geronimo-jta_1.1_spec-1.1.1.jar) exports the transaction API with version 1.1.0. Now, openjpa has the following javax.transaction imports: javax.transaction;version="1.1", javax.transaction.xa;version="1.1". On Felix, the container wires these imports using the system bundle since the system bundle exports these packages with higher version then the JTA bundle and that creates the NoClassDefFoundError problems. So, one would think that updating the version in our JTA spec bundle to something higher then 1.5 or 1.6 should work. And I think that should work but it doesn't seem to be working right on Felix. I don't know if this is a bug or if I'm just missing something or doing things wrong. When I install the openjpa bundle for the first time, its transaction imports get wired to our JTA bundle. But once I restart Felix, the openjpa transaction imports are wired to the system bundle maybe somebody knows what's going on here? Interestingly enough, Equinox exposes the JVM packages with version 0.0.0 and so I don't run into these NoClassDefFoundError errors there. One thing that worked for me reliably is when I updated the JTA spec bundle to be a fragment bundle (attaching itself to the system bundle). That way, the missing transaction classes can be loaded through the system bundle classloader. So, I'm wondering if we should turn the JTA spec bundle into a fragment bundle (just manifest updates) to deal with this problem? Jarek
[jira] Resolved: (GERONIMO-4649) WebServiceContext is null by use of axis and BASIC authentication
[ https://issues.apache.org/jira/browse/GERONIMO-4649?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jarek Gawor resolved GERONIMO-4649. --- Resolution: Cannot Reproduce > WebServiceContext is null by use of axis and BASIC authentication > - > > Key: GERONIMO-4649 > URL: https://issues.apache.org/jira/browse/GERONIMO-4649 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: webservices >Affects Versions: 2.1.4 > Environment: windows xp, geronimo2.1.4, tomcat 6.0.18, jdk 6.0.13, > pojo ws >Reporter: A. L. >Assignee: Jarek Gawor > > WebServiceContext is null by use of axis, https and BASIC authentication. > WebServiceContext is injected if the same webservice is used without > https/BASIC Authentication. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: jta spec bundle issue in felix
Interesting prob... I wonder if you add the split-package (see http://www.aqute.biz/Code/Bnd) when you export the jta packages would solve the prob for you. This is what I have been using but I only tried Equinox so far. Export-Package = \ javax.transaction;version=1.1;-split-package:=first, \ javax.transaction.xa;version=1.1;-split-package:=first Lin On Wed, Jun 10, 2009 at 1:58 PM, Jarek Gawor wrote: > Hey all, > > I'm experimenting with JPA (OpenJPA specifically) in osgi environment > and I ran into an interesting issue with the transaction API. The root > of the problem is that the JDK provides a *subset* of the > javax.transaction classes that the JTA specification defines. And that > creates problems (i.e. java.lang.NoClassDefFoundError) at runtime > depending on which bundle is used to wire in the transaction packages. > > The JVM transaction packages are exported via the system bundle (just > like any other JVM package). On Felix, the JVM packages are exported > with the version of the JVM you are running on (e.g. if you are > running Java 5, the version attribute is set to 1.5.0). Our JTA spec > bundle (geronimo-jta_1.1_spec-1.1.1.jar) exports the transaction API > with version 1.1.0. > > Now, openjpa has the following javax.transaction imports: > javax.transaction;version="1.1", javax.transaction.xa;version="1.1". > On Felix, the container wires these imports using the system bundle > since the system bundle exports these packages with higher version > then the JTA bundle and that creates the NoClassDefFoundError > problems. So, one would think that updating the version in our JTA > spec bundle to something higher then 1.5 or 1.6 should work. And I > think that should work but it doesn't seem to be working right on > Felix. I don't know if this is a bug or if I'm just missing something > or doing things wrong. When I install the openjpa bundle for the first > time, its transaction imports get wired to our JTA bundle. But once I > restart Felix, the openjpa transaction imports are wired to the system > bundle maybe somebody knows what's going on here? > > Interestingly enough, Equinox exposes the JVM packages with version > 0.0.0 and so I don't run into these NoClassDefFoundError errors there. > > One thing that worked for me reliably is when I updated the JTA spec > bundle to be a fragment bundle (attaching itself to the system > bundle). That way, the missing transaction classes can be loaded > through the system bundle classloader. So, I'm wondering if we should > turn the JTA spec bundle into a fragment bundle (just manifest > updates) to deal with this problem? > > Jarek >
jta spec bundle issue in felix
Hey all, I'm experimenting with JPA (OpenJPA specifically) in osgi environment and I ran into an interesting issue with the transaction API. The root of the problem is that the JDK provides a *subset* of the javax.transaction classes that the JTA specification defines. And that creates problems (i.e. java.lang.NoClassDefFoundError) at runtime depending on which bundle is used to wire in the transaction packages. The JVM transaction packages are exported via the system bundle (just like any other JVM package). On Felix, the JVM packages are exported with the version of the JVM you are running on (e.g. if you are running Java 5, the version attribute is set to 1.5.0). Our JTA spec bundle (geronimo-jta_1.1_spec-1.1.1.jar) exports the transaction API with version 1.1.0. Now, openjpa has the following javax.transaction imports: javax.transaction;version="1.1", javax.transaction.xa;version="1.1". On Felix, the container wires these imports using the system bundle since the system bundle exports these packages with higher version then the JTA bundle and that creates the NoClassDefFoundError problems. So, one would think that updating the version in our JTA spec bundle to something higher then 1.5 or 1.6 should work. And I think that should work but it doesn't seem to be working right on Felix. I don't know if this is a bug or if I'm just missing something or doing things wrong. When I install the openjpa bundle for the first time, its transaction imports get wired to our JTA bundle. But once I restart Felix, the openjpa transaction imports are wired to the system bundle maybe somebody knows what's going on here? Interestingly enough, Equinox exposes the JVM packages with version 0.0.0 and so I don't run into these NoClassDefFoundError errors there. One thing that worked for me reliably is when I updated the JTA spec bundle to be a fragment bundle (attaching itself to the system bundle). That way, the missing transaction classes can be loaded through the system bundle classloader. So, I'm wondering if we should turn the JTA spec bundle into a fragment bundle (just manifest updates) to deal with this problem? Jarek
[Fwd: ActiveMQ OSGi Integration]
http://activemq.apache.org/osgi-integration.html Original Message Subject: OSGi Integration Date: Wed, 10 Jun 2009 16:31:38 +0200 From: Dejan Bosanac Reply-To: d...@activemq.apache.org To: d...@activemq.apache.org, us...@activemq.apache.org Hi all, just put up an article explaining how to deploy and run ActiveMQ broker and web console in Apache Karaf and ServiceMix. http://www.nighttale.net/activemq/activemq-osgi-integration.html Cheers -- Dejan Bosanac Open Source Integration - http://fusesource.com/ ActiveMQ in Action - http://www.manning.com/snyder/ Blog - http://www.nighttale.net
[jira] Commented: (GERONIMO-4682) Unique snapshots does not work
[ https://issues.apache.org/jira/browse/GERONIMO-4682?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12718117#action_12718117 ] Trygve Hardersen commented on GERONIMO-4682: I first posted this to the Geronimo users mailing list, but removed some of that email from the bug report. Let me repost it here: ### Original Email ### We've had quite a few problems building Geronimo lately and we've switched our internal repository from Artifactory to Nexus in an attempt to get a more stable environment. This also made us, not entirely intentionally it must be said, go from using non-unique to unique snapshots of Geronimo 2.2-SNAPSHOT. ... problem report as filed here Is this behavior to be expected, or maybe a bug? As I mentioned using non-unique snapshots solves the problem. ### End Original Email ### Then David Jencks replied: ## Start Reply ### That's a bug. Could you please file a jira? --spoiled by always building g. on my dev machine-- ### End Reply ### So I filed this bug report. I don't have a problem with using non-unique snapshots, but if it isn't supported by Geronimo I think it should be clearly stated because it's a standard feature of Maven. > Unique snapshots does not work > -- > > Key: GERONIMO-4682 > URL: https://issues.apache.org/jira/browse/GERONIMO-4682 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: car-maven-plugin >Affects Versions: 2.2 > Environment: OS X 10.5.7, Java 6, Maven 2.1.0 or 2.0.9 >Reporter: Trygve Hardersen >Priority: Minor > > When we deploy Geronimo to our local Maven repository using unique snapshots > we're unable to build our server later. The car-maven-plugin fails with > errors like this: > Cound not find parent configuration: > org.apache.geronimo.configs/openejb-deployer/2.2-20090609.071606-2/car > When Geronimo is deployed using non-unique snapshots, or when we build our > server on a box that also has Geronimo built on it locally, the error does > not occur. Here's the full trace of the error: > [INFO] > > [ERROR] BUILD ERROR > [INFO] > > [INFO] could not package plugin > Embedded error: Unable to create configuration for deployment > Cound not find parent configuration: > org.apache.geronimo.configs/openejb-deployer/2.2-20090609.071606-2/car > [INFO] > > [INFO] Trace > org.apache.maven.lifecycle.LifecycleExecutionException: could not package > plugin > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:703) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:540) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:519) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:371) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:332) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:181) > at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:356) > at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:137) > at org.apache.maven.cli.MavenCli.main(MavenCli.java:356) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:597) > at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) > at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) > at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) > at org.codehaus.classworlds.Launcher.main(Launcher.java:375) > Caused by: org.apache.maven.plugin.MojoExecutionException: could not package > plugin > at > org.apache.geronimo.mavenplugins.car.PackageMojo.execute(PackageMojo.java:212) > at > org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:483) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:678) > ... 16 more > Caused by: org.apache.geronimo.common.DeploymentException: Unable to create > configuration for deployment > at > org.apache.geronimo.deployment.DeploymentContext.createTempConfiguration(DeploymentContext.java:151) >
[jira] Commented: (GERONIMO-4682) Unique snapshots does not work
[ https://issues.apache.org/jira/browse/GERONIMO-4682?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12718115#action_12718115 ] Donald Woods commented on GERONIMO-4682: Why do you need to rebuild the server with unique snapshots enabled? We don't use them for the normal builds, as the ASF requested that we not use unique timestamps, as it was using too much space on the snapshot repo. I believe, you'll need to perform a local build to use unique timestamps, due to the hard wired dependencies that have to go in the serialized config for a CAR, or add in artifact aliases for every CAR you need to use. > Unique snapshots does not work > -- > > Key: GERONIMO-4682 > URL: https://issues.apache.org/jira/browse/GERONIMO-4682 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: car-maven-plugin >Affects Versions: 2.2 > Environment: OS X 10.5.7, Java 6, Maven 2.1.0 or 2.0.9 >Reporter: Trygve Hardersen >Priority: Minor > > When we deploy Geronimo to our local Maven repository using unique snapshots > we're unable to build our server later. The car-maven-plugin fails with > errors like this: > Cound not find parent configuration: > org.apache.geronimo.configs/openejb-deployer/2.2-20090609.071606-2/car > When Geronimo is deployed using non-unique snapshots, or when we build our > server on a box that also has Geronimo built on it locally, the error does > not occur. Here's the full trace of the error: > [INFO] > > [ERROR] BUILD ERROR > [INFO] > > [INFO] could not package plugin > Embedded error: Unable to create configuration for deployment > Cound not find parent configuration: > org.apache.geronimo.configs/openejb-deployer/2.2-20090609.071606-2/car > [INFO] > > [INFO] Trace > org.apache.maven.lifecycle.LifecycleExecutionException: could not package > plugin > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:703) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:540) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:519) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:371) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:332) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:181) > at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:356) > at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:137) > at org.apache.maven.cli.MavenCli.main(MavenCli.java:356) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:597) > at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) > at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) > at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) > at org.codehaus.classworlds.Launcher.main(Launcher.java:375) > Caused by: org.apache.maven.plugin.MojoExecutionException: could not package > plugin > at > org.apache.geronimo.mavenplugins.car.PackageMojo.execute(PackageMojo.java:212) > at > org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:483) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:678) > ... 16 more > Caused by: org.apache.geronimo.common.DeploymentException: Unable to create > configuration for deployment > at > org.apache.geronimo.deployment.DeploymentContext.createTempConfiguration(DeploymentContext.java:151) > at > org.apache.geronimo.deployment.DeploymentContext.(DeploymentContext.java:131) > at > org.apache.geronimo.deployment.DeploymentContext.(DeploymentContext.java:111) > at > org.apache.geronimo.deployment.service.ServiceConfigBuilder.buildConfiguration(ServiceConfigBuilder.java:227) > at > org.apache.geronimo.deployment.service.ServiceConfigBuilder.buildConfiguration(ServiceConfigBuilder.java:199) > at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:256) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at >
[jira] Commented: (GERONIMO-4533) Fix "This is ridiculous" error messages on command execution
[ https://issues.apache.org/jira/browse/GERONIMO-4533?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12718109#action_12718109 ] Vladimir Ivanov commented on GERONIMO-4533: --- Thanks for quick fix and response! > Fix "This is ridiculous" error messages on command execution > > > Key: GERONIMO-4533 > URL: https://issues.apache.org/jira/browse/GERONIMO-4533 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) >Affects Versions: 2.1.3, 2.2 >Reporter: Kevan Miller >Assignee: Donald Woods > Fix For: 2.1.4, 2.1.5, 2.2 > > > Depending on the terminal you're running from, some commands will display a > "This is ridiculous" error message: > bash-3.2$ ./deploy.sh undeploy com.test/testwar/1.0/war > Using GERONIMO_HOME: > /Users/kevan/geronimo/server/branches/2.1/target/geronimo-tomcat6-javaee5-2.1.4-SNAPSHOT > Using GERONIMO_TMPDIR: var/temp > Using JRE_HOME: > /System/Library/Frameworks/JavaVM.framework/Versions/CurrentJDK/Home > Username: system > system > Password: *** > Module com.test/testwar/1.0/war unloaded. > Module com.test/testwar/1.0/war uninstalled. > line= Undeployed com.test/testwar/1.0/war; indent= 4; endCol= 0 > Exception in thread "main" java.lang.IllegalArgumentException: This is > ridiculous! line= Undeployed com.test/testwar/1.0/war; indent= 4; endCol= 0 > at > org.apache.geronimo.deployment.cli.DeployUtils.println(DeployUtils.java:103) > at > org.apache.geronimo.deployment.cli.CommandStart.execute(CommandStart.java:66) > at > org.apache.geronimo.deployment.cli.DeployTool.execute(DeployTool.java:164) > at > org.apache.geronimo.kernel.util.MainConfigurationBootstrapper.main(MainConfigurationBootstrapper.java:45) > at org.apache.geronimo.cli.AbstractCLI.executeMain(AbstractCLI.java:67) > at > org.apache.geronimo.cli.deployer.DeployerCLI.main(DeployerCLI.java:31) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (GERONIMO-4683) Transaction.commit method signature isn't entirely correctly
Transaction.commit method signature isn't entirely correctly Key: GERONIMO-4683 URL: https://issues.apache.org/jira/browse/GERONIMO-4683 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Components: specs Affects Versions: 2.1.4 Reporter: Lin Sun I found out the Transaction.commit method signature isn't entirely correct. Per JTA 1.1 for the Transaction interface: commit public void commit() throws RollbackException, HeuristicMixedException, HeuristicRollbackException, IllegalStateException, SecurityException, SystemException geronimo-jta_1.1_spec has: void commit() throws HeuristicMixedException, HeuristicRollbackException, RollbackException, SecurityException, SystemException; which is missing the IllegalStateException. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMODEVTOOLS-283) Refactoring a Dynamic Web Project's name doesn't refactor it's artifact id & context root
[ https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-283?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12718076#action_12718076 ] Delos Dai commented on GERONIMODEVTOOLS-283: I think it's not right behavior for refactor. Indeed, the default values of module-id and context-root are the same as the project name. But it's not always the case. User can change module-id or context-root into other names. So we have to keep them independent of each other. If possible, suggest to close this JIRA! Thanks! > Refactoring a Dynamic Web Project's name doesn't refactor it's artifact id & > context root > - > > Key: GERONIMODEVTOOLS-283 > URL: > https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-283 > Project: Geronimo-Devtools > Issue Type: Wish > Components: eclipse-plugin >Reporter: Shiva Kumar H R >Assignee: Shiva Kumar H R >Priority: Minor > Fix For: 2.2.0 > > > When a Dynamic Web Project with name say "tt" is created, a Geronimo > deployment plan "geronimo-web.xml" will get created with module-id as > "default/tt-1.0.car" and context-root as "/tt". > When this project is re-factored to say "tz", the module-id will still be the > same "default/tt-1.0.car" (note that artifact id is not re-factored from "tt" > to "tz"). The context-root also remains the same "/tt". > Although this doesn't pose any problem, wouldn't it be better to refactor the > artifact-id & context-root to match the project name? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMODEVTOOLS-578) Integrate server adapter 1.1 in GEP 2.2
[ https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-578?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12718059#action_12718059 ] Donald Woods commented on GERONIMODEVTOOLS-578: --- Why? We decided long ago that we would drop the 1.1 server support from GEP 2.x. Are we seeing enough users in the community asking for this to warrant the extra development and test overhead? Having to support 1.1.x, 2.0.x, 2.1.x and 2.2.x servers in the same GEP is asking a lot, considering there are no plans to release another 1.1.x or 2.0.x release. > Integrate server adapter 1.1 in GEP 2.2 > --- > > Key: GERONIMODEVTOOLS-578 > URL: > https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-578 > Project: Geronimo-Devtools > Issue Type: New Feature > Components: eclipse-plugin >Affects Versions: 2.2.0 >Reporter: Delos Dai >Assignee: Tim McConnell > Fix For: 2.2.0 > > > Need to integrate server adapter 1.1 in new GEP release to support Eclipse > 3.4 & 3.5. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: svn commit: r776749 - /geronimo/sandbox/blueprint/README
Sounds good. I was just using the latest released version to test with at the time. -Donald Guillaume Nodet wrote: I think we should even upgrade to the latest snapshot of felix. The reason is that the blueprint API depends on OSGi Core 4.2 for the ServiceException. Currently, I have hacked the api to remove this dependency, but we'll have to switch to the correct api at some point anyway. On Wed, May 20, 2009 at 18:11, wrote: Author: dwoods Date: Wed May 20 16:11:01 2009 New Revision: 776749 URL: http://svn.apache.org/viewvc?rev=776749&view=rev Log: updated versions to latest Felix 1.8.0 Modified: geronimo/sandbox/blueprint/README Modified: geronimo/sandbox/blueprint/README URL: http://svn.apache.org/viewvc/geronimo/sandbox/blueprint/README?rev=776749&r1=776748&r2=776749&view=diff == --- geronimo/sandbox/blueprint/README (original) +++ geronimo/sandbox/blueprint/README Wed May 20 16:11:01 2009 @@ -1,8 +1,8 @@ Installing and running the blueprint-sample bundle: --- -0) Download Felix (v1.6.0 used at the time of this writing): +0) Download Felix (v1.8.0 used at the time of this writing): - http://www.apache.org/dist/felix/felix-1.6.0.tar.gz + http://www.apache.org/dist/felix/felix-1.8.0.tar.gz 1) Start Felix under Java SE 5: @@ -20,8 +20,8 @@ 4) Build the blueprint project and install the extender and sample bundles: - a) install file:///org/apache/geronimo/blueprint-bundle/1.0.0-SNAPSHOT/blueprint-bundle-1.0.0-SNAPSHOT.jar - b) install file:///org/apache/geronimo/blueprint-sample/1.0.0-SNAPSHOT/blueprint-sample-1.0.0-SNAPSHOT.jar + a) install file:org/apache/geronimo/blueprint-bundle/1.0.0-SNAPSHOT/blueprint-bundle-1.0.0-SNAPSHOT.jar + b) install file:org/apache/geronimo/blueprint-sample/1.0.0-SNAPSHOT/blueprint-sample-1.0.0-SNAPSHOT.jar 5) Start the extender and sample bundles: @@ -35,7 +35,7 @@ a) install http://www.apache.org/dist/felix/org.osgi.compendium-1.2.0.jar b) install http://www.apache.org/dist/felix/org.apache.felix.http.jetty-1.0.0.jar - c) install http://www.apache.org/dist/felix/org.apache.felix.webconsole-1.2.8.jar + c) install http://www.apache.org/dist/felix/org.apache.felix.webconsole-1.2.10.jar 2) Start the web console:
[jira] Updated: (GERONIMO-4661) Meaningless message displays while Geronimo ear plan contains modules that aren't in the ear
[ https://issues.apache.org/jira/browse/GERONIMO-4661?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] viola.lu updated GERONIMO-4661: --- Attachment: GERONIMO-4661.patch With this patch, Message like below will be output on admin console: "Deployment Failed Geronimo ear plan contains modules that aren't in the ear: calculator-stateless.war org.apache.geronimo.common.DeploymentException: Geronimo ear plan contains modules that aren't in the ear: calculator-stateless.war" pls help review,thanks. > Meaningless message displays while Geronimo ear plan contains modules that > aren't in the ear > > > Key: GERONIMO-4661 > URL: https://issues.apache.org/jira/browse/GERONIMO-4661 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: deployment >Affects Versions: 2.2 > Environment: Windows XP > JDK 1.5 >Reporter: Ivan >Priority: Minor > Attachments: GERONIMO-4661.patch > > > While the ear plan contains modules which are not in the ear, the console > will show > Geronimo ear plan contains modules that aren't in the ear : false. It is not > friendly for user to correct the plan, > Please check the > \geronimo\plugins\j2ee\geronimo-j2ee-builder\src\main\java\org\apache\geronimo\j2ee\deployment\EARConfigBuilder.java > line 904 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: svn commit: r776749 - /geronimo/sandbox/blueprint/README
I think we should even upgrade to the latest snapshot of felix. The reason is that the blueprint API depends on OSGi Core 4.2 for the ServiceException. Currently, I have hacked the api to remove this dependency, but we'll have to switch to the correct api at some point anyway. On Wed, May 20, 2009 at 18:11, wrote: > Author: dwoods > Date: Wed May 20 16:11:01 2009 > New Revision: 776749 > > URL: http://svn.apache.org/viewvc?rev=776749&view=rev > Log: > updated versions to latest Felix 1.8.0 > > Modified: > geronimo/sandbox/blueprint/README > > Modified: geronimo/sandbox/blueprint/README > URL: > http://svn.apache.org/viewvc/geronimo/sandbox/blueprint/README?rev=776749&r1=776748&r2=776749&view=diff > == > --- geronimo/sandbox/blueprint/README (original) > +++ geronimo/sandbox/blueprint/README Wed May 20 16:11:01 2009 > @@ -1,8 +1,8 @@ > Installing and running the blueprint-sample bundle: > --- > -0) Download Felix (v1.6.0 used at the time of this writing): > +0) Download Felix (v1.8.0 used at the time of this writing): > > - http://www.apache.org/dist/felix/felix-1.6.0.tar.gz > + http://www.apache.org/dist/felix/felix-1.8.0.tar.gz > > 1) Start Felix under Java SE 5: > > @@ -20,8 +20,8 @@ > > 4) Build the blueprint project and install the extender and sample bundles: > > - a) install > file:///org/apache/geronimo/blueprint-bundle/1.0.0-SNAPSHOT/blueprint-bundle-1.0.0-SNAPSHOT.jar > - b) install > file:///org/apache/geronimo/blueprint-sample/1.0.0-SNAPSHOT/blueprint-sample-1.0.0-SNAPSHOT.jar > + a) install > file:org/apache/geronimo/blueprint-bundle/1.0.0-SNAPSHOT/blueprint-bundle-1.0.0-SNAPSHOT.jar > + b) install > file:org/apache/geronimo/blueprint-sample/1.0.0-SNAPSHOT/blueprint-sample-1.0.0-SNAPSHOT.jar > > 5) Start the extender and sample bundles: > > @@ -35,7 +35,7 @@ > > a) install http://www.apache.org/dist/felix/org.osgi.compendium-1.2.0.jar > b) install > http://www.apache.org/dist/felix/org.apache.felix.http.jetty-1.0.0.jar > - c) install > http://www.apache.org/dist/felix/org.apache.felix.webconsole-1.2.8.jar > + c) install > http://www.apache.org/dist/felix/org.apache.felix.webconsole-1.2.10.jar > > 2) Start the web console: > > > > -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ Open Source SOA http://fusesource.com
[jira] Created: (GERONIMODEVTOOLS-578) Integrate server adapter 1.1 in GEP 2.2
Integrate server adapter 1.1 in GEP 2.2 --- Key: GERONIMODEVTOOLS-578 URL: https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-578 Project: Geronimo-Devtools Issue Type: New Feature Components: eclipse-plugin Affects Versions: 2.2.0 Reporter: Delos Dai Assignee: Tim McConnell Fix For: 2.2.0 Need to integrate server adapter 1.1 in new GEP release to support Eclipse 3.4 & 3.5. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Geronimo EJB security
I am not sure if I express myself clearly in the last email. For example, in the ejb-jar.xml file, no method permission is defined, only some run as configuration, and in the geronimo's plan, a securiy configuration is defined. Before the changes I did, the builder checks whether there are method permission definitions in the ejb-jar.xml, if not, the builder would not create the JACC Manager for that configuration even if there is securiy configuration in the Geronmo's plan, which caused many cases failed for access denied. Thanks ! 2009/6/10 David Jencks > Hi Ivan, > On Jun 9, 2009, at 6:55 PM, Ivan wrote: > > Thanks, David, I have changed some codes about EJB security, for it made > some cases failed. Currently, I use whether securiy segment exists in the > deployment plan to decide that , JACC Manager is or not need to be created. > > > I think that's what we used to do and it is very wrong. It makes it too > easy to deploy an app without security you expect because you don't > understand how to write a geronimo plan. What we want is that if there are > security annotations in the ejbs or if security is configured in the > ejb-jar.xml spec deployment descriptor, then we require security > configuration in the geronimo plan and set up the JACC stuff. > > I thought I found all the tck tests that had security in the spec dd or > annotations and fixed the plans, but it's entirely possible I missed some. > We should add security config to the geronimo plans rather than allowing > decployment. > > thanks > david jencks > > > Ivan > > 2009/6/10 David Blevins > >> >> On Jun 2, 2009, at 11:08 PM, Ivan wrote: >> >>1. If there is no method-permission for an EJB in the ejb-jar.xml, >>> shall we still need a JACC Manager, which in it, we grant the all access >>> permissions ? >>> 2. When we will say that the EJBDeploymentGBean of an EJB is not >>> security-enabled. In the current codes, the value seems always set to true. >>> >> >> It seems both questions boil down to "if the user isn't using security, >> can we have security-enabled set to false?" IIRC, that's what we did. >> Though this part might have been changed along with David J's changes to >> make it so that an app with EJB method-permissions (or equivalent >> annotations) would fail on deployment if no security was setup. >> >> -David >> >> > > > -- > Ivan > > > -- Ivan
Re: Geronimo EJB security
Hi Ivan, On Jun 9, 2009, at 6:55 PM, Ivan wrote: Thanks, David, I have changed some codes about EJB security, for it made some cases failed. Currently, I use whether securiy segment exists in the deployment plan to decide that , JACC Manager is or not need to be created. I think that's what we used to do and it is very wrong. It makes it too easy to deploy an app without security you expect because you don't understand how to write a geronimo plan. What we want is that if there are security annotations in the ejbs or if security is configured in the ejb-jar.xml spec deployment descriptor, then we require security configuration in the geronimo plan and set up the JACC stuff. I thought I found all the tck tests that had security in the spec dd or annotations and fixed the plans, but it's entirely possible I missed some. We should add security config to the geronimo plans rather than allowing decployment. thanks david jencks Ivan 2009/6/10 David Blevins On Jun 2, 2009, at 11:08 PM, Ivan wrote: 1. If there is no method-permission for an EJB in the ejb-jar.xml, shall we still need a JACC Manager, which in it, we grant the all access permissions ? 2. When we will say that the EJBDeploymentGBean of an EJB is not security-enabled. In the current codes, the value seems always set to true. It seems both questions boil down to "if the user isn't using security, can we have security-enabled set to false?" IIRC, that's what we did. Though this part might have been changed along with David J's changes to make it so that an app with EJB method- permissions (or equivalent annotations) would fail on deployment if no security was setup. -David -- Ivan
