[Installation, Configuration & Deployment] - Issue with loading jars - NoClassDefFoundError
by cronydude
Folks,
After successful installation and configuration of JBoss 4.0.5 on AIX 5.1 with JDK 1.4.2, I tried deploying a .ear file that was initailly build for WAS 5.
I saw few errors during the deployment and I believe they are because of in-proper loading of jar files. Sample of exception is as below:
================================================
java.lang.NoClassDefFoundError: org/jdom/JDOMException
at org.grnds.facility.GrndsCommonFacilityBootstrap.getXmlFileSource(GrndsCommonFacilityBootstrap.java:485)
at org.grnds.facility.GrndsCommonFacilityBootstrap.doSetupConfiguration(GrndsCommonFacilityBootstrap.java:238)
at org.grnds.facility.GrndsCommonFacilityBootstrap.execute(GrndsCommonFacilityBootstrap.java:158)
================================================
I know one way of making the .jar files available to the application is to copy all of them to 'server/lib'. Is there any other way of making this? Do I need to configure something to force the server to add these jars to the CLASSPATH?
Appreciate yout time and help.
Thanks
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3998330#3998330
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3998330
19 years, 3 months
[JBossWS] - Pbs when consuming a Web Service with JBoss WS 1.0.3 and 1.0
by pguillot44
Hello everybody,
I'am trying to consume a web service I wrote - based on the samples provided with JBoss WS.
I'm using JBoss 4.0.4.GA with JDK 1.4.2_06 - we are using 1.4 because of some other third party software we are using which do not support 1.5 yet.
I have no problem with consuming the web service when the web service client and the web service implmentation share the Java source code of the service end point interface.
The case which is of interrest for us is to not have the service end point interface on the client side but rely on WSDL instead - we need to demonstrate that we are able to consume any web service, including the ones for which we don't have the source code of the service endpoint interface.
After installing JBoss WS 1.0.3 and JBoss XB 1.0.0.CR7, I have the following error when consuling the web service :
2007-01-05 17:12:33,406 ERROR [STDERR] [SEVERE] [DACC995A4FA18232BEA04A3CE9708A1D] [79d39d9f8f18bfd0b3f6f3bbd51d82f5] [LOG_EXCEPTION] [java.lang.NoSuchMethodError: org.jboss.xb.binding.sunday.unmarshalling.SchemaBinding.setXopUnmarshaller(Lorg/jboss/xb/binding/sunday/xop/XOPUnmarshaller;)V
at org.jboss.ws.jaxb.JBossXBUnmarshallerImpl.unmarshal(JBossXBUnmarshallerImpl.java:60)
at org.jboss.ws.jaxrpc.encoding.JAXBDeserializer.deserialize(JAXBDeserializer.java:92)
at org.jboss.ws.soap.SOAPContentElement.getObjectValue(SOAPContentElement.java:235)
at org.jboss.ws.binding.EndpointInvocation.transformPayloadValue(EndpointInvocation.java:233)
at org.jboss.ws.binding.EndpointInvocation.getReturnValue(EndpointInvocation.java:182)
at org.jboss.ws.jaxrpc.CallImpl.syncOutputParams(CallImpl.java:873)
at org.jboss.ws.jaxrpc.CallImpl.invokeInternal(CallImpl.java:704)
at org.jboss.ws.jaxrpc.CallImpl.invoke(CallImpl.java:404)
at com.ecitiz.mairie.toulouse.ws.TarifCantineWSCall.Invoke(TarifCantineWSCall.java:97)
The web service is reached and compute the result, but then things are getting wrong.
The strange point is that I checked in the JBoss XB 1.0.0.CR7 source code that this method indeed exist ! I then double checked that I indeed put the right jar file in JBoss's "client" and "lib" directories.
I even resintalled JBoss and JBoss WS from scratch to make sure everything is clean - and rebuilt all my application items.
I then tried with JBoss WS 1.0.4 and JBoss XB 1.0.0.CR7 : I get another error : this time, I cannot even reach the web service because of this error :
2007-01-05 18:00:33,359 ERROR [STDERR] [SEVERE] Error while invoking Web Service:
org.jboss.ws.WSException: Cannot load service endpoint interface: com.ecitiz.mairie.toulouse.cantine.ws.tarif.TarifCantineContract
at org.jboss.ws.metadata.EndpointMetaData.getServiceEndpointInterface(EndpointMetaData.java:228)
at org.jboss.ws.metadata.EndpointMetaData.initializeInternal(EndpointMetaData.java:467)
at org.jboss.ws.metadata.EndpointMetaData.eagerInitialize(EndpointMetaData.java:454)
at org.jboss.ws.metadata.ServiceMetaData.eagerInitialize(ServiceMetaData.java:439)
at org.jboss.ws.metadata.UnifiedMetaData.eagerInitialize(UnifiedMetaData.java:183)
at org.jboss.ws.deployment.JSR109ClientMetaDataBuilder.buildMetaData(JSR109ClientMetaDataBuilder.java:132)
at org.jboss.ws.deployment.JSR109ClientMetaDataBuilder.buildMetaData(JSR109ClientMetaDataBuilder.java:85)
at org.jboss.ws.jaxrpc.ServiceImpl.(ServiceImpl.java:96)
at org.jboss.ws.jaxrpc.ServiceFactoryImpl.createService(ServiceFactoryImpl.java:158)
at org.jboss.ws.jaxrpc.ServiceFactoryImpl.createService(ServiceFactoryImpl.java:129)
at com.ecitiz.mairie.toulouse.ws.TarifCantineWSCall.Invoke(TarifCantineWSCall.java:85)
...
at java.lang.Thread.run(Thread.java:534)
Caused by: java.lang.ClassNotFoundException: com.ecitiz.mairie.toulouse.cantine.ws.tarif.TarifCantineContract
at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1352)
at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1198)
at org.jboss.ws.metadata.EndpointMetaData.getServiceEndpointInterface(EndpointMetaData.java:219)
... 50 more
I tried both installations several time and took care of the following :
- deleted jboss-4.0.4.GA\server\default\work\ content
- deleted jboss-4.0.4.GA\server\default\tmp\ content
- deleted jboss-4.0.4.GA\server\default\jbossws14.sar\ content
- unzipped jbossws-1.0.3.GA\lib\jboss-jdk1.4\jbossws14.sar in jboss-4.0.4.GA\server\default\jbossws14.sar\
- copied jbossws-1.0.3.GA\lib\jboss-jdk1.4\jbossws14-client.jar in JBoss' "client" directory
- copied jboss-xml-binding.jar - got it here : http://repository.jboss.com/jboss/jbossxb/1.0.0.CR7/lib/ - in JBoss's "client" and "lib" directories.
- deleted all the build produced items and rebuild the web service implementation and client app...
Note that I changed nothing in my projects when I moved from JBoss WS 1.0.3 to JBoss WS 1.0.4. I simply rebuild everything.
Now, I don't see what I can try next...
Do you see anything wrong in what I did ?
Thanks in advance for any hint you could provide me.
Kind regards,
Patrick Guillot
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3998325#3998325
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3998325
19 years, 3 months
[EJB 3.0] - EJB QL - Inheritence Query Question
by costeen21
Assume the following environment:
I have a base abstract class setup for inheritence that has a Many-to-Many relationship with another class like:
| @Entity
| @Inheritance(strategy = InheritanceType.JOINED)
| public abstract class Automobile implements Serializable
| {
| private Set<Part> parts;
|
| @ManyToMany(mappedBy="parts")
| public Set<Part> getParts()
| {
| return parts;
| }
| }
|
| @Entity
| public class Part implements Serializable
| {
| private Set<Automobile> autos;
|
| @ManyToMany(cascade=CascadeType.ALL, fetch=FetchType.EAGER)
| public Set<Automobile> getAutomobiles()
| {
| return autos;
| }
| }
|
|
|
I have two classes that derive from my base calss.
| @Entity
| public class Car extends Automobile
|
| @Entity
| public class Truck extends Automobile
|
Can a EJB QL query be constructed such that I only get results for one of the derived classes?
Something like:
for this part get only the "Cars" associated with it.
SELECT auto FROM Autobile auto, IN(auto.parts) AS part where part=:specificPart and "Automobile instanceof Car"
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3998321#3998321
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3998321
19 years, 3 months
[JBossCache] - shun=true and JVM freezes + replication queue
by bruyeron
We are running into issues with our jbosscache cluster running inside a Tomcat 5.5.17 on JDK1.5.08. We are using the BETA of 1.4.1 that was released back in november.
Here's the current treecache config and below the current jgroups stack we are using:
| <bean id="treeCacheInstance" class="xxx.TreeCache">
| <property name="isolationLevel" value="REPEATABLE_READ" />
| <property name="cacheMode" value="REPL_ASYNC" />
| <property name="clusterName" value="${treeCache.clusterName}" />
| <property name="useReplQueue" value="false" />
| <property name="replQueueInterval" value="0" />
| <property name="replQueueMaxElements" value="0" />
| <property name="fetchInMemoryState" value="false" />
| <property name="initialStateRetrievalTimeout" value="20000" />
| <property name="syncReplTimeout" value="20000" />
| <property name="lockAcquisitionTimeout" value="5000" />
| <property name="useRegionBasedMarshalling" value="false" />
| <!-- <property name="useInterceptorMbeans" value="false"/> -->
| <property name="clusterProperties"
| value="${treeCache.clusterProperties}" />
| <property name="serviceName">
| <bean class="javax.management.ObjectName">
| <constructor-arg value="jboss.cache:service=${treeCache.clusterName},name=myapp"/>
| </bean>
| </property>
| <property name="evictionPolicyClass" value="org.jboss.cache.eviction.LRUPolicy"/>
| <property name="maxAgeSeconds" value="${treeCache.eviction.maxAgeSeconds}"/>
| <property name="maxNodes" value="${treeCache.eviction.maxNodes}"/>
| <property name="timeToLiveSeconds" value="${treeCache.eviction.timeToLiveSeconds}"/>
| </bean>
|
jgroups stack:
| treeCache.clusterProperties=UDP(ip_mcast=true;ip_ttl=64;loopback=false;mcast_addr=${treeCache.mcastAddress};mcast_port=${treeCache.mcastPort};mcast_recv_buf_size=80000;mcast_send_buf_size=150000;ucast_recv_buf_size=80000;ucast_send_buf_size=150000;bind_addr=${treeCache.bind_addr}):\
| PING(down_thread=false;num_initial_members=3;timeout=2000;up_thread=false):\
| MERGE2(max_interval=20000;min_interval=10000):\
| FD_SOCK(down_thread=false;up_thread=false):\
| FD(timeout=4000;max_tries=4;down_thread=false;up_thread=false;shun=false):\
| VERIFY_SUSPECT(down_thread=false;timeout=3000;up_thread=false):\
| pbcast.NAKACK(down_thread=false;gc_lag=50;retransmit_timeout=600,1200,2400,4800;up_thread=false):\
| pbcast.STABLE(desired_avg_gossip=20000;down_thread=false;up_thread=false):\
| UNICAST(down_thread=false;;timeout=600,1200,2400):\
| FRAG(down_thread=false;frag_size=8192;up_thread=false):\
| pbcast.GMS(join_retry_timeout=3000;join_timeout=5000;print_local_addr=true;shun=false):\
| pbcast.STATE_TRANSFER(down_thread=true;up_thread=true)
| treeCache.eviction.maxNodes=5000
| treeCache.eviction.maxAgeSeconds=1000
| treeCache.eviction.timeToLiveSeconds=900
|
We had an event today where one of the 4 JVMs in the cluster froze for about 30s (that's (possibly) a separate problem we are investigating). Here's a sample of the logging from that event:
# here is the view: 12 members (4 JVMs with 3 TreeCache instances each)
APP2 05/01/2007 09:04:45 INFO [TreeCache.java:5431] - viewAccepted(): [10.163.195.24:33030|131] [10.163.195.24:33030, 10.163.195.24:33033, 10.163.1
95.24:33035, 10.163.195.21:32875, 10.163.195.21:32877, 10.163.195.21:32879, 10.163.195.23:33033, 10.163.195.23:33035, 10.163.195.23:33037, 10.163.195.22:3308
7, 10.163.195.22:33089, 10.163.195.22:33091]
....
# at 12:05:22, the JVM of APP2 froze for about 30s
...
# APP4 is the coordinator at this point
APP4 05/01/2007 12:05:50 WARN [GMS.java:413] - failed to collect all ACKs (11) for view [10.163.195.24:33030|132] [10.163.195.24:33030, 10.163.195.24:33033, 10.163.195.24:33035, 10.163.195.21:32875, 10.163.195.21:32877, 10.163.195.21:32879, 10.163.195.23:33033, 10.163.195.23:33035, 10.163.195.23:33037, 10.163.195
.22:33089, 10.163.195.22:33091] after 2000ms, missing ACKs from [10.163.195.22:33089, 10.163.195.22:33091] (received=[10.163.195.24:33030, 10.163.195.21:3287
9, 10.163.195.23:33033, 10.163.195.24:33033, 10.163.195.24:33035, 10.163.195.21:32877, 10.163.195.21:32875, 10.163.195.23:33035, 10.163.195.23:33037]), local
_addr=10.163.195.24:33030
APP2 05/01/2007 12:05:58 WARN [FD.java:250] - I was suspected by 10.163.195.23:33037; ignoring the SUSPECT message and sending back a HEARTBEAT_ACK
APP2 05/01/2007 12:06:00 WARN [GMS.java:478] - I (10.163.195.22:33087) am not a member of view [10.163.195.24:33030|132] [10.163.195.24:33030, 10.163.195.24:
33033, 10.163.195.24:33035, 10.163.195.21:32875, 10.163.195.21:32877, 10.163.195.21:32879, 10.163.195.23:33033, 10.163.195.23:33035, 10.163.195.23:33037, 10.
163.195.22:33089, 10.163.195.22:33091]; discarding view
...
APP{1,3-12} 2007-01-05 12:13:44,243 WARN [org.jgroups.protocols.pbcast.NAKACK] - <10.163.195.22:33089] discarded message from non-member 10.163.195.22:33087, m
y view is [10.163.195.24:33030|132] [10.163.195.24:33030, 10.163.195.24:33033, 10.163.195.24:33035, 10.163.195.21:32875, 10.163.195.21:32877, 10.163.195.21:3
2879, 10.163.195.23:33033, 10.163.195.23:33035, 10.163.195.23:33037, 10.163.195.22:33089, 10.163.195.22:33091]>
We had to manually kill APP2 and restart it.
After reading more documentation, we think that shun=true is needed in our use-case: if I understand http://wiki.jboss.org/wiki/Wiki.jsp?page=Shunning correctly, this would have caused APP2 to shun itself from the group when it noticed that it was not part of the view, and then rejoin (since TreeCache configures the JChannel to autorejoin). Am I right?
I have several more questions regarding the settings of our stack:
* with shun=true, and assuming the "freezes" never exceed 30s, should I configure the timeouts and retries on the FD protocol so that they are > 30s (for example timeout=10000;max_tries=4, so that 40 > 30)?
* I noticed the UseReplQueue option: could you describe the use-cases where this might be useful (in the JBossCache distrib, the only example of its use is for the large http session replication cluster config)?
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3998318#3998318
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3998318
19 years, 3 months
[JBoss Seam] - Re: Seam and Portal Future
by bsmithjj
"swestbom" wrote : What is missing from seam applications is independent state maintenance for the various portlets on the page. We have many applications that we want to bring together under one site. These sites are all intranet based so the weight isn't as much of an issue (this can be ameliorated to a considerable degree).
|
| Also, where appropriate, we use traditional MVC (Sorry, not yours Gavin) and AJAX within portlets to deal with weight and avoid having to rebuild the whole page when an action is called within a portlet, so it is a hybrid.
|
| I really don't think that portlets are a big pain because I am not using seam to build them, I use that XML crazy other framework that Gavin King loves to take cracks at.
On state maintenance - your statement is flat out wrong - I'm going to sound like a Seam salesman, but Seam has one of the best state mgmt. capabilities available in Java-web frameworks. Your problem of tying state to individual regions on a page can be realized in a Seam architecture by using Stateful Session Beans (EJB3) that are associated to a particular conversation for a user-page interaction. In Seam, every component associated with a conversation exists as long as the conversation it's tied to exists. Having experience with both Portals and Seam, I'm going to say that my impression is that Seam's state-mgmt. is better; it's there working for you in an unobtrusive way, but it has hooks that allow you to perform sophisticated state mgmt. when necessary.
JSF apps are much easier to 'do Ajax with' than portlet apps - plain and simple. You have the options of letting a JSF component set (like ICEFaces) do the Ajax for you, use something like Seam remoting, do your own Ajax requests, etc...
By 'XML crazy other framework' do you mean Spring? --- IMHO - if we were still stuck with EJB 2.X/1.X and Java 1.4 or earlier, then Spring is a great way to build up your application infrastructure. Now that we have Java 5 annotations and JEE - EJB3 with JPA, a lot of the infrastructure difficulty that Spring was created to simplify is gone. Thus, if you can use Java 5 and the EJB3/JPA stuff for your apps, the value of using Spring goes way down. The Seam bijection annotations and annotations like @Resource in EJB3 make life so much easier and saner as a JEE developer.
Regards,
Brad Smith
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3998317#3998317
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3998317
19 years, 3 months