Re: net.sf.cglib.core.CodeGenerationException: what does usually mean
thanks everybody :) .. for the time been I will create my interface to match with configuration GBean and put a referance to it. Thanks Srinath On Tue, 23 Nov 2004 12:29:16 -0800, Dain Sundstrom [EMAIL PROTECTED] wrote: On Nov 23, 2004, at 10:48 AM, Aaron Mulder wrote: We might as well poll to see if anyone's using it, but it just seems dangerous to keep around in principle. I'd rather make people implement the interface and have some methods throw an UnsupportedOperationException instead of getting some kind of method doesn't exist error out of CGlib... It's not clear in that case that it's the callee's fault not the caller (or builder's) fault. I would never go as far as to require the target to implement the interface, as this creates all sorts of classloader issues, and it does not allow us to reference gbeans that implement no interfaces. I was suggesting that when we create a reference proxy we assure that the target exposes all of the necessary operations and attributes. -dain
[jira] Commented: (GERONIMO-234) Build fails when maven/plugins is not writable
[ http://nagoya.apache.org/jira/browse/GERONIMO-234?page=comments#action_55827 ] Rodrigo S. de Castro commented on GERONIMO-234: --- I checked Maven's code and it seems to have an inconsistent behaviour between the plugin:install and plugin:install-now, since the former install plugin in the global dir and the latter in the user dir. I submitted a bug to Maven Plugin Pluing, along with a very simple patch to fix that, allowing Geronimo to install the plugin without problems. Let's wait and check if the analysis is confirmed. You may check this issue here: http://jira.codehaus.org/browse/MPPLUGIN-30 Build fails when maven/plugins is not writable -- Key: GERONIMO-234 URL: http://nagoya.apache.org/jira/browse/GERONIMO-234 Project: Apache Geronimo Type: Improvement Components: buildsystem Versions: 1.0-M1 Environment: Linux [Debian | SuSE ], Maven RC1, Geronimo HEAD Reporter: Bernd Fondermann Assignee: Dain Sundstrom Priority: Minor When building by invoking 'maven' the build fails with the following error message when the maven plugin directory is not writable: + | Executing (default): Geronimo :: Deployment | Memory: 34M/43M + Attempting to download geronimo-xmlbeans-plugin-1.0-SNAPSHOT.jar. Attempting to download geronimo-kernel-1.0-SNAPSHOT.jar. Attempting to download geronimo-common-1.0-SNAPSHOT.jar. Attempting to download geronimo-system-1.0-SNAPSHOT.jar. BUILD FAILED File.. file:/home/username/apache/incubator-geronimo/ Element... maven:reactor Line.. 180 Column 27 /usr/local/maven-1.0-rc1/plugins/geronimo-xmlbeans-plugin-1.0-SNAPSHOT.jar (Permission denied) The immediate fix is to make plugins folder writable. I don't like any project modifying their sibbling projects... couldn't this also lead to unexpected results in a multi-user environment where maven is shared among users? -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://nagoya.apache.org/jira/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira
Unsbscribe
Unsbscirbe
[jira] Created: (GERONIMO-501) could not deploy an ejb-jar archive with M3
could not deploy an ejb-jar archive with M3 --- Key: GERONIMO-501 URL: http://nagoya.apache.org/jira/browse/GERONIMO-501 Project: Apache Geronimo Type: Bug Components: deployment Versions: 1.0-M3 Environment: OS: Windows XP pro SP2 JDK: java version 1.4.2_05 Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_05-b04) Java HotSpot(TM) Client VM (build 1.4.2_05-b04, mixed mode) Reporter: Bill Brown Greetings: I was unsuccessful in attempting to deploy an archive from the M3 build of Geronimo. I was able to start the server from the README.txt instructions C:\geronimo java -jar bin\server.jar org/apache/geronimo/DebugConsole. I then tried to deploy my ejb-jar with the following instructions from the README.txt example (It is also listed in the WIKI) $ java -jar bin/deployer.jar --install --module ../dev/GOCSC/ejb/busObjs/busObjs.jar. This did not work because of the syntax --install --module which is not recognized from by deployer.jar. I then tried to deploy with command below and got the following output [EMAIL PROTECTED] ~/geronimo-1.0-M3 $ java -jar bin/deployer.jar deploy ../dev/GOCSC/ejb/busObjs/busObjs.jar Username: system Password: manager Deployment failed Server reports: No deployer found:, moduleFilec:\geronimo-1.0-M3\..\dev\GOCSC\ ejb\busObjs\busObjs.jar org.apache.geronimo.deployment.DeploymentException: No deployer found:, moduleFi lec:\geronimo-1.0-M3\..\dev\GOCSC\ejb\busObjs\busObjs.jar at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:140) at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:60) at org.apache.geronimo.deployment.Deployer$$FastClassByCGLIB$$734a235d.i nvoke(generated) at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:87) at org.apache.geronimo.gbean.jmx.FastMethodInvoker.invoke(FastMethodInvo ker.java:38) at org.apache.geronimo.gbean.jmx.GBeanMBeanOperation.invoke(GBeanMBeanOp eration.java:142) at org.apache.geronimo.gbean.jmx.GBeanMBean.invoke(GBeanMBean.java:844) at mx4j.server.interceptor.InvokerMBeanServerInterceptor.invoke(InvokerM BeanServerInterceptor.java:218) at mx4j.server.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultM BeanServerInterceptor.java:121) at mx4j.server.interceptor.SecurityMBeanServerInterceptor.invoke(Securit yMBeanServerInterceptor.java:86) at mx4j.server.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultM BeanServerInterceptor.java:121) at mx4j.server.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultM BeanServerInterceptor.java:121) at mx4j.server.interceptor.ContextClassLoaderMBeanServerInterceptor.invo ke(ContextClassLoaderMBeanServerInterceptor.java:205) at mx4j.server.MX4JMBeanServer.invoke(MX4JMBeanServer.java:1079) at org.apache.geronimo.kernel.Kernel.invoke(Kernel.java:288) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) at java.lang.reflect.Method.invoke(Unknown Source) at mx4j.server.ReflectionMBeanInvoker.invokeImpl(ReflectionMBeanInvoker. java:152) at mx4j.server.ReflectionMBeanInvoker.doInvoke(ReflectionMBeanInvoker.ja va:119) at mx4j.server.ReflectionMBeanInvoker.invoke(ReflectionMBeanInvoker.java :54) at mx4j.server.interceptor.InvokerMBeanServerInterceptor.invoke(InvokerM BeanServerInterceptor.java:235) at mx4j.server.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultM BeanServerInterceptor.java:121) at mx4j.server.interceptor.SecurityMBeanServerInterceptor.invoke(Securit yMBeanServerInterceptor.java:86) at mx4j.server.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultM BeanServerInterceptor.java:121) at mx4j.server.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultM BeanServerInterceptor.java:121) at mx4j.server.interceptor.ContextClassLoaderMBeanServerInterceptor.invo ke(ContextClassLoaderMBeanServerInterceptor.java:205) at mx4j.server.MX4JMBeanServer.invoke(MX4JMBeanServer.java:1079) at mx4j.remote.rmi.RMIConnectionInvoker.invoke(RMIConnectionInvoker.java :222) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) at java.lang.reflect.Method.invoke(Unknown Source) at mx4j.remote.rmi.RMIConnectionProxy.invoke(RMIConnectionProxy.java:36) at mx4j.remote.rmi.RMIConnectionSubjectInvoker.chain(RMIConnectionSubjec tInvoker.java:98) at mx4j.remote.rmi.RMIConnectionSubjectInvoker.access$000(RMIConnectionS ubjectInvoker.java:32) at
[jira] Closed: (GERONIMO-499) JMSException not compliant with JMS 1.1 spec
[ http://nagoya.apache.org/jira/browse/GERONIMO-499?page=history ] Jeremy Boynes closed GERONIMO-499: -- JMSException not compliant with JMS 1.1 spec Key: GERONIMO-499 URL: http://nagoya.apache.org/jira/browse/GERONIMO-499 Project: Apache Geronimo Type: Bug Components: specs Reporter: Michael Gaffney Priority: Blocker Attachments: jms_exception.patch The serialized form of Geronimo's javax.jms.JMSException is not compatible with the serialized form of the javax.jms.JMSException defined in the JMS 1.1 specification. Using the serialver tool I obtained the serialVersionUID for the javax.jms.JMSException class from the three sources. Here are the sources along with their serialVersionUID values: JMS Spec: serialVersionUID = 8951994251593378324L; JBoss : serialVersionUID = 8951994251593378324L; geronimo: serialVersionUID = 2368476267211489441L; OK, I know this may seem trivial but while I was working on integrating ActiveMQ with JBoss this problem popped up over and over again. The problem is that the 'setLinkedException(..)' method needs to be declared 'synchronized'. I will attach a patch immediately. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://nagoya.apache.org/jira/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira
Remoting Test Failure
I'm getting a failure in org.apache.geronimo.remoting.RemotingInterceptorsTest (which I think is one that Dain did not change in his recent checkin, though it appears to use proxies). Note: this only happens on JDK 1.5.0 64-bit -- JDK 1.4 (32 or 64 bit) and JDK 1.5 32-bit seem to be unaffected. Go figure. Aaron Testcase: testSetTransientWithSerializedNonOptimizedProxy(org.apache.geronimo.re moting.RemotingInterceptorsTest): Caused an ERROR null java.lang.reflect.UndeclaredThrowableException at $Proxy15.getValue(Unknown Source) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl. java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces sorImpl.java:25) at org.apache.geronimo.remoting.RemotingInterceptorsTest.call(RemotingIn terceptorsTest.java:302) at org.apache.geronimo.remoting.RemotingInterceptorsTest.testSetTransien tWithSerializedNonOptimizedProxy(RemotingInterceptorsTest.java:283) ... Caused by: org.apache.geronimo.remoting.transport.TransportException: Request ti me out. at org.apache.geronimo.remoting.transport.async.ChannelPool.sendRequest( ChannelPool.java:429) at org.apache.geronimo.remoting.transport.async.AsyncClient.sendRequest( AsyncClient.java:54) at org.apache.geronimo.remoting.transport.RemoteTransportInterceptor.inv oke(RemoteTransportInterceptor.java:62) at org.apache.geronimo.remoting.MarshalingInterceptor.invoke(MarshalingI nterceptor.java:46) at org.apache.geronimo.remoting.InterVMRoutingInterceptor.invoke(InterVM RoutingInterceptor.java:49) at org.apache.geronimo.proxy.SimpleRPCContainer.invoke(SimpleRPCContaine r.java:48) at org.apache.geronimo.proxy.ProxyContainer.invoke(ProxyContainer.java:5 1) ... 74 more
GBeans, Kernel and JMX Exceptions
One of the last areas of tight coupling to JMX in the Geronimo kernel and the GBean architecture is the use of JMX Exceptions. These the exceptions are normally not declared as part of the interface, but are thrown from the methods that declare throws Exception. I propose that we catch all JMX exceptions and convert them to the following Geronimo specific exceptions: KernelException - Base class for the following exceptions. Direct subclass of Exception. GBeanNotFoundException - Thrown from getAttribute, setAttribute, invoke, getGBeanInfo, getClassLoaderFor, startGBean, startRecursiveGBean, stopGBean, and unloadGBean. This replaces javax.management.InstanceNotFoundException. GBeanAlreadyExistsException - Thrown from loadGBean. This replaces javax.management.InstanceAlreadyExistsException. InvalidGBeanException - Thrown from loadGBean. This is used instead of javax.management.NotCompliantMBeanException. NoSuchAttributeException - Thrown from getAttribute and setAttribute. This replaces javax.management.AttributeNotFoundException NoSuchOperationException - Thrown from invoke. There is no equivalent exception in JMX. InternalKernelException - Extend runtime exception. Thrown from all methods on kernel. This exception will contain any java.lang.Exception (and for the improbable case of direct subclass of java.lang.Throwable) thrown from the kernel or gbean architecture itself. This allows callers to differentiate between kernel problems and exceptions from the GBean instance implementation. -dain -- Dain Sundstrom Chief Architect Gluecode Software 310.536.8355, ext. 26
Re: Remoting Test Failure
On Nov 24, 2004, at 10:21 AM, Aaron Mulder wrote: On Wed, 24 Nov 2004, Dain Sundstrom wrote: What is inside the undeclared throwable? It appears to be the timeout exception (TransportException) down a little further. That's all I get in the log output, at any rate. Also, it turns out that I don't get the problem every time. That may cast doubt on the JVM's that I said worked, because I should really try them a few times each before I say that. (I'm using maven m:rebuild-all and maven -o m:rebuild-all and online/offline doesn't seem to make a difference.) Ah... I see these all the time, but the always go away after the second build. I assumed it was due to the apple vm being super slow (network code runs 10 times slower on apple). -dain
Re: GBeans, Kernel and JMX Exceptions
Sounds reasonable - I can roll this into the ObjectName changes. -- Jeremy Dain Sundstrom wrote: One of the last areas of tight coupling to JMX in the Geronimo kernel and the GBean architecture is the use of JMX Exceptions. These the exceptions are normally not declared as part of the interface, but are thrown from the methods that declare throws Exception. I propose that we catch all JMX exceptions and convert them to the following Geronimo specific exceptions: KernelException - Base class for the following exceptions. Direct subclass of Exception. GBeanNotFoundException - Thrown from getAttribute, setAttribute, invoke, getGBeanInfo, getClassLoaderFor, startGBean, startRecursiveGBean, stopGBean, and unloadGBean. This replaces javax.management.InstanceNotFoundException. GBeanAlreadyExistsException - Thrown from loadGBean. This replaces javax.management.InstanceAlreadyExistsException. InvalidGBeanException - Thrown from loadGBean. This is used instead of javax.management.NotCompliantMBeanException. NoSuchAttributeException - Thrown from getAttribute and setAttribute. This replaces javax.management.AttributeNotFoundException NoSuchOperationException - Thrown from invoke. There is no equivalent exception in JMX. InternalKernelException - Extend runtime exception. Thrown from all methods on kernel. This exception will contain any java.lang.Exception (and for the improbable case of direct subclass of java.lang.Throwable) thrown from the kernel or gbean architecture itself. This allows callers to differentiate between kernel problems and exceptions from the GBean instance implementation. -dain -- Dain Sundstrom Chief Architect Gluecode Software 310.536.8355, ext. 26
Re: GBeans, Kernel and JMX Exceptions
When you going to make that change? I'm working on the GBean code right now, but will be offline Thursday until Sunday Morning. Also, I'm a bit curious about the GBeanName interface? For example, I assume we are keeping the concept of pattern matching, but are we keeping the concept that a name contains name/value pairs. I know there is some J2EE deployment code manipulate the name/value pairs to build new object names. -dain -- Dain Sundstrom Chief Architect Gluecode Software 310.536.8355, ext. 26 On Nov 24, 2004, at 10:51 AM, Jeremy Boynes wrote: Sounds reasonable - I can roll this into the ObjectName changes. -- Jeremy Dain Sundstrom wrote: One of the last areas of tight coupling to JMX in the Geronimo kernel and the GBean architecture is the use of JMX Exceptions. These the exceptions are normally not declared as part of the interface, but are thrown from the methods that declare throws Exception. I propose that we catch all JMX exceptions and convert them to the following Geronimo specific exceptions: KernelException - Base class for the following exceptions. Direct subclass of Exception. GBeanNotFoundException - Thrown from getAttribute, setAttribute, invoke, getGBeanInfo, getClassLoaderFor, startGBean, startRecursiveGBean, stopGBean, and unloadGBean. This replaces javax.management.InstanceNotFoundException. GBeanAlreadyExistsException - Thrown from loadGBean. This replaces javax.management.InstanceAlreadyExistsException. InvalidGBeanException - Thrown from loadGBean. This is used instead of javax.management.NotCompliantMBeanException. NoSuchAttributeException - Thrown from getAttribute and setAttribute. This replaces javax.management.AttributeNotFoundException NoSuchOperationException - Thrown from invoke. There is no equivalent exception in JMX. InternalKernelException - Extend runtime exception. Thrown from all methods on kernel. This exception will contain any java.lang.Exception (and for the improbable case of direct subclass of java.lang.Throwable) thrown from the kernel or gbean architecture itself. This allows callers to differentiate between kernel problems and exceptions from the GBean instance implementation. -dain -- Dain Sundstrom Chief Architect Gluecode Software 310.536.8355, ext. 26
Re: LoginDomains and automapping
Jeff,
According to a conversating I just had with Alan, the other
container modules use a method of authorization with JACC that doesn't
require the containers to access all the principals. Basically, they just
give JACC the Subject containing an IdentificationPrincipal (which you
have), and our JACC implementation looks up the proper Subject and does
the calculations all on its side.
Alan thought that maybe Tomcat does authorization differently
(using Subject.doAs), in which case Tomcat would specifically need all the
RealmPrincipals to be present. However, as that appears to be fairly
slow, it's not ideal anyway.
So in the short term, you should probably try to insert a call to
ContextManager.getServerSideSubject which will get you all the
RealmPrincipals too. If you really have trouble inserting the call in
there, worst case, you could create a wrapper LoginModule that calls our
JaasLoginCoordinator LoginModule and then calls
ContextManager.getServerSideSubject and writes all the RealmPrincipals
into the Subject that will be returned to the caller. In the long term,
we'd like to adjust the interface between Tomcat and Geronimo to use a
different authorization method, which will mean the RealmPrincipals are no
longer necessary.
Aaron
On Tue, 23 Nov 2004, Jeff Genender wrote:
Ok, then this is my mistake. I assumed you were filling in the Subject
with the principals, but as I re-read, I saw what you were saying,
regarding the necessity to continue to call
ContextManager.getServerSideSubject.
I have some code that Alan and I worked on in the JaasLoginCoordinator
that populates the subject with the principals that I *think* does the
automagically you referred to in the previous email. I had the
JaasLoginService.serverLoginModuleCommit() return a Collection of
Principals, and then I set these principals in the Subject in the
JaasLoginCoordinator.ServerLoginModule.commit(), very similarly as the
ClientLoginModule. So I believe that in the same JVM, this may do as
what you stated below. I have included the patch which we have come up
with thus far. This is only for you guys to look at as I have not run
the unit tests for this yet.
If I am off base here, please set me straight. I am new to this code
and am just getting my feet wet in seeing what its doing, so I may end
up in a few dead ends.
Let me know if you would like me to continue down this path, and I can
write the unit tests for it and submit the changes.
Jeff
Here is the patch:
Index: src/java/org/apache/geronimo/security/jaas/JaasLoginCoordinator.java
===
--- src/java/org/apache/geronimo/security/jaas/JaasLoginCoordinator.java
(revision 106054)
+++ src/java/org/apache/geronimo/security/jaas/JaasLoginCoordinator.java
(working copy)
@@ -210,7 +210,13 @@
}
public boolean commit() throws LoginException {
-return service.serverLoginModuleCommit(client, index);
+Collection c = service.serverLoginModuleCommit(client, index);
+if (c == null)
+return false;
+
+subject.getPrincipals().addAll(c);
+
+return true;
}
public boolean abort() throws LoginException {
Index: src/java/org/apache/geronimo/security/jaas/JaasLoginService.java
===
--- src/java/org/apache/geronimo/security/jaas/JaasLoginService.java
(revision 106054)
+++ src/java/org/apache/geronimo/security/jaas/JaasLoginService.java
(working copy)
@@ -260,7 +260,7 @@
* once for each server-side login module that was processed
before the
* overall authentication succeeded.
*/
-public boolean serverLoginModuleCommit(JaasClientId userIdentifier,
int loginModuleIndex) throws LoginException {
+public Collection serverLoginModuleCommit(JaasClientId
userIdentifier, int loginModuleIndex) throws LoginException {
JaasSecurityContext context = (JaasSecurityContext)
activeLogins.get(userIdentifier);
if(context == null) {
throw new ExpiredLoginModuleException();
@@ -270,8 +270,16 @@
}
JaasLoginModuleConfiguration module =
context.getModules()[loginModuleIndex];
boolean result = module.getLoginModule(classLoader).commit();
+
+if (!result)
+return null;
+
context.processPrincipals();
-return result;
+Subject s = context.getSubject();
+if (s == null)
+return null;
+
+return s.getPrincipals();
}
/**
Index: src/java/org/apache/geronimo/security/jaas/JaasLoginServiceMBean.java
===
---
src/java/org/apache/geronimo/security/jaas/JaasLoginServiceMBean.java
(revision
Re: LoginDomains and automapping
Aaron,
Thanks for the reply. I took the JAASRealm code from Tomcat, and made a
Geronimo version which makes a call to ContextManager.getServerSideSubject
after obtaining the subject. I will test this when I get home tonight.
I very interested in discussing the long term approach with you as I would
like to begin thinking in this direction.
Thanks for the input, it is appreciated.
Jeff
Jeff,
According to a conversating I just had with Alan, the other
container modules use a method of authorization with JACC that doesn't
require the containers to access all the principals. Basically, they just
give JACC the Subject containing an IdentificationPrincipal (which you
have), and our JACC implementation looks up the proper Subject and does
the calculations all on its side.
Alan thought that maybe Tomcat does authorization differently
(using Subject.doAs), in which case Tomcat would specifically need all the
RealmPrincipals to be present. However, as that appears to be fairly
slow, it's not ideal anyway.
So in the short term, you should probably try to insert a call to
ContextManager.getServerSideSubject which will get you all the
RealmPrincipals too. If you really have trouble inserting the call in
there, worst case, you could create a wrapper LoginModule that calls our
JaasLoginCoordinator LoginModule and then calls
ContextManager.getServerSideSubject and writes all the RealmPrincipals
into the Subject that will be returned to the caller. In the long term,
we'd like to adjust the interface between Tomcat and Geronimo to use a
different authorization method, which will mean the RealmPrincipals are no
longer necessary.
Aaron
On Tue, 23 Nov 2004, Jeff Genender wrote:
Ok, then this is my mistake. I assumed you were filling in the Subject
with the principals, but as I re-read, I saw what you were saying,
regarding the necessity to continue to call
ContextManager.getServerSideSubject.
I have some code that Alan and I worked on in the JaasLoginCoordinator
that populates the subject with the principals that I *think* does the
automagically you referred to in the previous email. I had the
JaasLoginService.serverLoginModuleCommit() return a Collection of
Principals, and then I set these principals in the Subject in the
JaasLoginCoordinator.ServerLoginModule.commit(), very similarly as the
ClientLoginModule. So I believe that in the same JVM, this may do as
what you stated below. I have included the patch which we have come up
with thus far. This is only for you guys to look at as I have not run
the unit tests for this yet.
If I am off base here, please set me straight. I am new to this code
and am just getting my feet wet in seeing what its doing, so I may end
up in a few dead ends.
Let me know if you would like me to continue down this path, and I can
write the unit tests for it and submit the changes.
Jeff
Here is the patch:
Index:
src/java/org/apache/geronimo/security/jaas/JaasLoginCoordinator.java
===
--- src/java/org/apache/geronimo/security/jaas/JaasLoginCoordinator.java
(revision 106054)
+++ src/java/org/apache/geronimo/security/jaas/JaasLoginCoordinator.java
(working copy)
@@ -210,7 +210,13 @@
}
public boolean commit() throws LoginException {
-return service.serverLoginModuleCommit(client, index);
+Collection c = service.serverLoginModuleCommit(client,
index);
+if (c == null)
+return false;
+
+subject.getPrincipals().addAll(c);
+
+return true;
}
public boolean abort() throws LoginException {
Index: src/java/org/apache/geronimo/security/jaas/JaasLoginService.java
===
--- src/java/org/apache/geronimo/security/jaas/JaasLoginService.java
(revision 106054)
+++ src/java/org/apache/geronimo/security/jaas/JaasLoginService.java
(working copy)
@@ -260,7 +260,7 @@
* once for each server-side login module that was processed
before the
* overall authentication succeeded.
*/
-public boolean serverLoginModuleCommit(JaasClientId userIdentifier,
int loginModuleIndex) throws LoginException {
+public Collection serverLoginModuleCommit(JaasClientId
userIdentifier, int loginModuleIndex) throws LoginException {
JaasSecurityContext context = (JaasSecurityContext)
activeLogins.get(userIdentifier);
if(context == null) {
throw new ExpiredLoginModuleException();
@@ -270,8 +270,16 @@
}
JaasLoginModuleConfiguration module =
context.getModules()[loginModuleIndex];
boolean result = module.getLoginModule(classLoader).commit();
+
+if (!result)
+return null;
+
context.processPrincipals();
-return result;
+Subject s
tools.jar classpath problem
Hi. How do I force geronimo to look in a specific place for tools.jar? It's trying to load it from some old JRE I dumped long ago and complaining it can't find it. (JAVA_HOME points to my current JDK 1.4.2._05) Thanks K.
RE: tools.jar classpath problem
Sometimes you have to start java using its entire path instead of just the executable name, e.g.: /cygdrive/c/java/j2sdk1.4.2_06/bin/java -jar bin/server.jar Regards, Alan -Original Message- From: Kuato [mailto:[EMAIL PROTECTED] Sent: Wed 11/24/2004 3:14 PM To: [EMAIL PROTECTED] Cc: Subject: tools.jar classpath problem Hi. How do I force geronimo to look in a specific place for tools.jar? It's trying to load it from some old JRE I dumped long ago and complaining it can't find it. (JAVA_HOME points to my current JDK 1.4.2._05) Thanks K.
[jira] Commented: (GERONIMO-501) could not deploy an ejb-jar archive with M3
[ http://nagoya.apache.org/jira/browse/GERONIMO-501?page=comments#action_55833 ] Aaron Mulder commented on GERONIMO-501: --- Updated README Added link to updated README to web site (not live yet; will be published eventually) http://svn.apache.org/viewcvs.cgi/*checkout*/geronimo/trunk/README.txt?rev=106435 As far as your error goes, this probably means that Geronimo was not able to process your ejb-jar.xml or openejb-jar.xml files (if you're using M3; the same error might mean something different in SVN HEAD). Can you validate those two files against the schemas in geronimo/schema/ and/or post them here? could not deploy an ejb-jar archive with M3 --- Key: GERONIMO-501 URL: http://nagoya.apache.org/jira/browse/GERONIMO-501 Project: Apache Geronimo Type: Bug Components: deployment Versions: 1.0-M3 Environment: OS: Windows XP pro SP2 JDK: java version 1.4.2_05 Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_05-b04) Java HotSpot(TM) Client VM (build 1.4.2_05-b04, mixed mode) Reporter: Bill Brown Greetings: I was unsuccessful in attempting to deploy an archive from the M3 build of Geronimo. I was able to start the server from the README.txt instructions C:\geronimo java -jar bin\server.jar org/apache/geronimo/DebugConsole. I then tried to deploy my ejb-jar with the following instructions from the README.txt example (It is also listed in the WIKI) $ java -jar bin/deployer.jar --install --module ../dev/GOCSC/ejb/busObjs/busObjs.jar. This did not work because of the syntax --install --module which is not recognized from by deployer.jar. I then tried to deploy with command below and got the following output [EMAIL PROTECTED] ~/geronimo-1.0-M3 $ java -jar bin/deployer.jar deploy ../dev/GOCSC/ejb/busObjs/busObjs.jar Username: system Password: manager Deployment failed Server reports: No deployer found:, moduleFilec:\geronimo-1.0-M3\..\dev\GOCSC\ ejb\busObjs\busObjs.jar org.apache.geronimo.deployment.DeploymentException: No deployer found:, moduleFi lec:\geronimo-1.0-M3\..\dev\GOCSC\ejb\busObjs\busObjs.jar at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:140) at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:60) at org.apache.geronimo.deployment.Deployer$$FastClassByCGLIB$$734a235d.i nvoke(generated) at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:87) at org.apache.geronimo.gbean.jmx.FastMethodInvoker.invoke(FastMethodInvo ker.java:38) at org.apache.geronimo.gbean.jmx.GBeanMBeanOperation.invoke(GBeanMBeanOp eration.java:142) at org.apache.geronimo.gbean.jmx.GBeanMBean.invoke(GBeanMBean.java:844) at mx4j.server.interceptor.InvokerMBeanServerInterceptor.invoke(InvokerM BeanServerInterceptor.java:218) at mx4j.server.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultM BeanServerInterceptor.java:121) at mx4j.server.interceptor.SecurityMBeanServerInterceptor.invoke(Securit yMBeanServerInterceptor.java:86) at mx4j.server.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultM BeanServerInterceptor.java:121) at mx4j.server.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultM BeanServerInterceptor.java:121) at mx4j.server.interceptor.ContextClassLoaderMBeanServerInterceptor.invo ke(ContextClassLoaderMBeanServerInterceptor.java:205) at mx4j.server.MX4JMBeanServer.invoke(MX4JMBeanServer.java:1079) at org.apache.geronimo.kernel.Kernel.invoke(Kernel.java:288) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) at java.lang.reflect.Method.invoke(Unknown Source) at mx4j.server.ReflectionMBeanInvoker.invokeImpl(ReflectionMBeanInvoker. java:152) at mx4j.server.ReflectionMBeanInvoker.doInvoke(ReflectionMBeanInvoker.ja va:119) at mx4j.server.ReflectionMBeanInvoker.invoke(ReflectionMBeanInvoker.java :54) at mx4j.server.interceptor.InvokerMBeanServerInterceptor.invoke(InvokerM BeanServerInterceptor.java:235) at mx4j.server.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultM BeanServerInterceptor.java:121) at mx4j.server.interceptor.SecurityMBeanServerInterceptor.invoke(Securit yMBeanServerInterceptor.java:86) at mx4j.server.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultM BeanServerInterceptor.java:121) at mx4j.server.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultM BeanServerInterceptor.java:121) at mx4j.server.interceptor.ContextClassLoaderMBeanServerInterceptor.invo
Re: GBeans, Kernel and JMX Exceptions
+1 from me. On Wed, 24 Nov 2004 10:39:18 -0800, Dain Sundstrom [EMAIL PROTECTED] wrote: One of the last areas of tight coupling to JMX in the Geronimo kernel and the GBean architecture is the use of JMX Exceptions. These the exceptions are normally not declared as part of the interface, but are thrown from the methods that declare throws Exception. I propose that we catch all JMX exceptions and convert them to the following Geronimo specific exceptions: KernelException - Base class for the following exceptions. Direct subclass of Exception. GBeanNotFoundException - Thrown from getAttribute, setAttribute, invoke, getGBeanInfo, getClassLoaderFor, startGBean, startRecursiveGBean, stopGBean, and unloadGBean. This replaces javax.management.InstanceNotFoundException. GBeanAlreadyExistsException - Thrown from loadGBean. This replaces javax.management.InstanceAlreadyExistsException. InvalidGBeanException - Thrown from loadGBean. This is used instead of javax.management.NotCompliantMBeanException. NoSuchAttributeException - Thrown from getAttribute and setAttribute. This replaces javax.management.AttributeNotFoundException NoSuchOperationException - Thrown from invoke. There is no equivalent exception in JMX. InternalKernelException - Extend runtime exception. Thrown from all methods on kernel. This exception will contain any java.lang.Exception (and for the improbable case of direct subclass of java.lang.Throwable) thrown from the kernel or gbean architecture itself. This allows callers to differentiate between kernel problems and exceptions from the GBean instance implementation. -dain -- Dain Sundstrom Chief Architect Gluecode Software 310.536.8355, ext. 26 -- Davanum Srinivas - http://webservices.apache.org/~dims/
Re: GBeans, Kernel and JMX Exceptions
Dain Sundstrom wrote: When you going to make that change? I'm working on the GBean code right now, but will be offline Thursday until Sunday Morning. I've been waiting to see if there is any more input given this is not critical and it does change the API. As I said, I plan to get to it this week. Are you going to finish up your changes before you disappear? Also, I'm a bit curious about the GBeanName interface? For example, I assume we are keeping the concept of pattern matching, but are we keeping the concept that a name contains name/value pairs. I know there is some J2EE deployment code manipulate the name/value pairs to build new object names. Of course - there is a lot of other stuff that relies on this. -- Jeremy
Re: GBeans, Kernel and JMX Exceptions
On Nov 24, 2004, at 12:54 PM, Jeremy Boynes wrote: Dain Sundstrom wrote: When you going to make that change? I'm working on the GBean code right now, but will be offline Thursday until Sunday Morning. I've been waiting to see if there is any more input given this is not critical and it does change the API. As I said, I plan to get to it this week. Are you going to finish up your changes before you disappear? I hope so :) I'm getting close Also, I'm a bit curious about the GBeanName interface? For example, I assume we are keeping the concept of pattern matching, but are we keeping the concept that a name contains name/value pairs. I know there is some J2EE deployment code manipulate the name/value pairs to build new object names. Of course - there is a lot of other stuff that relies on this. cool -dain
