-
1. Re: Invalid invocation, check your deployment packaging in J
adellechiaie May 6, 2005 1:09 PM (in response to adellechiaie)I've just RTFM ;-)) on the classloading issues, I understood the concepts but I don't see any out-of-the-box example how to be servlet spec compliant and still running my existing applications.
Bye
Andrea -
3. Re: Invalid invocation, check your deployment packaging in J
bocio May 8, 2005 11:52 AM (in response to adellechiaie)"scott.stark@jboss.org" wrote:
http://wiki.jboss.org/wiki/Wiki.jsp?page=ClassLoadingConfiguration
http://wiki.jboss.org/wiki/Wiki.jsp?page=JBossClassLoadingUseCases
Hi Scott I read both the wikis, but as I told, what I have to chanage into my existing apps to get it working again?
I see some in depth nice classloading explanations but I do not see a pratical example as for this comment:
http://jira.jboss.com/jira/browse/JBAS-1691#action_12317322
Thank you in advance. -
4. Re: Invalid invocation, check your deployment packaging in J
jm1 May 11, 2005 5:12 PM (in response to adellechiaie)Ditto, I have same problem with 4.0.2 - exact same Exception. Simple SessionBean, used to work in 4.0.1. What gives?
This is why I stayed away from JBoss for so long, things breaking from version to version and so called experts always telling people to RTFM. I see the business model behind JBoss now, crappy product + paid support.
Fortunately I am in position to influence the change at my Fortune 500 company. Saying goodbye to JBoss forever, stick with what works - Weblogic/Webspere. Enough of this open source nonsense for me!!! -
5. Re: Invalid invocation, check your deployment packaging in J
adrian.brock May 11, 2005 5:30 PM (in response to adellechiaie)Ignoring the obvious TROLL.
I told you Scott that using the servlet spec classloader would just lead to
a fleury (sic! :-) of faqs from people that don't understand packaging/classloading.
Bocio, which part of the following don't you understand?To revert to pre-4.0.2 config use: <attribute name="Java2ClassLoadingCompliance">true</attribute> <attribute name="UseJBossWebLoader">true</attribute>
The pre-4.0.2 behaviour was to ignore the servlet spec and use standard
java classloading, meaning it ignores your duplicate deployments of classes
in the ejb jars and wars. -
6. Re: Invalid invocation, check your deployment packaging in J
starksm64 May 11, 2005 5:58 PM (in response to adellechiaie)What can I say, people don't care about flexibility to configure it the way the need apparently.
-
7. Re: Invalid invocation, check your deployment packaging in J
adrian.brock May 11, 2005 6:21 PM (in response to adellechiaie)We need that installer so you can give them the options:
* Dumb spec (scoped with marshalled calls)
* Fast (flat classloader and call by reference)
The 4.0.2 hybrid of "scoped with call by reference" just gives users (and us) a headache. -
8. Re: Invalid invocation, check your deployment packaging in J
starksm64 May 11, 2005 6:27 PM (in response to adellechiaie)Yes, we'll see if we can get there for 4.0.3. Who knows what twists the ejb3 stuff will throw into the mix.
-
9. Re: Invalid invocation, check your deployment packaging in J
adrian.bigland May 12, 2005 8:28 AM (in response to adellechiaie)I'm playing around with different approaches to dealing with isolated EARs, and I get this error when:
a) I've scoped the classloader for the EAR:
<jboss-app>
<loader-repository>
Cyrus.classloading:loader=application registry
<loader-repository-config>
java2ParentDelegation=true
</loader-repository-config>
</loader-repository>
</jboss-app>
b) set JNDI to call-by-value (so the EJB home object is deserialized into the clients classloader context)
c) NOT enforced call-by-value on the EJB
I've tried one approach to enforcing call-by-value for the EJB, which makes everything work (as you would expect!). This is to change the standardjboss.xml invoker-proxy-binding to always use the marshalling invoker.
When I try setting ...<call-by-value>true</call-by-value>... in the EJBs jboss.xml instead of the proxy binding solution it doesn't seem to help. I'm trying to look up more info on the call-by-value attribute i.e. does it affect the EJB's client invoker stack or does it affect the EJB's calls out to other beans?
Anyway, I think that although the wiki and documentation covers the configuration of the classloading well, with good discussion of the issues, it is a bit confusing how and where you need to do semi-detyping using serialization to bridge the different classloaders. There seem to be several ways of doing this but its a bit difficult to figure out the 'best' way. Or perhaps I've got the wrong end of the stick... -
10. Re: Invalid invocation, check your deployment packaging in J
bocio May 13, 2005 5:36 AM (in response to adellechiaie)"scott.stark@jboss.org" wrote:
What can I say, people don't care about flexibility to configure it the way the need apparently.
Geee Scott & Adrian!
I'm not a troll but please stop to treat us like monkeys.
I do care about flexibility and I do care about Jboss givena that I have various applications running JBoss in production environment. And I do not use because it's free but just because it's the best I ever used.
If I have to to change lubricating oil to my car, Ford design plans probably don't help me too much but I prefer to have a simple howto :-)
#1 open the hood
#2 remove the screw plug located...
Should I be a classloading Jedi to be a JBoss customer?
I have the same problem as adrian.bigland:
I added:<jboss-app> <loader-repository> sogei.com.console:loader=console.ear </loader-repository> </jboss-app> In my jboss-web.xml, I added: <jboss-web> <class-loading> <loader-repository> sogei.com.console:loader=console.ear </loader-repository> </class-loading> </jboss-web>
But I'm still getting this error.
Now As Adrian previously stated on the Jira task:P.S. It is a good idea to provide an example than actually works out-of-the-box.
Bye form a monkey -
11. Re: Invalid invocation, check your deployment packaging in J
adrian.brock May 13, 2005 9:43 AM (in response to adellechiaie)The TROLL comment was aimed at "jm1@blitz.serveftp.com"
A "TROLL" is somebody that has nothing useful to add and just wants to start an argument. -
12. Re: Invalid invocation, check your deployment packaging in J
adrian.brock May 13, 2005 9:51 AM (in response to adellechiaie)"bocio" wrote:
Now As Adrian previously stated on the Jira task:P.S. It is a good idea to provide an example than actually works out-of-the-box.
Bye form a monkey
That is a misrepresentation I what I said.
I was complaining about a submitted test where I had would have had to completely rework
my environment variables (amongst other things) just to get the thing to compile.
JBoss does work out the box.
To (ab)use your analogy, you are complaining about where you previously
bought a car. You then update to this year's model and the maker has
decided to enable an annoying alarm when you don't put your seatbelt on.
It was still a problem before when you didn't wear your seatbelt, you
just didn't get the annoying sound.
Like the car, JBoss has a switch to revert to the earlier behaviour. -
13. Re: Invalid invocation, check your deployment packaging in J
msaringer May 13, 2005 9:53 AM (in response to adellechiaie)I do have exactly the same problem.
After reading the messages here as well as the manual and the wiki entries, I'm just able to revert to the pre 4.0.2 configuration.
What I really need is more detailled information on how to organize complex deployments so that they work properly with the default JBoss (4.0.2) settings. -
14. Re: Invalid invocation, check your deployment packaging in J
adrian.brock May 13, 2005 10:01 AM (in response to adellechiaie)"adrian.bigland" wrote:
When I try setting <session>...<call-by-value>true</call-by-value>...</session>
I've raised a bug report for this. It could be that this is broken.
http://jira.jboss.com/jira/browse/JBAS-1813