from:"Trygve Hardersen"

[jira] Commented: (GERONIMO-4807) Hidden-classes does not support excluding files

2010-05-24 Thread Trygve Hardersen (JIRA)


[ 
https://issues.apache.org/jira/browse/GERONIMO-4807?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12870960#action_12870960
 ] 

Trygve Hardersen commented on GERONIMO-4807:


Jeg jobber ikke lengre i Jotta!
I no longer work at Jotta!

Trygve Hardersen
try...@hypobytes.com


 Hidden-classes does not support excluding files
 ---

 Key: GERONIMO-4807
 URL: https://issues.apache.org/jira/browse/GERONIMO-4807
 Project: Geronimo
  Issue Type: New Feature
  Security Level: public(Regular issues) 
  Components: deployment
Affects Versions: 2.2
 Environment: OS X 10.5, Java 6
Reporter: Trygve Hardersen
 Fix For: 2.2.2


 It is not possible to exclude files with a . in the file name using the 
 hidden-classes classloader functionality. Example:
 build.properties -- a file that lives on the root of a JAR in a parent 
 classloader
 When creating a hidden-classes filter on build.properties, it is treated 
 as build/properties, which would be correct for a Java class, but not for a 
 plain file.

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

[jira] Commented: (GERONIMO-4807) Hidden-classes does not support excluding files

2010-05-04 Thread Trygve Hardersen (JIRA)


[ 
https://issues.apache.org/jira/browse/GERONIMO-4807?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12864163#action_12864163
 ] 

Trygve Hardersen commented on GERONIMO-4807:


Jeg jobber ikke lengre i Jotta!
I no longer work at Jotta!

Trygve Hardersen
try...@hypobytes.com


 Hidden-classes does not support excluding files
 ---

 Key: GERONIMO-4807
 URL: https://issues.apache.org/jira/browse/GERONIMO-4807
 Project: Geronimo
  Issue Type: New Feature
  Security Level: public(Regular issues) 
  Components: deployment
Affects Versions: 2.2
 Environment: OS X 10.5, Java 6
Reporter: Trygve Hardersen
 Fix For: 2.2.1


 It is not possible to exclude files with a . in the file name using the 
 hidden-classes classloader functionality. Example:
 build.properties -- a file that lives on the root of a JAR in a parent 
 classloader
 When creating a hidden-classes filter on build.properties, it is treated 
 as build/properties, which would be correct for a Java class, but not for a 
 plain file.

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

[jira] Commented: (GERONIMO-4756) jetty 7 ignores default subject settings unless authentication is set up [SAMPLE APP]

2010-03-31 Thread Trygve Hardersen (JIRA)


[ 
https://issues.apache.org/jira/browse/GERONIMO-4756?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12852188#action_12852188
 ] 

Trygve Hardersen commented on GERONIMO-4756:


Jeg jobber ikke lengre i Jotta!
I no longer work at Jotta!

Trygve Hardersen
try...@hypobytes.com


 jetty 7 ignores default subject settings unless authentication is set up 
 [SAMPLE APP]
 -

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

 Attachments: Geronimo-4766.patch, jgs.tar.gz


 Jetty 7 should be setting up security stuff if a security-realm-name is 
 definied, not only if authentication is specifically configured: this will 
 make default subjects work when no auth is configured.  Should not be a 
 problem for tomcat for some reason I found this problem there already :-)

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

Re: problem with axis/axiom dependencies building 2.2

2009-12-04 Thread Trygve Hardersen

On Thu, Dec 3, 2009 at 4:38 PM, Kevan Miller kevan.mil...@gmail.com wrote:


  error: error reading
 /Users/trygve/.m2/repository/org/apache/axis2/axis2-saaj/1.5/axis2-saaj-1.5.jar;
 cannot read zip file

 Looks like you have a corrupted axis2-saaj-1.5.jar. I'd remove it from your
 local repo and rerun your build...


Yup, I tried to delete the axis2 and axiom directories, but I'm still
getting the same error. I'm also unable to build the Axis2 1.5 tag on first
attempt. Will try some more.

Thanks

Trygve

[jira] Commented: (GERONIMO-4846) form based security for the web application does not work with Jetty WADI clustering.

2009-11-02 Thread Trygve Hardersen (JIRA)

[
https://issues.apache.org/jira/browse/GERONIMO-4846?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12772536#action_12772536
]

Trygve Hardersen commented on GERONIMO-4846:

I'll try to get this tested sometime later this week. Thanks!

form based security for the web application does not work with Jetty WADI
clustering.
-

Key: GERONIMO-4846
URL: https://issues.apache.org/jira/browse/GERONIMO-4846
Project: Geronimo
Issue Type: Bug
Security Level: public(Regular issues)
Components: Clustering
Affects Versions: 2.2
Reporter: Shawn Jiang

This is a part of https://issues.apache.org/jira/browse/GERONIMO-4777, the
major issue has been resolved with the patch from Trygve Hardersen.
Opening this JIRA to track the remaining problems.

However it does not work when combined with form based security for the web
application. The first problem is that
org.eclipse.jetty.security.authentication.SessionCachingAuthenticator$SessionAuthentication
and org.eclipse.jetty.security.authentication.SessionCachingAuthenticator
are not serializable, so they can not be sent across the network. I made
these classes serializable, and then login works as long as there is only one
member in the cluster (well, not really a cluster...). When there are
multiple members in the cluster, login fails because there is no valid
constructor for
org.eclipse.jetty.security.authentication.SessionCachingAuthenticator$SessionAuthentication.
I tried to add a default constructor, but it's an inner class, and it seems
to me like theAuthenticator and UserIdentity properties are required for it
to work so I did not try to extract the class.
As I said login works as long as there's only one member in the cluster, but
logout does not. Calling javax.servlet.http.HttpSession#invalidate() throws
an exception, because the curent session can not be found:
java.lang.AssertionError: Session
[org.apache.geronimo.clustering.wadi.wadisessionadap...@7f488ddb] is undefined
org.codehaus.wadi.replication.manager.ReplicationKeyNotFoundException: Key
[ccge2q2w9dz2] does not exist
I am attaching the patch for the WADIJettyClusteringBuilder
(WADIJettyClusteringBuilder.patch) and a sample project JGS (jgs.tar.gz) that
demonstrates the security problems I'm experiencing. The
web-formlogin-clustering-plugin of the JGS project uses form based security
and WADI clustering. The /customer page is protected, and to access it one
must login with any username and password, as long as they are the same. Use
test/test for instance. To test session invalidation, manually enter the URL
/logout.
It would be very helpful if someone can comment on the usability of WADI
clustering in combination with Jetty7. To me it seems like it has not been
tested much, and I think going back to Jetty6 again is the best option for
us, unless the issues described above can be easily solved.
Thanks for your help!
--

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

[jira] Commented: (GERONIMO-4846) form based security for the web application does not work with Jetty WADI clustering.

2009-10-30 Thread Trygve Hardersen (JIRA)

[
https://issues.apache.org/jira/browse/GERONIMO-4846?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12771973#action_12771973
]

Trygve Hardersen commented on GERONIMO-4846:

I've not tested WADI with Jetty7 for a while now but last time I checked it
behaved very differently from Jetty6. With Jetty7 I can't used form-based
security, with Jetty6 I can.

You're right this is not part of the spec but if you can't use WADI with
form-based security it must be documented as a change between 2.1 and 2.2 I
think. I can do another test if you like.

form based security for the web application does not work with Jetty WADI
clustering.
-

This is a part of https://issues.apache.org/jira/browse/GERONIMO-4777, the
major issue has been resolved with the patch from Trygve Hardersen.
Opening this JIRA to track the remaining problems.

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

[jira] Commented: (GERONIMO-4807) Hidden-classes does not support excluding files

2009-08-20 Thread Trygve Hardersen (JIRA)


[ 
https://issues.apache.org/jira/browse/GERONIMO-4807?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12745341#action_12745341
 ] 

Trygve Hardersen commented on GERONIMO-4807:


If someone could point me to the relevant code for this I can probably create a 
patch for it. I suggest escaping . with a \. Example:

build\.properties

This will exclude items starting with build.properties, not items in 
build/properties.  

 Hidden-classes does not support excluding files
 ---

 Key: GERONIMO-4807
 URL: https://issues.apache.org/jira/browse/GERONIMO-4807
 Project: Geronimo
  Issue Type: New Feature
  Security Level: public(Regular issues) 
  Components: deployment
Affects Versions: 2.2
 Environment: OS X 10.5, Java 6
Reporter: Trygve Hardersen

 It is not possible to exclude files with a . in the file name using the 
 hidden-classes classloader functionality. Example:
 build.properties -- a file that lives on the root of a JAR in a parent 
 classloader
 When creating a hidden-classes filter on build.properties, it is treated 
 as build/properties, which would be correct for a Java class, but not for a 
 plain file.

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

Re: Compilation failures on trunk

2009-08-04 Thread Trygve Hardersen

Hi

Is it possible that these changes broke run-as security for Jetty7 servlets?
At least something changed between r799958 and r800712 that causes our
run-as servlets to run as UNAUTHENTICATED with the latest Geronimo
2.2-SNAPSHOT.

I provided a sample application in relation to GERONIMO-4756 that
demonstrates run-as security for servlets talking to EJBs. AFAICT this now
behaves as prior to r797291 again; the servlets are not authenticated.

I've looked through the various run-as and security discussions that have
been going on lately, but I can't see that our approach has been invalidated
by any of the changes.

Any help or insight to this is greatly appreciated.

Thanks!

Trygve Hardersen
Jotta AS


On Mon, Aug 3, 2009 at 6:30 PM, David Jencks david_jen...@yahoo.com wrote:

 Greg changed some things around here over the weekend.  I'm looking into
 this.  There's some chance this will fix the problems Ivan mentioned with
 dispatch versus redirect to the login page.

 thanks
 david jencks


 On Aug 3, 2009, at 8:25 AM, Jason Warner wrote:

  I'm seeing some compilation failures on trunk[1].  Does anyone else get
 the same error?  I'm building using java version 1.5.0 update 19 on a mac.
  The TCK builds are seeing the same failures as well, and they run using the
 same java version but on linux.

 [1]
 [INFO]
 
 [ERROR] BUILD FAILURE
 [INFO]
 
 [INFO] Compilation failure

 /Users/jason/trunk/plugins/jetty7/geronimo-jetty7/src/main/java/org/apache/geronimo/jetty7/security/JettySecurityHandlerFactory.java:[46,49]
 cannot find symbol
 symbol  : class SessionCachingAuthenticator
 location: package org.eclipse.jetty.security.authentication

 /Users/jason/trunk/plugins/jetty7/geronimo-jetty7/src/main/java/org/apache/geronimo/jetty7/connector/JettyConnector.java:[90,23]
 [deprecation] getHeaderBufferSize() in org.eclipse.jetty.http.HttpBuffers
 has been deprecated

 /Users/jason/trunk/plugins/jetty7/geronimo-jetty7/src/main/java/org/apache/geronimo/jetty7/connector/JettyConnector.java:[93,16]
 [deprecation] setHeaderBufferSize(int) in org.eclipse.jetty.http.HttpBuffers
 has been deprecated

 /Users/jason/trunk/plugins/jetty7/geronimo-jetty7/src/main/java/org/apache/geronimo/jetty7/security/auth/JAASLoginService.java:[40,7]
 org.apache.geronimo.jetty7.security.auth.JAASLoginService is not abstract
 and does not override abstract method
 validate(org.eclipse.jetty.server.UserIdentity) in
 org.eclipse.jetty.security.LoginService

 /Users/jason/trunk/plugins/jetty7/geronimo-jetty7/src/main/java/org/apache/geronimo/jetty7/security/JettySecurityHandlerFactory.java:[102,32]
 cannot find symbol
 symbol  : class SessionCachingAuthenticator
 location: class
 org.apache.geronimo.jetty7.security.JettySecurityHandlerFactory

 /Users/jason/trunk/plugins/jetty7/geronimo-jetty7/src/main/java/org/apache/geronimo/jetty7/security/JettySecurityHandlerFactory.java:[102,60]
 cannot find symbol
 symbol  : constructor FormAuthenticator(java.lang.String,java.lang.String)
 location: class
 org.eclipse.jetty.security.authentication.FormAuthenticator


 ~Jason Warner

Re: Compilation failures on trunk

2009-08-04 Thread Trygve Hardersen

I'm building Geronimo trunk locally without any hacks, so I should have the
latest stuff. There's of course a chance there's something wrong with my
local build, though I've not had such issues before.

I'll try the testsuite as suggested and debugging the sample app a bit
further. Due to the Jetty API changes I can't run the revisions before you
fixed this against the current Jetty trunk, but I've checked that the sample
app works with Geronimo r799958 and Jetty r614. Will do some more tests
tomorrow and let you know what I find.

Thanks for helping out!

Trygve

On Tue, Aug 4, 2009 at 10:36 PM, David Jencks david_jen...@yahoo.comwrote:

On Aug 4, 2009, at 10:38 AM, Trygve Hardersen wrote:

Is it possible that these changes broke run-as security for Jetty7
servlets? At least something changed between r799958 and r800712 that causes
our run-as servlets to run as UNAUTHENTICATED with the latest Geronimo
2.2-SNAPSHOT.

I provided a sample application in relation to GERONIMO-4756 that
demonstrates run-as security for servlets talking to EJBs. AFAICT this now
behaves as prior to r797291 again; the servlets are not authenticated.

I've looked through the various run-as and security discussions that have
been going on lately, but I can't see that our approach has been invalidated
by any of the changes.

I didn't try re-running your sample app and havent had time to turn it into
a testsuite app, but the existing testsuite run-as test still appears to
work fine. It checks that run-as roles on servlets and ejbs are correctly
used during servlet dispatch and servlet calls to ejbs. On the other hand
I'm not sure when geronimo snapshots are pushed, so I may have more recent
code.

Can you check against trunk (if you haven't already) and see if you can
narrow the problem down a little further?

BTW to run the testuite stuff individually you can start a g. server
somewhere and in testsuite/enterprise-testsuite/sec-tests add the following
profile to the pom in sec-ear/pom.xml:

profiles
profile
!-- use to start up selenium when running a single test
against an already-started server --
idstandalone/id
build
plugins
plugin
groupIdorg.codehaus.mojo/groupId
artifactIdselenium-maven-plugin/artifactId
inheritedfalse/inherited
executions
execution
idstart/id
phasepre-integration-test/phase
goals
goalstart-server/goal
/goals
configuration
logOutputtrue/logOutput
backgroundtrue/background
systemProperties
property
namebrowser/name
value${browser}/value
/property
/systemProperties
/configuration
/execution
execution
idstop/id
phasepost-integration-test/phase
goals
goalstop-server/goal
/goals
/execution
/executions
/plugin

/plugins
/build
/profile
/profiles

and run mvn clean install -Pstandalone

thanks
david jencks

Any help or insight to this is greatly appreciated.

Thanks!

Trygve Hardersen
Jotta AS

On Mon, Aug 3, 2009 at 6:30 PM, David Jencks david_jen...@yahoo.comwrote:

Greg changed some things around here over the weekend. I'm looking into
this. There's some chance this will fix the problems Ivan mentioned with
dispatch versus redirect to the login page.

thanks
david jencks

On Aug 3, 2009, at 8:25 AM, Jason Warner wrote:

I'm seeing some compilation failures on trunk[1]. Does anyone else get
the same error? I'm building using java version 1.5.0 update 19 on a mac.
The TCK builds are seeing the same failures as well, and they run using the
same java version but on linux.

[1]
[INFO]

[ERROR] BUILD FAILURE
[INFO]

[INFO] Compilation failure

/Users/jason/trunk/plugins/jetty7/geronimo-jetty7/src/main/java/org/apache/geronimo/jetty7/security/JettySecurityHandlerFactory.java:[46,49]
cannot find symbol
symbol

[jira] Created: (GERONIMO-4777) WADI clustering does not work with Jetty7

2009-07-30 Thread Trygve Hardersen (JIRA)

WADI clustering does not work with Jetty7
-

Key: GERONIMO-4777
URL: https://issues.apache.org/jira/browse/GERONIMO-4777
Project: Geronimo
Issue Type: Bug
Security Level: public (Regular issues)
Components: Jetty
Affects Versions: 2.2
Environment: Tested on OS X 10.5 and Ubuntu 8.10, both running 64-bit
Java 1.6
Reporter: Trygve Hardersen
Attachments: WADIJettyClusteringBuilder.patch

I've been trying to get WADI clustering to work with Jetty7, but I've found
numerous issues:

The first problem is that a Geronimo plugin that uses WADI clustering and
Jetty7 cannot be built. The WADIJettyClusteringBuilder is unable to locate the
web module in the deployment, so the build fails with the following error:

org.apache.maven.lifecycle.LifecycleExecutionException: could not package plugin
Caused by: org.apache.maven.plugin.MojoExecutionException: could not package
plugin
Caused by: org.apache.geronimo.common.DeploymentException: Could not locate web
module gbean in web app configuration

I was able to resolve this by copying the code that creates the webModuleQuery
from the equivalent Jetty6 module into the Jetty7 module, see
WADIJettyClusteringBuilder.patch. With this the build succeeds, and I'm able to
deploy the plugin. I don't know if it breaks anything else, but I've not seen
issues with it.

AFAICT normal session replication works fine with this. However it does not
work when combined with form based security for the web application. The first
problem is that
org.eclipse.jetty.security.authentication.SessionCachingAuthenticator$SessionAuthentication
and org.eclipse.jetty.security.authentication.SessionCachingAuthenticator are
not serializable, so they can not be sent across the network. I made these
classes serializable, and then login works as long as there is only one member
in the cluster (well, not really a cluster...). When there are multiple members
in the cluster, login fails because there is no valid constructor for
org.eclipse.jetty.security.authentication.SessionCachingAuthenticator$SessionAuthentication.
I tried to add a default constructor, but it's an inner class, and it seems to
me like theAuthenticator and UserIdentity properties are required for it to
work so I did not try to extract the class.

As I said login works as long as there's only one member in the cluster, but
logout does not. Calling javax.servlet.http.HttpSession#invalidate() throws an
exception, because the curent session can not be found:

java.lang.AssertionError: Session
[org.apache.geronimo.clustering.wadi.wadisessionadap...@7f488ddb] is undefined
org.codehaus.wadi.replication.manager.ReplicationKeyNotFoundException: Key
[ccge2q2w9dz2] does not exist

I am attaching the patch for the WADIJettyClusteringBuilder
(WADIJettyClusteringBuilder.patch) and a sample project JGS (jgs.tar.gz) that
demonstrates the security problems I'm experiencing. The
web-formlogin-clustering-plugin of the JGS project uses form based security and
WADI clustering. The /customer page is protected, and to access it one must
login with any username and password, as long as they are the same. Use
test/test for instance. To test session invalidation, manually enter the URL
/logout.

It would be very helpful if someone can comment on the usability of WADI
clustering in combination with Jetty7. To me it seems like it has not been
tested much, and I think going back to Jetty6 again is the best option for us,
unless the issues described above can be easily solved.

Thanks for your help!

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

[jira] Updated: (GERONIMO-4777) WADI clustering does not work with Jetty7

2009-07-30 Thread Trygve Hardersen (JIRA)

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

Trygve Hardersen updated GERONIMO-4777:
---

Attachment: WADIJettyClusteringBuilder.patch

Patch for WADIJettyClusteringBuilder

WADI clustering does not work with Jetty7
-

Key: GERONIMO-4777
URL: https://issues.apache.org/jira/browse/GERONIMO-4777
Project: Geronimo
Issue Type: Bug
Security Level: public(Regular issues)
Components: Jetty
Affects Versions: 2.2
Environment: Tested on OS X 10.5 and Ubuntu 8.10, both running 64-bit
Java 1.6
Reporter: Trygve Hardersen
Attachments: WADIJettyClusteringBuilder.patch

I've been trying to get WADI clustering to work with Jetty7, but I've found
numerous issues:
The first problem is that a Geronimo plugin that uses WADI clustering and
Jetty7 cannot be built. The WADIJettyClusteringBuilder is unable to locate
the web module in the deployment, so the build fails with the following error:
org.apache.maven.lifecycle.LifecycleExecutionException: could not package
plugin
Caused by: org.apache.maven.plugin.MojoExecutionException: could not package
plugin
Caused by: org.apache.geronimo.common.DeploymentException: Could not locate
web module gbean in web app configuration
I was able to resolve this by copying the code that creates the
webModuleQuery from the equivalent Jetty6 module into the Jetty7 module, see
WADIJettyClusteringBuilder.patch. With this the build succeeds, and I'm able
to deploy the plugin. I don't know if it breaks anything else, but I've not
seen issues with it.
AFAICT normal session replication works fine with this. However it does not
work when combined with form based security for the web application. The
first problem is that
org.eclipse.jetty.security.authentication.SessionCachingAuthenticator$SessionAuthentication
and org.eclipse.jetty.security.authentication.SessionCachingAuthenticator
are not serializable, so they can not be sent across the network. I made
these classes serializable, and then login works as long as there is only one
member in the cluster (well, not really a cluster...). When there are
multiple members in the cluster, login fails because there is no valid
constructor for
org.eclipse.jetty.security.authentication.SessionCachingAuthenticator$SessionAuthentication.
I tried to add a default constructor, but it's an inner class, and it seems
to me like theAuthenticator and UserIdentity properties are required for it
to work so I did not try to extract the class.
As I said login works as long as there's only one member in the cluster, but
logout does not. Calling javax.servlet.http.HttpSession#invalidate() throws
an exception, because the curent session can not be found:
java.lang.AssertionError: Session
[org.apache.geronimo.clustering.wadi.wadisessionadap...@7f488ddb] is undefined
org.codehaus.wadi.replication.manager.ReplicationKeyNotFoundException: Key
[ccge2q2w9dz2] does not exist
I am attaching the patch for the WADIJettyClusteringBuilder
(WADIJettyClusteringBuilder.patch) and a sample project JGS (jgs.tar.gz) that
demonstrates the security problems I'm experiencing. The
web-formlogin-clustering-plugin of the JGS project uses form based security
and WADI clustering. The /customer page is protected, and to access it one
must login with any username and password, as long as they are the same. Use
test/test for instance. To test session invalidation, manually enter the URL
/logout.
It would be very helpful if someone can comment on the usability of WADI
clustering in combination with Jetty7. To me it seems like it has not been
tested much, and I think going back to Jetty6 again is the best option for
us, unless the issues described above can be easily solved.
Thanks for your help!

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

[jira] Updated: (GERONIMO-4777) WADI clustering does not work with Jetty7

2009-07-30 Thread Trygve Hardersen (JIRA)

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

Trygve Hardersen updated GERONIMO-4777:
---

Attachment: jgs.tar.gz

The JGS sample project

WADI clustering does not work with Jetty7
-

Key: GERONIMO-4777
URL: https://issues.apache.org/jira/browse/GERONIMO-4777
Project: Geronimo
Issue Type: Bug
Security Level: public(Regular issues)
Components: Jetty
Affects Versions: 2.2
Environment: Tested on OS X 10.5 and Ubuntu 8.10, both running 64-bit
Java 1.6
Reporter: Trygve Hardersen
Attachments: jgs.tar.gz, WADIJettyClusteringBuilder.patch

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

[jira] Commented: (GERONIMO-4756) jetty 7 ignores default subject settings unless authentication is set up

2009-07-27 Thread Trygve Hardersen (JIRA)


[ 
https://issues.apache.org/jira/browse/GERONIMO-4756?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12735533#action_12735533
 ] 

Trygve Hardersen commented on GERONIMO-4756:


I've confirmed that the sample app works as expected with r798013. Many thanks 
for fixing this so quickly!

 jetty 7 ignores default subject settings unless authentication is set up
 

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

 Attachments: Geronimo-4766.patch, jgs.tar.gz


 Jetty 7 should be setting up security stuff if a security-realm-name is 
 definied, not only if authentication is specifically configured: this will 
 make default subjects work when no auth is configured.  Should not be a 
 problem for tomcat for some reason I found this problem there already :-)

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

[jira] Commented: (GERONIMO-4756) jetty 7 ignores default subject settings unless authentication is set up

2009-07-23 Thread Trygve Hardersen (JIRA)

[
https://issues.apache.org/jira/browse/GERONIMO-4756?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12734550#action_12734550
]

Trygve Hardersen commented on GERONIMO-4756:

Please feel free to do whatever you like with the sample project, nice that
it's useful. I think I uploaded it under the ASF license.

The behavior you're describing sound correct. For the non-authenticated the
user has to specify their name using the name parameter in the request, or
they will be greeted as null. I was getting EJBAccessExceptions. Has your fix
been made available somewhere? I'd love to test it.

When trying to build the web-plugin project with the ServerAuthModule enable,
which does not do anything useful it must be said, I get ClassNotFoundException
for no.jotta.jgs.web.DummyServerAuthModule. I tried to put it in both the
web-classes and realm-classes projects. When I add a direct dependency between
the web-plugin and web-classes projects, web-plugin won't start because the
ejb-classes EJB archive cannot be found in the local Maven repository. Here
Geronimo is searching for a .ejb file, but the file is named .jar. This
might have to do with the way I've packaged the EAR and CAR, not sure.

Thanks for looking at this so quickly.

jetty 7 ignores default subject settings unless authentication is set up

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

Attachments: Geronimo-4766.patch, jgs.tar.gz

Jetty 7 should be setting up security stuff if a security-realm-name is
definied, not only if authentication is specifically configured: this will
make default subjects work when no auth is configured. Should not be a
problem for tomcat for some reason I found this problem there already :-)

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

[jira] Updated: (GERONIMO-4756) jetty 7 ignores default subject settings unless authentication is set up

2009-07-22 Thread Trygve Hardersen (JIRA)


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

Trygve Hardersen updated GERONIMO-4756:
---

Attachment: jgs.tar.gz

The JGS sample project.

 jetty 7 ignores default subject settings unless authentication is set up
 

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

 Attachments: Geronimo-4766.patch, jgs.tar.gz


 Jetty 7 should be setting up security stuff if a security-realm-name is 
 definied, not only if authentication is specifically configured: this will 
 make default subjects work when no auth is configured.  Should not be a 
 problem for tomcat for some reason I found this problem there already :-)

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

[jira] Commented: (GERONIMO-4756) jetty 7 ignores default subject settings unless authentication is set up

2009-07-22 Thread Trygve Hardersen (JIRA)

[
https://issues.apache.org/jira/browse/GERONIMO-4756?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12734105#action_12734105
]

Trygve Hardersen commented on GERONIMO-4756:

I've been trying to upgrade our application to use Jetty7, but can't get the
run-as security to work. Since our application is rather complex and big, I've
created a sample project that illustrates the problem in a more controlled
environment using the current Geronimo trunk (rev 796620) without any
modifications.

The sample project is called JGS (Jotta Geronimo Security) and has 3 components
that are deployed as Geronimo plugins:

realm-plugin - Holds the security realm and credential store
ejb-plugin - Holds the EJB service layer
web-plugin - Holds the WAR HTTP layer

The realm-plugin uses a custom login module TestLoginModule that checks that
the supplied username matches the supplied password. If the username is
admin, anonymous or system, the username will also be used as role name.
If not, the role name will be set to customer. The realm-plugin also holds a
credential store that gives the username and password for the anonymous and
system run-as users.

The ejb-plugin has two stateless sessions beans; TestServiceEJB and
SecureServiceEJB. Both EJBs are set to run-as system. TestServiceEJB declares
the roles admin, anonymous, customer and system, and references the
SecureServiceEJB. TestServiceEJB has three hello methods:

sayHello(String) - Says hello to admin, anonymous, customer and system users.
sayHello() - Says hello customer users.
secureHello(String) - Says hello to admin, customer and system users using
SecureSeviceEJB to demonstrate run-as security.

The SecureServiceEJB declares the same roles as TestServiceEJB, but only has
one method:

sayHello(String) - Says hello only to system components.

In other words SecureServiceEJB can only be used by callers in the system
role, such as TestServiceEJB.

All of this work as expected including run-as security, at least when I use
remote EJB to test the services directly. See RemoteEJBTest in the ejb-test
module. The problem starts when I try to use run-as security in the web-plugin.
This is what I want:

/welcome - WelcomeServlet says hello to the user identified by a parameter
called name. Set to run-as anonymous.
/default - DefaultServlet does the same as WelcomeServlet, but does not declare
run-as and should use the default run-as identity with is also anonymous.
/customer - Customer servlet is only accessible by customer users, and does
not use run-as.
/system - SystemServlet should run-as system because it is a secure system
component.

Of these 4 URLs I can only get /customer to work properly. When the URL is used
the BASIC authentication triggers and the user can log in as test/test or
whatever they like. The username is picked up all the way down to the EJB that
greets the customer.

The 3 other URLs generally do not work. I've tried many configuration
combinations, such as using run-as annotations, defining security constraints
for the run-as URLs, disabling the default run-as subject and only using a
single servlet, but I can't get things to run-as anything consistently.
Strangely I'm 99% sure I've seen the run-as security work a couple of times, at
least after doing normal authentication first. Could there be a concurrency
issue somewhere?

I'm attaching the sample project. Thanks a lot for looking into this, and
please let me know if you have questions.

jetty 7 ignores default subject settings unless authentication is set up

Attachments: Geronimo-4766.patch, jgs.tar.gz

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

Re: Default Subject configuration for Jetty assembility

2009-07-21 Thread Trygve Hardersen

I'll start working on getting our app to run with Geronimo 2.2  Jetty7
today. We're currently using Jetty6 because of security configuration
problems.

Will let you know what I find.

Thanks

Trygve

On Tue, Jul 21, 2009 at 9:55 AM, Ivan xhh...@gmail.com wrote:

 Seem, it still does not work.
 I did not find those codes like ContextManager.setCaller() in the
 SecurityHandler, so, did not think that the defaultSubject in attached to
 the current thread.

 2009/7/21 David Jencks david_jen...@yahoo.com

 Well, its a bug :- 
 )https://issues.apache.org/jira/browse/GERONIMO-475https://issues.apache.org/jira/browse/GERONIMO-4756
 6
 I think I fixed it but don't have a test case handy.  Could you check?

 thanks
 david jencks

 On Jul 20, 2009, at 4:39 AM, Trygve Hardersen wrote:

 I'm also having this problem. Are you saying it will work if I configure
 JASPI authentication?

 Thanks

 Trygve

 On Mon, Jul 20, 2009 at 11:17 AM, Ivan xhh...@gmail.com wrote:

 Hi,
While working with the current 2.2 Jetty assembility, I found that the
 way we used to configure the default subject does not take effect again.
After checking the codes, it seems that, currently, jetty builder will
 always check for the jaspi authentication configuration, if not found, the
 runassource will be ignored.
   I wonder whether it is by design or an issue. Thanks for any comment !

 --
 Ivan






 --
 Ivan

Re: Default Subject configuration for Jetty assembility

2009-07-20 Thread Trygve Hardersen

I'm also having this problem. Are you saying it will work if I configure
JASPI authentication?

Thanks

Trygve

On Mon, Jul 20, 2009 at 11:17 AM, Ivan xhh...@gmail.com wrote:

 Hi,
While working with the current 2.2 Jetty assembility, I found that the
 way we used to configure the default subject does not take effect again.
After checking the codes, it seems that, currently, jetty builder will
 always check for the jaspi authentication configuration, if not found, the
 runassource will be ignored.
   I wonder whether it is by design or an issue. Thanks for any comment !

 --
 Ivan

Re: svn commit: r792824 - in /geronimo/server/trunk: plugins/axis/geronimo-axis-builder/src/main/java/org/apache/geronimo/axis/builder/ plugins/axis/geronimo-axis/src/main/java/org/apache/geronimo/a

2009-07-10 Thread Trygve Hardersen

No problem, thanks for the quick fix :)

Trygve

On Fri, Jul 10, 2009 at 6:30 PM, David Jencks david_jen...@yahoo.comwrote:


 On Jul 10, 2009, at 5:00 AM, Trygve Hardersen wrote:

  Hi

 I'm getting a compilation error on the Axis2 plugin, could there be
 something missing from this commit?


 oops, should be fixed now :-(


 [INFO]
 
 [ERROR] BUILD FAILURE
 [INFO]
 
 [INFO] Compilation failure

 /workspace/geronimo/server/plugins/axis2/geronimo-axis2-ejb/src/main/java/org/apache/geronimo/axis2/ejb/EJBWebServiceGBean.java:[77,19]
 addWebService(java.lang.String,java.lang.String[],org.apache.geronimo.webservices.WebServiceContainer,java.lang.String,org.apache.geronimo.security.jaas.ConfigurationFactory,java.lang.String,java.lang.String,java.lang.String,java.lang.String[],java.util.Properties,java.lang.ClassLoader)
 in org.apache.geronimo.webservices.SoapHandler cannot be applied to
 (java.lang.String,java.lang.String[],org.apache.geronimo.axis2.ejb.EJBWebServiceContainer,org.apache.geronimo.security.jaas.ConfigurationFactory,java.lang.String,java.lang.String,java.lang.String,java.lang.String[],java.util.Properties,java.lang.ClassLoader)

 I was unable to start the server because of a serialVersionUID conflict,
 so I tried to build the latest source:

 ERROR [GBeanInstanceState] Error while starting; GBean is now in the
 FAILED state:
 abstractName=org.apache.geronimo.configs/mejb/2.2-SNAPSHOT/car?configurationName=org.apache.geronimo.configs/mejb/2.2-SNAPSHOT/car

 java.io.InvalidClassException: javax.security.jacc.EJBMethodPermission;
 local class incompatible: stream classdesc serialVersionUID =
 3020288003824316299, local class serialVersionUID = 4513173161293901832


 I changed the serialization of the EJBMethodPermissionCollection class to
 only store one copy of the data.  Unfortunately this means recompiling ejb
 apps will be necessary (at least MEJB and monitoring console)

 thanks for pointing this out and my apologies for not checking that I'd
 committed everything I thought I had.

 david jencks


  Thanks

 Trygve Hardersen
 Jotta AS

[jira] Commented: (GERONIMO-4682) Unique snapshots does not work

2009-06-25 Thread Trygve Hardersen (JIRA)


[ 
https://issues.apache.org/jira/browse/GERONIMO-4682?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12723930#action_12723930
 ] 

Trygve Hardersen commented on GERONIMO-4682:


I'll try to verify this today. Thanks for looking into it so quickly!

 Unique snapshots does not work
 --

 Key: GERONIMO-4682
 URL: https://issues.apache.org/jira/browse/GERONIMO-4682
 Project: Geronimo
  Issue Type: Bug
  Security Level: public(Regular issues) 
  Components: car-maven-plugin
Affects Versions: 2.2
 Environment: OS X 10.5.7, Java 6, Maven 2.1.0 or 2.0.9
Reporter: Trygve Hardersen
Assignee: David Jencks
Priority: Minor

 When we deploy Geronimo to our local Maven repository using unique snapshots 
 we're unable to build our server later. The car-maven-plugin fails with 
 errors like this:
 Cound not find parent configuration: 
 org.apache.geronimo.configs/openejb-deployer/2.2-20090609.071606-2/car
 When Geronimo is deployed using non-unique snapshots, or when we build our 
 server on a box that also has Geronimo built on it locally, the error does 
 not occur. Here's the full trace of the error:
 [INFO] 
 
 [ERROR] BUILD ERROR
 [INFO] 
 
 [INFO] could not package plugin
 Embedded error: Unable to create configuration for deployment
 Cound not find parent configuration: 
 org.apache.geronimo.configs/openejb-deployer/2.2-20090609.071606-2/car
 [INFO] 
 
 [INFO] Trace
 org.apache.maven.lifecycle.LifecycleExecutionException: could not package 
 plugin
 at 
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:703)
 at 
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:540)
 at 
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:519)
 at 
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:371)
 at 
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:332)
 at 
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:181)
 at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:356)
 at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:137)
 at org.apache.maven.cli.MavenCli.main(MavenCli.java:356)
 at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
 at 
 sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
 at 
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
 at java.lang.reflect.Method.invoke(Method.java:597)
 at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
 at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
 at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
 at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
 Caused by: org.apache.maven.plugin.MojoExecutionException: could not package 
 plugin
 at 
 org.apache.geronimo.mavenplugins.car.PackageMojo.execute(PackageMojo.java:212)
 at 
 org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:483)
 at 
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:678)
 ... 16 more
 Caused by: org.apache.geronimo.common.DeploymentException: Unable to create 
 configuration for deployment
 at 
 org.apache.geronimo.deployment.DeploymentContext.createTempConfiguration(DeploymentContext.java:151)
 at 
 org.apache.geronimo.deployment.DeploymentContext.init(DeploymentContext.java:131)
 at 
 org.apache.geronimo.deployment.DeploymentContext.init(DeploymentContext.java:111)
 at 
 org.apache.geronimo.deployment.service.ServiceConfigBuilder.buildConfiguration(ServiceConfigBuilder.java:227)
 at 
 org.apache.geronimo.deployment.service.ServiceConfigBuilder.buildConfiguration(ServiceConfigBuilder.java:199)
 at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:256)
 at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
 at 
 sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
 at 
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
 at java.lang.reflect.Method.invoke(Method.java:597)
 at 
 org.apache.geronimo.gbean.runtime.ReflectionMethodInvoker.invoke(ReflectionMethodInvoker.java:34)
 at 
 org.apache.geronimo.gbean.runtime.GBeanOperation.invoke

[jira] Issue Comment Edited: (GERONIMO-4682) Unique snapshots does not work

2009-06-25 Thread Trygve Hardersen (JIRA)


[ 
https://issues.apache.org/jira/browse/GERONIMO-4682?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12723930#action_12723930
 ] 

Trygve Hardersen edited comment on GERONIMO-4682 at 6/25/09 1:25 AM:
-

I'll try to verify this today. Thanks for looking into it so quickly!

Update: I'm unable to build the server right now because of:

'dependencies.dependency.version' is missing for org.apache.pluto:pluto-taglib 
in plugins/system-database/sysdb-portlets/pom.xml

Waiting for this to be resolved, seems like the pluto stuff was changed lately. 
Thanks again.

  was (Author: trygve):
I'll try to verify this today. Thanks for looking into it so quickly!
  
 Unique snapshots does not work
 --

 Key: GERONIMO-4682
 URL: https://issues.apache.org/jira/browse/GERONIMO-4682
 Project: Geronimo
  Issue Type: Bug
  Security Level: public(Regular issues) 
  Components: car-maven-plugin
Affects Versions: 2.2
 Environment: OS X 10.5.7, Java 6, Maven 2.1.0 or 2.0.9
Reporter: Trygve Hardersen
Assignee: David Jencks
Priority: Minor

 When we deploy Geronimo to our local Maven repository using unique snapshots 
 we're unable to build our server later. The car-maven-plugin fails with 
 errors like this:
 Cound not find parent configuration: 
 org.apache.geronimo.configs/openejb-deployer/2.2-20090609.071606-2/car
 When Geronimo is deployed using non-unique snapshots, or when we build our 
 server on a box that also has Geronimo built on it locally, the error does 
 not occur. Here's the full trace of the error:
 [INFO] 
 
 [ERROR] BUILD ERROR
 [INFO] 
 
 [INFO] could not package plugin
 Embedded error: Unable to create configuration for deployment
 Cound not find parent configuration: 
 org.apache.geronimo.configs/openejb-deployer/2.2-20090609.071606-2/car
 [INFO] 
 
 [INFO] Trace
 org.apache.maven.lifecycle.LifecycleExecutionException: could not package 
 plugin
 at 
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:703)
 at 
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:540)
 at 
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:519)
 at 
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:371)
 at 
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:332)
 at 
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:181)
 at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:356)
 at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:137)
 at org.apache.maven.cli.MavenCli.main(MavenCli.java:356)
 at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
 at 
 sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
 at 
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
 at java.lang.reflect.Method.invoke(Method.java:597)
 at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
 at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
 at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
 at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
 Caused by: org.apache.maven.plugin.MojoExecutionException: could not package 
 plugin
 at 
 org.apache.geronimo.mavenplugins.car.PackageMojo.execute(PackageMojo.java:212)
 at 
 org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:483)
 at 
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:678)
 ... 16 more
 Caused by: org.apache.geronimo.common.DeploymentException: Unable to create 
 configuration for deployment
 at 
 org.apache.geronimo.deployment.DeploymentContext.createTempConfiguration(DeploymentContext.java:151)
 at 
 org.apache.geronimo.deployment.DeploymentContext.init(DeploymentContext.java:131)
 at 
 org.apache.geronimo.deployment.DeploymentContext.init(DeploymentContext.java:111)
 at 
 org.apache.geronimo.deployment.service.ServiceConfigBuilder.buildConfiguration(ServiceConfigBuilder.java:227)
 at 
 org.apache.geronimo.deployment.service.ServiceConfigBuilder.buildConfiguration(ServiceConfigBuilder.java:199)
 at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:256

[jira] Commented: (GERONIMO-4682) Unique snapshots does not work

2009-06-25 Thread Trygve Hardersen (JIRA)


[ 
https://issues.apache.org/jira/browse/GERONIMO-4682?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12724005#action_12724005
 ] 

Trygve Hardersen commented on GERONIMO-4682:


Strange, somehow r788280 did the trick, though I can't see any difference that 
should impact the error I got. I do have some local changes, and I'm using the 
EU SVN mirror, not sure if that caused the error.

Anyways I built the server and deployed it to my local Nexus Maven repository 
using unique snapshots. The local Nexus repository did not have any Geronimo 
server artifacts in it when I deployed the server. I then removed the Geronimo 
artifacts from the local Maven repository on the build machine, and built our 
server successfully. I did the same on another machine where Geronimo has never 
been built locally and it works there as well.

Pretty sure this is fixed. Thanks a lot!


 Unique snapshots does not work
 --

 Key: GERONIMO-4682
 URL: https://issues.apache.org/jira/browse/GERONIMO-4682
 Project: Geronimo
  Issue Type: Bug
  Security Level: public(Regular issues) 
  Components: car-maven-plugin
Affects Versions: 2.2
 Environment: OS X 10.5.7, Java 6, Maven 2.1.0 or 2.0.9
Reporter: Trygve Hardersen
Assignee: David Jencks
Priority: Minor

 When we deploy Geronimo to our local Maven repository using unique snapshots 
 we're unable to build our server later. The car-maven-plugin fails with 
 errors like this:
 Cound not find parent configuration: 
 org.apache.geronimo.configs/openejb-deployer/2.2-20090609.071606-2/car
 When Geronimo is deployed using non-unique snapshots, or when we build our 
 server on a box that also has Geronimo built on it locally, the error does 
 not occur. Here's the full trace of the error:
 [INFO] 
 
 [ERROR] BUILD ERROR
 [INFO] 
 
 [INFO] could not package plugin
 Embedded error: Unable to create configuration for deployment
 Cound not find parent configuration: 
 org.apache.geronimo.configs/openejb-deployer/2.2-20090609.071606-2/car
 [INFO] 
 
 [INFO] Trace
 org.apache.maven.lifecycle.LifecycleExecutionException: could not package 
 plugin
 at 
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:703)
 at 
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:540)
 at 
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:519)
 at 
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:371)
 at 
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:332)
 at 
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:181)
 at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:356)
 at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:137)
 at org.apache.maven.cli.MavenCli.main(MavenCli.java:356)
 at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
 at 
 sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
 at 
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
 at java.lang.reflect.Method.invoke(Method.java:597)
 at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
 at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
 at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
 at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
 Caused by: org.apache.maven.plugin.MojoExecutionException: could not package 
 plugin
 at 
 org.apache.geronimo.mavenplugins.car.PackageMojo.execute(PackageMojo.java:212)
 at 
 org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:483)
 at 
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:678)
 ... 16 more
 Caused by: org.apache.geronimo.common.DeploymentException: Unable to create 
 configuration for deployment
 at 
 org.apache.geronimo.deployment.DeploymentContext.createTempConfiguration(DeploymentContext.java:151)
 at 
 org.apache.geronimo.deployment.DeploymentContext.init(DeploymentContext.java:131)
 at 
 org.apache.geronimo.deployment.DeploymentContext.init(DeploymentContext.java:111)
 at 
 org.apache.geronimo.deployment.service.ServiceConfigBuilder.buildConfiguration(ServiceConfigBuilder.java:227

[jira] Commented: (GERONIMO-4682) Unique snapshots does not work

2009-06-11 Thread Trygve Hardersen (JIRA)


[ 
https://issues.apache.org/jira/browse/GERONIMO-4682?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12718330#action_12718330
 ] 

Trygve Hardersen commented on GERONIMO-4682:


FYI the Nexus repository, and least the 1.3.4 Open Source version without any 
specific settings for this, will accept non-unique snapshots. It seems to me 
like the various Apache projects use both unique and non-unique snapshots:

https://repository.apache.org/content/repositories/snapshots/org/apache/activemq/activemq-core/5.3-SNAPSHOT/

https://repository.apache.org/content/repositories/snapshots/org/apache/camel/camel-core/2.0-SNAPSHOT/

My apologies for the strange characters in my previous post; I don't know the 
ASF JIRA syntax.

 Unique snapshots does not work
 --

 Key: GERONIMO-4682
 URL: https://issues.apache.org/jira/browse/GERONIMO-4682
 Project: Geronimo
  Issue Type: Bug
  Security Level: public(Regular issues) 
  Components: car-maven-plugin
Affects Versions: 2.2
 Environment: OS X 10.5.7, Java 6, Maven 2.1.0 or 2.0.9
Reporter: Trygve Hardersen
Priority: Minor

 When we deploy Geronimo to our local Maven repository using unique snapshots 
 we're unable to build our server later. The car-maven-plugin fails with 
 errors like this:
 Cound not find parent configuration: 
 org.apache.geronimo.configs/openejb-deployer/2.2-20090609.071606-2/car
 When Geronimo is deployed using non-unique snapshots, or when we build our 
 server on a box that also has Geronimo built on it locally, the error does 
 not occur. Here's the full trace of the error:
 [INFO] 
 
 [ERROR] BUILD ERROR
 [INFO] 
 
 [INFO] could not package plugin
 Embedded error: Unable to create configuration for deployment
 Cound not find parent configuration: 
 org.apache.geronimo.configs/openejb-deployer/2.2-20090609.071606-2/car
 [INFO] 
 
 [INFO] Trace
 org.apache.maven.lifecycle.LifecycleExecutionException: could not package 
 plugin
 at 
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:703)
 at 
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:540)
 at 
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:519)
 at 
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:371)
 at 
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:332)
 at 
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:181)
 at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:356)
 at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:137)
 at org.apache.maven.cli.MavenCli.main(MavenCli.java:356)
 at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
 at 
 sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
 at 
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
 at java.lang.reflect.Method.invoke(Method.java:597)
 at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
 at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
 at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
 at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
 Caused by: org.apache.maven.plugin.MojoExecutionException: could not package 
 plugin
 at 
 org.apache.geronimo.mavenplugins.car.PackageMojo.execute(PackageMojo.java:212)
 at 
 org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:483)
 at 
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:678)
 ... 16 more
 Caused by: org.apache.geronimo.common.DeploymentException: Unable to create 
 configuration for deployment
 at 
 org.apache.geronimo.deployment.DeploymentContext.createTempConfiguration(DeploymentContext.java:151)
 at 
 org.apache.geronimo.deployment.DeploymentContext.init(DeploymentContext.java:131)
 at 
 org.apache.geronimo.deployment.DeploymentContext.init(DeploymentContext.java:111)
 at 
 org.apache.geronimo.deployment.service.ServiceConfigBuilder.buildConfiguration(ServiceConfigBuilder.java:227)
 at 
 org.apache.geronimo.deployment.service.ServiceConfigBuilder.buildConfiguration(ServiceConfigBuilder.java:199)
 at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:256

[jira] Created: (GERONIMO-4682) Unique snapshots does not work

2009-06-10 Thread Trygve Hardersen (JIRA)

Unique snapshots does not work
--

 Key: GERONIMO-4682
 URL: https://issues.apache.org/jira/browse/GERONIMO-4682
 Project: Geronimo
  Issue Type: Bug
  Security Level: public (Regular issues)
  Components: car-maven-plugin
Affects Versions: 2.2
 Environment: OS X 10.5.7, Java 6, Maven 2.1.0 or 2.0.9
Reporter: Trygve Hardersen
Priority: Minor


When we deploy Geronimo to our local Maven repository using unique snapshots 
we're unable to build our server later. The car-maven-plugin fails with errors 
like this:

Cound not find parent configuration: 
org.apache.geronimo.configs/openejb-deployer/2.2-20090609.071606-2/car

When Geronimo is deployed using non-unique snapshots, or when we build our 
server on a box that also has Geronimo built on it locally, the error does not 
occur. Here's the full trace of the error:

[INFO] 
[ERROR] BUILD ERROR
[INFO] 
[INFO] could not package plugin

Embedded error: Unable to create configuration for deployment
Cound not find parent configuration: 
org.apache.geronimo.configs/openejb-deployer/2.2-20090609.071606-2/car
[INFO] 
[INFO] Trace
org.apache.maven.lifecycle.LifecycleExecutionException: could not package plugin
at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:703)
at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:540)
at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:519)
at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:371)
at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:332)
at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:181)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:356)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:137)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:356)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
Caused by: org.apache.maven.plugin.MojoExecutionException: could not package 
plugin
at 
org.apache.geronimo.mavenplugins.car.PackageMojo.execute(PackageMojo.java:212)
at 
org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:483)
at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:678)
... 16 more
Caused by: org.apache.geronimo.common.DeploymentException: Unable to create 
configuration for deployment
at 
org.apache.geronimo.deployment.DeploymentContext.createTempConfiguration(DeploymentContext.java:151)
at 
org.apache.geronimo.deployment.DeploymentContext.init(DeploymentContext.java:131)
at 
org.apache.geronimo.deployment.DeploymentContext.init(DeploymentContext.java:111)
at 
org.apache.geronimo.deployment.service.ServiceConfigBuilder.buildConfiguration(ServiceConfigBuilder.java:227)
at 
org.apache.geronimo.deployment.service.ServiceConfigBuilder.buildConfiguration(ServiceConfigBuilder.java:199)
at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:256)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at 
org.apache.geronimo.gbean.runtime.ReflectionMethodInvoker.invoke(ReflectionMethodInvoker.java:34)
at 
org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:130)
at 
org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:850)
at org.apache.geronimo.kernel.basic.BasicKernel.invoke(BasicKernel.java:237)
at 
org.apache.geronimo.mavenplugins.car.PackageMojo.invokeDeployer(PackageMojo.java:483)
at 
org.apache.geronimo.mavenplugins.car.PackageMojo.buildPackage(PackageMojo.java:309)
at 
org.apache.geronimo.mavenplugins.car.PackageMojo.execute

[jira] Commented: (GERONIMO-4682) Unique snapshots does not work

2009-06-10 Thread Trygve Hardersen (JIRA)


[ 
https://issues.apache.org/jira/browse/GERONIMO-4682?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12718117#action_12718117
 ] 

Trygve Hardersen commented on GERONIMO-4682:


I first posted this to the Geronimo users mailing list, but removed some of 
that email from the bug report. Let me repost it here:

### Original Email ### 
We've had quite a few problems building Geronimo lately and we've switched our 
internal repository from Artifactory to Nexus in an attempt to get a more 
stable environment. This also made us, not entirely intentionally it must be 
said, go from using non-unique to unique snapshots of Geronimo 2.2-SNAPSHOT.

... problem report as filed here

Is this behavior to be expected, or maybe a bug? As I mentioned using 
non-unique snapshots solves the problem.

### End Original Email ###

Then David Jencks replied:

## Start Reply ###

That's a bug.  Could you please file a jira?

--spoiled by always building g. on my dev machine--

### End Reply ###

So I filed this bug report. I don't have a problem with using non-unique 
snapshots, but if it isn't supported by Geronimo I think it should be clearly 
stated because it's a standard feature of Maven.


 Unique snapshots does not work
 --

 Key: GERONIMO-4682
 URL: https://issues.apache.org/jira/browse/GERONIMO-4682
 Project: Geronimo
  Issue Type: Bug
  Security Level: public(Regular issues) 
  Components: car-maven-plugin
Affects Versions: 2.2
 Environment: OS X 10.5.7, Java 6, Maven 2.1.0 or 2.0.9
Reporter: Trygve Hardersen
Priority: Minor

 When we deploy Geronimo to our local Maven repository using unique snapshots 
 we're unable to build our server later. The car-maven-plugin fails with 
 errors like this:
 Cound not find parent configuration: 
 org.apache.geronimo.configs/openejb-deployer/2.2-20090609.071606-2/car
 When Geronimo is deployed using non-unique snapshots, or when we build our 
 server on a box that also has Geronimo built on it locally, the error does 
 not occur. Here's the full trace of the error:
 [INFO] 
 
 [ERROR] BUILD ERROR
 [INFO] 
 
 [INFO] could not package plugin
 Embedded error: Unable to create configuration for deployment
 Cound not find parent configuration: 
 org.apache.geronimo.configs/openejb-deployer/2.2-20090609.071606-2/car
 [INFO] 
 
 [INFO] Trace
 org.apache.maven.lifecycle.LifecycleExecutionException: could not package 
 plugin
 at 
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:703)
 at 
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:540)
 at 
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:519)
 at 
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:371)
 at 
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:332)
 at 
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:181)
 at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:356)
 at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:137)
 at org.apache.maven.cli.MavenCli.main(MavenCli.java:356)
 at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
 at 
 sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
 at 
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
 at java.lang.reflect.Method.invoke(Method.java:597)
 at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
 at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
 at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
 at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
 Caused by: org.apache.maven.plugin.MojoExecutionException: could not package 
 plugin
 at 
 org.apache.geronimo.mavenplugins.car.PackageMojo.execute(PackageMojo.java:212)
 at 
 org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:483)
 at 
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:678)
 ... 16 more
 Caused by: org.apache.geronimo.common.DeploymentException: Unable to create 
 configuration for deployment
 at 
 org.apache.geronimo.deployment.DeploymentContext.createTempConfiguration(DeploymentContext.java:151)
 at 
 org.apache.geronimo.deployment.DeploymentContext.init

[jira] Commented: (GERONIMO-4587) Array security issue

2009-06-02 Thread Trygve Hardersen (JIRA)


[ 
https://issues.apache.org/jira/browse/GERONIMO-4587?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12715443#action_12715443
 ] 

Trygve Hardersen commented on GERONIMO-4587:


AFAICT none of the three methods you list take an array as argument. You should 
try this:

getName(String name, int pos); -- Security works
getName1(String name, int... pos); -- Security breaks
getName2(String name, int[] pos); -- Security breaks

The difference between when I referred to as a vararg array and proper 
array is the difference between getName1 and getName2 above (int... vs. int[]).

Thanks for looking into this.

 Array security issue
 

 Key: GERONIMO-4587
 URL: https://issues.apache.org/jira/browse/GERONIMO-4587
 Project: Geronimo
  Issue Type: Bug
  Security Level: public(Regular issues) 
  Components: security
Affects Versions: 2.2
 Environment: Java 6 on OS X 10.5.
Reporter: Trygve Hardersen

 We have a stateless session bean called SSB, with a method called getX:
 SSB#getX(java.lang.String)
 Our security model has 5 roles; admin, anonymous, customer, partner and 
 system. Users can only be in one role. SSB is accessible for all roles, but 
 the getX method does not allow anonymous access. So we have these annotations:
 @DeclareRoles({
 Constants.ROLE_ADMIN,
 Constants.ROLE_ANONYMOUS,
 Constants.ROLE_CUSTOMER,
 Constants.ROLE_PARTNER,
 Constants.ROLE_SYSTEM})
 public class SSB 
 @RolesAllowed({
 Constants.ROLE_ADMIN,
 Constants.ROLE_CUSTOMER,
 Constants.ROLE_PARTNER,
 Constants.ROLE_SYSTEM})
 public X getX(String y)
 In out test suite I have a simple test case to verify that access by users in 
 the anonymous role (unauthenticated web users) is not permitted for the getX 
 method:
 SSB anonymous_service = LOG_IN_AS_ANONYMOUS_USER
 X obj = null;
 EJBAccessException eae = null;
 try{
 obj = anonymous_service.getX(test)
 ;
 }catch (EJBAccessException e) {
   eae = e;
 }
 Assert.assertNull(obj);
 Assert.assertNotNull(eae);
 Assert.assertEquals(eae.getMessage(), Unauthorized Access by Principal 
 Denied);
 We've not had issues with this test case for months. However yesterday we 
 decided to change the method signature of getX to support an optional list of 
 int flags than control the object initialization (which related records to 
 get from the DB):
 public X getX(String y, int... flags)
 After this the test shown above fails. An object is returned back and no 
 exception is raised. The security system still works; we can check the user 
 manually using the SessionContext resource. But the container authorization 
 does not trigger.
 We have also confirmed that the security system fails if a proper array is 
 used instead of the vararg array. We have not had a chance to test whether 
 using a XML-based configuration solves the issue.
 Since the security system is accessible through the SessionContext we work 
 around this issue by manually checking the user role from our code.

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

Re: [BUILD] trunk: Failed for Revision: 779134

2009-05-27 Thread Trygve Hardersen

FYI:

I got the geronimo build to run again locally after first building the xbean
project to get xbean-finder-shaded and then deleting all
src/main/history/dependences.xml files in the geronimo project. Not sure
deleting all dependencies.xml files was required but a lot of them had
changed.

The build for our project failed for the same reason because it also uses
openejb through geronimo-2.2. I think at least.

Trygve

On Wed, May 27, 2009 at 2:41 PM, ga...@apache.org wrote:

 Geronimo Revision: 779134 built with tests included

 See the full build-0900.log file at
 http://people.apache.org/builds/geronimo/server/binaries/trunk/20090527/build-0900.log


 See the unit test reports at
 http://people.apache.org/builds/geronimo/server/binaries/trunk/20090527/unit-test-reports

  ibiblio.org (http://repo.exist.com/maven2),
  apache.snapshots (http://people.apache.org/repo/m2-snapshot-repository),
  apache-snapshots (http://people.apache.org/repo/m2-snapshot-repository),
  codehaus-snapshots (http://snapshots.repository.codehaus.org),
  apache.nexus.snapshots (
 https://repository.apache.org/content/repositories/snapshots),
  apache-incubator (http://people.apache.org/repo/m2-incubating-repository/
 )


 [INFO]
 
 [INFO] Trace
 org.apache.maven.lifecycle.LifecycleExecutionException: Missing:
 --
 1) org.apache.xbean:xbean-finder-shaded:jar:3.6-SNAPSHOT

  Try downloading the file manually from the project website.

  Then, install it using the command:
  mvn install:install-file -DgroupId=org.apache.xbean
 -DartifactId=xbean-finder-shaded -Dversion=3.6-SNAPSHOT -Dpackaging=jar
 -Dfile=/path/to/file

  Alternatively, if you host your own repository you can deploy the file
 there:
  mvn deploy:deploy-file -DgroupId=org.apache.xbean
 -DartifactId=xbean-finder-shaded -Dversion=3.6-SNAPSHOT -Dpackaging=jar
 -Dfile=/path/to/file -Durl=[url] -DrepositoryId=[id]

  Path to dependency:
1) org.apache.geronimo.modules:geronimo-openejb:jar:2.2-SNAPSHOT
2) org.apache.openejb:openejb-core:jar:3.1.1-SNAPSHOT
3) org.apache.xbean:xbean-finder-shaded:jar:3.6-SNAPSHOT

 --
 1 required artifact is missing.

 for artifact:
  org.apache.geronimo.modules:geronimo-openejb:jar:2.2-SNAPSHOT

 from the specified remote repositories:
  ibiblio.org (http://repo.exist.com/maven2),
  apache.snapshots (http://people.apache.org/repo/m2-snapshot-repository),
  apache-snapshots (http://people.apache.org/repo/m2-snapshot-repository),
  codehaus-snapshots (http://snapshots.repository.codehaus.org),
  apache.nexus.snapshots (
 https://repository.apache.org/content/repositories/snapshots),
  apache-incubator (http://people.apache.org/repo/m2-incubating-repository/
 )

at
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:575)
at
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:499)
at
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:478)
at
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:330)
at
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:291)
at
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:142)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:336)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:129)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:287)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
 sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at
 org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
at
 org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
 Caused by:
 org.apache.maven.artifact.resolver.MultipleArtifactsNotFoundException:
 Missing:
 --
 1) org.apache.xbean:xbean-finder-shaded:jar:3.6-SNAPSHOT

  Try downloading the file manually from the project website.

  Then, install it using the command:
  mvn install:install-file -DgroupId=org.apache.xbean
 -DartifactId=xbean-finder-shaded -Dversion=3.6-SNAPSHOT -Dpackaging=jar
 -Dfile=/path/to/file

  Alternatively, if you host your own repository you can deploy the file
 there:
  mvn deploy:deploy-file -DgroupId=org.apache.xbean
 -DartifactId=xbean-finder-shaded -Dversion=3.6-SNAPSHOT -Dpackaging=jar
 -Dfile=/path/to/file -Durl=[url]

[jira] Created: (GERONIMO-4587) Array security issue

2009-03-13 Thread Trygve Hardersen (JIRA)

Array security issue


 Key: GERONIMO-4587
 URL: https://issues.apache.org/jira/browse/GERONIMO-4587
 Project: Geronimo
  Issue Type: Bug
  Security Level: public (Regular issues)
  Components: security
Affects Versions: 2.2
 Environment: Java 6 on OS X 10.5.
Reporter: Trygve Hardersen


We have a stateless session bean called SSB, with a method called getX:

SSB#getX(java.lang.String)

Our security model has 5 roles; admin, anonymous, customer, partner and system. 
Users can only be in one role. SSB is accessible for all roles, but the getX 
method does not allow anonymous access. So we have these annotations:

@DeclareRoles({
Constants.ROLE_ADMIN,
Constants.ROLE_ANONYMOUS,
Constants.ROLE_CUSTOMER,
Constants.ROLE_PARTNER,
Constants.ROLE_SYSTEM})
public class SSB 

@RolesAllowed({
Constants.ROLE_ADMIN,
Constants.ROLE_CUSTOMER,
Constants.ROLE_PARTNER,
Constants.ROLE_SYSTEM})
public X getX(String y)

In out test suite I have a simple test case to verify that access by users in 
the anonymous role (unauthenticated web users) is not permitted for the getX 
method:

SSB anonymous_service = LOG_IN_AS_ANONYMOUS_USER
X obj = null;
EJBAccessException eae = null;
try{
obj = anonymous_service.getX(test)
;
}catch (EJBAccessException e) {
  eae = e;
}
Assert.assertNull(obj);
Assert.assertNotNull(eae);
Assert.assertEquals(eae.getMessage(), Unauthorized Access by Principal 
Denied);

We've not had issues with this test case for months. However yesterday we 
decided to change the method signature of getX to support an optional list of 
int flags than control the object initialization (which related records to get 
from the DB):

public X getX(String y, int... flags)

After this the test shown above fails. An object is returned back and no 
exception is raised. The security system still works; we can check the user 
manually using the SessionContext resource. But the container authorization 
does not trigger.

We have also confirmed that the security system fails if a proper array is 
used instead of the vararg array. We have not had a chance to test whether 
using a XML-based configuration solves the issue.

Since the security system is accessible through the SessionContext we work 
around this issue by manually checking the user role from our code.

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

Re: [jira] Closed: (GERONIMO-4522) history dependencies.xml file should support property substitutions. Plan processing should use maven filtering, not velocity

2009-01-28 Thread Trygve Hardersen

On Tue, Jan 27, 2009 at 6:32 PM, David Jencks david_jen...@yahoo.comwrote:

 Hi Trygve,
 Maybe I broke stuff its a bit hard to tell from your description.
  There are two things going on in your build:

 1. car-maven-plugin car packaging which for each plugin project builds a
 plugin and puts it in the local maven repo.  It's plausible that the changes
 here broke this step.
 2. car-maven-plugin assembly packaging which assembles a server out of the
 plugins from the maven repo.  I don't see how this could have broken but you
 never know...

 To clarify the situation... IIUC (1) is actually generating artifacts that
 get into the local maven repo??  Are these artifacts copied into the
 geronimo server repository in (2)?  If not, something else must have changed
 so these plugins aren't dependencies of the server assembly project.


Thanks for the clarification, it matches my understanding.



 back to (1)...
 in each plugin project, there should be a target/fliteredplan/plan.xml file
 that should be your plan with the property substitutions done (but not the
 environment element inserted).  Is it there and did the property
 substitution work?


The file is not there.


 Furthermore, there should be target/resources/META-INF/plan.xml which
 should be your completed plan file with the dependencies etc included and
 target/resources/META-INF/geronimo-;plugin.xml which should have the
 dependencies and the category.  Finally both these files should be in the
 completed car file.


The plan.xml file is missing as well, but geronimo-plan.xml is present. The
content of geronimo-plan.xml from the broken setup is identical to that of
geronimo-plan.xml in the working setup.



 I'd also like to make two suggestions about your build...  is a very bad
 idea to have projects reference into each others directories or into other
 file system locations.  I'm not sure why you have a lot of individual db
 pools...


The reason we have multiple DB pools is that we (try to...) scale our
application horizontally by using many databases. These databases are
identical to each other, hence the shared plan.xml file.


  - if the db pools are all used in one application, note that you can set
 up as many db pools in one plan as you need, as
 connectiondefinitiony-instance elements.


The pools are used by many applications (or many different modules of the
same application). The idea behind making each pool a separate plugin was
that some pools would not be used at some server setups, but in practice
either all or none of them are used. I created a plugingroup for all the
pools but it would be better to use a single plan.xml file with multiple
pool definitions as you suggest.


 - if you actually need separate plugins for each db pool so they can be
 used independently, I strongly advise packing the common plan into a jar
 file as a resource (in its own project) and then using the
 maven-dependency-plugin to unpack it into target/rawplan or similar
 location.


Yes that sounds reasonable.



 Please let us know what is wrong.


I did a couple of quick tests today and it seems to me like the
planFileName and sourceDir configuration variables are ignored by the
car-maven-plugin. At least I am unable to pick up any other file than
/src/main/plan/plan.xml. Tried both with different directory as well as
filename:

build
plugins
plugin
groupIdorg.apache.geronimo.buildsupport/groupId
artifactIdcar-maven-plugin/artifactId
configuration
planFileNametest-plan.xml/planFileName
sourceDir${project.basedir}/src/main/hobo/sourceDir
deploymentConfigs

deploymentConfig${connectorDeployer}/deploymentConfig
/deploymentConfigs
category${productName}/category
   module
groupIdorg.tranql/groupId
artifactIdtranql-connector-mysql-local/artifactId
typerar/type
   /module
/configuration
/plugin
/plugins
/build

This still uses /src/main/plan/plan.xml if present, or ignores plan.xml if
not found on the standard location:

[INFO] [car:validate-configuration]
[INFO] [car:prepare-plan]
[INFO] No plan found, plugin will have no classloader

From you recommendations I won't really need to use a custom plan.xml
location any more, but I'm 90% sure this used to work and was broken
sometime between last week and yesterday.

Many thanks for your quick help! Much appreciated.

Trygve


 On Jan 27, 2009, at 6:15 AM, Trygve Hardersen wrote:

 Hi

 I hit a problem today with our custom Geronimo assembly that I think is
 related to this:

 We have many MySQL DB pools, each represented as a Geronimo plugin. The
 plan.xml file for these plugins is very simmilar, so I'm sharing a common
 file between the plugins:

 db-plugin/pom.xml --

 plugins
 plugin
 groupIdorg.apache.geronimo.buildsupport/groupId

Re: [jira] Closed: (GERONIMO-4522) history dependencies.xml file should support property substitutions. Plan processing should use maven filtering, not velocity

2009-01-27 Thread Trygve Hardersen

Hi

I hit a problem today with our custom Geronimo assembly that I think is
related to this:

We have many MySQL DB pools, each represented as a Geronimo plugin. The
plan.xml file for these plugins is very simmilar, so I'm sharing a common
file between the plugins:

db-plugin/pom.xml --

plugins
plugin
groupIdorg.apache.geronimo.buildsupport/groupId
artifactIdcar-maven-plugin/artifactId
extensionstrue/extensions
configuration
!-- We use a common plan template for DB pools --
  planFileNamemysql-pool-plan.xml/planFileName
sourceDir${project.parent.basedir}/src/main/plan/sourceDir
/configuration
/plugin
/plugins

db-plugin/src/main/plan/mysql-pool-plan.xml --

?xml version=1.0 encoding=UTF-8?
!-- The master DB connection pool --
connector xmlns=
http://geronimo.apache.org/xml/ns/j2ee/connector-${geronimoSchemaVersion}http://geronimo.apache.org/xml/ns/j2ee/connector-$%7BgeronimoSchemaVersion%7D

!-- The DB pool --
resourceadapter
outbound-resourceadapter
connection-definition

connectionfactory-interfacejavax.sql.DataSource/connectionfactory-interface
connectiondefinition-instance
name${currentDBName}/name
config-property-setting
name=ServerName${currentDBHost}/config-property-setting
config-property-setting
name=PortNumber${currentDBPort}/config-property-setting
config-property-setting
name=DatabaseName${currentDBSchema}/config-property-setting
config-property-setting
name=UserName${currentDBUser}/config-property-setting
config-property-setting
name=Password${currentDBPass}/config-property-setting
connectionmanager
local-transaction/
single-pool
max-size${currentDBMaxPoolSize}/max-size
min-size${currentDBMinPoolSize}/min-size

blocking-timeout-milliseconds${currentDBBlockTimeout}/blocking-timeout-milliseconds

idle-timeout-minutes${currentDBIdleTimeout}/idle-timeout-minutes
match-one/
/single-pool
/connectionmanager
/connectiondefinition-instance
/connection-definition
/outbound-resourceadapter
/resourceadapter
/connector

db-plugin/db-001/pom.xml --

properties
currentDBHostdb-001/currentDBHost
currentDBNamedb/shard-001/currentDBName
currentDBSchemajdb_shard_001/currentDBSchema
/properties
...
build
plugins
plugin
groupIdorg.apache.geronimo.buildsupport/groupId
artifactIdcar-maven-plugin/artifactId
configuration
deploymentConfigs

!--deploymentConfig${gbeanDeployer}/deploymentConfig--

deploymentConfig${connectorDeployer}/deploymentConfig
/deploymentConfigs
category${productName}/category
   module
groupIdorg.tranql/groupId
artifactIdtranql-connector-mysql-local/artifactId
typerar/type
   /module
/configuration
/plugin
/plugins
/build
...

The build still works, but the DB plugins are not included in the final
/var/config/config.xml file, so they are not started with the server. If I
create a plan.xml file in src/main/plan for each of the DB plugins
everything works fine.

Is my way of doing it not supported any longer, or is this a bug with
Geronimo?

Many thanks for your help!

Trygve

On Mon, Jan 26, 2009 at 9:35 AM, David Jencks (JIRA) j...@apache.orgwrote:


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

 David Jencks closed GERONIMO-4522.
 --

Resolution: Fixed

 Implemented rev 737650.

 To build g. with ee6 bits first build the jetty7 plugins from
 sandbox/djencks then do the main build with

 mvn clean install -Pee6,default



  history dependencies.xml file should support property substitutions.
  Plan processing should use maven filtering, not velocity
 
 --
 
  Key: GERONIMO-4522
  URL: https://issues.apache.org/jira/browse/GERONIMO-4522
  Project: Geronimo
   Issue Type: Bug
   Security Level: public(Regular issues)
   Components: car-maven-plugin
 Affects Versions: 2.2
 Reporter: David Jencks
 Assignee: David Jencks
  Fix For: 2.2
 
 
  In order to support easier switching between ee5 and ee6 builds we need
 to be able to use properties in the dependencies.xml files.  In addition the
 plan processing can remove a todo by using maven filtering rather than

Re: svn update performance

2009-01-13 Thread Trygve Hardersen

Same here, I've been unable to checkout the code to a new computer all day.

Trygve

On Tue, Jan 13, 2009 at 9:41 PM, Jason Warner jaw...@gmail.com wrote:

 You're not alone


 On Tue, Jan 13, 2009 at 3:39 PM, Tim McConnell tim.mcco...@gmail.comwrote:

 Is anyone other than me experiencing extremely slow svn performance,
 especially when updating the Geronimo server trunk ?? Yesterday and today
 have been excruciatingly slow.

 --
 Thanks,
 Tim McConnell




 --
 ~Jason Warner

Re: svn commit: r718393 [1/2] - in /geronimo/server/trunk/plugins/monitoring: ./ agent-car-jmx/ agent-car-jmx/src/main/history/ agent-car-jmx/src/main/plan/ agent-ds/ agent-ds/src/main/plan/ agent-ejb

2008-12-07 Thread Trygve Hardersen

Seems like this has been fixed. Thanks a lot!

Trygve

On Thu, Nov 27, 2008 at 1:42 AM, David Jencks [EMAIL PROTECTED]wrote:

 I think I see one way to fix this. now for some time to try it out.
 I'm thinking of adding a realm that generates a subject with only the
 required mejb-user principal for the ejb timer to use.

 I added a comment to the jira issue to try to remind me about this :-/

 thanks
 david jencks

 On Nov 26, 2008, at 9:28 AM, Trygve Hardersen wrote:

 Yes I've changed the password.

 In /plugins/monitoring/agent/src/main/plan/plan.xml the monitoring-user
 is set to system/manager. If I set my local system password to manager, the
 server starts fine. If I don't, the server fails to start unless I disable
 the org.apache.geronimo.plugins.monitoring/agent/2.2-SNAPSHOT/car plugin.

 I build my own Geronimo distros (mainly to be able to run on 1.6, though
 this was fixed yesterday in the client plugin), and I get around this by
 picking up a password from Maven's settings.xml and putting that in the
 plan.xml for the monitoring/agent plugin.

 Thanks!

 Trygve

 On Wed, Nov 26, 2008 at 6:15 PM, David Jencks [EMAIL PROTECTED]wrote:

 It shouldn't.  Can you confirm that all you have changed is the password
 for system in var/security/users.properties?I'm focussed on a couple
 other projects at the moment but I'll try to find some time to investigate.
 thanks
 david jencks

 On Nov 26, 2008, at 7:50 AM, Trygve Hardersen wrote:

 Hi

 I'm developing a project that uses Geronimo trunk.

 Does the org.apache.geronimo.plugins.monitoring/agent/2.2-SNAPSHOT/car
 plugin require the password for the system user to be set to manager (i.e.
 the default)? My server fails to start when I use something else. Is there a
 way, besides changing plan.xml for the plugin, to set a different password?

 Thanks in advance!

 Trygve

 On Mon, Nov 17, 2008 at 10:37 PM, [EMAIL PROTECTED] wrote:

 Author: djencks
 Date: Mon Nov 17 13:37:30 2008
 New Revision: 718393

 URL: http://svn.apache.org/viewvc?rev=718393view=rev
 Log:
 GERONIMO-4415 start of code cleanup and use of jpa in console.  Also add
 a server assembly for testing

Re: svn commit: r718393 [1/2] - in /geronimo/server/trunk/plugins/monitoring: ./ agent-car-jmx/ agent-car-jmx/src/main/history/ agent-car-jmx/src/main/plan/ agent-ds/ agent-ds/src/main/plan/ agent-ejb

2008-11-26 Thread Trygve Hardersen

Hi

I'm developing a project that uses Geronimo trunk.

Does the org.apache.geronimo.plugins.monitoring/agent/2.2-SNAPSHOT/car
plugin require the password for the system user to be set to manager (i.e.
the default)? My server fails to start when I use something else. Is there a
way, besides changing plan.xml for the plugin, to set a different password?

Thanks in advance!

Trygve

On Mon, Nov 17, 2008 at 10:37 PM, [EMAIL PROTECTED] wrote:

 Author: djencks
 Date: Mon Nov 17 13:37:30 2008
 New Revision: 718393

 URL: http://svn.apache.org/viewvc?rev=718393view=rev
 Log:
 GERONIMO-4415 start of code cleanup and use of jpa in console.  Also add a
 server assembly for testing

Re: svn commit: r718393 [1/2] - in /geronimo/server/trunk/plugins/monitoring: ./ agent-car-jmx/ agent-car-jmx/src/main/history/ agent-car-jmx/src/main/plan/ agent-ds/ agent-ds/src/main/plan/ agent-ejb

2008-11-26 Thread Trygve Hardersen

Yes I've changed the password.

In /plugins/monitoring/agent/src/main/plan/plan.xml the monitoring-user is
set to system/manager. If I set my local system password to manager, the
server starts fine. If I don't, the server fails to start unless I disable
the org.apache.geronimo.plugins.monitoring/agent/2.2-SNAPSHOT/car plugin.

I build my own Geronimo distros (mainly to be able to run on 1.6, though
this was fixed yesterday in the client plugin), and I get around this by
picking up a password from Maven's settings.xml and putting that in the
plan.xml for the monitoring/agent plugin.

Thanks!

Trygve

On Wed, Nov 26, 2008 at 6:15 PM, David Jencks [EMAIL PROTECTED]wrote:

 It shouldn't.  Can you confirm that all you have changed is the password
 for system in var/security/users.properties?I'm focussed on a couple
 other projects at the moment but I'll try to find some time to investigate.
 thanks
 david jencks

 On Nov 26, 2008, at 7:50 AM, Trygve Hardersen wrote:

 Hi

 I'm developing a project that uses Geronimo trunk.

 Does the org.apache.geronimo.plugins.monitoring/agent/2.2-SNAPSHOT/car
 plugin require the password for the system user to be set to manager (i.e.
 the default)? My server fails to start when I use something else. Is there a
 way, besides changing plan.xml for the plugin, to set a different password?

 Thanks in advance!

 Trygve

 On Mon, Nov 17, 2008 at 10:37 PM, [EMAIL PROTECTED] wrote:

 Author: djencks
 Date: Mon Nov 17 13:37:30 2008
 New Revision: 718393

 URL: http://svn.apache.org/viewvc?rev=718393view=rev
 Log:
 GERONIMO-4415 start of code cleanup and use of jpa in console.  Also add a
 server assembly for testing

[jira] Commented: (GERONIMO-4807) Hidden-classes does not support excluding files

[jira] Commented: (GERONIMO-4807) Hidden-classes does not support excluding files

[jira] Commented: (GERONIMO-4756) jetty 7 ignores default subject settings unless authentication is set up [SAMPLE APP]

Re: problem with axis/axiom dependencies building 2.2

[jira] Commented: (GERONIMO-4846) form based security for the web application does not work with Jetty WADI clustering.

[jira] Commented: (GERONIMO-4846) form based security for the web application does not work with Jetty WADI clustering.

[jira] Commented: (GERONIMO-4807) Hidden-classes does not support excluding files

Re: Compilation failures on trunk

Re: Compilation failures on trunk

[jira] Created: (GERONIMO-4777) WADI clustering does not work with Jetty7

[jira] Updated: (GERONIMO-4777) WADI clustering does not work with Jetty7

[jira] Updated: (GERONIMO-4777) WADI clustering does not work with Jetty7

[jira] Commented: (GERONIMO-4756) jetty 7 ignores default subject settings unless authentication is set up

[jira] Commented: (GERONIMO-4756) jetty 7 ignores default subject settings unless authentication is set up

[jira] Updated: (GERONIMO-4756) jetty 7 ignores default subject settings unless authentication is set up

[jira] Commented: (GERONIMO-4756) jetty 7 ignores default subject settings unless authentication is set up

Re: Default Subject configuration for Jetty assembility

Re: Default Subject configuration for Jetty assembility

Re: svn commit: r792824 - in /geronimo/server/trunk: plugins/axis/geronimo-axis-builder/src/main/java/org/apache/geronimo/axis/builder/ plugins/axis/geronimo-axis/src/main/java/org/apache/geronimo/a

[jira] Commented: (GERONIMO-4682) Unique snapshots does not work

[jira] Issue Comment Edited: (GERONIMO-4682) Unique snapshots does not work

[jira] Commented: (GERONIMO-4682) Unique snapshots does not work

[jira] Commented: (GERONIMO-4682) Unique snapshots does not work

[jira] Created: (GERONIMO-4682) Unique snapshots does not work

[jira] Commented: (GERONIMO-4682) Unique snapshots does not work

[jira] Commented: (GERONIMO-4587) Array security issue

Re: [BUILD] trunk: Failed for Revision: 779134

[jira] Created: (GERONIMO-4587) Array security issue

Re: [jira] Closed: (GERONIMO-4522) history dependencies.xml file should support property substitutions. Plan processing should use maven filtering, not velocity

Re: [jira] Closed: (GERONIMO-4522) history dependencies.xml file should support property substitutions. Plan processing should use maven filtering, not velocity

Re: svn update performance

Re: svn commit: r718393 [1/2] - in /geronimo/server/trunk/plugins/monitoring: ./ agent-car-jmx/ agent-car-jmx/src/main/history/ agent-car-jmx/src/main/plan/ agent-ds/ agent-ds/src/main/plan/ agent-ejb

Re: svn commit: r718393 [1/2] - in /geronimo/server/trunk/plugins/monitoring: ./ agent-car-jmx/ agent-car-jmx/src/main/history/ agent-car-jmx/src/main/plan/ agent-ds/ agent-ds/src/main/plan/ agent-ejb

Re: svn commit: r718393 [1/2] - in /geronimo/server/trunk/plugins/monitoring: ./ agent-car-jmx/ agent-car-jmx/src/main/history/ agent-car-jmx/src/main/plan/ agent-ds/ agent-ds/src/main/plan/ agent-ejb

34 matches

Site Navigation

Mail list logo

Footer information