[jira] Resolved: (AMQ-942) ActiveMQStreamMessage should support large text format in writeString.
[ https://issues.apache.org/activemq/browse/AMQ-942?page=all ] Adrian Co resolved AMQ-942. --- Fix Version/s: 4.1 Resolution: Fixed rev: r452793 Added support for writing and reading of large strings in ActiveMQStreamMessage. Also, refactored ActiveMQStreamMessage to also use the MarshallingSupport utility. NOTE: Refactoring the ActiveMQStreamMessage to use the MarshallingSupport utility will make it incompatible with previous versions as the wireformat has been changed. It is advisable to clear existing messages and use clients with the same version. ActiveMQStreamMessage should support large text format in writeString. -- Key: AMQ-942 URL: https://issues.apache.org/activemq/browse/AMQ-942 Project: ActiveMQ Issue Type: Bug Components: JMS client Affects Versions: 4.1, 4.0.2 Reporter: Adrian Co Assigned To: Adrian Co Priority: Critical Fix For: 4.1 I was wondering if ActiveMQStreamMessage should support large text messages also, since MapMessage is also able to support this. -- 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
Changes in ActiveMQStreamMessage wireformat
Hi, I refactored the ActiveMQStreamMessage to also use the MarshallingSupport utility to write its data. This cause some changes in the wireformat of ActiveMQStreamMessage. So there would be wireformat incompatibility from r452793 and up with previous revisions. It is advisable to clear your message database to prevent any wireformat problems. :) Hope this is not too much of an inconvenience. Regards, Adrian Co
[jira] Created: (AMQ-955) Failover connection not working with master slave configuration
Failover connection not working with master slave configuration --- Key: AMQ-955 URL: https://issues.apache.org/activemq/browse/AMQ-955 Project: ActiveMQ Issue Type: Bug Components: Broker, JMS client Affects Versions: 4.0.1 Environment: Red Hat Enterprise Linux Reporter: Vikas Naredi Attachments: masterSlave.zip We are trying to set up master-slave configuration using ActiveMQ 4.0.1. We have tried our best to configure it as directed by the docs but couldn't achieve the desired result as the failover does not operate if the master goes down. We have attached our configuration files and following are the steps to reproduce the problem. 1. Start the two brokers with masterSpike.xml and masterSlave.xml. 2. Run the spike app SpikeMasterSlaveApp. It works fine. 3. Now kill the master broker and run our spike application again. 4. It doesn't establish connection with the slave. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (SM-660) org.apache.servicemix.eip.DeploymentTest
org.apache.servicemix.eip.DeploymentTest Key: SM-660 URL: https://issues.apache.org/activemq/browse/SM-660 Project: ServiceMix Issue Type: Sub-task Components: servicemix-eip Affects Versions: incubation Reporter: Fritz Oconer -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (SM-662) org.apache.servicemix.eip.SpringConfigurationTest
org.apache.servicemix.eip.SpringConfigurationTest - Key: SM-662 URL: https://issues.apache.org/activemq/browse/SM-662 Project: ServiceMix Issue Type: Sub-task Components: servicemix-eip Affects Versions: incubation Reporter: Fritz Oconer -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (SM-661) org.apache.servicemix.eip.support.NamespaceContextImplTest
org.apache.servicemix.eip.support.NamespaceContextImplTest -- Key: SM-661 URL: https://issues.apache.org/activemq/browse/SM-661 Project: ServiceMix Issue Type: Sub-task Components: servicemix-eip Affects Versions: incubation Reporter: Fritz Oconer -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (SM-665) org.apache.servicemix.http.HttpTxTest
org.apache.servicemix.http.HttpTxTest - Key: SM-665 URL: https://issues.apache.org/activemq/browse/SM-665 Project: ServiceMix Issue Type: Sub-task Components: servicemix-http Affects Versions: incubation Reporter: Fritz Oconer -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (SM-667) org.apache.servicemix.common.TransactionsTest
org.apache.servicemix.common.TransactionsTest - Key: SM-667 URL: https://issues.apache.org/activemq/browse/SM-667 Project: ServiceMix Issue Type: Sub-task Components: servicemix-common Affects Versions: incubation Reporter: Fritz Oconer -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (SM-668) JCAFlow should reject synchronous exchanges
[ https://issues.apache.org/activemq/browse/SM-668?page=all ] Guillaume Nodet resolved SM-668. Resolution: Fixed Assignee: Guillaume Nodet Author: gnodet Date: Wed Oct 4 04:41:09 2006 New Revision: 452856 URL: http://svn.apache.org/viewvc?view=revrev=452856 Log: SM-668: JCAFlow should reject synchronous exchanges Modified: incubator/servicemix/trunk/servicemix-core/src/main/java/org/apache/servicemix/jbi/nmr/flow/jca/JCAFlow.java incubator/servicemix/trunk/servicemix-core/src/test/java/org/apache/servicemix/jbi/nmr/flow/jca/JcaFlowWithTxLogTest.java JCAFlow should reject synchronous exchanges --- Key: SM-668 URL: https://issues.apache.org/activemq/browse/SM-668 Project: ServiceMix Issue Type: Bug Components: servicemix-core Affects Versions: 3.0 Reporter: Guillaume Nodet Assigned To: Guillaume Nodet Fix For: 3.1 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (SM-669) Statistic file should be named stats.csv instead of stats.cvs
Statistic file should be named stats.csv instead of stats.cvs - Key: SM-669 URL: https://issues.apache.org/activemq/browse/SM-669 Project: ServiceMix Issue Type: Bug Affects Versions: 3.0 Reporter: Guillaume Nodet Fix For: 3.1 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (SM-669) Statistic file should be named stats.csv instead of stats.cvs
[ https://issues.apache.org/activemq/browse/SM-669?page=all ] Guillaume Nodet resolved SM-669. Resolution: Fixed Assignee: Guillaume Nodet Author: gnodet Date: Wed Oct 4 04:55:27 2006 New Revision: 452868 URL: http://svn.apache.org/viewvc?view=revrev=452868 Log: SM-669: rename the stats file to stats.csv Modified: incubator/servicemix/trunk/servicemix-core/src/main/java/org/apache/servicemix/jbi/container/EnvironmentContext.java Statistic file should be named stats.csv instead of stats.cvs - Key: SM-669 URL: https://issues.apache.org/activemq/browse/SM-669 Project: ServiceMix Issue Type: Bug Affects Versions: 3.0 Reporter: Guillaume Nodet Assigned To: Guillaume Nodet Fix For: 3.1 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (SM-507) attribute dumpStats is ignored and Stats.csv not created / filled
[ https://issues.apache.org/activemq/browse/SM-507?page=all ] Guillaume Nodet resolved SM-507. Resolution: Cannot Reproduce I fixed SM-669. Stats dump seems to work fine for me, but stats are only dumped for standard jbi components, not lightweight components. attribute dumpStats is ignored and Stats.csv not created / filled - Key: SM-507 URL: https://issues.apache.org/activemq/browse/SM-507 Project: ServiceMix Issue Type: Bug Environment: ServiceMix 3.0M2, current trunk from SVN Reporter: Georg According to http://servicemix.org/site/management.html Stats.csv will be written if ServiceMix is configured to do so. In the basic example, servicemix.xml contains the attributes dumpStats=true statsInterval=10 so I assumed ServiceMix will dump statistics to a file. While running the example in the binary distribution incubating-servicemix-3.0-SNAPSHOT, I searched the whole hard drive but no .csv was found. So I did further reseach. When starting the quartz example of the current SVN snapshot from within eclipse in debugging mode, ServiceMix really reads the information from the servicemix.xml and org.apache.servicemix.jbi.container.EnvironmentContext.setDumpStats(boolean value) is called with value=true (so like it shall) but no csv is written to harddisk. I did not find the place in the source of servicemix where a Stats.csv is created/filled/appended. Moreover, the string Stats.csv cannot be found in any source file. How can one enable the dumping of statistic information to files? -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (SM-582) Current ErrorHandler implementation used by ValidateComponent is not thread safe
[ https://issues.apache.org/activemq/browse/SM-582?page=all ] Grant McDonald updated SM-582: -- Attachment: SM-582.patch Fixed mixed tabs/spaces in patch Current ErrorHandler implementation used by ValidateComponent is not thread safe Key: SM-582 URL: https://issues.apache.org/activemq/browse/SM-582 Project: ServiceMix Issue Type: Bug Components: servicemix-components Affects Versions: incubation Environment: Ubuntu Linux 6.06 LTS, WinXP SP2 Reporter: Grant McDonald Assigned To: Grant McDonald Attachments: SM-582.patch Original Estimate: 30 minutes Remaining Estimate: 30 minutes Due to the error handler being dependency injected it is a singleton which unfortunately stores state across invocations. The solution is to use the factory pattern, whereby an ErrorHandlerFactory implementation is created as the singleton which has properties containing the arguments to pass to the ErrorHandler when it is instantiated. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (SM-670) Including JMSFlow in default servicemix.conf
Including JMSFlow in default servicemix.conf Key: SM-670 URL: https://issues.apache.org/activemq/browse/SM-670 Project: ServiceMix Issue Type: Improvement Components: servicemix-assembly Affects Versions: 3.0 Environment: All Reporter: Jamie McCrindle It would be useful to have JMSFlow in addition to the SedaFlow and JCAFlow servicemix flows as part of the default install (SERVICEMIX_HOME/conf/servicemix.xml). That way third party components or applications that need to use synchronous remote exchanges can work out of the box. sm:jmsFlow jmsURL=tcp://localhost:61616 / -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Reopened: (SM-470) servicemix-http has no way to set a soap action
[ https://issues.apache.org/activemq/browse/SM-470?page=all ] satya sunkara reopened SM-470: -- 1) Soap action is needed for all the operations of a webservice. It is not possible to specify multiple soapactions ,if provided as an attribute. 2)localhost:8192/service/main.wsdl is not able to generate wsdl with proper soapaction URI even after specifying the value in xbean.xml It generates an empty soapaction attribute like the following wsdlsoap:operation soapAction= / Services running on .Net throws an error unrecognized soapaction when called from a proxy generated by using servicemix's main.wsdl. servicemix-http has no way to set a soap action --- Key: SM-470 URL: https://issues.apache.org/activemq/browse/SM-470 Project: ServiceMix Issue Type: Bug Components: servicemix-components Affects Versions: 3.0-M2 Reporter: Pete Assigned To: Guillaume Nodet Fix For: 3.0 When using servicemix-http we need to be able to set the soap action to a fixed value (well different for each web service) See http://www.nabble.com/SAAJMarshaller---soapfault-content-getting-removed-t1830872.html#a5002091 Currently, the only way is to set a property on the jbi message named javax.jbi.protocol.headers which should contain a map. All elements in this map will be added as http headers on the outgoing request. This JIRA is to add a way to configure the value of the soap action header directly on the deployed http endpoint. thanks Pete -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (SM-670) Including JMSFlow in default servicemix.conf
[ https://issues.apache.org/activemq/browse/SM-670?page=all ] Guillaume Nodet resolved SM-670. Fix Version/s: 3.1 Resolution: Fixed Assignee: Guillaume Nodet Author: gnodet Date: Wed Oct 4 06:50:36 2006 New Revision: 452889 URL: http://svn.apache.org/viewvc?view=revrev=452889 Log: SM-670: including JMSFlow in default servicemix config Modified: incubator/servicemix/trunk/apache-servicemix/src/main/release/conf/servicemix.xml Including JMSFlow in default servicemix.conf Key: SM-670 URL: https://issues.apache.org/activemq/browse/SM-670 Project: ServiceMix Issue Type: Improvement Components: servicemix-assembly Affects Versions: 3.0 Environment: All Reporter: Jamie McCrindle Assigned To: Guillaume Nodet Fix For: 3.1 It would be useful to have JMSFlow in addition to the SedaFlow and JCAFlow servicemix flows as part of the default install (SERVICEMIX_HOME/conf/servicemix.xml). That way third party components or applications that need to use synchronous remote exchanges can work out of the box. sm:jmsFlow jmsURL=tcp://localhost:61616 / -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (SM-675) MimeMailMarshaler supports multiple recipients but does not support multiple to, cc and bcc adresses
MimeMailMarshaler supports multiple recipients but does not support multiple to, cc and bcc adresses Key: SM-675 URL: https://issues.apache.org/activemq/browse/SM-675 Project: ServiceMix Issue Type: Improvement Components: servicemix-components Affects Versions: 3.0 Environment: windows xp java 1.5.0_08 eclipse 3.2.1 Reporter: Alper Sogukpinar Attachments: GtMimeMailMarshaler.java MimeMailMarshaler supports multiple recipients but does not support multiple to, cc and bcc adresses even java.mail.internet.MimeMessage supports multiple recipients its not supported in MimeMailMarshaler class. I wrote my own mail marshaller class which extends MimeMailMarshaler and supports multiple email recipients. Although my own marshaller has other differences than MimeMailMarshaler because of our own business needs, I send my code attached with the issue to make improvement more clear... -- 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: What is GShell?
On Oct 3, 2006, at 10:12 AM, Paul McMahan wrote: OK I should have guessed that windows was the culprit. I jumped over to debian and now all is fine. GShell looks very promising!! I love the idea of being able to telnet or ssh into the server and run commands remotely. As a matter of fact this appears to provide a vital improvement that Geronimo users have been asking for: the ability to remotely administer a running server (see the Swing console? thread from 9/17/2006). Yup, that is the general idea. :-) A few questions : - what's the security model? Mostly this is TBD. I plan on adding some sort of login context to allow users to login (for ssh this will be the ssh auth callback, for telnet it will have to be a custom login handler). Once credentials are established, then it should be possible to limit the set of commands that are enabled for a user. I am sure there is much more than can be done here too. But at the moment, I've only planned to get a simple login implemented and have not done much more design of a richer model. - will GShell share a common code path with the console and the CLI for handling things like deployment? Yes, well... yes for the CLI, as I hope to eventually replace the existing CLI tools with command plugins into gshell, so they will be one and the same. I am not really sure what the web console is doing, but we should definitely share as much as possible where possible. It should be possible to define a simple interface (or set o interfaces) for each admin bit in the console... and provide a portlet and gshell command (or set of commands) to adapt to the interface. I think this will be easy(ish) to do... more so once the webconsole is more xtensible/pluggbale, and when admin portlets are split up into modules that are specific to the function they provide. It certainly would be nice to have one-to-one mappings for admin functionality between the webconsole and gshell commands... but there is still work on both sides before that would be possible... but it is kind of a longer term goal. - which subsystems of geronimo will GShell depend on and how will it access them? e.g. will it be wrappered as a gbean and use the kernel to get access to them? mainly I'm wondering if (unlike the console) it will be able to administer components running in the server without a having a run-time dependency against them. Um, well I am in the process of writing a few simple GBeans to run/ manage the server components of GShell (the telnet/ssh server and the config and monitoring aspects that they bring in). Short of that there are no dependencies on Geronimo. I am thinking that a simple GBean to mange the start/stop of the server (ie, start/stop the telnet/ssh connector), which will manage the basic port config as well as the more advanced ssh config needed. And then a simple portlet to control the gbean, to list who is logged in, maybe even allow sessions to be terminated and such. May need to introduce some extra command sets which are G specific... or augment the script command to know more about the G namespace, so that we can register some more helpful variables to allow some meaningful/useful scripts to be written. But, so far these are just ideas in my head... some with TODO comments in code... I have not had enough time to get anymore significant work done on gshell after the initial flurry of code I dropped in over a week or so. I hope that once all this build muck is over and done with that I can get back into the GShell groove... clean it up and get it integrated into the server. Anyways... ideas and suggestions are welcome :-) --jason
Re: [jira] Commented: (GERONIMO-2393) Maven eclipse plugin is generating invalid classpath entries in .classpath
I recommend that you ask the users list and/or hop in #maven on irc.codehaus.org and ask them about it.It sounds like a problem with the eclipse maven plugin... or your environment. But either way, I recommend going to the source for more detailed help.--jasonOn Oct 3, 2006, at 10:59 PM, Vamsavardhana Reddy wrote:I have not asked the Maven folks. I use English-US locale. --vamsiOn 10/4/06, Jason Dillon [EMAIL PROTECTED] wrote: Have you asked the Maven folks about this?Is your system using a specific locale?--jason On Oct 3, 2006, at 10:30 PM, Vamsavardhana Reddy wrote:Running mvn eclipse:eclipse is not giving any errors. But the entries in .classpath have the first letter missing. VamsiOn 10/4/06, Jason Dillon [EMAIL PROTECTED] wrote: What is the exact error? Can can you run with -X to produce some debug output. --jasonOn Oct 3, 2006, at 10:24 PM, Vamsavardhana Reddy wrote: Can someone who is not facing this eclipse .classpath problem zip the .classpath files from their source tree and send it to my id [EMAIL PROTECTED] . Thanks, Vamsi On 10/4/06, Jason Dillon [EMAIL PROTECTED] wrote: I don't think that is the problem... as I can `mvn eclipse:eclipse` just fine and it downloads the maven-eclipse-plugin v2.2.Maybe some metadata in your local repo is corrupt? --jasonOn Oct 3, 2006, at 9:29 PM, Vamsavardhana Reddy wrote: How do I do that? Because of this classpath entry problem, I am really stranded in using Eclipse for development on G TRUNK. I will have to look for a work around, like getting this .classpath files from someone who is not seeing this problem and overwrite the ones I have. --vamsiOn 10/4/06, Jason Dillon [EMAIL PROTECTED] wrote: Configure a version for the eclipse plugin. --jasonOn Oct 3, 2006, at 8:52 PM, Vamsavardhana Reddy wrote: Has anyone else faced this problem with .classpath entries? See http://issues.apache.org/jira/browse/GERONIMO-2393 for details. Thanks, Vamsi On 10/4/06, Vamsavardhana Reddy (JIRA) dev@geronimo.apache.org wrote: [ http://issues.apache.org/jira/browse/GERONIMO-2393?page=comments#action_12439718 ]Vamsavardhana Reddy commented on GERONIMO-2393: ---Anita, I am getting the following error upon deleting .m2/o/a/maven/plugins/maven-eclipse-plugin and then running mvn eclipse:eclipse : [INFO] Scanning for projects... [INFO] Searching repository for plugin with prefix: 'eclipse'.[INFO] [ERROR] BUILD ERROR[INFO] [INFO] The plugin 'org.apache.maven.plugins:maven-eclipse-plugin' does not exist or no valid version could be found[INFO] [INFO] For more information, run Maven with the -e switch [INFO] [INFO] Total time: 1 second[INFO] Finished at: Wed Oct 04 09:14:34 IST 2006[INFO] Final Memory: 1M/2M[INFO] Maven eclipse plugin is generating invalid classpath entries in .classpath -- Key: GERONIMO-2393 URL: http://issues.apache.org/jira/browse/GERONIMO-2393 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: buildsystemAffects Versions: 1.2 Environment: WinXP, G TRUNKReporter: Vamsavardhana Reddy Fix For: 1.2 Attachments: .classpath, .classpath I have run mvn eclipse:eclipse. Upon importing the projects into eclipse, I am noticing the the classpath entries generated have the first letter missing. Here is an example of some classpath entries in .classpath file. classpathentry kind="var" path="M2_REPO/ommons-cli/commons-cli/1.0/commons-cli-1.0.jar"/ classpathentry kind="var" path="M2_REPO/tax/stax-api/1.0/stax- api-1.0.jar"/ classpathentry kind="var" path="M2_REPO/lassworlds/classworlds/1.1-alpha-2/classworlds-1.1-alpha-2.jar"/ classpathentry kind="var" path="M2_REPO/rg/apache/maven/maven-repository-metadata/2.0.4/maven- repository-metadata-2.0.4.jar"/--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: (SM-654) org.apache.servicemix.eip.PipelineTxTest
org.apache.servicemix.eip.PipelineTxTest Key: SM-654 URL: https://issues.apache.org/activemq/browse/SM-654 Project: ServiceMix Issue Type: Sub-task Components: servicemix-eip Affects Versions: incubation Reporter: Fritz Oconer -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (SM-653) org.apache.servicemix.eip.WireTapJmsFlowTest
org.apache.servicemix.eip.WireTapJmsFlowTest Key: SM-653 URL: https://issues.apache.org/activemq/browse/SM-653 Project: ServiceMix Issue Type: Sub-task Components: servicemix-eip Affects Versions: incubation Reporter: Fritz Oconer -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (SM-652) org.apache.servicemix.eip.StaticRoutingSlipTxTest
org.apache.servicemix.eip.StaticRoutingSlipTxTest - Key: SM-652 URL: https://issues.apache.org/activemq/browse/SM-652 Project: ServiceMix Issue Type: Sub-task Components: servicemix-eip Affects Versions: incubation Reporter: Fritz Oconer -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (SM-657) org.apache.servicemix.eip.MessageFilterTxTest
org.apache.servicemix.eip.MessageFilterTxTest - Key: SM-657 URL: https://issues.apache.org/activemq/browse/SM-657 Project: ServiceMix Issue Type: Sub-task Components: servicemix-eip Affects Versions: incubation Reporter: Fritz Oconer -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (SM-656) org.apache.servicemix.eip.StaticRecipientListTxTest
org.apache.servicemix.eip.StaticRecipientListTxTest --- Key: SM-656 URL: https://issues.apache.org/activemq/browse/SM-656 Project: ServiceMix Issue Type: Sub-task Components: servicemix-eip Affects Versions: incubation Reporter: Fritz Oconer -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (SM-655) org.apache.servicemix.eip.SplitAggregatorTxTest
org.apache.servicemix.eip.SplitAggregatorTxTest --- Key: SM-655 URL: https://issues.apache.org/activemq/browse/SM-655 Project: ServiceMix Issue Type: Sub-task Components: servicemix-eip Affects Versions: incubation Reporter: Fritz Oconer -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Fixing java.endorsed.dirs
Alan D. Cabrera wrote: On Sep 28, 2006, at 12:25 PM, Dain Sundstrom wrote: Anyway, this sucks, since it requires users to use a shell script to launch Geronimo. Is there anyway to detect the corba api version and not load the Yoko classes that have the problems? OT: in the future, if we used OSGi as a base, we would have a clean workaround for this problem, no? I'm not sure how OSGi would help with this. The functioning of java.endorsed.dirs is a base function of how the JVM works. There's not much other option to get around this. Regards, Alan
Re: CXF Geronimo Integration
Hi Dan, some comments below... On Tue, 2006-10-03 at 14:19 -0400, Dan Diephouse wrote: As I understand it, we would need to integrate CXF at two points. First, the deployment. We need to support JSR 109 deployment descriptors. Second, we need to support invoking EJBs. For deployment, we can wire in JSR 109 descriptors into the service construction. In CXF we have a Service, which holds a WSDL like service model and information about CXF can invoke the server (like databinding info, interceptors/handlers, etc). Generally you create a Service from a ServiceFactory [2][3]. The base service factory (ReflectionServiceFactoryBean) can actually construct the service from WSDL using the WSDLServiceFactory or from introspection. During this construction, ServiceConfigurations [4] can provide values for the service. There can be many of these. For instance, lets say we want to determine the namespace of the service. We can have a JaxWsServiceConfiguration which takes the namespace from the @WebService attribute. If there is no specified namespace, the service factory will move to the DefaultServiceConfiguration which will create a namespace from the package name. With that all said - its easy to envision how a Jsr109ServiceConfiguration could be created to override values in the JAX-WS attributes. I still don't know enough about JSR109 to say if this will be sufficient though - It would be good to come up with a list of areas that JSR 109 affects. I'm not overly familiar with CXF's service model stuff but this sounds reasonable. With JEE5 and Web Services 1.2, deployment descriptors optional so the CXF web service builder must be able to introspect the deployment archive and find suitably annotated classes. The second area - EJB invocation - is a bit simpler. In CXF we have the concept of Invokers [5][6]. Invokers allow you to control how your object is invoked. You can supply your own object, scopes, etc. XFire had an EJB invoker [7] which I think is similar to what needs to happen here (although I know jack about EJBs, so I could be wrong). While the Invoker interface in CXF is slightly different, all the same information is there. I did some work with the Geronimo Web Service container and Celtix 1.0, although that was with a WS endpoint implemented using a servlet. For the servlet case, the integration was done as a custom Celtix transport that sat atop the Geronimo web service container. The transport was G's but the bindings and dispatch were handled by Celtix. Currently with Geronimo, are EJBs invoked on through the same Web Service Container? If so, then CXF may need to adapt to the WS container as well as using the EJB invoker. If not, is the plan for CXF to supply the whole WS stack, including transport? And not forgetting support servlet endpoints. Are there other integration areas that I missed here? Anyone able to provide a more comprehensive view of what exactly we need to do in terms of JSR 109? On the client side, injection of @WebServiceRef annotations need to be supported. I guess this would come under some general resource injection framework for Geronimo, but CXF will need to be able to hook into it to provide proxies for the referenced services On the builder side of thing, I'll dust off the old Celtix one and see how out of date it is. rgds Conrad Cheers, - Dan 1. http://dev.rectang.com/logs/codehaus/%23cxf/20061001.html 2. http://fisheye3.cenqua.com/browse/celtixfire/trunk/rt/frontend/simple/src/main/java/org/apache/cxf/service/factory/ReflectionServiceFactoryBean.java?r=450267#l287 3. http://fisheye3.cenqua.com/browse/celtixfire/trunk/rt/frontend/jaxws/src/main/java/org/apache/cxf/jaxws/support/JaxWsServiceFactoryBean.java?r=450397 4. http://fisheye3.cenqua.com/browse/celtixfire/trunk/rt/frontend/simple/src/main/java/org/apache/cxf/service/factory/AbstractServiceConfiguration.java?r=450267 5. http://fisheye3.cenqua.com/browse/~raw,r=437862/celtixfire/trunk/api/src/main/java/org/apache/cxf/service/invoker/Invoker.java 6. http://fisheye3.cenqua.com/browse/celtixfire/trunk/rt/core/src/main/java/org/apache/cxf/service/invoker/AbstractInvoker.java?r=447027 7. http://xfire.codehaus.org/Invokers David Jencks wrote: I'm starting to look into jee5 webservices integration in geronimo. So far I've got as far as locating some of the specs and starting to read them :-). If anyone wants to help or take over aspects of this that would be great! Unfortunately I haven't been able to keep up with the dev lists for either axis or cxf so I'm not sure whether anyone has thought about this before nor how much of the appropriate specs are implemented already by either project. I have been pointed to a cxf geronimo builder, but haven't determined how out of date it is, as there have been quite a few builder changes in geronimo since the builder was written.
bootstrap build error in configs\rmi-naming
[INFO] Scanning for projects...
[INFO]
[INFO] Building Geronimo Configs :: RMI Naming
[INFO] task-segment: [install]
[INFO]
[INFO] [tools:require-java-version {execution: validate-java-version}]
[INFO] [tools:copy-legal-files {execution: install-legal-files}]
[INFO] [resources:resources]
[INFO] Using default encoding to copy filtered resources.
[INFO] [car:prepare-plan]
[INFO] Generated: G:\t\configs\rmi-naming\target\plan\plan.xml
[INFO] [car:package]
[INFO] Packaging module configuration: G:\t\configs\rmi-naming\target\plan\plan.xml
[ERROR] Deployment failed due to
org.apache.geronimo.gbean.InvalidConfigurationException: Could not load class org.apache.geronimo.gjndi.GlobalContextGBean
at org.apache.geronimo.gbean.GBeanInfo.getGBeanInfo(GBeanInfo.java:57)
at org.apache.geronimo.deployment.service.GBeanBuilder.addGBeanData(GBeanBuilder.java:109)
at org.apache.geronimo.deployment.service.GBeanBuilder.build(GBeanBuilder.java:99)
at org.apache.geronimo.deployment.service.GBeanBuilder$$FastClassByCGLIB$$65102f86.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:820)
at org.apache.geronimo.gbean.runtime.RawInvoker.invoke(RawInvoker.java:57)
at org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke(RawOperationInvoker.java:35)
at org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept(ProxyMethodInterceptor.java:96)
at org.apache.geronimo.deployment.NamespaceDrivenBuilder$$EnhancerByCGLIB$$9d724bee.build(generated)
at
org.apache.geronimo.deployment.NamespaceDrivenBuilderCollection.build(NamespaceDrivenBuilderCollection.java:82)
at
org.apache.geronimo.deployment.service.ServiceConfigBuilder.buildConfiguration(ServiceConfigBuilder.java:218)
at
org.apache.geronimo.deployment.service.ServiceConfigBuilder.buildConfiguration(ServiceConfigBuilder.java:177)
at
org.apache.geronimo.deployment.service.ServiceConfigBuilder$$FastClassByCGLIB$$9f173be6.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:820)
at org.apache.geronimo.gbean.runtime.RawInvoker.invoke(RawInvoker.java:57)
at org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke(RawOperationInvoker.java:35)
at org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept(ProxyMethodInterceptor.java:96)
at
org.apache.geronimo.deployment.ConfigurationBuilder$$EnhancerByCGLIB$$fd166ebf.buildConfiguration(generated)
at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:302)
at org.apache.geronimo.deployment.Deployer$$FastClassByCGLIB$$734a235d.invoke(generated)
at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53)
at org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38)
at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:122)
at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:855)
at org.apache.geronimo.kernel.basic.BasicKernel.invoke(BasicKernel.java:239)
at org.apache.geronimo.plugin.car.PackageMojo.invokeDeployer(PackageMojo.java:569)
at org.apache.geronimo.plugin.car.PackageMojo.buildPackage(PackageMojo.java:408)
at org.apache.geronimo.plugin.car.PackageMojo.doExecute(PackageMojo.java:245)
at org.apache.geronimo.genesis.MojoSupport.execute(MojoSupport.java:94)
at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:412)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:534)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:475)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:454)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:306)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:273)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:140)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:322)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:115)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:256)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
[jira] Created: (SM-664) org.apache.servicemix.http.HttpAddressingTest (Hangs)
org.apache.servicemix.http.HttpAddressingTest (Hangs) - Key: SM-664 URL: https://issues.apache.org/activemq/browse/SM-664 Project: ServiceMix Issue Type: Sub-task Components: servicemix-http Affects Versions: incubation Reporter: Fritz Oconer -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Priorities for 1.2
OpenJPA integration GShell integration Global JNDI Full Java 5 support More out of the box samples Thanks, Gianny On 03/10/2006, at 5:40 AM, Dain Sundstrom wrote: We have collected 14 features for 1.2 and now we need to prioritize them. The sorted list of features will help guide us in determining when to release based on how many high priority features we have completed. Please, sort the following list according to what *you* believe are the most important features to include in 1.2. It will help me tally the list if you simply reorder the list instead of putting numbers next to the features. Also, please *do not* attempt to give more than one feature the same priority. In such a case, I will give priority to the highest left-most item in your list. I will tally the results on Friday, October 6th. -dain OpenJPA integration Global JNDI Yoko ORB support Full Java 5 support JAF 1.1 GShell integration CMP improvements Console usability improvements Jetspeed integration More server modularization via plugins Console extensibility More out of the box samples OpenEJB 3.0 integration with @Stateless EJBs support Geronimo OSGi bundle
Re: [jira] Commented: (GERONIMO-2393) Maven eclipse plugin is generating invalid classpath entries in .classpath
Vamsi, I am attaching an eclipse.log generated by running mvn -o eclipse:eclipse on geronimo-tomcat module directory. Do you get the same output? Does the 'List of artifacts' have full names? If the .classpath file is corrupt, it has nothing to do with eclipse version. The problem occurs even before importing into eclipse. Which directory are you running the command from?ThanksAnita- Original Message From: Vamsavardhana Reddy [EMAIL PROTECTED]To: dev@geronimo.apache.orgSent: Wednesday, October 4, 2006 12:43:31 AMSubject: Re: [jira] Commented: (GERONIMO-2393) Maven eclipse plugin is generating invalid classpath entries in .classpathI tried that too after my last e-mail. It didn't help. Do you think it has anything to do with the eclipse version I have? I am using Version: 3.1.1 Build id: M20050929-0840 --vamsiOn 10/4/06, anita kulshreshtha [EMAIL PROTECTED] wrote: I just ran mvn -o eclipse:eclipse and it works fine. Did you delete .project and .classpath files? try deleting them in one of the modules and run mvn -o eclipse:eclipse. ThanksAnita- Original Message From: Vamsavardhana Reddy (JIRA) dev@geronimo.apache.orgTo: dev@geronimo.apache.orgSent: Wednesday, October 4, 2006 12:21:20 AMSubject: [jira] Commented: (GERONIMO-2393) Maven eclipse plugin is generating invalid classpath entries in .classpath [ http://issues.apache.org/jira/browse/GERONIMO-2393?page=comments#action_12439721 ] Vamsavardhana Reddy commented on GERONIMO-2393:---Anita, Ignore my previous comment.That error was due to something else.I re ran mvn eclipse:eclipse after deleting.m2/o/a/maven/plugins/maven-eclipse-plugin .I still see the same problem with entries in .classpath Maven eclipse plugin is generating invalid classpath entries in .classpath -- Key: GERONIMO-2393 URL: http://issues.apache.org/jira/browse/GERONIMO-2393 Project: GeronimoIssue Type: BugSecurity Level: public(Regular issues) Components: buildsystemAffects Versions: 1.2 Environment: WinXP, G TRUNK Reporter: Vamsavardhana Reddy Fix For: 1.2 Attachments: .classpath, .classpath I have run mvn eclipse:eclipse.Upon importing the projects into eclipse, I am noticing the the classpath entries generated have the first letter missing.Here is an example of some classpath entries in .classpath file. classpathentry kind="var" path="M2_REPO/ommons-cli/commons-cli/1.0/commons-cli-1.0.jar"/ classpathentry kind="var" path="M2_REPO/tax/stax-api/1.0/stax- api-1.0.jar"/ classpathentry kind="var" path="M2_REPO/lassworlds/classworlds/1.1-alpha-2/classworlds-1.1-alpha-2.jar"/ classpathentry kind="var" path="M2_REPO/rg/apache/maven/maven-repository-metadata/2.0.4/maven- repository-metadata-2.0.4.jar"/-- 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 eclipse.log Description: Binary data
Re: Another Geronimo Sample Is Ready
On 10/4/06, Lasantha Ranaweera [EMAIL PROTECTED] wrote: I can add this functionality to the console and provide it as a patch. What do u think? I think that sounds great! Seems like this would fit nicely as an additional item in the Actions column in the initial table that shows up in the database pools portlet, beside the current edit and usage actions. Or you might have something else in mind. Let me know if I can help. Best wishes, Paul
[jira] Commented: (SM-507) attribute dumpStats is ignored and Stats.csv not created / filled
[ https://issues.apache.org/activemq/browse/SM-507?page=comments#action_37094 ] Georg commented on SM-507: -- Confirming stats are written, bug resolved. I just did not find stats.csv as stats.cvs was created (see SM-669). attribute dumpStats is ignored and Stats.csv not created / filled - Key: SM-507 URL: https://issues.apache.org/activemq/browse/SM-507 Project: ServiceMix Issue Type: Bug Environment: ServiceMix 3.0M2, current trunk from SVN Reporter: Georg According to http://servicemix.org/site/management.html Stats.csv will be written if ServiceMix is configured to do so. In the basic example, servicemix.xml contains the attributes dumpStats=true statsInterval=10 so I assumed ServiceMix will dump statistics to a file. While running the example in the binary distribution incubating-servicemix-3.0-SNAPSHOT, I searched the whole hard drive but no .csv was found. So I did further reseach. When starting the quartz example of the current SVN snapshot from within eclipse in debugging mode, ServiceMix really reads the information from the servicemix.xml and org.apache.servicemix.jbi.container.EnvironmentContext.setDumpStats(boolean value) is called with value=true (so like it shall) but no csv is written to harddisk. I did not find the place in the source of servicemix where a Stats.csv is created/filled/appended. Moreover, the string Stats.csv cannot be found in any source file. How can one enable the dumping of statistic information to files? -- 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: [jira] Commented: (GERONIMO-2393) Maven eclipse plugin is generating invalid classpath entries in .classpath
Anita, Thanks for your help. I will check and reply. I have done a fresh checkout and bootstrap on a different machine. I notice the classpath entries created by mvn eclipse:eclipse are proper (even though the bootstrap was not successful). Looks like the problem is unique to my machine. I will investigate the same and report any findings. Regards, VamsiOn 10/4/06, anita kulshreshtha [EMAIL PROTECTED] wrote: Vamsi, I am attaching an eclipse.log generated by running mvn -o eclipse:eclipse on geronimo-tomcat module directory. Do you get the same output? Does the 'List of artifacts' have full names? If the .classpath file is corrupt, it has nothing to do with eclipse version. The problem occurs even before importing into eclipse. Which directory are you running the command from?ThanksAnita- Original Message From: Vamsavardhana Reddy [EMAIL PROTECTED]To: dev@geronimo.apache.orgSent: Wednesday, October 4, 2006 12:43:31 AMSubject: Re: [jira] Commented: (GERONIMO-2393) Maven eclipse plugin is generating invalid classpath entries in .classpathI tried that too after my last e-mail. It didn't help. Do you think it has anything to do with the eclipse version I have? I am using Version: 3.1.1 Build id: M20050929-0840 --vamsiOn 10/4/06, anita kulshreshtha [EMAIL PROTECTED] wrote: I just ran mvn -o eclipse:eclipse and it works fine. Did you delete .project and .classpath files? try deleting them in one of the modules and run mvn -o eclipse:eclipse. ThanksAnita- Original Message From: Vamsavardhana Reddy (JIRA) dev@geronimo.apache.orgTo: dev@geronimo.apache.orgSent: Wednesday, October 4, 2006 12:21:20 AMSubject: [jira] Commented: (GERONIMO-2393) Maven eclipse plugin is generating invalid classpath entries in .classpath [ http://issues.apache.org/jira/browse/GERONIMO-2393?page=comments#action_12439721 ] Vamsavardhana Reddy commented on GERONIMO-2393:---Anita, Ignore my previous comment.That error was due to something else.I re ran mvn eclipse:eclipse after deleting.m2/o/a/maven/plugins/maven-eclipse-plugin .I still see the same problem with entries in .classpath Maven eclipse plugin is generating invalid classpath entries in .classpath -- Key: GERONIMO-2393 URL: http://issues.apache.org/jira/browse/GERONIMO-2393 Project: GeronimoIssue Type: BugSecurity Level: public(Regular issues) Components: buildsystemAffects Versions: 1.2 Environment: WinXP, G TRUNK Reporter: Vamsavardhana Reddy Fix For: 1.2 Attachments: .classpath, .classpath I have run mvn eclipse:eclipse.Upon importing the projects into eclipse, I am noticing the the classpath entries generated have the first letter missing.Here is an example of some classpath entries in .classpath file. classpathentry kind=var path=M2_REPO/ommons-cli/commons-cli/1.0/commons-cli-1.0.jar/ classpathentry kind=var path=M2_REPO/tax/stax-api/1.0/stax- api-1.0.jar/ classpathentry kind=var path=M2_REPO/lassworlds/classworlds/1.1-alpha-2/classworlds-1.1-alpha-2.jar/ classpathentry kind=var path=M2_REPO/rg/apache/maven/maven-repository-metadata/2.0.4/maven- repository-metadata-2.0.4.jar/-- 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: http://geronimo.apache.org/plugins?
Great work Paul! I am very interested in getting the 1.2-SNAPSHOT cars published as well so that I can have a more standard way to deploy the tomcat, jetty, tomcat-deployer, and jetty-deployer plugins I created for Micro-G. So needs to be done to get the cars published for 1.2-SNAPSHOT and can I help? Joe Paul McMahan wrote: I added catalogs for the 1.1 and 1.1.1 plugins at http://geronimo.apache.org/plugins/. They point at the plugins hosted at http://repo1.maven.org/maven2/. I also added a catalog for the 1.2-SNAPSHOT plugins pointing at the snapshot repository http://people.apache.org/repo/m2-snapshot-repository/ This will start to work if/when the 1.2 snapshot configs get published. For anyone interested in the play-by-play :-) the next steps I had in mind are: - publish 1.2-SNAPSHOT configs so we can install plugins from geronimo's snapshot builds (need some guidance here on how to publish) - update config.xml to get the repository list from geronimo.apache.org as discussed in this thread: http://www.nabble.com/plugin-repository-list-URL-in-config.xml-tf2247272.html - figure out a way to generate the catalog during the build process - look into the idea Jason suggested for publishing the plugin catalogs directly in the repository Best wishes, Paul
Re: http://geronimo.apache.org/plugins?
On 10/4/06, Joe Bohn [EMAIL PROTECTED] wrote: So needs to be done to get the cars published for 1.2-SNAPSHOT and can I help? It might just involve uncommenting line 1246 of trunk/pom.xml so that the configs module is listed in the release environment. Then I suppose there are some manual steps to invoke mvn against that profile. But I don't know for sure. Perhaps someone with more knowledge about how the snapshot builds get published can advise. Paul
Re: Feedback from JAOO
On 10/4/06, Matt Hogstrom [EMAIL PROTECTED] wrote: The net result from my conversations was: Java 1.5 JEE 5.0 soon Simpler to use More activity on the website; it doesn't change enough. All what Matt wrote about the conference and our presentations about Apache Geronimo is true so I won't repeat it. What I wanted to stress is our visibility (aka PR). I had a couple of discussions with attendees about what they'd change to bring more attention to Apache Geronimo and they all mentioned about documentation and website updates. They need more not only about Geronimo itself, but some pages about how different technologies apply to Geronimo. As an example let's take GBeans, POJOs, Geronimo Kernel, XBean and Spring. They seem to be so similar that people who attended Geronimo session and OSGi one afterwards kept asking how it's different and why we're implementing something that we could re-use. Even though I could explain the existence of XBean and its way to simplify Spring configuration it wasn't easy to explain Geronimo Kernel with GBeans and OSGi. It seemed so similar to me that I keep scratching my head around it yet. I enjoy the conference and the ability to hear people's views on different aspects of Apache Geronimo development and open source projects in general. People seemed to be very interested in Geronimo. I can't explain what it was exactly (as they couldn't explain it to me and I didn't push too much), but I could feel they appreciated our efforts and collaboration. What I was really surprised with was to *not* hear much about JEE features. Well, people mentioned it, but that's it. It turns out that POJOs changed the expectations and as far as one can write a POJO and annotate/configure it somehow and it will (automagically) work they'll be happy. Of course, JEE-compliancy is important, but more documentation and website updates are yet more important. There were some comments about Geronimo's error message reporting that's not very helpful and fixing problems with applications using Apache Geronimo was not as easy as it should be. Aha, people expect v1.2 soon regardless of what it's going to provide. Just that it's available seems to be very important to many people and although features are highly appreciated, the better we polish what we've *already* got the merrier. Jacek -- Jacek Laskowski http://www.laskowski.net.pl
How do I get the configID from deploymentPlan?
I must be overlooking something but I'm having trouble using XMLBeans to get to the EnvironmentType for a given deployment plan.If I have...XmlObject xmlObject = XmlBeansUtil.parse(planFile.getLocation().toFile());from there if I cast to a particular DocumentType (WebAppDocument, etc..) there are no methods to get me to the EnvioronmentType..So I looked at the o.a.g.deployment.Deployer and in there... and what got me even more confused was the following code... There are only two implementations of ConfigurationBuilder, (ServiceConfigBuilder and EARConfigBuilder), so how is the configID being retrieved? Where is the getConfigurationID implementation for the other plan types?Object plan = null; ConfigurationBuilder builder = null; for (Iterator i = builders.iterator(); i.hasNext();) { ConfigurationBuilder candidate = (ConfigurationBuilder) i.next(); System.out.println("***" + candidate.getClass().getName()); plan = candidate.getDeploymentPlan(planFile, module, idBuilder); if (plan != null) { builder = candidate; break; } } if (builder == null) { throw new DeploymentException("Cannot deploy the requested application module because no deployer is able to handle it. " + " This can happen if you have omitted the J2EE deployment descriptor, disabled a deployer module, or if, for example, you are trying to deploy an" + " EJB module on a minimal Geronimo server that does not have EJB support installed. (" + (planFile == null ? "" : "planFile=" + planFile.getAbsolutePath()) + (moduleFile == null ? "" : (planFile == null ? "" : ", ") + "moduleFile=" + moduleFile.getAbsolutePath()) + ")"); } Artifact configID = builder.getConfigurationID(plan, module, idBuilder);Thanks-sachin
Re: http://geronimo.apache.org/plugins?
I attempted to use geronimo 1.1 and deploy the web console on little-G with this plugin repo. I hit some problems that I think are related to the information that is published (or not) in http://repo1.maven.org/maven2/ For both jetty and tomcat I received the following error on the server: 11:29:09,875 ERROR [PluginInstallerGBean] Cannot find plugin index at site http://geronimo.apache.org/1.1/repository/geronimo-plugins.xml # Installed configuration # id = geronimo/webconsole-tomcat/1.1/car # location = C:\g-images\1.1\tomcat-lg\geronimo-1.1\repository\geronimo\webconsole-tomcat\1.1\webconsole-tomcat-1.1.car # Installed configuration # id = geronimo/system-database/1.0/car # location = C:\g-images\1.1\tomcat-lg\geronimo-1.1\repository\geronimo\system-database\1.0\system-database-1.0.car 11:30:24,578 WARN [ConfigurationStoreUtil] Checksum file not found: C:\g-images\1.1\tomcat-lg\geronimo-1.1\repository\geronimo\system-database\1.0\system-datab ase-1.0.car\META-INF\config.ser.sha1 I'm not sure what the initial error is with finding the plugin index ... but it seems to continue and download the webconsole car in spite of it ... so I don't know if it's a real error or just a bogus message. After that it attempts to download the 1.0 system-database rather than the 1.1 version. I think this was the same problem that I originally had with geronimoplugins.com a while back. In that case Aaron updated the metadata on the geronimoplugins repo. The metadata in http://repo1.maven.org/maven2/geronimo/webconsole-jetty/ currently only references 1.0 (which is also the only version that includes a pom.xml in the repo). Am I correct in thinking that we need to get both the metadata updated and the poms published on the repo before this will work? Thanks, Joe Paul McMahan wrote: I added catalogs for the 1.1 and 1.1.1 plugins at http://geronimo.apache.org/plugins/. They point at the plugins hosted at http://repo1.maven.org/maven2/. I also added a catalog for the 1.2-SNAPSHOT plugins pointing at the snapshot repository http://people.apache.org/repo/m2-snapshot-repository/ This will start to work if/when the 1.2 snapshot configs get published. For anyone interested in the play-by-play :-) the next steps I had in mind are: - publish 1.2-SNAPSHOT configs so we can install plugins from geronimo's snapshot builds (need some guidance here on how to publish) - update config.xml to get the repository list from geronimo.apache.org as discussed in this thread: http://www.nabble.com/plugin-repository-list-URL-in-config.xml-tf2247272.html - figure out a way to generate the catalog during the build process - look into the idea Jason suggested for publishing the plugin catalogs directly in the repository Best wishes, Paul
Re: http://geronimo.apache.org/plugins?
Please ignore the initial error . I forgot that I typed the wrong URL on my first attempt and hence the error. If I knew how to make an emoticon that was blushing I would use it now. :-/ Joe Joe Bohn wrote: I attempted to use geronimo 1.1 and deploy the web console on little-G with this plugin repo. I hit some problems that I think are related to the information that is published (or not) in http://repo1.maven.org/maven2/ For both jetty and tomcat I received the following error on the server: 11:29:09,875 ERROR [PluginInstallerGBean] Cannot find plugin index at site http://geronimo.apache.org/1.1/repository/geronimo-plugins.xml # Installed configuration # id = geronimo/webconsole-tomcat/1.1/car # location = C:\g-images\1.1\tomcat-lg\geronimo-1.1\repository\geronimo\webconsole-tomcat\1.1\webconsole-tomcat-1.1.car # Installed configuration # id = geronimo/system-database/1.0/car # location = C:\g-images\1.1\tomcat-lg\geronimo-1.1\repository\geronimo\system-database\1.0\system-database-1.0.car 11:30:24,578 WARN [ConfigurationStoreUtil] Checksum file not found: C:\g-images\1.1\tomcat-lg\geronimo-1.1\repository\geronimo\system-database\1.0\system-datab ase-1.0.car\META-INF\config.ser.sha1 I'm not sure what the initial error is with finding the plugin index ... but it seems to continue and download the webconsole car in spite of it ... so I don't know if it's a real error or just a bogus message. After that it attempts to download the 1.0 system-database rather than the 1.1 version. I think this was the same problem that I originally had with geronimoplugins.com a while back. In that case Aaron updated the metadata on the geronimoplugins repo. The metadata in http://repo1.maven.org/maven2/geronimo/webconsole-jetty/ currently only references 1.0 (which is also the only version that includes a pom.xml in the repo). Am I correct in thinking that we need to get both the metadata updated and the poms published on the repo before this will work? Thanks, Joe Paul McMahan wrote: I added catalogs for the 1.1 and 1.1.1 plugins at http://geronimo.apache.org/plugins/. They point at the plugins hosted at http://repo1.maven.org/maven2/. I also added a catalog for the 1.2-SNAPSHOT plugins pointing at the snapshot repository http://people.apache.org/repo/m2-snapshot-repository/ This will start to work if/when the 1.2 snapshot configs get published. For anyone interested in the play-by-play :-) the next steps I had in mind are: - publish 1.2-SNAPSHOT configs so we can install plugins from geronimo's snapshot builds (need some guidance here on how to publish) - update config.xml to get the repository list from geronimo.apache.org as discussed in this thread: http://www.nabble.com/plugin-repository-list-URL-in-config.xml-tf2247272.html - figure out a way to generate the catalog during the build process - look into the idea Jason suggested for publishing the plugin catalogs directly in the repository Best wishes, Paul
[jira] Created: (GERONIMO-2465) Relocate plugin repository list to a source controlled location
Relocate plugin repository list to a source controlled location --- Key: GERONIMO-2465 URL: http://issues.apache.org/jira/browse/GERONIMO-2465 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Components: Plugins Affects Versions: 1.1.1, 1.1 Reporter: Paul McMahan Assigned To: Paul McMahan The default list of plugin repositories that gets loaded into the admin console currently comes from a user directory at people.apache.org. The list should be relocated to SVN so that it can be version controlled and updated by project committers. See discussion at: http://mail-archives.apache.org/mod_mbox/geronimo-dev/200609.mbox/[EMAIL PROTECTED] -- 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: Server is unrecoverable when keystore is locked
This is a known issue. GERONIMO-2234 You will have to edit config.xml to recover from the problem. --vamsi On 10/4/06, Huang Yonghong [EMAIL PROTECTED] wrote: Hi,I locked the keystore, and shut server down.When I restart the server, I got following error tellingme unlock it in console admin page ,then server bootingabort.But how can I access admin page while server is down? tcp://0.0.0.0:6161601:02:17,531 INFO[TransportConnector] Connectortcp://0.0.0.0:61616 Started01:02:17,578 INFO[TransportConnector] Connector vm://localhost Started01:02:17,609 INFO[TransportServerThreadSupport]Listening for connections at: stomp://GRIDCENS:6161301:02:17,609 INFO[TransportConnector] Connectorstomp://GRIDCENS:61613 Started [**] 42%35s Startingorg.apache.geronimo.c...01:02:23,343 WARN[SslListener]EXCEPTIONorg.apache.geronimo.management.geronimo.KeystoreIsLocked:Key 'geronimo' in keystore 'geronimo-default' is locked; please use the keystore page in the admin console to unlock itatorg.apache.geronimo.security.keystore.FileKeystoreManager.createSSLServerFactory(FileKeystoreManager.java:303)atorg.apache.geronimo.security.keystore.FileKeystoreManager$$FastClassByCGLIB$$4d9d2a71.invoke (generated)atnet.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53)atorg.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38)atorg.apache.geronimo.gbean.runtime.GBeanOperation.invoke (GBeanOperation.java:122)atorg.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:820)atorg.apache.geronimo.gbean.runtime.RawInvoker.invoke(RawInvoker.java:57)at org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke(RawOperationInvoker.java:35)atorg.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept(ProxyMethodInterceptor.java:96)at org.apache.geronimo.management.geronimo.KeystoreManager$$EnhancerByCGLIB$$34b2f051.createSSLServerFactory(generated)atorg.apache.geronimo.jetty.connector.GeronimoSSLListener.createFactory(GeronimoSSLListener.java :41)atorg.mortbay.http.SslListener.newServerSocket(SslListener.java:283)atorg.mortbay.util.ThreadedServer.open(ThreadedServer.java:477)atorg.apache.geronimo.jetty.connector.JettyConnector.doStart (JettyConnector.java:233)atorg.apache.geronimo.gbean.runtime.GBeanInstance.createInstance(GBeanInstance.java:984)atorg.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStart(GBeanInstanceState.java :267)atorg.apache.geronimo.gbean.runtime.GBeanInstanceState.start(GBeanInstanceState.java:102)atorg.apache.geronimo.gbean.runtime.GBeanInstance.start(GBeanInstance.java:529)at org.apache.geronimo.gbean.runtime.GBeanDependency.attemptFullStart(GBeanDependency.java:111)atorg.apache.geronimo.gbean.runtime.GBeanDependency.addTarget(GBeanDependency.java:146)atorg.apache.geronimo.gbean.runtime.GBeanDependency$1.running (GBeanDependency.java:120)atorg.apache.geronimo.kernel.basic.BasicLifecycleMonitor.fireRunningEvent(BasicLifecycleMonitor.java:173)atorg.apache.geronimo.kernel.basic.BasicLifecycleMonitor.access$300 (BasicLifecycleMonitor.java:41)atorg.apache.geronimo.kernel.basic.BasicLifecycleMonitor$RawLifecycleBroadcaster.fireRunningEvent(BasicLifecycleMonitor.java:251)atorg.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStart (GBeanInstanceState.java:292)atorg.apache.geronimo.gbean.runtime.GBeanInstanceState.start(GBeanInstanceState.java:102)atorg.apache.geronimo.gbean.runtime.GBeanInstance.start(GBeanInstance.java :529)atorg.apache.geronimo.gbean.runtime.GBeanDependency.attemptFullStart(GBeanDependency.java:111)atorg.apache.geronimo.gbean.runtime.GBeanDependency.addTarget(GBeanDependency.java:146) atorg.apache.geronimo.gbean.runtime.GBeanDependency$1.running(GBeanDependency.java:120)atorg.apache.geronimo.kernel.basic.BasicLifecycleMonitor.fireRunningEvent(BasicLifecycleMonitor.java:173) atorg.apache.geronimo.kernel.basic.BasicLifecycleMonitor.access$300(BasicLifecycleMonitor.java:41)atorg.apache.geronimo.kernel.basic.BasicLifecycleMonitor$RawLifecycleBroadcaster.fireRunningEvent (BasicLifecycleMonitor.java:251)atorg.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStart(GBeanInstanceState.java:292)atorg.apache.geronimo.gbean.runtime.GBeanInstanceState.start (GBeanInstanceState.java:102)atorg.apache.geronimo.gbean.runtime.GBeanInstanceState.startRecursive(GBeanInstanceState.java:124)atorg.apache.geronimo.gbean.runtime.GBeanInstance.startRecursive (GBeanInstance.java:543)atorg.apache.geronimo.kernel.basic.BasicKernel.startRecursiveGBean(BasicKernel.java:379)atorg.apache.geronimo.kernel.config.ConfigurationUtil.startConfigurationGBeans (ConfigurationUtil.java:374)atorg.apache.geronimo.kernel.config.KernelConfigurationManager.start(KernelConfigurationManager.java:187)atorg.apache.geronimo.kernel.config.SimpleConfigurationManager.startConfiguration
Re: How do I get the configID from deploymentPlan?
So though some debug, the configID is retrieved for all of J2EE is retreived from the EARConfigBuilder. But looks like there is alot of overhead involved in getting this. Is there a simple way I can get to the configID?On Oct 4, 2006, at 11:43 AM, Sachin Patel wrote:I must be overlooking something but I'm having trouble using XMLBeans to get to the EnvironmentType for a given deployment plan.If I have...XmlObject xmlObject = XmlBeansUtil.parse(planFile.getLocation().toFile());from there if I cast to a particular DocumentType (WebAppDocument, etc..) there are no methods to get me to the EnvioronmentType..So I looked at the o.a.g.deployment.Deployer and in there... and what got me even more confused was the following code... There are only two implementations of ConfigurationBuilder, (ServiceConfigBuilder and EARConfigBuilder), so how is the configID being retrieved? Where is the getConfigurationID implementation for the other plan types?Object plan = null; ConfigurationBuilder builder = null; for (Iterator i = builders.iterator(); i.hasNext();) { ConfigurationBuilder candidate = (ConfigurationBuilder) i.next(); System.out.println("***" + candidate.getClass().getName()); plan = candidate.getDeploymentPlan(planFile, module, idBuilder); if (plan != null) { builder = candidate; break; } } if (builder == null) { throw new DeploymentException("Cannot deploy the requested application module because no deployer is able to handle it. " + " This can happen if you have omitted the J2EE deployment descriptor, disabled a deployer module, or if, for example, you are trying to deploy an" + " EJB module on a minimal Geronimo server that does not have EJB support installed. (" + (planFile == null ? "" : "planFile=" + planFile.getAbsolutePath()) + (moduleFile == null ? "" : (planFile == null ? "" : ", ") + "moduleFile=" + moduleFile.getAbsolutePath()) + ")"); } Artifact configID = builder.getConfigurationID(plan, module, idBuilder);Thanks-sachin -sachin
Re: Release schedule
I put a post in the user forum for this, but thought I'd add something to this thread. I'm concerned about backward compatibility. I've got a test environment with all brokers at 4.0.1, except one I'm upgrading to 4.1. This would be how our production environment would be upgraded - a machine or so at a time. However, the 4.0.1 brokers will not connect to the 4.1 broker, giving the following exception: Exception in thread ActiveMQ Transport: tcp:///170.137.15.160:34695 java.lang.IllegalArgumentException: Invalid version: 2, could not l oad org.apache.activemq.openwire.v2.MarshallerFactory at org.apache.activemq.openwire.OpenWireFormat.setVersion(OpenWireFormat.java:329) at org.apache.activemq.openwire.OpenWireFormat.renegociatWireFormat(OpenWireFormat.java:569) at org.apache.activemq.transport.WireFormatNegotiator.onCommand(WireFormatNegotiator.java:100) at org.apache.activemq.transport.InactivityMonitor.onCommand(InactivityMonitor.java:122) at org.apache.activemq.transport.TransportSupport.doConsume(TransportSupport.java:87) at org.apache.activemq.transport.tcp.TcpTransport.run(TcpTransport.java:143) at java.lang.Thread.run(Thread.java:595) Caused by: java.lang.ClassNotFoundException: org.apache.activemq.openwire.v2.MarshallerFactory at org.apache.activemq.util.ClassLoading.loadClass(ClassLoading.java:104) at org.apache.activemq.openwire.OpenWireFormat.setVersion(OpenWireFormat.java:327) ... 6 more There must be an upgrade path for 4.1. If that means I have to go to 4.0.2 (which I did not try yet), that is OK. But, I can't possibly tell my management that I have to upgrade the AMQ version on all 50 or so machines we have in production. Hiram Chirino wrote: I'm starting to work on the first release candidate for 4.1.. please let me know if I should hold off! On 10/3/06, Vadim Pesochinsky [EMAIL PROTECTED] wrote: Hi James, It looks like this is changed now with 4.0.3. Any idea when 4.1 is going to be out? Thanks. -- View this message in context: http://www.nabble.com/Release-schedule-tf2124265.html#a6630219 Sent from the ActiveMQ - Dev mailing list archive at Nabble.com. -- Regards, Hiram Blog: http://hiramchirino.com -- View this message in context: http://www.nabble.com/Release-schedule-tf2124265.html#a6643855 Sent from the ActiveMQ - Dev mailing list archive at Nabble.com.
[jira] Resolved: (GERONIMO-2353) Reduce the number of places where CORBA config parameters are specified.
[ http://issues.apache.org/jira/browse/GERONIMO-2353?page=all ] Rick McGuire resolved GERONIMO-2353. Resolution: Fixed Resolved by changes committed under GERONIMO-2180. Reduce the number of places where CORBA config parameters are specified. Key: GERONIMO-2353 URL: http://issues.apache.org/jira/browse/GERONIMO-2353 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: CORBA Affects Versions: 1.2 Reporter: Rick McGuire Assigned To: Rick McGuire Fix For: 1.2 The CORBA configuration situation is a bit of a mess currently, with information scattered over multiple locations. Much of this information is ORB implementation specific, which makes it very difficult to switch between ORBs. For example, various CORBABean configurations manage bits of the ORB configuration using: 1) The name of an ORB config adapter class. 2) ORB.init() properties specified on the CorbaBean declaration 3) ORB.init() arguments specified on the 4) CORBASystemProperties values that must be set in System.properties before initializing the ORB. 2), 3), and 4) above are values that are handled in a non-portable fashion, and are scattered over seemingly unreleated portions of the configs. A better solution would be to have GBeans that encapsulate the knowledge about what ORB is going to be used as the server and pull these pieces together into a simple GBean declaration, which would make it much easier to switch between ORB implementations. The ORB config adapter seems tailor made for this. It just needs to be turned into a GBean rather than a classname argument to CorbaBean and CSSBean. -- 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: (SM-673) Simplify classloader definition for xbean based SU
Simplify classloader definition for xbean based SU -- Key: SM-673 URL: https://issues.apache.org/activemq/browse/SM-673 Project: ServiceMix Issue Type: New Feature Components: servicemix-common Affects Versions: 3.0 Reporter: Guillaume Nodet Fix For: 3.1 In 3.0, you can create a classloader for an xbean based SU by adding a classpath / tag inside the xbean.xml This is great, but need to be done manually. So the xbean SU should 1) classpath tag in xbean.xml 2) classpath.xml in the root of the SU 3) SU folder + lib/*.jar -- 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
Spec versioning
I'd like to reach conclusion on the spec versioning policy this week, so I spent an hour attempting to fairly summarize the two main spec versioning proposals: one version and version per spec. My summary can be found here: http://cwiki.apache.org/confluence/display/GMOxDEV/ Spec+Versioning I propose that we spend a day updating the summary of the options and possibly adding more proposals (like David's proposal), and tomorrow we vote on which procedure to choose for the specs. Please, do not sandbag a proposal you are against or unfairly pump up the one you are for as this will only delay this decision. Please participate early, so we can get this bikeshed behind us, -dain
The specs version question (again)
I'm afraid I've lost the thread on the discussion about what to do with specs. Has this been resolved? I'm asking because I found a few minutes today to implement the JAF-1.1 specs module. Should I hold off before checking this in? Rick
Re: The specs version question (again)
On Oct 4, 2006, at 10:48 AM, Rick McGuire wrote: I'm afraid I've lost the thread on the discussion about what to do with specs. Has this been resolved? I'm asking because I found a few minutes today to implement the JAF-1.1 specs module. Should I hold off before checking this in? Definitely check it in. Whatever we decide on the versioning thing is unrelated. -David
[jira] Created: (GERONIMO-2466) Add a new Java Activation Framework 1.1 implementation.
Add a new Java Activation Framework 1.1 implementation. --- Key: GERONIMO-2466 URL: http://issues.apache.org/jira/browse/GERONIMO-2466 Project: Geronimo Issue Type: New Feature Security Level: public (Regular issues) Components: specs Affects Versions: 1.2 Reporter: Rick McGuire Assigned To: Rick McGuire Fix For: 1.2 There's an updated 1.1 version of the Java Activation Framework which will be needed for j2ee 5 certification. -- 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: (SM-674) jbi:installComponent (and others) fails authentication against default SM container
jbi:installComponent (and others) fails authentication against default SM container --- Key: SM-674 URL: https://issues.apache.org/activemq/browse/SM-674 Project: ServiceMix Issue Type: Bug Components: tooling Affects Versions: 3.0 Environment: Java 1.5, Windows XP SP2 Reporter: Jamie McCrindle Fix For: 3.1 When running the jbi:installComponent maven task to install a component into a running SM 3.0 container, it fails with an Authentication failed User not found message. Debug from maven as follows: [DEBUG] Configuring mojo 'org.apache.servicemix.tooling:jbi-maven-plugin:3.0-inc ubating:installComponent' -- [DEBUG] -- end configuration -- [INFO] [jbi:installComponent] installComponent: [echo] Installing C:\dev\component-mvn\component-task-jbi\target/component- task-jbi-1.0-beta2-SNAPSHOT-installer.zip to service:jmx:rmi:///jndi/rmi://local host:1099/jmxrmi [installComponent] Error accessing ServiceMix administration: Authentication fai led [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Failed to execute: Executing Ant script: /jbi.build.xml [installComponent ]: Failed to execute. User does not exist [INFO] [DEBUG] Trace org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute: Execu ting Ant script: /jbi.build.xml [installComponent]: Failed to execute. at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(Defa ultLifecycleExecutor.java:559) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandalone Goal(DefaultLifecycleExecutor.java:488) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(Defau ltLifecycleExecutor.java:458) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHan dleFailures(DefaultLifecycleExecutor.java:306) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegmen ts(DefaultLifecycleExecutor.java:273) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLi fecycleExecutor.java:140) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:322) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:115) at org.apache.maven.cli.MavenCli.main(MavenCli.java:256) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl. java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces sorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) at org.codehaus.classworlds.Launcher.main(Launcher.java:375) Caused by: org.apache.maven.plugin.MojoExecutionException: Failed to execute: Ex ecuting Ant script: /jbi.build.xml [installComponent]: Failed to execute. at org.apache.maven.script.ant.AntMojoWrapper.execute(AntMojoWrapper.jav a:37) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPlugi nManager.java:412) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(Defa ultLifecycleExecutor.java:534) ... 16 more Caused by: org.codehaus.plexus.component.factory.ant.AntComponentExecutionExcept ion: Executing Ant script: /jbi.build.xml [installComponent]: Failed to execute. at org.codehaus.plexus.component.factory.ant.AntScriptInvoker.invoke(Ant ScriptInvoker.java:227) at org.apache.maven.script.ant.AntMojoWrapper.execute(AntMojoWrapper.jav a:33) ... 18 more Caused by: C:\DOCUME~1\JamesM\LOCALS~1\Temp\plexus-ant-component30723.build.xml: 30: Error accessing ServiceMix administration at org.apache.servicemix.jbi.management.task.JbiTask.execute(JbiTask.jav a:272) at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:275) at org.apache.tools.ant.Task.perform(Task.java:364) at org.apache.tools.ant.Target.execute(Target.java:341) at org.apache.tools.ant.Target.performTasks(Target.java:369) at org.apache.tools.ant.Project.executeSortedTargets(Project.java:1216) at org.apache.tools.ant.Project.executeTarget(Project.java:1185) at org.codehaus.plexus.component.factory.ant.AntScriptInvoker.invoke(Ant ScriptInvoker.java:222) ... 19 more Caused by: java.lang.SecurityException: Authentication failed at org.apache.servicemix.jbi.jmx.JaasAuthenticator.authenticate(JaasAuth
Separate client/server packages...
Is there a way to generate a light weight clientside package (without any broker specifics) when a version is released ? -- View this message in context: http://www.nabble.com/Separate-client-server-packages...-tf2384020.html#a6645013 Sent from the ActiveMQ - Dev mailing list archive at Nabble.com.
[jira] Resolved: (SM-674) jbi:installComponent (and others) fails authentication against default SM container
[ https://issues.apache.org/activemq/browse/SM-674?page=all ] Philip Dodds resolved SM-674. - Resolution: Fixed The problem was the lack of defaulting in the ANT tasks , this has been switched so that default username, passwords are smx/smx. Note that for 3.0 you can simply add username,password as configuration parameters in the jbi-maven-plugin to get the logins to work. jbi:installComponent (and others) fails authentication against default SM container --- Key: SM-674 URL: https://issues.apache.org/activemq/browse/SM-674 Project: ServiceMix Issue Type: Bug Components: tooling Affects Versions: 3.0 Environment: Java 1.5, Windows XP SP2 Reporter: Jamie McCrindle Fix For: 3.0.1, 3.1 When running the jbi:installComponent maven task to install a component into a running SM 3.0 container, it fails with an Authentication failed User not found message. Debug from maven as follows: [DEBUG] Configuring mojo 'org.apache.servicemix.tooling:jbi-maven-plugin:3.0-inc ubating:installComponent' -- [DEBUG] -- end configuration -- [INFO] [jbi:installComponent] installComponent: [echo] Installing C:\dev\component-mvn\component-task-jbi\target/component- task-jbi-1.0-beta2-SNAPSHOT-installer.zip to service:jmx:rmi:///jndi/rmi://local host:1099/jmxrmi [installComponent] Error accessing ServiceMix administration: Authentication fai led [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Failed to execute: Executing Ant script: /jbi.build.xml [installComponent ]: Failed to execute. User does not exist [INFO] [DEBUG] Trace org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute: Execu ting Ant script: /jbi.build.xml [installComponent]: Failed to execute. at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(Defa ultLifecycleExecutor.java:559) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandalone Goal(DefaultLifecycleExecutor.java:488) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(Defau ltLifecycleExecutor.java:458) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHan dleFailures(DefaultLifecycleExecutor.java:306) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegmen ts(DefaultLifecycleExecutor.java:273) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLi fecycleExecutor.java:140) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:322) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:115) at org.apache.maven.cli.MavenCli.main(MavenCli.java:256) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl. java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces sorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) at org.codehaus.classworlds.Launcher.main(Launcher.java:375) Caused by: org.apache.maven.plugin.MojoExecutionException: Failed to execute: Ex ecuting Ant script: /jbi.build.xml [installComponent]: Failed to execute. at org.apache.maven.script.ant.AntMojoWrapper.execute(AntMojoWrapper.jav a:37) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPlugi nManager.java:412) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(Defa ultLifecycleExecutor.java:534) ... 16 more Caused by: org.codehaus.plexus.component.factory.ant.AntComponentExecutionExcept ion: Executing Ant script: /jbi.build.xml [installComponent]: Failed to execute. at org.codehaus.plexus.component.factory.ant.AntScriptInvoker.invoke(Ant ScriptInvoker.java:227) at org.apache.maven.script.ant.AntMojoWrapper.execute(AntMojoWrapper.jav a:33) ... 18 more Caused by: C:\DOCUME~1\JamesM\LOCALS~1\Temp\plexus-ant-component30723.build.xml: 30: Error accessing ServiceMix administration at org.apache.servicemix.jbi.management.task.JbiTask.execute(JbiTask.jav a:272) at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:275) at org.apache.tools.ant.Task.perform(Task.java:364)
Uh oh...what was I doing in Denmark
Ok, I got back to my hotel room and started to work...I turned on the TV and Armageddon was on. The soundtrack was in English and the subtitles in Danish. When someone said dial 911...the screen said (something in danish) 112. Oh, I'm not a Lawyer (IANAL) or an EMT so check your local listings :) Just interesting :) Matt Hogstrom [EMAIL PROTECTED]
Re: svn commit: r452927 - /geronimo/server/trunk/pom.xml
I think maven needs to fix this problem in general... I was thinking about suggesting they add dependencyGroups to dependencies, which can be used to share config between dependencies: dependencyManagement dependencyGroups dependencyGroup groupIdorg.apache.openejb/groupId version2.2-incubating-SNAPSHOT/version dependencies dependency artifactIdopenejb-core/artifactId /dependency dependency artifactIdopenejb-builder/artifactId /dependency dependency artifactIdopenejb-pkgen-builder/artifactId /dependency dependency artifactIdopenejb-yoko/artifactId /dependency dependency artifactIdopenejb-sunorb/artifactId /dependency /dependencies /dependencyGroups /dependencyGroups /dependencyManagement Dunno about the exact syntax, but the general idea is to allow more config to be shared between deps. --jason On Oct 4, 2006, at 11:38 AM, Dain Sundstrom wrote: On Oct 4, 2006, at 11:13 AM, Jason Dillon wrote: I have been trying to remove the need for all of those properties. I think a few of these are fine... just as long as those properties are never used in child modules. But most people copy past the deps, so these properties are bound to leak. I agree but the alternative is some pretty ugly perl code to find the correct version numbers to change. -dain
Re: Help w/GShell GBean
Sounds good. Probably want to add a JIRA to migrate it to 1.2 so we don't forget. --jason On Oct 4, 2006, at 12:17 PM, Aaron Mulder wrote: On 10/4/06, Jason Dillon [EMAIL PROTECTED] wrote: Why not just add a new plugin-support module to server/trunk for now? The code I have at present works in Geronimo 1.1.x. I can check it into the 1.1 branch and whoever gets around to making it work in trunk can migrate it to trunk, I guess. Once it's in the repo we can svn move it wherever we need, eh? Thanks, Aaron On Oct 2, 2006, at 7:28 AM, Aaron Mulder wrote: It will be easier once I put in the plugin utils code -- do you have a thought on the SVN location for that? It'll include the GBean used to install a screen into the console. Then I can check it in and give you an example. Thanks, Aaron On 10/2/06, Jason Dillon [EMAIL PROTECTED] wrote: Do you (Aaron) have a simple example of how to implement a new bit to stuff into the webconsole and tickle it to be installed when a module/ plugin is loaded? --jason On Jun 24, 2006, at 4:16 AM, Aaron Mulder wrote: So to get a GBean running in Geronimo, you need to write a deployment plan for it. If you look at the advanced plugin sample under Geronimo Deployment Plan, you'll see an example. The plan should have a dependency element for any server module that must be running in order for the GBean to work correctly (if it has none, you're essentially saying that this module can run in a server with literally nothing else running). In the example, it requires rmi-naming which is the 2nd root-most module in the hierarchy (after j2ee-system). It should also have a dependency element for each external JAR that the GBean requires. In the example it depends on the Quartz JAR. This is how you should list all JAR dependencies. (Normally any Geronimo JAR dependencies are taken care of by the JARs used by the parent server modules, which are also added to the classpath, but you can list them individually if you like). Then you create a gbean element like the one in the example but with your class, a unique name of your choosing, and a port attribute for your GBean (doesn't look like yours uses any references). To deploy this, you can package the plan into a JAR with the GBean classes (put the plan at META-INF/geronimo-service.xml), keep it as a separate file alongside the JAR with the GBean classes, or if all the GBean classes are in the JARs you listed as dependencies, you can just deploy the plan standalone with no JAR. The normal deploy tool (or console deploy tool or Maven deploy plugin or etc.) will take the JAR-including-plan, JAR-with-separate-plan, or plan-only as arguments and deploy your service. Before it will deploy, you'll need to manually install all the dependency JARs into the repository, either by manual mkdir and file copying, or using the common libraries screen in the console. Once you get the GBean running, ping this thread again and we can get it packaged as a plugin, which will mean the dependency JARs will be downloaded and installed automatically and things like that. Thanks, Aaron On 6/23/06, Jason Dillon [EMAIL PROTECTED] wrote: Can someone help explain what I need to do to get a GBean installed for GShell? I've looked over some of the other GBeans and created: http://svn.apache.org/repos/asf/geronimo/sandbox/gshell/ trunk/ gshell-server/gshell-server-gbean/src/main/java/org/apache/ geronimo/ gshell/server/gbean/ShellServerDaemonGBean.java I think this code is okay, but any advise would be helpful. I've also looked over the Advanced Plugin Sample: http://wiki.apache.org/geronimo/Advanced_Plugin_Sample But I am not sure how relevant any of this is. There are a hand full of jars that need to be installed, and it would be nice to not have to have users manually install them. I'm looking for the best way to make it simple to install this component, which will allow (at the moment) Telnet-based access to a GShell running inside of Geronimo. I'd also like to add a new portlet to display some stats (like active shells) or to configure the port number and restart the component. Can someone drops some knowledge and/or point me at the latest relevant docs? Thanks, --jason
Re: Uh oh...what was I doing in Denmark
On Oct 4, 2006, at 11:47 AM, Matt Hogstrom wrote: Ok, I got back to my hotel room and started to work...I turned on the TV and Armageddon was on. The soundtrack was in English and the subtitles in Danish. When someone said dial 911...the screen said (something in danish) 112. Oh, I'm not a Lawyer (IANAL) or an EMT so check your local listings :) Just interesting :) /me mumbles something about jet lag...
Re: Uh oh...what was I doing in Denmark
Alan D. Cabrera wrote: On Oct 4, 2006, at 11:47 AM, Matt Hogstrom wrote: Ok, I got back to my hotel room and started to work...I turned on the TV and Armageddon was on. The soundtrack was in English and the subtitles in Danish. When someone said dial 911...the screen said (something in danish) 112. Oh, I'm not a Lawyer (IANAL) or an EMT so check your local listings :) Just interesting :) /me mumbles something about jet lag... ROFL
Re: Fixing java.endorsed.dirs
On Oct 4, 2006, at 1:53 AM, Rick McGuire wrote: Alan D. Cabrera wrote: On Sep 28, 2006, at 12:25 PM, Dain Sundstrom wrote: Anyway, this sucks, since it requires users to use a shell script to launch Geronimo. Is there anyway to detect the corba api version and not load the Yoko classes that have the problems? OT: in the future, if we used OSGi as a base, we would have a clean workaround for this problem, no? I'm not sure how OSGi would help with this. The functioning of java.endorsed.dirs is a base function of how the JVM works. There's not much other option to get around this. IIUC, you can eclipse JVM classes with your own. Do I have it wrong? Regards, Alan
Re: Fixing java.endorsed.dirs
I think this would only work if the JVM was based on OSGI... --jason On Oct 4, 2006, at 12:39 PM, Alan D. Cabrera wrote: On Oct 4, 2006, at 1:53 AM, Rick McGuire wrote: Alan D. Cabrera wrote: On Sep 28, 2006, at 12:25 PM, Dain Sundstrom wrote: Anyway, this sucks, since it requires users to use a shell script to launch Geronimo. Is there anyway to detect the corba api version and not load the Yoko classes that have the problems? OT: in the future, if we used OSGi as a base, we would have a clean workaround for this problem, no? I'm not sure how OSGi would help with this. The functioning of java.endorsed.dirs is a base function of how the JVM works. There's not much other option to get around this. IIUC, you can eclipse JVM classes with your own. Do I have it wrong? Regards, Alan
Re: Geronimo Release Roadmap
Hernan, Dain and I are working off of http://cwiki.apache.org/GMOxDEV/ priorities-12.html. I prefer that there be a single source for this kind of information and since Dain and I are working with the pointy end of the stick, let's use our page. The general roadmap feature set that you have is useful. I'd like to keep the resource commitments on the above page. Regards, Alan On Sep 28, 2006, at 11:14 AM, Hernan Cunico wrote: Yeah, tricky column. Should we have a separate release roadmap page for each release? With some exceptions the Target Release column just shows 1.2. I added 1.1.1 because most of the doc is completed after the software is released. I am currently working on v1.1 and v1.1.1 doc and hope to have as a minimum those features also covered in the upcoming release. I see several folks updating the Person working on the function column already. ;-) BTW, adding some comments during the page update may help a lot ( thanks Jacek ;-) ) Probably Dain and/or Alan ( being the release managers ) would have some thoughts as of how to have this list better organized. Cheers! Hernan Paul McMahan wrote: Thanks Hernan. I put my name next to some items. I wasn't sure how to determine the target release, though. I'm assuming that column will undergo some refinement. Best wishes, Paul On 9/26/06, Hernan Cunico [EMAIL PROTECTED] wrote: Hi All, I just updated the release roadmap with some doc stuff and put my name on it. http://cwiki.apache.org/GMOxPMGT/geronimo-release-roadmap.html Pls chime in and put your name too. Cheers! Hernan
[jira] Commented: (SM-674) jbi:installComponent (and others) fails authentication against default SM container
[ https://issues.apache.org/activemq/browse/SM-674?page=comments#action_37099 ] Jamie McCrindle commented on SM-674: tried setting the username / password but they're configured as readonly in the jbi.mojo.xml (in fact, almost everything is configured as readonly). am i doing it wrong? jbi:installComponent (and others) fails authentication against default SM container --- Key: SM-674 URL: https://issues.apache.org/activemq/browse/SM-674 Project: ServiceMix Issue Type: Bug Components: tooling Affects Versions: 3.0 Environment: Java 1.5, Windows XP SP2 Reporter: Jamie McCrindle Fix For: 3.0.1, 3.1 When running the jbi:installComponent maven task to install a component into a running SM 3.0 container, it fails with an Authentication failed User not found message. Debug from maven as follows: [DEBUG] Configuring mojo 'org.apache.servicemix.tooling:jbi-maven-plugin:3.0-inc ubating:installComponent' -- [DEBUG] -- end configuration -- [INFO] [jbi:installComponent] installComponent: [echo] Installing C:\dev\component-mvn\component-task-jbi\target/component- task-jbi-1.0-beta2-SNAPSHOT-installer.zip to service:jmx:rmi:///jndi/rmi://local host:1099/jmxrmi [installComponent] Error accessing ServiceMix administration: Authentication fai led [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Failed to execute: Executing Ant script: /jbi.build.xml [installComponent ]: Failed to execute. User does not exist [INFO] [DEBUG] Trace org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute: Execu ting Ant script: /jbi.build.xml [installComponent]: Failed to execute. at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(Defa ultLifecycleExecutor.java:559) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandalone Goal(DefaultLifecycleExecutor.java:488) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(Defau ltLifecycleExecutor.java:458) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHan dleFailures(DefaultLifecycleExecutor.java:306) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegmen ts(DefaultLifecycleExecutor.java:273) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLi fecycleExecutor.java:140) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:322) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:115) at org.apache.maven.cli.MavenCli.main(MavenCli.java:256) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl. java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces sorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) at org.codehaus.classworlds.Launcher.main(Launcher.java:375) Caused by: org.apache.maven.plugin.MojoExecutionException: Failed to execute: Ex ecuting Ant script: /jbi.build.xml [installComponent]: Failed to execute. at org.apache.maven.script.ant.AntMojoWrapper.execute(AntMojoWrapper.jav a:37) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPlugi nManager.java:412) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(Defa ultLifecycleExecutor.java:534) ... 16 more Caused by: org.codehaus.plexus.component.factory.ant.AntComponentExecutionExcept ion: Executing Ant script: /jbi.build.xml [installComponent]: Failed to execute. at org.codehaus.plexus.component.factory.ant.AntScriptInvoker.invoke(Ant ScriptInvoker.java:227) at org.apache.maven.script.ant.AntMojoWrapper.execute(AntMojoWrapper.jav a:33) ... 18 more Caused by: C:\DOCUME~1\JamesM\LOCALS~1\Temp\plexus-ant-component30723.build.xml: 30: Error accessing ServiceMix administration at org.apache.servicemix.jbi.management.task.JbiTask.execute(JbiTask.jav a:272) at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:275) at org.apache.tools.ant.Task.perform(Task.java:364) at org.apache.tools.ant.Target.execute(Target.java:341) at
[jira] Commented: (GERONIMO-2458) MapEditor does not work
[
http://issues.apache.org/jira/browse/GERONIMO-2458?page=comments#action_12439953
]
Jason Dillon commented on GERONIMO-2458:
Why not just change MapEditor to extend from PropertiesEditor?
MapEditor does not work
---
Key: GERONIMO-2458
URL: http://issues.apache.org/jira/browse/GERONIMO-2458
Project: Geronimo
Issue Type: Bug
Security Level: public(Regular issues)
Components: common
Affects Versions: 1.2, 1.1.1
Environment: 1.2-SNAPSHOT
Reporter: Vamsavardhana Reddy
Fix For: 1.2, 1.1.2
Attachments: GERONIMO-2458.patch
MapEditor.getAsText() is returning map.toString() which is not in sync with
setAsText() that expects input in the form name1=value1 on separate lines.
Bottom line...
MapEditor.getAsText() returns
{name1=value1, name2=value2}
where as MapEditor.setAsText() expects
name1=value1
name=value2
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (GERONIMO-2464) Remove overloaded maven scope from CAR plugin
[ http://issues.apache.org/jira/browse/GERONIMO-2464?page=comments#action_12439957 ] Jason Dillon commented on GERONIMO-2464: Possible solution is to provide optional configuration in the car plugin that maps a dependency artifact to the Geronimo import type. This allows the normal maven dependency resolution/ordering mechanism to be used... and allows for a cleaner method to augment the dependency with some extra information. Unless... there is a better way to annotate a dependency with custom elements.. ? Remove overloaded maven scope from CAR plugin - Key: GERONIMO-2464 URL: http://issues.apache.org/jira/browse/GERONIMO-2464 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: buildsystem Affects Versions: 1.2 Reporter: Jason Dillon Assigned To: Jason Dillon Priority: Critical Remove overloaded maven scope from CAR plugin. Re-add similar functionality with nested configuration elements (extensions of ArtifactItem) which provide clear meaning w/o overloading maven's dependency system. -- 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: Fixing java.endorsed.dirs
Alan D. Cabrera wrote: On Oct 4, 2006, at 1:53 AM, Rick McGuire wrote: Alan D. Cabrera wrote: On Sep 28, 2006, at 12:25 PM, Dain Sundstrom wrote: Anyway, this sucks, since it requires users to use a shell script to launch Geronimo. Is there anyway to detect the corba api version and not load the Yoko classes that have the problems? OT: in the future, if we used OSGi as a base, we would have a clean workaround for this problem, no? I'm not sure how OSGi would help with this. The functioning of java.endorsed.dirs is a base function of how the JVM works. There's not much other option to get around this. IIUC, you can eclipse JVM classes with your own. Do I have it wrong? Yes, but there are certain fundamental classes where this become problematic because other portions of the JVM also contain references to these classes. This is why java.endorsed.dirs got created in the first place. Regards, Alan
[jira] Reopened: (SM-674) jbi:installComponent (and others) fails authentication against default SM container
[ https://issues.apache.org/activemq/browse/SM-674?page=all ] Philip Dodds reopened SM-674: - Unable to set read-only parameters jbi:installComponent (and others) fails authentication against default SM container --- Key: SM-674 URL: https://issues.apache.org/activemq/browse/SM-674 Project: ServiceMix Issue Type: Bug Components: tooling Affects Versions: 3.0 Environment: Java 1.5, Windows XP SP2 Reporter: Jamie McCrindle Fix For: 3.0.1, 3.1 When running the jbi:installComponent maven task to install a component into a running SM 3.0 container, it fails with an Authentication failed User not found message. Debug from maven as follows: [DEBUG] Configuring mojo 'org.apache.servicemix.tooling:jbi-maven-plugin:3.0-inc ubating:installComponent' -- [DEBUG] -- end configuration -- [INFO] [jbi:installComponent] installComponent: [echo] Installing C:\dev\component-mvn\component-task-jbi\target/component- task-jbi-1.0-beta2-SNAPSHOT-installer.zip to service:jmx:rmi:///jndi/rmi://local host:1099/jmxrmi [installComponent] Error accessing ServiceMix administration: Authentication fai led [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Failed to execute: Executing Ant script: /jbi.build.xml [installComponent ]: Failed to execute. User does not exist [INFO] [DEBUG] Trace org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute: Execu ting Ant script: /jbi.build.xml [installComponent]: Failed to execute. at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(Defa ultLifecycleExecutor.java:559) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandalone Goal(DefaultLifecycleExecutor.java:488) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(Defau ltLifecycleExecutor.java:458) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHan dleFailures(DefaultLifecycleExecutor.java:306) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegmen ts(DefaultLifecycleExecutor.java:273) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLi fecycleExecutor.java:140) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:322) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:115) at org.apache.maven.cli.MavenCli.main(MavenCli.java:256) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl. java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces sorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) at org.codehaus.classworlds.Launcher.main(Launcher.java:375) Caused by: org.apache.maven.plugin.MojoExecutionException: Failed to execute: Ex ecuting Ant script: /jbi.build.xml [installComponent]: Failed to execute. at org.apache.maven.script.ant.AntMojoWrapper.execute(AntMojoWrapper.jav a:37) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPlugi nManager.java:412) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(Defa ultLifecycleExecutor.java:534) ... 16 more Caused by: org.codehaus.plexus.component.factory.ant.AntComponentExecutionExcept ion: Executing Ant script: /jbi.build.xml [installComponent]: Failed to execute. at org.codehaus.plexus.component.factory.ant.AntScriptInvoker.invoke(Ant ScriptInvoker.java:227) at org.apache.maven.script.ant.AntMojoWrapper.execute(AntMojoWrapper.jav a:33) ... 18 more Caused by: C:\DOCUME~1\JamesM\LOCALS~1\Temp\plexus-ant-component30723.build.xml: 30: Error accessing ServiceMix administration at org.apache.servicemix.jbi.management.task.JbiTask.execute(JbiTask.jav a:272) at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:275) at org.apache.tools.ant.Task.perform(Task.java:364) at org.apache.tools.ant.Target.execute(Target.java:341) at org.apache.tools.ant.Target.performTasks(Target.java:369) at org.apache.tools.ant.Project.executeSortedTargets(Project.java:1216) at
[jira] Resolved: (SM-674) jbi:installComponent (and others) fails authentication against default SM container
[ https://issues.apache.org/activemq/browse/SM-674?page=all ] Philip Dodds resolved SM-674. - Resolution: Fixed Applied change to 3.0 branch and trunk to change parameters to read-write. jbi:installComponent (and others) fails authentication against default SM container --- Key: SM-674 URL: https://issues.apache.org/activemq/browse/SM-674 Project: ServiceMix Issue Type: Bug Components: tooling Affects Versions: 3.0 Environment: Java 1.5, Windows XP SP2 Reporter: Jamie McCrindle Fix For: 3.0.1, 3.1 When running the jbi:installComponent maven task to install a component into a running SM 3.0 container, it fails with an Authentication failed User not found message. Debug from maven as follows: [DEBUG] Configuring mojo 'org.apache.servicemix.tooling:jbi-maven-plugin:3.0-inc ubating:installComponent' -- [DEBUG] -- end configuration -- [INFO] [jbi:installComponent] installComponent: [echo] Installing C:\dev\component-mvn\component-task-jbi\target/component- task-jbi-1.0-beta2-SNAPSHOT-installer.zip to service:jmx:rmi:///jndi/rmi://local host:1099/jmxrmi [installComponent] Error accessing ServiceMix administration: Authentication fai led [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Failed to execute: Executing Ant script: /jbi.build.xml [installComponent ]: Failed to execute. User does not exist [INFO] [DEBUG] Trace org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute: Execu ting Ant script: /jbi.build.xml [installComponent]: Failed to execute. at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(Defa ultLifecycleExecutor.java:559) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandalone Goal(DefaultLifecycleExecutor.java:488) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(Defau ltLifecycleExecutor.java:458) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHan dleFailures(DefaultLifecycleExecutor.java:306) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegmen ts(DefaultLifecycleExecutor.java:273) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLi fecycleExecutor.java:140) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:322) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:115) at org.apache.maven.cli.MavenCli.main(MavenCli.java:256) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl. java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces sorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) at org.codehaus.classworlds.Launcher.main(Launcher.java:375) Caused by: org.apache.maven.plugin.MojoExecutionException: Failed to execute: Ex ecuting Ant script: /jbi.build.xml [installComponent]: Failed to execute. at org.apache.maven.script.ant.AntMojoWrapper.execute(AntMojoWrapper.jav a:37) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPlugi nManager.java:412) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(Defa ultLifecycleExecutor.java:534) ... 16 more Caused by: org.codehaus.plexus.component.factory.ant.AntComponentExecutionExcept ion: Executing Ant script: /jbi.build.xml [installComponent]: Failed to execute. at org.codehaus.plexus.component.factory.ant.AntScriptInvoker.invoke(Ant ScriptInvoker.java:227) at org.apache.maven.script.ant.AntMojoWrapper.execute(AntMojoWrapper.jav a:33) ... 18 more Caused by: C:\DOCUME~1\JamesM\LOCALS~1\Temp\plexus-ant-component30723.build.xml: 30: Error accessing ServiceMix administration at org.apache.servicemix.jbi.management.task.JbiTask.execute(JbiTask.jav a:272) at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:275) at org.apache.tools.ant.Task.perform(Task.java:364) at org.apache.tools.ant.Target.execute(Target.java:341) at org.apache.tools.ant.Target.performTasks(Target.java:369) at
Re: Release schedule
Sorry about that. I'd forgotten about the wireformat stuff. Looks like you can set AMQ 4.1 minimum wire format to 1 and then it will connect to AMQ 4.0.2 (still breaks with AMQ 4.0.1, but 4.0.1 and 4.0.2 work together). This gives me the rollout path we need. Two things though: 1) I could not get multiple connection properties on the TCP connectors, such as tcp://perfgc1a::5112?minmumWireFormatVersion=1connectionTimeout=5000. The XML parser complained. How should this look?? 2) Even with minmumWireFormatVersion=1, will two AMQ 4.1 brokers connect using their newer v2 format? yaussy wrote: I put a post in the user forum for this, but thought I'd add something to this thread. I'm concerned about backward compatibility. I've got a test environment with all brokers at 4.0.1, except one I'm upgrading to 4.1. This would be how our production environment would be upgraded - a machine or so at a time. However, the 4.0.1 brokers will not connect to the 4.1 broker, giving the following exception: Exception in thread ActiveMQ Transport: tcp:///170.137.15.160:34695 java.lang.IllegalArgumentException: Invalid version: 2, could not l oad org.apache.activemq.openwire.v2.MarshallerFactory at org.apache.activemq.openwire.OpenWireFormat.setVersion(OpenWireFormat.java:329) at org.apache.activemq.openwire.OpenWireFormat.renegociatWireFormat(OpenWireFormat.java:569) at org.apache.activemq.transport.WireFormatNegotiator.onCommand(WireFormatNegotiator.java:100) at org.apache.activemq.transport.InactivityMonitor.onCommand(InactivityMonitor.java:122) at org.apache.activemq.transport.TransportSupport.doConsume(TransportSupport.java:87) at org.apache.activemq.transport.tcp.TcpTransport.run(TcpTransport.java:143) at java.lang.Thread.run(Thread.java:595) Caused by: java.lang.ClassNotFoundException: org.apache.activemq.openwire.v2.MarshallerFactory at org.apache.activemq.util.ClassLoading.loadClass(ClassLoading.java:104) at org.apache.activemq.openwire.OpenWireFormat.setVersion(OpenWireFormat.java:327) ... 6 more There must be an upgrade path for 4.1. If that means I have to go to 4.0.2 (which I did not try yet), that is OK. But, I can't possibly tell my management that I have to upgrade the AMQ version on all 50 or so machines we have in production. Hiram Chirino wrote: I'm starting to work on the first release candidate for 4.1.. please let me know if I should hold off! On 10/3/06, Vadim Pesochinsky [EMAIL PROTECTED] wrote: Hi James, It looks like this is changed now with 4.0.3. Any idea when 4.1 is going to be out? Thanks. -- View this message in context: http://www.nabble.com/Release-schedule-tf2124265.html#a6630219 Sent from the ActiveMQ - Dev mailing list archive at Nabble.com. -- Regards, Hiram Blog: http://hiramchirino.com -- View this message in context: http://www.nabble.com/Release-schedule-tf2124265.html#a6647640 Sent from the ActiveMQ - Dev mailing list archive at Nabble.com.
Re: Fixing java.endorsed.dirs
You can only replace the bootstrap classes with the endorsed mechanism or by changing the bootstrap class path. I don't think that there is anything else available. Heinz On 10/4/06, Alan D. Cabrera [EMAIL PROTECTED] wrote: On Oct 4, 2006, at 1:53 AM, Rick McGuire wrote: Alan D. Cabrera wrote: On Sep 28, 2006, at 12:25 PM, Dain Sundstrom wrote: Anyway, this sucks, since it requires users to use a shell script to launch Geronimo. Is there anyway to detect the corba api version and not load the Yoko classes that have the problems? OT: in the future, if we used OSGi as a base, we would have a clean workaround for this problem, no? I'm not sure how OSGi would help with this. The functioning of java.endorsed.dirs is a base function of how the JVM works. There's not much other option to get around this. IIUC, you can eclipse JVM classes with your own. Do I have it wrong? Regards, Alan
Re: How do I get the configID from deploymentPlan?
On Oct 4, 2006, at 8:43 AM, Sachin Patel wrote:I must be overlooking something but I'm having trouble using XMLBeans to get to the EnvironmentType for a given deployment plan.If I have...XmlObject xmlObject = XmlBeansUtil.parse(planFile.getLocation().toFile());from there if I cast to a particular DocumentType (WebAppDocument, etc..) there are no methods to get me to the EnvioronmentType..So I looked at the o.a.g.deployment.Deployer and in there... and what got me even more confused was the following code... There are only two implementations of ConfigurationBuilder, (ServiceConfigBuilder and EARConfigBuilder), so how is the configID being retrieved? Where is the getConfigurationID implementation for the other plan types?Object plan = null; ConfigurationBuilder builder = null; for (Iterator i = builders.iterator(); i.hasNext();) { ConfigurationBuilder candidate = (ConfigurationBuilder) i.next(); System.out.println("***" + candidate.getClass().getName()); plan = candidate.getDeploymentPlan(planFile, module, idBuilder); if (plan != null) { builder = candidate; break; } } if (builder == null) { throw new DeploymentException("Cannot deploy the requested application module because no deployer is able to handle it. " + " This can happen if you have omitted the J2EE deployment descriptor, disabled a deployer module, or if, for example, you are trying to deploy an" + " EJB module on a minimal Geronimo server that does not have EJB support installed. (" + (planFile == null ? "" : "planFile=" + planFile.getAbsolutePath()) + (moduleFile == null ? "" : (planFile == null ? "" : ", ") + "moduleFile=" + moduleFile.getAbsolutePath()) + ")"); } Artifact configID = builder.getConfigurationID(plan, module, idBuilder);ThanksThat code's from Deployer which doesn't know anything about xml or plans or anything like that. All the ConfigBuilders and ModuleBuilders have code that extracts the Enviroment element, typicaly like EnvironmentType environmentType = gerConnector.getEnvironment(); Environment environment = EnvironmentBuilder.buildEnvironment(environmentType, defaultEnvironment);However you may find it easier to do something more generic likeQNameSet ENV_QNAMESET = EnvironementDocument.type.getDocumentElementQName();XmlObject untypedEnv = plan.selectChildren(ENV_QNAMESET);EnvironmentType env = (EnvironmentType)untypedEnv.changeType(EnvironmentType.type);Sometimes it's hard to convince xmlbeans to change the type correctly, you get null out of changeType. In that case I useenv = (EnvironemntType)untypedEnv.copy().changeTYpe(EnvironmentTYpe.type);but then changes you make to env won't be reflected in the original XmlObject or written back into the xml if you save. It's possible to get around this but if changeType works without copying do that.thanksdavid jencks-sachin
Re: svn commit: r452927 - /geronimo/server/trunk/pom.xml
On Oct 4, 2006, at 11:38 AM, Dain Sundstrom wrote: On Oct 4, 2006, at 11:13 AM, Jason Dillon wrote: I have been trying to remove the need for all of those properties. I think a few of these are fine... just as long as those properties are never used in child modules. But most people copy past the deps, so these properties are bound to leak. I agree but the alternative is some pretty ugly perl code to find the correct version numbers to change. Another possiblility might be to move the openejb configs into openejb so the only use of openejb is in assemblies. (don't know if the webconsole refers to openejb -- if so that part should also move to openejb) david jencks -dain
[jira] Updated: (GERONIMO-2463) Add support to conditionally load modules based on environment + simple expression
[ http://issues.apache.org/jira/browse/GERONIMO-2463?page=all ]
Jason Dillon updated GERONIMO-2463:
---
Attachment: GERONIMO-2463.diff
{{GERONIMO-2463.diff}} provides basic support for condition expressions for
module elements in attributes. Includes java, os and props variables to
provide basic read-only access to environment details.
Add support to conditionally load modules based on environment + simple
expression
--
Key: GERONIMO-2463
URL: http://issues.apache.org/jira/browse/GERONIMO-2463
Project: Geronimo
Issue Type: New Feature
Security Level: public(Regular issues)
Components: core
Affects Versions: 1.2
Reporter: Jason Dillon
Assigned To: Jason Dillon
Attachments: GERONIMO-2463.diff
Add support to conditionally load modules (defined in {{config.xml}}) based
on environment + simple expression.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (GERONIMO-2463) Add support to conditionally load modules based on environment + simple expression
[
http://issues.apache.org/jira/browse/GERONIMO-2463?page=comments#action_12439995
]
Jason Dillon commented on GERONIMO-2463:
Allows expressions like:
* {{java.is1_5}}
* {{!java.is1_5}}
* {{os.isLinux or os.isWindows}}
Add support to conditionally load modules based on environment + simple
expression
--
Key: GERONIMO-2463
URL: http://issues.apache.org/jira/browse/GERONIMO-2463
Project: Geronimo
Issue Type: New Feature
Security Level: public(Regular issues)
Components: core
Affects Versions: 1.2
Reporter: Jason Dillon
Assigned To: Jason Dillon
Attachments: GERONIMO-2463.diff
Add support to conditionally load modules (defined in {{config.xml}}) based
on environment + simple expression.
--
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
[REVIEW] Conditionally loading modules based on expression (and environment)
I cleaned up my quick POC into a patch suitable to be applied to trunk: https://issues.apache.org/jira/browse/GERONIMO-2463 Please review. If there are no objections I will apply this over the weekend. Thanks, --jason
Re: What is GShell?
On Oct 3, 2006, at 10:12 AM, Paul McMahan wrote: I love the idea of being able to telnet or ssh into the server and run commands remotely. Ditto. Everyone gave me hard time when I did this in OpenEJB a couple years ago. Hiram cleaned the code up considerably when I moved it into xbean -- thanks Hiram. http://incubator.apache.org/openejb/telnet-console.html GShell looks pretty awesome.. Jason's definitely taken it to the next level. Super excited to see GShell get integrated into Geronimo. Really looking forward to that full bash shell. That's going to be so sweet. I'm a bash junkie. I did a Groovy shell that James blogged about, but Groovy just didn't cut it as an interactive shell -- sorry James. Props to Jason for some pretty outstanding work! -David
Re: Release schedule
On 10/4/06, yaussy [EMAIL PROTECTED] wrote: Sorry about that. I'd forgotten about the wireformat stuff. Looks like you can set AMQ 4.1 minimum wire format to 1 and then it will connect to AMQ 4.0.2 (still breaks with AMQ 4.0.1, but 4.0.1 and 4.0.2 work together). This gives me the rollout path we need. Since 4.0.2 has not been officially released, which 4.0.2 versin are you using? RC4 ? I think 4.0.2 RC 4 should be able to connecto the 4.1 without any config changes. A small bug in 4.0 was fixed in 4.0.2 that fixes auto wirefomat versin negociation. Two things though: 1) I could not get multiple connection properties on the TCP connectors, such as tcp://perfgc1a::5112?minmumWireFormatVersion=1connectionTimeout=5000. The XML parser complained. How should this look?? in XML you need replace all the '' with 'amp;' 2) Even with minmumWireFormatVersion=1, will two AMQ 4.1 brokers connect using their newer v2 format? Hum they should. Sees odd that the default is not 1... it should be 1. I'll double check. Thanks for testing this stuff out! yaussy wrote: I put a post in the user forum for this, but thought I'd add something to this thread. I'm concerned about backward compatibility. I've got a test environment with all brokers at 4.0.1, except one I'm upgrading to 4.1. This would be how our production environment would be upgraded - a machine or so at a time. However, the 4.0.1 brokers will not connect to the 4.1 broker, giving the following exception: Exception in thread ActiveMQ Transport: tcp:///170.137.15.160:34695 java.lang.IllegalArgumentException: Invalid version: 2, could not l oad org.apache.activemq.openwire.v2.MarshallerFactory at org.apache.activemq.openwire.OpenWireFormat.setVersion(OpenWireFormat.java:329) at org.apache.activemq.openwire.OpenWireFormat.renegociatWireFormat(OpenWireFormat.java:569) at org.apache.activemq.transport.WireFormatNegotiator.onCommand(WireFormatNegotiator.java:100) at org.apache.activemq.transport.InactivityMonitor.onCommand(InactivityMonitor.java:122) at org.apache.activemq.transport.TransportSupport.doConsume(TransportSupport.java:87) at org.apache.activemq.transport.tcp.TcpTransport.run(TcpTransport.java:143) at java.lang.Thread.run(Thread.java:595) Caused by: java.lang.ClassNotFoundException: org.apache.activemq.openwire.v2.MarshallerFactory at org.apache.activemq.util.ClassLoading.loadClass(ClassLoading.java:104) at org.apache.activemq.openwire.OpenWireFormat.setVersion(OpenWireFormat.java:327) ... 6 more There must be an upgrade path for 4.1. If that means I have to go to 4.0.2 (which I did not try yet), that is OK. But, I can't possibly tell my management that I have to upgrade the AMQ version on all 50 or so machines we have in production. Hiram Chirino wrote: I'm starting to work on the first release candidate for 4.1.. please let me know if I should hold off! On 10/3/06, Vadim Pesochinsky [EMAIL PROTECTED] wrote: Hi James, It looks like this is changed now with 4.0.3. Any idea when 4.1 is going to be out? Thanks. -- View this message in context: http://www.nabble.com/Release-schedule-tf2124265.html#a6630219 Sent from the ActiveMQ - Dev mailing list archive at Nabble.com. -- Regards, Hiram Blog: http://hiramchirino.com -- View this message in context: http://www.nabble.com/Release-schedule-tf2124265.html#a6647640 Sent from the ActiveMQ - Dev mailing list archive at Nabble.com. -- Regards, Hiram Blog: http://hiramchirino.com
[jira] Commented: (GERONIMO-2458) MapEditor does not work
[
http://issues.apache.org/jira/browse/GERONIMO-2458?page=comments#action_12440018
]
Vamsavardhana Reddy commented on GERONIMO-2458:
---
The current MapEditor won't work at all. Whereas the fix I submitted is
alright as long as there are no null keys or values. I agree that my patch
will make the class equivalent to MapEditor extends PropertiesEditor with
nothing extra.
Maps can have null keys values and null mapped to null. Keys and values need
not be Strings. MapEditor should handle all these scenarios. I submitted the
patch with the idea that I will sumbit another patch later to handle nulls etc.
Each key and its corresponding value in Properties is a String.
If we will not be handling non-string properties or values and nulls in maps in
G, we can remove this class altogether and use PropertiesEditor alone.
MapEditor does not work
---
Key: GERONIMO-2458
URL: http://issues.apache.org/jira/browse/GERONIMO-2458
Project: Geronimo
Issue Type: Bug
Security Level: public(Regular issues)
Components: common
Affects Versions: 1.1.1, 1.2
Environment: 1.2-SNAPSHOT
Reporter: Vamsavardhana Reddy
Fix For: 1.1.2, 1.2
Attachments: GERONIMO-2458.patch
MapEditor.getAsText() is returning map.toString() which is not in sync with
setAsText() that expects input in the form name1=value1 on separate lines.
Bottom line...
MapEditor.getAsText() returns
{name1=value1, name2=value2}
where as MapEditor.setAsText() expects
name1=value1
name=value2
--
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: [REVIEW] Conditionally loading modules based on expression (and environment)
btw.. ongl might also be a good canidate to use as an expression language. On 10/4/06, Jason Dillon [EMAIL PROTECTED] wrote: I cleaned up my quick POC into a patch suitable to be applied to trunk: https://issues.apache.org/jira/browse/GERONIMO-2463 Please review. If there are no objections I will apply this over the weekend. Thanks, --jason -- Regards, Hiram Blog: http://hiramchirino.com
[STATUS] (geronimo) Wed Oct 4 23:48:56 2006
APACHE GERONIMO STATUS: -*-text-*- Last modified at [$Date: 2006-10-02 19:18:19 -0400 (Mon, 02 Oct 2006) $] The current version of this file can be found at: * http://svn.apache.org/repos/asf/geronimo/trunk/STATUS Upcoming Releases: Geronimo 1.2 -- geronimo/trunk/ Release Manager: Dain Sundstrom and Alan Cabrera Estimated Date: Q4 2006 RELEASE SHOWSTOPPERS: Certification - Historically certification has been the most time consuming portion of a release, and there is no reason to expect it to be any different for this release. To make matters worse, the certification test suite has not been run in several months while major changes have been made to EJB, Transaction, Connector and Servlet Session. Features - The scope for the 1.2 release is currently being finalized. We have collected a list of 14 features to be included in the release and are working on prioritizing the list. The prioritized list will help guide us in determining when to release based on the number of completed high priority features. Dead 1.2 - There are still 37 unmerged commits the dead 1.2 branch. These commits must be merged before the 1.2 release. The current status of the dead-1.2 changes can be found at http://svn.apache.org/repos/asf/geronimo/server/trunk/all_changes.log Specs - There are two proposals for versioning specification jars in Geronimo. The first uses a single version number for all specifications. The makes releasing new versions of specifications easy for the Geronimo committers as only a single file must be updated. Alternatively, each specification could have an independent version number. With this approach several files may have to be updated to release a jar, but this approach reduces the number of jars that are released with no changes. This issue is in active discussion and will hopefully be resolved quickly. Outstanding patches awaiting votes: On JIRA, the following patches are oustanding: GERONIMO-1277 Change group-id to org.apache.geronimo Status: New proposal by Jason Dillon to change base the groupId to org.apache.geronimo.server GERONIMO-2015 Let's replace JKS to PKCS12 key store type - Opened Status: No active discussion GERONIMO-2409 Provide config/module aliasing ability Status: 3 +1 votes GERONIMO-2413 Add a Certification Authority (CA) portlet to Geronimo console Status: Not reviewed Release history: 2006-09-18 Geronimo 1.1 2006-06-26 Geronimo 1.1 2006-01-05 Geronimo 1.0 2005-10-04 Geronimo 1.0 milestone 5 2005-08-10 Geronimo 1.0 milestone 4 2004-11-11 Geronimo 1.0 milestone 3 2004-09-09 Geronimo 1.0 milestone 2 2004-04-29 Geronimo 1.0 milestone 1 If you're a contributor looking for something to do: * Review the documentation and suggest improvements * Review the bug list and suggest fixes or report reproducibility * Report bugs yourself
Building minimally to test code changes
Is there a way to quickly build only those modules that are affected by a code change in one module? For e.g., if I change some code in applications\console\geronimo-console-standard I build applications\console\geronimo-console-standard applications\console\geronimo-console-ear configs\webconsole-tomcat assemblies\geronimo-tomcat-j2ee and the changes get reflected in the assembly. But if I make a change in modules\geronimo-management it is not that simple. What I want to know is if I specify modules\geronimo-management or geronimo-management on the command line as an argument, the build script should build this module and only those that depend on this module so that the changes reflect in the assemblies. Is there already a way to do this? Thanks, Vamsi
Re: [STATUS] (geronimo) Wed Oct 4 23:48:56 2006
Release History should say 2006-09-18 Geronimo 1.1.1 --vamsiOn 10/5/06, Geronimo Weekly Status dev@geronimo.apache.org wrote: APACHE GERONIMO STATUS: -*-text-*-Last modified at [$Date: 2006-10-02 19:18:19 -0400 (Mon, 02 Oct 2006) $]The current version of this file can be found at:* http://svn.apache.org/repos/asf/geronimo/trunk/STATUS Upcoming Releases:Geronimo 1.2 -- geronimo/trunk/Release Manager: Dain Sundstrom and Alan CabreraEstimated Date: Q4 2006RELEASE SHOWSTOPPERS:Certification - Historically certification has been the most time consuming portion of a release, and there is no reason to expect it to be any differentfor this release.To make matters worse, the certification test suite has notbeen run in several months while major changes have been made to EJB, Transaction, Connector and Servlet Session.Features - The scope for the 1.2 release is currently being finalized.Wehave collected a list of 14 features to be included in the release and areworking on prioritizing the list.The prioritized list will help guide us in determining when to release based on the number of completed high priorityfeatures.Dead 1.2 -There are still 37 unmerged commits the dead 1.2 branch.Thesecommits must be merged before the 1.2 release.The current status of the dead-1.2 changes can be found athttp://svn.apache.org/repos/asf/geronimo/server/trunk/all_changes.logSpecs - There are two proposals for versioning specification jars in Geronimo. The first uses a single version number for all specifications.The makesreleasing new versions of specifications easy for the Geronimo committers asonly a single file must be updated.Alternatively, each specification could have an independent version number.With this approach several files may haveto be updated to release a jar, but this approach reduces the number of jarsthat are released with no changes.This issue is in active discussion and will hopefully be resolved quickly.Outstanding patches awaiting votes:On JIRA, the following patches are oustanding:GERONIMO-1277 Change group-id to org.apache.geronimoStatus: New proposal by Jason Dillon to change base the groupId to org.apache.geronimo.serverGERONIMO-2015 Let's replace JKS to PKCS12 key store type - OpenedStatus: No active discussionGERONIMO-2409 Provide config/module aliasing abilityStatus: 3 +1 votes GERONIMO-2413 Add a Certification Authority (CA) portlet to Geronimo consoleStatus: Not reviewedRelease history:2006-09-18Geronimo 1.12006-06-26Geronimo 1.12006-01-05Geronimo 1.02005-10-04Geronimo 1.0 milestone 52005-08-10Geronimo 1.0 milestone 42004-11-11Geronimo 1.0 milestone 32004-09-09Geronimo 1.0 milestone 22004-04-29Geronimo 1.0 milestone 1 If you're a contributor looking for something to do:* Review the documentation and suggest improvements* Review the bug list and suggest fixes or report reproducibility * Report bugs yourself
[jira] Commented: (GERONIMO-2393) Maven eclipse plugin is generating invalid classpath entries in .classpath
[ http://issues.apache.org/jira/browse/GERONIMO-2393?page=comments#action_12440030 ] Vamsavardhana Reddy commented on GERONIMO-2393: --- URGH... I will have to withdraw my previous comment that Sun JDK v1.4.2_12 solved it. The problem has not gone away. I did a fresh checkout and bootstrap on a machine that had Sun JDK 1.4.2_09 and noticed that the classpath entries are fine. Afterward that I installed Sun JDK1.4.2_12 on my machine and ran mvn eclipse:eclipse under a specific directory (modules\geronimo-tomcat) and noticed that the classpath entries are alright (this was before a reboot once JDK1.4.2_12 is installed. I do not know if the reboot has any effect on the current issue). I thought the problem is solved. After a later run of mvn eclipse:eclipse, I am still left with incorrect classpath entries. HELP Maven eclipse plugin is generating invalid classpath entries in .classpath -- Key: GERONIMO-2393 URL: http://issues.apache.org/jira/browse/GERONIMO-2393 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: buildsystem Affects Versions: 1.2 Environment: WinXP, G TRUNK Reporter: Vamsavardhana Reddy Fix For: 1.2 Attachments: .classpath, .classpath I have run mvn eclipse:eclipse. Upon importing the projects into eclipse, I am noticing the the classpath entries generated have the first letter missing. Here is an example of some classpath entries in .classpath file. classpathentry kind=var path=M2_REPO/ommons-cli/commons-cli/1.0/commons-cli-1.0.jar/ classpathentry kind=var path=M2_REPO/tax/stax-api/1.0/stax-api-1.0.jar/ classpathentry kind=var path=M2_REPO/lassworlds/classworlds/1.1-alpha-2/classworlds-1.1-alpha-2.jar/ classpathentry kind=var path=M2_REPO/rg/apache/maven/maven-repository-metadata/2.0.4/maven-repository-metadata-2.0.4.jar/ -- 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
ERROR: Building Geronimo Configs :: Corba J2EE Client
Anything that needs a refresh in the repos?
--vamsi
--
[INFO] -
---
[INFO] Building Geronimo Configs :: Corba J2EE Client
[INFO] task-segment: [install]
[INFO] -
---
[INFO] [tools:require-java-version {execution: validate-java-version}]
[INFO] [tools:copy-legal-files {execution: install-legal-files}]
[INFO] [resources:resources]
[INFO] Using default encoding to copy filtered resources.
[INFO] [car:prepare-plan]
[INFO] Generated: G:\configs\client-corba-yoko\target\plan\plan.xml
[WARNING] POM for 'activecluster:activecluster:pom:1.1-SNAPSHOT:provided' is inv
alid. It will be ignored for artifact resolution. Reason: Not a v4.0.0 POM.
[WARNING] POM for 'activemq:activemq:pom:3.2.4-SNAPSHOT:provided' is invalid. It
will be ignored for artifact resolution. Reason: Not a v4.0.0 POM.
[WARNING] POM for 'tranql:tranql:pom:1.4-SNAPSHOT:provided' is invalid. It will
be ignored for artifact resolution. Reason: Not a v4.0.0 POM.
[WARNING] POM for 'tranql:tranql-connector-derby-embed-xa:pom:1.1:provided' is i
nvalid. It will be ignored for artifact resolution. Reason: Failed to validate P
OM
[WARNING] POM for 'tranql:tranql:pom:1.4-SNAPSHOT:provided' is invalid. It will
be ignored for artifact resolution. Reason: Not a v4.0.0 POM.
[WARNING] POM for 'tranql:tranql:pom:1.4-SNAPSHOT:provided' is invalid. It will
be ignored for artifact resolution. Reason: Not a v4.0.0 POM.
[WARNING] POM for 'tranql:tranql:pom:1.4-SNAPSHOT:compile' is invalid. It will b
e ignored for artifact resolution. Reason: Not a v4.0.0 POM.
[WARNING] POM for 'activecluster:activecluster:pom:1.1-SNAPSHOT:compile' is inva
lid. It will be ignored for artifact resolution. Reason: Not a v4.0.0 POM.
[WARNING] POM for 'activemq:activemq:pom:3.2.4-SNAPSHOT:compile' is invalid. It
will be ignored for artifact resolution. Reason: Not a v4.0.0 POM.
[WARNING] POM for 'tranql:tranql:pom:1.4-SNAPSHOT:compile' is invalid. It will b
e ignored for artifact resolution. Reason: Not a v4.0.0 POM.
[WARNING] POM for 'tranql:tranql:pom:1.4-SNAPSHOT:compile' is invalid. It will b
e ignored for artifact resolution. Reason: Not a v4.0.0 POM.
[WARNING] POM for 'activecluster:activecluster:pom:1.1-SNAPSHOT:compile' is inva
lid. It will be ignored for artifact resolution. Reason: Not a v4.0.0 POM.
[WARNING] POM for 'activemq:activemq:pom:3.2.4-SNAPSHOT:compile' is invalid. It
will be ignored for artifact resolution. Reason: Not a v4.0.0 POM.
[WARNING] POM for 'tranql:tranql:pom:1.4-SNAPSHOT:compile' is invalid. It will b
e ignored for artifact resolution. Reason: Not a v4.0.0 POM.
[INFO] snapshot org.apache.geronimo.modules:geronimo-security-builder:1.2-SNAPSH
OT: checking for updates from local-m1
[INFO] snapshot org.apache.geronimo.modules:geronimo-naming-builder:1.2-SNAPSHOT
: checking for updates from local-m1
[INFO] [car:package]
[INFO] Packaging module configuration: G:\configs\client-corba-yoko\target\plan\
plan.xml
[INFO]
[ERROR] BUILD ERROR
[INFO]
[INFO] No reference named configAdapter in gbean org.apache.geronimo.configs/cli
ent-corba-yoko/1.2-SNAPSHOT/car?ServiceModule=org.apache.geronimo.configs/client
-corba-yoko/1.2-SNAPSHOT/car,j2eeType=CORBANameService,name=NameServerRef
[INFO]
[INFO] For more information, run Maven with the -e switch
[INFO]
[INFO] Total time: 5 minutes 51 seconds
[INFO] Finished at: Thu Oct 05 11:20:45 IST 2006
[INFO] Final Memory: 59M/138M
[INFO]
[jira] Created: (XBEAN-56) Unable to parse nested custom spring tags (defined using spring 2 handlers)
Unable to parse nested custom spring tags (defined using spring 2 handlers) --- Key: XBEAN-56 URL: http://issues.apache.org/jira/browse/XBEAN-56 Project: XBean Issue Type: Bug Components: spring Affects Versions: 2.6 Reporter: Guillaume Nodet Fix For: 2.7 For example, the following definition does not work: beans xmlns:b=http://xbean.apache.org/schemas/pizza; xmlns:util=http://www.springframework.org/schema/util; b:dummy b:inner util:constant static-field=java.sql.Connection.TRANSACTION_SERIALIZABLE/ /b:inner /b:dummy /beans -- 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
