[jira] Created: (AMQ-1022) when client is not authorized to write to A_QUEUE, producer.send to A_QUEUE does not raise exception
when client is not authorized to write to A_QUEUE, producer.send to A_QUEUE does not raise exception Key: AMQ-1022 URL: https://issues.apache.org/activemq/browse/AMQ-1022 Project: ActiveMQ Issue Type: Bug Components: Broker Affects Versions: 4.0.1 Environment: Windows, amq 4.0.1, using security features described on http://incubator.apache.org/activemq/security.html Reporter: Massive Boisson Using amq 4.0.1, transacted session, jms.useAsyncSend=false, security features described on http://incubator.apache.org/activemq/security.html and client NOT authorized to write to A_QUEUE, producer.send to that A_QUEUE does NOT raise an exception. Instead an asynchronous exception is raised to ExceptionListener. This way the data from the message is essentially lost, because it is not possible to connect exception to the message that should have cause the exception. -- 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: 1.2 Fit and Finish
I just uploaded a new weekly release here: http://people.apache.org/dist/geronimo/unstable/1.2-r470164/ Please spend a few minutes trying it out. -dain
Re: Deployment Plan -geronimo-web.xml
Hi Jacek Thanks a lot for your comments and reading it.My comments inline Best Regards Kanchana On 11/2/06, Jacek Laskowski [EMAIL PROTECTED] wrote: On 11/1/06, Kanchana Welagedara [EMAIL PROTECTED] wrote: Now the geronimo deployment plan for web application is ready for users.Please find the location here with, http://cwiki.apache.org/GMOxDOC11/geronimo-webxml.html It must've taken lots of time and effort! I hoped to read it all, but after a couple of paragraphs my brain simply melt down. So much technical information at once for such a faint-hearted person like me is not a good idea, isn't it? ;-) Let's hope the new users are not as faint-hearted :) I would like to have your feed back as input to make the other deployment plans better.Therefore following documentations are presently underconstruction and will be available soon for users. openejb-jar.xml geronimo-ra.xml geronimo-application.xml geronimo-application-client.xml It's much to do and am not sure whether it's in sync after a few commits. Jacek I'm sorry I didn't understand this part of the mail and can you please kindly explain it bit more to me?Are you referring some JIRA sort of commits? I think we'd be better off if we put the tag documentation into XSDs themselves so XML editors will provide concise information right when necessary. sure Jacek .will do. Jacek -- Jacek Laskowski http://www.jaceklaskowski.pl
Re: svn commit: r470013 - /geronimo/server/trunk/modules/geronimo-system/src/test/java/org/apache/geronimo/system/properties/NamingPropertiesTest.java
Since we now have our own class for this, can't we make the test vm independent? attribute name="namingFactoryInitial"org.apache.xbean.naming.global.GlobalContextManager/attributefrom rmi-naming.thanksdavid jencksOn Nov 1, 2006, at 9:49 PM, Vamsavardhana Reddy wrote:There is a private static final String NAMING_FACTORY_INITIAL = "com.sun.jndi.rmi.registry.RegistryContextFactory" in the class. should it be Should it be Class.forName(NAMING_FACTORY_INITIAL) ? --vamsiOn 11/2/06, Jacek Laskowski [EMAIL PROTECTED] wrote: On 11/1/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Author: rickmcguire Date: Wed Nov 1 09:48:44 2006 New Revision: 470013 URL: http://svn.apache.org/viewvc?view=revrev=470013 Log: GERONIMO-1840 NamingPropertiesTest is not compatible with non-Sun VMs. ... +try { +// the above assumes we're running on a Sun JVM. If we can't load the class first, +// we'll skip the attempt at creating the InitialContext. We've already verified that the +// system properties have been set to the correct values, so this last bit is largely a formality. +Class.forName("NAME_FACTORY_INITIAL"); +new InitialContext(); +} catch (ClassNotFoundException e) { +}It's not the first time I ask for some help understanding a change and this one is not an exception.Why do we look up the "NAME_FACTORY_INITIAL" class since it's deemedto fail every time?Jacek--Jacek Laskowski http://www.jaceklaskowski.pl
Re: xbean-finder: ClassFinder
On 11/2/06, David Blevins [EMAIL PROTECTED] wrote: More updates to the ClassFinder You can now construct the finder with exactly the list of classes you want to search for annotations. It uses var args too, so you can easily specify one class if you like. Convenient for when you have some of the code that picks which class or classes should be scraped for annotated methods, fields, constructors, etc. I also added a 'findClassesInPackage' method that allows you to suck in all the classes under a certain package name. This can be done recursively or not. Awesome! I've already taken a look at the changes and wonder why it wasn't me who came up with such an easy yet brilliant solution. I think I couldn't already have done it, but somehow I can't find an answer why I didn't ;-) It seems so easy now. Time to write some docs and examples about it. I'll be doing some for OpenEJB 3 (it looks it became a reference implementation for XBean and those new features ;-)) Jacek -- Jacek Laskowski http://www.jaceklaskowski.pl
[jira] Closed: (GERONIMO-495) Provide an auditing login module implementation
[ http://issues.apache.org/jira/browse/GERONIMO-495?page=all ] Vamsavardhana Reddy closed GERONIMO-495. Provide an auditing login module implementation --- Key: GERONIMO-495 URL: http://issues.apache.org/jira/browse/GERONIMO-495 Project: Geronimo Issue Type: New Feature Components: security Affects Versions: 1.0-M3, 1.0-M1, 1.0-M2 Reporter: Aaron Mulder Assigned To: Aaron Mulder Fix For: 1.0-M4 It should write an entry to a file on every login attempt and then follow up with success, failure, and/or logout. -- 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-570) Improve format of Gbean is not running message, issued at startup
[ http://issues.apache.org/jira/browse/GERONIMO-570?page=all ] Vamsavardhana Reddy closed GERONIMO-570. Improve format of Gbean is not running message, issued at startup - Key: GERONIMO-570 URL: http://issues.apache.org/jira/browse/GERONIMO-570 Project: Geronimo Issue Type: Improvement Reporter: John Sisson Assigned To: Alan Cabrera Priority: Trivial Attachments: patch.txt Change the format of the end of the following message, to make it more readable: 18:53:26,449 INFO [Daemon] GBean geronimo.server:J2EEApplication=null,J2EEModule=blah,J2EEServer=geronimo,j2eeType=GBean,name=blahblah is not running in state starting to: 18:53:26,449 INFO [Daemon] GBean geronimo.server:J2EEApplication=null,J2EEModule=blah,J2EEServer=geronimo,j2eeType=GBean,name=blahblah is not running. Current state is: starting -- 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-493) Add Login Domains to Security Objects
[ http://issues.apache.org/jira/browse/GERONIMO-493?page=all ] Vamsavardhana Reddy closed GERONIMO-493. Add Login Domains to Security Objects - Key: GERONIMO-493 URL: http://issues.apache.org/jira/browse/GERONIMO-493 Project: Geronimo Issue Type: Improvement Components: security Affects Versions: 1.0-M3, 1.0-M1, 1.0-M2 Reporter: Aaron Mulder Assigned To: Aaron Mulder Fix For: 1.0-M4 Security realms don't distinguish between different login domains, so if you deploy the same login module twice, the two instance are indistinguishable as far as roles are concerned. You might want to do this if, for example, you had an IT login domain and a Finance login domain (both LDAP or Active Directory or something but on different servers) and you want map users from both login domains to roles in the same application. -- 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
License issues in Geronimo 1.0 Samples
Hi All, Past few days I have been upgrading JBoss to Apache Geronimo samples from v1.0 of the documentation to v1.1. As part of the upgrade procedure, when I was looking at one of the samples I found something that grabbed my attention in the existing JBoss to Geronimo sample applications. Have a look at "JBoss to Geronimo - Security Migration" in following url: http://cwiki.apache.org/confluence/display/GMOxDOC10/JBoss+to+Geronimo+-+Security+Migration Source code of this sample contains some proprietary license. So we can't do any editing this sample. Isn't it? I'm quite new to the open source model, and AFAIK it should come with ASF license. Please correct me if I am wrong. Thanks, Lasantha Ranaweera
[jira] Closed: (GERONIMO-463) CLI Deployer doesn't give login prompt for non-Geronimo server
[ http://issues.apache.org/jira/browse/GERONIMO-463?page=all ] Vamsavardhana Reddy closed GERONIMO-463. CLI Deployer doesn't give login prompt for non-Geronimo server -- Key: GERONIMO-463 URL: http://issues.apache.org/jira/browse/GERONIMO-463 Project: Geronimo Issue Type: Improvement Components: deployment Affects Versions: 1.0-M3 Reporter: Aaron Mulder Assigned To: Aaron Mulder Priority: Minor Fix For: 1.0 The CLI tool only prompts the user for authentication if it detects a Geronimo authentication failure. It should detect when a non-Geronimo URI is being used, and prompt for authentication before attempting to connect (unless the info was provided on the command line). An argument could be made that it should always prompt (Geronimo or not), but then it would prompt even if it was ultimately going to fall back on operating in offline mode, which would be a little weird. -- 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-444) New CLI deployer should indicate TargetModuleID relationships
[ http://issues.apache.org/jira/browse/GERONIMO-444?page=all ] Vamsavardhana Reddy closed GERONIMO-444. New CLI deployer should indicate TargetModuleID relationships - Key: GERONIMO-444 URL: http://issues.apache.org/jira/browse/GERONIMO-444 Project: Geronimo Issue Type: Improvement Components: deployment Affects Versions: 1.0-M3 Reporter: Aaron Mulder Assigned To: Aaron Mulder Fix For: 1.0-M5 When listing TargetModuleIDs (the results of many commands), they should be arranged with indentation to show which ones are parents/children of which ones. -- 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-443) New Deployer should prompt for username/password if necessary
[ http://issues.apache.org/jira/browse/GERONIMO-443?page=all ] Vamsavardhana Reddy closed GERONIMO-443. New Deployer should prompt for username/password if necessary - Key: GERONIMO-443 URL: http://issues.apache.org/jira/browse/GERONIMO-443 Project: Geronimo Issue Type: Improvement Components: deployment Affects Versions: 1.0-M2 Reporter: Aaron Mulder Assigned To: Aaron Mulder Fix For: 1.0-M3 If the deployer connects to the server but gets an authentication error, and a username and/or password was not passed on the command line, it should prompt for them and try again. Ideally, we'd figure out how to make the password typing invisible -- I have hope that we could use similar code to what Maven does when it updates the download progress, but I really have no idea. I expect this can be broken off as a separate issue once some sort of prompting is working. -- 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-430) Generalize security realms, consolidate logic into Login Modules
[ http://issues.apache.org/jira/browse/GERONIMO-430?page=all ] Vamsavardhana Reddy closed GERONIMO-430. Generalize security realms, consolidate logic into Login Modules Key: GERONIMO-430 URL: http://issues.apache.org/jira/browse/GERONIMO-430 Project: Geronimo Issue Type: Improvement Components: security Affects Versions: 1.0-M2 Reporter: Aaron Mulder Assigned To: Aaron Mulder Fix For: 1.0-M4 I'd like to generalize the security realm implementation, and make it take a more arbitrary/configurable list of login modules. That would let you implement features like auditing and lockout as login modules, and hopefully entirely encapsulate Kerberos, SQL, and File access as login modules. Then you pick login modules from here and there and pop them into a general security realm, and off you go. It makes it all much more modular, and lets us reuse the same features across realm types without needing to separately update multiple security realm implementations to handle them. To implement this, I'd suggest creating an interface such as DeployerSupport, to hold the methods getUserPrincipals and getGroupPrincipals (or their equivalents; see issue 410). Then the LoginModules could implement that, moving that logic from security realm to login module (though the realm could still provide a thin wrapper for it). For example, look at the SQL realm. Both SQLSecurityRealm and SQLLoginModule have database logic, and they don't share connections or reuse code or anything. If we make SQLLoginModule implement DeployerSupport, then all the DB/SQL logic could go in the SQLLoginModule. The SQLSecurityRealm would suddenly have no SQL-realm-specific code, and could be replaced by a generic realm. The same could be done with the PropertiesFile realm and Kerberos realm, so long as we provide a way to pass required options to the individual LoginModules. If we consolidate all 3 of our realms on one SecurityRealm implementation class, then it woudl be easier to make that one class support multiple login modules (issue 424). This would also let us solve the issue of passing options to login modules once, since it would need to be handled in order to configure multiple login modules as well. We could also consolidate down to one way to pass options to login modules (issue 422). If our combined realm took a ServerInfo parameter, that could provide the hook required for issue 426. -- 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-419) Lockout after N failed logins
[ http://issues.apache.org/jira/browse/GERONIMO-419?page=all ] Vamsavardhana Reddy closed GERONIMO-419. Lockout after N failed logins - Key: GERONIMO-419 URL: http://issues.apache.org/jira/browse/GERONIMO-419 Project: Geronimo Issue Type: New Feature Components: security Affects Versions: 1.0-M2 Reporter: Aaron Mulder Assigned To: Aaron Mulder Priority: Minor Fix For: 1.0 It would be nice if the default security realms supported locking an account after a certain number of consecutive failed logins. Lacking that, it would be nice if they supported a configurable delay on a failed login attempt. Both methods help defend against brute force login attacks. This is a pretty low priority, but IMHO it still goes on the nice to have list. -- 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-358) JSR-88 deployer should work remotely
[ http://issues.apache.org/jira/browse/GERONIMO-358?page=all ] Vamsavardhana Reddy closed GERONIMO-358. JSR-88 deployer should work remotely Key: GERONIMO-358 URL: http://issues.apache.org/jira/browse/GERONIMO-358 Project: Geronimo Issue Type: Improvement Components: deployment Affects Versions: 1.0-M1 Reporter: Jeremy Boynes Assigned To: Aaron Mulder Fix For: 1.0 Currently the deployer just sends the File to the server so the tool and server must be on the same machine (or have the File on a network drive). It would be useful if the File or InputStream could be sent to the server allowing deployment to a remote machine. However, RMI may not be the best transport for this :-) -- 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-350) Reclaim disk space when deploying updated app version
[ http://issues.apache.org/jira/browse/GERONIMO-350?page=all ] Vamsavardhana Reddy closed GERONIMO-350. Reclaim disk space when deploying updated app version - Key: GERONIMO-350 URL: http://issues.apache.org/jira/browse/GERONIMO-350 Project: Geronimo Issue Type: Improvement Components: deployment Affects Versions: 1.0-M3 Reporter: Aaron Mulder Fix For: 1.0-M5 When redeploying an EAR with deployer.jar --install, it creates a new directory in the config-store, and updates the index to point to the new directory. It does not delete the old directory, which means over time, you get dozens of copies of the application, only one of which is being used in the server. For now, it's probably sufficient to delete the old directory once the new directory has been successfully deployed. In any case it should certainly be safe to keep no more than two copies. -- 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-293) Add support for CORBA
[ http://issues.apache.org/jira/browse/GERONIMO-293?page=all ] Vamsavardhana Reddy closed GERONIMO-293. Add support for CORBA - Key: GERONIMO-293 URL: http://issues.apache.org/jira/browse/GERONIMO-293 Project: Geronimo Issue Type: New Feature Components: CORBA Reporter: Alan Cabrera Assigned To: Alan Cabrera Add support for CORBA. Stubs for EJBs should be automatically generated. -- 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-698) Print port map at server startup
[ http://issues.apache.org/jira/browse/GERONIMO-698?page=all ] Vamsavardhana Reddy closed GERONIMO-698. Print port map at server startup Key: GERONIMO-698 URL: http://issues.apache.org/jira/browse/GERONIMO-698 Project: Geronimo Issue Type: New Feature Reporter: Erin Mulder Assigned To: Aaron Mulder Priority: Minor Fix For: 1.0-M4 Would be nice (especially for new users) to have the server print out a list of port assignments upon successful startup. For example: bin/startup.sh Environment information: JDK_HOME: /usr/lib/java GERONIMO_BUILD: 1.0-169186 VERBOSE_LEVEL: quiet (use -verbose to change) SERVER STARTING.. Now listening on: Port 1234: JMS Port 8080: HTTP Port 8081: HTTPS Port 9876: Foo SERVER STARTED SUCCESSFULLY! Browse to http://localhost:8080/ for web console -- 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-697) Need guidance for new users upon successful server startup
[ http://issues.apache.org/jira/browse/GERONIMO-697?page=all ] Vamsavardhana Reddy closed GERONIMO-697. Need guidance for new users upon successful server startup -- Key: GERONIMO-697 URL: http://issues.apache.org/jira/browse/GERONIMO-697 Project: Geronimo Issue Type: Improvement Components: usability Reporter: Erin Mulder Assigned To: Aaron Mulder Priority: Minor Fix For: 1.0-M5 There's no sense of what to do next when first launching the server. It would be nice to see something like Server started successfully! Visit the web console at http://localhost:8080/;. -- 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-695) Need better progress feedback during startup sequence
[ http://issues.apache.org/jira/browse/GERONIMO-695?page=all ] Vamsavardhana Reddy closed GERONIMO-695. Need better progress feedback during startup sequence - Key: GERONIMO-695 URL: http://issues.apache.org/jira/browse/GERONIMO-695 Project: Geronimo Issue Type: Improvement Reporter: Erin Mulder Assigned To: Aaron Mulder Priority: Minor Fix For: 1.0-M4 When first launching the server, it's hard to tell when startup is complete. There are lots of pauses, and it's not clear whether there will eventually be a successful startup message. This adds a bit of uncertainty/confusion as you sit there and wonder whether it's done, still going or broken. (It would actually be quite cool/unique to add some sort of ascii progress bar like sftp and scp use.) -- 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-696) Too much info-level output during startup
[ http://issues.apache.org/jira/browse/GERONIMO-696?page=all ] Vamsavardhana Reddy closed GERONIMO-696. Too much info-level output during startup - Key: GERONIMO-696 URL: http://issues.apache.org/jira/browse/GERONIMO-696 Project: Geronimo Issue Type: Improvement Reporter: Erin Mulder Assigned To: Aaron Mulder Fix For: 1.0-M4 During startup, too much unnecessary information is written to the console. Ideally, it should display a Server starting... message, followed by some sort of small progress indicator, followed by a Server started successfully! message. Only errors, severe warnings, or truly useful environment information should go in between. (A verbose switch could be added to allow developers to load the server with the current chatty log4j config.) For example: - bin/startup.sh Environment information: JDK_HOME: /usr/lib/java GERONIMO_BUILD: 1.0-169186 VERBOSE_LEVEL: quiet (use -verbose to change) SERVER STARTING.. Now listening on: Port 1234: JMS Port 8080: HTTP Port 8081: HTTPS Port 9876: Foo SERVER STARTED SUCCESSFULLY! Browse to http://localhost:8080/ for web console - -- 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-728) Jetty gives misleading NPE on port in use condition
[ http://issues.apache.org/jira/browse/GERONIMO-728?page=all ] Vamsavardhana Reddy closed GERONIMO-728. Jetty gives misleading NPE on port in use condition - Key: GERONIMO-728 URL: http://issues.apache.org/jira/browse/GERONIMO-728 Project: Geronimo Issue Type: Improvement Components: web, dependencies Affects Versions: 1.0-M3, 1.0-M5, 1.0-M4 Reporter: Aaron Mulder Assigned To: Kevan Miller Fix For: 1.0-M5 When Jetty starts up but the port it wants is in use, you get an error like this: 19 ERROR [GBeanInstance] Problem in doFail of geronimo.server:J2EEApplication=null,J2EEModule=org/apache/geronimo/Server,J2EEServer=geronimo,j2eeType=GBean,name=JettyWebConnector java.lang.NullPointerException at org.mortbay.util.ThreadedServer.stop(ThreadedServer.java:544) at org.mortbay.http.SocketListener.stop(SocketListener.java:211) at org.apache.geronimo.jetty.connector.JettyConnector.doFail(JettyConnector.java:102) at org.apache.geronimo.gbean.runtime.GBeanInstance.createInstance(GBeanInstance.java:869) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStart(GBeanInstanceState.java:328) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.start(GBeanInstanceState.java:111) at org.apache.geronimo.gbean.runtime.GBeanInstance.start(GBeanInstance.java:486) at org.apache.geronimo.gbean.runtime.GBeanSingleReference.attemptFullStart(GBeanSingleReference.java:154) at org.apache.geronimo.gbean.runtime.GBeanSingleReference.targetAdded(GBeanSingleReference.java:127) at org.apache.geronimo.gbean.runtime.AbstractGBeanReference.addTarget(AbstractGBeanReference.java:242) at org.apache.geronimo.gbean.runtime.GBeanSingleReference$1.running(GBeanSingleReference.java:163) at org.apache.geronimo.kernel.basic.BasicLifecycleMonitor.fireRunningEvent(BasicLifecycleMonitor.java:155) at org.apache.geronimo.kernel.basic.BasicLifecycleMonitor.access$300(BasicLifecycleMonitor.java:38) at org.apache.geronimo.kernel.basic.BasicLifecycleMonitor$RawLifecycleBroadcaster.fireRunningEvent(BasicLifecycleMonitor.java:231) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStart(GBeanInstanceState.java:352) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.start(GBeanInstanceState.java:111) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.startRecursive(GBeanInstanceState.java:133) at org.apache.geronimo.gbean.runtime.GBeanInstance.startRecursive(GBeanInstance.java:503) at org.apache.geronimo.kernel.basic.BasicKernel.startRecursiveGBean(BasicKernel.java:207) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.startRecursive(GBeanInstanceState.java:141) at org.apache.geronimo.gbean.runtime.GBeanInstance.startRecursive(GBeanInstance.java:503) at org.apache.geronimo.kernel.basic.BasicKernel.startRecursiveGBean(BasicKernel.java:207) at org.apache.geronimo.system.main.Daemon.doStartup(Daemon.java:247) at org.apache.geronimo.system.main.Daemon.init(Daemon.java:81) at org.apache.geronimo.system.main.Daemon.main(Daemon.java:320) Only later does the BindException show up, whereas I believe the BindException should be first (and in fact only -- what good does the NPE do?). So what I think should happen is that we should trap a BindException, and if it comes up, don't try to stop the SocketListener (or at least don't generate another exception if it doesn't work). Then print an ERROR message including the port number (ERROR: Jetty unable to bind to port 8080). Then throw the BindException if the full stack trace would be useful. -- 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-1217) WARN message in console for JMS Server
[ http://issues.apache.org/jira/browse/GERONIMO-1217?page=all ] Vamsavardhana Reddy closed GERONIMO-1217. - WARN message in console for JMS Server -- Key: GERONIMO-1217 URL: http://issues.apache.org/jira/browse/GERONIMO-1217 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: console Affects Versions: 1.0-M5 Reporter: Krishnakumar B Assigned To: Aaron Mulder Priority: Minor Fix For: 1.0 When i click JMS Server in Console JMS Server Manager and Listeners are displayed. The following WARN message is displayed in console and is logged in log file. 11:20:55,076 WARN [BasicProxyManager] Could not load interface org.activemq.gbean.ActiveMQContainer in provided ClassLoader for ActiveMQ 11:20:55,797 WARN [BasicProxyManager] Could not load interface org.activemq.gbean.ActiveMQContainer in provided ClassLoader for ActiveMQ -- 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-762) Improve manageability by adding a web based management console
[ http://issues.apache.org/jira/browse/GERONIMO-762?page=all ] Vamsavardhana Reddy closed GERONIMO-762. Improve manageability by adding a web based management console -- Key: GERONIMO-762 URL: http://issues.apache.org/jira/browse/GERONIMO-762 Project: Geronimo Issue Type: New Feature Components: management Reporter: David Klavon Assigned To: Aaron Mulder Fix For: 1.0-M5 Attachments: console.zip, GeronimoConsoleJars.zip Geronimo should provide a way to administer the server via the web. -- 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-748) Deployer gives nasty stack traces for login failure
[ http://issues.apache.org/jira/browse/GERONIMO-748?page=all ] Vamsavardhana Reddy closed GERONIMO-748. Deployer gives nasty stack traces for login failure --- Key: GERONIMO-748 URL: http://issues.apache.org/jira/browse/GERONIMO-748 Project: Geronimo Issue Type: Improvement Components: deployment Affects Versions: 1.0-M3 Reporter: Aaron Mulder Assigned To: Aaron Mulder Fix For: 1.0-M5 Deployer should give nice message and no stack track for login failure. -- 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-804) Redeploy should calculate ModuleID to replace if not provided
[ http://issues.apache.org/jira/browse/GERONIMO-804?page=all ] Vamsavardhana Reddy closed GERONIMO-804. Redeploy should calculate ModuleID to replace if not provided - Key: GERONIMO-804 URL: http://issues.apache.org/jira/browse/GERONIMO-804 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: deployment Affects Versions: 1.0-M3 Reporter: Aaron Mulder Assigned To: Aaron Mulder Fix For: 1.0 When you redeploy, it would be nice to pull the configId or archive name or whatever we usually do to generate the moduleID. That way if you redeploy the same archive, it would automatically know what ModuleIDs to replace, instead of you needing to specify them on the command line. Of course this may be a little tricky since the configId is on a different XML file for every module type... As a workaround, it would be possible for the deployer to remember the module IDs generated for the archive name used for each distribute or deploy operation, and prompt you based on that if you neglect to specify a module ID on the command line (Last time you deployed 'foo.war' it was called 'MyFooWebApp'. Replace 'MyFooWebApp' (Y/n)?) -- 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-801) Deployment with missing resource-ref gives an error including an ObjectName query
[ http://issues.apache.org/jira/browse/GERONIMO-801?page=all ] Vamsavardhana Reddy closed GERONIMO-801. Deployment with missing resource-ref gives an error including an ObjectName query - Key: GERONIMO-801 URL: http://issues.apache.org/jira/browse/GERONIMO-801 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: deployment, usability Affects Versions: 1.0-M3 Reporter: Aaron Mulder Assigned To: Aaron Mulder Fix For: 1.0-M5 When deploying a module with an unresolved resource ref (such as web app with a web.xml with a resource-ref and no geronimo-web.xml), the error looks like this: Unknown or ambiguous connection factory name query: geronimo.server:J2EEServer=geronimo,J2EEApplication=null,j2eeType=JCAManagedConnectionFactory,name=jdbc/Database,* match count: 0 (Where jdbc/Database is the res-ref-name) It would be much nicer if the error said Unable to resolve the resource reference 'jdbc/DataSource'. -- 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
[VOTE] Release ServiceMix 3.0.1
I have uploaded the 3.0.1 to the maven repo at http://people.apache.org/repo/m2-incubating-repository/org/apache/servicemix/apache-servicemix/3.0.1-incubating/ Please take some time to review and vote: [ ] +1 release 3.0.1 [ ] 0 [ ] -1 do not release 3.0.1 Here's my +1 -- Cheers, Guillaume Nodet
[jira] Closed: (GERONIMO-839) Require flag to provide config list on server startup, handle bogus arguments
[ http://issues.apache.org/jira/browse/GERONIMO-839?page=all ] Vamsavardhana Reddy closed GERONIMO-839. Require flag to provide config list on server startup, handle bogus arguments - Key: GERONIMO-839 URL: http://issues.apache.org/jira/browse/GERONIMO-839 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: startup/shutdown Affects Versions: 1.0-M4 Reporter: Aaron Mulder Assigned To: Aaron Mulder Fix For: 1.0 Currently, if you run java -jar server.jar foo then it interprets foo as (a list of) configurations you want to start the server with. And if foo doesn't exist, you get a stack track (unfortunate if you tried --help or /? or something). I'd like to require a flag before the list of configurations, something like: java -jar server.jar -configs o/a/g/Server o/a/g/RuntimeDeployer So if you don't provide the -configs it knows you gave incorrect arguments and should then provide syntax/help text instead of a stack trace. -- 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-862) Remove HTTP/HTTPS manager portlets
[ http://issues.apache.org/jira/browse/GERONIMO-862?page=all ] Vamsavardhana Reddy closed GERONIMO-862. Remove HTTP/HTTPS manager portlets -- Key: GERONIMO-862 URL: http://issues.apache.org/jira/browse/GERONIMO-862 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: console Affects Versions: 1.0-M5 Reporter: Aaron Mulder Assigned To: Aaron Mulder Fix For: 1.0-M5 Attachments: connectors.patch, connectors.zip, webserver.zip The AJP portlet has been converted to a generic web connector manager portlet. It now handles all the connector types. The HTTP and HTTPS portlets should be removed in favor of the new AJP one. There are a couple things that ought to be done first or at the same time: - The AJP one ought to be renamed to something more generic. - A copy of the editHTTP JSP should be created for HTTPS, with additional connector settings per what's in the SecureConnector interface. AJP doesn't need any special treatment (it can reuse the HTTP JSP for now). - The look and feel of the old HTTP connector list screen is nicer than the new unified connector list screen, so it should be migrated to the new portlet before the HTTP one is removed -- 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-1223) Hot Deploy performance improvement Just check directories -patch available
[ http://issues.apache.org/jira/browse/GERONIMO-1223?page=all ] Vamsavardhana Reddy closed GERONIMO-1223. - Hot Deploy performance improvement Just check directories -patch available -- Key: GERONIMO-1223 URL: http://issues.apache.org/jira/browse/GERONIMO-1223 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: deployment Affects Versions: 1.0 Environment: linux or windows Reporter: Gao Yong Pan Assigned To: Aaron Mulder Fix For: 1.0 Attachments: DirectoryMonitor.java.patch The method getLastModifiedInDir in the hot-deploy/src/java/org/apache/geronimo/deployment/hot/DirectoryMonitor.java is using the algorithm by calculating highest modified time of any files or directories, this could be improved. In fact, we only need to check every directory is enough, because any changes, for example, add, remove, edit any files in a directory, the change can be reflected by its current directory's modification time, so we don't need to check files. I also write a patch for the issue. A simple performance testing shows that the patch will improve 58% of the performance. -- 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-944) Bundle a JavaMail implementation SMTP provider
[ http://issues.apache.org/jira/browse/GERONIMO-944?page=all ] Vamsavardhana Reddy closed GERONIMO-944. Bundle a JavaMail implementation SMTP provider Key: GERONIMO-944 URL: http://issues.apache.org/jira/browse/GERONIMO-944 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: mail Affects Versions: 1.0-M4 Reporter: Aaron Mulder Assigned To: Aaron Mulder Priority: Critical Fix For: 1.1 I'm not sure what the state is of our JavaMail implementation. I know we have our own spec JAR and I think I've heard that we have our own SMTP provider, but that it's not part of the Geronimo distribution and as a result the Sun JavaMail provider is recommended. I'd like to straighten this out for M5 so we can provide basic JavaMail resource mapping (at least for outgoing mail via SMTP) as part of the standard package. If this is not possible for some reason, please retarget this issue to 1.0 and suggest a path forward. Thanks. -- 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-1174) Hot deployer should know when a file was last deployed
[ http://issues.apache.org/jira/browse/GERONIMO-1174?page=all ] Vamsavardhana Reddy closed GERONIMO-1174. - Hot deployer should know when a file was last deployed -- Key: GERONIMO-1174 URL: http://issues.apache.org/jira/browse/GERONIMO-1174 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: Hot Deploy Dir Affects Versions: 1.0-M5 Reporter: Aaron Mulder Assigned To: Aaron Mulder Priority: Critical Fix For: 1.1 It would be nice if the hot deployer knew when a module was last deployed. That way, during startup, it could update deployments where the archive in the hot deployer directory had been updated while the server was down. This would go into HotDeployer.getDeploymentTime (which currently is essentially a noop). It seems like the most expedient way to implement this would be to add a method to the config store to get the deployment time (given a URI). David J suggests putting that method in a separate interface, something like TimedConfigStore or whatever. It's not clear that it should live forever in the config store, but that seems like the best short-term plan. -- 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-1202) SQL Login Module support for server Database Pools
[ http://issues.apache.org/jira/browse/GERONIMO-1202?page=all ] Vamsavardhana Reddy closed GERONIMO-1202. - SQL Login Module support for server Database Pools -- Key: GERONIMO-1202 URL: http://issues.apache.org/jira/browse/GERONIMO-1202 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: security Affects Versions: 1.0-M5 Reporter: Aaron Mulder Assigned To: Aaron Mulder Fix For: 1.0 It would be nice if the SQL security realm could take a database pool name as an alternative to the driver/URL/etc. properties. -- 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-1143) Need a capable security realm configuration portlet
[ http://issues.apache.org/jira/browse/GERONIMO-1143?page=all ] Vamsavardhana Reddy closed GERONIMO-1143. - Need a capable security realm configuration portlet --- Key: GERONIMO-1143 URL: http://issues.apache.org/jira/browse/GERONIMO-1143 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: console, security, management Affects Versions: 1.0-M5 Reporter: Aaron Mulder Assigned To: Aaron Mulder Fix For: 1.0 There should be a portlet that lets you create and edit security realms, control which login modules go into the realms, etc. The edit feature may be a little tricky as changing the login modules IIUC requires a fair bit of adding and removing GBeans. -- 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-1137) Proper DConfigBeans for Connectors
[ http://issues.apache.org/jira/browse/GERONIMO-1137?page=all ] Vamsavardhana Reddy closed GERONIMO-1137. - Proper DConfigBeans for Connectors -- Key: GERONIMO-1137 URL: http://issues.apache.org/jira/browse/GERONIMO-1137 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: connector, deployment Affects Versions: 1.0-M5 Reporter: Aaron Mulder Assigned To: Aaron Mulder Fix For: 1.1 The best way for the console to properly deploy DB pools and JMS resources is to use JSR-88, so... if we only had DConfigBeans, the console wouldn't be maintaining templates for deployment plans. :) -- 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-1120) Auto-detect config ID for a deployable archive
[ http://issues.apache.org/jira/browse/GERONIMO-1120?page=all ] Vamsavardhana Reddy closed GERONIMO-1120. - Auto-detect config ID for a deployable archive -- Key: GERONIMO-1120 URL: http://issues.apache.org/jira/browse/GERONIMO-1120 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: deployment Affects Versions: 1.0-M3 Reporter: Aaron Mulder Assigned To: Aaron Mulder Fix For: 1.0 Given an application/module/service archive, or an archive and a plan, we need a routine to pull out what the configuration name will be for it. In other words, we need to peek into the deployment plan and look for the configId attribute, the catch being that we don't know up front what the name of the plan file is if it's embedded in the JAR. This is necessary to be able to redeploy without explicitly naming the configuration to replace, which is necessary to do redeploy operations in a hot deploy directory. It seems like it'd be easy to write a bit of code to do this by hardcoding the locations of all known deployment types, but it would be a little more elegant if the deployers coughed up the required information and it could be handled on a more pluggable basis. -- 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-1016) DayTrader Application donation
[ http://issues.apache.org/jira/browse/GERONIMO-1016?page=all ] Vamsavardhana Reddy closed GERONIMO-1016. - DayTrader Application donation -- Key: GERONIMO-1016 URL: http://issues.apache.org/jira/browse/GERONIMO-1016 Project: Geronimo Issue Type: New Feature Security Level: public(Regular issues) Affects Versions: 1.0 Environment: All Reporter: Matt Hogstrom Assigned To: Geir Magnusson Jr Attachments: daytrader.tar.gz The dayTrader application for performance and sample deployment for Geronimo. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (GERONIMO-1075) Configuration classloaders should support an inverse classloading delegation model.
[ http://issues.apache.org/jira/browse/GERONIMO-1075?page=all ] Vamsavardhana Reddy closed GERONIMO-1075. - Configuration classloaders should support an inverse classloading delegation model. --- Key: GERONIMO-1075 URL: http://issues.apache.org/jira/browse/GERONIMO-1075 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: kernel Affects Versions: 1.0-M5, 1.0-M4, 1.0-M3, 1.0-M2, 1.0-M1 Reporter: Gianny Damour Assigned To: Gianny Damour Fix For: 1.2 Currently, configuration classloaders use the standard class loading delegation model. It seems that a reverse class loading delegation model, a la servlet container, may be useful. Also, after discussion with Dain, it seems that a configuration classloader should defines two types of filters: * classes hidden from the configuration: this means that this configuration cannot see the classes defined by this filter; and * classes non overridable by this configuration: this means that this configuration cannot override the classes defined by this filter. Note that this list has a meaning only when the class loading delegation model is reversed. -- 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-1357) Apache Geronimo V1.0 Documentation Draft
[ http://issues.apache.org/jira/browse/GERONIMO-1357?page=all ] Vamsavardhana Reddy closed GERONIMO-1357. - Apache Geronimo V1.0 Documentation Draft Key: GERONIMO-1357 URL: http://issues.apache.org/jira/browse/GERONIMO-1357 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: documentation Affects Versions: 1.0 Environment: All Reporter: Hernan Cunico Assigned To: Hernan Cunico Attachments: GDoc_2005_12_15.zip, GDoc_2005_12_16.zip, GERONIMO_DOC_2005_12_13.zip Better later than never, here is the updated HTML documentation. -- 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-1346) Encrypt passwords stored in config.xml
[ http://issues.apache.org/jira/browse/GERONIMO-1346?page=all ] Vamsavardhana Reddy closed GERONIMO-1346. - Encrypt passwords stored in config.xml -- Key: GERONIMO-1346 URL: http://issues.apache.org/jira/browse/GERONIMO-1346 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: core, security Affects Versions: 1.0-M5 Reporter: Aaron Mulder Assigned To: Aaron Mulder Fix For: 1.0 Passwords (such as database or ActiveMQ or keystore passwords) appearing in the config.xml file should be encrypted (at least to a degree that prevents casual observation). -- 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-1318) HTTP redirects for the geronimo.apache.org site
[ http://issues.apache.org/jira/browse/GERONIMO-1318?page=all ] Vamsavardhana Reddy closed GERONIMO-1318. - HTTP redirects for the geronimo.apache.org site --- Key: GERONIMO-1318 URL: http://issues.apache.org/jira/browse/GERONIMO-1318 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: console Affects Versions: 1.0 Reporter: Paul McMahan Assigned To: Alan Cabrera Priority: Minor Fix For: 1.0 Attachments: GERONIMO-1318.patch The welcome application and the welcome portlet currently contain links to web pages outside of the geronimo.apache.org web site (e.g. the docs in Confluence). Since the destination of these links is outside of our control they may go stale during the lifetime of the 1.0 console. So instead of linking to those web pages directly the welcome application and welcome portlet should instead link to web pages on the geronimo.apache.org web site. The geronimo.apache.org web site can then redirect the browser to the external address if necessary. This will allow us to change where the links in the welcome portlet and welcome app take a web browser without actually changing the installed geronimo server. Ideally we could configure the geronimo.apache.org HTTP server to issue the redirects. But since that requires administrative access to the HTTP server we can use html files containing a meta http-equiv=refresh ... tag instead. -- 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-1317) Rename the new goals to more meaningful names with additional build properties
[ http://issues.apache.org/jira/browse/GERONIMO-1317?page=all ] Vamsavardhana Reddy closed GERONIMO-1317. - Rename the new goals to more meaningful names with additional build properties Key: GERONIMO-1317 URL: http://issues.apache.org/jira/browse/GERONIMO-1317 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: buildsystem Affects Versions: 1.0, 1.2 Environment: Maven 1.1Beta2 on WinXP Reporter: Donald Woods Assigned To: Jacek Laskowski Fix For: 1.2 Attachments: Geronimo-1317.patch, maven.xml, patch.txt, project.properties For ongoing development builds, we need to get the clean, eclipse, idea and other Maven goals that we used to have working again. I have created updated \maven.xml and \project.properties files based on 1.0 Rev355316, which renames and integrates the new0-new5 goals into the m:default goal, only tries to build openejb and tranql if those directories exist and enables the usage of the rebuild-all, build-all, build, clean, clean-all, eclipse and idea goals. I'll attach the patch files and copies of the updated files for testing before integrating the changes. -- 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-1231) Error on startup: java.lang.NoClassDefFoundError at javax.crypto.Mac.getInstance...
[ http://issues.apache.org/jira/browse/GERONIMO-1231?page=all ] Vamsavardhana Reddy closed GERONIMO-1231. - Error on startup: java.lang.NoClassDefFoundError at javax.crypto.Mac.getInstance... --- Key: GERONIMO-1231 URL: http://issues.apache.org/jira/browse/GERONIMO-1231 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: kernel Affects Versions: 1.0-M5 Environment: Fedora Core 4. java version 1.5.0_04 Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_04-b05) Java HotSpot(TM) Client VM (build 1.5.0_04-b05, mixed mode) Reporter: Greg Luck Priority: Minor Fix For: 1.x ./startup.sh Booting Geronimo Kernel (in Java 1.5.0_04)... Starting Geronimo Application Server [*** ] 91% 11s Starting org/apache/geronimo/Console/Jetty 15:57:56,430 ERROR [GBeanInstanceState] Error while starting; GBean is now in the FAILED state: objectName=geronimo.server:J2EEApplication=org/apache/geronimo/Console/Jetty,J2EEModule=null,J2EEServer=geronimo,j2eeType=JACCManager,name=JACCManager java.lang.NoClassDefFoundError at javax.crypto.Mac.getInstance(DashoA12275) at org.apache.geronimo.security.ContextManager.setAlgorithm(ContextManager.java:292) at org.apache.geronimo.security.ContextManager.clinit(ContextManager.java:63) at org.apache.geronimo.security.jacc.ApplicationPolicyConfigurationManager.init(ApplicationPolicyConfigurationManager.java:115) at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27) at java.lang.reflect.Constructor.newInstance(Constructor.java:494) at org.apache.geronimo.gbean.runtime.GBeanInstance.createInstance(GBeanInstance.java:856) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStart(GBeanInstanceState.java:325) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.start(GBeanInstanceState.java:110) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.startRecursive(GBeanInstanceState.java:132) at org.apache.geronimo.gbean.runtime.GBeanInstance.startRecursive(GBeanInstance.java:497) at org.apache.geronimo.kernel.basic.BasicKernel.startRecursiveGBean(BasicKernel.java:210) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.startRecursive(GBeanInstanceState.java:140) at org.apache.geronimo.gbean.runtime.GBeanInstance.startRecursive(GBeanInstance.java:497) at org.apache.geronimo.kernel.basic.BasicKernel.startRecursiveGBean(BasicKernel.java:210) at org.apache.geronimo.system.main.Daemon.doStartup(Daemon.java:233) at org.apache.geronimo.system.main.Daemon.init(Daemon.java:78) at org.apache.geronimo.system.main.Daemon.main(Daemon.java:316) Exception in thread main java.lang.NoClassDefFoundError at javax.crypto.Mac.getInstance(DashoA12275) at org.apache.geronimo.security.ContextManager.setAlgorithm(ContextManager.java:292) at org.apache.geronimo.security.ContextManager.clinit(ContextManager.java:63) at org.apache.geronimo.security.jacc.ApplicationPolicyConfigurationManager.init(ApplicationPolicyConfigurationManager.java:115) at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27) at java.lang.reflect.Constructor.newInstance(Constructor.java:494) at org.apache.geronimo.gbean.runtime.GBeanInstance.createInstance(GBeanInstance.java:856) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStart(GBeanInstanceState.java:325) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.start(GBeanInstanceState.java:110) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.startRecursive(GBeanInstanceState.java:132) at org.apache.geronimo.gbean.runtime.GBeanInstance.startRecursive(GBeanInstance.java:497) at org.apache.geronimo.kernel.basic.BasicKernel.startRecursiveGBean(BasicKernel.java:210) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.startRecursive(GBeanInstanceState.java:140) at org.apache.geronimo.gbean.runtime.GBeanInstance.startRecursive(GBeanInstance.java:497) at
[jira] Closed: (GERONIMO-1290) Rename the geronimo.base.dir System Property to org.apache.geronimo.base.dir
[ http://issues.apache.org/jira/browse/GERONIMO-1290?page=all ] Vamsavardhana Reddy closed GERONIMO-1290. - Rename the geronimo.base.dir System Property to org.apache.geronimo.base.dir Key: GERONIMO-1290 URL: http://issues.apache.org/jira/browse/GERONIMO-1290 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: usability Affects Versions: 1.0-M5, 1.0-M4 Reporter: John Sisson Assigned To: Sachin Patel Fix For: 1.0 This will be renamed to be conistent with other Geronimo properties with the org.apache prefix. See dev mailing list thread System property geronimo.base.dir naming convention -- 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-1284) Set default console log level to INFO
[ http://issues.apache.org/jira/browse/GERONIMO-1284?page=all ] Vamsavardhana Reddy closed GERONIMO-1284. - Set default console log level to INFO - Key: GERONIMO-1284 URL: http://issues.apache.org/jira/browse/GERONIMO-1284 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: startup/shutdown Affects Versions: 1.0-M5 Reporter: Aaron Mulder Assigned To: Aaron Mulder Fix For: 1.0 The log level for the console output is currently WARN. We would like it to be INFO, so we can use INFO messages for information that it's important for the user to see but which is not bad (e.g. not WARN or above). In order to do that, we need to tone down the amount of INFO traffic we generate, particularly during startup and shutdown, and including third-party libraries. -- 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-1272) Edit Network Listener portlet should show name of listener being editted.
[ http://issues.apache.org/jira/browse/GERONIMO-1272?page=all ] Vamsavardhana Reddy closed GERONIMO-1272. - Edit Network Listener portlet should show name of listener being editted. - Key: GERONIMO-1272 URL: http://issues.apache.org/jira/browse/GERONIMO-1272 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: console Reporter: Rick McGuire Assigned To: Aaron Mulder Fix For: 1.0 Attachments: GERONIMO-1272.patch When you click on the edit operation of the Web Server-Network Listeners portlet, the editting portlet should show the name of the listener being editted. The lack if context is a little unsettling. -- 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-1429) Post Geronimo Schemas online (e.g. http://java.sun.com/xml/ns/j2ee/)
[ http://issues.apache.org/jira/browse/GERONIMO-1429?page=all ] Vamsavardhana Reddy closed GERONIMO-1429. - Post Geronimo Schemas online (e.g. http://java.sun.com/xml/ns/j2ee/) Key: GERONIMO-1429 URL: http://issues.apache.org/jira/browse/GERONIMO-1429 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: documentation Affects Versions: 1.0 Reporter: Aaron Mulder Assigned To: Aaron Mulder Fix For: 1.2 It would be nice to have an index page like http://java.sun.com/xml/ns/j2ee/ and have our schemas appear at their namespace URIs. Not for any technical reason, but because it makes the deployment plans very self-documenting if you can pop the URI into your browser and get the XSD 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] Closed: (GERONIMO-1478) Donation of XBean source
[ http://issues.apache.org/jira/browse/GERONIMO-1478?page=all ] Vamsavardhana Reddy closed GERONIMO-1478. - Donation of XBean source Key: GERONIMO-1478 URL: http://issues.apache.org/jira/browse/GERONIMO-1478 Project: Geronimo Issue Type: New Feature Security Level: public(Regular issues) Reporter: Dain Sundstrom Assigned To: Dain Sundstrom The XBean project has voted to donate all of the code located at https://svn.codehaus.org/xbean (view with fisheye http://cvs.codehaus.org/viewrep/xbean) to Apache Geronimo. XBean is a lightweight server framework which includes a simple kernel for managing service lifecycle, a server framework turns the kernel into a sand alone server, and several generic services/extensions that augment the simple server framework. The committers to this code base can be seen with the following UNIX command: svn log https://svn.codehaus.org/xbean | grep r[0-9][0-9]* | | sed s/r[0-9][0-9]* | \(.*\) | .* | .*$/\1/ | sort | uniq All of the committers have a CLA on file at Apache. The following table maps the unix user names to real names: chirino Hiram Chirino dain Dain Sundstrom dandiepDaniel Diephouse dblevinsDavid Blevins gnt Guillaume Nodet jstrachan James Strachan jvanzyl Jason van Zyl maguro Alan Cabrera root -service account- spullara Sam Pullara -- 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-1520) Add product name to NetworkManager
[ http://issues.apache.org/jira/browse/GERONIMO-1520?page=all ] Vamsavardhana Reddy closed GERONIMO-1520. - Add product name to NetworkManager -- Key: GERONIMO-1520 URL: http://issues.apache.org/jira/browse/GERONIMO-1520 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: management Affects Versions: 1.0 Reporter: Aaron Mulder Assigned To: Aaron Mulder Priority: Blocker Fix For: 1.1 Would be nice to be able to list available managers by name -- 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-1529) Console should display Geronimo Version
[ http://issues.apache.org/jira/browse/GERONIMO-1529?page=all ]
Vamsavardhana Reddy closed GERONIMO-1529.
-
Console should display Geronimo Version
---
Key: GERONIMO-1529
URL: http://issues.apache.org/jira/browse/GERONIMO-1529
Project: Geronimo
Issue Type: Improvement
Security Level: public(Regular issues)
Components: console, Logging
Affects Versions: 1.0, 1.0-M5, 1.0-M4, 1.0-M3, 1.0-M2, 1.0-M1, 1.1, 1.2,
1.x
Reporter: Matthias Schmidt
Assigned To: Aaron Mulder
Priority: Minor
Fix For: 1.1
Attachments: 1529-display-geronimo-version.patch, showVersion.patch
One should be able to figure out geronimo's Version by:
a) looking in the Console, perhaps under Server Info
b) looking in the Logfiles.
for a) one can do the following:
---
applications/console-standard/src/java/org/apache/geronimo/console/infomanager/ServerInfoPortlet.java
2006-01-23 14:57:59.0 +0100
+++
applications/console-standard/src/java/org/apache/geronimo/console/infomanager/ServerInfoPortlet.java.CHANGE
2006-01-23 15:02:27.0 +0100
@@ -34,6 +34,7 @@
import org.apache.geronimo.console.BasePortlet;
import org.apache.geronimo.console.util.PortletManager;
import org.apache.geronimo.management.geronimo.JVM;
+import org.apache.geronimo.console.GeronimoVersion;
/**
* Calculates various information about the server to display in the server
@@ -71,6 +72,8 @@
Date bootDate = jvm.getKernelBootTime();
svrProps.put(Kernel Boot Time, bootDate);
+svrProps.put(Geronimo Version, new
GeronimoVersion().GERONIMO_VERSION);
+
renderRequest.setAttribute(svrProps, svrProps);
jvmProps.put(Java Version, jvm.getJavaVersion());
---
applications/console-standard/src/webapp/WEB-INF/view/infomanager/svrInfoNormal.jsp
2006-01-11 17:34:52.0 +0100
+++
applications/console-standard/src/webapp/WEB-INF/view/infomanager/svrInfoNormal.jsp.CHANGE
2006-01-23 15:06:42.0 +0100
@@ -5,6 +5,7 @@
script type='text/javascript'
src='/console-standard/dwr/engine.js'/script
script type='text/javascript' src='/console-standard/dwr/util.js'/script
+
portlet:defineObjects/
table width=100%
@@ -19,6 +20,10 @@
td class=MediumBackgroundKernel Up Time/td
td class=MediumBackgrounddiv id=portlet:namespace/UpTimeNot
Yet Available/div/td
/tr
+ tr
+td class=LightBackground width=20% nowrapGeronimo Version/td
+td class=LightBackground width=80%${svrProps['Geronimo
Version']}/td
+ /tr
/table
br
!--
--
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-1675) Add NNTP transport to the javamail package.
[ http://issues.apache.org/jira/browse/GERONIMO-1675?page=all ] Vamsavardhana Reddy closed GERONIMO-1675. - Add NNTP transport to the javamail package. --- Key: GERONIMO-1675 URL: http://issues.apache.org/jira/browse/GERONIMO-1675 Project: Geronimo Issue Type: New Feature Security Level: public(Regular issues) Components: mail Affects Versions: 1.x Reporter: Rick McGuire Assigned To: Jacek Laskowski Fix For: 1.x Attachments: addr.patch, GERONIMO-1675.patch Add the capability of posting messages to NNTP servers using the javamail API. This is a capability that the Sun version does not currently have. -- 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-1656) Complete implementation of javamail Session class address map loading.
[ http://issues.apache.org/jira/browse/GERONIMO-1656?page=all ] Vamsavardhana Reddy closed GERONIMO-1656. - Complete implementation of javamail Session class address map loading. -- Key: GERONIMO-1656 URL: http://issues.apache.org/jira/browse/GERONIMO-1656 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: mail Affects Versions: 1.x Reporter: Rick McGuire Assigned To: Jacek Laskowski Fix For: 1.x Attachments: GERONIMO-1656.patch The javamail Session class is supposed to be loading address type-transport type mappings from a search order of resources. Currently, this code is only using a hard-coded address map and makes no attempt to load the different property files. -- 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: Deployment Plan -geronimo-web.xml
Hi Jacek What I was referring to was that after a few commits your hard work become harder and harder to keep in sync. It doesn't happen very often that XSDs change, but when they do the documentation will have to be updated as well. It's then better to include that part in the XSDs themselves. Just rise an JIRA issue/task with your patch and it'll be committed on your behalf. Sure.So I'm gonna work in the XSD.txt which comes with the geronimo distribution and presently those XSD's are in lack of documentation.(I have written the xml schema documentation for Gv1.1 and updated the confluence long time back http://cwiki.apache.org/GMOxDOC11/xml-schemas.html) So I'm planning to update the XSD flies come in the distribution as much as in detail with the similar content of the same documentation in the web base(Which I have done already).Please let me know if there is any thing else need to be added in XSD s.Once I complete this task I'll create JIRA Issue and will send the patch.(I hope with out completing this task I can't create an issue or make the task assigned to me isn't it?) Have I interpreted your instructions correctly Jacek? Best Regards Kanchana On 11/2/06, Jacek Laskowski [EMAIL PROTECTED] wrote: On 11/2/06, Kanchana Welagedara [EMAIL PROTECTED] wrote: It's much to do and am not sure whether it's in sync after a few commits. Jacek I'm sorry I didn't understand this part of the mail and can you please kindly explain it bit more to me?Are you referring some JIRA sort of commits? What I was referring to was that after a few commits your hard work become harder and harder to keep in sync. It doesn't happen very often that XSDs change, but when they do the documentation will have to be updated as well. It's then better to include that part in the XSDs themselves. Just rise an JIRA issue/task with your patch and it'll be committed on your behalf. I think we'd be better off if we put the tag documentation into XSDs themselves so XML editors will provide concise information right when necessary. sure Jacek .will do. That's exactly what I meant describing above. Jacek -- Jacek Laskowski http://www.jaceklaskowski.pl
[jira] Closed: (GERONIMO-1712) Add NNTP Store support to javamail
[ http://issues.apache.org/jira/browse/GERONIMO-1712?page=all ] Vamsavardhana Reddy closed GERONIMO-1712. - Add NNTP Store support to javamail -- Key: GERONIMO-1712 URL: http://issues.apache.org/jira/browse/GERONIMO-1712 Project: Geronimo Issue Type: New Feature Security Level: public(Regular issues) Components: mail Affects Versions: 1.2 Reporter: Rick McGuire Assigned To: Jacek Laskowski Fix For: 1.x Attachments: GERONIMO-1712.patch This patch adds a NNTP Store protocol handler to the Geronimo javamail support. -- 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-1705) Use AJAX to provide for a progress bar when downloading a JDBC jar
[ http://issues.apache.org/jira/browse/GERONIMO-1705?page=all ] Vamsavardhana Reddy closed GERONIMO-1705. - Use AJAX to provide for a progress bar when downloading a JDBC jar -- Key: GERONIMO-1705 URL: http://issues.apache.org/jira/browse/GERONIMO-1705 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: console Affects Versions: 1.0 Reporter: Jeff Genender Assigned To: Paul McMahan Fix For: 1.2 Attachments: downloadProgress2.png, GERONIMO-1705.patch, GERONIMO-1705.patch Use AJAX to provide for a progress bar when downloading a JDBC jar for the Download Drivers portlet. As it stands, for people who have slower connections, it currently can make them think something is wrong with Geronimo because web page refresh takes too long. A progrss bar using AJAX can help keep the user up to date on the downloading progress. -- 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-1691) Console should help configure Geronimo to hook up to Apache HTTP
[ http://issues.apache.org/jira/browse/GERONIMO-1691?page=all ] Vamsavardhana Reddy closed GERONIMO-1691. - Console should help configure Geronimo to hook up to Apache HTTP Key: GERONIMO-1691 URL: http://issues.apache.org/jira/browse/GERONIMO-1691 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: console, web Affects Versions: 1.0 Reporter: Aaron Mulder Assigned To: Aaron Mulder Fix For: 1.1 There are a number of steps involved in hooking Geronimo up to Apache HTTP via mod_jk -- getting the module installed, writing a workers.properties, and adding configuration information to the Apache config file (including some for each web application to be exposed). It would be nice if the console could walk you through this. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (AMQ-1021) Release build of ActiveMQ-CPP from trunk with Visual Studio 2005 fails due to Windows headers include order issue
Release build of ActiveMQ-CPP from trunk with Visual Studio 2005 fails due to
Windows headers include order issue
-
Key: AMQ-1021
URL: https://issues.apache.org/activemq/browse/AMQ-1021
Project: ActiveMQ
Issue Type: Bug
Components: CMS (C++ client)
Affects Versions: 4.0.1
Environment: Windows
Reporter: Albert Strasheim
Doing a release build of ActiveMQ-CPP from trunk with Visual Studio 2005
results in the following error when compiling DataInputStreamTest.cpp:
{quote}
1-- Build started: Project: vc2005-activemq-unittests, Configuration:
Release Win32 --
1Compiling...
1DataInputStreamTest.cpp
1f:\activemq-cpp\src\main\activemq/io/ByteArrayInputStream.h(142) : warning
C4244: 'return' : conversion from '__w64 int' to 'int', possible loss of data
1C:\Program Files\Microsoft Platform SDK\Include\Winsock2.h(112) : error
C2011: 'fd_set' : 'struct' type redefinition
1C:\Program Files\Microsoft Platform SDK\Include\winsock.h(54) : see
declaration of 'fd_set'
1C:\Program Files\Microsoft Platform SDK\Include\Winsock2.h(147) : warning
C4005: 'FD_SET' : macro redefinition
1C:\Program Files\Microsoft Platform SDK\Include\winsock.h(88) : see
previous definition of 'FD_SET'
1C:\Program Files\Microsoft Platform SDK\Include\Winsock2.h(156) : error
C2011: 'timeval' : 'struct' type redefinition
1C:\Program Files\Microsoft Platform SDK\Include\winsock.h(97) : see
declaration of 'timeval'
...
{quote}
This error happens when some combination of winsock.h, winsock2.h and windows.h
is included in the wrong order. The following change fixes the problem and
might provide some clue as to what is going on.
{quote}
Index: DataInputStreamTest.h
===
--- DataInputStreamTest.h (revision 470321)
+++ DataInputStreamTest.h (working copy)
@@ -21,10 +21,10 @@
#include cppunit/TestFixture.h
#include cppunit/extensions/HelperMacros.h
+#include activemq/util/Endian.h
#include activemq/exceptions/ActiveMQException.h
#include activemq/io/BufferedInputStream.h
#include activemq/io/ByteArrayInputStream.h
-#include activemq/util/Endian.h
#include activemq/io/DataInputStream.h
#ifdef min
{quote}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://issues.apache.org/activemq/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (GERONIMO-1273) JMS Network Listener add dialogs should give some context information on the protocol.
[ http://issues.apache.org/jira/browse/GERONIMO-1273?page=all ] Vamsavardhana Reddy closed GERONIMO-1273. - Fix Version/s: 1.2 (was: Wish List) Resolution: Fixed JMS Network Listener add dialogs should give some context information on the protocol. -- Key: GERONIMO-1273 URL: http://issues.apache.org/jira/browse/GERONIMO-1273 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: console Affects Versions: 1.0-M5 Reporter: Rick McGuire Priority: Minor Fix For: 1.2 Attachments: 1273-jms-listener-add-dialog.patch The JMS Network Listener add dialogs (add activieio listener, etc) should give some kind of context information rather than presenting the exact dialog for all listener types. This causes a bit of uncertainty on the user's part that the correct operation is being performed. -- 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-1391) Portlet Exception Thrown by generate key pair
[ http://issues.apache.org/jira/browse/GERONIMO-1391?page=all ] Vamsavardhana Reddy closed GERONIMO-1391. - Resolution: Cannot Reproduce Portlet Exception Thrown by generate key pair --- Key: GERONIMO-1391 URL: http://issues.apache.org/jira/browse/GERONIMO-1391 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: console Affects Versions: 1.0-M5 Environment: All Reporter: Anita Kulshreshtha Priority: Minor The following exception can be reproduced by : keystore -- generate key pair -- cancel Geronimo Application Server started 09:15:03,562 ERROR [[Keystore]] Servlet.service() for servlet Keystore threw exception javax.portlet.PortletException at org.apache.geronimo.console.certmanager.actions.GenerateKeyPair.action(GenerateKeyPair.java:83) at org.apache.geronimo.console.certmanager.CertManagerPortlet.processAction(CertManagerPortlet.java:91) at org.apache.pluto.core.PortletServlet.dispatch(PortletServlet.java:229) at org.apache.pluto.core.PortletServlet.doPost(PortletServlet.java:163) at javax.servlet.http.HttpServlet.service(HttpServlet.java:615) at javax.servlet.http.HttpServlet.service(HttpServlet.java:688) at org.apache.pluto.core.PortletServlet.service(PortletServlet.java:153) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173) at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:672) at org.apache.catalina.core.ApplicationDispatcher.doInclude(ApplicationDispatcher.java:574) at org.apache.catalina.core.ApplicationDispatcher.include(ApplicationDispatcher.java:499) at org.apache.pluto.invoker.impl.PortletInvokerImpl.invoke(PortletInvokerImpl.java:120) at org.apache.pluto.invoker.impl.PortletInvokerImpl.action(PortletInvokerImpl.java:68) at org.apache.pluto.PortletContainerImpl.processPortletAction(PortletContainerImpl.java:164) at org.apache.pluto.portalImpl.core.PortletContainerWrapperImpl.processPortletAction(PortletContainerWrapperImpl .java:82) at org.apache.pluto.portalImpl.Servlet.doGet(Servlet.java:227) at org.apache.pluto.portalImpl.Servlet.doPost(Servlet.java:267) at javax.servlet.http.HttpServlet.service(HttpServlet.java:615) at javax.servlet.http.HttpServlet.service(HttpServlet.java:688) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:178) at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:514) at org.apache.geronimo.tomcat.GeronimoStandardContext$SystemMethodValve.invoke(GeronimoStandardContext.java:272) at org.apache.geronimo.tomcat.valve.DefaultSubjectValve.invoke(DefaultSubjectValve.java:46) at org.apache.geronimo.tomcat.valve.PolicyContextValve.invoke(PolicyContextValve.java:50) at org.apache.geronimo.tomcat.valve.TransactionContextValve.invoke(TransactionContextValve.java:53) at org.apache.geronimo.tomcat.valve.ComponentContextValve.invoke(ComponentContextValve.java:47) at org.apache.geronimo.tomcat.valve.InstanceContextValve.invoke(InstanceContextValve.java:60) at org.apache.catalina.core.StandardHostValv e.invoke(StandardHostValve.java:126) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107) at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:541) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:868) at org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection(Http11BaseProtocol.java :663) at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:527) at org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(LeaderFollowerWorkerThread.java:80) at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:684) at java.lang.Thread.run(Thread.java:534) Caused by:
[jira] Assigned: (AMQ-1021) Release build of ActiveMQ-CPP from trunk with Visual Studio 2005 fails due to Windows headers include order issue
[ https://issues.apache.org/activemq/browse/AMQ-1021?page=all ]
Timothy Bish reassigned AMQ-1021:
-
Assignee: Timothy Bish
Release build of ActiveMQ-CPP from trunk with Visual Studio 2005 fails due to
Windows headers include order issue
-
Key: AMQ-1021
URL: https://issues.apache.org/activemq/browse/AMQ-1021
Project: ActiveMQ
Issue Type: Bug
Components: CMS (C++ client)
Affects Versions: 4.0.1
Environment: Windows
Reporter: Albert Strasheim
Assigned To: Timothy Bish
Doing a release build of ActiveMQ-CPP from trunk with Visual Studio 2005
results in the following error when compiling DataInputStreamTest.cpp:
{quote}
1-- Build started: Project: vc2005-activemq-unittests, Configuration:
Release Win32 --
1Compiling...
1DataInputStreamTest.cpp
1f:\activemq-cpp\src\main\activemq/io/ByteArrayInputStream.h(142) : warning
C4244: 'return' : conversion from '__w64 int' to 'int', possible loss of data
1C:\Program Files\Microsoft Platform SDK\Include\Winsock2.h(112) : error
C2011: 'fd_set' : 'struct' type redefinition
1C:\Program Files\Microsoft Platform SDK\Include\winsock.h(54) : see
declaration of 'fd_set'
1C:\Program Files\Microsoft Platform SDK\Include\Winsock2.h(147) : warning
C4005: 'FD_SET' : macro redefinition
1C:\Program Files\Microsoft Platform SDK\Include\winsock.h(88) : see
previous definition of 'FD_SET'
1C:\Program Files\Microsoft Platform SDK\Include\Winsock2.h(156) : error
C2011: 'timeval' : 'struct' type redefinition
1C:\Program Files\Microsoft Platform SDK\Include\winsock.h(97) : see
declaration of 'timeval'
...
{quote}
This error happens when some combination of winsock.h, winsock2.h and
windows.h is included in the wrong order. The following change fixes the
problem and might provide some clue as to what is going on.
{quote}
Index: DataInputStreamTest.h
===
--- DataInputStreamTest.h (revision 470321)
+++ DataInputStreamTest.h (working copy)
@@ -21,10 +21,10 @@
#include cppunit/TestFixture.h
#include cppunit/extensions/HelperMacros.h
+#include activemq/util/Endian.h
#include activemq/exceptions/ActiveMQException.h
#include activemq/io/BufferedInputStream.h
#include activemq/io/ByteArrayInputStream.h
-#include activemq/util/Endian.h
#include activemq/io/DataInputStream.h
#ifdef min
{quote}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://issues.apache.org/activemq/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
important: License issues in Geronimo 1.0 Samples
Sorry to send it again. This is an important issue. Have a look at the
attached file. I have stuck here whether to reuse this sample or not. :-\
Lasantha Ranaweera wrote:
Hi All,
Past few days I have been upgrading JBoss to Apache Geronimo samples
from v1.0 of the documentation to v1.1. As part of the upgrade
procedure, when I was looking at one of the samples I found something
that grabbed my attention in the existing JBoss to Geronimo sample
applications. Have a look at "JBoss to
Geronimo - Security Migration" in following url:
http://cwiki.apache.org/confluence/display/GMOxDOC10/JBoss+to+Geronimo+-+Security+Migration
Source code of this sample contains some proprietary license. So we
can't do any editing this sample. Isn't it?
I'm quite new to the open source model, and AFAIK it should come with
ASF license. Please correct me if I am wrong.
Thanks,
Lasantha Ranaweera
/*
* File: BusinessLogicEJB.java
*
* Date Version Author Changes
* Oct.05,2005 1.1 Ivan Dubrov Created
*
* Copyright (c) 2005, IBM Corporation
* All rights reserved.
*/
package com.ibm.j2g.security;
import java.rmi.RemoteException;
import javax.ejb.EJBException;
import javax.ejb.SessionBean;
import javax.ejb.SessionContext;
/**
* Business logic stateless bean.
*
* @ejb.bean name=BusinessLogic display-name=BusinessLogic bean
* jndi-name=ejb/BusinessLogic type=Stateless view-type=remote
*/
public class BusinessLogicEJB implements SessionBean {
/** Serial version uid. */
private static final long serialVersionUID = 4688250533090120601L;
/**
* @ejb.interface-method
* @ejb.permission role-name = uploader
*
* @return result message
*/
public String upload() {
return File successfully uploaded;
}
/**
* @see javax.ejb.SessionBean#setSessionContext(javax.ejb.SessionContext)
*/
public void setSessionContext(SessionContext ctx) throws EJBException,
RemoteException {
// Nothing...
}
/**
* Create method.
*
* @ejb.create-method
* @ejb.permission unchecked=true
*
* @throws EJBException
* @throws RemoteException
*/
public void ejbCreate() throws EJBException, RemoteException {
// Nothing...
}
/**
* @see javax.ejb.SessionBean#ejbRemove()
*/
public void ejbRemove() throws EJBException, RemoteException {
// Nothing...
}
/**
* @see javax.ejb.SessionBean#ejbActivate()
*/
public void ejbActivate() throws EJBException, RemoteException {
// Nothing...
}
/**
* @see javax.ejb.SessionBean#ejbPassivate()
*/
public void ejbPassivate() throws EJBException, RemoteException {
// Nothing...
}
}
Re: important: License issues in Geronimo 1.0 Samples
Hi Lasantha,
I'm reviewing it now. I worked on this article and at that time did not pay
attention to this license issue. In fact, the earlier releases of these sample
had no license at all.
There are about 3 samples in the same situation, I would encourage you to
continue with the other samples until I found an appropriate solution to this
issue.
The other samples have no license headers so we should add some and also clean
some of the original comments in the src code that were more for our own
tracking purposes.
Thanks a lot for helping out updating these samples.
Cheers!
Hernan
Lasantha Ranaweera wrote:
Sorry to send it again. This is an important issue. Have a look at the
attached file. I have stuck here whether to reuse this sample or not. :-\
Lasantha Ranaweera wrote:
Hi All,
Past few days I have been upgrading JBoss to Apache Geronimo samples
from v1.0 of the documentation to v1.1. As part of the upgrade
procedure, when I was looking at one of the samples I found something
that grabbed my attention in the existing JBoss to Geronimo sample
applications. Have a look at JBoss to Geronimo - Security Migration
in following url:
http://cwiki.apache.org/confluence/display/GMOxDOC10/JBoss+to+Geronimo+-+Security+Migration
Source code of this sample contains some proprietary license. So we
can't do any editing this sample. Isn't it?
I'm quite new to the open source model, and AFAIK it should come with
ASF license. Please correct me if I am wrong.
Thanks,
Lasantha Ranaweera
/*
* File: BusinessLogicEJB.java
*
* Date Version Author Changes
* Oct.05,2005 1.1 Ivan Dubrov Created
*
* Copyright (c) 2005, IBM Corporation
* All rights reserved.
*/
package com.ibm.j2g.security;
import java.rmi.RemoteException;
import javax.ejb.EJBException;
import javax.ejb.SessionBean;
import javax.ejb.SessionContext;
/**
* Business logic stateless bean.
*
* @ejb.bean name=BusinessLogic display-name=BusinessLogic bean
* jndi-name=ejb/BusinessLogic type=Stateless view-type=remote
*/
public class BusinessLogicEJB implements SessionBean {
/** Serial version uid. */
private static final long serialVersionUID = 4688250533090120601L;
/**
* @ejb.interface-method
* @ejb.permission role-name = uploader
*
* @return result message
*/
public String upload() {
return File successfully uploaded;
}
/**
* @see
javax.ejb.SessionBean#setSessionContext(javax.ejb.SessionContext)
*/
public void setSessionContext(SessionContext ctx) throws EJBException,
RemoteException {
// Nothing...
}
/**
* Create method.
*
* @ejb.create-method
* @ejb.permission unchecked=true
*
* @throws EJBException
* @throws RemoteException
*/
public void ejbCreate() throws EJBException, RemoteException {
// Nothing...
}
/**
* @see javax.ejb.SessionBean#ejbRemove()
*/
public void ejbRemove() throws EJBException, RemoteException {
// Nothing...
}
/**
* @see javax.ejb.SessionBean#ejbActivate()
*/
public void ejbActivate() throws EJBException, RemoteException {
// Nothing...
}
/**
* @see javax.ejb.SessionBean#ejbPassivate()
*/
public void ejbPassivate() throws EJBException, RemoteException {
// Nothing...
}
}
[jira] Commented: (AMQ-1021) Release build of ActiveMQ-CPP from trunk with Visual Studio 2005 fails due to Windows headers include order issue
[
https://issues.apache.org/activemq/browse/AMQ-1021?page=comments#action_37343 ]
Timothy Bish commented on AMQ-1021:
---
I've updated the project files and they now build in release mode. Try that
out and see if its works better for you.
Release build of ActiveMQ-CPP from trunk with Visual Studio 2005 fails due to
Windows headers include order issue
-
Key: AMQ-1021
URL: https://issues.apache.org/activemq/browse/AMQ-1021
Project: ActiveMQ
Issue Type: Bug
Components: CMS (C++ client)
Affects Versions: 4.0.1
Environment: Windows
Reporter: Albert Strasheim
Assigned To: Timothy Bish
Doing a release build of ActiveMQ-CPP from trunk with Visual Studio 2005
results in the following error when compiling DataInputStreamTest.cpp:
{quote}
1-- Build started: Project: vc2005-activemq-unittests, Configuration:
Release Win32 --
1Compiling...
1DataInputStreamTest.cpp
1f:\activemq-cpp\src\main\activemq/io/ByteArrayInputStream.h(142) : warning
C4244: 'return' : conversion from '__w64 int' to 'int', possible loss of data
1C:\Program Files\Microsoft Platform SDK\Include\Winsock2.h(112) : error
C2011: 'fd_set' : 'struct' type redefinition
1C:\Program Files\Microsoft Platform SDK\Include\winsock.h(54) : see
declaration of 'fd_set'
1C:\Program Files\Microsoft Platform SDK\Include\Winsock2.h(147) : warning
C4005: 'FD_SET' : macro redefinition
1C:\Program Files\Microsoft Platform SDK\Include\winsock.h(88) : see
previous definition of 'FD_SET'
1C:\Program Files\Microsoft Platform SDK\Include\Winsock2.h(156) : error
C2011: 'timeval' : 'struct' type redefinition
1C:\Program Files\Microsoft Platform SDK\Include\winsock.h(97) : see
declaration of 'timeval'
...
{quote}
This error happens when some combination of winsock.h, winsock2.h and
windows.h is included in the wrong order. The following change fixes the
problem and might provide some clue as to what is going on.
{quote}
Index: DataInputStreamTest.h
===
--- DataInputStreamTest.h (revision 470321)
+++ DataInputStreamTest.h (working copy)
@@ -21,10 +21,10 @@
#include cppunit/TestFixture.h
#include cppunit/extensions/HelperMacros.h
+#include activemq/util/Endian.h
#include activemq/exceptions/ActiveMQException.h
#include activemq/io/BufferedInputStream.h
#include activemq/io/ByteArrayInputStream.h
-#include activemq/util/Endian.h
#include activemq/io/DataInputStream.h
#ifdef min
{quote}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://issues.apache.org/activemq/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: important: License issues in Geronimo 1.0 Samples
do we have a script to add the license info automatically that I could use for the samples? Cheers! Hernan Kevan Miller wrote: On Nov 2, 2006, at 10:26 AM, Hernan Cunico wrote: Lasantha, those samples were donated to the project ergo they should only display ASF2 license. This is the text we have in trunk today !-- Copyright 2006 The Apache Software Foundation Licensed under the Apache License, Version 2.0 (the License); you may not use this file except in compliance with the License. You may obtain a copy of the License at http://www.apache.org/licenses/LICENSE-2.0 Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an AS IS BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License. -- Could you please remove the unnecessary (old) data and comments and add the appropriate lines to each of the files for all the samples you are updating. Lasantha should not be *removing* copyright statements from a source file. The copyright holder should do that (i.e. someone from ibm). In this case, it sounds like that has already been done. If that's true, then Lasantha should just pick up the latest source. FYI, http://www.apache.org/legal/src-headers.html contains the current policy regarding source headers/license/copyright info. Source headers should not contain copyright statements and the license text has been updated. Lasantha, Thanks for identifying this issue. --kevan
Re: Unable to build trunk from clean repo
nevermind, something was corrupt in my repo, I deleted the genesis dir from the repo and was able to get past the problem.On Nov 2, 2006, at 12:00 PM, Sachin Patel wrote:After cleaning out my maven repo, I'm unable to build trunk as it fails immediately with...[INFO] [ERROR] FATAL ERROR[INFO] [INFO] Failed to resolve artifact.GroupId: org.apache.geronimo.genesis.configArtifactId: project-configVersion: 1.1-SNAPSHOTReason: Unable to download the artifact from any repository org.apache.geronimo.genesis.config:project-config:pom:1.1-SNAPSHOTfrom the specified remote repositories: central (http://repo1.maven.org/maven2), apache-snapshots (http://people.apache.org/repo/m2-snapshot-repository)[INFO] [INFO] Traceorg.apache.maven.reactor.MavenExecutionException: Cannot find parent: org.apache.geronimo.genesis.config:project-config for project: org.apache.geronimo:geronimo:pom:1.2-SNAPSHOT at org.apache.maven.DefaultMaven.getProjects(DefaultMaven.java:365) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:278) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:115) at org.apache.maven.cli.MavenCli.main(MavenCli.java:256) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) at org.codehaus.classworlds.Launcher.main(Launcher.java:375)Caused by: org.apache.maven.project.ProjectBuildingException: Cannot find parent: org.apache.geronimo.genesis.config:project-config for project: org.apache.geronimo:geronimo:pom:1.2-SNAPSHOT at org.apache.maven.project.DefaultMavenProjectBuilder.assembleLineage(DefaultMavenProjectBuilder.java:1161) at org.apache.maven.project.DefaultMavenProjectBuilder.buildInternal(DefaultMavenProjectBuilder.java:674) at org.apache.maven.project.DefaultMavenProjectBuilder.buildFromSourceFileInternal(DefaultMavenProjectBuilder.java:416) at org.apache.maven.project.DefaultMavenProjectBuilder.build(DefaultMavenProjectBuilder.java:192) at org.apache.maven.DefaultMaven.getProject(DefaultMaven.java:515) at org.apache.maven.DefaultMaven.collectProjects(DefaultMaven.java:447) at org.apache.maven.DefaultMaven.getProjects(DefaultMaven.java:351) ... 11 moreCaused by: org.apache.maven.project.ProjectBuildingException: POM 'org.apache.geronimo.genesis.config:project-config' not found in repository: Unable to download the artifact from any repository org.apache.geronimo.genesis.config:project-config:pom:1.1-SNAPSHOTfrom the specified remote repositories: central (http://repo1.maven.org/maven2), apache-snapshots (http://people.apache.org/repo/m2-snapshot-repository) at org.apache.maven.project.DefaultMavenProjectBuilder.findModelFromRepository(DefaultMavenProjectBuilder.java:513) at org.apache.maven.project.DefaultMavenProjectBuilder.assembleLineage(DefaultMavenProjectBuilder.java:1157) ... 17 moreCaused by: org.apache.maven.artifact.resolver.ArtifactNotFoundException: Unable to download the artifact from any repository org.apache.geronimo.genesis.config:project-config:pom:1.1-SNAPSHOTfrom the specified remote repositories: central (http://repo1.maven.org/maven2), apache-snapshots (http://people.apache.org/repo/m2-snapshot-repository) at org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolve(DefaultArtifactResolver.java:136) at org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolve(DefaultArtifactResolver.java:63) at org.apache.maven.project.DefaultMavenProjectBuilder.findModelFromRepository(DefaultMavenProjectBuilder.java:467) ... 18 moreCaused by: org.apache.maven.wagon.ResourceDoesNotExistException: Unable to download the artifact from any repository at org.apache.maven.artifact.manager.DefaultWagonManager.getArtifact(DefaultWagonManager.java:260) at org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolve(DefaultArtifactResolver.java:124) ... 20 more[INFO] [INFO] Total time: 1 second[INFO] Finished at: Thu Nov 02 11:59:08 EST 2006[INFO] Final Memory: 1M/508M[INFO] -sachin -sachin
Java EE 5 sandbox
It appears that sandbox/javaee5 is the location that we should be using to integrate various EE 5 items until 1.2 is released. Therefore, I thought I would post some information that I've learned (and problems that I've encountered) here since I supposed others are or soon will be doing the same thing. Perhaps somebody has some information that might help get around some of problems listed below (such as when Jetty snapshots might be published?). First, this is a feature branch. To use it you must first build trunk to populate your local repository. Next you must checkout https://svn.apache.org/repos/asf/geronimo/sandbox/javaee5 and build it. However, in doing the last step you'll hit some problems: - The Jetty 6.1 snapshots are not published anywhere yet (at least not anywhere I've been able to find them). Therefore, you will need to build Jetty 6.1 locally. Can somebody related to both Geronimo and Jetty help us to get the Jetty 6.1 snapshots published? Building Jetty: - You can check out Jetty from http://svn.codehaus.org/jetty/jetty/trunk Jetty requires cvs to build (in case you don't already have it). For me the build failed because of test failures but it appeared to create the jetty jars that we need. After building Jetty you should be ready to build the javaee5 branch. Of course, this build requires JDK 1.5 - Next I hit a problem building javaee5. Apparently there have been some changes in Jetty since the original integration in the branch. It appears that the Jetty Session object may have changed. Here is the error I received: [ERROR] BUILD FAILURE [INFO] [INFO] Compilation failure C:\javaee5\modules-jee5\geronimo-jetty6\src\main\java\org\apache\geronimo\jetty6\cluster\ClusteredSessionManager.java:[94,12] cannot find symbol symbol : constructor Session(nulltype,java.lang.String) location: class org.mortbay.jetty.servlet.AbstractSessionManager.Session I then spoke with David Jencks and he told me the revision of Jetty that he used when he first created the branch. That was revision 1064. So, I checked out this Jetty revision but with this one the build fails earlier with this error 2006-11-02 11:48:40.687::WARN: failed [EMAIL PROTECTED] java.io.IOException: Cannot write log directory C:\tmp at org.mortbay.util.RolloverFileOutputStream.setFile(RolloverFileOutputStream.java:131) at org.mortbay.util.RolloverFileOutputStream.init(RolloverFileOutputStream.java:88) at org.mortbay.jetty.NCSARequestLog.doStart(NCSARequestLog.java:363) at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:39) at org.mortbay.jetty.handler.RequestLogHandler.doStart(RequestLogHandler.java:116) . I'll let you know as I resolve these issues in case you too need to work on the JavaEE5 branch. Thanks, Joe
Re: important: License issues in Geronimo 1.0 Samples
Hi Hernan,
I can't add those modifications to the samples with propriety licenses,
you know it is not illegal and ethical :(. Sure I can add this Apache
licence to the samples I had written.
Also one more question. Can I add this license to other existing samples?
Somewhere I heard we can't change the distributed license to any other
license. Confluence is bit different than JIRA, nobody accepts ASF
licences before their commiting. I haven't come across this situation at
all. Please help.
Thanks,
Lasantha Ranaweera
Lasantha,
those samples were donated to the project ergo they should only display
ASF2 license.
This is the text we have in trunk today
!--
Copyright 2006 The Apache Software Foundation
Licensed under the Apache License, Version 2.0 (the License);
you may not use this file except in compliance with the License.
You may obtain a copy of the License at
http://www.apache.org/licenses/LICENSE-2.0
Unless required by applicable law or agreed to in writing, software
distributed under the License is distributed on an AS IS BASIS,
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or
implied.
See the License for the specific language governing permissions and
limitations under the License.
--
Could you please remove the unnecessary (old) data and comments and add
the appropriate lines to each of the files for all the samples you are
updating.
http://www.apache.org/licenses may give you some additional tips.
Thanks for taking care of this.
Cheers!
Hernan
Lasantha Ranaweera wrote:
Sorry to send it again. This is an important issue. Have a look at the
attached file. I have stuck here whether to reuse this sample or not.
:-\
Lasantha Ranaweera wrote:
Hi All,
Past few days I have been upgrading JBoss to Apache Geronimo samples
from v1.0 of the documentation to v1.1. As part of the upgrade
procedure, when I was looking at one of the samples I found something
that grabbed my attention in the existing JBoss to Geronimo sample
applications. Have a look at JBoss to Geronimo - Security Migration
in following url:
http://cwiki.apache.org/confluence/display/GMOxDOC10/JBoss+to+Geronimo+-+Security+Migration
Source code of this sample contains some proprietary license. So we
can't do any editing this sample. Isn't it?
I'm quite new to the open source model, and AFAIK it should come with
ASF license. Please correct me if I am wrong.
Thanks,
Lasantha Ranaweera
/*
* File: BusinessLogicEJB.java
*
* Date Version Author Changes
* Oct.05,2005 1.1 Ivan Dubrov Created
*
* Copyright (c) 2005, IBM Corporation
* All rights reserved.
*/
package com.ibm.j2g.security;
import java.rmi.RemoteException;
import javax.ejb.EJBException;
import javax.ejb.SessionBean;
import javax.ejb.SessionContext;
/**
* Business logic stateless bean.
*
* @ejb.bean name=BusinessLogic display-name=BusinessLogic bean
* jndi-name=ejb/BusinessLogic type=Stateless
view-type=remote
*/
public class BusinessLogicEJB implements SessionBean {
/** Serial version uid. */
private static final long serialVersionUID = 4688250533090120601L;
/**
* @ejb.interface-method
* @ejb.permission role-name = uploader
*
* @return result message
*/
public String upload() {
return File successfully uploaded;
}
/**
* @see
javax.ejb.SessionBean#setSessionContext(javax.ejb.SessionContext)
*/
public void setSessionContext(SessionContext ctx) throws EJBException,
RemoteException {
// Nothing...
}
/**
* Create method.
*
* @ejb.create-method
* @ejb.permission unchecked=true
*
* @throws EJBException
* @throws RemoteException
*/
public void ejbCreate() throws EJBException, RemoteException {
// Nothing...
}
/**
* @see javax.ejb.SessionBean#ejbRemove()
*/
public void ejbRemove() throws EJBException, RemoteException {
// Nothing...
}
/**
* @see javax.ejb.SessionBean#ejbActivate()
*/
public void ejbActivate() throws EJBException, RemoteException {
// Nothing...
}
/**
* @see javax.ejb.SessionBean#ejbPassivate()
*/
public void ejbPassivate() throws EJBException, RemoteException {
// Nothing...
}
}
[jira] Closed: (GERONIMO-2341) EditableConfigurationManager problems!!???!!!!
[ http://issues.apache.org/jira/browse/GERONIMO-2341?page=all ] Vamsavardhana Reddy closed GERONIMO-2341. - Resolution: Fixed Fixed. Rev 470430 (branches\1.1) and Rev 470437 (trunk). EditableConfigurationManager problems!!??? -- Key: GERONIMO-2341 URL: http://issues.apache.org/jira/browse/GERONIMO-2341 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: kernel Affects Versions: 1.2, 1.1, 1.1.1, 1.1.2 Reporter: Vamsavardhana Reddy Priority: Critical Fix For: 1.1.2, 1.2 Attachments: GERONIMO-2341.patch Here are a few problems I noticed. 1. Delete a network listener (Jetty Web/Tomcat Web/JMS) thru administration console and the listener showsup after server restart. 2. Stop any network listener, the listener is started automatically at server restart (Related JIRA GERONIMO-2340) I think these problems have been fixed several times in the past. But the problem still remains. It will be a big relief I am wrong and this JIRA is invalid. -- 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: important: License issues in Geronimo 1.0 Samples
Hi Kevan, Thanks for your description. It cleared some of my doubts regarding this issue. Thanks, Lasantha Ranaweera On Nov 2, 2006, at 10:26 AM, Hernan Cunico wrote: Lasantha, those samples were donated to the project ergo they should only display ASF2 license. This is the text we have in trunk today !-- Copyright 2006 The Apache Software Foundation Licensed under the Apache License, Version 2.0 (the License); you may not use this file except in compliance with the License. You may obtain a copy of the License at http://www.apache.org/licenses/LICENSE-2.0 Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an AS IS BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License. -- Could you please remove the unnecessary (old) data and comments and add the appropriate lines to each of the files for all the samples you are updating. Lasantha should not be *removing* copyright statements from a source file. The copyright holder should do that (i.e. someone from ibm). In this case, it sounds like that has already been done. If that's true, then Lasantha should just pick up the latest source. FYI, http://www.apache.org/legal/src-headers.html contains the current policy regarding source headers/license/copyright info. Source headers should not contain copyright statements and the license text has been updated. Lasantha, Thanks for identifying this issue. --kevan
Re: important: License issues in Geronimo 1.0 Samples
Hi Hernan,
I felt this is yet another issue created by confluence. That is because
people can contribute to the Geronimo project not accepting ASF licenses.
If the contributors are working with the JIRA then they have to accept ASF
license with each and every patch (if they like to contribute to the
project). Is there any way to give this functionality to the confluence
too? Anyway I am not a fan of confluence than JIRA to get contributions to
an open source project, hear are my points regarding it (may be this
horse has been beaten to dead several times by this same community ;-) ).
First I will start from it's positives. Yeah I accept it will give very
nice presentation to the users with some very good inbuilt capabilities
(pdf export etc etc).
The point I am against here is using it directly to get the user
contributions. Here are some the points come to my mind.
1. License issues like above might occur because of the contributors are
not accepting ASF licenses. Also it will not promote the ASF licenses. I
think you all will understand the importance of ASF licenses to the open
source community.
(This is one of the major promotion slogans of Geronimo too ;-) )
2. Visibility of the work done in the confluence is limited to a very few
developers because most of the developers are working with the JIRA. I am
not sure this is the best way to handle a community driven project like
Geronimo.
3. Nobody is going to create JIRA issues regarding documentation issues.
So according to my understanding documentation will not improve from
starting. There is noway to submit a patches to the existing bugs of the
documentation (then we might have to get the help of JIRA).
4. I am sure people like tech writers, graphic editors, translators etc.
are part of an open source project contributors (I heard some of the
Apache members start their work as tech writers). In this kind of
environment they will not get the credit they deserve too.
Comments
Thanks,
Lasantha Ranaweera
Lasantha,
those samples were donated to the project ergo they should only display
ASF2 license.
This is the text we have in trunk today
!--
Copyright 2006 The Apache Software Foundation
Licensed under the Apache License, Version 2.0 (the License);
you may not use this file except in compliance with the License.
You may obtain a copy of the License at
http://www.apache.org/licenses/LICENSE-2.0
Unless required by applicable law or agreed to in writing, software
distributed under the License is distributed on an AS IS BASIS,
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or
implied.
See the License for the specific language governing permissions and
limitations under the License.
--
Could you please remove the unnecessary (old) data and comments and add
the appropriate lines to each of the files for all the samples you are
updating.
http://www.apache.org/licenses may give you some additional tips.
Thanks for taking care of this.
Cheers!
Hernan
Lasantha Ranaweera wrote:
Sorry to send it again. This is an important issue. Have a look at the
attached file. I have stuck here whether to reuse this sample or not.
:-\
Lasantha Ranaweera wrote:
Hi All,
Past few days I have been upgrading JBoss to Apache Geronimo samples
from v1.0 of the documentation to v1.1. As part of the upgrade
procedure, when I was looking at one of the samples I found something
that grabbed my attention in the existing JBoss to Geronimo sample
applications. Have a look at JBoss to Geronimo - Security Migration
in following url:
http://cwiki.apache.org/confluence/display/GMOxDOC10/JBoss+to+Geronimo+-+Security+Migration
Source code of this sample contains some proprietary license. So we
can't do any editing this sample. Isn't it?
I'm quite new to the open source model, and AFAIK it should come with
ASF license. Please correct me if I am wrong.
Thanks,
Lasantha Ranaweera
/*
* File: BusinessLogicEJB.java
*
* Date Version Author Changes
* Oct.05,2005 1.1 Ivan Dubrov Created
*
* Copyright (c) 2005, IBM Corporation
* All rights reserved.
*/
package com.ibm.j2g.security;
import java.rmi.RemoteException;
import javax.ejb.EJBException;
import javax.ejb.SessionBean;
import javax.ejb.SessionContext;
/**
* Business logic stateless bean.
*
* @ejb.bean name=BusinessLogic display-name=BusinessLogic bean
* jndi-name=ejb/BusinessLogic type=Stateless
view-type=remote
*/
public class BusinessLogicEJB implements SessionBean {
/** Serial version uid. */
private static final long serialVersionUID = 4688250533090120601L;
/**
* @ejb.interface-method
[jira] Closed: (GERONIMO-2404) Edit HTTPS Connector page does not display the connector name
[ http://issues.apache.org/jira/browse/GERONIMO-2404?page=all ] Vamsavardhana Reddy closed GERONIMO-2404. - Resolution: Fixed Fixed. Rev 470444 (branches\1.1) and Rev 470446 (trunk). Edit HTTPS Connector page does not display the connector name - Key: GERONIMO-2404 URL: http://issues.apache.org/jira/browse/GERONIMO-2404 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: console Affects Versions: 1.1.1 Environment: G 1.1.1 Reporter: Vamsavardhana Reddy Priority: Minor Fix For: 1.1.2, 1.1.x, 1.2 Attachments: GERONIMO-2404-v1.1.x.patch, GERONIMO-2404-v1.2.patch, GERONIMO-2404.patch Edit HTTPS Connector page does not display the connector name while editing an existing HTTPS connector. -- 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: important: License issues in Geronimo 1.0 Samples
Lasantha,
I either wrote or co-authored all those docs and the headers in question
skipped my attention at that time.
I know for sure they were not there in the first releases of those samples as we were developing them. Apparently those headers were added at a later time.
Either way those samples as well as the entire documentation were made
available in JIRA GERONIMO-1357 granting ASL to all the content. But clicking
the ASL check box in JIRA does not add any license info to the attached files.
As for Confluence itself, in the autoexported version you can read at the bottom of each
page Copyright © 2003-2006, The Apache Software Foundation. Maybe this is not
enough.
Confluence is just a wiki and there is no way (without major surgery) to modify the attachments page so we can click an ASL check box. Even if there is one there would be no chance to add any ASL related info to the actual files.
I don't know what the solution would be so I'm open to suggestions.
Cheers!
Hernan
[EMAIL PROTECTED] wrote:
Hi Hernan,
I can't add those modifications to the samples with propriety licenses,
you know it is not illegal and ethical :(. Sure I can add this Apache
licence to the samples I had written.
Also one more question. Can I add this license to other existing samples?
Somewhere I heard we can't change the distributed license to any other
license. Confluence is bit different than JIRA, nobody accepts ASF
licences before their commiting. I haven't come across this situation at
all. Please help.
Thanks,
Lasantha Ranaweera
Lasantha,
those samples were donated to the project ergo they should only display
ASF2 license.
This is the text we have in trunk today
!--
Copyright 2006 The Apache Software Foundation
Licensed under the Apache License, Version 2.0 (the License);
you may not use this file except in compliance with the License.
You may obtain a copy of the License at
http://www.apache.org/licenses/LICENSE-2.0
Unless required by applicable law or agreed to in writing, software
distributed under the License is distributed on an AS IS BASIS,
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or
implied.
See the License for the specific language governing permissions and
limitations under the License.
--
Could you please remove the unnecessary (old) data and comments and add
the appropriate lines to each of the files for all the samples you are
updating.
http://www.apache.org/licenses may give you some additional tips.
Thanks for taking care of this.
Cheers!
Hernan
Lasantha Ranaweera wrote:
Sorry to send it again. This is an important issue. Have a look at the
attached file. I have stuck here whether to reuse this sample or not.
:-\
Lasantha Ranaweera wrote:
Hi All,
Past few days I have been upgrading JBoss to Apache Geronimo samples
from v1.0 of the documentation to v1.1. As part of the upgrade
procedure, when I was looking at one of the samples I found something
that grabbed my attention in the existing JBoss to Geronimo sample
applications. Have a look at JBoss to Geronimo - Security Migration
in following url:
http://cwiki.apache.org/confluence/display/GMOxDOC10/JBoss+to+Geronimo+-+Security+Migration
Source code of this sample contains some proprietary license. So we
can't do any editing this sample. Isn't it?
I'm quite new to the open source model, and AFAIK it should come with
ASF license. Please correct me if I am wrong.
Thanks,
Lasantha Ranaweera
/*
* File: BusinessLogicEJB.java
*
* Date Version Author Changes
* Oct.05,2005 1.1 Ivan Dubrov Created
*
* Copyright (c) 2005, IBM Corporation
* All rights reserved.
*/
package com.ibm.j2g.security;
import java.rmi.RemoteException;
import javax.ejb.EJBException;
import javax.ejb.SessionBean;
import javax.ejb.SessionContext;
/**
* Business logic stateless bean.
*
* @ejb.bean name=BusinessLogic display-name=BusinessLogic bean
* jndi-name=ejb/BusinessLogic type=Stateless
view-type=remote
*/
public class BusinessLogicEJB implements SessionBean {
/** Serial version uid. */
private static final long serialVersionUID = 4688250533090120601L;
/**
* @ejb.interface-method
* @ejb.permission role-name = uploader
*
* @return result message
*/
public String upload() {
return File successfully uploaded;
}
/**
* @see
javax.ejb.SessionBean#setSessionContext(javax.ejb.SessionContext)
*/
public void setSessionContext(SessionContext ctx) throws EJBException,
RemoteException {
// Nothing...
}
/**
* Create method.
[jira] Closed: (GERONIMO-2539) car-maven-plugin should allow more stuff into manifest classpath
[ http://issues.apache.org/jira/browse/GERONIMO-2539?page=all ] David Jencks closed GERONIMO-2539. -- Resolution: Fixed Assignee: David Jencks Sachin committed a solution. I added a comment to the online-deployer pom in rev 470452. car-maven-plugin should allow more stuff into manifest classpath Key: GERONIMO-2539 URL: http://issues.apache.org/jira/browse/GERONIMO-2539 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: buildsystem Affects Versions: 1.2 Reporter: David Jencks Assigned To: David Jencks Fix For: 1.2 Attachments: GERONIMO-2539.patch In the m1 build online-deployer config which turns into deployer.jar has a manifest cp entry for server.jar which let the offline deployer work. This is missing from the m2 build. I think I'm going to need something similar for runtime class enhancement for jpa. I've come up with a patch to car-maven-plugin that lets you add arbitrary aliases for dependencies. I'd prefer some review before committing. -- 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 these errors due to changes in genesis logging ?
components.xml with a new lifecycle for site http://people.apache.org/~prasad/components.xml When I used to run the 'mvn -e -X site' command on the test-deployment pom (packaging integration-test), it used to fail with the following exception [DEBUG] Error looking up lifecycle mapping to retrieve optional mojos. Lifecycle ID: site. Error: Component descriptor cannot be found in the component repository: org.apache.maven.lifecycle.mapping.LifecycleMappingintegration-test. org.codehaus.plexus.component.repository.exception.ComponentLookupException: Component descriptor cannot be found in the component repository: org.apache.maven.lifecycle.mapping.LifecycleMappingintegration-test. Seems like the plugin extensions of the tools-plugin isn't being recognised for site. Then I added the build extension in the test-deployment pom and the above exception disappeared ! Today, I have begun to get the following stacktrace for the same pom - org.apache.commons.logging.LogConfigurationException: Invalid class loader hierarchy. You have more than one version of 'org.apache.commons.logging.Log' visible, which is not allowed. (Caused by org.apache.commons.logging.LogConfigurationException: Invalid class loader hierarchy. You have more than one version of 'org.apache.commons.logging.Log' visible, which is not allowed.)) at org.apache.commons.logging.impl.LogFactoryImpl.newInstance(LogFactoryImpl.java:543) at org.apache.commons.logging.impl.LogFactoryImpl.getInstance(LogFactoryImpl.java:235) at org.apache.commons.logging.impl.LogFactoryImpl.getInstance(LogFactoryImpl.java:209) at org.apache.commons.logging.LogFactory.getLog(LogFactory.java:351) at org.apache.geronimo.genesis.logging.Logging.reset(Logging.java:53) at org.apache.geronimo.genesis.MojoSupport.execute(MojoSupport.java:142) This exception goes away if I remove the build extension. Did something change in genesis logging recently ? Are there any changes I should make to fix this ? PS. I deleted the o.a.g tree in local repo, did a svn update and then a 'mvn clean install' top down. Cheers Prasad
Re: important: License issues in Geronimo 1.0 Samples
[EMAIL PROTECTED] wrote: 1. License issues like above might occur because of the contributors are not accepting ASF licenses. Also it will not promote the ASF licenses. I think you all will understand the importance of ASF licenses to the open source community. I may be wrong, but I think the issue of license on content added to the wiki came up before and it was stated that content added to wiki is (by the nature of wikis) automatically freely available to everyone for any use. It may be a good idea to put an official license policy onto the wiki though. That way, there should hopefully not be any future questions about permissible use to it's content or the license that applies. Here is an excerpt from the license/copyright page from Wikipedia (http://en.wikipedia.org/wiki/Wikipedia:Copyrights): excerpt Contributors' rights and obligations If you contribute material to Wikipedia, you thereby license it to the public under the GFDL (with no invariant sections, front-cover texts, or back-cover texts). In order to contribute, you therefore must be in a position to grant this license, which means that either * you own the copyright to the material, for instance because you produced it yourself, or * you acquired the material from a source that allows the licensing under GFDL, for instance because the material is in the public domain http://en.wikipedia.org/wiki/Public_domain or is itself published under GFDL. In the first case, you retain copyright to your materials. You can later republish and relicense them in any way you like. However, you can never retract the GFDL license for the versions you placed here: that material will remain under GFDL forever. In the second case, if you incorporate external GFDL materials, as a requirement of the GFDL, you need to acknowledge the authorship and provide a link back to the network location of the original copy. /excerpt Jay
Re: important: License issues in Geronimo 1.0 Samples
If those sample are added with JIRA then it won't be that much of big
problem because contributor knows it goes under ASL. I thought it might
have added as the current way of confluence itself. Even though it might
not add the license information to the source code I think it is very
important to let the contributor know that they are donating their
materials under ASL. JIRA handles that issue atleast ;).
Thanks,
Lasantha Ranaweera
Lasantha,
I either wrote or co-authored all those docs and the headers in question
skipped my attention at that time.
I know for sure they were not there in the first releases of those samples
as we were developing them. Apparently those headers were added at a later
time.
Either way those samples as well as the entire documentation were made
available in JIRA GERONIMO-1357 granting ASL to all the content. But
clicking the ASL check box in JIRA does not add any license info to the
attached files.
As for Confluence itself, in the autoexported version you can read at the
bottom of each page Copyright © 2003-2006, The Apache Software
Foundation. Maybe this is not enough.
Confluence is just a wiki and there is no way (without major surgery) to
modify the attachments page so we can click an ASL check box. Even if
there is one there would be no chance to add any ASL related info to the
actual files.
I don't know what the solution would be so I'm open to suggestions.
Cheers!
Hernan
[EMAIL PROTECTED] wrote:
Hi Hernan,
I can't add those modifications to the samples with propriety licenses,
you know it is not illegal and ethical :(. Sure I can add this Apache
licence to the samples I had written.
Also one more question. Can I add this license to other existing
samples?
Somewhere I heard we can't change the distributed license to any other
license. Confluence is bit different than JIRA, nobody accepts ASF
licences before their commiting. I haven't come across this situation at
all. Please help.
Thanks,
Lasantha Ranaweera
Lasantha,
those samples were donated to the project ergo they should only display
ASF2 license.
This is the text we have in trunk today
!--
Copyright 2006 The Apache Software Foundation
Licensed under the Apache License, Version 2.0 (the License);
you may not use this file except in compliance with the License.
You may obtain a copy of the License at
http://www.apache.org/licenses/LICENSE-2.0
Unless required by applicable law or agreed to in writing, software
distributed under the License is distributed on an AS IS BASIS,
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or
implied.
See the License for the specific language governing permissions and
limitations under the License.
--
Could you please remove the unnecessary (old) data and comments and add
the appropriate lines to each of the files for all the samples you are
updating.
http://www.apache.org/licenses may give you some additional tips.
Thanks for taking care of this.
Cheers!
Hernan
Lasantha Ranaweera wrote:
Sorry to send it again. This is an important issue. Have a look at the
attached file. I have stuck here whether to reuse this sample or not.
:-\
Lasantha Ranaweera wrote:
Hi All,
Past few days I have been upgrading JBoss to Apache Geronimo samples
from v1.0 of the documentation to v1.1. As part of the upgrade
procedure, when I was looking at one of the samples I found something
that grabbed my attention in the existing JBoss to Geronimo sample
applications. Have a look at JBoss to Geronimo - Security Migration
in following url:
http://cwiki.apache.org/confluence/display/GMOxDOC10/JBoss+to+Geronimo+-+Security+Migration
Source code of this sample contains some proprietary license. So we
can't do any editing this sample. Isn't it?
I'm quite new to the open source model, and AFAIK it should come with
ASF license. Please correct me if I am wrong.
Thanks,
Lasantha Ranaweera
/*
* File: BusinessLogicEJB.java
*
* Date Version Author Changes
* Oct.05,2005 1.1 Ivan Dubrov Created
*
* Copyright (c) 2005, IBM Corporation
* All rights reserved.
*/
package com.ibm.j2g.security;
import java.rmi.RemoteException;
import javax.ejb.EJBException;
import javax.ejb.SessionBean;
import javax.ejb.SessionContext;
/**
* Business logic stateless bean.
*
* @ejb.bean name=BusinessLogic display-name=BusinessLogic bean
* jndi-name=ejb/BusinessLogic type=Stateless
view-type=remote
*/
public class BusinessLogicEJB implements SessionBean {
/** Serial version uid. */
private static final long serialVersionUID = 4688250533090120601L;
/**
* @ejb.interface-method
Re: Java EE 5 sandbox
On Nov 2, 2006, at 9:18 AM, Joe Bohn wrote: It appears that sandbox/javaee5 is the location that we should be using to integrate various EE 5 items until 1.2 is released. Therefore, I thought I would post some information that I've learned (and problems that I've encountered) here since I supposed others are or soon will be doing the same thing. Perhaps somebody has some information that might help get around some of problems listed below (such as when Jetty snapshots might be published?). First, this is a feature branch. To use it you must first build trunk to populate your local repository. Next you must checkout https://svn.apache.org/repos/asf/geronimo/sandbox/javaee5 and build it. However, in doing the last step you'll hit some problems: - The Jetty 6.1 snapshots are not published anywhere yet (at least not anywhere I've been able to find them). Therefore, you will need to build Jetty 6.1 locally. Can somebody related to both Geronimo and Jetty help us to get the Jetty 6.1 snapshots published? They are currently available at http://jetty.mortbay.org/maven2/snapshot however I am encouraging jan to publish them to the codehaus snapshot repo. I think we can wait a day or two for this rather than adding another repo to the list. Building Jetty: - You can check out Jetty from http://svn.codehaus.org/jetty/jetty/ trunkJetty requires cvs to build (in case you don't already have it). For me the build failed because of test failures but it appeared to create the jetty jars that we need. After building Jetty you should be ready to build the javaee5 branch. Of course, this build requires JDK 1.5 - Next I hit a problem building javaee5. Apparently there have been some changes in Jetty since the original integration in the branch. It appears that the Jetty Session object may have changed. Here is the error I received: -- -- [ERROR] BUILD FAILURE [INFO] -- -- [INFO] Compilation failure C:\javaee5\modules-jee5\geronimo-jetty6\src\main\java\org\apache \geronimo\jetty6\cluster\ClusteredSessionManager.java:[94,12] cannot find symbol symbol : constructor Session(nulltype,java.lang.String) location: class org.mortbay.jetty.servlet.AbstractSessionManager.Session I committed a change to this class to work with current jetty 6.1 I then spoke with David Jencks and he told me the revision of Jetty that he used when he first created the branch. That was revision 1064. So, I checked out this Jetty revision but with this one the build fails earlier with this error 2006-11-02 11:48:40.687::WARN: failed [EMAIL PROTECTED] java.io.IOException: Cannot write log directory C:\tmp at org.mortbay.util.RolloverFileOutputStream.setFile (RolloverFileOutputStream.java:131) at org.mortbay.util.RolloverFileOutputStream.init (RolloverFileOutputStream.java:88) at org.mortbay.jetty.NCSARequestLog.doStart (NCSARequestLog.java:363) at org.mortbay.component.AbstractLifeCycle.start (AbstractLifeCycle.java:39) at org.mortbay.jetty.handler.RequestLogHandler.doStart (RequestLogHandler.java:116) . I haven't seen this. I'll let you know as I resolve these issues in case you too need to work on the JavaEE5 branch. thanks david it works on my machine jencks Thanks, Joe
[jira] Created: (GERONIMO-2540) Naming builders do not see classes located in a war in an ear
Naming builders do not see classes located in a war in an ear - Key: GERONIMO-2540 URL: http://issues.apache.org/jira/browse/GERONIMO-2540 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Components: naming Reporter: Dain Sundstrom Assigned To: Dain Sundstrom When building ejb references that class loader of the outer ear is used instead of the module class loader. This means that the naming builder will not be able to see the war classes. This problem also occurs in the other naming builders. -- 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-2443) Import CA reply should match the public key in the keystore with that in the certificate from CA.
[ http://issues.apache.org/jira/browse/GERONIMO-2443?page=all ] Vamsavardhana Reddy closed GERONIMO-2443. - Resolution: Fixed Fixed. Rev 470461 (trunk) and Rev 470470 (branches\1.1) Import CA reply should match the public key in the keystore with that in the certificate from CA. - Key: GERONIMO-2443 URL: http://issues.apache.org/jira/browse/GERONIMO-2443 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: security Affects Versions: 1.2, 1.1.1 Environment: G1.1.1 Reporter: Vamsavardhana Reddy Fix For: 1.1.2, 1.2 Attachments: GERONIMO-2443-v1.2.patch While importing CA reply into the keystore, the public key in the certificate issued by the CA should be matched with the public key that is currently in the keystore. java.securtiy.KeyStore.setKeyEntry does not complain if the privateKey and the publicKey in the certificate are not related An accidental import of a certificate corresponding to one public key along with an unrelated private key renders the key pair useless and results in errors while using the certificate. -- 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-2540) Naming builders do not see classes located in a war in an ear
[ http://issues.apache.org/jira/browse/GERONIMO-2540?page=all ] Dain Sundstrom closed GERONIMO-2540. Resolution: Fixed Naming builders do not see classes located in a war in an ear - Key: GERONIMO-2540 URL: http://issues.apache.org/jira/browse/GERONIMO-2540 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: naming Reporter: Dain Sundstrom Assigned To: Dain Sundstrom When building ejb references that class loader of the outer ear is used instead of the module class loader. This means that the naming builder will not be able to see the war classes. This problem also occurs in the other naming builders. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: 1.2 Fit and Finish
OK I had a hunch something might break but I figured I would ask anyway just in case there was a way. For now I can probably manufacture a reasonable test env on my local machine but as the server gets more componentized as plugins I think it will become more important to test the system as a whole before releasing. To me that means base server, plugins, and plugin repos bits are all tested in the same configuration that a user will see when the release is announced. BTW, we're close to the point where you can install the framework assembly and then use the CLI to slurp in the admin console and all its dependencies from the 1.2 plugin repo at http://geronimo.apache.org/plugins/geronimo-1.2/. Looking forward I'm excited about the new possibilities this opens up for us in how we release. Best wishes, Paul On 11/1/06, Dain Sundstrom [EMAIL PROTECTED] wrote: It isn't really possible to publish a 1.2 release like that. It would break lots of stuff (like maven) that assumes that there will only ever be a single 1.2 release. Why can't you test against a 1.2- timestamp release? -dain On Nov 1, 2006, at 5:55 AM, Paul McMahan wrote: One of the activities to coordinate when finalizing the release is updating the 1.2 plugin repository catalog at: http://geronimo.apache.org/plugins/geronimo-1.2/geronimo-plugins.xml to point at a repo where the 1.2 artifacts are published instead of the snapshot repo it currently points at. For testing purposes it would be ideal to build Geronimo as version 1.2 (not 1.2rc1 or 1.2.timestamp or something like that) and publish the 1.2 artifacts to a maven2 repo during the release candidate cycle. That would allow us to test the plugin system in pretty much the exact state it will be when 1.2 is released. Is that feasible? If not then we may need to work out an alternate approach where the repository catalog gets updated after the release goes out and the artifacts get published. That makes me a little nervous though since it will be too late to make changes to the server if something doesn't work right. Best wishes, Paul On 10/30/06, Dain Sundstrom [EMAIL PROTECTED] wrote: In a typical Geronimo release we tend to spend a significant amount of time in what I'll call the Fit and Finish phase. This involves tying up loose ends such as log levels, tools LF, startup times, licenses and so on. Basically, the phase includes fixing all the nits that cause people to vote -1 for a release (BTW no vetos in a release vote). Please, take a moment and respond to this email with any items you feel should be cleaned up before we release the software. That way we can hopefully get these items out in the open and addressed while we are finishing the TCK testing. Please note that just because an item is mentioned doesn't mean it must be completed before a release. The only thing required for a release it to successfully pass a vote of the PMC, so if the item is critical to you, spend a few minutes fixing it. With any luck we should be able to have the server ready to ship about the same time we finish the TCK testing. -dain
Re: Failover Protocol
Combining failover and asynchronous sends as suggested doesn't work either, it appears only failover configuration items are expected there. Limiting the retry count worked great, the send returns quickly when a broker is not available. This allows me to restart things, shut down the application, and/or notify someone there is a problem. Adrian Co wrote: Hi, Try: failover:(tcp://remotehost:61616,tcp://localhost:61616)?jms.useAsyncSend=true Regarding the blocking part: It could be blocking because of the failover transport, as it keeps retrying to connect to one of the brokers. I'd try setting the retry count and the retry interval to a smaller value. ronK wrote: I am looking for a way to have my clients failover to alternate brokers, use asynchronous sends, and keep my client code vanilla JMS. It appears you can't use the failover transport and set connection properties via the uri at the same time. What I would like to do is combine failover:(tcp://localhost:61616,tcp://remotehost:61616) with tcp://localhost:61616?jms.useAsyncSend=true but it doesn't seem to work. i.e. failover:(tcp://localhost:61616?jms.useAsyncSend=true,tcp://remotehost:61616?jms.useAsyncSend=true) Anyone know if this is supposed to work? The documentation says: The good news is that ActiveMQ sends message in async mode by default in several cases. It is only in cases where the JMS specification required the use of sync sending that we default to sync sending. The cases that we are forced to send in sync mode are when persistent messages are being sent outside of a transaction. This doesn't appear to be entirely true because when I attempt to use the NON_PERSISTENT mode, send() still blocks if no brokers are available. When this happens I can't shut the program down or notify anyone there is a problem. Note, the ttl of the message can expire and the send() remains blocked. If I could somehow stop the send() I could have another thread monitor it and stop it if necessary. Lots of things seem to block that shouldn't, you can't build robust software if you can't shut things down and restart them when you suspect something is out of wack. Ron -- View this message in context: http://www.nabble.com/Failover-Protocol-tf2549326.html#a7144086 Sent from the ActiveMQ - Dev mailing list archive at Nabble.com.
[jira] Commented: (GERONIMO-2436) FileKeystoreInstance.generateKeyPair() should check if the keystore is loaded
[ http://issues.apache.org/jira/browse/GERONIMO-2436?page=comments#action_12446700 ] Vamsavardhana Reddy commented on GERONIMO-2436: --- Fixed in trunk as part of GERONIMO-2504. FileKeystoreInstance.generateKeyPair() should check if the keystore is loaded - Key: GERONIMO-2436 URL: http://issues.apache.org/jira/browse/GERONIMO-2436 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: security Affects Versions: 1.1.1, 1.2 Reporter: Vamsavardhana Reddy Fix For: 1.1.2, 1.2 Attachments: GERONIMO-2436-v1.1.x-correctone.patch, GERONIMO-2436-v1.1.x.patch, GERONIMO-2436-v1.2.patch I have the following code: KeystoreInstance ks = PortletManager.getCurrentServer(request).getKeystoreManager().createKeystore(mykeystore, password); ks.unlockKeystore(password); ks.generateKeyPair(alias, password, password, keyAlgorithm, keySize, algorithm, 365, cn, ou, o, l, st, c); The generateKeyPair() call is resulting in NullPointerException since the newly created keystore is not readily loaded and generateKeyPair() is not checking if the keystore is loaded. generateKeyPair() should check and load the keystore if necessary. -- 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: Time to remove bootstrap
I agree that bootstrap has served its purpose and can be eliminated. Thanks for the work you did on it. It helped us through some rough times :-) Paul On 11/1/06, Jason Dillon [EMAIL PROTECTED] wrote: Yesterday, I tried to build G with mvn alone after removing my local repository and it works fine... now that the specs and openejb2 snaps are deployed. I have not really even used bootstrap in a many weeks... and I think its time for it to go away. So... unless someone objects strongly (and soonish) I am gonna nuke it. --jason
[jira] Closed: (GERONIMO-2436) FileKeystoreInstance.generateKeyPair() should check if the keystore is loaded
[ http://issues.apache.org/jira/browse/GERONIMO-2436?page=all ] Vamsavardhana Reddy closed GERONIMO-2436. - Resolution: Fixed Fixed. Rev 470482 (branches\1.1) FileKeystoreInstance.generateKeyPair() should check if the keystore is loaded - Key: GERONIMO-2436 URL: http://issues.apache.org/jira/browse/GERONIMO-2436 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: security Affects Versions: 1.1.1, 1.2 Reporter: Vamsavardhana Reddy Fix For: 1.1.2, 1.2 Attachments: GERONIMO-2436-v1.1.x-correctone.patch, GERONIMO-2436-v1.1.x.patch, GERONIMO-2436-v1.2.patch I have the following code: KeystoreInstance ks = PortletManager.getCurrentServer(request).getKeystoreManager().createKeystore(mykeystore, password); ks.unlockKeystore(password); ks.generateKeyPair(alias, password, password, keyAlgorithm, keySize, algorithm, 365, cn, ou, o, l, st, c); The generateKeyPair() call is resulting in NullPointerException since the newly created keystore is not readily loaded and generateKeyPair() is not checking if the keystore is loaded. generateKeyPair() should check and load the keystore if necessary. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: 1.2 Fit and Finish
On Nov 2, 2006, at 11:08 AM, Paul McMahan wrote: OK I had a hunch something might break but I figured I would ask anyway just in case there was a way. For now I can probably manufacture a reasonable test env on my local machine but as the server gets more componentized as plugins I think it will become more important to test the system as a whole before releasing. To me that means base server, plugins, and plugin repos bits are all tested in the same configuration that a user will see when the release is announced. I'm not so sure about that. We already have a hard enough time release Geronimo because of all the bits we throw into the server bucket. I'm concerned that if we decide to delay the server to make sure plugins run, we will never get a release out. -dain
Re: 1.2 Fit and Finish
On 11/2/06, Dain Sundstrom [EMAIL PROTECTED] wrote: On Nov 2, 2006, at 11:08 AM, Paul McMahan wrote: OK I had a hunch something might break but I figured I would ask anyway just in case there was a way. For now I can probably manufacture a reasonable test env on my local machine but as the server gets more componentized as plugins I think it will become more important to test the system as a whole before releasing. To me that means base server, plugins, and plugin repos bits are all tested in the same configuration that a user will see when the release is announced. I'm not so sure about that. We already have a hard enough time release Geronimo because of all the bits we throw into the server bucket. I'm concerned that if we decide to delay the server to make sure plugins run, we will never get a release out. -dain I see your point. It comes down to how critical the plugin infrastructure is to the release, and right now that's debatable. Let's just continue to innovate and see where that road takes us :-) Best wishes, Paul
Catching exceptions
Just for fun a made a little script that searched the activemq source for a catch blocks with no code or comments inside them. I was somewhat disturbed to find that there were hundreds of these throughout the code, many that are catching on Throwable. There are 58 in activemq-core/src/main/java alone. It seems to me that at the very least these should log the exception to DEBUG, so as to provide some viability. Is there some reason this has not been done? signature.asc Description: OpenPGP digital signature
[jira] Closed: (GERONIMO-2343) tomcat does not use maxPostSize set in config.xml
[ http://issues.apache.org/jira/browse/GERONIMO-2343?page=all ]
Vamsavardhana Reddy closed GERONIMO-2343.
-
Resolution: Fixed
Fixed. Rev 470493 (trunk) and Rev 470494 (branches\1.1).
tomcat does not use maxPostSize set in config.xml
-
Key: GERONIMO-2343
URL: http://issues.apache.org/jira/browse/GERONIMO-2343
Project: Geronimo
Issue Type: Bug
Security Level: public(Regular issues)
Components: Tomcat
Affects Versions: 1.2, 1.1, 1.1.1, 1.1.2
Reporter: Krishnakumar B
Fix For: 1.1.2, 1.2
Attachments: tomcat-maxPostSize.patch
I set a value for maxPostSize in config.xml
gbean name=TomcatWebConnector
attribute name=host0.0.0.0/attribute
attribute name=port8080/attribute
attribute name=redirectPort8443/attribute
attribute name=bufferSizeBytes2048/attribute
attribute name=maxThreads150/attribute
attribute name=acceptQueueSize100/attribute
attribute name=lingerMillis-1/attribute
attribute name=tcpNoDelaytrue/attribute
attribute name=minSpareThreads25/attribute
attribute name=maxSpareThreads75/attribute
attribute name=maxHttpHeaderSizeBytes8192/attribute
attribute name=hostLookupEnabledfalse/attribute
attribute name=connectionTimeoutMillis2/attribute
attribute name=uploadTimeoutEnabledfalse/attribute
attribute name=maxPostSize20/attribute
attribute name=maxSavePostSize4096/attribute
attribute name=emptySessionPathfalse/attribute
/gbean
Tomcat Connector uses the value set in Connector to check for POST size.
if (len 0) {
int maxPostSize = connector.getMaxPostSize();
if ((maxPostSize 0) (len maxPostSize)) {
context.getLogger().info
(sm.getString(coyoteRequest.postTooLarge));
throw new IllegalStateException(Post too large);
}
While in Connector GBean setAttribute does not set in Connector
connector.setAttribute(maxPostSize, new Integer(bytes));
This is set in hashtable in HTTP11Protocol Handler. As a result the default
value is maintained in connector ( 2097152 )
This fix uses setter method in connector to set this value. (
connector.setMaxPostSize(bytes) )
--
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-734) Drools 3.0 Service Engine
Drools 3.0 Service Engine - Key: SM-734 URL: https://issues.apache.org/activemq/browse/SM-734 Project: ServiceMix Issue Type: New Feature Components: servicemix-drools Reporter: Guillaume Nodet Assigned To: Guillaume Nodet Fix For: 3.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
Builders and jpa
I'm working on support for runtime class enhancement for jpa and have run into a gbean start order issue. The PersistenceProvider implementation class can install a byte code transformer that will enhance the classes used in the app for jpa PersistenceCapable. This needs to be done before any application classes are loaded. I think the gbean that starts the PersistenceProvider needs to be in the same configuration as the app, so I think it needs to be arranged that that gbean starts more or less first. Dain suggested that we could implement this by giving GBeanData a priority order and starting them consistent with the priority order. The dependencies will still override the priority order but this will provide easier hints about the desired start order. GBeanInfo can include a default priority order. We can eventually let you set the priority order in a gbean plan. I've opened GERONIMO-2541 to track this.
[jira] Created: (GERONIMO-2541) Priority order for GBeans
Priority order for GBeans - Key: GERONIMO-2541 URL: http://issues.apache.org/jira/browse/GERONIMO-2541 Project: Geronimo Issue Type: Improvement Security Level: public (Regular issues) Components: kernel Affects Versions: 1.2 Reporter: David Jencks Assigned To: David Jencks Fix For: 1.2 Add a priority order to GBeanData to order attempted starts of GBeans. GBeanInfo can have a default. GBean dependencies will still override the priority, in that a priority ordering will determine the order in which we try to start gbeans, but one won't start until all its dependencies have started. This will probably be useful in several contexts but right now I need to get the PersistenceUnitGBean to start first so it can install the class enhancer before any classes are loaded. -- 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: Builders and jpa
Instead of leaving it up to GBeans to handle, do you think we should just put a hook into the Configuration where you can specify byte code transformers that it will apply to the Configuration ClassLoader? Now that the transformer API is there, I'm surmising that JPA may not be the only area where this specific issue may crop up. Thanks, Aaron On 11/2/06, David Jencks [EMAIL PROTECTED] wrote: I'm working on support for runtime class enhancement for jpa and have run into a gbean start order issue. The PersistenceProvider implementation class can install a byte code transformer that will enhance the classes used in the app for jpa PersistenceCapable. This needs to be done before any application classes are loaded. I think the gbean that starts the PersistenceProvider needs to be in the same configuration as the app, so I think it needs to be arranged that that gbean starts more or less first. Dain suggested that we could implement this by giving GBeanData a priority order and starting them consistent with the priority order. The dependencies will still override the priority order but this will provide easier hints about the desired start order. GBeanInfo can include a default priority order. We can eventually let you set the priority order in a gbean plan. I've opened GERONIMO-2541 to track this.
[jira] Closed: (GERONIMO-2348) Tomcat ConnectorGBean does not handle attribute values properly
[ http://issues.apache.org/jira/browse/GERONIMO-2348?page=all ] Vamsavardhana Reddy closed GERONIMO-2348. - Fix Version/s: (was: 1.1.x) Resolution: Fixed Fixed. Rev 470501 (branches\1.1) and Rev 470503 (trunk). Tomcat ConnectorGBean does not handle attribute values properly --- Key: GERONIMO-2348 URL: http://issues.apache.org/jira/browse/GERONIMO-2348 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: Tomcat Affects Versions: 1.1, 1.0, 1.1.1 Environment: Win XP, Geronimo Tomcat 1.1.1-SNAPSHOT Reporter: Vamsavardhana Reddy Fix For: 1.1.2, 1.2 Attachments: GERONIMO-2348.patch, http11protocol.patch Tomcat ConnectorGBean does not handle the following attributes properly. 1. hostLookupEnabled 2. redirectPort 3. maxSavePostSize 4. useBodyEncodingForURI There may be other attributes that are not handled properly as well. So, far I have confirmed the above list. I will continue investigation and update the list. A similar problem GERONIMO-2343 is observed and fixed by Krishnakumar B. And the fix is also similar. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (SM-734) Drools 3.0 Service Engine
[ https://issues.apache.org/activemq/browse/SM-734?page=all ] Guillaume Nodet resolved SM-734. Resolution: Fixed Author: gnodet Date: Thu Nov 2 12:08:11 2006 New Revision: 470499 URL: http://svn.apache.org/viewvc?view=revrev=470499 Log: SM-734: Drools 3.0 Service Engine The SE has currently only been tested with routing, where the SE acts as a proxy to a dynamically selected target Added: incubator/servicemix/trunk/servicemix-drools/ (with props) incubator/servicemix/trunk/servicemix-drools/pom.xml incubator/servicemix/trunk/servicemix-drools/src/ incubator/servicemix/trunk/servicemix-drools/src/main/ incubator/servicemix/trunk/servicemix-drools/src/main/java/ incubator/servicemix/trunk/servicemix-drools/src/main/java/org/ incubator/servicemix/trunk/servicemix-drools/src/main/java/org/apache/ incubator/servicemix/trunk/servicemix-drools/src/main/java/org/apache/servicemix/ incubator/servicemix/trunk/servicemix-drools/src/main/java/org/apache/servicemix/drools/ incubator/servicemix/trunk/servicemix-drools/src/main/java/org/apache/servicemix/drools/DroolsComponent.java incubator/servicemix/trunk/servicemix-drools/src/main/java/org/apache/servicemix/drools/DroolsEndpoint.java incubator/servicemix/trunk/servicemix-drools/src/main/java/org/apache/servicemix/drools/model/ incubator/servicemix/trunk/servicemix-drools/src/main/java/org/apache/servicemix/drools/model/Exchange.java incubator/servicemix/trunk/servicemix-drools/src/main/java/org/apache/servicemix/drools/model/Fault.java incubator/servicemix/trunk/servicemix-drools/src/main/java/org/apache/servicemix/drools/model/JbiHelper.java incubator/servicemix/trunk/servicemix-drools/src/main/java/org/apache/servicemix/drools/model/Message.java incubator/servicemix/trunk/servicemix-drools/src/main/java/org/apache/servicemix/drools/package.html incubator/servicemix/trunk/servicemix-drools/src/main/resources/ incubator/servicemix/trunk/servicemix-drools/src/main/resources/META-INF/ incubator/servicemix/trunk/servicemix-drools/src/main/resources/META-INF/DISCLAIMER incubator/servicemix/trunk/servicemix-drools/src/main/resources/META-INF/LICENSE incubator/servicemix/trunk/servicemix-drools/src/main/resources/META-INF/NOTICE incubator/servicemix/trunk/servicemix-drools/src/test/ incubator/servicemix/trunk/servicemix-drools/src/test/java/ incubator/servicemix/trunk/servicemix-drools/src/test/java/org/ incubator/servicemix/trunk/servicemix-drools/src/test/java/org/apache/ incubator/servicemix/trunk/servicemix-drools/src/test/java/org/apache/servicemix/ incubator/servicemix/trunk/servicemix-drools/src/test/java/org/apache/servicemix/drools/ incubator/servicemix/trunk/servicemix-drools/src/test/java/org/apache/servicemix/drools/DroolsComponentTest.java incubator/servicemix/trunk/servicemix-drools/src/test/resources/ incubator/servicemix/trunk/servicemix-drools/src/test/resources/router.drl Drools 3.0 Service Engine - Key: SM-734 URL: https://issues.apache.org/activemq/browse/SM-734 Project: ServiceMix Issue Type: New Feature Components: servicemix-drools Reporter: Guillaume Nodet Assigned To: Guillaume Nodet Fix For: 3.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: Builders and jpa
On Nov 2, 2006, at 12:15 PM, Aaron Mulder wrote: Instead of leaving it up to GBeans to handle, do you think we should just put a hook into the Configuration where you can specify byte code transformers that it will apply to the Configuration ClassLoader? Now that the transformer API is there, I'm surmising that JPA may not be the only area where this specific issue may crop up. I don't really see how this is attached to a particular classloader -- probably my limited understanding of what's going on. I'm using the instrumentation stuff to install the enhancers and have an agent with a TransformerCollection that the jpa enhancers get added to. In particular I don't see how to add this directly to the configuration since we don't know what the enhancer is going to be until we create a PersistenceProvider and it registers it with the PersistenceUnitInfo. If you want to peek at my code before I get it completely working let me know and I'll create a patch. thanks david jencks Thanks, Aaron On 11/2/06, David Jencks [EMAIL PROTECTED] wrote: I'm working on support for runtime class enhancement for jpa and have run into a gbean start order issue. The PersistenceProvider implementation class can install a byte code transformer that will enhance the classes used in the app for jpa PersistenceCapable. This needs to be done before any application classes are loaded. I think the gbean that starts the PersistenceProvider needs to be in the same configuration as the app, so I think it needs to be arranged that that gbean starts more or less first. Dain suggested that we could implement this by giving GBeanData a priority order and starting them consistent with the priority order. The dependencies will still override the priority order but this will provide easier hints about the desired start order. GBeanInfo can include a default priority order. We can eventually let you set the priority order in a gbean plan. I've opened GERONIMO-2541 to track this.
Re: important: License issues in Geronimo 1.0 Samples
I think you pretty much nailed it, thanks ;-) I'll work on something and put a link on the Geronimo cwiki home page (we can't cover all the pages) Cheers! Hernan Jay D. McHugh wrote: [EMAIL PROTECTED] wrote: 1. License issues like above might occur because of the contributors are not accepting ASF licenses. Also it will not promote the ASF licenses. I think you all will understand the importance of ASF licenses to the open source community. I may be wrong, but I think the issue of license on content added to the wiki came up before and it was stated that content added to wiki is (by the nature of wikis) automatically freely available to everyone for any use. It may be a good idea to put an official license policy onto the wiki though. That way, there should hopefully not be any future questions about permissible use to it's content or the license that applies. Here is an excerpt from the license/copyright page from Wikipedia (http://en.wikipedia.org/wiki/Wikipedia:Copyrights): excerpt Contributors' rights and obligations If you contribute material to Wikipedia, you thereby license it to the public under the GFDL (with no invariant sections, front-cover texts, or back-cover texts). In order to contribute, you therefore must be in a position to grant this license, which means that either * you own the copyright to the material, for instance because you produced it yourself, or * you acquired the material from a source that allows the licensing under GFDL, for instance because the material is in the public domain http://en.wikipedia.org/wiki/Public_domain or is itself published under GFDL. In the first case, you retain copyright to your materials. You can later republish and relicense them in any way you like. However, you can never retract the GFDL license for the versions you placed here: that material will remain under GFDL forever. In the second case, if you incorporate external GFDL materials, as a requirement of the GFDL, you need to acknowledge the authorship and provide a link back to the network location of the original copy. /excerpt Jay
Re: important: License issues in Geronimo 1.0 Samples
[EMAIL PROTECTED] wrote: Hi Hernan, I felt this is yet another issue created by confluence. That is because people can contribute to the Geronimo project not accepting ASF licenses. If the contributors are working with the JIRA then they have to accept ASF license with each and every patch (if they like to contribute to the project). Is there any way to give this functionality to the confluence As I said in an earlier note, clicking a checkbox will not address the issue of having some files with some pre-existing license or credits information. too? Anyway I am not a fan of confluence than JIRA to get contributions to an open source project, hear are my points regarding it (may be this horse has been beaten to dead several times by this same community ;-) ). Not to dead, looks like it's still kicking ;-) First I will start from it's positives. Yeah I accept it will give very nice presentation to the users with some very good inbuilt capabilities (pdf export etc etc). The point I am against here is using it directly to get the user contributions. Here are some the points come to my mind. That's exactly the point for using a wiki, so everybody can contribute. Collaboration 1. License issues like above might occur because of the contributors are not accepting ASF licenses. Also it will not promote the ASF licenses. I think you all will understand the importance of ASF licenses to the open source community. There should not be any licensing related issues, we are talking about documentation. I grant that a vast majority of the articles in the documentation contain some sort of examples and most of those examples are also available as attachments. I would not be happy if we need to change the current method for contributing to the doc with a more strict one (i.e. restricted edit access) so we can avoid this kind of issues. That will, IMO, make it even harder for new contributors trying to provide some docs. (This is one of the major promotion slogans of Geronimo too ;-) ) 2. Visibility of the work done in the confluence is limited to a very few developers because most of the developers are working with the JIRA. I am not sure this is the best way to handle a community driven project like Geronimo. Not sure I follow what you are saying ...visibility of the work done in the confluence is limited... I think the wiki has more visibility than any other media. Can you expand a bit more 3. Nobody is going to create JIRA issues regarding documentation issues. So according to my understanding documentation will not improve from starting. There is noway to submit a patches to the existing bugs of the documentation (then we might have to get the help of JIRA). Using JIRA is not going to enhance nor leverage more community building around the documentation. However it may help to track some articles and its versions but there will be no revisions in sync with the current Confluence content. Again, not sure I understand your concern about ...documentation will not improve from starting... You don't need an issue tracking system to get feedback on the documentation. There are a lot of folks chiming in and either send an email with comments or go directly to the wiki and fix some typos for example. That's the beauty of the wiki, everybody can collaborate and contribute improve the documentation. 4. I am sure people like tech writers, graphic editors, translators etc. are part of an open source project contributors (I heard some of the Apache members start their work as tech writers). In this kind of environment they will not get the credit they deserve too. Now this is the horse we beat to dead ;-) we have had endless discussions about this subject over a long period of time and I think we tried every possible recipe available. If you are concerned about the visibility of the articles you contribute then I would encourage you to do the same thing you would do if you were posting the same article anywhere else. Talk about it, let us (the community) know what you've worked on. Don't let an automatic email do it for you, it would probably get filtered ;-) HTH Cheers! Hernan Comments Thanks, Lasantha Ranaweera Lasantha, those samples were donated to the project ergo they should only display ASF2 license. This is the text we have in trunk today !-- Copyright 2006 The Apache Software Foundation Licensed under the Apache License, Version 2.0 (the License); you may not use this file except in compliance with the License. You may obtain a copy of the License at http://www.apache.org/licenses/LICENSE-2.0 Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an AS IS BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License. -- Could you please
Re: important: License issues in Geronimo 1.0 Samples
As I said, I worked with other folks on those samples and I submitted the patch into JIRA granting ASL, that's why I asked you if you could fix the headers in the docs you were updating. I wasn't asking for anything weird as you suggested in a previous email, but you're right, I should probably go fix all those src myself. I will work on a doc about granting license to ASF for all the docs and attachments and put a link on Geronimo's cwiki homepage. The license issue does not apply only to the samples but to the doc and images altogether. Cheers! Hernan [EMAIL PROTECTED] wrote: If those sample are added with JIRA then it won't be that much of big problem because contributor knows it goes under ASL. I thought it might have added as the current way of confluence itself. Even though it might not add the license information to the source code I think it is very important to let the contributor know that they are donating their materials under ASL. JIRA handles that issue atleast ;). Thanks, Lasantha Ranaweera Lasantha, I either wrote or co-authored all those docs and the headers in question skipped my attention at that time. I know for sure they were not there in the first releases of those samples as we were developing them. Apparently those headers were added at a later time. Either way those samples as well as the entire documentation were made available in JIRA GERONIMO-1357 granting ASL to all the content. But clicking the ASL check box in JIRA does not add any license info to the attached files. As for Confluence itself, in the autoexported version you can read at the bottom of each page Copyright © 2003-2006, The Apache Software Foundation. Maybe this is not enough. Confluence is just a wiki and there is no way (without major surgery) to modify the attachments page so we can click an ASL check box. Even if there is one there would be no chance to add any ASL related info to the actual files. I don't know what the solution would be so I'm open to suggestions. Cheers! Hernan [EMAIL PROTECTED] wrote: Hi Hernan, I can't add those modifications to the samples with propriety licenses, you know it is not illegal and ethical :(. Sure I can add this Apache licence to the samples I had written. Also one more question. Can I add this license to other existing samples? Somewhere I heard we can't change the distributed license to any other license. Confluence is bit different than JIRA, nobody accepts ASF licences before their commiting. I haven't come across this situation at all. Please help. Thanks, Lasantha Ranaweera Lasantha, those samples were donated to the project ergo they should only display ASF2 license. This is the text we have in trunk today !-- Copyright 2006 The Apache Software Foundation Licensed under the Apache License, Version 2.0 (the License); you may not use this file except in compliance with the License. You may obtain a copy of the License at http://www.apache.org/licenses/LICENSE-2.0 Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an AS IS BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License. -- Could you please remove the unnecessary (old) data and comments and add the appropriate lines to each of the files for all the samples you are updating. http://www.apache.org/licenses may give you some additional tips. Thanks for taking care of this. Cheers! Hernan Lasantha Ranaweera wrote: Sorry to send it again. This is an important issue. Have a look at the attached file. I have stuck here whether to reuse this sample or not. :-\ Lasantha Ranaweera wrote: Hi All, Past few days I have been upgrading JBoss to Apache Geronimo samples from v1.0 of the documentation to v1.1. As part of the upgrade procedure, when I was looking at one of the samples I found something that grabbed my attention in the existing JBoss to Geronimo sample applications. Have a look at JBoss to Geronimo - Security Migration in following url: http://cwiki.apache.org/confluence/display/GMOxDOC10/JBoss+to+Geronimo+-+Security+Migration Source code of this sample contains some proprietary license. So we can't do any editing this sample. Isn't it? I'm quite new to the open source model, and AFAIK it should come with ASF license. Please correct me if I am wrong. Thanks, Lasantha Ranaweera /* * File: BusinessLogicEJB.java * * Date Version Author Changes * Oct.05,2005 1.1 Ivan Dubrov Created * * Copyright (c) 2005, IBM Corporation * All rights reserved. */ package com.ibm.j2g.security; import
