Problem in openwire-cpp API for messages
Hi, I am working on openwire-cpp ( for ActiveMQ-4.0) code on SuSe(Linux machine-i686-suse-linux, version 2.6.13-15.8-default), I am not able to ceate a message which have more than 252 char by using message = session-createTextMessage(Message,moreThan252Char); API how I will achieve it, because I want to send the data more than 252 char. is there any other procesure to create a message? Pls assist me Thanks in advance Regards Arashad Ahamad
Re: Problem in openwire-cpp API for messages
Hi, code for create the text message pIQueue queue, queue1 ; pITextMessage message; char Replay[300] // contains more then 252 char queue = session-getQueue(FOO.BAR) ; producer = session-createProducer(queue) ; consumer = session-createConsumer(queue) ; consumer-setMessageListener( smartify(this) ) ; message = session-createTextMessage(Replay); producer-send(message) ; I am working on openwire-cpp ( for ActiveMQ-4.0) code on SuSe(Linux machine-i686-suse-linux, version 2.6.13-15.8-default), I am not able to ceate a message which have more than 252 char by using message = session-createTextMessage(Message,moreThan252Char); API how I will achieve it, because I want to send the data more than 252 char. is there any other procesure to create a message? Pls assist me Thanks in advance Regards Arashad Ahamad
RE: Problem in openwire-cpp API for messages
Are you talking about the initial size value? If so I submitted a patch yesterday that fixed the ByteArrayOutputStream's code that expands the buffer, so if you grab the latest code from SVN you shouldn't need to change the initial size value as the output stream should grow correctly now. If you can try that and let me know if it still has issues that would be helpful. - Timothy A. Bish Sensis Corporation 5717 Enterprise Parkway East Syracuse, NY 13057 Phone: (315) 634-3027 [EMAIL PROTECTED] - -Original Message- From: Arshad Ahamad [mailto:[EMAIL PROTECTED] Sent: Wednesday, July 26, 2006 8:23 AM To: [EMAIL PROTECTED]; activemq-dev@geronimo.apache.org Subject: Re: Problem in openwire-cpp API for messages Hi, I have solve this problem, I change the size of the variable in the following files ./main/cpp/ppr/io/ByteArrayOutputStream.hpp ./main/cpp/activemq/command/ActiveMQBytesMessage.hpp Hi, code for create the text message pIQueue queue, queue1 ; pITextMessage message; char Replay[300] // contains more then 252 char queue = session-getQueue(FOO.BAR) ; producer = session-createProducer(queue) ; consumer = session-createConsumer(queue) ; consumer-setMessageListener( smartify(this) ) ; message = session-createTextMessage(Replay); producer-send(message) ; I am working on openwire-cpp ( for ActiveMQ-4.0) code on SuSe(Linux machine-i686-suse-linux, version 2.6.13-15.8-default), I am not able to ceate a message which have more than 252 char by using message = session-createTextMessage(Message,moreThan252Char); API how I will achieve it, because I want to send the data more than 252 char. is there any other procesure to create a message? Pls assist me Thanks in advance Regards Arashad Ahamad
Re: [VOTE] Release Apache ActiveMQ 4.0.2
+1 Regards, Jonas - Original Message - From: Hiram Chirino [EMAIL PROTECTED] To: activemq-dev@geronimo.apache.org Sent: Wednesday, July 26, 2006 1:26 PM Subject: [VOTE] Release Apache ActiveMQ 4.0.2 Since it was brought up, and folks concurred that it's about time to put out a bug fix release for ActiveMQ, I've put together a binary release of ActiveMQ 4.0.2: http://people.apache.org/~chirino/incubator-activemq-4.0.2-RC1/maven1/incubator-activemq/distributions/ http://people.apache.org/%7Echirino/incubator-activemq-4.0.1-RC1/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-RC1 http://people.apache.org/%7Echirino/incubator-activemq-4.0.1-RC1/ Here's the wiki page for the release notes (they should soon get mirrored to the activemq static website) : http://goopen.org/confluence/display/ACTIVEMQ/ActiveMQ+4.0.2+Release http://goopen.org/confluence/display/ACTIVEMQ/ActiveMQ+4.0.1+Release Please vote to approve this release binary [ ] +1 Release the binary as Apache ActiveMQ 4.0.2 [ ] -1 Veto the release (provide specific comments) If this vote passes, then we will then ask the Incubator PMC for their blessing to ship this release officially. Here's my +1 -- Regards, Hiram Blog: http://hiramchirino.com
Streamlining the ActiveMQ release process
Hi, I just recently put up a ActiveMQ 4.0.2 release candidate for vote so while it's fresh on my mind I'd like to see if anybody minds if I make a small tweak to the way we label our snapshot versions. I'd like to either change it to 4.0-SNAPSHOT or even 4.0.x-SNAPSHOT. The driver behind this change is that on the 4.0 branch, every time we do a release (for example this 4.0.2 release), we have to remember to increment the version on the branch on all the poms. It's easy to forget to change this and I don't see much value in changing the pom after every release. -- Regards, Hiram Blog: http://hiramchirino.com
Re: svn commit: r425429 - /geronimo/branches/1.1/modules/system/src/java/org/apache/geronimo/system/configuration/GBeanOverride.java
Aaron,
What JIRA is associated with this change?
Thanks,
John
[EMAIL PROTECTED] wrote:
Author: ammulder
Date: Tue Jul 25 08:55:34 2006
New Revision: 425429
URL: http://svn.apache.org/viewvc?rev=425429view=rev
Log:
Module and name are independent of artifact
Modified:
geronimo/branches/1.1/modules/system/src/java/org/apache/geronimo/system/configuration/GBeanOverride.java
Modified:
geronimo/branches/1.1/modules/system/src/java/org/apache/geronimo/system/configuration/GBeanOverride.java
URL:
http://svn.apache.org/viewvc/geronimo/branches/1.1/modules/system/src/java/org/apache/geronimo/system/configuration/GBeanOverride.java?rev=425429r1=425428r2=425429view=diff
==
---
geronimo/branches/1.1/modules/system/src/java/org/apache/geronimo/system/configuration/GBeanOverride.java
(original)
+++
geronimo/branches/1.1/modules/system/src/java/org/apache/geronimo/system/configuration/GBeanOverride.java
Tue Jul 25 08:55:34 2006
@@ -459,17 +459,17 @@
type.appendChild(doc.createTextNode(artifact.getType()));
pat.appendChild(type);
}
-Map nameMap = pattern.getName();
-if (nameMap.get(module) != null) {
-Element module = doc.createElement(module);
-
module.appendChild(doc.createTextNode(nameMap.get(module).toString()));
-pat.appendChild(module);
-}
-if (nameMap.get(name) != null) {
-Element patName = doc.createElement(name);
-
patName.appendChild(doc.createTextNode(nameMap.get(name).toString()));
-pat.appendChild(patName);
-}
+}
+Map nameMap = pattern.getName();
+if (nameMap.get(module) != null) {
+Element module = doc.createElement(module);
+
module.appendChild(doc.createTextNode(nameMap.get(module).toString()));
+pat.appendChild(module);
+}
+if (nameMap.get(name) != null) {
+Element patName = doc.createElement(name);
+
patName.appendChild(doc.createTextNode(nameMap.get(name).toString()));
+pat.appendChild(patName);
}
//out.print(pattern.toString());
}
[jira] Created: (GERONIMO-2228) GeronimoAsMavenServlet.java generates wrong default-repository element
GeronimoAsMavenServlet.java generates wrong default-repository element -- Key: GERONIMO-2228 URL: http://issues.apache.org/jira/browse/GERONIMO-2228 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Components: Plugins Affects Versions: 1.1, 1.1.1, 1.2 Reporter: Kristian Koehler The GeronimoAsMavenServlet generates a XML document which contains an element called 'default-repository' (see http://localhost:8080/console-standard/maven-repo/geronimo-plugins.xml). The value of this element looks like: --- 8 --- ... default-repository HTTP/1.1://localhost:8081/console-standard/maven-repo/ /default-repository --- 8 --- With this issue it isn't possible to import a plugin from a Geronimo Server running somewhere. This should be: --- 8 --- ... default-repository http://localhost:8081/console-standard/maven-repo/ /default-repository --- 8 --- The attached patch resolves this issue. Kristian -- 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-2228) GeronimoAsMavenServlet.java generates wrong default-repository element
[ http://issues.apache.org/jira/browse/GERONIMO-2228?page=all ] Kristian Koehler updated GERONIMO-2228: --- Attachment: diff.patch the patch GeronimoAsMavenServlet.java generates wrong default-repository element -- Key: GERONIMO-2228 URL: http://issues.apache.org/jira/browse/GERONIMO-2228 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: Plugins Affects Versions: 1.2, 1.1, 1.1.1 Reporter: Kristian Koehler Attachments: diff.patch The GeronimoAsMavenServlet generates a XML document which contains an element called 'default-repository' (see http://localhost:8080/console-standard/maven-repo/geronimo-plugins.xml). The value of this element looks like: --- 8 --- ... default-repository HTTP/1.1://localhost:8081/console-standard/maven-repo/ /default-repository --- 8 --- With this issue it isn't possible to import a plugin from a Geronimo Server running somewhere. This should be: --- 8 --- ... default-repository http://localhost:8081/console-standard/maven-repo/ /default-repository --- 8 --- The attached patch resolves this issue. Kristian -- 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: o.a.g.connector.outbound.connectionmanagerconfig.XATransactions?
I put what I know about these at http://chariotsolutions.com/geronimo/connector-plan.html in section 13.3.2.2.1. I think thread caching is not a suitable default. Thanks, Aaron On 7/26/06, Dain Sundstrom [EMAIL PROTECTED] wrote: I'm working on some code in the Jencks project that uses the XATransactions class. From what I have gathered, this an instance of this class or the NoTransaction or LocalTransaction class is passed the the GenericConnectionManager, and it specifies the relationship between the connector and transactions. This all part sense to me. The part I find confusing are the two properties on the XATransaction class: useTransactionCaching and useThreadCaching. What do these settings do/ mean? Is having them both true or both false a valid setting? What should the default values be? For this I'm thinking of turning on transactionCaching when we have a connection tracker and thread tracking when we are running in an environment that doesn't. TIA, -dain
RE: Problem in openwire-cpp API for messages
Ok, I will take a look and get back to you as soon as I can. - Timothy A. Bish Sensis Corporation - -Original Message- From: Arshad Ahamad [mailto:[EMAIL PROTECTED] Sent: Wednesday, July 26, 2006 7:56 AM To: [EMAIL PROTECTED]; activemq-dev@geronimo.apache.org Subject: Re: Problem in openwire-cpp API for messages Hi, code for create the text message pIQueue queue, queue1 ; pITextMessage message; char Replay[300] // contains more then 252 char queue = session-getQueue(FOO.BAR) ; producer = session-createProducer(queue) ; consumer = session-createConsumer(queue) ; consumer-setMessageListener( smartify(this) ) ; message = session-createTextMessage(Replay); producer-send(message) ; I am working on openwire-cpp ( for ActiveMQ-4.0) code on SuSe(Linux machine-i686-suse-linux, version 2.6.13-15.8-default), I am not able to ceate a message which have more than 252 char by using message = session-createTextMessage(Message,moreThan252Char); API how I will achieve it, because I want to send the data more than 252 char. is there any other procesure to create a message? Pls assist me Thanks in advance Regards Arashad Ahamad
Re: How to use M2 G Packaging Plugin
--- Jason Dillon [EMAIL PROTECTED] wrote: FYI, newer car plugin side is up: http://geronimo.apache.org/maven/plugins/car-maven-plugin Though due to non-xhtml javadocs in PackageMojo the config page for that mojo is broken. I've fixed it but need to wait again for the site to sync. --jason Great work!! Thanks! The installMojo is not used anywhere. It can be removed. Thanks Anita __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: Problem in openwire-cpp API for messages
Hi, I have solve this problem, I change the size of the variable in the following files ./main/cpp/ppr/io/ByteArrayOutputStream.hpp ./main/cpp/activemq/command/ActiveMQBytesMessage.hpp Hi, code for create the text message pIQueue queue, queue1 ; pITextMessage message; char Replay[300] // contains more then 252 char queue = session-getQueue(FOO.BAR) ; producer = session-createProducer(queue) ; consumer = session-createConsumer(queue) ; consumer-setMessageListener( smartify(this) ) ; message = session-createTextMessage(Replay); producer-send(message) ; I am working on openwire-cpp ( for ActiveMQ-4.0) code on SuSe(Linux machine-i686-suse-linux, version 2.6.13-15.8-default), I am not able to ceate a message which have more than 252 char by using message = session-createTextMessage(Message,moreThan252Char); API how I will achieve it, because I want to send the data more than 252 char. is there any other procesure to create a message? Pls assist me Thanks in advance Regards Arashad Ahamad
[jira] Updated: (GERONIMO-2067) Configs migration to M2
[ http://issues.apache.org/jira/browse/GERONIMO-2067?page=all ] Anita Kulshreshtha updated GERONIMO-2067: - Attachment: m2-plugins.patch This patch is for the M2migration branch. This implements geronimoPlugin for applications and multiple artifact handling for daytrader. Configs migration to M2 --- Key: GERONIMO-2067 URL: http://issues.apache.org/jira/browse/GERONIMO-2067 Project: Geronimo Issue Type: Sub-task Security Level: public(Regular issues) Components: buildsystem Affects Versions: 1.2 Environment: All Reporter: Anita Kulshreshtha Assigned To: Anita Kulshreshtha Fix For: 1.2 Attachments: applications.patch, applications.patch, configs.log, configs.log, configs.log, configs.log, configs.patch, configs.patch, configs.patch, configs.patch, configs.patch, configs.patch, configs.patch, configs.patch, console-configs.patch, etc.patch, m2-plugins.patch, m2-plugins.patch, m2-plugins.patch, modules.patch, modules.patch, modules.patch, newconfigs.patch, pom.patch, pom.patch, pom.patch To build these configurations use packaging plugin GERONIMO-1740. This patch builds non openejb and non jetty configurations. This patch is for the new trunk, and has been edited using emcas to rempve ^M. -- 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-1959) Console: plugin % complete shoudl reset to 0 while preparing a download
[ http://issues.apache.org/jira/browse/GERONIMO-1959?page=all ] Sachin Patel reassigned GERONIMO-1959: -- Assignee: Sachin Patel Console: plugin % complete shoudl reset to 0 while preparing a download --- Key: GERONIMO-1959 URL: http://issues.apache.org/jira/browse/GERONIMO-1959 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: console Affects Versions: 1.1 Reporter: Aaron Mulder Assigned To: Sachin Patel Priority: Minor Fix For: 1.1.1 Attachments: GERONIMO-1959.patch The console progress bar should go back to 0 if the percent complete is set to -1 (which should handle resetting it to 0 during the preparing to download phase, whereas now it stays at whatever value it had for the last status message) -- 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-2067) Configs migration to M2
[ http://issues.apache.org/jira/browse/GERONIMO-2067?page=all ] Anita Kulshreshtha updated GERONIMO-2067: - Attachment: m2-plugins.patch The earlier patch does not look right. Use the latest m2-plugins.patch Configs migration to M2 --- Key: GERONIMO-2067 URL: http://issues.apache.org/jira/browse/GERONIMO-2067 Project: Geronimo Issue Type: Sub-task Security Level: public(Regular issues) Components: buildsystem Affects Versions: 1.2 Environment: All Reporter: Anita Kulshreshtha Assigned To: Anita Kulshreshtha Fix For: 1.2 Attachments: applications.patch, applications.patch, configs.log, configs.log, configs.log, configs.log, configs.patch, configs.patch, configs.patch, configs.patch, configs.patch, configs.patch, configs.patch, configs.patch, console-configs.patch, etc.patch, m2-plugins.patch, m2-plugins.patch, m2-plugins.patch, m2-plugins.patch, modules.patch, modules.patch, modules.patch, newconfigs.patch, pom.patch, pom.patch, pom.patch To build these configurations use packaging plugin GERONIMO-1740. This patch builds non openejb and non jetty configurations. This patch is for the new trunk, and has been edited using emcas to rempve ^M. -- 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
1.1 keystore portlet bugs patches
I was looking to see what else we need to get fixed in 1.1.1 and noticed that there are several issues (in both 1.1 and 1.1.1) around the keystore portlet. I know nothing about the keystore portlet and thought I'd check here (esp. with Aaron) before I started looking into the patches that Vamsi has provided. It appears that this is a real problem spot (esp. given my initial experiment ... see below), so I'm hoping that the patch from Vamsi works wonders :-) . It seems like there are a number of issues (1196, 1531, 1984, and 2218) which have all been grouped with one fix under 2218. Some of these sound like enhancements to me but since they appear to be addressing function that was previously available in 1.0 but dropped from the updated keystore portlet I assume they could be considered bug fixes. Comments? While just trying to get familiar with the keystore portlet as it currently stands (w/o the 2218 patch) I managed to get serialization errors that then reappeared each time I attempted to stop the server (even with no additional changes). I also managed to get the jetty server into a state where it could not start with just two clicks of the mouse from the portlet (one on the unlocked icon under Available for the geronimo-default keystore and then a second click on then locked icon attempting to undo what I did with the first click). The result was the following set of stack traces on server restart (kinda funny how it wants me to unlock the keystore using the console when the server itself won't even start). Joe Booting Geronimo Kernel (in Java 1.4.2_08)... Starting Geronimo Application Server v1.1.1-SNAPSHOT [*] 43% 8s Starting geronimo/jetty/1.1.1-SNA...10:27:12,640 WARN [SslListener] EXCEPTION org.apache.geronimo.management.geronimo.KeystoreIsLocked: Keystore 'geronimo-default' is locked; please use the keystore page in the admin console to unlock it at org.apache.geronimo.security.keystore.FileKeystoreManager.createSSLServerFactory(FileKeystoreManager.java:300) at org.apache.geronimo.security.keystore.FileKeystoreManager$$FastClassByCGLIB$$4d9d2a71.invoke(generated) at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53) at org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38) at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:122) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:817) at org.apache.geronimo.gbean.runtime.RawInvoker.invoke(RawInvoker.java:57) at org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke(RawOperationInvoker.java:35) at org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept(ProxyMethodInterceptor.java:96) at org.apache.geronimo.management.geronimo.KeystoreManager$$EnhancerByCGLIB$$be50f1ec.createSSLServerFactory(generated) at org.apache.geronimo.jetty.connector.GeronimoSSLListener.createFactory(GeronimoSSLListener.java:41) at org.mortbay.http.SslListener.newServerSocket(SslListener.java:283) at org.mortbay.util.ThreadedServer.open(ThreadedServer.java:477) at org.apache.geronimo.jetty.connector.JettyConnector.doStart(JettyConnector.java:233) at org.apache.geronimo.gbean.runtime.GBeanInstance.createInstance(GBeanInstance.java:981) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStart(GBeanInstanceState.java:267) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.start(GBeanInstanceState.java:102) at org.apache.geronimo.gbean.runtime.GBeanInstance.start(GBeanInstance.java:526) at org.apache.geronimo.gbean.runtime.GBeanDependency.attemptFullStart(GBeanDependency.java:111) at org.apache.geronimo.gbean.runtime.GBeanDependency.addTarget(GBeanDependency.java:146) at org.apache.geronimo.gbean.runtime.GBeanDependency$1.running(GBeanDependency.java:120) at org.apache.geronimo.kernel.basic.BasicLifecycleMonitor.fireRunningEvent(BasicLifecycleMonitor.java:173) at org.apache.geronimo.kernel.basic.BasicLifecycleMonitor.access$300(BasicLifecycleMonitor.java:41) at org.apache.geronimo.kernel.basic.BasicLifecycleMonitor$RawLifecycleBroadcaster.fireRunningEvent(BasicLifecycleMonitor.java:251) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStart(GBeanInstanceState.java:292) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.start(GBeanInstanceState.java:102) at org.apache.geronimo.gbean.runtime.GBeanInstance.start(GBeanInstance.java:526) at org.apache.geronimo.gbean.runtime.GBeanDependency.attemptFullStart(GBeanDependency.java:111) at org.apache.geronimo.gbean.runtime.GBeanDependency.addTarget(GBeanDependency.java:146) at org.apache.geronimo.gbean.runtime.GBeanDependency$1.running(GBeanDependency.java:120)
[jira] Closed: (GERONIMO-1959) Console: plugin % complete shoudl reset to 0 while preparing a download
[ http://issues.apache.org/jira/browse/GERONIMO-1959?page=all ] Sachin Patel closed GERONIMO-1959. -- Resolution: Fixed p applied Console: plugin % complete shoudl reset to 0 while preparing a download --- Key: GERONIMO-1959 URL: http://issues.apache.org/jira/browse/GERONIMO-1959 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: console Affects Versions: 1.1 Reporter: Aaron Mulder Assigned To: Sachin Patel Priority: Minor Fix For: 1.1.1 Attachments: GERONIMO-1959.patch The console progress bar should go back to 0 if the percent complete is set to -1 (which should handle resetting it to 0 during the preparing to download phase, whereas now it stays at whatever value it had for the last status message) -- 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: 1.1 keystore portlet bugs patches
On 7/26/06, Joe Bohn [EMAIL PROTECTED] wrote: I was looking to see what else we need to get fixed in 1.1.1 and noticed that there are several issues (in both 1.1 and 1.1.1) around the keystore portlet. I know nothing about the keystore portlet and thought I'd check here (esp. with Aaron) before I started looking into the patches that Vamsi has provided. It appears that this is a real problem spot (esp. given my initial experiment ... see below), so I'm hoping that the patch from Vamsi works wonders :-) . It seems like there are a number of issues (1196, 1531, 1984, and 2218) which have all been grouped with one fix under 2218. Some of these sound like enhancements to me but since they appear to be addressing function that was previously available in 1.0 but dropped from the updated keystore portlet I assume they could be considered bug fixes. Comments? While I don't agree with your logic, I'm happy to consider this a bug fix, because that way some improvements might actually be applied. While just trying to get familiar with the keystore portlet as it currently stands (w/o the 2218 patch) I managed to get serialization errors that then reappeared each time I attempted to stop the server (even with no additional changes). I also managed to get the jetty server into a state where it could not start with just two clicks of the mouse from the portlet (one on the unlocked icon under Available for the geronimo-default keystore and then a second click on then locked icon attempting to undo what I did with the first click). The result was the following set of stack traces on server restart (kinda funny how it wants me to unlock the keystore using the console when the server itself won't even start). It is unfortunate that you can hose the server this way. But it's correct that the HTTPS connectors shouldn't start if they lack a correctly configured keystore. I think the best solution would be for the server to start up without HTTPS enabled, but that's a much larger conversation (there was a decision made in 1.1 to bail on startup if any GBean fails to start, and I'm not sure I agree). If the patch in question changes the startup failure if the keystore is locked, can you explain how it does it? For now, it might be best to have a confirm popup or screen if you lock a keystore that's currently in use by a web connector, though that's not a very scalable solution once things like CORBA (and perhaps EJB) start using these keystores too. Thanks, Aaron Joe Booting Geronimo Kernel (in Java 1.4.2_08)... Starting Geronimo Application Server v1.1.1-SNAPSHOT [*] 43% 8s Starting geronimo/jetty/1.1.1-SNA...10:27:12,640 WARN [SslListener] EXCEPTION org.apache.geronimo.management.geronimo.KeystoreIsLocked: Keystore 'geronimo-default' is locked; please use the keystore page in the admin console to unlock it at org.apache.geronimo.security.keystore.FileKeystoreManager.createSSLServerFactory(FileKeystoreManager.java:300) at org.apache.geronimo.security.keystore.FileKeystoreManager$$FastClassByCGLIB$$4d9d2a71.invoke(generated) at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53) at org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38) at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:122) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:817) at org.apache.geronimo.gbean.runtime.RawInvoker.invoke(RawInvoker.java:57) at org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke(RawOperationInvoker.java:35) at org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept(ProxyMethodInterceptor.java:96) at org.apache.geronimo.management.geronimo.KeystoreManager$$EnhancerByCGLIB$$be50f1ec.createSSLServerFactory(generated) at org.apache.geronimo.jetty.connector.GeronimoSSLListener.createFactory(GeronimoSSLListener.java:41) at org.mortbay.http.SslListener.newServerSocket(SslListener.java:283) at org.mortbay.util.ThreadedServer.open(ThreadedServer.java:477) at org.apache.geronimo.jetty.connector.JettyConnector.doStart(JettyConnector.java:233) at org.apache.geronimo.gbean.runtime.GBeanInstance.createInstance(GBeanInstance.java:981) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStart(GBeanInstanceState.java:267) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.start(GBeanInstanceState.java:102) at org.apache.geronimo.gbean.runtime.GBeanInstance.start(GBeanInstance.java:526) at org.apache.geronimo.gbean.runtime.GBeanDependency.attemptFullStart(GBeanDependency.java:111) at org.apache.geronimo.gbean.runtime.GBeanDependency.addTarget(GBeanDependency.java:146) at org.apache.geronimo.gbean.runtime.GBeanDependency$1.running(GBeanDependency.java:120) at
Re: [VOTE] Release Apache ActiveMQ 4.0.2
+1 On 7/26/06, Hiram Chirino [EMAIL PROTECTED] wrote: Since it was brought up, and folks concurred that it's about time to put out a bug fix release for ActiveMQ, I've put together a binary release of ActiveMQ 4.0.2: http://people.apache.org/~chirino/incubator-activemq-4.0.2-RC1/maven1/incubator-activemq/distributions/ http://people.apache.org/%7Echirino/incubator-activemq-4.0.1-RC1/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-RC1 http://people.apache.org/%7Echirino/incubator-activemq-4.0.1-RC1/ Here's the wiki page for the release notes (they should soon get mirrored to the activemq static website) : http://goopen.org/confluence/display/ACTIVEMQ/ActiveMQ+4.0.2+Release http://goopen.org/confluence/display/ACTIVEMQ/ActiveMQ+4.0.1+Release Please vote to approve this release binary [ ] +1 Release the binary as Apache ActiveMQ 4.0.2 [ ] -1 Veto the release (provide specific comments) If this vote passes, then we will then ask the Incubator PMC for their blessing to ship this release officially. Here's my +1 -- Regards, Hiram Blog: http://hiramchirino.com
[jira] Updated: (GERONIMO-2067) Configs migration to M2
[ http://issues.apache.org/jira/browse/GERONIMO-2067?page=all ] Anita Kulshreshtha updated GERONIMO-2067: - Attachment: configs.patch etc.patch pom.xml Prasad, These are the missing uddi-* patches. They are for the m2migration branch Here is the list - 1. configs.patch 2. etc.patch 3. pom.patch servlet-examples-* build fine for me. We should precompile jsps for the examples too. Configs migration to M2 --- Key: GERONIMO-2067 URL: http://issues.apache.org/jira/browse/GERONIMO-2067 Project: Geronimo Issue Type: Sub-task Security Level: public(Regular issues) Components: buildsystem Affects Versions: 1.2 Environment: All Reporter: Anita Kulshreshtha Assigned To: Anita Kulshreshtha Fix For: 1.2 Attachments: applications.patch, applications.patch, configs.log, configs.log, configs.log, configs.log, configs.patch, configs.patch, configs.patch, configs.patch, configs.patch, configs.patch, configs.patch, configs.patch, configs.patch, console-configs.patch, etc.patch, etc.patch, m2-plugins.patch, m2-plugins.patch, m2-plugins.patch, m2-plugins.patch, modules.patch, modules.patch, modules.patch, newconfigs.patch, pom.patch, pom.patch, pom.patch, pom.xml To build these configurations use packaging plugin GERONIMO-1740. This patch builds non openejb and non jetty configurations. This patch is for the new trunk, and has been edited using emcas to rempve ^M. -- 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-2067) Configs migration to M2
[ http://issues.apache.org/jira/browse/GERONIMO-2067?page=all ] Anita Kulshreshtha updated GERONIMO-2067: - Attachment: pom.patch The pom.patch is for the top level pom Configs migration to M2 --- Key: GERONIMO-2067 URL: http://issues.apache.org/jira/browse/GERONIMO-2067 Project: Geronimo Issue Type: Sub-task Security Level: public(Regular issues) Components: buildsystem Affects Versions: 1.2 Environment: All Reporter: Anita Kulshreshtha Assigned To: Anita Kulshreshtha Fix For: 1.2 Attachments: applications.patch, applications.patch, configs.log, configs.log, configs.log, configs.log, configs.patch, configs.patch, configs.patch, configs.patch, configs.patch, configs.patch, configs.patch, configs.patch, configs.patch, console-configs.patch, etc.patch, etc.patch, m2-plugins.patch, m2-plugins.patch, m2-plugins.patch, m2-plugins.patch, modules.patch, modules.patch, modules.patch, newconfigs.patch, pom.patch, pom.patch, pom.patch, pom.patch, pom.xml To build these configurations use packaging plugin GERONIMO-1740. This patch builds non openejb and non jetty configurations. This patch is for the new trunk, and has been edited using emcas to rempve ^M. -- 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: 1.1 keystore portlet bugs patches
Thanks for the response Aaron. Just to clarify ... should I go ahead and look into the patch from Vamsi or are you already looking at this? Some more info (and strange results) on the failure when the default-geronimo keystore is locked: jetty: - It really only takes one mouse click to hose the server. After I click on the unlocked icon under Available it changes to locked with no error or warning. This is enough to hose the server on a subsequent restart. More-over, it isn't obvious how to unlock this once I lock it (if I want to correct things before I terminate the server). It didn't require a password or anything other than the mouse click to lock it. However, to unlock it requires a password. How can one learn the password for the default keystore? Perhaps if we required the password on the lock operation (along with a warning message) it would prevent a casual click from having such destructive results. thoughts? tomcat: - The same operation on tomcat doesn't result in same failure to start the server ... but I suspect this is because we fail to persist the knowledge that the keystore is locked to begin with. Below is the serialization failure I get on shutdown. The funny thing is that after I restart the server the portlet continues to show the geronimo-default keystore as locked ... and yet this doesn't prevent the server from starting (as with jetty). I thought the error on shutdown was because we couldn't persist that locked attribute and hence that was why tomcat could still start. Any clues what's really going on here? Here's the serialization error on shutdown. There are no errors on restart but subsequent shutdowns continue to produce the same error if I navigate to the portlet at all: Server shutdown begun 11:05:39,515 WARN [[/console-standard]] Cannot serialize session attribute javax.portlet.p.Security_keystores_row1_col1_p1?org.apache.geronimo.keystore.geronim o-default for session C547C812F95DC4D3E60D02CEB57D0110 java.io.NotSerializableException: org.apache.geronimo.management.geronimo.KeystoreInstance$$EnhancerByCGLIB$$1211917 at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1054) at java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1332) at java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1304) at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1247) at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1052) at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:278) at org.apache.catalina.session.StandardSession.writeObject(StandardSession.java:1460) at org.apache.catalina.session.StandardSession.writeObjectData(StandardSession.java:936) at org.apache.catalina.session.StandardManager.doUnload(StandardManager.java:516) at org.apache.catalina.session.StandardManager.unload(StandardManager.java:462) at org.apache.catalina.session.StandardManager.stop(StandardManager.java:666) at org.apache.catalina.core.StandardContext.stop(StandardContext.java:4316) at org.apache.geronimo.tomcat.GeronimoStandardContext.stop(GeronimoStandardContext.java:216) at org.apache.geronimo.tomcat.TomcatContainer.removeContext(TomcatContainer.java:324) at org.apache.geronimo.tomcat.TomcatContainer$$FastClassByCGLIB$$9370b073.invoke(generated) at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53) at org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38) at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:122) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:817) at org.apache.geronimo.gbean.runtime.RawInvoker.invoke(RawInvoker.java:57) at org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke(RawOperationInvoker.java:35) at org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept(ProxyMethodInterceptor.java:96) at org.apache.geronimo.tomcat.TomcatContainer$$EnhancerByCGLIB$$350b65fa.removeContext(generated) at org.apache.geronimo.tomcat.TomcatWebAppContext.doStop(TomcatWebAppContext.java:459) at org.apache.geronimo.gbean.runtime.GBeanInstance.destroyInstance(GBeanInstance.java:1143) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStop(GBeanInstanceState.java:337) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.stop(GBeanInstanceState.java:188) at org.apache.geronimo.gbean.runtime.GBeanInstance.stop(GBeanInstance.java:548) at org.apache.geronimo.kernel.basic.BasicKernel.stopGBean(BasicKernel.java:423) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.stop(GBeanInstanceState.java:180) at
Openwire CPP Client Help
I got the latest from the http://svn.activemq.org/branches/activemq-4.0.1/openwire-cpp I don't know if this is the correct version to be working on or not. When I run the test this is what I get. Connecting to ActiveMQ broker... Opening socket to: 127.0.0.1 on port 61616 Sending command: cmd.id = 1, corr.id = -1, type = CONNECTION_INFO Received command: cmd.id = 0, corr.id = -1, type = WIRE_FORMAT_INFO Received command: cmd.id = 1, corr.id = -1, type = BROKER_INFO The program is stuck waiting for response on the CONNECTION_INFO. The response is null and there is an endless loop to sit there forever until response is set. Thanks for the help, -- View this message in context: http://www.nabble.com/Openwire-CPP-Client-Help-tf2004485.html#a5505442 Sent from the ActiveMQ - Dev forum at Nabble.com.
Re: 1.1 keystore portlet bugs patches
On 7/26/06, Joe Bohn [EMAIL PROTECTED] wrote: Thanks for the response Aaron. Just to clarify ... should I go ahead and look into the patch from Vamsi or are you already looking at this? Go ahead. Some more info (and strange results) on the failure when the default-geronimo keystore is locked: jetty: - It really only takes one mouse click to hose the server. After I click on the unlocked icon under Available it changes to locked with no error or warning. This is enough to hose the server on a subsequent restart. More-over, it isn't obvious how to unlock this once I lock it (if I want to correct things before I terminate the server). It didn't require a password or anything other than the mouse click to lock it. However, to unlock it requires a password. How can one learn the password for the default keystore? Perhaps if we required the password on the lock operation (along with a warning message) it would prevent a casual click from having such destructive results. thoughts? It's possible, though I think a confirmation along the lines of This keystore is currently in use. Locking it may prevent the server from starting. Continue? might be better. tomcat: - The same operation on tomcat doesn't result in same failure to start the server ... but I suspect this is because we fail to persist the knowledge that the keystore is locked to begin with. Below is the serialization failure I get on shutdown. The funny thing is that after I restart the server the portlet continues to show the geronimo-default keystore as locked ... and yet this doesn't prevent the server from starting (as with jetty). I thought the error on shutdown was because we couldn't persist that locked attribute and hence that was why tomcat could still start. Any clues what's really going on here? No, it's because Tomcat does not use the new keystore GBeans. So you can configure the keystore in question using the portlet, but you can't just pick it from a list in the Tomcat HTTPS configuration like you can for the Jetty HTTPS configuration, you have to instead manually re-enter the file location, keystore and key passwords, etc. It would be great if someone updated the Tocmat HTTPS connector to use the keystore GBean. Here's the serialization error on shutdown. There are no errors on restart but subsequent shutdowns continue to produce the same error if I navigate to the portlet at all: Looks like it's putting an instance of the KeystoreInstance GBean in the session. We should probably change the code to put some Serializable object in the session that holds the AbstractName for the KeystoreInstance and looks it up again from the kernel every time the portlet needs it. Thanks, Aaron Server shutdown begun 11:05:39,515 WARN [[/console-standard]] Cannot serialize session attribute javax.portlet.p.Security_keystores_row1_col1_p1?org.apache.geronimo.keystore.geronim o-default for session C547C812F95DC4D3E60D02CEB57D0110 java.io.NotSerializableException: org.apache.geronimo.management.geronimo.KeystoreInstance$$EnhancerByCGLIB$$1211917 at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1054) at java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1332) at java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1304) at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1247) at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1052) at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:278) at org.apache.catalina.session.StandardSession.writeObject(StandardSession.java:1460) at org.apache.catalina.session.StandardSession.writeObjectData(StandardSession.java:936) at org.apache.catalina.session.StandardManager.doUnload(StandardManager.java:516) at org.apache.catalina.session.StandardManager.unload(StandardManager.java:462) at org.apache.catalina.session.StandardManager.stop(StandardManager.java:666) at org.apache.catalina.core.StandardContext.stop(StandardContext.java:4316) at org.apache.geronimo.tomcat.GeronimoStandardContext.stop(GeronimoStandardContext.java:216) at org.apache.geronimo.tomcat.TomcatContainer.removeContext(TomcatContainer.java:324) at org.apache.geronimo.tomcat.TomcatContainer$$FastClassByCGLIB$$9370b073.invoke(generated) at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53) at org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38) at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:122) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:817) at org.apache.geronimo.gbean.runtime.RawInvoker.invoke(RawInvoker.java:57) at org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke(RawOperationInvoker.java:35) at
[jira] Resolved: (GERONIMO-1695) CORBA for EJB with Local interface only causes NPE
[ http://issues.apache.org/jira/browse/GERONIMO-1695?page=all ] Kevan Miller resolved GERONIMO-1695. Resolution: Fixed Applied patches to OpenEJB. Thanks Rick! RC 2817 for openejb/branches/v2_1/openejb2 RC 2818 for openejb/trunk/openejb2 CORBA for EJB with Local interface only causes NPE -- Key: GERONIMO-1695 URL: http://issues.apache.org/jira/browse/GERONIMO-1695 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: CORBA Affects Versions: 1.0 Reporter: Aaron Mulder Assigned To: Kevan Miller Priority: Critical Fix For: 1.1.1, 1.2 Attachments: GERONIMO-1695.diff-1.1.1, GERONIMO-1695.diff-1.2, GERONIMO-1695.diff-1.2a I have an EJB with a local interface and I tried applying CORBA settings. It blows up during deployment. My guess is that it wants a remote interface to be there, but somehow, the checks in StandardServant:126 are not working and the interface just comes up as null. Caused by: java.lang.NullPointerException at org.openejb.corba.util.Util.getAllInterfaces(Util.java:593) at org.openejb.corba.util.Util.getAllMethods(Util.java:815) at org.openejb.corba.util.Util.iiopMap(Util.java:608) at org.openejb.corba.util.Util.mapOperationToMethod(Util.java:604) at org.openejb.corba.StandardServant.init(StandardServant.java:135) at org.openejb.corba.StandardServant.init(StandardServant.java:116) at org.openejb.corba.Adapter.init(Adapter.java:100) ... 67 more -- 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] Resolved: (GERONIMO-2198) CSSBean creates 2 unnecessary threads for every instance.
[ http://issues.apache.org/jira/browse/GERONIMO-2198?page=all ] Kevan Miller resolved GERONIMO-2198. Fix Version/s: 1.2 Resolution: Fixed Fixed both CORBABean and CSSBean for OpenEJB 2.1.1 (RC 2814) and 2.2 (RC 2816) CSSBean creates 2 unnecessary threads for every instance. - Key: GERONIMO-2198 URL: http://issues.apache.org/jira/browse/GERONIMO-2198 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: OpenEJB Affects Versions: 1.1 Reporter: Rick McGuire Assigned To: Kevan Miller Fix For: 1.1.1, 1.2 Attachments: geronimo-2198.diff The CSSBean creates 2 ORB instances, then spins off a thread for each that calls orb.run(). This is completely unnecessary, since orb.run() doesn't actually run anythingit just causes the thread to wait until orb.destroy() is called. These two thread instances are pure overhead, with no functional purpose. -- 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] Resolved: (GERONIMO-2199) Key portion of Geronimo-1145 appears have gotten lost.
[ http://issues.apache.org/jira/browse/GERONIMO-2199?page=all ] Kevan Miller resolved GERONIMO-2199. Resolution: Fixed Thanks Rick. Patches applied. OpenEJB 2.1.1 (RC 2814) OpenEJB 2.2 (RC 2815) Key portion of Geronimo-1145 appears have gotten lost. -- Key: GERONIMO-2199 URL: http://issues.apache.org/jira/browse/GERONIMO-2199 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: OpenEJB Affects Versions: 1.1 Reporter: Rick McGuire Assigned To: Kevan Miller Priority: Minor Fix For: 1.1.1, 1.2 Attachments: GERONIMO-2199.diff-1.1.1, GERONIMO-2199.diff-1.2 A key piece of the patch for GERONIMO-1145 was left out when the patch was applied. The following change needs to be added: - componentContext.put(ORB, Util.getORB()); + componentContext.put(ORB, orb); Without this change, the rest of the patch is meaningless. -- 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: Openwire CPP Client Help
I got the latest on the openwire-cpp from the trunk directory and that has a
different effect.
pDataInputStream OpenWireProtocol::checkInputStream(pIInputStream
istream) throw (IOException)
{
// Assert that supplied output stream is a data output stream
pDataInputStream dis = p_dyncastDataInputStream (istream) ;
The cast to DataInputStream causes the following error
First-chance exception at 0x10227637 (msvcr71d.dll) in activemq-test.exe:
0xC005: Access violation reading location 0x0004.
The 4.0.1 branch hangs and never returns. The trunk version throws and
exception.
I can connect to the broker using java. I do notice on the jconsole that
the connection to the broker is created. But on the TcpTransport::Start()
method, it calls readThread-Start() that is where it throws the
exception.
Thanks,
--
View this message in context:
http://www.nabble.com/Openwire-CPP-Client-Help-tf2004485.html#a5506356
Sent from the ActiveMQ - Dev forum at Nabble.com.
[jira] Created: (GERONIMO-2229) Configs migration: uddi-jetty and uddi-tomcat
Configs migration: uddi-jetty and uddi-tomcat - Key: GERONIMO-2229 URL: http://issues.apache.org/jira/browse/GERONIMO-2229 Project: Geronimo Issue Type: Sub-task Security Level: public (Regular issues) Components: buildsystem Affects Versions: 1.2 Reporter: Prasad Kashyap Assigned To: Jason Dillon Fix For: 1.2 Thanks to Anita's patch in 2067 ( http://issues.apache.org/jira/secure/attachment/12337565/configs.patch ), the uddi configs can now be migrated. I had to rework her patch to apply against the latest code in m2migration branch. I also enabled the config in the assemblies. -- 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-2229) Configs migration: uddi-jetty and uddi-tomcat
[ http://issues.apache.org/jira/browse/GERONIMO-2229?page=all ] Prasad Kashyap updated GERONIMO-2229: - Attachment: uddi-config.patch Configs migration: uddi-jetty and uddi-tomcat - Key: GERONIMO-2229 URL: http://issues.apache.org/jira/browse/GERONIMO-2229 Project: Geronimo Issue Type: Sub-task Security Level: public(Regular issues) Components: buildsystem Affects Versions: 1.2 Reporter: Prasad Kashyap Assigned To: Jason Dillon Fix For: 1.2 Attachments: uddi-config.patch Thanks to Anita's patch in 2067 ( http://issues.apache.org/jira/secure/attachment/12337565/configs.patch ), the uddi configs can now be migrated. I had to rework her patch to apply against the latest code in m2migration branch. I also enabled the config in the assemblies. -- 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: [m2 build]: Runtime error using the hot-deployer
Prasad, The hot deployer configuration has changed recently. I hope to be able to provide a new patch by tommorrow. Thanks Anita --- Prasad Kashyap [EMAIL PROTECTED] wrote: I'm having trouble running the hot-deployer car in an m2 built server. The errror is as follows : java.lang.NoClassDefFoundError: org/apache/geronimo/deployment/plugin/ConfigIDEx tractor at java.lang.ClassLoader.defineClass0(Native Method) at java.lang.ClassLoader.defineClass(ClassLoader.java:539) at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:12 3) at org.apache.geronimo.kernel.classloader.JarFileClassLoader.access$200( JarFileClassLoader.java:51) at org.apache.geronimo.kernel.classloader.JarFileClassLoader$6.run(JarFi leClassLoader.java:275) Now I first saw a similar NoClassDefFoundError on the DeploymentFactoryImpl.class while loading/starting this hot-deployer CAR. I resolved that error by explicitly defining the geronimo-deploy-jsr88 artifact as a dependency of the hot-deployer config. (configs/hot-deployer/pom.xml). That successfully loaded/started the hot-deployer CAR. But when I try to deploy the jsp-examples-tomcat.5.5.15.war by dropping it into the deploy dir, I get the above error. Any ideas ? Cheers Prasad __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
M2 Configs : Dependency on logging-config jar in the plans
Jason, I found this in target/plan.xml of all the configs. dependency groupIdorg.apache.geronimo.genesis.config/groupId artifactIdlogging-config/artifactId version1.0.0-SNAPSHOT/version typejar/type importclasses/import /dependency How and why is this being added? Thanks Anita __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
RE: Openwire CPP Client Help
To be honest my knowledge of the openwire-cpp code is limited. I've
looked at it a little bit, and while the smart pointer code is scary, I
have not seen anything that looks terribly wrong. To figure this out
I'd have to spend time debugging and testing this code.
I'm only working on this in my free time, which is limited at the
moment, so it could take me some time to get to this, stupid day job...
Maybe one of the Openwire-cpp authors is lurking and will chime in on
what could be going wrong here.
-
Timothy A. Bish
Sensis Corporation
-
-Original Message-
From: kevinba [mailto:[EMAIL PROTECTED]
Sent: Wednesday, July 26, 2006 12:20 PM
To: activemq-dev@geronimo.apache.org
Subject: Re: Openwire CPP Client Help
I got the latest on the openwire-cpp from the trunk directory and that
has
a
different effect.
pDataInputStream OpenWireProtocol::checkInputStream(pIInputStream
istream) throw (IOException)
{
// Assert that supplied output stream is a data output stream
pDataInputStream dis = p_dyncastDataInputStream (istream) ;
The cast to DataInputStream causes the following error
First-chance exception at 0x10227637 (msvcr71d.dll) in
activemq-test.exe:
0xC005: Access violation reading location 0x0004.
The 4.0.1 branch hangs and never returns. The trunk version throws
and
exception.
I can connect to the broker using java. I do notice on the jconsole
that
the connection to the broker is created. But on the
TcpTransport::Start()
method, it calls readThread-Start() that is where it throws the
exception.
Thanks,
--
View this message in context:
http://www.nabble.com/Openwire-CPP-Client-
Help-tf2004485.html#a5506356
Sent from the ActiveMQ - Dev forum at Nabble.com.
RE: Openwire CPP Client Help
I'm trying to get a CPP client working. Stomp doesn't support Temporary topics so that is out of the question. I can't seem to get openwire-cpp working from the 4.0.1 or trunk branch to work. Different problems. Does anyone know of a good stable CPP client that I can use. I got the java side of the application switched over to ActiveMQ in an hour but it has been almost 2 weeks and still no working cpp side. If that means using 4.0.0 branch that is fine, what ever branch I have to use would be fine. I need use of temporary topics, to create them and to send replies back to. Request comes through on defined topic and the reply-to is set to a temporary topic so everyone doesn't receive the results. Thanks, -- View this message in context: http://www.nabble.com/Openwire-CPP-Client-Help-tf2004485.html#a5507875 Sent from the ActiveMQ - Dev forum at Nabble.com.
Re: Openwire CPP Client Help
Try using the C++ openwire that we recently contributed: https://issues.apache.org/activemq/browse/AMQ-842 Andrew Lusk Amazon.com -Original Message- From: kevinba [EMAIL PROTECTED] To: activemq-dev@geronimo.apache.org activemq-dev@geronimo.apache.org Sent: Wed Jul 26 10:44:56 2006 Subject: RE: Openwire CPP Client Help I'm trying to get a CPP client working. Stomp doesn't support Temporary topics so that is out of the question. I can't seem to get openwire-cpp working from the 4.0.1 or trunk branch to work. Different problems. Does anyone know of a good stable CPP client that I can use. I got the java side of the application switched over to ActiveMQ in an hour but it has been almost 2 weeks and still no working cpp side. If that means using 4.0.0 branch that is fine, what ever branch I have to use would be fine. I need use of temporary topics, to create them and to send replies back to. Request comes through on defined topic and the reply-to is set to a temporary topic so everyone doesn't receive the results. Thanks, -- View this message in context: http://www.nabble.com/Openwire-CPP-Client-Help-tf2004485.html#a5507875 Sent from the ActiveMQ - Dev forum at Nabble.com.
Re: M2 Configs : Dependency on logging-config jar in the plans
Interesting. logging-config provides a common log4j.properties to be used by all modules of the build system. Probably the car plugin needs to ignore dependencies that are extensions, since extensions imply they are for the build only. --jason On Jul 26, 2006, at 9:59 AM, anita kulshreshtha wrote: Jason, I found this in target/plan.xml of all the configs. dependency groupIdorg.apache.geronimo.genesis.config/groupId artifactIdlogging-config/artifactId version1.0.0-SNAPSHOT/version typejar/type importclasses/import /dependency How and why is this being added? Thanks Anita __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: Streamlining the ActiveMQ release process
Sounds cool with me. I guess once we get to 4.1 we can use the maven 2 release plugin to make this kinda stuff easier On 7/26/06, Hiram Chirino [EMAIL PROTECTED] wrote: Hi, I just recently put up a ActiveMQ 4.0.2 release candidate for vote so while it's fresh on my mind I'd like to see if anybody minds if I make a small tweak to the way we label our snapshot versions. I'd like to either change it to 4.0-SNAPSHOT or even 4.0.x-SNAPSHOT. The driver behind this change is that on the 4.0 branch, every time we do a release (for example this 4.0.2 release), we have to remember to increment the version on the branch on all the poms. It's easy to forget to change this and I don't see much value in changing the pom after every release. -- Regards, Hiram Blog: http://hiramchirino.com -- James --- http://radio.weblogs.com/0112098/
Re: LWContainer, JSR181 (and the components?)
With these new Container Service Engines approach how will people working in a servicemix.xml world use them? will the servicemix.xml start to include the ability to deploy exploded su's Like: sm:container id=jbi rootDir=./data/smx MBeanServer=#mbeanServer installationDirPath=./install deploymentDirPath=./deploy dumpStats=true statsInterval=10 flowName=seda transactionManager=#transactionManager workManager=#workManager depends-on=jndi sm:installComponent location=classpath:myComponent.jar/ sm:deployServiceUnit location=classpath:/firstSU/ /sm:container Since otherwise if we start to migrate away from POJO components to proper Service Engines (such as the obvious introduction of a Transformation Service Engine) how can people embedding ServiceMix use these engines and manage their deployment? I think its worth talking this through now - since I really would like to try and build a mental image of how smx migrates into a cleaner separtion of core functionality, and also makes adding components to a product/ESB or SOA simple. P On 7/23/06, Guillaume Nodet [EMAIL PROTECTED] wrote: On 7/24/06, Philip Dodds [EMAIL PROTECTED] wrote: Its a good point - though I think a lot of people at attaching themselves to the lw-container as the de-facto mechanism for developing JBI components, we should probably start trying to break down what they want to achieve and offer up some better SE's in that case. Maybe an EJB3 SE would allow people to see that they can house their application logic in a good development container and still reference it from JBI. I was thinking of embedding PitchFork ( http://www.interface21.com/pitchfork) in the jsr181 component, which would provide a non persistent ejb3 container. I was also thinking on creating a wsdl / jbi binding annotation set to be able to map jbi properties or attachments to arguments on a method call. If you want to access a real EJB, you can still use the jsr181 component and leverage spring proxy features to expose an existing EJB as a JBI endpoint. Another recent addition is the jsr181 proxy that can be used to request another endpoint using a java proxy (provided that the endpoint has a wsdl description and that you have a matching java interface). On the POJO side, we also have the SCA component (that needs to be finished and documented). I had some chat with the tuscany guys about that at Apachecon in Dublin. I see your point on the Container of Containers, I suppose its how that breaks into physical implementation that is still vague, and while JSR181 is a good way of exposing the metadata I suppose it isn't a good development container. And I still feel that we are going to need to look at how we can extend the handing of common SE Container logic (ie. classpaths for SU's etc). I think we need to visit how we can start creating a cleaner understanding of the components - and it might be time to state that we see the POJO components are first generation and not the future - and quickly provide a replacement POJO deployment model so that people can get into JBI with POJO's without picking up the lw-container? Agreed. But this is mainly a problem of documentation, which is obvisouly not my main skill :( I think we nearly have the POJO deployment model with the jsr181, but we need (maybe another component) more jbi specific features (time to revive/rewrite the Spring Client Toolkit somehow). Cheers, Guillaume Nodet P On 7/23/06, Guillaume Nodet [EMAIL PROTECTED] wrote: Note that the lwcontainer' s only purpose is to be able to deploy existing lightweight components. It relies on servicemix specific features, whereas other components are not specifically tied to ServiceMix. I' d really like to get rid of that in a very very long term. * implement existing lw components (xslt, ftp, drools, groovy, ...) as standard JBI components * create a simpler programming model (maybe like the old spring client toolkit) or enhance the jsr181 component . Recall that a JBI container is a container of containers. JBI components are not so easy to write (if you want it to be reusable) and when possible, all JBI related features should be hidden by SE when you want to develop a service. That' s what the jsr181 component or a BPEL engine SE do: you just deploy a service unit (pojo, xslt, bpel, ...) in a container (the component) to activate a service. Cheers, Guillaume Nodet On 7/24/06, Guillaume Nodet [EMAIL PROTECTED] wrote: Quoting the JBI spec: SEs are the business logic drivers of the JBI system. BCs are used to send and receive messages via particular protocols and transports. Let's talk about the jsr181 component. I think the definition for BCs clearly indicates that the
[jira] Created: (GERONIMO-2230) No cleanup after DeploymentWatcher exception
No cleanup after DeploymentWatcher exception Key: GERONIMO-2230 URL: http://issues.apache.org/jira/browse/GERONIMO-2230 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Components: deployment Affects Versions: 1.1 Reporter: Aaron Mulder Assigned To: Aaron Mulder Fix For: 1.1.1 Currently, DeploymentWatchers are notified of deployments, but if they throw an exception, the deployment fails but is not cleaned up. The easiest way around this is to allow DeploymentWatcher.deploy to throw IOException or DeploymentException, which we do clean up after. -- 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: LWContainer, JSR181 (and the components?)
All existing components can already be deployed in a servicemix.xmlconfiguration file. See for example http://servicemix.goopen.org/site/servicemix-eip.html#servicemix-eip-UsingservicemixeipinaServiceMixxmlconfigurationfile The syntax is exactly the same (thanks to XBean). So I don' t see any problems with the way it currently works, but any opinion is welcome. You are right that there is no support for installing components and deploying SUs from the servicemix.xml configuration file, but I think that the current way is easier to deal with. Cheers, Guillaume Nodet On 7/26/06, Philip Dodds [EMAIL PROTECTED] wrote: With these new Container Service Engines approach how will people working in a servicemix.xml world use them? will the servicemix.xml start to include the ability to deploy exploded su's Like: sm:container id=jbi rootDir=./data/smx MBeanServer=#mbeanServer installationDirPath=./install deploymentDirPath=./deploy dumpStats=true statsInterval=10 flowName=seda transactionManager=#transactionManager workManager=#workManager depends-on=jndi sm:installComponent location=classpath:myComponent.jar/ sm:deployServiceUnit location=classpath:/firstSU/ /sm:container Since otherwise if we start to migrate away from POJO components to proper Service Engines (such as the obvious introduction of a Transformation Service Engine) how can people embedding ServiceMix use these engines and manage their deployment? I think its worth talking this through now - since I really would like to try and build a mental image of how smx migrates into a cleaner separtion of core functionality, and also makes adding components to a product/ESB or SOA simple. P On 7/23/06, Guillaume Nodet [EMAIL PROTECTED] wrote: On 7/24/06, Philip Dodds [EMAIL PROTECTED] wrote: Its a good point - though I think a lot of people at attaching themselves to the lw-container as the de-facto mechanism for developing JBI components, we should probably start trying to break down what they want to achieve and offer up some better SE's in that case. Maybe an EJB3 SE would allow people to see that they can house their application logic in a good development container and still reference it from JBI. I was thinking of embedding PitchFork ( http://www.interface21.com/pitchfork) in the jsr181 component, which would provide a non persistent ejb3 container. I was also thinking on creating a wsdl / jbi binding annotation set to be able to map jbi properties or attachments to arguments on a method call. If you want to access a real EJB, you can still use the jsr181 component and leverage spring proxy features to expose an existing EJB as a JBI endpoint. Another recent addition is the jsr181 proxy that can be used to request another endpoint using a java proxy (provided that the endpoint has a wsdl description and that you have a matching java interface). On the POJO side, we also have the SCA component (that needs to be finished and documented). I had some chat with the tuscany guys about that at Apachecon in Dublin. I see your point on the Container of Containers, I suppose its how that breaks into physical implementation that is still vague, and while JSR181 is a good way of exposing the metadata I suppose it isn't a good development container. And I still feel that we are going to need to look at how we can extend the handing of common SE Container logic (ie. classpaths for SU's etc). I think we need to visit how we can start creating a cleaner understanding of the components - and it might be time to state that we see the POJO components are first generation and not the future - and quickly provide a replacement POJO deployment model so that people can get into JBI with POJO's without picking up the lw-container? Agreed. But this is mainly a problem of documentation, which is obvisouly not my main skill :( I think we nearly have the POJO deployment model with the jsr181, but we need (maybe another component) more jbi specific features (time to revive/rewrite the Spring Client Toolkit somehow). Cheers, Guillaume Nodet P On 7/23/06, Guillaume Nodet [EMAIL PROTECTED] wrote: Note that the lwcontainer' s only purpose is to be able to deploy existing lightweight components. It relies on servicemix specific features, whereas other components are not specifically tied to ServiceMix. I' d really like to get rid of that in a very very long term. * implement existing lw components (xslt, ftp, drools, groovy, ...) as standard JBI components * create a simpler programming model (maybe like the old spring client toolkit) or enhance the jsr181 component . Recall that a JBI container is a container of containers. JBI components
Re: [jira] Created: (GERONIMO-2229) Configs migration: uddi-jetty and uddi-tomcat
I will look at this later today. --jason On Jul 26, 2006, at 9:27 AM, Prasad Kashyap (JIRA) wrote: Configs migration: uddi-jetty and uddi-tomcat - Key: GERONIMO-2229 URL: http://issues.apache.org/jira/browse/ GERONIMO-2229 Project: Geronimo Issue Type: Sub-task Security Level: public (Regular issues) Components: buildsystem Affects Versions: 1.2 Reporter: Prasad Kashyap Assigned To: Jason Dillon Fix For: 1.2 Thanks to Anita's patch in 2067 ( http://issues.apache.org/jira/ secure/attachment/12337565/configs.patch ), the uddi configs can now be migrated. I had to rework her patch to apply against the latest code in m2migration branch. I also enabled the config in the assemblies. -- 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: 1.1 keystore portlet bugs patches
On 7/26/06, Joe Bohn [EMAIL PROTECTED] wrote: I think I understand your goals here Vamsi. However, I'm not sure that the portlet (as it currently stands) is a net positive or negative for Geronimo, even with your changes. It's not a matter of stress tests. It looks like basic function tests (unit tests) aren't working with this portlet. I don't fully understand the function of this portlet and perhaps that is clouding my judgment. Here's a list of the problems that I'm seeing (not necessarily complete): 1) You can hose the jetty server with one simple mouse click on the available lock icon. Even if we provided a warning prior to taking any action, it is still not a safe situation. There was a comment on the dev list just before 1.1 went out that this could be fixed by setting load=false on the SSLConnector and making the keystore available after server restart ... then restarting with the SSLConnector loaded again. However, even after doing this the next restart of the server still fails with the same error even though the console shows the keystore as available. I think this is a critical problem (see earlier post for one proposal on how to fix this by requiring the password). 2) Serialization failures terminating tomcat after attempting to lock a keystore so that it is unavailable. 2) The first panel indicates that the initial state of the keystores is locked and unavailable. However, it appears this is in error as the default keystore is locked to edit but available. This might just be semantics but it sounds like the capability doesn't match the description. This is not my experience. On a default install, if I look at that portlet, I see: Editable=(locked icon) Available=(unlocked icon) 1 key available Indicating that the keystore is available to be used by clients, but requires a password in order to edit. If that's not what you see can you try again from a fresh install of Geronimo? 3) Unlocking for edit state or making the keystore available after it's been locked seems to always result in serialization errors. This is the same as the first #2 above, and as I said, there's an easy workaround for the Serialization errors. 4) The keystore itself is not selectable when edit is locked. I assume this is by design. If you attempt to unlock the keystore for edit and provide no password (or a bogus password), then in addition to the exception being tossed for the bad password I would expect the keystore to remain locked. However, the edit icon will show unlocked and you can get to the edit fields of the keystore. It would be good to chage it to detect bad passwords and handle by not claiming that the keystore is unlocked. That's also important for when you make it available not just when you make it editable. To add to your list: we currently act like you can unlock specific keys in the keystore when you make the keystore available. However, I think most consumers expect to get the one and only private key in the keystore. It would be great to test with a keystore with two private keys and see if we can really allow you to select one or the other and have the HTTPS connectors use it accordingly. Finally, based on your questions below, you should do a bit more research on key/certificate plumbing. A certificate is different from a CA signing request and a CA signing response. It is appropriate to generate or upload a certificate but paste out a CA request and paste in a CA response. The procedure is more or less to create or install an unsigned cert, then ask a CA to sign it, then update the cert to include the signature information. Thanks, Aaron These problems don't have anything to do with the patch ... but I think they are higher priority than the items that the patch does address. Again, many of these problems may be my mis-understanding. However, I'm pretty sure that our users are not going to understand this any better than I did and potentially get themselves into trouble (esp. with Jetty). Vamsi, On your patch I don't see a lot changes from the initial behavior. Can you explain how I can get to re-introduced function that had been missing (preferably with a comment to GERONIMO-2218)? I'm also confused because I see things that I think are the functions you list as missing even before I apply the patch. For example, the JIRAs indicated that you could not import a CA reply. But isn't this just the ability to import the certificate itself? One difference between the behavior with your patch versus the front-door code is how the certificate is specified for import. The front-door code imports by selecting a certificate file (both jetty and tomcat) but with the patch it is an input field that wants the certificate content. Can you help me understand how it is better to cut and paste the content of the file rather than just select the file or am I not comparing these correctly? Your patch also mentioned adding the capability to generate a
Re: LWContainer, JSR181 (and the components?)
So in this case only Service Engines based on XBeans can be used in servicemix.xml, I suppose in my mind in the end SE's like the bpel and transformation would have been more likely to work out endpoints through provides/consumes metadata in jbi.xml and simple contain xslts and bpel in the SU's not xbean.xml? Also if this is the case we should probably package the components (and dependencies) in a none-SE/SL form? P On 7/26/06, Guillaume Nodet [EMAIL PROTECTED] wrote: All existing components can already be deployed in a servicemix.xmlconfiguration file. See for example http://servicemix.goopen.org/site/servicemix-eip.html#servicemix-eip-UsingservicemixeipinaServiceMixxmlconfigurationfile The syntax is exactly the same (thanks to XBean). So I don' t see any problems with the way it currently works, but any opinion is welcome. You are right that there is no support for installing components and deploying SUs from the servicemix.xml configuration file, but I think that the current way is easier to deal with. Cheers, Guillaume Nodet On 7/26/06, Philip Dodds [EMAIL PROTECTED] wrote: With these new Container Service Engines approach how will people working in a servicemix.xml world use them? will the servicemix.xml start to include the ability to deploy exploded su's Like: sm:container id=jbi rootDir=./data/smx MBeanServer=#mbeanServer installationDirPath=./install deploymentDirPath=./deploy dumpStats=true statsInterval=10 flowName=seda transactionManager=#transactionManager workManager=#workManager depends-on=jndi sm:installComponent location=classpath:myComponent.jar/ sm:deployServiceUnit location=classpath:/firstSU/ /sm:container Since otherwise if we start to migrate away from POJO components to proper Service Engines (such as the obvious introduction of a Transformation Service Engine) how can people embedding ServiceMix use these engines and manage their deployment? I think its worth talking this through now - since I really would like to try and build a mental image of how smx migrates into a cleaner separtion of core functionality, and also makes adding components to a product/ESB or SOA simple. P On 7/23/06, Guillaume Nodet [EMAIL PROTECTED] wrote: On 7/24/06, Philip Dodds [EMAIL PROTECTED] wrote: Its a good point - though I think a lot of people at attaching themselves to the lw-container as the de-facto mechanism for developing JBI components, we should probably start trying to break down what they want to achieve and offer up some better SE's in that case. Maybe an EJB3 SE would allow people to see that they can house their application logic in a good development container and still reference it from JBI. I was thinking of embedding PitchFork ( http://www.interface21.com/pitchfork) in the jsr181 component, which would provide a non persistent ejb3 container. I was also thinking on creating a wsdl / jbi binding annotation set to be able to map jbi properties or attachments to arguments on a method call. If you want to access a real EJB, you can still use the jsr181 component and leverage spring proxy features to expose an existing EJB as a JBI endpoint. Another recent addition is the jsr181 proxy that can be used to request another endpoint using a java proxy (provided that the endpoint has a wsdl description and that you have a matching java interface). On the POJO side, we also have the SCA component (that needs to be finished and documented). I had some chat with the tuscany guys about that at Apachecon in Dublin. I see your point on the Container of Containers, I suppose its how that breaks into physical implementation that is still vague, and while JSR181 is a good way of exposing the metadata I suppose it isn't a good development container. And I still feel that we are going to need to look at how we can extend the handing of common SE Container logic (ie. classpaths for SU's etc). I think we need to visit how we can start creating a cleaner understanding of the components - and it might be time to state that we see the POJO components are first generation and not the future - and quickly provide a replacement POJO deployment model so that people can get into JBI with POJO's without picking up the lw-container? Agreed. But this is mainly a problem of documentation, which is obvisouly not my main skill :( I think we nearly have the POJO deployment model with the jsr181, but we need (maybe another component) more jbi specific features (time to revive/rewrite the Spring Client Toolkit somehow). Cheers, Guillaume Nodet P On 7/23/06, Guillaume Nodet [EMAIL PROTECTED] wrote: Note that
[jira] Created: (GERONIMO-2231) Plugins can't reuse ENCConfigBuilder
Plugins can't reuse ENCConfigBuilder Key: GERONIMO-2231 URL: http://issues.apache.org/jira/browse/GERONIMO-2231 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Components: Plugins Affects Versions: 1.1 Reporter: Aaron Mulder Fix For: 1.x -- 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-2143) ENCConfigBuilder blocks outside callers
[ http://issues.apache.org/jira/browse/GERONIMO-2143?page=all ] Aaron Mulder updated GERONIMO-2143: --- Description: ENCConfigBuilder makes strategic methods private and some methods require an EAR context, module ID, JNDI builder, etc. that are only relevant for EAR callers. For plugins, etc. that want to create EJB/Resource/Service references, they need a lot of copy and paste and refactoring of code that should be reusable. The ENCConfigBuilder should be fixed to be equally useful to internal (J2EE) and external (non-J2EE) callers. Ideally, it would also take ConfigurationData instead of Configuration as arguments, which would make it easier to reuse outside the normal deployment process. was:ENCConfigBuilder makes strategic methods private and some methods require an EAR context, module ID, JNDI builder, etc. that are only relevant for EAR callers. For plugins, etc. that want to create EJB/Resource/Service references, they need a lot of copy and paste and refactoring of code that should be reusable. The ENCConfigBuilder should be fixed to be equally useful to internal (J2EE) and external (non-J2EE) callers. ENCConfigBuilder blocks outside callers --- Key: GERONIMO-2143 URL: http://issues.apache.org/jira/browse/GERONIMO-2143 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: deployment, naming Affects Versions: 1.1 Reporter: Aaron Mulder Fix For: 1.1.x ENCConfigBuilder makes strategic methods private and some methods require an EAR context, module ID, JNDI builder, etc. that are only relevant for EAR callers. For plugins, etc. that want to create EJB/Resource/Service references, they need a lot of copy and paste and refactoring of code that should be reusable. The ENCConfigBuilder should be fixed to be equally useful to internal (J2EE) and external (non-J2EE) callers. Ideally, it would also take ConfigurationData instead of Configuration as arguments, which would make it easier to reuse outside the normal deployment process. -- 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-2232) Plugins can't clean up when uninstallled
Plugins can't clean up when uninstallled Key: GERONIMO-2232 URL: http://issues.apache.org/jira/browse/GERONIMO-2232 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Components: Plugins Affects Versions: 1.1 Reporter: Aaron Mulder Fix For: 1.1.x When plugins are installed they can install files, etc. However, there's no way for them to clean up after themselves when uninstalled. Ideally, a plugin could include a class that would be called during the uninstall process. -- 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: LWContainer, JSR181 (and the components?)
It will be difficult to embed servicemix and use non embeddable components. (I guess it depends on what you mean by embed). For example if you take the PXE component, it will require a full installation step so that it can create the embedded database (and thus require a file system directory to store it). I think in this case, it would be easier to just start a full servicemix container and put the components and assemblies in the install/deploy dir, where they would automatically be installed. Cheers, Guillaume Nodet On 7/26/06, Philip Dodds [EMAIL PROTECTED] wrote: So in this case only Service Engines based on XBeans can be used in servicemix.xml, I suppose in my mind in the end SE's like the bpel and transformation would have been more likely to work out endpoints through provides/consumes metadata in jbi.xml and simple contain xslts and bpel in the SU's not xbean.xml? Also if this is the case we should probably package the components (and dependencies) in a none-SE/SL form? P On 7/26/06, Guillaume Nodet [EMAIL PROTECTED] wrote: All existing components can already be deployed in a servicemix.xmlconfiguration file. See for example http://servicemix.goopen.org/site/servicemix-eip.html#servicemix-eip-UsingservicemixeipinaServiceMixxmlconfigurationfile The syntax is exactly the same (thanks to XBean). So I don' t see any problems with the way it currently works, but any opinion is welcome. You are right that there is no support for installing components and deploying SUs from the servicemix.xml configuration file, but I think that the current way is easier to deal with. Cheers, Guillaume Nodet On 7/26/06, Philip Dodds [EMAIL PROTECTED] wrote: With these new Container Service Engines approach how will people working in a servicemix.xml world use them? will the servicemix.xml start to include the ability to deploy exploded su's Like: sm:container id=jbi rootDir=./data/smx MBeanServer=#mbeanServer installationDirPath=./install deploymentDirPath=./deploy dumpStats=true statsInterval=10 flowName=seda transactionManager=#transactionManager workManager=#workManager depends-on=jndi sm:installComponent location=classpath:myComponent.jar/ sm:deployServiceUnit location=classpath:/firstSU/ /sm:container Since otherwise if we start to migrate away from POJO components to proper Service Engines (such as the obvious introduction of a Transformation Service Engine) how can people embedding ServiceMix use these engines and manage their deployment? I think its worth talking this through now - since I really would like to try and build a mental image of how smx migrates into a cleaner separtion of core functionality, and also makes adding components to a product/ESB or SOA simple. P On 7/23/06, Guillaume Nodet [EMAIL PROTECTED] wrote: On 7/24/06, Philip Dodds [EMAIL PROTECTED] wrote: Its a good point - though I think a lot of people at attaching themselves to the lw-container as the de-facto mechanism for developing JBI components, we should probably start trying to break down what they want to achieve and offer up some better SE's in that case. Maybe an EJB3 SE would allow people to see that they can house their application logic in a good development container and still reference it from JBI. I was thinking of embedding PitchFork ( http://www.interface21.com/pitchfork) in the jsr181 component, which would provide a non persistent ejb3 container. I was also thinking on creating a wsdl / jbi binding annotation set to be able to map jbi properties or attachments to arguments on a method call. If you want to access a real EJB, you can still use the jsr181 component and leverage spring proxy features to expose an existing EJB as a JBI endpoint. Another recent addition is the jsr181 proxy that can be used to request another endpoint using a java proxy (provided that the endpoint has a wsdl description and that you have a matching java interface). On the POJO side, we also have the SCA component (that needs to be finished and documented). I had some chat with the tuscany guys about that at Apachecon in Dublin. I see your point on the Container of Containers, I suppose its how that breaks into physical implementation that is still vague, and while JSR181 is a good way of exposing the metadata I suppose it isn't a good development container. And I still feel that we are going to need to look at how we can extend the handing of common SE Container logic (ie. classpaths for SU's etc). I think we need to visit how we can start creating a cleaner
Re: LWContainer, JSR181 (and the components?)
I suppose there are compliations, and the embedding of SMX in App Server get around most of them, I suppose its just a case now of people understanding that the two models are different, and so the plan for current POJO components is to re-write them as Service Engines based on XBean so they can continue to be used in the embedded mode? Does the Service Engine archetype provide enough framework to ensure that any component written using it as a base in embeddable? Should we look at provide guidelines for writing components from this basis? P On 7/26/06, Guillaume Nodet [EMAIL PROTECTED] wrote: It will be difficult to embed servicemix and use non embeddable components. (I guess it depends on what you mean by embed). For example if you take the PXE component, it will require a full installation step so that it can create the embedded database (and thus require a file system directory to store it). I think in this case, it would be easier to just start a full servicemix container and put the components and assemblies in the install/deploy dir, where they would automatically be installed. Cheers, Guillaume Nodet On 7/26/06, Philip Dodds [EMAIL PROTECTED] wrote: So in this case only Service Engines based on XBeans can be used in servicemix.xml, I suppose in my mind in the end SE's like the bpel and transformation would have been more likely to work out endpoints through provides/consumes metadata in jbi.xml and simple contain xslts and bpel in the SU's not xbean.xml? Also if this is the case we should probably package the components (and dependencies) in a none-SE/SL form? P On 7/26/06, Guillaume Nodet [EMAIL PROTECTED] wrote: All existing components can already be deployed in a servicemix.xmlconfiguration file. See for example http://servicemix.goopen.org/site/servicemix-eip.html#servicemix-eip-UsingservicemixeipinaServiceMixxmlconfigurationfile The syntax is exactly the same (thanks to XBean). So I don' t see any problems with the way it currently works, but any opinion is welcome. You are right that there is no support for installing components and deploying SUs from the servicemix.xml configuration file, but I think that the current way is easier to deal with. Cheers, Guillaume Nodet On 7/26/06, Philip Dodds [EMAIL PROTECTED] wrote: With these new Container Service Engines approach how will people working in a servicemix.xml world use them? will the servicemix.xml start to include the ability to deploy exploded su's Like: sm:container id=jbi rootDir=./data/smx MBeanServer=#mbeanServer installationDirPath=./install deploymentDirPath=./deploy dumpStats=true statsInterval=10 flowName=seda transactionManager=#transactionManager workManager=#workManager depends-on=jndi sm:installComponent location=classpath:myComponent.jar/ sm:deployServiceUnit location=classpath:/firstSU/ /sm:container Since otherwise if we start to migrate away from POJO components to proper Service Engines (such as the obvious introduction of a Transformation Service Engine) how can people embedding ServiceMix use these engines and manage their deployment? I think its worth talking this through now - since I really would like to try and build a mental image of how smx migrates into a cleaner separtion of core functionality, and also makes adding components to a product/ESB or SOA simple. P On 7/23/06, Guillaume Nodet [EMAIL PROTECTED] wrote: On 7/24/06, Philip Dodds [EMAIL PROTECTED] wrote: Its a good point - though I think a lot of people at attaching themselves to the lw-container as the de-facto mechanism for developing JBI components, we should probably start trying to break down what they want to achieve and offer up some better SE's in that case. Maybe an EJB3 SE would allow people to see that they can house their application logic in a good development container and still reference it from JBI. I was thinking of embedding PitchFork ( http://www.interface21.com/pitchfork) in the jsr181 component, which would provide a non persistent ejb3 container. I was also thinking on creating a wsdl / jbi binding annotation set to be able to map jbi properties or attachments to arguments on a method call. If you want to access a real EJB, you can still use the jsr181 component and leverage spring proxy features to expose an existing EJB as a JBI endpoint. Another recent addition is the jsr181 proxy that can be used to request another endpoint using a java proxy (provided that the endpoint has a wsdl description and that
Re: Streamlining the ActiveMQ release process
I actually think the maven 2 release plugin is a bit of pain. It's not built to follow our release process where we put up release candidates, hold a vote, then deploy the release binaries. It also handles the branching and tagging very differently. On 7/26/06, James Strachan [EMAIL PROTECTED] wrote: Sounds cool with me. I guess once we get to 4.1 we can use the maven 2 release plugin to make this kinda stuff easier On 7/26/06, Hiram Chirino [EMAIL PROTECTED] wrote: Hi, I just recently put up a ActiveMQ 4.0.2 release candidate for vote so while it's fresh on my mind I'd like to see if anybody minds if I make a small tweak to the way we label our snapshot versions. I'd like to either change it to 4.0-SNAPSHOT or even 4.0.x-SNAPSHOT. The driver behind this change is that on the 4.0 branch, every time we do a release (for example this 4.0.2 release), we have to remember to increment the version on the branch on all the poms. It's easy to forget to change this and I don't see much value in changing the pom after every release. -- Regards, Hiram Blog: http://hiramchirino.com -- James --- http://radio.weblogs.com/0112098/ -- Regards, Hiram Blog: http://hiramchirino.com
Re: LWContainer, JSR181 (and the components?)
On 7/26/06, Philip Dodds [EMAIL PROTECTED] wrote: I suppose there are compliations, and the embedding of SMX in App Server get around most of them, I suppose its just a case now of people understanding that the two models are different, and so the plan for current POJO components is to re-write them as Service Engines based on XBean so they can continue to be used in the embedded mode? Agreed. FWIW, the servicemix-http is already a rewrite of the lightweight http components, so is servicemix-jms. Does the Service Engine archetype provide enough framework to ensure that any component written using it as a base in embeddable? Should we look at provide guidelines for writing components from this basis? The SE archetype is already embeddable. The junit test proves it :) We need to provide better documentation for sure. I need to finish http://servicemix.goopen.org/site/creating-a-standard-jbi-component.html Cheers, Guillaume Nodet P On 7/26/06, Guillaume Nodet [EMAIL PROTECTED] wrote: It will be difficult to embed servicemix and use non embeddable components. (I guess it depends on what you mean by embed). For example if you take the PXE component, it will require a full installation step so that it can create the embedded database (and thus require a file system directory to store it). I think in this case, it would be easier to just start a full servicemix container and put the components and assemblies in the install/deploy dir, where they would automatically be installed. Cheers, Guillaume Nodet On 7/26/06, Philip Dodds [EMAIL PROTECTED] wrote: So in this case only Service Engines based on XBeans can be used in servicemix.xml, I suppose in my mind in the end SE's like the bpel and transformation would have been more likely to work out endpoints through provides/consumes metadata in jbi.xml and simple contain xslts and bpel in the SU's not xbean.xml? Also if this is the case we should probably package the components (and dependencies) in a none-SE/SL form? P On 7/26/06, Guillaume Nodet [EMAIL PROTECTED] wrote: All existing components can already be deployed in a servicemix.xmlconfiguration file. See for example http://servicemix.goopen.org/site/servicemix-eip.html#servicemix-eip-UsingservicemixeipinaServiceMixxmlconfigurationfile The syntax is exactly the same (thanks to XBean). So I don' t see any problems with the way it currently works, but any opinion is welcome. You are right that there is no support for installing components and deploying SUs from the servicemix.xml configuration file, but I think that the current way is easier to deal with. Cheers, Guillaume Nodet On 7/26/06, Philip Dodds [EMAIL PROTECTED] wrote: With these new Container Service Engines approach how will people working in a servicemix.xml world use them? will the servicemix.xml start to include the ability to deploy exploded su's Like: sm:container id=jbi rootDir=./data/smx MBeanServer=#mbeanServer installationDirPath=./install deploymentDirPath=./deploy dumpStats=true statsInterval=10 flowName=seda transactionManager=#transactionManager workManager=#workManager depends-on=jndi sm:installComponent location=classpath:myComponent.jar/ sm:deployServiceUnit location=classpath:/firstSU/ /sm:container Since otherwise if we start to migrate away from POJO components to proper Service Engines (such as the obvious introduction of a Transformation Service Engine) how can people embedding ServiceMix use these engines and manage their deployment? I think its worth talking this through now - since I really would like to try and build a mental image of how smx migrates into a cleaner separtion of core functionality, and also makes adding components to a product/ESB or SOA simple. P On 7/23/06, Guillaume Nodet [EMAIL PROTECTED] wrote: On 7/24/06, Philip Dodds [EMAIL PROTECTED] wrote: Its a good point - though I think a lot of people at attaching themselves to the lw-container as the de-facto mechanism for developing JBI components, we should probably start trying to break down what they want to achieve and offer up some better SE's in that case. Maybe an EJB3 SE would allow people to see that they can house their application logic in a good development container and still reference it from JBI. I was thinking of embedding PitchFork ( http://www.interface21.com/pitchfork) in the jsr181 component, which would provide a non persistent ejb3
[jira] Created: (SM-500) FTPClientPool can't put its clients into passive mode
FTPClientPool can't put its clients into passive mode - Key: SM-500 URL: https://issues.apache.org/activemq/browse/SM-500 Project: ServiceMix Issue Type: Improvement Components: servicemix-components Affects Versions: 3.0 Reporter: Jordan Christensen Attachments: patch.txt FTPClientPool creates the FTPClients, and manages their connections, but cannot put them into passive mode. The attached patch adds a passiveMode parameter that causes it to put all created clients into passive mode. -- 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: Streamlining the ActiveMQ release process
True. So we must either: * change our release process to the maven practice, i.e. vote on snapshots and then release * find a nice way to release things and document it. Also note that our release process is somehow problematic. The way I did in ServiceMix and Xbean was to deploy the release to a private remote repository at Apache. But when the release is approved, you have to put the content of the repo in the public Apache repositories (at least for XBean, because ServiceMix and ActiveMQ are still in incubation). But if you just copy things, some metadata on the repository are lost :( From what i heard, maven 2.1 should handle such a release process better, but i'm not sure how. Cheers, Guillaume Nodet On 7/26/06, Hiram Chirino [EMAIL PROTECTED] wrote: I actually think the maven 2 release plugin is a bit of pain. It's not built to follow our release process where we put up release candidates, hold a vote, then deploy the release binaries. It also handles the branching and tagging very differently. On 7/26/06, James Strachan [EMAIL PROTECTED] wrote: Sounds cool with me. I guess once we get to 4.1 we can use the maven 2 release plugin to make this kinda stuff easier On 7/26/06, Hiram Chirino [EMAIL PROTECTED] wrote: Hi, I just recently put up a ActiveMQ 4.0.2 release candidate for vote so while it's fresh on my mind I'd like to see if anybody minds if I make a small tweak to the way we label our snapshot versions. I'd like to either change it to 4.0-SNAPSHOT or even 4.0.x-SNAPSHOT. The driver behind this change is that on the 4.0 branch, every time we do a release (for example this 4.0.2 release), we have to remember to increment the version on the branch on all the poms. It's easy to forget to change this and I don't see much value in changing the pom after every release. -- Regards, Hiram Blog: http://hiramchirino.com -- James --- http://radio.weblogs.com/0112098/ -- Regards, Hiram Blog: http://hiramchirino.com
Re: LWContainer, JSR181 (and the components?)
Actually that is a good point, I wonder whether we should depreciate the HTTP bindings from the components then? And I'll try and give you a hand on the documentation :) P On 7/26/06, Guillaume Nodet [EMAIL PROTECTED] wrote: On 7/26/06, Philip Dodds [EMAIL PROTECTED] wrote: I suppose there are compliations, and the embedding of SMX in App Server get around most of them, I suppose its just a case now of people understanding that the two models are different, and so the plan for current POJO components is to re-write them as Service Engines based on XBean so they can continue to be used in the embedded mode? Agreed. FWIW, the servicemix-http is already a rewrite of the lightweight http components, so is servicemix-jms. Does the Service Engine archetype provide enough framework to ensure that any component written using it as a base in embeddable? Should we look at provide guidelines for writing components from this basis? The SE archetype is already embeddable. The junit test proves it :) We need to provide better documentation for sure. I need to finish http://servicemix.goopen.org/site/creating-a-standard-jbi-component.html Cheers, Guillaume Nodet P On 7/26/06, Guillaume Nodet [EMAIL PROTECTED] wrote: It will be difficult to embed servicemix and use non embeddable components. (I guess it depends on what you mean by embed). For example if you take the PXE component, it will require a full installation step so that it can create the embedded database (and thus require a file system directory to store it). I think in this case, it would be easier to just start a full servicemix container and put the components and assemblies in the install/deploy dir, where they would automatically be installed. Cheers, Guillaume Nodet On 7/26/06, Philip Dodds [EMAIL PROTECTED] wrote: So in this case only Service Engines based on XBeans can be used in servicemix.xml, I suppose in my mind in the end SE's like the bpel and transformation would have been more likely to work out endpoints through provides/consumes metadata in jbi.xml and simple contain xslts and bpel in the SU's not xbean.xml? Also if this is the case we should probably package the components (and dependencies) in a none-SE/SL form? P On 7/26/06, Guillaume Nodet [EMAIL PROTECTED] wrote: All existing components can already be deployed in a servicemix.xmlconfiguration file. See for example http://servicemix.goopen.org/site/servicemix-eip.html#servicemix-eip-UsingservicemixeipinaServiceMixxmlconfigurationfile The syntax is exactly the same (thanks to XBean). So I don' t see any problems with the way it currently works, but any opinion is welcome. You are right that there is no support for installing components and deploying SUs from the servicemix.xml configuration file, but I think that the current way is easier to deal with. Cheers, Guillaume Nodet On 7/26/06, Philip Dodds [EMAIL PROTECTED] wrote: With these new Container Service Engines approach how will people working in a servicemix.xml world use them? will the servicemix.xml start to include the ability to deploy exploded su's Like: sm:container id=jbi rootDir=./data/smx MBeanServer=#mbeanServer installationDirPath=./install deploymentDirPath=./deploy dumpStats=true statsInterval=10 flowName=seda transactionManager=#transactionManager workManager=#workManager depends-on=jndi sm:installComponent location=classpath:myComponent.jar/ sm:deployServiceUnit location=classpath:/firstSU/ /sm:container Since otherwise if we start to migrate away from POJO components to proper Service Engines (such as the obvious introduction of a Transformation Service Engine) how can people embedding ServiceMix use these engines and manage their deployment? I think its worth talking this through now - since I really would like to try and build a mental image of how smx migrates into a cleaner separtion of core functionality, and also makes adding components to a product/ESB or SOA simple. P On 7/23/06, Guillaume Nodet [EMAIL PROTECTED] wrote: On 7/24/06, Philip Dodds [EMAIL PROTECTED] wrote: Its a good point - though I think a lot of people at attaching themselves to the lw-container as the de-facto mechanism for developing JBI components, we should probably start trying to break down what they want to achieve and offer up some better SE's in that
Re: 1.1 keystore portlet bugs patches
Aaron, Once again, thanks for the comments. Some more responses inline. I also renumbered the items to avoid the duplicate #2's ... sorry for the confusion. Aaron Mulder wrote: On 7/26/06, Joe Bohn [EMAIL PROTECTED] wrote: I think I understand your goals here Vamsi. However, I'm not sure that the portlet (as it currently stands) is a net positive or negative for Geronimo, even with your changes. It's not a matter of stress tests. It looks like basic function tests (unit tests) aren't working with this portlet. I don't fully understand the function of this portlet and perhaps that is clouding my judgment. Here's a list of the problems that I'm seeing (not necessarily complete): 1) You can hose the jetty server with one simple mouse click on the available lock icon. Even if we provided a warning prior to taking any action, it is still not a safe situation. There was a comment on the dev list just before 1.1 went out that this could be fixed by setting load=false on the SSLConnector and making the keystore available after server restart ... then restarting with the SSLConnector loaded again. However, even after doing this the next restart of the server still fails with the same error even though the console shows the keystore as available. I think this is a critical problem (see earlier post for one proposal on how to fix this by requiring the password). 2) Serialization failures terminating tomcat after attempting to lock a keystore so that it is unavailable. 3) The first panel indicates that the initial state of the keystores is locked and unavailable. However, it appears this is in error as the default keystore is locked to edit but available. This might just be semantics but it sounds like the capability doesn't match the description. This is not my experience. On a default install, if I look at that portlet, I see: Editable=(locked icon) Available=(unlocked icon) 1 key available Indicating that the keystore is available to be used by clients, but requires a password in order to edit. If that's not what you see can you try again from a fresh install of Geronimo? We are seeing the same thing. What I was pointing out was that the text on the panel says Keystores start out as locked against editing and also not available for usage by other components in the server. The *not available* statement led me to think that the portlet should show: Editable=(locked icon) Available=(locked icon) not available Again, it might just be a semantic problem with the wording on the panel rather than the state of keystore, but right now the two don't seem to match. 4) Unlocking for edit state or making the keystore available after it's been locked seems to always result in serialization errors. This is the same as #2 above, and as I said, there's an easy workaround for the Serialization errors. I'm not disputing your proposed change ... just listing some basic problems I'm seeing with the front-door code. I listed this separately because it is a different scenario that fails both on jetty and tomcat. This failure happens immediately on *unlock*. The #2 failure is on the available *lock* but only when the server is terminated as opposed to when the action is issued. And, IIRC, #2 only happens on tomcat. The same available lock operation on jetty results in #1 above. 5) The keystore itself is not selectable when edit is locked. I assume this is by design. If you attempt to unlock the keystore for edit and provide no password (or a bogus password), then in addition to the exception being tossed for the bad password I would expect the keystore to remain locked. However, the edit icon will show unlocked and you can get to the edit fields of the keystore. It would be good to chage it to detect bad passwords and handle by not claiming that the keystore is unlocked. That's also important for when you make it available not just when you make it editable. Not only would this be good, but it is the expected behavior when we challenge for a password to act accordingly if the correct password is not provided, isn't it? To add to your list: we currently act like you can unlock specific keys in the keystore when you make the keystore available. However, I think most consumers expect to get the one and only private key in the keystore. It would be great to test with a keystore with two private keys and see if we can really allow you to select one or the other and have the HTTPS connectors use it accordingly. Yep, sounds like another test case that should be run. Finally, based on your questions below, you should do a bit more research on key/certificate plumbing. A certificate is different from a CA signing request and a CA signing response. It is appropriate to generate or upload a certificate but paste out a CA request and paste in a CA response. The procedure is more or less to create or install an unsigned cert, then ask a CA to sign it,
Re: LWContainer, JSR181 (and the components?)
On 7/26/06, Philip Dodds [EMAIL PROTECTED] wrote: Actually that is a good point, I wonder whether we should depreciate the HTTP bindings from the components then? I think so. I have tried hardly to push servicemix-http during the past monthes. The only thing is that if you want some custom things, they are easier to modify, as you do not need to repackage the component. And I'll try and give you a hand on the documentation :) Thanks Cheers, Guillaume Nodet P On 7/26/06, Guillaume Nodet [EMAIL PROTECTED] wrote: On 7/26/06, Philip Dodds [EMAIL PROTECTED] wrote: I suppose there are compliations, and the embedding of SMX in App Server get around most of them, I suppose its just a case now of people understanding that the two models are different, and so the plan for current POJO components is to re-write them as Service Engines based on XBean so they can continue to be used in the embedded mode? Agreed. FWIW, the servicemix-http is already a rewrite of the lightweight http components, so is servicemix-jms. Does the Service Engine archetype provide enough framework to ensure that any component written using it as a base in embeddable? Should we look at provide guidelines for writing components from this basis? The SE archetype is already embeddable. The junit test proves it :) We need to provide better documentation for sure. I need to finish http://servicemix.goopen.org/site/creating-a-standard-jbi-component.html Cheers, Guillaume Nodet P On 7/26/06, Guillaume Nodet [EMAIL PROTECTED] wrote: It will be difficult to embed servicemix and use non embeddable components. (I guess it depends on what you mean by embed). For example if you take the PXE component, it will require a full installation step so that it can create the embedded database (and thus require a file system directory to store it). I think in this case, it would be easier to just start a full servicemix container and put the components and assemblies in the install/deploy dir, where they would automatically be installed. Cheers, Guillaume Nodet On 7/26/06, Philip Dodds [EMAIL PROTECTED] wrote: So in this case only Service Engines based on XBeans can be used in servicemix.xml, I suppose in my mind in the end SE's like the bpel and transformation would have been more likely to work out endpoints through provides/consumes metadata in jbi.xml and simple contain xslts and bpel in the SU's not xbean.xml? Also if this is the case we should probably package the components (and dependencies) in a none-SE/SL form? P On 7/26/06, Guillaume Nodet [EMAIL PROTECTED] wrote: All existing components can already be deployed in a servicemix.xmlconfiguration file. See for example http://servicemix.goopen.org/site/servicemix-eip.html#servicemix-eip-UsingservicemixeipinaServiceMixxmlconfigurationfile The syntax is exactly the same (thanks to XBean). So I don' t see any problems with the way it currently works, but any opinion is welcome. You are right that there is no support for installing components and deploying SUs from the servicemix.xml configuration file, but I think that the current way is easier to deal with. Cheers, Guillaume Nodet On 7/26/06, Philip Dodds [EMAIL PROTECTED] wrote: With these new Container Service Engines approach how will people working in a servicemix.xml world use them? will the servicemix.xmlstart to include the ability to deploy exploded su's Like: sm:container id=jbi rootDir=./data/smx MBeanServer=#mbeanServer installationDirPath=./install deploymentDirPath=./deploy dumpStats=true statsInterval=10 flowName=seda transactionManager=#transactionManager workManager=#workManager depends-on=jndi sm:installComponent location=classpath:myComponent.jar / sm:deployServiceUnit location=classpath:/firstSU/ /sm:container Since otherwise if we start to migrate away from POJO components to proper Service Engines (such as the obvious introduction of a Transformation Service Engine) how can people embedding ServiceMix use these engines and manage their deployment? I think its worth talking this through now - since I really would like to try and build a mental image of how smx migrates into a cleaner separtion of core functionality, and also makes adding components to a product/ESB or SOA simple. P
Re: LWContainer, JSR181 (and the components?)
What about extending the endpoint in the Service Unit? P On 7/26/06, Guillaume Nodet [EMAIL PROTECTED] wrote: On 7/26/06, Philip Dodds [EMAIL PROTECTED] wrote: Actually that is a good point, I wonder whether we should depreciate the HTTP bindings from the components then? I think so. I have tried hardly to push servicemix-http during the past monthes. The only thing is that if you want some custom things, they are easier to modify, as you do not need to repackage the component. And I'll try and give you a hand on the documentation :) Thanks Cheers, Guillaume Nodet P On 7/26/06, Guillaume Nodet [EMAIL PROTECTED] wrote: On 7/26/06, Philip Dodds [EMAIL PROTECTED] wrote: I suppose there are compliations, and the embedding of SMX in App Server get around most of them, I suppose its just a case now of people understanding that the two models are different, and so the plan for current POJO components is to re-write them as Service Engines based on XBean so they can continue to be used in the embedded mode? Agreed. FWIW, the servicemix-http is already a rewrite of the lightweight http components, so is servicemix-jms. Does the Service Engine archetype provide enough framework to ensure that any component written using it as a base in embeddable? Should we look at provide guidelines for writing components from this basis? The SE archetype is already embeddable. The junit test proves it :) We need to provide better documentation for sure. I need to finish http://servicemix.goopen.org/site/creating-a-standard-jbi-component.html Cheers, Guillaume Nodet P On 7/26/06, Guillaume Nodet [EMAIL PROTECTED] wrote: It will be difficult to embed servicemix and use non embeddable components. (I guess it depends on what you mean by embed). For example if you take the PXE component, it will require a full installation step so that it can create the embedded database (and thus require a file system directory to store it). I think in this case, it would be easier to just start a full servicemix container and put the components and assemblies in the install/deploy dir, where they would automatically be installed. Cheers, Guillaume Nodet On 7/26/06, Philip Dodds [EMAIL PROTECTED] wrote: So in this case only Service Engines based on XBeans can be used in servicemix.xml, I suppose in my mind in the end SE's like the bpel and transformation would have been more likely to work out endpoints through provides/consumes metadata in jbi.xml and simple contain xslts and bpel in the SU's not xbean.xml? Also if this is the case we should probably package the components (and dependencies) in a none-SE/SL form? P On 7/26/06, Guillaume Nodet [EMAIL PROTECTED] wrote: All existing components can already be deployed in a servicemix.xmlconfiguration file. See for example http://servicemix.goopen.org/site/servicemix-eip.html#servicemix-eip-UsingservicemixeipinaServiceMixxmlconfigurationfile The syntax is exactly the same (thanks to XBean). So I don' t see any problems with the way it currently works, but any opinion is welcome. You are right that there is no support for installing components and deploying SUs from the servicemix.xml configuration file, but I think that the current way is easier to deal with. Cheers, Guillaume Nodet On 7/26/06, Philip Dodds [EMAIL PROTECTED] wrote: With these new Container Service Engines approach how will people working in a servicemix.xml world use them? will the servicemix.xmlstart to include the ability to deploy exploded su's Like: sm:container id=jbi rootDir=./data/smx MBeanServer=#mbeanServer installationDirPath=./install deploymentDirPath=./deploy dumpStats=true statsInterval=10 flowName=seda transactionManager=#transactionManager workManager=#workManager depends-on=jndi sm:installComponent location=classpath:myComponent.jar / sm:deployServiceUnit location=classpath:/firstSU/ /sm:container Since otherwise if we start to migrate away from POJO components to proper Service Engines (such as the obvious introduction of a Transformation Service Engine) how can people embedding ServiceMix use these engines and manage their deployment? I think its worth talking this through now
Re: 1.1 keystore portlet bugs patches
I don't have a ton of time to work on this right now -- that's the only reason I'm trying to avoid doing it myself. However, it sounds like we probably ought to start in any case with a Wiki page and a description of what we think this portlet ought to be able to do, and perhaps a list of which of those functions have problems or are missing and which patches address each issue. Could you and Vamsi work on putting that together? If we all agree on exactly what needs to be done then it should be easier to get the patches aligned and make it easier to evaluate and apply them. Thanks, Aaron On 7/26/06, Joe Bohn [EMAIL PROTECTED] wrote: Aaron, Once again, thanks for the comments. Some more responses inline. I also renumbered the items to avoid the duplicate #2's ... sorry for the confusion. Aaron Mulder wrote: On 7/26/06, Joe Bohn [EMAIL PROTECTED] wrote: I think I understand your goals here Vamsi. However, I'm not sure that the portlet (as it currently stands) is a net positive or negative for Geronimo, even with your changes. It's not a matter of stress tests. It looks like basic function tests (unit tests) aren't working with this portlet. I don't fully understand the function of this portlet and perhaps that is clouding my judgment. Here's a list of the problems that I'm seeing (not necessarily complete): 1) You can hose the jetty server with one simple mouse click on the available lock icon. Even if we provided a warning prior to taking any action, it is still not a safe situation. There was a comment on the dev list just before 1.1 went out that this could be fixed by setting load=false on the SSLConnector and making the keystore available after server restart ... then restarting with the SSLConnector loaded again. However, even after doing this the next restart of the server still fails with the same error even though the console shows the keystore as available. I think this is a critical problem (see earlier post for one proposal on how to fix this by requiring the password). 2) Serialization failures terminating tomcat after attempting to lock a keystore so that it is unavailable. 3) The first panel indicates that the initial state of the keystores is locked and unavailable. However, it appears this is in error as the default keystore is locked to edit but available. This might just be semantics but it sounds like the capability doesn't match the description. This is not my experience. On a default install, if I look at that portlet, I see: Editable=(locked icon) Available=(unlocked icon) 1 key available Indicating that the keystore is available to be used by clients, but requires a password in order to edit. If that's not what you see can you try again from a fresh install of Geronimo? We are seeing the same thing. What I was pointing out was that the text on the panel says Keystores start out as locked against editing and also not available for usage by other components in the server. The *not available* statement led me to think that the portlet should show: Editable=(locked icon) Available=(locked icon) not available Again, it might just be a semantic problem with the wording on the panel rather than the state of keystore, but right now the two don't seem to match. 4) Unlocking for edit state or making the keystore available after it's been locked seems to always result in serialization errors. This is the same as #2 above, and as I said, there's an easy workaround for the Serialization errors. I'm not disputing your proposed change ... just listing some basic problems I'm seeing with the front-door code. I listed this separately because it is a different scenario that fails both on jetty and tomcat. This failure happens immediately on *unlock*. The #2 failure is on the available *lock* but only when the server is terminated as opposed to when the action is issued. And, IIRC, #2 only happens on tomcat. The same available lock operation on jetty results in #1 above. 5) The keystore itself is not selectable when edit is locked. I assume this is by design. If you attempt to unlock the keystore for edit and provide no password (or a bogus password), then in addition to the exception being tossed for the bad password I would expect the keystore to remain locked. However, the edit icon will show unlocked and you can get to the edit fields of the keystore. It would be good to chage it to detect bad passwords and handle by not claiming that the keystore is unlocked. That's also important for when you make it available not just when you make it editable. Not only would this be good, but it is the expected behavior when we challenge for a password to act accordingly if the correct password is not provided, isn't it? To add to your list: we currently act like you can unlock specific keys in the keystore when you make the keystore available. However, I think most consumers expect to get the one
Re: LWContainer, JSR181 (and the components?)
That's they way to do it. But HttpEndpoint delegates to ConsumerProcessor / ProviderProcessor, so you also need to write another processor for your endpoint. Btw, Bruce suggested a while ago, that we should have several dedicated endpoints instead of having only one. We should be able to do that without breaking compatibility (I hope, else...) so we would have http:consumer ... / http:provider / http:soap-consumer ... / http:soap-provider ... / It may be easier to understand for users. Cheers, Guillaume Nodet On 7/26/06, Philip Dodds [EMAIL PROTECTED] wrote: What about extending the endpoint in the Service Unit? P On 7/26/06, Guillaume Nodet [EMAIL PROTECTED] wrote: On 7/26/06, Philip Dodds [EMAIL PROTECTED] wrote: Actually that is a good point, I wonder whether we should depreciate the HTTP bindings from the components then? I think so. I have tried hardly to push servicemix-http during the past monthes. The only thing is that if you want some custom things, they are easier to modify, as you do not need to repackage the component. And I'll try and give you a hand on the documentation :) Thanks Cheers, Guillaume Nodet P On 7/26/06, Guillaume Nodet [EMAIL PROTECTED] wrote: On 7/26/06, Philip Dodds [EMAIL PROTECTED] wrote: I suppose there are compliations, and the embedding of SMX in App Server get around most of them, I suppose its just a case now of people understanding that the two models are different, and so the plan for current POJO components is to re-write them as Service Engines based on XBean so they can continue to be used in the embedded mode? Agreed. FWIW, the servicemix-http is already a rewrite of the lightweight http components, so is servicemix-jms. Does the Service Engine archetype provide enough framework to ensure that any component written using it as a base in embeddable? Should we look at provide guidelines for writing components from this basis? The SE archetype is already embeddable. The junit test proves it :) We need to provide better documentation for sure. I need to finish http://servicemix.goopen.org/site/creating-a-standard-jbi-component.html Cheers, Guillaume Nodet P On 7/26/06, Guillaume Nodet [EMAIL PROTECTED] wrote: It will be difficult to embed servicemix and use non embeddable components. (I guess it depends on what you mean by embed). For example if you take the PXE component, it will require a full installation step so that it can create the embedded database (and thus require a file system directory to store it). I think in this case, it would be easier to just start a full servicemix container and put the components and assemblies in the install/deploy dir, where they would automatically be installed. Cheers, Guillaume Nodet On 7/26/06, Philip Dodds [EMAIL PROTECTED] wrote: So in this case only Service Engines based on XBeans can be used in servicemix.xml, I suppose in my mind in the end SE's like the bpel and transformation would have been more likely to work out endpoints through provides/consumes metadata in jbi.xml and simple contain xslts and bpel in the SU's not xbean.xml? Also if this is the case we should probably package the components (and dependencies) in a none-SE/SL form? P On 7/26/06, Guillaume Nodet [EMAIL PROTECTED] wrote: All existing components can already be deployed in a servicemix.xmlconfiguration file. See for example http://servicemix.goopen.org/site/servicemix-eip.html#servicemix-eip-UsingservicemixeipinaServiceMixxmlconfigurationfile The syntax is exactly the same (thanks to XBean). So I don' t see any problems with the way it currently works, but any opinion is welcome. You are right that there is no support for installing components and deploying SUs from the servicemix.xml configuration file, but I think that the current way is easier to deal with. Cheers, Guillaume Nodet On 7/26/06, Philip Dodds [EMAIL PROTECTED] wrote: With these new Container Service Engines approach how will people working in a servicemix.xml world use them? will the servicemix.xmlstart to include the ability to deploy exploded su's Like: sm:container id=jbi rootDir=./data/smx MBeanServer=#mbeanServer installationDirPath=./install deploymentDirPath=./deploy dumpStats=true
Re: Packaging options and archetypes
On 7/23/06, Philip Dodds [EMAIL PROTECTED] wrote: Yeah - Actually I think we need to look more holistically at the packaging, archetypes, samples and website. Maybe before doing anything we can starting laying out how we can structure the components, documentation and make the website a little more structured, so that you can choose a route through the product/samples/documentation. Don't you think we can handle svn layout / distributions and documentation separatly ? IMHO, they are quite independant things and it would be easier to discuss. I was thinking something like a front page that says I want to set-up Apache ServiceMix to integrate applications I want to use Apache ServiceMix components in my Web Application I want to add integration functionality to my messaging architecture I want to start building processes using choreography and Apache ServiceMix Then each would take you through not only the packaging for you, but also the archetypes and the samples. I know its a big picture thing - but I have always found its best to envisage the goal while we plan the projects. Don't you think it will be difficult not to be redundant in these sections ? I would have thought about a User Guide a la spring. Cheers, Guillaume Nodet P On 7/22/06, Guillaume Nodet [EMAIL PROTECTED] wrote: I think this is the best way. We need to rewrite the examples using the archetypes and it will also provide nice tutorials (we miss them a lot). Cheers, Guillaume Nodet On 7/23/06, Philip Dodds [EMAIL PROTECTED] wrote: True, and I think a mix of samples and archetypes would be good. What I was thinking was if the samples where completed archetypes - ie. for a loan broker or something you have 3-4 archetypes and are completed with the business requirements. Thus giving people the completed picture, and allowing them the basis for building it. P On 7/22/06, Guillaume Nodet [EMAIL PROTECTED] wrote: I do agree. However, I' m still not sure if archetype can completely replace samples. I guess they can if they can show something usefull, but will it be the case for all archetypes ? Cheers, Guillaume Nodet On 7/23/06, Philip Dodds [EMAIL PROTECTED] wrote: We need to look at the examples and assign a package pre-req for them, on the web app note I'm starting to wonder whether providing ServiceMix in a WAR would be better made into a archetype than a project - something that someone can create a basic web-app framework (smx set-up inside) for use? P On 7/22/06, Guillaume Nodet [EMAIL PROTECTED] wrote: +1 for several distributions. However I see several problems: * where to put the samples: some use the standard JBI deployment (SU + SA) and other only use a static spring configuration with lightweight components. * we need to provide a clean documentation about integration styles: servicemix standalone, in a web app, embedded so that users can choose the needed distribution On 7/18/06, Philip Dodds [EMAIL PROTECTED] wrote: I have been thinking over the restructuring that we have been discussing and I'm wondering whether we should look at create a couple of flavours of distribution, so that in place of a big install we have: Server - Just the Core Server (no components) Server/Components - Core Server and Components Geronimo Package - Core Server with everything needed to deploy to geronimo For the Geronimo package, I think that a Geronimo plugin would be the best way to do that, as Aaron pointed in another thread. JBoss Package (off-site) - Core Server with everything needed to deploy to JBoss Components - Just the components Also I'm wondering whether we should look at the archetypes as a way to offer the functionality such as: +1 Cheers, Guillaume Nodet ServiceMix Embedded in a Web Application ServiceMix Embedded in a simple Application ServiceMix Embedding with Spring I have been adding archetypes to get things started for the components we have now and intend to continue with that. Also I'm thinking we could fix up the lwcontainers (I'm getting to it) and then create archetypes for each of the components so that we are able to provide a little bit of quick start information. Cheers Philip
[jira] Created: (DAYTRADER-9) MarketSummary fix for NPE with less than 106 quotes
MarketSummary fix for NPE with less than 106 quotes --- Key: DAYTRADER-9 URL: http://issues.apache.org/jira/browse/DAYTRADER-9 Project: DayTrader Issue Type: Improvement Components: EJB Tier Affects Versions: 1.1 Environment: All OS / all platforms Reporter: Slava This is a fix for the NPE in the MarketSummary.jsp and TradeHome.jsp thrown when the Daytrader database contains only 100 or less quotes. (see http://issues.apache.org/jira/browse/GERONIMO-1674) The current default configuration is 200 users and 400 quotes. As previously discussed, it takes long time to populate Daytrader database with as many user/quotes. This fix solves that problem. No NPE will be thrown if the database is populated with less than 105 quotes. This will speed up significantly the functional test with Daytrader. However, to retrieve market summary data you still need to have more than 106 quotes in the database. Therefore for performance measurments with Daytrader should be done using higher number of users/quotes. Slava -- 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: (DAYTRADER-9) MarketSummary fix for NPE with less than 106 quotes
[ http://issues.apache.org/jira/browse/DAYTRADER-9?page=all ] Slava updated DAYTRADER-9: -- Attachment: DAYTRADER-9.patch MarketSummary fix for NPE with less than 106 quotes --- Key: DAYTRADER-9 URL: http://issues.apache.org/jira/browse/DAYTRADER-9 Project: DayTrader Issue Type: Improvement Components: EJB Tier Affects Versions: 1.1 Environment: All OS / all platforms Reporter: Slava Attachments: DAYTRADER-9.patch This is a fix for the NPE in the MarketSummary.jsp and TradeHome.jsp thrown when the Daytrader database contains only 100 or less quotes. (see http://issues.apache.org/jira/browse/GERONIMO-1674) The current default configuration is 200 users and 400 quotes. As previously discussed, it takes long time to populate Daytrader database with as many user/quotes. This fix solves that problem. No NPE will be thrown if the database is populated with less than 105 quotes. This will speed up significantly the functional test with Daytrader. However, to retrieve market summary data you still need to have more than 106 quotes in the database. Therefore for performance measurments with Daytrader should be done using higher number of users/quotes. Slava -- 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
NetBeans plugin for Geronimo - anyone interested?
Hi, It's been a while when I approached the idea to build a serverplugins plugin for Geronimo. After some time, when I was about to announce it my hard drive crashed and everything flew away in the blink of an eye. Nothing left thus it needs to be started over. We've got an Eclipse plugin in the devtools project, but no NetBeans one. The serverplugins module is a bunch of plugins for J2EE application servers. There's no Geronimo plugin and I think we need to take appropriate steps to change it. There are some alternatives - Mevenide (M2 support and once Geronimo becomes M2-oriented it's going to be very easy to combine those two worlds), copying j2ee modules to hot-deploy directory of Geronimo and the last but not least Codehaus Cargo, but it's not the truly NetBeans-oriented approach. It's time to change it. Therefore, I'd like to ask you how important it is to have such a plugin for NetBeans. Would you care to help out and contribute? The work could be conducted in sandbox so no fear it'll be lost when your hard drive blows up. Jacek -- Jacek Laskowski http://www.laskowski.net.pl
Re: Packaging options and archetypes
I would recommend more worked examples in the documentation and strictly, the worked examples should be used as QA tests for snapshots so that the examples are provably in sync with the releases. If you look at the forum, nobody could build consistently until a web page was put up documenting the sequence of build steps to apply. The same thing is required for the main common issues like JBoss integration, manual deployment of dependent classes for lw-container apps, real-world HTTP endpoint configuration etc. The examples are useful, but too simple and too focused upon lw-container approaches so you can't actually get a broad understanding of the JBI model from looking at the examples and the docs presuppose a strong background in Web Service concepts and jargon which is not always the case for Java-centric developers moving into integration. I am finding that the best way to illustrate some of these subjects to my developers is to build animated PowerPoint presentations that show how events move about within the environment. If we can find a web-centric way of doing animation easily, I'm happy to contribute similar docs for the site? Terry
[jira] Resolved: (SM-500) FTPClientPool can't put its clients into passive mode
[ https://issues.apache.org/activemq/browse/SM-500?page=all ] Guillaume Nodet resolved SM-500. Fix Version/s: 3.0-M3 Resolution: Fixed Assignee: Guillaume Nodet Author: gnodet Date: Wed Jul 26 15:01:58 2006 New Revision: 425868 URL: http://svn.apache.org/viewvc?rev=425868view=rev Log: SM-500: FTPClientPool can't put its clients into passive mode Patch provided by Jordan Christensen, thx ! Modified: incubator/servicemix/trunk/servicemix-components/src/main/java/org/apache/servicemix/components/net/FTPClientPool.java FTPClientPool can't put its clients into passive mode - Key: SM-500 URL: https://issues.apache.org/activemq/browse/SM-500 Project: ServiceMix Issue Type: Improvement Components: servicemix-components Affects Versions: 3.0 Reporter: Jordan Christensen Assigned To: Guillaume Nodet Fix For: 3.0-M3 Attachments: patch.txt FTPClientPool creates the FTPClients, and manages their connections, but cannot put them into passive mode. The attached patch adds a passiveMode parameter that causes it to put all created clients into passive mode. -- 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: NetBeans plugin for Geronimo - anyone interested?
NetBeans is a very popular IDE and with the latest version sporting a bunch of JEE features, it would be great if we had support for it... so that instead of needing SunONE developers could use Geronimo :-) --jason On Jul 26, 2006, at 2:57 PM, Jacek Laskowski wrote: Hi, It's been a while when I approached the idea to build a serverplugins plugin for Geronimo. After some time, when I was about to announce it my hard drive crashed and everything flew away in the blink of an eye. Nothing left thus it needs to be started over. We've got an Eclipse plugin in the devtools project, but no NetBeans one. The serverplugins module is a bunch of plugins for J2EE application servers. There's no Geronimo plugin and I think we need to take appropriate steps to change it. There are some alternatives - Mevenide (M2 support and once Geronimo becomes M2-oriented it's going to be very easy to combine those two worlds), copying j2ee modules to hot-deploy directory of Geronimo and the last but not least Codehaus Cargo, but it's not the truly NetBeans-oriented approach. It's time to change it. Therefore, I'd like to ask you how important it is to have such a plugin for NetBeans. Would you care to help out and contribute? The work could be conducted in sandbox so no fear it'll be lost when your hard drive blows up. Jacek -- Jacek Laskowski http://www.laskowski.net.pl
[jira] Reopened: (GERONIMO-2066) Openejb migration to M2
[ http://issues.apache.org/jira/browse/GERONIMO-2066?page=all ] Anita Kulshreshtha reopened GERONIMO-2066: -- Assignee: Anita Kulshreshtha (was: Prasad Kashyap) Openejb migration to M2 --- Key: GERONIMO-2066 URL: http://issues.apache.org/jira/browse/GERONIMO-2066 Project: Geronimo Issue Type: Sub-task Security Level: public(Regular issues) Components: buildsystem Environment: All Reporter: Anita Kulshreshtha Assigned To: Anita Kulshreshtha Attachments: openejb.patch, openejb.patch, openejb.patch, openejb.patch The attached patch provides a local openejb build for Geronimo using o.a.g.modules groupId. This is to ensure that the latest openejb jars are available. The results for rev 2659 are below : Path: . URL: https://svn.codehaus.org/openejb/branches/v2_1/openejb2 Repository UUID: 2b0c1533-c60b-0410-b8bd-89f67432e5c6 Revision: 2659 Node Kind: directory Schedule: normal Last Changed Author: gdamour Last Changed Rev: 2659 Last Changed Date: 2006-05-27 08:00:16 -0400 (Sat, 27 May 2006) Properties Last Updated: 2006-05-26 19:05:28 -0400 (Fri, 26 May 2006) Todo - fix the test failures. APSHOT\openejb-builder-2.1-SNAPSHOT.jar [INFO] [INFO] [INFO] [INFO] Reactor Summary: [INFO] [INFO] OpenEJB SUCCESS [3.953s] [INFO] OpenEJB :: Core SUCCESS [30.515s] [INFO] OpenEJB :: PK Generation :: Builder SUCCESS [9.297s] [INFO] OpenEJB :: Builder . SUCCESS [27.875s] [INFO] [INFO] [INFO] BUILD SUCCESSFUL [INFO] [INFO] Total time: 1 minute 12 seconds [INFO] Finished at: Mon May 29 08:11:40 EDT 2006 [INFO] Final Memory: 17M/53M [INFO] -- 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] Resolved: (GERONIMO-2066) Openejb migration to M2
[ http://issues.apache.org/jira/browse/GERONIMO-2066?page=all ] Anita Kulshreshtha resolved GERONIMO-2066. -- Fix Version/s: 1.2 Resolution: Fixed The openejb.patch dt 02/Jun/06 was attached to GERONIMO-2071 and was applied by David Jencks to openejb at codehaus on 02/Jun/06. http://issues.apache.org/jira/browse/GERONIMO-2071#action_12414538 Openejb migration to M2 --- Key: GERONIMO-2066 URL: http://issues.apache.org/jira/browse/GERONIMO-2066 Project: Geronimo Issue Type: Sub-task Security Level: public(Regular issues) Components: buildsystem Environment: All Reporter: Anita Kulshreshtha Assigned To: Anita Kulshreshtha Fix For: 1.2 Attachments: openejb.patch, openejb.patch, openejb.patch, openejb.patch The attached patch provides a local openejb build for Geronimo using o.a.g.modules groupId. This is to ensure that the latest openejb jars are available. The results for rev 2659 are below : Path: . URL: https://svn.codehaus.org/openejb/branches/v2_1/openejb2 Repository UUID: 2b0c1533-c60b-0410-b8bd-89f67432e5c6 Revision: 2659 Node Kind: directory Schedule: normal Last Changed Author: gdamour Last Changed Rev: 2659 Last Changed Date: 2006-05-27 08:00:16 -0400 (Sat, 27 May 2006) Properties Last Updated: 2006-05-26 19:05:28 -0400 (Fri, 26 May 2006) Todo - fix the test failures. APSHOT\openejb-builder-2.1-SNAPSHOT.jar [INFO] [INFO] [INFO] [INFO] Reactor Summary: [INFO] [INFO] OpenEJB SUCCESS [3.953s] [INFO] OpenEJB :: Core SUCCESS [30.515s] [INFO] OpenEJB :: PK Generation :: Builder SUCCESS [9.297s] [INFO] OpenEJB :: Builder . SUCCESS [27.875s] [INFO] [INFO] [INFO] BUILD SUCCESSFUL [INFO] [INFO] Total time: 1 minute 12 seconds [INFO] Finished at: Mon May 29 08:11:40 EDT 2006 [INFO] Final Memory: 17M/53M [INFO] -- 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: svn commit: r425429 - /geronimo/branches/1.1/modules/system/src/java/org/apache/geronimo/system/configuration/GBeanOverride.java
Reposting.. probably got lost in all the email traffic.
John
John Sisson wrote:
Aaron,
What JIRA is associated with this change?
Thanks,
John
[EMAIL PROTECTED] wrote:
Author: ammulder
Date: Tue Jul 25 08:55:34 2006
New Revision: 425429
URL: http://svn.apache.org/viewvc?rev=425429view=rev
Log:
Module and name are independent of artifact
Modified:
geronimo/branches/1.1/modules/system/src/java/org/apache/geronimo/system/configuration/GBeanOverride.java
Modified:
geronimo/branches/1.1/modules/system/src/java/org/apache/geronimo/system/configuration/GBeanOverride.java
URL:
http://svn.apache.org/viewvc/geronimo/branches/1.1/modules/system/src/java/org/apache/geronimo/system/configuration/GBeanOverride.java?rev=425429r1=425428r2=425429view=diff
==
---
geronimo/branches/1.1/modules/system/src/java/org/apache/geronimo/system/configuration/GBeanOverride.java
(original)
+++
geronimo/branches/1.1/modules/system/src/java/org/apache/geronimo/system/configuration/GBeanOverride.java
Tue Jul 25 08:55:34 2006
@@ -459,17 +459,17 @@
type.appendChild(doc.createTextNode(artifact.getType()));
pat.appendChild(type);
}
-Map nameMap = pattern.getName();
-if (nameMap.get(module) != null) {
-Element module = doc.createElement(module);
-
module.appendChild(doc.createTextNode(nameMap.get(module).toString()));
-pat.appendChild(module);
-}
-if (nameMap.get(name) != null) {
-Element patName = doc.createElement(name);
-
patName.appendChild(doc.createTextNode(nameMap.get(name).toString()));
-pat.appendChild(patName);
-}
+}
+Map nameMap = pattern.getName();
+if (nameMap.get(module) != null) {
+Element module = doc.createElement(module);
+
module.appendChild(doc.createTextNode(nameMap.get(module).toString()));
+pat.appendChild(module);
+}
+if (nameMap.get(name) != null) {
+Element patName = doc.createElement(name);
+
patName.appendChild(doc.createTextNode(nameMap.get(name).toString()));
+pat.appendChild(patName);
}
//out.print(pattern.toString());
}
[jira] Commented: (DAYTRADER-9) MarketSummary fix for NPE with less than 106 quotes
[
http://issues.apache.org/jira/browse/DAYTRADER-9?page=comments#action_12423753
]
Matt Hogstrom commented on DAYTRADER-9:
---
Slava,
there is an if in the patch
+if ( (topGainersData.size() 0) || (topGainersData.size() 0)){
I'm not sure why the comparison is duplicated. Did you mean to have another
value for the comparison? I expect we only need one of the comparisons but
wanted to check.
MarketSummary fix for NPE with less than 106 quotes
---
Key: DAYTRADER-9
URL: http://issues.apache.org/jira/browse/DAYTRADER-9
Project: DayTrader
Issue Type: Improvement
Components: EJB Tier
Affects Versions: 1.1
Environment: All OS / all platforms
Reporter: Slava
Attachments: DAYTRADER-9.patch
This is a fix for the NPE in the MarketSummary.jsp and TradeHome.jsp thrown
when the Daytrader database contains only 100 or less quotes. (see
http://issues.apache.org/jira/browse/GERONIMO-1674)
The current default configuration is 200 users and 400 quotes. As previously
discussed, it takes long time to populate Daytrader database with as many
user/quotes.
This fix solves that problem. No NPE will be thrown if the database is
populated with less than 105 quotes. This will speed up significantly the
functional test with Daytrader.
However, to retrieve market summary data you still need to have more than 106
quotes in the database. Therefore for performance measurments with Daytrader
should be done using higher number of users/quotes.
Slava
--
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: 1.1 keystore portlet bugs patches
Aaron Mulder wrote: On 7/26/06, Joe Bohn [EMAIL PROTECTED] wrote: I was looking to see what else we need to get fixed in 1.1.1 and noticed that there are several issues (in both 1.1 and 1.1.1) around the keystore portlet. I know nothing about the keystore portlet and thought I'd check here (esp. with Aaron) before I started looking into the patches that Vamsi has provided. It appears that this is a real problem spot (esp. given my initial experiment ... see below), so I'm hoping that the patch from Vamsi works wonders :-) . It seems like there are a number of issues (1196, 1531, 1984, and 2218) which have all been grouped with one fix under 2218. Some of these sound like enhancements to me but since they appear to be addressing function that was previously available in 1.0 but dropped from the updated keystore portlet I assume they could be considered bug fixes. Comments? While I don't agree with your logic, I'm happy to consider this a bug fix, because that way some improvements might actually be applied. While just trying to get familiar with the keystore portlet as it currently stands (w/o the 2218 patch) I managed to get serialization errors that then reappeared each time I attempted to stop the server (even with no additional changes). I also managed to get the jetty server into a state where it could not start with just two clicks of the mouse from the portlet (one on the unlocked icon under Available for the geronimo-default keystore and then a second click on then locked icon attempting to undo what I did with the first click). The result was the following set of stack traces on server restart (kinda funny how it wants me to unlock the keystore using the console when the server itself won't even start). It is unfortunate that you can hose the server this way. But it's correct that the HTTPS connectors shouldn't start if they lack a correctly configured keystore. I think the best solution would be for the server to start up without HTTPS enabled, but that's a much larger conversation (there was a decision made in 1.1 to bail on startup if any GBean fails to start, and I'm not sure I agree). A failure like this I would consider a fatal error. If the patch in question changes the startup failure if the keystore is locked, can you explain how it does it? For now, it might be best to have a confirm popup or screen if you lock a keystore that's currently in use by a web connector, though that's not a very scalable solution once things like CORBA (and perhaps EJB) start using these keystores too. Thanks, Aaron Joe Booting Geronimo Kernel (in Java 1.4.2_08)... Starting Geronimo Application Server v1.1.1-SNAPSHOT [*] 43% 8s Starting geronimo/jetty/1.1.1-SNA...10:27:12,640 WARN [SslListener] EXCEPTION org.apache.geronimo.management.geronimo.KeystoreIsLocked: Keystore 'geronimo-default' is locked; please use the keystore page in the admin console to unlock it at org.apache.geronimo.security.keystore.FileKeystoreManager.createSSLServerFactory(FileKeystoreManager.java:300) at org.apache.geronimo.security.keystore.FileKeystoreManager$$FastClassByCGLIB$$4d9d2a71.invoke(generated) at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53) at org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38) at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:122) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:817) at org.apache.geronimo.gbean.runtime.RawInvoker.invoke(RawInvoker.java:57) at org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke(RawOperationInvoker.java:35) at org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept(ProxyMethodInterceptor.java:96) at org.apache.geronimo.management.geronimo.KeystoreManager$$EnhancerByCGLIB$$be50f1ec.createSSLServerFactory(generated) at org.apache.geronimo.jetty.connector.GeronimoSSLListener.createFactory(GeronimoSSLListener.java:41) at org.mortbay.http.SslListener.newServerSocket(SslListener.java:283) at org.mortbay.util.ThreadedServer.open(ThreadedServer.java:477) at org.apache.geronimo.jetty.connector.JettyConnector.doStart(JettyConnector.java:233) at org.apache.geronimo.gbean.runtime.GBeanInstance.createInstance(GBeanInstance.java:981) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStart(GBeanInstanceState.java:267) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.start(GBeanInstanceState.java:102) at org.apache.geronimo.gbean.runtime.GBeanInstance.start(GBeanInstance.java:526) at org.apache.geronimo.gbean.runtime.GBeanDependency.attemptFullStart(GBeanDependency.java:111) at org.apache.geronimo.gbean.runtime.GBeanDependency.addTarget(GBeanDependency.java:146)
Pessimistic locking strategy for CMP beans in 1.1.1
I wanted to let people know about one of the fixes I'm putting into 1.1.1. I addressed this issue in a note previously and it has to do with our locking model for CMP persistence. This note is applicable to OpenEJB-2.1.1-SNAPSHOT as well as TranQL 1.3.1-SNAPSHOT. Currently users deploying CMP beans have no mechanism to specify if they want to lock the row in a DB when they execute a finder on a CMP entity. This means that there is no locking in the database and multiple concurrent users have a high degree of either corrupting data or getting SQL -911 deadlocks in their application. To mitigate this issue I am adding a few new elements to the OpenEJB schema to allow users to specify this option. Here is my current thinking and I'd like some feedback if you have time and are interested. Basically there are two ways locking is implemented. The first is a pessimistic strategy that relies on the database to enforce locking. Unfortunately, different DBMS's have various ways to address this. It is generally accomplished by setting the appropriate isolation level and specifying *for update* on the select clause. I believe that with the knowledge of a pessimistic strategy the DBSyntaxGenerators in TranQL can put out the appropriate SQL to accomplish this. The second method is to use an optimistic strategy where a mono incrementing column or timestamp is used to disambiguate tuples from each other. The container keeps track of the value of the optimistic column. I'm planning on implementing this later but thought we'd make the schema changes now. I would like to add a locking-strategy section to the entity-bean element after the pre-fetch group. The locking strategy really is either optimistic or pessimistic. Currently I'm focusing on pessimistic and need to finalize the optimistic options but this is enough for discussion. Something like: xs:element name=locking-strategy xs:complexType xs:sequence xs:element name=optimistic-locking maxOccurs=1 xs:complexType xs:sequence xs:element name=optimistic-column type=xs:string/ xs:element name=optimistic-type type=xs:string/ /xs:sequence /xs:complexType /xs:element /xs:sequence /xs:complexType xs:complexType xs:sequence xs:element name=pessimistic-locking maxOccurs=1 xs:complexType xs:sequence xs:element name=select-for-update minOccurs=0/ /xs:sequence /xs:complexType /xs:element /xs:sequence /xs:complexType /xs:element This seems clunky to me...is there a better way to express this idea as the locking strategy requires one or the other but not both. I think the above is ok and will validate in the builder but want some feedback. Here is what I would expect a user to code: entity ejb-nameKeyGenEJB/ejb-name table-nameKeyGenEJB/table-name cmp-field-mapping cmp-field-namekeyVal/cmp-field-name table-columnkeyVal/table-column /cmp-field-mapping cmp-field-mapping cmp-field-namekeyName/cmp-field-name table-columnkeyName/table-column /cmp-field-mapping locking-strategy pessimistic-locking /locking-strategy . . or . . locking-strategy optimistic-locking optimistic-columnoccColumn/optimistic-column optimistic-typeTIMESTAMP/optimistic-type /locking-strategy /entity BAH...NOTE I wrote this abot 8 hours ago and here it sits unsent...bummer. Well, here it is now.
[jira] Commented: (GERONIMO-2229) Configs migration: uddi-jetty and uddi-tomcat
[ http://issues.apache.org/jira/browse/GERONIMO-2229?page=comments#action_12423758 ] Jason Dillon commented on GERONIMO-2229: Is the config supposed to be load=false? How can I test if the car works? Configs migration: uddi-jetty and uddi-tomcat - Key: GERONIMO-2229 URL: http://issues.apache.org/jira/browse/GERONIMO-2229 Project: Geronimo Issue Type: Sub-task Security Level: public(Regular issues) Components: buildsystem Affects Versions: 1.2 Reporter: Prasad Kashyap Assigned To: Jason Dillon Fix For: 1.2 Attachments: uddi-config.patch Thanks to Anita's patch in 2067 ( http://issues.apache.org/jira/secure/attachment/12337565/configs.patch ), the uddi configs can now be migrated. I had to rework her patch to apply against the latest code in m2migration branch. I also enabled the config in the assemblies. -- 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
