Nabble - Apache Geronimo - Users

Re: Could not resolve reference for persistence/jpaEntity#org.apache.geronimo.persistence.PersistenceUnitGBean

2009-07-03T07:23:08Z

I'm not sure because I never used Oracle with Geronimo before.

Can you please create a standalone NonJta instead of reusing the JTA as the Non-JTA ?

Note: There is no way to create a single module that contains both JTA and Non-JTA DS with console wizard. See: [1], You need to use the database pool wizard again to create another module for Non-JTA. and add this module as a dependency just like the JTA module.

[1] https://issues.apache.org/jira/browse/GERONIMO-4331

On Fri, Jul 3, 2009 at 6:16 AM, pookie1973 <christopher.adkin@...> wrote:

Shawn,

I've added a none JTA data source to the persistence.xml, and changed the
transaction type to resource local, I now get:-

Unable to resolve reference "NonJtaDataSourceWrapper"

in gbean
default/jpaTest/1.0/car?EJBModule=jpaFacade.jar,J2EEApplication=default/jpaTest/1.0/car,PersistenceUnitModule=jpaEntity.jar,j2eeType=PersistenceUnit,name=jpaEntity
to a gbean matching the pattern
[?name=OracleDS#org.apache.geronimo.naming.ResourceSource]
due to: No matches for referencePatterns:
[?name=OracleDS#org.apache.geronimo.naming.ResourceSource]
Unable to resolve reference "JtaDataSourceWrapper"
in gbean
default/jpaTest/1.0/car?EJBModule=jpaFacade.jar,J2EEApplication=default/jpaTest/1.0/car,PersistenceUnitModule=jpaEntity.jar,j2eeType=PersistenceUnit,name=jpaEntity
to a gbean matching the pattern
[?name=OracleDS#org.apache.geronimo.naming.ResourceSource]
due to: No matches for referencePatterns:
[?name=OracleDS#org.apache.geronimo.naming.ResourceSource]

org.apache.geronimo.common.DeploymentException: Unable to resolve reference
"NonJtaDataSourceWrapper"

in gbean
default/jpaTest/1.0/car?EJBModule=jpaFacade.jar,J2EEApplication=default/jpaTest/1.0/car,PersistenceUnitModule=jpaEntity.jar,j2eeType=PersistenceUnit,name=jpaEntity
to a gbean matching the pattern
[?name=OracleDS#org.apache.geronimo.naming.ResourceSource]
due to: No matches for referencePatterns:
[?name=OracleDS#org.apache.geronimo.naming.ResourceSource]
Unable to resolve reference "JtaDataSourceWrapper"
in gbean
default/jpaTest/1.0/car?EJBModule=jpaFacade.jar,J2EEApplication=default/jpaTest/1.0/car,PersistenceUnitModule=jpaEntity.jar,j2eeType=PersistenceUnit,name=jpaEntity
to a gbean matching the pattern
[?name=OracleDS#org.apache.geronimo.naming.ResourceSource]
due to: No matches for referencePatterns:
[?name=OracleDS#org.apache.geronimo.naming.ResourceSource]

at

org.apache.geronimo.deployment.DeploymentContext.getConfigurationData(DeploymentContext.java:672)

at org.apache.geronimo.deployment.Deployer.install(Deployer.java:332)
at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:256)

at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:133)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at
org.apache.geronimo.gbean.runtime.ReflectionMethodInvoker.invoke(ReflectionMethodInvoker.java:34)
at
org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:124)
at
org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:867)
at
org.apache.geronimo.kernel.basic.BasicKernel.invoke(BasicKernel.java:239)
at
org.apache.geronimo.deployment.plugin.local.AbstractDeployCommand.doDeploy(AbstractDeployCommand.java:116)
at
org.apache.geronimo.deployment.plugin.local.DistributeCommand.run(DistributeCommand.java:61)
at java.lang.Thread.run(Unknown Source)

My understanding of a JTA data source is that it supports distributed
transactions (XA) and that a none JTA data source only supports local
transactions. I'm using the Oracle thin driver which supports both JTA and
none JTA transactions, therefore I have specified the same data source for
both transaction types.

Please advise.

Regards,

Chris

http://www.nabble.com/Could-not-resolve-reference-for-persistence-jpaEntity-org.apache.geronimo.persistence.PersistenceUnitGBean-tp24191944s134p24238070.html

pookie1973 wrote:
>
> I'm using Geronimo 2.1, I have an ear file containing an EJB project with
> a single stateless session bean and a JPA project containing four entity
> beans. When I export the ear file and deploy it to Geronimo via the
> console, I get:-
>
> At least one deployment
> problem:[org.apache.geronimo.common.DeploymentException: Could not resolve
> reference at deploy time for query
> ?name=persistence/jpaEntity#org.apache.geronimo.persistence.PersistenceUnitGBean.
> No GBean references found.]
> org.apache.geronimo.common.DeploymentException: At least one deployment
> problem:[org.apache.geronimo.common.DeploymentException: Could not resolve
> reference at deploy time for query
> ?name=persistence/jpaEntity#org.apache.geronimo.persistence.PersistenceUnitGBean.
> No GBean references found.]
> at
> org.apache.geronimo.persistence.builder.PersistenceUnitRefBuilder.buildNaming(PersistenceUnitRefBuilder.java:154)
> at
> org.apache.geronimo.j2ee.deployment.NamingBuilderCollection.buildNaming(NamingBuilderCollection.java:53)
> at
> org.apache.geronimo.openejb.deployment.EjbDeploymentBuilder.addEnc(EjbDeploymentBuilder.java:329)
> at
> org.apache.geronimo.openejb.deployment.EjbDeploymentBuilder.buildEnc(EjbDeploymentBuilder.java:294)
> at
> org.apache.geronimo.openejb.deployment.EjbModuleBuilder.addGBeans(EjbModuleBuilder.java:764)
> at
> org.apache.geronimo.j2ee.deployment.EARConfigBuilder.buildConfiguration(EARConfigBuilder.java:647)
> at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:254)
> at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:133)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
> at java.lang.reflect.Method.invoke(Unknown Source)
> at
> org.apache.geronimo.gbean.runtime.ReflectionMethodInvoker.invoke(ReflectionMethodInvoker.java:34)
> at
> org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:124)
> at
> org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:867)
> at
> org.apache.geronimo.kernel.basic.BasicKernel.invoke(BasicKernel.java:239)
> at
> org.apache.geronimo.deployment.plugin.local.AbstractDeployCommand.doDeploy(AbstractDeployCommand.java:116)
> at
> org.apache.geronimo.deployment.plugin.local.DistributeCommand.run(DistributeCommand.java:61)
> at java.lang.Thread.run(Unknown Source)
>
> I searched the internet in order to see if anyone else encountered this
> issue. I found that Shawn (Jiang) responded to someone who had exactly the
> same issue as myself on IBM DeveloperWorks. Shawn asked for the EAR
> package structure, here it is:-
>
> Top level:-
>
> META-INF/MANIFEST.MF
> /geronimo-application.xml
> jpaFacadeClient.jar
> jpaFacade.jar
> jpaEntity.jar
>
> If I unzip the ear file and run a jar tvf on the jpaEntity.jar file I
> have:-
>
> C:\jpaTestEAR\jpaEntity>jar tvf jpaEntity.jar
> 58 Wed Jun 24 12:31:06 BST 2009 META-INF/MANIFEST.MF
> 0 Tue Jun 23 22:12:06 BST 2009 com/jpaEntity/
> 313 Tue Jun 23 22:08:26 BST 2009 META-INF/orm.xml
> 0 Tue Jun 23 22:08:26 BST 2009 META-INF/
> 1654 Wed Jun 24 14:00:16 BST 2009 com/jpaEntity/test/Dept.class
> 1353 Wed Jun 24 14:00:16 BST 2009 com/jpaEntity/test/Bonus.class
> 0 Tue Jun 23 22:12:42 BST 2009 com/jpaEntity/test/
> 0 Tue Jun 23 22:12:06 BST 2009 com/
> 686 Wed Jun 24 13:52:16 BST 2009 META-INF/persistence.xml
> 1124 Wed Jun 24 14:00:16 BST 2009 com/jpaEntity/test/Salgrade.class
> 2702 Wed Jun 24 14:00:16 BST 2009 com/jpaEntity/test/Emp.class
>
> Shawn also requested the EAR file, which I will attach. Previously I had
> attempted to deploy this directly to the app server from Eclipse and I
> wasn't getting as far as this. I posted a question to which Shawn
> responded, I did not reply to this as my second son was born on Monday,
> hence I was a tad proccupied with other things, so Shawn is you read this
> I wasn't blanking you out, but many thanks for responding my last question
> in such a prompt manner anyway.
> http://www.nabble.com/file/p24191944/jpaTestEAR.ear jpaTestEAR.ear
>

--

View this message in context: http://www.nabble.com/Could-not-resolve-reference-for-persistence-jpaEntity-org.apache.geronimo.persistence.PersistenceUnitGBean-tp24191944s134p24314829.html

Sent from the Apache Geronimo - Users mailing list archive at Nabble.com.

--
Shawn

-Shawn

Re: Performance tuning...

2009-07-03T03:49:37Z

Any log about your errors? And some suggestions: maximize your OS tcp connections and open file descriptors, on linux:
modify /etc/sysctl.conf with net.ipv4.ip_local_port_range = 1024 65000 ,this will promise about 6000 tcp connections and run sysctl -p to check whether this setting works fine.

modify /etc/security/limits.conf with
root soft nofile 10240 #you can change 10240 as you would like
root hard nofile 10240

edit /etc/pam.d/login with
session required pam_limits.so

Pls try it!

appel wrote:

Hi

I am in need of performance tuning my Geronimo (Jetty) server to accommodate for a specific type of load burst.

The behavior I need to tune Geronimo to handle goes something like this:

- Every minute, 3000 unique clients will load up a set of 4 pages.
- This happens every minute for 10 minutes, so all in all there are 30.000 unique clients that will try to connect and request those 4 pages over a period of 10 minutes.

The pages are very plain, two html pages, two jsp pages that do minimum stuff.

The bottleneck here is the number of clients.

How can I performance tune Geronimo (Jetty container) to handle this type of high client load?

(I've already increased the max-threads to 500, but when I do performance load-test in JMeter I get lots of errors.)

Thanks.

Performance tuning...

2009-07-03T03:31:04Z

Hi

I am in need of performance tuning my Geronimo (Jetty) server to accommodate for a specific type of load burst.

The behavior I need to tune Geronimo to handle goes something like this:

- Every minute, 3000 unique clients will load up a set of 4 pages.
- This happens every minute for 10 minutes, so all in all there are 30.000 unique clients that will try to connect and request those 4 pages over a period of 10 minutes.

The pages are very plain, two html pages, two jsp pages that do minimum stuff.

The bottleneck here is the number of clients.

How can I performance tune Geronimo (Jetty container) to handle this type of high client load?

(I've already increased the max-threads to 500, but when I do performance load-test in JMeter I get lots of errors.)

Thanks.

Re: Could not resolve reference for persistence/jpaEntity#org.apache.geronimo.persistence.PersistenceUnitGBean

2009-07-02T15:16:35Z

Shawn,

I've added a none JTA data source to the persistence.xml, and changed the transaction type to resource local, I now get:-

Unable to resolve reference "NonJtaDataSourceWrapper"
in gbean default/jpaTest/1.0/car?EJBModule=jpaFacade.jar,J2EEApplication=default/jpaTest/1.0/car,PersistenceUnitModule=jpaEntity.jar,j2eeType=PersistenceUnit,name=jpaEntity
to a gbean matching the pattern [?name=OracleDS#org.apache.geronimo.naming.ResourceSource]
due to: No matches for referencePatterns: [?name=OracleDS#org.apache.geronimo.naming.ResourceSource]
Unable to resolve reference "JtaDataSourceWrapper"
in gbean default/jpaTest/1.0/car?EJBModule=jpaFacade.jar,J2EEApplication=default/jpaTest/1.0/car,PersistenceUnitModule=jpaEntity.jar,j2eeType=PersistenceUnit,name=jpaEntity
to a gbean matching the pattern [?name=OracleDS#org.apache.geronimo.naming.ResourceSource]
due to: No matches for referencePatterns: [?name=OracleDS#org.apache.geronimo.naming.ResourceSource]
org.apache.geronimo.common.DeploymentException: Unable to resolve reference "NonJtaDataSourceWrapper"
in gbean default/jpaTest/1.0/car?EJBModule=jpaFacade.jar,J2EEApplication=default/jpaTest/1.0/car,PersistenceUnitModule=jpaEntity.jar,j2eeType=PersistenceUnit,name=jpaEntity
to a gbean matching the pattern [?name=OracleDS#org.apache.geronimo.naming.ResourceSource]
due to: No matches for referencePatterns: [?name=OracleDS#org.apache.geronimo.naming.ResourceSource]
Unable to resolve reference "JtaDataSourceWrapper"
in gbean default/jpaTest/1.0/car?EJBModule=jpaFacade.jar,J2EEApplication=default/jpaTest/1.0/car,PersistenceUnitModule=jpaEntity.jar,j2eeType=PersistenceUnit,name=jpaEntity
to a gbean matching the pattern [?name=OracleDS#org.apache.geronimo.naming.ResourceSource]
due to: No matches for referencePatterns: [?name=OracleDS#org.apache.geronimo.naming.ResourceSource]
at org.apache.geronimo.deployment.DeploymentContext.getConfigurationData(DeploymentContext.java:672)
at org.apache.geronimo.deployment.Deployer.install(Deployer.java:332)
at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:256)
at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:133)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at org.apache.geronimo.gbean.runtime.ReflectionMethodInvoker.invoke(ReflectionMethodInvoker.java:34)
at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:124)
at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:867)
at org.apache.geronimo.kernel.basic.BasicKernel.invoke(BasicKernel.java:239)
at org.apache.geronimo.deployment.plugin.local.AbstractDeployCommand.doDeploy(AbstractDeployCommand.java:116)
at org.apache.geronimo.deployment.plugin.local.DistributeCommand.run(DistributeCommand.java:61)
at java.lang.Thread.run(Unknown Source)

My understanding of a JTA data source is that it supports distributed transactions (XA) and that a none JTA data source only supports local transactions. I'm using the Oracle thin driver which supports both JTA and none JTA transactions, therefore I have specified the same data source for both transaction types.

Please advise.

Regards,

Chris

http://www.nabble.com/Could-not-resolve-reference-for-persistence-jpaEntity-org.apache.geronimo.persistence.PersistenceUnitGBean-tp24191944s134p24238070.html

pookie1973 wrote:

I'm using Geronimo 2.1, I have an ear file containing an EJB project with a single stateless session bean and a JPA project containing four entity beans. When I export the ear file and deploy it to Geronimo via the console, I get:-

At least one deployment problem:[org.apache.geronimo.common.DeploymentException: Could not resolve reference at deploy time for query ?name=persistence/jpaEntity#org.apache.geronimo.persistence.PersistenceUnitGBean. No GBean references found.]
org.apache.geronimo.common.DeploymentException: At least one deployment problem:[org.apache.geronimo.common.DeploymentException: Could not resolve reference at deploy time for query ?name=persistence/jpaEntity#org.apache.geronimo.persistence.PersistenceUnitGBean. No GBean references found.]
at org.apache.geronimo.persistence.builder.PersistenceUnitRefBuilder.buildNaming(PersistenceUnitRefBuilder.java:154)
at org.apache.geronimo.j2ee.deployment.NamingBuilderCollection.buildNaming(NamingBuilderCollection.java:53)
at org.apache.geronimo.openejb.deployment.EjbDeploymentBuilder.addEnc(EjbDeploymentBuilder.java:329)
at org.apache.geronimo.openejb.deployment.EjbDeploymentBuilder.buildEnc(EjbDeploymentBuilder.java:294)
at org.apache.geronimo.openejb.deployment.EjbModuleBuilder.addGBeans(EjbModuleBuilder.java:764)
at org.apache.geronimo.j2ee.deployment.EARConfigBuilder.buildConfiguration(EARConfigBuilder.java:647)
at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:254)
at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:133)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at org.apache.geronimo.gbean.runtime.ReflectionMethodInvoker.invoke(ReflectionMethodInvoker.java:34)
at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:124)
at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:867)
at org.apache.geronimo.kernel.basic.BasicKernel.invoke(BasicKernel.java:239)
at org.apache.geronimo.deployment.plugin.local.AbstractDeployCommand.doDeploy(AbstractDeployCommand.java:116)
at org.apache.geronimo.deployment.plugin.local.DistributeCommand.run(DistributeCommand.java:61)
at java.lang.Thread.run(Unknown Source)

I searched the internet in order to see if anyone else encountered this issue. I found that Shawn (Jiang) responded to someone who had exactly the same issue as myself on IBM DeveloperWorks. Shawn asked for the EAR package structure, here it is:-

Top level:-

META-INF/MANIFEST.MF
/geronimo-application.xml
jpaFacadeClient.jar
jpaFacade.jar
jpaEntity.jar

If I unzip the ear file and run a jar tvf on the jpaEntity.jar file I have:-

C:\jpaTestEAR\jpaEntity>jar tvf jpaEntity.jar
58 Wed Jun 24 12:31:06 BST 2009 META-INF/MANIFEST.MF
0 Tue Jun 23 22:12:06 BST 2009 com/jpaEntity/
313 Tue Jun 23 22:08:26 BST 2009 META-INF/orm.xml
0 Tue Jun 23 22:08:26 BST 2009 META-INF/
1654 Wed Jun 24 14:00:16 BST 2009 com/jpaEntity/test/Dept.class
1353 Wed Jun 24 14:00:16 BST 2009 com/jpaEntity/test/Bonus.class
0 Tue Jun 23 22:12:42 BST 2009 com/jpaEntity/test/
0 Tue Jun 23 22:12:06 BST 2009 com/
686 Wed Jun 24 13:52:16 BST 2009 META-INF/persistence.xml
1124 Wed Jun 24 14:00:16 BST 2009 com/jpaEntity/test/Salgrade.class
2702 Wed Jun 24 14:00:16 BST 2009 com/jpaEntity/test/Emp.class

Shawn also requested the EAR file, which I will attach. Previously I had attempted to deploy this directly to the app server from Eclipse and I wasn't getting as far as this. I posted a question to which Shawn responded, I did not reply to this as my second son was born on Monday, hence I was a tad proccupied with other things, so Shawn is you read this I wasn't blanking you out, but many thanks for responding my last question in such a prompt manner anyway.jpaTestEAR.ear

Re: Problem with Eclipse Galileo

2009-07-02T11:06:29Z

The nightly/unstable/unreleased builds are under:

http://people.apache.org/dist/geronimo/eclipse/unstable/

For GEP 2.1.5 (which support 2.0.x and 2.1.x servers) you'd want:
http://people.apache.org/dist/geronimo/eclipse/unstable/2.1.5/geronimo-eclipse-plugin-2.1.5-deployable.zip

-Donald

Ivan Babanin wrote:
> Thank you for link, but there is no such directory:
> http://apache.org/dist/geronimo/eclipse/2.2/. I tried 2.1.4, but I got
> the same error.
>

Re: Problem with Eclipse Galileo

2009-07-02T10:32:38Z

Thank you for link, but there is no such directory:
http://apache.org/dist/geronimo/eclipse/2.2/. I tried 2.1.4, but I got
the same error.

--
Ivan Babanin

Re: ClassCastException with Log4J when Running Multiple Ears

2009-07-02T07:18:54Z

Since the log4j jar is in your web module.

Have you tried to add hidden-classes in your WAR/WEB-INF/geronimo-web.xml ?

Greythorn wrote:

Scenario: I deploy two ear files. The first application I can access successfully, the application's logging working fine (to console and log file).

When I access the second application I get a class cast exception on the very first call to Log4J's Logger.getLogger(). The first application still works.

If I restart Geronimo and access the applications in the REVERSE order, I get the same error, i.e. the first application I hit works (and continues to work) but the second fails.

Also, the Server Log Viewer now gives an ArrayIndexOutOfBoundsException exception:

java.lang.ArrayIndexOutOfBoundsException: 0
at org.apache.geronimo.console.logmanager.LogViewerPortlet.doView(LogViewerPortlet.java:107)
at javax.portlet.GenericPortlet.doDispatch(GenericPortlet.java:247)
at javax.portlet.GenericPortlet.render(GenericPortlet.java:175)
at org.apache.geronimo.console.BasePortlet.render(BasePortlet.java:125)
at org.apache.pluto.core.PortletServlet.dispatch(PortletServlet.java:208)
at org.apache.pluto.core.PortletServlet.doGet(PortletServlet.java:139)

Both ears contain a single web module each using its own log4j.jar (same version as Geronimo).

I have tried using the hidden-classes tag in geronimo-application.xml for the org.apache.log4j packages. Same error.

I have added the inverse-classloading tag to the geronimo-application.xml. Same error.

I have tried removing the log4j jars from the applications to force them to use Geronimo's log4j jar. Same error.

Have deployed via the console. Same error.

I'm obviously missing something (hopefully something straight forward) but what?

Any ideas?

-Shawn

ClassCastException with Log4J when Running Multiple Ears

2009-07-02T02:58:43Z

Scenario: I deploy two ear files. The first application I can access successfully, the application's logging working fine (to console and log file).

When I access the second application I get a class cast exception on the very first call to Log4J's Logger.getLogger(). The first application still works.

If I restart Geronimo and access the applications in the REVERSE order, I get the same error, i.e. the first application I hit works (and continues to work) but the second fails.

Also, the Server Log Viewer now gives an ArrayIndexOutOfBoundsException exception:

java.lang.ArrayIndexOutOfBoundsException: 0
at org.apache.geronimo.console.logmanager.LogViewerPortlet.doView(LogViewerPortlet.java:107)
at javax.portlet.GenericPortlet.doDispatch(GenericPortlet.java:247)
at javax.portlet.GenericPortlet.render(GenericPortlet.java:175)
at org.apache.geronimo.console.BasePortlet.render(BasePortlet.java:125)
at org.apache.pluto.core.PortletServlet.dispatch(PortletServlet.java:208)
at org.apache.pluto.core.PortletServlet.doGet(PortletServlet.java:139)

Both ears contain a single web module each using its own log4j.jar (same version as Geronimo).

I have tried using the hidden-classes tag in geronimo-application.xml for the org.apache.log4j packages. Same error.

I have added the inverse-classloading tag to the geronimo-application.xml. Same error.

I have tried removing the log4j jars from the applications to force them to use Geronimo's log4j jar. Same error.

Have deployed via the console. Same error.

I'm obviously missing something (hopefully something straight forward) but what?

Any ideas?

Re: Problem with Eclipse Galileo

2009-07-02T01:58:08Z

And document on how to use deployable.zip and updatesites.zip goes to

http://cwiki.apache.org/GMOxDOC22/installing-geronimo-eclipse-plugin.html#InstallingGeronimoEclipsePlugin-ManualInstallation

Any questions, just let us know.

Jeff C

On Thu, Jul 2, 2009 at 5:26 AM, Donald Woods <dwoods@...> wrote:

The 2.1.4 plugin does not support Galileo...

You'll need to install one of the nightly/unstable builds of 2.1.5 plugin until it is released. See [1] for details.

[1]http://geronimo.apache.org/development-tools.html#DevelopmentTools-NightlyBuilds

-Donald

Ivan Babanin wrote:

Hello! Plz help me. When i try to set up Apache Geronimo Server
Adapter 2.1 in Eclipse Galileo i got the following error:

Cannot complete the install because one or more required items could
not be found.
Software being installed: Geronimo v2.1 Server Adapter 2.1.4
(org.apache.geronimo.v21.feature.feature.group 2.1.4)
Missing requirement: Geronimo v2.1 Server Adapter 2.1.4
(org.apache.geronimo.v21.feature.feature.group 2.1.4) requires
'org.eclipse.jst.common_core.feature.feature.group
2.0.0.v200706041905-1007w311817231426' but it could not be found

How to solve this problem?

Re: GShell deploy/redeploy problem?

2009-07-02T01:51:39Z

hi Eric, I tried it in G2.1.4, and no problem with that. Try 2.1.4?

-Rex

2009/7/1 ericp56 <eric.phetteplace@...>

Hello.

Using Geronimo 2.1.3

I issued a simple redeploy in GShell from my Windows destkop to a Linux
Server:

eric@workstation:/> deploy/redeploy -u admin -w password -s linuxServer
c:\\te
mp\\__IVRFrameworkHttp.war
No ModuleID or TargetModuleID provided. Attempting to guess based
on the content of the archive.
Attempting to use ModuleID 'twcable/IVRFrameworkHttp/1.0/car'
Stopped twcable/IVRFrameworkHttp/1.0/car
Unloaded twcable/IVRFrameworkHttp/1.0/car
Uninstalled twcable/IVRFrameworkHttp/1.0/car
Uploading 1 file(s) to server
Uploading __IVRFrameworkHttp.war: 11 KB
Uploading __IVRFrameworkHttp.war: 21 KB
Uploading __IVRFrameworkHttp.war: 31 KB
File upload complete (Server status=OK)
File(s) transferred to server. Resuming deployment operation.
Deployed twcable/IVRFrameworkHttp/1.0/car
Started twcable/IVRFrameworkHttp/1.0/car
Redeployed twcable/IVRFrameworkHttp/1.0/car
eric@workstation:/>

It looks like it redeployed, but when I inspect the files in the repository
on the linux server, the project has NOT been redeployed!

If I use the "Deploy New" Web page on the server, the redeployment works
fine.

Any suggestions?

--
View this message in context: http://www.nabble.com/GShell-deploy-redeploy-problem--tp24290474s134p24290474.html
Sent from the Apache Geronimo - Users mailing list archive at Nabble.com.

Re: Geronimo2.1.0 build failure with Java5 (method getContentType() not found)

2009-07-01T22:44:01Z

Heh. Interesting. I would have thought if we made it that far, config.xml would be a piece of cake... By the way, what version of Geronimo are you building?

I used the 2.1.4 source of Geronimo.

Regards,
Mohan

On Wed, Jul 1, 2009 at 10:35 PM, Kevan Miller <kevan.miller@...> wrote:

On Jul 1, 2009, at 2:09 AM, Mohanraj Loganathan wrote:

Geronimo Binary built by Harmony is not as equivalent to the binary built by SUN JDK. var/config/config.xml file is empty and few other config files also empty. No idea why harmony build binary has empty config files. Any thoughts on this?

Heh. Interesting. I would have thought if we made it that far, config.xml would be a piece of cake... By the way, what version of Geronimo are you building?

I replaced the config files from SunJDK built geronimo binary and followed the steps mentioned here to start the server using HARMONY Java. Server sucessfully started.

Great!

As mentioned in the page when i passed the argument -Djava.naming.factory.url.pkgs=org.apache.harmony.jndi.provider to java tests are run continuously. Now tests are running fine. But found few test failures. I will be analyse these failures further.

Thanks for the update!

--kevan

--
Mohan

Re: OpenEJB encountered an unknown system error in container:

2009-07-01T18:58:02Z

The tranql wrapper should be dealing with the autocommit state of the
connection automatically. Is there any chance your code called
setAutocommit(true)? Were there any sql errors before this?

Which tranql wrapper are you using? I expect its the generic one but
it doesn't hurt to check.

thanks
david jencks

On Jul 1, 2009, at 4:11 PM, David Blevins wrote:

> On Jun 23, 2009, at 7:46 AM, Michael Simons wrote:
>
>> Caused by: javax.resource.spi.LocalTransactionException: Unable to
>> rollback
>> at
>> org
>> .tranql
>> .connector
>> .jdbc
>> .ManagedJDBCConnection
>> .localTransactionRollback(ManagedJDBCConnection.java:113)
>> at
>> org.tranql.connector.AbstractManagedConnection
>> $LocalTransactionImpl.rollback(AbstractManagedConnection.java:197)
>> at
>> org
>> .apache
>> .geronimo
>> .connector.outbound.LocalXAResource.rollback(LocalXAResource.java:86)
>> ... 20 more
>> Caused by: java.sql.SQLException: rollback() should not be called
>> while in auto-commit mode.
>> at
>> net
>> .sourceforge
>> .jtds.jdbc.ConnectionJDBC2.rollback(ConnectionJDBC2.java:2031)
>> at
>> org
>> .tranql
>> .connector
>> .jdbc
>> .ManagedJDBCConnection
>> .localTransactionRollback(ManagedJDBCConnection.java:111)
>> ... 22 more
>
> This seems to be the root exception right here. Looks like the
> driver is complaining that rollback should not be used when the
> driver is setup with auto-commit enabled. Not familiar with the
> driver, but definitely auto-commit needs to be off for any
> environment with a transaction manager.
>
> Hope this helps!
>
> -David
>

Re: OpenEJB encountered an unknown system error in container:

2009-07-01T16:11:07Z

On Jun 23, 2009, at 7:46 AM, Michael Simons wrote:

> Caused by: javax.resource.spi.LocalTransactionException: Unable to
> rollback
> at
> org
> .tranql
> .connector
> .jdbc
> .ManagedJDBCConnection
> .localTransactionRollback(ManagedJDBCConnection.java:113)
> at
> org.tranql.connector.AbstractManagedConnection
> $LocalTransactionImpl.rollback(AbstractManagedConnection.java:197)
> at
> org
> .apache
> .geronimo
> .connector.outbound.LocalXAResource.rollback(LocalXAResource.java:86)
> ... 20 more
> Caused by: java.sql.SQLException: rollback() should not be called
> while in auto-commit mode.
> at
> net
> .sourceforge.jtds.jdbc.ConnectionJDBC2.rollback(ConnectionJDBC2.java:
> 2031)
> at
> org
> .tranql
> .connector
> .jdbc
> .ManagedJDBCConnection
> .localTransactionRollback(ManagedJDBCConnection.java:111)
> ... 22 more

This seems to be the root exception right here. Looks like the driver
is complaining that rollback should not be used when the driver is
setup with auto-commit enabled. Not familiar with the driver, but
definitely auto-commit needs to be off for any environment with a
transaction manager.

Hope this helps!

-David

Re: Problem with Eclipse Galileo

2009-07-01T14:26:43Z

The 2.1.4 plugin does not support Galileo...

You'll need to install one of the nightly/unstable builds of 2.1.5
plugin until it is released. See [1] for details.

[1]http://geronimo.apache.org/development-tools.html#DevelopmentTools-NightlyBuilds

-Donald

Ivan Babanin wrote:

> Hello! Plz help me. When i try to set up Apache Geronimo Server
> Adapter 2.1 in Eclipse Galileo i got the following error:
>
> Cannot complete the install because one or more required items could
> not be found.
> Software being installed: Geronimo v2.1 Server Adapter 2.1.4
> (org.apache.geronimo.v21.feature.feature.group 2.1.4)
> Missing requirement: Geronimo v2.1 Server Adapter 2.1.4
> (org.apache.geronimo.v21.feature.feature.group 2.1.4) requires
> 'org.eclipse.jst.common_core.feature.feature.group
> 2.0.0.v200706041905-1007w311817231426' but it could not be found
>
> How to solve this problem?
>

Problem with Eclipse Galileo

2009-07-01T12:29:46Z

Hello! Plz help me. When i try to set up Apache Geronimo Server
Adapter 2.1 in Eclipse Galileo i got the following error:

Cannot complete the install because one or more required items could
not be found.
Software being installed: Geronimo v2.1 Server Adapter 2.1.4
(org.apache.geronimo.v21.feature.feature.group 2.1.4)
Missing requirement: Geronimo v2.1 Server Adapter 2.1.4
(org.apache.geronimo.v21.feature.feature.group 2.1.4) requires
'org.eclipse.jst.common_core.feature.feature.group
2.0.0.v200706041905-1007w311817231426' but it could not be found

How to solve this problem?

--
Ivan Babanin

Re: Geronimo2.1.0 build failure with Java5 (method getContentType() not found)

2009-07-01T10:05:54Z

On Jul 1, 2009, at 2:09 AM, Mohanraj Loganathan wrote:

Geronimo Binary built by Harmony is not as equivalent to the binary built by SUN JDK. var/config/config.xml file is empty and few other config files also empty. No idea why harmony build binary has empty config files. Any thoughts on this?

Heh. Interesting. I would have thought if we made it that far, config.xml would be a piece of cake... By the way, what version of Geronimo are you building?

I replaced the config files from SunJDK built geronimo binary and followed the steps mentioned here to start the server using HARMONY Java. Server sucessfully started.

Great!

As mentioned in the page when i passed the argument -Djava.naming.factory.url.pkgs=org.apache.harmony.jndi.provider to java tests are run continuously. Now tests are running fine. But found few test failures. I will be analyse these failures further.

Thanks for the update!

--kevan

GShell deploy/redeploy problem?

2009-07-01T07:10:18Z

Hello.

Using Geronimo 2.1.3

I issued a simple redeploy in GShell from my Windows destkop to a Linux Server:

eric@workstation:/> deploy/redeploy -u admin -w password -s linuxServer c:\\te
mp\\__IVRFrameworkHttp.war
No ModuleID or TargetModuleID provided. Attempting to guess based
on the content of the archive.
Attempting to use ModuleID 'twcable/IVRFrameworkHttp/1.0/car'
Stopped twcable/IVRFrameworkHttp/1.0/car
Unloaded twcable/IVRFrameworkHttp/1.0/car
Uninstalled twcable/IVRFrameworkHttp/1.0/car
Uploading 1 file(s) to server
Uploading __IVRFrameworkHttp.war: 11 KB
Uploading __IVRFrameworkHttp.war: 21 KB
Uploading __IVRFrameworkHttp.war: 31 KB
File upload complete (Server status=OK)
File(s) transferred to server. Resuming deployment operation.
Deployed twcable/IVRFrameworkHttp/1.0/car
Started twcable/IVRFrameworkHttp/1.0/car
Redeployed twcable/IVRFrameworkHttp/1.0/car
eric@workstation:/>

It looks like it redeployed, but when I inspect the files in the repository on the linux server, the project has NOT been redeployed!

If I use the "Deploy New" Web page on the server, the redeployment works fine.

Any suggestions?

Re: accessing the administration console error

2009-07-01T01:49:44Z

Hi SShehab, please try v2.1.4.

Here is the download url: http://geronimo.apache.org/apache-geronimo-v214-release.html

Jeff C

On Wed, Jul 1, 2009 at 4:07 PM, SShehab <sherif.shehab@...> wrote:

Hi Guys ,

when i'm trying to access the administration console for geronimo v2.0
this exception occurs after writing the username and password :

HTTP Status 500 -

type Exception report

message

description The server encountered an internal error () that prevented it
from fulfilling this request.

exception

javax.servlet.ServletException: Servlet.init() for servlet se-console threw
exception

org.apache.geronimo.tomcat.valve.DefaultSubjectValve.invoke(DefaultSubjectValve.java:56)

org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:525)

org.apache.geronimo.tomcat.GeronimoStandardContext$SystemMethodValve.invoke(GeronimoStandardContext.java:338)

org.apache.geronimo.tomcat.valve.GeronimoBeforeAfterValve.invoke(GeronimoBeforeAfterValve.java:47)

org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105)
org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:517)
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:212)
org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:844)

org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:634)
org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:445)
java.lang.Thread.run(Thread.java:619)
root cause

java.lang.NullPointerException

org.apache.pluto.portalImpl.core.PortletContainerEnvironment.addContainerService(PortletContainerEnvironment.java:46)
org.apache.pluto.portalImpl.Servlet.init(Servlet.java:113)

org.apache.geronimo.tomcat.valve.DefaultSubjectValve.invoke(DefaultSubjectValve.java:56)

org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:525)

org.apache.geronimo.tomcat.GeronimoStandardContext$SystemMethodValve.invoke(GeronimoStandardContext.java:338)

org.apache.geronimo.tomcat.valve.GeronimoBeforeAfterValve.invoke(GeronimoBeforeAfterValve.java:47)

org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105)
org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:517)
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:212)
org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:844)

org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:634)
org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:445)
java.lang.Thread.run(Thread.java:619)
note The full stack trace of the root cause is available in the Apache
Tomcat/6.0.0-dev logs.

Any explanations ? :-(

--
View this message in context: http://www.nabble.com/accessing-the-administration-console-error-tp24285826s134p24285826.html
Sent from the Apache Geronimo - Users mailing list archive at Nabble.com.

accessing the administration console error

2009-07-01T01:07:19Z

Hi Guys ,

when i'm trying to access the administration console for geronimo v2.0 this exception occurs after writing the username and password :

HTTP Status 500 -

type Exception report

message

description The server encountered an internal error () that prevented it from fulfilling this request.

exception

javax.servlet.ServletException: Servlet.init() for servlet se-console threw exception
org.apache.geronimo.tomcat.valve.DefaultSubjectValve.invoke(DefaultSubjectValve.java:56)
org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:525)
org.apache.geronimo.tomcat.GeronimoStandardContext$SystemMethodValve.invoke(GeronimoStandardContext.java:338)
org.apache.geronimo.tomcat.valve.GeronimoBeforeAfterValve.invoke(GeronimoBeforeAfterValve.java:47)
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105)
org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:517)
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:212)
org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:844)
org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:634)
org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:445)
java.lang.Thread.run(Thread.java:619)
root cause

java.lang.NullPointerException
org.apache.pluto.portalImpl.core.PortletContainerEnvironment.addContainerService(PortletContainerEnvironment.java:46)
org.apache.pluto.portalImpl.Servlet.init(Servlet.java:113)
org.apache.geronimo.tomcat.valve.DefaultSubjectValve.invoke(DefaultSubjectValve.java:56)
org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:525)
org.apache.geronimo.tomcat.GeronimoStandardContext$SystemMethodValve.invoke(GeronimoStandardContext.java:338)
org.apache.geronimo.tomcat.valve.GeronimoBeforeAfterValve.invoke(GeronimoBeforeAfterValve.java:47)
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105)
org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:517)
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:212)
org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:844)
org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:634)
org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:445)
java.lang.Thread.run(Thread.java:619)
note The full stack trace of the root cause is available in the Apache Tomcat/6.0.0-dev logs.

Any explanations ?

Re: Geronimo2.1.0 build failure with Java5 (method getContentType() not found)

2009-06-30T23:09:25Z

Geronimo Binary built by Harmony is not as equivalent to the binary built by SUN JDK. var/config/config.xml file is empty and few other config files also empty. No idea why harmony build binary has empty config files. Any thoughts on this?

I replaced the config files from SunJDK built geronimo binary and followed the steps mentioned here to start the server using HARMONY Java. Server sucessfully started.

As mentioned in the page when i passed the argument -Djava.naming.factory.url.pkgs=org.apache.harmony.jndi.provider to java tests are run continuously. Now tests are running fine. But found few test failures. I will be analyse these failures further.

Thanks and regards,
Mohan

On Mon, Jun 22, 2009 at 1:37 PM, Jack Cai <greensight@...> wrote:

Harmony use MX4J, which implements JSR 003 and 160 (remote API). So I suppose the jmx remoting function is there.

Mohan, can you start the server built with Harmony in command line? ie., use "startup" command for example.

-Jack

On Mon, Jun 22, 2009 at 12:33 AM, Kevan Miller <kevan.miller@...> wrote:

On Jun 21, 2009, at 12:04 PM, David Jencks wrote:

On Jun 21, 2009, at 2:29 AM, Mohanraj Loganathan wrote:

Hello

After a long time, i could able to build the geronimo using Harmony JDK. But Building was not so smooth. I need to build the modules one by one. I struck at running the testsuites module ..

It is failed to verify the Geronimo server start. But i am sure server is started. Server logs shows that server is up and running. But build script while running the command-testsuite failed to detect the server start. Any help would be much appreciated. Please note, Harmony doesnt implement JPA.

umm, neither does any other vm, not sure what you mean here. Maybe it doesn't implement java agents or not the same way?

IIRC, Harmony does not support -javaagent. You can run OpenJPA without it, but I think we'll run into a number of problems without -javaagent support.

I wonder if harmony implements jmx remoting? checking whether the server started relies on this.

Sounds like a reasonable guess...

--kevan

--
Mohan

Re: Deployment Plan for Tomcat?

2009-06-30T18:19:06Z

On Jun 30, 2009, at 4:29 PM, caof2005 wrote:

>
> Hello Friends,
>
> With an easy question I haven´t found any reference to this:
>
> What is the official name the deployment plan for Tomcat?
>
> I know that the name for the Jetty container is: geronimo-jetty.xml,
> but I
> don´t know which is the one for Tomcat.
>
> Does any body knows this? Also any reference to know more about
> deployment
> plans would be very appreciated.

There are a lot of choices. I prefer to use an external plan called
plan.xml. If you include the plan in the web app it can be called
geronimo-web.xml for either jetty or tomcat. For tomcat you can also
use geronimo-tomcat.xml. For these embedded plans it needs to be in
WEB-INF.

If your web app is part of an ear the web plan can also be in a
geronimo-application.xml for the ear or you can have an external plan
for the entire ear.

The most important things to specify are the name of the geronimo
plugin you are constructing (the "module-id"), the dependencies which
specify the classloader for your web app, and the context root. If
you have named datasources or ejbs badly you might need to map the
names specified in your web.xml or annotations to the actual names.
You can also specify a few tomcat specific features such as virtual
hosts IIRC.

hope this helps
david jencks

>
> Regards
> Carlos
>
> --
> View this message in context: http://www.nabble.com/Deployment-Plan-for-Tomcat--tp24281634s134p24281634.html
> Sent from the Apache Geronimo - Users mailing list archive at
> Nabble.com.
>

Deployment Plan for Tomcat?

2009-06-30T16:29:32Z

Hello Friends,

With an easy question I haven´t found any reference to this:

What is the official name the deployment plan for Tomcat?

I know that the name for the Jetty container is: geronimo-jetty.xml, but I don´t know which is the one for Tomcat.

Does any body knows this? Also any reference to know more about deployment plans would be very appreciated.

Regards
Carlos

WebService Problem

2009-06-30T04:38:37Z

Hi,

I'm trying to create a simple webservice (for which the WSDL should be
created automatically). I use this code...

@Remote(IService.class)
@Stateless
@WebService
public class Service {
public void doSomething(A a) {
// do Something with a
}
}

My problem is, that the generated wsdl doesn't reflect the class A
correctly. A is like...

public class A {
private List<B> b;
private List<C> c;
// etc. (including getters)
}

...but in the wsdl, A is only modelled as a simple object without any
fields. Does anyone know what I have to change here to allow geronimo
automatically create a correct wsdl?

Bye,

Flo
--
OPTITOOL GmbH

Bruderwöhrdstr. 15b
D - 93055 Regensburg

T: +49-941-59578-13

eMail: florian.schaetz@...
URL: www.optitool.de

Sitz der Gesellschaft: Regensburg
Registergericht Regensburg: HR B 9544

Re: Binaries not getting deleted while un-deploying axis2-1.4.1 war from Geronimo 2.1.4

2009-06-30T02:09:27Z

Thanks Kevan.
I deployed/undeployed axis2 - 1.5 and it works fine.

Anshuk

kevan wrote:

On Jun 26, 2009, at 5:40 AM, Anshuk wrote:

>
> Hi,
>
> I am trying to deploy/undeploy axis2 version 1.4.1. You can download
> the the
> distribution from
> http://apache.promopeddler.com/ws/axis2/1_4_1/axis2-1.4.1-war.zip
> and try to deploying the same.
>
> Deploy will not be any issue. While undeploying I am facing the
> mentioned
> issue/problem.
>
> Would really appreciate if you can look into it.

This same problem was reported some time ago. We (Tim) developed a
patch for Axis2 (it's Axis2 that is locking the files, not Geronimo).
See https://issues.apache.org/jira/browse/AXIS2-4072 -- I would assume
that this fix is included in their recent 1.5 release...

Rather than bundling web services support in your web app, I'd
recommend you use the web services supported provided by Geronimo.

--kevan

Upgrade ActiveMQ in Geronimo 2.1.4 to improve reliability

2009-06-29T04:22:52Z

Hi all,

I'm experiencing some reliability issues with ActiveMQ in G 2.1.4 in
combination with the application I'm working on now. Basically I see the same
three issues described in GERONIMO-4257[0]. Unfortunately I can't reproduce
the issues reliably, but still I'm not comfortable to put G into production at
its current state.

[0] https://issues.apache.org/jira/browse/GERONIMO-4257

As a stop gap solution before G 2.2 is stable I'm considering upgrading
ActiveMQ in G 2.1.4. Running with a stand alone broker using ActiveMQ 5.2 seems
to better, but I'm not entirely confident that we won't run into any unintended
classpath issues while still having ActiveMQ 4.1.2-G20090207 deployed in the
application server. Further It'd be convenient to have the 5.2 broker deployed
in the application server.

What I hope to elicit from you on this list is some feedback, is it reasonable,
etc...

So, here's my plan:

undeploy org.apache.geronimo.plugins/activemq-console-jetty/2.1.4/car
undeploy org.apache.geronimo.configs/activemq-ra/2.1.4/car
undeploy org.apache.geronimo.configs/activemq-broker/2.1.4/car

install-library org.apache.activemq/activemq-core/5.2.0/jar
install-library org.apache.activemq/activeio-core/3.1.0/jar
install-library org.apache.activemq/activemq-rar/5.2.0/jar

# Seems like openejb depends on activemq-broker so i now need to
# create a plugin that artifact-aliases ...configs/activemq-broker/2.1.4/car
# and starts a 5.2.0 broker.
deploy said module

#Is there a uninstall-library command, or is "rm -rf whatever" fine?
rm -rf $G/repository/org/apache/activemq/activemq-core/4.1.2-G20090207
rm -rf $G/repository/org/apache/activemq/activeio-core/3.0.1

That's pretty much it. Are there any glaring omissions in this plan? Anyone
else done anything similar before? Is it reasonable? Any feedback much
appreciated. Thanks!

--
Fredrik Jonson

Re: Getting current Subject in Geronimo 2.1

2009-06-28T05:58:30Z

Thanks David,

The JACC interfaces method works like a charm.
I wasn't precise enough. I'm getting Subject in servlet and I'm using Geronimo embedded in Websphere Application Server Community Edition.

Regards
Pawel

djencks wrote:

It's always been there when I look. Where are you trying to access it
from?

You can also use JACC interfaces

javax
..security
..jacc.PolicyContext.getContext("javax.security.auth.Subject.container");

david jencks

Re: Getting current Subject in Geronimo 2.1

2009-06-28T00:52:18Z

On Jun 27, 2009, at 12:49 PM, Pawel B wrote:

>
> Hi
>
> How to get the current subject in Geronimo 2.1? The
> org.apache.geronimo.security.ContextManager class seems to be not
> available.

It's always been there when I look. Where are you trying to access it
from?

You can also use JACC interfaces

javax
..security
..jacc.PolicyContext.getContext("javax.security.auth.Subject.container");

david jencks

>
> Regards
> Pawel
> --
> View this message in context: http://www.nabble.com/Getting-current-Subject-in-Geronimo-2.1-tp24236102s134p24236102.html
> Sent from the Apache Geronimo - Users mailing list archive at
> Nabble.com.
>

Re: Could not resolve reference for persistence/jpaEntity#org.apache.geronimo.persistence.PersistenceUnitGBean

2009-06-27T18:29:25Z

I have to add both JTA and NON-JTA datasource in persistence.xml when I deployed JPA with derby(IIRC). I don't know if deploying JPA with Oracle should do the same.

See how to add NON-JTA datasource here and give it a try.

http://cwiki.apache.org/confluence/display/GMOxDOC22/persistence.xml#persistence.xml-%3Cjtadatasource%3E%2C%3Cnonjtadatasource%3E

On Sun, Jun 28, 2009 at 3:48 AM, pookie1973 <christopher.adkin@...> wrote:

Shawn,

I added the module dependancy in Eclipse as advised and this has rectified
the issue persistence GBean. However, I have now run into another issue when
deploying, namely:-

Unable to resolve reference "JtaDataSourceWrapper"
in gbean
default/jpaTest/1.0/car?EJBModule=jpaFacade.jar,J2EEApplication=default/jpaTest/1.0/car,PersistenceUnitModule=jpaEntity.jar,j2eeType=PersistenceUnit,name=jpaEntity
to a gbean matching the pattern
[?name=OracleDS#org.apache.geronimo.naming.ResourceSource]
due to: No matches for referencePatterns:
[?name=OracleDS#org.apache.geronimo.naming.ResourceSource]
org.apache.geronimo.common.DeploymentException: Unable to resolve reference
"JtaDataSourceWrapper"
in gbean
default/jpaTest/1.0/car?EJBModule=jpaFacade.jar,J2EEApplication=default/jpaTest/1.0/car,PersistenceUnitModule=jpaEntity.jar,j2eeType=PersistenceUnit,name=jpaEntity
to a gbean matching the pattern
[?name=OracleDS#org.apache.geronimo.naming.ResourceSource]
due to: No matches for referencePatterns:
[?name=OracleDS#org.apache.geronimo.naming.ResourceSource]
at
org.apache.geronimo.deployment.DeploymentContext.getConfigurationData(DeploymentContext.java:672)
at org.apache.geronimo.deployment.Deployer.install(Deployer.java:332)
at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:256)

at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:133)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at
org.apache.geronimo.gbean.runtime.ReflectionMethodInvoker.invoke(ReflectionMethodInvoker.java:34)
at
org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:124)
at
org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:867)
at
org.apache.geronimo.kernel.basic.BasicKernel.invoke(BasicKernel.java:239)
at
org.apache.geronimo.deployment.plugin.local.AbstractDeployCommand.doDeploy(AbstractDeployCommand.java:116)
at
org.apache.geronimo.deployment.plugin.local.DistributeCommand.run(DistributeCommand.java:61)
at java.lang.Thread.run(Unknown Source)

It appears that other people have run into this issue, but I'm unable to
glean any useful information as to what the resolution to this is. Other
people that have reported this to forums and mailing groups have been
advised to:-

1. Make sure that the data source specificied in the persistence.xml is
actaully set up in the app server, in my case the data source is set up on
the app server.

2. The data source is listed as an application dependancy, I have already
done this.

Thanks for all your help so far, please advise as to how I can get past this
latest issue.

Regards,

Chris

pookie1973 wrote:
>
> I'm using Geronimo 2.1, I have an ear file containing an EJB project with
> a single stateless session bean and a JPA project containing four entity
> beans. When I export the ear file and deploy it to Geronimo via the
> console, I get:-
>
> At least one deployment
> problem:[org.apache.geronimo.common.DeploymentException: Could not resolve
> reference at deploy time for query
> ?name=persistence/jpaEntity#org.apache.geronimo.persistence.PersistenceUnitGBean.
> No GBean references found.]
> org.apache.geronimo.common.DeploymentException: At least one deployment
> problem:[org.apache.geronimo.common.DeploymentException: Could not resolve
> reference at deploy time for query
> ?name=persistence/jpaEntity#org.apache.geronimo.persistence.PersistenceUnitGBean.
> No GBean references found.]
> at
> org.apache.geronimo.persistence.builder.PersistenceUnitRefBuilder.buildNaming(PersistenceUnitRefBuilder.java:154)
> at
> org.apache.geronimo.j2ee.deployment.NamingBuilderCollection.buildNaming(NamingBuilderCollection.java:53)
> at
> org.apache.geronimo.openejb.deployment.EjbDeploymentBuilder.addEnc(EjbDeploymentBuilder.java:329)
> at
> org.apache.geronimo.openejb.deployment.EjbDeploymentBuilder.buildEnc(EjbDeploymentBuilder.java:294)
> at
> org.apache.geronimo.openejb.deployment.EjbModuleBuilder.addGBeans(EjbModuleBuilder.java:764)
> at
> org.apache.geronimo.j2ee.deployment.EARConfigBuilder.buildConfiguration(EARConfigBuilder.java:647)
> at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:254)
> at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:133)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
> at java.lang.reflect.Method.invoke(Unknown Source)
> at
> org.apache.geronimo.gbean.runtime.ReflectionMethodInvoker.invoke(ReflectionMethodInvoker.java:34)
> at
> org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:124)
> at
> org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:867)
> at
> org.apache.geronimo.kernel.basic.BasicKernel.invoke(BasicKernel.java:239)
> at
> org.apache.geronimo.deployment.plugin.local.AbstractDeployCommand.doDeploy(AbstractDeployCommand.java:116)
> at
> org.apache.geronimo.deployment.plugin.local.DistributeCommand.run(DistributeCommand.java:61)
> at java.lang.Thread.run(Unknown Source)
>
> I searched the internet in order to see if anyone else encountered this
> issue. I found that Shawn (Jiang) responded to someone who had exactly the
> same issue as myself on IBM DeveloperWorks. Shawn asked for the EAR
> package structure, here it is:-
>
> Top level:-
>
> META-INF/MANIFEST.MF
> /geronimo-application.xml
> jpaFacadeClient.jar
> jpaFacade.jar
> jpaEntity.jar
>
> If I unzip the ear file and run a jar tvf on the jpaEntity.jar file I
> have:-
>
> C:\jpaTestEAR\jpaEntity>jar tvf jpaEntity.jar
> 58 Wed Jun 24 12:31:06 BST 2009 META-INF/MANIFEST.MF
> 0 Tue Jun 23 22:12:06 BST 2009 com/jpaEntity/
> 313 Tue Jun 23 22:08:26 BST 2009 META-INF/orm.xml
> 0 Tue Jun 23 22:08:26 BST 2009 META-INF/
> 1654 Wed Jun 24 14:00:16 BST 2009 com/jpaEntity/test/Dept.class
> 1353 Wed Jun 24 14:00:16 BST 2009 com/jpaEntity/test/Bonus.class
> 0 Tue Jun 23 22:12:42 BST 2009 com/jpaEntity/test/
> 0 Tue Jun 23 22:12:06 BST 2009 com/
> 686 Wed Jun 24 13:52:16 BST 2009 META-INF/persistence.xml
> 1124 Wed Jun 24 14:00:16 BST 2009 com/jpaEntity/test/Salgrade.class
> 2702 Wed Jun 24 14:00:16 BST 2009 com/jpaEntity/test/Emp.class
>
> Shawn also requested the EAR file, which I will attach. Previously I had
> attempted to deploy this directly to the app server from Eclipse and I
> wasn't getting as far as this. I posted a question to which Shawn
> responded, I did not reply to this as my second son was born on Monday,
> hence I was a tad proccupied with other things, so Shawn is you read this
> I wasn't blanking you out, but many thanks for responding my last question
> in such a prompt manner anyway.
> http://www.nabble.com/file/p24191944/jpaTestEAR.ear jpaTestEAR.ear
>

--

View this message in context: http://www.nabble.com/Could-not-resolve-reference-for-persistence-jpaEntity-org.apache.geronimo.persistence.PersistenceUnitGBean-tp24191944s134p24236094.html

Sent from the Apache Geronimo - Users mailing list archive at Nabble.com.

--
Shawn

-Shawn

Getting current Subject in Geronimo 2.1

2009-06-27T12:49:47Z

Hi

How to get the current subject in Geronimo 2.1? The org.apache.geronimo.security.ContextManager class seems to be not available.

Regards
Pawel

Re: Could not resolve reference for persistence/jpaEntity#org.apache.geronimo.persistence.PersistenceUnitGBean

2009-06-27T12:48:40Z

Shawn,

I added the module dependancy in Eclipse as advised and this has rectified the issue persistence GBean. However, I have now run into another issue when deploying, namely:-

Unable to resolve reference "JtaDataSourceWrapper"
in gbean default/jpaTest/1.0/car?EJBModule=jpaFacade.jar,J2EEApplication=default/jpaTest/1.0/car,PersistenceUnitModule=jpaEntity.jar,j2eeType=PersistenceUnit,name=jpaEntity
to a gbean matching the pattern [?name=OracleDS#org.apache.geronimo.naming.ResourceSource]
due to: No matches for referencePatterns: [?name=OracleDS#org.apache.geronimo.naming.ResourceSource]
org.apache.geronimo.common.DeploymentException: Unable to resolve reference "JtaDataSourceWrapper"
in gbean default/jpaTest/1.0/car?EJBModule=jpaFacade.jar,J2EEApplication=default/jpaTest/1.0/car,PersistenceUnitModule=jpaEntity.jar,j2eeType=PersistenceUnit,name=jpaEntity
to a gbean matching the pattern [?name=OracleDS#org.apache.geronimo.naming.ResourceSource]
due to: No matches for referencePatterns: [?name=OracleDS#org.apache.geronimo.naming.ResourceSource]
at org.apache.geronimo.deployment.DeploymentContext.getConfigurationData(DeploymentContext.java:672)
at org.apache.geronimo.deployment.Deployer.install(Deployer.java:332)
at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:256)
at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:133)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at org.apache.geronimo.gbean.runtime.ReflectionMethodInvoker.invoke(ReflectionMethodInvoker.java:34)
at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:124)
at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:867)
at org.apache.geronimo.kernel.basic.BasicKernel.invoke(BasicKernel.java:239)
at org.apache.geronimo.deployment.plugin.local.AbstractDeployCommand.doDeploy(AbstractDeployCommand.java:116)
at org.apache.geronimo.deployment.plugin.local.DistributeCommand.run(DistributeCommand.java:61)
at java.lang.Thread.run(Unknown Source)

It appears that other people have run into this issue, but I'm unable to glean any useful information as to what the resolution to this is. Other people that have reported this to forums and mailing groups have been advised to:-

1. Make sure that the data source specificied in the persistence.xml is actaully set up in the app server, in my case the data source is set up on the app server.

2. The data source is listed as an application dependancy, I have already done this.

Thanks for all your help so far, please advise as to how I can get past this latest issue.

Regards,

Chris

pookie1973 wrote:

I'm using Geronimo 2.1, I have an ear file containing an EJB project with a single stateless session bean and a JPA project containing four entity beans. When I export the ear file and deploy it to Geronimo via the console, I get:-

At least one deployment problem:[org.apache.geronimo.common.DeploymentException: Could not resolve reference at deploy time for query ?name=persistence/jpaEntity#org.apache.geronimo.persistence.PersistenceUnitGBean. No GBean references found.]
org.apache.geronimo.common.DeploymentException: At least one deployment problem:[org.apache.geronimo.common.DeploymentException: Could not resolve reference at deploy time for query ?name=persistence/jpaEntity#org.apache.geronimo.persistence.PersistenceUnitGBean. No GBean references found.]
at org.apache.geronimo.persistence.builder.PersistenceUnitRefBuilder.buildNaming(PersistenceUnitRefBuilder.java:154)
at org.apache.geronimo.j2ee.deployment.NamingBuilderCollection.buildNaming(NamingBuilderCollection.java:53)
at org.apache.geronimo.openejb.deployment.EjbDeploymentBuilder.addEnc(EjbDeploymentBuilder.java:329)
at org.apache.geronimo.openejb.deployment.EjbDeploymentBuilder.buildEnc(EjbDeploymentBuilder.java:294)
at org.apache.geronimo.openejb.deployment.EjbModuleBuilder.addGBeans(EjbModuleBuilder.java:764)
at org.apache.geronimo.j2ee.deployment.EARConfigBuilder.buildConfiguration(EARConfigBuilder.java:647)
at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:254)
at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:133)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at org.apache.geronimo.gbean.runtime.ReflectionMethodInvoker.invoke(ReflectionMethodInvoker.java:34)
at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:124)
at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:867)
at org.apache.geronimo.kernel.basic.BasicKernel.invoke(BasicKernel.java:239)
at org.apache.geronimo.deployment.plugin.local.AbstractDeployCommand.doDeploy(AbstractDeployCommand.java:116)
at org.apache.geronimo.deployment.plugin.local.DistributeCommand.run(DistributeCommand.java:61)
at java.lang.Thread.run(Unknown Source)

I searched the internet in order to see if anyone else encountered this issue. I found that Shawn (Jiang) responded to someone who had exactly the same issue as myself on IBM DeveloperWorks. Shawn asked for the EAR package structure, here it is:-

Top level:-

META-INF/MANIFEST.MF
/geronimo-application.xml
jpaFacadeClient.jar
jpaFacade.jar
jpaEntity.jar

If I unzip the ear file and run a jar tvf on the jpaEntity.jar file I have:-

C:\jpaTestEAR\jpaEntity>jar tvf jpaEntity.jar
58 Wed Jun 24 12:31:06 BST 2009 META-INF/MANIFEST.MF
0 Tue Jun 23 22:12:06 BST 2009 com/jpaEntity/
313 Tue Jun 23 22:08:26 BST 2009 META-INF/orm.xml
0 Tue Jun 23 22:08:26 BST 2009 META-INF/
1654 Wed Jun 24 14:00:16 BST 2009 com/jpaEntity/test/Dept.class
1353 Wed Jun 24 14:00:16 BST 2009 com/jpaEntity/test/Bonus.class
0 Tue Jun 23 22:12:42 BST 2009 com/jpaEntity/test/
0 Tue Jun 23 22:12:06 BST 2009 com/
686 Wed Jun 24 13:52:16 BST 2009 META-INF/persistence.xml
1124 Wed Jun 24 14:00:16 BST 2009 com/jpaEntity/test/Salgrade.class
2702 Wed Jun 24 14:00:16 BST 2009 com/jpaEntity/test/Emp.class

Shawn also requested the EAR file, which I will attach. Previously I had attempted to deploy this directly to the app server from Eclipse and I wasn't getting as far as this. I posted a question to which Shawn responded, I did not reply to this as my second son was born on Monday, hence I was a tad proccupied with other things, so Shawn is you read this I wasn't blanking you out, but many thanks for responding my last question in such a prompt manner anyway.jpaTestEAR.ear

Re: Difference between server restart and application restart

2009-06-26T15:31:37Z

On Jun 26, 2009, at 1:11 PM, Kevan Miller wrote:

>
> On Jun 26, 2009, at 12:15 PM, David Jencks wrote:
>
>>
>> On Jun 26, 2009, at 6:11 AM, Kevan Miller wrote:
>>
>>>
>>> On Jun 26, 2009, at 3:26 AM, David Jencks wrote:
>>>
>>>>
>>>> On Jun 26, 2009, at 12:02 AM, chander_bawa wrote:
>>>>
>>>>>
>>>>> Thanks Djencks,
>>>>> You are right. I tried deploying the ear from command line and
>>>>> faced the
>>>>> same issue.
>>>>> The thing is i am working on upgrading the geronimo server from
>>>>> 1.1.1 to
>>>>> 2.1.4 and the application is working perfectly in 1.1.1
>>>>> My confusion is why this error came when app is deployed on
>>>>> 2.1.4 when it
>>>>> worked perfectly on 1.1.1?
>>>>
>>>> The only reason I can think that this might work on 1.1.1 is that
>>>> we had a bug in the jndi implementation in 1.1.1 that lets the
>>>> lookup succeed. It should fail on 1.1.1 just as it does on 2.1.4.
>>>>
>>>> If you answer the questions I asked in my previous reply I might
>>>> be able to suggest a way to proceed. For instance you might be
>>>> able to look the destinations up in the jca:/ global jndi context.
>>>
>>> I don't think they're looking for destinations. Instead, it's
>>> looking for a TransactionManager. This same problem was reported
>>> back in April. That user reported that the oracle adapter was
>>> looking for "java:comp/pm/TransactionManager". I wonder if they
>>> could be configured to look for "java:/TransactionManager".
>>>
>>> I'm also wondering if throwing a RunTime exception is the
>>> appropriate behavior, in this situation. Why not a
>>> NamingException? I confess that the subtleties of JNDI are
>>> frequently lost on me...
>>>
>>
>> I think a RuntimeException might be appropriate here..... there's a
>> major logic problem in how the user is attempting to use jndi, this
>> is not a problem due to someone forgetting to bind something in jndi.
>
> Well, not necessarily a logic error. Code may be looking for a
> TransactionManager in a number of jndi locations. For example, see
> the following OpenJPA code -- http://svn.apache.org/viewvc/incubator/openjpa/trunk/openjpa-kernel/src/main/java/org/apache/openjpa/ee/AutomaticManagedRuntime.java?annotate=421741&pathrev=421741
>
> They are catching Throwable, when looking for a TM in a number of
> locations. Don't know what Oracle is doing, here. But it sure sounds
> like they are treating a RuntimeException differently from a
> NamingException. You might argue that they should be more accepting.
> We've had two people report this problem. I'm just trying to see if
> we can/should *fix* the problem...

Ya, you're right... I guess NotContextException is probably good.

thanks
david jencks

>
> --kevan

Re: Difference between server restart and application restart

2009-06-26T13:11:19Z

On Jun 26, 2009, at 12:15 PM, David Jencks wrote:

>
> On Jun 26, 2009, at 6:11 AM, Kevan Miller wrote:
>
>>
>> On Jun 26, 2009, at 3:26 AM, David Jencks wrote:
>>
>>>
>>> On Jun 26, 2009, at 12:02 AM, chander_bawa wrote:
>>>
>>>>
>>>> Thanks Djencks,
>>>> You are right. I tried deploying the ear from command line and
>>>> faced the
>>>> same issue.
>>>> The thing is i am working on upgrading the geronimo server from
>>>> 1.1.1 to
>>>> 2.1.4 and the application is working perfectly in 1.1.1
>>>> My confusion is why this error came when app is deployed on 2.1.4
>>>> when it
>>>> worked perfectly on 1.1.1?
>>>
>>> The only reason I can think that this might work on 1.1.1 is that
>>> we had a bug in the jndi implementation in 1.1.1 that lets the
>>> lookup succeed. It should fail on 1.1.1 just as it does on 2.1.4.
>>>
>>> If you answer the questions I asked in my previous reply I might
>>> be able to suggest a way to proceed. For instance you might be
>>> able to look the destinations up in the jca:/ global jndi context.
>>
>> I don't think they're looking for destinations. Instead, it's
>> looking for a TransactionManager. This same problem was reported
>> back in April. That user reported that the oracle adapter was
>> looking for "java:comp/pm/TransactionManager". I wonder if they
>> could be configured to look for "java:/TransactionManager".
>>
>> I'm also wondering if throwing a RunTime exception is the
>> appropriate behavior, in this situation. Why not a NamingException?
>> I confess that the subtleties of JNDI are frequently lost on me...
>>
>
> I think a RuntimeException might be appropriate here..... there's a
> major logic problem in how the user is attempting to use jndi, this
> is not a problem due to someone forgetting to bind something in jndi.

Well, not necessarily a logic error. Code may be looking for a
TransactionManager in a number of jndi locations. For example, see the
following OpenJPA code -- http://svn.apache.org/viewvc/incubator/openjpa/trunk/openjpa-kernel/src/main/java/org/apache/openjpa/ee/AutomaticManagedRuntime.java?annotate=421741&pathrev=421741

They are catching Throwable, when looking for a TM in a number of
locations. Don't know what Oracle is doing, here. But it sure sounds
like they are treating a RuntimeException differently from a
NamingException. You might argue that they should be more accepting.
We've had two people report this problem. I'm just trying to see if we
can/should *fix* the problem...

--kevan

Re: Difference between server restart and application restart

2009-06-26T09:15:42Z

On Jun 26, 2009, at 6:11 AM, Kevan Miller wrote:

>
> On Jun 26, 2009, at 3:26 AM, David Jencks wrote:
>
>>
>> On Jun 26, 2009, at 12:02 AM, chander_bawa wrote:
>>
>>>
>>> Thanks Djencks,
>>> You are right. I tried deploying the ear from command line and
>>> faced the
>>> same issue.
>>> The thing is i am working on upgrading the geronimo server from
>>> 1.1.1 to
>>> 2.1.4 and the application is working perfectly in 1.1.1
>>> My confusion is why this error came when app is deployed on 2.1.4
>>> when it
>>> worked perfectly on 1.1.1?
>>
>> The only reason I can think that this might work on 1.1.1 is that
>> we had a bug in the jndi implementation in 1.1.1 that lets the
>> lookup succeed. It should fail on 1.1.1 just as it does on 2.1.4.
>>
>> If you answer the questions I asked in my previous reply I might be
>> able to suggest a way to proceed. For instance you might be able
>> to look the destinations up in the jca:/ global jndi context.
>
> I don't think they're looking for destinations. Instead, it's
> looking for a TransactionManager. This same problem was reported
> back in April. That user reported that the oracle adapter was
> looking for "java:comp/pm/TransactionManager". I wonder if they
> could be configured to look for "java:/TransactionManager".
>
> I'm also wondering if throwing a RunTime exception is the
> appropriate behavior, in this situation. Why not a NamingException?
> I confess that the subtleties of JNDI are frequently lost on me...
>

I think a RuntimeException might be appropriate here..... there's a
major logic problem in how the user is attempting to use jndi, this is
not a problem due to someone forgetting to bind something in jndi.

thanks
david jencks

> --kevan

Re: Difference between server restart and application restart

2009-06-26T06:11:44Z

On Jun 26, 2009, at 3:26 AM, David Jencks wrote:

>
> On Jun 26, 2009, at 12:02 AM, chander_bawa wrote:
>
>>
>> Thanks Djencks,
>> You are right. I tried deploying the ear from command line and
>> faced the
>> same issue.
>> The thing is i am working on upgrading the geronimo server from
>> 1.1.1 to
>> 2.1.4 and the application is working perfectly in 1.1.1
>> My confusion is why this error came when app is deployed on 2.1.4
>> when it
>> worked perfectly on 1.1.1?
>
> The only reason I can think that this might work on 1.1.1 is that we
> had a bug in the jndi implementation in 1.1.1 that lets the lookup
> succeed. It should fail on 1.1.1 just as it does on 2.1.4.
>
> If you answer the questions I asked in my previous reply I might be
> able to suggest a way to proceed. For instance you might be able to
> look the destinations up in the jca:/ global jndi context.

I don't think they're looking for destinations. Instead, it's looking
for a TransactionManager. This same problem was reported back in
April. That user reported that the oracle adapter was looking for
"java:comp/pm/TransactionManager". I wonder if they could be
configured to look for "java:/TransactionManager".

I'm also wondering if throwing a RunTime exception is the appropriate
behavior, in this situation. Why not a NamingException? I confess that
the subtleties of JNDI are frequently lost on me...

--kevan

Re: Binaries not getting deleted while un-deploying axis2-1.4.1 war from Geronimo 2.1.4

2009-06-26T05:54:21Z

On Jun 26, 2009, at 5:40 AM, Anshuk wrote:

>
> Hi,
>
> I am trying to deploy/undeploy axis2 version 1.4.1. You can download
> the the
> distribution from
> http://apache.promopeddler.com/ws/axis2/1_4_1/axis2-1.4.1-war.zip
> and try to deploying the same.
>
> Deploy will not be any issue. While undeploying I am facing the
> mentioned
> issue/problem.
>
> Would really appreciate if you can look into it.

This same problem was reported some time ago. We (Tim) developed a
patch for Axis2 (it's Axis2 that is locking the files, not Geronimo).
See https://issues.apache.org/jira/browse/AXIS2-4072 -- I would assume
that this fix is included in their recent 1.5 release...

Rather than bundling web services support in your web app, I'd
recommend you use the web services supported provided by Geronimo.

--kevan