[Tomcat, HTTPD, Servlets & JSP] - charset=ISO-8895-1 being added to response content type
by thmix10
We have an application that is comprised of a client side component run on phones, and a server side component which communicates with the phones and links them to our other SOA architectures. This was previously running on WebLogic 7, but since we are shifting to JBoss, it was decided to move this application over.
For the most part, the port went smoothly. Removal of WebLogic specific classes was a simple task, getting it to compile under the new environment took a little time and tinkering but it, too, went smoothly. After getting the ported application deployed to the server and letting some of the phones communicate, strange things started to happen. After some time trying to debug the situation, we found the problem. Without getting into too much nitty-gritty about how the application (phone or server) works, the responses coming from the server differ in one small way that breaks functionality on the phone. Mainly, we are setting the content type to a specific type (?application/eventstream?). When this response leaves the server, it has become ?application/eventstream;charset=ISO-8895-1?. While there is nothing wrong with this from an HTTP standpoint, then phone application is exclusively looking for ?application/eventstream? and nothing else.
Now, probably the simplest thing to do to fix the issue would be to change a ?.equals? to a ?.startsWith? or a ?.indexOf(?)>=0? inside the phone code. However, there are some 3000+ phones in the field and the procedure for getting the application on the phones and actually updated is a long and arduous one. The change would have to be server-side, at least as a temporarily until we reach a point where an update can be made to the phone application. So, back to work looking for where this string is modified in the JBoss (or to be more exact, Tomcat) codebase.
It can be tracked to the class org.apache.coyote.Response. Inside the getContentType() method, there is a small section of code that is checking for encoding, and appending it on the string before it?s returned. It?s an easy task to comment out that small section and recompile the class. However, it?s not so easy to figure out what to do with the class. The solution that seemed to work was to take the class, jar it up, and throw that jar into the JBoss instance?s \lib directory. When the class-loader started loading, this was picked up first and was therefore the instance of the class used from there on. Problems do exist with this, however. The override is instance wide, which means that any other applications deployed to that instance also have the changed class. It also makes for a headache going forward, as this class needs to be checked with every new version to make sure that it is still compatible with the other code around it.
I tried looking for ways to make it local to the application and found a few possibilities with the class-loader, but none seemed to override the original class. I also tried to think of different implementation strategies, such as implementing a custom servlet (it?s currently a set of JSP pages), but these seemed to also use the same underlying class.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3957756#3957756
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3957756
19 years, 9 months
[JBossCache] - Re: Transactions in JBossCache 1.4CR2
by KChvilyov
Thahk you for 1.4 GA release. There is resolved previous error.
But we have a new:
java.lang.RuntimeException: PojoCache.putObject(): fqn: /poker/tournaments/1361/21/data at org.jboss.cache.aop.PojoCache.putObject(PojoCache.java:478) at org.jboss.cache.aop.CacheInterceptor.invoke(CacheInterceptor.java:152) at org.jboss.aop.joinpoint.FieldReadInvocation.invokeNext(FieldReadInvocation.java:48) at com.intersolved.poker.table.model.TableModelData.currRound_r_$aop(TableModelData.java) at com.intersolved.poker.table.model.TableModelData.getCurrRound(TableModelData.java:61) at com.intersolved.poker.table.model.TableModel.getCurrRound(TableModel.java:324) at com.intersolved.poker.table.services.hand.manager.AbstractHandManagerService.check(AbstractHandManagerService.java:327) at com.intersolved.poker.table.AbstractPokerTable.check(AbstractPokerTable.java:331) at com.intersolved.poker.lobby.tourney.tournaments.tournament.TournamentPokerTable.check(TournamentPokerTable.java:157) at com.intersolved.poker.lobby.tourney.tournaments.tournament.AbstractTournament.cleanTables(AbstractTournament.java:1042) at com.intersolved.poker.lobby.tourney.tournaments.tournament.AbstractTournament.handFinishedProcess(AbstractTournament.java:1158) at com.intersolved.poker.lobby.tourney.tournaments.tournament.AbstractTournament.processLosers(AbstractTournament.java:1099) at com.intersolved.poker.lobby.tourney.tournaments.tournament.TournamentPokerTable.onHandFinished(TournamentPokerTable.java:88) at com.intersolved.poker.table.services.hand.manager.TournamentHandManagerService.finish(TournamentHandManagerService.java:17) at com.intersolved.poker.table.services.hand.manager.AbstractHandManagerService.handProcess(AbstractHandManagerService.java:266) at com.intersolved.poker.table.services.hand.manager.AbstractHandManagerService.onTimer(AbstractHandManagerService.java:223) at com.intersolved.poker.table.AbstractPokerTable.onTimer(AbstractPokerTable.java:845) at com.intersolved.xmlserver.common.AbstractAsyncCommandExecutor.onEvent(AbstractAsyncCommandExecutor.java:63) at com.intersolved.xmlserver.common.AbstractCommandExecutor.execute(AbstractCommandExecutor.java:266) at com.intersolved.xmlserver.common.CommandExecutorQueue$PacketThreadQueueElement.executePacket(CommandExecutorQueue.java:89) at com.intersolved.xmlserver.common.CommandExecutorQueue$PacketThreadQueueElement.run(CommandExecutorQueue.java:71) at com.intersolved.xmlserver.common.queue.SynchronizedSystemThreadQueue$1.run(SynchronizedSystemThreadQueue.java:40) at EDU.oswego.cs.dl.util.concurrent.PooledExecutor$Worker.run(Unknown Source) at java.lang.Thread.run(Thread.java:595)Caused by: java.lang.RuntimeException: InternalDelegate.incrementRefCount(): null aopInstance for fqn: /poker/tournaments/1361/21/data at org.jboss.cache.aop.InternalDelegate.incrementRefCount(InternalDelegate.java:96) at org.jboss.cache.aop.ObjectGraphHandler.incrementRefCount(ObjectGraphHandler.java:212) at org.jboss.cache.aop.ObjectGraphHandler.setupRefCounting(ObjectGraphHandler.java:192) at org.jboss.cache.aop.ObjectGraphHandler.objectGraphPut(ObjectGraphHandler.java:88) at org.jboss.cache.aop.TreeCacheAopDelegate._putObject(TreeCacheAopDelegate.java:197) at org.jboss.cache.aop.PojoCache._putObject(PojoCache.java:731) at org.jboss.cache.aop.PojoCache.putObject(PojoCache.java:462) ... 23 more
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3957754#3957754
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3957754
19 years, 9 months
[Security & JAAS/JBoss] - Using j_security_check with a custom Principal , a custom Ca
by emailmsgbox
Hear me out, I'll make it short
I need username, password and kuku as parameters in my CallbackHandler and my LoginModule
when I initiate a login using my CallbackHandler MyPrincipal to my facades local or remote
like this
| MyLoginHandler login = new MyLoginHandler(new MyPrincipal( username, kuku),password);
| loginContext = new LoginContext("my-login",login);
| loginContext.login();
| ...
|
all is good
but when I try the "full Monty" meaning web and EJB with auth-method FORM (j_security_check) I of course fail ,
since the CallbackHandler that I get in my login module is a with a SimplePrincipal
and this SimplePrincipal is missing the extra parameter
So my problem is to pass the extra parameter to the my LoginModule
how do I get the j_security_check to take the extra paramenter and pass it on . in some way
I looked at the ExtendedFormAuthenticator but I do not see how could did help me.
since I do not use a filter
So be a sport and H-E-L-P
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3957753#3957753
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3957753
19 years, 9 months