Re: Virtual Hosts
Aaron Mulder wrote: It would be saying something like, there must be a GBean to represent a virtual host, and that GBean must have a set of host names associated with it, and any application can be associated with that defined virtual host. For Tomcat, this would be effectively a HostGBean with all that entails. For Jetty, it would be a GBean holding a list of Strings that get applied as virtual hosts when the app is associated with that defined virtual host. Can we modify this to: there must be a GBean to represent a HOST, and that GBean must have a set of host names AND a set of aliases (virtual host names) associated with it. Any applicaton can be associated with that defined HOST. For Tomcat, this would be effectively a HostHBean with all that entails. For Jetty it would be a GBean holding a list of string that get applied as hosts and a list of strings that get applied as virtual hosts when the app is associated with that defined HOST. cheers
[jira] Assigned: (GERONIMO-1513) The directory geronimo-1.0\lib\extension does not match the Extension-Dirs: lib/ext value in server.jar's manifest.mf file
[ http://issues.apache.org/jira/browse/GERONIMO-1513?page=all ] John Sisson reassigned GERONIMO-1513: - Assign To: John Sisson The directory geronimo-1.0\lib\extension does not match the Extension-Dirs: lib/ext value in server.jar's manifest.mf file -- Key: GERONIMO-1513 URL: http://issues.apache.org/jira/browse/GERONIMO-1513 Project: Geronimo Type: Bug Components: buildsystem, startup/shutdown Versions: 1.0.1 Reporter: John Sisson Assignee: John Sisson Priority: Minor Fix For: 1.0.1, 1.1 The geronimo-1.0\lib\extension directory does not match the directory name in the META-INF/Manifest.mf file contained in the geronimo-1.0\bin\server.jar file. The manifest specifies lib/ext (not lib/extension). The 1.0 manifest file currently contains the following: Manifest-Version: 1.0 Class-Path: ../lib/geronimo-qname_1.1_spec-1.0.jar ../lib/geronimo-com mon-1.0.jar ../lib/geronimo-kernel-1.0.jar ../lib/geronimo-system-1.0 .jar ../lib/geronimo-util-1.0.jar ../lib/cglib-nodep-2.1_3.jar ../lib /commons-cli-1.0.jar ../lib/commons-logging-1.0.4.jar ../lib/log4j-1. 2.8.jar ../lib/mx4j-3.0.1.jar ../lib/mx4j-remote-3.0.1.jar ../lib/end orsed/xercesImpl-2.6.2.jar ../lib/endorsed/xmlParserAPIs-2.2.1.jar Main-Class: org.apache.geronimo.system.main.Daemon Endorsed-Dirs: lib/endorsed Extension-Dirs: lib/ext We need to change the directory in the distribution (not the manifest.mf file) to be lib/ext (to be consistent with the value specified in the manifest file, and also to be consisten with the naming of the directory in a JRE). -- 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: Dealing with multiple GBeans
Another issue you don't show all your code but you will have a
much easier time matching names if you include the j2eeType in both
the reference specifications and the GBeanInfoBuider constructor
infoFactory.addReference(APrinter,APrinterGBean.class,
NameFactory.GERONIMO_SERVICE);
infoFactory.addReference(BPrinter,BPrinterGBean.class,
NameFactory.GERONIMO_SERVICE);
GBeanInfoBuilder infoFactory = GBeanInfoBuilder.createStatic
(FooGBean.class, NameFactory.GERONIMO_SERVICE);
hope this helps
david jencks
On Jan 19, 2006, at 12:20 PM, David Jencks wrote:
I think you have named your printer gbeans with keys name=gbean1
and name=gbean2 but the references expect them to be named
name=APrinterGBean and name=BPrinterGBean.
You can look in var/log/geronimo.log for debug messages about why
MyGBean didn't start: it will tell you what it is looking for. You
might need to adjust the log level to include DEBUG level.
thanks
david jencks
On Jan 19, 2006, at 11:44 AM, Nelson A. Perez wrote:
Hi All,
With you help I have been developing a small
application. The goal is very simple, we have 3
GBeans: MyGBean, APrinterGBean and BPrinterGBean.
MyGBean invokes a print operation on the two
printers which it references and gets via dependency
injection.
MyGBean prints MyGBean when started. For the other
two GBeans, they have public print operations that
when invoked (by MyGBean in this case) they output
APrinterGBean and BPrinterGBean respectively. So,
if all were working correctly, we would see the
sequence:
MyGBean
APrinterGBean
BPrinterGBean
If I run MyGBean without referencing any of the
printer GBeans, I get the correct message: MyGBean.
However, when I do handle the references for
APrinterGBean and BPrinterGBean, I am able to compile
and deploy the configuratiion plan successfuly, but
only APrinterGBean and BPrinterGBean get started and
as a result nothing gets printed. It is puzzling that
it seems to be working fine, but MyGBean just doesn't
get started, because if it were, we would see the
sequence of the three messages:
MyGBean
APrinterGBean
BPrinterGBean
Any idea on why this is happening ? It all seems to be
done properly, so I am a bit surprised. The
configuration plan that I am using is:
?xml version=1.0 encoding=UTF-8?
configuration
xmlns=http://geronimo.apache.org/xml/ns/deployment;
configId=task/SampleTask
dependency
groupIdsamples/groupId
artifactIdtask/artifactId
version1.0/version
/dependency
gbean name=gbean1 class=task.APrinterGBean
/gbean
gbean name=gbean2 class=task.BPrinterGBean
/gbean
!--
gbean name=DefaultThreadPool
class=org.apache.geronimo.pool.ThreadPool
attribute
name=keepAliveTime15000/attribute
attribute name=poolSize30/attribute
attribute
name=poolNameDefaultThreadPool/attribute
/gbean --
gbean name=MyGBean class=task.MyGBean
!-- reference
name=ExecutornameDefaultThreadPool/name/reference
--
reference name=APrinter
nameAPrinterGBean/name /reference
reference name=BPrinter
nameBPrinterGBean/name /reference
/gbean
!-- gbean name=PrintStopper
class=task.PrintStopper / /gbean --
/configuration
The MyGBean looks as follows:
public class MyGBean implements GBeanLifecycle {
...
private APrinterGBean APrinter;
private BPrinterGBean BPrinter;
...
public void setAPrinter( APrinterGBean APrinter )
{
this.APrinter = APrinter;
}
public void setBPrinter( BPrinterGBean BPrinter )
{
this.BPrinter = BPrinter;
}
...
infoFactory.addReference(APrinter,APrinterGBean.class);
infoFactory.addReference(BPrinter,BPrinterGBean.class);
...
public void doStart() throws WaitingException,
Exception {
System.out.println(GBean: + objectName + has
started);
log.info(My GBean has started);
log.info(objectName);
log.info( bean1 = + APrinter);
log.info( bean2 = + BPrinter);
print(); //prints: MyGBean
APrinter.print(); //prints: APrinterGBean
BPrinter.print(); //prints: BPrinterGBean
}
Clearly, the doStart() of MyGBean operation is not
being executed, but I dont get any error messages
related to MyGBean on the console nor on the log
files.
So, the issue here is that the configuration plan is
deployed correctly, APrinterGBean and BPrinterGBean
get started, but MyGBean is not getting started.
Finally, in the next
[jira] Updated: (GERONIMO-1402) Recipients set by calling MimeMessage.setRecipients(RecipientType, Adress[]) not remembered by getAllRecipients()
[ http://issues.apache.org/jira/browse/GERONIMO-1402?page=all ] Jakob Færch updated GERONIMO-1402: -- Version: 1.0 Recipients set by calling MimeMessage.setRecipients(RecipientType, Adress[]) not remembered by getAllRecipients() - Key: GERONIMO-1402 URL: http://issues.apache.org/jira/browse/GERONIMO-1402 Project: Geronimo Type: Bug Components: mail Versions: 1.0 Reporter: Jakob Færch Assignee: Jacek Laskowski Attachments: patch-javamail-casesensitive-headers.patch In the AdventureBuilder blueprint application, the following snippet is used in class com.sun.j2ee.blueprints.opc.mailerMailHelper to send an email using JavaMail: msg.setRecipients(Message.RecipientType.TO, InternetAddress.parse(emailAddress, false)); [...] Transport.send(msg); Transport in turn calls getAllRecipients() on the message, which returns an empty array. As far as I could tell, the error is caused by the method javax.mail.InternetHeaders#getHeaderList(String) from the geronimo javamail implementation looks up the headers in a map using as key the lowercase version of the header name supplied, whereas the setHeader method puts the header using as key the unmodified header name. The addHeader method correctly lowercases the header name before storing it in the map. -- 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-1513) The directory geronimo-1.0\lib\extension does not match the Extension-Dirs: lib/ext value in server.jar's manifest.mf file
[ http://issues.apache.org/jira/browse/GERONIMO-1513?page=all ] John Sisson closed GERONIMO-1513: - Resolution: Fixed The directory geronimo-1.0\lib\extension does not match the Extension-Dirs: lib/ext value in server.jar's manifest.mf file -- Key: GERONIMO-1513 URL: http://issues.apache.org/jira/browse/GERONIMO-1513 Project: Geronimo Type: Bug Components: buildsystem, startup/shutdown Versions: 1.0.1 Reporter: John Sisson Assignee: John Sisson Priority: Minor Fix For: 1.1, 1.0.1 The geronimo-1.0\lib\extension directory does not match the directory name in the META-INF/Manifest.mf file contained in the geronimo-1.0\bin\server.jar file. The manifest specifies lib/ext (not lib/extension). The 1.0 manifest file currently contains the following: Manifest-Version: 1.0 Class-Path: ../lib/geronimo-qname_1.1_spec-1.0.jar ../lib/geronimo-com mon-1.0.jar ../lib/geronimo-kernel-1.0.jar ../lib/geronimo-system-1.0 .jar ../lib/geronimo-util-1.0.jar ../lib/cglib-nodep-2.1_3.jar ../lib /commons-cli-1.0.jar ../lib/commons-logging-1.0.4.jar ../lib/log4j-1. 2.8.jar ../lib/mx4j-3.0.1.jar ../lib/mx4j-remote-3.0.1.jar ../lib/end orsed/xercesImpl-2.6.2.jar ../lib/endorsed/xmlParserAPIs-2.2.1.jar Main-Class: org.apache.geronimo.system.main.Daemon Endorsed-Dirs: lib/endorsed Extension-Dirs: lib/ext We need to change the directory in the distribution (not the manifest.mf file) to be lib/ext (to be consistent with the value specified in the manifest file, and also to be consisten with the naming of the directory in a JRE). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Assigned: (GERONIMO-1456) geronimo-1.0-src.zip has a meta-inf folder in the root directory
[ http://issues.apache.org/jira/browse/GERONIMO-1456?page=all ] John Sisson reassigned GERONIMO-1456: - Assign To: John Sisson geronimo-1.0-src.zip has a meta-inf folder in the root directory Key: GERONIMO-1456 URL: http://issues.apache.org/jira/browse/GERONIMO-1456 Project: Geronimo Type: Bug Components: buildsystem Versions: 1.0 Reporter: John Sisson Assignee: John Sisson Priority: Minor Fix For: 1.0.1, 1.1 The geronimo-1.0-src.zip has a meta-inf folder in the root directory that is at the same level as the geronimo-1.0-src directory. Needs to be fixed. All files extracted should be under the geronimo-1.0-src directory. -- 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: CORBA incubation proposal
Trieloff, Carl wrote: One thing I just realized is that we don't want the sub-project to show up as being called CORBA Server. CORBA is trademarked by the OMG and that would be an infringement. Thus we can't use CORBA in the name of the project due to this trademark, so I would suggest something neutral like Transport Server. Yes. Guidelines regarding use of OMG trademarks can be found here: http://www.omg.org/legal/tm_guidelines.htm I'm no expert on trademark law, but as I understand it we are not allowed to use the term CORBA at all, unless we get permission from OMG. Regards, Anders
I am out of the office on Friday January 20
I will be out of the office starting January 20, 2006 and will not return until January 23, 2006. I will respond to your message when I return.
Re: CORBA incubation proposal
Hi AllI would like to work on this project. Please let me know how can I invilve in this.Best RegardsThushanthaOn 1/18/06, Alan D. Cabrera [EMAIL PROTECTED] wrote:That would be great. Regards,AlanMatt Hogstrom wrote, On 1/18/2006 6:29 PM: Are there any people on the Harmony project that might (are) interested in an ORB?Seems like prime territory for them. Otherwise it looks good. Alan D. Cabrera wrote: Here is the incubation proposal http://wiki.apache.org/incubator/CorbaProposal Does anyone have any comments before we vote on it? Should this also get sent to the incubator list or do we wait until after the vote? Alex Karasulu and I were talking about it and we both think that it might be a good idea to shoot for making this a TLP.Thoughts? Regards, Alan
Re: v1.x Installer comments - Long
Dave, Thanks for the comments... I made comments below. Would you create installer component JIRAs for the items that make sense? On Thursday 19 January 2006 17:02, Dave Colasurdo wrote: Looks like the Installer has made quite a bit of progress. Thanks Erik!! I'd like to suggest a few Usabality changes to the current installer.. I'm sure you are already aware of many of these and have plans to update them. Just wanted to provide some input based on my first impression. BTW, I've attempted to provide input based on my thoughts on how this would be perceived from the perspective of a first time user. *Package Selection Panel* 1)The available selections are really a hierarchy -Server --J2EE Features ---Jetty Web Container Jetty Sample Applications ---Tomcat Web Container Tomcat Sample Applications Does Izpack allow you to capture the hierarchy graphically? Not that I've seen. It looks like it's strictly a list box. If not, anyway to insert padding to the front of entries to show the hierarchy to the user? I think this would be a better solution than the Inserting spaces is something worth trying. Dependencies box and would more clearly convey the relationship between selections. Also, we should remove the dependencies box and the I don't think it's possible to remove the dependencies box and keep the overall look and feel. other righthand box that contains the Logo. The description box should I agree that the 2nd graphic is redundant at this point. However, one thing we have not explored is the fact that the graphic on the right is actually different for each pack although for now each is a distinct instance of the same bitmap. There is the potential to enhance each bitmap - possibly by making the Geronimo image subdued while overlaying something related to the pack. I have not tried removing the graphic, but I don't think it's possible to remove it and keep this look and feel. be located directly to the right of the main selection box OR below it on the left. I doubt that this is easy to change. We can look into making some of these changes in more detail at some point. Anything is actually possible depending on the capabilities of IzPack itself and how much we're willing to diverge the Geronimo installer from the IzPack codebase. It may actually be possible to make some of the changes without changing IzPack, but based on what I know right now, I don't think so. We've already diverged from the IzPack codebase and we need to factor these changes into IzPack as we move forward or we may run into problems related to these changes later as IzPack itself diverges. I'm struggling a little with this at this point given that IzPack is a generalized installer and some of the changes made are specific to Geronimo. I tried to keep the changes separated, but our requirements are reflected in code I wanted to keep generalized anyway. I don't want to boil the ocean, but I'd also like to minimize problems occurring from the two distinct dev paths as much as possible. Graphical look and feel changes might be less painful to push back into IzPack, but it's still a little worrisome. I like the way the dependant boxes interact (turning off something at the top of the hierarchy automatically trickles down to the dependant choices).. 2) It seems that we are allowing the user to choose two web containers? I thought we would limit the choice to just one? The operator can install both containers, but they cannot activate both at runtime. 3) It seems that it is currently possible to pick-and-choose selections that result in a server that won't start. We need to decide which choices are valid and assure that the resulting installations all work. Flexibility is great, but we don't want to give users the ability to choose non-working installations. The intent is to prevent the building of a non-working server. There's only one instance I'm aware of that will result in problems and it will be fixed soon. If daytrader is selected, with no database, then obviously there will be problems. David Jencks has suggested that we just go ahead and install Derby when the J2EE Features are selected -- and I plan to do this. If you're aware of other instances please enumerate them... 4) The available disk space seems to only be specified for Server. I assume the other selections will eventually be updated. IzPack only displays this for packs which have files associated. This is one of the current issues about the installer. It installs everything. This will be addressed. 5) Should the Server selection be re-labeled as Geronimo kernel or Geronimo base infrastructure or something to better reflect what it is? I don't have a real opinion on this. 6) The Greyed out packs are required comment is somewhat confusing.. Perhaps just adding the word (Required) next to the server selection and removing the other comment
[jira] Updated: (GERONIMO-1484) Display username who is logged into the Webconsole
[ http://issues.apache.org/jira/browse/GERONIMO-1484?page=all ] Matthias Schmidt updated GERONIMO-1484: --- Description: Display the user who is logged into the Webconsole might by handy, esp. when having something like a role-based administration concept. One can achieve this by putting a %=request.getRemoteUser()% somewhere in the JSP's, for example: applications/console-framework/src/webapp/WEB-INF/aggregation/TabNavigation.jsp I'm no Designer, so it's up to you guys where to put it. was:Display the user who is logged into the Webconsole might by handy, esp. when having something like a role-based administration concept. Display username who is logged into the Webconsole -- Key: GERONIMO-1484 URL: http://issues.apache.org/jira/browse/GERONIMO-1484 Project: Geronimo Type: Improvement Components: console Versions: 1.0, 1.1, 1.x, 1.0.1 Environment: applies to all Enviroments Reporter: Matthias Schmidt Priority: Minor Display the user who is logged into the Webconsole might by handy, esp. when having something like a role-based administration concept. One can achieve this by putting a %=request.getRemoteUser()% somewhere in the JSP's, for example: applications/console-framework/src/webapp/WEB-INF/aggregation/TabNavigation.jsp I'm no Designer, so it's up to you guys where to put it. -- 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
geronimo-contributers
Can someone please add me to the geronimo-contributers JIRA group so that I can be assigned issues? My JIRA userid is pmcmahan.thanks,Paul
Re: Clustering - initial overview doc... - where should we keep it ?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jules Gosnell wrote: Guys, there seems to be some debate about whether the doc should end up in Confluence or MoinMoin... please resolve it and I will publish the doc. Official documentation for the project should be a) under source control in an ASF repository; b) hosted on Apache infrastructure; and c) easily exportable into a readable format that can be packaged for distribution with the code or separately. IMHO, wikis are good for prototyping and rapid collaboration. If a wiki is used, once consensus has been achieved, the content should be moved into the above environment. Working documentation *should* be on ASF infrastructure for holistic reasons and to be captured by the ASF backups. If the majority of the project wants to work in Confluence, then an instance of it should be installed at the ASF. This may require some of the proponents committing to support it there. Content in MoinMoin should be migrated to the Confluent environment. If the majority of the project wants to work in MoinMoin, the content in Confluence needs to be migrated into the Geronimo MoinMoin at Apache. Time for a vote, I guess.. - -- #kenP-)} Ken Coar, Sanagendamgagwedweinini http://Ken.Coar.Org/ Author, developer, opinionist http://Apache-Server.Com/ Millennium hand and shrimp! -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iQCVAwUBQ9Dza5rNPMCpn3XdAQIFowP/eQ0SZO/waNyxe7ZNSxQSKdJRjivbNkmQ ut8rnvRIvqsnY3b/oMAb6G/bFSfFLh459apsrciCPoUEY0b5HmoR4RJNagItzH2J YwyhL8kBEiAzLVyvh1typf/wCEmEqzFdh7QyQoZdFL/SdsgGyUVaZrrSKOsaVS3J HLVQT5pcFnw= =ynzI -END PGP SIGNATURE-
[jira] Created: (GERONIMO-1514) Fix installer license statements
Fix installer license statements Key: GERONIMO-1514 URL: http://issues.apache.org/jira/browse/GERONIMO-1514 Project: Geronimo Type: Task Components: installer Versions: 1.0 Reporter: erik daughtrey They need to be fixed for both branches/1,0 and trunk -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (GERONIMO-1515) Installer - some GBeans do not start correctly after install
Installer - some GBeans do not start correctly after install Key: GERONIMO-1515 URL: http://issues.apache.org/jira/browse/GERONIMO-1515 Project: Geronimo Type: Bug Components: installer Versions: 1.1 Reporter: erik daughtrey This seems to be happening in trunk and not on branches/1.0 -- 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] Documentation in Confluence, MoinMoin, or..
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Anyone with an interest in working with the documentation, either directly or for some sort of postprocessing, please vote here. Unless there are problems, this vote will close in one week, at 14h00 UTC on 27 January 2006. At that point, a two-thirds majority will be a clear indicator of which way to go; any narrower majority will mean opinions are still too divided. Working documentation for Apache Geronimo should be kept in [ ] Confluence [ ] MoinMoin wiki [ ] Other (explain) This does not affect the need for 'solid' or released documentation to be under source control. This vote is only to decide a single collaborative environment for its development. - -- #kenP-)} Ken Coar, Sanagendamgagwedweinini http://Ken.Coar.Org/ Author, developer, opinionist http://Apache-Server.Com/ Millennium hand and shrimp! -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iQCVAwUBQ9D1bprNPMCpn3XdAQIguAP/W4N8a5bp0F0kqhLnInPkBb1Hgacg7r0D eBHx/NiyQzZ/qjsStvCh/Ud3dDSzVbTCno5mgoaM6lmqEgOJ/EqMVzD/lYmtt/0y Jl2dI4DrPRe7Y5UvWNM76dSaGob3xuGyhYLm2mVJYxDnow9L6MO6btrWOCsb8Ww7 48uwYXnlh1c= =1Dmb -END PGP SIGNATURE-
[jira] Created: (GERONIMO-1516) Installer - add new components to install: openejb, openejb-builder, axis and axis-builder
Installer - add new components to install: openejb, openejb-builder, axis and axis-builder -- Key: GERONIMO-1516 URL: http://issues.apache.org/jira/browse/GERONIMO-1516 Project: Geronimo Type: Task Components: installer Versions: 1.1 Reporter: erik daughtrey New configurations. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (GERONIMO-1518) Installer - only copy jars needed by selected configuration
Installer - only copy jars needed by selected configuration --- Key: GERONIMO-1518 URL: http://issues.apache.org/jira/browse/GERONIMO-1518 Project: Geronimo Type: Improvement Components: installer Versions: 1.1 Reporter: erik daughtrey -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (GERONIMO-1517) Installer - Install Derby with base J2EE Features
Installer - Install Derby with base J2EE Features - Key: GERONIMO-1517 URL: http://issues.apache.org/jira/browse/GERONIMO-1517 Project: Geronimo Type: Bug Components: installer Versions: 1.1, 1.0.1 Reporter: erik daughtrey -- 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: [VOTE] Documentation in Confluence, MoinMoin, or..
[X] Confluence - sachin On Jan 20, 2006, at 9:36 AM, Rodent of Unusual Size wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Anyone with an interest in working with the documentation, either directly or for some sort of postprocessing, please vote here. Unless there are problems, this vote will close in one week, at 14h00 UTC on 27 January 2006. At that point, a two-thirds majority will be a clear indicator of which way to go; any narrower majority will mean opinions are still too divided. Working documentation for Apache Geronimo should be kept in [ ] Confluence [ ] MoinMoin wiki [ ] Other (explain) This does not affect the need for 'solid' or released documentation to be under source control. This vote is only to decide a single collaborative environment for its development. - -- #kenP-)} Ken Coar, Sanagendamgagwedweinini http://Ken.Coar.Org/ Author, developer, opinionist http://Apache-Server.Com/ Millennium hand and shrimp! -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iQCVAwUBQ9D1bprNPMCpn3XdAQIguAP/W4N8a5bp0F0kqhLnInPkBb1Hgacg7r0D eBHx/NiyQzZ/qjsStvCh/Ud3dDSzVbTCno5mgoaM6lmqEgOJ/EqMVzD/lYmtt/0y Jl2dI4DrPRe7Y5UvWNM76dSaGob3xuGyhYLm2mVJYxDnow9L6MO6btrWOCsb8Ww7 48uwYXnlh1c= =1Dmb -END PGP SIGNATURE-
Re: [VOTE] Documentation in Confluence, MoinMoin, or..
[X] Confluence
Re: [VOTE] Documentation in Confluence, MoinMoin, or..
On 1/20/06, Rodent of Unusual Size [EMAIL PROTECTED] wrote: Working documentation for Apache Geronimo should be kept in [+0] Confluence [+1] MoinMoin wiki [ ] Other (explain) I don't really care except that I know MoinMoin markup quite well and am newer to Confluence. :) But also, as I understand it, even if we choose Confluence we need a different Confluence installation which someone TBD needs to take charge of and then all the content needs to be moved? Anyway, if the majority prefers Confluence I'm fine with it, but I don't have te cycles to help set it up at the moment. Thanks, Aaron
Re: [VOTE] Documentation in Confluence, MoinMoin, or..
[x] Confluence From an end-user point of view I think it's more organized and easy to navigate. From a contributers point of view I think there is already a good skeleton in place for anybody interested to fill in the gaps. Regards, Rajith
[jira] Updated: (GERONIMO-1514) Fix installer license statements
[ http://issues.apache.org/jira/browse/GERONIMO-1514?page=all ] erik daughtrey updated GERONIMO-1514: - Geronimo Info: [Patch Available] Fix installer license statements Key: GERONIMO-1514 URL: http://issues.apache.org/jira/browse/GERONIMO-1514 Project: Geronimo Type: Task Components: installer Versions: 1.0 Reporter: erik daughtrey They need to be fixed for both branches/1,0 and trunk -- 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-1191) Installer should not allow conflicting configuration information
[ http://issues.apache.org/jira/browse/GERONIMO-1191?page=all ] Kevan Miller closed GERONIMO-1191: -- Resolution: Duplicate Assign To: Kevan Miller Fixed by 1192 Installer should not allow conflicting configuration information Key: GERONIMO-1191 URL: http://issues.apache.org/jira/browse/GERONIMO-1191 Project: Geronimo Type: New Feature Components: installer Versions: 1.0-M5 Environment: Installer runtime -- all platfoms Reporter: erik daughtrey Assignee: Kevan Miller Fix For: 1.x Currently, the installer does not verify that conflicting ports may have been configured by the operator. Fixing this problem requires encoding of the potential field conflicts on an inter-panel and intra-panel basis. Ultimately, it would be great to factor environmental information into the equation, but that's boiling the ocean. -- 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: [VOTE] Documentation in Confluence, MoinMoin, or..
Rodent of Unusual Size wrote: Working documentation for Apache Geronimo should be kept in [X] Confluence [ ] MoinMoin wiki [ ] Other (explain) I haven't written any Geronimo documentation yet, but if I eventually do, I'd prefer Confluence, primarily because of how easy it makes it to organize, move and rename pages. That's really important in documentation efforts (to optimize the reader experience) and yet is a major pain to do in MoinMoin. Also nice: * Breadcrumbs (linked to easily managed content hierarchy) * Easy to use callout boxes and multi-column layouts within the wiki markup * WYSIWIG editor option which can make it easier to maintain large tables whose rows don't fit on one line in the wiki markup. * Easy to do things like list all of the children of a page along with excerpts, include the contents of another page, pull in RSS feeds, include a sidebar with a list of open JIRA issues, etc. * PDF export of single pages or subsets of the whole content tree * Easy security config if needed (vs. MoinMoin's somewhat awkward ACLs) * I think Maven can parse Confluence content to pull into the generated site (haven't tried this yet) In my experience, the major downside to Confluence vs. MoinMoin (besides infrastructure requirements) is the speed of the edit screen. MoinMoin's edit is almost instantaneous. Confluence's takes a few seconds to render. Overall, that's kind of a pain, but it's not serious enough to outweigh the other Confluence benefits. One major downside of Confluence vs. other wikis like MediaWiki is the inability to edit individual sections of a page. However, MoinMoin doesn't let you do that either, and you can approximate it in Confluence by breaking content out into separate pages and using includes to construct the larger views. Cheers, Erin
Re: [VOTE] Documentation in Confluence, MoinMoin, or..
[ X ] Confluence Joe Rodent of Unusual Size wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Anyone with an interest in working with the documentation, either directly or for some sort of postprocessing, please vote here. Unless there are problems, this vote will close in one week, at 14h00 UTC on 27 January 2006. At that point, a two-thirds majority will be a clear indicator of which way to go; any narrower majority will mean opinions are still too divided. Working documentation for Apache Geronimo should be kept in [ ] Confluence [ ] MoinMoin wiki [ ] Other (explain) This does not affect the need for 'solid' or released documentation to be under source control. This vote is only to decide a single collaborative environment for its development. - -- #kenP-)} Ken Coar, Sanagendamgagwedweinini http://Ken.Coar.Org/ Author, developer, opinionist http://Apache-Server.Com/ Millennium hand and shrimp! -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iQCVAwUBQ9D1bprNPMCpn3XdAQIguAP/W4N8a5bp0F0kqhLnInPkBb1Hgacg7r0D eBHx/NiyQzZ/qjsStvCh/Ud3dDSzVbTCno5mgoaM6lmqEgOJ/EqMVzD/lYmtt/0y Jl2dI4DrPRe7Y5UvWNM76dSaGob3xuGyhYLm2mVJYxDnow9L6MO6btrWOCsb8Ww7 48uwYXnlh1c= =1Dmb -END PGP SIGNATURE- -- Joe Bohn joe.bohn at earthlink.net He is no fool who gives what he cannot keep, to gain what he cannot lose. -- Jim Elliot
[jira] Created: (GERONIMODEVTOOLS-51) Cannot remove published applications
Cannot remove published applications Key: GERONIMODEVTOOLS-51 URL: http://issues.apache.org/jira/browse/GERONIMODEVTOOLS-51 Project: Geronimo-Devtools Type: Bug Environment: WINXP, JDK 1.4.2 eclipse 3.1.1 Reporter: Lin Sun Priority: Blocker This problem started to appear in one of the very recent builds. 1) Start with a clean workspace: eclipse -clean and define the geronimo server. 2) Imported the Hello.war 3) did the normal Run on server 4) saw the hello page in the eclipse browser 5) any attempts to Run on server, Remove, ... failed. The .log and server.log was showing that the hello app was already on the server and it was not being redeployed. Did a deploy list-modules, and saw hello program with a + sign on the left indicating it is still running. -- 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: [VOTE] Documentation in Confluence, MoinMoin, or..
+1 Confluence -dain On Jan 20, 2006, at 6:36 AM, Rodent of Unusual Size wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Anyone with an interest in working with the documentation, either directly or for some sort of postprocessing, please vote here. Unless there are problems, this vote will close in one week, at 14h00 UTC on 27 January 2006. At that point, a two-thirds majority will be a clear indicator of which way to go; any narrower majority will mean opinions are still too divided. Working documentation for Apache Geronimo should be kept in [ ] Confluence [ ] MoinMoin wiki [ ] Other (explain) This does not affect the need for 'solid' or released documentation to be under source control. This vote is only to decide a single collaborative environment for its development. - -- #kenP-)} Ken Coar, Sanagendamgagwedweinini http://Ken.Coar.Org/ Author, developer, opinionist http://Apache-Server.Com/ Millennium hand and shrimp! -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iQCVAwUBQ9D1bprNPMCpn3XdAQIguAP/W4N8a5bp0F0kqhLnInPkBb1Hgacg7r0D eBHx/NiyQzZ/qjsStvCh/Ud3dDSzVbTCno5mgoaM6lmqEgOJ/EqMVzD/lYmtt/0y Jl2dI4DrPRe7Y5UvWNM76dSaGob3xuGyhYLm2mVJYxDnow9L6MO6btrWOCsb8Ww7 48uwYXnlh1c= =1Dmb -END PGP SIGNATURE-
Re: Will 1.0.1 1.1 be incompatible with 1.0?
Another option would be to add a new attribute to deployment plans called something like isCompatibleWith or upgrades. This attribute would tell Geronimo that it can use this version of the component in place of the component that it upgrades. So for v1.0.1 we could use configuration configId=geronimo/j2ee-server/1.0.1/car isCompatibleWith=geronimo/j2ee-server/1.0/car xmlns=... and for v1.1 we could use configuration configId=geronimo/j2ee-server/1.1/car isCompatibleWith=geronimo/j2ee-server/1.0/car,geronimo/j2ee-server/1.0.1/car xmlns=... Perhaps using a new element instead of an attribute with CSVs would be cleaner... There would need to be some special logic in place to look for cycles and handle cases where there are multiple components that declare compatibility with a given component. Seems like we could arrive at some reasonable defaults (e.g. choose the node furthest out in the dep chain, last in wins, etc). Best wishes, Paul On 1/19/06, Aaron Mulder [EMAIL PROTECTED] wrote: It seems like if we move ahead as planned for 1.0.1 and 1.1, we'regoing to ship a product with configIds likegeronimo/j2ee-server/1.0.1/car, which means that many deployment planswritten for 1.0 will not be able to be deployed unmodified on 1.0 --and it will instantly turn a huge number of published articles andexamples into errors (think of it -- any example including a GeronimoconfigId will be wrong).Furthermore, there's no way to write a plan that will work on more than one specific major/minor/patch release ofGeronimo, if you have a dependency on a server plan other that thedefault (such as depending on ActiveMQ or CORBA or whatever) or areference to a GBean in a Geronimo configuration other than your own (such that the module's configId must appear in the reference, like,say, ServerInfo).I don't know why this hasn't bothered me up untilnow, but I think it's a pretty serious problem.I think we have a few options: 1) Ship 1.0.1 with all the configIds saying 1.0 so there is no issuefor at least that release2) Remove version numbers from configIds from 1.0.1 onward, so atleast we can have backward compatibility from 1.0.1 forward3) Put in some logic to treat all version numbers in configIds as wildcards4) Support explicit wildcards or version ranges in configIdsMy opinions on these are:I think it would be workable to make all the configIds in 1.0.1 say1.0, though it would surely be painful to change substitutionvariables in ALL the plans accordingly.Though, this is a prettyshort-sighted fix because eventually we'll have to stop callingeverything 1.0.I'd be pretty happy removing the version numbers from the configIds,because I think there has to be a better way to declare and expressversion-ness than to bury it in a String that's used for other things. I'd rather have a plan say configId='geronimo/j2ee-server/car'version='1.0.1' and a reference say name='geronimo/j2ee-server/car'version='1.*' where the version number is optional for the referrer (to be used if you really care about locking it down and to be omittedif you want to maximize portability to other Geronimo versions).Ifwe went this way, I guess we would also make the version a separate property of the ObjectName.I think supporting wildcards or ranges in the version numbers inconfigIds as they are today, and/or treating all version numbers aswildcards, would be pretty hard to implement.I also don't think version ranges or wildcards will work that well.I expect there won'tbe much reason why an application developed and deployed on Geronimo1.0 wouldn't be able to be redeployed on Geronimo 2.0.Sure somethings will change, but I hope it will be rare that you might actually *need* to rewrite an old deployment plan if you just want to redeploythe same old app and don't care about taking full advantage ofwhatever new stuff 2.0 offers.So if we recommend everyone write 1.xplans to say 1.* or [ 1.0,2.0) or whatever, that just means we'reartificially making it impossible to deploy in a future release ofGeronimo without mangling your plans -- and also making configIds alot less pleasant to write to begin with (parentId=geronimo/j2ee-server/[1.0,2.0)/car)So I think overall I prefer pulling the version out of the configId,and making it a separate property of the configuration, which you canuse in a reference or not as you please.Accordingly, I'd also suggest removing the parentId so any parents have to be declared in aimport, where we can make the version number a separate element orattribute, and I guess we'd need to handle it in GBean references too. Anyway, bottom line, I'm not real comfortable shipping 1.0.1 withoutaddressing this in some way.Maybe we should ship 1.0.1 with all theconfigId versions saying 1.0 and then plan to address this ASAP for 1.1 (and maybe even plan to call it 2.0 since it would then beincompatible with 1.0.x).Thoughts?Thanks,Aaron
Cut date for 1.1?
I have heard from some that 1.1 will be cut next week and from others that it will be at least 4 more weeks. Can we make a decision now on what the date will be? I have a fairly big change I'd like to commit sometime next week, but if we are going to cut on Friday, I'll wait until Saturday to commit it. I normally prefer it to commit my changes at the beginning of a cycle so they have a long time to bake. -dain
Re: Cut date for 1.1?
Do you mean 1.0.1 for cutting next week? Dain Sundstrom wrote: I have heard from some that 1.1 will be cut next week and from others that it will be at least 4 more weeks. Can we make a decision now on what the date will be? I have a fairly big change I'd like to commit sometime next week, but if we are going to cut on Friday, I'll wait until Saturday to commit it. I normally prefer it to commit my changes at the beginning of a cycle so they have a long time to bake. -dain
Re: geronimo-contributers
Done. -dain On Jan 20, 2006, at 6:24 AM, Paul McMahan wrote: Can someone please add me to the geronimo-contributers JIRA group so that I can be assigned issues? My JIRA userid is pmcmahan. thanks, Paul
RE: CORBA incubation proposal
Adi, Is this a show stopper for you? I don't understand what you are asking. I was just stating what code I've managed to get my company to agree to contribute to the project (if anyone's interested in it), what components might be useful from another open source project I work on, and what work I would be interested in focussing on. Technical decisions are taken after the community is bootstrapped. The incoming code bases may be used or may even be thrown out completely. Of course things always change in the development of an open source project; I've seen that happen plenty of times just in the last 4-5 months of working on Celtix. But, I've also found it useful to try to get some consensus on where to start. In fact, I've seen people on the incubator mailing list interested in at least some degree of high-level technical overview, including potential outside dependencies. (as a side, it might help to add more detail to the current proposal.) Why wouldn't it be a good idea for the initial committers and the rest of the geroniumo community to discuss it. Certainly there is no diktat on having to use specific outside dependencies. End of the day, who ever is doing the work (once the project gets going) decides on how to do things following apache's usual process(es). 'diktat' seems like an unnecessarily strong word to use for an email where I was asking for feedback on what I would be interested in doing with my own time. I'm sorry if you got the impression that I was trying to unilaterally impose something on this project -- I hope no one else got that impression. Note that I concluded with, I'm open to other ideas, in case people involved in this proposal think that my suggestions would actually not be a good place to start. So do you have any particular feedback on my ideas, or were you just making sure I wasn't trying to impose an iron-clad speification for the project's future work? ;-) Adi -Original Message- From: Davanum Srinivas [mailto:[EMAIL PROTECTED] Sent: Thursday, January 19, 2006 5:56 PM To: dev@geronimo.apache.org Subject: Re: CORBA incubation proposal Adi, Is this a show stopper for you? Technical decisions are taken after the community is bootstrapped. The incoming code bases may be used or may even be thrown out completely. Certainly there is no diktat on having to use specific outside dependencies. End of the day, who ever is doing the work (once the project gets going) decides on how to do things following apache's usual process(es). thanks, dims On 1/19/06, Sakala, Adinarayana [EMAIL PROTECTED] wrote: Before voting on this proposal or sending it to the incubator list, I want to clarify the first paragraph under Initial Source. Aside from the Trifork contribution, the rest of the paragraph really implies three different sources of code: a) reuse of components in the ObjectWeb Celtix project, b) code contributed from IONA to Apache for this project, and c) ongoing contribution from me and the other initial committers from IONA. Components that we would use from the ObjectWeb Celtix project are the pluggable transport framework and the in dispatch infrastructure in order to use the ORB and IIOP transport form a XMLSchema based type system from JAX-B, EJB's, XMLBeans or selected API. Code that my employer could grant to Apache for development within this project include the ORB and IIOP transport. Most importantly, the work that me, Balaji, Prasad, Darren, Edell, Conrad, Dion, and David (Weir) can commit to spending time on would be (to start with, anyway) the creation of the CORBA transport utilizing required aspects from Celtix and integration with selected dynamic API to provide support for Geronimo and other Apache projects. I'm open to other ideas, but I think/hope that this combination would help get things started and also attract other developers to the project. Adi Sakala -Original Message- From: Alan D. Cabrera [mailto:[EMAIL PROTECTED] Sent: Thursday, January 19, 2006 3:11 PM To: dev@geronimo.apache.org Subject: Re: CORBA incubation proposal Fixed! Regards, Alan Trieloff, Carl wrote, On 1/19/2006 9:13 AM: The missing text... As a side benefit the XMLShema API will also be able to support other transports and binding through configuration. Carl. -Original Message- From: Anders Hessellund Jensen [mailto:[EMAIL PROTECTED] Sent: Thursday, January 19, 2006 10:48 AM To: dev@geronimo.apache.org Subject: Re: CORBA incubation proposal Alan D. Cabrera wrote: Here is the incubation proposal http://wiki.apache.org/incubator/CorbaProposal Does anyone have any comments before we vote on it? There is a half-finished sentence in the document. In the Initial Source section it says: As a side
Re: Cut date for 1.1?
Nope, I mean 1.1. -dain On Jan 20, 2006, at 9:14 AM, Jeff Genender wrote: Do you mean 1.0.1 for cutting next week? Dain Sundstrom wrote: I have heard from some that 1.1 will be cut next week and from others that it will be at least 4 more weeks. Can we make a decision now on what the date will be? I have a fairly big change I'd like to commit sometime next week, but if we are going to cut on Friday, I'll wait until Saturday to commit it. I normally prefer it to commit my changes at the beginning of a cycle so they have a long time to bake. -dain
Re: [VOTE] Documentation in Confluence, MoinMoin, or..
[X] Confluence The integration w/ Jira is great! Regards, Alan
Re: [VOTE] Documentation in Confluence, MoinMoin, or..
+1 Confluence David Jencks On Jan 20, 2006, at 6:36 AM, Rodent of Unusual Size wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Anyone with an interest in working with the documentation, either directly or for some sort of postprocessing, please vote here. Unless there are problems, this vote will close in one week, at 14h00 UTC on 27 January 2006. At that point, a two-thirds majority will be a clear indicator of which way to go; any narrower majority will mean opinions are still too divided. Working documentation for Apache Geronimo should be kept in [ ] Confluence [ ] MoinMoin wiki [ ] Other (explain) This does not affect the need for 'solid' or released documentation to be under source control. This vote is only to decide a single collaborative environment for its development. - -- #kenP-)} Ken Coar, Sanagendamgagwedweinini http://Ken.Coar.Org/ Author, developer, opinionist http://Apache-Server.Com/ Millennium hand and shrimp! -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iQCVAwUBQ9D1bprNPMCpn3XdAQIguAP/W4N8a5bp0F0kqhLnInPkBb1Hgacg7r0D eBHx/NiyQzZ/qjsStvCh/Ud3dDSzVbTCno5mgoaM6lmqEgOJ/EqMVzD/lYmtt/0y Jl2dI4DrPRe7Y5UvWNM76dSaGob3xuGyhYLm2mVJYxDnow9L6MO6btrWOCsb8Ww7 48uwYXnlh1c= =1Dmb -END PGP SIGNATURE-
Re: Cut date for 1.1?
David Jencks wrote: Personally I am not ready for 1.1 to be frozen. Also, there is at least one major bug (tomcat cross-context dispatch) that needs to be fixed and I haven't seen any progress on it. I am not going to be able to get to this at least until Monday...you know...day job and family things to do ;-) Sorry...I wish I could expedite this...I am happy to chat about it and come up with a solution if you need it before the beginning of next week. Feel free to tackle it yourself if that time is not acceptable for you. The nature of your change might affect other peoples opinion on this also, what are you planning? I agree...I think a 1.1 cut for next week is a bit aggressive. thanks david jencks On Jan 20, 2006, at 9:19 AM, Dain Sundstrom wrote: Nope, I mean 1.1. -dain On Jan 20, 2006, at 9:14 AM, Jeff Genender wrote: Do you mean 1.0.1 for cutting next week? Dain Sundstrom wrote: I have heard from some that 1.1 will be cut next week and from others that it will be at least 4 more weeks. Can we make a decision now on what the date will be? I have a fairly big change I'd like to commit sometime next week, but if we are going to cut on Friday, I'll wait until Saturday to commit it. I normally prefer it to commit my changes at the beginning of a cycle so they have a long time to bake. -dain
Re: Cut date for 1.1?
On Jan 20, 2006, at 9:46 AM, David Jencks wrote: Personally I am not ready for 1.1 to be frozen. Also, there is at least one major bug (tomcat cross-context dispatch) that needs to be fixed and I haven't seen any progress on it. The nature of your change might affect other peoples opinion on this also, what are you planning? I am working on splitting the OpenEJB container into one object for each deployed ejb and a set of share invocation processing ejb containers. This is a refactoring of internal interfaces well below the layer our users see. Regardless, of this change, I don't want to be the one that checks in stuff that breaks the build or TCK 3 days before a branch is cut. -dain
Re: CORBA incubation proposal
Hmm, please don't take this the wrong way. i am just trying to guide the discussions and stating the precedents and how things work. Such discussions can drag on, making it difficult to set up resources for infra stuff, getting commit privs to everyone involved etc. FWIW, the first email about a corba donation was 6 months ago (http://marc.theaimsgroup.com/?l=geronimo-devm=112046915405363w=2) and we still don't have a sub project :( /me just going to shut up now. Am sure you guys can handle this on your own. thanks, -- dims On 1/20/06, Sakala, Adinarayana [EMAIL PROTECTED] wrote: Adi, Is this a show stopper for you? I don't understand what you are asking. I was just stating what code I've managed to get my company to agree to contribute to the project (if anyone's interested in it), what components might be useful from another open source project I work on, and what work I would be interested in focussing on. Technical decisions are taken after the community is bootstrapped. The incoming code bases may be used or may even be thrown out completely. Of course things always change in the development of an open source project; I've seen that happen plenty of times just in the last 4-5 months of working on Celtix. But, I've also found it useful to try to get some consensus on where to start. In fact, I've seen people on the incubator mailing list interested in at least some degree of high-level technical overview, including potential outside dependencies. (as a side, it might help to add more detail to the current proposal.) Why wouldn't it be a good idea for the initial committers and the rest of the geroniumo community to discuss it. Certainly there is no diktat on having to use specific outside dependencies. End of the day, who ever is doing the work (once the project gets going) decides on how to do things following apache's usual process(es). 'diktat' seems like an unnecessarily strong word to use for an email where I was asking for feedback on what I would be interested in doing with my own time. I'm sorry if you got the impression that I was trying to unilaterally impose something on this project -- I hope no one else got that impression. Note that I concluded with, I'm open to other ideas, in case people involved in this proposal think that my suggestions would actually not be a good place to start. So do you have any particular feedback on my ideas, or were you just making sure I wasn't trying to impose an iron-clad speification for the project's future work? ;-) Adi -Original Message- From: Davanum Srinivas [mailto:[EMAIL PROTECTED] Sent: Thursday, January 19, 2006 5:56 PM To: dev@geronimo.apache.org Subject: Re: CORBA incubation proposal Adi, Is this a show stopper for you? Technical decisions are taken after the community is bootstrapped. The incoming code bases may be used or may even be thrown out completely. Certainly there is no diktat on having to use specific outside dependencies. End of the day, who ever is doing the work (once the project gets going) decides on how to do things following apache's usual process(es). thanks, dims On 1/19/06, Sakala, Adinarayana [EMAIL PROTECTED] wrote: Before voting on this proposal or sending it to the incubator list, I want to clarify the first paragraph under Initial Source. Aside from the Trifork contribution, the rest of the paragraph really implies three different sources of code: a) reuse of components in the ObjectWeb Celtix project, b) code contributed from IONA to Apache for this project, and c) ongoing contribution from me and the other initial committers from IONA. Components that we would use from the ObjectWeb Celtix project are the pluggable transport framework and the in dispatch infrastructure in order to use the ORB and IIOP transport form a XMLSchema based type system from JAX-B, EJB's, XMLBeans or selected API. Code that my employer could grant to Apache for development within this project include the ORB and IIOP transport. Most importantly, the work that me, Balaji, Prasad, Darren, Edell, Conrad, Dion, and David (Weir) can commit to spending time on would be (to start with, anyway) the creation of the CORBA transport utilizing required aspects from Celtix and integration with selected dynamic API to provide support for Geronimo and other Apache projects. I'm open to other ideas, but I think/hope that this combination would help get things started and also attract other developers to the project. Adi Sakala -Original Message- From: Alan D. Cabrera [mailto:[EMAIL PROTECTED] Sent: Thursday, January 19, 2006 3:11 PM To: dev@geronimo.apache.org Subject: Re: CORBA incubation proposal Fixed! Regards, Alan Trieloff, Carl wrote, On 1/19/2006 9:13 AM: The missing text...
Re: [VOTE] Documentation in Confluence, MoinMoin, or..
On 1/20/06, Rodent of Unusual Size [EMAIL PROTECTED] wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Anyone with an interest in working with the documentation, either directly or for some sort of postprocessing, please vote here. Unless there are problems, this vote will close in one week, at 14h00 UTC on 27 January 2006. At that point, a two-thirds majority will be a clear indicator of which way to go; any narrower majority will mean opinions are still too divided. Working documentation for Apache Geronimo should be kept in [ ] Confluence [ ] MoinMoin wiki [ ] Other (explain) +1 for Confluence Bruce -- perl -e 'print unpack(u30,D0G)[EMAIL PROTECTED]5R\F)R=6-E+G-N61ED\!G;6%I;\YC;VT* );' Apache Geronimo (http://geronimo.apache.org/) Castor (http://castor.org/)
[jira] Resolved: (GERONIMODEVTOOLS-51) Cannot remove published applications
[ http://issues.apache.org/jira/browse/GERONIMODEVTOOLS-51?page=all ] Sachin Patel resolved GERONIMODEVTOOLS-51: -- Resolution: Fixed Assign To: Sachin Patel Good catch! I accidently overrid a line that allows WTP to update the publish.xml file to indicate that a given project is associated with a server. Cannot remove published applications Key: GERONIMODEVTOOLS-51 URL: http://issues.apache.org/jira/browse/GERONIMODEVTOOLS-51 Project: Geronimo-Devtools Type: Bug Environment: WINXP, JDK 1.4.2 eclipse 3.1.1 Reporter: Lin Sun Assignee: Sachin Patel Priority: Blocker This problem started to appear in one of the very recent builds. 1) Start with a clean workspace: eclipse -clean and define the geronimo server. 2) Imported the Hello.war 3) did the normal Run on server 4) saw the hello page in the eclipse browser 5) any attempts to Run on server, Remove, ... failed. The .log and server.log was showing that the hello app was already on the server and it was not being redeployed. Did a deploy list-modules, and saw hello program with a + sign on the left indicating it is still running. -- 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: [VOTE] Documentation in Confluence, MoinMoin, or..
[ X ] Confluence Cheers! Hernan Rodent of Unusual Size wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Anyone with an interest in working with the documentation, either directly or for some sort of postprocessing, please vote here. Unless there are problems, this vote will close in one week, at 14h00 UTC on 27 January 2006. At that point, a two-thirds majority will be a clear indicator of which way to go; any narrower majority will mean opinions are still too divided. Working documentation for Apache Geronimo should be kept in [ ] Confluence [ ] MoinMoin wiki [ ] Other (explain) This does not affect the need for 'solid' or released documentation to be under source control. This vote is only to decide a single collaborative environment for its development. - -- #kenP-)} Ken Coar, Sanagendamgagwedweinini http://Ken.Coar.Org/ Author, developer, opinionist http://Apache-Server.Com/ Millennium hand and shrimp! -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iQCVAwUBQ9D1bprNPMCpn3XdAQIguAP/W4N8a5bp0F0kqhLnInPkBb1Hgacg7r0D eBHx/NiyQzZ/qjsStvCh/Ud3dDSzVbTCno5mgoaM6lmqEgOJ/EqMVzD/lYmtt/0y Jl2dI4DrPRe7Y5UvWNM76dSaGob3xuGyhYLm2mVJYxDnow9L6MO6btrWOCsb8Ww7 48uwYXnlh1c= =1Dmb -END PGP SIGNATURE-
Re: [VOTE] Documentation in Confluence, MoinMoin, or..
On Fri, Jan 20, 2006 at 10:30:59AM -0500, Aaron Mulder wrote: But also, as I understand it, even if we choose Confluence we need a different Confluence installation which someone TBD needs to take charge of and then all the content needs to be moved? Excellent point. It's more important to have a single wiki than to have any specific wiki. Does Confluence have an import feature for pulling pages from Moin? Toby
Does Apache Geronimo 1.0 run on iSeries?
Hi, Does anyone know the answer to the question: Does Apache Geronimo 1.0 run on iSeries? It's been asked and unfortunatelly the answer is not yet known. -- Jacek Laskowski http://www.laskowski.org.pl
[jira] Resolved: (GERONIMODEVTOOLS-22) Geronimo Feature Failed to Install Properly
[ http://issues.apache.org/jira/browse/GERONIMODEVTOOLS-22?page=all ] Sachin Patel resolved GERONIMODEVTOOLS-22: -- Resolution: Fixed Assign To: Sachin Patel This is fixed. Once the jars are re-posted on the update site, this feature will be made available. Geronimo Feature Failed to Install Properly --- Key: GERONIMODEVTOOLS-22 URL: http://issues.apache.org/jira/browse/GERONIMODEVTOOLS-22 Project: Geronimo-Devtools Type: Bug Components: eclipse-plugin Environment: Windows XP Reporter: Arthur Ryman Assignee: Sachin Patel I am testing with WTP 1.0 RC4. I tried to install the Geronimo runtime using the Install New Server function which uses Update Manager. The update appeared to complete but the runtime was in a broken state. Only the \lib folder was created - no \bin, no \repository. There was no way for me to refresh the update. There should be some better check to verfiy that the Feature was updated correctly. I'll have to manually delete the Feature and retry. -- 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: Cut date for 1.1?
On Jan 20, 2006, at 9:59 AM, Dain Sundstrom wrote: On Jan 20, 2006, at 9:46 AM, David Jencks wrote: Personally I am not ready for 1.1 to be frozen. Also, there is at least one major bug (tomcat cross-context dispatch) that needs to be fixed and I haven't seen any progress on it. The nature of your change might affect other peoples opinion on this also, what are you planning? I am working on splitting the OpenEJB container into one object for each deployed ejb and a set of share invocation processing ejb containers. This is a refactoring of internal interfaces well below the layer our users see. Does this mean there will be one interceptor stack for each ejb type, shared among all the e.g. stateless sesssion ejbs? What is the advantage of this design? I can think of some disadvantages compared to our present design but no advantages. Probably just a lack of imagination, but I'd really appreciate discussion of architectural changes before the code arrives. thanks david jencks Regardless, of this change, I don't want to be the one that checks in stuff that breaks the build or TCK 3 days before a branch is cut. -dain
1.0.1 Release Plans - Work Items and JIRA list - Targetting availability 1st week of February
All, I've pulled the JIRAS that are currently currently targetted against 1.0.1. I talked with Alan about doing the 1.0.1 Release Management so I can finish out the doc of how to get one of these monsters out. I'm suggesting that we target close of coding for 1.0.1 by next Sunday and then start a release / verification cycle for end of January availability. Below I prioritized Cosmetic things that will need to be done and then actual bugs (based on the JIRA comments) and finally items I'd like to move foreward to the next release. I'll go ahead and move the ones below unless there is a strong objection. I think the biggest problem we face is the issue with the configIds. Aaron sent out an e-mail about that and I expect it will get straightened out this week. Chime in for your favorite bugs. I'll do some assignment of the JIRAs to who I think owns the area. If your really excited about a specific defect better grab it straight away :) As always, feedback and help appreciated. Cosmetic GERONIMO-1417 [daytrader] daytrader/docs/tradeFAQ.html out of date GERONIMO-1456 geronimo-1.0-src.zip has a meta-inf folder in the root directory Improvement GERONIMO-1199 Keystore portlet should display certificate finger print before importing trusted certificates Bugs GERONIMO-1012 Tomcat integration does not set a subject in an unsecured web module in a secured ejb application GERONIMO-1196 Keystore portlet: Viewing trusted certificate results in an error GERONIMO-1336 Setting the Max PoolSize on a DataBase pool with invalid information does not yield an error message and silently fails GERONIMO-1387 Geronimo Console Applications portlets fail after starting app client. GERONIMO-1410 Configuration geronimo/jetty/1.0-SNAPSHOT/car defines Spring Framework - Hibernate based Web-app do not work GERONIMO-1476 Changes to default log4j.rootCategory are not dynamic GERONIMO-1423 log4j.properties's category is ignored GERONIMO-1433 Security vulnerability of WEB-INF contents on windows platforms GERONIMO-1448 debug-tool does not work on Tomcat GERONIMO-1450 Console usage plans use old namspace parentId GERONIMO-1451 A new TCP listener for ActiveMQ is not persisting across server startups GERONIMO-1462 Finish implementing inverseClassloading attribute in plan schemas GERONIMO-1466 Preparing 1.0 branch for development of 1.0.1 GERONIMO-1467 DB pool portlet error when web session saved GERONIMO-1468 FileSystemRepository#listUris() produces wrong URI array when the repository contains a malformed entry GERONIMO-1472 packaging plugin creates client cars with wrong version GERONIMO-1474 Cross site scripting vulnerabilites GERONIMO-1475 Configs needing updated to not include Xerces files in the Repository as duplicates to lib\endorsed GERONIMO-1480 Cross context include does not set jacc contextID for 2nd web app. (Tomcat only) GERONIMO-1490 setjavaenv.bat is not called by deploy.bat GERONIMO-1491 ActiveMQ plan uses hardcoded obsolete org/apache/geronimo/ActiveMQ module name GERONIMO-1492 Many org/apache/geronimo configIds still live in source tree GERONIMO-1508 1.0.1 won't accept plans with 1.0 configIds in references, parents, imports, etc. GERONIMO-1510 NPE in connector DConfigBeans if no config params present on connection definition instance Move Forward GERONIMO-1192 Installer should create a config.xml for the target install GERONIMO-1349 Missing Ports in Startup Port List GERONIMO-1374 Open EJB does not allow the setting of a ForiegnKey that is involved in a CMR relationship GERONIMO-1379 Login Error page does not include updates to remove table and include About link GERONIMO-1441 Build path contains duplicate entry errors for some geronimo projects in eclipse GERONIMO-1445 Allow deployment and use of exploded EAR modules GERONIMO-1489 Minor fixes/updates to jUDDI webapp and Tomcat config GERONIMO-1503 keystore generated by KeyStore portlet could not be used to add either Jetty or Tomcat HTTPS Listeners GERONIMO-1509 Maven logging output multipled
[jira] Assigned: (GERONIMO-1514) Fix installer license statements
[ http://issues.apache.org/jira/browse/GERONIMO-1514?page=all ] David Jencks reassigned GERONIMO-1514: -- Assign To: David Jencks Fix installer license statements Key: GERONIMO-1514 URL: http://issues.apache.org/jira/browse/GERONIMO-1514 Project: Geronimo Type: Task Components: installer Versions: 1.0 Reporter: erik daughtrey Assignee: David Jencks Attachments: installer-license-text-fix.patch They need to be fixed for both branches/1,0 and trunk -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Assigned: (GERONIMO-1505) Installer should default Tomcat on at runtime if Jetty pack is not selected
[ http://issues.apache.org/jira/browse/GERONIMO-1505?page=all ] David Jencks reassigned GERONIMO-1505: -- Assign To: David Jencks Installer should default Tomcat on at runtime if Jetty pack is not selected --- Key: GERONIMO-1505 URL: http://issues.apache.org/jira/browse/GERONIMO-1505 Project: Geronimo Type: Bug Components: installer Versions: 1.0 Reporter: erik daughtrey Assignee: David Jencks Attachments: installer-tomcat-only-wc-config-fix.patch When both Jetty and Tomcat are selected for install, the installer will default Jetty to active at runtime and Tomcat as off by default. If Jetty is not selected for install and Tomcat is, then Tomcat should default to active at runtime. Currently it does not. -- 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: Will 1.0.1 1.1 be incompatible with 1.0?
Aaron, Thanks for raising this issue - this is important. It's tacky to force people to change their plans for a minor version upgrade. 1) Ship 1.0.1 with all the configIds saying 1.0 so there is no issue for at least that release I like this option for this branch. It looks as if the plan names have changed already but I'd like to see them changed back, (even if it's a temporary hack for this branch). I think it would be workable to make all the configIds in 1.0.1 say 1.0, though it would surely be painful to change substitution variables in ALL the plans accordingly. Though, this is a pretty short-sighted fix because eventually we'll have to stop calling everything 1.0. I guess since I opened my big trap above, it would be rude of me to not volunteer to help with the work. So consider this an offer. I'd be pretty happy removing the version numbers from the configIds, because I think there has to be a better way to declare and express version-ness than to bury it in a String that's used for other things. Agreed. If it stays then it should be used for versioning purposes, i.e. it should be changed to indicate that something has changed enough to break backward compatibility. Otherwise it's just make-work for the users (like me!). I'd rather have a plan say configId='geronimo/j2ee-server/car' version='1.0.1' and a reference say name='geronimo/j2ee-server/car' version='1.*' where the version number is optional for the referrer (to be used if you really care about locking it down and to be omitted if you want to maximize portability to other Geronimo versions). If we went this way, I guess we would also make the version a separate property of the ObjectName. While we're at it, what's the car mean? Is this necessary? From a user perspective, the best solution is to not have to use a parent ID at all, just deploy your j2ee app and it works as expected. Next best would be to set it once and forget it, next best is to have to change it every now and then (i.e. big Geronimo version change). I'm concered about inventing elaborate semantics for the version field when it's not clear that it helps users. Thanks again for bringing this up, Toby
Re: Does Apache Geronimo 1.0 run on iSeries?
That would be a question for an IBMer :) Geronimo currently does not run on iSeries since its an IBM JDK and Geronimo isn't certified there. We're working towards JDK independence soon but unfortunately 1.0 is not available. That said, one can run Geronimo on an IBM JDK and on iSeries by making a few simple changes. It won't work for applications that need to use IIOP but for most people that's not a problem. I've run Geronimo on the JDK with DayTrader and it runs really well. So, the answer is its not a certified platform but with an editor and 30 seconds of time it will work with some slightly reduced function. Matt Jacek Laskowski wrote: Hi, Does anyone know the answer to the question: Does Apache Geronimo 1.0 run on iSeries? It's been asked and unfortunatelly the answer is not yet known. -- Jacek Laskowski http://www.laskowski.org.pl
Re: Cut date for 1.1?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Dain Sundstrom wrote: Regardless, of this change, I don't want to be the one that checks in stuff that breaks the build or TCK 3 days before a branch is cut. Who is the release manager? If there isn't one, then there's no point worrying about any particular date. The release manager gets to call the shots on freeze, thaw, and cut dates. - -- #kenP-)} Ken Coar, Sanagendamgagwedweinini http://Ken.Coar.Org/ Author, developer, opinionist http://Apache-Server.Com/ Millennium hand and shrimp! -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iQCVAwUBQ9E9B5rNPMCpn3XdAQKmtAP/YGBUoOmSSfv/JLdWjb2qG6xGov9Ve7wE PZNO/tUbu1J7JUb3xkpN8CwUBtv6GEO9pr7T/CrR5WxgSJblmq1E5B4c+Ok2liIz YXVZoc2qYBU0tyHz7VEVNOaqMTERrL40amdez0gy08dA86dk5ySHGk1RXZqH7IKH bvVBOMPeUZk= =7yAY -END PGP SIGNATURE-
Re: Cut date for 1.1?
For what it's worth, Dain whiteboarded his plan for me the other day and I'm 100% on board with the proposed changes. Thanks, Aaron On 1/20/06, David Jencks [EMAIL PROTECTED] wrote: On Jan 20, 2006, at 9:59 AM, Dain Sundstrom wrote: On Jan 20, 2006, at 9:46 AM, David Jencks wrote: Personally I am not ready for 1.1 to be frozen. Also, there is at least one major bug (tomcat cross-context dispatch) that needs to be fixed and I haven't seen any progress on it. The nature of your change might affect other peoples opinion on this also, what are you planning? I am working on splitting the OpenEJB container into one object for each deployed ejb and a set of share invocation processing ejb containers. This is a refactoring of internal interfaces well below the layer our users see. Does this mean there will be one interceptor stack for each ejb type, shared among all the e.g. stateless sesssion ejbs? What is the advantage of this design? I can think of some disadvantages compared to our present design but no advantages. Probably just a lack of imagination, but I'd really appreciate discussion of architectural changes before the code arrives. thanks david jencks Regardless, of this change, I don't want to be the one that checks in stuff that breaks the build or TCK 3 days before a branch is cut. -dain
[jira] Resolved: (GERONIMODEVTOOLS-33) Plugin: Add/remove programs doesn't work when server in debugging mode
[ http://issues.apache.org/jira/browse/GERONIMODEVTOOLS-33?page=all ] Sachin Patel resolved GERONIMODEVTOOLS-33: -- Resolution: Fixed Assign To: Sachin Patel Marking as fixed on behalf of originator. Plugin: Add/remove programs doesn't work when server in debugging mode --- Key: GERONIMODEVTOOLS-33 URL: http://issues.apache.org/jira/browse/GERONIMODEVTOOLS-33 Project: Geronimo-Devtools Type: Bug Components: eclipse-plugin Environment: WinXP, JDK 1.4.2, Plugin I built a few days ago, Eclipse 3.1.1. Reporter: Lin Sun Assignee: Sachin Patel 1) Able to deploy a simple hello program. 2) added a breakpoint in the hello program 3) restarted the server to let it run in debugging mode. (When attempting to right click the application and select debug--debug on server, a window popup asked me the server is not running in debugging mode, click restart button to restart it in debugging mode). 4) Click on debug--debug on server to start the debug for the hello program. 5) Got a unable to publish error, check .log for errors. error is copied below: java.lang.Exception: Module hello/hello already exists in the server. Try to undeploy it first or use the redeploy command. org.apache.geronimo.common.DeploymentException: Module hello/hello already exists in the server. Try to undeploy it first or use the redeploy command. at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:235) at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:102) at org.apache.geronimo.deployment.Deployer$$FastClassByCGLIB$$734a235d.invoke(generated) at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53) at org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38) at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:118) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:835) at org.apache.geronimo.kernel.basic.BasicKernel.invoke(BasicKernel.java:178) at org.apache.geronimo.kernel.KernelGBean.invoke(KernelGBean.java:125) at org.apache.geronimo.kernel.KernelGBean$$FastClassByCGLIB$$1cccefc9.invoke 6) remove the hello program via eclipse using add/remove projects. Check deploy.bat list-modules but I still see hello programs running. -- 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: [VOTE] Documentation in Confluence, MoinMoin, or..
+1 Confluence Rodent of Unusual Size wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Anyone with an interest in working with the documentation, either directly or for some sort of postprocessing, please vote here. Unless there are problems, this vote will close in one week, at 14h00 UTC on 27 January 2006. At that point, a two-thirds majority will be a clear indicator of which way to go; any narrower majority will mean opinions are still too divided. Working documentation for Apache Geronimo should be kept in [ ] Confluence [ ] MoinMoin wiki [ ] Other (explain) This does not affect the need for 'solid' or released documentation to be under source control. This vote is only to decide a single collaborative environment for its development. - -- #kenP-)} Ken Coar, Sanagendamgagwedweinini http://Ken.Coar.Org/ Author, developer, opinionist http://Apache-Server.Com/ Millennium hand and shrimp! -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iQCVAwUBQ9D1bprNPMCpn3XdAQIguAP/W4N8a5bp0F0kqhLnInPkBb1Hgacg7r0D eBHx/NiyQzZ/qjsStvCh/Ud3dDSzVbTCno5mgoaM6lmqEgOJ/EqMVzD/lYmtt/0y Jl2dI4DrPRe7Y5UvWNM76dSaGob3xuGyhYLm2mVJYxDnow9L6MO6btrWOCsb8Ww7 48uwYXnlh1c= =1Dmb -END PGP SIGNATURE-
Re: CORBA incubation proposal
I'm interested in working on the ORB. My specific areas of interest are in object copying and marshalling. Alan, can you add me to the list of interested parties? Rick McGuire wrote: Alan D. Cabrera wrote: Here is the incubation proposal http://wiki.apache.org/incubator/CorbaProposal I'm interested in assisting with this. I was wrote the adapter code that allowed IBM's WAS CE product to work with the IBM JDK ORB. This required developing a pretty good understanding of how Geronimo hooks into the ORB, as well as finding places where hidden assumptions about ORB behavior created additional tie-ins to a single implementation. Does anyone have any comments before we vote on it? Should this also get sent to the incubator list or do we wait until after the vote? Alex Karasulu and I were talking about it and we both think that it might be a good idea to shoot for making this a TLP. Thoughts? Regards, Alan
releasing: it takes two
One thing I've been meaning to hit the list with now that we are formalizing our release process a bit more For every release I've done ever (in OpenEJB, Geronimo, or otherwise), the dynamic I call Pilot and Co-Pilot seems to always come in. You have the person leading the show, the Pilot (aka Release Manager) and someone dedicated to the pilot. The two of them are responsible for delivering a good release. It's just too much work to do a release completely alone; too much to remember and too many steps to do. You usually have someone putting in the hours with you dotting the is and crossing the ts while you are doing the tagging and branching, building and signing, etc. In OpenEJB for many of the releases is was me as pilot and Alan as co- pilot. For some Alan would be pilot and I would be co-pilot. In Geronimo, I seem to remember the releases going like this: 1.0-M1: David B. (pilot), Dain (co-pilot) 1.0-M2: David B. (pilot), Dain (co-pilot) 1.0-M3: David B. (pilot), Dain (co-pilot) Those were all done in the exact same Dunn Brothers coffee shop, ironically, and took 1-2 weeks each. In M3 we actually tried to do it at OSCON '04 and I lost Dain to endless meetings and the release just didn't happen till the second week after when we happened to be back in MN again. None of those releases could have happened without Dain. 1.0-M4: David B. (pilot), David J. (co-pilot) This one was a bit TCK release and it was David J. and I up till the wee hours of the morning the last three days and pushing binaries getting the last few tck results. I remember I screwed up the installer cause I built it from the branch and no the tag by mistake. Since David J. was working with me on it, he was able to figure it out and put out a good installer right away the next morning when people complained about it not working quite right. Definitely, that release would not exist without David J. He carries more than his weight in TCK work in all releases these days, but this one he did a significant amount of the polish on the binary work. 1.0-M5: Jeff (pilot), David B. (co-pilot) Jeff lead the charge with closing up issues, branching, etc., and I pretty much just did my best to try and figure out what it is I usually did for releases and communicate that to Jeff. David J. and I did the pre-final-build TCK testing and managed to get that done just before OSCON '05. The final run happened on David J's machine crow during OSCON '05. 1.0: Matt (pilot), David B. (co-pilot) Matt lead the charge. He gets the record for the most endurance displayed during a release cycle ;). This was the most community driven release to date namely because many of us in LA then San Diego for a week. TCK work done by David J. and myself. The final-final- final-final binaries created, signed and pushed to the mirrors by Matt with help from me. I'm not a very good co-pilot or I would have remembered to push the OpenEJB binaries at the same time we did the Geronimo ones :) Anyway, all releases should be community run and they are getting that way more and more. But I know from experience doing a release is hard work and you need a dedicated backup to really do it right. It's also the only real way to pass the release baton from one person to another: let them co-pilot a release with you and then let them be pilot on the next release; or let them be pilot and you be co-pilot. The proposal is that I think it would be great if we designated a pilot and co-pilot for every release cause that's pretty much the way every release has been done. I've also noticed that the quality of release seems to be very tied to how closely the pilot and co-pilot work together (i.e. less is overlooked). What do you guys think? -David
Re: [VOTE] Documentation in Confluence, MoinMoin, or..
+0 I think the quality of the documentation is more important than the documentation tool. But, if Confluence gives us features that would dramatically improve the documentation by all means change. However, assuming there's no easy way to slurp the existing pages into Confluence, I'd wonder if the conversion time would be worth it ... Jan Rodent of Unusual Size wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Anyone with an interest in working with the documentation, either directly or for some sort of postprocessing, please vote here. Unless there are problems, this vote will close in one week, at 14h00 UTC on 27 January 2006. At that point, a two-thirds majority will be a clear indicator of which way to go; any narrower majority will mean opinions are still too divided. Working documentation for Apache Geronimo should be kept in [ ] Confluence [ ] MoinMoin wiki [ ] Other (explain) This does not affect the need for 'solid' or released documentation to be under source control. This vote is only to decide a single collaborative environment for its development. - -- #kenP-)} Ken Coar, Sanagendamgagwedweinini http://Ken.Coar.Org/ Author, developer, opinionist http://Apache-Server.Com/ Millennium hand and shrimp! -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iQCVAwUBQ9D1bprNPMCpn3XdAQIguAP/W4N8a5bp0F0kqhLnInPkBb1Hgacg7r0D eBHx/NiyQzZ/qjsStvCh/Ud3dDSzVbTCno5mgoaM6lmqEgOJ/EqMVzD/lYmtt/0y Jl2dI4DrPRe7Y5UvWNM76dSaGob3xuGyhYLm2mVJYxDnow9L6MO6btrWOCsb8Ww7 48uwYXnlh1c= =1Dmb -END PGP SIGNATURE-
Re: CORBA incubation proposal
On 1/20/2006 4:57 AM, Anders Hessellund Jensen wrote: Trieloff, Carl wrote: One thing I just realized is that we don't want the sub-project to show up as being called CORBA Server. CORBA is trademarked by the OMG and that would be an infringement. Thus we can't use CORBA in the name of the project due to this trademark, so I would suggest something neutral like Transport Server. Yes. Guidelines regarding use of OMG trademarks can be found here: http://www.omg.org/legal/tm_guidelines.htm I'm no expert on trademark law, but as I understand it we are not allowed to use the term CORBA at all, unless we get permission from OMG. Its name isn't CORBA Server. It is being characterized as a CORBA server, which IIUC is perfectly legal. I shall initially name it Yoko, after my daughter. :D The community is free to rename it if we make it into incubation. Regards, Alan
Re: releasing: it takes two
I agree with this. The release can be difficult at best. And I appreciate you giving me *much* more credit that is due...you did a lot more than just a co-pilot (perhaps I should be scolding you for giving me more credit than is due) ;-) In any case, this is a great idea, and I would be happy to help co-pilot others in some coming releases. Having 2 is the way to go, and its a great learning experience to be able to learn from your peers, as everyone does things a little differently. Jeff David Blevins wrote: One thing I've been meaning to hit the list with now that we are formalizing our release process a bit more For every release I've done ever (in OpenEJB, Geronimo, or otherwise), the dynamic I call Pilot and Co-Pilot seems to always come in. You have the person leading the show, the Pilot (aka Release Manager) and someone dedicated to the pilot. The two of them are responsible for delivering a good release. It's just too much work to do a release completely alone; too much to remember and too many steps to do. You usually have someone putting in the hours with you dotting the is and crossing the ts while you are doing the tagging and branching, building and signing, etc. In OpenEJB for many of the releases is was me as pilot and Alan as co-pilot. For some Alan would be pilot and I would be co-pilot. In Geronimo, I seem to remember the releases going like this: 1.0-M1: David B. (pilot), Dain (co-pilot) 1.0-M2: David B. (pilot), Dain (co-pilot) 1.0-M3: David B. (pilot), Dain (co-pilot) Those were all done in the exact same Dunn Brothers coffee shop, ironically, and took 1-2 weeks each. In M3 we actually tried to do it at OSCON '04 and I lost Dain to endless meetings and the release just didn't happen till the second week after when we happened to be back in MN again. None of those releases could have happened without Dain. 1.0-M4: David B. (pilot), David J. (co-pilot) This one was a bit TCK release and it was David J. and I up till the wee hours of the morning the last three days and pushing binaries getting the last few tck results. I remember I screwed up the installer cause I built it from the branch and no the tag by mistake. Since David J. was working with me on it, he was able to figure it out and put out a good installer right away the next morning when people complained about it not working quite right. Definitely, that release would not exist without David J. He carries more than his weight in TCK work in all releases these days, but this one he did a significant amount of the polish on the binary work. 1.0-M5: Jeff (pilot), David B. (co-pilot) Jeff lead the charge with closing up issues, branching, etc., and I pretty much just did my best to try and figure out what it is I usually did for releases and communicate that to Jeff. David J. and I did the pre-final-build TCK testing and managed to get that done just before OSCON '05. The final run happened on David J's machine crow during OSCON '05. 1.0: Matt (pilot), David B. (co-pilot) Matt lead the charge. He gets the record for the most endurance displayed during a release cycle ;). This was the most community driven release to date namely because many of us in LA then San Diego for a week. TCK work done by David J. and myself. The final-final-final-final binaries created, signed and pushed to the mirrors by Matt with help from me. I'm not a very good co-pilot or I would have remembered to push the OpenEJB binaries at the same time we did the Geronimo ones :) Anyway, all releases should be community run and they are getting that way more and more. But I know from experience doing a release is hard work and you need a dedicated backup to really do it right. It's also the only real way to pass the release baton from one person to another: let them co-pilot a release with you and then let them be pilot on the next release; or let them be pilot and you be co-pilot. The proposal is that I think it would be great if we designated a pilot and co-pilot for every release cause that's pretty much the way every release has been done. I've also noticed that the quality of release seems to be very tied to how closely the pilot and co-pilot work together (i.e. less is overlooked). What do you guys think? -David
Re: releasing: it takes two
On Jan 20, 2006, at 12:20 PM, Jeff Genender wrote: I agree with this. The release can be difficult at best. And I appreciate you giving me *much* more credit that is due...you did a lot more than just a co-pilot (perhaps I should be scolding you for giving me more credit than is due) ;-) Well it was the first time we tried someone else as pilot. Learning experience for us all. I'm thinking it probably wasn't fair to put you or Matt in the pilot seat without having co-piloted a release first, but then again that may be the best way to learn. Time will tell I guess. In any case, this is a great idea, and I would be happy to help co- pilot others in some coming releases. Having 2 is the way to go, and its a great learning experience to be able to learn from your peers, as everyone does things a little differently. You said a keyword (peer) that just made me go duh! This is pretty much peer programming but for releases. Not really a new concept. -David Jeff David Blevins wrote: One thing I've been meaning to hit the list with now that we are formalizing our release process a bit more For every release I've done ever (in OpenEJB, Geronimo, or otherwise), the dynamic I call Pilot and Co-Pilot seems to always come in. You have the person leading the show, the Pilot (aka Release Manager) and someone dedicated to the pilot. The two of them are responsible for delivering a good release. It's just too much work to do a release completely alone; too much to remember and too many steps to do. You usually have someone putting in the hours with you dotting the is and crossing the ts while you are doing the tagging and branching, building and signing, etc. In OpenEJB for many of the releases is was me as pilot and Alan as co-pilot. For some Alan would be pilot and I would be co-pilot. In Geronimo, I seem to remember the releases going like this: 1.0-M1: David B. (pilot), Dain (co-pilot) 1.0-M2: David B. (pilot), Dain (co-pilot) 1.0-M3: David B. (pilot), Dain (co-pilot) Those were all done in the exact same Dunn Brothers coffee shop, ironically, and took 1-2 weeks each. In M3 we actually tried to do it at OSCON '04 and I lost Dain to endless meetings and the release just didn't happen till the second week after when we happened to be back in MN again. None of those releases could have happened without Dain. 1.0-M4: David B. (pilot), David J. (co-pilot) This one was a bit TCK release and it was David J. and I up till the wee hours of the morning the last three days and pushing binaries getting the last few tck results. I remember I screwed up the installer cause I built it from the branch and no the tag by mistake. Since David J. was working with me on it, he was able to figure it out and put out a good installer right away the next morning when people complained about it not working quite right. Definitely, that release would not exist without David J. He carries more than his weight in TCK work in all releases these days, but this one he did a significant amount of the polish on the binary work. 1.0-M5: Jeff (pilot), David B. (co-pilot) Jeff lead the charge with closing up issues, branching, etc., and I pretty much just did my best to try and figure out what it is I usually did for releases and communicate that to Jeff. David J. and I did the pre-final-build TCK testing and managed to get that done just before OSCON '05. The final run happened on David J's machine crow during OSCON '05. 1.0: Matt (pilot), David B. (co-pilot) Matt lead the charge. He gets the record for the most endurance displayed during a release cycle ;). This was the most community driven release to date namely because many of us in LA then San Diego for a week. TCK work done by David J. and myself. The final-final-final-final binaries created, signed and pushed to the mirrors by Matt with help from me. I'm not a very good co-pilot or I would have remembered to push the OpenEJB binaries at the same time we did the Geronimo ones :) Anyway, all releases should be community run and they are getting that way more and more. But I know from experience doing a release is hard work and you need a dedicated backup to really do it right. It's also the only real way to pass the release baton from one person to another: let them co-pilot a release with you and then let them be pilot on the next release; or let them be pilot and you be co-pilot. The proposal is that I think it would be great if we designated a pilot and co-pilot for every release cause that's pretty much the way every release has been done. I've also noticed that the quality of release seems to be very tied to how closely the pilot and co-pilot work together (i.e. less is overlooked). What do you guys think? -David
Re: Cut date for 1.1?
On Jan 20, 2006, at 11:42 AM, Rodent of Unusual Size wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Dain Sundstrom wrote: Regardless, of this change, I don't want to be the one that checks in stuff that breaks the build or TCK 3 days before a branch is cut. Who is the release manager? If there isn't one, then there's no point worrying about any particular date. The release manager gets to call the shots on freeze, thaw, and cut dates. Um, I really disagree here. If the release is cut on Fiday and I check in code on Thrudaay that breaks the release, I'm going to get blamed regardless of who makes the decision to cut. Anyway, who is running this release and are we cutting on Friday? -dain
Re: Cut date for 1.1?
This is really a discussion for the openejb mailing list, but since you asked here I'll respond here. On Jan 20, 2006, at 11:17 AM, David Jencks wrote: On Jan 20, 2006, at 9:59 AM, Dain Sundstrom wrote: On Jan 20, 2006, at 9:46 AM, David Jencks wrote: Personally I am not ready for 1.1 to be frozen. Also, there is at least one major bug (tomcat cross-context dispatch) that needs to be fixed and I haven't seen any progress on it. The nature of your change might affect other peoples opinion on this also, what are you planning? I am working on splitting the OpenEJB container into one object for each deployed ejb and a set of share invocation processing ejb containers. This is a refactoring of internal interfaces well below the layer our users see. Does this mean there will be one interceptor stack for each ejb type, shared among all the e.g. stateless sesssion ejbs? By default, yes. The idea is you can deploy extra invocation processors that have different QoSes configured and then you assign an ejb to the processor you want. What is the advantage of this design? I think the important important advantage for OpenEJB is that this change aligns the 2 code with the 1 code. The other big advantage is that it the job of a deployer is simpler because the most complex configurations (like caches) are placed on the invocation processors which will be defined using he generic gbean xml tags. I can think of some disadvantages compared to our present design but no advantages. Probably just a lack of imagination, but I'd really appreciate discussion of architectural changes before the code arrives. The architectural change is to split the current EJB container into a service for each EJB and a shared service for invocation processing. If you want to have a discussion on this, we should move to the openejb dev mailing list. -dain
Fw: Error deploying Servlet 2.3 application
Vijay Balasubramanian DPRA Inc., - Forwarded by Vijay Balasubramanian/R6/USEPA/US on 01/20/2006 03:10 PM - Vijay Balasubramanian/ R6/USEPA/[EMAIL PROTECTED] To user@geronimo.apache.org 01/20/2006 01:48cc PM Subject Error deploying Servlet 2.3 Please respond application to [EMAIL PROTECTED] ache.org Hello, I am trying to deploy a servlet 2.3 application( with 2.3 dtd specified in web.xml) in version 1.0. I am seeing 2.4 xml schema stuff gets prepended as below and i get the following error. I get the same error when i deploy with a plan file or not, command line or console. Am i missing something here, should there be a flag set in geronimo config. Please let me know if you have any info on this. Thanks, Vijay Caused by: org.apache.xmlbeans.XmlException: Invalid deployment descriptor: [err or: cvc-complex-type.2.4b: Element not allowed: [EMAIL PROTECTED]://java.sun.com/ xml/ns/j2ee in element [EMAIL PROTECTED]://java.sun.com/xml/ns/j2ee, error: cvc -complex-type.2.4b: Element not allowed: [EMAIL PROTECTED]://java.sun.com/xml/ns/ j2ee in element [EMAIL PROTECTED]://java.sun.com/xml/ns/j2ee, error: cvc-comple x-type.2.4b: Element not allowed: [EMAIL PROTECTED]://java.sun.com/xml/ns/j2ee in element [EMAIL PROTECTED]://java.sun.com/xml/ns/j2ee, error: cvc-complex-type. 2.4b: Element not allowed: [EMAIL PROTECTED]://java.sun.com/xml/ns/j2ee in elemen t [EMAIL PROTECTED]://java.sun.com/xml/ns/j2ee, error: cvc-complex-type.2.4b: E lement not allowed: [EMAIL PROTECTED]://java.sun.com/xml/ns/j2ee in element conte [EMAIL PROTECTED]://java.sun.com/xml/ns/j2ee, error: cvc-complex-type.2.4b: Element not allowed: [EMAIL PROTECTED]://java.sun.com/xml/ns/j2ee in element context-para [EMAIL PROTECTED]://java.sun.com/xml/ns/j2ee, error: cvc-complex-type.2.4b: Element not all owed: [EMAIL PROTECTED]://java.sun.com/xml/ns/j2ee in element [EMAIL PROTECTED]: //java.sun.com/xml/ns/j2ee] Descriptor: web-app xsi:schemaLocation=http://java.sun.com/xml/ns/j2eehttp://j ava.sun.com/xml/ns/j2ee/web-app_2_4.xsd version=2.4 id=sdmsc xmlns:xsi=htt p://www.w3.org/2001/XMLSchema-instance xmlns=http://java.sun.com/xml/ns/j2ee; ! My web.xml is printed here --- /web-app at org.apache.geronimo.schema.SchemaConversionUtils.validateDD(SchemaCon versionUtils.java:594) at org.apache.geronimo.schema.SchemaConversionUtils.convertToServletSche ma(SchemaConversionUtils.java:318) at org.apache.geronimo.tomcat.deployment.TomcatModuleBuilder.createModul e(TomcatModuleBuilder.java:176) ... 79 more java.lang.ArrayIndexOutOfBoundsException: 8192 at org.apache.coyote.http11.InternalOutputBuffer.write(InternalOutputBuf fer.java:721) at org.apache.coyote.http11.InternalOutputBuffer.write(InternalOutputBuf fer.java:628) at org.apache.coyote.http11.InternalOutputBuffer.sendHeader(InternalOutp utBuffer.java:501) at org.apache.coyote.http11.Http11Processor.prepareResponse(Http11Proces sor.java:1592) at org.apache.coyote.http11.Http11Processor.action(Http11Processor.java: 949) at org.apache.coyote.Response.action(Response.java:182) at org.apache.coyote.Response.sendHeaders(Response.java:374) at org.apache.catalina.connector.OutputBuffer.doFlush(OutputBuffer.java: 317) at org.apache.catalina.connector.OutputBuffer.close(OutputBuffer.java:27 8) at org.apache.catalina.connector.Response.finishResponse(Response.java:4 73) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.jav a:151) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java :856) at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.proce ssConnection(Http11Protocol.java:744) at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpo int.java:527) at org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(LeaderFol lowerWorkerThread.java:80) at
Re: Fw: Error deploying Servlet 2.3 application
Please post your web.xml for us to review. Thanks, Aaron On 1/20/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Vijay Balasubramanian DPRA Inc., - Forwarded by Vijay Balasubramanian/R6/USEPA/US on 01/20/2006 03:10 PM - Vijay Balasubramanian/ R6/USEPA/[EMAIL PROTECTED] To user@geronimo.apache.org 01/20/2006 01:48cc PM Subject Error deploying Servlet 2.3 Please respond application to [EMAIL PROTECTED] ache.org Hello, I am trying to deploy a servlet 2.3 application( with 2.3 dtd specified in web.xml) in version 1.0. I am seeing 2.4 xml schema stuff gets prepended as below and i get the following error. I get the same error when i deploy with a plan file or not, command line or console. Am i missing something here, should there be a flag set in geronimo config. Please let me know if you have any info on this. Thanks, Vijay Caused by: org.apache.xmlbeans.XmlException: Invalid deployment descriptor: [err or: cvc-complex-type.2.4b: Element not allowed: [EMAIL PROTECTED]://java.sun.com/ xml/ns/j2ee in element [EMAIL PROTECTED]://java.sun.com/xml/ns/j2ee, error: cvc -complex-type.2.4b: Element not allowed: [EMAIL PROTECTED]://java.sun.com/xml/ns/ j2ee in element [EMAIL PROTECTED]://java.sun.com/xml/ns/j2ee, error: cvc-comple x-type.2.4b: Element not allowed: [EMAIL PROTECTED]://java.sun.com/xml/ns/j2ee in element [EMAIL PROTECTED]://java.sun.com/xml/ns/j2ee, error: cvc-complex-type. 2.4b: Element not allowed: [EMAIL PROTECTED]://java.sun.com/xml/ns/j2ee in elemen t [EMAIL PROTECTED]://java.sun.com/xml/ns/j2ee, error: cvc-complex-type.2.4b: E lement not allowed: [EMAIL PROTECTED]://java.sun.com/xml/ns/j2ee in element conte [EMAIL PROTECTED]://java.sun.com/xml/ns/j2ee, error: cvc-complex-type.2.4b: Element not allowed: [EMAIL PROTECTED]://java.sun.com/xml/ns/j2ee in element context-para [EMAIL PROTECTED]://java.sun.com/xml/ns/j2ee, error: cvc-complex-type.2.4b: Element not all owed: [EMAIL PROTECTED]://java.sun.com/xml/ns/j2ee in element [EMAIL PROTECTED]: //java.sun.com/xml/ns/j2ee] Descriptor: web-app xsi:schemaLocation=http://java.sun.com/xml/ns/j2eehttp://j ava.sun.com/xml/ns/j2ee/web-app_2_4.xsd version=2.4 id=sdmsc xmlns:xsi=htt p://www.w3.org/2001/XMLSchema-instance xmlns=http://java.sun.com/xml/ns/j2ee; ! My web.xml is printed here --- /web-app at org.apache.geronimo.schema.SchemaConversionUtils.validateDD(SchemaCon versionUtils.java:594) at org.apache.geronimo.schema.SchemaConversionUtils.convertToServletSche ma(SchemaConversionUtils.java:318) at org.apache.geronimo.tomcat.deployment.TomcatModuleBuilder.createModul e(TomcatModuleBuilder.java:176) ... 79 more java.lang.ArrayIndexOutOfBoundsException: 8192 at org.apache.coyote.http11.InternalOutputBuffer.write(InternalOutputBuf fer.java:721) at org.apache.coyote.http11.InternalOutputBuffer.write(InternalOutputBuf fer.java:628) at org.apache.coyote.http11.InternalOutputBuffer.sendHeader(InternalOutp utBuffer.java:501) at org.apache.coyote.http11.Http11Processor.prepareResponse(Http11Proces sor.java:1592) at org.apache.coyote.http11.Http11Processor.action(Http11Processor.java: 949) at org.apache.coyote.Response.action(Response.java:182) at org.apache.coyote.Response.sendHeaders(Response.java:374) at org.apache.catalina.connector.OutputBuffer.doFlush(OutputBuffer.java: 317) at org.apache.catalina.connector.OutputBuffer.close(OutputBuffer.java:27 8) at org.apache.catalina.connector.Response.finishResponse(Response.java:4 73) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.jav a:151) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java :856) at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.proce ssConnection(Http11Protocol.java:744) at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpo int.java:527) at org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(LeaderFol lowerWorkerThread.java:80) at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadP ool.java:684) at java.lang.Thread.run(Thread.java:534) 13:34:21,248 ERROR [Http11Processor] Error finishing response java.lang.ArrayIndexOutOfBoundsException at java.lang.System.arraycopy(Native Method) at org.apache.coyote.http11.InternalOutputBuffer.write(InternalOutputBuf fer.java:690) at
[jira] Closed: (GERONIMO-1506) DB info portlet should use new GeronimoVersion
[ http://issues.apache.org/jira/browse/GERONIMO-1506?page=all ] Matt Hogstrom closed GERONIMO-1506: --- Fix Version: 1.0.1 1.1 Resolution: Fixed Assign To: Paul McMahan Applied patch to 1.1 and 1.0.1 branches ~/dev/geronimo/branches/1.0/applications hogstrom$ svn commit -m GERONIMO-1506 Database portlet version issue Sending applications/console-standard/src/java/org/apache/geronimo/console/internaldb/DerbyConnectionUtil.java Transmitting file data . Committed revision 370911. Hogstrom:~/dev/geronimo/branches/1.0/applications hogstrom$ cd ../../../trunk/applications/ Hogstrom:~/dev/geronimo/trunk/applications hogstrom$ svn commit -m GERONIMO-1506 Database portlet version issue Sending applications/console-standard/src/java/org/apache/geronimo/console/internaldb/DerbyConnectionUtil.java Transmitting file data . Committed revision 370912. DB info portlet should use new GeronimoVersion -- Key: GERONIMO-1506 URL: http://issues.apache.org/jira/browse/GERONIMO-1506 Project: Geronimo Type: Bug Components: console Versions: 1.0.1 Reporter: Paul McMahan Assignee: Paul McMahan Fix For: 1.0.1, 1.1 Attachments: GERONIMO-1506.patch The DB info portlet currently refers to the system database using a hard coded version number. It should use the new GeronimoVersion.GERONIMO_VERSION for the version number instead. Without this fix the DB info portlet shows no data. -- 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
Docco system (Confluent, MoinMoin, ...)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Just some food for thought on the 'which docco system' discussion/vote/etc.. Whatever system gets chosen will need to be running on Apache hardware. That's not an issue for MoinMoin, since it's already there and the infra people are familiar with it. However, if Confluence is the option the project decides to adopt, more is involved than just saying so: some people from the project are going to have to join the infrastructure team and become the Confluence experts and maintainers. If Confluence is selected but no-one will step up to provide the necessary expertise and commitment to make it happen, then Geronimo won't be using Confluence. The all-volunteer infrastructure team is already overloaded; adding yet another application for it to support without adding resources to help in the supporting just isn't going to fly. So, distinct from the voting, if you'd be willing to be one of the supporters of the Confluence environment at the ASF, please speak up here. Or if you have any other comments about the Confluence/MoinMoin/whatever topic. :-) The infrastructure team may require that anyone joining to support Confluence (if it comes to that) may need to be a project committer. I'm not sure; I'm checking. But if you're not a committer [yet] but are willing to help out with Confluence, don't let that stop you from volunteering! - -- #kenP-)} Ken Coar, Sanagendamgagwedweinini http://Ken.Coar.Org/ Author, developer, opinionist http://Apache-Server.Com/ Millennium hand and shrimp! -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iQCVAwUBQ9Fn55rNPMCpn3XdAQLLrAQA0LCKsMsAMa/GQNmbH0ntpYbp2W9Wic26 4ZawAu6Z+L3reo9tNQPuhD6CG/6NOYc9prM7ybqCM9pKYPTZTEJ5oybMJnIIy7Gt 2yLVL259aRrEFPKWkwoS5MBkmxXt5LvzkPN2YnKtBdP7jDWPeonxQHzZP1EHd4RW d7JblzKcw3A= =++zP -END PGP SIGNATURE-
Re: Cut date for 1.1?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Dain Sundstrom wrote: Who is the release manager? If there isn't one, then there's no point worrying about any particular date. The release manager gets to call the shots on freeze, thaw, and cut dates. Um, I really disagree here. If the release is cut on Fiday and I check in code on Thrudaay that breaks the release, I'm going to get blamed regardless of who makes the decision to cut. I see no disagreement. That's right, if the release manager says 'no more commits' and you go ahead and commit, you're going to get blamed whether it breaks things or not. It's the release manager's responsibility to coordinate dates so that such brokenness gets detected before the freeze. One possible scenario would be for the RM to say, 'Okey, we're frozen. Regression tests run now. If nothing pops up, we'll cut and then unfreeze and go back to commit mode.' It's the RM's call. - -- #kenP-)} Ken Coar, Sanagendamgagwedweinini http://Ken.Coar.Org/ Author, developer, opinionist http://Apache-Server.Com/ Millennium hand and shrimp! -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iQCVAwUBQ9FpqprNPMCpn3XdAQL1EAQAnN9gGYfu+++gZMRGc3vbq5w1RS3dllki JBnVoGUDgcGsTbEVMMCOkzuqDlacTAD62cSwBTxpEFp5s/S0q/nxOG6BAFUwLli6 TrCF3avuNAQM85UlDog/XyXN1wczWW5l0Wwjxv1TfXTb42nYJ0yhx6Fxtc+Q51zz jxzymExJYN4= =uZ3b -END PGP SIGNATURE-
Re: [VOTE] Documentation in Confluence, MoinMoin, or..
+1 Confluence Gianny Rodent of Unusual Size wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Anyone with an interest in working with the documentation, either directly or for some sort of postprocessing, please vote here. Unless there are problems, this vote will close in one week, at 14h00 UTC on 27 January 2006. At that point, a two-thirds majority will be a clear indicator of which way to go; any narrower majority will mean opinions are still too divided. Working documentation for Apache Geronimo should be kept in [ ] Confluence [ ] MoinMoin wiki [ ] Other (explain) This does not affect the need for 'solid' or released documentation to be under source control. This vote is only to decide a single collaborative environment for its development. - -- #kenP-)} Ken Coar, Sanagendamgagwedweinini http://Ken.Coar.Org/ Author, developer, opinionist http://Apache-Server.Com/ Millennium hand and shrimp! -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iQCVAwUBQ9D1bprNPMCpn3XdAQIguAP/W4N8a5bp0F0kqhLnInPkBb1Hgacg7r0D eBHx/NiyQzZ/qjsStvCh/Ud3dDSzVbTCno5mgoaM6lmqEgOJ/EqMVzD/lYmtt/0y Jl2dI4DrPRe7Y5UvWNM76dSaGob3xuGyhYLm2mVJYxDnow9L6MO6btrWOCsb8Ww7 48uwYXnlh1c= =1Dmb -END PGP SIGNATURE-
[jira] Commented: (GERONIMO-1510) NPE in connector DConfigBeans if no config params present on connection definition instance
[ http://issues.apache.org/jira/browse/GERONIMO-1510?page=comments#action_12363481 ] Aaron Mulder commented on GERONIMO-1510: More problems revealed by more extensive testing: If XATransactions are set on the RAR that's not detected properly and the DConfigBeans don't default to XA transactions due to a typo on ConnectionManager:56 The ConnectionManager DConfigBean getter for the thread-caching element is erroneously checking for the transaction-caching element instead. NPE in connector DConfigBeans if no config params present on connection definition instance --- Key: GERONIMO-1510 URL: http://issues.apache.org/jira/browse/GERONIMO-1510 Project: Geronimo Type: Bug Components: connector Versions: 1.0 Reporter: Aaron Mulder Fix For: 1.1, 1.0.1 Attachments: dconfigbeans.patch, jms.rar Observed when loading a JMS plan that has no config params on the connection definition instance -- 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] Reopened: (GERONIMO-1506) DB info portlet should use new GeronimoVersion
[ http://issues.apache.org/jira/browse/GERONIMO-1506?page=all ] Aaron Mulder reopened GERONIMO-1506: Assign To: Aaron Mulder (was: Paul McMahan) I don't think this issue should be closed until we resolve the version-in-configId issue. One of the proposals on the table is to leave the configId versions at 1.0 even if the product version is 1.0.1. If that was done, it's not clear what the version constant would say, and whether the resulting configId construction would be correct. I don't think we should apply more changes of this nature until that issue is resolved. DB info portlet should use new GeronimoVersion -- Key: GERONIMO-1506 URL: http://issues.apache.org/jira/browse/GERONIMO-1506 Project: Geronimo Type: Bug Components: console Versions: 1.0.1 Reporter: Paul McMahan Assignee: Aaron Mulder Fix For: 1.0.1, 1.1 Attachments: GERONIMO-1506.patch The DB info portlet currently refers to the system database using a hard coded version number. It should use the new GeronimoVersion.GERONIMO_VERSION for the version number instead. Without this fix the DB info portlet shows no data. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (GERONIMO-1517) Installer - Install Derby with base J2EE Features
[ http://issues.apache.org/jira/browse/GERONIMO-1517?page=all ] erik daughtrey updated GERONIMO-1517: - Attachment: installer-derby-as-j2ee-feature.patch Apply this fix to both trunk and branches/1.0. Installer - Install Derby with base J2EE Features - Key: GERONIMO-1517 URL: http://issues.apache.org/jira/browse/GERONIMO-1517 Project: Geronimo Type: Bug Components: installer Versions: 1.1, 1.0.1 Reporter: erik daughtrey Attachments: installer-derby-as-j2ee-feature.patch -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (GERONIMO-1517) Installer - Install Derby with base J2EE Features
[ http://issues.apache.org/jira/browse/GERONIMO-1517?page=all ] erik daughtrey updated GERONIMO-1517: - Geronimo Info: [Patch Available] Installer - Install Derby with base J2EE Features - Key: GERONIMO-1517 URL: http://issues.apache.org/jira/browse/GERONIMO-1517 Project: Geronimo Type: Bug Components: installer Versions: 1.1, 1.0.1 Reporter: erik daughtrey Attachments: installer-derby-as-j2ee-feature.patch -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Assigned: (GERONIMO-1517) Installer - Install Derby with base J2EE Features
[ http://issues.apache.org/jira/browse/GERONIMO-1517?page=all ] David Jencks reassigned GERONIMO-1517: -- Assign To: David Jencks Installer - Install Derby with base J2EE Features - Key: GERONIMO-1517 URL: http://issues.apache.org/jira/browse/GERONIMO-1517 Project: Geronimo Type: Bug Components: installer Versions: 1.1, 1.0.1 Reporter: erik daughtrey Assignee: David Jencks Attachments: installer-derby-as-j2ee-feature.patch -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (GERONIMO-1505) Installer should default Tomcat on at runtime if Jetty pack is not selected
[ http://issues.apache.org/jira/browse/GERONIMO-1505?page=comments#action_12363493 ] David Jencks commented on GERONIMO-1505: Applied with 1514 and 1517 to trunk. Sendingassemblies/j2ee-installer/src/izpack/geronimo-izpack.xml Sendingassemblies/j2ee-installer/src/izpack/izpack-user-input.xml Sending modules/installer-processing/src/java/org/apache/geronimo/installer/processing/ConfigInstaller.java Sending modules/installer-support/src/java/com/izforge/izpack/panels/GeronimoConfigProcessor.java Sending modules/installer-support/src/java/com/izforge/izpack/panels/PasswordGroup.java Sending modules/installer-support/src/java/com/izforge/izpack/panels/ProcessPanelAutomationHelper.java Sending modules/installer-support/src/java/com/izforge/izpack/panels/ProcessingClient.java Sending modules/installer-support/src/java/com/izforge/izpack/panels/Processor.java Sending modules/installer-support/src/java/com/izforge/izpack/panels/RuleInputField.java Sending modules/installer-support/src/java/com/izforge/izpack/panels/RuleTextField.java Sending modules/installer-support/src/java/com/izforge/izpack/panels/ValidatePackSelections.java Sending modules/installer-support/src/java/com/izforge/izpack/panels/ValidatePackSelectionsAutomationHelper.java Sending modules/installer-support/src/java/com/izforge/izpack/panels/Validator.java Transmitting file data . Committed revision 370956. Installer should default Tomcat on at runtime if Jetty pack is not selected --- Key: GERONIMO-1505 URL: http://issues.apache.org/jira/browse/GERONIMO-1505 Project: Geronimo Type: Bug Components: installer Versions: 1.0 Reporter: erik daughtrey Assignee: David Jencks Attachments: installer-tomcat-only-wc-config-fix.patch When both Jetty and Tomcat are selected for install, the installer will default Jetty to active at runtime and Tomcat as off by default. If Jetty is not selected for install and Tomcat is, then Tomcat should default to active at runtime. Currently it does not. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (GERONIMO-1514) Fix installer license statements
[ http://issues.apache.org/jira/browse/GERONIMO-1514?page=comments#action_12363494 ] David Jencks commented on GERONIMO-1514: Applied with 1505 and 1517 to trunk Sendingassemblies/j2ee-installer/src/izpack/geronimo-izpack.xml Sendingassemblies/j2ee-installer/src/izpack/izpack-user-input.xml Sending modules/installer-processing/src/java/org/apache/geronimo/installer/processing/ConfigInstaller.java Sending modules/installer-support/src/java/com/izforge/izpack/panels/GeronimoConfigProcessor.java Sending modules/installer-support/src/java/com/izforge/izpack/panels/PasswordGroup.java Sending modules/installer-support/src/java/com/izforge/izpack/panels/ProcessPanelAutomationHelper.java Sending modules/installer-support/src/java/com/izforge/izpack/panels/ProcessingClient.java Sending modules/installer-support/src/java/com/izforge/izpack/panels/Processor.java Sending modules/installer-support/src/java/com/izforge/izpack/panels/RuleInputField.java Sending modules/installer-support/src/java/com/izforge/izpack/panels/RuleTextField.java Sending modules/installer-support/src/java/com/izforge/izpack/panels/ValidatePackSelections.java Sending modules/installer-support/src/java/com/izforge/izpack/panels/ValidatePackSelectionsAutomationHelper.java Sending modules/installer-support/src/java/com/izforge/izpack/panels/Validator.java Transmitting file data . Committed revision 370956. Fix installer license statements Key: GERONIMO-1514 URL: http://issues.apache.org/jira/browse/GERONIMO-1514 Project: Geronimo Type: Task Components: installer Versions: 1.0 Reporter: erik daughtrey Assignee: David Jencks Attachments: installer-license-text-fix.patch They need to be fixed for both branches/1,0 and trunk -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (GERONIMO-1517) Installer - Install Derby with base J2EE Features
[ http://issues.apache.org/jira/browse/GERONIMO-1517?page=comments#action_12363495 ] David Jencks commented on GERONIMO-1517: applied with 1505 and 1514 to trunk Sendingassemblies/j2ee-installer/src/izpack/geronimo-izpack.xml Sendingassemblies/j2ee-installer/src/izpack/izpack-user-input.xml Sending modules/installer-processing/src/java/org/apache/geronimo/installer/processing/ConfigInstaller.java Sending modules/installer-support/src/java/com/izforge/izpack/panels/GeronimoConfigProcessor.java Sending modules/installer-support/src/java/com/izforge/izpack/panels/PasswordGroup.java Sending modules/installer-support/src/java/com/izforge/izpack/panels/ProcessPanelAutomationHelper.java Sending modules/installer-support/src/java/com/izforge/izpack/panels/ProcessingClient.java Sending modules/installer-support/src/java/com/izforge/izpack/panels/Processor.java Sending modules/installer-support/src/java/com/izforge/izpack/panels/RuleInputField.java Sending modules/installer-support/src/java/com/izforge/izpack/panels/RuleTextField.java Sending modules/installer-support/src/java/com/izforge/izpack/panels/ValidatePackSelections.java Sending modules/installer-support/src/java/com/izforge/izpack/panels/ValidatePackSelectionsAutomationHelper.java Sending modules/installer-support/src/java/com/izforge/izpack/panels/Validator.java Transmitting file data . Committed revision 370956. Installer - Install Derby with base J2EE Features - Key: GERONIMO-1517 URL: http://issues.apache.org/jira/browse/GERONIMO-1517 Project: Geronimo Type: Bug Components: installer Versions: 1.1, 1.0.1 Reporter: erik daughtrey Assignee: David Jencks Attachments: installer-derby-as-j2ee-feature.patch -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (GERONIMO-1192) Installer should create a config.xml for the target install
[ http://issues.apache.org/jira/browse/GERONIMO-1192?page=all ] John Sisson closed GERONIMO-1192: - Fix Version: 1.1 Resolution: Fixed Installer should create a config.xml for the target install --- Key: GERONIMO-1192 URL: http://issues.apache.org/jira/browse/GERONIMO-1192 Project: Geronimo Type: New Feature Components: installer Versions: 1.0-M5 Environment: Installer runtime Reporter: erik daughtrey Assignee: John Sisson Fix For: 1.0.1, 1.1 Attachments: 20051214_jsisson_patch_installer.patch, installer-200512111301.patch, installer-200512112003.patch, installer-200512121118.patch, installer-200512122002.patch, installer-branches-1.0-12151601.patch.gz, installer-branches-1.0-200512181734.patch.gz, installer_1192_200512080036.patch DJ - This could be done by adding bits associated with each configuration, or by removing chunks from a 'universal' config.xml for the configuations we didn't install. -- 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-1505) Installer should default Tomcat on at runtime if Jetty pack is not selected
[ http://issues.apache.org/jira/browse/GERONIMO-1505?page=all ] David Jencks closed GERONIMO-1505: -- Fix Version: 1.0.1 1.1 Resolution: Fixed with 1514, 1517, to branch 1.0 Sendingassemblies/j2ee-installer/src/izpack/geronimo-izpack.xml Sendingassemblies/j2ee-installer/src/izpack/izpack-user-input.xml Sending modules/installer-processing/src/java/org/apache/geronimo/installer/processing/ConfigInstaller.java Sending modules/installer-support/src/java/com/izforge/izpack/panels/GeronimoConfigProcessor.java Sending modules/installer-support/src/java/com/izforge/izpack/panels/PasswordGroup.java Sending modules/installer-support/src/java/com/izforge/izpack/panels/ProcessPanelAutomationHelper.java Sending modules/installer-support/src/java/com/izforge/izpack/panels/ProcessingClient.java Sending modules/installer-support/src/java/com/izforge/izpack/panels/Processor.java Sending modules/installer-support/src/java/com/izforge/izpack/panels/RuleInputField.java Sending modules/installer-support/src/java/com/izforge/izpack/panels/RuleTextField.java Sending modules/installer-support/src/java/com/izforge/izpack/panels/ValidatePackSelections.java Sending modules/installer-support/src/java/com/izforge/izpack/panels/ValidatePackSelectionsAutomationHelper.java Sending modules/installer-support/src/java/com/izforge/izpack/panels/Validator.java Transmitting file data . Committed revision 370961. Installer should default Tomcat on at runtime if Jetty pack is not selected --- Key: GERONIMO-1505 URL: http://issues.apache.org/jira/browse/GERONIMO-1505 Project: Geronimo Type: Bug Components: installer Versions: 1.0 Reporter: erik daughtrey Assignee: David Jencks Fix For: 1.1, 1.0.1 Attachments: installer-tomcat-only-wc-config-fix.patch When both Jetty and Tomcat are selected for install, the installer will default Jetty to active at runtime and Tomcat as off by default. If Jetty is not selected for install and Tomcat is, then Tomcat should default to active at runtime. Currently it does not. -- 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-1514) Fix installer license statements
[ http://issues.apache.org/jira/browse/GERONIMO-1514?page=all ] David Jencks closed GERONIMO-1514: -- Fix Version: 1.0.1 1.1 Resolution: Fixed with 1505, 1517, to branch 1.0 Sendingassemblies/j2ee-installer/src/izpack/geronimo-izpack.xml Sendingassemblies/j2ee-installer/src/izpack/izpack-user-input.xml Sending modules/installer-processing/src/java/org/apache/geronimo/installer/processing/ConfigInstaller.java Sending modules/installer-support/src/java/com/izforge/izpack/panels/GeronimoConfigProcessor.java Sending modules/installer-support/src/java/com/izforge/izpack/panels/PasswordGroup.java Sending modules/installer-support/src/java/com/izforge/izpack/panels/ProcessPanelAutomationHelper.java Sending modules/installer-support/src/java/com/izforge/izpack/panels/ProcessingClient.java Sending modules/installer-support/src/java/com/izforge/izpack/panels/Processor.java Sending modules/installer-support/src/java/com/izforge/izpack/panels/RuleInputField.java Sending modules/installer-support/src/java/com/izforge/izpack/panels/RuleTextField.java Sending modules/installer-support/src/java/com/izforge/izpack/panels/ValidatePackSelections.java Sending modules/installer-support/src/java/com/izforge/izpack/panels/ValidatePackSelectionsAutomationHelper.java Sending modules/installer-support/src/java/com/izforge/izpack/panels/Validator.java Transmitting file data . Committed revision 370961. Fix installer license statements Key: GERONIMO-1514 URL: http://issues.apache.org/jira/browse/GERONIMO-1514 Project: Geronimo Type: Task Components: installer Versions: 1.0 Reporter: erik daughtrey Assignee: David Jencks Fix For: 1.0.1, 1.1 Attachments: installer-license-text-fix.patch They need to be fixed for both branches/1,0 and trunk -- 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-1517) Installer - Install Derby with base J2EE Features
[ http://issues.apache.org/jira/browse/GERONIMO-1517?page=all ] David Jencks closed GERONIMO-1517: -- Fix Version: 1.0.1 1.1 Resolution: Fixed With 1505, 1514, to branch 1.0 Sendingassemblies/j2ee-installer/src/izpack/geronimo-izpack.xml Sendingassemblies/j2ee-installer/src/izpack/izpack-user-input.xml Sending modules/installer-processing/src/java/org/apache/geronimo/installer/processing/ConfigInstaller.java Sending modules/installer-support/src/java/com/izforge/izpack/panels/GeronimoConfigProcessor.java Sending modules/installer-support/src/java/com/izforge/izpack/panels/PasswordGroup.java Sending modules/installer-support/src/java/com/izforge/izpack/panels/ProcessPanelAutomationHelper.java Sending modules/installer-support/src/java/com/izforge/izpack/panels/ProcessingClient.java Sending modules/installer-support/src/java/com/izforge/izpack/panels/Processor.java Sending modules/installer-support/src/java/com/izforge/izpack/panels/RuleInputField.java Sending modules/installer-support/src/java/com/izforge/izpack/panels/RuleTextField.java Sending modules/installer-support/src/java/com/izforge/izpack/panels/ValidatePackSelections.java Sending modules/installer-support/src/java/com/izforge/izpack/panels/ValidatePackSelectionsAutomationHelper.java Sending modules/installer-support/src/java/com/izforge/izpack/panels/Validator.java Transmitting file data . Committed revision 370961. Installer - Install Derby with base J2EE Features - Key: GERONIMO-1517 URL: http://issues.apache.org/jira/browse/GERONIMO-1517 Project: Geronimo Type: Bug Components: installer Versions: 1.0.1, 1.1 Reporter: erik daughtrey Assignee: David Jencks Fix For: 1.0.1, 1.1 Attachments: installer-derby-as-j2ee-feature.patch -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Cut date for 1.1?
Dain Sundstrom wrote: I have heard from some that 1.1 will be cut next week and from others that it will be at least 4 more weeks. Can we make a decision now on what the date will be? I have a fairly big change I'd like to commit sometime next week, but if we are going to cut on Friday, I'll wait until Saturday to commit it. I normally prefer it to commit my changes at the beginning of a cycle so they have a long time to bake. -dain I am assuming you mean cut a branch for the 1.1 release. I think we need to identify what it is that is being delivered (from an end user point of view) in the 1.1 release. What is in 1.1 that is worth delivering so soon? Wouldn't it be better to wait a bit after the 1.0.1 release that has been proposed so any bugs fixed for 1.0.1 are in trunk prior to branching for 1.1? I did a quick JIRA search of all New Features, Improvments, Wishes and Tasks that are resolved and completed (I excluded bugs, as they should be merged to the 1.0 branch for the 1.0.1 release). The search only resulted in 11 JIRAs. If there is more that is going in 1.1 than JIRA is showing then could people please speak up and update their JIRA records to reflect reality. John
Was GERONIMO-1075 (Configuration classloaders should support an inverse classloading delegation model) in the 1.0 release?
http://issues.apache.org/jira/browse/GERONIMO-1075 Looking at the changes made in the JIRA it was prior to the 1.0 branch, but I'm not clear whether the there were more changes made after the 1.0 branch. Thanks, John
Re: Docco system (Confluent, MoinMoin, ...)
Hi, For now I am just lurking on the geronimo list (my primary interest is Cayenne persistence framework, which happens to be container- independent). Anyways, I am willing to volunteer to get it going at Apache, still I am not a committer on any of the projects (AFAIK this *is* a requirement). I've been running Confluence for some time for the ObjectStyle community: http://objectstyle.org/confluence/ So I have experience setting it up, configuring permissions, doing backups, etc. Good news are that (a) you can delegate user management to Jira, (b) there is almost zero day-to-day maintenance needed and (c) upgrades go smoothly (unlike Jira). As an aside, it concerns me somewhat that Apache infrastructure uses MySQL (and there are no alternatives like PostgreSQL, etc.). This may add to the maintenance burden. In any event I'll be glad to help with that, though not sure how at this point. Andrus Adamchik On Jan 20, 2006, at 5:44 PM, Rodent of Unusual Size wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Just some food for thought on the 'which docco system' discussion/vote/etc.. Whatever system gets chosen will need to be running on Apache hardware. That's not an issue for MoinMoin, since it's already there and the infra people are familiar with it. However, if Confluence is the option the project decides to adopt, more is involved than just saying so: some people from the project are going to have to join the infrastructure team and become the Confluence experts and maintainers. If Confluence is selected but no-one will step up to provide the necessary expertise and commitment to make it happen, then Geronimo won't be using Confluence. The all-volunteer infrastructure team is already overloaded; adding yet another application for it to support without adding resources to help in the supporting just isn't going to fly. So, distinct from the voting, if you'd be willing to be one of the supporters of the Confluence environment at the ASF, please speak up here. Or if you have any other comments about the Confluence/MoinMoin/whatever topic. :-) The infrastructure team may require that anyone joining to support Confluence (if it comes to that) may need to be a project committer. I'm not sure; I'm checking. But if you're not a committer [yet] but are willing to help out with Confluence, don't let that stop you from volunteering! - -- #kenP-)} Ken Coar, Sanagendamgagwedweinini http://Ken.Coar.Org/ Author, developer, opinionist http://Apache-Server.Com/ Millennium hand and shrimp! -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iQCVAwUBQ9Fn55rNPMCpn3XdAQLLrAQA0LCKsMsAMa/GQNmbH0ntpYbp2W9Wic26 4ZawAu6Z+L3reo9tNQPuhD6CG/6NOYc9prM7ybqCM9pKYPTZTEJ5oybMJnIIy7Gt 2yLVL259aRrEFPKWkwoS5MBkmxXt5LvzkPN2YnKtBdP7jDWPeonxQHzZP1EHd4RW d7JblzKcw3A= =++zP -END PGP SIGNATURE-
Re: Docco system (Confluent, MoinMoin, ...)
And a thought regarding the content transfer. This can be done semi-automatically. Using 'wget' I was able to pull the entire *raw* contents of the current geronimo Wiki on my hard drive. With a simple Perl script formatting can be converted to Confluence style (formatting styles are very close), and then manually loaded to Confluence. Should not be such a big deal. Andrus On Jan 20, 2006, at 10:49 PM, Andrus Adamchik wrote: Hi, For now I am just lurking on the geronimo list (my primary interest is Cayenne persistence framework, which happens to be container- independent). Anyways, I am willing to volunteer to get it going at Apache, still I am not a committer on any of the projects (AFAIK this *is* a requirement). I've been running Confluence for some time for the ObjectStyle community: http://objectstyle.org/confluence/ So I have experience setting it up, configuring permissions, doing backups, etc. Good news are that (a) you can delegate user management to Jira, (b) there is almost zero day-to-day maintenance needed and (c) upgrades go smoothly (unlike Jira). As an aside, it concerns me somewhat that Apache infrastructure uses MySQL (and there are no alternatives like PostgreSQL, etc.). This may add to the maintenance burden. In any event I'll be glad to help with that, though not sure how at this point. Andrus Adamchik On Jan 20, 2006, at 5:44 PM, Rodent of Unusual Size wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Just some food for thought on the 'which docco system' discussion/vote/etc.. Whatever system gets chosen will need to be running on Apache hardware. That's not an issue for MoinMoin, since it's already there and the infra people are familiar with it. However, if Confluence is the option the project decides to adopt, more is involved than just saying so: some people from the project are going to have to join the infrastructure team and become the Confluence experts and maintainers. If Confluence is selected but no-one will step up to provide the necessary expertise and commitment to make it happen, then Geronimo won't be using Confluence. The all-volunteer infrastructure team is already overloaded; adding yet another application for it to support without adding resources to help in the supporting just isn't going to fly. So, distinct from the voting, if you'd be willing to be one of the supporters of the Confluence environment at the ASF, please speak up here. Or if you have any other comments about the Confluence/MoinMoin/whatever topic. :-) The infrastructure team may require that anyone joining to support Confluence (if it comes to that) may need to be a project committer. I'm not sure; I'm checking. But if you're not a committer [yet] but are willing to help out with Confluence, don't let that stop you from volunteering! - -- #kenP-)} Ken Coar, Sanagendamgagwedweinini http://Ken.Coar.Org/ Author, developer, opinionist http://Apache-Server.Com/ Millennium hand and shrimp! -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iQCVAwUBQ9Fn55rNPMCpn3XdAQLLrAQA0LCKsMsAMa/GQNmbH0ntpYbp2W9Wic26 4ZawAu6Z+L3reo9tNQPuhD6CG/6NOYc9prM7ybqCM9pKYPTZTEJ5oybMJnIIy7Gt 2yLVL259aRrEFPKWkwoS5MBkmxXt5LvzkPN2YnKtBdP7jDWPeonxQHzZP1EHd4RW d7JblzKcw3A= =++zP -END PGP SIGNATURE-
Re: [VOTE] Documentation in Confluence, MoinMoin, or..
+1 for Confluence --jason
Re: [VOTE] Documentation in Confluence, MoinMoin, or..
I'm not sure that everyone knows about some of the nicer features of Confluence... * WYSIWYG Editor * Rich integration with JIRA (issue lists and embedded portlets) * Rich integration with Groovy/Jython/BeanShell SQL * Simple page linking... no need for *ugly* CamelCase * Integrated search that index content *and* attachments * Simple page view/edit restrictions * Integrated blog-style news pages (great for tracking milestone events) * Integrated RSS, with advanced feedbuilder.. just get the news you care about * Page export to HTML, PDF and... Word (not that I care about word... but someone does) * Archives mail... nice because that mail becomes searchable * Simple to embed Flash,MPG,etc. Flash specifically, which is a great tool for online visual demos/tutorials (very powerful) * Versioning of attachments * Labels... organize content across spaces using flexible labeling system * Rich plugin support... which is really growing * Renaming/moving pages updates references (huge plus IMO) ** Chart ** Dynamic calendars ** Dynamic TOC (must have for generated docs) ** Dynamic Excel .xls rendering (and sorting... very spiffy) ** Dynamic AJAX-based searching Um... I could go on... and on. My engineering organization has found Confluence a huge benefit for managing release notes (pulled dynamically from JIRA), tracking release history (as news items, with links to release notes). Some of the advanced macros for content formatting also make Confluence work really well as a project dashboard... with all the information you want about a projects status in one place. I believe this is an amazing tool. Blows MoinMoin out of the water from a feature, usability and administration perspective... as well as its built in ability to be configured to look (colors, layouts) anyway you want. For example, once space could look like a regular website, another could look like a user's guide and another could look like a FAQ. I guess I am going on and on now... so I will stop. Cheers, --jason
