geronimo-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rick McGuire <rick...@gmail.com>
Subject Re: geronimo mail 1.1.1
Date Tue, 30 Jan 2007 15:05:51 GMT
Michael C. wrote:
> We have been using the debug attribute.  This is all we get: (I omitted the
> errors since those are in an earlier thread i sent)  
>   
Uh, where?  I don't see a stack traceback for an authentication 
exception in any of your earlier emails.

> Loading javamail.default.providers from jar:file:/our
> path/lib/geronimo-javamail-transport.jar!/META-INF/javamail.default.providers
>
> DEBUG: loading new provider protocol=smtp,
> className=org.apache.geronimo.javamail.transport.smtp.SMTPTransport,
> vendor=Apache Software Foundation, version=1.0
>   
Hmmmm, this isn't correct.  The 1.1.1 version of the SMTPTransport 
should be showing a 1.1 version number.  I just went back to the source 
to verify.  Somehow, you're picking up the 1.0 version of the 
javamail-transport code.  The 1.1.1 version is a significant update over 
the 1.0 version.  In particular, it has much better debug support.

Rick


> DEBUG: getProvider() returning provider protocol=smtp;
> type=javax.mail.Provider$Type@29f7c;
> class=org.apache.geronimo.javamail.transport.smtp.SMTPTransport;
> vendor=Apache Software Foundation;version=1.0
>
> When we run this in WebSphere however, we get this debug information:
>
> [1/29/07 15:39:32:677 EST] 000009a4 SystemOut     O DEBUG: setDebug:
> JavaMail version 1.3.1
> [1/29/07 15:39:32:693 EST] 000009a4 SystemOut     O DEBUG: getProvider()
> returning
> javax.mail.Provider[TRANSPORT,smtp,com.sun.mail.smtp.SMTPTransport,Sun
> Microsystems, Inc]
> [1/29/07 15:39:32:739 EST] 000009a4 SystemOut     O DEBUG SMTP: useEhlo
> true, useAuth false
> [1/29/07 15:39:32:739 EST] 000009a4 SystemOut     O DEBUG SMTP: trying to
> connect to host "our.host.com", port 25
> [1/29/07 15:39:32:833 EST] 000009a4 SystemOut     O 220 our web server
> Microsoft ESMTP MAIL Service, Version: 6.0.3790.1830 ready at  Mon, 29 Jan
> 2007 15:39:32 -0500 
> [1/29/07 15:39:32:833 EST] 000009a4 SystemOut     O DEBUG SMTP: connected to
> host "our.mail.host", port: 25
> [1/29/07 15:39:32:833 EST] 000009a4 SystemOut     O EHLO our app server
> [1/29/07 15:39:32:880 EST] 000009a4 SystemOut     O 250-our web server Hello
> [10.155.100.175]
> 250-TURN
> 250-SIZE
> 250-ETRN
> 250-PIPELINING
> 250-DSN
> 250-ENHANCEDSTATUSCODES
> 250-8bitmime
> 250-BINARYMIME
> 250-CHUNKING
> 250-VRFY
> 250-X-EXPS GSSAPI NTLM LOGIN
> 250-X-EXPS=LOGIN
> 250-AUTH GSSAPI NTLM LOGIN
> 250-AUTH=LOGIN
> 250-X-LINK2STATE
> 250-XEXCH50
> 250 OK
> [1/29/07 15:39:32:880 EST] 000009a4 SystemOut     O DEBUG SMTP: Found
> extension "TURN", arg ""
> [1/29/07 15:39:32:880 EST] 000009a4 SystemOut     O DEBUG SMTP: Found
> extension "SIZE", arg ""
> [1/29/07 15:39:32:880 EST] 000009a4 SystemOut     O DEBUG SMTP: Found
> extension "ETRN", arg ""
> [1/29/07 15:39:32:880 EST] 000009a4 SystemOut     O DEBUG SMTP: Found
> extension "PIPELINING", arg ""
> [1/29/07 15:39:32:880 EST] 000009a4 SystemOut     O DEBUG SMTP: Found
> extension "DSN", arg ""
> [1/29/07 15:39:32:880 EST] 000009a4 SystemOut     O DEBUG SMTP: Found
> extension "ENHANCEDSTATUSCODES", arg ""
> [1/29/07 15:39:32:880 EST] 000009a4 SystemOut     O DEBUG SMTP: Found
> extension "8bitmime", arg ""
> [1/29/07 15:39:32:880 EST] 000009a4 SystemOut     O DEBUG SMTP: Found
> extension "BINARYMIME", arg ""
> [1/29/07 15:39:32:880 EST] 000009a4 SystemOut     O DEBUG SMTP: Found
> extension "CHUNKING", arg ""
> [1/29/07 15:39:32:880 EST] 000009a4 SystemOut     O DEBUG SMTP: Found
> extension "VRFY", arg ""
> [1/29/07 15:39:32:880 EST] 000009a4 SystemOut     O DEBUG SMTP: Found
> extension "X-EXPS", arg "GSSAPI NTLM LOGIN"
> [1/29/07 15:39:32:880 EST] 000009a4 SystemOut     O DEBUG SMTP: Found
> extension "X-EXPS=LOGIN", arg ""
> [1/29/07 15:39:32:880 EST] 000009a4 SystemOut     O DEBUG SMTP: Found
> extension "AUTH", arg "GSSAPI NTLM LOGIN"
> [1/29/07 15:39:32:880 EST] 000009a4 SystemOut     O DEBUG SMTP: Found
> extension "AUTH=LOGIN", arg ""
> [1/29/07 15:39:32:880 EST] 000009a4 SystemOut     O DEBUG SMTP: Found
> extension "X-LINK2STATE", arg ""
> [1/29/07 15:39:32:880 EST] 000009a4 SystemOut     O DEBUG SMTP: Found
> extension "XEXCH50", arg ""
> [1/29/07 15:39:32:880 EST] 000009a4 SystemOut     O DEBUG SMTP: Found
> extension "OK", arg ""
> [1/29/07 15:39:32:880 EST] 000009a4 SystemOut     O DEBUG SMTP: use8bit
> false
> [1/29/07 15:39:32:880 EST] 000009a4 SystemOut     O MAIL
> FROM:<some@address.com>
> [1/29/07 15:39:32:927 EST] 000009a4 SystemOut     O 250 2.1.0
> some@address.com....Sender OK
> [1/29/07 15:39:32:927 EST] 000009a4 SystemOut     O RCPT
> TO:<some@address.com>
> [1/29/07 15:39:32:974 EST] 000009a4 SystemOut     O 250 2.1.5
> some@address.com 
> [1/29/07 15:39:32:974 EST] 000009a4 SystemOut     O DEBUG SMTP: Verified
> Addresses
> [1/29/07 15:39:32:974 EST] 000009a4 SystemOut     O DEBUG SMTP:  
> some@address.com
> [1/29/07 15:39:32:974 EST] 000009a4 SystemOut     O DATA
> [1/29/07 15:39:33:021 EST] 000009a4 SystemOut     O 354 Start mail input;
> end with <CRLF>.<CRLF>
> [1/29/07 15:39:33:021 EST] 000009a4 SystemOut     O Message-ID:
> <630203792.1170103172693.JavaMail.SYSTEM@our app server>
> From: some@address.com
> To: some@address.com
> Subject: Payment Confirmation - Subject
> Mime-Version: 1.0
> Content-Type: text/html; charset=us-ascii
> Content-Transfer-Encoding: 7bit
>
>  
>
>
>
>
> Rick McGuire wrote:
>   
>> Michael C. wrote:
>>     
>>> I am working on getting you the exact string for the addRecipient call
>>> between other daily endeavors.  Meanwhile, we changed our code to use the
>>> getInstance() and get the same authentication error.  I reviewed the
>>> geronimo SMTPTransport class to see what is going on and found these
>>> constants:
>>>
>>>     private static final char CR = 13;
>>>     private static final char LF = 10;
>>>     private static final String MAIL_HOST = "mail.host";
>>>     private static final String MAIL_SMTP_LOCALHOST =
>>> "mail.smtp.localhost";
>>>     private static final String MAIL_SMTP_PORT = "mail.smtp.port";	
>>>     private static final int MIN_MILLIS = 60000;
>>>     private static final String DEFAULT_MAIL_HOST = "localhost";
>>>     private static final int DEFAULT_MAIL_SMTP_PORT = 25;
>>>   
>>>       
>> you might want to add to your properties "mail.debug" with a value of 
>> "true".  I guess the only other thing that would help me now is a stack 
>> trace for the authentication error so I can see where this is coming 
>> from.  The SMTPTransport should only attempt to authenticate with the 
>> server if the property "mail.smtp.auth" has been set to true.
>>
>> Rick
>>
>>
>>     
>>> I cross-referenced these tags with our email configuration properties
>>> file
>>> and found that we are using mail.smtp.host which does not exist here.  So
>>> i
>>> added it to our email properties.  The class does default to port 25 so
>>> that
>>> should not be an issue.  We also only need host-name and port to connect
>>> and
>>> these entries are in our properties.  We debugged our app and saw the
>>> mail
>>> Session object does contain the port and host name properties as they are
>>> identified in the constants of the geronimo SMTPTransport class.  We
>>> still
>>> get the authentication error.  Is there any other configuration that we
>>> could be missing?
>>>
>>>  To summarize:
>>>
>>> -We modified our email deployment plan shown below
>>> -we removed our GBEAN references from the earlier 1.0 version
>>> -we removed the mail.jar from our classpath
>>> -we changed our send() method to use getInstance() instead of
>>> getDefaultInstance()
>>> -we validated the host and port number (which is all that is needed) is
>>> in
>>> the mail Session object before sending the email
>>>
>>> Here is our plan we have deployed:
>>>
>>> <?xml version="1.0" encoding="UTF-8"?> 
>>> <module xmlns="http://geronimo.apache.org/xml/ns/deployment-1.1"> 
>>>  <dep:environment 
>>> xmlns:dep="http://geronimo.apache.org/xml/ns/deployment-1.1"> 
>>>    <dep:moduleId> 
>>>      <dep:groupId>geronimo</dep:groupId> 
>>>      <dep:artifactId>javamail-server</dep:artifactId> 
>>>    </dep:moduleId> 
>>>    <dep:dependencies> 
>>>      <dep:dependency> 
>>>        <dep:groupId>geronimo</dep:groupId> 
>>>        <dep:artifactId>geronimo-javamail</dep:artifactId> 
>>>        <dep:version>1.3.1_spec</dep:version> 
>>>        <dep:type>jar</dep:type> 
>>>        <dep:import>classes</dep:import> 
>>>      </dep:dependency> 
>>>      <dep:dependency> 
>>>        <dep:groupId>geronimo</dep:groupId> 
>>>        <dep:artifactId>geronimo-activation</dep:artifactId> 
>>>        <dep:version>1.0.2_spec</dep:version> 
>>>        <dep:type>jar</dep:type> 
>>>        <dep:import>classes</dep:import> 
>>>      </dep:dependency> 
>>>      <dep:dependency> 
>>>        <dep:groupId>geronimo</dep:groupId> 
>>>        <dep:artifactId>geronimo-javamail-transport</dep:artifactId> 
>>>        <dep:version>1.0</dep:version> 
>>>        <dep:type>jar</dep:type> 
>>>        <dep:import>classes</dep:import> 
>>>      </dep:dependency>    
>>>      <dep:dependency> 
>>>        <dep:groupId>geronimo</dep:groupId> 
>>>        <dep:artifactId>geronimo-mail</dep:artifactId> 
>>>        <dep:version>1.1.1</dep:version> 
>>>        <dep:type>jar</dep:type> 
>>>        <dep:import>classes</dep:import> 
>>>      </dep:dependency>     
>>>      <dep:dependency> 
>>>        <dep:groupId>geronimo</dep:groupId> 
>>>        <dep:artifactId>geronimo-management</dep:artifactId> 
>>>        <dep:version>1.1.1</dep:version> 
>>>        <dep:type>jar</dep:type> 
>>>        <dep:import>classes</dep:import> 
>>>      </dep:dependency>            
>>>    </dep:dependencies> 
>>>    <dep:hidden-classes/> 
>>>    <dep:non-overridable-classes/> 
>>>  </dep:environment> 
>>> </module>
>>>
>>>
>>>
>>> Rick McGuire wrote:
>>>   
>>>       
>>>> Well, ok.  You are creating your own mail session, but I really 
>>>> recommend you NOT use getDefaultInstance().  If something else in the 
>>>> JVM has done a getDefaultInstance() call, then you're going to end up 
>>>> with an instance with a different configuration than you expect.  
>>>> getInstance() will return an instance that respects your property
>>>> bundle.
>>>>
>>>> Once you've fixed that, if you're still having the problem, then you 
>>>> need to look at what properties you are passing in when you create the 
>>>> session.  Done the way you are doing now, your host, port, userid, and 
>>>> password should all be defined there, since it appears that the target 
>>>> SMTP server is requiring authentication.
>>>>
>>>> As for the still unresolved problem of the internet address parsing, I'm 
>>>> looking for the exact string that is getting passed into the 
>>>> addRecipient() call.  I really don't care where it comes from, I just 
>>>> want have the exact string so I can write some test cases to make sure 
>>>> that string is getting parsed compatibly with the Sun implementation.
>>>>
>>>> Rick
>>>>
>>>>
>>>> Michael C. wrote:
>>>>     
>>>>         
>>>>> Here is our send logic, a lot of code has been omitted, including error
>>>>> handling...
>>>>>
>>>>> public void send(EmailMessage outboundMsg) {
>>>>>
>>>>> 		String workString;
>>>>> 		MimeMessage message;
>>>>>
>>>>> 		Properties systemProp =
>>>>> SystemImpl.getInstance().getApplicationProperties("System_Defaults");
>>>>>
>>>>> 		workString = systemProp.getProperty("mail.smtp.host");
>>>>>
>>>>> 		Session session = Session.getDefaultInstance(systemProp, null);
>>>>>
>>>>> 		
>>>>> 		try {
>>>>> 			message = new MimeMessage(session);
>>>>> 				
>>>>> 			if( !outboundMsg.isBccEmpty() ) {
>>>>> 				message.addRecipient(Message.RecipientType.BCC, new
>>>>> InternetAddress(outboundMsg.getBcc().trim()));
>>>>> 			}
>>>>>
>>>>> 			if( !outboundMsg.isCcEmpty() ) {
>>>>> 				message.addRecipient(Message.RecipientType.CC, new
>>>>> InternetAddress(outboundMsg.getCc().trim()));
>>>>> 			}
>>>>>
>>>>> 	message.setFrom(new InternetAddress(outboundMsg.getFrom().trim()));
>>>>> 			
>>>>> 				
>>>>> // ***NOTE: Geronimo 1.0 has an incomplete implementation for JavaMail.
>>>>> There is no implementation for 
>>>>> //"addRecipient". The recommended workaround is to use "SetRecipient".
>>>>> Version 1.1 is supposed to 
>>>>> //address the issue. However, we may be able to continue to use the
>>>>> "setRecipient" going forward.
>>>>> //				
>>>>>
>>>>> message.addRecipient(Message.RecipientType.TO, new
>>>>> InternetAddress(outboundMsg.getTo().trim()));
>>>>> 				message.setRecipient(Message.RecipientType.TO, new
>>>>> InternetAddress(outboundMsg.getTo().trim()));
>>>>> 			}
>>>>> 	message.setSubject(outboundMsg.getSubject());
>>>>>
>>>>> 			//Determine if this message is to be sent as text or html and setup
>>>>> accordingly
>>>>> 			if (outboundMsg.getMimeType().endsWith("plain")) {
>>>>> 				message.setText(outboundMsg.getText());
>>>>> 			}
>>>>> 			else {
>>>>> 		message.setContent(outboundMsg.getText(), outboundMsg.getMimeType());
>>>>> 			}
>>>>>
>>>>> 			Transport.send(message);
>>>>>
>>>>> 		}
>>>>>
>>>>> //end send logic
>>>>>
>>>>> The outboundMsg.getTo() and outboundMsg.getFrom() just return strings
>>>>> for
>>>>> the actual email addresses configured in our properties files or from
>>>>> input
>>>>> fields on pages that vary on an application basis.
>>>>> 			
>>>>>
>>>>> Rick McGuire wrote:
>>>>>   
>>>>>       
>>>>>           
>>>>>> Michael C. wrote:
>>>>>>     
>>>>>>         
>>>>>>             
>>>>>>> We are finally using the SMTPTransport class from Geronimo.  We had a
>>>>>>> mail.jar file on our system path that was being picked up.  At this
>>>>>>> point,
>>>>>>> we are getting an AuthenticationFailedException.  If we do not need a
>>>>>>> GBEAN
>>>>>>> configuration, how do we configure our mail server and port number in
>>>>>>> the
>>>>>>> plan?  Or should we not need to since our application logic is
>>>>>>> reading
>>>>>>> this
>>>>>>> information from an external file and will "tranparently" pass this
>>>>>>> information to the geronimo SMTPTransport class.  
>>>>>>>   
>>>>>>>       
>>>>>>>           
>>>>>>>               
>>>>>> I hate to keep asking the same question over and over again, but I'm 
>>>>>> afraid I have to.  How you configure the transport depends on
>>>>>> how you are creating the mail session within your application.  This 
>>>>>> includes setting up authentication information if your target SMTP 
>>>>>> server requires it.  If you are creating the session by doing:
>>>>>>
>>>>>> Session mySession = Session.getInstance(props);
>>>>>>
>>>>>> Then you are responsible for configuring things like the server and
>>>>>> port 
>>>>>> number in the property bundle you use to create the session.  No GBean 
>>>>>> configuration is necessary,  or even  has any effect if you do happen
>>>>>> to 
>>>>>> specify it.
>>>>>>
>>>>>> If you are using InitialContext.lookup() to get the configured mail 
>>>>>> session GBean, then you DO need to have a configured mail session and 
>>>>>> can set up things like the authentication information on the 
>>>>>> SMTPTransport definition. 
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>     
>>>>>>         
>>>>>>             
>>>>>>> Below is the new error and includes the form of the email address we
>>>>>>> were
>>>>>>> using, which is actually the FROM address, but seems to be treating
>>>>>>> it
>>>>>>> as
>>>>>>> a
>>>>>>> TO address according to the error:
>>>>>>>   
>>>>>>>       
>>>>>>>           
>>>>>>>               
>>>>>> I really would like to see the exact string being set in the API call, 
>>>>>> not the string reported by the error message.  However, an 
>>>>>> authentication failure us different than the error you were reporting 
>>>>>> earlier, and indicates you've not provided correct information for 
>>>>>> accessing the target server.
>>>>>>
>>>>>> Rick
>>>>>>
>>>>>>
>>>>>>     
>>>>>>         
>>>>>>             
>>>>>>> Loading javamail.default.providers from jar:file:/C:/Our Path/Our
>>>>>>> .war/WEB-INF/lib/geronimo-javamail-transport.jar!/META-INF/javamail.default.providers
>>>>>>>
>>>>>>> DEBUG: loading new provider protocol=smtp,
>>>>>>> className=org.apache.geronimo.javamail.transport.smtp.SMTPTransport,
>>>>>>> vendor=Apache Software Foundation, version=1.0
>>>>>>>
>>>>>>> DEBUG: getProvider() returning provider protocol=smtp;
>>>>>>> type=javax.mail.Provider$Type@63b627;
>>>>>>> class=org.apache.geronimo.javamail.transport.smtp.SMTPTransport;
>>>>>>> vendor=Apache Software Foundation;version=1.0
>>>>>>>
>>>>>>> <<Error>> Fri Jan 26 16:28:04 EST 2007 <;>
>>>>>>> Class=framework.services.OutboundEmailMgr <;> ID=2 <;> Message=Could
>>>>>>> not
>>>>>>> send eMail to address mcroft@amica.com <;>
>>>>>>> Thread=Thread[WebApp--TP-Processor3,5,main] <;> Original
>>>>>>> Exception=javax.mail.SendFailedException: Send failure
>>>>>>> (javax.mail.AuthenticationFailedException: null):Send failure
>>>>>>> (javax.mail.AuthenticationFailedException: null) <</Error>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Rick McGuire wrote:
>>>>>>>   
>>>>>>>       
>>>>>>>           
>>>>>>>               
>>>>>>>> Michael C. wrote:
>>>>>>>>     
>>>>>>>>         
>>>>>>>>             
>>>>>>>>                 
>>>>>>>>> We removed all references to the sun mail.jar file in the geronimo
>>>>>>>>> classpath
>>>>>>>>> and i removed the GBEAN references from the geronimo email plan and
>>>>>>>>> left
>>>>>>>>> only the geronimo mail dependency jars.  We undeployed the old plan
>>>>>>>>> and
>>>>>>>>> redeployed the new and ran the application.  We recieved an error
>>>>>>>>> that
>>>>>>>>> i
>>>>>>>>> expected.  The app could not find the provider for smtp.  Since our
>>>>>>>>> application references the sun javax.mail SMTP class indirectly via
>>>>>>>>> the
>>>>>>>>> javax.mail.Transport.send(message); call, i am not sure how
>>>>>>>>> internally
>>>>>>>>> geronimo would resolve to use the geronimo SMTPTransport mail
>>>>>>>>> class.  
>>>>>>>>>       
>>>>>>>>>           
>>>>>>>>>               
>>>>>>>>>                   
>>>>>>>> Transport.send() uses the context class loader to identify and load
>>>>>>>> the 
>>>>>>>> list of Transport and Store providers using files contained in the 
>>>>>>>> META-INF directories of the jar files.  Once the classpath is set up 
>>>>>>>> correctly, it's all automatic.  Your original problem was caused by 
>>>>>>>> having both the sun mail.jar in the classpath with the Geronimo mail 
>>>>>>>> jars.  This caused the Sun version to end up overriding the Geronimo 
>>>>>>>> version.  This might actually work, but it appears you might have
>>>>>>>> hit
>>>>>>>> an 
>>>>>>>> incompatibility.  I'm willing to chase that incompatibility, but
>>>>>>>> I'll 
>>>>>>>> need the exact form of the address you used to add the address.
>>>>>>>>
>>>>>>>>
>>>>>>>>     
>>>>>>>>         
>>>>>>>>             
>>>>>>>>                 
>>>>>>>>> But, i
>>>>>>>>> thought somehow the geronimo email plan we deployed would handle
>>>>>>>>> this. 
>>>>>>>>> Here
>>>>>>>>> is the error:
>>>>>>>>>
>>>>>>>>> Thu Jan 25 16:33:49 EST 2007 <;> <;> ID=3 <;> Message=Could not
>>>>>>>>> locate
>>>>>>>>> the
>>>>>>>>> internet provider for someone@somewhere.com<;>
>>>>>>>>> Thread=Thread[AmicaWebApp--TP-Processor3,5,main] <;> Original
>>>>>>>>> Exception=javax.mail.NoSuchProviderException: Unable to locate
>>>>>>>>> provider
>>>>>>>>> for
>>>>>>>>> protocol: smtp:Unable to locate provider for protocol: smtp 
>>>>>>>>>
>>>>>>>>> We cannot change our application logic to use the geronimo
>>>>>>>>> SMTPTransport
>>>>>>>>> class since our production environment is not Geronimo.  Here is
>>>>>>>>> our
>>>>>>>>> application import list:
>>>>>>>>>
>>>>>>>>> import javax.mail.Message;
>>>>>>>>> import javax.mail.MessagingException;
>>>>>>>>> import javax.mail.NoSuchProviderException;
>>>>>>>>> import javax.mail.SendFailedException;
>>>>>>>>> import javax.mail.Session;
>>>>>>>>> import javax.mail.Transport;
>>>>>>>>> import javax.mail.internet.AddressException;
>>>>>>>>> import javax.mail.internet.InternetAddress;
>>>>>>>>> import javax.mail.internet.MimeMessage;
>>>>>>>>>
>>>>>>>>> We cannot change these imports due to the reasons i mentioned
>>>>>>>>> above,
>>>>>>>>> but
>>>>>>>>> since the javax.mail.Transport object uses the
>>>>>>>>> com.sun.mail.smtp.SMTPTransport class, how can we tell it to use
>>>>>>>>> the
>>>>>>>>> geronimo SMTPTransport class?  Should this be handled by our plan
>>>>>>>>> without
>>>>>>>>> having to change our application code?  here is the plan we
>>>>>>>>> deployed:
>>>>>>>>>   
>>>>>>>>>       
>>>>>>>>>           
>>>>>>>>>               
>>>>>>>>>                   
>>>>>>>> You shouldn't have to, this should be getting resolved
>>>>>>>> automatically.  
>>>>>>>> The critical dependencies to make this happen are the javamail spec
>>>>>>>> jar, 
>>>>>>>> the activation jar,  and the javamail transport jar 
>>>>>>>> (geronimo-javamail_1.3.1_spec, geronimo-activation_1.0.2_spec and 
>>>>>>>> geronimo-javamail-transport).  You do not need a dependency on 
>>>>>>>> geronimo-mail and you do not need to configure a mail session GBean 
>>>>>>>> unless your application obtains the mail session by doing a jndi
>>>>>>>> lookup.
>>>>>>>>
>>>>>>>> I have seen a problem where some application environments (e.g, the 
>>>>>>>> Quartz scheduler) were not setting the correct thread context class 
>>>>>>>> loader before calling the application methods.  This resulted in a 
>>>>>>>> failure because the incorrect class loader was getting used to
>>>>>>>> resolve 
>>>>>>>> the javamail transport code.  In this case, it was necessary to set
>>>>>>>> the 
>>>>>>>> context class loader using the load obtained from 
>>>>>>>> "this.getClass().getClassLoader()"
>>>>>>>>
>>>>>>>> .
>>>>>>>> Rick
>>>>>>>>     
>>>>>>>>         
>>>>>>>>             
>>>>>>>>                 
>>>>>>>>> <?xml version="1.0" encoding="UTF-8"?> 
>>>>>>>>> <module xmlns="http://geronimo.apache.org/xml/ns/deployment-1.1"> 
>>>>>>>>>  <dep:environment 
>>>>>>>>> xmlns:dep="http://geronimo.apache.org/xml/ns/deployment-1.1"> 
>>>>>>>>>    <dep:moduleId> 
>>>>>>>>>      <dep:groupId>geronimo</dep:groupId> 
>>>>>>>>>      <dep:artifactId>javamail-server</dep:artifactId> 
>>>>>>>>>    </dep:moduleId> 
>>>>>>>>>
>>>>>>>>>    <dep:dependencies> 
>>>>>>>>>      <dep:dependency> 
>>>>>>>>>        <dep:groupId>geronimo</dep:groupId> 
>>>>>>>>>        <dep:artifactId>geronimo-mail</dep:artifactId> 
>>>>>>>>>        <dep:version>1.1.1</dep:version> 
>>>>>>>>>        <dep:type>jar</dep:type> 
>>>>>>>>>        <dep:import>classes</dep:import> 
>>>>>>>>>      </dep:dependency> 
>>>>>>>>>      <dep:dependency> 
>>>>>>>>>        <dep:groupId>geronimo</dep:groupId> 
>>>>>>>>>        <dep:artifactId>geronimo-javamail-transport</dep:artifactId> 
>>>>>>>>>        <dep:version>1.1.1</dep:version> 
>>>>>>>>>        <dep:type>jar</dep:type> 
>>>>>>>>>        <dep:import>classes</dep:import> 
>>>>>>>>>      </dep:dependency> 
>>>>>>>>>      <dep:dependency> 
>>>>>>>>>        <dep:groupId>geronimo</dep:groupId> 
>>>>>>>>>        <dep:artifactId>rmi-naming</dep:artifactId> 
>>>>>>>>>        <dep:version>1.1.1</dep:version> 
>>>>>>>>>        <dep:type>car</dep:type> 
>>>>>>>>>      </dep:dependency> 
>>>>>>>>>    </dep:dependencies> 
>>>>>>>>>    <dep:hidden-classes/> 
>>>>>>>>>    <dep:non-overridable-classes/> 
>>>>>>>>>  </dep:environment> 
>>>>>>>>> </module>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Rick McGuire wrote:
>>>>>>>>>   
>>>>>>>>>       
>>>>>>>>>           
>>>>>>>>>               
>>>>>>>>>                   
>>>>>>>>>> Michael C. wrote:
>>>>>>>>>>     
>>>>>>>>>>         
>>>>>>>>>>             
>>>>>>>>>>                 
>>>>>>>>>>                     
>>>>>>>>>>> Thank  you for your replies, they are greatly appreciated.  I
>>>>>>>>>>> would
>>>>>>>>>>> like
>>>>>>>>>>> to
>>>>>>>>>>> step back for a moment and be sure i understand the big picture.
>>>>>>>>>>>
>>>>>>>>>>> When our team first changed over from WSAD to MyEclipse and
>>>>>>>>>>> decided
>>>>>>>>>>> to
>>>>>>>>>>> use
>>>>>>>>>>> Geronimo 1.0 as our local app server, we ran into this same email
>>>>>>>>>>> problem. 
>>>>>>>>>>> I found that there were some email bugs in the Geronimo 1.0
>>>>>>>>>>> version,
>>>>>>>>>>> and
>>>>>>>>>>> that you had to use the geronimo-mail.jar and the
>>>>>>>>>>> geronimo-javamail-transport.jar files, and configure geronimo
>>>>>>>>>>> thru
>>>>>>>>>>> a
>>>>>>>>>>> GBEAN
>>>>>>>>>>> to use these jars to fix the email issue.  Maybe already, my
>>>>>>>>>>> understanding
>>>>>>>>>>> was incorrect but this did fix the issue.
>>>>>>>>>>>
>>>>>>>>>>> We just upgraded to geronimo 1.1.1 and re-introduced the same
>>>>>>>>>>> email
>>>>>>>>>>> issue. 
>>>>>>>>>>> I have read where this email issue was fixed with 1.1.1.  But
>>>>>>>>>>> without
>>>>>>>>>>> any
>>>>>>>>>>> changes, we still throw errors.  When i deployed the new email
>>>>>>>>>>> plan(in
>>>>>>>>>>> my
>>>>>>>>>>> earlier threads), we still throw errors.  So i have a couple
>>>>>>>>>>> questions...
>>>>>>>>>>>
>>>>>>>>>>> Since our application code uses the javax.mail.* packages, it
>>>>>>>>>>> would
>>>>>>>>>>> be
>>>>>>>>>>> best
>>>>>>>>>>> to configure geronimo to use these packages for email.  To be
>>>>>>>>>>> honest,
>>>>>>>>>>> if
>>>>>>>>>>> this is fixed with 1.1.1, then why are there still geronimo
>>>>>>>>>>> version
>>>>>>>>>>> email
>>>>>>>>>>> packages in the new install?
>>>>>>>>>>>
>>>>>>>>>>> Our intent would certainly be to use the mail packages from Sun
>>>>>>>>>>> since
>>>>>>>>>>> this
>>>>>>>>>>> is the .jar file used in our app and our WebSphere production
>>>>>>>>>>> server. 
>>>>>>>>>>> Is
>>>>>>>>>>> it
>>>>>>>>>>> an option to configure Geronimo to use this mail.jar file and if
>>>>>>>>>>> so,
>>>>>>>>>>> how
>>>>>>>>>>> do
>>>>>>>>>>> we go about doing it?  
>>>>>>>>>>>   
>>>>>>>>>>>       
>>>>>>>>>>>           
>>>>>>>>>>>               
>>>>>>>>>>>                   
>>>>>>>>>>>                       
>>>>>>>>>> Geronimo comes with its own implementation of the javax.mail.*
>>>>>>>>>> apis
>>>>>>>>>> and 
>>>>>>>>>> it's own transport implementation.  The javax.mail APIs are used
>>>>>>>>>> by 
>>>>>>>>>> other components (e.g., Axis) so they are pretty fundamental to
>>>>>>>>>> Geronimo 
>>>>>>>>>> operations and show up in a lot of dependencies. 
>>>>>>>>>>
>>>>>>>>>> Unfortunately, part of javamail processing is locating and loading
>>>>>>>>>> all 
>>>>>>>>>> transport implementations contained in jars on the classpath.   If
>>>>>>>>>> both 
>>>>>>>>>> the sun jar and the geronimo jars are present, then both sets of 
>>>>>>>>>> transports get loaded and depending on the search order, the
>>>>>>>>>> default 
>>>>>>>>>> transports can end up being the Sun versions.  This appears to be
>>>>>>>>>> what's 
>>>>>>>>>> happening in this case. 
>>>>>>>>>>
>>>>>>>>>> My recommendation is to just use the geronimo jar files, and
>>>>>>>>>> remove
>>>>>>>>>> the 
>>>>>>>>>> Sun versions.  The setup is very similar to the previous release. 
>>>>>>>>>> You 
>>>>>>>>>> only actually need to configure a GBean if you're using a mail 
>>>>>>>>>> resource.  If you're just directly using the mail apis, you only
>>>>>>>>>> need
>>>>>>>>>> to 
>>>>>>>>>> add the jar files to your dependency list.
>>>>>>>>>>
>>>>>>>>>> Rick
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>     
>>>>>>>>>>         
>>>>>>>>>>             
>>>>>>>>>>                 
>>>>>>>>>>                     
>>>>>>>>>>> Rick McGuire wrote:
>>>>>>>>>>>   
>>>>>>>>>>>       
>>>>>>>>>>>           
>>>>>>>>>>>               
>>>>>>>>>>>                   
>>>>>>>>>>>                       
>>>>>>>>>>>> The message about unable to relay for that address is sent back
>>>>>>>>>>>> from
>>>>>>>>>>>> the 
>>>>>>>>>>>> SMTP server.  I'm not sure what it didn't like, but it appears
>>>>>>>>>>>> it 
>>>>>>>>>>>> couldn't figure out where to relay the message. 
>>>>>>>>>>>>
>>>>>>>>>>>> The part I find interesting is the stack trace.  You're using
>>>>>>>>>>>> the
>>>>>>>>>>>> Sun 
>>>>>>>>>>>> javamail transport implementation, not the Geronimo one.  The
>>>>>>>>>>>> API
>>>>>>>>>>>> code 
>>>>>>>>>>>> (javax.mail.* appears to be the Geronimo version).  Is that what
>>>>>>>>>>>> you 
>>>>>>>>>>>> intended?  I know we've never tested that combo, so it's unclear
>>>>>>>>>>>> how 
>>>>>>>>>>>> well that would work.  You might want to check around for a
>>>>>>>>>>>> spurious 
>>>>>>>>>>>> mail.jar file.  Having that in your classpath can potentially
>>>>>>>>>>>> cause
>>>>>>>>>>>> the 
>>>>>>>>>>>> other transports to get registered and override the Geronimo
>>>>>>>>>>>> ones.
>>>>>>>>>>>>
>>>>>>>>>>>> Rick
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Michael C. wrote:
>>>>>>>>>>>>     
>>>>>>>>>>>>         
>>>>>>>>>>>>             
>>>>>>>>>>>>                 
>>>>>>>>>>>>                     
>>>>>>>>>>>>                         
>>>>>>>>>>>>> I tried your approach and that particular error went away but
>>>>>>>>>>>>> now
>>>>>>>>>>>>> i
>>>>>>>>>>>>> believe i
>>>>>>>>>>>>> am back to the root cause of all this effort; our email logic
>>>>>>>>>>>>> is
>>>>>>>>>>>>> throwing
>>>>>>>>>>>>> an
>>>>>>>>>>>>> error on this line in our application:
>>>>>>>>>>>>>
>>>>>>>>>>>>> javax.mail.Transport.send(message);
>>>>>>>>>>>>>
>>>>>>>>>>>>> Message=Could not send eMail to address
>>>>>>>>>>>>> someaddress@somewhere.com
>>>>>>>>>>>>> <;>
>>>>>>>>>>>>> Thread=Thread[AmicaWebApp--TP-Processor3,5,main] <;> Original
>>>>>>>>>>>>> Exception=javax.mail.SendFailedException: Invalid Addresses
>>>>>>>>>>>>> (javax.mail.SendFailedException: 550 5.7.1 Unable to relay for
>>>>>>>>>>>>> someaddress@somewhere.com
>>>>>>>>>>>>>
>>>>>>>>>>>>> ):Invalid Addresses (javax.mail.SendFailedException: 550 5.7.1
>>>>>>>>>>>>> Unable
>>>>>>>>>>>>> to
>>>>>>>>>>>>> relay for someaddress@somewhere.com
>>>>>>>>>>>>>
>>>>>>>>>>>>> Thu Jan 25 09:28:14 EST 2007 <;>  Message=Could not send eMail
>>>>>>>>>>>>> to
>>>>>>>>>>>>> address
>>>>>>>>>>>>> someaddress@somewhere.com<;>
>>>>>>>>>>>>> Thread=Thread[AmicaWebApp--TP-Processor3,5,main] <;> Original
>>>>>>>>>>>>> Exception=javax.mail.SendFailedException: Invalid Addresses
>>>>>>>>>>>>> (javax.mail.SendFailedException: 550 5.7.1 Unable to relay for
>>>>>>>>>>>>> someaddress@somewhere.com
>>>>>>>>>>>>>
>>>>>>>>>>>>> ):Invalid Addresses (javax.mail.SendFailedException: 550 5.7.1
>>>>>>>>>>>>> Unable
>>>>>>>>>>>>> to
>>>>>>>>>>>>> relay for someaddress@somewhere.com
>>>>>>>>>>>>>
>>>>>>>>>>>>> ) :Could not send eMail to address someaddress@somewhere.com
>>>>>>>>>>>>> javax.mail.SendFailedException: Invalid Addresses
>>>>>>>>>>>>> (javax.mail.SendFailedException: 550 5.7.1 Unable to relay for
>>>>>>>>>>>>> someaddress@somewhere.com
>>>>>>>>>>>>>
>>>>>>>>>>>>> )
>>>>>>>>>>>>>       at
>>>>>>>>>>>>> com.sun.mail.smtp.SMTPTransport.rcptTo(SMTPTransport.java:804)
>>>>>>>>>>>>>       at
>>>>>>>>>>>>> com.sun.mail.smtp.SMTPTransport.sendMessage(SMTPTransport.java:320)
>>>>>>>>>>>>>       at javax.mail.Transport.send(Transport.java:93)
>>>>>>>>>>>>>       at javax.mail.Transport.send(Transport.java:46)
>>>>>>>>>>>>>
>>>>>>>>>>>>> Caused by: javax.mail.SendFailedException: 550 5.7.1 Unable to
>>>>>>>>>>>>> relay
>>>>>>>>>>>>> for
>>>>>>>>>>>>> someaddress@somewhere.com
>>>>>>>>>>>>>       at
>>>>>>>>>>>>> com.sun.mail.smtp.SMTPTransport.rcptTo(SMTPTransport.java:672)
>>>>>>>>>>>>>
>>>>>>>>>>>>> I supplemented the real address but we are using a good
>>>>>>>>>>>>> address. 
>>>>>>>>>>>>> This
>>>>>>>>>>>>> error
>>>>>>>>>>>>> only occurs in our local testing using Geronimo but once we
>>>>>>>>>>>>> move
>>>>>>>>>>>>> our
>>>>>>>>>>>>> code
>>>>>>>>>>>>> to
>>>>>>>>>>>>> the next tier where WebSphere is running, everything works
>>>>>>>>>>>>> fine. 
>>>>>>>>>>>>> There
>>>>>>>>>>>>> is a
>>>>>>>>>>>>> configuration issue that i do not understand.
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> djencks wrote:
>>>>>>>>>>>>>   
>>>>>>>>>>>>>       
>>>>>>>>>>>>>           
>>>>>>>>>>>>>               
>>>>>>>>>>>>>                   
>>>>>>>>>>>>>                       
>>>>>>>>>>>>>                           
>>>>>>>>>>>>>> It looks to me as if the error message is fairly clear about
>>>>>>>>>>>>>> the  
>>>>>>>>>>>>>> first think that is wrong with your xml....
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> <resource-ref>
>>>>>>>>>>>>>>             <property>MailSession</property>
>>>>>>>>>>>>>>             <res-type>javax.mail.Session</res-type>
>>>>>>>>>>>>>>             <res-auth>Container</res-auth>
>>>>>>>>>>>>>>             <res-sharing-scope>Shareable</res-sharing-scope>
>>>>>>>>>>>>>>             <pattern>
>>>>>>>>>>>>>>                  <name>mail/MailSession</name>
>>>>>>>>>>>>>>             </pattern>
>>>>>>>>>>>>>>         </resource-ref>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>     
>>>>>>>>>>>>>>         
>>>>>>>>>>>>>>             
>>>>>>>>>>>>>>                 
>>>>>>>>>>>>>>                     
>>>>>>>>>>>>>>                         
>>>>>>>>>>>>>>                             
>>>>>>>>>>>>>>> Caused by: org.apache.xmlbeans.XmlException: Invalid
>>>>>>>>>>>>>>> deployment  
>>>>>>>>>>>>>>> descriptor:
>>>>>>>>>>>>>>> [error: cvc-complex-type.2.4a: Expected element
>>>>>>>>>>>>>>> 'ref-name@http://geronimo.apache.org/xml/ns/naming-1.1'
>>>>>>>>>>>>>>> instead
>>>>>>>>>>>>>>> of
>>>>>>>>>>>>>>> 'property@http://geronimo.apache.org/xml/ns/naming-1.1' here
>>>>>>>>>>>>>>> in  
>>>>>>>>>>>>>>> element
>>>>>>>>>>>>>>> resource-ref@http://geronimo.apache.org/xml/ns/naming-1.1,
>>>>>>>>>>>>>>>       
>>>>>>>>>>>>>>>           
>>>>>>>>>>>>>>>               
>>>>>>>>>>>>>>>                   
>>>>>>>>>>>>>>>                       
>>>>>>>>>>>>>>>                           
>>>>>>>>>>>>>>>                               
>>>>>>>>>>>>>> I think this will work:
>>>>>>>>>>>>>> <resource-ref>
>>>>>>>>>>>>>>             <ref-name>MailSession</ref-name>
>>>>>>>>>>>>>>             <resource-link>mail/MailSession</resource-link>
>>>>>>>>>>>>>>         </resource-ref>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> and I also think that if you name the mail session the same in
>>>>>>>>>>>>>> your  
>>>>>>>>>>>>>> app and your mail-server plan you won't need any entry in the  
>>>>>>>>>>>>>> geronimo-web.xml at all.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> thanks
>>>>>>>>>>>>>> david jencks
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On Jan 24, 2007, at 7:57 AM, Michael C. wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>     
>>>>>>>>>>>>>>         
>>>>>>>>>>>>>>             
>>>>>>>>>>>>>>                 
>>>>>>>>>>>>>>                     
>>>>>>>>>>>>>>                         
>>>>>>>>>>>>>>                             
>>>>>>>>>>>>>>> Our team has just upgraded from geronimo 1.0 to 1.1.1
>>>>>>>>>>>>>>> Previously, to surpress javamail errors, we had to create a
>>>>>>>>>>>>>>> gbean  
>>>>>>>>>>>>>>> and deploy
>>>>>>>>>>>>>>> it, then add a resource-ref entry to our geronimo-web.xml
>>>>>>>>>>>>>>> file
>>>>>>>>>>>>>>> and  
>>>>>>>>>>>>>>> this
>>>>>>>>>>>>>>> worked.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Since our upgrade, we are back to our original javamail
>>>>>>>>>>>>>>> errors. 
>>>>>>>>>>>>>>> I  
>>>>>>>>>>>>>>> found
>>>>>>>>>>>>>>> entries on other postings here and successfully deployed the  
>>>>>>>>>>>>>>> following plan:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> <?xml version="1.0" encoding="UTF-8"?>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> <module
>>>>>>>>>>>>>>> xmlns="http://geronimo.apache.org/xml/ns/deployment-1.1">
>>>>>>>>>>>>>>>  <dep:environment
>>>>>>>>>>>>>>> xmlns:dep="http://geronimo.apache.org/xml/ns/deployment-1.1">
>>>>>>>>>>>>>>>    <dep:moduleId>
>>>>>>>>>>>>>>>      <dep:groupId>geronimo</dep:groupId>
>>>>>>>>>>>>>>>      <dep:artifactId>javamail-server</dep:artifactId>
>>>>>>>>>>>>>>>    </dep:moduleId>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>    <dep:dependencies>
>>>>>>>>>>>>>>>      <dep:dependency>
>>>>>>>>>>>>>>>        <dep:groupId>geronimo</dep:groupId>
>>>>>>>>>>>>>>>        <dep:artifactId>geronimo-mail</dep:artifactId>
>>>>>>>>>>>>>>>        <dep:version>1.1.1</dep:version>
>>>>>>>>>>>>>>>        <dep:type>jar</dep:type>
>>>>>>>>>>>>>>>        <dep:import>classes</dep:import>
>>>>>>>>>>>>>>>      </dep:dependency>
>>>>>>>>>>>>>>>      <dep:dependency>
>>>>>>>>>>>>>>>        <dep:groupId>geronimo</dep:groupId>
>>>>>>>>>>>>>>>       
>>>>>>>>>>>>>>> <dep:artifactId>geronimo-javamail-transport</dep:artifactId>
>>>>>>>>>>>>>>>        <dep:version>1.1.1</dep:version>
>>>>>>>>>>>>>>>        <dep:type>jar</dep:type>
>>>>>>>>>>>>>>>        <dep:import>classes</dep:import>
>>>>>>>>>>>>>>>      </dep:dependency>
>>>>>>>>>>>>>>>      <dep:dependency>
>>>>>>>>>>>>>>>        <dep:groupId>geronimo</dep:groupId>
>>>>>>>>>>>>>>>        <dep:artifactId>rmi-naming</dep:artifactId>
>>>>>>>>>>>>>>>        <dep:type>car</dep:type>
>>>>>>>>>>>>>>>      </dep:dependency>
>>>>>>>>>>>>>>>    </dep:dependencies>
>>>>>>>>>>>>>>>    <dep:hidden-classes/>
>>>>>>>>>>>>>>>    <dep:non-overridable-classes/>
>>>>>>>>>>>>>>>  </dep:environment>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>  <gbean name="SMTPTransport"
>>>>>>>>>>>>>>> class="org.apache.geronimo.mail.SMTPTransportGBean">
>>>>>>>>>>>>>>>    <attribute name="host">our smtp remote host</attribute>
>>>>>>>>>>>>>>>    <attribute name="port">25</attribute>
>>>>>>>>>>>>>>>  </gbean>
>>>>>>>>>>>>>>>  <gbean name="mail/MailSession"  
>>>>>>>>>>>>>>> class="org.apache.geronimo.mail.MailGBean">
>>>>>>>>>>>>>>>    <attribute name="transportProtocol">smtp</attribute>
>>>>>>>>>>>>>>>    <attribute name="debug">true</attribute>
>>>>>>>>>>>>>>>    <reference name="Protocols">
>>>>>>>>>>>>>>>       <name>SMTPTransport</name>
>>>>>>>>>>>>>>>    </reference>
>>>>>>>>>>>>>>>  </gbean>
>>>>>>>>>>>>>>> </module>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> at this point, we need an entry in our geronimo-web.xml and
>>>>>>>>>>>>>>> so
>>>>>>>>>>>>>>> i  
>>>>>>>>>>>>>>> have added
>>>>>>>>>>>>>>> this:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> <resource-ref>
>>>>>>>>>>>>>>>            <property>MailSession</property>
>>>>>>>>>>>>>>>            <res-type>javax.mail.Session</res-type>
>>>>>>>>>>>>>>>            <res-auth>Container</res-auth>
>>>>>>>>>>>>>>>            <res-sharing-scope>Shareable</res-sharing-scope>
>>>>>>>>>>>>>>>            <pattern>
>>>>>>>>>>>>>>>                 <name>mail/MailSession</name>
>>>>>>>>>>>>>>>            </pattern>
>>>>>>>>>>>>>>>        </resource-ref>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> This entry throws the following error:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> 10:16:48,922 ERROR [Hot Deployer] Unable to deploy: xml
>>>>>>>>>>>>>>> problem
>>>>>>>>>>>>>>> for  
>>>>>>>>>>>>>>> web app
>>>>>>>>>>>>>>> .
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> org.apache.geronimo.common.DeploymentException: xml problem
>>>>>>>>>>>>>>> for
>>>>>>>>>>>>>>> web  
>>>>>>>>>>>>>>> app .
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>       at
>>>>>>>>>>>>>>> org.apache.geronimo.tomcat.deployment.TomcatModuleBuilder.getTomcatWeb 
>>>>>>>>>>>>>>> App(TomcatModuleBuilder.java:234)
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>       at
>>>>>>>>>>>>>>> org.apache.geronimo.tomcat.deployment.TomcatModuleBuilder.createModule 
>>>>>>>>>>>>>>> (TomcatModuleBuilder.java:158)
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>       at
>>>>>>>>>>>>>>> org.apache.geronimo.web.deployment.AbstractWebModuleBuilder.createModu 
>>>>>>>>>>>>>>> le(AbstractWebModuleBuilder.java:121)
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>       at
>>>>>>>>>>>>>>> org.apache.geronimo.web.deployment.AbstractWebModuleBuilder$ 
>>>>>>>>>>>>>>> $FastClassByCGLIB$$459e0cc.invoke(<generated>)
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>       at
>>>>>>>>>>>>>>> net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53)
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>       at
>>>>>>>>>>>>>>> org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke 
>>>>>>>>>>>>>>> (FastMethodInvoker.java:38)
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>       at
>>>>>>>>>>>>>>> org.apache.geronimo.gbean.runtime.GBeanOperation.invoke 
>>>>>>>>>>>>>>> (GBeanOperation.java:122)
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>       at
>>>>>>>>>>>>>>> org.apache.geronimo.gbean.runtime.GBeanInstance.invoke 
>>>>>>>>>>>>>>> (GBeanInstance.java:817)
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>       at
>>>>>>>>>>>>>>> org.apache.geronimo.gbean.runtime.RawInvoker.invoke(RawInvoker.java: 
>>>>>>>>>>>>>>> 57)
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>       at
>>>>>>>>>>>>>>> org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke 
>>>>>>>>>>>>>>> (RawOperationInvoker.java:35)
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>       at
>>>>>>>>>>>>>>> org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept 
>>>>>>>>>>>>>>> (ProxyMethodInterceptor.java:96)
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>       at
>>>>>>>>>>>>>>> org.apache.geronimo.j2ee.deployment.ModuleBuilder$$EnhancerByCGLIB$ 
>>>>>>>>>>>>>>> $1f792348.createModule(<generated>)
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>       at
>>>>>>>>>>>>>>> org.apache.geronimo.j2ee.deployment.SwitchingModuleBuilder.createModul 
>>>>>>>>>>>>>>> e(SwitchingModuleBuilder.java:94)
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>       at
>>>>>>>>>>>>>>> org.apache.geronimo.j2ee.deployment.SwitchingModuleBuilder$ 
>>>>>>>>>>>>>>> $FastClassByCGLIB$$d0c31844.invoke(<generated>)
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>       at
>>>>>>>>>>>>>>> net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53)
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>       at
>>>>>>>>>>>>>>> org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke 
>>>>>>>>>>>>>>> (FastMethodInvoker.java:38)
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>       at
>>>>>>>>>>>>>>> org.apache.geronimo.gbean.runtime.GBeanOperation.invoke 
>>>>>>>>>>>>>>> (GBeanOperation.java:122)
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>       at
>>>>>>>>>>>>>>> org.apache.geronimo.gbean.runtime.GBeanInstance.invoke 
>>>>>>>>>>>>>>> (GBeanInstance.java:817)
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>       at
>>>>>>>>>>>>>>> org.apache.geronimo.gbean.runtime.RawInvoker.invoke(RawInvoker.java: 
>>>>>>>>>>>>>>> 57)
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>       at
>>>>>>>>>>>>>>> org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke 
>>>>>>>>>>>>>>> (RawOperationInvoker.java:35)
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>       at
>>>>>>>>>>>>>>> org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept 
>>>>>>>>>>>>>>> (ProxyMethodInterceptor.java:96)
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>       at
>>>>>>>>>>>>>>> org.apache.geronimo.j2ee.deployment.ModuleBuilder$$EnhancerByCGLIB$ 
>>>>>>>>>>>>>>> $1f792348.createModule(<generated>)
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>       at
>>>>>>>>>>>>>>> org.apache.geronimo.j2ee.deployment.EARConfigBuilder.getDeploymentPlan 
>>>>>>>>>>>>>>> (EARConfigBuilder.java:275)
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>       at
>>>>>>>>>>>>>>> org.apache.geronimo.j2ee.deployment.EARConfigBuilder$ 
>>>>>>>>>>>>>>> $FastClassByCGLIB$$38e56ec6.invoke(<generated>)
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>       at
>>>>>>>>>>>>>>> net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53)
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>       at
>>>>>>>>>>>>>>> org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke 
>>>>>>>>>>>>>>> (FastMethodInvoker.java:38)
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>       at
>>>>>>>>>>>>>>> org.apache.geronimo.gbean.runtime.GBeanOperation.invoke 
>>>>>>>>>>>>>>> (GBeanOperation.java:122)
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>       at
>>>>>>>>>>>>>>> org.apache.geronimo.gbean.runtime.GBeanInstance.invoke 
>>>>>>>>>>>>>>> (GBeanInstance.java:817)
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>       at
>>>>>>>>>>>>>>> org.apache.geronimo.gbean.runtime.RawInvoker.invoke(RawInvoker.java: 
>>>>>>>>>>>>>>> 57)
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>       at
>>>>>>>>>>>>>>> org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke 
>>>>>>>>>>>>>>> (RawOperationInvoker.java:35)
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>       at
>>>>>>>>>>>>>>> org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept 
>>>>>>>>>>>>>>> (ProxyMethodInterceptor.java:96)
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>       at
>>>>>>>>>>>>>>> org.apache.geronimo.deployment.ConfigurationBuilder$$EnhancerByCGLIB 
>>>>>>>>>>>>>>> $$2b662bba.getDeploymentPlan(<generated>)
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>       at org.apache.geronimo.deployment.Deployer.deploy 
>>>>>>>>>>>>>>> (Deployer.java:232)
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>       at org.apache.geronimo.deployment.Deployer.deploy 
>>>>>>>>>>>>>>> (Deployer.java:124)
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>       at
>>>>>>>>>>>>>>> org.apache.geronimo.deployment.Deployer$$FastClassByCGLIB$ 
>>>>>>>>>>>>>>> $734a235d.invoke(<generated>)
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>       at
>>>>>>>>>>>>>>> net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53)
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>       at
>>>>>>>>>>>>>>> org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke 
>>>>>>>>>>>>>>> (FastMethodInvoker.java:38)
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>       at
>>>>>>>>>>>>>>> org.apache.geronimo.gbean.runtime.GBeanOperation.invoke 
>>>>>>>>>>>>>>> (GBeanOperation.java:122)
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>       at
>>>>>>>>>>>>>>> org.apache.geronimo.gbean.runtime.GBeanInstance.invoke 
>>>>>>>>>>>>>>> (GBeanInstance.java:852)
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>       at
>>>>>>>>>>>>>>> org.apache.geronimo.kernel.basic.BasicKernel.invoke 
>>>>>>>>>>>>>>> (BasicKernel.java:239)
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>       at
>>>>>>>>>>>>>>> org.apache.geronimo.deployment.plugin.local.AbstractDeployCommand.doDe 
>>>>>>>>>>>>>>> ploy(AbstractDeployCommand.java:106)
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>       at
>>>>>>>>>>>>>>> org.apache.geronimo.deployment.plugin.local.DistributeCommand.run 
>>>>>>>>>>>>>>> (DistributeCommand.java:60)
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>       at java.lang.Thread.run(Thread.java:534)
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Caused by: org.apache.xmlbeans.XmlException: Invalid
>>>>>>>>>>>>>>> deployment  
>>>>>>>>>>>>>>> descriptor:
>>>>>>>>>>>>>>> [error: cvc-complex-type.2.4a: Expected element
>>>>>>>>>>>>>>> 'ref-name@http://geronimo.apache.org/xml/ns/naming-1.1'
>>>>>>>>>>>>>>> instead
>>>>>>>>>>>>>>> of
>>>>>>>>>>>>>>> 'property@http://geronimo.apache.org/xml/ns/naming-1.1' here
>>>>>>>>>>>>>>> in  
>>>>>>>>>>>>>>> element
>>>>>>>>>>>>>>> resource-ref@http://geronimo.apache.org/xml/ns/naming-1.1,
>>>>>>>>>>>>>>> error:
>>>>>>>>>>>>>>> cvc-complex-type.2.4a: Expected element
>>>>>>>>>>>>>>> 'ref-name@http://geronimo.apache.org/xml/ns/naming-1.1'
>>>>>>>>>>>>>>> instead
>>>>>>>>>>>>>>> of
>>>>>>>>>>>>>>> 'res-type@http://geronimo.apache.org/xml/ns/naming-1.1' here
>>>>>>>>>>>>>>> in  
>>>>>>>>>>>>>>> element
>>>>>>>>>>>>>>> resource-ref@http://geronimo.apache.org/xml/ns/naming-1.1,
>>>>>>>>>>>>>>> error:
>>>>>>>>>>>>>>> cvc-complex-type.2.4a: Expected element
>>>>>>>>>>>>>>> 'ref-name@http://geronimo.apache.org/xml/ns/naming-1.1'
>>>>>>>>>>>>>>> instead
>>>>>>>>>>>>>>> of
>>>>>>>>>>>>>>> 'res-auth@http://geronimo.apache.org/xml/ns/naming-1.1' here
>>>>>>>>>>>>>>> in  
>>>>>>>>>>>>>>> element
>>>>>>>>>>>>>>> resource-ref@http://geronimo.apache.org/xml/ns/naming-1.1,
>>>>>>>>>>>>>>> error:
>>>>>>>>>>>>>>> cvc-complex-type.2.4a: Expected element
>>>>>>>>>>>>>>> 'ref-name@http://geronimo.apache.org/xml/ns/naming-1.1'
>>>>>>>>>>>>>>> instead
>>>>>>>>>>>>>>> of
>>>>>>>>>>>>>>> 'res-sharing-scope@http://geronimo.apache.org/xml/ns/naming-1.1'  
>>>>>>>>>>>>>>> here in
>>>>>>>>>>>>>>> element
>>>>>>>>>>>>>>> resource-ref@http://geronimo.apache.org/xml/ns/naming-1.1,  
>>>>>>>>>>>>>>> error:
>>>>>>>>>>>>>>> cvc-complex-type.2.4a: Expected element
>>>>>>>>>>>>>>> 'ref-name@http://geronimo.apache.org/xml/ns/naming-1.1'
>>>>>>>>>>>>>>> instead
>>>>>>>>>>>>>>> of
>>>>>>>>>>>>>>> 'pattern@http://geronimo.apache.org/xml/ns/naming-1.1' here
>>>>>>>>>>>>>>> in
>>>>>>>>>>>>>>> element
>>>>>>>>>>>>>>> resource-ref@http://geronimo.apache.org/xml/ns/naming-1.1,
>>>>>>>>>>>>>>> error:
>>>>>>>>>>>>>>> cvc-complex-type.2.4c: Expected element
>>>>>>>>>>>>>>> 'ref-name@http://geronimo.apache.org/xml/ns/naming-1.1'
>>>>>>>>>>>>>>> before
>>>>>>>>>>>>>>> the  
>>>>>>>>>>>>>>> end of
>>>>>>>>>>>>>>> the content in element
>>>>>>>>>>>>>>> resource-ref@http://geronimo.apache.org/xml/ns/naming-1.1]
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Descriptor: <xml-fragment
>>>>>>>>>>>>>>> xsi:schemaLocation="http://geronimo.apache.org/xml/ns/j2ee/web-1.1
>>>>>>>>>>>>>>> ../../../schemas/geronimo-web-1.1.xsd
>>>>>>>>>>>>>>> http://geronimo.apache.org/xml/ns/naming-1.1     geronimo- 
>>>>>>>>>>>>>>> naming-1.1.xsd
>>>>>>>>>>>>>>> http://geronimo..apache.org/xml/ns/security-1.1
>>>>>>>>>>>>>>> geronimo-security-1.1.xsd http://geronimo.apache.org/xml/ns/ 
>>>>>>>>>>>>>>> deployment-1.1
>>>>>>>>>>>>>>> geronimo-module-1.1.xsd "
>>>>>>>>>>>>>>> xmlns:geronimo="http://geronimo.apache.org/xml/ns/security-1.1"
>>>>>>>>>>>>>>> xmlns:naming="http://geronimo.apache.org/xml/ns/naming-1.1"
>>>>>>>>>>>>>>> xmlns:sys="http://geronimo.apache.org/xml/ns/deployment-1.1"
>>>>>>>>>>>>>>> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
>>>>>>>>>>>>>>> xmlns:tom="http://geronimo.apache.org/xml/ns/j2ee/web/tomcat-1.1">
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Can anyone provide assistance?  Thanks in advance.
>>>>>>>>>>>>>>> -- 
>>>>>>>>>>>>>>> View this message in context: http://www.nabble.com/geronimo- 
>>>>>>>>>>>>>>> mail-1.1.1-tf3081989.html#a8563115
>>>>>>>>>>>>>>> Sent from the Apache Geronimo - Users mailing list archive at  
>>>>>>>>>>>>>>> Nabble.com.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>       
>>>>>>>>>>>>>>>           
>>>>>>>>>>>>>>>               
>>>>>>>>>>>>>>>                   
>>>>>>>>>>>>>>>                       
>>>>>>>>>>>>>>>                           
>>>>>>>>>>>>>>>                               
>>>>>>>>>>>>>>     
>>>>>>>>>>>>>>         
>>>>>>>>>>>>>>             
>>>>>>>>>>>>>>                 
>>>>>>>>>>>>>>                     
>>>>>>>>>>>>>>                         
>>>>>>>>>>>>>>                             
>>>>>>>>>>>>>   
>>>>>>>>>>>>>       
>>>>>>>>>>>>>           
>>>>>>>>>>>>>               
>>>>>>>>>>>>>                   
>>>>>>>>>>>>>                       
>>>>>>>>>>>>>                           
>>>>>>>>>>>>     
>>>>>>>>>>>>         
>>>>>>>>>>>>             
>>>>>>>>>>>>                 
>>>>>>>>>>>>                     
>>>>>>>>>>>>                         
>>>>>>>>>>>   
>>>>>>>>>>>       
>>>>>>>>>>>           
>>>>>>>>>>>               
>>>>>>>>>>>                   
>>>>>>>>>>>                       
>>>>>>>>>>     
>>>>>>>>>>         
>>>>>>>>>>             
>>>>>>>>>>                 
>>>>>>>>>>                     
>>>>>>>>>   
>>>>>>>>>       
>>>>>>>>>           
>>>>>>>>>               
>>>>>>>>>                   
>>>>>>>>     
>>>>>>>>         
>>>>>>>>             
>>>>>>>>                 
>>>>>>>   
>>>>>>>       
>>>>>>>           
>>>>>>>               
>>>>>>     
>>>>>>         
>>>>>>             
>>>>>   
>>>>>       
>>>>>           
>>>>     
>>>>         
>>>   
>>>       
>>
>>     
>
>   


Mime
View raw message