Re: [JBoss-dev] [ANN] JBoss 3.0 alpha is out
1. The tests are pretty incomplete - it is very possible that you have found a hole in them. 2. if you sync yourself with the cvs tree you will get an upgrade to Jetty4. I am much happier with the Security integration in this version. If the problem lies with Jetty itself ask Greg whether the fix has gone into Jetty4 - Greg ? You really should sync, if you can - because lots of stuff has gone into my integration since 3.0alpha was released. 3. ClassLoaders are a problem at the moment. I am waiting for a new ClassLoader strategy to finally get checked in, then they should be sorted. For the moment, if you are trying to compile JSPs on the fly (You'd be better of precompiling them) you will be OK if, you only reference jars that you ship in your war. Jars referenced from the ear will not be found, J2EE stuff (except servlet and jasper itself) will not be found. Let me know how you get on. Jules P.S. CVS JBoss seems pretty broken at the moment (I can't even run the web integration tests). so you may want to hold of for a couple of days. --- Allen Fogleson [EMAIL PROTECTED] wrote: Jules, I didnt get a chance to dig into the code yet, but I tried my app quickly on the CVS code, and I am getting jasper exceptions about not being able to import classes. (ClassNotFoundExceptions) Which is better than a HTML error 403 I guess heh. Im planning on looking at it more tomorrow and seeing if it is just my setup or if there is some problem. I admit that the app I made really kind of pushes jboss. It is an ASP sort of model where. More of a webappcabaret model kind of ASP than a real ASP so it is almost as likely that it is my code too. (or at least my setup in Jboss) I had problems with the security not properly being propogated in the Jboss-3alpha/jetty on the web site but I can get around that by dropping in older Jetty jars. I am going to try to find some time today to look at my code and the CVS code and see where the problem lies. Im assuming since it passes the webIntegration tests it is in my setup of jboss and not in the integration but one never knows. Al [EMAIL PROTECTED] wrote: Adam, Have you tried the Jetty integration ? If so, and you didn't like it, would you let me know what was broken, so it can be fixed. Any feedback at all would be useful, otherwise I am working in a vacuum. JBoss 3 cvs now contains Jetty4 which is Servlet 2.3 and JSP 1.2 (Jasper - same as Catalina). As far as the user is concerned this should be a drop in replacement for Catalina. If it isn't we need to know. Thanks, Jules marc fleury wrote: |-Original Message- |From: [EMAIL PROTECTED] |[mailto:[EMAIL PROTECTED]]On Behalf Of Adam |Heath |Sent: Sunday, November 25, 2001 1:23 AM |To: marc fleury |Cc: Jboss-Development@Lists. Sourceforge. Net |Subject: Re: [JBoss-dev] [ANN] JBoss 3.0 alpha is out | | |On Wed, 21 Nov 2001, marc fleury wrote: | | This is it! | | http://prdownloads.sourceforge.net/jboss/jboss-3.0.0alpha.zip | | we will have the link on www.jboss.org shortly | | so go gentlemen, you know what is in there, clustering, EJB 2.0, sar, cl | microkernel, the future. | |Where is tomcat integration? Is this just an oversite? JBoss 2.4.3 had |Tomcat integration(both 3.x and 4.x), yet I see nothing in JBoss cvs that |mention this. Where is your code, Adam? If you care so much about it, get your keyboard and code that integration it should be fairly simple just drop the code from 2.x with 4.0 mods. You got a big mouth, let's hope your hands are as big, otherwise you will rapidly fall in the crocodile category (you figure it out). |Was this on purpose, or an honest oversite? I hope it is not the former, |seeing as how Tomcat is the reference implementation for java servlets. bullshit. Tomcat is just an implementation. Jetty is just an implementation. The main reason right now is 1- the 3.0 release is about CMP 2.0 so get that going, 2- no-one has really contributed the integration 3- I don't care about it I would rather wait to see, but if you care go ahead! You know what to do, come back when you are done. marcf | | |___ |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 _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com ___ Jboss-development mailing list [EMAIL PROTECTED]
Re: [JBoss-dev] (rh) Can we combine j2ee and jboss dds with xsl to get just one dd?
--- Holger Engels [EMAIL PROTECTED] wrote: On Mon, 26 Nov 2001, David Jencks wrote: It's just an idea... What if --when we are doing j2ee spec compliant deployment we use xsl (or something like it) to combine the 2 (or 3 or ...) dds into one unified dd that can be processed in one pass. --we can also deploy the unified version directly for those who like it. what if we use xslt to transform the deploymentdescriptors to jdk1.4's longterm persistence format and let the task of parsing the xml and instantiating the metadata beans to the java.beans.XMLDecoder .. this would at least enhance maintainability. Nice idea - but beware - maintaining the XSL could be more awkward than just doing it in Java. I've been there ! Jules Good idea or am I nuts? .. definately I am ;-) Holger ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development __ Do You Yahoo!? Everything you'll ever need on one web page from News and Sport to Email and Music Charts http://uk.my.yahoo.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Classloader puzzle
On Mon, 26 Nov 2001, Francisco Reverbel wrote: IIOP stuff outperforms the JRMP code in RH on _all_ other bank testcases. This claim is false, of course. Please read 6 out of 10 instead of _all_ other. I guess yesterday night I was too tired to look at those numbers... Cheers, Francisco ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] javax.management.InstanceAlreadyExistsException...
On running the WebIntegration test on a freshly built Server (cvs updated about 12 hours ago) I get a : javax.management.InstanceAlreadyExistsException: SingleJBoss:name=jbosstest-web.ear, J2EEServer=Single, J2EEApplication=jbosstest-web.ear, type=EJBModule, J2EEManagement=Manager, from JMX. The last JBoss stackframe was : org.jboss.management.j2ee.EJBModule.create() - EJBModule.java - line 78. I would send the whole stack - but I'm not on my development box, Apologies if this has already been sorted. Jules __ Do You Yahoo!? Everything you'll ever need on one web page from News and Sport to Email and Music Charts http://uk.my.yahoo.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] [ANN] JBoss 3.0 alpha is out
I'm just going to agree with Jules here... try to get onto the cvs HEAD as lots has changed here. You will probably still have some JSP compilation problems, but you can hack around those in the short term by either precompiling JSPs (better yet just don't use them:-) or you can set the classpath initparam of the JspServlet in the defaultweb.xml file. You will have to list all the jars that you need to compile the JSPs. cheers Julian Gosnell wrote: 1. The tests are pretty incomplete - it is very possible that you have found a hole in them. 2. if you sync yourself with the cvs tree you will get an upgrade to Jetty4. I am much happier with the Security integration in this version. If the problem lies with Jetty itself ask Greg whether the fix has gone into Jetty4 - Greg ? You really should sync, if you can - because lots of stuff has gone into my integration since 3.0alpha was released. 3. ClassLoaders are a problem at the moment. I am waiting for a new ClassLoader strategy to finally get checked in, then they should be sorted. For the moment, if you are trying to compile JSPs on the fly (You'd be better of precompiling them) you will be OK if, you only reference jars that you ship in your war. Jars referenced from the ear will not be found, J2EE stuff (except servlet and jasper itself) will not be found. Let me know how you get on. Jules P.S. CVS JBoss seems pretty broken at the moment (I can't even run the web integration tests). so you may want to hold of for a couple of days. --- Allen Fogleson [EMAIL PROTECTED] wrote: Jules, I didnt get a chance to dig into the code yet, but I tried my app quickly on the CVS code, and I am getting jasper exceptions about not being able to import classes. (ClassNotFoundExceptions) Which is better than a HTML error 403 I guess heh. Im planning on looking at it more tomorrow and seeing if it is just my setup or if there is some problem. I admit that the app I made really kind of pushes jboss. It is an ASP sort of model where. More of a webappcabaret model kind of ASP than a real ASP so it is almost as likely that it is my code too. (or at least my setup in Jboss) I had problems with the security not properly being propogated in the Jboss-3alpha/jetty on the web site but I can get around that by dropping in older Jetty jars. I am going to try to find some time today to look at my code and the CVS code and see where the problem lies. Im assuming since it passes the webIntegration tests it is in my setup of jboss and not in the integration but one never knows. Al [EMAIL PROTECTED] wrote: Adam, Have you tried the Jetty integration ? If so, and you didn't like it, would you let me know what was broken, so it can be fixed. Any feedback at all would be useful, otherwise I am working in a vacuum. JBoss 3 cvs now contains Jetty4 which is Servlet 2.3 and JSP 1.2 (Jasper - same as Catalina). As far as the user is concerned this should be a drop in replacement for Catalina. If it isn't we need to know. Thanks, Jules marc fleury wrote: |-Original Message- |From: [EMAIL PROTECTED] |[mailto:[EMAIL PROTECTED]]On Behalf Of Adam |Heath |Sent: Sunday, November 25, 2001 1:23 AM |To: marc fleury |Cc: Jboss-Development@Lists. Sourceforge. Net |Subject: Re: [JBoss-dev] [ANN] JBoss 3.0 alpha is out | | |On Wed, 21 Nov 2001, marc fleury wrote: | | This is it! | | http://prdownloads.sourceforge.net/jboss/jboss-3.0.0alpha.zip | | we will have the link on www.jboss.org shortly | | so go gentlemen, you know what is in there, clustering, EJB 2.0, sar, cl | microkernel, the future. | |Where is tomcat integration? Is this just an oversite? JBoss 2.4.3 had |Tomcat integration(both 3.x and 4.x), yet I see nothing in JBoss cvs that |mention this. Where is your code, Adam? If you care so much about it, get your keyboard and code that integration it should be fairly simple just drop the code from 2.x with 4.0 mods. You got a big mouth, let's hope your hands are as big, otherwise you will rapidly fall in the crocodile category (you figure it out). |Was this on purpose, or an honest oversite? I hope it is not the former, |seeing as how Tomcat is the reference implementation for java servlets. bullshit. Tomcat is just an implementation. Jetty is just an implementation. The main reason right now is 1- the 3.0 release is about CMP 2.0 so get that going, 2- no-one has really contributed the integration 3- I don't care about it I would rather wait to see, but if you care go ahead! You know what to do, come back when you are done. marcf | | |___ |Jboss-development mailing list |[EMAIL PROTECTED] |https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED]
Re: [JBoss-dev] notes on Container as abstract collection
Hi, Not sure I've read your message correctly... One thought I've been toying with is that it should be possible to use different protocols to access metods of the same enterprise bean. I am not talking about deploying two almost identical (except for some change on a deployment descriptor) copies of the same bean, one to be called via JRMP and the other via IIOP. I mean deploying just one enterprise bean, which would have both a JRMP and an IIOP container invoker associated to it. Is this what you are getting at? Best, Francisco On Mon, 26 Nov 2001, marc fleury wrote: OK I am almost done rewriting the proxy and container invoker stack, this is not about that but the container understanding. First off a small API change in the stuff that remains namely the CI getEJB types that today return typed EJB interfaces, I want to return Objects to allow for optimization between proxy and container, more on that later. I will get numbers. The note is on the current understanding of container as a one one mapping with invokers. One of the goals of the current design is to completely detach the invoker stack from the container one. An EJB is nothing but a collection of predefined behavior (transaction and security) with guaranteed cache on the server. In the theoretical world what we use to invoke the container stack should be transparent. I.e. the same contianer with the same series of cached object shouldn't care whether we use IIOP or JRMP or webservices. In our implementation it is not the case, some of the calls namely the lifecycle ones (create/find) are typed in the sense that they hardcode the creation of the proxies with the one invocation stack that is supposed to be calling them. There is a one one mapping in invocation and container through this link. It is a weak link. It also clearly draws the line for a association with the invocation as opposed to the container invoker. I have coded in the new proxy and invocation the support for an absolutely generic container representation. For all practical purposes the JNDI name is good the bottom line being that the same container stack as we understand it today can be called through 2 invocation stacks as 2 different containers sharing the same cache. The power would be really to have the centralized caches, as dedicating a cache and a container to a given invocation stack is a limitation of the current design. So the support is there, and by associating the invocation with an identifier, we are then capable from any stack inside of saying look I am involved with creators and I need to know your stack, personally I don't care (I don't have a pointer) but you care, that is where you came from and it is where you are returning to we do have that information it is in the right place (the invocation not the container) and i will move it. As a byproduct of the generic association we are also able to retrieve relevant CL from any stack that touches that invocation. In short the invocation is it. PS: In the immediate future I want to get the current proxy and invocation working with the legacy ContainerInvoker, this way I do keep support for local stuff and the IIOP stuff unchanged, as is, and the creation mechanisms are unchanged as well. I just wanted to share the first insight into generic invokers that made sense to me :) documenting as scott says. It seems you feel our work is not a benefit to the public? Replicants are like any other machine, they are either a benefit or a hazard, if they are a benefit it is not my problem. Marc Fleury President JBoss Group, LLC ___ 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] javax.management.InstanceAlreadyExistsException...
On Tue, 27 Nov 2001, Julian Gosnell wrote: On running the WebIntegration test on a freshly built Server (cvs updated about 12 hours ago) I get a : javax.management.InstanceAlreadyExistsException: SingleJBoss:name=jbosstest-web.ear, J2EEServer=Single, J2EEApplication=jbosstest-web.ear, type=EJBModule, J2EEManagement=Manager, from JMX. I get a similar message, when deploying an ear: 11:49:12,628 INFO [Default] File: file:/home/hengels/jdevel/jboss-all/build/output/jboss-3.0.0alpha/deploy/Default/egor.ear/ejb1006.jar, descriptor: META-INF/ejb-jar.xml 11:49:12,643 INFO [Default] J2EEManagedObject.getObjectName(), name: SingleJBoss:name=egor.ear,J2EEServer=Single,J2EEApplication=egor.ear,type=EJBModule,J2EEManagement=Manager 11:49:12,645 INFO [Default] J2EEManagedObject.postRegister(), parent: SingleJBoss:J2EEServer=Single,name=egor.ear,type=J2EEApplication,J2EEManagement=Manager 11:49:12,647 ERROR [Default] javax.management.InstanceAlreadyExistsException: SingleJBoss:name=egor.ear,J2EEServer=Single,J2EEApplication=egor.ear,type=EJBModule,J2EEManagement=Manager 11:49:12,649 ERROR [Default]at com.sun.management.jmx.RepositorySupport.addMBean(RepositorySupport.java:134) 11:49:12,650 ERROR [Default]at com.sun.management.jmx.MBeanServerImpl.internal_addObject(MBeanServerImpl.java:2352) 11:49:12,651 ERROR [Default]at com.sun.management.jmx.MBeanServerImpl.createMBean(MBeanServerImpl.java:641) 11:49:12,653 ERROR [Default]at org.jboss.management.j2ee.EjbModule.create(EjbModule.java:78) 11:49:12,654 ERROR [Default]at org.jboss.ejb.ContainerFactory.deploy(ContainerFactory.java:394) 11:49:12,655 ERROR [Default]at org.jboss.ejb.ContainerFactory.deploy(ContainerFactory.java:368) 11:49:12,657 ERROR [Default]at org.jboss.ejb.ContainerFactory.deploy(ContainerFactory.java:299) 11:49:12,658 ERROR [Default]at java.lang.reflect.Method.invoke(Native Method) 11:49:12,659 ERROR [Default]at com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1628) 11:49:12,660 ERROR [Default]at com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1523) 11:49:12,662 ERROR [Default]at org.jboss.deployment.J2eeDeployer.startModules(J2eeDeployer.java:516) 11:49:12,663 ERROR [Default]at org.jboss.deployment.J2eeDeployer.startApplication(J2eeDeployer.java:490) 11:49:12,665 ERROR [Default]at org.jboss.deployment.J2eeDeployer.deploy(J2eeDeployer.java:222) 11:49:12,666 ERROR [Default]at java.lang.reflect.Method.invoke(Native Method) 11:49:12,667 ERROR [Default]at com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1628) 11:49:12,669 ERROR [Default]at com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1523) 11:49:12,670 ERROR [Default]at org.jboss.deployment.AutoDeployer.deploy(AutoDeployer.java:653) 11:49:12,671 ERROR [Default]at org.jboss.deployment.AutoDeployer.run(AutoDeployer.java:326) 11:49:12,672 ERROR [Default]at java.lang.Thread.run(Thread.java:484) 11:49:12,674 ERROR [ContainerFactory] Could not deploy file:/home/hengels/jdevel/jboss-all/build/output/jboss-3.0.0alpha/deploy/Default/egor.ear my checkout is less than an hour old, holger ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-482875 ] OutOfMemory after many Deploy cycles
Bugs item #482875, was opened at 2001-11-17 12:12
You can respond by visiting:
http://sourceforge.net/tracker/?func=detailatid=376685aid=482875group_id=22866
Category: JBossServer
Group: v2.4 (stable)
Status: Open
Resolution: Works For Me
Priority: 7
Submitted By: Joel Boehland (jolby)
Assigned to: Scott M Stark (starksm)
Summary: OutOfMemory after many Deploy cycles
Initial Comment:
I have been seeing OutOfMemoryErrors in my server after
doing several deploy/redeploy cycles of my application
.ear file (which is around 3 megs in size)
Basic info:
*Hardware: AMD-K2-400MHz, 196MB RAM
*OS: linux 2.2.14
*jdk: Blackdown-1.3.0-FCS, mixed mode
*Server: JBoss-2.4.3_Jetty-3.1.3-1
*ServerTrace: I don't have one now, but I can provide
one later if needed.
*Steps to reproduce: Deploy/Redeploy .ear file many
times. My .ear is around 3 megs, so it may be necessary
to use a large one to trigger this effect.
Other info
*I have had this happen using native threads mode, and
green threads mode.
*Jozsa Kristof [EMAIL PROTECTED] has also reported
this error on the jboss-user list. He was using IBM jdk
1.3.0 on linux, so this doesn't appear to be tied to
any particular version of the jdk.
--Joel
--
Comment By: Adrian Brock (ejort)
Date: 2001-11-27 02:48
Message:
Logged In: YES
user_id=9459
You can let go now;-), I found the rest of the problem!
There is another a hard link cache in
org.jboss.ejb.plugins.jrmp.interfaces.RemoteMethodInvocation
This one is harder to spot.
I think the code in method calculateHash is wrong for two
reasons.
1) The cache (hashMap) is a WeakHashMap, but its values
contain HashMaps that have hard links to the application's
classes.
The garbage collector can't remove these, the weak
behaviour is in the keys.
2) You can't rely on the garbage collector to remove old
entries BEFORE the application is redeployed.
The old calculated hash values may still be in the cache
when JRMPContainerInvoke.init is run over the new bean.
This means it uses the (wrong? not sure how important this
is?) old hash values.
NOTE: ejb.plugins.local.BaseLocalContainerInvoker almost
certainly has the same problem.
My solution is make the cache a normal HashMap and get
JRMPContainerInvoker.destroy to remove its cached values,
ensuring the new bean has to recalculate them.
I think the changes should be: (I have no CVS access)
In RemoteInvocation.java
-static Map hashMap = new WeakHashMap();
+static Map hashMap = new HashMap();
public static long calculateHash(Method method)
{
Map methodHashes = (Map)hashMap.get(
method.getDeclaringClass());
if (methodHashes == null)
{
methodHashes = getInterfaceHashes(
method.getDeclaringClass());
hashMap.put(method.getDeclaringClass()),
methodHashes);
}
return ((Long)methodHashes.get(method)).longValue();
}
public static void uncacheHash(Method method)
{
hashMap.remove(method.getDeclaringClass());
}
In JRMPContainerInvoker.java
public void destroy()
{
Method[] methods = ((ContainerInvokerContainer)container)
.getRemoteClass().getMethods();
for (int i = 0; i methods.length(); i++)
RemoteMethodInvocation.uncacheHash(methods[i]);
methods = ((ContainerInvokerContainer)container)
.getHomeClass().getMethods();
for (int i = 0; i methods.length(); i++)
RemoteMethodInvocation.uncacheHash(methods[i]);
}
PEFORMANCE NOTE: I HAVEN'T TESTED THIS
It should be possible to check the class loader before
uncaching. Only those loaded through the application's
class loader need to be removed (I think?).
i.e.
public static void uncacheHash(Method method)
{
if (Thread.currentThread().getContextClassLoader() ==
method.getDeclaringClass().getClassLoader())
hashMap.remove(method.getDeclaringClass());
}
This fix and the one for ENCFactory sorts the problem.
Scott, I have been testing it on Windows XP using Sun 1.4.0-
beta3 JDK on both JBoss 2.4.3 and 3.0.0alpha.
On 2.4.3 I used -Xmx2049k, on 3.0.0 with Jetty running
it was -Xmx4097k (spooky numbers, probably not)
it always broke before 20 redeploys.
Regards,
Adrian
--
Comment By: Scott M Stark (starksm)
Date: 2001-11-26 18:37
Message:
Logged In: YES
user_id=175228
I can't reproduce this behavior on a RedHat 7.2(2.4.7-10)
using the Sun 1.3.1_01 JDK or on a Win2ksp2 system running
the Sun 1.3.1_01 JDK using the latest 2.4 branch code that
will be released as 2.4.4. On the Win2k system I am running
with JBoss under OptimizeIT using -Xms20m -Xmx24m and the
heap stays at 20M and the heap usage ranges between 5M and
12M. I have redeployed the 14k bank.jar from the jbosstest
suite 100 times and still see no hint of OutOfMemory
problems.
--
Comment By: Adrian Brock (ejort)
Date: 2001-11-25 07:04
Message:
Logged
Re: [JBoss-dev] Build Broken?
On 2001.11.27 06:56:22 -0500 Julian Gosnell wrote: Have you got JBOSS_HOME set ? This one has bittent me before This was my mistake, I checked in a wrong version a jboss-service.xml. Fixed now as far as I can tell. david jencks Jules --- Hunter Hillegas [EMAIL PROTECTED] wrote: Just grabbed the latest CVS and I get this on startup: 20:09:54,995 WARN [ServiceDeployer] SaxException getting document: java.io.FileNotFoundException: /usr/java/jboss/co6/jboss-all/server/src/resources/org/jboss/metadata/jboss- service.dtd (No such file or directory) at org.apache.crimson.parser.Parser2.fatal(Parser2.java:3108) At this point the server shuts down... ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development __ Do You Yahoo!? Everything you'll ever need on one web page from News and Sport to Email and Music Charts http://uk.my.yahoo.com ___ 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] My Experience With Local Interfaces
this is bullshit, I don't mean your work, just another example of packaging madness. It is obscure, it is counter intuitive, takes time and it is ARTIFICIAL will try to solve it marcf |-Original Message- |From: [EMAIL PROTECTED] |[mailto:[EMAIL PROTECTED]]On Behalf Of |Hunter Hillegas |Sent: Monday, November 26, 2001 11:57 PM |To: JBoss Dev |Subject: [JBoss-dev] My Experience With Local Interfaces | | |After a couple of days of trying to figure this out, I discovered that |things works perfectly when the WAR and JAR are packaged in an EAR without |the jboss-web.xml file. | |Hunter | | |___ |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
pretty good pretty good, serialization is heavy and should be dealt with with great care, that much we understand marcf |-Original Message- |From: Francisco Reverbel [mailto:[EMAIL PROTECTED]] |Sent: Tuesday, November 27, 2001 5:08 AM |To: marc fleury |Cc: David Jencks; [EMAIL PROTECTED] |Subject: RE: [JBoss-dev] Classloader puzzle | | |On Mon, 26 Nov 2001, Francisco Reverbel wrote: | | IIOP stuff outperforms the JRMP code in RH on _all_ other bank |testcases. | |This claim is false, of course. | |Please read 6 out of 10 instead of _all_ other. | |I guess yesterday night I was too tired to look at those numbers... | |Cheers, | |Francisco | | | | ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] notes on Container as abstract collection
|-Original Message- |From: [EMAIL PROTECTED] |[mailto:[EMAIL PROTECTED]]On Behalf Of |Francisco Reverbel |Sent: Tuesday, November 27, 2001 5:27 AM |To: marc fleury |Cc: Jboss-Development@Lists. Sourceforge. Net |Subject: Re: [JBoss-dev] notes on Container as abstract collection | | |Hi, | |Not sure I've read your message correctly... One thought I've been toying |with is that it should be possible to use different protocols to access |metods of the same enterprise bean. I am not talking about deploying two |almost identical (except for some change on a deployment descriptor) |copies of the same bean, one to be called via JRMP and the other via |IIOP. I mean deploying just one enterprise bean, which would have both a |JRMP and an IIOP container invoker associated to it. | |Is this what you are getting at? yes, I want the same container to live under 3 different invokers, the JRMP the IIOP the .NET right now we are talking 3 copies and 3 caches that won't be synchronized. The performance will be much better, marcf | |Best, | |Francisco | |On Mon, 26 Nov 2001, marc fleury wrote: | | OK I am almost done rewriting the proxy and container invoker |stack, this is | not about that but the container understanding. | | First off a small API change in the stuff that remains namely |the CI getEJB | types that today return typed EJB interfaces, I want to return Objects to | allow for optimization between proxy and container, more on that |later. I | will get numbers. | | The note is on the current understanding of container as a one |one mapping | with invokers. One of the goals of the current design is to completely | detach the invoker stack from the container one. An EJB is nothing but a | collection of predefined behavior (transaction and security) |with guaranteed | cache on the server. In the theoretical world what we use to invoke the | container stack should be transparent. I.e. the same contianer |with the same | series of cached object shouldn't care whether we use IIOP or JRMP or | webservices. In our implementation it is not the case, some of the calls | namely the lifecycle ones (create/find) are typed in the sense that they | hardcode the creation of the proxies with the one invocation |stack that is | supposed to be calling them. There is a one one mapping in |invocation and | container through this link. It is a weak link. | | It also clearly draws the line for a association with the invocation as | opposed to the container invoker. I have coded in the new proxy and | invocation the support for an absolutely generic container |representation. | For all practical purposes the JNDI name is good the bottom line |being that | the same container stack as we understand it today can be called |through 2 | invocation stacks as 2 different containers sharing the same cache. The | power would be really to have the centralized caches, as |dedicating a cache | and a container to a given invocation stack is a limitation of |the current | design. So the support is there, and by associating the |invocation with an | identifier, we are then capable from any stack inside of saying |look I am | involved with creators and I need to know your stack, personally I don't | care (I don't have a pointer) but you care, that is where you |came from and | it is where you are returning to we do have that information it |is in the | right place (the invocation not the container) and i will move it. As a | byproduct of the generic association we are also able to |retrieve relevant | CL from any stack that touches that invocation. In short the |invocation is | it. | | PS: In the immediate future I want to get the current proxy and |invocation | working with the legacy ContainerInvoker, this way I do keep support for | local stuff and the IIOP stuff unchanged, as is, and the |creation mechanisms | are unchanged as well. I just wanted to share the first insight into | generic invokers that made sense to me :) documenting as scott says. | | It seems you feel our work is not a benefit to the public? | Replicants are like any other machine, | they are either a benefit or a hazard, | if they are a benefit it is not my problem. | | | | Marc Fleury | President | JBoss Group, LLC | | | | ___ | 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] JMS issues re: stopservice, jndi names
From: David Jencks [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] JMS issues re: stopservice, jndi names Date: Mon, 26 Nov 2001 23:26:02 -0500 On 2001.11.26 22:50:55 -0500 David Budworth wrote: Hi all, There are two things bugging me right now in JMS, and I just wanted to know if anyone is working on them, or if they need to be fixed at all. The first one, is pretty obviously a 'needs-to-be-done'. You can't current undeploy a queue/topic. In my sar, I define the JMS queues that the services use, and when I undeploy the .sar, the log says queue stop not yet implemented. The problem this causes is that once you delete the SAR, the queue name disappears from the 8082 UI, but, if you attempt to re-deploy the SAR, or just create the queue via the 8082 UI, you'll get a an error stating the topic/queue already exists. So it seems that on undeploy, the internal stuctures of JBossMQ gets fux0r3d (in script-kiddie speak). I'd be happy to work on this (since I need it). I just didn't know if anyone else was already doing it. Nor do I really know where to start on it. I'm not the most expert... but I think the queue stop method needs to arrange with the JMSService to stop accepting messages and possibly with the persistence manager to make sure everything is stably saved that should be. Make sure all open transactions are ended before shutting down! Sounds about right. The second one is just something that bothers me, which is if you specify a queue name like: mycompany/queuea You will get a name not bound exception on mycompany. For EJBs this works correctly, where the subcontexts are created on the fly as need be. But for JMS it doesn't. I'd also like to add this, since I don't like having the JMS topics/queues in a flat namespace. I'm not sure if this is by spec though. Are you not allowed to create a heirarchy for the queue/topic names? If I create transient topics, I can do it if I pre-create the subcontexts. So I know it 'works', I'm just not sure it's legal. Also, is there some helper code somewhere in jboss to create a JNDI tree already? Or does everyone just roll there own with tokenizers or something? I feel like I've seen 10 or twenty implementations of this, but its probably just 3 or 4;-) They are often in Deployers. Could we put one version in either DeployerMBeanSupport or ServiceMBeanSupport? The MBean classes don't seem to ME to be the right place for the kind of code. Maybe a new JNDISupport in the org.jboss.util?? Regards, Hiram David Jencks -David ___ 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 _ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] (rh) Can we combine j2ee and jboss dds with xsl to get just one dd?
On 2001.11.27 02:19:19 -0500 Holger Engels wrote: On Mon, 26 Nov 2001, David Jencks wrote: It's just an idea... What if --when we are doing j2ee spec compliant deployment we use xsl (or something like it) to combine the 2 (or 3 or ...) dds into one unified dd that can be processed in one pass. --we can also deploy the unified version directly for those who like it. what if we use xslt to transform the deploymentdescriptors to jdk1.4's longterm persistence format and let the task of parsing the xml and instantiating the metadata beans to the java.beans.XMLDecoder .. this would at least enhance maintainability. Very interesting idea. I was playing with using jaxb for xml to object conversion, although there may be license issues with it. Offhand, it looks to me as if using the jdk 1.4 persistence format (I just read about it for 5 min or so) would involve some pretty heavy-duty xml transformations and require jdk 1.4. Jaxb appears (in very preliminary experiments) to be able to generate classes from the ejb 2 dtd and jbosscmp-jdbc dtd. sooo.. --jaxb requires using specially generated base classes but requires minimal xml transformation. License may make it unavailable ( anyone else have an opinion about this???) --jdk 1.4 persistence can use regular classes but requires a lot of xsl, and jdb 1.4. Any one have experience with both or at least an opinion? Thanks david jencks Good idea or am I nuts? .. definately I am ;-) Holger ___ 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] EJB QL
This is all just conjecture. Run a profiler on the section that is taking sooo long and find out for sure what it going on. We can waste weeks discussing what might be the problem. -dain -Original Message- From: Peter Levart [mailto:[EMAIL PROTECTED]] Sent: Tuesday, November 27, 2001 6:45 AM To: danch; Peter Levart Cc: Dain Sundstrom; [EMAIL PROTECTED] Subject: Re: [JBoss-dev] EJB QL On Monday 26 November 2001 19:08, danch wrote: Peter Levart wrote: What about using finder methods like in BMP EBs? The responsibility of a BMP finder method is to return a Collection of primary keys. That's easy to do with JDBC/SQL. There would only have to be a way to apply BMP finders to CMP beans and we'll have dynamic SQL already. Currently I'm using JDBC/SQL to retrieve primary keys and then a loop of findByPrimaryKey() for each key to obtain Local interfaces and it takes about 1-2 seconds per 30 objects. The abovementioned BMP finders would speed things up considerably since it would only take one invocation... That may still takes n+1 DB hits - remember that the BMP finder returns a set of keys - beyond that you're OK if the bean is already in cache (commit option A). If you're doing all this from a session bean (in transaction) it shouldn't be any faster with a BMP finder than what you're doing. Unless I'm missing something big. DB hits are one thing. I don't know if read-ahead option in JBossCMP is used for anything else than relations, but it would be a great idea to apply this to finders also. The other thing are invocations. Even if I use Local interfaces to call a bean from an already established transaction context, the invocations have to pass all the interceptors, etc. I was hoping that building the Local interface from the primary key does not have to hit the DB until some accessors in the Local interface are called, so building a lot of local interfaces should be cheap if it is done during one invocation (a call to finder method). Peter ___ 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] Installer / Deployer Problem
Hi Geeks In the Installer all deployed application are copyed and then inflated (right now in /deploy/Default/). During this inflation the name of the contained archives are lost. As example for an JAR file it will be renamed to ejb1002.jar. Unfortunately the mapping of the orginal archive name is lost but JSR-77 needs to know the name of the archive. QUESTION: Is this a problem to keep the orignal name of the archive ? Andy x Andreas Schaefer Senior Consultant JBoss Group, LLC x ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Installer / Deployer Problem
|Hi Geeks | |In the Installer all deployed application are copyed and then |inflated (right now in /deploy/Default/). During this inflation |the name of the contained archives are lost. As example for |an JAR file it will be renamed to ejb1002.jar. | |Unfortunately the mapping of the orginal archive name is lost |but JSR-77 needs to know the name of the archive. | |QUESTION: Is this a problem to keep the orignal name of |the archive ? not that I know, the original deployer was a piece of crap anyway, fix this if you want. BTW is the URL caching thing FIXED in 1.4 JDK or not? if so we could require the 1.4 VM for proper behavior of the deployer I think it would greatly simplify the design as we wouldn't need to copy the files over. Also teh copying gets to be slow when the stuff is too big, marcf | |Andy | |x |Andreas Schaefer |Senior Consultant |JBoss Group, LLC |x | | |___ |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] notes on Container as abstract collection
I read this email yesterday. It made sense, but I couldn't follow some of the arguments. Then last night I was laying in bed at about 4am, and I was pissed about finders. The getEntityCollection method on ContainerInvoke is declared to throw a RemoteExceptions even though no implementations throw a RemoteException from this method. And then your message clicked. Why the fuck should the container invoker care about the container internally loading entities into memory? That isn't its job; Its job it to invoke methods on the container and them propagate the results back to the caller. Oh, that is what marc was talking about. I'm excited to see this change when you get it done and I have some question: Are you going to move the ctx cache code from the container invoker to a container level object? Are you going to remove the RemoteExceptions from this code? I think that in general remote exceptions should be removed from all of the internal container code. If there is a generic exception in the container, then it should use an EJBException instead, and if the call happens to be propagated over a remote interface, it can be wrapped with a remote exception at that point. When you get the change in, I'll be more then happy to convert the cmp 2 code quickly. -dain -Original Message- From: marc fleury [mailto:[EMAIL PROTECTED]] Sent: Monday, November 26, 2001 3:27 PM To: Jboss-Development@Lists. Sourceforge. Net Subject: [JBoss-dev] notes on Container as abstract collection OK I am almost done rewriting the proxy and container invoker stack, this is not about that but the container understanding. First off a small API change in the stuff that remains namely the CI getEJB types that today return typed EJB interfaces, I want to return Objects to allow for optimization between proxy and container, more on that later. I will get numbers. The note is on the current understanding of container as a one one mapping with invokers. One of the goals of the current design is to completely detach the invoker stack from the container one. An EJB is nothing but a collection of predefined behavior (transaction and security) with guaranteed cache on the server. In the theoretical world what we use to invoke the container stack should be transparent. I.e. the same contianer with the same series of cached object shouldn't care whether we use IIOP or JRMP or webservices. In our implementation it is not the case, some of the calls namely the lifecycle ones (create/find) are typed in the sense that they hardcode the creation of the proxies with the one invocation stack that is supposed to be calling them. There is a one one mapping in invocation and container through this link. It is a weak link. It also clearly draws the line for a association with the invocation as opposed to the container invoker. I have coded in the new proxy and invocation the support for an absolutely generic container representation. For all practical purposes the JNDI name is good the bottom line being that the same container stack as we understand it today can be called through 2 invocation stacks as 2 different containers sharing the same cache. The power would be really to have the centralized caches, as dedicating a cache and a container to a given invocation stack is a limitation of the current design. So the support is there, and by associating the invocation with an identifier, we are then capable from any stack inside of saying look I am involved with creators and I need to know your stack, personally I don't care (I don't have a pointer) but you care, that is where you came from and it is where you are returning to we do have that information it is in the right place (the invocation not the container) and i will move it. As a byproduct of the generic association we are also able to retrieve relevant CL from any stack that touches that invocation. In short the invocation is it. PS: In the immediate future I want to get the current proxy and invocation working with the legacy ContainerInvoker, this way I do keep support for local stuff and the IIOP stuff unchanged, as is, and the creation mechanisms are unchanged as well. I just wanted to share the first insight into generic invokers that made sense to me :) documenting as scott says. It seems you feel our work is not a benefit to the public? Replicants are like any other machine, they are either a benefit or a hazard, if they are a benefit it is not my problem. Marc Fleury President JBoss Group, LLC ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED]
[JBoss-dev] [ jboss-Patches-486027 ] Incorrect ObjectNotFoundException
Patches item #486027, was opened at 2001-11-27 07:37
You can respond by visiting:
http://sourceforge.net/tracker/?func=detailatid=376687aid=486027group_id=22866
Category: JBossCMP
Group: v2.4 (stable)
Status: Open
Resolution: None
Priority: 5
Submitted By: Bani Greyling (banigreyling)
Assigned to: Nobody/Anonymous (nobody)
Summary: Incorrect ObjectNotFoundException
Initial Comment:
I have a problem when doing a findByPrimaryKey (CMP)
and the pool give out a dead
connection. I think I got to the source of the
problem.
While doing a findByPrimaryKey JBoss first determine
if the object exist by doing a
count. If this count fail (because the pool gave a
dead connection), then the exeption
is ignored and false is returned as described by the
following code fragment:
(from
org.jboss.ejb.plugins.jaws.jdbc.JDBCBeanExistsCommand.j
ava)
public boolean execute(Object id)
{
boolean result = false;
try
{
result = ((Boolean)jdbcExecute
(id)).booleanValue();
} catch (Exception e)
{
log.debug(e);
}
return result;
}
Subsequently the follwing code fragment from
org.jboss.ejb.plugins.jaws.jdbc.JDBCFindEntityCommand.j
ava throw an
ObjectNotFoundException which result in the client
getting message that the record
does not exist.
protected Object findByPrimaryKey(Object id) throws
FinderException
{
if (beanExistsCommand.execute(id))
{
return id;
} else
{
throw new ObjectNotFoundException(Object
with primary key + id +
not found
in storage);
}
}
I feel that the first mentioned codefragment should be
changed to:
public boolean execute(Object id)
throws FinderException
{
boolean result = false;
try
{
result = ((Boolean)jdbcExecute
(id)).booleanValue();
} catch (Exception e)
{
log.debug(e);
throw new FinderException(e.toString());
}
return result;
}
This will ensure that the client is informed that his
request could not be serviced.
My current configuration:
JBoss 2.4.1
JDK 1.3
Windows NT4
MS SQLServer2000
com.jnetdirect.jsql.JSQLDriver
Unified diff:
--- JDBCBeanExistsCommand.java~1~ Sat Jul 14
21:43:24 2001
+++ JDBCBeanExistsCommand.java Tue Nov 27 12:12:28
2001
@@ -10,6 +10,7 @@
import java.sql.PreparedStatement;
import java.sql.ResultSet;
import java.sql.SQLException;
+import javax.ejb.FinderException;
import org.jboss.ejb.EntityEnterpriseContext;
@@ -38,6 +39,7 @@
// Checks whether the database already holds the
entity
public boolean execute(Object id)
+ throws FinderException
{
boolean result = false;
@@ -47,6 +49,7 @@
} catch (Exception e)
{
log.debug(e);
+ throw new FinderException(e.toString());
}
return result;
--
You can respond by visiting:
http://sourceforge.net/tracker/?func=detailatid=376687aid=486027group_id=22866
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Installer / Deployer Problem
Ok, then I will also do this changes: - rearrange Deployment and Application therefore I can be used to pass information from Installer/J2eeDeployer to ContainerFactory - ContainerFactory should not be called directly therefore I will remove the convenience deploy() method accepting a String instead of an URL Andy BTW I will check if the problem is fixed in JDK1.4. - Original Message - From: marc fleury [EMAIL PROTECTED] To: Andreas Schaefer [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Tuesday, November 27, 2001 8:07 AM Subject: RE: [JBoss-dev] Installer / Deployer Problem |Hi Geeks | |In the Installer all deployed application are copyed and then |inflated (right now in /deploy/Default/). During this inflation |the name of the contained archives are lost. As example for |an JAR file it will be renamed to ejb1002.jar. | |Unfortunately the mapping of the orginal archive name is lost |but JSR-77 needs to know the name of the archive. | |QUESTION: Is this a problem to keep the orignal name of |the archive ? not that I know, the original deployer was a piece of crap anyway, fix this if you want. BTW is the URL caching thing FIXED in 1.4 JDK or not? if so we could require the 1.4 VM for proper behavior of the deployer I think it would greatly simplify the design as we wouldn't need to copy the files over. Also teh copying gets to be slow when the stuff is too big, marcf | |Andy | |x |Andreas Schaefer |Senior Consultant |JBoss Group, LLC |x | | |___ |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] Installer / Deployer Problem
|It's not fixed. Marc, do you remember when we were at J1 and talked to |your french friend that said something about it being a security hole if |it was fixed. Or something like that. Are you sure it is not fixed? as in you verified or as in you took what this guy said at face value (name is jc collet btw), I wouldn't trust everything he said :) you know we were friends and all but... |I've been thinking about this problem though. Wouldn't it be possible to |make a custom URL handler that returns a connection wrapper that we can |drop under the covers. I.e. even if the URLClassLoader hangs onto it, we |can still close the file under the covers. I think that would make it |work, and wouldn't be *that* intrusive in the code. sure, that is an idea and it would simplify the code a lot. The problem I see is that I suspect they keep the connection opened for classloading reasons, i.e. the VM asks for loading classes at random times. Reopening the connection seems slow (the security hole would be the capability to change the jar we look up???). I guess the way this works is you would put a time out on the URL or something, you need to make guesses as to when the vm will be done loading from this puppy which is never in the case of JMX and SL CL architectures. A problem will be slow classloading in the JMX/SL base (it will affect 2.4 and 3.0) as you will ask CL to look for classes in connections that are closed... h we are going to need smart CLs... at least with indexing, yes... indexing of cl contents to allow for fast clusterwide lookups h me likes... do you see these? is there a way to create a default jar tvf (t being the important one here) and allowing for indexing PER Cl, that would dramaticaly improve the speed of our superservers as well as solve the above problem. but in any case until we know what it takes to open and close a connection that would be the simplest. Go ahead and also try to get some number on how much time to open one connection to file/10 connections/ lookup a class randomly in the 10 that are there... if you get that in time for the rewrite it would really make the work simple. marcf | |/Rickard | |-- |Rickard Öberg | ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Installer / Deployer Problem
rickard, following my own mantra of communicate simple, go right ahead and create a URLConnection that closes the connection after some time or every time, maybe even every time is enough. That will solve our problem for sure the vm will not be holding on to connections to the file system and we will be able to hotdeploy on the original files. The discussion I have below only affects loading times when new classes are deployed and we can always measure that and deal with it. So KISS the URL. marcf |-Original Message- |From: [EMAIL PROTECTED] |[mailto:[EMAIL PROTECTED]]On Behalf Of marc |fleury |Sent: Tuesday, November 27, 2001 12:14 PM |To: Rickard Öberg |Cc: Andreas Schaefer; [EMAIL PROTECTED] |Subject: RE: [JBoss-dev] Installer / Deployer Problem | | ||It's not fixed. Marc, do you remember when we were at J1 and talked to ||your french friend that said something about it being a security hole if ||it was fixed. Or something like that. | |Are you sure it is not fixed? as in you verified or as in you took |what this |guy said at face value (name is jc collet btw), I wouldn't trust everything |he said :) you know we were friends and all but... | ||I've been thinking about this problem though. Wouldn't it be possible to ||make a custom URL handler that returns a connection wrapper that we can ||drop under the covers. I.e. even if the URLClassLoader hangs onto it, we ||can still close the file under the covers. I think that would make it ||work, and wouldn't be *that* intrusive in the code. | |sure, that is an idea and it would simplify the code a lot. The problem I |see is that I suspect they keep the connection opened for classloading |reasons, i.e. the VM asks for loading classes at random times. |Reopening the |connection seems slow (the security hole would be the capability to change |the jar we look up???). | |I guess the way this works is you would put a time out on the URL or |something, you need to make guesses as to when the vm will be done loading |from this puppy which is never in the case of JMX and SL CL architectures. | |A problem will be slow classloading in the JMX/SL base (it will affect 2.4 |and 3.0) as you will ask CL to look for classes in connections that are |closed... h we are going to need smart CLs... at least with |indexing, yes... indexing of cl contents to allow for fast clusterwide |lookups h me likes... do you see these? is there a way to create a |default jar tvf (t being the important one here) and allowing for indexing |PER Cl, that would dramaticaly improve the speed of our |superservers as well |as solve the above problem. | |but in any case until we know what it takes to open and close a connection |that would be the simplest. | |Go ahead and also try to get some number on how much time to open one |connection to file/10 connections/ lookup a class randomly in the 10 that |are there... if you get that in time for the rewrite it would really make |the work simple. | |marcf | | || ||/Rickard || ||-- ||Rickard Öberg || | | |___ |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] [ jboss-Bugs-486081 ] cluster-service.xml not in 3.0 alpha kit
Bugs item #486081, was opened at 2001-11-27 09:36 You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=376685aid=486081group_id=22866 Category: Build System Group: v2.5 Rabbit Hole (unstable) Status: Open Resolution: None Priority: 5 Submitted By: Alan Lewis (alanlewis) Assigned to: Jason Dillon (user57) Summary: cluster-service.xml not in 3.0 alpha kit Initial Comment: A file that is required to enable clustering, cluster-service.xml, is not included in the 3.0.0alpha kit. In order to enable clustering you have to get this file from CVS. You could technically write one yourself, but there is no information in the docs on how to do this, so it would be pretty difficult. It looks as though this file should go under conf/cluster, but this directory is empty in the kit. -- You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=376685aid=486081group_id=22866 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Installer / Deployer Problem
Hi I don't see the point here. The copying of the file is done when it get deployed and this is a rare occurance. When you now have to open/close the connection to the URL then it can affect the overall performance which I think is the worse that to copy the file. Also the file must inflated anyway and do I miss something ? Andy - Original Message - From: marc fleury [EMAIL PROTECTED] To: Rickard Öberg [EMAIL PROTECTED] Cc: Andreas Schaefer [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Tuesday, November 27, 2001 9:13 AM Subject: RE: [JBoss-dev] Installer / Deployer Problem |It's not fixed. Marc, do you remember when we were at J1 and talked to |your french friend that said something about it being a security hole if |it was fixed. Or something like that. Are you sure it is not fixed? as in you verified or as in you took what this guy said at face value (name is jc collet btw), I wouldn't trust everything he said :) you know we were friends and all but... |I've been thinking about this problem though. Wouldn't it be possible to |make a custom URL handler that returns a connection wrapper that we can |drop under the covers. I.e. even if the URLClassLoader hangs onto it, we |can still close the file under the covers. I think that would make it |work, and wouldn't be *that* intrusive in the code. sure, that is an idea and it would simplify the code a lot. The problem I see is that I suspect they keep the connection opened for classloading reasons, i.e. the VM asks for loading classes at random times. Reopening the connection seems slow (the security hole would be the capability to change the jar we look up???). I guess the way this works is you would put a time out on the URL or something, you need to make guesses as to when the vm will be done loading from this puppy which is never in the case of JMX and SL CL architectures. A problem will be slow classloading in the JMX/SL base (it will affect 2.4 and 3.0) as you will ask CL to look for classes in connections that are closed... h we are going to need smart CLs... at least with indexing, yes... indexing of cl contents to allow for fast clusterwide lookups h me likes... do you see these? is there a way to create a default jar tvf (t being the important one here) and allowing for indexing PER Cl, that would dramaticaly improve the speed of our superservers as well as solve the above problem. but in any case until we know what it takes to open and close a connection that would be the simplest. Go ahead and also try to get some number on how much time to open one connection to file/10 connections/ lookup a class randomly in the 10 that are there... if you get that in time for the rewrite it would really make the work simple. marcf | |/Rickard | |-- |Rickard Öberg | ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Installer / Deployer Problem
|-Original Message- |From: Andreas Schaefer [mailto:[EMAIL PROTECTED]] |Sent: Tuesday, November 27, 2001 12:57 PM |To: marc fleury; Rickard Öberg |Cc: [EMAIL PROTECTED] |Subject: Re: [JBoss-dev] Installer / Deployer Problem | | |Hi | |I don't see the point here. The copying of the file is done when it get |deployed |and this is a rare occurance. When you now have to open/close the It really slows down large deployment. Copying 2 meg is just bad. Again packaging madness. |connection |to the URL then it can affect the overall performance which I think is the |worse |that to copy the file. |Also the file must inflated anyway and do I miss something ? it's a point, I don't care either way. But when do you need to inflate and why? refresh my memory marcf | |Andy | |- Original Message - |From: marc fleury [EMAIL PROTECTED] |To: Rickard Öberg [EMAIL PROTECTED] |Cc: Andreas Schaefer [EMAIL PROTECTED]; |[EMAIL PROTECTED] |Sent: Tuesday, November 27, 2001 9:13 AM |Subject: RE: [JBoss-dev] Installer / Deployer Problem | | | |It's not fixed. Marc, do you remember when we were at J1 and talked to | |your french friend that said something about it being a security hole if | |it was fixed. Or something like that. | | Are you sure it is not fixed? as in you verified or as in you took what |this | guy said at face value (name is jc collet btw), I wouldn't trust |everything | he said :) you know we were friends and all but... | | |I've been thinking about this problem though. Wouldn't it be possible to | |make a custom URL handler that returns a connection wrapper that we can | |drop under the covers. I.e. even if the URLClassLoader hangs onto it, we | |can still close the file under the covers. I think that would make it | |work, and wouldn't be *that* intrusive in the code. | | sure, that is an idea and it would simplify the code a lot. The |problem I | see is that I suspect they keep the connection opened for classloading | reasons, i.e. the VM asks for loading classes at random times. Reopening |the | connection seems slow (the security hole would be the capability |to change | the jar we look up???). | | I guess the way this works is you would put a time out on the URL or | something, you need to make guesses as to when the vm will be |done loading | from this puppy which is never in the case of JMX and SL CL |architectures. | | A problem will be slow classloading in the JMX/SL base (it will |affect 2.4 | and 3.0) as you will ask CL to look for classes in connections that are | closed... h we are going to need smart CLs... at least with | indexing, yes... indexing of cl contents to allow for fast clusterwide | lookups h me likes... do you see these? is there a way |to create a | default jar tvf (t being the important one here) and allowing |for indexing | PER Cl, that would dramaticaly improve the speed of our superservers as |well | as solve the above problem. | | but in any case until we know what it takes to open and close a |connection | that would be the simplest. | | Go ahead and also try to get some number on how much time to open one | connection to file/10 connections/ lookup a class randomly in the 10 that | are there... if you get that in time for the rewrite it would |really make | the work simple. | | marcf | | | | | |/Rickard | | | |-- | |Rickard Öberg | | | | ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Installer / Deployer Problem
On 2001.11.27 13:34:31 -0500 marc fleury wrote: |-Original Message- |From: Andreas Schaefer [mailto:[EMAIL PROTECTED]] |Sent: Tuesday, November 27, 2001 12:57 PM |To: marc fleury; Rickard Öberg |Cc: [EMAIL PROTECTED] |Subject: Re: [JBoss-dev] Installer / Deployer Problem | | |Hi | |I don't see the point here. The copying of the file is done when it get |deployed |and this is a rare occurance. When you now have to open/close the It really slows down large deployment. Copying 2 meg is just bad. Again packaging madness. |connection |to the URL then it can affect the overall performance which I think is the |worse |that to copy the file. |Also the file must inflated anyway and do I miss something ? it's a point, I don't care either way. But when do you need to inflate and why? refresh my memory You may not need to inflate a jar, but rar, ear, and now sar have jars inside them. Unless someone can come up with a way to get classes out of them using a jar:jar:jar:http://.!/!/!/ url we need to unpack them. If network speed is the problem here, how can it possibly be faster after deployment to use a remote url rather than a local copy? Otherwise are you sure it is file copying that is taking the time? So far I agree with Andy. david jencks marcf | |Andy | |- Original Message - |From: marc fleury [EMAIL PROTECTED] |To: Rickard Öberg [EMAIL PROTECTED] |Cc: Andreas Schaefer [EMAIL PROTECTED]; |[EMAIL PROTECTED] |Sent: Tuesday, November 27, 2001 9:13 AM |Subject: RE: [JBoss-dev] Installer / Deployer Problem | | | |It's not fixed. Marc, do you remember when we were at J1 and talked to | |your french friend that said something about it being a security hole if | |it was fixed. Or something like that. | | Are you sure it is not fixed? as in you verified or as in you took what |this | guy said at face value (name is jc collet btw), I wouldn't trust |everything | he said :) you know we were friends and all but... | | |I've been thinking about this problem though. Wouldn't it be possible to | |make a custom URL handler that returns a connection wrapper that we can | |drop under the covers. I.e. even if the URLClassLoader hangs onto it, we | |can still close the file under the covers. I think that would make it | |work, and wouldn't be *that* intrusive in the code. | | sure, that is an idea and it would simplify the code a lot. The |problem I | see is that I suspect they keep the connection opened for classloading | reasons, i.e. the VM asks for loading classes at random times. Reopening |the | connection seems slow (the security hole would be the capability |to change | the jar we look up???). | | I guess the way this works is you would put a time out on the URL or | something, you need to make guesses as to when the vm will be |done loading | from this puppy which is never in the case of JMX and SL CL |architectures. | | A problem will be slow classloading in the JMX/SL base (it will |affect 2.4 | and 3.0) as you will ask CL to look for classes in connections that are | closed... h we are going to need smart CLs... at least with | indexing, yes... indexing of cl contents to allow for fast clusterwide | lookups h me likes... do you see these? is there a way |to create a | default jar tvf (t being the important one here) and allowing |for indexing | PER Cl, that would dramaticaly improve the speed of our superservers as |well | as solve the above problem. | | but in any case until we know what it takes to open and close a |connection | that would be the simplest. | | Go ahead and also try to get some number on how much time to open one | connection to file/10 connections/ lookup a class randomly in the 10 that | are there... if you get that in time for the rewrite it would |really make | the work simple. | | marcf | | | | | |/Rickard | | | |-- | |Rickard Öberg | | | | ___ 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] [ANN] JBoss 3.0 alpha is out
Actually the latest works fine. I didnt even get a chance to look at the src before it was fixed :) [EMAIL PROTECTED] wrote: 2. if you sync yourself with the cvs tree you will get an upgrade to Jetty4. I am much happier with the Security integration in this version. If the problem lies with Jetty itself ask Greg whether the fix has gone into Jetty4 - Greg ? You really should sync, if you can - because lots of stuff has gone into my integration since 3.0alpha was released. ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development __ Do You Yahoo!? Everything you'll ever need on one web page from News and Sport to Email and Music Charts http://uk.my.yahoo.com ___ 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] Installer / Deployer Problem
marc fleury wrote: |It's not fixed. Marc, do you remember when we were at J1 and talked to |your french friend that said something about it being a security hole if |it was fixed. Or something like that. Are you sure it is not fixed? as in you verified or as in you took what this guy said at face value (name is jc collet btw), I wouldn't trust everything he said :) you know we were friends and all but... Haven't checked, but can't imagine that it's been fixed... still, would be nice with a solution that works on 1.3 too. |I've been thinking about this problem though. Wouldn't it be possible to |make a custom URL handler that returns a connection wrapper that we can |drop under the covers. I.e. even if the URLClassLoader hangs onto it, we |can still close the file under the covers. I think that would make it |work, and wouldn't be *that* intrusive in the code. sure, that is an idea and it would simplify the code a lot. The problem I see is that I suspect they keep the connection opened for classloading reasons, i.e. the VM asks for loading classes at random times. Reopening the connection seems slow (the security hole would be the capability to change the jar we look up???). That's irrelevant. It's ok that they hold on to the connection. It's not ok that there's no way to flush that cache. What our custom URL handler would buy us is that we can close the underlying connections explicitly as needed. If there's another call on the connection we would reopen it, but during the time it is closed we can replace the underlying JAR. I guess the way this works is you would put a time out on the URL or something, you need to make guesses as to when the vm will be done loading from this puppy which is never in the case of JMX and SL CL architectures. Nope, just an explicit way of closing the connections and thus disregarding how the URLClassLoader connection cache does things. A problem will be slow classloading in the JMX/SL base (it will affect 2.4 and 3.0) as you will ask CL to look for classes in connections that are closed... h we are going to need smart CLs... at least with indexing, yes... indexing of cl contents to allow for fast clusterwide lookups h me likes... do you see these? is there a way to create a default jar tvf (t being the important one here) and allowing for indexing PER Cl, that would dramaticaly improve the speed of our superservers as well as solve the above problem. blah blah blah... nonsense. Not a problem, see above. The only thing that's important is that we can *close* them when *we* want to. Other than that its fine that the URLCL hangs onto open connections. /Rickard -- Rickard Öberg ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Installer / Deployer Problem
marc fleury wrote: following my own mantra of communicate simple, go right ahead and create a URLConnection that closes the connection after some time or every time, maybe even every time is enough. See previous email. No guessing is needed. All the connection needs is that when we explicitly say close() goddammit it will close the underlying connection, so that we can remove the file that it was pointing to. The discussion I have below only affects loading times when new classes are deployed and we can always measure that and deal with it. So KISS the URL. There would be no loading time problems. See previous descriptions. /Rickard -- Rickard Öberg ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Installer / Deployer Problem
marc fleury wrote: not that I know, the original deployer was a piece of crap anyway, fix this if you want. BTW is the URL caching thing FIXED in 1.4 JDK or not? if so we could require the 1.4 VM for proper behavior of the deployer I think it would greatly simplify the design as we wouldn't need to copy the files over. It's not fixed. Marc, do you remember when we were at J1 and talked to your french friend that said something about it being a security hole if it was fixed. Or something like that. I've been thinking about this problem though. Wouldn't it be possible to make a custom URL handler that returns a connection wrapper that we can drop under the covers. I.e. even if the URLClassLoader hangs onto it, we can still close the file under the covers. I think that would make it work, and wouldn't be *that* intrusive in the code. /Rickard -- Rickard Öberg ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] (rh) Can we combine j2ee and jboss dds with xsl toget just one dd?
what if we use xslt to transform the deploymentdescriptors to jdk1.4's longterm persistence format and let the task of parsing the xml and instantiating the metadata beans to the java.beans.XMLDecoder .. this would at least enhance maintainability. Very interesting idea. I was playing with using jaxb for xml to object conversion, although there may be license issues with it. Offhand, it looks to me as if using the jdk 1.4 persistence format (I just read about it for 5 min or so) would involve some pretty heavy-duty xml transformations and require jdk 1.4. Jaxb appears (in very preliminary experiments) to be able to generate classes from the ejb 2 dtd and jbosscmp-jdbc dtd. sooo.. --jaxb requires using specially generated base classes but requires minimal xml transformation. License may make it unavailable ( anyone else have an opinion about this???) Probably the simplest thing to glue these things would be using Castor with custom mapping and/or autogenerated classes. (JAXB seems to be an effort to standardize Castor-like technologies from various players in the field. From what I remember Exolab (or Intalio, or whatever their current name is) was a member of this JSR. Castor has a mode where you write your custom class hierarchy that would be used to represent an XML in object tree form. Then you write a special XML file which describes how these classes are mapped into XML entities and attributes. Then you can simple use a Marshaller or Unmarshaller to store/restore an object tree to/from XML. The other mode that Castor provides, is auto-generation of classes that would represent any valid instance of an XML file that conforms to a given XML Schema from which the classes are generated. This is, in a way, a way for the lazy guys to get around learning SAX or DOM (exactly what I did). And this is what JAXB seems to promise at the moment. Though, JAXB only works with dtds at the moment, while Castor can already deal with XML Schemas which are far more expressive than DTDs. In my current project I am using auto-generated classes for J2EE and JBoss descriptors (J2EE 1.1 and JBoss 2.2 or something like that). As a head start I can provide XML Schemas which I've used to produce the class hierarchies with Castor. For some custom XML descriptors that I am using to store my project's metadata, I have written custom classes and used mapping technique of Castor. I can share my experiences with those as well. It is a solid technology, though, I am glad I did not have to mess with SAX or DOM. This is how you would glue several files together. Say you have ejb-jar.xml jboss.xml jaws.xml You unmarshal all 3 files and get 3 objects, say, instances of jboss.xml.j2ee.EjbJar jboss.xml.jbossconf.Jboss jboss.xml.jbossconf.Jaws Then you create a new instance of a class (which is also marshallable by Castor), say jboss.xml.SuperJBoss and add the above 3 objects into that newly created objects with appropriate set() methods. then marshal SuperJBoss into a file, say super-jboss.xml Vice versa it is similar: unmarshal SuperJBoss from an XML file. Obtain subcomponents with appropriate getters, store them individually in each one's XML file. Voila. (Well, sort of) Anatoly. --jdk 1.4 persistence can use regular classes but requires a lot of xsl, and jdb 1.4. Any one have experience with both or at least an opinion? Thanks david jencks Good idea or am I nuts? .. definately I am ;-) Holger ___ 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] Installer / Deployer Problem
On Tue, 27 Nov 2001, Rickard [ISO-8859-1] Öberg wrote: Andreas Schaefer wrote: I don't see the point here. The copying of the file is done when it get deployed and this is a rare occurance. When you now have to open/close the connection to the URL then it can affect the overall performance which I think is the worse that to copy the file. The open/close only happens at deploy time, so no problem Also the file must inflated anyway and do I miss something ? AFAIK the file would *not* have to be inflated. What are the reasons it must be inflated? See David Jencks previous message in this thread where he said it is needed for ears, sars and any other JAR archive which has nested JAR archives in them which have to be used by a CL. So, inflating is needed unless you dump standard j2ee packaging (which, in fact, we are discussing in a different thread, well we would need it for backward compatibility but still) or come up with a way of (getting inside a jar)* to reach another jar without inflating them. ^^regex^^^ Packaging sucks... Anatoly. /Rickard -- Rickard Öberg ___ 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] JMS issues re: stopservice, jndi names
Does anyone know if it's actually legal for JMS topics/queues to have structure? I was making the change for binding subcontexts automatically (using org.jboss.naming.Util). And it deploys fine. But, if I kill jboss and restart it (without my sar that defines the queue in deploy), it throws exceptions because it finds a directory in the db/messaging/QUEUE.mycompany/myqueue The queue was mycompany/myqueue, which was created correctly as db/messaging/QUEUE.mycompany/myqueue/ I can only assume that the queue restoration only looks one level deep. And attempts to restore a queue (even though the queue is not in any DD anymore) I'm just trying to understand what all should be fixed. So, questions of the day are : 1) Can a queuename have depth? 2) Should all queues be restored at jboss startup regardless of if they are needed anymore? 2a) Or when the MBEAN descriptor is located? -David On Tue, 27 Nov 2001, Hiram Chirino wrote: From: David Jencks [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] JMS issues re: stopservice, jndi names Date: Mon, 26 Nov 2001 23:26:02 -0500 On 2001.11.26 22:50:55 -0500 David Budworth wrote: Hi all, There are two things bugging me right now in JMS, and I just wanted to know if anyone is working on them, or if they need to be fixed at all. The first one, is pretty obviously a 'needs-to-be-done'. You can't current undeploy a queue/topic. In my sar, I define the JMS queues that the services use, and when I undeploy the .sar, the log says queue stop not yet implemented. The problem this causes is that once you delete the SAR, the queue name disappears from the 8082 UI, but, if you attempt to re-deploy the SAR, or just create the queue via the 8082 UI, you'll get a an error stating the topic/queue already exists. So it seems that on undeploy, the internal stuctures of JBossMQ gets fux0r3d (in script-kiddie speak). I'd be happy to work on this (since I need it). I just didn't know if anyone else was already doing it. Nor do I really know where to start on it. I'm not the most expert... but I think the queue stop method needs to arrange with the JMSService to stop accepting messages and possibly with the persistence manager to make sure everything is stably saved that should be. Make sure all open transactions are ended before shutting down! Sounds about right. The second one is just something that bothers me, which is if you specify a queue name like: mycompany/queuea You will get a name not bound exception on mycompany. For EJBs this works correctly, where the subcontexts are created on the fly as need be. But for JMS it doesn't. I'd also like to add this, since I don't like having the JMS topics/queues in a flat namespace. I'm not sure if this is by spec though. Are you not allowed to create a heirarchy for the queue/topic names? If I create transient topics, I can do it if I pre-create the subcontexts. So I know it 'works', I'm just not sure it's legal. Also, is there some helper code somewhere in jboss to create a JNDI tree already? Or does everyone just roll there own with tokenizers or something? I feel like I've seen 10 or twenty implementations of this, but its probably just 3 or 4;-) They are often in Deployers. Could we put one version in either DeployerMBeanSupport or ServiceMBeanSupport? The MBean classes don't seem to ME to be the right place for the kind of code. Maybe a new JNDISupport in the org.jboss.util?? Regards, Hiram David Jencks -David ___ 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 _ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp ___ 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] (rh) Can we combine j2ee and jboss dds with xsl to get just one dd?
On 2001.11.27 15:38:07 -0500 Anatoly Akkerman wrote: what if we use xslt to transform the deploymentdescriptors to jdk1.4's longterm persistence format and let the task of parsing the xml and instantiating the metadata beans to the java.beans.XMLDecoder .. this would at least enhance maintainability. Very interesting idea. I was playing with using jaxb for xml to object conversion, although there may be license issues with it. Offhand, it looks to me as if using the jdk 1.4 persistence format (I just read about it for 5 min or so) would involve some pretty heavy-duty xml transformations and require jdk 1.4. Jaxb appears (in very preliminary experiments) to be able to generate classes from the ejb 2 dtd and jbosscmp-jdbc dtd. sooo.. --jaxb requires using specially generated base classes but requires minimal xml transformation. License may make it unavailable ( anyone else have an opinion about this???) Probably the simplest thing to glue these things would be using Castor with custom mapping and/or autogenerated classes. (JAXB seems to be an effort to standardize Castor-like technologies from various players in the field. From what I remember Exolab (or Intalio, or whatever their current name is) was a member of this JSR. Castor has a mode where you write your custom class hierarchy that would be used to represent an XML in object tree form. Then you write a special XML file which describes how these classes are mapped into XML entities and attributes. Then you can simple use a Marshaller or Unmarshaller to store/restore an object tree to/from XML. The other mode that Castor provides, is auto-generation of classes that would represent any valid instance of an XML file that conforms to a given XML Schema from which the classes are generated. This is, in a way, a way for the lazy guys to get around learning SAX or DOM (exactly what I did). And this is what JAXB seems to promise at the moment. Though, JAXB only works with dtds at the moment, while Castor can already deal with XML Schemas which are far more expressive than DTDs. In my current project I am using auto-generated classes for J2EE and JBoss descriptors (J2EE 1.1 and JBoss 2.2 or something like that). As a head start I can provide XML Schemas which I've used to produce the class hierarchies with Castor. For some custom XML descriptors that I am using to store my project's metadata, I have written custom classes and used mapping technique of Castor. I can share my experiences with those as well. It is a solid technology, though, I am glad I did not have to mess with SAX or DOM. This is how you would glue several files together. Say you have ejb-jar.xml jboss.xml jaws.xml You unmarshal all 3 files and get 3 objects, say, instances of jboss.xml.j2ee.EjbJar jboss.xml.jbossconf.Jboss jboss.xml.jbossconf.Jaws Then you create a new instance of a class (which is also marshallable by Castor), say jboss.xml.SuperJBoss and add the above 3 objects into that newly created objects with appropriate set() methods. then marshal SuperJBoss into a file, say super-jboss.xml Vice versa it is similar: unmarshal SuperJBoss from an XML file. Obtain subcomponents with appropriate getters, store them individually in each one's XML file. Voila. (Well, sort of) Anatoly. Can Castor merge nested attributes from all the files into one object? For instance, there are elements under ejb-jar/enterprise-beans/entity and jboss-cmp/enterprise-beans/entity that should all end up in result-dd/enterprise-beans/entity. Just having copies of all 3 docs in the super-jboss is probably easier with including an xml entity;-) david jencks ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] JMS issues re: stopservice, jndi names
Sorry to follow up my own message, but I need another question answered. Note: In the previous message, I was incorrectly saying db/messaging, it's really db/jbossmq/file Is it possible to have queues named: companyA companyA/myqueue1 companyA/myqueue2 I'm changing (in anticipation that deep queues are valid), the file pm for queues. It currently just get's a list of all files in db/jbossmq/file/ Then attempts to restore the MessageLogs for each file in that list. When MessageLog attempts to restore, it just looks for a . in the name (ie: QUEUE.bob), and restores all messages files in that dir, if no . is there it assumes the file is a message log and attempts to restore it directly, which is why my stuff is failing, because it looks like QUEUE.companyA/myqueue1/* But the restoration code assumes myqueue1 is a file, and not a subdir (because no .) It seems to me, that a much easier fix is to not restore the queue on startup, but instead restore in when the DD is deployed. But I suppose there may be a need to restore a queue before it's actually defined? The auto-restored queues doesn't show up in the 8082 UI (BTW what's that called?). So I am not sure why the PM is creating an instance of MessageLog for them at startup. Am I just not getting it? -David On Tue, 27 Nov 2001, David Budworth wrote: Does anyone know if it's actually legal for JMS topics/queues to have structure? I was making the change for binding subcontexts automatically (using org.jboss.naming.Util). And it deploys fine. But, if I kill jboss and restart it (without my sar that defines the queue in deploy), it throws exceptions because it finds a directory in the db/messaging/QUEUE.mycompany/myqueue The queue was mycompany/myqueue, which was created correctly as db/messaging/QUEUE.mycompany/myqueue/ I can only assume that the queue restoration only looks one level deep. And attempts to restore a queue (even though the queue is not in any DD anymore) I'm just trying to understand what all should be fixed. So, questions of the day are : 1) Can a queuename have depth? 2) Should all queues be restored at jboss startup regardless of if they are needed anymore? 2a) Or when the MBEAN descriptor is located? -David On Tue, 27 Nov 2001, Hiram Chirino wrote: From: David Jencks [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] JMS issues re: stopservice, jndi names Date: Mon, 26 Nov 2001 23:26:02 -0500 On 2001.11.26 22:50:55 -0500 David Budworth wrote: Hi all, There are two things bugging me right now in JMS, and I just wanted to know if anyone is working on them, or if they need to be fixed at all. The first one, is pretty obviously a 'needs-to-be-done'. You can't current undeploy a queue/topic. In my sar, I define the JMS queues that the services use, and when I undeploy the .sar, the log says queue stop not yet implemented. The problem this causes is that once you delete the SAR, the queue name disappears from the 8082 UI, but, if you attempt to re-deploy the SAR, or just create the queue via the 8082 UI, you'll get a an error stating the topic/queue already exists. So it seems that on undeploy, the internal stuctures of JBossMQ gets fux0r3d (in script-kiddie speak). I'd be happy to work on this (since I need it). I just didn't know if anyone else was already doing it. Nor do I really know where to start on it. I'm not the most expert... but I think the queue stop method needs to arrange with the JMSService to stop accepting messages and possibly with the persistence manager to make sure everything is stably saved that should be. Make sure all open transactions are ended before shutting down! Sounds about right. The second one is just something that bothers me, which is if you specify a queue name like: mycompany/queuea You will get a name not bound exception on mycompany. For EJBs this works correctly, where the subcontexts are created on the fly as need be. But for JMS it doesn't. I'd also like to add this, since I don't like having the JMS topics/queues in a flat namespace. I'm not sure if this is by spec though. Are you not allowed to create a heirarchy for the queue/topic names? If I create transient topics, I can do it if I pre-create the subcontexts. So I know it 'works', I'm just not sure it's legal. Also, is there some helper code somewhere in jboss to create a JNDI tree already? Or does everyone just roll there own with tokenizers or something? I feel like I've seen 10 or twenty implementations of this, but its probably just 3 or 4;-) They are often in Deployers. Could we put one version in either DeployerMBeanSupport or ServiceMBeanSupport? The MBean classes don't seem to ME to be the right place for the kind of code. Maybe a new JNDISupport in the org.jboss.util??
Re: [JBoss-dev] Installer / Deployer Problem
marc fleury wrote: |The open/close only happens at deploy time, so no problem You don't get it, the cl arch of 3.0 asks all the cls in case a class is not there, so well beyond the deployment if a class is not loaded during that deployment we might have problems... if everything is loaded at deployment time then we will be ok. No, you don't get it. Please reread my previous posts. The connection will be open pretty much all of the time. The only time it will be closed is during deploy time. Hence, no problem. /R -- Rickard Öberg ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] (rh) Can we combine j2ee and jboss dds with xsl toget just one dd?
Can Castor merge nested attributes from all the files into one object? For instance, there are elements under ejb-jar/enterprise-beans/entity and jboss-cmp/enterprise-beans/entity that should all end up in result-dd/enterprise-beans/entity. Not that I know of. Doing XSLT, would, probably be the best way for such processing. Castor can only instantiate a new object tree that represents a given XML file. It cannot 'update' an existing tree from this 'incremental' unmarshalling. In general it is an impossible task. Think about it. Castor (or any other software) would have to know which pieces match where. Say, in the case of ejb descriptors, it would not be enough to match and entity /entity from ejb-jar.xml with entity /entity from jboss.xml. You would have to match _names_ and whatever else to make sure you are updating descriptor object for the right entity bean. This already is _semantic_ interpretation of what stands behind the data in the XML file. You can only write a custom combiner that would take 3 object trees (say, from ejb-jar.xml, jboss.xml and jaws.xml) and produce a combined tree, matching appripriate descriptors by hand. Actually, I don't know if XSLT will to that for you, it also does not know anything about the semantics of the XML files you are combining. It seems to me, this must be a custom combining solution. Anatoly. Just having copies of all 3 docs in the super-jboss is probably easier with including an xml entity;-) david jencks ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Installer / Deployer Problem
| You don't get it, the cl arch of 3.0 asks all the cls in case a |class is not | there, so well beyond the deployment if a class is not loaded |during that | deployment we might have problems... if everything is loaded at |deployment | time then we will be ok. | | |No, you don't get it. Please reread my previous posts. The connection |will be open pretty much all of the time. The only time it will be |closed is during deploy time. Hence, no problem. ok one of us doesn't get it, if you are open most of the time how do you release the lock in the filesystem for anyone to overwrite the file ? I could be missing it :) marcf | |/R | |-- |Rickard Öberg | | ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] JMS issues re: stopservice, jndi names
On 2001.11.27 15:55:06 -0500 David Budworth wrote: Does anyone know if it's actually legal for JMS topics/queues to have structure? I was making the change for binding subcontexts automatically (using org.jboss.naming.Util). And it deploys fine. But, if I kill jboss and restart it (without my sar that defines the queue in deploy), it throws exceptions because it finds a directory in the db/messaging/QUEUE.mycompany/myqueue The queue was mycompany/myqueue, which was created correctly as db/messaging/QUEUE.mycompany/myqueue/ I can only assume that the queue restoration only looks one level deep. And attempts to restore a queue (even though the queue is not in any DD anymore) I'm just trying to understand what all should be fixed. So, questions of the day are : 1) Can a queuename have depth? 2) Should all queues be restored at jboss startup regardless of if they are needed anymore? 2a) Or when the MBEAN descriptor is located? The startup is in 2 phases. When the pm is started, it pre-restores all the queues it can find, figures out which messages weren't committed (btw I'm not convinced it handles prepared but not committed properly), and makes lists of undelivered messages. Then when each queue starts, it registers with the pm and gets its list of messages. For topics, if I remember correctly, the queue representing the topic asks the StateManager for all the subscriber queues and restores each one individually. In regards to (2), there is no way to tell if a queue is needed anymore. The mbeans for the queues are not necessarily in the same file as the mbean for the pm, and could be deployed hours or days later. On the other hand, the cleanup of uncommitted messages should happen as soon as the pm is started, so you don't need to keep dead data around indefinitely. david jencks -David ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] (rh) Can we combine j2ee and jboss dds with xsl to get just one dd?
On 2001.11.27 16:37:20 -0500 Anatoly Akkerman wrote: Can Castor merge nested attributes from all the files into one object? For instance, there are elements under ejb-jar/enterprise-beans/entity and jboss-cmp/enterprise-beans/entity that should all end up in result-dd/enterprise-beans/entity. Not that I know of. Doing XSLT, would, probably be the best way for such processing. Castor can only instantiate a new object tree that represents a given XML file. It cannot 'update' an existing tree from this 'incremental' unmarshalling. In general it is an impossible task. Think about it. Castor (or any other software) would have to know which pieces match where. Say, in the case of ejb descriptors, it would not be enough to match and entity /entity from ejb-jar.xml with entity /entity from jboss.xml. You would have to match _names_ and whatever else to make sure you are updating descriptor object for the right entity bean. This already is _semantic_ interpretation of what stands behind the data in the XML file. You can only write a custom combiner that would take 3 object trees (say, from ejb-jar.xml, jboss.xml and jaws.xml) and produce a combined tree, matching appripriate descriptors by hand. Actually, I don't know if XSLT will to that for you, it also does not know anything about the semantics of the XML files you are combining. It seems to me, this must be a custom combining solution. Well, I think I figured out all the hard parts of using xslt to combine them in this way. Since all the xml can be validated by a dtd I think it will work out fine. Castor instead of jaxb might be an option still, though. I'd prefer to use a standards based solution but if licensing makes it unavailable... david jencks Anatoly. Just having copies of all 3 docs in the super-jboss is probably easier with including an xml entity;-) david jencks ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] QueueConnectionFactory in Rabbit Hole
I beleive you should use ConnectionFactory nowadays. -Original Message- From: Hunter Hillegas [mailto:[EMAIL PROTECTED]] Sent: Wednesday, 28 November 2001 10:38 a.m. To: JBoss Dev Subject: [JBoss-dev] QueueConnectionFactory in Rabbit Hole Anyone know where QueueConnectionFactory lives in RH JNDI? I can't see it in JNDIView so I suppose it is not started by default? Has this mbean changed or can I just paste over 2.x code to get it in there? ___ 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] (rh)Possible consistency problem in jbosscmp-jdbc.dtd?
I'm wondering what the intent behind the eager-load and lazy-load-group is. I would think that you would want to partition the cmp-fields into one eager-load and 0 or more lazy-load groups. Is this correct? If so, the current xml structure makes it pretty easy to include fields into many of these groups. Is this intentional? What should happen in this case? If a partition is really desired, perhaps an alternate xml structure along the lines of !ELEMENT cmp-field (description?, field-name, column-name?, lazy-load-group?) !ELEMENT lazy-load-group EMPTY !ATTLIST lazy-load-group group CDATA #REQUIRED or !ELEMENT cmp-field (description?, field-name, column-name?, lazy-load-group?) !ELEMENT lazy-load-group #PCDATA would be more appropriate. cmp-fields without a lazy-load-group would be in the unique eager-load group. Any thoughts? david jencks ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] JMS issues re: stopservice, jndi names
So, why do we pre-restore the message queues? And not just restore them when a queue deploys? It seems to be a waste of memory to load an entire queue 'just in case' it gets deployed. Is there any reason why I couldn't just move the code from restoreTransactions() (which is called only by startService()) to restoreDestination() which currently seems to just take the messages out of the cache created by restoreTransactions(). -david On Tue, 27 Nov 2001, David Jencks wrote: On 2001.11.27 15:55:06 -0500 David Budworth wrote: Does anyone know if it's actually legal for JMS topics/queues to have structure? I was making the change for binding subcontexts automatically (using org.jboss.naming.Util). And it deploys fine. But, if I kill jboss and restart it (without my sar that defines the queue in deploy), it throws exceptions because it finds a directory in the db/messaging/QUEUE.mycompany/myqueue The queue was mycompany/myqueue, which was created correctly as db/messaging/QUEUE.mycompany/myqueue/ I can only assume that the queue restoration only looks one level deep. And attempts to restore a queue (even though the queue is not in any DD anymore) I'm just trying to understand what all should be fixed. So, questions of the day are : 1) Can a queuename have depth? 2) Should all queues be restored at jboss startup regardless of if they are needed anymore? 2a) Or when the MBEAN descriptor is located? The startup is in 2 phases. When the pm is started, it pre-restores all the queues it can find, figures out which messages weren't committed (btw I'm not convinced it handles prepared but not committed properly), and makes lists of undelivered messages. Then when each queue starts, it registers with the pm and gets its list of messages. For topics, if I remember correctly, the queue representing the topic asks the StateManager for all the subscriber queues and restores each one individually. In regards to (2), there is no way to tell if a queue is needed anymore. The mbeans for the queues are not necessarily in the same file as the mbean for the pm, and could be deployed hours or days later. On the other hand, the cleanup of uncommitted messages should happen as soon as the pm is started, so you don't need to keep dead data around indefinitely. david jencks -David ___ 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] Installer / Deployer Problem
marc fleury wrote: ok one of us doesn't get it, if you are open most of the time how do you release the lock in the filesystem for anyone to overwrite the file ? I could be missing it :) 1. URLCL wants to access custom://somejar.jar 2. It uses CustomURLHandler to get a connection to somejar.jar. This connection is put in cache and is never let go of. 3. The connection retrieved from CustomURLHandler is not a real connection, but merely a wrapper to a file connection. Similar to how a connection pool provides implementations of Connection that are only wrappers for real connections that can be managed by the pool. 4. Operations on the connection are passed on to the file connection. 5. When redeploy of a JAR is to be done, the wrapper is told to close its underlying connection 6. At this point there are no open connections to the JAR, so it can be replaced with a new file or removed. 7. At some point the connection wrapper is called, either by the old URLCL or a new one using the same connection. The file connection is then re-acquired, only now to the new file. See? /Rickard -- Rickard Öberg ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] JMS issues re: stopservice, jndi names
The JMS spec has nothing to say about JNDI namespace conventions for administered objects, so add support for this. There is an assumption of a flat namespace under queue and topic that needs to be generalized. Scott Stark Chief Technology Officer JBoss Group, LLC - Original Message - From: David Budworth [EMAIL PROTECTED] To: Hiram Chirino [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Tuesday, November 27, 2001 12:55 PM Subject: Re: [JBoss-dev] JMS issues re: stopservice, jndi names Does anyone know if it's actually legal for JMS topics/queues to have structure? I was making the change for binding subcontexts automatically (using org.jboss.naming.Util). And it deploys fine. But, if I kill jboss and restart it (without my sar that defines the queue in deploy), it throws exceptions because it finds a directory in the db/messaging/QUEUE.mycompany/myqueue The queue was mycompany/myqueue, which was created correctly as db/messaging/QUEUE.mycompany/myqueue/ I can only assume that the queue restoration only looks one level deep. And attempts to restore a queue (even though the queue is not in any DD anymore) I'm just trying to understand what all should be fixed. So, questions of the day are : 1) Can a queuename have depth? 2) Should all queues be restored at jboss startup regardless of if they are needed anymore? 2a) Or when the MBEAN descriptor is located? -David ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] JMS issues re: stopservice, jndi names
On 2001.11.27 16:32:05 -0500 David Budworth wrote: Sorry to follow up my own message, but I need another question answered. Note: In the previous message, I was incorrectly saying db/messaging, it's really db/jbossmq/file Is it possible to have queues named: companyA companyA/myqueue1 companyA/myqueue2 I'm changing (in anticipation that deep queues are valid), the file pm for queues. It currently just get's a list of all files in db/jbossmq/file/ Then attempts to restore the MessageLogs for each file in that list. When MessageLog attempts to restore, it just looks for a . in the name (ie: QUEUE.bob), and restores all messages files in that dir, if no . is there it assumes the file is a message log and attempts to restore it directly, which is why my stuff is failing, because it looks like QUEUE.companyA/myqueue1/* But the restoration code assumes myqueue1 is a file, and not a subdir (because no .) It seems to me, that a much easier fix is to not restore the queue on startup, but instead restore in when the DD is deployed. But I suppose there may be a need to restore a queue before it's actually defined? The auto-restored queues doesn't show up in the 8082 UI (BTW what's that called?). So I am not sure why the PM is creating an instance of MessageLog for them at startup. Am I just not getting it? You need to read in all the info pertaining to a particular pm when the pm is started so you can figure out what to do with incomplete transactions. Is there some way you can improve the naming conventions to make your nested queue names work without modifying the rest of the startup code? david jencks -David On Tue, 27 Nov 2001, David Budworth wrote: Does anyone know if it's actually legal for JMS topics/queues to have structure? I was making the change for binding subcontexts automatically (using org.jboss.naming.Util). And it deploys fine. But, if I kill jboss and restart it (without my sar that defines the queue in deploy), it throws exceptions because it finds a directory in the db/messaging/QUEUE.mycompany/myqueue The queue was mycompany/myqueue, which was created correctly as db/messaging/QUEUE.mycompany/myqueue/ I can only assume that the queue restoration only looks one level deep. And attempts to restore a queue (even though the queue is not in any DD anymore) I'm just trying to understand what all should be fixed. So, questions of the day are : 1) Can a queuename have depth? 2) Should all queues be restored at jboss startup regardless of if they are needed anymore? 2a) Or when the MBEAN descriptor is located? -David On Tue, 27 Nov 2001, Hiram Chirino wrote: From: David Jencks [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] JMS issues re: stopservice, jndi names Date: Mon, 26 Nov 2001 23:26:02 -0500 On 2001.11.26 22:50:55 -0500 David Budworth wrote: Hi all, There are two things bugging me right now in JMS, and I just wanted to know if anyone is working on them, or if they need to be fixed at all. The first one, is pretty obviously a 'needs-to-be-done'. You can't current undeploy a queue/topic. In my sar, I define the JMS queues that the services use, and when I undeploy the .sar, the log says queue stop not yet implemented. The problem this causes is that once you delete the SAR, the queue name disappears from the 8082 UI, but, if you attempt to re-deploy the SAR, or just create the queue via the 8082 UI, you'll get a an error stating the topic/queue already exists. So it seems that on undeploy, the internal stuctures of JBossMQ gets fux0r3d (in script-kiddie speak). I'd be happy to work on this (since I need it). I just didn't know if anyone else was already doing it. Nor do I really know where to start on it. I'm not the most expert... but I think the queue stop method needs to arrange with the JMSService to stop accepting messages and possibly with the persistence manager to make sure everything is stably saved that should be. Make sure all open transactions are ended before shutting down! Sounds about right. The second one is just something that bothers me, which is if you specify a queue name like: mycompany/queuea You will get a name not bound exception on mycompany. For EJBs this works correctly, where the subcontexts are created on the fly as need be. But for JMS it doesn't. I'd also like to add this, since I don't like having the JMS topics/queues in a flat namespace. I'm not sure if this is by spec though. Are you not allowed to create a heirarchy for the queue/topic names? If I create transient topics, I can do it if I pre-create the subcontexts. So I know it 'works', I'm just not sure it's legal. Also,
RE: [JBoss-dev] (rh)Possible consistency problem in jbosscmp-jdbc.dtd?
I'm wondering what the intent behind the eager-load and lazy-load-group is. I would think that you would want to partition the cmp-fields into one eager-load and 0 or more lazy-load groups. Is this correct? If so, the current xml structure makes it pretty easy to include fields into many of these groups. Is this intentional? What should happen in this case? This is intentional. An example is easier to explain. Let's say we have a product ejb with the following lazy load groups: lazy-load-groups lazy-load-group descriptionpricing info/description field-nameunit/field-name field-namecostPerUnit/field-name field-nameweight/field-name /lazy-load-group lazy-load-group descriptionshipping info/description field-namelength/field-name field-namegirth/field-name field-nameweight/field-name /lazy-load-group /lazy-load-groups If you access unit or costPerUnit, and it is unloaded, you get unit, costPerUnit and weight. If you first access Wight you, all of the above fields will be loaded. This allows you to have different groups with the same data. In the future I want each query to be able to have a different eager load group. I have been thinking that maybe, better to specify all groups. Then entity would have a eager-load with just a group named and the lazy-load-groups would have many names. The real reason for the change would be to add an eager-load element to the query element. Oh, eager/lazy loading of relationship foreign key fields is on my todo list. I have not decided how to structure this yet. What do you think? -dain ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Question regarding federated JNDI namespaces
Hello there. I am working with JBoss 3.0 and was hoping that somebody could answer a question for me regarding federated JNDI namespaces. Essentially, I am looking at using JBoss as a services framework and, if a J2EE application server is already in use (e.g., Weblogic or Websphere), sharing the JNDI namespace of the application server with JBoss via the ExternalContext MBean. I am not sure that I am using the right approach and was hoping that someone could help set me straight if I am mistaken, or direct me to where I can get answers on how to make this work. I first went into the jboss-service.xml file and, after the JNDIView MBean entry, added the following: !-- ===-- !-- External Context -- !-- -- mbean code=org.jboss.naming.ExternalContext name=DefaultDomain:service=ExternalContext,jndiName=external/beaWebLogic attribute name=JndiNameexternal/beaWebLogic/attribute attribute name=ProperitiesbeaWebLogicProperties/attribute attribute name=InitialContextjavax.naming.InitialContext/attribute !--attribute name=RemoteAccesstrue/attribute-- /mbean For the beaWebLogicProperties file, I provided the following two entries: java.naming.factory.initial=weblogic.jndi.WLInitialContextFactory java.naming.provider.url=t3://localhost:7001 Does JBoss allow you to create federated namespaces with only ldap or the file system, or does it allow you to share namespaces across application servers? If the answer is yes, and the above is correct, should I be doing something on the side of the application server itself that I am unaware of? Any help would be greatly appreciated. Thank you. Craig M. Parsons-Kerins LEXIGN Craig M. Parsons-Kerins Senior Software Engineer, Engineering Development 22 COTTON ROAD * NASHUA, NH * 03063 T 603.883.3800 x335 F 603.889.9259 mailto:[EMAIL PROTECTED] http://www.lexign.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Installer / Deployer Problem
|-Original Message- |From: [EMAIL PROTECTED] |[mailto:[EMAIL PROTECTED]]On Behalf Of |Rickard Oberg |Sent: Tuesday, November 27, 2001 5:24 PM |To: marc fleury |Cc: Andreas Schaefer; [EMAIL PROTECTED] |Subject: Re: [JBoss-dev] Installer / Deployer Problem | | |marc fleury wrote: | | ok one of us doesn't get it, if you are open most of the time |how do you | release the lock in the filesystem for anyone to overwrite the file ? I | could be missing it :) | I understand what you proposed what I don't understand is the above, see below :) |1. URLCL wants to access custom://somejar.jar |2. It uses CustomURLHandler to get a connection to somejar.jar. This |connection is put in cache and is never let go of. |3. The connection retrieved from CustomURLHandler is not a real |connection, but merely a wrapper to a file connection. Similar to how a |connection pool provides implementations of Connection that are only |wrappers for real connections that can be managed by the pool. |4. Operations on the connection are passed on to the file connection. |5. When redeploy of a JAR is to be done, the wrapper is told to close |its underlying connection Question: can you overwrite the jar if the vm holds a open connection to it and thus a lock to it in windows (file in usage)? If no which is my assumption for this discussion then you don't know when ANT is going to replace that file from JBoss, or when the user wants to drag and drop, it is an asynchronous operation that happens without your knowledge (won't happen in this case) |6. At this point there are no open connections to the JAR, so it can be |replaced with a new file or removed. no see above, you don't know *when* someone is going to replace the file so you can't be open most of the time. Do we agree here? |7. At some point the connection wrapper is called, either by the old |URLCL or a new one using the same connection. The file connection is |then re-acquired, only now to the new file. sure |See? almost, some googoo on my glasses still (or is it yours?) marcf | |/Rickard | | |-- |Rickard Öberg | | | |___ |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] JMS issues re: stopservice, jndi names
On 2001.11.27 17:21:31 -0500 David Budworth wrote: So, why do we pre-restore the message queues? And not just restore them when a queue deploys? It seems to be a waste of memory to load an entire queue 'just in case' it gets deployed. Is there any reason why I couldn't just move the code from restoreTransactions() (which is called only by startService()) to restoreDestination() which currently seems to just take the messages out of the cache created by restoreTransactions(). Maybe you can make it work. I didn't see any way to, and I couldn't figure out any way to test it either. So I tried to change it as little as possible. You will definitely have to keep track of the recovered transaction info until all queues are restored: detecting this may me another trick. I thought it was way simpler to process it all at once when the pm started. Why is this causing you problems? I don't see the connection to the namespace issues. david jencks -david On Tue, 27 Nov 2001, David Jencks wrote: On 2001.11.27 15:55:06 -0500 David Budworth wrote: Does anyone know if it's actually legal for JMS topics/queues to have structure? I was making the change for binding subcontexts automatically (using org.jboss.naming.Util). And it deploys fine. But, if I kill jboss and restart it (without my sar that defines the queue in deploy), it throws exceptions because it finds a directory in the db/messaging/QUEUE.mycompany/myqueue The queue was mycompany/myqueue, which was created correctly as db/messaging/QUEUE.mycompany/myqueue/ I can only assume that the queue restoration only looks one level deep. And attempts to restore a queue (even though the queue is not in any DD anymore) I'm just trying to understand what all should be fixed. So, questions of the day are : 1) Can a queuename have depth? 2) Should all queues be restored at jboss startup regardless of if they are needed anymore? 2a) Or when the MBEAN descriptor is located? The startup is in 2 phases. When the pm is started, it pre-restores all the queues it can find, figures out which messages weren't committed (btw I'm not convinced it handles prepared but not committed properly), and makes lists of undelivered messages. Then when each queue starts, it registers with the pm and gets its list of messages. For topics, if I remember correctly, the queue representing the topic asks the StateManager for all the subscriber queues and restores each one individually. In regards to (2), there is no way to tell if a queue is needed anymore. The mbeans for the queues are not necessarily in the same file as the mbean for the pm, and could be deployed hours or days later. On the other hand, the cleanup of uncommitted messages should happen as soon as the pm is started, so you don't need to keep dead data around indefinitely. david jencks -David ___ 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] NPE when using DefaultDS
While pooking around i found and : Uncommented body of deleteObject(pooledObject) - line 71 of org/jboss/resource/connectionmanager.ManagedConnectionPoolFactory.java (it seems this is called when the pool shrinks or is shut down. some test -is shrinking the pool to [0/0/10] and as a effect the next test using the DefaultDS do not have a connection ? ... it should probably create one before trying to create a table ? ...) *** Now when running run-testsuite I have 169 tests running and 1 error 99.41% Success rate - heh ... So the xa test is failing above - We knew that - and disabeling it should render a cool 100% of the 169 tests ! ... /peter_f on 1-11-26 22.54, David Maplesden at [EMAIL PROTECTED] wrote: I have been experiencing a NPE when calling createStatement on a connection obtained from DefaultDS. java.lang.NullPointerException at org.jboss.resource.adapter.jdbc.local.StatementInPool.init(StatementInPool .java:35) at org.jboss.resource.adapter.jdbc.local.ConnectionInPool.createStatement(Conne ctionInPool.java:606) This doesn't always occur and I have only noticed it in the last week or so, previously it worked fine. It occurs after a previous statement throws an SQLException. In other words if you are using the connections from DefaultDS everything is fine until one of your SQL queries causes an SQL exception. After this point you get a NPE every time you try to create another statement from a connection for DefaultDS. I think (though I don't know for sure) that it has been caused by a change to the Object pool code made last week sometime. I hope someone out there can help. Thanks David. --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.298 / Virus Database: 161 - Release Date: 11/13/2001 ___ 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] Installer / Deployer Problem
On 2001.11.27 17:23:32 -0500 Rickard Oberg wrote: marc fleury wrote: ok one of us doesn't get it, if you are open most of the time how do you release the lock in the filesystem for anyone to overwrite the file ? I could be missing it :) 1. URLCL wants to access custom://somejar.jar 2. It uses CustomURLHandler to get a connection to somejar.jar. This connection is put in cache and is never let go of. 3. The connection retrieved from CustomURLHandler is not a real connection, but merely a wrapper to a file connection. Similar to how a connection pool provides implementations of Connection that are only wrappers for real connections that can be managed by the pool. 4. Operations on the connection are passed on to the file connection. 5. When redeploy of a JAR is to be done, the wrapper is told to close its underlying connection 6. At this point there are no open connections to the JAR, so it can be replaced with a new file or removed. 7. At some point the connection wrapper is called, either by the old URLCL or a new one using the same connection. The file connection is then re-acquired, only now to the new file. See? So this requires an explicit undeploy of the old jar: it cannot work via an autodeployer watching for changed timestamps, because you have to undeploy the file first before you can change it. You sure this is better than copying? david jencks /Rickard -- Rickard Öberg ___ 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] Re: on the use of final
We use JTest from parasoft for static analysis. It usually flags up these
sort of errors. The reasoning behind their rules can be found at:
http://www.parasoft.com/products/jtest/manuals/v4_1/r_index.htm#1001102 -
Scan to correct section
John
-Original Message-
From: Jason Dillon [mailto:[EMAIL PROTECTED]]
Sent: 23 November 2001 20:32
To: marc fleury
Cc: Jboss-Development@Lists. Sourceforge. Net
Subject: [JBoss-dev] Re: on the use of final
My question though is is it worth it? what are the advantages of using
final as opposed to not using final and not worrying about the mutability
of
it?
speed gain?
Depends on where final is used. For final as a method attribute modifier
there is no speed increase, it is just an engineering tool to prevent the
value from being modified. It is common to use final for constructors. For
example:
class MyClass
{
int foo;
MyClass(int foo) {
foo = foo;
}
}
This is an error, but will compile and execute. To avoid this type of bug,
mark method attributes which should not change as final:
class MyClass
{
int foo;
MyClass(final int foo) {
foo = foo; // COMPILE ERROR
}
}
Final on a method, could cause a speed increase, allowing the compiler to
inline the method. From what I remember, the HotSpot VM folks at JavaOne
said that this will have little or no effect due to new compiler techniques.
* * *
Which usage of final are you refering too?
--jason
___
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] JMS issues re: stopservice, jndi names
Nevermind, problem fixed. I just changed how it finds the directories on restoreTransactions(), and made it ignore them in MessageLog.restore() I'll commit after some testing. -David On Tue, 27 Nov 2001, David Jencks wrote: On 2001.11.27 17:21:31 -0500 David Budworth wrote: So, why do we pre-restore the message queues? And not just restore them when a queue deploys? It seems to be a waste of memory to load an entire queue 'just in case' it gets deployed. Is there any reason why I couldn't just move the code from restoreTransactions() (which is called only by startService()) to restoreDestination() which currently seems to just take the messages out of the cache created by restoreTransactions(). Maybe you can make it work. I didn't see any way to, and I couldn't figure out any way to test it either. So I tried to change it as little as possible. You will definitely have to keep track of the recovered transaction info until all queues are restored: detecting this may me another trick. I thought it was way simpler to process it all at once when the pm started. Why is this causing you problems? I don't see the connection to the namespace issues. david jencks -david On Tue, 27 Nov 2001, David Jencks wrote: On 2001.11.27 15:55:06 -0500 David Budworth wrote: Does anyone know if it's actually legal for JMS topics/queues to have structure? I was making the change for binding subcontexts automatically (using org.jboss.naming.Util). And it deploys fine. But, if I kill jboss and restart it (without my sar that defines the queue in deploy), it throws exceptions because it finds a directory in the db/messaging/QUEUE.mycompany/myqueue The queue was mycompany/myqueue, which was created correctly as db/messaging/QUEUE.mycompany/myqueue/ I can only assume that the queue restoration only looks one level deep. And attempts to restore a queue (even though the queue is not in any DD anymore) I'm just trying to understand what all should be fixed. So, questions of the day are : 1) Can a queuename have depth? 2) Should all queues be restored at jboss startup regardless of if they are needed anymore? 2a) Or when the MBEAN descriptor is located? The startup is in 2 phases. When the pm is started, it pre-restores all the queues it can find, figures out which messages weren't committed (btw I'm not convinced it handles prepared but not committed properly), and makes lists of undelivered messages. Then when each queue starts, it registers with the pm and gets its list of messages. For topics, if I remember correctly, the queue representing the topic asks the StateManager for all the subscriber queues and restores each one individually. In regards to (2), there is no way to tell if a queue is needed anymore. The mbeans for the queues are not necessarily in the same file as the mbean for the pm, and could be deployed hours or days later. On the other hand, the cleanup of uncommitted messages should happen as soon as the pm is started, so you don't need to keep dead data around indefinitely. david jencks -David ___ 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] Installer / Deployer Problem
That is correct and my objection, however andreas pointed out that I was arguing an irrelevant point anyhow, I will forward his email marcf |-Original Message- |From: [EMAIL PROTECTED] |[mailto:[EMAIL PROTECTED]]On Behalf Of David |Jencks |Sent: Tuesday, November 27, 2001 6:44 PM |To: Rickard Oberg |Cc: marc fleury; Andreas Schaefer; |[EMAIL PROTECTED] |Subject: Re: [JBoss-dev] Installer / Deployer Problem | | |On 2001.11.27 17:23:32 -0500 Rickard Oberg wrote: | marc fleury wrote: | | ok one of us doesn't get it, if you are open most of the time how do | you | release the lock in the filesystem for anyone to overwrite the file ? | I | could be missing it :) | | | 1. URLCL wants to access custom://somejar.jar | 2. It uses CustomURLHandler to get a connection to somejar.jar. This | connection is put in cache and is never let go of. | 3. The connection retrieved from CustomURLHandler is not a real | connection, but merely a wrapper to a file connection. Similar to how a | connection pool provides implementations of Connection that are only | wrappers for real connections that can be managed by the pool. | 4. Operations on the connection are passed on to the file connection. | 5. When redeploy of a JAR is to be done, the wrapper is told to close | its underlying connection | 6. At this point there are no open connections to the JAR, so it can be | replaced with a new file or removed. | 7. At some point the connection wrapper is called, either by the old | URLCL or a new one using the same connection. The file connection is | then re-acquired, only now to the new file. | | See? | |So this requires an explicit undeploy of the old jar: it cannot work via an |autodeployer watching for changed timestamps, because you have to undeploy |the file first before you can change it. You sure this is better than |copying? | |david jencks | | /Rickard | | | -- | Rickard Öberg | | | | ___ | 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] Installer / Deployer Problem
|-Original Message- |From: Andreas Schaefer [mailto:[EMAIL PROTECTED]] |Sent: Tuesday, November 27, 2001 6:33 PM |To: marc fleury |Subject: Re: [JBoss-dev] Installer / Deployer Problem | | |Hi Geeks | |We are maybe still discussing the wrong issue. I had a |look at the ZipFile and JarFile classes and they don't |allow you to open an archive inside an archive. true, more of that packaging madness, THE STANDARD PACKAGING OF J2EE IS A BROWN SMELLY CYLINDER. Anyway we got to eat it... |Therefore for most of the files except the JAR file |(EAR, WAR, RAR and SAR) we have to inflate the |archive anyhow. |Now with the old trick of various directories or numbering |the files we can go around the lock. that is correct. |When Rickard can implement a lock-free URLCL then |we don't have to create subclasses and can reuse the |files (right now I can grow and grow until the server is |bounced) and that would be valueable. yes and the trick will also enable to not have to renumber the jar and wars so we can have a more fine grained deployment with the actual names and you get to keep (andreas) your JSR77 requirements of keeping track. good call andy, our bad marcf | |Andy | ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] (rh) Can we combine j2ee and jboss dds with xsl to get just one dd?
|-Original Message- |From: [EMAIL PROTECTED] |[mailto:[EMAIL PROTECTED]]On Behalf Of |Anatoly Akkerman |Sent: Tuesday, November 27, 2001 4:37 PM |To: David Jencks |Cc: [EMAIL PROTECTED] |Subject: Re: [JBoss-dev] (rh) Can we combine j2ee and jboss dds with xsl |to get just one dd? | | | | Can Castor merge nested attributes from all the files into one |object? For | instance, there are elements under ejb-jar/enterprise-beans/entity and | jboss-cmp/enterprise-beans/entity that should all end up in | result-dd/enterprise-beans/entity. | |Not that I know of. Doing XSLT, would, probably be the best way for such |processing. Castor can only instantiate a new object tree that represents |a given XML file. It cannot 'update' an existing tree from this |'incremental' unmarshalling. In general it is an impossible task. Think |about it. Castor (or any other software) would have to know which pieces |match where. Say, in the case of ejb descriptors, it would not be enough |to match and entity /entity from ejb-jar.xml with entity /entity |from jboss.xml. You would have to match _names_ and whatever else to make |sure you are updating descriptor object for the right entity bean. This |already is _semantic_ interpretation of what stands behind the data in the |XML file. You can only write a custom combiner that would take 3 object |trees (say, from ejb-jar.xml, jboss.xml and jaws.xml) and produce a |combined tree, matching appripriate descriptors by hand. david, you and I should take a page from anatoly's book this is what I call complex stuff explained in layman terms I almost understood it all at once :) you are going to write a great phd anatoly, you are going to be a real doctor one day, David, in my office, right this minute ;-) marcf | |Actually, I don't know if XSLT will to that for you, it also does not know |anything about the semantics of the XML files you are combining. It seems |to me, this must be a custom combining solution. | |Anatoly. | | | Just having copies of all 3 docs in the super-jboss is probably |easier with | including an xml entity;-) | | david jencks | | | | | |___ |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] javax.management.InstanceAlreadyExistsException...
Andy, I have just updated and built from clean. Upon running the WebIntegration testsuite, I immediately get : 23:48:58,218 INFO [Default] EjbModule.create(), server name: J2EEServer=Single 23:48:58,219 INFO [Default] File: file:/mnt/pteranodon/home/jules/cvs/JBoss/3.0/build/output/jboss-3.0.0alpha/deploy/Default/jbosstest-web.ear/ejb1005.jar, descriptor: META-INF/ejb-jar.xml 23:48:58,243 INFO [Default] J2EEManagedObject.getObjectName(), name: SingleJBoss:name=jbosstest-web.ear,J2EEServer=Single,J2EEApplication=jbosstest-web.ear,type=EJBModule,J2EEManagement=Manager 23:48:58,244 INFO [Default] J2EEManagedObject.postRegister(), parent: SingleJBoss:J2EEServer=Single,name=jbosstest-web.ear,type=J2EEApplication,J2EEManagement=Manager 23:48:58,261 ERROR [Default] javax.management.InstanceAlreadyExistsException: SingleJBoss:name=jbosstest-web.ear,J2EEServer=Single,J2EEApplication=jbosstest-web.ear,type=EJBModule,J2EEManagement=Manager 23:48:58,261 ERROR [Default] at com.sun.management.jmx.RepositorySupport.addMBean(RepositorySupport.java:134) 23:48:58,264 ERROR [Default] at com.sun.management.jmx.MBeanServerImpl.internal_addObject(MBeanServerImpl.java:2352) 23:48:58,264 ERROR [Default] at com.sun.management.jmx.MBeanServerImpl.createMBean(MBeanServerImpl.java:641) 23:48:58,264 ERROR [Default] at org.jboss.management.j2ee.EjbModule.create(EjbModule.java:78) 23:48:58,264 ERROR [Default] at org.jboss.ejb.ContainerFactory.deploy(ContainerFactory.java:394) 23:48:58,265 ERROR [Default] at org.jboss.ejb.ContainerFactory.deploy(ContainerFactory.java:368) 23:48:58,265 ERROR [Default] at org.jboss.ejb.ContainerFactory.deploy(ContainerFactory.java:299) 23:48:58,265 ERROR [Default] at java.lang.reflect.Method.invoke(Native Method) 23:48:58,265 ERROR [Default] at com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1628) 23:48:58,265 ERROR [Default] at com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1523) 23:48:58,265 ERROR [Default] at org.jboss.deployment.J2eeDeployer.startModules(J2eeDeployer.java:516) 23:48:58,266 ERROR [Default] at org.jboss.deployment.J2eeDeployer.startApplication(J2eeDeployer.java:490) 23:48:58,266 ERROR [Default] at org.jboss.deployment.J2eeDeployer.deploy(J2eeDeployer.java:222) 23:48:58,266 ERROR [Default] at java.lang.reflect.Method.invoke(Native Method) 23:48:58,266 ERROR [Default] at com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1628) 23:48:58,266 ERROR [Default] at com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1523) 23:48:58,266 ERROR [Default] at org.jboss.jmx.adaptor.rmi.RMIAdaptorImpl.invoke(RMIAdaptorImpl.java:283) 23:48:58,267 ERROR [Default] at java.lang.reflect.Method.invoke(Native Method) 23:48:58,267 ERROR [Default] at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:241) 23:48:58,267 ERROR [Default] at sun.rmi.transport.Transport$1.run(Transport.java:152) 23:48:58,267 ERROR [Default] at java.security.AccessController.doPrivileged(Native Method) 23:48:58,267 ERROR [Default] at sun.rmi.transport.Transport.serviceCall(Transport.java:148) 23:48:58,267 ERROR [Default] at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:465) 23:48:58,267 ERROR [Default] at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:706) 23:48:58,268 ERROR [Default] at java.lang.Thread.run(Thread.java:484) 23:48:58,285 ERROR [ContainerFactory] Could not deploy file:/mnt/pteranodon/home/jules/cvs/JBoss/3.0/build/output/jboss-3.0.0alpha/deploy/Default/jbosstest-web.ear Sorry ! Jules Andreas Schaefer wrote: Hi Yes, this is my mistake. I toke the wrong name, instead the name of the JAR file the name of the EAR application. Will fix it now. Andy - Original Message - From: Julian Gosnell [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, November 27, 2001 2:12 AM Subject: [JBoss-dev] javax.management.InstanceAlreadyExistsException... On running the WebIntegration test on a freshly built Server (cvs updated about 12 hours ago) I get a : javax.management.InstanceAlreadyExistsException: SingleJBoss:name=jbosstest-web.ear, J2EEServer=Single, J2EEApplication=jbosstest-web.ear, type=EJBModule, J2EEManagement=Manager, from JMX. The last JBoss stackframe was : org.jboss.management.j2ee.EJBModule.create() - EJBModule.java - line 78. I would send the whole stack - but I'm not on my development box, Apologies if this has already been sorted. Jules __ Do You Yahoo!? Everything you'll ever need on one web page from News and Sport to Email and Music Charts http://uk.my.yahoo.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development _ Do You Yahoo!? Get your
[JBoss-dev] CVS update: jboss/src/main/org/jboss/verifier/strategy AbstractVerifier.java
User: juhalindfors
Date: 01/11/27 16:27:14
Modified:src/main/org/jboss/verifier/strategy AbstractVerifier.java
Log:
Revision ChangesPath
1.24 +9 -4 jboss/src/main/org/jboss/verifier/strategy/AbstractVerifier.java
Index: AbstractVerifier.java
===
RCS file:
/cvsroot/jboss/jboss/src/main/org/jboss/verifier/strategy/AbstractVerifier.java,v
retrieving revision 1.23
retrieving revision 1.24
diff -u -r1.23 -r1.24
--- AbstractVerifier.java 2001/11/02 06:07:48 1.23
+++ AbstractVerifier.java 2001/11/28 00:27:14 1.24
@@ -19,7 +19,7 @@
* Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
*
* This package and its source code is available at www.jboss.org
- * $Id: AbstractVerifier.java,v 1.23 2001/11/02 06:07:48 schaefera Exp $
+ * $Id: AbstractVerifier.java,v 1.24 2001/11/28 00:27:14 juhalindfors Exp $
*/
// standard imports
@@ -70,7 +70,7 @@
* /ul
* /p
*
- * @version $Revision: 1.23 $
+ * @version $Revision: 1.24 $
* @sinceJDK 1.3
*/
public abstract class AbstractVerifier implements VerificationStrategy {
@@ -979,8 +979,13 @@
if (Error.class.isAssignableFrom(type))
return false;
-if (RuntimeException.class.isAssignableFrom(type))
-return false;
+// 28.3.4.4 (6) java.rmi.RemoteException and its subclasses, and unchecked
+// exception classes, are assumed to be mapped to the implicit
+// CORBA system exception, and are therefore not explicitly
+// declared in OMG IDL.
+//
+//if (RuntimeException.class.isAssignableFrom(type))
+//return false;
if (!isRMIIDLValueType(type))
return false;
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Re: on the use of final
There are like five hundred rules on that page. What is it specifically
flagging as a bad practice? I am actually interested.
-dain
-Original Message-
From: Weir, John [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, November 27, 2001 5:43 PM
To: Jboss-Development@Lists. Sourceforge. Net
Subject: RE: [JBoss-dev] Re: on the use of final
We use JTest from parasoft for static analysis. It usually
flags up these
sort of errors. The reasoning behind their rules can be found at:
http://www.parasoft.com/products/jtest/manuals/v4_1/r_index.ht
m#1001102 -
Scan to correct section
John
-Original Message-
From: Jason Dillon [mailto:[EMAIL PROTECTED]]
Sent: 23 November 2001 20:32
To: marc fleury
Cc: Jboss-Development@Lists. Sourceforge. Net
Subject: [JBoss-dev] Re: on the use of final
My question though is is it worth it? what are the
advantages of using
final as opposed to not using final and not worrying about
the mutability
of
it?
speed gain?
Depends on where final is used. For final as a method
attribute modifier
there is no speed increase, it is just an engineering tool to
prevent the
value from being modified. It is common to use final for
constructors. For
example:
class MyClass
{
int foo;
MyClass(int foo) {
foo = foo;
}
}
This is an error, but will compile and execute. To avoid
this type of bug,
mark method attributes which should not change as final:
class MyClass
{
int foo;
MyClass(final int foo) {
foo = foo; // COMPILE ERROR
}
}
Final on a method, could cause a speed increase, allowing the
compiler to
inline the method. From what I remember, the HotSpot VM
folks at JavaOne
said that this will have little or no effect due to new
compiler techniques.
* * *
Which usage of final are you refering too?
--jason
___
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-dev] CVS update: jboss/src/main/org/jboss/management/j2ee EJB.java EjbModule.java
User: schaefera
Date: 01/11/27 16:40:32
Modified:src/main/org/jboss/management/j2ee EJB.java EjbModule.java
Log:
Fix for a problem with a NPE.
Revision ChangesPath
1.2 +3 -3 jboss/src/main/org/jboss/management/j2ee/EJB.java
Index: EJB.java
===
RCS file: /cvsroot/jboss/jboss/src/main/org/jboss/management/j2ee/EJB.java,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- EJB.java 2001/11/27 06:15:26 1.1
+++ EJB.java 2001/11/28 00:40:32 1.2
@@ -18,7 +18,7 @@
* {@link javax.management.j2ee.EJB EJB}.
*
* @author a href=mailto:[EMAIL PROTECTED];Andreas Schaefer/a.
- * @version $Revision: 1.1 $
+ * @version $Revision: 1.2 $
*
* pbRevisions:/b
*
@@ -65,7 +65,7 @@
).getObjectName();
}
catch( Exception e ) {
- e.printStackTrace();
+// e.printStackTrace();
return null;
}
}
@@ -76,7 +76,7 @@
pServer.unregisterMBean( new ObjectName( pEJBName ) );
}
catch( Exception e ) {
- e.printStackTrace();
+// e.printStackTrace();
}
}
1.5 +5 -1 jboss/src/main/org/jboss/management/j2ee/EjbModule.java
Index: EjbModule.java
===
RCS file: /cvsroot/jboss/jboss/src/main/org/jboss/management/j2ee/EjbModule.java,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -r1.4 -r1.5
--- EjbModule.java2001/11/27 06:15:26 1.4
+++ EjbModule.java2001/11/28 00:40:32 1.5
@@ -27,7 +27,7 @@
* {@link javax.management.j2ee.EjbModule EjbModule}.
*
* @author a href=mailto:[EMAIL PROTECTED];Andreas Schaefer/a.
- * @version $Revision: 1.4 $
+ * @version $Revision: 1.5 $
*
* pbRevisions:/b
*
@@ -75,6 +75,10 @@
}
try {
// Now create the J2EEApplication
+ System.out.println( Create EJB-Module, name: + pName +
+, application: + lApplication +
+, dd: + lDD
+ );
return pServer.createMBean(
org.jboss.management.j2ee.EjbModule,
null,
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jboss/src/main/org/jboss/ejb ContainerFactory.java
User: schaefera
Date: 01/11/27 16:40:31
Modified:src/main/org/jboss/ejb ContainerFactory.java
Log:
Fix for a problem with a NPE.
Revision ChangesPath
1.101 +15 -6 jboss/src/main/org/jboss/ejb/ContainerFactory.java
Index: ContainerFactory.java
===
RCS file: /cvsroot/jboss/jboss/src/main/org/jboss/ejb/ContainerFactory.java,v
retrieving revision 1.100
retrieving revision 1.101
diff -u -r1.100 -r1.101
--- ContainerFactory.java 2001/11/27 06:15:26 1.100
+++ ContainerFactory.java 2001/11/28 00:40:31 1.101
@@ -70,7 +70,7 @@
* @author a href=mailto:[EMAIL PROTECTED];Peter Antman/a.
* @author a href=mailto:[EMAIL PROTECTED];Scott Stark/a
* @author a href=mailto:[EMAIL PROTECTED];Sacha Labourey/a
-* @version $Revision: 1.100 $
+* @version $Revision: 1.101 $
*/
public class ContainerFactory
extends ServiceMBeanSupport
@@ -391,13 +391,20 @@
throws NamingException, Exception
{
// Create JSR-77 EJB-Module
- String lModule = EjbModule.create(
+ int i = app.getName().lastIndexOf( / );
+ String lName = app.getName().substring(
+ i = 0 ? i + 1 : 0
+ );
+ ObjectName lModule = EjbModule.create(
getServer(),
pParentId,
- pAppId,
+ lName,
+// pAppId,
url
- ).toString();
- app.setModuleName( lModule );
+ );
+ if( lModule != null ) {
+ app.setModuleName( lModule.toString() );
+ }
// Create a file loader with which to load the files
XmlFileLoader efm = new XmlFileLoader(validateDTDs);
@@ -495,7 +502,9 @@
// Remove deployment
deployments.remove( url );
// Remove JSR-77 Module
- EjbModule.destroy( getServer(), app.getModuleName() );
+ if( app.getModuleName() != null ) {
+EjbModule.destroy( getServer(), app.getModuleName() );
+ }
// Done
log.info( Undeployed application: + app.getName() );
}
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jboss/src/main/org/jboss/ejb ContainerFactory.java
User: schaefera
Date: 01/11/27 17:15:08
Modified:src/main/org/jboss/ejb ContainerFactory.java
Log:
Remove some System.out.println() and print stack traces and replaced
by logging.
Revision ChangesPath
1.102 +1 -2 jboss/src/main/org/jboss/ejb/ContainerFactory.java
Index: ContainerFactory.java
===
RCS file: /cvsroot/jboss/jboss/src/main/org/jboss/ejb/ContainerFactory.java,v
retrieving revision 1.101
retrieving revision 1.102
diff -u -r1.101 -r1.102
--- ContainerFactory.java 2001/11/28 00:40:31 1.101
+++ ContainerFactory.java 2001/11/28 01:15:08 1.102
@@ -70,7 +70,7 @@
* @author a href=mailto:[EMAIL PROTECTED];Peter Antman/a.
* @author a href=mailto:[EMAIL PROTECTED];Scott Stark/a
* @author a href=mailto:[EMAIL PROTECTED];Sacha Labourey/a
-* @version $Revision: 1.101 $
+* @version $Revision: 1.102 $
*/
public class ContainerFactory
extends ServiceMBeanSupport
@@ -399,7 +399,6 @@
getServer(),
pParentId,
lName,
-// pAppId,
url
);
if( lModule != null ) {
___
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 EJB.java EjbModule.java J2EEApplication.java
User: schaefera
Date: 01/11/27 17:15:08
Modified:src/main/org/jboss/management/j2ee EJB.java EjbModule.java
J2EEApplication.java
Log:
Remove some System.out.println() and print stack traces and replaced
by logging.
Revision ChangesPath
1.3 +6 -3 jboss/src/main/org/jboss/management/j2ee/EJB.java
Index: EJB.java
===
RCS file: /cvsroot/jboss/jboss/src/main/org/jboss/management/j2ee/EJB.java,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- EJB.java 2001/11/28 00:40:32 1.2
+++ EJB.java 2001/11/28 01:15:08 1.3
@@ -10,6 +10,7 @@
import javax.management.MBeanServer;
import javax.management.ObjectName;
+import org.jboss.logging.Logger;
import org.jboss.metadata.BeanMetaData;
import org.jboss.metadata.SessionMetaData;
@@ -18,7 +19,7 @@
* {@link javax.management.j2ee.EJB EJB}.
*
* @author a href=mailto:[EMAIL PROTECTED];Andreas Schaefer/a.
- * @version $Revision: 1.2 $
+ * @version $Revision: 1.3 $
*
* pbRevisions:/b
*
@@ -45,6 +46,7 @@
};
public static ObjectName create( MBeanServer pServer, String pEjbModule,
BeanMetaData pBeanMeta ) {
+ Logger lLog = Logger.getLogger( EJB.class );
try {
int lType =
pBeanMeta.isSession() ?
@@ -65,18 +67,19 @@
).getObjectName();
}
catch( Exception e ) {
-// e.printStackTrace();
+ lLog.error( Could not create JSR-77 EJB: + pBeanMeta.getJndiName(), e );
return null;
}
}
public static void destroy( MBeanServer pServer, String pEJBName ) {
+ Logger lLog = Logger.getLogger( EJB.class );
try {
// Now remove the EJB
pServer.unregisterMBean( new ObjectName( pEJBName ) );
}
catch( Exception e ) {
-// e.printStackTrace();
+ lLog.error( Could not destory JSR-77 EJB: + pEJBName, e );
}
}
1.6 +12 -16jboss/src/main/org/jboss/management/j2ee/EjbModule.java
Index: EjbModule.java
===
RCS file: /cvsroot/jboss/jboss/src/main/org/jboss/management/j2ee/EjbModule.java,v
retrieving revision 1.5
retrieving revision 1.6
diff -u -r1.5 -r1.6
--- EjbModule.java2001/11/28 00:40:32 1.5
+++ EjbModule.java2001/11/28 01:15:08 1.6
@@ -22,12 +22,14 @@
import java.security.InvalidParameterException;
+import org.jboss.logging.Logger;
+
/**
* Root class of the JBoss JSR-77 implementation of
* {@link javax.management.j2ee.EjbModule EjbModule}.
*
* @author a href=mailto:[EMAIL PROTECTED];Andreas Schaefer/a.
- * @version $Revision: 1.5 $
+ * @version $Revision: 1.6 $
*
* pbRevisions:/b
*
@@ -51,6 +53,7 @@
// Static
public static ObjectName create( MBeanServer pServer, String pApplicationName,
String pName, URL pURL ) {
+ Logger lLog = Logger.getLogger( EjbModule.class );
String lDD = null;
ObjectName lApplication = null;
try {
@@ -60,7 +63,7 @@
).iterator().next();
String lServerName = lServer.getKeyPropertyList().get( type ) + = +
lServer.getKeyPropertyList().get( name );
- System.out.println( EjbModule.create(), server name: + lServerName );
+ lLog.debug( EjbModule.create(), server name: + lServerName );
lApplication = (ObjectName) pServer.queryNames(
new ObjectName( J2EEManagedObject.getDomainName() +
:type=J2EEApplication +
,name= + pApplicationName + , + lServerName + ,*
@@ -71,11 +74,13 @@
lDD = J2EEDeployedObject.getDeploymentDescriptor( pURL,
J2EEDeployedObject.EJB );
}
catch( Exception e ) {
- e.printStackTrace();
+ lLog.error( Could not create JSR-77 EjbModule: + pApplicationName, e );
+ return null;
}
try {
// Now create the J2EEApplication
- System.out.println( Create EJB-Module, name: + pName +
+ lLog.debug(
+Create EJB-Module, name: + pName +
, application: + lApplication +
, dd: + lDD
);
@@ -95,28 +100,19 @@
).getObjectName();
}
catch( Exception e ) {
- e.printStackTrace();
+ lLog.error( Could not create JSR-77 EjbModule: + pApplicationName, e );
return null;
}
}
public static void destroy( MBeanServer pServer, String pModuleName ) {
+ Logger lLog = Logger.getLogger( EjbModule.class );
try {
[JBoss-dev] CVS update: contrib/jetty/src/resources/jetty-plugin/META-INF jboss-service.xml
User: jules_gosnell Date: 01/11/27 17:22:25 Modified:jetty/src/resources/jetty-plugin/META-INF jboss-service.xml Log: messing around with DebugMBean stuff trying to get jetty.xml read out of jetty-plugin.sar ... Revision ChangesPath 1.5 +6 -1 contrib/jetty/src/resources/jetty-plugin/META-INF/jboss-service.xml Index: jboss-service.xml === RCS file: /cvsroot/jboss/contrib/jetty/src/resources/jetty-plugin/META-INF/jboss-service.xml,v retrieving revision 1.4 retrieving revision 1.5 diff -u -r1.4 -r1.5 --- jboss-service.xml 2001/11/26 23:39:22 1.4 +++ jboss-service.xml 2001/11/28 01:22:25 1.5 @@ -22,14 +22,19 @@ mbean code=org.jboss.jetty.JettyService name=JBOSS-SYSTEM:service=Jetty attribute name=JettyHomedummy/attribute +!-- +attribute name=Configurationjetty.xml/attribute + -- attribute name=Configuration../conf/default/jetty.xml/attribute attribute name=WebDefault../conf/default/webdefault.xml/attribute attribute name=UnpackWarstrue/attribute attribute name=PublishMBeanstrue/attribute /mbean +!-- + -- mbean code=org.mortbay.jetty.jmx.DebugMBean - name=Jetty:Jetty=Debug + name=Jetty:Jetty=Debug2 /mbean /server ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: contrib/jetty TODO build.xml
User: jules_gosnell
Date: 01/11/27 17:22:24
Modified:jettyTODO build.xml
Log:
messing around with DebugMBean stuff
trying to get jetty.xml read out of jetty-plugin.sar
...
Revision ChangesPath
1.6 +3 -1 contrib/jetty/TODO
Index: TODO
===
RCS file: /cvsroot/jboss/contrib/jetty/TODO,v
retrieving revision 1.5
retrieving revision 1.6
diff -u -r1.5 -r1.6
--- TODO 2001/11/25 15:09:44 1.5
+++ TODO 2001/11/28 01:22:24 1.6
@@ -1,7 +1,9 @@
-
+Get Jetty to load config from SAR
+properly MBeanify
Get Jetty Debug MBean running
connect EAR CLASSPATH up to Jasper
Do we have a problem with JNDI bindings not working ?
Get testsuite working/integrate with scoped classloaders.
Persistant/Distributed Sessions
+
1.12 +6 -1 contrib/jetty/build.xml
Index: build.xml
===
RCS file: /cvsroot/jboss/contrib/jetty/build.xml,v
retrieving revision 1.11
retrieving revision 1.12
diff -u -r1.11 -r1.12
--- build.xml 2001/11/21 23:13:00 1.11
+++ build.xml 2001/11/28 01:22:24 1.12
@@ -374,6 +374,9 @@
jar jarfile=${build.lib}/${module.name}.sar
!-- Jetty plugin classes --
+ fileset dir=${build.etc}
+include name=jetty.xml/
+ /fileset
fileset dir=${build.classes}
include name=**/
/fileset
@@ -413,15 +416,17 @@
/
sleep seconds=5/
+!--
exec dir=../../testsuite/
executable=/bin/sh
arg value=./build.sh/
arg value=-emacs/
arg value=-Djavac.debug=true/
- arg value=-Dtest=WebIntegrationUnitTestCase/
+ arg value=-Dtest=org.jboss.test.web.test.WebIntegrationUnitTestCase/
arg value=one-test/
/exec
+ --
/target
___
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 Jetty.java JettyService.java
User: jules_gosnell
Date: 01/11/27 17:22:25
Modified:jetty/src/main/org/jboss/jetty
JBossWebApplicationContext.java Jetty.java
JettyService.java
Log:
messing around with DebugMBean stuff
trying to get jetty.xml read out of jetty-plugin.sar
...
Revision ChangesPath
1.4 +17 -18
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.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- JBossWebApplicationContext.java 2001/11/25 14:52:48 1.3
+++ JBossWebApplicationContext.java 2001/11/28 01:22:25 1.4
@@ -5,7 +5,7 @@
* See terms of license at gnu.org.
*/
-// $Id: JBossWebApplicationContext.java,v 1.3 2001/11/25 14:52:48 jules_gosnell Exp
$
+// $Id: JBossWebApplicationContext.java,v 1.4 2001/11/28 01:22:25 jules_gosnell Exp
$
// A Jetty HttpServer with the interface expected by JBoss'
// J2EEDeployer...
@@ -135,7 +135,6 @@
}
}
-
/**
* return the first JBossSXSecurityHandler, inserting one at the
* beginning of the list, if no other can be found.
@@ -173,31 +172,31 @@
super.initWebXmlElement(element, node);
}
-// 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);
-// }
+ // 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.
- protected void initClassLoader()
- throws java.net.MalformedURLException, java.io.IOException
- {
- super.initClassLoader();
+ protected void initClassLoader()
+throws java.net.MalformedURLException, java.io.IOException
+{
+ super.initClassLoader();
- ClassLoader _loader=getClassLoader();
- if (_loader instanceof org.mortbay.http.ContextLoader)
+ ClassLoader _loader=getClassLoader();
+ if (_loader instanceof org.mortbay.http.ContextLoader)
((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...
+ // copy our superclass' version of this, but ensure that servlet
+ // api and jasper jars are appended to it...
public String getFileClassPath()
throws IllegalStateException
1.22 +5 -1 contrib/jetty/src/main/org/jboss/jetty/Jetty.java
Index: Jetty.java
===
RCS file: /cvsroot/jboss/contrib/jetty/src/main/org/jboss/jetty/Jetty.java,v
retrieving revision 1.21
retrieving revision 1.22
diff -u -r1.21 -r1.22
--- Jetty.java2001/11/26 03:24:53 1.21
+++ Jetty.java2001/11/28 01:22:25 1.22
@@ -5,7 +5,7 @@
* See terms of license at gnu.org.
*/
-// $Id: Jetty.java,v 1.21 2001/11/26 03:24:53 starksm Exp $
+// $Id: Jetty.java,v 1.22 2001/11/28 01:22:25 jules_gosnell Exp $
// A Jetty HttpServer with the interface expected by JBoss'
// J2EEDeployer...
@@ -119,9 +119,13 @@
if (configUrl==null)
return;
+_log.info(CONFIG IS: +configUrl);
+_log.info(CONFIG IS: +findResourceInJar(configUrl));
+
try
{
_log.info(loading config: +configUrl);
+ // configure(findResourceInJar(configUrl).toString());
configure(configUrl);
_log.info(loaded config: +configUrl);
_configuration=configUrl;
1.32 +18 -3 contrib/jetty/src/main/org/jboss/jetty/JettyService.java
Index: JettyService.java
===
RCS file: /cvsroot/jboss/contrib/jetty/src/main/org/jboss/jetty/JettyService.java,v
retrieving revision 1.31
retrieving revision 1.32
diff -u -r1.31 -r1.32
--- JettyService.java 2001/11/26 23:39:22 1.31
+++ JettyService.java 2001/11/28 01:22:25 1.32
@@ -5,7 +5,7 @@
* See terms of license
[JBoss-dev] CVS update: jbosscx/src/main/org/jboss/resource ConnectionFactoryLoader.java
User: d_jencks
Date: 01/11/27 17:36:08
Modified:src/main/org/jboss/resource ConnectionFactoryLoader.java
Log:
Made jndi binding work on nested subcontexts
Revision ChangesPath
1.16 +5 -21 jbosscx/src/main/org/jboss/resource/ConnectionFactoryLoader.java
Index: ConnectionFactoryLoader.java
===
RCS file:
/cvsroot/jboss/jbosscx/src/main/org/jboss/resource/ConnectionFactoryLoader.java,v
retrieving revision 1.15
retrieving revision 1.16
diff -u -r1.15 -r1.16
--- ConnectionFactoryLoader.java 2001/11/26 06:35:12 1.15
+++ ConnectionFactoryLoader.java 2001/11/28 01:36:08 1.16
@@ -45,6 +45,7 @@
import org.jboss.logging.Logger;
import org.jboss.logging.log4j.CategoryWriter;
+import org.jboss.naming.Util;
import org.jboss.resource.security.PrincipalMapping;
import org.jboss.system.ServiceMBeanSupport;
@@ -61,7 +62,7 @@
* @author a href=[EMAIL PROTECTED]Toby Allsopp/a
* @author a href=mailto:[EMAIL PROTECTED];David Jencks/a
* @seeRARDeployer
- * @version$Revision: 1.15 $ p
+ * @version$Revision: 1.16 $ p
*
* bRevisions:/b p
*
@@ -443,12 +444,8 @@
// Private ---
/**
-* Does the actual work of configuring a connection factory. Because this is
-* invoked from a notification handler, it makes no sense to propagate
-* exceptions, so we handle all checked exceptions in the body of this
-* method.
-*
-* @param metaData Description of Parameter
+* Does the actual work of configuring a connection factory.
+* This could now throw exceptions since it is no longer called from a
notification.
*/
private void loadConnectionFactory()
{
@@ -515,8 +512,6 @@
try
{
parseProperties(mcfProps, mcfProperties);
- //mcfProps.load(
- //new ByteArrayInputStream(mcfProperties.getBytes(ISO-8859-1)));
}
catch (IOException ioe)
{
@@ -651,17 +646,6 @@
// Find the connection manager factory
ConnectionManagerFactory cmf;
- /*try
- {
- cmf = (ConnectionManagerFactory)ctx.lookup(java:/ + cmfName);
- }
- catch (Exception e)
- {
- log.error(Unable to find connection manager factory at 'java:/ +
- cmfName + ', e);
- return;
- }
- */
try
{
cmf = (ConnectionManagerFactory)server.getAttribute(cmfLoaderName,
ConnectionManagerFactory);
@@ -735,7 +719,7 @@
null));
try
{
- ctx.bind(bindName, cf);
+ Util.bind(ctx, bindName, cf);
log.info(Bound connection factory for resource adapter ' +
resourceAdapterName + ' to JNDI name ' + bindName + ');
}
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jbossmq/src/main/org/jboss/mq/server QueueManager.java TopicManager.java
User: dbudworth
Date: 01/11/27 16:55:29
Modified:src/main/org/jboss/mq/server QueueManager.java
TopicManager.java
Log:
Added support for deep topic and queue names
Passes run-basic-testsuite, so if something is broken the test needs updating.
TopicManager/QueueManager, uses org.jboss.naming.Util to auto-create subcontexts
PersistenceManager/MessageLog updated to support deep subdirectories in
db/jbossmq/file
Revision ChangesPath
1.6 +4 -2 jbossmq/src/main/org/jboss/mq/server/QueueManager.java
Index: QueueManager.java
===
RCS file: /cvsroot/jboss/jbossmq/src/main/org/jboss/mq/server/QueueManager.java,v
retrieving revision 1.5
retrieving revision 1.6
diff -u -r1.5 -r1.6
--- QueueManager.java 2001/11/10 21:38:05 1.5
+++ QueueManager.java 2001/11/28 00:55:29 1.6
@@ -21,13 +21,15 @@
import org.jboss.mq.*;
import org.jboss.system.ServiceMBeanSupport;
+import org.jboss.naming.Util;
+
/**
* This class is a message queue which is stored (hashed by Destination) on the
* JMS provider
*
* @author Norbert Lataille ([EMAIL PROTECTED])
* @author a href=[EMAIL PROTECTED]Hiram Chirino/a
- * @version$Revision: 1.5 $
+ * @version$Revision: 1.6 $
*/
public class QueueManager extends ServiceMBeanSupport implements QueueManagerMBean
{
@@ -120,7 +122,7 @@
{
subctx = ctx.createSubcontext(queue);
}
- subctx.rebind(queueName, queue);
+ Util.rebind(subctx,queueName,queue);
}
1.6 +3 -3 jbossmq/src/main/org/jboss/mq/server/TopicManager.java
Index: TopicManager.java
===
RCS file: /cvsroot/jboss/jbossmq/src/main/org/jboss/mq/server/TopicManager.java,v
retrieving revision 1.5
retrieving revision 1.6
diff -u -r1.5 -r1.6
--- TopicManager.java 2001/11/10 21:38:05 1.5
+++ TopicManager.java 2001/11/28 00:55:29 1.6
@@ -22,6 +22,7 @@
import org.jboss.mq.*;
import org.jboss.system.ServiceMBeanSupport;
import org.jboss.mq.DurableSubcriptionID;//Typo!!!
+import org.jboss.naming.Util;
/**
* This class is a message queue which is stored (hashed by Destination) on the
@@ -29,7 +30,7 @@
*
* @author Norbert Lataille ([EMAIL PROTECTED])
* @author a href=[EMAIL PROTECTED]Hiram Chirino/a
- * @version$Revision: 1.5 $
+ * @version$Revision: 1.6 $
*/
public class TopicManager
extends ServiceMBeanSupport
@@ -124,8 +125,7 @@
{
subctx = ctx.createSubcontext(topic);
}
- subctx.rebind(topicName, topic);
-
+ Util.rebind(subctx,topicName,topic);
}
protected void stopService()
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: thirdparty/mortbay LICENSE.html
User: jules_gosnell Date: 01/11/27 17:23:00 Added: mortbay LICENSE.html Log: Jetty's license Revision ChangesPath 1.1 thirdparty/mortbay/LICENSE.html Index: LICENSE.html === HTML HEAD TITLEJetty License/TITLE /HEAD BODY BGCOLOR=#FF FONT FACE=ARIAL,HELVETICA CENTERFONT SIZE=+3BJetty License/B/FONT/CENTER CENTERFONT SIZE=-1B$Revision: 1.1 $/B/FONT/CENTER BPreamble:/Bp The intent of this document is to state the conditions under which the Jetty Package may be copied, such that the Copyright Holder maintains some semblance of control over the development of the package, while giving the users of the package the right to use, distribute and make reasonable modifications to the Package in accordance with the goals and ideals of the Open Source concept as described at A HREF=http://www.opensource.org;http://www.opensource.org/A. P It is the intent of this license to allow commercial usage of the Jetty package, so long as the source code is distributed or suitable visible credit given or other arrangements made with the copyright holders. PBDefinitions:/BP UL LI Jetty refers to the collection of Java classes that are distributed as a HTTP server with servlet capabilities and associated utilities.p LIPackage refers to the collection of files distributed by the Copyright Holder, and derivatives of that collection of files created through textual modification.P LIStandard Version refers to such a Package if it has not been modified, or has been modified in accordance with the wishes of the Copyright Holder.P LICopyright Holder is whoever is named in the copyright or copyrights for the package. BR Mort Bay Consulting Pty. Ltd. (Australia) is the Copyright Holder for the Jetty package.P LIYou is you, if you're thinking about copying or distributing this Package.P LIReasonable copying fee is whatever you can justify on the basis of media cost, duplication charges, time of people involved, and so on. (You will not be required to justify it to the Copyright Holder, but only to the computing community at large as a market that must bear the fee.)P LIFreely Available means that no fee is charged for the item itself, though there may be fees involved in handling the item. It also means that recipients of the item may redistribute it under the same conditions they received it.P /UL 0. The Jetty Package is Copyright (c) 1998 Mort Bay Consulting Pty. Ltd. (Australia) and others. Individual files in this package may contain additional copyright notices. The javax.servlet packages are copyright Sun Microsystems Inc. P 1. The Standard Version of the Jetty package is available from A HREF=http://www.mortbay.comhttp://www.mortbay.com/A.P 2. You may make and distribute verbatim copies of the source form of the Standard Version of this Package without restriction, provided that you include this license and all of the original copyright notices and associated disclaimers.P 3. You may make and distribute verbatim copies of the compiled form of the Standard Version of this Package without restriction, provided that you include this license.P 4. You may apply bug fixes, portability fixes and other modifications derived from the Public Domain or from the Copyright Holder. A Package modified in such a way shall still be considered the Standard Version.P 5. You may otherwise modify your copy of this Package in any way, provided that you insert a prominent notice in each changed file stating how and when you changed that file, and provided that you do at least ONE of the following:P BLOCKQUOTE a) Place your modifications in the Public Domain or otherwise make them Freely Available, such as by posting said modifications to Usenet or an equivalent medium, or placing the modifications on a major archive site such as ftp.uu.net, or by allowing the Copyright Holder to include your modifications in the Standard Version of the Package.P b) Use the modified Package only within your corporation or organization.P c) Rename any non-standard classes so the names do not conflict with standard classes, which must also be provided, and provide a separate manual page for each non-standard class that clearly documents how it differs from the Standard Version.P d) Make other arrangements with the Copyright Holder.P /BLOCKQUOTE 6. You may distribute modifications or subsets of this Package in source code or compiled form, provided that you do at least ONE of the following:P BLOCKQUOTE a)
Re: [JBoss-dev] Build Broken?
I should have been more specific. I only get the error when I set it ! Jules --- Hunter Hillegas [EMAIL PROTECTED] wrote: Yup, JBOSS_HOME was set properly. I'll do a refresh and test it again this afternoon to see if it persists... From: Julian Gosnell [EMAIL PROTECTED] Date: Tue, 27 Nov 2001 11:56:22 + (GMT) To: Hunter Hillegas [EMAIL PROTECTED], JBoss Dev [EMAIL PROTECTED] Subject: Re: [JBoss-dev] Build Broken? Have you got JBOSS_HOME set ? This one has bittent me before Jules --- Hunter Hillegas [EMAIL PROTECTED] wrote: Just grabbed the latest CVS and I get this on startup: 20:09:54,995 WARN [ServiceDeployer] SaxException getting document: java.io.FileNotFoundException: /usr/java/jboss/co6/jboss-all/server/src/resources/org/jboss/metadata/jboss- service.dtd (No such file or directory) at org.apache.crimson.parser.Parser2.fatal(Parser2.java:3108) At this point the server shuts down... ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development __ Do You Yahoo!? Everything you'll ever need on one web page from News and Sport to Email and Music Charts http://uk.my.yahoo.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development __ Do You Yahoo!? Everything you'll ever need on one web page from News and Sport to Email and Music Charts http://uk.my.yahoo.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Build Broken?
what IS this JBOSS_HOME thing? it keeps pooping up and we keep banging it on the head, SETTING VARIABLES IS DUMB... who needs jboss-home set? marcf |-Original Message- |From: [EMAIL PROTECTED] |[mailto:[EMAIL PROTECTED]]On Behalf Of |Julian Gosnell |Sent: Tuesday, November 27, 2001 6:56 AM |To: Hunter Hillegas; JBoss Dev |Subject: Re: [JBoss-dev] Build Broken? | | |Have you got JBOSS_HOME set ? | |This one has bittent me before | | |Jules | | --- Hunter Hillegas [EMAIL PROTECTED] wrote: | Just grabbed the latest CVS and I get this on | startup: | | 20:09:54,995 WARN [ServiceDeployer] SaxException | getting document: | java.io.FileNotFoundException: | |/usr/java/jboss/co6/jboss-all/server/src/resources/org/jboss/metada |ta/jboss- | service.dtd (No such file or directory) | at | |org.apache.crimson.parser.Parser2.fatal(Parser2.java:3108) | | | At this point the server shuts down... | | | ___ | Jboss-development mailing list | [EMAIL PROTECTED] | |https://lists.sourceforge.net/lists/listinfo/jboss-development | |__ |Do You Yahoo!? |Everything you'll ever need on one web page from News and Sport to |Email and Music Charts |http://uk.my.yahoo.com | |___ |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] CVS update: contrib/tomcat/src/etc/conf/tomcat server.xml.patch
User: starksm Date: 01/11/27 19:53:39 Modified:tomcat/src/etc/conf/tomcat Tag: Branch_2_4 server.xml.patch Log: Update for tomcat-3.2.4 Revision ChangesPath No revision No revision 1.4.2.1 +27 -31contrib/tomcat/src/etc/conf/tomcat/server.xml.patch Index: server.xml.patch === RCS file: /cvsroot/jboss/contrib/tomcat/src/etc/conf/tomcat/server.xml.patch,v retrieving revision 1.4 retrieving revision 1.4.2.1 diff -u -r1.4 -r1.4.2.1 --- server.xml.patch 2001/06/22 05:49:08 1.4 +++ server.xml.patch 2001/11/28 03:53:39 1.4.2.1 @@ -1,47 +1,43 @@ -*** server.xml Tue Dec 12 13:36:20 2000 server.jboss.xml Thu May 24 09:52:03 2001 +*** server.xml Tue Nov 27 19:52:39 2001 +--- server.jboss.xml Tue Nov 27 19:56:41 2001 *** *** 120,135 + ContextInterceptor className=org.apache.tomcat.context.LoaderInterceptor / ContextInterceptor className=org.apache.tomcat.context.DefaultCMSetter / ContextInterceptor className=org.apache.tomcat.context.WorkDirInterceptor / + +!!-- Uncomment if you are using JDK1.2 or higher. +Insures proper thread context class loader is in effect for servlet execution + ContextInterceptor + className=org.apache.tomcat.request.Jdk12Interceptor / +--- -! !-- Request processing -- + !-- Request processing -- !-- Session interceptor will extract the session id from cookies and - deal with URL rewriting ( by fixing the URL ). If you wish to - suppress the use of cookies for session identifiers, change the - noCookies attribute to true --- - RequestInterceptor - className=org.apache.tomcat.request.SessionInterceptor - noCookies=false / 120,140 +--- 120,136 + ContextInterceptor className=org.apache.tomcat.context.LoaderInterceptor / - ContextInterceptor ++ ContextInterceptor + className=org.jboss.tomcat.naming.JbossWebXmlReader / -+ ContextInterceptor + ContextInterceptor className=org.apache.tomcat.context.DefaultCMSetter / ContextInterceptor className=org.apache.tomcat.context.WorkDirInterceptor / -! !-- JBoss, Set the request thread classloader to the thread context classloader -- -! RequestInterceptor className=org.apache.tomcat.request.Jdk12Interceptor / -! +!!-- Uncomment if you are using JDK1.2 or higher. -- +Insures proper thread context class loader is in effect for servlet execution + ContextInterceptor + className=org.apache.tomcat.request.Jdk12Interceptor / + + !-- Request processing -- !-- Session interceptor will extract the session id from cookies and - deal with URL rewriting ( by fixing the URL ). If you wish to - suppress the use of cookies for session identifiers, change the - noCookies attribute to true --- -+ - RequestInterceptor - className=org.apache.tomcat.request.SessionInterceptor - noCookies=false / *** -*** 176,215 +*** 183,222 className=org.apache.tomcat.request.AccessInterceptor debug=0 / @@ -78,18 +74,18 @@ ! userCredCol=user_pass !userRoleTable=user_roles ! roleNameCol=role_name / -! -- + -- !-- Loaded last since JSP's that load-on-startup use request handling -- ContextInterceptor 181,190 +--- 184,193 className=org.apache.tomcat.request.AccessInterceptor debug=0 / -!!-- JBoss, Perform authentication and authorization using the security-domain -!security manager. -!-- -!RequestInterceptor className=org.jboss.tomcat.security.JBossSecurityMgrRealm / +! !-- JBoss, Perform authentication and authorization using the security-domain +! security manager. + -- ++ RequestInterceptor className=org.jboss.tomcat.security.JBossSecurityMgrRealm / !-- Loaded last since JSP's that load-on-startup use request handling -- ContextInterceptor ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jbossmq/src/main/org/jboss/mq/pm/file MessageLog.java PersistenceManager.java
User: dbudworth
Date: 01/11/27 16:55:29
Modified:src/main/org/jboss/mq/pm/file MessageLog.java
PersistenceManager.java
Log:
Added support for deep topic and queue names
Passes run-basic-testsuite, so if something is broken the test needs updating.
TopicManager/QueueManager, uses org.jboss.naming.Util to auto-create subcontexts
PersistenceManager/MessageLog updated to support deep subdirectories in
db/jbossmq/file
Revision ChangesPath
1.8 +4 -1 jbossmq/src/main/org/jboss/mq/pm/file/MessageLog.java
Index: MessageLog.java
===
RCS file: /cvsroot/jboss/jbossmq/src/main/org/jboss/mq/pm/file/MessageLog.java,v
retrieving revision 1.7
retrieving revision 1.8
diff -u -r1.7 -r1.8
--- MessageLog.java 2001/11/14 01:53:40 1.7
+++ MessageLog.java 2001/11/28 00:55:29 1.8
@@ -29,7 +29,7 @@
*
* @createdAugust 16, 2001
* @author:Paul Kendall ([EMAIL PROTECTED])
- * @version$Revision: 1.7 $
+ * @version$Revision: 1.8 $
*/
public class MessageLog {
@@ -83,6 +83,9 @@
try {
File[] files = queueName.listFiles();
for ( int i = 0; i files.length; i++ ) {
+// If it's a subdirectory, it's a different queue, PM will restore that
also, so ignore it here
+if (files[i].isDirectory())
+ continue;
String fileName = files[i].getName();
int extIndex = fileName.indexOf( . );
if ( extIndex 0 ) {
1.11 +37 -4 jbossmq/src/main/org/jboss/mq/pm/file/PersistenceManager.java
Index: PersistenceManager.java
===
RCS file:
/cvsroot/jboss/jbossmq/src/main/org/jboss/mq/pm/file/PersistenceManager.java,v
retrieving revision 1.10
retrieving revision 1.11
diff -u -r1.10 -r1.11
--- PersistenceManager.java 2001/11/14 04:23:27 1.10
+++ PersistenceManager.java 2001/11/28 00:55:29 1.11
@@ -15,12 +15,14 @@
import java.io.File;
+import java.io.FileFilter;
import java.io.IOException;
import java.net.URL;
import java.util.Collection;
import java.util.HashMap;
import java.util.Iterator;
import java.util.LinkedList;
+import java.util.ArrayList;
import java.util.Map;
import java.util.TreeSet;
import javax.jms.JMSException;
@@ -43,7 +45,7 @@
* persistence.
*
* @author Paul Kendall ([EMAIL PROTECTED])
- * @version$Revision: 1.10 $
+ * @version$Revision: 1.11 $
*/
public class PersistenceManager extends ServiceMBeanSupport implements
PersistenceManagerMBean, org.jboss.mq.pm.PersistenceManager
{
@@ -159,6 +161,37 @@
}
/**
+* The codegetDirTreecode function takes a directory and
+* looks for all subdirectories below it (recursively)
+*
+* Note: Recursive function, REALLY deep queues WILL cause stack fault
+* Note: Possible bug if someone implements an unused queue cleanup
+*and it attempts to remove the parent dir of a deep queue
+*without verifying that it's really just a parent dir
+*
+* @param parent The directory to look in
+*
+* @return The deep list of subdirectories
+*/
+ private final File[] getDirTree(File parent)
+ {
+ final ArrayList dirs = new ArrayList(); //must be final
+ parent.listFiles(new FileFilter()
+ {
+ public final boolean accept(File file)
+ {
+if (file.isDirectory())
+{
+ dirs.add(file); //add to list of all dirs
+ file.listFiles(this);
+}
+return false; //avoid File.listFiles doing extra work
+ }
+ });
+ return (File[])dirs.toArray(new File[dirs.size()]);
+ }
+
+ /**
* The coderestoreTransactions/code method is called when the
* PersistenceManager service is started. It reads all transaction log
* files, and pre-restores all messages that are committed and not read.
@@ -170,7 +203,8 @@
private void restoreTransactions() throws javax.jms.JMSException
{
TreeSet txs = new TreeSet();
- File[] transactFiles = dataDirFile.listFiles();
+ File[] transactFiles = getDirTree(dataDirFile);
+ int queueNameOffset = dataDirFile.toString().length()+1;
if(transactFiles != null)
{
for (int i = 0; i transactFiles.length; i++)
@@ -179,8 +213,7 @@
if( transactFiles[i].isDirectory() )
{
String dirName = transactFiles[i].toString();
- int start = transactFiles[i].getParent().length()+1;
- String key = dirName.substring(start);
+ String key =
RE: [JBoss-dev] CVS update: jboss/src/main/org/jboss/verifier/strategy AbstractVerifier.java
he is done with the JMX book and he is baack
marcf
|-Original Message-
|From: [EMAIL PROTECTED]
|[mailto:[EMAIL PROTECTED]]On Behalf Of Juha
|Lindfors
|Sent: Tuesday, November 27, 2001 7:27 PM
|To: [EMAIL PROTECTED]
|Subject: [JBoss-dev] CVS update:
|jboss/src/main/org/jboss/verifier/strategy AbstractVerifier.java
|
|
| User: juhalindfors
| Date: 01/11/27 16:27:14
|
| Modified:src/main/org/jboss/verifier/strategy AbstractVerifier.java
| Log:
|
|
| Revision ChangesPath
| 1.24 +9 -4
|jboss/src/main/org/jboss/verifier/strategy/AbstractVerifier.java
|
| Index: AbstractVerifier.java
| ===
| RCS file:
|/cvsroot/jboss/jboss/src/main/org/jboss/verifier/strategy/AbstractV
|erifier.java,v
| retrieving revision 1.23
| retrieving revision 1.24
| diff -u -r1.23 -r1.24
| --- AbstractVerifier.java2001/11/02 06:07:48 1.23
| +++ AbstractVerifier.java2001/11/28 00:27:14 1.24
| @@ -19,7 +19,7 @@
|* Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA
|02111-1307 USA
|*
|* This package and its source code is available at www.jboss.org
| - * $Id: AbstractVerifier.java,v 1.23 2001/11/02 06:07:48 schaefera Exp $
| + * $Id: AbstractVerifier.java,v 1.24 2001/11/28 00:27:14
|juhalindfors Exp $
|*/
|
| // standard imports
| @@ -70,7 +70,7 @@
|* /ul
|* /p
|*
| - * @version $Revision: 1.23 $
| + * @version $Revision: 1.24 $
|* @since JDK 1.3
|*/
| public abstract class AbstractVerifier implements VerificationStrategy {
| @@ -979,8 +979,13 @@
| if (Error.class.isAssignableFrom(type))
| return false;
|
| -if (RuntimeException.class.isAssignableFrom(type))
| -return false;
| +// 28.3.4.4 (6) java.rmi.RemoteException and its subclasses,
|and unchecked
| +// exception classes, are assumed to be mapped to
|the implicit
| +// CORBA system exception, and are therefore not
|explicitly
| +// declared in OMG IDL.
| +//
| +//if (RuntimeException.class.isAssignableFrom(type))
| +//return false;
|
| if (!isRMIIDLValueType(type))
| return false;
|
|
|
|
|___
|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] CVS update: jboss/src/main/org/jboss/util Info.java InfoMBean.java
User: starksm
Date: 01/11/27 20:52:48
Modified:src/main/org/jboss/util Info.java InfoMBean.java
Log:
Add displayPackageInfo operation to display the lava.lang.Package
object info for a package name.
Revision ChangesPath
1.15 +53 -17jboss/src/main/org/jboss/util/Info.java
Index: Info.java
===
RCS file: /cvsroot/jboss/jboss/src/main/org/jboss/util/Info.java,v
retrieving revision 1.14
retrieving revision 1.15
diff -u -r1.14 -r1.15
--- Info.java 2001/08/03 17:15:57 1.14
+++ Info.java 2001/11/28 04:52:48 1.15
@@ -21,7 +21,7 @@
* @author a href=mailto:[EMAIL PROTECTED];Scott Stark/a.
* @author a href=mailto:[EMAIL PROTECTED];Hiram Chirino/a.
* @author a href=mailto:[EMAIL PROTECTED];Jason Dillon/a
- * @version $Revision: 1.14 $
+ * @version $Revision: 1.15 $
*/
public class Info
implements InfoMBean, MBeanRegistration
@@ -58,10 +58,12 @@
System.getProperty(os.arch));
// dump out the entire system properties if debug is enabled
- if (log.isDebugEnabled()) {
+ if (log.isDebugEnabled())
+ {
log.debug(+++ Full System Properties Dump);
Enumeration names= System.getProperties().propertyNames();
- while (names.hasMoreElements()) {
+ while (names.hasMoreElements())
+ {
String pname= (String) names.nextElement();
log.debug(pname + : + System.getProperty(pname));
}
@@ -69,22 +71,27 @@
// MF TODO: say everything that needs to be said here:
// copyright, included libs and TM, contributor and (C) jboss org 2000
- return new ObjectName(OBJECT_NAME);
+ name = name == null ? new ObjectName(OBJECT_NAME) : name;
+ return name;
}
- public void postRegister(Boolean registrationDone) {
+ public void postRegister(Boolean registrationDone)
+ {
// empty
}
- public void preDeregister() throws Exception {
+ public void preDeregister() throws Exception
+ {
// empty
}
- public void postDeregister() {
+ public void postDeregister()
+ {
// empty
}
- public String getThreadGroupInfo(ThreadGroup group) {
+ public String getThreadGroupInfo(ThreadGroup group)
+ {
StringBuffer rc= new StringBuffer();
rc.append(BRB);
@@ -96,7 +103,8 @@
rc.append(blockquote);
Thread threads[]= new Thread[group.activeCount()];
group.enumerate(threads, false);
- for (int i= 0; i threads.length threads[i] != null; i++) {
+ for (int i= 0; i threads.length threads[i] != null; i++)
+ {
rc.append(B);
rc.append(Thread: + threads[i].getName());
rc.append(/B : );
@@ -107,14 +115,16 @@
ThreadGroup groups[]= new ThreadGroup[group.activeGroupCount()];
group.enumerate(groups, false);
- for (int i= 0; i groups.length groups[i] != null; i++) {
+ for (int i= 0; i groups.length groups[i] != null; i++)
+ {
rc.append(getThreadGroupInfo(groups[i]));
}
rc.append(/blockquote);
return rc.toString();
}
- public String runGarbageCollector() {
+ public String runGarbageCollector()
+ {
StringBuffer buff = new StringBuffer();
buff.append(h3Before/h3);
buff.append(listMemoryUsage());
@@ -127,7 +137,8 @@
return buff.toString();
}
- public String listMemoryUsage() {
+ public String listMemoryUsage()
+ {
String rc= PBTotal Memory: /B +
(Runtime.getRuntime().totalMemory()) +
/P + PBFree Memory: /B +
@@ -135,7 +146,8 @@
return rc;
}
- public String listSystemInfo() {
+ public String listSystemInfo()
+ {
// Dump out basic info as INFO priority msgs
StringBuffer rc= new StringBuffer();
rc.append(pre);
@@ -160,10 +172,12 @@
return rc.toString();
}
- public String listThreadDump() {
+ public String listThreadDump()
+ {
// Get the root thread group
ThreadGroup root= Thread.currentThread().getThreadGroup();
- while (root.getParent() != null) {
+ while (root.getParent() != null)
+ {
root = root.getParent();
}
@@ -181,17 +195,39 @@
return rc;
}
+ /** Display the java.lang.Package info for the pkgName */
+ public String displayPackageInfo(String pkgName)
+ {
+ Package pkg = Package.getPackage(pkgName);
+ if( pkg == null )
+ return h2Package: +pkgName+ Not Found!/h2\n;
+
+ StringBuffer info = new StringBuffer(h2Package: +pkgName+/h2\n);
+ info.append(pre\n);
+
[JBoss-dev] Using java.lang.Package to get more info about a build
I would like to switch from the hard-coded version information embedded in
classes to use the standard java package version manifest headers that
are accessed using the java.lang.Package class. I have added support for
this to the 2.4.4 build I'm working on. It uses a target in the build.xml to
generate the approriate manifest headers. For example, to build the run.mf
manifest the following is done:
project ...
...
target name=create-manifest
copy file=${etc.dir}/${manifest.file} todir=${build.dir}
overwrite=true /
echo file=${build.dir}/${manifest.file}
append=trueSpecification-Title: JBoss-${version}
Specification-Version: ${version}
Specification-Vendor: JBoss Group, LLC
Implementation-Title: JBoss-${version} CVSTag=${version-tag}
Implementation-Version: ${version}.${build.time}
Implementation-Vendor: JBoss Group, LLC
/echo
fixcrlf srcdir=${build.dir} includes=${manifest.file} eol=crlf /
/target
...
antcall target=create-manifest
param name=manifest.file value=run.mf/
/antcall
jar jarfile=${build.bin.dir}/run.jar
basedir=${build.classes.dir}
manifest=${build.dir}/run.mf
include name=org/jboss/Main*.* /
include name=org/jboss/dependencies/** /
/jar
/project
The encoded information is then available for use at runtime. I have updated
the Info MBean to display the Package info, and for example, the current
2.4.4 build I'm testing shows the following info for the org.jboss
package:
Package: org.jboss
SpecificationTitle: JBoss-2.4.4
SpecificationVersion: 2.4.4
SpecificationVendor: JBoss Group, LLC
ImplementationTitle: JBoss-2.4.4 CVSTag=Rel_2_4_4_16
ImplementationVersion: 2.4.4.2001-11-27 20:59:04 PST
ImplementationVendor: JBoss Group, LLC
isSealed: false
I would like to update main to use a similar approach, but it would probably
be better to create either a custom manifest task or jar task to allow the
modules to use the manifest creation logic.
Scott Stark
Chief Technology Officer
JBoss Group, LLC
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: newsite/src/docs/developers head.jsp index.jsp navigation.jsp
User: mnf999
Date: 01/11/27 21:17:42
Modified:src/docs/developers head.jsp index.jsp navigation.jsp
Log:
new banners, new training, new partners
Revision ChangesPath
1.7 +3 -2 newsite/src/docs/developers/head.jsp
Index: head.jsp
===
RCS file: /cvsroot/jboss/newsite/src/docs/developers/head.jsp,v
retrieving revision 1.6
retrieving revision 1.7
diff -u -r1.6 -r1.7
--- head.jsp 2001/11/21 03:21:09 1.6
+++ head.jsp 2001/11/28 05:17:42 1.7
@@ -27,8 +27,9 @@
table cellspacing=0 cellpadding=0 border=0 width=100%
tr
td bgcolor=#00 align=center
- a href=/jbossgroup/training.jsp
- img src=/pictures/banner-x.gif border=0/a/td
+
+ jsp:include page=/common/picabanner.jsp flush=true /
+
/tr
/table
1.11 +4 -4 newsite/src/docs/developers/index.jsp
Index: index.jsp
===
RCS file: /cvsroot/jboss/newsite/src/docs/developers/index.jsp,v
retrieving revision 1.10
retrieving revision 1.11
diff -u -r1.10 -r1.11
--- index.jsp 2001/11/21 03:21:09 1.10
+++ index.jsp 2001/11/28 05:17:42 1.11
@@ -59,14 +59,14 @@
the whole team.
-
-p class=headTRAINING: BOSTON JAN 21-25, SYDNEY FEB 11-15
+
+p class=headTRAINING FROM THE GURUS: BOSTON JAN 21-25, SYDNEY FEB 11-15, LONDON
MAR 11-15
p class=textSpend your money on source knowledge not proprietary licenses.
Training is a requirement for those wishing to participate in The JBoss Certified
Affiliate Program,
for 3rd party JBoss consulting and support providers. The next JBoss Group
trainings
- will be held in Boston and Down Under in Sydney.
- Don't miss out on our unique road show.
+ will be held in Boston, Down Under in Sydney and in Londond again.
+ Don't miss out on our unique Q1 2002 road show.
a class=link href=/jbossgroup/training.jspRead more/a.
1.14 +11 -1 newsite/src/docs/developers/navigation.jsp
Index: navigation.jsp
===
RCS file: /cvsroot/jboss/newsite/src/docs/developers/navigation.jsp,v
retrieving revision 1.13
retrieving revision 1.14
diff -u -r1.13 -r1.14
--- navigation.jsp2001/11/21 21:47:33 1.13
+++ navigation.jsp2001/11/28 05:17:42 1.14
@@ -2,10 +2,20 @@
% if (request.getParameter(printable) == null) { %
+
+table cellspacing=0 cellpadding=0 border=0 width=100%
+ tr
+ td bgcolor=#ee align=center
+ jsp:include page=/common/picabanner.jsp flush=true /
+ /tr
+/table
+
hr
p[a href=/developers/index.jspHome/a]
[a href=#TOPTop/a]
-
+br
+
+
/div/tdtdimg src=/pictures/t.gif width=15 height=1/td
/tr/table
/td
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: newsite/src/docs/jbossgroup cocobase.jsp partners.jsp training.jsp
User: mnf999 Date: 01/11/27 21:17:42 Modified:src/docs/jbossgroup partners.jsp training.jsp Added: src/docs/jbossgroup cocobase.jsp Log: new banners, new training, new partners Revision ChangesPath 1.3 +74 -43newsite/src/docs/jbossgroup/partners.jsp Index: partners.jsp === RCS file: /cvsroot/jboss/newsite/src/docs/jbossgroup/partners.jsp,v retrieving revision 1.2 retrieving revision 1.3 diff -u -r1.2 -r1.3 --- partners.jsp 2001/10/12 23:01:29 1.2 +++ partners.jsp 2001/11/28 05:17:42 1.3 @@ -31,11 +31,67 @@ high-quality, JBoss-compatible products, remember that, through their partnership with JBoss Group, all the companies featured here help finance the free JBoss effort and these product sales help JBoss remain strong, competitive and ahead of the curve. + +P class=headfont color=redAPPLICATION PLATFORMS/font +p class=headALTOWEB +p class=texta class=link href=http://www.altoweb.com/b/jboss.html; +img align=left alt= height=62 src=/pictures/altowebLogo.gif width=162 hspace=10 vspace=3 border=2/a +The AltoWebreg; Application Platform, run on JBoss#153; application server, provides a reusable, + component-based architecture and rapid application development solution that streamlines + the development, deployment, monitoring, and management of e-Business applications. The AltoWeb + Application Platform on JBoss maximizes your productivity when you need to deliver an increasing + number of applications faster than ever before, with fewer resources, and at a lower + cost. The AltoWeb Application Platform on JBoss helps you develop, deploy, and change your + e-Business applications in the fastest possible way. +a class=link href=http://www.altoweb.com/b/jboss.html;Read More/a +a class=link href=http://www.altoweb.com/b/jbossBuy.html;Buy Now/a. + +p class=headfont color=redHOSTING/font + +p class=headRACKSPACE: MANAGED JBOSS HOSTING NOW AVAILABLE + +p class=text +a class=link href=http://www.rackspace.com/?supbig=jboss1; +img src=/pictures/rckspc_logo_web_150.gif hspace=10 vspace=3 align=left +/a +Rackspace Managed Hosting is a pioneer and leader in the fastest growing segment of Internet hosting. +Rackspace rents dedicated web servers that anyone can afford. No colocation or shared servers, +only whole servers. Using hardware chosen for web hosting, Rackspace builds custom web servers to host +Internet sites of any size or type. +Standard choices are; Windows/IIS or Linux/Apache, Pentium or UltraSparc, RAM, size and type of hard +drives, and estimated bandwidth. Additional services include; firewalls, load balancing, clustering, backup, advanced monitoring, site analysis, streaming media, email and ecommerce software, and more. +Rackspace will build your server and place it in a world-class datacenter with the other 4000 plus +servers they manage. They promise to have it online for you within 24 hours. You get root access +to your server and remotely install any software and content you want. You manage the applications +and content, and Rackspace guarantees the operation of every server and datacenter component. +brContracts can be as short as 30-days. +brAnd the best part, every component supplied by Rackspace comes with 24x7 Fanatical customer service that's ranked #1 in the hosting industry. +It couldn't be any easier or more cost effective. +a class=link href=mailto:[EMAIL PROTECTED]?subject=Rackspace;Buy Now/a. + +p class=headfont color=redIDE INTEGRATION/font + +p class=headTOGETHERSOFT DEPLOYER FOR JBOSS. +p class=text +The BJBoss#152; Deployer Plugin/B for Together ControlCenter#152; 5.0.2 and 5.5 provides +EJB Jar, WAR and EAR generation for the JBoss 2.2/2.4 server. The generated files include the JBoss +specific XML descriptor files (jboss.xml, jboss-web.xml and jaws.xml). The plugin also provides +server management features to start/stop the JBoss server and undeploy modules. JBoss can be +launched in debug and the EJBs deployed; the Servlets/JSPs can be deployed and Tomcat launched in +debug. Then the debugger can be used to step through any or all of the JSPs, Servlets and EJBs +(and JBoss code if you so wish!). All this can be done without leaving the +ITogether/ISUPreg;/SUPenvironment. +a class=link href=/jbossgroup/together.jspRead more/a +a class=link href=http://www.flashline.com/components/view.jsp?prodid=4042affiliateid=260343;Buy Now/a +PFONT SIZE=1 +Together is a registered trademark of TogetherSoft Corporation BR +Together ControlCenter is a trademark of TogetherSoft Corporation/FONT/P + p class=headfont color=redPERSISTENCE ENGINES/font p class=headCOCOBASE -p class=texta class=link href=http://www.thoughtinc.com/jboss/index.html; +p
[JBoss-dev] CVS update: website-forums/src/web/forums footer.jsp header.jsp
User: mnf999 Date: 01/11/27 21:18:39 Modified:src/web/forums footer.jsp header.jsp Log: new header and footer for forums, banners Revision ChangesPath 1.5 +8 -0 website-forums/src/web/forums/footer.jsp Index: footer.jsp === RCS file: /cvsroot/jboss/website-forums/src/web/forums/footer.jsp,v retrieving revision 1.4 retrieving revision 1.5 diff -u -r1.4 -r1.5 --- footer.jsp2001/10/06 06:56:02 1.4 +++ footer.jsp2001/11/28 05:18:39 1.5 @@ -1,4 +1,12 @@ + +table cellspacing=0 cellpadding=0 border=0 width=100% + tr + td bgcolor=#ff align=center + jsp:include page=/common/picabanner.jsp flush=true / + /tr +/table + table cellpadding=6 cellspacing=0 border=0 width=100% tr td align=center 1.7 +10 -7 website-forums/src/web/forums/header.jsp Index: header.jsp === RCS file: /cvsroot/jboss/website-forums/src/web/forums/header.jsp,v retrieving revision 1.6 retrieving revision 1.7 diff -u -r1.6 -r1.7 --- header.jsp2001/10/11 15:01:13 1.6 +++ header.jsp2001/11/28 05:18:39 1.7 @@ -1,8 +1,8 @@ % /** * $RCSfile: header.jsp,v $ - * $Revision: 1.6 $ - * $Date: 2001/10/11 15:01:13 $ + * $Revision: 1.7 $ + * $Date: 2001/11/28 05:18:39 $ */ % @@ -41,13 +41,16 @@ vlink=%= JiveGlobals.getJiveProperty(skin.default.vLinkColor) % alink=%= JiveGlobals.getJiveProperty(skin.default.aLinkColor) % + table cellspacing=0 cellpadding=0 border=0 width=100% - tr - td bgcolor=#00 align=center - a class=link href = /jbossgroup/training.jsp - img src=/pictures/training1.gif border = 0/a/td - /tr + tr + td bgcolor=#00 align=center + + jsp:include page=/common/picabanner.jsp flush=true / + + /tr /table + table cellspacing=0 cellpadding=0 border=0 width=100% tr ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] 2.4.4 performance issue resolved, MarshalledObject again
I finally tracked down the issue that was causing the performance regression in the pending 2.4.4 release. It was another case of the MarshalledObject generating huge serialized forms due to the encoded object's class loader classpath. The change that triggered this was the removal of the jboss-client.jar from the run.jar classpath. This caused the ejb handles to see the server classpath as their annotated classpath and resulted in 9k serialized form sizes. I didn't want to go back to needing additional classes in the classpath so I used a trival subclass of MLet as the server main classloader that returned an empty URL[] from the getURLs() method. This restored the RMI server codebase value as the annotated codebase of the ejb handles and the serialized size dropped to 1k. The moral is known minimize your MarshalledObject input's class loader classpath. Scott Stark Chief Technology Officer JBoss Group, LLC ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: newsite/src/docs/common picabanner.jsp doco.jsp
User: mnf999
Date: 01/11/27 21:17:42
Modified:src/docs/common doco.jsp
Added: src/docs/common picabanner.jsp
Log:
new banners, new training, new partners
Revision ChangesPath
1.8 +26 -7 newsite/src/docs/common/doco.jsp
Index: doco.jsp
===
RCS file: /cvsroot/jboss/newsite/src/docs/common/doco.jsp,v
retrieving revision 1.7
retrieving revision 1.8
diff -u -r1.7 -r1.8
--- doco.jsp 2001/11/07 19:55:37 1.7
+++ doco.jsp 2001/11/28 05:17:41 1.8
@@ -1,13 +1,33 @@
!-- CONTENT --
p class=headBUY THE DOCUMENTATION
-p class=textjsp:include page=/common/picateam.jsp flush=true /
+p class=text
+
+
+
+img align=left border=1 hspace=10 vspace=3 alt=Scott Stark, USA
src=/pictures/stark2.gif
+
In order to support the development of JBoss and ensure that the documentation
remains up to date we offer printable version of the documentation for purchase.
The manual contains all the documentation a user needs to install,
configure and run JBoss. It also includes a quick start section and helps you to
make your first steps
with JBoss. As a promotion we include the working draft of the forthcoming JBoss
book to be
- published by SAMS publishing. a class=link
href=http://www.flashline.com/components/view.jsp?prodid=4252;Buy now/a.
+ published by SAMS publishing. This book is a complete rewrite of the documentation
by Scott Stark.a class=link
href=http://www.flashline.com/components/view.jsp?prodid=4252;Buy now/a.
+
+
+p class=headJBOSSCMP 2.0 PERSISTENCE ENGINE DOCUMENTATION
+img align=right border=1 hspace=10 vspace=3 alt=Dain Sundstrom, USA
src=/pictures/dain.jpg
+p class=textJBOSS 3.0 comes with a full blown JBOSSCMP persistence engine.
This is a fully
+EJB 2.0 compliant persistence engine. The engine is Open Source and free (part of
the free JBOSS core),
+the documentation costs $5. This is the official documentation, for the CMP 2.0
engine in JBoss.
+JBossCMP includes many new features, such as eager/lazy loading of fields,
read-only fields, Container
+Managed Relationships, ejbSelect methods, and ejb-ql support. The manual
introduces you to each
+feature in detail and its configuration, and guides you through the process of
specifying the database mapping
+of container managed fields, relationships and queries. Example code is included
throughout the text.
+This is you chance to purchase the official documentation package written by the
feature's developer,
+Dain Sundstrom. This material is not available in the free documentation or the
$9.99 base documentation.
+a class=link href=http://www.flashline.com/Components/View.jsp?prodid=4312;Buy
Now/a.
+
p class=headBROWSE THE MANUAL
p class=textA free volunteer maintained manual was developed in the
early stages of JBoss. A more complete and updated version
@@ -22,10 +42,10 @@
CVS. /li
li
FORM ACTION=http://search.freefind.com/find.html; METHOD=GET
-Search the select name=s
- option value=manual selectedmanual only/option
- option value=entire JBoss site/option
-/select
+Search the select name=s
+ option value=manual selectedmanual only/option
+ option value=entire JBoss site/option
+/select
for a keyword:
INPUT TYPE=HIDDEN NAME=id SIZE=-1 VALUE=811347
INPUT TYPE=HIDDEN NAME=pageid SIZE=-1 VALUE=r
@@ -48,5 +68,4 @@
ul class=text
lia class=link href=/ECPerf.htmlRunning ECperf on JBoss/a/li
lia class=link href=/migration.jspMigrating to JBoss 2.2/a/li
- lia class=link href=/cmp-two.jspActivating CMP 2.x support/a/li
/ul
1.1 newsite/src/docs/common/picabanner.jsp
Index: picabanner.jsp
===
%!
String[] banner = {
sam.gif,
service.gif,
download.gif,
viagra4.gif,
banner-x.gif,
banner-x.gif,
banner-x.gif
};
java.util.Random random = new java.util.Random();
%
% int select = new Float(random.nextFloat()*banner.length).intValue(); %
a class=link href=/jbossgroup/training.jsp
img border=0
alt=Oh come on you know you want it!
src=/pictures/%= banner[select] %/a
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: newsite/src/docs binary.jsp head.jsp index.jsp navigation.jsp
User: mnf999 Date: 01/11/27 21:17:37 Modified:src/docs binary.jsp head.jsp index.jsp navigation.jsp Log: new banners, new training, new partners Revision ChangesPath 1.15 +43 -17newsite/src/docs/binary.jsp Index: binary.jsp === RCS file: /cvsroot/jboss/newsite/src/docs/binary.jsp,v retrieving revision 1.14 retrieving revision 1.15 diff -u -r1.14 -r1.15 --- binary.jsp2001/11/21 21:13:48 1.14 +++ binary.jsp2001/11/28 05:17:32 1.15 @@ -41,64 +41,90 @@ p class=textDownload now: -p class=headJBoss 2.4p - +p class=headfont color=redJBOSS 3.0/fontp p class=text - table border=0 - trth align=leftp class=textPackages/ththp class=textnbsp;nbsp;nbsp;Sizenbsp;nbsp;nbsp;/ththp class=textDate/th/tr + trth align=leftp class=textPackages/th + thp class=textnbsp;nbsp;nbsp;Sizenbsp;nbsp;nbsp;/th + thp class=textDate/th/tr tr tda class=link href=http://prdownloads.sourceforge.net/jboss/jboss-3.0.0alpha.zip;JBoss-3.0.0.zip alpha/a/td -td align=rightp class=text9951882/td +td align=rightp class=text9.9M/td td align=centerp class=textNovember 21, 2001/td /tr -trth colspan=3 bgcolor=#008000/th/tr +/table + hr +p class=headfont color=redJBOSS 2.4/fontp + +p class=text + + table border=0 + trth align=leftp class=textPackages/th + thp class=textnbsp;nbsp;nbsp;Sizenbsp;nbsp;nbsp;/th + thp class=textDate/th/tr + tr tda class=link href=http://prdownloads.sourceforge.net/jboss/JBoss-2.4.3.zip;JBoss-2.4.3.zip/a/td -td align=rightp class=text6125514/td +td align=rightp class=text6.1M/td td align=centerp class=textOctober 3, 2001/td /tr tr tda class=link href=http://prdownloads.sourceforge.net/jboss/JBoss-2.4.3.tgz;JBoss-2.4.3.tgz Src Archive/a/td -td align=rightp class=text19010983/td +td align=rightp class=text19M/td td align=centerp class=textOctober 3, 2001/td /tr tr tda class=link href=http://prdownloads.sourceforge.net/jboss/JBoss-2.4.3_Tomcat-3.2.3.zip;JBoss-2.4.3_Tomcat-3.2.3.zip/a/td -td align=rightp class=text9404161/td +td align=rightp class=text9.4M/td td align=centerp class=textOctober 3, 2001/td /tr tr tda class=link href=http://prdownloads.sourceforge.net/jboss/JBoss-2.4.3_Jetty-3.1.3-1.zip;JBoss-2.4.3_Jetty-3.1.3-1.zip/a/td -td align=rightp class=text10512966/td +td align=rightp class=text10.5M/td td align=centerp class=textOctober 30, 2001/td /tr trth colspan=3 bgcolor=#008000/th/tr tr tda class=link href=http://prdownloads.sourceforge.net/jboss/JBoss-2.4.1.zip;JBoss-2.4.1.zip/a/td -td align=rightp class=text8379911/td -td align=centerp class=textSetempter 10, 2001/td +td align=rightp class=text8.3M/td +td align=centerp class=textSeptember 10, 2001/td /tr tr tda class=link href=http://prdownloads.sourceforge.net/jboss/JBoss-2.4.1a_Tomcat-3.2.3.zip;JBoss-2.4.1a_Tomcat-3.2.3.zip/a/td -td align=rightp class=text9018426/td -td align=centerp class=textSetempter 14, 2001/td +td align=rightp class=text9M/td +td align=centerp class=textSeptember 14, 2001/td /tr tr tda class=link href=http://prdownloads.sourceforge.net/jboss/JBoss-2.4.1_Jetty-3.1.RC9-1.zip;JBoss-2.4.1_Jetty-3.1.RC9-1.zip/a/td -td align=rightp class=text12773406/td +td align=rightp class=text12.7M/td td align=centerp class=textSeptember 15, 2001/td /tr /table br -a class=link href=changelog_2_4_beta.jspChange Log/a for version 2.4.x. +p class=texta class=link href=changelog_2_4_beta.jspChange Log/a for version 2.4.x. + +p class=head PARTNER SOFTWARE FOR JBOSS 2.4.x/p +AltoWeb#153; Instant J2EE and Web Services. Evaluation software bundled +with JBoss 2.4.3 and Tomcat 3.2.3. +table border=0 + trth align=leftp class=textPackages/th + thp class=textnbsp;nbsp;nbsp;Sizenbsp;nbsp;nbsp;/th + thp class=textDate/th/tr +tr +tda class=link href=http://www.altoweb.com/b/jbossDl.html;altoweb-2.5-jboss243-nojvm.win.zip/a +td31.8M/td +tdNovember 12,2001/td +/tr +/table + hr -p class=headJBoss 2.2.2/p + +p class=headfont color=red 2.2.2/font/p p class=text table border=0 1.10 +1 -2 newsite/src/docs/head.jsp Index: head.jsp === RCS file:
[JBoss-dev] CVS update: newsite/src/docs/pictures altowebLogo.gif download.gif sam.gif service.gif viagra4.gif
User: mnf999 Date: 01/11/27 21:17:42 Added: src/docs/pictures altowebLogo.gif download.gif sam.gif service.gif viagra4.gif Log: new banners, new training, new partners Revision ChangesPath 1.1 newsite/src/docs/pictures/altowebLogo.gif Binary file 1.1 newsite/src/docs/pictures/download.gif Binary file 1.1 newsite/src/docs/pictures/sam.gif Binary file 1.1 newsite/src/docs/pictures/service.gif Binary file 1.1 newsite/src/docs/pictures/viagra4.gif Binary file ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jbosssx/src/main/org/jboss/security Logger.java
User: starksm
Date: 01/11/27 22:10:45
Modified:src/main/org/jboss/security Tag: Branch_2_4 Logger.java
Log:
Complete switch to org.jboss.logging.Logger
Add support for package version manifest headers
Revision ChangesPath
No revision
No revision
1.1.2.2 +3 -2 jbosssx/src/main/org/jboss/security/Attic/Logger.java
Index: Logger.java
===
RCS file: /cvsroot/jboss/jbosssx/src/main/org/jboss/security/Attic/Logger.java,v
retrieving revision 1.1.2.1
retrieving revision 1.1.2.2
diff -u -r1.1.2.1 -r1.1.2.2
--- Logger.java 2001/10/19 23:48:23 1.1.2.1
+++ Logger.java 2001/11/28 06:10:45 1.1.2.2
@@ -8,13 +8,14 @@
classes using the thread context class loader.
* @author [EMAIL PROTECTED]
- * @version $Revision: 1.1.2.1 $
+ * @version $Revision: 1.1.2.2 $
*/
public class Logger
{
/** */
private static final String CATEGORY_CLASS = org.apache.log4j.Category;
private static final String PRIORITY_CLASS = org.apache.log4j.Priority;
+ private static final String TRACE_PRIORITY_CLASS =
org.jboss.logging.TracePriority;
private static final int GET_INSTANCE = 0;
private static final int IS_ENABLED_FOR_PRIORITY = 1;
private static final int LOG_PRIORITY_MSG = 2;
@@ -221,7 +222,7 @@
log4jPriorities[n] = toPriority.invoke(null, args);
}
// Load the custom trace Priority class
- Class trace = loader.loadClass(org.jboss.logging.log4j.TracePriority);
+ Class trace = loader.loadClass(TRACE_PRIORITY_CLASS);
toPriorityTypes = new Class[] {String.class, priorityClass};
toPriority = trace.getDeclaredMethod(toPriority, toPriorityTypes);
log4jPriorities[0] = toPriority.invoke(null, new Object[]{TRACE,
log4jPriorities[1]});
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jbosssx/src/build build.xml
User: starksm
Date: 01/11/27 22:10:45
Modified:src/build Tag: Branch_2_4 build.xml
Log:
Complete switch to org.jboss.logging.Logger
Add support for package version manifest headers
Revision ChangesPath
No revision
No revision
1.11.2.5 +23 -7 jbosssx/src/build/Attic/build.xml
Index: build.xml
===
RCS file: /cvsroot/jboss/jbosssx/src/build/Attic/build.xml,v
retrieving revision 1.11.2.4
retrieving revision 1.11.2.5
diff -u -r1.11.2.4 -r1.11.2.5
--- build.xml 2001/11/09 10:30:14 1.11.2.4
+++ build.xml 2001/11/28 06:10:45 1.11.2.5
@@ -1,6 +1,6 @@
!-- An ant build file for JBossSX security framework
@author [EMAIL PROTECTED]
-@version $Revision: 1.11.2.4 $
+@version $Revision: 1.11.2.5 $
--
project name=JBossSX default=jar basedir=../../
!-- The location of the JBoss server dist tree. This is
@@ -23,6 +23,7 @@
property name=conf.dir value=${dist.dir}/conf/default/
property name=etc.dir value=${basedir}/src/etc/
property name=src.dir value=${basedir}/src/main/
+property name=Name value=JBossSX/
property name=packages value=org.jboss.* /
@@ -42,6 +43,17 @@
mkdir dir=${build.lib}/
mkdir dir=${dist.dir}/
/target
+ target name=create-manifest
+echo file=${build.dir}/version.mf
+ append=trueSpecification-Title: ${Name}-${version}
+Specification-Version: ${version}
+Specification-Vendor: JBoss Group, LLC
+Implementation-Title: ${Name}-${release} CVSTag=${release-tag}
+Implementation-Version: ${release}.${build.time}
+Implementation-Vendor: JBoss Group, LLC
+/echo
+fixcrlf srcdir=${build.dir} includes=version.mf eol=crlf /
+ /target
!-- The main project classpath --
path id=base.path
@@ -104,9 +116,11 @@
!-- Create the JBossSX jars --
target name=jar depends=compile
+antcall target=create-manifest /
!-- The jbosssx.jar --
jar jarfile=${build.lib}/jbosssx.jar
basedir=${build.classes.dir}
+manifest=${build.dir}/version.mf
include name=org/jboss/security/** /
!-- Exclude the JAAS 1.0x LoginModule and related classes that
@@ -114,8 +128,8 @@
JAAS.
--
exclude name=org/jboss/security/ClientLoginModule.class /
- exclude name=org/jboss/security/NestableGroup*.class /
- exclude name=org/jboss/security/NestablePrincipal*.class /
+exclude name=org/jboss/security/NestableGroup*.class /
+exclude name=org/jboss/security/NestablePrincipal*.class /
exclude name=org/jboss/security/SecurityAssociation*.class /
exclude name=org/jboss/security/AnybodyPrincipal.class /
exclude name=org/jboss/security/NobodyPrincipal.class /
@@ -137,10 +151,11 @@
!-- The jboss-jaas.jar, the compliment of jbosssx.jar --
jar jarfile=${build.lib}/jboss-jaas.jar
basedir=${build.classes.dir}
+manifest=${build.dir}/version.mf
include name=org/jboss/security/ClientLoginModule.class /
- include name=org/jboss/security/NestableGroup*.class /
- include name=org/jboss/security/NestablePrincipal*.class /
+include name=org/jboss/security/NestableGroup*.class /
+include name=org/jboss/security/NestablePrincipal*.class /
include name=org/jboss/security/SecurityAssociation*.class /
include name=org/jboss/security/AnybodyPrincipal.class /
include name=org/jboss/security/NobodyPrincipal.class /
@@ -162,11 +177,12 @@
!-- The jbosssx-client.jar, a subset of jboss-jaas.jar --
jar jarfile=${build.lib}/jbosssx-client.jar
basedir=${build.classes.dir}
+manifest=${build.dir}/version.mf
include name=org/jboss/security/AnybodyPrincipal.class /
include name=org/jboss/security/ClientLoginModule.class /
- include name=org/jboss/security/NestableGroup*.class /
- include name=org/jboss/security/NestablePrincipal*.class /
+ include name=org/jboss/security/NestableGroup*.class /
+ include name=org/jboss/security/NestablePrincipal*.class /
include name=org/jboss/security/NobodyPrincipal.class /
include name=org/jboss/security/Logger.class /
include name=org/jboss/security/SimpleGroup.class /
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jbosssx/src/main/org/jboss/security/ssl DomainServerSocketFactory.java RMISSLClientSocketFactory.java
User: starksm
Date: 01/11/27 22:10:46
Modified:src/main/org/jboss/security/ssl Tag: Branch_2_4
DomainServerSocketFactory.java
RMISSLClientSocketFactory.java
Log:
Complete switch to org.jboss.logging.Logger
Add support for package version manifest headers
Revision ChangesPath
No revision
No revision
1.1.2.3 +3 -4
jbosssx/src/main/org/jboss/security/ssl/Attic/DomainServerSocketFactory.java
Index: DomainServerSocketFactory.java
===
RCS file:
/cvsroot/jboss/jbosssx/src/main/org/jboss/security/ssl/Attic/DomainServerSocketFactory.java,v
retrieving revision 1.1.2.2
retrieving revision 1.1.2.3
diff -u -r1.1.2.2 -r1.1.2.3
--- DomainServerSocketFactory.java2001/11/09 10:18:14 1.1.2.2
+++ DomainServerSocketFactory.java2001/11/28 06:10:46 1.1.2.3
@@ -19,8 +19,7 @@
import com.sun.net.ssl.TrustManager;
import com.sun.net.ssl.TrustManagerFactory;
-import org.apache.log4j.Category;
-
+import org.jboss.logging.Logger;
import org.jboss.security.SecurityDomain;
/** An implementation of ServerSocketFactory that creates SSL server sockets
@@ -33,11 +32,11 @@
@see org.jboss.security.SecurityDomain
@author [EMAIL PROTECTED]
-@version $Revision: 1.1.2.2 $
+@version $Revision: 1.1.2.3 $
*/
public class DomainServerSocketFactory extends ServerSocketFactory
{
- private static Category log =
Category.getInstance(DomainServerSocketFactory.class);
+ private static Logger log = Logger.getLogger(DomainServerSocketFactory.class);
private transient SecurityDomain securityDomain;
private transient InetAddress bindAddress;
1.2.2.2 +4 -4
jbosssx/src/main/org/jboss/security/ssl/RMISSLClientSocketFactory.java
Index: RMISSLClientSocketFactory.java
===
RCS file:
/cvsroot/jboss/jbosssx/src/main/org/jboss/security/ssl/RMISSLClientSocketFactory.java,v
retrieving revision 1.2.2.1
retrieving revision 1.2.2.2
diff -u -r1.2.2.1 -r1.2.2.2
--- RMISSLClientSocketFactory.java2001/11/09 10:18:14 1.2.2.1
+++ RMISSLClientSocketFactory.java2001/11/28 06:10:46 1.2.2.2
@@ -16,13 +16,13 @@
import javax.net.ssl.SSLSocketFactory;
import javax.net.ssl.SSLSocket;
-import org.apache.log4j.Category;
+import org.jboss.logging.Logger;
/** An implementation of RMIClientSocketFactory that uses the JSSE
default SSLSocketFactory to create a client SSLSocket.
*
* @author [EMAIL PROTECTED]
- * @version $Revision: 1.2.2.1 $
+ * @version $Revision: 1.2.2.2 $
*/
public class RMISSLClientSocketFactory implements HandshakeCompletedListener,
RMIClientSocketFactory, Serializable
@@ -60,8 +60,8 @@
public void handshakeCompleted(HandshakeCompletedEvent handshakeCompletedEvent)
{
- Category log = Category.getInstance(RMISSLClientSocketFactory.class);
- if( log.isDebugEnabled() )
+ Logger log = Logger.getLogger(RMISSLClientSocketFactory.class);
+ if( log.isTraceEnabled() )
{
String cipher = handshakeCompletedEvent.getCipherSuite();
SSLSession session = handshakeCompletedEvent.getSession();
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jbosssx/src/main/org/jboss/security/plugins JaasSecurityManager.java
User: starksm
Date: 01/11/27 22:10:46
Modified:src/main/org/jboss/security/plugins Tag: Branch_2_4
JaasSecurityManager.java
Log:
Complete switch to org.jboss.logging.Logger
Add support for package version manifest headers
Revision ChangesPath
No revision
No revision
1.7.2.9 +10 -12
jbosssx/src/main/org/jboss/security/plugins/JaasSecurityManager.java
Index: JaasSecurityManager.java
===
RCS file:
/cvsroot/jboss/jbosssx/src/main/org/jboss/security/plugins/JaasSecurityManager.java,v
retrieving revision 1.7.2.8
retrieving revision 1.7.2.9
diff -u -r1.7.2.8 -r1.7.2.9
--- JaasSecurityManager.java 2001/11/09 10:24:51 1.7.2.8
+++ JaasSecurityManager.java 2001/11/28 06:10:46 1.7.2.9
@@ -29,9 +29,7 @@
import javax.security.auth.callback.PasswordCallback;
import javax.security.auth.callback.UnsupportedCallbackException;
-import org.apache.log4j.Category;
-
-import org.jboss.logging.log4j.TracePriority;
+import org.jboss.logging.Logger;
import org.jboss.security.AppPolicy;
import org.jboss.security.AuthenticationInfo;
import org.jboss.security.RealmMapping;
@@ -55,7 +53,7 @@
@author a href=[EMAIL PROTECTED]Oleg Nitz/a
@author [EMAIL PROTECTED]
- @version $Revision: 1.7.2.8 $
+ @version $Revision: 1.7.2.9 $
*/
public class JaasSecurityManager implements SubjectSecurityManager, RealmMapping
{
@@ -90,7 +88,7 @@
private SecurityAssociationHandler handler = new SecurityAssociationHandler();
/** The log4j category for the security manager domain
*/
- protected Category log;
+ protected Logger log;
/** Get the currently authenticated Subject in securityDomain.
@return The Subject for securityDomain if one exists, false otherwise.
@@ -143,8 +141,8 @@
public JaasSecurityManager(String securityDomain)
{
this.securityDomain = securityDomain;
- String categoryName = getClass().getName()+#+securityDomain;
- this.log = Category.getInstance(categoryName);
+ String categoryName = getClass().getName()+'.'+securityDomain;
+ this.log = Logger.getLogger(categoryName);
try
{ // Try to get the SecurityPolicy from the JAAS Policy class
securityPolicy = (SecurityPolicy) Policy.getPolicy();
@@ -374,7 +372,7 @@
catch(LoginException e)
{
// Don't log anonymous user failures unless trace level logging is on
- if( principal != null principal.getName() != null ||
log.isEnabledFor(TracePriority.TRACE) )
+ if( principal != null principal.getName() != null ||
log.isTraceEnabled() )
log.debug(Login failure, e);
}
@@ -401,8 +399,8 @@
*/
private boolean validateCache(DomainInfo info, Object credential)
{
- if( log.isEnabledFor(TracePriority.TRACE) )
- log.log(TracePriority.TRACE, validateCache, info=+info);
+ if( log.isTraceEnabled() )
+ log.trace(validateCache, info=+info);
Object subjectCredential = info.credential;
boolean isValid = false;
@@ -461,8 +459,8 @@
info.subject = subject;
info.credential = credential;
- if( log.isEnabledFor(TracePriority.TRACE) )
- log.log(TracePriority.TRACE, updateCache, subject=+subject);
+ if( log.isTraceEnabled() )
+ log.trace(updateCache, subject=+subject);
/* If we don't have a cache policy create a default timed cache
that has an 1800 sec lifetime, is thread-safe, and a resolution
of 60 seconds.
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jbosssx/src/main/org/jboss/security/auth/spi DatabaseServerLoginModule.java UsernamePasswordLoginModule.java
User: starksm
Date: 01/11/27 22:10:45
Modified:src/main/org/jboss/security/auth/spi Tag: Branch_2_4
DatabaseServerLoginModule.java
UsernamePasswordLoginModule.java
Log:
Complete switch to org.jboss.logging.Logger
Add support for package version manifest headers
Revision ChangesPath
No revision
No revision
1.2.4.3 +11 -3
jbosssx/src/main/org/jboss/security/auth/spi/DatabaseServerLoginModule.java
Index: DatabaseServerLoginModule.java
===
RCS file:
/cvsroot/jboss/jbosssx/src/main/org/jboss/security/auth/spi/DatabaseServerLoginModule.java,v
retrieving revision 1.2.4.2
retrieving revision 1.2.4.3
diff -u -r1.2.4.2 -r1.2.4.3
--- DatabaseServerLoginModule.java2001/10/19 23:50:08 1.2.4.2
+++ DatabaseServerLoginModule.java2001/11/28 06:10:45 1.2.4.3
@@ -43,7 +43,7 @@
@author a href=[EMAIL PROTECTED]Oleg Nitz/a
@author [EMAIL PROTECTED]
- @version $Revision: 1.2.4.2 $
+ @version $Revision: 1.2.4.3 $
*/
public class DatabaseServerLoginModule extends UsernamePasswordLoginModule
{
@@ -157,8 +157,16 @@
ps.setString(1, username);
ResultSet rs = ps.executeQuery();
if( rs.next() == false )
-throw new FailedLoginException(No matching username found in Roles);
-
+ {
+if( getUnauthenticatedIdentity() == null )
+ throw new FailedLoginException(No matching username found in
Roles);
+/* We are running with an unauthenticatedIdentity so create an
+ empty Roles set and return.
+*/
+Group[] roleSets = { new SimpleGroup(Roles) };
+return roleSets;
+ }
+
do
{
String name = rs.getString(1);
1.3.4.4 +8 -1
jbosssx/src/main/org/jboss/security/auth/spi/UsernamePasswordLoginModule.java
Index: UsernamePasswordLoginModule.java
===
RCS file:
/cvsroot/jboss/jbosssx/src/main/org/jboss/security/auth/spi/UsernamePasswordLoginModule.java,v
retrieving revision 1.3.4.3
retrieving revision 1.3.4.4
diff -u -r1.3.4.3 -r1.3.4.4
--- UsernamePasswordLoginModule.java 2001/10/19 23:50:08 1.3.4.3
+++ UsernamePasswordLoginModule.java 2001/11/28 06:10:45 1.3.4.4
@@ -38,7 +38,7 @@
@see #getUsersRoles()
@author [EMAIL PROTECTED]
- @version $Revision: 1.3.4.3 $
+ @version $Revision: 1.3.4.4 $
*/
public abstract class UsernamePasswordLoginModule extends AbstractServerLoginModule
{
@@ -61,7 +61,10 @@
// Check for unauthenticatedIdentity option.
String name = (String) options.get(unauthenticatedIdentity);
if( name != null )
+ {
unauthenticatedIdentity = new SimplePrincipal(name);
+ super.log.trace(Saw unauthenticatedIdentity=+name);
+ }
}
/**
@@ -95,7 +98,11 @@
String username = info[0];
String password = info[1];
if( username == null password == null )
+ {
identity = unauthenticatedIdentity;
+ super.log.trace(Authenticating as unauthenticatedIdentity=+identity);
+ }
+
if( identity == null )
{
identity = new SimplePrincipal(username);
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jbosspool/src/build build.xml
User: starksm
Date: 01/11/27 22:11:08
Modified:src/build Tag: Branch_2_4 build.xml
Log:
Add support for package version manifest headers
Revision ChangesPath
No revision
No revision
1.2.2.5 +18 -1 jbosspool/src/build/Attic/build.xml
Index: build.xml
===
RCS file: /cvsroot/jboss/jbosspool/src/build/Attic/build.xml,v
retrieving revision 1.2.2.4
retrieving revision 1.2.2.5
diff -u -r1.2.2.4 -r1.2.2.5
--- build.xml 2001/10/21 11:01:27 1.2.2.4
+++ build.xml 2001/11/28 06:11:08 1.2.2.5
@@ -55,6 +55,18 @@
available property=jdk1.3+ classname=java.lang.StrictMath /
/target
+ target name=create-manifest
+echo file=${build.dir}/version.mf
+ append=trueSpecification-Title: ${Name}-${version}
+Specification-Version: ${version}
+Specification-Vendor: JBoss Group, LLC
+Implementation-Title: ${Name}-${release} CVSTag=${release-tag}
+Implementation-Version: ${release}.${build.time}
+Implementation-Vendor: JBoss Group, LLC
+/echo
+fixcrlf srcdir=${build.dir} includes=version.mf eol=crlf /
+ /target
+
!-- === --
!-- Prepares the build directory--
!-- === --
@@ -82,8 +94,10 @@
!-- === --
target name=jar depends=compile
mkdir dir=${external.dir}/
+antcall target=create-manifest /
jar jarfile=${external.dir}/${name}.jar
basedir=${build.classes.dir}
+ manifest=${build.dir}/version.mf
includes=**
/
@@ -93,7 +107,9 @@
copy todir=${build.rar.dir}
fileset dir=${src.resources}/jdbc-rar/
/copy
-jar jarfile=${build.rar.dir}/ra-libs.jar
+jar jarfile=${build.rar.dir}/ra-libs.jar
+ manifest=${build.dir}/version.mf
+
fileset dir=${build.classes.dir}
include name=org/jboss/pool/*.class/
include name=org.jboss/pool/connector/*.class/
@@ -104,6 +120,7 @@
/jar
jar jarfile=${external.dir}/${name}-jdbc.rar
basedir=${build.rar.dir}
+ manifest=${build.dir}/version.mf
includes=**
/
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jbosscx/src/build build.xml
User: starksm
Date: 01/11/27 22:11:24
Modified:src/build Tag: Branch_2_4 build.xml
Log:
Add support for package version manifest headers
Revision ChangesPath
No revision
No revision
1.4.2.6 +14 -0 jbosscx/src/build/Attic/build.xml
Index: build.xml
===
RCS file: /cvsroot/jboss/jbosscx/src/build/Attic/build.xml,v
retrieving revision 1.4.2.5
retrieving revision 1.4.2.6
diff -u -r1.4.2.5 -r1.4.2.6
--- build.xml 2001/11/20 09:23:18 1.4.2.5
+++ build.xml 2001/11/28 06:11:24 1.4.2.6
@@ -61,6 +61,18 @@
mkdir dir=${external.dir}/
/target
+ target name=create-manifest
+echo file=${build.dir}/version.mf
+ append=trueSpecification-Title: ${Name}-${version}
+Specification-Version: ${version}
+Specification-Vendor: JBoss Group, LLC
+Implementation-Title: ${Name}-${release} CVSTag=${release-tag}
+Implementation-Version: ${release}.${build.time}
+Implementation-Vendor: JBoss Group, LLC
+/echo
+fixcrlf srcdir=${build.dir} includes=version.mf eol=crlf /
+ /target
+
!-- === --
!-- Compiles the source code--
!-- === --
@@ -80,8 +92,10 @@
!-- Creates the jar archives--
!-- === --
target name=jar depends=compile
+antcall target=create-manifest /
jar jarfile=${external.dir}/jbosscx.jar
basedir=${build.classes.dir}
+ manifest=${build.dir}/version.mf
includes=org/jboss/resource/**
/
/target
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jboss-j2ee/src/build build.xml
User: starksm
Date: 01/11/27 22:14:18
Modified:src/build Tag: Branch_2_4 build.xml
Log:
Add support for package version manifest headers
Revision ChangesPath
No revision
No revision
1.8.2.2 +16 -2 jboss-j2ee/src/build/Attic/build.xml
Index: build.xml
===
RCS file: /cvsroot/jboss/jboss-j2ee/src/build/Attic/build.xml,v
retrieving revision 1.8.2.1
retrieving revision 1.8.2.2
diff -u -r1.8.2.1 -r1.8.2.2
--- build.xml 2001/09/10 16:36:31 1.8.2.1
+++ build.xml 2001/11/28 06:14:18 1.8.2.2
@@ -11,7 +11,7 @@
project name=JBoss-j2ee default=jar basedir=../..
target name=init
-property name=Name value=JBoss-j2ee/
+property name=Name value=JBossJ2EE/
property name=name value=jboss-j2ee/
property name=version value=1.0/
@@ -51,6 +51,18 @@
available property=jdk1.3+ classname=java.lang.StrictMath /
/target
+ target name=create-manifest
+echo file=${build.dir}/version.mf
+ append=trueSpecification-Title: ${Name}-${version}
+Specification-Version: ${version}
+Specification-Vendor: JBoss Group, LLC
+Implementation-Title: ${Name}-${release} CVSTag=${release-tag}
+Implementation-Version: ${release}.${build.time}
+Implementation-Vendor: JBoss Group, LLC
+/echo
+fixcrlf srcdir=${build.dir} includes=version.mf eol=crlf /
+ /target
+
!-- === --
!-- Prepares the build directory--
!-- === --
@@ -78,16 +90,18 @@
!-- === --
target name=jar depends=compile
mkdir dir=${external.dir}/
-
+antcall target=create-manifest /
!-- Make jdbc_ext.jar file --
jar jarfile=${external.dir}/jboss-jdbc_ext.jar
basedir=${build.classes.dir}
+ manifest=${build.dir}/version.mf
includes=${jdbc_ext-packages.expr}
/
!-- Make j2ee.jar with everything but the jdbc 2.0 std extensions --
jar jarfile=${external.dir}/jboss-j2ee.jar
basedir=${build.classes.dir}
+ manifest=${build.dir}/version.mf
includes=${j2ee-packages.expr}
/
/target
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jbossmq/src/build build.xml
User: starksm
Date: 01/11/27 22:15:27
Modified:src/build Tag: Branch_2_4 build.xml
Log:
Complete switch to org.jboss.logging.Logger and use trace to reduce default
logging
Add support for package version manifest headers
Revision ChangesPath
No revision
No revision
1.8.2.3 +15 -0 jbossmq/src/build/Attic/build.xml
Index: build.xml
===
RCS file: /cvsroot/jboss/jbossmq/src/build/Attic/build.xml,v
retrieving revision 1.8.2.2
retrieving revision 1.8.2.3
diff -u -r1.8.2.2 -r1.8.2.3
--- build.xml 2001/09/08 05:41:33 1.8.2.2
+++ build.xml 2001/11/28 06:15:27 1.8.2.3
@@ -67,6 +67,18 @@
mkdir dir=${build.dir}/
/target
+ target name=create-manifest
+echo file=${build.dir}/version.mf
+ append=trueSpecification-Title: ${Name}-${version}
+Specification-Version: ${version}
+Specification-Vendor: JBoss Group, LLC
+Implementation-Title: ${Name}-${release} CVSTag=${release-tag}
+Implementation-Version: ${release}.${build.time}
+Implementation-Vendor: JBoss Group, LLC
+/echo
+fixcrlf srcdir=${build.dir} includes=version.mf eol=crlf /
+ /target
+
!-- === --
!-- Compiles the source code--
!-- === --
@@ -104,6 +116,7 @@
!-- === --
target name=jar depends=compile
+antcall target=create-manifest /
copy todir=${build.classes.dir}
fileset dir=${src.resources}/
/copy
@@ -111,11 +124,13 @@
mkdir dir=${build.lib.dir}/ext/
jar jarfile=${build.lib.dir}/ext/jbossmq.jar
basedir=${build.classes.dir}
+ manifest=${build.dir}/version.mf
includes=org/**/
mkdir dir=${build.dir}/client/
jar jarfile=${build.dir}/client/jbossmq-client.jar
basedir=${build.classes.dir}
+ manifest=${build.dir}/version.mf
includes=log4j.properties,
org/jboss/mq/*
org/jboss/mq/referenceable/**
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jbossmq/src/main/org/jboss/mq/cluster/jms ClusterTopicConnectionFactory.java
User: starksm
Date: 01/11/27 22:15:31
Modified:src/main/org/jboss/mq/cluster/jms Tag: Branch_2_4
ClusterTopicConnectionFactory.java
Log:
Complete switch to org.jboss.logging.Logger and use trace to reduce default
logging
Add support for package version manifest headers
Revision ChangesPath
No revision
No revision
1.2.2.2 +1 -3
jbossmq/src/main/org/jboss/mq/cluster/jms/ClusterTopicConnectionFactory.java
Index: ClusterTopicConnectionFactory.java
===
RCS file:
/cvsroot/jboss/jbossmq/src/main/org/jboss/mq/cluster/jms/ClusterTopicConnectionFactory.java,v
retrieving revision 1.2.2.1
retrieving revision 1.2.2.2
diff -u -r1.2.2.1 -r1.2.2.2
--- ClusterTopicConnectionFactory.java2001/08/23 03:57:09 1.2.2.1
+++ ClusterTopicConnectionFactory.java2001/11/28 06:15:30 1.2.2.2
@@ -20,13 +20,11 @@
*
* @author Hiram Chirino ([EMAIL PROTECTED])
* @createdAugust 16, 2001
- * @version$Revision: 1.2.2.1 $
+ * @version$Revision: 1.2.2.2 $
*/
public class ClusterTopicConnectionFactory implements java.io.Serializable,
javax.jms.TopicConnectionFactory {
private XElement serverXElement;
-
- static org.apache.log4j.Category cat = org.apache.log4j.Category.getInstance(
ClusterTopicConnection.class );
public ClusterTopicConnectionFactory()
throws Exception {
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jbossmq/src/main/org/jboss/mq/referenceable SpyConnectionFactoryObjectFactory.java SpyDestinationObjectFactory.java
User: starksm
Date: 01/11/27 22:15:32
Modified:src/main/org/jboss/mq/referenceable Tag: Branch_2_4
SpyConnectionFactoryObjectFactory.java
SpyDestinationObjectFactory.java
Log:
Complete switch to org.jboss.logging.Logger and use trace to reduce default
logging
Add support for package version manifest headers
Revision ChangesPath
No revision
No revision
1.2.2.2 +24 -18
jbossmq/src/main/org/jboss/mq/referenceable/SpyConnectionFactoryObjectFactory.java
Index: SpyConnectionFactoryObjectFactory.java
===
RCS file:
/cvsroot/jboss/jbossmq/src/main/org/jboss/mq/referenceable/SpyConnectionFactoryObjectFactory.java,v
retrieving revision 1.2.2.1
retrieving revision 1.2.2.2
diff -u -r1.2.2.1 -r1.2.2.2
--- SpyConnectionFactoryObjectFactory.java2001/08/23 03:57:12 1.2.2.1
+++ SpyConnectionFactoryObjectFactory.java2001/11/28 06:15:31 1.2.2.2
@@ -8,6 +8,7 @@
import javax.naming.spi.ObjectFactory;
+import org.jboss.logging.Logger;
import org.jboss.mq.GenericConnectionFactory;
/**
@@ -17,13 +18,12 @@
*
* @author Hiram Chirino ([EMAIL PROTECTED])
* @createdAugust 16, 2001
- * @version$Revision: 1.2.2.1 $
+ * @version$Revision: 1.2.2.2 $
*/
-public class SpyConnectionFactoryObjectFactory implements
javax.naming.spi.ObjectFactory {
-
- static org.apache.log4j.Category cat = org.apache.log4j.Category.getInstance(
SpyConnectionFactoryObjectFactory.class );
-
-
+public class SpyConnectionFactoryObjectFactory implements
javax.naming.spi.ObjectFactory
+{
+ private static Logger log = Logger.getLogger(
SpyConnectionFactoryObjectFactory.class );
+
/**
* getObjectInstance method.
*
@@ -34,23 +34,29 @@
* @return The ObjectInstance value
* @exception java.lang.Exception Description of Exception
*/
- public java.lang.Object getObjectInstance( java.lang.Object reference,
javax.naming.Name name, javax.naming.Context contex, java.util.Hashtable properties )
- throws java.lang.Exception {
-
- cat.debug( SpyConnectionFactoryObjectFactory-getObjectInstance() );
- try {
-
+ public java.lang.Object getObjectInstance(Object reference, javax.naming.Name
name, javax.naming.Context contex, java.util.Hashtable properties )
+ throws Exception
+ {
+ if( log.isTraceEnabled() )
+ log.trace( SpyConnectionFactoryObjectFactory-getObjectInstance() );
+ try
+ {
javax.naming.Reference ref = ( javax.naming.Reference )reference;
GenericConnectionFactory dcf = ( GenericConnectionFactory )
- ObjectRefAddr.extractObjectRefFrom( ref, DCF );
-
- if ( ref.getClassName().equals( org.jboss.mq.SpyConnectionFactory ) ) {
+ ObjectRefAddr.extractObjectRefFrom( ref, DCF );
+
+ if ( ref.getClassName().equals( org.jboss.mq.SpyConnectionFactory ) )
+ {
return new org.jboss.mq.SpyConnectionFactory( dcf );
- } else if ( ref.getClassName().equals(
org.jboss.mq.SpyXAConnectionFactory ) ) {
+ }
+ else if ( ref.getClassName().equals( org.jboss.mq.SpyXAConnectionFactory
) )
+ {
return new org.jboss.mq.SpyXAConnectionFactory( dcf );
}
- } catch ( Throwable ignore ) {
- ignore.printStackTrace();
+ }
+ catch ( Throwable ignore )
+ {
+ log.debug(Unexpected error, ignore);
// This method should not throw an exception since
// It would prevent another ObjectFactory from attempting
// to create an instance of the object.
1.2.2.2 +33 -20
jbossmq/src/main/org/jboss/mq/referenceable/SpyDestinationObjectFactory.java
Index: SpyDestinationObjectFactory.java
===
RCS file:
/cvsroot/jboss/jbossmq/src/main/org/jboss/mq/referenceable/SpyDestinationObjectFactory.java,v
retrieving revision 1.2.2.1
retrieving revision 1.2.2.2
diff -u -r1.2.2.1 -r1.2.2.2
--- SpyDestinationObjectFactory.java 2001/08/23 03:57:12 1.2.2.1
+++ SpyDestinationObjectFactory.java 2001/11/28 06:15:31 1.2.2.2
@@ -8,25 +8,29 @@
import javax.naming.spi.ObjectFactory;
+import org.jboss.logging.Logger;
+
/**
* This class is used to create instances of of: SpyTopic SpyQueue classes from
* a javax.naming.Reference instance.
*
* @author Hiram Chirino ([EMAIL PROTECTED])
* @createdAugust 16, 2001
- * @version$Revision: 1.2.2.1 $
+ * @version$Revision: 1.2.2.2 $
*/
-public class SpyDestinationObjectFactory implements
[JBoss-dev] CVS update: jnp/src/build build.xml
User: starksm
Date: 01/11/27 22:16:35
Modified:src/build Tag: Branch_2_4 build.xml
Log:
Add support for package version manifest headers
Revision ChangesPath
No revision
No revision
1.5.2.2 +22 -4 jnp/src/build/Attic/build.xml
Index: build.xml
===
RCS file: /cvsroot/jboss/jnp/src/build/Attic/build.xml,v
retrieving revision 1.5.2.1
retrieving revision 1.5.2.2
diff -u -r1.5.2.1 -r1.5.2.2
--- build.xml 2001/09/07 23:17:44 1.5.2.1
+++ build.xml 2001/11/28 06:16:35 1.5.2.2
@@ -5,7 +5,7 @@
!-- === --
project name=JNP default=main basedir=../..
- property name=Name value=JNP/
+ property name=Name value=JBossNS/
property name=name value=jnp/
property name=version value=1.2/
property name=bin.dir value=${basedir}/bin/
@@ -43,6 +43,18 @@
target name=prepare
mkdir dir=${build.dir}/
/target
+ target name=create-manifest
+copy file=${etc.dir}/${manifest.file} todir=${build.dir} overwrite=true
/
+echo file=${build.dir}/${manifest.file}
+ append=trueSpecification-Title: ${Name}-${version}
+Specification-Version: ${version}
+Specification-Vendor: JBoss Group, LLC
+Implementation-Title: ${Name}-${release} CVSTag=${release-tag}
+Implementation-Version: ${release}.${build.time}
+Implementation-Vendor: JBoss Group, LLC
+/echo
+fixcrlf srcdir=${build.dir} includes=${manifest.file} eol=crlf /
+ /target
!-- === --
!-- Compiles the source code--
@@ -72,9 +84,12 @@
/copy
mkdir dir=${build.bin.dir}/
+antcall target=create-manifest
+ param name=manifest.file value=server.mf/
+/antcall
jar jarfile=${build.bin.dir}/jnpserver.jar
basedir=${build.classes.dir}
- manifest=${etc.dir}/server.mf
+ manifest=${build.dir}/server.mf
includes=org/jnp/server/**,org/jnp/interfaces/**
/
@@ -85,13 +100,16 @@
/
mkdir dir=${build.lib.dir}/ext/
+antcall target=create-manifest
+ param name=manifest.file value=jnp.mf/
+/antcall
jar jarfile=${build.lib.dir}/ext/jnp-client.jar
basedir=${build.classes.dir}
- manifest=${etc.dir}/jnp.mf
+ manifest=${build.dir}/jnp.mf
includes=org/jnp/interfaces/**,org/jnp/server/*Stub.class
/
/target
-
+
!-- === --
!-- Creates the binary structure--
!-- === --
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jbossmq/src/main/org/jboss/mq/il/oil OILClientIL.java OILClientILService.java OILServerILService.java
User: starksm
Date: 01/11/27 22:15:31
Modified:src/main/org/jboss/mq/il/oil Tag: Branch_2_4
OILClientIL.java OILClientILService.java
OILServerILService.java
Log:
Complete switch to org.jboss.logging.Logger and use trace to reduce default
logging
Add support for package version manifest headers
Revision ChangesPath
No revision
No revision
1.2.2.2 +56 -34jbossmq/src/main/org/jboss/mq/il/oil/OILClientIL.java
Index: OILClientIL.java
===
RCS file: /cvsroot/jboss/jbossmq/src/main/org/jboss/mq/il/oil/OILClientIL.java,v
retrieving revision 1.2.2.1
retrieving revision 1.2.2.2
diff -u -r1.2.2.1 -r1.2.2.2
--- OILClientIL.java 2001/08/23 03:57:10 1.2.2.1
+++ OILClientIL.java 2001/11/28 06:15:31 1.2.2.2
@@ -17,9 +17,10 @@
import javax.jms.Destination;
import javax.jms.JMSException;
+
+import org.jboss.logging.Logger;
import org.jboss.mq.Connection;
import org.jboss.mq.ReceiveRequest;
-
import org.jboss.mq.SpyDestination;
import org.jboss.mq.il.ClientIL;
@@ -29,94 +30,115 @@
* @author Norbert Lataille ([EMAIL PROTECTED])
* @author Hiram Chirino ([EMAIL PROTECTED])
* @createdAugust 16, 2001
- * @version$Revision: 1.2.2.1 $
+ * @version$Revision: 1.2.2.2 $
*/
-public class OILClientIL implements ClientIL, java.io.Serializable {
-
+public class OILClientIL implements ClientIL, java.io.Serializable
+{
+ private static Logger log = Logger.getLogger( OILClientIL.class );
private InetAddress addr;
private transient ObjectInputStream in;
private transient ObjectOutputStream out;
private int port;
private transient Socket socket;
- static org.apache.log4j.Category cat = org.apache.log4j.Category.getInstance(
OILClientIL.class );
final static int m_close = 2;
final static int m_deleteTemporaryDestination = 1;
final static int m_receive = 3;
-
- OILClientIL( InetAddress addr, int port ) {
+
+ OILClientIL( InetAddress addr, int port )
+ {
this.addr = addr;
this.port = port;
}
-
+
public void close()
- throws Exception {
+ throws Exception
+ {
checkSocket();
out.writeByte( m_close );
waitAnswer();
}
-
+
public synchronized void deleteTemporaryDestination( SpyDestination dest )
- throws Exception {
+ throws Exception
+ {
checkSocket();
out.writeByte( m_deleteTemporaryDestination );
out.writeObject( dest );
waitAnswer();
}
-
+
public synchronized void receive( ReceiveRequest messages[] )
- throws Exception {
- cat.debug( Checking socket );
+ throws Exception
+ {
+ boolean trace = log.isTraceEnabled();
+ if( trace )
+ log.trace( Checking socket );
checkSocket();
- cat.debug( Writing request );
+ if( trace )
+ log.trace( Writing request );
out.writeByte( m_receive );
out.writeInt( messages.length );
- for ( int i = 0; i messages.length; ++i ) {
+ for ( int i = 0; i messages.length; ++i )
+ {
messages[i].writeExternal( out );
}
- cat.debug( Waiting for awnser );
+ if( trace )
+ log.trace( Waiting for awnser );
waitAnswer();
- cat.debug( Done );
+ if( trace )
+ log.trace( Done );
}
-
+
protected void checkSocket()
- throws Exception {
- if ( socket == null ) {
+ throws Exception
+ {
+ if ( socket == null )
+ {
createConnection();
}
}
-
+
protected void createConnection()
- throws RemoteException {
- try {
- cat.info( ConnectionReceiverOILClient is connecting to: +
addr.getHostAddress() + : + port );
+ throws RemoteException
+ {
+ try
+ {
+ log.debug( ConnectionReceiverOILClient is connecting to: +
addr.getHostAddress() + : + port );
socket = new Socket( addr, port );
out = new ObjectOutputStream( new BufferedOutputStream(
socket.getOutputStream() ) );
out.flush();
in = new ObjectInputStream( new BufferedInputStream(
socket.getInputStream() ) );
- } catch ( Exception e ) {
- cat.debug( e );
+ }
+ catch ( Exception e )
+ {
+ log.debug( e );
throw new RemoteException( Cannot connect to the
ConnectionReceiver/Server );
}
}
-
+
protected void waitAnswer()
- throws Exception {
+ throws Exception
+ {
Exception throwException = null;
- try {
+ try
+
[JBoss-dev] CVS update: jbossmq/src/main/org/jboss/mq/selectors Selector.java
User: starksm
Date: 01/11/27 22:15:32
Modified:src/main/org/jboss/mq/selectors Tag: Branch_2_4
Selector.java
Log:
Complete switch to org.jboss.logging.Logger and use trace to reduce default
logging
Add support for package version manifest headers
Revision ChangesPath
No revision
No revision
1.3.2.2 +84 -49jbossmq/src/main/org/jboss/mq/selectors/Selector.java
Index: Selector.java
===
RCS file: /cvsroot/jboss/jbossmq/src/main/org/jboss/mq/selectors/Selector.java,v
retrieving revision 1.3.2.1
retrieving revision 1.3.2.2
diff -u -r1.3.2.1 -r1.3.2.2
--- Selector.java 2001/08/23 03:57:12 1.3.2.1
+++ Selector.java 2001/11/28 06:15:32 1.3.2.2
@@ -12,6 +12,7 @@
import javax.jms.JMSException;
+import org.jboss.logging.Logger;
import org.jboss.mq.SpyMessage;
/**
@@ -20,111 +21,145 @@
* @author Norbert Lataille ([EMAIL PROTECTED])
* @author Juha Lindfors ([EMAIL PROTECTED])
* @createdAugust 16, 2001
- * @version$Revision: 1.3.2.1 $
+ * @version$Revision: 1.3.2.2 $
*/
-public class Selector {
+public class Selector
+{
+ static Logger log = Logger.getLogger( Selector.class );
+
public HashMap identifiers;
// HashMap of Identifiers
public Objectresult;
-
- static org.apache.log4j.Category cat = org.apache.log4j.Category.getInstance(
Selector.class );
-
+
public Selector( String sel )
- throws JMSException {
+ throws JMSException
+ {
parser bob = new parser();
identifiers = new HashMap();
-
- try {
+
+ try
+ {
result = bob.parse( sel, identifiers );
- } catch ( Exception e ) {
+ } catch ( Exception e )
+ {
InvalidSelectorException exception = new InvalidSelectorException( The
selector is invalid. );
exception.setLinkedException( e );
throw exception;
}
-
+
//Log.notice(result.toString());
}
-
+
public boolean test( SpyMessage mes )
- throws JMSException {
-
- try {
-
+ throws JMSException
+ {
+
+ try
+ {
+
//Set the identifiers values
Iterator i = identifiers.values().iterator();
-
- while ( i.hasNext() ) {
+
+ while ( i.hasNext() )
+ {
Identifier id = ( Identifier )i.next();
-
+
Object find = mes.getObjectProperty( id.name );
-
-if ( find == null ) {
+
+if ( find == null )
+{
find = getHeaderFieldReferences( mes, id.name );
}
-
-if ( find == null ) {
- cat.debug( Warning : missing property + id.name );
+
+if ( find == null )
+{
+ log.debug( Warning : missing property + id.name );
id.value = null;
-} else {
+} else
+{
Class type = find.getClass();
if ( type.equals( Boolean.class ) || type.equals( String.class )
- || type.equals( Double.class ) || type.equals( Float.class )
- || type.equals( Integer.class ) || type.equals( Long.class )
- || type.equals( Short.class ) || type.equals( Byte.class ) ) {
+ || type.equals( Double.class ) || type.equals( Float.class )
+ || type.equals( Integer.class ) || type.equals( Long.class )
+ || type.equals( Short.class ) || type.equals( Byte.class ) )
+ {
id.value = find;
- } else {
+ }
+ else
+ {
throw new Exception( Bad property type ! );
}
//Log.notice(SEL:+id.name+ =+id.value);
}
}
-
+
//Compute the result of this operator
Object res;
-
- if ( result.getClass().equals( Identifier.class ) ) {
+
+ if ( result.getClass().equals( Identifier.class ) )
+ {
res = ( ( Identifier )result ).value;
- } else if ( result.getClass().equals( Operator.class ) ) {
+ } else if ( result.getClass().equals( Operator.class ) )
+ {
res = ( ( Operator )result ).apply();
- } else {
+ } else
+ {
res = result;
}
-
- if ( res == null ) {
+
+ if ( res == null )
+ {
return false;
}
-
[JBoss-dev] CVS update: jboss/src/main/org/jboss Main.java
User: starksm
Date: 01/11/27 22:18:11
Modified:src/main/org/jboss Tag: Branch_2_4 Main.java
Log:
Use a trival subclass of MLet that returns an empty URL[] from getURLs to
force the use of the rmi codebase as the annotated codebase.
Remove the embedded version string in favor of the Package.getSpecificationTitle
value
Revision ChangesPath
No revision
No revision
1.35.2.15 +30 -5 jboss/src/main/org/jboss/Main.java
Index: Main.java
===
RCS file: /cvsroot/jboss/jboss/src/main/org/jboss/Main.java,v
retrieving revision 1.35.2.14
retrieving revision 1.35.2.15
diff -u -r1.35.2.14 -r1.35.2.15
--- Main.java 2001/11/11 08:15:58 1.35.2.14
+++ Main.java 2001/11/28 06:18:11 1.35.2.15
@@ -27,13 +27,12 @@
* @author Rickard Öberg ([EMAIL PROTECTED])
* @author a href=mailto:[EMAIL PROTECTED];Daniel O'Connor/a.
* @author [EMAIL PROTECTED]
- * @version $Revision: 1.35.2.14 $
+ * @version $Revision: 1.35.2.15 $
*/
public class Main
{
// Constants -
- String versionIdentifier = 2.4.4;
// Attributes
// Static
@@ -167,7 +166,8 @@
}
// Create MLet
- MLet mlet = new MLet(urls);
+ MLet mlet = new NullURLsMLet(urls);
+
server.registerMBean(mlet, new ObjectName(server.getDefaultDomain(),
service, MLet));
// Set MLet as classloader for this app
@@ -230,11 +230,36 @@
}
// Done
+ Package mainPkg = Package.getPackage(org.jboss);
long stopTime = System.currentTimeMillis();
long lapsedTime = stopTime - startTime;
long minutes = lapsedTime / 6;
long seconds = (lapsedTime - 6 * minutes) / 1000;
- long milliseconds = lapsedTime - 6 * minutes - 1000 * seconds;
- System.out.println(JBoss +versionIdentifier+ Started in
+minutes+m:+seconds+s.+milliseconds);
+ long milliseconds = lapsedTime - 6 * minutes - 1000 * seconds;
+ String version = mainPkg.getSpecificationTitle();
+ System.out.println(version+ Started in
+minutes+m:+seconds+s.+milliseconds);
+ }
+
+ /**
+*/
+ static class NullURLsMLet extends MLet
+ {
+ URL[] empty = {};
+ public NullURLsMLet()
+ {
+ }
+ public NullURLsMLet(URL[] urls)
+ {
+ super(urls);
+ }
+
+ public URL[] getURLs()
+ {
+ return empty;
+ }
+ public URL[] getLocalURLs()
+ {
+ return super.getURLs();
+ }
}
}
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jboss/src/main/org/jboss/ejb/plugins TxInterceptorCMT.java
User: starksm
Date: 01/11/27 22:19:29
Modified:src/main/org/jboss/ejb/plugins Tag: Branch_2_4
TxInterceptorCMT.java
Log:
Use the trace log level to provide detailed progress
Revision ChangesPath
No revision
No revision
1.10.4.2 +665 -616 jboss/src/main/org/jboss/ejb/plugins/TxInterceptorCMT.java
Index: TxInterceptorCMT.java
===
RCS file: /cvsroot/jboss/jboss/src/main/org/jboss/ejb/plugins/TxInterceptorCMT.java,v
retrieving revision 1.10.4.1
retrieving revision 1.10.4.2
diff -u -r1.10.4.1 -r1.10.4.2
--- TxInterceptorCMT.java 2001/07/08 21:19:28 1.10.4.1
+++ TxInterceptorCMT.java 2001/11/28 06:19:29 1.10.4.2
@@ -1,616 +1,665 @@
-/*
-* JBoss, the OpenSource EJB server
-*
-* Distributable under LGPL license.
-* See terms of license at gnu.org.
-*/
-package org.jboss.ejb.plugins;
-
-import java.lang.reflect.Method;
-import java.rmi.NoSuchObjectException;
-import java.rmi.RemoteException;
-import java.rmi.ServerException;
-import java.util.*;
-
-import javax.transaction.Status;
-import javax.transaction.Transaction;
-import javax.transaction.TransactionManager;
-import javax.transaction.RollbackException;
-import javax.transaction.TransactionRequiredException;
-import javax.transaction.TransactionRolledbackException;
-import javax.transaction.SystemException;
-
-import javax.ejb.EJBException;
-import javax.ejb.NoSuchEntityException;
-
-import org.jboss.ejb.Container;
-import org.jboss.ejb.EnterpriseContext;
-import org.jboss.ejb.MethodInvocation;
-import org.jboss.logging.Logger;
-
-import org.jboss.metadata.MetaData;
-import org.jboss.metadata.BeanMetaData;
-import org.jboss.metadata.MethodMetaData;
-
-/**
-* description
-*
-* @see related
-* @author Rickard Öberg ([EMAIL PROTECTED])
-* @author a href=mailto:[EMAIL PROTECTED];Marc Fleury/a
-* @author a href=mailto:[EMAIL PROTECTED];Sebastien Alborini/a
-* @author a href=mailto:[EMAIL PROTECTED];Anatoly Akkerman/a
-* @version $Revision: 1.10.4.1 $
-*/
-public class TxInterceptorCMT
-extends AbstractInterceptor
-{
-
-// Attributes
-private TransactionManager tm;
-private HashMap methodTx = new HashMap();
-
-protected Container container;
-
-// Static
-
-// Constructors --
-
-// Public
-public void setContainer(Container container)
-{
-this.container = container;
-}
-
-public Container getContainer()
-{
-return container;
-}
-
-// Interceptor implementation --
-public void init()
-throws Exception
-{
-// Store TM reference locally
-tm = (TransactionManager) getContainer().getTransactionManager();
-
-// Find out method-tx-type mappings from meta-info
-// EnterpriseBean eb = getContainer.getMetaData();
-// eb.getBeanContext()
-
-}
-
-public Object invokeHome(MethodInvocation mi)
-throws Exception
-{
-return runWithTransactions(false, mi);
-}
-
-/**
-* This method does invocation interpositioning of tx management
-*
-* @param id
-* @param m
-* @param args
-* @return
-* @exception Exception
-*/
-public Object invoke(MethodInvocation mi) throws Exception {
-return runWithTransactions(true, mi);
-}
-
-private void printMethod(Method m, byte type) {
-String name;
-switch(type) {
-case MetaData.TX_MANDATORY:
-name = TX_MANDATORY;
-break;
-case MetaData.TX_NEVER:
-name = TX_NEVER;
-break;
-case MetaData.TX_NOT_SUPPORTED:
-name = TX_NOT_SUPPORTED;
-break;
-case MetaData.TX_REQUIRED:
-name = TX_REQUIRED;
-break;
-case MetaData.TX_REQUIRES_NEW:
-name = TX_REQUIRES_NEW;
-break;
-case MetaData.TX_SUPPORTS:
-name = TX_SUPPORTS;
-break;
-default:
-name = TX_UNKNOWN;
-}
-//DEBUGLogger.debug(name+ for +m.getName());
-}
-
-private Object invokeNext(boolean remoteInvocation, MethodInvocation mi) throws
Exception {
- try
- {
- if (remoteInvocation) {
- return
