Failure on schemas when builing trunk
I have the following problem when building Geronimo.
Any idea how to work around the problem ?
[INFO]
[INFO] Building Geronimo :: Jetty :: Builder
[INFO]task-segment: [install]
[INFO]
[INFO] [tools:require-java-version {execution: validate-java-version}]
[INFO] [xmlbeans:xmlbeans {execution: default}]
IO Error java.io.FileNotFoundException:
C:\java\geronimo\server\trunk\modules\geronimo-jetty-builder\src\main\schema\geronimo-application-1.2.xsd
(The system cannot find the file specified)
Time to build schema type system: 2.266 seconds
BUILD FAILED
[INFO]
[ERROR] BUILD ERROR
[INFO]
[INFO] XmlBeans compile failed:
xml ErrorLoading schema file
C:\java\geronimo\server\trunk\modules\geronimo-jetty-builder\src\main\schema\geronimo-jetty-1.2.xsd
xml ErrorLoading schema file
C:\java\geronimo\server\trunk\modules\geronimo-jetty-builder\src\main\schema\geronimo-jetty-config-1.0.xsd
xml ErrorLoading config file
C:\java\geronimo\server\trunk\modules\geronimo-jetty-builder\src\main\schema\xmlconfig.xml
xml
ErrorC:\java\geronimo\server\trunk\modules\geronimo-jetty-builder\src\main\schema\geronimo-jetty-1.2.xsd:33:
error: java.io.FileNotFoundException:
C:\java\geronimo\server\trunk\modules\geronimo-je
tty-builder\src\main\schema\geronimo-application-1.2.xsd (The system
cannot find the file specified)
xml
ErrorC:\java\geronimo\server\trunk\modules\geronimo-jetty-builder\src\main\schema\geronimo-jetty-1.2.xsd:45:
error: src-resolve: element
'[EMAIL PROTECTED]://geronimo.apache.org/xml/ns/j2ee/applicat
ion-1.2' not found.
xml
ErrorC:\java\geronimo\server\trunk\modules\geronimo-jetty-builder\src\main\schema\geronimo-jetty-1.2.xsd:58:
error: src-resolve: element
'[EMAIL PROTECTED]://geronimo.apache.org/xml/ns/j2ee/applicatio
n-1.2' not found.
--
Cheers,
Guillaume Nodet
Project Creatation Error in Eclipse-FUSE
Hello everybody ! I'm a new guy just join in serviceMix from India. I downlaod Eclipse-FUSE id from logizblaze site. i got error while create new project Servicemix(JBI) ... Error msg "Unable to install Apache Maven" Thanks -- View this message in context: http://www.nabble.com/Project-Creatation-Error-in-Eclipse-FUSE-tf2471514.html#a6891152 Sent from the ServiceMix - Dev mailing list archive at Nabble.com.
[jira] Resolved: (AMQ-969) .NET Compact Framevork compatibility
[ https://issues.apache.org/activemq/browse/AMQ-969?page=all ] Hiram Chirino resolved AMQ-969. --- Resolution: Fixed Thanks for the patch and the info. Changes commited in revision: 465501. > .NET Compact Framevork compatibility > > > Key: AMQ-969 > URL: https://issues.apache.org/activemq/browse/AMQ-969 > Project: ActiveMQ > Issue Type: Improvement > Components: NMS (C# client) > Environment: .NET Compact Framework 2.0 >Reporter: Oleg Deribas > Attachments: nms-cf20-projects.zip > > > For connecting to ActiveMQ from PDA (PocketPC) NMS should be compiled for > .NET Compact Framework. > And currently there are not projects for .NET CF in vs2005 solution. -- 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: [ANNOUNCE] Please welcome Vamsavardhana Reddy as one of our newest Committer
Congratulations Vamsi-- ShivaOn 10/19/06, Krishnakumar B <[EMAIL PROTECTED]> wrote: Congrats Vamsi.RegardsKrishOn 10/19/06, John Sisson <[EMAIL PROTECTED]> wrote:> Congratulations Vamsi!>> Regards,> John> > Alan Cabrera wrote:> > The Geronimo PMC is pleased to announce that Vamsavardhana Reddy has> > recently accepted our invitation to become an Apache Geronimo> > Committer. Vamsi has been submitting many great patches for > > an embarrassing long time. The breadth of his patches is remarkable> > but we are excited by the possibility of him working on security.> >> > Congratulations and welcome Vamsi! > >> >> > Regards,> > Alan> >> > --> > Apache Geronimo - http://geronimo.apache.org> > Apache Yoko - http://incubator.apache.org/yoko> > LiveTribe - http://www.livetribe.org> >> >> >> > >>
Re: [ANNOUNCE] Please welcome Christopher M. Cardona as our newest Committer
Congratulations Chris.-- ShivaOn 10/19/06, John Sisson <[EMAIL PROTECTED]> wrote: Congratulations Chris!Regards,JohnGianny Damour wrote:> Hi,>> The Geronimo PMC is pleased to announce that Christopher M. Cardona> has recently accepted our invitation to become an Apache Geronimo > Committer. Over the past few months, Chris has been working on the> improvement of the Server Console and has demonstrated initiatives and> a noteworthy ability to work with others.>> Congratulations and Welcome Christopher! >>
Re: [ANNOUNCE] Please welcome Vamsavardhana Reddy as one of our newest Committer
Congrats Vamsi. Regards Krish On 10/19/06, John Sisson <[EMAIL PROTECTED]> wrote: Congratulations Vamsi! Regards, John Alan Cabrera wrote: > The Geronimo PMC is pleased to announce that Vamsavardhana Reddy has > recently accepted our invitation to become an Apache Geronimo > Committer. Vamsi has been submitting many great patches for > an embarrassing long time. The breadth of his patches is remarkable > but we are excited by the possibility of him working on security. > > Congratulations and welcome Vamsi! > > > Regards, > Alan > > -- > Apache Geronimo - http://geronimo.apache.org > Apache Yoko - http://incubator.apache.org/yoko > LiveTribe - http://www.livetribe.org > > > >
Re: WS-Security and Geronimo KeystoreInstance
On Oct 18, 2006, at 5:47 PM, Aaron Mulder wrote: I still have the problem that you can create a new keystore and add new password-protected keys to the keystore(s) at runtime. So I don't see how at login/startup anything will be able to populate all the needed passwords. If you could add passwords to the Subject at runtime and they would be saved for future runs, that's a possibility -- as in, when you create or first access a keystore it saves the password you use for future re-use. But I'm not sure that's workable. What do you think? I'm not sure one way or the other. How about this: -- modify security admin's login info so new password is added to their private credentials when they login -- they login as security admin -- they create the keystore with the new password -- they can access the new keystore because the password is already in their subject. As I said, I'm not sure one way or the other but it seems possible. I may be arguing that permissions to create a keystore and administer login config are different from permissions to change the contents of the keystore. thanks david jencks Thanks, Aaron On 10/18/06, David Jencks <[EMAIL PROTECTED]> wrote: This is a bit related to GERONIMO-1486,7,8. I thought simon had fleshed these ideas out more than he seems to have. This is also not necessarily something we can implement quickly. - when you start the server you need to provide credentials. You get logged in and a Subject is created using a bunch of login modules. What the server can do is determined by this Subject. In particular the keystore gbean can look for a private credential in this subject to unlock the keystore. This subject is attached to all threads unless they are processing an authenticated j2ee request. - For any user who can modify the keystore, the credentials necessary to allow them to do this are attached to their Subject when they login. When they try to modify the keystore, we look for the credentials in their Subject. - We can also define permissions to modify the keystore, add role>> permission mappings, and use JACC to enforce them. I did something similar with the jetspeed2 portat permissions. I think these ideas are independent of each other. While I don't think we'd necessarily want to use the console login password as the keystore password, we also don't necessarily want to give the keystore password to those who can modify it. By using JAAS to install it as a private credential in the Subject we can hide it from the user yet let them modify the keystore. For our default demo console security we'd probably want to have 2 predefined users, one who can modify the keystore and one who can't Hopefully this is a little clearer. keep asking questions if it isn't thanks david jencks On Oct 18, 2006, at 3:16 PM, Guillaume Nodet wrote: > How does the java security mechanism integrates with JAAS and / or > JACC ? > > Btw, one of the problem I see (but this may not be a problem, I'm not > very proficient in this area), is that the console requires a password > to edit the keystore. We can not just use the user provided when > logging in the console... > > On 10/18/06, David Jencks <[EMAIL PROTECTED]> wrote: >> I'm wondering if we can solve this using JAAS and java security and >> maybe even JACC?? >> >> I haven't checked to see if there are already permission checks on >> the keystore methods. If not, I'd suggest defining an appropriate >> permission and checking it. >> >> For the password I suggest using a LoginModule to attach a private >> credential to the Subject for those authorized to unlock and/or use >> the keystore. The methods wouldn't need to have the password as a >> parameter, it could be extracted from the Subject. >> >> thanks >> david jencks >> >> >> On Oct 18, 2006, at 7:25 AM, Guillaume Nodet wrote: >> >> > Yeah, I do understand that the key password has to be provided. >> > >> > I see three different ways I could handle the modification: >> > 1) duplicate all methods that are read-only wrt to the keystore >> > and remove the keystore password (it would use the internal >> one) >> > 2) remove the keystore password on existing methods >> > 3) assume that when password is null, it uses the internal one >> > >> > The second method can not really be used, because the internal >> > password is only set when the keystore is unlocked for use. >> > The first one is not really clean imho, so I would go for the third >> > option. >> > >> > Btw, I found several problems in the current implementation. >> > Some edition methods do not have a password given, so they >> > use the internal one. This means that they fail when executing >> > the method on a keystore that is locked for use. This can be >> > reproduce if you try to delete an entry from a locked keystore. >> > It seems to be the case for >> > * deleteEntry >> > * importPKCS7Certificate >> > * generateCSR >> > >> > I will try to fix th
[jira] Closed: (AMQ-993) test
[ https://issues.apache.org/activemq/browse/AMQ-993?page=all ] Hiram Chirino closed AMQ-993. - Resolution: Won't Fix > test > > > Key: AMQ-993 > URL: https://issues.apache.org/activemq/browse/AMQ-993 > Project: ActiveMQ > Issue Type: Test >Reporter: Hiram Chirino > Attachments: test.txt > > -- 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] Updated: (AMQ-993) test
[ https://issues.apache.org/activemq/browse/AMQ-993?page=all ] Hiram Chirino updated AMQ-993: -- Attachment: test.txt test attachment. > test > > > Key: AMQ-993 > URL: https://issues.apache.org/activemq/browse/AMQ-993 > Project: ActiveMQ > Issue Type: Test >Reporter: Hiram Chirino > Attachments: test.txt > > -- 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-993) test
test Key: AMQ-993 URL: https://issues.apache.org/activemq/browse/AMQ-993 Project: ActiveMQ Issue Type: Test Reporter: Hiram Chirino Attachments: test.txt -- 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] Resolved: (AMQ-938) Support extending the activemq classpath with the ACTIVEMQ_CLASSPATH variable and overriding of the SUNJMX
[ https://issues.apache.org/activemq/browse/AMQ-938?page=all ] Hiram Chirino resolved AMQ-938. --- Fix Version/s: 4.0.2 (was: 4.0.3) Resolution: Fixed in trunk: rev 452108 and 449079 in 4.0 branch rev 452107 and 449077 > Support extending the activemq classpath with the ACTIVEMQ_CLASSPATH variable > and overriding of the SUNJMX > -- > > Key: AMQ-938 > URL: https://issues.apache.org/activemq/browse/AMQ-938 > Project: ActiveMQ > Issue Type: New Feature > Components: Broker >Affects Versions: 4.0 >Reporter: Hiram Chirino > Assigned To: Hiram Chirino > Fix For: 4.1, 4.0.2 > > > This will allow folks to be able to customized thier run enviorment without > having to modify the activemq start script -- 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] Resolved: (AMQ-971) NMSTimestamp returning LocalTime instead of UTC
[ https://issues.apache.org/activemq/browse/AMQ-971?page=all ] Hiram Chirino resolved AMQ-971. --- Resolution: Fixed Fixed in 465441 > NMSTimestamp returning LocalTime instead of UTC > --- > > Key: AMQ-971 > URL: https://issues.apache.org/activemq/browse/AMQ-971 > Project: ActiveMQ > Issue Type: Improvement > Components: NMS (C# client) >Affects Versions: incubation > Environment: Windows >Reporter: Rob Lugt > Assigned To: Hiram Chirino >Priority: Minor > > The NMSTimestamp property has been changed from long to DateTime - which is a > good thing. However, the DateTime is currently being adjusted to localtime > before being returned to the client - which is probably not ideal. The > DateTime struct does not contain timezone information, therefore the > programmer has to make some assumption about what timezone the time is > expressed in. A UTC time is more in-keeping with the JMS specification - > which specifies that Timestamp is a normal Java time i.e. expressed in GMT. > This article from Microsoft also suggests using UTC as a common time where > possible: > http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dndotnet/html/datetimecode.asp -- 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: (GERONIMO-2502) NPE in ConnectionTrackingCoordinator
NPE in ConnectionTrackingCoordinator Key: GERONIMO-2502 URL: http://issues.apache.org/jira/browse/GERONIMO-2502 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Components: connector Affects Versions: 1.2 Environment: All Reporter: Anita Kulshreshtha If server is shutdown using ^C, a NCDFE is thrwon: java.lang.NoClassDefFoundError: EDU/oswego/cs/dl/util/concurrent/LinkedNode at EDU.oswego.cs.dl.util.concurrent.SynchronousChannel.poll(Unknown Source) at EDU.oswego.cs.dl.util.concurrent.PooledExecutor.getTask(Unknown Source) at EDU.oswego.cs.dl.util.concurrent.PooledExecutor$Worker.run(Unknown Source) at java.lang.Thread.run(Thread.java:534) NPE is thrown during shutdown from the console. To reproduce the following trace start the server and shutdown using console. Geronimo Application Server started 19:10:38,984 INFO [ServerManagerPortlet] Shutting down by user request: system 19:10:39,031 INFO [StandardWrapper] Waiting for 1 instance(s) to be deallocated 19:10:40,125 INFO [StandardWrapper] Waiting for 1 instance(s) to be deallocated 19:10:41,218 INFO [StandardWrapper] Waiting for 1 instance(s) to be deallocated 19:10:41,421 INFO [StandardWrapper] Waiting for 1 instance(s) to be deallocated 19:10:42,515 INFO [StandardWrapper] Waiting for 1 instance(s) to be deallocated 19:10:43,609 INFO [StandardWrapper] Waiting for 1 instance(s) to be deallocated 19:10:43,718 INFO [StandardWrapper] Waiting for 2 instance(s) to be deallocated 19:10:44,812 INFO [StandardWrapper] Waiting for 2 instance(s) to be deallocated 19:10:45,906 INFO [StandardWrapper] Waiting for 2 instance(s) to be deallocated 19:10:46,015 INFO [StandardWrapper] Waiting for 1 instance(s) to be deallocated 19:10:47,109 INFO [StandardWrapper] Waiting for 1 instance(s) to be deallocated 19:10:48,203 INFO [StandardWrapper] Waiting for 1 instance(s) to be deallocated 19:10:48,625 INFO [StandardWrapper] Waiting for 1 instance(s) to be deallocated 19:10:49,718 INFO [StandardWrapper] Waiting for 1 instance(s) to be deallocated 19:10:50,812 INFO [StandardWrapper] Waiting for 1 instance(s) to be deallocated 19:10:50,921 INFO [StandardWrapper] Waiting for 1 instance(s) to be deallocated 19:10:52,015 INFO [StandardWrapper] Waiting for 1 instance(s) to be deallocated 19:10:53,109 INFO [StandardWrapper] Waiting for 1 instance(s) to be deallocated 19:10:55,328 INFO [TransportConnector] Connector stomp://your-4dacd0ea75:61613 Stopped 19:10:55,328 INFO [TransportConnector] Connector vm://localhost Stopped 19:11:00,328 INFO [TransportConnector] Connector tcp://0.0.0.0:61616 Stopped 19:11:00,328 INFO [BrokerService] ActiveMQ Message Broker (possibly-unique-broker, ID:you r-4dacd0ea75-1136-1161212953093-1:0) is shutting down 19:11:00,328 INFO [TransportConnector] Connector stomp://your-4dacd0ea75:61613 Stopped 19:11:00,328 INFO [TransportConnector] Connector vm://localhost Stopped 19:11:00,328 INFO [TransportConnector] Connector tcp://0.0.0.0:61616 Stopped 19:11:00,343 ERROR [JournalPersistenceAdapter] Could not stop service: org.apache.activemq [EMAIL PROTECTED] Reason: java.lang.NullPointerException java.lang.NullPointerException at org.apache.geronimo.connector.outbound.connectiontracking.ConnectionTrackingCoo rdinator.handleReleased(ConnectionTrackingCoordinator.java:127) at org.apache.geronimo.connector.outbound.connectiontracking.ConnectionTrackingCoo rdinator$$FastClassByCGLIB$$5d33aabf.invoke() at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53) at org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.ja va:38) at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:122 ) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:820) 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(ProxyMethodIn terceptor.java:96) at org.apache.geronimo.connector.outbound.connectiontracking.ConnectionTracker$$En hancerByCGLIB$$b4048776.handleReleased() at org.apache.geronimo.connector.outbound.ConnectionTrackingInterceptor.returnConn ection(ConnectionTrackingInterceptor.java:81) at org.apache.geronimo.connector.outbound.GeronimoConnectionEventListener.connecti onClosed(GeronimoConnectionEventListener.java:67) at org.tranql.connector.AbstractManagedConnection.connectionClosed(AbstractManaged Connection.java:102) at org.tranql.connector.jdbc.ConnectionHandle.close(ConnectionHandle.java:97) at org.apache.activemq.store.jdbc.DefaultDatabaseLocker.stop(DefaultDa
Re: WS-Security and Geronimo KeystoreInstance
I still have the problem that you can create a new keystore and add new password-protected keys to the keystore(s) at runtime. So I don't see how at login/startup anything will be able to populate all the needed passwords. If you could add passwords to the Subject at runtime and they would be saved for future runs, that's a possibility -- as in, when you create or first access a keystore it saves the password you use for future re-use. But I'm not sure that's workable. What do you think? Thanks, Aaron On 10/18/06, David Jencks <[EMAIL PROTECTED]> wrote: This is a bit related to GERONIMO-1486,7,8. I thought simon had fleshed these ideas out more than he seems to have. This is also not necessarily something we can implement quickly. - when you start the server you need to provide credentials. You get logged in and a Subject is created using a bunch of login modules. What the server can do is determined by this Subject. In particular the keystore gbean can look for a private credential in this subject to unlock the keystore. This subject is attached to all threads unless they are processing an authenticated j2ee request. - For any user who can modify the keystore, the credentials necessary to allow them to do this are attached to their Subject when they login. When they try to modify the keystore, we look for the credentials in their Subject. - We can also define permissions to modify the keystore, add role>> permission mappings, and use JACC to enforce them. I did something similar with the jetspeed2 portat permissions. I think these ideas are independent of each other. While I don't think we'd necessarily want to use the console login password as the keystore password, we also don't necessarily want to give the keystore password to those who can modify it. By using JAAS to install it as a private credential in the Subject we can hide it from the user yet let them modify the keystore. For our default demo console security we'd probably want to have 2 predefined users, one who can modify the keystore and one who can't Hopefully this is a little clearer. keep asking questions if it isn't thanks david jencks On Oct 18, 2006, at 3:16 PM, Guillaume Nodet wrote: > How does the java security mechanism integrates with JAAS and / or > JACC ? > > Btw, one of the problem I see (but this may not be a problem, I'm not > very proficient in this area), is that the console requires a password > to edit the keystore. We can not just use the user provided when > logging in the console... > > On 10/18/06, David Jencks <[EMAIL PROTECTED]> wrote: >> I'm wondering if we can solve this using JAAS and java security and >> maybe even JACC?? >> >> I haven't checked to see if there are already permission checks on >> the keystore methods. If not, I'd suggest defining an appropriate >> permission and checking it. >> >> For the password I suggest using a LoginModule to attach a private >> credential to the Subject for those authorized to unlock and/or use >> the keystore. The methods wouldn't need to have the password as a >> parameter, it could be extracted from the Subject. >> >> thanks >> david jencks >> >> >> On Oct 18, 2006, at 7:25 AM, Guillaume Nodet wrote: >> >> > Yeah, I do understand that the key password has to be provided. >> > >> > I see three different ways I could handle the modification: >> > 1) duplicate all methods that are read-only wrt to the keystore >> > and remove the keystore password (it would use the internal >> one) >> > 2) remove the keystore password on existing methods >> > 3) assume that when password is null, it uses the internal one >> > >> > The second method can not really be used, because the internal >> > password is only set when the keystore is unlocked for use. >> > The first one is not really clean imho, so I would go for the third >> > option. >> > >> > Btw, I found several problems in the current implementation. >> > Some edition methods do not have a password given, so they >> > use the internal one. This means that they fail when executing >> > the method on a keystore that is locked for use. This can be >> > reproduce if you try to delete an entry from a locked keystore. >> > It seems to be the case for >> > * deleteEntry >> > * importPKCS7Certificate >> > * generateCSR >> > >> > I will try to fix these, add the new needed methods (with the ones >> > from the GERONIMO-2413 patch) and when the given password >> > is null for read-only method, try to use the internal password. >> > >> > However, I'm wondering if the private key password problem >> > could be solved by using the java.lang.SecurityManager. >> > >> > >> > On 10/18/06, Vamsavardhana Reddy <[EMAIL PROTECTED]> wrote: >> >> Hi Guillaume, >> >> >> >> To make the CA Portlet >> >> (http://issues.apache.org/jira/browse/GERONIMO-2413) use a >> >> KeystoreInstance to store its keys, I have added a getCertificate >> >> () and >> >> getPrivateKey() methods. >> >> >> >> Now coming to the met
[jira] Work started: (SM-604) Allow servicemix-http managed mode to dynamically determine the server, port, and context path it is running on when generating jsr181 WSDLs
[ https://issues.apache.org/activemq/browse/SM-604?page=all ] Work on SM-604 started by Jeff Puro. > Allow servicemix-http managed mode to dynamically determine the server, port, > and context path it is running on when generating jsr181 WSDLs > > > Key: SM-604 > URL: https://issues.apache.org/activemq/browse/SM-604 > Project: ServiceMix > Issue Type: Bug > Components: servicemix-http, servicemix-jsr181 >Affects Versions: 3.0 >Reporter: Jeff Puro > Assigned To: Jeff Puro > Fix For: 3.0.1 > > Attachments: servicemix-http-host-port.patch > > > Currently when ServiceMix has an http endpoint that is running in "managed" > mode and that endpoint has a target service of a jsr181 endpoint it generates > WSDLs with a hardcoded value of "localhost". However, it should determine > the server, port, and context path of the web container that it is running > under and use this information to generate the service element in the WSDL. -- 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] Updated: (SM-604) Allow servicemix-http managed mode to dynamically determine the server, port, and context path it is running on when generating jsr181 WSDLs
[ https://issues.apache.org/activemq/browse/SM-604?page=all ] Jeff Puro updated SM-604: - Attachment: servicemix-http-host-port.patch > Allow servicemix-http managed mode to dynamically determine the server, port, > and context path it is running on when generating jsr181 WSDLs > > > Key: SM-604 > URL: https://issues.apache.org/activemq/browse/SM-604 > Project: ServiceMix > Issue Type: Bug > Components: servicemix-http, servicemix-jsr181 >Affects Versions: 3.0 >Reporter: Jeff Puro > Assigned To: Jeff Puro > Fix For: 3.0.1 > > Attachments: servicemix-http-host-port.patch > > > Currently when ServiceMix has an http endpoint that is running in "managed" > mode and that endpoint has a target service of a jsr181 endpoint it generates > WSDLs with a hardcoded value of "localhost". However, it should determine > the server, port, and context path of the web container that it is running > under and use this information to generate the service element in the WSDL. -- 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: [ANNOUNCE] Please welcome Vamsavardhana Reddy as one of our newest Committer
Congratulations Vamsi! Regards, John Alan Cabrera wrote: The Geronimo PMC is pleased to announce that Vamsavardhana Reddy has recently accepted our invitation to become an Apache Geronimo Committer. Vamsi has been submitting many great patches for an embarrassing long time. The breadth of his patches is remarkable but we are excited by the possibility of him working on security. Congratulations and welcome Vamsi! Regards, Alan -- Apache Geronimo - http://geronimo.apache.org Apache Yoko - http://incubator.apache.org/yoko LiveTribe - http://www.livetribe.org
Re: [ANNOUNCE] Please welcome Christopher M. Cardona as our newest Committer
Congratulations Chris! Regards, John Gianny Damour wrote: Hi, The Geronimo PMC is pleased to announce that Christopher M. Cardona has recently accepted our invitation to become an Apache Geronimo Committer. Over the past few months, Chris has been working on the improvement of the Server Console and has demonstrated initiatives and a noteworthy ability to work with others. Congratulations and Welcome Christopher!
[jira] Resolved: (SM-714) component.properties in conf directory
[ https://issues.apache.org/activemq/browse/SM-714?page=all ] Guillaume Nodet resolved SM-714. Fix Version/s: 3.1 Resolution: Fixed Assignee: Guillaume Nodet Author: gnodet Date: Wed Oct 18 16:34:00 2006 New Revision: 465420 URL: http://svn.apache.org/viewvc?view=rev&rev=465420 Log: SM-714: component.properties in conf directory Modified: incubator/servicemix/trunk/servicemix-http/src/main/java/org/apache/servicemix/http/HttpBootstrap.java incubator/servicemix/trunk/servicemix-http/src/main/java/org/apache/servicemix/http/HttpComponent.java incubator/servicemix/trunk/servicemix-http/src/main/java/org/apache/servicemix/http/HttpConfiguration.java Author: gnodet Date: Wed Oct 18 16:34:26 2006 New Revision: 465421 URL: http://svn.apache.org/viewvc?view=rev&rev=465421 Log: SM-714: component.properties in conf directory Patch provided by Thomas Termin Added: incubator/servicemix/trunk/apache-servicemix/src/main/release/conf/component.properties > component.properties in conf directory > -- > > Key: SM-714 > URL: https://issues.apache.org/activemq/browse/SM-714 > Project: ServiceMix > Issue Type: Improvement > Components: servicemix-http >Reporter: Thomas Termin > Assigned To: Guillaume Nodet > Fix For: 3.1 > > Attachments: component.properties, patch.txt > > > There should be support for an initial component.properties file in the > servicemix/conf directory. > I added support for that (see the patch). > The file in the conf directory will be loaded if no property file is in the > workspace directory (I implemented that just for the servicemix-http > component). If you change properties via JMX the changes will be saved in the > workspace directory. The file in the conf directory has then still the > original values. > I added also a component.properties file. -- 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] Resolved: (AMQ-986) Homepage download page points to wrong directory for 4.x
[ https://issues.apache.org/activemq/browse/AMQ-986?page=all ] Hiram Chirino resolved AMQ-986. --- Resolution: Fixed download page update. Thanks for the tip! Simplified it down and added more detailed section about where our maven repositories are located. > Homepage download page points to wrong directory for 4.x > > > Key: AMQ-986 > URL: https://issues.apache.org/activemq/browse/AMQ-986 > Project: ActiveMQ > Issue Type: Bug > Components: Documentation >Affects Versions: 4.x >Reporter: Bernhard Wellhöfer > > The www.activemq.org web page points for the 4.1 distro under > Download/"Latest Release" to the wrong download directory. > Currently it points to > http://people.apache.org/repository/incubator-activemq/distributions, but > here the oldest distro is from Jul 2006. The ocrrect URL is > http://people.apache.org/maven-snapshot-repository/org/apache/activemq/apache-activemq/4.1-incubator-SNAPSHOT. -- 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] Resolved: (SM-695) Dynamic HTTP provider endpoint
[ https://issues.apache.org/activemq/browse/SM-695?page=all ] Guillaume Nodet resolved SM-695. Fix Version/s: 3.1 Resolution: Fixed Assignee: Guillaume Nodet Author: gnodet Date: Wed Oct 18 16:07:50 2006 New Revision: 465412 URL: http://svn.apache.org/viewvc?view=rev&rev=465412 Log: SM-695: Dynamic HTTP provider endpoint Patch provided by James Lorrenzen, thx Modified: incubator/servicemix/trunk/servicemix-core/src/main/java/org/apache/servicemix/JbiConstants.java incubator/servicemix/trunk/servicemix-http/src/main/java/org/apache/servicemix/http/processors/ProviderProcessor.java incubator/servicemix/trunk/servicemix-http/src/test/java/org/apache/servicemix/http/HttpProviderTest.java > Dynamic HTTP provider endpoint > -- > > Key: SM-695 > URL: https://issues.apache.org/activemq/browse/SM-695 > Project: ServiceMix > Issue Type: New Feature > Components: servicemix-http >Affects Versions: 3.0 >Reporter: James Lorenzen > Assigned To: Guillaume Nodet >Priority: Minor > Fix For: 3.1 > > Attachments: HttpProviderTest.java, JbiConstants.java, > ProviderProcessor.java, ProviderProcessor.java > > > It would be benficial to add functionaility to the HTTP BC to allow consumers > to specify the provider locationURI through a NormalizedMessage property. > Please see this thread for related information: > http://www.nabble.com/http-endpoint-in-provider-mode%3A-dynamic-destination--tf1413771.html#a6721824 > Our team plans on adding some code to the HTTP BC that first looks to see if > the NormalizedMessage contains a specific property containing the value for > the destination. Therefore a consumer could create a new NormalizedMessage > and call setProperty to set the destination URI. If the HTTP BC detects this > property he routes the request to this URI; otherwise it continues as normal > and uses the locationURI specified in the xbean.xml file. > We plan on making and testing this change in the next couple of days. After > which we will reply back with the modifications. -- 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: WS-Security and Geronimo KeystoreInstance
This is a bit related to GERONIMO-1486,7,8. I thought simon had fleshed these ideas out more than he seems to have. This is also not necessarily something we can implement quickly. - when you start the server you need to provide credentials. You get logged in and a Subject is created using a bunch of login modules. What the server can do is determined by this Subject. In particular the keystore gbean can look for a private credential in this subject to unlock the keystore. This subject is attached to all threads unless they are processing an authenticated j2ee request. - For any user who can modify the keystore, the credentials necessary to allow them to do this are attached to their Subject when they login. When they try to modify the keystore, we look for the credentials in their Subject. - We can also define permissions to modify the keystore, add role>> permission mappings, and use JACC to enforce them. I did something similar with the jetspeed2 portat permissions. I think these ideas are independent of each other. While I don't think we'd necessarily want to use the console login password as the keystore password, we also don't necessarily want to give the keystore password to those who can modify it. By using JAAS to install it as a private credential in the Subject we can hide it from the user yet let them modify the keystore. For our default demo console security we'd probably want to have 2 predefined users, one who can modify the keystore and one who can't Hopefully this is a little clearer. keep asking questions if it isn't thanks david jencks On Oct 18, 2006, at 3:16 PM, Guillaume Nodet wrote: How does the java security mechanism integrates with JAAS and / or JACC ? Btw, one of the problem I see (but this may not be a problem, I'm not very proficient in this area), is that the console requires a password to edit the keystore. We can not just use the user provided when logging in the console... On 10/18/06, David Jencks <[EMAIL PROTECTED]> wrote: I'm wondering if we can solve this using JAAS and java security and maybe even JACC?? I haven't checked to see if there are already permission checks on the keystore methods. If not, I'd suggest defining an appropriate permission and checking it. For the password I suggest using a LoginModule to attach a private credential to the Subject for those authorized to unlock and/or use the keystore. The methods wouldn't need to have the password as a parameter, it could be extracted from the Subject. thanks david jencks On Oct 18, 2006, at 7:25 AM, Guillaume Nodet wrote: > Yeah, I do understand that the key password has to be provided. > > I see three different ways I could handle the modification: > 1) duplicate all methods that are read-only wrt to the keystore > and remove the keystore password (it would use the internal one) > 2) remove the keystore password on existing methods > 3) assume that when password is null, it uses the internal one > > The second method can not really be used, because the internal > password is only set when the keystore is unlocked for use. > The first one is not really clean imho, so I would go for the third > option. > > Btw, I found several problems in the current implementation. > Some edition methods do not have a password given, so they > use the internal one. This means that they fail when executing > the method on a keystore that is locked for use. This can be > reproduce if you try to delete an entry from a locked keystore. > It seems to be the case for > * deleteEntry > * importPKCS7Certificate > * generateCSR > > I will try to fix these, add the new needed methods (with the ones > from the GERONIMO-2413 patch) and when the given password > is null for read-only method, try to use the internal password. > > However, I'm wondering if the private key password problem > could be solved by using the java.lang.SecurityManager. > > > On 10/18/06, Vamsavardhana Reddy <[EMAIL PROTECTED]> wrote: >> Hi Guillaume, >> >> To make the CA Portlet >> (http://issues.apache.org/jira/browse/GERONIMO-2413) use a >> KeystoreInstance to store its keys, I have added a getCertificate >> () and >> getPrivateKey() methods. >> >> Now coming to the methods you need, except for getPrivateKey(), >> it may be >> alright to provide methods in KeystoreInstance not to require >> keystore >> password and these would succeed only if the keystore is unlocked >> for "use". >> We should make getPrivateKey() method always require a keyPassword. >> >> Vamsi >> >> >> On 10/18/06, Guillaume Nodet < [EMAIL PROTECTED]> wrote: >> > I'm trying to look at integrating ServiceMix >> > security in Geronimo. Security in ServiceMix >> > has several different aspects, but one of them >> > is to be able to encrypt / decrypt, sign messages >> > using WS-Security. >> > I have defined in ServiceMix a Crypto [1] implementation [2] >> > (used by wss4j) on top of a servicemix K
Re: WS-Security and Geronimo KeystoreInstance
How does the java security mechanism integrates with JAAS and / or JACC ? Btw, one of the problem I see (but this may not be a problem, I'm not very proficient in this area), is that the console requires a password to edit the keystore. We can not just use the user provided when logging in the console... On 10/18/06, David Jencks <[EMAIL PROTECTED]> wrote: I'm wondering if we can solve this using JAAS and java security and maybe even JACC?? I haven't checked to see if there are already permission checks on the keystore methods. If not, I'd suggest defining an appropriate permission and checking it. For the password I suggest using a LoginModule to attach a private credential to the Subject for those authorized to unlock and/or use the keystore. The methods wouldn't need to have the password as a parameter, it could be extracted from the Subject. thanks david jencks On Oct 18, 2006, at 7:25 AM, Guillaume Nodet wrote: > Yeah, I do understand that the key password has to be provided. > > I see three different ways I could handle the modification: > 1) duplicate all methods that are read-only wrt to the keystore > and remove the keystore password (it would use the internal one) > 2) remove the keystore password on existing methods > 3) assume that when password is null, it uses the internal one > > The second method can not really be used, because the internal > password is only set when the keystore is unlocked for use. > The first one is not really clean imho, so I would go for the third > option. > > Btw, I found several problems in the current implementation. > Some edition methods do not have a password given, so they > use the internal one. This means that they fail when executing > the method on a keystore that is locked for use. This can be > reproduce if you try to delete an entry from a locked keystore. > It seems to be the case for > * deleteEntry > * importPKCS7Certificate > * generateCSR > > I will try to fix these, add the new needed methods (with the ones > from the GERONIMO-2413 patch) and when the given password > is null for read-only method, try to use the internal password. > > However, I'm wondering if the private key password problem > could be solved by using the java.lang.SecurityManager. > > > On 10/18/06, Vamsavardhana Reddy <[EMAIL PROTECTED]> wrote: >> Hi Guillaume, >> >> To make the CA Portlet >> (http://issues.apache.org/jira/browse/GERONIMO-2413) use a >> KeystoreInstance to store its keys, I have added a getCertificate >> () and >> getPrivateKey() methods. >> >> Now coming to the methods you need, except for getPrivateKey(), >> it may be >> alright to provide methods in KeystoreInstance not to require >> keystore >> password and these would succeed only if the keystore is unlocked >> for "use". >> We should make getPrivateKey() method always require a keyPassword. >> >> Vamsi >> >> >> On 10/18/06, Guillaume Nodet < [EMAIL PROTECTED]> wrote: >> > I'm trying to look at integrating ServiceMix >> > security in Geronimo. Security in ServiceMix >> > has several different aspects, but one of them >> > is to be able to encrypt / decrypt, sign messages >> > using WS-Security. >> > I have defined in ServiceMix a Crypto [1] implementation [2] >> > (used by wss4j) on top of a servicemix KeystoreInstance [3] >> > (which is quite the same as the Geronimo one). >> > The main differences are 2 new methods (getCertificateChain and >> > getCertificateAlias) and the fact that the methods do not need >> > the keystore password in the parameters. >> > >> > I had a close look at the Geronimo KeystoreInstance and found >> > that nearly all methods are called from the console only. The only >> > real methods used inside the server are when an SSLSocketFactory >> > is created. >> > >> > So I'm wondering what is the best way to go. I can easily add >> the two new >> > methods to the KeystoreInstance, but the need to give the password >> > for all the calls is a bit disturbing. I need to access the >> following >> methods: >> > * listPrivateKeys >> > * listTrustCertificates >> > * getCertificate >> > * getCertificateAlias >> > * getCertificateChain >> > * getPrivateKey >> > >> > Would it be possible from the FileKeystoreInstance to use the >> > keystorePassword attribute instead of passing the password >> > in the parameters ? I do understand that this may be a security >> > hole, as the private keys would be available to everyone inside >> > the server, so I'm willing to find a better way ... >> > >> > Any ideas ? >> > >> > >> > [1] >> http://ws.apache.org/wss4j/apidocs/org/apache/ws/security/ >> components/crypto/Crypto.html >> > [2] >> http://svn.apache.org/viewvc/incubator/servicemix/trunk/servicemix- >> soap/src/main/java/org/apache/servicemix/soap/handlers/security/ >> KeystoreInstanceCrypto.java?view=markup >> > [3] >> http://svn.apache.org/viewvc/incubator/servicemix/trunk/servicemix- >> core/src/main/java/org/apache/servicemix/jbi/security/keystore/ >> K
Re: [ANNOUNCE] Please welcome Christopher M. Cardona as our newest Committer
Congrats ! On 10/18/06, Gianny Damour <[EMAIL PROTECTED]> wrote: Hi, The Geronimo PMC is pleased to announce that Christopher M. Cardona has recently accepted our invitation to become an Apache Geronimo Committer. Over the past few months, Chris has been working on the improvement of the Server Console and has demonstrated initiatives and a noteworthy ability to work with others. Congratulations and Welcome Christopher! -- Cheers, Guillaume Nodet
Re: [ANNOUNCE] Please welcome Vamsavardhana Reddy as one of our newest Committer
Congrats ! On 10/18/06, Alan Cabrera <[EMAIL PROTECTED]> wrote: The Geronimo PMC is pleased to announce that Vamsavardhana Reddy has recently accepted our invitation to become an Apache Geronimo Committer. Vamsi has been submitting many great patches for an embarrassing long time. The breadth of his patches is remarkable but we are excited by the possibility of him working on security. Congratulations and welcome Vamsi! Regards, Alan -- Apache Geronimo - http://geronimo.apache.org Apache Yoko - http://incubator.apache.org/yoko LiveTribe - http://www.livetribe.org -- Cheers, Guillaume Nodet
Re: WS-Security and Geronimo KeystoreInstance
I came with the following interface definition: http://pastebin.ca/208852 As stated by Vamsavardhana, nearly all methods have a char[] storePassword parameter, which MUST be non-null for editing the keystore (adding keys, locking / unlocking, removing keys, etc ...). Other read-only methods use this parameter the following way: 1) if a null parameter is provided, it means the call comes from a "service" (http ssl factory creation from jetty / tomcat, servicemix, etc ...). The keystore must have been previously unlocked for use and the operation will use the stored password to access the keystore 2) if a non-null parameter is provided, it means the caller is the "console" in which case, the operation will be performed using the provided password. I have also rewritten the exception handling. All exceptions now derive from the KeystoreException, and all methods throw an exception when a problem arise (instead of just logging it or returning null). These would allow to clean a bit the keystore portlets which * do not report any error * mess everything if you provided a wrong password * some operations fail if you have not unlocked the keystore for use (because some operations use the internal password instead of using the one provided by the console). The only problem left is for accessing the PrivateKey. I'm not very at ease with the java security check, but I feel that it could solve the problem better. On 10/18/06, Vamsavardhana Reddy <[EMAIL PROTECTED]> wrote: Aaron, I forgot to add that my previous mail is applicable to "read-only" service methods like getKeyManager, getCertificate etc. 1. Any edit methods (like add new certificate) will require a non null valid keystore password parameter. 2. Method to retrieve privateKey will require the key-password parameter. Vamsi On 10/19/06, Aaron Mulder <[EMAIL PROTECTED]> wrote: > On 10/18/06, Vamsavardhana Reddy <[EMAIL PROTECTED]> wrote: > > David, > > > > Myself and Guillaume had a discussion on IRC and come up with a conclusion > > that all methods should require storePassword. If the null is passed as > > storePassword and the keystore is not unlocked for "use" the methods will > > throw an Exception. Otherwise the method will use the storePassword > > provided as parameter. Keystores portlet will be supplying the > > storePassword in the method calls and others (like HTTPSConnector) will only > > be able to use the methods if the keystore is unlocked for "use". > > > > Have me missed something? > > If a keystore is unlocked for "use", I didn't think that should give > any user a free pass to edit the keystore. For example, if I > configure SSL and the keystore, should you as a random application > user be able to do a GBean query to fetch the keystore manager, and > then invoke methods to, say, export the private key, or add new > different private keys and delete the current one, and stuff like > that? I think that's bad -- I'd be against any solution like that. > It sounds like you're saying that once the keystore is unlocked > anybody has full access just by setting the password to null. > > If there is any way to cleanly separate the methods needed by server > components at runtime from methods that let users inspect and > manipulate the contents of the keystore, that would be ideal. It > worked for SSL where we could cough up a socket factory for server > callers rather than producing the actual key material, but it sounds > like this is not going to work for ServiceMix. Maybe we can create a > similar wrapper around the calls needed by ServiceMix where our > wrapper class handles the key material and never exposes it directly > to callers, and that's what could be unlocked for "use"? > > Thanks, > Aaron > -- Cheers, Guillaume Nodet
Re: Download page incorrectly lists "OS X" and "Unix" as being compatible
Maybe we can add something like this at the top of the download page J2EE Certified! <- title Apache Geronimo is certified in the full J2EE 1.4 stack on Linux and Windows platforms. and then, as Joe said, entirely remove the "J2EE 1.4 Certified Releases" from the individual download sections. Do we need to disclose anything in particular for Little-G being a subset of the "Big-G"? Cheers! Hernan Joe Bohn wrote: Geir Magnusson Jr. wrote: They aren't tested. Can we put a separate section (or a separate page) for the non-certified downloads? geir IIUC you are concerned about the heading "J2EE 1.4 Certified Releases" followed by "Linux/Mac OS X/Unix Downloads". Those downloads are for those various platforms listed even if we only certified against a subset of the list. Would it be better to just remove the word "certified" from the earlier heading? If necessary, we could specify somewhere else on the download page that we actually only certified against Linux and Windows. What do you think? Joe
Re: Download page incorrectly lists "OS X" and "Unix" as being compatible
Geir Magnusson Jr. wrote: They aren't tested. Can we put a separate section (or a separate page) for the non-certified downloads? geir IIUC you are concerned about the heading "J2EE 1.4 Certified Releases" followed by "Linux/Mac OS X/Unix Downloads". Those downloads are for those various platforms listed even if we only certified against a subset of the list. Would it be better to just remove the word "certified" from the earlier heading? If necessary, we could specify somewhere else on the download page that we actually only certified against Linux and Windows. What do you think? Joe
Download page incorrectly lists "OS X" and "Unix" as being compatible
They aren't tested. Can we put a separate section (or a separate page) for the non-certified downloads? geir
Re: [ANNOUNCE] Please welcome Christopher M. Cardona as our newest Committer
On 10/18/06, Gianny Damour <[EMAIL PROTECTED]> wrote: Hi, The Geronimo PMC is pleased to announce that Christopher M. Cardona has recently accepted our invitation to become an Apache Geronimo Committer. Over the past few months, Chris has been working on the improvement of the Server Console and has demonstrated initiatives and a noteworthy ability to work with others. Congratulations and Welcome Christopher! I'm getting used to see more and more AJAX bits in the console and I believe Chris will keep'em coming! Congrats Chris! Jacek -- Jacek Laskowski http://www.laskowski.net.pl
Re: [ANNOUNCE] Please welcome Vamsavardhana Reddy as one of our newest Committer
On 10/18/06, Alan Cabrera <[EMAIL PROTECTED]> wrote: The Geronimo PMC is pleased to announce that Vamsavardhana Reddy has recently accepted our invitation to become an Apache Geronimo Committer. Vamsi has been submitting many great patches for an embarrassing long time. The breadth of his patches is remarkable but we are excited by the possibility of him working on security. Congratulations and welcome Vamsi! Whow! Awesome! Another committer - nice. It looks like v1.2 is going to be a solid rock and will beat the competition easily. Congrats Vamsi! Jacek -- Jacek Laskowski http://www.laskowski.net.pl
Re: WS-Security and Geronimo KeystoreInstance
Aaron, I forgot to add that my previous mail is applicable to "read-only" service methods like getKeyManager, getCertificate etc. 1. Any edit methods (like add new certificate) will require a non null valid keystore password parameter. 2. Method to retrieve privateKey will require the key-password parameter. VamsiOn 10/19/06, Aaron Mulder <[EMAIL PROTECTED]> wrote: On 10/18/06, Vamsavardhana Reddy <[EMAIL PROTECTED]> wrote:> David,>> Myself and Guillaume had a discussion on IRC and come up with a conclusion> that all methods should require storePassword. If the null is passed as > storePassword and the keystore is not unlocked for "use" the methods will> throw an Exception. Otherwise the method will use the storePassword> provided as parameter. Keystores portlet will be supplying the > storePassword in the method calls and others (like HTTPSConnector) will only> be able to use the methods if the keystore is unlocked for "use".>> Have me missed something?If a keystore is unlocked for "use", I didn't think that should give any user a free pass to edit the keystore. For example, if Iconfigure SSL and the keystore, should you as a random applicationuser be able to do a GBean query to fetch the keystore manager, andthen invoke methods to, say, export the private key, or add new different private keys and delete the current one, and stuff likethat? I think that's bad -- I'd be against any solution like that.It sounds like you're saying that once the keystore is unlockedanybody has full access just by setting the password to null. If there is any way to cleanly separate the methods needed by servercomponents at runtime from methods that let users inspect andmanipulate the contents of the keystore, that would be ideal. Itworked for SSL where we could cough up a socket factory for server callers rather than producing the actual key material, but it soundslike this is not going to work for ServiceMix. Maybe we can create asimilar wrapper around the calls needed by ServiceMix where ourwrapper class handles the key material and never exposes it directly to callers, and that's what could be unlocked for "use"?Thanks, Aaron
Re: WS-Security and Geronimo KeystoreInstance
On 10/18/06, Vamsavardhana Reddy <[EMAIL PROTECTED]> wrote: David, Myself and Guillaume had a discussion on IRC and come up with a conclusion that all methods should require storePassword. If the null is passed as storePassword and the keystore is not unlocked for "use" the methods will throw an Exception. Otherwise the method will use the storePassword provided as parameter. Keystores portlet will be supplying the storePassword in the method calls and others (like HTTPSConnector) will only be able to use the methods if the keystore is unlocked for "use". Have me missed something? If a keystore is unlocked for "use", I didn't think that should give any user a free pass to edit the keystore. For example, if I configure SSL and the keystore, should you as a random application user be able to do a GBean query to fetch the keystore manager, and then invoke methods to, say, export the private key, or add new different private keys and delete the current one, and stuff like that? I think that's bad -- I'd be against any solution like that. It sounds like you're saying that once the keystore is unlocked anybody has full access just by setting the password to null. If there is any way to cleanly separate the methods needed by server components at runtime from methods that let users inspect and manipulate the contents of the keystore, that would be ideal. It worked for SSL where we could cough up a socket factory for server callers rather than producing the actual key material, but it sounds like this is not going to work for ServiceMix. Maybe we can create a similar wrapper around the calls needed by ServiceMix where our wrapper class handles the key material and never exposes it directly to callers, and that's what could be unlocked for "use"? Thanks, Aaron
Re: WS-Security and Geronimo KeystoreInstance
David, Myself and Guillaume had a discussion on IRC and come up with a conclusion that all methods should require storePassword. If the null is passed as storePassword and the keystore is not unlocked for "use" the methods will throw an Exception. Otherwise the method will use the storePassword provided as parameter. Keystores portlet will be supplying the storePassword in the method calls and others (like HTTPSConnector) will only be able to use the methods if the keystore is unlocked for "use". Have me missed something? VamsiOn 10/19/06, David Jencks <[EMAIL PROTECTED]> wrote: On Oct 18, 2006, at 11:14 AM, Aaron Mulder wrote:> This is a good conversation to have -- all the options we've> considered previously seem bad in some way or other.>> The original goals were: > 1) require that a user enter a password to view or manipulate the> keystore> 2) provide a way for the server to remember the password(s) needed at> runtime, but still respecting #1 (that is, just because the server is > going to use SSL, don't make that a back door for anyone to view/edit> the keystore contents)> 3) Don't leave the keystore/key passwords lying around in the> configuration for any callers (Jetty, Tomcat, ServiceMix, etc.)... > with #2, this led to the idea of a keystore "unlocked" for usage by> server components but not for editing, and with #1 led to the separate> "unlocked for editing" bit.> > The side effects are kind of muddled usage contracts, and the problem> that if the keystore is fully locked and you still enable SSL then> Geronimo won't start.>> It looks like ServiceMix needs pretty extensive access to the keystore > -- more extensive than HTTPS requires even.>> I wonder if we should take all the keystore passwords out of the> current API and have a method on the keystore manager where it gets a> password somehow and it gives the caller an unlocked read-only > keystore -- for HTTPS and ServiceMix to use (though we'd still need to> deal with private key passwords?). Then it could have a separate> method where the caller gives it a password and it gives you an > unlocked read/write keystore -- for the console or other user tools to> use. We could attempt to restrict access to the two methods> separately, with java.lang.security permissions or whatever. I guess > that suggests we might need two separate GBeans, one read-only and one> read-write, or something like that. But we wouldn't want people to be> able to just do a GBean query to get an unlocked keystore. >> This still doesn't solve the problem that if the keystore is not> "unlocked" then the server won't start.This might get back to the idea I've had for a while that you shouldneed some credentials to start the server, and that the server should be running as whatever user you started it as.>> I still don't see a great solution. Maybe the JAAS thing would help> but I don't see how you'd arrange for all the password(s) to be> available at the time the login module was executed (especially since > you can add private keys at runtime). More discussion would be good.> :)I don't see a way to do that either. I guess I need to understandthe use cases better.thanksdavid jencks >> Thanks,>Aaron>> On 10/18/06, David Jencks <[EMAIL PROTECTED]> wrote:>> I'm wondering if we can solve this using JAAS and java security and >> maybe even JACC?? I haven't checked to see if there are already permission checks on>> the keystore methods. If not, I'd suggest defining an appropriate>> permission and checking it. For the password I suggest using a LoginModule to attach a private>> credential to the Subject for those authorized to unlock and/or use>> the keystore. The methods wouldn't need to have the password as a >> parameter, it could be extracted from the Subject. thanks>> david jencks>> On Oct 18, 2006, at 7:25 AM, Guillaume Nodet wrote:>> >> > Yeah, I do understand that the key password has to be provided.>> >>> > I see three different ways I could handle the modification:>> > 1) duplicate all methods that are read-only wrt to the keystore >> > and remove the keystore password (it would use the internal>> one)>> > 2) remove the keystore password on existing methods>> > 3) assume that when password is null, it uses the internal one >> >>> > The second method can not really be used, because the internal>> > password is only set when the keystore is unlocked for use.>> > The first one is not really clean imho, so I would go for the third >> > option.>> >>> > Btw, I found several problems in the current implementation.>> > Some edition methods do not have a password given, so they>> > use the internal one. This means that they fail when executing >> > the method on a keystore that is locked for use. This can be>> > reproduce if you try to delete an entry from a locked keystore.>> > It seems to be the case for>> > * deleteEntry >> > * importPKCS7Certificate>> > * generateCSR>> >>> > I will try to fix these, add the new needed methods (wi
Re: WS-Security and Geronimo KeystoreInstance
On Oct 18, 2006, at 11:14 AM, Aaron Mulder wrote: This is a good conversation to have -- all the options we've considered previously seem bad in some way or other. The original goals were: 1) require that a user enter a password to view or manipulate the keystore 2) provide a way for the server to remember the password(s) needed at runtime, but still respecting #1 (that is, just because the server is going to use SSL, don't make that a back door for anyone to view/edit the keystore contents) 3) Don't leave the keystore/key passwords lying around in the configuration for any callers (Jetty, Tomcat, ServiceMix, etc.)... with #2, this led to the idea of a keystore "unlocked" for usage by server components but not for editing, and with #1 led to the separate "unlocked for editing" bit. The side effects are kind of muddled usage contracts, and the problem that if the keystore is fully locked and you still enable SSL then Geronimo won't start. It looks like ServiceMix needs pretty extensive access to the keystore -- more extensive than HTTPS requires even. I wonder if we should take all the keystore passwords out of the current API and have a method on the keystore manager where it gets a password somehow and it gives the caller an unlocked read-only keystore -- for HTTPS and ServiceMix to use (though we'd still need to deal with private key passwords?). Then it could have a separate method where the caller gives it a password and it gives you an unlocked read/write keystore -- for the console or other user tools to use. We could attempt to restrict access to the two methods separately, with java.lang.security permissions or whatever. I guess that suggests we might need two separate GBeans, one read-only and one read-write, or something like that. But we wouldn't want people to be able to just do a GBean query to get an unlocked keystore. This still doesn't solve the problem that if the keystore is not "unlocked" then the server won't start. This might get back to the idea I've had for a while that you should need some credentials to start the server, and that the server should be running as whatever user you started it as. I still don't see a great solution. Maybe the JAAS thing would help but I don't see how you'd arrange for all the password(s) to be available at the time the login module was executed (especially since you can add private keys at runtime). More discussion would be good. :) I don't see a way to do that either. I guess I need to understand the use cases better. thanks david jencks Thanks, Aaron On 10/18/06, David Jencks <[EMAIL PROTECTED]> wrote: I'm wondering if we can solve this using JAAS and java security and maybe even JACC?? I haven't checked to see if there are already permission checks on the keystore methods. If not, I'd suggest defining an appropriate permission and checking it. For the password I suggest using a LoginModule to attach a private credential to the Subject for those authorized to unlock and/or use the keystore. The methods wouldn't need to have the password as a parameter, it could be extracted from the Subject. thanks david jencks On Oct 18, 2006, at 7:25 AM, Guillaume Nodet wrote: > Yeah, I do understand that the key password has to be provided. > > I see three different ways I could handle the modification: > 1) duplicate all methods that are read-only wrt to the keystore > and remove the keystore password (it would use the internal one) > 2) remove the keystore password on existing methods > 3) assume that when password is null, it uses the internal one > > The second method can not really be used, because the internal > password is only set when the keystore is unlocked for use. > The first one is not really clean imho, so I would go for the third > option. > > Btw, I found several problems in the current implementation. > Some edition methods do not have a password given, so they > use the internal one. This means that they fail when executing > the method on a keystore that is locked for use. This can be > reproduce if you try to delete an entry from a locked keystore. > It seems to be the case for > * deleteEntry > * importPKCS7Certificate > * generateCSR > > I will try to fix these, add the new needed methods (with the ones > from the GERONIMO-2413 patch) and when the given password > is null for read-only method, try to use the internal password. > > However, I'm wondering if the private key password problem > could be solved by using the java.lang.SecurityManager. > > > On 10/18/06, Vamsavardhana Reddy <[EMAIL PROTECTED]> wrote: >> Hi Guillaume, >> >> To make the CA Portlet >> (http://issues.apache.org/jira/browse/GERONIMO-2413) use a >> KeystoreInstance to store its keys, I have added a getCertificate >> () and >> getPrivateKey() methods. >> >> Now coming to the methods you need, except for getPrivateKey(), >> it may be >> alright to provide methods in KeystoreInstance not to require >> keysto
JSTL 1.2 for JEE 5
I'm looking at what it would take to include an implementation of JSTL 1.2 (JSR 52) for compliance with JEE 5 in Geronimo. We currently include the Jakarta implementation of the 1.1 spec in some of our web applications (such as the web console) but not directly in the Geronimo J2EE server. I think the first order of business is to see if I can pick up an open source implementation and spec from someplace. I asked on the Jakarta taglibs user mailing list and was told that there is not an effort underway to implement the 1.2 version of this spec. They then pointed me to Glassfish. So, I'm planning to investigate what it would take to include the Glassfish implementation into Geronimo. If any body has any concerns/objections/recommendations/insight/etc... please speak up. Thanks, Joe
Re: [ANNOUNCE] Please welcome Vamsavardhana Reddy as one of our newest Committer
Congratulations Vamsi! Joe Alan Cabrera wrote: The Geronimo PMC is pleased to announce that Vamsavardhana Reddy has recently accepted our invitation to become an Apache Geronimo Committer. Vamsi has been submitting many great patches for an embarrassing long time. The breadth of his patches is remarkable but we are excited by the possibility of him working on security. Congratulations and welcome Vamsi! Regards, Alan -- Apache Geronimo - http://geronimo.apache.org Apache Yoko - http://incubator.apache.org/yoko LiveTribe - http://www.livetribe.org
[jira] Closed: (DAYTRADER-11) AccountProfile field "password" conflicts with DB2 v9.1 keyword
[ http://issues.apache.org/jira/browse/DAYTRADER-11?page=all ] Matt Hogstrom closed DAYTRADER-11. -- Fix Version/s: 1.2 Resolution: Fixed Applied to trunk as it changes schemas and is inappropriate for 1.x releases. > AccountProfile field "password" conflicts with DB2 v9.1 keyword > --- > > Key: DAYTRADER-11 > URL: http://issues.apache.org/jira/browse/DAYTRADER-11 > Project: DayTrader > Issue Type: Improvement > Components: EJB Tier >Affects Versions: 1.2, 1.1, 1.1.1 > Environment: DB2 v9.1 >Reporter: Christopher James Blythe >Priority: Minor > Fix For: 1.2 > > Attachments: daytrader-11.txt > > > The DB2 v9.1 documentation now states that "password" is a reserved word that > should not be used for table/column names, etc. In the AccountProfile ejb we > use a "password" field that is mapped directly to a "password" column in the > database. > http://publib.boulder.ibm.com/infocenter/db2luw/v9/index.jsp?topic=/com.ibm.db2.udb.admin.doc/doc/r0001095.htm > In order to prevent this keyword clash, I have modified the AccountProfile > field from "password" to "passwd" and made the necessary changes in the ejb > source, TradeDirect, sql schema, and plan files. > The associated patch is attached... -- 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] Commented: (DAYTRADER-14) Include sql script in the ear and use a gbean to create tables etc
[ http://issues.apache.org/jira/browse/DAYTRADER-14?page=comments#action_12443329 ] Piyush Agarwal commented on DAYTRADER-14: - I almost have the entire changes done which are required to make the above work. On testing the drop tables and repopulate against Daytrader I came across a problem in repopulation part which was causing DuplicateKeyException to be thrown. On analyzing I realized that the repopulate db part which my code was calling after recreating the tables never deleted/repopulated the KeyGen table. The KeySequenceDirect and KeySequenceBean cache blocks of Ids from this keygen table and use them for holdings, orders etc. When the table is deleted, the caches dont realize this and continue allocating ids from the cache until they run-out and go to the table to get new block of ids. Since the table is re-created, the ids which were used before from the cache are re-generated causing DuplicateKeyExceptions. To solve this I thought of two options - 1) Do not drop the keyGen table in my ddl script. The attempt to create the KeyGen table will fail with SQLException in case it already exists. This will cause the repopulate code to work as-is and prevent the DuplicateKeyException. 2) The cleaner way (avoiding all exceptions) will be to signal the KeySequenceDirect and KeySequenceBean (depending on Direct or EJB mode) to drop their cached blocks when the repopulation of the tables is being done. This will require some code to be added to the above classes but I think its still do-able without a lot of new code. Also this will be the right way of doing it. So currently I am going to evaluate the Option 2 unless anyone has something better in mind. > Include sql script in the ear and use a gbean to create tables etc > -- > > Key: DAYTRADER-14 > URL: http://issues.apache.org/jira/browse/DAYTRADER-14 > Project: DayTrader > Issue Type: Improvement > Components: EJB Tier >Affects Versions: 1.2 >Reporter: David Jencks > Attachments: d-j-plan.xml, DAYTRADER-14.patch > > > You can use the DatabaseIntitializationGBean (GERONIMO-2396) in a g. plan and > include the sql script in the ejb module so the database will get created if > not already present. This is way better than the previous hack of including a > pre-built database in the car file. -- 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: (AMQ-992) MySQL doesn't honor lock in JDBC Master Slave configuration?
MySQL doesn't honor lock in JDBC Master Slave configuration? Key: AMQ-992 URL: https://issues.apache.org/activemq/browse/AMQ-992 Project: ActiveMQ Issue Type: Bug Affects Versions: 4.1 Environment: RHEL 4 MySQL 4.x, 5.x mysql-ab_jdbc_driver Reporter: Steven Lotito Attachments: mysql_obtain_lock.txt I have been attempting to get the new 4.1 JDBC Master Slave configuration working with MySQL. The log from the first broker to start up states: 2006-10-18 09:35:08,558 [main ] INFO DefaultDatabaseLocker - Attempting to acquire the exclusive lock to become the Master broker 2006-10-18 09:35:08,559 [main ] INFO DefaultDatabaseLocker - Becoming the master on dataSource: [EMAIL PROTECTED] The 2nd broker to start up has an identical message and both brokers listen for connections. The 2nd broker should be waiting for the lock and NOT accepting connections, if I understand http://www.activemq.org/site/jdbc-master-slave.html correctly... Oracle exhibits the expected behavior: When running the exact same configuration (except using an Oracle datasource), the first broker has the same log message as above, while the 2nd broker halts at the "Attempting to acquire the exclusive lock to become the Master broker" message until I fail the master. Then it becomes the master. Is this a known issue? I was able to replicate it using both MySql 4 and 5 (trying both the MySQL Connector/J 3.1 and MySQL Connector/J 5.0 drivers) -- 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 Servicemix 3.0.1
+1
On 17 Oct 2006, at 21:38, Bruce Snyder wrote:
On 10/16/06, Guillaume Nodet <[EMAIL PROTECTED]> wrote:
I'd like to start the release process for 3.0.1.
The list of bugs fixed in 3.0.1 is available at
http://issues.apache.org/activemq/secure/IssueNavigator.jspa?
view=&decorator=printable&start=0&fixfor=11716&mode=hide&reset=true&p
id=10950&tempMax=1000
[ ] +1 Release servicemix 3.0.1
[ ] 0 Abstain
[ ] -1 Do not release servicemix 3.0.1
Here's my +1
+1
Bruce
--
perl -e 'print unpack("u30","D0G)[EMAIL PROTECTED]&5R\"F)R=6-E+G-N>61EG;6%I;\"YC;VT*"
);'
Apache Geronimo - http://geronimo.apache.org/
Apache ActiveMQ - http://incubator.apache.org/activemq/
Apache ServiceMix - http://incubator.apache.org/servicemix/
Castor - http://castor.org/
Re: WS-Security and Geronimo KeystoreInstance
This is a good conversation to have -- all the options we've considered previously seem bad in some way or other. The original goals were: 1) require that a user enter a password to view or manipulate the keystore 2) provide a way for the server to remember the password(s) needed at runtime, but still respecting #1 (that is, just because the server is going to use SSL, don't make that a back door for anyone to view/edit the keystore contents) 3) Don't leave the keystore/key passwords lying around in the configuration for any callers (Jetty, Tomcat, ServiceMix, etc.)... with #2, this led to the idea of a keystore "unlocked" for usage by server components but not for editing, and with #1 led to the separate "unlocked for editing" bit. The side effects are kind of muddled usage contracts, and the problem that if the keystore is fully locked and you still enable SSL then Geronimo won't start. It looks like ServiceMix needs pretty extensive access to the keystore -- more extensive than HTTPS requires even. I wonder if we should take all the keystore passwords out of the current API and have a method on the keystore manager where it gets a password somehow and it gives the caller an unlocked read-only keystore -- for HTTPS and ServiceMix to use (though we'd still need to deal with private key passwords?). Then it could have a separate method where the caller gives it a password and it gives you an unlocked read/write keystore -- for the console or other user tools to use. We could attempt to restrict access to the two methods separately, with java.lang.security permissions or whatever. I guess that suggests we might need two separate GBeans, one read-only and one read-write, or something like that. But we wouldn't want people to be able to just do a GBean query to get an unlocked keystore. This still doesn't solve the problem that if the keystore is not "unlocked" then the server won't start. I still don't see a great solution. Maybe the JAAS thing would help but I don't see how you'd arrange for all the password(s) to be available at the time the login module was executed (especially since you can add private keys at runtime). More discussion would be good. :) Thanks, Aaron On 10/18/06, David Jencks <[EMAIL PROTECTED]> wrote: I'm wondering if we can solve this using JAAS and java security and maybe even JACC?? I haven't checked to see if there are already permission checks on the keystore methods. If not, I'd suggest defining an appropriate permission and checking it. For the password I suggest using a LoginModule to attach a private credential to the Subject for those authorized to unlock and/or use the keystore. The methods wouldn't need to have the password as a parameter, it could be extracted from the Subject. thanks david jencks On Oct 18, 2006, at 7:25 AM, Guillaume Nodet wrote: > Yeah, I do understand that the key password has to be provided. > > I see three different ways I could handle the modification: > 1) duplicate all methods that are read-only wrt to the keystore > and remove the keystore password (it would use the internal one) > 2) remove the keystore password on existing methods > 3) assume that when password is null, it uses the internal one > > The second method can not really be used, because the internal > password is only set when the keystore is unlocked for use. > The first one is not really clean imho, so I would go for the third > option. > > Btw, I found several problems in the current implementation. > Some edition methods do not have a password given, so they > use the internal one. This means that they fail when executing > the method on a keystore that is locked for use. This can be > reproduce if you try to delete an entry from a locked keystore. > It seems to be the case for > * deleteEntry > * importPKCS7Certificate > * generateCSR > > I will try to fix these, add the new needed methods (with the ones > from the GERONIMO-2413 patch) and when the given password > is null for read-only method, try to use the internal password. > > However, I'm wondering if the private key password problem > could be solved by using the java.lang.SecurityManager. > > > On 10/18/06, Vamsavardhana Reddy <[EMAIL PROTECTED]> wrote: >> Hi Guillaume, >> >> To make the CA Portlet >> (http://issues.apache.org/jira/browse/GERONIMO-2413) use a >> KeystoreInstance to store its keys, I have added a getCertificate >> () and >> getPrivateKey() methods. >> >> Now coming to the methods you need, except for getPrivateKey(), >> it may be >> alright to provide methods in KeystoreInstance not to require >> keystore >> password and these would succeed only if the keystore is unlocked >> for "use". >> We should make getPrivateKey() method always require a keyPassword. >> >> Vamsi >> >> >> On 10/18/06, Guillaume Nodet < [EMAIL PROTECTED]> wrote: >> > I'm trying to look at integrating ServiceMix >> > security in Geronimo. Security in ServiceMix >> > has several different aspect
Re: [ANNOUNCE] Please welcome Vamsavardhana Reddy as one of our newest Committer
Congrats Vamsi! gr8 to see a committer from India.Rgds/Bharath.On 10/18/06, Alan Cabrera <[EMAIL PROTECTED] > wrote:The Geronimo PMC is pleased to announce that Vamsavardhana Reddy has recently accepted our invitation to become an Apache Geronimo Committer. Vamsi has been submitting many great patches for an embarrassing long time. The breadth of his patches is remarkable but we are excited by the possibility of him working on security. Congratulations and welcome Vamsi! Regards,Alan--Apache Geronimo - http://geronimo.apache.orgApache Yoko - http://incubator.apache.org/yokoLiveTribe - http://www.livetribe.org
Re: [ANNOUNCE] Please welcome Vamsavardhana Reddy as one of our newest Committer
Congratulations!On Oct 18, 2006, at 11:40 AM, Alan Cabrera wrote:The Geronimo PMC is pleased to announce that Vamsavardhana Reddy has recently accepted our invitation to become an Apache Geronimo Committer. Vamsi has been submitting many great patches for an embarrassing long time. The breadth of his patches is remarkable but we are excited by the possibility of him working on security.Congratulations and welcome Vamsi!Regards,Alan--Apache Geronimo - http://geronimo.apache.orgApache Yoko - http://incubator.apache.org/yokoLiveTribe - http://www.livetribe.org -sachin
Re: [ANNOUNCE] Please welcome Vamsavardhana Reddy as one of our newest Committer
Congrats Vamsi! Cheers! Hernan Alan Cabrera wrote: The Geronimo PMC is pleased to announce that Vamsavardhana Reddy has recently accepted our invitation to become an Apache Geronimo Committer. Vamsi has been submitting many great patches for an embarrassing long time. The breadth of his patches is remarkable but we are excited by the possibility of him working on security. Congratulations and welcome Vamsi! Regards, Alan -- Apache Geronimo - http://geronimo.apache.org Apache Yoko - http://incubator.apache.org/yoko LiveTribe - http://www.livetribe.org
Re: [ANNOUNCE] Please welcome Vamsavardhana Reddy as one of our newest Committer
Congrats Vamsi !! chris Alan Cabrera wrote: The Geronimo PMC is pleased to announce that Vamsavardhana Reddy has recently accepted our invitation to become an Apache Geronimo Committer. Vamsi has been submitting many great patches for an embarrassing long time. The breadth of his patches is remarkable but we are excited by the possibility of him working on security. Congratulations and welcome Vamsi! Regards, Alan -- Apache Geronimo - http://geronimo.apache.org Apache Yoko - http://incubator.apache.org/yoko LiveTribe - http://www.livetribe.org
Re: [ANNOUNCE] Please welcome Vamsavardhana Reddy as one of our newest Committer
Hey Vamsi, Congrats ! Cheers Prasad On 10/18/06, Paul McMahan <[EMAIL PROTECTED]> wrote: Congrats Vamsi! Paul On 10/18/06, Alan Cabrera <[EMAIL PROTECTED]> wrote: > > The Geronimo PMC is pleased to announce that Vamsavardhana Reddy has > recently accepted our invitation to become an Apache Geronimo Committer. > Vamsi has been submitting many great patches for an embarrassing long time. > The breadth of his patches is remarkable but we are excited by the > possibility of him working on security. > > Congratulations and welcome Vamsi! > > > Regards, > Alan > > -- > Apache Geronimo - http://geronimo.apache.org > Apache Yoko - http://incubator.apache.org/yoko > LiveTribe - http://www.livetribe.org > > > > >
Re: [Results] Priorities for 1.2
On Oct 18, 2006, at 8:37 AM, Alan D. Cabrera wrote:On Oct 18, 2006, at 12:24 AM, David Jencks wrote:On Oct 17, 2006, at 11:02 PM, Alan D. Cabrera wrote:On Oct 10, 2006, at 8:28 AM, Matt Hogstrom wrote:Thanks Alan ... I figured that was the plan but thought I should ask than assume :)Jencks is encouraging me to fix some of the TranQL problems in TCK so I'm updating my copy to 1.2. I simply can't wait to start running the TCK :-PGreat. I'm thinking that we can try to cut a real release by the end of this month and run it through the TCK wringer. What does everyone think?I was thinking more in terms of getting the tck to pass and then cutting a release. Otherwise we run the risk of having months of work on 2 codebases to get the tck to pass. Experience has shown me that we can't apply fixes to 2 codebases very well.Good point. Unfortunately the TCK licensing prevents us from providing an estimate on when this will happen.To me the main open question about 1.2 is whether we can certify on j2ee 1.4 with jee5 spec libraries. If so it is fairly simple to include jee5 preview features. If not we are going to have to jump through a lot of hoops to demonstrate any jee5 functionality. I haven't heard back from Geir with any news from sun on this question.Can you explain your comment about "we are going to have to jump through a lot of hoops to demonstrate any jee5 functionality"? It sounds scary.Yup, I'm worried. Lets take a simple example -- the tx manager. To do jpa according to spec, we need a jta 1.1 spec jar. It's possible to swap tx manager impls using the module/config aliasing, but I don't see a way to make this easy for users other than shipping 2 separate servers, one j2ee 1.4 w/no jee5 stuff and one uncertified jee5 server. Shipping twice as many servers would strain our resources as far as keeping track of so many zips.thanksdavid jencksRegards,Alan --Apache Geronimo - http://geronimo.apache.orgApache Yoko - http://incubator.apache.org/yokoLiveTribe - http://www.livetribe.org
Re: WS-Security and Geronimo KeystoreInstance
I'm wondering if we can solve this using JAAS and java security and maybe even JACC?? I haven't checked to see if there are already permission checks on the keystore methods. If not, I'd suggest defining an appropriate permission and checking it. For the password I suggest using a LoginModule to attach a private credential to the Subject for those authorized to unlock and/or use the keystore. The methods wouldn't need to have the password as a parameter, it could be extracted from the Subject. thanks david jencks On Oct 18, 2006, at 7:25 AM, Guillaume Nodet wrote: Yeah, I do understand that the key password has to be provided. I see three different ways I could handle the modification: 1) duplicate all methods that are read-only wrt to the keystore and remove the keystore password (it would use the internal one) 2) remove the keystore password on existing methods 3) assume that when password is null, it uses the internal one The second method can not really be used, because the internal password is only set when the keystore is unlocked for use. The first one is not really clean imho, so I would go for the third option. Btw, I found several problems in the current implementation. Some edition methods do not have a password given, so they use the internal one. This means that they fail when executing the method on a keystore that is locked for use. This can be reproduce if you try to delete an entry from a locked keystore. It seems to be the case for * deleteEntry * importPKCS7Certificate * generateCSR I will try to fix these, add the new needed methods (with the ones from the GERONIMO-2413 patch) and when the given password is null for read-only method, try to use the internal password. However, I'm wondering if the private key password problem could be solved by using the java.lang.SecurityManager. On 10/18/06, Vamsavardhana Reddy <[EMAIL PROTECTED]> wrote: Hi Guillaume, To make the CA Portlet (http://issues.apache.org/jira/browse/GERONIMO-2413) use a KeystoreInstance to store its keys, I have added a getCertificate () and getPrivateKey() methods. Now coming to the methods you need, except for getPrivateKey(), it may be alright to provide methods in KeystoreInstance not to require keystore password and these would succeed only if the keystore is unlocked for "use". We should make getPrivateKey() method always require a keyPassword. Vamsi On 10/18/06, Guillaume Nodet < [EMAIL PROTECTED]> wrote: > I'm trying to look at integrating ServiceMix > security in Geronimo. Security in ServiceMix > has several different aspects, but one of them > is to be able to encrypt / decrypt, sign messages > using WS-Security. > I have defined in ServiceMix a Crypto [1] implementation [2] > (used by wss4j) on top of a servicemix KeystoreInstance [3] > (which is quite the same as the Geronimo one). > The main differences are 2 new methods (getCertificateChain and > getCertificateAlias) and the fact that the methods do not need > the keystore password in the parameters. > > I had a close look at the Geronimo KeystoreInstance and found > that nearly all methods are called from the console only. The only > real methods used inside the server are when an SSLSocketFactory > is created. > > So I'm wondering what is the best way to go. I can easily add the two new > methods to the KeystoreInstance, but the need to give the password > for all the calls is a bit disturbing. I need to access the following methods: > * listPrivateKeys > * listTrustCertificates > * getCertificate > * getCertificateAlias > * getCertificateChain > * getPrivateKey > > Would it be possible from the FileKeystoreInstance to use the > keystorePassword attribute instead of passing the password > in the parameters ? I do understand that this may be a security > hole, as the private keys would be available to everyone inside > the server, so I'm willing to find a better way ... > > Any ideas ? > > > [1] http://ws.apache.org/wss4j/apidocs/org/apache/ws/security/ components/crypto/Crypto.html > [2] http://svn.apache.org/viewvc/incubator/servicemix/trunk/servicemix- soap/src/main/java/org/apache/servicemix/soap/handlers/security/ KeystoreInstanceCrypto.java?view=markup > [3] http://svn.apache.org/viewvc/incubator/servicemix/trunk/servicemix- core/src/main/java/org/apache/servicemix/jbi/security/keystore/ KeystoreInstance.java?view=markup > > > > -- > Cheers, > Guillaume Nodet > -- Cheers, Guillaume Nodet
Re: [VOTE] Accept CIMERO code donation
+1 On 9/20/06, Guillaume Nodet wrote: I have told Bull to submit a Software Grant so that we can fill a IP Clearance for Cimero donation. We need to officially vote to accept the donation, which is the reason for this vote. [ ] +1 accept Cimero code donation [ ] 0 No opinion [ ] -1 Reject donation Here's my +1
Re: [ANNOUNCE] Please welcome Vamsavardhana Reddy as one of our newest Committer
Congrats Vamsi! Paul On 10/18/06, Alan Cabrera <[EMAIL PROTECTED]> wrote: The Geronimo PMC is pleased to announce that Vamsavardhana Reddy has recently accepted our invitation to become an Apache Geronimo Committer. Vamsi has been submitting many great patches for an embarrassing long time. The breadth of his patches is remarkable but we are excited by the possibility of him working on security. Congratulations and welcome Vamsi! Regards, Alan -- Apache Geronimo - http://geronimo.apache.org Apache Yoko - http://incubator.apache.org/yoko LiveTribe - http://www.livetribe.org
Re: [ANNOUNCE] Please welcome Vamsavardhana Reddy as one of our newest Committer
Congrats Vamsi!--kevanOn Oct 18, 2006, at 11:40 AM, Alan Cabrera wrote:The Geronimo PMC is pleased to announce that Vamsavardhana Reddy has recently accepted our invitation to become an Apache Geronimo Committer. Vamsi has been submitting many great patches for an embarrassing long time. The breadth of his patches is remarkable but we are excited by the possibility of him working on security.Congratulations and welcome Vamsi!Regards,Alan--Apache Geronimo - http://geronimo.apache.orgApache Yoko - http://incubator.apache.org/yokoLiveTribe - http://www.livetribe.org
[jira] Commented: (SM-695) Dynamic HTTP provider endpoint
[ https://issues.apache.org/activemq/browse/SM-695?page=comments#action_37232 ] James Lorenzen commented on SM-695: --- Were you able to commit the patch yesterday? I know of others wishing to checkout 3.0 and build with this new patch. > Dynamic HTTP provider endpoint > -- > > Key: SM-695 > URL: https://issues.apache.org/activemq/browse/SM-695 > Project: ServiceMix > Issue Type: New Feature > Components: servicemix-http >Affects Versions: 3.0 >Reporter: James Lorenzen >Priority: Minor > Attachments: HttpProviderTest.java, JbiConstants.java, > ProviderProcessor.java, ProviderProcessor.java > > > It would be benficial to add functionaility to the HTTP BC to allow consumers > to specify the provider locationURI through a NormalizedMessage property. > Please see this thread for related information: > http://www.nabble.com/http-endpoint-in-provider-mode%3A-dynamic-destination--tf1413771.html#a6721824 > Our team plans on adding some code to the HTTP BC that first looks to see if > the NormalizedMessage contains a specific property containing the value for > the destination. Therefore a consumer could create a new NormalizedMessage > and call setProperty to set the destination URI. If the HTTP BC detects this > property he routes the request to this URI; otherwise it continues as normal > and uses the locationURI specified in the xbean.xml file. > We plan on making and testing this change in the next couple of days. After > which we will reply back with the modifications. -- 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: [ANNOUNCE] Please welcome Vamsavardhana Reddy as one of our newest Committer
Congratulations Vamsi!AnitaAlan Cabrera <[EMAIL PROTECTED]> wrote: The Geronimo PMC is pleased to announce that Vamsavardhana Reddy has recently accepted our invitation to become an Apache Geronimo Committer. Vamsi has been submitting many great patches for an embarrassing long time. The breadth of his patches is remarkable but we are excited by the possibility of him working on security.Congratulations and welcome Vamsi!Regards,Alan--Apache Geronimo - http://geronimo.apache.orgApache Yoko - http://incubator.apache.org/yokoLiveTribe - http://www.livetribe.org Talk is cheap. Use Yahoo! Messenger to make PC-to-Phone calls. Great rates starting at 1¢/min.
Re: [ANNOUNCE] Please welcome Vamsavardhana Reddy as one of our newest Committer
Weldone Vamsi !!! Great Work !!! > The Geronimo PMC is pleased to announce that Vamsavardhana Reddy has > recently accepted our invitation to become an Apache Geronimo > Committer. Vamsi has been submitting many great patches for an > embarrassing long time. The breadth of his patches is remarkable but > we are excited by the possibility of him working on security. > > Congratulations and welcome Vamsi! > > > Regards, > Alan > > -- > Apache Geronimo - http://geronimo.apache.org > Apache Yoko - http://incubator.apache.org/yoko > LiveTribe - http://www.livetribe.org > > > > >
Re: [Results] Priorities for 1.2
On Oct 18, 2006, at 2:02 AM, Alan D. Cabrera wrote:Great. I'm thinking that we can try to cut a real release by the end of this month and run it through the TCK wringer. What does everyone think?I think it would be excellent to get past TCK and branch trunk for the 1.2 release. I am hearing more and more folks interested in JEE 5.0 (the JUG last night was yet another confirmation). I'll volunteer to start the march to JEE 5.0. Based on the meeting with the JBoss guys it would be so great for us to beat them...if not beat them...be really, really close :-) Matt Hogstrom[EMAIL PROTECTED]
Re: [ANNOUNCE] Please welcome Vamsavardhana Reddy as one of our newest Committer
Congrats! Alan Cabrera wrote: > The Geronimo PMC is pleased to announce that Vamsavardhana Reddy has > recently accepted our invitation to become an Apache Geronimo > Committer. Vamsi has been submitting many great patches for > an embarrassing long time. The breadth of his patches is remarkable but > we are excited by the possibility of him working on security. > > Congratulations and welcome Vamsi! > > > Regards, > Alan > > -- > Apache Geronimo - http://geronimo.apache.org > Apache Yoko - http://incubator.apache.org/yoko > LiveTribe - http://www.livetribe.org > > > >
[ANNOUNCE] Please welcome Vamsavardhana Reddy as one of our newest Committer
The Geronimo PMC is pleased to announce that Vamsavardhana Reddy has recently accepted our invitation to become an Apache Geronimo Committer. Vamsi has been submitting many great patches for an embarrassing long time. The breadth of his patches is remarkable but we are excited by the possibility of him working on security.Congratulations and welcome Vamsi!Regards,Alan--Apache Geronimo - http://geronimo.apache.orgApache Yoko - http://incubator.apache.org/yokoLiveTribe - http://www.livetribe.org
Re: [Results] Priorities for 1.2
On Oct 18, 2006, at 12:24 AM, David Jencks wrote:On Oct 17, 2006, at 11:02 PM, Alan D. Cabrera wrote:On Oct 10, 2006, at 8:28 AM, Matt Hogstrom wrote:Thanks Alan ... I figured that was the plan but thought I should ask than assume :)Jencks is encouraging me to fix some of the TranQL problems in TCK so I'm updating my copy to 1.2. I simply can't wait to start running the TCK :-PGreat. I'm thinking that we can try to cut a real release by the end of this month and run it through the TCK wringer. What does everyone think?I was thinking more in terms of getting the tck to pass and then cutting a release. Otherwise we run the risk of having months of work on 2 codebases to get the tck to pass. Experience has shown me that we can't apply fixes to 2 codebases very well.Good point. Unfortunately the TCK licensing prevents us from providing an estimate on when this will happen.To me the main open question about 1.2 is whether we can certify on j2ee 1.4 with jee5 spec libraries. If so it is fairly simple to include jee5 preview features. If not we are going to have to jump through a lot of hoops to demonstrate any jee5 functionality. I haven't heard back from Geir with any news from sun on this question.Can you explain your comment about "we are going to have to jump through a lot of hoops to demonstrate any jee5 functionality"? It sounds scary.Regards,Alan --Apache Geronimo - http://geronimo.apache.orgApache Yoko - http://incubator.apache.org/yokoLiveTribe - http://www.livetribe.org
[jira] Updated: (GERONIMO-2501) Unable to deploy database pools
[ http://issues.apache.org/jira/browse/GERONIMO-2501?page=all ] David Chudnow updated GERONIMO-2501: Priority: Critical (was: Major) I need to be able to create database connection pools in order to continue with my project > Unable to deploy database pools > --- > > Key: GERONIMO-2501 > URL: http://issues.apache.org/jira/browse/GERONIMO-2501 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: databases >Affects Versions: 1.1.1 > Environment: Mac OS x (version 10.4.8) >Reporter: David Chudnow >Priority: Critical > > After completing the informaion and testing the connection I get the > following when attempting to deploy either an oracle or sql server db pool > 10:36:49,635 ERROR [[DBWizard]] Servlet.service() for servlet DBWizard threw > exception > java.lang.NullPointerException > at > org.apache.geronimo.console.databasemanager.wizard.DatabasePoolPortlet.save(DatabasePoolPortlet.java:873) > at > org.apache.geronimo.console.databasemanager.wizard.DatabasePoolPortlet.processAction(DatabasePoolPortlet.java:338) > at > org.apache.pluto.core.PortletServlet.dispatch(PortletServlet.java:229) > at org.apache.pluto.core.PortletServlet.doPost(PortletServlet.java:163) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:615) > 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(ApplicationFilterChain.java:252) > at > org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173) > at > org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:672) > at > org.apache.catalina.core.ApplicationDispatcher.doInclude(ApplicationDispatcher.java:574) > at > org.apache.catalina.core.ApplicationDispatcher.include(ApplicationDispatcher.java:499) > at > org.apache.pluto.invoker.impl.PortletInvokerImpl.invoke(PortletInvokerImpl.java:120) > at > org.apache.pluto.invoker.impl.PortletInvokerImpl.action(PortletInvokerImpl.java:68) > at > org.apache.pluto.PortletContainerImpl.processPortletAction(PortletContainerImpl.java:164) > at > org.apache.pluto.portalImpl.core.PortletContainerWrapperImpl.processPortletAction(PortletContainerWrapperImpl.java:82) > at org.apache.pluto.portalImpl.Servlet.doGet(Servlet.java:227) > at org.apache.pluto.portalImpl.Servlet.doPost(Servlet.java:267) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:615) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:688) > at > org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252) > at > org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173) > at > org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213) > at > org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:178) > at > org.apache.geronimo.tomcat.valve.DefaultSubjectValve.invoke(DefaultSubjectValve.java:56) > at > org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:524) > at > org.apache.geronimo.tomcat.GeronimoStandardContext$SystemMethodValve.invoke(GeronimoStandardContext.java:342) > at > org.apache.geronimo.tomcat.valve.GeronimoBeforeAfterValve.invoke(GeronimoBeforeAfterValve.java:31) > at > org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126) > at > org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105) > at > org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107) > at > org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:541) > at > org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148) > at > org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:869) > at > org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection(Http11BaseProtocol.java:667) > at > org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:527) > at > org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(LeaderFollowerWorkerThread.java:80) > at > org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:684) > at java.lang.Thread.run(Thread.java:613) > 10:36:49,638 ERROR [Servlet] Exception caught: > java.lang.NullPointerException > at > org.apache.geronimo.console.databasemanager.wizard.DatabasePoolPortlet.save(DatabasePoolPortlet.java:873) > at > o
[jira] Created: (GERONIMO-2501) Unable to deploy database pools
Unable to deploy database pools --- Key: GERONIMO-2501 URL: http://issues.apache.org/jira/browse/GERONIMO-2501 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Components: databases Affects Versions: 1.1.1 Environment: Mac OS x (version 10.4.8) Reporter: David Chudnow After completing the informaion and testing the connection I get the following when attempting to deploy either an oracle or sql server db pool 10:36:49,635 ERROR [[DBWizard]] Servlet.service() for servlet DBWizard threw exception java.lang.NullPointerException at org.apache.geronimo.console.databasemanager.wizard.DatabasePoolPortlet.save(DatabasePoolPortlet.java:873) at org.apache.geronimo.console.databasemanager.wizard.DatabasePoolPortlet.processAction(DatabasePoolPortlet.java:338) at org.apache.pluto.core.PortletServlet.dispatch(PortletServlet.java:229) at org.apache.pluto.core.PortletServlet.doPost(PortletServlet.java:163) at javax.servlet.http.HttpServlet.service(HttpServlet.java:615) 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(ApplicationFilterChain.java:252) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173) at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:672) at org.apache.catalina.core.ApplicationDispatcher.doInclude(ApplicationDispatcher.java:574) at org.apache.catalina.core.ApplicationDispatcher.include(ApplicationDispatcher.java:499) at org.apache.pluto.invoker.impl.PortletInvokerImpl.invoke(PortletInvokerImpl.java:120) at org.apache.pluto.invoker.impl.PortletInvokerImpl.action(PortletInvokerImpl.java:68) at org.apache.pluto.PortletContainerImpl.processPortletAction(PortletContainerImpl.java:164) at org.apache.pluto.portalImpl.core.PortletContainerWrapperImpl.processPortletAction(PortletContainerWrapperImpl.java:82) at org.apache.pluto.portalImpl.Servlet.doGet(Servlet.java:227) at org.apache.pluto.portalImpl.Servlet.doPost(Servlet.java:267) at javax.servlet.http.HttpServlet.service(HttpServlet.java:615) at javax.servlet.http.HttpServlet.service(HttpServlet.java:688) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:178) at org.apache.geronimo.tomcat.valve.DefaultSubjectValve.invoke(DefaultSubjectValve.java:56) at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:524) at org.apache.geronimo.tomcat.GeronimoStandardContext$SystemMethodValve.invoke(GeronimoStandardContext.java:342) at org.apache.geronimo.tomcat.valve.GeronimoBeforeAfterValve.invoke(GeronimoBeforeAfterValve.java:31) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107) at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:541) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:869) at org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection(Http11BaseProtocol.java:667) at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:527) at org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(LeaderFollowerWorkerThread.java:80) at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:684) at java.lang.Thread.run(Thread.java:613) 10:36:49,638 ERROR [Servlet] Exception caught: java.lang.NullPointerException at org.apache.geronimo.console.databasemanager.wizard.DatabasePoolPortlet.save(DatabasePoolPortlet.java:873) at org.apache.geronimo.console.databasemanager.wizard.DatabasePoolPortlet.processAction(DatabasePoolPortlet.java:338) at org.apache.pluto.core.PortletServlet.dispatch(PortletServlet.java:229) at org.apache.pluto.core.PortletServlet.doPost(PortletServlet.java:163) at javax.servlet.http.HttpServlet.service(HttpServlet.java:615) at javax.servlet.http.HttpServlet.service(
Re: [ANNOUNCE] Please welcome Christopher M. Cardona as our newest Committer
Congrats Chris! --kevan On Oct 18, 2006, at 7:26 AM, Gianny Damour wrote: Hi, The Geronimo PMC is pleased to announce that Christopher M. Cardona has recently accepted our invitation to become an Apache Geronimo Committer. Over the past few months, Chris has been working on the improvement of the Server Console and has demonstrated initiatives and a noteworthy ability to work with others. Congratulations and Welcome Christopher!
[jira] Commented: (AMQ-980) lastImageSubscriptionRecoveryPolicy does not work with wildcards
[
https://issues.apache.org/activemq/browse/AMQ-980?page=comments#action_37231 ]
james strachan commented on AMQ-980:
BTW I marked this resolved as a 'Cannot Reproduce' for now - if you can figure
out how to reproduce we can reopen it
> lastImageSubscriptionRecoveryPolicy does not work with wildcards
>
>
> Key: AMQ-980
> URL: https://issues.apache.org/activemq/browse/AMQ-980
> Project: ActiveMQ
> Issue Type: Bug
> Components: Broker
>Affects Versions: 4.0.2
> Environment: Windows, JDK 1.5
>Reporter: Rob Lugt
> Fix For: 4.1
>
>
> The lastImageSubscriptionRecoveryPolicy does not appear to work with
> wildcards.
> In the following example, a new consumer only receives one message for the
> topics covered by the wildcard instead of receiving one message for each
> topic.
>
> config file:-
>
>
>
>
>
>
> consumer subscription:-
> GetTopic("PRICES.>?consumer.retrocactive=true");
--
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] Resolved: (AMQ-980) lastImageSubscriptionRecoveryPolicy does not work with wildcards
[ https://issues.apache.org/activemq/browse/AMQ-980?page=all ]
james strachan resolved AMQ-980.
Fix Version/s: 4.1
Resolution: Cannot Reproduce
I've created a JUnit test case to try reproduce the issue. I've added the test
case RetroactiveConsumerTestWithLastImagePolicyWithWildcardTest (in the
activemq-core module)
which creates a broker without persistence, sends 20 messages to different
topics, then creates a retroactive consumer using a wildcard and it receives
all 20 messages on each topic.
Am wondering how to reproduce your issue - any ideas? Does this issue only show
itself in ActiveMQ.Net?
> lastImageSubscriptionRecoveryPolicy does not work with wildcards
>
>
> Key: AMQ-980
> URL: https://issues.apache.org/activemq/browse/AMQ-980
> Project: ActiveMQ
> Issue Type: Bug
> Components: Broker
>Affects Versions: 4.0.2
> Environment: Windows, JDK 1.5
>Reporter: Rob Lugt
> Fix For: 4.1
>
>
> The lastImageSubscriptionRecoveryPolicy does not appear to work with
> wildcards.
> In the following example, a new consumer only receives one message for the
> topics covered by the wildcard instead of receiving one message for each
> topic.
>
> config file:-
>
>
>
>
>
>
> consumer subscription:-
> GetTopic("PRICES.>?consumer.retrocactive=true");
--
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: WS-Security and Geronimo KeystoreInstance
Yeah, I do understand that the key password has to be provided. I see three different ways I could handle the modification: 1) duplicate all methods that are read-only wrt to the keystore and remove the keystore password (it would use the internal one) 2) remove the keystore password on existing methods 3) assume that when password is null, it uses the internal one The second method can not really be used, because the internal password is only set when the keystore is unlocked for use. The first one is not really clean imho, so I would go for the third option. Btw, I found several problems in the current implementation. Some edition methods do not have a password given, so they use the internal one. This means that they fail when executing the method on a keystore that is locked for use. This can be reproduce if you try to delete an entry from a locked keystore. It seems to be the case for * deleteEntry * importPKCS7Certificate * generateCSR I will try to fix these, add the new needed methods (with the ones from the GERONIMO-2413 patch) and when the given password is null for read-only method, try to use the internal password. However, I'm wondering if the private key password problem could be solved by using the java.lang.SecurityManager. On 10/18/06, Vamsavardhana Reddy <[EMAIL PROTECTED]> wrote: Hi Guillaume, To make the CA Portlet (http://issues.apache.org/jira/browse/GERONIMO-2413) use a KeystoreInstance to store its keys, I have added a getCertificate() and getPrivateKey() methods. Now coming to the methods you need, except for getPrivateKey(), it may be alright to provide methods in KeystoreInstance not to require keystore password and these would succeed only if the keystore is unlocked for "use". We should make getPrivateKey() method always require a keyPassword. Vamsi On 10/18/06, Guillaume Nodet < [EMAIL PROTECTED]> wrote: > I'm trying to look at integrating ServiceMix > security in Geronimo. Security in ServiceMix > has several different aspects, but one of them > is to be able to encrypt / decrypt, sign messages > using WS-Security. > I have defined in ServiceMix a Crypto [1] implementation [2] > (used by wss4j) on top of a servicemix KeystoreInstance [3] > (which is quite the same as the Geronimo one). > The main differences are 2 new methods (getCertificateChain and > getCertificateAlias) and the fact that the methods do not need > the keystore password in the parameters. > > I had a close look at the Geronimo KeystoreInstance and found > that nearly all methods are called from the console only. The only > real methods used inside the server are when an SSLSocketFactory > is created. > > So I'm wondering what is the best way to go. I can easily add the two new > methods to the KeystoreInstance, but the need to give the password > for all the calls is a bit disturbing. I need to access the following methods: > * listPrivateKeys > * listTrustCertificates > * getCertificate > * getCertificateAlias > * getCertificateChain > * getPrivateKey > > Would it be possible from the FileKeystoreInstance to use the > keystorePassword attribute instead of passing the password > in the parameters ? I do understand that this may be a security > hole, as the private keys would be available to everyone inside > the server, so I'm willing to find a better way ... > > Any ideas ? > > > [1] http://ws.apache.org/wss4j/apidocs/org/apache/ws/security/components/crypto/Crypto.html > [2] http://svn.apache.org/viewvc/incubator/servicemix/trunk/servicemix-soap/src/main/java/org/apache/servicemix/soap/handlers/security/KeystoreInstanceCrypto.java?view=markup > [3] http://svn.apache.org/viewvc/incubator/servicemix/trunk/servicemix-core/src/main/java/org/apache/servicemix/jbi/security/keystore/KeystoreInstance.java?view=markup > > > > -- > Cheers, > Guillaume Nodet > -- Cheers, Guillaume Nodet
Re: [ANNOUNCE] Please welcome Christopher M. Cardona as our newest Committer
Congrats Chris!Regards,AlanOn Oct 18, 2006, at 4:26 AM, Gianny Damour wrote:Hi,The Geronimo PMC is pleased to announce that Christopher M. Cardona has recently accepted our invitation to become an Apache Geronimo Committer. Over the past few months, Chris has been working on the improvement of the Server Console and has demonstrated initiatives and a noteworthy ability to work with others.Congratulations and Welcome Christopher! --Apache Geronimo - http://geronimo.apache.orgApache Yoko - http://incubator.apache.org/yokoLiveTribe - http://www.livetribe.org
Re: [ANNOUNCE] Please welcome Christopher M. Cardona as our newest Committer
congrats!On Oct 18, 2006, at 7:26 AM, Gianny Damour wrote:Hi,The Geronimo PMC is pleased to announce that Christopher M. Cardona has recently accepted our invitation to become an Apache Geronimo Committer. Over the past few months, Chris has been working on the improvement of the Server Console and has demonstrated initiatives and a noteworthy ability to work with others.Congratulations and Welcome Christopher! -sachin
[jira] Created: (AMQ-991) ActiveMQ 4.0.1 crashes when using client from trunk.
ActiveMQ 4.0.1 crashes when using client from trunk.
Key: AMQ-991
URL: https://issues.apache.org/activemq/browse/AMQ-991
Project: ActiveMQ
Issue Type: Bug
Components: NMS (C# client)
Reporter: Pawel Niewiadomski
I tried today to use C# client from trunk agains ActiveMQ 4.0.1 server. This
caused server to die totally. Following error message was shown by server:
{noformat}
Exception in thread "ActiveMQ Transport: tcp:///127.0.0.1:1699" java.lang.Illega
lArgumentException: Invalid version: 2, could not load
org.apache.activemq.openwire.v2.MarshallerFactory
at
org.apache.activemq.openwire.OpenWireFormat.setVersion(OpenWireFormat.java:329)
at
org.apache.activemq.openwire.OpenWireFormat.renegociatWireFormat(OpenWireFormat.java:569)
at
org.apache.activemq.transport.WireFormatNegotiator.onCommand(WireFormatNegotiator.java:100)
at
org.apache.activemq.transport.InactivityMonitor.onCommand(InactivityMonitor.java:122)
at
org.apache.activemq.transport.TransportSupport.doConsume(TransportSupport.java:87)
at
org.apache.activemq.transport.tcp.TcpTransport.run(TcpTransport.java:143)
at java.lang.Thread.run(Thread.java:595)
Caused by: java.lang.ClassNotFoundException:
org.apache.activemq.openwire.v2.MarshallerFactory
at
org.apache.activemq.util.ClassLoading.loadClass(ClassLoading.java:104)
at
org.apache.activemq.openwire.OpenWireFormat.setVersion(OpenWireFormat.java:327)
... 6 more
{noformat}
I then used ActiveMQ 4.0.2 server and it worked. Isn't that client should
automatically negotiate protocol with server? Why server after this error dies
totally? (new client connecting were not handled at all, everything died).
--
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: [ANNOUNCE] Please welcome Christopher M. Cardona as our newest Committer
Congrats Chris! Joe Gianny Damour wrote: Hi, The Geronimo PMC is pleased to announce that Christopher M. Cardona has recently accepted our invitation to become an Apache Geronimo Committer. Over the past few months, Chris has been working on the improvement of the Server Console and has demonstrated initiatives and a noteworthy ability to work with others. Congratulations and Welcome Christopher!
Re: [ANNOUNCE] Please welcome Christopher M. Cardona as our newest Committer
Congratulations Chris!AnitaGianny Damour <[EMAIL PROTECTED]> wrote: Hi,The Geronimo PMC is pleased to announce that Christopher M. Cardona has recently accepted our invitation to become an Apache Geronimo Committer. Over the past few months, Chris has been working on the improvement of the Server Console and has demonstrated initiatives and a noteworthy ability to work with others.Congratulations and Welcome Christopher! Stay in the know. Pulse on the new Yahoo.com. Check it out.
[jira] Updated: (GERONIMO-2500) TomcatAJPConntector exposes non existent attributes
[ http://issues.apache.org/jira/browse/GERONIMO-2500?page=all ] Anita Kulshreshtha updated GERONIMO-2500: - Attachment: ajp.JPG snpshot of AJPConnector in mc4j > TomcatAJPConntector exposes non existent attributes > --- > > Key: GERONIMO-2500 > URL: http://issues.apache.org/jira/browse/GERONIMO-2500 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: Tomcat >Affects Versions: 1.2 > Environment: All >Reporter: Anita Kulshreshtha > Attachments: ajp.JPG > > > The tomcat ConnectorGBean exposes many attributes for TomcatAJPConnector > which are non existent. Some of the invalid attributes are maxThread, > connectionTimeoutMillis, maxHttpHeaderSizeBytes, maxKeepAliveRequests, > maxSpareThreads, maxThreads, etc. For a complete list see the attached image. > The attributes set on TomcatAJPConnector are listed on the left. The list on > the right shows the attributes known to tomcat connector,i.e. > ..type=connector,address=0.0.0.0,port=8009,. > -- 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: WS-Security and Geronimo KeystoreInstance
Guillaume, There should not be any problem in providing these methods without requiring a keystore password. java.security.KeyStore.load() allows a Keystore file to be loaded without even a keystore password. This method will not accept a wrong password, but will accept null as the keystore password parameter. keypassword will be required for retrieving any private-key. VamsiOn 10/18/06, Vamsavardhana Reddy <[EMAIL PROTECTED]> wrote: Hi Guillaume, To make the CA Portlet (http://issues.apache.org/jira/browse/GERONIMO-2413) use a KeystoreInstance to store its keys, I have added a getCertificate() and getPrivateKey() methods. Now coming to the methods you need, except for getPrivateKey(), it may be alright to provide methods in KeystoreInstance not to require keystore password and these would succeed only if the keystore is unlocked for "use". We should make getPrivateKey() method always require a keyPassword. Vamsi On 10/18/06, Guillaume Nodet < [EMAIL PROTECTED]> wrote: I'm trying to look at integrating ServiceMix security in Geronimo. Security in ServiceMixhas several different aspects, but one of themis to be able to encrypt / decrypt, sign messagesusing WS-Security.I have defined in ServiceMix a Crypto [1] implementation [2] (used by wss4j) on top of a servicemix KeystoreInstance [3](which is quite the same as the Geronimo one).The main differences are 2 new methods (getCertificateChain andgetCertificateAlias) and the fact that the methods do not need the keystore password in the parameters.I had a close look at the Geronimo KeystoreInstance and foundthat nearly all methods are called from the console only. The onlyreal methods used inside the server are when an SSLSocketFactory is created.So I'm wondering what is the best way to go. I can easily add the two newmethods to the KeystoreInstance, but the need to give the passwordfor all the calls is a bit disturbing. I need to access the following methods: * listPrivateKeys * listTrustCertificates * getCertificate * getCertificateAlias * getCertificateChain * getPrivateKeyWould it be possible from the FileKeystoreInstance to use the keystorePassword attribute instead of passing the passwordin the parameters ? I do understand that this may be a securityhole, as the private keys would be available to everyone insidethe server, so I'm willing to find a better way ... Any ideas ?[1] http://ws.apache.org/wss4j/apidocs/org/apache/ws/security/components/crypto/Crypto.html [2] http://svn.apache.org/viewvc/incubator/servicemix/trunk/servicemix-soap/src/main/java/org/apache/servicemix/soap/handlers/security/KeystoreInstanceCrypto.java?view=markup [3] http://svn.apache.org/viewvc/incubator/servicemix/trunk/servicemix-core/src/main/java/org/apache/servicemix/jbi/security/keystore/KeystoreInstance.java?view=markup --Cheers,Guillaume Nodet
[jira] Created: (GERONIMO-2500) TomcatAJPConntector exposes non existent attributes
TomcatAJPConntector exposes non existent attributes --- Key: GERONIMO-2500 URL: http://issues.apache.org/jira/browse/GERONIMO-2500 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Components: Tomcat Affects Versions: 1.2 Environment: All Reporter: Anita Kulshreshtha The tomcat ConnectorGBean exposes many attributes for TomcatAJPConnector which are non existent. Some of the invalid attributes are maxThread, connectionTimeoutMillis, maxHttpHeaderSizeBytes, maxKeepAliveRequests, maxSpareThreads, maxThreads, etc. For a complete list see the attached image. The attributes set on TomcatAJPConnector are listed on the left. The list on the right shows the attributes known to tomcat connector,i.e. ..type=connector,address=0.0.0.0,port=8009,. -- 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: [ANNOUNCE] Please welcome Christopher M. Cardona as our newest Committer
Congrats Chris! Cheers! Hernan Gianny Damour wrote: Hi, The Geronimo PMC is pleased to announce that Christopher M. Cardona has recently accepted our invitation to become an Apache Geronimo Committer. Over the past few months, Chris has been working on the improvement of the Server Console and has demonstrated initiatives and a noteworthy ability to work with others. Congratulations and Welcome Christopher!
Re: [ANNOUNCE] Please welcome Christopher M. Cardona as our newest Committer
Congratulations Chris ! Cheers Prasad On 10/18/06, Paul McMahan <[EMAIL PROTECTED]> wrote: Congrats Chris!! Paul On 10/18/06, Gianny Damour <[EMAIL PROTECTED]> wrote: > Hi, > > The Geronimo PMC is pleased to announce that Christopher M. Cardona > has recently accepted our invitation to become an Apache Geronimo > Committer. Over the past few months, Chris has been working on the > improvement of the Server Console and has demonstrated initiatives > and a noteworthy ability to work with others. > > Congratulations and Welcome Christopher! > >
Re: [ANNOUNCE] Please welcome Christopher M. Cardona as our newest Committer
Congrats Chris!! Paul On 10/18/06, Gianny Damour <[EMAIL PROTECTED]> wrote: Hi, The Geronimo PMC is pleased to announce that Christopher M. Cardona has recently accepted our invitation to become an Apache Geronimo Committer. Over the past few months, Chris has been working on the improvement of the Server Console and has demonstrated initiatives and a noteworthy ability to work with others. Congratulations and Welcome Christopher!
[jira] Created: (AMQ-990) Leaving threads running if Connection.Dispose fails.
Leaving threads running if Connection.Dispose fails. Key: AMQ-990 URL: https://issues.apache.org/activemq/browse/AMQ-990 Project: ActiveMQ Issue Type: Bug Components: NMS (C# client) Reporter: Pawel Niewiadomski I faced today following error - in Connection.Dispose call to DisposeOf(ConnectionId); fails with exception. This causes Connection.Dispose to be aborted leading to thread responsible for communication not to be joined. I'm talking about the thread created in TcpTransport. closing = true; DisposeOf(ConnectionId); // this causes exception and aborts further execution on this scope sessions.Clear(); transport.Oneway(new ShutdownInfo()); transport.Dispose(); // this is responsible for joining the thread and closing sockets closed = true; In summary - thread is still running and we can't get rid of it. -- 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: (SM-714) component.properties in conf directory
component.properties in conf directory -- Key: SM-714 URL: https://issues.apache.org/activemq/browse/SM-714 Project: ServiceMix Issue Type: Improvement Components: servicemix-http Reporter: Thomas Termin Attachments: component.properties, patch.txt There should be support for an initial component.properties file in the servicemix/conf directory. I added support for that (see the patch). The file in the conf directory will be loaded if no property file is in the workspace directory (I implemented that just for the servicemix-http component). If you change properties via JMX the changes will be saved in the workspace directory. The file in the conf directory has then still the original values. I added also a component.properties file. -- 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: WS-Security and Geronimo KeystoreInstance
Hi Guillaume, To make the CA Portlet (http://issues.apache.org/jira/browse/GERONIMO-2413) use a KeystoreInstance to store its keys, I have added a getCertificate() and getPrivateKey() methods. Now coming to the methods you need, except for getPrivateKey(), it may be alright to provide methods in KeystoreInstance not to require keystore password and these would succeed only if the keystore is unlocked for "use". We should make getPrivateKey() method always require a keyPassword. Vamsi On 10/18/06, Guillaume Nodet < [EMAIL PROTECTED]> wrote: I'm trying to look at integrating ServiceMix security in Geronimo. Security in ServiceMixhas several different aspects, but one of themis to be able to encrypt / decrypt, sign messagesusing WS-Security.I have defined in ServiceMix a Crypto [1] implementation [2] (used by wss4j) on top of a servicemix KeystoreInstance [3](which is quite the same as the Geronimo one).The main differences are 2 new methods (getCertificateChain andgetCertificateAlias) and the fact that the methods do not need the keystore password in the parameters.I had a close look at the Geronimo KeystoreInstance and foundthat nearly all methods are called from the console only. The onlyreal methods used inside the server are when an SSLSocketFactory is created.So I'm wondering what is the best way to go. I can easily add the two newmethods to the KeystoreInstance, but the need to give the passwordfor all the calls is a bit disturbing. I need to access the following methods: * listPrivateKeys * listTrustCertificates * getCertificate * getCertificateAlias * getCertificateChain * getPrivateKeyWould it be possible from the FileKeystoreInstance to use the keystorePassword attribute instead of passing the passwordin the parameters ? I do understand that this may be a securityhole, as the private keys would be available to everyone insidethe server, so I'm willing to find a better way ... Any ideas ?[1] http://ws.apache.org/wss4j/apidocs/org/apache/ws/security/components/crypto/Crypto.html [2] http://svn.apache.org/viewvc/incubator/servicemix/trunk/servicemix-soap/src/main/java/org/apache/servicemix/soap/handlers/security/KeystoreInstanceCrypto.java?view=markup [3] http://svn.apache.org/viewvc/incubator/servicemix/trunk/servicemix-core/src/main/java/org/apache/servicemix/jbi/security/keystore/KeystoreInstance.java?view=markup --Cheers,Guillaume Nodet
[jira] Resolved: (AMQ-951) NMS requires the concept of a Connection Exception event to mirror rhe ExceptionListener in JMS.
[ https://issues.apache.org/activemq/browse/AMQ-951?page=all ] james strachan resolved AMQ-951. Fix Version/s: 4.1 Resolution: Fixed I've added an ExceptionListener event on the IConnection which should serve a similar purpose to ExceptionListener in JMS. Does this seem an OK solution to you? > NMS requires the concept of a Connection Exception event to mirror rhe > ExceptionListener in JMS. > > > Key: AMQ-951 > URL: https://issues.apache.org/activemq/browse/AMQ-951 > Project: ActiveMQ > Issue Type: New Feature > Components: NMS (C# client) >Affects Versions: incubation >Reporter: Rob Lugt > Assigned To: Rob Lugt > Fix For: 4.1 > > > Applications using NMS have no way of discovering problems with the > connection. JMS allws a ExceptionListener to be registered with a > Connection, NMS should provide a similar concept. -- 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
WS-Security and Geronimo KeystoreInstance
I'm trying to look at integrating ServiceMix security in Geronimo. Security in ServiceMix has several different aspects, but one of them is to be able to encrypt / decrypt, sign messages using WS-Security. I have defined in ServiceMix a Crypto [1] implementation [2] (used by wss4j) on top of a servicemix KeystoreInstance [3] (which is quite the same as the Geronimo one). The main differences are 2 new methods (getCertificateChain and getCertificateAlias) and the fact that the methods do not need the keystore password in the parameters. I had a close look at the Geronimo KeystoreInstance and found that nearly all methods are called from the console only. The only real methods used inside the server are when an SSLSocketFactory is created. So I'm wondering what is the best way to go. I can easily add the two new methods to the KeystoreInstance, but the need to give the password for all the calls is a bit disturbing. I need to access the following methods: * listPrivateKeys * listTrustCertificates * getCertificate * getCertificateAlias * getCertificateChain * getPrivateKey Would it be possible from the FileKeystoreInstance to use the keystorePassword attribute instead of passing the password in the parameters ? I do understand that this may be a security hole, as the private keys would be available to everyone inside the server, so I'm willing to find a better way ... Any ideas ? [1] http://ws.apache.org/wss4j/apidocs/org/apache/ws/security/components/crypto/Crypto.html [2] http://svn.apache.org/viewvc/incubator/servicemix/trunk/servicemix-soap/src/main/java/org/apache/servicemix/soap/handlers/security/KeystoreInstanceCrypto.java?view=markup [3] http://svn.apache.org/viewvc/incubator/servicemix/trunk/servicemix-core/src/main/java/org/apache/servicemix/jbi/security/keystore/KeystoreInstance.java?view=markup -- Cheers, Guillaume Nodet
[jira] Commented: (AMQ-952) .Net Client ConnectionFactory requires additional configurable attributes
[ https://issues.apache.org/activemq/browse/AMQ-952?page=comments#action_37228 ] james strachan commented on AMQ-952: So the only things left for this I think are closeTimeout and connectTimeout. For closeTimeout, we currently are not waiting for a receipt to come back from the broker when we send a ShutdownInfo - which seems fine to me. The Java client will do a timeout based request-response up to the closeTimeout - am not sure how useful that is to implement in .Net though. For connectTimeout, in Java we set that as a property on the Socket class when doing a Connect() - I don't see any way to do something similar on .Net. Though the SendTimeout and ReceiveTimeout properties can be set via the URI notation of transport.socket.sendTimeout=1234 etc > .Net Client ConnectionFactory requires additional configurable attributes > - > > Key: AMQ-952 > URL: https://issues.apache.org/activemq/browse/AMQ-952 > Project: ActiveMQ > Issue Type: New Feature > Components: NMS (C# client) >Reporter: Rob Lugt >Priority: Minor > > The Java Client has a rich set of configuration options, which should also be > available on the .Net client. > As a mimimum I believe we need:- > closeTimeout > retroactiveConsumer > Is it also worth considering a connectTimeout property - or should this be > transport specific? -- 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] Commented: (AMQ-952) .Net Client ConnectionFactory requires additional configurable attributes
[ https://issues.apache.org/activemq/browse/AMQ-952?page=comments#action_37227 ] james strachan commented on AMQ-952: Incidentally, while looking at the Connection.Dispose(), we no longer call Dispose() on child sessions as they are iDisposable - by the same logic I guess we should no longer call transport.Dispose() too? > .Net Client ConnectionFactory requires additional configurable attributes > - > > Key: AMQ-952 > URL: https://issues.apache.org/activemq/browse/AMQ-952 > Project: ActiveMQ > Issue Type: New Feature > Components: NMS (C# client) >Reporter: Rob Lugt >Priority: Minor > > The Java Client has a rich set of configuration options, which should also be > available on the .Net client. > As a mimimum I believe we need:- > closeTimeout > retroactiveConsumer > Is it also worth considering a connectTimeout property - or should this be > transport specific? -- 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] Commented: (AMQ-952) .Net Client ConnectionFactory requires additional configurable attributes
[
https://issues.apache.org/activemq/browse/AMQ-952?page=comments#action_37226 ]
james strachan commented on AMQ-952:
I've added API access to the various consumer related configuration options;
so you can now do things like
ISession session = ...
session.Retroactive = true
session.CreateConsumer()...
etc
Also you should be able to use the URI syntax currently...
new ActiveMQQueue("Foo.BAR?consumer.retroactive=true") etc
> .Net Client ConnectionFactory requires additional configurable attributes
> -
>
> Key: AMQ-952
> URL: https://issues.apache.org/activemq/browse/AMQ-952
> Project: ActiveMQ
> Issue Type: New Feature
> Components: NMS (C# client)
>Reporter: Rob Lugt
>Priority: Minor
>
> The Java Client has a rich set of configuration options, which should also be
> available on the .Net client.
> As a mimimum I believe we need:-
> closeTimeout
> retroactiveConsumer
> Is it also worth considering a connectTimeout property - or should this be
> transport specific?
--
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] Resolved: (AMQ-966) NMSDestination is null when receiving messages
[ https://issues.apache.org/activemq/browse/AMQ-966?page=all ] james strachan resolved AMQ-966. Fix Version/s: 4.1 Resolution: Fixed yes, it should be the Destination property :) Patch applied with thanks > NMSDestination is null when receiving messages > -- > > Key: AMQ-966 > URL: https://issues.apache.org/activemq/browse/AMQ-966 > Project: ActiveMQ > Issue Type: Bug > Components: NMS (C# client) >Affects Versions: 4.0.2 >Reporter: Rob Lugt > Fix For: 4.1 > > > The NMSDestination property is null when receiving messages via an > asynchronous listener. -- 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] Resolved: (AMQ-989) .Net Client: allow specification of wireFormat parameters in broker URI
[ https://issues.apache.org/activemq/browse/AMQ-989?page=all ] james strachan resolved AMQ-989. Fix Version/s: 4.1 Resolution: Fixed I think I've faithfully applied your patch for this issue - many thanks. This issue seemed to cut across a few other issues to do with logging; could you double check I"ve applied your patch correctly please? > .Net Client: allow specification of wireFormat parameters in broker URI > --- > > Key: AMQ-989 > URL: https://issues.apache.org/activemq/browse/AMQ-989 > Project: ActiveMQ > Issue Type: Improvement > Components: NMS (C# client) >Affects Versions: 4.0.2 > Environment: Windows >Reporter: Rob Lugt > Assigned To: james strachan > Fix For: 4.1 > > Attachments: amq989.txt > > > Update required to TcpTransportFactory to accept wireFormat connection > parameters in the connection URI. This is the only means for .Net client > applications to set properties such as tight/loose encoding. > Please apply the attached patch. > Best Regards > Rob Lugt -- 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] Assigned: (AMQ-971) NMSTimestamp returning LocalTime instead of UTC
[ https://issues.apache.org/activemq/browse/AMQ-971?page=all ] james strachan reassigned AMQ-971: -- Assignee: Hiram Chirino > NMSTimestamp returning LocalTime instead of UTC > --- > > Key: AMQ-971 > URL: https://issues.apache.org/activemq/browse/AMQ-971 > Project: ActiveMQ > Issue Type: Improvement > Components: NMS (C# client) >Affects Versions: incubation > Environment: Windows >Reporter: Rob Lugt > Assigned To: Hiram Chirino >Priority: Minor > > The NMSTimestamp property has been changed from long to DateTime - which is a > good thing. However, the DateTime is currently being adjusted to localtime > before being returned to the client - which is probably not ideal. The > DateTime struct does not contain timezone information, therefore the > programmer has to make some assumption about what timezone the time is > expressed in. A UTC time is more in-keeping with the JMS specification - > which specifies that Timestamp is a normal Java time i.e. expressed in GMT. > This article from Microsoft also suggests using UTC as a common time where > possible: > http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dndotnet/html/datetimecode.asp -- 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] Resolved: (AMQ-972) NMS Client does not set NMSTimestamp
[ https://issues.apache.org/activemq/browse/AMQ-972?page=all ] james strachan resolved AMQ-972. Fix Version/s: 4.1 Resolution: Fixed Looks great to me - patch applied with thanks! > NMS Client does not set NMSTimestamp > > > Key: AMQ-972 > URL: https://issues.apache.org/activemq/browse/AMQ-972 > Project: ActiveMQ > Issue Type: Bug > Components: NMS (C# client) >Affects Versions: 4.0.2 > Environment: Windows client >Reporter: Rob Lugt > Assigned To: james strachan > Fix For: 4.1 > > Attachments: amq972-patch.txt, DateUtils.cs > > > MessageProducer.cs fails to set the Timestamp property on a message > regardless if the DisableMessageTimestamp feature property is set or not. -- 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] Resolved: (AMQ-985) TcpTransportFactory adds LoggingTransport after WireFormatNegotiator
[ https://issues.apache.org/activemq/browse/AMQ-985?page=all ]
james strachan resolved AMQ-985.
Fix Version/s: 4.1
Resolution: Fixed
Patch applied - thanks again :)
> TcpTransportFactory adds LoggingTransport after WireFormatNegotiator
>
>
> Key: AMQ-985
> URL: https://issues.apache.org/activemq/browse/AMQ-985
> Project: ActiveMQ
> Issue Type: Improvement
> Components: NMS (C# client)
>Affects Versions: 4.0.2
> Environment: Windows
>Reporter: Rob Lugt
> Assigned To: james strachan
>Priority: Minor
> Fix For: 4.1
>
>
> The TcpTransportFactory class will insert a LoggingTransport filter into the
> transport chain if the useLogging=true attribute is set. However, it
> currently adds the LoggingTransport after the WireFormatNegotiator, which
> means that the wire format negotiation packets are excluded from the log
> output. This can be simply rectified by adding the LoggingTransport
> immediately after the TcpTransport. e.g.
> public ITransport CreateTransport(Uri location)
> {
> // Console.WriteLine("Opening socket to: " + host + " on port: "
> + port);
> Socket socket = Connect(location.Host, location.Port);
> TcpTransport tcpTransport = new TcpTransport(socket);
> ITransport rc = tcpTransport;
> // At present the URI is parsed for options by the
> ConnectionFactory
> if (UseLogging)
> {
> rc = new LoggingTransport(rc);
> }
> rc = new WireFormatNegotiator(rc, tcpTransport.Wireformat);
> ...
--
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] Resolved: (AMQ-974) .Net client needs centralised trace facility
[ https://issues.apache.org/activemq/browse/AMQ-974?page=all ] james strachan resolved AMQ-974. Resolution: Fixed Patch applied, thanks again! > .Net client needs centralised trace facility > > > Key: AMQ-974 > URL: https://issues.apache.org/activemq/browse/AMQ-974 > Project: ActiveMQ > Issue Type: New Feature > Components: NMS (C# client) >Affects Versions: 4.0.2 > Environment: Windows >Reporter: Rob Lugt > Assigned To: james strachan > Fix For: 4.1 > > Attachments: amq974-patch.txt, ITrace.cs, Tracer.cs > > > There are several classes within activemq-dotnet which need to write > log/trace information. This data is currently written to an ad-hoc mixture > of the Console and System.Diagnostics.Trace. > Neither of these detinations are suitable because System.Diagnostics.Trace is > not fully supported in the .Net compact framework and the Console is > unsuitable for severl reasons - not least of which is that output is > discarded in a Windows (i.e. non-console) application. > There are two possible solutions to this problem > 1) adopt log4net as the strategic logging/tracing platform > 2) write our own Tracing interface which can be controlled at run-time to > make use of any logging mechanism. > Log4net is an attractive proposition because it is powerful, full-featured, > reliable and is also an Apache incubator project. However, there is a strong > desire to keep activemq-dotnet as clear as possible from any external > dependencies. So far this has been successfull and as there is an > alternative solution perhaps we should not create a dependency now. > Creating a custom Tracing interface is attractive because it is stand-alone > and allows the client application to plug-in whichever trace mechanism it > requires. There don't seem to be many down sides to this solution, so I'll > post a sample impementation shortly. -- 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] Resolved: (AMQ-988) Thread synchronization error in TcpTransport
[ https://issues.apache.org/activemq/browse/AMQ-988?page=all ] james strachan resolved AMQ-988. Fix Version/s: 4.1 Resolution: Fixed Great catch Rob! Patch applied with huge thanks > Thread synchronization error in TcpTransport > > > Key: AMQ-988 > URL: https://issues.apache.org/activemq/browse/AMQ-988 > Project: ActiveMQ > Issue Type: Bug > Components: NMS (C# client) >Affects Versions: 4.0.2 > Environment: Windows >Reporter: Rob Lugt > Assigned To: james strachan > Fix For: 4.1 > > > I have a problem where my C# client application crashes when placed under > load. It's taken a while to get to the bottom of it, but I believe I have > identified the problem and luckily there's a simple solution. > The AMQ .Net client uses a common pattern where a full-duplex TCP/IP > connection is established with the broker, and the client uses two threads to > concurrently read and write data to/from the underlying socket - one thread > reading from a Reader object and the other writing to a Writer object. > The TcpTransport.Start() method contains the following:- > NetworkStream networkStream = new NetworkStream(socket); > socketWriter = new OpenWireBinaryWriter(networkStream); > socketReader = new OpenWireBinaryReader(networkStream); > This pattern is explicitly allowed in Java and Win32 applications, but .Net > is a little vague on the subject. The Microsoft documentation [1] suggests > use of the asynchronous read/write calls for multithreaded applications, but > that would significantly complicate the C# client which relies on blocking > stream behaviour. On the same doc page > Microsoft does specifiy that the Socket class is thread-safe, which I take to > mean that concurrent read/write calls are permitted, however the same is not > true of NetworkStream [2]. > Perhaps it would be reasonable to expect NetworkStream to have no internal > state other than the Socket it contains, but apparently this is not the case > because I've identified that it is a corrupt NetworkStream which is causing > my application to crash under load. After some experimentation and a fair > amount of load testing, I think the solution is a simple change to the > TcpTransport.start() method to use a separate NetworkStream for input and > output operations. e.g. :- > NetworkStream inputNetworkStream = new NetworkStream(socket); > NetworkStream outputNetworkStream = new NetworkStream(socket); > socketWriter = new OpenWireBinaryWriter(inputNetworkStream); > socketReader = new OpenWireBinaryReader(outputNetworkStream); > This works for me and my test client has now been running for 16 hours > without crashing (before it would rarely last longer than 10 minutes). > Regards > Rob Lugt > [1] http://msdn2.microsoft.com/en-us/library/system.net.sockets.socket.aspx > [2] > http://msdn2.microsoft.com/en-us/library/system.net.sockets.networkstream.aspx -- 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: [ANNOUNCE] Please welcome Christopher M. Cardona as our newest Committer
Congratulations Chris. --vamsi On 10/18/06, Gianny Damour <[EMAIL PROTECTED]> wrote: Hi,The Geronimo PMC is pleased to announce that Christopher M. Cardonahas recently accepted our invitation to become an Apache GeronimoCommitter. Over the past few months, Chris has been working on the improvement of the Server Console and has demonstrated initiativesand a noteworthy ability to work with others.Congratulations and Welcome Christopher!
[ANNOUNCE] Please welcome Christopher M. Cardona as our newest Committer
Hi, The Geronimo PMC is pleased to announce that Christopher M. Cardona has recently accepted our invitation to become an Apache Geronimo Committer. Over the past few months, Chris has been working on the improvement of the Server Console and has demonstrated initiatives and a noteworthy ability to work with others. Congratulations and Welcome Christopher!
Re: Build error while running 'bootstrap openejb2'
Rick, Thanks for your reply. I got the errors resolved with the help of David Jencks. There were some files missing in svn and a few other files needed some updates. Build is successful now as of revision 465184. Thanks, VamsiOn 10/18/06, Rick McGuire <[EMAIL PROTECTED]> wrote: This is another one of those updates where updates to both openejb2 andgeronimo have occurred. I got this to build correctly using thefollowing steps: From the main geronimo directory: mvn -N From the geronimo modules directory: mvn clean install From the openejb2 directory: mvn clean install From the main geronimo directory: mvn clean installRickVamsavardhana Reddy wrote:> Error is due to a missing pom.xml . Console output given below. >> Reason: Could not find the model file> 'G:\target\external\openejb2\modules\opene> jb-corba-builder\pom.xml'.> [INFO]> > [INFO] Trace> org.apache.maven.reactor.MavenExecutionException: Could not find the> model file> 'G:\target\external\openejb2\modules\openejb-corba-builder\pom.xml'.> at> org.apache.maven.DefaultMaven.getProjects(DefaultMaven.java:365)> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:278)> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java :115)> at org.apache.maven.cli.MavenCli.main(MavenCli.java:256)> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)> at> sun.reflect.NativeMethodAccessorImpl.invoke (NativeMethodAccessorImpl.> java:39)> at> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces> sorImpl.java:25)> at java.lang.reflect.Method.invoke(Method.java :324)> at> org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)> at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)> at> org.codehaus.classworlds.Launcher.mainWithExitCode (Launcher.java:430)>> at org.codehaus.classworlds.Launcher.main(Launcher.java:375)> Caused by: org.apache.maven.project.ProjectBuildingException: Could> not find the> model file > 'G:\target\external\openejb2\modules\openejb-corba-builder\pom.xml'.>> at> org.apache.maven.project.DefaultMavenProjectBuilder.readModel(Default> MavenProjectBuilder.java:1274) > at> org.apache.maven.project.DefaultMavenProjectBuilder.buildFromSourceFi> leInternal(DefaultMavenProjectBuilder.java:414)> at> org.apache.maven.project.DefaultMavenProjectBuilder.build (DefaultMave> nProjectBuilder.java:192)> at org.apache.maven.DefaultMaven.getProject(DefaultMaven.java:515)> at> org.apache.maven.DefaultMaven.collectProjects(DefaultMaven.java:447) > at> org.apache.maven.DefaultMaven.collectProjects(DefaultMaven.java:491)> at> org.apache.maven.DefaultMaven.collectProjects(DefaultMaven.java:491)> at> org.apache.maven.DefaultMaven.getProjects (DefaultMaven.java:351)> ... 11 more> Caused by: java.io.FileNotFoundException:> G:\target\external\openejb2\modules\op> enejb-corba-builder\pom.xml (The system cannot find the file specified) > at java.io.FileInputStream.open(Native Method)> at java.io.FileInputStream.(FileInputStream.java:106)> at java.io.FileReader.(FileReader.java:55)> at > org.apache.maven.project.DefaultMavenProjectBuilder.readModel(Default> MavenProjectBuilder.java:1269)> ... 18 more
Re: Build error while running 'bootstrap openejb2'
This is another one of those updates where updates to both openejb2 and geronimo have occurred. I got this to build correctly using the following steps: From the main geronimo directory: mvn -N From the geronimo modules directory: mvn clean install From the openejb2 directory: mvn clean install From the main geronimo directory: mvn clean install Rick Vamsavardhana Reddy wrote: Error is due to a missing pom.xml . Console output given below. Reason: Could not find the model file 'G:\target\external\openejb2\modules\opene jb-corba-builder\pom.xml'. [INFO] [INFO] Trace org.apache.maven.reactor.MavenExecutionException: Could not find the model file 'G:\target\external\openejb2\modules\openejb-corba-builder\pom.xml'. at org.apache.maven.DefaultMaven.getProjects(DefaultMaven.java:365) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:278) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:115) at org.apache.maven.cli.MavenCli.main(MavenCli.java:256) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl. java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces sorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) at org.codehaus.classworlds.Launcher.main(Launcher.java:375) Caused by: org.apache.maven.project.ProjectBuildingException: Could not find the model file 'G:\target\external\openejb2\modules\openejb-corba-builder\pom.xml'. at org.apache.maven.project.DefaultMavenProjectBuilder.readModel(Default MavenProjectBuilder.java:1274) at org.apache.maven.project.DefaultMavenProjectBuilder.buildFromSourceFi leInternal(DefaultMavenProjectBuilder.java:414) at org.apache.maven.project.DefaultMavenProjectBuilder.build(DefaultMave nProjectBuilder.java:192) at org.apache.maven.DefaultMaven.getProject(DefaultMaven.java:515) at org.apache.maven.DefaultMaven.collectProjects(DefaultMaven.java:447) at org.apache.maven.DefaultMaven.collectProjects(DefaultMaven.java:491) at org.apache.maven.DefaultMaven.collectProjects(DefaultMaven.java:491) at org.apache.maven.DefaultMaven.getProjects(DefaultMaven.java:351) ... 11 more Caused by: java.io.FileNotFoundException: G:\target\external\openejb2\modules\op enejb-corba-builder\pom.xml (The system cannot find the file specified) at java.io.FileInputStream.open(Native Method) at java.io.FileInputStream.(FileInputStream.java:106) at java.io.FileReader.(FileReader.java:55) at org.apache.maven.project.DefaultMavenProjectBuilder.readModel(Default MavenProjectBuilder.java:1269) ... 18 more
[jira] Assigned: (AMQ-988) Thread synchronization error in TcpTransport
[ https://issues.apache.org/activemq/browse/AMQ-988?page=all ] Rob Lugt reassigned AMQ-988: Assignee: james strachan > Thread synchronization error in TcpTransport > > > Key: AMQ-988 > URL: https://issues.apache.org/activemq/browse/AMQ-988 > Project: ActiveMQ > Issue Type: Bug > Components: NMS (C# client) >Affects Versions: 4.0.2 > Environment: Windows >Reporter: Rob Lugt > Assigned To: james strachan > > I have a problem where my C# client application crashes when placed under > load. It's taken a while to get to the bottom of it, but I believe I have > identified the problem and luckily there's a simple solution. > The AMQ .Net client uses a common pattern where a full-duplex TCP/IP > connection is established with the broker, and the client uses two threads to > concurrently read and write data to/from the underlying socket - one thread > reading from a Reader object and the other writing to a Writer object. > The TcpTransport.Start() method contains the following:- > NetworkStream networkStream = new NetworkStream(socket); > socketWriter = new OpenWireBinaryWriter(networkStream); > socketReader = new OpenWireBinaryReader(networkStream); > This pattern is explicitly allowed in Java and Win32 applications, but .Net > is a little vague on the subject. The Microsoft documentation [1] suggests > use of the asynchronous read/write calls for multithreaded applications, but > that would significantly complicate the C# client which relies on blocking > stream behaviour. On the same doc page > Microsoft does specifiy that the Socket class is thread-safe, which I take to > mean that concurrent read/write calls are permitted, however the same is not > true of NetworkStream [2]. > Perhaps it would be reasonable to expect NetworkStream to have no internal > state other than the Socket it contains, but apparently this is not the case > because I've identified that it is a corrupt NetworkStream which is causing > my application to crash under load. After some experimentation and a fair > amount of load testing, I think the solution is a simple change to the > TcpTransport.start() method to use a separate NetworkStream for input and > output operations. e.g. :- > NetworkStream inputNetworkStream = new NetworkStream(socket); > NetworkStream outputNetworkStream = new NetworkStream(socket); > socketWriter = new OpenWireBinaryWriter(inputNetworkStream); > socketReader = new OpenWireBinaryReader(outputNetworkStream); > This works for me and my test client has now been running for 16 hours > without crashing (before it would rarely last longer than 10 minutes). > Regards > Rob Lugt > [1] http://msdn2.microsoft.com/en-us/library/system.net.sockets.socket.aspx > [2] > http://msdn2.microsoft.com/en-us/library/system.net.sockets.networkstream.aspx -- 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: servicemix examples
See http://servicemix.goopen.org/sm30ug/4-examples.html On 10/18/06, emicalc <[EMAIL PROTECTED]> wrote: Hello, I have downloaded the latest version of servicemix and I have noted that the examples are changed. Is there an example like "soap-binding"? Where is the documentation about the new examples? Cheers, Emilio -- View this message in context: http://www.nabble.com/servicemix-examples-tf2465383.html#a6872612 Sent from the ServiceMix - Dev mailing list archive at Nabble.com. -- Cheers, Guillaume Nodet
servicemix examples
Hello, I have downloaded the latest version of servicemix and I have noted that the examples are changed. Is there an example like "soap-binding"? Where is the documentation about the new examples? Cheers, Emilio -- View this message in context: http://www.nabble.com/servicemix-examples-tf2465383.html#a6872612 Sent from the ServiceMix - Dev mailing list archive at Nabble.com.
[jira] Updated: (AMQ-989) .Net Client: allow specification of wireFormat parameters in broker URI
[ https://issues.apache.org/activemq/browse/AMQ-989?page=all ] Rob Lugt updated AMQ-989: - Attachment: amq989.txt > .Net Client: allow specification of wireFormat parameters in broker URI > --- > > Key: AMQ-989 > URL: https://issues.apache.org/activemq/browse/AMQ-989 > Project: ActiveMQ > Issue Type: Improvement > Components: NMS (C# client) >Affects Versions: 4.0.2 > Environment: Windows >Reporter: Rob Lugt > Assigned To: james strachan > Attachments: amq989.txt > > > Update required to TcpTransportFactory to accept wireFormat connection > parameters in the connection URI. This is the only means for .Net client > applications to set properties such as tight/loose encoding. > Please apply the attached patch. > Best Regards > Rob Lugt -- 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-989) .Net Client: allow specification of wireFormat parameters in broker URI
.Net Client: allow specification of wireFormat parameters in broker URI --- Key: AMQ-989 URL: https://issues.apache.org/activemq/browse/AMQ-989 Project: ActiveMQ Issue Type: Improvement Components: NMS (C# client) Affects Versions: 4.0.2 Environment: Windows Reporter: Rob Lugt Assigned To: james strachan Update required to TcpTransportFactory to accept wireFormat connection parameters in the connection URI. This is the only means for .Net client applications to set properties such as tight/loose encoding. Please apply the attached patch. Best Regards Rob Lugt -- 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
