Re: Anonymous read and authenticated write access to a destination
I think Kelly was referring to the use of the character in XML. So you could try gt; to encode nicely for XML. On 7/31/06, Asankha C. Perera [EMAIL PROTECTED] wrote: Hi Kelly I just guessed using * and anonymous but they are of no use.. I was not able to locate in documentation how this could be achieved. thanks asankha Kelly Campbell wrote: Is it possible your queue name is causing the problem because it's an XML special character? What kind of error are you getting or is it just not probiding this access control you expect? On 7/28/06, asankha [EMAIL PROTECTED] wrote: Hi I want to allow unauthenticated connections to read from a destination, and allow writes only to authenticated connections. e.g. *anyone* can read from a queue, but only a member of the admin group can write.. How can I specify an AuthorizationEntry for this? The following entries does not work authorizationEntry queue= read=* write=admins admin=admins/ authorizationEntry queue= read=anonymous write=admins admin=admins/ thanks asankha -- View this message in context: http://www.nabble.com/Anonymous-read-and-authenticated-write-access-to-a-destination-tf2013985.html#a5535072 Sent from the ActiveMQ - Dev forum at Nabble.com. -- James --- http://radio.weblogs.com/0112098/
Re: Continuum Build Failure
BTW it looks like a new error has crept in... http://ci.gbuild.org/continuum/servlet/continuum/target/ProjectBuild.vm?view=ProjectBuildbuildId=5623id=4 Error: JAVA_HOME is not defined correctly. We cannot execute java On 7/27/06, Kevan Miller [EMAIL PROTECTED] wrote: On Jul 27, 2006, at 12:52 PM, James Strachan wrote: On 7/27/06, Kevan Miller [EMAIL PROTECTED] wrote: The ActiveMQ Core Build on GBuild's Continuum (http://ci.gbuild.org/ continuum/target/) has been failing since July 7th. See http:// ci.gbuild.org/continuum/servlet/continuum/target/ProjectBuild.vm? view=ProjectBuildbuildId=5212id=4 for the specific failures. FWIW am not sure why the failures are not making the SCM list. Good point. I'd wondered about that... I don't think any email notifications are getting out for any project. I don't recall seeing any Geronimo notifications for a while. Must be some configuration problem. Are these tests failing for everyone? Or is there an environmental problem on GBuild? They are not failing for me at least - it could be environmental. After some grepping I've found the tests that are failing (wish CI would tell you that easily :) org.apache.activemq.usecases.MultiBrokersMultiClientsTest org.apache.activemq.usecases.TwoMulticastDiscoveryBrokerTopicSendRecei veTest org.apache.activemq.transport.TopicClusterTest It could be something to do with multicast support as all these tests are using multicast. -- James --- http://radio.weblogs.com/0112098/ Probably right. Any hints on likely causes of multicast problems? In case it's useful, here are the Surefire reports: --- Test set: org.apache.activemq.usecases.MultiBrokersMultiClientsTest --- Tests run: 2, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 42.211 sec FAILURE! testTopicAllConnected (org.apache.activemq.usecases.MultiBrokersMultiClientsTest) Time elapsed: 26.172 sec FAILURE! junit.framework.AssertionFailedError: expected:60 but was:30 at junit.framework.Assert.fail(Assert.java:47) at junit.framework.Assert.failNotEquals(Assert.java:282) at junit.framework.Assert.assertEquals(Assert.java:64) at junit.framework.Assert.assertEquals(Assert.java:201) at junit.framework.Assert.assertEquals(Assert.java:207) at org.apache.activemq.usecases.MultiBrokersMultiClientsTest.testTopicAllCo nnected(MultiBrokersMultiClientsTest.java:68) --- Test set: org.apache.activemq.usecases.TwoMulticastDiscoveryBrokerTopicSendReceive Test --- Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 70.757 sec FAILURE! testSendReceive (org.apache.activemq.usecases.TwoMulticastDiscoveryBrokerTopicSendReceiv eTest) Time elapsed: 70.729 sec FAIL\URE! junit.framework.AssertionFailedError: Not enough messages received expected:100 but was:0 at junit.framework.Assert.fail(Assert.java:47) at junit.framework.Assert.failNotEquals(Assert.java:282) at junit.framework.Assert.assertEquals(Assert.java:64) at junit.framework.Assert.assertEquals(Assert.java:201) at org.apache.activemq.test.JmsSendReceiveTestSupport.assertMessagesReceive dAreValid(JmsSendReceiveTestSupport.java:169) at org.apache.activemq.test.JmsSendReceiveTestSupport.assertMessagesAreRece ived(JmsSendReceiveTestSupport.java:149) at org.apache.activemq.test.JmsSendReceiveTestSupport.testSendReceive (JmsSendReceiveTestSupport.java:123) ... --- Test set: org.apache.activemq.transport.TopicClusterTest --- Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 33.752 sec FAILURE! testSendReceive(org.apache.activemq.transport.TopicClusterTest) Time elapsed: 33.723 sec FAILURE! junit.framework.AssertionFailedError: Expected message count not correct expected:450 but was:150 at junit.framework.Assert.fail(Assert.java:47) at junit.framework.Assert.failNotEquals(Assert.java:282) at junit.framework.Assert.assertEquals(Assert.java:64) at junit.framework.Assert.assertEquals(Assert.java:201) at org.apache.activemq.transport.TopicClusterTest.testSendReceive (TopicClusterTest.java:176) -- James --- http://radio.weblogs.com/0112098/
[jira] Resolved: (AMQ-842) Amazon's contributed C++ Openwire Client
[ https://issues.apache.org/activemq/browse/AMQ-842?page=all ] james strachan resolved AMQ-842. Resolution: Fixed Patch applied, many thanks. Until we figure out what to do with our various C++ code bases I've added it into an amazon directory; we can then hopefully consolidate our C++ codebases. Amazon's contributed C++ Openwire Client Key: AMQ-842 URL: https://issues.apache.org/activemq/browse/AMQ-842 Project: ActiveMQ Issue Type: Improvement Reporter: Andrew Lusk Attachments: amq_openwirecpp-0.1.2.tar.gz In the spirit of OSCON, here is the latest tarball of our C++ Openwire client. I believe that all of the source headers are in order. (at last!) High-level documentation: http://www.activemq.org/site/openwire-cpp-client.html Let me know what I can do to expedite this being committed. Thanks for your patience guys. In order for this to be committed, we need the following at the bottom of the project NOTICE file: Portions of this software copyright 2006 Amazon.com, inc. -- 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
Amazon's C++ client imported into SVN
Amazon have donated a C++ client; its been written for some time but its just recently got through the lawyers etc :) http://issues.apache.org/activemq/browse/AMQ-842 I've just imported it temporarily here... https://svn.apache.org/repos/asf/incubator/activemq/trunk/amazon/ hopefully we can figure out some rationalisation of our various C++ code bases going forward. -- James --- http://radio.weblogs.com/0112098/
Re: ActiveMQ OpenWire .NET Example
James, Been doing some more testing using the 4.1 snap shot with the following settings and a large heap size: memoryManager usageManager id=memory-manager limitMB=400/ /memoryManager However, we still can't seem to push files much larger than about 10mb through the queues! Smaller files seem to work OK. Do you have any more suggesdtions? Carl -- View this message in context: http://www.nabble.com/ActiveMQ-OpenWire-.NET-Example-tf2014936.html#a5573569 Sent from the ActiveMQ - Dev forum at Nabble.com.
Re: Amazon's C++ client imported into SVN
BTW, I was thinking that since we don't actually do releases of all the c/c++/#net etc. etc. at the same time that we do releases of the main broker, perhaps we should move all those bit's to a different branch of development. Folks could get confused if they get a source tar ball of activemq 4.1 and it contains all that source code. They might think that those bit's are part of the 4.1 release too. Regards, Hiram On 7/31/06, James Strachan [EMAIL PROTECTED] wrote: Amazon have donated a C++ client; its been written for some time but its just recently got through the lawyers etc :) http://issues.apache.org/activemq/browse/AMQ-842 I've just imported it temporarily here... https://svn.apache.org/repos/asf/incubator/activemq/trunk/amazon/ hopefully we can figure out some rationalisation of our various C++ code bases going forward. -- James --- http://radio.weblogs.com/0112098/ -- Regards, Hiram Blog: http://hiramchirino.com
[jira] Commented: (SM-504) Beanflow: Multiple execution of beanflow steps
[
https://issues.apache.org/activemq/browse/SM-504?page=comments#action_36665 ]
Andreas Held commented on SM-504:
-
To add some more information:
The first time, the steps are being executed from Workflow.java:102, I believe
that this is the problem, as this calls DefaultState.set and
SynchronousNotifier.run. This then exexcutes all the listeners and calls
Workflow.run again. o be honest, I do not quite understand line
DefaultState.java:73. What is the meaning fo the notifiers?
Regards
Andreas.
Beanflow: Multiple execution of beanflow steps
--
Key: SM-504
URL: https://issues.apache.org/activemq/browse/SM-504
Project: ServiceMix
Issue Type: Bug
Affects Versions: incubation
Environment: Windows2K, running ServiceMix under JBoss4.0.3SP1
Reporter: Andreas Held
Assigned To: james strachan
Consider the following simple Beanflow example:
public class TestWorkflow extends WorkflowString {
private static Logger log =
Logger.getLogger(TestWorkflow.class.getName());
public static int count = 0;
public TestWorkflow() {
super(startStep);
}
public String startStep() {
count += 1;
log.info(Workflow: Validation);
// next step
return persistenceStep;
}
public String persistenceStep() {
count += 1;
log.info(Workflow: Persistence);
// next step
return transferStep;
}
public String transferStep() {
count += 1;
log.info(Workflow: Transfer);
// next step
return stop;
}
}
If I write a JUnit test case with assertEquals(workflow.count, 3); then
this will fail, as count has a value of 5. Looking at the log shows the
following output:
08:19:26,335 DEBUG [org.apache.servicemix.beanflow.Workflow.run()] About
to execute step: startStep
08:19:26,351 INFO [ch.bbp.igt.comm.ServiceMix.TestWorkflow.startStep()]
FileActWorkflow: Validation
08:19:26,351 DEBUG [org.apache.servicemix.beanflow.Workflow.run()] About
to execute step: persistenceStep
08:19:26,351 INFO
[ch.bbp.igt.comm.ServiceMix.TestWorkflow.persistenceStep()]
FileActWorkflow: Persistence
08:19:26,351 DEBUG [org.apache.servicemix.beanflow.Workflow.run()] About
to execute step: persistenceStep
08:19:26,351 INFO
[ch.bbp.igt.comm.ServiceMix.TestWorkflow.persistenceStep()]
FileActWorkflow: Persistence
08:19:26,351 DEBUG [org.apache.servicemix.beanflow.Workflow.run()] About
to execute step: transferStep
08:19:26,351 INFO
[ch.bbp.igt.comm.ServiceMix.TestWorkflow.transferStep()]
FileActWorkflow: Transfer
08:19:26,351 DEBUG [org.apache.servicemix.beanflow.Workflow.run()] About
to execute step: transferStep
08:19:26,351 INFO
[ch.bbp.igt.comm.ServiceMix.TestWorkflow.transferStep()]
FileActWorkflow: Transfer
08:19:26,351 DEBUG [org.apache.servicemix.beanflow.Workflow.run()] About
to execute step: stop
08:19:26,367 DEBUG [org.apache.servicemix.beanflow.Workflow.run()] About
to execute step: stop
This means, all steps but the start step are executed twice! This
corresponds to count being 5 in the end!
JUnit Testcase :
public class WorkflowTest extends TestCase {
public WorkflowTest(String s) {
super(s);
}
protected void setUp() {
}
protected void tearDown() {
}
public void testTest() throws Exception {
TestWorkflow workflow = new TestWorkflow();
workflow.start();
Thread.sleep(2000);
assertEquals(3, workflow.count);
}
public static Test suite() {
TestSuite suite = new TestSuite();
suite.addTest(new WorkflowTest(testTest));
return suite;
}
}
--
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: BAM Component
Thanks James, The positioning is the most important thing... I completely agree with you. And specially when some of the utility pieces are already there in SM and the concept of BAM in my opinion fits well in the ESB Space. Let's hope users will find it worth while... Best regards Soumadeep - Original Message - From: James Strachan [EMAIL PROTECTED] To: servicemix-dev@geronimo.apache.org Sent: Monday, July 31, 2006 3:35 PM Subject: Re: BAM Component Interesting stuff. I've pondered before on whether we should create a kind of 'Event-Condition-Action' (ECA) type component where we can register conditions (typically XPath predicates) on 'events' (or maybe endpoints is a more JBI term to use) and fire arbitrary actions when they are matched. In terms of low level implementation we can kinda do similar things today such as via the xpath router or drools component - but I'm thinking it would make lots of sense to provide this 'high level concept' to an end user - such as the XML example given below. I think the ECA approach can make things simpler for users to understand. Under the ECA approach I'm sure we could plugin the various capabilities we already have in ServiceMix such as the pluggable Expressions (XPath, Groovy etc). http://incubator.apache.org/servicemix/maven/servicemix-core/apidocs/org/apache/servicemix/expression/package-summary.html along with reusing many of the existing components as the actions etc. Incidentally the ECA approach lends itself nicely to great IDE tooling :) On 7/31/06, Guillaume Nodet [EMAIL PROTECTED] wrote: Great, thx a lot ! CCing servicemix-dev, as I think this is the place where this discussion should take place. Do you have any plan / ideas of future features for this component ? Currently, it seems this that the component is a router with actions. How will it differ from existing content based routers (xpath router, drools component) ? Another point I am wondering about, is the fact that the component embeds the email code inside an action: i think it would be better to reuse the existing components for that, else the BAM component would end up lots of BCs code internally (what about jms, jabber, etc...). On 7/31/06, Soumadeep-Infravio [EMAIL PROTECTED] wrote: Hi Guillaume/All, We feel that a Business Activity Monitoring Component would be a good addition to ServiceMix's existing samples. We have worked on a prototype for such a component and would like to contribute it. We have phased it out and depending on the feedback we will add other features as required. Please send us your feedback... Best regards Soumadeep Details of the component == Phase 1 This is a Business Activity Monitoring Component which would work only for Web services message payload in phase 1. An XPath expression could be provided in a config file which will be used to evaluate the incoming message. Depending on the evaluation result it will allow one or more actions to be taken. These actions again could be made available in a config files as below. Config file: === SM-WS-BAM Service url=http://www.xmethod.com/getVersion Rule name=sendEmailWhenGetQuoteInvoked expression value/Envelope/Body/GetQuote Action name=emailer/ Action name=.../ /Rule Rule name=.../ /Service /SM-WS-BAM Actions Action name=emailer Description/ Adaptor name=org.apache.sm.Emailer smtp-host name=mail.webmail.org from address=[EMAIL PROTECTED] to [EMAIL PROTECTED];[EMAIL PROTECTED] message value=There is a new quotation coming your way!! /Adaptor /Action /Actions Flow (inside the BAM component) === note: The usual MEP will be followed to pass the payload to the next component in line. 1) Fetch the Source from the Normalized Message 2) Fetch the rule to evaluate depending on the endpoint-request URL 3) Check for condition and get the evaluation result (using java1.5xpath's evaluate method) 4) Get the adaptor to invoke and invoke it. (Adaptor instances will be cached ) - from the action definition. Phase 2 The component would be extended to monitor any payload. This will be achieved using appropriate marshalers, which will convert the payload to xml. The marshaler to use could be indicated as a property value in the MessageExchange. The rest will be per phase 1. Possible use: == Servicemix 3.0 currently is distributed with several samples, one of them being the http-binding, which internally uses a saaj binding to redirect the message to a soap endpoint. The BAM component could be used in-between which would enable the user to monitor the payload and take action. -- Cheers, Guillaume Nodet -- James --- http://radio.weblogs.com/0112098/
Re: servicemix web service
You can take a look at the soap-binding example. It exposes a service on the JBI bus as a web service accessible through http+soap. The same thing can be applied to a service which would be an xslt transformation engine. If you want to describe your service using a wsdl, you will need to write it and deploy it on the servicemix-http component. See http://servicemix.goopen.org/site/servicemix-http.html Cheers, Guillaume Nodet On 7/31/06, emicalc [EMAIL PROTECTED] wrote: thank you, but where I can find other information on this? Are there some examples on wsdl file necessary to publish a component like web service? -- View this message in context: http://www.nabble.com/servicemix---web-service-tf2009607.html#a5575262 Sent from the ServiceMix - Dev forum at Nabble.com. -- Cheers, Guillaume Nodet
Re: BAM Component
The URI configuration mechanism does rock - I agree with Guillaume, it'd be a very useful way to configure an ECA / BAM configuration. On 7/31/06, Guillaume Nodet [EMAIL PROTECTED] wrote: On 7/31/06, Soumadeep-Infravio [EMAIL PROTECTED] wrote: I agree... but in a content based routing too the end result is a path to an application or service etc... though the technology used could be the same but from a BAM perspective the utility factor is effectively greater... Agreed. And be sure that I do not underestimate the need for such easier configuration, though I still think that using endpoint resolution would avoid duplicating code, and allow using any existing BC that support such feature, while keeping a centralized configuration. Maybe I miss something, i would have thought a BAM component would be more about monitoring than embedding business logic with rules: see one definition of BAM at http://www.ebizq.net/topics/bam/features/4689.html -- of course all definitions can be argued ;) - Original Message - From: Guillaume Nodet [EMAIL PROTECTED] To: servicemix-dev@geronimo.apache.org Sent: Monday, July 31, 2006 4:41 PM Subject: Re: BAM Component On 7/31/06, Soumadeep-Infravio [EMAIL PROTECTED] wrote: Thanks Guillaume, comments inline... Thanks Soumadeep - Original Message - From: Guillaume Nodet [EMAIL PROTECTED] To: servicemix-dev@geronimo.apache.org Cc: servicemix-users@geronimo.apache.org Sent: Monday, July 31, 2006 3:14 PM Subject: Re: BAM Component Great, thx a lot ! CCing servicemix-dev, as I think this is the place where this discussion should take place. Do you have any plan / ideas of future features for this component ? Well, to start with we can have 1) Marshaler for various input sources 2) integration with GUI based monitoring applications 3) integration with OpenOffice, where you can directly feed data to a spread sheet template 4) have an intelligence module to monitor usage/evaluation patterns and predict or forcast based on those patterns ... possibilities are infinite... Currently, it seems this that the component is a router with actions. How will it differ from existing content based routers (xpath router, drools component) ? Traditionally, routing is more in terms of providing options for failover, parallel, load balancing etc...techniques not for monitoring and for taking corrective actions it's again restricted to finding a path to a service/app etc nothing more than that. I was talking about content-based routing ;) I also agree with James that we could leverage ServiceMix expressions. But I do agree we can factor out the existing SM Samples code base and use it Another point I am wondering about, is the fact that the component embeds the email code inside an action: i think it would be better to reuse the existing components Yes, our intension is to factor out the common parameters and use a global configuration file which can be referenced. for that, else the BAM component would end up lots of BCs code internally (what about jms, jabber, etc...). You are right as a feature extension we will certainly use all possible ways of communication/transport , my idea was to provide adaptors for it - actions That was exactly what was worrying me. Having duplicate code will lead to a more difficult maintenance. Maybe we could use URIs ( http://servicemix.goopen.org/site/uris.html), or more generally endpoint resolution. This would allow configuring endpoints in the BAM component, while putting the code in the respective BCs. On 7/31/06, Soumadeep-Infravio [EMAIL PROTECTED] wrote: Hi Guillaume/All, We feel that a Business Activity Monitoring Component would be a good addition to ServiceMix's existing samples. We have worked on a prototype for such a component and would like to contribute it. We have phased it out and depending on the feedback we will add other features as required. Please send us your feedback... Best regards Soumadeep Details of the component == Phase 1 This is a Business Activity Monitoring Component which would work only for Web services message payload in phase 1. An XPath expression could be provided in a config file which will be used to evaluate the incoming message. Depending on the evaluation result it will allow one or more actions to be taken. These actions again could be made available in a config files as below. Config file: === SM-WS-BAM Service url=http://www.xmethod.com/getVersion Rule name=sendEmailWhenGetQuoteInvoked expression value/Envelope/Body/GetQuote Action name=emailer/ Action name=.../ /Rule Rule name=.../
Unassigned Patches: week of 07-31-2006
Project: Apache Geronimo Status: Open Assignee: Unassigned Geronimo Info: Patch Available Total: 25 items DATE UPDATED KEY SUMMARY Jan 3 2006 - GERONIMO-1413 - Console needs to set JSP and Servlet contentType to UTF-8 Jan 19 2006 - GERONIMO-1499 - Daytrader: uncomment the drop table statements in daytrader.sql Jan 19 2006 - GERONIMO-1501 - Daytrader: remove hardcoded dependency versions in project.xml Jan 23 2006 - GERONIMO-1534 - Daytrader: ejb-ql-compiler-factory element is wrong for DB2 or Oracle db Feb 25 2006 - GERONIMO-1652 - EJBModuleImpl.getEJBs() always return an empty array Mar 7 2006 - GERONIMO-1657 - CommandSupport doesn't bubble up the exception. Prints stacktrace. Mar 21 2006 - GERONIMO-1757 - rarRelativePath is not set correctly cause showplan.jsp displayswrong instruction Apr 10 2006 - GERONIMO-1804 - The name of JNDI/RMI service provider is hardcoded in the sources. Apr 11 2006 - GERONIMO-1826 - Naming tests might not work on non-Sun VMs. Apr 12 2006 - GERONIMO-1833 - Non-public Sun classes dependencies in tests Apr 13 2006 - GERONIMO-1840 - NamingPropertiesTest is not compatible with non-Sun VMs. Apr 26 2006 - GERONIMO-1911 - HTTPS algorithm=Default is not preserved after the server is started May 26 2006 - GERONIMO-2064 - Mail archive links in the Welcome portlet should use the redirects at geronimo.apache.org Jun 6 2006 - GERONIMO-1813 - When already deployed application is hot deployed once gain , Server doesn't delete the module from hot deployed directory Jul 16 2006 - GERONIMO-1130 - Implement WebServer Manager (statistics gathering/reporting) management interface Jul 16 2006 - GERONIMO-1341 - POP3 Implementation Jul 16 2006 - GERONIMO-1273 - JMS Network Listener add dialogs should give some context information on the protocol. Jul 16 2006 - GERONIMO-1260 - simplify construction of the combined deployment plan: deployment plan template and preprocessor Jul 16 2006 - GERONIMO-1381 - [Daytrader] Removed unused code Jul 16 2006 - GERONIMO-1396 - Provide consistent look and feel for table views in the web console across all portlets Jul 16 2006 - GERONIMO-1400 - modularize daytrader deployment plan Jul 16 2006 - GERONIMO-1418 - allow user to specify deployment targets by nickname Jul 16 2006 - GERONIMO-1518 - Installer - only copy jars needed by selected configuration Jul 16 2006 - GERONIMO-1648 - Eliminate unnecessary config parent (import) dependencies Jul 16 2006 - GERONIMO-1701 - Improve the EJB Server portlet
Re: BAM Component
On 7/31/06, Soumadeep-Infravio [EMAIL PROTECTED] wrote: Thanks Guillaume, comments inline... Thanks Soumadeep - Original Message - From: Guillaume Nodet [EMAIL PROTECTED] To: servicemix-dev@geronimo.apache.org Cc: servicemix-users@geronimo.apache.org Sent: Monday, July 31, 2006 3:14 PM Subject: Re: BAM Component Great, thx a lot ! CCing servicemix-dev, as I think this is the place where this discussion should take place. Do you have any plan / ideas of future features for this component ? Well, to start with we can have 1) Marshaler for various input sources 2) integration with GUI based monitoring applications 3) integration with OpenOffice, where you can directly feed data to a spread sheet template 4) have an intelligence module to monitor usage/evaluation patterns and predict or forcast based on those patterns ... possibilities are infinite... Currently, it seems this that the component is a router with actions. How will it differ from existing content based routers (xpath router, drools component) ? Traditionally, routing is more in terms of providing options for failover, parallel, load balancing etc...techniques not for monitoring and for taking corrective actions it's again restricted to finding a path to a service/app etc nothing more than that. I was talking about content-based routing ;) I also agree with James that we could leverage ServiceMix expressions. But I do agree we can factor out the existing SM Samples code base and use it Another point I am wondering about, is the fact that the component embeds the email code inside an action: i think it would be better to reuse the existing components Yes, our intension is to factor out the common parameters and use a global configuration file which can be referenced. for that, else the BAM component would end up lots of BCs code internally (what about jms, jabber, etc...). You are right as a feature extension we will certainly use all possible ways of communication/transport , my idea was to provide adaptors for it - actions That was exactly what was worrying me. Having duplicate code will lead to a more difficult maintenance. Maybe we could use URIs ( http://servicemix.goopen.org/site/uris.html), or more generally endpoint resolution. This would allow configuring endpoints in the BAM component, while putting the code in the respective BCs. On 7/31/06, Soumadeep-Infravio [EMAIL PROTECTED] wrote: Hi Guillaume/All, We feel that a Business Activity Monitoring Component would be a good addition to ServiceMix's existing samples. We have worked on a prototype for such a component and would like to contribute it. We have phased it out and depending on the feedback we will add other features as required. Please send us your feedback... Best regards Soumadeep Details of the component == Phase 1 This is a Business Activity Monitoring Component which would work only for Web services message payload in phase 1. An XPath expression could be provided in a config file which will be used to evaluate the incoming message. Depending on the evaluation result it will allow one or more actions to be taken. These actions again could be made available in a config files as below. Config file: === SM-WS-BAM Service url=http://www.xmethod.com/getVersion Rule name=sendEmailWhenGetQuoteInvoked expression value/Envelope/Body/GetQuote Action name=emailer/ Action name=.../ /Rule Rule name=.../ /Service /SM-WS-BAM Actions Action name=emailer Description/ Adaptor name=org.apache.sm.Emailer smtp-host name=mail.webmail.org from address=[EMAIL PROTECTED] to [EMAIL PROTECTED];[EMAIL PROTECTED] message value=There is a new quotation coming your way!! /Adaptor /Action /Actions Flow (inside the BAM component) === note: The usual MEP will be followed to pass the payload to the next component in line. 1) Fetch the Source from the Normalized Message 2) Fetch the rule to evaluate depending on the endpoint-request URL 3) Check for condition and get the evaluation result (using java1.5xpath's evaluate method) 4) Get the adaptor to invoke and invoke it. (Adaptor instances will be cached ) - from the action definition. Phase 2 The component would be extended to monitor any payload. This will be achieved using appropriate marshalers, which will convert the payload to xml. The marshaler to use could be indicated as a property value in the MessageExchange. The rest will be per phase 1. Possible use: == Servicemix 3.0 currently is distributed with several samples, one of them being the http-binding, which internally uses a saaj binding to redirect the message to a soap endpoint. The BAM component could be used in-between
Re: BAM Component
I agree... but in a content based routing too the end result is a path to an application or service etc... though the technology used could be the same but from a BAM perspective the utility factor is effectively greater... - Original Message - From: Guillaume Nodet [EMAIL PROTECTED] To: servicemix-dev@geronimo.apache.org Sent: Monday, July 31, 2006 4:41 PM Subject: Re: BAM Component On 7/31/06, Soumadeep-Infravio [EMAIL PROTECTED] wrote: Thanks Guillaume, comments inline... Thanks Soumadeep - Original Message - From: Guillaume Nodet [EMAIL PROTECTED] To: servicemix-dev@geronimo.apache.org Cc: servicemix-users@geronimo.apache.org Sent: Monday, July 31, 2006 3:14 PM Subject: Re: BAM Component Great, thx a lot ! CCing servicemix-dev, as I think this is the place where this discussion should take place. Do you have any plan / ideas of future features for this component ? Well, to start with we can have 1) Marshaler for various input sources 2) integration with GUI based monitoring applications 3) integration with OpenOffice, where you can directly feed data to a spread sheet template 4) have an intelligence module to monitor usage/evaluation patterns and predict or forcast based on those patterns ... possibilities are infinite... Currently, it seems this that the component is a router with actions. How will it differ from existing content based routers (xpath router, drools component) ? Traditionally, routing is more in terms of providing options for failover, parallel, load balancing etc...techniques not for monitoring and for taking corrective actions it's again restricted to finding a path to a service/app etc nothing more than that. I was talking about content-based routing ;) I also agree with James that we could leverage ServiceMix expressions. But I do agree we can factor out the existing SM Samples code base and use it Another point I am wondering about, is the fact that the component embeds the email code inside an action: i think it would be better to reuse the existing components Yes, our intension is to factor out the common parameters and use a global configuration file which can be referenced. for that, else the BAM component would end up lots of BCs code internally (what about jms, jabber, etc...). You are right as a feature extension we will certainly use all possible ways of communication/transport , my idea was to provide adaptors for it - actions That was exactly what was worrying me. Having duplicate code will lead to a more difficult maintenance. Maybe we could use URIs ( http://servicemix.goopen.org/site/uris.html), or more generally endpoint resolution. This would allow configuring endpoints in the BAM component, while putting the code in the respective BCs. On 7/31/06, Soumadeep-Infravio [EMAIL PROTECTED] wrote: Hi Guillaume/All, We feel that a Business Activity Monitoring Component would be a good addition to ServiceMix's existing samples. We have worked on a prototype for such a component and would like to contribute it. We have phased it out and depending on the feedback we will add other features as required. Please send us your feedback... Best regards Soumadeep Details of the component == Phase 1 This is a Business Activity Monitoring Component which would work only for Web services message payload in phase 1. An XPath expression could be provided in a config file which will be used to evaluate the incoming message. Depending on the evaluation result it will allow one or more actions to be taken. These actions again could be made available in a config files as below. Config file: === SM-WS-BAM Service url=http://www.xmethod.com/getVersion Rule name=sendEmailWhenGetQuoteInvoked expression value/Envelope/Body/GetQuote Action name=emailer/ Action name=.../ /Rule Rule name=.../ /Service /SM-WS-BAM Actions Action name=emailer Description/ Adaptor name=org.apache.sm.Emailer smtp-host name=mail.webmail.org from address=[EMAIL PROTECTED] to [EMAIL PROTECTED];[EMAIL PROTECTED] message value=There is a new quotation coming your way!! /Adaptor /Action /Actions Flow (inside the BAM component) === note: The usual MEP will be followed to pass the payload to the next component in line. 1) Fetch the Source from the Normalized Message 2) Fetch the rule to evaluate depending on the endpoint-request URL 3) Check for condition and get the evaluation result (using java1.5xpath's evaluate method) 4) Get the adaptor to invoke and invoke it. (Adaptor instances will be cached ) - from the action definition. Phase 2 The component would be extended to monitor any payload. This will be achieved using appropriate marshalers,
[jira] Updated: (GERONIMO-1906) Cannot add a new connector using ActiveMQManagerGBean
[ http://issues.apache.org/jira/browse/GERONIMO-1906?page=all ] Sachin Patel updated GERONIMO-1906: --- Assignee: (was: Sachin Patel) Cannot add a new connector using ActiveMQManagerGBean - Key: GERONIMO-1906 URL: http://issues.apache.org/jira/browse/GERONIMO-1906 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: ActiveMQ Affects Versions: 1.1 Environment: Geronimo 1.1 build, rev 396619; activemq_version=3.2.4-SNAPSHOT Reporter: Paul McMahan Priority: Critical Fix For: 1.1.1 Attachments: ACTIVEMQ-gbeaninfo.diff Calling this API: myJMSManager.addConnector( myJMSBroker, name, protocol, host, port ); Produces the following ST: java.lang.AssertionError: javax.management.MalformedObjectNameException: Invalid value: geronimo/activemq-broker/1.1-SNAPSHOT/car?ServiceModule=geronimo/activemq-broker/1.1-SNAPSHOT/car,j2eeType=JMSServer,name=ActiveMQ.activeio.0.0.0.0.61616-test at org.apache.geronimo.kernel.Jsr77Naming.createObjectName(Jsr77Naming.java:98) at org.apache.geronimo.kernel.Jsr77Naming.createChildName(Jsr77Naming.java:66) at org.apache.geronimo.kernel.Jsr77Naming.createChildName(Jsr77Naming.java:54) at org.activemq.gbean.management.ActiveMQManagerGBean.addConnector(ActiveMQManagerGBean.java:179) at org.activemq.gbean.management.ActiveMQManagerGBean$$FastClassByCGLIB$$a78b116e.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:816) at org.apache.geronimo.gbean.runtime.RawInvoker.invoke(RawInvoker.java:57) at org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke(RawOperationInvoker.java:35) at org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept(ProxyMethodInterceptor.java:96) at org.activemq.gbean.ActiveMQManager$$EnhancerByCGLIB$$2bdd185c.addConnector(generated) at org.apache.geronimo.console.util.PortletManager.createJMSConnector(PortletManager.java:274) at org.apache.geronimo.console.jmsmanager.server.JMSConnectorPortlet.processAction(JMSConnectorPortlet.java:80) at org.apache.pluto.core.PortletServlet.dispatch(PortletServlet.java:229) at org.apache.pluto.core.PortletServlet.doGet(PortletServlet.java:158) at javax.servlet.http.HttpServlet.service(HttpServlet.java:595) at javax.servlet.http.HttpServlet.service(HttpServlet.java:688) at org.apache.pluto.core.PortletServlet.service(PortletServlet.java:153) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173) at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:672) at org.apache.catalina.core.ApplicationDispatcher.doInclude(ApplicationDispatcher.java:574) at org.apache.catalina.core.ApplicationDispatcher.include(ApplicationDispatcher.java:499) at org.apache.pluto.invoker.impl.PortletInvokerImpl.invoke(PortletInvokerImpl.java:120) at org.apache.pluto.invoker.impl.PortletInvokerImpl.action(PortletInvokerImpl.java:68) at org.apache.pluto.PortletContainerImpl.processPortletAction(PortletContainerImpl.java:164) at org.apache.pluto.portalImpl.core.PortletContainerWrapperImpl.processPortletAction(PortletContainerWrapperImpl.java:82) at org.apache.pluto.portalImpl.Servlet.doGet(Servlet.java:227) at javax.servlet.http.HttpServlet.service(HttpServlet.java:595) at javax.servlet.http.HttpServlet.service(HttpServlet.java:688) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:178) at org.apache.geronimo.tomcat.valve.DefaultSubjectValve.invoke(DefaultSubjectValve.java:52) at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:482) at org.apache.geronimo.tomcat.GeronimoStandardContext$SystemMethodValve.invoke(GeronimoStandardContext.java:336) at org.apache.geronimo.tomcat.valve.GeronimoBeforeAfterValve.invoke(GeronimoBeforeAfterValve.java:31) at
critical jetty keystore problems on 1.1.1
I'm still trying to figure out some critical problems with the keystore processing on jetty. The most serious problem that I've yet to resolve is a problem with the lock/unlock of the keystore availability lock. A subsequent server restart will fail because Keystore 'geronimo-default' is locked. It appears that we cannot recover from this error either. Even if I change the config.xml for SSLConnector to load=false, restart the server, unlock the keystore/key (again) I still get the same failure when I attempt to start with the SSLConnector enabled. At first I thought this was because of the duplicate attribute entries referenced in an earlier post. In fact, I'm pretty sure that I edited the config.xml to remove the null entries and was able to get the server started. However, I have recently been unable to recover from this error using the same mechanism. In fact it seems to create more problems because after removing the null entries I now get an UnrecoverableKeyException. Any advice or recommendations? I'm beginning to wonder if we should disable the keystore portlet for 1.1.1 so that the user can't shoot himself in the foot. Joe
Re: BAM Component
On 7/31/06, Soumadeep-Infravio [EMAIL PROTECTED] wrote: I agree... but in a content based routing too the end result is a path to an application or service etc... though the technology used could be the same but from a BAM perspective the utility factor is effectively greater... Agreed. And be sure that I do not underestimate the need for such easier configuration, though I still think that using endpoint resolution would avoid duplicating code, and allow using any existing BC that support such feature, while keeping a centralized configuration. Maybe I miss something, i would have thought a BAM component would be more about monitoring than embedding business logic with rules: see one definition of BAM at http://www.ebizq.net/topics/bam/features/4689.html -- of course all definitions can be argued ;) - Original Message - From: Guillaume Nodet [EMAIL PROTECTED] To: servicemix-dev@geronimo.apache.org Sent: Monday, July 31, 2006 4:41 PM Subject: Re: BAM Component On 7/31/06, Soumadeep-Infravio [EMAIL PROTECTED] wrote: Thanks Guillaume, comments inline... Thanks Soumadeep - Original Message - From: Guillaume Nodet [EMAIL PROTECTED] To: servicemix-dev@geronimo.apache.org Cc: servicemix-users@geronimo.apache.org Sent: Monday, July 31, 2006 3:14 PM Subject: Re: BAM Component Great, thx a lot ! CCing servicemix-dev, as I think this is the place where this discussion should take place. Do you have any plan / ideas of future features for this component ? Well, to start with we can have 1) Marshaler for various input sources 2) integration with GUI based monitoring applications 3) integration with OpenOffice, where you can directly feed data to a spread sheet template 4) have an intelligence module to monitor usage/evaluation patterns and predict or forcast based on those patterns ... possibilities are infinite... Currently, it seems this that the component is a router with actions. How will it differ from existing content based routers (xpath router, drools component) ? Traditionally, routing is more in terms of providing options for failover, parallel, load balancing etc...techniques not for monitoring and for taking corrective actions it's again restricted to finding a path to a service/app etc nothing more than that. I was talking about content-based routing ;) I also agree with James that we could leverage ServiceMix expressions. But I do agree we can factor out the existing SM Samples code base and use it Another point I am wondering about, is the fact that the component embeds the email code inside an action: i think it would be better to reuse the existing components Yes, our intension is to factor out the common parameters and use a global configuration file which can be referenced. for that, else the BAM component would end up lots of BCs code internally (what about jms, jabber, etc...). You are right as a feature extension we will certainly use all possible ways of communication/transport , my idea was to provide adaptors for it - actions That was exactly what was worrying me. Having duplicate code will lead to a more difficult maintenance. Maybe we could use URIs ( http://servicemix.goopen.org/site/uris.html), or more generally endpoint resolution. This would allow configuring endpoints in the BAM component, while putting the code in the respective BCs. On 7/31/06, Soumadeep-Infravio [EMAIL PROTECTED] wrote: Hi Guillaume/All, We feel that a Business Activity Monitoring Component would be a good addition to ServiceMix's existing samples. We have worked on a prototype for such a component and would like to contribute it. We have phased it out and depending on the feedback we will add other features as required. Please send us your feedback... Best regards Soumadeep Details of the component == Phase 1 This is a Business Activity Monitoring Component which would work only for Web services message payload in phase 1. An XPath expression could be provided in a config file which will be used to evaluate the incoming message. Depending on the evaluation result it will allow one or more actions to be taken. These actions again could be made available in a config files as below. Config file: === SM-WS-BAM Service url=http://www.xmethod.com/getVersion Rule name=sendEmailWhenGetQuoteInvoked expression value/Envelope/Body/GetQuote Action name=emailer/ Action name=.../ /Rule Rule name=.../ /Service /SM-WS-BAM Actions Action name=emailer Description/ Adaptor name=org.apache.sm.Emailer smtp-host name=mail.webmail.org from address=[EMAIL PROTECTED] to [EMAIL PROTECTED];[EMAIL PROTECTED]
Re: servicemix web service
thank you, but where I can find other information on this? Are there some examples on wsdl file necessary to publish a component like web service? -- View this message in context: http://www.nabble.com/servicemix---web-service-tf2009607.html#a5575262 Sent from the ServiceMix - Dev forum at Nabble.com.
[jira] Created: (GERONIMO-2250) Error rather than exception from server whilst deploying causes deployer to hang (not end)
Error rather than exception from server whilst deploying causes deployer to hang (not end) -- Key: GERONIMO-2250 URL: http://issues.apache.org/jira/browse/GERONIMO-2250 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Components: deployment Affects Versions: 1.1, 1.0 Reporter: John Sisson Priority: Minor Fix For: 1.x Whilst using the test application attached to GERONIMO-1996 I found that the Error from the server (e.g. java.lang.ExceptionInInitializerError ) caused the thread (see Thread-2 below) to end and the deploy command does not return. It appears that the run() methods for commands need to catch Throwable rather than Exception so that it can end more gracefully. Debugger output: Java HotSpot(TM) Client VM[localhost:8001] Thread [main] (Suspended) org.apache.geronimo.deployment.plugin.jmx.RemoteDeploymentManager(org.apache.geronimo.deployment.plugin.jmx.JMXDeploymentManager).distribute(javax.enterprise.deploy.spi.Target[], java.io.File, java.io.File) line: 176 org.apache.geronimo.deployment.cli.CommandDeploy(org.apache.geronimo.deployment.cli.CommandDistribute).runCommand(javax.enterprise.deploy.spi.DeploymentManager, java.io.PrintWriter, boolean, javax.enterprise.deploy.spi.Target[], java.io.File, java.io.File) line: 75 org.apache.geronimo.deployment.cli.CommandDeploy.runCommand(javax.enterprise.deploy.spi.DeploymentManager, java.io.PrintWriter, boolean, javax.enterprise.deploy.spi.Target[], java.io.File, java.io.File) line: 51 org.apache.geronimo.deployment.cli.CommandDeploy(org.apache.geronimo.deployment.cli.CommandDistribute).executeOnline(org.apache.geronimo.deployment.cli.ServerConnection, boolean, java.util.List, java.io.PrintWriter, java.io.File, java.io.File) line: 148 org.apache.geronimo.deployment.cli.CommandDeploy(org.apache.geronimo.deployment.cli.CommandDistribute).execute(java.io.PrintWriter, org.apache.geronimo.deployment.cli.ServerConnection, java.lang.String[]) line: 132 org.apache.geronimo.deployment.cli.CommandDeploy.execute(java.io.PrintWriter, org.apache.geronimo.deployment.cli.ServerConnection, java.lang.String[]) line: 60 org.apache.geronimo.deployment.cli.DeployTool.execute(java.lang.String[]) line: 159 org.apache.geronimo.deployment.cli.DeployTool.main(java.lang.String[]) line: 313 Thread [Thread-1] (Running) Thread [Connection HeartBeat] (Running) Thread [Notification Deliverer #1] (Running) Thread [Notification Fetcher #1] (Running) Thread [Thread-2] (Suspended (exception java.lang.ExceptionInInitializerError)) org.apache.geronimo.deployment.plugin.local.DistributeCommand.run() line: 65 java.lang.Thread.run() line: not available -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: svn commit: r427120 - /geronimo/branches/1.1/modules/deployment/src/java/org/apache/geronimo/deployment/Deployer.java
Hurray!
Thanks,
Aaron
On 7/31/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
Author: jsisson
Date: Mon Jul 31 07:08:13 2006
New Revision: 427120
URL: http://svn.apache.org/viewvc?rev=427120view=rev
Log:
GERONIMO-1996 Fix cleanup of configurations when Errors occur. Previously an
Error such as a java.lang.ExceptionInInitializerError during Serialization
during deployment leaves files in the repository and possibly leaves things in
a state where you cannot undeploy.
Modified:
geronimo/branches/1.1/modules/deployment/src/java/org/apache/geronimo/deployment/Deployer.java
Modified:
geronimo/branches/1.1/modules/deployment/src/java/org/apache/geronimo/deployment/Deployer.java
URL:
http://svn.apache.org/viewvc/geronimo/branches/1.1/modules/deployment/src/java/org/apache/geronimo/deployment/Deployer.java?rev=427120r1=427119r2=427120view=diff
==
---
geronimo/branches/1.1/modules/deployment/src/java/org/apache/geronimo/deployment/Deployer.java
(original)
+++
geronimo/branches/1.1/modules/deployment/src/java/org/apache/geronimo/deployment/Deployer.java
Mon Jul 31 07:08:13 2006
@@ -301,6 +301,7 @@
// It's our responsibility to close this context, once we're done
with it...
DeploymentContext context = builder.buildConfiguration(inPlace,
configID, plan, module, stores, artifactResolver, store);
List configurations = new ArrayList();
+boolean configsCleanupRequired = false;
configurations.add(context.getConfigurationData());
configurations.addAll(context.getAdditionalDeployment());
@@ -334,23 +335,31 @@
notifyWatchers(deployedURIs);
return deployedURIs;
} else {
-cleanupConfigurations(configurations);
+configsCleanupRequired = true;
return Collections.EMPTY_LIST;
}
} catch (DeploymentException e) {
-cleanupConfigurations(configurations);
+configsCleanupRequired = true;
throw e;
} catch (IOException e) {
-cleanupConfigurations(configurations);
+configsCleanupRequired = true;
throw e;
} catch (InvalidConfigException e) {
-cleanupConfigurations(configurations);
+configsCleanupRequired = true;
// unlikely as we just built this
throw new DeploymentException(e);
+} catch (Throwable e) {
+// Could get here if serialization of the configuration failed
(GERONIMO-1996)
+configsCleanupRequired = true;
+throw e;
} finally {
thread.setContextClassLoader(oldCl);
if (context != null) {
context.close();
+}
+if (configsCleanupRequired) {
+// We do this after context is closed so the module jar
isn't open
+cleanupConfigurations(configurations);
}
}
} catch (Throwable e) {
[jira] Created: (GERONIMODEVTOOLS-93) Support for non-plugin archives for installable runtimes
Support for non-plugin archives for installable runtimes Key: GERONIMODEVTOOLS-93 URL: http://issues.apache.org/jira/browse/GERONIMODEVTOOLS-93 Project: Geronimo-Devtools Issue Type: Improvement Components: eclipse-plugin Affects Versions: 1.1.0 Reporter: Sachin Patel Assigned To: Sachin Patel Fix For: 1.1.0 With the following support in wtp 1.5.1 https://bugs.eclipse.org/bugs/show_bug.cgi?id=125385 need to rid of the installable runtime plugins that wrap the entire appserver and replace them with data archives in the feature that reference the geronimo binary distributions directly -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: 1.1.1 Status
Any objections to removing the licenses from the about page in the console. See GERONIMO-2136 (listed below) FYI, I was originally planning on upgrading Derby (*GERONIMO-2155 https://issues.apache.org/jira/browse/GERONIMO-2155)*, but the debug versions of the derby libraries aren't in the maven repos and I'm running out of time, so will leave as targeted for 1.x. Thanks, John Matt Hogstrom wrote: There has been a lot of progress on 1.1.1. We started with 61 issues and we're down to 21 left. Originally I suggested that we branch on Friday. I'd like to give a little more time and would like to revise the branch to a freeze state on Tuesday, August 1 at 0500 PT. At that time I'll spin off branches/1.1.1 and update branches/1.1 to be 1.1.2-SNAPSHOT. We'll do performance regression and TCK work during the next week and shoot for an official release within two weeks. If anyone is opposed to this plan let me know. Also, please review the JIRA's below. If you don't think you can get thte ones done with your name please unassign yourself and hopefully someone else will pick them up. Thanks. *Outstanding Issues* GERONIMO- Open John Sisson Application errors in static initialization blocks during serialization of configuration during deployment due to incorrect TCCL GERONIMO-2218 Open Unassigned KeyStore portlet: Functionality missing from 1.0 GERONIMO-1906 Reopened Sachin Patel Cannot add a new connector using ActiveMQManagerGBean GERONIMO-1917 Open David Jencks repository doesn't deal well with case insensitive file systems GERONIMO-1996 Open John Sisson Serialization failure during deployment leaves a config.ser in the repository but doesn't write a config.info causing problems later. GERONIMO-2080 Open John Sisson Create a Geronimo Bug Guidelines Page GERONIMO-2169 Open Kevan Miller Once tagged, the m:co goal of tags/1.1.1 should checkout the corresponding tagged version of OpenEJB (not a branch) GERONIMO-2170 Open Kevan Miller Tagged versions of Geronimo should not include people.apache.org/repository in their list of maven repositories GERONIMO-2167 Open Kevan Miller deployer.jar not cleaning up properly during redeploy and undeploy GERONIMO-2202 Open Kevan Miller Move to new Apache Maven 1 repo (repo/m1-snapshot-repository 1.2 GERONIMO-2030 Open Unassigned Allow WebServiceBuilder determine if there are WebServices to be deployed GERONIMO-1476 Open Unassigned Changes to default log4j.rootCategory are not dynamic GERONIMO-2228 Open Unassigned GeronimoAsMavenServlet.java generates wrong default-repository element GERONIMO-2230 Open Aaron Mulder No cleanup after DeploymentWatcher exception GERONIMO-2142 Open David Jencks EJB Refs to EJB in parent module often fail GERONIMO-2227 Open David Jencks ENC Lookup Fix (include parent modules) GERONIMO-1557 Open David Jencks When you enter the url of a web service in the console You should get a page showing the service name GERONIMO-1531 Open Unassigned KeyStore portlet should support deletion of certificates and private keys GERONIMO-1716 Open Donald Woods Add usage of SimpleEncryption to PropertiesFileLoginModule and Admin Console GERONIMO-2204 Open David Jencks ProxyMethodInterceptor doesn't handle finalize appropriately GERONIMO-2136 Open John Sisson Remove/Update licenses displayed in about page of console GERONIMO-1810 Open John Sisson Improve the Error: Unable to distribute foo.ear: Cannot deploy the requested application module message
Re: TCK Dog
On Jul 28, 2006, at 4:30 PM, Joe Bohn wrote: Kevan, Sorry for being so late with this response, but I was thinking that I should probably get involved some with the TCK (to help address your desire for broader participation across the project and get some much deserved personal relief). I just faxed my NDA for confidential materials. I'll let you know when I get my authorization. Hey Joe, That's great! Thanks. --kevan Kevan Miller wrote: On Jul 10, 2006, at 1:55 PM, David Blevins wrote: Kevan, you've been tck dog for six months now. Having built the system and done the job myself, I know you're not going to survive another six months. We definitely need to get someone else to take that job for a while. What do you think? I certainly agree with that... I would also hope that we can work on distributing the burden, a bit. So, it's not one dog, but several... Although I certainly had a lot of help from you, David J, and Dain, It'd be great to see a broader base of participation... I see the following pieces: 1) Keeping builds running through Continuum 2) Keeping tests running through GBuild 3) Monitoring/advertising test results. 4) Fixing problems It's #4 that can be the killer and where we should be working as a team... but the others can eat up time, also. I have #1 going for 1.1.1-SNAPSHOT and 1.2-SNAPSHOT. Hope to get #2 going later today... Now, would be a great time for getting more people involved... --kevan
Re: 1.1.1 Status
Fine with me On 7/31/06, John Sisson [EMAIL PROTECTED] wrote: Any objections to removing the licenses from the about page in the console. See GERONIMO-2136 (listed below) FYI, I was originally planning on upgrading Derby (*GERONIMO-2155 https://issues.apache.org/jira/browse/GERONIMO-2155)*, but the debug versions of the derby libraries aren't in the maven repos and I'm running out of time, so will leave as targeted for 1.x. Thanks, John Matt Hogstrom wrote: There has been a lot of progress on 1.1.1. We started with 61 issues and we're down to 21 left. Originally I suggested that we branch on Friday. I'd like to give a little more time and would like to revise the branch to a freeze state on Tuesday, August 1 at 0500 PT. At that time I'll spin off branches/1.1.1 and update branches/1.1 to be 1.1.2-SNAPSHOT. We'll do performance regression and TCK work during the next week and shoot for an official release within two weeks. If anyone is opposed to this plan let me know. Also, please review the JIRA's below. If you don't think you can get thte ones done with your name please unassign yourself and hopefully someone else will pick them up. Thanks. *Outstanding Issues* GERONIMO- Open John Sisson Application errors in static initialization blocks during serialization of configuration during deployment due to incorrect TCCL GERONIMO-2218 Open Unassigned KeyStore portlet: Functionality missing from 1.0 GERONIMO-1906 Reopened Sachin Patel Cannot add a new connector using ActiveMQManagerGBean GERONIMO-1917 Open David Jencks repository doesn't deal well with case insensitive file systems GERONIMO-1996 Open John Sisson Serialization failure during deployment leaves a config.ser in the repository but doesn't write a config.info causing problems later. GERONIMO-2080 Open John Sisson Create a Geronimo Bug Guidelines Page GERONIMO-2169 Open Kevan Miller Once tagged, the m:co goal of tags/1.1.1 should checkout the corresponding tagged version of OpenEJB (not a branch) GERONIMO-2170 Open Kevan Miller Tagged versions of Geronimo should not include people.apache.org/repository in their list of maven repositories GERONIMO-2167 Open Kevan Miller deployer.jar not cleaning up properly during redeploy and undeploy GERONIMO-2202 Open Kevan Miller Move to new Apache Maven 1 repo (repo/m1-snapshot-repository 1.2 GERONIMO-2030 Open Unassigned Allow WebServiceBuilder determine if there are WebServices to be deployed GERONIMO-1476 Open Unassigned Changes to default log4j.rootCategory are not dynamic GERONIMO-2228 Open Unassigned GeronimoAsMavenServlet.java generates wrong default-repository element GERONIMO-2230 Open Aaron Mulder No cleanup after DeploymentWatcher exception GERONIMO-2142 Open David Jencks EJB Refs to EJB in parent module often fail GERONIMO-2227 Open David Jencks ENC Lookup Fix (include parent modules) GERONIMO-1557 Open David Jencks When you enter the url of a web service in the console You should get a page showing the service name GERONIMO-1531 Open Unassigned KeyStore portlet should support deletion of certificates and private keys GERONIMO-1716 Open Donald Woods Add usage of SimpleEncryption to PropertiesFileLoginModule and Admin Console GERONIMO-2204 Open David Jencks ProxyMethodInterceptor doesn't handle finalize appropriately GERONIMO-2136 Open John Sisson Remove/Update licenses displayed in about page of console GERONIMO-1810 Open John Sisson Improve the Error: Unable to distribute foo.ear: Cannot deploy the requested application module message
Re: wiki migration
John Sisson wrote: Hernan Cunico wrote: Hi All, this is a friendly reminder that the Moin Moin wiki ( namely wiki.apache.org/geronimo ) is being migrated to the confluence based http://cwiki.apache.org/geronimo Great! Please refrain from continuing updating content to the Moin Moin wiki. The current migration status can me seen at http://cwiki.apache.org/confluence/display/GMOxMoinMoin/Home I tried looking at the status and got a page not found. I also tried http://cwiki.apache.org/confluence/display/GMOxMoinMoin and got a Not Permitted page. Not sure what the problem is, I just clicked those two links and both worked without logging in. Does anyone else have this problem? This is the raw content migrated so far from the Moin Moin wiki has not been edited yet, this is a temporary space while migrating. This is the first step of several, later this content will be evaluated for accuracy and then incorporated to one of the cwiki.apache.org/geronimo sub-structures. Comments, suggestions and HELP! are very much welcomed. Will information be moved to space for a particular release? E.G. the build instructions for 1.1.x will differ to 1.2? Yes but first thing first, we need to totally move the Moin Moin content to confluence, get rid of the duplicated/obsolete information (do some housekeeping) and then get the good stuff reorganized into confluence structure. We may potentially need to create additional spaces. Looking at the current organization we have we already have the content organized according to Geronimo versions, we may need to do some reorganization within those spaces (maybe consolidating user's and developer's guide into just user's guide for simplicity). As soon as we have some material to put out for v1.2 we will create a new Apache Geronimo v1.2 space with version specific info. Cheers! Hernan Thanks, John Cheers! Hernan
Re: 1.1.1 Status
Okay with me. John Sisson wrote: Any objections to removing the licenses from the about page in the console. See GERONIMO-2136 (listed below) FYI, I was originally planning on upgrading Derby (*GERONIMO-2155 https://issues.apache.org/jira/browse/GERONIMO-2155)*, but the debug versions of the derby libraries aren't in the maven repos and I'm running out of time, so will leave as targeted for 1.x. Thanks, John Matt Hogstrom wrote: There has been a lot of progress on 1.1.1. We started with 61 issues and we're down to 21 left. Originally I suggested that we branch on Friday. I'd like to give a little more time and would like to revise the branch to a freeze state on Tuesday, August 1 at 0500 PT. At that time I'll spin off branches/1.1.1 and update branches/1.1 to be 1.1.2-SNAPSHOT. We'll do performance regression and TCK work during the next week and shoot for an official release within two weeks. If anyone is opposed to this plan let me know. Also, please review the JIRA's below. If you don't think you can get thte ones done with your name please unassign yourself and hopefully someone else will pick them up. Thanks. *Outstanding Issues* GERONIMO- Open John Sisson Application errors in static initialization blocks during serialization of configuration during deployment due to incorrect TCCL GERONIMO-2218 Open Unassigned KeyStore portlet: Functionality missing from 1.0 GERONIMO-1906 Reopened Sachin Patel Cannot add a new connector using ActiveMQManagerGBean GERONIMO-1917 Open David Jencks repository doesn't deal well with case insensitive file systems GERONIMO-1996 Open John Sisson Serialization failure during deployment leaves a config.ser in the repository but doesn't write a config.info causing problems later. GERONIMO-2080 Open John Sisson Create a Geronimo Bug Guidelines Page GERONIMO-2169 Open Kevan Miller Once tagged, the m:co goal of tags/1.1.1 should checkout the corresponding tagged version of OpenEJB (not a branch) GERONIMO-2170 Open Kevan Miller Tagged versions of Geronimo should not include people.apache.org/repository in their list of maven repositories GERONIMO-2167 Open Kevan Miller deployer.jar not cleaning up properly during redeploy and undeploy GERONIMO-2202 Open Kevan Miller Move to new Apache Maven 1 repo (repo/m1-snapshot-repository 1.2 GERONIMO-2030 Open Unassigned Allow WebServiceBuilder determine if there are WebServices to be deployed GERONIMO-1476 Open Unassigned Changes to default log4j.rootCategory are not dynamic GERONIMO-2228 Open Unassigned GeronimoAsMavenServlet.java generates wrong default-repository element GERONIMO-2230 Open Aaron Mulder No cleanup after DeploymentWatcher exception GERONIMO-2142 Open David Jencks EJB Refs to EJB in parent module often fail GERONIMO-2227 Open David Jencks ENC Lookup Fix (include parent modules) GERONIMO-1557 Open David Jencks When you enter the url of a web service in the console You should get a page showing the service name GERONIMO-1531 Open Unassigned KeyStore portlet should support deletion of certificates and private keys GERONIMO-1716 Open Donald Woods Add usage of SimpleEncryption to PropertiesFileLoginModule and Admin Console GERONIMO-2204 Open David Jencks ProxyMethodInterceptor doesn't handle finalize appropriately GERONIMO-2136 Open John Sisson Remove/Update licenses displayed in about page of console GERONIMO-1810 Open John Sisson Improve the Error: Unable to distribute foo.ear: Cannot deploy the requested application module message
Re: Pessimistic locking strategy for CMP beans in 1.1.1
Perhaps one additional element in the optimistic section like: concurrency-control[DATABASE | CONTAINER]/concurrency-control Dain Sundstrom wrote: +1 looks good On Jul 26, 2006, at 7:47 PM, Matt Hogstrom wrote: locking-strategy optimistic-locking optimistic-columnoccColumn/optimistic-column optimistic-typeTIMESTAMP/optimistic-type /locking-strategy one comment... this xml implies that the database is handling the auto increment/update of the optimistic lock column. I have seen schemas that assume that the application code will be handling this, with some sql like this: UPDATE foo SET value = newValue, ver = 5 WHERE pk = myPk AND ver = 4 If the database is auto updating the row, you will need to reread the column after any update, so if you make another update in the same transaction, you can assure you know the current value of the optimistic column. -dain
1.1.1 Status 2006/07/31
Hey everyone, We're almost there for 1.1.1. I noticed that people are opeening new JIRA's for 1.1.1 which is great. However, unless you feel you can get them done before the cut off time please put them in 1.x or 1.2. I plan on moving all outstanding JIRAs as of the cut off time to the next release. Alan rightly pointed out a few day slip. We can easily start a 1.1.2 if people have critical fixes they want to get in. The branch time remains at *Tuesday, August 1 at 0500 PT*. On or around this time I will do an SVN copy to branches/1.1.1 and we'll start the final testing, TCK, etc. with the goal to get this out next week. I announced this time on Friday. Comments welcome :) Matt
Re: 1.1.1 Status
Sounds good to me. --kevan On Jul 31, 2006, at 10:25 AM, John Sisson wrote: Any objections to removing the licenses from the about page in the console. See GERONIMO-2136 (listed below) FYI, I was originally planning on upgrading Derby (*GERONIMO-2155 https://issues.apache.org/jira/browse/GERONIMO-2155)*, but the debug versions of the derby libraries aren't in the maven repos and I'm running out of time, so will leave as targeted for 1.x. Thanks, John Matt Hogstrom wrote: There has been a lot of progress on 1.1.1. We started with 61 issues and we're down to 21 left. Originally I suggested that we branch on Friday. I'd like to give a little more time and would like to revise the branch to a freeze state on Tuesday, August 1 at 0500 PT. At that time I'll spin off branches/1.1.1 and update branches/1.1 to be 1.1.2-SNAPSHOT. We'll do performance regression and TCK work during the next week and shoot for an official release within two weeks. If anyone is opposed to this plan let me know. Also, please review the JIRA's below. If you don't think you can get thte ones done with your name please unassign yourself and hopefully someone else will pick them up. Thanks. *Outstanding Issues* GERONIMO- Open John Sisson Application errors in static initialization blocks during serialization of configuration during deployment due to incorrect TCCL GERONIMO-2218 Open Unassigned KeyStore portlet: Functionality missing from 1.0 GERONIMO-1906 Reopened Sachin Patel Cannot add a new connector using ActiveMQManagerGBean GERONIMO-1917 Open David Jencks repository doesn't deal well with case insensitive file systems GERONIMO-1996 Open John Sisson Serialization failure during deployment leaves a config.ser in the repository but doesn't write a config.info causing problems later. GERONIMO-2080 Open John Sisson Create a Geronimo Bug Guidelines Page GERONIMO-2169 Open Kevan Miller Once tagged, the m:co goal of tags/1.1.1 should checkout the corresponding tagged version of OpenEJB (not a branch) GERONIMO-2170 Open Kevan Miller Tagged versions of Geronimo should not include people.apache.org/repository in their list of maven repositories GERONIMO-2167 Open Kevan Miller deployer.jar not cleaning up properly during redeploy and undeploy GERONIMO-2202 Open Kevan Miller Move to new Apache Maven 1 repo (repo/m1-snapshot-repository 1.2 GERONIMO-2030 Open Unassigned Allow WebServiceBuilder determine if there are WebServices to be deployed GERONIMO-1476 Open Unassigned Changes to default log4j.rootCategory are not dynamic GERONIMO-2228 Open Unassigned GeronimoAsMavenServlet.java generates wrong default-repository element GERONIMO-2230 Open Aaron Mulder No cleanup after DeploymentWatcher exception GERONIMO-2142 Open David Jencks EJB Refs to EJB in parent module often fail GERONIMO-2227 Open David Jencks ENC Lookup Fix (include parent modules) GERONIMO-1557 Open David Jencks When you enter the url of a web service in the console You should get a page showing the service name GERONIMO-1531 Open Unassigned KeyStore portlet should support deletion of certificates and private keys GERONIMO-1716 Open Donald Woods Add usage of SimpleEncryption to PropertiesFileLoginModule and Admin Console GERONIMO-2204 Open David Jencks ProxyMethodInterceptor doesn't handle finalize appropriately GERONIMO-2136 Open John Sisson Remove/Update licenses displayed in about page of console GERONIMO-1810 Open John Sisson Improve the Error: Unable to distribute foo.ear: Cannot deploy the requested application module message
Re: wiki migration
Hi Kanchana, There is an icon in the upper right corner to export the content ( formatted ) in PDF. If you want a confluence backup you can click Browse Space - Advanced - Export Space, select XML Output and click Export Cheers! Hernan Kanchana Welagedara wrote: Hi Hernan I worked on the apache wiki staging environment and presently I stopped working on the the staging.I want to get a copy and back ups of the work I have done so far.What is the method of getting a back up of the staging work?It's just a copy and past from the wiki to a document or more than that? Is there a way of getting a copy with out making any harm to the format of the documents? Thanks Kanchana On 7/29/06, Hernan Cunico [EMAIL PROTECTED] wrote: Hi All, this is a friendly reminder that the Moin Moin wiki ( namely wiki.apache.org/geronimo ) is being migrated to the confluence based http://cwiki.apache.org/geronimo Please refrain from continuing updating content to the Moin Moin wiki. The current migration status can me seen at http://cwiki.apache.org/confluence/display/GMOxMoinMoin/Home This is the raw content migrated so far from the Moin Moin wiki has not been edited yet, this is a temporary space while migrating. This is the first step of several, later this content will be evaluated for accuracy and then incorporated to one of the cwiki.apache.org/geronimo sub-structures. Comments, suggestions and HELP! are very much welcomed. Cheers! Hernan
Re: BAM Component
I guess for now let's stick to the passive mode and delegate the processing, based on an event. Let me know -from a birds eye view if this is OK. 1) we passively sniff data from payloads 2) evaluate the xpath based expression(reuse what is available in SM) 3) delegate the processing to some adaptor (or reuse what is available in SM) 4) provide configuration files for global,rule and actions - or reuse the existing URI based code (do let us know how you want to reuse it) Thanks Soumadeep - Original Message - From: Soumadeep-Infravio [EMAIL PROTECTED] To: servicemix-dev@geronimo.apache.org Sent: Monday, July 31, 2006 7:36 PM Subject: Re: BAM Component I agree...about reusability. Regarding the concepts of BAM I guess there has been a lot of debate on this... Here is the trade off - from a use case perspective : 1) Passive - where we just sniff the data without hindering the process and delegate the processing depending on an event. - pure monitoring mode. 2) Active - where the evaluation takes place and depending on the situation the process is terminated because of an evaluation exception. Say for example : I set up a rule which says that if the order value is more than $5000 then switch to async mode because the retailer doesn't keep stock more than $1000 and can't handle the transaction. In such a situation the rule would take precedence. As far as reasoning goes... we could have this evaluation logic at the endpoint service but the flip side is we are anyway evaluating a rule at the intermediary level for monitoring, which would increasing the overall latency, so why not do it at the intermediary level rather than at the endpoint service.Further, the BAM solution then shifts to the Service end and becomes very specific where as the SM BAM way we can generalize it and make it available for more than one service. - Original Message - From: Guillaume Nodet [EMAIL PROTECTED] To: servicemix-dev@geronimo.apache.org Sent: Monday, July 31, 2006 6:11 PM Subject: Re: BAM Component On 7/31/06, Soumadeep-Infravio [EMAIL PROTECTED] wrote: I agree... but in a content based routing too the end result is a path to an application or service etc... though the technology used could be the same but from a BAM perspective the utility factor is effectively greater... Agreed. And be sure that I do not underestimate the need for such easier configuration, though I still think that using endpoint resolution would avoid duplicating code, and allow using any existing BC that support such feature, while keeping a centralized configuration. Maybe I miss something, i would have thought a BAM component would be more about monitoring than embedding business logic with rules: see one definition of BAM at http://www.ebizq.net/topics/bam/features/4689.html -- of course all definitions can be argued ;) - Original Message - From: Guillaume Nodet [EMAIL PROTECTED] To: servicemix-dev@geronimo.apache.org Sent: Monday, July 31, 2006 4:41 PM Subject: Re: BAM Component On 7/31/06, Soumadeep-Infravio [EMAIL PROTECTED] wrote: Thanks Guillaume, comments inline... Thanks Soumadeep - Original Message - From: Guillaume Nodet [EMAIL PROTECTED] To: servicemix-dev@geronimo.apache.org Cc: servicemix-users@geronimo.apache.org Sent: Monday, July 31, 2006 3:14 PM Subject: Re: BAM Component Great, thx a lot ! CCing servicemix-dev, as I think this is the place where this discussion should take place. Do you have any plan / ideas of future features for this component ? Well, to start with we can have 1) Marshaler for various input sources 2) integration with GUI based monitoring applications 3) integration with OpenOffice, where you can directly feed data to a spread sheet template 4) have an intelligence module to monitor usage/evaluation patterns and predict or forcast based on those patterns ... possibilities are infinite... Currently, it seems this that the component is a router with actions. How will it differ from existing content based routers (xpath router, drools component) ? Traditionally, routing is more in terms of providing options for failover, parallel, load balancing etc...techniques not for monitoring and for taking corrective actions it's again restricted to finding a path to a service/app etc nothing more than that. I was talking about content-based routing ;) I also agree with James that we could leverage ServiceMix expressions. But I do agree we can factor out the existing SM Samples code base and use it Another point I am wondering about, is the fact that the component embeds the email code inside an action: i think it would be better to reuse the existing components Yes, our intension is to factor out the common parameters and use a global configuration file which can be referenced. for that, else the BAM component would end up lots of BCs code
[jira] Created: (GERONIMO-2251) Add Proxy variables to geronimo.bat geronimo.sh
Add Proxy variables to geronimo.bat geronimo.sh - Key: GERONIMO-2251 URL: http://issues.apache.org/jira/browse/GERONIMO-2251 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Components: console, Plugins, startup/shutdown Affects Versions: 1.1 Reporter: Aaron Mulder Fix For: 1.1.x Reported by a user whose machine is behind a web proxy: I have tested the setting of the proxy through the JVM and found that the following works when included in the JAVA_OPTS environment variable: -DproxySet=true -DproxyHost=proxy.local -DproxyPort=8080 It would be great to have PROXY_HOST and PROXY_PORT variables in the big list of variables at the front of these scripts, and if the PROXY_HOST is set, turn that into the string of arguments above and append them to JAVA_OPTS. (The proxy would be used for downloading JDBC drivers, browsing and installing plugins, 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
Re: 1.1 keystore portlet bugs patches
Aaron Mulder wrote: Here's the serialization error on shutdown. There are no errors on restart but subsequent shutdowns continue to produce the same error if I navigate to the portlet at all: Looks like it's putting an instance of the KeystoreInstance GBean in the session. We should probably change the code to put some Serializable object in the session that holds the AbstractName for the KeystoreInstance and looks it up again from the kernel every time the portlet needs it. Aaron, It looked to me like were were already looking up the KeystoreInstance GBean on each view request in the portlet (renderView() in ListHandler). Therefore, it seemed like the simpliest fix was to just make the KeystoreInstance transient in the BaseKeystoreHandler.KeystoreData class so that it wouldn't be serialized. I put that change in last week. Please let me know if you see a problem with this. Thanks, Joe
Can't use car-maven-plugin today!
So I tried on a different machine today. If I specify no version number for car-maven-plugin in the POM, I get: [ERROR] BUILD ERROR [INFO] [INFO] The plugin 'org.apache.geronimo.plugins:car-maven-plugin' does not exist or no valid version could be found If I specify the version 1.2-SNAPSHOT, I get: [WARNING] Unable to get resource from repository apache-snapshots (http://people.apache.org/repo/m2-snapshot-repository) Downloading: http://www.ibiblio.org/maven/org.apache.geronimo.plugins/poms/car-maven-plugin-1.2-SNAPSHOT.pom [WARNING] Unable to get resource from repository ibiblio-maven-1 (http://www.ibiblio.org/maven) [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Failed to resolve artifact. GroupId: org.apache.geronimo.plugins ArtifactId: car-maven-plugin Version: 1.2-SNAPSHOT Reason: Unable to download the artifact from any repository Indeed, if I look, there is no org/apache/geronimo/plugins/car-maven-plugin/1.2-SNAPSHOT/car-maven-plugin-1.2-SNAPSHOT.pom in the Apache snapshot repository (http://people.apache.org/repo/m2-snapshot-repository) There is only org/apache/geronimo/plugins/car-maven-plugin/1.2-SNAPSHOT/http://people.apache.org/repo/m2-snapshot-repository/org/apache/geronimo/plugins/car-maven-plugin/1.2-SNAPSHOT/car-maven-plugin-1.2-20060716.224116-1.pom What's up? How am I supposed to use the car-maven-plugin when the version numbers don't match up? (I'm using Maven 2.0.4 on OS X) Thanks, Aaron
Re: BAM Component
Ok, let me explain or we could use URI or endpoint resolution to avoid duplicating some code. Each component must implement the ServiceEndpoint resolveEndpointReference(DocumentFragment epr) method provided by the Component interface. This method takes a DOM fragment as an argument and returns a ServiceEndpoint that can be used as a target for a given JBI exchange. Currently, the only components implementing this method are servicemix-http and servicemix-jms, but future BCs will certainly implement it also. Other components can query for such dynamic endpoints by using ComponentContext.resolveEndpointReference. The current implementation can recognized a WS-Addressing EPR and returns a custom ServiceEndpoint. When an exchange using such an endpoint, the servicemix-http component will create a dynamic HttpEndpoint and use the uri to configure it. Hence the http.soap=true parameter on the URI. All properties can be configured this way, so the main benefit is that using only the JBI api, you can eaily leverage all existing BCs. I think the BAM component should implement an Adaptor, which would use such URIs to resolve EPRs so that it can send exchange to all known protocols. The endpoint reolution mechanism could be enhanced, if URIs are not sufficient, to allow other xml fragment to be resolved. Of course, this would not work currently for email, as there is no standard JBI BC handling smtp, but this should be done in the future. That way, you could have the following configuration, Adaptor name=org.apache.sm.URISender uri value=smtp://mail.webmail.org?from= [EMAIL PROTECTED][EMAIL PROTECTED];[EMAIL PROTECTED]message=There is a new quotation coming your way!! / /Adaptor The URI can be a bit complex in such a case, that' s why the endpoint resolution could be enhanced to recognize a specific syntax. Adaptor name=org.apache.sm.EPRSender smtp:epr xmlns:smtp=xxx smtp:host name=mail.webmail.org smtp:from address=[EMAIL PROTECTED] smtp:to [EMAIL PROTECTED];[EMAIL PROTECTED] smtp:message value=There is a new quotation coming your way!! /smtp /Adaptor The main difference with the existing implementation is that all smtp related code would be in the SMTP BC. It would be given the whole smtp:epr / tag to resolve, return a ServiceEndpoint which would be used as the target of the jbi exchange. This way, all SMTP related code remains under the control of the SMTP BC :) On 7/31/06, Soumadeep-Infravio [EMAIL PROTECTED] wrote: I guess for now let's stick to the passive mode and delegate the processing, based on an event. Let me know -from a birds eye view if this is OK. 1) we passively sniff data from payloads 2) evaluate the xpath based expression(reuse what is available in SM) 3) delegate the processing to some adaptor (or reuse what is available in SM) 4) provide configuration files for global,rule and actions - or reuse the existing URI based code (do let us know how you want to reuse it) Thanks Soumadeep - Original Message - From: Soumadeep-Infravio [EMAIL PROTECTED] To: servicemix-dev@geronimo.apache.org Sent: Monday, July 31, 2006 7:36 PM Subject: Re: BAM Component I agree...about reusability. Regarding the concepts of BAM I guess there has been a lot of debate on this... Here is the trade off - from a use case perspective : 1) Passive - where we just sniff the data without hindering the process and delegate the processing depending on an event. - pure monitoring mode. 2) Active - where the evaluation takes place and depending on the situation the process is terminated because of an evaluation exception. Say for example : I set up a rule which says that if the order value is more than $5000 then switch to async mode because the retailer doesn't keep stock more than $1000 and can't handle the transaction. In such a situation the rule would take precedence. As far as reasoning goes... we could have this evaluation logic at the endpoint service but the flip side is we are anyway evaluating a rule at the intermediary level for monitoring, which would increasing the overall latency, so why not do it at the intermediary level rather than at the endpoint service.Further, the BAM solution then shifts to the Service end and becomes very specific where as the SM BAM way we can generalize it and make it available for more than one service. - Original Message - From: Guillaume Nodet [EMAIL PROTECTED] To: servicemix-dev@geronimo.apache.org Sent: Monday, July 31, 2006 6:11 PM Subject: Re: BAM Component On 7/31/06, Soumadeep-Infravio [EMAIL PROTECTED] wrote: I agree... but in a content based routing too the end result is a path to an application or service etc... though the technology used could be the same but from a BAM perspective the utility factor is
Re: BAM Component
Looks great to me! :) On 7/31/06, Guillaume Nodet [EMAIL PROTECTED] wrote: Ok, let me explain or we could use URI or endpoint resolution to avoid duplicating some code. Each component must implement the ServiceEndpoint resolveEndpointReference(DocumentFragment epr) method provided by the Component interface. This method takes a DOM fragment as an argument and returns a ServiceEndpoint that can be used as a target for a given JBI exchange. Currently, the only components implementing this method are servicemix-http and servicemix-jms, but future BCs will certainly implement it also. Other components can query for such dynamic endpoints by using ComponentContext.resolveEndpointReference. The current implementation can recognized a WS-Addressing EPR and returns a custom ServiceEndpoint. When an exchange using such an endpoint, the servicemix-http component will create a dynamic HttpEndpoint and use the uri to configure it. Hence the http.soap=true parameter on the URI. All properties can be configured this way, so the main benefit is that using only the JBI api, you can eaily leverage all existing BCs. I think the BAM component should implement an Adaptor, which would use such URIs to resolve EPRs so that it can send exchange to all known protocols. The endpoint reolution mechanism could be enhanced, if URIs are not sufficient, to allow other xml fragment to be resolved. Of course, this would not work currently for email, as there is no standard JBI BC handling smtp, but this should be done in the future. That way, you could have the following configuration, Adaptor name=org.apache.sm.URISender uri value=smtp://mail.webmail.org?from= [EMAIL PROTECTED][EMAIL PROTECTED];[EMAIL PROTECTED]message=There is a new quotation coming your way!! / /Adaptor The URI can be a bit complex in such a case, that' s why the endpoint resolution could be enhanced to recognize a specific syntax. Adaptor name=org.apache.sm.EPRSender smtp:epr xmlns:smtp=xxx smtp:host name=mail.webmail.org smtp:from address=[EMAIL PROTECTED] smtp:to [EMAIL PROTECTED];[EMAIL PROTECTED] smtp:message value=There is a new quotation coming your way!! /smtp /Adaptor The main difference with the existing implementation is that all smtp related code would be in the SMTP BC. It would be given the whole smtp:epr / tag to resolve, return a ServiceEndpoint which would be used as the target of the jbi exchange. This way, all SMTP related code remains under the control of the SMTP BC :) On 7/31/06, Soumadeep-Infravio [EMAIL PROTECTED] wrote: I guess for now let's stick to the passive mode and delegate the processing, based on an event. Let me know -from a birds eye view if this is OK. 1) we passively sniff data from payloads 2) evaluate the xpath based expression(reuse what is available in SM) 3) delegate the processing to some adaptor (or reuse what is available in SM) 4) provide configuration files for global,rule and actions - or reuse the existing URI based code (do let us know how you want to reuse it) Thanks Soumadeep - Original Message - From: Soumadeep-Infravio [EMAIL PROTECTED] To: servicemix-dev@geronimo.apache.org Sent: Monday, July 31, 2006 7:36 PM Subject: Re: BAM Component I agree...about reusability. Regarding the concepts of BAM I guess there has been a lot of debate on this... Here is the trade off - from a use case perspective : 1) Passive - where we just sniff the data without hindering the process and delegate the processing depending on an event. - pure monitoring mode. 2) Active - where the evaluation takes place and depending on the situation the process is terminated because of an evaluation exception. Say for example : I set up a rule which says that if the order value is more than $5000 then switch to async mode because the retailer doesn't keep stock more than $1000 and can't handle the transaction. In such a situation the rule would take precedence. As far as reasoning goes... we could have this evaluation logic at the endpoint service but the flip side is we are anyway evaluating a rule at the intermediary level for monitoring, which would increasing the overall latency, so why not do it at the intermediary level rather than at the endpoint service.Further, the BAM solution then shifts to the Service end and becomes very specific where as the SM BAM way we can generalize it and make it available for more than one service. - Original Message - From: Guillaume Nodet [EMAIL PROTECTED] To: servicemix-dev@geronimo.apache.org Sent: Monday, July 31, 2006 6:11 PM Subject: Re: BAM Component On 7/31/06, Soumadeep-Infravio [EMAIL PROTECTED] wrote: I agree... but in a content based routing too the end result
Re: 1.1 keystore portlet bugs patches
OK, so long as it gets looked up again if it was nulled out due to being serialized and deserialized. Thanks, Aaron On 7/31/06, Joe Bohn [EMAIL PROTECTED] wrote: Aaron Mulder wrote: Here's the serialization error on shutdown. There are no errors on restart but subsequent shutdowns continue to produce the same error if I navigate to the portlet at all: Looks like it's putting an instance of the KeystoreInstance GBean in the session. We should probably change the code to put some Serializable object in the session that holds the AbstractName for the KeystoreInstance and looks it up again from the kernel every time the portlet needs it. Aaron, It looked to me like were were already looking up the KeystoreInstance GBean on each view request in the portlet (renderView() in ListHandler). Therefore, it seemed like the simpliest fix was to just make the KeystoreInstance transient in the BaseKeystoreHandler.KeystoreData class so that it wouldn't be serialized. I put that change in last week. Please let me know if you see a problem with this. Thanks, Joe
Re: 1.1.1 Status 2006/07/31
On Jul 31, 2006, at 10:45 AM, Matt Hogstrom wrote: Hey everyone, We're almost there for 1.1.1. I noticed that people are opeening new JIRA's for 1.1.1 which is great. However, unless you feel you can get them done before the cut off time please put them in 1.x or 1.2. I plan on moving all outstanding JIRAs as of the cut off time to the next release. Alan rightly pointed out a few day slip. We can easily start a 1.1.2 if people have critical fixes they want to get in. The branch time remains at *Tuesday, August 1 at 0500 PT*. On or around this time I will do an SVN copy to branches/1.1.1 and we'll start the final testing, TCK, etc. with the goal to get this out next week. I announced this time on Friday. Comments welcome :) Sounds good. I'm currently working on TCK issues. I've moved one of my 1.1.1 Jira's to 1.1.x. Problem needs to be fixed, but can be fixed later. Apps can easily (and ought to) avoid the problem by closing any Resources they've opened. The other two 1.1.1 Jira's that are assigned to me are issues having to do with the release process. They can be addressed as we're releasing 1.1.1. --kevan
Re: VMware on GBuild?
Just back online after OSCON. Reading/replying on this thread one at a time. On Jul 28, 2006, at 10:21 AM, Aaron Mulder wrote: I'm interested in setting up VMware Server on my GBuild boxes, since my understanding is that the TCK is pretty single-threaded and we ought to get better utilization out of the (dual-CPU) machines if we ran the host plus one VM or just two VMs (and forget about the host) on each box. I've been wanting to try that as well. Pretty much for the same reasons you mention (more utilization, more test results), and also that we could maybe start getting certification numbers for other OSs depending on how we did it. Obviously, the other OS concept would require VMWare whereas we might get away with just Xen if we simply wanted to expand our number of test hosts. It sounds like memory might be the constraining feature -- my boxes have 1.5, 2, and 4 GB respectively and I wonder whether splitting the smaller ones in half would leave enough RAM for the TCK to run. Would 512 or 768 be enough? To my memory, 512 isn't enough. I seem to recall 1g being the general, finger in the wind, of size. We could experiment as it has been a while and our server has changed a bit. The other question is IPs. I only have 3 IPs. Is there any way for me to put all the boxes/VMs behind a NAT and have them share 1 IP with various port forwards, or do they really need to each have a public IP? Testing boxes don't need public IPs to test, we just need some way to get in to admin the box. As long as we can do that we're golden; forwarding or tunneling should work. -David
Re: VMware on GBuild?
On Jul 28, 2006, at 11:17 AM, Jason Dillon wrote: If I thought it was going to be possible to have multiple TCKs running simultaneously, I would, but that seems to be such a massive undertaking that I'm not willing to do it myself. Do you think it's easier than I'm speculating? How hard could it be? Change some port numbers... run from a different directory? Sounds like you're volunteering :) -David
Re: VMware on GBuild?
On Jul 28, 2006, at 11:41 AM, Aaron Mulder wrote: On 7/28/06, Jason Dillon [EMAIL PROTECTED] wrote: I'm no expert on how the TCK runs, but I do not believe that you need a public IP. Though, with out a public IP, we can't use Cacti to monitor the hosts, or ssh to them directly to admin them... but if you dedicate one host as a gateway then we can get past that... and might even be able to setup port forwarding for SNMP/Cacti monitoring. If there is any other issue that requires a public IP I am not aware of it... and we should remove the need for it if one exists. How does the GBuild master communicate with the GBuild slaves? Is it all pull from the slaves? So far, 100% of master/slave communication is over JMS with no port requirements for the slave. It just needs to be able to connect to the master's broker. -David
Re: Pessimistic locking strategy for CMP beans in 1.1.1
I'm not sure this will cover the common strategies used by most containers. I recall implementing a few different strategies in another appserver: o DB auto update sequence o Container manual update sequence o DB last modified timestamp column o Container manual update sequence (unreliable but people use it) o Check column values haven't changed between select an update o All columns o Some special columns o Only columns being updated o All columns that were read in during the tx I doubt we need all of these, but I think we should allow room for growth in the schema. -dain On Jul 31, 2006, at 7:38 AM, Matt Hogstrom wrote: Perhaps one additional element in the optimistic section like: concurrency-control[DATABASE | CONTAINER]/concurrency-control Dain Sundstrom wrote: +1 looks good On Jul 26, 2006, at 7:47 PM, Matt Hogstrom wrote: locking-strategy optimistic-locking optimistic-columnoccColumn/optimistic-column optimistic-typeTIMESTAMP/optimistic-type /locking-strategy one comment... this xml implies that the database is handling the auto increment/update of the optimistic lock column. I have seen schemas that assume that the application code will be handling this, with some sql like this: UPDATE foo SET value = newValue, ver = 5 WHERE pk = myPk AND ver = 4 If the database is auto updating the row, you will need to reread the column after any update, so if you make another update in the same transaction, you can assure you know the current value of the optimistic column. -dain
[jira] Updated: (GERONIMO-2167) deployer.jar not cleaning up properly during redeploy and undeploy
[ http://issues.apache.org/jira/browse/GERONIMO-2167?page=all ]
Kevan Miller updated GERONIMO-2167:
---
Fix Version/s: 1.1.x
(was: 1.1.1)
Affects Version/s: 1.1.1
1.1.x
1.2
I haven't gotten enough time to fix this problem and I'm hesitant to mess with
the ClassLoader this close to a release. So, unless things go extremely well
the next two days, I'll fix in 1.1.x.
This problem can be avoided by having an application clean up the resources
that it opens (which is pretty good practice).
deployer.jar not cleaning up properly during redeploy and undeploy
--
Key: GERONIMO-2167
URL: http://issues.apache.org/jira/browse/GERONIMO-2167
Project: Geronimo
Issue Type: Bug
Security Level: public(Regular issues)
Components: deployment
Affects Versions: 1.2, 1.1, 1.1.1, 1.1.x
Environment: Win32/XP SP1
Sun JDK 1.5_06
Reporter: Leonard Wu
Assigned To: Kevan Miller
Fix For: 1.1.x
Attachments: dwr-demo.war, jw-0620-dwr.zip
deployment using deploy.jar doesn't appear to clean up correctly.
first deploy always works. subsequent re-deploy and un-deploy are problematic.
following illustrates the full sequence of events as i had encountered:
--
D:\work\SERVER\geronimo-1.1\binc:\JDK\jdk1.5.0_06\bin\java.exe -jar
deployer.ja
r --user system --password manager deploy D:/work/SERVER/dwr-demo.war
Deployed littleoldme/dwrdemo/1.1/war @ http://vaio:8080/dwr-demo
D:\work\SERVER\geronimo-1.1\binc:\JDK\jdk1.5.0_06\bin\java.exe -jar
deployer.ja
r --user system --password manager redeploy D:/work/SERVER/dwr-demo.war
No ModuleID or TargetModuleID provided. Attempting to guess based
on the content of the archive.
Attempting to use ModuleID 'littleoldme/dwrdemo/1.1/war'
Stopped littleoldme/dwrdemo/1.1/war
Unloaded littleoldme/dwrdemo/1.1/war
Uninstalled littleoldme/dwrdemo/1.1/war
Deployed littleoldme/dwrdemo/1.1/war
Started littleoldme/dwrdemo/1.1/war
Redeployed littleoldme/dwrdemo/1.1/war
D:\work\SERVER\geronimo-1.1\binc:\JDK\jdk1.5.0_06\bin\java.exe -jar
deployer.ja
r --user system --password manager redeploy D:/work/SERVER/dwr-demo.war
No ModuleID or TargetModuleID provided. Attempting to guess based
on the content of the archive.
Attempting to use ModuleID 'littleoldme/dwrdemo/1.1/war'
Stopped littleoldme/dwrdemo/1.1/war
Unloaded littleoldme/dwrdemo/1.1/war
Uninstalled littleoldme/dwrdemo/1.1/war
Error: Operation failed:
org.apache.geronimo.kernel.config.ConfigurationAlreadyExistsException:
Configuration already exists: littleoldme/dwrdemo/1.1/war
Configuration already exists: littleoldme/dwrdemo/1.1/war
D:\work\SERVER\geronimo-1.1\binc:\JDK\jdk1.5.0_06\bin\java.exe -jar
deployer.ja
r --user system --password manager undeploy littleoldme/dwrdemo/1.1/war
Error: littleoldme/dwrdemo/1.1/war does not appear to be a the name
of a module available on the selected server. Perhaps it has already
been stopped or undeployed? If you're trying to specify a
TargetModuleID, use the syntax TargetName|ModuleName instead. If
you're not sure what's running, try the list-modules command.
--
While in this broken state, i'm able to recover by manually removing the
${geronimo}/repository/littleoldme directory and removing the one line in
${geronimo}/var/config/config.xml that says
module load=false name=littleoldme/dwrdemo/1.1/war/
However, this only gets me to a fresh beginning, and then the whole sequence
starts again as I repeat (re/un)deploying.
--
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-2252) A locked key in a keystore can never be unlocked.
A locked key in a keystore can never be unlocked. - Key: GERONIMO-2252 URL: http://issues.apache.org/jira/browse/GERONIMO-2252 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Components: console, security Affects Versions: 1.1, 1.1.1, 1.2 Environment: windows xp jetty and tomcat Reporter: Joe Bohn Assigned To: Joe Bohn Fix For: 1.1.1, 1.2 Once the key of a keystore has been locked it can never be unlocked. This is because the password stored in the gbean attribute is incorrectly being stored as the string representation of the charater array rather than the value of the character array itself. Thanks to Vamsavardhana Reddy for finding the root cause of this problem in FileKeystoreInstance.storePasswords(). -- 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: VMware on GBuild?
On Jul 31, 2006, at 12:46 PM, David Blevins wrote: Just back online after OSCON. Reading/replying on this thread one at a time. On Jul 28, 2006, at 10:21 AM, Aaron Mulder wrote: I'm interested in setting up VMware Server on my GBuild boxes, since my understanding is that the TCK is pretty single-threaded and we ought to get better utilization out of the (dual-CPU) machines if we ran the host plus one VM or just two VMs (and forget about the host) on each box. I've been wanting to try that as well. Pretty much for the same reasons you mention (more utilization, more test results), and also that we could maybe start getting certification numbers for other OSs depending on how we did it. Obviously, the other OS concept would require VMWare whereas we might get away with just Xen if we simply wanted to expand our number of test hosts. It sounds like memory might be the constraining feature -- my boxes have 1.5, 2, and 4 GB respectively and I wonder whether splitting the smaller ones in half would leave enough RAM for the TCK to run. Would 512 or 768 be enough? To my memory, 512 isn't enough. I seem to recall 1g being the general, finger in the wind, of size. We could experiment as it has been a while and our server has changed a bit. Currently, we're running w/ min heap of 512 Megs and max of 1024. No idea if we can get by with less... May be a toss up as to whether we're processor or memory constrained... Currently, I'm much more interested in increasing test throughput rather than testing multiple OS's. So, Xen could be an option. However, if VMware gives us options for both, then that seems great. --kevan The other question is IPs. I only have 3 IPs. Is there any way for me to put all the boxes/VMs behind a NAT and have them share 1 IP with various port forwards, or do they really need to each have a public IP? Testing boxes don't need public IPs to test, we just need some way to get in to admin the box. As long as we can do that we're golden; forwarding or tunneling should work. -David
[jira] Resolved: (GERONIMO-2252) A locked key in a keystore can never be unlocked.
[ http://issues.apache.org/jira/browse/GERONIMO-2252?page=all ] Joe Bohn resolved GERONIMO-2252. Resolution: Fixed fixed in geronimo 1.1.1 Sending modules\security\src\java\org\apache\geronimo\security\keystore\FileKeystoreInstance.java Transmitting file data . Committed revision 427183. and trunk Sending modules\security\src\java\org\apache\geronimo\security\keystore\FileKeystoreInstance.java Transmitting file data . Committed revision 427184. A locked key in a keystore can never be unlocked. - Key: GERONIMO-2252 URL: http://issues.apache.org/jira/browse/GERONIMO-2252 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: console, security Affects Versions: 1.1, 1.1.1, 1.2 Environment: windows xp jetty and tomcat Reporter: Joe Bohn Assigned To: Joe Bohn Fix For: 1.1.1, 1.2 Once the key of a keystore has been locked it can never be unlocked. This is because the password stored in the gbean attribute is incorrectly being stored as the string representation of the charater array rather than the value of the character array itself. Thanks to Vamsavardhana Reddy for finding the root cause of this problem in FileKeystoreInstance.storePasswords(). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: 1.1.1 Status
I'm fine with both items. Joe John Sisson wrote: Any objections to removing the licenses from the about page in the console. See GERONIMO-2136 (listed below) FYI, I was originally planning on upgrading Derby (*GERONIMO-2155 https://issues.apache.org/jira/browse/GERONIMO-2155)*, but the debug versions of the derby libraries aren't in the maven repos and I'm running out of time, so will leave as targeted for 1.x. Thanks, John Matt Hogstrom wrote: There has been a lot of progress on 1.1.1. We started with 61 issues and we're down to 21 left. Originally I suggested that we branch on Friday. I'd like to give a little more time and would like to revise the branch to a freeze state on Tuesday, August 1 at 0500 PT. At that time I'll spin off branches/1.1.1 and update branches/1.1 to be 1.1.2-SNAPSHOT. We'll do performance regression and TCK work during the next week and shoot for an official release within two weeks. If anyone is opposed to this plan let me know. Also, please review the JIRA's below. If you don't think you can get thte ones done with your name please unassign yourself and hopefully someone else will pick them up. Thanks. *Outstanding Issues* GERONIMO- Open John Sisson Application errors in static initialization blocks during serialization of configuration during deployment due to incorrect TCCL GERONIMO-2218 Open Unassigned KeyStore portlet: Functionality missing from 1.0 GERONIMO-1906 Reopened Sachin Patel Cannot add a new connector using ActiveMQManagerGBean GERONIMO-1917 Open David Jencks repository doesn't deal well with case insensitive file systems GERONIMO-1996 Open John Sisson Serialization failure during deployment leaves a config.ser in the repository but doesn't write a config.info causing problems later. GERONIMO-2080 Open John Sisson Create a Geronimo Bug Guidelines Page GERONIMO-2169 Open Kevan Miller Once tagged, the m:co goal of tags/1.1.1 should checkout the corresponding tagged version of OpenEJB (not a branch) GERONIMO-2170 Open Kevan Miller Tagged versions of Geronimo should not include people.apache.org/repository in their list of maven repositories GERONIMO-2167 Open Kevan Miller deployer.jar not cleaning up properly during redeploy and undeploy GERONIMO-2202 Open Kevan Miller Move to new Apache Maven 1 repo (repo/m1-snapshot-repository 1.2 GERONIMO-2030 Open Unassigned Allow WebServiceBuilder determine if there are WebServices to be deployed GERONIMO-1476 Open Unassigned Changes to default log4j.rootCategory are not dynamic GERONIMO-2228 Open Unassigned GeronimoAsMavenServlet.java generates wrong default-repository element GERONIMO-2230 Open Aaron Mulder No cleanup after DeploymentWatcher exception GERONIMO-2142 Open David Jencks EJB Refs to EJB in parent module often fail GERONIMO-2227 Open David Jencks ENC Lookup Fix (include parent modules) GERONIMO-1557 Open David Jencks When you enter the url of a web service in the console You should get a page showing the service name GERONIMO-1531 Open Unassigned KeyStore portlet should support deletion of certificates and private keys GERONIMO-1716 Open Donald Woods Add usage of SimpleEncryption to PropertiesFileLoginModule and Admin Console GERONIMO-2204 Open David Jencks ProxyMethodInterceptor doesn't handle finalize appropriately GERONIMO-2136 Open John Sisson Remove/Update licenses displayed in about page of console GERONIMO-1810 Open John Sisson Improve the Error: Unable to distribute foo.ear: Cannot deploy the requested application module message
Re: critical jetty keystore problems on 1.1.1
Just an update on this problem. There is still a problem with the locking (esp. in jetty) due to multiple attributes (containing both the password value and null) for the keystorePassword and keyPasswords. However, with the fix just integrated for GERONIMO-2252 we at least have some recovery plan (modify the config.xml to remove the null entries and the remain stored entries will correctly unlock the keys). Thanks to Vamsavardhana Reddy for finding the root cause of why the passwords were being stored incorrectly. Now we just need to figure out why we're ending up with multiple entries in config.xml for the same attributes. Joe Joe Bohn wrote: I'm still trying to figure out some critical problems with the keystore processing on jetty. The most serious problem that I've yet to resolve is a problem with the lock/unlock of the keystore availability lock. A subsequent server restart will fail because Keystore 'geronimo-default' is locked. It appears that we cannot recover from this error either. Even if I change the config.xml for SSLConnector to load=false, restart the server, unlock the keystore/key (again) I still get the same failure when I attempt to start with the SSLConnector enabled. At first I thought this was because of the duplicate attribute entries referenced in an earlier post. In fact, I'm pretty sure that I edited the config.xml to remove the null entries and was able to get the server started. However, I have recently been unable to recover from this error using the same mechanism. In fact it seems to create more problems because after removing the null entries I now get an UnrecoverableKeyException. Any advice or recommendations? I'm beginning to wonder if we should disable the keystore portlet for 1.1.1 so that the user can't shoot himself in the foot. Joe
[jira] Assigned: (GERONIMO-2240) Memory leak in DWR memory viewer info screen in console
[ http://issues.apache.org/jira/browse/GERONIMO-2240?page=all ] Kevan Miller reassigned GERONIMO-2240: -- Assignee: Kevan Miller Memory leak in DWR memory viewer info screen in console --- Key: GERONIMO-2240 URL: http://issues.apache.org/jira/browse/GERONIMO-2240 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: console Affects Versions: 1.1.1 Environment: Windows Reporter: Jeff Genender Assigned To: Kevan Miller Priority: Critical Fix For: 1.1.1 After leaving the console up on the serverinfo screen which contains the DWR AJAX component for 25 minutes, Geronimo fails with an OutOfMemory Error: 16:01:01,790 WARN [ExecuteQuery] Method execution failed: net.sf.cglib.core.CodeGenerationException: java.lang.reflect.InvocationTargetException--null at net.sf.cglib.core.AbstractClassGenerator.create(AbstractClassGenerator.java:237) at net.sf.cglib.proxy.Enhancer.createHelper(Enhancer.java:377) at net.sf.cglib.proxy.Enhancer.createClass(Enhancer.java:317) at org.apache.geronimo.kernel.basic.BasicProxyManager$ManagedProxyFactory.init(BasicProxyManager.java:206) at org.apache.geronimo.kernel.basic.BasicProxyManager.createProxyFactory(BasicProxyManager.java:81) at org.apache.geronimo.kernel.basic.BasicProxyManager.createProxy(BasicProxyManager.java:106) at org.apache.geronimo.console.util.KernelManagementHelper.getDomains(KernelManagementHelper.java:96) at org.apache.geronimo.console.jsr77.Jsr77Lookup.getJavaVMStatistics(Jsr77Lookup.java:39) at sun.reflect.GeneratedMethodAccessor446.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at uk.ltd.getahead.dwr.impl.ExecuteQuery.execute(ExecuteQuery.java:239) at uk.ltd.getahead.dwr.impl.DefaultExecProcessor.handle(DefaultExecProcessor.java:48) at uk.ltd.getahead.dwr.impl.DefaultProcessor.handle(DefaultProcessor.java:81) at uk.ltd.getahead.dwr.AbstractDWRServlet.doPost(AbstractDWRServlet.java:162) at javax.servlet.http.HttpServlet.service(HttpServlet.java:615) at javax.servlet.http.HttpServlet.service(HttpServlet.java:688) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173) at org.apache.geronimo.console.servlet.ForwardDispatchFilter.doFilter(ForwardDispatchFilter.java:59) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173) at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:672) at org.apache.catalina.core.ApplicationDispatcher.processRequest(ApplicationDispatcher.java:463) at org.apache.catalina.core.ApplicationDispatcher.doForward(ApplicationDispatcher.java:398) at org.apache.catalina.core.ApplicationDispatcher.forward(ApplicationDispatcher.java:301) at org.apache.geronimo.console.servlet.ContextForwardServlet.doPost(ContextForwardServlet.java:71) at javax.servlet.http.HttpServlet.service(HttpServlet.java:615) at javax.servlet.http.HttpServlet.service(HttpServlet.java:688) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:178) at org.apache.geronimo.tomcat.valve.DefaultSubjectValve.invoke(DefaultSubjectValve.java:52) at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:524) at org.apache.geronimo.tomcat.GeronimoStandardContext$SystemMethodValve.invoke(GeronimoStandardContext.java:342) at org.apache.geronimo.tomcat.valve.GeronimoBeforeAfterValve.invoke(GeronimoBeforeAfterValve.java:31) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107) at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:541)
Re: BAM Component
Let me give it a shot... - Original Message - From: Guillaume Nodet [EMAIL PROTECTED] To: servicemix-dev@geronimo.apache.org Sent: Monday, July 31, 2006 9:35 PM Subject: Re: BAM Component Ok, let me explain or we could use URI or endpoint resolution to avoid duplicating some code. Each component must implement the ServiceEndpoint resolveEndpointReference(DocumentFragment epr) method provided by the Component interface. This method takes a DOM fragment as an argument and returns a ServiceEndpoint that can be used as a target for a given JBI exchange. Currently, the only components implementing this method are servicemix-http and servicemix-jms, but future BCs will certainly implement it also. Other components can query for such dynamic endpoints by using ComponentContext.resolveEndpointReference. The current implementation can recognized a WS-Addressing EPR and returns a custom ServiceEndpoint. When an exchange using such an endpoint, the servicemix-http component will create a dynamic HttpEndpoint and use the uri to configure it. Hence the http.soap=true parameter on the URI. All properties can be configured this way, so the main benefit is that using only the JBI api, you can eaily leverage all existing BCs. I think the BAM component should implement an Adaptor, which would use such URIs to resolve EPRs so that it can send exchange to all known protocols. The endpoint reolution mechanism could be enhanced, if URIs are not sufficient, to allow other xml fragment to be resolved. Of course, this would not work currently for email, as there is no standard JBI BC handling smtp, but this should be done in the future. That way, you could have the following configuration, Adaptor name=org.apache.sm.URISender uri value=smtp://mail.webmail.org?from= [EMAIL PROTECTED][EMAIL PROTECTED];[EMAIL PROTECTED]message=There is a new quotation coming your way!! / /Adaptor The URI can be a bit complex in such a case, that' s why the endpoint resolution could be enhanced to recognize a specific syntax. Adaptor name=org.apache.sm.EPRSender smtp:epr xmlns:smtp=xxx smtp:host name=mail.webmail.org smtp:from address=[EMAIL PROTECTED] smtp:to [EMAIL PROTECTED];[EMAIL PROTECTED] smtp:message value=There is a new quotation coming your way!! /smtp /Adaptor The main difference with the existing implementation is that all smtp related code would be in the SMTP BC. It would be given the whole smtp:epr / tag to resolve, return a ServiceEndpoint which would be used as the target of the jbi exchange. This way, all SMTP related code remains under the control of the SMTP BC :) On 7/31/06, Soumadeep-Infravio [EMAIL PROTECTED] wrote: I guess for now let's stick to the passive mode and delegate the processing, based on an event. Let me know -from a birds eye view if this is OK. 1) we passively sniff data from payloads 2) evaluate the xpath based expression(reuse what is available in SM) 3) delegate the processing to some adaptor (or reuse what is available in SM) 4) provide configuration files for global,rule and actions - or reuse the existing URI based code (do let us know how you want to reuse it) Thanks Soumadeep - Original Message - From: Soumadeep-Infravio [EMAIL PROTECTED] To: servicemix-dev@geronimo.apache.org Sent: Monday, July 31, 2006 7:36 PM Subject: Re: BAM Component I agree...about reusability. Regarding the concepts of BAM I guess there has been a lot of debate on this... Here is the trade off - from a use case perspective : 1) Passive - where we just sniff the data without hindering the process and delegate the processing depending on an event. - pure monitoring mode. 2) Active - where the evaluation takes place and depending on the situation the process is terminated because of an evaluation exception. Say for example : I set up a rule which says that if the order value is more than $5000 then switch to async mode because the retailer doesn't keep stock more than $1000 and can't handle the transaction. In such a situation the rule would take precedence. As far as reasoning goes... we could have this evaluation logic at the endpoint service but the flip side is we are anyway evaluating a rule at the intermediary level for monitoring, which would increasing the overall latency, so why not do it at the intermediary level rather than at the endpoint service.Further, the BAM solution then shifts to the Service end and becomes very specific where as the SM BAM way we can generalize it and make it available for more than one service. - Original Message - From: Guillaume Nodet [EMAIL PROTECTED] To: servicemix-dev@geronimo.apache.org Sent: Monday, July 31, 2006 6:11 PM Subject: Re: BAM Component On 7/31/06, Soumadeep-Infravio [EMAIL
[jira] Resolved: (SM-502) *ProviderProcessor in servicemix-jms overwrites the MimeMessage content-type with the one from the incoming normalizedmessage
[ https://issues.apache.org/activemq/browse/SM-502?page=all ]
Guillaume Nodet resolved SM-502.
Fix Version/s: 3.0-M3
(was: 3.0)
Resolution: Fixed
Assignee: Guillaume Nodet
Author: gnodet
Date: Mon Jul 31 11:25:00 2006
New Revision: 427192
URL: http://svn.apache.org/viewvc?rev=427192view=rev
Log:
SM-502: ProviderProcessor in servicemix-jms overwrites the MimeMessage
content-type with the one from the incoming normalizedmessage
Patch provided by Renaud Bruyeron
Modified:
incubator/servicemix/trunk/servicemix-jms/src/main/java/org/apache/servicemix/jms/multiplexing/MultiplexingProviderProcessor.java
incubator/servicemix/trunk/servicemix-jms/src/main/java/org/apache/servicemix/jms/standard/StandardProviderProcessor.java
*ProviderProcessor in servicemix-jms overwrites the MimeMessage content-type
with the one from the incoming normalizedmessage
-
Key: SM-502
URL: https://issues.apache.org/activemq/browse/SM-502
Project: ServiceMix
Issue Type: Bug
Components: servicemix-jms
Affects Versions: 3.0-M1, 3.0-M2, 3.0, 3.0-M3
Reporter: Renaud Bruyeron
Assigned To: Guillaume Nodet
Fix For: 3.0-M3
Attachments: patch.txt
The problem (MultiplexingProviderProcessor in servicemix-jms):
Message msg = session.createTextMessage(baos.toString());
msg.setStringProperty(Content-Type, writer.getContentType());
Map headers = (Map) nm.getProperty(JbiConstants.PROTOCOL_HEADERS);
if (headers != null) {
for (Iterator it = headers.keySet().iterator(); it.hasNext();) {
String name = (String) it.next();
String value = (String) headers.get(name);
msg.setStringProperty(name, value);
}
}
This means that any Content-Type header in the PROTOCOL_HEADERS will
overwrite the one set line 176.
The problem manifests itself when sending a SAAJ (SOAP with attachments)
request into an http:endpoint proxying a jms:endpoint provider endpoint. In
the resulting JMS message, the content-type is the original content-type but
it should be the new content-type computed by the SoapWriter: this bug
renders the JMS message content unusable.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://issues.apache.org/activemq/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (AMQ-853) Make BrokerFactoryBean use pre-existing app context as parent
Make BrokerFactoryBean use pre-existing app context as parent - Key: AMQ-853 URL: https://issues.apache.org/activemq/browse/AMQ-853 Project: ActiveMQ Issue Type: Improvement Components: Broker Affects Versions: 4.1 Reporter: Jason Carreira Fix For: 4.1 I've made a local enhancement to the BrokerFactoryBean to make it where your activeMQ XML configuration files refer to beans configured in your Spring application context. Basically I just made the BrokerFactoryBean implement ApplicationContextAware so the ApplicationContext will be set, then in afterPropertiesSet() when it's creating the context for the config resource location, it does this: context = new ResourceXmlApplicationContext(config, applicationContext) passing in the Spring application context as the parent application context for the ResourceXmlApplicationContext. I did this for myself so I could use the same DataSource as the backing DataSource for JDBC persistence. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (GERONIMO-2218) KeyStore portlet: Functionality missing from 1.0
[ http://issues.apache.org/jira/browse/GERONIMO-2218?page=all ] Vamsavardhana Reddy updated GERONIMO-2218: -- Attachment: GERONIMO-2218-with-unlockkey-new.patch GERONIMO-2218-with-unlockkey-new.patch: Includes GERONIMO-2218-with-unlockkey.patch and fixes one error in UnlockKeyHandler.java KeyStore portlet: Functionality missing from 1.0 - Key: GERONIMO-2218 URL: http://issues.apache.org/jira/browse/GERONIMO-2218 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: console Affects Versions: 1.1, 1.1.1 Environment: Win XP, Sun JDK1.4.2_08 Reporter: Vamsavardhana Reddy Assigned To: Joe Bohn Priority: Critical Fix For: 1.1.1 Attachments: GERONIMO-2218-with-unlockkey-new.patch, GERONIMO-2218-with-unlockkey.patch, GERONIMO-2218.patch Functionality missing from AG1.0 includes 1. Ability to view Trusted Certificate and Private Key Entry details 2. Ability to generate CertificateRequests 3. Ability to import CA reply The 2nd and 3rd functions from above are most important and without these the portlet is of very less (or no) use in any practical scenario. -- 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: (SM-501) ServiceMix Ant tasks: accept URL for file
[ https://issues.apache.org/activemq/browse/SM-501?page=all ] Guillaume Nodet resolved SM-501. Fix Version/s: 3.0-M3 Resolution: Fixed Assignee: Guillaume Nodet Author: gnodet Date: Mon Jul 31 11:49:01 2006 New Revision: 427204 URL: http://svn.apache.org/viewvc?rev=427204view=rev Log: SM-501: ServiceMix Ant tasks: accept URL for file Patch provided by John Muth Modified: incubator/servicemix/trunk/servicemix-core/src/main/java/org/apache/servicemix/jbi/management/task/DeployServiceAssemblyTask.java incubator/servicemix/trunk/servicemix-core/src/main/java/org/apache/servicemix/jbi/management/task/InstallComponentTask.java incubator/servicemix/trunk/servicemix-core/src/main/java/org/apache/servicemix/jbi/management/task/InstallSharedLibraryTask.java ServiceMix Ant tasks: accept URL for file - Key: SM-501 URL: https://issues.apache.org/activemq/browse/SM-501 Project: ServiceMix Issue Type: Improvement Affects Versions: 3.0-M2 Environment: any Reporter: John Muth Assigned To: Guillaume Nodet Priority: Minor Fix For: 3.0-M3 Attachments: dep_sa_patch.txt, inst_comp_patch.txt, inst_sl_patch.txt It would be very useful to be able to pass urls to the servicemix ant tasks that install things, and for servicemix to go and fetch the file you've pointed to at the point at which it's ready to do the installing. The affected files are: InstallComponentTask.java InstallSharedLibraryTask.java DeployServiceAssemblyTask.java The change is nearly identical in all three. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (GERONIMO-2247) Apllications Portlets: Restart column does not alternate background color
[ http://issues.apache.org/jira/browse/GERONIMO-2247?page=all ] Joe Bohn resolved GERONIMO-2247. Fix Version/s: 1.2 Resolution: Fixed patch applied in geronimo .1.1 Sending applications\console-standard\src\webapp\WEB-INF\view\configmanager\normal.jsp Transmitting file data . Committed revision 427210. and trunk: Sending applications\console\console-standard\src\webapp\WEB-INF\view\configmanager\normal.jsp Transmitting file data . Committed revision 427211. Apllications Portlets: Restart column does not alternate background color --- Key: GERONIMO-2247 URL: http://issues.apache.org/jira/browse/GERONIMO-2247 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: console Affects Versions: 1.1.1 Reporter: Vamsavardhana Reddy Assigned To: Joe Bohn Priority: Trivial Fix For: 1.1.1, 1.2 Attachments: GERONIMO-2247.patch Newly added Restart link column does not alternate backgound color on the applications portlets. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Assigned: (SM-504) Beanflow: Multiple execution of beanflow steps
[ https://issues.apache.org/activemq/browse/SM-504?page=all ]
Guillaume Nodet reassigned SM-504:
--
Assignee: Guillaume Nodet (was: james strachan)
Beanflow: Multiple execution of beanflow steps
--
Key: SM-504
URL: https://issues.apache.org/activemq/browse/SM-504
Project: ServiceMix
Issue Type: Bug
Affects Versions: incubation
Environment: Windows2K, running ServiceMix under JBoss4.0.3SP1
Reporter: Andreas Held
Assigned To: Guillaume Nodet
Consider the following simple Beanflow example:
public class TestWorkflow extends WorkflowString {
private static Logger log =
Logger.getLogger(TestWorkflow.class.getName());
public static int count = 0;
public TestWorkflow() {
super(startStep);
}
public String startStep() {
count += 1;
log.info(Workflow: Validation);
// next step
return persistenceStep;
}
public String persistenceStep() {
count += 1;
log.info(Workflow: Persistence);
// next step
return transferStep;
}
public String transferStep() {
count += 1;
log.info(Workflow: Transfer);
// next step
return stop;
}
}
If I write a JUnit test case with assertEquals(workflow.count, 3); then
this will fail, as count has a value of 5. Looking at the log shows the
following output:
08:19:26,335 DEBUG [org.apache.servicemix.beanflow.Workflow.run()] About
to execute step: startStep
08:19:26,351 INFO [ch.bbp.igt.comm.ServiceMix.TestWorkflow.startStep()]
FileActWorkflow: Validation
08:19:26,351 DEBUG [org.apache.servicemix.beanflow.Workflow.run()] About
to execute step: persistenceStep
08:19:26,351 INFO
[ch.bbp.igt.comm.ServiceMix.TestWorkflow.persistenceStep()]
FileActWorkflow: Persistence
08:19:26,351 DEBUG [org.apache.servicemix.beanflow.Workflow.run()] About
to execute step: persistenceStep
08:19:26,351 INFO
[ch.bbp.igt.comm.ServiceMix.TestWorkflow.persistenceStep()]
FileActWorkflow: Persistence
08:19:26,351 DEBUG [org.apache.servicemix.beanflow.Workflow.run()] About
to execute step: transferStep
08:19:26,351 INFO
[ch.bbp.igt.comm.ServiceMix.TestWorkflow.transferStep()]
FileActWorkflow: Transfer
08:19:26,351 DEBUG [org.apache.servicemix.beanflow.Workflow.run()] About
to execute step: transferStep
08:19:26,351 INFO
[ch.bbp.igt.comm.ServiceMix.TestWorkflow.transferStep()]
FileActWorkflow: Transfer
08:19:26,351 DEBUG [org.apache.servicemix.beanflow.Workflow.run()] About
to execute step: stop
08:19:26,367 DEBUG [org.apache.servicemix.beanflow.Workflow.run()] About
to execute step: stop
This means, all steps but the start step are executed twice! This
corresponds to count being 5 in the end!
JUnit Testcase :
public class WorkflowTest extends TestCase {
public WorkflowTest(String s) {
super(s);
}
protected void setUp() {
}
protected void tearDown() {
}
public void testTest() throws Exception {
TestWorkflow workflow = new TestWorkflow();
workflow.start();
Thread.sleep(2000);
assertEquals(3, workflow.count);
}
public static Test suite() {
TestSuite suite = new TestSuite();
suite.addTest(new WorkflowTest(testTest));
return suite;
}
}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://issues.apache.org/activemq/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (SM-504) Beanflow: Multiple execution of beanflow steps
[ https://issues.apache.org/activemq/browse/SM-504?page=all ]
Guillaume Nodet resolved SM-504.
Fix Version/s: 3.0-M3
Resolution: Fixed
Author: gnodet
Date: Mon Jul 31 12:08:25 2006
New Revision: 427214
URL: http://svn.apache.org/viewvc?rev=427214view=rev
Log:
SM-504: Beanflow: Multiple execution of beanflow steps
Added:
incubator/servicemix/trunk/servicemix-beanflow/src/test/java/org/apache/servicemix/beanflow/CountWorkflow.java
incubator/servicemix/trunk/servicemix-beanflow/src/test/java/org/apache/servicemix/beanflow/CountWorkflowTest.java
Modified:
incubator/servicemix/trunk/servicemix-beanflow/src/main/java/org/apache/servicemix/beanflow/Workflow.java
Beanflow: Multiple execution of beanflow steps
--
Key: SM-504
URL: https://issues.apache.org/activemq/browse/SM-504
Project: ServiceMix
Issue Type: Bug
Affects Versions: incubation
Environment: Windows2K, running ServiceMix under JBoss4.0.3SP1
Reporter: Andreas Held
Assigned To: Guillaume Nodet
Fix For: 3.0-M3
Consider the following simple Beanflow example:
public class TestWorkflow extends WorkflowString {
private static Logger log =
Logger.getLogger(TestWorkflow.class.getName());
public static int count = 0;
public TestWorkflow() {
super(startStep);
}
public String startStep() {
count += 1;
log.info(Workflow: Validation);
// next step
return persistenceStep;
}
public String persistenceStep() {
count += 1;
log.info(Workflow: Persistence);
// next step
return transferStep;
}
public String transferStep() {
count += 1;
log.info(Workflow: Transfer);
// next step
return stop;
}
}
If I write a JUnit test case with assertEquals(workflow.count, 3); then
this will fail, as count has a value of 5. Looking at the log shows the
following output:
08:19:26,335 DEBUG [org.apache.servicemix.beanflow.Workflow.run()] About
to execute step: startStep
08:19:26,351 INFO [ch.bbp.igt.comm.ServiceMix.TestWorkflow.startStep()]
FileActWorkflow: Validation
08:19:26,351 DEBUG [org.apache.servicemix.beanflow.Workflow.run()] About
to execute step: persistenceStep
08:19:26,351 INFO
[ch.bbp.igt.comm.ServiceMix.TestWorkflow.persistenceStep()]
FileActWorkflow: Persistence
08:19:26,351 DEBUG [org.apache.servicemix.beanflow.Workflow.run()] About
to execute step: persistenceStep
08:19:26,351 INFO
[ch.bbp.igt.comm.ServiceMix.TestWorkflow.persistenceStep()]
FileActWorkflow: Persistence
08:19:26,351 DEBUG [org.apache.servicemix.beanflow.Workflow.run()] About
to execute step: transferStep
08:19:26,351 INFO
[ch.bbp.igt.comm.ServiceMix.TestWorkflow.transferStep()]
FileActWorkflow: Transfer
08:19:26,351 DEBUG [org.apache.servicemix.beanflow.Workflow.run()] About
to execute step: transferStep
08:19:26,351 INFO
[ch.bbp.igt.comm.ServiceMix.TestWorkflow.transferStep()]
FileActWorkflow: Transfer
08:19:26,351 DEBUG [org.apache.servicemix.beanflow.Workflow.run()] About
to execute step: stop
08:19:26,367 DEBUG [org.apache.servicemix.beanflow.Workflow.run()] About
to execute step: stop
This means, all steps but the start step are executed twice! This
corresponds to count being 5 in the end!
JUnit Testcase :
public class WorkflowTest extends TestCase {
public WorkflowTest(String s) {
super(s);
}
protected void setUp() {
}
protected void tearDown() {
}
public void testTest() throws Exception {
TestWorkflow workflow = new TestWorkflow();
workflow.start();
Thread.sleep(2000);
assertEquals(3, workflow.count);
}
public static Test suite() {
TestSuite suite = new TestSuite();
suite.addTest(new WorkflowTest(testTest));
return suite;
}
}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://issues.apache.org/activemq/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (GERONIMO-2227) ENC Lookup Fix (include parent modules)
[ http://issues.apache.org/jira/browse/GERONIMO-2227?page=all ] Aaron Mulder updated GERONIMO-2227: --- Fix Version/s: 1.x (was: 1.1.1) ENC Lookup Fix (include parent modules) --- Key: GERONIMO-2227 URL: http://issues.apache.org/jira/browse/GERONIMO-2227 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Affects Versions: 1.1 Reporter: Aaron Mulder Assigned To: David Jencks Fix For: 1.x Attachments: 2227-enc-include-parents.patch I ran across this while working on plugins that use resource-ref-like features to identify a database connection pool, JMS destination, etc. The problem was that some naming searches were restricted to the current module only when I felt all parents should be searched too. I would like David J to review this before I commit it, as my understanding of the code in question is not terribly thorough. -- 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
Welcome David Jencks as the newest memeber of the Geronimo PMC
The PMC would like to welcome David Jencks as the newest member of the PMC. Please join us in welcoming David. Matt
Re: Welcome David Jencks as the newest memeber of the Geronimo PMC
Congratulations David! -dain On Jul 31, 2006, at 12:48 PM, Matt Hogstrom wrote: The PMC would like to welcome David Jencks as the newest member of the PMC. Please join us in welcoming David. Matt
Re: Welcome David Jencks as the newest memeber of the Geronimo PMC
Way to go David! Paul On 7/31/06, Matt Hogstrom [EMAIL PROTECTED] wrote: The PMC would like to welcome David Jencks as the newest member of the PMC. Please join us in welcoming David. Matt
Re: Welcome David Jencks as the newest memeber of the Geronimo PMC
Wow !! Congrats David. Cheers Prasad On 7/31/06, Paul McMahan [EMAIL PROTECTED] wrote: Way to go David! Paul On 7/31/06, Matt Hogstrom [EMAIL PROTECTED] wrote: The PMC would like to welcome David Jencks as the newest member of the PMC. Please join us in welcoming David. Matt
Re: Welcome David Jencks as the newest memeber of the Geronimo PMC
congrats!On Jul 31, 2006, at 3:48 PM, Matt Hogstrom wrote:The PMC would like to welcome David Jencks as the newest member of the PMC. Please join us in welcoming David.Matt -sachin
Re: Welcome David Jencks as the newest memeber of the Geronimo PMC
Congrats Mr. Jencks! -David On Jul 31, 2006, at 12:48 PM, Matt Hogstrom wrote: The PMC would like to welcome David Jencks as the newest member of the PMC. Please join us in welcoming David. Matt
Certificate login
Hi all, I have another requirement in my project (a tough one). Instead of using username/password I want to use only certificate for both authentication and authorization. I see two approaches: 1. As JMS allows only (username, password) in createConnection(), I can export certificate to a String and supply it as a username and develop custom JAAS login module that would convert username String back to the certificate and authenticate (against an LDAP directory). However, I don't like this approach. 2. As I am going to use SSL anyway, I would like to use SSL client authentication as the basis for AMQ authentication. As much as I understood JSSE, certificates are checked against keystore so I can develop custom keystore implementation that checks certificates against LDAP directory. However, I do not know how to make AMQ aware of this process i.e. how to bind the Subject with SSL connection so that AMQ can use this information for authorization. SSL client authentication is invisible to AMQ, as I understood. Concentrating on approach (2.), I can obtian certificates from SSL session but how do I obtain SSL session from AMQ? Is it Connection, Transport or other entity? Would it be convenient in current AMQ architecture to do what I propose? I would appreciate a hint from somebody with deeper knowledge of AMQ and JSSE. Thanks and regards, NGC -- View this message in context: http://www.nabble.com/Certificate-login-tf2029724.html#a5583011 Sent from the ActiveMQ - Dev forum at Nabble.com.
Re: Welcome David Jencks as the newest memeber of the Geronimo PMC
Congrats David! --kevan On Jul 31, 2006, at 3:48 PM, Matt Hogstrom wrote: The PMC would like to welcome David Jencks as the newest member of the PMC. Please join us in welcoming David. Matt
Re: Welcome David Jencks as the newest memeber of the Geronimo PMC
Congratulations Dave, way to go !!! Cheers! Hernan Matt Hogstrom wrote: The PMC would like to welcome David Jencks as the newest member of the PMC. Please join us in welcoming David. Matt
Re: Welcome David Jencks as the newest memeber of the Geronimo PMC
Congratulations David Joe Matt Hogstrom wrote: The PMC would like to welcome David Jencks as the newest member of the PMC. Please join us in welcoming David. Matt
[jira] Created: (GERONIMO-2254) No way for users to list installed plugins
No way for users to list installed plugins -- Key: GERONIMO-2254 URL: http://issues.apache.org/jira/browse/GERONIMO-2254 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Components: Plugins Affects Versions: 1.1 Reporter: Aaron Mulder Assigned To: Aaron Mulder Fix For: 1.1.x -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Re: Liferay Plugin for G
I updated the liferay plugins as Aaron suggested, adding tomcat to the module name, providing better metadata for the plugin site, etc. My dev/test plugin repository is currently available at http://mcmahanfamily.org/repository/geronimo-1.1/ if you would like to follow the instructions provided earlier in this thread (quoted below) to add the repository to your admin console. Feedback is most welcome!! A few points: - you probably want to start your JVM with -Xmx1024m to make more memory available to the portal application - Jeff is helping with a new version of Liferay that can be deployed into Geronimo as an EAR file and can reuse some jars in Geronimo's repository. My understanding is that those changes will be rolled into the next version of Liferay (4.1.0?). I'm also going to see if the changes I made for Derby can make that release as well and then roll up a new version of the plugins. - If you notice some glitches with the UI while downloading the plugin then you probably need to pick up the changes made in GERONIMO-1959 which were committed last week (thanks Sachin). - I am offering to provide my assistance to Liferay so they can set up a repository and host the plugin at their site. thanks, Paul On 7/29/06, Aaron Mulder [EMAIL PROTECTED] wrote: Paul, If you're going to update the liferay plugin soon with more extensive metadata and to add tomcat to the name, I'd rather wait to post it until I get the update -- so the page about it will be more complete, so the module ID won't be changing for the next release, and so we don't have a dilemma caused by a second release of the version 4.0.0 plugin. If that's going to be a problem, let me know and I'll post the version I have now. I don't remember of you've done this already, but if not, you might also want to make sure that the plugin lists itself in the obsoletes section, so it will uninstall older versions when you install a newer version. Thanks, Aaron On 7/27/06, Paul McMahan [EMAIL PROTECTED] wrote: On 7/27/06, Aaron Mulder [EMAIL PROTECTED] wrote: Paul, I haven't heard back about whether you want me to post the same plugins that are on your site, so I'll assume yes unless I hear otherwise. I see you updated the paths on your server though, which is great. Aaron, I'm at a conference this week and have limited devlist time so thanks for your patience. I did update the repository paths as you suggested, thanks for the tip. Posting the plugin to your site sounds great. But for the longer term I would like to encourage Liferay to host the plugin instead. I'll offer my assistance in setting up their repository and also help fix GERONIMO-2076 so people can copy/paste alternate repository URLs into the admin console. A few more notes about the liferay plugins: It looks like you have a plugin for Geronimo/Tomcat only (not Geronimo/Jetty). Can you build a Jetty plugin too, or does the integration only work with Tomcat? If there are going to be versions for both, it would be best to put tomcat or jetty in the module ID for the portal plugin -- liferay/liferay-portal-tomcat/4.0.0/car and liferay/liferay-portal-jetty/4.0.0/car instead of just using liferay/liferay-portal/4.0.0/car for the Tomcat version (and then what for Jetty?). Agreed. Adding a Jetty version of the plugin is definitely near the top of the todo list. It should be straightfoward since Liferay already provides a Jetty version. I'll rename the plugin to include the servlet engine name as you suggest. Does the plugin system support either/or style dependencies so I could create a single plugin with a dependency against either tomcat or jetty? If not then does it sound like a reasonable enhancement request for the 1.2 timeframe (maybe I can work on this)? You should use a human-readable name for the plugin metadata, and make the description an actual description (it will be used as text on the web page that describes the plugin). There is no real description for the Liferay plugin (only for the Liferay database plugin), which means the web page on the site for the plugin will be pretty empty. They both use the module ID as the name, which isn't so good. It would be great if you could update the metadata accordingly. I agree and will add some better info to the plugin's metadata in its next iteration. Generally, I'm not sure it's wise to make the plugin version the same as the Liferay product version. That means you can't release enhancements to the plugin separately from new versions of the product. However, if you're simply repackaging the default Liferay install (so you think there's no reason to release a separate plugin update), then it makes sense. Right now the procedure I use to generate the plugin is just to export the Liferay WAR as a CAR using the plugin UI. I made a few changes to the exported artifact so it could support Derby. Liferay has indicated
Re: Re: Liferay Plugin for G
Cool! I'll post it to the main plugin site tonight. Thanks, Aaron On 7/31/06, Paul McMahan [EMAIL PROTECTED] wrote: I updated the liferay plugins as Aaron suggested, adding tomcat to the module name, providing better metadata for the plugin site, etc. My dev/test plugin repository is currently available at http://mcmahanfamily.org/repository/geronimo-1.1/ if you would like to follow the instructions provided earlier in this thread (quoted below) to add the repository to your admin console. Feedback is most welcome!! A few points: - you probably want to start your JVM with -Xmx1024m to make more memory available to the portal application - Jeff is helping with a new version of Liferay that can be deployed into Geronimo as an EAR file and can reuse some jars in Geronimo's repository. My understanding is that those changes will be rolled into the next version of Liferay (4.1.0?). I'm also going to see if the changes I made for Derby can make that release as well and then roll up a new version of the plugins. - If you notice some glitches with the UI while downloading the plugin then you probably need to pick up the changes made in GERONIMO-1959 which were committed last week (thanks Sachin). - I am offering to provide my assistance to Liferay so they can set up a repository and host the plugin at their site. thanks, Paul On 7/29/06, Aaron Mulder [EMAIL PROTECTED] wrote: Paul, If you're going to update the liferay plugin soon with more extensive metadata and to add tomcat to the name, I'd rather wait to post it until I get the update -- so the page about it will be more complete, so the module ID won't be changing for the next release, and so we don't have a dilemma caused by a second release of the version 4.0.0 plugin. If that's going to be a problem, let me know and I'll post the version I have now. I don't remember of you've done this already, but if not, you might also want to make sure that the plugin lists itself in the obsoletes section, so it will uninstall older versions when you install a newer version. Thanks, Aaron On 7/27/06, Paul McMahan [EMAIL PROTECTED] wrote: On 7/27/06, Aaron Mulder [EMAIL PROTECTED] wrote: Paul, I haven't heard back about whether you want me to post the same plugins that are on your site, so I'll assume yes unless I hear otherwise. I see you updated the paths on your server though, which is great. Aaron, I'm at a conference this week and have limited devlist time so thanks for your patience. I did update the repository paths as you suggested, thanks for the tip. Posting the plugin to your site sounds great. But for the longer term I would like to encourage Liferay to host the plugin instead. I'll offer my assistance in setting up their repository and also help fix GERONIMO-2076 so people can copy/paste alternate repository URLs into the admin console. A few more notes about the liferay plugins: It looks like you have a plugin for Geronimo/Tomcat only (not Geronimo/Jetty). Can you build a Jetty plugin too, or does the integration only work with Tomcat? If there are going to be versions for both, it would be best to put tomcat or jetty in the module ID for the portal plugin -- liferay/liferay-portal-tomcat/4.0.0/car and liferay/liferay-portal-jetty/4.0.0/car instead of just using liferay/liferay-portal/4.0.0/car for the Tomcat version (and then what for Jetty?). Agreed. Adding a Jetty version of the plugin is definitely near the top of the todo list. It should be straightfoward since Liferay already provides a Jetty version. I'll rename the plugin to include the servlet engine name as you suggest. Does the plugin system support either/or style dependencies so I could create a single plugin with a dependency against either tomcat or jetty? If not then does it sound like a reasonable enhancement request for the 1.2 timeframe (maybe I can work on this)? You should use a human-readable name for the plugin metadata, and make the description an actual description (it will be used as text on the web page that describes the plugin). There is no real description for the Liferay plugin (only for the Liferay database plugin), which means the web page on the site for the plugin will be pretty empty. They both use the module ID as the name, which isn't so good. It would be great if you could update the metadata accordingly. I agree and will add some better info to the plugin's metadata in its next iteration. Generally, I'm not sure it's wise to make the plugin version the same as the Liferay product version. That means you can't release enhancements to the plugin separately from new versions of the product. However, if you're simply repackaging the default Liferay install (so you think there's no reason to release a separate plugin update), then it makes sense. Right now the
Re: Liferay Plugin for G
Paul McMahan wrote: - Jeff is helping with a new version of Liferay that can be deployed into Geronimo as an EAR file and can reuse some jars in Geronimo's repository. My understanding is that those changes will be rolled into the next version of Liferay (4.1.0?). I'm also going to see if the changes I made for Derby can make that release as well and then roll up a new version of the plugins. I got it working, but it has found some nasties with Geronimo. First, the EAR deployment seems to want 1.5G in the JAVA_OPTS for memory to run on Linux and MacOSX machines. It seems to run fine there with those memory settings. But Windows can't seem to allocate more than 1.498G to the Java heap, so it doesn't work on that platform. The issue is, it runs fine in 1G on all other appservers, except for G. This likely is a problem in OpenEJB and I will have to profile why the need for so much memory. :( Jeff
[jira] Assigned: (GERONIMO-2241) Duplicate attributes created in config.xml for gbean
[ http://issues.apache.org/jira/browse/GERONIMO-2241?page=all ]
Joe Bohn reassigned GERONIMO-2241:
--
Assignee: Joe Bohn
Duplicate attributes created in config.xml for gbean
Key: GERONIMO-2241
URL: http://issues.apache.org/jira/browse/GERONIMO-2241
Project: Geronimo
Issue Type: Bug
Security Level: public(Regular issues)
Affects Versions: 1.1.1
Environment: windows xp
jetty and tomcat
Reporter: Joe Bohn
Assigned To: Joe Bohn
Fix For: 1.1.1
Here is the text from a dev list post. For the post responses see:
http://marc.theaimsgroup.com/?l=geronimo-devm=115412195529876w=2
There is either a problem with the attribute processing on gbeans or the
keystore use of this processing, I'm not sure which.
The problem is that there are times when an attribute is being set which
result in two entries in the config.xml for the same attribute rather than
replacing the current setting. Here is the scenario.
There is an attribute on the keystore instance gbean (the default one we
provide) for the keystore lock password and key passwords. The scenario
happens with both attributes but I'm most concerned with the keystore lock at
the moment so I'll just discuss that one.
With a brand new image, the attribute for the keystore lock is set to the
default password (which effectively means it is unlocked). If we lock the
keystore the password is then replaced with a null value and this is
reflected in the config.xml. So far, so good. However, when we subsequently
unlock the keystore, rather than replacing the password attribute with the
value again it ends up creating a second entry for the attribute just before
the null value entry. Here is what it looks like in the config.xml:
gbean
name=geronimo/j2ee-security/1.1.1-SNAPSHOT/car?ServiceModule=geronimo/j2ee-security/1.1.1-SNAPSHOT/car,j2eeType=Keystore,name=geronimo-default
attribute
name=keystorePassword{Simple}rO0ABXNyABlqYXZheC5jcnlwdG8uU2VhbGVkT2JqZWN0PjY9psO3VHACAARbAA1lbmNvZGVkUGFyYW1zdAACW0JbABBlbmNyeXB0ZWRDb250ZW50cQB+AAFMAAlwYXJhbXNBbGd0ABJMamF2YS9sYW5nL1N0cmluZztMAAdzZWFsQWxncQB+AAJ4cHB1cgACW0Ks8xf4BghU4AIAAHhwEArVToThqcjvbXFD5C2uUmpwdAADQUVT/attribute
attribute
name=keyPasswords{Simple}rO0ABXNyABlqYXZheC5jcnlwdG8uU2VhbGVkT2JqZWN0PjY9psO3VHACAARbAA1lbmNvZGVkUGFyYW1zdAACW0JbABBlbmNyeXB0ZWRDb250ZW50cQB+AAFMAAlwYXJhbXNBbGd0ABJMamF2YS9sYW5nL1N0cmluZztMAAdzZWFsQWxncQB+AAJ4cHB1cgACW0Ks8xf4BghU4AIAAHhwIJu+zYXdGgTo+dMtBxYduheM0Te6O/om49Ln+vWNipopcHQAA0FFUw==/attribute
attribute name=keystorePassword null=true/
attribute name=keyPasswords null=true/
It appears that null wins out (probably because it is last) and the net
result is that the keystore remains locked. This is not a good thing (see
other posts on the keystore processing).
So my question is this: Is this a problem with the way we are setting the
attribute or is it a problem with the attribute processing itself
(particularly around the setting and removing of a null value)? The code
that sets the attribute is in FileKeystoreInstance around line 130.
--
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-2241) Duplicate attributes created in config.xml for gbean
[ http://issues.apache.org/jira/browse/GERONIMO-2241?page=all ]
Joe Bohn updated GERONIMO-2241:
---
Component/s: core
Duplicate attributes created in config.xml for gbean
Key: GERONIMO-2241
URL: http://issues.apache.org/jira/browse/GERONIMO-2241
Project: Geronimo
Issue Type: Bug
Security Level: public(Regular issues)
Components: core
Affects Versions: 1.1.1
Environment: windows xp
jetty and tomcat
Reporter: Joe Bohn
Assigned To: Joe Bohn
Fix For: 1.1.1
Here is the text from a dev list post. For the post responses see:
http://marc.theaimsgroup.com/?l=geronimo-devm=115412195529876w=2
There is either a problem with the attribute processing on gbeans or the
keystore use of this processing, I'm not sure which.
The problem is that there are times when an attribute is being set which
result in two entries in the config.xml for the same attribute rather than
replacing the current setting. Here is the scenario.
There is an attribute on the keystore instance gbean (the default one we
provide) for the keystore lock password and key passwords. The scenario
happens with both attributes but I'm most concerned with the keystore lock at
the moment so I'll just discuss that one.
With a brand new image, the attribute for the keystore lock is set to the
default password (which effectively means it is unlocked). If we lock the
keystore the password is then replaced with a null value and this is
reflected in the config.xml. So far, so good. However, when we subsequently
unlock the keystore, rather than replacing the password attribute with the
value again it ends up creating a second entry for the attribute just before
the null value entry. Here is what it looks like in the config.xml:
gbean
name=geronimo/j2ee-security/1.1.1-SNAPSHOT/car?ServiceModule=geronimo/j2ee-security/1.1.1-SNAPSHOT/car,j2eeType=Keystore,name=geronimo-default
attribute
name=keystorePassword{Simple}rO0ABXNyABlqYXZheC5jcnlwdG8uU2VhbGVkT2JqZWN0PjY9psO3VHACAARbAA1lbmNvZGVkUGFyYW1zdAACW0JbABBlbmNyeXB0ZWRDb250ZW50cQB+AAFMAAlwYXJhbXNBbGd0ABJMamF2YS9sYW5nL1N0cmluZztMAAdzZWFsQWxncQB+AAJ4cHB1cgACW0Ks8xf4BghU4AIAAHhwEArVToThqcjvbXFD5C2uUmpwdAADQUVT/attribute
attribute
name=keyPasswords{Simple}rO0ABXNyABlqYXZheC5jcnlwdG8uU2VhbGVkT2JqZWN0PjY9psO3VHACAARbAA1lbmNvZGVkUGFyYW1zdAACW0JbABBlbmNyeXB0ZWRDb250ZW50cQB+AAFMAAlwYXJhbXNBbGd0ABJMamF2YS9sYW5nL1N0cmluZztMAAdzZWFsQWxncQB+AAJ4cHB1cgACW0Ks8xf4BghU4AIAAHhwIJu+zYXdGgTo+dMtBxYduheM0Te6O/om49Ln+vWNipopcHQAA0FFUw==/attribute
attribute name=keystorePassword null=true/
attribute name=keyPasswords null=true/
It appears that null wins out (probably because it is last) and the net
result is that the keystore remains locked. This is not a good thing (see
other posts on the keystore processing).
So my question is this: Is this a problem with the way we are setting the
attribute or is it a problem with the attribute processing itself
(particularly around the setting and removing of a null value)? The code
that sets the attribute is in FileKeystoreInstance around line 130.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (GERONIMO-2241) Duplicate attributes created in config.xml for gbean
[ http://issues.apache.org/jira/browse/GERONIMO-2241?page=all ]
Joe Bohn resolved GERONIMO-2241.
Fix Version/s: 1.2
Resolution: Fixed
fixed in both geronimo 1.1:
Sending
modules\system\src\java\org\apache\geronimo\system\configuration\GBeanOverride.java
Transmitting file data .
Committed revision 427255.
and trunk:
Sending
modules\system\src\java\org\apache\geronimo\system\configuration\GBeanOverride.java
Transmitting file data .
Committed revision 427256.
Duplicate attributes created in config.xml for gbean
Key: GERONIMO-2241
URL: http://issues.apache.org/jira/browse/GERONIMO-2241
Project: Geronimo
Issue Type: Bug
Security Level: public(Regular issues)
Components: core
Affects Versions: 1.1.1
Environment: windows xp
jetty and tomcat
Reporter: Joe Bohn
Assigned To: Joe Bohn
Fix For: 1.1.1, 1.2
Here is the text from a dev list post. For the post responses see:
http://marc.theaimsgroup.com/?l=geronimo-devm=115412195529876w=2
There is either a problem with the attribute processing on gbeans or the
keystore use of this processing, I'm not sure which.
The problem is that there are times when an attribute is being set which
result in two entries in the config.xml for the same attribute rather than
replacing the current setting. Here is the scenario.
There is an attribute on the keystore instance gbean (the default one we
provide) for the keystore lock password and key passwords. The scenario
happens with both attributes but I'm most concerned with the keystore lock at
the moment so I'll just discuss that one.
With a brand new image, the attribute for the keystore lock is set to the
default password (which effectively means it is unlocked). If we lock the
keystore the password is then replaced with a null value and this is
reflected in the config.xml. So far, so good. However, when we subsequently
unlock the keystore, rather than replacing the password attribute with the
value again it ends up creating a second entry for the attribute just before
the null value entry. Here is what it looks like in the config.xml:
gbean
name=geronimo/j2ee-security/1.1.1-SNAPSHOT/car?ServiceModule=geronimo/j2ee-security/1.1.1-SNAPSHOT/car,j2eeType=Keystore,name=geronimo-default
attribute
name=keystorePassword{Simple}rO0ABXNyABlqYXZheC5jcnlwdG8uU2VhbGVkT2JqZWN0PjY9psO3VHACAARbAA1lbmNvZGVkUGFyYW1zdAACW0JbABBlbmNyeXB0ZWRDb250ZW50cQB+AAFMAAlwYXJhbXNBbGd0ABJMamF2YS9sYW5nL1N0cmluZztMAAdzZWFsQWxncQB+AAJ4cHB1cgACW0Ks8xf4BghU4AIAAHhwEArVToThqcjvbXFD5C2uUmpwdAADQUVT/attribute
attribute
name=keyPasswords{Simple}rO0ABXNyABlqYXZheC5jcnlwdG8uU2VhbGVkT2JqZWN0PjY9psO3VHACAARbAA1lbmNvZGVkUGFyYW1zdAACW0JbABBlbmNyeXB0ZWRDb250ZW50cQB+AAFMAAlwYXJhbXNBbGd0ABJMamF2YS9sYW5nL1N0cmluZztMAAdzZWFsQWxncQB+AAJ4cHB1cgACW0Ks8xf4BghU4AIAAHhwIJu+zYXdGgTo+dMtBxYduheM0Te6O/om49Ln+vWNipopcHQAA0FFUw==/attribute
attribute name=keystorePassword null=true/
attribute name=keyPasswords null=true/
It appears that null wins out (probably because it is last) and the net
result is that the keystore remains locked. This is not a good thing (see
other posts on the keystore processing).
So my question is this: Is this a problem with the way we are setting the
attribute or is it a problem with the attribute processing itself
(particularly around the setting and removing of a null value)? The code
that sets the attribute is in FileKeystoreInstance around line 130.
--
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-2218) KeyStore portlet: Functionality missing from 1.0
[ http://issues.apache.org/jira/browse/GERONIMO-2218?page=comments#action_12424651 ] Joe Bohn commented on GERONIMO-2218: I'm going to integrate the original patch (without the unlockkey addition). I didn't apply the most recent unlockkey patch but the earlier patch had several problems that I think we need to work out with some discussion before we go down that path. My recommendation is that we close this JIRA and create a new JIRA for the unlock key issue. For the moment, not integrating the unlock key function means that when a user adds a new key they need to go back to the availability lock, lock it, unlock it, and then select the newly added key to unlock the specific key. Here are some of the issues I think exists once we start to unlock the key in other places: 1) It seems like jetty has some problems if there is more than one unlocked key in the same keystore. I'm not sure what these are exactly, but I couldn't get jetty to start once I had more than one key unlocked. I think this is the largest issue. 2) If we provide the ability to unlock specific keys within a keystore then it seems like we should also provide the ability to lock keys from the same panel. 3) After unlocking a key it didn't return me to the same panel that I had locked from ... rather it took me to a different panel. 4) I received some exceptions from portlet state when performing either the lock or the unlock (I can't remember). This may have been corrected in the most recent patch. KeyStore portlet: Functionality missing from 1.0 - Key: GERONIMO-2218 URL: http://issues.apache.org/jira/browse/GERONIMO-2218 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: console Affects Versions: 1.1, 1.1.1 Environment: Win XP, Sun JDK1.4.2_08 Reporter: Vamsavardhana Reddy Assigned To: Joe Bohn Priority: Critical Fix For: 1.1.1 Attachments: GERONIMO-2218-with-unlockkey-new.patch, GERONIMO-2218-with-unlockkey.patch, GERONIMO-2218.patch Functionality missing from AG1.0 includes 1. Ability to view Trusted Certificate and Private Key Entry details 2. Ability to generate CertificateRequests 3. Ability to import CA reply The 2nd and 3rd functions from above are most important and without these the portlet is of very less (or no) use in any practical scenario. -- 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: (XBEAN-30) NPE using XBeanHelper.createBeanDefinitionReader and spring 2.0-rc2
NPE using XBeanHelper.createBeanDefinitionReader and spring 2.0-rc2 --- Key: XBEAN-30 URL: http://issues.apache.org/jira/browse/XBEAN-30 Project: XBean Issue Type: Bug Components: spring Affects Versions: 2.5 Environment: xbean-spring-2.5.jar spring-2.0-rc2.jar Reporter: Guillaume Nodet Fix For: 2.6 Exception in thread JMX Connector Thread [service:jmx:rmi:///jndi/rmi://localhost:1099/jmxrmi] java.lang.IllegalStateException: Could not find valid implement ation for: 2.0-rc2 at org.apache.xbean.spring.context.impl.XBeanHelper.createBeanDefinitionReader(XBeanHelper.java:24) at org.apache.xbean.spring.context.impl.XBeanXmlBeanFactory.init(XBeanXmlBeanFactory.java:72) at org.apache.xbean.spring.context.impl.XBeanXmlBeanFactory.init(XBeanXmlBeanFactory.java:37) at org.apache.xbean.spring.jndi.SpringInitialContextFactory.createContext(SpringInitialContextFactory.java:105) at org.apache.xbean.spring.jndi.SpringInitialContextFactory.loadContext(SpringInitialContextFactory.java:96) at org.apache.xbean.spring.jndi.SpringInitialContextFactory.getInitialContext(SpringInitialContextFactory.java:83) at javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:667) at javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java:247) at javax.naming.InitialContext.init(InitialContext.java:223) at javax.naming.InitialContext.init(InitialContext.java:197) at javax.management.remote.rmi.RMIConnectorServer.bind(RMIConnectorServer.java:629) at javax.management.remote.rmi.RMIConnectorServer.start(RMIConnectorServer.java:427) at org.springframework.jmx.support.ConnectorServerFactoryBean$1.run(ConnectorServerFactoryBean.java:153) Caused by: java.lang.reflect.InvocationTargetException at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27) at java.lang.reflect.Constructor.newInstance(Constructor.java:494) at org.apache.xbean.spring.context.impl.XBeanHelper.createBeanDefinitionReader(XBeanHelper.java:22) ... 12 more Caused by: java.lang.NullPointerException at org.springframework.beans.factory.xml.ResourceEntityResolver.init(ResourceEntityResolver.java:64) at org.apache.xbean.spring.context.v2.XBeanXmlBeanDefinitionReader.init(XBeanXmlBeanDefinitionReader.java:60) ... 17 more -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (GERONIMO-2218) KeyStore portlet: Functionality missing from 1.0
[ http://issues.apache.org/jira/browse/GERONIMO-2218?page=all ] Joe Bohn resolved GERONIMO-2218. Resolution: Fixed patch applied to geronimo 1.1 Sending applications\console-standard\src\java\org\apache\geronimo\console\keystores\BaseKeystoreHandler.java Adding applications\console-standard\src\java\org\apache\geronimo\console\keystores\CertificateDetailsHandler.java Sending applications\console-standard\src\java\org\apache\geronimo\console\keystores\ConfirmCertificateHandler.java Adding applications\console-standard\src\java\org\apache\geronimo\console\keystores\DeleteEntryHandler.java Adding applications\console-standard\src\java\org\apache\geronimo\console\keystores\GenerateCSRHandler.java Adding applications\console-standard\src\java\org\apache\geronimo\console\keystores\ImportCAReplyHandler.java Sending applications\console-standard\src\java\org\apache\geronimo\console\keystores\KeystoresPortlet.java Sending applications\console-standard\src\java\org\apache\geronimo\console\keystores\UnlockKeyHandler.java Sending applications\console-standard\src\java\org\apache\geronimo\console\keystores\UploadCertificateHandler.java Adding applications\console-standard\src\webapp\WEB-INF\view\keystore\certificateDetails.jsp Adding applications\console-standard\src\webapp\WEB-INF\view\keystore\generateCSR.jsp Adding applications\console-standard\src\webapp\WEB-INF\view\keystore\importCAReply.jsp Sending applications\console-standard\src\webapp\WEB-INF\view\keystore\uploadCertificate.jsp Sending applications\console-standard\src\webapp\WEB-INF\view\keystore\viewKeystore.jsp Sending modules\management\src\java\org\apache\geronimo\management\geronimo\KeystoreInstance.java Sending modules\security\src\java\org\apache\geronimo\security\keystore\FileKeystoreInstance.java Transmitting file data Committed revision 427268. and trunk: Sending applications\console\console-standard\src\java\org\apache\geronimo\console\keystores\BaseKeystoreHandler.java Adding applications\console\console-standard\src\java\org\apache\geronimo\console\keystores\CertificateDetailsHandler.java Sending applications\console\console-standard\src\java\org\apache\geronimo\console\keystores\ConfirmCertificateHandler.java Adding applications\console\console-standard\src\java\org\apache\geronimo\console\keystores\DeleteEntryHandler.java Adding applications\console\console-standard\src\java\org\apache\geronimo\console\keystores\GenerateCSRHandler.java Adding applications\console\console-standard\src\java\org\apache\geronimo\console\keystores\ImportCAReplyHandler.java Sending applications\console\console-standard\src\java\org\apache\geronimo\console\keystores\KeystoresPortlet.java Sending applications\console\console-standard\src\java\org\apache\geronimo\console\keystores\UnlockKeyHandler.java Sending applications\console\console-standard\src\java\org\apache\geronimo\console\keystores\UploadCertificateHandler.java Adding applications\console\console-standard\src\webapp\WEB-INF\view\keystore\certificateDetails.jsp Adding applications\console\console-standard\src\webapp\WEB-INF\view\keystore\generateCSR.jsp Adding applications\console\console-standard\src\webapp\WEB-INF\view\keystore\importCAReply.jsp Sending applications\console\console-standard\src\webapp\WEB-INF\view\keystore\uploadCertificate.jsp Sending applications\console\console-standard\src\webapp\WEB-INF\view\keystore\viewKeystore.jsp Sending modules\management\src\java\org\apache\geronimo\management\geronimo\KeystoreInstance.java Sending modules\security\src\java\org\apache\geronimo\security\keystore\FileKeystoreInstance.java Transmitting file data Committed revision 427270. KeyStore portlet: Functionality missing from 1.0 - Key: GERONIMO-2218 URL: http://issues.apache.org/jira/browse/GERONIMO-2218 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: console Affects Versions: 1.1, 1.1.1 Environment: Win XP, Sun JDK1.4.2_08 Reporter: Vamsavardhana Reddy Assigned To: Joe Bohn Priority: Critical Fix For: 1.1.1 Attachments: GERONIMO-2218-with-unlockkey-new.patch, GERONIMO-2218-with-unlockkey.patch, GERONIMO-2218.patch Functionality missing from AG1.0 includes 1. Ability to view Trusted Certificate and Private Key Entry details 2. Ability to generate CertificateRequests 3. Ability to import CA reply The 2nd and 3rd functions from above are most important and without these the portlet is of very less (or no) use in any
[jira] Updated: (GERONIMO-2248) Applications portlets: List Parent and Child components against each component
[ http://issues.apache.org/jira/browse/GERONIMO-2248?page=all ] Joe Bohn updated GERONIMO-2248: --- Fix Version/s: (was: 1.1.1) This is an improvement and therefore would not normally be considered for a maintenance release. If there are compelling reasons this should be considered for 1.1.x please provide more details. I think it's too late to be considered for 1.1.1 Applications portlets: List Parent and Child components against each component -- Key: GERONIMO-2248 URL: http://issues.apache.org/jira/browse/GERONIMO-2248 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: console Affects Versions: 1.2, 1.1, 1.1.1 Reporter: Vamsavardhana Reddy Fix For: 1.2 Attachments: GERONIMO-2248.patch Applications portlets currently provide component status and links to start/stop/restart/uninstall. They do not provide a listing of parent components and child components. If child components are listed, a user will immediatley know what all configurations will be stopped if a particular component is stopped. How is it useful? I have stopped geronimo/system-database/1.1.1-SNAPSHOT/car to test something. Only after an error HTTP 404 was displayed next, I realized that the admin console had a dependency on geronimo/system-database/1.1.1-SNAPSHOT/car. Had there been a Child Components listing next to geronimo/system-database/1.1.1-SNAPSHOT/car, it would have avoided the surprise. -- 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: Certificate login
Browsing through forum I saw that my approach (2.) is covered in thread http://www.nabble.com/forum/ViewPost.jtp?post=5366595framed=y Has there been any progress in implementation? Thanks and regards, NGC -- View this message in context: http://www.nabble.com/Certificate-login-tf2029724.html#a5584406 Sent from the ActiveMQ - Dev forum at Nabble.com.
Re: Creating a secure connection system and using JMSXUserID support
Hi, Has there been any progress on this issue? I have the same need in my project and am able to accept some work load to help this. (I was already going to start it myself, aanyway ;-) ) Regards, NGC -- View this message in context: http://www.nabble.com/Creating-a-secure-connection-system-and-using-JMSXUserID-support-tf1956575.html#a5584494 Sent from the ActiveMQ - Dev forum at Nabble.com.
[jira] Closed: (GERONIMO-1531) KeyStore portlet should support deletion of certificates and private keys
[ http://issues.apache.org/jira/browse/GERONIMO-1531?page=all ] Joe Bohn closed GERONIMO-1531. -- Resolution: Fixed This issue is resolved with the fix for GERONIMO-2218 KeyStore portlet should support deletion of certificates and private keys - Key: GERONIMO-1531 URL: http://issues.apache.org/jira/browse/GERONIMO-1531 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: console Affects Versions: 1.0 Reporter: Vamsavardhana Reddy Assigned To: Joe Bohn Priority: Minor Fix For: 1.1.1 Attachments: GERONIMO-1531.patch KeyStore portlet currently supports generation of keypairs, adding trusted certificates to keystore and importing certificate issued by CA. It does not address deletion of any of these from the keystore. -- 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: (XBEAN-30) NPE using XBeanHelper.createBeanDefinitionReader and spring 2.0-rc2
[ http://issues.apache.org/jira/browse/XBEAN-30?page=all ] Guillaume Nodet resolved XBEAN-30. -- Resolution: Fixed Assignee: Guillaume Nodet Add a test case and fix the NPE Author: gnodet Date: Mon Jul 31 14:51:00 2006 New Revision: 427307 URL: http://svn.apache.org/viewvc?rev=427307view=rev Log: XBEAN-30: NPE using XBeanHelper.createBeanDefinitionReader and spring 2.0-rc2 Modified: geronimo/xbean/trunk/xbean-spring-itests/core/src/main/java/org/apache/xbean/spring/context/RestaurantUsingXBeanTest.java geronimo/xbean/trunk/xbean-spring-v2/src/main/java/org/apache/xbean/spring/context/v2/XBeanXmlBeanDefinitionReader.java NPE using XBeanHelper.createBeanDefinitionReader and spring 2.0-rc2 --- Key: XBEAN-30 URL: http://issues.apache.org/jira/browse/XBEAN-30 Project: XBean Issue Type: Bug Components: spring Affects Versions: 2.5 Environment: xbean-spring-2.5.jar spring-2.0-rc2.jar Reporter: Guillaume Nodet Assigned To: Guillaume Nodet Fix For: 2.6 Exception in thread JMX Connector Thread [service:jmx:rmi:///jndi/rmi://localhost:1099/jmxrmi] java.lang.IllegalStateException: Could not find valid implement ation for: 2.0-rc2 at org.apache.xbean.spring.context.impl.XBeanHelper.createBeanDefinitionReader(XBeanHelper.java:24) at org.apache.xbean.spring.context.impl.XBeanXmlBeanFactory.init(XBeanXmlBeanFactory.java:72) at org.apache.xbean.spring.context.impl.XBeanXmlBeanFactory.init(XBeanXmlBeanFactory.java:37) at org.apache.xbean.spring.jndi.SpringInitialContextFactory.createContext(SpringInitialContextFactory.java:105) at org.apache.xbean.spring.jndi.SpringInitialContextFactory.loadContext(SpringInitialContextFactory.java:96) at org.apache.xbean.spring.jndi.SpringInitialContextFactory.getInitialContext(SpringInitialContextFactory.java:83) at javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:667) at javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java:247) at javax.naming.InitialContext.init(InitialContext.java:223) at javax.naming.InitialContext.init(InitialContext.java:197) at javax.management.remote.rmi.RMIConnectorServer.bind(RMIConnectorServer.java:629) at javax.management.remote.rmi.RMIConnectorServer.start(RMIConnectorServer.java:427) at org.springframework.jmx.support.ConnectorServerFactoryBean$1.run(ConnectorServerFactoryBean.java:153) Caused by: java.lang.reflect.InvocationTargetException at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27) at java.lang.reflect.Constructor.newInstance(Constructor.java:494) at org.apache.xbean.spring.context.impl.XBeanHelper.createBeanDefinitionReader(XBeanHelper.java:22) ... 12 more Caused by: java.lang.NullPointerException at org.springframework.beans.factory.xml.ResourceEntityResolver.init(ResourceEntityResolver.java:64) at org.apache.xbean.spring.context.v2.XBeanXmlBeanDefinitionReader.init(XBeanXmlBeanDefinitionReader.java:60) ... 17 more -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Welcome David Jencks as the newest memeber of the Geronimo PMC
Congratulations! David Cheers Anita --- Matt Hogstrom [EMAIL PROTECTED] wrote: The PMC would like to welcome David Jencks as the newest member of the PMC. Please join us in welcoming David. Matt __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: Roadmap for 3.0
On 7/24/06, Philip Dodds [EMAIL PROTECTED] wrote: Before pushing 3.0 out of the door I think we need to address : 1/ The project structure so that we can build core/components and tooling independently 2/ The packaging so we can create clean packages Any reason why we should do that before releasing 3.0 ? The thread about the project structure (see http://www.nabble.com/Source-re-structuring-tf2017112.html) is still undecided. Could you also be more precise about what you are referring to as clean packages ? distributions ? 3/ Documentation - I don't think producing a release with re-visting the documentation is going to help people +1 I think 3.0 is a big and important release for ServiceMix and we should make sure our ducks are in a row before putting it out there Agreed. But I'm not sure that restructuring the source code will have a great impact on users. Once the release is out, they will mostly use it, not build it. And offering several distributions may be addressed later. ServiceMix latest release (not milestone) is more than 8 months old, and while I agree that we need to work on documentation, I'm not very keen on delaying the release too much. It will be difficult to delay the release while not developing new features, and at the same time, adding new features will certainly delay the release due to stabilization time, etc... Working on fixing all unit tests, bug fixes, samples and documentation should be enough. Maybe we could add some critical features (the JNDI factory to integrate web apps ?), but we have to minimize their number, else we will never release anything. Btw, we can not discuss TCK things in detail, but I just want to say that we should be able to pass the full TCK soon (still waiting for the mailing list and svn repo). I think this makes a good plan for a 3.0 release, but discussion is welcome. Pushing a M3 / RC1 this month (when ?) and a 3.0 asap in september sounds like a good plan to me. P On 7/24/06, Guillaume Nodet [EMAIL PROTECTED] wrote: I guess it mainly depends if we want a timed-box release or a featured-box release ;) But we must first agree on that... Cheers, Guillaume Nodet On 7/24/06, Philip Dodds [EMAIL PROTECTED] wrote: +1 for getting a roadmap in place, though until we have a clear set of stuf that we want in place should be set a release date? P On 7/24/06, Guillaume Nodet [EMAIL PROTECTED] wrote: I' d like to start a discussion about ServiceMix roadmap for 3.0. IMHO, we should release a 3.0 asap, and I want to propose that we release 3.0 at the end of August. The main point I' d like to focus on are: * JBI TCK (which should be available to all committers that have signed a NDA) * bug fixes * documentation Any thoughts ? Cheers, Guillaume Nodet -- Cheers, Guillaume Nodet
Re: [VOTE] Release Apache ActiveMQ 4.0.2
Are you making this change for 4.0.2? -Brian On Jul 28, 2006, at 12:24 AM, James Strachan wrote: Looks good to me. Thanks for sorting this out Hiram. On 7/27/06, Hiram Chirino [EMAIL PROTECTED] wrote: Hey.. I opened issue http://issues.apache.org/activemq/browse/ AMQ-848 to track. Folks please check the new LICENSE https://svn.apache.org/repos/asf/incubator/activemq/branches/ activemq-4.0.2/assembly/src/release/LICENSE.txt It seems to me that both jetty and spring also use the Apache license. I would think it's ok if I remove those copies of the LICENSE right? On 7/27/06, Kevan Miller [EMAIL PROTECTED] wrote: Looks like your base LICENSE and NOTICE files contain only AL 2.0 license information. Since you're releasing code under multiple licenses, according to http://www.apache.org/dev/release.html , all license/notice information needs to be placed there. --kevan On Jul 26, 2006, at 1:26 AM, Hiram Chirino wrote: Since it was brought up, and folks concurred that it's about time to put out a bug fix release for ActiveMQ, I've put together a binary release of ActiveMQ 4.0.2: http://people.apache.org/~chirino/incubator-activemq-4.0.2-RC1/ http://people.apache.org/%7Echirino/incubator-activemq-4.0.2-RC1/ maven1/incubator-activemq/distributions/ http://people.apache.org/%7Echirino/incubator-activemq-4.0.1- RC1/ maven1/incubator-activemq/distributions/ Maven 1 and Maven 2 repos for this release can be found at: http://people.apache.org/~chirino/incubator-activemq-4.0.2- RC1http://people.apache.org/%7Echirino/incubator-activemq-4.0.2-RC1 http://people.apache.org/%7Echirino/incubator-activemq-4.0.1- RC1/ Here's the wiki page for the release notes (they should soon get mirrored to the activemq static website) : http://goopen.org/confluence/display/ACTIVEMQ/ActiveMQ+4.0.2 +Release http://goopen.org/confluence/display/ACTIVEMQ/ActiveMQ+4.0.1 +Release Please vote to approve this release binary [ ] +1 Release the binary as Apache ActiveMQ 4.0.2 [ ] -1 Veto the release (provide specific comments) If this vote passes, then we will then ask the Incubator PMC for their blessing to ship this release officially. Here's my +1 -- Regards, Hiram Blog: http://hiramchirino.com -- Regards, Hiram Blog: http://hiramchirino.com -- James --- http://radio.weblogs.com/0112098/
Re: Welcome David Jencks as the newest memeber of the Geronimo PMC
Congratulations David! Regards, John Matt Hogstrom wrote: The PMC would like to welcome David Jencks as the newest member of the PMC. Please join us in welcoming David. Matt
1.1.1-SNAPSHOT Memory Problems
Jeff just noted that Liferay seems to take an abnormal amount of memory to run. I just redeployed the console twice and got an OutOfMemoryError. When working on the console for 1.1, I could redeploy dozens of times. I think we've introduced a pretty serious memory problem between 1.1 and now. I know we're close to the deadline, but I think we ought to investigate this before shipping 1.1.1. Thanks, Aaron
Re: 1.1.1-SNAPSHOT Memory Problems
Yep..I concur...this is a nasty one and we need to see whats up. This is a blocker IMHO.. Jeff Aaron Mulder wrote: Jeff just noted that Liferay seems to take an abnormal amount of memory to run. I just redeployed the console twice and got an OutOfMemoryError. When working on the console for 1.1, I could redeploy dozens of times. I think we've introduced a pretty serious memory problem between 1.1 and now. I know we're close to the deadline, but I think we ought to investigate this before shipping 1.1.1. Thanks, Aaron
Re: wiki migration
Hernan Cunico wrote: John Sisson wrote: Hernan Cunico wrote: Hi All, this is a friendly reminder that the Moin Moin wiki ( namely wiki.apache.org/geronimo ) is being migrated to the confluence based http://cwiki.apache.org/geronimo Great! Please refrain from continuing updating content to the Moin Moin wiki. The current migration status can me seen at http://cwiki.apache.org/confluence/display//Home I tried looking at the status and got a page not found. I also tried http://cwiki.apache.org/confluence/display/GMOxMoinMoin and got a Not Permitted page. Not sure what the problem is, I just clicked those two links and both worked without logging in. Does anyone else have this problem? Hmm, I logged out and logged back in and it worked. When I was logged in if I went to http://cwiki.apache.org/confluence/dashboard.action where it lists the spaces, the GMOxMoinMoin space is not listed. After I logged out and logged back in again it was listed and I could access the link above. Thanks, John This is the raw content migrated so far from the Moin Moin wiki has not been edited yet, this is a temporary space while migrating. This is the first step of several, later this content will be evaluated for accuracy and then incorporated to one of the cwiki.apache.org/geronimo sub-structures. Comments, suggestions and HELP! are very much welcomed. Will information be moved to space for a particular release? E.G. the build instructions for 1.1.x will differ to 1.2? Yes but first thing first, we need to totally move the Moin Moin content to confluence, get rid of the duplicated/obsolete information (do some housekeeping) and then get the good stuff reorganized into confluence structure. We may potentially need to create additional spaces. Looking at the current organization we have we already have the content organized according to Geronimo versions, we may need to do some reorganization within those spaces (maybe consolidating user's and developer's guide into just user's guide for simplicity). As soon as we have some material to put out for v1.2 we will create a new Apache Geronimo v1.2 space with version specific info. Cheers! Hernan Thanks, John Cheers! Hernan
Re: 1.1.1-SNAPSHOT Memory Problems
Agreed. I'm seeing problems during TCK runs, also. We've obviously regressed somewhere. I'm pretty sure it's happened in the last two weeks (or at least one of the problems was created in the last two weeks). I've already started looking at the Jira Jeff raised -- GERONIMO-2240. --kevan On Jul 31, 2006, at 6:56 PM, Jeff Genender wrote: Yep..I concur...this is a nasty one and we need to see whats up. This is a blocker IMHO.. Jeff Aaron Mulder wrote: Jeff just noted that Liferay seems to take an abnormal amount of memory to run. I just redeployed the console twice and got an OutOfMemoryError. When working on the console for 1.1, I could redeploy dozens of times. I think we've introduced a pretty serious memory problem between 1.1 and now. I know we're close to the deadline, but I think we ought to investigate this before shipping 1.1.1. Thanks, Aaron
Re: 1.1.1-SNAPSHOT Memory Problems
Yeah, a blocker. As a sanity check, do we get the same problem off of trunk? Regards, Alan Jeff Genender wrote: Yep..I concur...this is a nasty one and we need to see whats up. This is a blocker IMHO.. Jeff Aaron Mulder wrote: Jeff just noted that Liferay seems to take an abnormal amount of memory to run. I just redeployed the console twice and got an OutOfMemoryError. When working on the console for 1.1, I could redeploy dozens of times. I think we've introduced a pretty serious memory problem between 1.1 and now. I know we're close to the deadline, but I think we ought to investigate this before shipping 1.1.1. Thanks, Aaron
[Discussion] Removal of TransactionContextManager
history length=too long About a week ago there was a discussion on the OpenEJB mailing list regarding the TransactionContextManager. In OpenEJB 3 we removed the use of the TCM from Geronimo and replaced it with just a javax.transaction.TransactionManager. This brought all of the openejb containers into alignment. The other big motivation was to ease the integration of OpenEJB and third part libraries, specifically Spring. The problem with the TCM is that if you use it you can't use the TM directly since the TCM needs to know about all TM calls. Additionally, to use the TCM you must demarcate all changes in component context by starting an unspecified transaction context. This is all quite invasive and made OpenEJB hard to use in Spring or plain old Tomcat. That was all fine and good for OpenEJB 3, but as it turns out there is a desire to keep the OpenEJB 2 and 3 code aligned as much as possible, so a discussion started around how to backport the changes to 2. We determined there were two options: 1) wrap the TCM with a class that implements TM but delegates to the TCM - this would be tricky to get working and there is always the problem of demarcating the unspecified transaction context 2) remove the TCM from Geronimo entirely - this could be a lot of work After a quick look at the first option, I decided to try option two. It turned out to be a lot easier than I thought since, the biggest user of TCM was OpenEJB and I had already pulled it out of OpenEJB. I also think I have become the master of using the IntelliJ refactor tools and was able to remove the code without too much hand tweaking. /history I have checked the fruits of this effort into https://svn.apache.org/ repos/asf/geronimo/branches/dain/notcm and there is a matching OpenEJB branch that is checked out with maven m:co. I have not updated the m2 build yet, as it was finalized during this work. For those of you that are following the Jencks project, which wraps the Geronimo transaction and connector modules with Spring bean factories, I have created a branch there also, which contains a massive simplification due to the refactors in the removal of the Geronimo TCM. Here are some fun examples from that project: http://fisheye.codehaus.org/browse/jencks/branches/notcm/src/test/ resources/org/jencks/samples/outbound/jencks-tranql.xml?r=112 http://fisheye.codehaus.org/browse/jencks/branches/notcm/src/test/ resources/org/jencks/spring-request-reply-jta.xml?r=112 So what does everyone think about removing the TCM in general? After that I think we may want to discuss the specifics of my branch. I may have gotten too refactory happy :) Details on the specific changes I made follow: TransactionContextManager - Removed TransactionContextManager and replaced all uses with a plain old TransactionManager Removed all code from web containers, app client and timer that was simply demarcating an unspecified transaction context, which is no longer needed TransactionManager -- Merged XATerminator portion of TCM into GeronimoTransactionManager which is a subclass of TransactionManagerImpl Improved tx thread association code so we can throw an error if someone attempts to resume a tx associated with another thread Added TransactionManagerMonitor which is used by the connection tracker to know when a transaction context has changed UserTransaction --- TransactionManagerImpl now implements UserTransaction to ease integration with third party libraries such as Spring Removed OnlineUserTransaction since it was only really used by OpenEJB and it has it's own UserTransaction implementation Web containers now use GeronimoUserTransaction which is an always on wrapper around a transaction manager Third party support --- Moved use of ServerInfo from HOWLLog to HOWLLogGBean so it can be more easily use by third party libraries Moved connector related transaction data to connector module Replace use of Geronimo's thread pool with a concurrent executor -dain
Re: Roadmap for 3.0
On 8/1/06, Philip Dodds [EMAIL PROTECTED] wrote: I agree that the source restructuring doesn't make much sense, though that is only really true if we can start getting weekly builds available to people to use so they don't have to download M? releases and then find out they need something from head. Agreed. I must sort out the problems that happen when deploying a snapshot. It seems that maven fails to upload them. James is setting up a continuum server on http://goopen.org:8080/continuum/servlet/continuum and I hope we will be able to use it for nightly (or weekly) snapshot deployments . As for the clean packaging this is really trying to reduce the download so that we can have a core download, components download and then the things like servicemix-web outside. This can probably be done with just working inside the apache-servicemix assembly project. Cool :) P On 7/31/06, Guillaume Nodet [EMAIL PROTECTED] wrote: On 7/24/06, Philip Dodds [EMAIL PROTECTED] wrote: Before pushing 3.0 out of the door I think we need to address : 1/ The project structure so that we can build core/components and tooling independently 2/ The packaging so we can create clean packages Any reason why we should do that before releasing 3.0 ? The thread about the project structure (see http://www.nabble.com/Source-re-structuring-tf2017112.html) is still undecided. Could you also be more precise about what you are referring to as clean packages ? distributions ? 3/ Documentation - I don't think producing a release with re-visting the documentation is going to help people +1 I think 3.0 is a big and important release for ServiceMix and we should make sure our ducks are in a row before putting it out there Agreed. But I'm not sure that restructuring the source code will have a great impact on users. Once the release is out, they will mostly use it, not build it. And offering several distributions may be addressed later. ServiceMix latest release (not milestone) is more than 8 months old, and while I agree that we need to work on documentation, I'm not very keen on delaying the release too much. It will be difficult to delay the release while not developing new features, and at the same time, adding new features will certainly delay the release due to stabilization time, etc... Working on fixing all unit tests, bug fixes, samples and documentation should be enough. Maybe we could add some critical features (the JNDI factory to integrate web apps ?), but we have to minimize their number, else we will never release anything. Btw, we can not discuss TCK things in detail, but I just want to say that we should be able to pass the full TCK soon (still waiting for the mailing list and svn repo). I think this makes a good plan for a 3.0 release, but discussion is welcome. Pushing a M3 / RC1 this month (when ?) and a 3.0 asap in september sounds like a good plan to me. P On 7/24/06, Guillaume Nodet [EMAIL PROTECTED] wrote: I guess it mainly depends if we want a timed-box release or a featured-box release ;) But we must first agree on that... Cheers, Guillaume Nodet On 7/24/06, Philip Dodds [EMAIL PROTECTED] wrote: +1 for getting a roadmap in place, though until we have a clear set of stuf that we want in place should be set a release date? P On 7/24/06, Guillaume Nodet [EMAIL PROTECTED] wrote: I' d like to start a discussion about ServiceMix roadmap for 3.0 . IMHO, we should release a 3.0 asap, and I want to propose that we release 3.0 at the end of August. The main point I' d like to focus on are: * JBI TCK (which should be available to all committers that have signed a NDA) * bug fixes * documentation Any thoughts ? Cheers, Guillaume Nodet -- Cheers, Guillaume Nodet -- Cheers, Guillaume Nodet
Re: [Discussion] Removal of TransactionContextManager
On Jul 31, 2006, at 4:51 PM, Aaron Mulder wrote: +1, so long as the threads are still coming from a Geronimo thread pool under the covers (even if its hidden by the concurrent executor interface). I'd really like to have more components using Geronimo thread pools rather than fewer, since right now there's really no way to view or manage all the threads in the server. Absolutely! The Geronimo standalone servers still supply a Geronimo thread pool to the work manager, but now third parties can make the same demands on our code (i.e., they want to use their own pools). For example, in the Jencks project we simply supply new PooledExecutor (threadPoolSize). -dain
Re: JIRAs adopter query/policy?
Sachin Patel wrote: As the Geronimo user base grows, it is important that we be able to distinguish between JIRAs open during a development cycle to those that are being hit in the field or requested by companies who either use Geronimo or build products and or plugins on top of it. So I suggest we provide a restricted adopter required field in JIRA. This adopter field would be exposed to JIRA users who request and identify themselves as adopters. So just like our query for available patches, we can easily query these and help ensure that these issues that companies face get the necessary attention and help resolve them faster then they would be otherwise. I don't think that we need to track this distinction. I cannot conceive of a problem that this would solve that using Jira as it stands today does not accommodate. Regards. Alan
Re: [Discussion] Removal of TransactionContextManager
On 7/31/06, Dain Sundstrom [EMAIL PROTECTED] wrote: +1, so long as the threads are still coming from a Geronimo thread pool under the covers (even if its hidden by the concurrent executor interface). I'd really like to have more components using Geronimo thread pools rather than fewer, since right now there's really no way to view or manage all the threads in the server. Absolutely! The Geronimo standalone servers still supply a Geronimo thread pool to the work manager, but now third parties can make the same demands on our code (i.e., they want to use their own pools). For example, in the Jencks project we simply supply new PooledExecutor (threadPoolSize). Great! Thanks, Aaron
Re: [VOTE] Release Apache ActiveMQ 4.0.2
If I understand the memo that came down from legal, we need to do this for this patch release. Regards, Alan Brian McCallister wrote: Are you making this change for 4.0.2? -Brian On Jul 28, 2006, at 12:24 AM, James Strachan wrote: Looks good to me. Thanks for sorting this out Hiram. On 7/27/06, Hiram Chirino [EMAIL PROTECTED] wrote: Hey.. I opened issue http://issues.apache.org/activemq/browse/AMQ-848 to track. Folks please check the new LICENSE https://svn.apache.org/repos/asf/incubator/activemq/branches/activemq-4.0.2/assembly/src/release/LICENSE.txt It seems to me that both jetty and spring also use the Apache license. I would think it's ok if I remove those copies of the LICENSE right? On 7/27/06, Kevan Miller [EMAIL PROTECTED] wrote: Looks like your base LICENSE and NOTICE files contain only AL 2.0 license information. Since you're releasing code under multiple licenses, according to http://www.apache.org/dev/release.html , all license/notice information needs to be placed there. --kevan On Jul 26, 2006, at 1:26 AM, Hiram Chirino wrote: Since it was brought up, and folks concurred that it's about time to put out a bug fix release for ActiveMQ, I've put together a binary release of ActiveMQ 4.0.2: http://people.apache.org/~chirino/incubator-activemq-4.0.2-RC1/ http://people.apache.org/%7Echirino/incubator-activemq-4.0.2-RC1/ maven1/incubator-activemq/distributions/ http://people.apache.org/%7Echirino/incubator-activemq-4.0.1-RC1/ maven1/incubator-activemq/distributions/ Maven 1 and Maven 2 repos for this release can be found at: http://people.apache.org/~chirino/incubator-activemq-4.0.2-RC1http://people.apache.org/%7Echirino/incubator-activemq-4.0.2-RC1 http://people.apache.org/%7Echirino/incubator-activemq-4.0.1-RC1/ Here's the wiki page for the release notes (they should soon get mirrored to the activemq static website) : http://goopen.org/confluence/display/ACTIVEMQ/ActiveMQ+4.0.2+Release http://goopen.org/confluence/display/ACTIVEMQ/ActiveMQ+4.0.1+Release Please vote to approve this release binary [ ] +1 Release the binary as Apache ActiveMQ 4.0.2 [ ] -1 Veto the release (provide specific comments) If this vote passes, then we will then ask the Incubator PMC for their blessing to ship this release officially. Here's my +1 -- Regards, Hiram Blog: http://hiramchirino.com -- Regards, Hiram Blog: http://hiramchirino.com -- James --- http://radio.weblogs.com/0112098/
[jira] Resolved: (GERONIMO-2253) No way to get information on a plugin you're about to install through the console
[ http://issues.apache.org/jira/browse/GERONIMO-2253?page=all ] Aaron Mulder resolved GERONIMO-2253. Fix Version/s: 1.1.1 (was: 1.1.x) Resolution: Fixed No way to get information on a plugin you're about to install through the console - Key: GERONIMO-2253 URL: http://issues.apache.org/jira/browse/GERONIMO-2253 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: Plugins Affects Versions: 1.1 Reporter: Aaron Mulder Assigned To: Aaron Mulder Fix For: 1.1.1 You can't check the license, prerequisites, etc. without manually browsing to the plugin repository site -- 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: Can't use car-maven-plugin today!
First, you must specify 1.2-SNAPSHOT, there is no released version. It only exists here: http://people.apache.org/repo/m2-snapshot-repository/org/apache/ geronimo/plugins/car-maven-plugin/1.2-SNAPSHOT/ And it looks valid enough to me. Sorry, I've been flying all day. Might be if you were trying to pull a bunch of deps from people that it blocked you... try again. I am unaware of any reason why this would not work... and I did not change anything. --jason On Jul 31, 2006, at 9:04 AM, Aaron Mulder wrote: So I tried on a different machine today. If I specify no version number for car-maven-plugin in the POM, I get: [ERROR] BUILD ERROR [INFO] -- -- [INFO] The plugin 'org.apache.geronimo.plugins:car-maven-plugin' does not exist or no valid version could be found If I specify the version 1.2-SNAPSHOT, I get: [WARNING] Unable to get resource from repository apache-snapshots (http://people.apache.org/repo/m2-snapshot-repository) Downloading: http://www.ibiblio.org/maven/ org.apache.geronimo.plugins/poms/car-maven-plugin-1.2-SNAPSHOT.pom [WARNING] Unable to get resource from repository ibiblio-maven-1 (http://www.ibiblio.org/maven) [INFO] -- -- [ERROR] BUILD ERROR [INFO] -- -- [INFO] Failed to resolve artifact. GroupId: org.apache.geronimo.plugins ArtifactId: car-maven-plugin Version: 1.2-SNAPSHOT Reason: Unable to download the artifact from any repository Indeed, if I look, there is no org/apache/geronimo/plugins/car-maven-plugin/1.2-SNAPSHOT/car-maven- plugin-1.2-SNAPSHOT.pom in the Apache snapshot repository (http://people.apache.org/repo/m2-snapshot-repository) There is only org/apache/geronimo/plugins/car-maven-plugin/1.2- SNAPSHOT/http://people.apache.org/repo/m2-snapshot-repository/org/ apache/geronimo/plugins/car-maven-plugin/1.2-SNAPSHOT/car-maven- plugin-1.2-20060716.224116-1.pom What's up? How am I supposed to use the car-maven-plugin when the version numbers don't match up? (I'm using Maven 2.0.4 on OS X) Thanks, Aaron
Re: Welcome David Jencks as the newest memeber of the Geronimo PMC
Saaaweet! --jason On Jul 31, 2006, at 12:48 PM, Matt Hogstrom wrote: The PMC would like to welcome David Jencks as the newest member of the PMC. Please join us in welcoming David. Matt
