[jira] Created: (AMQ-994) .Net client TcpTransport does not prevent concurrent access to BinaryWriter
.Net client TcpTransport does not prevent concurrent access to BinaryWriter --- Key: AMQ-994 URL: https://issues.apache.org/activemq/browse/AMQ-994 Project: ActiveMQ Issue Type: Bug Components: NMS (C# client) Affects Versions: 4.0.2 Environment: Windows Reporter: Rob Lugt A client application using multiple sessions may write multiple messages concurrently. The underlying TcpTransport does not synchronize access to its BinaryWriter, resulting in possible data message corruption or worse. The TcpTransportFactory in the Java client uses a MutexTransport to protect the underlying socket. This technique would work equally well in the .Net client, but I propose simply locking the writer as the TcpTransport should argueably protect itselft rather than relying on the factory to provide protection. -- 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-994) .Net client TcpTransport does not prevent concurrent access to BinaryWriter
[ https://issues.apache.org/activemq/browse/AMQ-994?page=all ] Rob Lugt updated AMQ-994: - Attachment: patch-amq994.txt Patch to lock the socketWriter to protect against concurrent access. .Net client TcpTransport does not prevent concurrent access to BinaryWriter --- Key: AMQ-994 URL: https://issues.apache.org/activemq/browse/AMQ-994 Project: ActiveMQ Issue Type: Bug Components: NMS (C# client) Affects Versions: 4.0.2 Environment: Windows Reporter: Rob Lugt Attachments: patch-amq994.txt A client application using multiple sessions may write multiple messages concurrently. The underlying TcpTransport does not synchronize access to its BinaryWriter, resulting in possible data message corruption or worse. The TcpTransportFactory in the Java client uses a MutexTransport to protect the underlying socket. This technique would work equally well in the .Net client, but I propose simply locking the writer as the TcpTransport should argueably protect itselft rather than relying on the factory to provide protection. -- 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-995) An unhandled exception in the TcpTransports' reader thread should close the connection (and inform the app)
An unhandled exception in the TcpTransports' reader thread should close the connection (and inform the app) --- Key: AMQ-995 URL: https://issues.apache.org/activemq/browse/AMQ-995 Project: ActiveMQ Issue Type: Bug Components: NMS (C# client) Affects Versions: 4.0.2 Environment: Windows Reporter: Rob Lugt If the reader thread throws an exception (e.g. IOException) then the socket should be closed to prevent further messages being sent to the broker. If an exception is thrown during the marshalling of a message then there's no way for the stream to be set to the beginning of the next message, so all communication with the broker should cease at that point. Similarly, if the broker is killed, an IOException will probably be detected in the read thread first. -- 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-996) IConnection requires Start(), Stop() and Close() methods
IConnection requires Start(), Stop() and Close() methods Key: AMQ-996 URL: https://issues.apache.org/activemq/browse/AMQ-996 Project: ActiveMQ Issue Type: Improvement Components: NMS (C# client) Affects Versions: 4.0.2 Environment: Windows Reporter: Rob Lugt These three methods are needed to bring IConnection closer to the JMS Connection interface, and also provide important capabilities. Start() and Stop() methods should start and stop/join the underlying transport's reader thread. Close() should perform the tasks described in the JMS specification (ie wait for current message to be processed), whereas Dispose should probably concern itself simply with freeing up resources. Both Close() and Dispose() should be able to be called multiple times without throwing an exception. -- 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] Closed: (AMQ-978) No Messaged delivery when mixing Perl stomp client Producer/Consumer and Java JMS Producer/Consumer
[ https://issues.apache.org/activemq/browse/AMQ-978?page=all ] Sileshi Kassa closed AMQ-978. - Resolution: Won't Fix This is not ActiveMQ problem as such. This is more of the Perl Net::Stomp package dealing with binary data reading. No Messaged delivery when mixing Perl stomp client Producer/Consumer and Java JMS Producer/Consumer --- Key: AMQ-978 URL: https://issues.apache.org/activemq/browse/AMQ-978 Project: ActiveMQ Issue Type: Bug Components: Connector Environment: This problem seems platform independent: It happens in Linux, Mac OSX, and Windows. Software Used: ActiveMQ 4.0, Java 5.0, JMS, Perl 5.8.7, Perl CPAN module Net-Stomp-0.31 Reporter: Sileshi Kassa Attachments: Publisher.pl, Subscriber.pl Facts: Perl Stomp client Producer and Consumer works fine Java JMS client Producer and Consumer works fine I have also used other Perl Stomp protocol implementation with no problem. The problem happens when I mix Java and Perl clients Scenario Test 1: A. Perl Stomp client Consumer B. Java JMS client Producer Scenario Test 2: A. Java JMS client Consumer B. Perl Stomp client Producer I have looked into it via Java JMX management jconsole, and it seems to me there is a wall between the stomp server and default server. It the stomp server only passes messages coming from stomp lients and default server also does the same. If this is truly the case, and this is by design, I will be very disappointed. There should not be any wall. A message is message irrespective of its source and should be delivered to any one that is listening on the same destination. I will attach the Perl clients testcases. For Java client, a simple JMS client Producer and Consumer with the same topic used as the perl side will do the job. The topic I used on the perl side: /topic/Test.CrossDelivery and the Java side topic is Test.CrossDelivery This problem is a show stopper for us. -- 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-980) lastImageSubscriptionRecoveryPolicy does not work with wildcards
[ https://issues.apache.org/activemq/browse/AMQ-980?page=all ] Rob Lugt updated AMQ-980: - Component/s: NMS (C# client) (was: Broker) lastImageSubscriptionRecoveryPolicy does not work with wildcards Key: AMQ-980 URL: https://issues.apache.org/activemq/browse/AMQ-980 Project: ActiveMQ Issue Type: Bug Components: NMS (C# client) 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:- policyEntry topic=PRICES. subscriptionRecoveryPolicy lastImageSubscriptionRecoveryPolicy/ /subscriptionRecoveryPolicy /policyEntry 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
durable subscriptons
Is there a reason that the header field for durable subscriptions in Stomp is spelled subcriptionName rather than the more intuitive subscriptionName? The web page describing how to use this (www.activemq.org/site/stomp.html) mentions this field three times, spelled three different ways, none of them the way it is spelled in the code.
[jira] Created: (AMQ-997) Use the ACTIVEMQ_BASE environment variable to support running multiple broker instances from he same activemq install
Use the ACTIVEMQ_BASE environment variable to support running multiple broker
instances from he same activemq install
-
Key: AMQ-997
URL: https://issues.apache.org/activemq/browse/AMQ-997
Project: ActiveMQ
Issue Type: New Feature
Reporter: Hiram Chirino
Assigned To: Hiram Chirino
Fix For: 4.1
The activemq startup shell scripts are allready using / find the ACTIVEMQ_HOME
which is where AcitiveMQ has been installed. Currently, you can only run one
instance of the broker per ActiveMQ installation directory. We should support
running multiple broker instances using that same ACTIVEMQ_HOME. All the per
broker instance variable data should be relative to a new ACTIVEMQ_BASE
enviroment variable.
By default the ACTIVEMQ_BASE == ACTIVEMQ_HOME so that sarting up the default
activemq instance continues to behave as it allways has.
Createing a new per instance directory, as admin should only have to do:
{code}
export ACTIVEMQ_BASE=/path/to/new/directory
mkdir -p ${ACTIVEMQ_BASE}
cp -R ${ACTIVEMQ_HOME}/conf ${ACTIVEMQ_BASE}
{code}
customize the ${ACTIVEMQ_BASE}/conf/activemq.xml file
And to run the new instance:
{code}
export ACTIVEMQ_BASE=/path/to/new/directory
${ACTIVEMQ_HOME}/bin/activemq
{code}
--
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-997) Use the ACTIVEMQ_BASE environment variable to support running multiple broker instances from he same activemq install
[ https://issues.apache.org/activemq/browse/AMQ-997?page=all ]
Hiram Chirino resolved AMQ-997.
---
Resolution: Fixed
implemented.
Use the ACTIVEMQ_BASE environment variable to support running multiple broker
instances from he same activemq install
-
Key: AMQ-997
URL: https://issues.apache.org/activemq/browse/AMQ-997
Project: ActiveMQ
Issue Type: New Feature
Reporter: Hiram Chirino
Assigned To: Hiram Chirino
Fix For: 4.1
The activemq startup shell scripts are allready using / find the
ACTIVEMQ_HOME which is where AcitiveMQ has been installed. Currently, you
can only run one instance of the broker per ActiveMQ installation directory.
We should support running multiple broker instances using that same
ACTIVEMQ_HOME. All the per broker instance variable data should be relative
to a new ACTIVEMQ_BASE enviroment variable.
By default the ACTIVEMQ_BASE == ACTIVEMQ_HOME so that sarting up the default
activemq instance continues to behave as it allways has.
Createing a new per instance directory, as admin should only have to do:
{code}
export ACTIVEMQ_BASE=/path/to/new/directory
mkdir -p ${ACTIVEMQ_BASE}
cp -R ${ACTIVEMQ_HOME}/conf ${ACTIVEMQ_BASE}
{code}
customize the ${ACTIVEMQ_BASE}/conf/activemq.xml file
And to run the new instance:
{code}
export ACTIVEMQ_BASE=/path/to/new/directory
${ACTIVEMQ_HOME}/bin/activemq
{code}
--
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
[VOTE] Release Apache ActiveMQ 4.0.2 (RC 5)
Some copyright header/licence/notice issues were found in the 4th release candidate of the 4.0.2 build. I have cut and RC 5 of the 4.0.2 build with the fixes and it's available here: http://people.apache.org/~chirino/incubator-activemq-4.0.2-RC5/maven1/incubator-activemq/distributions/ Maven 1 and Maven 2 repos for this release can be found at: http://people.apache.org/~chirino/incubator-activemq-4.0.2-RC5 Here's the wiki page for the release notes: http://incubator.apache.org/activemq/activemq-402-release.html Please vote to approve this release binary [ ] +1 Release the binary as Apache ActiveMQ 4.0.2 [ ] -1 Veto the release (provide specific comments) This vote is being cross posted to the general incubator mailing list also to expedite the voting process. Here's my +1 -- Regards, Hiram Blog: http://hiramchirino.com
Re: [VOTE] Release Apache ActiveMQ 4.0.2 (RC 5)
+1 Hiram Chirino wrote: Some copyright header/licence/notice issues were found in the 4th release candidate of the 4.0.2 build. I have cut and RC 5 of the 4.0.2 build with the fixes and it's available here: http://people.apache.org/~chirino/incubator-activemq-4.0.2-RC5/maven1/incubator-activemq/distributions/ Maven 1 and Maven 2 repos for this release can be found at: http://people.apache.org/~chirino/incubator-activemq-4.0.2-RC5 Here's the wiki page for the release notes: http://incubator.apache.org/activemq/activemq-402-release.html Please vote to approve this release binary [ ] +1 Release the binary as Apache ActiveMQ 4.0.2 [ ] -1 Veto the release (provide specific comments) This vote is being cross posted to the general incubator mailing list also to expedite the voting process. Here's my +1
[jira] Reopened: (AMQ-978) No Messaged delivery when mixing Perl stomp client Producer/Consumer and Java JMS Producer/Consumer
[ https://issues.apache.org/activemq/browse/AMQ-978?page=all ] Hiram Chirino reopened AMQ-978: --- Assignee: Hiram Chirino No Messaged delivery when mixing Perl stomp client Producer/Consumer and Java JMS Producer/Consumer --- Key: AMQ-978 URL: https://issues.apache.org/activemq/browse/AMQ-978 Project: ActiveMQ Issue Type: Bug Components: Connector Environment: This problem seems platform independent: It happens in Linux, Mac OSX, and Windows. Software Used: ActiveMQ 4.0, Java 5.0, JMS, Perl 5.8.7, Perl CPAN module Net-Stomp-0.31 Reporter: Sileshi Kassa Assigned To: Hiram Chirino Attachments: Publisher.pl, Subscriber.pl Facts: Perl Stomp client Producer and Consumer works fine Java JMS client Producer and Consumer works fine I have also used other Perl Stomp protocol implementation with no problem. The problem happens when I mix Java and Perl clients Scenario Test 1: A. Perl Stomp client Consumer B. Java JMS client Producer Scenario Test 2: A. Java JMS client Consumer B. Perl Stomp client Producer I have looked into it via Java JMX management jconsole, and it seems to me there is a wall between the stomp server and default server. It the stomp server only passes messages coming from stomp lients and default server also does the same. If this is truly the case, and this is by design, I will be very disappointed. There should not be any wall. A message is message irrespective of its source and should be delivered to any one that is listening on the same destination. I will attach the Perl clients testcases. For Java client, a simple JMS client Producer and Consumer with the same topic used as the perl side will do the job. The topic I used on the perl side: /topic/Test.CrossDelivery and the Java side topic is Test.CrossDelivery This problem is a show stopper for us. -- 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-978) No Messaged delivery when mixing Perl stomp client Producer/Consumer and Java JMS Producer/Consumer
[ https://issues.apache.org/activemq/browse/AMQ-978?page=all ] Hiram Chirino updated AMQ-978: -- Attachment: Net-Stomp-0.31-bytemessage-support.patch I've made a modification to the Net::Stomp 0.31 package so that it can support receiving TextMessage and ByteMessages. We need to feed this back to the upstream maintainer so that it can get back on CPAN. No Messaged delivery when mixing Perl stomp client Producer/Consumer and Java JMS Producer/Consumer --- Key: AMQ-978 URL: https://issues.apache.org/activemq/browse/AMQ-978 Project: ActiveMQ Issue Type: Bug Components: Connector Environment: This problem seems platform independent: It happens in Linux, Mac OSX, and Windows. Software Used: ActiveMQ 4.0, Java 5.0, JMS, Perl 5.8.7, Perl CPAN module Net-Stomp-0.31 Reporter: Sileshi Kassa Assigned To: Hiram Chirino Attachments: Net-Stomp-0.31-bytemessage-support.patch, Publisher.pl, Subscriber.pl Facts: Perl Stomp client Producer and Consumer works fine Java JMS client Producer and Consumer works fine I have also used other Perl Stomp protocol implementation with no problem. The problem happens when I mix Java and Perl clients Scenario Test 1: A. Perl Stomp client Consumer B. Java JMS client Producer Scenario Test 2: A. Java JMS client Consumer B. Perl Stomp client Producer I have looked into it via Java JMX management jconsole, and it seems to me there is a wall between the stomp server and default server. It the stomp server only passes messages coming from stomp lients and default server also does the same. If this is truly the case, and this is by design, I will be very disappointed. There should not be any wall. A message is message irrespective of its source and should be delivered to any one that is listening on the same destination. I will attach the Perl clients testcases. For Java client, a simple JMS client Producer and Consumer with the same topic used as the perl side will do the job. The topic I used on the perl side: /topic/Test.CrossDelivery and the Java side topic is Test.CrossDelivery This problem is a show stopper for us. -- 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: Web server and distribution
Sounds like a great idea! On 10/11/06, Guillaume Nodet [EMAIL PROTECTED] wrote: In the current distribution, we currently ship ServiceMix as a standalone server, but we don't provide an easy way to deploy web applications. This would be very handy imho, so that we could maybe work more on the console web app (which is currently not very usable) and be able to deploy it easily on ServiceMix. So I'd like if we could start a jetty 6 server and maybe use it to provide all the http stuff (the servicemix-http component could be deployed and use it instead of starting its own http server). Another way would be to use a very light geronimo server (which should be able using G 1.2) which would only contain a Jetty 6 web server and ActiveMQ 4 broker. And maybe the Geronimo console augmented by our own console. Opinions ? -- Cheers, Guillaume Nodet -- Regards, Hiram Blog: http://hiramchirino.com
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.
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
[VOTE RESULT] Release XBean 2.7
The vote has passed with 7 +1. I have cut the release, singed and published it at http://people.apache.org/repo/m2-ibiblio-rsync-repository/org/apache/xbean/ Thanks ! -- Cheers, Guillaume Nodet
Re: [ANNOUNCE] Please welcome Vamsavardhana Reddy as one of our newest Committer
Congratulations Vamsi! Gianny On 19/10/2006, at 1: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.org Apache Yoko - http://incubator.apache.org/yoko LiveTribe - http://www.livetribe.org
Re: Failure on schemas when builing trunk
I had a successful build yesterday and there were no changes to the
source tree after that. I was verifying this and your second post
came :o)
VamsiOn 10/19/06, Guillaume Nodet [EMAIL PROTECTED] wrote:
Oops, sorry.Cleaning all the modules helped ...On 10/19/06, Guillaume Nodet [EMAIL PROTECTED] wrote: 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 'clustering@http://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 'security@http://geronimo.apache.org/xml/ns/j2ee/applicatio n-1.2' not found.
-- Cheers, Guillaume Nodet--Cheers,Guillaume Nodet
Re: [VOTE] Accept CIMERO code donation
+1 again Charles Souillard wrote: +1 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 -- View this message in context: http://www.nabble.com/-VOTE--Accept-CIMERO-code-donation-tf2305523.html#a6893375 Sent from the ServiceMix - Dev mailing list archive at Nabble.com.
[jira] Updated: (GERONIMO-2413) Add a Certification Authority (CA) portlet to Geronimo console
[ http://issues.apache.org/jira/browse/GERONIMO-2413?page=all ] Vamsavardhana Reddy updated GERONIMO-2413: -- Attachment: GERONIMO-2413-v1.1.x.patch GERONIMO-2413-v1.1.x.patch: For those who want to try out the CA portlet on 1.1.x codebase. Add a Certification Authority (CA) portlet to Geronimo console -- Key: GERONIMO-2413 URL: http://issues.apache.org/jira/browse/GERONIMO-2413 Project: Geronimo Issue Type: New Feature Security Level: public(Regular issues) Components: console, security Reporter: Vamsavardhana Reddy Fix For: 1.2, 1.x Attachments: 02.ca-initialization-enter-details.JPG, 07.issue-certificate-show-csr-details.JPG, 09.issue-certificate-successful.JPG, GERONIMO-2413-revised.patch, GERONIMO-2413-v1.1.x.patch, GERONIMO-2413-v1.2.patch, GERONIMO-2413.patch, GeronimoCA.zip A Certification Authority portlet will be very useful. A full fledged CA may be a long way to go. But what ever minimum function is required to process CSR's etc. is not hard and the users can issue their own digital certificates instead of getting trial certificates from some CA. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (GERONIMO-2503) Webapp classloader prefers WEB-INF/lib over WEB-INF/classes
Webapp classloader prefers WEB-INF/lib over WEB-INF/classes --- Key: GERONIMO-2503 URL: http://issues.apache.org/jira/browse/GERONIMO-2503 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Components: web Affects Versions: 1.1.1, 1.1 Environment: windows and linux, jetty and tomcat Reporter: Nikla Ratinen Application classloader looks in WAR's WEB-INF/lib before WEB-INF/classes. This is in violation of servlet 2.4 (and 2.3) specification, 9.5 Directory Structure, which states: TheWeb application class loader must load classes from the WEB-INF/ classes directory first, and then from library JARs in the WEB-INF/lib directory. This behaviour prevents web application from overriding classes and resources from included libraries. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (GERONIMO-2503) Webapp classloader prefers WEB-INF/lib over WEB-INF/classes
[ http://issues.apache.org/jira/browse/GERONIMO-2503?page=all ] Nikla Ratinen updated GERONIMO-2503: Attachment: patch.txt test.war A minimal web application to demonstrate the issue. Should print Servlet loaded from WEB-INF/classes to System.out when servlet class loaded from WEB-INF/classes. Also, a patch against org.apache.geronimo.web.deployment.AbstractWebModuleBuilder to change classloading order. Webapp classloader prefers WEB-INF/lib over WEB-INF/classes --- Key: GERONIMO-2503 URL: http://issues.apache.org/jira/browse/GERONIMO-2503 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: web Affects Versions: 1.1, 1.1.1 Environment: windows and linux, jetty and tomcat Reporter: Nikla Ratinen Attachments: patch.txt, test.war Application classloader looks in WAR's WEB-INF/lib before WEB-INF/classes. This is in violation of servlet 2.4 (and 2.3) specification, 9.5 Directory Structure, which states: TheWeb application class loader must load classes from the WEB-INF/ classes directory first, and then from library JARs in the WEB-INF/lib directory. This behaviour prevents web application from overriding classes and resources from included libraries. -- 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] Assigned: (GERONIMO-2503) Webapp classloader prefers WEB-INF/lib over WEB-INF/classes
[ http://issues.apache.org/jira/browse/GERONIMO-2503?page=all ] Rick McGuire reassigned GERONIMO-2503: -- Assignee: Rick McGuire Webapp classloader prefers WEB-INF/lib over WEB-INF/classes --- Key: GERONIMO-2503 URL: http://issues.apache.org/jira/browse/GERONIMO-2503 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: web Affects Versions: 1.1, 1.1.1 Environment: windows and linux, jetty and tomcat Reporter: Nikla Ratinen Assigned To: Rick McGuire Attachments: patch.txt, test.war Application classloader looks in WAR's WEB-INF/lib before WEB-INF/classes. This is in violation of servlet 2.4 (and 2.3) specification, 9.5 Directory Structure, which states: TheWeb application class loader must load classes from the WEB-INF/ classes directory first, and then from library JARs in the WEB-INF/lib directory. This behaviour prevents web application from overriding classes and resources from included libraries. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (GERONIMO-2504) Allow all read-only operations on KeystoreInstance to be available to services
Allow all read-only operations on KeystoreInstance to be available to services -- Key: GERONIMO-2504 URL: http://issues.apache.org/jira/browse/GERONIMO-2504 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Components: console, security Reporter: Guillaume Nodet Assigned To: Guillaume Nodet Fix For: 1.2 Currently, the only operations available to services are SSL factory creations. This is quite unsufficient when you need to use WS-Security for example to sign / crypt / encrypt messages. The attached patch has the following modifications: * add several methods to KeystoreInstance * all methods use a keystorePassword parameter used in the following way - write operations on keystore must be given a non-null password - read-only operations may be given a null password, in which case, the internal saved password will be used * all methods throw a KeystoreException existing exceptions have been refactored to inherit this exception * fix several keystore porlets problems: - password is not validated - some actions fail when the keystore is not unlocked for use -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (GERONIMO-2504) Allow all read-only operations on KeystoreInstance to be available to services
[ http://issues.apache.org/jira/browse/GERONIMO-2504?page=all ] Guillaume Nodet updated GERONIMO-2504: -- Attachment: GERONIMO-2504.patch Allow all read-only operations on KeystoreInstance to be available to services -- Key: GERONIMO-2504 URL: http://issues.apache.org/jira/browse/GERONIMO-2504 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: console, security Reporter: Guillaume Nodet Assigned To: Guillaume Nodet Fix For: 1.2 Attachments: GERONIMO-2504.patch Currently, the only operations available to services are SSL factory creations. This is quite unsufficient when you need to use WS-Security for example to sign / crypt / encrypt messages. The attached patch has the following modifications: * add several methods to KeystoreInstance * all methods use a keystorePassword parameter used in the following way - write operations on keystore must be given a non-null password - read-only operations may be given a null password, in which case, the internal saved password will be used * all methods throw a KeystoreException existing exceptions have been refactored to inherit this exception * fix several keystore porlets problems: - password is not validated - some actions fail when the keystore is not unlocked for use -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (GERONIMO-2504) Allow all read-only operations on KeystoreInstance to be available to services
[ http://issues.apache.org/jira/browse/GERONIMO-2504?page=all ] Guillaume Nodet updated GERONIMO-2504: -- Attachment: GERONIMO-2504.openejb.patch Allow all read-only operations on KeystoreInstance to be available to services -- Key: GERONIMO-2504 URL: http://issues.apache.org/jira/browse/GERONIMO-2504 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: console, security Reporter: Guillaume Nodet Assigned To: Guillaume Nodet Fix For: 1.2 Attachments: GERONIMO-2504.openejb.patch, GERONIMO-2504.patch Currently, the only operations available to services are SSL factory creations. This is quite unsufficient when you need to use WS-Security for example to sign / crypt / encrypt messages. The attached patch has the following modifications: * add several methods to KeystoreInstance * all methods use a keystorePassword parameter used in the following way - write operations on keystore must be given a non-null password - read-only operations may be given a null password, in which case, the internal saved password will be used * all methods throw a KeystoreException existing exceptions have been refactored to inherit this exception * fix several keystore porlets problems: - password is not validated - some actions fail when the keystore is not unlocked for use -- 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: Fwd: Certification Authority (CA) portlet
Hi Hernan, I have uploaded CA portlet and helper application patch to JIRA. With what the portlet and the helper application provides, you should be able to submit a certificate request from web browser that supports KEYGEN tag (IE doesn't) and install the issued certificate back into the web browser . I have also provided a patch that can be used with 1.1.x codebase. Incase you are blocked by build problems on trunk you may try using this patch on branches\1.1 . Thanks, VamsiOn 10/10/06, Hernan Cunico [EMAIL PROTECTED] wrote: Absolutely, my bad. I guess I'll have a better idea how it is integrated once I try the patch.Cheers!HernanVamsavardhana Reddy wrote: That should go as part of Keystore portlet (may be), but not CA portlet. Vamsi On 10/10/06, *Hernan Cunico* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Thanks for the details Vamsi. Not that it will be used a lot (a migration scenario) but do you have any plans for exporting a whole keystore (and then choose the type) feature? Cheers! Hernan Vamsavardhana Reddy wrote: Hernan, In the Issue New Certificate function, there is no selection of JKS or p12.The CA will only be generating a certificate and the certificate is usually provided in a base64 encoded text.Once the requestor receives this text file, he/she will need to import this certificate into a keystore or browser where ever the private key is stored. Regarding search, search based on more criteria is needed.I am evolving this as I am going about develpoing the CA.The simplest search (and only search as of now) is based on serial number as the certificates are now stored as serial-number.txt.To support other criteria (in an efficient way) the certificates may need to be stored differently. N2:A PKCS10 requests will have the name information and public-key combined into a sequence and signed using the private-key.This is usually generated by tools like keytool.Some browsers support a KEYGEN tag which will make the browser generate a keypair, combine the public-key along with a challenge phrase, sign the same (known as SignedPublicKeyChallenge) and send it to the server when the form is submitted.CA should be able to handle both the formats for the requests (and any other commonly used formats, like self-signed certificate). Once the CA is setup, CA will need an interface (I call this CA Helper App as of now) using which certificates can be requested and downloaded etc.I am in the process of developing a sample application.For a certificate request received, processed and user downloads certificate, a typical workflow would be. Step 1:A user submits a certificate request by accessing a Request Certificate page in the application through the web browser.What happens at this step is that the browser generates a keypair, and sends tha public key (packaged as a SignedPublicKeyAndChallenge) and name information to the application.Application saves this information in a CertificateRequestStore and provides an request-id to the user. Step 2:CA accesses all these requests in the CertificateRequestStore in a screen in the CA portlet under List Requests waiting verification and approves or rejects the requests.In a real-world scenario, CA will have to verify the details provided by the requestor etc.Once approved, the request will showup in List Requests ready to be fulfilled. Step 3: CA accesses the requests ready to be fulfilled and processes the request by issuing a certificate.This certificate is stored in the Certificate Store and the fufilled request is removed from the Certificate Request Store. Step 4: User will visit a Download Certificate page in the CA Helper App, provides the request-id given to him (in Step 1) and downloads his/her certificate.The CA Helper App will upload the ceritificate to the user's web browser with appropriate mime-header.The browser will store the certificate along with the private key and the certificate is ready for use. I have implemented most of it and am testing the code.I am still using 1.1.1 code base for development since trunk is unstable and I do not want to be blocked by build failures.Once I complete the testing I will test the code by integrating it into trunk, create a patch and submit to JIRA.It will be a couple of days more before the new patch will showup in the JIRA. Thanks, Vamsi On 10/10/06, *Hernan Cunico* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] mailto: [EMAIL PROTECTED] mailto: [EMAIL PROTECTED] wrote: Hi Vamsi, I still have not had the chance to check the patch (GERONIMO-2413) but I do have a few questions form your first note. 4. can you select JKS or p12 in this step? I'm thinking in client certificates - HTTPS with Client Authentication scenario 5. in addition on entering the serial #, any chance to list the existing certificates in the CertificateStore? maybe CN + Alias N1. does that mean that the CSR will be provided as a text file (on a specific location) and the portlet will pick them up and list them? if so,
Re: JMX Portlet and java.lang.Object operations
It is not specific to JMX Viewer which uses GBeanInfo to get the list of operations. The mc4j console also shows these as operations on JMX Mbeans. It is a bug. Could you please open an issue.thanksAnitaGuillaume Nodet [EMAIL PROTECTED] wrote: Does anybody know why all java.lang.Object methodsare exposed as operations on JMX Mbeans whenyou browse the JMX portlet ?-- Cheers,Guillaume Nodet Yahoo! Messenger with Voice. Make PC-to-Phone Calls to the US (and 30+ countries) for 2¢/min or less.
Re: JMX Portlet and java.lang.Object operations
Hi Guillaume, Those operations are being returned by a call to GBeanInfo.getOperations(). Do we need to filter those operations? Best wishes, chris Guillaume Nodet wrote: Does anybody know why all java.lang.Object methods are exposed as operations on JMX Mbeans when you browse the JMX portlet ?
[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_12443523 ] Matt Hogstrom commented on DAYTRADER-14: The challenge as you pointed out is to somehow invalidate the KeySequence SLSBs. Since their most likely pooled it makes it a bit more tricky. The simplest way to do this which is non-standard would be to use a static int or some other fingerprint on the integrity of the tables. However, this doesn't help the situation when your running a cluster of the application so its applicability would be really to a single server. One possibility is to put in a timestamp as static that indicates the last time the table was valid. Then, for each SLSB keep a last used time and compare the two. If the last used is less than the valid then the beans need to be refreshed so all values could be reset at that time. The easiest solution I think is to allow the tables to be created...if they already exist warn the user that they need to recycle their environment. I'd be happy with that solution as its way better than what we have. If someone is repopulating...they should be fine with recycling. If possible, I'd add some text when a duplicate key exception occurs that would tip off the user of the possible problem with the Key entity. 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] Updated: (GERONIMO-2503) Webapp classloader prefers WEB-INF/lib over WEB-INF/classes
[ http://issues.apache.org/jira/browse/GERONIMO-2503?page=all ] Rick McGuire updated GERONIMO-2503: --- Fix Version/s: 1.1.2 1.2 Webapp classloader prefers WEB-INF/lib over WEB-INF/classes --- Key: GERONIMO-2503 URL: http://issues.apache.org/jira/browse/GERONIMO-2503 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: web Affects Versions: 1.1, 1.1.1 Environment: windows and linux, jetty and tomcat Reporter: Nikla Ratinen Assigned To: Rick McGuire Fix For: 1.2, 1.1.2 Attachments: patch.txt, test.war Application classloader looks in WAR's WEB-INF/lib before WEB-INF/classes. This is in violation of servlet 2.4 (and 2.3) specification, 9.5 Directory Structure, which states: TheWeb application class loader must load classes from the WEB-INF/ classes directory first, and then from library JARs in the WEB-INF/lib directory. This behaviour prevents web application from overriding classes and resources from included libraries. -- 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: Fwd: Certification Authority (CA) portlet
Hi Vamsi, great, I saw the updates to the JIRA and yes, I was having some issues building from trunk. I'm about to give it a shot again, I think it works now. Nice work ;-) ! Cheers! Hernan Vamsavardhana Reddy wrote: Hi Hernan, I have uploaded CA portlet and helper application patch to JIRA. With what the portlet and the helper application provides, you should be able to submit a certificate request from web browser that supports KEYGEN tag (IE doesn't) and install the issued certificate back into the web browser . I have also provided a patch that can be used with 1.1.x codebase. Incase you are blocked by build problems on trunk you may try using this patch on branches\1.1 . Thanks, Vamsi On 10/10/06, *Hernan Cunico* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Absolutely, my bad. I guess I'll have a better idea how it is integrated once I try the patch. Cheers! Hernan Vamsavardhana Reddy wrote: That should go as part of Keystore portlet (may be), but not CA portlet. Vamsi On 10/10/06, *Hernan Cunico* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Thanks for the details Vamsi. Not that it will be used a lot (a migration scenario) but do you have any plans for exporting a whole keystore (and then choose the type) feature? Cheers! Hernan Vamsavardhana Reddy wrote: Hernan, In the Issue New Certificate function, there is no selection of JKS or p12. The CA will only be generating a certificate and the certificate is usually provided in a base64 encoded text. Once the requestor receives this text file, he/she will need to import this certificate into a keystore or browser where ever the private key is stored. Regarding search, search based on more criteria is needed. I am evolving this as I am going about develpoing the CA. The simplest search (and only search as of now) is based on serial number as the certificates are now stored as serial-number.txt. To support other criteria (in an efficient way) the certificates may need to be stored differently. N2: A PKCS10 requests will have the name information and public-key combined into a sequence and signed using the private-key. This is usually generated by tools like keytool. Some browsers support a KEYGEN tag which will make the browser generate a keypair, combine the public-key along with a challenge phrase, sign the same (known as SignedPublicKeyChallenge) and send it to the server when the form is submitted. CA should be able to handle both the formats for the requests (and any other commonly used formats, like self-signed certificate). Once the CA is setup, CA will need an interface (I call this CA Helper App as of now) using which certificates can be requested and downloaded etc. I am in the process of developing a sample application. For a certificate request received, processed and user downloads certificate, a typical workflow would be. Step 1: A user submits a certificate request by accessing a Request Certificate page in the application through the web browser. What happens at this step is that the browser generates a keypair, and sends tha public key (packaged as a SignedPublicKeyAndChallenge) and name information to the application. Application saves this information in a CertificateRequestStore and provides an request-id to the user. Step 2: CA accesses all these requests in the CertificateRequestStore in a screen in the CA portlet under List Requests waiting verification and approves or rejects the requests. In a real-world scenario, CA will have to verify the details provided by the requestor etc. Once approved, the request will showup in List Requests ready to be fulfilled. Step 3: CA accesses the requests ready to be fulfilled and processes the request by issuing a certificate. This certificate is stored in the Certificate Store and the fufilled request is removed from the Certificate Request Store. Step 4: User will visit a Download Certificate page in the
[jira] Resolved: (GERONIMO-2503) Webapp classloader prefers WEB-INF/lib over WEB-INF/classes
[ http://issues.apache.org/jira/browse/GERONIMO-2503?page=all ] Rick McGuire resolved GERONIMO-2503. Resolution: Fixed Fixed in version 1.1.x Committed revision 465625. Fixed in trunk Committed revision 465638. Webapp classloader prefers WEB-INF/lib over WEB-INF/classes --- Key: GERONIMO-2503 URL: http://issues.apache.org/jira/browse/GERONIMO-2503 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: web Affects Versions: 1.1, 1.1.1 Environment: windows and linux, jetty and tomcat Reporter: Nikla Ratinen Assigned To: Rick McGuire Fix For: 1.1.2, 1.2 Attachments: patch.txt, test.war Application classloader looks in WAR's WEB-INF/lib before WEB-INF/classes. This is in violation of servlet 2.4 (and 2.3) specification, 9.5 Directory Structure, which states: TheWeb application class loader must load classes from the WEB-INF/ classes directory first, and then from library JARs in the WEB-INF/lib directory. This behaviour prevents web application from overriding classes and resources from included libraries. -- 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
activemq.prefetchSize behavior concerns in STOMP C client
Hi, I am using STOMP C client with latest build available of AMQ (pre 4.0.2 10/17 build). I have some questions about how prefetchSize is affecting my client working. My STOMP C consumer is implemented in a way that once it connected to the AMQ server it loops and reads all the messages in the particular queue. And once all the messages are read it disconnects. What I am seeing here is if I have a prefetchSize value set then it only reads messages up to the prefetchSize value and then it blocks at the stomp_read call. If I don't have any prefetchSize value set then it loops and stomp_read reads all the messages in the queue. But my Openwire java client doesn't behave similarly. Even if I have a prefetchSize set to a small value in java client every nextMessage() call gives me a message if there is any message in the queue. I am not sure why there is different in prefetchSize working in STOMP and java client. Is this expected behavior? Any help would be appreciated. Thanks! Vik
[jira] Reopened: (AMQ-980) lastImageSubscriptionRecoveryPolicy does not work with wildcards
[ https://issues.apache.org/activemq/browse/AMQ-980?page=all ] Rob Lugt reopened AMQ-980: -- It transpires this is a bug/feature in the .Net client. The broker correctly dispatches the last image messages to the client, but the client receives them before the call to Session.CreateConsumer() completes, so it has not yet had a chance to register its listener. The messages are queued, and when the client does eventually register its listener, it starts to dispatch the queued messages. However only one (or perhaps several) messages are dispatched due to a fix we put in recently to prevent thread starvation. This problem will be rectified if we have a dedicated dispatching thread per session. lastImageSubscriptionRecoveryPolicy does not work with wildcards Key: AMQ-980 URL: https://issues.apache.org/activemq/browse/AMQ-980 Project: ActiveMQ Issue Type: Bug Components: NMS (C# client) 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:- policyEntry topic=PRICES. subscriptionRecoveryPolicy lastImageSubscriptionRecoveryPolicy/ /subscriptionRecoveryPolicy /policyEntry 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] Commented: (AMQ-980) lastImageSubscriptionRecoveryPolicy does not work with wildcards
[ https://issues.apache.org/activemq/browse/AMQ-980?page=comments#action_37248 ] james strachan commented on AMQ-980: Ah cool - thanks for the analysis Rob. As soon as we've the '1 thread per session' change in ActiveMQ.Net we can retest that things are working fine lastImageSubscriptionRecoveryPolicy does not work with wildcards Key: AMQ-980 URL: https://issues.apache.org/activemq/browse/AMQ-980 Project: ActiveMQ Issue Type: Bug Components: NMS (C# client) 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:- policyEntry topic=PRICES. subscriptionRecoveryPolicy lastImageSubscriptionRecoveryPolicy/ /subscriptionRecoveryPolicy /policyEntry 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: JSTL 1.2 for JEE 5
Does anyone know of an alternative to Glassfish's JSTL 1.2? Also, I wonder if Jakarta might consider providing an implementation if we expressed interest in using it in Geronimo? Paul On 10/18/06, Joe Bohn [EMAIL PROTECTED] wrote: 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: JMX Portlet and java.lang.Object operations
One of the places the filtering could be done is GBeanInfoBuilder.addInterface(..). This would make sure that the fake MBeanServer also returns correct operations. ThanksAnita "Christopher M. Cardona" [EMAIL PROTECTED] wrote: Hi Guillaume,Those operations are being returned by a call to GBeanInfo.getOperations(). Do we need to filter those operations?Best wishes,chrisGuillaume Nodet wrote: Does anybody know why all java.lang.Object methods are exposed as operations on JMX Mbeans when you browse the JMX portlet ? Get your email and more, right on the new Yahoo.com
Re: WS-Security and Geronimo KeystoreInstance
I have raised a JIRA: http://issues.apache.org/jira/browse/GERONIMO-2504 Any objections to me committing this in ? Well, actually, i will need help, as there is a very small patch to openejb and I do not have karma ... On 10/19/06, Guillaume Nodet [EMAIL PROTECTED] wrote: 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 -- Cheers, Guillaume Nodet
Re: Download page incorrectly lists OS X and Unix as being compatible
On Oct 18, 2006, at 5:31 PM, 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? The web page seems OK to me, as is. The *releases* are certified. We create different distributions to aid users in installing on different platforms. They all contain the same binaries... If you want to remove the certified, I'm ok with that. If we want to add explicit information about what platforms we certify on (Linux and Azul at the moment), we can do that, also... --kevan
Re: JMX Portlet and java.lang.Object operations
Issue raised: http://issues.apache.org/jira/browse/GERONIMO-2505 On 10/19/06, anita kulshreshtha [EMAIL PROTECTED] wrote: It is not specific to JMX Viewer which uses GBeanInfo to get the list of operations. The mc4j console also shows these as operations on JMX Mbeans. It is a bug. Could you please open an issue. thanks Anita Guillaume Nodet [EMAIL PROTECTED] wrote: Does anybody know why all java.lang.Object methods are exposed as operations on JMX Mbeans when you browse the JMX portlet ? -- Cheers, Guillaume Nodet Yahoo! Messenger with Voice. Make PC-to-Phone Calls to the US (and 30+ countries) for 2¢/min or less. -- Cheers, Guillaume Nodet
[jira] Created: (GERONIMO-2505) GBeanInfo.getOperations() returns the operations defined on java.lang.Object. They should be filtered
GBeanInfo.getOperations() returns the operations defined on java.lang.Object. They should be filtered - Key: GERONIMO-2505 URL: http://issues.apache.org/jira/browse/GERONIMO-2505 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Components: core Affects Versions: 1.1.1 Reporter: Guillaume Nodet Priority: Minor -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (GERONIMO-2506) NullPointerException in TransactionContextBeforeAfter.after()
NullPointerException in TransactionContextBeforeAfter.after() - Key: GERONIMO-2506 URL: http://issues.apache.org/jira/browse/GERONIMO-2506 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Components: transaction manager Affects Versions: 1.1 Environment: Geronimo-1.1 Reporter: Alex Boisvert I'm getting the following NPE after a transaction rollback when running with Apache Ode deployed as a webapp and explicitly managing transaction through Geronimo's TransactionContextManager (wrapped as TransactionManager using Jencks): 12:52:45,978 WARN [HttpConnection] POST /ode/processes/Async HTTP/1.1 java.lang.NullPointerException at org.apache.geronimo.jetty.interceptor.TransactionContextBeforeAfter.after(TransactionContextBeforeAfter.java:71) at org.apache.geronimo.jetty.interceptor.ComponentContextBeforeAfter.after(ComponentContextBeforeAfter.java:50) at org.apache.geronimo.jetty.interceptor.ThreadClassloaderBeforeAfter.after(ThreadClassloaderBeforeAfter.java:52) at org.apache.geronimo.jetty.interceptor.WebApplicationContextBeforeAfter.after(WebApplicationContextBeforeAfter.java:51) at org.apache.geronimo.jetty.interceptor.RequestWrappingBeforeAfter.after(RequestWrappingBeforeAfter.java:53) at org.apache.geronimo.jetty.JettyWebAppContext.leaveContextScope(JettyWebAppContext.java:375) at org.mortbay.http.HttpContext.handle(HttpContext.java:1542) at org.mortbay.jetty.servlet.WebApplicationContext.handle(WebApplicationContext.java:633) at org.mortbay.http.HttpContext.handle(HttpContext.java:1482) at org.mortbay.http.HttpServer.service(HttpServer.java:909) at org.mortbay.http.HttpConnection.service(HttpConnection.java:816) at org.mortbay.http.HttpConnection.handleNext(HttpConnection.java:982) at org.mortbay.http.HttpConnection.handle(HttpConnection.java:833) at org.mortbay.http.SocketListener.handleConnection(SocketListener.java:244) at org.mortbay.util.ThreadedServer.handle(ThreadedServer.java:357) at org.mortbay.util.ThreadPool$PoolThread.run(ThreadPool.java:534) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (GERONIMO-2504) Allow all read-only operations on KeystoreInstance to be available to services
[ http://issues.apache.org/jira/browse/GERONIMO-2504?page=all ] Guillaume Nodet updated GERONIMO-2504: -- Attachment: GERONIMO-2504.openejb.patch Javadoc fixed Allow all read-only operations on KeystoreInstance to be available to services -- Key: GERONIMO-2504 URL: http://issues.apache.org/jira/browse/GERONIMO-2504 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: security, console Reporter: Guillaume Nodet Assigned To: Guillaume Nodet Fix For: 1.2 Attachments: GERONIMO-2504.openejb.patch, GERONIMO-2504.openejb.patch, GERONIMO-2504.patch Currently, the only operations available to services are SSL factory creations. This is quite unsufficient when you need to use WS-Security for example to sign / crypt / encrypt messages. The attached patch has the following modifications: * add several methods to KeystoreInstance * all methods use a keystorePassword parameter used in the following way - write operations on keystore must be given a non-null password - read-only operations may be given a null password, in which case, the internal saved password will be used * all methods throw a KeystoreException existing exceptions have been refactored to inherit this exception * fix several keystore porlets problems: - password is not validated - some actions fail when the keystore is not unlocked for use -- 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: JSTL 1.2 for JEE 5
Here's another option. Depending on how much the spec has changed between 1.1 and 1.2, we could fork jakarta and provide our own implementation. Just a thought. Then again, what are the pros and cons of picking up Glassfish ? Cheers Prasad On 10/19/06, Paul McMahan [EMAIL PROTECTED] wrote: Does anyone know of an alternative to Glassfish's JSTL 1.2? Also, I wonder if Jakarta might consider providing an implementation if we expressed interest in using it in Geronimo? Paul On 10/18/06, Joe Bohn [EMAIL PROTECTED] wrote: 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: Webapps exposed on distinct ports
Hi Mark, thanks for bringing this up. I also noted the sample is not working and I'm working on it to fix it. Not sure why it's failing now so I could use some help too. Cheers! Hernan Mark Bradley wrote: I'm still stuck on this, and unfortunately I cannot deploy my applications in production with Geronimo until I get this working. Has anyone been able to deploy two different applications to two different tomcat connectors in the same Geronimo instance? As shown below, the example on the wiki does not work! Thanks, -Mark Well, I thought that I might be able to take the example in wiki (http://cwiki.apache.org/GMOxDOC11/exposing-web-applications-on- distinct-ports.html) and whittle it down to what I need, but I can't even deploy the example .ear( appPerPort.ear). I get this error: geronimo-1.1.1% java -jar bin/deployer.jar deploy appPerPort.ear Error: Unable to distribute appPerPort.ear: Cannot deploy the requested application module because no deployer is able to handle it. This can happen if you have omitted the J2EE deployment descriptor, disabled a deployer module, or if, for example, you are trying to deploy an EJB module on a minimal Geronimo server that does not have EJB support installed. (moduleFile=/Users/mark/Programs/geronimo-1.1.1/var/temp/ geronimo-deployer4506.tmpdir/appPerPort.ear) and here is the stack trace in the log: Deployer operation failed: Cannot deploy the requested application module because no deployer is able to handle it. This can happen if you have omitted the J2EE deployment descriptor, disabled a deployer module, or if, for example, you are trying to deploy an EJB module on a minimal Geronimo server that does not have EJB support installed. (moduleFile=/Users/mark/Programs/geronimo-1.1.1/var/temp/geronimo- deployer4504.tmpdir/appperport.ear) org.apache.geronimo.common.DeploymentException: Cannot deploy the requested application module because no deployer is able to handle it. This can happen if you have omitted the J2EE deployment descriptor, disabled a deployer module, or if, for example, you are trying to deploy an EJB module on a minimal Geronimo server that does not have EJB support installed. (moduleFile=/Users/mark/Programs/ geronimo-1.1.1/var/temp/geronimo-deployer4504.tmpdir/appperport.ear) at org.apache.geronimo.deployment.Deployer.deploy (Deployer.java:239) at org.apache.geronimo.deployment.Deployer.deploy (Deployer.java:124) at org.apache.geronimo.deployment.Deployer$$FastClassByCGLIB$ $734a235d.invoke(generated) at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53) at org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke (FastMethodInvoker.java:38) at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke (GBeanOperation.java:122) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke (GBeanInstance.java:852) at org.apache.geronimo.kernel.basic.BasicKernel.invoke (BasicKernel.java:239) at org.apache.geronimo.deployment.plugin.local.AbstractDeployCommand.doDepl oy(AbstractDeployCommand.java:106) at org.apache.geronimo.deployment.plugin.local.DistributeCommand.run (DistributeCommand.java:60) at java.lang.Thread.run(Thread.java:613) Any ideas?
Re: [VOTE] Release Apache ActiveMQ 4.0.2 (RC 5)
+1 On 10/19/06, Hiram Chirino [EMAIL PROTECTED] wrote: Some copyright header/licence/notice issues were found in the 4th release candidate of the 4.0.2 build. I have cut and RC 5 of the 4.0.2 build with the fixes and it's available here: http://people.apache.org/~chirino/incubator-activemq-4.0.2-RC5/maven1/incubator-activemq/distributions/ Maven 1 and Maven 2 repos for this release can be found at: http://people.apache.org/~chirino/incubator-activemq-4.0.2-RC5 Here's the wiki page for the release notes: http://incubator.apache.org/activemq/activemq-402-release.html Please vote to approve this release binary [ ] +1 Release the binary as Apache ActiveMQ 4.0.2 [ ] -1 Veto the release (provide specific comments) This vote is being cross posted to the general incubator mailing list also to expedite the voting process. Here's my +1 -- Regards, Hiram Blog: http://hiramchirino.com -- Cheers, Guillaume Nodet
Re: JSTL 1.2 for JEE 5
Yes, we could look at implementing our own or building on the 1.1 Jakarta impl. I'm a little hesitant to do that given that the Jakarta folks themselves have considered this and apparently decided not to pursue that path. I figure they know more about this than I do. However, using Glassfish may not be that simple either. So far I haven't seen the Glassfish published JSTL in any public repo. I also haven't found a way to download just the JSTL impl from Glassfish apart from downloading the entire image. Still investigating Joe Prasad Kashyap wrote: Here's another option. Depending on how much the spec has changed between 1.1 and 1.2, we could fork jakarta and provide our own implementation. Just a thought. Then again, what are the pros and cons of picking up Glassfish ? Cheers Prasad On 10/19/06, Paul McMahan [EMAIL PROTECTED] wrote: Does anyone know of an alternative to Glassfish's JSTL 1.2? Also, I wonder if Jakarta might consider providing an implementation if we expressed interest in using it in Geronimo? Paul On 10/18/06, Joe Bohn [EMAIL PROTECTED] wrote: 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
[jira] Resolved: (GERONIMO-2504) Allow all read-only operations on KeystoreInstance to be available to services
[ http://issues.apache.org/jira/browse/GERONIMO-2504?page=all ] Guillaume Nodet resolved GERONIMO-2504. --- Resolution: Fixed Allow all read-only operations on KeystoreInstance to be available to services -- Key: GERONIMO-2504 URL: http://issues.apache.org/jira/browse/GERONIMO-2504 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: console, security Reporter: Guillaume Nodet Assigned To: Guillaume Nodet Fix For: 1.2 Attachments: GERONIMO-2504.openejb.patch, GERONIMO-2504.openejb.patch, GERONIMO-2504.patch Currently, the only operations available to services are SSL factory creations. This is quite unsufficient when you need to use WS-Security for example to sign / crypt / encrypt messages. The attached patch has the following modifications: * add several methods to KeystoreInstance * all methods use a keystorePassword parameter used in the following way - write operations on keystore must be given a non-null password - read-only operations may be given a null password, in which case, the internal saved password will be used * all methods throw a KeystoreException existing exceptions have been refactored to inherit this exception * fix several keystore porlets problems: - password is not validated - some actions fail when the keystore is not unlocked for use -- 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: (GERONIMO-911) Admin Console should require SSL
[ http://issues.apache.org/jira/browse/GERONIMO-911?page=comments#action_12443604 ] Guillaume Nodet commented on GERONIMO-911: -- I would be happy to check this patch in (at least an updated one). Any objections ? Admin Console should require SSL Key: GERONIMO-911 URL: http://issues.apache.org/jira/browse/GERONIMO-911 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: console Affects Versions: 1.0-M5 Environment: all Reporter: Donald Woods Assigned To: Donald Woods Priority: Trivial Fix For: 1.x Attachments: Geronimo-911.patch Admin Console login and Portlet access should require SSL to protect the system password and any connector/DB/LDAP configured passwords in the Portlets. I'm willing to create and post a patch for this, once I get a couple other items off my plate... -Donald -- 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: (GERONIMO-911) Admin Console should require SSL
[ http://issues.apache.org/jira/browse/GERONIMO-911?page=comments#action_12443607 ] Guillaume Nodet commented on GERONIMO-911: -- I missed Aaron comment :( and I agree it would not be very user friendly... Is there any way to have certificate for IE, Firefix, Safari, and Opera ? Admin Console should require SSL Key: GERONIMO-911 URL: http://issues.apache.org/jira/browse/GERONIMO-911 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: console Affects Versions: 1.0-M5 Environment: all Reporter: Donald Woods Assigned To: Donald Woods Priority: Trivial Fix For: 1.x Attachments: Geronimo-911.patch Admin Console login and Portlet access should require SSL to protect the system password and any connector/DB/LDAP configured passwords in the Portlets. I'm willing to create and post a patch for this, once I get a couple other items off my plate... -Donald -- 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
Possible bug in Yoko, POA
Rick, Here's the Yoko bug I was talking about. I deployed a simple TSSBean whose POAName attribute is set. It deployed fine. I then undeployed the plan. That was successfull as well. Now when I go back to redeploy the same plan, I get an adapter already exists exception. I have attached both the plan and the log for your scrutiny. Thanx Prasad ?xml version=1.0 encoding=UTF-8? !-- Copyright 2004 The Apache Software Foundation Licensed under the Apache License, Version 2.0 (the License); you may not use this file except in compliance with the License. You may obtain a copy of the License at http://www.apache.org/licenses/LICENSE-2.0 Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an AS IS BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License. -- !-- Configuration for the CORBA server. -- module xmlns=http://geronimo.apache.org/xml/ns/deployment-1.2; environment moduleId groupIdopenejb/groupId artifactIdsecurity/artifactId version2.2-SNAPSHOT/version typecar/type /moduleId dependencies dependency groupIdorg.apache.geronimo.configs/groupId artifactIdsystem-database/artifactId version1.2-SNAPSHOT/version typecar/type /dependency dependency groupIdactiveio/groupId artifactIdactiveio/artifactId version2.0-r118/version /dependency dependency groupIdorg.apache.geronimo.modules/groupId artifactIdgeronimo-security/artifactId version1.2-SNAPSHOT/version /dependency dependency groupIdorg.apache.geronimo.configs/groupId artifactIdj2ee-security/artifactId version1.2-SNAPSHOT/version typecar/type /dependency dependency groupIdorg.apache.geronimo.configs/groupId artifactIdj2ee-corba-yoko/artifactId version1.2-SNAPSHOT/version typecar/type /dependency dependency groupIdorg.apache.openejb/groupId artifactIdopenejb-yoko/artifactId version2.2-incubating-SNAPSHOT/version typejar/type importclasses/import /dependency /dependencies /environment !--gbean gbeanName=geronimo.remoting:target=JaasLoginServiceRemotingServer class=org.apache.geronimo.security.remoting.jmx.JaasLoginServiceRemotingServer attribute name=bindURItcp://0.0.0.0:4242/attribute reference name=LoginServicegbean-namegeronimo.server:J2EEApplication=null,J2EEModule=org/apache/geronimo/Server,J2EEServer=geronimo,j2eeType=GBean,name=JaasLoginService/gbean-name/reference /gbean-- gbean name=public-properties-realm class=org.apache.geronimo.security.realm.GenericSecurityRealm attribute name=realmNamepublic-properties-realm/attribute reference name=ServerInfo nameServerInfo/name /reference reference name=LoginService nameJaasLoginService/name /reference xml-reference name=LoginModuleConfiguration lc:login-config xmlns:lc=http://geronimo.apache.org/xml/ns/loginconfig-1.2; lc:login-module control-flag=REQUIRED server-side=true lc:login-domain-namepublic-login/lc:login-domain-name lc:login-module-classorg.apache.geronimo.security.realm.providers.PropertiesFileLoginModule/lc:login-module-class lc:option name=usersURIvar/security/public_users.properties/lc:option lc:option name=groupsURIvar/security/public_groups.properties/lc:option /lc:login-module /lc:login-config /xml-reference /gbean gbean name=public class=org.apache.geronimo.security.jaas.ServerRealmConfigurationEntry attribute name=applicationConfigNamepublic/attribute attribute name=realmNamepublic-properties-realm/attribute reference name=LoginService nameJaasLoginService/name /reference /gbean !-- secret internal auditing security realm -- !--gbean name=black-login class=org.apache.geronimo.security.jaas.LoginModuleGBean attribute name=loginModuleClassorg.apache.geronimo.security.realm.providers.PropertiesFileLoginModule/attribute attribute name=serverSidetrue/attribute attribute name=options usersURI=var/security/black_users.properties groupsURI=var/security/black_groups.properties /attribute attribute name=loginDomainNameblack-properties-realm/attribute /gbean-- gbean name=black-properties-realm class=org.apache.geronimo.security.realm.GenericSecurityRealm attribute name=realmNameblack-properties-realm/attribute reference name=ServerInfo nameServerInfo/name /reference reference name=LoginService nameJaasLoginService/name /reference xml-reference name=LoginModuleConfiguration
[jira] Commented: (GERONIMO-911) Admin Console should require SSL
[ http://issues.apache.org/jira/browse/GERONIMO-911?page=comments#action_12443609 ] Paul McMahan commented on GERONIMO-911: --- IANASE. But I agree with Aaron's comment that the warning message about self-signed cert would not make a good first impression. The only way that I know of to avoid the message would be for Geronimo to use a certificate that has been signed by a trusted root ca like verisign or thawte.I notice that https://svn.apache.org uses a cert signed by Starfield and that one does not produce a browser warning. I wonder if ASF might be able to provide its projects with certificates signed by a trusted CA? Even if so I am doubtful it would be appropriate to redistribute that cert in a server assembly. Admin Console should require SSL Key: GERONIMO-911 URL: http://issues.apache.org/jira/browse/GERONIMO-911 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: console Affects Versions: 1.0-M5 Environment: all Reporter: Donald Woods Assigned To: Donald Woods Priority: Trivial Fix For: 1.x Attachments: Geronimo-911.patch Admin Console login and Portlet access should require SSL to protect the system password and any connector/DB/LDAP configured passwords in the Portlets. I'm willing to create and post a patch for this, once I get a couple other items off my plate... -Donald -- 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: (GERONIMO-911) Admin Console should require SSL
[ http://issues.apache.org/jira/browse/GERONIMO-911?page=comments#action_12443623 ] Aaron Mulder commented on GERONIMO-911: --- Not only that, but you get a different warning if the host name of the HTTPS server doesn't match the host name of the certificate. Our only option would be to get a certificate for localhost and assume that the user wouldn't put the proper server hostname into the URL (e.g. https://localhost would work but https://my.server.com would not), but I suspect we'd have trouble getting a certificate issued for localhost since it would be so subject to abuse. Bottom line, I don't think we can default to HTTPS. But we can certainly provide a document or wizard to enable HTTPS (where you select a real keystore, enter passwords, etc.) and point you to the HTTPS URL for the console. That would be the better way to go in my opinion. Admin Console should require SSL Key: GERONIMO-911 URL: http://issues.apache.org/jira/browse/GERONIMO-911 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: console Affects Versions: 1.0-M5 Environment: all Reporter: Donald Woods Assigned To: Donald Woods Priority: Trivial Fix For: 1.x Attachments: Geronimo-911.patch Admin Console login and Portlet access should require SSL to protect the system password and any connector/DB/LDAP configured passwords in the Portlets. I'm willing to create and post a patch for this, once I get a couple other items off my plate... -Donald -- 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_12443624 ] Piyush Agarwal commented on DAYTRADER-14: - Matt, thanks for the headsup and valuable insight. So inorder to keep things simple and not have to change the logic inside the KeySequnceBeans and also avoid catching the DuplicateKeyExceptions I propose doing the following -- Drop and Recreate the tables, at end of that the user will get a prominent message to Stop and Restart their application and then use the link to Repopulate the daytrader database. Since the user will be recycling his environment before the repopulation of the tables the SLSBs will get recycled and the DuplicateKeyExceptions will be avoided. Thoughts?? 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
Re: Creating a secure connection system and using JMSXUserID support
Hi Sepand, Do you have any testcases where you atually use the SslBrokerService ?? On 8/30/06, Sepand M [EMAIL PROTECTED] wrote: Hi all, I've seen a similar patch going out so I'm giving an update on this one. Currently, it does the following: - Allows for wantClientAuth and needClientAuth on SslTransport and SslTransportServer classes. - SslTransport attaches the client's certificate chain to ConnectionInfo in the newly added (not by me) connection context field. - Adds ActiveMQSslConnectionFactory and SslBrokerService, which can be used to specify trust and key managers from within code (otherwise, you can use the default ActiveMQConnectionFactory and BrokerService classes and just give an ssl URI) - Adds a new JaasCertificateAuthenticationPlugin and the corresponding broker which allow for authentication based on the certificate - The above use the standard JAAS interface (with some new classes for handling SSL certs) - These classes can be tied into the existing authorization system and UserIDBroker (JaasCertificateAuthenticationBroker will set the securityContext's username to one associated with the certificate based on CertificateLoginModule). It has no problems right now, but I'd rather test it more thoroughly before sending the patch. I should be done within the next 2 weeks. - Sepand On 8/3/06, Sepand M [EMAIL PROTECTED] wrote: Hi, The DN will overwrite the client-provided username (if any) when the SslTransport writes it. On 8/3/06, Kelly Campbell [EMAIL PROTECTED] wrote: Sepand, One possible gotcha I haven't heard anyone bring up that we should address is to make sure that someone can't just fake the DN in the username field through a normal login and make the system think it's authenticated with the certificate. -Kelly On 8/3/06, Hiram Chirino [EMAIL PROTECTED] wrote: Hi Sepand, 4.1 and 4.0 branches are not that different yet. If you need your solution for 4.0, go ahead and do it. Chances are we will only apply it only to 4.1 (since this a new feature). On 8/3/06, Sepand M [EMAIL PROTECTED] wrote: Thanks Hiram. That sounds great. I guess my last question is: what branch do I work off of? Personally, I would like to build my stuff on a stable release (4.0.1), but I've looked at the svn logs and you guys seem to be pretty active around the stuff I want to change so I'm not sure how my changes could be reintegrated once I'm done. Any thoughts? On 8/3/06, Hiram Chirino [EMAIL PROTECTED] wrote: Sepand, Do what you need to to get you project done, you cand send us tidbit as you get it done and we can work on merging it back to the main branch. The great thing is that you have a use case that we want to support, so if you put something together that work for you, I don't see why it would not just go whole hog into the main branch. On 8/3/06, Sepand M [EMAIL PROTECTED] wrote: Hi guys, Here are a few things: 1) I cannot use LDAP. We don't use it now, and don't want to later. I understand if you want to use it, but I can't. 2) From what I understand (and my understanding isn't too bad at this point), SSL sockets with needClientAuth just verify the client's cert against the CA. This means that the socket only does authentication and the rest is up to the broker (which seems perfect). 3) The other ideas we're getting like separating the user from the connection (which I don't fully understand) seem like they are overkill. To be done properly, they would need significant (not drastic, but significant) architectural rework (look at things like UserIDBroker, and how the user ID is currently obtained from the connection with the producer ID registration stuff) and are fairly independent of the SSL thing. Yeah I think this is overkill too. So here's my plan: I want to implement my original idea (it's in this thread a few posts up) with (at most) the addition of a subject/principal back end for authorization. I say at most because I've been working on my idea for a while and know exactly how to do it; adding the subject/principal thing is a good design choice but I'm hesitant to persue it since I don't know much about it and I have a deadline (and therefore, would rather avoid having to read about it). If someone knows their stuff regarding to JAAS and is willing to work on it, I would be very glad to incorporate that into the design. If not, I must begin working on my implementation by the end of the week (hopefully sooner). I would *REALLY* like to work with you guys, but I have deadlines to meet. I would also hate it if my work didn't make it into the project's main branch, but I would totally understand if you decided to go with
[jira] Created: (GERONIMO-2507) Starting the webconsole config is taking *way* too much time
Starting the webconsole config is taking *way* too much time Key: GERONIMO-2507 URL: http://issues.apache.org/jira/browse/GERONIMO-2507 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Affects Versions: 1.2 Reporter: Kevan Miller Priority: Critical Fix For: 1.2 Server startup time of 1.2 has more than doubled. The vast majority of time is being spent starting the webconsole config. -- 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: JSTL 1.2 for JEE 5
On Oct 19, 2006, at 2:21 PM, Joe Bohn wrote: However, using Glassfish may not be that simple either. So far I haven't seen the Glassfish published JSTL in any public repo. I also haven't found a way to download just the JSTL impl from Glassfish apart from downloading the entire image. Joe, Have a look at https://maven-repository.dev.java.net/nonav/repository/ --kevan
deploying apps to a specific port
Hi All, is there a way to deploy a particular application to a specific port without having to define an entirely new virtual host? is it possible to point/bind to a specific (already defined) web connector? Cheers! Hernan
Re: JSTL 1.2 for JEE 5
Ok, I've found jstl on the java.net repo at this location: https://maven-repository.dev.java.net/repository/jstl/ Are there any issues with downloading items from java.net? Unfortunately it's substantially larger that what we had with JSTL 1.1 and it appears that the reason is it includes a whole lot more stuff (strangely most of it under an org\apache\... path). THe other strange thing is that this jstl jar doesn't match the content of the one included with the full Glassfish download (which is a good thing since the jar in the full image only seems to include the extra gorp and not the classes that we need from the spec). Joe Joe Bohn wrote: Yes, we could look at implementing our own or building on the 1.1 Jakarta impl. I'm a little hesitant to do that given that the Jakarta folks themselves have considered this and apparently decided not to pursue that path. I figure they know more about this than I do. However, using Glassfish may not be that simple either. So far I haven't seen the Glassfish published JSTL in any public repo. I also haven't found a way to download just the JSTL impl from Glassfish apart from downloading the entire image. Still investigating Joe Prasad Kashyap wrote: Here's another option. Depending on how much the spec has changed between 1.1 and 1.2, we could fork jakarta and provide our own implementation. Just a thought. Then again, what are the pros and cons of picking up Glassfish ? Cheers Prasad On 10/19/06, Paul McMahan [EMAIL PROTECTED] wrote: Does anyone know of an alternative to Glassfish's JSTL 1.2? Also, I wonder if Jakarta might consider providing an implementation if we expressed interest in using it in Geronimo? Paul On 10/18/06, Joe Bohn [EMAIL PROTECTED] wrote: 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: JSTL 1.2 for JEE 5
Thanks for the info. It looks like we both found the same thing at about the same time :-) Joe Kevan Miller wrote: On Oct 19, 2006, at 2:21 PM, Joe Bohn wrote: However, using Glassfish may not be that simple either. So far I haven't seen the Glassfish published JSTL in any public repo. I also haven't found a way to download just the JSTL impl from Glassfish apart from downloading the entire image. Joe, Have a look at https://maven-repository.dev.java.net/nonav/repository/ --kevan
Re: deploying apps to a specific port
On Oct 19, 2006, at 12:50 PM, Hernan Cunico wrote: Hi All, is there a way to deploy a particular application to a specific port without having to define an entirely new virtual host? AFAICT the only way to get app-per-port binding in either tomcat or jetty is to define an entire web container + connector(s) for each port and deploy each app to connect to the appropriate web container. This mimics the setups I've seen in tomcat server.xml files and IIUC from conversations with gregw is also the correct approach for jetty. So, a new virtual host is not enough or correct. is it possible to point/bind to a specific (already defined) web connector? The web-container element in the geronimo plan lets you specify the web container you want to deploy on. You can't specify a web connector in any way and it doesn't make sense to try to in either the tomcat or jetty architectures. thanks david jencks Cheers! Hernan
Re: deploying apps to a specific port
Thanks for the quick reply David. This is the geronimo-web.xml I tried and it worked but I am also creating a new virtual host. It didn't look right when I first tried it and you just confirmed this is not the right way to do it. However all my attempts to define a new container and connector failed to deploy or to start if I wasn't also defining a whole new virtual host. Any pointer for where cut this plan? Thanks in advance. ?xml version=1.0 encoding=UTF-8? web-app xmlns=http://geronimo.apache.org/xml/ns/j2ee/web-1.1; environment moduleId groupIdsamples.applications/groupId artifactIdHelloWorldApp/artifactId version1.1/version /moduleId /environment context-root/hello1/context-root web-container gbean-linkTomcatWebContainer1/gbean-link /web-container gbean name=TomcatWebConnector1 class=org.apache.geronimo.tomcat.ConnectorGBean attribute name=nameHTTP/attribute attribute name=hostlocalhost/attribute attribute name=port8081/attribute attribute name=maxHttpHeaderSizeBytes8192/attribute attribute name=maxThreads150/attribute attribute name=minSpareThreads25/attribute attribute name=maxSpareThreads75/attribute attribute name=hostLookupEnabledfalse/attribute attribute name=redirectPort8453/attribute attribute name=acceptQueueSize100/attribute attribute name=connectionTimeoutMillis2/attribute attribute name=uploadTimeoutEnabledfalse/attribute reference name=TomcatContainer nameTomcatWebContainer1/name /reference /gbean gbean name=TomcatWebContainer1 class=org.apache.geronimo.tomcat.TomcatContainer attribute name=catalinaHomevar/catalina/attribute reference name=EngineGBean nameTomcatEngine1/name /reference reference name=ServerInfo nameServerInfo/name /reference reference name=WebManager nameTomcatWebManager/name /reference /gbean gbean name=TomcatEngine1 class=org.apache.geronimo.tomcat.EngineGBean attribute name=classNameorg.apache.geronimo.tomcat.TomcatEngine/attribute attribute name=initParams name=Geronimo1 /attribute reference name=DefaultHost nameTomcatHost1/name /reference references name=Hosts pattern nameTomcatHost1/name /pattern /references reference name=RealmGBean nameTomcatJAASRealm/name /reference /gbean gbean name=TomcatHost1 class=org.apache.geronimo.tomcat.HostGBean attribute name=classNameorg.apache.catalina.core.StandardHost/attribute attribute name=initParams name=localhost appBase= workDir=work /attribute /gbean /web-app Cheers! Hernan David Jencks wrote: On Oct 19, 2006, at 12:50 PM, Hernan Cunico wrote: Hi All, is there a way to deploy a particular application to a specific port without having to define an entirely new virtual host? AFAICT the only way to get app-per-port binding in either tomcat or jetty is to define an entire web container + connector(s) for each port and deploy each app to connect to the appropriate web container. This mimics the setups I've seen in tomcat server.xml files and IIUC from conversations with gregw is also the correct approach for jetty. So, a new virtual host is not enough or correct. is it possible to point/bind to a specific (already defined) web connector? The web-container element in the geronimo plan lets you specify the web container you want to deploy on. You can't specify a web connector in any way and it doesn't make sense to try to in either the tomcat or jetty architectures. thanks david jencks Cheers! Hernan
Re: [VOTE] Release Apache ActiveMQ 4.0.2 (RC 5)
+1 -Brian On Oct 19, 2006, at 10:13 AM, Hiram Chirino wrote: Some copyright header/licence/notice issues were found in the 4th release candidate of the 4.0.2 build. I have cut and RC 5 of the 4.0.2 build with the fixes and it's available here: http://people.apache.org/~chirino/incubator-activemq-4.0.2-RC5/ maven1/incubator-activemq/distributions/ Maven 1 and Maven 2 repos for this release can be found at: http://people.apache.org/~chirino/incubator-activemq-4.0.2-RC5 Here's the wiki page for the release notes: http://incubator.apache.org/activemq/activemq-402-release.html Please vote to approve this release binary [ ] +1 Release the binary as Apache ActiveMQ 4.0.2 [ ] -1 Veto the release (provide specific comments) This vote is being cross posted to the general incubator mailing list also to expedite the voting process. Here's my +1 -- Regards, Hiram Blog: http://hiramchirino.com
[jira] Created: (GERONIMO-2508) An empty enterprise naming context does not cotain a context at java:comp/env
An empty enterprise naming context does not cotain a context at java:comp/env - Key: GERONIMO-2508 URL: http://issues.apache.org/jira/browse/GERONIMO-2508 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Components: naming Reporter: Dain Sundstrom Assigned To: Dain Sundstrom Priority: Blocker For a component without any defined enc values, the following code will throw an exception: new InitialContext().lookup(java:comp/env); -- 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: [jira] Commented: (GERONIMO-911) Admin Console should require SSL
Can the console not use a different port/container from the base settings? Similar to the approach done in WebSphere. This would signifcantly reduce the exposure and would not require to default to HTTPS without proper infrastructure. Heinz On 10/19/06, Aaron Mulder (JIRA) dev@geronimo.apache.org wrote: [ http://issues.apache.org/jira/browse/GERONIMO-911?page=comments#action_12443623 ] Aaron Mulder commented on GERONIMO-911: --- Not only that, but you get a different warning if the host name of the HTTPS server doesn't match the host name of the certificate. Our only option would be to get a certificate for localhost and assume that the user wouldn't put the proper server hostname into the URL (e.g. https://localhost would work but https://my.server.com would not), but I suspect we'd have trouble getting a certificate issued for localhost since it would be so subject to abuse. Bottom line, I don't think we can default to HTTPS. But we can certainly provide a document or wizard to enable HTTPS (where you select a real keystore, enter passwords, etc.) and point you to the HTTPS URL for the console. That would be the better way to go in my opinion. Admin Console should require SSL Key: GERONIMO-911 URL: http://issues.apache.org/jira/browse/GERONIMO-911 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: console Affects Versions: 1.0-M5 Environment: all Reporter: Donald Woods Assigned To: Donald Woods Priority: Trivial Fix For: 1.x Attachments: Geronimo-911.patch Admin Console login and Portlet access should require SSL to protect the system password and any connector/DB/LDAP configured passwords in the Portlets. I'm willing to create and post a patch for this, once I get a couple other items off my plate... -Donald -- 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
Assembly is caching old junk
The tck is moving very slow because when I make a simple change to a jar the final assembly is getting the old code. For example, I do the following: * changing some code (In my case naming) * run mvn install from the geronimo/server/trunk At this point if I unpack an assembly and debug, it I get the old code. The only way I have found around this is to run a clean build (and a clean build again in the tck), which means the turn around time to test a single fix to a tck bug is about 30 minutes. Can someone please fix this? -dain
[jira] Closed: (GERONIMO-2508) An empty enterprise naming context does not cotain a context at java:comp/env
[ http://issues.apache.org/jira/browse/GERONIMO-2508?page=all ] Dain Sundstrom closed GERONIMO-2508. Resolution: Fixed ENC now adds an empty env context if not env bindings are present in the context map. An empty enterprise naming context does not cotain a context at java:comp/env - Key: GERONIMO-2508 URL: http://issues.apache.org/jira/browse/GERONIMO-2508 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: naming Reporter: Dain Sundstrom Assigned To: Dain Sundstrom Priority: Blocker For a component without any defined enc values, the following code will throw an exception: new InitialContext().lookup(java:comp/env); -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (GERONIMO-2509) Appclient missing activeio from the class path
Appclient missing activeio from the class path -- Key: GERONIMO-2509 URL: http://issues.apache.org/jira/browse/GERONIMO-2509 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Components: application client Reporter: Dain Sundstrom Assigned To: Dain Sundstrom JaasLoginServiceRemotingClient uses some code from ActiveIO but the activeio jar in on in the application client. -- 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: Assembly is caching old junk
It might help anyone trying to fix this if you can determine what is out of date in the assembly. For instance, -- assembly might pick up timestamped jars instead of locally build - SNAPSHOT jars -- assembly might include old copies of jars As workarounds for the first you can build offline after removing all g. timestamped jars from your m2 repo for the second perhaps running mvn -o clean install in assembly would help. Pesonally I try to only rebuild stuff that I've changed or depends on stuff I've changed thanks david jencks On Oct 19, 2006, at 3:40 PM, Dain Sundstrom wrote: The tck is moving very slow because when I make a simple change to a jar the final assembly is getting the old code. For example, I do the following: * changing some code (In my case naming) * run mvn install from the geronimo/server/trunk At this point if I unpack an assembly and debug, it I get the old code. The only way I have found around this is to run a clean build (and a clean build again in the tck), which means the turn around time to test a single fix to a tck bug is about 30 minutes. Can someone please fix this? -dain
Re: Assembly is caching old junk
I don't understand how any of this stuff works. All I know is when I run mvn install I don't get my source changes. It would be nice to have a single command that does something reasonable. -dain On Oct 19, 2006, at 4:17 PM, David Jencks wrote: It might help anyone trying to fix this if you can determine what is out of date in the assembly. For instance, -- assembly might pick up timestamped jars instead of locally build -SNAPSHOT jars -- assembly might include old copies of jars As workarounds for the first you can build offline after removing all g. timestamped jars from your m2 repo for the second perhaps running mvn -o clean install in assembly would help. Pesonally I try to only rebuild stuff that I've changed or depends on stuff I've changed thanks david jencks On Oct 19, 2006, at 3:40 PM, Dain Sundstrom wrote: The tck is moving very slow because when I make a simple change to a jar the final assembly is getting the old code. For example, I do the following: * changing some code (In my case naming) * run mvn install from the geronimo/server/trunk At this point if I unpack an assembly and debug, it I get the old code. The only way I have found around this is to run a clean build (and a clean build again in the tck), which means the turn around time to test a single fix to a tck bug is about 30 minutes. Can someone please fix this? -dain
[jira] Closed: (GERONIMO-2509) Appclient missing activeio from the class path
[ http://issues.apache.org/jira/browse/GERONIMO-2509?page=all ] Dain Sundstrom closed GERONIMO-2509. Resolution: Fixed Added dependency on activeio and geronimo-interceptor to the client plan. Appclient missing activeio from the class path -- Key: GERONIMO-2509 URL: http://issues.apache.org/jira/browse/GERONIMO-2509 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: application client Reporter: Dain Sundstrom Assigned To: Dain Sundstrom JaasLoginServiceRemotingClient uses some code from ActiveIO but the activeio jar in on in the application client. -- 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: Assembly is caching old junk
This should do something reasonble: mvn clean install At the cost of taking longer... :-( --jason On Oct 19, 2006, at 4:34 PM, Dain Sundstrom wrote: I don't understand how any of this stuff works. All I know is when I run mvn install I don't get my source changes. It would be nice to have a single command that does something reasonable. -dain On Oct 19, 2006, at 4:17 PM, David Jencks wrote: It might help anyone trying to fix this if you can determine what is out of date in the assembly. For instance, -- assembly might pick up timestamped jars instead of locally build -SNAPSHOT jars -- assembly might include old copies of jars As workarounds for the first you can build offline after removing all g. timestamped jars from your m2 repo for the second perhaps running mvn -o clean install in assembly would help. Pesonally I try to only rebuild stuff that I've changed or depends on stuff I've changed thanks david jencks On Oct 19, 2006, at 3:40 PM, Dain Sundstrom wrote: The tck is moving very slow because when I make a simple change to a jar the final assembly is getting the old code. For example, I do the following: * changing some code (In my case naming) * run mvn install from the geronimo/server/trunk At this point if I unpack an assembly and debug, it I get the old code. The only way I have found around this is to run a clean build (and a clean build again in the tck), which means the turn around time to test a single fix to a tck bug is about 30 minutes. Can someone please fix this? -dain
Re: [ANNOUNCE] Please welcome Christopher M. Cardona as our newest Committer
Congrats Chris. --- 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! __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
[jira] Created: (GERONIMO-2510) CORBA/RMI delegate code requires delegate implementation to be on the system classpath
CORBA/RMI delegate code requires delegate implementation to be on the system
classpath
--
Key: GERONIMO-2510
URL: http://issues.apache.org/jira/browse/GERONIMO-2510
Project: Geronimo
Issue Type: Bug
Security Level: public (Regular issues)
Components: CORBA
Reporter: Dain Sundstrom
When the java.rmi.Util class is loaded, it uses Class.forName to load the
UtilDelegate specified in a system property. This is what yoko uses:
private static UtilDelegate delegate = null;
private static final String defaultDelegate =
org.apache.yoko.rmi.impl.UtilImpl;
static {
// Initialize delegate
String delegateName = System.getProperty(javax.rmi.CORBA.UtilClass,
defaultDelegate);
try {
delegate = (UtilDelegate)Class.forName(delegateName).newInstance();
} catch (Exception e) {
throw new RuntimeException(Can not create Util delegate:
+delegateName, e);
}
}
IIRC Class.forName(String) uses the class loader of the class containing the
code, and since java.rmi.Util will always be on the system class path our
delegate must be on the system class path :(
I see a few choices:
* change yoko to use the thread context class loader... then add a gbean to set
the property and load the Util class. repeat of every delegate class.
* write a delegate delegate that allows us to swap out the actual delegate
implementation later
* split out out delegate class into a jar we can put on the system class path
--
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: (GERONIMO-2510) CORBA/RMI delegate code requires delegate implementation to be on the system classpath
[
http://issues.apache.org/jira/browse/GERONIMO-2510?page=comments#action_12443676
]
David Jencks commented on GERONIMO-2510:
I'm not convinced your analysis is correct since I believe this worked before I
moved the openejb corba classes into a separate jar. I'll look into it further.
CORBA/RMI delegate code requires delegate implementation to be on the system
classpath
--
Key: GERONIMO-2510
URL: http://issues.apache.org/jira/browse/GERONIMO-2510
Project: Geronimo
Issue Type: Bug
Security Level: public(Regular issues)
Components: CORBA
Reporter: Dain Sundstrom
When the java.rmi.Util class is loaded, it uses Class.forName to load the
UtilDelegate specified in a system property. This is what yoko uses:
private static UtilDelegate delegate = null;
private static final String defaultDelegate =
org.apache.yoko.rmi.impl.UtilImpl;
static {
// Initialize delegate
String delegateName = System.getProperty(javax.rmi.CORBA.UtilClass,
defaultDelegate);
try {
delegate =
(UtilDelegate)Class.forName(delegateName).newInstance();
} catch (Exception e) {
throw new RuntimeException(Can not create Util delegate:
+delegateName, e);
}
}
IIRC Class.forName(String) uses the class loader of the class containing the
code, and since java.rmi.Util will always be on the system class path our
delegate must be on the system class path :(
I see a few choices:
* change yoko to use the thread context class loader... then add a gbean to
set the property and load the Util class. repeat of every delegate class.
* write a delegate delegate that allows us to swap out the actual delegate
implementation later
* split out out delegate class into a jar we can put on the system class path
--
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: Assembly is caching old junk
The problem is really in the configs build... and is compounded by the assembly build, especially for the bits which are picked up from a boilerplate. --jason On Oct 19, 2006, at 4:17 PM, David Jencks wrote: It might help anyone trying to fix this if you can determine what is out of date in the assembly. For instance, -- assembly might pick up timestamped jars instead of locally build -SNAPSHOT jars -- assembly might include old copies of jars As workarounds for the first you can build offline after removing all g. timestamped jars from your m2 repo for the second perhaps running mvn -o clean install in assembly would help. Pesonally I try to only rebuild stuff that I've changed or depends on stuff I've changed thanks david jencks On Oct 19, 2006, at 3:40 PM, Dain Sundstrom wrote: The tck is moving very slow because when I make a simple change to a jar the final assembly is getting the old code. For example, I do the following: * changing some code (In my case naming) * run mvn install from the geronimo/server/trunk At this point if I unpack an assembly and debug, it I get the old code. The only way I have found around this is to run a clean build (and a clean build again in the tck), which means the turn around time to test a single fix to a tck bug is about 30 minutes. Can someone please fix this? -dain
[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_12443686 ] Matt Hogstrom commented on DAYTRADER-14: I'm open to other ideas but I think that is clear and makes life the easiest. 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
Re: Download page incorrectly lists OS X and Unix as being compatible
Geir, Can you enumerate the specific requirements for certification? You have a valid point about OS X but if we certified on SuSE 9.3 is it not still certified release on SuSE 10? Or even jumping from SuSE to Red Hat or even Solaris x86 or SPARC. I'm curious about how the certification treats all these possible permutations (yikes ;-0 ) Would it be acceptable to say something like: J2EE certified Release (with some link to a page that describes the exact certification environment) and lists *nix as a general platform? I guess I'm really curious about what certified means based on your comment below. On Oct 18, 2006, at 5:29 PM, Geir Magnusson Jr. wrote: They aren't tested. Can we put a separate section (or a separate page) for the non- certified downloads? geir Matt Hogstrom [EMAIL PROTECTED]
Re: Download page incorrectly lists OS X and Unix as being compatible
IMO it is really lame to need to certify a Java product on a billion different operating systems... Isn't Sun's Java motto still write once run everywhere? Or does that not apply to certification of j2ee platforms? Write once certify everywhere?! --jason On Oct 19, 2006, at 9:08 PM, Matt Hogstrom wrote: Geir, Can you enumerate the specific requirements for certification? You have a valid point about OS X but if we certified on SuSE 9.3 is it not still certified release on SuSE 10? Or even jumping from SuSE to Red Hat or even Solaris x86 or SPARC. I'm curious about how the certification treats all these possible permutations (yikes ;-0 ) Would it be acceptable to say something like: J2EE certified Release (with some link to a page that describes the exact certification environment) and lists *nix as a general platform? I guess I'm really curious about what certified means based on your comment below. On Oct 18, 2006, at 5:29 PM, Geir Magnusson Jr. wrote: They aren't tested. Can we put a separate section (or a separate page) for the non- certified downloads? geir Matt Hogstrom [EMAIL PROTECTED]
