Return-Path: Delivered-To: apmail-geronimo-user-archive@www.apache.org Received: (qmail 80805 invoked from network); 29 Jan 2007 16:00:15 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 29 Jan 2007 16:00:15 -0000 Received: (qmail 95114 invoked by uid 500); 29 Jan 2007 16:00:16 -0000 Delivered-To: apmail-geronimo-user-archive@geronimo.apache.org Received: (qmail 95070 invoked by uid 500); 29 Jan 2007 16:00:16 -0000 Mailing-List: contact user-help@geronimo.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: List-Post: Reply-To: user@geronimo.apache.org List-Id: Delivered-To: mailing list user@geronimo.apache.org Received: (qmail 95038 invoked by uid 99); 29 Jan 2007 16:00:16 -0000 Received: from herse.apache.org (HELO herse.apache.org) (140.211.11.133) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 29 Jan 2007 08:00:16 -0800 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (herse.apache.org: domain of rickmcg@gmail.com designates 64.233.184.234 as permitted sender) Received: from [64.233.184.234] (HELO wr-out-0506.google.com) (64.233.184.234) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 29 Jan 2007 08:00:06 -0800 Received: by wr-out-0506.google.com with SMTP id i31so940702wra for ; Mon, 29 Jan 2007 07:59:45 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:reply-to:user-agent:mime-version:to:subject:references:in-reply-to:content-type:content-transfer-encoding; b=K1oeGIRTGxgFV103N3KWuLoglbJfZ/6F9hxnFfiA9zJq+acNFfEf4EkZo5CYCD9v7fQ0Z1RmUes+HdqEELSXogOrORr+qralMkBLehbnaefAjFk4ak2d6Oy/512dznZBY29aSDgRaWHEIivCrqEXagyN2N0n31cAl46d8ArAErE= Received: by 10.90.79.6 with SMTP id c6mr6807595agb.1170086385178; Mon, 29 Jan 2007 07:59:45 -0800 (PST) Received: from ?192.168.1.101? ( [68.191.49.248]) by mx.google.com with ESMTP id 3sm12378476wrh.2007.01.29.07.59.42; Mon, 29 Jan 2007 07:59:43 -0800 (PST) Message-ID: <45BE19F8.1010804@gmail.com> Date: Mon, 29 Jan 2007 10:59:52 -0500 From: Rick McGuire Reply-To: rickmcg@gmail.com User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: user@geronimo.apache.org Subject: Re: geronimo mail 1.1.1 References: <8563115.post@talk.nabble.com> <5F2F6B01-72B1-42AB-BF8A-E1F8D732A3FA@yahoo.com> <8624375.post@talk.nabble.com> <45B8CB0D.9030901@gmail.com> <8639304.post@talk.nabble.com> <45B905AE.5030600@gmail.com> <8641662.post@talk.nabble.com> <45B9318E.2040109@gmail.com> <8689856.post@talk.nabble.com> <45BE0943.2060200@gmail.com> <8691039.post@talk.nabble.com> In-Reply-To: <8691039.post@talk.nabble.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org 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 >>> >>> <> 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) <> >>> >>> >>> >>> >>> >>> 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 >>>> >>>> >>>>> >>>>> >>>>> >>>> xmlns:dep="http://geronimo.apache.org/xml/ns/deployment-1.1"> >>>>> >>>>> geronimo >>>>> javamail-server >>>>> >>>>> >>>>> >>>>> >>>>> geronimo >>>>> geronimo-mail >>>>> 1.1.1 >>>>> jar >>>>> classes >>>>> >>>>> >>>>> geronimo >>>>> geronimo-javamail-transport >>>>> 1.1.1 >>>>> jar >>>>> classes >>>>> >>>>> >>>>> geronimo >>>>> rmi-naming >>>>> 1.1.1 >>>>> car >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> 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.... >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> MailSession >>>>>>>>>> javax.mail.Session >>>>>>>>>> Container >>>>>>>>>> Shareable >>>>>>>>>> >>>>>>>>>> mail/MailSession >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> 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: >>>>>>>>>> >>>>>>>>>> MailSession >>>>>>>>>> mail/MailSession >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> 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: >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> xmlns:dep="http://geronimo.apache.org/xml/ns/deployment-1.1"> >>>>>>>>>>> >>>>>>>>>>> geronimo >>>>>>>>>>> javamail-server >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> geronimo >>>>>>>>>>> geronimo-mail >>>>>>>>>>> 1.1.1 >>>>>>>>>>> jar >>>>>>>>>>> classes >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> geronimo >>>>>>>>>>> >>>>>>>>>>> geronimo-javamail-transport >>>>>>>>>>> 1.1.1 >>>>>>>>>>> jar >>>>>>>>>>> classes >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> geronimo >>>>>>>>>>> rmi-naming >>>>>>>>>>> car >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> class="org.apache.geronimo.mail.SMTPTransportGBean"> >>>>>>>>>>> our smtp remote host >>>>>>>>>>> 25 >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> class="org.apache.geronimo.mail.MailGBean"> >>>>>>>>>>> smtp >>>>>>>>>>> true >>>>>>>>>>> >>>>>>>>>>> SMTPTransport >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> at this point, we need an entry in our geronimo-web.xml and so i >>>>>>>>>>> have added >>>>>>>>>>> this: >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> MailSession >>>>>>>>>>> javax.mail.Session >>>>>>>>>>> Container >>>>>>>>>>> Shareable >>>>>>>>>>> >>>>>>>>>>> mail/MailSession >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> 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() >>>>>>>>>>> >>>>>>>>>>> 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() >>>>>>>>>>> >>>>>>>>>>> at >>>>>>>>>>> org.apache.geronimo.j2ee.deployment.SwitchingModuleBuilder.createModul >>>>>>>>>>> e(SwitchingModuleBuilder.java:94) >>>>>>>>>>> >>>>>>>>>>> at >>>>>>>>>>> org.apache.geronimo.j2ee.deployment.SwitchingModuleBuilder$ >>>>>>>>>>> $FastClassByCGLIB$$d0c31844.invoke() >>>>>>>>>>> >>>>>>>>>>> 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() >>>>>>>>>>> >>>>>>>>>>> at >>>>>>>>>>> org.apache.geronimo.j2ee.deployment.EARConfigBuilder.getDeploymentPlan >>>>>>>>>>> (EARConfigBuilder.java:275) >>>>>>>>>>> >>>>>>>>>>> at >>>>>>>>>>> org.apache.geronimo.j2ee.deployment.EARConfigBuilder$ >>>>>>>>>>> $FastClassByCGLIB$$38e56ec6.invoke() >>>>>>>>>>> >>>>>>>>>>> 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() >>>>>>>>>>> >>>>>>>>>>> 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() >>>>>>>>>>> >>>>>>>>>>> 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: >>>>>>>>>> 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. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>>> >>>> >>>> >>> >>> >> >> > >