[jira] Created: (AMQ-889) Broker 'loses' messages and leaks resources when handling duplicate connections
Broker 'loses' messages and leaks resources when handling duplicate connections --- Key: AMQ-889 URL: https://issues.apache.org/activemq/browse/AMQ-889 Project: ActiveMQ Issue Type: Bug Components: Broker Affects Versions: 4.0.2 Reporter: John Heitmann Attachments: doubleConsumer.patch.gz A client that uses a transport like the failover transport can damage the broker's ability to deliver messages to other clients and ultimately cause broker resource leaks and message loss. I've found 4 issues starting on the client and ending on the broker that could be improved to make the situation a lot better. In this issue I've provided a patch for #3. 1) A failover client stores session metadata commands like ConsumerInfo in a local state tracker. When failover occurs it replays these commands verbatim to the newly connected-to broker. If the failover transport fails back to the original broker it will replay the same commands with the same ids as it already sent the broker. If the failover happens before the broker notices the old connection has gone this can result in bad mojo. Clients should probably regenerate session, consumer, and maybe connection ids. 2) When the broker detects a duplicate ClientId being sent to it it throws an exception saying so, but this does not stop the broker from processing subsequent messages on that connection. The broker should tear down the connection immediately when it sees a client thrashing about. 3) When a broker receives a certain series of ConsumerInfo add and remove commands with the same ConsumerId it leaks resources. One of the resources leaked is the knowledge of lock owners on messages out in prefetch buffers. This means those messages are stuck forever on the broker and can never be retrieved and never be gc()ed. More below. 4) Messages locked and out in prefetch buffers have no broker-side timeout. If a consumer is up, saying hello to the inactivity monitor, but otherwise doing nothing then its messages are locked forever. The broker should have a janitor that redrives stale messages. This seems like the hardest of the 4 to fix, but is one of the most important. More on #3: One bad sequence of events is: 1) Consumer 'c' connects to the broker over a failover transport. 2) c subscribes to a queue and addConsumer() gets called. 3) c fails away and then fails back. 4) c replays ConsumerInfo to the broker. addConsumer() gets called again and overwrites subscription tracking from the first. After this the broker will eventually get a double remove and there will be noisy JMX complaints etc., but the serious problem has already occurred in step 4. My patch synchronizes the add step so that the broker is protected. The individual client will still be a bit confused, and there will still be noise when the second remove comes and JMX can't find the consumer to remove, but the resource and message leaks are taken care of. I'll file issues on the other 3 problems if they sound valid to you and aren't already entered. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (AMQ-890) JMX purge() fails with a ConcurrentModificationException
JMX purge() fails with a ConcurrentModificationException Key: AMQ-890 URL: https://issues.apache.org/activemq/browse/AMQ-890 Project: ActiveMQ Issue Type: Bug Components: Broker Affects Versions: 4.0.2 Reporter: John Heitmann Priority: Minor Attachments: purge.patch.gz I think this must be an issue running under jdk 1.5 only. It shows up on Mac OS X and Linux 1.5 jvms. Remove and gc() were stumbling over each other and invalidating the iterator. I broke them apart a bit to avoid the exception. Thanks to Alan Robbins for help tracking this down. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (AMQ-891) InterruptedException handling tweaks
InterruptedException handling tweaks Key: AMQ-891 URL: https://issues.apache.org/activemq/browse/AMQ-891 Project: ActiveMQ Issue Type: Bug Components: Broker Affects Versions: 4.0.2 Reporter: John Heitmann Priority: Minor Attachments: interrupted.patch.gz There were a few spots where the broker was masking the interrupt state after handling an InterruptedException. This is a lint pass to clean some of that up. I learned after I made this patch that it's actually slightly better stylistically to call Thread.interrupt() instead of Thread.currentThread().interrupt() since it's static and the interrupt state is global(ish), but this is the version we've tested. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (AMQ-892) Allow the JMX RMI server port to be hard set
Allow the JMX RMI server port to be hard set Key: AMQ-892 URL: https://issues.apache.org/activemq/browse/AMQ-892 Project: ActiveMQ Issue Type: Improvement Components: Broker Affects Versions: 4.0.2 Reporter: John Heitmann Priority: Minor Attachments: jmxPort.patch When debugging a broker over the firewall with JMX it's often necessary to use ssh tunneling. JMX uses 2 ports. The RMI registry port is what is typically configured, but JMX also runs an RMI server on a different port-- one that's typically chosen randomly. When you're ssh tunneling you need to know what ports to tunnel to a priori so this is no good. This patch adds a setting to allow the RMI server port to be set in addition to the registry port. This is what it looks like in xml: managementContext connectorPort=11099 rmiServerPort=9 jmxDomainName=org.apache.activemq/ Also I snuck in a one-liner change that will create the connector if the user configured jmx. This seems like the right thing to do, but my JMX experience is pretty limited so it could break in something like Tomcat. Please take a close look at that line before applying. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (AMQ-515) Add option so that producer.send() throws an exception if it would block due to the queue/broker being full.
[ https://issues.apache.org/activemq/browse/AMQ-515?page=comments#action_36821 ] John Heitmann commented on AMQ-515: --- I'm attaching a feature we're using to get 90% of this. It's a per-UsageManager setting that configures whether sends will block on the usage manager (the default/old way) or get an exception thrown back to the producer. Because it's on a usage manager the setting can be applied per destination. I'd prefer this setting to be set on the producer side and passed over the wire, but I don't see a clean way to add it in that wouldn't require an openwire version bump, so the usage manager config is a compromise. Add option so that producer.send() throws an exception if it would block due to the queue/broker being full. Key: AMQ-515 URL: https://issues.apache.org/activemq/browse/AMQ-515 Project: ActiveMQ Issue Type: New Feature Components: JMS client, Broker Reporter: Hiram Chirino Assigned To: John Heitmann Fix For: 4.2 -- 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: openwire command generation
Ok guys. This is probably something really stupid that I'm doing, but so far I am not having much luck adding new scripts to the openwire generator. I've added two groovy scripts, GenerateAmqCppClasses.groovy and GenerateAmqCppHeaders.groovy and the associated java classes in with the rest of the OpenwireXX classes. I've added my groovy scripts into the activemq-core pom with all the rest. I can build the generator and install it. But when I try and run mvn gram:gram (from activemq-core directory) I get an error shown below: [INFO] Evaluating Groovy script: GenerateAmqCcppHeaders.groovy [ERROR] Caught: java.io.IOException: No script called: GenerateAmqCcppHeaders.groovy could be found on the classpath or the file system java.io.IOException: No script called: GenerateAmqCcppHeaders.groovy could be found on the classpath or the file system at org.apache.activemq.maven.GramMojo.execute(GramMojo.java:127) at org.apache.activemq.maven.GramMojo.execute(GramMojo.java:106) Any Idea what I am doing wrong? - Timothy A. Bish -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Hiram Chirino Sent: Thursday, August 17, 2006 8:34 PM To: activemq-dev@geronimo.apache.org Subject: Re: openwire command generation Importance: High Hi Tim, Wild, I just ran it and it was ok. Try setting you MAVEN_OPTS shell variable to something like -Xmx800M Regards, Hiram On 8/17/06, Timothy Bish [EMAIL PROTECTED] wrote: Hey guys I'm trying to understand the openwire command generator. My first task is just getting it to run and generate commands for the current set of clients.. Once I build the broker I attempt to run the generator with Mvn gram:gram from the activemq-core folder. I get tons of errors that look like this: [INFO] [gram:gram] Parsing source files in: [e:\Eclipse\ActiveMQ\activemq-trunk\activemq-core\src\main\java] [INFO] Evaluating Groovy script: GenerateJavaMarshalling.groovy GenerateJavaMarshalling generating files in: src\main\java\org\apache\activemq\openwire\v2 [JAM] Warning: failed to resolve class AsyncCommandChannel [JAM] Warning: failed to resolve class Statistic [JAM] Warning: failed to resolve class MessageListener [JAM] Warning: failed to resolve class QueueSession [JAM] Warning: failed to resolve class Resource [JAM] Warning: failed to resolve class Statistic [JAM] Warning: failed to resolve class JMSException [JAM] Warning: failed to resolve class Queue [JAM] Warning: failed to resolve class Queue [JAM] Warning: failed to resolve class QueueConnectionFactory [JAM] Warning: failed to resolve class QueueConnection [JAM] Warning: failed to resolve class JndiTemplate GenerateJavaMarshalling processing class: LocalTransactionId GenerateJavaMarshalling processing class: PartialCommand GenerateJavaMarshalling processing class: IntegerResponse GenerateJavaMarshalling processing class: ActiveMQQueue Most of the time I end up with a Build Failure with an out of memory exception which looks like the following: [INFO] - [ERROR] FATAL ERROR [INFO] - [INFO] Java heap space [INFO] - [INFO] Trace java.lang.OutOfMemoryError: Java heap space Any clues what is going on here? I need to get this working so that I can go onto trying to get openwire commands generated for activemq-cpp. - Timothy A. Bish -- Regards, Hiram Blog: http://hiramchirino.com
JAAS problems
Hi, I can't seem to get JAAS working. I've defined the login.config as shown on the site, but I get the following error once a connection comes in (the exception is thrown when lc.login is called in JaasAuthenticationBroker.java): javax.security.auth.login.LoginException: unable to find LoginModule class: org.apache.activemq.jaas.GroupPrincipal at javax.security.auth.login.LoginContext.invoke(LoginContext.java:808) at javax.security.auth.login.LoginContext.access$000(LoginContext.java:186) at javax.security.auth.login.LoginContext$4.run(LoginContext.java:683) at java.security.AccessController.doPrivileged(Native Method) at javax.security.auth.login.LoginContext.invokePriv(LoginContext.java:680) at javax.security.auth.login.LoginContext.login(LoginContext.java:579) at org.apache.activemq.security.JaasAuthenticationBroker.addConnection(JaasAuthenticationBroker.java:76) at org.apache.activemq.broker.BrokerFilter.addConnection(BrokerFilter.java:80) at org.apache.activemq.broker.MutableBrokerFilter.addConnection(MutableBrokerFilter.java:90) at org.apache.activemq.broker.AbstractConnection.processAddConnection(AbstractConnection.java:559) at org.apache.activemq.broker.jmx.ManagedTransportConnection.processAddConnection(ManagedTransportConnection.java:83) at org.apache.activemq.command.ConnectionInfo.visit(ConnectionInfo.java:120) at org.apache.activemq.broker.AbstractConnection.service(AbstractConnection.java:228) at org.apache.activemq.broker.TransportConnection$1.onCommand(TransportConnection.java:63) at org.apache.activemq.transport.ResponseCorrelator.onCommand(ResponseCorrelator.java:92) at org.apache.activemq.transport.TransportFilter.onCommand(TransportFilter.java:67) at org.apache.activemq.transport.WireFormatNegotiator.onCommand(WireFormatNegotiator.java:123) at org.apache.activemq.transport.InactivityMonitor.onCommand(InactivityMonitor.java:123) at org.apache.activemq.transport.TransportSupport.doConsume(TransportSupport.java:88) at org.apache.activemq.transport.tcp.SslTransport.doConsume(SslTransport.java:128) at org.apache.activemq.transport.tcp.TcpTransport.run(TcpTransport.java:127) at java.lang.Thread.run(Thread.java:595) As you may have noticed, the class missing is GroupPrincipal. This is because I changed login.config to use that class. I did the same thing using ActiveMQConnectionFactory and there were no problems (well, it obviously couldn't use it as a LoginModule, but it had no problem finding the class). It seems that it can't find classes within org.apache.activemq.jaas. Does anyone know what's going on? Regards, Sepand
Re: How tight is Geronimo integrated?
There will be no clashes. These jars are needed for embedded JCA support used by the JCAFlow and also to provide the WorkManager implementation. The use of the work manager will soon disappear for a basic configuration, and the jca flow is optional, so you should be able to remove them if you want in a near future. On 8/22/06, ftrietsch [EMAIL PROTECTED] wrote: Hi, we're currently evaluating ServiceMix under JBoss AS 4.0.4. What is somewhat irritating to us is that there are a couple of Geronimo internal libraries bundled with the JBoss Deployer (geronimo-transaction and geronimo-connector for example). How tight is the Geronimo integration in fact? Do we have to expect any clashes with JBoss libraries? Thanx for your help, Frank -- View this message in context: http://www.nabble.com/How-tight-is-Geronimo-integrated--tf2144637.html#a5920499 Sent from the ServiceMix - Dev forum at Nabble.com. -- Cheers, Guillaume Nodet
Refactoring code to reduce the amount of code required to write full JBI components
I was wondering about the minimal amount of code required to write a nicely behaving JBI component with proper component, endpoint, deployer and URI/EPR handling etc. e.g. if we were to refactor more of the components in the servicemix-components module into their own module like the jms, http and jsr181 modules - what new code would be required. Or rather how little could we get away with :) So I was wondering if we could do a little bit of refactoring to reduce the amount of code that is really needed to be written on each component. (Some of the other components are way simpler than jms, http and JSR181 support too such as the file component so the code should hopefully be even simpler). I've not had an coffee yet so please excuse any silly ideas but a quick run through the code in the Jms and HTTP components with brief looks at JSR181 led to the following thoughts... * HttpBootstrap JmsBootstrap are pretty much identical apart from the configuration property (incidentally should HttpBootstrap use a HttpConfiguration like JmsBootstrap?) so am wondering if we can push more of its logic up to a base class - maybe allowing the configuration object to be specified as a constructor argument? * HttpLifecycle JmsLifecycle have quite a few similarities. I wonder could we refactor most of the code into the *Configuration and *Endpoint classes so that we could basically share the same Lifecycle classes in most components? * Jms/HttpExternalEndpoint look pretty identical - just dependent on their Jms/HttpEndpoint classes * Jms/HttpResolvedEndpoint pretty much the same bar some constants - maybe moving those into the *Endpoint or *Component classes might make the code simpler? * Jms/HttpSpringComponent - look about the same apart from the use of Jms/HttpEndpoint - I wonder if generics could be used to share a common base class? Basically the only real difference is the type of the endpoint. * Jms/HttpXBeanDeployer - we could maybe use a generic XBeanDeployer which is parameterized on the type of the Endpoint and then call *Endpoint.validate() to avoid needing to write a new class for this unless its absolutely necessary (like it is for JSR181)? I was really just trying to avoid as much of the boiler plate code as possible so we could make more fully-JBI compliant components with as little code as possible. Am thinking the bare minimum would be something like the bootstrap, component, configuration endpoint classes with reusable base classes for most of the other stuff then the consumer/producer classes for doing the actual work. Any other thoughts on how to reduce/simplify the amount of code required? -- James --- http://radio.weblogs.com/0112098/
Re: How tight is Geronimo integrated?
Hi Guillaume, thanx for your fast answer! Cheers, Frank gnodet wrote: There will be no clashes. These jars are needed for embedded JCA support used by the JCAFlow and also to provide the WorkManager implementation. The use of the work manager will soon disappear for a basic configuration, and the jca flow is optional, so you should be able to remove them if you want in a near future. -- View this message in context: http://www.nabble.com/How-tight-is-Geronimo-integrated--tf2144637.html#a5921028 Sent from the ServiceMix - Dev forum at Nabble.com.
Re: ServiceMix 3.0
On 8/22/06, Guillaume Nodet [EMAIL PROTECTED] wrote: I think we should release 3.0 asap. +1 The remaining todos are: * xbean 2.6 release * jencks 1.3 release (dependant on xbean) * check samples and ensure they work I will handled these. Note that the docs still need lots of improvements, but I'm not sure it should really delay the release... I'll try help out on the docs as much as I can (though am on vacation next week) Thoughts ? Did i miss something ? On another related point, it would be nice at the same time to create a 3.0 branch for this release so that development can continue on trunk. Agreed. Though it'd be nice ot hold off doing too much development until 3.0 is out the door to minimise the backporting of fixes etc -- James --- http://radio.weblogs.com/0112098/
Re: ServiceMix 3.0
On 8/22/06, James Strachan [EMAIL PROTECTED] wrote: On 8/22/06, Guillaume Nodet [EMAIL PROTECTED] wrote: I think we should release 3.0 asap. +1 The remaining todos are: * xbean 2.6 release * jencks 1.3 release (dependant on xbean) * check samples and ensure they work I will handled these. Note that the docs still need lots of improvements, but I'm not sure it should really delay the release... I'll try help out on the docs as much as I can (though am on vacation next week) Thoughts ? Did i miss something ? On another related point, it would be nice at the same time to create a 3.0 branch for this release so that development can continue on trunk. Agreed. Though it'd be nice ot hold off doing too much development until 3.0 is out the door to minimise the backporting of fixes etc New development and fixes are two different problems imho. -- James --- http://radio.weblogs.com/0112098/ -- Cheers, Guillaume Nodet
Re: ServiceMix 3.0
On 8/22/06, Guillaume Nodet [EMAIL PROTECTED] wrote: On 8/22/06, James Strachan [EMAIL PROTECTED] wrote: On 8/22/06, Guillaume Nodet [EMAIL PROTECTED] wrote: I think we should release 3.0 asap. +1 The remaining todos are: * xbean 2.6 release * jencks 1.3 release (dependant on xbean) * check samples and ensure they work I will handled these. Note that the docs still need lots of improvements, but I'm not sure it should really delay the release... I'll try help out on the docs as much as I can (though am on vacation next week) Thoughts ? Did i miss something ? On another related point, it would be nice at the same time to create a 3.0 branch for this release so that development can continue on trunk. Agreed. Though it'd be nice ot hold off doing too much development until 3.0 is out the door to minimise the backporting of fixes etc New development and fixes are two different problems imho. Agreed - though backporting of fixes from trunk to a branch can be time consuming; so it might be worth us all holding off for a couple of weeks doing lots of new development until we've got the 3.0 release cooked. No biggie -- James --- http://radio.weblogs.com/0112098/
[jira] Updated: (SM-403) The JMS spec mandates that all properties on JMS message are valid java identifiers
[ https://issues.apache.org/activemq/browse/SM-403?page=all ] Guillaume Nodet updated SM-403: --- Fix Version/s: 3.0-M3 The JMS spec mandates that all properties on JMS message are valid java identifiers Key: SM-403 URL: https://issues.apache.org/activemq/browse/SM-403 Project: ServiceMix Issue Type: Bug Components: servicemix-jms Reporter: Guillaume Nodet Fix For: 3.0-M3 -- 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: DeployServiceAssemblyTask Problem!!!
Thanks for your reploy Guillaume. But I still don't see how it's being fixed. I'm expecting the file being uploaded to SM server but it's still looking at its local file system. Also, putting the SA file at a URL on certain web server is not good solution for me because it requires addiontal setup. All I want is to be able to upload the SA zip file to the remote server, which then unpacks and deployes it. Lei gnodet wrote: This has already been fixed. Try using a snapshot version. On 8/22/06, leiolay [EMAIL PROTECTED] wrote: Hi, I'm trying deploy a SA to a remote machine using the DeployServiceAssemblyTask ant task. However I got the following error on the server: 2006-08-21 11:49:23 ERROR - Error deploying service assembly java.lang.Exception: ?xml version=1.0 encoding=UTF-8? jbi-task xmlns=http://java.sun.com/xml/ns/jbi/management-message; version=1.0 jbi-task-result frmwk-task-result frmwk-task-result-details task-result-details task-iddeploy/task-id task-resultFAILED/task-result message-typeERROR/message-type task-status-msg msg-loc-info loc-token/ loc-messageUnable to unpack archive: c:\opt\sfc\kronos-engine\local\kronos-engine-sa.zip/loc-message /msg-loc-info /task-status-msg exception-info nesting-level1/nesting-level loc-token/ loc-messagejava.net.MalformedURLException: unknown protocol: c/loc-message stack-trace![CDATA[javax.jbi.management.DeploymentException: java.net.MalformedURLException: unknown protocol: c at org.apache.servicemix.jbi.framework.AutoDeploymentService.unpackLocation( AutoDeploymentService.java:442) at org.apache.servicemix.jbi.framework.DeploymentService.deploy( DeploymentService.java:181) at org.apache.servicemix.jbi.framework.AdminCommandsService.deployServiceAssembly (AdminCommandsService.java:175) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) at java.lang.reflect.Method.invoke(Unknown Source) at org.apache.commons.beanutils.MethodUtils.invokeMethod(MethodUtils.java :216) at org.apache.servicemix.jbi.management.BaseStandardMBean.invoke( BaseStandardMBean.java:315) at com.sun.jmx.mbeanserver.DynamicMetaDataImpl.invoke(Unknown Source) at com.sun.jmx.mbeanserver.MetaDataImpl.invoke(Unknown Source) at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(Unknown Source) at com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(Unknown Source) at javax.management.remote.rmi.RMIConnectionImpl.doOperation (Unknown Source) at javax.management.remote.rmi.RMIConnectionImpl.access$100 (Unknown Source) at javax.management.remote.rmi.RMIConnectionImpl$PrivilegedOperation.run (Unknown Source) at javax.management.remote.rmi.RMIConnectionImpl.doPrivilegedOperation (Unknown Source) at javax.management.remote.rmi.RMIConnectionImpl.invoke(Unknown Source) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) at java.lang.reflect.Method.invoke(Unknown Source) at sun.rmi.server.UnicastServerRef.dispatch(Unknown Source) at sun.rmi.transport.Transport$1.run(Unknown Source) at java.security.AccessController.doPrivileged(Native Method) at sun.rmi.transport.Transport.serviceCall(Unknown Source) at sun.rmi.transport.tcp.TCPTransport.handleMessages(Unknown Source) at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run (Unknown Source) at java.lang.Thread.run(Unknown Source) Caused by: java.net.MalformedURLException: unknown protocol: c at java.net.URL.init(Unknown Source) at java.net.URL.init(Unknown Source) at java.net.URL.init(Unknown Source) at org.apache.servicemix.jbi.framework.AutoDeploymentService.unpackLocation( AutoDeploymentService.java:435) ... 28 more ]]/stack-trace /exception-info /task-result-details /frmwk-task-result-details /frmwk-task-result /jbi-task-result /jbi-task at org.apache.servicemix.jbi.framework.ManagementSupport.failure( ManagementSupport.java:120) at org.apache.servicemix.jbi.framework.ManagementSupport.failure( ManagementSupport.java:110) at org.apache.servicemix.jbi.framework.DeploymentService.deploy( DeploymentService.java:183) at org.apache.servicemix.jbi.framework.AdminCommandsService.deployServiceAssembly (AdminCommandsService.java:175) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown
Re: DeployServiceAssemblyTask Problem!!!
btw i downloaded the latest snapshot apache-servicemix-3.0-incubating-20060813.140148-3.tar.gz. It gives me the same error, as I have expected. leiolay wrote: Thanks for your reploy Guillaume. But I still don't see how it's being fixed. I'm expecting the file being uploaded to SM server but it's still looking at its local file system. Also, putting the SA file at a URL on certain web server is not good solution for me because it requires addiontal setup. All I want is to be able to upload the SA zip file to the remote server, which then unpacks and deployes it. Lei gnodet wrote: This has already been fixed. Try using a snapshot version. On 8/22/06, leiolay [EMAIL PROTECTED] wrote: Hi, I'm trying deploy a SA to a remote machine using the DeployServiceAssemblyTask ant task. However I got the following error on the server: 2006-08-21 11:49:23 ERROR - Error deploying service assembly java.lang.Exception: ?xml version=1.0 encoding=UTF-8? jbi-task xmlns=http://java.sun.com/xml/ns/jbi/management-message; version=1.0 jbi-task-result frmwk-task-result frmwk-task-result-details task-result-details task-iddeploy/task-id task-resultFAILED/task-result message-typeERROR/message-type task-status-msg msg-loc-info loc-token/ loc-messageUnable to unpack archive: c:\opt\sfc\kronos-engine\local\kronos-engine-sa.zip/loc-message /msg-loc-info /task-status-msg exception-info nesting-level1/nesting-level loc-token/ loc-messagejava.net.MalformedURLException: unknown protocol: c/loc-message stack-trace![CDATA[javax.jbi.management.DeploymentException: java.net.MalformedURLException: unknown protocol: c at org.apache.servicemix.jbi.framework.AutoDeploymentService.unpackLocation( AutoDeploymentService.java:442) at org.apache.servicemix.jbi.framework.DeploymentService.deploy( DeploymentService.java:181) at org.apache.servicemix.jbi.framework.AdminCommandsService.deployServiceAssembly (AdminCommandsService.java:175) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) at java.lang.reflect.Method.invoke(Unknown Source) at org.apache.commons.beanutils.MethodUtils.invokeMethod(MethodUtils.java :216) at org.apache.servicemix.jbi.management.BaseStandardMBean.invoke( BaseStandardMBean.java:315) at com.sun.jmx.mbeanserver.DynamicMetaDataImpl.invoke(Unknown Source) at com.sun.jmx.mbeanserver.MetaDataImpl.invoke(Unknown Source) at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(Unknown Source) at com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(Unknown Source) at javax.management.remote.rmi.RMIConnectionImpl.doOperation (Unknown Source) at javax.management.remote.rmi.RMIConnectionImpl.access$100 (Unknown Source) at javax.management.remote.rmi.RMIConnectionImpl$PrivilegedOperation.run (Unknown Source) at javax.management.remote.rmi.RMIConnectionImpl.doPrivilegedOperation (Unknown Source) at javax.management.remote.rmi.RMIConnectionImpl.invoke(Unknown Source) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) at java.lang.reflect.Method.invoke(Unknown Source) at sun.rmi.server.UnicastServerRef.dispatch(Unknown Source) at sun.rmi.transport.Transport$1.run(Unknown Source) at java.security.AccessController.doPrivileged(Native Method) at sun.rmi.transport.Transport.serviceCall(Unknown Source) at sun.rmi.transport.tcp.TCPTransport.handleMessages(Unknown Source) at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run (Unknown Source) at java.lang.Thread.run(Unknown Source) Caused by: java.net.MalformedURLException: unknown protocol: c at java.net.URL.init(Unknown Source) at java.net.URL.init(Unknown Source) at java.net.URL.init(Unknown Source) at org.apache.servicemix.jbi.framework.AutoDeploymentService.unpackLocation( AutoDeploymentService.java:435) ... 28 more ]]/stack-trace /exception-info /task-result-details /frmwk-task-result-details /frmwk-task-result /jbi-task-result /jbi-task at org.apache.servicemix.jbi.framework.ManagementSupport.failure( ManagementSupport.java:120) at org.apache.servicemix.jbi.framework.ManagementSupport.failure( ManagementSupport.java:110) at org.apache.servicemix.jbi.framework.DeploymentService.deploy( DeploymentService.java:183) at org.apache.servicemix.jbi.framework.AdminCommandsService.deployServiceAssembly (AdminCommandsService.java:175) at
Re: DeployServiceAssemblyTask Problem!!!
What is the url you passed as an argument to the ant task ? On 8/22/06, leiolay [EMAIL PROTECTED] wrote: btw i downloaded the latest snapshot apache-servicemix-3.0-incubating-20060813.140148-3.tar.gz. It gives me the same error, as I have expected. leiolay wrote: Thanks for your reploy Guillaume. But I still don't see how it's being fixed. I'm expecting the file being uploaded to SM server but it's still looking at its local file system. Also, putting the SA file at a URL on certain web server is not good solution for me because it requires addiontal setup. All I want is to be able to upload the SA zip file to the remote server, which then unpacks and deployes it. Lei gnodet wrote: This has already been fixed. Try using a snapshot version. On 8/22/06, leiolay [EMAIL PROTECTED] wrote: Hi, I'm trying deploy a SA to a remote machine using the DeployServiceAssemblyTask ant task. However I got the following error on the server: 2006-08-21 11:49:23 ERROR - Error deploying service assembly java.lang.Exception: ?xml version=1.0 encoding=UTF-8? jbi-task xmlns=http://java.sun.com/xml/ns/jbi/management-message; version=1.0 jbi-task-result frmwk-task-result frmwk-task-result-details task-result-details task-iddeploy/task-id task-resultFAILED/task-result message-typeERROR/message-type task-status-msg msg-loc-info loc-token/ loc-messageUnable to unpack archive: c:\opt\sfc\kronos-engine\local\kronos-engine-sa.zip/loc-message /msg-loc-info /task-status-msg exception-info nesting-level1/nesting-level loc-token/ loc-messagejava.net.MalformedURLException: unknown protocol: c/loc-message stack-trace![CDATA[javax.jbi.management.DeploymentException: java.net.MalformedURLException: unknown protocol: c at org.apache.servicemix.jbi.framework.AutoDeploymentService.unpackLocation( AutoDeploymentService.java:442) at org.apache.servicemix.jbi.framework.DeploymentService.deploy( DeploymentService.java:181) at org.apache.servicemix.jbi.framework.AdminCommandsService.deployServiceAssembly (AdminCommandsService.java:175) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) at java.lang.reflect.Method.invoke(Unknown Source) at org.apache.commons.beanutils.MethodUtils.invokeMethod(MethodUtils.java :216) at org.apache.servicemix.jbi.management.BaseStandardMBean.invoke( BaseStandardMBean.java:315) at com.sun.jmx.mbeanserver.DynamicMetaDataImpl.invoke(Unknown Source) at com.sun.jmx.mbeanserver.MetaDataImpl.invoke(Unknown Source) at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(Unknown Source) at com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(Unknown Source) at javax.management.remote.rmi.RMIConnectionImpl.doOperation (Unknown Source) at javax.management.remote.rmi.RMIConnectionImpl.access$100 (Unknown Source) at javax.management.remote.rmi.RMIConnectionImpl$PrivilegedOperation.run (Unknown Source) at javax.management.remote.rmi.RMIConnectionImpl.doPrivilegedOperation (Unknown Source) at javax.management.remote.rmi.RMIConnectionImpl.invoke (Unknown Source) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) at java.lang.reflect.Method.invoke(Unknown Source) at sun.rmi.server.UnicastServerRef.dispatch(Unknown Source) at sun.rmi.transport.Transport$1.run(Unknown Source) at java.security.AccessController.doPrivileged(Native Method) at sun.rmi.transport.Transport.serviceCall(Unknown Source) at sun.rmi.transport.tcp.TCPTransport.handleMessages(Unknown Source) at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run (Unknown Source) at java.lang.Thread.run(Unknown Source) Caused by: java.net.MalformedURLException: unknown protocol: c at java.net.URL.init(Unknown Source) at java.net.URL.init(Unknown Source) at java.net.URL.init(Unknown Source) at org.apache.servicemix.jbi.framework.AutoDeploymentService.unpackLocation( AutoDeploymentService.java:435) ... 28 more ]]/stack-trace /exception-info /task-result-details /frmwk-task-result-details /frmwk-task-result /jbi-task-result /jbi-task at org.apache.servicemix.jbi.framework.ManagementSupport.failure( ManagementSupport.java:120) at org.apache.servicemix.jbi.framework.ManagementSupport.failure( ManagementSupport.java:110) at org.apache.servicemix.jbi.framework.DeploymentService.deploy( DeploymentService.java:183) at
Re: DeployServiceAssemblyTask Problem!!!
/opt/sfc/kronos-engine/superdev/kronos-engine-sa.zip, which maps to c:\opt\sfc\kronos-engine\superdev\kronos-engine-sa.zip on my WinXP machine. I'm trying deploy this onto a Solaris box. gnodet wrote: What is the url you passed as an argument to the ant task ? On 8/22/06, leiolay [EMAIL PROTECTED] wrote: btw i downloaded the latest snapshot apache-servicemix-3.0-incubating-20060813.140148-3.tar.gz. It gives me the same error, as I have expected. leiolay wrote: Thanks for your reploy Guillaume. But I still don't see how it's being fixed. I'm expecting the file being uploaded to SM server but it's still looking at its local file system. Also, putting the SA file at a URL on certain web server is not good solution for me because it requires addiontal setup. All I want is to be able to upload the SA zip file to the remote server, which then unpacks and deployes it. Lei gnodet wrote: This has already been fixed. Try using a snapshot version. On 8/22/06, leiolay [EMAIL PROTECTED] wrote: Hi, I'm trying deploy a SA to a remote machine using the DeployServiceAssemblyTask ant task. However I got the following error on the server: 2006-08-21 11:49:23 ERROR - Error deploying service assembly java.lang.Exception: ?xml version=1.0 encoding=UTF-8? jbi-task xmlns=http://java.sun.com/xml/ns/jbi/management-message; version=1.0 jbi-task-result frmwk-task-result frmwk-task-result-details task-result-details task-iddeploy/task-id task-resultFAILED/task-result message-typeERROR/message-type task-status-msg msg-loc-info loc-token/ loc-messageUnable to unpack archive: c:\opt\sfc\kronos-engine\local\kronos-engine-sa.zip/loc-message /msg-loc-info /task-status-msg exception-info nesting-level1/nesting-level loc-token/ loc-messagejava.net.MalformedURLException: unknown protocol: c/loc-message stack-trace![CDATA[javax.jbi.management.DeploymentException: java.net.MalformedURLException: unknown protocol: c at org.apache.servicemix.jbi.framework.AutoDeploymentService.unpackLocation( AutoDeploymentService.java:442) at org.apache.servicemix.jbi.framework.DeploymentService.deploy( DeploymentService.java:181) at org.apache.servicemix.jbi.framework.AdminCommandsService.deployServiceAssembly (AdminCommandsService.java:175) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) at java.lang.reflect.Method.invoke(Unknown Source) at org.apache.commons.beanutils.MethodUtils.invokeMethod(MethodUtils.java :216) at org.apache.servicemix.jbi.management.BaseStandardMBean.invoke( BaseStandardMBean.java:315) at com.sun.jmx.mbeanserver.DynamicMetaDataImpl.invoke(Unknown Source) at com.sun.jmx.mbeanserver.MetaDataImpl.invoke(Unknown Source) at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(Unknown Source) at com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(Unknown Source) at javax.management.remote.rmi.RMIConnectionImpl.doOperation (Unknown Source) at javax.management.remote.rmi.RMIConnectionImpl.access$100 (Unknown Source) at javax.management.remote.rmi.RMIConnectionImpl$PrivilegedOperation.run (Unknown Source) at javax.management.remote.rmi.RMIConnectionImpl.doPrivilegedOperation (Unknown Source) at javax.management.remote.rmi.RMIConnectionImpl.invoke (Unknown Source) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) at java.lang.reflect.Method.invoke(Unknown Source) at sun.rmi.server.UnicastServerRef.dispatch(Unknown Source) at sun.rmi.transport.Transport$1.run(Unknown Source) at java.security.AccessController.doPrivileged(Native Method) at sun.rmi.transport.Transport.serviceCall(Unknown Source) at sun.rmi.transport.tcp.TCPTransport.handleMessages(Unknown Source) at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run (Unknown Source) at java.lang.Thread.run(Unknown Source) Caused by: java.net.MalformedURLException: unknown protocol: c at java.net.URL.init(Unknown Source) at java.net.URL.init(Unknown Source) at java.net.URL.init(Unknown Source) at org.apache.servicemix.jbi.framework.AutoDeploymentService.unpackLocation( AutoDeploymentService.java:435) ... 28 more ]]/stack-trace /exception-info /task-result-details /frmwk-task-result-details /frmwk-task-result /jbi-task-result /jbi-task at
Re: DeployServiceAssemblyTask Problem!!!
Oh, I understand now. You want to upload the file with the ant task ? Well, that's not possible :( On 8/22/06, leiolay [EMAIL PROTECTED] wrote: /opt/sfc/kronos-engine/superdev/kronos-engine-sa.zip, which maps to c:\opt\sfc\kronos-engine\superdev\kronos-engine-sa.zip on my WinXP machine. I'm trying deploy this onto a Solaris box. gnodet wrote: What is the url you passed as an argument to the ant task ? On 8/22/06, leiolay [EMAIL PROTECTED] wrote: btw i downloaded the latest snapshot apache-servicemix-3.0-incubating-20060813.140148-3.tar.gz. It gives me the same error, as I have expected. leiolay wrote: Thanks for your reploy Guillaume. But I still don't see how it's being fixed. I'm expecting the file being uploaded to SM server but it's still looking at its local file system. Also, putting the SA file at a URL on certain web server is not good solution for me because it requires addiontal setup. All I want is to be able to upload the SA zip file to the remote server, which then unpacks and deployes it. Lei gnodet wrote: This has already been fixed. Try using a snapshot version. On 8/22/06, leiolay [EMAIL PROTECTED] wrote: Hi, I'm trying deploy a SA to a remote machine using the DeployServiceAssemblyTask ant task. However I got the following error on the server: 2006-08-21 11:49:23 ERROR - Error deploying service assembly java.lang.Exception: ?xml version=1.0 encoding=UTF-8? jbi-task xmlns=http://java.sun.com/xml/ns/jbi/management-message; version=1.0 jbi-task-result frmwk-task-result frmwk-task-result-details task-result-details task-iddeploy/task-id task-resultFAILED/task-result message-typeERROR/message-type task-status-msg msg-loc-info loc-token/ loc-messageUnable to unpack archive: c:\opt\sfc\kronos-engine\local\kronos-engine-sa.zip/loc-message /msg-loc-info /task-status-msg exception-info nesting-level1/nesting-level loc-token/ loc-messagejava.net.MalformedURLException: unknown protocol: c/loc-message stack-trace![CDATA[javax.jbi.management.DeploymentException: java.net.MalformedURLException: unknown protocol: c at org.apache.servicemix.jbi.framework.AutoDeploymentService.unpackLocation( AutoDeploymentService.java:442) at org.apache.servicemix.jbi.framework.DeploymentService.deploy( DeploymentService.java:181) at org.apache.servicemix.jbi.framework.AdminCommandsService.deployServiceAssembly (AdminCommandsService.java:175) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) at java.lang.reflect.Method.invoke(Unknown Source) at org.apache.commons.beanutils.MethodUtils.invokeMethod(MethodUtils.java :216) at org.apache.servicemix.jbi.management.BaseStandardMBean.invoke( BaseStandardMBean.java:315) at com.sun.jmx.mbeanserver.DynamicMetaDataImpl.invoke (Unknown Source) at com.sun.jmx.mbeanserver.MetaDataImpl.invoke(Unknown Source) at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke (Unknown Source) at com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(Unknown Source) at javax.management.remote.rmi.RMIConnectionImpl.doOperation (Unknown Source) at javax.management.remote.rmi.RMIConnectionImpl.access$100 (Unknown Source) at javax.management.remote.rmi.RMIConnectionImpl$PrivilegedOperation.run (Unknown Source) at javax.management.remote.rmi.RMIConnectionImpl.doPrivilegedOperation (Unknown Source) at javax.management.remote.rmi.RMIConnectionImpl.invoke (Unknown Source) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) at java.lang.reflect.Method.invoke(Unknown Source) at sun.rmi.server.UnicastServerRef.dispatch(Unknown Source) at sun.rmi.transport.Transport$1.run(Unknown Source) at java.security.AccessController.doPrivileged(Native Method) at sun.rmi.transport.Transport.serviceCall(Unknown Source) at sun.rmi.transport.tcp.TCPTransport.handleMessages (Unknown Source) at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run (Unknown Source) at java.lang.Thread.run(Unknown Source) Caused by: java.net.MalformedURLException: unknown protocol: c at java.net.URL.init(Unknown Source) at java.net.URL.init(Unknown Source) at java.net.URL.init(Unknown Source) at org.apache.servicemix.jbi.framework.AutoDeploymentService.unpackLocation( AutoDeploymentService.java:435) ... 28 more
Re: DeployServiceAssemblyTask Problem!!!
I'm kinda in a shock to realize that the ant task doesn't support remote deployment. To me, the JBI ant tasks are useless. If both build and deploy are on the same machine, I could just write an ant task simply to copy the file to deploy directory to achieve the same thing. As matter of fact, remote deployment using ant is the only deployment approach for our production J2EE application running on Weblogic and tomcat. This way build machine doesn't have to be the same as the server machine. Is there a plan to enhance the ant tasks in the future? Lei gnodet wrote: Oh, I understand now. You want to upload the file with the ant task ? Well, that's not possible :( On 8/22/06, leiolay [EMAIL PROTECTED] wrote: /opt/sfc/kronos-engine/superdev/kronos-engine-sa.zip, which maps to c:\opt\sfc\kronos-engine\superdev\kronos-engine-sa.zip on my WinXP machine. I'm trying deploy this onto a Solaris box. gnodet wrote: What is the url you passed as an argument to the ant task ? On 8/22/06, leiolay [EMAIL PROTECTED] wrote: btw i downloaded the latest snapshot apache-servicemix-3.0-incubating-20060813.140148-3.tar.gz. It gives me the same error, as I have expected. leiolay wrote: Thanks for your reploy Guillaume. But I still don't see how it's being fixed. I'm expecting the file being uploaded to SM server but it's still looking at its local file system. Also, putting the SA file at a URL on certain web server is not good solution for me because it requires addiontal setup. All I want is to be able to upload the SA zip file to the remote server, which then unpacks and deployes it. Lei gnodet wrote: This has already been fixed. Try using a snapshot version. On 8/22/06, leiolay [EMAIL PROTECTED] wrote: Hi, I'm trying deploy a SA to a remote machine using the DeployServiceAssemblyTask ant task. However I got the following error on the server: 2006-08-21 11:49:23 ERROR - Error deploying service assembly java.lang.Exception: ?xml version=1.0 encoding=UTF-8? jbi-task xmlns=http://java.sun.com/xml/ns/jbi/management-message; version=1.0 jbi-task-result frmwk-task-result frmwk-task-result-details task-result-details task-iddeploy/task-id task-resultFAILED/task-result message-typeERROR/message-type task-status-msg msg-loc-info loc-token/ loc-messageUnable to unpack archive: c:\opt\sfc\kronos-engine\local\kronos-engine-sa.zip/loc-message /msg-loc-info /task-status-msg exception-info nesting-level1/nesting-level loc-token/ loc-messagejava.net.MalformedURLException: unknown protocol: c/loc-message stack-trace![CDATA[javax.jbi.management.DeploymentException: java.net.MalformedURLException: unknown protocol: c at org.apache.servicemix.jbi.framework.AutoDeploymentService.unpackLocation( AutoDeploymentService.java:442) at org.apache.servicemix.jbi.framework.DeploymentService.deploy( DeploymentService.java:181) at org.apache.servicemix.jbi.framework.AdminCommandsService.deployServiceAssembly (AdminCommandsService.java:175) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) at java.lang.reflect.Method.invoke(Unknown Source) at org.apache.commons.beanutils.MethodUtils.invokeMethod(MethodUtils.java :216) at org.apache.servicemix.jbi.management.BaseStandardMBean.invoke( BaseStandardMBean.java:315) at com.sun.jmx.mbeanserver.DynamicMetaDataImpl.invoke (Unknown Source) at com.sun.jmx.mbeanserver.MetaDataImpl.invoke(Unknown Source) at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke (Unknown Source) at com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(Unknown Source) at javax.management.remote.rmi.RMIConnectionImpl.doOperation (Unknown Source) at javax.management.remote.rmi.RMIConnectionImpl.access$100 (Unknown Source) at javax.management.remote.rmi.RMIConnectionImpl$PrivilegedOperation.run (Unknown Source) at javax.management.remote.rmi.RMIConnectionImpl.doPrivilegedOperation (Unknown Source) at javax.management.remote.rmi.RMIConnectionImpl.invoke (Unknown Source) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) at java.lang.reflect.Method.invoke(Unknown Source) at sun.rmi.server.UnicastServerRef.dispatch(Unknown Source) at sun.rmi.transport.Transport$1.run(Unknown
Re: [VOTE] Specs organization, versioning, and releasing
Close our eyes? Why should it matter? They can all live in the same tree... just some with 1.5 and some with 1.4 compiles. --jason On Aug 21, 2006, at 10:44 PM, David Blevins wrote: On Aug 21, 2006, at 7:13 PM, Kevan Miller wrote: I think the source of complexity is the granularity of versioning we're trying to apply to specs... I wonder if the simplest course of action is to stop releasing individually versioned specs, and instead always release all specs. When an update to the 1.2.0 specs are required, release a 1.2.1 version of all specs (even if some of the 1.2.1 versions are identical to their 1.2.0 version). This just came into mind. Any thoughts on what we'd do for the specs that are javaee 5 only versions (corba, servlet, soon jta and ejb, etc.) and the ones that overlap between j2ee 1.4 and javaee 5 like jms, jca and jacc? -David
Re: [VOTE] Specs organization, versioning, and releasing
On Aug 21, 2006, at 11:09 PM, Jason Dillon wrote: Close our eyes? Why should it matter? They can all live in the same tree... just some with 1.5 and some with 1.4 compiles. I think you read the email too fast :) -David --jason On Aug 21, 2006, at 10:44 PM, David Blevins wrote: On Aug 21, 2006, at 7:13 PM, Kevan Miller wrote: I think the source of complexity is the granularity of versioning we're trying to apply to specs... I wonder if the simplest course of action is to stop releasing individually versioned specs, and instead always release all specs. When an update to the 1.2.0 specs are required, release a 1.2.1 version of all specs (even if some of the 1.2.1 versions are identical to their 1.2.0 version). This just came into mind. Any thoughts on what we'd do for the specs that are javaee 5 only versions (corba, servlet, soon jta and ejb, etc.) and the ones that overlap between j2ee 1.4 and javaee 5 like jms, jca and jacc? -David
[jira] Updated: (GERONIMO-2326) unable to deploy a database pool
[ http://issues.apache.org/jira/browse/GERONIMO-2326?page=all ] David Jencks updated GERONIMO-2326: --- Attachment: GERONIMO-2326.djencks.patch I worked on the dependencies and may have solved the dependency problems. I'm having problems apparently with the portlet deploying a local tx derby db pool and some weird problem with the portlet getting and empty string for one of the jars deploying a derby xa pool. I'm attaching my progress so far as I may not have internet access for a while. unable to deploy a database pool Key: GERONIMO-2326 URL: http://issues.apache.org/jira/browse/GERONIMO-2326 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Affects Versions: 1.2, 1.1.2 Reporter: Bill Dudney Assigned To: David Jencks Fix For: 1.1.2, 1.2 Attachments: 2326-deploy-datasource.patch, GERONIMO-2326.djencks.patch Trying to deploy a jdbc datasource leads to a blank screen and the following stack trace in the log. The issue appears to be that URLPatternSpec does not like the URL generated by DatabasePoolPortlet from the info found in the DatabaseInfo.ALL_DATABASES array. java.lang.IllegalArgumentException: Qualifier patterns must be present when first URLPattern is an exact pattern at javax.security.jacc.URLPatternSpec.init(URLPatternSpec.java:98) at javax.security.jacc.WebUserDataPermission.init(WebUserDataPermission.java:83) at org.apache.geronimo.tomcat.realm.TomcatGeronimoRealm.hasUserDataPermission(TomcatGeronimoRealm.java:131) at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:460) at org.apache.geronimo.tomcat.GeronimoStandardContext$SystemMethodValve.invoke(GeronimoStandardContext.java:322) at org.apache.geronimo.tomcat.valve.GeronimoBeforeAfterValve.invoke(GeronimoBeforeAfterValve.java:31) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:869) at org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection(Http11BaseProtocol.java:667) at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:527) at org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(LeaderFollowerWorkerThread.java:80) at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:684) at java.lang.Thread.run(Thread.java:552) -- 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: Handling of LICENSE.txt and NOTICE.txt on trunk
Okay, I take it back... Maven plugin dependency handling is
completely broke, as it pollutes the classpath of other plugins...
With this change the car plugin starts to barf... so for the time
being I'm backing this out.
--jason
On Aug 21, 2006, at 10:54 PM, Jason Dillon wrote:
I recently discovered that if a parent pom adds an antrun plugin
execution to build, that children can not add dependencies, which
causes some problems further down in the build. I was going to use
antrun to install LICENSE.txt and NOTICE.txt into target/classes/
META-INF as a work around to the problem that occurs when we added
them to build/resources that caused the maven-eclipse-plugin to barf.
So I finally gave up and create a new plugin which allows Groovy
scripts to be executed inline and with the AntBuilder we can
execute Ant bits, as well as perform logic operations all within a
pom. And I setup the project-config pom to add an execution that
will copy LICENSE.txt and NOTICE.txt from the module root to target/
classes/META-INF for all modules unless the packaging is pom, with:
plugin
groupIdorg.apache.geronimo.genesis.plugins/groupId
artifactIdscript-maven-plugin/artifactId
version1.0.0-SNAPSHOT/version
executions
execution
idinstall-licenses-and-notice/id
phasegenerate-resources/phase
goals
goalgroovy/goal
/goals
configuration
code
if (project.packaging != pom) {
def ant = new AntBuilder()
def dir = ${project.basedir}/target/
classes/META-INF
ant.mkdir(dir: dir)
ant.copy(todir: dir) {
fileset(dir: ${project.basedir}) {
include(name: LICENSE.txt)
include(name: NOTICE.txt)
}
}
}
/code
/configuration
/execution
/executions
/plugin
The new script-maven-plugin is a tad different than the groovy-
maven-plugin in the mojo sandbox, primarily allows the code for the
script to be defined in the pom or at an external URL. Also allows
extra dependencies to be added outside of the normal Maven plugin
dependency mechanism, since antrun has shown that it is broken for
parent and child configurations.
There are still however a few issues remaining that prevent `mvn
eclipse:eclipse` from generating clean .classpath files, which will
be fixed when we move modules to use the standard m2 layout.
--jason
How tight is Geronimo integrated?
Hi, we're currently evaluating ServiceMix under JBoss AS 4.0.4. What is somewhat irritating to us is that there are a couple of Geronimo internal libraries bundled with the JBoss Deployer (geronimo-transaction and geronimo-connector for example). How tight is the Geronimo integration in fact? Do we have to expect any clashes with JBoss libraries? Thanx for your help, Frank -- View this message in context: http://www.nabble.com/How-tight-is-Geronimo-integrated--tf2144637.html#a5920499 Sent from the ServiceMix - Dev forum at Nabble.com.
[jira] Assigned: (GERONIMO-2274) realm-principal does not work in web app security
[ http://issues.apache.org/jira/browse/GERONIMO-2274?page=all ] Alan Cabrera reassigned GERONIMO-2274: -- Assignee: Alan Cabrera (was: Vamsavardhana Reddy) realm-principal does not work in web app security - Key: GERONIMO-2274 URL: http://issues.apache.org/jira/browse/GERONIMO-2274 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: security Affects Versions: 1.1 Environment: WinXP, G1.1.1-SNAPSHOT, Tomcat Reporter: Vamsavardhana Reddy Assigned To: Alan Cabrera Fix For: 1.1.2, 1.2 Attachments: GERONIMO-2274.patch, geronimo-web.xml, sql-realm-advanced.xml I have deployed a security realm with wrap-principals set to true. Then, I have deployed a web application to authenticate against this security realm. In the web app deployment plan, I have used realm-principal in role mapping. Even though login is successful, I am getting Error HTTP 403 Forbidden. Authorization works as expected if I use login-domain-principal or principal instead of realm-principal. Appears like realm-principal is not working as expected. -- 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
maven-geronimodevtools-plugin specifying source directory
Hi, I've a massive pain in my head trying to incorporate the building of Eclipse plugins into a Maven build system. It would be much simpler to just use Maven to build them all if possible. I've just discovered maven-geronimodevtools-plugin and it looks like it fits the bill perfectly. I've been playing with it a little but cannot get maven to pick up the source directory for the plugin. When I build the Geronimo eclipse plugins, the compileSourceRoot property is set to ./src whereas when I build my own plugins, it is set to ./src/main/java, the default value. I've grepped through the files in the Geronimo eclipse-plugin project but cannot find where the source directory is set. Can anyone point me to how to configure compileSourceRoot for maven- geronimodevtools-plugin? On a related note, has this plugin been released yet? thanks Conrad
Release XBean 2.6 ?
I'd like to release XBean 2.6 asap. I wanted to delay it until qdox 1.6 is out, which is now done. Unfortunately, it is compiled with JDK 5, and thus i think we can not use it, unless we all agree to put a JDK 5 dependency at compilation time (as qdox is only used to generate the mapping). There is also one JIRA in RTC about the classloader module, so if people could vote on it ... Or should be delay it until next release ? Another problem is that we will need a release of the genesis stuff ... Thoughts ? -- Cheers, Guillaume Nodet
Re: ServiceMix 3.0
On 8/22/06, Guillaume Nodet [EMAIL PROTECTED] wrote: I think we should release 3.0 asap. The remaining todos are: * xbean 2.6 release * jencks 1.3 release (dependant on xbean) How far off are these two? * check samples and ensure they work Are there tests for the samples? Maybe we should consider creating some so it's easier and faster to determine if they're working or not? But, then again, maybe this is going too far. I will handled these. Note that the docs still need lots of improvements, but I'm not sure it should really delay the release... Thoughts ? Did i miss something ? On another related point, it would be nice at the same time to create a 3.0 branch for this release so that development can continue on trunk. Agreed, a branch is a necessity. Bruce -- perl -e 'print unpack(u30,D0G)[EMAIL PROTECTED]5R\F)R=6-E+G-N61ED\!G;6%I;\YC;VT* );' Apache Geronimo - http://geronimo.apache.org/ Apache ActiveMQ - http://incubator.apache.org/activemq/ Apache ServiceMix - http://incubator.apache.org/servicemix/ Castor - http://castor.org/
Re: ServiceMix 3.0
On 8/22/06, Bruce Snyder [EMAIL PROTECTED] wrote: On 8/22/06, Guillaume Nodet [EMAIL PROTECTED] wrote: I think we should release 3.0 asap. The remaining todos are: * xbean 2.6 release * jencks 1.3 release (dependant on xbean) How far off are these two? Jencks should be release as soon as xbean is. For xbean, see the xbean dev list (I just posted a mail there). There is one outstanding JIRA in RTC and a question to solve about including qdox 1.6. * check samples and ensure they work Are there tests for the samples? Maybe we should consider creating some so it's easier and faster to determine if they're working or not? But, then again, maybe this is going too far. Well, there aren't. Now that the use maven to be built, we should be able to add some tests to them, but i'm not sure how easy it would be (especially when using the std jbi packaging) I will handled these. Note that the docs still need lots of improvements, but I'm not sure it should really delay the release... Thoughts ? Did i miss something ? On another related point, it would be nice at the same time to create a 3.0 branch for this release so that development can continue on trunk. Agreed, a branch is a necessity. Bruce -- perl -e 'print unpack(u30,D0G)[EMAIL PROTECTED]5R\F)R=6-E+G-N61ED\!G;6%I;\YC;VT* );' Apache Geronimo - http://geronimo.apache.org/ Apache ActiveMQ - http://incubator.apache.org/activemq/ Apache ServiceMix - http://incubator.apache.org/servicemix/ Castor - http://castor.org/ -- Cheers, Guillaume Nodet
Re: Mitigating uneven queue consumption
(moved to activemq-dev) On Jun 19, 2006, at 11:41 PM, James Strachan wrote: The forced-reconnect after a certain amount of time is probably the simplest way of solving this issue. I ended up implementing this first. It works ok, but it's pretty lame by design. It has actually turned out to be most handy to stress test the failover transport. Would you be interested in the patch for this or would you rather wait for multiplexing? I'm also interested in the multiplexing option. We already have the FanoutTransport which kinda does something like this; though we'd need to think carefully about the semantics, like transactions etc. I am part way through the implementation of this and wanted to bounce the rough design off you and see if it sounds like the right direction. I'm calling it 'fanin', but I see you've called something similar 'jedi' in Jira. Maybe I'll rename mine 'sith' just to be contrarian :) It currently connects to all discovered brokers. Message sends round- robin to individual brokers (ie only one broker handles a message send). Connection/session metadata commands are handled with the same state tracking failover uses. Anything stored in the state tracker is broadcast instead of unicast. Message acks are obviously only sent to the broker they originated from. Ranged acks are intelligently split so each broker gets the acks for the bits of range only it knows about. Transactions are still todo. My plan is that once the transport sees a transaction it punts and stops round-robin sending and locks down to one broker. That should be good enough for 1.0. Request/reply and temporary destinations are still untested, but I think they should work without much design tweaking. I don't plan on doing anything about message ordering. We don't care much about ordering, and I don't think there's much that could be done here anyway. Connection handling is done roughly the same way fanout does. The transport is basically a frankenstein of fanout and failover. Once I have the functionality complete I think it'll worthwhile to refactor the 3 a bit. Does this sounds pretty reasonable? John On 6/19/06, John Heitmann [EMAIL PROTECTED] wrote: Our setup: We have a set of brokers directly feeding consumers messages on a single queue destination (I'm going to lie a bit about our setup to keep things simple). On each host we're running a broker and multiple consumers. Each consumer connects to the broker set with a failover connection. Messages flow into the broker set from upstream sources (in our case another set of brokers) in a pretty even fashion, so each broker gets about the same amount of messages. The problem with this is that it's easy for one broker to have an uneven number of consumers, and in some cases have so few consumers that it will backlog. One way this can happen is if a broker is taken down for some routine reason. All the connections to that broker will fail over to another broker. When the broker comes back up it will not receive new connections until consumers restart yet it will continue to receive an equal share of messages from upstream. We're considering implementing two different code changes to ActiveMQ to help with this, but I wanted to poll the group to be sure there was not already something there to help us. Our first solution would be to add logic to ActiveMQConnection that would trigger a reconnect on the failover transport after a certain configurable time period expires and the current transaction is complete. This would give decent statistical certainty that a single broker won't ever get a large backlog compared to the others and should be transparent to the client code except for a hitch in message flow. Our second solution is to implement connection multiplexing for consumers. Behind the scenes each consumer would connect to all of the broker set, divide its prefetch buffer across all those brokers, and start grabbing messages from multiple at once. We'd also need hooks to auto-discovery for when we bring new brokers up or old brokers come back. Also transactions would probably need to be tied to a single broker. This seems like it would be smoother behavior overall, but tougher to implement than the first so we're putting it off. Scalability is also a concern. If you know of a way to do this already I would appreciate hearing about it. Thanks, John -- James --- http://radio.weblogs.com/0112098/
[jira] Created: (GERONIMO-2339) Empty auth-constraint tag in web app security-constraint does not prevent access to resource
Empty auth-constraint tag in web app security-constraint does not prevent access to resource Key: GERONIMO-2339 URL: http://issues.apache.org/jira/browse/GERONIMO-2339 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Components: security, Tomcat Affects Versions: 1.1.1 Environment: Geronimo Tomcat 1.1.1 Reporter: Vamsavardhana Reddy Fix For: 1.1.2, 1.2 I have the following security constraint in web.xml security-constraint web-resource-collection web-resource-nameNo Access/web-resource-name url-pattern/forbidden/*/url-pattern /web-resource-collection auth-constraint/ /security-constraint This means /forbidden/* is not accessible by any user. The permission woks fine if the application is deployed in Geronimo Jetty distribution. If the application is deployed in Geronimo Tomcat distribution, URLs /forbidden/* are accessible by all users. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [VOTE] Specs organization, versioning, and releasing
+1
Jason Dillon wrote:
PROPOSAL:
1. Each spec will no longer be split up into trunk+branches+tags.
There will instead be one trunk+branches+tags for all specs laid out
as follows:
specs/trunk/pom.xml
specs/trunk/artifactId
specs/tags/artifactId-version
specs/branches/
2. Each plugin will continue to have its own version and will be
released independently.
3. The top-level will have it's own version, which will remain
independent. When there is a major configuration change in that pom,
the version will be changed and the pom will be republished.
4. Releasing will be done with the maven release plugin ('mvn
release') and should occur at a stable point after any major change to
a spec module.
5. Change all module directories to match artifactIds.
MOTIVATION:
1. one trunk allows the entire set of specs to be checked out all at
once and built all at once.
* * *
[ ] +1 Allow changes
[ ] 0 No opinion
[ ] -1 No, leave the specs asis (provide rationale)
--jason
[jira] Created: (GERONIMO-2340) Jetty Network Listener state not persisted across server startups
Jetty Network Listener state not persisted across server startups - Key: GERONIMO-2340 URL: http://issues.apache.org/jira/browse/GERONIMO-2340 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Components: console Affects Versions: 1.1.1 Environment: Win XP, Geronimo Jetty 1.1.1-SNAPSHOT Reporter: Vamsavardhana Reddy Fix For: 1.1.2, 1.2 I have stopped the Jetty HTTPS and AJP Network Listeners thru Web Servers portlet. Upon restarting the server, these stopped listeners have started automatically. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (GERONIMO-2340) Network Listener state not persisted across server startups
[ http://issues.apache.org/jira/browse/GERONIMO-2340?page=all ] Vamsavardhana Reddy updated GERONIMO-2340: -- Summary: Network Listener state not persisted across server startups (was: Jetty Network Listener state not persisted across server startups) Description: I have stopped the HTTPS and AJP Network Listeners thru Web Servers portlet. Upon restarting the server, these stopped listeners have started automatically. Happens with both Jetty and Tomcat. (was: I have stopped the Jetty HTTPS and AJP Network Listeners thru Web Servers portlet. Upon restarting the server, these stopped listeners have started automatically.) Environment: Win XP, Geronimo 1.1.1-SNAPSHOT (was: Win XP, Geronimo Jetty 1.1.1-SNAPSHOT) Network Listener state not persisted across server startups --- Key: GERONIMO-2340 URL: http://issues.apache.org/jira/browse/GERONIMO-2340 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: console Affects Versions: 1.1.1 Environment: Win XP, Geronimo 1.1.1-SNAPSHOT Reporter: Vamsavardhana Reddy Fix For: 1.1.2, 1.2 I have stopped the HTTPS and AJP Network Listeners thru Web Servers portlet. Upon restarting the server, these stopped listeners have started automatically. Happens with both Jetty and Tomcat. -- 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-2340) Network Listener state not persisted across server startups
[ http://issues.apache.org/jira/browse/GERONIMO-2340?page=comments#action_12429667 ] Vamsavardhana Reddy commented on GERONIMO-2340: --- Same happens with JMS Listeners too. Network Listener state not persisted across server startups --- Key: GERONIMO-2340 URL: http://issues.apache.org/jira/browse/GERONIMO-2340 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: console Affects Versions: 1.1.1 Environment: Win XP, Geronimo 1.1.1-SNAPSHOT Reporter: Vamsavardhana Reddy Fix For: 1.1.2, 1.2 I have stopped the HTTPS and AJP Network Listeners thru Web Servers portlet. Upon restarting the server, these stopped listeners have started automatically. Happens with both Jetty and Tomcat. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (GERONIMO-2341) EditableConfigurationManager problems!!???!!!!
EditableConfigurationManager problems!!??? -- Key: GERONIMO-2341 URL: http://issues.apache.org/jira/browse/GERONIMO-2341 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Components: ActiveMQ, kernel Affects Versions: 1.1.1 Reporter: Vamsavardhana Reddy Priority: Critical Fix For: 1.1.1 Here are a few problems I noticed. 1. Delete a network listener (Jetty Web/Tomcat Web/JMS) thru administration console and the listener showsup after server restart. 2. Stop any network listener, the listener is started automatically at server restart (Related JIRA GERONIMO-2340) I think these problems have been fixed several times in the past. But the problem still remains. It will be a big relief I am wrong and this JIRA is invalid. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Assigned: (SM-536) The defaultMep is a mandatory attribute on consumer endpoints and should be checked
[ https://issues.apache.org/activemq/browse/SM-536?page=all ] Grant McDonald reassigned SM-536: - Assignee: Grant McDonald The defaultMep is a mandatory attribute on consumer endpoints and should be checked --- Key: SM-536 URL: https://issues.apache.org/activemq/browse/SM-536 Project: ServiceMix Issue Type: Bug Components: servicemix-http, servicemix-jms Reporter: Guillaume Nodet Assigned To: Grant McDonald Fix For: 3.0 -- 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: How to create a temporary Queue
On 8/22/06, ahamad [EMAIL PROTECTED] wrote: Hi all, Any one can help to tell me that How I can create a Temporary queue and how to use this? See http://java.sun.com/j2ee/1.4/docs/api/javax/jms/Session.html#createTemporaryQueue() then just use it like any other Destination -- James --- http://radio.weblogs.com/0112098/
[jira] Assigned: (GERONIMO-2341) EditableConfigurationManager problems!!???!!!!
[ http://issues.apache.org/jira/browse/GERONIMO-2341?page=all ] Vamsavardhana Reddy reassigned GERONIMO-2341: - Assignee: Vamsavardhana Reddy EditableConfigurationManager problems!!??? -- Key: GERONIMO-2341 URL: http://issues.apache.org/jira/browse/GERONIMO-2341 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: ActiveMQ, kernel Affects Versions: 1.1.1 Reporter: Vamsavardhana Reddy Assigned To: Vamsavardhana Reddy Priority: Critical Fix For: 1.1.1 Here are a few problems I noticed. 1. Delete a network listener (Jetty Web/Tomcat Web/JMS) thru administration console and the listener showsup after server restart. 2. Stop any network listener, the listener is started automatically at server restart (Related JIRA GERONIMO-2340) I think these problems have been fixed several times in the past. But the problem still remains. It will be a big relief I am wrong and this JIRA is invalid. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (GERONIMO-2341) EditableConfigurationManager problems!!???!!!!
[ http://issues.apache.org/jira/browse/GERONIMO-2341?page=all ] Vamsavardhana Reddy updated GERONIMO-2341: -- Attachment: GERONIMO-2341.patch GERONIMO-2341.patch: Fixes a problem in EditableKernelConfigurationManager.removeGBeanFromConfiguration() The method is calling configuration.removeGBean() twice and the second call is resulting in GBeanNotFoundException since the GBean is already removed in the first call. EditableConfigurationManager problems!!??? -- Key: GERONIMO-2341 URL: http://issues.apache.org/jira/browse/GERONIMO-2341 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: ActiveMQ, kernel Affects Versions: 1.1.1 Reporter: Vamsavardhana Reddy Assigned To: Vamsavardhana Reddy Priority: Critical Fix For: 1.1.1 Attachments: GERONIMO-2341.patch Here are a few problems I noticed. 1. Delete a network listener (Jetty Web/Tomcat Web/JMS) thru administration console and the listener showsup after server restart. 2. Stop any network listener, the listener is started automatically at server restart (Related JIRA GERONIMO-2340) I think these problems have been fixed several times in the past. But the problem still remains. It will be a big relief I am wrong and this JIRA is invalid. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (GERONIMO-2341) EditableConfigurationManager problems!!???!!!!
[ http://issues.apache.org/jira/browse/GERONIMO-2341?page=all ] Vamsavardhana Reddy updated GERONIMO-2341: -- Patch Info: [Patch Available] GERONIMO-2341.patch fixes the problem seen with removing connectors. EditableConfigurationManager problems!!??? -- Key: GERONIMO-2341 URL: http://issues.apache.org/jira/browse/GERONIMO-2341 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: ActiveMQ, kernel Affects Versions: 1.1.1 Reporter: Vamsavardhana Reddy Assigned To: Vamsavardhana Reddy Priority: Critical Fix For: 1.1.1 Attachments: GERONIMO-2341.patch Here are a few problems I noticed. 1. Delete a network listener (Jetty Web/Tomcat Web/JMS) thru administration console and the listener showsup after server restart. 2. Stop any network listener, the listener is started automatically at server restart (Related JIRA GERONIMO-2340) I think these problems have been fixed several times in the past. But the problem still remains. It will be a big relief I am wrong and this JIRA is invalid. -- 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: GERONIMO-1526
Ok thanks for the clarification.On Aug 21, 2006, at 8:13 PM, Dain Sundstrom wrote:On Aug 21, 2006, at 4:11 PM, Sachin Patel wrote: On Aug 21, 2006, at 4:31 PM, Dain Sundstrom wrote: Thanks. I have a few questions/issues...Why the separation between resources and classes. Don't we need to add both to the class loader anyway? I'm curious when this differentiation is important. Ok, This is where I value your input. There could be definitely a distinction from a tools perspective, as the java output folder could only contain .class files and not resources and metadata. From a server runtime perspective I wasn't 100% sure as Looking at AbstractWebModuleBuilder.installModule(...), resources are added to the module context either via addFile(), addInclude() and addToClasspath(). So I assume addFile() and addInclude() also adds these to the classloader? If there does not need to be a separation then yes, we can combine both methods. I think I see the disconnect. When I hear the word resources, I think of additional non-class files available via the class loader, but they all end up in the class loader bucket. In the case of a web application, we have two buckets: the class loader and the web app context. The former is the same for all modules, and the latter contains files that are accessible via http.If that is the case, I think we need to keep the separation, but I'm not sure "resource" is the best name given the level of confusion we have already seen.-dain -sachin
Re: Mitigating uneven queue consumption
On 8/22/06, John Heitmann [EMAIL PROTECTED] wrote: (moved to activemq-dev) On Jun 19, 2006, at 11:41 PM, James Strachan wrote: The forced-reconnect after a certain amount of time is probably the simplest way of solving this issue. I ended up implementing this first. It works ok, but it's pretty lame by design. It has actually turned out to be most handy to stress test the failover transport. Would you be interested in the patch for this or would you rather wait for multiplexing? Sure :) I'm also interested in the multiplexing option. We already have the FanoutTransport which kinda does something like this; though we'd need to think carefully about the semantics, like transactions etc. I am part way through the implementation of this and wanted to bounce the rough design off you and see if it sounds like the right direction. Great! :) I'm calling it 'fanin', but I see you've called something similar 'jedi' in Jira. Maybe I'll rename mine 'sith' just to be contrarian :) LOL! It currently connects to all discovered brokers. Message sends round- robin to individual brokers (ie only one broker handles a message send). BTW for topics you might wanna send the message to all brokers. Connection/session metadata commands are handled with the same state tracking failover uses. Anything stored in the state tracker is broadcast instead of unicast. Message acks are obviously only sent to the broker they originated from. Ranged acks are intelligently split so each broker gets the acks for the bits of range only it knows about. Sounds *awesome*! Can't wait for the patch :) Transactions are still todo. My plan is that once the transport sees a transaction it punts and stops round-robin sending and locks down to one broker. That should be good enough for 1.0. Yeah, that'd be fine to start with. Another option is that each transaction is pinned to a specific broker all operations are fixed with that broker. Bear in mind different threads can be performing different transactions - so if a Message / MessageAck has a transactionId property then associate it with a single broker. We could then round robin transactions around brokers too :) Request/reply and temporary destinations are still untested, but I think they should work without much design tweaking. Yeah - we'd need to broadcast temporary destination commands to all brokers just in case (as the temporary destination could be put on the JMSReplyTo on another message I don't plan on doing anything about message ordering. We don't care much about ordering, and I don't think there's much that could be done here anyway. Cool. If forks are worried about that we could pin a destination to a broker - or even a message for a destination with a specific Message Group header (JMSXGroupID) to a broker so we could load balance messages to the same queue across brokers using Message Groups to preserve order Connection handling is done roughly the same way fanout does. The transport is basically a frankenstein of fanout and failover. Once I have the functionality complete I think it'll worthwhile to refactor the 3 a bit. Does this sounds pretty reasonable? Sounds great. I'd be happy for this to replace fanout as its mostly a case of just choosing the 1 or all brokers that messages go to based on the type of command whether or not its in a transaction etc. Given the different semantics to failover its probably worth keeping it separate though we could maybe reuse some code at some point. Its all sounding great so far John! :) -- James --- http://radio.weblogs.com/0112098/
Re: Refactoring code to reduce the amount of code required to write full JBI components
On 8/22/06, Guillaume Nodet [EMAIL PROTECTED] wrote: Comments inline On 8/22/06, James Strachan [EMAIL PROTECTED] wrote: I was wondering about the minimal amount of code required to write a nicely behaving JBI component with proper component, endpoint, deployer and URI/EPR handling etc. e.g. if we were to refactor more of the components in the servicemix-components module into their own module like the jms, http and jsr181 modules - what new code would be required. Or rather how little could we get away with :) So I was wondering if we could do a little bit of refactoring to reduce the amount of code that is really needed to be written on each component. (Some of the other components are way simpler than jms, http and JSR181 support too such as the file component so the code should hopefully be even simpler). Of course it would be nice. I think all your following points came from the fact that I added features to servicemix-http first (so not in servicemix-common / servicemix-soap) and then duplicated them in servicemix-http instead of refactoring them in some common code :( My mistake. No worries - my bad for choosing the wrong components to look at :). Its good to know servicemix-soap is the clean one to use as a template when we start writing more components I've not had an coffee yet so please excuse any silly ideas but a quick run through the code in the Jms and HTTP components with brief looks at JSR181 led to the following thoughts... * HttpBootstrap JmsBootstrap are pretty much identical apart from the configuration property (incidentally should HttpBootstrap use a HttpConfiguration like JmsBootstrap?) so am wondering if we can push more of its logic up to a base class - maybe allowing the configuration object to be specified as a constructor argument? At first, they were inheriting a base class (BaseBootstrap in servicemix-common). The problem is that shared libraries are not available at bootstrap time according to the jbi spec (hence to ServiceMix too). So we can not refactor much here :( Damn! Thanks for the heads up. It might be worth us putting comments in the bootstrap classes to warn folks not to bother trying to refactor that code :) * HttpLifecycle JmsLifecycle have quite a few similarities. I wonder could we refactor most of the code into the *Configuration and *Endpoint classes so that we could basically share the same Lifecycle classes in most components? Yeah maybe. There are other ways too: refactor the component and the lifecycle in the same class (this would lead to one class less to implement) and / or have a base component for soap-enabled base component class which would retrieve the needed additional components (AuthenticationService, KeystoreManager). Yeah - I was musing that too on the way to see a customer this morning. It does seem like Spring support requires a slightly different component and lifecycle. But given the simplicity of these 3 classes (lifecycle, component, spring component) maybe we can merge the three together and put most of the work in the base class. I did wonder about a reusable base class for Configuration too for things like the authentication service keystore manager. * Jms/HttpExternalEndpoint look pretty identical - just dependent on their Jms/HttpEndpoint classes * Jms/HttpResolvedEndpoint pretty much the same bar some constants - maybe moving those into the *Endpoint or *Component classes might make the code simpler? Agreed, we could have only two classes for these Great * Jms/HttpSpringComponent - look about the same apart from the use of Jms/HttpEndpoint - I wonder if generics could be used to share a common base class? Basically the only real difference is the type of the endpoint. Not sure, as the configuration, enpoint resolution and lifecycles are different. Also the use of generics will introduce a JDK 5 requirement, unless we use retrotranslator ;) Yeah :) I wonder if we bad a base class that combined the component lifecycle spring stuff then had a separate endpoint then had plenty of hooks we could mostly share the same code and just overload where need be (and for simple components we'll have little work to do). * Jms/HttpXBeanDeployer - we could maybe use a generic XBeanDeployer which is parameterized on the type of the Endpoint and then call *Endpoint.validate() to avoid needing to write a new class for this unless its absolutely necessary (like it is for JSR181)? True also. I was really just trying to avoid as much of the boiler plate code as possible so we could make more fully-JBI compliant components with as little code as possible. Am thinking the bare minimum would be something like the bootstrap, component, configuration endpoint classes with reusable base classes for most of the other stuff then the consumer/producer classes for doing the actual work. Any other thoughts on how to reduce/simplify the amount of code required? We
Deploying common libs from maven2 to Geronimo
Hi, My team is trying to get our hands around automating deployment of common libraries from our build environment (maven 2.x) to a Geronimo repository. Being that the G build environment is now also maven 2.x, I'm hoping to see how others are tackling this problem. It seems that the G repository is almost identical to a maven repository in structure and we were hoping for an easy way to bridge between the two. Our first idea was to copy the directory structure from .m2/repository to GHOME/repository. Geronimo, however, has issues with the pom.xml files when resolving dependencies to the libraries at runtime (it seems to confuse the pom for the library). Certainly, we could write a script to filter out all the pom.xml files, but we'd still have the problem of filtering what does and does not get deployed to G. Since the easiest thing to do would be to copy top-level folders in the repository, we would probably be deploying way more libraries than necessary. It seems reasonable to simply create one big maven project that has dependencies on all the projects that we would want to deploy. This would take care of the filtering part of the problem. If we could then deploy this project and all of its dependencies to a G repo (removing pom.xml, etc), that would solve the rest. Perhaps a m2 geronimo plugin? These were our ideas. Does anyone know of a better way we could tackle this problem? ... perhaps tools/tricks to help automate the deployment from m2-G? Thanks in advance for the help! - Brian
Re: maven-geronimodevtools-plugin specifying source directory
Hi I'm confused as what you're asking. The Eclipse plugins do build purely with Maven.All you need to do is checkout the source...https://svn.apache.org/repos/asf/geronimo/devtools/eclipse-plugin/trunk/Then run "mvn install".And thats it. Then you can import the projects into your Eclipse workspace and work from there. I think the source directory is inherited from the root pom. Since I was migrating from M1 to M2 I did not move the source yet into the M2 convention directory. But this should not affect building or compilation.On Aug 22, 2006, at 3:59 AM, Conrad O'Dea wrote:ding of Eclipse plugins into a Maven build system. It would be much simpler to just use Maven to build them all if possible. I've just discovered maven-geronimodevtools-plugin and it looks like it fits the bill perfectly. I've been playing with it a little but cannot get maven to pick up the source directory for the plugin. When I build the Geronimo eclipse plugins, the compileSourceRoot property is se -sachin
Car plugin
I recently experienced some problems [1] when building Geronimo 1.1 plugins using the car-maven-plugin. It seems this is related to the following change: http://svn.apache.org/viewvc/geronimo/trunk/m2-plugins/car-maven-plugin/src/main/java/org/apache/geronimo/plugin/car/PlanProcessorMojo.java?r1=431112r2=432510pathrev=433457diff_format=h I hope one of the goal for this plugin is also to be able to handle Geronimo 1.1 plugins, else we will need to copy it somewhere else. I'll take a look at this problem. [1] Maven error: Caused by: org.apache.geronimo.common.DeploymentException: Invalid deployment descriptor: [c:\java\servicemix\geronimo\servicemix\target\plan\plan.xml:18: error : cvc-complex-type.2.4a: Expected element '[EMAIL PROTECTED]://geronimo.apache.org/xml/ns/deployment-1.1' instead of '[EMAIL PROTECTED]://geronimo.apache.org/xml/ ns/deployment-1.2' here in element [EMAIL PROTECTED]://geronimo.apache.org/xml/ns/deployment-1.1, c:\java\servicemix\geronimo\servicemix\target\plan\plan.xml:184: err or: cvc-complex-type.2.4a: Expected element '[EMAIL PROTECTED]://geronimo.apache.org/xml/ns/deployment-1.1' instead of '[EMAIL PROTECTED]://geronimo.apache.org/xml/ns/d eployment-1.1' here in element [EMAIL PROTECTED]://geronimo.apache.org/xml/ns/deployment-1.1, c:\java\servicemix\geronimo\servicemix\target\plan\plan.xml:189: error: cvc-complex-type.2.4a: Expected element '[EMAIL PROTECTED]://geronimo.apache.org/xml/ns/deployment-1.1' instead of '[EMAIL PROTECTED]://geronimo.apache.org/xml/ns/deplo yment-1.1' here in element [EMAIL PROTECTED]://geronimo.apache.org/xml/ns/deployment-1.1, c:\java\servicemix\geronimo\servicemix\target\plan\plan.xml:203: error: cvc- complex-type.2.4a: Expected element '[EMAIL PROTECTED]://geronimo.apache.org/xml/ns/deployment-1.1' instead of '[EMAIL PROTECTED]://geronimo.apache.org/xml/ns/deploymen t-1.1' here in element [EMAIL PROTECTED]://geronimo.apache.org/xml/ns/deployment-1.1, c:\java\servicemix\geronimo\servicemix\target\plan\plan.xml:210: error: cvc-comp lex-type.2.4c: Expected element '[EMAIL PROTECTED]://geronimo.apache.org/xml/ns/deployment-1.1' before the end of the content in element [EMAIL PROTECTED]://geronimo.a pache.org/xml/ns/deployment-1.1] Descriptor: !--Licensed to the Apache Software Foundation (ASF) under one or more contributor license agreements. See the NOTICE file distributed with this work for additional information regarding copyright ownership. The ASF licenses this file to You under the Apache License, Version 2.0 (the License); you may not use this file except in compliance with the License. You may obtain a copy of the License at http://www.apache.org/licenses/LICENSE-2.0 Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an AS IS BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License.-- !--Configuration for ServiceMix container.-- module xmlns=http://geronimo.apache.org/xml/ns/deployment-1.1; dep:environment xmlns:dep=http://geronimo.apache.org/xml/ns/deployment-1.2; moduleId groupIdorg.apache.servicemix.geronimo/groupId artifactIdservicemix/artifactId version3.0-incubating-SNAPSHOT/version typecar/type /moduleId dependencies dependency groupIdgeronimo/groupId artifactIdgeronimo-transaction/artifactId version1.1/version typejar/type importclasses/import /dependency dependency groupIdhowl/groupId artifactIdhowl-logger/artifactId version0.1.11/version typejar/type importclasses/import /dependency dependency groupIdgeronimo/groupId artifactIdgeronimo-management/artifactId version1.1/version typejar/type importclasses/import /dependency dependency groupIdgeronimo/groupId artifactIdgeronimo-system/artifactId version1.1/version typejar/type importclasses/import /dependency dependency groupIdorg.apache.geronimo.specs/groupId artifactIdgeronimo-jsp_2.0_spec/artifactId version1.0.1/version typejar/type importclasses/import /dependency dependency groupIdgeronimo/groupId artifactIdgeronimo-client/artifactId version1.1/version typejar/type importclasses/import /dependency dependency groupIdasm/groupId artifactIdasm/artifactId version1.4.3/version typejar/type importclasses/import /dependency dependency groupIdgeronimo/groupId artifactIdgeronimo-connector-builder/artifactId version1.1/version typejar/type importclasses/import /dependency dependency groupIdgeronimo/groupId artifactIdgeronimo-naming-builder/artifactId
Re: maven-geronimodevtools-plugin specifying source directory
See the FAQ on the wiki for additional details...http://cwiki.apache.org/GMOxDOC11/geronimo-eclipse-plugin-faq.htmlOn Aug 22, 2006, at 3:59 AM, Conrad O'Dea wrote:Hi,I've a massive pain in my head trying to incorporate the building of Eclipse plugins into a Maven build system. It would be much simpler to just use Maven to build them all if possible.I've just discovered maven-geronimodevtools-plugin and it looks like it fits the bill perfectly. I've been playing with it a little but cannot get maven to pick up the source directory for the plugin.When I build the Geronimo eclipse plugins, the compileSourceRoot property is set to ./src whereas when I build my own plugins, it is set to ./src/main/java, the default value. I've grepped through the files in the Geronimo eclipse-plugin project but cannot find where the source directory is set.Can anyone point me to how to configure compileSourceRoot for maven-geronimodevtools-plugin?On a related note, has this plugin been released yet?thanksConrad -sachin
Re: Car plugin
On 8/22/06, Guillaume Nodet [EMAIL PROTECTED] wrote: I recently experienced some problems [1] when building Geronimo 1.1 plugins using the car-maven-plugin. I think a solution may be to build the maven plugin locally from 1.1 sources and build Geronimo 1.1 then. It seems you've been trying to run the build online and thus all the deps (the maven plugin including) is pulled down too. For it's an incompatible version, the build blows up. Just a wild guess, but may be of help. Report back! ;-) Jacek -- Jacek Laskowski http://www.laskowski.net.pl
Re: Deploying common libs from maven2 to Geronimo
What geronimo does is to first deploy all applications into the maven repo (packaging plugin for g 1.1 and earlier, car plugin for trunk) and then assemble a server by copying the car files and then pulling in all transitive dependencies (using geronimo's dependency system) (assembly plugin for g 1.1 and earlier, I think car plugin again for trunk, I'm not quite sure how it works in trunk). This assures that you get exactly the artifacts you need in your server. However if you are using g 1.1 it means you have to get your artifacts into an m1 repo and trunk is not quite production ready at this point. IMO geronimo should not object to poms being in our repo. Can you provide more details on how to reproduce this problem? The best would be a jira entry with a sample and instructions. thanks david jencks On Aug 22, 2006, at 8:40 AM, Desai, Brian wrote: Hi, My team is trying to get our hands around automating deployment of common libraries from our build environment (maven 2.x) to a Geronimo repository. Being that the G build environment is now also maven 2.x, I'm hoping to see how others are tackling this problem. It seems that the G repository is almost identical to a maven repository in structure and we were hoping for an easy way to bridge between the two. Our first idea was to copy the directory structure from .m2/repository to GHOME/repository. Geronimo, however, has issues with the pom.xml files when resolving dependencies to the libraries at runtime (it seems to confuse the pom for the library). Certainly, we could write a script to filter out all the pom.xml files, but we'd still have the problem of filtering what does and does not get deployed to G. Since the easiest thing to do would be to copy top-level folders in the repository, we would probably be deploying way more libraries than necessary. It seems reasonable to simply create one big maven project that has dependencies on all the projects that we would want to deploy. This would take care of the filtering part of the problem. If we could then deploy this project and all of its dependencies to a G repo (removing pom.xml, etc), that would solve the rest. Perhaps a m2 geronimo plugin? These were our ideas. Does anyone know of a better way we could tackle this problem? ... perhaps tools/tricks to help automate the deployment from m2-G? Thanks in advance for the help! - Brian
Re: Car plugin
I suspect that perhaps you are running with an old version of geronimo-service-builder.jar with an old set of namespace conversions in XmlBeansUtil. The idea is that XmlBeansUtil.parse is used to read all plans and it will convert the 1.1 namespaces to the latest 1.2 namespaces. So, -check you are really using up to date geronimo-service-builder -check that XmlBeansUtil is being used to parse the xml in the code path you are going through. thanks david jencks On Aug 22, 2006, at 8:55 AM, Guillaume Nodet wrote: I recently experienced some problems [1] when building Geronimo 1.1 plugins using the car-maven-plugin. It seems this is related to the following change: http://svn.apache.org/viewvc/geronimo/trunk/m2-plugins/car-maven- plugin/src/main/java/org/apache/geronimo/plugin/car/ PlanProcessorMojo.java? r1=431112r2=432510pathrev=433457diff_format=h I hope one of the goal for this plugin is also to be able to handle Geronimo 1.1 plugins, else we will need to copy it somewhere else. I'll take a look at this problem. [1] Maven error: Caused by: org.apache.geronimo.common.DeploymentException: Invalid deployment descriptor: [c:\java\servicemix\geronimo\servicemix\target\plan\plan.xml:18: error : cvc-complex-type.2.4a: Expected element '[EMAIL PROTECTED]://geronimo.apache.org/xml/ns/deployment-1.1' instead of '[EMAIL PROTECTED]://geronimo.apache.org/xml/ ns/deployment-1.2' here in element [EMAIL PROTECTED]://geronimo.apache.org/xml/ns/deployment-1.1, c:\java\servicemix\geronimo\servicemix\target\plan\plan.xml:184: err or: cvc-complex-type.2.4a: Expected element '[EMAIL PROTECTED]://geronimo.apache.org/xml/ns/deployment-1.1' instead of '[EMAIL PROTECTED]://geronimo.apache.org/xml/ns/d eployment-1.1' here in element [EMAIL PROTECTED]://geronimo.apache.org/xml/ns/deployment-1.1, c:\java\servicemix\geronimo\servicemix\target\plan\plan.xml:189: error: cvc-complex-type.2.4a: Expected element '[EMAIL PROTECTED]://geronimo.apache.org/xml/ns/deployment-1.1' instead of '[EMAIL PROTECTED]://geronimo.apache.org/xml/ns/deplo yment-1.1' here in element [EMAIL PROTECTED]://geronimo.apache.org/xml/ns/deployment-1.1, c:\java\servicemix\geronimo\servicemix\target\plan\plan.xml:203: error: cvc- complex-type.2.4a: Expected element '[EMAIL PROTECTED]://geronimo.apache.org/xml/ns/deployment-1.1' instead of '[EMAIL PROTECTED]://geronimo.apache.org/xml/ns/deploymen t-1.1' here in element [EMAIL PROTECTED]://geronimo.apache.org/xml/ns/deployment-1.1, c:\java\servicemix\geronimo\servicemix\target\plan\plan.xml:210: error: cvc-comp lex-type.2.4c: Expected element '[EMAIL PROTECTED]://geronimo.apache.org/xml/ns/deployment-1.1' before the end of the content in element [EMAIL PROTECTED]://geronimo.a pache.org/xml/ns/deployment-1.1] Descriptor: !--Licensed to the Apache Software Foundation (ASF) under one or more contributor license agreements. See the NOTICE file distributed with this work for additional information regarding copyright ownership. The ASF licenses this file to You under the Apache License, Version 2.0 (the License); you may not use this file except in compliance with the License. You may obtain a copy of the License at http://www.apache.org/licenses/LICENSE-2.0 Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an AS IS BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License.-- !--Configuration for ServiceMix container.-- module xmlns=http://geronimo.apache.org/xml/ns/deployment-1.1; dep:environment xmlns:dep=http://geronimo.apache.org/xml/ns/ deployment-1.2 moduleId groupIdorg.apache.servicemix.geronimo/groupId artifactIdservicemix/artifactId version3.0-incubating-SNAPSHOT/version typecar/type /moduleId dependencies dependency groupIdgeronimo/groupId artifactIdgeronimo-transaction/artifactId version1.1/version typejar/type importclasses/import /dependency dependency groupIdhowl/groupId artifactIdhowl-logger/artifactId version0.1.11/version typejar/type importclasses/import /dependency dependency groupIdgeronimo/groupId artifactIdgeronimo-management/artifactId version1.1/version typejar/type importclasses/import /dependency dependency groupIdgeronimo/groupId artifactIdgeronimo-system/artifactId version1.1/version typejar/type importclasses/import /dependency dependency groupIdorg.apache.geronimo.specs/groupId artifactIdgeronimo-jsp_2.0_spec/artifactId version1.0.1/version typejar/type importclasses/import /dependency dependency groupIdgeronimo/groupId artifactIdgeronimo-client/artifactId
[jira] Updated: (GERONIMO-2326) unable to deploy a database pool
[ http://issues.apache.org/jira/browse/GERONIMO-2326?page=all ] David Jencks updated GERONIMO-2326: --- Attachment: GERONIMO-2326.djencks-2.patch Previous patch had some problems with hot-deploy config starting. This patch has the jetty server starting ok for me and I can deploy derby xa datasources with no errors. bdudney could you check my work? unable to deploy a database pool Key: GERONIMO-2326 URL: http://issues.apache.org/jira/browse/GERONIMO-2326 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Affects Versions: 1.2, 1.1.2 Reporter: Bill Dudney Assigned To: David Jencks Fix For: 1.1.2, 1.2 Attachments: 2326-deploy-datasource.patch, GERONIMO-2326.djencks-2.patch, GERONIMO-2326.djencks.patch Trying to deploy a jdbc datasource leads to a blank screen and the following stack trace in the log. The issue appears to be that URLPatternSpec does not like the URL generated by DatabasePoolPortlet from the info found in the DatabaseInfo.ALL_DATABASES array. java.lang.IllegalArgumentException: Qualifier patterns must be present when first URLPattern is an exact pattern at javax.security.jacc.URLPatternSpec.init(URLPatternSpec.java:98) at javax.security.jacc.WebUserDataPermission.init(WebUserDataPermission.java:83) at org.apache.geronimo.tomcat.realm.TomcatGeronimoRealm.hasUserDataPermission(TomcatGeronimoRealm.java:131) at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:460) at org.apache.geronimo.tomcat.GeronimoStandardContext$SystemMethodValve.invoke(GeronimoStandardContext.java:322) at org.apache.geronimo.tomcat.valve.GeronimoBeforeAfterValve.invoke(GeronimoBeforeAfterValve.java:31) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:869) at org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection(Http11BaseProtocol.java:667) at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:527) at org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(LeaderFollowerWorkerThread.java:80) at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:684) at java.lang.Thread.run(Thread.java:552) -- 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: Car plugin
I guess I was misunderstood. I' m using the maven 2 plugin in trunk to build a plugin for Geronimo 1.1. This is the only way, because there is no maven 2 plugin for G 1.1. Everything was working fine until this recent change. Adding a property to specify the target geronimo version seems to do the trick. So i can now have: module xmlns=http://geronimo.apache.org/xml/ns/deployment-1.1; environment instead of module xmlns=http://geronimo.apache.org/xml/ns/deployment-1.1; environment xmlns=http://geronimo.apache.org/xml/ns/deployment-1.2; Btw, I' m wondering why the PlanProcessorMojo only overrides the environmnet tag, and not the module one. On 8/22/06, Jacek Laskowski [EMAIL PROTECTED] wrote: On 8/22/06, Guillaume Nodet [EMAIL PROTECTED] wrote: I recently experienced some problems [1] when building Geronimo 1.1 plugins using the car-maven-plugin. I think a solution may be to build the maven plugin locally from 1.1 sources and build Geronimo 1.1 then. It seems you've been trying to run the build online and thus all the deps (the maven plugin including) is pulled down too. For it's an incompatible version, the build blows up. Just a wild guess, but may be of help. Report back! ;-) Jacek -- Jacek Laskowski http://www.laskowski.net.pl -- Cheers, Guillaume Nodet
Re: [VOTE] Specs organization, versioning, and releasing
On Aug 22, 2006, at 1:37 AM, David Jencks wrote: On Aug 21, 2006, at 9:21 PM, David Blevins wrote: On Aug 21, 2006, at 7:13 PM, Kevan Miller wrote: As long as we have inter-dependencies between specs (e.g. javamail depends on activation; jaxrpc on saaj, qname, and servlet; and especially geronimo-spec-j2ee depends on everything), I'm not convinced that this really makes things any better... I agree that your plan is better than the previous plan for multiple trunks, but I'm not convinced that either plan is actually making things simpler... If I understand your proposal, tags/geronimo-spec-jaxrpc-jax- rpcversion/pom.xml will specify the tagged versions of saaj, qname, and servlet upon which it depends? So, haven't we just split apart the specification of these version dependencies from a single pom.xml into multiple poms? Is this really making things simpler? That'd be right. I'm not sure how complicated that is, though. None of those specs have changed in a year. Can you give an non- hypothetical example of something that does change and causes this problem that isn't the J2EE uber-jar? Well, the current activation spec is at version 1.1. When that version was bumped from 1.0 (or 1.0.x), you'd have needed to know/ remember to change the poms in the following specs: geronimo-spec- j2ee, geronimo-spec-javamail, geronimo-spec-jaxr, and geronimo-spec- saaj. A question for you, Jason: If someone wants to build our released specs from source, what's the process? Maybe I don't understand the proposal, but otherwise IIUC every time we've found a problem in e.g. the jacc spec we'd need to release every spec jar, and update all the versions. I guess we do this with a lot of geronimo jars going e.g. from 1.1 to 1.1.1 but I think having a lot of identical-contents spec jars would be too confusing. No, I don't think that's what is happening (at least not in theory), but I've never actually released specs. So, I may be mistaken... Current Process for updating jacc 1) Update branches/1_1/pom.xml with new geronimoSpecsVersion and new geronimoSpecsJaccVersion 2) Update jacc spec sources 3) Build all specs 4) Release jacc and uber-jar spec 5) tag branches/1_1 as tags/1.1.x Current Proposed Process 1) Update branches/1_1/geronimo-j2ee/pom.xml with new uber-jar spec version and new jacc spec version 2) Update branches/1_1/geronimo-jacc/pom.xml with new jacc spec version 3) Update jacc spec sources 4) Build jacc and uber-jar (build seperately or together?). 6) Release jacc 7) tag jacc-version 8) Release uber-jar 9) tag uber-jar-version Single-version Proposed Process 1) Update branches/1_1_/pom.xml with new specs version 2) Update jacc spec sources 3) Build all specs 4) Release all specs 5) tag branches/1_1 as tags/1.1.x I don't see that releasing identical content spec jars are necessarily confusing (as you point out, we essentially do it with every Geronimo release). Less confusing to have only a single version to worry about... What's the latest release 1.1.x geronimo specs? Use that for all of my j2ee 1.4 spec dependencies. Seems simpler than knowing the latest jacc spec is at version x and the latest servlet 2.4 spec is at version y. --kevan
[jira] Created: (GERONIMO-2342) Can't change keystore type for Jetty
Can't change keystore type for Jetty Key: GERONIMO-2342 URL: http://issues.apache.org/jira/browse/GERONIMO-2342 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Components: connector Affects Versions: 1.1 Reporter: Nellya Udovichenko Priority: Minor I've tried to replace Jetty SSL keystore type, for example, with PKCS12, by adding the parameter to config.xml (like I did with Tomcat): ... gbean name=JettySSLConnector attribute name=keystoreTypePKCS12/attribute attribute name=host0.0.0.0/attribute attribute name=port8443/attribute /gbean ... and got the following error log: [*] 43% 72s Startup failed org.apache.geronimo.kernel.config.LifecycleException: start of geronimo/jetty/1.1/car failed at org.apache.geronimo.kernel.config.SimpleConfigurationManager.startConfiguration(SimpleConfigurationManager.java:529) ... Caused by: java.lang.IllegalStateException: Attribute is not persistent Attribute Name: keystoreType, Type: class java.lang.String, GBeanInstance: Jetty Connector HTTPS at org.apache.geronimo.gbean.runtime.GBeanAttribute.setPersistentValue(GBeanAttribute.java:355) at org.apache.geronimo.gbean.runtime.GBeanInstance.setAttribute(GBeanInstance.java:749) at org.apache.geronimo.gbean.runtime.GBeanInstance.init(GBeanInstance.java:367) ... 17 more -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Car plugin
On 8/22/06, Guillaume Nodet [EMAIL PROTECTED] wrote: I guess I was misunderstood. I' m using the maven 2 plugin in trunk to build a plugin for Geronimo 1.1. This is the only way, because there is no maven 2 plugin for G 1.1. Everything was working fine until this recent change. If this stuff is not to be supported by the car-maven-plugin, or if there will be incompatible changes in the deployer so that the same plugin can not handle G 1.1 and 1.2, then I propose we start a new plugin (where ?) from the current one to target G 1.1. Adding a property to specify the target geronimo version seems to do the trick. So i can now have: module xmlns=http://geronimo.apache.org/xml/ns/deployment-1.1; environment instead of module xmlns=http://geronimo.apache.org/xml/ns/deployment-1.1; environment xmlns=http://geronimo.apache.org/xml/ns/deployment-1.2; Btw, I' m wondering why the PlanProcessorMojo only overrides the environmnet tag, and not the module one. On 8/22/06, Jacek Laskowski [EMAIL PROTECTED] wrote: On 8/22/06, Guillaume Nodet [EMAIL PROTECTED] wrote: I recently experienced some problems [1] when building Geronimo 1.1 plugins using the car-maven-plugin. I think a solution may be to build the maven plugin locally from 1.1 sources and build Geronimo 1.1 then. It seems you've been trying to run the build online and thus all the deps (the maven plugin including) is pulled down too. For it's an incompatible version, the build blows up. Just a wild guess, but may be of help. Report back! ;-) Jacek -- Jacek Laskowski http://www.laskowski.net.pl -- Cheers, Guillaume Nodet -- Cheers, Guillaume Nodet
[jira] Resolved: (SM-403) The JMS spec mandates that all properties on JMS message are valid java identifiers
[ https://issues.apache.org/activemq/browse/SM-403?page=all ] Guillaume Nodet resolved SM-403. Resolution: Fixed Assignee: Guillaume Nodet Author: gnodet Date: Tue Aug 22 06:36:42 2006 New Revision: 433626 URL: http://svn.apache.org/viewvc?rev=433626view=rev Log: SM-403: add a needJavaIdentifiers property on the jms endpoint Also refactor the processors common code into the AbstractJmsProcessor Modified: incubator/servicemix/trunk/servicemix-jms/src/main/java/org/apache/servicemix/jms/AbstractJmsProcessor.java incubator/servicemix/trunk/servicemix-jms/src/main/java/org/apache/servicemix/jms/JmsEndpoint.java incubator/servicemix/trunk/servicemix-jms/src/main/java/org/apache/servicemix/jms/jca/JcaConsumerProcessor.java incubator/servicemix/trunk/servicemix-jms/src/main/java/org/apache/servicemix/jms/jca/JcaProviderProcessor.java incubator/servicemix/trunk/servicemix-jms/src/main/java/org/apache/servicemix/jms/multiplexing/MultiplexingConsumerProcessor.java incubator/servicemix/trunk/servicemix-jms/src/main/java/org/apache/servicemix/jms/multiplexing/MultiplexingProviderProcessor.java incubator/servicemix/trunk/servicemix-jms/src/main/java/org/apache/servicemix/jms/standard/StandardConsumerProcessor.java incubator/servicemix/trunk/servicemix-jms/src/main/java/org/apache/servicemix/jms/standard/StandardProviderProcessor.java incubator/servicemix/trunk/servicemix-jms/src/main/java/org/apache/servicemix/jms/wsdl/JmsAddress.java incubator/servicemix/trunk/servicemix-jms/src/main/java/org/apache/servicemix/jms/wsdl/JmsAddressDeserializer.java incubator/servicemix/trunk/servicemix-jms/src/main/java/org/apache/servicemix/jms/wsdl/JmsBinding.java incubator/servicemix/trunk/servicemix-jms/src/main/java/org/apache/servicemix/jms/wsdl/JmsExtension.java incubator/servicemix/trunk/servicemix-jms/src/test/java/org/apache/servicemix/jms/JMSComponentTest.java incubator/servicemix/trunk/servicemix-jms/src/test/java/org/apache/servicemix/jms/JmsXBeanDeployerTest.java incubator/servicemix/trunk/servicemix-jms/src/test/resources/org/apache/servicemix/jms/activemq.xml The JMS spec mandates that all properties on JMS message are valid java identifiers Key: SM-403 URL: https://issues.apache.org/activemq/browse/SM-403 Project: ServiceMix Issue Type: Bug Components: servicemix-jms Reporter: Guillaume Nodet Assigned To: Guillaume Nodet Fix For: 3.0-M3 -- 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: Exceptions in servicemix-jms with WebSphereMQ
I have just fixed that. You can now add the needJavaIdentifiers=true attribute so that all non valid properties will be skipped. Note that the Content-Type property has been renamed to MimeContentType so that mime streams can still be sent. On 8/21/06, Klaus Alfert [EMAIL PROTECTED] wrote: Hi Folks, I have a problem connecting service mix via the servicemix-jms component to a WebSphereMQ Queue. My provider configuration is as follows: !-- Reads a message from the NMR and writes them to XNEAIDV3.SMIX.TEST.2 -- jms:endpoint service=dz:MyProviderService endpoint=myProvider role=provider destinationStyle=queue jmsProviderDestinationName=XNEAIDV3.SMIX.TEST.2 connectionFactory=#jmsFactory / The message sent is as follows: ?xml version=1.0 encoding=UTF-8? sample id=0 here is some testdata /sample I get the following exception: javax.jms.MessageFormatException: MQJMS1058: Invalid message property name: Content-Type at com.ibm.jms.JMSMessage.newMessageFormatException(JMSMessage.java:4674) at com.ibm.jms.JMSMessage.setStringProperty(JMSMessage.java:5658) at org.apache.servicemix.jms.multiplexing.MultiplexingProviderProcessor.process(MultiplexingProviderProcessor.java:182) at org.apache.servicemix.common.AsyncBaseLifeCycle.processExchange(AsyncBaseLifeCycle.java:398) at org.apache.servicemix.common.BaseLifeCycle.onMessageExchange(BaseLifeCycle.java:43) at org.apache.servicemix.jbi.messaging.DeliveryChannelImpl.processInBound(DeliveryChannelImpl.java:623) at org.apache.servicemix.jbi.nmr.flow.AbstractFlow.doRouting(AbstractFlow.java:169) at org.apache.servicemix.jbi.nmr.flow.seda.SedaFlow.doRouting(SedaFlow.java:177) at org.apache.servicemix.jbi.nmr.flow.seda.SedaQueue$1.run(SedaQueue.java:227) at org.apache.geronimo.connector.work.WorkerContext.run(WorkerContext.java:291) at EDU.oswego.cs.dl.util.concurrent.PooledExecutor$Worker.run(Unknown Source) at java.lang.Thread.run(Thread.java:595) As far as I understand the code, in line 182 of MultiplexingProviderProcessor the property Content-Type is set to the value defined in the normalized message (according to http://issues.apache.org/activemq/browse/SM-502). But Content-Type is not a proper name for a JMS property (at least according to SM-398 and SM-403, I did not check the JMS spec myself) and WebSphereMQ chokes immediately. The discussion of SM-502 indicates that the Content-Type property is required for SOAP and SAAJ. However, my configuration does not use SOAP at all (which shall be the default case according to the docs). I am also not sure whether it is needed to set the content type property to the JMS message. I would expect the content-type as a part of the message payload itself but I am by no means an expert of the SOAP/JMS on the wire format. A final remark: In contrast to the marshaler in the older lightweight jms component, there is no checking of valid header names in the loop immediately before line 182. This looks like an additionally potential error source. A simple workaround is to catch and silently ignore exceptions when setting the message properties. Cheers, Klaus. -- View this message in context: http://www.nabble.com/Exceptions-in-servicemix-jms-with-WebSphereMQ-tf2141329.html#a5910358 Sent from the ServiceMix - Dev forum at Nabble.com. -- Cheers, Guillaume Nodet
[jira] Created: (GERONIMO-2343) tomcat does not use maxPostSize set in config.xml
tomcat does not use maxPostSize set in config.xml
-
Key: GERONIMO-2343
URL: http://issues.apache.org/jira/browse/GERONIMO-2343
Project: Geronimo
Issue Type: Bug
Security Level: public (Regular issues)
Components: Tomcat
Affects Versions: 1.1.2, 1.1.x
Reporter: Krishnakumar B
Attachments: tomcat-maxPostSize.patch
I set a value for maxPostSize in config.xml
gbean name=TomcatWebConnector
attribute name=host0.0.0.0/attribute
attribute name=port8080/attribute
attribute name=redirectPort8443/attribute
attribute name=bufferSizeBytes2048/attribute
attribute name=maxThreads150/attribute
attribute name=acceptQueueSize100/attribute
attribute name=lingerMillis-1/attribute
attribute name=tcpNoDelaytrue/attribute
attribute name=minSpareThreads25/attribute
attribute name=maxSpareThreads75/attribute
attribute name=maxHttpHeaderSizeBytes8192/attribute
attribute name=hostLookupEnabledfalse/attribute
attribute name=connectionTimeoutMillis2/attribute
attribute name=uploadTimeoutEnabledfalse/attribute
attribute name=maxPostSize20/attribute
attribute name=maxSavePostSize4096/attribute
attribute name=emptySessionPathfalse/attribute
/gbean
Tomcat Connector uses the value set in Connector to check for POST size.
if (len 0) {
int maxPostSize = connector.getMaxPostSize();
if ((maxPostSize 0) (len maxPostSize)) {
context.getLogger().info
(sm.getString(coyoteRequest.postTooLarge));
throw new IllegalStateException(Post too large);
}
While in Connector GBean setAttribute does not set in Connector
connector.setAttribute(maxPostSize, new Integer(bytes));
This is set in hashtable in HTTP11Protocol Handler. As a result the default
value is maintained in connector ( 2097152 )
This fix uses setter method in connector to set this value. (
connector.setMaxPostSize(bytes) )
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (GERONIMO-2343) tomcat does not use maxPostSize set in config.xml
[ http://issues.apache.org/jira/browse/GERONIMO-2343?page=all ]
Krishnakumar B updated GERONIMO-2343:
-
Attachment: tomcat-maxPostSize.patch
tomcat does not use maxPostSize set in config.xml
-
Key: GERONIMO-2343
URL: http://issues.apache.org/jira/browse/GERONIMO-2343
Project: Geronimo
Issue Type: Bug
Security Level: public(Regular issues)
Components: Tomcat
Affects Versions: 1.1.2, 1.1.x
Reporter: Krishnakumar B
Attachments: tomcat-maxPostSize.patch
I set a value for maxPostSize in config.xml
gbean name=TomcatWebConnector
attribute name=host0.0.0.0/attribute
attribute name=port8080/attribute
attribute name=redirectPort8443/attribute
attribute name=bufferSizeBytes2048/attribute
attribute name=maxThreads150/attribute
attribute name=acceptQueueSize100/attribute
attribute name=lingerMillis-1/attribute
attribute name=tcpNoDelaytrue/attribute
attribute name=minSpareThreads25/attribute
attribute name=maxSpareThreads75/attribute
attribute name=maxHttpHeaderSizeBytes8192/attribute
attribute name=hostLookupEnabledfalse/attribute
attribute name=connectionTimeoutMillis2/attribute
attribute name=uploadTimeoutEnabledfalse/attribute
attribute name=maxPostSize20/attribute
attribute name=maxSavePostSize4096/attribute
attribute name=emptySessionPathfalse/attribute
/gbean
Tomcat Connector uses the value set in Connector to check for POST size.
if (len 0) {
int maxPostSize = connector.getMaxPostSize();
if ((maxPostSize 0) (len maxPostSize)) {
context.getLogger().info
(sm.getString(coyoteRequest.postTooLarge));
throw new IllegalStateException(Post too large);
}
While in Connector GBean setAttribute does not set in Connector
connector.setAttribute(maxPostSize, new Integer(bytes));
This is set in hashtable in HTTP11Protocol Handler. As a result the default
value is maintained in connector ( 2097152 )
This fix uses setter method in connector to set this value. (
connector.setMaxPostSize(bytes) )
--
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-2342) Can't change keystore type for Jetty
[ http://issues.apache.org/jira/browse/GERONIMO-2342?page=comments#action_12429708 ] David Jencks commented on GERONIMO-2342: The jetty connector doesn't work like the tomcat one, it uses a reference to a KeystoreManager. You would have to supply a KeystoreManager that is using PKCS12. If you wanted to update the tomcat https stuff to use a KeystoreManager as well everyone would really appreciate it. Can't change keystore type for Jetty Key: GERONIMO-2342 URL: http://issues.apache.org/jira/browse/GERONIMO-2342 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: connector Affects Versions: 1.1 Reporter: Nellya Udovichenko Priority: Minor I've tried to replace Jetty SSL keystore type, for example, with PKCS12, by adding the parameter to config.xml (like I did with Tomcat): ... gbean name=JettySSLConnector attribute name=keystoreTypePKCS12/attribute attribute name=host0.0.0.0/attribute attribute name=port8443/attribute /gbean ... and got the following error log: [*] 43% 72s Startup failed org.apache.geronimo.kernel.config.LifecycleException: start of geronimo/jetty/1.1/car failed at org.apache.geronimo.kernel.config.SimpleConfigurationManager.startConfiguration(SimpleConfigurationManager.java:529) ... Caused by: java.lang.IllegalStateException: Attribute is not persistent Attribute Name: keystoreType, Type: class java.lang.String, GBeanInstance: Jetty Connector HTTPS at org.apache.geronimo.gbean.runtime.GBeanAttribute.setPersistentValue(GBeanAttribute.java:355) at org.apache.geronimo.gbean.runtime.GBeanInstance.setAttribute(GBeanInstance.java:749) at org.apache.geronimo.gbean.runtime.GBeanInstance.init(GBeanInstance.java:367) ... 17 more -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (GERONIMO-2342) Can't change keystore type for Jetty
[ http://issues.apache.org/jira/browse/GERONIMO-2342?page=all ] Nellya Udovichenko updated GERONIMO-2342: - Affects Version/s: 1.1.1 (was: 1.1) Can't change keystore type for Jetty Key: GERONIMO-2342 URL: http://issues.apache.org/jira/browse/GERONIMO-2342 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: connector Affects Versions: 1.1.1 Reporter: Nellya Udovichenko Priority: Minor I've tried to replace Jetty SSL keystore type, for example, with PKCS12, by adding the parameter to config.xml (like I did with Tomcat): ... gbean name=JettySSLConnector attribute name=keystoreTypePKCS12/attribute attribute name=host0.0.0.0/attribute attribute name=port8443/attribute /gbean ... and got the following error log: [*] 43% 72s Startup failed org.apache.geronimo.kernel.config.LifecycleException: start of geronimo/jetty/1.1/car failed at org.apache.geronimo.kernel.config.SimpleConfigurationManager.startConfiguration(SimpleConfigurationManager.java:529) ... Caused by: java.lang.IllegalStateException: Attribute is not persistent Attribute Name: keystoreType, Type: class java.lang.String, GBeanInstance: Jetty Connector HTTPS at org.apache.geronimo.gbean.runtime.GBeanAttribute.setPersistentValue(GBeanAttribute.java:355) at org.apache.geronimo.gbean.runtime.GBeanInstance.setAttribute(GBeanInstance.java:749) at org.apache.geronimo.gbean.runtime.GBeanInstance.init(GBeanInstance.java:367) ... 17 more -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Car plugin
On Aug 22, 2006, at 9:34 AM, Guillaume Nodet wrote: On 8/22/06, Guillaume Nodet [EMAIL PROTECTED] wrote: I guess I was misunderstood. I' m using the maven 2 plugin in trunk to build a plugin for Geronimo 1.1. This is the only way, because there is no maven 2 plugin for G 1.1. Everything was working fine until this recent change. If this stuff is not to be supported by the car-maven-plugin, or if there will be incompatible changes in the deployer so that the same plugin can not handle G 1.1 and 1.2, then I propose we start a new plugin (where ?) from the current one to target G 1.1. I'm not sure anyone thought of this use case: I certainly didn't. Did you find that a small change makes the trunk car plugin work with 1.1? If so I'm certainly willing to consider trying to maintain compatibility. We could also maybe put a tiny m2 project in branches/1.1 with a version of this plugin that works with 1.1 thanks david jencks Adding a property to specify the target geronimo version seems to do the trick. So i can now have: module xmlns=http://geronimo.apache.org/xml/ns/deployment-1.1; environment instead of module xmlns=http://geronimo.apache.org/xml/ns/deployment-1.1; environment xmlns=http://geronimo.apache.org/xml/ns/ deployment-1.2 Btw, I' m wondering why the PlanProcessorMojo only overrides the environmnet tag, and not the module one. On 8/22/06, Jacek Laskowski [EMAIL PROTECTED] wrote: On 8/22/06, Guillaume Nodet [EMAIL PROTECTED] wrote: I recently experienced some problems [1] when building Geronimo 1.1 plugins using the car-maven-plugin. I think a solution may be to build the maven plugin locally from 1.1 sources and build Geronimo 1.1 then. It seems you've been trying to run the build online and thus all the deps (the maven plugin including) is pulled down too. For it's an incompatible version, the build blows up. Just a wild guess, but may be of help. Report back! ;-) Jacek -- Jacek Laskowski http://www.laskowski.net.pl -- Cheers, Guillaume Nodet -- Cheers, Guillaume Nodet
Re: in case anyone else is still building 1.0
On Aug 18, 2006, at 2:47 PM, toby cabot wrote:
Hi Folks,
We're using 1.0 and while it's getting a little long in the tooth it
still works great. I tried to build it the other day and had some
problems, mostly relating to various external infrastructure changing.
If anyone cares, here are the changes that I made to get the build to
work. Basically it's just changing from cvs.apache.org to
people.apache.org because cvs.a.o sends an http redirect which Maven
can't handle, and changing to use http instead of https when checking
out openejb from codehaus.org.
Toby,
Thanks for documenting this.
--kevan
Toby
Index: plugins/project.properties
===
--- plugins/project.properties (revision 431689)
+++ plugins/project.properties (working copy)
@@ -27,6 +27,6 @@
maven.remote.group=apcvs
maven.username=${user.name}
maven.repo.central=apache.org
-maven.repo.central.directory=/www/cvs.apache.org/repository
+maven.repo.central.directory=/www/people.apache.org/repository
Index: plugins/geronimo-packaging-plugin/project.properties
===
--- plugins/geronimo-packaging-plugin/project.properties (revision
431689)
+++ plugins/geronimo-packaging-plugin/project.properties (working
copy)
@@ -22,7 +22,7 @@
maven.compile.source=1.4
maven.compile.target=1.4
-maven.repo.remote=http://cvs.apache.org/repository, http://
www.ibiblio.org/maven
+maven.repo.remote=http://people.apache.org/repository, http://
www.ibiblio.org/maven
maven.multiproject.type=plugin
Index: applications/project.properties
===
--- applications/project.properties (revision 431689)
+++ applications/project.properties (working copy)
@@ -30,6 +30,6 @@
maven.remote.group=apcvs
maven.username=${user.name}
maven.repo.central=apache.org
-maven.repo.central.directory=/www/cvs.apache.org/repository
+maven.repo.central.directory=/www/people.apache.org/repository
Index: project.properties
===
--- project.properties (revision 431689)
+++ project.properties (working copy)
@@ -57,7 +57,7 @@
maven.username=${user.name}
maven.repo.central=apache.org
-maven.repo.central.directory=/www/cvs.apache.org/repository
+maven.repo.central.directory=/www/people.apache.org/repository
Index: maven.xml
===
--- maven.xml (revision 431689)
+++ maven.xml (working copy)
@@ -281,7 +281,7 @@
!--gscm:checkout module=howl/logger root=$
[EMAIL PROTECTED]:/cvsroot/howl/--
!-- http isn't working to svn.codehaus.org. so using
https for now... --
ant:exec dir=${basedir} executable=svn
-ant:arg line=checkout https://svn.codehaus.org/
openejb/branches/v2_0/openejb2 openejb/
+ant:arg line=checkout http://svn.codehaus.org/
openejb/branches/v2_0/openejb2 openejb/
/ant:exec
!--gscm:checkout-tag module=openejb root=$
[EMAIL PROTECTED]:/home/projects/
openejb/scm tag=v2_0/ --
!--
Index: modules/project.properties
===
--- modules/project.properties (revision 431689)
+++ modules/project.properties (working copy)
@@ -30,6 +30,6 @@
maven.remote.group=apcvs
maven.username=${user.name}
maven.repo.central=apache.org
-maven.repo.central.directory=/www/cvs.apache.org/repository
+maven.repo.central.directory=/www/people.apache.org/repository
Index: etc/project.properties
===
--- etc/project.properties (revision 431689)
+++ etc/project.properties (working copy)
@@ -26,7 +26,7 @@
#
maven.repo.remote=\
-http://cvs.apache.org/repository,\
+http://people.apache.org/repo/m1-snapshot-repository,\
http://dist.codehaus.org,\
http://www.mortbay.org/maven,\
http://www.ibiblio.org/maven
Re: [VOTE] Specs organization, versioning, and releasing
+1.
Jason Dillon wrote:
PROPOSAL:
1. Each spec will no longer be split up into trunk+branches+tags. There
will instead be one trunk+branches+tags for all specs laid out as follows:
specs/trunk/pom.xml
specs/trunk/artifactId
specs/tags/artifactId-version
specs/branches/
2. Each plugin will continue to have its own version and will be
released independently.
3. The top-level will have it's own version, which will remain
independent. When there is a major configuration change in that pom,
the version will be changed and the pom will be republished.
4. Releasing will be done with the maven release plugin ('mvn release')
and should occur at a stable point after any major change to a spec module.
5. Change all module directories to match artifactIds.
MOTIVATION:
1. one trunk allows the entire set of specs to be checked out all at
once and built all at once.
* * *
[ ] +1 Allow changes
[ ] 0 No opinion
[ ] -1 No, leave the specs asis (provide rationale)
--jason
Re: Car plugin
On 8/22/06, David Jencks [EMAIL PROTECTED] wrote: On Aug 22, 2006, at 9:34 AM, Guillaume Nodet wrote: On 8/22/06, Guillaume Nodet [EMAIL PROTECTED] wrote: I guess I was misunderstood. I' m using the maven 2 plugin in trunk to build a plugin for Geronimo 1.1. This is the only way, because there is no maven 2 plugin for G 1.1. Everything was working fine until this recent change. If this stuff is not to be supported by the car-maven-plugin, or if there will be incompatible changes in the deployer so that the same plugin can not handle G 1.1 and 1.2, then I propose we start a new plugin (where ?) from the current one to target G 1.1. I'm not sure anyone thought of this use case: I certainly didn't. Did you find that a small change makes the trunk car plugin work with 1.1? If so I'm certainly willing to consider trying to maintain compatibility. Aaron and Dain did as they built plugins for Geronimo 1.1 using a m2 build. And there' s no other way to do that afaik. And yes, I found a way. So i will check it in. We could also maybe put a tiny m2 project in branches/1.1 with a version of this plugin that works with 1.1 thanks david jencks Adding a property to specify the target geronimo version seems to do the trick. So i can now have: module xmlns=http://geronimo.apache.org/xml/ns/deployment-1.1; environment instead of module xmlns=http://geronimo.apache.org/xml/ns/deployment-1.1; environment xmlns=http://geronimo.apache.org/xml/ns/ deployment-1.2 Btw, I' m wondering why the PlanProcessorMojo only overrides the environmnet tag, and not the module one. On 8/22/06, Jacek Laskowski [EMAIL PROTECTED] wrote: On 8/22/06, Guillaume Nodet [EMAIL PROTECTED] wrote: I recently experienced some problems [1] when building Geronimo 1.1 plugins using the car-maven-plugin. I think a solution may be to build the maven plugin locally from 1.1 sources and build Geronimo 1.1 then. It seems you've been trying to run the build online and thus all the deps (the maven plugin including) is pulled down too. For it's an incompatible version, the build blows up. Just a wild guess, but may be of help. Report back! ;-) Jacek -- Jacek Laskowski http://www.laskowski.net.pl -- Cheers, Guillaume Nodet -- Cheers, Guillaume Nodet -- Cheers, Guillaume Nodet
Re: Car plugin
On 8/22/06, David Jencks [EMAIL PROTECTED] wrote: I'm not sure anyone thought of this use case: I certainly didn't. Did you find that a small change makes the trunk car plugin work with 1.1? If so I'm certainly willing to consider trying to maintain compatibility. They certainly have -- I've asked about this before. I specifically asked to have a working car-maven-plugin along with any reuqired G libs saved as a new version so we could refer to that version eternally and not have to worry about upgrades causing problems. Jason said he couldn't do it but he was going to publish a new snapshot... We could also maybe put a tiny m2 project in branches/1.1 with a version of this plugin that works with 1.1 I think the problem is not so much the plugin itself, as the fact that the plugin is built against G 1.2 JARs (for the kernel and system modules, etc.). I think any problem with the deployer can be avoided by specifying the correct set of dependencies and configuration info in the project POM (to force it to use only 1.1 JARs/CARs and the 1.1 deployer GBean). But if any of the kernel/system interfaces changed, that would probably stop working. Thanks, Aaron Adding a property to specify the target geronimo version seems to do the trick. So i can now have: module xmlns=http://geronimo.apache.org/xml/ns/deployment-1.1; environment instead of module xmlns=http://geronimo.apache.org/xml/ns/deployment-1.1; environment xmlns=http://geronimo.apache.org/xml/ns/ deployment-1.2 Btw, I' m wondering why the PlanProcessorMojo only overrides the environmnet tag, and not the module one. On 8/22/06, Jacek Laskowski [EMAIL PROTECTED] wrote: On 8/22/06, Guillaume Nodet [EMAIL PROTECTED] wrote: I recently experienced some problems [1] when building Geronimo 1.1 plugins using the car-maven-plugin. I think a solution may be to build the maven plugin locally from 1.1 sources and build Geronimo 1.1 then. It seems you've been trying to run the build online and thus all the deps (the maven plugin including) is pulled down too. For it's an incompatible version, the build blows up. Just a wild guess, but may be of help. Report back! ;-) Jacek -- Jacek Laskowski http://www.laskowski.net.pl -- Cheers, Guillaume Nodet -- Cheers, Guillaume Nodet
Re: Exceptions in servicemix-jms with WebSphereMQ
Great. I'll give it a try. Klaus. gnodet wrote: I have just fixed that. You can now add the needJavaIdentifiers=true attribute so that all non valid properties will be skipped. Note that the Content-Type property has been renamed to MimeContentType so that mime streams can still be sent. On 8/21/06, Klaus Alfert [EMAIL PROTECTED] wrote: Hi Folks, I have a problem connecting service mix via the servicemix-jms component to a WebSphereMQ Queue. My provider configuration is as follows: !-- Reads a message from the NMR and writes them to XNEAIDV3.SMIX.TEST.2 -- jms:endpoint service=dz:MyProviderService endpoint=myProvider role=provider destinationStyle=queue jmsProviderDestinationName=XNEAIDV3.SMIX.TEST.2 connectionFactory=#jmsFactory / The message sent is as follows: ?xml version=1.0 encoding=UTF-8? sample id=0 here is some testdata /sample I get the following exception: javax.jms.MessageFormatException: MQJMS1058: Invalid message property name: Content-Type at com.ibm.jms.JMSMessage.newMessageFormatException(JMSMessage.java:4674) at com.ibm.jms.JMSMessage.setStringProperty(JMSMessage.java:5658) at org.apache.servicemix.jms.multiplexing.MultiplexingProviderProcessor.process(MultiplexingProviderProcessor.java:182) at org.apache.servicemix.common.AsyncBaseLifeCycle.processExchange(AsyncBaseLifeCycle.java:398) at org.apache.servicemix.common.BaseLifeCycle.onMessageExchange(BaseLifeCycle.java:43) at org.apache.servicemix.jbi.messaging.DeliveryChannelImpl.processInBound(DeliveryChannelImpl.java:623) at org.apache.servicemix.jbi.nmr.flow.AbstractFlow.doRouting(AbstractFlow.java:169) at org.apache.servicemix.jbi.nmr.flow.seda.SedaFlow.doRouting(SedaFlow.java:177) at org.apache.servicemix.jbi.nmr.flow.seda.SedaQueue$1.run(SedaQueue.java:227) at org.apache.geronimo.connector.work.WorkerContext.run(WorkerContext.java:291) at EDU.oswego.cs.dl.util.concurrent.PooledExecutor$Worker.run(Unknown Source) at java.lang.Thread.run(Thread.java:595) As far as I understand the code, in line 182 of MultiplexingProviderProcessor the property Content-Type is set to the value defined in the normalized message (according to http://issues.apache.org/activemq/browse/SM-502). But Content-Type is not a proper name for a JMS property (at least according to SM-398 and SM-403, I did not check the JMS spec myself) and WebSphereMQ chokes immediately. The discussion of SM-502 indicates that the Content-Type property is required for SOAP and SAAJ. However, my configuration does not use SOAP at all (which shall be the default case according to the docs). I am also not sure whether it is needed to set the content type property to the JMS message. I would expect the content-type as a part of the message payload itself but I am by no means an expert of the SOAP/JMS on the wire format. A final remark: In contrast to the marshaler in the older lightweight jms component, there is no checking of valid header names in the loop immediately before line 182. This looks like an additionally potential error source. A simple workaround is to catch and silently ignore exceptions when setting the message properties. Cheers, Klaus. -- View this message in context: http://www.nabble.com/Exceptions-in-servicemix-jms-with-WebSphereMQ-tf2141329.html#a5910358 Sent from the ServiceMix - Dev forum at Nabble.com. -- Cheers, Guillaume Nodet -- View this message in context: http://www.nabble.com/Exceptions-in-servicemix-jms-with-WebSphereMQ-tf2141329.html#a5926206 Sent from the ServiceMix - Dev forum at Nabble.com.
Re: Car plugin
On 8/22/06, Aaron Mulder [EMAIL PROTECTED] wrote: On 8/22/06, David Jencks [EMAIL PROTECTED] wrote: I'm not sure anyone thought of this use case: I certainly didn't. Did you find that a small change makes the trunk car plugin work with 1.1? If so I'm certainly willing to consider trying to maintain compatibility. They certainly have -- I've asked about this before. I specifically asked to have a working car-maven-plugin along with any reuqired G libs saved as a new version so we could refer to that version eternally and not have to worry about upgrades causing problems. Jason said he couldn't do it but he was going to publish a new snapshot... We could also maybe put a tiny m2 project in branches/1.1 with a version of this plugin that works with 1.1 I think the problem is not so much the plugin itself, as the fact that the plugin is built against G 1.2 JARs (for the kernel and system modules, etc.). Yeah, I know, but is there any other way to deal with that, but forking the plugin and build one version against G 1.1 jars ? I think any problem with the deployer can be avoided by specifying the correct set of dependencies and configuration info in the project POM (to force it to use only 1.1 JARs/CARs and the 1.1 deployer GBean). But if any of the kernel/system interfaces changed, that would probably stop working. Actually, that' s the main problem. Maybe it would be wiser to fork it. This would also allow to release one version of the m2 plugin for 1.1 asap. Thanks, Aaron Adding a property to specify the target geronimo version seems to do the trick. So i can now have: module xmlns=http://geronimo.apache.org/xml/ns/deployment-1.1; environment instead of module xmlns=http://geronimo.apache.org/xml/ns/deployment-1.1; environment xmlns=http://geronimo.apache.org/xml/ns/ deployment-1.2 Btw, I' m wondering why the PlanProcessorMojo only overrides the environmnet tag, and not the module one. On 8/22/06, Jacek Laskowski [EMAIL PROTECTED] wrote: On 8/22/06, Guillaume Nodet [EMAIL PROTECTED] wrote: I recently experienced some problems [1] when building Geronimo 1.1 plugins using the car-maven-plugin. I think a solution may be to build the maven plugin locally from 1.1 sources and build Geronimo 1.1 then. It seems you've been trying to run the build online and thus all the deps (the maven plugin including) is pulled down too. For it's an incompatible version, the build blows up. Just a wild guess, but may be of help. Report back! ;-) Jacek -- Jacek Laskowski http://www.laskowski.net.pl -- Cheers, Guillaume Nodet -- Cheers, Guillaume Nodet -- Cheers, Guillaume Nodet
Re: Car plugin
On 8/22/06, Guillaume Nodet [EMAIL PROTECTED] wrote: I think any problem with the deployer can be avoided by specifying the correct set of dependencies and configuration info in the project POM (to force it to use only 1.1 JARs/CARs and the 1.1 deployer GBean). But if any of the kernel/system interfaces changed, that would probably stop working. Actually, that' s the main problem. I'm not convinced. If I understand this correctly, you got a problem when the G 1.2 service builder attempted to do something with a G 1.1 deployment plan. I think you can avoid the 1.2 service builder being invoked by listing all the 1.1 dependencies explicitly. Is that not what's going on? Thanks, Aaron Adding a property to specify the target geronimo version seems to do the trick. So i can now have: module xmlns=http://geronimo.apache.org/xml/ns/deployment-1.1; environment instead of module xmlns=http://geronimo.apache.org/xml/ns/deployment-1.1; environment xmlns=http://geronimo.apache.org/xml/ns/ deployment-1.2 Btw, I' m wondering why the PlanProcessorMojo only overrides the environmnet tag, and not the module one. On 8/22/06, Jacek Laskowski [EMAIL PROTECTED] wrote: On 8/22/06, Guillaume Nodet [EMAIL PROTECTED] wrote: I recently experienced some problems [1] when building Geronimo 1.1 plugins using the car-maven-plugin. I think a solution may be to build the maven plugin locally from 1.1 sources and build Geronimo 1.1 then. It seems you've been trying to run the build online and thus all the deps (the maven plugin including) is pulled down too. For it's an incompatible version, the build blows up. Just a wild guess, but may be of help. Report back! ;-) Jacek -- Jacek Laskowski http://www.laskowski.net.pl -- Cheers, Guillaume Nodet -- Cheers, Guillaume Nodet -- Cheers, Guillaume Nodet
Re: Car plugin
On 8/22/06, Aaron Mulder [EMAIL PROTECTED] wrote: On 8/22/06, Guillaume Nodet [EMAIL PROTECTED] wrote: I think any problem with the deployer can be avoided by specifying the correct set of dependencies and configuration info in the project POM (to force it to use only 1.1 JARs/CARs and the 1.1 deployer GBean). But if any of the kernel/system interfaces changed, that would probably stop working. Actually, that' s the main problem. I'm not convinced. If I understand this correctly, you got a problem when the G 1.2 service builder attempted to do something with a G 1.1 deployment plan. I think you can avoid the 1.2 service builder being invoked by listing all the 1.1 dependencies explicitly. Is that not what's going on? The problem is very simple. That processed plan begins with module xmlns=http://geronimo.apache.org/xml/ns/deployment-1.1; environment xmlns=http://geronimo.apache.org/xml/ns/deployment-1.2; which is rejected when deployed on G 1.1. Btw, it really sounds weird that the plugin process the environment tag, but not the module tag... My fix is to allow specifying the target geronimo version, so that the plugin will build the namespace uri dynamically: URI_PREFIX + 1.2. This works. What I meant, is that I' m not convinced that the API will never change and that a single plugin will be able to handle all versions in the future. This is already the case for the schema which are upgraded by default, even if no change happen (I do not argue against that, just stating the fact). But if something change, the plugin will need to cope with the difference. Is that what we want ? Also, I think it would be good to be able to release the plugin without having to wait for G 1.2 final, so that users can build G 1.1 plugins easily. Thanks, Aaron Adding a property to specify the target geronimo version seems to do the trick. So i can now have: module xmlns=http://geronimo.apache.org/xml/ns/deployment-1.1; environment instead of module xmlns=http://geronimo.apache.org/xml/ns/deployment-1.1; environment xmlns=http://geronimo.apache.org/xml/ns/ deployment-1.2 Btw, I' m wondering why the PlanProcessorMojo only overrides the environmnet tag, and not the module one. On 8/22/06, Jacek Laskowski [EMAIL PROTECTED] wrote: On 8/22/06, Guillaume Nodet [EMAIL PROTECTED] wrote: I recently experienced some problems [1] when building Geronimo 1.1 plugins using the car-maven-plugin. I think a solution may be to build the maven plugin locally from 1.1 sources and build Geronimo 1.1 then. It seems you've been trying to run the build online and thus all the deps (the maven plugin including) is pulled down too. For it's an incompatible version, the build blows up. Just a wild guess, but may be of help. Report back! ;-) Jacek -- Jacek Laskowski http://www.laskowski.net.pl -- Cheers, Guillaume Nodet -- Cheers, Guillaume Nodet -- Cheers, Guillaume Nodet -- Cheers, Guillaume Nodet
[jira] Commented: (GERONIMO-2326) unable to deploy a database pool
[ http://issues.apache.org/jira/browse/GERONIMO-2326?page=comments#action_12429715 ] Bill Dudney commented on GERONIMO-2326: --- The GERONIMO-2326.djencks-2.patch patch fixes tomcat as well for all 4 derby configs (embeded, network, xa-embeded, xa-network). unable to deploy a database pool Key: GERONIMO-2326 URL: http://issues.apache.org/jira/browse/GERONIMO-2326 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Affects Versions: 1.2, 1.1.2 Reporter: Bill Dudney Assigned To: David Jencks Fix For: 1.1.2, 1.2 Attachments: 2326-deploy-datasource.patch, GERONIMO-2326.djencks-2.patch, GERONIMO-2326.djencks.patch Trying to deploy a jdbc datasource leads to a blank screen and the following stack trace in the log. The issue appears to be that URLPatternSpec does not like the URL generated by DatabasePoolPortlet from the info found in the DatabaseInfo.ALL_DATABASES array. java.lang.IllegalArgumentException: Qualifier patterns must be present when first URLPattern is an exact pattern at javax.security.jacc.URLPatternSpec.init(URLPatternSpec.java:98) at javax.security.jacc.WebUserDataPermission.init(WebUserDataPermission.java:83) at org.apache.geronimo.tomcat.realm.TomcatGeronimoRealm.hasUserDataPermission(TomcatGeronimoRealm.java:131) at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:460) at org.apache.geronimo.tomcat.GeronimoStandardContext$SystemMethodValve.invoke(GeronimoStandardContext.java:322) at org.apache.geronimo.tomcat.valve.GeronimoBeforeAfterValve.invoke(GeronimoBeforeAfterValve.java:31) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:869) at org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection(Http11BaseProtocol.java:667) at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:527) at org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(LeaderFollowerWorkerThread.java:80) at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:684) at java.lang.Thread.run(Thread.java:552) -- 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: Exceptions in servicemix-jms with WebSphereMQ
Hi Guillaume, after an svn update (to revision 433641), I got a compile error. Is there some checking pending? Compiling 24 source files to /home/alfert/src/service-mix/svn-trunk/trunk/servicemix-jms/target/classes [INFO] [ERROR] BUILD FAILURE [INFO] [INFO] Compilation failure /home/alfert/src/service-mix/svn-trunk/trunk/servicemix-jms/src/main/java/org/apache/servicemix/jms/AbstractJmsProcessor.java:[174,25] createContext(org.apache.servicemix.soap.marshalers.SoapMessage) in org.apache.servicemix.soap.SoapHelper cannot be applied to () Klaus. gnodet wrote: I have just fixed that. You can now add the needJavaIdentifiers=true attribute so that all non valid properties will be skipped. Note that the Content-Type property has been renamed to MimeContentType so that mime streams can still be sent. [..] -- Cheers, Guillaume Nodet -- View this message in context: http://www.nabble.com/Exceptions-in-servicemix-jms-with-WebSphereMQ-tf2141329.html#a5926623 Sent from the ServiceMix - Dev forum at Nabble.com.
Re: Exceptions in servicemix-jms with WebSphereMQ
Oops, sorry. This is fixed. On 8/22/06, Klaus Alfert [EMAIL PROTECTED] wrote: Hi Guillaume, after an svn update (to revision 433641), I got a compile error. Is there some checking pending? Compiling 24 source files to /home/alfert/src/service-mix/svn-trunk/trunk/servicemix-jms/target/classes [INFO] [ERROR] BUILD FAILURE [INFO] [INFO] Compilation failure /home/alfert/src/service-mix/svn-trunk/trunk/servicemix-jms/src/main/java/org/apache/servicemix/jms/AbstractJmsProcessor.java:[174,25] createContext(org.apache.servicemix.soap.marshalers.SoapMessage) in org.apache.servicemix.soap.SoapHelper cannot be applied to () Klaus. gnodet wrote: I have just fixed that. You can now add the needJavaIdentifiers=true attribute so that all non valid properties will be skipped. Note that the Content-Type property has been renamed to MimeContentType so that mime streams can still be sent. [..] -- Cheers, Guillaume Nodet -- View this message in context: http://www.nabble.com/Exceptions-in-servicemix-jms-with-WebSphereMQ-tf2141329.html#a5926623 Sent from the ServiceMix - Dev forum at Nabble.com. -- Cheers, Guillaume Nodet
[jira] Updated: (GERONIMO-2326) unable to deploy a database pool
[ http://issues.apache.org/jira/browse/GERONIMO-2326?page=all ] Bill Dudney updated GERONIMO-2326: -- Attachment: GERONIMO-2326.bdudney-additional.patch sorry got a bit ahead of myself, I also had to apply this patch to the root pom to get the 1.1 version of the tranql/tranql-connector/rar. The 1.1. version is refered to explicitly by the DatabaseInfo class, perhaps David you had copied the 1.1. version into your geronimo repo? The real solution is to copy the changes that have been made in the 1.1 branch for the console to the trunk. unable to deploy a database pool Key: GERONIMO-2326 URL: http://issues.apache.org/jira/browse/GERONIMO-2326 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Affects Versions: 1.2, 1.1.2 Reporter: Bill Dudney Assigned To: David Jencks Fix For: 1.1.2, 1.2 Attachments: 2326-deploy-datasource.patch, GERONIMO-2326.bdudney-additional.patch, GERONIMO-2326.djencks-2.patch, GERONIMO-2326.djencks.patch Trying to deploy a jdbc datasource leads to a blank screen and the following stack trace in the log. The issue appears to be that URLPatternSpec does not like the URL generated by DatabasePoolPortlet from the info found in the DatabaseInfo.ALL_DATABASES array. java.lang.IllegalArgumentException: Qualifier patterns must be present when first URLPattern is an exact pattern at javax.security.jacc.URLPatternSpec.init(URLPatternSpec.java:98) at javax.security.jacc.WebUserDataPermission.init(WebUserDataPermission.java:83) at org.apache.geronimo.tomcat.realm.TomcatGeronimoRealm.hasUserDataPermission(TomcatGeronimoRealm.java:131) at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:460) at org.apache.geronimo.tomcat.GeronimoStandardContext$SystemMethodValve.invoke(GeronimoStandardContext.java:322) at org.apache.geronimo.tomcat.valve.GeronimoBeforeAfterValve.invoke(GeronimoBeforeAfterValve.java:31) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:869) at org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection(Http11BaseProtocol.java:667) at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:527) at org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(LeaderFollowerWorkerThread.java:80) at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:684) at java.lang.Thread.run(Thread.java:552) -- 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: Car plugin
If the only difference is the target version of the build, I'm not seeing a need to fork. You should be able to use profiles (http://maven.apache.org/guides/introduction/introduction-to-profiles.html) to specify version-specific dependencies without the need to modify the source. I see this as being analagous to building with different JDK versions. I apologize if there is something I'm missing that makes this more complex than it seems. Ian It's better to be hated for who you are than loved for who you're not Ian D. Stewart Distributed Computing Engineer II DSS eCommerce Engineering JPMorganChase Global Technology Infrastructure Phone: (614) 244-2564 Guillaume Nodet [EMAIL PROTECTED] To dev@geronimo.apache.org 08/22/2006 10:08 cc AM Subject Re: Car plugin Please respond to [EMAIL PROTECTED] he.org On 8/22/06, Aaron Mulder [EMAIL PROTECTED] wrote: On 8/22/06, David Jencks [EMAIL PROTECTED] wrote: I'm not sure anyone thought of this use case: I certainly didn't. Did you find that a small change makes the trunk car plugin work with 1.1? If so I'm certainly willing to consider trying to maintain compatibility. They certainly have -- I've asked about this before. I specifically asked to have a working car-maven-plugin along with any reuqired G libs saved as a new version so we could refer to that version eternally and not have to worry about upgrades causing problems. Jason said he couldn't do it but he was going to publish a new snapshot... We could also maybe put a tiny m2 project in branches/1.1 with a version of this plugin that works with 1.1 I think the problem is not so much the plugin itself, as the fact that the plugin is built against G 1.2 JARs (for the kernel and system modules, etc.). Yeah, I know, but is there any other way to deal with that, but forking the plugin and build one version against G 1.1 jars ? I think any problem with the deployer can be avoided by specifying the correct set of dependencies and configuration info in the project POM (to force it to use only 1.1 JARs/CARs and the 1.1 deployer GBean). But if any of the kernel/system interfaces changed, that would probably stop working. Actually, that' s the main problem. Maybe it would be wiser to fork it. This would also allow to release one version of the m2 plugin for 1.1 asap. Thanks, Aaron Adding a property to specify the target geronimo version seems to do the trick. So i can now have: module xmlns=http://geronimo.apache.org/xml/ns/deployment-1.1; environment instead of module xmlns=http://geronimo.apache.org/xml/ns/deployment-1.1; environment xmlns=http://geronimo.apache.org/xml/ns/ deployment-1.2 Btw, I' m wondering why the PlanProcessorMojo only overrides the environmnet tag, and not the module one. On 8/22/06, Jacek Laskowski [EMAIL PROTECTED] wrote: On 8/22/06, Guillaume Nodet [EMAIL PROTECTED] wrote: I recently experienced some problems [1] when building Geronimo 1.1 plugins using the car-maven-plugin. I think a solution may be to build the maven plugin locally from 1.1 sources and build Geronimo 1.1 then. It seems you've been trying to run the build online and thus all the deps (the maven plugin including) is pulled down too. For it's an incompatible version, the build blows up. Just a wild guess, but may be of help. Report back! ;-) Jacek -- Jacek Laskowski http://www.laskowski.net.pl -- Cheers, Guillaume Nodet -- Cheers, Guillaume Nodet -- Cheers, Guillaume Nodet - This transmission may contain information that is privileged, confidential, legally privileged, and/or exempt from disclosure under applicable law. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, or use of the information contained herein
Re: Multiple HTTP Component(s)?
I think there is a consensus, that the lightweight components model is really confusing. In the future, we will try to make new std jbi components out of the old components and deprecate them. The POJO component should be an easy alternative for more jbi oriented simple components. On 8/21/06, Brian O'Neill [EMAIL PROTECTED] wrote: The behavior of servicemix-components/http component and the servicemix-http component appear to differ. Can someone explain the difference between these two? Both appear to provide HTTP client/server functionality. In general, what is the status of the components under servicemix-components? We are interested in using rss and jabber as well, and could potentially contribute one or more of our own. I know there was some discussion on minimizing the number of components in the code-base, and to break out component development elsewhere. Was this resolved? -brian Brian ONeill Technical Architect, Gestalt LLC [EMAIL PROTECTED] 215.588.6024 (m) -- Cheers, Guillaume Nodet
Re: Car plugin
Here is my diff, so that hopefully if will make things clearer.But i really think this is more of a hack than a clean way to solve the differences between the schemas ;)Index: src/main/java/org/apache/geronimo/plugin/car/PlanProcessorMojo.java
===--- src/main/java/org/apache/geronimo/plugin/car/PlanProcessorMojo.java (revision 432624)+++ src/main/java/org/apache/geronimo/plugin/car/PlanProcessorMojo.java (working copy)
@@ -61,7 +61,7 @@ { private static final String ENVIRONMENT_LOCAL_NAME = environment; -private static final QName ENVIRONMENT_QNAME = new QName(
http://geronimo.apache.org/xml/ns/deployment-1.2, environment);+private static final String ENVIRONMENT_URI_PREFIX = http://geronimo.apache.org/xml/ns/deployment-
; /*** @parameter _expression_=${basedir}/src/plan@@ -86,7 +86,13 @@* @required*/ private File targetFile;-++/**+ * @parameter _expression_=
1.2+ * @required + */+private String geronimoVersion;+ private VelocityContext createContext() { VelocityContext context = new VelocityContext(); @@ -157,9 +163,11 @@
xmlCursor.toFirstChild(); QName childName = xmlCursor.getName(); Environment oldEnvironment;++QName environmentQName = new QName(ENVIRONMENT_URI_PREFIX + geronimoVersion, ENVIRONMENT_LOCAL_NAME);
if (childName != null childName.getLocalPart().equals(ENVIRONMENT_LOCAL_NAME)) {-convertElement(xmlCursor, ENVIRONMENT_QNAME.getNamespaceURI());+convertElement(xmlCursor,
environmentQName.getNamespaceURI()); XmlObject xmlObject = xmlCursor.getObject(); EnvironmentType environmentType = (EnvironmentType) xmlObject.copy().changeType(EnvironmentType.type); oldEnvironment =
EnvironmentBuilder.buildEnvironment(environmentType);@@ -176,7 +184,7 @@ EnvironmentBuilder.mergeEnvironments(oldEnvironment, newEnvironment); EnvironmentType environmentType = EnvironmentBuilder.buildEnvironmentType
(oldEnvironment); -xmlCursor.beginElement(ENVIRONMENT_QNAME);+xmlCursor.beginElement(environmentQName); XmlCursor element = environmentType.newCursor(); try {
On 8/22/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: If the only difference is the target version of the build, I'm not seeing a
need to fork.You should be able to use profiles (http://maven.apache.org/guides/introduction/introduction-to-profiles.html
) to specify version-specific dependencies without the need to modify the source.I see this as being analagous to building with different JDK versions. I apologize if there is something I'm missing that makes this more complex
than it seems. Ian It's better to be hated for who you are than loved for who you're not Ian D. Stewart Distributed Computing Engineer II
DSS eCommerce Engineering JPMorganChase Global Technology Infrastructure Phone: (614) 244-2564 Guillaume Nodet
[EMAIL PROTECTED]To
dev@geronimo.apache.org08/22/2006 10:08 ccAMSubject
Re: Car pluginPlease respond to[EMAIL PROTECTED]
he.orgOn 8/22/06, Aaron Mulder [EMAIL PROTECTED] wrote: On 8/22/06, David Jencks
[EMAIL PROTECTED] wrote: I'm not sure anyone thought of this use case: I certainly didn't. Did you find that a small change makes the trunk car plugin work with
1.1?If so I'm certainly willing to consider trying to maintain compatibility. They certainly have -- I've asked about this before.I specifically asked to have a working car-maven-plugin along with any reuqired G
libs saved as a new version so we could refer to that version eternally and not have to worry about upgrades causing problems. Jason said he couldn't do it but he was going to publish a new
snapshot...We could also maybe put a tiny m2 project in branches/1.1 with a version of this plugin that works with 1.1 I think the problem is not so much the plugin itself, as the fact that
the plugin is built against G 1.2 JARs (for the kernel and system modules, etc.). Yeah, I know, but is there any other way to deal with that, but forking the plugin and build one version against G
1.1 jars ?I think any problem with the deployer can be avoided by specifying the correct set of dependencies and configuration info in the project POM (to force it to use only
1.1 JARs/CARs and the 1.1 deployer GBean). But if any of the kernel/system interfaces changed, that would probably stop working. Actually, that' s the main problem. Maybe it would be wiser to fork it.
This would also allow to release one version of the m2 plugin for 1.1 asap.Thanks, Aaron Adding a property to specify the target geronimo version seems to
do the trick.So i can now have: module xmlns=
http://geronimo.apache.org/xml/ns/deployment-1.1environment instead of module xmlns=
http://geronimo.apache.org/xml/ns/deployment-1.1environment xmlns=
http://geronimo.apache.org/xml/ns/deployment-1.2 Btw, I' m wondering why the PlanProcessorMojo only overrides theenvironmnet
tag, and not the module one. On 8/22/06, Jacek Laskowski [EMAIL
Re: Car plugin
Ah, I see -- it's that the plugin plan writing causes problems. In any case, I agree that it would be nice to have a dedicated G 1.1 version of the car-maven-plugin. Thanks, Aaron On 8/22/06, Guillaume Nodet [EMAIL PROTECTED] wrote: On 8/22/06, Aaron Mulder [EMAIL PROTECTED] wrote: On 8/22/06, Guillaume Nodet [EMAIL PROTECTED] wrote: I think any problem with the deployer can be avoided by specifying the correct set of dependencies and configuration info in the project POM (to force it to use only 1.1 JARs/CARs and the 1.1 deployer GBean). But if any of the kernel/system interfaces changed, that would probably stop working. Actually, that' s the main problem. I'm not convinced. If I understand this correctly, you got a problem when the G 1.2 service builder attempted to do something with a G 1.1 deployment plan. I think you can avoid the 1.2 service builder being invoked by listing all the 1.1 dependencies explicitly. Is that not what's going on? The problem is very simple. That processed plan begins with module xmlns=http://geronimo.apache.org/xml/ns/deployment-1.1; environment xmlns=http://geronimo.apache.org/xml/ns/deployment-1.2; which is rejected when deployed on G 1.1. Btw, it really sounds weird that the plugin process the environment tag, but not the module tag... My fix is to allow specifying the target geronimo version, so that the plugin will build the namespace uri dynamically: URI_PREFIX + 1.2. This works. What I meant, is that I' m not convinced that the API will never change and that a single plugin will be able to handle all versions in the future. This is already the case for the schema which are upgraded by default, even if no change happen (I do not argue against that, just stating the fact). But if something change, the plugin will need to cope with the difference. Is that what we want ? Also, I think it would be good to be able to release the plugin without having to wait for G 1.2 final, so that users can build G 1.1 plugins easily. Thanks, Aaron Adding a property to specify the target geronimo version seems to do the trick. So i can now have: module xmlns=http://geronimo.apache.org/xml/ns/deployment-1.1; environment instead of module xmlns=http://geronimo.apache.org/xml/ns/deployment-1.1; environment xmlns=http://geronimo.apache.org/xml/ns/ deployment-1.2 Btw, I' m wondering why the PlanProcessorMojo only overrides the environmnet tag, and not the module one. On 8/22/06, Jacek Laskowski [EMAIL PROTECTED] wrote: On 8/22/06, Guillaume Nodet [EMAIL PROTECTED] wrote: I recently experienced some problems [1] when building Geronimo 1.1 plugins using the car-maven-plugin. I think a solution may be to build the maven plugin locally from 1.1 sources and build Geronimo 1.1 then. It seems you've been trying to run the build online and thus all the deps (the maven plugin including) is pulled down too. For it's an incompatible version, the build blows up. Just a wild guess, but may be of help. Report back! ;-) Jacek -- Jacek Laskowski http://www.laskowski.net.pl -- Cheers, Guillaume Nodet -- Cheers, Guillaume Nodet -- Cheers, Guillaume Nodet -- Cheers, Guillaume Nodet
Re: Exceptions in servicemix-jms with WebSphereMQ
Sorry to bother you again, but I still get build errors. Do you have any advice what to do? Is there perhaps a profile to exclude the geronimo stuff - I am currently not interested into that. Klaus. [INFO] [INFO] Building ServiceMix :: Geronimo :: ServiceMix plugin [INFO]task-segment: [install] [INFO] [INFO] [resources:resources] [INFO] Using default encoding to copy filtered resources. [INFO] [car:prepare-plan] [INFO] Generated: /home/alfert/src/service-mix/svn-trunk/trunk/geronimo/servicemix/target/plan/plan.xml [INFO] [car:package] [INFO] Packaging module configuration: /home/alfert/src/service-mix/svn-trunk/trunk/geronimo/servicemix/target/plan/plan.xml [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Invalid deployment descriptor: [/home/alfert/src/service-mix/svn-trunk/trunk/geronimo/servicemix/target/plan/plan.xml:18: error: cvc-complex-type.2.4a: Expected element '[EMAIL PROTECTED]://geronimo.apache.org/xml/ns/deployment-1.1' instead of '[EMAIL PROTECTED]://geronimo.apache.org/xml/ns/deployment-1.2' here in element [EMAIL PROTECTED]://geronimo.apache.org/xml/ns/deployment-1.1, /home/alfert/src/service-mix/svn-trunk/trunk/geronimo/servicemix/target/plan/plan.xml:184: error: cvc-complex-type.2.4a: Expected element '[EMAIL PROTECTED]://geronimo.apache.org/xml/ns/deployment-1.1' instead of '[EMAIL PROTECTED]://geronimo.apache.org/xml/ns/deployment-1.1' here in element [EMAIL PROTECTED]://geronimo.apache.org/xml/ns/deployment-1.1, /home/alfert/src/service-mix/svn-trunk/trunk/geronimo/servicemix/target/plan/plan.xml:189: error: cvc-complex-type.2.4a: Expected element '[EMAIL PROTECTED]://geronimo.apache.org/xml/ns/deployment-1.1' instead of '[EMAIL PROTECTED]://geronimo.apache.org/xml/ns/deployment-1.1' here in element [EMAIL PROTECTED]://geronimo.apache.org/xml/ns/deployment-1.1, /home/alfert/src/service-mix/svn-trunk/trunk/geronimo/servicemix/target/plan/plan.xml:203: error: cvc-complex-type.2.4a: Expected element '[EMAIL PROTECTED]://geronimo.apache.org/xml/ns/deployment-1.1' instead of '[EMAIL PROTECTED]://geronimo.apache.org/xml/ns/deployment-1.1' here in element [EMAIL PROTECTED]://geronimo.apache.org/xml/ns/deployment-1.1, /home/alfert/src/service-mix/svn-trunk/trunk/geronimo/servicemix/target/plan/plan.xml:210: error: cvc-complex-type.2.4c: Expected element '[EMAIL PROTECTED]://geronimo.apache.org/xml/ns/deployment-1.1' before the end of the content in element [EMAIL PROTECTED]://geronimo.apache.org/xml/ns/deployment-1.1] gnodet wrote: Oops, sorry. This is fixed. On 8/22/06, Klaus Alfert [EMAIL PROTECTED] wrote: Hi Guillaume, after an svn update (to revision 433641), I got a compile error. Is there some checking pending? Compiling 24 source files to /home/alfert/src/service-mix/svn-trunk/trunk/servicemix-jms/target/classes [INFO] [ERROR] BUILD FAILURE [INFO] [INFO] Compilation failure /home/alfert/src/service-mix/svn-trunk/trunk/servicemix-jms/src/main/java/org/apache/servicemix/jms/AbstractJmsProcessor.java:[174,25] createContext(org.apache.servicemix.soap.marshalers.SoapMessage) in org.apache.servicemix.soap.SoapHelper cannot be applied to () Klaus. gnodet wrote: I have just fixed that. You can now add the needJavaIdentifiers=true attribute so that all non valid properties will be skipped. Note that the Content-Type property has been renamed to MimeContentType so that mime streams can still be sent. [..] -- Cheers, Guillaume Nodet -- View this message in context: http://www.nabble.com/Exceptions-in-servicemix-jms-with-WebSphereMQ-tf2141329.html#a5926623 Sent from the ServiceMix - Dev forum at Nabble.com. -- Cheers, Guillaume Nodet -- View this message in context: http://www.nabble.com/Exceptions-in-servicemix-jms-with-WebSphereMQ-tf2141329.html#a5927221 Sent from the ServiceMix - Dev forum at Nabble.com.
Re: Exceptions in servicemix-jms with WebSphereMQ
I' m trying to fix this problem. If will disable geronimo module until the plugin works again. On 8/22/06, Klaus Alfert [EMAIL PROTECTED] wrote: Sorry to bother you again, but I still get build errors. Do you have any advice what to do? Is there perhaps a profile to exclude the geronimo stuff - I am currently not interested into that. Klaus. [INFO] [INFO] Building ServiceMix :: Geronimo :: ServiceMix plugin [INFO]task-segment: [install] [INFO] [INFO] [resources:resources] [INFO] Using default encoding to copy filtered resources. [INFO] [car:prepare-plan] [INFO] Generated: /home/alfert/src/service-mix/svn-trunk/trunk/geronimo/servicemix/target/plan/plan.xml [INFO] [car:package] [INFO] Packaging module configuration: /home/alfert/src/service-mix/svn-trunk/trunk/geronimo/servicemix/target/plan/plan.xml [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Invalid deployment descriptor: [/home/alfert/src/service-mix/svn-trunk/trunk/geronimo/servicemix/target/plan/plan.xml:18: error: cvc-complex-type.2.4a: Expected element '[EMAIL PROTECTED]://geronimo.apache.org/xml/ns/deployment-1.1' instead of '[EMAIL PROTECTED]://geronimo.apache.org/xml/ns/deployment-1.2' here in element [EMAIL PROTECTED]://geronimo.apache.org/xml/ns/deployment-1.1, /home/alfert/src/service-mix/svn-trunk/trunk/geronimo/servicemix/target/plan/plan.xml:184: error: cvc-complex-type.2.4a: Expected element '[EMAIL PROTECTED]://geronimo.apache.org/xml/ns/deployment-1.1' instead of '[EMAIL PROTECTED]://geronimo.apache.org/xml/ns/deployment-1.1' here in element [EMAIL PROTECTED]://geronimo.apache.org/xml/ns/deployment-1.1, /home/alfert/src/service-mix/svn-trunk/trunk/geronimo/servicemix/target/plan/plan.xml:189: error: cvc-complex-type.2.4a: Expected element '[EMAIL PROTECTED]://geronimo.apache.org/xml/ns/deployment-1.1' instead of '[EMAIL PROTECTED]://geronimo.apache.org/xml/ns/deployment-1.1' here in element [EMAIL PROTECTED]://geronimo.apache.org/xml/ns/deployment-1.1, /home/alfert/src/service-mix/svn-trunk/trunk/geronimo/servicemix/target/plan/plan.xml:203: error: cvc-complex-type.2.4a: Expected element '[EMAIL PROTECTED]://geronimo.apache.org/xml/ns/deployment-1.1' instead of '[EMAIL PROTECTED]://geronimo.apache.org/xml/ns/deployment-1.1' here in element [EMAIL PROTECTED]://geronimo.apache.org/xml/ns/deployment-1.1, /home/alfert/src/service-mix/svn-trunk/trunk/geronimo/servicemix/target/plan/plan.xml:210: error: cvc-complex-type.2.4c: Expected element '[EMAIL PROTECTED]://geronimo.apache.org/xml/ns/deployment-1.1' before the end of the content in element [EMAIL PROTECTED]://geronimo.apache.org/xml/ns/deployment-1.1] gnodet wrote: Oops, sorry. This is fixed. On 8/22/06, Klaus Alfert [EMAIL PROTECTED] wrote: Hi Guillaume, after an svn update (to revision 433641), I got a compile error. Is there some checking pending? Compiling 24 source files to /home/alfert/src/service-mix/svn-trunk/trunk/servicemix-jms/target/classes [INFO] [ERROR] BUILD FAILURE [INFO] [INFO] Compilation failure /home/alfert/src/service-mix/svn-trunk/trunk/servicemix-jms/src/main/java/org/apache/servicemix/jms/AbstractJmsProcessor.java:[174,25] createContext(org.apache.servicemix.soap.marshalers.SoapMessage) in org.apache.servicemix.soap.SoapHelper cannot be applied to () Klaus. gnodet wrote: I have just fixed that. You can now add the needJavaIdentifiers=true attribute so that all non valid properties will be skipped. Note that the Content-Type property has been renamed to MimeContentType so that mime streams can still be sent. [..] -- Cheers, Guillaume Nodet -- View this message in context: http://www.nabble.com/Exceptions-in-servicemix-jms-with-WebSphereMQ-tf2141329.html#a5926623 Sent from the ServiceMix - Dev forum at Nabble.com. -- Cheers, Guillaume Nodet -- View this message in context: http://www.nabble.com/Exceptions-in-servicemix-jms-with-WebSphereMQ-tf2141329.html#a5927221 Sent from the ServiceMix - Dev forum at Nabble.com. -- Cheers, Guillaume Nodet
Re: Car plugin
I will start a new discussion thread about that.On 8/22/06, Aaron Mulder [EMAIL PROTECTED] wrote:Ah, I see -- it's that the plugin plan writing causes problems. In any case, I agree that it would be nice to have a dedicated G 1.1version of the car-maven-plugin.Thanks,AaronOn 8/22/06, Guillaume Nodet [EMAIL PROTECTED] wrote: On 8/22/06, Aaron Mulder [EMAIL PROTECTED] wrote: On 8/22/06, Guillaume Nodet [EMAIL PROTECTED] wrote:I think any problem with the deployer can be avoided by specifying thecorrect set of dependencies and configuration info in the project POM (to force it to use only 1.1 JARs/CARs and the 1.1 deployer GBean).But if any of the kernel/system interfaces changed, that wouldprobably stop working. Actually, that' s the main problem. I'm not convinced.If I understand this correctly, you got a problem when the G 1.2 service builder attempted to do something with a G 1.1 deployment plan.I think you can avoid the 1.2 service builder being invoked by listing all the 1.1 dependencies explicitly.Is that not what's going on? The problem is very simple.That processed plan begins with module xmlns=http://geronimo.apache.org/xml/ns/deployment-1.1environment xmlns= http://geronimo.apache.org/xml/ns/deployment-1.2 which is rejected when deployed on G 1.1. Btw, it really sounds weird that the plugin process the environment tag, but not the module tag... My fix is to allow specifying the target geronimo version, so that the plugin will build the namespace uri dynamically: URI_PREFIX + 1.2. This works. What I meant, is that I' m not convinced that the API will never change and that a single plugin will be able to handle all versions in the future. This is already the case for the schema which are upgraded by default, even if no change happen (I do not argue against that, just stating the fact).But if something change, the plugin will need to cope with the difference. Is that what we want ? Also, I think it would be good to be able to release the plugin without having to wait for G 1.2 final, so that users can build G 1.1 plugins easily. Thanks, Aaron Adding a property to specify the target geronimo version seems to do the trick. So i can now have: module xmlns= http://geronimo.apache.org/xml/ns/deployment-1.1 environment instead of module xmlns=http://geronimo.apache.org/xml/ns/deployment-1.1 environment xmlns= http://geronimo.apache.org/xml/ns/ deployment-1.2 Btw, I' m wondering why the PlanProcessorMojo only overrides the environmnet tag, and not the module one.On 8/22/06, Jacek Laskowski [EMAIL PROTECTED] wrote: On 8/22/06, Guillaume Nodet [EMAIL PROTECTED] wrote: I recently experienced some problems [1] when building Geronimo 1.1plugins usingthe car-maven-plugin. I think a solution may be to build the maven plugin locally from 1.1 sources and build Geronimo 1.1 then. It seems you've been trying to run the build online and thus all the deps (the maven plugin including) is pulled down too. For it's an incompatible version, the build blows up. Just a wild guess, but may be of help. Report back! ;-) Jacek -- Jacek Laskowski http://www.laskowski.net.pl -- Cheers, Guillaume Nodet -- Cheers, Guillaume Nodet -- Cheers, Guillaume Nodet-- Cheers, Guillaume Nodet -- Cheers,Guillaume Nodet
[PROPOSAL] Car maven plugin dedicated to G 1.1
The car-maven-plugin is used as part of the geronimo build in G 1.2.This plugin is also very usefull to build Geronimo plugins targeted to G 1.1,but has recently changed in a *slight* incompatible way.However, I think that: * it may be difficult in the future to ensure that a single maven plugin will be able to create car files for all past and future version of Geronimo * G 1.1 is out and a minor release is about to go. I think that it will benefit users to be able to write Geronimo 1.1 plugins wihtout relying on a snapshot plugin.Hence, I propose that the plugin be forked to a new location, /devtools/maven-plugin/geronimo-1.x/car-maven-plugin (any better idea ?)and that we release this plugin at the same time that the 1.1.1 is out.Thoughts ?-- Cheers,Guillaume Nodet
[jira] Commented: (DAYTRADER-10) Update the import statements of Quote.java and QuoteHome.java
[ http://issues.apache.org/jira/browse/DAYTRADER-10?page=comments#action_12429737 ] Matt Hogstrom commented on DAYTRADER-10: Thanks Slava...applied Sending trunk/modules/ejb/src/main/java/org/apache/geronimo/samples/daytrader/ejb/Quote.java Sending trunk/modules/ejb/src/main/java/org/apache/geronimo/samples/daytrader/ejb/QuoteHome.java Transmitting file data .. Committed revision 433666. Update the import statements of Quote.java and QuoteHome.java - Key: DAYTRADER-10 URL: http://issues.apache.org/jira/browse/DAYTRADER-10 Project: DayTrader Issue Type: Improvement Components: EJB Tier Affects Versions: 1.2 Environment: All Reporter: Slava Priority: Minor Fix For: 1.2 Attachments: FixForDaytrader-10.patch Java 5 EE introduces a new javax.ejb.Remote interface. Currently Daytrader EJBs Quote.java and QuoteHome.java import Java packages with wild cards. For example: import javax.ejb.*; import java.math.BigDecimal; import com.ibm.websphere.samples.trade.*; import java.rmi.*; Prior to Java 5 EE there was only one Remote interface (java.rmi.Remote). Therefore it is clear that Quote.java and QuoteHome.java extend the java.rmi.Remote interface. When we start to support Java 5EE however, there will be two Remote interfaces (java.rmi.Remote and javax.ejb.Remote. That will cause confusion for the java compiler during the ejbdeploy. The solution is really simple: to provide the full interface name/path during imports. I know that this is not a problem for Daytrader yet but it will become. So lets be proactive, fix the imports now and avoid the problem in the future. I am providing a fix for this issue. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Assigned: (DAYTRADER-10) Update the import statements of Quote.java and QuoteHome.java
[ http://issues.apache.org/jira/browse/DAYTRADER-10?page=all ] Matt Hogstrom reassigned DAYTRADER-10: -- Assignee: Matt Hogstrom Update the import statements of Quote.java and QuoteHome.java - Key: DAYTRADER-10 URL: http://issues.apache.org/jira/browse/DAYTRADER-10 Project: DayTrader Issue Type: Improvement Components: EJB Tier Affects Versions: 1.2 Environment: All Reporter: Slava Assigned To: Matt Hogstrom Priority: Minor Fix For: 1.2 Attachments: FixForDaytrader-10.patch Java 5 EE introduces a new javax.ejb.Remote interface. Currently Daytrader EJBs Quote.java and QuoteHome.java import Java packages with wild cards. For example: import javax.ejb.*; import java.math.BigDecimal; import com.ibm.websphere.samples.trade.*; import java.rmi.*; Prior to Java 5 EE there was only one Remote interface (java.rmi.Remote). Therefore it is clear that Quote.java and QuoteHome.java extend the java.rmi.Remote interface. When we start to support Java 5EE however, there will be two Remote interfaces (java.rmi.Remote and javax.ejb.Remote. That will cause confusion for the java compiler during the ejbdeploy. The solution is really simple: to provide the full interface name/path during imports. I know that this is not a problem for Daytrader yet but it will become. So lets be proactive, fix the imports now and avoid the problem in the future. I am providing a fix for this issue. -- 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] Closed: (DAYTRADER-10) Update the import statements of Quote.java and QuoteHome.java
[ http://issues.apache.org/jira/browse/DAYTRADER-10?page=all ] Matt Hogstrom closed DAYTRADER-10. -- Fix Version/s: 1.2 Resolution: Fixed Update the import statements of Quote.java and QuoteHome.java - Key: DAYTRADER-10 URL: http://issues.apache.org/jira/browse/DAYTRADER-10 Project: DayTrader Issue Type: Improvement Components: EJB Tier Affects Versions: 1.2 Environment: All Reporter: Slava Assigned To: Matt Hogstrom Priority: Minor Fix For: 1.2 Attachments: FixForDaytrader-10.patch Java 5 EE introduces a new javax.ejb.Remote interface. Currently Daytrader EJBs Quote.java and QuoteHome.java import Java packages with wild cards. For example: import javax.ejb.*; import java.math.BigDecimal; import com.ibm.websphere.samples.trade.*; import java.rmi.*; Prior to Java 5 EE there was only one Remote interface (java.rmi.Remote). Therefore it is clear that Quote.java and QuoteHome.java extend the java.rmi.Remote interface. When we start to support Java 5EE however, there will be two Remote interfaces (java.rmi.Remote and javax.ejb.Remote. That will cause confusion for the java compiler during the ejbdeploy. The solution is really simple: to provide the full interface name/path during imports. I know that this is not a problem for Daytrader yet but it will become. So lets be proactive, fix the imports now and avoid the problem in the future. I am providing a fix for this issue. -- 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: XBean site using new G-theme
You may not like them but they do own the browser market. We need to make Geronimo so popular that as developers use G to produce cool new apps and push the edge that they have to follow us :) Jason Dillon wrote: #^$% I hate IE. Anyways, looks like the URL gets rendered as when you are on the page... which is bunk too. Silly AutoExport trying to be smart and ends up being really dumb. Thanks for pointing this out... will see what I can do about that... Also IE wrecks the justification for the sidenav... so stupid. --jason On Aug 21, 2006, at 2:13 PM, Joe Bohn wrote: Jason Dillon wrote: On Aug 21, 2006, at 1:54 PM, Joe Bohn wrote: I noticed a peculiar thing with the links at the top right of the banner. It seems like clicking on a link like Source functions as a toggle ... such that if you click it again once there it will take you back to the home page. This is also true of Download and Mailing Lists. I do not see this... what browser? They are just plain a href= links... I did not need to clear my browser cache to keep from getting the old site pages... but after that I can click the Source link all day and night and it will bring me to: http://geronimo.apache.org/xbean/source.html You're favorite ... IE ;-)I didn't think to check other browsers .. but after reading your response I tried firefox it worked as it should. Some more IE oddities I guess. Also, clicking on JavaDocs takes me out of the theme completely and doesn't really show javadoc. I did not alter the links, I just ported from the previous site. --jason
Re: [PROPOSAL] Car maven plugin dedicated to G 1.1
I think this would be great. We could change the forked version to build against G 1.1 (or later perhaps 1.1.1) JARs to ensure compatibility. Thanks, Aaron On 8/22/06, Guillaume Nodet [EMAIL PROTECTED] wrote: The car-maven-plugin is used as part of the geronimo build in G 1.2. This plugin is also very usefull to build Geronimo plugins targeted to G 1.1, but has recently changed in a *slight* incompatible way. However, I think that: * it may be difficult in the future to ensure that a single maven plugin will be able to create car files for all past and future version of Geronimo * G 1.1 is out and a minor release is about to go. I think that it will benefit users to be able to write Geronimo 1.1 plugins wihtout relying on a snapshot plugin. Hence, I propose that the plugin be forked to a new location, /devtools/maven-plugin/geronimo-1.x/car-maven-plugin (any better idea ?) and that we release this plugin at the same time that the 1.1.1 is out. Thoughts ? -- Cheers, Guillaume Nodet
DeployServiceAssemblyTask Problem!!!
Hi, I'm trying deploy a SA to a remote machine using the DeployServiceAssemblyTask ant task. However I got the following error on the server: 2006-08-21 11:49:23 ERROR - Error deploying service assembly java.lang.Exception: ?xml version=1.0 encoding=UTF-8? jbi-task xmlns=http://java.sun.com/xml/ns/jbi/management-message; version=1.0 jbi-task-result frmwk-task-result frmwk-task-result-details task-result-details task-iddeploy/task-id task-resultFAILED/task-result message-typeERROR/message-type task-status-msg msg-loc-info loc-token/ loc-messageUnable to unpack archive: c:\opt\sfc\kronos-engine\local\kronos-engine-sa.zip/loc-message /msg-loc-info /task-status-msg exception-info nesting-level1/nesting-level loc-token/ loc-messagejava.net.MalformedURLException: unknown protocol: c/loc-message stack-trace![CDATA[javax.jbi.management.DeploymentException: java.net.MalformedURLException: unknown protocol: c at org.apache.servicemix.jbi.framework.AutoDeploymentService.unpackLocation(AutoDeploymentService.java:442) at org.apache.servicemix.jbi.framework.DeploymentService.deploy(DeploymentService.java:181) at org.apache.servicemix.jbi.framework.AdminCommandsService.deployServiceAssembly(AdminCommandsService.java:175) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) at java.lang.reflect.Method.invoke(Unknown Source) at org.apache.commons.beanutils.MethodUtils.invokeMethod(MethodUtils.java:216) at org.apache.servicemix.jbi.management.BaseStandardMBean.invoke(BaseStandardMBean.java:315) at com.sun.jmx.mbeanserver.DynamicMetaDataImpl.invoke(Unknown Source) at com.sun.jmx.mbeanserver.MetaDataImpl.invoke(Unknown Source) at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(Unknown Source) at com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(Unknown Source) at javax.management.remote.rmi.RMIConnectionImpl.doOperation(Unknown Source) at javax.management.remote.rmi.RMIConnectionImpl.access$100(Unknown Source) at javax.management.remote.rmi.RMIConnectionImpl$PrivilegedOperation.run(Unknown Source) at javax.management.remote.rmi.RMIConnectionImpl.doPrivilegedOperation(Unknown Source) at javax.management.remote.rmi.RMIConnectionImpl.invoke(Unknown Source) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) at java.lang.reflect.Method.invoke(Unknown Source) at sun.rmi.server.UnicastServerRef.dispatch(Unknown Source) at sun.rmi.transport.Transport$1.run(Unknown Source) at java.security.AccessController.doPrivileged(Native Method) at sun.rmi.transport.Transport.serviceCall(Unknown Source) at sun.rmi.transport.tcp.TCPTransport.handleMessages(Unknown Source) at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(Unknown Source) at java.lang.Thread.run(Unknown Source) Caused by: java.net.MalformedURLException: unknown protocol: c at java.net.URL.init(Unknown Source) at java.net.URL.init(Unknown Source) at java.net.URL.init(Unknown Source) at org.apache.servicemix.jbi.framework.AutoDeploymentService.unpackLocation(AutoDeploymentService.java:435) ... 28 more ]]/stack-trace /exception-info /task-result-details /frmwk-task-result-details /frmwk-task-result /jbi-task-result /jbi-task at org.apache.servicemix.jbi.framework.ManagementSupport.failure(ManagementSupport.java:120) at org.apache.servicemix.jbi.framework.ManagementSupport.failure(ManagementSupport.java:110) at org.apache.servicemix.jbi.framework.DeploymentService.deploy(DeploymentService.java:183) at org.apache.servicemix.jbi.framework.AdminCommandsService.deployServiceAssembly(AdminCommandsService.java:175) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) at java.lang.reflect.Method.invoke(Unknown Source) at org.apache.commons.beanutils.MethodUtils.invokeMethod(MethodUtils.java:216) at org.apache.servicemix.jbi.management.BaseStandardMBean.invoke(BaseStandardMBean.java:315) at com.sun.jmx.mbeanserver.DynamicMetaDataImpl.invoke(Unknown Source) at com.sun.jmx.mbeanserver.MetaDataImpl.invoke(Unknown Source) at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(Unknown Source) at com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(Unknown Source) at javax.management.remote.rmi.RMIConnectionImpl.doOperation(Unknown Source) at
[jira] Commented: (GERONIMODEVTOOLS-103) not able to get geronimo plan editor recognize openejb-jar.xml or geronimo-application.xml
[ http://issues.apache.org/jira/browse/GERONIMODEVTOOLS-103?page=comments#action_12429742 ] Lin Sun commented on GERONIMODEVTOOLS-103: -- After further investigation, the problem lies in that not able to get geronimo plan editor recognize openejb-jar.xml or geronimo-application.xml -- Key: GERONIMODEVTOOLS-103 URL: http://issues.apache.org/jira/browse/GERONIMODEVTOOLS-103 Project: Geronimo-Devtools Issue Type: Bug Affects Versions: 1.1.0 Environment: Eclipse 3.2 and WTP 1.5 windows XP Reporter: Lin Sun I still have similar prob. The MDB openejb-jar.xml plan actually contains the fully qualified tags but it cannot be opened with the geornimo plan editor. Similar with a new openejb-jar.xml file created by default using the create new ejb project wizard. Is this also some code missed from 1.0? This was working in 1.0 from what I remember. -- 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: (GERONIMODEVTOOLS-103) not able to get geronimo plan editor recognize openejb-jar.xml or geronimo-application.xml
[ http://issues.apache.org/jira/browse/GERONIMODEVTOOLS-103?page=comments#action_12429744 ] Lin Sun commented on GERONIMODEVTOOLS-103: -- Sorry I hit enter by accident earlier. The problem lies in that deployment being null when fei.getFile() is a plan other than geronimo-web.xml, in the following code in AbstractGeronimoDeploymentPlanEditor. deploymentPlan = loadDeploymentPlan(fei.getFile()); I will supply a patch shortly. not able to get geronimo plan editor recognize openejb-jar.xml or geronimo-application.xml -- Key: GERONIMODEVTOOLS-103 URL: http://issues.apache.org/jira/browse/GERONIMODEVTOOLS-103 Project: Geronimo-Devtools Issue Type: Bug Affects Versions: 1.1.0 Environment: Eclipse 3.2 and WTP 1.5 windows XP Reporter: Lin Sun I still have similar prob. The MDB openejb-jar.xml plan actually contains the fully qualified tags but it cannot be opened with the geornimo plan editor. Similar with a new openejb-jar.xml file created by default using the create new ejb project wizard. Is this also some code missed from 1.0? This was working in 1.0 from what I remember. -- 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: DeployServiceAssemblyTask Problem!!!
This has already been fixed. Try using a snapshot version. On 8/22/06, leiolay [EMAIL PROTECTED] wrote: Hi, I'm trying deploy a SA to a remote machine using the DeployServiceAssemblyTask ant task. However I got the following error on the server: 2006-08-21 11:49:23 ERROR - Error deploying service assembly java.lang.Exception: ?xml version=1.0 encoding=UTF-8? jbi-task xmlns=http://java.sun.com/xml/ns/jbi/management-message; version=1.0 jbi-task-result frmwk-task-result frmwk-task-result-details task-result-details task-iddeploy/task-id task-resultFAILED/task-result message-typeERROR/message-type task-status-msg msg-loc-info loc-token/ loc-messageUnable to unpack archive: c:\opt\sfc\kronos-engine\local\kronos-engine-sa.zip/loc-message /msg-loc-info /task-status-msg exception-info nesting-level1/nesting-level loc-token/ loc-messagejava.net.MalformedURLException: unknown protocol: c/loc-message stack-trace![CDATA[javax.jbi.management.DeploymentException: java.net.MalformedURLException: unknown protocol: c at org.apache.servicemix.jbi.framework.AutoDeploymentService.unpackLocation( AutoDeploymentService.java:442) at org.apache.servicemix.jbi.framework.DeploymentService.deploy( DeploymentService.java:181) at org.apache.servicemix.jbi.framework.AdminCommandsService.deployServiceAssembly (AdminCommandsService.java:175) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) at java.lang.reflect.Method.invoke(Unknown Source) at org.apache.commons.beanutils.MethodUtils.invokeMethod(MethodUtils.java :216) at org.apache.servicemix.jbi.management.BaseStandardMBean.invoke( BaseStandardMBean.java:315) at com.sun.jmx.mbeanserver.DynamicMetaDataImpl.invoke(Unknown Source) at com.sun.jmx.mbeanserver.MetaDataImpl.invoke(Unknown Source) at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(Unknown Source) at com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(Unknown Source) at javax.management.remote.rmi.RMIConnectionImpl.doOperation (Unknown Source) at javax.management.remote.rmi.RMIConnectionImpl.access$100 (Unknown Source) at javax.management.remote.rmi.RMIConnectionImpl$PrivilegedOperation.run (Unknown Source) at javax.management.remote.rmi.RMIConnectionImpl.doPrivilegedOperation (Unknown Source) at javax.management.remote.rmi.RMIConnectionImpl.invoke(Unknown Source) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) at java.lang.reflect.Method.invoke(Unknown Source) at sun.rmi.server.UnicastServerRef.dispatch(Unknown Source) at sun.rmi.transport.Transport$1.run(Unknown Source) at java.security.AccessController.doPrivileged(Native Method) at sun.rmi.transport.Transport.serviceCall(Unknown Source) at sun.rmi.transport.tcp.TCPTransport.handleMessages(Unknown Source) at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run (Unknown Source) at java.lang.Thread.run(Unknown Source) Caused by: java.net.MalformedURLException: unknown protocol: c at java.net.URL.init(Unknown Source) at java.net.URL.init(Unknown Source) at java.net.URL.init(Unknown Source) at org.apache.servicemix.jbi.framework.AutoDeploymentService.unpackLocation( AutoDeploymentService.java:435) ... 28 more ]]/stack-trace /exception-info /task-result-details /frmwk-task-result-details /frmwk-task-result /jbi-task-result /jbi-task at org.apache.servicemix.jbi.framework.ManagementSupport.failure( ManagementSupport.java:120) at org.apache.servicemix.jbi.framework.ManagementSupport.failure( ManagementSupport.java:110) at org.apache.servicemix.jbi.framework.DeploymentService.deploy( DeploymentService.java:183) at org.apache.servicemix.jbi.framework.AdminCommandsService.deployServiceAssembly (AdminCommandsService.java:175) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) at java.lang.reflect.Method.invoke(Unknown Source) at org.apache.commons.beanutils.MethodUtils.invokeMethod(MethodUtils.java :216) at org.apache.servicemix.jbi.management.BaseStandardMBean.invoke( BaseStandardMBean.java:315) at com.sun.jmx.mbeanserver.DynamicMetaDataImpl.invoke(Unknown Source) at com.sun.jmx.mbeanserver.MetaDataImpl.invoke(Unknown Source) at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(Unknown Source) at com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(Unknown
[jira] Updated: (GERONIMODEVTOOLS-103) not able to get geronimo plan editor recognize openejb-jar.xml or geronimo-application.xml
[ http://issues.apache.org/jira/browse/GERONIMODEVTOOLS-103?page=all ] Lin Sun updated GERONIMODEVTOOLS-103: - Attachment: devtools103.patch With the fix, I am able to open my mdb's openejb-jar.xml using the geronimo deployment plan editor. I am also able to open the newly created geornimo-application.xml and connector plan using the geronimo deployment plan editor. i tested with both 1.0 and 1.1 server. However, I am still not able to deploy my mdb jar file which I suspect is a WTP 1.5 prob. Whenever I right click on the project and do a run-run on server, I got a popup panel saying No launchable artifact could be found in the selection. I think I will open a eclipse wtp bugzilla on this unless Sachin feels differently. Lin not able to get geronimo plan editor recognize openejb-jar.xml or geronimo-application.xml -- Key: GERONIMODEVTOOLS-103 URL: http://issues.apache.org/jira/browse/GERONIMODEVTOOLS-103 Project: Geronimo-Devtools Issue Type: Bug Affects Versions: 1.1.0 Environment: Eclipse 3.2 and WTP 1.5 windows XP Reporter: Lin Sun Attachments: devtools103.patch I still have similar prob. The MDB openejb-jar.xml plan actually contains the fully qualified tags but it cannot be opened with the geornimo plan editor. Similar with a new openejb-jar.xml file created by default using the create new ejb project wizard. Is this also some code missed from 1.0? This was working in 1.0 from what I remember. -- 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: Where is the source code for the G samples ?
+1 from me. Now we can jar up their classes too. Cheers Prasad On 8/21/06, David Jencks [EMAIL PROTECTED] wrote: +1 to committing it from me thanks david jencks On Aug 21, 2006, at 6:47 PM, Jason Dillon wrote: Anyone object if I commit this to trunk? Its been siting in my workspace for a few days, no comments so far... I think it is important that we have control over these artifacts we include. --jason On 8/20/06, Jason Dillon [EMAIL PROTECTED] wrote: I've got new war's and car's in my workspace. How can I verify that they work like the geronimo-samples:* versions? --jason On Aug 16, 2006, at 7:41 AM, Aaron Mulder wrote: On 8/16/06, Matt Hogstrom [EMAIL PROTECTED] wrote: I think they were removed from Geronimo as part of the plugins work. Aaron provides the samples as plugins now. Perhaps we need to have them in G as well due to the issues you are tracking. I think it made sense to move them previously but sounds like there are reasons to keep them in both places. Nope. I just took them out of the assemblies. I didn't change the way that they were built, other than to add the geronimo- plugin.xml to the various config/ modules. I've never seen the source for these examples. Didn't the JARs just pop off of Zeus' leg or something? Thanks, Aaron Prasad Kashyap wrote: Does anybody know where I can find the source code for the geronimo samples, jsp-examples and tomcat-examples ? We are using these in our builds from this repository http://people.apache.org/repo/m1-snapshot-repository/geronimo- samples/wars/ We should archive the classes dirs in these wars just like we do to the apps in our build. When these examples wars are used in our build as is, there is a good possibility that it might hit the long path limit on windows. Cheers Prasad
[jira] Updated: (SM-536) The defaultMep is a mandatory attribute on consumer endpoints and should be checked
[ https://issues.apache.org/activemq/browse/SM-536?page=all ] Grant McDonald updated SM-536: -- Patch Info: [Patch Available] added patch The defaultMep is a mandatory attribute on consumer endpoints and should be checked --- Key: SM-536 URL: https://issues.apache.org/activemq/browse/SM-536 Project: ServiceMix Issue Type: Bug Components: servicemix-http, servicemix-jms Reporter: Guillaume Nodet Assigned To: Grant McDonald Fix For: 3.0 Attachments: SM-536.patch -- 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-536) The defaultMep is a mandatory attribute on consumer endpoints and should be checked
[ https://issues.apache.org/activemq/browse/SM-536?page=all ] Grant McDonald updated SM-536: -- Attachment: SM-536.patch Patch reorganises validations from HttpXBeanDeployer into HttpEndpoint and adds the validation on defaultMep for consumer endpoints into the SoapEndpoint. The defaultMep is a mandatory attribute on consumer endpoints and should be checked --- Key: SM-536 URL: https://issues.apache.org/activemq/browse/SM-536 Project: ServiceMix Issue Type: Bug Components: servicemix-http, servicemix-jms Reporter: Guillaume Nodet Assigned To: Grant McDonald Fix For: 3.0 Attachments: SM-536.patch -- 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] Work started: (SM-536) The defaultMep is a mandatory attribute on consumer endpoints and should be checked
[ https://issues.apache.org/activemq/browse/SM-536?page=all ] Work on SM-536 started by Grant McDonald. The defaultMep is a mandatory attribute on consumer endpoints and should be checked --- Key: SM-536 URL: https://issues.apache.org/activemq/browse/SM-536 Project: ServiceMix Issue Type: Bug Components: servicemix-http, servicemix-jms Reporter: Guillaume Nodet Assigned To: Grant McDonald Fix For: 3.0 Attachments: SM-536.patch -- 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: Exceptions in servicemix-jms with WebSphereMQ
Thanx for you quick answer, it helped a lot. But I am still tumbling from exception to exception. Now, MQ chokes on the send-call :-( [junit] 26441 [Thread-0] INFO smix.console - javax.jms.JMSException: MQJMS1013: operation invalid whilst session is using asynchronous delivery [junit] 26441 [Thread-0] INFO smix.console - at com.ibm.mq.jms.services.ConfigEnvironment.newException(ConfigEnvironment.java:567) [junit] 26441 [Thread-0] INFO smix.console - at com.ibm.mq.jms.MQMessageProducer.send(MQMessageProducer.java:1051) [junit] 26441 [Thread-0] INFO smix.console - at com.ibm.mq.jms.MQMessageProducer.send(MQMessageProducer.java:1108) [junit] 26441 [Thread-0] INFO smix.console - at org.apache.servicemix.jms.multiplexing.MultiplexingProviderProcessor.process(MultiplexingProviderProcessor.java:164) [junit] 26442 [Thread-0] INFO smix.console - at org.apache.servicemix.common.AsyncBaseLifeCycle.processExchange(AsyncBaseLifeCycle.java:399) [junit] 26442 [Thread-0] INFO smix.console - at org.apache.servicemix.common.BaseLifeCycle.onMessageExchange(BaseLifeCycle.java:43) [junit] 26442 [Thread-0] INFO smix.console - at org.apache.servicemix.jbi.messaging.DeliveryChannelImpl.processInBound(DeliveryChannelImpl.java:623) [junit] 26442 [Thread-0] INFO smix.console - at org.apache.servicemix.jbi.nmr.flow.AbstractFlow.doRouting(AbstractFlow.java:169) [junit] 26442 [Thread-0] INFO smix.console - at org.apache.servicemix.jbi.nmr.flow.seda.SedaFlow.doRouting(SedaFlow.java:177) [junit] 26442 [Thread-0] INFO smix.console - at org.apache.servicemix.jbi.nmr.flow.seda.SedaQueue$1.run(SedaQueue.java:227) [junit] 26442 [Thread-0] INFO smix.console - at org.apache.geronimo.connector.work.WorkerContext.run(WorkerContext.java:291) [junit] 26442 [Thread-0] INFO smix.console - at EDU.oswego.cs.dl.util.concurrent.PooledExecutor$Worker.run(Unknown Source) [junit] 26442 [Thread-0] INFO smix.console - at java.lang.Thread.run(Thread.java:595) [j I'll take a look on it tomorrow. Klaus. gnodet wrote: I' m trying to fix this problem. If will disable geronimo module until the plugin works again. [..] -- Cheers, Guillaume Nodet -- View this message in context: http://www.nabble.com/Exceptions-in-servicemix-jms-with-WebSphereMQ-tf2141329.html#a5928806 Sent from the ServiceMix - Dev forum at Nabble.com.
[jira] Created: (GERONIMO-2344) Tomcat Console can't find TomcatManagerImpl class during display of ServerLogs
Tomcat Console can't find TomcatManagerImpl class during display of ServerLogs -- Key: GERONIMO-2344 URL: http://issues.apache.org/jira/browse/GERONIMO-2344 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Affects Versions: 1.2 Reporter: Bill Dudney Attachments: GERONIMO-2344.bdudney.patch Console classpath problems prevent the class from being found. Here are the error messages; 10:12:39,240 WARN [BasicProxyManager] Could not load interface org.apache.geronimo.tomcat.TomcatManagerImpl in provided ClassLoader for org.apache.geronimo.configs/tomcat/1.2-SNAPSHOT/car?ServiceModule=org.apache.geronimo.configs/tomcat/1.2-SNAPSHOT/car,j2eeType=GBean,name=TomcatWebManager 10:12:39,298 WARN [BasicProxyManager] Could not load interface org.apache.geronimo.tomcat.TomcatWebContainer in provided ClassLoader for org.apache.geronimo.configs/tomcat/1.2-SNAPSHOT/car?ServiceModule=org.apache.geronimo.configs/tomcat/1.2-SNAPSHOT/car,j2eeType=GBean,name=TomcatWebContainer 10:12:39,305 WARN [BasicProxyManager] Could not load interface org.apache.geronimo.tomcat.TomcatContainer in provided ClassLoader for org.apache.geronimo.configs/tomcat/1.2-SNAPSHOT/car?ServiceModule=org.apache.geronimo.configs/tomcat/1.2-SNAPSHOT/car,j2eeType=GBean,name=TomcatWebContainer The patch simply removes the scopeprovided/scope from the tomcat-deployer dependency. -- 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
