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 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
> 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
> 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.
To recap:
deployment type | Advantages |Disadvantages
-
.sar archive | 1 file | Pain in the ass to configure
| digital signature |
|
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"...
>
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
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,
*
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
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 publi
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 org.jboss.test.jbossmq.test.SecurityUnitT
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]>
Sen
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
- A
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
> 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 ser
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 tha
oblems come from "everything in
> sight?" If you have server-specific jars, you'd need to change 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
>
>
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
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
19 matches
Mail list logo
