[Tomcat, HTTPD, Servlets & JSP] - <META HTTP-EQUIV="Content-Type" > setting did not work in J
by evan036
Hi everyone,
We are doing an EJB application which is supported Chinese language (which allowed end-user to entry chinese and retrieve it from DB and displayed on page).
In order to displayed the chinses on jsp page, we have the following setting for HTML header in every jsp page:
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=GB2312" >
As my understand, this setting will automatically change the browser's encoding menthod to GB2312 without asking end-user to manually change the setting by they own.
However, we found this setting did not work. the encoding setting of browser is always set to ISO and end-user need to manual change it to GB2312.
But if we add "<%response.reset();%> in the jsp page, then it work and automatically change the browser's setting....... very strange. Unforunately, reset() menthod is also reset some parameter value in the response header which is necessary information for us.
Does anyone have this kind of experience before? Is any setting of Jboss will override the setting for charset in every response?
It will be appreciate for any comments for you guys. Thank you
-Evan
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4007125#4007125
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4007125
19 years, 2 months
[JBossWS] - Re: EJB3 and JBossWS (JAXWS), is WSgen even needed for botto
by jason.greene@jboss.com
"dwin" wrote : please clarify for me,
|
| this "magic" that happens behind the scene is specific to JBossWS 1.2 or to any implementation of JAX-WS?
It's a feature specific to JBossWS. The whole reason for the JAX-WS wrapper classes is to solve a technical problem that is specific to the vender. So since the end-user never actually does anything with these classes, we think it's silly to epect them to run an offline tool to generate them. So if you do not include them, we generate them on the fly for you during deployment.
That said, since the wrapper types are required artifacts, in order for your deployment to be portable to other containers (if you even care) you would need to generate them offline using the wsgen tool. I recently finished the offline tool for this purpose (code is currently in trunk).
Also, this only applies to the wrapper types. The WSDL file is not needed on any JAX-WS compliant container.
-Jason
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4007106#4007106
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4007106
19 years, 2 months
[JBossWS] - Jaxb EAR project - please help
by X490812
I have an EAR project. In the project I have a web app and an EJB. My goal is to have a REST webservice servlet that gets the XML payload, uses JAXB to unmarshal it into XJC generated classes, then pass those classes to an EJB for processing. What I have found is the following:
scenario 1)
here is the EAR fle structure:
EAR
bpo-lib.jar - holds the XJC generated classes
bpo-ejb.jar - references bpo-lib.jar in its manifest.mf file
bpo-webservice.war - holds the rest servlet that does the unmarshaling and passes unmarshaled objects to EJB
- holds bpo-lib.jar in WEB-INF/lib - I did this because I saw in the FAQ that JAXBContext.newInstance tries to load
classes using the same clasloader that the JAXBContext class is in
- references bpo-lib.jar in its manifest.mf file
The result is that I can unmarshal the data into the XJC classes, but after I pass them to the EJB, I try to cast the object into the expected types and get a class cast exception. this is possibly the behavior mentioned in https://jaxb.dev.java.net/faq/#classloader
scenario 2)
here is the EAR file structure:
EAR
bpo-lib.jar - holds the XJC generated classes
bpo-ejb.jar - references bpo-lib.jar in its manifest.mf file
bpo-webservice.war - holds the rest servlet that does the unmarshaling and passes unmarshaled objects to EJB
- does NOT hold bpo-lib.jar in WEB-INF/lib - I did this because in theory, on JBOSS4.0.4GA,
the EAR classes are accessible to the WAR context. I.E., I should NOT have to put the bpo-lib.jar file
in both the WEB-INF/lib dir and the EAR file
- references bpo-lib.jar in its manifest.mf file
The result is that I can NOT unmarshal the data into the XJC classes.
To analyze this, I checked what classes the JAXBContext knows about, and what I found was that when it unmarshalled data, I had this set of classes:
boolean
byte
char
com.homeq.bpo.domain.FirstAmericanSchema.request.AppraisalStatusResponses
com.homeq.bpo.domain.FirstAmericanSchema.request.AppraisalStatusResponses$AppraisalStatusResponse
com.homeq.bpo.domain.FirstAmericanSchema.request.AppraisalStatusResponses$AppraisalStatusResponse$Notes
com.homeq.bpo.domain.FirstAmericanSchema.request.NoteType
com.homeq.bpo.domain.FirstAmericanSchema.request.ResultsDataType
com.sun.xml.bind.api.CompositeStructure
double
.
.
.
When it did not unmarshal data it had this set of classes:
boolean
byte
char
com.homeq.bpo.domain.FirstAmericanSchema.request.ObjectFactory
com.sun.xml.bind.api.CompositeStructure
double
float
.
.
.
The above shows (I think) that I MUST have the bpo-lib.jar in the WEB-INF/lib dir as the classloader that loads JAXBContext must also load the generated files. But as shown in scenario 1 above, this prevents you from also referencing those classes in an EJB as an EJB should not access classes loaded inside of the WAR classloader.
Would I be correct in stating that using JAXB in a rest based web service on JBOSS4.0.4GA cannot be done, or am I missing something?
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4007082#4007082
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4007082
19 years, 2 months