Re: Kaha package re-rog
+1, of course On 9/5/06, Hiram Chirino [EMAIL PROTECTED] wrote: Howdy Folks, In the interest of making the kaha.impl package a little easier to grok, I was think that perhaps we split it up into a kaha.impl.data, kaha.impl.index, and kaha.impl.container packages. Since each builds on the other. Any objections? -- Regards, Hiram Blog: http://hiramchirino.com -- Cheers, Guillaume Nodet
[jira] Assigned: (AMQ-876) Kaha DB cannot locate queue data files
[ https://issues.apache.org/activemq/browse/AMQ-876?page=all ] Rob Davies reassigned AMQ-876: -- Assignee: Rob Davies 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 Assigned To: Rob Davies 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
[jira] Commented: (AMQ-903) ActivemMQ slows down after a rather small number of messages
[ https://issues.apache.org/activemq/browse/AMQ-903?page=comments#action_36907 ] Daniel Aioanei commented on AMQ-903: It seems that by specifying jms.useAsyncSend=true in the connection url, the throughput stays more or less constant even with a postgresql backend, and a single producer thread is enough to get the maximum performance. ActivemMQ slows down after a rather small number of messages Key: AMQ-903 URL: https://issues.apache.org/activemq/browse/AMQ-903 Project: ActiveMQ Issue Type: Bug Affects Versions: 4.0.1 Reporter: Daniel Aioanei Attachments: activemq.xml I have activemq with a postgresql backend running as a standalone server, and a client application that produces persistent messages in 50 threads. Each time I run my app it pushes as many msg as it can for about 62.5 seconds after which it quits. Although initially it works fast, every time I run my app it produces less messages: enqueue speed 50 threads: msg/second: 334.183334 second time: msg/second: 194.15 third time: msg/second: 123.0 fourth time: msg/second: 58.616667 fifth time: msg/second: 19.434 sixth time: msg/second: 33.816667 seventh time: msg/second: 11.783 eigth time: msg/second: 24.734 ninght time: msg/second: 10.883 After I ran the above test there seem to be 50241 msg in that queue. activemq= select count(1) from activemq_msgs ; count --- 50241 (1 row) activemq= select count(1) from activemq_acks ; count --- 0 (1 row) Note that I don't have any message consumers active for this test. Here is the way the client app connects: bean id=jmsResourceAdapter class=org.apache.activemq.ra.ActiveMQResourceAdapter property name=serverUrl value=tcp://localhost:61616?wireFormat.cacheEnabled=falseamp;wireFormat.tightEncodingEnabled=false / /bean -- 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
Can you set maven to build without updating plugins, etc without heavy modifications to poms?
Hi guys, I need to get activemq to build without maven searching for updates, etc. The only way I know of doing that right now is to manually edit all pom files and set static versions. But that would require a lot of modifications to the poms, which I would rather avoid. Does anyone know a better way? I know this could be asked in the maven boards, but I'd rather get info from people familiar with the specifics of activemq. Regards, Sepand
Re: Can you set maven to build without updating plugins, etc without heavy modifications to poms?
you can build offline with -o. It just builds off you local repo. maven also has a command to manually install artifacts to the local repo if that's what your looking for. On 9/5/06, Sepand M [EMAIL PROTECTED] wrote: Hi guys, I need to get activemq to build without maven searching for updates, etc. The only way I know of doing that right now is to manually edit all pom files and set static versions. But that would require a lot of modifications to the poms, which I would rather avoid. Does anyone know a better way? I know this could be asked in the maven boards, but I'd rather get info from people familiar with the specifics of activemq. Regards, Sepand -- Regards, Hiram Blog: http://hiramchirino.com
Re: Can you set maven to build without updating plugins, etc without heavy modifications to poms?
something like: mvn install:install-file -DgroupId=org.apache.directory.server -DartifactId=apacheds-protocol-kerberos -Dversion=1.0-RC3 -Dpackaging=jar -Dfile=/path/to/file and you would have to do this for each dependency.. so I'm not sure how good this idea really is. On 9/5/06, Sepand M [EMAIL PROTECTED] wrote: That would be great actually, do you know what that command is? And where does it install the artifacts? (I need everything to be in one neat directory) On 9/5/06, Hiram Chirino [EMAIL PROTECTED] wrote: you can build offline with -o. It just builds off you local repo. maven also has a command to manually install artifacts to the local repo if that's what your looking for. On 9/5/06, Sepand M [EMAIL PROTECTED] wrote: Hi guys, I need to get activemq to build without maven searching for updates, etc. The only way I know of doing that right now is to manually edit all pom files and set static versions. But that would require a lot of modifications to the poms, which I would rather avoid. Does anyone know a better way? I know this could be asked in the maven boards, but I'd rather get info from people familiar with the specifics of activemq. Regards, Sepand -- Regards, Hiram Blog: http://hiramchirino.com -- Regards, Hiram Blog: http://hiramchirino.com
Re: Core-Jaas dependencies ... again
Responses below On 9/5/06, Guillaume Nodet [EMAIL PROTECTED] wrote: What do you mean by non optional dependency ? A dependency can always be set as optional, and actually is until you use it. The way things are, core always needs jaas, so it's not really optional. I guess the other solution is to create a module for these classes only, but i' m not sure it' s worth it. I highly doubt it's worth the effort. On 9/5/06, Sepand M [EMAIL PROTECTED] wrote: Hi guys, I brought this up before and I thought it was solved, but it isn't. The basic problem is that JaasAuthenticationBroker, JaasCertificationAuthenticationBroker (that's a new class), and their supporting classes need Broker, BrokerFilter, etc. and also need JaasCertificateCallback (also new), etc. Broker, BrokerFilter are in the core module (for obvious reasons) and JaasCertificateCallback, etc. are in Jaas module. This forces a non-optional dependency between core and jaas, which from what I understand we are trying to avoid. Moving JaasAuthenticationBroker and JaasCertificationAuthenticationBroker to jaas is not an option (as far as I know) since mvn doesn't allow a circular dependency (from core to jaas and back to core). Obviously moving everything into core is dumb. So... any suggestions? Regards, Sepand -- Cheers, Guillaume Nodet
[jira] Created: (AMQ-911) Transient connection failure with Failover transport can cause InvalidClientIDException
Transient connection failure with Failover transport can cause InvalidClientIDException --- Key: AMQ-911 URL: https://issues.apache.org/activemq/browse/AMQ-911 Project: ActiveMQ Issue Type: Bug Affects Versions: 4.0 Reporter: Hiram Chirino Assigned To: Hiram Chirino Fix For: 4.1, 4.0.2 It shows up as errors on the broker log: Error occured while processing sync command: javax.jms.InvalidClientIDException: Broker: localhost - Client: ID:hchirino-mac.local-51624-1157486953862-2:0 already connected -- 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: servicemix-http and normalization
I don't recall there being anything in WSI-BP that prohibits the usage of RPC-literal encoding, which results in multiple parts. -mbs On 9/5/06, Alex Boisvert [EMAIL PROTECTED] wrote: Oh yes, good question! The point of mapping headers into message content is that many applications/frameworks do not give you easy access (or advise against accessing) message headers. Take, for example, BPEL processes. BPEL only gives you access to the abstract message definition. If headers are not defined and mapped into the content, you can't access them in a portable way. Maybe we could have a configuration attribute to normalize using WSDL 1.1 or WSDL 2.0? That way, if there are no mapped headers and only one SOAP body element, then we could have basic support for WSDL 2.0. I'm very interested in getting full WSDL 1.1 support because that's what's mostly used and deployed today. The tooling and infrastructure ecosystem works great with WSDL 1.1 but still has ways to go with WSDL 2.0. With complete WSDL 1.1 support, we can make the most of ServiceMix today and gradually migrate to WSDL 2.0 when it becomes more widespread. alex Guillaume Nodet wrote: I have attached an updated patch to the jira http://issues.apache.org/activemq/secure/ManageAttachments.jspa?id=24443 I still have some questions, now that I have a better understanding of what the patch do. Mainly, I'm questionning the need to the wsdl 1.1 jbi wrapper. If all services exposed and invoked by servicemix are ws-i basic profile compliant, there is only one child in the soap body. Other parts that may be included in the normalized message may come from soap headers. So we are in the same case as for WSDL 2.0: only one element in the soap body, and additioanl soap headers. However, for WSDL 2, soap headers won't be mapped inside the xml content, but should be put as properties on the message. So i'm not quite sure if headers should be put inside the content for WSDL 1.1, as it will not be consistent. I don't really see the point of the wrapper here. Thoughts ? On 8/31/06, Alex Boisvert [EMAIL PROTECTED] wrote: Guillaume Nodet wrote: The binding model should only be built on top of the wsdl for the current HttpEndpoint (either consumer or provider). This WSDL can be explicitely set, or may be auto-generated using the target endpoint WSDL. If the WSDL is provided, there is nothing to do, but if the WSDL is generated, we have to: * check if there is any existing binding infos (for example, if the target endpoint is a soap provider). In this case, we should use the binding informations * else, we need a flag on the http endpoint to set the binding style (rpc / doc). If the user need to provide a more detailed binding, then he has to provide it in the wsdl. Ok, that clarifies it. I'm trying to abstract the SoapBindingModel a bit more to be able to easily handle a plain HTTP binding. WSDL 2.0 bindings will require another reformat later i guess. Cool! I might be able to help with WSDL 2.0 as well. thanks, alex
Re: servicemix-http and normalization
See http://www.ws-i.org/Profiles/BasicProfile-1.1-2004-08-24.html#SOAP_encodingStyle_Attribute it seems pretty clear for me, but maybe i misread it. On 9/5/06, Maciej Szefler [EMAIL PROTECTED] wrote: I don't recall there being anything in WSI-BP that prohibits the usage of RPC-literal encoding, which results in multiple parts. -mbs On 9/5/06, Alex Boisvert [EMAIL PROTECTED] wrote: Oh yes, good question! The point of mapping headers into message content is that many applications/frameworks do not give you easy access (or advise against accessing) message headers. Take, for example, BPEL processes. BPEL only gives you access to the abstract message definition. If headers are not defined and mapped into the content, you can't access them in a portable way. Maybe we could have a configuration attribute to normalize using WSDL 1.1 or WSDL 2.0? That way, if there are no mapped headers and only one SOAP body element, then we could have basic support for WSDL 2.0. I'm very interested in getting full WSDL 1.1 support because that's what's mostly used and deployed today. The tooling and infrastructure ecosystem works great with WSDL 1.1 but still has ways to go with WSDL 2.0. With complete WSDL 1.1 support, we can make the most of ServiceMix today and gradually migrate to WSDL 2.0 when it becomes more widespread. alex Guillaume Nodet wrote: I have attached an updated patch to the jira http://issues.apache.org/activemq/secure/ManageAttachments.jspa?id=24443 I still have some questions, now that I have a better understanding of what the patch do. Mainly, I'm questionning the need to the wsdl 1.1 jbi wrapper. If all services exposed and invoked by servicemix are ws-i basic profile compliant, there is only one child in the soap body. Other parts that may be included in the normalized message may come from soap headers. So we are in the same case as for WSDL 2.0: only one element in the soap body, and additioanl soap headers. However, for WSDL 2, soap headers won't be mapped inside the xml content, but should be put as properties on the message. So i'm not quite sure if headers should be put inside the content for WSDL 1.1, as it will not be consistent. I don't really see the point of the wrapper here. Thoughts ? On 8/31/06, Alex Boisvert [EMAIL PROTECTED] wrote: Guillaume Nodet wrote: The binding model should only be built on top of the wsdl for the current HttpEndpoint (either consumer or provider). This WSDL can be explicitely set, or may be auto-generated using the target endpoint WSDL. If the WSDL is provided, there is nothing to do, but if the WSDL is generated, we have to: * check if there is any existing binding infos (for example, if the target endpoint is a soap provider). In this case, we should use the binding informations * else, we need a flag on the http endpoint to set the binding style (rpc / doc). If the user need to provide a more detailed binding, then he has to provide it in the wsdl. Ok, that clarifies it. I'm trying to abstract the SoapBindingModel a bit more to be able to easily handle a plain HTTP binding. WSDL 2.0 bindings will require another reformat later i guess. Cool! I might be able to help with WSDL 2.0 as well. thanks, alex -- Cheers, Guillaume Nodet
Re: servicemix-http and normalization
Not sure if I understand you. Are you saying you also want to normalize WSDL 2 based soap envelopes the same way ? Using WSDL 2, the rpc-lit style does not exist anymore, so you only have a single child in the soap body which is described using an xml schema. I' m not quite sure how to use soap headers in WSDL 2, but afaik, a jbi component will have to retrieve them from the properties on the message. I guess it would be easier to do the same for WSDL 1.1. Using WSDL 1.1, soap headers mapped to message parts will be included in the wrapper, others will still be accessible from the properties. I' m not a soap expert at all, so please, correct me if I say anything wrong. On 9/5/06, Alex Boisvert [EMAIL PROTECTED] wrote: Oh yes, good question! The point of mapping headers into message content is that many applications/frameworks do not give you easy access (or advise against accessing) message headers. Take, for example, BPEL processes. BPEL only gives you access to the abstract message definition. If headers are not defined and mapped into the content, you can't access them in a portable way. Maybe we could have a configuration attribute to normalize using WSDL 1.1 or WSDL 2.0? That way, if there are no mapped headers and only one SOAP body element, then we could have basic support for WSDL 2.0. I'm very interested in getting full WSDL 1.1 support because that's what's mostly used and deployed today. The tooling and infrastructure ecosystem works great with WSDL 1.1 but still has ways to go with WSDL 2.0. With complete WSDL 1.1 support, we can make the most of ServiceMix today and gradually migrate to WSDL 2.0 when it becomes more widespread. alex Guillaume Nodet wrote: I have attached an updated patch to the jira http://issues.apache.org/activemq/secure/ManageAttachments.jspa?id=24443 I still have some questions, now that I have a better understanding of what the patch do. Mainly, I'm questionning the need to the wsdl 1.1 jbi wrapper. If all services exposed and invoked by servicemix are ws-i basic profile compliant, there is only one child in the soap body. Other parts that may be included in the normalized message may come from soap headers. So we are in the same case as for WSDL 2.0: only one element in the soap body, and additioanl soap headers. However, for WSDL 2, soap headers won't be mapped inside the xml content, but should be put as properties on the message. So i'm not quite sure if headers should be put inside the content for WSDL 1.1, as it will not be consistent. I don't really see the point of the wrapper here. Thoughts ? On 8/31/06, Alex Boisvert [EMAIL PROTECTED] wrote: Guillaume Nodet wrote: The binding model should only be built on top of the wsdl for the current HttpEndpoint (either consumer or provider). This WSDL can be explicitely set, or may be auto-generated using the target endpoint WSDL. If the WSDL is provided, there is nothing to do, but if the WSDL is generated, we have to: * check if there is any existing binding infos (for example, if the target endpoint is a soap provider). In this case, we should use the binding informations * else, we need a flag on the http endpoint to set the binding style (rpc / doc). If the user need to provide a more detailed binding, then he has to provide it in the wsdl. Ok, that clarifies it. I'm trying to abstract the SoapBindingModel a bit more to be able to easily handle a plain HTTP binding. WSDL 2.0 bindings will require another reformat later i guess. Cool! I might be able to help with WSDL 2.0 as well. thanks, alex -- Cheers, Guillaume Nodet
Re: servicemix-http and normalization
I do agree. I do not really question this need for wsdl 1.1, but I' d like to find how you will handle soap headers in WSDL 2, and i think JBI components will have to retrieve the headers from the message properties and not from the xml content. This is also true for optional soap headers in WSDL 1.1 that are not mapped to message parts. On a side not, if the soap request contains more than one header for a particular QName, I guess they should all be put inside one single part of the wrapped message, right ? Just trying to find how it will look at the end ;) On 9/5/06, Maciej Szefler [EMAIL PROTECTED] wrote: Guillaume, The problem with this solution are two-fold. a) It is arbitrarily based on SOAP convention b) It contradicts the solution to the same problem that is explicitly codified in the JBI specification This is really a serious problem because it forces all components that hope to interact with something like servicemix-http to not conform to the JBI specification. At the very least, there should be an option of supporting the spec. -maciej On 9/5/06, Guillaume Nodet [EMAIL PROTECTED] wrote: Yes, WS-I BP 1.1 supports RPC literal, so there will be several parts in the message, but they are all wrapped inside an element with the operation name. This lead to a single child for the soap body element. Currently, servicemix-http passes this child as the content of the normalized message. On 9/5/06, Alex Boisvert [EMAIL PROTECTED] wrote: I think Maciej meant RPC literal (non-encoded XML), which leads to multiple parts and is allowed by WS-I BP 1.1. alex Guillaume Nodet wrote: See http://www.ws-i.org/Profiles/BasicProfile-1.1-2004-08-24.html#SOAP_encodingStyle_Attribute it seems pretty clear for me, but maybe i misread it. On 9/5/06, Maciej Szefler [EMAIL PROTECTED] wrote: I don't recall there being anything in WSI-BP that prohibits the usage of RPC-literal encoding, which results in multiple parts. -mbs On 9/5/06, Alex Boisvert [EMAIL PROTECTED] wrote: Oh yes, good question! The point of mapping headers into message content is that many applications/frameworks do not give you easy access (or advise against accessing) message headers. Take, for example, BPEL processes. BPEL only gives you access to the abstract message definition. If headers are not defined and mapped into the content, you can't access them in a portable way. Maybe we could have a configuration attribute to normalize using WSDL 1.1 or WSDL 2.0? That way, if there are no mapped headers and only one SOAP body element, then we could have basic support for WSDL 2.0. I'm very interested in getting full WSDL 1.1 support because that's what's mostly used and deployed today. The tooling and infrastructure ecosystem works great with WSDL 1.1 but still has ways to go with WSDL 2.0. With complete WSDL 1.1 support, we can make the most of ServiceMix today and gradually migrate to WSDL 2.0 when it becomes more widespread. alex Guillaume Nodet wrote: I have attached an updated patch to the jira http://issues.apache.org/activemq/secure/ManageAttachments.jspa?id=24443 I still have some questions, now that I have a better understanding of what the patch do. Mainly, I'm questionning the need to the wsdl 1.1jbi wrapper. If all services exposed and invoked by servicemix are ws-i basic profile compliant, there is only one child in the soap body. Other parts that may be included in the normalized message may come from soap headers. So we are in the same case as for WSDL 2.0: only one element in the soap body, and additioanl soap headers. However, for WSDL 2, soap headers won't be mapped inside the xml content, but should be put as properties on the message. So i'm not quite sure if headers should be put inside the content for WSDL 1.1, as it will not be consistent. I don't really see the point of the wrapper here. Thoughts ? On 8/31/06, Alex Boisvert [EMAIL PROTECTED] wrote: Guillaume Nodet wrote: The binding model should only be built on top of the wsdl for the current HttpEndpoint (either consumer or provider). This WSDL can be explicitely set, or may be auto-generated using the target endpoint WSDL. If the WSDL is provided, there is nothing to do, but if the WSDL is generated, we have to: * check if there is any existing binding infos (for example, if the target endpoint is a soap provider). In this case, we should use the binding informations * else, we need a flag on the http endpoint to set the binding style (rpc / doc). If the user need to provide a more detailed binding,
Geronimo Samples
Hi All, Yet another two Geronimo sample applications are ready and waiting for your review. 1. EJB Sample Application (http://cwiki.apache.org/confluence/display/GMOxDOC11/EJB+sample+application) 2. MDB Sample Application (http://cwiki.apache.org/confluence/display/GMOxDOC11/MDB+sample+application) I would like to rename MDB sample application as a JMS sample application since it covers JMS aspects too. Do we need to cover more aspects than in this sample application? All feedbacks are welcome. :-) Thanks, Lasantha Ranaweera
Re: Kaha package re-rog
go for it! +1 cheers, Rob Davies http://rajdavies.blogspot.com/ On 5 Sep 2006, at 06:38, Hiram Chirino wrote: Howdy Folks, In the interest of making the kaha.impl package a little easier to grok, I was think that perhaps we split it up into a kaha.impl.data, kaha.impl.index, and kaha.impl.container packages. Since each builds on the other. Any objections? -- Regards, Hiram Blog: http://hiramchirino.com
Re: Kaha package re-rog
Sounds good - anything to make kaha easier to grok is a good thing :) On 9/5/06, Hiram Chirino [EMAIL PROTECTED] wrote: Howdy Folks, In the interest of making the kaha.impl package a little easier to grok, I was think that perhaps we split it up into a kaha.impl.data, kaha.impl.index, and kaha.impl.container packages. Since each builds on the other. Any objections? -- Regards, Hiram Blog: http://hiramchirino.com -- James --- http://radio.weblogs.com/0112098/
[jira] Created: (GERONIMO-2378) Problems in JavaScript validation code forms.js
Problems in JavaScript validation code forms.js --- Key: GERONIMO-2378 URL: http://issues.apache.org/jira/browse/GERONIMO-2378 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Components: console Affects Versions: 1.1.1 Environment: WinXP, Sun JDK 1.4.2_08, G-1.1.1-rc1 Tomcat Reporter: Vamsavardhana Reddy Fix For: 1.1.2, 1.1.x, 1.2 1. Validation javascript is not able to handle form and field names containing -. Some of the portlets in console use field names containing -. 2. checkIntegral() method returns true for empty string. -- 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-2378) Problems in JavaScript validation code forms.js
[ http://issues.apache.org/jira/browse/GERONIMO-2378?page=all ] Vamsavardhana Reddy updated GERONIMO-2378: -- Description: 1. Validation javascript is not able to handle form and field names containing hyphen (-). Some of the portlets in console use field names containing hyphen. 2. checkIntegral() method returns true for empty string. was: 1. Validation javascript is not able to handle form and field names containing -. Some of the portlets in console use field names containing -. 2. checkIntegral() method returns true for empty string. Problems in JavaScript validation code forms.js --- Key: GERONIMO-2378 URL: http://issues.apache.org/jira/browse/GERONIMO-2378 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: console Affects Versions: 1.1.1 Environment: WinXP, Sun JDK 1.4.2_08, G-1.1.1-rc1 Tomcat Reporter: Vamsavardhana Reddy Fix For: 1.2, 1.1.x, 1.1.2 1. Validation javascript is not able to handle form and field names containing hyphen (-). Some of the portlets in console use field names containing hyphen. 2. checkIntegral() method returns true for empty string. -- 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-2378) Problems in JavaScript validation code forms.js
[ http://issues.apache.org/jira/browse/GERONIMO-2378?page=all ] Vamsavardhana Reddy updated GERONIMO-2378: -- Description: 1. Validation javascript is not able to handle form and field names containing hyphen '-'. Some of the portlets in console use field names containing hyphen. 2. checkIntegral() method returns true for empty string. was: 1. Validation javascript is not able to handle form and field names containing hyphen (-). Some of the portlets in console use field names containing hyphen. 2. checkIntegral() method returns true for empty string. Problems in JavaScript validation code forms.js --- Key: GERONIMO-2378 URL: http://issues.apache.org/jira/browse/GERONIMO-2378 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: console Affects Versions: 1.1.1 Environment: WinXP, Sun JDK 1.4.2_08, G-1.1.1-rc1 Tomcat Reporter: Vamsavardhana Reddy Fix For: 1.2, 1.1.x, 1.1.2 1. Validation javascript is not able to handle form and field names containing hyphen '-'. Some of the portlets in console use field names containing hyphen. 2. checkIntegral() method returns true for empty string. -- 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-2378) Problems in JavaScript validation code forms.js
[ http://issues.apache.org/jira/browse/GERONIMO-2378?page=all ] Vamsavardhana Reddy updated GERONIMO-2378: -- Attachment: GERONIMO-2378.patch GERONIMO-2378.patch: 1. Fixes the problem with form and field names containing hypen. 2. Adds check for empty strings in checkIntegral() method. Problems in JavaScript validation code forms.js --- Key: GERONIMO-2378 URL: http://issues.apache.org/jira/browse/GERONIMO-2378 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: console Affects Versions: 1.1.1 Environment: WinXP, Sun JDK 1.4.2_08, G-1.1.1-rc1 Tomcat Reporter: Vamsavardhana Reddy Fix For: 1.2, 1.1.x, 1.1.2 Attachments: GERONIMO-2378.patch 1. Validation javascript is not able to handle form and field names containing hyphen '-'. Some of the portlets in console use field names containing hyphen. 2. checkIntegral() method returns true for empty string. -- 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-2379) Security Realms portlet - form field validation using javascript
Security Realms portlet - form field validation using javascript Key: GERONIMO-2379 URL: http://issues.apache.org/jira/browse/GERONIMO-2379 Project: Geronimo Issue Type: Improvement Security Level: public (Regular issues) Components: console Affects Versions: 1.1.1 Environment: WinXP, Sun JDK 1.4.2_08, G-1.1.1-rc1 Reporter: Vamsavardhana Reddy Fix For: 1.1.2, 1.1.x, 1.2 Security Realm portlet pages do not perform any field validations before submitting the form. Some of the fields can be validated using javascript. Even though it is not complete validation of every field, checks can be put in place for non empty strings, non numerical values etc. -- 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-2379) Security Realms portlet - form field validation using javascript
[ http://issues.apache.org/jira/browse/GERONIMO-2379?page=all ] Vamsavardhana Reddy updated GERONIMO-2379: -- Attachment: GERONIMO-2379.patch GERONIMO-2379.patch: 1. Validates name field. Checks for empty strings. 2. For Properties File and Certificate Properties File Realms, validates the usersURI and groupsURI fields. Checks for empty strings. 3. For Databse Realm, validates userSelect and groupSelect. If a database pool is not selected then it will validate the JDBC parameters. Checks for empty strings. 4. For LDAP realm, validates all fields except connectionProtocol, authentication and userRoleName fields. Checks for empty strings. 5. Field validation can be controlled by setting a property like the following in login-modules.properties: module.ldap.field.connectionProtocol.blankAllowed=true 6. In advanced configuration, validates auditPath (check for empty string), lockoutCount, lockoutWindow, lockoutDuration (checks for integral values). Conditional validation based on the checkBoxes checked. Security Realms portlet - form field validation using javascript Key: GERONIMO-2379 URL: http://issues.apache.org/jira/browse/GERONIMO-2379 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: console Affects Versions: 1.1.1 Environment: WinXP, Sun JDK 1.4.2_08, G-1.1.1-rc1 Reporter: Vamsavardhana Reddy Fix For: 1.2, 1.1.x, 1.1.2 Attachments: GERONIMO-2379.patch Security Realm portlet pages do not perform any field validations before submitting the form. Some of the fields can be validated using javascript. Even though it is not complete validation of every field, checks can be put in place for non empty strings, non numerical values etc. -- 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-2379) Security Realms portlet - form field validation using javascript
[ http://issues.apache.org/jira/browse/GERONIMO-2379?page=all ] Vamsavardhana Reddy updated GERONIMO-2379: -- Attachment: GERONIMO-2379-removedtabs.patch GERONIMO-2379-removedtabs.patch: As always, I left a few tab characters in the source before creating GERONIMO-2379.patch. Please use GERONIMO-2379-removedtabs.patch instead of GERONIMO-2379.patch Security Realms portlet - form field validation using javascript Key: GERONIMO-2379 URL: http://issues.apache.org/jira/browse/GERONIMO-2379 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: console Affects Versions: 1.1.1 Environment: WinXP, Sun JDK 1.4.2_08, G-1.1.1-rc1 Reporter: Vamsavardhana Reddy Fix For: 1.2, 1.1.x, 1.1.2 Attachments: GERONIMO-2379-removedtabs.patch, GERONIMO-2379.patch Security Realm portlet pages do not perform any field validations before submitting the form. Some of the fields can be validated using javascript. Even though it is not complete validation of every field, checks can be put in place for non empty strings, non numerical values etc. -- 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-2380) Keystores portlet - Form field validation using javascript
Keystores portlet - Form field validation using javascript -- Key: GERONIMO-2380 URL: http://issues.apache.org/jira/browse/GERONIMO-2380 Project: Geronimo Issue Type: Improvement Security Level: public (Regular issues) Components: console Affects Versions: 1.1.1 Environment: Win XP, G 1.1.1-rc1 Reporter: Vamsavardhana Reddy Fix For: 1.1.2, 1.1.x, 1.2 Forms in Keystores portlet could use field validation using javascript to check for empty strings and non numerical values before posting the data to the server. -- 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: console deployer dependencies
On 9/4/06, Bill Dudney [EMAIL PROTECTED] wrote:
Now making sure I understood what you said the cause of the error
message is. Since the jetty-deployer is 'provided' scope it is not
added explicitly to the class loader for the console. The jetty-
deloyer has the interface and impl for JettyWebAppContext. Since the
jar that this interface is in is not explicitly added to the
console's class path (because of 'provided' if I understand
correctly) it barfs.
I'm not sure what the point is of listing it as provided, if that's
what we're currently doing. I'm pretty sure it's not provided so we
might as well either not list it or list it as a regular dependency.
We should also make sure to do the same thing for the Tomcat and Jetty
console modules, just each with their respective JARs.
Note that it's not a big barf -- it just means we won't be able to
call server-specific methods using the interface that couldn't be
loaded (only the generic methods in the superinterface). That's not
necessarily disastrous, but it would be nice if we could avoid it. It
depends on whether we'd normally want to be able to use the extra
methods or not.
I guess there's also a third option, which is to get rid of any
functionality in the server-specific intrefaces (putting everything in
the generic interface) and force each server to just throw an
UnsupportedOperationException for any methods that it can't handle.
Thanks,
Aaron
On Sep 4, 2006, at 8:54 AM, Aaron Mulder wrote:
It's actually the proxy manager that produces those messages. It
means that the console asked for a proxy to some GBean, and some of
the interfaces implemented by that GBean weren't available in the
caller's (the console's) class loader.
It would be nice to have a larger discussion about how to handle this.
For example, do we package all management interfaces in separate JARs
from the core libraries (Jetty, Tomcat, ActiveMQ, etc.) so that the
console can add only the interfaces to its class loader? Or are we OK
with the console just adding the full implementation JARs for
everything to its class path?
Thanks,
Aaron
On 9/4/06, Bill Dudney [EMAIL PROTECTED] wrote:
Hi All,
The consoles (tomcat jetty) are spewing warning messages like this;
08:00:18,511 WARN [BasicProxyManager] Could not load interface
org.apache.geronimo.jetty.JettyWebAppContext in provided ClassLoader
for org.apache.geronimo.configs/welcome-jetty/1.2-SNAPSHOT/car?
J2EEApplication=null,j2eeType=WebModule,name=org.apache.geronimo.conf
igs
/welcome-jetty/1.2-SNAPSHOT/car
To fix it we can simply remove the scopeprovided/scope from the
artifactId{jetty,tomcat}-deployer/artifactId dependencies in the
webconsole-{jetty,tomcat}/pom.xml.
Could someone who knows more about the console than me please review
the patch (GERONIMO-2344.bdudney-2.patch) here;
http://issues.apache.org/jira/browse/GERONIMO-2344
And apply it if it makes sense?
Thanks!
-bd-
[jira] Updated: (GERONIMO-2380) Keystores portlet - Form field validation using javascript
[ http://issues.apache.org/jira/browse/GERONIMO-2380?page=all ] Vamsavardhana Reddy updated GERONIMO-2380: -- Attachment: GERONIMO-2380.patch GERONIMO-2380.patch: Updates Create Private Key and Add Trust Certificate pages to use field validation using javascript. Keystores portlet - Form field validation using javascript -- Key: GERONIMO-2380 URL: http://issues.apache.org/jira/browse/GERONIMO-2380 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: console Affects Versions: 1.1.1 Environment: Win XP, G 1.1.1-rc1 Reporter: Vamsavardhana Reddy Fix For: 1.2, 1.1.x, 1.1.2 Attachments: GERONIMO-2380.patch Forms in Keystores portlet could use field validation using javascript to check for empty strings and non numerical values before posting the data to the server. -- 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: September STATUS Report
Thanks. posted at http://wiki.apache.org/incubator/September2006 On 9/1/06, Rob Davies [EMAIL PROTECTED] wrote: looks good to me! On 1 Sep 2006, at 16:51, Hiram Chirino wrote: Howdy Folks, here is my first stab at septemeber status report.. please let me know if something needs to be added/changed: The ActiveMQ community continues to grow as evidenced by the mailing list volumes. Each month mailing list volumes continues to grow. Last month we had 574 emails sent to the developer list and 905 email sent to the user list! We have also seen a big increase in the amount of patches and contributions submitted from non ActiveMQ committers. A large amount of development work and community interest has been around the Native clients used to access the Messaging broker. Tim Bish's excellent work on the STOMP c++ client has earned him an invitation to become an ActiveMQ committer. Amazon did a in house c++ client to ActiveMQ and that source code donation was accepted and committed to the source tree. All the source headers in the 2 active branches have be update to comply with the new policies outline at: http://www.apache.org/legal/src-headers.html. The Apache ActiveMQ 4.0.1 has successfully been released. For more information about the release, see: http://incubator.apache.org/activemq/activemq-401-release.html Development continues on the next 4.1 release. In tandem, the 4.0 branch has continued to stabilize and a 4.0.2 release should be ready shortly. The project has discussed graduating and feels that ActiveMQ ready and would prefer to become a TLP. Once the 4.0.2 release is completed expect more serious discussions regarding graduation to pop up on the incubator mailing lists. -- Regards, Hiram Blog: http://hiramchirino.com -- Regards, Hiram Blog: http://hiramchirino.com
Re: svn commit: r437291 - in /geronimo/server/trunk: bootstrap bootstrap.bat bootstrap.xml
I am in favor of keeping bootstrap around for automating the several steps it takes to check out and build the server into one command. I agree with Anita that there should be instructions for advanced users on the wiki for building without bootstrap -- I have already found her advice very helpful for working around some problems. But for the default build environment (i.e. what a new user sees when checking out from SVN and then reads about in BUILDING.txt) I think we should stay the course for resolving the problems Jason listed before removing bootstrap. My rationale is that fewer manual steps means fewer chances for user error. Best wishes, Paul On 9/1/06, Jason Dillon [EMAIL PROTECTED] wrote: I give up trying to explain... do as you please. --jason On Sep 1, 2006, at 12:48 PM, anita kulshreshtha wrote: inline.. --- Jason Dillon [EMAIL PROTECTED] wrote: On Sep 1, 2006, at 7:42 AM, anita kulshreshtha wrote: Anita, why do you always bring this up when there is talk about bootstrap? Because when people are using bootstrap, it is not very obvious what is going on. It is much simpler to give the 3 URLs and a simple build command mvn. If there are build/test failures, they can look at the default profile, and see what they are building. If for example the openejb2 test failed, they could simply do cd openejb2 and mvn -Dmaven.test.skip=true After this they can continue the build from the next step, i.e. configs, etc. I have explained over and over and over again that the point of bootstrap is not to facilitate a normal build but to ensure People only care about the normal build. that the build works from a known state (ie. clean, fresh specs, from openejb2). Your method does not provide this level of assurance. I You have not given any concrete example/scenario in which my build method does not work. created this script because people had problems checking things out in the right place, Is this the main reason? cleaning the right bits and running the right mvn Could you be more precise? commands to perform the build steps that were needed to help ensure that most everyone (except for some folks with whacky windows machines) can make a reliable build near 100% of the time. I'm really kinda getting tired of having to re-explain this. To build geronimo with openejb2 add openejb2 to the default profile in the top level pom.xml as shown below: modules modulemodules/module modulemaven-plugins/module moduleapplications/module moduleopenejb2/module --- moduleconfigs/module moduleassemblies/module /modules and No, no, no, no... no... no. We had already talked about this weeks ago. Its fine that you want to build in this manner, but I am firmly against putting a module into the main build that is for a directory that the user must checkout by hand. I do not see any problems with that. Let us give people a choice by putting these instructions on the wiki and they can decide if they want to use bootstrap. BTW, it is in line with your philosophy about builds: http://www.nabble.com/Re%3A-Unable-to-build-using-m2-p5074204.html cd .. mvn After the first time you can build from any directory. Please give it a try and provide feedback, so that we can put bootstrap to rest. I don't have any problems with you, or anyone else making changes to include openejb2 in their local workspace (I'd recommend putting that into a profiles.xml next to the pom.xml though). But I think that your method is unacceptable for the project default. Bootstrap is there for a reason... I am not crazy, I actually know what I am doing. At this point I believe that bootstrap is important and needs to remain, until the items I previously listed are resolved. I am not asking you to remove the bootstrap, I want to give our users a choice. Thanks Anita --jason __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
SVN Repository Reorganization
Hi Everybody,
The ActiveMQ project has been growing tremendously and our source tree
now has many modules that are at different stages of development.
Furthermore, we require multiple build systems and platforms to build
all our supported native clients. I think we are getting to the point
where we need reorganize the svn repository a little so that when we
do a main ActiveMQ release, our src distro just includes the things
that are being built / tested in the main ActiveMQ build.
So.. the reorg would look something like:
/incubator/activemq/trunk/sandbox - /incubator/activemq/sandbox
/incubator/activemq/trunk/activemq-dotnet -
/incubator/activemq/activemq-dotnet/trunk
/incubator/activemq/trunk/activemq-cpp -
/incubator/activemq/activemq-cpp/trunk
/incubator/activemq/trunk/cms - /incubator/activemq/cms/trunk
/incubator/activemq/trunk/openwire-c - /incubator/activemq/openwire-c/trunk
/incubator/activemq/trunk/openwire-cpp -
/incubator/activemq/openwire-cpp/trunk
/incubator/activemq/trunk/amazon - /incubator/activemq/amazon/trunk
/incubator/activemq/trunk/activeio - /incubator/activemq/activeio/trunk
/incubator/activemq/trunk/activecluster -
/incubator/activemq/activecluster/trunk
/incubator/activemq/trunk/activemq-jmeter -
/incubator/activemq/activemq-jmeter/trunk
/incubator/activemq/trunk/activemq-tooling/maven-gram-plugin -
/incubator/activemq/maven-plugins/trunk/maven-gram-plugin
/incubator/activemq/trunk/activemq-tooling/maven-bundle-plugin -
/incubator/activemq/maven-plugins/trunk/maven-bundle-plugin
/incubator/activemq/trunk/activemq-tooling/maven-bundle-plugin -
/incubator/activemq/maven-plugins/trunk/maven-bundle-plugin
And finally.. to keep a consistent
/incubator/activemq/${project}/trunk structure...
/incubator/activemq/trunk - /incubator/activemq/activemq/trunk
/incubator/activemq/tags - /incubator/activemq/activemq/tags
/incubator/activemq/branches - /incubator/activemq/activemq/branches
What do you guys think? Am i missing anything that should also get
moved? When do you think would be a good time for the re-org?
--
Regards,
Hiram
Blog: http://hiramchirino.com
[jira] Created: (GERONIMO-2381) DB Manager portlet - Form field validation using javascript
DB Manager portlet - Form field validation using javascript --- Key: GERONIMO-2381 URL: http://issues.apache.org/jira/browse/GERONIMO-2381 Project: Geronimo Issue Type: Improvement Security Level: public (Regular issues) Components: console Affects Versions: 1.1.1 Environment: WinXP, G 1.1.1-rc1 Reporter: Vamsavardhana Reddy Fix For: 1.1.2, 1.1.x, 1.2 Form field validation in DB Manager portlet using javascript. -- 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-2381) DB Manager portlet - Form field validation using javascript
[ http://issues.apache.org/jira/browse/GERONIMO-2381?page=all ] Vamsavardhana Reddy updated GERONIMO-2381: -- Attachment: GERONIMO-2381.patch GERONIMO-2381.patch: Adds field validation for createDB and sqlStmts. DB Manager portlet - Form field validation using javascript --- Key: GERONIMO-2381 URL: http://issues.apache.org/jira/browse/GERONIMO-2381 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: console Affects Versions: 1.1.1 Environment: WinXP, G 1.1.1-rc1 Reporter: Vamsavardhana Reddy Fix For: 1.2, 1.1.x, 1.1.2 Attachments: GERONIMO-2381.patch Form field validation in DB Manager portlet using javascript. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: SVN Repository Reorganization
I'm all for cleaning things up - though I'd hate to break the zillions
of snippet macros littered throughout the wiki showing example
snippets of code or xml configuration etc.
How about we keep the Java broker client where it is, move the
tooling (maven and otherwise) out to a separate area and the other
clients like C/C++/C# to a different place so they can be released
separately as required etc?
On 9/5/06, Hiram Chirino [EMAIL PROTECTED] wrote:
Hi Everybody,
The ActiveMQ project has been growing tremendously and our source tree
now has many modules that are at different stages of development.
Furthermore, we require multiple build systems and platforms to build
all our supported native clients. I think we are getting to the point
where we need reorganize the svn repository a little so that when we
do a main ActiveMQ release, our src distro just includes the things
that are being built / tested in the main ActiveMQ build.
So.. the reorg would look something like:
/incubator/activemq/trunk/sandbox - /incubator/activemq/sandbox
/incubator/activemq/trunk/activemq-dotnet -
/incubator/activemq/activemq-dotnet/trunk
/incubator/activemq/trunk/activemq-cpp -
/incubator/activemq/activemq-cpp/trunk
/incubator/activemq/trunk/cms - /incubator/activemq/cms/trunk
/incubator/activemq/trunk/openwire-c - /incubator/activemq/openwire-c/trunk
/incubator/activemq/trunk/openwire-cpp -
/incubator/activemq/openwire-cpp/trunk
/incubator/activemq/trunk/amazon - /incubator/activemq/amazon/trunk
/incubator/activemq/trunk/activeio - /incubator/activemq/activeio/trunk
/incubator/activemq/trunk/activecluster -
/incubator/activemq/activecluster/trunk
/incubator/activemq/trunk/activemq-jmeter -
/incubator/activemq/activemq-jmeter/trunk
/incubator/activemq/trunk/activemq-tooling/maven-gram-plugin -
/incubator/activemq/maven-plugins/trunk/maven-gram-plugin
/incubator/activemq/trunk/activemq-tooling/maven-bundle-plugin -
/incubator/activemq/maven-plugins/trunk/maven-bundle-plugin
/incubator/activemq/trunk/activemq-tooling/maven-bundle-plugin -
/incubator/activemq/maven-plugins/trunk/maven-bundle-plugin
And finally.. to keep a consistent
/incubator/activemq/${project}/trunk structure...
/incubator/activemq/trunk - /incubator/activemq/activemq/trunk
/incubator/activemq/tags - /incubator/activemq/activemq/tags
/incubator/activemq/branches - /incubator/activemq/activemq/branches
What do you guys think? Am i missing anything that should also get
moved? When do you think would be a good time for the re-org?
--
Regards,
Hiram
Blog: http://hiramchirino.com
--
James
---
http://radio.weblogs.com/0112098/
Re: SVN Repository Reorganization
Good point.. we can clean that last bit of the broker and client when
the project graduates. Since it will force us to move url anyways.
On 9/5/06, James Strachan [EMAIL PROTECTED] wrote:
I'm all for cleaning things up - though I'd hate to break the zillions
of snippet macros littered throughout the wiki showing example
snippets of code or xml configuration etc.
How about we keep the Java broker client where it is, move the
tooling (maven and otherwise) out to a separate area and the other
clients like C/C++/C# to a different place so they can be released
separately as required etc?
On 9/5/06, Hiram Chirino [EMAIL PROTECTED] wrote:
Hi Everybody,
The ActiveMQ project has been growing tremendously and our source tree
now has many modules that are at different stages of development.
Furthermore, we require multiple build systems and platforms to build
all our supported native clients. I think we are getting to the point
where we need reorganize the svn repository a little so that when we
do a main ActiveMQ release, our src distro just includes the things
that are being built / tested in the main ActiveMQ build.
So.. the reorg would look something like:
/incubator/activemq/trunk/sandbox - /incubator/activemq/sandbox
/incubator/activemq/trunk/activemq-dotnet -
/incubator/activemq/activemq-dotnet/trunk
/incubator/activemq/trunk/activemq-cpp -
/incubator/activemq/activemq-cpp/trunk
/incubator/activemq/trunk/cms - /incubator/activemq/cms/trunk
/incubator/activemq/trunk/openwire-c - /incubator/activemq/openwire-c/trunk
/incubator/activemq/trunk/openwire-cpp -
/incubator/activemq/openwire-cpp/trunk
/incubator/activemq/trunk/amazon - /incubator/activemq/amazon/trunk
/incubator/activemq/trunk/activeio - /incubator/activemq/activeio/trunk
/incubator/activemq/trunk/activecluster -
/incubator/activemq/activecluster/trunk
/incubator/activemq/trunk/activemq-jmeter -
/incubator/activemq/activemq-jmeter/trunk
/incubator/activemq/trunk/activemq-tooling/maven-gram-plugin -
/incubator/activemq/maven-plugins/trunk/maven-gram-plugin
/incubator/activemq/trunk/activemq-tooling/maven-bundle-plugin -
/incubator/activemq/maven-plugins/trunk/maven-bundle-plugin
/incubator/activemq/trunk/activemq-tooling/maven-bundle-plugin -
/incubator/activemq/maven-plugins/trunk/maven-bundle-plugin
And finally.. to keep a consistent
/incubator/activemq/${project}/trunk structure...
/incubator/activemq/trunk - /incubator/activemq/activemq/trunk
/incubator/activemq/tags - /incubator/activemq/activemq/tags
/incubator/activemq/branches - /incubator/activemq/activemq/branches
What do you guys think? Am i missing anything that should also get
moved? When do you think would be a good time for the re-org?
--
Regards,
Hiram
Blog: http://hiramchirino.com
--
James
---
http://radio.weblogs.com/0112098/
--
Regards,
Hiram
Blog: http://hiramchirino.com
Re: SVN Repository Reorganization
Perhaps we should put all the c/c++ stuff together??? I think that
would make it simpler to merge implementations and share ideas.
On 9/5/06, Hiram Chirino [EMAIL PROTECTED] wrote:
Hi Everybody,
The ActiveMQ project has been growing tremendously and our source tree
now has many modules that are at different stages of development.
Furthermore, we require multiple build systems and platforms to build
all our supported native clients. I think we are getting to the point
where we need reorganize the svn repository a little so that when we
do a main ActiveMQ release, our src distro just includes the things
that are being built / tested in the main ActiveMQ build.
So.. the reorg would look something like:
/incubator/activemq/trunk/sandbox - /incubator/activemq/sandbox
/incubator/activemq/trunk/activemq-dotnet -
/incubator/activemq/activemq-dotnet/trunk
/incubator/activemq/trunk/activemq-cpp -
/incubator/activemq/activemq-cpp/trunk
/incubator/activemq/trunk/cms - /incubator/activemq/cms/trunk
/incubator/activemq/trunk/openwire-c - /incubator/activemq/openwire-c/trunk
/incubator/activemq/trunk/openwire-cpp -
/incubator/activemq/openwire-cpp/trunk
/incubator/activemq/trunk/amazon - /incubator/activemq/amazon/trunk
/incubator/activemq/trunk/activeio - /incubator/activemq/activeio/trunk
/incubator/activemq/trunk/activecluster -
/incubator/activemq/activecluster/trunk
/incubator/activemq/trunk/activemq-jmeter -
/incubator/activemq/activemq-jmeter/trunk
/incubator/activemq/trunk/activemq-tooling/maven-gram-plugin -
/incubator/activemq/maven-plugins/trunk/maven-gram-plugin
/incubator/activemq/trunk/activemq-tooling/maven-bundle-plugin -
/incubator/activemq/maven-plugins/trunk/maven-bundle-plugin
/incubator/activemq/trunk/activemq-tooling/maven-bundle-plugin -
/incubator/activemq/maven-plugins/trunk/maven-bundle-plugin
And finally.. to keep a consistent
/incubator/activemq/${project}/trunk structure...
/incubator/activemq/trunk - /incubator/activemq/activemq/trunk
/incubator/activemq/tags - /incubator/activemq/activemq/tags
/incubator/activemq/branches - /incubator/activemq/activemq/branches
What do you guys think? Am i missing anything that should also get
moved? When do you think would be a good time for the re-org?
--
Regards,
Hiram
Blog: http://hiramchirino.com
--
Regards,
Hiram
Blog: http://hiramchirino.com
Re: servicemix-http and normalization
Oh yes, good question! The point of mapping headers into message content is that many applications/frameworks do not give you easy access (or advise against accessing) message headers. Take, for example, BPEL processes. BPEL only gives you access to the abstract message definition. If headers are not defined and mapped into the content, you can't access them in a portable way. Maybe we could have a configuration attribute to normalize using WSDL 1.1 or WSDL 2.0? That way, if there are no mapped headers and only one SOAP body element, then we could have basic support for WSDL 2.0. I'm very interested in getting full WSDL 1.1 support because that's what's mostly used and deployed today. The tooling and infrastructure ecosystem works great with WSDL 1.1 but still has ways to go with WSDL 2.0. With complete WSDL 1.1 support, we can make the most of ServiceMix today and gradually migrate to WSDL 2.0 when it becomes more widespread. alex Guillaume Nodet wrote: I have attached an updated patch to the jira http://issues.apache.org/activemq/secure/ManageAttachments.jspa?id=24443 I still have some questions, now that I have a better understanding of what the patch do. Mainly, I'm questionning the need to the wsdl 1.1 jbi wrapper. If all services exposed and invoked by servicemix are ws-i basic profile compliant, there is only one child in the soap body. Other parts that may be included in the normalized message may come from soap headers. So we are in the same case as for WSDL 2.0: only one element in the soap body, and additioanl soap headers. However, for WSDL 2, soap headers won't be mapped inside the xml content, but should be put as properties on the message. So i'm not quite sure if headers should be put inside the content for WSDL 1.1, as it will not be consistent. I don't really see the point of the wrapper here. Thoughts ? On 8/31/06, Alex Boisvert [EMAIL PROTECTED] wrote: Guillaume Nodet wrote: The binding model should only be built on top of the wsdl for the current HttpEndpoint (either consumer or provider). This WSDL can be explicitely set, or may be auto-generated using the target endpoint WSDL. If the WSDL is provided, there is nothing to do, but if the WSDL is generated, we have to: * check if there is any existing binding infos (for example, if the target endpoint is a soap provider). In this case, we should use the binding informations * else, we need a flag on the http endpoint to set the binding style (rpc / doc). If the user need to provide a more detailed binding, then he has to provide it in the wsdl. Ok, that clarifies it. I'm trying to abstract the SoapBindingModel a bit more to be able to easily handle a plain HTTP binding. WSDL 2.0 bindings will require another reformat later i guess. Cool! I might be able to help with WSDL 2.0 as well. thanks, alex
Re: SVN Repository Reorganization
On 9/5/06, Hiram Chirino [EMAIL PROTECTED] wrote: Good point.. we can clean that last bit of the broker and client when the project graduates. Since it will force us to move url anyways. Good call. -- James --- http://radio.weblogs.com/0112098/
Re: SVN Repository Reorganization
On 9/5/06, Hiram Chirino [EMAIL PROTECTED] wrote: Perhaps we should put all the c/c++ stuff together??? I think that would make it simpler to merge implementations and share ideas. Sounds fine with me. -- James --- http://radio.weblogs.com/0112098/
Re: console deployer dependencies
Anita,
While the jar's are not required in the class loader, without them
the warning messages are printed.
Do you have ideas about how to get rid of the warning messages and
keep the 'provided' scope?
I think I prefer pushing all the methods into the 'super interface'
and having an UnsupportedOperationException as long as there are good
error messages as to what has happened (i.e. 'a method was invoked on
the Jetty container that is not supported, perhaps you wanted to use
Tomcat instead?' or something less cheesy).
Anyway I'm not sure of the best way to handle this but I don't like
the warning messages. I think they would look ominous to initial
users then over time users would stop worrying about warning
messages. Which is bad IMO.
TTFN,
-bd-
On Sep 5, 2006, at 8:23 AM, anita kulshreshtha wrote:
I'm not sure what the point is of listing it as provided, if that's
what we're currently doing. I'm pretty sure it's not provided so
we
might as well either not list it or list it as a regular dependency.
The scope=provided is used to enforce the build order for the
configs, i.e the console configs are not built before the jetty/tomcat
deployer configs are built in a multi config build. These cars are not
required in the classloader.
Thanks
Anita
On 9/4/06, Bill Dudney [EMAIL PROTECTED] wrote:
Hi All,
The consoles (tomcat jetty) are spewing warning messages like
this;
08:00:18,511 WARN [BasicProxyManager] Could not load interface
org.apache.geronimo.jetty.JettyWebAppContext in provided
ClassLoader
for org.apache.geronimo.configs/welcome-jetty/1.2-SNAPSHOT/car?
J2EEApplication=null,j2eeType=WebModule,name=org.apache.geronimo.conf
igs
/welcome-jetty/1.2-SNAPSHOT/car
To fix it we can simply remove the scopeprovided/scope from
the
artifactId{jetty,tomcat}-deployer/artifactId dependencies in
the
webconsole-{jetty,tomcat}/pom.xml.
Could someone who knows more about the console than me please
review
the patch (GERONIMO-2344.bdudney-2.patch) here;
http://issues.apache.org/jira/browse/GERONIMO-2344
And apply it if it makes sense?
Thanks!
-bd-
__
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
[jira] Commented: (GERONIMODEVTOOLS-99) need to publish web project dependencies outside of WAR
[ http://issues.apache.org/jira/browse/GERONIMODEVTOOLS-99?page=comments#action_12432622 ] Oleg Gusakov commented on GERONIMODEVTOOLS-99: -- added comment to GERONIMO-2324 need to publish web project dependencies outside of WAR --- Key: GERONIMODEVTOOLS-99 URL: http://issues.apache.org/jira/browse/GERONIMODEVTOOLS-99 Project: Geronimo-Devtools Issue Type: Improvement Components: eclipse-plugin Affects Versions: 1.1.0 Environment: IBM Java 1.5, Eclipse 3.2.0, WTP 1.5, w2k/w3k, 32/64 bit Reporter: Oleg Gusakov Assigned To: Sachin Patel Priority: Blocker Fix For: 1.x In our use case for geronimo plugin we need to be able to deploy WAR project dependencies outside of WAR. The best place seems to SharedLib deployer. Dependencies to deploy include: - Eclipse WAR project references to other Eclipse projects - external JAR files, attached to the project and/ot it's dependencies - external dependencies supplied by Maven plugin from project's POM file. This is almost identical to the previous one. All dependencies need to be deployed in place for efficiency reasons. Binary dependencies do not change often and can reside in one classloader. Eclipse projects, on the other hand, change a lot and could be subjected to hot redeployment, so they probably should reside in their own set of classloaders. Please consider for implementation. -- 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: When has the server started?
Jason Dillon wrote: On Sep 4, 2006, at 1:39 PM, David Jencks wrote: IMO this would be a perversion of the geronimo architecture. What does fully started mean anyway? If you start with say geronimo-jetty-minimal and add cars to turn it into a full j2ee server while it is running, when exactly is it started? It certainly has nothing to do with the kernel. Not to get too pedantic but what if some of the configurations in the persistent configuration couldn't be started for some reason, is the server still fully started? Perhaps something more like initialBootstrapCompleted might be more intuitive. When we thought about this last the best idea we could come up with is that it's fully started when all the modules listed in persistent configuration lists (should be persistent module lists) that are in the bootstrap or included recursively in those modules are started. Think about what happens if a module in the original PCL includes another PCL. Started (or fully started) means that the server has loaded, initialized and started all modules in the persistent configuration, such that it could then start to serve applications... and start listening on ports, etc. True there might be more modules to be loaded or configured after that, but the point is to tell when the server is ready to start accepting work. There is a period while the server is starting, when it starts listening to http, but it is not ready to serve applications which have been configured to be deployed. Anyways, I don't care too much what it is called... but I think that flag should be exposed as a simple Boolean on some common MBean. Maybe its not the Kernel, as the kernel might be started, but the system might not be ready to serve my webapps or whatever. Having to pull in geronimo-kernel to perform a simple remote call to fetch a boolean is overkill... especially since that module has magical logging fluff that rudely overwrites configuration. If we had a specialized MBean/GBean that just exposed the very common remote functionality via JMX directly then we would be in a very good position to keep tools (IDE plugins, maven plugins, etc) working even after we change the internals around. Such tools need an easy way to: * Detect when the server is started and ready to server applications * Shutdown Probably some other things too... --jason
Re: When has the server started?
On 9/5/06, Matt Hogstrom [EMAIL PROTECTED] wrote: Not to get too pedantic but what if some of the configurations in the persistent configuration couldn't be started for some reason, is the server still fully started? Currently if that happens, the server shuts down. That's another issue we might want to revisit. Thanks, Aaron Perhaps something more like initialBootstrapCompleted might be more intuitive. When we thought about this last the best idea we could come up with is that it's fully started when all the modules listed in persistent configuration lists (should be persistent module lists) that are in the bootstrap or included recursively in those modules are started. Think about what happens if a module in the original PCL includes another PCL. Started (or fully started) means that the server has loaded, initialized and started all modules in the persistent configuration, such that it could then start to serve applications... and start listening on ports, etc. True there might be more modules to be loaded or configured after that, but the point is to tell when the server is ready to start accepting work. There is a period while the server is starting, when it starts listening to http, but it is not ready to serve applications which have been configured to be deployed. Anyways, I don't care too much what it is called... but I think that flag should be exposed as a simple Boolean on some common MBean. Maybe its not the Kernel, as the kernel might be started, but the system might not be ready to serve my webapps or whatever. Having to pull in geronimo-kernel to perform a simple remote call to fetch a boolean is overkill... especially since that module has magical logging fluff that rudely overwrites configuration. If we had a specialized MBean/GBean that just exposed the very common remote functionality via JMX directly then we would be in a very good position to keep tools (IDE plugins, maven plugins, etc) working even after we change the internals around. Such tools need an easy way to: * Detect when the server is started and ready to server applications * Shutdown Probably some other things too... --jason
Re: Keystore features - Create certificate request
Thanks for the tip :) so the process is - create new keystore - create new private key - return to the keystore list and unlock the newly created private key - access the keystore - view details for the private key - generate CSR - import reply from CA Is this the correct process? Cheers! Hernan Vamsavardhana Reddy wrote: See point no. 2, Ability to generate CertificateRequests. GERONIMO-2218 addresses this. You need to be viewing the privatekey details to be able to generate a CSR for the same, Vamsi On 8/31/06, *Hernan Cunico* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Hi All, is there a way to create a certificate request in 1.1.1? I found GERONIMO-2218 but creating certificate request seems to have escaped from the patch. I have not found any other JIRA discussing this CSR issue ( that doesn't mean there isn't one ). Should I create a KeyStore portlet: Functionality missing from 1.0 [take 2] Cheers! Hernan
Re: Keystore features - Create certificate request
That's right. VamsiOn 9/5/06, Hernan Cunico [EMAIL PROTECTED] wrote: Thanks for the tip :)so the process is- create new keystore- create new private key- return to the keystore list and unlock the newly created private key- access the keystore- view details for the private key - generate CSR- import reply from CAIs this the correct process?Cheers!HernanVamsavardhana Reddy wrote: See point no. 2, Ability to generate CertificateRequests.GERONIMO-2218 addresses this.You need to be viewing the privatekey details to be able to generate a CSR for the same, Vamsi On 8/31/06, *Hernan Cunico* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Hi All, is there a way to create a certificate request in 1.1.1? I found GERONIMO-2218 but creating certificate request seems to have escaped from the patch. I have not found any other JIRA discussing this CSR issue ( that doesn't mean there isn't one ). Should I create a KeyStore portlet: Functionality missing from 1.0 [take 2] Cheers! Hernan
[jira] Commented: (GERONIMO-2364) Update geronimo to use ActiveMQ 4.1.x
[ http://issues.apache.org/jira/browse/GERONIMO-2364?page=comments#action_12432629 ] Alan Cabrera commented on GERONIMO-2364: Should the patch be updated to reflect the change? Update geronimo to use ActiveMQ 4.1.x - Key: GERONIMO-2364 URL: http://issues.apache.org/jira/browse/GERONIMO-2364 Project: Geronimo Issue Type: RTC Security Level: public(Regular issues) Components: ActiveMQ Reporter: Hiram Chirino Assigned To: Hiram Chirino Fix For: 1.2 Attachments: GERONIMO-2364.patch -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (GERONIMO-2364) Update geronimo to use ActiveMQ 4.1.x
[ http://issues.apache.org/jira/browse/GERONIMO-2364?page=comments#action_12432631 ] Hiram Chirino commented on GERONIMO-2364: - It's a small change and is simple enough to apply manually. I don't think the patch needs to be updated. It should not affect the voting on patch. Update geronimo to use ActiveMQ 4.1.x - Key: GERONIMO-2364 URL: http://issues.apache.org/jira/browse/GERONIMO-2364 Project: Geronimo Issue Type: RTC Security Level: public(Regular issues) Components: ActiveMQ Reporter: Hiram Chirino Assigned To: Hiram Chirino Fix For: 1.2 Attachments: GERONIMO-2364.patch -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (GERONIMO-2364) Update geronimo to use ActiveMQ 4.1.x
[ http://issues.apache.org/jira/browse/GERONIMO-2364?page=comments#action_12432632 ] Hiram Chirino commented on GERONIMO-2364: - in otherwords, the main thing that needs to get voted on is moving to 4.1 of activemq and the related changes. the small change can be treated as a bug fix and RTC does not apply.. Update geronimo to use ActiveMQ 4.1.x - Key: GERONIMO-2364 URL: http://issues.apache.org/jira/browse/GERONIMO-2364 Project: Geronimo Issue Type: RTC Security Level: public(Regular issues) Components: ActiveMQ Reporter: Hiram Chirino Assigned To: Hiram Chirino Fix For: 1.2 Attachments: GERONIMO-2364.patch -- 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-2382) Webservers portlet - Form field validation using javascript
Webservers portlet - Form field validation using javascript --- Key: GERONIMO-2382 URL: http://issues.apache.org/jira/browse/GERONIMO-2382 Project: Geronimo Issue Type: Improvement Security Level: public (Regular issues) Components: console Affects Versions: 1.1.1 Environment: WinXP, G 1.1.1-rc1 Reporter: Vamsavardhana Reddy Fix For: 1.1.2, 1.1.x, 1.2 Form field validation in DB Manager portlet using javascript. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (GERONIMO-2324) Allow in-place and exploded jar support for sharedlib
[ http://issues.apache.org/jira/browse/GERONIMO-2324?page=comments#action_12432637 ] David Jencks commented on GERONIMO-2324: [ Show » ] Sachin Patel [16/Aug/06 07:32 PM] Actually we need to re-open this for discussion. The dummy jar won't solve the classes dir and modifying the config will require a server restart. I don't think is reasonable. - Can't we put a directory entry in manifest classpath in addition to actual jars? This would make modifying the classes attribute unnecessary - If that doesn't work, the classes attribute can be changed while the server is running using the kernel reflection methods, e.g. kernel.setAttribute(sharedLibGBeanName, classes, newValue); This can be called remotely: see the jmx deployment stuff for an example of how. When you change an attribute through the kernel like this the new value gets saved in config.xml Therefore I think that using a dummy jar is still quite workable. [ Show » ] Oleg Gusakov [01/Sep/06 03:53 PM] SharedLib might not be an ideal solution as David quite reasonably indicated, but here is the use case: * I develop a WAR project under Eclipse * this project depends on 15 Eclipse JAR projects (just java code) I need to debug * this project depends on 500 JAR artifacts that are attached (in Eclipse) via either Eclipse external jar or Maven plugin dependency * I need to debug my WAR under Geronimo o all my dependencies, both Eclipse project references and external JARs should be available o if I change a java file in one of the referenced projects - it should be re-published into Geronimo on the fly by the plugin o I may choose to convert one of those 500 dependency JARs into a full blown Eclipse project so + plugin may have to drop that jar from Geronimo + redeploy it as an Eclipse project Controlling all those jars and classes via Maven-like repository migh be a stretch - by definition Maven repository hosts finalized artifacts that have passed unit tests. (dj) - Are you really planning to work with code outside an open eclipse project that doesn't pass _unit_ tests? Maven repositories can certainly contain SNAPSHOT -versioned jars which I think of as being typically the compiled version of whatever code is on your machine currently. Maybe the impedance mismatch we're having is that I have a hard time remembering developing without maven and you don't use it :-) I, on the contrary, am trying to quickly manupulate half-baked code that really belongs to IDE, not even a JAR file. So SharedLib seems to be a logical candidate. Or some other GBean that would allow easy classloading changes, especially given the fact that all manipulations originate not from a user but from a plugin that is fairly well tested Another consideration - visibility of the published classes. It does not matter that much for development deployments. But even here - I can envision rather complex applications desiring to limit the visibility of their artifacts. This leads to another idea - there should a way to specify where this SharedDevLib classloaders attaches - server-wide, particular EAR or, even WAR. First, you can already attach shared-lib classloaders wherever you want. We just provide one that acts sort of like the tomcat shared/lib but you are free to create as many configurations containing one or more shared-lib gbeans and include these configurations as parents/dependencies of whatever app you want. However, if you are wanting to create complicated classloader structures I think that shared lib is an inappropriate tool and you should think harder about putting the jars into the maven repo structure (they can all be under e.g. com.myco.bigproject or you can separate them more) and using explicit dependencies in your geronimo plans. This might be painful in the short term but I suspect it would clarify and document the exact dependencies between the jars. At this point I think we are trying to cram too much into the existing repository and shared lib implementations. I think its becoming clearer that the needs of a development environment may not be appropriate to support in a production server. However, there are a lot of possible solutions: here are a couple of suggestions: 1. Geronimo can support any number of simultaneous repository gbeans. If you were willing to use explicit dependencies instead of shared-lib, we could write a repository implementation that pointed into the eclipse workspace(s) and used the eclipse-compiled classes in situ. Presumably it would be possible to make it look first in eclipse for opened projects and then in some other location for jars that are not currently opened as eclipse projects. I think this is the cleanest solution: when a jar or project changes, you just need to restart the configuration that actually uses it, and the
[jira] Updated: (GERONIMO-2382) Webservers portlet - Form field validation using javascript
[ http://issues.apache.org/jira/browse/GERONIMO-2382?page=all ] Vamsavardhana Reddy updated GERONIMO-2382: -- Attachment: GERONIMO-2382.patch GERONIMO-2382.patch: Validates name, host, port, minThreads, maxThreads, keystoreFile and keystorePassword fields. Checks for empty strings and non numerical values where applicable. Webservers portlet - Form field validation using javascript --- Key: GERONIMO-2382 URL: http://issues.apache.org/jira/browse/GERONIMO-2382 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: console Affects Versions: 1.1.1 Environment: WinXP, G 1.1.1-rc1 Reporter: Vamsavardhana Reddy Fix For: 1.1.2, 1.1.x, 1.2 Attachments: GERONIMO-2382.patch Form field validation in DB Manager portlet using javascript. -- 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-2383) Replace ENCConfigBuilder with a pluggable set of NamingBuilders
Replace ENCConfigBuilder with a pluggable set of NamingBuilders --- Key: GERONIMO-2383 URL: http://issues.apache.org/jira/browse/GERONIMO-2383 Project: Geronimo Issue Type: Improvement Security Level: public (Regular issues) Affects Versions: 1.2 Reporter: David Jencks Assigned To: David Jencks Fix For: 1.2 (Previously part of GERONIMO-2349) The ENCConfigBuilder is way too hardcoded into what it accepts and how. It won't let you add things like a persistence-ref builder very easily. We can replace it with a set of NamingBuilders somewhat similar to NamespaceDrivenBuilders. -- 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-2349) jta 1.1 support with container manager jpa support in transaction module
[ http://issues.apache.org/jira/browse/GERONIMO-2349?page=all ] David Jencks updated GERONIMO-2349: --- Attachment: GERONIMO-2349-v5.patch This is getting out of control... I'd like to scale back this issue to the changes in the transaction module itself and deal with persistence-refs in a separate issue (GERONIMO-2383). Please consider this patch together with the sandbox jta11 modules and vote soon. jta 1.1 support with container manager jpa support in transaction module Key: GERONIMO-2349 URL: http://issues.apache.org/jira/browse/GERONIMO-2349 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: transaction manager Affects Versions: 1.2 Reporter: David Jencks Assigned To: David Jencks Fix For: 1.2 Attachments: GERONIMO-2349-1.patch, GERONIMO-2349-2.patch, GERONIMO-2349-3.patch, GERONIMO-2349-v4-plus-2163-openejb.patch, GERONIMO-2349-v4-plus-2163.patch, GERONIMO-2349-v5.patch, persistencecontextref.zip We need a strategy for supporting jta 1.1 and parts of jpa in the transaction module while still passing the j2ee 1.4 signature tests. Here's a proposal: - put the basis for support into the current transaction module, but don't use any jee5 interfaces - add an additional transaction-jta11 module that uses the new interfaces and extends the appropriate classes in transaction. I've started along this path. I'll put the new module in sandbox and supply a patch for the changes to the existing transaction module. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (GERONIMO-2324) Allow in-place and exploded jar support for sharedlib
[ http://issues.apache.org/jira/browse/GERONIMO-2324?page=comments#action_12432652 ] Sachin Patel commented on GERONIMO-2324: Ok, so running a quick test it seems you can put absolute locations for both directories and jars inside the manifest classpath entry even though the 1.4.2 jar specification seems to say otherwise... On comments above... (1) Eclipse workspaces are much more flexible now days, and each of the actual project contents can reside anywhere on the filesystem and the actual contents fo the workspace directory only contain eclipse configuration metadata. Also project stuctures can contain multiple outfolders so this could get compilcated quickly. I prefer to go down the dummy jar path and recycle sharedlib as the dummy jar changes. Allow in-place and exploded jar support for sharedlib - Key: GERONIMO-2324 URL: http://issues.apache.org/jira/browse/GERONIMO-2324 Project: Geronimo Issue Type: RTC Security Level: public(Regular issues) Components: deployment Affects Versions: 1.1 Reporter: Sachin Patel Assigned To: Sachin Patel Fix For: 1.x Attachments: GERONIMO-2324.patch, GERONIMO-2324.patch The shared library support should allow in-place support to allow and load jars (exploded as well) that are located externally on the filesystem. This is needed to improve developer experience and allow better integration within tooling and the runtime. Perhaps we can have a properties file insie the shared lib that have external entries in them. -- 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-2321) DB Pool wizard allows / in the DB Pool name
[ http://issues.apache.org/jira/browse/GERONIMO-2321?page=all ] Donald Woods closed GERONIMO-2321. -- Resolution: Duplicate Fixed by patch for Geronimo-2314. DB Pool wizard allows / in the DB Pool name - Key: GERONIMO-2321 URL: http://issues.apache.org/jira/browse/GERONIMO-2321 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: console Affects Versions: 1.1, 1.1.1 Environment: Geronimo 1.1.1 Reporter: Donald Woods Assigned To: Donald Woods Priority: Minor Fix For: 1.1.x, 1.2 Follow the database pool wizard, create a datasource with the name jdbc/EmployeeDatasource, the connection test is successful, but when click on the button deploy, see the following stacktrace in the server output window: org.apache.geronimo.common.DeploymentException: java.lang.IllegalArgumentException: Invalid id: console.dbpool/jdbc/EmployeeDatasource/1.0/rar at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:364) at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:124) at org.apache.geronimo.deployment.Deployer$$FastClassByCGLIB$$734a235d.invoke(generated) at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53) at org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38) at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:122) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:852) at org.apache.geronimo.kernel.basic.BasicKernel.invoke(BasicKernel.java:239) at org.apache.geronimo.deployment.plugin.local.AbstractDeployCommand.doDeploy(AbstractDeployCommand.java:106) at org.apache.geronimo.deployment.plugin.local.DistributeCommand.run(DistributeCommand.java:60) at java.lang.Thread.run(Thread.java:797) Caused by: java.lang.IllegalArgumentException: Invalid id: console.dbpool/jdbc/EmployeeDatasource/1.0/rar at org.apache.geronimo.kernel.repository.Artifact.create(Artifact.java:49) at org.apache.geronimo.deployment.Deployer.notifyWatchers(Deployer.java:376) at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:325) ... 10 more The Portlet should validate that the DB Pool Name does not contain / or white space. -- 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: Build failure on branches/1.1.1 due to geronimo-j2ee-jacc_1.0_spec-1.1.1.jar
Sorry for my late reponse. I was taking a bit of a holidy over the weekend. The 1.1.1 build is broken due to the unreleased version of the jars you mentioned. The appropriate jars can be found here. http://people.apache.org/~hogstrom/1.1.1-rc1 I think in the future I'll verison the specs with an rc1,2,3... as well. Too many moving parts. Jacek Laskowski wrote: On 8/31/06, Vamsavardhana Reddy [EMAIL PROTECTED] wrote: Build is failing due to geronimo-j2ee-jacc_1.0_spec-1.1.1.jar unavailable in the repository. Has anyone else hit this error? Console output given below. Haven't checked it out, but seems that you need to co https://svn.apache.org/repos/asf/geronimo/specs/tags/1_1 and built it. It should've worked with no additional steps, though, I guess. I'd wait for Matt to comment on it. Perhaps we may need to publish them if they're not available anywhere. Don't know what Geronimo version the JIRA task to put in, though, when it's fixed (you will report the JIRA item, will you? ;-) ) Jacek
Re: servicemix-http and normalization
I think Maciej meant RPC literal (non-encoded XML), which leads to multiple parts and is allowed by WS-I BP 1.1. alex Guillaume Nodet wrote: See http://www.ws-i.org/Profiles/BasicProfile-1.1-2004-08-24.html#SOAP_encodingStyle_Attribute it seems pretty clear for me, but maybe i misread it. On 9/5/06, Maciej Szefler [EMAIL PROTECTED] wrote: I don't recall there being anything in WSI-BP that prohibits the usage of RPC-literal encoding, which results in multiple parts. -mbs On 9/5/06, Alex Boisvert [EMAIL PROTECTED] wrote: Oh yes, good question! The point of mapping headers into message content is that many applications/frameworks do not give you easy access (or advise against accessing) message headers. Take, for example, BPEL processes. BPEL only gives you access to the abstract message definition. If headers are not defined and mapped into the content, you can't access them in a portable way. Maybe we could have a configuration attribute to normalize using WSDL 1.1 or WSDL 2.0? That way, if there are no mapped headers and only one SOAP body element, then we could have basic support for WSDL 2.0. I'm very interested in getting full WSDL 1.1 support because that's what's mostly used and deployed today. The tooling and infrastructure ecosystem works great with WSDL 1.1 but still has ways to go with WSDL 2.0. With complete WSDL 1.1 support, we can make the most of ServiceMix today and gradually migrate to WSDL 2.0 when it becomes more widespread. alex Guillaume Nodet wrote: I have attached an updated patch to the jira http://issues.apache.org/activemq/secure/ManageAttachments.jspa?id=24443 I still have some questions, now that I have a better understanding of what the patch do. Mainly, I'm questionning the need to the wsdl 1.1 jbi wrapper. If all services exposed and invoked by servicemix are ws-i basic profile compliant, there is only one child in the soap body. Other parts that may be included in the normalized message may come from soap headers. So we are in the same case as for WSDL 2.0: only one element in the soap body, and additioanl soap headers. However, for WSDL 2, soap headers won't be mapped inside the xml content, but should be put as properties on the message. So i'm not quite sure if headers should be put inside the content for WSDL 1.1, as it will not be consistent. I don't really see the point of the wrapper here. Thoughts ? On 8/31/06, Alex Boisvert [EMAIL PROTECTED] wrote: Guillaume Nodet wrote: The binding model should only be built on top of the wsdl for the current HttpEndpoint (either consumer or provider). This WSDL can be explicitely set, or may be auto-generated using the target endpoint WSDL. If the WSDL is provided, there is nothing to do, but if the WSDL is generated, we have to: * check if there is any existing binding infos (for example, if the target endpoint is a soap provider). In this case, we should use the binding informations * else, we need a flag on the http endpoint to set the binding style (rpc / doc). If the user need to provide a more detailed binding, then he has to provide it in the wsdl. Ok, that clarifies it. I'm trying to abstract the SoapBindingModel a bit more to be able to easily handle a plain HTTP binding. WSDL 2.0 bindings will require another reformat later i guess. Cool! I might be able to help with WSDL 2.0 as well. thanks, alex
[jira] Commented: (GERONIMO-2324) Allow in-place and exploded jar support for sharedlib
[ http://issues.apache.org/jira/browse/GERONIMO-2324?page=comments#action_12432657 ] Sachin Patel commented on GERONIMO-2324: Oleg.. Could you clarrify what you are doing in the following situation currently??? Lets say you have a single project, WebProject-A in your workspace. This project has a classpath reference to an external jar foo.jar (which in production gets copied to the sharedlib. Now lets say you want to make modifcations to foo.jar and you import foo.jar into your workspace as project Foo. What are you doing with the classpath reference on WebProject-A to Foo.jar? Are you currently manually deleting it and replacng it with a project reference to project Foo? I see a problem in this especially if you are keeping your .project and .classpath file's under source control. Is this the case? If so then people could accidentally commit these and the next person who checks out the code would have a .classpath reference to a non existent project. This is dangerous. How do you plan to address this? Allow in-place and exploded jar support for sharedlib - Key: GERONIMO-2324 URL: http://issues.apache.org/jira/browse/GERONIMO-2324 Project: Geronimo Issue Type: RTC Security Level: public(Regular issues) Components: deployment Affects Versions: 1.1 Reporter: Sachin Patel Assigned To: Sachin Patel Fix For: 1.x Attachments: GERONIMO-2324.patch, GERONIMO-2324.patch The shared library support should allow in-place support to allow and load jars (exploded as well) that are located externally on the filesystem. This is needed to improve developer experience and allow better integration within tooling and the runtime. Perhaps we can have a properties file insie the shared lib that have external entries in them. -- 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: Restructuring trunk, then next steps
I'm assuming everything is not geronimo- ... that might be from the department of redundancy department. Jason Dillon wrote: So, I've mentioned a few times before that we should start thinking about how to split up modules in trunk into a few smaller chunks. I took a few minutes and took a crude stab at what that might look like. This is just an example of how it might work... I did not do any extensive research into dependencies... Basically, I split things up into 5 main trees: * framework - common stuff, not really the server, but supports the server, modules here should have minimal deps * system - the major components which make up the server's system (should be the bits to start up a server shell) * tools - bits that support the system * plugins - components which plugin to the system * testsuite - placeholder for modules which will be aded soon that use the itest plugin to perform integration tests I'm not sure if this is the best split, but it kinda comes closer to what I hope we can get to. Below is how the modules that exists fit into these sections. framework/ geronimo-testsupport (may need to be in other tree? so can include in all modules by default) geronimo-common geronimo-util geronimo-interceptor geronimo-activation geronimo-kernel system/ geronimo-management geronimo-security geronimo-security-builder geronimo-service-builder geronimo-core geronimo-system geronimo-transaction geronimo-connector geronimo-connector-builder geronimo-jmx-remoting geronimo-naming geronimo-naming-builder geronimo-test-ddbean (wtf is this for?) geronimo-deployment/ geronimo-deployment (rename to -core) ? geronimo-deploy-config geronimo-deploy-jsr88 geronimo-deploy-tool geronimo-hot-deploy geronimo-client geronimo-client-builder geronimo-j2ee/ geronimo-j2ee geronimo-j2ee-builder geronimo-j2ee-schema geronimo-web-builder plugins/ geronimo-activemq/ ge-activemq-rar (rename) geronimo-activemq-gbean geronimo-activemq-gbean-management geronimo-axis geronimo-axis-builder geronimo-derby geronimo-directory geronimo-tomcat geronimo-tomcat-builder geronimo-jetty geronimo-jetty-builder geronimo-mail geronimo-timer geronimo-webservices tools/ geronimo-upgrade geronimo-converter testsuite/ TODO, home for itest usage Anyways, I wanted to post what I am thinking. I think that we are really close to the point where we will want to implement this sort of split up. Comments? --jason
[jira] Updated: (GERONIMO-2314) Can not create a datasource with the name jdbc/EmployeeDatasource from console
[ http://issues.apache.org/jira/browse/GERONIMO-2314?page=all ]
Donald Woods updated GERONIMO-2314:
---
Attachment: G2314-1.1.patch
Attaching patch that correctly handles the jdbc/ case and will throw a
meaningful exception if more than one / is supplied in the datasource name.
Patch was created against the 1.1 branch directory (1.1.2-SNAPSHOT) at
Rev438015 and should be applied to the applications directory.
Can not create a datasource with the name jdbc/EmployeeDatasource from
console
Key: GERONIMO-2314
URL: http://issues.apache.org/jira/browse/GERONIMO-2314
Project: Geronimo
Issue Type: Bug
Security Level: public(Regular issues)
Components: console
Affects Versions: 1.1, 1.1.1, 1.1.2, 1.2
Reporter: Yunfeng Ma
Assigned To: Donald Woods
Fix For: 1.1.2
Attachments: G2314-1.1.patch
Follow the database pool wizard, create a datasource with the name
jdbc/EmployeeDatasource, the connection test is successful, but when click
on the button deploy, see the following stacktrace in the server output
window:
org.apache.geronimo.common.DeploymentException:
java.lang.IllegalArgumentException: Invalid id:
console.dbpool/jdbc/EmployeeDatasource/1.0/rar
at
org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:364)
at
org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:124)
at
org.apache.geronimo.deployment.Deployer$$FastClassByCGLIB$$734a235d.invoke(generated)
at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53)
at
org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38)
at
org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:122)
at
org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:852)
at
org.apache.geronimo.kernel.basic.BasicKernel.invoke(BasicKernel.java:239)
at
org.apache.geronimo.deployment.plugin.local.AbstractDeployCommand.doDeploy(AbstractDeployCommand.java:106)
at
org.apache.geronimo.deployment.plugin.local.DistributeCommand.run(DistributeCommand.java:60)
at java.lang.Thread.run(Thread.java:797)
Caused by:
java.lang.IllegalArgumentException: Invalid id:
console.dbpool/jdbc/EmployeeDatasource/1.0/rar
at
org.apache.geronimo.kernel.repository.Artifact.create(Artifact.java:49)
at
org.apache.geronimo.deployment.Deployer.notifyWatchers(Deployer.java:376)
at
org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:325)
... 10 more
This error just happens in the condition of the database pool name includes
the character /, such as jdbc/EmployeeDatasource. If database pool name
is EmployeeDatasource, then everything is OK.
Have a look at the souce codes of Artifact.java, the snippet of create method
as following:
public static Artifact create(String id) {
String[] parts = id.split(/, -1);
if (parts.length != 4) {
throw new IllegalArgumentException(Invalid id: + id);
}
for (int i = 0; i parts.length; i++) {
if (parts[i].equals()) {
parts[i] = null;
}
}
return new Artifact(parts[0], parts[1], parts[2], parts[3]);
}
If database pool name is jdbc/EmployeeDatasource, the parts.length would be
5 and IllegalArgumentException would be throwed.
--
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: servicemix-http and normalization
Yes, WS-I BP 1.1 supports RPC literal, so there will be several parts in the message, but they are all wrapped inside an element with the operation name. This lead to a single child for the soap body element. Currently, servicemix-http passes this child as the content of the normalized message. On 9/5/06, Alex Boisvert [EMAIL PROTECTED] wrote: I think Maciej meant RPC literal (non-encoded XML), which leads to multiple parts and is allowed by WS-I BP 1.1. alex Guillaume Nodet wrote: See http://www.ws-i.org/Profiles/BasicProfile-1.1-2004-08-24.html#SOAP_encodingStyle_Attribute it seems pretty clear for me, but maybe i misread it. On 9/5/06, Maciej Szefler [EMAIL PROTECTED] wrote: I don't recall there being anything in WSI-BP that prohibits the usage of RPC-literal encoding, which results in multiple parts. -mbs On 9/5/06, Alex Boisvert [EMAIL PROTECTED] wrote: Oh yes, good question! The point of mapping headers into message content is that many applications/frameworks do not give you easy access (or advise against accessing) message headers. Take, for example, BPEL processes. BPEL only gives you access to the abstract message definition. If headers are not defined and mapped into the content, you can't access them in a portable way. Maybe we could have a configuration attribute to normalize using WSDL 1.1 or WSDL 2.0? That way, if there are no mapped headers and only one SOAP body element, then we could have basic support for WSDL 2.0. I'm very interested in getting full WSDL 1.1 support because that's what's mostly used and deployed today. The tooling and infrastructure ecosystem works great with WSDL 1.1 but still has ways to go with WSDL 2.0. With complete WSDL 1.1 support, we can make the most of ServiceMix today and gradually migrate to WSDL 2.0 when it becomes more widespread. alex Guillaume Nodet wrote: I have attached an updated patch to the jira http://issues.apache.org/activemq/secure/ManageAttachments.jspa?id=24443 I still have some questions, now that I have a better understanding of what the patch do. Mainly, I'm questionning the need to the wsdl 1.1 jbi wrapper. If all services exposed and invoked by servicemix are ws-i basic profile compliant, there is only one child in the soap body. Other parts that may be included in the normalized message may come from soap headers. So we are in the same case as for WSDL 2.0: only one element in the soap body, and additioanl soap headers. However, for WSDL 2, soap headers won't be mapped inside the xml content, but should be put as properties on the message. So i'm not quite sure if headers should be put inside the content for WSDL 1.1, as it will not be consistent. I don't really see the point of the wrapper here. Thoughts ? On 8/31/06, Alex Boisvert [EMAIL PROTECTED] wrote: Guillaume Nodet wrote: The binding model should only be built on top of the wsdl for the current HttpEndpoint (either consumer or provider). This WSDL can be explicitely set, or may be auto-generated using the target endpoint WSDL. If the WSDL is provided, there is nothing to do, but if the WSDL is generated, we have to: * check if there is any existing binding infos (for example, if the target endpoint is a soap provider). In this case, we should use the binding informations * else, we need a flag on the http endpoint to set the binding style (rpc / doc). If the user need to provide a more detailed binding, then he has to provide it in the wsdl. Ok, that clarifies it. I'm trying to abstract the SoapBindingModel a bit more to be able to easily handle a plain HTTP binding. WSDL 2.0 bindings will require another reformat later i guess. Cool! I might be able to help with WSDL 2.0 as well. thanks, alex -- Cheers, Guillaume Nodet
[jira] Updated: (GERONIMO-2314) Can not create a datasource with the name jdbc/EmployeeDatasource from console
[ http://issues.apache.org/jira/browse/GERONIMO-2314?page=all ]
Donald Woods updated GERONIMO-2314:
---
Patch Info: [Patch Available]
Fix Version/s: 1.2
Assignee: (was: Donald Woods)
Unassigning from me so a committer can grab it
Can not create a datasource with the name jdbc/EmployeeDatasource from
console
Key: GERONIMO-2314
URL: http://issues.apache.org/jira/browse/GERONIMO-2314
Project: Geronimo
Issue Type: Bug
Security Level: public(Regular issues)
Components: console
Affects Versions: 1.1, 1.1.1, 1.1.2, 1.2
Reporter: Yunfeng Ma
Fix For: 1.1.2, 1.2
Attachments: G2314-1.1.patch
Follow the database pool wizard, create a datasource with the name
jdbc/EmployeeDatasource, the connection test is successful, but when click
on the button deploy, see the following stacktrace in the server output
window:
org.apache.geronimo.common.DeploymentException:
java.lang.IllegalArgumentException: Invalid id:
console.dbpool/jdbc/EmployeeDatasource/1.0/rar
at
org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:364)
at
org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:124)
at
org.apache.geronimo.deployment.Deployer$$FastClassByCGLIB$$734a235d.invoke(generated)
at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53)
at
org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38)
at
org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:122)
at
org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:852)
at
org.apache.geronimo.kernel.basic.BasicKernel.invoke(BasicKernel.java:239)
at
org.apache.geronimo.deployment.plugin.local.AbstractDeployCommand.doDeploy(AbstractDeployCommand.java:106)
at
org.apache.geronimo.deployment.plugin.local.DistributeCommand.run(DistributeCommand.java:60)
at java.lang.Thread.run(Thread.java:797)
Caused by:
java.lang.IllegalArgumentException: Invalid id:
console.dbpool/jdbc/EmployeeDatasource/1.0/rar
at
org.apache.geronimo.kernel.repository.Artifact.create(Artifact.java:49)
at
org.apache.geronimo.deployment.Deployer.notifyWatchers(Deployer.java:376)
at
org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:325)
... 10 more
This error just happens in the condition of the database pool name includes
the character /, such as jdbc/EmployeeDatasource. If database pool name
is EmployeeDatasource, then everything is OK.
Have a look at the souce codes of Artifact.java, the snippet of create method
as following:
public static Artifact create(String id) {
String[] parts = id.split(/, -1);
if (parts.length != 4) {
throw new IllegalArgumentException(Invalid id: + id);
}
for (int i = 0; i parts.length; i++) {
if (parts[i].equals()) {
parts[i] = null;
}
}
return new Artifact(parts[0], parts[1], parts[2], parts[3]);
}
If database pool name is jdbc/EmployeeDatasource, the parts.length would be
5 and IllegalArgumentException would be throwed.
--
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: Restructuring trunk, then next steps
The problem with not keeping the geronimo- prefix is that all jars will end up as activemq-1.2.jar activation-1.2.jarIt will be highly confusing.The other solution is to break the directory name = artifactId rule, which is imho a bad idea.On 9/5/06, Matt Hogstrom [EMAIL PROTECTED] wrote: I'm assuming everything is not geronimo- ... that might be from the department of redundancy department.Jason Dillon wrote: So, I've mentioned a few times before that we should start thinking about how to split up modules in trunk into a few smaller chunks.I took a few minutes and took a crude stab at what that might look like. This is just an example of how it might work... I did not do any extensive research into dependencies... Basically, I split things up into 5 main trees: * framework - common stuff, not really the server, but supports the server, modules here should have minimal deps* system - the major components which make up the server's system (should be the bits to start up a server shell) * tools - bits that support the system* plugins - components which plugin to the system* testsuite - placeholder for modules which will be aded soon that use the itest plugin to perform integration tests I'm not sure if this is the best split, but it kinda comes closer to what I hope we can get to.Below is how the modules that exists fit into these sections. framework/ geronimo-testsupport (may need to be in other tree? so can include in all modules by default) geronimo-common geronimo-util geronimo-interceptor geronimo-activation geronimo-kernel system/ geronimo-management geronimo-security geronimo-security-builder geronimo-service-builder geronimo-core geronimo-system geronimo-transaction geronimo-connector geronimo-connector-builder geronimo-jmx-remoting geronimo-naming geronimo-naming-builder geronimo-test-ddbean (wtf is this for?) geronimo-deployment/ geronimo-deployment (rename to -core) ? geronimo-deploy-config geronimo-deploy-jsr88 geronimo-deploy-tool geronimo-hot-deploy geronimo-client geronimo-client-builder geronimo-j2ee/ geronimo-j2ee geronimo-j2ee-builder geronimo-j2ee-schema geronimo-web-builder plugins/ geronimo-activemq/ ge-activemq-rar (rename) geronimo-activemq-gbean geronimo-activemq-gbean-management geronimo-axis geronimo-axis-builder geronimo-derby geronimo-directory geronimo-tomcat geronimo-tomcat-builder geronimo-jetty geronimo-jetty-builder geronimo-mail geronimo-timer geronimo-webservices tools/ geronimo-upgrade geronimo-converter testsuite/ TODO, home for itest usage Anyways, I wanted to post what I am thinking.I think that we are really close to the point where we will want to implement this sort of split up. Comments? --jason-- Cheers,Guillaume Nodet
Re: Restructuring trunk, then next steps
I understand your point. I guess I'm conflicted at this point as it seems like Geronimo is becoming a Maven project :-) If the underlying tool is causing such fundamental changes to the way the project is structured, named, etc. is the tool flexible enough? I don't mean to start a rant or a huge debate as I know many people love Maven. I'm just commenting that it seems like were spending more time restructuring Geronimo around Maven than we are developing Geronimo. Seems a bit backwards. Ok, flamesuit on :) Guillaume Nodet wrote: The problem with not keeping the geronimo- prefix is that all jars will end up as activemq-1.2.jar activation-1.2.jar It will be highly confusing. The other solution is to break the directory name = artifactId rule, which is imho a bad idea. On 9/5/06, Matt Hogstrom [EMAIL PROTECTED] wrote: I'm assuming everything is not geronimo- ... that might be from the department of redundancy department. Jason Dillon wrote: So, I've mentioned a few times before that we should start thinking about how to split up modules in trunk into a few smaller chunks. I took a few minutes and took a crude stab at what that might look like. This is just an example of how it might work... I did not do any extensive research into dependencies... Basically, I split things up into 5 main trees: * framework - common stuff, not really the server, but supports the server, modules here should have minimal deps * system - the major components which make up the server's system (should be the bits to start up a server shell) * tools - bits that support the system * plugins - components which plugin to the system * testsuite - placeholder for modules which will be aded soon that use the itest plugin to perform integration tests I'm not sure if this is the best split, but it kinda comes closer to what I hope we can get to. Below is how the modules that exists fit into these sections. framework/ geronimo-testsupport (may need to be in other tree? so can include in all modules by default) geronimo-common geronimo-util geronimo-interceptor geronimo-activation geronimo-kernel system/ geronimo-management geronimo-security geronimo-security-builder geronimo-service-builder geronimo-core geronimo-system geronimo-transaction geronimo-connector geronimo-connector-builder geronimo-jmx-remoting geronimo-naming geronimo-naming-builder geronimo-test-ddbean (wtf is this for?) geronimo-deployment/ geronimo-deployment (rename to -core) ? geronimo-deploy-config geronimo-deploy-jsr88 geronimo-deploy-tool geronimo-hot-deploy geronimo-client geronimo-client-builder geronimo-j2ee/ geronimo-j2ee geronimo-j2ee-builder geronimo-j2ee-schema geronimo-web-builder plugins/ geronimo-activemq/ ge-activemq-rar (rename) geronimo-activemq-gbean geronimo-activemq-gbean-management geronimo-axis geronimo-axis-builder geronimo-derby geronimo-directory geronimo-tomcat geronimo-tomcat-builder geronimo-jetty geronimo-jetty-builder geronimo-mail geronimo-timer geronimo-webservices tools/ geronimo-upgrade geronimo-converter testsuite/ TODO, home for itest usage Anyways, I wanted to post what I am thinking. I think that we are really close to the point where we will want to implement this sort of split up. Comments? --jason
Re: Restructuring trunk, then next steps
Right, the pom can and should contain the geronimo-prefix but why is it necessary for the directory structure to match? With all the file length problems, I also this this is unnecessary and redundant.On Sep 5, 2006, at 3:36 PM, Guillaume Nodet wrote:The problem with not keeping the geronimo- prefix is that all jars will end up as activemq-1.2.jar activation-1.2.jarIt will be highly confusing.The other solution is to break the directory name = artifactId rule, which is imho a bad idea.On 9/5/06, Matt Hogstrom [EMAIL PROTECTED] wrote: I'm assuming everything is not geronimo- ... that might be from the department of redundancy department.Jason Dillon wrote: So, I've mentioned a few times before that we should start thinking about how to split up modules in trunk into a few smaller chunks. I took a few minutes and took a crude stab at what that might look like. This is just an example of how it might work... I did not do any extensive research into dependencies... Basically, I split things up into 5 main trees: * framework - common stuff, not really the server, but supports the server, modules here should have minimal deps * system - the major components which make up the server's system (should be the bits to start up a server shell) * tools - bits that support the system * plugins - components which plugin to the system * testsuite - placeholder for modules which will be aded soon that use the itest plugin to perform integration tests I'm not sure if this is the best split, but it kinda comes closer to what I hope we can get to. Below is how the modules that exists fit into these sections. framework/ geronimo-testsupport (may need to be in other tree? so can include in all modules by default) geronimo-common geronimo-util geronimo-interceptor geronimo-activation geronimo-kernel system/ geronimo-management geronimo-security geronimo-security-builder geronimo-service-builder geronimo-core geronimo-system geronimo-transaction geronimo-connector geronimo-connector-builder geronimo-jmx-remoting geronimo-naming geronimo-naming-builder geronimo-test-ddbean (wtf is this for?) geronimo-deployment/ geronimo-deployment (rename to -core) ? geronimo-deploy-config geronimo-deploy-jsr88 geronimo-deploy-tool geronimo-hot-deploy geronimo-client geronimo-client-builder geronimo-j2ee/ geronimo-j2ee geronimo-j2ee-builder geronimo-j2ee-schema geronimo-web-builder plugins/ geronimo-activemq/ ge-activemq-rar (rename) geronimo-activemq-gbean geronimo-activemq-gbean-management geronimo-axis geronimo-axis-builder geronimo-derby geronimo-directory geronimo-tomcat geronimo-tomcat-builder geronimo-jetty geronimo-jetty-builder geronimo-mail geronimo-timer geronimo-webservices tools/ geronimo-upgrade geronimo-converter testsuite/ TODO, home for itest usage Anyways, I wanted to post what I am thinking. I think that we are really close to the point where we will want to implement this sort of split up. Comments? --jason-- Cheers,Guillaume Nodet -sachin
Re: servicemix-http and normalization
Guillaume Nodet wrote: Yes, WS-I BP 1.1 supports RPC literal, so there will be several parts in the message, but they are all wrapped inside an element with the operation name. This lead to a single child for the soap body element. Currently, servicemix-http passes this child as the content of the normalized message. Yes, and that's the root of the problem. Normalization is left to the component. Ideally, we'd like to move this code into the bus such that multiple components can benefit from this normalization and not care whether the transport message format is Document-style or Procedural-Style. And it also covers the cases where you can to access/handle SOAP headers. alex
Re: servicemix-http and normalization
Guillaume Nodet wrote: Not sure if I understand you. Are you saying you also want to normalize WSDL 2 based soap envelopes the same way ? Using WSDL 2, the rpc-lit style does not exist anymore, so you only have a single child in the soap body which is described using an xml schema. I'm proposing that we could have configurable normalization paths: 1) SOAP 1.x message described with WSDL 1.1 = WSDL 1.1-wrapped JBI normalized message 2) SOAP 1.x message described with WSDL 1.1/2.0) = Standard JBI normalized message 3) SOAP 1.x message described with WSDL 2.0 = WSDL 1.1-wrapped JBI normalized message The 2nd case works only if there's only one message part (i.e., SOAP body) and Document-Literal binding. The 3rd case isn't supported yet. alex
Re: When has the server started?
I'm not sure that happens in every instance. I seem to remember that an Application (Daytrader) that failed to start and the server still initialized. I'll need to confirm this. Aaron Mulder wrote: On 9/5/06, Matt Hogstrom [EMAIL PROTECTED] wrote: Not to get too pedantic but what if some of the configurations in the persistent configuration couldn't be started for some reason, is the server still fully started? Currently if that happens, the server shuts down. That's another issue we might want to revisit. Thanks, Aaron Perhaps something more like initialBootstrapCompleted might be more intuitive. When we thought about this last the best idea we could come up with is that it's fully started when all the modules listed in persistent configuration lists (should be persistent module lists) that are in the bootstrap or included recursively in those modules are started. Think about what happens if a module in the original PCL includes another PCL. Started (or fully started) means that the server has loaded, initialized and started all modules in the persistent configuration, such that it could then start to serve applications... and start listening on ports, etc. True there might be more modules to be loaded or configured after that, but the point is to tell when the server is ready to start accepting work. There is a period while the server is starting, when it starts listening to http, but it is not ready to serve applications which have been configured to be deployed. Anyways, I don't care too much what it is called... but I think that flag should be exposed as a simple Boolean on some common MBean. Maybe its not the Kernel, as the kernel might be started, but the system might not be ready to serve my webapps or whatever. Having to pull in geronimo-kernel to perform a simple remote call to fetch a boolean is overkill... especially since that module has magical logging fluff that rudely overwrites configuration. If we had a specialized MBean/GBean that just exposed the very common remote functionality via JMX directly then we would be in a very good position to keep tools (IDE plugins, maven plugins, etc) working even after we change the internals around. Such tools need an easy way to: * Detect when the server is started and ready to server applications * Shutdown Probably some other things too... --jason
Release Early, Release Often
According to our STATUS file, our last feature release (1.1) was on 2006-06-26 which is about 2.5 months ago. I'm not sure exactly what we have in trunk right now, but I'd guess we most likely have enough to do a release right now. I'm going to spend a few hours today browsing the JIRAs and SVN logs and compile a list of the features we have in trunk right now. Anyways, I'll let you know what I find and we can figure out what we want to do. Thanks, -dain
Move STAUS file?
Since the last svn reorg our status file is now located at: http://svn.apache.org/repos/asf/geronimo/server/trunk/STATUS I propose we move it to: http://svn.apache.org/repos/asf/geronimo/STATUS So it is easy for anyone to find. -dain
Re: Core-Jaas dependencies ... again
Sepand, It's ok if it's compile time required... as long as it's not runtime required. To me that means it's optional. Since by default the broker is not configured with JAAS, you could run the borker without the jaas jars. On 9/5/06, Sepand M [EMAIL PROTECTED] wrote: Responses below On 9/5/06, Guillaume Nodet [EMAIL PROTECTED] wrote: What do you mean by non optional dependency ? A dependency can always be set as optional, and actually is until you use it. The way things are, core always needs jaas, so it's not really optional. I guess the other solution is to create a module for these classes only, but i' m not sure it' s worth it. I highly doubt it's worth the effort. On 9/5/06, Sepand M [EMAIL PROTECTED] wrote: Hi guys, I brought this up before and I thought it was solved, but it isn't. The basic problem is that JaasAuthenticationBroker, JaasCertificationAuthenticationBroker (that's a new class), and their supporting classes need Broker, BrokerFilter, etc. and also need JaasCertificateCallback (also new), etc. Broker, BrokerFilter are in the core module (for obvious reasons) and JaasCertificateCallback, etc. are in Jaas module. This forces a non-optional dependency between core and jaas, which from what I understand we are trying to avoid. Moving JaasAuthenticationBroker and JaasCertificationAuthenticationBroker to jaas is not an option (as far as I know) since mvn doesn't allow a circular dependency (from core to jaas and back to core). Obviously moving everything into core is dumb. So... any suggestions? Regards, Sepand -- Cheers, Guillaume Nodet -- Regards, Hiram Blog: http://hiramchirino.com
Re: Move STAUS file?
On 9/5/06, Dain Sundstrom [EMAIL PROTECTED] wrote: Since the last svn reorg our status file is now located at: http://svn.apache.org/repos/asf/geronimo/server/trunk/STATUS I propose we move it to: http://svn.apache.org/repos/asf/geronimo/STATUS So it is easy for anyone to find. +1 Jacek -- Jacek Laskowski http://www.laskowski.net.pl
[jira] Commented: (GERONIMO-2113) Geronimo doesn't start if restarted using another JDK
[ http://issues.apache.org/jira/browse/GERONIMO-2113?page=comments#action_12432672 ] Donald Woods commented on GERONIMO-2113: You're having problems with the updated Aug. 4th patch file that was created against the 1.1.1 branch? Not sure how the above is an error, as I use TortoiseSVN on Windows What command are you using to apply the patch file? Geronimo doesn't start if restarted using another JDK - Key: GERONIMO-2113 URL: http://issues.apache.org/jira/browse/GERONIMO-2113 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: transaction manager Affects Versions: 1.2, 1.1, 1.1.1 Reporter: Nellya Udovichenko Assigned To: David Jencks Fix For: 1.2, 1.1.2 Attachments: HOWLLog.patch, HOWLLog.patch There is a bug in HOWL. At Geronimo launching time the file content control sum is calculated by the function java.nio.ByteBuffer.hashCode(). Therefore, if hash code algorithms of various JDKs differ Geronimo doesn't start. The bug is repaired in howl-1.0.1 by the introducing of the new parameter adler32Checksum. If the parameter value is false the control sum is calculated by the function java.nio.ByteBuffer.hashCode() otherwise it is calculated using ADLER-32 algorithm. Attached patch adds the parameter to configs/j2ee-server/src/plan/plan.xml and to org.apache.geronimo.transaction.log.HOWLLog gbean with default value 'true'. -- 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: Core-Jaas dependencies ... again
Oh. That makes more sense (and works well). Thanks, Sepand On 9/5/06, Hiram Chirino [EMAIL PROTECTED] wrote: Sepand, It's ok if it's compile time required... as long as it's not runtime required. To me that means it's optional. Since by default the broker is not configured with JAAS, you could run the borker without the jaas jars. On 9/5/06, Sepand M [EMAIL PROTECTED] wrote: Responses below On 9/5/06, Guillaume Nodet [EMAIL PROTECTED] wrote: What do you mean by non optional dependency ? A dependency can always be set as optional, and actually is until you use it. The way things are, core always needs jaas, so it's not really optional. I guess the other solution is to create a module for these classes only, but i' m not sure it' s worth it. I highly doubt it's worth the effort. On 9/5/06, Sepand M [EMAIL PROTECTED] wrote: Hi guys, I brought this up before and I thought it was solved, but it isn't. The basic problem is that JaasAuthenticationBroker, JaasCertificationAuthenticationBroker (that's a new class), and their supporting classes need Broker, BrokerFilter, etc. and also need JaasCertificateCallback (also new), etc. Broker, BrokerFilter are in the core module (for obvious reasons) and JaasCertificateCallback, etc. are in Jaas module. This forces a non-optional dependency between core and jaas, which from what I understand we are trying to avoid. Moving JaasAuthenticationBroker and JaasCertificationAuthenticationBroker to jaas is not an option (as far as I know) since mvn doesn't allow a circular dependency (from core to jaas and back to core). Obviously moving everything into core is dumb. So... any suggestions? Regards, Sepand -- Cheers, Guillaume Nodet -- Regards, Hiram Blog: http://hiramchirino.com
Re: Restructuring trunk, then next steps
I am sure that some of these names will change... But the directory name should be the same as the artifactId... so that its easy to see where the source for artifacts come from, and because some maven plugins that work on sets of modules make that assumption (like site plugin for example) when running. This is a best practice with Maven... and I don't recommend moving away from that. Before we already had things like console-jetty making a jar named webconsole-jetty-* and others too which only make it more difficult to tell where these things come from. --jason On Sep 5, 2006, at 12:25 PM, Matt Hogstrom wrote: I'm assuming everything is not geronimo- ... that might be from the department of redundancy department. Jason Dillon wrote: So, I've mentioned a few times before that we should start thinking about how to split up modules in trunk into a few smaller chunks. I took a few minutes and took a crude stab at what that might look like. This is just an example of how it might work... I did not do any extensive research into dependencies... Basically, I split things up into 5 main trees: * framework - common stuff, not really the server, but supports the server, modules here should have minimal deps * system - the major components which make up the server's system (should be the bits to start up a server shell) * tools - bits that support the system * plugins - components which plugin to the system * testsuite - placeholder for modules which will be aded soon that use the itest plugin to perform integration tests I'm not sure if this is the best split, but it kinda comes closer to what I hope we can get to. Below is how the modules that exists fit into these sections. framework/ geronimo-testsupport (may need to be in other tree? so can include in all modules by default) geronimo-common geronimo-util geronimo-interceptor geronimo-activation geronimo-kernel system/ geronimo-management geronimo-security geronimo-security-builder geronimo-service-builder geronimo-core geronimo-system geronimo-transaction geronimo-connector geronimo-connector-builder geronimo-jmx-remoting geronimo-naming geronimo-naming-builder geronimo-test-ddbean (wtf is this for?) geronimo-deployment/ geronimo-deployment (rename to -core) ? geronimo-deploy-config geronimo-deploy-jsr88 geronimo-deploy-tool geronimo-hot-deploy geronimo-client geronimo-client-builder geronimo-j2ee/ geronimo-j2ee geronimo-j2ee-builder geronimo-j2ee-schema geronimo-web-builder plugins/ geronimo-activemq/ ge-activemq-rar (rename) geronimo-activemq-gbean geronimo-activemq-gbean-management geronimo-axis geronimo-axis-builder geronimo-derby geronimo-directory geronimo-tomcat geronimo-tomcat-builder geronimo-jetty geronimo-jetty-builder geronimo-mail geronimo-timer geronimo-webservices tools/ geronimo-upgrade geronimo-converter testsuite/ TODO, home for itest usage Anyways, I wanted to post what I am thinking. I think that we are really close to the point where we will want to implement this sort of split up. Comments? --jason
Re: Restructuring trunk, then next steps
On Sep 5, 2006, at 12:56 PM, Matt Hogstrom wrote: I understand your point. I guess I'm conflicted at this point as it seems like Geronimo is becoming a Maven project :-) If the underlying tool is causing such fundamental changes to the way the project is structured, named, etc. is the tool flexible enough? Fundamental changes to the way the project is structured? Huh? Do you mean that the 'geronimo-' prefix is fundament to structure? Its a naming convention and not related to structure at all. The structure bits which this email was started for are related to the way that the G project has ended up from a long time with Maven1. And how it would be better to restructure the project to organize components, dependency modules and to take advantage of Maven2 integrated multi-moulde system. I don't mean to start a rant or a huge debate as I know many people love Maven. I'm just commenting that it seems like were spending more time restructuring Geronimo around Maven than we are developing Geronimo. Seems a bit backwards. No... we spend way more time making patches and applying them and praying that someone will vote on them than we do developing Geronimo. And to this point we really have not done much restructuring... only fixing modules to confrom to standards. Now its about how do we organize those modules in the best way to fix into your project. And I can tell you right now that if you think that they all fit into a nice little modules bucket as peers with no hierarchy, that you are on much more crack than I am :-P --jason
Re: Restructuring trunk, then next steps
The directory should match because: * it makes it easier to find out which module produces which artifact * plugins that operate on hierarchies of modules make use of the parent directory name when generating output. if they don't match, then you end up needing to configure each module, which is added elements in the pom to maintainIf you really want this, this convince the maven team that they need to add additional support for a modules directory name in addition to its artifactId and then get them to update all plugins that traverse trees to use this information.Or just keep them the same.--jasonOn Sep 5, 2006, at 12:57 PM, Sachin Patel wrote:Right, the pom can and should contain the geronimo-prefix but why is it necessary for the directory structure to match? With all the file length problems, I also this this is unnecessary and redundant.On Sep 5, 2006, at 3:36 PM, Guillaume Nodet wrote:The problem with not keeping the geronimo- prefix is that all jars will end up as activemq-1.2.jar activation-1.2.jarIt will be highly confusing.The other solution is to break the directory name = artifactId rule, which is imho a bad idea.On 9/5/06, Matt Hogstrom [EMAIL PROTECTED] wrote: I'm assuming everything is not geronimo- ... that might be from the department of redundancy department.Jason Dillon wrote: So, I've mentioned a few times before that we should start thinking about how to split up modules in trunk into a few smaller chunks. I took a few minutes and took a crude stab at what that might look like. This is just an example of how it might work... I did not do any extensive research into dependencies... Basically, I split things up into 5 main trees: * framework - common stuff, not really the server, but supports the server, modules here should have minimal deps * system - the major components which make up the server's system (should be the bits to start up a server shell) * tools - bits that support the system * plugins - components which plugin to the system * testsuite - placeholder for modules which will be aded soon that use the itest plugin to perform integration tests I'm not sure if this is the best split, but it kinda comes closer to what I hope we can get to. Below is how the modules that exists fit into these sections. framework/ geronimo-testsupport (may need to be in other tree? so can include in all modules by default) geronimo-common geronimo-util geronimo-interceptor geronimo-activation geronimo-kernel system/ geronimo-management geronimo-security geronimo-security-builder geronimo-service-builder geronimo-core geronimo-system geronimo-transaction geronimo-connector geronimo-connector-builder geronimo-jmx-remoting geronimo-naming geronimo-naming-builder geronimo-test-ddbean (wtf is this for?) geronimo-deployment/ geronimo-deployment (rename to -core) ? geronimo-deploy-config geronimo-deploy-jsr88 geronimo-deploy-tool geronimo-hot-deploy geronimo-client geronimo-client-builder geronimo-j2ee/ geronimo-j2ee geronimo-j2ee-builder geronimo-j2ee-schema geronimo-web-builder plugins/ geronimo-activemq/ ge-activemq-rar (rename) geronimo-activemq-gbean geronimo-activemq-gbean-management geronimo-axis geronimo-axis-builder geronimo-derby geronimo-directory geronimo-tomcat geronimo-tomcat-builder geronimo-jetty geronimo-jetty-builder geronimo-mail geronimo-timer geronimo-webservices tools/ geronimo-upgrade geronimo-converter testsuite/ TODO, home for itest usage Anyways, I wanted to post what I am thinking. I think that we are really close to the point where we will want to implement this sort of split up. Comments? --jason-- Cheers,Guillaume Nodet -sachin
Re: Restructuring trunk, then next steps
Please don't get mad at me, but I'd like to move a bit slower on more classification inside of the server module. I'd like to pull transaction and connector out to independently versioned modules and then see if the tree still feels crowded. -dain On Sep 5, 2006, at 2:27 PM, Jason Dillon wrote: I am sure that some of these names will change... But the directory name should be the same as the artifactId... so that its easy to see where the source for artifacts come from, and because some maven plugins that work on sets of modules make that assumption (like site plugin for example) when running. This is a best practice with Maven... and I don't recommend moving away from that. Before we already had things like console-jetty making a jar named webconsole-jetty-* and others too which only make it more difficult to tell where these things come from. --jason On Sep 5, 2006, at 12:25 PM, Matt Hogstrom wrote: I'm assuming everything is not geronimo- ... that might be from the department of redundancy department. Jason Dillon wrote: So, I've mentioned a few times before that we should start thinking about how to split up modules in trunk into a few smaller chunks. I took a few minutes and took a crude stab at what that might look like. This is just an example of how it might work... I did not do any extensive research into dependencies... Basically, I split things up into 5 main trees: * framework - common stuff, not really the server, but supports the server, modules here should have minimal deps * system - the major components which make up the server's system (should be the bits to start up a server shell) * tools - bits that support the system * plugins - components which plugin to the system * testsuite - placeholder for modules which will be aded soon that use the itest plugin to perform integration tests I'm not sure if this is the best split, but it kinda comes closer to what I hope we can get to. Below is how the modules that exists fit into these sections. framework/ geronimo-testsupport (may need to be in other tree? so can include in all modules by default) geronimo-common geronimo-util geronimo-interceptor geronimo-activation geronimo-kernel system/ geronimo-management geronimo-security geronimo-security-builder geronimo-service-builder geronimo-core geronimo-system geronimo-transaction geronimo-connector geronimo-connector-builder geronimo-jmx-remoting geronimo-naming geronimo-naming-builder geronimo-test-ddbean (wtf is this for?) geronimo-deployment/ geronimo-deployment (rename to -core) ? geronimo-deploy-config geronimo-deploy-jsr88 geronimo-deploy-tool geronimo-hot-deploy geronimo-client geronimo-client-builder geronimo-j2ee/ geronimo-j2ee geronimo-j2ee-builder geronimo-j2ee-schema geronimo-web-builder plugins/ geronimo-activemq/ ge-activemq-rar (rename) geronimo-activemq-gbean geronimo-activemq-gbean-management geronimo-axis geronimo-axis-builder geronimo-derby geronimo-directory geronimo-tomcat geronimo-tomcat-builder geronimo-jetty geronimo-jetty-builder geronimo-mail geronimo-timer geronimo-webservices tools/ geronimo-upgrade geronimo-converter testsuite/ TODO, home for itest usage Anyways, I wanted to post what I am thinking. I think that we are really close to the point where we will want to implement this sort of split up. Comments? --jason
Re: Restructuring trunk, then next steps
Ya, this is one of the main reasons.We don't have to have geronimo-* in infront of everything, for example our activemq integration might be in:components/ activemq-component/This, plus the groupId makes it clear enough... but we should not call the module activemq. * * *Its sad and a little frustrating, that an email about structure ends up as some complains about naming conventions.:-(--jasonOn Sep 5, 2006, at 12:36 PM, Guillaume Nodet wrote:The problem with not keeping the geronimo- prefix is that all jars will end up as activemq-1.2.jar activation-1.2.jarIt will be highly confusing.The other solution is to break the directory name = artifactId rule, which is imho a bad idea.On 9/5/06, Matt Hogstrom [EMAIL PROTECTED] wrote: I'm assuming everything is not geronimo- ... that might be from the department of redundancy department.Jason Dillon wrote: So, I've mentioned a few times before that we should start thinking about how to split up modules in trunk into a few smaller chunks. I took a few minutes and took a crude stab at what that might look like. This is just an example of how it might work... I did not do any extensive research into dependencies... Basically, I split things up into 5 main trees: * framework - common stuff, not really the server, but supports the server, modules here should have minimal deps * system - the major components which make up the server's system (should be the bits to start up a server shell) * tools - bits that support the system * plugins - components which plugin to the system * testsuite - placeholder for modules which will be aded soon that use the itest plugin to perform integration tests I'm not sure if this is the best split, but it kinda comes closer to what I hope we can get to. Below is how the modules that exists fit into these sections. framework/ geronimo-testsupport (may need to be in other tree? so can include in all modules by default) geronimo-common geronimo-util geronimo-interceptor geronimo-activation geronimo-kernel system/ geronimo-management geronimo-security geronimo-security-builder geronimo-service-builder geronimo-core geronimo-system geronimo-transaction geronimo-connector geronimo-connector-builder geronimo-jmx-remoting geronimo-naming geronimo-naming-builder geronimo-test-ddbean (wtf is this for?) geronimo-deployment/ geronimo-deployment (rename to -core) ? geronimo-deploy-config geronimo-deploy-jsr88 geronimo-deploy-tool geronimo-hot-deploy geronimo-client geronimo-client-builder geronimo-j2ee/ geronimo-j2ee geronimo-j2ee-builder geronimo-j2ee-schema geronimo-web-builder plugins/ geronimo-activemq/ ge-activemq-rar (rename) geronimo-activemq-gbean geronimo-activemq-gbean-management geronimo-axis geronimo-axis-builder geronimo-derby geronimo-directory geronimo-tomcat geronimo-tomcat-builder geronimo-jetty geronimo-jetty-builder geronimo-mail geronimo-timer geronimo-webservices tools/ geronimo-upgrade geronimo-converter testsuite/ TODO, home for itest usage Anyways, I wanted to post what I am thinking. I think that we are really close to the point where we will want to implement this sort of split up. Comments? --jason-- Cheers,Guillaume Nodet
Re: Restructuring trunk, then next steps
On 9/5/06, Jason Dillon [EMAIL PROTECTED] wrote: I am sure that some of these names will change... But the directory name should be the same as the artifactId... so that its easy to see where the source for artifacts come from, and because some maven plugins that work on sets of modules make that assumption (like site plugin for example) when running. This is a best practice with Maven... and I don't recommend moving away from that. Before we already had things like console-jetty making a jar named webconsole-jetty-* and others too which only make it more difficult to tell where these things come from. I agree with this 100%. IMO, this is probably one of the biggest benefits that Maven provides - the ability to look at an artifact named foobar-baz-1.2.3.jar and you just know that it comes from the foobar-baz directory. This makes navigating the directory structure much easier. The last thing I want to see us do is bury everything about the way Geronimo is built in the buid tool configuration. This still happens with many, many projects (both closed and open source) that use Ant and it drives me insane. Why should I have to dig into an Ant build.xml file just to figure out how a particular artifact is produced!? I want the ability to see this at a glance. 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: Restructuring trunk, then next steps
Fine with me. The tree is still in need of reorganization even after those modules are gone. --jason On Sep 5, 2006, at 2:42 PM, Dain Sundstrom wrote: Please don't get mad at me, but I'd like to move a bit slower on more classification inside of the server module. I'd like to pull transaction and connector out to independently versioned modules and then see if the tree still feels crowded. -dain On Sep 5, 2006, at 2:27 PM, Jason Dillon wrote: I am sure that some of these names will change... But the directory name should be the same as the artifactId... so that its easy to see where the source for artifacts come from, and because some maven plugins that work on sets of modules make that assumption (like site plugin for example) when running. This is a best practice with Maven... and I don't recommend moving away from that. Before we already had things like console-jetty making a jar named webconsole-jetty-* and others too which only make it more difficult to tell where these things come from. --jason On Sep 5, 2006, at 12:25 PM, Matt Hogstrom wrote: I'm assuming everything is not geronimo- ... that might be from the department of redundancy department. Jason Dillon wrote: So, I've mentioned a few times before that we should start thinking about how to split up modules in trunk into a few smaller chunks. I took a few minutes and took a crude stab at what that might look like. This is just an example of how it might work... I did not do any extensive research into dependencies... Basically, I split things up into 5 main trees: * framework - common stuff, not really the server, but supports the server, modules here should have minimal deps * system - the major components which make up the server's system (should be the bits to start up a server shell) * tools - bits that support the system * plugins - components which plugin to the system * testsuite - placeholder for modules which will be aded soon that use the itest plugin to perform integration tests I'm not sure if this is the best split, but it kinda comes closer to what I hope we can get to. Below is how the modules that exists fit into these sections. framework/ geronimo-testsupport (may need to be in other tree? so can include in all modules by default) geronimo-common geronimo-util geronimo-interceptor geronimo-activation geronimo-kernel system/ geronimo-management geronimo-security geronimo-security-builder geronimo-service-builder geronimo-core geronimo-system geronimo-transaction geronimo-connector geronimo-connector-builder geronimo-jmx-remoting geronimo-naming geronimo-naming-builder geronimo-test-ddbean (wtf is this for?) geronimo-deployment/ geronimo-deployment (rename to -core) ? geronimo-deploy-config geronimo-deploy-jsr88 geronimo-deploy-tool geronimo-hot-deploy geronimo-client geronimo-client-builder geronimo-j2ee/ geronimo-j2ee geronimo-j2ee-builder geronimo-j2ee-schema geronimo-web-builder plugins/ geronimo-activemq/ ge-activemq-rar (rename) geronimo-activemq-gbean geronimo-activemq-gbean-management geronimo-axis geronimo-axis-builder geronimo-derby geronimo-directory geronimo-tomcat geronimo-tomcat-builder geronimo-jetty geronimo-jetty-builder geronimo-mail geronimo-timer geronimo-webservices tools/ geronimo-upgrade geronimo-converter testsuite/ TODO, home for itest usage Anyways, I wanted to post what I am thinking. I think that we are really close to the point where we will want to implement this sort of split up. Comments? --jason
[jira] Created: (AMQ-912) ActiveMQ support for SSL authentication and authorization
ActiveMQ support for SSL authentication and authorization - Key: AMQ-912 URL: https://issues.apache.org/activemq/browse/AMQ-912 Project: ActiveMQ Issue Type: Improvement Components: Test Cases, Transport Reporter: Sepand Mavandadi Attachments: ssl_certifiacte_auth_patch.txt This patch adds new Transports, Brokers, and Plugins needed for authentication and authorization based on SSL certificates. It also adds a few unit tests for the mentioned classes. The new (or heavily modified) SslTransport, SslTransportServer, and SslTransportFactory classes allow for access to the underlying socket's need and want client auth settings. If a certificate is found, it is set as the transportContext of the created connection. The JaasCertificateAuthenticationBroker uses the new CertificateLoginModule to authenticate certificates (this class is abstract to allow for different backends for certificate authentication, a concrete class is TextFileCertificateLoginModule). JaasCertificateAuthenticationBroker also sets the security context's user name to that provided for the certificate by the login module. This allows for authorization using the existing authorization 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
SSL authentication/authorization patch
Hey guys, The patch is done. It's here: https://issues.apache.org/activemq/browse/AMQ-912 Hope you like it. It would be really great if you could give an estimate of when you will decide if it goes in or not (although I doubt you can =) ). Regards, Sepand
Re: Restructuring trunk, then next steps
BTW I do think we should rename the dirs to match the maven standard geronimo-foo standard. -dain On Sep 5, 2006, at 2:49 PM, Jason Dillon wrote: Fine with me. The tree is still in need of reorganization even after those modules are gone. --jason On Sep 5, 2006, at 2:42 PM, Dain Sundstrom wrote: Please don't get mad at me, but I'd like to move a bit slower on more classification inside of the server module. I'd like to pull transaction and connector out to independently versioned modules and then see if the tree still feels crowded. -dain On Sep 5, 2006, at 2:27 PM, Jason Dillon wrote: I am sure that some of these names will change... But the directory name should be the same as the artifactId... so that its easy to see where the source for artifacts come from, and because some maven plugins that work on sets of modules make that assumption (like site plugin for example) when running. This is a best practice with Maven... and I don't recommend moving away from that. Before we already had things like console-jetty making a jar named webconsole-jetty-* and others too which only make it more difficult to tell where these things come from. --jason On Sep 5, 2006, at 12:25 PM, Matt Hogstrom wrote: I'm assuming everything is not geronimo- ... that might be from the department of redundancy department. Jason Dillon wrote: So, I've mentioned a few times before that we should start thinking about how to split up modules in trunk into a few smaller chunks. I took a few minutes and took a crude stab at what that might look like. This is just an example of how it might work... I did not do any extensive research into dependencies... Basically, I split things up into 5 main trees: * framework - common stuff, not really the server, but supports the server, modules here should have minimal deps * system - the major components which make up the server's system (should be the bits to start up a server shell) * tools - bits that support the system * plugins - components which plugin to the system * testsuite - placeholder for modules which will be aded soon that use the itest plugin to perform integration tests I'm not sure if this is the best split, but it kinda comes closer to what I hope we can get to. Below is how the modules that exists fit into these sections. framework/ geronimo-testsupport (may need to be in other tree? so can include in all modules by default) geronimo-common geronimo-util geronimo-interceptor geronimo-activation geronimo-kernel system/ geronimo-management geronimo-security geronimo-security-builder geronimo-service-builder geronimo-core geronimo-system geronimo-transaction geronimo-connector geronimo-connector-builder geronimo-jmx-remoting geronimo-naming geronimo-naming-builder geronimo-test-ddbean (wtf is this for?) geronimo-deployment/ geronimo-deployment (rename to -core) ? geronimo-deploy-config geronimo-deploy-jsr88 geronimo-deploy-tool geronimo-hot-deploy geronimo-client geronimo-client-builder geronimo-j2ee/ geronimo-j2ee geronimo-j2ee-builder geronimo-j2ee-schema geronimo-web-builder plugins/ geronimo-activemq/ ge-activemq-rar (rename) geronimo-activemq-gbean geronimo-activemq-gbean-management geronimo-axis geronimo-axis-builder geronimo-derby geronimo-directory geronimo-tomcat geronimo-tomcat-builder geronimo-jetty geronimo-jetty-builder geronimo-mail geronimo-timer geronimo-webservices tools/ geronimo-upgrade geronimo-converter testsuite/ TODO, home for itest usage Anyways, I wanted to post what I am thinking. I think that we are really close to the point where we will want to implement this sort of split up. Comments? --jason
Re: Changing the name of the ServiceMix project at the Codehaus
+1 Regards, Alan Dain Sundstrom wrote: ServiceMixins -dain On Sep 1, 2006, at 8:13 AM, Bruce Snyder wrote: ServiceMix was moved from the Codehaus to the ASF late in 2005. This involved leaving behind some modules that are not compatible with the Apache License so we decided to just leave the project that housed ServiceMix at the Codehaus in place to continue to house these modules. However, it has become rather confusing for people to understand the distinction between these two project spaces (one at the ASF and one at the Codehaus) and it's high time that we decided to change the name of the ServiceMix project that remains at the Codehaus. Therefore, I propose that we select a new name for this project. If others are interested let's begin to discuss names. 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: Can you set maven to build without updating plugins, etc without heavy modifications to poms?
In case anyone is interested, you can do a mvn -Dmaven.repo.local=local_repo_path [compile/install/etc.] then do a mvn -o -Dmaven.repo.local=local_repo_path [compile/install/etc.] - Sepand On 9/5/06, Sepand M [EMAIL PROTECTED] wrote: hmm. Yeah. Definately a good starting point though. Thanks On 9/5/06, Hiram Chirino [EMAIL PROTECTED] wrote: something like: mvn install:install-file -DgroupId=org.apache.directory.server -DartifactId=apacheds-protocol-kerberos -Dversion=1.0-RC3 -Dpackaging=jar -Dfile=/path/to/file and you would have to do this for each dependency.. so I'm not sure how good this idea really is. On 9/5/06, Sepand M [EMAIL PROTECTED] wrote: That would be great actually, do you know what that command is? And where does it install the artifacts? (I need everything to be in one neat directory) On 9/5/06, Hiram Chirino [EMAIL PROTECTED] wrote: you can build offline with -o. It just builds off you local repo. maven also has a command to manually install artifacts to the local repo if that's what your looking for. On 9/5/06, Sepand M [EMAIL PROTECTED] wrote: Hi guys, I need to get activemq to build without maven searching for updates, etc. The only way I know of doing that right now is to manually edit all pom files and set static versions. But that would require a lot of modifications to the poms, which I would rather avoid. Does anyone know a better way? I know this could be asked in the maven boards, but I'd rather get info from people familiar with the specifics of activemq. Regards, Sepand -- Regards, Hiram Blog: http://hiramchirino.com -- Regards, Hiram Blog: http://hiramchirino.com
[jira] Created: (AMQ-913) Wireformat negociation needs to negociate to to the minimum version supported by both sides.
Wireformat negociation needs to negociate to to the minimum version supported by both sides. Key: AMQ-913 URL: https://issues.apache.org/activemq/browse/AMQ-913 Project: ActiveMQ Issue Type: Bug Components: Transport Affects Versions: 4.0 Reporter: Hiram Chirino Assigned To: Hiram Chirino Fix For: 4.1, 4.0.2 Right now it's negociating to the maximum supported by both sides. This means that old version will try to load a newer version of the wireformat that it does not support! -- 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: (GERONIMO-2364) Update geronimo to use ActiveMQ 4.1.x
[ http://issues.apache.org/jira/browse/GERONIMO-2364?page=comments#action_12432698 ] Dain Sundstrom commented on GERONIMO-2364: -- +1 Looks good to me Update geronimo to use ActiveMQ 4.1.x - Key: GERONIMO-2364 URL: http://issues.apache.org/jira/browse/GERONIMO-2364 Project: Geronimo Issue Type: RTC Security Level: public(Regular issues) Components: ActiveMQ Reporter: Hiram Chirino Assigned To: Hiram Chirino Fix For: 1.2 Attachments: GERONIMO-2364.patch -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (GERONIMO-2354) Replace concurrent with backport-concurrent-util
[ http://issues.apache.org/jira/browse/GERONIMO-2354?page=comments#action_12432699 ] Dain Sundstrom commented on GERONIMO-2354: -- +1 looks good to me Replace concurrent with backport-concurrent-util Key: GERONIMO-2354 URL: http://issues.apache.org/jira/browse/GERONIMO-2354 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Affects Versions: 1.2 Reporter: Jason Dillon Attachments: GERONIMO-2354-openejb2.diff, GERONIMO-2354-openejb2.diff, GERONIMO-2354.diff, GERONIMO-2354.diff Replace usage of concurrent classes with backport-concurrent-util. Preparation for using java.util.concurrent in JDK 1.5, and reduce the need for 2 sets of concurrent classes on the boot classloader. Sill need to include concurrent, as activeio and openejb still have some dependencies upon it... but this brings us a step closer to not needing both. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (AMQ-913) Wireformat negociation needs to negociate to to the minimum version supported by both sides.
[ https://issues.apache.org/activemq/browse/AMQ-913?page=all ] Hiram Chirino resolved AMQ-913. --- Resolution: Fixed Fix applied in 4.0 branch rev 440543 Fix applied in trunk rev 440541 Wireformat negociation needs to negociate to to the minimum version supported by both sides. Key: AMQ-913 URL: https://issues.apache.org/activemq/browse/AMQ-913 Project: ActiveMQ Issue Type: Bug Components: Transport Affects Versions: 4.0 Reporter: Hiram Chirino Assigned To: Hiram Chirino Fix For: 4.1, 4.0.2 Right now it's negociating to the maximum supported by both sides. This means that old version will try to load a newer version of the wireformat that it does not support! -- 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: Re: Returning to Commit-Then-Review?
I will support anything that does not leave patches to fester and still provides any required pre-commit oversight. I would really like to see a CTR-like policy that puts trust back into the community for example, I trust Hirams activemq patch but my concurrent patch... well I want others to ack it first, as it his areas of the server which are not as familiar to me. It seems to me that David's proposal fits into this... Can we please make an effort to agree on a policy? And once agreed upon, have the PMC officially announce it? I believe this is critical for our community to move forward. --jason On 8/25/06, David Blevins [EMAIL PROTECTED] wrote: So anyone have any thoughts on this? I'll assume there's no support unless I hear otherwise. -David On Aug 23, 2006, at 1:14 PM, David Blevins wrote: On Aug 22, 2006, at 6:56 PM, David Blevins wrote: I'd be more inclined to talk about what we want to apply it to and how. More thoughts on the where and how topic. So far my thoughts on how; review to your satisfaction and +1, 72 hour cut off. As far as where I'm inclined to say at your discretion where the following are encouraged: - Significant new functionality - Significant changes - Patches from Contributors - Borderline fixes to a stable branch Whether or not it merits RTC would be at your discretion. It is to your advantage in these situations because: - Significant new functionality and Significant changes: It's a Get out of jail free card. Having more people understand your code keeps you from spending all day on the user list. You do support your code on the user list, right? - Patches from Contributors: Getting three votes for your patches is not a bad way to, in time, get your three votes to be a committer. Let's be clear, someone who commits all your patches with no review from others on the project isn't doing you any favors. It's in your interest to push to get your votes on every patch. - Borderline 'fixes' to a stable branch: It's a given you will think everything you want to put in a stable branch is important. But, is it a fix or is it a new feature? If you think others may disagree, you may want to put it up for review or you may find yourself running the TCK all alone with no help. Those are the advantages you stand to gain should you choose to use RTC for any of the above situations. RTC is not the only way to get the above benefits, so it is at your discretion whether or not your situation merits it. My pragmatic take on RTC for the moment. -David
Re: Move STAUS file?
+1 But lets not get into the habit of adding files there, this one is fine though IMO. --jason On Sep 5, 2006, at 1:40 PM, Dain Sundstrom wrote: Since the last svn reorg our status file is now located at: http://svn.apache.org/repos/asf/geronimo/server/trunk/STATUS I propose we move it to: http://svn.apache.org/repos/asf/geronimo/STATUS So it is easy for anyone to find. -dain
Re: Release Early, Release Often
I think that trunk might be good enough for an alpha or beta pre- release of 1.2. I would love to see use release early and often... --jason On Sep 5, 2006, at 1:40 PM, Dain Sundstrom wrote: According to our STATUS file, our last feature release (1.1) was on 2006-06-26 which is about 2.5 months ago. I'm not sure exactly what we have in trunk right now, but I'd guess we most likely have enough to do a release right now. I'm going to spend a few hours today browsing the JIRAs and SVN logs and compile a list of the features we have in trunk right now. Anyways, I'll let you know what I find and we can figure out what we want to do. Thanks, -dain
[jira] Commented: (AMQ-911) Transient connection failure with Failover transport can cause InvalidClientIDException
[ https://issues.apache.org/activemq/browse/AMQ-911?page=comments#action_36910 ] Hiram Chirino commented on AMQ-911: --- fixed in 4.0 branch rev 440548 Transient connection failure with Failover transport can cause InvalidClientIDException --- Key: AMQ-911 URL: https://issues.apache.org/activemq/browse/AMQ-911 Project: ActiveMQ Issue Type: Bug Affects Versions: 4.0 Reporter: Hiram Chirino Assigned To: Hiram Chirino Fix For: 4.1, 4.0.2 It shows up as errors on the broker log: Error occured while processing sync command: javax.jms.InvalidClientIDException: Broker: localhost - Client: ID:hchirino-mac.local-51624-1157486953862-2:0 already connected -- 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
No need for m2 central mirror
With the new central repo off of ibiblio, you no longer need a mirror in settings.xml. I recommend that everyone remove the mirror setting and use the central mirror... and report any problems. --jason
Re: svn commit: r437291 - in /geronimo/server/trunk: bootstrap bootstrap.bat bootstrap.xml
I'm in favor of adding and advanced section to the docs ( on http:// cwiki.apache.org/GMOxDEV/building-apache-geronimo-with-maven-2.html ) --jason On Sep 5, 2006, at 7:34 AM, Paul McMahan wrote: I am in favor of keeping bootstrap around for automating the several steps it takes to check out and build the server into one command. I agree with Anita that there should be instructions for advanced users on the wiki for building without bootstrap -- I have already found her advice very helpful for working around some problems. But for the default build environment (i.e. what a new user sees when checking out from SVN and then reads about in BUILDING.txt) I think we should stay the course for resolving the problems Jason listed before removing bootstrap. My rationale is that fewer manual steps means fewer chances for user error. Best wishes, Paul On 9/1/06, Jason Dillon [EMAIL PROTECTED] wrote: I give up trying to explain... do as you please. --jason On Sep 1, 2006, at 12:48 PM, anita kulshreshtha wrote: inline.. --- Jason Dillon [EMAIL PROTECTED] wrote: On Sep 1, 2006, at 7:42 AM, anita kulshreshtha wrote: Anita, why do you always bring this up when there is talk about bootstrap? Because when people are using bootstrap, it is not very obvious what is going on. It is much simpler to give the 3 URLs and a simple build command mvn. If there are build/test failures, they can look at the default profile, and see what they are building. If for example the openejb2 test failed, they could simply do cd openejb2 and mvn -Dmaven.test.skip=true After this they can continue the build from the next step, i.e. configs, etc. I have explained over and over and over again that the point of bootstrap is not to facilitate a normal build but to ensure People only care about the normal build. that the build works from a known state (ie. clean, fresh specs, from openejb2). Your method does not provide this level of assurance. I You have not given any concrete example/scenario in which my build method does not work. created this script because people had problems checking things out in the right place, Is this the main reason? cleaning the right bits and running the right mvn Could you be more precise? commands to perform the build steps that were needed to help ensure that most everyone (except for some folks with whacky windows machines) can make a reliable build near 100% of the time. I'm really kinda getting tired of having to re-explain this. To build geronimo with openejb2 add openejb2 to the default profile in the top level pom.xml as shown below: modules modulemodules/module modulemaven-plugins/module moduleapplications/module moduleopenejb2/module --- moduleconfigs/module moduleassemblies/module /modules and No, no, no, no... no... no. We had already talked about this weeks ago. Its fine that you want to build in this manner, but I am firmly against putting a module into the main build that is for a directory that the user must checkout by hand. I do not see any problems with that. Let us give people a choice by putting these instructions on the wiki and they can decide if they want to use bootstrap. BTW, it is in line with your philosophy about builds: http://www.nabble.com/Re%3A-Unable-to-build-using-m2-p5074204.html cd .. mvn After the first time you can build from any directory. Please give it a try and provide feedback, so that we can put bootstrap to rest. I don't have any problems with you, or anyone else making changes to include openejb2 in their local workspace (I'd recommend putting that into a profiles.xml next to the pom.xml though). But I think that your method is unacceptable for the project default. Bootstrap is there for a reason... I am not crazy, I actually know what I am doing. At this point I believe that bootstrap is important and needs to remain, until the items I previously listed are resolved. I am not asking you to remove the bootstrap, I want to give our users a choice. Thanks Anita --jason __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
[PROPOSAL] Modified RTC
Before getting to the proposal I'd like to acknowledge the efforts of the community to adjust to RTC. Blevins and Dillon helped to streamline the system with some changes to JIRA (I think Alan had a hand in that as well) that improved the process and I think most of the folks in the community reviewed patches and made a valiant attempt to work with the changes to the process. I think overall we did improve communication but we also experienced some slowing (heck, a lot of slowing) in innovation. As with all things there was some good and some things to learn from. Based on that here is a proposal for a modified RTC that I think will help to address a number of issues and capture the good. *** Begin Proposal *** Geronimo Development Process Geronimo follows a model similar to Review Then Commit (RTC). Patches for new function are provided by developers for review and comment by their peers. Feedback is conducted through JIRA comments. The goal of this interaction is to solicit suggestions from the community and incorporate their feedback as appropriate. In order for a patch to be accepted it requires the following: * Needs to be reviewed by committers on the project. Others may comment but their comments are not binding. The review may, but does not have to, include application and testing. The goal of the review is to understand the technical attributes of the change as well as the assess other impacts to the project as a whole. * 3 +1 votes from committers on the project (1 of these committers needs to be a member of the PMC) with no outstanding -1 votes. * Any -1 votes need to be accompanied by a reason and a mutually agreed upon solution to the issue raised. * If the issues can't be resolved then the PMC can be called upon to settle the dispute and make a recommendation. * Issues are generally of a technical nature. However, issues may include other items like usability, project cohesiveness or other issues that impact the project as a whole. The goal of these guidelines is to facilitate timely communication as well as the fostering of ideas and collaboration as well as innovation. *** End Proposal *** It is not my intention to make a list of rules to follow but rather to capture the best of RTC in terms of communication as well as provide binding influence over the technical direction of the project for both committers as well as PMC members and not create a hierarchical system. In the case of dispute or problem resolution the responsibility falls to the PMC for resolution. Please provide your input for this proposal. I'd like to bring this to the community for a vote this week.
