[jira] Commented: (AMQ-935) Port the JmsLogAppender API from ActiveMQ 3.2.4 to ActiveMQ 4.1
[
https://issues.apache.org/activemq/browse/AMQ-935?page=comments#action_37018 ]
Adrian Co commented on AMQ-935:
---
Patch applied. Just need to update the test case to properly test the
functionality.
> Port the JmsLogAppender API from ActiveMQ 3.2.4 to ActiveMQ 4.1
> ---
>
> Key: AMQ-935
> URL: https://issues.apache.org/activemq/browse/AMQ-935
> Project: ActiveMQ
> Issue Type: New Feature
>Affects Versions: 4.1
>Reporter: Bruce Snyder
> Assigned To: Adrian Co
> Attachments: JmsLogAppenderSupport.diff.txt
>
>
> Porting the following classes from ACTIVEMQ_3_2_4:
> {code}
> modules/core/src/test/org/activemq/util/test-log4j.properties
> modules/core/src/java/org/activemq/util/JmsLogAppender.java
> modules/core/src/java/org/activemq/util/JmsLogAppenderSupport.java
> modules/core/src/java/org/activemq/util/JndiJmsLogAppender.java
> modules/core/src/test/org/activemq/util/JmsLogAppenderTest.java
> {code}
> to ActiveMQ 4.1:
> {code}
> activemq-optional/src/test/java/org/apache/activemq/util
> activemq-optional/src/test/java/org/apache/activemq/util/JmsLogAppenderTest.java
> activemq-optional/src/test/resources/test-log4j.properties
> activemq-optional/src/main/java/org/apache/activemq/util
> activemq-optional/src/main/java/org/apache/activemq/util/JndiJmsLogAppender.java
> activemq-optional/src/main/java/org/apache/activemq/util/JmsLogAppenderSupport.java
> activemq-optional/src/main/java/org/apache/activemq/util/JmsLogAppender.java
> {code}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://issues.apache.org/activemq/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Assigned: (AMQ-935) Port the JmsLogAppender API from ActiveMQ 3.2.4 to ActiveMQ 4.1
[ https://issues.apache.org/activemq/browse/AMQ-935?page=all ]
Adrian Co reassigned AMQ-935:
-
Assignee: Adrian Co (was: Hiram Chirino)
> Port the JmsLogAppender API from ActiveMQ 3.2.4 to ActiveMQ 4.1
> ---
>
> Key: AMQ-935
> URL: https://issues.apache.org/activemq/browse/AMQ-935
> Project: ActiveMQ
> Issue Type: New Feature
>Affects Versions: 4.1
>Reporter: Bruce Snyder
> Assigned To: Adrian Co
> Attachments: JmsLogAppenderSupport.diff.txt
>
>
> Porting the following classes from ACTIVEMQ_3_2_4:
> {code}
> modules/core/src/test/org/activemq/util/test-log4j.properties
> modules/core/src/java/org/activemq/util/JmsLogAppender.java
> modules/core/src/java/org/activemq/util/JmsLogAppenderSupport.java
> modules/core/src/java/org/activemq/util/JndiJmsLogAppender.java
> modules/core/src/test/org/activemq/util/JmsLogAppenderTest.java
> {code}
> to ActiveMQ 4.1:
> {code}
> activemq-optional/src/test/java/org/apache/activemq/util
> activemq-optional/src/test/java/org/apache/activemq/util/JmsLogAppenderTest.java
> activemq-optional/src/test/resources/test-log4j.properties
> activemq-optional/src/main/java/org/apache/activemq/util
> activemq-optional/src/main/java/org/apache/activemq/util/JndiJmsLogAppender.java
> activemq-optional/src/main/java/org/apache/activemq/util/JmsLogAppenderSupport.java
> activemq-optional/src/main/java/org/apache/activemq/util/JmsLogAppender.java
> {code}
--
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: Wiki page for building Geronimo with m2
I have been trying to build geronimo with the complete bootstrap and it has been impossible. The "step by step" way worked but when I tryed to do a mvn clean install, it always failed. I am going crazy about this issue since I haven't even been able to start working on anything. I would appreciate it very much if someone could take a look about this issue since its too big for a new comer like me. Thanks in advance!Eduardo2006/9/25, Joe Bohn <[EMAIL PROTECTED]>: Jay D. McHugh wrote:> Hello all,>> Am I correct in thinking that since the specs were changed, trunk can no> longer be built with a simple 'bootstrap' and must now actually be built> step by step following the 'bootstrap without a full "bootstrap"' > directions?I believe that this is correct (or at least that's the procedure I nowfollow building the specs only with jdk 1.5).>> If that is true I could try to modify the wiki page to remove the simple > directions and lead everyone to the step-by-step directions right away> (I would need to have someone take a look when I was done though - I> don't trust myself to change anything without review). Go for it!Joe
Re: Micro-G
The initial commit is out there with rev. 449892. I can deploy the updated tomcat car and then subsequently the tomcat-deployer car produced with these changes. I can then subsequently deploy a simple web application on tomcat. I have also done the same with jetty, jetty-deploy, and again a simple web application. However, to this I have to cheat a little at the moment. I manually copy the 1.2-SNAPSHOT jars necessary for tomcat, tomcat-deployer, jetty, jetty-deployer, and most recently geronimo-clustering (due to the dependency from jetty to geronimo-clustering) into the assemblies repository. This is necessary for the time being because these jars don't exist in any public repository. I also have to cheat and copy the jetty schemas into the schema location (the framework assembly build already includes the tomcat schemas for now). Aaron pointed me to some info on how to get these schemas included in the plugin and copied at deploy time which I will look at next. Finally, for Jetty I also have to modify var\config\config.xml WebBuilder default namespace to reference jetty instead of tomcat so there's still some more work necessary there. There are also some more items that should probably be removed from this framework assembly ... but this is a start. Initial commit to trunk on 09/25/06: Adding assemblies\geronimo-framework Adding assemblies\geronimo-framework\LICENSE.txt Adding assemblies\geronimo-framework\NOTICE.txt Adding assemblies\geronimo-framework\pom.xml Adding assemblies\geronimo-framework\src Adding assemblies\geronimo-framework\src\main Adding assemblies\geronimo-framework\src\main\assembly Adding assemblies\geronimo-framework\src\main\assembly\bin.xml Adding assemblies\geronimo-framework\src\main\var Adding assemblies\geronimo-framework\src\main\var\config Adding assemblies\geronimo-framework\src\main\var\config\config.xml Adding assemblies\geronimo-framework\src\main\var\config\offline-deployer-list Sendingassemblies\pom.xml Sendingconfigs\jetty\pom.xml Adding configs\jetty\src\main Adding configs\jetty\src\main\resources Adding configs\jetty\src\main\resources\META-INF Adding configs\jetty\src\main\resources\META-INF\geronimo-plugin.xml Sendingconfigs\jetty\src\plan\plan.xml Sendingconfigs\jetty-deployer\pom.xml Adding configs\jetty-deployer\src\main Adding configs\jetty-deployer\src\main\resources Adding configs\jetty-deployer\src\main\resources\META-INF Adding configs\jetty-deployer\src\main\resources\META-INF\geronimo-plugin.xml Sendingconfigs\pom.xml Sendingconfigs\tomcat\pom.xml Adding configs\tomcat\src\main Adding configs\tomcat\src\main\resources Adding configs\tomcat\src\main\resources\META-INF Adding configs\tomcat\src\main\resources\META-INF\geronimo-plugin.xml Sendingconfigs\tomcat\src\plan\plan.xml Sendingconfigs\tomcat-deployer\pom.xml Adding configs\tomcat-deployer\src\main Adding configs\tomcat-deployer\src\main\resources Adding configs\tomcat-deployer\src\main\resources\META-INF Adding configs\tomcat-deployer\src\main\resources\META-INF\geronimo-plugin.xml Transmitting file data .. Committed revision 449892. Joe Bohn wrote: I've done some work on a new assembly that I've nicknamed "Micro-G" (I know .. not very creative). The name that I'm using under geronimo/assemblies is "geronimo-framework". This is intended to be a new foundational assembly from which any customized Geronimo assembly could be built by installing plugins we would provide (starting with tomcat and jetty plugins). Hopefully this could help us eliminate the need to provide so many canned configurations with each release. I'm pretty sure we would probably still want to provide at least one full j2ee server configuration that we certified against, but we could potentially drop the little-G assemblies and hopefully avoid additional future assemblies based upon different combinations of components in the works. So far, I've been doing this on my local image. I would like to get this code (incomplete as it currently is) checked into trunk to better manage the changes and to share the effort. Is this considered a "controversial change"? Should I first provide a patch as it currently stands so that folks can comment on it prior to a commit(ala RTC)? I'm inclined to just commit the code since it is relatively self contained at the moment, safe, and can be easily reverted. I think the only controversial change thus far might be that I updated the default port selections on the tomcat configuration so that if you install a tomcat plugin on this framework assembly you will end up with the same port configurations currently available on our existing tomcat distributions.
[jira] Commented: (GERONIMO-2417) Create a new framework assembly to be used as a fundamental Geronimo assembly building block
[ http://issues.apache.org/jira/browse/GERONIMO-2417?page=comments#action_12437726 ] Joe Bohn commented on GERONIMO-2417: Initial commit to trunk on 09/25/06: Adding assemblies\geronimo-framework Adding assemblies\geronimo-framework\LICENSE.txt Adding assemblies\geronimo-framework\NOTICE.txt Adding assemblies\geronimo-framework\pom.xml Adding assemblies\geronimo-framework\src Adding assemblies\geronimo-framework\src\main Adding assemblies\geronimo-framework\src\main\assembly Adding assemblies\geronimo-framework\src\main\assembly\bin.xml Adding assemblies\geronimo-framework\src\main\var Adding assemblies\geronimo-framework\src\main\var\config Adding assemblies\geronimo-framework\src\main\var\config\config.xml Adding assemblies\geronimo-framework\src\main\var\config\offline-deployer-list Sendingassemblies\pom.xml Sendingconfigs\jetty\pom.xml Adding configs\jetty\src\main Adding configs\jetty\src\main\resources Adding configs\jetty\src\main\resources\META-INF Adding configs\jetty\src\main\resources\META-INF\geronimo-plugin.xml Sendingconfigs\jetty\src\plan\plan.xml Sendingconfigs\jetty-deployer\pom.xml Adding configs\jetty-deployer\src\main Adding configs\jetty-deployer\src\main\resources Adding configs\jetty-deployer\src\main\resources\META-INF Adding configs\jetty-deployer\src\main\resources\META-INF\geronimo-plugin.xml Sendingconfigs\pom.xml Sendingconfigs\tomcat\pom.xml Adding configs\tomcat\src\main Adding configs\tomcat\src\main\resources Adding configs\tomcat\src\main\resources\META-INF Adding configs\tomcat\src\main\resources\META-INF\geronimo-plugin.xml Sendingconfigs\tomcat\src\plan\plan.xml Sendingconfigs\tomcat-deployer\pom.xml Adding configs\tomcat-deployer\src\main Adding configs\tomcat-deployer\src\main\resources Adding configs\tomcat-deployer\src\main\resources\META-INF Adding configs\tomcat-deployer\src\main\resources\META-INF\geronimo-plugin.xml Transmitting file data .. Committed revision 449892. > Create a new framework assembly to be used as a fundamental Geronimo assembly > building block > > > Key: GERONIMO-2417 > URL: http://issues.apache.org/jira/browse/GERONIMO-2417 > Project: Geronimo > Issue Type: Improvement > Security Level: public(Regular issues) > Components: general >Affects Versions: 1.2 >Reporter: Joe Bohn > Assigned To: Joe Bohn > > It seems clear that the direction of Geronimo is to use the the modular > framework and plugin capability to facilitate the creation of custom > assemblies by users, third party solution distributors, etc... There are > also issue with a proliferation of geronimo assemblies due to the dependence > on either the tomcat or jetty based assemblies. In order to address these > issues we need a new, core assembly that can be the foundation of any other > custom built assembly. The minimal assemblies are a good start but the fact > that there are two and they include the web containers makes not quite what > we need for a strating point. We need an assembly that includes just the > fundamental infrastructure and enough capability to be used as a base for > deploying plugins to create any of the existing assemblies or some entirely > new custom assembly by a user of Geronimo. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (GERONIMO-2427) NamingBuilders should handle both j2ee 1.4 and jee 5 environment entries (such as resource-refs)
[ http://issues.apache.org/jira/browse/GERONIMO-2427?page=all ] David Jencks closed GERONIMO-2427. -- Resolution: Fixed Axis service-ref builder and env entry builder modified to use parameterized namespaces, rev 449846 sandbox javaee set to supply both namespaces rev 449847 > NamingBuilders should handle both j2ee 1.4 and jee 5 environment entries > (such as resource-refs) > > > Key: GERONIMO-2427 > URL: http://issues.apache.org/jira/browse/GERONIMO-2427 > Project: Geronimo > Issue Type: Improvement > Security Level: public(Regular issues) > Components: buildsystem >Affects Versions: 1.2 >Reporter: David Jencks > Assigned To: David Jencks > Fix For: 1.2 > > > (related to GERONIMO-2414). Currently the ref builders only take one kind of > e.g. resource ref, either j2ee 1.4 or jee5. It's pretty easy to make them > accept either kind, thus allowing incremental migration to jee5 deployment > descriptors. -- 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: SSL authentication/authorization patch
The keystore problem has been addressed (the patch we talked about before should fix it, right?) Checking the DN should be possible through the JaasCertificationAuthenticationModule (I'm not too sure about the name, I haven't looked at the code in a while); the entire client certificate chain is passed in so you should have all the data you need. the setEnabledCipherSuites is not currently possible without the heavy modifications you mentioned (do you agree Hiram?). I think the best method for doing this would be to create a reflection-based createTransport call (just like the ones there, but with support for custom objects). That would take a lot of work too, but it would also be more useful and compatible with the current architecture. On 9/25/06, Kelly Campbell <[EMAIL PROTECTED]> wrote: Ok, that works for relatively basic options, but what about the more complex stuff I need to do? Specifically turning off weak ciphers on the connection (via socket.setEnabledCipherSuites), and verifying the server's DN. Also, I need to use different settings for setting up the keystore and truststore (e.g. if one is in pkcs12 format and the other is in jks format). Someone else on the user's mailing list asked a similar question about customizing the ssl keystore. If I add a SocketFactory param in the createTransport calls, it requires lots of changes to support it across all the different composite transports and such. Is there perhaps something similar to the options that can have objects associated with a key for params to the transports that will get passed along to all the sub transports so the SSL one will get it? Thanks, Kelly On 9/22/06, Sepand M <[EMAIL PROTECTED]> wrote: > Some of the more experienced people can correct me on this, but I think > you can set socket options using "socket._option_" arguments in the URI > (e.g. "ssl://localhost:61616?socket.my_option=true"). I'm not sure if > this would give all the flexibility you need, but it's a start. If that > doesn't work, for SSL specific stuff, I added a > SslActiveMQConnectionFactory (or a similar name). > > Any good? > Sepand > > Kelly Campbell wrote: > > Thanks Sepand. I did review those instructions earlier. > > > > What about the other requirements to be able to set specific options > > on the socket, e.g. not allowing weak ciphers? I think having the > > config in the URL is good, but not sufficient in this case. I'd like > > to propose adding a SocketFactory parameter to a new constructor on > > the ActiveMQConnectionFactory (actually the code for this is almost > > complete). This would be useful for not only SSL connections, but > > other tcp connections if the user wants to customize some of the > > socket options. > > > > Thanks, > > Kelly > > > > On 9/21/06, Sepand M <[EMAIL PROTECTED]> wrote: > >> Yeah, we realized this was needed, but I didn't have time (my work term > >> at the company was ending). > >> I've left instructions for people taking over this project on how to do > >> this (it just takes one setter and a well placed call from that setter). > >> I'm not sure when it will be done though. > >> > >> - Sepand > >> > >> Hiram Chirino wrote: > >> > On 9/21/06, Hiram Chirino <[EMAIL PROTECTED]> wrote: > >> >> On 9/21/06, Kelly Campbell <[EMAIL PROTECTED]> wrote: > >> >> > Thanks for getting this submitted Sepand, and thanks for patching > >> >> it in Hiram. > >> >> > > >> >> > I'm looking at how best to configure the keystore settings more > >> >> > dynamically without using the default system properties or > >> anything in > >> >> > the URL. It looks like I'd need to be able to pass in a > >> >> > javax.net.ssl.SSLContext or SSLSocketFactory. I'd also like to > >> be able > >> >> > to pass these in so I can provide an implementation that does some > >> >> > extra security checks, e.g. checking that the server's DN is > >> what we > >> >> > expect, turning off weak ciphers. > >> >> > > >> >> > >> >> It would be nice if they were properties on the ssl transport server > >> >> so that you can configure them using the URI... like: > >> >> > >> >> ssl://localhost:61617?keystore=foo.ks&truststore=foo.ts > >> >> > >> >> > The part I'm struggling with now is where to create this API for > >> the > >> >> > client. Should it be a new constructor on > >> ActiveMQConnectionFactory, > >> >> > or should I add a new overridden > >> ActiveMQSecureConnectionFactory? Or > >> >> > should I just override it in my own code base, and not have this in > >> >> > the activemq code at all? > >> >> > >> >> Just add properties to the SslTransportServer and make sure they have > >> >> setters. > >> >> > >> > > >> > And properties to the SslTransport if you want to set those properties > >> > on the client connect URL > >> > > >> >> > > >> >> > Thanks, > >> >> > Kelly > >> >> > > >> >> > On 9/11/06, Hiram Chirino <[EMAIL PROTECTED]> wrote: > >> >> > > starting to look into it now. thx for the patch! > >> >> > > > >> >> > > On 9/5/06, Sepand M <[EMAIL PROTECTE
[jira] Created: (AMQ-941) OutOfMemoryError in OpenWireFormat.
OutOfMemoryError in OpenWireFormat. - Key: AMQ-941 URL: https://issues.apache.org/activemq/browse/AMQ-941 Project: ActiveMQ Issue Type: Bug Components: Broker Affects Versions: 4.1 Environment: linux, jdk1.6 Reporter: Kelly Campbell Exception in thread "ActiveMQ Transport Server: tcp://localhost:61616" java.lang.OutOfMemoryError: Java heap space at org.apache.activemq.openwire.OpenWireFormat.(OpenWireFormat.java:60) at org.apache.activemq.openwire.OpenWireFormat.(OpenWireFormat.java:65) at org.apache.activemq.openwire.OpenWireFormatFactory.createWireFormat(OpenWireFormatFactory.java:58) at org.apache.activemq.transport.tcp.TcpTransportServer.run(TcpTransportServer.java:164) at java.lang.Thread.run(Thread.java:619) Java heap histogram (top 50 only): num #instances#bytes class name -- 1: 65042603600 [Lorg.apache.activemq.command.DataStructure; 2: 7388 9818352 [B 3: 32554 3305656 4: 32554 2866464 5: 26761 2321496 [Ljava.util.HashMap$Entry; 6: 41208 1935824 7: 26582 1605224 [Ljava.lang.Object; 8: 14316 1573672 [C 9: 2777 1528528 10: 38976 1247232 edu.emory.mathcs.backport.java.util.concurrent.ConcurrentHashMap$Segment 11: 2777 1237080 12: 26731 1069240 java.util.HashMap 13: 2458 992592 14: 24395 780640 org.apache.activemq.filter.DestinationMapNode 15: 32011 768264 java.util.HashMap$Entry 16: 38976 651464 [Ledu.emory.mathcs.backport.java.util.concurrent.ConcurrentHashMap$HashEntry; 17: 38984 623744 edu.emory.mathcs.backport.java.util.concurrent.locks.ReentrantLock$NonfairSync 18: 25303 607272 java.util.ArrayList 19: 23150 555600 java.lang.String 20: 3100 297600 java.lang.Class 21: 3536 266144 [I 22:61 250832 [Lorg.apache.activemq.command.ConsumerId; 23: 3452 226136 [S 24: 4446 207928 [[I 25: 2436 194880 [Ledu.emory.mathcs.backport.java.util.concurrent.ConcurrentHashMap$Segment; 26: 2436 116928 edu.emory.mathcs.backport.java.util.concurrent.ConcurrentHashMap 27: 314 100480 28: 3593 86232 edu.emory.mathcs.backport.java.util.concurrent.ConcurrentHashMap$HashEntry 29: 464 77952 org.apache.activemq.command.ActiveMQMessage 30: 2328 71616 [Ljava.lang.String; 31: 1453 69744 org.apache.activemq.command.ProducerId 32: 1434 68832 org.apache.activemq.management.CountStatisticImpl 33: 1645 65800 org.apache.activemq.command.SessionId 34: 1257 60336 org.apache.activemq.command.ActiveMQTempQueue 35: 658 52640 java.lang.reflect.Method 36: 3251 52016 edu.emory.mathcs.backport.java.util.concurrent.atomic.AtomicBoolean 37: 1235 49400 org.apache.activemq.command.ProducerInfo 38: 1928 46272 java.util.Hashtable$Entry 39: 1382 44224 java.lang.ref.SoftReference 40: 334 40080 java.net.SocksSocketImpl 41: 350 39200 java.lang.Thread 42: 647 36232 edu.emory.mathcs.backport.java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask 43: 853 34120 org.apache.activemq.command.MessageId 44: 526 33664 java.lang.reflect.Constructor 45: 323 33592 org.apache.activemq.broker.jmx.ManagedTransportConnection 46: 1365 32760 javax.management.ObjectName$Property 47: 322 30912 org.apache.activemq.transport.tcp.TcpTransport 48: 1196 28704 org.apache.activemq.state.ProducerState 49: 390 28080 org.apache.activemq.broker.region.IndirectMessageReference 50: 348 27840 [Ljava.lang.ThreadLocal$ThreadLocalMap$Entry; -- 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: SSL authentication/authorization patch
Ok, that works for relatively basic options, but what about the more complex stuff I need to do? Specifically turning off weak ciphers on the connection (via socket.setEnabledCipherSuites), and verifying the server's DN. Also, I need to use different settings for setting up the keystore and truststore (e.g. if one is in pkcs12 format and the other is in jks format). Someone else on the user's mailing list asked a similar question about customizing the ssl keystore. If I add a SocketFactory param in the createTransport calls, it requires lots of changes to support it across all the different composite transports and such. Is there perhaps something similar to the options that can have objects associated with a key for params to the transports that will get passed along to all the sub transports so the SSL one will get it? Thanks, Kelly On 9/22/06, Sepand M <[EMAIL PROTECTED]> wrote: Some of the more experienced people can correct me on this, but I think you can set socket options using "socket._option_" arguments in the URI (e.g. "ssl://localhost:61616?socket.my_option=true"). I'm not sure if this would give all the flexibility you need, but it's a start. If that doesn't work, for SSL specific stuff, I added a SslActiveMQConnectionFactory (or a similar name). Any good? Sepand Kelly Campbell wrote: > Thanks Sepand. I did review those instructions earlier. > > What about the other requirements to be able to set specific options > on the socket, e.g. not allowing weak ciphers? I think having the > config in the URL is good, but not sufficient in this case. I'd like > to propose adding a SocketFactory parameter to a new constructor on > the ActiveMQConnectionFactory (actually the code for this is almost > complete). This would be useful for not only SSL connections, but > other tcp connections if the user wants to customize some of the > socket options. > > Thanks, > Kelly > > On 9/21/06, Sepand M <[EMAIL PROTECTED]> wrote: >> Yeah, we realized this was needed, but I didn't have time (my work term >> at the company was ending). >> I've left instructions for people taking over this project on how to do >> this (it just takes one setter and a well placed call from that setter). >> I'm not sure when it will be done though. >> >> - Sepand >> >> Hiram Chirino wrote: >> > On 9/21/06, Hiram Chirino <[EMAIL PROTECTED]> wrote: >> >> On 9/21/06, Kelly Campbell <[EMAIL PROTECTED]> wrote: >> >> > Thanks for getting this submitted Sepand, and thanks for patching >> >> it in Hiram. >> >> > >> >> > I'm looking at how best to configure the keystore settings more >> >> > dynamically without using the default system properties or >> anything in >> >> > the URL. It looks like I'd need to be able to pass in a >> >> > javax.net.ssl.SSLContext or SSLSocketFactory. I'd also like to >> be able >> >> > to pass these in so I can provide an implementation that does some >> >> > extra security checks, e.g. checking that the server's DN is >> what we >> >> > expect, turning off weak ciphers. >> >> > >> >> >> >> It would be nice if they were properties on the ssl transport server >> >> so that you can configure them using the URI... like: >> >> >> >> ssl://localhost:61617?keystore=foo.ks&truststore=foo.ts >> >> >> >> > The part I'm struggling with now is where to create this API for >> the >> >> > client. Should it be a new constructor on >> ActiveMQConnectionFactory, >> >> > or should I add a new overridden >> ActiveMQSecureConnectionFactory? Or >> >> > should I just override it in my own code base, and not have this in >> >> > the activemq code at all? >> >> >> >> Just add properties to the SslTransportServer and make sure they have >> >> setters. >> >> >> > >> > And properties to the SslTransport if you want to set those properties >> > on the client connect URL >> > >> >> > >> >> > Thanks, >> >> > Kelly >> >> > >> >> > On 9/11/06, Hiram Chirino <[EMAIL PROTECTED]> wrote: >> >> > > starting to look into it now. thx for the patch! >> >> > > >> >> > > On 9/5/06, Sepand M <[EMAIL PROTECTED]> wrote: >> >> > > > Hey guys, >> >> > > > >> >> > > > The patch is done. >> >> > > > It's here: https://issues.apache.org/activemq/browse/AMQ-912 >> >> > > > Hope you like it. >> >> > > > It would be really great if you could give an estimate of when >> >> you will >> >> > > > decide if it goes in or not (although I doubt you can =) ). >> >> > > > >> >> > > > Regards, >> >> > > > Sepand >> >> > > > >> >> > > > >> >> > > >> >> > > >> >> > > -- >> >> > > Regards, >> >> > > Hiram >> >> > > >> >> > > Blog: http://hiramchirino.com >> >> > > >> >> > >> >> >> >> >> >> -- >> >> Regards, >> >> Hiram >> >> >> >> Blog: http://hiramchirino.com >> >> >> > >> > >> >> >
Re: svn commit: r449693 [1/2] - in /geronimo/server/trunk/applications/console: geronimo-console-framework/src/main/webapp/WEB-INF/aggregation/ geronimo-console-framework/src/main/webapp/WEB-INF/data/
On 9/25/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
Author: pmcmahan
Date: Mon Sep 25 07:43:09 2006
New Revision: 449693
URL: http://svn.apache.org/viewvc?view=rev&rev=449693
Log:
GERONIMO-2333 JMX Portlet
Whoever done it really knows how to play with Dojo and DWR. I could
play with Dojo in a project and I remember I had a hard time dealing
with these pesky Dojo quirks. What I could read in this commit kicks
ass! I mark it to review again later. Thanks!
These is one thing that looked to me as a tiny bug.
+html>body tbody.scrollContent {
Should it have been 'html.body'?
--
Jacek Laskowski
http://www.laskowski.net.pl
[jira] Closed: (SM-585) Deadlock on BoundedLinkedQueue
[ https://issues.apache.org/activemq/browse/SM-585?page=all ] Robin Byrne closed SM-585. -- Fix Version/s: 3.1 Resolution: Fixed One outstanding issue - see SM-600 > Deadlock on BoundedLinkedQueue > -- > > Key: SM-585 > URL: https://issues.apache.org/activemq/browse/SM-585 > Project: ServiceMix > Issue Type: Bug > Components: servicemix-jbi >Affects Versions: 3.0 > Environment: Windows XP, Java 5 >Reporter: Robin Byrne > Assigned To: Guillaume Nodet >Priority: Critical > Fix For: 3.1 > > Attachments: deadlock.zip > > > We've encountered a problem with slow endpoints leading to a deadlock > situation around the BoundedLinkedQueue. We've reproduce the problem with > Seda, JMS and JCA flows. > The situation is similar to that described for SM-512/SM-521 in the Jira, > although we don't think sendSync is necessarily involved. > Our servicemix configuration started with a JMS endpoint receiving messages > from a topic. The messages were sent to a pipeline which invoked an XSL > transform and forwarded the result to an HTTPComponent. The HTTPComponent > sent the transformed messages to a SOAP service. > We noticed that rapidly sending a large number of messages to the JMS topic > would lock up ServiceMix. That is, > 1) no more messages were sent to the SOAP service > 2) more messages would simply create more blocked threads > 3) ServiceMix never recovered. > We suspected that the slowness of the HTTP interaction was triggering the > problem. To confirm this we replaced the HTTPComponent with a TraceComponent > - modified to wait a configurable number of millis before sending the done > message. > We were able to reliably recreate the problem. We found that, in the blocked > state, all of the worker threads were waiting to put ME's into the > BoundedLinkedQueue. Many of the threads were blocked trying to put 'done' > messages into the queue. > We found that, as long as the Queue for the TraceComponent remained below > capacity, that system continued to work. However, when the queue for that > component hit capacity (100 MEs) the Trace output stopped. Even if the > inbound flow of messages stopped at that point, and all of the other queue's > were empty, the queue for the TraceComponent retained those 100 MEs > After that, the next 100 inbound messages simply filled up the prior Queue > (for the XSLT) until it hit capacity. And so it went until all of Queues > were full. Once all of the Queue's were full each new message created a > thread that blocked trying to put the new ME into the first Queue. > The attached zip file contains the servicemix config file, xslt, and modified > TraceComponent.java necessary to recreate the problem. You will also need a > test harness capable of pushing a lot of messages into the JMS topic. A > burst of 250 messages onto the JMS topic should do it. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (SM-600) Compilation error in Geronimo ServiceMixGBean
Compilation error in Geronimo ServiceMixGBean - Key: SM-600 URL: https://issues.apache.org/activemq/browse/SM-600 Project: ServiceMix Issue Type: Bug Components: geronimo Affects Versions: 3.1 Environment: All Reporter: Robin Byrne Seems to have been introduced by SM-594 Compiling 5 source files to C:\servicemix\src\trunk\geronimo\servicemix-service\target\classes [INFO] [ERROR] BUILD FAILURE [INFO] [INFO] Compilation failure C:\servicemix\src\trunk\geronimo\servicemix-service\src\main\java\org\apache\servicemix\geronimo\ServiceMixGBean.java:[1 65,17] cannot find symbol symbol : method setWorkManager(javax.resource.spi.work.WorkManager) location: class org.apache.servicemix.jbi.container.JBIContainer -- 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
Build error - No reference named ResourceEnvironmentSetter in gbean ....configs/openejb-deployer/1.2-SNAPSHOT/car
Hi, I'm getting the following build error and can't get around it. Does anyone have any clues? I remember DJ's refactored the code recently. Is this something that has not been updated? [INFO] [car:package] [INFO] Packaging module configuration: c:\oss\geronimo\configs\openejb-deployer\target\plan\plan.xml [INFO] [ERROR] BUILD ERROR [INFO] [INFO] No reference named ResourceEnvironmentSetter in gbean org.apache.geronimo.configs/openejb-deployer/1.2-SNAPSHOT/car?ServiceModule=org.apache.geronimo.configs/openejb-deploye r/1.2-SNAPSHOT/car,j2eeType=ModuleBuilder,name=EJBBuilder Jacek -- Jacek Laskowski http://www.laskowski.net.pl
Re: Micro-G
What I have now is dependent upon geronimo-boilerplate-minimal (same as the minimal tomcat assembly which I cloned and used as a starting point). Joe Jason Dillon wrote: How is this new assembly going to work with the boilerplates? --jason On Sep 25, 2006, at 1:20 PM, Joe Bohn wrote: I didn't create a branch earlier because I didn't have experience doing that and thought I'd just start to play with my local build (I know, not a good excuse but it's the truth). I was just getting to the point where I figured I should either create a branch or provide a patch for RTC when we made the switch to CTR last week. Since it appears that there are no strong objections I'll go ahead and commit what I have later today. Thanks, Joe Jacek Laskowski wrote: On 9/25/06, Joe Bohn <[EMAIL PROTECTED]> wrote: So far, I've been doing this on my local image. I would like to get this code (incomplete as it currently is) checked into trunk to better manage the changes and to share the effort. Is this considered a "controversial change"? Should I first provide a patch as it currently stands so that folks can comment on it prior to a commit(ala RTC)? I wonder why you haven't been doing your experiments in a branch or the sandbox? You would surely avoid dealing with these troubles. Should I go ahead and commit this new assembly and config updates? +0 Jacek
Re: Micro-G
How is this new assembly going to work with the boilerplates? --jason On Sep 25, 2006, at 1:20 PM, Joe Bohn wrote: I didn't create a branch earlier because I didn't have experience doing that and thought I'd just start to play with my local build (I know, not a good excuse but it's the truth). I was just getting to the point where I figured I should either create a branch or provide a patch for RTC when we made the switch to CTR last week. Since it appears that there are no strong objections I'll go ahead and commit what I have later today. Thanks, Joe Jacek Laskowski wrote: On 9/25/06, Joe Bohn <[EMAIL PROTECTED]> wrote: So far, I've been doing this on my local image. I would like to get this code (incomplete as it currently is) checked into trunk to better manage the changes and to share the effort. Is this considered a "controversial change"? Should I first provide a patch as it currently stands so that folks can comment on it prior to a commit(ala RTC)? I wonder why you haven't been doing your experiments in a branch or the sandbox? You would surely avoid dealing with these troubles. Should I go ahead and commit this new assembly and config updates? +0 Jacek
Re: Micro-G
+1. Go for it. -- dims On 9/25/06, Joe Bohn <[EMAIL PROTECTED]> wrote: I didn't create a branch earlier because I didn't have experience doing that and thought I'd just start to play with my local build (I know, not a good excuse but it's the truth). I was just getting to the point where I figured I should either create a branch or provide a patch for RTC when we made the switch to CTR last week. Since it appears that there are no strong objections I'll go ahead and commit what I have later today. Thanks, Joe Jacek Laskowski wrote: > On 9/25/06, Joe Bohn <[EMAIL PROTECTED]> wrote: > > >> So far, I've been doing this on my local image. I would like to get >> this code (incomplete as it currently is) checked into trunk to better >> manage the changes and to share the effort. Is this considered a >> "controversial change"? Should I first provide a patch as it currently >> stands so that folks can comment on it prior to a commit(ala RTC)? > > > I wonder why you haven't been doing your experiments in a branch or > the sandbox? You would surely avoid dealing with these troubles. > >> Should I go ahead and commit this new assembly and config updates? > > > +0 > > Jacek > -- Davanum Srinivas : http://www.wso2.net (Oxygen for Web Service Developers)
Re: Micro-G
I didn't create a branch earlier because I didn't have experience doing that and thought I'd just start to play with my local build (I know, not a good excuse but it's the truth). I was just getting to the point where I figured I should either create a branch or provide a patch for RTC when we made the switch to CTR last week. Since it appears that there are no strong objections I'll go ahead and commit what I have later today. Thanks, Joe Jacek Laskowski wrote: On 9/25/06, Joe Bohn <[EMAIL PROTECTED]> wrote: So far, I've been doing this on my local image. I would like to get this code (incomplete as it currently is) checked into trunk to better manage the changes and to share the effort. Is this considered a "controversial change"? Should I first provide a patch as it currently stands so that folks can comment on it prior to a commit(ala RTC)? I wonder why you haven't been doing your experiments in a branch or the sandbox? You would surely avoid dealing with these troubles. Should I go ahead and commit this new assembly and config updates? +0 Jacek
[jira] Closed: (GERONIMO-2414) SchemaConversionUtils should have only generic code: individual builders should have specific code
[ http://issues.apache.org/jira/browse/GERONIMO-2414?page=all ] David Jencks closed GERONIMO-2414. -- Resolution: Fixed Methods moved in a variety of commits, last one 449797. Involves openejb changes in rev 449796. > SchemaConversionUtils should have only generic code: individual builders > should have specific code > -- > > Key: GERONIMO-2414 > URL: http://issues.apache.org/jira/browse/GERONIMO-2414 > Project: Geronimo > Issue Type: Improvement > Security Level: public(Regular issues) > Components: deployment >Affects Versions: 1.2 >Reporter: David Jencks > Assigned To: David Jencks > Fix For: 1.2 > > > SchemaConversionUtils has a lot of j2ee 1.4 specific methods such as > ConvertToServletSchema that reference the xmlbeans generated classes for j2ee > 1.4. These should be moved into the j2ee 1.4 builders, and appropriate > similar methods included in jee5 builders. SchemaConversionUtils should have > only parameterized-for-ee-version generic methods and geronimo-specific > methods. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (GERONIMO-2426) Site docs, javadocs for the geronimo-maven-plugin
[ http://issues.apache.org/jira/browse/GERONIMO-2426?page=all ]
Jason Dillon closed GERONIMO-2426.
--
Resolution: Fixed
Applied, thx. I did some more clean up, and fixed one error, where I found
this:
{code:xml}
...
{code}
Which should have been:
{code:xml}
...
{code}
> Site docs, javadocs for the geronimo-maven-plugin
> -
>
> Key: GERONIMO-2426
> URL: http://issues.apache.org/jira/browse/GERONIMO-2426
> Project: Geronimo
> Issue Type: Improvement
> Security Level: public(Regular issues)
> Components: buildsystem
>Reporter: Prasad Kashyap
> Assigned To: Jason Dillon
> Fix For: 1.2
>
> Attachments: site-docs.patch
>
>
> Use this JIRA to update the site docs and javadocs for the
> geronimo-maven-plugin.
--
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
JMX issue with 3.0?
Hej, with the current 3.0 binary distro I'm unable to use the JMX console. JConsole trows errors when trying to connect the address given by SM in the console output and the address given at http://www.servicemix.org/site/jmx-console.html I tried with deactivated firewall; no change. With an approx. 2 months old snapshot it works as desired, so JMX itself is working. Can anyone reproduce the problem? Georg SM output: Starting Apache ServiceMix ESB: 3.0-incubating Loading Apache ServiceMix from servicemix.xml on the CLASSPATH INFO - ConnectorServerFactoryBean - JMX connector available at: service:jmx:rmi:///jndi/rmi://localhost:1099/jmxrmi INFO - JBIContainer - ServiceMix 3.0-incubating JBI Container (ServiceMix) is starting INFO - JBIContainer - For help or more informations please see: http://incubator.apache.org/servicemix/ INFO - ComponentMBeanImpl - Initializing component: #SubscriptionManager# INFO - DeploymentService - Restoring service assemblies INFO - ServiceAssemblyLifeCycle - Starting service assembly: bridge-sa INFO - JBIContainer - ServiceMix JBI Container (ServiceMix) started INFO - AutoDeploymentService - Location bridge-sa-1.0-SNAPSHOT.zip no longer exists - removing ... INFO - AutoDeploymentService - Attempting to remove archive at: bridge-sa-1.0-SNAPSHOT.zip INFO - AutoDeploymentService - Undeploying service assembly bridge-sa INFO - ServiceAssemblyLifeCycle - Shutting down service assembly: bridge-sa INFO - ServiceAssemblyLifeCycle - Shutting down service assembly: bridge-sa JConsole output: Exception in thread "JConsole.addUrl" java.lang.IllegalArgumentException: Expect ed String[2], got null at org.apache.servicemix.jbi.jmx.JaasAuthenticator.authenticate(JaasAuth enticator.java:73) at javax.management.remote.rmi.RMIServerImpl.doNewClient(RMIServerImpl.j ava:221) at javax.management.remote.rmi.RMIServerImpl.newClient(RMIServerImpl.jav a:188) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl. java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces sorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:294) at sun.rmi.transport.Transport$1.run(Transport.java:153) at java.security.AccessController.doPrivileged(Native Method) at sun.rmi.transport.Transport.serviceCall(Transport.java:149) at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:4 66) at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport .java:707) at java.lang.Thread.run(Thread.java:595) at sun.rmi.transport.StreamRemoteCall.exceptionReceivedFromServer(Stream RemoteCall.java:247) at sun.rmi.transport.StreamRemoteCall.executeCall(StreamRemoteCall.java: 223) at sun.rmi.server.UnicastRef.invoke(UnicastRef.java:126) at javax.management.remote.rmi.RMIServerImpl_Stub.newClient(Unknown Sour ce) at javax.management.remote.rmi.RMIConnector.getConnection(RMIConnector.j ava:2239) at javax.management.remote.rmi.RMIConnector.connect(RMIConnector.java:27 1) at javax.management.remote.JMXConnectorFactory.connect(JMXConnectorFacto ry.java:248) at sun.tools.jconsole.ProxyClient.(ProxyClient.java:117) at sun.tools.jconsole.ProxyClient.getProxyClient(ProxyClient.java:87) at sun.tools.jconsole.JConsole$2.run(JConsole.java:410) -- View this message in context: http://www.nabble.com/JMX-issue-with-3.0--tf2333436.html#a6492224 Sent from the ServiceMix - Dev mailing list archive at Nabble.com.
Re: Micro-G
Sweeet... we need a new logo Since its new I'm happy to look at it after you commit it. Matt Hogstrom [EMAIL PROTECTED]
Re: Micro-G
On 9/25/06, Joe Bohn <[EMAIL PROTECTED]> wrote: So far, I've been doing this on my local image. I would like to get this code (incomplete as it currently is) checked into trunk to better manage the changes and to share the effort. Is this considered a "controversial change"? Should I first provide a patch as it currently stands so that folks can comment on it prior to a commit(ala RTC)? I wonder why you haven't been doing your experiments in a branch or the sandbox? You would surely avoid dealing with these troubles. Should I go ahead and commit this new assembly and config updates? +0 Jacek -- Jacek Laskowski http://www.laskowski.net.pl
Re: [jira] Resolved: (GERONIMO-2429) Branches/1.1 - Several project.xml files are referencing jaxr-api-0.5.jar which does not seem to exist anymore
On 9/25/06, Jay D. McHugh <[EMAIL PROTECTED]> wrote: I had to manually download the org.mortbay.jetty-5.1.10.jar file and put it into my .maven repo for my build to finish. Is that the problem that you were having? Caused by: java.lang.ClassNotFoundException: org.apache.geronimo.samples.daytrader.web.prims.PingServlet2Session2CMROne2Many in classloader geronimo/daytrader-derby-jetty_web.war/1 .1.2-SNAPSHOT/car at org.apache.geronimo.kernel.config.MultiParentClassLoader.loadClass(MultiParentClassLoader.java:249) at java.lang.ClassLoader.loadClass(ClassLoader.java:235) at org.apache.geronimo.jetty.deployment.JettyModuleBuilder.addServlet(JettyModuleBuilder.java:826) ... 91 more 19:46:51,312 ERROR [PlanProcessor] java.lang.reflect.InvocationTargetException: null Jacek -- Jacek Laskowski http://www.laskowski.net.pl
Re: Micro-G
I'd like to see the changes. I think CTR is fine. Tomcat config update seems like the right thing, anyway. --kevan
Re: Micro-G
--- Joe Bohn <[EMAIL PROTECTED]> wrote: > > I've done some work on a new assembly that I've nicknamed "Micro-G" > (I > know .. not very creative). The name that I'm using under > geronimo/assemblies is "geronimo-framework". This is intended to be > a > new foundational assembly from which any customized Geronimo assembly > > could be built by installing plugins we would provide (starting with > tomcat and jetty plugins). > > Hopefully this could help us eliminate the need to provide so many > canned configurations with each release. I'm pretty sure we would > probably still want to provide at least one full j2ee server > configuration that we certified against, but we could potentially > drop > the little-G assemblies and hopefully avoid additional future > assemblies > based upon different combinations of components in the works. > > So far, I've been doing this on my local image. I would like to get > this code (incomplete as it currently is) checked into trunk to > better > manage the changes and to share the effort. Yes, please go ahead.. and let me know if and how I can share the effort. thanks Anita Is this considered a > "controversial change"? Should I first provide a patch as it > currently > stands so that folks can comment on it prior to a commit(ala RTC)? > > I'm inclined to just commit the code since it is relatively self > contained at the moment, safe, and can be easily reverted. I think > the > only controversial change thus far might be that I updated the > default > port selections on the tomcat configuration so that if you install a > tomcat plugin on this framework assembly you will end up with the > same > port configurations currently available on our existing tomcat > distributions. Of course, this means that the default ports are no > longer conducive to running two web servers in the same > configuration. > > Should I go ahead and commit this new assembly and config updates? > > Joe > > __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
[jira] Commented: (GERONIMO-2409) Provide config/module aliasing ability
[ http://issues.apache.org/jira/browse/GERONIMO-2409?page=comments#action_12437612 ] Rick McGuire commented on GERONIMO-2409: It would be nice if this aliasing carried through to at least deploy start/stop. This would be very handy for applications where they have a dependency on a system module where there might be multiple choices (e.g., j2ee-corba, where there's a Sun ORB option or a Yoko ORB option). The artifact_aliases entry can identify the default by mapping j2ee-corba to one of the options, and the system administrator need only worry about starting/stopping the j2ee-corba module without needing to know which option was selected for use. > Provide config/module aliasing ability > -- > > Key: GERONIMO-2409 > URL: http://issues.apache.org/jira/browse/GERONIMO-2409 > Project: Geronimo > Issue Type: Improvement > Security Level: public(Regular issues) > Components: core >Affects Versions: 1.2 >Reporter: David Jencks > Assigned To: David Jencks > Fix For: 1.2 > > Attachments: GERONIMO-2409-v1.patch > > > It's sort of impossible to swap a basic configuration such as transaction > with a substitute such as transaction-jta11: there are too many modules that > depend on it that all have to be rebuilt just because you changed one name. > To fix this we need some way to substitute one module (configuration) for > another. We might aim for a function-based registry rather than a name based > one, but that is more that I want to think about right now. > I've done some simple experiments and it looks like some trivial changes in > DefaultArtifactResolver, the car maven plugin, and an additional properties > file in the server at least let you swap modules and get the server started. > I expected that changes in the kernel gbean lookups and Configuration gbean > lookups would be necessary as well, but I haven't needed them yet. > I think the changes so far should be applied since they clarify the explicit > version resolution code and enable at least some module swapping. I suspect > we'll find out soon if more work is needed. -- 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: Micro-G
On Sep 25, 2006, at 9:49 AM, Joe Bohn wrote: I've done some work on a new assembly that I've nicknamed "Micro- G" (I know .. not very creative). The name that I'm using under geronimo/assemblies is "geronimo-framework". This is intended to be a new foundational assembly from which any customized Geronimo assembly could be built by installing plugins we would provide (starting with tomcat and jetty plugins). Hopefully this could help us eliminate the need to provide so many canned configurations with each release. I'm pretty sure we would probably still want to provide at least one full j2ee server configuration that we certified against, but we could potentially drop the little-G assemblies and hopefully avoid additional future assemblies based upon different combinations of components in the works. So far, I've been doing this on my local image. I would like to get this code (incomplete as it currently is) checked into trunk to better manage the changes and to share the effort. Is this considered a "controversial change"? Should I first provide a patch as it currently stands so that folks can comment on it prior to a commit(ala RTC)? I'm inclined to just commit the code since it is relatively self contained at the moment, safe, and can be easily reverted. I think the only controversial change thus far might be that I updated the default port selections on the tomcat configuration so that if you install a tomcat plugin on this framework assembly you will end up with the same port configurations currently available on our existing tomcat distributions. Of course, this means that the default ports are no longer conducive to running two web servers in the same configuration. Should I go ahead and commit this new assembly and config updates? yes, please do. Updating the tomcat config ports to the "normal" expected values is a really good idea anyway. Anyone crazy enough (that would be me) to want to run 2 web servers in the same g instance can deal with setting the ports in the config.xml thanks david jencks Joe
Re: Micro-G
Yes...commit it...this is a great foundation for SOA and ESBs (no web container needed). Joe Bohn wrote: > > I've done some work on a new assembly that I've nicknamed "Micro-G" (I > know .. not very creative). The name that I'm using under > geronimo/assemblies is "geronimo-framework". This is intended to be a > new foundational assembly from which any customized Geronimo assembly > could be built by installing plugins we would provide (starting with > tomcat and jetty plugins). > > Hopefully this could help us eliminate the need to provide so many > canned configurations with each release. I'm pretty sure we would > probably still want to provide at least one full j2ee server > configuration that we certified against, but we could potentially drop > the little-G assemblies and hopefully avoid additional future assemblies > based upon different combinations of components in the works. > > So far, I've been doing this on my local image. I would like to get > this code (incomplete as it currently is) checked into trunk to better > manage the changes and to share the effort. Is this considered a > "controversial change"? Should I first provide a patch as it currently > stands so that folks can comment on it prior to a commit(ala RTC)? > > I'm inclined to just commit the code since it is relatively self > contained at the moment, safe, and can be easily reverted. I think the > only controversial change thus far might be that I updated the default > port selections on the tomcat configuration so that if you install a > tomcat plugin on this framework assembly you will end up with the same > port configurations currently available on our existing tomcat > distributions. Of course, this means that the default ports are no > longer conducive to running two web servers in the same configuration. > > Should I go ahead and commit this new assembly and config updates? > > Joe
Micro-G
I've done some work on a new assembly that I've nicknamed "Micro-G" (I know .. not very creative). The name that I'm using under geronimo/assemblies is "geronimo-framework". This is intended to be a new foundational assembly from which any customized Geronimo assembly could be built by installing plugins we would provide (starting with tomcat and jetty plugins). Hopefully this could help us eliminate the need to provide so many canned configurations with each release. I'm pretty sure we would probably still want to provide at least one full j2ee server configuration that we certified against, but we could potentially drop the little-G assemblies and hopefully avoid additional future assemblies based upon different combinations of components in the works. So far, I've been doing this on my local image. I would like to get this code (incomplete as it currently is) checked into trunk to better manage the changes and to share the effort. Is this considered a "controversial change"? Should I first provide a patch as it currently stands so that folks can comment on it prior to a commit(ala RTC)? I'm inclined to just commit the code since it is relatively self contained at the moment, safe, and can be easily reverted. I think the only controversial change thus far might be that I updated the default port selections on the tomcat configuration so that if you install a tomcat plugin on this framework assembly you will end up with the same port configurations currently available on our existing tomcat distributions. Of course, this means that the default ports are no longer conducive to running two web servers in the same configuration. Should I go ahead and commit this new assembly and config updates? Joe
[jira] Resolved: (AMQ-888) Licence headers missing from several source files.
[ https://issues.apache.org/activemq/browse/AMQ-888?page=all ]
james strachan resolved AMQ-888.
Resolution: Fixed
Fixed now
> Licence headers missing from several source files.
> --
>
> Key: AMQ-888
> URL: https://issues.apache.org/activemq/browse/AMQ-888
> Project: ActiveMQ
> Issue Type: Bug
>Affects Versions: 4.0
>Reporter: Hiram Chirino
> Assigned To: james strachan
> Fix For: 4.1, 4.0.2
>
> Attachments: findunlicensed.pl
>
>
> robert burrell donkin reported:
> {quote}
> missing license headers from some of the files i checked at random
> gives me concerns. for example:
> maven-bundle-plugin/src/main/java/org/apache/activemq/maven/BundleMojo.java
> activemq-web-demo worries me: there are a lot of files without license
> headers and some which have them were not created at the ASF (which is
> ok but gives me concerns about the rest).
> i would like to see the issue of licenses in the source tidied up
> before this release ships. i haven't gone through every file but IMO
> this needs to be done.
> {quote}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://issues.apache.org/activemq/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (AMQ-888) Licence headers missing from several source files.
[
https://issues.apache.org/activemq/browse/AMQ-888?page=comments#action_37015 ]
james strachan commented on AMQ-888:
I've fixed up activemq-web-demo and activemq-web-console
in trunk...
http://svn.apache.org/viewvc?view=rev&rev=449694
http://svn.apache.org/viewvc?view=rev&rev=449726
in 4.0 branch...
449731
> Licence headers missing from several source files.
> --
>
> Key: AMQ-888
> URL: https://issues.apache.org/activemq/browse/AMQ-888
> Project: ActiveMQ
> Issue Type: Bug
>Affects Versions: 4.0
>Reporter: Hiram Chirino
> Assigned To: james strachan
> Fix For: 4.1, 4.0.2
>
> Attachments: findunlicensed.pl
>
>
> robert burrell donkin reported:
> {quote}
> missing license headers from some of the files i checked at random
> gives me concerns. for example:
> maven-bundle-plugin/src/main/java/org/apache/activemq/maven/BundleMojo.java
> activemq-web-demo worries me: there are a lot of files without license
> headers and some which have them were not created at the ASF (which is
> ok but gives me concerns about the rest).
> i would like to see the issue of licenses in the source tidied up
> before this release ships. i haven't gone through every file but IMO
> this needs to be done.
> {quote}
--
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: Web Service Sample Application
I know that the way we have it today for tracking progress in the doc is far from optimal but JIRAs may not be the easiest way either. If we use JIRA for the doc, this is what I think the author should do: - create a JIRA for documentation - JIRA summary should match cwiki page title - what priority should be used? - specify affected releases - assign the issue to itself - add a link in the JIRA to the cwiki HTML page - non English versions of the doc should also contain a link to the original doc (dependency?) - add a link to JIRA from the cwiki documentation page - develop the actual documentation content and necessary samples - no further status update/changes on the JIRA would be necessary while the content is developed in cwiki - close the JIRA once the document is finished hmmm, on second thought, this may not bee too hard to deal with as long as we keep the main focus in the doc and not in maintaining those doc JIRAs. Let's give it a try for the remaining of the v1.1 and v1.1.1 doc, if it works we could go full steam ahead for the next G release. Comments? Cheers! Hernan Jacek Laskowski wrote: On 9/22/06, Lasantha Ranaweera <[EMAIL PROTECTED]> wrote: I saw there is an empty sample application under web services section in Geronimo user guide. Does anybody working on that? I would like to contribute on that. Once you've decided you'd go for it, could you please add your name to the section so it's clear you're working on it? Or better yet, create a jira issue and assign it to you. This way when we cut a release and create RELEASE NOTES it will be noted. People will surely appreciate it, i.e. your example and the way it's announced ;-) BTW, please don't cross-post dev and user. It's an issue for the user mailing list (but I must admit I would not have picked it up so early if it'd been sent to user ;-)) Jacek
Re: Wiki page for building Geronimo with m2
Jay D. McHugh wrote: Hello all, Am I correct in thinking that since the specs were changed, trunk can no longer be built with a simple 'bootstrap' and must now actually be built step by step following the 'bootstrap without a full "bootstrap"' directions? I believe that this is correct (or at least that's the procedure I now follow building the specs only with jdk 1.5). If that is true I could try to modify the wiki page to remove the simple directions and lead everyone to the step-by-step directions right away (I would need to have someone take a look when I was done though - I don't trust myself to change anything without review). Go for it! Joe
Re: [jira] Resolved: (GERONIMO-2429) Branches/1.1 - Several project.xml files are referencing jaxr-api-0.5.jar which does not seem to exist anymore
On 9/25/06, Jay D. McHugh <[EMAIL PROTECTED]> wrote: I had to manually download the org.mortbay.jetty-5.1.10.jar file and put it into my .maven repo for my build to finish. Is that the problem that you were having? Not sure - don't remember it exactly. I'll give it a shot again and update project.xml is it's because of missing jar. Thanks! Jacek -- Jacek Laskowski http://www.laskowski.net.pl
Re: Wiki page for building Geronimo with m2
On 9/25/06, Jay D. McHugh <[EMAIL PROTECTED]> wrote: Am I correct in thinking that since the specs were changed, trunk can no longer be built with a simple 'bootstrap' and must now actually be built step by step following the 'bootstrap without a full "bootstrap"' directions? Not sure. I'm building Geronimo without the boostrap. If that is true I could try to modify the wiki page to remove the simple directions and lead everyone to the step-by-step directions right away (I would need to have someone take a look when I was done though - I don't trust myself to change anything without review). Go for it. There will be someone who takes care of reviewing your changes. No need to worry if you make mistakes - we all do them, too. Jacek -- Jacek Laskowski http://www.laskowski.net.pl
Patches in RTC (Geronimo - 2006-09-25)
Geronimo - Monday, September 25, 2006 2 Patches in RTC [GERONIMO-2015] Let's replace JKS to PKCS12 key store type - Assignee: Unassigned - Reporter: Nikolay Chugunov - Created: Fri May 12 14:54:17 PDT 2006 - Updated: Sun Sep 10 11:08:59 PDT 2006 - Votes: 0 - http://issues.apache.org/jira/browse/GERONIMO-2015 [GERONIMO-2409] Provide config/module aliasing ability - Assignee: David Jencks - Reporter: David Jencks - Created: Fri Sep 15 15:36:59 PDT 2006 - Updated: Tue Sep 19 10:29:30 PDT 2006 - Votes: 3 1 Gianny Damour 2 Jeff Genender 3 Joe Bohn - http://issues.apache.org/jira/browse/GERONIMO-2409 NOTE: This email is generated and does not constitute and offical vote or vote result. All official voting is done on the dev list. If you do not see your issue here, click the "Begin RTC Review" link under the "Available Workflow Actions" of the JIRA page. If you do not see your vote here, click the "Vote" link under the "Operations" section of the JIRA page. *** ALL COMMUNITY MEMBERS ARE ENCOURAGED TO VOTE *** Template: http://svn.apache.org/repos/asf/geronimo/gbuild/jirareports/patchesInRtc.vm
[jira] Updated: (GERONIMO-2333) Add JMX Portlet
[ http://issues.apache.org/jira/browse/GERONIMO-2333?page=all ] Paul McMahan updated GERONIMO-2333: --- Fix Version/s: 1.2 > Add JMX Portlet > --- > > Key: GERONIMO-2333 > URL: http://issues.apache.org/jira/browse/GERONIMO-2333 > Project: Geronimo > Issue Type: New Feature > Security Level: public(Regular issues) > Components: console >Affects Versions: 1.2 >Reporter: Christopher M. Cardona > Assigned To: Paul McMahan > Fix For: 1.2 > > Attachments: dojo-0.3.1-bin.zip, GERONIMO-2333-trunk.patch, > GERONIMO-2333-trunk2.patch, GERONIMO-2333-trunk3.patch, > jmxMgrPortlet-G1.1.1-1.jpg, jmxMgrPortlet-G1.1.1-2.jpg, > jmxMgrPortlet-G1.1.1-3.jpg, jmxMgrPortlet-G1.1.1-New.patch, > jmxMgrPortlet-G1.1.1.patch > > > Add a JMX portlet with the following minimum capabilities: > 1. Be able to list all the MBeans > 2. Predefined searches for the different J2EE types: J2EEApplication, > EJBModule, WebModule, Sertlet, JCAConnectionFactory, etc. > 3. Be able to query MBeans (if possible with autocomplete feature) > 4. View the attributes and operations of MBeans > The plan is to use Ajax (Dojo and DWR) to make this portlet a little bit > responsive. Any thoughts and suggestions are welcome. > cheers, > chris -- 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: (GERONIMO-2333) Add JMX Portlet
[ http://issues.apache.org/jira/browse/GERONIMO-2333?page=all ] Paul McMahan reassigned GERONIMO-2333: -- Assignee: Paul McMahan (was: Christopher M. Cardona) > Add JMX Portlet > --- > > Key: GERONIMO-2333 > URL: http://issues.apache.org/jira/browse/GERONIMO-2333 > Project: Geronimo > Issue Type: New Feature > Security Level: public(Regular issues) > Components: console >Affects Versions: 1.2 >Reporter: Christopher M. Cardona > Assigned To: Paul McMahan > Attachments: dojo-0.3.1-bin.zip, GERONIMO-2333-trunk.patch, > GERONIMO-2333-trunk2.patch, GERONIMO-2333-trunk3.patch, > jmxMgrPortlet-G1.1.1-1.jpg, jmxMgrPortlet-G1.1.1-2.jpg, > jmxMgrPortlet-G1.1.1-3.jpg, jmxMgrPortlet-G1.1.1-New.patch, > jmxMgrPortlet-G1.1.1.patch > > > Add a JMX portlet with the following minimum capabilities: > 1. Be able to list all the MBeans > 2. Predefined searches for the different J2EE types: J2EEApplication, > EJBModule, WebModule, Sertlet, JCAConnectionFactory, etc. > 3. Be able to query MBeans (if possible with autocomplete feature) > 4. View the attributes and operations of MBeans > The plan is to use Ajax (Dojo and DWR) to make this portlet a little bit > responsive. Any thoughts and suggestions are welcome. > cheers, > chris -- 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-2333) Add JMX Portlet
[ http://issues.apache.org/jira/browse/GERONIMO-2333?page=comments#action_12437580 ] Paul McMahan commented on GERONIMO-2333: Chris, great job on this! I checked in the files and will go ahead and mark this JIRA resoloved. As I recall there were a few additional items you were investigating. If you have any subsequent changes then feel free to reopen this JIRA or open a new one. > Add JMX Portlet > --- > > Key: GERONIMO-2333 > URL: http://issues.apache.org/jira/browse/GERONIMO-2333 > Project: Geronimo > Issue Type: New Feature > Security Level: public(Regular issues) > Components: console >Affects Versions: 1.2 >Reporter: Christopher M. Cardona > Assigned To: Christopher M. Cardona > Attachments: dojo-0.3.1-bin.zip, GERONIMO-2333-trunk.patch, > GERONIMO-2333-trunk2.patch, GERONIMO-2333-trunk3.patch, > jmxMgrPortlet-G1.1.1-1.jpg, jmxMgrPortlet-G1.1.1-2.jpg, > jmxMgrPortlet-G1.1.1-3.jpg, jmxMgrPortlet-G1.1.1-New.patch, > jmxMgrPortlet-G1.1.1.patch > > > Add a JMX portlet with the following minimum capabilities: > 1. Be able to list all the MBeans > 2. Predefined searches for the different J2EE types: J2EEApplication, > EJBModule, WebModule, Sertlet, JCAConnectionFactory, etc. > 3. Be able to query MBeans (if possible with autocomplete feature) > 4. View the attributes and operations of MBeans > The plan is to use Ajax (Dojo and DWR) to make this portlet a little bit > responsive. Any thoughts and suggestions are welcome. > cheers, > chris -- 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
JSF 1.2
Hi, I would like to start investigating JSF 1.2 (JSR-252) for inclusion in the Geronimo 1.2 release and have updated the Geronimo Release Roadmap (below) accordingly. If there are any comments and/or suggestions please let me know. Thanks. http://cwiki.apache.org/confluence/display/GMOxPMGT/Geronimo+Release+Roadmap --
[jira] Commented: (GERONIMO-2333) Add JMX Portlet
[ http://issues.apache.org/jira/browse/GERONIMO-2333?page=comments#action_12437575 ] Paul McMahan commented on GERONIMO-2333: Thanks for the nudge Gianny :-) Sending applications\console\geronimo-console-framework\src\main\webapp\WEB-INF\data\pageregistry.xml Sending applications\console\geronimo-console-framework\src\main\webapp\WEB-INF\data\portletentityregistry.xml Adding applications\console\geronimo-console-standard\src\main\java\org\apache\geronimo\console\jmxmanager Adding applications\console\geronimo-console-standard\src\main\java\org\apache\geronimo\console\jmxmanager\JMXManagerHelper.java Adding applications\console\geronimo-console-standard\src\main\java\org\apache\geronimo\console\jmxmanager\JMXManagerPortlet.java Sending applications\console\geronimo-console-standard\src\main\webapp\WEB-INF\dwr.xml Sending applications\console\geronimo-console-standard\src\main\webapp\WEB-INF\portlet.xml Adding applications\console\geronimo-console-standard\src\main\webapp\WEB-INF\view\jmxmanager Adding applications\console\geronimo-console-standard\src\main\webapp\WEB-INF\view\jmxmanager\help.jsp Adding applications\console\geronimo-console-standard\src\main\webapp\WEB-INF\view\jmxmanager\viewJMXServer.jsp Sending applications\console\geronimo-console-standard\src\main\webapp\WEB-INF\web.xml Transmitting file data .. Committed revision 449693. > Add JMX Portlet > --- > > Key: GERONIMO-2333 > URL: http://issues.apache.org/jira/browse/GERONIMO-2333 > Project: Geronimo > Issue Type: New Feature > Security Level: public(Regular issues) > Components: console >Affects Versions: 1.2 >Reporter: Christopher M. Cardona > Assigned To: Christopher M. Cardona > Attachments: dojo-0.3.1-bin.zip, GERONIMO-2333-trunk.patch, > GERONIMO-2333-trunk2.patch, GERONIMO-2333-trunk3.patch, > jmxMgrPortlet-G1.1.1-1.jpg, jmxMgrPortlet-G1.1.1-2.jpg, > jmxMgrPortlet-G1.1.1-3.jpg, jmxMgrPortlet-G1.1.1-New.patch, > jmxMgrPortlet-G1.1.1.patch > > > Add a JMX portlet with the following minimum capabilities: > 1. Be able to list all the MBeans > 2. Predefined searches for the different J2EE types: J2EEApplication, > EJBModule, WebModule, Sertlet, JCAConnectionFactory, etc. > 3. Be able to query MBeans (if possible with autocomplete feature) > 4. View the attributes and operations of MBeans > The plan is to use Ajax (Dojo and DWR) to make this portlet a little bit > responsive. Any thoughts and suggestions are welcome. > cheers, > chris -- 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: how to use failover url protocol in STOMP C client
On 9/25/06, Dhawan, Vikram (LNG-DAY) <[EMAIL PROTECTED]> wrote: Hi Hiram, I will do that. BTW I had another question and haven't got any response yet... this is about message selector in STOMP C clients. Because of some reason I can't get it work. Can you provide me some sample? As far as my understanding I am setting the selector at the SUBSCRIBE command and it should work. Yes it should - details on all the Stomp headers supported here... http://incubator.apache.org/activemq/stomp.html -- James --- http://radio.weblogs.com/0112098/
[jira] Created: (SM-598) MTOM attachments are not output by the jsr181 component
MTOM attachments are not output by the jsr181 component --- Key: SM-598 URL: https://issues.apache.org/activemq/browse/SM-598 Project: ServiceMix Issue Type: Bug Components: servicemix-jsr181 Affects Versions: 3.0 Reporter: Hari Iyer While sending an MTOM attachment to the component works, retrieving an attachment does not: Operation: DataSource getDocumentById(String documentId) The request that gets created is: http://schemas.xmlsoap.org/soap/envelope/"; xmlns:xsd="http://www.w3.org/2001/XMLSchema"; xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";>http://webservices.sterling.com";>abcd --=_Part_0_12577309.1158352665757-- The response that comes back is: http://schemas.xmlsoap.org/soap/envelope/";>http://webservices.sterling.com";>http://www.w3.org/2004/11/xmlmime"; ns1:mimeType="text">http://www.w3.org/2004/08/xop/include"; href="cid:11583526659604-182379438@http://www.w3.org/2001/XMLSchema"; /> The client gives the error: org.codehaus.xfire.fault.XFireFault: Could not find the attachment cid:11583526659604-182379438@http://www.w3.org/2001/XMLSchema at org.codehaus.xfire.aegis.type.mtom.AbstractXOPType.readInclude(AbstractXOPType.java:62) The attachment is missing from the response. This same request works correctly in a pure XFire deployment. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
RE: how to use failover url protocol in STOMP C client
Hi Hiram, I will do that. BTW I had another question and haven't got any response yet... this is about message selector in STOMP C clients. Because of some reason I can't get it work. Can you provide me some sample? As far as my understanding I am setting the selector at the SUBSCRIBE command and it should work. Thanks! Vik -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Hiram Chirino Sent: Friday, September 22, 2006 7:37 PM To: activemq-dev@geronimo.apache.org Subject: Re: how to use failover url protocol in STOMP C client Hi Vikram, Not implemented in the stomp C client yet. If you want to take a cracked at implementing it yourself, you might want to peek at how it was implemented in the stomp ruby client. On 9/22/06, Dhawan, Vikram (LNG-DAY) <[EMAIL PROTECTED]> wrote: > Hi, > > > > I want to know can I use same failover protocol URL syntax in STOMP C > clients. And will it work the way failover is described in the AMQ > documentation. > > > > Thanks! > > > > Vik > > > > > -- Regards, Hiram Blog: http://hiramchirino.com
Re: [ANNOUNCE] Welcome Paul McMahan as the newest member of the Geronimo PMC
Congrats!On Sep 21, 2006, at 5:23 PM, David Jencks wrote:All,The Geronimo PMC is pleased to welcome Paul McMahan as the newest member of the Geronimo PMC. We're very happy to have Paul joining us to help with the oversight of the Geronimo project. Lets give a round of applause for Paul.Well done, Paul!The Apache Geronimo PMCdavid jencks -sachin
Re: [jira] Updated: (GERONIMO-2314) Can not create a datasource with the name "jdbc/EmployeeDatasource" from console
Donald Woods (JIRA) wrote:
[ http://issues.apache.org/jira/browse/GERONIMO-2314?page=all ]
Donald Woods updated GERONIMO-2314:
---
Patch Info: [Patch Available]
Fix Version/s: 1.2
Assignee: (was: Donald Woods)
Unassigning from me so a committer can grab it
Can not create a datasource with the name "jdbc/EmployeeDatasource" from console
Key: GERONIMO-2314
URL: http://issues.apache.org/jira/browse/GERONIMO-2314
Project: Geronimo
Issue Type: Bug
Security Level: public(Regular issues)
Components: console
Affects Versions: 1.1, 1.1.1, 1.1.2, 1.2
Reporter: Yunfeng Ma
Fix For: 1.1.2, 1.2
Attachments: G2314-1.1.patch
Follow the database pool wizard, create a datasource with the name
"jdbc/EmployeeDatasource", the connection test is successful, but when click on the
button "deploy", see the following stacktrace in the server output window:
org.apache.geronimo.common.DeploymentException:
java.lang.IllegalArgumentException: Invalid id:
console.dbpool/jdbc/EmployeeDatasource/1.0/rar
at
org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:364)
at
org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:124)
at
org.apache.geronimo.deployment.Deployer$$FastClassByCGLIB$$734a235d.invoke()
at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53)
at
org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38)
at
org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:122)
at
org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:852)
at
org.apache.geronimo.kernel.basic.BasicKernel.invoke(BasicKernel.java:239)
at
org.apache.geronimo.deployment.plugin.local.AbstractDeployCommand.doDeploy(AbstractDeployCommand.java:106)
at
org.apache.geronimo.deployment.plugin.local.DistributeCommand.run(DistributeCommand.java:60)
at java.lang.Thread.run(Thread.java:797)
Caused by:
java.lang.IllegalArgumentException: Invalid id: console.dbpool/jdbc/EmployeeDatasource/1.0/rar
at
org.apache.geronimo.kernel.repository.Artifact.create(Artifact.java:49)
at
org.apache.geronimo.deployment.Deployer.notifyWatchers(Deployer.java:376)
at
org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:325)
... 10 more
This error just happens in the condition of the database pool name includes the character "/", such
as "jdbc/EmployeeDatasource". If database pool name is "EmployeeDatasource", then
everything is OK.
Have a look at the souce codes of Artifact.java, the snippet of create method
as following:
public static Artifact create(String id) {
String[] parts = id.split("/", -1);
if (parts.length != 4) {
throw new IllegalArgumentException("Invalid id: " + id);
}
for (int i = 0; i < parts.length; i++) {
if (parts[i].equals("")) {
parts[i] = null;
}
}
return new Artifact(parts[0], parts[1], parts[2], parts[3]);
}
If database pool name is "jdbc/EmployeeDatasource", the parts.length would be 5
and IllegalArgumentException would be throwed.
I'm not a committer, but I did test this patch and it allowed me to
create a database pool with a 'jdbc/' prefix. The actual name after the
pool was created did not include the 'jdbc/' in the database pool portlet.
The entry in j2ee connectors is slightly different between tags/1.1.1
and branches/1.1:
tags/1.1.1-> console.dbpool/plc/1.0/rar
branches/1.1 -> jdbc/plc/1.0/rar
'plc' is the name of my database pool.
I could not test further because some other change is preventing me from
deploying my webapp (the thing that is blocking my deployment is that
I'm not very good a changing my deployment descriptors). I will try
again to get my app deployed with the new datasource on Monday.
Jay
Wiki page for building Geronimo with m2
Hello all, Am I correct in thinking that since the specs were changed, trunk can no longer be built with a simple 'bootstrap' and must now actually be built step by step following the 'bootstrap without a full "bootstrap"' directions? If that is true I could try to modify the wiki page to remove the simple directions and lead everyone to the step-by-step directions right away (I would need to have someone take a look when I was done though - I don't trust myself to change anything without review). There have been at least two people who tried to build trunk in the past week and had to ask for help because a simple bootstrap didn't work for them. Jay
Re: [jira] Resolved: (GERONIMO-2429) Branches/1.1 - Several project.xml files are referencing jaxr-api-0.5.jar which does not seem to exist anymore
Jacek Laskowski (JIRA) wrote: [ http://issues.apache.org/jira/browse/GERONIMO-2429?page=all ] Jacek Laskowski resolved GERONIMO-2429. --- Fix Version/s: 1.1.x Resolution: Fixed Although I can't seem to build Geronimo, it has nothing to do with the patch. Committed as revision 449394. Thanks! Branches/1.1 - Several project.xml files are referencing jaxr-api-0.5.jar which does not seem to exist anymore -- Key: GERONIMO-2429 URL: http://issues.apache.org/jira/browse/GERONIMO-2429 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: buildsystem Affects Versions: 1.1.x Reporter: Jay D. McHugh Assigned To: Jacek Laskowski Fix For: 1.1.x Attachments: geronimo-2429-v1.1.patch Starting with a new checkout of branches/1.1 and an empty .maven repo. The build fails because several project.xml files reference jaxr-api-0.5.jar: configs/client/project.xml configs/ldap-realm/project.xml assemblies/j2ee-jetty-server/project.xml assemblies/j2ee-tomcat-server/project.xml assemblies/minimal-jetty-server/project.xml assemblies/minimal-tomcat-server/project.xml Jacek, I had to manually download the org.mortbay.jetty-5.1.10.jar file and put it into my .maven repo for my build to finish. Is that the problem that you were having? Jay
[jira] Commented: (AMQ-826) LDAP based authorization support
[ https://issues.apache.org/activemq/browse/AMQ-826?page=comments#action_37014 ] Nikola Goran Cutura commented on AMQ-826: - Hi, I've been busy with another module. Based on Sepand's contribution, I made LDAPCertificateLoginModule that takes certificate from SSL connection and verifies it against LDAP. I'll commit it together with unit test. Now, about testing with Apache direstory: What (I understood) you asked for (and I volounteered) is the ability of unit tests to start (an embedded instance of) directory server loladed with testing data and perform unit tests against it. Right now, I start manually ApacheDS and perform unit tests but we want that automated, right? If that is the case, I believe I can make that easily (I already started ApacheDS as embedded). But, if I understood you correctly, you would like to utilize existing libraries from AMQ project and submit only the difference, is this correct? I'll try to find the differences, too, but my knowledgde of Maven is extremly poor so I won't be able to produce some kond of '.pom' or whatever appropriate. I'll just submit the jars and the code, would that be acceptable? > LDAP based authorization support > > > Key: AMQ-826 > URL: https://issues.apache.org/activemq/browse/AMQ-826 > Project: ActiveMQ > Issue Type: Improvement >Reporter: james strachan > Assigned To: Nikola Goran Cutura > Attachments: LdapAuth.zip > > > Patch kindly added by ngcutura - discussion thread... > http://www.nabble.com/LDAP-Authorization-tf1851705.html#a5344494 -- 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: Swing console?
Awesome! Let me know if and how I can help.On Sep 21, 2006, at 2:17 PM, Simone Bordet wrote:Hi,On 9/18/06, Heinz Drews <[EMAIL PROTECTED]> wrote: That is a good suggestion.I agree with your opinion about webapps.Especially during development it seems, that using a component toconfigure the component which it is dependent on, is increasing risks.I had several times to manually modify config.xml to get G started againPersonally I would prefer an application based on Eclipse because thiscould be nicely integrated with the plugin for launching G. Just to mention that at LiveTribe we're building an Eclipse-based RCPconsole, and the goals are to use the plugin architecture of Eclipseto create a completely modular RCP application that can manage/monitorthe most common app servers, with the ability of replacing completelythe UI if you don't like it (or for special management purposes).We're currently doing this for Jetty, next in list is G and AMQ.Simon--Â http://livetribe.codehaus.orghttp://bordet.blogspot.com -sachin
Re: Authentication (Jconsole)
On 9/25/06, Tommy615 <[EMAIL PROTECTED]> wrote: I set the value at environment where JAVA_HOME=C:\Program Files\Java\jre1.5.0_08 (w/o space) Looks like a space to me. Make sure you quote any arguments that have a space. James.Strachan wrote: > > On 9/25/06, James Strachan <[EMAIL PROTECTED]> wrote: >> Maybe JRE_HOME has a spacein it? > > What is the value of JRE_HOME - does it have a space? > > -- > > James > --- > http://radio.weblogs.com/0112098/ > > -- View this message in context: http://www.nabble.com/Authentication-%28Jconsole%29-tf2329958.html#a6482412 Sent from the ActiveMQ - Dev mailing list archive at Nabble.com. -- Regards, Hiram Blog: http://hiramchirino.com
[jira] Created: (GERONIMO-2433) ClassLoader debugging Portlet
ClassLoader debugging Portlet - Key: GERONIMO-2433 URL: http://issues.apache.org/jira/browse/GERONIMO-2433 Project: Geronimo Issue Type: New Feature Security Level: public (Regular issues) Components: console Affects Versions: 1.2 Reporter: Gianny Damour Priority: Minor It is rather hard to understand classloading problems without debugging them by putting a breakpoint and observing ClassLoaders. It would be nice to have a portlet, which could helps us to understand how the ClassLoaders are organized and what they can load. I will work on such a portlet. -- 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-2333) Add JMX Portlet
[ http://issues.apache.org/jira/browse/GERONIMO-2333?page=comments#action_12437541 ] Gianny Damour commented on GERONIMO-2333: - Paul, do you want to progress further this patch, i.e. ci it? > Add JMX Portlet > --- > > Key: GERONIMO-2333 > URL: http://issues.apache.org/jira/browse/GERONIMO-2333 > Project: Geronimo > Issue Type: New Feature > Security Level: public(Regular issues) > Components: console >Affects Versions: 1.2 >Reporter: Christopher M. Cardona > Assigned To: Christopher M. Cardona > Attachments: dojo-0.3.1-bin.zip, GERONIMO-2333-trunk.patch, > GERONIMO-2333-trunk2.patch, GERONIMO-2333-trunk3.patch, > jmxMgrPortlet-G1.1.1-1.jpg, jmxMgrPortlet-G1.1.1-2.jpg, > jmxMgrPortlet-G1.1.1-3.jpg, jmxMgrPortlet-G1.1.1-New.patch, > jmxMgrPortlet-G1.1.1.patch > > > Add a JMX portlet with the following minimum capabilities: > 1. Be able to list all the MBeans > 2. Predefined searches for the different J2EE types: J2EEApplication, > EJBModule, WebModule, Sertlet, JCAConnectionFactory, etc. > 3. Be able to query MBeans (if possible with autocomplete feature) > 4. View the attributes and operations of MBeans > The plan is to use Ajax (Dojo and DWR) to make this portlet a little bit > responsive. Any thoughts and suggestions are welcome. > cheers, > chris -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (AMQ-917) Discovery Network Connector needs to clean up internal ...
[ https://issues.apache.org/activemq/browse/AMQ-917?page=all ] james strachan resolved AMQ-917. Resolution: Won't Fix Unfortunately your patch breaks 5 test cases. I wonder could you try submitting a different patch to solve your problem? > Discovery Network Connector needs to clean up internal ... > -- > > Key: AMQ-917 > URL: https://issues.apache.org/activemq/browse/AMQ-917 > Project: ActiveMQ > Issue Type: Bug > Components: Connector >Reporter: Sridhar Komandur > Assigned To: james strachan > Attachments: patchfile.txt > > > Consider the following scenario: All the brokers are using a directory > service based discovery agent (for example, DNS). Broker A comes up and tries > to connect to broker B, which is not functional yet. The Discovery Network > Connector at A adds service B to its tracking state "bridges" (list of > connected services) before activating the connection. However, if there is a > failure, the data structure is not cleaned up. When the DNS Discovery Agent > module rescans (DNS) and passes on uri for B into DNC, it simply ignores it > (as its tracking state hasn't been cleaned up upon prior failure). > The attached patch should take care of this issue (in the observed code path) > - test log below: > 2006-09-11 15:36:11,810 [main ] INFO > network.DemandForwardingBridge1 - Starting a network connection between > vm://localhost#0 and tcp://null:0 has been established. > 2006-09-11 15:36:48,158 [main ] DEBUG > network.DemandForwardingBridge1 - stopping localhost bridge to null is > disposed already ? false > 2006-09-11 15:36:48,158 [main ] INFO > ransport.vm.VMTransportFactory1 - Shutting down VM connectors for broker: > localhost > 2006-09-11 15:36:48,159 [main ] INFO > ransport.vm.VMTransportFactory1 - Shutting down VM connectors for broker: > localhost > 2006-09-11 15:36:48,162 [main ] INFO > vemq.broker.TransportConnector1 - Connector vm://localhost Stopped > 2006-09-11 15:36:48,162 [main ] DEBUG > network.DemandForwardingBridge1 - localhost bridge to null stopped > 2006-09-11 15:37:11,246 [main ] WARN > ivemq.network.NetworkConnector1 - Could not start network bridge between: > vm://localhost?network=true and: tcp://komandur-2.desktop.amazon.com:61617 > due to: java.net.ConnectException: Connection refused > java.net.ConnectException: Connection refused -- 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-570) HTTP connector can blow up while trying to report a problem
[ https://issues.apache.org/activemq/browse/SM-570?page=all ]
Guillaume Nodet resolved SM-570.
Fix Version/s: 3.0.1
3.1
Resolution: Fixed
Assignee: Guillaume Nodet
Author: gnodet
Date: Mon Sep 25 04:14:43 2006
New Revision: 449650
URL: http://svn.apache.org/viewvc?view=rev&rev=449650
Log:
SM-570: HTTP connector can blow up while trying to report a problem
Modified:
incubator/servicemix/branches/servicemix-3.0/servicemix-components/src/main/java/org/apache/servicemix/components/http/HttpBindingSupport.java
Author: gnodet
Date: Mon Sep 25 04:14:45 2006
New Revision: 449651
URL: http://svn.apache.org/viewvc?view=rev&rev=449651
Log:
SM-570: HTTP connector can blow up while trying to report a problem
Modified:
incubator/servicemix/trunk/servicemix-components/src/main/java/org/apache/servicemix/components/http/HttpBindingSupport.java
> HTTP connector can blow up while trying to report a problem
> ---
>
> Key: SM-570
> URL: https://issues.apache.org/activemq/browse/SM-570
> Project: ServiceMix
> Issue Type: Bug
> Components: servicemix-components
>Affects Versions: 3.0-M2
>Reporter: Robert H. Pollack
> Assigned To: Guillaume Nodet
>Priority: Minor
> Fix For: 3.0.1, 3.1
>
> Attachments: HttpBindingSupport.java
>
>
> The HttpBindingSupport class has a general exception reporter that handles
> uncaught exceptions by sending them back to the client as HTML messages. The
> code looks like this:
> PrintWriter writer = response.getWriter();
> writer.println("Request failed with error: " + e);
> e.printStackTrace(writer);
> But the HttpMarshaler class, in preparing the normal response, has the
> following line:
> getTransformer().toResult(message.getContent(), new
> StreamResult(response.getOutputStream()));
> If this transformer fails, the error reporting logic will get an
> IllegalStateException, because you cannot ask for the response writer after
> you have already obtained the response output stream. The solution is to ask
> for the output stream again (you are allowed to get it more than once) and
> created a new PrintWriter: The following code seems to work just fine:
> PrintWriter writer = null;
> try {
> writer = response.getWriter();
> } catch (IllegalStateException ise) {
> OutputStream os = response.getOutputStream();
> writer = new PrintWriter (os);
> }
> writer.println("Request failed with error: " + e);
> e.printStackTrace(writer);
> A corrected version of the source file (you also need another import
> statement) is attached.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://issues.apache.org/activemq/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (GERONIMO-2432) Missing dependency in geronimo-clustering-wadi module.
[ http://issues.apache.org/jira/browse/GERONIMO-2432?page=all ] Rick McGuire closed GERONIMO-2432. -- Resolution: Duplicate Fixed before the checkin could be completed. > Missing dependency in geronimo-clustering-wadi module. > -- > > Key: GERONIMO-2432 > URL: http://issues.apache.org/jira/browse/GERONIMO-2432 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: Clustering >Affects Versions: 1.2 >Reporter: Rick McGuire > Fix For: 1.2 > > > There's a commented-out depenency for geronimo-jetty in the pom.xml module > for geronimo-clustering-wadi causing compilation errors on build. -- 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-577) JSR 181 fault message does not respect WSDL message fault definition
[ https://issues.apache.org/activemq/browse/SM-577?page=all ] Guillaume Nodet resolved SM-577. Fix Version/s: 3.1 Resolution: Fixed Assignee: Guillaume Nodet Author: gnodet Date: Mon Sep 25 04:09:46 2006 New Revision: 449649 URL: http://svn.apache.org/viewvc?view=rev&rev=449649 Log: SM-577: JSR181 fault messages does not respect WSDL message fault definition Modified: incubator/servicemix/trunk/servicemix-itests/src/test/java/org/apache/servicemix/itests/Jsr181HttpTest.java incubator/servicemix/trunk/servicemix-itests/src/test/java/org/apache/servicemix/itests/PersonTest.java incubator/servicemix/trunk/servicemix-itests/src/test/java/org/apache/servicemix/itests/beans/Echo.java incubator/servicemix/trunk/servicemix-jsr181/src/main/java/org/apache/servicemix/jsr181/Jsr181ExchangeProcessor.java incubator/servicemix/trunk/servicemix-jsr181/src/main/java/org/apache/servicemix/jsr181/xfire/JbiFaultSerializer.java > JSR 181 fault message does not respect WSDL message fault definition > > > Key: SM-577 > URL: https://issues.apache.org/activemq/browse/SM-577 > Project: ServiceMix > Issue Type: Bug > Components: servicemix-jsr181 >Affects Versions: incubation > Environment: Linux >Reporter: Charles Souillard > Assigned To: Guillaume Nodet > Fix For: 3.1 > > Original Estimate: 30 minutes > Remaining Estimate: 30 minutes > > I have deployed a new Service in jsr181 component. This service is based on a > pojo with no annotations and is using style="document". > The java method only perform a throw new Exception. > The Component which get the jsr181 response is receiving a document with the > following pattern : > > Fault: the name of the exception thrown > a document corresponding to the fault message defined in the > wsdl > > In fact, only the detail content should be set as the Fault > (NormalizeMessage) content. -- 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: (GERONIMO-2432) Missing dependency in geronimo-clustering-wadi module.
Missing dependency in geronimo-clustering-wadi module. --- Key: GERONIMO-2432 URL: http://issues.apache.org/jira/browse/GERONIMO-2432 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Components: Clustering Affects Versions: 1.2 Reporter: Rick McGuire Fix For: 1.2 There's a commented-out depenency for geronimo-jetty in the pom.xml module for geronimo-clustering-wadi causing compilation errors on build. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Build failure due to missing classes in geronimo-clustering-wadi
Jacek Laskowski wrote: Hi, The subject says it all. I suspect pom.xml has not been updated to reflect the changes in jars. I won't be able to fix it at the moment. There's a commented out dependency in the geronimo-clustering-wadi pom.xml that appears to be causing the problem. I'll open a Jira and update. Rick The exact error messages are: Compiling 10 source files to c:\oss\geronimo\modules\geronimo-clustering-wadi\target\classes [INFO] [ERROR] BUILD FAILURE [INFO] [INFO] Compilation failure c:\oss\geronimo\modules\geronimo-clustering-wadi\src\main\java\org\apache\geronimo\clustering\wadi\WADIClusteredHandleInterceptor.java:[32,33] package org.apache.geronimo.jetty doe s not exist c:\oss\geronimo\modules\geronimo-clustering-wadi\src\main\java\org\apache\geronimo\clustering\wadi\WADIClusteredHandleInterceptor.java:[33,41] package org.apache.geronimo.jetty.clu ster does not exist c:\oss\geronimo\modules\geronimo-clustering-wadi\src\main\java\org\apache\geronimo\clustering\wadi\WADIClusteredHandleInterceptor.java:[37,24] package org.mortbay.http does not exi st c:\oss\geronimo\modules\geronimo-clustering-wadi\src\main\java\org\apache\geronimo\clustering\wadi\WADIClusteredHandleInterceptor.java:[38,24] package org.mortbay.http does not exi st c:\oss\geronimo\modules\geronimo-clustering-wadi\src\main\java\org\apache\geronimo\clustering\wadi\WADIClusteredHandleInterceptor.java:[39,33] package org.mortbay.jetty.servlet doe s not exist c:\oss\geronimo\modules\geronimo-clustering-wadi\src\main\java\org\apache\geronimo\clustering\wadi\WADIClusteredHandleInterceptor.java:[40,33] package org.mortbay.jetty.servlet doe s not exist c:\oss\geronimo\modules\geronimo-clustering-wadi\src\main\java\org\apache\geronimo\clustering\wadi\WADIClusteredHandleInterceptor.java:[47,52] cannot resolve symbol symbol : class AbstractClusteredHandleInterceptor location: class org.apache.geronimo.clustering.wadi.WADIClusteredHandleInterceptor c:\oss\geronimo\modules\geronimo-clustering-wadi\src\main\java\org\apache\geronimo\clustering\wadi\WADIClusteredHandleInterceptor.java:[68,98] cannot resolve symbol symbol : class HttpRequest location: class org.apache.geronimo.clustering.wadi.WADIClusteredHandleInterceptor c:\oss\geronimo\modules\geronimo-clustering-wadi\src\main\java\org\apache\geronimo\clustering\wadi\WADIClusteredHandleInterceptor.java:[69,12] cannot resolve symbol symbol : class HttpResponse location: class org.apache.geronimo.clustering.wadi.WADIClusteredHandleInterceptor c:\oss\geronimo\modules\geronimo-clustering-wadi\src\main\java\org\apache\geronimo\clustering\wadi\WADIClusteredHandleInterceptor.java:[69,35] cannot resolve symbol symbol : class HandleInterceptor location: class org.apache.geronimo.clustering.wadi.WADIClusteredHandleInterceptor c:\oss\geronimo\modules\geronimo-clustering-wadi\src\main\java\org\apache\geronimo\clustering\wadi\WADIClusteredHandleInterceptor.java:[73,55] cannot resolve symbol symbol : class WebClusteredInvocation location: class org.apache.geronimo.clustering.wadi.WADIClusteredHandleInterceptor.WADIWebClusteredInvocation c:\oss\geronimo\modules\geronimo-clustering-wadi\src\main\java\org\apache\geronimo\clustering\wadi\WADIClusteredHandleInterceptor.java:[75,83] cannot resolve symbol symbol : class HttpRequest location: class org.apache.geronimo.clustering.wadi.WADIClusteredHandleInterceptor.WADIWebClusteredInvocation c:\oss\geronimo\modules\geronimo-clustering-wadi\src\main\java\org\apache\geronimo\clustering\wadi\WADIClusteredHandleInterceptor.java:[76,16] cannot resolve symbol symbol : class HttpResponse location: class org.apache.geronimo.clustering.wadi.WADIClusteredHandleInterceptor.WADIWebClusteredInvocation c:\oss\geronimo\modules\geronimo-clustering-wadi\src\main\java\org\apache\geronimo\clustering\wadi\WADIClusteredHandleInterceptor.java:[76,39] cannot resolve symbol symbol : class HandleInterceptor location: class org.apache.geronimo.clustering.wadi.WADIClusteredHandleInterceptor.WADIWebClusteredInvocation c:\oss\geronimo\modules\geronimo-clustering-wadi\src\main\java\org\apache\geronimo\clustering\wadi\WADIClusteredHandleInterceptor.java:[81,12] cannot resolve symbol symbol : class ServletHttpRequest location: class org.apache.geronimo.clustering.wadi.WADIClusteredHandleInterceptor.WADIWebClusteredInvocation c:\oss\geronimo\modules\geronimo-clustering-wadi\src\main\java\org\apache\geronimo\clustering\wadi\WADIClusteredHandleInterceptor.java:[81,53] cannot resolve symbol symbol : class ServletHttpRequest location: class org.apache.geronimo.clustering.wadi.WADIClusteredHandleInterceptor.WADIWebClusteredInvocation c:\oss\geronimo\modules\geronimo-clustering-wadi\src\main\java\org\apache\geronimo\clustering\wadi\WADIClusteredHandleInte
[jira] Commented: (GERONIMO-1053) Session Bean, Finder, & Method Permissions
[
http://issues.apache.org/jira/browse/GERONIMO-1053?page=comments#action_12437515
]
Viacheslav Grinevich commented on GERONIMO-1053:
I waiting for a resolution yet!
> Session Bean, Finder, & Method Permissions
> --
>
> Key: GERONIMO-1053
> URL: http://issues.apache.org/jira/browse/GERONIMO-1053
> Project: Geronimo
> Issue Type: Bug
> Security Level: public(Regular issues)
> Components: OpenEJB, security
>Affects Versions: 1.0-M5
>Reporter: Aaron Mulder
>Priority: Blocker
> Fix For: 1.1.2
>
>
> I have an EAR with a Web App, Session Bean, and CMP Entity Bean, using the M5
> release.
> The user brings up a secure page on the web app and logs in.
> The web code invoked after the login calls the session bean.
> The session bean calls a finder on the entity bean, and gets this (in the
> session bean method code, where it calls the finder):
> {noformat}
> Caused by: javax.ejb.TransactionRolledbackLocalException
> at
> org.openejb.transaction.ContainerPolicy$TxRequired.invoke(ContainerPolicy.java:123)
> at
> org.openejb.transaction.TransactionContextInterceptor.invoke(TransactionContextInterceptor.java:80)
> at
> org.openejb.SystemExceptionInterceptor.invoke(SystemExceptionInterceptor.java:82)
> at
> org.openejb.GenericEJBContainer$DefaultSubjectInterceptor.invoke(GenericEJBContainer.java:545)
> at
> org.openejb.GenericEJBContainer.invoke(GenericEJBContainer.java:238)
> at
> org.openejb.proxy.EJBMethodInterceptor.intercept(EJBMethodInterceptor.java:129)
> at
> org.openejb.proxy.EntityEJBLocalHome$$EnhancerByCGLIB$$afb1a239.findAll()
> at
> org.loadmagus.ejb.TestManagerBean.getAllApplications(TestManagerBean.java:70)
> ... 48 more
> Caused by: javax.ejb.AccessLocalException: access denied
> (javax.security.jacc.EJBMethodPermission EntityBean findAll,LocalHome,)
> at
> org.openejb.security.EJBSecurityInterceptor.invoke(EJBSecurityInterceptor.java:107)
> at
> org.apache.geronimo.naming.java.ComponentContextInterceptor.invoke(ComponentContextInterceptor.java:56)
> at
> org.openejb.ConnectionTrackingInterceptor.invoke(ConnectionTrackingInterceptor.java:81)
> at
> org.openejb.entity.EntityInstanceInterceptor.invoke(EntityInstanceInterceptor.java:136)
> at
> org.openejb.entity.cmp.InTxCacheInterceptor.invoke(InTxCacheInterceptor.java:84)
> at
> org.openejb.transaction.ContainerPolicy$TxRequired.invoke(ContainerPolicy.java:119)
> ... 55 more
> {noformat}
> The ejb-jar.xml for the EJBs in question has:
> {noformat}
>
> Developer
>
>
> Developer
>
> SessionBean
> *
>
>
>
> Developer
>
> EntityBean
> *
>
>
> {noformat}
> So it's a little odd that the session bean sees a transaction rolled back
> exception rather than the real security exception, but whatever.
> The real problem is that both the session bean and the entity bean are
> covered by identical all-inclusive method permission blocks, so if the user
> got into the session bean, there should be no reason they can't get into the
> entity bean. The syntax above is specifically supported in the
> ejb-jar-2_1.xsd Schema (#1; "This style is used to refer to all the methods
> of the specified enterprise bean's home, component, and/or web service
> endpoint interfaces.")
--
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
Building servicemix-3.0-M2-incubating
After running the last command to build the source for version 3.0-M2-incubating using Maven 2.0.4 ie.: C:\apache-servicemix-3.0-M2-incubating\src> mvn install -Dmaven.test.skip=true the last message it gave was: Downloading: https://maven-repository.dev.java.net/nonav/repository/org.codehaus.xfire/poms/xfire-parent-1.1.1.pom [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Error building POM (may not be this project's POM). Project ID: null:xfire-all:jar:1.1.1 Reason: Cannot find parent: org.codehaus.xfire:xfire-parent for project: null:xfire-all:jar:1.1.1 SOS, zul -- View this message in context: http://www.nabble.com/Building-servicemix-3.0-M2-incubating-tf2330151.html#a6482284 Sent from the ServiceMix - Dev mailing list archive at Nabble.com.
[jira] Updated: (GERONIMO-2420) No support of WebDAV http-methods (MKCOL ...) in web-app with security-constraint
[ http://issues.apache.org/jira/browse/GERONIMO-2420?page=all ] Daniel Sportes updated GERONIMO-2420: - Attachment: http-2.txt http flow for the case b) > No support of WebDAV http-methods (MKCOL ...) in web-app with > security-constraint > - > > Key: GERONIMO-2420 > URL: http://issues.apache.org/jira/browse/GERONIMO-2420 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: deployment > Environment: Release in WASCE (probably 1.0) - Windows XP - Java 1.5 >Reporter: Daniel Sportes > Attachments: err.log, http-1.txt, http-2.txt, > server-Bug-Deployment.log, web-app_2_4b.xsd, web.xml > > > The schema web-app_2_4.xsd does not accept WebDAV http-method as PROPFIND, > MKCOL, etc. in security-constraint (in web.xml). > As consequence as I develop a business server based on WebDAV, I cannot > require an authentication for accessing the WebDAV servlet. Just observe it > is possible with Tomcat. > As the error message indicates the web-app_2_4.xsd schema, I patched this > schema in the directory %install%/schema. > Eclipse is now happy and does not mark anymore my web.xml in error. > However, this causes an exception at deployment in the server. > If I remove all forbidden http-method, no more deployment exception of > course, but I do not receive PROPFIND method calls in my servlet. > If I completely remove the security-constraint section, PROPFIND methods are > correctly received in my servlet ... but the user authentication is no more > required (that is not an acceptable solution for a business server). The > method list seems to be coded somewhere else than in the schema. -- 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-2420) No support of WebDAV http-methods (MKCOL ...) in web-app with security-constraint
[ http://issues.apache.org/jira/browse/GERONIMO-2420?page=all ] Daniel Sportes updated GERONIMO-2420: - Attachment: http-1.txt http flow for case a) > No support of WebDAV http-methods (MKCOL ...) in web-app with > security-constraint > - > > Key: GERONIMO-2420 > URL: http://issues.apache.org/jira/browse/GERONIMO-2420 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: deployment > Environment: Release in WASCE (probably 1.0) - Windows XP - Java 1.5 >Reporter: Daniel Sportes > Attachments: err.log, http-1.txt, http-2.txt, > server-Bug-Deployment.log, web-app_2_4b.xsd, web.xml > > > The schema web-app_2_4.xsd does not accept WebDAV http-method as PROPFIND, > MKCOL, etc. in security-constraint (in web.xml). > As consequence as I develop a business server based on WebDAV, I cannot > require an authentication for accessing the WebDAV servlet. Just observe it > is possible with Tomcat. > As the error message indicates the web-app_2_4.xsd schema, I patched this > schema in the directory %install%/schema. > Eclipse is now happy and does not mark anymore my web.xml in error. > However, this causes an exception at deployment in the server. > If I remove all forbidden http-method, no more deployment exception of > course, but I do not receive PROPFIND method calls in my servlet. > If I completely remove the security-constraint section, PROPFIND methods are > correctly received in my servlet ... but the user authentication is no more > required (that is not an acceptable solution for a business server). The > method list seems to be coded somewhere else than in the schema. -- 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-2420) No support of WebDAV http-methods (MKCOL ...) in web-app with security-constraint
[ http://issues.apache.org/jira/browse/GERONIMO-2420?page=comments#action_12437480 ] Daniel Sportes commented on GERONIMO-2420: -- Report of last tests: a) if no one http-method is listed in web-resource-collection: 1) OPTIONS method is routed in the servlet 2) PROPFIND methods are not transmitted to the service() method of my servlet : "An exception or error occurred in the container during the request processing org.apache.catalina.connector.CoyoteAdapter" This behaviour is hardly correct. b) if allowed methods (OPTIONS, HEAD, GET, POST, PUT, DELETE) are listed in web-resource-collection, both OPTIONS and PROPFIND are routed in the service(). This behaviour could be considered as a bit strange, but DO NOT CHANGE IT. This is a good work around for this issue and exactly the result I hoped: 1) authentication is well required 2) all methods are transmittd to the service() method. The Apache Slide project just would require a different web-xml for Geronimo than for Tomcat 5. > No support of WebDAV http-methods (MKCOL ...) in web-app with > security-constraint > - > > Key: GERONIMO-2420 > URL: http://issues.apache.org/jira/browse/GERONIMO-2420 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: deployment > Environment: Release in WASCE (probably 1.0) - Windows XP - Java 1.5 >Reporter: Daniel Sportes > Attachments: err.log, server-Bug-Deployment.log, web-app_2_4b.xsd, > web.xml > > > The schema web-app_2_4.xsd does not accept WebDAV http-method as PROPFIND, > MKCOL, etc. in security-constraint (in web.xml). > As consequence as I develop a business server based on WebDAV, I cannot > require an authentication for accessing the WebDAV servlet. Just observe it > is possible with Tomcat. > As the error message indicates the web-app_2_4.xsd schema, I patched this > schema in the directory %install%/schema. > Eclipse is now happy and does not mark anymore my web.xml in error. > However, this causes an exception at deployment in the server. > If I remove all forbidden http-method, no more deployment exception of > course, but I do not receive PROPFIND method calls in my servlet. > If I completely remove the security-constraint section, PROPFIND methods are > correctly received in my servlet ... but the user authentication is no more > required (that is not an acceptable solution for a business server). The > method list seems to be coded somewhere else than in the schema. -- 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-583) Jetty context Path verification
[ https://issues.apache.org/activemq/browse/SM-583?page=all ]
Guillaume Nodet resolved SM-583.
Fix Version/s: 3.0.1
3.1
Resolution: Fixed
Assignee: Guillaume Nodet
Author: gnodet
Date: Mon Sep 25 01:24:27 2006
New Revision: 449602
URL: http://svn.apache.org/viewvc?view=rev&rev=449602
Log:
SM-583: Jetty context Path verification
Modified:
incubator/servicemix/branches/servicemix-3.0/servicemix-http/src/main/java/org/apache/servicemix/http/jetty/JettyContextManager.java
incubator/servicemix/branches/servicemix-3.0/servicemix-http/src/test/java/org/apache/servicemix/http/ServerManagerTest.java
Author: gnodet
Date: Mon Sep 25 01:24:28 2006
New Revision: 449603
URL: http://svn.apache.org/viewvc?view=rev&rev=449603
Log:
SM-583: Jetty context Path verification
Modified:
incubator/servicemix/trunk/servicemix-http/src/main/java/org/apache/servicemix/http/jetty/JettyContextManager.java
incubator/servicemix/trunk/servicemix-http/src/test/java/org/apache/servicemix/http/ServerManagerTest.java
> Jetty context Path verification
> ---
>
> Key: SM-583
> URL: https://issues.apache.org/activemq/browse/SM-583
> Project: ServiceMix
> Issue Type: Bug
> Components: servicemix-http
>Affects Versions: incubation
> Environment: Linux, jdk 1.5 sun
>Reporter: Charles Souillard
> Assigned To: Guillaume Nodet
> Fix For: 3.0.1, 3.1
>
> Original Estimate: 5 minutes
> Remaining Estimate: 5 minutes
>
> i am using sm build from 2006/09/12.
> I am trying to deploy 2 SUs in sm-http.
> the first one has the following path :
> locationURI="http://localhost:8192/junit_HttpEndpoint_invokeUtilTester";
> the second :
> locationURI="http://localhost:8192/junit_HttpEndpoint_invoke";
> I get the following exception :
> The requested context for path '/junit_HttpEndpoint_invoke' overlaps
> with an existing context for path: '/junit_HttpEndpoint_invokeUtilTester'
> I had a look at the code in
> org.apache.servicemix.http.jetty.JettyContextManager at line 138 (the
> method where is thrown the exception) and I found very strange the
> following test :
> if (h.getContextPath().startsWith(path) ||
> path.startsWith(h.getContextPath())) {
> throw new Exception("The requested context for path '" + path + "'
> overlaps with an existing context for path: '" + h.getContextPath() + "'");
> }
> h is a handler which represents an already deployed path
> (/junit_HttpEndpoint_invokeUtilTester).
> path is the current path (being deployed = /junit_HttpEndpoint_invoke)
> The exception is thrown as the following is true I think :
> h.getContextPath().startsWith(path)
> I can deploy another su having the following path without any error:
> /junit_HttpEndpoint_incrementService
> This let me thinking that there could have a matching region but one
> could not be completely included in another...
> PATCH :
> replace
> if (h.getContextPath().startsWith(path) ||
> path.startsWith(h.getContextPath())) {
> by
> if (h.getContextPath().equals(path)) {
--
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
Build failure due to missing classes in geronimo-clustering-wadi
Hi, The subject says it all. I suspect pom.xml has not been updated to reflect the changes in jars. I won't be able to fix it at the moment. The exact error messages are: Compiling 10 source files to c:\oss\geronimo\modules\geronimo-clustering-wadi\target\classes [INFO] [ERROR] BUILD FAILURE [INFO] [INFO] Compilation failure c:\oss\geronimo\modules\geronimo-clustering-wadi\src\main\java\org\apache\geronimo\clustering\wadi\WADIClusteredHandleInterceptor.java:[32,33] package org.apache.geronimo.jetty doe s not exist c:\oss\geronimo\modules\geronimo-clustering-wadi\src\main\java\org\apache\geronimo\clustering\wadi\WADIClusteredHandleInterceptor.java:[33,41] package org.apache.geronimo.jetty.clu ster does not exist c:\oss\geronimo\modules\geronimo-clustering-wadi\src\main\java\org\apache\geronimo\clustering\wadi\WADIClusteredHandleInterceptor.java:[37,24] package org.mortbay.http does not exi st c:\oss\geronimo\modules\geronimo-clustering-wadi\src\main\java\org\apache\geronimo\clustering\wadi\WADIClusteredHandleInterceptor.java:[38,24] package org.mortbay.http does not exi st c:\oss\geronimo\modules\geronimo-clustering-wadi\src\main\java\org\apache\geronimo\clustering\wadi\WADIClusteredHandleInterceptor.java:[39,33] package org.mortbay.jetty.servlet doe s not exist c:\oss\geronimo\modules\geronimo-clustering-wadi\src\main\java\org\apache\geronimo\clustering\wadi\WADIClusteredHandleInterceptor.java:[40,33] package org.mortbay.jetty.servlet doe s not exist c:\oss\geronimo\modules\geronimo-clustering-wadi\src\main\java\org\apache\geronimo\clustering\wadi\WADIClusteredHandleInterceptor.java:[47,52] cannot resolve symbol symbol : class AbstractClusteredHandleInterceptor location: class org.apache.geronimo.clustering.wadi.WADIClusteredHandleInterceptor c:\oss\geronimo\modules\geronimo-clustering-wadi\src\main\java\org\apache\geronimo\clustering\wadi\WADIClusteredHandleInterceptor.java:[68,98] cannot resolve symbol symbol : class HttpRequest location: class org.apache.geronimo.clustering.wadi.WADIClusteredHandleInterceptor c:\oss\geronimo\modules\geronimo-clustering-wadi\src\main\java\org\apache\geronimo\clustering\wadi\WADIClusteredHandleInterceptor.java:[69,12] cannot resolve symbol symbol : class HttpResponse location: class org.apache.geronimo.clustering.wadi.WADIClusteredHandleInterceptor c:\oss\geronimo\modules\geronimo-clustering-wadi\src\main\java\org\apache\geronimo\clustering\wadi\WADIClusteredHandleInterceptor.java:[69,35] cannot resolve symbol symbol : class HandleInterceptor location: class org.apache.geronimo.clustering.wadi.WADIClusteredHandleInterceptor c:\oss\geronimo\modules\geronimo-clustering-wadi\src\main\java\org\apache\geronimo\clustering\wadi\WADIClusteredHandleInterceptor.java:[73,55] cannot resolve symbol symbol : class WebClusteredInvocation location: class org.apache.geronimo.clustering.wadi.WADIClusteredHandleInterceptor.WADIWebClusteredInvocation c:\oss\geronimo\modules\geronimo-clustering-wadi\src\main\java\org\apache\geronimo\clustering\wadi\WADIClusteredHandleInterceptor.java:[75,83] cannot resolve symbol symbol : class HttpRequest location: class org.apache.geronimo.clustering.wadi.WADIClusteredHandleInterceptor.WADIWebClusteredInvocation c:\oss\geronimo\modules\geronimo-clustering-wadi\src\main\java\org\apache\geronimo\clustering\wadi\WADIClusteredHandleInterceptor.java:[76,16] cannot resolve symbol symbol : class HttpResponse location: class org.apache.geronimo.clustering.wadi.WADIClusteredHandleInterceptor.WADIWebClusteredInvocation c:\oss\geronimo\modules\geronimo-clustering-wadi\src\main\java\org\apache\geronimo\clustering\wadi\WADIClusteredHandleInterceptor.java:[76,39] cannot resolve symbol symbol : class HandleInterceptor location: class org.apache.geronimo.clustering.wadi.WADIClusteredHandleInterceptor.WADIWebClusteredInvocation c:\oss\geronimo\modules\geronimo-clustering-wadi\src\main\java\org\apache\geronimo\clustering\wadi\WADIClusteredHandleInterceptor.java:[81,12] cannot resolve symbol symbol : class ServletHttpRequest location: class org.apache.geronimo.clustering.wadi.WADIClusteredHandleInterceptor.WADIWebClusteredInvocation c:\oss\geronimo\modules\geronimo-clustering-wadi\src\main\java\org\apache\geronimo\clustering\wadi\WADIClusteredHandleInterceptor.java:[81,53] cannot resolve symbol symbol : class ServletHttpRequest location: class org.apache.geronimo.clustering.wadi.WADIClusteredHandleInterceptor.WADIWebClusteredInvocation c:\oss\geronimo\modules\geronimo-clustering-wadi\src\main\java\org\apache\geronimo\clustering\wadi\WADIClusteredHandleInterceptor.java:[81,73] cannot resolve symbol symbol : variable request location: class org.apache.geronimo.clustering.wadi.WADIClusteredHandleInterceptor.WADIWebClusteredInvocation c:\oss\geronimo\modules\geronimo-clustering-wadi\src\main\java\org\apa
[jira] Resolved: (SM-593) Jetty jars missing when running servicemix-web example
[ https://issues.apache.org/activemq/browse/SM-593?page=all ] Guillaume Nodet resolved SM-593. Fix Version/s: 3.0.1 3.1 Resolution: Fixed Assignee: Guillaume Nodet Author: gnodet Date: Mon Sep 25 01:16:28 2006 New Revision: 449600 URL: http://svn.apache.org/viewvc?view=rev&rev=449600 Log: SM-593: Jetty jars missing when running servicemix-web example Modified: incubator/servicemix/branches/servicemix-3.0/samples/servicemix-web/pom.xml Author: gnodet Date: Mon Sep 25 01:16:32 2006 New Revision: 449601 URL: http://svn.apache.org/viewvc?view=rev&rev=449601 Log: SM-593: Jetty jars missing when running servicemix-web example Modified: incubator/servicemix/trunk/samples/servicemix-web/pom.xml > Jetty jars missing when running servicemix-web example > -- > > Key: SM-593 > URL: https://issues.apache.org/activemq/browse/SM-593 > Project: ServiceMix > Issue Type: Bug > Components: servicemix-assembly >Affects Versions: 3.0 >Reporter: Markus Rado > Assigned To: Guillaume Nodet >Priority: Minor > Fix For: 3.0.1, 3.1 > > > Running the servicemix-web example fails with a > java.lang.NoClassDefFoundError: org/mortbay/jetty/nio/SelectChannelConnector. > The problem seems to be that jetty-6.0.0rc4.jar and jetty-util-6.0.0rc4.jar > are missing in WEB-INF/lib. > The build configuration needs to be changed so that these jars are included > in runtime. -- 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: Invalid property 'destinations' of bean class
On 9/25/06, Tommy615 <[EMAIL PROTECTED]> wrote: I attached a image showing the error. It doesn't really help much. Could you provide the full XML file you are using along with the full stack trace? e.g. try piping the output to a file. -- James --- http://radio.weblogs.com/0112098/
[jira] Resolved: (SM-596) add throws DeploymentException to getServices() in AbstractXBeanDeployer
[ https://issues.apache.org/activemq/browse/SM-596?page=all ] Guillaume Nodet resolved SM-596. Fix Version/s: 3.1 Resolution: Fixed Assignee: Guillaume Nodet Author: gnodet Date: Mon Sep 25 01:02:25 2006 New Revision: 449597 URL: http://svn.apache.org/viewvc?view=rev&rev=449597 Log: SM-596: add throws DeploymentException to getServices() in AbstractXBeanDeployer Modified: incubator/servicemix/trunk/servicemix-common/src/main/java/org/apache/servicemix/common/xbean/AbstractXBeanDeployer.java > add throws DeploymentException to getServices() in AbstractXBeanDeployer > > > Key: SM-596 > URL: https://issues.apache.org/activemq/browse/SM-596 > Project: ServiceMix > Issue Type: Improvement > Components: servicemix-common >Affects Versions: 3.0 >Reporter: Raffaele Spazzoli > Assigned To: Guillaume Nodet > Fix For: 3.1 > > > I have a binding component that may create multiple endpoint starting from a > single service unit. I use the AbstractXBeanDeployer to ease the reading of > the > service unit configuration. > The number of endpoint is determined in the getServices method which can be > overridden. The problem is that my getServices method is quite complicated and > the code inside it may rise differnt type of exception wich I can't handel and > which should make the deployment fail. To resolve the problem it would be > enough to change the method signatire from > protected List getServices(Kernel kernel) > to > protected List getServices(Kernel kernel) throws DeploymentException -- 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: Invalid property 'destinations' of bean class
I attached a image showing the error. Thanks James.Strachan wrote: > > On 9/25/06, Tommy615 <[EMAIL PROTECTED]> wrote: >> >> Thanks for your reply. I had tried it at 4.1 as well and the result was >> same. >> Any idea? > > It certainly works in our test case on 4.1. > > http://svn.apache.org/repos/asf/incubator/activemq/trunk/activemq-core/src/test/resources/org/apache/activemq/broker/destinations-on-start.xml > > could you post the stack trace when you try use this file? > > > -- > > James > --- > http://radio.weblogs.com/0112098/ > > http://www.nabble.com/file/126/error.JPG http://www.nabble.com/file/126/error.JPG -- View this message in context: http://www.nabble.com/Invalid-property-%27destinations%27-of-bean-class-tf2328853.html#a6481830 Sent from the ActiveMQ - Dev mailing list archive at Nabble.com.
[jira] Updated: (GERONIMO-2431) generateCSR reverses the attribute sequence in subject name
[ http://issues.apache.org/jira/browse/GERONIMO-2431?page=all ] Vamsavardhana Reddy updated GERONIMO-2431: -- Attachment: GERONIMO-2431-v1.1.x.patch GERONIMO-2431-v1.1.x.patch: Patch for braches 1.1 > generateCSR reverses the attribute sequence in subject name > --- > > Key: GERONIMO-2431 > URL: http://issues.apache.org/jira/browse/GERONIMO-2431 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: security >Affects Versions: 1.1.1 > Environment: G-1.1.1 >Reporter: Vamsavardhana Reddy > Fix For: 1.2, 1.1.2 > > Attachments: GERONIMO-2431-v1.1.x.patch, GERONIMO-2431-v1.2.patch > > > generateCSR function in FileKeystoreInstance is reversing the attribute > sequence in the subject name. For e.g, if the attribute sequence in subject > inside the certificate is (C, ST, L, O, OU, CN), the attribute sequence in > subject in the CSR is (CN, OU, O, L, ST, C). -- 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: Authentication (Jconsole)
Maybe JRE_HOME has a spacein it? On 9/25/06, Tommy615 <[EMAIL PROTECTED]> wrote: I had added the below two parameters inside the activemq.bat but why an error 'is not recognisez as an internal or externam command, operable program or batch file' appeared? I had set the authentication=true. i) -Dcom.sun.management.jmxremote.password.file=%JRE_HOME%/lib/management/jmxremote.password ii) -Dcom.sun.management.jmxremote.access.file=%JRE_HOME%/lib/management/jmxremote.access (I tried at both 4.0.2 and 4.1 versions) Thanks in advance -- View this message in context: http://www.nabble.com/Authentication-%28Jconsole%29-tf2329958.html#a6481748 Sent from the ActiveMQ - Dev mailing list archive at Nabble.com. -- James --- http://radio.weblogs.com/0112098/
[jira] Resolved: (SM-592) notifier.run() missing from DefaultState
[ https://issues.apache.org/activemq/browse/SM-592?page=all ]
Guillaume Nodet resolved SM-592.
Resolution: Fixed
Assignee: Guillaume Nodet
Author: gnodet
Date: Mon Sep 25 00:54:34 2006
New Revision: 449594
URL: http://svn.apache.org/viewvc?view=rev&rev=449594
Log:
SM-592: notifier.run() missing from DefaultState
Modified:
incubator/servicemix/branches/servicemix-3.0/servicemix-beanflow/src/main/java/org/apache/servicemix/beanflow/DefaultState.java
Author: gnodet
Date: Mon Sep 25 00:54:36 2006
New Revision: 449595
URL: http://svn.apache.org/viewvc?view=rev&rev=449595
Log:
SM-592: notifier.run() missing from DefaultState
Modified:
incubator/servicemix/trunk/servicemix-beanflow/src/main/java/org/apache/servicemix/beanflow/DefaultState.java
> notifier.run() missing from DefaultState
>
>
> Key: SM-592
> URL: https://issues.apache.org/activemq/browse/SM-592
> Project: ServiceMix
> Issue Type: Bug
> Components: beanflow
>Affects Versions: 3.0
> Environment: linux, jdk1.5
>Reporter: Roger Menday
> Assigned To: Guillaume Nodet
> Fix For: 3.0.1, 3.1
>
>
> In
> org.apache.servicemix.beanflow.DefaultState
> there seems to be a notifier call missed out from the compareAndSet method
> public boolean compareAndSet(T expected, T newValue) {
> synchronized (lock) {
> if (equals(value, expected)) {
> this.value = newValue;
> **
> notifier.run();
> **
>return true;
> }
> }
> return false;
> }
--
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
Authentication (Jconsole)
I had added the below two parameters inside the activemq.bat but why an error 'is not recognisez as an internal or externam command, operable program or batch file' appeared? I had set the authentication=true. i) -Dcom.sun.management.jmxremote.password.file=%JRE_HOME%/lib/management/jmxremote.password ii) -Dcom.sun.management.jmxremote.access.file=%JRE_HOME%/lib/management/jmxremote.access (I tried at both 4.0.2 and 4.1 versions) Thanks in advance -- View this message in context: http://www.nabble.com/Authentication-%28Jconsole%29-tf2329958.html#a6481748 Sent from the ActiveMQ - Dev mailing list archive at Nabble.com.
Re: Invalid property 'destinations' of bean class
On 9/25/06, Tommy615 <[EMAIL PROTECTED]> wrote: Thanks for your reply. I had tried it at 4.1 as well and the result was same. Any idea? It certainly works in our test case on 4.1. http://svn.apache.org/repos/asf/incubator/activemq/trunk/activemq-core/src/test/resources/org/apache/activemq/broker/destinations-on-start.xml could you post the stack trace when you try use this file? -- James --- http://radio.weblogs.com/0112098/
Re: Invalid property 'destinations' of bean class
Thanks for your reply. I had tried it at 4.1 as well and the result was same. Any idea? James.Strachan wrote: > > only works in 4.1 I'm afraid, I suspect you're using 4.0.x > > On 9/25/06, Tommy615 <[EMAIL PROTECTED]> wrote: >> >> After I putting the below xml code inside the then error occured >> saying that Invalid property 'destinations' of bean class >> [org.apache.activemq.xbean.XBeanBrokerService]: Bean property >> 'destinations' >> is not writable or has an invalid setter method: Does the parameter type >> of >> the setter match the return type of the getter? >> >> >> >> >> >> >> Is it the destination is not a proper parameter of it? >> -- >> View this message in context: >> http://www.nabble.com/Invalid-property-%27destinations%27-of-bean-class-tf2328853.html#a6479041 >> Sent from the ActiveMQ - Dev mailing list archive at Nabble.com. >> >> > > > -- > > James > --- > http://radio.weblogs.com/0112098/ > > -- View this message in context: http://www.nabble.com/Invalid-property-%27destinations%27-of-bean-class-tf2328853.html#a6481674 Sent from the ActiveMQ - Dev mailing list archive at Nabble.com.
Re: Invalid property 'destinations' of bean class
only works in 4.1 I'm afraid, I suspect you're using 4.0.x On 9/25/06, Tommy615 <[EMAIL PROTECTED]> wrote: After I putting the below xml code inside the then error occured saying that Invalid property 'destinations' of bean class [org.apache.activemq.xbean.XBeanBrokerService]: Bean property 'destinations' is not writable or has an invalid setter method: Does the parameter type of the setter match the return type of the getter? Is it the destination is not a proper parameter of it? -- View this message in context: http://www.nabble.com/Invalid-property-%27destinations%27-of-bean-class-tf2328853.html#a6479041 Sent from the ActiveMQ - Dev mailing list archive at Nabble.com. -- James --- http://radio.weblogs.com/0112098/
[jira] Updated: (GERONIMO-2431) generateCSR reverses the attribute sequence in subject name
[ http://issues.apache.org/jira/browse/GERONIMO-2431?page=all ] Vamsavardhana Reddy updated GERONIMO-2431: -- Attachment: GERONIMO-2431-v1.2.patch GERONIMO-2431-v1.2.patch: Chanages the generateCSR method to use subject DER sequence from the certificate instead of subjectDN. > generateCSR reverses the attribute sequence in subject name > --- > > Key: GERONIMO-2431 > URL: http://issues.apache.org/jira/browse/GERONIMO-2431 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: security >Affects Versions: 1.1.1 > Environment: G-1.1.1 >Reporter: Vamsavardhana Reddy > Fix For: 1.1.2, 1.2 > > Attachments: GERONIMO-2431-v1.2.patch > > > generateCSR function in FileKeystoreInstance is reversing the attribute > sequence in the subject name. For e.g, if the attribute sequence in subject > inside the certificate is (C, ST, L, O, OU, CN), the attribute sequence in > subject in the CSR is (CN, OU, O, L, ST, C). -- 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-2431) generateCSR reverses the attribute sequence in subject name
generateCSR reverses the attribute sequence in subject name --- Key: GERONIMO-2431 URL: http://issues.apache.org/jira/browse/GERONIMO-2431 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Components: security Affects Versions: 1.1.1 Environment: G-1.1.1 Reporter: Vamsavardhana Reddy Fix For: 1.1.2, 1.2 generateCSR function in FileKeystoreInstance is reversing the attribute sequence in the subject name. For e.g, if the attribute sequence in subject inside the certificate is (C, ST, L, O, OU, CN), the attribute sequence in subject in the CSR is (CN, OU, O, L, ST, C). -- 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
