Re: Where to add new SSL BrokerService functionality
Conceptually you need both. -- the client needs a policy to say what kind of authentication it will offer. client cert is one choice. -- the server needs a policy to say what kind of client authentication it will accept. client certs are one choice. AFAICT these are your two options. I'll repeat that IMO you should expand the choices to match what's in corba csiv2. Otherwise you are apt to implement little bits and pieces in inconsistent and incompatible ways that will be very difficult to extend to a set of reasonable choices. thanks david jencks On Aug 10, 2006, at 10:38 PM, Hiram Chirino wrote: I would go with option 1 since SSL is transport layer option and does not really have anything to do with the core of the broker. On 8/10/06, Sepand M [EMAIL PROTECTED] wrote: Hi all, As some of you may know, I'm working on an SSL client certificate authorization system for ActiveMQ. I've gotten some of the basics done and am trying to create a way of ensuring that SSL client certificates are used. I see two options (and I strongly prefer the second one): 1. The client would add the proper option to the URI they bind to on the broker side (e.g URI=localhost:61616?needClientAuth=true). 2. Adding a method to the BrokerService that enables this functionality. Unless someone suggests something different, I'm choosing method 2. The problem is I can't decide if I should subclass the existing BrokerService or add the menthioned method to the existing BrokerService class. So far, BrokerService seems to be doing everything and it has no subclasses, but I'm wondering how much more can be crammed into it and if SSL functionality should be built into the general purpose broker. Any thoughts? Regards, Sepand -- Regards, Hiram Blog: http://hiramchirino.com
Re: Pulling consumer design
Sorry about that, I'd forgotten to run the mvn gram:gram command. Its now in SVN On 8/11/06, Vadim Pesochinsky [EMAIL PROTECTED] wrote: There is a little problem with MessagePullMarshaller not generated / added to svn. I tried to run generator, but withouth much luck. Found this instructions, but I could not find the maven-gram-plugin. Thanks. cd maven-gram-plugin/ mvn install cd ../activemq-openwire-generator/ mvn install cd ../activemq-core mvn gram:gram javax.jms.JMSException: Unknown data type: 20 at org.apache.activemq.util.JMSExceptionSupport.create(JMSExceptionSupport.java:58) at org.apache.activemq.ActiveMQConnection.asyncSendPacket(ActiveMQConnection.java:1130) at org.apache.activemq.ActiveMQSession.asyncSendPacket(ActiveMQSession.java:1649) at org.apache.activemq.ActiveMQMessageConsumer.sendPullCommand(ActiveMQMessageConsumer.java:605) at org.apache.activemq.ActiveMQMessageConsumer.receive(ActiveMQMessageConsumer.java:463) at com.barra.cp.common.io.SingleMessageMultiQueueReceiver$OneMessageAtATime.runSingleQueue(SingleMessageMultiQueueReceiver.java:185) at com.barra.cp.common.io.SingleMessageMultiQueueReceiver$OneMessageAtATime.doRun(SingleMessageMultiQueueReceiver.java:141) at com.barra.cp.common.io.SingleMessageMultiQueueReceiver$OneMessageAtATime.run(SingleMessageMultiQueueReceiver.java:124) at java.lang.Thread.run(Unknown Source) Caused by: java.io.IOException: Unknown data type: 20 at org.apache.activemq.openwire.OpenWireFormat.marshal(OpenWireFormat.java:231) at org.apache.activemq.transport.tcp.TcpTransport.oneway(TcpTransport.java:108) at org.apache.activemq.transport.InactivityMonitor.oneway(InactivityMonitor.java:142) at org.apache.activemq.transport.TransportFilter.oneway(TransportFilter.java:82) at org.apache.activemq.transport.WireFormatNegotiator.oneway(WireFormatNegotiator.java:86) at org.apache.activemq.transport.MutexTransport.oneway(MutexTransport.java:45) at org.apache.activemq.transport.ResponseCorrelator.oneway(ResponseCorrelator.java:59) at org.apache.activemq.ActiveMQConnection.asyncSendPacket(ActiveMQConnection.java:1128) ... 7 more -- View this message in context: http://www.nabble.com/Pulling-consumer-design-tf2086371.html#a5757354 Sent from the ActiveMQ - Dev forum at Nabble.com. -- James --- http://radio.weblogs.com/0112098/
[jira] Created: (AMQ-875) TCP connector (server) will stop accepting connection if an invalid connection is made to him.
TCP connector (server) will stop accepting connection if an invalid connection is made to him. -- Key: AMQ-875 URL: https://issues.apache.org/activemq/browse/AMQ-875 Project: ActiveMQ Issue Type: Bug Components: Transport Affects Versions: 4.0 Reporter: Hiram Chirino Assigned To: Hiram Chirino Charles reported on the mailing list: Hi All, We've just had a nasty situation : our ActiveMQ Server standalone plain vanilla TCP Transport, no persistency, no nuffink) on one of our live installations suddenly refused to accept any new connections - no clients could connect. All currently connected clients were fine, and messages were being processed sent and received fine. Just no-one else could connect. After 20 minutes, new connections were suddenly allowed. The following exception was in our log. 2006-Aug-11 12:17:47.726 aqualive [ActiveMQ Transport Server: tcp://blah:61616] ERROR org.apache.activemq.broker.TransportConnector - Could not accept connection: java.net.SocketException: Connection reset by peer: socket write error java.net.SocketException: Connection reset by peer: socket write error at java.net.SocketOutputStream.socketWrite0(Native Method) at java.net.SocketOutputStream.socketWrite(SocketOutputStream.java:92) at java.net.SocketOutputStream.write(SocketOutputStream.java:136) at org.apache.activemq.transport.tcp.TcpBufferedOutputStream.flush(TcpBufferedO utputStream.java:108) at java.io.DataOutputStream.flush(DataOutputStream.java:101) at org.apache.activemq.transport.tcp.TcpTransport.oneway(TcpTransport.java:125) at org.apache.activemq.transport.InactivityMonitor.oneway(InactivityMonitor.jav a:141) at org.apache.activemq.transport.WireFormatNegotiator.sendWireFormat(WireFormat Negotiator.java:128) at org.apache.activemq.transport.WireFormatNegotiator.start(WireFormatNegotiato r.java:64) at org.apache.activemq.transport.TransportFilter.start(TransportFilter.java:52) at org.apache.activemq.transport.TransportFilter.start(TransportFilter.java:52) at org.apache.activemq.broker.TransportConnection.start(TransportConnection.jav a:75) at org.apache.activemq.broker.TransportConnector$1.onAccept(TransportConnector. java:136) at org.apache.activemq.transport.tcp.TcpTransportServer.run(TcpTransportServer. java:137) at java.lang.Thread.run(Thread.java:534) My interpretation of the above that something (port scanner maybe ? Our curious IT department ?) is connecting to the listening socket, and the TransportServer is trying to tell the connecting process what the wireformat is - and the connection process is just sitting there, not responding, acknlowedging, or doing anything at all - yet not closing the connection. Therefore, the transport server is blocked, preventing anyone else connecting. After 20 mins - which I am guessing is somekind of lowlevel timeout, seeing as all the default AMQ timeouts seen to be of the order of 1 - 30 secs - a low level TCP exception is thrown, freeing the whole shebang up. I notice there is an InactivityMonitor, and looking at the code there is the following comment // Disable inactivity monitoring while processing a command. Could this be the case ? That - until the wireformat has been negotiated - there is no timeout configured ? Is there anything we can do to reduce this timeout from 20 mins ? Or have I completed gone down the wrong track ? This is AMQ 4.0, Win2K, JRE 1.4.2 Cheers, Charles -- 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: Where to add new SSL BrokerService functionality
Hi Hiram, Thanks for the quick replies, but I have more =) I can't make a broker plugin since my design (to allow for quicker implementation, etc.) uses the JAAS plugin. It stores the client's DN as the username and then passes it to a JAAS broker. There is no way of telling if client certificates were checked without talking to the transports. On 8/11/06, Hiram Chirino [EMAIL PROTECTED] wrote: Hi Sepand, For the paranoid, they should use a security broker plugin that only authorizes connections authenticated using certificates. On 8/11/06, Sepand M [EMAIL PROTECTED] wrote: I am actually implementing option 1 anyways since the reflection stuff is part of the other Transport implementations (I'm being consistent). The problem is that I want the user to be sure that the broker they start will only use certificate authenticated connections (this is for the paranoid to be sure that nothing else will get inside their server). I am suggesting something like a setNeedClientCert method that would operate similar to setUseJmx (except that setUseJmx adds a broker filter and setNeedClientAuth would change the addConnector calls to enable client certificates). On 8/10/06, Hiram Chirino [EMAIL PROTECTED] wrote: I would go with option 1 since SSL is transport layer option and does not really have anything to do with the core of the broker. On 8/10/06, Sepand M [EMAIL PROTECTED] wrote: Hi all, As some of you may know, I'm working on an SSL client certificate authorization system for ActiveMQ. I've gotten some of the basics done and am trying to create a way of ensuring that SSL client certificates are used. I see two options (and I strongly prefer the second one): 1. The client would add the proper option to the URI they bind to on the broker side (e.g URI=localhost:61616?needClientAuth=true). 2. Adding a method to the BrokerService that enables this functionality. Unless someone suggests something different, I'm choosing method 2. The problem is I can't decide if I should subclass the existing BrokerService or add the menthioned method to the existing BrokerService class. So far, BrokerService seems to be doing everything and it has no subclasses, but I'm wondering how much more can be crammed into it and if SSL functionality should be built into the general purpose broker. Any thoughts? Regards, Sepand -- Regards, Hiram Blog: http://hiramchirino.com -- Regards, Hiram Blog: http://hiramchirino.com
Re: Where to add new SSL BrokerService functionality
Sounds like it may be time to add that transient Object field to the ConnectionInfo object. Your transport could attach something to it there that the broker plugin uses to to figure out, hey this connection came from an SSL transport. perhaps it's the Certificate, perhaps it's a reference to the SSL session object. On 8/11/06, Sepand M [EMAIL PROTECTED] wrote: Hi Hiram, Thanks for the quick replies, but I have more =) I can't make a broker plugin since my design (to allow for quicker implementation, etc.) uses the JAAS plugin. It stores the client's DN as the username and then passes it to a JAAS broker. There is no way of telling if client certificates were checked without talking to the transports. On 8/11/06, Hiram Chirino [EMAIL PROTECTED] wrote: Hi Sepand, For the paranoid, they should use a security broker plugin that only authorizes connections authenticated using certificates. On 8/11/06, Sepand M [EMAIL PROTECTED] wrote: I am actually implementing option 1 anyways since the reflection stuff is part of the other Transport implementations (I'm being consistent). The problem is that I want the user to be sure that the broker they start will only use certificate authenticated connections (this is for the paranoid to be sure that nothing else will get inside their server). I am suggesting something like a setNeedClientCert method that would operate similar to setUseJmx (except that setUseJmx adds a broker filter and setNeedClientAuth would change the addConnector calls to enable client certificates). On 8/10/06, Hiram Chirino [EMAIL PROTECTED] wrote: I would go with option 1 since SSL is transport layer option and does not really have anything to do with the core of the broker. On 8/10/06, Sepand M [EMAIL PROTECTED] wrote: Hi all, As some of you may know, I'm working on an SSL client certificate authorization system for ActiveMQ. I've gotten some of the basics done and am trying to create a way of ensuring that SSL client certificates are used. I see two options (and I strongly prefer the second one): 1. The client would add the proper option to the URI they bind to on the broker side (e.g URI=localhost:61616?needClientAuth=true). 2. Adding a method to the BrokerService that enables this functionality. Unless someone suggests something different, I'm choosing method 2. The problem is I can't decide if I should subclass the existing BrokerService or add the menthioned method to the existing BrokerService class. So far, BrokerService seems to be doing everything and it has no subclasses, but I'm wondering how much more can be crammed into it and if SSL functionality should be built into the general purpose broker. Any thoughts? Regards, Sepand -- Regards, Hiram Blog: http://hiramchirino.com -- Regards, Hiram Blog: http://hiramchirino.com -- Regards, Hiram Blog: http://hiramchirino.com
Re: Where to add new SSL BrokerService functionality
Hmm. Sounds like you're right =) I think I will. A few questions: 1. Why transient? Is ConnectionInfo serialized anywhere? I thought marshallers were doing that stuff. 2. If I use a generic Object field, the hypothetical security broker plugin would have to do a cast to Certificate (or whatever) which, if the classes are not hooked up right, could fail. Is that ok? On 8/11/06, Hiram Chirino [EMAIL PROTECTED] wrote: Sounds like it may be time to add that transient Object field to the ConnectionInfo object. Your transport could attach something to it there that the broker plugin uses to to figure out, hey this connection came from an SSL transport. perhaps it's the Certificate, perhaps it's a reference to the SSL session object. On 8/11/06, Sepand M [EMAIL PROTECTED] wrote: Hi Hiram, Thanks for the quick replies, but I have more =) I can't make a broker plugin since my design (to allow for quicker implementation, etc.) uses the JAAS plugin. It stores the client's DN as the username and then passes it to a JAAS broker. There is no way of telling if client certificates were checked without talking to the transports. On 8/11/06, Hiram Chirino [EMAIL PROTECTED] wrote: Hi Sepand, For the paranoid, they should use a security broker plugin that only authorizes connections authenticated using certificates. On 8/11/06, Sepand M [EMAIL PROTECTED] wrote: I am actually implementing option 1 anyways since the reflection stuff is part of the other Transport implementations (I'm being consistent). The problem is that I want the user to be sure that the broker they start will only use certificate authenticated connections (this is for the paranoid to be sure that nothing else will get inside their server). I am suggesting something like a setNeedClientCert method that would operate similar to setUseJmx (except that setUseJmx adds a broker filter and setNeedClientAuth would change the addConnector calls to enable client certificates). On 8/10/06, Hiram Chirino [EMAIL PROTECTED] wrote: I would go with option 1 since SSL is transport layer option and does not really have anything to do with the core of the broker. On 8/10/06, Sepand M [EMAIL PROTECTED] wrote: Hi all, As some of you may know, I'm working on an SSL client certificate authorization system for ActiveMQ. I've gotten some of the basics done and am trying to create a way of ensuring that SSL client certificates are used. I see two options (and I strongly prefer the second one): 1. The client would add the proper option to the URI they bind to on the broker side (e.g URI=localhost:61616?needClientAuth=true). 2. Adding a method to the BrokerService that enables this functionality. Unless someone suggests something different, I'm choosing method 2. The problem is I can't decide if I should subclass the existing BrokerService or add the menthioned method to the existing BrokerService class. So far, BrokerService seems to be doing everything and it has no subclasses, but I'm wondering how much more can be crammed into it and if SSL functionality should be built into the general purpose broker. Any thoughts? Regards, Sepand -- Regards, Hiram Blog: http://hiramchirino.com -- Regards, Hiram Blog: http://hiramchirino.com -- Regards, Hiram Blog: http://hiramchirino.com
RE: Pulling consumer design
James, I'm looking into your change (430445) and don't understand how it solves problem of slow consumer. It is essentially still a push model as Queue.dispatch actively pushes messages to subscriptions. Subscriptions store unconsumed messages in pending list. So slow consumer still will get its share of messages. I think temporary workaround could be sharing pending list between all consumers that have same message selector. Maxim. -Original Message- From: James Strachan [mailto:[EMAIL PROTECTED] Sent: Friday, August 11, 2006 1:00 AM To: activemq-dev@geronimo.apache.org Subject: Re: Pulling consumer design Sorry about that, I'd forgotten to run the mvn gram:gram command. Its now in SVN On 8/11/06, Vadim Pesochinsky [EMAIL PROTECTED] wrote: There is a little problem with MessagePullMarshaller not generated / added to svn. I tried to run generator, but withouth much luck. Found this instructions, but I could not find the maven-gram-plugin. Thanks. cd maven-gram-plugin/ mvn install cd ../activemq-openwire-generator/ mvn install cd ../activemq-core mvn gram:gram javax.jms.JMSException: Unknown data type: 20 at org.apache.activemq.util.JMSExceptionSupport.create(JMSExceptionSupport.java:58) at org.apache.activemq.ActiveMQConnection.asyncSendPacket(ActiveMQConnection.java:1130) at org.apache.activemq.ActiveMQSession.asyncSendPacket(ActiveMQSession.java:1649) at org.apache.activemq.ActiveMQMessageConsumer.sendPullCommand(ActiveMQMessageConsumer.java:605) at org.apache.activemq.ActiveMQMessageConsumer.receive(ActiveMQMessageConsumer.java:463) at com.barra.cp.common.io.SingleMessageMultiQueueReceiver$OneMessageAtATime.runSingleQueue(SingleMessageMultiQueueReceiver.java:185) at com.barra.cp.common.io.SingleMessageMultiQueueReceiver$OneMessageAtATime.doRun(SingleMessageMultiQueueReceiver.java:141) at com.barra.cp.common.io.SingleMessageMultiQueueReceiver$OneMessageAtATime.run(SingleMessageMultiQueueReceiver.java:124) at java.lang.Thread.run(Unknown Source) Caused by: java.io.IOException: Unknown data type: 20 at org.apache.activemq.openwire.OpenWireFormat.marshal(OpenWireFormat.java:231) at org.apache.activemq.transport.tcp.TcpTransport.oneway(TcpTransport.java:108) at org.apache.activemq.transport.InactivityMonitor.oneway(InactivityMonitor.java:142) at org.apache.activemq.transport.TransportFilter.oneway(TransportFilter.java:82) at org.apache.activemq.transport.WireFormatNegotiator.oneway(WireFormatNegotiator.java:86) at org.apache.activemq.transport.MutexTransport.oneway(MutexTransport.java:45) at org.apache.activemq.transport.ResponseCorrelator.oneway(ResponseCorrelator.java:59) at org.apache.activemq.ActiveMQConnection.asyncSendPacket(ActiveMQConnection.java:1128) ... 7 more -- View this message in context: http://www.nabble.com/Pulling-consumer-design-tf2086371.html#a5757354 Sent from the ActiveMQ - Dev forum at Nabble.com. -- James --- http://radio.weblogs.com/0112098/
Re: Where to add new SSL BrokerService functionality
On 8/11/06, Sepand M [EMAIL PROTECTED] wrote: Hmm. Sounds like you're right =) I think I will. A few questions: 1. Why transient? Is ConnectionInfo serialized anywhere? I thought marshallers were doing that stuff. because it's not field that should be serialized. It only a way for the broker side transport to communicate some info to the broker. 2. If I use a generic Object field, the hypothetical security broker plugin would have to do a cast to Certificate (or whatever) which, if the classes are not hooked up right, could fail. Is that ok? Well, he should first test to see if it's an instance of what you expect. If it's not that or not set at all you could assume that the transport being used is NOT ssl and reject that request. On 8/11/06, Hiram Chirino [EMAIL PROTECTED] wrote: Sounds like it may be time to add that transient Object field to the ConnectionInfo object. Your transport could attach something to it there that the broker plugin uses to to figure out, hey this connection came from an SSL transport. perhaps it's the Certificate, perhaps it's a reference to the SSL session object. On 8/11/06, Sepand M [EMAIL PROTECTED] wrote: Hi Hiram, Thanks for the quick replies, but I have more =) I can't make a broker plugin since my design (to allow for quicker implementation, etc.) uses the JAAS plugin. It stores the client's DN as the username and then passes it to a JAAS broker. There is no way of telling if client certificates were checked without talking to the transports. On 8/11/06, Hiram Chirino [EMAIL PROTECTED] wrote: Hi Sepand, For the paranoid, they should use a security broker plugin that only authorizes connections authenticated using certificates. On 8/11/06, Sepand M [EMAIL PROTECTED] wrote: I am actually implementing option 1 anyways since the reflection stuff is part of the other Transport implementations (I'm being consistent). The problem is that I want the user to be sure that the broker they start will only use certificate authenticated connections (this is for the paranoid to be sure that nothing else will get inside their server). I am suggesting something like a setNeedClientCert method that would operate similar to setUseJmx (except that setUseJmx adds a broker filter and setNeedClientAuth would change the addConnector calls to enable client certificates). On 8/10/06, Hiram Chirino [EMAIL PROTECTED] wrote: I would go with option 1 since SSL is transport layer option and does not really have anything to do with the core of the broker. On 8/10/06, Sepand M [EMAIL PROTECTED] wrote: Hi all, As some of you may know, I'm working on an SSL client certificate authorization system for ActiveMQ. I've gotten some of the basics done and am trying to create a way of ensuring that SSL client certificates are used. I see two options (and I strongly prefer the second one): 1. The client would add the proper option to the URI they bind to on the broker side (e.g URI=localhost:61616?needClientAuth=true). 2. Adding a method to the BrokerService that enables this functionality. Unless someone suggests something different, I'm choosing method 2. The problem is I can't decide if I should subclass the existing BrokerService or add the menthioned method to the existing BrokerService class. So far, BrokerService seems to be doing everything and it has no subclasses, but I'm wondering how much more can be crammed into it and if SSL functionality should be built into the general purpose broker. Any thoughts? Regards, Sepand -- Regards, Hiram Blog: http://hiramchirino.com -- Regards, Hiram Blog: http://hiramchirino.com -- Regards, Hiram Blog: http://hiramchirino.com -- Regards, Hiram Blog: http://hiramchirino.com
[jira] Commented: (AMQ-630) After broker has shutdown, cannot shutdown a client application
[ https://issues.apache.org/activemq/browse/AMQ-630?page=comments#action_36761 ] Kieran Murphy commented on AMQ-630: --- Yes - even with the closeTimeout value set to 500ms, if I am using failover then the client will wait FOREVER for the broker to reply before shutting down. Without failover, if I just use TCP, then client shuts down properly, I have been testing this using the 4.0.1 release: incubator-activemq-4.0.1. Perhaps you could try to duplicate this, so I'll at least know that it's not just my configuration? Thanks. After broker has shutdown, cannot shutdown a client application --- Key: AMQ-630 URL: https://issues.apache.org/activemq/browse/AMQ-630 Project: ActiveMQ Issue Type: Bug Affects Versions: 4.0 M4 Reporter: Kieran Murphy Assigned To: Hiram Chirino Fix For: 4.1 1. Bring up a broker 2. Bring up a client application which connects to the broker 3. Stop the broker. 4. Now try to stop the client app -- it will not shutdown until the broker is restarted. Using failover:tcp to connect to broker. -- 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: (SM-526) Fault messages returned to BPEL via servicemix-bpe are not accessible in BPEL
[ https://issues.apache.org/activemq/browse/SM-526?page=comments#action_36757 ] Guillaume Nodet commented on SM-526: Thx. When you launch the command from the root dir, the patch file will include the path informations. This is much easier to apply as you only need to apply one patch file. Fault messages returned to BPEL via servicemix-bpe are not accessible in BPEL - Key: SM-526 URL: https://issues.apache.org/activemq/browse/SM-526 Project: ServiceMix Issue Type: Bug Components: servicemix-bpe Environment: Ubuntu Linux 5.10, Windows XP SP2, ServiceMix HEAD Reporter: Grant McDonald Attachments: servicemix-bpe.zip Original Estimate: 15 minutes Remaining Estimate: 15 minutes When returning output and fault messages an XMLInteractionObject is currently being used to wrap the Document object created from the NormalizedMessage. The use of XMLInteractionObject is deprecated within ODE and due to some not entirely understood code paths this results in Fault messages being wrapped in a CannedFormattableValue which renders the object immutable in BPEL and its data unretrieveable to the JBI world when sent back to ServiceMix. The answer is to use instead DescribedValue from ODE/BPE to wrap both the output and fault messages of a JBI invoke action. A patch for this has been attached. Testing has been done, although no test cases have been prepared. -- 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: build broken
AFAIK, i have fixed that yesterday. Could you try with the svn head ?
On 8/11/06, Antoni Reus [EMAIL PROTECTED] wrote:
It seems there is a problem in samples:
It seems there is a problem with relative/absolute path of file
samples/wsdl-first/wsdl-first-jsr181-su/src/main/resources/xbean.xml
mvn -Dmaven.test.skip=true -Dprofile=step2 install, fails with:
[INFO]
[INFO] Building ServiceMix :: Samples :: WSDL first :: JSR181
[INFO]task-segment: [install]
[INFO]
[INFO] [antrun:run {execution: default}]
[INFO] Executing tasks
11/08/200It seems there is a problem with relative/absolute path of file
samples/wsdl-first/wsdl-first-jsr181-su/src/main/resources/xbean.xml6
09:41:37 org.codehaus.xfire.gen.Wsdl11Generator generate
INFO: Generating code for WSDL at
file:/home/IBIT/areus/java/servicemix/servicemix-3.0-dev
/samples/wsdl-first/wsdl-first-jsr181-su/src/main/resources/person.wsdl
with a base URI of
file:/home/IBIT/areus/java/servicemix/servicemix-3.0-dev
/samples/wsdl-first/wsdl-first-jsr181-su/src/main/resources/person.wsdl
org/apache/servicemix/samples/wsdl_first/types/GetPersonRequest.java
org/apache/servicemix/samples/wsdl_first/types/GetPersonResponse.java
org/apache/servicemix/samples/wsdl_first/types/ObjectFactory.java
org/apache/servicemix/samples/wsdl_first/types/UnknownPersonFault.java
org/apache/servicemix/samples/wsdl_first/types/package-info.java
11/08/2006 09:41:37
org.codehaus.xfire.gen.jsr181.AbstractServiceGenerator generate
INFO: Creating class org.apache.servicemix.samples.wsdl_first.Person
11/08/2006 09:41:37
org.codehaus.xfire.gen.jsr181.AbstractServiceGenerator generate
INFO: Creating class
org.apache.servicemix.samples.wsdl_first.PersonServiceImpl
org/apache/servicemix/samples/wsdl_first/Person.java
org/apache/servicemix/samples/wsdl_first/PersonServiceImpl.java
org/apache/servicemix/samples/wsdl_first/PersonServiceService.java
org/apache/servicemix/samples/wsdl_first/UnknownPersonFault.java
[INFO] Executed tasks
[INFO] Registering compile source root
/home/IBIT/areus/java/servicemix/servicemix-3.0-dev
/samples/wsdl-first/wsdl-first-jsr181-su/target/jaxws
[INFO] [resources:resources]
[INFO] Using default encoding to copy filtered resources.
[INFO] [compiler:compile]
Compiling 9 source files to
/home/IBIT/areus/java/servicemix/servicemix-3.0-dev
/samples/wsdl-first/wsdl-first-jsr181-su/target/classes
[INFO] [jbi:generate-jbi-service-unit-descriptor]
[INFO] Generating jbi.xml
[INFO] Created Service Unit Analyzer
[EMAIL PROTECTED]
2006-08-11 09:41:38,733 [main ] INFO
CollectionFactory - JDK 1.4+ collections available
2006-08-11 09:41:38,743 [main ] INFO
CollectionFactory - Commons Collections 3.x available
2006-08-11 09:41:38,785 [main ] INFO
XBeanXmlBeanDefinitionReader - Loading XML bean definitions from file
[/home/IBIT/areus/java/servicemix/servicemix-3.0-dev
/home/IBIT/areus/java/servicemix/servicemix-3.0-dev
/samples/wsdl-first/wsdl-first-jsr181-su/src/main/resources/xbean.xml]
[INFO]
[ERROR] BUILD ERROR
[INFO]
[INFO] Failed to generate jbi.xml
Embedded error: Unable to generate service unit descriptor!
home/IBIT/areus/java/servicemix/servicemix-3.0-dev
/samples/wsdl-first/wsdl-first-jsr181-su/src/main/resources/xbean.xml
(No such file or directory)
Salut.
--
Antoni Reus Darder
Cap de Projecte
Administració Digital, Negoci Electrònic i Sanitat
F u n d a c i ó I B I T
Illes Balears Innovació Tecnològica
http://www.ibit.org
Tel. +34 971 17 72 70/71
Fax. +34 971 17 72 79
--
Cheers,
Guillaume Nodet
Re: build broken
I build on a debian linux, perhaps is a platform issue?
Antoni Reus wrote:
I Just tried:
svn update
mvn -Dmaven.test.skip=true -Dprofile=step1 install
mvn -Dmaven.test.skip=true -Dprofile=step2 install
same error :-(
Guillaume Nodet wrote:
AFAIK, i have fixed that yesterday. Could you try with the svn head ?
On 8/11/06, Antoni Reus [EMAIL PROTECTED] wrote:
It seems there is a problem in samples:
It seems there is a problem with relative/absolute path of file
samples/wsdl-first/wsdl-first-jsr181-su/src/main/resources/xbean.xml
mvn -Dmaven.test.skip=true -Dprofile=step2 install, fails with:
[INFO]
[INFO] Building ServiceMix :: Samples :: WSDL first :: JSR181
[INFO]task-segment: [install]
[INFO]
[INFO] [antrun:run {execution: default}]
[INFO] Executing tasks
11/08/200It seems there is a problem with relative/absolute path of
file
samples/wsdl-first/wsdl-first-jsr181-su/src/main/resources/xbean.xml6
09:41:37 org.codehaus.xfire.gen.Wsdl11Generator generate
INFO: Generating code for WSDL at
file:/home/IBIT/areus/java/servicemix/servicemix-3.0-dev
/samples/wsdl-first/wsdl-first-jsr181-su/src/main/resources/person.wsdl
with a base URI of
file:/home/IBIT/areus/java/servicemix/servicemix-3.0-dev
/samples/wsdl-first/wsdl-first-jsr181-su/src/main/resources/person.wsdl
org/apache/servicemix/samples/wsdl_first/types/GetPersonRequest.java
org/apache/servicemix/samples/wsdl_first/types/GetPersonResponse.java
org/apache/servicemix/samples/wsdl_first/types/ObjectFactory.java
org/apache/servicemix/samples/wsdl_first/types/UnknownPersonFault.java
org/apache/servicemix/samples/wsdl_first/types/package-info.java
11/08/2006 09:41:37
org.codehaus.xfire.gen.jsr181.AbstractServiceGenerator generate
INFO: Creating class org.apache.servicemix.samples.wsdl_first.Person
11/08/2006 09:41:37
org.codehaus.xfire.gen.jsr181.AbstractServiceGenerator generate
INFO: Creating class
org.apache.servicemix.samples.wsdl_first.PersonServiceImpl
org/apache/servicemix/samples/wsdl_first/Person.java
org/apache/servicemix/samples/wsdl_first/PersonServiceImpl.java
org/apache/servicemix/samples/wsdl_first/PersonServiceService.java
org/apache/servicemix/samples/wsdl_first/UnknownPersonFault.java
[INFO] Executed tasks
[INFO] Registering compile source root
/home/IBIT/areus/java/servicemix/servicemix-3.0-dev
/samples/wsdl-first/wsdl-first-jsr181-su/target/jaxws
[INFO] [resources:resources]
[INFO] Using default encoding to copy filtered resources.
[INFO] [compiler:compile]
Compiling 9 source files to
/home/IBIT/areus/java/servicemix/servicemix-3.0-dev
/samples/wsdl-first/wsdl-first-jsr181-su/target/classes
[INFO] [jbi:generate-jbi-service-unit-descriptor]
[INFO] Generating jbi.xml
[INFO] Created Service Unit Analyzer
[EMAIL PROTECTED]
2006-08-11 09:41:38,733 [main ] INFO
CollectionFactory - JDK 1.4+ collections available
2006-08-11 09:41:38,743 [main ] INFO
CollectionFactory - Commons Collections 3.x available
2006-08-11 09:41:38,785 [main ] INFO
XBeanXmlBeanDefinitionReader - Loading XML bean definitions from file
[/home/IBIT/areus/java/servicemix/servicemix-3.0-dev
/home/IBIT/areus/java/servicemix/servicemix-3.0-dev
/samples/wsdl-first/wsdl-first-jsr181-su/src/main/resources/xbean.xml]
[INFO]
[ERROR] BUILD ERROR
[INFO]
[INFO] Failed to generate jbi.xml
Embedded error: Unable to generate service unit descriptor!
home/IBIT/areus/java/servicemix/servicemix-3.0-dev
/samples/wsdl-first/wsdl-first-jsr181-su/src/main/resources/xbean.xml
(No such file or directory)
Salut.
--
Antoni Reus Darder
Cap de Projecte
Administració Digital, Negoci Electrònic i Sanitat
F u n d a c i ó I B I T
Illes Balears Innovació Tecnològica
http://www.ibit.org
Tel. +34 971 17 72 70/71
Fax. +34 971 17 72 79
--
Antoni Reus Darder
Cap de Projecte
Administració Digital, Negoci Electrònic i Sanitat
F u n d a c i ó I B I T
Illes Balears Innovació Tecnològica
http://www.ibit.org
Tel. +34 971 17 72 70/71
Fax. +34 971 17 72 79
Re: [jira] Created: (SM-534) Business Activity Monitoring Component
A few comments: 1) Files should include the Apache standard header 2) resources are loaded with xbean in BAMEndpoint.process they override any definition specified directly with the rules, actions properties IMHO, they should be loaded when activate is called (or at initialization time, by implementing the spring interface InitializingBean) and only if the properties are not set 3) I don't see any use of the BAMGlobalConfig / Params classes 4) Rules are not extensible. People will need to use to be able to check for properties, attachments, not only xpath on the content. So it should be an interface with Object evaluate(MessageExchange exchange) or Object evaluate(NormalizedMessage message) or anything like that. 5) When using xpath, you need a way to configure the namesapces in use in the xpath expression, else you can not use it on xml requests with namespaces. Take a look at the XPathPredicate in servicemix-eip 6) The configuration could leverage much more of spring/xbean features and use a clean POJO model which will be easily translated into a clean xml schema using xbean. They don't need to use id references and class names, as spring will do that easily. And instead of using BAMActionParameters, these parameters could be easily configured on the action / adaptor itself. So instead of having bam:bAMRule description=Email rule1 resultType=Boolean ruleName=emailRule1 xpath=/[EMAIL PROTECTED]'555-3482'] bam:actionDetails bam:bAMActionDetail executeOn=true actionID=printer active=true/ /bam:actionDetails /bam:bAMRule bam:bAMAction actionName=printer adaptorClass= org.apache.servicemix.bam.sample.PrintAdaptor description=For emailing bam:params bam:bAMActionParameter name=mobileNumber value=405-3785 type=String/ bam:bAMActionParameter name=address value=680, morse ave CA type=String/ /bam:params /bam:bAMAction You could simply have bam:endpoint ... bam:rule bam:evaluator bam:xpath xpath=/test:sample/@id nsContext=#nsContext / /bam:evaluator bam:actions bam:action executeOn=554-345 adaptor=#printAdaptor / /bam:actions /bam:endpoint bam:print id=printAdaptor output=stderr mobileNumber=405-3785 address=680, morse ave CA / bam:namespaceContext id=nsContext bam:namespace prefix=testhttp://test/bam:namespace /bam:namespaceContext This is only an example to show how to use references, without having to define IDs and classNames. This lead to a much cleaner POJO model. On 8/10/06, Soumadeep Sen (JIRA) [EMAIL PROTECTED] wrote: Business Activity Monitoring Component -- Key: SM-534 URL: https://issues.apache.org/activemq/browse/SM-534 Project: ServiceMix Issue Type: New Feature Components: servicemix-common Reporter: Soumadeep Sen Attachments: servicemix-bam.zip This Business Activity Monitoring component which works off an xpath expression. The xpath expression acts as a Key performance indicator. Based on the xpath evaluation, actions can be triggered. These actions can be implemented by users by extending the BAMAdaptor interface's execute method which takes an array of BAMActionParameter. For providing details in terms of Rules,Actions and global parameters, the actions.xml, rules.xml and globalConfig.xml need to be populated. Sample files can be found in the src/test/resources directory and usage details for the BAMComponent can be found in the spring.xml file which is in the same directory. The relationship between actions and rules is established by id reference where in the rules have actions IDs (no or more). Please refer the respective xml files. All implemented adaptor classes could be put in the option lib directory of smx so that they can be referenced by the BAM processor. (A sample Adaptor called PrintAdaptor has been provided in the src...samples dir for reference) Will be putting a wiki page shortly which will have more details. -- 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 -- Cheers, Guillaume Nodet
Re: build broken
:(
It works fine for me.
Could you try to run with -e at the end ? maven should print any exception
stack trace.
On 8/11/06, Antoni Reus [EMAIL PROTECTED] wrote:
I Just tried:
svn update
mvn -Dmaven.test.skip=true -Dprofile=step1 install
mvn -Dmaven.test.skip=true -Dprofile=step2 install
same error :-(
Guillaume Nodet wrote:
AFAIK, i have fixed that yesterday. Could you try with the svn head ?
On 8/11/06, Antoni Reus [EMAIL PROTECTED] wrote:
It seems there is a problem in samples:
It seems there is a problem with relative/absolute path of file
samples/wsdl-first/wsdl-first-jsr181-su/src/main/resources/xbean.xml
mvn -Dmaven.test.skip=true -Dprofile=step2 install, fails with:
[INFO]
[INFO] Building ServiceMix :: Samples :: WSDL first :: JSR181
[INFO]task-segment: [install]
[INFO]
[INFO] [antrun:run {execution: default}]
[INFO] Executing tasks
11/08/200It seems there is a problem with relative/absolute path of
file
samples/wsdl-first/wsdl-first-jsr181-su/src/main/resources/xbean.xml6
09:41:37 org.codehaus.xfire.gen.Wsdl11Generator generate
INFO: Generating code for WSDL at
file:/home/IBIT/areus/java/servicemix/servicemix-3.0-dev
/samples/wsdl-first/wsdl-first-jsr181-su/src/main/resources/person.wsdl
with a base URI of
file:/home/IBIT/areus/java/servicemix/servicemix-3.0-dev
/samples/wsdl-first/wsdl-first-jsr181-su/src/main/resources/person.wsdl
org/apache/servicemix/samples/wsdl_first/types/GetPersonRequest.java
org/apache/servicemix/samples/wsdl_first/types/GetPersonResponse.java
org/apache/servicemix/samples/wsdl_first/types/ObjectFactory.java
org/apache/servicemix/samples/wsdl_first/types/UnknownPersonFault.java
org/apache/servicemix/samples/wsdl_first/types/package-info.java
11/08/2006 09:41:37
org.codehaus.xfire.gen.jsr181.AbstractServiceGenerator generate
INFO: Creating class org.apache.servicemix.samples.wsdl_first.Person
11/08/2006 09:41:37
org.codehaus.xfire.gen.jsr181.AbstractServiceGenerator generate
INFO: Creating class
org.apache.servicemix.samples.wsdl_first.PersonServiceImpl
org/apache/servicemix/samples/wsdl_first/Person.java
org/apache/servicemix/samples/wsdl_first/PersonServiceImpl.java
org/apache/servicemix/samples/wsdl_first/PersonServiceService.java
org/apache/servicemix/samples/wsdl_first/UnknownPersonFault.java
[INFO] Executed tasks
[INFO] Registering compile source root
/home/IBIT/areus/java/servicemix/servicemix-3.0-dev
/samples/wsdl-first/wsdl-first-jsr181-su/target/jaxws
[INFO] [resources:resources]
[INFO] Using default encoding to copy filtered resources.
[INFO] [compiler:compile]
Compiling 9 source files to
/home/IBIT/areus/java/servicemix/servicemix-3.0-dev
/samples/wsdl-first/wsdl-first-jsr181-su/target/classes
[INFO] [jbi:generate-jbi-service-unit-descriptor]
[INFO] Generating jbi.xml
[INFO] Created Service Unit Analyzer
[EMAIL PROTECTED]
2006-08-11 09:41:38,733 [main ] INFO
CollectionFactory - JDK 1.4+ collections available
2006-08-11 09:41:38,743 [main ] INFO
CollectionFactory - Commons Collections 3.x available
2006-08-11 09:41:38,785 [main ] INFO
XBeanXmlBeanDefinitionReader - Loading XML bean definitions from file
[/home/IBIT/areus/java/servicemix/servicemix-3.0-dev
/home/IBIT/areus/java/servicemix/servicemix-3.0-dev
/samples/wsdl-first/wsdl-first-jsr181-su/src/main/resources/xbean.xml]
[INFO]
[ERROR] BUILD ERROR
[INFO]
[INFO] Failed to generate jbi.xml
Embedded error: Unable to generate service unit descriptor!
home/IBIT/areus/java/servicemix/servicemix-3.0-dev
/samples/wsdl-first/wsdl-first-jsr181-su/src/main/resources/xbean.xml
(No such file or directory)
Salut.
--
Antoni Reus Darder
Cap de Projecte
Administració Digital, Negoci Electrònic i Sanitat
F u n d a c i ó I B I T
Illes Balears Innovació Tecnològica
http://www.ibit.org
Tel. +34 971 17 72 70/71
Fax. +34 971 17 72 79
--
Antoni Reus Darder
Cap de Projecte
Administració Digital, Negoci Electrònic i Sanitat
F u n d a c i ó I B I T
Illes Balears Innovació Tecnològica
http://www.ibit.org
Tel. +34 971 17 72 70/71
Fax. +34 971 17 72 79
--
Cheers,
Guillaume Nodet
[jira] Resolved: (SM-458) Remove xbean patches
[ https://issues.apache.org/activemq/browse/SM-458?page=all ] Guillaume Nodet resolved SM-458. Fix Version/s: 3.0-M3 (was: 3.0) Resolution: Fixed Assignee: Guillaume Nodet Author: gnodet Date: Fri Aug 11 02:49:59 2006 New Revision: 430746 URL: http://svn.apache.org/viewvc?rev=430746view=rev Log: SM-458: Remove xbean patches Removed: incubator/servicemix/trunk/servicemix-core/src/main/java/org/apache/servicemix/jbi/loaders/ incubator/servicemix/trunk/servicemix-core/src/main/java/org/apache/servicemix/xbean/ Modified: incubator/servicemix/trunk/servicemix-core/src/main/java/org/apache/servicemix/jbi/framework/AdminCommandsServiceMBean.java incubator/servicemix/trunk/servicemix-core/src/main/java/org/apache/servicemix/jbi/framework/ComponentRegistry.java incubator/servicemix/trunk/servicemix-core/src/main/java/org/apache/servicemix/jbi/framework/InstallerMBeanImpl.java incubator/servicemix/trunk/servicemix-core/src/main/java/org/apache/servicemix/jbi/framework/Registry.java incubator/servicemix/trunk/servicemix-core/src/main/java/org/apache/servicemix/jbi/framework/ServiceUnitMBean.java incubator/servicemix/trunk/servicemix-core/src/main/java/org/apache/servicemix/jbi/framework/SharedLibrary.java incubator/servicemix/trunk/servicemix-core/src/main/java/org/apache/servicemix/jbi/framework/SharedLibraryMBean.java incubator/servicemix/trunk/servicemix-core/src/test/java/org/apache/servicemix/jbi/loaders/ClassLoaderTest.java Remove xbean patches Key: SM-458 URL: https://issues.apache.org/activemq/browse/SM-458 Project: ServiceMix Issue Type: Task Components: servicemix-core Affects Versions: 3.0-M2 Reporter: Guillaume Nodet Assigned To: Guillaume Nodet Fix For: 3.0-M3 Depends on http://issues.apache.org/jira/browse/XBEAN-21 http://issues.apache.org/jira/browse/XBEAN-22 Packages: org.apache.servicemix.xbean org.apache.servicemix.jbi.loaders -- 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-521) Tuning parameters configuration
[ https://issues.apache.org/activemq/browse/SM-521?page=all ] Guillaume Nodet updated SM-521: --- Fix Version/s: 3.0 (was: 3.0-M3) Tuning parameters configuration --- Key: SM-521 URL: https://issues.apache.org/activemq/browse/SM-521 Project: ServiceMix Issue Type: Improvement Components: servicemix-core Reporter: Guillaume Nodet Fix For: 3.0 We need to provide a way to configure tuning parameters for servicemix: * thread pools (core + flows + seda queues + components ) * queues (delivery channels + seda queues) * component throttling This may need a way to configure dummy activationSpecs (with no components, only the component name) so that we can configure these parameters when using JBI std installation -- 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: build broken
This is the exact issue i fixed a few hours ago. See http://svn.apache.org/viewvc?view=revrevision=430410 Are you sure you compile the latest svn head ? On 8/11/06, Antoni Reus [EMAIL PROTECTED] wrote: with -e: [INFO] [jbi:generate-jbi-service-unit-descriptor] [INFO] Generating jbi.xml [INFO] Created Service Unit Analyzer [EMAIL PROTECTED] 2006-08-11 12:13:33,176 [main ] INFO CollectionFactory - JDK 1.4+ collections available 2006-08-11 12:13:33,186 [main ] INFO CollectionFactory - Commons Collections 3.x available 2006-08-11 12:13:33,235 [main ] INFO XBeanXmlBeanDefinitionReader - Loading XML bean definitions from file [/home/IBIT/areus/java/servicemix/servicemix-3.0-dev /home/IBIT/areus/java/servicemix/servicemix-3.0-dev /samples/wsdl-first/wsdl-first-jsr181-su/src/main/resources/xbean.xml] [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Failed to generate jbi.xml Embedded error: Unable to generate service unit descriptor! home/IBIT/areus/java/servicemix/servicemix-3.0-dev /samples/wsdl-first/wsdl-first-jsr181-su/src/main/resources/xbean.xml (No such file or directory) [INFO] [INFO] Trace org.apache.maven.lifecycle.LifecycleExecutionException: Failed to generate jbi.xml at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals( DefaultLifecycleExecutor.java:559) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle (DefaultLifecycleExecutor.java:475) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal( DefaultLifecycleExecutor.java:454) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures (DefaultLifecycleExecutor.java:306) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments( DefaultLifecycleExecutor.java:273) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute( DefaultLifecycleExecutor.java:140) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:322) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:115) at org.apache.maven.cli.MavenCli.main(MavenCli.java:256) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java :39) at sun.reflect.DelegatingMethodAccessorImpl.invoke( DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) at org.codehaus.classworlds.Launcher.main(Launcher.java:375) Caused by: org.apache.maven.plugin.MojoExecutionException: Failed to generate jbi.xml at org.apache.servicemix.maven.plugin.jbi.GenerateServiceUnitDescriptorMojo.execute (GenerateServiceUnitDescriptorMojo.java:143) at org.apache.maven.plugin.DefaultPluginManager.executeMojo( DefaultPluginManager.java:412) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals( DefaultLifecycleExecutor.java:534) ... 16 more Caused by: org.apache.servicemix.maven.plugin.jbi.JbiPluginException: Unable to generate service unit descriptor! at org.apache.servicemix.maven.plugin.jbi.GenerateServiceUnitDescriptorMojo.generateJbiDescriptor (GenerateServiceUnitDescriptorMojo.java:234) at org.apache.servicemix.maven.plugin.jbi.GenerateServiceUnitDescriptorMojo.execute (GenerateServiceUnitDescriptorMojo.java:141) ... 18 more Caused by: org.springframework.beans.factory.BeanDefinitionStoreException: IOException parsing XML document from file [/home/IBIT/areus/java/servicemix/servicemix-3.0-dev /home/IBIT/areus/java/servicemix/servicemix-3.0-dev /samples/wsdl-first/wsdl-first-jsr181-su/src/main/resources/xbean.xml]; nested exception is java.io.FileNotFoundException: home/IBIT/areus/java/servicemix/servicemix-3.0-dev /samples/wsdl-first/wsdl-first-jsr181-su/src/main/resources/xbean.xml (No such file or directory) at org.springframework.beans.factory.xml.XmlBeanDefinitionReader.loadBeanDefinitions (XmlBeanDefinitionReader.java:347) at org.springframework.beans.factory.xml.XmlBeanDefinitionReader.loadBeanDefinitions (XmlBeanDefinitionReader.java:315) at org.springframework.beans.factory.support.AbstractBeanDefinitionReader.loadBeanDefinitions (AbstractBeanDefinitionReader.java:126) at org.springframework.beans.factory.support.AbstractBeanDefinitionReader.loadBeanDefinitions (AbstractBeanDefinitionReader.java:142) at
[jira] Resolved: (SM-367) Add a JCA processor to servicemix-jms
[ https://issues.apache.org/activemq/browse/SM-367?page=all ] Guillaume Nodet resolved SM-367. Fix Version/s: 3.0-M3 Resolution: Fixed Assignee: Guillaume Nodet Author: gnodet Date: Fri Aug 11 09:43:46 2006 New Revision: 430821 URL: http://svn.apache.org/viewvc?rev=430821view=rev Log: SM-367: add JCA support to servicemix-jms Added: incubator/servicemix/trunk/servicemix-jms/src/main/java/org/apache/servicemix/jms/jca/ 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/resources/META-INF/services/org/apache/servicemix/jms/jca incubator/servicemix/trunk/servicemix-jms/src/test/java/org/apache/servicemix/jms/JmsSpringJcaTest.java incubator/servicemix/trunk/servicemix-jms/src/test/resources/org/apache/servicemix/jms/spring-jca.xml Modified: incubator/servicemix/trunk/servicemix-jms/pom.xml 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/JmsBootstrap.java incubator/servicemix/trunk/servicemix-jms/src/main/java/org/apache/servicemix/jms/JmsConfiguration.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/JmsWsdl1Deployer.java incubator/servicemix/trunk/servicemix-jms/src/main/java/org/apache/servicemix/jms/JmsXBeanDeployer.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/jbi/META-INF/NOTICE incubator/servicemix/trunk/servicemix-jms/src/test/java/org/apache/servicemix/jms/JmsSpringTest.java Add a JCA processor to servicemix-jms - Key: SM-367 URL: https://issues.apache.org/activemq/browse/SM-367 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
Nightly snapshots are up again
Nightly snapshots can be downloaded at http://people.apache.org/maven-snapshot-repository/org/apache/servicemix/apache-servicemix/3.0-incubating-SNAPSHOT/ -- Cheers, Guillaume Nodet
[jira] Closed: (SM-140) Add a GBean project to better integrate ServiceMix into Geronimo
[ https://issues.apache.org/activemq/browse/SM-140?page=all ] Guillaume Nodet closed SM-140. -- Fix Version/s: 3.0-M2 (was: 3.0) Resolution: Fixed Add a GBean project to better integrate ServiceMix into Geronimo Key: SM-140 URL: https://issues.apache.org/activemq/browse/SM-140 Project: ServiceMix Issue Type: New Feature Components: geronimo Reporter: Guillaume Nodet Assigned To: Guillaume Nodet Fix For: 3.0-M2 -- 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: NoClassDefFoundError: org/apache/geronimo/deployment/plugin/ConfigIDExtractor
I haven't checked but assume this is a side effect of changing the pom dependency scopes in the deploy-jsr88 pom. thanks david jencks On Aug 10, 2006, at 10:03 PM, Jason Dillon wrote: Anyone know why this error gets spit out after the server boots? snip java.lang.NoClassDefFoundError: org/apache/geronimo/deployment/ plugin/ConfigIDExtractor at java.lang.ClassLoader.defineClass0(Native Method) at java.lang.ClassLoader.defineClass(ClassLoader.java:539) at java.security.SecureClassLoader.defineClass (SecureClassLoader.java:123) at org.apache.geronimo.kernel.classloader.JarFileClassLoader.access$200 (JarFileClassLoader.java:51) at org.apache.geronimo.kernel.classloader.JarFileClassLoader $6.run(JarFileClassLoader.java:275) at java.security.AccessController.doPrivileged(Native Method) at org.apache.geronimo.kernel.classloader.JarFileClassLoader.findClass (JarFileClassLoader.java:227) at org.apache.geronimo.kernel.config.MultiParentClassLoader.loadClass (MultiParentClassLoader.java:243) at java.lang.ClassLoader.loadClass(ClassLoader.java:235) at org.apache.geronimo.kernel.config.MultiParentClassLoader.loadClass (MultiParentClassLoader.java:227) at java.lang.ClassLoader.loadClass(ClassLoader.java:235) at org.apache.geronimo.kernel.config.MultiParentClassLoader.loadClass (MultiParentClassLoader.java:227) at java.lang.ClassLoader.loadClass(ClassLoader.java:235) at java.lang.ClassLoader.loadClassInternal(ClassLoader.java: 302) at org.apache.geronimo.deployment.hot.DirectoryMonitor.calculateModuleId( DirectoryMonitor.java:358) at org.apache.geronimo.deployment.hot.DirectoryMonitor.initialize (DirectoryMonitor.java:230) at org.apache.geronimo.deployment.hot.DirectoryMonitor.run (DirectoryMonitor.java:206) at java.lang.Thread.run(Thread.java:552) /snip --jason
Re: NoClassDefFoundError: org/apache/geronimo/deployment/plugin/ConfigIDExtractor
Maybe... it does spit up after the server lists the web contexts. If you have a chance to peek I'd appreciate it. --jason On Aug 10, 2006, at 11:12 PM, David Jencks wrote: I haven't checked but assume this is a side effect of changing the pom dependency scopes in the deploy-jsr88 pom. thanks david jencks On Aug 10, 2006, at 10:03 PM, Jason Dillon wrote: Anyone know why this error gets spit out after the server boots? snip java.lang.NoClassDefFoundError: org/apache/geronimo/deployment/ plugin/ConfigIDExtractor at java.lang.ClassLoader.defineClass0(Native Method) at java.lang.ClassLoader.defineClass(ClassLoader.java:539) at java.security.SecureClassLoader.defineClass (SecureClassLoader.java:123) at org.apache.geronimo.kernel.classloader.JarFileClassLoader.access $200(JarFileClassLoader.java:51) at org.apache.geronimo.kernel.classloader.JarFileClassLoader$6.run (JarFileClassLoader.java:275) at java.security.AccessController.doPrivileged(Native Method) at org.apache.geronimo.kernel.classloader.JarFileClassLoader.findClass (JarFileClassLoader.java:227) at org.apache.geronimo.kernel.config.MultiParentClassLoader.loadClass (MultiParentClassLoader.java:243) at java.lang.ClassLoader.loadClass(ClassLoader.java:235) at org.apache.geronimo.kernel.config.MultiParentClassLoader.loadClass (MultiParentClassLoader.java:227) at java.lang.ClassLoader.loadClass(ClassLoader.java:235) at org.apache.geronimo.kernel.config.MultiParentClassLoader.loadClass (MultiParentClassLoader.java:227) at java.lang.ClassLoader.loadClass(ClassLoader.java:235) at java.lang.ClassLoader.loadClassInternal (ClassLoader.java:302) at org.apache.geronimo.deployment.hot.DirectoryMonitor.calculateModuleId (DirectoryMonitor.java:358) at org.apache.geronimo.deployment.hot.DirectoryMonitor.initialize (DirectoryMonitor.java:230) at org.apache.geronimo.deployment.hot.DirectoryMonitor.run (DirectoryMonitor.java:206) at java.lang.Thread.run(Thread.java:552) /snip --jason
Build error on 1.1.1 branch geronimo rev 430687, openejb rev 2844?
Anyone know of any changes that could have broken it? I have tried the build on windows and solaris and get the same error. John + | configurations openejb Configuration for performing J2EE deployments | Memory: 49M/78M + DEPRECATED: the default goal should be specified in the build section of project.xml instead of maven.xml DEPRECATED: the default goal should be specified in the build section of project.xml instead of maven.xml build:end: Attempting to download openejb-builder-2.1.1-SNAPSHOT.jar. build:start: multiproject:install-callback: [echo] Running car:install for openejb Configuration for performing J2EE deployments car:prepare-plan: car:package: [delete] Deleting directory R:\1.1.1\configs\openejb-deployer\target\repository [mkdir] Created dir: R:\1.1.1\configs\openejb-deployer\target\repository Packaging configuration R:\1.1.1\configs\openejb-deployer\target\plan\plan.xml 13:26:47,140 ERROR [Deployer] Deployment failed due to java.lang.NoClassDefFoundError: org/apache/axis/Handler at java.lang.Class.forName0(Native Method) at java.lang.Class.forName(Class.java:141) at org.openejb.server.axis.WSContainerGBean.class$(WSContainerGBean.java:61) at org.openejb.server.axis.WSContainerGBean.clinit(WSContainerGBean.java:61) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at org.apache.geronimo.gbean.GBeanInfo.getGBeanInfo(GBeanInfo.java:70) at org.apache.geronimo.deployment.service.ServiceConfigBuilder.addGBeanData(ServiceConfigBuilder.java:295) at org.apache.geronimo.deployment.service.ServiceConfigBuilder.addGBeans(ServiceConfigBuilder.java:290) at org.apache.geronimo.deployment.service.ServiceConfigBuilder.buildConfiguration(ServiceConfigBuilder.java:256) at org.apache.geronimo.deployment.service.ServiceConfigBuilder.buildConfiguration(ServiceConfigBuilder.java:211) at org.apache.geronimo.deployment.service.ServiceConfigBuilder$$FastClassByCGLIB$$9f173be6.invoke(generated) at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53) at org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38) at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:122) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:817) at org.apache.geronimo.gbean.runtime.RawInvoker.invoke(RawInvoker.java:57) at org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke(RawOperationInvoker.java:35) at org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept(ProxyMethodInterceptor.java:96) at org.apache.geronimo.deployment.ConfigurationBuilder$$EnhancerByCGLIB$$2dd00db1.buildConfiguration(generated) at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:302) at org.apache.geronimo.deployment.Deployer$$FastClassByCGLIB$$734a235d.invoke(generated) at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53) at org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38) at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:122) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:852) at org.apache.geronimo.kernel.basic.BasicKernel.invoke(BasicKernel.java:239) at org.apache.geronimo.plugin.packaging.PackageBuilder.invokeDeployer(PackageBuilder.java:472) at org.apache.geronimo.plugin.packaging.PackageBuilder.execute(PackageBuilder.java:332) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at org.apache.geronimo.plugin.packaging.PackageBuilderShell.execute(PackageBuilderShell.java:291) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at org.apache.commons.jelly.impl.DynamicBeanTag.doTag(DynamicBeanTag.java:180) at org.apache.commons.jelly.impl.StaticTagScript.run(StaticTagScript.java:102) at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95) at
[jira] Created: (GERONIMO-2315) On Editing a database pool by changing the database name and restarting it fails to startup
On Editing a database pool by changing the database name and restarting it fails to startup --- Key: GERONIMO-2315 URL: http://issues.apache.org/jira/browse/GERONIMO-2315 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Components: console Affects Versions: 1.1.x Environment: All Supported Platforms Reporter: Manu T George Suppose I create an embedded derby Datasource pointing to an embedded DB TestDB and deploy it.It works w/o any problem. Now from the console if i edit the datasorce to point to another db and restart it fails with the exception below 12:31:32,231 ERROR [Servlet] Exception caught: javax.portlet.PortletException: Exception at org.apache.geronimo.console.configmanager.ConfigManagerPortlet.proces sAction(ConfigManagerPortlet.java:107) at org.apache.pluto.core.PortletServlet.dispatch(PortletServlet.java:229 ) at org.apache.pluto.core.PortletServlet.doGet(PortletServlet.java:158) at javax.servlet.http.HttpServlet.service(HttpServlet.java:595) at javax.servlet.http.HttpServlet.service(HttpServlet.java:688) at org.apache.pluto.core.PortletServlet.service(PortletServlet.java:153) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Appl icationFilterChain.java:252) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationF ilterChain.java:173) at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDisp atcher.java:672) at org.apache.catalina.core.ApplicationDispatcher.doInclude(ApplicationD ispatcher.java:574) at org.apache.catalina.core.ApplicationDispatcher.include(ApplicationDis patcher.java:499) at org.apache.pluto.invoker.impl.PortletInvokerImpl.invoke(PortletInvoke rImpl.java:120) at org.apache.pluto.invoker.impl.PortletInvokerImpl.action(PortletInvoke rImpl.java:68) at org.apache.pluto.PortletContainerImpl.processPortletAction(PortletCon tainerImpl.java:164) at org.apache.pluto.portalImpl.core.PortletContainerWrapperImpl.processP ortletAction(PortletContainerWrapperImpl.java:82) at org.apache.pluto.portalImpl.Servlet.doGet(Servlet.java:227) at javax.servlet.http.HttpServlet.service(HttpServlet.java:595) at javax.servlet.http.HttpServlet.service(HttpServlet.java:688) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Appl icationFilterChain.java:252) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationF ilterChain.java:173) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperV alve.java:213) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextV alve.java:178) at org.apache.geronimo.tomcat.valve.DefaultSubjectValve.invoke(DefaultSu bjectValve.java:52) at org.apache.catalina.authenticator.AuthenticatorBase.invoke(Authentica torBase.java:524) at org.apache.geronimo.tomcat.GeronimoStandardContext$SystemMethodValve. invoke(GeronimoStandardContext.java:342) at org.apache.geronimo.tomcat.valve.GeronimoBeforeAfterValve.invoke(Gero nimoBeforeAfterValve.java:31) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.j ava:126) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.j ava:105) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineVal ve.java:107) at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java: 541) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.jav a:148) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java :869) at org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.p rocessConnection(Http11BaseProtocol.java:667) at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpo int.java:527) at org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(LeaderFol lowerWorkerThread.java:80) at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadP ool.java:684) at java.lang.Thread.run(Unknown Source) Caused by: org.apache.geronimo.kernel.config.LifecycleException: start of consol e.dbpool/TestPool/1.0/rar failed at org.apache.geronimo.kernel.config.SimpleConfigurationManager.startCon figuration(SimpleConfigurationManager.java:529) at org.apache.geronimo.kernel.config.SimpleConfigurationManager.startCon figuration(SimpleConfigurationManager.java:493) at org.apache.geronimo.kernel.config.SimpleConfigurationManager$$FastCla ssByCGLIB$$ce77a924.invoke(generated) at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53) at
[jira] Created: (GERONIMO-2316) Unable to create a new Active IO listener from console
Unable to create a new Active IO listener from console -- Key: GERONIMO-2316 URL: http://issues.apache.org/jira/browse/GERONIMO-2316 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Components: ActiveMQ Affects Versions: 1.2 Environment: Geronimo 1.1 Reporter: Krishnakumar B I get the following exception when i create a New Active IO Listener from console 12:46:13,784 ERROR [JMSConnectorPortlet] Unable to process portlet action java.lang.NoSuchMethodError: org.activeio.ChannelFactory.bindAsynchChannel(Ljava/net/URI;)Lorg/activeio/AsynchChannelServer; at org.activemq.transport.activeio.ActiveIOTransportServerChannelFactory.createAsynchChannelServer(ActiveIOTransportServerChannelFactory.java:60) at org.activemq.transport.activeio.ActiveIOTransportServerChannelFactory.create(ActiveIOTransportServerChannelFactory.java:49) at org.activemq.transport.TransportServerChannelProvider.create(TransportServerChannelProvider.java:45) at org.activemq.broker.impl.BrokerConnectorImpl.createTransportServerChannel(BrokerConnectorImpl.java:425) at org.activemq.broker.impl.BrokerConnectorImpl.init(BrokerConnectorImpl.java:69) at org.activemq.gbean.ActiveMQConnectorGBean.createBrokerConnector(ActiveMQConnectorGBean.java:160) at org.activemq.gbean.ActiveMQConnectorGBean.doStart(ActiveMQConnectorGBean.java:128) at org.apache.geronimo.gbean.runtime.GBeanInstance.createInstance(GBeanInstance.java:981) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStart(GBeanInstanceState.java:267) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.start(GBeanInstanceState.java:102) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.startRecursive(GBeanInstanceState.java:124) at org.apache.geronimo.gbean.runtime.GBeanInstance.startRecursive(GBeanInstance.java:540) at org.apache.geronimo.kernel.basic.BasicKernel.startRecursiveGBean(BasicKernel.java:379) at org.apache.geronimo.kernel.basic.ProxyMethodInterceptor$StartRecursiveInvoke.invoke(ProxyMethodInterceptor.java:365) at org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept(ProxyMethodInterceptor.java:96) at org.activemq.gbean.ActiveMQConnector$$EnhancerByCGLIB$$c6a55a11.startRecursive(generated) at org.apache.geronimo.console.jmsmanager.server.JMSConnectorPortlet.processAction(JMSConnectorPortlet.java:104) at org.apache.pluto.core.PortletServlet.dispatch(PortletServlet.java:229) at org.apache.pluto.core.PortletServlet.doGet(PortletServlet.java:158) at javax.servlet.http.HttpServlet.service(HttpServlet.java:595) at javax.servlet.http.HttpServlet.service(HttpServlet.java:688) at org.apache.pluto.core.PortletServlet.service(PortletServlet.java:153) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173) at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:672) at org.apache.catalina.core.ApplicationDispatcher.doInclude(ApplicationDispatcher.java:574) at org.apache.catalina.core.ApplicationDispatcher.include(ApplicationDispatcher.java:499) at org.apache.pluto.invoker.impl.PortletInvokerImpl.invoke(PortletInvokerImpl.java:120) at org.apache.pluto.invoker.impl.PortletInvokerImpl.action(PortletInvokerImpl.java:68) at org.apache.pluto.PortletContainerImpl.processPortletAction(PortletContainerImpl.java:164) at org.apache.pluto.portalImpl.core.PortletContainerWrapperImpl.processPortletAction(PortletContainerWrapperImpl.java:82) at org.apache.pluto.portalImpl.Servlet.doGet(Servlet.java:227) at javax.servlet.http.HttpServlet.service(HttpServlet.java:595) at javax.servlet.http.HttpServlet.service(HttpServlet.java:688) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:178) at org.apache.geronimo.tomcat.valve.DefaultSubjectValve.invoke(DefaultSubjectValve.java:52) at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:524) at org.apache.geronimo.tomcat.GeronimoStandardContext$SystemMethodValve.invoke(GeronimoStandardContext.java:342) at
[jira] Created: (XBEAN-44) Problem in JarFileUrlStreamHandler
Problem in JarFileUrlStreamHandler --- Key: XBEAN-44 URL: http://issues.apache.org/jira/browse/XBEAN-44 Project: XBean Issue Type: Bug Components: server Reporter: Guillaume Nodet Fix For: 2.6 -- 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-2317) Unable to create a new peer listener from console
Unable to create a new peer listener from console - Key: GERONIMO-2317 URL: http://issues.apache.org/jira/browse/GERONIMO-2317 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Components: ActiveMQ Affects Versions: 1.2 Environment: Geronimo 1.1 Reporter: Krishnakumar B I get the following exception when i create a new peer listener from console 12:48:47,655 ERROR [GBeanInstanceState] Error while starting; GBean is now in the FAILED state: abstractName=geronimo/activemq-broker/1.1/car?JMSServer=ActiveMQ,ServiceModule=geronimo/activemq-broker/1.1/car,j2eeType=GBean,name=NewPeer javax.jms.JMSException: Could not load protocol: peer. Reason: java.lang.ClassNotFoundException: org.activemq.transport.peer.PeerTransportServerChannelFactory in classloader geronimo/activemq-broker/1.1/car at org.activemq.transport.TransportServerChannelProvider.createJMSexception(TransportServerChannelProvider.java:85) at org.activemq.transport.TransportServerChannelProvider.getFactory(TransportServerChannelProvider.java:79) at org.activemq.transport.TransportServerChannelProvider.create(TransportServerChannelProvider.java:45) at org.activemq.broker.impl.BrokerConnectorImpl.createTransportServerChannel(BrokerConnectorImpl.java:425) at org.activemq.broker.impl.BrokerConnectorImpl.init(BrokerConnectorImpl.java:69) at org.activemq.gbean.ActiveMQConnectorGBean.createBrokerConnector(ActiveMQConnectorGBean.java:160) at org.activemq.gbean.ActiveMQConnectorGBean.doStart(ActiveMQConnectorGBean.java:128) at org.apache.geronimo.gbean.runtime.GBeanInstance.createInstance(GBeanInstance.java:981) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStart(GBeanInstanceState.java:267) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.start(GBeanInstanceState.java:102) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.startRecursive(GBeanInstanceState.java:124) at org.apache.geronimo.gbean.runtime.GBeanInstance.startRecursive(GBeanInstance.java:540) at org.apache.geronimo.kernel.basic.BasicKernel.startRecursiveGBean(BasicKernel.java:379) at org.apache.geronimo.kernel.basic.ProxyMethodInterceptor$StartRecursiveInvoke.invoke(ProxyMethodInterceptor.java:365) at org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept(ProxyMethodInterceptor.java:96) at org.activemq.gbean.ActiveMQConnector$$EnhancerByCGLIB$$c6a55a11.startRecursive(generated) at org.apache.geronimo.console.jmsmanager.server.JMSConnectorPortlet.processAction(JMSConnectorPortlet.java:104) at org.apache.pluto.core.PortletServlet.dispatch(PortletServlet.java:229) at org.apache.pluto.core.PortletServlet.doGet(PortletServlet.java:158) at javax.servlet.http.HttpServlet.service(HttpServlet.java:595) at javax.servlet.http.HttpServlet.service(HttpServlet.java:688) at org.apache.pluto.core.PortletServlet.service(PortletServlet.java:153) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173) at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:672) at org.apache.catalina.core.ApplicationDispatcher.doInclude(ApplicationDispatcher.java:574) at org.apache.catalina.core.ApplicationDispatcher.include(ApplicationDispatcher.java:499) at org.apache.pluto.invoker.impl.PortletInvokerImpl.invoke(PortletInvokerImpl.java:120) at org.apache.pluto.invoker.impl.PortletInvokerImpl.action(PortletInvokerImpl.java:68) at org.apache.pluto.PortletContainerImpl.processPortletAction(PortletContainerImpl.java:164) at org.apache.pluto.portalImpl.core.PortletContainerWrapperImpl.processPortletAction(PortletContainerWrapperImpl.java:82) at org.apache.pluto.portalImpl.Servlet.doGet(Servlet.java:227) at javax.servlet.http.HttpServlet.service(HttpServlet.java:595) at javax.servlet.http.HttpServlet.service(HttpServlet.java:688) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:178) at org.apache.geronimo.tomcat.valve.DefaultSubjectValve.invoke(DefaultSubjectValve.java:52) at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:524) at
[jira] Created: (GERONIMO-2318) Database path validation not present
Database path validation not present - Key: GERONIMO-2318 URL: http://issues.apache.org/jira/browse/GERONIMO-2318 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Components: console Affects Versions: 1.1.x Environment: All Supported Platforms Reporter: Manu T George On deploying pools referring to derby databases. Deployment is shown to be sucessful but the pool does not start. Steps are given below (1)Logged into Administrative Console. (2)Clicked Database Pools. (3) Next, clicked Create a new database pool: Using the Geronimo database pool wizard. (4)Entered Name of Database Pool: CPRO and Database Type: Derby Embedded. Then clicked Next. (5)Thereafter entered the following:- JDBC Driver Class: org.apache.derby.jdbc.EmbeddedDriver Driver JAR: org.apache.derby/derby/10.1.2.ibm/jar DB Username: cpro DB Password: cpro Database: c:\cprodb\cprodb_COSMO\csdb Then clicked Next. (5)The next screen showed:- JDBC Connection URL: jdbc:derby:c:cprodbcprodb_COSMOcsdb (This being incorrect, it was changed to jdbc:derby:c:\cprodb\cprodb_COSMO\csdb). (6)Driver Status: Loaded successfully (7)Now clicked Test Connection. This showed:- Test Result: Connected to Apache Derby 10.1.2.4 (8)Finally clicked Deploy It appears that this step was successful because:- (i)The DOS window showed Deployment completed successfully! Even though this happens when we refer to this DB Pool in an application error occurs. Thus there is no handling of '\' character in these two fields Giving '/' instead of '\' solves 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] Updated: (GERONIMO-2317) Unable to create a new peer listener from console
[ http://issues.apache.org/jira/browse/GERONIMO-2317?page=all ] Krishnakumar B updated GERONIMO-2317: - Component/s: console Unable to create a new peer listener from console - Key: GERONIMO-2317 URL: http://issues.apache.org/jira/browse/GERONIMO-2317 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: ActiveMQ, console Affects Versions: 1.2 Environment: Geronimo 1.1 Reporter: Krishnakumar B I get the following exception when i create a new peer listener from console 12:48:47,655 ERROR [GBeanInstanceState] Error while starting; GBean is now in the FAILED state: abstractName=geronimo/activemq-broker/1.1/car?JMSServer=ActiveMQ,ServiceModule=geronimo/activemq-broker/1.1/car,j2eeType=GBean,name=NewPeer javax.jms.JMSException: Could not load protocol: peer. Reason: java.lang.ClassNotFoundException: org.activemq.transport.peer.PeerTransportServerChannelFactory in classloader geronimo/activemq-broker/1.1/car at org.activemq.transport.TransportServerChannelProvider.createJMSexception(TransportServerChannelProvider.java:85) at org.activemq.transport.TransportServerChannelProvider.getFactory(TransportServerChannelProvider.java:79) at org.activemq.transport.TransportServerChannelProvider.create(TransportServerChannelProvider.java:45) at org.activemq.broker.impl.BrokerConnectorImpl.createTransportServerChannel(BrokerConnectorImpl.java:425) at org.activemq.broker.impl.BrokerConnectorImpl.init(BrokerConnectorImpl.java:69) at org.activemq.gbean.ActiveMQConnectorGBean.createBrokerConnector(ActiveMQConnectorGBean.java:160) at org.activemq.gbean.ActiveMQConnectorGBean.doStart(ActiveMQConnectorGBean.java:128) at org.apache.geronimo.gbean.runtime.GBeanInstance.createInstance(GBeanInstance.java:981) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStart(GBeanInstanceState.java:267) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.start(GBeanInstanceState.java:102) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.startRecursive(GBeanInstanceState.java:124) at org.apache.geronimo.gbean.runtime.GBeanInstance.startRecursive(GBeanInstance.java:540) at org.apache.geronimo.kernel.basic.BasicKernel.startRecursiveGBean(BasicKernel.java:379) at org.apache.geronimo.kernel.basic.ProxyMethodInterceptor$StartRecursiveInvoke.invoke(ProxyMethodInterceptor.java:365) at org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept(ProxyMethodInterceptor.java:96) at org.activemq.gbean.ActiveMQConnector$$EnhancerByCGLIB$$c6a55a11.startRecursive(generated) at org.apache.geronimo.console.jmsmanager.server.JMSConnectorPortlet.processAction(JMSConnectorPortlet.java:104) at org.apache.pluto.core.PortletServlet.dispatch(PortletServlet.java:229) at org.apache.pluto.core.PortletServlet.doGet(PortletServlet.java:158) at javax.servlet.http.HttpServlet.service(HttpServlet.java:595) at javax.servlet.http.HttpServlet.service(HttpServlet.java:688) at org.apache.pluto.core.PortletServlet.service(PortletServlet.java:153) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173) at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:672) at org.apache.catalina.core.ApplicationDispatcher.doInclude(ApplicationDispatcher.java:574) at org.apache.catalina.core.ApplicationDispatcher.include(ApplicationDispatcher.java:499) at org.apache.pluto.invoker.impl.PortletInvokerImpl.invoke(PortletInvokerImpl.java:120) at org.apache.pluto.invoker.impl.PortletInvokerImpl.action(PortletInvokerImpl.java:68) at org.apache.pluto.PortletContainerImpl.processPortletAction(PortletContainerImpl.java:164) at org.apache.pluto.portalImpl.core.PortletContainerWrapperImpl.processPortletAction(PortletContainerWrapperImpl.java:82) at org.apache.pluto.portalImpl.Servlet.doGet(Servlet.java:227) at javax.servlet.http.HttpServlet.service(HttpServlet.java:595) at javax.servlet.http.HttpServlet.service(HttpServlet.java:688) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:178) at
[jira] Created: (GERONIMO-2319) Unable to create a new OpenWire Listener from console
Unable to create a new OpenWire Listener from console - Key: GERONIMO-2319 URL: http://issues.apache.org/jira/browse/GERONIMO-2319 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Components: ActiveMQ, console Affects Versions: 1.2 Environment: Geronimo 1.1 Reporter: Krishnakumar B I am unable to create a new openwire listener from console. I get the following exception 12:51:25,081 ERROR [GBeanInstanceState] Error while starting; GBean is now in the FAILED state: abstractName=geronimo/activemq-broker/1.1/car?JMSServer=ActiveMQ,ServiceModule=geronimo/activemq-broker/1.1/car,j2eeType=GBean,name=NewOpenWire javax.jms.JMSException: Could not load protocol: openwire. Reason: java.lang.ClassNotFoundException: org.activemq.transport.openwire.OpenWireTransportServerChannelFactory in classloader geronimo/activemq-broker/1.1/car at org.activemq.transport.TransportServerChannelProvider.createJMSexception(TransportServerChannelProvider.java:85) at org.activemq.transport.TransportServerChannelProvider.getFactory(TransportServerChannelProvider.java:79) at org.activemq.transport.TransportServerChannelProvider.create(TransportServerChannelProvider.java:45) at org.activemq.broker.impl.BrokerConnectorImpl.createTransportServerChannel(BrokerConnectorImpl.java:425) at org.activemq.broker.impl.BrokerConnectorImpl.init(BrokerConnectorImpl.java:69) at org.activemq.gbean.ActiveMQConnectorGBean.createBrokerConnector(ActiveMQConnectorGBean.java:160) at org.activemq.gbean.ActiveMQConnectorGBean.doStart(ActiveMQConnectorGBean.java:128) at org.apache.geronimo.gbean.runtime.GBeanInstance.createInstance(GBeanInstance.java:981) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStart(GBeanInstanceState.java:267) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.start(GBeanInstanceState.java:102) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.startRecursive(GBeanInstanceState.java:124) at org.apache.geronimo.gbean.runtime.GBeanInstance.startRecursive(GBeanInstance.java:540) at org.apache.geronimo.kernel.basic.BasicKernel.startRecursiveGBean(BasicKernel.java:379) at org.apache.geronimo.kernel.basic.ProxyMethodInterceptor$StartRecursiveInvoke.invoke(ProxyMethodInterceptor.java:365) at org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept(ProxyMethodInterceptor.java:96) at org.activemq.gbean.ActiveMQConnector$$EnhancerByCGLIB$$c6a55a11.startRecursive(generated) at org.apache.geronimo.console.jmsmanager.server.JMSConnectorPortlet.processAction(JMSConnectorPortlet.java:83) at org.apache.pluto.core.PortletServlet.dispatch(PortletServlet.java:229) at org.apache.pluto.core.PortletServlet.doGet(PortletServlet.java:158) at javax.servlet.http.HttpServlet.service(HttpServlet.java:595) at javax.servlet.http.HttpServlet.service(HttpServlet.java:688) at org.apache.pluto.core.PortletServlet.service(PortletServlet.java:153) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173) at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:672) at org.apache.catalina.core.ApplicationDispatcher.doInclude(ApplicationDispatcher.java:574) at org.apache.catalina.core.ApplicationDispatcher.include(ApplicationDispatcher.java:499) at org.apache.pluto.invoker.impl.PortletInvokerImpl.invoke(PortletInvokerImpl.java:120) at org.apache.pluto.invoker.impl.PortletInvokerImpl.action(PortletInvokerImpl.java:68) at org.apache.pluto.PortletContainerImpl.processPortletAction(PortletContainerImpl.java:164) at org.apache.pluto.portalImpl.core.PortletContainerWrapperImpl.processPortletAction(PortletContainerWrapperImpl.java:82) at org.apache.pluto.portalImpl.Servlet.doGet(Servlet.java:227) at javax.servlet.http.HttpServlet.service(HttpServlet.java:595) at javax.servlet.http.HttpServlet.service(HttpServlet.java:688) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:178) at org.apache.geronimo.tomcat.valve.DefaultSubjectValve.invoke(DefaultSubjectValve.java:52) at
[jira] Updated: (GERONIMO-1701) Improve the EJB Server portlet
[ http://issues.apache.org/jira/browse/GERONIMO-1701?page=all ] Chris Cardona updated GERONIMO-1701: Attachment: ejbmgrportlet-G1.1.1.patch ejbmgrportlet-openejb-G1.1.1.patch viewEJBModules.jpg Updated the patch to work on geronimo\branches\1.1.1 source: 1. ejbmgrportlet-G1.1.1.patch - the Geronimo patch file 2. ejbmgrportlet-openejb-G1.1.1.patch - the OpenEJB patch file 3. viewEJBModules.jpg - sample view EJB modules snapshot Please provide comments and suggestions. Thanks. Improve the EJB Server portlet -- Key: GERONIMO-1701 URL: http://issues.apache.org/jira/browse/GERONIMO-1701 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: console, OpenEJB Affects Versions: 1.1, 1.2 Reporter: Chris Cardona Attachments: ejbMgrPortlet-G.patch, ejbmgrportlet-G1.1.1.patch, ejbmgrportlet-openejb-G1.1.1.patch, ejbMgrPortlet-OpenEJB.patch, ejbMgrPortlet-Snapshot.zip, viewEJBModules.jpg Improve the EJB Server portlet to do the ff.: 1. View a list of deployed EJB modules in the EJB server including basic statistics of the different EJB types. 2. View a list of deployed EJBs of an EJB module including basic statistics of the different EJB types. 3. View the deployment descriptor of an EJB module. 4. View a specific EJB to get basic configuration info Note: This portlet can still be enhanced to do other stuff. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (AMQ-874) The Activemq-cpp example code no longer builds.
The Activemq-cpp example code no longer builds. --- Key: AMQ-874 URL: https://issues.apache.org/activemq/browse/AMQ-874 Project: ActiveMQ Issue Type: Bug Components: CMS (C++ client) Reporter: Timothy Bish Assigned To: Timothy Bish Priority: Minor Code in the Activemq-cpp example is no longer up to date with the latest version. We need to clean this code up to match the samll changes in the CMS interface. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Assigned: (GERONIMODEVTOOLS-71) Geronimo publish failed with javax.naming.NoInitialContextException
[ http://issues.apache.org/jira/browse/GERONIMODEVTOOLS-71?page=all ] Sachin Patel reassigned GERONIMODEVTOOLS-71: Assignee: Sachin Patel Geronimo publish failed with javax.naming.NoInitialContextException --- Key: GERONIMODEVTOOLS-71 URL: http://issues.apache.org/jira/browse/GERONIMODEVTOOLS-71 Project: Geronimo-Devtools Issue Type: Bug Components: eclipse-plugin Environment: WTP 1.0.1 + Geronimo 1.0 plugin + Geronimo 1.0 server Starting Eclipse with IBM JRE 1.4.2 J2RE 1.4.2 IBM Windows 32 build cn142-20050609 Reporter: Kathy Chan Assigned To: Sachin Patel Fix For: 1.x I had an EAR that's deployed to a Geronimo server. After I changed a Java file and re-publish to the server using server tooling popup menu on the server, I got the Publish Failed error. Here's the application console log: !SUBENTRY 1 org.apache.geronimo.devtools.eclipse.core 4 0 2006-03-07 13:08:59.630 !MESSAGE Connection to deployment manager failed. See .log for details. !STACK 0 javax.enterprise.deploy.spi.exceptions.DeploymentManagerCreationException: javax.naming.NoInitialCon textException: Cannot instantiate class: org.apache.naming.java.javaURLContextFactory [Root exceptio n is java.lang.ClassNotFoundException: org.apache.naming.java.javaURLContextFactory] at org.apache.geronimo.deployment.plugin.factories.DeploymentFactoryImpl.getDeploymentManage r(DeploymentFactoryImpl.java:132) at javax.enterprise.deploy.shared.factories.DeploymentFactoryManager.getDeploymentManager(De ploymentFactoryManager.java:109) at org.apache.geronimo.core.GeronimoConnectionFactory.getDeploymentManager(GeronimoConnectio nFactory.java:54) at org.apache.geronimo.core.commands.DeploymentCommandFactory.getDeploymentManager(Deploymen tCommandFactory.java:111) at org.apache.geronimo.core.commands.DeploymentCommandFactory.createRedeployCommand(Deployme ntCommandFactory.java:87) at org.apache.geronimo.core.internal.GeronimoServerBehaviour.reDeploy(GeronimoServerBehaviou r.java:361) at org.apache.geronimo.core.internal.GeronimoServerBehaviour.doRedeploy(GeronimoServerBehavi our.java:282) at org.apache.geronimo.core.internal.GeronimoServerBehaviour.invokeCommand(GeronimoServerBeh aviour.java:234) at org.apache.geronimo.core.internal.GeronimoServerBehaviour.publishModule(GeronimoServerBeh aviour.java:217) at org.eclipse.wst.server.core.model.ServerBehaviourDelegate.publishModule(ServerBehaviourDe legate.java:672) at org.eclipse.wst.server.core.model.ServerBehaviourDelegate.publishModules(ServerBehaviourD elegate.java:752) at org.eclipse.wst.server.core.model.ServerBehaviourDelegate.publish(ServerBehaviourDelegate .java:610) at org.eclipse.wst.server.core.internal.Server.doPublish(Server.java:800) at org.eclipse.wst.server.core.internal.Server.publish(Server.java:788) at org.eclipse.wst.server.core.internal.PublishServerJob.run(PublishServerJob.java:145) at org.eclipse.core.internal.jobs.Worker.run(Worker.java:58) Caused by: java.io.IOException: javax.naming.NoInitialContextException: Cannot instantiate class: or g.apache.naming.java.javaURLContextFactory [Root exception is java.lang.ClassNotFoundException: org. apache.naming.java.javaURLContextFactory] at mx4j.remote.resolver.rmi.Resolver.lookupStubInJNDI(Resolver.java:100) at mx4j.remote.resolver.rmi.Resolver.lookupRMIServerStub(Resolver.java:72) at mx4j.remote.resolver.rmi.Resolver.lookupClient(Resolver.java:52) at javax.management.remote.rmi.RMIConnector.connect(RMIConnector.java:119) at javax.management.remote.JMXConnectorFactory.connect(JMXConnectorFactory.java:38) at org.apache.geronimo.deployment.plugin.factories.DeploymentFactoryImpl.getDeploymentManage r(DeploymentFactoryImpl.java:125) at javax.enterprise.deploy.shared.factories.DeploymentFactoryManager.getDeploymentManager(De ploymentFactoryManager.java:109) at org.apache.geronimo.core.GeronimoConnectionFactory.getDeploymentManager(GeronimoConnectio nFactory.java:54) at org.apache.geronimo.core.commands.DeploymentCommandFactory.getDeploymentManager(Deploymen tCommandFactory.java:111) at org.apache.geronimo.core.commands.DeploymentCommandFactory.createRedeployCommand(Deployme ntCommandFactory.java:87) at org.apache.geronimo.core.internal.GeronimoServerBehaviour.reDeploy(GeronimoServerBehaviou r.java:361) at org.apache.geronimo.core.internal.GeronimoServerBehaviour.doRedeploy(GeronimoServerBehavi our.java:282) at
[jira] Closed: (GERONIMODEVTOOLS-71) Geronimo publish failed with javax.naming.NoInitialContextException
[ http://issues.apache.org/jira/browse/GERONIMODEVTOOLS-71?page=all ] Sachin Patel closed GERONIMODEVTOOLS-71. Resolution: Fixed Geronimo publish failed with javax.naming.NoInitialContextException --- Key: GERONIMODEVTOOLS-71 URL: http://issues.apache.org/jira/browse/GERONIMODEVTOOLS-71 Project: Geronimo-Devtools Issue Type: Bug Components: eclipse-plugin Environment: WTP 1.0.1 + Geronimo 1.0 plugin + Geronimo 1.0 server Starting Eclipse with IBM JRE 1.4.2 J2RE 1.4.2 IBM Windows 32 build cn142-20050609 Reporter: Kathy Chan Assigned To: Sachin Patel Fix For: 1.x I had an EAR that's deployed to a Geronimo server. After I changed a Java file and re-publish to the server using server tooling popup menu on the server, I got the Publish Failed error. Here's the application console log: !SUBENTRY 1 org.apache.geronimo.devtools.eclipse.core 4 0 2006-03-07 13:08:59.630 !MESSAGE Connection to deployment manager failed. See .log for details. !STACK 0 javax.enterprise.deploy.spi.exceptions.DeploymentManagerCreationException: javax.naming.NoInitialCon textException: Cannot instantiate class: org.apache.naming.java.javaURLContextFactory [Root exceptio n is java.lang.ClassNotFoundException: org.apache.naming.java.javaURLContextFactory] at org.apache.geronimo.deployment.plugin.factories.DeploymentFactoryImpl.getDeploymentManage r(DeploymentFactoryImpl.java:132) at javax.enterprise.deploy.shared.factories.DeploymentFactoryManager.getDeploymentManager(De ploymentFactoryManager.java:109) at org.apache.geronimo.core.GeronimoConnectionFactory.getDeploymentManager(GeronimoConnectio nFactory.java:54) at org.apache.geronimo.core.commands.DeploymentCommandFactory.getDeploymentManager(Deploymen tCommandFactory.java:111) at org.apache.geronimo.core.commands.DeploymentCommandFactory.createRedeployCommand(Deployme ntCommandFactory.java:87) at org.apache.geronimo.core.internal.GeronimoServerBehaviour.reDeploy(GeronimoServerBehaviou r.java:361) at org.apache.geronimo.core.internal.GeronimoServerBehaviour.doRedeploy(GeronimoServerBehavi our.java:282) at org.apache.geronimo.core.internal.GeronimoServerBehaviour.invokeCommand(GeronimoServerBeh aviour.java:234) at org.apache.geronimo.core.internal.GeronimoServerBehaviour.publishModule(GeronimoServerBeh aviour.java:217) at org.eclipse.wst.server.core.model.ServerBehaviourDelegate.publishModule(ServerBehaviourDe legate.java:672) at org.eclipse.wst.server.core.model.ServerBehaviourDelegate.publishModules(ServerBehaviourD elegate.java:752) at org.eclipse.wst.server.core.model.ServerBehaviourDelegate.publish(ServerBehaviourDelegate .java:610) at org.eclipse.wst.server.core.internal.Server.doPublish(Server.java:800) at org.eclipse.wst.server.core.internal.Server.publish(Server.java:788) at org.eclipse.wst.server.core.internal.PublishServerJob.run(PublishServerJob.java:145) at org.eclipse.core.internal.jobs.Worker.run(Worker.java:58) Caused by: java.io.IOException: javax.naming.NoInitialContextException: Cannot instantiate class: or g.apache.naming.java.javaURLContextFactory [Root exception is java.lang.ClassNotFoundException: org. apache.naming.java.javaURLContextFactory] at mx4j.remote.resolver.rmi.Resolver.lookupStubInJNDI(Resolver.java:100) at mx4j.remote.resolver.rmi.Resolver.lookupRMIServerStub(Resolver.java:72) at mx4j.remote.resolver.rmi.Resolver.lookupClient(Resolver.java:52) at javax.management.remote.rmi.RMIConnector.connect(RMIConnector.java:119) at javax.management.remote.JMXConnectorFactory.connect(JMXConnectorFactory.java:38) at org.apache.geronimo.deployment.plugin.factories.DeploymentFactoryImpl.getDeploymentManage r(DeploymentFactoryImpl.java:125) at javax.enterprise.deploy.shared.factories.DeploymentFactoryManager.getDeploymentManager(De ploymentFactoryManager.java:109) at org.apache.geronimo.core.GeronimoConnectionFactory.getDeploymentManager(GeronimoConnectio nFactory.java:54) at org.apache.geronimo.core.commands.DeploymentCommandFactory.getDeploymentManager(Deploymen tCommandFactory.java:111) at org.apache.geronimo.core.commands.DeploymentCommandFactory.createRedeployCommand(Deployme ntCommandFactory.java:87) at org.apache.geronimo.core.internal.GeronimoServerBehaviour.reDeploy(GeronimoServerBehaviou r.java:361) at org.apache.geronimo.core.internal.GeronimoServerBehaviour.doRedeploy(GeronimoServerBehavi our.java:282) at
Deadlock on 4.0.2
I sometime have deadlocks while running junit tests that involve ActiveMQ. Following is a stack trace i dumped. As you can see, the two last threads are deadlocked because of the MutexTransport. This cause the first thread (main thread) to hang forever. Thread [main] (Suspended) MutexTransport.oneway(Command) line: 44 == MutexTransport (id=292) ResponseCorrelator.oneway(Command) line: 58 ManagedTransportConnection(TransportConnection).dispatch(Command) line: 211 ManagedTransportConnection(AbstractConnection).processDispatch(Command) line: 628 ManagedTransportConnection(AbstractConnection).dispatchSync(Command) line: 605 TopicSubscription.dispatch(MessageReference) line: 315 TopicSubscription.add(MessageReference) line: 74 SimpleDispatchPolicy.dispatch(ConnectionContext, MessageReference, MessageEvaluationContext, List) line: 50 Topic.dispatch(ConnectionContext, Message) line: 443 Topic.send(ConnectionContext, Message) line: 254 ManagedTopicRegion(AbstractRegion).send(ConnectionContext, Message) line: 225 ManagedRegionBroker(RegionBroker).send(ConnectionContext, Message) line: 345 TransactionBroker.send(ConnectionContext, Message) line: 192 AdvisoryBroker(BrokerFilter).send(ConnectionContext, Message) line: 113 CompositeDestinationBroker.send(ConnectionContext, Message) line: 97 BrokerService$2(MutableBrokerFilter).send(ConnectionContext, Message) line: 126 ManagedTransportConnection(AbstractConnection).processMessage(Message) line: 377 ActiveMQObjectMessage(ActiveMQMessage).visit(CommandVisitor) line: 590 ManagedTransportConnection(AbstractConnection).service(Command) line: 226 TransportConnection$1.onCommand(Command) line: 62 ResponseCorrelator.onCommand(Command) line: 91 MutexTransport(TransportFilter).onCommand(Command) line: 63 VMTransportServer$1(VMTransport).oneway(Command) line: 76 MutexTransport.oneway(Command) line: 44 = MutexTransport (id=314) ResponseCorrelator.oneway(Command) line: 58 ActiveMQConnection.asyncSendPacket(Command) line: 1092 ActiveMQSession.send(ActiveMQMessageProducer, ActiveMQDestination, Message, int, int, long) line: 1553 ActiveMQMessageProducer.send(Destination, Message, int, int, long) line: 462 ActiveMQMessageProducer.send(Message) line: 356 JCAFlow.sendJmsMessage(Destination, Serializable, boolean, boolean) line: 707 JCAFlow.onInternalEndpointUnregistered(EndpointEvent, boolean) line: 462 JCAFlow$1.internalEndpointUnregistered(EndpointEvent) line: 245 EndpointRegistry.fireEvent(ServiceEndpoint, int) line: 575 EndpointRegistry.unregisterInternalEndpoint(ComponentContext, InternalEndpoint) line: 199 Registry.deactivateEndpoint(ComponentContext, InternalEndpoint) line: 205 ComponentContextImpl.deactivateEndpoint(ServiceEndpoint) line: 157 ReceiverComponent(PojoSupport).shutDown() line: 103 ComponentMBeanImpl.doShutDown() line: 335 ComponentRegistry.shutDown() line: 105 Registry.shutDown() line: 142 SpringJBIContainer(JBIContainer).shutDown() line: 601 SpringJBIContainer.destroy() line: 184 DisposableBeanAdapter.destroy() line: 97 DefaultListableBeanFactory(AbstractBeanFactory).destroyBean(String, Object) line: 1159 DefaultListableBeanFactory(AbstractBeanFactory).destroyDisposableBean(String) line: 1131 DefaultListableBeanFactory(AbstractBeanFactory).destroySingletons() line: 660 ClassPathXmlApplicationContext(AbstractApplicationContext).doClose() line: 594 ClassPathXmlApplicationContext(AbstractApplicationContext).close() line: 563 ClassPathXmlApplicationContext(AbstractApplicationContext).destroy() line: 552 JmsSpringJcaTest(SpringTestSupport).tearDown() line: 66 JmsSpringJcaTest.tearDown() line: 52 JmsSpringJcaTest(TestCase).runBare() line: 130 TestResult$1.protect() line: 106 TestResult.runProtected(Test, Protectable) line: 124 TestResult.run(TestCase) line: 109 JmsSpringJcaTest(TestCase).run(TestResult) line: 118 TestSuite.runTest(Test, TestResult) line: 208 TestSuite.run(TestResult) line: 203 JUnit3TestReference.run(TestExecution) line: 128 TestExecution.run(ITestReference[]) line: 38 RemoteTestRunner.runTests(String[], String, TestExecution) line: 460 RemoteTestRunner.runTests(TestExecution) line: 673 RemoteTestRunner.run() line: 386 RemoteTestRunner.main(String[]) line: 196 Thread [ActiveMQ Session Task] (Suspended) MutexTransport.oneway(Command) line: 44 == MutexTransport (id=419) ResponseCorrelator.oneway(Command) line: 58 ActiveMQConnection.asyncSendPacket(Command) line: 1092 ActiveMQSession.init(ActiveMQConnection, SessionId, int, boolean, boolean) line: 227
[jira] Updated: (GERONIMO-2308) All Geronimo JARs should include a NOTICE.txt file in addition to the LICENSE.txt file
[ http://issues.apache.org/jira/browse/GERONIMO-2308?page=all ] Prasad Kashyap updated GERONIMO-2308: - Patch Info: [Patch Available] All Geronimo JARs should include a NOTICE.txt file in addition to the LICENSE.txt file -- Key: GERONIMO-2308 URL: http://issues.apache.org/jira/browse/GERONIMO-2308 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: buildsystem Affects Versions: 1.0, 1.1 Reporter: John Sisson Assigned To: John Sisson Priority: Blocker Fix For: 1.1.1 Attachments: activation-converter.patch, core-installersupport.patch, j2ee-management.patch, naming-tomcat.patch, tomcatbuilder-webservices.patch Currently Geronimo jars (e.g. the JARs for each application/module) do not contain a NOTICE.txt file under the META-INF directory. The NOTICE.txt files in modules needs to contain attributions that are relevant for that module (not Geronimo as a whole). For example, if the module has a dependency on a library that has a license requiring attributions upon use of the library (e.g. it has wording Redistribution and use of this software in the library license) then the module using the library should contain the attribution in the NOTICE.txt file. Whilst reviewing attributions, the LICENSE.txt files for the modules and applications should also be updated to include the relevant licenses. The following is a checklist to help track what has been done, in case someone wants to help out :-) (x) = not done (?) = partially done (/) = done ||trunk||1.1||1.1.1||Notes|| |(x)|(/)|(/)|applications\console-core| Notice needs IBM attribution?| |(x)|(/)|(/)|applications\console-ear|Notice needs IBM attribution?| |(x)|(/)|(/)|applications\console-framework|Notice needs IBM attribution?| |(x)|(/)|(/)|applications\console-standard|Notice needs IBM attribution?| |(x)|(/)|(/)|applications\daytrader| | |(x)|(/)|(/)|applications\demo| | |(x)|(/)|(/)|applications\ldap-realm-demo| | |(x)|(/)|(/)|applications\magicGball| | |(x)|(/)|(/)|applications\project.properties| | |(x)|(/)|(/)|applications\remote-deploy| | |(x)|(/)|(/)|applications\remote-deploy-lib| | |(x)|(/)|(/)|applications\uddi-db| | |(x)|(/)|(/)|applications\uddi-server| | |(x)|(/)|(/)|applications\welcome| | |(?)|(x)|(x)|modules\activation| | |(x)|(x)|(x)|modules\activemq-embedded-rar| | |(?)|(x)|(x)|modules\axis| | |(?)|(x)|(x)|modules\axis-builder| | |(?)|(x)|(x)|modules\client| | |(?)|(x)|(x)|modules\client-builder| | |(?)|(x)|(x)|modules\common| | |(?)|(x)|(x)|modules\connector| | |(?)|(x)|(x)|modules\connector-builder| | |(/)|(x)|(x)|modules\console-web| (Won't fix in trunk) | |(?)|(x)|(x)|modules\converter| | |(?)|(x)|(x)|modules\core| | |(?)|(x)|(x)|modules\deploy-config| | |(?)|(x)|(x)|modules\deploy-jsr88| | |(?)|(x)|(x)|modules\deploy-tool| | |(?)|(x)|(x)|modules\deployment| | |(?)|(x)|(x)|modules\derby| | |(?)|(x)|(x)|modules\directory| | |(?)|(x)|(x)|modules\hot-deploy| | |(?)|(x)|(x)|modules\installer-processing| | |(?)|(x)|(x)|modules\installer-support| | |(?)|(x)|(x)|modules\j2ee| | |(?)|(x)|(x)|modules\j2ee-builder| | |(?)|(x)|(x)|modules\j2ee-schema| | |(/)|(x)|(x)|modules\javamail-transport| (No longer in trunk) | |(?)|(x)|(x)|modules\jetty| | |(?)|(x)|(x)|modules\jetty-builder| | |(?)|(x)|(x)|modules\jmx-remoting| | |(?)|(x)|(x)|modules\kernel| | |(?)|(x)|(x)|modules\mail| | |(?)|(x)|(x)|modules\management| | |(?)|(x)|(x)|modules\naming| | |(?)|(x)|(x)|modules\naming-builder| | |(/)|(x)|(x)|modules\scripts| (Not distributed) | |(?)|(x)|(x)|modules\security| | |(?)|(x)|(x)|modules\security-builder| | |(?)|(x)|(x)|modules\service-builder| | |(?)|(x)|(x)|modules\system| | |(?)|(x)|(x)|modules\test-ddbean| | |(?)|(x)|(x)|modules\timer| | |(?)|(x)|(x)|modules\tomcat| | |(?)|(x)|(x)|modules\tomcat-builder| | |(?)|(x)|(x)|modules\transaction| | |(?)|(x)|(x)|modules\upgrade| | |(?)|(x)|(x)|modules\util| | |(?)|(x)|(x)|modules\web-builder| | |(?)|(x)|(x)|modules\webservices| | -- 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: NoClassDefFoundError: org/apache/geronimo/deployment/plugin/ConfigIDExtractor
Jason, http://www.mail-archive.com/dev@geronimo.apache.org/msg29265.html Cheers Prasad On 8/11/06, Jason Dillon [EMAIL PROTECTED] wrote: Anyone know why this error gets spit out after the server boots? snip java.lang.NoClassDefFoundError: org/apache/geronimo/deployment/plugin/ ConfigIDExtractor at java.lang.ClassLoader.defineClass0(Native Method) at java.lang.ClassLoader.defineClass(ClassLoader.java:539) at java.security.SecureClassLoader.defineClass (SecureClassLoader.java:123) at org.apache.geronimo.kernel.classloader.JarFileClassLoader.access$200 (JarFileClassLoader.java:51) at org.apache.geronimo.kernel.classloader.JarFileClassLoader $6.run(JarFileClassLoader.java:275) at java.security.AccessController.doPrivileged(Native Method) at org.apache.geronimo.kernel.classloader.JarFileClassLoader.findClass (JarFileClassLoader.java:227) at org.apache.geronimo.kernel.config.MultiParentClassLoader.loadClass (MultiParentClassLoader.java:243) at java.lang.ClassLoader.loadClass(ClassLoader.java:235) at org.apache.geronimo.kernel.config.MultiParentClassLoader.loadClass (MultiParentClassLoader.java:227) at java.lang.ClassLoader.loadClass(ClassLoader.java:235) at org.apache.geronimo.kernel.config.MultiParentClassLoader.loadClass (MultiParentClassLoader.java:227) at java.lang.ClassLoader.loadClass(ClassLoader.java:235) at java.lang.ClassLoader.loadClassInternal(ClassLoader.java: 302) at org.apache.geronimo.deployment.hot.DirectoryMonitor.calculateModuleId (DirectoryMonitor.java:358) at org.apache.geronimo.deployment.hot.DirectoryMonitor.initialize (DirectoryMonitor.java:230) at org.apache.geronimo.deployment.hot.DirectoryMonitor.run (DirectoryMonitor.java:206) at java.lang.Thread.run(Thread.java:552) /snip --jason
Re: Build error on 1.1.1 branch geronimo rev 430687, openejb rev 2844?
I'm not getting that far... I'm getting a test failure in modules/ activation: test:test: [junit] Running org.apache.geronimo.activation.handlers.MailcapTest [junit] Tests run: 1, Failures: 1, Errors: 0, Time elapsed: 0.237 sec [junit] [ERROR] Test org.apache.geronimo.activation.handlers.MailcapTest FAILED [junit] Running org.apache.geronimo.activation.handlers.TextHtmlTest [junit] Tests run: 3, Failures: 0, Errors: 0, Time elapsed: 0.026 sec [junit] Running org.apache.geronimo.activation.handlers.TextPlainTest [junit] Tests run: 3, Failures: 0, Errors: 0, Time elapsed: 0.03 sec [junit] Running org.apache.geronimo.activation.handlers.TextXmlTest [junit] Tests run: 3, Failures: 0, Errors: 0, Time elapsed: 0.011 sec --kevan On Aug 11, 2006, at 2:33 AM, John Sisson wrote: Anyone know of any changes that could have broken it? I have tried the build on windows and solaris and get the same error. John + | configurations openejb Configuration for performing J2EE deployments | Memory: 49M/78M + DEPRECATED: the default goal should be specified in the build section of project.xml instead of maven.xml DEPRECATED: the default goal should be specified in the build section of project.xml instead of maven.xml build:end: Attempting to download openejb-builder-2.1.1-SNAPSHOT.jar. build:start: multiproject:install-callback: [echo] Running car:install for openejb Configuration for performing J2EE deployments car:prepare-plan: car:package: [delete] Deleting directory R:\1.1.1\configs\openejb-deployer \target\repository [mkdir] Created dir: R:\1.1.1\configs\openejb-deployer\target \repository Packaging configuration R:\1.1.1\configs\openejb-deployer\target \plan\plan.xml 13:26:47,140 ERROR [Deployer] Deployment failed due to java.lang.NoClassDefFoundError: org/apache/axis/Handler at java.lang.Class.forName0(Native Method) at java.lang.Class.forName(Class.java:141) at org.openejb.server.axis.WSContainerGBean.class$ (WSContainerGBean.java:61) at org.openejb.server.axis.WSContainerGBean.clinit (WSContainerGBean.java:61) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke (NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at org.apache.geronimo.gbean.GBeanInfo.getGBeanInfo (GBeanInfo.java:70) at org.apache.geronimo.deployment.service.ServiceConfigBuilder.addGBeanDa ta(ServiceConfigBuilder.java:295) at org.apache.geronimo.deployment.service.ServiceConfigBuilder.addGBeans( ServiceConfigBuilder.java:290) at org.apache.geronimo.deployment.service.ServiceConfigBuilder.buildConfi guration(ServiceConfigBuilder.java:256) at org.apache.geronimo.deployment.service.ServiceConfigBuilder.buildConfi guration(ServiceConfigBuilder.java:211) at org.apache.geronimo.deployment.service.ServiceConfigBuilder$ $FastClassByCGLIB$$9f173be6.invoke(generated) at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53) at org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke (FastMethodInvoker.java:38) at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke (GBeanOperation.java:122) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke (GBeanInstance.java:817) at org.apache.geronimo.gbean.runtime.RawInvoker.invoke (RawInvoker.java:57) at org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke (RawOperationInvoker.java:35) at org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept (ProxyMethodInterceptor.java:96) at org.apache.geronimo.deployment.ConfigurationBuilder$ $EnhancerByCGLIB$$2dd00db1.buildConfiguration(generated) at org.apache.geronimo.deployment.Deployer.deploy (Deployer.java:302) at org.apache.geronimo.deployment.Deployer$$FastClassByCGLIB$ $734a235d.invoke(generated) at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53) at org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke (FastMethodInvoker.java:38) at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke (GBeanOperation.java:122) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke (GBeanInstance.java:852) at org.apache.geronimo.kernel.basic.BasicKernel.invoke (BasicKernel.java:239) at org.apache.geronimo.plugin.packaging.PackageBuilder.invokeDeployer (PackageBuilder.java:472) at org.apache.geronimo.plugin.packaging.PackageBuilder.execute (PackageBuilder.java:332) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke (NativeMethodAccessorImpl.java:39) at
Re: Merge fix for GERONIMO-2305 into 1.1.1?
David, I'm chasing a couple of other things this morning. I'm willing to take your recommendation and apply it. Before anyone gets too worked up at why I would let this one in and not others we got derailed a bit with the addressing the security issue (now resolved). Given the delay I'm ok with putting it in and closing the release since this is addressing an issue a user is having at this time. We'll start 1.1.2 straight away. Thanks David David Jencks wrote: I'm not quite sure where the 1.1.1 release is, so I'm asking if we should merge in dain's fix for g-2305. The problem is that if you get a resource url from our classloader for something in the app URL url = cl.getResource(file1.xml); and then try to use that url to construct a related url: URL url2 = new URL(url, somethingelse.xml); the second url doesn't work because we put a UrlStreamHandler in the first url that only works with that first url, and the url constructor used for url2 uses that same UrlStreamHandler. The fix is to make the UrlStreamHandler work for any path into the same jar, and use normal mechanisms for paths outside the jar. This breaks trinidad (part of myfaces IIUC) and seems like a fairly serious error. IMO there is extremely little danger of the fix breaking anything that used to work, since the code path that is changed used to throw an exception. The fix does allow the user's sample app to work. I'm leaning towards recommending adding it to 1.1.1. thanks david jencks
Re: Deadlock on 4.0.2
I think that if we enable async dispatch this issue should go away. This would only affect vm transport since the transport oneways. We should look into making async to be dispatch be the default when using the vm transport. On 8/11/06, Guillaume Nodet [EMAIL PROTECTED] wrote: I sometime have deadlocks while running junit tests that involve ActiveMQ. Following is a stack trace i dumped. As you can see, the two last threads are deadlocked because of the MutexTransport. This cause the first thread (main thread) to hang forever. Thread [main] (Suspended) MutexTransport.oneway(Command) line: 44 == MutexTransport (id=292) ResponseCorrelator.oneway(Command) line: 58 ManagedTransportConnection(TransportConnection).dispatch(Command) line: 211 ManagedTransportConnection(AbstractConnection).processDispatch(Command) line: 628 ManagedTransportConnection(AbstractConnection).dispatchSync(Command) line: 605 TopicSubscription.dispatch(MessageReference) line: 315 TopicSubscription.add(MessageReference) line: 74 SimpleDispatchPolicy.dispatch(ConnectionContext, MessageReference, MessageEvaluationContext, List) line: 50 Topic.dispatch(ConnectionContext, Message) line: 443 Topic.send(ConnectionContext, Message) line: 254 ManagedTopicRegion(AbstractRegion).send(ConnectionContext, Message) line: 225 ManagedRegionBroker(RegionBroker).send(ConnectionContext, Message) line: 345 TransactionBroker.send(ConnectionContext, Message) line: 192 AdvisoryBroker(BrokerFilter).send(ConnectionContext, Message) line: 113 CompositeDestinationBroker.send(ConnectionContext, Message) line: 97 BrokerService$2(MutableBrokerFilter).send(ConnectionContext, Message) line: 126 ManagedTransportConnection(AbstractConnection).processMessage(Message) line: 377 ActiveMQObjectMessage(ActiveMQMessage).visit(CommandVisitor) line: 590 ManagedTransportConnection(AbstractConnection).service(Command) line: 226 TransportConnection$1.onCommand(Command) line: 62 ResponseCorrelator.onCommand(Command) line: 91 MutexTransport(TransportFilter).onCommand(Command) line: 63 VMTransportServer$1(VMTransport).oneway(Command) line: 76 MutexTransport.oneway(Command) line: 44 = MutexTransport (id=314) ResponseCorrelator.oneway(Command) line: 58 ActiveMQConnection.asyncSendPacket(Command) line: 1092 ActiveMQSession.send(ActiveMQMessageProducer, ActiveMQDestination, Message, int, int, long) line: 1553 ActiveMQMessageProducer.send(Destination, Message, int, int, long) line: 462 ActiveMQMessageProducer.send(Message) line: 356 JCAFlow.sendJmsMessage(Destination, Serializable, boolean, boolean) line: 707 JCAFlow.onInternalEndpointUnregistered(EndpointEvent, boolean) line: 462 JCAFlow$1.internalEndpointUnregistered(EndpointEvent) line: 245 EndpointRegistry.fireEvent(ServiceEndpoint, int) line: 575 EndpointRegistry.unregisterInternalEndpoint(ComponentContext, InternalEndpoint) line: 199 Registry.deactivateEndpoint(ComponentContext, InternalEndpoint) line: 205 ComponentContextImpl.deactivateEndpoint(ServiceEndpoint) line: 157 ReceiverComponent(PojoSupport).shutDown() line: 103 ComponentMBeanImpl.doShutDown() line: 335 ComponentRegistry.shutDown() line: 105 Registry.shutDown() line: 142 SpringJBIContainer(JBIContainer).shutDown() line: 601 SpringJBIContainer.destroy() line: 184 DisposableBeanAdapter.destroy() line: 97 DefaultListableBeanFactory(AbstractBeanFactory).destroyBean(String, Object) line: 1159 DefaultListableBeanFactory(AbstractBeanFactory).destroyDisposableBean(String) line: 1131 DefaultListableBeanFactory(AbstractBeanFactory).destroySingletons() line: 660 ClassPathXmlApplicationContext(AbstractApplicationContext).doClose() line: 594 ClassPathXmlApplicationContext(AbstractApplicationContext).close() line: 563 ClassPathXmlApplicationContext(AbstractApplicationContext).destroy() line: 552 JmsSpringJcaTest(SpringTestSupport).tearDown() line: 66 JmsSpringJcaTest.tearDown() line: 52 JmsSpringJcaTest(TestCase).runBare() line: 130 TestResult$1.protect() line: 106 TestResult.runProtected(Test, Protectable) line: 124 TestResult.run(TestCase) line: 109 JmsSpringJcaTest(TestCase).run(TestResult) line: 118 TestSuite.runTest(Test, TestResult) line: 208 TestSuite.run(TestResult) line: 203 JUnit3TestReference.run(TestExecution) line: 128 TestExecution.run(ITestReference[]) line: 38 RemoteTestRunner.runTests(String[], String, TestExecution) line: 460 RemoteTestRunner.runTests(TestExecution) line: 673 RemoteTestRunner.run() line: 386 RemoteTestRunner.main(String[]) line: 196
Re: Build error on 1.1.1 branch geronimo rev 430687, openejb rev 2844?
I cheated - I wasn't running tests :-) John Kevan Miller wrote: I'm not getting that far... I'm getting a test failure in modules/activation: test:test: [junit] Running org.apache.geronimo.activation.handlers.MailcapTest [junit] Tests run: 1, Failures: 1, Errors: 0, Time elapsed: 0.237 sec [junit] [ERROR] Test org.apache.geronimo.activation.handlers.MailcapTest FAILED [junit] Running org.apache.geronimo.activation.handlers.TextHtmlTest [junit] Tests run: 3, Failures: 0, Errors: 0, Time elapsed: 0.026 sec [junit] Running org.apache.geronimo.activation.handlers.TextPlainTest [junit] Tests run: 3, Failures: 0, Errors: 0, Time elapsed: 0.03 sec [junit] Running org.apache.geronimo.activation.handlers.TextXmlTest [junit] Tests run: 3, Failures: 0, Errors: 0, Time elapsed: 0.011 sec --kevan On Aug 11, 2006, at 2:33 AM, John Sisson wrote: Anyone know of any changes that could have broken it? I have tried the build on windows and solaris and get the same error. John + | configurations openejb Configuration for performing J2EE deployments | Memory: 49M/78M + DEPRECATED: the default goal should be specified in the build section of project.xml instead of maven.xml DEPRECATED: the default goal should be specified in the build section of project.xml instead of maven.xml build:end: Attempting to download openejb-builder-2.1.1-SNAPSHOT.jar. build:start: multiproject:install-callback: [echo] Running car:install for openejb Configuration for performing J2EE deployments car:prepare-plan: car:package: [delete] Deleting directory R:\1.1.1\configs\openejb-deployer\target\repository [mkdir] Created dir: R:\1.1.1\configs\openejb-deployer\target\repository Packaging configuration R:\1.1.1\configs\openejb-deployer\target\plan\plan.xml 13:26:47,140 ERROR [Deployer] Deployment failed due to java.lang.NoClassDefFoundError: org/apache/axis/Handler at java.lang.Class.forName0(Native Method) at java.lang.Class.forName(Class.java:141) at org.openejb.server.axis.WSContainerGBean.class$(WSContainerGBean.java:61) at org.openejb.server.axis.WSContainerGBean.clinit(WSContainerGBean.java:61) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at org.apache.geronimo.gbean.GBeanInfo.getGBeanInfo(GBeanInfo.java:70) at org.apache.geronimo.deployment.service.ServiceConfigBuilder.addGBeanData(ServiceConfigBuilder.java:295) at org.apache.geronimo.deployment.service.ServiceConfigBuilder.addGBeans(ServiceConfigBuilder.java:290) at org.apache.geronimo.deployment.service.ServiceConfigBuilder.buildConfiguration(ServiceConfigBuilder.java:256) at org.apache.geronimo.deployment.service.ServiceConfigBuilder.buildConfiguration(ServiceConfigBuilder.java:211) at org.apache.geronimo.deployment.service.ServiceConfigBuilder$$FastClassByCGLIB$$9f173be6.invoke(generated) at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53) at org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38) at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:122) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:817) at org.apache.geronimo.gbean.runtime.RawInvoker.invoke(RawInvoker.java:57) at org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke(RawOperationInvoker.java:35) at org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept(ProxyMethodInterceptor.java:96) at org.apache.geronimo.deployment.ConfigurationBuilder$$EnhancerByCGLIB$$2dd00db1.buildConfiguration(generated) at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:302) at org.apache.geronimo.deployment.Deployer$$FastClassByCGLIB$$734a235d.invoke(generated) at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53) at org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38) at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:122) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:852) at org.apache.geronimo.kernel.basic.BasicKernel.invoke(BasicKernel.java:239) at org.apache.geronimo.plugin.packaging.PackageBuilder.invokeDeployer(PackageBuilder.java:472) at org.apache.geronimo.plugin.packaging.PackageBuilder.execute(PackageBuilder.java:332) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at
Re: Proposed refactoring to allow alternative persistence mechanisms
Please submit that patch!
On 8/10/06, Fateev, Maxim [EMAIL PROTECTED] wrote:
Hi,
We were looking at alternate message persistence mechanisms that can
co-exist in current ActiveMQ code base and we are thinking of a mechanism that
is somewhat incompatible with the current MessageStore and PersistenceAdapter
APIs. Unfortunately, the current ActiveMQ broker doesn't allow for such a
change as the PersistenceAdapter and MessageStore interfaces are referenced
directly by the RegionBroker and by both the Queue and Topic region
implementations. Therefore, we are proposing a relatively small backwards
compatible refactoring of the broker code that would eliminate all dependencies
on the PersistenceAdapter and MessageStore interfaces from those classes that
do not use them directly. This refactoring would also allow creation of a
custom Destination implementation that may use an alternative persistence
mechanism on a destination by destination basis (which is exactly what we need
to do).
The main idea behind the refactoring is to replace many references to
PersistenceAdapter with a new interface: DestinationFactory:
public abstract class DestinationFactory {
abstract public Destination createDestination(ConnectionContext
context, ActiveMQDestination destination, DestinationStatistics
destinationStatistics) throws Exception;
abstract public Set getDestinations();
abstract public SubscriptionInfo[]
getAllDurableSubscriptions(ActiveMQTopic topic) throws IOException;
abstract public long getLastMessageBrokerSequenceId() throws
IOException;
abstract public void setRegionBroker(RegionBroker regionBroker);
}
Note that DestinationFactory doesn't mandate any specific persistence
mechanism. The classes that would reference it instead of PersistenceAdapter
are: RegionBroker, AbstractRegion, QueueRegion, and TopicRegion. Also, the
AbstractRegion.createDestination method would be changed from abstract to an
implementation that uses DestinationFactory to create a destination.
BrokerService could be changed to use DestinationFactory if one is
provided. If none is provided, it will create a DestinationFactory
implementation that instantiates Queue and Topic using PersistenceAdapter as it
does currently. Hence, full backwards compatibility will be maintained.
We have a preliminary implementation on local workspace. We can provide
full patch for review. Appreciate your thoughts.
Thanks
Maxim Fateev.
--
Regards,
Hiram
Blog: http://hiramchirino.com
[jira] Assigned: (GERONIMODEVTOOLS-95) pim.xml still uses WTP 1.5.0
[ http://issues.apache.org/jira/browse/GERONIMODEVTOOLS-95?page=all ] Sachin Patel reassigned GERONIMODEVTOOLS-95: Assignee: Sachin Patel pim.xml still uses WTP 1.5.0 Key: GERONIMODEVTOOLS-95 URL: http://issues.apache.org/jira/browse/GERONIMODEVTOOLS-95 Project: Geronimo-Devtools Issue Type: Bug Components: eclipse-plugin Affects Versions: 1.1.0 Reporter: Lin Sun Assigned To: Sachin Patel Priority: Minor Fix For: 1.x The pom.xml at the root dir still uses: wtpUrlhttp://download.eclipse.org/webtools/downloads/drops/R1.5/R-1.5.0-200606281455/wtp-sdk-R-1.5.0-200606281455.zip/wtpUrl It should move to WTP 1.5.1 build ( for example: wtp-sdk-M-1.5.1-200608032139.zip), as WTP 1.5.1 is required for certain functions (devtools 93) checked in lately. -- 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: (GERONIMODEVTOOLS-95) pim.xml still uses WTP 1.5.0
[ http://issues.apache.org/jira/browse/GERONIMODEVTOOLS-95?page=all ] Sachin Patel closed GERONIMODEVTOOLS-95. Resolution: Fixed pim.xml still uses WTP 1.5.0 Key: GERONIMODEVTOOLS-95 URL: http://issues.apache.org/jira/browse/GERONIMODEVTOOLS-95 Project: Geronimo-Devtools Issue Type: Bug Components: eclipse-plugin Affects Versions: 1.1.0 Reporter: Lin Sun Assigned To: Sachin Patel Priority: Minor Fix For: 1.x The pom.xml at the root dir still uses: wtpUrlhttp://download.eclipse.org/webtools/downloads/drops/R1.5/R-1.5.0-200606281455/wtp-sdk-R-1.5.0-200606281455.zip/wtpUrl It should move to WTP 1.5.1 build ( for example: wtp-sdk-M-1.5.1-200608032139.zip), as WTP 1.5.1 is required for certain functions (devtools 93) checked in lately. -- 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-87) Distribution of configuration failed
[ http://issues.apache.org/jira/browse/GERONIMODEVTOOLS-87?page=comments#action_12427526 ] Sachin Patel commented on GERONIMODEVTOOLS-87: -- I cannot reproduce this, could you send me a test case to reproduce? Distribution of configuration failed Key: GERONIMODEVTOOLS-87 URL: http://issues.apache.org/jira/browse/GERONIMODEVTOOLS-87 Project: Geronimo-Devtools Issue Type: Bug Components: eclipse-plugin Affects Versions: 1.0.0 Environment: eclipse.buildId=M20060629-1905 java.version=1.4.2_10 java.vendor=Sun Microsystems Inc. BootLoader constants: OS=win32, ARCH=x86, WS=win32, NL=fr_BE Command-line arguments: -os win32 -ws win32 -arch x86 WPT 1.5 (Callisto) Geronimo 1.0 Reporter: Jens Nicolay Fix For: 1.x When I do the following... - create Dynamic Web Project, name: TestWeb - create Servlet in TestWeb, name: TestServlet - TestServlet.java - Run on Server - Geronimo ... I get this error: Error Mon Jul 03 11:42:51 CEST 2006 Distribution of configuration failed. See .log for details. java.lang.Exception: Cannot deploy the requested application module (moduleFile=C:\DOCUME~1\ADSL\LOCALS~1\Temp\geronimo-deployer12834.tmpdir\TestWeb.zip) org.apache.geronimo.common.DeploymentException: Cannot deploy the requested application module (moduleFile=C:\DOCUME~1\ADSL\LOCALS~1\Temp\geronimo-deployer12834.tmpdir\TestWeb.zip) at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:226) at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:102) at org.apache.geronimo.deployment.Deployer$$FastClassByCGLIB$$734a235d.invoke(generated) at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53) at org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38) at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:118) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:835) at org.apache.geronimo.kernel.basic.BasicKernel.invoke(BasicKernel.java:178) at org.apache.geronimo.kernel.KernelGBean.invoke(KernelGBean.java:125) at org.apache.geronimo.kernel.KernelGBean$$FastClassByCGLIB$$1cccefc9.invoke(generated) at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53) at org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38) at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:118) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:835) at org.apache.geronimo.kernel.basic.BasicKernel.invoke(BasicKernel.java:178) at org.apache.geronimo.kernel.jmx.MBeanServerDelegate.invoke(MBeanServerDelegate.java:117) at mx4j.remote.rmi.RMIConnectionInvoker.invoke(RMIConnectionInvoker.java:219) at sun.reflect.GeneratedMethodAccessor60.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) at java.lang.reflect.Method.invoke(Unknown Source) at mx4j.remote.rmi.RMIConnectionProxy.invoke(RMIConnectionProxy.java:34) at mx4j.remote.rmi.RMIConnectionSubjectInvoker.chain(RMIConnectionSubjectInvoker.java:99) at mx4j.remote.rmi.RMIConnectionSubjectInvoker.access$000(RMIConnectionSubjectInvoker.java:31) at mx4j.remote.rmi.RMIConnectionSubjectInvoker$1.run(RMIConnectionSubjectInvoker.java:90) at java.security.AccessController.doPrivileged(Native Method) at javax.security.auth.Subject.doAsPrivileged(Unknown Source) at mx4j.remote.MX4JRemoteUtils.subjectInvoke(MX4JRemoteUtils.java:163) at mx4j.remote.rmi.RMIConnectionSubjectInvoker.subjectInvoke(RMIConnectionSubjectInvoker.java:86) at mx4j.remote.rmi.RMIConnectionSubjectInvoker.invoke(RMIConnectionSubjectInvoker.java:80) at $Proxy0.invoke(Unknown Source) at javax.management.remote.rmi.RMIConnectionImpl.invoke(RMIConnectionImpl.java:221) at sun.reflect.GeneratedMethodAccessor60.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) at org.apache.geronimo.core.internal.GeronimoServerBehaviour.doFail(GeronimoServerBehaviour.java:329) at
[jira] Updated: (GERONIMODEVTOOLS-92) Support builds on Linux x86_64 based systems
[ http://issues.apache.org/jira/browse/GERONIMODEVTOOLS-92?page=all ] Sachin Patel updated GERONIMODEVTOOLS-92: - Patch Info: (was: [Patch Available]) Support builds on Linux x86_64 based systems Key: GERONIMODEVTOOLS-92 URL: http://issues.apache.org/jira/browse/GERONIMODEVTOOLS-92 Project: Geronimo-Devtools Issue Type: Improvement Components: eclipse-plugin Affects Versions: 1.1.0 Environment: SLES 10 on x86_64 Reporter: Donald Woods Assigned To: Donald Woods Priority: Minor Fix For: 1.x Need to update the maven-geronimodevtools-plugin to support more than just Windows x86, Linux x86 and MacOS. Will test and provide a patch tomorrow that allows builds on x86_64 Linux systems (like SLES10 on Intel EM64T or AMD64). Will also include code to recognize Linux on ppc, AIX on ppc, SunOS on x86 and SunOS on sparc, but will not be able to verify all those systems (just going by the os.arch and org.eclipse.swt.* mappings.) -- 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: Deadlock on 4.0.2
Btw, the docs on http://www.activemq.org/site/consumer-dispatch-async.html refer to dispatchAsync but the code uses asyncDispatch. I guess this is an oversight, right ? On 8/11/06, Hiram Chirino [EMAIL PROTECTED] wrote: I think that if we enable async dispatch this issue should go away. This would only affect vm transport since the transport oneways. We should look into making async to be dispatch be the default when using the vm transport. On 8/11/06, Guillaume Nodet [EMAIL PROTECTED] wrote: I sometime have deadlocks while running junit tests that involve ActiveMQ. Following is a stack trace i dumped. As you can see, the two last threads are deadlocked because of the MutexTransport. This cause the first thread (main thread) to hang forever. Thread [main] (Suspended) MutexTransport.oneway(Command) line: 44 == MutexTransport (id=292) ResponseCorrelator.oneway(Command) line: 58 ManagedTransportConnection(TransportConnection).dispatch(Command) line: 211 ManagedTransportConnection(AbstractConnection).processDispatch(Command) line: 628 ManagedTransportConnection(AbstractConnection).dispatchSync(Command) line: 605 TopicSubscription.dispatch(MessageReference) line: 315 TopicSubscription.add(MessageReference) line: 74 SimpleDispatchPolicy.dispatch(ConnectionContext, MessageReference, MessageEvaluationContext, List) line: 50 Topic.dispatch(ConnectionContext, Message) line: 443 Topic.send(ConnectionContext, Message) line: 254 ManagedTopicRegion(AbstractRegion).send(ConnectionContext, Message) line: 225 ManagedRegionBroker(RegionBroker).send(ConnectionContext, Message) line: 345 TransactionBroker.send(ConnectionContext, Message) line: 192 AdvisoryBroker(BrokerFilter).send(ConnectionContext, Message) line: 113 CompositeDestinationBroker.send(ConnectionContext, Message) line: 97 BrokerService$2(MutableBrokerFilter).send(ConnectionContext, Message) line: 126 ManagedTransportConnection(AbstractConnection).processMessage(Message) line: 377 ActiveMQObjectMessage(ActiveMQMessage).visit(CommandVisitor) line: 590 ManagedTransportConnection(AbstractConnection).service(Command) line: 226 TransportConnection$1.onCommand(Command) line: 62 ResponseCorrelator.onCommand(Command) line: 91 MutexTransport(TransportFilter).onCommand(Command) line: 63 VMTransportServer$1(VMTransport).oneway(Command) line: 76 MutexTransport.oneway(Command) line: 44 = MutexTransport (id=314) ResponseCorrelator.oneway(Command) line: 58 ActiveMQConnection.asyncSendPacket(Command) line: 1092 ActiveMQSession.send(ActiveMQMessageProducer, ActiveMQDestination, Message, int, int, long) line: 1553 ActiveMQMessageProducer.send(Destination, Message, int, int, long) line: 462 ActiveMQMessageProducer.send(Message) line: 356 JCAFlow.sendJmsMessage(Destination, Serializable, boolean, boolean) line: 707 JCAFlow.onInternalEndpointUnregistered(EndpointEvent, boolean) line: 462 JCAFlow$1.internalEndpointUnregistered(EndpointEvent) line: 245 EndpointRegistry.fireEvent(ServiceEndpoint, int) line: 575 EndpointRegistry.unregisterInternalEndpoint(ComponentContext, InternalEndpoint) line: 199 Registry.deactivateEndpoint(ComponentContext, InternalEndpoint) line: 205 ComponentContextImpl.deactivateEndpoint(ServiceEndpoint) line: 157 ReceiverComponent(PojoSupport).shutDown() line: 103 ComponentMBeanImpl.doShutDown() line: 335 ComponentRegistry.shutDown() line: 105 Registry.shutDown() line: 142 SpringJBIContainer(JBIContainer).shutDown() line: 601 SpringJBIContainer.destroy() line: 184 DisposableBeanAdapter.destroy() line: 97 DefaultListableBeanFactory(AbstractBeanFactory).destroyBean(String, Object) line: 1159 DefaultListableBeanFactory(AbstractBeanFactory).destroyDisposableBean(String) line: 1131 DefaultListableBeanFactory(AbstractBeanFactory).destroySingletons() line: 660 ClassPathXmlApplicationContext(AbstractApplicationContext).doClose() line: 594 ClassPathXmlApplicationContext(AbstractApplicationContext).close() line: 563 ClassPathXmlApplicationContext(AbstractApplicationContext).destroy() line: 552 JmsSpringJcaTest(SpringTestSupport).tearDown() line: 66 JmsSpringJcaTest.tearDown() line: 52 JmsSpringJcaTest(TestCase).runBare() line: 130 TestResult$1.protect() line: 106 TestResult.runProtected(Test, Protectable) line: 124 TestResult.run(TestCase) line: 109 JmsSpringJcaTest(TestCase).run(TestResult) line: 118 TestSuite.runTest(Test, TestResult) line: 208 TestSuite.run(TestResult) line: 203 JUnit3TestReference.run(TestExecution) line: 128
[jira] Commented: (GERONIMO-2307) Include appropriate license for the Sun j2ee schema files that are redistributed
[ http://issues.apache.org/jira/browse/GERONIMO-2307?page=comments#action_12427532 ] Matt Hogstrom commented on GERONIMO-2307: - Here is a list of other files that are in the build that we need to consider. application-client_1_2.dtd application-client_1_3.dtd application-client_1_4.xsd application_1_2.dtd application_1_3.dtd application_1_4.xsd connector_1_0.dtd connector_1_5.xsd ejb-jar_1_1.dtd ejb-jar_2_0.dtd ejb-jar_2_1.xsd j2ee_1_4.xsd j2ee_jaxrpc_mapping_1_1.xsd j2ee_web_services_1_1.xsd j2ee_web_services_client_1_1.xsd jsp_2_0.xsd web-app_2_2.dtd web-app_2_3.dtd web-app_2_4.xsd web-jsptaglibrary_1_1.dtd web-jsptaglibrary_1_2.dtd Include appropriate license for the Sun j2ee schema files that are redistributed Key: GERONIMO-2307 URL: http://issues.apache.org/jira/browse/GERONIMO-2307 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: buildsystem Affects Versions: 1.0, 1.1 Reporter: John Sisson Assigned To: Geir Magnusson Jr Priority: Blocker Fix For: 1.1.1 Geronimo redistributes the Sun J2EE schema files for deployment descriptors etc but doesn't appear to include anything in the global license file about it. The following two statement in the copyright text in the schema files (e.g. http://java.sun.com/xml/ns/j2ee/ejb-jar_2_1.xsd ) concern me: * This document and the technology which it describes are distributed under licenses restricting their use, copying, distribution, and decompilation. * No part of this document may be reproduced in any form by any means without prior written authorization of Sun and its licensors, if any. Considering the first point, we need to determine what license the files are under. Seems we need written authorization for the second point. The concern regarding copyrights for the schemas came to mind whilst testing the geronimo eclipse plugin, eclipse prompted me to acknowledge the Sun license at http://developers.sun.com/license/berkeley_license.html when caching the j2ee schema files (e.g. http://java.sun.com/xml/ns/j2ee/ejb-jar_2_1.xsd ). I can't find anything to confirm that the berkeley license displayed by eclipse is the correct license for the schemas. -- 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
Yoko and Geronimo
I've run into an interesting snag with getting Geronimo to run with the Yoko ORB. Because there in an inherent conflict with some of the class files that ship with the JVM, it is necessary to prepend the yoko jar file to the bootclasspath when launching the server. This sort of lies outside of the realm of normal execution dependencies. I suppose it can added to the startup batch file, but this means Geronimo can no longer be started by just doing java server.jar. Additionally, if the Yoko jar is on the bootclasspath, then the Sun version of the ORB adaptor will not function. This is an either/or situation, and the choice, unfortunately, must be made before the JVM is launched. This even comes into play during the build, because there are unit tests for the SunNameService (and also the YokoNameService). Any thoughts on how we should handle this particularly awkward situation? Rick
Re: NoClassDefFoundError: org/apache/geronimo/deployment/plugin/ConfigIDExtractor
The error is from the hot deployer, and the hot deployer puts in a little delay before it runs in order to let everything else finish starting. It didn't seem reasonable to try to put in service dependencies on all the other deployers, since we don't really know what will change with time, plugins, etc., so IIRC it just starts a thread with like a 5 or 10 second sleep before it processes the stuff in the hot deploy dir. As for the actual problem, I assume the hot deploy module POM is missing a dependency on one of the other deploy modules. Thanks, Aaron On 8/11/06, Jason Dillon [EMAIL PROTECTED] wrote: Maybe... it does spit up after the server lists the web contexts. If you have a chance to peek I'd appreciate it. --jason On Aug 10, 2006, at 11:12 PM, David Jencks wrote: I haven't checked but assume this is a side effect of changing the pom dependency scopes in the deploy-jsr88 pom. thanks david jencks On Aug 10, 2006, at 10:03 PM, Jason Dillon wrote: Anyone know why this error gets spit out after the server boots? snip java.lang.NoClassDefFoundError: org/apache/geronimo/deployment/ plugin/ConfigIDExtractor at java.lang.ClassLoader.defineClass0(Native Method) at java.lang.ClassLoader.defineClass(ClassLoader.java:539) at java.security.SecureClassLoader.defineClass (SecureClassLoader.java:123) at org.apache.geronimo.kernel.classloader.JarFileClassLoader.access $200(JarFileClassLoader.java:51) at org.apache.geronimo.kernel.classloader.JarFileClassLoader$6.run (JarFileClassLoader.java:275) at java.security.AccessController.doPrivileged(Native Method) at org.apache.geronimo.kernel.classloader.JarFileClassLoader.findClass (JarFileClassLoader.java:227) at org.apache.geronimo.kernel.config.MultiParentClassLoader.loadClass (MultiParentClassLoader.java:243) at java.lang.ClassLoader.loadClass(ClassLoader.java:235) at org.apache.geronimo.kernel.config.MultiParentClassLoader.loadClass (MultiParentClassLoader.java:227) at java.lang.ClassLoader.loadClass(ClassLoader.java:235) at org.apache.geronimo.kernel.config.MultiParentClassLoader.loadClass (MultiParentClassLoader.java:227) at java.lang.ClassLoader.loadClass(ClassLoader.java:235) at java.lang.ClassLoader.loadClassInternal (ClassLoader.java:302) at org.apache.geronimo.deployment.hot.DirectoryMonitor.calculateModuleId (DirectoryMonitor.java:358) at org.apache.geronimo.deployment.hot.DirectoryMonitor.initialize (DirectoryMonitor.java:230) at org.apache.geronimo.deployment.hot.DirectoryMonitor.run (DirectoryMonitor.java:206) at java.lang.Thread.run(Thread.java:552) /snip --jason
Re: problem installing plugin for web console in g 1.1
Does anybody know how to update the Maven metadata on ibiblio? It looks like this is incorrect for all of the 1.1 artifacts. Aaron, Thanks for looking into this. Have you added (or are you going to add) the full set of geronimo artifacts for 1.1 to your plugin repo as you mentioned? Can you let me know when they are there? It seems like it makes sense to have these on the geronimo plugins repo anyway, even once ibiblio is fixed. They are geronimo artifacts that may be needed by many Geronimo plugins and it would eliminate possible failures due to connectivity problems with ibiblio. Joe Aaron Mulder wrote: This is because the Maven metadata in the Maven 2 repository on ibiblio is wrong. I'm surprised -- I would have thought this was updated when we published our 1.1 JARs. Anyway, look here: http://www.ibiblio.org/maven2/geronimo/geronimo-timer/maven-metadata.xml Notice that there's no 1.1 listed, even though http://www.ibiblio.org/maven2/geronimo/geronimo-timer/1.1/ exists. So the path we took to get here is because we need a module and there's no version in the dependency, we find the first server that has a matching module and take the highest version it has. I can probably work around this by putting a full set of Geronimo artifacts on geronimoplugins.com (so we won't fall back to ibiblio for those modules), though again, the real fix is to correct the Maven metadata on ibiblio. I have no idea how to do that. Thanks, Aaron On 8/10/06, Joe Bohn [EMAIL PROTECTED] wrote: I hit an error attempting to install the plugin for the web console on a little-G tomcat image with the official Geronimo 1.1 release. Are there known problems with this capability? I assumed that this plugin is for this very purpose (since we already include the console with the j2ee image). It looked like the download and install went as expected but failed attempting to start the gbean. I think that somehow the wrong dependencies were installed for geronimo-timer (and perhaps geronimo-derby). For both of these version 1.0 was deployed rather than 1.1. Installation Complete! Used existing: geronimo/j2ee-server//car Used existing: geronimo/j2ee-security//car Used existing: geronimo/tomcat//car Used existing: geronimo/geronimo-management//jar Used existing: geronimo/geronimo-deploy-jsr88//jar Used existing: geronimo/geronimo-service-builder//jar Used existing: geronimo/geronimo-connector-builder//jar Used existing: geronimo/geronimo-naming-builder//jar Used existing: geronimo/geronimo-security-builder//jar Used existing: geronimo/geronimo-j2ee-schema//jar Used existing: xmlbeans/xbean/2.0.0/jar Used existing: stax/stax-api/1.0.1/jar Used existing: geronimo/geronimo-util//jar Installed new: geronimo/system-database//car Installed new: geronimo/geronimo-derby//jar Installed new: org.apache.derby/derby//jar Installed new: org.apache.derby/derbynet//jar Installed new: geronimo/geronimo-timer//jar Installed new: portlet-api/portlet-api/1.0/jar Installed new: org.apache.pluto/pluto/1.0.1/jar Installed new: geronimo/geronimo-console-core//jar Installed new: geronimo/geronimo-upgrade//jar Installed new: geronimo/geronimo-test-ddbean//jar Installed new: geronimo/geronimo-deploy-config//jar Installed new: activemq/activemq-gbean-management-g1_1/3.2.4/jar Installed new: activemq/activemq-gbean-g1_1/3.2.4/jar Installed new: activemq/activemq-core/3.2.4/jar Installed new: geronimo/geronimo-converter//jar Installed new: jdom/jdom//jar Now starting geronimo/webconsole-tomcat/1.1/car... org.apache.geronimo.kernel.config.LifecycleException: start of geronimo/webconsole-tomcat/1.1/car failed at org.apache.geronimo.kernel.config.SimpleConfigurationManager.startConfiguration(SimpleConfigurationManager.java:529) at org.apache.geronimo.kernel.config.SimpleConfigurationManager.startConfiguration(SimpleConfigurationManager.java:493) at org.apache.geronimo.kernel.config.SimpleConfigurationManager$$FastClassByCGLIB$$ce77a924.invoke(generated) at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53) at org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38) at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:122) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:852) at org.apache.geronimo.kernel.basic.BasicKernel.invoke(BasicKernel.java:239) at org.apache.geronimo.kernel.KernelGBean.invoke(KernelGBean.java:338) at org.apache.geronimo.kernel.KernelGBean$$FastClassByCGLIB$$1cccefc9.invoke(generated) at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53) at org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38)
Re: Yoko and Geronimo
Rick, I'm curious about the inherent conflict with the classes that ship with the JVM. Can you explain a little more about what that means (which classes, when and how are they loaded, etc)? thanks, Paul On 8/11/06, Rick McGuire [EMAIL PROTECTED] wrote: I've run into an interesting snag with getting Geronimo to run with the Yoko ORB. Because there in an inherent conflict with some of the class files that ship with the JVM, it is necessary to prepend the yoko jar file to the bootclasspath when launching the server. This sort of lies outside of the realm of normal execution dependencies. I suppose it can added to the startup batch file, but this means Geronimo can no longer be started by just doing java server.jar. Additionally, if the Yoko jar is on the bootclasspath, then the Sun version of the ORB adaptor will not function. This is an either/or situation, and the choice, unfortunately, must be made before the JVM is launched. This even comes into play during the build, because there are unit tests for the SunNameService (and also the YokoNameService). Any thoughts on how we should handle this particularly awkward situation? Rick
Re: problem installing plugin for web console in g 1.1
I agree. I'll let you know when the site is updated. I won't be able to do it during the day, but tonight or over the weekend. Thanks, Aaron On 8/11/06, Joe Bohn [EMAIL PROTECTED] wrote: Does anybody know how to update the Maven metadata on ibiblio? It looks like this is incorrect for all of the 1.1 artifacts. Aaron, Thanks for looking into this. Have you added (or are you going to add) the full set of geronimo artifacts for 1.1 to your plugin repo as you mentioned? Can you let me know when they are there? It seems like it makes sense to have these on the geronimo plugins repo anyway, even once ibiblio is fixed. They are geronimo artifacts that may be needed by many Geronimo plugins and it would eliminate possible failures due to connectivity problems with ibiblio. Joe Aaron Mulder wrote: This is because the Maven metadata in the Maven 2 repository on ibiblio is wrong. I'm surprised -- I would have thought this was updated when we published our 1.1 JARs. Anyway, look here: http://www.ibiblio.org/maven2/geronimo/geronimo-timer/maven-metadata.xml Notice that there's no 1.1 listed, even though http://www.ibiblio.org/maven2/geronimo/geronimo-timer/1.1/ exists. So the path we took to get here is because we need a module and there's no version in the dependency, we find the first server that has a matching module and take the highest version it has. I can probably work around this by putting a full set of Geronimo artifacts on geronimoplugins.com (so we won't fall back to ibiblio for those modules), though again, the real fix is to correct the Maven metadata on ibiblio. I have no idea how to do that. Thanks, Aaron On 8/10/06, Joe Bohn [EMAIL PROTECTED] wrote: I hit an error attempting to install the plugin for the web console on a little-G tomcat image with the official Geronimo 1.1 release. Are there known problems with this capability? I assumed that this plugin is for this very purpose (since we already include the console with the j2ee image). It looked like the download and install went as expected but failed attempting to start the gbean. I think that somehow the wrong dependencies were installed for geronimo-timer (and perhaps geronimo-derby). For both of these version 1.0 was deployed rather than 1.1. Installation Complete! Used existing: geronimo/j2ee-server//car Used existing: geronimo/j2ee-security//car Used existing: geronimo/tomcat//car Used existing: geronimo/geronimo-management//jar Used existing: geronimo/geronimo-deploy-jsr88//jar Used existing: geronimo/geronimo-service-builder//jar Used existing: geronimo/geronimo-connector-builder//jar Used existing: geronimo/geronimo-naming-builder//jar Used existing: geronimo/geronimo-security-builder//jar Used existing: geronimo/geronimo-j2ee-schema//jar Used existing: xmlbeans/xbean/2.0.0/jar Used existing: stax/stax-api/1.0.1/jar Used existing: geronimo/geronimo-util//jar Installed new: geronimo/system-database//car Installed new: geronimo/geronimo-derby//jar Installed new: org.apache.derby/derby//jar Installed new: org.apache.derby/derbynet//jar Installed new: geronimo/geronimo-timer//jar Installed new: portlet-api/portlet-api/1.0/jar Installed new: org.apache.pluto/pluto/1.0.1/jar Installed new: geronimo/geronimo-console-core//jar Installed new: geronimo/geronimo-upgrade//jar Installed new: geronimo/geronimo-test-ddbean//jar Installed new: geronimo/geronimo-deploy-config//jar Installed new: activemq/activemq-gbean-management-g1_1/3.2.4/jar Installed new: activemq/activemq-gbean-g1_1/3.2.4/jar Installed new: activemq/activemq-core/3.2.4/jar Installed new: geronimo/geronimo-converter//jar Installed new: jdom/jdom//jar Now starting geronimo/webconsole-tomcat/1.1/car... org.apache.geronimo.kernel.config.LifecycleException: start of geronimo/webconsole-tomcat/1.1/car failed at org.apache.geronimo.kernel.config.SimpleConfigurationManager.startConfiguration(SimpleConfigurationManager.java:529) at org.apache.geronimo.kernel.config.SimpleConfigurationManager.startConfiguration(SimpleConfigurationManager.java:493) at org.apache.geronimo.kernel.config.SimpleConfigurationManager$$FastClassByCGLIB$$ce77a924.invoke(generated) at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53) at org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38) at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:122) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:852) at org.apache.geronimo.kernel.basic.BasicKernel.invoke(BasicKernel.java:239) at org.apache.geronimo.kernel.KernelGBean.invoke(KernelGBean.java:338) at
Re: Yoko and Geronimo
On 8/11/06, Rick McGuire [EMAIL PROTECTED] wrote: ... Any thoughts on how we should handle this particularly awkward situation? I vote we (e.g. Yoko) do whatever it takes to avoid the class conflict, and then Geronimo can forget about the JVM ORB forever. Do we know how other open source ORBs handle the conflict? Thanks, Aaron
Re: Yoko and Geronimo
Aaron Mulder wrote: On 8/11/06, Rick McGuire [EMAIL PROTECTED] wrote: ... Any thoughts on how we should handle this particularly awkward situation? I vote we (e.g. Yoko) do whatever it takes to avoid the class conflict, and then Geronimo can forget about the JVM ORB forever. Probably a question best asked on the yoko dev list. The best people to answer this are the ones who dealt with the problem originally. I just discovered the issue today...I might have avoided a lot of hair pulling had I been more aware of it. Rick Do we know how other open source ORBs handle the conflict? Thanks, Aaron
Re: Where to add new SSL BrokerService functionality
I am actually implementing option 1 anyways since the reflection stuff is part of the other Transport implementations (I'm being consistent). The problem is that I want the user to be sure that the broker they start will only use certificate authenticated connections (this is for the paranoid to be sure that nothing else will get inside their server). I am suggesting something like a setNeedClientCert method that would operate similar to setUseJmx (except that setUseJmx adds a broker filter and setNeedClientAuth would change the addConnector calls to enable client certificates). On 8/10/06, Hiram Chirino [EMAIL PROTECTED] wrote: I would go with option 1 since SSL is transport layer option and does not really have anything to do with the core of the broker. On 8/10/06, Sepand M [EMAIL PROTECTED] wrote: Hi all, As some of you may know, I'm working on an SSL client certificate authorization system for ActiveMQ. I've gotten some of the basics done and am trying to create a way of ensuring that SSL client certificates are used. I see two options (and I strongly prefer the second one): 1. The client would add the proper option to the URI they bind to on the broker side (e.g URI=localhost:61616?needClientAuth=true). 2. Adding a method to the BrokerService that enables this functionality. Unless someone suggests something different, I'm choosing method 2. The problem is I can't decide if I should subclass the existing BrokerService or add the menthioned method to the existing BrokerService class. So far, BrokerService seems to be doing everything and it has no subclasses, but I'm wondering how much more can be crammed into it and if SSL functionality should be built into the general purpose broker. Any thoughts? Regards, Sepand -- Regards, Hiram Blog: http://hiramchirino.com
[general question]how do code contributions work
Hi, My name is Philipp Rossmanith and I'm working at T-Systems, Spain. We're currently involved in a research project where we need to implement a system providing functionality that to a large extent already seems to be provided by an ESB. Since a week, I and my team (4 people in total) are exploring which (open-source) ESB to use and to (later on) contribute code to. The last 2 remaining options are ServiceMix and Mule. So far, we have no experience of working in open-source projects. Hence I have a couple of questions regarding work in Apache projects: - In general, would you be interested in contributions on our behalf? - Can anyone raise any issues they like on the JIRA? - How are issues from the JIRA assigned to a developer? What's the procedure for resolving an issue? - How is the code merged into the code base? Thanks in advance, Ciao, Philipp This e-mail may contain confidential or privileged information. Any unauthorised copying, use or distribution of this information is strictly prohibited. Este mensaje electrónico puede contener información confidencial o privilegiada, por lo que está completamente prohibida la copia, el uso o la distribución no autorizada de dicha información Aquest missatge electrònic pot contenir informació confidencial o privilegiada i està completament prohibida qualsevol còpia, ús o distribució no autoritzada d'aquesta informació. Mezu honek, enpresaren jabetzapeko edo legalki babestutako isilpeko informazioa izan dezake. Zu ez baldin bazara hartzailea, mesedez bidaltzaileari jakinarazi iezaiozu eta mezua ezabatu, ez ezazu gorde ezta birbidali ere, baimendu gabeko bere erabilera debekatzen da eta.
[jira] Commented: (GERONIMO-2209) Enable tests (geronimo-activation :: **/MailcapTest.java)
[ http://issues.apache.org/jira/browse/GERONIMO-2209?page=comments#action_12427545 ] Rick McGuire commented on GERONIMO-2209: I think it goes beyond just a JDK 1.5 vs. 1.4 issue. Some JVMs (or some JVM extension) appears to contain a set of mailcap handlers that are defined in a corresponding META-INF/mailcap file. When the unit test loads the definitions using InputStream is = TextPlainHandler.class.getClassLoader().getResourceAsStream(META-INF/mailcap); map = new MailcapCommandMap(is); it appears to be pulling in the JVM resident one rather than the mailcap file contained in the Geronimo activation module. This causes the failure because the resolved command handler is other than the Geronimo provided one. I'm not sure this test case can be made completely reliable. If the intent was to test the default mappings of the MailcapCommandMap, then there will be inherent conflicts. If the intent is just to test the functioning of MailcapCommandMap to load a definition file and resolve a mime type, then a more appropriate test would be to use a test case resource file to source the mappings. I suspect the intent was 1), but this can't really be made reliable because of JVM differences. I suggest just disabling this test case. Enable tests (geronimo-activation :: **/MailcapTest.java) - Key: GERONIMO-2209 URL: http://issues.apache.org/jira/browse/GERONIMO-2209 Project: Geronimo Issue Type: Sub-task Security Level: public(Regular issues) Affects Versions: 1.2 Reporter: Jason Dillon Fix For: 1.2 A few tests failed in non-obvious ways when run under the m2 build. Need someone who knows these tests better to inspect, resolve and enable the test (remove the test exclusions in the pom). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Error while deploying WAR application
Hello, I need to deploy a WAR application. I have created a deployment plan, but I can't find my mistake. When I try to deploy my application I get the exception: 10:08:11,671 ERROR [PortletInvokerImpl] PortletInvokerImpl.render() - Error while dispatching portlet. javax.portlet.PortletException ... My deployment plan (geronimo-web.xml) is: web-app xmlns=http://geronimo.apache.org/xml/ns/web-1.0; xmlns:sys=http://geronimo.apache.org/xml/ns/deployment-1.0; xmlns:naming=http://geronimo.apache.org/xml/ns/naming-1.0; xmlns:security=http://geronimo.apache.org/xml/ns/security-1.0; configId=com/lito/test00 parentId=geronimo/j2ee-server/1.0/car context-rootlito/context-root context-priority-classloadertrue/context-priority-classloader naming:resource-ref naming:ref-nameSWITCH_Con/naming:ref-name naming:resource-linkjdbc/SWITCH_Con/naming:resource-link /naming:resource-ref naming:resource-ref naming:ref-nameSWITCH_Conn/naming:ref-name naming:resource-linkjdbc/SWITCH_Conn/naming:resource-link /naming:resource-ref /web-app My WAR web.xml file is: !DOCTYPE web-app PUBLIC -//Sun Microsystems, Inc.//DTD Web Application 2.3//EN http://java.sun.com/dtd/web-app_2_3.dtd; web-app id=WebApp_ID display-nameSWITCH/display-name context-param param-namecom.ibm.ws.jsf.JSP_UPDATE_CHECK/param-name param-valuetrue/param-value descriptionDescription/context-param context-param param-namecom.ibm.ws.jsf.LOAD_FACES_CONFIG_AT_STARTUP/param-name param-valuetrue/param-value description/description /context-param context-param param-namecrystal_image_uri/param-name param-valuecrystalreportviewers11/param-value /context-param listener listener-classcom.sun.faces.config.ConfigureListener/listener-class /listener servlet id=Servlet_1144596880843 servlet-nameJS Resource Servlet/servlet-name servlet-class com.ibm.faces.webapp.JSResourceServlet/servlet-class load-on-startup-1/load-on-startup /servlet A lot more of servlet/servlet tags servlet-mapping servlet-nameJS Resource Servlet/servlet-name url-pattern/.ibmjsfres/*/url-pattern /servlet-mapping A lot more of servlet-mapping/servlet-mapping tags welcome-file-list welcome-fileindex.html/welcome-file welcome-fileindex.htm/welcome-file welcome-fileindex.jsp/welcome-file welcome-filedefault.html/welcome-file welcome-filedefault.htm/welcome-file welcome-filedefault.jsp/welcome-file /welcome-file-list error-page error-code404/error-code location/error.jsp/location /error-page taglib taglib-urihttp://jakarta.apache.org/taglibs/datetime-1.0/taglib-uri taglib-location/WEB-INF/lib/taglibs-datetime.jar/taglib-location /taglib taglib taglib-urihttp://jakarta.apache.org/taglibs/string-1.0.1/taglib-uri taglib-location/WEB-INF/lib/taglibs-string.jar/taglib-location /taglib taglib taglib-urihttp://jakarta.apache.org/taglibs/utility/taglib-uri taglib-location/WEB-INF/lib/utility.jar/taglib-location /taglib taglib taglib-urihttp://jakarta.apache.org/taglibs/mailer-1.1/taglib-uri taglib-location/WEB-INF/lib/taglibs-mailer.jar/taglib-location /taglib taglib taglib-uri/crystal-tags-reportviewer.tld/taglib-uri taglib-location/WEB-INF/crystal-tags-reportviewer.tld/taglib-location /taglib resource-ref id=ResourceRef_1145807649406 descriptionAuto Generated - WDO Datasource connection to SWITCH/description res-ref-nameSWITCH_Con/res-ref-name res-typejavax.sql.DataSource/res-type res-authContainer/res-auth res-sharing-scopeShareable/res-sharing-scope /resource-ref resource-ref id=ResourceRef_1155302136328 descriptionAuto Generated - WDO Datasource connection to SWITCH/description res-ref-nameSWITCH_Conn/res-ref-name res-typejavax.sql.DataSource/res-type res-authContainer/res-auth res-sharing-scopeShareable/res-sharing-scope /resource-ref login-config auth-methodUNSPECIFIED/auth-method /login-config /web-app Can someone help me to create a valid deployment plant for this specific application please??? Thanks a lot. -- View this message in context: http://www.nabble.com/Error-while-deploying-WAR-application-tf2091788.html#a5765932 Sent from the Apache Geronimo - Dev forum at Nabble.com.
[jira] Resolved: (GERONIMO-2209) Enable tests (geronimo-activation :: **/MailcapTest.java)
[ http://issues.apache.org/jira/browse/GERONIMO-2209?page=all ] Rick McGuire resolved GERONIMO-2209. Fix Version/s: 1.1.1 Resolution: Fixed Assignee: Rick McGuire This test case is highly dependent on the JDK version and what packages might be installed in the extensions dir. As a result, it's extremely difficult to make this work reliably. Also, this test doesn't actually test anything particularly useful, so it will just be deleted. Committed revision 430833 for version 1.1.1 Committed revision 430834 for version 1.2 Enable tests (geronimo-activation :: **/MailcapTest.java) - Key: GERONIMO-2209 URL: http://issues.apache.org/jira/browse/GERONIMO-2209 Project: Geronimo Issue Type: Sub-task Security Level: public(Regular issues) Affects Versions: 1.2 Reporter: Jason Dillon Assigned To: Rick McGuire Fix For: 1.1.1, 1.2 A few tests failed in non-obvious ways when run under the m2 build. Need someone who knows these tests better to inspect, resolve and enable the test (remove the test exclusions in the pom). -- 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: (GERONIMO-2209) Enable tests (geronimo-activation :: **/MailcapTest.java)
[ http://issues.apache.org/jira/browse/GERONIMO-2209?page=all ] Jason Dillon closed GERONIMO-2209. -- Cool, I've removed the build config in 1.2 to disable this test since it no longer exists. Enable tests (geronimo-activation :: **/MailcapTest.java) - Key: GERONIMO-2209 URL: http://issues.apache.org/jira/browse/GERONIMO-2209 Project: Geronimo Issue Type: Sub-task Security Level: public(Regular issues) Affects Versions: 1.2 Reporter: Jason Dillon Assigned To: Rick McGuire Fix For: 1.2, 1.1.1 A few tests failed in non-obvious ways when run under the m2 build. Need someone who knows these tests better to inspect, resolve and enable the test (remove the test exclusions in the pom). -- 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: Error while deploying WAR application
Is this for Geronimo 1.1? If so... Your geronimo-web.xml plan is in the G 1.0 format, so that would probably be the problem. There's an upgrade tool in the bin/ directory that you can use to take the first stab at upgrading this plan to the G 1.1 syntax. You can also look here: http://chariotsolutions.com/geronimo/geronimo-1.1/web.html http://geronimo.apache.org/schemas-1.1/geronimo-web-1.1.xsd Also, there's probably a more instructive error in the server console or server log at geronimo-1.1/var/log/geronimo.log -- I think the one you quoted is an error in the console when your application doesn't deploy right, it's not the actual underlying error that came up during deployment. That quirk should be fixed in Geronimo 1.1.1, to be released soon. Thanks, Aaron On 8/11/06, Malvarez1982 [EMAIL PROTECTED] wrote: Hello, I need to deploy a WAR application. I have created a deployment plan, but I can't find my mistake. When I try to deploy my application I get the exception: 10:08:11,671 ERROR [PortletInvokerImpl] PortletInvokerImpl.render() - Error while dispatching portlet. javax.portlet.PortletException ... My deployment plan (geronimo-web.xml) is: web-app xmlns=http://geronimo.apache.org/xml/ns/web-1.0; xmlns:sys=http://geronimo.apache.org/xml/ns/deployment-1.0; xmlns:naming=http://geronimo.apache.org/xml/ns/naming-1.0; xmlns:security=http://geronimo.apache.org/xml/ns/security-1.0; configId=com/lito/test00 parentId=geronimo/j2ee-server/1.0/car context-rootlito/context-root context-priority-classloadertrue/context-priority-classloader naming:resource-ref naming:ref-nameSWITCH_Con/naming:ref-name naming:resource-linkjdbc/SWITCH_Con/naming:resource-link /naming:resource-ref naming:resource-ref naming:ref-nameSWITCH_Conn/naming:ref-name naming:resource-linkjdbc/SWITCH_Conn/naming:resource-link /naming:resource-ref /web-app My WAR web.xml file is: !DOCTYPE web-app PUBLIC -//Sun Microsystems, Inc.//DTD Web Application 2.3//EN http://java.sun.com/dtd/web-app_2_3.dtd; web-app id=WebApp_ID display-nameSWITCH/display-name context-param param-namecom.ibm.ws.jsf.JSP_UPDATE_CHECK/param-name param-valuetrue/param-value descriptionDescription/context-param context-param param-namecom.ibm.ws.jsf.LOAD_FACES_CONFIG_AT_STARTUP/param-name param-valuetrue/param-value description/description /context-param context-param param-namecrystal_image_uri/param-name param-valuecrystalreportviewers11/param-value /context-param listener listener-classcom.sun.faces.config.ConfigureListener/listener-class /listener servlet id=Servlet_1144596880843 servlet-nameJS Resource Servlet/servlet-name servlet-class com.ibm.faces.webapp.JSResourceServlet/servlet-class load-on-startup-1/load-on-startup /servlet A lot more of servlet/servlet tags servlet-mapping servlet-nameJS Resource Servlet/servlet-name url-pattern/.ibmjsfres/*/url-pattern /servlet-mapping A lot more of servlet-mapping/servlet-mapping tags welcome-file-list welcome-fileindex.html/welcome-file welcome-fileindex.htm/welcome-file welcome-fileindex.jsp/welcome-file welcome-filedefault.html/welcome-file welcome-filedefault.htm/welcome-file welcome-filedefault.jsp/welcome-file /welcome-file-list error-page error-code404/error-code location/error.jsp/location /error-page taglib taglib-urihttp://jakarta.apache.org/taglibs/datetime-1.0/taglib-uri taglib-location/WEB-INF/lib/taglibs-datetime.jar/taglib-location /taglib taglib taglib-urihttp://jakarta.apache.org/taglibs/string-1.0.1/taglib-uri taglib-location/WEB-INF/lib/taglibs-string.jar/taglib-location /taglib taglib taglib-urihttp://jakarta.apache.org/taglibs/utility/taglib-uri taglib-location/WEB-INF/lib/utility.jar/taglib-location /taglib taglib taglib-urihttp://jakarta.apache.org/taglibs/mailer-1.1/taglib-uri taglib-location/WEB-INF/lib/taglibs-mailer.jar/taglib-location /taglib taglib taglib-uri/crystal-tags-reportviewer.tld/taglib-uri taglib-location/WEB-INF/crystal-tags-reportviewer.tld/taglib-location /taglib resource-ref id=ResourceRef_1145807649406 descriptionAuto Generated - WDO Datasource connection to SWITCH/description res-ref-nameSWITCH_Con/res-ref-name res-typejavax.sql.DataSource/res-type res-authContainer/res-auth res-sharing-scopeShareable/res-sharing-scope /resource-ref resource-ref id=ResourceRef_1155302136328 descriptionAuto Generated - WDO Datasource connection to SWITCH/description res-ref-nameSWITCH_Conn/res-ref-name res-typejavax.sql.DataSource/res-type res-authContainer/res-auth res-sharing-scopeShareable/res-sharing-scope /resource-ref login-config auth-methodUNSPECIFIED/auth-method /login-config /web-app Can someone help me to create a valid deployment plant for this specific application please??? Thanks a lot. -- View this message in context: http://www.nabble.com/Error-while-deploying-WAR-application-tf2091788.html#a5765932 Sent from the Apache Geronimo - Dev forum at Nabble.com.
XBEAN-39 - what's next?
Hi all, I've attached a second version of patch to XBEAN-39 with the changes Guillaume suggested. As far as I understand the process PMC members have to review and vote for the patch. So, I please have a look at it - and vote for it... :-) - http://issues.apache.org/jira/browse/XBEAN-39 Cheers, -Stefan -- Stefan Kleineikenscheidt tel. +49 (711) 99 33 035 Rosenbergstr. 58 mob. +49 (172) 130 54 77 70176 Stuttgart (GERMANY) [EMAIL PROTECTED]
Re: XBEAN-39 - what's next?
There is no need to review for bugfixes.I will commit it asap.Thanks for this patch.On 8/11/06, Stefan Kleineikenscheidt [EMAIL PROTECTED] wrote:Hi all,I've attached a second version of patch to XBEAN-39 with the changes Guillaume suggested.As far as I understand the process PMC members have toreview and vote for the patch.So, I please have a look at it - and vote for it...:-)- http://issues.apache.org/jira/browse/XBEAN-39Cheers,-Stefan--Stefan Kleineikenscheidt tel. +49 (711) 99 33 035Rosenbergstr. 58 mob. +49 (172) 130 54 77 70176 Stuttgart (GERMANY) [EMAIL PROTECTED]-- Cheers,Guillaume Nodet
Re: Error while deploying WAR application
Thanks Aaron, Unfortunately, I can't go to the Geronimo 1.1. I have WebSphere Application Server Community who is based on Geronimo 1.0. By the other hand, I suspect that my problem is because of the use of JSF components. Do you know if JSF is supported by Geronimo? One again, Thanks a lot. Aaron Mulder wrote: Is this for Geronimo 1.1? If so... Your geronimo-web.xml plan is in the G 1.0 format, so that would probably be the problem. There's an upgrade tool in the bin/ directory that you can use to take the first stab at upgrading this plan to the G 1.1 syntax. You can also look here: http://chariotsolutions.com/geronimo/geronimo-1.1/web.html http://geronimo.apache.org/schemas-1.1/geronimo-web-1.1.xsd Also, there's probably a more instructive error in the server console or server log at geronimo-1.1/var/log/geronimo.log -- I think the one you quoted is an error in the console when your application doesn't deploy right, it's not the actual underlying error that came up during deployment. That quirk should be fixed in Geronimo 1.1.1, to be released soon. Thanks, Aaron On 8/11/06, Malvarez1982 [EMAIL PROTECTED] wrote: Hello, I need to deploy a WAR application. I have created a deployment plan, but I can't find my mistake. When I try to deploy my application I get the exception: 10:08:11,671 ERROR [PortletInvokerImpl] PortletInvokerImpl.render() - Error while dispatching portlet. javax.portlet.PortletException ... My deployment plan (geronimo-web.xml) is: web-app xmlns=http://geronimo.apache.org/xml/ns/web-1.0; xmlns:sys=http://geronimo.apache.org/xml/ns/deployment-1.0; xmlns:naming=http://geronimo.apache.org/xml/ns/naming-1.0; xmlns:security=http://geronimo.apache.org/xml/ns/security-1.0; configId=com/lito/test00 parentId=geronimo/j2ee-server/1.0/car context-rootlito/context-root context-priority-classloadertrue/context-priority-classloader naming:resource-ref naming:ref-nameSWITCH_Con/naming:ref-name naming:resource-linkjdbc/SWITCH_Con/naming:resource-link /naming:resource-ref naming:resource-ref naming:ref-nameSWITCH_Conn/naming:ref-name naming:resource-linkjdbc/SWITCH_Conn/naming:resource-link /naming:resource-ref /web-app My WAR web.xml file is: !DOCTYPE web-app PUBLIC -//Sun Microsystems, Inc.//DTD Web Application 2.3//EN http://java.sun.com/dtd/web-app_2_3.dtd; web-app id=WebApp_ID display-nameSWITCH/display-name context-param param-namecom.ibm.ws.jsf.JSP_UPDATE_CHECK/param-name param-valuetrue/param-value descriptionDescription/context-param context-param param-namecom.ibm.ws.jsf.LOAD_FACES_CONFIG_AT_STARTUP/param-name param-valuetrue/param-value description/description /context-param context-param param-namecrystal_image_uri/param-name param-valuecrystalreportviewers11/param-value /context-param listener listener-classcom.sun.faces.config.ConfigureListener/listener-class /listener servlet id=Servlet_1144596880843 servlet-nameJS Resource Servlet/servlet-name servlet-class com.ibm.faces.webapp.JSResourceServlet/servlet-class load-on-startup-1/load-on-startup /servlet A lot more of servlet/servlet tags servlet-mapping servlet-nameJS Resource Servlet/servlet-name url-pattern/.ibmjsfres/*/url-pattern /servlet-mapping A lot more of servlet-mapping/servlet-mapping tags welcome-file-list welcome-fileindex.html/welcome-file welcome-fileindex.htm/welcome-file welcome-fileindex.jsp/welcome-file welcome-filedefault.html/welcome-file welcome-filedefault.htm/welcome-file welcome-filedefault.jsp/welcome-file /welcome-file-list error-page error-code404/error-code location/error.jsp/location /error-page taglib taglib-urihttp://jakarta.apache.org/taglibs/datetime-1.0/taglib-uri taglib-location/WEB-INF/lib/taglibs-datetime.jar/taglib-location /taglib taglib taglib-urihttp://jakarta.apache.org/taglibs/string-1.0.1/taglib-uri taglib-location/WEB-INF/lib/taglibs-string.jar/taglib-location /taglib taglib taglib-urihttp://jakarta.apache.org/taglibs/utility/taglib-uri taglib-location/WEB-INF/lib/utility.jar/taglib-location /taglib taglib taglib-urihttp://jakarta.apache.org/taglibs/mailer-1.1/taglib-uri taglib-location/WEB-INF/lib/taglibs-mailer.jar/taglib-location /taglib taglib taglib-uri/crystal-tags-reportviewer.tld/taglib-uri taglib-location/WEB-INF/crystal-tags-reportviewer.tld/taglib-location /taglib resource-ref id=ResourceRef_1145807649406 descriptionAuto Generated - WDO Datasource connection to SWITCH/description res-ref-nameSWITCH_Con/res-ref-name res-typejavax.sql.DataSource/res-type res-authContainer/res-auth res-sharing-scopeShareable/res-sharing-scope /resource-ref resource-ref id=ResourceRef_1155302136328 descriptionAuto Generated - WDO Datasource connection to SWITCH/description res-ref-nameSWITCH_Conn/res-ref-name res-typejavax.sql.DataSource/res-type res-authContainer/res-auth res-sharing-scopeShareable/res-sharing-scope
[jira] Closed: (XBEAN-39) NPE in XBeanHelper.createBeanDefinitionReader with some Classloaders
[ http://issues.apache.org/jira/browse/XBEAN-39?page=all ] Guillaume Nodet closed XBEAN-39. Fix Version/s: 2.6 Resolution: Fixed Assignee: Guillaume Nodet The same as patch has also been applied to xbean-spring-v2. Author: gnodet Date: Fri Aug 11 11:09:41 2006 New Revision: 430840 URL: http://svn.apache.org/viewvc?rev=430840view=rev Log: XBEAN-39: NPE in XBeanHelper.createBeanDefinitionReader with some Classloaders Patch submitted by Stefan Kleineikenscheidt Modified: geronimo/xbean/trunk/xbean-spring-common/src/main/java/org/apache/xbean/spring/context/impl/XBeanHelper.java geronimo/xbean/trunk/xbean-spring-v1/src/main/java/org/apache/xbean/spring/context/v1/XBeanXmlBeanDefinitionParser.java geronimo/xbean/trunk/xbean-spring-v2/src/main/java/org/apache/xbean/spring/context/v2/XBeanNamespaceHandler.java NPE in XBeanHelper.createBeanDefinitionReader with some Classloaders Key: XBEAN-39 URL: http://issues.apache.org/jira/browse/XBEAN-39 Project: XBean Issue Type: Bug Affects Versions: 2.0, 2.1, 2.2, 2.3, 2.4, 2.5 Reporter: Stefan Kleineikenscheidt Assigned To: Guillaume Nodet Fix For: 2.6 Attachments: XBEAN-39.patch, XBEAN-39.patch XBean fails on systems with some classloaders, which do not return sensible values from the following methods pkg.getImplementationVersion(); or cl.getResourceAsStream(name); This leads to a) a NPE thrown by SpringVersion.getVersion, b) the property files with custom mappings are not found. -- 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: Yoko and Geronimo
Hi, The JDK class http://java.sun.com/j2se/1.5.0/docs/api/org/omg/PortableInterceptor/IORI nterceptor_3_0Operations.html#adapter_manager_state_changed(int,%20short ) doesn't correctly implement the corba 3.0 spec... This method should have a string as the manager ID. Anyways, there are 2 ways to handle this... 1) java.endorsed.dirs setting 2) xbootclasspath - Balaji -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Aaron Mulder Sent: Friday, August 11, 2006 10:57 AM To: dev@geronimo.apache.org Subject: Re: Yoko and Geronimo On 8/11/06, Rick McGuire [EMAIL PROTECTED] wrote: ... Any thoughts on how we should handle this particularly awkward situation? I vote we (e.g. Yoko) do whatever it takes to avoid the class conflict, and then Geronimo can forget about the JVM ORB forever. Do we know how other open source ORBs handle the conflict? Thanks, Aaron
[jira] Created: (AMQ-876) Kaha DB cannot locate queue data files
Kaha DB cannot locate queue data files -- Key: AMQ-876 URL: https://issues.apache.org/activemq/browse/AMQ-876 Project: ActiveMQ Issue Type: Bug Components: Message Store Affects Versions: 4.1 Environment: WinXP Reporter: Vadim Pesochinskiy Fix For: 4.1 Keep getting exception below. Note that you are looking for queue-data-1, but actual file name is data-queue-data-1 $ pwd /cygdrive/d/amq/activemq-kaha/kaha.db $ ls data-kaha-1 data-queue-data-1 index-kaha index-queue-data index-transactions javax.jms.JMSException: java.io.IOException: Could not locate data file queue-data-1 at org.apache.activemq.util.JMSExceptionSupport.create(JMSExceptionSupport.java:46) at org.apache.activemq.ActiveMQConnection.syncSendPacket(ActiveMQConnection.java:1154) at org.apache.activemq.TransactionContext.commit(TransactionContext.java:260) at org.apache.activemq.ActiveMQSession.commit(ActiveMQSession.java:464) at com.barra.cp.common.io.MultiQueueReceiver.onMessage(MultiQueueReceiver.java:163) at com.barra.cp.common.io.SingleMessageMultiQueueReceiver$OneMessageAtATime.runMultiQueue(SingleMessageMultiQueueReceiver.java:176) at com.barra.cp.common.io.SingleMessageMultiQueueReceiver$OneMessageAtATime.doRun(SingleMessageMultiQueueReceiver.java:143) at com.barra.cp.common.io.SingleMessageMultiQueueReceiver$OneMessageAtATime.run(SingleMessageMultiQueueReceiver.java:124) at java.lang.Thread.run(Unknown Source) Caused by: org.apache.activemq.kaha.RuntimeStoreException: java.io.IOException: Could not locate data file queue-data-1 at org.apache.activemq.kaha.impl.MapContainerImpl.getValue(MapContainerImpl.java:340) at org.apache.activemq.kaha.impl.MapContainerImpl.remove(MapContainerImpl.java:265) at org.apache.activemq.store.kahadaptor.KahaMessageStore.removeMessage(KahaMessageStore.java:68) at org.apache.activemq.store.kahadaptor.KahaTransaction.commit(KahaTransaction.java:92) at org.apache.activemq.store.kahadaptor.KahaTransactionStore.commit(KahaTransactionStore.java:95) at org.apache.activemq.transaction.LocalTransaction.commit(LocalTransaction.java:68) at org.apache.activemq.broker.TransactionBroker.commitTransaction(TransactionBroker.java:154) at org.apache.activemq.broker.BrokerFilter.commitTransaction(BrokerFilter.java:92) at org.apache.activemq.broker.BrokerFilter.commitTransaction(BrokerFilter.java:92) at org.apache.activemq.broker.MutableBrokerFilter.commitTransaction(MutableBrokerFilter.java:102) at org.apache.activemq.broker.AbstractConnection.processCommitTransactionOnePhase(AbstractConnection.java:330) at org.apache.activemq.command.TransactionInfo.visit(TransactionInfo.java:99) 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.TcpTransport.run(TcpTransport.java:127) ... 1 more Caused by: java.io.IOException: Could not locate data file queue-data-1 at org.apache.activemq.kaha.impl.DataManager.getDataFile(DataManager.java:117) at org.apache.activemq.kaha.impl.StoreDataReader.readItem(StoreDataReader.java:62) at org.apache.activemq.kaha.impl.DataManager.readItem(DataManager.java:121) at org.apache.activemq.kaha.impl.MapContainerImpl.getValue(MapContainerImpl.java:337) ... 20 more -- 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: Error while deploying WAR application
JSF should work OK. I was able to install and run the samples from http://myfaces.apache.org/ in Geronimo 1.0. I had to make one minor adjustment to the samples' web.xml before deploying, which was to remove the description elements from the context-param and init-param elements. Looks like you may need to do the same. If that doesn't work, can you post some more of the stack trace you see in var/log/geronimo.log when you try to deploy? The most useful information is usually embedded a few exceptions deep. Best wishes, Paul On 8/11/06, Malvarez1982 [EMAIL PROTECTED] wrote: Thanks Aaron, Unfortunately, I can't go to the Geronimo 1.1. I have WebSphere Application Server Community who is based on Geronimo 1.0. By the other hand, I suspect that my problem is because of the use of JSF components. Do you know if JSF is supported by Geronimo? One again, Thanks a lot. Aaron Mulder wrote: Is this for Geronimo 1.1? If so... Your geronimo-web.xml plan is in the G 1.0 format, so that would probably be the problem. There's an upgrade tool in the bin/ directory that you can use to take the first stab at upgrading this plan to the G 1.1 syntax. You can also look here: http://chariotsolutions.com/geronimo/geronimo-1.1/web.html http://geronimo.apache.org/schemas-1.1/geronimo-web-1.1.xsd Also, there's probably a more instructive error in the server console or server log at geronimo-1.1/var/log/geronimo.log -- I think the one you quoted is an error in the console when your application doesn't deploy right, it's not the actual underlying error that came up during deployment. That quirk should be fixed in Geronimo 1.1.1, to be released soon. Thanks, Aaron On 8/11/06, Malvarez1982 [EMAIL PROTECTED] wrote: Hello, I need to deploy a WAR application. I have created a deployment plan, but I can't find my mistake. When I try to deploy my application I get the exception: 10:08:11,671 ERROR [PortletInvokerImpl] PortletInvokerImpl.render() - Error while dispatching portlet. javax.portlet.PortletException ... My deployment plan (geronimo-web.xml) is: web-app xmlns=http://geronimo.apache.org/xml/ns/web-1.0; xmlns:sys=http://geronimo.apache.org/xml/ns/deployment-1.0; xmlns:naming=http://geronimo.apache.org/xml/ns/naming-1.0; xmlns:security=http://geronimo.apache.org/xml/ns/security-1.0; configId=com/lito/test00 parentId=geronimo/j2ee-server/1.0/car context-rootlito/context-root context-priority-classloadertrue/context-priority-classloader naming:resource-ref naming:ref-nameSWITCH_Con/naming:ref-name naming:resource-linkjdbc/SWITCH_Con/naming:resource-link /naming:resource-ref naming:resource-ref naming:ref-nameSWITCH_Conn/naming:ref-name naming:resource-linkjdbc/SWITCH_Conn/naming:resource-link /naming:resource-ref /web-app My WAR web.xml file is: !DOCTYPE web-app PUBLIC -//Sun Microsystems, Inc.//DTD Web Application 2.3//EN http://java.sun.com/dtd/web-app_2_3.dtd; web-app id=WebApp_ID display-nameSWITCH/display-name context-param param-namecom.ibm.ws.jsf.JSP_UPDATE_CHECK/param-name param-valuetrue/param-value descriptionDescription/context-param context-param param-namecom.ibm.ws.jsf.LOAD_FACES_CONFIG_AT_STARTUP/param-name param-valuetrue/param-value description/description /context-param context-param param-namecrystal_image_uri/param-name param-valuecrystalreportviewers11/param-value /context-param listener listener-classcom.sun.faces.config.ConfigureListener/listener-class /listener servlet id=Servlet_1144596880843 servlet-nameJS Resource Servlet/servlet-name servlet-class com.ibm.faces.webapp.JSResourceServlet/servlet-class load-on-startup-1/load-on-startup /servlet A lot more of servlet/servlet tags servlet-mapping servlet-nameJS Resource Servlet/servlet-name url-pattern/.ibmjsfres/*/url-pattern /servlet-mapping A lot more of servlet-mapping/servlet-mapping tags welcome-file-list welcome-fileindex.html/welcome-file welcome-fileindex.htm/welcome-file welcome-fileindex.jsp/welcome-file welcome-filedefault.html/welcome-file welcome-filedefault.htm/welcome-file welcome-filedefault.jsp/welcome-file /welcome-file-list error-page error-code404/error-code location/error.jsp/location /error-page taglib taglib-urihttp://jakarta.apache.org/taglibs/datetime-1.0/taglib-uri taglib-location/WEB-INF/lib/taglibs-datetime.jar/taglib-location /taglib taglib taglib-urihttp://jakarta.apache.org/taglibs/string-1.0.1/taglib-uri taglib-location/WEB-INF/lib/taglibs-string.jar/taglib-location /taglib taglib taglib-urihttp://jakarta.apache.org/taglibs/utility/taglib-uri taglib-location/WEB-INF/lib/utility.jar/taglib-location /taglib taglib taglib-urihttp://jakarta.apache.org/taglibs/mailer-1.1/taglib-uri taglib-location/WEB-INF/lib/taglibs-mailer.jar/taglib-location /taglib taglib taglib-uri/crystal-tags-reportviewer.tld/taglib-uri
Re: Yoko and Geronimo
Are you saying that every open source and commercial ORB that wants to run under JDK 1.5.0 requires one of these two approaches? That no one has come up with a workaround that doesn't require user intervention? Thanks, Aaron On 8/11/06, Mosur Ravi, Balaji [EMAIL PROTECTED] wrote: The JDK class http://java.sun.com/j2se/1.5.0/docs/api/org/omg/PortableInterceptor/IORI nterceptor_3_0Operations.html#adapter_manager_state_changed(int,%20short ) doesn't correctly implement the corba 3.0 spec... This method should have a string as the manager ID. Anyways, there are 2 ways to handle this... 1) java.endorsed.dirs setting 2) xbootclasspath - Balaji -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Aaron Mulder Sent: Friday, August 11, 2006 10:57 AM To: dev@geronimo.apache.org Subject: Re: Yoko and Geronimo On 8/11/06, Rick McGuire [EMAIL PROTECTED] wrote: ... Any thoughts on how we should handle this particularly awkward situation? I vote we (e.g. Yoko) do whatever it takes to avoid the class conflict, and then Geronimo can forget about the JVM ORB forever. Do we know how other open source ORBs handle the conflict? Thanks, Aaron
[jira] Closed: (XBEAN-41) Improper abstract bean definitions handling
[ http://issues.apache.org/jira/browse/XBEAN-41?page=all ] Guillaume Nodet closed XBEAN-41. Fix Version/s: 2.6 Resolution: Fixed Assignee: Guillaume Nodet Abstract bean definitions are removed when those can be detected. Author: gnodet Date: Fri Aug 11 12:12:49 2006 New Revision: 430865 URL: http://svn.apache.org/viewvc?rev=430865view=rev Log: XBEAN-41: Improper abstract bean definitions handling Modified: geronimo/xbean/trunk/xbean-server/src/main/java/org/apache/xbean/server/spring/configuration/SpringConfiguration.java geronimo/xbean/trunk/xbean-server/src/test/resources/org/apache/xbean/server/spring/loader/classpath-xbean.xml Improper abstract bean definitions handling --- Key: XBEAN-41 URL: http://issues.apache.org/jira/browse/XBEAN-41 Project: XBean Issue Type: Bug Components: spring, server Affects Versions: 2.4 Reporter: Ilya Bochkov Assigned To: Guillaume Nodet Fix For: 2.6 Attachments: diff.txt When SpringConfiguration tries to load the config file, it iterates throug the whole list of bean definitions, including abstract ones, and tries to get them by name (using getBean() method). If a bean happens to be declared abstract=true, such call raises the exception. This leads to inability of abstract bean usage. I've created a simple and stupid patch, I am sure authors will come up with something more gentle, but that's enought for me. Please incorporate the fix future releases. -- 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
Organization and versioning of specs; a new proposal
A while ago there was talks about independently versioning specs, and
Alan started a reorg branch which gives each spec module its own trunk
+branches+tags...
I have been thinking about this for a while, and with the recent
desire to split off more modules from geronimo/trunk I've been
pondering it even more. What I have come to believe is that spitting
up spec modules into their own trunk+branches+tags is probably not
the best direction for us to head in.
I believe that all of our specs can, and should, share one trunk...
and still have each module specify its own version. This is very
similar to how Maven2 plugins is setup, see here:
http://svn.apache.org/repos/asf/maven/plugins
Each plugin has its own version that changes independently. The top-
level pom has a version too, which is independent and is only changed
when there is a major configuration change in that pom.
I recommend that we follow this model for our specs.
The advantage to one trunk, is that it facilitates easy check out and
building when you just want all of the specs. If each spec was in
its own trunk, you would need to svn co each one, then mvn install in
each tree, which is a pain.
We also almost never branch specs, they just keep chugging along,
only really needing tags to track released versions.
So, here is what I propose:
specs/trunk/pom.xml
specs/trunk/artifactId
specs/tags/artifactId/version
And if needed:
specs/branches/artifactId/name
This is a single trunk so to build all specs:
svn co https://svn.apache.org/repos/asf/geronimo/specs/trunk/ specs
cd specs
mvn install
To release an individual spec, say geronimo-spec-jms:
cd specs/geronimo-spec-jms
mvn release
The m2 release plugin can be configured with a _tag base_, which we
can set to:
https://svn.apache.org/repos/asf/geronimo/specs/tags/$
{pom.artifactId}
When released, the plugin will svn cp just the module's directory
into a directory under tags, so it will be easy to see what the
released versions of a specific spec are.
* * *
I really do not see the need for each spec to have its own trunk, and
really I think that if we did then it would just make it more
difficult for cases when we really want all specs.
I do not see any downside to the approach above.
I recommend that we implement this. The only major change, which
isn't that major, is that the properties which live in the root pom
that control the versions need to be removed... or rather moved back
to the version element of the respective pom.
Comments?
--jason
Re: [XBEAN] Mailing lists
It seems that there is a consensus to create these mailing lists.I will raise a JIRA for that on infra.On 8/1/06, Guillaume Nodet [EMAIL PROTECTED] wrote:While looking at http://issues.apache.org/jira/browse/XBEAN-28,I was wondering if we should ask for xbean specific mailing lists. [EMAIL PROTECTED] [EMAIL PROTECTED]Any opinion ? -- Cheers,Guillaume Nodet -- Cheers,Guillaume Nodet
[jira] Created: (AMQ-877) Patch: refactoring to allow alternative (using different storage interface) Destinations implementations.
Patch: refactoring to allow alternative (using different storage interface)
Destinations implementations.
--
Key: AMQ-877
URL: https://issues.apache.org/activemq/browse/AMQ-877
Project: ActiveMQ
Issue Type: Improvement
Components: Broker
Affects Versions: 4.x
Reporter: Maxim Fateev
Attachments: destinationFactoryActiveMQPatch.txt
We were looking at alternate message persistence mechanisms that can co-exist
in current ActiveMQ code base and we are thinking of a mechanism that is
somewhat incompatible with the current MessageStore and PersistenceAdapter
APIs. Unfortunately, the current ActiveMQ broker doesn't allow for such a
change as the PersistenceAdapter and MessageStore interfaces are referenced
directly by the RegionBroker and by both the Queue and Topic region
implementations. Therefore, we are proposing a relatively small backwards
compatible refactoring of the broker code that would eliminate all dependencies
on the PersistenceAdapter and MessageStore interfaces from those classes that
do not use them directly. This refactoring would also allow creation of a
custom Destination implementation that may use an alternative persistence
mechanism on a destination by destination basis (which is exactly what we need
to do).
The main idea behind the refactoring is to replace many references to
PersistenceAdapter with a new interface: DestinationFactory:
public abstract class DestinationFactory {
abstract public Destination createDestination(ConnectionContext
context, ActiveMQDestination destination, DestinationStatistics
destinationStatistics) throws Exception;
abstract public Set getDestinations();
abstract public SubscriptionInfo[]
getAllDurableSubscriptions(ActiveMQTopic topic) throws IOException;
abstract public long getLastMessageBrokerSequenceId() throws
IOException;
abstract public void setRegionBroker(RegionBroker regionBroker);
}
Note that DestinationFactory doesn't mandate any specific persistence
mechanism. The classes that would reference it instead of PersistenceAdapter
are: RegionBroker, AbstractRegion, QueueRegion, and TopicRegion. Also, the
AbstractRegion.createDestination method would be changed from abstract to an
implementation that uses DestinationFactory to create a destination.
BrokerService could be changed to use DestinationFactory if one is
provided. If none is provided, it will create a DestinationFactory
implementation that instantiates Queue and Topic using PersistenceAdapter as it
does currently. Hence, full backwards compatibility will be maintained.
Patch is attached.
--
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: Organization and versioning of specs; a new proposal
Great proposal, I like this. Comment below...
On Aug 11, 2006, at 12:15 PM, Jason Dillon wrote:
[...]
So, here is what I propose:
specs/trunk/pom.xml
specs/trunk/artifactId
specs/tags/artifactId/version
Have you thought about using specs/tags/artifactId-version for
the tag names? That's what maven does, so I'm guessing you noticed
and didn't like it for some reason.
-David
This is a single trunk so to build all specs:
svn co https://svn.apache.org/repos/asf/geronimo/specs/trunk/
specs
cd specs
mvn install
To release an individual spec, say geronimo-spec-jms:
cd specs/geronimo-spec-jms
mvn release
The m2 release plugin can be configured with a _tag base_, which we
can set to:
https://svn.apache.org/repos/asf/geronimo/specs/tags/$
{pom.artifactId}
When released, the plugin will svn cp just the module's directory
into a directory under tags, so it will be easy to see what the
released versions of a specific spec are.
* * *
I really do not see the need for each spec to have its own trunk,
and really I think that if we did then it would just make it more
difficult for cases when we really want all specs.
I do not see any downside to the approach above.
I recommend that we implement this. The only major change, which
isn't that major, is that the properties which live in the root pom
that control the versions need to be removed... or rather moved
back to the version element of the respective pom.
Comments?
--jason
Re: Organization and versioning of specs; a new proposal
Sounds fine to me.
Thanks,
Aaron
On 8/11/06, Jason Dillon [EMAIL PROTECTED] wrote:
A while ago there was talks about independently versioning specs, and
Alan started a reorg branch which gives each spec module its own trunk
+branches+tags...
I have been thinking about this for a while, and with the recent
desire to split off more modules from geronimo/trunk I've been
pondering it even more. What I have come to believe is that spitting
up spec modules into their own trunk+branches+tags is probably not
the best direction for us to head in.
I believe that all of our specs can, and should, share one trunk...
and still have each module specify its own version. This is very
similar to how Maven2 plugins is setup, see here:
http://svn.apache.org/repos/asf/maven/plugins
Each plugin has its own version that changes independently. The top-
level pom has a version too, which is independent and is only changed
when there is a major configuration change in that pom.
I recommend that we follow this model for our specs.
The advantage to one trunk, is that it facilitates easy check out and
building when you just want all of the specs. If each spec was in
its own trunk, you would need to svn co each one, then mvn install in
each tree, which is a pain.
We also almost never branch specs, they just keep chugging along,
only really needing tags to track released versions.
So, here is what I propose:
specs/trunk/pom.xml
specs/trunk/artifactId
specs/tags/artifactId/version
And if needed:
specs/branches/artifactId/name
This is a single trunk so to build all specs:
svn co https://svn.apache.org/repos/asf/geronimo/specs/trunk/ specs
cd specs
mvn install
To release an individual spec, say geronimo-spec-jms:
cd specs/geronimo-spec-jms
mvn release
The m2 release plugin can be configured with a _tag base_, which we
can set to:
https://svn.apache.org/repos/asf/geronimo/specs/tags/$
{pom.artifactId}
When released, the plugin will svn cp just the module's directory
into a directory under tags, so it will be easy to see what the
released versions of a specific spec are.
* * *
I really do not see the need for each spec to have its own trunk, and
really I think that if we did then it would just make it more
difficult for cases when we really want all specs.
I do not see any downside to the approach above.
I recommend that we implement this. The only major change, which
isn't that major, is that the properties which live in the root pom
that control the versions need to be removed... or rather moved back
to the version element of the respective pom.
Comments?
--jason
Re: Deadlock on 4.0.2
Yep it's been fixed in 4.1 but not in the 4.0 branch yet. The commit that fixed this was revision 418966: http://mail-archives.apache.org/mod_mbox/geronimo-activemq-commits/200607.mbox/[EMAIL PROTECTED] It's also got an issue: http://issues.apache.org/activemq/browse/AMQ-792 I wonder what you guys think about porting this fix to the 4.0 branch? Since it does slightly change the API (to make it consistent) it could break folks that are calling this method directly so on one hand we should not make that kind of change to the 4.0 branch. The inconstancy of the naming is a bug IMO so I think we should fix it. On 8/11/06, Guillaume Nodet [EMAIL PROTECTED] wrote: Btw, the docs on http://www.activemq.org/site/consumer-dispatch-async.html refer to dispatchAsync but the code uses asyncDispatch. I guess this is an oversight, right ? On 8/11/06, Hiram Chirino [EMAIL PROTECTED] wrote: I think that if we enable async dispatch this issue should go away. This would only affect vm transport since the transport oneways. We should look into making async to be dispatch be the default when using the vm transport. On 8/11/06, Guillaume Nodet [EMAIL PROTECTED] wrote: I sometime have deadlocks while running junit tests that involve ActiveMQ. Following is a stack trace i dumped. As you can see, the two last threads are deadlocked because of the MutexTransport. This cause the first thread (main thread) to hang forever. Thread [main] (Suspended) MutexTransport.oneway(Command) line: 44 == MutexTransport (id=292) ResponseCorrelator.oneway(Command) line: 58 ManagedTransportConnection(TransportConnection).dispatch(Command) line: 211 ManagedTransportConnection(AbstractConnection).processDispatch(Command) line: 628 ManagedTransportConnection(AbstractConnection).dispatchSync(Command) line: 605 TopicSubscription.dispatch(MessageReference) line: 315 TopicSubscription.add(MessageReference) line: 74 SimpleDispatchPolicy.dispatch(ConnectionContext, MessageReference, MessageEvaluationContext, List) line: 50 Topic.dispatch(ConnectionContext, Message) line: 443 Topic.send(ConnectionContext, Message) line: 254 ManagedTopicRegion(AbstractRegion).send(ConnectionContext, Message) line: 225 ManagedRegionBroker(RegionBroker).send(ConnectionContext, Message) line: 345 TransactionBroker.send(ConnectionContext, Message) line: 192 AdvisoryBroker(BrokerFilter).send(ConnectionContext, Message) line: 113 CompositeDestinationBroker.send(ConnectionContext, Message) line: 97 BrokerService$2(MutableBrokerFilter).send(ConnectionContext, Message) line: 126 ManagedTransportConnection(AbstractConnection).processMessage(Message) line: 377 ActiveMQObjectMessage(ActiveMQMessage).visit(CommandVisitor) line: 590 ManagedTransportConnection(AbstractConnection).service(Command) line: 226 TransportConnection$1.onCommand(Command) line: 62 ResponseCorrelator.onCommand(Command) line: 91 MutexTransport(TransportFilter).onCommand(Command) line: 63 VMTransportServer$1(VMTransport).oneway(Command) line: 76 MutexTransport.oneway(Command) line: 44 = MutexTransport (id=314) ResponseCorrelator.oneway(Command) line: 58 ActiveMQConnection.asyncSendPacket(Command) line: 1092 ActiveMQSession.send(ActiveMQMessageProducer, ActiveMQDestination, Message, int, int, long) line: 1553 ActiveMQMessageProducer.send(Destination, Message, int, int, long) line: 462 ActiveMQMessageProducer.send(Message) line: 356 JCAFlow.sendJmsMessage(Destination, Serializable, boolean, boolean) line: 707 JCAFlow.onInternalEndpointUnregistered(EndpointEvent, boolean) line: 462 JCAFlow$1.internalEndpointUnregistered(EndpointEvent) line: 245 EndpointRegistry.fireEvent(ServiceEndpoint, int) line: 575 EndpointRegistry.unregisterInternalEndpoint(ComponentContext, InternalEndpoint) line: 199 Registry.deactivateEndpoint(ComponentContext, InternalEndpoint) line: 205 ComponentContextImpl.deactivateEndpoint(ServiceEndpoint) line: 157 ReceiverComponent(PojoSupport).shutDown() line: 103 ComponentMBeanImpl.doShutDown() line: 335 ComponentRegistry.shutDown() line: 105 Registry.shutDown() line: 142 SpringJBIContainer(JBIContainer).shutDown() line: 601 SpringJBIContainer.destroy() line: 184 DisposableBeanAdapter.destroy() line: 97 DefaultListableBeanFactory(AbstractBeanFactory).destroyBean(String, Object) line: 1159 DefaultListableBeanFactory(AbstractBeanFactory).destroyDisposableBean(String) line: 1131 DefaultListableBeanFactory(AbstractBeanFactory).destroySingletons() line: 660
Re: Organization and versioning of specs; a new proposal
I like the direction. I think David's comment about
tags/artifact-version works also but tags will get a little busy. If one approach is closer to
Maven behaviour in terms of recommended practices I'd go with that .
Jason Dillon wrote:
A while ago there was talks about independently versioning specs, and
Alan started a reorg branch which gives each spec module its own
trunk+branches+tags...
I have been thinking about this for a while, and with the recent desire
to split off more modules from geronimo/trunk I've been pondering it
even more. What I have come to believe is that spitting up spec modules
into their own trunk+branches+tags is probably not the best direction
for us to head in.
I believe that all of our specs can, and should, share one trunk... and
still have each module specify its own version. This is very similar to
how Maven2 plugins is setup, see here:
http://svn.apache.org/repos/asf/maven/plugins
Each plugin has its own version that changes independently. The
top-level pom has a version too, which is independent and is only
changed when there is a major configuration change in that pom.
I recommend that we follow this model for our specs.
The advantage to one trunk, is that it facilitates easy check out and
building when you just want all of the specs. If each spec was in its
own trunk, you would need to svn co each one, then mvn install in each
tree, which is a pain.
We also almost never branch specs, they just keep chugging along, only
really needing tags to track released versions.
So, here is what I propose:
specs/trunk/pom.xml
specs/trunk/artifactId
specs/tags/artifactId/version
And if needed:
specs/branches/artifactId/name
This is a single trunk so to build all specs:
svn co https://svn.apache.org/repos/asf/geronimo/specs/trunk/ specs
cd specs
mvn install
To release an individual spec, say geronimo-spec-jms:
cd specs/geronimo-spec-jms
mvn release
The m2 release plugin can be configured with a _tag base_, which we can
set to:
https://svn.apache.org/repos/asf/geronimo/specs/tags/${pom.artifactId}
When released, the plugin will svn cp just the module's directory into a
directory under tags, so it will be easy to see what the released
versions of a specific spec are.
* * *
I really do not see the need for each spec to have its own trunk, and
really I think that if we did then it would just make it more difficult
for cases when we really want all specs.
I do not see any downside to the approach above.
I recommend that we implement this. The only major change, which isn't
that major, is that the properties which live in the root pom that
control the versions need to be removed... or rather moved back to the
version element of the respective pom.
Comments?
--jason
Re: Yoko and Geronimo
Rick, I believe what you really want to do is to use the endorsed directory. This allows you to override the vm implementation of endorsed specification such as corba (https://java.sun.com/j2se/1.5.0/ docs/guide/standards/index.html). In general, you should try to keep the stuff in the endorsed jar to a minimum as not to pollute the class path. In geronimo, to add something to the endorsed dir, you need to add it to our endorsed manifest entry Endorsed-Dirs (I have no idea where this is set in the build) and you need to modify the build to put the jar into lib/endorsed by modifying the bin.xml. -dain On Aug 11, 2006, at 7:41 AM, Rick McGuire wrote: I've run into an interesting snag with getting Geronimo to run with the Yoko ORB. Because there in an inherent conflict with some of the class files that ship with the JVM, it is necessary to prepend the yoko jar file to the bootclasspath when launching the server. This sort of lies outside of the realm of normal execution dependencies. I suppose it can added to the startup batch file, but this means Geronimo can no longer be started by just doing java server.jar. Additionally, if the Yoko jar is on the bootclasspath, then the Sun version of the ORB adaptor will not function. This is an either/or situation, and the choice, unfortunately, must be made before the JVM is launched. This even comes into play during the build, because there are unit tests for the SunNameService (and also the YokoNameService). Any thoughts on how we should handle this particularly awkward situation? Rick
Re: Organization and versioning of specs; a new proposal
This is a good idea. I like it.
+1
Cheers
Prasad
On 8/11/06, Aaron Mulder [EMAIL PROTECTED] wrote:
Sounds fine to me.
Thanks,
Aaron
On 8/11/06, Jason Dillon [EMAIL PROTECTED] wrote:
A while ago there was talks about independently versioning specs, and
Alan started a reorg branch which gives each spec module its own trunk
+branches+tags...
I have been thinking about this for a while, and with the recent
desire to split off more modules from geronimo/trunk I've been
pondering it even more. What I have come to believe is that spitting
up spec modules into their own trunk+branches+tags is probably not
the best direction for us to head in.
I believe that all of our specs can, and should, share one trunk...
and still have each module specify its own version. This is very
similar to how Maven2 plugins is setup, see here:
http://svn.apache.org/repos/asf/maven/plugins
Each plugin has its own version that changes independently. The top-
level pom has a version too, which is independent and is only changed
when there is a major configuration change in that pom.
I recommend that we follow this model for our specs.
The advantage to one trunk, is that it facilitates easy check out and
building when you just want all of the specs. If each spec was in
its own trunk, you would need to svn co each one, then mvn install in
each tree, which is a pain.
We also almost never branch specs, they just keep chugging along,
only really needing tags to track released versions.
So, here is what I propose:
specs/trunk/pom.xml
specs/trunk/artifactId
specs/tags/artifactId/version
And if needed:
specs/branches/artifactId/name
This is a single trunk so to build all specs:
svn co https://svn.apache.org/repos/asf/geronimo/specs/trunk/ specs
cd specs
mvn install
To release an individual spec, say geronimo-spec-jms:
cd specs/geronimo-spec-jms
mvn release
The m2 release plugin can be configured with a _tag base_, which we
can set to:
https://svn.apache.org/repos/asf/geronimo/specs/tags/$
{pom.artifactId}
When released, the plugin will svn cp just the module's directory
into a directory under tags, so it will be easy to see what the
released versions of a specific spec are.
* * *
I really do not see the need for each spec to have its own trunk, and
really I think that if we did then it would just make it more
difficult for cases when we really want all specs.
I do not see any downside to the approach above.
I recommend that we implement this. The only major change, which
isn't that major, is that the properties which live in the root pom
that control the versions need to be removed... or rather moved back
to the version element of the respective pom.
Comments?
--jason
Re: Organization and versioning of specs; a new proposal
This feels like an excellent compromise where we can easily build
them together and they can be independently versioned.
-dain
On Aug 11, 2006, at 12:15 PM, Jason Dillon wrote:
A while ago there was talks about independently versioning specs,
and Alan started a reorg branch which gives each spec module its
own trunk+branches+tags...
I have been thinking about this for a while, and with the recent
desire to split off more modules from geronimo/trunk I've been
pondering it even more. What I have come to believe is that
spitting up spec modules into their own trunk+branches+tags is
probably not the best direction for us to head in.
I believe that all of our specs can, and should, share one trunk...
and still have each module specify its own version. This is very
similar to how Maven2 plugins is setup, see here:
http://svn.apache.org/repos/asf/maven/plugins
Each plugin has its own version that changes independently. The
top-level pom has a version too, which is independent and is only
changed when there is a major configuration change in that pom.
I recommend that we follow this model for our specs.
The advantage to one trunk, is that it facilitates easy check out
and building when you just want all of the specs. If each spec was
in its own trunk, you would need to svn co each one, then mvn
install in each tree, which is a pain.
We also almost never branch specs, they just keep chugging along,
only really needing tags to track released versions.
So, here is what I propose:
specs/trunk/pom.xml
specs/trunk/artifactId
specs/tags/artifactId/version
And if needed:
specs/branches/artifactId/name
This is a single trunk so to build all specs:
svn co https://svn.apache.org/repos/asf/geronimo/specs/trunk/
specs
cd specs
mvn install
To release an individual spec, say geronimo-spec-jms:
cd specs/geronimo-spec-jms
mvn release
The m2 release plugin can be configured with a _tag base_, which we
can set to:
https://svn.apache.org/repos/asf/geronimo/specs/tags/$
{pom.artifactId}
When released, the plugin will svn cp just the module's directory
into a directory under tags, so it will be easy to see what the
released versions of a specific spec are.
* * *
I really do not see the need for each spec to have its own trunk,
and really I think that if we did then it would just make it more
difficult for cases when we really want all specs.
I do not see any downside to the approach above.
I recommend that we implement this. The only major change, which
isn't that major, is that the properties which live in the root pom
that control the versions need to be removed... or rather moved
back to the version element of the respective pom.
Comments?
--jason
Re: Organization and versioning of specs; a new proposal
On Aug 11, 2006, at 12:32 PM, David Blevins wrote:
Have you thought about using specs/tags/artifactId-version for
the tag names? That's what maven does, so I'm guessing you noticed
and didn't like it for some reason.
The issue with that is that specs/tags becomes massive over time and
not easy to grok.
But you are right, the release plugin puts the artifact on there too,
so its more like:
specs/tags/artifactId/artifactId-version
--jason
-David
This is a single trunk so to build all specs:
svn co https://svn.apache.org/repos/asf/geronimo/specs/trunk/
specs
cd specs
mvn install
To release an individual spec, say geronimo-spec-jms:
cd specs/geronimo-spec-jms
mvn release
The m2 release plugin can be configured with a _tag base_, which
we can set to:
https://svn.apache.org/repos/asf/geronimo/specs/tags/$
{pom.artifactId}
When released, the plugin will svn cp just the module's directory
into a directory under tags, so it will be easy to see what the
released versions of a specific spec are.
* * *
I really do not see the need for each spec to have its own trunk,
and really I think that if we did then it would just make it more
difficult for cases when we really want all specs.
I do not see any downside to the approach above.
I recommend that we implement this. The only major change, which
isn't that major, is that the properties which live in the root
pom that control the versions need to be removed... or rather
moved back to the version element of the respective pom.
Comments?
--jason
RE: Yoko and Geronimo
If the ORB wants to be 3.0 compliant, then yes... java.endorsed.dirs is the preferred way that sun wants to follow for these cases... - Balaji -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Aaron Mulder Sent: Friday, August 11, 2006 3:08 PM To: dev@geronimo.apache.org Subject: Re: Yoko and Geronimo Are you saying that every open source and commercial ORB that wants to run under JDK 1.5.0 requires one of these two approaches? That no one has come up with a workaround that doesn't require user intervention? Thanks, Aaron On 8/11/06, Mosur Ravi, Balaji [EMAIL PROTECTED] wrote: The JDK class http://java.sun.com/j2se/1.5.0/docs/api/org/omg/PortableInterceptor/IORI nterceptor_3_0Operations.html#adapter_manager_state_changed(int,%20short ) doesn't correctly implement the corba 3.0 spec... This method should have a string as the manager ID. Anyways, there are 2 ways to handle this... 1) java.endorsed.dirs setting 2) xbootclasspath - Balaji -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Aaron Mulder Sent: Friday, August 11, 2006 10:57 AM To: dev@geronimo.apache.org Subject: Re: Yoko and Geronimo On 8/11/06, Rick McGuire [EMAIL PROTECTED] wrote: ... Any thoughts on how we should handle this particularly awkward situation? I vote we (e.g. Yoko) do whatever it takes to avoid the class conflict, and then Geronimo can forget about the JVM ORB forever. Do we know how other open source ORBs handle the conflict? Thanks, Aaron
Re: NoClassDefFoundError: org/apache/geronimo/deployment/plugin/ConfigIDExtractor
Any idea how to fix? I have already committed the change that Anita posted about scope instead of type... ConfigIDExtractor is part of geronimo-deploy-jsr88, which is a dependency of the hot-deployer config. Does it need a scope? Right now it has the default scope. I really don't like how we are overloading the scope mechanism like this either. If we need to add additional metadata to a dependency, then we can easily move the dependency def into a plugin's configuration... very similar to how the maven-dependency-plugin works. --jason On Aug 11, 2006, at 6:39 AM, Prasad Kashyap wrote: Jason, http://www.mail-archive.com/dev@geronimo.apache.org/msg29265.html Cheers Prasad On 8/11/06, Jason Dillon [EMAIL PROTECTED] wrote: Anyone know why this error gets spit out after the server boots? snip java.lang.NoClassDefFoundError: org/apache/geronimo/deployment/ plugin/ ConfigIDExtractor at java.lang.ClassLoader.defineClass0(Native Method) at java.lang.ClassLoader.defineClass(ClassLoader.java:539) at java.security.SecureClassLoader.defineClass (SecureClassLoader.java:123) at org.apache.geronimo.kernel.classloader.JarFileClassLoader.access$200 (JarFileClassLoader.java:51) at org.apache.geronimo.kernel.classloader.JarFileClassLoader $6.run(JarFileClassLoader.java:275) at java.security.AccessController.doPrivileged(Native Method) at org.apache.geronimo.kernel.classloader.JarFileClassLoader.findClass (JarFileClassLoader.java:227) at org.apache.geronimo.kernel.config.MultiParentClassLoader.loadClass (MultiParentClassLoader.java:243) at java.lang.ClassLoader.loadClass(ClassLoader.java:235) at org.apache.geronimo.kernel.config.MultiParentClassLoader.loadClass (MultiParentClassLoader.java:227) at java.lang.ClassLoader.loadClass(ClassLoader.java:235) at org.apache.geronimo.kernel.config.MultiParentClassLoader.loadClass (MultiParentClassLoader.java:227) at java.lang.ClassLoader.loadClass(ClassLoader.java:235) at java.lang.ClassLoader.loadClassInternal(ClassLoader.java: 302) at org.apache.geronimo.deployment.hot.DirectoryMonitor.calculateModuleId (DirectoryMonitor.java:358) at org.apache.geronimo.deployment.hot.DirectoryMonitor.initialize (DirectoryMonitor.java:230) at org.apache.geronimo.deployment.hot.DirectoryMonitor.run (DirectoryMonitor.java:206) at java.lang.Thread.run(Thread.java:552) /snip --jason
Re: Yoko and Geronimo
That is just to put the jar into a dir, which the system property java.endorsed.dirs points to? --jason On Aug 11, 2006, at 12:51 PM, Mosur Ravi, Balaji wrote: If the ORB wants to be 3.0 compliant, then yes... java.endorsed.dirs is the preferred way that sun wants to follow for these cases... - Balaji -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Aaron Mulder Sent: Friday, August 11, 2006 3:08 PM To: dev@geronimo.apache.org Subject: Re: Yoko and Geronimo Are you saying that every open source and commercial ORB that wants to run under JDK 1.5.0 requires one of these two approaches? That no one has come up with a workaround that doesn't require user intervention? Thanks, Aaron On 8/11/06, Mosur Ravi, Balaji [EMAIL PROTECTED] wrote: The JDK class http://java.sun.com/j2se/1.5.0/docs/api/org/omg/PortableInterceptor/ IORI nterceptor_3_0Operations.html#adapter_manager_state_changed(int,% 20short ) doesn't correctly implement the corba 3.0 spec... This method should have a string as the manager ID. Anyways, there are 2 ways to handle this... 1) java.endorsed.dirs setting 2) xbootclasspath - Balaji -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Aaron Mulder Sent: Friday, August 11, 2006 10:57 AM To: dev@geronimo.apache.org Subject: Re: Yoko and Geronimo On 8/11/06, Rick McGuire [EMAIL PROTECTED] wrote: ... Any thoughts on how we should handle this particularly awkward situation? I vote we (e.g. Yoko) do whatever it takes to avoid the class conflict, and then Geronimo can forget about the JVM ORB forever. Do we know how other open source ORBs handle the conflict? Thanks, Aaron
Re: Yoko and Geronimo
FYI, in 1.2, the lib/ and lib/endorsed/* bits are now configured in geronimo-boilerplate-minimal/pom.xml... which is picked up by all of the assemblies. --jason On Aug 11, 2006, at 12:40 PM, Dain Sundstrom wrote: Rick, I believe what you really want to do is to use the endorsed directory. This allows you to override the vm implementation of endorsed specification such as corba (https://java.sun.com/j2se/ 1.5.0/docs/guide/standards/index.html). In general, you should try to keep the stuff in the endorsed jar to a minimum as not to pollute the class path. In geronimo, to add something to the endorsed dir, you need to add it to our endorsed manifest entry Endorsed-Dirs (I have no idea where this is set in the build) and you need to modify the build to put the jar into lib/endorsed by modifying the bin.xml. -dain On Aug 11, 2006, at 7:41 AM, Rick McGuire wrote: I've run into an interesting snag with getting Geronimo to run with the Yoko ORB. Because there in an inherent conflict with some of the class files that ship with the JVM, it is necessary to prepend the yoko jar file to the bootclasspath when launching the server. This sort of lies outside of the realm of normal execution dependencies. I suppose it can added to the startup batch file, but this means Geronimo can no longer be started by just doing java server.jar. Additionally, if the Yoko jar is on the bootclasspath, then the Sun version of the ORB adaptor will not function. This is an either/or situation, and the choice, unfortunately, must be made before the JVM is launched. This even comes into play during the build, because there are unit tests for the SunNameService (and also the YokoNameService). Any thoughts on how we should handle this particularly awkward situation? Rick
Re: [XBEAN] Mailing lists
I can help by being a moderator. Regards, Alan Guillaume Nodet wrote: It seems that there is a consensus to create these mailing lists. I will raise a JIRA for that on infra. On 8/1/06, Guillaume Nodet [EMAIL PROTECTED] wrote: While looking at http://issues.apache.org/jira/browse/XBEAN-28, I was wondering if we should ask for xbean specific mailing lists. [EMAIL PROTECTED] [EMAIL PROTECTED] Any opinion ? -- Cheers, Guillaume Nodet -- Cheers, Guillaume Nodet
Re: Organization and versioning of specs; a new proposal
Makes sense to me too. +1
Joe
Jason Dillon wrote:
A while ago there was talks about independently versioning specs, and
Alan started a reorg branch which gives each spec module its own trunk
+branches+tags...
I have been thinking about this for a while, and with the recent desire
to split off more modules from geronimo/trunk I've been pondering it
even more. What I have come to believe is that spitting up spec
modules into their own trunk+branches+tags is probably not the best
direction for us to head in.
I believe that all of our specs can, and should, share one trunk... and
still have each module specify its own version. This is very similar
to how Maven2 plugins is setup, see here:
http://svn.apache.org/repos/asf/maven/plugins
Each plugin has its own version that changes independently. The top-
level pom has a version too, which is independent and is only changed
when there is a major configuration change in that pom.
I recommend that we follow this model for our specs.
The advantage to one trunk, is that it facilitates easy check out and
building when you just want all of the specs. If each spec was in its
own trunk, you would need to svn co each one, then mvn install in each
tree, which is a pain.
We also almost never branch specs, they just keep chugging along, only
really needing tags to track released versions.
So, here is what I propose:
specs/trunk/pom.xml
specs/trunk/artifactId
specs/tags/artifactId/version
And if needed:
specs/branches/artifactId/name
This is a single trunk so to build all specs:
svn co https://svn.apache.org/repos/asf/geronimo/specs/trunk/ specs
cd specs
mvn install
To release an individual spec, say geronimo-spec-jms:
cd specs/geronimo-spec-jms
mvn release
The m2 release plugin can be configured with a _tag base_, which we can
set to:
https://svn.apache.org/repos/asf/geronimo/specs/tags/$ {pom.artifactId}
When released, the plugin will svn cp just the module's directory into
a directory under tags, so it will be easy to see what the released
versions of a specific spec are.
* * *
I really do not see the need for each spec to have its own trunk, and
really I think that if we did then it would just make it more difficult
for cases when we really want all specs.
I do not see any downside to the approach above.
I recommend that we implement this. The only major change, which isn't
that major, is that the properties which live in the root pom that
control the versions need to be removed... or rather moved back to the
version element of the respective pom.
Comments?
--jason
Board report
The board report is due this month. I have edited it, but feel free to add / change anything needed. http://wiki.apache.org/incubator/August2006 -- Cheers, Guillaume Nodet
Re: Board report
On 8/11/06, Guillaume Nodet [EMAIL PROTECTED] wrote: The board report is due this month. I have edited it, but feel free to add / change anything needed. http://wiki.apache.org/incubator/August2006 Shall we add the addition of a new committer? 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: svn commit: r430833 - /geronimo/branches/1.1/modules/activation/src/test/org/apache/geronimo/activation/handlers/MailcapTest.java
Rick,
Did you intend to just add this println or were you really planning to
remove the part (as you did with trunk).
Joe
[EMAIL PROTECTED] wrote:
Author: rickmcguire
Date: Fri Aug 11 10:26:32 2006
New Revision: 430833
URL: http://svn.apache.org/viewvc?rev=430833view=rev
Log:
GERONIMO-2209 - Enable tests (geronimo-activation :: **/MailcapTest.java)
Delete invalid MailcapTest.
Modified:
geronimo/branches/1.1/modules/activation/src/test/org/apache/geronimo/activation/handlers/MailcapTest.java
Modified:
geronimo/branches/1.1/modules/activation/src/test/org/apache/geronimo/activation/handlers/MailcapTest.java
URL:
http://svn.apache.org/viewvc/geronimo/branches/1.1/modules/activation/src/test/org/apache/geronimo/activation/handlers/MailcapTest.java?rev=430833r1=430832r2=430833view=diff
==
---
geronimo/branches/1.1/modules/activation/src/test/org/apache/geronimo/activation/handlers/MailcapTest.java
(original)
+++
geronimo/branches/1.1/modules/activation/src/test/org/apache/geronimo/activation/handlers/MailcapTest.java
Fri Aug 11 10:26:32 2006
@@ -31,6 +31,7 @@
public void testTextPlainHandler() {
CommandInfo info = map.getCommand(text/plain, content-handler);
+System.out.println(Command handler classname is +
info.getCommandClass());
assertEquals(TextPlainHandler.class.getName(), info.getCommandClass());
}
[jira] Updated: (GERONIMO-2319) Unable to create a new OpenWire Listener from console
[ http://issues.apache.org/jira/browse/GERONIMO-2319?page=all ] Donald Woods updated GERONIMO-2319: --- Fix Version/s: 1.2 Affects Version/s: 1.1 1.0 (was: 1.2) Duplicate of [GERONIMO-1786|http://issues.apache.org/jira/browse/GERONIMO-1786] Unable to create a new OpenWire Listener from console - Key: GERONIMO-2319 URL: http://issues.apache.org/jira/browse/GERONIMO-2319 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: ActiveMQ, console Affects Versions: 1.1, 1.0 Environment: Geronimo 1.1 Reporter: Krishnakumar B Fix For: 1.2 I am unable to create a new openwire listener from console. I get the following exception 12:51:25,081 ERROR [GBeanInstanceState] Error while starting; GBean is now in the FAILED state: abstractName=geronimo/activemq-broker/1.1/car?JMSServer=ActiveMQ,ServiceModule=geronimo/activemq-broker/1.1/car,j2eeType=GBean,name=NewOpenWire javax.jms.JMSException: Could not load protocol: openwire. Reason: java.lang.ClassNotFoundException: org.activemq.transport.openwire.OpenWireTransportServerChannelFactory in classloader geronimo/activemq-broker/1.1/car at org.activemq.transport.TransportServerChannelProvider.createJMSexception(TransportServerChannelProvider.java:85) at org.activemq.transport.TransportServerChannelProvider.getFactory(TransportServerChannelProvider.java:79) at org.activemq.transport.TransportServerChannelProvider.create(TransportServerChannelProvider.java:45) at org.activemq.broker.impl.BrokerConnectorImpl.createTransportServerChannel(BrokerConnectorImpl.java:425) at org.activemq.broker.impl.BrokerConnectorImpl.init(BrokerConnectorImpl.java:69) at org.activemq.gbean.ActiveMQConnectorGBean.createBrokerConnector(ActiveMQConnectorGBean.java:160) at org.activemq.gbean.ActiveMQConnectorGBean.doStart(ActiveMQConnectorGBean.java:128) at org.apache.geronimo.gbean.runtime.GBeanInstance.createInstance(GBeanInstance.java:981) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStart(GBeanInstanceState.java:267) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.start(GBeanInstanceState.java:102) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.startRecursive(GBeanInstanceState.java:124) at org.apache.geronimo.gbean.runtime.GBeanInstance.startRecursive(GBeanInstance.java:540) at org.apache.geronimo.kernel.basic.BasicKernel.startRecursiveGBean(BasicKernel.java:379) at org.apache.geronimo.kernel.basic.ProxyMethodInterceptor$StartRecursiveInvoke.invoke(ProxyMethodInterceptor.java:365) at org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept(ProxyMethodInterceptor.java:96) at org.activemq.gbean.ActiveMQConnector$$EnhancerByCGLIB$$c6a55a11.startRecursive(generated) at org.apache.geronimo.console.jmsmanager.server.JMSConnectorPortlet.processAction(JMSConnectorPortlet.java:83) at org.apache.pluto.core.PortletServlet.dispatch(PortletServlet.java:229) at org.apache.pluto.core.PortletServlet.doGet(PortletServlet.java:158) at javax.servlet.http.HttpServlet.service(HttpServlet.java:595) at javax.servlet.http.HttpServlet.service(HttpServlet.java:688) at org.apache.pluto.core.PortletServlet.service(PortletServlet.java:153) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173) at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:672) at org.apache.catalina.core.ApplicationDispatcher.doInclude(ApplicationDispatcher.java:574) at org.apache.catalina.core.ApplicationDispatcher.include(ApplicationDispatcher.java:499) at org.apache.pluto.invoker.impl.PortletInvokerImpl.invoke(PortletInvokerImpl.java:120) at org.apache.pluto.invoker.impl.PortletInvokerImpl.action(PortletInvokerImpl.java:68) at org.apache.pluto.PortletContainerImpl.processPortletAction(PortletContainerImpl.java:164) at org.apache.pluto.portalImpl.core.PortletContainerWrapperImpl.processPortletAction(PortletContainerWrapperImpl.java:82) at org.apache.pluto.portalImpl.Servlet.doGet(Servlet.java:227) at javax.servlet.http.HttpServlet.service(HttpServlet.java:595) at javax.servlet.http.HttpServlet.service(HttpServlet.java:688) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
ActiveMQ v4 and Geronimo
Anyone know what the status is of the ActiveMQ v4 integration into Geronimo? A while pack some modules were added to trunk, but looks like those modules were never hooked up... so right now we depend on 3.2.4-SNAPSHOT and 4.0.1. Can we get this resolved, and get G 1.2 (trunk) on ActiveMQ v4? --jason
What is left to merge from dead-1.2?
Can we get this finished... so we can move forward and setup modules to use the m2 standard layout? Also, if there is a list of modules which no merge is needed, we can update them now. Anyone know? --jason
Re: Yoko and Geronimo
On Aug 11, 2006, at 12:40 PM, Dain Sundstrom wrote: Rick, I believe what you really want to do is to use the endorsed directory. This allows you to override the vm implementation of endorsed specification such as corba (https://java.sun.com/j2se/ 1.5.0/docs/guide/standards/index.html). In general, you should try to keep the stuff in the endorsed jar to a minimum as not to pollute the class path. In geronimo, to add something to the endorsed dir, you need to add it to our endorsed manifest entry Endorsed-Dirs (I have no idea where this is set in the build) and you need to modify the build to put the jar into lib/endorsed by modifying the bin.xml. I'm dumb. You simply need to add the jar to lib/endorsed jar in the boilerplate config (thanks Jason), and add it to the manifest class path of the j2ee-system configuration (see the pom file in that dir). It will be added to the system class path and marked as endorsed so it can override the corba specs just like we override the xml specs using xerces. -dain
Re: Yoko and Geronimo
Cool, that's a lot nicer than I had thought. Thanks, Aaron On 8/11/06, Dain Sundstrom [EMAIL PROTECTED] wrote: I'm dumb. You simply need to add the jar to lib/endorsed jar in the boilerplate config (thanks Jason), and add it to the manifest class path of the j2ee-system configuration (see the pom file in that dir). It will be added to the system class path and marked as endorsed so it can override the corba specs just like we override the xml specs using xerces.
[jira] Created: (SM-535) Allow interface to be used with jsr181 annotations
Allow interface to be used with jsr181 annotations -- Key: SM-535 URL: https://issues.apache.org/activemq/browse/SM-535 Project: ServiceMix Issue Type: Bug Components: servicemix-jsr181 Reporter: Guillaume Nodet Assigned To: Guillaume Nodet Fix For: 3.0-M3 See http://www.nabble.com/Re%3A-Spring-transaction-proxy-with-jsr181-POJO-p5690463.html -- 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: [XBEAN] Mailing lists
me 2 -dain On Aug 11, 2006, at 1:09 PM, Alan D. Cabrera wrote: I can help by being a moderator. Regards, Alan Guillaume Nodet wrote: It seems that there is a consensus to create these mailing lists. I will raise a JIRA for that on infra. On 8/1/06, Guillaume Nodet [EMAIL PROTECTED] wrote: While looking at http://issues.apache.org/jira/browse/XBEAN-28, I was wondering if we should ask for xbean specific mailing lists. [EMAIL PROTECTED] [EMAIL PROTECTED] Any opinion ? -- Cheers, Guillaume Nodet -- Cheers, Guillaume Nodet
[jira] Resolved: (SM-535) Allow interface to be used with jsr181 annotations
[ https://issues.apache.org/activemq/browse/SM-535?page=all ] Guillaume Nodet resolved SM-535. Resolution: Fixed Author: gnodet Date: Fri Aug 11 14:00:22 2006 New Revision: 430895 URL: http://svn.apache.org/viewvc?rev=430895view=rev Log: SM-535: Allow interface to be used with jsr181 annotations Added: incubator/servicemix/trunk/servicemix-jsr181/src/test/java/org/apache/servicemix/jsr181/Jsr181SpringProxyTest.java incubator/servicemix/trunk/servicemix-jsr181/src/test/resources/org/apache/servicemix/jsr181/spring-proxy.xml Modified: incubator/servicemix/trunk/servicemix-jsr181/pom.xml incubator/servicemix/trunk/servicemix-jsr181/src/main/java/org/apache/servicemix/jsr181/Jsr181Endpoint.java incubator/servicemix/trunk/servicemix-jsr181/src/test/java/test/Echo.java Allow interface to be used with jsr181 annotations -- Key: SM-535 URL: https://issues.apache.org/activemq/browse/SM-535 Project: ServiceMix Issue Type: Bug Components: servicemix-jsr181 Reporter: Guillaume Nodet Assigned To: Guillaume Nodet Fix For: 3.0-M3 See http://www.nabble.com/Re%3A-Spring-transaction-proxy-with-jsr181-POJO-p5690463.html -- 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
AJAX and Geronimo
Dojo is a popular open source AJAX library that's available under the BSD and Academic Free licenses. The DayTrader folks use it in the web UI they recently announced on the Geronimo dev list and Chris used it in the nice LDAP UI he did for GERONIMO-1823. I would also like to start introducing some use of it into the Geronimo admin console when its appropriate to do so. The way that developers usually incorporate an AJAX library into their applications is by making a copy of its static files (javascript, css, gifs, etc) in their webapp and referencing them from their servlets and JSPs. The obvious downside is that each application has a separate copy of the AJAX library, increasing the server's overall disk footprint (Dojo is ~3mb) and preventing the browser from using a single copy of the library files from its cache. Another downside is that the AJAX library can't be upgraded independently from the web application. I think it would be great if Geronimo could provide a more AJAX friendly development environment by helping solve these problems. One idea is that Geronimo could include the Dojo library as a native, standalone webapp with its AJAX library files laid out so that other applications can point at from their HTML. Referencing it in geronimo-web.xml would cause Geronimo to start it up and make its files available at some predetermined context root, say /dojo. Referencing it with a versionless moduleId would make sure the most recent version is always used. So AJAX enabling your application in Geronimo would be a simple as add this line to your geronimo-web.xml. Does this sound like a good idea? Any suggestions or concerns? Perhaps this could be done as a plugin instead of a native module? Best wishes, Paul
