[JBossCache] - Re: Configuring JBossCluster
by urisherman
> You're not *deploying* the cache from an EJB, right?
What do you mean by "*deploying*"? Creating it and starting it?
Lets say I won't do that from an EJB, that's not the issue.
> It should be a separate deployment, either standalone or packaged with
> the ejb jar(s) in an ear or a sar.
It won't be standalone, it is intended to "live" inside our application. What do you mean by packaged with the ejb jars? The cache implementation is provided by u guys, it's in the server's lib directory. I use it inside my application, which is an ear that includes a bunch of ejb jars and wars.
> If not deploying the cache from the EJB, you're not creating threads
> from the EJB either, and there is no issue using the cache from the EJB.
Even if I don't deploy the cache from within an ejb (assuming "deploy"="create and start"), when I manipulate it from within an ejb the cache has to replicate itself, thus creating/dispatching a call to another thread (if working with async replication), or issue network io calls from the containers thread (if working with sync replication).
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3987953#3987953
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3987953
19Â years, 5Â months
[JBoss Seam] - Re: What's your prefered deployment strategy when developing
by ellenzhao
I found the example on this page is very helpful:
http://wiki.jboss.org/wiki/Wiki.jsp?page=EclipseSeamProject
The first time it took me almost one hour to set up everything correctly but you can really grok the Seam's packaging structure once you completely walk it through by heart. It serves very well as a template. Now I've modified the booking example a great deal, adding jpdl pageflow and rules stuff, never had any packaging or "class/resource not found" problem following this example. Once you grokked the seam packaging structure and familiar with the several xml configuration files, you can apply it with any IDE.
Currently the JBossIDE for Eclipse or any other Eclipse based IDE don't like to publish the project to a configured app server. However the workaround is extremely simple. You can "run packaging" with the eclipse seam projects set like the example, then copy&paste the ear file to the JBoss deploy folder. Either with a line of console command (cp ....) or with a GUI file management tool drag and drop.
I've used all of Eclipse 3.2+, NetBeans 5.5 and IDEA 6. When it comes to deployment, I'm happiest with NetBeans' Ant-based approach. I used NetBeans to setup a new project and configured everything with its GUI tools. NetBeans generates the build.xml for me. You can happily work on projects with this build file (Assume the ant is installed on your system) without any big IDE and the deployment is a simple "ant deploy". Since most of the developers around me are still using Eclipse so I'm using Eclipse just to be social. Actually I like NetBeans better merely because it is so easy to get the working build.xml from it. :-)
And yes, Seam is great stuff. I highly appreciate the idea behind and the Seam developer's hardwork. :-)
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3987952#3987952
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3987952
19Â years, 5Â months
[JBossWS] - Re: Securing POJO Web Service in 4.0.3 SP1
by osganian
Hi Sanjay,
I am having a similar problem that I was hoping you could help me with. How do you have your client setup to access your web services wsdl files? Do you bundle the wsdl files on the client?
Currently I have the client accessing my wsdl files by going to: https://localhost:8443/service/MyService?wsdl
My problem is when I secure my POJO web service in web.xml like:
| <security-constraint>
| <web-resource-collection>
| <web-resource-name>SecureServer</web-resource-name>
| <url-pattern>/service/*</url-pattern>
| <http-method>GET</http-method>
| <http-method>POST</http-method>
| </web-resource-collection>
| <auth-constraint>
| <role-name>USER</role-name>
| </auth-constraint>
| <user-data-constraint>
| <transport-guarantee>CONFIDENTIAL</transport-guarantee>
| </user-data-constraint>
| </security-constraint>
|
The problem is since my wsdl url is protected just like the service itself. So I end up getting the following error on the client:
| [java] Caused by: java.io.IOException: Server returned HTTP response code:
| 401 for URL: https://localhost:8443/service/MyService?wsdl
| [java] at sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1153)
| [java] at sun.net.www.protocol.https.HttpsURLConnectionImpl.getInputStream(HttpsURLConnectionImpl.java:234)
| [java] at java.net.URL.openStream(URL.java:1007)
| [java] at org.jboss.ws.metadata.wsdl.WSDLDefinitionsFactory.getDocument(WSDLDefinitionsFactory.java:181)
|
Thanks for any help,
Mike
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3987951#3987951
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3987951
19Â years, 5Â months
[Clustering/JBoss] - NotSerializableException in JBossCache with Log4J Level clas
by Marlig
Hi,
I'm wondering whether someone has had this problem before, because I couldn't find anything about it in the forums. From time to time in my logs I see this exception:
| 2006-11-22 17:19:21,104 ERROR [org.jboss.web.tomcat.tc5.session.JBossCacheService] externalizeSession(): exception occurred externalizing session SessionBasedClusteredSession[id: POpO-xNbPcMuoMCfHsgI2w**.node01 lastAccessedTime: 1164212361095 version: 27 lastOutdated: 0]
| java.io.NotSerializableException: org.apache.log4j.Level
| at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1081)
| at java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1375)
| at java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1347)
| at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1290)
| at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1079)
| at java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1375)
| at java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1347)
| at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1290)
| at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1079)
| at java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1375)
| at java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1347)
| at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1290)
| at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1079)
| at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:302)
| at java.util.HashSet.writeObject(HashSet.java:254)
| at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
| at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
| at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
| at java.lang.reflect.Method.invoke(Method.java:585)
| at java.io.ObjectStreamClass.invokeWriteObject(ObjectStreamClass.java:917)
| at java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1339)
| at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1290)
| at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1079)
| at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:302)
| at java.util.HashMap.writeObject(HashMap.java:1039)
| at sun.reflect.GeneratedMethodAccessor134.invoke(Unknown Source)
| at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
| at java.lang.reflect.Method.invoke(Method.java:585)
| at java.io.ObjectStreamClass.invokeWriteObject(ObjectStreamClass.java:917)
| at java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1339)
| at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1290)
| at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1079)
| at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:302)
| at java.util.Hashtable.writeObject(Hashtable.java:813)
| at sun.reflect.GeneratedMethodAccessor342.invoke(Unknown Source)
| at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
| at java.lang.reflect.Method.invoke(Method.java:585)
| at java.io.ObjectStreamClass.invokeWriteObject(ObjectStreamClass.java:917)
| at java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1339)
| at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1290)
| at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1079)
| at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:302)
| at org.jboss.web.tomcat.tc5.session.SessionBasedClusteredSession.writeExternal(SessionBasedClusteredSession.java:175)
| at org.jboss.web.tomcat.tc5.session.JBossCacheService.externalizeSession(JBossCacheService.java:902)
| at org.jboss.web.tomcat.tc5.session.JBossCacheService.putSession(JBossCacheService.java:348)
| at org.jboss.web.tomcat.tc5.session.JBossCacheClusteredSession.processSessionRepl(JBossCacheClusteredSession.java:122)
| at org.jboss.web.tomcat.tc5.session.JBossCacheManager.processSessionRepl(JBossCacheManager.java:994)
| at org.jboss.web.tomcat.tc5.session.JBossCacheManager.storeSession(JBossCacheManager.java:637)
| at org.jboss.web.tomcat.tc5.session.InstantSnapshotManager.snapshot(InstantSnapshotManager.java:52)
| at org.jboss.web.tomcat.tc5.session.ClusteredSessionValve.invoke(ClusteredSessionValve.java:105)
| at org.jboss.web.tomcat.tc5.session.JvmRouteValve.invoke(JvmRouteValve.java:84)
| at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:432)
| at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:74)
| at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126)
| at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105)
| at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107)
| at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148)
| at org.apache.jk.server.JkCoyoteHandler.invoke(JkCoyoteHandler.java:199)
| at org.apache.jk.common.HandlerRequest.invoke(HandlerRequest.java:282)
| at org.apache.jk.common.ChannelSocket.invoke(ChannelSocket.java:754)
| at org.apache.jk.common.ChannelSocket.processConnection(ChannelSocket.java:684)
| at org.apache.jk.common.ChannelSocket$SocketConnection.runIt(ChannelSocket.java:876)
| at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:684)
| at java.lang.Thread.run(Thread.java:595)
|
What I was able to find somewhere was a bug in Log4J saying the Level class is not serializable. Now I thought I would just replace the Log4J version that ships with JBoss 4.0.4 with a newer version (Log4J 1.2.13), but somehow the problem persists.
What I replaced were the log4j.jar in server/all/lib, but not the log4j-boot.jar in the servers lib directory. I guess these are the classes that are still loaded first, and thus still causing the problem. But I am not sure on how to replace this log4j-boot.jar (if it's the source of the problem at all)? Could I just replace it with the normal log4j.jar?
Thanks for your help and ideas
Martin
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3987946#3987946
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3987946
19Â years, 5Â months