[jira] Updated: (GERONIMO-1296) Corba spec does not define ExceptionDetailMessage
[ http://issues.apache.org/jira/browse/GERONIMO-1296?page=all ] Aaron Mulder updated GERONIMO-1296: --- Fix Version: 1.1 Version: 1.0-M5 Corba spec does not define ExceptionDetailMessage - Key: GERONIMO-1296 URL: http://issues.apache.org/jira/browse/GERONIMO-1296 Project: Geronimo Type: Sub-task Components: CORBA Versions: 1.0-M5 Reporter: Anders Hessellund Jensen Assignee: Alan Cabrera Fix For: 1.1 Attachments: ExceptionDetailMessage.patch The corba spec does not define ExceptionDetailMessage in package org.omg.IOP. This causes a build failure. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (GERONIMO-1181) Add/Edit Tomcat HTTPS Connector does not address truststore parameters
[ http://issues.apache.org/jira/browse/GERONIMO-1181?page=all ] Vamsavardhana Reddy closed GERONIMO-1181: - Add/Edit Tomcat HTTPS Connector does not address truststore parameters -- Key: GERONIMO-1181 URL: http://issues.apache.org/jira/browse/GERONIMO-1181 Project: Geronimo Type: Bug Components: console Versions: 1.0 Environment: Win XP, Sun JDK 1.4.2_08 Reporter: Vamsavardhana Reddy Assignee: Aaron Mulder Fix For: 1.0 Attachments: GERONIMO-1181-corrected.patch, GERONIMO-1181.patch Adding/Editing Tomcat HTTPS Connectors through Connector portlet does not provide fields to add/edit truststoreFileName, truststoreType and truststorePassword attributes. -- 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-1292) Connector Portlet: List connectors in Web Server management page throws exception
[ http://issues.apache.org/jira/browse/GERONIMO-1292?page=all ] Vamsavardhana Reddy closed GERONIMO-1292: - Connector Portlet: List connectors in Web Server management page throws exception - Key: GERONIMO-1292 URL: http://issues.apache.org/jira/browse/GERONIMO-1292 Project: Geronimo Type: Bug Components: console Versions: 1.0-M5 Environment: Win XP, Sun JDK 1.4.2_08 Reporter: Vamsavardhana Reddy Assignee: Aaron Mulder Priority: Minor Fix For: 1.0 Attachments: GERONIMO-1292.patch Listing the network listeners under web server management page throws the following exception. 17:02:19,037 ERROR [Servlet] Exception caught: java.lang.NullPointerException: ObjectName 'name' parameter can't be null at javax.management.ObjectName.init(ObjectName.java:74) at javax.management.ObjectName.getInstance(ObjectName.java:261) at org.apache.geronimo.console.util.KernelManagementHelper.getObject(KernelManagementHelper.java:898) at org.apache.geronimo.console.util.PortletManager.getWebContainer(PortletManager.java:258) at org.apache.geronimo.console.webmanager.ConnectorPortlet.processAction(ConnectorPortlet.java:71) ... -- 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: Disasterous problem with 2 spec jars
Sachin says that maven 2 uses the eclipse compiler rather than javac
and that judging by its behavior when looking at binary classes in
eclipse it may well be producing these bad class files. It appears
that all the methods in the implements interfaces have been added to
the class.
Presumably the solution is to build with maven 1.
If the eclipse compiler is in fact at fault, I think that this will
prevent us from using maven 2 until either a javac compiler is provided
or the eclipse compiler is fixed. If the eclipse compiler behavior is
actually according to the jdk spec we may have a different issue.
thanks
david jencks
On Dec 13, 2005, at 1:11 AM, David Jencks wrote:
Something is dreadfully wrong with two of the spec jars build by maven
2.
The javamail BodyPart class source looks like this:
package javax.mail;
/**
* @version $Rev: 54266 $ $Date: 2004-10-10 14:02:50 -0700 (Sun, 10
Oct 2004) $
*/
public abstract class BodyPart implements Part {
protected Multipart parent;
public Multipart getParent() {
return parent;
}
}
Decompiling the class (1951 bytes) from the maven 2 build gives this:
David-Jencks-Computer:~/geronimo/geronimo/svn/geronimo/branches/1.0
david$ javap -classpath
~/downloads/geronimo-javamail_1.3.1_spec-1.0.jar javax.mail.BodyPart
Compiled from BodyPart.java
public abstract class javax.mail.BodyPart extends java.lang.Object
implements javax.mail.Part{
protected javax.mail.Multipart parent;
public javax.mail.BodyPart();
public javax.mail.Multipart getParent();
public abstract void writeTo(java.io.OutputStream);
throws java/io/IOException, javax/mail/MessagingException
public abstract void setText(java.lang.String);
throws javax/mail/MessagingException
public abstract void setHeader(java.lang.String,java.lang.String);
throws javax/mail/MessagingException
public abstract void setFileName(java.lang.String);
throws javax/mail/MessagingException
public abstract void setDisposition(java.lang.String);
throws javax/mail/MessagingException
public abstract void setDescription(java.lang.String);
throws javax/mail/MessagingException
public abstract void setDataHandler(javax.activation.DataHandler);
throws javax/mail/MessagingException
public abstract void setContent(java.lang.Object,java.lang.String);
throws javax/mail/MessagingException
public abstract void setContent(javax.mail.Multipart);
throws javax/mail/MessagingException
public abstract void removeHeader(java.lang.String);
throws javax/mail/MessagingException
public abstract boolean isMimeType(java.lang.String);
throws javax/mail/MessagingException
public abstract int getSize();
throws javax/mail/MessagingException
public abstract java.util.Enumeration
getNonMatchingHeaders(java.lang.String[]);
throws javax/mail/MessagingException
public abstract java.util.Enumeration
getMatchingHeaders(java.lang.String[]);
throws javax/mail/MessagingException
public abstract int getLineCount();
throws javax/mail/MessagingException
public abstract java.io.InputStream getInputStream();
throws java/io/IOException, javax/mail/MessagingException
public abstract java.lang.String[] getHeader(java.lang.String);
throws javax/mail/MessagingException
public abstract java.lang.String getFileName();
throws javax/mail/MessagingException
public abstract java.lang.String getDisposition();
throws javax/mail/MessagingException
public abstract java.lang.String getDescription();
throws javax/mail/MessagingException
public abstract javax.activation.DataHandler getDataHandler();
throws javax/mail/MessagingException
public abstract java.lang.String getContentType();
throws javax/mail/MessagingException
public abstract java.lang.Object getContent();
throws java/io/IOException, javax/mail/MessagingException
public abstract java.util.Enumeration getAllHeaders();
throws javax/mail/MessagingException
public abstract void addHeader(java.lang.String,java.lang.String);
throws javax/mail/MessagingException
}
Decompiling the class from our own maven 1 build gives:
David-Jencks-Computer:~/geronimo/geronimo/svn/geronimo/branches/1.0
david$ javap -classpath
~/.maven/repository/geronimo-spec/jars/geronimo-spec-javamail-1.3.1-
rc6.jar javax.mail.BodyPart
Compiled from BodyPart.java
public abstract class javax.mail.BodyPart extends java.lang.Object
implements javax.mail.Part{
protected javax.mail.Multipart parent;
public javax.mail.BodyPart();
public javax.mail.Multipart getParent();
}
There appears to be a similar problem with the saaj SOAPPart class.
What should we do? Use the maven 1 built jars?
thanks
david jencks
[jira] Commented: (GERONIMO-1333) [Daytrader] ejb module should not depend on wsappclient module
[ http://issues.apache.org/jira/browse/GERONIMO-1333?page=comments#action_12360289 ] Vincent Massol commented on GERONIMO-1333: -- I've done some more analysis. The problem comes from TradeWebSoapProxy.java in the ejb module which uses TradeWSServices.java located in the wsapplicent module... Several things that do not seem right: * The ejb module should be dedicated to ejbs. If not then it's not correctly named. Maybe a functional name like business would be better? * Currently the ejb module containers the direct code (JDBC/JMS) which has nothing to do with ejbs. It could stay if the module was renamed to something like business. * The TradeWSServices.java class should be moved to the business module to remove the dependency on wsapplicent * The ejb module should be producing 2 jars: an EJB jar and an EJB-Client jar Thanks [Daytrader] ejb module should not depend on wsappclient module -- Key: GERONIMO-1333 URL: http://issues.apache.org/jira/browse/GERONIMO-1333 Project: Geronimo Type: Improvement Components: sample apps Versions: 1.0-M5 Reporter: Vincent Massol Assignee: Matt Hogstrom Fix For: 1.1 There is dependency on the wsappclient jar in the ejb module. That doesn't look right. Does it mean the wsappclient should be split into 2 modules? I haven't investigated more but it smells like a circular depdency somewhere. -- 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: Disasterous problem with 2 spec jars
I just took a look at the Sun version of the BodyPart class, and it is
similarly truncated (although it supports a setParent() method in
addition to getParent()). It appears that the eclipse compiler is
adding this incorrectly. It makes sense that it shouldn't, since the
BodyPart class is abstract. It NEEDS to leave all of the unimplemented
methods unimplemented to ensure that subclasses complete the concrete
class contract.
Rick
David Jencks wrote:
Sachin says that maven 2 uses the eclipse compiler rather than javac
and that judging by its behavior when looking at binary classes in
eclipse it may well be producing these bad class files. It appears
that all the methods in the implements interfaces have been added
to the class.
Presumably the solution is to build with maven 1.
If the eclipse compiler is in fact at fault, I think that this will
prevent us from using maven 2 until either a javac compiler is
provided or the eclipse compiler is fixed. If the eclipse compiler
behavior is actually according to the jdk spec we may have a
different issue.
thanks
david jencks
On Dec 13, 2005, at 1:11 AM, David Jencks wrote:
Something is dreadfully wrong with two of the spec jars build by
maven 2.
The javamail BodyPart class source looks like this:
package javax.mail;
/**
* @version $Rev: 54266 $ $Date: 2004-10-10 14:02:50 -0700 (Sun, 10
Oct 2004) $
*/
public abstract class BodyPart implements Part {
protected Multipart parent;
public Multipart getParent() {
return parent;
}
}
Decompiling the class (1951 bytes) from the maven 2 build gives this:
David-Jencks-Computer:~/geronimo/geronimo/svn/geronimo/branches/1.0
david$ javap -classpath
~/downloads/geronimo-javamail_1.3.1_spec-1.0.jar javax.mail.BodyPart
Compiled from BodyPart.java
public abstract class javax.mail.BodyPart extends java.lang.Object
implements javax.mail.Part{
protected javax.mail.Multipart parent;
public javax.mail.BodyPart();
public javax.mail.Multipart getParent();
public abstract void writeTo(java.io.OutputStream);
throws java/io/IOException, javax/mail/MessagingException
public abstract void setText(java.lang.String);
throws javax/mail/MessagingException
public abstract void setHeader(java.lang.String,java.lang.String);
throws javax/mail/MessagingException
public abstract void setFileName(java.lang.String);
throws javax/mail/MessagingException
public abstract void setDisposition(java.lang.String);
throws javax/mail/MessagingException
public abstract void setDescription(java.lang.String);
throws javax/mail/MessagingException
public abstract void setDataHandler(javax.activation.DataHandler);
throws javax/mail/MessagingException
public abstract void setContent(java.lang.Object,java.lang.String);
throws javax/mail/MessagingException
public abstract void setContent(javax.mail.Multipart);
throws javax/mail/MessagingException
public abstract void removeHeader(java.lang.String);
throws javax/mail/MessagingException
public abstract boolean isMimeType(java.lang.String);
throws javax/mail/MessagingException
public abstract int getSize();
throws javax/mail/MessagingException
public abstract java.util.Enumeration
getNonMatchingHeaders(java.lang.String[]);
throws javax/mail/MessagingException
public abstract java.util.Enumeration
getMatchingHeaders(java.lang.String[]);
throws javax/mail/MessagingException
public abstract int getLineCount();
throws javax/mail/MessagingException
public abstract java.io.InputStream getInputStream();
throws java/io/IOException, javax/mail/MessagingException
public abstract java.lang.String[] getHeader(java.lang.String);
throws javax/mail/MessagingException
public abstract java.lang.String getFileName();
throws javax/mail/MessagingException
public abstract java.lang.String getDisposition();
throws javax/mail/MessagingException
public abstract java.lang.String getDescription();
throws javax/mail/MessagingException
public abstract javax.activation.DataHandler getDataHandler();
throws javax/mail/MessagingException
public abstract java.lang.String getContentType();
throws javax/mail/MessagingException
public abstract java.lang.Object getContent();
throws java/io/IOException, javax/mail/MessagingException
public abstract java.util.Enumeration getAllHeaders();
throws javax/mail/MessagingException
public abstract void addHeader(java.lang.String,java.lang.String);
throws javax/mail/MessagingException
}
Decompiling the class from our own maven 1 build gives:
David-Jencks-Computer:~/geronimo/geronimo/svn/geronimo/branches/1.0
david$ javap -classpath
~/.maven/repository/geronimo-spec/jars/geronimo-spec-javamail-1.3.1-
rc6.jar javax.mail.BodyPart
Compiled from
Re: Fwd: OpenEJB Question
Hi Manu, Thanks for your debugging! This was a bug in IdentityDefinerBuilder, which was wrongly trying to identify a compound PK based on the number of primary key fields. This is now fixed. I will create a JIRA to track this issue tomorrow as it seems that JIRA is down tonight. Thanks, Gianny Manu George wrote: Hi Gianny, I have done all that you mentioned. I am still getting the error.I have replicated the issue in a simple EJB,the example CMP in Ed Roman's book Mastering EJB. I am attaching the stack trace and the plans below 17:02:05,211 WARN [SystemExceptionInterceptor] Product snip While i was debugging I saw a method public IdentityTransform getPrimaryKeyTransform(Entity entity) in the class IdentityDefinerBuilder. Here based on size of pkFields the SimplePKTransform or CompoundPKTransform class is selected. In the case of a custom class with 1 field also the SimplePKTransform is selected. Is this how it should behave? Could you give a general idea of how the primary key values are taken from the Custom classes in OpenEJB? Thanks Manu
Re: [jira] Updated: (GERONIMO-1130) Implement WebServer Manager (statistics gathering/reporting) management interface
Aaron, I understand your reluctance at this late date. I was actually hoping to get this implemented last week ... but it's pretty late now and probably not worth the risk. It still bothers me that when running under tomcat the web server stats portlet gives the impression that it supports the statistics but in fact does nothing. Would it be helpful if I provided a quick patch to present a message indicating that the stats are not supported or do you want to leave well enough alone for 1.0? Joe Aaron Mulder (JIRA) wrote: [ http://issues.apache.org/jira/browse/GERONIMO-1130?page=all ] Aaron Mulder updated GERONIMO-1130: --- Fix Version: 1.1 (was: 1.x) I'm sorry to say, I don't feel real good about applying this at this point since we're geared up for the next round of TCK testing tonight and this patch covers a fair bit of stuff outside the portal. If the testing doesn't go well and we have more fixes tomorrow, I'll put it in tomorrow. Otherwise, it'll be early 1.1. Implement WebServer Manager (statistics gathering/reporting) management interface - Key: GERONIMO-1130 URL: http://issues.apache.org/jira/browse/GERONIMO-1130 Project: Geronimo Type: New Feature Components: management, console Versions: 1.0-M5 Environment: all Reporter: Joe Bohn Assignee: Joe Bohn Fix For: 1.1 Attachments: StatsJetty5.1.5.patch, StatsJetty5.1.7rc05.patch, StatsJettyG1.0.patch Jetty has a statistics gathering and reporting capability that is support in the console via the Web Server Manager portlet. We should provide similar monitoring capabilities for tomcat. However, the Jetty implementation is tightly bound to Jetty. We need a more generic interface build upon the principles of JSR77 to address statistical information for the web server (both jetty and tomcat). -- Joe Bohn [EMAIL PROTECTED] He is no fool who gives what he cannot keep, to gain what he cannot lose. -- Jim Elliot
Re: Fwd: OpenEJB Question
Hi Gianny Great to know its fixed. Will try it out after building geronimo from source. Thanks ManuOn 12/13/05, Gianny Damour [EMAIL PROTECTED] wrote: Hi Manu,Thanks for your debugging! This was a bug in IdentityDefinerBuilder,which was wrongly trying to identify a compound PK based on the numberof primary key fields.This is now fixed.I will create a JIRA to track this issue tomorrow as it seems that JIRA is down tonight.Thanks,GiannyManu George wrote: Hi Gianny, I have done all that you mentioned. I am still getting the error.I have replicated the issue in a simple EJB,the example CMP in Ed Roman's book Mastering EJB. I am attaching the stack trace and the plans below 17:02:05,211 WARN[SystemExceptionInterceptor] Product snip While i was debugging I saw a method public IdentityTransform getPrimaryKeyTransform(Entity entity) in the class IdentityDefinerBuilder. Here based on size of pkFields the SimplePKTransform or CompoundPKTransform class is selected. In the case of a custom class with 1 field also the SimplePKTransform is selected. Is this how it should behave? Could you give a general idea of how the primary key values are taken from the Custom classes in OpenEJB? Thanks Manu
Re: [jira] Updated: (GERONIMO-1130) Implement WebServer Manager (statistics gathering/reporting) management interface
A Tomcat patch might be good so long as it only affects the console (e.g. not modules/tomcat). Aaron On 12/13/05, Joe Bohn [EMAIL PROTECTED] wrote: Aaron, I understand your reluctance at this late date. I was actually hoping to get this implemented last week ... but it's pretty late now and probably not worth the risk. It still bothers me that when running under tomcat the web server stats portlet gives the impression that it supports the statistics but in fact does nothing. Would it be helpful if I provided a quick patch to present a message indicating that the stats are not supported or do you want to leave well enough alone for 1.0? Joe Aaron Mulder (JIRA) wrote: [ http://issues.apache.org/jira/browse/GERONIMO-1130?page=all ] Aaron Mulder updated GERONIMO-1130: --- Fix Version: 1.1 (was: 1.x) I'm sorry to say, I don't feel real good about applying this at this point since we're geared up for the next round of TCK testing tonight and this patch covers a fair bit of stuff outside the portal. If the testing doesn't go well and we have more fixes tomorrow, I'll put it in tomorrow. Otherwise, it'll be early 1.1. Implement WebServer Manager (statistics gathering/reporting) management interface - Key: GERONIMO-1130 URL: http://issues.apache.org/jira/browse/GERONIMO-1130 Project: Geronimo Type: New Feature Components: management, console Versions: 1.0-M5 Environment: all Reporter: Joe Bohn Assignee: Joe Bohn Fix For: 1.1 Attachments: StatsJetty5.1.5.patch, StatsJetty5.1.7rc05.patch, StatsJettyG1.0.patch Jetty has a statistics gathering and reporting capability that is support in the console via the Web Server Manager portlet. We should provide similar monitoring capabilities for tomcat. However, the Jetty implementation is tightly bound to Jetty. We need a more generic interface build upon the principles of JSR77 to address statistical information for the web server (both jetty and tomcat). -- Joe Bohn [EMAIL PROTECTED] He is no fool who gives what he cannot keep, to gain what he cannot lose. -- Jim Elliot
Re: Fwd: OpenEJB Question
Gianny, Did the fix go into TranQL? Geronimo 1.0 is not using a TranQL snapshot right now, so someone would need to cut a new TranQL release for us to get the fix into Geronimo 1.0. Thanks, Aaron On 12/13/05, Gianny Damour [EMAIL PROTECTED] wrote: Hi Manu, Thanks for your debugging! This was a bug in IdentityDefinerBuilder, which was wrongly trying to identify a compound PK based on the number of primary key fields. This is now fixed. I will create a JIRA to track this issue tomorrow as it seems that JIRA is down tonight. Thanks, Gianny Manu George wrote: Hi Gianny, I have done all that you mentioned. I am still getting the error.I have replicated the issue in a simple EJB,the example CMP in Ed Roman's book Mastering EJB. I am attaching the stack trace and the plans below 17:02:05,211 WARN [SystemExceptionInterceptor] Product snip While i was debugging I saw a method public IdentityTransform getPrimaryKeyTransform(Entity entity) in the class IdentityDefinerBuilder. Here based on size of pkFields the SimplePKTransform or CompoundPKTransform class is selected. In the case of a custom class with 1 field also the SimplePKTransform is selected. Is this how it should behave? Could you give a general idea of how the primary key values are taken from the Custom classes in OpenEJB? Thanks Manu
Re: Disasterous problem with 2 spec jars
I don't fully understand the issue, but Eclipse may not be doing the
wrong thing... Sun JDK 1.5 will, in fact, behave in the same manner (I
haven't tested to see how 1.5 will compile the same class).
Just to be clear, the near-term options seem to be:
1) switch spec build to maven 1
2) configure maven 2 to use javac from Sun 1.4 (there are references to setting a compilerId in the maven-compiler-plug
3) challenge the test results
We should be able to easily determine if 2 will work... If not, then get started on 1...
--kevan
On 12/13/05, Rick McGuire [EMAIL PROTECTED] wrote:
I just took a look at the Sun version of the BodyPart class, and it issimilarly truncated (although it supports a setParent() method inaddition to getParent()).It appears that the eclipse compiler isadding this incorrectly.It makes sense that it shouldn't, since the
BodyPart class is abstract.It NEEDS to leave all of the unimplementedmethods unimplemented to ensure that subclasses complete the concreteclass contract.RickDavid Jencks wrote: Sachin says that maven 2 uses the eclipse compiler rather than javac
and that judging by its behavior when looking at binary classes in eclipse it may well be producing these bad class files.It appears that all the methods in the implements interfaces have been added
tothe class. Presumably the solution is to build with maven 1. If the eclipse compiler is in fact at fault, I think that this will prevent us from using maven 2 until either a javac compiler is
providedor the eclipse compiler is fixed.If the eclipse compiler behavior isactually according to the jdk spec we may have a different issue. thanks david jencks
On Dec 13, 2005, at 1:11 AM, David Jencks wrote: Something is dreadfully wrong with two of the spec jars build by maven2. The javamail BodyPart classsource looks like this:
package javax.mail; /*** @version $Rev: 54266 $ $Date: 2004-10-10 14:02:50 -0700 (Sun, 10 Oct 2004) $*/ public abstract class BodyPart implements Part {
protected Multipart parent; public Multipart getParent() { return parent; } } Decompiling the class (1951 bytes) from the maven 2 build gives this:
David-Jencks-Computer:~/geronimo/geronimo/svn/geronimo/branches/1.0 david$ javap -classpath ~/downloads/geronimo-javamail_1.3.1_spec-1.0.jar javax.mail.BodyPart Compiled from
BodyPart.java public abstract class javax.mail.BodyPart extends java.lang.Object implements javax.mail.Part{ protected javax.mail.Multipart parent; public javax.mail.BodyPart
(); public javax.mail.Multipart getParent(); public abstract void writeTo(java.io.OutputStream);throws java/io/IOException, javax/mail/MessagingException public abstract void setText(
java.lang.String);throws javax/mail/MessagingException public abstract void setHeader(java.lang.String,java.lang.String);throws javax/mail/MessagingException public abstract void setFileName(
java.lang.String);throws javax/mail/MessagingException public abstract void setDisposition(java.lang.String);throws javax/mail/MessagingException public abstract void setDescription(
java.lang.String);throws javax/mail/MessagingException public abstract void setDataHandler(javax.activation.DataHandler);throws javax/mail/MessagingException public abstract void setContent(
java.lang.Object,java.lang.String);throws javax/mail/MessagingException public abstract void setContent(javax.mail.Multipart);throws javax/mail/MessagingException
public abstract void removeHeader(java.lang.String);throws javax/mail/MessagingException public abstract boolean isMimeType(java.lang.String);throws javax/mail/MessagingException
public abstract int getSize();throws javax/mail/MessagingException public abstract java.util.Enumeration getNonMatchingHeaders(java.lang.String[]);throws javax/mail/MessagingException
public abstract java.util.Enumeration getMatchingHeaders(java.lang.String[]);throws javax/mail/MessagingException public abstract int getLineCount();throws javax/mail/MessagingException
public abstract java.io.InputStream getInputStream();throws java/io/IOException, javax/mail/MessagingException public abstract java.lang.String[] getHeader(java.lang.String
);throws javax/mail/MessagingException public abstract java.lang.String getFileName();throws javax/mail/MessagingException public abstract java.lang.String
getDisposition();throws javax/mail/MessagingException public abstract java.lang.String getDescription();throws javax/mail/MessagingException public abstract
javax.activation.DataHandler getDataHandler();throws javax/mail/MessagingException public abstract java.lang.String getContentType();throws javax/mail/MessagingException
public abstract java.lang.Object getContent();throws java/io/IOException, javax/mail/MessagingException public abstract java.util.Enumeration getAllHeaders();throws javax/mail/MessagingException
public abstract void addHeader(java.lang.String,java.lang.String);throws javax/mail/MessagingException } Decompiling the class from our own maven 1 build gives:
[jira] Created: (GERONIMO-1349) Missing Ports in Startup Port List
Missing Ports in Startup Port List -- Key: GERONIMO-1349 URL: http://issues.apache.org/jira/browse/GERONIMO-1349 Project: Geronimo Type: Bug Components: startup/shutdown Versions: 1.0-M5 Reporter: Aaron Mulder Assigned to: Aaron Mulder Priority: Blocker Fix For: 1.0 The port list for Geronimo is: Listening on Ports: 1099 0.0.0.0 RMI Naming 1527 0.0.0.0 Derby Connector 4201 0.0.0.0 ActiveIO Connector EJB 4242 0.0.0.0 Remote Login Listener 8019 127.0.0.1 Jetty Connector AJP13 8080 0.0.0.0 Jetty Connector HTTP 8443 0.0.0.0 Jetty Connector HTTPS 61616 0.0.0.0 ActiveMQ Message Broker Connector The port list from netstat is: tcp0 0 :::1099 :::*LISTEN 8447/java tcp0 0 :::1389 :::*LISTEN 8447/java tcp0 0 :::1527 :::*LISTEN 8447/java tcp0 0 :::4201 :::*LISTEN 8447/java tcp0 0 :::4242 :::*LISTEN 8447/java tcp0 0 127.0.0.1:8019 :::*LISTEN 8447/java tcp0 0 :::8080 :::*LISTEN 8447/java tcp0 0 :::8443 :::*LISTEN 8447/java tcp0 0 :::16321:::*LISTEN 8447/java tcp0 0 :::61616:::*LISTEN 8447/java The differences are: 1389 -- Directory variable -- 16321 (16333 on next run) -- what is this?? -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (GERONIMO-1216) ORB string - object conversion
[ http://issues.apache.org/jira/browse/GERONIMO-1216?page=comments#action_12360333 ] Lars Kühne commented on GERONIMO-1216: -- That may very well be the case. You applied the GERONIMO-1242 patch first, that might have changed the ORB class so much that this patch cannot be applied. Should I create a new patch or will you figure things out yourself? ORB string - object conversion Key: GERONIMO-1216 URL: http://issues.apache.org/jira/browse/GERONIMO-1216 Project: Geronimo Type: Sub-task Components: CORBA Versions: 1.0-M5 Reporter: Lars Kühne Assignee: Alan Cabrera Fix For: 1.x Attachments: issue1216.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
log properties in var/log directory
Hi All, I am playing around with the new builds. For documentation and testing purposes I normally clean the *logs* by just wiping out the content of the /log directory. I found out (the hard way) there were some properties files there that I deleted too. Since this easy way to clean the logs is not that unusual in the field I would like to propose (for future improvement) moving the */logs* directory with just the logs to the root of that assembly (either j2ee-jetty-server or j2ee-tomcat-server) and leave the property files in the var/log directory. Cheers! Hernan
[jira] Created: (GERONIMO-1350) Web Console indicates that web server stats are available for Tomcat when they really are not
Web Console indicates that web server stats are available for Tomcat when they really are not - Key: GERONIMO-1350 URL: http://issues.apache.org/jira/browse/GERONIMO-1350 Project: Geronimo Type: Bug Components: console Versions: 1.0 Environment: Win XP Reporter: Joe Bohn Assigned to: Joe Bohn Priority: Minor Fix For: 1.0 The Web Server view in the Web Console includes a portlet to display web server statistics. This functinoality is implemented for Jetty but is not currently implemented for Tomcat. However, the console indicates that statistics collection can be enabled without regard for the hosting web conainer. In the case of Tomcat that means that the user can select the enable statistics collection but the action will have no effect and statistics will never be enabled.. -- 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-1349) Missing Ports in Startup Port List
[ http://issues.apache.org/jira/browse/GERONIMO-1349?page=all ] Aaron Mulder updated GERONIMO-1349: --- Fix Version: 1.1 (was: 1.0) Priority: Major (was: Blocker) Fixed the directory port. Not sure where the other random port is coming from, but it's probably less critical. Missing Ports in Startup Port List -- Key: GERONIMO-1349 URL: http://issues.apache.org/jira/browse/GERONIMO-1349 Project: Geronimo Type: Bug Components: startup/shutdown Versions: 1.0-M5 Reporter: Aaron Mulder Assignee: Aaron Mulder Fix For: 1.1 The port list for Geronimo is: Listening on Ports: 1099 0.0.0.0 RMI Naming 1527 0.0.0.0 Derby Connector 4201 0.0.0.0 ActiveIO Connector EJB 4242 0.0.0.0 Remote Login Listener 8019 127.0.0.1 Jetty Connector AJP13 8080 0.0.0.0 Jetty Connector HTTP 8443 0.0.0.0 Jetty Connector HTTPS 61616 0.0.0.0 ActiveMQ Message Broker Connector The port list from netstat is: tcp0 0 :::1099 :::*LISTEN 8447/java tcp0 0 :::1389 :::*LISTEN 8447/java tcp0 0 :::1527 :::*LISTEN 8447/java tcp0 0 :::4201 :::*LISTEN 8447/java tcp0 0 :::4242 :::*LISTEN 8447/java tcp0 0 127.0.0.1:8019 :::*LISTEN 8447/java tcp0 0 :::8080 :::*LISTEN 8447/java tcp0 0 :::8443 :::*LISTEN 8447/java tcp0 0 :::16321:::*LISTEN 8447/java tcp0 0 :::61616:::*LISTEN 8447/java The differences are: 1389 -- Directory variable -- 16321 (16333 on next run) -- what is this?? -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [VOTE] David Blevins as Axis committer (Re: Axis 1.4 Final Branch)
On Mon, 2005-12-12 at 03:41 -0500, Davanum Srinivas wrote: Folks, Can we please vote David as committer to take care of Axis 1.x. Here's my +1 +1 .. welcome aboard David. Sanjiva.
Re: log properties in var/log directory
It's not a bad idea to support rm -rf log/* but I don't think moving stuff out of /var is the right answer. I'd rather think of a better place under /var to store the log config files. Aaron On 12/13/05, Hernan Cunico [EMAIL PROTECTED] wrote: Hi All, I am playing around with the new builds. For documentation and testing purposes I normally clean the *logs* by just wiping out the content of the /log directory. I found out (the hard way) there were some properties files there that I deleted too. Since this easy way to clean the logs is not that unusual in the field I would like to propose (for future improvement) moving the */logs* directory with just the logs to the root of that assembly (either j2ee-jetty-server or j2ee-tomcat-server) and leave the property files in the var/log directory. Cheers! Hernan
Re: log properties in var/log directory
I had the same problem awhile back.. I agree the log properties files shoule be kept in a different spot than the logs.. -Dave- Hernan Cunico wrote: Hi All, I am playing around with the new builds. For documentation and testing purposes I normally clean the *logs* by just wiping out the content of the /log directory. I found out (the hard way) there were some properties files there that I deleted too. Since this easy way to clean the logs is not that unusual in the field I would like to propose (for future improvement) moving the */logs* directory with just the logs to the root of that assembly (either j2ee-jetty-server or j2ee-tomcat-server) and leave the property files in the var/log directory. Cheers! Hernan
RE: [Geronimo] Clustering
Jules, Sorry for the late reply and thanks for all the info!!! It's awesome. I have more questions if you don't mind. Not very organized so bear with me :( Answers are greatly appreciated. JNDI implementation I guess what you are talking about is our own version of (at the least)JNDI Context implementation that is cluster aware and the lookup is based on the various strategies outlined in your email. (This is where I guess Apache directory can be leveraged to build our impl on top) Plus you are taked about passing in membership information to the client via a proprietary protocol or the client taking on itself to obtain membership info via configuration or an auto discovery handle. Instead can we have a proxy (which sits between the stub and skeleton) which will sit on our JNDI server and handle any membership issues. Sort of a proxy to a proxy :) Client -- stub -- proxy (which handles membership issues) -- skeleton -- EJB This will shield the client from having to have any knowledge whatsoever about the cluster membership. Assumptions - So the basic assumption is that it's a homogenous cluster. Does it mean that only the EJB's are present in every cluster or is it EJB's plus + other resources are available??? Does it mean that they all have access to the same data?? Like they could be pointing to the same database or a cluster of databases. SLSB I agree that in general we have a use case for non-sticky clustering. Again as you pointed out the SLSB is usually a façade for other more complex operations that may use system resources heavily. So in such a case are we going to collocate the resources and use a per-Bean or per-User (or per-Server?) sticky behavior here? If so that means we have to make sure that particular SLSB is sticky in terms of clustering. So it boils down to the fact that we are going to define a clustering strategy per bean (not bean type for ex SLSB or SFSB). Is this correct??? SFSB - As u mentioned most SFSB are going to be sticky, but if we do cluster the data associated with the session then we can use a non sticky algo. But u mentioned this is sub optimal? So is this really expensive?? Is it really worth looking at this option? Again I guess it depends on the amount of information that should be replicated which bring us back to the strategy of choosing a clustering type per Bean not by bean type. Entity I guess if the underlying data sources are clustered then we can use a non-sticky algo if not we have to use sticky. Is that correct for all scenarios?? More Questions/Answers and discussions will help us to flesh this out more. Regards, Rajith Attapattu. -Original Message- From: Jules Gosnell [mailto:[EMAIL PROTECTED] Sent: Tuesday, December 06, 2005 1:51 PM To: dev@geronimo.apache.org Cc: [EMAIL PROTECTED] Subject: Re: [Geronimo] Clustering Rajith, I'll have a crack at these and then if Jeff wants to add anything I'm sure he will :-) please see inline... Rajith Attapattu wrote: Jeff, I am currently involved with JavaMail implementations so haven't had much time to look at the clustering side. Will do soon after the mail thingy is done. However can please comment on the points stated below so when you are done with the 1.0 release and me with the JavaMail thing, we can continue with the clustering conversation. Thanks, Rajith -Original Message- From: Rajith Attapattu [mailto:[EMAIL PROTECTED] Sent: Wednesday, November 30, 2005 7:29 PM To: dev@geronimo.apache.org; [EMAIL PROTECTED] Subject: RE: [Geronimo] Clustering Jeff, We maybe able to leverage the Apache Directory for the underlying JNDI aspect of it (I will look in to this, but might need help) How about the policy management portion of clustering service?? For ex Clustering strategy == Whether to use Sticky vs Random vs other load balancing mechanisms or are we allowing the user to choose a strategy from above. OK - lets get down to brass tacks. Ultimately we will need a number of different policies including those that you have outlined above. Different policies will suit different types of bean and different use cases and it would be good to put together some sort of list of common combinations. Here is a start... This is all straight off the top of my head - so be gentle :-) I think we probably can assume homogeneous JNDI population - i.e. all JNDI services carry exactly the same information - otherwise a client would have to visit all of them to be sure that a service it required did not exist. This means that deploying a new JNDI entry is expensive (since it has to update all JNDI service replicas), but the deployment of new entries is an exceptional event, whereas client lookup is a common event - so we keep the common event cheap and the exceptional one pays the price. So, somehow (probably initially via some sort of autodiscovery mechanism) the
[jira] Updated: (GERONIMO-777) Deployment files not removed on Windows
[ http://issues.apache.org/jira/browse/GERONIMO-777?page=all ] Kevan Miller updated GERONIMO-777: -- Fix Version: 1.1 (was: 1.0) Version: 1.0 (was: 1.0-M3) (was: 1.0-M4) (was: 1.0-M5) Most temporary/config-store files are now cleaned up on Windows, but not all... We can do better, but I don't want to touch it right now. I'll fix the remaining issues on HEAD. FYI, thanks to John Sisson, if you use geronimo.sh or .bat, by default, temp files will be stored in $GERONIMO_BASE/var/temp Here's info on the current status... config-store: On unix, config-store directories will always be deleted on undeploy. On windows, config-store directories will sometimes be deleted on undeploy. jsp/servlets config-store directories are often deleted immediately. ejb's are almost always locked by the ClassLoader and not deleted immediately. Until the ClassLoader has been GC'ed, we won't be able to delete the directory. A ThreadLocal reference is keeping the ClassLoader's alive. Until the thread is used (and the threadlocal reference is overwritten, the ClassLoader won't be GC'ed)delet. So, it may be a very long time before the ClassLoader is GC'ed. If we're unable to delete the directory during undeploy processing, the directory is queued for deletion. A config-store reaper will attempt to delete the directory once a minute. The pending deletion queue is also persisted to disk. So, on a restart, we'll be able to delete the directories. temp files: During deploy, temporary files are created by Deployer and DeploymentUtil. Deployer files are deleted after use. On windoze, we're not always able to delete these files. If we're unable to delete, the files/directories are placed on a pending deletion queue. This queue is not persisted. If the server is stopped, the files will never be deleted. This needs to be improved, but I don't want to introduce this late in the game. DeploymentUtil temporary files are not explicitly deleted. Instead, deleteOnExit() is used to mark the files for deletion on process exit. As far as I can tell, this works on unix systems, but not on Windows. Also, this means that the files will exist for at the life of the server process (at a minimum). I haven't made any changes to this. I think we should be more proactive cleaning up this files, but again have not yet fixed. Deployment files not removed on Windows --- Key: GERONIMO-777 URL: http://issues.apache.org/jira/browse/GERONIMO-777 Project: Geronimo Type: Bug Versions: 1.0 Environment: Windows Reporter: Jeremy Boynes Assignee: Kevan Miller Fix For: 1.1 When running on Windows, deployment leaves behind files and directories in the user's temp directory. Due to the way temp file names are allocated, this can result in deployment failures with an unintuitive AccessDenied IOException. These files cannot be removed without shutting down the server. -- 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: log properties in var/log directory
./var/log ./var/properties On 12/13/05 11:19 AM, Dave Colasurdo [EMAIL PROTECTED] wrote: I had the same problem awhile back.. I agree the log properties files shoule be kept in a different spot than the logs.. -Dave- Hernan Cunico wrote: Hi All, I am playing around with the new builds. For documentation and testing purposes I normally clean the *logs* by just wiping out the content of the /log directory. I found out (the hard way) there were some properties files there that I deleted too. Since this easy way to clean the logs is not that unusual in the field I would like to propose (for future improvement) moving the */logs* directory with just the logs to the root of that assembly (either j2ee-jetty-server or j2ee-tomcat-server) and leave the property files in the var/log directory. Cheers! Hernan
[jira] Created: (GERONIMO-1351) Separate Derby network listener from system-databsae ocnfiguration
Separate Derby network listener from system-databsae ocnfiguration -- Key: GERONIMO-1351 URL: http://issues.apache.org/jira/browse/GERONIMO-1351 Project: Geronimo Type: Bug Components: databases, security Versions: 1.0-M5 Reporter: Aaron Mulder Fix For: 1.1 Currently the system-database configuraiton is required (for EJB timer, JMS, etc.). The configuration starts a Derby network listener. There's no need for a network listener to support these core features. It seems like it would be nice to separate the network listener so it could be disabled independently without crippling the server, and only enabled when remote access to the embedded database was desirable. -- 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-1351) Separate Derby network listener from system-databsae configuration
[ http://issues.apache.org/jira/browse/GERONIMO-1351?page=all ] Aaron Mulder updated GERONIMO-1351: --- Component: security Summary: Separate Derby network listener from system-databsae configuration (was: Separate Derby network listener from system-databsae ocnfiguration) Separate Derby network listener from system-databsae configuration -- Key: GERONIMO-1351 URL: http://issues.apache.org/jira/browse/GERONIMO-1351 Project: Geronimo Type: Bug Components: databases, security Versions: 1.0-M5 Reporter: Aaron Mulder Fix For: 1.1 Currently the system-database configuraiton is required (for EJB timer, JMS, etc.). The configuration starts a Derby network listener. There's no need for a network listener to support these core features. It seems like it would be nice to separate the network listener so it could be disabled independently without crippling the server, and only enabled when remote access to the embedded database was desirable. -- 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-1350) Web Console indicates that web server stats are available for Tomcat when they really are not
[ http://issues.apache.org/jira/browse/GERONIMO-1350?page=all ] Joe Bohn updated GERONIMO-1350: --- Attachment: NoTomcatStats.patch This patch includes changes to just the console itself to provide an appropriate message for tomcat indicating that statistics are not yet supported for the web container. Web Console indicates that web server stats are available for Tomcat when they really are not - Key: GERONIMO-1350 URL: http://issues.apache.org/jira/browse/GERONIMO-1350 Project: Geronimo Type: Bug Components: console Versions: 1.0 Environment: Win XP Reporter: Joe Bohn Assignee: Joe Bohn Priority: Minor Fix For: 1.0 Attachments: NoTomcatStats.patch The Web Server view in the Web Console includes a portlet to display web server statistics. This functinoality is implemented for Jetty but is not currently implemented for Tomcat. However, the console indicates that statistics collection can be enabled without regard for the hosting web conainer. In the case of Tomcat that means that the user can select the enable statistics collection but the action will have no effect and statistics will never be enabled.. -- 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-1216) ORB string - object conversion
[ http://issues.apache.org/jira/browse/GERONIMO-1216?page=comments#action_12360350 ] Alan Cabrera commented on GERONIMO-1216: A new patch would be good. Things have changed significantly. ORB string - object conversion Key: GERONIMO-1216 URL: http://issues.apache.org/jira/browse/GERONIMO-1216 Project: Geronimo Type: Sub-task Components: CORBA Versions: 1.0-M5 Reporter: Lars Kühne Assignee: Alan Cabrera Fix For: 1.x Attachments: issue1216.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: [jira] Updated: (GERONIMO-1130) Implement WebServer Manager (statistics gathering/reporting) management interface
I created GERONIMO-1350 for this purpose and attached a patch that only affects the console (not modules/management, modules/tomcat, or modules/jetty). http://issues.apache.org/jira/browse/GERONIMO-1350 Joe Aaron Mulder wrote: A Tomcat patch might be good so long as it only affects the console (e.g. not modules/tomcat). Aaron On 12/13/05, Joe Bohn [EMAIL PROTECTED] wrote: Aaron, I understand your reluctance at this late date. I was actually hoping to get this implemented last week ... but it's pretty late now and probably not worth the risk. It still bothers me that when running under tomcat the web server stats portlet gives the impression that it supports the statistics but in fact does nothing. Would it be helpful if I provided a quick patch to present a message indicating that the stats are not supported or do you want to leave well enough alone for 1.0? Joe Aaron Mulder (JIRA) wrote: [ http://issues.apache.org/jira/browse/GERONIMO-1130?page=all ] Aaron Mulder updated GERONIMO-1130: --- Fix Version: 1.1 (was: 1.x) I'm sorry to say, I don't feel real good about applying this at this point since we're geared up for the next round of TCK testing tonight and this patch covers a fair bit of stuff outside the portal. If the testing doesn't go well and we have more fixes tomorrow, I'll put it in tomorrow. Otherwise, it'll be early 1.1. Implement WebServer Manager (statistics gathering/reporting) management interface - Key: GERONIMO-1130 URL: http://issues.apache.org/jira/browse/GERONIMO-1130 Project: Geronimo Type: New Feature Components: management, console Versions: 1.0-M5 Environment: all Reporter: Joe Bohn Assignee: Joe Bohn Fix For: 1.1 Attachments: StatsJetty5.1.5.patch, StatsJetty5.1.7rc05.patch, StatsJettyG1.0.patch Jetty has a statistics gathering and reporting capability that is support in the console via the Web Server Manager portlet. We should provide similar monitoring capabilities for tomcat. However, the Jetty implementation is tightly bound to Jetty. We need a more generic interface build upon the principles of JSR77 to address statistical information for the web server (both jetty and tomcat). -- Joe Bohn [EMAIL PROTECTED] He is no fool who gives what he cannot keep, to gain what he cannot lose. -- Jim Elliot -- Joe Bohn [EMAIL PROTECTED] He is no fool who gives what he cannot keep, to gain what he cannot lose. -- Jim Elliot
[jira] Assigned: (GERONIMO-1216) ORB string - object conversion
[ http://issues.apache.org/jira/browse/GERONIMO-1216?page=all ] Alan Cabrera reassigned GERONIMO-1216: -- Assign To: Lars Kühne (was: Alan Cabrera) ORB string - object conversion Key: GERONIMO-1216 URL: http://issues.apache.org/jira/browse/GERONIMO-1216 Project: Geronimo Type: Sub-task Components: CORBA Versions: 1.0-M5 Reporter: Lars Kühne Assignee: Lars Kühne Fix For: 1.x Attachments: issue1216.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: Fwd: OpenEJB Question
Hi Manu, This was a simple TranQL fix. So, you simply need to build TranQL and drop it in your repo (you do not need a full rebuild of Geronimo). Thanks, Gianny Manu George wrote: Hi Gianny Great to know its fixed. Will try it out after building geronimo from source. Thanks Manu On 12/13/05, *Gianny Damour* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Hi Manu, Thanks for your debugging! This was a bug in IdentityDefinerBuilder, which was wrongly trying to identify a compound PK based on the number of primary key fields. This is now fixed. I will create a JIRA to track this issue tomorrow as it seems that JIRA is down tonight. Thanks, Gianny Manu George wrote: Hi Gianny, I have done all that you mentioned. I am still getting the error.I have replicated the issue in a simple EJB,the example CMP in Ed Roman's book Mastering EJB. I am attaching the stack trace and the plans below 17:02:05,211 WARN [SystemExceptionInterceptor] Product snip While i was debugging I saw a method public IdentityTransform getPrimaryKeyTransform(Entity entity) in the class IdentityDefinerBuilder. Here based on size of pkFields the SimplePKTransform or CompoundPKTransform class is selected. In the case of a custom class with 1 field also the SimplePKTransform is selected. Is this how it should behave? Could you give a general idea of how the primary key values are taken from the Custom classes in OpenEJB? Thanks Manu
[jira] Updated: (GERONIMO-1216) ORB string - object conversion
[ http://issues.apache.org/jira/browse/GERONIMO-1216?page=all ] Lars Kühne updated GERONIMO-1216: - Attachment: issue1216-2.patch Here is version 2 of the patch. It is hand edited to remove other changes I already have locally, hope this works out... ORB string - object conversion Key: GERONIMO-1216 URL: http://issues.apache.org/jira/browse/GERONIMO-1216 Project: Geronimo Type: Sub-task Components: CORBA Versions: 1.0-M5 Reporter: Lars Kühne Assignee: Lars Kühne Fix For: 1.x Attachments: issue1216-2.patch, issue1216.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
Server Logs
Hi All, I have a general question about the Console/Server Logs. I'm trying to specify a different server log (geronimo.log) from the *Server Log Viewer* pull-down menu. So far there is only one option to select from and it is ruled by the value you specify in the server-log4j.properties file. If this is the case, why there is a pull-down menu in the *Server Log Viewer*. If this is for a future feature I would like to have some info as I am documenting administration now. Cheers! Hernan
svn commit: r356616 - in /incubator/activemq/trunk: activemq-core/src/main/java/org/activemq/broker/jmx/ activemq-core/src/main/java/org/activemq/transport/vm/ activemq-ra/src/main/rar/ assembly/src/r
Author: chirino
Date: Tue Dec 13 13:02:04 2005
New Revision: 356616
URL: http://svn.apache.org/viewcvs?rev=356616view=rev
Log:
- Updated the config xml to use new discovery syntax.
- Using specific version of activeio as that may change a bit soon.
- The vm transport now support specifing a broker config file:
vm://localhost?brokerConfig=xbean:/path/to/config/file
- Starting the JMX connector was taking a LONG time to start up... so I switch
to starting it up async.
- The object name for a managed transport connection could be invalid so we now
encode the name so that it's not.
Modified:
incubator/activemq/trunk/activemq-core/src/main/java/org/activemq/broker/jmx/ManagedTransportConnection.java
incubator/activemq/trunk/activemq-core/src/main/java/org/activemq/broker/jmx/ManagementContext.java
incubator/activemq/trunk/activemq-core/src/main/java/org/activemq/transport/vm/VMTransportFactory.java
incubator/activemq/trunk/activemq-ra/src/main/rar/broker-config.xml
incubator/activemq/trunk/assembly/src/release/conf/activemq.xml
incubator/activemq/trunk/etc/project.properties
Modified:
incubator/activemq/trunk/activemq-core/src/main/java/org/activemq/broker/jmx/ManagedTransportConnection.java
URL:
http://svn.apache.org/viewcvs/incubator/activemq/trunk/activemq-core/src/main/java/org/activemq/broker/jmx/ManagedTransportConnection.java?rev=356616r1=356615r2=356616view=diff
==
---
incubator/activemq/trunk/activemq-core/src/main/java/org/activemq/broker/jmx/ManagedTransportConnection.java
(original)
+++
incubator/activemq/trunk/activemq-core/src/main/java/org/activemq/broker/jmx/ManagedTransportConnection.java
Tue Dec 13 13:02:04 2005
@@ -25,6 +25,7 @@
import org.activemq.thread.TaskRunnerFactory;
import org.activemq.transport.Transport;
import org.activemq.util.IOExceptionSupport;
+import org.activemq.util.JMXSupport;
import org.apache.commons.logging.Log;
import org.apache.commons.logging.LogFactory;
@@ -116,7 +117,7 @@
Hashtable map = new Hashtable(connectorName.getKeyPropertyList());
map.put(Type, Connection);
String jmxConnectionId = ObjectName.quote(connectionId);
-map.put(Connection, jmxConnectionId);
+map.put(Connection, JMXSupport.encodeObjectNamePart(connectionId));
try {
return new ObjectName(connectorName.getDomain(), map);
}
Modified:
incubator/activemq/trunk/activemq-core/src/main/java/org/activemq/broker/jmx/ManagementContext.java
URL:
http://svn.apache.org/viewcvs/incubator/activemq/trunk/activemq-core/src/main/java/org/activemq/broker/jmx/ManagementContext.java?rev=356616r1=356615r2=356616view=diff
==
---
incubator/activemq/trunk/activemq-core/src/main/java/org/activemq/broker/jmx/ManagementContext.java
(original)
+++
incubator/activemq/trunk/activemq-core/src/main/java/org/activemq/broker/jmx/ManagementContext.java
Tue Dec 13 13:02:04 2005
@@ -82,12 +82,18 @@
getMBeanServer().invoke(namingServiceObjectName, start,
null, null);
} catch (Throwable ignore) {
}
-try {
-connectorServer.start();
-log.info(JMX consoles can connect to +
connectorServer.getAddress());
-} catch (IOException e) {
-log.warn(Failed to start jmx connector: +e.getMessage());
-}
+Thread t = new Thread(JMX connector) {
+public void run() {
+try {
+connectorServer.start();
+log.info(JMX consoles can connect to +
connectorServer.getAddress());
+} catch (IOException e) {
+log.warn(Failed to start jmx connector:
+e.getMessage());
+}
+}
+};
+t.setDaemon(true);
+t.start();
}
}
Modified:
incubator/activemq/trunk/activemq-core/src/main/java/org/activemq/transport/vm/VMTransportFactory.java
URL:
http://svn.apache.org/viewcvs/incubator/activemq/trunk/activemq-core/src/main/java/org/activemq/transport/vm/VMTransportFactory.java?rev=356616r1=356615r2=356616view=diff
==
---
incubator/activemq/trunk/activemq-core/src/main/java/org/activemq/transport/vm/VMTransportFactory.java
(original)
+++
incubator/activemq/trunk/activemq-core/src/main/java/org/activemq/transport/vm/VMTransportFactory.java
Tue Dec 13 13:02:04 2005
@@ -76,8 +76,13 @@
try {
host = location.getHost();
options = URISupport.parseParamters(location);
-Map brokerOptions =
IntrospectionSupport.extractProperties(options, broker.);
-brokerURI = new
Re: Server Logs
If you configured more than one log file in your configuration, there should be more than one option in the menu. Aaron On 12/13/05, Hernan Cunico [EMAIL PROTECTED] wrote: Hi All, I have a general question about the Console/Server Logs. I'm trying to specify a different server log (geronimo.log) from the *Server Log Viewer* pull-down menu. So far there is only one option to select from and it is ruled by the value you specify in the server-log4j.properties file. If this is the case, why there is a pull-down menu in the *Server Log Viewer*. If this is for a future feature I would like to have some info as I am documenting administration now. Cheers! Hernan
[jira] Resolved: (GERONIMO-1350) Web Console indicates that web server stats are available for Tomcat when they really are not
[ http://issues.apache.org/jira/browse/GERONIMO-1350?page=all ] Aaron Mulder resolved GERONIMO-1350: Resolution: Fixed Applied to 1.0 branch (356626) Web Console indicates that web server stats are available for Tomcat when they really are not - Key: GERONIMO-1350 URL: http://issues.apache.org/jira/browse/GERONIMO-1350 Project: Geronimo Type: Bug Components: console Versions: 1.0 Environment: Win XP Reporter: Joe Bohn Assignee: Joe Bohn Priority: Minor Fix For: 1.0 Attachments: NoTomcatStats.patch The Web Server view in the Web Console includes a portlet to display web server statistics. This functinoality is implemented for Jetty but is not currently implemented for Tomcat. However, the console indicates that statistics collection can be enabled without regard for the hosting web conainer. In the case of Tomcat that means that the user can select the enable statistics collection but the action will have no effect and statistics will never be enabled.. -- 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-1350) Web Console indicates that web server stats are available for Tomcat when they really are not
[ http://issues.apache.org/jira/browse/GERONIMO-1350?page=all ] Aaron Mulder updated GERONIMO-1350: --- Version: 1.0-M5 (was: 1.0) Web Console indicates that web server stats are available for Tomcat when they really are not - Key: GERONIMO-1350 URL: http://issues.apache.org/jira/browse/GERONIMO-1350 Project: Geronimo Type: Bug Components: console Versions: 1.0-M5 Environment: Win XP Reporter: Joe Bohn Assignee: Joe Bohn Priority: Minor Fix For: 1.0 Attachments: NoTomcatStats.patch The Web Server view in the Web Console includes a portlet to display web server statistics. This functinoality is implemented for Jetty but is not currently implemented for Tomcat. However, the console indicates that statistics collection can be enabled without regard for the hosting web conainer. In the case of Tomcat that means that the user can select the enable statistics collection but the action will have no effect and statistics will never be enabled.. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: svn commit: r356493 - in /geronimo/devtools/trunk/modules/eclipse-plugin: ./ features/org.apache.geronimo.installableruntime.feature/ plugins/org.apache.geronimo.deployment.model.edit/src/org/apac
[EMAIL PROTECTED] wrote: Author: sppatel Date: Mon Dec 12 23:14:08 2005 New Revision: 356493 URL: http://svn.apache.org/viewcvs?rev=356493view=rev Log: RC4 released Added: geronimo/devtools/trunk/modules/eclipse-plugin/plugins/org.apache.geronimo.deployment.model.edit/src/org/apache/geronimo/xml/ns/naming/provider/EjbLocalRefTypeItemProvider.java geronimo/devtools/trunk/modules/eclipse-plugin/plugins/org.apache.geronimo.deployment.model.edit/src/org/apache/geronimo/xml/ns/naming/provider/EjbRefTypeItemProvider.java Modified: geronimo/devtools/trunk/modules/eclipse-plugin/features/org.apache.geronimo.installableruntime.feature/.project geronimo/devtools/trunk/modules/eclipse-plugin/maven.xml geronimo/devtools/trunk/modules/eclipse-plugin/plugins/org.apache.geronimo.deployment.model.edit/src/org/apache/geronimo/xml/ns/naming/provider/ResourceRefTypeItemProvider.java snip Added: geronimo/devtools/trunk/modules/eclipse-plugin/plugins/org.apache.geronimo.deployment.model.edit/src/org/apache/geronimo/xml/ns/naming/provider/EjbLocalRefTypeItemProvider.java URL: http://svn.apache.org/viewcvs/geronimo/devtools/trunk/modules/eclipse-plugin/plugins/org.apache.geronimo.deployment.model.edit/src/org/apache/geronimo/xml/ns/naming/provider/EjbLocalRefTypeItemProvider.java?rev=356493view=auto == --- geronimo/devtools/trunk/modules/eclipse-plugin/plugins/org.apache.geronimo.deployment.model.edit/src/org/apache/geronimo/xml/ns/naming/provider/EjbLocalRefTypeItemProvider.java (added) +++ geronimo/devtools/trunk/modules/eclipse-plugin/plugins/org.apache.geronimo.deployment.model.edit/src/org/apache/geronimo/xml/ns/naming/provider/EjbLocalRefTypeItemProvider.java Mon Dec 12 23:14:08 2005 @@ -0,0 +1,338 @@ +/** snip + +import org.apache.geronimo.deployment.model.edit.GeronimoEMFEditPlugin; Where is GeronimoEMFEditPlugin defined? Thanks Bill
[jira] Created: (GERONIMO-1354) The var/config.xml file is always re-written even if no attribute changes are made by the user
The var/config.xml file is always re-written even if no attribute changes are made by the user -- Key: GERONIMO-1354 URL: http://issues.apache.org/jira/browse/GERONIMO-1354 Project: Geronimo Type: Bug Components: startup/shutdown, usability Versions: 1.0 Reporter: John Sisson Fix For: 1.1 This means the user can never edit the config.xml file while Geronimo is running. The user has to shut down Geronimo and then make their changes and therefore the amount of time to implement a change is longer than needed. For 1.0 I will add some extra text to the warning in the top of the config.xml file ( see org.apache.geronimo.system.configuration.ServerOverride) that tells the user not to edit the file whilst Geronimo is 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: Disasterous problem with 2 spec jars
For the record...
Maven does not use the eclipse compiler without it being configured.
However, by default it is -source 1.3 and -target 1.1 (maximum JVM
compatibility). It's the -target 1.1 that adds these signatures.
Adding source1.4/source and target1.4/target fixed the issue.
- Brett
On 12/13/05, Kevan Miller [EMAIL PROTECTED] wrote:
I don't fully understand the issue, but Eclipse may not be doing the wrong
thing... Sun JDK 1.5 will, in fact, behave in the same manner (I haven't
tested to see how 1.5 will compile the same class).
Just to be clear, the near-term options seem to be:
1) switch spec build to maven 1
2) configure maven 2 to use javac from Sun 1.4 (there are references to
setting a compilerId in the maven-compiler-plug
3) challenge the test results
We should be able to easily determine if 2 will work... If not, then get
started on 1...
--kevan
On 12/13/05, Rick McGuire [EMAIL PROTECTED] wrote:
I just took a look at the Sun version of the BodyPart class, and it is
similarly truncated (although it supports a setParent() method in
addition to getParent()). It appears that the eclipse compiler is
adding this incorrectly. It makes sense that it shouldn't, since the
BodyPart class is abstract. It NEEDS to leave all of the unimplemented
methods unimplemented to ensure that subclasses complete the concrete
class contract.
Rick
David Jencks wrote:
Sachin says that maven 2 uses the eclipse compiler rather than javac
and that judging by its behavior when looking at binary classes in
eclipse it may well be producing these bad class files. It appears
that all the methods in the implements interfaces have been added
to the class.
Presumably the solution is to build with maven 1.
If the eclipse compiler is in fact at fault, I think that this will
prevent us from using maven 2 until either a javac compiler is
provided or the eclipse compiler is fixed. If the eclipse compiler
behavior is actually according to the jdk spec we may have a
different issue.
thanks
david jencks
On Dec 13, 2005, at 1:11 AM, David Jencks wrote:
Something is dreadfully wrong with two of the spec jars build by
maven 2.
The javamail BodyPart class source looks like this:
package javax.mail;
/**
* @version $Rev: 54266 $ $Date: 2004-10-10 14:02:50 -0700 (Sun, 10
Oct 2004) $
*/
public abstract class BodyPart implements Part {
protected Multipart parent;
public Multipart getParent() {
return parent;
}
}
Decompiling the class (1951 bytes) from the maven 2 build gives this:
David-Jencks-Computer:~/geronimo/geronimo/svn/geronimo/branches/1.0
david$ javap -classpath
~/downloads/geronimo-javamail_1.3.1_spec-1.0.jar
javax.mail.BodyPart
Compiled from BodyPart.java
public abstract class javax.mail.BodyPart extends java.lang.Object
implements javax.mail.Part{
protected javax.mail.Multipart parent;
public javax.mail.BodyPart ();
public javax.mail.Multipart getParent();
public abstract void writeTo(java.io.OutputStream);
throws java/io/IOException, javax/mail/MessagingException
public abstract void setText( java.lang.String);
throws javax/mail/MessagingException
public abstract void setHeader(java.lang.String,java.lang.String);
throws javax/mail/MessagingException
public abstract void setFileName( java.lang.String);
throws javax/mail/MessagingException
public abstract void setDisposition(java.lang.String);
throws javax/mail/MessagingException
public abstract void setDescription( java.lang.String);
throws javax/mail/MessagingException
public abstract void setDataHandler(javax.activation.DataHandler);
throws javax/mail/MessagingException
public abstract void setContent(
java.lang.Object,java.lang.String);
throws javax/mail/MessagingException
public abstract void setContent(javax.mail.Multipart);
throws javax/mail/MessagingException
public abstract void removeHeader(java.lang.String);
throws javax/mail/MessagingException
public abstract boolean isMimeType(java.lang.String);
throws javax/mail/MessagingException
public abstract int getSize();
throws javax/mail/MessagingException
public abstract java.util.Enumeration
getNonMatchingHeaders(java.lang.String[]);
throws javax/mail/MessagingException
public abstract java.util.Enumeration
getMatchingHeaders(java.lang.String[]);
throws javax/mail/MessagingException
public abstract int getLineCount();
throws javax/mail/MessagingException
public abstract java.io.InputStream getInputStream();
throws java/io/IOException, javax/mail/MessagingException
public abstract java.lang.String[]
[jira] Created: (GERONIMO-1355) Geronimo Server Plug-in Needs User Documentation
Geronimo Server Plug-in Needs User Documentation Key: GERONIMO-1355 URL: http://issues.apache.org/jira/browse/GERONIMO-1355 Project: Geronimo Type: Bug Components: eclipse-plugin Versions: 1.0-M5 Environment: Windows XP Reporter: Arthur Ryman I was trying to install the server adapter in WTP 1.0 RC4 but didn't get very far. I don't understand the expected behavior after download. What do I need to configure. In the New Server Runtime dialog there are two buttons. [Browse] and [Install Server]. I believe the [Browse] button just want the location of the Geronimo runtime, i.e. where I unzipped the download (I am trying to install manually since the Update Manager approach failed). What does [Install Server] do? It also prompts for a directory. What is that used for? I'd appreciate some online Help. How about adding some Dynamic Help to explain the buttons, or maybe a new article or tutorial. The old Tim Francis article skips over the install details. Thx. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: svn commit: r356493 - in /geronimo/devtools/trunk/modules/eclipse-plugin: ./ features/org.apache.geronimo.installableruntime.feature/ plugins/org.apache.geronimo.deployment.model.edit/src/org/apac
Sachin Patel wrote: In the plugins directory. (org.apache.geronimo.deployment.model.edit) The bundle activator is generated dynamically along with the rest of the classes until I get to each of them individual to do custom overrides on the generated code for our editors. So currently there's only about 4 or 5 classes in the repo for that plugin. When I do a build of the eclipse plugin, I see messages like this: [java] [emf.XSD2Java] Generating Java class org.apache.geronimo.deployment.model.edit.GeronimoEMFEditPlugin Then hit a compile failure a bit further on: [javac] Compiling 5 source files to C:\home\apache\devtools\modules\eclipse-plugin\plugins\org.apache.geronimo.deployment.model.edit\target\classes C:\home\apache\devtools\modules\eclipse-plugin\plugins\org.apache.geronimo.deployment.model.edit\src\org\apache\geronimo\xml\ns\naming\provider\EjbLocalRefTypeItemProvider.java:21: package org.apache.geronimo.deployment.model.edit does not exist import org.apache.geronimo.deployment.model.edit.GeronimoEMFEditPlugin; The five source files in the *.model.edit.* directory are: EjbLocalRefTypeItemProvider.java EjbRefTypeItemProvider.java NamingItemProviderAdapterFactory.java ResourceEnvRefTypeItemProvider.java ResourceRefTypeItemProvider.java Building against the 1.0 branch. Any suggestions for how to debug? Thanks, Bill
[jira] Commented: (GERONIMO-1355) Geronimo Server Plug-in Needs User Documentation
[ http://issues.apache.org/jira/browse/GERONIMO-1355?page=comments#action_12360366 ] Arthur Ryman commented on GERONIMO-1355: To proceed with testing, I created a directory for the [Install Server] button. However, Eclipse seemed to hang at that point. I got an hourglass cursor and my window said Not Responding.If this task takes a long time, it should be done in a background job. What is supposed to happen during install? Geronimo Server Plug-in Needs User Documentation Key: GERONIMO-1355 URL: http://issues.apache.org/jira/browse/GERONIMO-1355 Project: Geronimo Type: Bug Components: eclipse-plugin Versions: 1.0-M5 Environment: Windows XP Reporter: Arthur Ryman I was trying to install the server adapter in WTP 1.0 RC4 but didn't get very far. I don't understand the expected behavior after download. What do I need to configure. In the New Server Runtime dialog there are two buttons. [Browse] and [Install Server]. I believe the [Browse] button just want the location of the Geronimo runtime, i.e. where I unzipped the download (I am trying to install manually since the Update Manager approach failed). What does [Install Server] do? It also prompts for a directory. What is that used for? I'd appreciate some online Help. How about adding some Dynamic Help to explain the buttons, or maybe a new article or tutorial. The old Tim Francis article skips over the install details. Thx. -- 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-1352) RMI port number is not specified in URL for JMXConnector in server config.xml files
[ http://issues.apache.org/jira/browse/GERONIMO-1352?page=all ] John Sisson reassigned GERONIMO-1352: - Assign To: (was: John Sisson) RMI port number is not specified in URL for JMXConnector in server config.xml files --- Key: GERONIMO-1352 URL: http://issues.apache.org/jira/browse/GERONIMO-1352 Project: Geronimo Type: Bug Components: startup/shutdown, usability Reporter: John Sisson Fix For: 1.0 The port number should be specified in the JMXConnector URL so that a user can search and replace the current port number (e.g. 1099) with the new value. Currently the JMXConnector URL does not specified the port number therefore it always uses the default port. Currently if a user changes the RMI port number they will get exceptions at startup. I tried changing the JMXConnector URL to specify the port but it was not used. Basically this means if a site has port 1099 in use, they cannot run Geronimo. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (GERONIMO-903) Update Log4J usage from 1.2.8 to latest maintenance version of 1.2.11
[ http://issues.apache.org/jira/browse/GERONIMO-903?page=comments#action_12360368 ] Fredrik Westermarck commented on GERONIMO-903: -- Consider using the newly released log4j 1.2.13 instead of 1.2.11 since it includes the long awaited trace loglevel. Update Log4J usage from 1.2.8 to latest maintenance version of 1.2.11 - Key: GERONIMO-903 URL: http://issues.apache.org/jira/browse/GERONIMO-903 Project: Geronimo Type: Improvement Components: common Versions: 1.0-M5 Environment: All Reporter: Donald Woods Priority: Trivial Fix For: 1.1 Upgrade to the latest log4j maintenance version, which is 1.2.11and is available to maven on ibiblio - http://www.ibiblio.org/maven/log4j/jars/log4j-1.2.11.jar Updates required in project.properties for Geronimo and OpenEJB and any project.xml which is currently hardcoded to use log4j-1.2.8 -- 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: [continuum] BUILD FAILURE: Geronimo:: Assemblies
Still failing On Dec 12, 2005, at 3:50 PM, David Blevins wrote: Still getting this error on Assemblies. On Dec 12, 2005, at 3:23 PM, continuum wrote: izpack:izpack-prepare: [echo] izpack-prepare is running [echo] Processing installer file geronimo-izpack.xml [echo] Processing installer file izpack-process.xml [echo] Processing installer file izpack-user-input.xml izpack:izpack-installer-build: [echo] IZPack installer build is running. [echo] IZPack Version is 3.8.0 [java] [java] .:: IzPack - Version 3.8.0 ::. [java] [java] compiler specifications version : 1.0 [java] [java] - Copyright (C) 2001-2005 Julien Ponge [java] - Visit http://www.izforge.com/ for the latests releases [java] - Released under the terms of the Apache Software License version 2.0. [java] [java] - Processing : /home/continuum/build/work/4/ assemblies/j2ee-installer/target/geronimo-1.0-SNAPSHOT/geronimo- izpack.xml [java] - Output : /home/continuum/build/work/4/ assemblies/j2ee-installer/target/geronimo-installer-1.0-SNAPSHOT.jar [java] - Base path : . [java] - Kind: standard [java] - Compression : default [java] - Compr. level: -1 [java] [java] Adding resource: IzPack.uninstaller [java] Setting the installer information [java] Adding content of jar: file:/home/continuum/.maven/ repository/izpack/jars/standalone-compiler-3.8.0.jar!/lib/ liquidlnf.jar [java] Setting the GUI preferences [java] Adding langpack: eng [java] Adding resource: flag.eng [java] Adding resource: Installer.image [java] - Fatal error : [java]/home/continuum/build/work/4/assemblies/j2ee- installer/target/geronimo-1.0-SNAPSHOT/geronimo-izpack.xml:22: Resource not found: /home/continuum/build/work/4/assemblies/j2ee- installer/target/geronimo-1.0-SNAPSHOT/LICENSE.txt [java] com.izforge.izpack.compiler.CompilerException: /home/ continuum/build/work/4/assemblies/j2ee-installer/target/ geronimo-1.0-SNAPSHOT/geronimo-izpack.xml:22: Resource not found: / home/continuum/build/work/4/assemblies/j2ee-installer/target/ geronimo-1.0-SNAPSHOT/LICENSE.txt [java] at com.izforge.izpack.compiler.CompilerConfig.parseError (CompilerConfig.java:1518) [java] at com.izforge.izpack.compiler.CompilerConfig.findProjectResource (CompilerConfig.java:1447) [java] at com.izforge.izpack.compiler.CompilerConfig.addResources (CompilerConfig.java:1044) [java] at com.izforge.izpack.compiler.CompilerConfig.executeCompiler (CompilerConfig.java:313) [java] at com.izforge.izpack.compiler.CompilerConfig.main (CompilerConfig.java:1847) [java] at com.izforge.izpack.compiler.Compiler.main (Compiler.java:620) [java] [java] (tip : use -? to get the commmand line parameters) [java] [ERROR] Java Result: 1 BUILD FAILED File.. /home/continuum/.maven/cache/maven-multiproject- plugin-1.4.1/plugin.jelly Element... maven:reactor Line.. 218 Column -1 Unable to obtain goal [multiproject:install-callback] -- /home/ continuum/.maven/cache/geronimo-izpack-plugin-1.0-SNAPSHOT/ plugin.jelly:77:-1: ant:copy Warning: Could not find file /home/ continuum/build/work/4/assemblies/j2ee-installer/target/geronimo- installer-1.0-SNAPSHOT.jar to copy. Total time : 1 minutes 43 seconds Finished at : Monday, December 12, 2005 3:23:36 PM PST * ***
[jira] Updated: (GERONIMO-1352) RMI port number is not specified in URL for JMXConnector in server config.xml files
[ http://issues.apache.org/jira/browse/GERONIMO-1352?page=all ] John Sisson updated GERONIMO-1352: -- Fix Version: 1.1 (was: 1.0) Assign To: Aaron Mulder Assigned to you.. Matt made me! RMI port number is not specified in URL for JMXConnector in server config.xml files --- Key: GERONIMO-1352 URL: http://issues.apache.org/jira/browse/GERONIMO-1352 Project: Geronimo Type: Bug Components: startup/shutdown, usability Reporter: John Sisson Assignee: Aaron Mulder Fix For: 1.1 The port number should be specified in the JMXConnector URL so that a user can search and replace the current port number (e.g. 1099) with the new value. Currently the JMXConnector URL does not specified the port number therefore it always uses the default port. Currently if a user changes the RMI port number they will get exceptions at startup. I tried changing the JMXConnector URL to specify the port but it was not used. Basically this means if a site has port 1099 in use, they cannot run Geronimo. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (GERONIMO-1192) Installer should create a config.xml for the target install
[ http://issues.apache.org/jira/browse/GERONIMO-1192?page=all ] John Sisson updated GERONIMO-1192: -- Fix Version: 1.1 (was: 1.0) 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.1 Attachments: installer-200512111301.patch, installer-200512112003.patch, installer-200512121118.patch, installer-200512122002.patch, 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
Re: Geronimo 1.0 Status ... Countdown to release
Another update It's looking good. We have a bunch of people working on release notes. I'm double-checking some tests, then going to cut a tag 1.0.0 and create the proposed final binaries. When all that is done we can start the vote and the final tck run -- both take a few days. More soon. -David On Dec 11, 2005, at 11:25 PM, Matt Hogstrom wrote: All, We wanted to update everyone on where the release stands. A lot of progress has been made in terms of reducing the number of JIRAs, identifying minor bug fixes and preparing for the final certification and testing. Here is the plan for tonight (as of 23:25 PST): Finish some final mods for the release Start a certification set of tests Continue testing the release. For tomorrow morning (assuming all goes well tonight) we will have a release candidate for download and review and begin a vote with that candidate. Please take some time to download the binary and test out the server and provide your feedback. We're keenly interested in your feedback. Thanks for your patience and hats off to the G-team as they've been working diligently here at the ApacheCon hackathon to drive this release to completion. - Matt
[jira] Updated: (GERONIMO-1344) Get java usage help when a trailing slash '/' is in GERONIMO_HOME environment variable when running geronimo.bat
[ http://issues.apache.org/jira/browse/GERONIMO-1344?page=all ] John Sisson updated GERONIMO-1344: -- Fix Version: 1.1 (was: 1.0) Version: 1.0 Get java usage help when a trailing slash '/' is in GERONIMO_HOME environment variable when running geronimo.bat Key: GERONIMO-1344 URL: http://issues.apache.org/jira/browse/GERONIMO-1344 Project: Geronimo Type: Bug Components: startup/shutdown Versions: 1.0 Reporter: John Sisson Assignee: John Sisson Priority: Minor Fix For: 1.1 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (GERONIMO-1112) Problem with sending mail using G's JavaMail SMTP transport
[ http://issues.apache.org/jira/browse/GERONIMO-1112?page=all ]
John Sisson resolved GERONIMO-1112:
---
Resolution: Fixed
Problem with sending mail using G's JavaMail SMTP transport
---
Key: GERONIMO-1112
URL: http://issues.apache.org/jira/browse/GERONIMO-1112
Project: Geronimo
Type: Bug
Components: mail
Reporter: Geir Magnusson Jr
Assignee: Bruce Snyder
Fix For: 1.0
The following was reported by Chris Cardona on 26-Aug-2005 on the dev list :
I am trying to use the JavaMail in sandbox and I used
the ff. steps:
1. Checked out geronimo, applied the javamail portlet
patch, built geronimo
2. Compiled the files from sandbox/mail and created a
jar then I copied it to the geronimo snapshot
repository folder
3. I included the jar as a dependency in the
\console-ear\src\plan\geronimo-application.xml
4. Built and redeployed geronimo console
5. Started Geronimo and James
6. Opened the JavaMail portlet then sent out a test
email by clicking the 'test' link
Here's the code that sends the email:
...
String mailGBean =
actionRequest.getParameter(mailGBean);
String toAddress =
actionRequest.getParameter(toAddress);
String fromAddress =
actionRequest.getParameter(fromAddress);
ObjectName mailInfo = new ObjectName(mailGBean);
Session session = (Session) kernel.invoke(mailInfo,
$getResource);
Transport trans =
session.getTransport(MAIL_TRANSPORT);
MimeMessage message = new MimeMessage(session);
message.setFrom(new InternetAddress(fromAddress));
message.addRecipients(Message.RecipientType.TO,
toAddress);
message.setSubject(MAIL_SUBJECT);
message.setText(MAIL_BODY +
mailInfo.getKeyProperty(name));
trans.connect();
trans.sendMessage(message, new Address[] {new
InternetAddress(toAddress)});
...
I got the ff. exception:
Booting Geronimo Kernel (in Java 1.4.2_08)...
Starting Geronimo Application Server
[] 100% 24s Startup complete
Listening on Ports:
1099 0.0.0.0 RMI Naming
1527 127.0.0.1 Derby Connector
4201 127.0.0.1 OpenEJB Connector EJB
8080 0.0.0.0 Jetty Connector HTTP
8443 0.0.0.0 Jetty Connector HTTPS
61616 0.0.0.0 ActiveMQ Message Broker Connector
Geronimo Application Server started
22:34:25,030 WARN [Servlet]
org.apache.pluto.portalImpl.Servlet#init(): Couldn'
t read property pluto.allowSetBufferSize from config
file ConfigService.proper
ties
22:39:31,601 WARN [Servlet]
org.apache.pluto.portalImpl.Servlet#init(): Couldn'
t read property pluto.allowSetBufferSize from config
file ConfigService.proper
ties
22:49:36,441 WARN [Servlet]
org.apache.pluto.portalImpl.Servlet#init(): Couldn'
t read property pluto.allowSetBufferSize from config
file ConfigService.proper
ties
22:50:05,463 ERROR [PortletInvokerImpl]
PortletInvokerImpl.render() - Error whil
e dispatching portlet.
javax.portlet.PortletException
at
org.apache.geronimo.console.mailmanager.MailManagerPortlet.processSen
dMail(MailManagerPortlet.java:513)
at
org.apache.geronimo.console.mailmanager.MailManagerPortlet.processAct
ion(MailManagerPortlet.java:366)
at
org.apache.pluto.core.PortletServlet.dispatch(PortletServlet.java:229
)
at
org.apache.pluto.core.PortletServlet.doGet(PortletServlet.java:158)
at
javax.servlet.http.HttpServlet.service(HttpServlet.java:595)
at
javax.servlet.http.HttpServlet.service(HttpServlet.java:688)
at
org.apache.pluto.core.PortletServlet.service(PortletServlet.java:153)
at
org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:427
)
at
org.apache.geronimo.jetty.JettyServletHolder.handle(JettyServletHolde
r.java:92)
at
org.mortbay.jetty.servlet.WebApplicationHandler$CachedChain.doFilter(
WebApplicationHandler.java:832)
at
org.mortbay.jetty.servlet.JSR154Filter.doFilter(JSR154Filter.java:171
)
at
org.mortbay.jetty.servlet.WebApplicationHandler$CachedChain.doFilter(
WebApplicationHandler.java:823)
at
org.mortbay.jetty.servlet.WebApplicationHandler.dispatch(WebApplicati
onHandler.java:473)
at
org.mortbay.jetty.servlet.Dispatcher.dispatch(Dispatcher.java:272)
at
org.mortbay.jetty.servlet.Dispatcher.include(Dispatcher.java:161)
at
org.apache.pluto.invoker.impl.PortletInvokerImpl.invoke(PortletInvoke
rImpl.java:120)
at
org.apache.pluto.invoker.impl.PortletInvokerImpl.action(PortletInvoke
rImpl.java:68)
at
org.apache.pluto.PortletContainerImpl.processPortletAction(PortletCon
tainerImpl.java:164)
at
org.apache.pluto.portalImpl.core.PortletContainerWrapperImpl.processP
ortletAction(PortletContainerWrapperImpl.java:82)
at
org.apache.pluto.portalImpl.Servlet.doGet(Servlet.java:188)
at
[jira] Closed: (GERONIMO-1112) Problem with sending mail using G's JavaMail SMTP transport
[ http://issues.apache.org/jira/browse/GERONIMO-1112?page=all ]
John Sisson closed GERONIMO-1112:
-
Problem with sending mail using G's JavaMail SMTP transport
---
Key: GERONIMO-1112
URL: http://issues.apache.org/jira/browse/GERONIMO-1112
Project: Geronimo
Type: Bug
Components: mail
Reporter: Geir Magnusson Jr
Assignee: Bruce Snyder
Fix For: 1.0
The following was reported by Chris Cardona on 26-Aug-2005 on the dev list :
I am trying to use the JavaMail in sandbox and I used
the ff. steps:
1. Checked out geronimo, applied the javamail portlet
patch, built geronimo
2. Compiled the files from sandbox/mail and created a
jar then I copied it to the geronimo snapshot
repository folder
3. I included the jar as a dependency in the
\console-ear\src\plan\geronimo-application.xml
4. Built and redeployed geronimo console
5. Started Geronimo and James
6. Opened the JavaMail portlet then sent out a test
email by clicking the 'test' link
Here's the code that sends the email:
...
String mailGBean =
actionRequest.getParameter(mailGBean);
String toAddress =
actionRequest.getParameter(toAddress);
String fromAddress =
actionRequest.getParameter(fromAddress);
ObjectName mailInfo = new ObjectName(mailGBean);
Session session = (Session) kernel.invoke(mailInfo,
$getResource);
Transport trans =
session.getTransport(MAIL_TRANSPORT);
MimeMessage message = new MimeMessage(session);
message.setFrom(new InternetAddress(fromAddress));
message.addRecipients(Message.RecipientType.TO,
toAddress);
message.setSubject(MAIL_SUBJECT);
message.setText(MAIL_BODY +
mailInfo.getKeyProperty(name));
trans.connect();
trans.sendMessage(message, new Address[] {new
InternetAddress(toAddress)});
...
I got the ff. exception:
Booting Geronimo Kernel (in Java 1.4.2_08)...
Starting Geronimo Application Server
[] 100% 24s Startup complete
Listening on Ports:
1099 0.0.0.0 RMI Naming
1527 127.0.0.1 Derby Connector
4201 127.0.0.1 OpenEJB Connector EJB
8080 0.0.0.0 Jetty Connector HTTP
8443 0.0.0.0 Jetty Connector HTTPS
61616 0.0.0.0 ActiveMQ Message Broker Connector
Geronimo Application Server started
22:34:25,030 WARN [Servlet]
org.apache.pluto.portalImpl.Servlet#init(): Couldn'
t read property pluto.allowSetBufferSize from config
file ConfigService.proper
ties
22:39:31,601 WARN [Servlet]
org.apache.pluto.portalImpl.Servlet#init(): Couldn'
t read property pluto.allowSetBufferSize from config
file ConfigService.proper
ties
22:49:36,441 WARN [Servlet]
org.apache.pluto.portalImpl.Servlet#init(): Couldn'
t read property pluto.allowSetBufferSize from config
file ConfigService.proper
ties
22:50:05,463 ERROR [PortletInvokerImpl]
PortletInvokerImpl.render() - Error whil
e dispatching portlet.
javax.portlet.PortletException
at
org.apache.geronimo.console.mailmanager.MailManagerPortlet.processSen
dMail(MailManagerPortlet.java:513)
at
org.apache.geronimo.console.mailmanager.MailManagerPortlet.processAct
ion(MailManagerPortlet.java:366)
at
org.apache.pluto.core.PortletServlet.dispatch(PortletServlet.java:229
)
at
org.apache.pluto.core.PortletServlet.doGet(PortletServlet.java:158)
at
javax.servlet.http.HttpServlet.service(HttpServlet.java:595)
at
javax.servlet.http.HttpServlet.service(HttpServlet.java:688)
at
org.apache.pluto.core.PortletServlet.service(PortletServlet.java:153)
at
org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:427
)
at
org.apache.geronimo.jetty.JettyServletHolder.handle(JettyServletHolde
r.java:92)
at
org.mortbay.jetty.servlet.WebApplicationHandler$CachedChain.doFilter(
WebApplicationHandler.java:832)
at
org.mortbay.jetty.servlet.JSR154Filter.doFilter(JSR154Filter.java:171
)
at
org.mortbay.jetty.servlet.WebApplicationHandler$CachedChain.doFilter(
WebApplicationHandler.java:823)
at
org.mortbay.jetty.servlet.WebApplicationHandler.dispatch(WebApplicati
onHandler.java:473)
at
org.mortbay.jetty.servlet.Dispatcher.dispatch(Dispatcher.java:272)
at
org.mortbay.jetty.servlet.Dispatcher.include(Dispatcher.java:161)
at
org.apache.pluto.invoker.impl.PortletInvokerImpl.invoke(PortletInvoke
rImpl.java:120)
at
org.apache.pluto.invoker.impl.PortletInvokerImpl.action(PortletInvoke
rImpl.java:68)
at
org.apache.pluto.PortletContainerImpl.processPortletAction(PortletCon
tainerImpl.java:164)
at
org.apache.pluto.portalImpl.core.PortletContainerWrapperImpl.processP
ortletAction(PortletContainerWrapperImpl.java:82)
at
org.apache.pluto.portalImpl.Servlet.doGet(Servlet.java:188)
at
Re: svn commit: r356493 - in /geronimo/devtools/trunk/modules/eclipse-plugin: ./ features/org.apache.geronimo.installableruntime.feature/ plugins/org.apache.geronimo.deployment.model.edit/src/org/apac
The [emf.XSD2Java] messages are normal. What command are you using to build? From inside /devtools/modules/eclipse-plugin/ Try.. maven clean build On 12/13/05 2:33 PM, Bill Stoddard [EMAIL PROTECTED] wrote: Sachin Patel wrote: In the plugins directory. (org.apache.geronimo.deployment.model.edit) The bundle activator is generated dynamically along with the rest of the classes until I get to each of them individual to do custom overrides on the generated code for our editors. So currently there's only about 4 or 5 classes in the repo for that plugin. When I do a build of the eclipse plugin, I see messages like this: [java] [emf.XSD2Java] Generating Java class org.apache.geronimo.deployment.model.edit.GeronimoEMFEditPlugin Then hit a compile failure a bit further on: [javac] Compiling 5 source files to C:\home\apache\devtools\modules\eclipse-plugin\plugins\org.apache.geronimo.dep loyment.model.edit\target\classes C:\home\apache\devtools\modules\eclipse-plugin\plugins\org.apache.geronimo.dep loyment.model.edit\src\org\apache\geronimo\xml\ns\naming\provider\EjbLocalRefT ypeItemProvider.java:21: package org.apache.geronimo.deployment.model.edit does not exist import org.apache.geronimo.deployment.model.edit.GeronimoEMFEditPlugin; The five source files in the *.model.edit.* directory are: EjbLocalRefTypeItemProvider.java EjbRefTypeItemProvider.java NamingItemProviderAdapterFactory.java ResourceEnvRefTypeItemProvider.java ResourceRefTypeItemProvider.java Building against the 1.0 branch. Any suggestions for how to debug? Thanks, Bill
[jira] Commented: (GERONIMO-1353) Geronimo Feature Failed to Install Properly
[ http://issues.apache.org/jira/browse/GERONIMO-1353?page=comments#action_12360377 ] Sachin Patel commented on GERONIMO-1353: I was able to get the feature to install, but WTP would not extract the server image into the directory specified. Due to the eclipse update manager defect when running within a runtime workbench, could not debug. Waiting for tim to get back to me. Geronimo Feature Failed to Install Properly --- Key: GERONIMO-1353 URL: http://issues.apache.org/jira/browse/GERONIMO-1353 Project: Geronimo Type: Bug Components: eclipse-plugin Versions: 1.0-M5 Environment: Windows XP Reporter: Arthur Ryman 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
[jira] Commented: (GERONIMO-1355) Geronimo Server Plug-in Needs User Documentation
[ http://issues.apache.org/jira/browse/GERONIMO-1355?page=comments#action_12360379 ] Sachin Patel commented on GERONIMO-1355: Yes I got the hang as well, the following bugzilla has been opened. Since the download is 50+ megs, theres no progress status shown to the user and it appears that the workbench is hung. https://bugs.eclipse.org/bugs/show_bug.cgi?id=120715 Also the UI layout is part of the generic server wizard framework, not in the geronimo plugin. I've already opened the following bugzilla for improvements to this panel... https://bugs.eclipse.org/bugs/show_bug.cgi?id=120743 The other concern is that the current design is for the geronimo server to be repackaged inside a plugin. This needs to change. The update manager has support for installing data archives. Using a install handler pointing the data archive using a URL mapping we should be able to avoid repackaging the server and just point to the binary distro's of geronimo. Geronimo Server Plug-in Needs User Documentation Key: GERONIMO-1355 URL: http://issues.apache.org/jira/browse/GERONIMO-1355 Project: Geronimo Type: Bug Components: eclipse-plugin Versions: 1.0-M5 Environment: Windows XP Reporter: Arthur Ryman I was trying to install the server adapter in WTP 1.0 RC4 but didn't get very far. I don't understand the expected behavior after download. What do I need to configure. In the New Server Runtime dialog there are two buttons. [Browse] and [Install Server]. I believe the [Browse] button just want the location of the Geronimo runtime, i.e. where I unzipped the download (I am trying to install manually since the Update Manager approach failed). What does [Install Server] do? It also prompts for a directory. What is that used for? I'd appreciate some online Help. How about adding some Dynamic Help to explain the buttons, or maybe a new article or tutorial. The old Tim Francis article skips over the install details. Thx. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: svn commit: r356493 - in /geronimo/devtools/trunk/modules/eclipse-plugin: ./ features/org.apache.geronimo.installableruntime.feature/ plugins/org.apache.geronimo.deployment.model.edit/src/org/apac
Sachin Patel wrote: The [emf.XSD2Java] messages are normal. What command are you using to build? From inside /devtools/modules/eclipse-plugin/ Try.. maven clean build Thanks Sachin. I must be missing something obvious... Ran maven clean build and hit this: BUILD FAILED File.. C:\Documents and Settings\Administrator\.maven\cache\maven-multiproject-plugin-1.3.1\plugin.jelly Element... maven:reactor Line.. 217 Column 9 The build cannot continue because of the following unsatisfied dependencies: org.apache.geronimo.j2ee.server.v1-0.5.0-SNAPSHOT.jar org.apache.geronimo.feature.source-0.5.0-SNAPSHOT.jar Total time: 2 minutes 7 seconds Finished at: Tue Dec 13 19:24:14 EST 2005 Neither of these are in the cvs.apache.org maven repo, http://cvs.apache.org/repository/geronimo-devtools/jars/ Are these autogenerated? Bill
svn commit: r356666 - in /incubator/activemq/trunk/activemq-web/src/java/org/activemq/web: MessageServlet.java WebClient.java
Author: chirino
Date: Tue Dec 13 17:07:08 2005
New Revision: 35
URL: http://svn.apache.org/viewcvs?rev=35view=rev
Log:
Was having some wierd issues with the consumer.. disabled continuations for
now (but i don't think that was the issue).
added a semaphore to avoid multiple blocking threads (i've got a feeling this
might be what fixed it).
Modified:
incubator/activemq/trunk/activemq-web/src/java/org/activemq/web/MessageServlet.java
incubator/activemq/trunk/activemq-web/src/java/org/activemq/web/WebClient.java
Modified:
incubator/activemq/trunk/activemq-web/src/java/org/activemq/web/MessageServlet.java
URL:
http://svn.apache.org/viewcvs/incubator/activemq/trunk/activemq-web/src/java/org/activemq/web/MessageServlet.java?rev=35r1=356665r2=35view=diff
==
---
incubator/activemq/trunk/activemq-web/src/java/org/activemq/web/MessageServlet.java
(original)
+++
incubator/activemq/trunk/activemq-web/src/java/org/activemq/web/MessageServlet.java
Tue Dec 13 17:07:08 2005
@@ -18,12 +18,10 @@
package org.activemq.web;
-import org.activemq.MessageAvailableConsumer;
-import org.activemq.MessageAvailableListener;
-import org.apache.commons.logging.Log;
-import org.apache.commons.logging.LogFactory;
-import org.mortbay.util.ajax.Continuation;
-import org.mortbay.util.ajax.ContinuationSupport;
+import java.io.IOException;
+import java.io.PrintWriter;
+import java.util.LinkedList;
+import java.util.List;
import javax.jms.Destination;
import javax.jms.JMSException;
@@ -36,10 +34,12 @@
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;
-import java.io.IOException;
-import java.io.PrintWriter;
-import java.util.LinkedList;
-import java.util.List;
+import org.activemq.MessageAvailableConsumer;
+import org.activemq.MessageAvailableListener;
+import org.apache.commons.logging.Log;
+import org.apache.commons.logging.LogFactory;
+import org.mortbay.util.ajax.Continuation;
+import org.mortbay.util.ajax.ContinuationSupport;
/**
* A servlet for sending and receiving messages to/from JMS destinations using
@@ -110,7 +110,7 @@
* from a queue
*/
protected void doDelete(HttpServletRequest request, HttpServletResponse
response) throws ServletException, IOException {
-doMessages(request, response, 1);
+doMessagesWithoutContinuation(request, response, 1);
}
/**
@@ -118,7 +118,7 @@
* from a queue
*/
protected void doGet(HttpServletRequest request, HttpServletResponse
response) throws ServletException, IOException {
-doMessages(request, response, -1);
+doMessagesWithoutContinuation(request, response, -1);
}
/**
@@ -229,6 +229,106 @@
throw new ServletException(Could not post JMS message: + e, e);
}
finally {
+if (log.isDebugEnabled()) {
+log.debug(Received + messages + message(s));
+}
+}
+}
+
+/**
+ * Reads a message from a destination up to some specific timeout period
+ *
+ * @param request
+ * @param response
+ * @throws ServletException
+ * @throws IOException
+ */
+protected void doMessagesWithoutContinuation(HttpServletRequest request,
HttpServletResponse response,
+int maxMessages) throws ServletException, IOException {
+
+int messages = 0;
+try {
+WebClient client = getWebClient(request);
+Destination destination = getDestination(client, request);
+long timeout = getReadTimeout(request);
+boolean ajax = isRicoAjax(request);
+if (!ajax)
+maxMessages = 1;
+
+if (log.isDebugEnabled()) {
+log.debug(Receiving message(s) from: + destination + with
timeout: + timeout);
+}
+
+MessageAvailableConsumer consumer = (MessageAvailableConsumer)
client.getConsumer(destination);
+Continuation continuation = null;
+Listener listener = null;
+Message message = null;
+
+// write a responds
+response.setContentType(text/xml);
+PrintWriter writer = response.getWriter();
+
+if (ajax)
+writer.println(ajax-response);
+
+// Only one client thread at a time should poll for messages.
+if (client.getSemaphore().tryAcquire()) {
+try {
+// Look for any available messages
+message = consumer.receive(timeout);
+
+// handle any message(s)
+if (message == null) {
+// No messages so OK response of for ajax else no
+// content.
+response.setStatus(ajax ? HttpServletResponse.SC_OK :
HttpServletResponse.SC_NO_CONTENT);
+} else {
Re: svn commit: r356493 - in /geronimo/devtools/trunk/modules/eclipse-plugin: ./ features/org.apache.geronimo.installableruntime.feature/ plugins/org.apache.geronimo.deployment.model.edit/src/org/apac
Just kicked off a build on Continuum and it passed. You're correct though I have not yet uploaded those snapshots. You could go into each of those directories and run maven on each of them individually and then go to the root and build. On 12/13/05 5:01 PM, Bill Stoddard [EMAIL PROTECTED] wrote: Sachin Patel wrote: The [emf.XSD2Java] messages are normal. What command are you using to build? From inside /devtools/modules/eclipse-plugin/ Try.. maven clean build Thanks Sachin. I must be missing something obvious... Ran maven clean build and hit this: BUILD FAILED File.. C:\Documents and Settings\Administrator\.maven\cache\maven-multiproject-plugin-1.3.1\plugin.jel ly Element... maven:reactor Line.. 217 Column 9 The build cannot continue because of the following unsatisfied dependencies: org.apache.geronimo.j2ee.server.v1-0.5.0-SNAPSHOT.jar org.apache.geronimo.feature.source-0.5.0-SNAPSHOT.jar Total time: 2 minutes 7 seconds Finished at: Tue Dec 13 19:24:14 EST 2005 Neither of these are in the cvs.apache.org maven repo, http://cvs.apache.org/repository/geronimo-devtools/jars/ Are these autogenerated? Bill
[jira] Created: (GERONIMO-1356) Clean up distributionDirectory element in project.xml files as it contains 'incubator'
Clean up distributionDirectory element in project.xml files as it contains 'incubator' Key: GERONIMO-1356 URL: http://issues.apache.org/jira/browse/GERONIMO-1356 Project: Geronimo Type: Task Components: buildsystem Reporter: John Sisson Priority: Trivial Fix For: 1.1 -- 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
ApacheCon Geronimo Clustering Huddle: 10:00am Wednesday, Hackathon Area.
Guys, Interest in clustering seems to be growing rapidly, along with requirements from various areas. I thought it would be useful to get everyone with an interest together in one place to answer peoples' questions about Geronimo clustering status and to canvas you all for expectations, requirements and ideas. regards, Jules
Re: Geronimo 1.0 Status ... Countdown to release
Cutting tag now -David On Dec 13, 2005, at 3:44 PM, David Blevins wrote: Another update It's looking good. We have a bunch of people working on release notes. I'm double-checking some tests, then going to cut a tag 1.0.0 and create the proposed final binaries. When all that is done we can start the vote and the final tck run -- both take a few days. More soon. -David On Dec 11, 2005, at 11:25 PM, Matt Hogstrom wrote: All, We wanted to update everyone on where the release stands. A lot of progress has been made in terms of reducing the number of JIRAs, identifying minor bug fixes and preparing for the final certification and testing. Here is the plan for tonight (as of 23:25 PST): Finish some final mods for the release Start a certification set of tests Continue testing the release. For tomorrow morning (assuming all goes well tonight) we will have a release candidate for download and review and begin a vote with that candidate. Please take some time to download the binary and test out the server and provide your feedback. We're keenly interested in your feedback. Thanks for your patience and hats off to the G-team as they've been working diligently here at the ApacheCon hackathon to drive this release to completion. - Matt
[jira] Closed: (GERONIMO-1216) ORB string - object conversion
[ http://issues.apache.org/jira/browse/GERONIMO-1216?page=all ] Alan Cabrera closed GERONIMO-1216: -- Resolution: Fixed ORB string - object conversion Key: GERONIMO-1216 URL: http://issues.apache.org/jira/browse/GERONIMO-1216 Project: Geronimo Type: Sub-task Components: CORBA Versions: 1.0-M5 Reporter: Lars Kühne Assignee: Lars Kühne Fix For: 1.x Attachments: issue1216-2.patch, issue1216.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-1296) Corba spec does not define ExceptionDetailMessage
[ http://issues.apache.org/jira/browse/GERONIMO-1296?page=all ] Alan Cabrera closed GERONIMO-1296: -- Resolution: Fixed Corba spec does not define ExceptionDetailMessage - Key: GERONIMO-1296 URL: http://issues.apache.org/jira/browse/GERONIMO-1296 Project: Geronimo Type: Sub-task Components: CORBA Versions: 1.0-M5 Reporter: Anders Hessellund Jensen Assignee: Alan Cabrera Fix For: 1.1 Attachments: ExceptionDetailMessage.patch The corba spec does not define ExceptionDetailMessage in package org.omg.IOP. This causes a build failure. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (GERONIMO-1357) Apache Geronimo V1.0 Documentation Draft
Apache Geronimo V1.0 Documentation Draft Key: GERONIMO-1357 URL: http://issues.apache.org/jira/browse/GERONIMO-1357 Project: Geronimo Type: Improvement Versions: 1.0 Environment: All Reporter: Hernan Cunico Assigned to: Hernan Cunico Better later than never, here is the updated HTML documentation. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (GERONIMO-1357) Apache Geronimo V1.0 Documentation Draft
[ http://issues.apache.org/jira/browse/GERONIMO-1357?page=all ] Hernan Cunico updated GERONIMO-1357: Attachment: GERONIMO_DOC_2005_12_13.zip Apache Geronimo V1.0 Documentation Draft Key: GERONIMO-1357 URL: http://issues.apache.org/jira/browse/GERONIMO-1357 Project: Geronimo Type: Improvement Versions: 1.0 Environment: All Reporter: Hernan Cunico Assignee: Hernan Cunico Attachments: GERONIMO_DOC_2005_12_13.zip Better later than never, here is the updated HTML documentation. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Geronimo Documentation update
Hi All, better later than never, I just created a JIRA http://issues.apache.org/jira/browse/GERONIMO-1357 with updated documentation. Major updates were on the Administration section. Cheers! Hernan
[Vote] Geronimo V1.0 Release binaries
We are currently going through the final testing phases and have the binary images available for review. These images represent what we will be making available to users after we confirm the final set of tests. Please take some time to download a binary and review it for completeness. The binaries you will be most interested in are: http://people.apache.org/~dblevins/geronimo-1.0/ geronimo-jetty-j2ee-1.0.tar.gz geronimo-jetty-j2ee-1.0.zip geronimo-tomcat-j2ee-1.0.tar.gz geronimo-tomcat-j2ee-1.0.zip The .gz files are for *nix platforms and the .zip binaries are for Windows. There are other files in the distribution for your reviewing pleasure like source and signature files. Please post your votes and comments. Thanks [ ] +1 Release these binaries [ ] -1 Veto the release (provide specific comments) ~ Matt
Re: [Vote] Geronimo V1.0 Release binaries
+1 assuming the binaries pass the TCK On Dec 13, 2005, at 8:30 PM, Matt Hogstrom wrote: We are currently going through the final testing phases and have the binary images available for review. These images represent what we will be making available to users after we confirm the final set of tests. Please take some time to download a binary and review it for completeness. The binaries you will be most interested in are: http://people.apache.org/~dblevins/geronimo-1.0/ geronimo-jetty-j2ee-1.0.tar.gz geronimo-jetty-j2ee-1.0.zip geronimo-tomcat-j2ee-1.0.tar.gz geronimo-tomcat-j2ee-1.0.zip The .gz files are for *nix platforms and the .zip binaries are for Windows. There are other files in the distribution for your reviewing pleasure like source and signature files. Please post your votes and comments. Thanks [ ] +1 Release these binaries [ ] -1 Veto the release (provide specific comments) ~ Matt -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED]
Re: [Vote] Geronimo V1.0 Release binaries
[X] +1 Release these binaries Matt Hogstrom wrote: We are currently going through the final testing phases and have the binary images available for review. These images represent what we will be making available to users after we confirm the final set of tests. Please take some time to download a binary and review it for completeness. The binaries you will be most interested in are: http://people.apache.org/~dblevins/geronimo-1.0/ geronimo-jetty-j2ee-1.0.tar.gz geronimo-jetty-j2ee-1.0.zip geronimo-tomcat-j2ee-1.0.tar.gz geronimo-tomcat-j2ee-1.0.zip The .gz files are for *nix platforms and the .zip binaries are for Windows. There are other files in the distribution for your reviewing pleasure like source and signature files. Please post your votes and comments. Thanks [ ] +1 Release these binaries [ ] -1 Veto the release (provide specific comments) ~ Matt
Re: [Vote] Geronimo V1.0 Release binaries
I assume david is still uploading? they aren't all there... On Dec 13, 2005, at 8:30 PM, Matt Hogstrom wrote: We are currently going through the final testing phases and have the binary images available for review. These images represent what we will be making available to users after we confirm the final set of tests. Please take some time to download a binary and review it for completeness. The binaries you will be most interested in are: http://people.apache.org/~dblevins/geronimo-1.0/ geronimo-jetty-j2ee-1.0.tar.gz geronimo-jetty-j2ee-1.0.zip geronimo-tomcat-j2ee-1.0.tar.gz geronimo-tomcat-j2ee-1.0.zip The .gz files are for *nix platforms and the .zip binaries are for Windows. There are other files in the distribution for your reviewing pleasure like source and signature files. Please post your votes and comments. Thanks [ ] +1 Release these binaries [ ] -1 Veto the release (provide specific comments) ~ Matt -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED]
Re: [Vote] Geronimo V1.0 Release binaries
Uploading again... The connection was reset. On Dec 13, 2005, at 9:29 PM, Geir Magnusson Jr. wrote: I assume david is still uploading? they aren't all there... On Dec 13, 2005, at 8:30 PM, Matt Hogstrom wrote: We are currently going through the final testing phases and have the binary images available for review. These images represent what we will be making available to users after we confirm the final set of tests. Please take some time to download a binary and review it for completeness. The binaries you will be most interested in are: http://people.apache.org/~dblevins/geronimo-1.0/ geronimo-jetty-j2ee-1.0.tar.gz geronimo-jetty-j2ee-1.0.zip geronimo-tomcat-j2ee-1.0.tar.gz geronimo-tomcat-j2ee-1.0.zip The .gz files are for *nix platforms and the .zip binaries are for Windows. There are other files in the distribution for your reviewing pleasure like source and signature files. Please post your votes and comments. Thanks [ ] +1 Release these binaries [ ] -1 Veto the release (provide specific comments) ~ Matt -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED]
[jira] Created: (GERONIMO-1358) Switch database config file looking to geronimo.apache.org
Switch database config file looking to geronimo.apache.org -- Key: GERONIMO-1358 URL: http://issues.apache.org/jira/browse/GERONIMO-1358 Project: Geronimo Type: Bug Components: console, databases Versions: 1.0-M5 Reporter: Aaron Mulder Fix For: 1.1 Currently the database file is looked up at people.apache.org/~ammulder and this ought to go to geronimo.apache.org instead. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [Vote] Geronimo V1.0 Release binaries
Files uploaded! Here is my +1 baring any tck failures. -David On Dec 13, 2005, at 8:30 PM, Matt Hogstrom wrote: We are currently going through the final testing phases and have the binary images available for review. These images represent what we will be making available to users after we confirm the final set of tests. Please take some time to download a binary and review it for completeness. The binaries you will be most interested in are: http://people.apache.org/~dblevins/geronimo-1.0/ geronimo-jetty-j2ee-1.0.tar.gz geronimo-jetty-j2ee-1.0.zip geronimo-tomcat-j2ee-1.0.tar.gz geronimo-tomcat-j2ee-1.0.zip The .gz files are for *nix platforms and the .zip binaries are for Windows. There are other files in the distribution for your reviewing pleasure like source and signature files. Please post your votes and comments. Thanks [ ] +1 Release these binaries [ ] -1 Veto the release (provide specific comments) ~ Matt
RE: [Vote] Geronimo V1.0 Release binaries
---BeginMessage--- David, Are the contents of .zip and .tar different? i see the unix startup commands are there in .zip akshay From: David Blevins [mailto:[EMAIL PROTECTED] Sent: Wed 12/14/2005 11:05 AM To: dev@geronimo.apache.org Subject: Re: [Vote] Geronimo V1.0 Release binaries Uploading again... The connection was reset. On Dec 13, 2005, at 9:29 PM, Geir Magnusson Jr. wrote: I assume david is still uploading? they aren't all there... On Dec 13, 2005, at 8:30 PM, Matt Hogstrom wrote: We are currently going through the final testing phases and have the binary images available for review. These images represent what we will be making available to users after we confirm the final set of tests. Please take some time to download a binary and review it for completeness. The binaries you will be most interested in are: http://people.apache.org/~dblevins/geronimo-1.0/ geronimo-jetty-j2ee-1.0.tar.gz geronimo-jetty-j2ee-1.0.zip geronimo-tomcat-j2ee-1.0.tar.gz geronimo-tomcat-j2ee-1.0.zip The .gz files are for *nix platforms and the .zip binaries are for Windows. There are other files in the distribution for your reviewing pleasure like source and signature files. Please post your votes and comments. Thanks [ ] +1 Release these binaries [ ] -1 Veto the release (provide specific comments) ~ Matt -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED] winmail.dat---End Message--- This e-mail and any files transmitted with it are for the sole use of the intended recipient(s) and may contain confidential and privileged information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. Any unauthorized review, use, disclosure, dissemination, forwarding, printing or copying of this email or any action taken in reliance on this e-mail is strictly prohibited and may be unlawful. Visit us at http://www.cognizant.com
Re: [Vote] Geronimo V1.0 Release binaries
Not gonna do a RCn series first? --jason On Dec 13, 2005, at 8:30 PM, Matt Hogstrom wrote: We are currently going through the final testing phases and have the binary images available for review. These images represent what we will be making available to users after we confirm the final set of tests. Please take some time to download a binary and review it for completeness. The binaries you will be most interested in are: http://people.apache.org/~dblevins/geronimo-1.0/ geronimo-jetty-j2ee-1.0.tar.gz geronimo-jetty-j2ee-1.0.zip geronimo-tomcat-j2ee-1.0.tar.gz geronimo-tomcat-j2ee-1.0.zip The .gz files are for *nix platforms and the .zip binaries are for Windows. There are other files in the distribution for your reviewing pleasure like source and signature files. Please post your votes and comments. Thanks [ ] +1 Release these binaries [ ] -1 Veto the release (provide specific comments) ~ Matt
Re: Fwd: OpenEJB Question
Hi Gianny, I get it.But the problem is if I put this jar in the repo of my existing Geronimo Instance it fails to start due to de-serialisation problems. org.apache.geronimo.kernel.config.InvalidConfigException: Could not extract gbean data from configuation at org.apache.geronimo.kernel.config.ConfigurationManagerImpl.loadGBeans(ConfigurationManag rImpl.java:130) at org.apache.geronimo.kernel.config.ConfigurationManagerImpl$$FastClassByCGLIB$$fbed85d2.i voke(generated) I guess this is because I have apps deployed in the server which have EJBs and the EJB class in TranQL has changed. So to replace this I need to install geronimo again and deploy all the applications and data sources :-(. So I might as well build a later version from source. If there is a way to resolve this other than by uninstalling all apps please let me know. Thanks ManuOn 12/14/05, Gianny Damour [EMAIL PROTECTED] wrote: Hi Manu,This was a simple TranQL fix. So, you simply need to build TranQL anddrop it in your repo (you do not need a full rebuild of Geronimo).Thanks,GiannyManu George wrote: Hi Gianny Great to know its fixed. Will try it out after building geronimo from source. Thanks Manu On 12/13/05, *Gianny Damour* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Hi Manu, Thanks for your debugging! This was a bug in IdentityDefinerBuilder, which was wrongly trying to identify a compound PK based on the number of primary key fields. This is now fixed. I will create a JIRA to track this issue tomorrow as it seems that JIRA is down tonight. Thanks, Gianny Manu George wrote: Hi Gianny, I have done all that you mentioned. I am still getting the error.I have replicated the issue in a simple EJB,the example CMP in Ed Roman's book Mastering EJB. I am attaching the stack trace and the plans below 17:02:05,211 WARN[SystemExceptionInterceptor] Product snip While i was debugging I saw a method public IdentityTransform getPrimaryKeyTransform(Entity entity) in the class IdentityDefinerBuilder. Here based on size of pkFields the SimplePKTransform or CompoundPKTransform class is selected. In the case of a custom class with 1 field also the SimplePKTransform is selected. Is this how it should behave? Could you give a general idea of how the primary key values are taken from the Custom classes in OpenEJB? Thanks Manu
Re: [Vote] Geronimo V1.0 Release binaries
I'm sorry to say, but -1: the console has a dangling SNAPSHOT that means that no database pools can be deployed from the database pool portlet. I put all the blame on the guy who did the SNAPSHOT cleanup in the branch, who was, umm, me. :) I checked the fix in to the 1.0 branch. Aaron On 12/14/05, Jason Dillon [EMAIL PROTECTED] wrote: Not gonna do a RCn series first? --jason On Dec 13, 2005, at 8:30 PM, Matt Hogstrom wrote: We are currently going through the final testing phases and have the binary images available for review. These images represent what we will be making available to users after we confirm the final set of tests. Please take some time to download a binary and review it for completeness. The binaries you will be most interested in are: http://people.apache.org/~dblevins/geronimo-1.0/ geronimo-jetty-j2ee-1.0.tar.gz geronimo-jetty-j2ee-1.0.zip geronimo-tomcat-j2ee-1.0.tar.gz geronimo-tomcat-j2ee-1.0.zip The .gz files are for *nix platforms and the .zip binaries are for Windows. There are other files in the distribution for your reviewing pleasure like source and signature files. Please post your votes and comments. Thanks [ ] +1 Release these binaries [ ] -1 Veto the release (provide specific comments) ~ Matt
Re: building from 1.0 tag
That happens on the continuum build machines, but so far not on my machine. It's kind of not so bad since we aren't distributing the installer yet. But I'm not sure why it's happening, and it would sure be nice to figure it out and fix it. Aaron On 12/14/05, Christopher Chan [EMAIL PROTECTED] wrote: Has anyone experienced this in building from the 1.0 tag? [java] com.izforge.izpack.compiler.CompilerException: /home/cchan/OpenSource/geronimo/1.0tag/assemblies/j2ee-installer/target/geronimo-1.0/geronimo-izpack.xml:23: Resource not found: /home/cchan/OpenSource/geronimo/1.0tag/assemblies/j2ee-installer/target/geronimo-1.0/RELEASE-NOTES-1.0-M5.txt [java] at com.izforge.izpack.compiler.CompilerConfig.parseError(CompilerConfig.java:1518) [java] at com.izforge.izpack.compiler.CompilerConfig.findProjectResource(CompilerConfig.java:1447) [java] at com.izforge.izpack.compiler.CompilerConfig.addResources(CompilerConfig.java:1044) [java] at com.izforge.izpack.compiler.CompilerConfig.executeCompiler(CompilerConfig.java:313) [java] at com.izforge.izpack.compiler.CompilerConfig.main(CompilerConfig.java:1847) [java] at com.izforge.izpack.compiler.Compiler.main(Compiler.java:620) [java] [java] (tip : use -? to get the commmand line parameters) [java] [ERROR] Java Result: 1
Re: [Vote] Geronimo V1.0 Release binaries
Hi guys, unfortunately: -1 (non binding) Reason: The tarballs for source and bin are corrupt. They includes files with a missing last character in their name. I checked md5 of the downloads (OK). The zip seems OK. Some differences between the archives might be intentionally, but obviously not all. Furthermore: there are considerably more files in the src tarball, than in the zip: Concerning the bin archives: geronimo-1.0/config-store/24/geronimo-console-standard-1.0.war/WEB-INF/lib/jasper-runtime-5.5.12.ja geronimo-1.0/config-store/24/geronimo-console-standard-1.0.war/WEB-INF/lib/jasper-runtime-5.5.12.jar The file geronimo-tomcat-j2ee-1.0.zip is contained only in the zip archive. All other differences in the bin are concerning jsps. In geronimo-1.0/config-store/24/geronimo-console-framework-1.0.war/WEB-INF/: aggregation/PageFragment.js aggregation/PageFragment.jsp aggregation/RootFragment.js aggregation/RootFragment.jsp In geronimo-1.0/config-store/24/geronimo-console-standard-1.0.war/WEB-INF/: view/configmanager/deploy.js view/configmanager/deploy.jsp view/configmanager/normal.js view/configmanager/normal.jsp view/dbwizard/basicParams.js view/dbwizard/basicParams.jsp view/derbylogmanager/help.js view/derbylogmanager/view.js view/derbylogmanager/help.jsp view/derbylogmanager/view.jsp view/realmwizard/advanced.js view/realmwizard/advanced.jsp view/realmwizard/showPlan.js view/realmwizard/showPlan.jsp view/servermanager/normal.js view/servermanager/normal.jsp view/webmanager/maximized.js view/webmanager/maximized.jsp Concerning the src archives (much more differences), there is only one file, that is in both, the tarball and the zip. All other files and dirs are only contained in one of them: - geronimo-1.0/applications/* only contained in tar - geronimo-1.0/assemblies/* only contained in tar - geronimo-1.0/bin/* only contained in zip - geronimo-1.0/configs/* only contained in tar - geronimo-1.0/config-store/* only contained in zip - geronimo-1.0/docs/* only contained in tar - geronimo-1.0/modules/* only contained in tar - geronimo-1.0/plugins/* only contained in tar - geronimo-1.0/sandbox/* only contained in tar - geronimo-1.0/lib/* only contained in zip - geronimo-1.0/repository/* only contained in zip - geronimo-1.0/schema/* only contained in zip - geronimo-1.0/var/* only contained in zip - geronimo-1.0/xdocs/* only contained in zip and some individual files: geronimo-1.0/BUILDING.txt geronimo-1.0/COPYRIGHT geronimo-1.0/LICENSE.txt geronimo-1.0/NOTICE.txt geronimo-1.0/PROPOSAL.txt geronimo-1.0/README.txt geronimo-1.0/META-INF/ geronimo-1.0/META-INF/MANIFEST.MF geronimo-1.0/STATUS geronimo-1.0/docs_nopublish/ geronimo-1.0/docs_nopublish/JBoss_20031031.html geronimo-1.0/etc/ geronimo-1.0/etc/geronimo_checks.xml geronimo-1.0/etc/maven.xml geronimo-1.0/etc/project.properties geronimo-1.0/etc/project.xml geronimo-1.0/maven.xml geronimo-1.0/pom.xml geronimo-1.0/project.properties geronimo-1.0/project.xml geronimo-1.0/deploy/ geronimo-tomcat-j2ee-1.0.zip Hopefully only a packaging issue. Rainer
