RE: [JBoss-dev] Review the coding standards => NETBEANS
Hello,
For NetBeans users, you can find attached to this e-mail two templates:
Interface and Class.
To install them:
- Find your IDE settings folder, let's call it c:\MyNBSettings
- extract the content of the zip file in the
c:\MyNBSettings\system\Templates folder => it will create a JBoss folder in
it and extract two files
- Launch NetBeans
- Open your Project from which you develop for JBoss
- Click Project=>Settings
- Select "Java Sources"
- In the right pane, select "Strings Table" and open the property editor
("...")
- Modify the USER value and add the EMAIL property (each property is on its
own line)
Now you can create interfaces/class by selecting a package, right clicking
on it and selecting "New"=>"JBoss"=>...
There is a single problem: the date format in the JavaDoc revision part is
not in the MMDD format. So you will need to correct it manually.
Cheers,
Sacha
> -Message d'origine-
> De : [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]De la part de
> Scott M Stark
> Envoyé : mercredi, 21 novembre 2001 21:35
> À : JBoss Dev
> Objet : [JBoss-dev] Review the coding standards
>
>
> The main branch code is getting screwed up again with a mixuture of
> coding styles. Review the JBoss standards and use them to avoid
> getting your code reformatted:
>
> http://www.jboss.org/developers/guide/codestyle.jsp
>
>
> Scott Stark
> Chief Technology Officer
> JBoss Group, LLC
>
>
>
> ___
> Jboss-development mailing list
> [EMAIL PROTECTED]
> https://lists.sourceforge.net/lists/listinfo/jboss-development
>
JBossTemplatesForNetBeans.zip
Description: Zip compressed data
RE: [JBoss-dev] RH: TestSuite hangs - deadlock in ClassLoader.loadClass() ???
Hi Jules, > This is a full stack dump of a reproducible hang-up in the > WebIntegration test-suite with Jetty4. > > Note the two threads which seem to be waiting on the same line of > code > > at java.lang.ClassLoader.loadClass(ClassLoader.java:286) > > This looks like a deadlock to me - has anyone else had a > similar problem > ? > > Do any of those org.jboss.system folks have any ideas - or do I put on > my debugging hat ? We talked about this some time ago, I guess you're victim of loadClassInternal... What would be interesting here is to understand which is the classloader couple that hangs, ie what are the monitor objects specified by the sentence "waiting for monitor entry", and what is the CL hierarchy at that point. Since I encountered a very similar problem in one of my projects, I wrote a small utility class that uses JDI to inspect those monitor objects, and understand who is blocking on what. Of course the problem should be reproducible (or at least should happen often :). If you think the utility class may help you I can lend it to you, just let me know. Simon ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Classloader puzzle
Hi David, Thank you very much for your response. On Wed, 21 Nov 2001, David Jencks wrote: > ... [snip] > Have you checked that poaCurrent doesn't change the context classloader and > the classloader is really what you expect when you call toObject? I think I've already checked this. But am not really sure, am I going crazy or what? I'll (re?)check it anyway. Cheers, Francisco ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Feature Requests-484550 ] Extensions to AutoDeployer
Feature Requests item #484550, was opened at 2001-11-22 05:13 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=376688&aid=484550&group_id=22866 Category: JBossServer Group: v3.0 Rabbit Hole Status: Open Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Extensions to AutoDeployer Initial Comment: Several Extensions to AutoDeployer that would aid third party integration: 1) Multiple file deployers for an extension At present AutoDeployer only stores one deployer name in the deployment class. It would be very cool if several deployer MBeans could register for the same extension, i.e. *.jar. This would allow one deployment for the jar file for different tasks. For example I'm just finishing off a full implemention of Jboss.Net, and the EJB WebService works well. However because the home and remote interfaces are loaded by the EJB server, I have to deploy a new WebService Archive containing the web-service.xml deployment descriptor and the required classes. It would be very cool if I could just add my web-service.xml deployment descriptor to the orginal Jar file and both the J2EE deloyer and my JBoss.Net engine could read the reqiured details from the file and deploy the service into there respective containers. 2) Choose based on Deployment descriptors Another way of doing the above would be to choose the deployer based on deployment descriptors, rather than the file extension. The AutoDeployer would open the archive, (or read the directory, etc), and take a list of all files names in the /META-INF/ directory. It would then ask each deployer if it understands the filename, and if so, calls the deploy function of the deployer MBean. This way the J2EE deployer would be looking for archives containing ejb-jar and JBoss.NET looking for web-services.xml. Anyway keep up the good work, HotDeployment is just the best thing EVER! -- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=376688&aid=484550&group_id=22866 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Classloader puzzle
Hi Marc, On Wed, 21 Nov 2001, marc fleury wrote: > 1- make sure the context cl is set properly (system.out its hash when you > enter the method), make sure it is the hash of the cl that created the > container (compare to the cl printouts) Will do it as soon as I get to my linux box. > 2- make sure your code uses the context cl when deserializing, it seems that > the cl that is asked for the application is the system cl and that indicates > that the io deserialization is asking the cl that loaded the system class > (the container invoker in this case). How can I ensure that deserialization will use the context CL? It seems the the jdk's deserialization code (the code in ObjectInputStream, not the one in MarshalledObject) simply ignores the context CL. But I might be wrong, I will check this again. Cheers, Francisco ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Classloader puzzle
Hi again, On Wed, 21 Nov 2001, marc fleury wrote: > BTW what is wrong with "MarshalledObject" it is just a ByteArray with proper > CL behaviour, you are going to end up rewriting this class as I read it. A problem with with the MarshalledObject solution is that it generates a much larger byte array. As this array in embedded into the bean's CORBA reference, the result is a very large IOR. (I don't know what goes into a MarshalledObject, but it appears that the codebases for a whole hierarchy of class loaders are all there.) I still have to assess the impact of these bloated IORs in the (currently bad) performance of my IIOP container invoker in the bank test. Right now there is no optimized path for local IIOP invocations. Doing all IIOP invocations "remote style" is probably the worse time-eater. After I add an optimized path for in-VM invocations (hopefully today) it should be easier to tell how bad bloated IOR are. Regards, Francisco > > marcf > > |-Original Message- > |From: marc fleury [mailto:[EMAIL PROTECTED]] > |Sent: Wednesday, November 21, 2001 11:05 PM > |To: David Jencks; [EMAIL PROTECTED] > |Subject: RE: [JBoss-dev] Classloader puzzle > | > | > |> > ||> This code is in org.jboss.ejb.plugins.iiop.server.IIOPContainerInvoker, > ||> under contrib/iiop. Insertion/extraction of the PK is done through the > ||> methods toByteArray() and toObject(). Each of these methods has two > | > |professor, > | > |rereading this, if you set the context classloader correctly then > |the MarshalledObject works from these guys hence no problem. the > |toByteArray() and toObject() needs to work with the context class loader. > | > |So > |1- make sure the context cl is set properly (system.out its hash > |when you enter the method), make sure it is the hash of the cl > |that created the container (compare to the cl printouts) > | > |2- make sure your code uses the context cl when deserializing, it > |seems that the cl that is asked for the application is the system > |cl and that indicates that the io deserialization is asking the cl > |that loaded the system class (the container invoker in this case). > | > |marcf > | > ||> implementations, one of them commented out. The commented out > ||> implementation "solves" the problem in the way described above. > ||> > ||> Suggestions are very welcome! > ||> > ||> Cheers, > ||> > ||> Francisco > ||> > ||> > ||> > ||> > ||> > ||> > ||> > ||> > ||> ___ > ||> Jboss-development mailing list > ||> [EMAIL PROTECTED] > ||> https://lists.sourceforge.net/lists/listinfo/jboss-development > ||> > ||> > || > ||___ > ||Jboss-development mailing list > ||[EMAIL PROTECTED] > ||https://lists.sourceforge.net/lists/listinfo/jboss-development > > > ___ > Jboss-development mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-development > ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Developing with JBoss
On 2001.11.22 02:34:39 -0500 Jason Dillon wrote: > This makes alot of sence, would it be hard to augment the deployer in > such a > fashion as to make the window smaller? > > --jason I think offhand this would not be so easy. I think (without having checked) that what takes the most time is constructing all the objects to support the files - mbeans, interceptors, etc. This usually starts with the mbean being created. With our current mbean naming system, this would mean the old mbean had to go away first. (same for jndi bindings -- and I dont' have a solution for them yet). At one point we discussed having versioned mbeans -- another ObjectName component version=1234. Adding this, (except for the jndi), you could have 2 deployed versions at the same time. External (to the deployed objects) ObjectName references would have to be changed into queries to get the last version. Maybe a proxy mbean could store the "deployed version" and forward to it. Anyway, this would allow old requests to finish using the old mbeans while new ones used the new deployment. After a suitable time period the old mbeans could be undeployed. david jencks > > > > What I would really like, is to see that a redeploy needs to happen, > and have > > the new file extracted into a new directory first, THEN have the old > version > > undeployed, then have the new one deployed, then have the old one > deleted. > > > > The current way things are done, there is a big window open while the > > undeployment and redeployment is happening. > > > ___ > Jboss-development mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-development > > ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] jbosscmp-jdbc.xml
I see we have Should this not be I think for a uni-directional relationship there would be only 1 role. ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Classloader puzzle
Hi, On Wed, 21 Nov 2001, marc fleury wrote: > |It sure looks like the system (Service libraries) rather than application > |classloader is being used, despite your code that clearly sets the > |contextClassLoader to the container's. > > And some people wonder why I loved having Rickard Oberg on the project back > in EJBoss 0.9 > > attached is a ObjectinputStreamWithClassLoader that rickard and monson > haefel put together one night when I ran into the same problem you did > Francisco :) > > Rickard Oberg was a fucking genius make no mistakes about it ... > > Francisco to use this you want to create the ObjectInputStream with this > puppy and pass the context cl as the parameter to the constructor. Then > call readObject as you did. This is great! > > BTw don't commit this, MarshalledObject operates pretty much the same way. I might want to discuss this... ObjectInputStreamWithClassLoader might the way of cutting down bean IOR sizes. I'll get back after I try it. Best, Francisco > > marcf > > | > |Have you checked that poaCurrent doesn't change the context classloader and > |the classloader is really what you expect when you call toObject? > | > |david jencks > | > | > |On 2001.11.21 13:04:25 -0500 Francisco Reverbel wrote: > |> Hi, > |> > |> I have a classloader problem in the IIOP container invoker code and would > |> really appreciate some helpful hints... Classloader wizards: to > |> understand > |> the problem you do not have to know anything about CORBA/IIOP, so please > |> read on! > |> > |> The problem only shows up with entity beans. When the IIOP container > |> invoker creates a CORBA reference for such a bean, it embeds the bean´s > |> primary key into the CORBA reference. When handling a bean invocation, > |> the > |> container invoker extracts the PK from the CORBA reference and passes > |> this > |> PK to the container as the first argument of a MethodInvocation. > |> > |> A ClassNotFoundException is thrown when the container invoker attempts to > |> extract the PK from the CORBA reference (got the stack trace below > |> running > |> RMH's well-known cabin bean): > |> > |> java.lang.ClassNotFoundException: com.titan.cabin.CabinPK > |>at > |org.jboss.system.ServiceLibraries.loadClass(ServiceLibraries.java:372) > |>at > |org.jboss.system.URLClassLoader.loadClass(URLClassLoader.java:111) > |>at java.lang.ClassLoader.loadClass(ClassLoader.java:253) > |>at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:313) > |>at java.lang.Class.forName0(Native Method) > |>at java.lang.Class.forName(Class.java:195) > |>at > |java.io.ObjectInputStream.resolveClass(ObjectInputStream.java:654) > |>at > |java.io.ObjectInputStream.inputClassDescriptor(ObjectInputStream.java:918) > |>at java.io.ObjectInputStream.readObject(ObjectInputStream.java:366) > |>at java.io.ObjectInputStream.readObject(ObjectInputStream.java:236) > |>at > |java.io.ObjectInputStream.inputObject(ObjectInputStream.java:1186) > |>at java.io.ObjectInputStream.readObject(ObjectInputStream.java:386) > |>at java.io.ObjectInputStream.readObject(ObjectInputStream.java:236) > |>at org.jboss.ejb.CacheKey.readExternal(CacheKey.java:118) > |>at > |java.io.ObjectInputStream.inputObject(ObjectInputStream.java:1212) > |>at java.io.ObjectInputStream.readObject(ObjectInputStream.java:386) > |>at java.io.ObjectInputStream.readObject(ObjectInputStream.java:236) > |>at > |org.jboss.ejb.plugins.iiop.server.IIOPContainerInvoker.toObject(IIO > |PContainerInvoker.java:896) > |>at > |org.jboss.ejb.plugins.iiop.server.IIOPContainerInvoker._invoke(IIOP > |ContainerInvoker.java:665) > |>at > |org.jacorb.poa.RequestProcessor.invokeOperation(RequestProcessor.java:239) > |>at > |org.jacorb.poa.RequestProcessor.process(RequestProcessor.java:456) > |>at org.jacorb.poa.RequestProcessor.run(RequestProcessor.java:581) > |> > |> I've found a way of circumventing the problem, but am not satisfied with > |> it. Things work if I wrap the PK into a MarshalledObject before embedding > |> it into the CORBA reference, and do the opposite thing when extracting > |> the > |> PK from the reference. Runs fine, but is very slow... The bank test takes > |> forever to run. > |> > |> This code is in org.jboss.ejb.plugins.iiop.server.IIOPContainerInvoker, > |> under contrib/iiop. Insertion/extraction of the PK is done through the > |> methods toByteArray() and toObject(). Each of these methods has two > |> implementations, one of them commented out. The commented out > |> implementation "solves" the problem in the way described above. > |> > |> Suggestions are very welcome! > |> > |> Cheers, > |> > |> Francisco > |> > |> > |> > |> > |> > |> > |> > |> > |> ___ > |> Jboss-development mailing list > |> [EMAIL PROTECTED] > |> https://lists.sourceforge.net/lists/listinfo/jboss-development > |> > |> > | > |__
[JBoss-dev] CVS update: build/jboss build.xml
User: d_jencks
Date: 01/11/22 10:06:46
Modified:jbossbuild.xml
Log:
Cleaned up jbosscx packaging a little. Put jbosspool.jar in jbosscx.sar
Revision ChangesPath
1.50 +3 -10 build/jboss/build.xml
Index: build.xml
===
RCS file: /cvsroot/jboss/build/jboss/build.xml,v
retrieving revision 1.49
retrieving revision 1.50
diff -u -r1.49 -r1.50
--- build.xml 2001/11/19 15:34:04 1.49
+++ build.xml 2001/11/22 18:06:45 1.50
@@ -10,7 +10,7 @@
-
+
@@ -1000,20 +1000,13 @@
value="${project.root}/${_module.name}/output"/>
-
+
+
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jboss/src/etc/conf/default j2eedeployment-service.xml
User: d_jencks Date: 01/11/22 10:06:46 Modified:src/etc/conf/default j2eedeployment-service.xml Log: Cleaned up jbosscx packaging a little. Put jbosspool.jar in jbosscx.sar Revision ChangesPath 1.8 +0 -8 jboss/src/etc/conf/default/j2eedeployment-service.xml Index: j2eedeployment-service.xml === RCS file: /cvsroot/jboss/jboss/src/etc/conf/default/j2eedeployment-service.xml,v retrieving revision 1.7 retrieving revision 1.8 diff -u -r1.7 -r1.8 --- j2eedeployment-service.xml2001/11/12 06:36:50 1.7 +++ j2eedeployment-service.xml2001/11/22 18:06:46 1.8 @@ -40,12 +40,4 @@ JBOSS-SYSTEM:service=ServiceDeployer --> - - - - - - - ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jbosscx/src/resources/jca-sar/META-INF jboss-service.xml
User: d_jencks Date: 01/11/22 10:06:46 Modified:src/resources/jca-sar/META-INF jboss-service.xml Log: Cleaned up jbosscx packaging a little. Put jbosspool.jar in jbosscx.sar Revision ChangesPath 1.4 +6 -4 jbosscx/src/resources/jca-sar/META-INF/jboss-service.xml Index: jboss-service.xml === RCS file: /cvsroot/jboss/jbosscx/src/resources/jca-sar/META-INF/jboss-service.xml,v retrieving revision 1.3 retrieving revision 1.4 diff -u -r1.3 -r1.4 --- jboss-service.xml 2001/09/12 23:06:52 1.3 +++ jboss-service.xml 2001/11/22 18:06:46 1.4 @@ -7,7 +7,7 @@ - + - + + +
[JBoss-dev] CVS update: jbosscx build.xml
User: d_jencks Date: 01/11/22 10:06:46 Modified:.build.xml Log: Cleaned up jbosscx packaging a little. Put jbosspool.jar in jbosscx.sar Revision ChangesPath 1.15 +7 -3 jbosscx/build.xml Index: build.xml === RCS file: /cvsroot/jboss/jbosscx/build.xml,v retrieving revision 1.14 retrieving revision 1.15 diff -u -r1.14 -r1.15 --- build.xml 2001/11/10 21:38:03 1.14 +++ build.xml 2001/11/22 18:06:46 1.15 @@ -10,7 +10,7 @@ - + @@ -347,16 +347,17 @@ - + + @@ -364,6 +365,9 @@ + + + ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: thirdparty/mortbay/jetty/lib org.mortbay.jetty.jar
User: jules_gosnell Date: 01/11/22 17:57:37 Modified:mortbay/jetty/lib org.mortbay.jetty.jar Log: update Jetty binary Revision ChangesPath 1.4 +76 -86thirdparty/mortbay/jetty/lib/org.mortbay.jetty.jar <> ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: contrib/jetty/src/main/org/jboss/jetty JBossWebApplicationContext.java
User: jules_gosnell
Date: 01/11/22 18:01:29
Modified:jetty/src/main/org/jboss/jetty
JBossWebApplicationContext.java
Log:
tidy up a little
Revision ChangesPath
1.2 +37 -31
contrib/jetty/src/main/org/jboss/jetty/JBossWebApplicationContext.java
Index: JBossWebApplicationContext.java
===
RCS file:
/cvsroot/jboss/contrib/jetty/src/main/org/jboss/jetty/JBossWebApplicationContext.java,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- JBossWebApplicationContext.java 2001/11/21 23:13:01 1.1
+++ JBossWebApplicationContext.java 2001/11/23 02:01:29 1.2
@@ -5,7 +5,7 @@
* See terms of license at gnu.org.
*/
-// $Id: JBossWebApplicationContext.java,v 1.1 2001/11/21 23:13:01 jules_gosnell Exp
$
+// $Id: JBossWebApplicationContext.java,v 1.2 2001/11/23 02:01:29 jules_gosnell Exp
$
// A Jetty HttpServer with the interface expected by JBoss'
// J2EEDeployer...
@@ -112,22 +112,20 @@
if (cl==null)
_log.warn("WARNING: WebApp Context's ClassLoader is of incorrect
descent:"+loader);
- else
- _log.info("WebApp Context's ClassLoader is of correct descent:"+loader);
+ // else
+ //_log.info("WebApp Context's ClassLoader is of correct
descent:"+loader);
}
// Parse descriptors and set up the JNDI environment
Element webAppDD = _webApp.getWebApp();
Element jbossDD = _webApp.getJbossWeb();
_descriptorParser.parseWebAppDescriptors(loader, webAppDD, jbossDD);
- _log.info("WebApp Descriptors parsed");
// Add the JBoss security realm
String realmName = getRealm();
if (realmName!=null)
{
- _log.info("WebApp Realm initialised");
- // these need to be cached and reused by name... - TODO
+ // these need to be cached and reused by name...MAYBE - TODO
getHttpContext().getHttpServer().addRealm(new JBossUserRealm(realmName));
}
@@ -157,7 +155,7 @@
return securityHandler;
}
- // avoid Jetty maoning about things that it doesn't bu AbstractWebContainer does
do...
+ // avoid Jetty maoning about things that it doesn't but AbstractWebContainer does
do...
protected void
initWebXmlElement(String element, org.mortbay.xml.XmlParser.Node node)
@@ -175,16 +173,19 @@
super.initWebXmlElement(element, node);
}
- //--debugging
+// public boolean
+// handle(org.mortbay.http.HttpRequest request, org.mortbay.http.HttpResponse
response)
+// throws org.mortbay.http.HttpException, java.io.IOException
+// {
+// Thread.currentThread().setContextClassLoader(getClassLoader());
+// return super.handle(request, response);
+// }
+
+ // hack our class loader to be Java2 compliant - i.e. always
+ // delegate upwards before looking locally. This will be changed to
+ // a non-compliant strategy later when JBoss' new ClassLoader is
+ // ready.
- public boolean
-handle(org.mortbay.http.HttpRequest request, org.mortbay.http.HttpResponse
response)
-throws org.mortbay.http.HttpException, java.io.IOException
-{
- Thread.currentThread().setContextClassLoader(getClassLoader());
- return super.handle(request, response);
-}
-
protected void initClassLoader()
throws java.net.MalformedURLException, java.io.IOException
{
@@ -195,6 +196,9 @@
((org.mortbay.http.ContextLoader)_loader).setJava2Compliant(true);
}
+ // copy our superclass' version of this, but ensure that servlet
+ // api and jasper jars are appended to it...
+
public String getFileClassPath()
throws IllegalStateException
{
@@ -210,11 +214,9 @@
try
{
- String dtd="javax/servlet/resources/web-app_2_3.dtd";
- String path=getClass().getClassLoader().getResource(dtd).toString();
- String jarPath=path.substring(0,path.length()-(dtd.length()+2)); // lose final
'!/class...'
- jarPath=jarPath.substring("jar:file:".length(),jarPath.length());
- fileClassPath+=jarPath;
+ String jar=findJarByResource("javax/servlet/resources/web-app_2_3.dtd");
+ //
jar="/home/jules/cvs/JBoss/3.0/thirdparty/mortbay/jetty/lib/javax.servlet.jar";
+ fileClassPath+=jar;
}
catch (Exception e)
{
@@ -223,22 +225,26 @@
try
{
- String dtd="org/apache/jasper/resources/jsp12.dtd";
- String path=getClass().getClassLoader().getResource(dtd).toString();
- String jarPath=path.substring(0,path.length()-(dtd.length()+2)); // lose final
'!/class...'
- jarPath=jarPath.substring("jar:file:".length(),jarPath.length());
- fil
RE: [JBoss-dev] Classloader puzzle
|A problem with with the MarshalledObject solution is that it generates a |much larger byte array. As this array in embedded into the bean's CORBA |reference, the result is a very large IOR. (I don't know what goes into |a MarshalledObject, but it appears that the codebases for a whole hierarchy |of class loaders are all there.) Interesting, I will have to look at the stuff that gets serialized there. We do have the deserializing classloaders right here, so I guess that the code I gave you (the rickard code) will work just fine. |I still have to assess the impact of these bloated IORs in the (currently |bad) performance of my IIOP container invoker in the bank test. Right now Obviously the more bloated the byte array the more work and time is spent in the deserialization stacks. Just fyi, the optimized contaienr (no invocation stack) runs at 0.05ms on standard machines when you add the container you can go up to 0.5ms which means that 90% of the time is spent on the invocation stacks. Optimize that stack and you are gaining a lot of performance. Can we get solid data on the byte[] versus MO times? |there is no optimized path for local IIOP invocations. Doing all IIOP |invocations "remote style" is probably the worse time-eater. After I add |an optimized path for in-VM invocations (hopefully today) it should be |easier to tell how bad bloated IOR are. See the times above, a factor of 10, the point you made that MO tends to be a pig is interesting, I need to know whether it is real. marcf | |Regards, | |Francisco | |> |> marcf |> |> |-Original Message- |> |From: marc fleury [mailto:[EMAIL PROTECTED]] |> |Sent: Wednesday, November 21, 2001 11:05 PM |> |To: David Jencks; [EMAIL PROTECTED] |> |Subject: RE: [JBoss-dev] Classloader puzzle |> | |> | |> |> |> ||> This code is in |org.jboss.ejb.plugins.iiop.server.IIOPContainerInvoker, |> ||> under contrib/iiop. Insertion/extraction of the PK is done |through the |> ||> methods toByteArray() and toObject(). Each of these methods has two |> | |> |professor, |> | |> |rereading this, if you set the context classloader correctly then |> |the MarshalledObject works from these guys hence no problem. the |> |toByteArray() and toObject() needs to work with the context |class loader. |> | |> |So |> |1- make sure the context cl is set properly (system.out its hash |> |when you enter the method), make sure it is the hash of the cl |> |that created the container (compare to the cl printouts) |> | |> |2- make sure your code uses the context cl when deserializing, it |> |seems that the cl that is asked for the application is the system |> |cl and that indicates that the io deserialization is asking the cl |> |that loaded the system class (the container invoker in this case). |> | |> |marcf |> | |> ||> implementations, one of them commented out. The commented out |> ||> implementation "solves" the problem in the way described above. |> ||> |> ||> Suggestions are very welcome! |> ||> |> ||> Cheers, |> ||> |> ||> Francisco |> ||> |> ||> |> ||> |> ||> |> ||> |> ||> |> ||> |> ||> |> ||> ___ |> ||> Jboss-development mailing list |> ||> [EMAIL PROTECTED] |> ||> https://lists.sourceforge.net/lists/listinfo/jboss-development |> ||> |> ||> |> || |> ||___ |> ||Jboss-development mailing list |> ||[EMAIL PROTECTED] |> ||https://lists.sourceforge.net/lists/listinfo/jboss-development |> |> |> ___ |> Jboss-development mailing list |> [EMAIL PROTECTED] |> https://lists.sourceforge.net/lists/listinfo/jboss-development |> | | |___ |Jboss-development mailing list |[EMAIL PROTECTED] |https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Classloader puzzle
I am eagerly waiting for solid data on this. We need many datapoints: from no parameter and void in return, up to 10,000k in parameter 10,000k in return and many points in between, average time on byte[] vs MO there. mo.get() seems to be a very very expensive operation (for some reason). marcf |-Original Message- |From: Francisco Reverbel [mailto:[EMAIL PROTECTED]] |Sent: Thursday, November 22, 2001 9:26 AM |To: marc fleury |Cc: David Jencks; [EMAIL PROTECTED] |Subject: RE: [JBoss-dev] Classloader puzzle | | |Hi, | |On Wed, 21 Nov 2001, marc fleury wrote: | |> |It sure looks like the system (Service libraries) rather than |application |> |classloader is being used, despite your code that clearly sets the |> |contextClassLoader to the container's. |> |> And some people wonder why I loved having Rickard Oberg on the |project back |> in EJBoss 0.9 |> |> attached is a ObjectinputStreamWithClassLoader that rickard and monson |> haefel put together one night when I ran into the same problem you did |> Francisco :) |> |> Rickard Oberg was a fucking genius make no mistakes about it ... |> |> Francisco to use this you want to create the ObjectInputStream with this |> puppy and pass the context cl as the parameter to the constructor. Then |> call readObject as you did. | |This is great! | |> |> BTw don't commit this, MarshalledObject operates pretty much the |same way. | |I might want to discuss this... ObjectInputStreamWithClassLoader might the |way of cutting down bean IOR sizes. I'll get back after I try it. | |Best, | |Francisco | |> |> marcf |> |> | |> |Have you checked that poaCurrent doesn't change the context |classloader and |> |the classloader is really what you expect when you call toObject? |> | |> |david jencks |> | |> | |> |On 2001.11.21 13:04:25 -0500 Francisco Reverbel wrote: |> |> Hi, |> |> |> |> I have a classloader problem in the IIOP container invoker |code and would |> |> really appreciate some helpful hints... Classloader wizards: to |> |> understand |> |> the problem you do not have to know anything about |CORBA/IIOP, so please |> |> read on! |> |> |> |> The problem only shows up with entity beans. When the IIOP container |> |> invoker creates a CORBA reference for such a bean, it embeds |the bean´s |> |> primary key into the CORBA reference. When handling a bean invocation, |> |> the |> |> container invoker extracts the PK from the CORBA reference and passes |> |> this |> |> PK to the container as the first argument of a MethodInvocation. |> |> |> |> A ClassNotFoundException is thrown when the container invoker |attempts to |> |> extract the PK from the CORBA reference (got the stack trace below |> |> running |> |> RMH's well-known cabin bean): |> |> |> |> java.lang.ClassNotFoundException: com.titan.cabin.CabinPK |> |> at |> |org.jboss.system.ServiceLibraries.loadClass(ServiceLibraries.java:372) |> |> at |> |org.jboss.system.URLClassLoader.loadClass(URLClassLoader.java:111) |> |> at java.lang.ClassLoader.loadClass(ClassLoader.java:253) |> |> at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:313) |> |> at java.lang.Class.forName0(Native Method) |> |> at java.lang.Class.forName(Class.java:195) |> |> at |> |java.io.ObjectInputStream.resolveClass(ObjectInputStream.java:654) |> |> at |> ||java.io.ObjectInputStream.inputClassDescriptor(ObjectInputStream.java:918) |> |> at java.io.ObjectInputStream.readObject(ObjectInputStream.java:366) |> |> at java.io.ObjectInputStream.readObject(ObjectInputStream.java:236) |> |> at |> |java.io.ObjectInputStream.inputObject(ObjectInputStream.java:1186) |> |> at java.io.ObjectInputStream.readObject(ObjectInputStream.java:386) |> |> at java.io.ObjectInputStream.readObject(ObjectInputStream.java:236) |> |> at org.jboss.ejb.CacheKey.readExternal(CacheKey.java:118) |> |> at |> |java.io.ObjectInputStream.inputObject(ObjectInputStream.java:1212) |> |> at java.io.ObjectInputStream.readObject(ObjectInputStream.java:386) |> |> at java.io.ObjectInputStream.readObject(ObjectInputStream.java:236) |> |> at |> |org.jboss.ejb.plugins.iiop.server.IIOPContainerInvoker.toObject(IIO |> |PContainerInvoker.java:896) |> |> at |> |org.jboss.ejb.plugins.iiop.server.IIOPContainerInvoker._invoke(IIOP |> |ContainerInvoker.java:665) |> |> at |> ||org.jacorb.poa.RequestProcessor.invokeOperation(RequestProcessor.java:239) |> |> at |> |org.jacorb.poa.RequestProcessor.process(RequestProcessor.java:456) |> |> at org.jacorb.poa.RequestProcessor.run(RequestProcessor.java:581) |> |> |> |> I've found a way of circumventing the problem, but am not |satisfied with |> |> it. Things work if I wrap the PK into a MarshalledObject |before embedding |> |> it into the CORBA reference, and do the opposite thing when extracting |> |> the |> |> PK from the reference. Runs fine, but is very slow... The |bank test takes |> |> forever to run. |> |> |> |> This code is in |org.jboss.ejb.plugins.iiop.server.IIOPContainerInvoker, |> |> under contrib/iio
[JBoss-dev] Automated JBoss Testsuite Results
JBoss daily test results SUMMARY Number of tests run: 177 Successful tests: 148 Errors:16 Failures: 13 [time of test: 23 November 2001 3:12 GMT] [java.version: 1.3.0] [java.vendor: IBM Corporation] [java.vm.version: 1.3.0] [java.vm.name: Classic VM] [java.vm.info: J2RE 1.3.0 IBM build cx130-20010626 (JIT enabled: jitc)] [os.name: Linux] [os.arch: x86] [os.version: 2.4.9-12] See http://lubega.com for full details 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 [details not shown - as this makes the mail too big to reach the sf mailing list] PS BEFORE you commit, run the test suite. Its easy, just run the target 'run-basic-testsuite' from the main build.xml. PPS Come on people - there were a few days back in July 2001 when we had ZERO tests failing! Oh, and thanks - remember we love you too! ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Automated JBoss Testsuite Results
JBoss daily test results SUMMARY Number of tests run: 177 Successful tests: 150 Errors:15 Failures: 12 [time of test: 23 November 2001 3:57 GMT] [java.version: 1.3.1] [java.vendor: Blackdown Java-Linux Team] [java.vm.version: Blackdown-1.3.1-FCS] [java.vm.name: Java HotSpot(TM) Client VM] [java.vm.info: mixed mode] [os.name: Linux] [os.arch: i386] [os.version: 2.4.9-12] See http://lubega.com for full details 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 [details not shown - as this makes the mail too big to reach the sf mailing list] PS BEFORE you commit, run the test suite. Its easy, just run the target 'run-basic-testsuite' from the main build.xml. PPS Come on people - there were a few days back in July 2001 when we had ZERO tests failing! Oh, and thanks - remember we love you too! ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-424768 ] prepareStatement parameters
Bugs item #424768, was opened at 2001-05-17 00:29
You can respond by visiting:
http://sourceforge.net/tracker/?func=detail&atid=376685&aid=424768&group_id=22866
Category: JBossServer
Group: v2.2.1 (stable)
Status: Closed
Resolution: Fixed
Priority: 5
Submitted By: Oscar Radio Pina (oradio)
Assigned to: Andreas Schaefer (schaefera)
Summary: prepareStatement parameters
Initial Comment:
When you try to set ResultSet.TYPE_SCROLL_INSENSITIVE,
ResultSet.CONCUR_READ_ONLY properties to a
PreparedStatemt object, it doesn't works. The
following code shows the bug:
prepareStatement = con.prepareStatement
(this.stringSQL, ResultSet.TYPE_SCROLL_INSENSITIVE,
ResultSet.CONCUR_READ_ONLY);
if (prepareStatement.getResultSetType() ==
java.sql.ResultSet.TYPE_SCROLL_INSENSITIVE)
{
System.out.println
("TYPE_SCROLL_INSENSITIVE");
}
else
{
System.out.println("not
TYPE_SCROLL_INSENSITIVE");
}
Output results:
jboss2.0: TYPE_SCROLL_INSENSITIVE
jboss2.2.1: not TYPE_SCROLL_INSENSITIVE
The same code using a Statement instead of a
PreparedStatemt works. I find this code in the
jbosspool:
In the org.jboss.pool.jdbc.xa.XAClientConnection class:
public Statement createStatement(int
resultSetType, int resultSetConcurrency) throws
SQLException {
if(con == null) throw new SQLException(CLOSED);
try {
StatementInPool st = new StatementInPool
(con.createStatement(resultSetType,
resultSetConcurrency), this);
statements.add(st);
return st;
} catch(SQLException e) {
setError(e);
throw e;
}
}
public PreparedStatement prepareStatement(String
sql, int resultSetType, int resultSetConcurrency)
throws SQLException {
return prepareStatement(sql);
}
public PreparedStatement prepareStatement(String
sql) throws SQLException {
if(con == null) throw new SQLException(CLOSED);
try {
PreparedStatement ps = (PreparedStatement)
preparedStatementCache.useObject(sql);
if(ps == null)
throw new SQLException("Unable to
create PreparedStatement!");
PreparedStatementInPool wrapper = new
PreparedStatementInPool(ps, this, sql);
statements.add(wrapper);
return wrapper;
} catch(SQLException e) {
setError(e);
throw e;
}
}
So when you call the constructor of the class with the
three parameters it calls the constructor only with
one parameter the SQL string. But the same code using
createStatement works.
I'm using JBoss 2.2.1 JVM 1.3, win2k
The category I choose is JBoss if this bug it is of
other category please tell me and I will change it.
--
Comment By: David Jencks (d_jencks)
Date: 2001-11-22 21:14
Message:
Logged In: YES
user_id=60525
The cure is worse than the disease. This makes it
impossible to use jboss with any jdbc 1 driver or one that
does not support prepareStatement(String sql, int, i, int
j). I'll fix it.
--
You can respond by visiting:
http://sourceforge.net/tracker/?func=detail&atid=376685&aid=424768&group_id=22866
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Automated JBoss Testsuite Results
JBoss daily test results SUMMARY Number of tests run: 162 Successful tests: 137 Errors:13 Failures: 12 [time of test: 23 November 2001 5:22 GMT] [java.version: 1.3.1] [java.vendor: Blackdown Java-Linux Team] [java.vm.version: Blackdown-1.3.1-FCS] [java.vm.name: Classic VM] [java.vm.info: green threads, nojit] [os.name: Linux] [os.arch: i386] [os.version: 2.4.9-12] See http://lubega.com for full details 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 [details not shown - as this makes the mail too big to reach the sf mailing list] PS BEFORE you commit, run the test suite. Its easy, just run the target 'run-basic-testsuite' from the main build.xml. PPS Come on people - there were a few days back in July 2001 when we had ZERO tests failing! Oh, and thanks - remember we love you too! ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jbosscx/src/main/org/jboss/resource/adapter/jdbc/local ConnectionInPool.java PSCacheKey.java
User: d_jencks
Date: 01/11/22 21:54:56
Modified:src/main/org/jboss/resource/adapter/jdbc/local
ConnectionInPool.java PSCacheKey.java
Log:
refixed bug 424768 so it doesn't prevent usage of jboss with jdbc 1 drivers
Revision ChangesPath
1.3 +3 -1
jbosscx/src/main/org/jboss/resource/adapter/jdbc/local/ConnectionInPool.java
Index: ConnectionInPool.java
===
RCS file:
/cvsroot/jboss/jbosscx/src/main/org/jboss/resource/adapter/jdbc/local/ConnectionInPool.java,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- ConnectionInPool.java 2001/11/04 06:56:18 1.2
+++ ConnectionInPool.java 2001/11/23 05:54:55 1.3
@@ -650,7 +650,9 @@
else
{
wrapper = new PreparedStatementInPool(
- con.prepareStatement( pKey.sql, pKey.rsType, pKey.rsConcur ),
+ (pKey.jdbc1Flag) ?
+ con.prepareStatement(pKey.sql)
+ : con.prepareStatement( pKey.sql, pKey.rsType, pKey.rsConcur ),
this,
pKey.sql
);
1.2 +12 -6
jbosscx/src/main/org/jboss/resource/adapter/jdbc/local/PSCacheKey.java
Index: PSCacheKey.java
===
RCS file:
/cvsroot/jboss/jbosscx/src/main/org/jboss/resource/adapter/jdbc/local/PSCacheKey.java,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- PSCacheKey.java 2001/09/08 19:32:20 1.1
+++ PSCacheKey.java 2001/11/23 05:54:55 1.2
@@ -25,12 +25,14 @@
/**
* Description of the Field
*/
- public int rsType;
+ public int rsType = -1; //illegal value
/**
* Description of the Field
*/
- public int rsConcur;
+ public int rsConcur = -1; //illegal value
+ public boolean jdbc1Flag;
+
/**
* Constructor for the PSCacheKey object
*
@@ -41,8 +43,9 @@
{
this.con = con;
this.sql = sql;
- this.rsType = ResultSet.TYPE_FORWARD_ONLY;
- this.rsConcur = ResultSet.CONCUR_READ_ONLY;
+ jdbc1Flag = true;
+ //this.rsType = ResultSet.TYPE_FORWARD_ONLY;
+ //this.rsConcur = ResultSet.CONCUR_READ_ONLY;
}
/**
@@ -59,6 +62,7 @@
this.sql = sql;
this.rsType = rsType;
this.rsConcur = rsConcur;
+ jdbc1Flag = false;
}
/**
@@ -71,7 +75,8 @@
{
PSCacheKey key = (PSCacheKey)o;
return key.con.equals(con) && key.sql.equals(sql) &&
-key.rsType == rsType && key.rsConcur == rsConcur;
+key.rsType == rsType && key.rsConcur == rsConcur &&
+ key.jdbc1Flag == jdbc1Flag;
}
/**
@@ -81,6 +86,7 @@
*/
public int hashCode()
{
- return con.hashCode() ^ sql.hashCode() ^ rsType ^ rsConcur;
+ return con.hashCode() ^ sql.hashCode() ^ rsType ^ rsConcur
+ ^ (jdbc1Flag ? 1:2);
}
}
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jboss/src/main/org/jboss/deployment J2eeDeployer.java
User: schaefera
Date: 01/11/22 22:20:12
Modified:src/main/org/jboss/deployment J2eeDeployer.java
Log:
First added the J2EEApplication to JSR-77.
Revision ChangesPath
1.45 +11 -1 jboss/src/main/org/jboss/deployment/J2eeDeployer.java
Index: J2eeDeployer.java
===
RCS file: /cvsroot/jboss/jboss/src/main/org/jboss/deployment/J2eeDeployer.java,v
retrieving revision 1.44
retrieving revision 1.45
diff -u -r1.44 -r1.45
--- J2eeDeployer.java 2001/11/12 06:52:16 1.44
+++ J2eeDeployer.java 2001/11/23 06:20:12 1.45
@@ -49,6 +49,9 @@
import org.jboss.ejb.DeploymentException;
import org.jboss.ejb.ContainerFactoryMBean;
+import org.jboss.management.j2ee.J2EEApplication;
+import org.jboss.management.j2ee.J2EEManagedObject;
+
import org.w3c.dom.Document;
import org.w3c.dom.Element;
@@ -72,7 +75,7 @@
* @author mailto:[EMAIL PROTECTED]";>Toby Allsopp
* @author mailto:[EMAIL PROTECTED]";>Scott Stark.
* @author mailto:[EMAIL PROTECTED]";>Christoph G. Jung.
- * @version $Revision: 1.44 $
+ * @version $Revision: 1.45 $
*/
public class J2eeDeployer
@@ -429,6 +432,13 @@
* modules
*/
protected void startApplication(Deployment _d) throws J2eeDeploymentException {
+// Create the appropriate JSR-77 instance
+ObjectName lApplication = J2EEApplication.create(
+getServer(),
+_d.getName(),
+_d.getSourceUrl()
+);
+
// save the old classloader
ClassLoader oldCl = Thread.currentThread().getContextClassLoader();
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Automated JBoss Testsuite Results
JBoss daily test results SUMMARY Number of tests run: 177 Successful tests: 150 Errors:15 Failures: 12 [time of test: 23 November 2001 6:19 GMT] [java.version: 1.3.1] [java.vendor: Sun Microsystems Inc.] [java.vm.version: 1.3.1-b24] [java.vm.name: Java HotSpot(TM) Server VM] [java.vm.info: mixed mode] [os.name: Linux] [os.arch: i386] [os.version: 2.4.9-12] See http://lubega.com for full details 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 [details not shown - as this makes the mail too big to reach the sf mailing list] PS BEFORE you commit, run the test suite. Its easy, just run the target 'run-basic-testsuite' from the main build.xml. PPS Come on people - there were a few days back in July 2001 when we had ZERO tests failing! Oh, and thanks - remember we love you too! ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jboss/src/main/org/jboss/management/j2ee IpAddressMBean.java IpAddress.java J2EEApplication.java J2EEApplicationMBean.java J2EEManagedObject.java J2EEServer.java Node.java SingleJBossServerManagement.java
User: schaefera
Date: 01/11/22 22:20:12
Modified:src/main/org/jboss/management/j2ee IpAddress.java
J2EEApplication.java J2EEApplicationMBean.java
J2EEManagedObject.java J2EEServer.java Node.java
SingleJBossServerManagement.java
Added: src/main/org/jboss/management/j2ee IpAddressMBean.java
Log:
First added the J2EEApplication to JSR-77.
Revision ChangesPath
1.4 +2 -4 jboss/src/main/org/jboss/management/j2ee/IpAddress.java
Index: IpAddress.java
===
RCS file: /cvsroot/jboss/jboss/src/main/org/jboss/management/j2ee/IpAddress.java,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- IpAddress.java2001/11/21 04:50:53 1.3
+++ IpAddress.java2001/11/23 06:20:12 1.4
@@ -11,14 +11,12 @@
import javax.management.MalformedObjectNameException;
import javax.management.ObjectName;
-import javax.management.j2ee.Port;
-
/**
* @author Marc Fleury
**/
public class IpAddress
extends J2EEManagedObject
- implements javax.management.j2ee.IpAddress
+ implements IpAddressMBean
{
// -
// Members
@@ -54,7 +52,7 @@
}
public String toString() {
- return "IpAddress [ " +
+ return "IpAddress { " + super.toString() + " } [ " +
"IpAddress: " + getAddress() +
" ]";
}
1.3 +72 -1 jboss/src/main/org/jboss/management/j2ee/J2EEApplication.java
Index: J2EEApplication.java
===
RCS file:
/cvsroot/jboss/jboss/src/main/org/jboss/management/j2ee/J2EEApplication.java,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- J2EEApplication.java 2001/11/20 07:01:39 1.2
+++ J2EEApplication.java 2001/11/23 06:20:12 1.3
@@ -6,12 +6,19 @@
*/
package org.jboss.management.j2ee;
+import java.io.InputStreamReader;
+import java.io.StringWriter;
+import java.net.URL;
import java.security.InvalidParameterException;
import java.util.Arrays;
import java.util.ArrayList;
+import java.util.Hashtable;
import java.util.List;
+import java.util.jar.JarEntry;
+import java.util.jar.JarFile;
import javax.management.MalformedObjectNameException;
+import javax.management.MBeanServer;
import javax.management.ObjectName;
/**
@@ -19,7 +26,7 @@
* JBoss specific implementation.
*
* @author mailto:[EMAIL PROTECTED]";>Andreas Schafer
-* @version $Revision: 1.2 $
+* @version $Revision: 1.3 $
*/
public class J2EEApplication
extends J2EEDeployedObject
@@ -30,6 +37,54 @@
// -
private List mModules = new ArrayList();
+
+ public static ObjectName create( MBeanServer pServer, String pName, URL pURL ) {
+ String lDD = null;
+ ObjectName lServer = null;
+ try {
+ lServer = (ObjectName) pServer.queryNames(
+ new ObjectName( J2EEManagedObject.getDomainName() +
":type=J2EEServer,*" ),
+ null
+ ).iterator().next();
+ // First get the deployement descriptor
+ System.out.println( "URL: " + pURL.getFile() );
+ JarFile lFile = new JarFile( pURL.getFile() );
+ JarEntry lDDEntry = lFile.getJarEntry( "META-INF/application.xml" );
+ if( lDDEntry != null ) {
+InputStreamReader lInput = new InputStreamReader( lFile.getInputStream(
lDDEntry ) );
+StringWriter lOutput = new StringWriter();
+char[] lBuffer = new char[ 1024 ];
+int lLength = 0;
+while( ( lLength = lInput.read( lBuffer ) ) > 0 ) {
+ lOutput.write( lBuffer, 0, lLength );
+}
+lDD = lOutput.toString();
+ }
+ }
+ catch( Exception e ) {
+ e.printStackTrace();
+ }
+ try {
+ // Now create the J2EEApplication
+ return pServer.createMBean(
+"org.jboss.management.j2ee.J2EEApplication",
+null,
+new Object[] {
+ pName,
+ lServer,
+ lDD
+},
+new String[] {
+ String.class.getName(),
+ ObjectName.class.getName(),
+ String.class.getName()
+}
+ ).getObjectName();
+ }
+ catch( Exception e ) {
+ return null;
+ }
+ }
// -
// Constructors
@@ -65,6 +120,22 @@
return null;
}
+ public void addChild(
[JBoss-dev] CVS update: newsite/src/docs main.css
User: user57
Date: 01/11/22 23:58:37
Modified:src/docs main.css
Log:
o reverting relative font settings, all fonts will use px units again
Revision ChangesPath
1.12 +52 -17newsite/src/docs/main.css
Index: main.css
===
RCS file: /cvsroot/jboss/newsite/src/docs/main.css,v
retrieving revision 1.11
retrieving revision 1.12
diff -u -r1.11 -r1.12
--- main.css 2001/11/22 05:22:28 1.11
+++ main.css 2001/11/23 07:58:34 1.12
@@ -2,15 +2,16 @@
* CSS Style Sheet for the JBoss website.
*/
-/* $Id: main.css,v 1.11 2001/11/22 05:22:28 user57 Exp $ */
+/* $Id: main.css,v 1.12 2001/11/23 07:58:34 user57 Exp $ */
BODY {
font-family: Arial,serif;
- font-size: 0.9em;
+ font-size: 13px;
color: #00;
}
P, DIV, TBODY, TD, LI, DD {
+ font-size: 13px;
color: #00;
}
@@ -31,45 +32,50 @@
color: #336633;
clear: both;
font-weight: bold;
+ font-variant: small-caps;
+ letter-spacing: 0.1em;
}
H1 {
- font-size: 1.4em;
+ font-size: 15px;
}
H2 {
- font-size: 1.3em;
+ font-size: 15px;
}
H3 {
- font-size: 1.2em;
+ font-size: 14px;
}
H4 {
- font-size: 1.1em;
+ font-size: 13px;
}
H5 {
padding-top: 5px;
- font-size: 1.0em;
+ font-size: 13px;
font-weight: normal;
+ letter-spacing: normal;
}
H6 {
padding-top: 5px;
- font-size: 1.0em;
+ font-size: 13px;
+ font-variant: normal;
font-weight: normal;
+ letter-spacing: normal;
}
-.linkhead, .linkmenu {
- font-size: 12px;
- font-weight: bold;
-}
.linkhead {
+ font-size: 12px;
color: #ff;
+ font-weight: bold;
}
.linkmenu {
+ font-size: 12px;
color: #0a0a0a;
+ font-weight: bold;
text-decoration: none;
}
.linkmenu:hover {
@@ -78,19 +84,34 @@
}
.head {
- font-size: 1.3em;
+ font-size: 14px;
color: #336633;
font-weight: bold;
+ padding-top: 1px;
}
.slogan {
- font-size: 15px;
- font-weight: bold;
+ font-size: 15px;
color: #338833;
+ font-weight: bold;
+}
+
+.text {
+ font-size: 13px;
+ color: #00;
}
+.link {
+ font-size: 13px;
+ color: #003399;
+ font-weight: bold;
+}
+.link:hover {
+ color: #336633;
+}
+
.copy {
- font-size: 0.7em;
+ font-size: 11px;
color: #808080;
}
.copy:hover {
@@ -108,7 +129,7 @@
border-style: solid;
padding: 5px;
font-family: monospace;
- font-size: 0.8em;
+ font-size: 12px;
}
.code {
@@ -126,3 +147,17 @@
.red {
color: red;
}
+
+/* Old stuff we keep around for reference */
+
+a.menu { color: black; text-decoration: none }
+td.black { background-color: #00 }
+td.dark { background-color: #276561 }
+td.light { background-color: #307d77 }
+td.link { font-family: Arial,serif; font-size: 13px; color: #404040; font-weight:
bold; }
+td.newsbody { font-family: Arial,serif; font-size: 13px; color: #00}
+td.newsheader {font-family: Arial,serif; font-size: 14px; color: #336633;
font-weight: bold; }
+/*td.newsheader { color: black; background-color: #C1E0B2 }*/
+td.pageheader { color: white; font-weight: bold; font-size: 14pt; background-color:
#99 }
+td.yellow { background-color: #f4c641 }
+span.red { color: red; font-weight: bold }
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] NameNotBound with 3.0 alpha and Jetty4
So I'm getting started with Julian's new Jetty4+JBoss3 integration and I have some questions... Is jboss.xml still used in Rabbit Hole? In the past I've used it to set JNDI names for my EJBs. I have entries like this: Order groundswell/Order When I try to call these beans from a servlet I get: javax.servlet.ServletException: javax.naming.NameNotFoundException: groundswell not bound So... What am I doing wrong? Hunter ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
