In question 3) it should say:
<component name="org.jboss.seam.core.init"> <property name="debug">true</property> ... </component>
1) ejb-jar.xml should go in my_ejb.jar/META_INF
3) setting debug to true (combined with placing seam-debug.jar WEB-INF/lib) will cause the debug page to be shown when (some) exceptions are thrown.
4) I've never had to include a jndi.properties file in an ear (to JBoss AS)
Hey, thanks for the responses:
Question 2 should have read the following:
<component class="org.jboss.seam.core.Ejb" installed="false"/>
What does the above in components.xml do? And is it necessary?
Also, regarding your answer to question 3: we can place the JAR anywhere on the classpath, right? (Not necessarily WEB-INF/lib, or is it?)
2) If set to true that causes embedded ejb3 to be installed. AFAIK omitting that line from components.xml has the same effect as setting it to false
3) Anywhere that is on the classpath for the war. WEB-INF/lib is the standard/simple place to put it.
Thanks again. I do have one other question (I'm asking all of these because I seem to be getting closer to a functioning configuration, but I'm not quite there...still problems...)
I noticed that in the META-INF of the EAR there's a jboss-app.xml with the following:
<jboss-app> <loader-repository> seam.jboss.org:loader=seam-registration </loader-repository> </jboss-app>
This seems to be pretty significant, though I could be wrong...do I need one of these files? What would I replace seam-registration with...would it be the name of the context of my WAR? What exactly does this file do from the perspective of Seam...a web search tells me it has something to do with classloading...?
This just enables scoped classloading. You only need this if you will be running to EARs in the same server, and they both have classes with the same names.
How can the Seam "registration" example only have two jar files in the entire EAR? (jboss-seam.jar on the main section and jboss-seam-ui.jar in WEB-INF/lib)?
Where are the other necessary JARs, such as MyFaces, log4j, and the others?
Also, is there any advantage to putting a JAR directly underneath the EAR and declaring it in application.xml versus keeping it elsewhere in the EAR?
There are lots of libraries alreadly installed on JBoss AS (e.g. myfaces, log4j, ejb3, hibernate)
If you declare a jar in application.xml it will be added to the ear's classpath. Elsewhere it won't be (WEB-INF/lib as discussed above)
I'm guessing those already-installed libs you mentioned would either be located in JBOSS/lib or JBOSS/server/lib and thus added to the classpath of appropriate deployments?
I've been having an issue understanding what exactly is on my classpath at any given time...if I'm looking for a given class, I'd like to do it from a centralized place rather than essentially "guessing" which JAR it's in, then looking through it, then making another guess as to whether that JAR is on the classpath (because there could be multiple versions of the same class deployed in one app, which probably happened with me because I added the myfaces classes on top of the JBoss built-in ones)
How can I do this in JBoss (see all classes currently on the classpath for a given deployment or application)? Is this something I can do from the jmx-console, or some very simple Java client I could write to interact with the app server that could tell me this?
I'd hope so, as this seems like a pretty useful or commonly-needed feature when developing on JBoss and troubleshooting problems with web or ejb apps...
Well, even "for a given deployment or application" isn't consistent. Your web app has a different view of classes than your EAR.
If you are running with a scoped classloader, which you should be doing with a Seam application (and honestly, it is how you should deploy EVERY application on JBoss) then you can look at MBean for your repository in the JMX Console. (look an MBean of the same name as your the repository listed in your jboss-app.xml). One of the attributes there is URLs, which gives you a list of all the elements on in the classpath for the root of your deployment.
You might also want to check out the displayClassInfo action. You can enter a class name, and the action will let you know which jar a specific class has been loaded from. (assuming it has been loaded at all)
The default shared repository is JMImplementation:name=Default,service=LoaderRepository. If you scope ALL of your applications then you really won't need to look there much, but it's good to know where it is if you need it.
Thanks for that information about the jmx-console...I'm playing around with it right now and it seems very useful!
A few questions about these classloading issues that have come up by me reading the JBoss ClassLoading wikis:
1) What is the relationship between UnifiedClassLoaders and EARs, WARs, EJB-JARs, and regular JARs deployed in the application server? The following link doesn't explicitly say whether every archive has one and only one UCL:
What about an archive with sub-archives (e.g. an EAR containing WARs, JARs, and EJB-JARs)? Do they ALL share the same UCL? (My question asks more about this one...)
2) From http://www.jboss.org/wiki/Wiki.jsp?page=ClassLoadingConfiguration :
"There are two levels of scoping, isolation from other deployments, and isolation that overrides the loading of JBoss server classes. With nested modules, only the top level file may specify class loader scoping. If you have a .ear file containing other modules, only scoping specified in the .ear's META-INF/jboss-app.xml is used. This also applies for any other deployment which contains sub-deployments. For example, if a .sar contains a .war deployment, only the .sar META-INF/jboss-service.xml scoping has effect."
Does this mean that every class in a given top-level archive (or sub-archive of it) has been loaded by the same classloader, and therefore absolutely any class can see any other class within the top-level archive (or sub-archive)?
3) How does the exception with classes in the WAR file occur (where things in the WAR file can't be seen elsewhere in the archive by default)? Is the WAR's jboss-***.xml file ignored? (i.e. The equivalent of it always turning ON scoped classloading for that WAR?) Why is it treated different from other archive types?
4) Is saying that an archive has scoped classloading the exact same as saying that the archive has its own UCL?
Thanks a lot for your help.
To add to my questions in the previous post:
5) When would two EARs ever need to speak to each other? I've read things about the problems with CallByValue semantics of classloading (which happens if you set deployment isolation), but when would this problem manifest itself?
Are EARs supposed to be able to talk to each other? Aren't they independent enterprise archives? i.e. The whole application has only one and everything within it that it needs? If not, how would they communicate?
Any help on any of these questions would really help.
Thanks a lot.
For in-depth classloader discussions, you are probably better off in one of the JBoss AS forums.
1) Yes, each deployment gets 1 UCL that covers the entire archive, including sub-deployments
2) Every class in a deployment can see every other class in that same deployment (WAR files are a special case)
3) WAR files are special because the servlet spec says they should be special. If you have two WAR files in an EAR, they should not see eachothers classes. So, JBoss does not add WEB-INF/classes or WEB-INF/lib/* to the UCL by default. You can change this behavior by setting the UseJBossWebLoader option. When you do that, tomcat will use the deployment UCL for web app loading, making everything visible throughout your app.
4) Every archive has it's own UCL. A scoped application has a UCL that points to it's own repository instead of to the main repository.
5) In general, one app should be able to look up and use beans in another app on the same server. If there aren't common class definitions between the two apps, you have to go through serialization. This is costly, though JBoss people often make the mistake of over-emphasizing the cost. (by comparing the cost of serialization to the cost of a direct call without considering the amount of work being done in the call)
My general belief is that shared class definitions is a bad thing for applications and a good thing for services. I would always scope my applications in the absence of a compelling reason not to.