Hi Neal,
I have tested this on tomcat 5.5 and also on weblogic 8.1 and don't seem to be able to reproduce the problem. Can you be more specific about the steps? Where are you entering the text, on the edit page? What is the encoding you have specified in JIRA? Can you attach your weblogic.xml file so we can really replicate your environment?
Thanks,
Dylan

I've attached our weblogic.xml file and a sample text that I pasted into an issue on creation (i.e. create/edit description field). Also our system info.

Neal, can you verify that the webwork.properties that you are deploying with contains the following

webwork.multipart.parser=custom
webwork.multipart.parser.class=com.atlassian.jira.web.JiraMultipartRequestWrapper

This tells webwork to utilize the fix we introduced. Could you have redeployed and not updated this file?
Let me know,
Dylan

Neal, let me clarify, you do not need to manually add this to the file, this is in the file we ship with the distribution. But the deployed version of that file should contain those properties. Perhaps your weblogic admins can verify that the deployed version of the file contains those properties.

It certainly looks like I have the right file. I've uploaded the file currently on our system. I still think there's something suspicious about the encoding of the database being ISO646-US.

Hi Neal,
It looks like we can replicate the problem, I was testing the curly quotes and that was fine. I tested the character you encluded in your text file and it does not work, but I have to say we are having a time trying to understand what that character is, it looks like unicode 0092 which is a control character. From the context I would guess it is a varient of an apostrophe. Can you attach the original file with which you generated the character (word I am guessing)?
Thanks,
Dylan

It was from an e-mail using Microsoft Outlook, probably generated by a user who uses Word. Previously, the problems were indeed with text from a MS Word document. The default is to use smart quotes, so this is how it gets in to so many documents.
(Tools / Autocorrect / AutoFormat As You Type /Replace as you type "Straight quotes" with 'smart quotes')
You should be able to create your own test without a document by setting this option on in Word and copying the text from Word into your clipboard.
I attach a simple document and a screenshot of how JIRA interpreted it when I pasted it in from my clipboard.
Some research on this found:
From: http://en.wikipedia.org/wiki/Quotation_mark
Word processors have traditionally offered curved quotes to users, because in printed documents curved quotes are preferred to straight ones. Before Unicode was widely accepted and supported, this meant representing the curved quotes in whatever 8-bit encoding the software and underlying operating system were using — but the character sets for Windows and Macintosh used two different pairs of values for curved quotes, and ISO 8859-1 (typically the default character set for the Unices and Linux) had no curved quotes, making cross-platform compatibility a nightmare.
Compounding the problem is the "smart quotes" feature mentioned above, which some word processors (including Microsoft Word and OpenOffice.org) use by default. With this feature turned on, users may not have realised that the ASCII-compatible straight quotes they were typing on their keyboards ended up as something entirely different.
Unicode support has since become the norm for operating systems. Thus, in at least some cases, transferring content containing curved quotes (or any other non-ASCII characters) from a word processor to another application or platform has sometimes been less troublesome, provided all steps in the process (including the clipboard if applicable) are Unicode-aware. But there are many applications which still use the older character sets, or output data using them, and thus problems still occur.Word tends to use ASCII 146 (curly apostrophe) instead of ASCII 39 (straight apostrophe)."
From: http://pubs.logicalexpressions.com/Pub0009/LPMArticle.asp?ID=248
"For instance, were you aware that Microsoft Word's SmartQuotes really aren't? Did you know that the way Microsoft produces these characters is not compliant with ASCII, ANSI, the Latin-1 unicode set?"

The odd thing is... when I copy those characters into issues on my standalone version or jira.atlassian.com, there is no problem. They get converted correctly.

Here I am pasting the exact same text into j.a.com:

The main problem is that 'smart' quotes are really "dumb" because only MS Word knows about them.

Here's something interesting... and likely relevant.
I changed my personal preference locale to French and all the French characters would no longer render - on every prompt, button, and display. On standalone, it's fine. See Screenshot-fr.

The character in curlyquote.txt is a 'curly apostrophe' in a Microsoft-specific encoding (cp1252). Interestingly, it works when pasted into JIRA from IE, eg. TST-4012, so it's likely the problem is with the database rather than JIRA. I assume this problem doesn't occur with Standalone?

That's right. The same operation in standalone works just fine. And changing locale to French also works fine in standalone. There's something wrong with our database that won't allow any such characters to render correctly.

Hi Neal,
Sorry to being going back and forth so much on this one. I just want to make sure that we are on the same page.

1. If you open curlyquote.txt in Word, it prompts you to do a file conversion, and if you convert to windows and then copy and paste the text into JIRA, it does not get escaped, correct?
2. If you open the smartquotes.doc in Word and copy and paste into JIRA it does not get escaped, correct?
3. In the general configuration section of the admin section you have an entry that looks like this "Character Encoding UTF-8", correct?
4. If you try the first two steps in a standalone then you do get properly escaped text, correct?

What I have seen in the code is that if you are using a JIRA encoding (i.e. the encoding specified in the general configuration) of either "UTF-8", "Big5", or "Windows-1252" then we will try to escape these characters. One thing that could go wrong here is that for efficiencies sake we only build the conversion table the first time around. If you started JIRA with an encoding that was not one of the above and then edited the value in general configuration we do not rebuild the conversion table. Restarting JIRA will fix this. Could it be that your instance of JIRA was started with an encoding that was not UTF-8 and that it was changed and then not restarted?

Please let me know and we will get the bottom of this one eventually, sorry again for the back and forth.

Dylan

1) If you open curlyquote.txt in Word, it prompts you to do a file conversion, and if you convert to windows and then copy and paste the text into JIRA, it does not get escaped, correct?
2) If you open the smartquotes.doc in Word and copy and paste into JIRA it does not get escaped, correct?
There's no file conversion prompt from Word. It's just your standard Word doc. When you paste it into the issue, the quotes appear correctly (i.e. just like single quotes) in the JIRA comment or description. But after it's saved to the database, and the comment/description is re-displayed, it displays as a question mark.
3) In the general configuration section of the admin section you have an entry that looks like this "Character Encoding UTF-8", correct?
Yes
4) If you try the first two steps in a standalone then you do get properly escaped text, correct?
Yes

Could it be that your instance of JIRA was started with an encoding that was not UTF-8 and that it was changed and then not restarted?
No - this problem was evident from the first build, in version 3.2.3. After installing version 3.3.3, the problem persisted and so I re-opened the issue. JIRA has been restarted many times since then.

Also - the fact that French characters do not render when switching to French locale MUST be relevant.

Hi Neal,
I think that the problem you are having with the French locale is a red herring. You are missing the block:

<jsp-descriptor>
              <jsp-param>
                <param-name>encoding</param-name>
                <param-value>UTF-8</param-value>
              </jsp-param>
              <jsp-param>
                <param-name>compilerSupportsEncoding</param-name>
                <param-value>false</param-value>
              </jsp-param>
            </jsp-descriptor>

in your weblogic.xml file. I think that this should allow your instance of weblogic to correctly serve out the unicode characters.

The reason the French thing is not quite related is that we actually replace the curly quotes with normal quotes before the data even gets to the database. Our request filters actually hunt down the instances of those characters and replace them with the ASCII equivilent. So your server displaying the character incorrectly is probably related to the French thing, but the real problem is that the data should not be in the database in the first place. What we need to find out is why your instance of JIRA is allowing the characters through to the database.

To this end, I am attaching two patch files (atlassian-core.jar and JiraMultipartRequestWrapper.class) that will generate a very verbose output. You do not want to put these patches in-place in your production environment. If you can replicate the problem in a test setup and then apply these patches, the output should help us see what is really going on. I would really only like the log snippet from directly after clicking the "Update" button on an edit issue page with the sentence from the smartquotes.doc in the description field. What that should generate is something like this, but alot more of it:

----------------- BEGIN DEBUG ESCAPE CP1252 BUG -----------------
---- In JiraMultipartRequestWrapper about to escape with encoding: 'UTF-8'
---- In JiraMultipartRequestWrapper about to escape: 'The main problem is that 'smart' quotes are really "dumb" because only MS Word knows about them.'
---- In StringUtils examining the 0th character it is 84
---- In StringUtils examining the 1th character it is 104
---- In StringUtils examining the 2th character it is 101
---- In StringUtils examining the 3th character it is 32
---- In StringUtils examining the 4th character it is 109
---- In StringUtils examining the 5th character it is 97
---- In StringUtils examining the 6th character it is 105
---- In StringUtils examining the 7th character it is 110
---- In StringUtils examining the 8th character it is 32
---- In StringUtils examining the 9th character it is 112
---- In StringUtils examining the 10th character it is 114
---- In StringUtils examining the 11th character it is 111
---- In StringUtils examining the 12th character it is 98
---- In StringUtils examining the 13th character it is 108
---- In StringUtils examining the 14th character it is 101
---- In StringUtils examining the 15th character it is 109
---- In StringUtils examining the 16th character it is 32
---- In StringUtils examining the 17th character it is 105
---- In StringUtils examining the 18th character it is 115
---- In StringUtils examining the 19th character it is 32
---- In StringUtils examining the 20th character it is 116
---- In StringUtils examining the 21th character it is 104
---- In StringUtils examining the 22th character it is 97
---- In StringUtils examining the 23th character it is 116
---- In StringUtils examining the 24th character it is 32
---- In StringUtils examining the 25th character it is 8216
---- In StringUtils REPLACING 25th character with: ' !!!!!
---- In StringUtils REPLACING 31th character with: ' !!!!!
---- In StringUtils REPLACING 51th character with: " !!!!!
---- In StringUtils REPLACING 56th character with: " !!!!!
----------------- END DEBUG ESCAPE CP1252 BUG -------------------

I am guessing that on your installation we will not see this output since your smartquotes are not being replaced, but at least we will be able to see exactly what is getting executed.

Thanks for your patience,
Dyaln

I don't currently have a test environment available to me to test out in the Weblogic environment. So it may take a while
to get the I.T. folk to help me out with that. I can, however, gain access to the database directly via MS-SQL if that will help.
In the meantime, I'll see if I can fix our weblogic.xml file as you suggest to get the French characters to correctly display.
I'll send an update...

I made the suggested change to the weblogic.xml but JIRA failed to deploy.
I am attaching the error. I tried 2 different versions of weblogic.xml, one with an extra jsp-descriptor tag and one with just 1 set. Either way, JIRA failed to deploy. When I replaced it with the regular weblogic.xml without those options, it started up normally.

D'oh!
D'OH!
D'OH!
I re-checked my weblogic.xml file and found I somehow lost an open angle bracket in one of the param value tags, so obviosuly, Weblogic is going to barf.
I corrected the typo, and it did indeed launch successfully. So don't bother with my previous post and file attachments. Sorry about that.
Anyway, after the updated weblogic.xml file was in place, it had absolutely no effect on either issue - the smart quotes or the French characters displaying. I still claim I believe the two are related.
I ran a log while inserting the comment, and it showed this:

exec sp_prepexec @P1 output, N'@P1 bigint,@P2 bigint,@P3 nvarchar(4000),@P4 nvarchar(4000),@P5 nvarchar(4000),@P6 nvarchar(4000),@P7 datetime,@P8 decimal(38,0)', N'
INSERT INTO jiraaction (ID, issueid, AUTHOR, actiontype, actionlevel, actionbody, CREATED, actionnum) VALUES (@P1 , @P2 , @P3 , @P4 , @P5 , @P6 , @P7 , @P8 )', 11812, 10810, N'neala', N'comment', NULL, N'test comment:
The main problem is that ?smart? quotes are really ?dumb? because only MS Word knows about them.
', 'Nov  9 2005  5:56:33:383PM
', NULL

I am attaching log.sql which is a (SQL Profiler) log of activity as I navigated JIRA and added the smar/dumb comment. When I load it into Textpad, it tells me:
"WARNING: "log.sql" contains characters that do not exist in code page 1252 (ANSI - Latin I). They will be converted to the system default character, if you click OK."
So I am attaching the actual file itself in case it helps.

Did you also test in-house with Weblogic against MS-SQL db?
properties of jira db are: "Collation name: SQL_Latin1_General_CP1_CI_AS"
although microsoft says " Collations do not control the code page used for Unicode columns"
so how can I tell the code page for my db:
Character Encoding in JIRA: UTF-8

What else can I check for you?

SELECT COLLATIONPROPERTY('SQL_Latin1_General_CP1_CI_AS', 'CodePage')
==>
1252

A developer here thinks our problem is at the operating system level - that our SunOS does not have the necessary character set installed.
Whereas when running on a Windows operating system (e.g. my standalone) it works fine. That would also explain why French locale also fails
to display French accented characters.
I went to the server and ran this:
locale -a
==>
POSIX
C
iso_8859_1
iso_8859_15
en_CA
en_CA.ISO8859-1
en_US
en_US.ISO8859-1
en_US.ISO8859-15
en_US.ISO8859-15@euro
es
es_MX
es_MX.ISO8859-1
fr
fr_CA
fr_CA.ISO8859-1
en

The command
locale
==>
LANG=
LC_CTYPE=en_CA.ISO8859-1
LC_NUMERIC=en_CA.ISO8859-1
LC_TIME=en_CA.ISO8859-1
LC_COLLATE=en_CA.ISO8859-1
LC_MONETARY=en_CA.ISO8859-1
LC_MESSAGES=C
LC_ALL=

Neal,

We are really sorry for the delay on resolving this issue. We are very busy testing JIRA 3.4.1 to ensure that it is compatible with all databases.

As soon as we have JIRA 3.4.1 out the door we will have a much deeper look into this.

Again, I apologise for teh delay.

Anton

OK.
Here's some other links that might be helpful:
http://edocs.beasys.co.jp/e-docs/wls/docs81/en/relnotes_ja.html
http://edocs.beasys.co.jp/e-docs/wls/docs90/en/relnotes_ja.html
http://support.bea.com/application?namespace=askbea&origin=ask_bea_answer.jsp&event=link.view_answer_page_solution&answerpage=solution&page=wls/S-06313.htm
from search query:
http://seeker.bea.com/search?q=cp1252&x=12&y=11&ie=latin1&site=all&output=xml_no_dtd&client=dev2dev&lr=lang_en&proxystylesheet=dev2dev&oe=latin1&restrict=&filter=p&numgm=5&source=d2d

> locale -a
> ...

Can you install the cp1252 locale on the OS to see if that makes a difference?

Just an update... I.T. is currently not able to address my request.

Neal,

The smart quotes should be replaced by JIRA before they are saved to the database. The smart quote characters should be replaced by regular ASCII quote equivalent (single quote or double quote).

The fact that the smart quotes appear in your log.sql file means that JIRA is not replacing them. Would you be able to attach your web.xml file?
The file should be under the WEB-INF subdirectory of the JIRA web application.

If you try to add:
The main problem is that 'smart' quotes are really "dumb" because only MS Word knows about them.

(with smart quotes) in the description field during issue creation (rather than adding a comment) do the quotes appear OK on the View Issue page?

Thanks,
Anton

Anton, I attached that file a few weeks ago (liveweb.xml). And yes - it is a problem immediately. See scrrenshot (smartissue.jpg).

Thanks for the info. Sorry I have missed the liveweb.xml file.

On the following page, Administration -> Global Settings -> General Configuration is 'Character Encoding' set to 'UTF-8' (exactly)? Not UTF8 or utf8, but UTF-8?

May I ask if you have tried using Firefox to add the text an issue comment on your JIRA installation? Does the problem still exist?

Would you be able to execute the following SQL in your database:

select id from propertyentry where property_key = 'webwork.i18n.encoding';

And then:

select *  from propertystring where id = <id>;

where <id> is the id returned from the first SQL query.

What does the second query return?

Thanks,
Anton

I generally use Firefox, so yes - it happens with both browsers.
The character encoding is "UTF-8"
select id from propertyentry where property_key = 'webwork.i18n.encoding' ==> 10011
select * from jira.propertystring where id = 10011 ==> ID:propertyvalue ; 10011:UTF-8
Don't forget I can't even get accented characters to display when I change my locale to French.
It works fine on standalone.

Thanks for the information. Unfortunately we are at a complete loss here.

Let me see if I can describe our situation. We have replicated the problem with French characters on WebLogic 8.1 SP2. Adding:

<jsp-param>
   <param-name>encoding</param-name>
   <param-value>UTF-8</param-value>
</jsp-param>

to weblogic.xml (as indicated by our docs) does not fix the problem, the French characters are still showing up as ?. However, even with the French characters problem we cannot replicate the problem with smart quotes in WebLogic 8.1 SP2.

From a technical perspective the French character problem should not cause the replacement of smart quotes to fail. This is indeed what we are seeing in our environment. I have seen weirder things in the past, however So we will try to solve the French characters issue as well. It needs to be solved in any case.

Regarding the actual smart quotes problem, I am not too sure how we can move forward without another clean test environment. If you could setup a test instance of WebLogic and see if the problem persists that would be great. If the problem still occurs please use the attached test files provided by Dylan. Their output should help us understand the problem better.

This indeed is a tough one. Thanks for bearing with us through this.

Thanks,
Anton

I'll see what I can do about getting my own test installation - perhaps I can get Weblogic running JIRA on my own machine.
Our I.T. department is not really available for any requests right now, so i can't do much with our live installation.
I'll see if I can follow the installation instructions and create my own ms-sql db and local instance of Weblogic.
But, if I understood your note correctly, I am glad to hear you could replicate the problem where French characters did not display when
switching locales in JIRA under Weblogic. Does that mean the o/s is not a factor for that issue? If so, that helps isolate the problem.
When you were able to replicate the problem, was it on a Sun Solaris 9 like us?

> Does that mean the o/s is not a factor for that issue?

Yes, I believe OS does not cause this issue.

> When you were able to replicate the problem, was it on a Sun Solaris 9 like us?

Unfortunately no. We do not have a Sun box handy here so the tests were run on Linux. Without any absolute guarantees, I believe the Operating System should not cause this.

If you could organise a test environment that would be great.

Thanks,
Anton

Please note: My System encoding (as displayed on Admin System Info page) is "ISO646-US". How do I change this?
JRA-5176 did not give enough technical detail to tell me how to change this for Weblogic installation.
Note the weblogic.xml file says:
<jsp-param>
<param-name>encoding</param-name>
<param-value>UTF-8</param-value>
</jsp-param>
What should it be displaying as in JIRA?
config.xml on the server has UTF-8

Neal,

Are you simply trying to change your system encoding to check if it makes the international characters work?

This can be changed by passing teh following property to weblogic:
-Dfile.encoding=UTF-8

The easiest way to do that is to add them to the script that starts weblogic. May I ask why you would like to do this?

FYI, we are currently looking into the problem with displaying i18n characters in weblogic.

Anton

I'm just trying anything I can to resolve the problem. In what file and where would I put that code?
This is becoming an embarrassing problem for me.

Hi Neal,
I think that we solved the french part of this issue. See JRA-8708 for the details and a jar that should get things working for you. Still no progress on the curly quotes yet.

Dylan

Neal,

The file depends on how you launch weblogic. May I ask what do you run to start weblogic?

Thanks,
Anton

1) Dylan, re patch file: But I'm running 3.3.3. Will the .jar work for my installation? I can't upgrade to 3.4.2 that easily (since the last upgrade wasn't too smooth).
2) Anton, re how do I start weblogic? How do I know? I'm the "JIRA guy". Is it perhaps startWebLogic.sh (attached)?
The last line looks like this:

${JAVA_HOME}/bin/java ${JAVA_VM} ${MEM_ARGS} ${JAVA_OPTIONS} -Dweblogic.Name=${SERVER_NAME} -Dweblogic.ProductionModeEnabled=${PRODUCTION_MODE} -Djava.security.policy="${WL_HOME}/server/lib/weblogic.policy" weblogic.Server

My jar file is atlassian-core-2.3.18.jar, so I am assuming the patch on the linked issue won't help me.

Neal,

The jar should work as atlassian-core is backwards compatible. We have tested the atlassian-core-2.4.8.jar in JIRA 3.3.3 in WebLogic and it works. I would strongly recommend backing up the atlassian-core-2.3.18.jar file before removing it in case you need to recover.

startWebLogic.sh is the usual way to start it. If you edit the script to do:

${JAVA_HOME}/bin/java ${JAVA_VM} ${MEM_ARGS} ${JAVA_OPTIONS} -Dweblogic.Name=${SERVER_NAME} -Dweblogic.ProductionModeEnabled=${PRODUCTION_MODE} -Djava.security.policy="${WL_HOME}/server/lib/weblogic.policy" -Dfile.encoding=UTF-8 weblogic.Server

and then restart the setting should be picked up, Please backup the script first and check with your system administrators whether it is OK to modify it. Also please check if they actually do use that script to start WebLogic, and what is the accepted way in the company to stop/start WebLogic.

Cheers,
Anton

I added that option to the appropriate place in my weblogic startup script (it was actually StartManagedWebLogic.sh)
and I also made the changes to use the newer atlassian-core-2.4.3.jar and removed the parameters from the
weblogic.xml, as suggested. When JIRA re-started, its system encoding was now ISO8859-1 instead of ISO646-US.
However, none of these steps solved either problem. French users still see "?" instead of accented characters, and smart quotes
still don't get properly inserted into the database.
So, back to square one again.

I also restored my old weblogic.xml file (with the explicit jsp param setting of utf-8) and restarted JIRA.
No difference.
Does this link shed any light?
http://edocs.beasys.co.jp/e-docs/wls/docs81/en/i18n.html
Or this?
http://jira.opensymphony.com/browse/CACHE-38

Neal,

I am sorry but I am at a complete loss here.

Can you see the French characters in your browser on other websites? For example http://francesoir.quotidiano.net/

Mat I ask if you removed the old atlassian-core jar from the web application before moving the new one in? Did you run 'build.sh clean' and then 'build.sh' to rebuild the JIRA webapp? Was the new webapplicatin redeployed?

I am very hisitant on supplying this information as I know that all these changes will be done in the production environment where it is easy to make a mistake and end up in deep trouble.

We need ta test environment where tests can be made. Otherwise would using the Standalone distribution in production work for you? This way you would have a much easier time setting up test instances of JIRA.

Thanks,
Anton

Can you see the French characters in your browser on other websites? For example http://francesoir.quotidiano.net/
Yes - of course. And in the standalone version on my browser too.
May I ask if you removed the old atlassian-core jar from the web application before moving the new one in?
Yes
Did you run 'build.sh clean' and then 'build.sh' to rebuild the JIRA webapp?
No - I don't know how to do that. I just dropped the new file into the WEB-INF folder.
Was the new webapplication redeployed?
Yes
I am very hisitant on supplying this information as I know that all these changes will be done in the production environment where it is easy to make a mistake and end up in deep trouble.
Yes - and even for redeploying the app I got asked why I had to reboot it. They won't stand for me fooling around on the live server.

We need a test environment where tests can be made.
I know. But my knowledge of Weblogic etc. is still limited
Otherwise would using the Standalone distribution in production work for you?
I don't think so.
This way you would have a much easier time setting up test instances of JIRA.
Well, you said you could reproduce some of the problem in house, right?

>>Did you run 'build.sh clean' and then 'build.sh' to rebuild the JIRA webapp?
> No - I don't know how to do that. I just dropped the new file into the WEB-INF folder.

Where does the JIRA web application live? Do you deploy JIRA as an open war file?

> Well, you said you could reproduce some of the problem in house, right?
The only problem we reproduced is displaying French characters. This should be fixed by the new jar atatched to
JRA-8708. The jar attached to JRA-8708 is atlassian-core-2.4.8.jar

In you earlier comment you have mentioned that:
I also made the changes to use the newer atlassian-core-2.4.3.jar

Do you mean that you deployed 2.4.8?

>>Did you run 'build.sh clean' and then 'build.sh' to rebuild the JIRA webapp?
> No - I don't know how to do that. I just dropped the new file into the WEB-INF folder.
Where does the JIRA web application live? Do you deploy JIRA as an open war file?
I am not sure I understand the questions from a technical standpoint. My basic understanding is that a
war file is like a zip file. I don't know how all that works - this is my first exposure to the concept of a war file.
After initial deployment (where I.T. deployed from a war file according to install instructions),
I simply make updates by stopping jIRA, uploading files to WEB-INF folder and re-starting using the
Weblogic console (to re-deploy).
> Well, you said you could reproduce some of the problem in house, right?
The only problem we reproduced is displaying French characters. This should be fixed by the new jar atatched to
JRA-8708. The jar attached to JRA-8708 is atlassian-core-2.4.8.jar
In your earlier comment you have mentioned that:
I also made the changes to use the newer atlassian-core-2.4.3.jar

Do you mean that you deployed 2.4.8?
Yes - I deployed 2.4.8 by removing the old file and replacing with atlassian-core-2.4.8.jar into web-inf/lib and restarting.

I MAY be able to get JIRA installed on my local Weblogic (running on Windows, not Solaris), if I have time.

> I am not sure I understand the questions from a technical standpoint. My basic understanding is that a
> war file is like a zip file. I don't know how all that works - this is my first exposure to the concept of a war file.
> After initial deployment (where I.T. deployed from a war file according to install instructions),
> I simply make updates by stopping jIRA, uploading files to WEB-INF folder and re-starting using the
> Weblogic console (to re-deploy).

Yes, the WAR file is like a zip file. The question is: how do you place the uploaded files into the WAR (zip) file? Do you use the WebLogic console to update the contents of the WAR (zip) file?
If so, please let me know how to do that using the WebLogic console.

How do you copy the files to the machine where JIRA (WebLogic) is running?

When JIRA Standalone is not used, it would definitely help us if the person managing the JIRA WAR file was more aware about how the WAR application is deployed and can be updated.
Would it be possible to get the IT department to update the JIRA WAR? It seems like you are not getting much help from there side.

> I MAY be able to get JIRA installed on my local Weblogic (running on Windows, not Solaris), if I have time.
I think this would help us.

Thanks,
Anton

I believe we just followed the instructions on how to install from your website. I don't recall exactly how the war file
was built/unzipped, but in any case, once it has been unzipped there is a folder called jira which contains the subfolders
like WEB-INF etc. I use ftp to upload files to the file system and it seems to work (e.g. when I make customizations to Excel
output or filter subscriptions etc. Yes - I am getting little assistance from the deployment side, but I really don't think this
WAR issue is relevant. The files are there - however they got there - and the changes I made DID have some effect, changing
the system encoding from ISO646-US to ISO8859-1. If I can, I'll try to install JIRA locally on my machine running Weblogic and
see what happens.

Thanks for the info.

> changing the system encoding from ISO646-US to ISO8859-1
Just to cofnirm, this change was made to the startup script, rather than the contents of teh WAR file. Is this right?

> If I can, I'll try to install JIRA locally on my machine running Weblogic and
> see what happens.

Please keep us up to date on your progress.

Thanks,
Anton

Right - I added the -DFile option to the startup script that starts Weblogic, which affected what JIRA displayed
as the system encoding.

Well it took me 2 days of learning the ins and outs of Weblogic but I finally got JIRA installed on my local (Windows XP) machine. Here is the Environment:

Java Version 1.4.2_05
Java Vendor BEA Systems, Inc.
JVM Version 1.0
JVM Vendor Sun Microsystems Inc.
JVM Implementation Version ari-38120-20041118-1131-win-ia32
Java Runtime Java(TM) 2 Runtime Environment, Standard Edition
Java VM BEA WebLogic JRockit(TM) 1.4.2_05 JVM R24.4.0-1
System Encoding Cp1252
Operating System Windows XP 5.1
OS Architecture x86
Application Server Container WebLogic Server 8.1 SP4 Mon Nov 29 16:21:29 PST 2004 471647
Database type mssql
Database JNDI address JiraDS

The environment on my live application is:

Java Version 1.4.1_05
Java Vendor Sun Microsystems Inc.
JVM Version 1.0
JVM Vendor Sun Microsystems Inc.
JVM Implementation Version 1.4.1_05-b01
Java Runtime Java(TM) 2 Runtime Environment, Standard Edition
Java VM Java HotSpot(TM) Server VM
System Encoding ISO646-US
Operating System SunOS 5.9
OS Architecture sparc
Application Server Container WebLogic Server 8.1 SP2 Fri Dec 5 15:01:51 PST 2003 316284
Database type mssql
Database JNDI address JiraDS

With this local Weblogic build, French characters did not display.
Driver used is: weblogic.jdbc.sqlserver.SQLServerDriver

I replaced the atlassian-core.jar and redeployed JIRA. That had no effect.
So, I can only guess it might be the driver?

Atlassian recommends using the JTDS driver for MS-SQL so I changed it and rebuilt the WAR file after dropping in the newer core.jar file, and redeployed JIRA.Then I dropped in the 2 files Dylan provided. But I could not re-deploy:
<Connection Pool "MyJDBC Connection Pool" deployment failed with the following error: Cannot load driver class: net.sourceforge.jtds.jdbc.Driver.>

So I changed connection pool back to weblogic.jdbc.sqlserver.SQLServerDriver and was able to re-connect and re-deploy.

I then edited an issue to use the smart quotes, and it re-displayed just fine as regular quotes. Although it still does not display French characters when editing profile preferences.

Anyway, where is the log file with the content Dylan was looking for with the trace ("I would really only like the log snippet"? I searched my whole hard drive for a file called log and couldn't find one.

Then I modified the weblogic.xml file as indicated earlier in this issue to add encoding and compilerSupportsEncoding options, and rebuilt the app and redeployed again.

So, to sum up, I was finally able to get JIRA running on my local machine in a weblogic environment, and the smart quotes went in just fine (as regular quotes), as you would have expected.

So, perhaps it is the server being Solaris (and the way locales are defined) instead of Windows that is the culprit after all?

Well.. I found some more very interesting information.

I ran Microsoft Profiler when adding a comment on my local installation vs. my live installation.

In the case of the local instance, the statement in Profiler looked like this:

exec sp_prepare @P1 output, N'@P1 bigint,@P2 bigint,@P3 nvarchar(4000),@P4 nvarchar(4000),@P5 nvarchar(4000),@P6 nvarchar(4000),@P7 datetime,@P8 decimal(38,0)', N'INSERT INTO jiraaction (ID, issueid, AUTHOR, actiontype, actionlevel, actionbody, CREATED, actionnum) VALUES (@P1 , @P2 , @P3 , @P4 , @P5 , @P6 , @P7 , @P8 )'
select @P1
go
exec sp_execute 1220, 12590, 10549, N'neala', N'comment', NULL, N'The main problem is that ''smart'' quotes are really "dumb" because only MS Word knows about them.', 'Dec 31 2005 1:58:37:823PM', NULL

In the case of the live instance, the statement looked like this:

exec sp_prepexec @P1 output, N'@P1 bigint,@P2 bigint,@P3 nvarchar(4000),@P4 nvarchar(4000),@P5 nvarchar(4000),@P6 nvarchar(4000),@P7 datetime,@P8 decimal(38,0)', N'INSERT INTO jiraaction (ID, issueid, AUTHOR, actiontype, actionlevel, actionbody, CREATED, actionnum) VALUES (@P1 , @P2 , @P3 , @P4 , @P5 , @P6 , @P7 , @P8 )', 12823, 10549, N'neala', N'comment', NULL, N'The main problem is that ''smart'' quotes are really "dumb" because only MS Word knows about them.', 'Dec 31 2005 1:53:17:257PM', NULL

You'll notice that Profiler shows distinctly different results - i.e. one method using sp_prepare and sp_execute, and the other using sp_prepexec. And also, you'll notice that the quotes seem to have already been converted into regular quotes.

Some research found that this diference in syntax is most likely related to the drivers being used:

"One driver is using the 'merged' form of sp_prepare / sp_execute, instead of sp_prepexec (functionality is the same). Although there is no 'public' documentation for sp_prepexec, some people have reported performance problems with it.
If you can configure your driver at all regarding what type of statement to actually issue to the server, try getting it to use sp_executesql"

And, indeed it is the local installation using sp_prepare / sp_execute which is working.

See http://jtds.sourceforge.net/apiCursors.html :
"sp_prepexec: Used to prepare and execute a parameterized SQL statement. This command combines the functions of the sp_prepare and sp_execute procedures and is available from SQL2000 onwards."

Our live installation is using a connection pool with
classname: weblogic.jdbc.sqlserver.SQLServerDriver
URL: jdbc:microsoft:sqlserver://host1:1433
My local installation is also using a connection pool with
classname: weblogic.jdbc.sqlserver.SQLServerDriver
URL: jdbc:bea:sqlserver://host2:1433

So.. I changed my local installation's connection pool to be like our live installation:
==> URL: jdbc:microsoft:sqlserver://host2:1433
(changing config.xml as well, to match). Then I tried to re-deploy JIRA. But I got an error:
[Deployer:149033]preparing application atlassian-jira-3.3.3 on jira
[Deployer:149033]prepared application atlassian-jira-3.3.3 on jira
[Deployer:149033]activating application atlassian-jira-3.3.3 on jira
[Deployer:149033]failed application atlassian-jira-3.3.3 on jira
[Deployer:149034]An exception occurred for task [Deployer:149026]Deploy application atlassian-jira-3.3.3 on jira.:
Exception:weblogic.management.ApplicationException: start() failed.
Module: atlassian-jira-3.3.3 Error: weblogic.management.DeploymentException - with nested exception:
[java.lang.NullPointerException]

At this point I am so confused with the way to configure datasources and Weblogic etc. I can't even get JIRA up anymore.

Neal,

As mentioned previously the database driver should have nothing to do with this. The smart quotes should be replaced by JIRA while processing the user input and before saving it to the database (and hence using the driver).

As JIRA replaces the smart quotes, when you posted the output of the profiler in the comment above the smart quotes got replaced. So I cannot tell the difference in the actual content that is being inserted into the live and local databases.

I am guessing that the profiler showed that on your local system the quotes that are saved to the database are already replaced with regular quotes. While in production the quotes are smart quotes. Is this the case?
If this is the case, I think playing with the actual database drivers will not help, and the fact that the drivers use different methods of inserting the data should not matter.

Can I confirm that the regular quotes work OK in your production system?

The question is, why in the production environment, do the smart quotes not get replaced by JIRA?

As far as I can tell you were not able to replicate the problem in your test (local) environment. The 2 main differences between the environment is the system encoding and the operating system.

Can you try setting the system encoding of your local system to ISO646-US restarting the system and then seeing if this breaks the smart quotes?

If not, is there any way that you can get a Sun box, where a test instance of JIRA can be created?

Thanks.
Anton

OK. It's a new year. And the gremlin gods are being nice to me (for now). I went to replicate the problem this morning
on the live installation to take another look at what's actually being stored in the database since the Profiler log
showed the correct quotes themselves in the insert statement. I thought that to be quite odd.
And when I re-do my test, the quotes now GO IN CORRECTLY!
In fact, the comments I added on Dec. 31 actually show correctly as well - I just didn't notice (check) the on screen display.
I was too busy looking at the behind the scenes logs, assuming the problem was still there.
Maybe the fix is because of the the new core.jar I put in. I don't know at this point.
Also, while I was at home over the holidays, trying to sort this out, our I.T. guy was (unbeknownst to me) also playing around
with our Sun box and installation. I'm not sure (and he's not sure) exactly what he might have changed.
I now see that the System Encoding is back to ISO646-US (remember I had it changed to ISO8859-1 at one point).
The last "bad" comment in our jiraaction table is dated Dec. 6, so there was clearly this problem up until that date at least.
So I am going to assume that something I did or something our I.T. guy did or both has resolved the problem.
I'll definitely let you know if it happens again. At least I learned a lot about how to create a test installation of Weblogic. That's not wasted time

Neal,

Thanks for the update. I will resolve this issue for now. If you have any more info as to why the problem disappeared please let us know.

We will let you know if this problem is reported by someone else.

Thanks,
Anton