RE: auto-generating documentation for C++ client?
Looks good guys, thanks for getting that setup. - Timothy A. Bish Sensis Corporation - -Original Message- From: Nathan Mittler [mailto:[EMAIL PROTECTED] Sent: Thursday, August 03, 2006 6:14 AM To: activemq-dev@geronimo.apache.org Subject: Re: auto-generating documentation for C++ client? Awesome! Thanks. On 8/3/06, James Strachan [EMAIL PROTECTED] wrote: On 8/3/06, James Strachan [EMAIL PROTECTED] wrote: There you go... http://svn.apache.org/repos/asf/incubator/activemq/site/cms/ hopefully in an hour or so it should show up here http://incubator.apache.org/activemq/cms/html/ Unfortunately right now Confluence is down so we can't yet edit these pages to add a link... http://incubator.apache.org/activemq/javadocs.html http://incubator.apache.org/activemq/cms.html Done e.g. http://activemq.org/site/javadocs.html -- James --- http://radio.weblogs.com/0112098/
Is there a good reason for having a static Executor for Sessions shared across all Connections?
I'm just investigating a Lingo test case (LINGO-22) submitted by Jim Beattie which tests that we leave no threads around after shutting down lingo ActiveMQ - which sounds good to me. I've noticed that the Executor for all connections is a static and shared across connections. I was gonna make it so that after all connections are closed all threads are cleanly shutdown - I've a refactor of Jim's test case to test for this. I just wondered before I go ahead and change things - was there a good reason to keep the TaskRunnerFactory / Executor a singleton? I was thinking of creating one per connection. Failing that we could keep it a singleton and just reference count the connections so we can close it when the last connection goes away Am wondering if this was an optimisation to minimise context switching when using lots of sessions - or is it just an oversight? -- James --- http://radio.weblogs.com/0112098/
Re: Creating a secure connection system and using JMSXUserID support
There is one in ServiceMix. http://svn.apache.org/repos/asf/incubator/servicemix/trunk/servicemix-core/src/main/java/org/apache/servicemix/jbi/security/login/ On 8/2/06, Hiram Chirino [EMAIL PROTECTED] wrote: On 8/1/06, Sepand M [EMAIL PROTECTED] wrote: Hi all, So far I've mainly been reading ActiveMQ and making design docs. Here's what I've got: For authorization, my current plan is to just have the client's DN replace the user name field in the ConnectionInfo class (how this is done is explained below). I want to do this because I don't know much about JAAS and I'm trying to avoid writing classes to authorize based on DNs. If you guys know this stuff (and you probably do), we could change this easily enough. Here's the rest of my design: I want to modify SslTransportFactory to use a specific SslContext object and allow client's access to its init method so that they can set their own key and trust managers. I also want to create new SslTransport and SslTransportServer classes. SslTransport will be derived from TcpTransport. Its main task will be to replace the user name field of ConnectionInfo commands with its socket's DN (this could be changed easily to attach the entire certificate to ConnectionInfo as a new generic field). SslTransport will also make sure that it uses SslSocketFactory's. SslTransportServer will only be there to make sure SslSocketFactory's are used. For my current design that about does it. The proper Brokers and plugins (JaasAuthenticationBroker and AuthorizationPlugin) would have to be used and the configuration files would need to use the DN as the username. I'm not sure about this, but I think if we were to attach the complete certificate and try to do things properly we'd need a new CertificateAuthenticationBroker and a way for JAAS to authenticate that certificate (I'm new to JAAS so I don't know how easy/hard this would be). Sounds spot on! The JAAS part would totally depend on how the JAAS module that authenticates against a certificate expects to receive the certificate. Right now our current JAAS login only uses userid/password, that would need to change for a cert. Anybody know where we can get a JAAS module that authenticates certificates? Regards, Hiram Any thoughts? - Sepand On 8/1/06, James Strachan [EMAIL PROTECTED] wrote: On 8/1/06, ngcutura [EMAIL PROTECTED] wrote: My JIRA username is 'ngcutura' and I'll be glad to assign LDAP Authorization issue to myself. Great! You're all set now with JIRA karma I also take this opportunity to remind you of my code waiting for your review. :-) Thanks for the reminder - will try get there soon :) I wouldn't mind creating and assigning certificate login but as Sepand was the first to raise it I'd wait for him (a while). Coolio -- James --- http://radio.weblogs.com/0112098/ -- Regards, Hiram Blog: http://hiramchirino.com -- Cheers, Guillaume Nodet
Re: Creating a secure connection system and using JMSXUserID support
On Aug 2, 2006, at 4:35 PM, Sepand M wrote: Ok. So from what I've read, we're trying to separate the authorization part from the SSL socket and let the broker handle it. This sounds great. It would take more work (not so great since I have a deadline), but it would be a proper solution. From what I know of JAAS, the subject/principals fully represent identity. So attaching them to Connection info would be a good idea. That way, the Transport's job would be to authenticate and the Broker could handle authorization completely. This would also mean that any communication system could be used without having to change the Broker (as long as the Transport can authenticate and create proper subjet/principals). The one thing I will note is that we are changing the ActiveMQ architecture in that currently, the Brokers are doing both authentication and authorization (e.g. The Brokers are currently doing the user name and password validation). I think, however, that this is necessary because without our change, there would need to be a new broker for every new, authenticated, communication system. Please tell me if you agree (in which case I'll start looking at implementation details). I thought about this some more and wonder if it would be appropriate to consider using the full corba csiv2 framework or a reasonable facsimile. I think it would. Very briefly here is what it gives you: -both ends of the communication channel have policies specifying what they can provide and require for security: they negotiate a common policy. The policy can specify: - security level of channel (basically unprotected or ssl) - validation of identity of server and client, by user/pw or certificate chain - validation of identity of user by a variety of mechanisms including user/pw, cert chain, and trusting the client. Perhaps the most important point here is that the identity of the user and the client may not be the same: this would typically be the case when the client is a broker forwarding messages it got from somewhere else. Here the ssl connection with client certificates would be used to establish the identity of both brokers but the user who originated the message would also be communicated and used in authorization decisions. In other situations where the message sender is a single-user client the client certificate can be used to establish the identity of both the client and user. thanks david jencks On 8/2/06, David Jencks [EMAIL PROTECTED] wrote: I'm confused by the descriptions of this approach, and don't understand what is being proposed. I would separate the steps of 1. validating the client certificate based on the presented certificate chain, which in my experience can be done by the standard truststore implementation that comes with java, and serves to identify the client: this is done during the ssl connection setup and 2. deciding if the identified client is someone you want to let into the system, which can be done with a JAAS login module that accepts either a certificate chain callback handler (probably way overkill), the client certificate (possibly overkill, we've already verified the validity of the chain), or just the DN. Keeping the DN in LDAP should be no problem, perhaps mapped to the principals you want the user to have: I think this could be done after the ssl connection is set up and 3. deciding what permissions the logged in user should get. You might want to consider using a JACC like approach: I set up something like this for portal permissions in jetspeed2 and suspect something similar ought to work for amq. many thanks david jencks On Aug 2, 2006, at 12:20 PM, Hiram Chirino wrote: Hi, On 8/2/06, ngcutura [EMAIL PROTECTED] wrote: Hmmm... It didn't cross my mind but yes, indeed, it is possible. We may supply a fake truststore that would return 'true' for any certificate submitted for authentication and then perform real authentication after connection setup. We would then be able to obtain client certificate exactly as you stated. If we accept this approach, I see three components to implement: 1. Fake truststore 2. CertificateLoginModule (against LDAP) 3. Tweak connection setup to ask for peer certificates. In 3. we actually need some kind of policy reagarding authenitcation. Although SSL connection is established, a client may still supply username/password meaning that it should be used for login. I guess that obtaining client certificate from SSL session should be the last option. In 'Certificate login' thread I described another approach: We may use SSL without client authentication but find a way to export certificate to a String (on client side) and then supply that string as 'username' in createConnection(). On server side, the String would be converted back to certificate and authenticated. With this approach, we need to agree on the string format and conversion discipline and
Re: Creating a secure connection system and using JMSXUserID support
On Aug 3, 2006, at 3:35 AM, ngcutura wrote: I agree with this, I only think it will be a tough job. I also have a deadline, so I suggest that we split the work. I may take custom truststore and certificate authentication against LDAP (I already have idea how to do it) but I am open to suggestions. I still don't understand why you would want to use a fake truststore. I would expect that you would want to use the standard mechanisms to validate the supplied client cert chain, so you know by the time the connection is set up the client has supplied a valid cert chain, and then use a JAAS login module to decide if the identified user is someone you want to let into the system. I think that you will need a variety of approaches in the security broker filter to extract the necessary info from the environment (including the SSLSession and ConnectionInfo) and feed it into JAAS. thanks david jencks Regards, NGC Sepand M wrote: Ok. So from what I've read, we're trying to separate the authorization part from the SSL socket and let the broker handle it. This sounds great. It would take more work (not so great since I have a deadline), but it would be a proper solution. From what I know of JAAS, the subject/principals fully represent identity. So attaching them to Connection info would be a good idea. That way, the Transport's job would be to authenticate and the Broker could handle authorization completely. This would also mean that any communication system could be used without having to change the Broker (as long as the Transport can authenticate and create proper subjet/principals). The one thing I will note is that we are changing the ActiveMQ architecture in that currently, the Brokers are doing both authentication and authorization (e.g. The Brokers are currently doing the user name and password validation). I think, however, that this is necessary because without our change, there would need to be a new broker for every new, authenticated, communication system. Please tell me if you agree (in which case I'll start looking at implementation details). On 8/2/06, David Jencks [EMAIL PROTECTED] wrote: I'm confused by the descriptions of this approach, and don't understand what is being proposed. I would separate the steps of 1. validating the client certificate based on the presented certificate chain, which in my experience can be done by the standard truststore implementation that comes with java, and serves to identify the client: this is done during the ssl connection setup and 2. deciding if the identified client is someone you want to let into the system, which can be done with a JAAS login module that accepts either a certificate chain callback handler (probably way overkill), the client certificate (possibly overkill, we've already verified the validity of the chain), or just the DN. Keeping the DN in LDAP should be no problem, perhaps mapped to the principals you want the user to have: I think this could be done after the ssl connection is set up and 3. deciding what permissions the logged in user should get. You might want to consider using a JACC like approach: I set up something like this for portal permissions in jetspeed2 and suspect something similar ought to work for amq. many thanks david jencks On Aug 2, 2006, at 12:20 PM, Hiram Chirino wrote: Hi, On 8/2/06, ngcutura [EMAIL PROTECTED] wrote: Hmmm... It didn't cross my mind but yes, indeed, it is possible. We may supply a fake truststore that would return 'true' for any certificate submitted for authentication and then perform real authentication after connection setup. We would then be able to obtain client certificate exactly as you stated. If we accept this approach, I see three components to implement: 1. Fake truststore 2. CertificateLoginModule (against LDAP) 3. Tweak connection setup to ask for peer certificates. In 3. we actually need some kind of policy reagarding authenitcation. Although SSL connection is established, a client may still supply username/password meaning that it should be used for login. I guess that obtaining client certificate from SSL session should be the last option. In 'Certificate login' thread I described another approach: We may use SSL without client authentication but find a way to export certificate to a String (on client side) and then supply that string as 'username' in createConnection(). On server side, the String would be converted back to certificate and authenticated. With this approach, we need to agree on the string format and conversion discipline and then only another JAAS login module is required (that would actually perform coversion from String to Certificate and authenticate). Thus no change is required in existing code. We may even add another non-portable createConnection(Certificate, brokerURL) that would convert Certificate to String and invoke createConnection(username, password, brokerURL). So,
[jira] Created: (AMQ-860) include javadocs inside the binary distro build
include javadocs inside the binary distro build --- Key: AMQ-860 URL: https://issues.apache.org/activemq/browse/AMQ-860 Project: ActiveMQ Issue Type: Improvement Reporter: james strachan -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (AMQ-859) nightly snapshots to include source distro
nightly snapshots to include source distro -- Key: AMQ-859 URL: https://issues.apache.org/activemq/browse/AMQ-859 Project: ActiveMQ Issue Type: Improvement Reporter: james strachan Assigned To: Fritz Oconer -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Creating a secure connection system and using JMSXUserID support
On 8/2/06, David Jencks [EMAIL PROTECTED] wrote: I'm confused by the descriptions of this approach, and don't understand what is being proposed. I would separate the steps of 1. validating the client certificate based on the presented certificate chain, which in my experience can be done by the standard truststore implementation that comes with java, and serves to identify the client: this is done during the ssl connection setup So are you saying that the SSL layer will accept a client cert as long as it's signed by one of the certs in the trust store? and 2. deciding if the identified client is someone you want to let into the system, which can be done with a JAAS login module that accepts either a certificate chain callback handler (probably way overkill), the client certificate (possibly overkill, we've already verified the validity of the chain), or just the DN. Keeping the DN in LDAP should be no problem, perhaps mapped to the principals you want the user to have: I think this could be done after the ssl connection is set up Verifying against the DN does seem to be the simplest route and I think we just need a simple first implementation. and 3. deciding what permissions the logged in user should get. You might want to consider using a JACC like approach: I set up something like this for portal permissions in jetspeed2 and suspect something similar ought to work for amq. We allready have a plugable authorization strategy in amq I don't see this as being that hard part in this discussion. many thanks david jencks On Aug 2, 2006, at 12:20 PM, Hiram Chirino wrote: Hi, On 8/2/06, ngcutura [EMAIL PROTECTED] wrote: Hmmm... It didn't cross my mind but yes, indeed, it is possible. We may supply a fake truststore that would return 'true' for any certificate submitted for authentication and then perform real authentication after connection setup. We would then be able to obtain client certificate exactly as you stated. If we accept this approach, I see three components to implement: 1. Fake truststore 2. CertificateLoginModule (against LDAP) 3. Tweak connection setup to ask for peer certificates. In 3. we actually need some kind of policy reagarding authenitcation. Although SSL connection is established, a client may still supply username/password meaning that it should be used for login. I guess that obtaining client certificate from SSL session should be the last option. In 'Certificate login' thread I described another approach: We may use SSL without client authentication but find a way to export certificate to a String (on client side) and then supply that string as 'username' in createConnection(). On server side, the String would be converted back to certificate and authenticated. With this approach, we need to agree on the string format and conversion discipline and then only another JAAS login module is required (that would actually perform coversion from String to Certificate and authenticate). Thus no change is required in existing code. We may even add another non-portable createConnection(Certificate, brokerURL) that would convert Certificate to String and invoke createConnection(username, password, brokerURL). So, the necessary modules to implement would be: 1. Utility to convert Certificate to a string and back. 1a. (optional) createConnection(Certificate, brokerURL) method and ActiveMQConnection(Certifcate, brokerURL) constructor that perform conversion from Certificate to String using utility in #1 and invoke appropriate existing meothods/constructors. This sounds fine to me too. I would use the DN as the userId and encode the certificate as a string for the password and add a ActiveMQConnectionFactory.setCertificate( Certificate ) and have that set userid/password. 2. JAAS login module that accepts username (and blank password; or whatever convenient) converts it back to Certificate using utility in #1 and authenticates it. Yep, sounds good to me. BTW, how easy is it to get Certificate instance? Is this susceptible to spoofing? I didn't like this approach at first but now it seems the quickiest (and the dirtiest) solution. Actually, it is developing a new protocol on exisitng facilities. Any thoughts? Regards, NGC Hiram Chirino wrote: I guess I don't understand what you mean by #2 but that could be due to my ignorance of the SSL socket stuff. So perhaps you can help me understand what happens there... Lets assume we setup the ssl stuff to use 'need client auth'. Could we setup a truststore implementation that accepts any client certificate or would this be a problem? Can you later get use the SSLScoket.getSession ().getPeerCertificates() when the ConnectionInfo command comes in and attach those certificates to the command? Could that Certificate[] later be used against an LDAP JAAS module? Regards, Hiram On 8/2/06, ngcutura [EMAIL
Re: [VOTE] Release Apache ActiveMQ 4.0.2 (RC 2)
Hi Hiram, Is the NOTICE file correct? I believe you need a NOTICE for derby, at least. Also, the shell scripts in /bin are not marked executable when I untar the tar distribution... --kevan On Aug 1, 2006, at 1:47 PM, Hiram Chirino wrote: Some LICENSE file issues were found in the first release candidate of the 4.0.2 build. I have cut and RC 2 of the 4.0.2 build with the fixes and it's available here: http://people.apache.org/~chirino/incubator-activemq-4.0.2-RC2/ maven1/incubator-activemq/distributions/ Maven 1 and Maven 2 repos for this release can be found at: http://people.apache.org/~chirino/incubator-activemq-4.0.2-RC2 Here's the wiki page for the release notes (they should soon get mirrored to the activemq static website) : http://goopen.org/confluence/display/ACTIVEMQ/ActiveMQ+4.0.2+Release Please vote to approve this release binary [ ] +1 Release the binary as Apache ActiveMQ 4.0.2 [ ] -1 Veto the release (provide specific comments) If this vote passes, then we will then ask the Incubator PMC for their blessing to ship this release officially. Here's my +1 -- Regards, Hiram Blog: http://hiramchirino.com
Re: Creating a secure connection system and using JMSXUserID support
On 8/3/06, David Jencks [EMAIL PROTECTED] wrote: On Aug 2, 2006, at 4:35 PM, Sepand M wrote: Ok. So from what I've read, we're trying to separate the authorization part from the SSL socket and let the broker handle it. This sounds great. It would take more work (not so great since I have a deadline), but it would be a proper solution. From what I know of JAAS, the subject/principals fully represent identity. So attaching them to Connection info would be a good idea. That way, the Transport's job would be to authenticate and the Broker could handle authorization completely. This would also mean that any communication system could be used without having to change the Broker (as long as the Transport can authenticate and create proper subjet/principals). The one thing I will note is that we are changing the ActiveMQ architecture in that currently, the Brokers are doing both authentication and authorization (e.g. The Brokers are currently doing the user name and password validation). I think, however, that this is necessary because without our change, there would need to be a new broker for every new, authenticated, communication system. Please tell me if you agree (in which case I'll start looking at implementation details). I thought about this some more and wonder if it would be appropriate to consider using the full corba csiv2 framework or a reasonable facsimile. I think it would. Very briefly here is what it gives you: -both ends of the communication channel have policies specifying what they can provide and require for security: they negotiate a common policy. The policy can specify: - security level of channel (basically unprotected or ssl) - validation of identity of server and client, by user/pw or certificate chain - validation of identity of user by a variety of mechanisms including user/pw, cert chain, and trusting the client. Perhaps the most important point here is that the identity of the user and the client may not be the same: this would typically be the case when the client is a broker forwarding messages it got from somewhere else. Here the ssl connection with client certificates would be used to establish the identity of both brokers but the user who originated the message would also be communicated and used in authorization decisions. Seem like a bit of overkill but the whole separating the identity of the user from the identity of the connection bit is interesting. Could something similar be accomplished if each message was signed by the user before it was sent into the messaging system? In other situations where the message sender is a single-user client the client certificate can be used to establish the identity of both the client and user. thanks david jencks -- Regards, Hiram Blog: http://hiramchirino.com
Re: [VOTE] Release Apache ActiveMQ 4.0.2 (RC 2)
Hi Kevan, I wish you would have checked the notice file before I recut the release again. lol! Do you know what needs to be included in the NOTICE for derby? Regards, Hiram On 8/3/06, Kevan Miller [EMAIL PROTECTED] wrote: Hi Hiram, Is the NOTICE file correct? I believe you need a NOTICE for derby, at least. Also, the shell scripts in /bin are not marked executable when I untar the tar distribution... --kevan On Aug 1, 2006, at 1:47 PM, Hiram Chirino wrote: Some LICENSE file issues were found in the first release candidate of the 4.0.2 build. I have cut and RC 2 of the 4.0.2 build with the fixes and it's available here: http://people.apache.org/~chirino/incubator-activemq-4.0.2-RC2/ maven1/incubator-activemq/distributions/ Maven 1 and Maven 2 repos for this release can be found at: http://people.apache.org/~chirino/incubator-activemq-4.0.2-RC2 Here's the wiki page for the release notes (they should soon get mirrored to the activemq static website) : http://goopen.org/confluence/display/ACTIVEMQ/ActiveMQ+4.0.2+Release Please vote to approve this release binary [ ] +1 Release the binary as Apache ActiveMQ 4.0.2 [ ] -1 Veto the release (provide specific comments) If this vote passes, then we will then ask the Incubator PMC for their blessing to ship this release officially. Here's my +1 -- Regards, Hiram Blog: http://hiramchirino.com -- Regards, Hiram Blog: http://hiramchirino.com
Re: Is there a good reason for having a static Executor for Sessions shared across all Connections?
OK - thought so. Figured we could keep the singleton, but reference count the connections so that when no more connections are open we close down the threadpool. (e.g. so we don't leave threads around after undeploying a WAR). On 8/3/06, Hiram Chirino [EMAIL PROTECTED] wrote: Yeah the idea was it acts as a thread pool. I'm not sure why you would want multiple thread pools. Also if you are in use case where you want to avoid the context switches, there is a System property you can use which causes thread pooling to be disabled and dedicated threads are assigned to each task. Regards, Hiram On 8/3/06, James Strachan [EMAIL PROTECTED] wrote: I'm just investigating a Lingo test case (LINGO-22) submitted by Jim Beattie which tests that we leave no threads around after shutting down lingo ActiveMQ - which sounds good to me. I've noticed that the Executor for all connections is a static and shared across connections. I was gonna make it so that after all connections are closed all threads are cleanly shutdown - I've a refactor of Jim's test case to test for this. I just wondered before I go ahead and change things - was there a good reason to keep the TaskRunnerFactory / Executor a singleton? I was thinking of creating one per connection. Failing that we could keep it a singleton and just reference count the connections so we can close it when the last connection goes away Am wondering if this was an optimisation to minimise context switching when using lots of sessions - or is it just an oversight? -- James --- http://radio.weblogs.com/0112098/ -- Regards, Hiram Blog: http://hiramchirino.com -- James --- http://radio.weblogs.com/0112098/
Re: Creating a secure connection system and using JMSXUserID support
Hi guys, Here are a few things: 1) I cannot use LDAP. We don't use it now, and don't want to later. I understand if you want to use it, but I can't. 2) From what I understand (and my understanding isn't too bad at this point), SSL sockets with needClientAuth just verify the client's cert against the CA. This means that the socket only does authentication and the rest is up to the broker (which seems perfect). 3) The other ideas we're getting like separating the user from the connection (which I don't fully understand) seem like they are overkill. To be done properly, they would need significant (not drastic, but significant) architectural rework (look at things like UserIDBroker, and how the user ID is currently obtained from the connection with the producer ID registration stuff) and are fairly independent of the SSL thing. So here's my plan: I want to implement my original idea (it's in this thread a few posts up) with (at most) the addition of a subject/principal back end for authorization. I say at most because I've been working on my idea for a while and know exactly how to do it; adding the subject/principal thing is a good design choice but I'm hesitant to persue it since I don't know much about it and I have a deadline (and therefore, would rather avoid having to read about it). If someone knows their stuff regarding to JAAS and is willing to work on it, I would be very glad to incorporate that into the design. If not, I must begin working on my implementation by the end of the week (hopefully sooner). I would *REALLY* like to work with you guys, but I have deadlines to meet. I would also hate it if my work didn't make it into the project's main branch, but I would totally understand if you decided to go with your own ideas. On 8/3/06, Hiram Chirino [EMAIL PROTECTED] wrote: On 8/3/06, David Jencks [EMAIL PROTECTED] wrote: On Aug 2, 2006, at 4:35 PM, Sepand M wrote: Ok. So from what I've read, we're trying to separate the authorization part from the SSL socket and let the broker handle it. This sounds great. It would take more work (not so great since I have a deadline), but it would be a proper solution. From what I know of JAAS, the subject/principals fully represent identity. So attaching them to Connection info would be a good idea. That way, the Transport's job would be to authenticate and the Broker could handle authorization completely. This would also mean that any communication system could be used without having to change the Broker (as long as the Transport can authenticate and create proper subjet/principals). The one thing I will note is that we are changing the ActiveMQ architecture in that currently, the Brokers are doing both authentication and authorization (e.g. The Brokers are currently doing the user name and password validation). I think, however, that this is necessary because without our change, there would need to be a new broker for every new, authenticated, communication system. Please tell me if you agree (in which case I'll start looking at implementation details). I thought about this some more and wonder if it would be appropriate to consider using the full corba csiv2 framework or a reasonable facsimile. I think it would. Very briefly here is what it gives you: -both ends of the communication channel have policies specifying what they can provide and require for security: they negotiate a common policy. The policy can specify: - security level of channel (basically unprotected or ssl) - validation of identity of server and client, by user/pw or certificate chain - validation of identity of user by a variety of mechanisms including user/pw, cert chain, and trusting the client. Perhaps the most important point here is that the identity of the user and the client may not be the same: this would typically be the case when the client is a broker forwarding messages it got from somewhere else. Here the ssl connection with client certificates would be used to establish the identity of both brokers but the user who originated the message would also be communicated and used in authorization decisions. Seem like a bit of overkill but the whole separating the identity of the user from the identity of the connection bit is interesting. Could something similar be accomplished if each message was signed by the user before it was sent into the messaging system? In other situations where the message sender is a single-user client the client certificate can be used to establish the identity of both the client and user. thanks david jencks -- Regards, Hiram Blog: http://hiramchirino.com
Re: Creating a secure connection system and using JMSXUserID support
Sepand, Do what you need to to get you project done, you cand send us tidbit as you get it done and we can work on merging it back to the main branch. The great thing is that you have a use case that we want to support, so if you put something together that work for you, I don't see why it would not just go whole hog into the main branch. On 8/3/06, Sepand M [EMAIL PROTECTED] wrote: Hi guys, Here are a few things: 1) I cannot use LDAP. We don't use it now, and don't want to later. I understand if you want to use it, but I can't. 2) From what I understand (and my understanding isn't too bad at this point), SSL sockets with needClientAuth just verify the client's cert against the CA. This means that the socket only does authentication and the rest is up to the broker (which seems perfect). 3) The other ideas we're getting like separating the user from the connection (which I don't fully understand) seem like they are overkill. To be done properly, they would need significant (not drastic, but significant) architectural rework (look at things like UserIDBroker, and how the user ID is currently obtained from the connection with the producer ID registration stuff) and are fairly independent of the SSL thing. Yeah I think this is overkill too. So here's my plan: I want to implement my original idea (it's in this thread a few posts up) with (at most) the addition of a subject/principal back end for authorization. I say at most because I've been working on my idea for a while and know exactly how to do it; adding the subject/principal thing is a good design choice but I'm hesitant to persue it since I don't know much about it and I have a deadline (and therefore, would rather avoid having to read about it). If someone knows their stuff regarding to JAAS and is willing to work on it, I would be very glad to incorporate that into the design. If not, I must begin working on my implementation by the end of the week (hopefully sooner). I would *REALLY* like to work with you guys, but I have deadlines to meet. I would also hate it if my work didn't make it into the project's main branch, but I would totally understand if you decided to go with your own ideas. On 8/3/06, Hiram Chirino [EMAIL PROTECTED] wrote: On 8/3/06, David Jencks [EMAIL PROTECTED] wrote: On Aug 2, 2006, at 4:35 PM, Sepand M wrote: Ok. So from what I've read, we're trying to separate the authorization part from the SSL socket and let the broker handle it. This sounds great. It would take more work (not so great since I have a deadline), but it would be a proper solution. From what I know of JAAS, the subject/principals fully represent identity. So attaching them to Connection info would be a good idea. That way, the Transport's job would be to authenticate and the Broker could handle authorization completely. This would also mean that any communication system could be used without having to change the Broker (as long as the Transport can authenticate and create proper subjet/principals). The one thing I will note is that we are changing the ActiveMQ architecture in that currently, the Brokers are doing both authentication and authorization (e.g. The Brokers are currently doing the user name and password validation). I think, however, that this is necessary because without our change, there would need to be a new broker for every new, authenticated, communication system. Please tell me if you agree (in which case I'll start looking at implementation details). I thought about this some more and wonder if it would be appropriate to consider using the full corba csiv2 framework or a reasonable facsimile. I think it would. Very briefly here is what it gives you: -both ends of the communication channel have policies specifying what they can provide and require for security: they negotiate a common policy. The policy can specify: - security level of channel (basically unprotected or ssl) - validation of identity of server and client, by user/pw or certificate chain - validation of identity of user by a variety of mechanisms including user/pw, cert chain, and trusting the client. Perhaps the most important point here is that the identity of the user and the client may not be the same: this would typically be the case when the client is a broker forwarding messages it got from somewhere else. Here the ssl connection with client certificates would be used to establish the identity of both brokers but the user who originated the message would also be communicated and used in authorization decisions. Seem like a bit of overkill but the whole separating the identity of the user from the identity of the connection bit is interesting. Could something similar be accomplished if each message was signed by the user before it was sent into the messaging system? In other situations where the message sender is a
Re: Is there a good reason for having a static Executor for Sessions shared across all Connections?
Sounds good to me. On 8/3/06, James Strachan [EMAIL PROTECTED] wrote: OK - thought so. Figured we could keep the singleton, but reference count the connections so that when no more connections are open we close down the threadpool. (e.g. so we don't leave threads around after undeploying a WAR). On 8/3/06, Hiram Chirino [EMAIL PROTECTED] wrote: Yeah the idea was it acts as a thread pool. I'm not sure why you would want multiple thread pools. Also if you are in use case where you want to avoid the context switches, there is a System property you can use which causes thread pooling to be disabled and dedicated threads are assigned to each task. Regards, Hiram On 8/3/06, James Strachan [EMAIL PROTECTED] wrote: I'm just investigating a Lingo test case (LINGO-22) submitted by Jim Beattie which tests that we leave no threads around after shutting down lingo ActiveMQ - which sounds good to me. I've noticed that the Executor for all connections is a static and shared across connections. I was gonna make it so that after all connections are closed all threads are cleanly shutdown - I've a refactor of Jim's test case to test for this. I just wondered before I go ahead and change things - was there a good reason to keep the TaskRunnerFactory / Executor a singleton? I was thinking of creating one per connection. Failing that we could keep it a singleton and just reference count the connections so we can close it when the last connection goes away Am wondering if this was an optimisation to minimise context switching when using lots of sessions - or is it just an oversight? -- James --- http://radio.weblogs.com/0112098/ -- Regards, Hiram Blog: http://hiramchirino.com -- James --- http://radio.weblogs.com/0112098/ -- Regards, Hiram Blog: http://hiramchirino.com
Re: [VOTE] Release Apache ActiveMQ 4.0.2 (RC 2)
On Aug 3, 2006, at 12:10 PM, Hiram Chirino wrote: Hi Kevan, I wish you would have checked the notice file before I recut the release again. lol! Do you know what needs to be included in the NOTICE for derby? Yeah. It's lol in a painful sort of way. ;-) My apologies. IIRC you posted the new LICENSE file. I should have asked about the NOTICE, also. You should check the mx4j license. Geronimo has an mx4j notice in their NOTICE file. Not sure if it's needed... Here's the NOTICE file from the Derby 10.1.1.0 distribution: = == NOTICE file corresponding to section 4(d) of the Apache License, == == Version 2.0, in this case for the Apache Derby distribution. == = This product includes software developed by The Apache Software Foundation (http://www.apache.org/). Portions of Derby were orginally developed by International Business Machines Corporation and are licensed to the Apache Software Foundation under the Software Grant and Corporate Contribution License Agreement, informally known as the Derby CLA. The portion of the functionTests under 'nist' was originally developed by the National Institute of Standards and Technology (NIST), an agency of the United States Department of Commerce, and adapted by International Business Machines Corporation in accordance with the NIST Software Acknowledgment and Redistribution document at http://www.itl.nist.gov/div897/ctg/sql_form.htm --kevan Regards, Hiram On 8/3/06, Kevan Miller [EMAIL PROTECTED] wrote: Hi Hiram, Is the NOTICE file correct? I believe you need a NOTICE for derby, at least. Also, the shell scripts in /bin are not marked executable when I untar the tar distribution... --kevan On Aug 1, 2006, at 1:47 PM, Hiram Chirino wrote: Some LICENSE file issues were found in the first release candidate of the 4.0.2 build. I have cut and RC 2 of the 4.0.2 build with the fixes and it's available here: http://people.apache.org/~chirino/incubator-activemq-4.0.2-RC2/ maven1/incubator-activemq/distributions/ Maven 1 and Maven 2 repos for this release can be found at: http://people.apache.org/~chirino/incubator-activemq-4.0.2-RC2 Here's the wiki page for the release notes (they should soon get mirrored to the activemq static website) : http://goopen.org/confluence/display/ACTIVEMQ/ActiveMQ+4.0.2 +Release Please vote to approve this release binary [ ] +1 Release the binary as Apache ActiveMQ 4.0.2 [ ] -1 Veto the release (provide specific comments) If this vote passes, then we will then ask the Incubator PMC for their blessing to ship this release officially. Here's my +1 -- Regards, Hiram Blog: http://hiramchirino.com -- Regards, Hiram Blog: http://hiramchirino.com
[jira] Created: (AMQ-861) Kaha DB files are not removed
Kaha DB files are not removed - Key: AMQ-861 URL: https://issues.apache.org/activemq/browse/AMQ-861 Project: ActiveMQ Issue Type: Bug Components: Broker Affects Versions: 4.0.1 Environment: Win XP, Java 5 Reporter: Vadim Pesochinskiy Fix For: 4.1 I have request-response point to point test case, which I ran for 12 hours. Each message is exactly 5KBytes. This is what I see in the Kaha directory: 779 Aug 1 17:03 roots-data1 32M Aug 2 15:28 queue-data4 32M Aug 2 18:02 queue-data5 32M Aug 2 19:03 queue-data6 32M Aug 2 20:04 queue-data7 32M Aug 2 21:05 queue-data8 32M Aug 2 22:07 queue-data9 32M Aug 2 23:08 queue-data10 32M Aug 3 00:09 queue-data11 32M Aug 3 01:10 queue-data12 32M Aug 3 02:12 queue-data13 32M Aug 3 03:13 queue-data14 32M Aug 3 04:19 queue-data15 32M Aug 3 05:20 queue-data16 32M Aug 3 06:21 queue-data17 32M Aug 3 07:22 queue-data18 32M Aug 3 08:23 queue-data19 19M Aug 3 09:25 queue-data20 8.6K Aug 3 09:52 kaha.idx -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Creating a secure connection system and using JMSXUserID support
Thanks Hiram. That sounds great. I guess my last question is: what branch do I work off of? Personally, I would like to build my stuff on a stable release (4.0.1), but I've looked at the svn logs and you guys seem to be pretty active around the stuff I want to change so I'm not sure how my changes could be reintegrated once I'm done. Any thoughts? On 8/3/06, Hiram Chirino [EMAIL PROTECTED] wrote: Sepand, Do what you need to to get you project done, you cand send us tidbit as you get it done and we can work on merging it back to the main branch. The great thing is that you have a use case that we want to support, so if you put something together that work for you, I don't see why it would not just go whole hog into the main branch. On 8/3/06, Sepand M [EMAIL PROTECTED] wrote: Hi guys, Here are a few things: 1) I cannot use LDAP. We don't use it now, and don't want to later. I understand if you want to use it, but I can't. 2) From what I understand (and my understanding isn't too bad at this point), SSL sockets with needClientAuth just verify the client's cert against the CA. This means that the socket only does authentication and the rest is up to the broker (which seems perfect). 3) The other ideas we're getting like separating the user from the connection (which I don't fully understand) seem like they are overkill. To be done properly, they would need significant (not drastic, but significant) architectural rework (look at things like UserIDBroker, and how the user ID is currently obtained from the connection with the producer ID registration stuff) and are fairly independent of the SSL thing. Yeah I think this is overkill too. So here's my plan: I want to implement my original idea (it's in this thread a few posts up) with (at most) the addition of a subject/principal back end for authorization. I say at most because I've been working on my idea for a while and know exactly how to do it; adding the subject/principal thing is a good design choice but I'm hesitant to persue it since I don't know much about it and I have a deadline (and therefore, would rather avoid having to read about it). If someone knows their stuff regarding to JAAS and is willing to work on it, I would be very glad to incorporate that into the design. If not, I must begin working on my implementation by the end of the week (hopefully sooner). I would *REALLY* like to work with you guys, but I have deadlines to meet. I would also hate it if my work didn't make it into the project's main branch, but I would totally understand if you decided to go with your own ideas. On 8/3/06, Hiram Chirino [EMAIL PROTECTED] wrote: On 8/3/06, David Jencks [EMAIL PROTECTED] wrote: On Aug 2, 2006, at 4:35 PM, Sepand M wrote: Ok. So from what I've read, we're trying to separate the authorization part from the SSL socket and let the broker handle it. This sounds great. It would take more work (not so great since I have a deadline), but it would be a proper solution. From what I know of JAAS, the subject/principals fully represent identity. So attaching them to Connection info would be a good idea. That way, the Transport's job would be to authenticate and the Broker could handle authorization completely. This would also mean that any communication system could be used without having to change the Broker (as long as the Transport can authenticate and create proper subjet/principals). The one thing I will note is that we are changing the ActiveMQ architecture in that currently, the Brokers are doing both authentication and authorization (e.g. The Brokers are currently doing the user name and password validation). I think, however, that this is necessary because without our change, there would need to be a new broker for every new, authenticated, communication system. Please tell me if you agree (in which case I'll start looking at implementation details). I thought about this some more and wonder if it would be appropriate to consider using the full corba csiv2 framework or a reasonable facsimile. I think it would. Very briefly here is what it gives you: -both ends of the communication channel have policies specifying what they can provide and require for security: they negotiate a common policy. The policy can specify: - security level of channel (basically unprotected or ssl) - validation of identity of server and client, by user/pw or certificate chain - validation of identity of user by a variety of mechanisms including user/pw, cert chain, and trusting the client. Perhaps the most important point here is that the identity of the user and the client may not be the same: this would typically be the case when the client is a broker forwarding messages it got from somewhere else. Here the ssl connection with client certificates would be
Re: Creating a secure connection system and using JMSXUserID support
Hi, The DN will overwrite the client-provided username (if any) when the SslTransport writes it. On 8/3/06, Kelly Campbell [EMAIL PROTECTED] wrote: Sepand, One possible gotcha I haven't heard anyone bring up that we should address is to make sure that someone can't just fake the DN in the username field through a normal login and make the system think it's authenticated with the certificate. -Kelly On 8/3/06, Hiram Chirino [EMAIL PROTECTED] wrote: Hi Sepand, 4.1 and 4.0 branches are not that different yet. If you need your solution for 4.0, go ahead and do it. Chances are we will only apply it only to 4.1 (since this a new feature). On 8/3/06, Sepand M [EMAIL PROTECTED] wrote: Thanks Hiram. That sounds great. I guess my last question is: what branch do I work off of? Personally, I would like to build my stuff on a stable release (4.0.1), but I've looked at the svn logs and you guys seem to be pretty active around the stuff I want to change so I'm not sure how my changes could be reintegrated once I'm done. Any thoughts? On 8/3/06, Hiram Chirino [EMAIL PROTECTED] wrote: Sepand, Do what you need to to get you project done, you cand send us tidbit as you get it done and we can work on merging it back to the main branch. The great thing is that you have a use case that we want to support, so if you put something together that work for you, I don't see why it would not just go whole hog into the main branch. On 8/3/06, Sepand M [EMAIL PROTECTED] wrote: Hi guys, Here are a few things: 1) I cannot use LDAP. We don't use it now, and don't want to later. I understand if you want to use it, but I can't. 2) From what I understand (and my understanding isn't too bad at this point), SSL sockets with needClientAuth just verify the client's cert against the CA. This means that the socket only does authentication and the rest is up to the broker (which seems perfect). 3) The other ideas we're getting like separating the user from the connection (which I don't fully understand) seem like they are overkill. To be done properly, they would need significant (not drastic, but significant) architectural rework (look at things like UserIDBroker, and how the user ID is currently obtained from the connection with the producer ID registration stuff) and are fairly independent of the SSL thing. Yeah I think this is overkill too. So here's my plan: I want to implement my original idea (it's in this thread a few posts up) with (at most) the addition of a subject/principal back end for authorization. I say at most because I've been working on my idea for a while and know exactly how to do it; adding the subject/principal thing is a good design choice but I'm hesitant to persue it since I don't know much about it and I have a deadline (and therefore, would rather avoid having to read about it). If someone knows their stuff regarding to JAAS and is willing to work on it, I would be very glad to incorporate that into the design. If not, I must begin working on my implementation by the end of the week (hopefully sooner). I would *REALLY* like to work with you guys, but I have deadlines to meet. I would also hate it if my work didn't make it into the project's main branch, but I would totally understand if you decided to go with your own ideas. On 8/3/06, Hiram Chirino [EMAIL PROTECTED] wrote: On 8/3/06, David Jencks [EMAIL PROTECTED] wrote: On Aug 2, 2006, at 4:35 PM, Sepand M wrote: Ok. So from what I've read, we're trying to separate the authorization part from the SSL socket and let the broker handle it. This sounds great. It would take more work (not so great since I have a deadline), but it would be a proper solution. From what I know of JAAS, the subject/principals fully represent identity. So attaching them to Connection info would be a good idea. That way, the Transport's job would be to authenticate and the Broker could handle authorization completely. This would also mean that any communication system could be used without having to change the Broker (as long as the Transport can authenticate and create proper subjet/principals). The one thing I will note is that we are changing the ActiveMQ architecture in that currently, the Brokers are doing both authentication and authorization (e.g. The Brokers are currently doing the user name and password validation). I think, however, that this is necessary because without our change, there would need to be a new broker for every new, authenticated, communication system. Please tell me if you agree (in which case I'll start looking at implementation details). I thought
Re: creating a standard JBI Component using servicemix-common module
Have you defined the property M2_REPO in Eclipse ? On 8/3/06, Soumadeep-Infravio [EMAIL PROTECTED] wrote: Resolved it... problem with classpath. It created two eclipse related files 1) .project 2) .classpath The problem is when I import this project into Eclipse it doesn't resolve the classapth. Do I need to do anything else? Thanks Soumadeep - Original Message - From: Guillaume Nodet [EMAIL PROTECTED] To: servicemix-dev@geronimo.apache.org Sent: Thursday, August 03, 2006 3:11 PM Subject: Re: creating a standard JBI Component using servicemix-common module What do you mean by not OK ? On 8/3/06, Soumadeep-Infravio [EMAIL PROTECTED] wrote: Guillaume, I guess I got past this by re-building smx. What I am stuck with now is that eclipse is complaining that the project that was created using the command mvn eclipse:eclipse is not OK. Have you tried doing it lately? Thanks Soumadeep - Original Message - From: Guillaume Nodet [EMAIL PROTECTED] To: servicemix-dev@geronimo.apache.org Sent: Thursday, August 03, 2006 2:40 PM Subject: Re: creating a standard JBI Component using servicemix-common module You can also download the archetype from http://people.apache.org/maven-snapshot-repository/org/apache/servicemix/tooling/servicemix-service-engine/1.0-incubating-SNAPSHOT/servicemix-service-engine-1.0-incubating-20060803.064327-5.jar and put it in your local maven repo under ~/.m2/org/apache/servicemix/tooling/servicemix-service-engine/1.0-incubating-SNAPSHOT It should also work. On 8/3/06, Guillaume Nodet [EMAIL PROTECTED] wrote: We currently have problems uploading snapshots. Even in this case, as they are not on public repositories, I'm not sure it would work. The best way would be to build ServiceMix from sources, as the archetypes will be in your local repository. On 8/3/06, vikas kumar [EMAIL PROTECTED] wrote: Hi Guillaume/All, Tried creating a standard JBI Component using servicemix-common module. I followed the steps written in http://servicemix.org/site/creating-a-standard-jbi-component.html On executing the command mvn archetype:create \ -DarchetypeGroupId=org.apache.servicemix.tooling \ -DarchetypeArtifactId=servicemix-service-engine \ -DarchetypeVersion=1.0-incubating-SNAPSHOT \ -DgroupId=org.apache.servicemix.xslt \ -DartifactId=servicemix-xslt I got the following error: [ERROR] ResourceManager : unable to find resource 'VM_global_library.vm' in any resource loader. [INFO] Velocimacro : error using VM library template VM_global_library.vm : org .apache.velocity.exception.ResourceNotFoundException: Unable to find resource 'V M_global_library.vm' [INFO] Velocimacro : VM library template macro registration complete. [INFO] Velocimacro : allowInline = true : VMs can be defined inline in templates [INFO] Velocimacro : allowInlineToOverride = false : VMs defined inline may NOT replace previous VM definitions [INFO] Velocimacro : allowInlineLocal = false : VMs defined inline will be glob al in scope if allowed. [INFO] Velocimacro : initialization complete. [INFO] Velocity successfully started. [INFO] [archetype:create] [INFO] Defaulting package to group ID: org.apache.servicemix.bam [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Failed to resolve artifact. GroupId: org.apache.servicemix.tooling ArtifactId: servicemix-service-engine Version: 1.0-incubating-SNAPSHOT Reason: Unable to download the artifact from any repository Try downloading the file manually from the project website. Then, install it using the command: mvn install:install-file -DgroupId= org.apache.servicemix.tooling-DartifactI d=servicemix-service-engine \ -Dversion=1.0-incubating-SNAPSHOT -Dpackaging=jar -Dfile=/path/to/file org.apache.servicemix.tooling:servicemix-service-engine:jar:1.0-incubating-SNA PSHOT from the specified remote repositories: central (http://repo1.maven.org/maven2) Any pointers? ~Vikas -- Cheers, Guillaume Nodet -- Cheers, Guillaume Nodet -- Cheers, Guillaume Nodet -- Cheers, Guillaume Nodet
Re: creating a standard JBI Component using servicemix-common module
Yup.. the classpath variable in Eclipse. I am changing the classes to BAMxxx Thanks Soumadeep - Original Message - From: Guillaume Nodet [EMAIL PROTECTED] To: servicemix-dev@geronimo.apache.org Sent: Thursday, August 03, 2006 5:47 PM Subject: Re: creating a standard JBI Component using servicemix-common module Have you defined the property M2_REPO in Eclipse ? On 8/3/06, Soumadeep-Infravio [EMAIL PROTECTED] wrote: Resolved it... problem with classpath. It created two eclipse related files 1) .project 2) .classpath The problem is when I import this project into Eclipse it doesn't resolve the classapth. Do I need to do anything else? Thanks Soumadeep - Original Message - From: Guillaume Nodet [EMAIL PROTECTED] To: servicemix-dev@geronimo.apache.org Sent: Thursday, August 03, 2006 3:11 PM Subject: Re: creating a standard JBI Component using servicemix-common module What do you mean by not OK ? On 8/3/06, Soumadeep-Infravio [EMAIL PROTECTED] wrote: Guillaume, I guess I got past this by re-building smx. What I am stuck with now is that eclipse is complaining that the project that was created using the command mvn eclipse:eclipse is not OK. Have you tried doing it lately? Thanks Soumadeep - Original Message - From: Guillaume Nodet [EMAIL PROTECTED] To: servicemix-dev@geronimo.apache.org Sent: Thursday, August 03, 2006 2:40 PM Subject: Re: creating a standard JBI Component using servicemix-common module You can also download the archetype from http://people.apache.org/maven-snapshot-repository/org/apache/servicemix/tooling/servicemix-service-engine/1.0-incubating-SNAPSHOT/servicemix-service-engine-1.0-incubating-20060803.064327-5.jar and put it in your local maven repo under ~/.m2/org/apache/servicemix/tooling/servicemix-service-engine/1.0-incubating-SNAPSHOT It should also work. On 8/3/06, Guillaume Nodet [EMAIL PROTECTED] wrote: We currently have problems uploading snapshots. Even in this case, as they are not on public repositories, I'm not sure it would work. The best way would be to build ServiceMix from sources, as the archetypes will be in your local repository. On 8/3/06, vikas kumar [EMAIL PROTECTED] wrote: Hi Guillaume/All, Tried creating a standard JBI Component using servicemix-common module. I followed the steps written in http://servicemix.org/site/creating-a-standard-jbi-component.html On executing the command mvn archetype:create \ -DarchetypeGroupId=org.apache.servicemix.tooling \ -DarchetypeArtifactId=servicemix-service-engine \ -DarchetypeVersion=1.0-incubating-SNAPSHOT \ -DgroupId=org.apache.servicemix.xslt \ -DartifactId=servicemix-xslt I got the following error: [ERROR] ResourceManager : unable to find resource 'VM_global_library.vm' in any resource loader. [INFO] Velocimacro : error using VM library template VM_global_library.vm : org .apache.velocity.exception.ResourceNotFoundException: Unable to find resource 'V M_global_library.vm' [INFO] Velocimacro : VM library template macro registration complete. [INFO] Velocimacro : allowInline = true : VMs can be defined inline in templates [INFO] Velocimacro : allowInlineToOverride = false : VMs defined inline may NOT replace previous VM definitions [INFO] Velocimacro : allowInlineLocal = false : VMs defined inline will be glob al in scope if allowed. [INFO] Velocimacro : initialization complete. [INFO] Velocity successfully started. [INFO] [archetype:create] [INFO] Defaulting package to group ID: org.apache.servicemix.bam [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Failed to resolve artifact. GroupId: org.apache.servicemix.tooling ArtifactId: servicemix-service-engine Version: 1.0-incubating-SNAPSHOT Reason: Unable to download the artifact from any repository Try downloading the file manually from the project website. Then, install it using the command: mvn install:install-file -DgroupId= org.apache.servicemix.tooling-DartifactI d=servicemix-service-engine \ -Dversion=1.0-incubating-SNAPSHOT -Dpackaging=jar -Dfile=/path/to/file org.apache.servicemix.tooling:servicemix-service-engine:jar:1.0-incubating-SNA PSHOT from the specified remote repositories: central (http://repo1.maven.org/maven2) Any pointers? ~Vikas -- Cheers, Guillaume Nodet -- Cheers, Guillaume Nodet -- Cheers, Guillaume Nodet -- Cheers, Guillaume Nodet
Re: creating a standard JBI Component using servicemix-common module
Yeah, unfortunately, I don't think this is currently possible with maven archetypes :( Unless someone know a way to generate new files from velocity templates. On 8/3/06, Soumadeep-Infravio [EMAIL PROTECTED] wrote: Not a good idea to refactor the class names, like I said - changing to BAMxxx, I think it's better to change the filenames in the template. The reason is there are a whole lot of xml and xsds which refer to the java classes... your thoughts.. Soumadeep - Original Message - From: Soumadeep-Infravio [EMAIL PROTECTED] To: servicemix-dev@geronimo.apache.org Sent: Thursday, August 03, 2006 6:08 PM Subject: Re: creating a standard JBI Component using servicemix-common module Yup.. the classpath variable in Eclipse. I am changing the classes to BAMxxx Thanks Soumadeep - Original Message - From: Guillaume Nodet [EMAIL PROTECTED] To: servicemix-dev@geronimo.apache.org Sent: Thursday, August 03, 2006 5:47 PM Subject: Re: creating a standard JBI Component using servicemix-common module Have you defined the property M2_REPO in Eclipse ? On 8/3/06, Soumadeep-Infravio [EMAIL PROTECTED] wrote: Resolved it... problem with classpath. It created two eclipse related files 1) .project 2) .classpath The problem is when I import this project into Eclipse it doesn't resolve the classapth. Do I need to do anything else? Thanks Soumadeep - Original Message - From: Guillaume Nodet [EMAIL PROTECTED] To: servicemix-dev@geronimo.apache.org Sent: Thursday, August 03, 2006 3:11 PM Subject: Re: creating a standard JBI Component using servicemix-common module What do you mean by not OK ? On 8/3/06, Soumadeep-Infravio [EMAIL PROTECTED] wrote: Guillaume, I guess I got past this by re-building smx. What I am stuck with now is that eclipse is complaining that the project that was created using the command mvn eclipse:eclipse is not OK. Have you tried doing it lately? Thanks Soumadeep - Original Message - From: Guillaume Nodet [EMAIL PROTECTED] To: servicemix-dev@geronimo.apache.org Sent: Thursday, August 03, 2006 2:40 PM Subject: Re: creating a standard JBI Component using servicemix-common module You can also download the archetype from http://people.apache.org/maven-snapshot-repository/org/apache/servicemix/tooling/servicemix-service-engine/1.0-incubating-SNAPSHOT/servicemix-service-engine-1.0-incubating-20060803.064327-5.jar and put it in your local maven repo under ~/.m2/org/apache/servicemix/tooling/servicemix-service-engine/1.0-incubating-SNAPSHOT It should also work. On 8/3/06, Guillaume Nodet [EMAIL PROTECTED] wrote: We currently have problems uploading snapshots. Even in this case, as they are not on public repositories, I'm not sure it would work. The best way would be to build ServiceMix from sources, as the archetypes will be in your local repository. On 8/3/06, vikas kumar [EMAIL PROTECTED] wrote: Hi Guillaume/All, Tried creating a standard JBI Component using servicemix-common module. I followed the steps written in http://servicemix.org/site/creating-a-standard-jbi-component.html On executing the command mvn archetype:create \ -DarchetypeGroupId=org.apache.servicemix.tooling \ -DarchetypeArtifactId=servicemix-service-engine \ -DarchetypeVersion=1.0-incubating-SNAPSHOT \ -DgroupId=org.apache.servicemix.xslt \ -DartifactId=servicemix-xslt I got the following error: [ERROR] ResourceManager : unable to find resource 'VM_global_library.vm' in any resource loader. [INFO] Velocimacro : error using VM library template VM_global_library.vm : org .apache.velocity.exception.ResourceNotFoundException: Unable to find resource 'V M_global_library.vm' [INFO] Velocimacro : VM library template macro registration complete. [INFO] Velocimacro : allowInline = true : VMs can be defined inline in templates [INFO] Velocimacro : allowInlineToOverride = false : VMs defined inline may NOT replace previous VM definitions [INFO] Velocimacro : allowInlineLocal = false : VMs defined inline will be glob al in scope if allowed. [INFO] Velocimacro : initialization complete. [INFO] Velocity successfully started. [INFO] [archetype:create] [INFO] Defaulting package to group ID: org.apache.servicemix.bam [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Failed to resolve artifact. GroupId: org.apache.servicemix.tooling ArtifactId: servicemix-service-engine Version: 1.0-incubating-SNAPSHOT Reason: Unable to download the artifact from any repository
[jira] Created: (SM-510) The servicemix-jms component should support the ability to set jms message properties
The servicemix-jms component should support the ability to set jms message properties -- Key: SM-510 URL: https://issues.apache.org/activemq/browse/SM-510 Project: ServiceMix Issue Type: Improvement Components: servicemix-jms Affects Versions: 3.0 Reporter: Bruce Snyder Assigned To: Guillaume Nodet The servicemix-jms component should offer the ability to set JMS message properties. This will allow a normalized message to be created that includes an expiration, a CorrelationID, a priority, etc. or even any of the JMSX properties, all of which will be marshalled to the actual JMS message that's sent by the servicemix-jms component. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [VOTE] Release Apache ActiveMQ 4.0.2 (RC 2)
+1 Regards, Alan Hiram Chirino wrote: Some LICENSE file issues were found in the first release candidate of the 4.0.2 build. I have cut and RC 2 of the 4.0.2 build with the fixes and it's available here: http://people.apache.org/~chirino/incubator-activemq-4.0.2-RC2/maven1/incubator-activemq/distributions/ Maven 1 and Maven 2 repos for this release can be found at: http://people.apache.org/~chirino/incubator-activemq-4.0.2-RC2 Here's the wiki page for the release notes (they should soon get mirrored to the activemq static website) : http://goopen.org/confluence/display/ACTIVEMQ/ActiveMQ+4.0.2+Release Please vote to approve this release binary [ ] +1 Release the binary as Apache ActiveMQ 4.0.2 [ ] -1 Veto the release (provide specific comments) If this vote passes, then we will then ask the Incubator PMC for their blessing to ship this release officially. Here's my +1
Re: Current caller subject?
On Aug 2, 2006, at 10:53 PM, Dain Sundstrom wrote: I'm working on the Jencks project again and have discovered that the container managed security and pool partition by-subject doesn't work oustide of Geronimo since both depend on obtaining the current caller's subject from ContextManager.getCurrentCaller(), which is a Geronimo specific class. Is there a spec defined way we could be getting the current caller's subject that would reasonably work in most app servers? I'm hoping there is something in the JACC spec. If not, I think we should introduce a hook under these static calls, so we can redirect them to platform specific APIs when running outside of a Geronimo server. You could use (Subject)PolicyContext.getContext (javax.security.auth.Subject.container); which in geronimo delegates to ContextManager.getCurrentCaller() using a lot of hashmap lookups and security checks. thanks david jencks -dain
Re: [Discussion] Removal of TransactionContextManager
On Jul 31, 2006, at 4:09 PM, Dain Sundstrom wrote: history length=too long About a week ago there was a discussion on the OpenEJB mailing list regarding the TransactionContextManager. In OpenEJB 3 we removed the use of the TCM from Geronimo and replaced it with just a javax.transaction.TransactionManager. This brought all of the openejb containers into alignment. The other big motivation was to ease the integration of OpenEJB and third part libraries, specifically Spring. The problem with the TCM is that if you use it you can't use the TM directly since the TCM needs to know about all TM calls. Additionally, to use the TCM you must demarcate all changes in component context by starting an unspecified transaction context. This is all quite invasive and made OpenEJB hard to use in Spring or plain old Tomcat. That was all fine and good for OpenEJB 3, but as it turns out there is a desire to keep the OpenEJB 2 and 3 code aligned as much as possible, so a discussion started around how to backport the changes to 2. We determined there were two options: 1) wrap the TCM with a class that implements TM but delegates to the TCM - this would be tricky to get working and there is always the problem of demarcating the unspecified transaction context 2) remove the TCM from Geronimo entirely - this could be a lot of work After a quick look at the first option, I decided to try option two. It turned out to be a lot easier than I thought since, the biggest user of TCM was OpenEJB and I had already pulled it out of OpenEJB. I also think I have become the master of using the IntelliJ refactor tools and was able to remove the code without too much hand tweaking. /history I have checked the fruits of this effort into https:// svn.apache.org/repos/asf/geronimo/branches/dain/notcm and there is a matching OpenEJB branch that is checked out with maven m:co. I have not updated the m2 build yet, as it was finalized during this work. For those of you that are following the Jencks project, which wraps the Geronimo transaction and connector modules with Spring bean factories, I have created a branch there also, which contains a massive simplification due to the refactors in the removal of the Geronimo TCM. Here are some fun examples from that project: http://fisheye.codehaus.org/browse/jencks/branches/notcm/src/test/ resources/org/jencks/samples/outbound/jencks-tranql.xml?r=112 http://fisheye.codehaus.org/browse/jencks/branches/notcm/src/test/ resources/org/jencks/spring-request-reply-jta.xml?r=112 So what does everyone think about removing the TCM in general? After that I think we may want to discuss the specifics of my branch. I may have gotten too refactory happy :) Details on the specific changes I made follow: TransactionContextManager - Removed TransactionContextManager and replaced all uses with a plain old TransactionManager Removed all code from web containers, app client and timer that was simply demarcating an unspecified transaction context, which is no longer needed TransactionManager -- Merged XATerminator portion of TCM into GeronimoTransactionManager which is a subclass of TransactionManagerImpl Improved tx thread association code so we can throw an error if someone attempts to resume a tx associated with another thread Added TransactionManagerMonitor which is used by the connection tracker to know when a transaction context has changed UserTransaction --- TransactionManagerImpl now implements UserTransaction to ease integration with third party libraries such as Spring Why is this a good idea? This strikes me as a bad idea since a user can successfully cast UserTransaction to TransactionManager. Removed OnlineUserTransaction since it was only really used by OpenEJB and it has it's own UserTransaction implementation Web containers now use GeronimoUserTransaction which is an always on wrapper around a transaction manager Third party support --- Moved use of ServerInfo from HOWLLog to HOWLLogGBean so it can be more easily use by third party libraries Moved connector related transaction data to connector module I guess considering the number of threadlocal accesses and hashmap lookups in this code possibly adding one more isn't going to cause problems. How do you associate the data with the transaction? Replace use of Geronimo's thread pool with a concurrent executor Is this java 5 only? If so how is our retrotranslator testing going? Having just read the concurrency in practice book I'm eager to move to java 5 now :-) thanks david jencks -dain
[jira] Created: (GERONIMO-2267) RepeatedFailureLockoutLoginModule: Does not function
RepeatedFailureLockoutLoginModule: Does not function Key: GERONIMO-2267 URL: http://issues.apache.org/jira/browse/GERONIMO-2267 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Components: security Affects Versions: 1.1, 1.1.1, 1.1.2, 1.1.x, 1.2 Environment: Win XP, G1.1.1-SNAPSHOT, Tomcat Reporter: Vamsavardhana Reddy Fix For: 1.1.2, 1.1.x, 1.2 I have created a security realm enabled for lockout after repeated failures. But the feature does not seem to work. I observed that RepeatedFailureLockoutLoginModule.login() is never invoked when a login attempt fails!!! -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (GERONIMO-2268) Security Realm with more than one LoginModule does not function as expected
Security Realm with more than one LoginModule does not function as expected --- Key: GERONIMO-2268 URL: http://issues.apache.org/jira/browse/GERONIMO-2268 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Components: security Affects Versions: 1.1, 1.1.1, 1.1.x Environment: Win XP, G1.1.1-SNAPSHOT, Tomact Reporter: Vamsavardhana Reddy Fix For: 1.1.x, 1.2 I have created a security realm consisting two login modules. I have set the control-flag as REQUIRED on both the login modules. The second login module is supposed to be invoked whether or not the first one succeeds. But the second login module is not invoked when the first one fails. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [VOTE] Release Apache ActiveMQ 4.0.2 (RC 2)
+1 On 8/1/06, Hiram Chirino [EMAIL PROTECTED] wrote: Some LICENSE file issues were found in the first release candidate of the 4.0.2 build. I have cut and RC 2 of the 4.0.2 build with the fixes and it's available here: http://people.apache.org/~chirino/incubator-activemq-4.0.2-RC2/maven1/incubator-activemq/distributions/ Maven 1 and Maven 2 repos for this release can be found at: http://people.apache.org/~chirino/incubator-activemq-4.0.2-RC2 Here's the wiki page for the release notes (they should soon get mirrored to the activemq static website) : http://goopen.org/confluence/display/ACTIVEMQ/ActiveMQ+4.0.2+Release Please vote to approve this release binary [ ] +1 Release the binary as Apache ActiveMQ 4.0.2 [ ] -1 Veto the release (provide specific comments) If this vote passes, then we will then ask the Incubator PMC for their blessing to ship this release officially. Here's my +1 -- Regards, Hiram Blog: http://hiramchirino.com -- Cheers, Guillaume Nodet
creating a standard JBI Component using servicemix-common module
Hi Guillaume/All, Tried creating a standard JBI Component using servicemix-common module. I followed the steps written in http://servicemix.org/site/creating-a-standard-jbi-component.html On executing the command mvn archetype:create \ -DarchetypeGroupId=org.apache.servicemix.tooling \ -DarchetypeArtifactId=servicemix-service-engine \ -DarchetypeVersion=1.0-incubating-SNAPSHOT \ -DgroupId=org.apache.servicemix.xslt \ -DartifactId=servicemix-xslt I got the following error: [ERROR] ResourceManager : unable to find resource 'VM_global_library.vm' in any resource loader. [INFO] Velocimacro : error using VM library template VM_global_library.vm : org .apache.velocity.exception.ResourceNotFoundException: Unable to find resource 'V M_global_library.vm' [INFO] Velocimacro : VM library template macro registration complete. [INFO] Velocimacro : allowInline = true : VMs can be defined inline in templates [INFO] Velocimacro : allowInlineToOverride = false : VMs defined inline may NOT replace previous VM definitions [INFO] Velocimacro : allowInlineLocal = false : VMs defined inline will be glob al in scope if allowed. [INFO] Velocimacro : initialization complete. [INFO] Velocity successfully started. [INFO] [archetype:create] [INFO] Defaulting package to group ID: org.apache.servicemix.bam [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Failed to resolve artifact. GroupId: org.apache.servicemix.tooling ArtifactId: servicemix-service-engine Version: 1.0-incubating-SNAPSHOT Reason: Unable to download the artifact from any repository Try downloading the file manually from the project website. Then, install it using the command: mvn install:install-file -DgroupId=org.apache.servicemix.tooling -DartifactI d=servicemix-service-engine \ -Dversion=1.0-incubating-SNAPSHOT -Dpackaging=jar -Dfile=/path/to/file org.apache.servicemix.tooling:servicemix-service-engine:jar:1.0-incubating-SNA PSHOT from the specified remote repositories: central (http://repo1.maven.org/maven2) Any pointers? ~Vikas
Re: creating a standard JBI Component using servicemix-common module
We currently have problems uploading snapshots. Even in this case, as they are not on public repositories, I'm not sure it would work. The best way would be to build ServiceMix from sources, as the archetypes will be in your local repository. On 8/3/06, vikas kumar [EMAIL PROTECTED] wrote: Hi Guillaume/All, Tried creating a standard JBI Component using servicemix-common module. I followed the steps written in http://servicemix.org/site/creating-a-standard-jbi-component.html On executing the command mvn archetype:create \ -DarchetypeGroupId=org.apache.servicemix.tooling \ -DarchetypeArtifactId=servicemix-service-engine \ -DarchetypeVersion=1.0-incubating-SNAPSHOT \ -DgroupId=org.apache.servicemix.xslt \ -DartifactId=servicemix-xslt I got the following error: [ERROR] ResourceManager : unable to find resource 'VM_global_library.vm' in any resource loader. [INFO] Velocimacro : error using VM library template VM_global_library.vm : org .apache.velocity.exception.ResourceNotFoundException: Unable to find resource 'V M_global_library.vm' [INFO] Velocimacro : VM library template macro registration complete. [INFO] Velocimacro : allowInline = true : VMs can be defined inline in templates [INFO] Velocimacro : allowInlineToOverride = false : VMs defined inline may NOT replace previous VM definitions [INFO] Velocimacro : allowInlineLocal = false : VMs defined inline will be glob al in scope if allowed. [INFO] Velocimacro : initialization complete. [INFO] Velocity successfully started. [INFO] [archetype:create] [INFO] Defaulting package to group ID: org.apache.servicemix.bam [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Failed to resolve artifact. GroupId: org.apache.servicemix.tooling ArtifactId: servicemix-service-engine Version: 1.0-incubating-SNAPSHOT Reason: Unable to download the artifact from any repository Try downloading the file manually from the project website. Then, install it using the command: mvn install:install-file -DgroupId=org.apache.servicemix.tooling-DartifactI d=servicemix-service-engine \ -Dversion=1.0-incubating-SNAPSHOT -Dpackaging=jar -Dfile=/path/to/file org.apache.servicemix.tooling:servicemix-service-engine:jar:1.0-incubating-SNA PSHOT from the specified remote repositories: central (http://repo1.maven.org/maven2) Any pointers? ~Vikas -- Cheers, Guillaume Nodet
[jira] Commented: (GERONIMO-2255) Error on creation of standalone web services
[ http://issues.apache.org/jira/browse/GERONIMO-2255?page=comments#action_12425474 ] Manu T George commented on GERONIMO-2255: - I agree and understand now why its a bad idea to manually add the dependencies. Unfortunately I did not have that understanding when I posted the patch. Thank you for explaining the reasons. I also see that servlet web services get deployed and work when they are deployed as ear's. Somehow the references are getting resolved in that case. Error on creation of standalone web services Key: GERONIMO-2255 URL: http://issues.apache.org/jira/browse/GERONIMO-2255 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: webservices Affects Versions: 1.1.x Environment: Windows XP ,Sun JDK Reporter: Manu T George Attachments: openejb-deployer.diff, tomcat-deployer.diff When i deploy a standalone ejb web service in Geronimo 1.1 it gives an error 00:11:04,238 ERROR [Servlet] Exception caught: javax.portlet.PortletException: Exception at org.apache.geronimo.console.configmanager.ConfigManagerPortlet.proces sAction(ConfigManagerPortlet.java:107) at org.apache.pluto.core.PortletServlet.dispatch(PortletServlet.java:229 ) at org.apache.pluto.core.PortletServlet.doGet(PortletServlet.java:158) at javax.servlet.http.HttpServlet.service(HttpServlet.java:595) at javax.servlet.http.HttpServlet.service(HttpServlet.java:688) at org.apache.pluto.core.PortletServlet.service(PortletServlet.java:153) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Appl icationFilterChain.java:252) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationF ilterChain.java:173) at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDisp atcher.java:672) at org.apache.catalina.core.ApplicationDispatcher.doInclude(ApplicationD ispatcher.java:574) at org.apache.catalina.core.ApplicationDispatcher.include(ApplicationDis patcher.java:499) at org.apache.pluto.invoker.impl.PortletInvokerImpl.invoke(PortletInvoke rImpl.java:120) at org.apache.pluto.invoker.impl.PortletInvokerImpl.action (PortletInvoke rImpl.java:68) at org.apache.pluto.PortletContainerImpl.processPortletAction(PortletCon tainerImpl.java:164) at org.apache.pluto.portalImpl.core.PortletContainerWrapperImpl.processP ortletAction(PortletContainerWrapperImpl.java:82) at org.apache.pluto.portalImpl.Servlet.doGet(Servlet.java:227) at javax.servlet.http.HttpServlet.service(HttpServlet.java:595) at javax.servlet.http.HttpServlet.service (HttpServlet.java:688) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Appl icationFilterChain.java:252) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationF ilterChain.java:173) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperV alve.java:213) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextV alve.java :178) at org.apache.geronimo.tomcat.valve.DefaultSubjectValve.invoke(DefaultSu bjectValve.java:52) at org.apache.catalina.authenticator.AuthenticatorBase.invoke(Authentica torBase.java:524) at org.apache.geronimo.tomcat.GeronimoStandardContext$SystemMethodValve. invoke(GeronimoStandardContext.java:342) at org.apache.geronimo.tomcat.valve.GeronimoBeforeAfterValve.invoke(Gero nimoBeforeAfterValve.java :31) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.j ava:126) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.j ava:105) at org.apache.catalina.core.StandardEngineValve.invoke (StandardEngineVal ve.java:107) at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java: 541) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.jav a:148) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java :869) at org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.p rocessConnection(Http11BaseProtocol.java:667) at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpo int.java:527) at org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(LeaderFol lowerWorkerThread.java:80) at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadP ool.java:684) at java.lang.Thread.run(Unknown Source) Caused by: org.apache.geronimo.kernel.config.LifecycleException: start of geroni mo-samples/WSBean/1.2-SNAPSHOT/car failed at
Re: creating a standard JBI Component using servicemix-common module
Thanks. Can you send me the steps to do it. i am a newbie. ~Vikas On 8/3/06, Guillaume Nodet [EMAIL PROTECTED] wrote: We currently have problems uploading snapshots. Even in this case, as they are not on public repositories, I'm not sure it would work. The best way would be to build ServiceMix from sources, as the archetypes will be in your local repository. On 8/3/06, vikas kumar [EMAIL PROTECTED] wrote: Hi Guillaume/All, Tried creating a standard JBI Component using servicemix-common module. I followed the steps written in http://servicemix.org/site/creating-a-standard-jbi-component.html On executing the command mvn archetype:create \ -DarchetypeGroupId=org.apache.servicemix.tooling \ -DarchetypeArtifactId=servicemix-service-engine \ -DarchetypeVersion=1.0-incubating-SNAPSHOT \ -DgroupId=org.apache.servicemix.xslt \ -DartifactId=servicemix-xslt I got the following error: [ERROR] ResourceManager : unable to find resource 'VM_global_library.vm' in any resource loader. [INFO] Velocimacro : error using VM library template VM_global_library.vm : org .apache.velocity.exception.ResourceNotFoundException: Unable to find resource 'V M_global_library.vm' [INFO] Velocimacro : VM library template macro registration complete. [INFO] Velocimacro : allowInline = true : VMs can be defined inline in templates [INFO] Velocimacro : allowInlineToOverride = false : VMs defined inline may NOT replace previous VM definitions [INFO] Velocimacro : allowInlineLocal = false : VMs defined inline will be glob al in scope if allowed. [INFO] Velocimacro : initialization complete. [INFO] Velocity successfully started. [INFO] [archetype:create] [INFO] Defaulting package to group ID: org.apache.servicemix.bam [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Failed to resolve artifact. GroupId: org.apache.servicemix.tooling ArtifactId: servicemix-service-engine Version: 1.0-incubating-SNAPSHOT Reason: Unable to download the artifact from any repository Try downloading the file manually from the project website. Then, install it using the command: mvn install:install-file -DgroupId=org.apache.servicemix.tooling-DartifactI d=servicemix-service-engine \ -Dversion=1.0-incubating-SNAPSHOT -Dpackaging=jar -Dfile=/path/to/file org.apache.servicemix.tooling:servicemix-service-engine:jar:1.0-incubating-SNA PSHOT from the specified remote repositories: central (http://repo1.maven.org/maven2) Any pointers? ~Vikas -- Cheers, Guillaume Nodet
Re: creating a standard JBI Component using servicemix-common module
You can also download the archetype from http://people.apache.org/maven-snapshot-repository/org/apache/servicemix/tooling/servicemix-service-engine/1.0-incubating-SNAPSHOT/servicemix-service-engine-1.0-incubating-20060803.064327-5.jar and put it in your local maven repo under ~/.m2/org/apache/servicemix/tooling/servicemix-service-engine/1.0-incubating-SNAPSHOT It should also work. On 8/3/06, Guillaume Nodet [EMAIL PROTECTED] wrote: We currently have problems uploading snapshots. Even in this case, as they are not on public repositories, I'm not sure it would work. The best way would be to build ServiceMix from sources, as the archetypes will be in your local repository. On 8/3/06, vikas kumar [EMAIL PROTECTED] wrote: Hi Guillaume/All, Tried creating a standard JBI Component using servicemix-common module. I followed the steps written in http://servicemix.org/site/creating-a-standard-jbi-component.html On executing the command mvn archetype:create \ -DarchetypeGroupId=org.apache.servicemix.tooling \ -DarchetypeArtifactId=servicemix-service-engine \ -DarchetypeVersion=1.0-incubating-SNAPSHOT \ -DgroupId=org.apache.servicemix.xslt \ -DartifactId=servicemix-xslt I got the following error: [ERROR] ResourceManager : unable to find resource 'VM_global_library.vm' in any resource loader. [INFO] Velocimacro : error using VM library template VM_global_library.vm : org .apache.velocity.exception.ResourceNotFoundException: Unable to find resource 'V M_global_library.vm' [INFO] Velocimacro : VM library template macro registration complete. [INFO] Velocimacro : allowInline = true : VMs can be defined inline in templates [INFO] Velocimacro : allowInlineToOverride = false : VMs defined inline may NOT replace previous VM definitions [INFO] Velocimacro : allowInlineLocal = false : VMs defined inline will be glob al in scope if allowed. [INFO] Velocimacro : initialization complete. [INFO] Velocity successfully started. [INFO] [archetype:create] [INFO] Defaulting package to group ID: org.apache.servicemix.bam [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Failed to resolve artifact. GroupId: org.apache.servicemix.tooling ArtifactId: servicemix-service-engine Version: 1.0-incubating-SNAPSHOT Reason: Unable to download the artifact from any repository Try downloading the file manually from the project website. Then, install it using the command: mvn install:install-file -DgroupId= org.apache.servicemix.tooling-DartifactI d=servicemix-service-engine \ -Dversion=1.0-incubating-SNAPSHOT -Dpackaging=jar -Dfile=/path/to/file org.apache.servicemix.tooling:servicemix-service-engine:jar:1.0-incubating-SNA PSHOT from the specified remote repositories: central (http://repo1.maven.org/maven2) Any pointers? ~Vikas -- Cheers, Guillaume Nodet -- Cheers, Guillaume Nodet
Re: creating a standard JBI Component using servicemix-common module
See http://servicemix.goopen.org/site/building.html On 8/3/06, vikas kumar [EMAIL PROTECTED] wrote: Thanks. Can you send me the steps to do it. i am a newbie. ~Vikas On 8/3/06, Guillaume Nodet [EMAIL PROTECTED] wrote: We currently have problems uploading snapshots. Even in this case, as they are not on public repositories, I'm not sure it would work. The best way would be to build ServiceMix from sources, as the archetypes will be in your local repository. On 8/3/06, vikas kumar [EMAIL PROTECTED] wrote: Hi Guillaume/All, Tried creating a standard JBI Component using servicemix-common module. I followed the steps written in http://servicemix.org/site/creating-a-standard-jbi-component.html On executing the command mvn archetype:create \ -DarchetypeGroupId=org.apache.servicemix.tooling \ -DarchetypeArtifactId=servicemix-service-engine \ -DarchetypeVersion=1.0-incubating-SNAPSHOT \ -DgroupId=org.apache.servicemix.xslt \ -DartifactId=servicemix-xslt I got the following error: [ERROR] ResourceManager : unable to find resource 'VM_global_library.vm' in any resource loader. [INFO] Velocimacro : error using VM library template VM_global_library.vm : org .apache.velocity.exception.ResourceNotFoundException: Unable to find resource 'V M_global_library.vm' [INFO] Velocimacro : VM library template macro registration complete. [INFO] Velocimacro : allowInline = true : VMs can be defined inline in templates [INFO] Velocimacro : allowInlineToOverride = false : VMs defined inline may NOT replace previous VM definitions [INFO] Velocimacro : allowInlineLocal = false : VMs defined inline will be glob al in scope if allowed. [INFO] Velocimacro : initialization complete. [INFO] Velocity successfully started. [INFO] [archetype:create] [INFO] Defaulting package to group ID: org.apache.servicemix.bam [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Failed to resolve artifact. GroupId: org.apache.servicemix.tooling ArtifactId: servicemix-service-engine Version: 1.0-incubating-SNAPSHOT Reason: Unable to download the artifact from any repository Try downloading the file manually from the project website. Then, install it using the command: mvn install:install-file -DgroupId= org.apache.servicemix.tooling-DartifactI d=servicemix-service-engine \ -Dversion=1.0-incubating-SNAPSHOT -Dpackaging=jar -Dfile=/path/to/file org.apache.servicemix.tooling:servicemix-service-engine:jar:1.0-incubating-SNA PSHOT from the specified remote repositories: central (http://repo1.maven.org/maven2) Any pointers? ~Vikas -- Cheers, Guillaume Nodet -- Cheers, Guillaume Nodet
Re: [Discussion] Removal of TransactionContextManager
On 8/3/06, David Jencks [EMAIL PROTECTED] wrote: UserTransaction --- TransactionManagerImpl now implements UserTransaction to ease integration with third party libraries such as SpringWhy is this a good idea?This strikes me as a bad idea since a user can successfully cast UserTransaction to TransactionManager.This is only true if the exposed UserTransaction *is* the TransactionManager.It seems there is a simple UserTransaction implementation on top of the TransactionManagerImpl which can be exposed.-- Cheers,Guillaume Nodet Removed OnlineUserTransaction since it was only really used by OpenEJB and it has it's own UserTransaction implementation Web containers now use GeronimoUserTransaction which is an always on wrapper around a transaction manager Third party support --- Moved use of ServerInfo from HOWLLog to HOWLLogGBean so it can be more easily use by third party libraries Moved connector related transaction data to connector moduleI guess considering the number of threadlocal accesses and hashmaplookups in this code possibly adding one more isn't going to cause problems.How do you associate the data with the transaction? Replace use of Geronimo's thread pool with a concurrent executorIs this java 5 only?If so how is our retrotranslator testinggoing?Having just read the concurrency in practice book I'm eager to move to java 5 now :-)thanksdavid jencks -dain
Re: creating a standard JBI Component using servicemix-common module
Guillaume, I guess I got past this by re-building smx. What I am stuck with now is that eclipse is complaining that the project that was created using the command mvn eclipse:eclipse is not OK. Have you tried doing it lately? Thanks Soumadeep - Original Message - From: Guillaume Nodet [EMAIL PROTECTED] To: servicemix-dev@geronimo.apache.org Sent: Thursday, August 03, 2006 2:40 PM Subject: Re: creating a standard JBI Component using servicemix-common module You can also download the archetype from http://people.apache.org/maven-snapshot-repository/org/apache/servicemix/tooling/servicemix-service-engine/1.0-incubating-SNAPSHOT/servicemix-service-engine-1.0-incubating-20060803.064327-5.jar and put it in your local maven repo under ~/.m2/org/apache/servicemix/tooling/servicemix-service-engine/1.0-incubating-SNAPSHOT It should also work. On 8/3/06, Guillaume Nodet [EMAIL PROTECTED] wrote: We currently have problems uploading snapshots. Even in this case, as they are not on public repositories, I'm not sure it would work. The best way would be to build ServiceMix from sources, as the archetypes will be in your local repository. On 8/3/06, vikas kumar [EMAIL PROTECTED] wrote: Hi Guillaume/All, Tried creating a standard JBI Component using servicemix-common module. I followed the steps written in http://servicemix.org/site/creating-a-standard-jbi-component.html On executing the command mvn archetype:create \ -DarchetypeGroupId=org.apache.servicemix.tooling \ -DarchetypeArtifactId=servicemix-service-engine \ -DarchetypeVersion=1.0-incubating-SNAPSHOT \ -DgroupId=org.apache.servicemix.xslt \ -DartifactId=servicemix-xslt I got the following error: [ERROR] ResourceManager : unable to find resource 'VM_global_library.vm' in any resource loader. [INFO] Velocimacro : error using VM library template VM_global_library.vm : org .apache.velocity.exception.ResourceNotFoundException: Unable to find resource 'V M_global_library.vm' [INFO] Velocimacro : VM library template macro registration complete. [INFO] Velocimacro : allowInline = true : VMs can be defined inline in templates [INFO] Velocimacro : allowInlineToOverride = false : VMs defined inline may NOT replace previous VM definitions [INFO] Velocimacro : allowInlineLocal = false : VMs defined inline will be glob al in scope if allowed. [INFO] Velocimacro : initialization complete. [INFO] Velocity successfully started. [INFO] [archetype:create] [INFO] Defaulting package to group ID: org.apache.servicemix.bam [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Failed to resolve artifact. GroupId: org.apache.servicemix.tooling ArtifactId: servicemix-service-engine Version: 1.0-incubating-SNAPSHOT Reason: Unable to download the artifact from any repository Try downloading the file manually from the project website. Then, install it using the command: mvn install:install-file -DgroupId= org.apache.servicemix.tooling-DartifactI d=servicemix-service-engine \ -Dversion=1.0-incubating-SNAPSHOT -Dpackaging=jar -Dfile=/path/to/file org.apache.servicemix.tooling:servicemix-service-engine:jar:1.0-incubating-SNA PSHOT from the specified remote repositories: central (http://repo1.maven.org/maven2) Any pointers? ~Vikas -- Cheers, Guillaume Nodet -- Cheers, Guillaume Nodet
[jira] Commented: (GERONIMO-1476) Changes to default log4j.rootCategory are not dynamic
[ http://issues.apache.org/jira/browse/GERONIMO-1476?page=comments#action_12425475 ] Chris Cardona commented on GERONIMO-1476: - Donald, I wasn't able to replicate this problem. I modified the root logger level from log4j.rootCategory=INFO, CONSOLE, FILE to log4j.rootCategory=ALL, CONSOLE, FILE and it behaved as expected. I saw INFO, WARN, ERROR and FATAL messages logged into the console and DEBUG, INFO, WARN, ERROR and FATAL logged into geronimo.log file. Note that the CONSOLE appender has its threshold set to INFO by default and the FILE appender is set to DEBUG by default. Even though the root logger's level is set to ALL it has no influence on the appenders attached to it. The appender's threshold settings will be followed. Please comment if you think I misunderstood your problem otherwise I suggest that we close this issue. Thanks. chris Changes to default log4j.rootCategory are not dynamic - Key: GERONIMO-1476 URL: http://issues.apache.org/jira/browse/GERONIMO-1476 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: Logging Affects Versions: 1.0 Environment: AG 1.0 on WinXP w/ Sun JDK 1.4.2_08 Reporter: Donald Woods Assigned To: Chris Cardona Fix For: 1.1.1 Changes to the log4j.rootCategory value in server-log4j.properties while the server is running has no effect. If you change the default - log4j.rootCategory=INFO, CONSOLE, FILE to log4j.rootCategory=ALL, CONSOLE, FILE none of the Log4J loggers are updated to emit the additional log levels of Debug, Trace and All. Updating the following appender - log4j.appender.FILE.threshold=INFO to ALL is dynamic for already set components, so the timer thread to pickup changes to server-log4j.properties is working, but the rootCategory is never updated if changed. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: creating a standard JBI Component using servicemix-common module
What do you mean by not OK ? On 8/3/06, Soumadeep-Infravio [EMAIL PROTECTED] wrote: Guillaume, I guess I got past this by re-building smx. What I am stuck with now is that eclipse is complaining that the project that was created using the command mvn eclipse:eclipse is not OK. Have you tried doing it lately? Thanks Soumadeep - Original Message - From: Guillaume Nodet [EMAIL PROTECTED] To: servicemix-dev@geronimo.apache.org Sent: Thursday, August 03, 2006 2:40 PM Subject: Re: creating a standard JBI Component using servicemix-common module You can also download the archetype from http://people.apache.org/maven-snapshot-repository/org/apache/servicemix/tooling/servicemix-service-engine/1.0-incubating-SNAPSHOT/servicemix-service-engine-1.0-incubating-20060803.064327-5.jar and put it in your local maven repo under ~/.m2/org/apache/servicemix/tooling/servicemix-service-engine/1.0-incubating-SNAPSHOT It should also work. On 8/3/06, Guillaume Nodet [EMAIL PROTECTED] wrote: We currently have problems uploading snapshots. Even in this case, as they are not on public repositories, I'm not sure it would work. The best way would be to build ServiceMix from sources, as the archetypes will be in your local repository. On 8/3/06, vikas kumar [EMAIL PROTECTED] wrote: Hi Guillaume/All, Tried creating a standard JBI Component using servicemix-common module. I followed the steps written in http://servicemix.org/site/creating-a-standard-jbi-component.html On executing the command mvn archetype:create \ -DarchetypeGroupId=org.apache.servicemix.tooling \ -DarchetypeArtifactId=servicemix-service-engine \ -DarchetypeVersion=1.0-incubating-SNAPSHOT \ -DgroupId=org.apache.servicemix.xslt \ -DartifactId=servicemix-xslt I got the following error: [ERROR] ResourceManager : unable to find resource 'VM_global_library.vm' in any resource loader. [INFO] Velocimacro : error using VM library template VM_global_library.vm : org .apache.velocity.exception.ResourceNotFoundException: Unable to find resource 'V M_global_library.vm' [INFO] Velocimacro : VM library template macro registration complete. [INFO] Velocimacro : allowInline = true : VMs can be defined inline in templates [INFO] Velocimacro : allowInlineToOverride = false : VMs defined inline may NOT replace previous VM definitions [INFO] Velocimacro : allowInlineLocal = false : VMs defined inline will be glob al in scope if allowed. [INFO] Velocimacro : initialization complete. [INFO] Velocity successfully started. [INFO] [archetype:create] [INFO] Defaulting package to group ID: org.apache.servicemix.bam [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Failed to resolve artifact. GroupId: org.apache.servicemix.tooling ArtifactId: servicemix-service-engine Version: 1.0-incubating-SNAPSHOT Reason: Unable to download the artifact from any repository Try downloading the file manually from the project website. Then, install it using the command: mvn install:install-file -DgroupId= org.apache.servicemix.tooling-DartifactI d=servicemix-service-engine \ -Dversion=1.0-incubating-SNAPSHOT -Dpackaging=jar -Dfile=/path/to/file org.apache.servicemix.tooling:servicemix-service-engine:jar:1.0-incubating-SNA PSHOT from the specified remote repositories: central (http://repo1.maven.org/maven2) Any pointers? ~Vikas -- Cheers, Guillaume Nodet -- Cheers, Guillaume Nodet -- Cheers, Guillaume Nodet
Re: creating a standard JBI Component using servicemix-common module
Resolved it... problem with classpath. It created two eclipse related files 1) .project 2) .classpath The problem is when I import this project into Eclipse it doesn't resolve the classapth. Do I need to do anything else? Thanks Soumadeep - Original Message - From: Guillaume Nodet [EMAIL PROTECTED] To: servicemix-dev@geronimo.apache.org Sent: Thursday, August 03, 2006 3:11 PM Subject: Re: creating a standard JBI Component using servicemix-common module What do you mean by not OK ? On 8/3/06, Soumadeep-Infravio [EMAIL PROTECTED] wrote: Guillaume, I guess I got past this by re-building smx. What I am stuck with now is that eclipse is complaining that the project that was created using the command mvn eclipse:eclipse is not OK. Have you tried doing it lately? Thanks Soumadeep - Original Message - From: Guillaume Nodet [EMAIL PROTECTED] To: servicemix-dev@geronimo.apache.org Sent: Thursday, August 03, 2006 2:40 PM Subject: Re: creating a standard JBI Component using servicemix-common module You can also download the archetype from http://people.apache.org/maven-snapshot-repository/org/apache/servicemix/tooling/servicemix-service-engine/1.0-incubating-SNAPSHOT/servicemix-service-engine-1.0-incubating-20060803.064327-5.jar and put it in your local maven repo under ~/.m2/org/apache/servicemix/tooling/servicemix-service-engine/1.0-incubating-SNAPSHOT It should also work. On 8/3/06, Guillaume Nodet [EMAIL PROTECTED] wrote: We currently have problems uploading snapshots. Even in this case, as they are not on public repositories, I'm not sure it would work. The best way would be to build ServiceMix from sources, as the archetypes will be in your local repository. On 8/3/06, vikas kumar [EMAIL PROTECTED] wrote: Hi Guillaume/All, Tried creating a standard JBI Component using servicemix-common module. I followed the steps written in http://servicemix.org/site/creating-a-standard-jbi-component.html On executing the command mvn archetype:create \ -DarchetypeGroupId=org.apache.servicemix.tooling \ -DarchetypeArtifactId=servicemix-service-engine \ -DarchetypeVersion=1.0-incubating-SNAPSHOT \ -DgroupId=org.apache.servicemix.xslt \ -DartifactId=servicemix-xslt I got the following error: [ERROR] ResourceManager : unable to find resource 'VM_global_library.vm' in any resource loader. [INFO] Velocimacro : error using VM library template VM_global_library.vm : org .apache.velocity.exception.ResourceNotFoundException: Unable to find resource 'V M_global_library.vm' [INFO] Velocimacro : VM library template macro registration complete. [INFO] Velocimacro : allowInline = true : VMs can be defined inline in templates [INFO] Velocimacro : allowInlineToOverride = false : VMs defined inline may NOT replace previous VM definitions [INFO] Velocimacro : allowInlineLocal = false : VMs defined inline will be glob al in scope if allowed. [INFO] Velocimacro : initialization complete. [INFO] Velocity successfully started. [INFO] [archetype:create] [INFO] Defaulting package to group ID: org.apache.servicemix.bam [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Failed to resolve artifact. GroupId: org.apache.servicemix.tooling ArtifactId: servicemix-service-engine Version: 1.0-incubating-SNAPSHOT Reason: Unable to download the artifact from any repository Try downloading the file manually from the project website. Then, install it using the command: mvn install:install-file -DgroupId= org.apache.servicemix.tooling-DartifactI d=servicemix-service-engine \ -Dversion=1.0-incubating-SNAPSHOT -Dpackaging=jar -Dfile=/path/to/file org.apache.servicemix.tooling:servicemix-service-engine:jar:1.0-incubating-SNA PSHOT from the specified remote repositories: central (http://repo1.maven.org/maven2) Any pointers? ~Vikas -- Cheers, Guillaume Nodet -- Cheers, Guillaume Nodet -- Cheers, Guillaume Nodet
Re: auto-generating documentation for C++ client?
Awesome! Thanks. On 8/3/06, James Strachan [EMAIL PROTECTED] wrote: On 8/3/06, James Strachan [EMAIL PROTECTED] wrote: There you go... http://svn.apache.org/repos/asf/incubator/activemq/site/cms/ hopefully in an hour or so it should show up here http://incubator.apache.org/activemq/cms/html/ Unfortunately right now Confluence is down so we can't yet edit these pages to add a link... http://incubator.apache.org/activemq/javadocs.html http://incubator.apache.org/activemq/cms.html Done e.g. http://activemq.org/site/javadocs.html -- James --- http://radio.weblogs.com/0112098/
[jira] Resolved: (AMQ-854) Update to activemq-cpp source to enable documentation generation
[ https://issues.apache.org/activemq/browse/AMQ-854?page=all ] Nathan Mittler resolved AMQ-854. Resolution: Fixed The documentation has been added to http://activemq.org/site/javadocs.html Update to activemq-cpp source to enable documentation generation Key: AMQ-854 URL: https://issues.apache.org/activemq/browse/AMQ-854 Project: ActiveMQ Issue Type: Improvement Components: CMS (C++ client) Reporter: Timothy Bish Assigned To: Nathan Mittler Priority: Minor Attachments: activemq-cpp-0-0-2-DOCUpdates.zip This patch contains updated source files for the activemq-cpp project which expand the code documentation and clean up documentation that caused warnings when running the doxygen tool to document the code. A set of generated documentation files is included in the new docs folder. This patch adds no new functionality. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Creating a secure connection system and using JMSXUserID support
I agree with this, I only think it will be a tough job. I also have a deadline, so I suggest that we split the work. I may take custom truststore and certificate authentication against LDAP (I already have idea how to do it) but I am open to suggestions. Regards, NGC Sepand M wrote: Ok. So from what I've read, we're trying to separate the authorization part from the SSL socket and let the broker handle it. This sounds great. It would take more work (not so great since I have a deadline), but it would be a proper solution. From what I know of JAAS, the subject/principals fully represent identity. So attaching them to Connection info would be a good idea. That way, the Transport's job would be to authenticate and the Broker could handle authorization completely. This would also mean that any communication system could be used without having to change the Broker (as long as the Transport can authenticate and create proper subjet/principals). The one thing I will note is that we are changing the ActiveMQ architecture in that currently, the Brokers are doing both authentication and authorization (e.g. The Brokers are currently doing the user name and password validation). I think, however, that this is necessary because without our change, there would need to be a new broker for every new, authenticated, communication system. Please tell me if you agree (in which case I'll start looking at implementation details). On 8/2/06, David Jencks [EMAIL PROTECTED] wrote: I'm confused by the descriptions of this approach, and don't understand what is being proposed. I would separate the steps of 1. validating the client certificate based on the presented certificate chain, which in my experience can be done by the standard truststore implementation that comes with java, and serves to identify the client: this is done during the ssl connection setup and 2. deciding if the identified client is someone you want to let into the system, which can be done with a JAAS login module that accepts either a certificate chain callback handler (probably way overkill), the client certificate (possibly overkill, we've already verified the validity of the chain), or just the DN. Keeping the DN in LDAP should be no problem, perhaps mapped to the principals you want the user to have: I think this could be done after the ssl connection is set up and 3. deciding what permissions the logged in user should get. You might want to consider using a JACC like approach: I set up something like this for portal permissions in jetspeed2 and suspect something similar ought to work for amq. many thanks david jencks On Aug 2, 2006, at 12:20 PM, Hiram Chirino wrote: Hi, On 8/2/06, ngcutura [EMAIL PROTECTED] wrote: Hmmm... It didn't cross my mind but yes, indeed, it is possible. We may supply a fake truststore that would return 'true' for any certificate submitted for authentication and then perform real authentication after connection setup. We would then be able to obtain client certificate exactly as you stated. If we accept this approach, I see three components to implement: 1. Fake truststore 2. CertificateLoginModule (against LDAP) 3. Tweak connection setup to ask for peer certificates. In 3. we actually need some kind of policy reagarding authenitcation. Although SSL connection is established, a client may still supply username/password meaning that it should be used for login. I guess that obtaining client certificate from SSL session should be the last option. In 'Certificate login' thread I described another approach: We may use SSL without client authentication but find a way to export certificate to a String (on client side) and then supply that string as 'username' in createConnection(). On server side, the String would be converted back to certificate and authenticated. With this approach, we need to agree on the string format and conversion discipline and then only another JAAS login module is required (that would actually perform coversion from String to Certificate and authenticate). Thus no change is required in existing code. We may even add another non-portable createConnection(Certificate, brokerURL) that would convert Certificate to String and invoke createConnection(username, password, brokerURL). So, the necessary modules to implement would be: 1. Utility to convert Certificate to a string and back. 1a. (optional) createConnection(Certificate, brokerURL) method and ActiveMQConnection(Certifcate, brokerURL) constructor that perform conversion from Certificate to String using utility in #1 and invoke appropriate existing meothods/constructors. This sounds fine to me too. I would use the DN as the userId and encode the certificate as a string for the password and add a ActiveMQConnectionFactory.setCertificate( Certificate ) and have that set
Problem using Custom Security Realm with MyLoginModule and MyPrincipal
Hi, I have deployed a Custom Security Realm using MyLoginModule and MyPrincipal classes. I have configured a simple web application to authenticate against this realm. Even though the login succeeds, I am getting an HTTP 403 Forbidden error. But everything works fine if I change MyLoginModule to use org.apache.geronimo.security.realm.providers.GeronimoUserPrincipal instead of MyPrincipal and change the deployment plan for my web app accordingly. I guess this has to do something with the class loaders. Any ideas on what is happening and how to fix this? Thanks, Vamsi
Re: Problem using Custom Security Realm with MyLoginModule and MyPrincipal
Does the environment for your web app list a dependency on the security realm? Thanks, Aaron On 8/3/06, Vamsavardhana Reddy [EMAIL PROTECTED] wrote: Hi, I have deployed a Custom Security Realm using MyLoginModule and MyPrincipal classes. I have configured a simple web application to authenticate against this realm. Even though the login succeeds, I am getting an HTTP 403 Forbidden error. But everything works fine if I change MyLoginModule to use org.apache.geronimo.security.realm.providers.GeronimoUserPrincipal instead of MyPrincipal and change the deployment plan for my web app accordingly. I guess this has to do something with the class loaders. Any ideas on what is happening and how to fix this? Thanks, Vamsi
[jira] Commented: (GERONIMO-2264) Created branches/1.1.1 to start release process
[ http://issues.apache.org/jira/browse/GERONIMO-2264?page=comments#action_12425533 ] Aaron Mulder commented on GERONIMO-2264: I guess we also need to: - create an OpenEJB 2.1.1 branch - update the Geronimo 1.1.1 branch to refer to the OpenEJB 2.1.1 branch Created branches/1.1.1 to start release process --- Key: GERONIMO-2264 URL: http://issues.apache.org/jira/browse/GERONIMO-2264 Project: Geronimo Issue Type: Task Security Level: public(Regular issues) Affects Versions: 1.1.1 Reporter: Matt Hogstrom Assigned To: Matt Hogstrom Fix For: 1.1.1 svn cp https://svn.apache.org/repos/asf/geronimo/branches/1.1 https://svn.apache.org/repos/asf/geronimo/branches/1.1.1 Committed revision 428093. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Problem using Custom Security Realm with MyLoginModule and MyPrincipal
On Aug 3, 2006, at 7:35 AM, Vamsavardhana Reddy wrote: Hi, I have deployed a Custom Security Realm using MyLoginModule and MyPrincipal classes. I have configured a simple web application to authenticate against this realm. Even though the login succeeds, I am getting an HTTP 403 Forbidden error. But everything works fine if I change MyLoginModule to use org.apache.geronimo.security.realm.providers.GeronimoUserPrincipal instead of MyPrincipal and change the deployment plan for my web app accordingly. I guess this has to do something with the class loaders. Any ideas on what is happening and how to fix this? You might be right about the classloaders or there might be another problem. I suggest putting a breakpoint in PolicyConfigurationGeneric.implies and stepping through the authorization decision to find out what is going on. If you get stuck please post the code and I'll try to figure it out. thanks david jencks Thanks, Vamsi
Re: Problem using Custom Security Realm with MyLoginModule and MyPrincipal
Web app adds a dependency to myloginmodule-1.0.jar in the repository but not the security realm. Thanks, VamsiOn 8/3/06, Aaron Mulder [EMAIL PROTECTED] wrote: Does the environment for your web app list a dependency on the security realm?Thanks, AaronOn 8/3/06, Vamsavardhana Reddy [EMAIL PROTECTED] wrote: Hi,I have deployed a Custom Security Realm using MyLoginModule and MyPrincipal classes.I have configured a simple web application to authenticate against this realm.Even though the login succeeds, I am getting an HTTP 403 Forbidden error.But everything works fine if I change MyLoginModule to use org.apache.geronimo.security.realm.providers.GeronimoUserPrincipal instead of MyPrincipal and change the deployment plan for my web app accordingly.I guess this has to do something with the class loaders.Any ideas on what is happening and how to fix this?Thanks,Vamsi
[jira] Created: (GERONIMO-2269) Error after failed redeploy with no version in module ID (branches/1.1.1)
Error after failed redeploy with no version in module ID (branches/1.1.1) - Key: GERONIMO-2269 URL: http://issues.apache.org/jira/browse/GERONIMO-2269 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Components: deployment, kernel Affects Versions: 1.1.1 Reporter: Aaron Mulder Fix For: 1.1.x I deployed a web application (including a resource-ref to a database pool) successfully, with a module ID containing only an artifact element. I changed the web.xml and redeployed it. It failed due to a syntax error in web.xml (I changed the login page to not start with a / and it complained; apparently the / is necessary). The application still appeared to be running, though I didn't test it. I fixed the web.xml and redeployed it. It failed with the following error. It seems that after the redeploy the JNDI entry for the data source was invalid? 11:57:44,865 ERROR [ContextLoader] Context initialization failed org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'DataSource' defined in resource [/WEB-INF/applicationContext.xml] of ServletContext: Initialization of bean failed; nested exception is javax.naming.NamingException: Could not look up : env/jdbc/Database javax.naming.NamingException: Could not look up : env/jdbc/Database [Root exception is org.apache.geronimo.kernel.proxy.DeadProxyException: Proxy is no longer valid] at org.apache.geronimo.naming.enc.CachingReference.resolveReference(CachingReference.java:59) at org.apache.geronimo.naming.enc.CachingReference.get(CachingReference.java:45) at org.apache.geronimo.naming.enc.AbstractReadOnlyContext.lookup(AbstractReadOnlyContext.java:86) at org.apache.geronimo.naming.java.RootContext.lookup(RootContext.java:51) at javax.naming.InitialContext.lookup(InitialContext.java:347) at org.springframework.jndi.JndiTemplate$1.doInContext(JndiTemplate.java:120) at org.springframework.jndi.JndiTemplate.execute(JndiTemplate.java:85) at org.springframework.jndi.JndiTemplate.lookup(JndiTemplate.java:117) at org.springframework.jndi.AbstractJndiLocator.lookup(AbstractJndiLocator.java:181) at org.springframework.jndi.AbstractJndiLocator.afterPropertiesSet(AbstractJndiLocator.java:171) at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.invokeInitMethods(AbstractAutowireCapableBeanFactory.java:801) at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:249) at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:177) at org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:159) at org.springframework.beans.factory.support.DefaultListableBeanFactory.preInstantiateSingletons(DefaultListableBeanFactory.java:177) at org.springframework.context.support.AbstractApplicationContext.refresh(AbstractApplicationContext.java:268) at org.springframework.web.context.support.XmlWebApplicationContext.refresh(XmlWebApplicationContext.java:131) at org.springframework.web.context.ContextLoader.createWebApplicationContext(ContextLoader.java:156) at org.springframework.web.context.ContextLoader.initWebApplicationContext(ContextLoader.java:97) at org.springframework.web.context.ContextLoaderListener.contextInitialized(ContextLoaderListener.java:48) at org.mortbay.jetty.servlet.WebApplicationContext.doStart(WebApplicationContext.java:495) at org.apache.geronimo.jetty.JettyWebAppContext.doStart(JettyWebAppContext.java:401) at org.mortbay.util.Container.start(Container.java:72) at org.apache.geronimo.jetty.JettyWebAppContext.doStart(JettyWebAppContext.java:389) at org.apache.geronimo.gbean.runtime.GBeanInstance.createInstance(GBeanInstance.java:981) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStart(GBeanInstanceState.java:267) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.start(GBeanInstanceState.java:102) at org.apache.geronimo.gbean.runtime.GBeanInstance.start(GBeanInstance.java:526) at org.apache.geronimo.gbean.runtime.GBeanDependency.attemptFullStart(GBeanDependency.java:111) at org.apache.geronimo.gbean.runtime.GBeanDependency.addTarget(GBeanDependency.java:146) at org.apache.geronimo.gbean.runtime.GBeanDependency$1.running(GBeanDependency.java:120) at org.apache.geronimo.kernel.basic.BasicLifecycleMonitor.fireRunningEvent(BasicLifecycleMonitor.java:173) at
[jira] Updated: (GERONIMO-2269) Error after redeploy (with no version in module ID) (branches/1.1.1)
[ http://issues.apache.org/jira/browse/GERONIMO-2269?page=all ] Aaron Mulder updated GERONIMO-2269: --- Summary: Error after redeploy (with no version in module ID) (branches/1.1.1) (was: Error after failed redeploy with no version in module ID (branches/1.1.1)) Description: I deployed a web application (including a resource-ref to a database pool) successfully, with a module ID containing only an artifact element. I changed the web.xml and redeployed it. It failed due to a syntax error in web.xml (I changed the login page to not start with a / and it complained; apparently the / is necessary). The application still appeared to be running, though I didn't test it. I fixed the web.xml and redeployed it. It failed with the following error. It seems that after the redeploy the JNDI entry for the data source was invalid? UPDATE: a simple redeploy of the working application causes the error -- it's not necessary to have the failed redeploy in between. 11:57:44,865 ERROR [ContextLoader] Context initialization failed org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'DataSource' defined in resource [/WEB-INF/applicationContext.xml] of ServletContext: Initialization of bean failed; nested exception is javax.naming.NamingException: Could not look up : env/jdbc/Database javax.naming.NamingException: Could not look up : env/jdbc/Database [Root exception is org.apache.geronimo.kernel.proxy.DeadProxyException: Proxy is no longer valid] at org.apache.geronimo.naming.enc.CachingReference.resolveReference(CachingReference.java:59) at org.apache.geronimo.naming.enc.CachingReference.get(CachingReference.java:45) at org.apache.geronimo.naming.enc.AbstractReadOnlyContext.lookup(AbstractReadOnlyContext.java:86) at org.apache.geronimo.naming.java.RootContext.lookup(RootContext.java:51) at javax.naming.InitialContext.lookup(InitialContext.java:347) at org.springframework.jndi.JndiTemplate$1.doInContext(JndiTemplate.java:120) at org.springframework.jndi.JndiTemplate.execute(JndiTemplate.java:85) at org.springframework.jndi.JndiTemplate.lookup(JndiTemplate.java:117) at org.springframework.jndi.AbstractJndiLocator.lookup(AbstractJndiLocator.java:181) at org.springframework.jndi.AbstractJndiLocator.afterPropertiesSet(AbstractJndiLocator.java:171) at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.invokeInitMethods(AbstractAutowireCapableBeanFactory.java:801) at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:249) at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:177) at org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:159) at org.springframework.beans.factory.support.DefaultListableBeanFactory.preInstantiateSingletons(DefaultListableBeanFactory.java:177) at org.springframework.context.support.AbstractApplicationContext.refresh(AbstractApplicationContext.java:268) at org.springframework.web.context.support.XmlWebApplicationContext.refresh(XmlWebApplicationContext.java:131) at org.springframework.web.context.ContextLoader.createWebApplicationContext(ContextLoader.java:156) at org.springframework.web.context.ContextLoader.initWebApplicationContext(ContextLoader.java:97) at org.springframework.web.context.ContextLoaderListener.contextInitialized(ContextLoaderListener.java:48) at org.mortbay.jetty.servlet.WebApplicationContext.doStart(WebApplicationContext.java:495) at org.apache.geronimo.jetty.JettyWebAppContext.doStart(JettyWebAppContext.java:401) at org.mortbay.util.Container.start(Container.java:72) at org.apache.geronimo.jetty.JettyWebAppContext.doStart(JettyWebAppContext.java:389) at org.apache.geronimo.gbean.runtime.GBeanInstance.createInstance(GBeanInstance.java:981) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStart(GBeanInstanceState.java:267) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.start(GBeanInstanceState.java:102) at org.apache.geronimo.gbean.runtime.GBeanInstance.start(GBeanInstance.java:526) at org.apache.geronimo.gbean.runtime.GBeanDependency.attemptFullStart(GBeanDependency.java:111) at org.apache.geronimo.gbean.runtime.GBeanDependency.addTarget(GBeanDependency.java:146) at org.apache.geronimo.gbean.runtime.GBeanDependency$1.running(GBeanDependency.java:120) at org.apache.geronimo.kernel.basic.BasicLifecycleMonitor.fireRunningEvent(BasicLifecycleMonitor.java:173) at
[jira] Created: (GERONIMO-2270) Redeploy broken in 1.1.1
Redeploy broken in 1.1.1 Key: GERONIMO-2270 URL: http://issues.apache.org/jira/browse/GERONIMO-2270 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Components: deployment Affects Versions: 1.1.1 Reporter: Aaron Mulder Priority: Blocker Fix For: 1.1.1 Tried to redeploy a WAR in 1.1.1. Got the following (note, I did actually redeploy): No ModuleID or TargetModuleID provided. Attempting to guess based on the content of the archive. Attempting to use ModuleID 'aaron/IIIQuotes/1.0/' Error: Operation failed: Module aaron/IIIQuotes/1.0/war already exists in the server. Try to undeploy it first or use the redeploy command. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [VOTE] Release Apache ActiveMQ 4.0.2 (RC 2)
I thought the NOTICE file for Derby was just that its ASF code? Or is the specific Deby stuff that needs adding to the NOTICE file? On 8/3/06, Kevan Miller [EMAIL PROTECTED] wrote: Hi Hiram, Is the NOTICE file correct? I believe you need a NOTICE for derby, at least. Also, the shell scripts in /bin are not marked executable when I untar the tar distribution... --kevan On Aug 1, 2006, at 1:47 PM, Hiram Chirino wrote: Some LICENSE file issues were found in the first release candidate of the 4.0.2 build. I have cut and RC 2 of the 4.0.2 build with the fixes and it's available here: http://people.apache.org/~chirino/incubator-activemq-4.0.2-RC2/ maven1/incubator-activemq/distributions/ Maven 1 and Maven 2 repos for this release can be found at: http://people.apache.org/~chirino/incubator-activemq-4.0.2-RC2 Here's the wiki page for the release notes (they should soon get mirrored to the activemq static website) : http://goopen.org/confluence/display/ACTIVEMQ/ActiveMQ+4.0.2+Release Please vote to approve this release binary [ ] +1 Release the binary as Apache ActiveMQ 4.0.2 [ ] -1 Veto the release (provide specific comments) If this vote passes, then we will then ask the Incubator PMC for their blessing to ship this release officially. Here's my +1 -- Regards, Hiram Blog: http://hiramchirino.com -- James --- http://radio.weblogs.com/0112098/
Redeploy problems in branches/1.1.1
I think this is a blocker. I tried redeploying a web application, both with and without a version in the module ID. It failed both ways, though differently for each. Matt, do you mind if we work on this in the 1.1.1 branch? Dain or David Jencks, any chance you could look at the without a version in the module ID case? It complained about a dead proxy when Spring accessed a JDBC pool at java:comp/env/jdbc/DataSource during startup of the new version (GERONIMO-2269) Thanks, Aaron http://issues.apache.org/jira/browse/GERONIMO-2269 http://issues.apache.org/jira/browse/GERONIMO-2270
[jira] Commented: (GERONIMO-2237) Filtering of springframework.org in TomcatDeployer plan creates CNF Exceptions in Ears
[ http://issues.apache.org/jira/browse/GERONIMO-2237?page=comments#action_12425558 ] Aaron Mulder commented on GERONIMO-2237: I tested a web application WAR using Spring 1 and Hibernate 2 with the branches/1.1.1 build and it worked (without any adjustments to the environment element). So it seems like Spring/Hibernate apps currently work OK in 1.1.1. However, I did not test an EAR. Filtering of springframework.org in TomcatDeployer plan creates CNF Exceptions in Ears -- Key: GERONIMO-2237 URL: http://issues.apache.org/jira/browse/GERONIMO-2237 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: Tomcat Affects Versions: 1.1 Reporter: Jeff Genender Priority: Blocker Fix For: 1.1.1 Filtering of springframework.org in TomcatDeployer plan creates ClassNotFound Exceptions in Ears when it tries to use a component that uses Spring in the EAR. We originally filtered this to automatically prevent Spring clashing with a server based Spring (from 1.0). This was fine for wars but when used iun an ear, the web container is blocked from using the EAR version. I recommend we remove these filters as SPrin is not usable in an EAR. Recommended patch for configs/tomcat-deployer: Index: src/plan/plan.xml === --- src/plan/plan.xml (revision 426203) +++ src/plan/plan.xml (working copy) @@ -46,10 +46,7 @@ typecar/type /dependency /dependencies -hidden-classes -filterantlr./filter -filterorg.springframework./filter -/hidden-classes +hidden-classes/ non-overridable-classes filterjava./filter filterjavax./filter -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Redeploy problems in branches/1.1.1
Is this a regression or is the first test? Aaron Mulder wrote: I think this is a blocker. I tried redeploying a web application, both with and without a version in the module ID. It failed both ways, though differently for each. Matt, do you mind if we work on this in the 1.1.1 branch? Dain or David Jencks, any chance you could look at the without a version in the module ID case? It complained about a dead proxy when Spring accessed a JDBC pool at java:comp/env/jdbc/DataSource during startup of the new version (GERONIMO-2269) Thanks, Aaron http://issues.apache.org/jira/browse/GERONIMO-2269 http://issues.apache.org/jira/browse/GERONIMO-2270
HotDeployer causing OutOfMemory error on repeated use
I am using HotDeployer extensively. After repeated use, the server is running into memory problems. I have built the server from branches/1.1. The last time I updated my source tree is two days ago. Has this problem been addressed in the past two days? Regards, Vamsi
Security Realm deployed as part of a web app listed as Serverwide in SecurityRealms portlet
Hi, I have deployed a web application with its own security realm. The new security realm is shown as Serverwide in Security Realms portlet. Is this the way it should be or is it a bug? Thanks, Vamsi
Re: Security Realm deployed as part of a web app listed as Serverwide in SecurityRealms portlet
Sounds like a bug to me. Thanks, Aaron On 8/3/06, Vamsavardhana Reddy [EMAIL PROTECTED] wrote: Hi, I have deployed a web application with its own security realm. The new security realm is shown as Serverwide in Security Realms portlet. Is this the way it should be or is it a bug? Thanks, Vamsi
Re: Security Realm deployed as part of a web app listed as Serverwide in SecurityRealms portlet
Calls for a JIRA. VamsiOn 8/3/06, Aaron Mulder [EMAIL PROTECTED] wrote: Sounds like a bug to me.Thanks, AaronOn 8/3/06, Vamsavardhana Reddy [EMAIL PROTECTED] wrote: Hi,I have deployed a web application with its own security realm.The new security realm is shown as Serverwide in Security Realms portlet.Is this the way it should be or is it a bug?Thanks,Vamsi
[jira] Updated: (GERONIMO-2270) Redeploy broken in 1.1.1
[ http://issues.apache.org/jira/browse/GERONIMO-2270?page=all ] Aaron Mulder updated GERONIMO-2270: --- Description: Tried to redeploy a WAR in 1.1.1. Got the following (note, I did actually redeploy): No ModuleID or TargetModuleID provided. Attempting to guess based on the content of the archive. Attempting to use ModuleID 'aaron/IIIQuotes/1.0/' Error: Operation failed: Module aaron/IIIQuotes/1.0/war already exists in the server. Try to undeploy it first or use the redeploy command. Appears to happen when the moduleId includes a group/artifact/version but no type. Did not happen when all of group, artifact, version, and type were specified. was: Tried to redeploy a WAR in 1.1.1. Got the following (note, I did actually redeploy): No ModuleID or TargetModuleID provided. Attempting to guess based on the content of the archive. Attempting to use ModuleID 'aaron/IIIQuotes/1.0/' Error: Operation failed: Module aaron/IIIQuotes/1.0/war already exists in the server. Try to undeploy it first or use the redeploy command. Redeploy broken in 1.1.1 Key: GERONIMO-2270 URL: http://issues.apache.org/jira/browse/GERONIMO-2270 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: deployment Affects Versions: 1.1.1 Reporter: Aaron Mulder Priority: Blocker Fix For: 1.1.1 Tried to redeploy a WAR in 1.1.1. Got the following (note, I did actually redeploy): No ModuleID or TargetModuleID provided. Attempting to guess based on the content of the archive. Attempting to use ModuleID 'aaron/IIIQuotes/1.0/' Error: Operation failed: Module aaron/IIIQuotes/1.0/war already exists in the server. Try to undeploy it first or use the redeploy command. Appears to happen when the moduleId includes a group/artifact/version but no type. Did not happen when all of group, artifact, version, and type were specified. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Redeploy problems in branches/1.1.1
On 8/3/06, Matt Hogstrom [EMAIL PROTECTED] wrote: Is this a regression or is the first test? It looks like 1.1 has the same problems for the same test application. I haven't tried this particular application before -- it is a Spring app I pulled off the shelf to make sure 1.1.1 didn't have problems with Spring/Hibernate web apps. Still, I'd really rather not ship 1.1.1 with known errors in the deploy tool. Thanks, Aaron Aaron Mulder wrote: I think this is a blocker. I tried redeploying a web application, both with and without a version in the module ID. It failed both ways, though differently for each. Matt, do you mind if we work on this in the 1.1.1 branch? Dain or David Jencks, any chance you could look at the without a version in the module ID case? It complained about a dead proxy when Spring accessed a JDBC pool at java:comp/env/jdbc/DataSource during startup of the new version (GERONIMO-2269) Thanks, Aaron http://issues.apache.org/jira/browse/GERONIMO-2269 http://issues.apache.org/jira/browse/GERONIMO-2270
[jira] Created: (GERONIMO-2271) Security Realm deployed as part of a web app listed as Serverwide
Security Realm deployed as part of a web app listed as Serverwide --- Key: GERONIMO-2271 URL: http://issues.apache.org/jira/browse/GERONIMO-2271 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Components: console Affects Versions: 1.1, 1.1.1, 1.1.x, 1.2 Environment: Win XP, G1.1.1-SNAPSHOT Tomcat Reporter: Vamsavardhana Reddy Fix For: 1.1.2, 1.1.x, 1.2 I have deployed a web application with its own security realm. The new security realm is shown as Serverwide in Security Realms portlet. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [Discussion] Removal of TransactionContextManager
On Aug 2, 2006, at 11:57 PM, David Jencks wrote: On Jul 31, 2006, at 4:09 PM, Dain Sundstrom wrote: history length=too long About a week ago there was a discussion on the OpenEJB mailing list regarding the TransactionContextManager. In OpenEJB 3 we removed the use of the TCM from Geronimo and replaced it with just a javax.transaction.TransactionManager. This brought all of the openejb containers into alignment. The other big motivation was to ease the integration of OpenEJB and third part libraries, specifically Spring. The problem with the TCM is that if you use it you can't use the TM directly since the TCM needs to know about all TM calls. Additionally, to use the TCM you must demarcate all changes in component context by starting an unspecified transaction context. This is all quite invasive and made OpenEJB hard to use in Spring or plain old Tomcat. That was all fine and good for OpenEJB 3, but as it turns out there is a desire to keep the OpenEJB 2 and 3 code aligned as much as possible, so a discussion started around how to backport the changes to 2. We determined there were two options: 1) wrap the TCM with a class that implements TM but delegates to the TCM - this would be tricky to get working and there is always the problem of demarcating the unspecified transaction context 2) remove the TCM from Geronimo entirely - this could be a lot of work After a quick look at the first option, I decided to try option two. It turned out to be a lot easier than I thought since, the biggest user of TCM was OpenEJB and I had already pulled it out of OpenEJB. I also think I have become the master of using the IntelliJ refactor tools and was able to remove the code without too much hand tweaking. /history I have checked the fruits of this effort into https:// svn.apache.org/repos/asf/geronimo/branches/dain/notcm and there is a matching OpenEJB branch that is checked out with maven m:co. I have not updated the m2 build yet, as it was finalized during this work. For those of you that are following the Jencks project, which wraps the Geronimo transaction and connector modules with Spring bean factories, I have created a branch there also, which contains a massive simplification due to the refactors in the removal of the Geronimo TCM. Here are some fun examples from that project: http://fisheye.codehaus.org/browse/jencks/branches/notcm/src/test/ resources/org/jencks/samples/outbound/jencks-tranql.xml?r=112 http://fisheye.codehaus.org/browse/jencks/branches/notcm/src/test/ resources/org/jencks/spring-request-reply-jta.xml?r=112 So what does everyone think about removing the TCM in general? After that I think we may want to discuss the specifics of my branch. I may have gotten too refactory happy :) Details on the specific changes I made follow: TransactionContextManager - Removed TransactionContextManager and replaced all uses with a plain old TransactionManager Removed all code from web containers, app client and timer that was simply demarcating an unspecified transaction context, which is no longer needed TransactionManager -- Merged XATerminator portion of TCM into GeronimoTransactionManager which is a subclass of TransactionManagerImpl Improved tx thread association code so we can throw an error if someone attempts to resume a tx associated with another thread Added TransactionManagerMonitor which is used by the connection tracker to know when a transaction context has changed UserTransaction --- TransactionManagerImpl now implements UserTransaction to ease integration with third party libraries such as Spring Why is this a good idea? This strikes me as a bad idea since a user can successfully cast UserTransaction to TransactionManager. As Guillaume pointed out, you don't have to expose this UserTransaction to the end user. I personally don't care if the user gets their hands on a TransctionManager as the difference between the two interfaces is quite small. Removed OnlineUserTransaction since it was only really used by OpenEJB and it has it's own UserTransaction implementation Web containers now use GeronimoUserTransaction which is an always on wrapper around a transaction manager Third party support --- Moved use of ServerInfo from HOWLLog to HOWLLogGBean so it can be more easily use by third party libraries Moved connector related transaction data to connector module I guess considering the number of threadlocal accesses and hashmap lookups in this code possibly adding one more isn't going to cause problems. How do you associate the data with the transaction? org.apache.geronimo.connector.ConnectorTransactionContext contains a ConcurrentHashMap keyed by the transaction object. Replace use of Geronimo's thread pool with a concurrent executor Is this java 5 only? If so how is our
Re: Current caller subject?
On Aug 2, 2006, at 11:29 PM, David Jencks wrote:
On Aug 2, 2006, at 10:53 PM, Dain Sundstrom wrote:
I'm working on the Jencks project again and have discovered that
the container managed security and pool partition by-subject
doesn't work oustide of Geronimo since both depend on obtaining
the current caller's subject from ContextManager.getCurrentCaller
(), which is a Geronimo specific class.
Is there a spec defined way we could be getting the current
caller's subject that would reasonably work in most app servers?
I'm hoping there is something in the JACC spec. If not, I think
we should introduce a hook under these static calls, so we can
redirect them to platform specific APIs when running outside of a
Geronimo server.
You could use
(Subject)PolicyContext.getContext
(javax.security.auth.Subject.container);
which in geronimo delegates to ContextManager.getCurrentCaller()
using a lot of hashmap lookups and security checks.
Based on the response I got from Alan on IRC and this message, I
don't think it would be appropriate to change the connector code use
the JACC api directly due to the performance problems. Maybe we can
change the ContextManager methods as follows:
public static boolean useJacc = true;
public static Subject getCurrentCaller() throws
PolicyContextException {
if (useJacc) {
return (Subject)PolicyContext.getContext
(javax.security.auth.Subject.container);
} else {
SecurityManager sm = System.getSecurityManager();
if (sm != null) sm.checkPermission(GET_CONTEXT);
return (Subject) currentCaller.get();
}
}
When running in a Geronimo server we set useJacc to false.
What do you think?
-dain
Re: Redeploy problems in branches/1.1.1
On Aug 3, 2006, at 9:18 AM, Aaron Mulder wrote: I think this is a blocker. I tried redeploying a web application, both with and without a version in the module ID. It failed both ways, though differently for each. Matt, do you mind if we work on this in the 1.1.1 branch? I'd say it should be worked on in 1.1.2. Dain or David Jencks, any chance you could look at the without a version in the module ID case? It complained about a dead proxy when Spring accessed a JDBC pool at java:comp/env/jdbc/DataSource during startup of the new version (GERONIMO-2269) Thanks, Aaron http://issues.apache.org/jira/browse/GERONIMO-2269 My guess is this one is a side effect of the next one, so I'd fix 2270 first and rerun this test case. http://issues.apache.org/jira/browse/GERONIMO-2270 Didn't you write the redeploy code? -dain
[jira] Commented: (GERONIMO-2271) Security Realm deployed as part of a web app listed as Serverwide
[ http://issues.apache.org/jira/browse/GERONIMO-2271?page=comments#action_12425567 ] Vamsavardhana Reddy commented on GERONIMO-2271: --- And I could deploy a second web application that authenticates against the security realm in the first web app!!! Security Realm deployed as part of a web app listed as Serverwide --- Key: GERONIMO-2271 URL: http://issues.apache.org/jira/browse/GERONIMO-2271 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: console Affects Versions: 1.1, 1.1.1, 1.1.x, 1.2 Environment: Win XP, G1.1.1-SNAPSHOT Tomcat Reporter: Vamsavardhana Reddy Fix For: 1.1.2, 1.1.x, 1.2 I have deployed a web application with its own security realm. The new security realm is shown as Serverwide in Security Realms portlet. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Redeploy problems in branches/1.1.1
On 8/3/06, Dain Sundstrom [EMAIL PROTECTED] wrote: http://issues.apache.org/jira/browse/GERONIMO-2269 My guess is this one is a side effect of the next one, so I'd fix 2270 first and rerun this test case. I will, though I disagree with your guess -- 2270 is a problem before the call ever gets to the server, while 2269 is a problem after the call has gone to the ConfigurationManager and the app has been distributed and the new version is being started. http://issues.apache.org/jira/browse/GERONIMO-2270 Didn't you write the redeploy code? No, couldn't have been me -- my code never has bugs! :) I'm sure I should look at 2270. I definitely can't take full credit for the version-less redeploy because that goes through ConfigurationManager, and I dropped the ball on trying to refactor that code. But the more relevant question probably is -- how can we end up with a dead proxy error when looking up a JNDI resource? The database pool wasn't redeployed so a reference to it shouldn't become dead, and the pool isn't in the web app module so the version number for the database pool shouldn't have changed... Its a little confusing. Thanks, Aaron
Re: Redeploy problems in branches/1.1.1
On Aug 3, 2006, at 10:11 AM, Aaron Mulder wrote: On 8/3/06, Dain Sundstrom [EMAIL PROTECTED] wrote: http://issues.apache.org/jira/browse/GERONIMO-2269 My guess is this one is a side effect of the next one, so I'd fix 2270 first and rerun this test case. I will, though I disagree with your guess -- 2270 is a problem before the call ever gets to the server, while 2269 is a problem after the call has gone to the ConfigurationManager and the app has been distributed and the new version is being started. Sorry, I don't understand what you are saying. My guess is based on this text UPDATE: a simple redeploy of the working application causes the error If there is a problem during redeploy, I'd question any JIRA about problems after that. http://issues.apache.org/jira/browse/GERONIMO-2270 Didn't you write the redeploy code? No, couldn't have been me -- my code never has bugs! :) I'm sure I should look at 2270. I definitely can't take full credit for the version-less redeploy because that goes through ConfigurationManager, and I dropped the ball on trying to refactor that code. I wrote big chuncks of this, but I think you wrote the part that matches versionless ids to preexisting installations. But the more relevant question probably is -- how can we end up with a dead proxy error when looking up a JNDI resource? The database pool wasn't redeployed so a reference to it shouldn't become dead, and the pool isn't in the web app module so the version number for the database pool shouldn't have changed... Its a little confusing. My guess is the pool was actually redeployed, but the only way to tell is to sick a breakpoint in the code. -dain
Re: Redeploy problems in branches/1.1.1
OK, well, I'm working on it. :) Thanks, Aaron On 8/3/06, Dain Sundstrom [EMAIL PROTECTED] wrote: On Aug 3, 2006, at 10:11 AM, Aaron Mulder wrote: On 8/3/06, Dain Sundstrom [EMAIL PROTECTED] wrote: http://issues.apache.org/jira/browse/GERONIMO-2269 My guess is this one is a side effect of the next one, so I'd fix 2270 first and rerun this test case. I will, though I disagree with your guess -- 2270 is a problem before the call ever gets to the server, while 2269 is a problem after the call has gone to the ConfigurationManager and the app has been distributed and the new version is being started. Sorry, I don't understand what you are saying. My guess is based on this text UPDATE: a simple redeploy of the working application causes the error If there is a problem during redeploy, I'd question any JIRA about problems after that. http://issues.apache.org/jira/browse/GERONIMO-2270 Didn't you write the redeploy code? No, couldn't have been me -- my code never has bugs! :) I'm sure I should look at 2270. I definitely can't take full credit for the version-less redeploy because that goes through ConfigurationManager, and I dropped the ball on trying to refactor that code. I wrote big chuncks of this, but I think you wrote the part that matches versionless ids to preexisting installations. But the more relevant question probably is -- how can we end up with a dead proxy error when looking up a JNDI resource? The database pool wasn't redeployed so a reference to it shouldn't become dead, and the pool isn't in the web app module so the version number for the database pool shouldn't have changed... Its a little confusing. My guess is the pool was actually redeployed, but the only way to tell is to sick a breakpoint in the code. -dain
Re: creating a standard JBI Component using servicemix-common module
Ok then for the time being, let me then follow the same dir structure and use ant to get things moving. Are you ok with that? Soumadeep - Original Message - From: Guillaume Nodet [EMAIL PROTECTED] To: servicemix-dev@geronimo.apache.org Sent: Thursday, August 03, 2006 7:15 PM Subject: Re: creating a standard JBI Component using servicemix-common module Yeah, unfortunately, I don't think this is currently possible with maven archetypes :( Unless someone know a way to generate new files from velocity templates. On 8/3/06, Soumadeep-Infravio [EMAIL PROTECTED] wrote: Not a good idea to refactor the class names, like I said - changing to BAMxxx, I think it's better to change the filenames in the template. The reason is there are a whole lot of xml and xsds which refer to the java classes... your thoughts.. Soumadeep - Original Message - From: Soumadeep-Infravio [EMAIL PROTECTED] To: servicemix-dev@geronimo.apache.org Sent: Thursday, August 03, 2006 6:08 PM Subject: Re: creating a standard JBI Component using servicemix-common module Yup.. the classpath variable in Eclipse. I am changing the classes to BAMxxx Thanks Soumadeep - Original Message - From: Guillaume Nodet [EMAIL PROTECTED] To: servicemix-dev@geronimo.apache.org Sent: Thursday, August 03, 2006 5:47 PM Subject: Re: creating a standard JBI Component using servicemix-common module Have you defined the property M2_REPO in Eclipse ? On 8/3/06, Soumadeep-Infravio [EMAIL PROTECTED] wrote: Resolved it... problem with classpath. It created two eclipse related files 1) .project 2) .classpath The problem is when I import this project into Eclipse it doesn't resolve the classapth. Do I need to do anything else? Thanks Soumadeep - Original Message - From: Guillaume Nodet [EMAIL PROTECTED] To: servicemix-dev@geronimo.apache.org Sent: Thursday, August 03, 2006 3:11 PM Subject: Re: creating a standard JBI Component using servicemix-common module What do you mean by not OK ? On 8/3/06, Soumadeep-Infravio [EMAIL PROTECTED] wrote: Guillaume, I guess I got past this by re-building smx. What I am stuck with now is that eclipse is complaining that the project that was created using the command mvn eclipse:eclipse is not OK. Have you tried doing it lately? Thanks Soumadeep - Original Message - From: Guillaume Nodet [EMAIL PROTECTED] To: servicemix-dev@geronimo.apache.org Sent: Thursday, August 03, 2006 2:40 PM Subject: Re: creating a standard JBI Component using servicemix-common module You can also download the archetype from http://people.apache.org/maven-snapshot-repository/org/apache/servicemix/tooling/servicemix-service-engine/1.0-incubating-SNAPSHOT/servicemix-service-engine-1.0-incubating-20060803.064327-5.jar and put it in your local maven repo under ~/.m2/org/apache/servicemix/tooling/servicemix-service-engine/1.0-incubating-SNAPSHOT It should also work. On 8/3/06, Guillaume Nodet [EMAIL PROTECTED] wrote: We currently have problems uploading snapshots. Even in this case, as they are not on public repositories, I'm not sure it would work. The best way would be to build ServiceMix from sources, as the archetypes will be in your local repository. On 8/3/06, vikas kumar [EMAIL PROTECTED] wrote: Hi Guillaume/All, Tried creating a standard JBI Component using servicemix-common module. I followed the steps written in http://servicemix.org/site/creating-a-standard-jbi-component.html On executing the command mvn archetype:create \ -DarchetypeGroupId=org.apache.servicemix.tooling \ -DarchetypeArtifactId=servicemix-service-engine \ -DarchetypeVersion=1.0-incubating-SNAPSHOT \ -DgroupId=org.apache.servicemix.xslt \ -DartifactId=servicemix-xslt I got the following error: [ERROR] ResourceManager : unable to find resource 'VM_global_library.vm' in any resource loader. [INFO] Velocimacro : error using VM library template VM_global_library.vm : org .apache.velocity.exception.ResourceNotFoundException: Unable to find resource 'V M_global_library.vm' [INFO] Velocimacro : VM library template macro registration complete. [INFO] Velocimacro : allowInline = true : VMs can be defined inline in templates [INFO] Velocimacro : allowInlineToOverride = false : VMs defined inline may NOT replace previous VM definitions [INFO] Velocimacro : allowInlineLocal = false : VMs defined inline will be glob al in scope if allowed. [INFO] Velocimacro : initialization complete. [INFO] Velocity successfully started. [INFO] [archetype:create] [INFO] Defaulting package to group ID: org.apache.servicemix.bam [INFO]
Re: creating a standard JBI Component using servicemix-common module
If you have renamed the file, where is your problem ? Using eclipse, you can easily refactor the code and it will change everything needed (at least in java files). I don' t how using ant will help you on that. On 8/3/06, Soumadeep-Infravio [EMAIL PROTECTED] wrote: Ok then for the time being, let me then follow the same dir structure and use ant to get things moving. Are you ok with that? Soumadeep - Original Message - From: Guillaume Nodet [EMAIL PROTECTED] To: servicemix-dev@geronimo.apache.org Sent: Thursday, August 03, 2006 7:15 PM Subject: Re: creating a standard JBI Component using servicemix-common module Yeah, unfortunately, I don't think this is currently possible with maven archetypes :( Unless someone know a way to generate new files from velocity templates. On 8/3/06, Soumadeep-Infravio [EMAIL PROTECTED] wrote: Not a good idea to refactor the class names, like I said - changing to BAMxxx, I think it's better to change the filenames in the template. The reason is there are a whole lot of xml and xsds which refer to the java classes... your thoughts.. Soumadeep - Original Message - From: Soumadeep-Infravio [EMAIL PROTECTED] To: servicemix-dev@geronimo.apache.org Sent: Thursday, August 03, 2006 6:08 PM Subject: Re: creating a standard JBI Component using servicemix-common module Yup.. the classpath variable in Eclipse. I am changing the classes to BAMxxx Thanks Soumadeep - Original Message - From: Guillaume Nodet [EMAIL PROTECTED] To: servicemix-dev@geronimo.apache.org Sent: Thursday, August 03, 2006 5:47 PM Subject: Re: creating a standard JBI Component using servicemix-common module Have you defined the property M2_REPO in Eclipse ? On 8/3/06, Soumadeep-Infravio [EMAIL PROTECTED] wrote: Resolved it... problem with classpath. It created two eclipse related files 1) .project 2) .classpath The problem is when I import this project into Eclipse it doesn't resolve the classapth. Do I need to do anything else? Thanks Soumadeep - Original Message - From: Guillaume Nodet [EMAIL PROTECTED] To: servicemix-dev@geronimo.apache.org Sent: Thursday, August 03, 2006 3:11 PM Subject: Re: creating a standard JBI Component using servicemix-common module What do you mean by not OK ? On 8/3/06, Soumadeep-Infravio [EMAIL PROTECTED] wrote: Guillaume, I guess I got past this by re-building smx. What I am stuck with now is that eclipse is complaining that the project that was created using the command mvn eclipse:eclipse is not OK. Have you tried doing it lately? Thanks Soumadeep - Original Message - From: Guillaume Nodet [EMAIL PROTECTED] To: servicemix-dev@geronimo.apache.org Sent: Thursday, August 03, 2006 2:40 PM Subject: Re: creating a standard JBI Component using servicemix-common module You can also download the archetype from http://people.apache.org/maven-snapshot-repository/org/apache/servicemix/tooling/servicemix-service-engine/1.0-incubating-SNAPSHOT/servicemix-service-engine-1.0-incubating-20060803.064327-5.jar and put it in your local maven repo under ~/.m2/org/apache/servicemix/tooling/servicemix-service-engine/1.0-incubating-SNAPSHOT It should also work. On 8/3/06, Guillaume Nodet [EMAIL PROTECTED] wrote: We currently have problems uploading snapshots. Even in this case, as they are not on public repositories, I'm not sure it would work. The best way would be to build ServiceMix from sources, as the archetypes will be in your local repository. On 8/3/06, vikas kumar [EMAIL PROTECTED] wrote: Hi Guillaume/All, Tried creating a standard JBI Component using servicemix-common module. I followed the steps written in http://servicemix.org/site/creating-a-standard-jbi-component.html On executing the command mvn archetype:create \ -DarchetypeGroupId=org.apache.servicemix.tooling \ -DarchetypeArtifactId=servicemix-service-engine \ -DarchetypeVersion=1.0-incubating-SNAPSHOT \ -DgroupId=org.apache.servicemix.xslt \ -DartifactId=servicemix-xslt I got the following error: [ERROR] ResourceManager : unable to find resource 'VM_global_library.vm' in any resource loader. [INFO] Velocimacro : error using VM library template VM_global_library.vm : org .apache.velocity.exception.ResourceNotFoundException: Unable to find resource 'V M_global_library.vm' [INFO] Velocimacro : VM library template macro registration complete. [INFO] Velocimacro : allowInline = true : VMs can be defined inline in templates [INFO] Velocimacro : allowInlineToOverride = false : VMs defined inline may NOT
Re: creating a standard JBI Component using servicemix-common module
I believe the only XML change after refactoring the class names is to change the pom.xml entries for the component class name (towards the end) P On 8/3/06, Guillaume Nodet [EMAIL PROTECTED] wrote: If you have renamed the file, where is your problem ? Using eclipse, you can easily refactor the code and it will change everything needed (at least in java files). I don' t how using ant will help you on that. On 8/3/06, Soumadeep-Infravio [EMAIL PROTECTED] wrote: Ok then for the time being, let me then follow the same dir structure and use ant to get things moving. Are you ok with that? Soumadeep - Original Message - From: Guillaume Nodet [EMAIL PROTECTED] To: servicemix-dev@geronimo.apache.org Sent: Thursday, August 03, 2006 7:15 PM Subject: Re: creating a standard JBI Component using servicemix-common module Yeah, unfortunately, I don't think this is currently possible with maven archetypes :( Unless someone know a way to generate new files from velocity templates. On 8/3/06, Soumadeep-Infravio [EMAIL PROTECTED] wrote: Not a good idea to refactor the class names, like I said - changing to BAMxxx, I think it's better to change the filenames in the template. The reason is there are a whole lot of xml and xsds which refer to the java classes... your thoughts.. Soumadeep - Original Message - From: Soumadeep-Infravio [EMAIL PROTECTED] To: servicemix-dev@geronimo.apache.org Sent: Thursday, August 03, 2006 6:08 PM Subject: Re: creating a standard JBI Component using servicemix-common module Yup.. the classpath variable in Eclipse. I am changing the classes to BAMxxx Thanks Soumadeep - Original Message - From: Guillaume Nodet [EMAIL PROTECTED] To: servicemix-dev@geronimo.apache.org Sent: Thursday, August 03, 2006 5:47 PM Subject: Re: creating a standard JBI Component using servicemix-common module Have you defined the property M2_REPO in Eclipse ? On 8/3/06, Soumadeep-Infravio [EMAIL PROTECTED] wrote: Resolved it... problem with classpath. It created two eclipse related files 1) .project 2) .classpath The problem is when I import this project into Eclipse it doesn't resolve the classapth. Do I need to do anything else? Thanks Soumadeep - Original Message - From: Guillaume Nodet [EMAIL PROTECTED] To: servicemix-dev@geronimo.apache.org Sent: Thursday, August 03, 2006 3:11 PM Subject: Re: creating a standard JBI Component using servicemix-common module What do you mean by not OK ? On 8/3/06, Soumadeep-Infravio [EMAIL PROTECTED] wrote: Guillaume, I guess I got past this by re-building smx. What I am stuck with now is that eclipse is complaining that the project that was created using the command mvn eclipse:eclipse is not OK. Have you tried doing it lately? Thanks Soumadeep - Original Message - From: Guillaume Nodet [EMAIL PROTECTED] To: servicemix-dev@geronimo.apache.org Sent: Thursday, August 03, 2006 2:40 PM Subject: Re: creating a standard JBI Component using servicemix-common module You can also download the archetype from http://people.apache.org/maven-snapshot-repository/org/apache/servicemix/tooling/servicemix-service-engine/1.0-incubating-SNAPSHOT/servicemix-service-engine-1.0-incubating-20060803.064327-5.jar and put it in your local maven repo under ~/.m2/org/apache/servicemix/tooling/servicemix-service-engine/1.0-incubating-SNAPSHOT It should also work. On 8/3/06, Guillaume Nodet [EMAIL PROTECTED] wrote: We currently have problems uploading snapshots. Even in this case, as they are not on public repositories, I'm not sure it would work. The best way would be to build ServiceMix from sources, as the archetypes will be in your local repository. On 8/3/06, vikas kumar [EMAIL PROTECTED] wrote: Hi Guillaume/All, Tried creating a standard JBI Component using servicemix-common module. I followed the steps written in http://servicemix.org/site/creating-a-standard-jbi-component.html On executing the command mvn archetype:create \ -DarchetypeGroupId=org.apache.servicemix.tooling\ -DarchetypeArtifactId=servicemix-service-engine \ -DarchetypeVersion=1.0-incubating-SNAPSHOT \ -DgroupId=org.apache.servicemix.xslt \ -DartifactId=servicemix-xslt I got the following error: [ERROR] ResourceManager : unable to find resource 'VM_global_library.vm' in any resource loader. [INFO] Velocimacro : error using VM library template VM_global_library.vm : org
Re: creating a standard JBI Component using servicemix-common module
Refactoring is done... no issues... just wasn't sure about the xmls...:-) Will give it a try if mvn install still works then I guess all is OK - Original Message - From: Guillaume Nodet [EMAIL PROTECTED] To: servicemix-dev@geronimo.apache.org Sent: Thursday, August 03, 2006 11:03 PM Subject: Re: creating a standard JBI Component using servicemix-common module If you have renamed the file, where is your problem ? Using eclipse, you can easily refactor the code and it will change everything needed (at least in java files). I don' t how using ant will help you on that. On 8/3/06, Soumadeep-Infravio [EMAIL PROTECTED] wrote: Ok then for the time being, let me then follow the same dir structure and use ant to get things moving. Are you ok with that? Soumadeep - Original Message - From: Guillaume Nodet [EMAIL PROTECTED] To: servicemix-dev@geronimo.apache.org Sent: Thursday, August 03, 2006 7:15 PM Subject: Re: creating a standard JBI Component using servicemix-common module Yeah, unfortunately, I don't think this is currently possible with maven archetypes :( Unless someone know a way to generate new files from velocity templates. On 8/3/06, Soumadeep-Infravio [EMAIL PROTECTED] wrote: Not a good idea to refactor the class names, like I said - changing to BAMxxx, I think it's better to change the filenames in the template. The reason is there are a whole lot of xml and xsds which refer to the java classes... your thoughts.. Soumadeep - Original Message - From: Soumadeep-Infravio [EMAIL PROTECTED] To: servicemix-dev@geronimo.apache.org Sent: Thursday, August 03, 2006 6:08 PM Subject: Re: creating a standard JBI Component using servicemix-common module Yup.. the classpath variable in Eclipse. I am changing the classes to BAMxxx Thanks Soumadeep - Original Message - From: Guillaume Nodet [EMAIL PROTECTED] To: servicemix-dev@geronimo.apache.org Sent: Thursday, August 03, 2006 5:47 PM Subject: Re: creating a standard JBI Component using servicemix-common module Have you defined the property M2_REPO in Eclipse ? On 8/3/06, Soumadeep-Infravio [EMAIL PROTECTED] wrote: Resolved it... problem with classpath. It created two eclipse related files 1) .project 2) .classpath The problem is when I import this project into Eclipse it doesn't resolve the classapth. Do I need to do anything else? Thanks Soumadeep - Original Message - From: Guillaume Nodet [EMAIL PROTECTED] To: servicemix-dev@geronimo.apache.org Sent: Thursday, August 03, 2006 3:11 PM Subject: Re: creating a standard JBI Component using servicemix-common module What do you mean by not OK ? On 8/3/06, Soumadeep-Infravio [EMAIL PROTECTED] wrote: Guillaume, I guess I got past this by re-building smx. What I am stuck with now is that eclipse is complaining that the project that was created using the command mvn eclipse:eclipse is not OK. Have you tried doing it lately? Thanks Soumadeep - Original Message - From: Guillaume Nodet [EMAIL PROTECTED] To: servicemix-dev@geronimo.apache.org Sent: Thursday, August 03, 2006 2:40 PM Subject: Re: creating a standard JBI Component using servicemix-common module You can also download the archetype from http://people.apache.org/maven-snapshot-repository/org/apache/servicemix/tooling/servicemix-service-engine/1.0-incubating-SNAPSHOT/servicemix-service-engine-1.0-incubating-20060803.064327-5.jar and put it in your local maven repo under ~/.m2/org/apache/servicemix/tooling/servicemix-service-engine/1.0-incubating-SNAPSHOT It should also work. On 8/3/06, Guillaume Nodet [EMAIL PROTECTED] wrote: We currently have problems uploading snapshots. Even in this case, as they are not on public repositories, I'm not sure it would work. The best way would be to build ServiceMix from sources, as the archetypes will be in your local repository. On 8/3/06, vikas kumar [EMAIL PROTECTED] wrote: Hi Guillaume/All, Tried creating a standard JBI Component using servicemix-common module. I followed the steps written in http://servicemix.org/site/creating-a-standard-jbi-component.html On executing the command mvn archetype:create \ -DarchetypeGroupId=org.apache.servicemix.tooling \ -DarchetypeArtifactId=servicemix-service-engine \ -DarchetypeVersion=1.0-incubating-SNAPSHOT \ -DgroupId=org.apache.servicemix.xslt \ -DartifactId=servicemix-xslt I got the following error: [ERROR] ResourceManager : unable to find resource 'VM_global_library.vm' in any resource loader. [INFO] Velocimacro : error using VM library template VM_global_library.vm : org
Re: creating a standard JBI Component using servicemix-common module
cool... let me change and see... - Original Message - From: Philip Dodds [EMAIL PROTECTED] To: servicemix-dev@geronimo.apache.org Sent: Thursday, August 03, 2006 11:05 PM Subject: Re: creating a standard JBI Component using servicemix-common module I believe the only XML change after refactoring the class names is to change the pom.xml entries for the component class name (towards the end) P On 8/3/06, Guillaume Nodet [EMAIL PROTECTED] wrote: If you have renamed the file, where is your problem ? Using eclipse, you can easily refactor the code and it will change everything needed (at least in java files). I don' t how using ant will help you on that. On 8/3/06, Soumadeep-Infravio [EMAIL PROTECTED] wrote: Ok then for the time being, let me then follow the same dir structure and use ant to get things moving. Are you ok with that? Soumadeep - Original Message - From: Guillaume Nodet [EMAIL PROTECTED] To: servicemix-dev@geronimo.apache.org Sent: Thursday, August 03, 2006 7:15 PM Subject: Re: creating a standard JBI Component using servicemix-common module Yeah, unfortunately, I don't think this is currently possible with maven archetypes :( Unless someone know a way to generate new files from velocity templates. On 8/3/06, Soumadeep-Infravio [EMAIL PROTECTED] wrote: Not a good idea to refactor the class names, like I said - changing to BAMxxx, I think it's better to change the filenames in the template. The reason is there are a whole lot of xml and xsds which refer to the java classes... your thoughts.. Soumadeep - Original Message - From: Soumadeep-Infravio [EMAIL PROTECTED] To: servicemix-dev@geronimo.apache.org Sent: Thursday, August 03, 2006 6:08 PM Subject: Re: creating a standard JBI Component using servicemix-common module Yup.. the classpath variable in Eclipse. I am changing the classes to BAMxxx Thanks Soumadeep - Original Message - From: Guillaume Nodet [EMAIL PROTECTED] To: servicemix-dev@geronimo.apache.org Sent: Thursday, August 03, 2006 5:47 PM Subject: Re: creating a standard JBI Component using servicemix-common module Have you defined the property M2_REPO in Eclipse ? On 8/3/06, Soumadeep-Infravio [EMAIL PROTECTED] wrote: Resolved it... problem with classpath. It created two eclipse related files 1) .project 2) .classpath The problem is when I import this project into Eclipse it doesn't resolve the classapth. Do I need to do anything else? Thanks Soumadeep - Original Message - From: Guillaume Nodet [EMAIL PROTECTED] To: servicemix-dev@geronimo.apache.org Sent: Thursday, August 03, 2006 3:11 PM Subject: Re: creating a standard JBI Component using servicemix-common module What do you mean by not OK ? On 8/3/06, Soumadeep-Infravio [EMAIL PROTECTED] wrote: Guillaume, I guess I got past this by re-building smx. What I am stuck with now is that eclipse is complaining that the project that was created using the command mvn eclipse:eclipse is not OK. Have you tried doing it lately? Thanks Soumadeep - Original Message - From: Guillaume Nodet [EMAIL PROTECTED] To: servicemix-dev@geronimo.apache.org Sent: Thursday, August 03, 2006 2:40 PM Subject: Re: creating a standard JBI Component using servicemix-common module You can also download the archetype from http://people.apache.org/maven-snapshot-repository/org/apache/servicemix/tooling/servicemix-service-engine/1.0-incubating-SNAPSHOT/servicemix-service-engine-1.0-incubating-20060803.064327-5.jar and put it in your local maven repo under ~/.m2/org/apache/servicemix/tooling/servicemix-service-engine/1.0-incubating-SNAPSHOT It should also work. On 8/3/06, Guillaume Nodet [EMAIL PROTECTED] wrote: We currently have problems uploading snapshots. Even in this case, as they are not on public repositories, I'm not sure it would work. The best way would be to build ServiceMix from sources, as the archetypes will be in your local repository. On 8/3/06, vikas kumar [EMAIL PROTECTED] wrote: Hi Guillaume/All, Tried creating a standard JBI Component using servicemix-common module. I followed the steps written in http://servicemix.org/site/creating-a-standard-jbi-component.html On executing the command mvn archetype:create \ -DarchetypeGroupId=org.apache.servicemix.tooling\ -DarchetypeArtifactId=servicemix-service-engine \ -DarchetypeVersion=1.0-incubating-SNAPSHOT \ -DgroupId=org.apache.servicemix.xslt \ -DartifactId=servicemix-xslt
Re: Redeploy problems in branches/1.1.1
Aaron, I missed the cut off for 1.1.1 on the three JIRA's I had. I'll move the remaining 1.1.1s to 1.1.2 and then we'll cut a 1.1.2 a few weeks after 1.1.1. Perhaps this is the start of the fast and furious release cycle that Hiram loves so much :) Dain Sundstrom wrote: On Aug 3, 2006, at 9:18 AM, Aaron Mulder wrote: I think this is a blocker. I tried redeploying a web application, both with and without a version in the module ID. It failed both ways, though differently for each. Matt, do you mind if we work on this in the 1.1.1 branch? I'd say it should be worked on in 1.1.2. Dain or David Jencks, any chance you could look at the without a version in the module ID case? It complained about a dead proxy when Spring accessed a JDBC pool at java:comp/env/jdbc/DataSource during startup of the new version (GERONIMO-2269) Thanks, Aaron http://issues.apache.org/jira/browse/GERONIMO-2269 My guess is this one is a side effect of the next one, so I'd fix 2270 first and rerun this test case. http://issues.apache.org/jira/browse/GERONIMO-2270 Didn't you write the redeploy code? -dain
Re: HotDeployer causing OutOfMemory error on repeated use
Yes, Kevan addresses a memory leak within the last two days. Try it on branches/1.1.1 or the current branches/1.1 (which is now 1.2-SNAPSHOT). Vamsavardhana Reddy wrote: I am using HotDeployer extensively. After repeated use, the server is running into memory problems. I have built the server from branches/1.1. The last time I updated my source tree is two days ago. Has this problem been addressed in the past two days? Regards, Vamsi
[jira] Updated: (GERONIMODEVTOOLS-93) Support for non-plugin archives for installable runtimes
[ http://issues.apache.org/jira/browse/GERONIMODEVTOOLS-93?page=all ] Sachin Patel updated GERONIMODEVTOOLS-93: - Patch Info: [Patch Available] Issue Type: RTC (was: Improvement) Support for non-plugin archives for installable runtimes Key: GERONIMODEVTOOLS-93 URL: http://issues.apache.org/jira/browse/GERONIMODEVTOOLS-93 Project: Geronimo-Devtools Issue Type: RTC Components: eclipse-plugin Affects Versions: 1.1.0 Reporter: Sachin Patel Assigned To: Sachin Patel Fix For: 1.1.0 Attachments: GERONIMODEVTOOLS-93.patch With the following support in wtp 1.5.1 https://bugs.eclipse.org/bugs/show_bug.cgi?id=125385 need to rid of the installable runtime plugins that wrap the entire appserver and replace them with data archives in the feature that reference the geronimo binary distributions directly -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (GERONIMODEVTOOLS-93) Support for non-plugin archives for installable runtimes
[ http://issues.apache.org/jira/browse/GERONIMODEVTOOLS-93?page=all ] Sachin Patel updated GERONIMODEVTOOLS-93: - Attachment: GERONIMODEVTOOLS-93.patch Support for non-plugin archives for installable runtimes Key: GERONIMODEVTOOLS-93 URL: http://issues.apache.org/jira/browse/GERONIMODEVTOOLS-93 Project: Geronimo-Devtools Issue Type: RTC Components: eclipse-plugin Affects Versions: 1.1.0 Reporter: Sachin Patel Assigned To: Sachin Patel Fix For: 1.1.0 Attachments: GERONIMODEVTOOLS-93.patch With the following support in wtp 1.5.1 https://bugs.eclipse.org/bugs/show_bug.cgi?id=125385 need to rid of the installable runtime plugins that wrap the entire appserver and replace them with data archives in the feature that reference the geronimo binary distributions directly -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (GERONIMO-2270) Redeploy broken in 1.1.1
[ http://issues.apache.org/jira/browse/GERONIMO-2270?page=all ] Aaron Mulder updated GERONIMO-2270: --- Attachment: 2270-fix-redeploy-no-type.patch Here's a patch that can be applied to branches/1.1.1 to fix this problem Already applied to branches/1.1 Redeploy broken in 1.1.1 Key: GERONIMO-2270 URL: http://issues.apache.org/jira/browse/GERONIMO-2270 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: deployment Affects Versions: 1.1.1 Reporter: Aaron Mulder Priority: Blocker Fix For: 1.1.1 Attachments: 2270-fix-redeploy-no-type.patch Tried to redeploy a WAR in 1.1.1. Got the following (note, I did actually redeploy): No ModuleID or TargetModuleID provided. Attempting to guess based on the content of the archive. Attempting to use ModuleID 'aaron/IIIQuotes/1.0/' Error: Operation failed: Module aaron/IIIQuotes/1.0/war already exists in the server. Try to undeploy it first or use the redeploy command. Appears to happen when the moduleId includes a group/artifact/version but no type. Did not happen when all of group, artifact, version, and type were specified. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (GERONIMO-2272) Fix bad javamail version in
Fix bad javamail version in Key: GERONIMO-2272 URL: http://issues.apache.org/jira/browse/GERONIMO-2272 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Affects Versions: 1.2 Reporter: Kevan Miller Assigned To: Kevan Miller Fix For: 1.2 explicit_versions.properties has 1.1 specified for the javamail spec version. It should be 1.2-SNAPSHOT -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Redeploy problems in branches/1.1.1
Dain, I fixed GERONIMO-2270 (redeploy when module ID includes version but not type) but this did not fix GERONIMO-2269 (redeploy with resource-ref when module ID includes artifact only). There's a stack trace in the Jira -- any suggestions on how to pursue it? http://issues.apache.org/jira/browse/GERONIMO-2269 Matt, I was assuming the point of branches and RC builds was to test for obvious problems, and I think the deploy tool is fairly central to the user experience, and since we appear to have some TCK issues anyway... Well, whatever, I attached the patch to GERONIMO-2270 and you can apply it or not as you see fit. Thanks, Aaron On 8/3/06, Matt Hogstrom [EMAIL PROTECTED] wrote: Aaron, I missed the cut off for 1.1.1 on the three JIRA's I had. I'll move the remaining 1.1.1s to 1.1.2 and then we'll cut a 1.1.2 a few weeks after 1.1.1. Perhaps this is the start of the fast and furious release cycle that Hiram loves so much :) Dain Sundstrom wrote: On Aug 3, 2006, at 9:18 AM, Aaron Mulder wrote: I think this is a blocker. I tried redeploying a web application, both with and without a version in the module ID. It failed both ways, though differently for each. Matt, do you mind if we work on this in the 1.1.1 branch? I'd say it should be worked on in 1.1.2. Dain or David Jencks, any chance you could look at the without a version in the module ID case? It complained about a dead proxy when Spring accessed a JDBC pool at java:comp/env/jdbc/DataSource during startup of the new version (GERONIMO-2269) Thanks, Aaron http://issues.apache.org/jira/browse/GERONIMO-2269 My guess is this one is a side effect of the next one, so I'd fix 2270 first and rerun this test case. http://issues.apache.org/jira/browse/GERONIMO-2270 Didn't you write the redeploy code? -dain
[jira] Commented: (GERONIMO-2269) Error after redeploy (with no version in module ID) (branches/1.1.1)
[ http://issues.apache.org/jira/browse/GERONIMO-2269?page=comments#action_12425585 ] Aaron Mulder commented on GERONIMO-2269: Maybe caused by the JNDI reference (a ConfigurationAwareReference) having the wrong Configuration set on it? That is, the ConfigurationAwareReference has the web app module ID with the old version instead of the web app module ID with the new version? Error after redeploy (with no version in module ID) (branches/1.1.1) Key: GERONIMO-2269 URL: http://issues.apache.org/jira/browse/GERONIMO-2269 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: deployment, kernel Affects Versions: 1.1.1 Reporter: Aaron Mulder Fix For: 1.1.x I deployed a web application (including a resource-ref to a database pool) successfully, with a module ID containing only an artifact element. I changed the web.xml and redeployed it. It failed due to a syntax error in web.xml (I changed the login page to not start with a / and it complained; apparently the / is necessary). The application still appeared to be running, though I didn't test it. I fixed the web.xml and redeployed it. It failed with the following error. It seems that after the redeploy the JNDI entry for the data source was invalid? UPDATE: a simple redeploy of the working application causes the error -- it's not necessary to have the failed redeploy in between. 11:57:44,865 ERROR [ContextLoader] Context initialization failed org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'DataSource' defined in resource [/WEB-INF/applicationContext.xml] of ServletContext: Initialization of bean failed; nested exception is javax.naming.NamingException: Could not look up : env/jdbc/Database javax.naming.NamingException: Could not look up : env/jdbc/Database [Root exception is org.apache.geronimo.kernel.proxy.DeadProxyException: Proxy is no longer valid] at org.apache.geronimo.naming.enc.CachingReference.resolveReference(CachingReference.java:59) at org.apache.geronimo.naming.enc.CachingReference.get(CachingReference.java:45) at org.apache.geronimo.naming.enc.AbstractReadOnlyContext.lookup(AbstractReadOnlyContext.java:86) at org.apache.geronimo.naming.java.RootContext.lookup(RootContext.java:51) at javax.naming.InitialContext.lookup(InitialContext.java:347) at org.springframework.jndi.JndiTemplate$1.doInContext(JndiTemplate.java:120) at org.springframework.jndi.JndiTemplate.execute(JndiTemplate.java:85) at org.springframework.jndi.JndiTemplate.lookup(JndiTemplate.java:117) at org.springframework.jndi.AbstractJndiLocator.lookup(AbstractJndiLocator.java:181) at org.springframework.jndi.AbstractJndiLocator.afterPropertiesSet(AbstractJndiLocator.java:171) at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.invokeInitMethods(AbstractAutowireCapableBeanFactory.java:801) at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:249) at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:177) at org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:159) at org.springframework.beans.factory.support.DefaultListableBeanFactory.preInstantiateSingletons(DefaultListableBeanFactory.java:177) at org.springframework.context.support.AbstractApplicationContext.refresh(AbstractApplicationContext.java:268) at org.springframework.web.context.support.XmlWebApplicationContext.refresh(XmlWebApplicationContext.java:131) at org.springframework.web.context.ContextLoader.createWebApplicationContext(ContextLoader.java:156) at org.springframework.web.context.ContextLoader.initWebApplicationContext(ContextLoader.java:97) at org.springframework.web.context.ContextLoaderListener.contextInitialized(ContextLoaderListener.java:48) at org.mortbay.jetty.servlet.WebApplicationContext.doStart(WebApplicationContext.java:495) at org.apache.geronimo.jetty.JettyWebAppContext.doStart(JettyWebAppContext.java:401) at org.mortbay.util.Container.start(Container.java:72) at org.apache.geronimo.jetty.JettyWebAppContext.doStart(JettyWebAppContext.java:389) at org.apache.geronimo.gbean.runtime.GBeanInstance.createInstance(GBeanInstance.java:981) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStart(GBeanInstanceState.java:267) at
[jira] Resolved: (GERONIMO-2272) Fix bad javamail version in
[ http://issues.apache.org/jira/browse/GERONIMO-2272?page=all ] Kevan Miller resolved GERONIMO-2272. Resolution: Fixed Updated explicit_versions.properties to specify 1.2-SNAPSHOT as the appropriate version for the javamail spec. Fix bad javamail version in --- Key: GERONIMO-2272 URL: http://issues.apache.org/jira/browse/GERONIMO-2272 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Affects Versions: 1.2 Reporter: Kevan Miller Assigned To: Kevan Miller Fix For: 1.2 explicit_versions.properties has 1.1 specified for the javamail spec version. It should be 1.2-SNAPSHOT -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (GERONIMO-2272) Fix bad javamail version in explicit_versions.properties
[ http://issues.apache.org/jira/browse/GERONIMO-2272?page=all ] Kevan Miller updated GERONIMO-2272: --- Summary: Fix bad javamail version in explicit_versions.properties (was: Fix bad javamail version in) Fix bad javamail version in explicit_versions.properties Key: GERONIMO-2272 URL: http://issues.apache.org/jira/browse/GERONIMO-2272 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Affects Versions: 1.2 Reporter: Kevan Miller Assigned To: Kevan Miller Fix For: 1.2 explicit_versions.properties has 1.1 specified for the javamail spec version. It should be 1.2-SNAPSHOT -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Creating a secure connection system and using JMSXUserID support
Hi Sepand, 4.1 and 4.0 branches are not that different yet. If you need your solution for 4.0, go ahead and do it. Chances are we will only apply it only to 4.1 (since this a new feature). On 8/3/06, Sepand M [EMAIL PROTECTED] wrote: Thanks Hiram. That sounds great. I guess my last question is: what branch do I work off of? Personally, I would like to build my stuff on a stable release (4.0.1), but I've looked at the svn logs and you guys seem to be pretty active around the stuff I want to change so I'm not sure how my changes could be reintegrated once I'm done. Any thoughts? On 8/3/06, Hiram Chirino [EMAIL PROTECTED] wrote: Sepand, Do what you need to to get you project done, you cand send us tidbit as you get it done and we can work on merging it back to the main branch. The great thing is that you have a use case that we want to support, so if you put something together that work for you, I don't see why it would not just go whole hog into the main branch. On 8/3/06, Sepand M [EMAIL PROTECTED] wrote: Hi guys, Here are a few things: 1) I cannot use LDAP. We don't use it now, and don't want to later. I understand if you want to use it, but I can't. 2) From what I understand (and my understanding isn't too bad at this point), SSL sockets with needClientAuth just verify the client's cert against the CA. This means that the socket only does authentication and the rest is up to the broker (which seems perfect). 3) The other ideas we're getting like separating the user from the connection (which I don't fully understand) seem like they are overkill. To be done properly, they would need significant (not drastic, but significant) architectural rework (look at things like UserIDBroker, and how the user ID is currently obtained from the connection with the producer ID registration stuff) and are fairly independent of the SSL thing. Yeah I think this is overkill too. So here's my plan: I want to implement my original idea (it's in this thread a few posts up) with (at most) the addition of a subject/principal back end for authorization. I say at most because I've been working on my idea for a while and know exactly how to do it; adding the subject/principal thing is a good design choice but I'm hesitant to persue it since I don't know much about it and I have a deadline (and therefore, would rather avoid having to read about it). If someone knows their stuff regarding to JAAS and is willing to work on it, I would be very glad to incorporate that into the design. If not, I must begin working on my implementation by the end of the week (hopefully sooner). I would *REALLY* like to work with you guys, but I have deadlines to meet. I would also hate it if my work didn't make it into the project's main branch, but I would totally understand if you decided to go with your own ideas. On 8/3/06, Hiram Chirino [EMAIL PROTECTED] wrote: On 8/3/06, David Jencks [EMAIL PROTECTED] wrote: On Aug 2, 2006, at 4:35 PM, Sepand M wrote: Ok. So from what I've read, we're trying to separate the authorization part from the SSL socket and let the broker handle it. This sounds great. It would take more work (not so great since I have a deadline), but it would be a proper solution. From what I know of JAAS, the subject/principals fully represent identity. So attaching them to Connection info would be a good idea. That way, the Transport's job would be to authenticate and the Broker could handle authorization completely. This would also mean that any communication system could be used without having to change the Broker (as long as the Transport can authenticate and create proper subjet/principals). The one thing I will note is that we are changing the ActiveMQ architecture in that currently, the Brokers are doing both authentication and authorization (e.g. The Brokers are currently doing the user name and password validation). I think, however, that this is necessary because without our change, there would need to be a new broker for every new, authenticated, communication system. Please tell me if you agree (in which case I'll start looking at implementation details). I thought about this some more and wonder if it would be appropriate to consider using the full corba csiv2 framework or a reasonable facsimile. I think it would. Very briefly here is what it gives you: -both ends of the communication channel have policies specifying what they can provide and require for security: they negotiate a common policy. The policy can specify: - security level of channel (basically unprotected or ssl) - validation of identity of server and client, by user/pw or certificate chain - validation of identity of user by a variety of mechanisms including user/pw,
Wiki migration
Hi All, I've been reviewing the content we have in the Moin Moin wiki and it is way more out of date than I thought it would be. I initially thought that it would be easier to do the housekeeping once we had the content migrated to Confluence but after a more detailed analysis of the actual content to migrate I found out that there is really little content to move over. This is either because we already have that content categorized and up to date or the Moin Moin content is so out of date that is not relevant anymore. So, did some cleaning and detailed review of the Moin Moin content ( thanks Jason for helping with Moin Moin ;-) ), ran the migration again (thanks Don for providing the migration tools and continuous support) and came up with a very reduced list of pages that, IMHO, should actually be migrated and integrated to the current cwiki. These pages are listed in the yellow box at the top of the front page, here is the link to the partially migrated space. http://cwiki.apache.org/confluence/display/GMOxMoinMoin I know we all focused on getting v1.1.1 out of the door now so how about time to review it untill next Friday Aug 11. Not sure if this calls for a vote ( we kinda did that already) but if there are not -1/negative comments I would propose to give wiki.apache.org/geronimo a proper burial and get it out of production. If anybody thinks that any other page should be included pls send me the page name (and link) and we'll review it. Thanks Cheers! Hernan
Re: Wiki migration
I don't seem to have the permissions to view that space. -dain On Aug 3, 2006, at 11:34 AM, Hernan Cunico wrote: Hi All, I've been reviewing the content we have in the Moin Moin wiki and it is way more out of date than I thought it would be. I initially thought that it would be easier to do the housekeeping once we had the content migrated to Confluence but after a more detailed analysis of the actual content to migrate I found out that there is really little content to move over. This is either because we already have that content categorized and up to date or the Moin Moin content is so out of date that is not relevant anymore. So, did some cleaning and detailed review of the Moin Moin content ( thanks Jason for helping with Moin Moin ;-) ), ran the migration again (thanks Don for providing the migration tools and continuous support) and came up with a very reduced list of pages that, IMHO, should actually be migrated and integrated to the current cwiki. These pages are listed in the yellow box at the top of the front page, here is the link to the partially migrated space. http://cwiki.apache.org/confluence/display/GMOxMoinMoin I know we all focused on getting v1.1.1 out of the door now so how about time to review it untill next Friday Aug 11. Not sure if this calls for a vote ( we kinda did that already) but if there are not -1/negative comments I would propose to give wiki.apache.org/ geronimo a proper burial and get it out of production. If anybody thinks that any other page should be included pls send me the page name (and link) and we'll review it. Thanks Cheers! Hernan
[jira] Commented: (GERONIMO-1700) NPE on tomcat when deploying same application more than once.
[ http://issues.apache.org/jira/browse/GERONIMO-1700?page=comments#action_12425589 ] Manu T George commented on GERONIMO-1700: - This error occurs because two different apps (with different configIds) have the same context root. If you have wo different apps with the same context root then also this error occurs. One solution could be to fail the deployment with an appropriate message. Another one would be to fail the startup as it happens now with a more meaningful message like this Another application with the same context root 'context-root' is already running. Please stop that application first. NPE on tomcat when deploying same application more than once. - Key: GERONIMO-1700 URL: http://issues.apache.org/jira/browse/GERONIMO-1700 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: deployment Affects Versions: 1.2 Environment: windows xp, tomcat server Reporter: Joe Bohn Priority: Minor Fix For: 1.1.x Attachments: 1700_DuplicateDeploy.patch Scenario: Deploy a web app (in my case snoop) to the tomcat server. All appears to go well. Attempt to deploy the same application again and the following NPE is produced. In addition it seems that the old application remains running and the newer application is stopped. I'm not sure if that is the desired behavior or not, but I would have expected the opposite. It seems that we should either fail the deployment (preferrably w/o a NPE) or permit it to succeed but notify the user that a newer version of an earlier application is being installed. I also noticed that if the deployment is via the web console then there is no notification given to the user that the deployment failed (it actually indicates that it succeeded). 11:08:26,765 ERROR [GBeanInstance] Problem in doFail of default/snoop/1151420905312/war?J2EEApplication=null,j2eeType=WebModule,name=default/snoop/1151420905312 /war java.lang.RuntimeException: java.lang.NullPointerException at org.apache.geronimo.tomcat.TomcatContainer.removeContext(TomcatContainer.java:327) at org.apache.geronimo.tomcat.TomcatContainer$$FastClassByCGLIB$$9370b073.invoke(generated) at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53) at org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38) at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:122) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:817) at org.apache.geronimo.gbean.runtime.RawInvoker.invoke(RawInvoker.java:57) at org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke(RawOperationInvoker.java:35) at org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept(ProxyMethodInterceptor.java:96) at org.apache.geronimo.tomcat.TomcatContainer$$EnhancerByCGLIB$$fad085bb.removeContext(generated) at org.apache.geronimo.tomcat.TomcatWebAppContext.doFail(TomcatWebAppContext.java:469) at org.apache.geronimo.gbean.runtime.GBeanInstance.createInstance(GBeanInstance.java:1010) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStart(GBeanInstanceState.java:267) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.start(GBeanInstanceState.java:102) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.startRecursive(GBeanInstanceState.java:124) at org.apache.geronimo.gbean.runtime.GBeanInstance.startRecursive(GBeanInstance.java:540) at org.apache.geronimo.kernel.basic.BasicKernel.startRecursiveGBean(BasicKernel.java:379) at org.apache.geronimo.kernel.config.ConfigurationUtil.startConfigurationGBeans(ConfigurationUtil.java:374) at org.apache.geronimo.kernel.config.KernelConfigurationManager.start(KernelConfigurationManager.java:187) at org.apache.geronimo.kernel.config.SimpleConfigurationManager.startConfiguration(SimpleConfigurationManager.java:512) at org.apache.geronimo.kernel.config.SimpleConfigurationManager.startConfiguration(SimpleConfigurationManager.java:493) at org.apache.geronimo.kernel.config.SimpleConfigurationManager$$FastClassByCGLIB$$ce77a924.invoke(generated) at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53) at org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38) at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:122) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:817) at
Re: [Discussion] Removal of TransactionContextManager
+1 great job dain. This is a great move toward making geronimo components more decoupled and more re-usable. On 7/31/06, Dain Sundstrom [EMAIL PROTECTED] wrote: history length=too long About a week ago there was a discussion on the OpenEJB mailing list regarding the TransactionContextManager. In OpenEJB 3 we removed the use of the TCM from Geronimo and replaced it with just a javax.transaction.TransactionManager. This brought all of the openejb containers into alignment. The other big motivation was to ease the integration of OpenEJB and third part libraries, specifically Spring. The problem with the TCM is that if you use it you can't use the TM directly since the TCM needs to know about all TM calls. Additionally, to use the TCM you must demarcate all changes in component context by starting an unspecified transaction context. This is all quite invasive and made OpenEJB hard to use in Spring or plain old Tomcat. That was all fine and good for OpenEJB 3, but as it turns out there is a desire to keep the OpenEJB 2 and 3 code aligned as much as possible, so a discussion started around how to backport the changes to 2. We determined there were two options: 1) wrap the TCM with a class that implements TM but delegates to the TCM - this would be tricky to get working and there is always the problem of demarcating the unspecified transaction context 2) remove the TCM from Geronimo entirely - this could be a lot of work After a quick look at the first option, I decided to try option two. It turned out to be a lot easier than I thought since, the biggest user of TCM was OpenEJB and I had already pulled it out of OpenEJB. I also think I have become the master of using the IntelliJ refactor tools and was able to remove the code without too much hand tweaking. /history I have checked the fruits of this effort into https://svn.apache.org/ repos/asf/geronimo/branches/dain/notcm and there is a matching OpenEJB branch that is checked out with maven m:co. I have not updated the m2 build yet, as it was finalized during this work. For those of you that are following the Jencks project, which wraps the Geronimo transaction and connector modules with Spring bean factories, I have created a branch there also, which contains a massive simplification due to the refactors in the removal of the Geronimo TCM. Here are some fun examples from that project: http://fisheye.codehaus.org/browse/jencks/branches/notcm/src/test/ resources/org/jencks/samples/outbound/jencks-tranql.xml?r=112 http://fisheye.codehaus.org/browse/jencks/branches/notcm/src/test/ resources/org/jencks/spring-request-reply-jta.xml?r=112 So what does everyone think about removing the TCM in general? After that I think we may want to discuss the specifics of my branch. I may have gotten too refactory happy :) Details on the specific changes I made follow: TransactionContextManager - Removed TransactionContextManager and replaced all uses with a plain old TransactionManager Removed all code from web containers, app client and timer that was simply demarcating an unspecified transaction context, which is no longer needed TransactionManager -- Merged XATerminator portion of TCM into GeronimoTransactionManager which is a subclass of TransactionManagerImpl Improved tx thread association code so we can throw an error if someone attempts to resume a tx associated with another thread Added TransactionManagerMonitor which is used by the connection tracker to know when a transaction context has changed UserTransaction --- TransactionManagerImpl now implements UserTransaction to ease integration with third party libraries such as Spring Removed OnlineUserTransaction since it was only really used by OpenEJB and it has it's own UserTransaction implementation Web containers now use GeronimoUserTransaction which is an always on wrapper around a transaction manager Third party support --- Moved use of ServerInfo from HOWLLog to HOWLLogGBean so it can be more easily use by third party libraries Moved connector related transaction data to connector module Replace use of Geronimo's thread pool with a concurrent executor -dain -- Regards, Hiram Blog: http://hiramchirino.com
RE: auto-generating documentation for C++ client?
Good idea ... I'll take care of that this evening. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Hiram Chirino Sent: Thursday, August 03, 2006 12:25 PM To: activemq-dev@geronimo.apache.org Subject: Re: auto-generating documentation for C++ client? Looks great. Just a small suggestion. Perhaps the docs for the cms modules and the activemq modules should generated seperatly. Since most users will only be using the cms:: namespace 99% of the time, includeing the activemq:: docs would just make the API harder for them to follow. On 8/3/06, Bish, Tim [EMAIL PROTECTED] wrote: Looks good guys, thanks for getting that setup. - Timothy A. Bish Sensis Corporation - -Original Message- From: Nathan Mittler [mailto:[EMAIL PROTECTED] Sent: Thursday, August 03, 2006 6:14 AM To: activemq-dev@geronimo.apache.org Subject: Re: auto-generating documentation for C++ client? Awesome! Thanks. On 8/3/06, James Strachan [EMAIL PROTECTED] wrote: On 8/3/06, James Strachan [EMAIL PROTECTED] wrote: There you go... http://svn.apache.org/repos/asf/incubator/activemq/site/cms/ hopefully in an hour or so it should show up here http://incubator.apache.org/activemq/cms/html/ Unfortunately right now Confluence is down so we can't yet edit these pages to add a link... http://incubator.apache.org/activemq/javadocs.html http://incubator.apache.org/activemq/cms.html Done e.g. http://activemq.org/site/javadocs.html -- James --- http://radio.weblogs.com/0112098/ -- Regards, Hiram Blog: http://hiramchirino.com
Classloader code
Hi, While working on some classloader code I noticed this: http://svn.apache.org/viewvc/geronimo/trunk/modules/kernel/src/java/ org/apache/geronimo/kernel/classloader/ Do you think that could be put in a separate module so that I could use it in ClassWorlds? Thanks, Jason van Zyl [EMAIL PROTECTED]
XBean namespace for ra
Looking at the examples in the Jencks project, I see the use of the following namespace: xmlns:amqra=http://activemq.org/ra/1.0; but I can't seem to find which jar/version contains that namespace. Anyone know which published jar has that ns? Thanks, -dain
Re: Classloader code
On Aug 3, 2006, at 12:20 PM, Jason van Zyl wrote: Hi, While working on some classloader code I noticed this: http://svn.apache.org/viewvc/geronimo/trunk/modules/kernel/src/java/ org/apache/geronimo/kernel/classloader/ Do you think that could be put in a separate module so that I could use it in ClassWorlds? Guillaume has a patch to merge the changes in Geronimo back into XBean but I can't seem to find the JIRA right now. After we merge it back, I think we should split it out into a separate module. -dain
Re: Creating a secure connection system and using JMSXUserID support
I wouldn't need a fake truststore. I would use a custom truststore that would use a custom login module to authenticate the client via certificate (LDAP would be just one of the login modules) and return authenticated subject and principals. This return seems complicated so fake truststore was an attempt to simplify things. What I don't like about it is that it performs half of the normal SSL authentication and then performs full authentication again on the broker side. I'll go for the original one. I'll try to find a way to return authenticated subject and principals from the custom truststore and somehow make it available to AMQ for later authorization. I haven't gone through the AMQ code yet so I would gladly accept suggestions. Regards, NGC David Jencks wrote: On Aug 3, 2006, at 3:35 AM, ngcutura wrote: I agree with this, I only think it will be a tough job. I also have a deadline, so I suggest that we split the work. I may take custom truststore and certificate authentication against LDAP (I already have idea how to do it) but I am open to suggestions. I still don't understand why you would want to use a fake truststore. I would expect that you would want to use the standard mechanisms to validate the supplied client cert chain, so you know by the time the connection is set up the client has supplied a valid cert chain, and then use a JAAS login module to decide if the identified user is someone you want to let into the system. I think that you will need a variety of approaches in the security broker filter to extract the necessary info from the environment (including the SSLSession and ConnectionInfo) and feed it into JAAS. thanks david jencks Regards, NGC Sepand M wrote: Ok. So from what I've read, we're trying to separate the authorization part from the SSL socket and let the broker handle it. This sounds great. It would take more work (not so great since I have a deadline), but it would be a proper solution. From what I know of JAAS, the subject/principals fully represent identity. So attaching them to Connection info would be a good idea. That way, the Transport's job would be to authenticate and the Broker could handle authorization completely. This would also mean that any communication system could be used without having to change the Broker (as long as the Transport can authenticate and create proper subjet/principals). The one thing I will note is that we are changing the ActiveMQ architecture in that currently, the Brokers are doing both authentication and authorization (e.g. The Brokers are currently doing the user name and password validation). I think, however, that this is necessary because without our change, there would need to be a new broker for every new, authenticated, communication system. Please tell me if you agree (in which case I'll start looking at implementation details). On 8/2/06, David Jencks [EMAIL PROTECTED] wrote: I'm confused by the descriptions of this approach, and don't understand what is being proposed. I would separate the steps of 1. validating the client certificate based on the presented certificate chain, which in my experience can be done by the standard truststore implementation that comes with java, and serves to identify the client: this is done during the ssl connection setup and 2. deciding if the identified client is someone you want to let into the system, which can be done with a JAAS login module that accepts either a certificate chain callback handler (probably way overkill), the client certificate (possibly overkill, we've already verified the validity of the chain), or just the DN. Keeping the DN in LDAP should be no problem, perhaps mapped to the principals you want the user to have: I think this could be done after the ssl connection is set up and 3. deciding what permissions the logged in user should get. You might want to consider using a JACC like approach: I set up something like this for portal permissions in jetspeed2 and suspect something similar ought to work for amq. many thanks david jencks On Aug 2, 2006, at 12:20 PM, Hiram Chirino wrote: Hi, On 8/2/06, ngcutura [EMAIL PROTECTED] wrote: Hmmm... It didn't cross my mind but yes, indeed, it is possible. We may supply a fake truststore that would return 'true' for any certificate submitted for authentication and then perform real authentication after connection setup. We would then be able to obtain client certificate exactly as you stated. If we accept this approach, I see three components to implement: 1. Fake truststore 2. CertificateLoginModule (against LDAP) 3. Tweak connection setup to ask for peer certificates. In 3. we actually need some kind of policy reagarding authenitcation. Although SSL connection is established, a client may still supply username/password meaning that it should be used for login. I guess
Re: Current caller subject?
On Aug 3, 2006, at 9:55 AM, Dain Sundstrom wrote:
On Aug 2, 2006, at 11:29 PM, David Jencks wrote:
On Aug 2, 2006, at 10:53 PM, Dain Sundstrom wrote:
I'm working on the Jencks project again and have discovered that
the container managed security and pool partition by-subject
doesn't work oustide of Geronimo since both depend on obtaining
the current caller's subject from ContextManager.getCurrentCaller
(), which is a Geronimo specific class.
Is there a spec defined way we could be getting the current
caller's subject that would reasonably work in most app servers?
I'm hoping there is something in the JACC spec. If not, I think
we should introduce a hook under these static calls, so we can
redirect them to platform specific APIs when running outside of a
Geronimo server.
You could use
(Subject)PolicyContext.getContext
(javax.security.auth.Subject.container);
which in geronimo delegates to ContextManager.getCurrentCaller()
using a lot of hashmap lookups and security checks.
Based on the response I got from Alan on IRC and this message, I
don't think it would be appropriate to change the connector code
use the JACC api directly due to the performance problems. Maybe
we can change the ContextManager methods as follows:
public static boolean useJacc = true;
public static Subject getCurrentCaller() throws
PolicyContextException {
if (useJacc) {
return (Subject)PolicyContext.getContext
(javax.security.auth.Subject.container);
} else {
SecurityManager sm = System.getSecurityManager();
if (sm != null) sm.checkPermission(GET_CONTEXT);
return (Subject) currentCaller.get();
}
}
When running in a Geronimo server we set useJacc to false.
What do you think?
I think we should use the jacc interfaces in the connector
framework. Alan was talking about getting the subject from the ACC
which is time consuming and independent of JACC. Our jacc
implementation delegates to ContextManager, so it's fast (only
involves about 2 more hashmap lookups than using ContextManager
directly). If someone wants to use a slow JACC implementation,
that's their problem.
thanks
david jencks
-dain
[jira] Commented: (GERONIMO-2269) Error after redeploy (with no version in module ID) (branches/1.1.1)
[ http://issues.apache.org/jira/browse/GERONIMO-2269?page=comments#action_12425601 ] Aaron Mulder commented on GERONIMO-2269: OK, the exception above is actually a problem *trying to restart the old web app* after the deployment of the new web app has failed. So that's one problem, but it is actually suppressing the underlying problem that caused the new web app to fail. Here's the original exception: javax.naming.NamingException: Could not look up : env/jdbc/Database [Root exception is java.lang.NullPointerException] at org.apache.geronimo.naming.enc.CachingReference.resolveReference(CachingReference.java:59) at org.apache.geronimo.naming.enc.CachingReference.get(CachingReference.java:45) at org.apache.geronimo.naming.enc.AbstractReadOnlyContext.lookup(AbstractReadOnlyContext.java:86) at org.apache.geronimo.naming.java.RootContext.lookup(RootContext.java:51) at javax.naming.InitialContext.lookup(InitialContext.java:347) at org.springframework.jndi.JndiTemplate$1.doInContext(JndiTemplate.java:120) ... Caused by: java.lang.NullPointerException at org.apache.geronimo.naming.reference.ConfigurationAwareReference.resolveTargetName(ConfigurationAwareReference.java:64) at org.apache.geronimo.naming.reference.ResourceReference.getContent(ResourceReference.java:54) at org.apache.geronimo.naming.enc.CachingReference.resolveReference(CachingReference.java:55) ... 98 more It looks like that means the ConfigurationAwareReference was not able to look up its Configuration. Error after redeploy (with no version in module ID) (branches/1.1.1) Key: GERONIMO-2269 URL: http://issues.apache.org/jira/browse/GERONIMO-2269 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: deployment, kernel Affects Versions: 1.1.1 Reporter: Aaron Mulder Fix For: 1.1.x I deployed a web application (including a resource-ref to a database pool) successfully, with a module ID containing only an artifact element. I changed the web.xml and redeployed it. It failed due to a syntax error in web.xml (I changed the login page to not start with a / and it complained; apparently the / is necessary). The application still appeared to be running, though I didn't test it. I fixed the web.xml and redeployed it. It failed with the following error. It seems that after the redeploy the JNDI entry for the data source was invalid? UPDATE: a simple redeploy of the working application causes the error -- it's not necessary to have the failed redeploy in between. 11:57:44,865 ERROR [ContextLoader] Context initialization failed org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'DataSource' defined in resource [/WEB-INF/applicationContext.xml] of ServletContext: Initialization of bean failed; nested exception is javax.naming.NamingException: Could not look up : env/jdbc/Database javax.naming.NamingException: Could not look up : env/jdbc/Database [Root exception is org.apache.geronimo.kernel.proxy.DeadProxyException: Proxy is no longer valid] at org.apache.geronimo.naming.enc.CachingReference.resolveReference(CachingReference.java:59) at org.apache.geronimo.naming.enc.CachingReference.get(CachingReference.java:45) at org.apache.geronimo.naming.enc.AbstractReadOnlyContext.lookup(AbstractReadOnlyContext.java:86) at org.apache.geronimo.naming.java.RootContext.lookup(RootContext.java:51) at javax.naming.InitialContext.lookup(InitialContext.java:347) at org.springframework.jndi.JndiTemplate$1.doInContext(JndiTemplate.java:120) at org.springframework.jndi.JndiTemplate.execute(JndiTemplate.java:85) at org.springframework.jndi.JndiTemplate.lookup(JndiTemplate.java:117) at org.springframework.jndi.AbstractJndiLocator.lookup(AbstractJndiLocator.java:181) at org.springframework.jndi.AbstractJndiLocator.afterPropertiesSet(AbstractJndiLocator.java:171) at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.invokeInitMethods(AbstractAutowireCapableBeanFactory.java:801) at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:249) at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:177) at org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:159) at
Re: Wiki migration
yeah, not sure why that is happening. What worked for others was to log out and log in again. It must be a caching thingy. Let me know if that doesn't work. Cheers! Hernan Dain Sundstrom wrote: I don't seem to have the permissions to view that space. -dain On Aug 3, 2006, at 11:34 AM, Hernan Cunico wrote: Hi All, I've been reviewing the content we have in the Moin Moin wiki and it is way more out of date than I thought it would be. I initially thought that it would be easier to do the housekeeping once we had the content migrated to Confluence but after a more detailed analysis of the actual content to migrate I found out that there is really little content to move over. This is either because we already have that content categorized and up to date or the Moin Moin content is so out of date that is not relevant anymore. So, did some cleaning and detailed review of the Moin Moin content ( thanks Jason for helping with Moin Moin ;-) ), ran the migration again (thanks Don for providing the migration tools and continuous support) and came up with a very reduced list of pages that, IMHO, should actually be migrated and integrated to the current cwiki. These pages are listed in the yellow box at the top of the front page, here is the link to the partially migrated space. http://cwiki.apache.org/confluence/display/GMOxMoinMoin I know we all focused on getting v1.1.1 out of the door now so how about time to review it untill next Friday Aug 11. Not sure if this calls for a vote ( we kinda did that already) but if there are not -1/negative comments I would propose to give wiki.apache.org/geronimo a proper burial and get it out of production. If anybody thinks that any other page should be included pls send me the page name (and link) and we'll review it. Thanks Cheers! Hernan
Re: Wiki migration
I doesn't work for me. Is there any reason not to open read access to everyone? -dain On Aug 3, 2006, at 1:19 PM, Hernan Cunico wrote: yeah, not sure why that is happening. What worked for others was to log out and log in again. It must be a caching thingy. Let me know if that doesn't work. Cheers! Hernan Dain Sundstrom wrote: I don't seem to have the permissions to view that space. -dain On Aug 3, 2006, at 11:34 AM, Hernan Cunico wrote: Hi All, I've been reviewing the content we have in the Moin Moin wiki and it is way more out of date than I thought it would be. I initially thought that it would be easier to do the housekeeping once we had the content migrated to Confluence but after a more detailed analysis of the actual content to migrate I found out that there is really little content to move over. This is either because we already have that content categorized and up to date or the Moin Moin content is so out of date that is not relevant anymore. So, did some cleaning and detailed review of the Moin Moin content ( thanks Jason for helping with Moin Moin ;-) ), ran the migration again (thanks Don for providing the migration tools and continuous support) and came up with a very reduced list of pages that, IMHO, should actually be migrated and integrated to the current cwiki. These pages are listed in the yellow box at the top of the front page, here is the link to the partially migrated space. http://cwiki.apache.org/confluence/display/GMOxMoinMoin I know we all focused on getting v1.1.1 out of the door now so how about time to review it untill next Friday Aug 11. Not sure if this calls for a vote ( we kinda did that already) but if there are not -1/negative comments I would propose to give wiki.apache.org/geronimo a proper burial and get it out of production. If anybody thinks that any other page should be included pls send me the page name (and link) and we'll review it. Thanks Cheers! Hernan
Re: Wiki migration
Scratch that. It will let me view the site as long as I am NOT logged in. As soon as I login in, I the space is removed from my dashboard. -dain On Aug 3, 2006, at 1:27 PM, Dain Sundstrom wrote: I doesn't work for me. Is there any reason not to open read access to everyone? -dain On Aug 3, 2006, at 1:19 PM, Hernan Cunico wrote: yeah, not sure why that is happening. What worked for others was to log out and log in again. It must be a caching thingy. Let me know if that doesn't work. Cheers! Hernan Dain Sundstrom wrote: I don't seem to have the permissions to view that space. -dain On Aug 3, 2006, at 11:34 AM, Hernan Cunico wrote: Hi All, I've been reviewing the content we have in the Moin Moin wiki and it is way more out of date than I thought it would be. I initially thought that it would be easier to do the housekeeping once we had the content migrated to Confluence but after a more detailed analysis of the actual content to migrate I found out that there is really little content to move over. This is either because we already have that content categorized and up to date or the Moin Moin content is so out of date that is not relevant anymore. So, did some cleaning and detailed review of the Moin Moin content ( thanks Jason for helping with Moin Moin ;-) ), ran the migration again (thanks Don for providing the migration tools and continuous support) and came up with a very reduced list of pages that, IMHO, should actually be migrated and integrated to the current cwiki. These pages are listed in the yellow box at the top of the front page, here is the link to the partially migrated space. http://cwiki.apache.org/confluence/display/GMOxMoinMoin I know we all focused on getting v1.1.1 out of the door now so how about time to review it untill next Friday Aug 11. Not sure if this calls for a vote ( we kinda did that already) but if there are not -1/negative comments I would propose to give wiki.apache.org/geronimo a proper burial and get it out of production. If anybody thinks that any other page should be included pls send me the page name (and link) and we'll review it. Thanks Cheers! Hernan
[RTC] GERONIMODEVTOOLS-93
I would like an RTC for the following change in devtools trunkhttp://issues.apache.org/jira/browse/GERONIMODEVTOOLS-93?page=allthx -sachin
