Re: [JBoss-user] Hot Deploy Does Not reflect Change.
Just to check the obvious things first... there are no copies of any of these classes in lib/ext? david jencks On 2001.11.01 20:11:31 -0500 vijay jagtap wrote: > > JBoss-2.4.3_Tomcat-3.2.3 > > It seems the AppServer is caching the JAR files to some unknown place. > > If I change the JAR file and redeploy, the changes are Not getting > effective. > > Even I shut down JBoss, machine, still I don't see the new changes made > to Bean. > > I deleted entire tmp folder. NO success. > > I don't think there any references kept open to Bean since I am running > simple test client program. > > Thanks. > > > > > > - > Do You Yahoo!? > Find a job, post your resume on Yahoo! Careers. > JBoss-2.4.3_Tomcat-3.2.3 > It seems the AppServer is caching the JAR files to some unknown > place. > If I change the JAR file and redeploy, the changes are Not getting > effective. > Even I shut down JBoss, machine, still I don't see the new changes > made to Bean. > I deleted entire tmp folder. NO success. > I don't think there any references kept open to Bean since I am > running simple test client program. > Thanks. > Do You Yahoo!? > Find a job, post your resume on href="http://careers.yahoo.com/?clink=foot-fp"; target="_blank">Yahoo! > Careers. ___ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user
RE: [JBoss-user] Debugging CMR
When was the last time you updated the code. I fixed a bug in that code on the 20th. The bug only appeared with self relations. This is an internal error and signifies a programming bug on my part. Just for your info, what is going on is each side of the relationship (each entity) has an object that represents it's part in the relationship. This object always exists and is completely independent of abstract accessor that the entity may or may not have. For the relationship code to work each side of the relationship needs to have a reference to the other sides cmr field object. Therefore, there is a whole bunch of code to connect the two sides, and this initialization code had a bug. -dain > -Original Message- > From: Hunter Hillegas [mailto:[EMAIL PROTECTED]] > Sent: Thursday, November 01, 2001 7:09 PM > To: JBoss 2 > Subject: [JBoss-user] Debugging CMR > > > I am deploying a bunch of EJB2.0 beans and getting an > exception. I'd like to > add some debug code to > > org.jboss.ejb.plugins.cmp.jdbc.bridge.JDBCCMRFieldBridge.initR > elatedData > > That will help print out why I'm getting this exception: > > Related CMR field not found. > > Anyone know what I could add to see more console detail? > > > ___ > JBoss-user mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-user > ___ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user
[JBoss-user] [ANN] JBoss training in Boston Jan 21-25 2002
Ladies and Gentlemen, Hello, on the heels of the succesful training in Las Vegas, we are pleased to announce our third US training to be held in Boston MA. We will be holding the training at the Lenox Hotel in Back Bay. The price for the full five days is $3150 for all attendees who pay by December 15th. After that date, the full price of $3500 applies. Reservation can only be confirmed upon payment. http://www.lenoxhotel.com/hotels/lenox/ If you are interested in registering and would like the payment details, please contact us by email mailto:[EMAIL PROTECTED]?subject=Boston training"> click here . We will update the website with the information shortly. Kind regards PS: we are setting up London and Sydney as we speak. These announcements to follow soon. Marc Fleury President JBoss Group, LLC ___ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user
[JBoss-user] Hot Deploy Does Not reflect Change.
JBoss-2.4.3_Tomcat-3.2.3 It seems the AppServer is caching the JAR files to some unknown place. If I change the JAR file and redeploy, the changes are Not getting effective. Even I shut down JBoss, machine, still I don't see the new changes made to Bean. I deleted entire tmp folder. NO success. I don't think there any references kept open to Bean since I am running simple test client program. Thanks. Do You Yahoo!? Find a job, post your resume on Yahoo! Careers.
[JBoss-user] [Fwd: javax.naming.NameNotFoundException: Name Interest is not bound inthis Context]
As far as I understand, the java:/comp/env (ENC) stuff is unlikely to be supported if
you are running separates. Since it gives each EAR it's own individual namespace it is
not a normal JNDI lookup into a flat namespace.
The integration code that holds JBoss/Tomcat or JBoss/Jetty together provides this
functionality.
Bear in mind that I know very little about Tomcat, being the Jetty integrator.
For a better answer try [EMAIL PROTECTED] or the user forums on the jboss web
site.
Try the in-vm integration with Tomcat or Jetty - I suspect your problem will disappear.
as for 'it is violate the distributed computing principle' - in my book anything that
makes my app go faster is fine. Provided that there is clean separation between tiers
I see nothing wrong in running them on the same box, or even in the same vm. Of
course, if you want to keep your options open you need to be aware of what features
work where, and it looks like you have just stumbled across your first.
Hope that helps,
Jules
cidy long wrote:
> Jules Gosnell
>
> I need a favor.
>
> I am cidy long from Australia. I have to write to you because when I
> deploy servlet on tomcat it can't found the ejb name.
>
> My situation is:
>
> My Platform is RedHat Linux 7.1 runs intel PIII 800
>
> My java version is 1.3.1-b24
>
> I seperate download and install jboss 2.4.3 and tomcat 4.0.1 in binary
> version. I didn't use embed tomcat in jobss solution, because that is
> not
> the really situation in industry, it is violate distributed computing
> principle.
>
> I installed and run jboss ok, I tested it by using interest examples. I
> didn't modify any deploy descriptors that included ejb-jar.xml and
> jboss.xml that mean the ejb name should be "Interesr" and jndi name
> should be "interest/Interest". The auto deploy is well, and I run the
> client
> application InterestClient to access the ejb is ok, That mean ejb
> deploy is OK.
>
> Then I follow howto "Tomcat - Jboss HOWTO V1.2" copy necassary lib to
> ${tomcat_home}/webapps/jboss/MEB_INF/lib and copy all
> run time dependent class under
> ${tomcat_home}/webapps/jboss/MEB_INF/classes. I config the servlet
> environment by modifying
> ${tomcat_home}/webapps/jboss/WEB-INF/web.xml by adding lines like
>
>
>
> java.naming.factory.initial
>
> com.sun.jndi.rmi.registry.RegistryContextFactory
>
>
>
>
> java.naming.provider.url
>
> rmi://localhost:1099
>
>
>
>
>
>InterestServlet
>
> org.jboss.docs.interest.InterestServlet
>
>
> I also modified the /conf/server.xml: by adding following
> line
>
> className="org.apache.tomcat.request.Jdk12Interceptor" />
>
> in same module, I put a servlet called snoopServlet that can figure out
> the servlet environment. after call that servlet and showed the
> environment is ok, the result like:
>
> Servlet init parameters:
>
> Context init parameters:
>java.naming.factory.initial =
> com.sun.jndi.rmi.registry.RegistryContextFactory
>java.naming.provider.url = rmi://localhost:1099
>
> Context attributes:
>javax.servlet.context.tempdir =
> /mnt/localdr/app/tomcat/jakarta-tomcat-4.0.1/work/localhost/jboss
>org.apache.catalina.resources =
> org.apache.naming.resources.ProxyDirContext@6c8909
>org.apache.catalina.WELCOME_FILES = [Ljava.lang.String;@18c56d
>org.apache.catalina.jsp_classpath =
>
>/mnt/localdr/app/tomcat/jakarta-tomcat-4.0.1/webapps/jboss/WEB-INF/classes/:/mnt/localdr/app/tomcat/jakarta-tomcat-4.0.1/webapps/jboss/WEB-INF/lib/jboss-client.jar:/mnt/localdr/app/tomcat/jakarta-tomcat-4.0.1/webapps/jboss/WEB-INF/lib/jboss-j2ee.jar:/mnt/localdr/app/tomcat/jakarta-tomcat-4.0.1/webapps/jboss/WEB-INF/lib/jbosssx-client.jar:/mnt/localdr/app/tomcat/jakarta-tomcat-4.0.1/webapps/jboss/WEB-INF/lib/jnp-client.jar:/mnt/localdr/app/tomcat/jakarta-tomcat-4.0.1/classes/:/mnt/localdr/app/tomcat/jakarta-tomcat-4.0.1/lib/jasper-runtime.jar:/mnt/localdr/app/tomcat/jakarta-tomcat-4.0.1/lib/naming-factory.jar:/mnt/localdr/app/tomcat/jakarta-tomcat-4.0.1/lib/jasper-compiler.jar:/mnt/localdr/app/tomcat/jakarta-tomcat-4.0.1/common/classes/:/mnt/localdr/app/tomcat/jakarta-tomcat-4.0.1/common/lib/activation.jar:/mnt/localdr/app/tomcat/jakarta-tomcat-4.0.1/common/lib/xerces.jar:/mnt/localdr/app/tomcat/jakarta-tomcat-4.0.1/common/lib/tyrex-0.9.7.0.jar:/mnt/localdr/app/tomcat/jakarta-tomcat-4.0.1/common/lib/jdbc2_0-stdext.jar:/mnt/localdr/app/tomcat/jakarta-tomcat-4.0.1/common/lib/servlet.jar:/mnt/localdr/app/tomcat/jakarta-tomcat-4.0.1/common/lib/mail.jar:/mnt/localdr/app/tomcat/jakarta-tomcat-4.0.1/common/lib/jta.jar:/mnt/localdr/app/tomcat/jakarta-tomcat-4.0.1/common/lib/naming-resources.jar:/mnt/localdr/app/tomcat/jakarta-tomcat-4.0.1/common/lib/naming-common.jar:/mnt/localdr/app/tomcat/jakarta-tomcat-4.0.1/common/lib/rmiregistry.jar
>
> Then I code and compile the InterestServlet that I put it in the
> attachment please find it
>
> The compile is ok. I put some debug information is code, so I can
> monito
RE: [JBoss-user] How do EJB properties work?
In your ejb-jar.xml file use the element.
example:
DTD Receiver for
SerializablePrepaedStatements
DTDReceiver
com.novalogic.ejb.DTDReceiverBean
Container
javax.jms.Topic
NonDurable
Auto-acknowledge
configUrl
java.lang.String
file:///jboss/properties/config.xml
DTDReceiver
*
NotSupported
In this file, I have included a configUrl env variable. This tells the app
server to create an environment variable that is a string called configUrl.
It is made available to all instances of the bean via the container. To
access the variable from within the bean, you look it up from your context.
example:
try {
Context myenv = (Context) initCtx.lookup("java:comp/env");
String configUrl = (String) myenv.lookup("configUrl");
} catch (Exception e) {
e.printStackTrace();
}
This is all part of the EJB spec. Check out section 20.2.
By doing it this way, you can make a specific variable accessible only to a
specific EJB class.
Hope that helps,
lucas
-Original Message-
From: Johnson, Lance [mailto:[EMAIL PROTECTED]]
Sent: Thursday, November 01, 2001 10:08 AM
To: [EMAIL PROTECTED]
Subject: [JBoss-user] How do EJB properties work?
Importance: High
Is there a way to set an EJB's properties per bean? For example, I need a
property remote.host to be per bean. This would give us the ability to hit
different remote hosts from different beans we deploy in jboss. The problem
is I don't know how to set or get this property per bean. Right now I have
placed this property in the conf/default/jboss.properties file and
retrieving it via System.getProperty("remote.host"). This has worked fine
until now, and I am sure this is not the correct place for this type of
property.
I did see an earlier post in the forum that talked about this and it said I
could use the tag inside the jboss.xml file per bean. Is this
correct? If so how do I get the property after I have set it? Do I just do
a System.getProperty() and it is automatically setup by the container?
Lance Johnson
e-mail: [EMAIL PROTECTED]
-Original Message-
From: marc fleury [mailto:[EMAIL PROTECTED]]
Sent: Thursday, November 01, 2001 10:18 AM
To: Kemp Randy-W18971; [EMAIL PROTECTED]
Subject: RE: [JBoss-user] Tomcat forum
|It was just announced that Tomcat has developed a user forum. So
|this means
|that if you have questions on Tomcat using jboss, there is another forum
|avenue available. It is also interesting they are following in the
|footsteps of Jboss with the forum avenue.
Everybody will follow in the footsteps of JBoss :)
but we are trail blazing
speed is key
marcf
|
|___
|JBoss-user mailing list
|[EMAIL PROTECTED]
|https://lists.sourceforge.net/lists/listinfo/jboss-user
___
JBoss-user mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-user
___
JBoss-user mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-user
___
JBoss-user mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-user
[JBoss-user] Books?? RE: Jboss and JRMP
Is there any online resouces or books that explain the internal of RMI (I mean implementation)? thanks ben -Original Message- From: Bill Burke [mailto:[EMAIL PROTECTED]] Sent: Monday, October 29, 2001 11:23 AM To: Ben Hui; Jboss-User@Lists. Sourceforge. Net (E-mail) Subject: RE: [JBoss-user] Jboss and JRMP JRMP is not a transport protocol. RMI is the transport protocol. If you're familiar with CORBA, JRMP is analogous to the DSI (Dynamic Skeleton Interface). The ability to swap in transport protocols is being developed on right now. Bill > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]]On Behalf Of Ben Hui > Sent: Monday, October 29, 2001 10:32 AM > To: Jboss-User@Lists. Sourceforge. Net (E-mail) > Subject: [JBoss-user] Jboss and JRMP > > > does Jboss uses JRMP as transport protocol, or does it use > another protocol? > > is it possible to swap in another transport protocol? > > thanks > > Ben Hui > > > ___ > JBoss-user mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-user > ___ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user
[JBoss-user] How do EJB properties work?
Is there a way to set an EJB's properties per bean? For example, I need a
property remote.host to be per bean. This would give us the ability to hit
different remote hosts from different beans we deploy in jboss. The problem
is I don't know how to set or get this property per bean. Right now I have
placed this property in the conf/default/jboss.properties file and
retrieving it via System.getProperty("remote.host"). This has worked fine
until now, and I am sure this is not the correct place for this type of
property.
I did see an earlier post in the forum that talked about this and it said I
could use the tag inside the jboss.xml file per bean. Is this
correct? If so how do I get the property after I have set it? Do I just do
a System.getProperty() and it is automatically setup by the container?
Lance Johnson
e-mail: [EMAIL PROTECTED]
-Original Message-
From: marc fleury [mailto:[EMAIL PROTECTED]]
Sent: Thursday, November 01, 2001 10:18 AM
To: Kemp Randy-W18971; [EMAIL PROTECTED]
Subject: RE: [JBoss-user] Tomcat forum
|It was just announced that Tomcat has developed a user forum. So
|this means
|that if you have questions on Tomcat using jboss, there is another forum
|avenue available. It is also interesting they are following in the
|footsteps of Jboss with the forum avenue.
Everybody will follow in the footsteps of JBoss :)
but we are trail blazing
speed is key
marcf
|
|___
|JBoss-user mailing list
|[EMAIL PROTECTED]
|https://lists.sourceforge.net/lists/listinfo/jboss-user
___
JBoss-user mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-user
___
JBoss-user mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-user
[JBoss-user] Mbean - looking for ppl who uses it for server in the server setup!!??
Hi, I think what happens is that the ejbserver sees that the interfaces is defined in the mbean.jar files and therefore tries to load the rest of the classes (ejbean definitions helper classes and so on) from this jar. Since it does not find them it stops... with a no classdef found exception. This is of course only what I think happens... It's quite a big project... so there's alot of helper classes, also clases that are communicated between the mbean and the ejb-sessions and entitybeans.. If you have any ideas please don't hesitate and send them to me... I'm very puzzled and that's also why we have decided to make the server external (and not spend more time on it yet). I asked on the mailing list for references of projects which uses the mbean interface in a similar way that we do, AND that do not have the problems we have. I have not heard from anyone that doesn't SPLIT up the client interface in the lib/ext together with the mbean and the ejbbean definitions in the deploy catalog. We need to have the interfaces definitions both places, on the mbean side since it's a client, and in the ejb.jar file because the session beans references the entity beans . !!! If anyone succesfully has done this, please please tell me, then I'm doing something wrong, and I will find the strength to debug it... But we have a tight schedule for beta release comming up, so unforturnally I will probably not be able to spent more time debugging it as it is right now... We can live with the external server... and when we get some more air we will look into it, and probbably code a mbean wrapper that solves our problem, so we can get the mbean into the jboss server again... /Carsten -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of David Jencks Sent: 1. november 2001 15:30 To: [EMAIL PROTECTED] Subject: Re: [JBoss-user] Mbean classloader bug ! On 2001.11.01 05:43:23 -0500 Carsten Rhod Gregersen wrote: > > >reread david's mail > > It doesn't change anything... > > It is not possible to both put the interfaces in the > lib/ext for the mbean server to see, AND in the packaging > of ejb's where the sessionbeans need it to comunicate with > the entitybeans. > > The server makes all kind's of problems when trying to do this. I haven't seen this: can you be specific about what the problems are? david jencks > > Maybe I'm doing something wrong... that's still a posibility.. > Please give me a hint ... if I am I'll gladly try anything you > mention... trust me it's not much. > > Right now, we have thrown away the mbeam approach and coded the > server to be fully external. This way everything works perfectly. > The server has now both a mainstart interface (for startup on > command line) and a mbeanstart interface. Starting it up > on the command line works perfectly, when I try to put it > to work as a mbean, the deployment of the ejbeans goes bazuka. > > If you don't think this is a bug or at all strange, that's ok. > (And that's what I hear you say right now) > I'll code my own wrapper that makes so the remote and home > interfaces in the mbean package does not conflict > with their precense in the ejb.jar package. Been there, done that. > (and it's allready been solved in the "tomcatmbean") > > But if this is a bug to be corrected, I of course will not waste > my time on such an effort... > > /Carsten > > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]]On Behalf Of marc fleury > Sent: 1. november 2001 00:24 > To: Carsten Rhod Gregersen; David Jencks; > [EMAIL PROTECTED] > Subject: RE: [JBoss-user] Mbean classloader bug ! > > > reread david's mail > > marcf > > |-Original Message- > |From: [EMAIL PROTECTED] > |[mailto:[EMAIL PROTECTED]]On Behalf Of Carsten Rhod > |Gregersen > |Sent: Wednesday, October 31, 2001 5:49 PM > |To: David Jencks; [EMAIL PROTECTED] > |Subject: RE: [JBoss-user] Mbean classloader bug ! > | > | > |Hej David, > | > |Sorry, by either I do not understand you, or I my earlier posts > |was inprecise. > | > |Yes, the mbean should be able to see the interfaces, no doubt.. > |It's a client just like anyone else... > | > |But hello... I'm not saying that you should put the implementation > |in the mbean path... I'm saying that it should be posible to > |both put the interfaces in the mbean.jar and in the ejb.jar > | > |But the problem arises if you put the interfaces in the lib/ext > |somehow together with the mbean. > | > |Jboss will then go bazuka if you also put them together with the > |ejbclasses (implementation)... And this I find to be a problem. > | > |For example sessionbeans mostly need to see the remote and home > |interface of certain entity beans. Therefore I will need to > |package an application in one way if I use some of the interfaces > |from an mbean, and another way if I dont > | > |This, I find wrong... my 2 øre :-) > | > |/Carsten > | > | > |-Original Message- > |From: [EMAIL PROTECTED] >
Re: [JBoss-user] RH Deploy Problems Continue
I checked out the latest source from CVS yesterday... The only classes I'm inheriting from are EntityBean, EJBLocalObject and EJBLocalHome... > From: Dave Smith <[EMAIL PROTECTED]> > Date: Thu, 01 Nov 2001 06:49:53 -0500 > To: Hunter Hillegas <[EMAIL PROTECTED]> > Cc: JBoss 2 <[EMAIL PROTECTED]> > Subject: Re: [JBoss-user] RH Deploy Problems Continue > > What version of RH are you running. I have you throwing an exception on > a debug line. Possibly doing inheritence and the super class does not > exsist? Return class not in class path ? > > Hunter Hillegas wrote: > >> I continue to have a problem deploying my SLSBs into rabbit-hole... >> >>> From the message it looks like it is a SLSB that is having trouble. I looked >> at the RH source code but that didn't help much. I've been through all my >> beans and I'm having a real hard time tracking it down. >> >> Also, I ran my JAR through Sun's verifier and it came out okay... >> >> Any ideas how I can figure out which bean Jboss is choking on? >> >> Here's part of the exception on the console: >> >> [15:50:00,658,ContainerFactory] Deploying PollManagerBean >> [15:50:00,664,ContainerFactory] Deploying LinkManagerBean >> [15:50:00,670,ContainerFactory] Deploying EmailBean >> [15:50:15,754,ContainerFactory] Could not deploy >> file:/Users/hunter/Desktop/jboss-3.0.0alpha/deploy/Default/ratevegas-ejb.jar >> java.lang.NoSuchMethodException >> at java.lang.Class.getMethod0(Native Method) >> at java.lang.Class.getMethod(Class.java:888) >> at >> org.jboss.ejb.StatelessSessionContainer.setUpBeanMappingImpl(StatelessSessio >> nContainer.java:447) >> at >> org.jboss.ejb.StatelessSessionContainer.setupBeanMapping(StatelessSessionCon >> tainer.java:473) >> at >> org.jboss.ejb.StatelessSessionContainer.init(StatelessSessionContainer.java: >> 157) >> >> >> >> ___ >> JBoss-user mailing list >> [EMAIL PROTECTED] >> https://lists.sourceforge.net/lists/listinfo/jboss-user >> >> > > > > ___ > JBoss-user mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-user ___ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user
RE: [JBoss-user] Tomcat forum
|It was just announced that Tomcat has developed a user forum. So |this means |that if you have questions on Tomcat using jboss, there is another forum |avenue available. It is also interesting they are following in the |footsteps of Jboss with the forum avenue. Everybody will follow in the footsteps of JBoss :) but we are trail blazing speed is key marcf | |___ |JBoss-user mailing list |[EMAIL PROTECTED] |https://lists.sourceforge.net/lists/listinfo/jboss-user ___ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user
RE: [JBoss-user] Mbean classloader bug !
|We loose the RE deployment facility because lib/ext is not dynamic. We |have to shutdown/restart Jboss to see the changes. |Does Jboss 3.0 have re-deployment facility of lib/ext classes ? yes marcf |Or is it recommended to put a "proxy" or "command" ejb between Mbean and |the EJB we want to talk to. |This EJB would never change and so does not need re-deployment. |I don't specifically see re-deployment of ejbs as a developement |facility but also as a configuration one. |Regards. |Vincent. | |> -Original Message- |> From: [EMAIL PROTECTED] |> [mailto:[EMAIL PROTECTED]] On Behalf Of |> marc fleury |> Sent: jeudi 1 novembre 2001 0:24 |> To: Carsten Rhod Gregersen; David Jencks; |> [EMAIL PROTECTED] |> Subject: RE: [JBoss-user] Mbean classloader bug ! |> |> |> reread david's mail |> |> marcf |> |> |-Original Message- |> |From: [EMAIL PROTECTED] |> |[mailto:[EMAIL PROTECTED]]On Behalf Of Carsten |> |Rhod Gregersen |> |Sent: Wednesday, October 31, 2001 5:49 PM |> |To: David Jencks; [EMAIL PROTECTED] |> |Subject: RE: [JBoss-user] Mbean classloader bug ! |> | |> | |> |Hej David, |> | |> |Sorry, by either I do not understand you, or I my earlier posts was |> |inprecise. |> | |> |Yes, the mbean should be able to see the interfaces, no |> doubt.. It's a |> |client just like anyone else... |> | |> |But hello... I'm not saying that you should put the |> implementation in |> |the mbean path... I'm saying that it should be posible to |> both put the |> |interfaces in the mbean.jar and in the ejb.jar |> | |> |But the problem arises if you put the interfaces in the |> lib/ext somehow |> |together with the mbean. |> | |> |Jboss will then go bazuka if you also put them together with the |> |ejbclasses (implementation)... And this I find to be a problem. |> | |> |For example sessionbeans mostly need to see the remote and home |> |interface of certain entity beans. Therefore I will need to |> package an |> |application in one way if I use some of the interfaces from |> an mbean, |> |and another way if I dont |> | |> |This, I find wrong... my 2 øre :-) |> | |> |/Carsten |> | |> | |> |-Original Message- |> |From: [EMAIL PROTECTED] |> |[mailto:[EMAIL PROTECTED]]On Behalf Of David |> |Jencks |> |Sent: 31. oktober 2001 23:17 |> |To: [EMAIL PROTECTED] |> |Subject: Re: [JBoss-user] Mbean classloader bug ! |> | |> | |> |This is as it should be, IMHO. the mbeans are part of the |> server, the |> |ejb interfaces are by default part of the application. Why |> should the |> |server be able to see the application classes? The |> application classes |> |can see the server classes, but not vice versa. If you want |> the server |> |to use application classes, put those in the "server |> classpath", namely |> |lib.ext |> | |> |david jencks |> | |> |On 2001.10.31 14:57:54 -0500 Carsten Rhod Gregersen wrote: |> |> Hi, |> |> |> |> From what I've heard so far, I'm pretty sure that there's |> |> a bug in the Mbean classloader. Everybody that has gotten |> mbean's to |> |> interact with the container does it via this method: |> |> |> |> 1. Put interfaces in the mbean jar files |> |> 2. Put the rest in the ejb files... |> |> |> |> This is wrong aprocedure is it not ? |> |> Normally you package both the implementation AND the |> interfaces and |> |> deploy them into the container, or ??? |> |> |> |> Still as I say, I will look into it if necesarry, but if |> |> the container is allready acting as it should (e.g. pr |> specification |> |> of mbeans), I would just be wasting my time (and we can't have |> |> that :-) |> |> |> |> My wish would be that each mbean gets it's own |> classloader, or that |> |> you at least could specify the ones that should be loaded without |> |> interfering with other lib/ext jar's or ejb packages. This way we |> |> would not get all the classloading conflicts... |> |> |> |> /Carsten |> |> |> |> -Original Message- |> |> From: [EMAIL PROTECTED] |> |> [mailto:[EMAIL PROTECTED]]On Behalf |> Of Carsten |> |> Rhod Gregersen |> |> Sent: 31. oktober 2001 17:15 |> |> To: [EMAIL PROTECTED] |> |> Subject: RE: [JBoss-user] Mbean using the home and remote beans - |> |> classloader bug in mbeans ? |> |> |> |> |> |> Hi, |> |> |> |> I actually think we can do that too... |> |> But that's a hack... isn't it ? |> |> You package ONLY the bean implementation in the |> |> ear file, and that is not correct as to the ejb |> |> standard where you have to package both the remote |> |> homes and beans together, or am I wrong ? |> |> |> |> /Carsten |> |> |> |> -Original Message- |> |> From: [EMAIL PROTECTED] |> |> [mailto:[EMAIL PROTECTED]]On Behalf |> Of Sternagel |> |> Annegret (PN-SYS/PE) |> |> Sent: 31. oktober 2001 15:05 |> |> To: [EMAIL PROTECTED] |> |> Subject: Re: [JBoss-user] Mbean using the home and remote beans - |> |> classloader bug in mbeans ? |> |> |> |> |> |> I don't know if this will help You ... |> |> |> |> We are using jboss 2.4.3 (standalone) on Windows NT / 2000 and we |>
[JBoss-user] NoClassDefFoundError - Why?
I have this very strange problem. I have an EAR file and inside that a WAR file and a JAR file. Inside the WAR file I have a lot of classes in different packages, i.e., my servlets and all the helper classes and utils. These are some files in this WAR archive: WEB-INF\classes\se\openmind\ramverk\gemensam\OMEnvironment.class WEB-INF\classes\se\openmind\ramverk\gemensam\OMServletEnvironment.class WEB-INF\classes\se\openmind\ramverk\gemensam\OMServletBase.class WEB-INF\classes\se\openmind\ramverk\util\StringUtil.class Now, in OMEnvironment.java, I have these two lines: import se.openmind.ramverk.util.*; [...] StringUtil su = new StringUtil(); [...] Everything gets compiled and deployed correctly, without any problem. However, when I try to run OMEnvironment.java from my web browser (via a servlet), the StringUtil line above generates an exception (shown below). Why is that? BTW, it seems like classes in the *same* package, e.g., se.openmind.ramverk.gemensam, can "see" each other without any problem, since the execution goes fine from OMServletBase -> OMServletEnvironment -> OMEnvironment. But when OMEnvironment tries to call StringUtil (which is in a package "above" this), it doesn't find it. Any help very much appreciated! Thanks in advance, Kristoffer 2001-11-01 04:05:23 - Ctx( /trapp ): Exception in: R( /trapp + /servlet/GOGemensam + /visaRam) - java.lang.NoClassDefFoundError: se/openmind/ramverk/util/String Util at se.openmind.ramverk.gemensam.OMEnvironment.setCurrentComponentName(OM Environment.java:447) at se.openmind.ramverk.gemensam.OMEnvironment.(OMEnvironment.java: 76) at se.openmind.ramverk.gemensam.OMEnvironment.(OMEnvironment.java: 69) at se.openmind.ramverk.gemensam.OMServletEnvironment.(OMServletEnv ironment.java:36) at se.openmind.ramverk.gemensam.OMServletBase.doHandle(OMServletBase.jav a:64) at se.openmind.ramverk.gemensam.OMServletBase.doGet(OMServletBase.java:5 2) at javax.servlet.http.HttpServlet.service(HttpServlet.java:740) at javax.servlet.http.HttpServlet.service(HttpServlet.java:853) at org.apache.tomcat.core.ServletWrapper.doService(ServletWrapper.java:4 05) at org.apache.tomcat.core.Handler.service(Handler.java:287) at org.apache.tomcat.core.ServletWrapper.service(ServletWrapper.java:372 ) at org.apache.tomcat.core.ContextManager.internalService(ContextManager. java:797) at org.apache.tomcat.core.ContextManager.service(ContextManager.java:743 ) at org.apache.tomcat.service.http.HttpConnectionHandler.processConnectio n(HttpConnectionHandler.java:213) at org.apache.tomcat.service.TcpWorkerThread.runIt(PoolTcpEndpoint.java: 416) at org.apache.tomcat.util.ThreadPool$ControlRunnable.run(ThreadPool.java :501) at java.lang.Thread.run(Unknown Source) ___ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user
[JBoss-user] Tomcat forum
It was just announced that Tomcat has developed a user forum. So this means that if you have questions on Tomcat using jboss, there is another forum avenue available. It is also interesting they are following in the footsteps of Jboss with the forum avenue. ___ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user
Re: [JBoss-user] Mbean classloader bug !
On 2001.11.01 05:43:23 -0500 Carsten Rhod Gregersen wrote: > > >reread david's mail > > It doesn't change anything... > > It is not possible to both put the interfaces in the > lib/ext for the mbean server to see, AND in the packaging > of ejb's where the sessionbeans need it to comunicate with > the entitybeans. > > The server makes all kind's of problems when trying to do this. I haven't seen this: can you be specific about what the problems are? david jencks > > Maybe I'm doing something wrong... that's still a posibility.. > Please give me a hint ... if I am I'll gladly try anything you > mention... trust me it's not much. > > Right now, we have thrown away the mbeam approach and coded the > server to be fully external. This way everything works perfectly. > The server has now both a mainstart interface (for startup on > command line) and a mbeanstart interface. Starting it up > on the command line works perfectly, when I try to put it > to work as a mbean, the deployment of the ejbeans goes bazuka. > > If you don't think this is a bug or at all strange, that's ok. > (And that's what I hear you say right now) > I'll code my own wrapper that makes so the remote and home > interfaces in the mbean package does not conflict > with their precense in the ejb.jar package. Been there, done that. > (and it's allready been solved in the "tomcatmbean") > > But if this is a bug to be corrected, I of course will not waste > my time on such an effort... > > /Carsten > > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]]On Behalf Of marc fleury > Sent: 1. november 2001 00:24 > To: Carsten Rhod Gregersen; David Jencks; > [EMAIL PROTECTED] > Subject: RE: [JBoss-user] Mbean classloader bug ! > > > reread david's mail > > marcf > > |-Original Message- > |From: [EMAIL PROTECTED] > |[mailto:[EMAIL PROTECTED]]On Behalf Of Carsten Rhod > |Gregersen > |Sent: Wednesday, October 31, 2001 5:49 PM > |To: David Jencks; [EMAIL PROTECTED] > |Subject: RE: [JBoss-user] Mbean classloader bug ! > | > | > |Hej David, > | > |Sorry, by either I do not understand you, or I my earlier posts > |was inprecise. > | > |Yes, the mbean should be able to see the interfaces, no doubt.. > |It's a client just like anyone else... > | > |But hello... I'm not saying that you should put the implementation > |in the mbean path... I'm saying that it should be posible to > |both put the interfaces in the mbean.jar and in the ejb.jar > | > |But the problem arises if you put the interfaces in the lib/ext > |somehow together with the mbean. > | > |Jboss will then go bazuka if you also put them together with the > |ejbclasses (implementation)... And this I find to be a problem. > | > |For example sessionbeans mostly need to see the remote and home > |interface of certain entity beans. Therefore I will need to > |package an application in one way if I use some of the interfaces > |from an mbean, and another way if I dont > | > |This, I find wrong... my 2 øre :-) > | > |/Carsten > | > | > |-Original Message- > |From: [EMAIL PROTECTED] > |[mailto:[EMAIL PROTECTED]]On Behalf Of David Jencks > |Sent: 31. oktober 2001 23:17 > |To: [EMAIL PROTECTED] > |Subject: Re: [JBoss-user] Mbean classloader bug ! > | > | > |This is as it should be, IMHO. the mbeans are part of the server, the > ejb > |interfaces are by default part of the application. Why should the > server > |be able to see the application classes? The application classes can see > the > |server classes, but not vice versa. If you want the server to use > |application classes, put those in the "server classpath", namely lib.ext > | > |david jencks > | > |On 2001.10.31 14:57:54 -0500 Carsten Rhod Gregersen wrote: > |> Hi, > |> > |> From what I've heard so far, I'm pretty sure that there's > |> a bug in the Mbean classloader. Everybody that has gotten > |> mbean's to interact with the container does it via this method: > |> > |> 1. Put interfaces in the mbean jar files > |> 2. Put the rest in the ejb files... > |> > |> This is wrong aprocedure is it not ? > |> Normally you package both the implementation AND the interfaces > |> and deploy them into the container, or ??? > |> > |> Still as I say, I will look into it if necesarry, but if > |> the container is allready acting as it should (e.g. pr specification > |> of mbeans), I would just be wasting my time (and we can't > |> have that :-) > |> > |> My wish would be that each mbean gets it's own classloader, > |> or that you at least could specify the ones that should be loaded > without > |> interfering with other lib/ext jar's or ejb packages. > |> This way we would not get all the classloading conflicts... > |> > |> /Carsten > |> > |> -Original Message- > |> From: [EMAIL PROTECTED] > |> [mailto:[EMAIL PROTECTED]]On Behalf Of Carsten > Rhod > |> Gregersen > |> Sent: 31. oktober 2001 17:15 > |> To: [EMAIL PROTECTED] > |> Subject: RE: [JBoss-user] Mbean using the home and remote bean
Re: [JBoss-user] Mbean classloader bug !
jboss 3 already has redeployable "lib/ext" classes (and they don't need to be there specifically). I haven't personally seen this problem with having ejb interfaces in 2 places. I do think we should have the ability to deploy mbeans as part of an application, using the application classloader: this would also solve the problem. I think to do this we will need to collapse the very similar ServiceLibrary classloader scheme and ScopedClassloader scheme into one that works for both purposes. david jencks On 2001.11.01 04:23:36 -0500 Vincent Harcq wrote: > Marc, > This is as it should be, ok. > But,... > We loose the RE deployment facility because lib/ext is not dynamic. We > have to shutdown/restart Jboss to see the changes. > Does Jboss 3.0 have re-deployment facility of lib/ext classes ? > Or is it recommended to put a "proxy" or "command" ejb between Mbean and > the EJB we want to talk to. > This EJB would never change and so does not need re-deployment. > I don't specifically see re-deployment of ejbs as a developement > facility but also as a configuration one. > Regards. > Vincent. > > > -Original Message- > > From: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED]] On Behalf Of > > marc fleury > > Sent: jeudi 1 novembre 2001 0:24 > > To: Carsten Rhod Gregersen; David Jencks; > > [EMAIL PROTECTED] > > Subject: RE: [JBoss-user] Mbean classloader bug ! > > > > > > reread david's mail > > > > marcf > > > > |-Original Message- > > |From: [EMAIL PROTECTED] > > |[mailto:[EMAIL PROTECTED]]On Behalf Of Carsten > > |Rhod Gregersen > > |Sent: Wednesday, October 31, 2001 5:49 PM > > |To: David Jencks; [EMAIL PROTECTED] > > |Subject: RE: [JBoss-user] Mbean classloader bug ! > > | > > | > > |Hej David, > > | > > |Sorry, by either I do not understand you, or I my earlier posts was > > |inprecise. > > | > > |Yes, the mbean should be able to see the interfaces, no > > doubt.. It's a > > |client just like anyone else... > > | > > |But hello... I'm not saying that you should put the > > implementation in > > |the mbean path... I'm saying that it should be posible to > > both put the > > |interfaces in the mbean.jar and in the ejb.jar > > | > > |But the problem arises if you put the interfaces in the > > lib/ext somehow > > |together with the mbean. > > | > > |Jboss will then go bazuka if you also put them together with the > > |ejbclasses (implementation)... And this I find to be a problem. > > | > > |For example sessionbeans mostly need to see the remote and home > > |interface of certain entity beans. Therefore I will need to > > package an > > |application in one way if I use some of the interfaces from > > an mbean, > > |and another way if I dont > > | > > |This, I find wrong... my 2 øre :-) > > | > > |/Carsten > > | > > | > > |-Original Message- > > |From: [EMAIL PROTECTED] > > |[mailto:[EMAIL PROTECTED]]On Behalf Of David > > |Jencks > > |Sent: 31. oktober 2001 23:17 > > |To: [EMAIL PROTECTED] > > |Subject: Re: [JBoss-user] Mbean classloader bug ! > > | > > | > > |This is as it should be, IMHO. the mbeans are part of the > > server, the > > |ejb interfaces are by default part of the application. Why > > should the > > |server be able to see the application classes? The > > application classes > > |can see the server classes, but not vice versa. If you want > > the server > > |to use application classes, put those in the "server > > classpath", namely > > |lib.ext > > | > > |david jencks > > | > > |On 2001.10.31 14:57:54 -0500 Carsten Rhod Gregersen wrote: > > |> Hi, > > |> > > |> From what I've heard so far, I'm pretty sure that there's > > |> a bug in the Mbean classloader. Everybody that has gotten > > mbean's to > > |> interact with the container does it via this method: > > |> > > |> 1. Put interfaces in the mbean jar files > > |> 2. Put the rest in the ejb files... > > |> > > |> This is wrong aprocedure is it not ? > > |> Normally you package both the implementation AND the > > interfaces and > > |> deploy them into the container, or ??? > > |> > > |> Still as I say, I will look into it if necesarry, but if > > |> the container is allready acting as it should (e.g. pr > > specification > > |> of mbeans), I would just be wasting my time (and we can't have > > |> that :-) > > |> > > |> My wish would be that each mbean gets it's own > > classloader, or that > > |> you at least could specify the ones that should be loaded without > > |> interfering with other lib/ext jar's or ejb packages. This way we > > |> would not get all the classloading conflicts... > > |> > > |> /Carsten > > |> > > |> -Original Message- > > |> From: [EMAIL PROTECTED] > > |> [mailto:[EMAIL PROTECTED]]On Behalf > > Of Carsten > > |> Rhod Gregersen > > |> Sent: 31. oktober 2001 17:15 > > |> To: [EMAIL PROTECTED] > > |> Subject: RE: [JBoss-user] Mbean using the home and remote beans - > > |> classloader bug in mbeans ? > > |> > > |> > > |> Hi, > > |>
Re: [JBoss-user] RH Deploy Problems Continue
What version of RH are you running. I have you throwing an exception on a debug line. Possibly doing inheritence and the super class does not exsist? Return class not in class path ? Hunter Hillegas wrote: > I continue to have a problem deploying my SLSBs into rabbit-hole... > >>From the message it looks like it is a SLSB that is having trouble. I looked > at the RH source code but that didn't help much. I've been through all my > beans and I'm having a real hard time tracking it down. > > Also, I ran my JAR through Sun's verifier and it came out okay... > > Any ideas how I can figure out which bean Jboss is choking on? > > Here's part of the exception on the console: > > [15:50:00,658,ContainerFactory] Deploying PollManagerBean > [15:50:00,664,ContainerFactory] Deploying LinkManagerBean > [15:50:00,670,ContainerFactory] Deploying EmailBean > [15:50:15,754,ContainerFactory] Could not deploy > file:/Users/hunter/Desktop/jboss-3.0.0alpha/deploy/Default/ratevegas-ejb.jar > java.lang.NoSuchMethodException > at java.lang.Class.getMethod0(Native Method) > at java.lang.Class.getMethod(Class.java:888) > at > org.jboss.ejb.StatelessSessionContainer.setUpBeanMappingImpl(StatelessSessio > nContainer.java:447) > at > org.jboss.ejb.StatelessSessionContainer.setupBeanMapping(StatelessSessionCon > tainer.java:473) > at > org.jboss.ejb.StatelessSessionContainer.init(StatelessSessionContainer.java: > 157) > > > > ___ > JBoss-user mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-user > > ___ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user
RE: [JBoss-user] Mbean classloader bug !
>reread david's mail It doesn't change anything... It is not possible to both put the interfaces in the lib/ext for the mbean server to see, AND in the packaging of ejb's where the sessionbeans need it to comunicate with the entitybeans. The server makes all kind's of problems when trying to do this. Maybe I'm doing something wrong... that's still a posibility.. Please give me a hint ... if I am I'll gladly try anything you mention... trust me it's not much. Right now, we have thrown away the mbeam approach and coded the server to be fully external. This way everything works perfectly. The server has now both a mainstart interface (for startup on command line) and a mbeanstart interface. Starting it up on the command line works perfectly, when I try to put it to work as a mbean, the deployment of the ejbeans goes bazuka. If you don't think this is a bug or at all strange, that's ok. (And that's what I hear you say right now) I'll code my own wrapper that makes so the remote and home interfaces in the mbean package does not conflict with their precense in the ejb.jar package. Been there, done that. (and it's allready been solved in the "tomcatmbean") But if this is a bug to be corrected, I of course will not waste my time on such an effort... /Carsten -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of marc fleury Sent: 1. november 2001 00:24 To: Carsten Rhod Gregersen; David Jencks; [EMAIL PROTECTED] Subject: RE: [JBoss-user] Mbean classloader bug ! reread david's mail marcf |-Original Message- |From: [EMAIL PROTECTED] |[mailto:[EMAIL PROTECTED]]On Behalf Of Carsten Rhod |Gregersen |Sent: Wednesday, October 31, 2001 5:49 PM |To: David Jencks; [EMAIL PROTECTED] |Subject: RE: [JBoss-user] Mbean classloader bug ! | | |Hej David, | |Sorry, by either I do not understand you, or I my earlier posts |was inprecise. | |Yes, the mbean should be able to see the interfaces, no doubt.. |It's a client just like anyone else... | |But hello... I'm not saying that you should put the implementation |in the mbean path... I'm saying that it should be posible to |both put the interfaces in the mbean.jar and in the ejb.jar | |But the problem arises if you put the interfaces in the lib/ext |somehow together with the mbean. | |Jboss will then go bazuka if you also put them together with the |ejbclasses (implementation)... And this I find to be a problem. | |For example sessionbeans mostly need to see the remote and home |interface of certain entity beans. Therefore I will need to |package an application in one way if I use some of the interfaces |from an mbean, and another way if I dont | |This, I find wrong... my 2 øre :-) | |/Carsten | | |-Original Message- |From: [EMAIL PROTECTED] |[mailto:[EMAIL PROTECTED]]On Behalf Of David Jencks |Sent: 31. oktober 2001 23:17 |To: [EMAIL PROTECTED] |Subject: Re: [JBoss-user] Mbean classloader bug ! | | |This is as it should be, IMHO. the mbeans are part of the server, the ejb |interfaces are by default part of the application. Why should the server |be able to see the application classes? The application classes can see the |server classes, but not vice versa. If you want the server to use |application classes, put those in the "server classpath", namely lib.ext | |david jencks | |On 2001.10.31 14:57:54 -0500 Carsten Rhod Gregersen wrote: |> Hi, |> |> From what I've heard so far, I'm pretty sure that there's |> a bug in the Mbean classloader. Everybody that has gotten |> mbean's to interact with the container does it via this method: |> |> 1. Put interfaces in the mbean jar files |> 2. Put the rest in the ejb files... |> |> This is wrong aprocedure is it not ? |> Normally you package both the implementation AND the interfaces |> and deploy them into the container, or ??? |> |> Still as I say, I will look into it if necesarry, but if |> the container is allready acting as it should (e.g. pr specification |> of mbeans), I would just be wasting my time (and we can't |> have that :-) |> |> My wish would be that each mbean gets it's own classloader, |> or that you at least could specify the ones that should be loaded without |> interfering with other lib/ext jar's or ejb packages. |> This way we would not get all the classloading conflicts... |> |> /Carsten |> |> -Original Message- |> From: [EMAIL PROTECTED] |> [mailto:[EMAIL PROTECTED]]On Behalf Of Carsten Rhod |> Gregersen |> Sent: 31. oktober 2001 17:15 |> To: [EMAIL PROTECTED] |> Subject: RE: [JBoss-user] Mbean using the home and remote beans - |> classloader bug in mbeans ? |> |> |> Hi, |> |> I actually think we can do that too... |> But that's a hack... isn't it ? |> You package ONLY the bean implementation in the |> ear file, and that is not correct as to the ejb |> standard where you have to package both the remote |> homes and beans together, or am I wrong ? |> |> /Carsten |> |> -Original Message- |> From: [EMAIL PROTECTED] |> [mailto:[EMAIL
[JBoss-user] Why RollBack Exception? Is it a bug of JBoss 2.4.3? Anyone help me?
An exception says as below when I called a method named getInfo():
The EJB source file is attached, and my getInfo() method just return a private
variable that's an instance of a Seriable Object used to transfer values:
like:
---
package com.lotus.mst.entity.c_order;
import javax.ejb.*;
import java.rmi.RemoteException;
import java.util.*;
import java.sql.*;
import java.io.Serializable;
import com.lotus.common.*;
import com.lotus.exception.LotusException;
/**
* @stereotype EntityBean
*/
public class C_OrderBean implements EntityBean {
final static boolean VERBOSE = false;
final static boolean DEBUG = false;
// use for method update -- system variable
private transient boolean isDirty;
private EntityContext ctx;
private C_OrderData cd = new C_OrderData();
...
public C_OrderData getInfo() throws RemoteException, LotusException {
return this.cd;
}
...
}
---
When I am calling this method in any client (JSP, SessionBean ...), JBoss always
reports the following error:
[C_OrderHome] TRANSACTION ROLLBACK EXCEPTION:try to access field
org.jboss.ejb.CacheKey.id from class org.jboss.ejb.plugins.EntityInstanceCache;
nested exception is:
java.lang.IllegalAccessError: try to access field org.jboss.ejb.CacheKey.id
from class org.jboss.ejb.plugins.EntityInstanceCache
[C_OrderHome] java.lang.IllegalAccessError: try to access field
org.jboss.ejb.CacheKey.id from class org.jboss.ejb.plugins.EntityInstanceCache
[C_OrderHome] at
org.jboss.ejb.plugins.EntityInstanceCache.setKey(EntityInstanceCache.java:92)
[C_OrderHome] at
org.jboss.ejb.plugins.AbstractInstanceCache.get(AbstractInstanceCache.java:165)
[C_OrderHome] at
org.jboss.ejb.plugins.EntityInstanceCache.get(EntityInstanceCache.java:58)
[C_OrderHome] at
org.jboss.ejb.plugins.EntityInstanceInterceptor.invoke(EntityInstanceInterceptor.java:126)
[C_OrderHome] at
org.jboss.ejb.plugins.TxInterceptorCMT.invokeNext(TxInterceptorCMT.java:133)
[C_OrderHome] at
org.jboss.ejb.plugins.TxInterceptorCMT.runWithTransactions(TxInterceptorCMT.java:263)
[C_OrderHome] at
org.jboss.ejb.plugins.TxInterceptorCMT.invoke(TxInterceptorCMT.java:99)
[C_OrderHome] at
org.jboss.ejb.plugins.SecurityInterceptor.invoke(SecurityInterceptor.java:190)
[C_OrderHome] at org.jboss.ejb.plugins.LogInterceptor.invoke(LogInterceptor.java:195)
[C_OrderHome] at org.jboss.ejb.EntityContainer.invoke(EntityContainer.java:323)
[C_OrderHome] at
org.jboss.ejb.plugins.jrmp.server.JRMPContainerInvoker.invoke(JRMPContainerInvoker.java:482)
[C_OrderHome] at
org.jboss.ejb.plugins.jrmp.interfaces.GenericProxy.invokeContainer(GenericProxy.java:335)
[C_OrderHome] at
org.jboss.ejb.plugins.jrmp.interfaces.EntityProxy.invoke(EntityProxy.java:133)
[C_OrderHome] at $Proxy97.getInfo(Unknown Source)
[C_OrderHome] at
com.lotus.mst.session.sb_c_order.SB_C_OrderBean.getRecordByCondition(SB_C_OrderBean.java:187)
[C_OrderHome] at java.lang.reflect.Method.invoke(Native Method)
[C_OrderHome] at
org.jboss.ejb.StatelessSessionContainer$ContainerInterceptor.invoke(StatelessSessionContainer.java:472)
[C_OrderHome] at
org.jboss.ejb.plugins.StatelessSessionInstanceInterceptor.invoke(StatelessSessionInstanceInterceptor.java:87)
[C_OrderHome] at
org.jboss.ejb.plugins.TxInterceptorCMT.invokeNext(TxInterceptorCMT.java:133)
[C_OrderHome] at
org.jboss.ejb.plugins.TxInterceptorCMT.runWithTransactions(TxInterceptorCMT.java:263)
[C_OrderHome] at
org.jboss.ejb.plugins.TxInterceptorCMT.invoke(TxInterceptorCMT.java:99)
[C_OrderHome] at
org.jboss.ejb.plugins.SecurityInterceptor.invoke(SecurityInterceptor.java:190)
[C_OrderHome] at org.jboss.ejb.plugins.LogInterceptor.invoke(LogInterceptor.java:195)
[C_OrderHome] at
org.jboss.ejb.StatelessSessionContainer.invoke(StatelessSessionContainer.java:271)
[C_OrderHome] at
org.jboss.ejb.plugins.jrmp.server.JRMPContainerInvoker.invoke(JRMPContainerInvoker.java:482)
[C_OrderHome] at
org.jboss.ejb.plugins.jrmp.interfaces.GenericProxy.invokeContainer(GenericProxy.java:335)
[C_OrderHome] at
org.jboss.ejb.plugins.jrmp.interfaces.StatelessSessionProxy.invoke(StatelessSessionProxy.java:123)
[C_OrderHome] at $Proxy47.getRecordByCondition(Unknown Source)
[C_OrderHome] at
order._0002forder_0002fsearchAdminOrders_0002ejspsearchAdminOrders_jsp_1.getSearchResult(_0002forder_0002fsearchAdminOrders_0002ejspsearchAdminOrders_jsp_1.java:217)
[C_OrderHome] at
order._0002forder_0002fsearchAdminOrders_0002ejspsearchAdminOrders_jsp_1._jspService(_0002forder_0002fsearchAdminOrders_0002ejspsearchAdminOrders_jsp_1.java:453)
[C_OrderHome] at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:119)
[C_OrderHome] at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
[C_OrderHome] at
org.apache.jasper.servlet.Jsp
RE: [JBoss-user] Mbean classloader bug !
Marc, This is as it should be, ok. But,... We loose the RE deployment facility because lib/ext is not dynamic. We have to shutdown/restart Jboss to see the changes. Does Jboss 3.0 have re-deployment facility of lib/ext classes ? Or is it recommended to put a "proxy" or "command" ejb between Mbean and the EJB we want to talk to. This EJB would never change and so does not need re-deployment. I don't specifically see re-deployment of ejbs as a developement facility but also as a configuration one. Regards. Vincent. > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]] On Behalf Of > marc fleury > Sent: jeudi 1 novembre 2001 0:24 > To: Carsten Rhod Gregersen; David Jencks; > [EMAIL PROTECTED] > Subject: RE: [JBoss-user] Mbean classloader bug ! > > > reread david's mail > > marcf > > |-Original Message- > |From: [EMAIL PROTECTED] > |[mailto:[EMAIL PROTECTED]]On Behalf Of Carsten > |Rhod Gregersen > |Sent: Wednesday, October 31, 2001 5:49 PM > |To: David Jencks; [EMAIL PROTECTED] > |Subject: RE: [JBoss-user] Mbean classloader bug ! > | > | > |Hej David, > | > |Sorry, by either I do not understand you, or I my earlier posts was > |inprecise. > | > |Yes, the mbean should be able to see the interfaces, no > doubt.. It's a > |client just like anyone else... > | > |But hello... I'm not saying that you should put the > implementation in > |the mbean path... I'm saying that it should be posible to > both put the > |interfaces in the mbean.jar and in the ejb.jar > | > |But the problem arises if you put the interfaces in the > lib/ext somehow > |together with the mbean. > | > |Jboss will then go bazuka if you also put them together with the > |ejbclasses (implementation)... And this I find to be a problem. > | > |For example sessionbeans mostly need to see the remote and home > |interface of certain entity beans. Therefore I will need to > package an > |application in one way if I use some of the interfaces from > an mbean, > |and another way if I dont > | > |This, I find wrong... my 2 øre :-) > | > |/Carsten > | > | > |-Original Message- > |From: [EMAIL PROTECTED] > |[mailto:[EMAIL PROTECTED]]On Behalf Of David > |Jencks > |Sent: 31. oktober 2001 23:17 > |To: [EMAIL PROTECTED] > |Subject: Re: [JBoss-user] Mbean classloader bug ! > | > | > |This is as it should be, IMHO. the mbeans are part of the > server, the > |ejb interfaces are by default part of the application. Why > should the > |server be able to see the application classes? The > application classes > |can see the server classes, but not vice versa. If you want > the server > |to use application classes, put those in the "server > classpath", namely > |lib.ext > | > |david jencks > | > |On 2001.10.31 14:57:54 -0500 Carsten Rhod Gregersen wrote: > |> Hi, > |> > |> From what I've heard so far, I'm pretty sure that there's > |> a bug in the Mbean classloader. Everybody that has gotten > mbean's to > |> interact with the container does it via this method: > |> > |> 1. Put interfaces in the mbean jar files > |> 2. Put the rest in the ejb files... > |> > |> This is wrong aprocedure is it not ? > |> Normally you package both the implementation AND the > interfaces and > |> deploy them into the container, or ??? > |> > |> Still as I say, I will look into it if necesarry, but if > |> the container is allready acting as it should (e.g. pr > specification > |> of mbeans), I would just be wasting my time (and we can't have > |> that :-) > |> > |> My wish would be that each mbean gets it's own > classloader, or that > |> you at least could specify the ones that should be loaded without > |> interfering with other lib/ext jar's or ejb packages. This way we > |> would not get all the classloading conflicts... > |> > |> /Carsten > |> > |> -Original Message- > |> From: [EMAIL PROTECTED] > |> [mailto:[EMAIL PROTECTED]]On Behalf > Of Carsten > |> Rhod Gregersen > |> Sent: 31. oktober 2001 17:15 > |> To: [EMAIL PROTECTED] > |> Subject: RE: [JBoss-user] Mbean using the home and remote beans - > |> classloader bug in mbeans ? > |> > |> > |> Hi, > |> > |> I actually think we can do that too... > |> But that's a hack... isn't it ? > |> You package ONLY the bean implementation in the > |> ear file, and that is not correct as to the ejb > |> standard where you have to package both the remote > |> homes and beans together, or am I wrong ? > |> > |> /Carsten > |> > |> -Original Message- > |> From: [EMAIL PROTECTED] > |> [mailto:[EMAIL PROTECTED]]On Behalf > Of Sternagel > |> Annegret (PN-SYS/PE) > |> Sent: 31. oktober 2001 15:05 > |> To: [EMAIL PROTECTED] > |> Subject: Re: [JBoss-user] Mbean using the home and remote beans - > |> classloader bug in mbeans ? > |> > |> > |> I don't know if this will help You ... > |> > |> We are using jboss 2.4.3 (standalone) on Windows NT / 2000 and we > |> access Stateful SessionBeans in a MBean using reflection. > We package
[JBoss-user] Why RollBack Exception? Is it a bug of JBoss 2.4.3? Anyone help me?
An exception says as below when I called a method named getInfo():
The EJB source file is attached, and my getInfo() method just return a private
variable that's an instance of a Seriable Object used to transfer values:
like:
---
package com.lotus.mst.entity.c_order;
import javax.ejb.*;
import java.rmi.RemoteException;
import java.util.*;
import java.sql.*;
import java.io.Serializable;
import com.lotus.common.*;
import com.lotus.exception.LotusException;
/**
* @stereotype EntityBean
*/
public class C_OrderBean implements EntityBean {
final static boolean VERBOSE = false;
final static boolean DEBUG = false;
// use for method update -- system variable
private transient boolean isDirty;
private EntityContext ctx;
private C_OrderData cd = new C_OrderData();
...
public C_OrderData getInfo() throws RemoteException, LotusException {
return this.cd;
}
...
}
---
When I am calling this method in any client (JSP, SessionBean ...), JBoss always
reports the following error:
[C_OrderHome] TRANSACTION ROLLBACK EXCEPTION:try to access field
org.jboss.ejb.CacheKey.id from class org.jboss.ejb.plugins.EntityInstanceCache;
nested exception is:
java.lang.IllegalAccessError: try to access field org.jboss.ejb.CacheKey.id
from class org.jboss.ejb.plugins.EntityInstanceCache
[C_OrderHome] java.lang.IllegalAccessError: try to access field
org.jboss.ejb.CacheKey.id from class org.jboss.ejb.plugins.EntityInstanceCache
[C_OrderHome] at
org.jboss.ejb.plugins.EntityInstanceCache.setKey(EntityInstanceCache.java:92)
[C_OrderHome] at
org.jboss.ejb.plugins.AbstractInstanceCache.get(AbstractInstanceCache.java:165)
[C_OrderHome] at
org.jboss.ejb.plugins.EntityInstanceCache.get(EntityInstanceCache.java:58)
[C_OrderHome] at
org.jboss.ejb.plugins.EntityInstanceInterceptor.invoke(EntityInstanceInterceptor.java:126)
[C_OrderHome] at
org.jboss.ejb.plugins.TxInterceptorCMT.invokeNext(TxInterceptorCMT.java:133)
[C_OrderHome] at
org.jboss.ejb.plugins.TxInterceptorCMT.runWithTransactions(TxInterceptorCMT.java:263)
[C_OrderHome] at
org.jboss.ejb.plugins.TxInterceptorCMT.invoke(TxInterceptorCMT.java:99)
[C_OrderHome] at
org.jboss.ejb.plugins.SecurityInterceptor.invoke(SecurityInterceptor.java:190)
[C_OrderHome] at org.jboss.ejb.plugins.LogInterceptor.invoke(LogInterceptor.java:195)
[C_OrderHome] at org.jboss.ejb.EntityContainer.invoke(EntityContainer.java:323)
[C_OrderHome] at
org.jboss.ejb.plugins.jrmp.server.JRMPContainerInvoker.invoke(JRMPContainerInvoker.java:482)
[C_OrderHome] at
org.jboss.ejb.plugins.jrmp.interfaces.GenericProxy.invokeContainer(GenericProxy.java:335)
[C_OrderHome] at
org.jboss.ejb.plugins.jrmp.interfaces.EntityProxy.invoke(EntityProxy.java:133)
[C_OrderHome] at $Proxy97.getInfo(Unknown Source)
[C_OrderHome] at
com.lotus.mst.session.sb_c_order.SB_C_OrderBean.getRecordByCondition(SB_C_OrderBean.java:187)
[C_OrderHome] at java.lang.reflect.Method.invoke(Native Method)
[C_OrderHome] at
org.jboss.ejb.StatelessSessionContainer$ContainerInterceptor.invoke(StatelessSessionContainer.java:472)
[C_OrderHome] at
org.jboss.ejb.plugins.StatelessSessionInstanceInterceptor.invoke(StatelessSessionInstanceInterceptor.java:87)
[C_OrderHome] at
org.jboss.ejb.plugins.TxInterceptorCMT.invokeNext(TxInterceptorCMT.java:133)
[C_OrderHome] at
org.jboss.ejb.plugins.TxInterceptorCMT.runWithTransactions(TxInterceptorCMT.java:263)
[C_OrderHome] at
org.jboss.ejb.plugins.TxInterceptorCMT.invoke(TxInterceptorCMT.java:99)
[C_OrderHome] at
org.jboss.ejb.plugins.SecurityInterceptor.invoke(SecurityInterceptor.java:190)
[C_OrderHome] at org.jboss.ejb.plugins.LogInterceptor.invoke(LogInterceptor.java:195)
[C_OrderHome] at
org.jboss.ejb.StatelessSessionContainer.invoke(StatelessSessionContainer.java:271)
[C_OrderHome] at
org.jboss.ejb.plugins.jrmp.server.JRMPContainerInvoker.invoke(JRMPContainerInvoker.java:482)
[C_OrderHome] at
org.jboss.ejb.plugins.jrmp.interfaces.GenericProxy.invokeContainer(GenericProxy.java:335)
[C_OrderHome] at
org.jboss.ejb.plugins.jrmp.interfaces.StatelessSessionProxy.invoke(StatelessSessionProxy.java:123)
[C_OrderHome] at $Proxy47.getRecordByCondition(Unknown Source)
[C_OrderHome] at
order._0002forder_0002fsearchAdminOrders_0002ejspsearchAdminOrders_jsp_1.getSearchResult(_0002forder_0002fsearchAdminOrders_0002ejspsearchAdminOrders_jsp_1.java:217)
[C_OrderHome] at
order._0002forder_0002fsearchAdminOrders_0002ejspsearchAdminOrders_jsp_1._jspService(_0002forder_0002fsearchAdminOrders_0002ejspsearchAdminOrders_jsp_1.java:453)
[C_OrderHome] at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:119)
[C_OrderHome] at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
[C_OrderHome] at
org.apache.jasper.servlet.Jsp
