[JBoss-dev] [ jboss-Bugs-762045 ] Cannot get EJB Home interface from Remote interface
Bugs item #762045, was opened at 2003-06-27 12:12
Message generated for change (Comment added) made by dciarnie
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=376685&aid=762045&group_id=22866
Category: JBossServer
>Group: v3.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Dan Ciarniello (dciarnie)
Assigned to: Nobody/Anonymous (nobody)
Summary: Cannot get EJB Home interface from Remote interface
Initial Comment:
One cannot get an EJB home interface from a remote
interface (using getEJBHome()) when the JNDI connection
properties are not set in the System property space.
The following code fragment illustrates the problem:
==
Properties props = new Properties();
props.setProperty(Context.INITIAL_CONTEXT_FACTORY,"org.jnp.interfaces.NamingContextFactory");
// host must be remote, not local
props.setProperty(Context.PROVIDER_URL,"remotehost:1099");
props.setProperty(Context.URL_PKG_PREFIXES,"org.jboss.naming");
InitialContext ctx = new InitialContext(props);
FooHome foohome = (FooHome)ctx.lookup("ejb/foohome");
Foo foo = foo.findByPrimaryKey(id);
EJBHome home = foo.getEJBHome();
==
The last line will fail with a
java.lang.reflect.UndeclaredThrowableException caused
by a java.net.SocketTimeoutException.
I have traced the problem to
org.jboss.proxy.ejb.GenericEJBInterceptor.getEJBHome(Invocation).
which has the line
InitialContext iniCtx = new InitialContext();
and therein lies the problem. This assumes that the
JNDI connection properties have been set in the System
property space which is not the case in the above example.
The remote interface must have explicit access to the
JNDI properties used to retrieve it in the first place.
It cannot assume that these properties have been set
in the System property space.
Note that this problem also exists in v3.2. It does
not exist in 2.4.x.
--
>Comment By: Dan Ciarniello (dciarnie)
Date: 2003-08-05 09:30
Message:
Logged In: YES
user_id=529841
Changing group to 3.2 since no one is responding to it
marked as 3.0 and it still exists in 3.2.2.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=376685&aid=762045&group_id=22866
---
This SF.Net email sponsored by: Free pre-built ASP.NET sites including
Data Reports, E-commerce, Portals, and Forums are available now.
Download today and enter to win an XBOX or Visual Studio .NET.
http://aspnet.click-url.com/go/psa0013ave/direct;at.aspnet_072303_01/01
___
JBoss-Development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-784584 ] Class-Path entry in war manifest ignored
Bugs item #784584, was opened at 2003-08-06 23:08 Message generated for change (Comment added) made by bstansberry You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=784584&group_id=22866 Category: JBossWeb Group: v3.2 Status: Open Resolution: None Priority: 5 Submitted By: Brian Stansberry (bstansberry) Assigned to: Nobody/Anonymous (nobody) Summary: Class-Path entry in war manifest ignored Initial Comment: JBoss 3.2.2RC2, with either Tomcat or Jetty, appears to ignore the Class-Path header in a war's Manifest.mf file. If an EAR includes a library jar that is only referenced via a war's Class-Path header, the jar is not loaded and the war will fail with ClassNotFoundExceptions. It appears the Class-Path header in an EJB jar is handled properly. Attached is a test case that demonstrates this. The attached zip includes an EAR, along with the source and Ant script to build the ear. The ear includes two trivial wars, each of which has a manifest Class-Path header pointing to its respective library jar. Each library jar includes a trivial ServletContextListener implementation that will be invoked when the war is loaded. There is also a trivial EJB. The ejb jar's manifest includes a Class-Path entry pointing to one of the library jar's. The EJB does not actually use the library; I just included the Class-Path entry to test if JBoss loads the jar based on the EJB's manifest. One of the wars has a web.xml reference to the EJB. The EJB is not really used by the war; the web.xml reference is just there to ensure the EJB is loaded before the war. The war associated with the EJB will load properly; the other war will fail with a ClassNotFoundException when the web container attempts to instantiate the ServletContextListener. In 3.2.1, both wars load properly. -- >Comment By: Brian Stansberry (bstansberry) Date: 2003-08-07 00:18 Message: Logged In: YES user_id=695688 To get the zip to upload I had to remove a jar with the javax.ejb and servlet classes in it. So, if you want to rebuild the test you'll have to add those to the build classpath. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=784584&group_id=22866 --- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa0013ave/direct;at.aspnet_072303_01/01 ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Problem with anonymous CVS checkout of Nukes
I don't think you are missing anything. Sourceforge have had problems with their anonymous CVS servers being overloaded for a while now. They have announced updates, and I too hope they will happen soon. Joachim - Original Message - From: "Steffen Zschaler" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Thursday, August 07, 2003 10:01 AM Subject: [JBoss-dev] Problem with anonymous CVS checkout of Nukes > Hi, > > I tried (several times already) to do a CVS CO of nukes as described in > your docs. 98 out of a 100 trials I get to see nothing but: > > cvs [update aborted]: end of file from server (consult above > messages if any) > > with no above messages to consult. The rest of the time I usually get: > > cvs [update aborted]: reading from server: Connection reset by peer > > again with no additional info. > > Every once in a while the update will get through, but it usually locks > up at some time and doesn't wake up again (I had it standing there over > night). > > What am I missing? (Please CC my mail-address, as I am not on the > mailing list) > > Regards, > > Steffen > > -- > Dipl.-Inf. Steffen Zschaler > Research Assistant > > Dresden University of Technology > Department of Computer Science > > Phone +49 351 463 38555 > Fax +49 351 463 38459 > Email [EMAIL PROTECTED] > > --- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa0013ave/direct;at.aspnet_072303_01/01 ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-784870 ] FilePersistenceManager cannot be used
Bugs item #784870, was opened at 2003-08-07 09:36 Message generated for change (Comment added) made by starksm You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=784870&group_id=22866 Category: JBossMQ Group: v3.2 >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: Srivatsan (srivatsanp) Assigned to: Nobody/Anonymous (nobody) Summary: FilePersistenceManager cannot be used Initial Comment: org.jboss.mq.pm.file.PersistenceManager does not implement org.jboss.mq.pm.CacheStore. Because of this, ClassCastException is thrown when jbossmq-service.xml is configured to use File PersistenceManager. Version JBoss3.2.1 2003-08-07 22:06:36,617 ERROR [org.jboss.mq.server.MessageCache] Starting failed java.lang.ClassCastException at org.jboss.mq.server.MessageCache.startService(MessageCache.java:432) at org.jboss.system.ServiceMBeanSupport.start(ServiceMBeanSupport.java:192) at sun.reflect.GeneratedMethodAccessor7.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBeanDispatcher.java:284) at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:549) at org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceController.java:966) at $Proxy13.start(Unknown Source) at org.jboss.system.ServiceController.start(ServiceController.java:392) at sun.reflect.GeneratedMethodAccessor6.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBeanDispatcher.java:284) at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:549) at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:177) at $Proxy5.start(Unknown Source) at org.jboss.deployment.SARDeployer.start(SARDeployer.java:226) at org.jboss.deployment.MainDeployer.start(MainDeployer.java:832) at org.jboss.deployment.MainDeployer.start(MainDeployer.java:824) at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:640) at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:613) at sun.reflect.GeneratedMethodAccessor24.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBeanDispatcher.java:284) -- >Comment By: Scott M Stark (starksm) Date: 2003-08-07 11:31 Message: Logged In: YES user_id=175228 Read the org.jboss.mq.server.MessageCache service comment: | | ATTENTION: When the "file" or "rollinglogged" Persistence Manager is used | you have to set the "CacheStore" to the CacheStore (the commented out line) | and not to the PM itself. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=784870&group_id=22866 --- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa0013ave/direct;at.aspnet_072303_01/01 ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] RE: [JBoss-user] Re: Recent CVS removals
Bill, Opinions on professionality aside, isn't forking a very expected activity in open source development? If someone can't take Open Source code and make a new (Open Source) product with it, then what is the difference between Open Source and (closed) Shared Source?[1] As long as a given fork adheres to the LGPL, what differentiates a "good" fork from a "bad" one? Or are all forks bad? FWIW, I don't have an opinion about this particular dispute, but am rather trying to learn more about the LGPL, Open Source, and your/JBoss.org's views on them. [1] Assuming, of course, that trademarks, etc. are not violated. - Matt -Original Message- From: Bill Burke [mailto:[EMAIL PROTECTED] Sent: Thu 8/7/2003 1:11 AM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: [JBoss-dev] RE: [JBoss-user] Re: Recent CVS removals > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] Behalf Of Greg Wilkins > Sent: Wednesday, August 06, 2003 8:37 PM > To: [EMAIL PROTECTED] > Cc: [EMAIL PROTECTED] > Subject: [JBoss-user] Re: Recent CVS removals > > > > Firstly a note to the list moderator: This is a request for CVS access, so > I believe that it is on topic and should not be censored. > > Bill Burke wrote: > > JBoss Group, as caretaker of the JBoss project, has recently decided to > > remove CVS access committers for a few of our committers. We > do not remove > > from CVS without good reason nor without just cause. These are > the reasons > > for the removals: > > I'll take these in reverse order: > > > 3. There is just too much conflict of interest of developers > working on two > > different J2EE projects that are being developed under two > very different > > open-source licenses. > > Surely that is for the developers or their actions to determine? Or is > this taking the Bush doctrine of pre-emptive action to it's > logical extreme? > > There are conflicts all the time in open source development - between the > day job and the project - between license types - between duplicate > projects - between competing clients both using your code - between time > developing and time to have a life etc. > The fact remains that you participated in a JBoss fork. This shows a complete lack of commitment to the JBoss project and community. You have lost the trust of the JBoss project admins. > As the author of Jetty, I have helped it be integrated with > JBoss, JOnAS and > avalon among other proprietary projects. I am serving on JSR154 and give > effort to improve all J2EE containers. I have worked with and submitted > bug reports and patches for tomcat. I frequently consult to competative > companies.I believe I have proven that I can deal with such conflicts > in a professional manner. > Participating in a fork of JBoss is not professional. You and other Jetty developers are listed as CVS developers of Elba. > JBoss has many users and JBG has many clients that they have encouraged > to use Jetty/JBoss as a stable and supported platform. JBoss is > currently > the best J2EE platform out there and I only wish to continue supporting > it - and fullfilling the implicit promise made to all JBoss users that > we will make best efforts to support our contributions. > > If you give us back our CVS access - what harm can it be? If we vandalize > the code, or become idle for a long period - then remove our access. > But we only wish to maintain our contributions and support the JBoss > community. The only reasons that I can see for removing us is so you > can make "no jboss developer" marketting claims. > Granting of CVS is a contract of trust between the project admins and yourself. You have broken this trust. You are free to submit patches through Sourceforge, but you have lost your CVS privilege. > > > 2. More importantly, we have learned that they have forked > JBoss. We also > > believe they are preparing to submit it, or some derivation, to the new > > Apache Geronimo project which would violate copyright and LGPL. > Our proof? > > > > http://sourceforge.net/projects/elba > > I'm not exactly up to speed with the full motivation for Elba, > but it is not > for submission to geronimo - nor would the ASF
[JBoss-dev] July 2003 news
Hello folks, As usual I will take the time to pitch you our new trainings and keep you update with the latest news about jboss. First let's take care of the business. TRAININGS x ATLANTA BOOTCAMP: Atlanta Boot Camp is fast approaching: Aug 16-17 in Atlanta at the Swissotel. This is a fast paced, and quite comprehensive overview of JBoss taught by the me, Scott, Bill and other US core developers. Come see the core in action in the famous "Atlanta Sessions". SYS-ADMIN: System Administration is in New York, Aug. 11-12. It is designed specially for those who administer JBoss and want to learn administration as they go to production. ADVANCED JBOSS Lastly, advanced JBoss training in Washington DC, Aug. 11-14. Learn all about the intricacies of the most downloaded app server and how to maximize your apps. IT IS ALMOST SOLD OUT SO HURRY. Contact Stephen Hobbs at 404-467-8555 ext 205, [EMAIL PROTECTED] or go to our web site for more information about training. http://www.jbossgroup.com/index.html?module=html&op=userdisplay&id=servi ces/training/index for the training schedule and registration. SERVICES Our recently announced Production Support, in addition to our Developer's support has been a best seller. Since our recent launch of the JBoss production support contract we have signed many new support customers (dev and prod) in the month of july. Some of the names are Dun and Bradstreet, Siemens, Compuware, Glaxo, Sagamore Hill Capital, a well know NYC financial firm under NDA and many more. Going to JBoss is almost routine for many IT depts. We are glad to support these fine companies in their professional usage of JBoss and we hope you are next. In addition, Unify and Librados have joined our software partner program, Unify ships fast development tools for JBoss and Librados produces a high end integration platform. Apple has given us great press coverage with their integration of JBoss in Panther (OSX) NEWS Xxxx JBoss J2EE certification effort. JBoss is increasingly used in production and as you all move to production we realize that certification brand becomes an important check mark. We have the financials to take it on, so we are. So many people have asked us where that was at and the press is having a field day with the story. It seems everyone likes drama. So there is no drama at least not anymore on our side. For all intents and purposes, JBoss has agreed to ALL the conditions imposed by SUN. It includes what for us is a hefty sum of money. They didn't give us a break, they didn't give us any break, which is kind of normal if you think about it as there are many parties involved and SUN must treat all licensees the same. In short the ball is in SUN's court and we are looking forward to inking the contract. Apache J2EE effort. First a bit of history. I offered EJBoss when it was 4 month old to Apache. The guys at Jakarta vote OK unanimously and their vote was overridden by Brian Behlendorf. The reason from behlendorf was that they 'were not the dust bin of open source projects'. I heard the Apache crowd got offended for me calling them "a bunch of fat ladies drinking tea" at a later date when they were running around telling us how to run our project. We had reports that this was the non-official reason for this "challenge". Challenge accepted. More seriously as we overtake them in corporate penetration and business model, I guess they are finally looking beyond the HTTPD C codebase and imitation is the sincerest form of flattery. We are the real thing, all we have so far is talk and announcement, announcements are a dime a dozen. Apache code on this project has yet to be released and then production reached and then maturity bla bla bla. I have little comment on the project except to say that JBOSS IS NOT A PART OF IT. In a misleading announcement Apache chairman's Greg Stein implied JBoss was participating and that JBOSS CODE WAS PART OF THE PROJECT. No current JBoss developers are participating in the Apache J2EE project and since JBoss is LGPL only full copyright holders can offer JBoss code under other licenses. Bottom line? JBoss can't be forked by apache. As our customers know, we are a business, a serious one and we seriously believe in and defend "professional open source". That includes legal protection of IP. Make no mistakes, JBoss will AGGRESIVELY defend its copyright and LGPL license. Expanded Tomcat Support. We hired Remy Maucherat the lead developer of Tomcat 5 on Monday and he will be part of our support organization in Europe. Remy was a SUN employee where he lead the TC4 development and is now on staff with JBoss Group Europe, reporting to Sacha Labourey and developing TC5 while on our watch. Moving forward Tomcat will be our default container as the market demands that support from JBoss Group. We are in a position to offer the best support for Tomcat enterprise users out there and are thrilled to continue providing a
[JBoss-dev] RE: [JBoss-user] Re: Recent CVS removals
> -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] Behalf Of Greg Wilkins > Sent: Wednesday, August 06, 2003 8:37 PM > To: [EMAIL PROTECTED] > Cc: [EMAIL PROTECTED] > Subject: [JBoss-user] Re: Recent CVS removals > > > > Firstly a note to the list moderator: This is a request for CVS access, so > I believe that it is on topic and should not be censored. > > Bill Burke wrote: > > JBoss Group, as caretaker of the JBoss project, has recently decided to > > remove CVS access committers for a few of our committers. We > do not remove > > from CVS without good reason nor without just cause. These are > the reasons > > for the removals: > > I'll take these in reverse order: > > > 3. There is just too much conflict of interest of developers > working on two > > different J2EE projects that are being developed under two > very different > > open-source licenses. > > Surely that is for the developers or their actions to determine? Or is > this taking the Bush doctrine of pre-emptive action to it's > logical extreme? > > There are conflicts all the time in open source development - between the > day job and the project - between license types - between duplicate > projects - between competing clients both using your code - between time > developing and time to have a life etc. > The fact remains that you participated in a JBoss fork. This shows a complete lack of commitment to the JBoss project and community. You have lost the trust of the JBoss project admins. > As the author of Jetty, I have helped it be integrated with > JBoss, JOnAS and > avalon among other proprietary projects. I am serving on JSR154 and give > effort to improve all J2EE containers. I have worked with and submitted > bug reports and patches for tomcat. I frequently consult to competative > companies.I believe I have proven that I can deal with such conflicts > in a professional manner. > Participating in a fork of JBoss is not professional. You and other Jetty developers are listed as CVS developers of Elba. > JBoss has many users and JBG has many clients that they have encouraged > to use Jetty/JBoss as a stable and supported platform. JBoss is > currently > the best J2EE platform out there and I only wish to continue supporting > it - and fullfilling the implicit promise made to all JBoss users that > we will make best efforts to support our contributions. > > If you give us back our CVS access - what harm can it be? If we vandalize > the code, or become idle for a long period - then remove our access. > But we only wish to maintain our contributions and support the JBoss > community. The only reasons that I can see for removing us is so you > can make "no jboss developer" marketting claims. > Granting of CVS is a contract of trust between the project admins and yourself. You have broken this trust. You are free to submit patches through Sourceforge, but you have lost your CVS privilege. > > > 2. More importantly, we have learned that they have forked > JBoss. We also > > believe they are preparing to submit it, or some derivation, to the new > > Apache Geronimo project which would violate copyright and LGPL. > Our proof? > > > > http://sourceforge.net/projects/elba > > I'm not exactly up to speed with the full motivation for Elba, > but it is not > for submission to geronimo - nor would the ASF accept it if it > was offered. > We are contacting ASF to determine what has or has not been submitted. JBoss Group will protect any infringement on copyright or LGPL. > The elba CVS is a totally legal fork of the JBoss code, which after recent > public legal threats is good to know that it can be done if needed. I > do know it was motivated by removing a private trademarc from an open > code base. > Trademark, copyright, and LGPL(or similar license) are all an open-source project has to protect itself from becoming closed source and proprietary. JBoss Group firmly believes in the spirit of LGPL and will protect against any violation. > But whatever, it's got nothing to do with JBoss nor my continuing desire > to support the project. > > > > 1. These individuals have refused to discuss design issues on > our public > > forums. It is crucial to have a public record of design > discussions so that > > others may particpate in future work. > > I have always been willing to discuss issues on jboss-dev. I, Jan, David, > Jeremy, Hiram and others have all posted to this forum recently - although > several such posts were censored. > The forums on www.jboss.org have been the designated place for design discussions since their inception over a year ago. You and your friends know this and yet made a public statement saying you would not participate in these forums. The jboss-dev list is meant only for general announcements, recruiting, and high level, random discussions. > Besides, even if we have done something to warrent our removal > from current > committers, we should not have
[JBoss-dev] [AUTOMATED] JBoss (HEAD/linux1) Test Results: 92 % ( 13 / 14 ) - come on - pull your finger out
=== ==THIS IS AN AUTOMATED EMAIL - SEE http://jboss1.kimptoc.net/ FOR DETAILS== === === JBoss daily test results SUMMARY Number of tests run: 14 Successful tests: 13 Errors:1 Failures: 0 [time of test: 2003-08-07.00-27 GMT] [java.version: 1.4.1_03] [java.vendor: Sun Microsystems Inc.] [java.vm.version: 1.4.1_03-b02] [java.vm.name: Java HotSpot(TM) Client VM] [java.vm.info: mixed mode] [os.name: Linux] [os.arch: i386] [os.version: 2.4.20-18.7] See http://jboss1.kimptoc.net/linux1/logtests/testresults/reports/html//. for the junit report of this test. NOTE: If there are any errors shown above - this mail is only highlighting them - it is NOT indicating that they are being looked at by anyone. It is assumed that whoever makes change(s) to jboss that break the test will be fixing the test or jboss, as appropriate! DETAILS OF ERRORS Suite: InvocationLogUnitTestCase Test:testClientInvocationLog(org.jboss.test.aop.test.InvocationLogUnitTestCase) Type:error Exception: java.lang.InternalError Message: Test timeout - ===Thu Aug 7 01:27:38 BST 2003 ===Linux nog 2.4.20-18.7 #1 Thu May 29 08:32:50 EDT 2003 i686 unknown ===java version "1.4.1_03" Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.1_03-b02) Java HotSpot(TM) Client VM (build 1.4.1_03-b02, mixed mode) --- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa0013ave/direct;at.aspnet_072303_01/01 ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-763378 ] housekeeping in mbean server module
Bugs item #763378, was opened at 2003-06-30 20:36 Message generated for change (Comment added) made by juhalindfors You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=763378&group_id=22866 Category: JBossMX Group: v4.0 >Status: Pending Resolution: Accepted Priority: 5 Submitted By: Rod Burgett (rodburgett) Assigned to: Juha Lindfors (juhalindfors) Summary: housekeeping in mbean server module Initial Comment: The mbean server has no clean operation, the server is never emptied or released from the mbean server factory. This constitutes a resource leak if JBoss is started (and restarted) from within a single JVM process. Unfortunately, the JMX API does not include a shutdown method for the MBeanServer interface. So cleanup must be performed outside of the JMX API, and must involve casting an MBeanServer to a specific implementation. The strategy used by this patch is to add a shutdown method to the mbean registry and mbean server implementations. The registry shutdown method is exposed through JMX, so it may be called during JBoss shutdown processing. The registry has a reference to the mbean server, so registry.shutdown can cast the server to server impl and invoke the server shutdown method. This strategy might be improved by defining a new interface that extends MBeanServer, adding the shutdown method. Then the registry impl becomes coupled to the new interface, rather than the server implementation class. On the other hand, such a generalization might be viewed as overkill until new mbean server implementations are considered. An alternative solution could reverse the shutdown method calls, so the mbean server shutdown calls the registry shutdown. This solution would require adding the registry shutdown method to the MBeanRegistry interface. And would also require whatever method invokes the server shutdown to cast it's server reference to MBeanServerImpl. I prefer the first solution because it limits the casting, and specific implementation knowledge to the registry implementation, which is more closely related to the mbean server than most other JBoss classes. It should be noted that this patch will have no effect at run-time until code elsewhere is changed to invoke the registry shutdown method. Actual invocation of these new shutdown methods is left for another patch, aimed at improving cleanup in the JBoss ServerImpl class. These patch files implement the mbean server and registry cleanup strategy. The patch file for MBeanServerImpl.java adds a new shutdown method that releases the server from it's factory, shuts down the default loader repository and clears each listener proxy. Note that attempts to invoke the loader repository shutdown method will fail until the org.jboss.mx.loading patch, #763343, is applied. A second addition to the MBeanServerImpl class adds a shutdown method to the jmx operations supported by the mbean registry mbean. MBeanServerImpl creates this MBean dynamically. The patch file for BasicMBeanRegistry.java adds a shutdown method that shuts down it's mbean server, nulls some field references and clears it's domain map container. -- >Comment By: Juha Lindfors (juhalindfors) Date: 2003-08-08 01:12 Message: Logged In: YES user_id=175239 This patch has been added modifed to the JBoss 4.0 branch (4.0 DR3). Modifications were made to handle the MBeanListenerRegistry implementation. The call sequence was reversed from MBeanServer to MBeanRegistry by adding a 'releaseRegistry' methd to MBeanRegistry interface. MBeanServer implementations that implement a 'void releaseServer' method will have that method invoked via Java reflection from the MBeanServerFactory.releaseServer() method. Any subsequent patches should use the standard JMX MBeanServerFactory.releaseMBeanServer() method to invoke the server and registry cleanup methods. I'm currently leaving this bug report to PENDING state. Depending on whether the other related patches are applied to 3.2 branch the original patch in this report should be applied as well. -- Comment By: Rod Burgett (rodburgett) Date: 2003-06-30 21:28 Message: Logged In: YES user_id=681969 Why null? Nulling the instance fields may not be required, but in this type of situation I think the GC needs all the help it can get. The MBean server/registry includes a reference to every registered mbean and each mbean holds a reference to the mbean server. Why restart? Our product embeds JBoss and permits bouncing the JBoss server without restarting the larger product. So, we can't rely on JVM destruction for memory and thread cleanup. -- Comment By: Juha Lindfors (juhalindfors) Date: 2003-06-30 21:01 Message: Logged In: YES user
[JBoss-dev] [ jboss-Bugs-784343 ] Invalid msgType Concurrency Bug?
Bugs item #784343, was opened at 2003-08-06 19:15 Message generated for change (Comment added) made by wolfftw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=784343&group_id=22866 Category: JBossMQ Group: v3.2 Status: Open Resolution: None Priority: 5 Submitted By: Todd Wolff (wolfftw) Assigned to: Adrian Brock (ejort) Summary: Invalid msgType Concurrency Bug? Initial Comment: Using 3.2.2RC3 Jetty Build, 1.4.2jdk on Windows XP Pro SP1 the attached test case causes an intermittent IllegalArgumentException: Invalid msgType error, when using the UIL2ConnectionFactory. When using the jvm IL (java:/ConnectionFactory), the process simply hangs after a few thousand messages, with no error messages. It may take a few attempts to get it to hang, and the machine should be relatively fast (roughly 100 messages per second) to duplicate the problem. The sessions are all non-transacted, the messages are non_persistent and do not expire. I don't believe I've broken any design idioms within the test case, but if so, please email me with the problem. I've spent several days trying to solve this one. See readme.txt in attached test case for test execution instructions. Thanks and let me know if you need anything else. [EMAIL PROTECTED] -- >Comment By: Todd Wolff (wolfftw) Date: 2003-08-07 13:42 Message: Logged In: YES user_id=839156 I get two different errors when using UIL2. Here's the first trace. BTW, it fails everytime unlike the jvm IL. -- Comment By: Todd Wolff (wolfftw) Date: 2003-08-07 13:39 Message: Logged In: YES user_id=839156 Here's the thread dump using the jvm il following the hang. BTW, I'm not using a multiprocessor machine. What I meant by multithreaded was multiple httpclient threads, multiple queue receivers listening on the same queue, multiple queue senders ... I had to run at least six times sending 3000 messages each time to get it to hang. My machine is a Pentium M, 1.3 ghz. It processes the 3000 messages in .489 minutes. I will follow-up with the UIL2 trace. -- Comment By: Adrian Brock (ejort) Date: 2003-08-07 09:19 Message: Logged In: YES user_id=9459 I've tried to get your testcase to crash but it is not happening for me. Probably because I don't have a multi-processor machine. When it hangs using the jvm IL, take a threaddump using ctrl-break and post the results. Alternatively, set TRACE logging for org.jboss.mq while running with UIL2 and post the log snippet for the last couple of minutes before you get the IllegalArgumentException Regards, Adrian -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=784343&group_id=22866 --- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa0013ave/direct;at.aspnet_072303_01/01 ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Problem with anonymous CVS checkout of Nukes
Hi, I tried (several times already) to do a CVS CO of nukes as described in your docs. 98 out of a 100 trials I get to see nothing but: cvs [update aborted]: end of file from server (consult above messages if any) with no above messages to consult. The rest of the time I usually get: cvs [update aborted]: reading from server: Connection reset by peer again with no additional info. Every once in a while the update will get through, but it usually locks up at some time and doesn't wake up again (I had it standing there over night). What am I missing? (Please CC my mail-address, as I am not on the mailing list) Regards, Steffen -- Dipl.-Inf. Steffen Zschaler Research Assistant Dresden University of Technology Department of Computer Science Phone +49 351 463 38555 Fax +49 351 463 38459 Email [EMAIL PROTECTED]
[JBoss-dev] Re: [JBoss-user] Recent CVS removals
On Thu, 7 Aug 2003 08:49, Bill Burke wrote: > 2. More importantly, we have learned that they have forked JBoss. We also > believe they are preparing to submit it, or some derivation, to the new > Apache Geronimo project which would violate copyright and LGPL. Our proof? > > http://sourceforge.net/projects/elba I had a look (at one randomly selected file) and it is a direct copy with the line "JBoss, the OpenSource EJB server" removed from the top. Shit. Back to the unix wars of my youth. And that is the thing that really damaged unix and gave MS an unassailable head start. --- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa0013ave/direct;at.aspnet_072303_01/01 ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
