[jira] Updated: (GERONIMO-4251) Class-Path entry in WAR manifest didn't work if entry is a directory

[Ivan (JIRA)]

 [ 
https://issues.apache.org/jira/browse/GERONIMO-4251?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ivan updated GERONIMO-4251:
---

Attachment: Geronimo-4251-withtestcase.patch

Hi, Jarek:
This files contains both the code changes and testcases. Please help to reivew 
it.
Thanks !

> Class-Path entry in WAR manifest didn't work if entry is a directory
> 
>
> Key: GERONIMO-4251
> URL: https://issues.apache.org/jira/browse/GERONIMO-4251
> Project: Geronimo
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>Affects Versions: 2.1, 2.1.1, 2.1.2, 2.1.3, 2.1.4, 2.2
> Environment: Geronimo 2.1.2 on Windows XP
>Reporter: Frank Meilinger
>Assignee: Jarek Gawor
> Fix For: 2.1.4, 2.2
>
> Attachments: Geronimo-4251-withtestcase.patch, Geronimo-4251.patch, 
> geronimo-deployment-2.2-SNAPSHOT.jar, my-ear-1.0-SNAPSHOT.ear
>
>
> Hi,
> it's not possible to define an Class-Path element in the WARs manifest, if 
> it's a directory.  I try to access jar files packed in the EARs lib/ 
> directory from within a WAR module.
> e.g. this will work:
> Class-Path: a.jar b.jar
> but this doesn't work:
> Class-Path: lib/
> If a directory is specifyed, I receive the following error:
> 15:20:13,170 ERROR [DirectoryHotDeployer] Unable to deploy: Manifest class 
> path
> entries must end with the .jar extension (J2EE 1.4 Section 8.2): module=../
> org.apache.geronimo.common.DeploymentException: Manifest class path entries 
> must
>  end with the .jar extension (J2EE 1.4 Section 8.2): module=../
> at 
> org.apache.geronimo.deployment.DeploymentContext.addManifestClassPath
> (DeploymentContext.java:419)
> ...
> I think this is definitely an error because the JEE5 specification section 
> 8.2.1 explicitely allows directories in manifest Class-Path entries. 
> See discussion:
> http://www.nabble.com/EAR-bundle-dir-classpath-issue-tt18982334s134.html

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (GERONIMO-4037) Geronimo 2.0.3 (and I guess at least 2.0.2) can't run with a security manager settled from the command line using -Djava.security.manager

[Ivan (JIRA)]

[ 
https://issues.apache.org/jira/browse/GERONIMO-4037?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12672900#action_12672900
 ] 

Ivan commented on GERONIMO-4037:


Is it possible for me to have a look at the error message of TCK ? I knew that 
there are a lot of restricts on TCK..
If does, please help to paste the error message, thanks !


> Geronimo 2.0.3 (and I guess at least 2.0.2) can't run  with a security 
> manager settled from the command line using -Djava.security.manager
> --
>
> Key: GERONIMO-4037
> URL: https://issues.apache.org/jira/browse/GERONIMO-4037
> Project: Geronimo
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>  Components: kernel, security
>Affects Versions: 2.0.2
> Environment: Windows Xp Sp2
>Reporter: Jacques Le Roux
>Priority: Blocker
> Fix For: 2.1.4, 2.2
>
> Attachments: Geronimo-4037.patch
>
>
> I'm facing an issue on Windows XPsp2: I can't run WASCE with a security 
> manager settled from the command line using 
> -Djava.security.manager-Djava.security.policy=client.policy options. I get 
> the error below. Note that this is working properly under Linux (Ubuntu and 
> Suze as well).
> C:\geronimo-tomcat6-jee5-2.0.3\bin>geronimo run
> Using GERONIMO_BASE:   C:\geronimo-tomcat6-jee5-2.0.3
> Using GERONIMO_HOME:   C:\geronimo-tomcat6-jee5-2.0.3
> Using GERONIMO_TMPDIR: var\temp
> Using JRE_HOME:C:\Program Files\Java\jre1.5.0_11
> Listening for transport dt_socket at address: 5005
> Booting Geronimo Kernel (in Java 1.5.0_11)...
> Starting Geronimo Application Server v2.0.3-SNAPSHOT
> [***>  ] 11%  27s Starting 
> org.apac...15:57:28,625 ERROR [GBeanInstanceState] Error while starting; 
> GBean is now in the FAILED state: abstractName="org.apache.geronimo.configs/
> j2ee-security/2.0.3-SNAPSHOT/car?ServiceModule=org.apache.geronimo.configs/j2ee-security/2.0.3-SNAPSHOT/car,j2eeType=GBean,name=SecurityService"
> java.lang.LinkageError: 
> org/apache/geronimo/security/jacc/GeronimoPolicyConfigurationFactory
> at 
> org.apache.geronimo.security.jacc.GeronimoPolicy.implies(GeronimoPolicy.java:74)
> at java.security.ProtectionDomain.implies(Unknown Source)
> at java.security.AccessControlContext.checkPermission(Unknown Source)
> at java.security.AccessController.checkPermission(Unknown Source)
> at java.lang.SecurityManager.checkPermission(Unknown Source)
> at java.lang.Thread.setContextClassLoader(Unknown Source)
> at 
> org.apache.geronimo.gbean.runtime.GBeanInstance.createInstance(GBeanInstance.java:1056)
> at 
> org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStart(GBeanInstanceState.java:268)
> at 
> org.apache.geronimo.gbean.runtime.GBeanInstanceState.start(GBeanInstanceState.java:102)
> at 
> org.apache.geronimo.gbean.runtime.GBeanInstanceState.startRecursive(GBeanInstanceState.java:124)
> at 
> org.apache.geronimo.gbean.runtime.GBeanInstance.startRecursive(GBeanInstance.java:553)
> at 
> org.apache.geronimo.kernel.basic.BasicKernel.startRecursiveGBean(BasicKernel.java:379)
> at 
> org.apache.geronimo.kernel.config.ConfigurationUtil.startConfigurationGBeans(ConfigurationUtil.java:448)
> at 
> org.apache.geronimo.kernel.config.KernelConfigurationManager.start(KernelConfigurationManager.java:187)
> at 
> org.apache.geronimo.kernel.config.SimpleConfigurationManager.startConfiguration(SimpleConfigurationManager.java:530)
> at 
> org.apache.geronimo.kernel.config.SimpleConfigurationManager$$FastClassByCGLIB$$ce77a924.invoke()
> at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53)
> at 
> org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38)
> at 
> org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:124)
> at 
> org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:830)
> at 
> org.apache.geronimo.gbean.runtime.RawInvoker.invoke(RawInvoker.java:57)
> at 
> org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke(RawOperationInvoker.java:35)
> at 
> org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept(ProxyMethodInterceptor.java:96)
> at 
> org.apache.geronimo.kernel.config.EditableConfigurationManager$$EnhancerByCGLIB$$7e14cd11.startConfiguration()
> at 
> org.apache.geronimo.system.main.EmbeddedDaemon.doStartup(EmbeddedDaemon.java:156)
> at 
> org.apache.geronimo.system.main.EmbeddedDaemon.execute(EmbeddedDaemon.java:78)
> at 
> org.apache.geronimo.kernel.util.MainConfigur

Re: Proposed build change to not run IT by default

[Jason Dillon]

Yay!  Can you make them activate with -Dit plz?

--jason


On Feb 12, 2009, at 5:41 AM, David Jencks wrote:

While I much prefer running the testsuite integration tests by  
default I think it is no longer a reasonable strategy.


Due to the bootstrap requirements the default modules have to be in  
a "default" profile in the root pom.  So, the no-it profile has all  
the default modules except testsuite in it.  So far so good.


However, there are now a few special purpose test servers scattered  
around the project, in at least activemq and mconsole.  These build  
a minimal server with the associated plugin bits and make sure it  
starts and maybe does something simple.  These are really really  
handy when you're working on that plugin set.  However, we might not  
want to force everyone to run them all the time, so they ought to be  
in a profile.  With the current setup we need to have a default  
profile with everything and a no-it profile without the custom  
servers.


IMO this is too hard to maintain and we should have the real modules  
outside any profile and the integration tests in a with-it profile.


This will presumably require changes to whatever scripts are running  
our automated builds to include the with-it profile.


I've opened  GERONIMO-4536 for this.

I'm going to go ahead with this, we can roll it back if there are  
objections or problems.


thanks
david jencks

[BUILD] trunk: Failed for Revision: 743584

[gawor]

Geronimo Revision: 743584 built with tests included
 
See the full build-2100.log file at 
http://people.apache.org/builds/geronimo/server/binaries/trunk/20090211/build-2100.log
 
Download the binaries from 
http://people.apache.org/builds/geronimo/server/binaries/trunk/20090211
[INFO] BUILD SUCCESSFUL
[INFO] 
[INFO] Total time: 36 minutes 31 seconds
[INFO] Finished at: Wed Feb 11 21:41:04 EST 2009
[INFO] Final Memory: 665M/947M
[INFO] 
 
TESTSUITE RESULTS (Failures only)
=
See detailed results at 
http://people.apache.org/builds/geronimo/server/testsuite/ResultsSummary.html
 
Assembly: tomcat
=
See the full test.log file at 
http://people.apache.org/builds/geronimo/server/binaries/trunk/20090211/logs-2100-tomcat/test.log
 
 
[INFO] snapshot 
org.apache.geronimo.assemblies:geronimo-tomcat6-javaee5:2.2-SNAPSHOT: checking 
for updates from codehaus-snapshots
[INFO] Using assembly artifact: 
org.apache.geronimo.assemblies:geronimo-tomcat6-javaee5:zip:bin:2.2-SNAPSHOT:provided
[INFO] Using geronimoHome: 
/home/geronimo/geronimo/trunk/testsuite/target/geronimo-tomcat6-javaee5-2.2-SNAPSHOT
[INFO] Installing assembly...
[INFO] Expanding: 
/home/geronimo/.m2/repository/org/apache/geronimo/assemblies/geronimo-tomcat6-javaee5/2.2-SNAPSHOT/geronimo-tomcat6-javaee5-2.2-SNAPSHOT-bin.zip
 into /home/geronimo/geronimo/trunk/testsuite/target
[INFO] Starting Geronimo server...
[INFO] Selected option set: default
[INFO] Redirecting output to: 
/home/geronimo/geronimo/trunk/testsuite/target/geronimo-logs/org.apache.geronimo.mavenplugins.geronimo.server.StartServerMojo.log
[INFO] Waiting for Geronimo server...
[INFO] Geronimo server started in 0:00:44.094
[INFO] [shitty:install {execution: default}]
[INFO] Installing /home/geronimo/geronimo/trunk/testsuite/pom.xml to 
/home/geronimo/.m2/repository/org/apache/geronimo/testsuite/testsuite/2.2-SNAPSHOT/testsuite-2.2-SNAPSHOT.pom
[INFO] [shitty:test {execution: default}]
[INFO] Starting 36 test builds
[INFO] 
[INFO] 
---
[INFO] 
[INFO] commands-testsuite/deploy  RUNNING
[INFO] commands-testsuite/deploy  SUCCESS (0:00:59.651) 
[INFO] commands-testsuite/gshell  RUNNING
[INFO] commands-testsuite/gshell  SUCCESS (0:00:28.604) 
[INFO] commands-testsuite/jaxws   RUNNING
[INFO] commands-testsuite/jaxws   SUCCESS (0:00:33.401) 
[INFO] commands-testsuite/shutdownRUNNING
[INFO] commands-testsuite/shutdownSUCCESS (0:00:16.197) 
[INFO] concurrent-testsuite/concurrent-basic  RUNNING
[INFO] concurrent-testsuite/concurrent-basic  SUCCESS (0:06:21.401) 
[INFO] console-testsuite/advanced RUNNING
[INFO] console-testsuite/advanced SUCCESS (0:01:20.178) 
[INFO] console-testsuite/basicRUNNING
[INFO] console-testsuite/basicSUCCESS (0:01:43.330) 
[INFO] corba-testsuite/corba-helloworld   RUNNING
[INFO] corba-testsuite/corba-helloworld   SUCCESS (0:00:45.816) 
[INFO] corba-testsuite/corba-marshal  RUNNING
[INFO] corba-testsuite/corba-marshal  SUCCESS (0:00:45.587) 
[INFO] corba-testsuite/corba-mytime   RUNNING
[INFO] corba-testsuite/corba-mytime   SUCCESS (0:00:39.237) 
[INFO] deployment-testsuite/deployment-tests  RUNNING
[INFO] deployment-testsuite/deployment-tests  SUCCESS (0:00:31.439) 
[INFO] deployment-testsuite/jca-cms-tests RUNNING
[INFO] deployment-testsuite/jca-cms-tests SUCCESS (0:00:28.389) 
[INFO] deployment-testsuite/manifestcp-tests  RUNNING
[INFO] deployment-testsuite/manifestcp-tests  SUCCESS (0:00:30.909) 
[INFO] enterprise-testsuite/ejb-tests RUNNING
[INFO] enterprise-testsuite/ejb-tests SUCCESS (0:00:48.143) 
[INFO] enterprise-testsuite/jms-tests RUNNING
[INFO] enterprise-testsuite/jms-tests SUCCESS (0:00:53.582) 
[INFO] enterprise-testsuite/jpa-tests RUNNING
[INFO] enterprise-testsuite/jpa-tests SUCCESS (0:01:04.751) 
[INFO] enterprise-testsuite/sec-clientRUNNING
[INFO] enterprise-testsuite/sec-clientSUCCESS (0:00:27.324) 
[INFO] enterprise-testsuite/sec-tests RUNNING
[INFO] enterprise-testsuite/sec-tests SUCCESS (0:00:47.453) 
[INFO] security-testsuite/test-security   RUNNING
[INFO] security-testsuite/test-security   FAILURE (0:00:36.578) Java 
returned: 1
[INFO] web-testsuite/test-2.1-jspsRUNNING
[INFO] web-testsuite/test-2.1-jspsSUCCESS (0:00:28.629) 
[INFO] web-testsuite/test-2.5-servletsRUNNING
[INFO] web-testsuite/test-2.5

[BUILD] branches/2.0: Failed for Revision: 743577

[gawor]

Geronimo Revision: 743577 built with tests included
 
See the full build-2000.log file at 
http://people.apache.org/builds/geronimo/server/binaries/2.0/20090211/build-2000.log
 
Download the binaries from 
http://people.apache.org/builds/geronimo/server/binaries/2.0/20090211
[INFO] BUILD SUCCESSFUL
[INFO] 
[INFO] Total time: 33 minutes 53 seconds
[INFO] Finished at: Wed Feb 11 20:38:15 EST 2009
[INFO] Final Memory: 219M/865M
[INFO] 
 
TESTSUITE RESULTS (Failures only)
=
See detailed results at 
http://people.apache.org/builds/geronimo/server/testsuite/ResultsSummary.html
 
Assembly: tomcat
=
See the full test.log file at 
http://people.apache.org/builds/geronimo/server/binaries/2.0/20090211/logs-2000-tomcat/test.log
 
[INFO] Running deployment-testsuite.deployment
[INFO] Tests run: 2, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.28 sec 
<<< FAILURE!
--
[INFO] Running jpa-testsuite.jpa
[INFO] Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.296 
sec <<< FAILURE!
[INFO] Running sec-testsuite.security
[INFO] Tests run: 2, Failures: 2, Errors: 0, Skipped: 0, Time elapsed: 0.652 
sec <<< FAILURE!
--
[INFO] Running web-testsuite.references
[INFO] Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.286 
sec <<< FAILURE!
 
Assembly: jetty
=
See the full test.log file at 
http://people.apache.org/builds/geronimo/server/binaries/2.0/20090211/logs-2000-jetty/test.log
 
[INFO] Running deployment-testsuite.deployment
[INFO] Tests run: 2, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.327 
sec <<< FAILURE!
--
[INFO] Running jpa-testsuite.jpa
[INFO] Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.349 
sec <<< FAILURE!
[INFO] Running sec-testsuite.security
[INFO] Tests run: 2, Failures: 2, Errors: 0, Skipped: 0, Time elapsed: 0.645 
sec <<< FAILURE!
--
[INFO] Running web-testsuite.references
[INFO] Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.33 sec 
<<< FAILURE!

[jira] Issue Comment Edited: (GERONIMODEVTOOLS-535) Add support for installing from update site for IBM RAD v7.5

[Delos Dai (JIRA)]

[ 
https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-535?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12669980#action_12669980
 ] 

delos edited comment on GERONIMODEVTOOLS-535 at 2/11/09 5:38 PM:
-

Hi Tim,
Sorry for my delay!

1) For branding missing problem, I think you're right. We should add the 
branding in "about eclipse platform" dialog. But it seems branding in RAD is 
not the same as that in base eclipse, so the branding is missing. I will 
continue to investigate the branding problem in RAD.

2) About the specific version in  tag, in fact, the version is 
copied from the plugin contained in WTP 2.0.0, for replacing the 
org.eclipse.jst 2.0.0

3) About the RAD 7.5.1 installation problem, it seems you didn't install GEP 
with right version. I haven't got a RAD 7.5.1 to reproduce it (I will try RAD 
7.5.1). But I suggest you try again. Make sure that uncheck all the other sites 
in update manager of eclipse, when you install GEP from local site. 

Thanks very much!

  was (Author: delos):
Hi Tim,
Sorry for my delay!

1) For branding problem missing, I think you're right. We should add the 
branding in "about eclipse platform" dialog. But it seems branding in RAD is 
not the same as that in base eclipse, so the branding is missing. I will 
continue to investigate the branding problem in RAD.

2) About the specific version in  tag, in fact, the version is 
copied from the plugin contained in WTP 2.0.0, for replacing the 
org.eclipse.jst 2.0.0

3) About the RAD 7.5.1 installation problem, it seems you didn't install GEP 
with right version. I haven't got a RAD 7.5.1 to reproduce it (I will try RAD 
7.5.1). But I suggest you try again. Make sure that uncheck all the other sites 
in update manager of eclipse, when you install GEP from local site. 

Thanks very much!
  
> Add support for installing from update site for IBM RAD v7.5
> 
>
> Key: GERONIMODEVTOOLS-535
> URL: 
> https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-535
> Project: Geronimo-Devtools
>  Issue Type: Bug
>  Components: eclipse-plugin
>Affects Versions: 2.1.3
> Environment: IBM RAD v7.5
>Reporter: Delos Dai
>Assignee: Tim McConnell
> Fix For: 2.2.0, 2.1.4
>
> Attachments: GERONIMODEVTOOLS-535.patch
>
>
> Now, in feature.xml of GEP, we have this snippet:
> 
>match="greaterOrEqual"/>
>   
> Since no "org.eclipse.jst" feature exist in RAD , we have to replace 
> "org.eclipse.jst" feature with the sub-features of "org.eclipse.jst". 
> The section above can be replaced with this snippet:
> 
>version="2.0.0.v200706041905-1007w311817231426" 
>   match="greaterOrEqual"/>
>version="2.0.2.v200802150100-77-CT9yJXEkuiKVeQrclqTHQ3648"
>   match="greaterOrEqual"/>
>version="2.0.2.v200802150100-787KE8iDUUEF6GwKwpHEQ"
>   match="greaterOrEqual"/>
>version="2.0.2.v200802150100-7B1DzCkuNa_RPevwkwB1iJ6z-0RH" 
>   match="greaterOrEqual"/>
>version="2.0.2.v200802150100-7b7_Es8EU6AXOV9QLJSees1SQoYQ"
>   match="greaterOrEqual"/>
> 
> The sole plugin of "org.eclipse.jst" feature and optional sub-feature 
> "org.eclipse.jst.webpageeditor.feature" can't be found in the plugin list of 
> RAD.  GEP doesn't require these two items, then don't need to add them into 
> the required section.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Closed: (GERONIMO-4536) Run integration tests in a profile rather than skipping them in a profile

[David Jencks (JIRA)]

 [ 
https://issues.apache.org/jira/browse/GERONIMO-4536?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

David Jencks closed GERONIMO-4536.
--

Resolution: Fixed

Implemented in rev 743582.

> Run integration tests in a profile rather than skipping them in a profile
> -
>
> Key: GERONIMO-4536
> URL: https://issues.apache.org/jira/browse/GERONIMO-4536
> Project: Geronimo
>  Issue Type: Improvement
>  Security Level: public(Regular issues) 
>  Components: buildsystem
>Affects Versions: 2.2
>Reporter: David Jencks
>Assignee: David Jencks
> Fix For: 2.2
>
>
> When developing plugin sets its very useful to be able to have a custom 
> server assembly with the plugins and run e.g. selenium or other tests against 
> it.  Excluding these integration tests in a profile introduces too much 
> complexity compared to including them in a profile.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: Pulling Geronimo Configuration

[David Jencks]

On Feb 11, 2009, at 1:13 PM, Gianny Damour wrote:


On 12/02/2009, at 6:08 AM, Chance Yeoman wrote:



On Feb 11, 2009, at 9:32 AM, Chance Yeoman wrote:



Thank you for information,

My understanding of the plugin-based farming is incomplete as well.
From the Geronimo 2.1 documentation of plugin-based farming, it did
not seem as if node server configuration was checked and updated
upon startup.  Is this new to Geronimo 2.2 farming?


I think the plugin based farming is only in 2.2.  IIRC the deployment
based farming in 2.1 relies on pushing stuff.



As an alternative to multicast, our configuration could use a
configured admin server approach to node discovery by using a
virtual IP that would route to a master server.  Unlike
multicasting, this approach would require configuration external to
Geronimo to remain flexible, like virtual IP routing or DNS
management.  While multicast would be a better choice for most
configurations, would it be plausible to include admin server
hostname/IP based node discovery as a configuration option, with
multicast as the default?


That sounds reasonable to me, although I don't know how virtual IP
works.

Since we're talking about a new feature it would be better to move  
the

discussion to the dev list, and if you would open a jira that would
also help.

Depending on your requirements I can think of a couple of possible
strategies:

1. when a node starts up it request the plugin list from the admin
server.  In this case the admin server doesn't track the node members
and if you update a plugin list nodes won't know until they restart.

2. when a node starts up it starts pinging the admin server.  The
admin server tracks cluster members similarly to how it does now with
multicast.  Changes to plugin lists will be propagated quickly to
running nodes.

I think (2) would be easier to implement as it just replaces the
multicast heartbeat with a more configured one.

Would you be interested in contributing an implementation?

thanks
david jencks


Absolutely.  I'm taking a peek at the MulticastDiscoveryAgent code  
to get an idea of how a new implementation would plug in.


I agree that strategy 2 would be a good place to start as the  
behavior of the server farm would be the same regardless of the  
node discovery mechanism.


One requirement that this would not address is the ability to  
rotate plugin deployments to cluster member nodes one at a time or  
in separate batches rather than all at once.  This functionality  
would probably belong elsewhere though.


I will open a jira about optionally configuring an admin host for  
node discovery and begin work on an implementation.





Hi,

FWIW, WADI provides API to implement this kind of tracking and  
trigger remote services.  A ServiceSpace can be executed on each note


http://wadi.codehaus.org/wadi-core/xref/org/codehaus/wadi/servicespace/ServiceSpace.html

. When a node joins or stops, you can receive events by registering  
a ServiceSpaceListener


http://wadi.codehaus.org/wadi-core/xref/org/codehaus/wadi/servicespace/ServiceSpaceListener.html

If you are interested by a specific remote service running on a  
node, e.g. a service tracking the plugins installed on the admin  
server, then you can also receive events all along its lifecycle by  
registering a ServiceListener


http://wadi.codehaus.org/wadi-core/xref/org/codehaus/wadi/servicespace/ServiceListener.html

To invoke a remote service, e.g. to retrieve all the plugins  
installed on the admin server, you can dynamically create a service  
proxy by using a ServiceProxyFactory (more info there http://docs.codehaus.org/display/WADI/2.+Distributed+Services)


http://wadi.codehaus.org/wadi-core/xref/org/codehaus/wadi/servicespace/ServiceProxyFactory.html


This is the approach I used to track the location of specific  
stateful SessionBean types to support the fail-over of EJB clients.  
This is also the approach I used to implement the WADI admin console  
which can track where sessions are located and gather various  
statistics.


If you want to implement from scratch a node discovery feature, then  
I believe that capturing the key contracts as part of the geronimo- 
clustering project would be great (which has support for the  
tracking of cluster member).


I think it would be great to get node discovery based on WADI  
working.  Unfortunately I was in too much of a hurry when I  
implemented the plugin based farming to look into how to do this.


Where is your ejb client failover code?

thanks
david jencks




Thanks,
Gianny



Thanks for your help,

Chance

[jira] Created: (GERONIMO-4536) Run integration tests in a profile rather than skipping them in a profile

[David Jencks (JIRA)]

Run integration tests in a profile rather than skipping them in a profile
-

 Key: GERONIMO-4536
 URL: https://issues.apache.org/jira/browse/GERONIMO-4536
 Project: Geronimo
  Issue Type: Improvement
  Security Level: public (Regular issues)
  Components: buildsystem
Affects Versions: 2.2
Reporter: David Jencks
Assignee: David Jencks
 Fix For: 2.2


When developing plugin sets its very useful to be able to have a custom server 
assembly with the plugins and run e.g. selenium or other tests against it.  
Excluding these integration tests in a profile introduces too much complexity 
compared to including them in a profile.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Proposed build change to not run IT by default

[David Jencks]

While I much prefer running the testsuite integration tests by default  
I think it is no longer a reasonable strategy.


Due to the bootstrap requirements the default modules have to be in a  
"default" profile in the root pom.  So, the no-it profile has all the  
default modules except testsuite in it.  So far so good.


However, there are now a few special purpose test servers scattered  
around the project, in at least activemq and mconsole.  These build a  
minimal server with the associated plugin bits and make sure it starts  
and maybe does something simple.  These are really really handy when  
you're working on that plugin set.  However, we might not want to  
force everyone to run them all the time, so they ought to be in a  
profile.  With the current setup we need to have a default profile  
with everything and a no-it profile without the custom servers.


IMO this is too hard to maintain and we should have the real modules  
outside any profile and the integration tests in a with-it profile.


This will presumably require changes to whatever scripts are running  
our automated builds to include the with-it profile.


I've opened  GERONIMO-4536 for this.

I'm going to go ahead with this, we can roll it back if there are  
objections or problems.


thanks
david jencks

[jira] Created: (GERONIMO-4535) Alternate Node Discovery for Plugin Based Farming

[Chance Yeoman (JIRA)]

Alternate Node Discovery for Plugin Based Farming
-

 Key: GERONIMO-4535
 URL: https://issues.apache.org/jira/browse/GERONIMO-4535
 Project: Geronimo
  Issue Type: New Feature
  Security Level: public (Regular issues)
  Components: Clustering
Affects Versions: 2.2
Reporter: Chance Yeoman
Priority: Trivial


Provide an alternative node discovery mechanism for cases where multicast is 
not an option.  Geographically separated nodes that are able to connect to the 
admin server by configured IP or DNS host name should be able to participate in 
a farm as if they were on the same LAN as the admin server.  

Refer to discussions on Pulling Geronimo Configuration:

http://www.nabble.com/Re%3A-Pulling-Geronimo-Configuration-td21962048s134.html

http://www.nabble.com/Pulling-Geronimo-Configuration-td21936891s134.html

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (GERONIMO-4251) Class-Path entry in WAR manifest didn't work if entry is a directory

[Jarek Gawor (JIRA)]

[ 
https://issues.apache.org/jira/browse/GERONIMO-4251?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12672806#action_12672806
 ] 

Jarek Gawor commented on GERONIMO-4251:
---

Ivan,

The patch looks good to me but it would be good to have a test case for this 
first. Can you create and submit such test case? 


> Class-Path entry in WAR manifest didn't work if entry is a directory
> 
>
> Key: GERONIMO-4251
> URL: https://issues.apache.org/jira/browse/GERONIMO-4251
> Project: Geronimo
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>Affects Versions: 2.1, 2.1.1, 2.1.2, 2.1.3, 2.1.4, 2.2
> Environment: Geronimo 2.1.2 on Windows XP
>Reporter: Frank Meilinger
>Assignee: Jarek Gawor
> Fix For: 2.1.4, 2.2
>
> Attachments: Geronimo-4251.patch, 
> geronimo-deployment-2.2-SNAPSHOT.jar, my-ear-1.0-SNAPSHOT.ear
>
>
> Hi,
> it's not possible to define an Class-Path element in the WARs manifest, if 
> it's a directory.  I try to access jar files packed in the EARs lib/ 
> directory from within a WAR module.
> e.g. this will work:
> Class-Path: a.jar b.jar
> but this doesn't work:
> Class-Path: lib/
> If a directory is specifyed, I receive the following error:
> 15:20:13,170 ERROR [DirectoryHotDeployer] Unable to deploy: Manifest class 
> path
> entries must end with the .jar extension (J2EE 1.4 Section 8.2): module=../
> org.apache.geronimo.common.DeploymentException: Manifest class path entries 
> must
>  end with the .jar extension (J2EE 1.4 Section 8.2): module=../
> at 
> org.apache.geronimo.deployment.DeploymentContext.addManifestClassPath
> (DeploymentContext.java:419)
> ...
> I think this is definitely an error because the JEE5 specification section 
> 8.2.1 explicitely allows directories in manifest Class-Path entries. 
> See discussion:
> http://www.nabble.com/EAR-bundle-dir-classpath-issue-tt18982334s134.html

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: Pulling Geronimo Configuration

[Gianny Damour]

On 12/02/2009, at 6:08 AM, Chance Yeoman wrote:



On Feb 11, 2009, at 9:32 AM, Chance Yeoman wrote:



Thank you for information,

My understanding of the plugin-based farming is incomplete as well.
From the Geronimo 2.1 documentation of plugin-based farming, it did
not seem as if node server configuration was checked and updated
upon startup.  Is this new to Geronimo 2.2 farming?


I think the plugin based farming is only in 2.2.  IIRC the deployment
based farming in 2.1 relies on pushing stuff.



As an alternative to multicast, our configuration could use a
configured admin server approach to node discovery by using a
virtual IP that would route to a master server.  Unlike
multicasting, this approach would require configuration external to
Geronimo to remain flexible, like virtual IP routing or DNS
management.  While multicast would be a better choice for most
configurations, would it be plausible to include admin server
hostname/IP based node discovery as a configuration option, with
multicast as the default?


That sounds reasonable to me, although I don't know how virtual IP
works.

Since we're talking about a new feature it would be better to move the
discussion to the dev list, and if you would open a jira that would
also help.

Depending on your requirements I can think of a couple of possible
strategies:

1. when a node starts up it request the plugin list from the admin
server.  In this case the admin server doesn't track the node members
and if you update a plugin list nodes won't know until they restart.

2. when a node starts up it starts pinging the admin server.  The
admin server tracks cluster members similarly to how it does now with
multicast.  Changes to plugin lists will be propagated quickly to
running nodes.

I think (2) would be easier to implement as it just replaces the
multicast heartbeat with a more configured one.

Would you be interested in contributing an implementation?

thanks
david jencks


Absolutely.  I'm taking a peek at the MulticastDiscoveryAgent code  
to get an idea of how a new implementation would plug in.


I agree that strategy 2 would be a good place to start as the  
behavior of the server farm would be the same regardless of the  
node discovery mechanism.


One requirement that this would not address is the ability to  
rotate plugin deployments to cluster member nodes one at a time or  
in separate batches rather than all at once.  This functionality  
would probably belong elsewhere though.


I will open a jira about optionally configuring an admin host for  
node discovery and begin work on an implementation.





Hi,

FWIW, WADI provides API to implement this kind of tracking and  
trigger remote services.  A ServiceSpace can be executed on each note


http://wadi.codehaus.org/wadi-core/xref/org/codehaus/wadi/ 
servicespace/ServiceSpace.html


. When a node joins or stops, you can receive events by registering a  
ServiceSpaceListener


http://wadi.codehaus.org/wadi-core/xref/org/codehaus/wadi/ 
servicespace/ServiceSpaceListener.html


If you are interested by a specific remote service running on a node,  
e.g. a service tracking the plugins installed on the admin server,  
then you can also receive events all along its lifecycle by  
registering a ServiceListener


http://wadi.codehaus.org/wadi-core/xref/org/codehaus/wadi/ 
servicespace/ServiceListener.html


To invoke a remote service, e.g. to retrieve all the plugins  
installed on the admin server, you can dynamically create a service  
proxy by using a ServiceProxyFactory (more info there http:// 
docs.codehaus.org/display/WADI/2.+Distributed+Services)


http://wadi.codehaus.org/wadi-core/xref/org/codehaus/wadi/ 
servicespace/ServiceProxyFactory.html



This is the approach I used to track the location of specific  
stateful SessionBean types to support the fail-over of EJB clients.  
This is also the approach I used to implement the WADI admin console  
which can track where sessions are located and gather various  
statistics.


If you want to implement from scratch a node discovery feature, then  
I believe that capturing the key contracts as part of the geronimo- 
clustering project would be great (which has support for the tracking  
of cluster member).


Thanks,
Gianny



Thanks for your help,

Chance

[jira] Reopened: (GERONIMO-4037) Geronimo 2.0.3 (and I guess at least 2.0.2) can't run with a security manager settled from the command line using -Djava.security.manager

[Jarek Gawor (JIRA)]

 [ 
https://issues.apache.org/jira/browse/GERONIMO-4037?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jarek Gawor reopened GERONIMO-4037:
---

  Assignee: (was: Jarek Gawor)

I had to undo the changes as they created problems in TCK (revision 743457, 
revision 743458).


> Geronimo 2.0.3 (and I guess at least 2.0.2) can't run  with a security 
> manager settled from the command line using -Djava.security.manager
> --
>
> Key: GERONIMO-4037
> URL: https://issues.apache.org/jira/browse/GERONIMO-4037
> Project: Geronimo
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>  Components: kernel, security
>Affects Versions: 2.0.2
> Environment: Windows Xp Sp2
>Reporter: Jacques Le Roux
>Priority: Blocker
> Fix For: 2.1.4, 2.2
>
> Attachments: Geronimo-4037.patch
>
>
> I'm facing an issue on Windows XPsp2: I can't run WASCE with a security 
> manager settled from the command line using 
> -Djava.security.manager-Djava.security.policy=client.policy options. I get 
> the error below. Note that this is working properly under Linux (Ubuntu and 
> Suze as well).
> C:\geronimo-tomcat6-jee5-2.0.3\bin>geronimo run
> Using GERONIMO_BASE:   C:\geronimo-tomcat6-jee5-2.0.3
> Using GERONIMO_HOME:   C:\geronimo-tomcat6-jee5-2.0.3
> Using GERONIMO_TMPDIR: var\temp
> Using JRE_HOME:C:\Program Files\Java\jre1.5.0_11
> Listening for transport dt_socket at address: 5005
> Booting Geronimo Kernel (in Java 1.5.0_11)...
> Starting Geronimo Application Server v2.0.3-SNAPSHOT
> [***>  ] 11%  27s Starting 
> org.apac...15:57:28,625 ERROR [GBeanInstanceState] Error while starting; 
> GBean is now in the FAILED state: abstractName="org.apache.geronimo.configs/
> j2ee-security/2.0.3-SNAPSHOT/car?ServiceModule=org.apache.geronimo.configs/j2ee-security/2.0.3-SNAPSHOT/car,j2eeType=GBean,name=SecurityService"
> java.lang.LinkageError: 
> org/apache/geronimo/security/jacc/GeronimoPolicyConfigurationFactory
> at 
> org.apache.geronimo.security.jacc.GeronimoPolicy.implies(GeronimoPolicy.java:74)
> at java.security.ProtectionDomain.implies(Unknown Source)
> at java.security.AccessControlContext.checkPermission(Unknown Source)
> at java.security.AccessController.checkPermission(Unknown Source)
> at java.lang.SecurityManager.checkPermission(Unknown Source)
> at java.lang.Thread.setContextClassLoader(Unknown Source)
> at 
> org.apache.geronimo.gbean.runtime.GBeanInstance.createInstance(GBeanInstance.java:1056)
> at 
> org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStart(GBeanInstanceState.java:268)
> at 
> org.apache.geronimo.gbean.runtime.GBeanInstanceState.start(GBeanInstanceState.java:102)
> at 
> org.apache.geronimo.gbean.runtime.GBeanInstanceState.startRecursive(GBeanInstanceState.java:124)
> at 
> org.apache.geronimo.gbean.runtime.GBeanInstance.startRecursive(GBeanInstance.java:553)
> at 
> org.apache.geronimo.kernel.basic.BasicKernel.startRecursiveGBean(BasicKernel.java:379)
> at 
> org.apache.geronimo.kernel.config.ConfigurationUtil.startConfigurationGBeans(ConfigurationUtil.java:448)
> at 
> org.apache.geronimo.kernel.config.KernelConfigurationManager.start(KernelConfigurationManager.java:187)
> at 
> org.apache.geronimo.kernel.config.SimpleConfigurationManager.startConfiguration(SimpleConfigurationManager.java:530)
> at 
> org.apache.geronimo.kernel.config.SimpleConfigurationManager$$FastClassByCGLIB$$ce77a924.invoke()
> at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53)
> at 
> org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38)
> at 
> org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:124)
> at 
> org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:830)
> at 
> org.apache.geronimo.gbean.runtime.RawInvoker.invoke(RawInvoker.java:57)
> at 
> org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke(RawOperationInvoker.java:35)
> at 
> org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept(ProxyMethodInterceptor.java:96)
> at 
> org.apache.geronimo.kernel.config.EditableConfigurationManager$$EnhancerByCGLIB$$7e14cd11.startConfiguration()
> at 
> org.apache.geronimo.system.main.EmbeddedDaemon.doStartup(EmbeddedDaemon.java:156)
> at 
> org.apache.geronimo.system.main.EmbeddedDaemon.execute(EmbeddedDaemon.java:78)
> at 
> org.apache.geronimo.kernel.util.MainConfigurationBootstrapper.main(MainConfigurationBootstrapper.java:45)
> at 
> org

Re: Pulling Geronimo Configuration

[Chance Yeoman]

On Feb 11, 2009, at 9:32 AM, Chance Yeoman wrote:

>
> Thank you for information,
>
> My understanding of the plugin-based farming is incomplete as well.   
> From the Geronimo 2.1 documentation of plugin-based farming, it did  
> not seem as if node server configuration was checked and updated  
> upon startup.  Is this new to Geronimo 2.2 farming?

I think the plugin based farming is only in 2.2.  IIRC the deployment  
based farming in 2.1 relies on pushing stuff.
>
>
> As an alternative to multicast, our configuration could use a  
> configured admin server approach to node discovery by using a  
> virtual IP that would route to a master server.  Unlike  
> multicasting, this approach would require configuration external to  
> Geronimo to remain flexible, like virtual IP routing or DNS  
> management.  While multicast would be a better choice for most  
> configurations, would it be plausible to include admin server  
> hostname/IP based node discovery as a configuration option, with  
> multicast as the default?

That sounds reasonable to me, although I don't know how virtual IP  
works.

Since we're talking about a new feature it would be better to move the  
discussion to the dev list, and if you would open a jira that would  
also help.

Depending on your requirements I can think of a couple of possible  
strategies:

1. when a node starts up it request the plugin list from the admin  
server.  In this case the admin server doesn't track the node members  
and if you update a plugin list nodes won't know until they restart.

2. when a node starts up it starts pinging the admin server.  The  
admin server tracks cluster members similarly to how it does now with  
multicast.  Changes to plugin lists will be propagated quickly to  
running nodes.

I think (2) would be easier to implement as it just replaces the  
multicast heartbeat with a more configured one.

Would you be interested in contributing an implementation?

thanks
david jencks


Absolutely.  I'm taking a peek at the MulticastDiscoveryAgent code to get an 
idea of how a new implementation would plug in.

I agree that strategy 2 would be a good place to start as the behavior of the 
server farm would be the same regardless of the node discovery mechanism.

One requirement that this would not address is the ability to rotate plugin 
deployments to cluster member nodes one at a time or in separate batches rather 
than all at once.  This functionality would probably belong elsewhere though.

I will open a jira about optionally configuring an admin host for node 
discovery and begin work on an implementation.


Thanks for your help,

Chance



>
>
>
> Thank you,
>
> Chance
>
> --
> Center for the Application of Information Technologies
>
> - Original Message -
> From: "David Jencks" 
> To: u...@geronimo.apache.org
> Sent: Tuesday, February 10, 2009 6:32:11 PM GMT -06:00 US/Canada  
> Central
> Subject: Re: Pulling Geronimo Configuration
>
>
> On Feb 10, 2009, at 1:52 PM, Russell E Glaue wrote:
>
>> David Jencks wrote:
>>>
>>> On Feb 10, 2009, at 8:09 AM, Chance Yeoman wrote:
>>>

 Hello All,

 I am interested in setting up geronimo installations that can pull
 installed plugins and their dependencies exclusively from a
 repository
 within a master geronimo server.  I hope to eventually have an
 automated process allowing cluster members to poll a cluster-
 specific
 geronimo server repository for available, locally uninstalled
 plugins.  My goal is to be able to more easily manage  
 geographically
 separated cluster members and to quickly add or reinitialize nodes.

 I've been having trouble getting started as I receive HTTP 401
 responses when installing remote plugins using the admin interface,
 even with security turned off on the maven-repo URL.  I can list  
 the
 contents of the remote server's repository, but not install  
 plugins.
>>>
>>> That's pretty odd.  Can you show the urls being used?  You should be
>>> able to check that it's working with a browser.
>>>


 My question is:  Is using the GeronimoAsMavenServlet even the
 correct
 approach to pull-based configuration?  How have others implemented
 configuration pulling?  Any advice would be greatly appreciated.
>>>
>>> If you use a geronimo server as the plugin repo then
>>> GeronimoAsMavenServlet is the correct approach.  However, if I were
>>> you
>>> I would give significant consideration to using nexus as the plugin
>>> repo.  I think you will have a much easier time integrating this
>>> with a
>>> reasonable build/qa process.  In particular, if you build the  
>>> plugins
>>> using maven with the car-maven-plugin, you can set the distribution
>>> management repos to be the nexus server and have mvn deploy or mvn
>>> release make the plugin available to the appropriate production
>>> servers.
>>
>> For satisfying this scenario, how does nexus compare to Archiva, or

[jira] Resolved: (GERONIMO-4528) Accessing a web service's WSDL throws a NPE

[Jarek Gawor (JIRA)]

 [ 
https://issues.apache.org/jira/browse/GERONIMO-4528?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jarek Gawor resolved GERONIMO-4528.
---

   Resolution: Fixed
Fix Version/s: 2.2

I committed a fix so that NPE is avoided and things behave the same with CXF 
and Axis2 (revision 743444).

Both Axis2 and CXF consult jax-ws-catalog.xml file to resolve wsdl and schema 
imports however it seems like the WSDL4J library ignores imports without the 
schemaLocation attribute or at least it doesn't use WSDLLocator to resolve such 
imports. That's why this import does not get handled correctly.


> Accessing a web service's WSDL throws a NPE
> ---
>
> Key: GERONIMO-4528
> URL: https://issues.apache.org/jira/browse/GERONIMO-4528
> Project: Geronimo
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>  Components: webservices
>Affects Versions: 2.2
> Environment: 2.2-SNAPSHOT from SVN
>Reporter: Janko Heilgeist
>Assignee: Jarek Gawor
> Fix For: 2.2
>
>
> I've deployed a web service whose WSDL contains various schema imports 
> without schemaLocations:
> {code:xml} namespace="http://schemas.ggf.org/jsdl/2005/11/jsdl"/>{code}
> These imports are resolved via a jax-ws-catalog.xml:
> {code:xml}
>  publicId="http://schemas.ggf.org/jsdl/2005/11/jsdl";
> uri="schemas/ext/jsdl/jsdl-1.0.xsd"/>
> {code}
> Accessing this WSDL via Geronimo with the ?wsdl-URL results in a 
> NullPointerException on Tomcat/Axis. The code tries to update the 
> schemaLocation to a server-local URL and, for this reason, retrieves the 
> imported schema. But it never checks for a valid return value. Jetty/CXF 
> simply copies these import-elements to the output WSDL without further ado.
> {code}
> 2009-02-06 08:02:21,239 ERROR [Axis2WebServiceContainer] Exception occurred 
> while trying to invoke service method doService()
> java.lang.NullPointerException
> at 
> org.apache.geronimo.axis2.WSDLQueryHandler.updateSchemaImports(WSDLQueryHandler.java:244)
> at 
> org.apache.geronimo.axis2.WSDLQueryHandler.updateSchemaImports(WSDLQueryHandler.java:252)
> at 
> org.apache.geronimo.axis2.WSDLQueryHandler.updateSchemaImports(WSDLQueryHandler.java:268)
> at 
> org.apache.geronimo.axis2.WSDLQueryHandler.updateDefinition(WSDLQueryHandler.java:230)
> at 
> org.apache.geronimo.axis2.WSDLQueryHandler.updateDefinition(WSDLQueryHandler.java:219)
> at 
> org.apache.geronimo.axis2.WSDLQueryHandler.init(WSDLQueryHandler.java:158)
> at 
> org.apache.geronimo.axis2.WSDLQueryHandler.writeResponse(WSDLQueryHandler.java:108)
> at 
> org.apache.geronimo.axis2.Axis2WebServiceContainer.processGETRequest(Axis2WebServiceContainer.java:366)
> at 
> org.apache.geronimo.axis2.Axis2WebServiceContainer.doService2(Axis2WebServiceContainer.java:306)
> at 
> org.apache.geronimo.axis2.Axis2WebServiceContainer.doService(Axis2WebServiceContainer.java:243)
> at 
> org.apache.geronimo.axis2.Axis2WebServiceContainer.getWsdl(Axis2WebServiceContainer.java:190)
> at 
> org.apache.geronimo.tomcat.TomcatEJBWebServiceContext$EJBWebServiceValve.handle(TomcatEJBWebServiceContext.java:213)
> at 
> org.apache.geronimo.tomcat.TomcatEJBWebServiceContext$EJBWebServiceValve.invoke(TomcatEJBWebServiceContext.java:187)
> at 
> org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128)
> at 
> org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
> at 
> org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
> at 
> org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:568)
> at 
> org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:286)
> at 
> org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:845)
> at 
> org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:583)
> at 
> org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447)
> at java.lang.Thread.run(Thread.java:595)
> {code}
> IMHO, both assemblies should first consult an existing jax-ws-catalog.xml to 
> resolve the schemaLocations. If this doesn't work they should copy the import 
> verbatim and let the client resolve via its own catalog.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (GERONIMO-4249) Integrate jetty7 (servlet 3.0) with jaspi support

[David Jencks (JIRA)]

[ 
https://issues.apache.org/jira/browse/GERONIMO-4249?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12672698#action_12672698
 ] 

David Jencks commented on GERONIMO-4249:


Jetty 7 trunk has merged in the jaspi work.  rev 743429 updates the g. 
integration to work with current jetty trunk.  Jetty is going to be doing a lot 
of package changes as it moves to eclipse so I will wait till that is further 
along before moving the sandbox branch to trunk.

> Integrate jetty7 (servlet 3.0) with jaspi support
> -
>
> Key: GERONIMO-4249
> URL: https://issues.apache.org/jira/browse/GERONIMO-4249
> Project: Geronimo
>  Issue Type: New Feature
>  Security Level: public(Regular issues) 
>  Components: Jetty
>Affects Versions: 2.2
>Reporter: David Jencks
>Assignee: David Jencks
> Fix For: 2.2
>
> Attachments: jetty-6-to-7-v2.patch, jetty-6-to-7.patch
>
>
> I've been working on a jetty7 jaspi implementation and integrating this in 
> geronimo.  The main code is at 
> https://svn.apache.org/repos/asf/geronimo/sandbox/djencks/jetty7
> I'll attach a patch to the main build so the jetty7 plugins get used instead 
> of the jetty6 plugins.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: Using apache's nexus instance for releases/staging

[Kevan Miller]

On Feb 11, 2009, at 11:31 AM, David Jencks wrote:

Sonatype is setting up a nexus instance at apache to help with  
releasing and in particular staging.  I think using this will make  
our releases a ___LOT___ easier.  Projects that want to use this are  
asked to comment on https://issues.apache.org/jira/browse/INFRA-1896


Unless anyone objects soon I'm going to add geronimo to the list.

For those not already convinced nexus is better than sliced  
bread :-)  the main nexus docs are here: http://www.sonatype.com/books/nexus-book/reference/


If we sign up sonatype will take care of moving our artifacts onto  
nexus and patching our poms to deploy to nexus.


I haven't looked at all of the details, yet, but looks good. I've seen  
enough to be in favor of having our name on the list.


--kevan 
 

Using apache's nexus instance for releases/staging

[David Jencks]

Sonatype is setting up a nexus instance at apache to help with  
releasing and in particular staging.  I think using this will make our  
releases a ___LOT___ easier.  Projects that want to use this are asked  
to comment on https://issues.apache.org/jira/browse/INFRA-1896


Unless anyone objects soon I'm going to add geronimo to the list.

For those not already convinced nexus is better than sliced bread :-)   
the main nexus docs are here: http://www.sonatype.com/books/nexus-book/reference/


If we sign up sonatype will take care of moving our artifacts onto  
nexus and patching our poms to deploy to nexus.


thanks
david jencks

[jira] Updated: (GERONIMO-4251) Class-Path entry in WAR manifest didn't work if entry is a directory

[Donald Woods (JIRA)]

 [ 
https://issues.apache.org/jira/browse/GERONIMO-4251?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Donald Woods updated GERONIMO-4251:
---

Patch Info: [Patch Available]
  Assignee: Jarek Gawor  (was: Ivan)

Jarek, transferring to you to consider for 2.1.4 (and trunk).

> Class-Path entry in WAR manifest didn't work if entry is a directory
> 
>
> Key: GERONIMO-4251
> URL: https://issues.apache.org/jira/browse/GERONIMO-4251
> Project: Geronimo
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>Affects Versions: 2.1, 2.1.1, 2.1.2, 2.1.3, 2.1.4, 2.2
> Environment: Geronimo 2.1.2 on Windows XP
>Reporter: Frank Meilinger
>Assignee: Jarek Gawor
> Fix For: 2.1.4, 2.2
>
> Attachments: Geronimo-4251.patch, 
> geronimo-deployment-2.2-SNAPSHOT.jar, my-ear-1.0-SNAPSHOT.ear
>
>
> Hi,
> it's not possible to define an Class-Path element in the WARs manifest, if 
> it's a directory.  I try to access jar files packed in the EARs lib/ 
> directory from within a WAR module.
> e.g. this will work:
> Class-Path: a.jar b.jar
> but this doesn't work:
> Class-Path: lib/
> If a directory is specifyed, I receive the following error:
> 15:20:13,170 ERROR [DirectoryHotDeployer] Unable to deploy: Manifest class 
> path
> entries must end with the .jar extension (J2EE 1.4 Section 8.2): module=../
> org.apache.geronimo.common.DeploymentException: Manifest class path entries 
> must
>  end with the .jar extension (J2EE 1.4 Section 8.2): module=../
> at 
> org.apache.geronimo.deployment.DeploymentContext.addManifestClassPath
> (DeploymentContext.java:419)
> ...
> I think this is definitely an error because the JEE5 specification section 
> 8.2.1 explicitely allows directories in manifest Class-Path entries. 
> See discussion:
> http://www.nabble.com/EAR-bundle-dir-classpath-issue-tt18982334s134.html

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (GERONIMO-4251) Class-Path entry in WAR manifest didn't work if entry is a directory

[Ivan (JIRA)]

[ 
https://issues.apache.org/jira/browse/GERONIMO-4251?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12672615#action_12672615
 ] 

Ivan commented on GERONIMO-4251:


Hi, Frank,
Glad to hear that. I think that your wish is also our aim.
And I am sure that  Geronimo will be better with the help from guys like you.
Thanks!
Ivan

> Class-Path entry in WAR manifest didn't work if entry is a directory
> 
>
> Key: GERONIMO-4251
> URL: https://issues.apache.org/jira/browse/GERONIMO-4251
> Project: Geronimo
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>Affects Versions: 2.1, 2.1.1, 2.1.2, 2.1.3, 2.1.4, 2.2
> Environment: Geronimo 2.1.2 on Windows XP
>Reporter: Frank Meilinger
>Assignee: Ivan
> Fix For: 2.1.4, 2.2
>
> Attachments: Geronimo-4251.patch, 
> geronimo-deployment-2.2-SNAPSHOT.jar, my-ear-1.0-SNAPSHOT.ear
>
>
> Hi,
> it's not possible to define an Class-Path element in the WARs manifest, if 
> it's a directory.  I try to access jar files packed in the EARs lib/ 
> directory from within a WAR module.
> e.g. this will work:
> Class-Path: a.jar b.jar
> but this doesn't work:
> Class-Path: lib/
> If a directory is specifyed, I receive the following error:
> 15:20:13,170 ERROR [DirectoryHotDeployer] Unable to deploy: Manifest class 
> path
> entries must end with the .jar extension (J2EE 1.4 Section 8.2): module=../
> org.apache.geronimo.common.DeploymentException: Manifest class path entries 
> must
>  end with the .jar extension (J2EE 1.4 Section 8.2): module=../
> at 
> org.apache.geronimo.deployment.DeploymentContext.addManifestClassPath
> (DeploymentContext.java:419)
> ...
> I think this is definitely an error because the JEE5 specification section 
> 8.2.1 explicitely allows directories in manifest Class-Path entries. 
> See discussion:
> http://www.nabble.com/EAR-bundle-dir-classpath-issue-tt18982334s134.html

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: Singleton Beans

[Fredrik Jonson]

Jazon wrote:
 
>  OpenEJB 3.1 supports Singleton Beans. Is there any plan when
>  will it be available to Geronimo?

I'm not a geronimo commiter.

If you look at the release plans for geronimo[0] You'll see that
OpenEJB 3.1 integration is on the agenda for a 2.2 release. There
is a _tentative_ release date too, before the end of Q1 2009.

http://cwiki.apache.org/GMOxPMGT/

-- 
Fredrik Jonson

Re: [jira] Resolved: (GERONIMO-4485) Port the GERONIMO-4474 patch for V2.1

[Gang Yin]

Hi, Jarek,
I have submitted all needed patches for
GERONIMO-4517

 The first patch had already been committed by Donald, and after Chinese
New Year Holiday, I have submitted the other 5 patches, please help to
review and commit them, so this issue could be closed, many thanks.

>
>
>

[jira] Commented: (GERONIMO-4251) Class-Path entry in WAR manifest didn't work if entry is a directory

[Frank Meilinger (JIRA)]

[ 
https://issues.apache.org/jira/browse/GERONIMO-4251?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12672560#action_12672560
 ] 

Frank Meilinger commented on GERONIMO-4251:
---

Hi Ivan,

I've done some tests and now everything works like it should.

Just a note about our usecase:
Now we are able to deploy our JEE5 application EAR with a lot of skinny WARs 
and EJBs and Webstart-Clients without any change and without application server 
specific deployment descriptors on Geronimo and Glassfish. This is "real" 
platform neutrality. Now we are going to test some other application servers 
(open source and commercial) and we hope that we are able to support a lot of 
different appservers in future with the exact same EAR. For JEE application 
developers this is a nice goal. Usually the most JEE applications nowadays are 
project development and target a specific appserver implementation which 
usually result in some appserver specific applications. We want do do product 
development for JEE and don't want to care about the appserver implementation 
the customer choose. We think, if this will be more and more possible it will 
also help JEE to get more popular.

Thanks a lot for your good work. 

Greetings,
 Frank

> Class-Path entry in WAR manifest didn't work if entry is a directory
> 
>
> Key: GERONIMO-4251
> URL: https://issues.apache.org/jira/browse/GERONIMO-4251
> Project: Geronimo
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>Affects Versions: 2.1, 2.1.1, 2.1.2, 2.1.3, 2.1.4, 2.2
> Environment: Geronimo 2.1.2 on Windows XP
>Reporter: Frank Meilinger
>Assignee: Ivan
> Fix For: 2.1.4, 2.2
>
> Attachments: Geronimo-4251.patch, 
> geronimo-deployment-2.2-SNAPSHOT.jar, my-ear-1.0-SNAPSHOT.ear
>
>
> Hi,
> it's not possible to define an Class-Path element in the WARs manifest, if 
> it's a directory.  I try to access jar files packed in the EARs lib/ 
> directory from within a WAR module.
> e.g. this will work:
> Class-Path: a.jar b.jar
> but this doesn't work:
> Class-Path: lib/
> If a directory is specifyed, I receive the following error:
> 15:20:13,170 ERROR [DirectoryHotDeployer] Unable to deploy: Manifest class 
> path
> entries must end with the .jar extension (J2EE 1.4 Section 8.2): module=../
> org.apache.geronimo.common.DeploymentException: Manifest class path entries 
> must
>  end with the .jar extension (J2EE 1.4 Section 8.2): module=../
> at 
> org.apache.geronimo.deployment.DeploymentContext.addManifestClassPath
> (DeploymentContext.java:419)
> ...
> I think this is definitely an error because the JEE5 specification section 
> 8.2.1 explicitely allows directories in manifest Class-Path entries. 
> See discussion:
> http://www.nabble.com/EAR-bundle-dir-classpath-issue-tt18982334s134.html

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[BUILD] branches/2.0: Failed for Revision: 743240

[gawor]

Geronimo Revision: 743240 built with tests included
 
See the full build-0200.log file at 
http://people.apache.org/builds/geronimo/server/binaries/2.0/20090211/build-0200.log
 
Download the binaries from 
http://people.apache.org/builds/geronimo/server/binaries/2.0/20090211
[INFO] BUILD SUCCESSFUL
[INFO] 
[INFO] Total time: 33 minutes 53 seconds
[INFO] Finished at: Wed Feb 11 02:43:01 EST 2009
[INFO] Final Memory: 256M/562M
[INFO] 
 
TESTSUITE RESULTS (Failures only)
=
See detailed results at 
http://people.apache.org/builds/geronimo/server/testsuite/ResultsSummary.html
 
Assembly: tomcat
=
See the full test.log file at 
http://people.apache.org/builds/geronimo/server/binaries/2.0/20090211/logs-0200-tomcat/test.log
 
[INFO] Running deployment-testsuite.deployment
[INFO] Tests run: 2, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.279 
sec <<< FAILURE!
--
[INFO] Running jpa-testsuite.jpa
[INFO] Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.284 
sec <<< FAILURE!
[INFO] Running sec-testsuite.security
[INFO] Tests run: 2, Failures: 2, Errors: 0, Skipped: 0, Time elapsed: 0.607 
sec <<< FAILURE!
--
[INFO] Running web-testsuite.references
[INFO] Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.288 
sec <<< FAILURE!
 
Assembly: jetty
=
See the full test.log file at 
http://people.apache.org/builds/geronimo/server/binaries/2.0/20090211/logs-0200-jetty/test.log
 
[INFO] Running deployment-testsuite.deployment
[INFO] Tests run: 2, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.326 
sec <<< FAILURE!
--
[INFO] Running jpa-testsuite.jpa
[INFO] Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.313 
sec <<< FAILURE!
[INFO] Running sec-testsuite.security
[INFO] Tests run: 2, Failures: 2, Errors: 0, Skipped: 0, Time elapsed: 0.702 
sec <<< FAILURE!
--
[INFO] Running web-testsuite.references
[INFO] Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.323 
sec <<< FAILURE!