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, > > |> > > |> 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 > > |> our Home and Remote-interfaces in a separate jar-file in > > |> jboss\lib\ext and deploy only the bean implementation and *.xml in > > |> the bean jar-file. This works fine for us. > > |> > > |> Annegret > > |> > > |> -----Ursprüngliche Nachricht----- > > |> Von: Carsten Rhod Gregersen [mailto:[EMAIL PROTECTED]] > > |> Gesendet: Mittwoch, 31. Oktober 2001 09:14 > > |> An: [EMAIL PROTECTED] > > |> Betreff: [JBoss-user] Mbean using the home and remote beans - > > |> classloader bug in mbeans ? > > |> > > |> > > |> > > |> Hi, > > |> > > |> I've asked this question before, I'll try again. > > |> > > |> The setup is: > > |> - JBoss-2.4.3_Tomcat-3.2.3.zip > > |> - JDK 1.3 > > |> - Linux Redhat 6.2 > > |> > > |> We're programming an ejb application, everythings is ok as > > regard to > > |> normal use of the EJB facilities in jboss (we have > > servlets and jsp's > > |> using the programmed ejb's) > > |> > > |> But when we're trying to incoporate a mbean based server > > within the > > |> jboss server, which should be ok regarding the documentation (?), > > |> everything goes bazuka.. > > |> > > |> The wish is to have the server listens for incomming telnet > > |> connections to a TCP/IP port, where users can do some > > command based > > |> admin stuff on the container managed beans. The mbean > > configuration, > > |> port listening, parsing, and all, works fine. The problems > > start when > > |> we try to contact the EJB server. > > |> > > |> We have alot of problems regarding classloading of the home and > > |> remote interfaces classloading within the Mbean. The classloading > > |> seems to be conflicting with the container classloading. > > |> > > |> It might be a setup problem, but I really doubt it. We're > > not new to > > |> EJB programming, but ok who's errorfree :-), and we have > > tried to set > > |> it up in all kind of ways. > > |> > > |> We have solved the problem by coding it as an external > > server... but > > |> that I find to be a temporary solution, since it's has to use RMI > > |> instead of inprocess call's. Also we have to two processes > > instead of > > |> one... alot of things can go wrong :-) > > |> > > |> Is the given usage possible ?, e.g. should I be able to > > contact beans > > |> put in the EJB server from an Mbean ? > > |> > > |> If so, has anyone managed with jboss 2.4.3 ?, > > |> > > |> If not I'll gladly debug it ... but as long as I don't > > know if it is > > |> a possible scheme I'll rather not spend time on it. > > |> > > |> > > |> mvh, > > |> Carsten Rhod Gregersen, M.Sc. CS. & Math. > > |> Email: [EMAIL PROTECTED], Tlf: 70211360 Web: http://www.logiva.dk > > |> Address: Logiva A/S, Klamsagervej 12, 8230 Åbyhøj, Denmark > > |> > > |> > > |> _______________________________________________ > > |> 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 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/j> boss-user > > > > > > _________________________________________________________ > Do You Yahoo!? > Get your free @yahoo.com address at http://mail.yahoo.com > > > _______________________________________________ > 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
