Return-Path: Delivered-To: apmail-incubator-ibatis-user-java-archive@www.apache.org Received: (qmail 45610 invoked from network); 6 Jun 2005 13:26:16 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 6 Jun 2005 13:26:16 -0000 Received: (qmail 46900 invoked by uid 500); 6 Jun 2005 13:26:14 -0000 Delivered-To: apmail-incubator-ibatis-user-java-archive@incubator.apache.org Received: (qmail 46753 invoked by uid 500); 6 Jun 2005 13:26:13 -0000 Mailing-List: contact ibatis-user-java-help@incubator.apache.org; run by ezmlm Precedence: bulk Reply-To: ibatis-user-java@incubator.apache.org List-Help: List-Unsubscribe: List-Post: List-Id: Delivered-To: mailing list ibatis-user-java@incubator.apache.org Received: (qmail 46720 invoked by uid 99); 6 Jun 2005 13:26:12 -0000 X-ASF-Spam-Status: No, hits=0.4 required=10.0 tests=HTML_30_40,HTML_MESSAGE,RCVD_BY_IP,SPF_HELO_PASS,SPF_PASS,SUBJ_ALL_CAPS X-Spam-Check-By: apache.org Received-SPF: pass (hermes.apache.org: domain of clinton.begin@gmail.com designates 64.233.184.203 as permitted sender) Received: from wproxy.gmail.com (HELO wproxy.gmail.com) (64.233.184.203) by apache.org (qpsmtpd/0.28) with ESMTP; Mon, 06 Jun 2005 06:26:10 -0700 Received: by wproxy.gmail.com with SMTP id 69so1189941wra for ; Mon, 06 Jun 2005 06:25:58 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:mime-version:content-type; b=CV7lmDVHBgy6L3UDYvB9EHz78dm6ToMthwXiV/h9O4qoEQ05NEUcPysCx1f4gi7YoWUFTYUX2CD9rvYxYWQbeCl87Hg1BXiJej8BxuAPXn8BxZTxJqopxIYUj8D0JYqbkjVZq58AdaWjC17r/U3DJpw7C/t+JSW6tndHj1QXP2s= Received: by 10.54.30.54 with SMTP id d54mr3144245wrd; Mon, 06 Jun 2005 06:25:58 -0700 (PDT) Received: by 10.54.93.11 with HTTP; Mon, 6 Jun 2005 06:25:57 -0700 (PDT) Message-ID: <16178eb10506060625125e2220@mail.gmail.com> Date: Mon, 6 Jun 2005 07:25:57 -0600 From: Clinton Begin Reply-To: cbegin@ibatis.com To: "ibatis-user-java@incubator.apache.org" , ibatis-dev@incubator.apache.org, ibatis-user-cs@incubator.apache.org, ibatis-ppmc@incubator.apache.org Subject: IBATIS DOMAIN NAME UPDATE - DTD WARNING Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_13712_19766182.1118064357835" X-Virus-Checked: Checked X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N ------=_Part_13712_19766182.1118064357835 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hi everyone, Sorry for the scary subject, I just wanted to make sure everyone wasn't=20 surprised if DTDs stop validating against ibatis.com in= =20 the next 24 hours. I've moved all of the ibatis.com/net/org domain= s=20 to be parked on the new apache domain ibatis.apache.org This means we'll have one nice consolodated website that all of our=20 developers can access. I'll still own the ibatis domains, because=20 unfrotunately I have 3 years woth of email registrations that I need to=20 slowly undo. So in a nutshell, ibatis.com/net/organd=20 ibatis.apache.org will all point to the same web= =20 server and site. So why the scary email? Well, like anything involving computers, sometimes things go wrong. When it= =20 comes to DNS updates and domain parking, there's a 24 hour delay before we= =20 know if something got screwed up. Worse yet, different ISPs and domain=20 servers will refresh at different periods. Since your iBATIS DTDs currently= =20 resolve from ibatis.com , that could be a problem.=20 The DTDs should be resolving from the JAR files by default, so you shouldn'= t=20 need to do anything. Unfortunatley some XML parsers don't use entity=20 resolvers properly. Also, your IDE might want to resolve from the network= =20 too. Good IDEs like IntelliJ IDEA use locally mapped resources for DTD=20 validation.=20 However, if you experience problems, here's what you can do: Option 1) Use ibatis.apache.org Start resolving your DTDs from ibatis.apache.org = .=20 They've been uploaded, but they're not being served yet...we seem to have a= =20 horrible cache or replication delay at apache.org .=20 Eventually they will appear at ibatis.apache.org/dtd/, just like they were at ibatis.com . This requires that= =20 you change each of your XML files from ibatis.com to=20 ibatis.apache.org . This will stop your DTDs from= =20 resolving from the JAR file, so don't do it unless you know you're having= =20 problems. Option 2) Use local filesystem Every iBATIS JAR file comes with the DTDs. You can extract the DTDs and put= =20 them on your local filesystem. This is a lame approach, but some people=20 already do it for performance or other security reasons. This will also sto= p=20 your DTDs from resolving from the JAR file. Option 3) Locally remap ibatis.com to ibatis.apache.org This is your own internal network solution. You can re-route ibatis.comto ibatis.apache.org yourself, temporarily, until= =20 ibatis.com corrects itself. This is an excellent=20 solution for production systems that you don't want to touch, especially if= =20 you have lots of SQL Mapping files. Of course, DTDs are only resolved once= =20 when you build the SQL map instance anyway, but some people have been=20 reloading SQL Maps at runtime, which might be problematic in this case. Our hope is that nothing goes wrong and that the transition is completely= =20 transparent. We apologize for any inconvenience you experience. When is this happening? Now! The domains have been reparked and the changes= =20 will be propogating over the next 24 hours. To be safe, consider the next 4= 8=20 hours as the risk period. Any problems beyond 48 hours will be due to your= =20 ISP or internal network configuration. Thanks for your patience in these exciting times of change.=20 Best regards, Clinton Begin ------=_Part_13712_19766182.1118064357835 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hi everyone,

Sorry for the scary subject, I just wanted to make sure everyone wasn't surprised if DTDs stop validating against iba= tis.com in the next 24 hours.

I've moved all of the ibatis.com/net/org domains to be parked on t= he new apache domain ibatis.apache.org

This means we'll have one nice consolodated website that all of our developers can access.  I'll still own the ibatis domains, because unfrotunately I have 3 years woth of email registrations that I need to slowly undo.  So in a nutshell, = ibatis.com/net/org and ibatis.apache.org will all point t= o the same web server and site.

So why the scary email?

Well, like anything involving computers, sometimes things go wrong.  When it comes to DNS updates and domain parking, there's a 24 hour delay before we know if something got screwed up.  Worse yet, different ISPs and domain servers will refresh at different periods.  Since your iBATIS DTDs currently resolve from ibatis.com, that could be a problem. = ;

The DTDs should be resolving from the JA= R files by default, so you shouldn't need to do anything.  Unfortunatley some XML parsers don't use entity resolvers properly.  Also, your IDE might want to resolve from the network too.  Good IDEs like IntelliJ IDEA use locally mapped resources for DTD validation.

However= , if you experience problems, here's what you can do:<= br>
Option 1) Use ibatis.apache.org

Start resolving your DTDs from ibatis.= apache.org.  They've been uploaded, but they're not being served yet...we seem to have a horrible cache or replication delay at apache.org.=    Eventually they will appear at ibatis.apache.org/= dtd/, just like they were at ibatis.com.  This requires that you = change each of your XML files from ibatis.com to ibatis.apache.org.  This will stop your DTDs from resolving from the JAR file, so = don't do it unless you know you're having problems .

Option 2) Use local filesystem
Every iBATIS JAR file comes with the DTDs.  You can extract the DTDs and put them on your local filesystem.  This is a lame approach, but some people already do it for performance or other security reasons.  This wi= ll also stop your DTDs from resolving from the JAR file.

Option 3) Locally remap ibatis.com to ibatis= .apache.org

This is your own internal network solution.  You can re-route ibatis.com to ibatis.apache.org yourself, temporarily, until ibatis.com corrects itself.  This is an excellent solution for production systems that you don't want to touch, especially if you have lots of SQL Mapping files.  Of course, DTDs are only resolved once when you build the SQL map instance anyway, but some people have been reloading SQL Maps at runtime, which might be problematic in this case.

Our hope is that nothing goes wrong and that the transition is completely transparent.  We apologize for any inconvenience you experience.

When is this happening?  Now!  The domains have been reparked and the changes will be propogating over the next 24 hours.  To be safe, consider the next 48 hours as the risk period.  Any problems beyond 48 hours will be due to your ISP or internal network configuration.


Thanks for your patience in these exciting times of change. 

Best regards,

Clinton Begin


------=_Part_13712_19766182.1118064357835--