I have finally downloaded and tested this patch with SwiftMQ, and it does indeed
fix the problem. Does anyone object if I go forward with this patch? (Note - I
simplified it a bit, and added some (too much?) commenting).
-Larry
I think I may have tracked down the SwiftMQ bug... let me know
Some additional comments:
1) If a hardware load balancer is out of the budget (Cisco local director series
start at about $4000 - not too expensive), then I would recommend looking at
Linux Virtual Server (http://www.linuxvirtualserver.org/). It is basically a
customized Linux kernel to do the
I'm having trouble with the cvs repository. It is reporting a cvs
lock in /cvsroot/jboss/manual/src/metadata. Is there anything I can do to
fix this?
-Larry
It was my patch that changed this. I changed the EARDeployer to only deploy
those applications listed in an application.xml file (I believe that this
was another bug on sourceforge?). The struts.jar should only be included on
the classpath if it is an application in the application.xml file, if
the ear
anyway to change which are deployed, so why not take out the packages you
don't want deployed?
Any other thoughts?
david jencks
On 2002.04.16 17:01:13 -0400 lsanders wrote:
It was my patch that changed this. I changed the EARDeployer to only
deploy
those applications listed
Comments inlined...
I agree that there should be a single definitive user-specified list of
what should be deployed, but I think it belongs in the ant build file that
constructs what gets deployed. To me, it is more sloppy to include stuff
in your package that you don't want deployed than
This is going to cause other problems. What if I have two wars that
uses struts and each have a different version of the same action class
because they are different releases of the same web application. If a
struts.jar is referred to by a war manifest is should be only loaded
by the servlet
Is anybody working on this? Any ideas for the
implementation? I don't think we can rely on Sun for this fix, and several
people have already claimed this to be a show-stopper.
-Larry
Though I've never experienced this, I think this is the problem scenario:
The players:
UnifiedClassLoader A (can load directly class foo)
UnifiedClassLoader B (can load directly class bar)
Thread 1 (context loader is A):
Load new class bar:
- synchronize on UCL A
- Search UCL B
-
That line in MainDeployer refers to a change I put in 2 days ago. I think
you need a clean - or at least you need to recompile the
org.jboss.deployment.DeploymentSorter class.
-Larry
- Original Message -
From: Hunter Hillegas [EMAIL PROTECTED]
To: JBoss Dev [EMAIL PROTECTED]
Sent:
FYI - I was having a similar problem when I compiled with jdk 1.3, but ran
on jdk 1.4 (Windows 2000).
-Larry
JDK 1.4.0 is also crashing for me about here:
[junit] Tests run: 25, Failures: 0, Errors: 1, Time elapsed: 234.215
sec
[junit] TEST
There is a bug in Sun's 1.3 jvm. Inner classes can not access protected
members inherited from the outer class's super class:
A (defines protected field: log)
B extends A
+-- C (Inner class of B)
Trying to access log from C fails. This is why all inner-classes of
MainDeployer called the
This was killing us too. To solve this, we developed two tools:
1) An ant task that invokes jasper's jspc to translate jsps.
2) A wrapper servlet around jasper that will first check for and use a
precompiled jsp if it exists, and if not fall back to the default mode of
translating / compiling at
This has been available since (I think) 3.0 RC2. Take a look at the default
jboss-service.xml file. At the bottom in the Deployment Scanning section,
look for an attribute named URLComparator. The default comparator
(DeploymentSorter) sorts by type in this order: *.sar, *service.xml, *rar,
Is the org.mortbay.jetty.jar file swappable with
the latest cvs builds from mortbay? It seems to work for me, but I was
wondering if there are any known issues.
Thanks
-Larry
OK- I agree. I will modify the existing PrefixDeploymentSorter.java. I
will also make it the default comparator in jboss-system.xml. Should I aply
these changes to Branch_3_0?
-Larry
Yes, that is the only way that makes sence for me at least.
I've submitted my sorter to patches...
Best
To recap:
deployment type | Advantages |Disadvantages
-
.sar archive | 1 file | Pain in the ass to configure
| digital signature |
|
Is there a particular issue that you are trying to resolve, or are you
just a compulsive neophile :-) ?
Well, that and the fact that I am having problems with
request.getContextPath() that I'm hoping the latest Jetty fixes. It now
appears that it did not - oh well.
digi sigs will not work when you need to change the config. it is only
useful
if you have static config and want to ensure that the contents do not
change.
the second you need to chagne the config, you must resign...
Right. The point is, it can be distributed with a signature, as long as
19 matches
Mail list logo
