[jira] Updated: (AMQ-818) Code Drop for Version 0.0.2 of the activemq-cpp library
[ https://issues.apache.org/activemq/browse/AMQ-818?page=all ] Timothy Bish updated AMQ-818: - Attachment: activemq-cpp-0-0-2-071906.zip Version 0.0.2 of the activemq-cpp source code is attached. Changes: New Features: * Destinations now support the Destination Options shown here: http://www.activemq.org/site/destination-options.html Additional Changes * Extensive code cleanup, including expanded Java DOC comments and more consistant formatting. * Memory leak checking with Rational Purify was done and several small leaks were fixed. * Added additional Unit tests for new functionality, and additional tests for existing feature correctness * Fixed a problem on Windows that was causing the socketinputstream reads to break unexpectedly. * Fixed the username, password, client-id processing so they get out in the ConnectCommand Properly. * Minor bug fixes Code Drop for Version 0.0.2 of the activemq-cpp library --- Key: AMQ-818 URL: https://issues.apache.org/activemq/browse/AMQ-818 Project: ActiveMQ Issue Type: Improvement Components: CMS Reporter: Timothy Bish Attachments: activemq-cpp-0-0-2-071906.zip This issues addresses the code drop for Revision 0.0.2 of the ActiveMQ CPP library. Changes are listed below. New Features: * Destinations now support the Destination Options shown here: http://www.activemq.org/site/destination-options.html Additional Changes * Extensive code cleanup, including expanded Java DOC comments and more consistant formatting. * Memory leak checking with Rational Purify were done and several small leaks were fixed. * Added additional Unit tests for new functionality, and additional tests for existing feature correctness * Minor bug fixes Known Issues * Unchanged from version 0.0.1 -- 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: Creating a secure connection system and using JMSXUserID support
Hi Sepand! On 7/18/06, Sepand M [EMAIL PROTECTED] wrote: Thanks for the info James. Please tell me what you think of the following: I plan on having a new transport class that will do SSL client certificate authentication and then override the ConnectionInfo class's username field (we don't need a password) with the distinguished name of the client. This sounds good. Now, that I think of it. I think that would useful for the authorization layer to be able to access the whole cert that was provided that the transport layer. Would it help if the ConnectionInfo class had an additional transient Object field that you could attach certificate info to? I could have the transport override every command's username with the DN, but that's not needed if I use a UserIdBroker. That sounds good too. This should be ok, right? Thanks, Sepand -- Regards, Hiram Blog: http://hiramchirino.com
Re: Creating a secure connection system and using JMSXUserID support
How about to avoid breaking backwards compatibiility (or introducing a new OpenWire version) just adding a new derivation of a ConnectionInfo which could take additional fields like the certificate token etc? On 7/19/06, Hiram Chirino [EMAIL PROTECTED] wrote: Hi Sepand! On 7/18/06, Sepand M [EMAIL PROTECTED] wrote: Thanks for the info James. Please tell me what you think of the following: I plan on having a new transport class that will do SSL client certificate authentication and then override the ConnectionInfo class's username field (we don't need a password) with the distinguished name of the client. This sounds good. Now, that I think of it. I think that would useful for the authorization layer to be able to access the whole cert that was provided that the transport layer. Would it help if the ConnectionInfo class had an additional transient Object field that you could attach certificate info to? I could have the transport override every command's username with the DN, but that's not needed if I use a UserIdBroker. That sounds good too. This should be ok, right? Thanks, Sepand -- Regards, Hiram Blog: http://hiramchirino.com -- James --- http://radio.weblogs.com/0112098/
Re: Creating a secure connection system and using JMSXUserID support
Adding a transient field to the ConnectionInfo would not cause a wireformat change. I'd rather keep it simple and do it in our current one. On 7/19/06, James Strachan [EMAIL PROTECTED] wrote: How about to avoid breaking backwards compatibiility (or introducing a new OpenWire version) just adding a new derivation of a ConnectionInfo which could take additional fields like the certificate token etc? On 7/19/06, Hiram Chirino [EMAIL PROTECTED] wrote: Hi Sepand! On 7/18/06, Sepand M [EMAIL PROTECTED] wrote: Thanks for the info James. Please tell me what you think of the following: I plan on having a new transport class that will do SSL client certificate authentication and then override the ConnectionInfo class's username field (we don't need a password) with the distinguished name of the client. This sounds good. Now, that I think of it. I think that would useful for the authorization layer to be able to access the whole cert that was provided that the transport layer. Would it help if the ConnectionInfo class had an additional transient Object field that you could attach certificate info to? I could have the transport override every command's username with the DN, but that's not needed if I use a UserIdBroker. That sounds good too. This should be ok, right? Thanks, Sepand -- Regards, Hiram Blog: http://hiramchirino.com -- James --- http://radio.weblogs.com/0112098/ -- Regards, Hiram Blog: http://hiramchirino.com
Re: Creating a secure connection system and using JMSXUserID support
Yep.. that's what I was thinking. On 7/19/06, Sepand M [EMAIL PROTECTED] wrote: I could be mistaken, but the transport class would have access to the transient field and, in the case of ssl, could attach the cert to it as the connections come in. On 7/19/06, James Strachan [EMAIL PROTECTED] wrote: How would the client send the data to a broker if it were transient? :) On 7/19/06, Hiram Chirino [EMAIL PROTECTED] wrote: Adding a transient field to the ConnectionInfo would not cause a wireformat change. I'd rather keep it simple and do it in our current one. On 7/19/06, James Strachan [EMAIL PROTECTED] wrote: How about to avoid breaking backwards compatibiility (or introducing a new OpenWire version) just adding a new derivation of a ConnectionInfo which could take additional fields like the certificate token etc? On 7/19/06, Hiram Chirino [EMAIL PROTECTED] wrote: Hi Sepand! On 7/18/06, Sepand M [EMAIL PROTECTED] wrote: Thanks for the info James. Please tell me what you think of the following: I plan on having a new transport class that will do SSL client certificate authentication and then override the ConnectionInfo class's username field (we don't need a password) with the distinguished name of the client. This sounds good. Now, that I think of it. I think that would useful for the authorization layer to be able to access the whole cert that was provided that the transport layer. Would it help if the ConnectionInfo class had an additional transient Object field that you could attach certificate info to? I could have the transport override every command's username with the DN, but that's not needed if I use a UserIdBroker. That sounds good too. This should be ok, right? Thanks, Sepand -- Regards, Hiram Blog: http://hiramchirino.com -- James --- http://radio.weblogs.com/0112098/ -- Regards, Hiram Blog: http://hiramchirino.com -- James --- http://radio.weblogs.com/0112098/ -- Regards, Hiram Blog: http://hiramchirino.com
Re: LDAP Authorization
On 7/17/06, ngcutura [EMAIL PROTECTED] wrote: Thanks! The patch is not coomplete yet. I still need help with integration into AMQ (Spring style properties) to be able to use it. (copied from previous post) I am not familiar with Spring and I was not able to deduce how to specify module properties in AMQ XML config file. I need help with this and I would very much appreciate the following: - given the LDAPAuthorizationMap.properties file produce XML file - given the LDAPAuthorizationMap.java add code changes to accept properties from XML file above Is there any documentation on this that I can read? Up until now no there wasn't a whole lot of documentation on this area. I've just created a little guide on configuring things in ActiveMQ which hopefully will help some... http://activemq.org/site/developing-plugins.html -- James --- http://radio.weblogs.com/0112098/
Re: Virtual Topics (was Re: Failover topic subscribers)
OK I've just added a test case that seems to show that the destinations are being created lazily when a consumer is added... http://svn.apache.org/repos/asf/incubator/activemq/trunk/activemq-core/src/test/java/org/apache/activemq/usecases/NewConsumerCreatesDestinationTest.java I've tried to simulate the kind of code you'll be calling the virtual topics stuff - namely using the broker.getDestination(topicSubscriberWildcard) to find all the virtual topic subscriber queues etc and it seems to work for me using SVN trunk. On 7/20/06, James Strachan [EMAIL PROTECTED] wrote: On 7/19/06, bmadigan [EMAIL PROTECTED] wrote: Is this the change to call lookup(...) in addConsumer( )? Yes Looks like its not being called. Damn - sorry about that. I knew I should have taken the time to write a test case :). Lemme see if I get chance to write a little test case today I'd like to run the broker in debug, I'm having trouble figuring out where exactly the lazy creation of destinations is happening. It should be the lookup() which calls addDestination() I think. More in a little while... -- James --- http://radio.weblogs.com/0112098/ -- James --- http://radio.weblogs.com/0112098/
[jira] Reopened: (AMQ-789) WireFormatNegotiator could hang a client or server connection if the peer disconnects before sending the wire format info
[ https://issues.apache.org/activemq/browse/AMQ-789?page=all ] Hiram Chirino reopened AMQ-789: --- This should also be backported to 4.0 branch WireFormatNegotiator could hang a client or server connection if the peer disconnects before sending the wire format info - Key: AMQ-789 URL: https://issues.apache.org/activemq/browse/AMQ-789 Project: ActiveMQ Issue Type: Bug Affects Versions: 4.0 Reporter: Hiram Chirino Assigned To: Hiram Chirino Fix For: 4.1 -- 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: More to be added to licenses file for 1.1.1 ?
Technically... its bad for a module to need to access bits from ../ (or ../../ or ../../../../../../). The proper way to do this would be to add them to a new license module, then have each module depend on it, using dependency plugin to download unpack and then antrun to copy into place. Still easier to have LICENSE.txt and NOTICE.txt local to the module. Most of them will be the same, so not much work to maintain... a few will need to be customized to keep us legal. If we want to have a global... then we gotta write up some custom plugin to handle that automatically for us. --jason On Jul 18, 2006, at 8:04 PM, Kevan Miller wrote: On Jul 18, 2006, at 6:43 PM, Alan D. Cabrera wrote: Kevan Miller wrote: On Jul 18, 2006, at 8:53 AM, John Sisson wrote: Whilst testing the geronimo eclipse plugin, eclipse prompted me to acknowledge the Sun license at http://developers.sun.com/ license/berkeley_license.html when caching the j2ee schema files (e.g. http://java.sun.com/xml/ns/j2ee/ejb-jar_2_1.xsd ). This made me wonder whether this license has been included for Geronimo (since we redistribute schema files) and it appears the LICENSE.txt file in 1.1 doesn't contain it. I'll add a JIRA for 1.1.1 if there aren't any objections. Can anyone think of any other licenses or notices we may have overlooked? Yes. Would appreciate your thoughts on the following: 1) Fix LICENSE and NOTICE files for branches/1.1/modules/util (currently they are only Bouncy Castle -- I believe that we have ASL code in there, also). I think we should do it 2) Do we need to add Bouncy Castle to our global LICENSE and NOTICE files (i.e. branches/1.1/modules/scripts/src/resources/) ? I think yes. 3) Insure NOTICE files are included in our jar files (currently only LICENSE files are there) 4) Do we need to add LICENSE/NOTICE files in our generated CARs? 5) Can the global LICENSE and NOTICE files be used in all our generated artifacts (distributions, jars, cars)? Or do we need global files and specific license/notice files for generated module jars and car files? --kevan 2-4 should be run by legal, no? To support #5, I hope we don't need some kind of maven magic. I think 1,2,3 are must do's. I think we can ignore 4. There are some CAR files in ibiblio -- http://www.ibiblio.org/maven/ geronimo/cars/ However, I'm not sure why they are there... They are all 1.0 and dated December 22nd. Should we have them removed? To my knowledge, we don't build or distribute CAR files in 1.1 (we do have .car directories in our repository, but IMO that's no different from any other directory name we might have...) Regarding 5, I think the right thing to do is have a global LICENSE and NOTICE file in the base of our distributions. We currently have this. Each of our jar files should have LICENSE and NOTICE files specific to each jar. I don't think that this is hard to do. Am I wrong? They all need standard ASL license and notice files. util needs to include bouncy castle info. Are there other geronimo generated jars with any licensing requirements beyond ASL 2? --kevan
Re: GroupId for DayTrader needed.
My non-binding, itty-bitty, wimpy, not sure its worth anything vote is for org.apache.geronimo.daytrader --jason On Jul 18, 2006, at 8:15 PM, Prasad Kashyap wrote: OK. I don't have a strong preference to any single groupId name. I believe Matt doesn't either but I'll see if I can get him to clarify that. So between Jeff and Jason, if we can reach a consensus on a name, can we please get the name change done ? Any other proposals ? Any other formalities ? IIf we are planning to drop the m1 build, then I'd like us to start including this in m2 build, with a goal to making the m2 build an exact replica or as close to m1 as possible. Cheers Prasad On 7/18/06, Jason Dillon [EMAIL PROTECTED] wrote: I think the 'samples' bit is not really necessary here. The groupId is just to organize artifacts in the repo. It does not (and should not) represent the full logical structure or package hierarchy of the application/component. But, I also don't think that it makes sense to artificially shorten either just to hack around platform specific issues either. --jason On Jul 18, 2006, at 12:09 PM, Jeff Genender wrote: I am a big fan of org.apache.geronimo.samples.daytrader. But...are we leading ourselves down the path of a Windows dir size too big nightmare? Jeff Jason Dillon wrote: Why not give it is own: org.apache.geronimo.daytrader --jason On Jul 18, 2006, at 11:59 AM, Prasad Kashyap wrote: The DayTrader project needs a consistent groupId for all it's artifacts. Currently, some of it's artifacts are under the geronimo groupid while others are under the org.apache.geronimo groupid. I discussed this with Matt and we decided to pose this Q to the community. One option is to have a groupId called org.apache.geronimo.samples which will be home to daytrader artifacts, other samples we currently have and ones to come. One other thing to consider is the very long artifactId name of some of daytrader's artifacts. An example is something like daytrader-derby-jetty-streamer. When this is coupled with an equally long groupId name, we'll be close to hitting the path limit on windows. Cheers Prasad
Re: GroupId for DayTrader needed.
Man, you have some serious windows scars or you need to ease off on the coffee :-) John Jason Dillon wrote: Um... blah... lets go back 10 years and give everything 8.3 names with mad cryptic names in one directory with a slew of meaning-deficient 3 letter suffixes to tell stuff apart. Oh... no... wait, lets create a long file name obfuscation system using ~[0-9] suffixes on truncated filenames... ya that will be better. Or lets just number all files 1-100 Or how about we generate secure randoms for each file name? or... how about lets just put everything into one big sparse file... Or we could have a post processor that takes a normal assembly + config and then truncates everything and adds a metadata descriptor for resolution. No, thats is too much... lets just use one big sparse file... though secure random file names is starting to grow on me. :-P --jason On Jul 18, 2006, at 9:01 PM, John Sisson wrote: I have already run into problems with path lengths in the 1.1 branch with daytrader now we have moved to 1.1.1-SNAPSHOT. See https://issues.apache.org/jira/browse/DAYTRADER-6 Considering the number of developers (and possibly future developers) on the windows platform, we should ensure it works. Even if it means we have to shorten the names. The groupid and artifactIds are just identifiers, you can have nice long descriptions in the pom files if you like :-) John Jason Dillon wrote: I think the 'samples' bit is not really necessary here. The groupId is just to organize artifacts in the repo. It does not (and should not) represent the full logical structure or package hierarchy of the application/component. But, I also don't think that it makes sense to artificially shorten either just to hack around platform specific issues either. --jason On Jul 18, 2006, at 12:09 PM, Jeff Genender wrote: I am a big fan of org.apache.geronimo.samples.daytrader. But...are we leading ourselves down the path of a Windows dir size too big nightmare? Jeff Jason Dillon wrote: Why not give it is own: org.apache.geronimo.daytrader --jason On Jul 18, 2006, at 11:59 AM, Prasad Kashyap wrote: The DayTrader project needs a consistent groupId for all it's artifacts. Currently, some of it's artifacts are under the geronimo groupid while others are under the org.apache.geronimo groupid. I discussed this with Matt and we decided to pose this Q to the community. One option is to have a groupId called org.apache.geronimo.samples which will be home to daytrader artifacts, other samples we currently have and ones to come. One other thing to consider is the very long artifactId name of some of daytrader's artifacts. An example is something like daytrader-derby-jetty-streamer. When this is coupled with an equally long groupId name, we'll be close to hitting the path limit on windows. Cheers Prasad
ClassLoader and Dependency Charts
HelloLooking into the classloader problems and knowing which classsloader loaded which class has always been a big problem in app servers. Same is the case with dependencies in Geronimo, We spend lot of time in knowing which components has what dependencies. I think it would be nice if in our Web Console we can have a page for showing Dependency chart and classloader chart.What do you say? Do you think we should do it for 1.2 or even additional feature to 1.1 ThanksRakesh
[jira] Created: (GERONIMO-2204) ProxyMethodInterceptor doesn't handle finalize appropriately
ProxyMethodInterceptor doesn't handle finalize appropriately
Key: GERONIMO-2204
URL: http://issues.apache.org/jira/browse/GERONIMO-2204
Project: Geronimo
Issue Type: Bug
Security Level: public (Regular issues)
Components: kernel
Affects Versions: 1.1
Reporter: David Jencks
Assigned To: Dain Sundstrom
Priority: Minor
A user noticed that while debugging in eclipse (or idea with
break-on-exceptions turned on) this method from ProxyMethodInterceptor throws
UnsupportedOperationException when finalize is called on a proxy object:
public final Object intercept(final Object object, final Method method,
final Object[] args, final MethodProxy proxy) throws Throwable {
ProxyInvoker gbeanInvoker;
int interfaceIndex = proxy.getSuperIndex();
synchronized (this) {
if (gbeanInvokers == null) {
throw new DeadProxyException(Proxy is no longer valid);
}
gbeanInvoker = gbeanInvokers[interfaceIndex];
}
if (gbeanInvoker == null) {
throw new UnsupportedOperationException(No implementation method:
objectName= + abstractName + , method= + method);
}
return gbeanInvoker.invoke(abstractName, args);
}
This appears to be harmless since the proxy doesn't implement finalize, but
annoying. We could fix this by explicitly ignoring the finalize method in the
code above, possibly by installing a suitable FinalizeInvoker, or by using a
CallbackFilter with a Noop or SerizializableNoop callback (the strategy used
by spring aop).
Is this worth fixing? Which way would be best?
--
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: Maven2 Conversation Status
On 7/19/06, Jason Dillon [EMAIL PROTECTED] wrote: Can we get some commitment from PMC members to review and vote in these changes so that we can finally finish the move to Maven 2? I'm on holidays in 2 weeks and would be happy to help out as much as it requires to get it tested and merged with the trunk. How do you want us to help out with it? How should we test it out? Will you send some helpful hints to get us started? Taking the chance I'd like to encourage *anyone* to check out svkmerge/m2conversion branch and give it a whirl. It's a great chance to learn a couple of tips and tricks of using M2 in a project. Jacek -- Jacek Laskowski http://www.laskowski.net.pl
[jira] Created: (AMQ-830) switch the C# code to use System.Runtime.InteropServices.Marshal.SizeOf) instead of sizeof() to avoid issues on .Net 1.1 (vs2003)
switch the C# code to use System.Runtime.InteropServices.Marshal.SizeOf) instead of sizeof() to avoid issues on .Net 1.1 (vs2003) - Key: AMQ-830 URL: https://issues.apache.org/activemq/browse/AMQ-830 Project: ActiveMQ Issue Type: Bug Reporter: james strachan Fix For: 4.1 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (AMQ-830) switch the C# code to use System.Runtime.InteropServices.Marshal.SizeOf) instead of sizeof() to avoid issues on .Net 1.1 (vs2003)
[ https://issues.apache.org/activemq/browse/AMQ-830?page=all ] james strachan updated AMQ-830: --- Description: For background see http://www.nabble.com/can-amq-dotnet-build-by-.net-framework1.1-%28vs2003%29-tf1958469.html#a5389861 switch the C# code to use System.Runtime.InteropServices.Marshal.SizeOf) instead of sizeof() to avoid issues on .Net 1.1 (vs2003) - Key: AMQ-830 URL: https://issues.apache.org/activemq/browse/AMQ-830 Project: ActiveMQ Issue Type: Bug Reporter: james strachan Fix For: 4.1 For background see http://www.nabble.com/can-amq-dotnet-build-by-.net-framework1.1-%28vs2003%29-tf1958469.html#a5389861 -- 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: Maven2 Conversation Status
This should do the trick: svn co https://svn.apache.org/repos/asf/geronimo/sandbox/ svkmerge/m2migration cd m2migration ./bootstrap gunzip -c m2-assemblies/geronimo-jetty-j2ee/target/geronimo- jetty-j2ee-1.2-SNAPSHOT-bin.tar.gz | tar xf - ./geronimo-jetty-j2ee/bin/startup.sh tail -f geronimo-jetty- j2ee/var/log/geronimo.out ... ./geronimo-jetty-j2ee/bin/startup.sh --user system --password manager --jason PS. I just typed this up in this email, did not actually run this... in my drunken stupor I might have mistyped something... but the general steps are solid (i've been testing w/this for some time). On Jul 19, 2006, at 12:24 AM, Jacek Laskowski wrote: On 7/19/06, Jason Dillon [EMAIL PROTECTED] wrote: Can we get some commitment from PMC members to review and vote in these changes so that we can finally finish the move to Maven 2? I'm on holidays in 2 weeks and would be happy to help out as much as it requires to get it tested and merged with the trunk. How do you want us to help out with it? How should we test it out? Will you send some helpful hints to get us started? Taking the chance I'd like to encourage *anyone* to check out svkmerge/m2conversion branch and give it a whirl. It's a great chance to learn a couple of tips and tricks of using M2 in a project. Jacek -- Jacek Laskowski http://www.laskowski.net.pl
Re: [DISCUSSION] Content for 1.2
I'd like to see the work to integrate jetty6 go in. However, we'd have to have some discussion about whether we wanted to upgrade the whole of Geronimo to JavaEE5 at that time or just have the web container (well, Jetty at least) support servlet 2.5. regards Jan Matt Hogstrom wrote: All, Its time to start defining the content of what everyone is planning on doing for 1.2. The biggest change so far that I'm aware of are the refactoring of OEJB by Dain and the Maven 2 work done by JDillon, Prasad, Anita and others. Not too much content from an end-user perspective. I think DJencks was doing some work on pluggable JAAC as well. In the spirit of kicking 1.2 off can you post to this thread the things you'd like to get into 1.2? I've heard many folks indiciate that the community would like to time box releases so they don't go on forever so to kick it off I'd think development through the end of August (that's when we'd branch) with a release toward the end of September sounds about right. Here's a strawman format for the ideas with my 2c in there. Proposer Description HogstromImprove tomcat, Jetty and Connector instrumentation HogstromSPECjAppServer Performance improvements. Let the games begin...
Re: [DISCUSSION] Content for 1.2
I'm working on 1) Adding additional providers for javamail beyond SMTP. POP3, NNTP, and NNTP-POST are already in. IMap is in the works. 2) Creating a 1.4 version of the javamail API (already done). 3) Add Yoko support to openejb and do a general cleanup of the openejb CORBA code. 4) Change the openejb CORBA code to use the Geronimo KeystoreManager API. Rick Matt Hogstrom wrote: All, Its time to start defining the content of what everyone is planning on doing for 1.2. The biggest change so far that I'm aware of are the refactoring of OEJB by Dain and the Maven 2 work done by JDillon, Prasad, Anita and others. Not too much content from an end-user perspective. I think DJencks was doing some work on pluggable JAAC as well. In the spirit of kicking 1.2 off can you post to this thread the things you'd like to get into 1.2? I've heard many folks indiciate that the community would like to time box releases so they don't go on forever so to kick it off I'd think development through the end of August (that's when we'd branch) with a release toward the end of September sounds about right. Here's a strawman format for the ideas with my 2c in there. Proposer Description HogstromImprove tomcat, Jetty and Connector instrumentation HogstromSPECjAppServer Performance improvements. Let the games begin...
[jira] Created: (GERONIMO-2205) SecurityRealms portlet does not list stopped security realms
SecurityRealms portlet does not list stopped security realms Key: GERONIMO-2205 URL: http://issues.apache.org/jira/browse/GERONIMO-2205 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Components: console Affects Versions: 1.1, 1.0 Environment: WinXP, Sun JDK1.4.2_08 Reporter: Vamsavardhana Reddy Fix For: 1.1.x, 1.2 Security Realms portlet does not list stopped security realms. It lists only those realms running currently. If indeed this is the expected behaviour, there is no need for State column in the listing since it will show runnng for all entries. -- 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
Are there some XML Schemas for Geronimo 1.1 ?
Hello, I just want to know if there are existing some XML Schemas for Geronimo 1.1 already? If so, then please paste the URL where I could find them. Thanks alot mika -- Echte DSL-Flatrate dauerhaft für 0,- Euro*! Feel free mit GMX DSL! http://www.gmx.net/de/go/dsl
Re: Are there some XML Schemas for Geronimo 1.1 ?
They're in the Geronimo distribution in the schemas/ directory. We don't have them posted to the web site yet though I'm working on it. Thanks, Aaron On 7/19/06, mika [EMAIL PROTECTED] wrote: Hello, I just want to know if there are existing some XML Schemas for Geronimo 1.1 already? If so, then please paste the URL where I could find them. Thanks alot mika -- Echte DSL-Flatrate dauerhaft für 0,- Euro*! Feel free mit GMX DSL! http://www.gmx.net/de/go/dsl
Re: ClassLoader and Dependency Charts
We have some code to show a dependency graph kicking around... We could probably squeeze that into a portlet. Here's an example: http://people.apache.org/~ammulder/classloaders.png However, I'm not sure how useful it will be -- it'll show you dependencies at the class loader level, but it won't tell you which class loaders hold a particular class or which class loader you're actually getting at some point when an error is uncovered. Can you think of some way to make it more useful that way? Thanks, Aaron On 7/19/06, Rakesh Midha [EMAIL PROTECTED] wrote: Hello Looking into the classloader problems and knowing which classsloader loaded which class has always been a big problem in app servers. Same is the case with dependencies in Geronimo, We spend lot of time in knowing which components has what dependencies. I think it would be nice if in our Web Console we can have a page for showing Dependency chart and classloader chart. What do you say? Do you think we should do it for 1.2 or even additional feature to 1.1 Thanks Rakesh
Re: Maven2 Conversation Status
inline.. --- Jason Dillon [EMAIL PROTECTED] wrote: Good news... we are almost there. Bad news... it will probably take another week or so get everything *fully* functional. Right now we have a functional Jetty J2EE assembly, which almost all components enabled. Tomcat J2EE assembly is complaining still, but my hunch is that the fix is relatively simple... for someone who knows better than I. The minimal assemblies are in close seconds, and should be easy to get functional once the J2EE assemblies are finished. As many of you have noticed I have been working out of the sandbox/ svkmerge/m2migration branch for this work. I've been tracking changes made to trunk and merging them periodically to my sandbox so that m2migration is kept up to date wrt to other changes. I think that this could start to get out of hand the longer that this work is kept separate. Already I've had to merge a few changes that would not be needed if we had one tree to work from. It is my opinion that we should probably start the RTC process now for merging the svkmerge/m2migration branch to trunk and to deprecate the Maven 1 build... and nuke its build files. Is this necessary? It is a nice thing to have during bug fixes. I believe that the m2 build is functional enough for people to work with for bug fixes and other changes going into trunk. I also believe that the longer we keep m1 and m2 files around the more work it will be for use to keep them in sync with each other. My recommendation is that we: * RTC vote genesis to be a peer-project to trunk * RTC vote the m2migration branch to be merged back to trunk I would prefer to finish up the work on trunk, but I am fine to merge back to trunk a working m2 build and then continue on the m2migration for another week or so to bunch up changes into per-week intervals for RTC merge-back to trunk (this is not ideal, but will work if that is what is required to get it done). IMO it is better to get trunk sync'd up with the new m2 work that has been done so that when others change configuration that it will get applied to the new build and not get lost in the transition. I am planning to maintain the packaging plugin and configs on the trunk despite all the cosmetic changes done by RTC-2161. I still need to add some functionality and tie some loose ends. I need to add classPath fix and explicit-version.properties fix. Jason, Do I have your permission to do so? We should submit 3 patches for RTC - 1. One from the branch 2. One with packaging plugin and configs made from the trunk 3. One with assembly plugin and Assemblies made from the trunk The patches 2 and 3 can be reviewed and tested independently of 1. IMO this is the only way to keep the build current at all times while we wait for RTC and other issues to be resolved. What do PMC members who will be reviewing this work feel about this approach? I am confident that we can get the m2 build finished in the next few weeks... pending the time required to RTC. Things do not always go as planned. I had planned to have all the servers running on the trunk before I left for my vacation. Thanks Anita Can we get some commitment from PMC members to review and vote in these changes so that we can finally finish the move to Maven 2? Please let me know what your opinion is. We are almost there... let's finish the job. --jason __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
[jira] Resolved: (SM-474) Add validation code in for jbi descriptor to enforce the inclusion of bootstrap classname and classpath elements
[ https://issues.apache.org/activemq/browse/SM-474?page=all ] Philip Dodds resolved SM-474. - Fix Version/s: 3.0-M3 Resolution: Fixed Added validation to the DesriptorFactory Add validation code in for jbi descriptor to enforce the inclusion of bootstrap classname and classpath elements Key: SM-474 URL: https://issues.apache.org/activemq/browse/SM-474 Project: ServiceMix Issue Type: Improvement Components: servicemix-core Affects Versions: incubation Environment: Ubuntu Linux 5.10, Windows XP SP2 Reporter: Grant McDonald Assigned To: Grant McDonald Fix For: 3.0-M3 Original Estimate: 30 minutes Remaining Estimate: 30 minutes Installers whose jbi.xml doesn't contain a bootstrap classpath and class name are invalid as described by the jbi spec and also cause an NPE to be thrown when the component is installed. Add in a validation on the jbi.xml to this effect (hint: JbiElementProcessor or for an easier implementation - DescriptorFactory) -- 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-1967) /remote-deploy url link throws Error 404.
[ http://issues.apache.org/jira/browse/GERONIMO-1967?page=all ] Sachin Patel closed GERONIMO-1967. -- Resolution: Fixed Assignee: Sachin Patel (was: Matt Hogstrom) patch applied /remote-deploy url link throws Error 404. - Key: GERONIMO-1967 URL: http://issues.apache.org/jira/browse/GERONIMO-1967 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: usability Affects Versions: 1.1 Reporter: Prasad Kashyap Assigned To: Sachin Patel Priority: Critical Fix For: 1.1.1 Attachments: logo_head_570x86.gif, remote-deploy.patch The following page on the console (http://localhost:8080/console/portal/apps/apps_war) lists all the WARs with their URL links. Accessing the /remote-deploy link throws an Error 404. Though this app is used by the CLI tool to deploy apps remotely, we should handle this gracefully instead of showing it as an error. Please review and apply the patch. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: GroupId for DayTrader needed.
Jeff, We also need to shorten the artifactId. It makes a good puzzle - Come up with sensible groupId and artifactId such that this does not exceed 256! Example 2 - D:\geronimo-1.2\configs\daytrader-tomcat\target\reposito ry\org\apache\geronimo\configs\daytrader-derby-tomcat_streamer.jar\1.2-SNAPSHOT\daytrader-derby-tomc at_streamer.jar-1.2-SNAPSHOT.car\org.apache.geronimo.modules\ge-activemq-rar\1.2-SNAPSHOT\rar\ activemq-3.2.4-SNAPSHOT.jar This example is taken from http://www.nabble.com/M2-%3A-build-on-Windows-p4914787.html is 256+30 long! Cheers Anita --- Jeff Genender [EMAIL PROTECTED] wrote: I am a big fan of org.apache.geronimo.samples.daytrader. But...are we leading ourselves down the path of a Windows dir size too big nightmare? Jeff Jason Dillon wrote: Why not give it is own: org.apache.geronimo.daytrader --jason On Jul 18, 2006, at 11:59 AM, Prasad Kashyap wrote: The DayTrader project needs a consistent groupId for all it's artifacts. Currently, some of it's artifacts are under the geronimo groupid while others are under the org.apache.geronimo groupid. I discussed this with Matt and we decided to pose this Q to the community. One option is to have a groupId called org.apache.geronimo.samples which will be home to daytrader artifacts, other samples we currently have and ones to come. One other thing to consider is the very long artifactId name of some of daytrader's artifacts. An example is something like daytrader-derby-jetty-streamer. When this is coupled with an equally long groupId name, we'll be close to hitting the path limit on windows. Cheers Prasad __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
[jira] Resolved: (GERONIMO-1582) NPE for EJB webservices.xml with bad jaxrpc-mapping-file
[ http://issues.apache.org/jira/browse/GERONIMO-1582?page=all ] Sachin Patel resolved GERONIMO-1582. Resolution: Fixed Assignee: Sachin Patel (was: Matt Hogstrom) patch applied NPE for EJB webservices.xml with bad jaxrpc-mapping-file -- Key: GERONIMO-1582 URL: http://issues.apache.org/jira/browse/GERONIMO-1582 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: OpenEJB, webservices Affects Versions: 1.1.x Reporter: Aaron Mulder Assigned To: Sachin Patel Priority: Critical Fix For: 1.1.1 Attachments: WSDescriptorParser.patch If the jaxrpc-mapping-file points to an invalid location, a NullPointerException is produced. It should instead give a DeploymentException with a message like: webservices.xml for EJB JAR points to jaxrpc-mapping-file 'META-INF/foo.map' for service 'bar' but that file is not found. 11:47:01,051 ERROR [Deployer] Deployment failed due to java.lang.NullPointerException at org.apache.geronimo.deployment.util.NestedJarFile.getInputStream(NestedJarFile.java:187) at org.apache.geronimo.axis.builder.WSDescriptorParser.readJaxrpcMapping(WSDescriptorParser.java:95) at org.apache.geronimo.axis.builder.WSDescriptorParser.readJaxrpcMapping(WSDescriptorParser.java:88) at org.apache.geronimo.axis.builder.WSDescriptorParser.parseWebServiceDescriptor(WSDescriptorParser.java:315) at org.apache.geronimo.axis.builder.WSDescriptorParser.parseWebServiceDescriptor(WSDescriptorParser.java:379) at org.apache.geronimo.axis.builder.AxisBuilder.parseWebServiceDescriptor(AxisBuilder.java:106) at org.apache.geronimo.axis.builder.AxisBuilder$$FastClassByCGLIB$$16a52a9a.invoke(generated) at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53) at org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38) at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:118) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:800) at org.apache.geronimo.gbean.runtime.RawInvoker.invoke(RawInvoker.java:57) at org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke(RawOperationInvoker.java:36) at org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept(ProxyMethodInterceptor.java:96) at org.apache.geronimo.j2ee.deployment.WebServiceBuilder$$EnhancerByCGLIB$$493cf3fa.parseWebServiceDescriptor(generated) at org.openejb.deployment.OpenEJBModuleBuilder.addGBeans(OpenEJBModuleBuilder.java:500) at org.openejb.deployment.OpenEJBModuleBuilder$$FastClassByCGLIB$$11bd7b20.invoke(generated) at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53) at org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38) at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:118) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:800) at org.apache.geronimo.gbean.runtime.RawInvoker.invoke(RawInvoker.java:57) at org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke(RawOperationInvoker.java:36) at org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept(ProxyMethodInterceptor.java:96) at org.apache.geronimo.j2ee.deployment.ModuleBuilder$$EnhancerByCGLIB$$4ca9e4d7.addGBeans(generated) at org.apache.geronimo.j2ee.deployment.EARConfigBuilder.buildConfiguration(EARConfigBuilder.java:402) at org.apache.geronimo.j2ee.deployment.EARConfigBuilder$$FastClassByCGLIB$$38e56ec6.invoke(generated) at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53) at org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38) at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:118) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:800) at org.apache.geronimo.gbean.runtime.RawInvoker.invoke(RawInvoker.java:57) at org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke(RawOperationInvoker.java:36) at org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept(ProxyMethodInterceptor.java:96) at org.apache.geronimo.deployment.ConfigurationBuilder$$EnhancerByCGLIB$$5896ed49.buildConfiguration(generated) at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:269) at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:102) at
Re: servicemix-http and normalization
To tell you the truth, I was secretly hoping to spur a debate around message normalization. :) The way I understand it, if I start changing the message format put on the bus, it will most likely break other components that expect the older format. I'd be curious to hear what other think about this. Various components seem to use different normalization rules (or no normalization at all) which will inevitably lead to interoperability problems down the road. Time to set higher standards? alex Philip Dodds wrote: Alex, I don't believe anyone is, and we would more than welcome a patch :) just create a JIRA and attach it Thanks P On 7/18/06, Alex Boisvert [EMAIL PROTECTED] wrote: Hi, I've noticed that servicemix-http simply places the child element of the SOAP:Body as the content of JBI normalized message. This doesn't seem to go with the spirit of normalization... I would have expected a WSDL 1.1-wrapper element with message parts if I deployed a WSDL 1.1. document. Is anybody working on this yet? If not, I could volunteer for a patch. cheers, alex
Re: Maven2 Conversation Status
Inline - On 7/19/06, anita kulshreshtha [EMAIL PROTECTED] wrote: inline.. --- Jason Dillon [EMAIL PROTECTED] wrote: It is my opinion that we should probably start the RTC process now for merging the svkmerge/m2migration branch to trunk and to deprecate the Maven 1 build... and nuke its build files. Is this necessary? It is a nice thing to have during bug fixes. Hmmm Anita, I too don't see the need for it. Why can't the m2 build be used for bug fixes ? For bugs in the m2 build itself, we can always refer to an older branch or revision that had maven 1. I think we just have to force people to switch to m2. My recommendation is that we: * RTC vote genesis to be a peer-project to trunk * RTC vote the m2migration branch to be merged back to trunk I would prefer to finish up the work on trunk, but I am fine to merge back to trunk a working m2 build and then continue on the m2migration for another week or so to bunch up changes into per-week intervals for RTC merge-back to trunk (this is not ideal, but will work if that is what is required to get it done). IMO it is better to get trunk sync'd up with the new m2 work that has been done so that when others change configuration that it will get applied to the new build and not get lost in the transition. I am planning to maintain the packaging plugin and configs on the trunk despite all the cosmetic changes done by RTC-2161. I still need to add some functionality and tie some loose ends. I need to add classPath fix and explicit-version.properties fix. Jason, Do I have your permission to do so? We should submit 3 patches for RTC - 1. One from the branch 2. One with packaging plugin and configs made from the trunk 3. One with assembly plugin and Assemblies made from the trunk The patches 2 and 3 can be reviewed and tested independently of 1. IMO this is the only way to keep the build current at all times while we wait for RTC and other issues to be resolved. What do PMC members who will be reviewing this work feel about this approach? Just a word of caution - The more the number of RTC, the more the delay. I am confident that we can get the m2 build finished in the next few weeks... pending the time required to RTC. Things do not always go as planned. I had planned to have all the servers running on the trunk before I left for my vacation. Thanks Anita Cheers Prasad
[jira] Resolved: (SM-483) Code snippets missing from soem static HTML pages
[ https://issues.apache.org/activemq/browse/SM-483?page=all ] Hiram Chirino resolved SM-483. -- Resolution: Fixed I exported all the pages and the sniplets are now working again. Code snippets missing from soem static HTML pages - Key: SM-483 URL: https://issues.apache.org/activemq/browse/SM-483 Project: ServiceMix Issue Type: Bug Reporter: Bruce Snyder Assigned To: Hiram Chirino I've run across a couple of pages where code snippets are missing from the static HTML pages but are present in the wiki pages. I'm assuming that this is maybe due to some issue with the wiki -- html export plugin, but I'm no expert. Here are a couple pages where code snippets are missing: http://www.servicemix.org/site/saaj.html http://servicemix.org/site/pojo-support.html -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[m2 build] configs for uddi
Anita, Here http://issues.apache.org/jira/browse/GERONIMO-2067#action_12416236, you said that you have uploaded a patch for uddi configs. I couldn't find it in any of the patches in this JIRA. Do you think you have the patch on your machine ? Or shall I go ahead and work on it ? Cheers Prasad
[jira] Commented: (DAYTRADER-7) [Daytrader] Precompiled jsp prevents Daytrader EAR from running on other J2EE servers like WebSphere
[ http://issues.apache.org/jira/browse/DAYTRADER-7?page=comments#action_12422184 ] Piyush Agarwal commented on DAYTRADER-7: I agree that Daytrader is in the Geronimo source tree and I am not trying to promote the above change just so that Daytrader works on WebSphere. Adding vendor-specific options and features to the default descriptors will prevent it from working with any of the other J2EE application servers like websphere, weblogic, oracle etc. Daytrader's focus is to be a performance benchmark application for all the J2EE application servers and to be that it has be vendor-neutral. We should be avoiding adding of vendor specific options in it which will go ahead and break all the other J2EE application servers. [Daytrader] Precompiled jsp prevents Daytrader EAR from running on other J2EE servers like WebSphere Key: DAYTRADER-7 URL: http://issues.apache.org/jira/browse/DAYTRADER-7 Project: DayTrader Issue Type: Bug Affects Versions: 1.1 Reporter: Piyush Agarwal In Daytrader1.1 ear file, JspC (Jasper) compiler has been used to precompile the JSPs and it adds these compiled JSP to servlet mappings in the web.xml file and places the compiled classes in the ear file. These precompiled JSPs extend and implement JspC specific classes. This EAR deploys successfully on WebSphere which doesn't use the JspC compiler for compilation. But when the precompiled JSPs are requested from the browser it causes application server to load the precompiled JSP classes which throw exceptions as it cannot find the Jasper specific classes in the classpath. The only way I have been able to fix this problem is to remove the rules in the pom.xml which cause the precompilation of the JSPs and places the precompiled JSP to servlet mapping in the web.xml and then rebuild the EAR file. -- 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: (DAYTRADER-7) [Daytrader] Precompiled jsp prevents Daytrader EAR from running on other J2EE servers like WebSphere
[ http://issues.apache.org/jira/browse/DAYTRADER-7?page=comments#action_12422191 ] Jacek Laskowski commented on DAYTRADER-7: - I'm leaning towards Piyush's view (sorry Jason and Jeff), but on the other hand it's got me thinking whether DayTrader should be part of Geronimo at all. If its goal is to be a platform-independent performance benchmark application why it's part of Apache Geronimo project? On to the main question, why can't we support other application servers? Why do we precompile these JSPs at all? The more servers DayTrader supports the merrier, right? [Daytrader] Precompiled jsp prevents Daytrader EAR from running on other J2EE servers like WebSphere Key: DAYTRADER-7 URL: http://issues.apache.org/jira/browse/DAYTRADER-7 Project: DayTrader Issue Type: Bug Affects Versions: 1.1 Reporter: Piyush Agarwal In Daytrader1.1 ear file, JspC (Jasper) compiler has been used to precompile the JSPs and it adds these compiled JSP to servlet mappings in the web.xml file and places the compiled classes in the ear file. These precompiled JSPs extend and implement JspC specific classes. This EAR deploys successfully on WebSphere which doesn't use the JspC compiler for compilation. But when the precompiled JSPs are requested from the browser it causes application server to load the precompiled JSP classes which throw exceptions as it cannot find the Jasper specific classes in the classpath. The only way I have been able to fix this problem is to remove the rules in the pom.xml which cause the precompilation of the JSPs and places the precompiled JSP to servlet mapping in the web.xml and then rebuild the EAR file. -- 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: (DAYTRADER-7) [Daytrader] Precompiled jsp prevents Daytrader EAR from running on other J2EE servers like WebSphere
[ http://issues.apache.org/jira/browse/DAYTRADER-7?page=comments#action_12422192 ] Scott Nicholls commented on DAYTRADER-7: Another option would be to change the build process to bundle the needed jar files into the war. Of course, this isn't necessary for those app servers that come distributed with those libraries -- which is why it wasn't done in this case. You should also be able to modify the app server's classpath to include the missing libraries as well. IMO, this issue does not prevent it from working with any of the other J2EE application servers. It does make things a little less convenient, I'll agree. [Daytrader] Precompiled jsp prevents Daytrader EAR from running on other J2EE servers like WebSphere Key: DAYTRADER-7 URL: http://issues.apache.org/jira/browse/DAYTRADER-7 Project: DayTrader Issue Type: Bug Affects Versions: 1.1 Reporter: Piyush Agarwal In Daytrader1.1 ear file, JspC (Jasper) compiler has been used to precompile the JSPs and it adds these compiled JSP to servlet mappings in the web.xml file and places the compiled classes in the ear file. These precompiled JSPs extend and implement JspC specific classes. This EAR deploys successfully on WebSphere which doesn't use the JspC compiler for compilation. But when the precompiled JSPs are requested from the browser it causes application server to load the precompiled JSP classes which throw exceptions as it cannot find the Jasper specific classes in the classpath. The only way I have been able to fix this problem is to remove the rules in the pom.xml which cause the precompilation of the JSPs and places the precompiled JSP to servlet mapping in the web.xml and then rebuild the EAR file. -- 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: (DAYTRADER-7) [Daytrader] Precompiled jsp prevents Daytrader EAR from running on other J2EE servers like WebSphere
[ http://issues.apache.org/jira/browse/DAYTRADER-7?page=comments#action_12422194 ] Jeff Genender commented on DAYTRADER-7: --- Im leaning towards Piyush's view (sorry Jason and Jeff), but on the other hand it's got me thinking whether DayTrader should be part of Geronimo at all. If its goal is to be a platform-independent performance benchmark application why it's part of Apache Geronimo project? I agree with you somewhat here, but unfortunately it is very Geronimo centric (codewise/DD) at this point and we would need to decide if this is Geronimo or not. From someone who lead a team to get this working on several platforms, I can honestly say that this is/was no simple task. and we will likely run into issues where things need to be significantly different for each of the application servers. IMHO, if we strip out much of the server specific code and start using tools like XDoclet and some of the AXIS compiling tools to be a part of the build rather than hard code the stubs and DDs, I think this will be a very viable possibility. We kind of do support multiple appservers. I believe we have a set of jboss DDs in there. On to the main question, why can't we support other application servers? Why do we precompile these JSPs at all? The more servers DayTrader supports the merrier, right? Being that this is a performance application, I would think that the more precompiling one can do, the better. However, why can't we make precompiling an option? If we do remove it, we may need a web option to compile the JSPs (Liferay has a really cool precompile option build into the web application itself)...i.e. it can hit all the JSP links behind the scenes...thus using the web server's native compiler. But this will be a bit of a PITA since a server restart will possibly yield a requirement to compile the JSPs once again depending on app server vendor. Yes we can support multiple application servers, but I think the answer will lie in leveraging XDoclet and other compilers. [Daytrader] Precompiled jsp prevents Daytrader EAR from running on other J2EE servers like WebSphere Key: DAYTRADER-7 URL: http://issues.apache.org/jira/browse/DAYTRADER-7 Project: DayTrader Issue Type: Bug Affects Versions: 1.1 Reporter: Piyush Agarwal In Daytrader1.1 ear file, JspC (Jasper) compiler has been used to precompile the JSPs and it adds these compiled JSP to servlet mappings in the web.xml file and places the compiled classes in the ear file. These precompiled JSPs extend and implement JspC specific classes. This EAR deploys successfully on WebSphere which doesn't use the JspC compiler for compilation. But when the precompiled JSPs are requested from the browser it causes application server to load the precompiled JSP classes which throw exceptions as it cannot find the Jasper specific classes in the classpath. The only way I have been able to fix this problem is to remove the rules in the pom.xml which cause the precompilation of the JSPs and places the precompiled JSP to servlet mapping in the web.xml and then rebuild the EAR file. -- 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: Maven2 Conversation Status
the Maven 1 build... and nuke its build files. Is this necessary? It is a nice thing to have during bug fixes. Yes this is necessary. We already have had several commits to trunk that changed Maven 1 configurations and skipped Maven 2... the longer we have both systems in place the more likely they will get out of sync. I am planning to maintain the packaging plugin and configs on the trunk despite all the cosmetic changes done by RTC-2161. I still need to add Please do not work from trunk... it will be very difficult to apply patches you make to trunk to the m2migration branch which is what is under active development. some functionality and tie some loose ends. I need to add classPath fix and explicit-version.properties fix. Jason, Do I have your permission to do so? What are the changes? We should submit 3 patches for RTC - 1. One from the branch 2. One with packaging plugin and configs made from the trunk 3. One with assembly plugin and Assemblies made from the trunk The patches 2 and 3 can be reviewed and tested independently of 1. IMO this is the only way to keep the build current at all times while we wait for RTC and other issues to be resolved. I do not plan on submitting a patch for RTC. I can produce a rather nasty diff of the trees for review if that is what the PMC wants, but IMO that would be a waste of time for them to review. Instead I suggest that the review be done by checking out the branch, building and then starting the Jetty assembly. --jason
Re: Maven2 Conversation Status
We should submit 3 patches for RTC - 1. One from the branch 2. One with packaging plugin and configs made from the trunk 3. One with assembly plugin and Assemblies made from the trunk The patches 2 and 3 can be reviewed and tested independently of 1. IMO this is the only way to keep the build current at all times while we wait for RTC and other issues to be resolved. What do PMC members who will be reviewing this work feel about this approach? Just a word of caution - The more the number of RTC, the more the delay. I agree. I'd rather get patches applied to m2migration and then use that branch for RTC review. --jason
[jira] Commented: (AMQ-776) ConduitBridge can malfunction when first of a set of consumers goes away
[ https://issues.apache.org/activemq/browse/AMQ-776?page=comments#action_36594 ] Kevin Yaussy commented on AMQ-776: -- Any reason why clearDownSubscriptions in DemandForwardingBridgeSupport is uncoded? Or perhaps overridden in ConduitBridge? I've coded an override method in ConduitBridge and this seems to take care of the issue. Maybe you coded it once, but some test cases failed? ConduitBridge can malfunction when first of a set of consumers goes away Key: AMQ-776 URL: https://issues.apache.org/activemq/browse/AMQ-776 Project: ActiveMQ Issue Type: Bug Components: Broker Affects Versions: 4.0.1 Reporter: Kevin Yaussy Priority: Critical Attachments: ConduitBridge.patch When the following scenario is followed, any of the subsequent consumers will stop receiving messages. I've reproduced this using the ConsumerTool, and ProducerTool supplied in the example area of the distribution. +++ Start Broker A Start Broker B Start Consumer 1, connecting to Broker B, consuming FOO Start Consumer 2, connecting to Broker B, consuming FOO Start Publisher, connecting to Broker A, publishing FOO Ctl-C out of Consumer 1 Consumer 2 stops receiving messages +++ Seems to me that ConduitBridge is supposed to track all consumers for a given subscription, by way of DemandSubscription. It is seeding DemandSubscription with the originating consumer, but when subsequent consumers are added, the ConduitBridge::addToAlreadyInterestedConsumers re-adds the original subscriber to the DemandSubscription's map - so the map only ever has the original subscription. I've attached a patch. Hope the change is good. -- 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: GroupId for DayTrader needed.
I think that in general... the m2 repository using the m2 style of artifactId and groupId names is not compatible with Windows. Short of changing the way m2 works or altering the m2 naming standard, I do not see any simple way around this problem. And we are getting hit by this in two places too... building the server, and then again when running the server. I think we need to find a real solution to this issue and not just truncate the names to get around problem... until it pops up again... which is will. And as much as I would love to just give all windows users the shaft and force them to snap out of their microsoft induced blue screen of death, reboot every day, annoying dancing paper clip, stupid file locking, file names can't be longer than 256 insanity... and I would really love to do that... we can't :-( Lucky we don't have to support TRS-80, CPM or Altair users... --jason On Jul 19, 2006, at 7:38 AM, anita kulshreshtha wrote: Jeff, We also need to shorten the artifactId. It makes a good puzzle - Come up with sensible groupId and artifactId such that this does not exceed 256! Example 2 - D:\geronimo-1.2\configs\daytrader-tomcat\target\reposito ry\org\apache\geronimo\configs\daytrader-derby-tomcat_streamer.jar \1.2-SNAPSHOT\daytrader-derby-tomc at_streamer.jar-1.2-SNAPSHOT.car\org.apache.geronimo.modules\ge- activemq-rar\1.2-SNAPSHOT\rar\ activemq-3.2.4-SNAPSHOT.jar This example is taken from http://www.nabble.com/M2-%3A-build-on-Windows-p4914787.html is 256+30 long! Cheers Anita --- Jeff Genender [EMAIL PROTECTED] wrote: I am a big fan of org.apache.geronimo.samples.daytrader. But...are we leading ourselves down the path of a Windows dir size too big nightmare? Jeff Jason Dillon wrote: Why not give it is own: org.apache.geronimo.daytrader --jason On Jul 18, 2006, at 11:59 AM, Prasad Kashyap wrote: The DayTrader project needs a consistent groupId for all it's artifacts. Currently, some of it's artifacts are under the geronimo groupid while others are under the org.apache.geronimo groupid. I discussed this with Matt and we decided to pose this Q to the community. One option is to have a groupId called org.apache.geronimo.samples which will be home to daytrader artifacts, other samples we currently have and ones to come. One other thing to consider is the very long artifactId name of some of daytrader's artifacts. An example is something like daytrader-derby-jetty-streamer. When this is coupled with an equally long groupId name, we'll be close to hitting the path limit on windows. Cheers Prasad __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: ClassLoader and Dependency Charts
Aaron Mulder wrote: http://people.apache.org/~ammulder/classloaders.png However, I'm not sure how useful it will be -- it'll show you dependencies at the class loader level, but it won't tell you which class loaders hold a particular class or which class loader you're actually getting at some point when an error is uncovered. Also, it still needs arrows. :) Right now, the code for that graph produces SVG. It would be great to make it interactive so that you could drag the nodes around, click on a node to load a div that shows which classes are loaded in it, and maybe even collapse certain branches. At JavaOne, I got a few simple JavaScript behaviors working with the graph prototype, but I'm not sure how complex it would be to add full-out drag and drop. Perhaps you can throw the code into the sandbox so other people can check it out and build on it? If I recall correctly, I was careful to make sure that all of its dependencies have Apache-compatible licenses, (which was actually quite difficult). Alternatively, someone could create and share a non-ASF-hosted plugin that makes use of one of the many LGPL graph libraries out there. Cheers, Erin
[jira] Assigned: (GERONIMO-2066) Openejb migration to M2
[ http://issues.apache.org/jira/browse/GERONIMO-2066?page=all ] Prasad Kashyap reassigned GERONIMO-2066: Assignee: Prasad Kashyap Openejb migration to M2 --- Key: GERONIMO-2066 URL: http://issues.apache.org/jira/browse/GERONIMO-2066 Project: Geronimo Issue Type: Sub-task Security Level: public(Regular issues) Components: buildsystem Environment: All Reporter: Anita Kulshreshtha Assigned To: Prasad Kashyap Attachments: openejb.patch, openejb.patch, openejb.patch, openejb.patch The attached patch provides a local openejb build for Geronimo using o.a.g.modules groupId. This is to ensure that the latest openejb jars are available. The results for rev 2659 are below : Path: . URL: https://svn.codehaus.org/openejb/branches/v2_1/openejb2 Repository UUID: 2b0c1533-c60b-0410-b8bd-89f67432e5c6 Revision: 2659 Node Kind: directory Schedule: normal Last Changed Author: gdamour Last Changed Rev: 2659 Last Changed Date: 2006-05-27 08:00:16 -0400 (Sat, 27 May 2006) Properties Last Updated: 2006-05-26 19:05:28 -0400 (Fri, 26 May 2006) Todo - fix the test failures. APSHOT\openejb-builder-2.1-SNAPSHOT.jar [INFO] [INFO] [INFO] [INFO] Reactor Summary: [INFO] [INFO] OpenEJB SUCCESS [3.953s] [INFO] OpenEJB :: Core SUCCESS [30.515s] [INFO] OpenEJB :: PK Generation :: Builder SUCCESS [9.297s] [INFO] OpenEJB :: Builder . SUCCESS [27.875s] [INFO] [INFO] [INFO] BUILD SUCCESSFUL [INFO] [INFO] Total time: 1 minute 12 seconds [INFO] Finished at: Mon May 29 08:11:40 EDT 2006 [INFO] Final Memory: 17M/53M [INFO] -- 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: (SM-490) Inconsistent property names for JbiConstants.PROTOCOL_TYPE and JbiConstants.PROTOCOL_HEADERS
Inconsistent property names for JbiConstants.PROTOCOL_TYPE and JbiConstants.PROTOCOL_HEADERS Key: SM-490 URL: https://issues.apache.org/activemq/browse/SM-490 Project: ServiceMix Issue Type: Bug Components: servicemix-core Affects Versions: 2.0.3, 3.0-M1, 3.0-M2, 3.0-M3 Reporter: Alex Boisvert Fix For: 3.0 Attachments: JbiConstants.diff The attached patch fixes the property names of JbiConstants.PROTOCOL_TYPE and JbiConstants.PROTOCOL_HEADERS according to JBI spec 1.0-FR section 5.5.1.1.3 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (AMQ-833) make the Subscription MBeans easier to view/navigate using jconsole
make the Subscription MBeans easier to view/navigate using jconsole --- Key: AMQ-833 URL: https://issues.apache.org/activemq/browse/AMQ-833 Project: ActiveMQ Issue Type: Improvement Affects Versions: 4.2 Reporter: james strachan e.g. when you look at subscriptions in the JMX view... http://incubator.apache.org/activemq/jmx.html you often see a huge list of subscriptions in the tree, with no idea what they are for. Could we add more of a tree structure maybe? e.g. Subscriptions/Queue/FOO.BAR? -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (AMQ-833) make the Subscription MBeans easier to view/navigate using jconsole
[ https://issues.apache.org/activemq/browse/AMQ-833?page=all ] james strachan updated AMQ-833: --- Fix Version/s: 4.2 Affects Version/s: 4.0.1 (was: 4.2) make the Subscription MBeans easier to view/navigate using jconsole --- Key: AMQ-833 URL: https://issues.apache.org/activemq/browse/AMQ-833 Project: ActiveMQ Issue Type: Improvement Affects Versions: 4.0.1 Reporter: james strachan Fix For: 4.2 e.g. when you look at subscriptions in the JMX view... http://incubator.apache.org/activemq/jmx.html you often see a huge list of subscriptions in the tree, with no idea what they are for. Could we add more of a tree structure maybe? e.g. Subscriptions/Queue/FOO.BAR? -- 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
Tomcat assembly failure
Anyone know how to fix this: snip Booting Geronimo Kernel (in Java 1.4.2_09)... log4j:WARN No appenders could be found for logger (org.apache.geronimo.system.main.Daemon). log4j:WARN Please initialize the log4j system properly. Module 1/18 org.apache.geronimo.configs/rmi-naming/1.2-SNAPSHOT/ car started in 1.309s Module 2/18 org.apache.geronimo.configs/j2ee-server/1.2-SNAPSHOT/ car started in 1.850s Module 3/18 org.apache.geronimo.configs/j2ee-security/1.2-SNAPSHOT/ car started in 1.865s Module 4/18 org.apache.geronimo.configs/axis/1.2-SNAPSHOT/ carstarted in .353s Module 5/18 org.apache.geronimo.configs/openejb/1.2-SNAPSHOT/ car started in 9.985s Module 6/18 org.apache.geronimo.configs/system-database/1.2-SNAPSHOT/ car started in .000s Module 7/18 org.apache.geronimo.configs/activemq-broker/1.2-SNAPSHOT/ car started in 4.712s Module 8/18 org.apache.geronimo.configs/activemq/1.2-SNAPSHOT/ carstarted in 3.279s Module 9/18 org.apache.geronimo.configs/tomcat/1.2-SNAPSHOT/ car Server Startup failed org.apache.geronimo.kernel.config.LifecycleException: start of org.apache.geronimo.configs/tomcat/1.2-SNAPSHOT/car failed at org.apache.geronimo.kernel.config.SimpleConfigurationManager.startConfig uration(SimpleConfigurationManager.java:529) at org.apache.geronimo.kernel.config.SimpleConfigurationManager.startConfig uration(SimpleConfigurationManager.java:493) at org.apache.geronimo.kernel.config.SimpleConfigurationManager$ $FastClassByCGLIB$$ce77a924.invoke(generated) at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53) at org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke (FastMethodInvoker.java:38) at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke (GBeanOperation.java:122) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke (GBeanInstance.java:817) at org.apache.geronimo.gbean.runtime.RawInvoker.invoke (RawInvoker.java:57) at org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke (RawOperationInvoker.java:35) at org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept (ProxyMethodInterceptor.java:96) at org.apache.geronimo.kernel.config.EditableConfigurationManager$ $EnhancerByCGLIB$$443b9517.startConfiguration(generated) at org.apache.geronimo.system.main.Daemon.doStartup(Daemon.java:297) at org.apache.geronimo.system.main.Daemon.init(Daemon.java:74) at org.apache.geronimo.system.main.Daemon.main(Daemon.java:377) Caused by: org.apache.geronimo.kernel.config.InvalidConfigException: Unknown start exception at org.apache.geronimo.kernel.config.ConfigurationUtil.startConfigurationGB eans(ConfigurationUtil.java:440) at org.apache.geronimo.kernel.config.KernelConfigurationManager.start (KernelConfigurationManager.java:187) at org.apache.geronimo.kernel.config.SimpleConfigurationManager.startConfig uration(SimpleConfigurationManager.java:512) ... 13 more Caused by: org.apache.geronimo.gbean.InvalidConfigurationException: Configuration org.apache.geronimo.configs/tomcat/1.2-SNAPSHOT/car failed to start due to the following reasons: The service ServiceModule=org.apache.geronimo.configs/tomcat/1.2- SNAPSHOT/car,j2eeType=GBean,name=TomcatEngine did not start because org.apache.geronimo.configs/tomcat/1.2-SNAPSHOT/car? ServiceModule=org.apache.geronimo.configs/tomcat/1.2-SNAPSHOT/ car,j2eeType=GBean,name=TomcatResources did not start. The service ServiceModule=org.apache.geronimo.configs/tomcat/1.2- SNAPSHOT/car,j2eeType=GBean,name=TomcatAJPConnector did not start because org.apache.geronimo.configs/tomcat/1.2-SNAPSHOT/car? ServiceModule=org.apache.geronimo.configs/tomcat/1.2-SNAPSHOT/ car,j2eeType=GBean,name=TomcatWebContainer did not start. The service ServiceModule=org.apache.geronimo.configs/tomcat/1.2- SNAPSHOT/car,j2eeType=GBean,name=TomcatWebSSLConnector did not start because org.apache.geronimo.configs/tomcat/1.2-SNAPSHOT/car? ServiceModule=org.apache.geronimo.configs/tomcat/1.2-SNAPSHOT/ car,j2eeType=GBean,name=TomcatWebContainer did not start. The service ServiceModule=org.apache.geronimo.configs/tomcat/1.2- SNAPSHOT/car,j2eeType=GBean,name=TomcatWebContainer did not start because org.apache.geronimo.configs/tomcat/1.2-SNAPSHOT/car? ServiceModule=org.apache.geronimo.configs/tomcat/1.2-SNAPSHOT/ car,j2eeType=GBean,name=TomcatEngine did not start. The service ServiceModule=org.apache.geronimo.configs/tomcat/1.2- SNAPSHOT/car,j2eeType=GBean,name=TomcatWebConnector did not start because org.apache.geronimo.configs/tomcat/1.2-SNAPSHOT/car? ServiceModule=org.apache.geronimo.configs/tomcat/1.2-SNAPSHOT/ car,j2eeType=GBean,name=TomcatWebContainer did not start. The service ServiceModule=org.apache.geronimo.configs/tomcat/1.2- SNAPSHOT/car,j2eeType=GBean,name=TomcatResources did not start for an
Re: Tomcat assembly failure
FYI, modules/tomcat was not including the right resources. Thanks for the hint Mr. Jencks :-) --jason -- View this message in context: http://www.nabble.com/Tomcat-assembly-failure-tf1968742.html#a5404498 Sent from the Apache Geronimo - Dev forum at Nabble.com.
[jira] Created: (DAYTRADER-8) Small difference in sync order processing between Direct and EJB mode
Small difference in sync order processing between Direct and EJB mode
--
Key: DAYTRADER-8
URL: http://issues.apache.org/jira/browse/DAYTRADER-8
Project: DayTrader
Issue Type: Bug
Components: EJB Tier
Affects Versions: 1.1
Reporter: Christopher James Blythe
Priority: Minor
I have noticed a slight difference in the behavior of synchronous buy/sell
operations between EJB and JDBC mode. For example, in Sync/Direct mode, if you
perform a buy operation the resulting output of the NewOrder pages will look
something like the following...
271002 open2006-07-19 17:04:50.921 null24.95 buy
s:0 100.0
If I perform the same operation in Sync/EJB mode, I get the following...
272002 closed 2006-07-19 17:12:25.156 2006-07-19
17:12:25.156 24.95 buy s:1 100.0
Notice the differences between the two...
- the status (closed vs. open)
- the completion date (null vs an actual value)
I have looked into the code for this and it seems that the EJB version actually
returns a refreshed version of the bean (as performed by the ejb container).
However, in the JDBC/Direct code we perform the necessary updates to the order
via the order processing apis, but we never update the actual local copy of the
order bean before returning this.
I realize this may be a minor detail, but it does point out a slight difference
between the execution of Direct/EJB mode. The simple solution is to re-fetch
the order data before the buy/sell operations are completed in the
TradeDirect.java code, similar to the following...
orderData = getOrderData(conn, orderData.getOrderID().intValue());
if (txn != null) {
if ( Log.doTrace() )
Log.trace(TradeDirect:sell committing global transaction);
txn.commit();
setInGlobalTxn(false);
}
else
commit(conn);
Will attach a patch with this code tomorrow morning...
--
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: Virtual Topics (was Re: Failover topic subscribers)
Is this the change to call lookup(...) in addConsumer( )? Looks like its not being called. I'd like to run the broker in debug, I'm having trouble figuring out where exactly the lazy creation of destinations is happening. -- View this message in context: http://www.nabble.com/Re%3A-Virtual-Topics-%28was-Re%3A-Failover-topic-subscribers%29-tf1942508.html#a5404863 Sent from the ActiveMQ - Dev forum at Nabble.com.
[jira] Created: (GERONIMO-2206) examples configs [jsp-examples, servlets-examples]
examples configs [jsp-examples, servlets-examples] -- Key: GERONIMO-2206 URL: http://issues.apache.org/jira/browse/GERONIMO-2206 Project: Geronimo Issue Type: Sub-task Security Level: public (Regular issues) Components: buildsystem Affects Versions: 1.2 Reporter: Prasad Kashyap Assigned To: Jason Dillon Fix For: 1.2 Attachments: examples-configs.patch patch enables the following configs - jsp-examples-jetty - jsp-examples-tomcat - servlet-examples-tomcat It also puts geronimoPlugin config option to the car-maven-plugin of console configs. servlets-examples-jetty config gives me the following error. [INFO] Could not load servlet class compressionFilters.CompressionFilterTestServlet compressionFilters.CompressionFilterTestServlet in classloader org.apache.geronimo.configs/servlet-examples-jetty/1.2-SNAPSHOT/car -- 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-2206) examples configs [jsp-examples, servlets-examples]
[ http://issues.apache.org/jira/browse/GERONIMO-2206?page=all ] Prasad Kashyap updated GERONIMO-2206: - Attachment: examples-configs.patch examples configs [jsp-examples, servlets-examples] -- Key: GERONIMO-2206 URL: http://issues.apache.org/jira/browse/GERONIMO-2206 Project: Geronimo Issue Type: Sub-task Security Level: public(Regular issues) Components: buildsystem Affects Versions: 1.2 Reporter: Prasad Kashyap Assigned To: Jason Dillon Fix For: 1.2 Attachments: examples-configs.patch patch enables the following configs - jsp-examples-jetty - jsp-examples-tomcat - servlet-examples-tomcat It also puts geronimoPlugin config option to the car-maven-plugin of console configs. servlets-examples-jetty config gives me the following error. [INFO] Could not load servlet class compressionFilters.CompressionFilterTestServlet compressionFilters.CompressionFilterTestServlet in classloader org.apache.geronimo.configs/servlet-examples-jetty/1.2-SNAPSHOT/car -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (GERONIMO-2067) Configs migration to M2
[ http://issues.apache.org/jira/browse/GERONIMO-2067?page=all ] Prasad Kashyap resolved GERONIMO-2067. -- Resolution: Fixed Individually handled by http://issues.apache.org/jira/browse/GERONIMO-2201 http://issues.apache.org/jira/browse/GERONIMO-2206 Configs migration to M2 --- Key: GERONIMO-2067 URL: http://issues.apache.org/jira/browse/GERONIMO-2067 Project: Geronimo Issue Type: Sub-task Security Level: public(Regular issues) Components: buildsystem Affects Versions: 1.2 Environment: All Reporter: Anita Kulshreshtha Assigned To: Anita Kulshreshtha Fix For: 1.2 Attachments: applications.patch, applications.patch, configs.log, configs.log, configs.log, configs.log, configs.patch, configs.patch, configs.patch, configs.patch, configs.patch, configs.patch, configs.patch, configs.patch, console-configs.patch, etc.patch, m2-plugins.patch, m2-plugins.patch, modules.patch, modules.patch, modules.patch, newconfigs.patch, pom.patch, pom.patch, pom.patch To build these configurations use packaging plugin GERONIMO-1740. This patch builds non openejb and non jetty configurations. This patch is for the new trunk, and has been edited using emcas to rempve ^M. -- 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: Maven2 Conversation Status
On 7/19/06, Jason Dillon [EMAIL PROTECTED] wrote: I do not plan on submitting a patch for RTC. I can produce a rather nasty diff of the trees for review if that is what the PMC wants, but IMO that would be a waste of time for them to review. Instead I suggest that the review be done by checking out the branch, building and then starting the Jetty assembly. What I expect is to check out the svkmerge/m2conversion branch and diff it against the trunk, then review the changes, apply them to my local trunk copy and give it a whirl. If it works, it will receive my +1. Anyone care to comment on it. Will it be enough to check it out? Have I already said I'm looking forward to giving it a shot? ;-) Jacek -- Jacek Laskowski http://www.laskowski.net.pl
Re: Maven2 Conversation Status
What I expect is to check out the svkmerge/m2conversion branch and diff it against the trunk, then review the changes, apply them to my local trunk copy and give it a whirl. If it works, it will receive my +1. Good luck ;-) I would encourage you (and others) to try the build from the branch first. If you feel the need to diff that is fine, though we will probably be merging this change back, not patching. Anyone care to comment on it. Will it be enough to check it out? Have I already said I'm looking forward to giving it a shot? ;-) Good :-) --jason
[jira] Updated: (GERONIMO-2206) examples configs [jsp-examples, servlets-examples]
[ http://issues.apache.org/jira/browse/GERONIMO-2206?page=all ]
Jason Dillon updated GERONIMO-2206:
---
Description:
patch enables the following configs
- jsp-examples-jetty
- jsp-examples-tomcat
- servlet-examples-tomcat
It also puts geronimoPlugin config option to the car-maven-plugin of console
configs.
servlets-examples-jetty config gives me the following error:
{noformat}
[INFO] Could not load servlet class
compressionFilters.CompressionFilterTestServlet
compressionFilters.CompressionFilterTestServlet in classloader
org.apache.geronimo.configs/servlet-examples-jetty/1.2-SNAPSHOT/car
{noformat}
was:
patch enables the following configs
- jsp-examples-jetty
- jsp-examples-tomcat
- servlet-examples-tomcat
It also puts geronimoPlugin config option to the car-maven-plugin of console
configs.
servlets-examples-jetty config gives me the following error.
[INFO] Could not load servlet class
compressionFilters.CompressionFilterTestServlet
compressionFilters.CompressionFilterTestServlet in classloader
org.apache.geronimo.configs/servlet-examples-jetty/1.2-SNAPSHOT/car
examples configs [jsp-examples, servlets-examples]
--
Key: GERONIMO-2206
URL: http://issues.apache.org/jira/browse/GERONIMO-2206
Project: Geronimo
Issue Type: Sub-task
Security Level: public(Regular issues)
Components: buildsystem
Affects Versions: 1.2
Reporter: Prasad Kashyap
Assigned To: Jason Dillon
Fix For: 1.2
Attachments: examples-configs.patch
patch enables the following configs
- jsp-examples-jetty
- jsp-examples-tomcat
- servlet-examples-tomcat
It also puts geronimoPlugin config option to the car-maven-plugin of
console configs.
servlets-examples-jetty config gives me the following error:
{noformat}
[INFO] Could not load servlet class
compressionFilters.CompressionFilterTestServlet
compressionFilters.CompressionFilterTestServlet in classloader
org.apache.geronimo.configs/servlet-examples-jetty/1.2-SNAPSHOT/car
{noformat}
--
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
Where the heck does this come from?
snip log4j: Parsing for [root] with value=[WARN, LOGFILE]. log4j: Level token is [WARN]. log4j: Category root set to WARN log4j: Parsing appender named LOGFILE. log4j: Parsing layout options for LOGFILE. log4j: Setting property [dateFormat] to [ISO8601]. log4j: Setting property [contextPrinting] to [true]. log4j: End of parsing for LOGFILE. log4j: Setting property [maxBackupIndex] to [3]. log4j: Setting property [maxFileSize] to [10MB]. log4j: Setting property [file] to [scout.log]. log4j: setFile called: scout.log, true log4j: setFile ended log4j: Parsed LOGFILE options. log4j: Parsing for [org.apache.axis.enterprise] with value=[FATAL, CONSOLE]. log4j: Level token is [FATAL]. log4j: Category org.apache.axis.enterprise set to FATAL log4j: Parsing appender named CONSOLE. log4j: Parsing layout options for CONSOLE. log4j: Setting property [conversionPattern] to [- %m%n]. log4j: End of parsing for CONSOLE. log4j: Setting property [threshold] to [INFO]. log4j: Parsed CONSOLE options. log4j: Handling log4j.additivity.org.apache.axis.enterprise=[null] log4j: Finished configuring. /snip --jason
Re: Maven2 Conversation Status
On 7/20/06, Jason Dillon [EMAIL PROTECTED] wrote: I would encourage you (and others) to try the build from the branch first. If you feel the need to diff that is fine, though we will probably be merging this change back, not patching. That's exactly what I had in mind, I believe. I'm going to merge the changes rather than creating a patch off svkmerge/m2migration and apply it to my local trunk copy. I don't see any other way to manage it. Is this what you had in mind? Jacek -- Jacek Laskowski http://www.laskowski.net.pl
Re: Maven2 Conversation Status
On Jul 19, 2006, at 3:18 PM, Jacek Laskowski wrote: On 7/20/06, Jason Dillon [EMAIL PROTECTED] wrote: I would encourage you (and others) to try the build from the branch first. If you feel the need to diff that is fine, though we will probably be merging this change back, not patching. That's exactly what I had in mind, I believe. I'm going to merge the changes rather than creating a patch off svkmerge/m2migration and apply it to my local trunk copy. I don't see any other way to manage it. Is this what you had in mind? Yup. Diff would only be for reference. --jason
[jira] Commented: (AMQ-794) make the support of advisory messages optional (so that they can be disabled to reduce RAM and boost performance a little)
[ https://issues.apache.org/activemq/browse/AMQ-794?page=comments#action_36595 ] Brian Madigan commented on AMQ-794: --- I tried this in the broker config and by defaulting advisorySupport to false in BrokerService. I hard coded isAdvisorySupport( ) to return false... Should these still be created?: 2006-07-19 17:22:09,179 [localhost:61616] INFO TransportConnection - Created new TransportConnection. Broker:a01 2006-07-19 17:22:09,201 [127.0.0.1:39964] INFO ActiveMQDestination - Creating destination: topic://ActiveMQ.Advisory.TempQueue 2006-07-19 17:22:09,201 [127.0.0.1:39964] INFO ActiveMQDestination - Creating destination: topic://ActiveMQ.Advisory.TempTopic 2006-07-19 17:22:09,201 [127.0.0.1:39964] INFO RegionBroker - Adding consumer for destination: topic://ActiveMQ.Advisory.TempQueue,topic://ActiveMQ.Advisory.TempTopic 2006-07-19 17:22:09,201 [127.0.0.1:39964] INFO AbstractRegion - Adding consumer: ID:photon.duncllc.com-39963-1153347728978-1:0:-1:1 2006-07-19 17:22:09,204 [127.0.0.1:39964] INFO AbstractRegion - Adding subscription to destination:Topic: destination=topic://ActiveMQ.Advisory.TempQueue,topic://ActiveMQ.Advisory.TempTopic, subscriptions=0 make the support of advisory messages optional (so that they can be disabled to reduce RAM and boost performance a little) -- Key: AMQ-794 URL: https://issues.apache.org/activemq/browse/AMQ-794 Project: ActiveMQ Issue Type: Improvement Reporter: james strachan Assigned To: james strachan Fix For: 4.1 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (GERONIMO-2206) examples configs [jsp-examples, servlets-examples]
[
http://issues.apache.org/jira/browse/GERONIMO-2206?page=comments#action_12422279
]
Jason Dillon commented on GERONIMO-2206:
I need to know where
{{geronimo-samples:geronimo-jsp-examples-tomcat:war:5.5.15}} comes from before
I can apply... or test.
examples configs [jsp-examples, servlets-examples]
--
Key: GERONIMO-2206
URL: http://issues.apache.org/jira/browse/GERONIMO-2206
Project: Geronimo
Issue Type: Sub-task
Security Level: public(Regular issues)
Components: buildsystem
Affects Versions: 1.2
Reporter: Prasad Kashyap
Assigned To: Jason Dillon
Fix For: 1.2
Attachments: examples-configs.patch
patch enables the following configs
- jsp-examples-jetty
- jsp-examples-tomcat
- servlet-examples-tomcat
It also puts geronimoPlugin config option to the car-maven-plugin of
console configs.
servlets-examples-jetty config gives me the following error:
{noformat}
[INFO] Could not load servlet class
compressionFilters.CompressionFilterTestServlet
compressionFilters.CompressionFilterTestServlet in classloader
org.apache.geronimo.configs/servlet-examples-jetty/1.2-SNAPSHOT/car
{noformat}
--
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-2206) examples configs [jsp-examples, servlets-examples]
[
http://issues.apache.org/jira/browse/GERONIMO-2206?page=comments#action_12422282
]
Jason Dillon commented on GERONIMO-2206:
NM, I found it here:
* http://people.apache.org/repo/m1-snapshot-repository/geronimo-samples/
Was having more remote repo access issues (again).
Where does this originate from though? Why is it only in the m1 snapshot repo?
examples configs [jsp-examples, servlets-examples]
--
Key: GERONIMO-2206
URL: http://issues.apache.org/jira/browse/GERONIMO-2206
Project: Geronimo
Issue Type: Sub-task
Security Level: public(Regular issues)
Components: buildsystem
Affects Versions: 1.2
Reporter: Prasad Kashyap
Assigned To: Jason Dillon
Fix For: 1.2
Attachments: examples-configs.patch
patch enables the following configs
- jsp-examples-jetty
- jsp-examples-tomcat
- servlet-examples-tomcat
It also puts geronimoPlugin config option to the car-maven-plugin of
console configs.
servlets-examples-jetty config gives me the following error:
{noformat}
[INFO] Could not load servlet class
compressionFilters.CompressionFilterTestServlet
compressionFilters.CompressionFilterTestServlet in classloader
org.apache.geronimo.configs/servlet-examples-jetty/1.2-SNAPSHOT/car
{noformat}
--
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-2206) examples configs [jsp-examples, servlets-examples]
[
http://issues.apache.org/jira/browse/GERONIMO-2206?page=comments#action_12422284
]
Jason Dillon commented on GERONIMO-2206:
When I try to install the plugin from the webconsole it barfs with:
{noformat}
javax.servlet.ServletException: Unable to install sample application
org.apache.geronimo.welcome.AbsentSampleServlet.doInstall(AbsentSampleServlet.java:75)
org.apache.geronimo.welcome.AbsentSampleServlet.doGet(AbsentSampleServlet.java:52)
javax.servlet.http.HttpServlet.service(HttpServlet.java:595)
javax.servlet.http.HttpServlet.service(HttpServlet.java:688)
root cause
java.lang.ClassCastException
org.apache.geronimo.kernel.config.SerializedConfigurationMarshaler.readConfigurationData(SerializedConfigurationMarshaler.java:57)
org.apache.geronimo.kernel.config.ConfigurationUtil.readConfigurationData(ConfigurationUtil.java:167)
org.apache.geronimo.system.configuration.RepositoryConfigurationStore.loadConfiguration(RepositoryConfigurationStore.java:113)
org.apache.geronimo.system.configuration.RepositoryConfigurationStore$$FastClassByCGLIB$$968bf00c.invoke(generated)
net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53)
org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38)
org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:122)
org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:817)
org.apache.geronimo.gbean.runtime.RawInvoker.invoke(RawInvoker.java:57)
org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke(RawOperationInvoker.java:35)
org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept(ProxyMethodInterceptor.java:96)
org.apache.geronimo.kernel.config.ConfigurationStore$$EnhancerByCGLIB$$a74830af.loadConfiguration(generated)
org.apache.geronimo.system.plugin.PluginInstallerGBean.downloadArtifact(PluginInstallerGBean.java:738)
org.apache.geronimo.system.plugin.PluginInstallerGBean.install(PluginInstallerGBean.java:454)
org.apache.geronimo.system.plugin.PluginInstallerGBean.install(PluginInstallerGBean.java:383)
org.apache.geronimo.system.plugin.PluginInstallerGBean$$FastClassByCGLIB$$cebc327e.invoke(generated)
net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53)
org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38)
org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:122)
org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:817)
org.apache.geronimo.gbean.runtime.RawInvoker.invoke(RawInvoker.java:57)
org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke(RawOperationInvoker.java:35)
org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept(ProxyMethodInterceptor.java:96)
org.apache.geronimo.system.plugin.PluginInstaller$$EnhancerByCGLIB$$75adb43a.install(generated)
org.apache.geronimo.welcome.AbsentSampleServlet.doInstall(AbsentSampleServlet.java:72)
org.apache.geronimo.welcome.AbsentSampleServlet.doGet(AbsentSampleServlet.java:52)
javax.servlet.http.HttpServlet.service(HttpServlet.java:595)
javax.servlet.http.HttpServlet.service(HttpServlet.java:688)
{noformat}
examples configs [jsp-examples, servlets-examples]
--
Key: GERONIMO-2206
URL: http://issues.apache.org/jira/browse/GERONIMO-2206
Project: Geronimo
Issue Type: Sub-task
Security Level: public(Regular issues)
Components: buildsystem
Affects Versions: 1.2
Reporter: Prasad Kashyap
Assigned To: Jason Dillon
Fix For: 1.2
Attachments: examples-configs.patch
patch enables the following configs
- jsp-examples-jetty
- jsp-examples-tomcat
- servlet-examples-tomcat
It also puts geronimoPlugin config option to the car-maven-plugin of
console configs.
servlets-examples-jetty config gives me the following error:
{noformat}
[INFO] Could not load servlet class
compressionFilters.CompressionFilterTestServlet
compressionFilters.CompressionFilterTestServlet in classloader
org.apache.geronimo.configs/servlet-examples-jetty/1.2-SNAPSHOT/car
{noformat}
--
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: Does each module really need LICENSE.txt and NOTICE.txt?
Matt Hogstrom wrote: I am referring to the modules. What I meant was if we have 25 modules and everyone has its own license and notices file I'm pretty confident they'll get out of sync. It would be nice to have a central place to pull the content from which should be modules/scripts/resources/* What I meant by the notices being an issue is that a single notices file identifies what additional licenses are in a module. So, it may or may not make sense for the Kernel module to have a Bouncycastle NOTICE. It looks like the majority of licenses use terminology similar to Redistribution and use in source and binary forms... In terms of redistribution, we don't redistribute third-party libraries (we only redistribute them in assemblies) as part of module jars, but they may use a third-party library directly or indirectly via transitive dependencies. I'm not sure if the use terminology in the licenses applies to indirect use, but it might be safer to err on the side of caution and include all licenses that may be in use both directly in the module and indirectly. If its ok to havbe a complete NOTICES file that includes licenses that are not in a module then that would be fine. It would be nice to say, Geronimo-Kernel may include one or more of the following elements. If we have to be precise on a module by module basis then I think that will be a problem. This sounds like an opportunity for maven to solve in the future (e.g. collating license information) but I don't think it has been thought out enough yet.. http://jira.codehaus.org/browse/MJAR-10?rc=1 Agree it would be a problem if for each module we had to work out what licenses were used via transitive dependencies. If it is only the licenses for direct dependencies that we need to include then that could be manageable. We would need a process in place so that if anyone modifies the dependencies of a module they need to review the licensing implications (e.g. does the new version of the dependency have a new license) and make the appropriate changes to the module's LICENSE.txt and NOTICE.txt files. John Kevan Miller wrote: On Jul 17, 2006, at 1:06 PM, Matt Hogstrom wrote: Well, I think adding the files to every module is potentially a problem. I think the release should have a central place all modules derive their LICENSE file from. The NOTICIES file is a different animal. Matt, What modules are you referring to? All of our generated jar files (.e.g geronimo-kernel-1.1.jar) should contain LICENSE and NOTICE files. Hrrm, I just looked at two 1.1 jars and they only contain LICENSE files. We also need a LICENSE and NOTICE file at the base of our distributions. These should contain all necessary license and notice information for all of the Geronimo code built and included in our distribution. The license and notice file also need to contain license and notice information for all jar files, or other artifacts, that we include in our distribution (e.g. asm jar, castor jar, etc...). Or, are you instead referring to modules as in CAR's? If so, then they are a different animal. However, I don't think we're released from any licensing requirements. Given the guidelines in http://www.apache.org/dev/release.html#what-must-every-release-contain (see the Can I distribute a raw artifact? section at the bottom), I think that any downloadable artifact (distribution, car, jar, war, ear, etc) that we release to ibiblio should have appropriate license and notice files (alternatively, we stop releasing the artifact). --kevan Jason Dillon wrote: If we want to keep these guys in the jars, then we should move them to their standard src/main/resources/META-INF/* locations so that they get picked up automatically. --jason On Jul 16, 2006, at 5:27 PM, John Sisson wrote: Jason Dillon wrote: Um... when were these ever included in the module's jars before? --jason On Jul 16, 2006, at 5:04 PM, John Sisson wrote: Jason Dillon wrote: Does each module really need LICENSE.txt and NOTICE.txt? Or can we just have this at the top-level of the project? I'd rather have less duplicate files to maintain... Any comments? --jason I think they are needed as each downloadable jar (which each module has) should contain the license and notice files. Same with source archives, which AFAIK maven can produce for each individual module for use by IDE debuggers etc. John I just checked and if you look at geronimo-activation-1.1.jar it should contain META-INF\LICENSE.TXT . It is a problem that the NOTICE.txt file isn't also included. We should add a JIRA for the 1.1.1 release for that. John
[jira] Commented: (GERONIMO-2206) examples configs [jsp-examples, servlets-examples]
[
http://issues.apache.org/jira/browse/GERONIMO-2206?page=comments#action_12422289
]
Jason Dillon commented on GERONIMO-2206:
I also see these in geronimo.out, which has the wrong groupIds:
{noformat}
# Installed configuration
# id = geronimo/servlets-examples-tomcat/1.0/car
# location =
/Users/jason/ws/apache/geronimo/svkmerge/m2migration/m2-assemblies/geronimo-tomcat-j2ee/geronimo-tomcat-j2ee-1.2-SNAPSHOT/repository/geronimo/servlets-examples-tomcat/1.0/servlets-examples-tomcat-1.0.car
# Installed configuration
# id = geronimo/jsp-examples-tomcat/1.0/car
# location =
/Users/jason/ws/apache/geronimo/svkmerge/m2migration/m2-assemblies/geronimo-tomcat-j2ee/geronimo-tomcat-j2ee-1.2-SNAPSHOT/repository/geronimo/jsp-examples-tomcat/1.0/jsp-examples-tomcat-1.0.car
{nofromat}
examples configs [jsp-examples, servlets-examples]
--
Key: GERONIMO-2206
URL: http://issues.apache.org/jira/browse/GERONIMO-2206
Project: Geronimo
Issue Type: Sub-task
Security Level: public(Regular issues)
Components: buildsystem
Affects Versions: 1.2
Reporter: Prasad Kashyap
Assigned To: Jason Dillon
Fix For: 1.2
Attachments: examples-configs.patch
patch enables the following configs
- jsp-examples-jetty
- jsp-examples-tomcat
- servlet-examples-tomcat
It also puts geronimoPlugin config option to the car-maven-plugin of
console configs.
servlets-examples-jetty config gives me the following error:
{noformat}
[INFO] Could not load servlet class
compressionFilters.CompressionFilterTestServlet
compressionFilters.CompressionFilterTestServlet in classloader
org.apache.geronimo.configs/servlet-examples-jetty/1.2-SNAPSHOT/car
{noformat}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Where the heck does this come from?
I noticed the scout.log entry below. I looked in geronimo-1.1\repository\scout\scout\0.5\scout-0.5.jar in the log4j.properties file and it has log4j.debug uncommented! I think that is the culprit. May want to send a mail to the scout project http://ws.apache.org/scout/ John Jason Dillon wrote: snip log4j: Parsing for [root] with value=[WARN, LOGFILE]. log4j: Level token is [WARN]. log4j: Category root set to WARN log4j: Parsing appender named LOGFILE. log4j: Parsing layout options for LOGFILE. log4j: Setting property [dateFormat] to [ISO8601]. log4j: Setting property [contextPrinting] to [true]. log4j: End of parsing for LOGFILE. log4j: Setting property [maxBackupIndex] to [3]. log4j: Setting property [maxFileSize] to [10MB]. log4j: Setting property [file] to [scout.log]. log4j: setFile called: scout.log, true log4j: setFile ended log4j: Parsed LOGFILE options. log4j: Parsing for [org.apache.axis.enterprise] with value=[FATAL, CONSOLE]. log4j: Level token is [FATAL]. log4j: Category org.apache.axis.enterprise set to FATAL log4j: Parsing appender named CONSOLE. log4j: Parsing layout options for CONSOLE. log4j: Setting property [conversionPattern] to [- %m%n]. log4j: End of parsing for CONSOLE. log4j: Setting property [threshold] to [INFO]. log4j: Parsed CONSOLE options. log4j: Handling log4j.additivity.org.apache.axis.enterprise=[null] log4j: Finished configuring. /snip --jason
Re: Where the heck does this come from?
Hrm... wonder what other jars have their own logging configs... I mailed their list... though we might want to implement some build fluff to strip these unwanted files out of jars. --jason On Jul 19, 2006, at 4:34 PM, John Sisson wrote: I noticed the scout.log entry below. I looked in geronimo-1.1 \repository\scout\scout\0.5\scout-0.5.jar in the log4j.properties file and it has log4j.debug uncommented! I think that is the culprit. May want to send a mail to the scout project http://ws.apache.org/scout/ John Jason Dillon wrote: snip log4j: Parsing for [root] with value=[WARN, LOGFILE]. log4j: Level token is [WARN]. log4j: Category root set to WARN log4j: Parsing appender named LOGFILE. log4j: Parsing layout options for LOGFILE. log4j: Setting property [dateFormat] to [ISO8601]. log4j: Setting property [contextPrinting] to [true]. log4j: End of parsing for LOGFILE. log4j: Setting property [maxBackupIndex] to [3]. log4j: Setting property [maxFileSize] to [10MB]. log4j: Setting property [file] to [scout.log]. log4j: setFile called: scout.log, true log4j: setFile ended log4j: Parsed LOGFILE options. log4j: Parsing for [org.apache.axis.enterprise] with value=[FATAL, CONSOLE]. log4j: Level token is [FATAL]. log4j: Category org.apache.axis.enterprise set to FATAL log4j: Parsing appender named CONSOLE. log4j: Parsing layout options for CONSOLE. log4j: Setting property [conversionPattern] to [- %m%n]. log4j: End of parsing for CONSOLE. log4j: Setting property [threshold] to [INFO]. log4j: Parsed CONSOLE options. log4j: Handling log4j.additivity.org.apache.axis.enterprise=[null] log4j: Finished configuring. /snip --jason
Re: More to be added to licenses file for 1.1.1 ?
Sorry for the slow response.. comments inline. Kevan Miller wrote: On Jul 18, 2006, at 6:43 PM, Alan D. Cabrera wrote: Kevan Miller wrote: On Jul 18, 2006, at 8:53 AM, John Sisson wrote: Whilst testing the geronimo eclipse plugin, eclipse prompted me to acknowledge the Sun license at http://developers.sun.com/license/berkeley_license.html when caching the j2ee schema files (e.g. http://java.sun.com/xml/ns/j2ee/ejb-jar_2_1.xsd ). This made me wonder whether this license has been included for Geronimo (since we redistribute schema files) and it appears the LICENSE.txt file in 1.1 doesn't contain it. I'll add a JIRA for 1.1.1 if there aren't any objections. Can anyone think of any other licenses or notices we may have overlooked? Yes. Would appreciate your thoughts on the following: 1) Fix LICENSE and NOTICE files for branches/1.1/modules/util (currently they are only Bouncy Castle -- I believe that we have ASL code in there, also). I think we should do it Agree. 2) Do we need to add Bouncy Castle to our global LICENSE and NOTICE files (i.e. branches/1.1/modules/scripts/src/resources/) ? I think yes. Agree. 3) Insure NOTICE files are included in our jar files (currently only LICENSE files are there) Agree. 4) Do we need to add LICENSE/NOTICE files in our generated CARs? Any artifact we publish should have a LICENSE/NOTICE file in it. 5) Can the global LICENSE and NOTICE files be used in all our generated artifacts (distributions, jars, cars)? Or do we need global files and specific license/notice files for generated module jars and car files? --kevan 2-4 should be run by legal, no? I think we should aim to have LICENSE and NOTICE files specific to each jar. What I am not sure of is what licenses need to be included. See my related post http://marc.theaimsgroup.com/?l=geronimo-devm=115335093425013w=2 To support #5, I hope we don't need some kind of maven magic. I think 1,2,3 are must do's. I think we can ignore 4. There are some CAR files in ibiblio -- http://www.ibiblio.org/maven/geronimo/cars/ However, I'm not sure why they are there... They are all 1.0 and dated December 22nd. Should we have them removed? To my knowledge, we don't build or distribute CAR files in 1.1 (we do have .car directories in our repository, but IMO that's no different from any other directory name we might have...) Regarding 5, I think the right thing to do is have a global LICENSE and NOTICE file in the base of our distributions. We currently have this. Each of our jar files should have LICENSE and NOTICE files specific to each jar. I don't think that this is hard to do. Am I wrong? They all need standard ASL license and notice files. util needs to include bouncy castle info. Are there other geronimo generated jars with any licensing requirements beyond ASL 2? I think many modules would need to include licenses for third party libraries as their licenses say use of. I also discussed this in the related post link above. We may need to ask legal about this. John --kevan
Random failures w/new apache repos
Is anyone else seeing random failures due to problems downloading artifacts from the new locations of the Apache repos? --jason
[jira] Resolved: (GERONIMO-1738) Plugin migration to Maven 2: geronimo-deployment-plugin
[ http://issues.apache.org/jira/browse/GERONIMO-1738?page=all ] Prasad Kashyap resolved GERONIMO-1738. -- Fix Version/s: 1.2 Resolution: Fixed Let's mark this fixed. The patch has gone into the sandbox/svkmerge/m2migration. The whole branch will be up for RTC review anyway. Plugin migration to Maven 2: geronimo-deployment-plugin --- Key: GERONIMO-1738 URL: http://issues.apache.org/jira/browse/GERONIMO-1738 Project: Geronimo Issue Type: Sub-task Security Level: public(Regular issues) Components: buildsystem Affects Versions: 1.x Reporter: Jacek Laskowski Assigned To: Prasad Kashyap Fix For: 1.2 Attachments: geronimo-deployment-plugin-RTC-VOTE.2.patch, geronimo-deployment-plugin-RTC-VOTE.3.patch, geronimo-deployment-plugin.patch It's a task to keep track of the progress of the plugin build migration to Maven2 -- 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-1737) geronimo-assembly-plugin + Jetty J2EE Assembly
[ http://issues.apache.org/jira/browse/GERONIMO-1737?page=all ] Prasad Kashyap updated GERONIMO-1737: - Summary: geronimo-assembly-plugin + Jetty J2EE Assembly (was: Plugin migration to Maven 2: geronimo-assembly-plugin) geronimo-assembly-plugin + Jetty J2EE Assembly -- Key: GERONIMO-1737 URL: http://issues.apache.org/jira/browse/GERONIMO-1737 Project: Geronimo Issue Type: Sub-task Security Level: public(Regular issues) Components: buildsystem Affects Versions: 1.x Reporter: Jacek Laskowski Assigned To: Prasad Kashyap Attachments: geronimo-assembly-plugin.patch, m2-jetty-server.patch, maven-assembly-plugin.patch It's a task to keep track of the progress of the plugin build migration to Maven2 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (GERONIMO-1737) geronimo-assembly-plugin + Jetty J2EE Assembly
[ http://issues.apache.org/jira/browse/GERONIMO-1737?page=all ] Prasad Kashyap resolved GERONIMO-1737. -- Fix Version/s: 1.2 Resolution: Fixed This JIRA introduces a new geronimo-assembly-plugin for M2 and migrates the Jetty J2EE assembly to build a binary distro in M2. Separate JIRAs will be opened for Tomcat J2EE and other minimal assemblies. geronimo-assembly-plugin + Jetty J2EE Assembly -- Key: GERONIMO-1737 URL: http://issues.apache.org/jira/browse/GERONIMO-1737 Project: Geronimo Issue Type: Sub-task Security Level: public(Regular issues) Components: buildsystem Affects Versions: 1.x Reporter: Jacek Laskowski Assigned To: Prasad Kashyap Fix For: 1.2 Attachments: geronimo-assembly-plugin.patch, m2-jetty-server.patch, maven-assembly-plugin.patch It's a task to keep track of the progress of the plugin build migration to Maven2 -- 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-2206) examples configs [jsp-examples, servlets-examples]
[
http://issues.apache.org/jira/browse/GERONIMO-2206?page=comments#action_12422312
]
Jason Dillon commented on GERONIMO-2206:
Applied (#423692) please post patch for fix for jetty servlets when you can.
examples configs [jsp-examples, servlets-examples]
--
Key: GERONIMO-2206
URL: http://issues.apache.org/jira/browse/GERONIMO-2206
Project: Geronimo
Issue Type: Sub-task
Security Level: public(Regular issues)
Components: buildsystem
Affects Versions: 1.2
Reporter: Prasad Kashyap
Assigned To: Jason Dillon
Fix For: 1.2
Attachments: examples-configs.patch
patch enables the following configs
- jsp-examples-jetty
- jsp-examples-tomcat
- servlet-examples-tomcat
It also puts geronimoPlugin config option to the car-maven-plugin of
console configs.
servlets-examples-jetty config gives me the following error:
{noformat}
[INFO] Could not load servlet class
compressionFilters.CompressionFilterTestServlet
compressionFilters.CompressionFilterTestServlet in classloader
org.apache.geronimo.configs/servlet-examples-jetty/1.2-SNAPSHOT/car
{noformat}
--
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: More to be added to licenses file for 1.1.1 ?
On Jul 19, 2006, at 2:12 AM, Jason Dillon wrote: Technically... its bad for a module to need to access bits from ../ (or ../../ or ../../../../../../). The proper way to do this would be to add them to a new license module, then have each module depend on it, using dependency plugin to download unpack and then antrun to copy into place. Still easier to have LICENSE.txt and NOTICE.txt local to the module. Most of them will be the same, so not much work to maintain... a few will need to be customized to keep us legal. If we want to have a global... then we gotta write up some custom plugin to handle that automatically for us. I'd be proposing that the LICENSE and NOTICE files be local to the module. That's what we currently have. The distribution license and notice files are in modules/scripts/ src/resources. They are currently built by hand. I'm assuming that they will continue to be built by hand. Automatically generating the license/module information would be great (I'm just a little doubtful that it's going to happen...) You have to include license/notice info for all of our generated modules -- that seems doable. However, the harder part is compiling license/notice information for dependencies that are loaded into our repository. We'd need to capture that information as meta-data, then accumulate during the assembly. We need to be more rigorous in maintaining our LICENSE and NOTICE information. IMO, identifying and compiling the information is the hard part, not getting them into the necessary format... --kevan --jason On Jul 18, 2006, at 8:04 PM, Kevan Miller wrote: On Jul 18, 2006, at 6:43 PM, Alan D. Cabrera wrote: Kevan Miller wrote: On Jul 18, 2006, at 8:53 AM, John Sisson wrote: Whilst testing the geronimo eclipse plugin, eclipse prompted me to acknowledge the Sun license at http://developers.sun.com/ license/berkeley_license.html when caching the j2ee schema files (e.g. http://java.sun.com/xml/ns/j2ee/ejb-jar_2_1.xsd ). This made me wonder whether this license has been included for Geronimo (since we redistribute schema files) and it appears the LICENSE.txt file in 1.1 doesn't contain it. I'll add a JIRA for 1.1.1 if there aren't any objections. Can anyone think of any other licenses or notices we may have overlooked? Yes. Would appreciate your thoughts on the following: 1) Fix LICENSE and NOTICE files for branches/1.1/modules/util (currently they are only Bouncy Castle -- I believe that we have ASL code in there, also). I think we should do it 2) Do we need to add Bouncy Castle to our global LICENSE and NOTICE files (i.e. branches/1.1/modules/scripts/src/ resources/) ? I think yes. 3) Insure NOTICE files are included in our jar files (currently only LICENSE files are there) 4) Do we need to add LICENSE/NOTICE files in our generated CARs? 5) Can the global LICENSE and NOTICE files be used in all our generated artifacts (distributions, jars, cars)? Or do we need global files and specific license/notice files for generated module jars and car files? --kevan 2-4 should be run by legal, no? To support #5, I hope we don't need some kind of maven magic. I think 1,2,3 are must do's. I think we can ignore 4. There are some CAR files in ibiblio -- http://www.ibiblio.org/maven/ geronimo/cars/ However, I'm not sure why they are there... They are all 1.0 and dated December 22nd. Should we have them removed? To my knowledge, we don't build or distribute CAR files in 1.1 (we do have .car directories in our repository, but IMO that's no different from any other directory name we might have...) Regarding 5, I think the right thing to do is have a global LICENSE and NOTICE file in the base of our distributions. We currently have this. Each of our jar files should have LICENSE and NOTICE files specific to each jar. I don't think that this is hard to do. Am I wrong? They all need standard ASL license and notice files. util needs to include bouncy castle info. Are there other geronimo generated jars with any licensing requirements beyond ASL 2? --kevan
Re: GroupId for DayTrader needed.
Hey, I used to have a TRS-80. 32k of RAM...yup, those were the good 'ol days. I agree that shortening the DT artifacts is only moving the bubble around. The fact is that for all of its issues there are a lot more Windows users out there than the *nix OS's. One area to improve things is to eliminate this redundancy: daytrader-derby-tomcat_streamer.jar\1.2-SNAPSHOT\daytrader-derby-tomcat_streamer.jar-1.2-SNAPSHOT.car At a minimum we burn up 47 characters with daytrader-derby-tomcat_streamer.jar\1.2-SNAPSHOT where the actual artifact name contains exactly the same information for the most part. I'm not sure what the right solution is here but if we had a creative way to remove the first part we'd get some serious relief. Is the reason we have this so we can use the Maven component directly? If we decided to modify our repository code to do some introspection would that help? Dain, I know you wrote most of the code with David, what are your thoughts on this? Jason Dillon wrote: I think that in general... the m2 repository using the m2 style of artifactId and groupId names is not compatible with Windows. Short of changing the way m2 works or altering the m2 naming standard, I do not see any simple way around this problem. And we are getting hit by this in two places too... building the server, and then again when running the server. I think we need to find a real solution to this issue and not just truncate the names to get around problem... until it pops up again... which is will. And as much as I would love to just give all windows users the shaft and force them to snap out of their microsoft induced blue screen of death, reboot every day, annoying dancing paper clip, stupid file locking, file names can't be longer than 256 insanity... and I would really love to do that... we can't :-( Lucky we don't have to support TRS-80, CPM or Altair users... --jason On Jul 19, 2006, at 7:38 AM, anita kulshreshtha wrote: Jeff, We also need to shorten the artifactId. It makes a good puzzle - Come up with sensible groupId and artifactId such that this does not exceed 256! Example 2 - D:\geronimo-1.2\configs\daytrader-tomcat\target\reposito ry\org\apache\geronimo\configs\daytrader-derby-tomcat_streamer.jar\1.2-SNAPSHOT\daytrader-derby-tomc at_streamer.jar-1.2-SNAPSHOT.car\org.apache.geronimo.modules\ge-activemq-rar\1.2-SNAPSHOT\rar\ activemq-3.2.4-SNAPSHOT.jar This example is taken from http://www.nabble.com/M2-%3A-build-on-Windows-p4914787.html is 256+30 long! Cheers Anita --- Jeff Genender [EMAIL PROTECTED] wrote: I am a big fan of org.apache.geronimo.samples.daytrader. But...are we leading ourselves down the path of a Windows dir size too big nightmare? Jeff Jason Dillon wrote: Why not give it is own: org.apache.geronimo.daytrader --jason On Jul 18, 2006, at 11:59 AM, Prasad Kashyap wrote: The DayTrader project needs a consistent groupId for all it's artifacts. Currently, some of it's artifacts are under the geronimo groupid while others are under the org.apache.geronimo groupid. I discussed this with Matt and we decided to pose this Q to the community. One option is to have a groupId called org.apache.geronimo.samples which will be home to daytrader artifacts, other samples we currently have and ones to come. One other thing to consider is the very long artifactId name of some of daytrader's artifacts. An example is something like daytrader-derby-jetty-streamer. When this is coupled with an equally long groupId name, we'll be close to hitting the path limit on windows. Cheers Prasad __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
[jira] Commented: (GERONIMO-2204) ProxyMethodInterceptor doesn't handle finalize appropriately
[
http://issues.apache.org/jira/browse/GERONIMO-2204?page=comments#action_12422323
]
Matt Hogstrom commented on GERONIMO-2204:
-
I think its worth fixing given that it pops up frequently and doesn't help
developers.
Serializable Noop sounds workable.
ProxyMethodInterceptor doesn't handle finalize appropriately
Key: GERONIMO-2204
URL: http://issues.apache.org/jira/browse/GERONIMO-2204
Project: Geronimo
Issue Type: Bug
Security Level: public(Regular issues)
Components: kernel
Affects Versions: 1.1
Reporter: David Jencks
Assigned To: Dain Sundstrom
Priority: Minor
A user noticed that while debugging in eclipse (or idea with
break-on-exceptions turned on) this method from ProxyMethodInterceptor throws
UnsupportedOperationException when finalize is called on a proxy object:
public final Object intercept(final Object object, final Method method,
final Object[] args, final MethodProxy proxy) throws Throwable {
ProxyInvoker gbeanInvoker;
int interfaceIndex = proxy.getSuperIndex();
synchronized (this) {
if (gbeanInvokers == null) {
throw new DeadProxyException(Proxy is no longer valid);
}
gbeanInvoker = gbeanInvokers[interfaceIndex];
}
if (gbeanInvoker == null) {
throw new UnsupportedOperationException(No implementation
method: objectName= + abstractName + , method= + method);
}
return gbeanInvoker.invoke(abstractName, args);
}
This appears to be harmless since the proxy doesn't implement finalize, but
annoying. We could fix this by explicitly ignoring the finalize method in
the code above, possibly by installing a suitable FinalizeInvoker, or by
using a CallbackFilter with a Noop or SerizializableNoop callback (the
strategy used by spring aop).
Is this worth fixing? Which way would be best?
--
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-1582) NPE for EJB webservices.xml with bad jaxrpc-mapping-file
[ http://issues.apache.org/jira/browse/GERONIMO-1582?page=all ] Matt Hogstrom closed GERONIMO-1582. --- Sachin applied the patch: URL: https://svn.apache.org/repos/asf/geronimo/branches/1.1/modules/axis-builder/src/java/org/apache/geronimo/axis/builder/WSDescriptorParser.java Repository Root: https://svn.apache.org/repos/asf Repository UUID: 13f79535-47bb-0310-9956-ffa450edef68 Revision: 423590 Node Kind: file Schedule: normal Last Changed Author: sppatel Last Changed Rev: 423475 Last Changed Date: 2006-07-19 10:40:06 -0400 (Wed, 19 Jul 2006) Text Last Updated: 2006-07-19 22:25:47 -0400 (Wed, 19 Jul 2006) Properties Last Updated: 2006-07-19 16:34:21 -0400 (Wed, 19 Jul 2006) Checksum: 02c35ba1784f386d3f83d631a0f3925b NPE for EJB webservices.xml with bad jaxrpc-mapping-file -- Key: GERONIMO-1582 URL: http://issues.apache.org/jira/browse/GERONIMO-1582 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: OpenEJB, webservices Affects Versions: 1.1.x Reporter: Aaron Mulder Assigned To: Sachin Patel Priority: Critical Fix For: 1.1.1 Attachments: WSDescriptorParser.patch If the jaxrpc-mapping-file points to an invalid location, a NullPointerException is produced. It should instead give a DeploymentException with a message like: webservices.xml for EJB JAR points to jaxrpc-mapping-file 'META-INF/foo.map' for service 'bar' but that file is not found. 11:47:01,051 ERROR [Deployer] Deployment failed due to java.lang.NullPointerException at org.apache.geronimo.deployment.util.NestedJarFile.getInputStream(NestedJarFile.java:187) at org.apache.geronimo.axis.builder.WSDescriptorParser.readJaxrpcMapping(WSDescriptorParser.java:95) at org.apache.geronimo.axis.builder.WSDescriptorParser.readJaxrpcMapping(WSDescriptorParser.java:88) at org.apache.geronimo.axis.builder.WSDescriptorParser.parseWebServiceDescriptor(WSDescriptorParser.java:315) at org.apache.geronimo.axis.builder.WSDescriptorParser.parseWebServiceDescriptor(WSDescriptorParser.java:379) at org.apache.geronimo.axis.builder.AxisBuilder.parseWebServiceDescriptor(AxisBuilder.java:106) at org.apache.geronimo.axis.builder.AxisBuilder$$FastClassByCGLIB$$16a52a9a.invoke(generated) at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53) at org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38) at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:118) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:800) at org.apache.geronimo.gbean.runtime.RawInvoker.invoke(RawInvoker.java:57) at org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke(RawOperationInvoker.java:36) at org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept(ProxyMethodInterceptor.java:96) at org.apache.geronimo.j2ee.deployment.WebServiceBuilder$$EnhancerByCGLIB$$493cf3fa.parseWebServiceDescriptor(generated) at org.openejb.deployment.OpenEJBModuleBuilder.addGBeans(OpenEJBModuleBuilder.java:500) at org.openejb.deployment.OpenEJBModuleBuilder$$FastClassByCGLIB$$11bd7b20.invoke(generated) at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53) at org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38) at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:118) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:800) at org.apache.geronimo.gbean.runtime.RawInvoker.invoke(RawInvoker.java:57) at org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke(RawOperationInvoker.java:36) at org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept(ProxyMethodInterceptor.java:96) at org.apache.geronimo.j2ee.deployment.ModuleBuilder$$EnhancerByCGLIB$$4ca9e4d7.addGBeans(generated) at org.apache.geronimo.j2ee.deployment.EARConfigBuilder.buildConfiguration(EARConfigBuilder.java:402) at org.apache.geronimo.j2ee.deployment.EARConfigBuilder$$FastClassByCGLIB$$38e56ec6.invoke(generated) at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53) at org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38) at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:118) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:800) at org.apache.geronimo.gbean.runtime.RawInvoker.invoke(RawInvoker.java:57) at
Re: Virtual Topics (was Re: Failover topic subscribers)
On 7/19/06, bmadigan [EMAIL PROTECTED] wrote: Is this the change to call lookup(...) in addConsumer( )? Yes Looks like its not being called. Damn - sorry about that. I knew I should have taken the time to write a test case :). Lemme see if I get chance to write a little test case today I'd like to run the broker in debug, I'm having trouble figuring out where exactly the lazy creation of destinations is happening. It should be the lookup() which calls addDestination() I think. More in a little while... -- James --- http://radio.weblogs.com/0112098/
[jira] Created: (AMQ-834) use the clientID rather than connectionID for the name of subscriptionIDs in JMX
use the clientID rather than connectionID for the name of subscriptionIDs in JMX Key: AMQ-834 URL: https://issues.apache.org/activemq/browse/AMQ-834 Project: ActiveMQ Issue Type: Improvement Components: Broker Affects Versions: 4.0.1 Reporter: james strachan Fix For: 4.1 Folks can customize their clientIDs so it'd make more sense to make more use of those rather than the connectionID when displaying subscriptions in JMX (e.g. the current tree of subscriptions). -- 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: GroupId for DayTrader needed.
I agree that shortening the DT artifacts is only moving the bubble around. The fact is that for all of its issues there are a lot more Windows users out there than the *nix OS's. Part of me thinks it is my duty to bring down the evil giant maker of crappy software... for the common good of humanity. Windows is a virus and needs to be treated with some serious medicine... or burned to rid the world of its sickness. --jason
[jira] Created: (GERONIMO-2207) TransactionCachingInterceptor is returning the same ManagedConnection despite different ConnectionRequestInfo
TransactionCachingInterceptor is returning the same ManagedConnection despite different ConnectionRequestInfo - Key: GERONIMO-2207 URL: http://issues.apache.org/jira/browse/GERONIMO-2207 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Components: connector Affects Versions: 1.0 Environment: Tomcat, Spring, Jencks, Geronimo Connector, Geronimo Transaction Reporter: Jörg Heinicke (Thread at http://marc.theaimsgroup.com/?t=11532350151r=1w=4) In my use case the same javax.resource.cci.ConnectionFactory instance is asked twice for a connection with two different ConnectionSpec within one transaction. The symptom is that the TransactionCachingInterceptor returns the ManagedConnectionInfo of ManagedConnectionInfos.getShared() without any comparison of ConnectionRequestInfo, so I get a wrong ManagedConnection and a wrong Connection handle at the end. David Jencks gave me the hint that I have to set my connections to unshareable. Aaron Mulder added: Would it make sense for us to add some logic to the cache to segment the cache like we segment the pool? That is, so if the cache notices that the pool is partitioned by connection request info, the cache would use the same logic before coughing up a shared connection? David Jencks added: I think we should seriously consider not forcing you to claim your connections are unshared. -- 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
