in special cases wadi clustering thread fails to load web application classes
-
Key: GERONIMO-5256
URL: https://issues.apache.org/jira/browse/GERONIMO-5256
Project: Geronimo
test application and logs attached
in special cases wadi clustering thread fails to load web application classes
-
Key: GERONIMO-5256
URL: https://issues.apache.org/jira/browse
the application cviewer.war after undeploy it when configure the
WADI clustering ,the there is an error:
org.apache.geronimo.common.DeploymentException: Unable to deploy
cviewer-2.1.1.2.war: Module com.ibm.wasce.samples/cviewer/2.1.1.2/car already
exists in the server. Try to undeploy
to address this issue.
There is an error after undeploy the application and deploy the application
again when configure WADI clustering,
--
Key: GERONIMO-4844
.
There is an error after undeploy the application and deploy the application
again when configure WADI clustering,
--
Key: GERONIMO-4844
URL: https
more
There is an error after undeploy the application and deploy the application
again when configure WADI clustering,
--
Key: GERONIMO-4844
URL
after undeploy the application and deploy the application
again when configure WADI clustering,
--
Key: GERONIMO-4844
URL: https://issues.apache.org/jira
ConfigurationUtil and adjust the expections a little bit to
get rmock to pass.
Nice work!
2.1 rev 903520
2.2 rev 903521
3.0 rev 903525
There is an error after undeploy the application and deploy the application
again when configure WADI clustering
comments over the patches?
There is an error after undeploy the application and deploy the application
again when configure WADI clustering,
--
Key: GERONIMO-4844
[
https://issues.apache.org/jira/browse/GERONIMO-5000?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ashish Jain closed GERONIMO-5000.
-
Resolution: Fixed
Doucmentation Update: WADI Clustering document updates after fix
Doucmentation Update: WADI Clustering document updates after fix to
GERONIMO-4900
-
Key: GERONIMO-5000
URL: https://issues.apache.org/jira/browse/GERONIMO-5000
Project
/confluence/display/GMOxDOC21/Farming
Doucmentation Update: WADI Clustering document updates after fix to
GERONIMO-4900
-
Key: GERONIMO-5000
URL: https://issues.apache.org/jira
and deploy the application
again when configure WADI clustering,
--
Key: GERONIMO-4844
URL: https://issues.apache.org/jira/browse/GERONIMO-4844
thanks.
There is an error after undeploy the application and deploy the application
again when configure WADI clustering,
--
Key: GERONIMO-4844
undeploy the application and deploy the application
again when configure WADI clustering,
--
Key: GERONIMO-4844
URL: https://issues.apache.org/jira
a patch for this issue.
There is an error after undeploy the application and deploy the application
again when configure WADI clustering,
--
Key: GERONIMO-4844
the application
again when configure WADI clustering,
--
Key: GERONIMO-4844
URL: https://issues.apache.org/jira/browse/GERONIMO-4844
Project
the application
again when configure WADI clustering,
--
Key: GERONIMO-4844
URL: https://issues.apache.org/jira/browse/GERONIMO-4844
Project
sometime later this week. Thanks!
form based security for the web application does not work with Jetty WADI
clustering.
-
Key: GERONIMO-4846
URL: https://issues.apache.org/jira
and I remembered there was no different
between jetty6 and jetty7. I am very appreciate that you can test it again.
form based security for the web application does not work with Jetty WADI
clustering
I
think. I can do another test if you like.
form based security for the web application does not work with Jetty WADI
clustering.
-
Key: GERONIMO-4846
URL: https
Jetty6 and Jetty7, and they have the same behavior.
I plan to close this jira, any thoughts?
-Rex
form based security for the web application does not work with Jetty WADI
clustering.
-
Key
[
https://issues.apache.org/jira/browse/GERONIMO-4850?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Shawn Jiang reassigned GERONIMO-4850:
-
Assignee: Shawn Jiang
WADI clustering: the application no node B will not start up
configuration is set to load=false. To fix it is not hard, but
I'm wondering if it's working as design case.
WADI clustering: the application no node B will not start up when start up
the node B
://www.nabble.com/Some-features-of-WADI-cluster-in-G22-td25287296s134.html#a25288801
WADI clustering: the application no node B will not start up when start up
the node B.
---
Key: GERONIMO-4850
[
https://issues.apache.org/jira/browse/GERONIMO-4777?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Shawn Jiang closed GERONIMO-4777.
-
Closing it.
WADI clustering does not work with Jetty7
based security for the web application does not work with Jetty WADI
clustering.
-
Key: GERONIMO-4846
URL: https://issues.apache.org/jira/browse/GERONIMO-4846
Project
WADI clustering: the application no node B will not start up when start up the
node B.
---
Key: GERONIMO-4850
URL: https://issues.apache.org/jira/browse/GERONIMO-4850
. ThanksTrygve Hardersen for the patch !
WADI clustering does not work with Jetty7
-
Key: GERONIMO-4777
URL: https://issues.apache.org/jira/browse/GERONIMO-4777
Project: Geronimo
Issue Type: Bug
the application
again when configure WADI clustering,
--
Key: GERONIMO-4844
URL: https://issues.apache.org/jira/browse/GERONIMO-4844
/jira/browse/GERONIMO-4846
to track the remaining security problem.
WADI clustering does not work with Jetty7
-
Key: GERONIMO-4777
URL: https://issues.apache.org/jira/browse/GERONIMO-4777
Project: Geronimo
form based security for the web application does not work with Jetty WADI
clustering.
-
Key: GERONIMO-4846
URL: https://issues.apache.org/jira/browse/GERONIMO-4846
attaching the patch for the WADIJettyClusteringBuilder
(WADIJettyClusteringBuilder.patch) and a sample project JGS (jgs.tar.gz) that
demonstrates the security problems I'm experiencing. The
web-formlogin-clustering-plugin of the JGS project uses form based security and
WADI clustering
with Jetty WADI
clustering.
-
Key: GERONIMO-4846
URL: https://issues.apache.org/jira/browse/GERONIMO-4846
Project: Geronimo
Issue Type: Bug
Security
There is an error after undeploy the application and deploy the application
again when configure WADI clustering,
--
Key: GERONIMO-4844
URL: https
[
https://issues.apache.org/jira/browse/GERONIMO-4777?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Shawn Jiang reassigned GERONIMO-4777:
-
Assignee: Shawn Jiang
WADI clustering does not work with Jetty7
WADI clustering does not work with Jetty7
-
Key: GERONIMO-4777
URL: https://issues.apache.org/jira/browse/GERONIMO-4777
Project: Geronimo
Issue Type: Bug
Security Level: public (Regular issues
WADI clustering does not work with Jetty7
-
Key: GERONIMO-4777
URL: https://issues.apache.org/jira/browse/GERONIMO-4777
Project: Geronimo
Issue Type: Bug
Security Level: public(Regular issues
[
https://issues.apache.org/jira/browse/GERONIMO-4777?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Trygve Hardersen updated GERONIMO-4777:
---
Attachment: jgs.tar.gz
The JGS sample project
WADI clustering does not work
wrote:
Hello,
I am back from holiday; A quick scan of the mailing lists tells me
that the upgrade to WADI 2.0 is causing classloader clashes.
As identified by Jason W. and Kevan, a Tribes class is loaded by
two distinct classloaders (tomcat6 and wadi-clustering
configuration classloaders
Hello,
I am back from holiday; A quick scan of the mailing lists tells me
that the upgrade to WADI 2.0 is causing classloader clashes.
As identified by Jason W. and Kevan, a Tribes class is loaded by two
distinct classloaders (tomcat6 and wadi-clustering configuration
classloaders
and wadi-clustering configuration
classloaders), which causes CCE upon message delivery. After having
investigated this problem, it seems to me that the best way to fix
it is to split the tomcat6 dependencies into two configurations:
tomcat6 and tomcat6-tribes. tomcat6-tribes imports
Gianny Damour wrote:
Hello,
I am back from holiday; A quick scan of the mailing lists tells me that
the upgrade to WADI 2.0 is causing classloader clashes.
As identified by Jason W. and Kevan, a Tribes class is loaded by two
distinct classloaders (tomcat6 and wadi-clustering configuration
Upon starting the org.apache.geronimo.configs/wadi-clustering/2.0.2/car in
Geronimo Jetty 2.0.2 distribution, I got an NCDFE error. Has anyone hit
this error? Stack trace is given below.
12:13:38,750 ERROR [GBeanInstanceState] Error while starting; GBean is now
in the FAILED state: bstractName
Hello,
Nope. It seems wadi-clustering dependencies have been cleaned up too
much for the 2.0.2 distribution. I do not think there is an easy work-
around, except the issue or a 2.0.3 wadi-clustering configuration
with the right runtime dependencies.
Thanks,
Gianny
On 18/03/2008, at 9:42
[EMAIL PROTECTED] wrote:
On Feb 3, 2008, at 5:34 PM, Gianny Damour wrote:
Hi Kevan,
concurrent is a WADI runtime dependency. The server starts fine
because wadi-clustering is not started by default and, assuming this
was the case, this dependency is only used when an invocation is
contextualized
On Feb 5, 2008, at 8:44 AM, Gianny Damour wrote:
Hi,
Indeed, WADI has a lot of dependencies on concurrent. As a matter of
fact, concurrent was a very handy toolkit to build the asynchronous
message processing/passing components and distributed locks of WADI
on top of the JDK 1.4.
I
On Feb 3, 2008 10:52 PM, Kevan Miller [EMAIL PROTECTED] wrote:
On Feb 3, 2008, at 5:34 PM, Gianny Damour wrote:
Hi Kevan,
concurrent is a WADI runtime dependency. The server starts fine
because wadi-clustering is not started by default and, assuming this
was the case, this dependency is only
Hi Kevan,
concurrent is a WADI runtime dependency. The server starts fine
because wadi-clustering is not started by default and, assuming this
was the case, this dependency is only used when an invocation is
contextualized.
So, could you please rollback this change?
Thanks,
Gianny
On Feb 3, 2008, at 5:34 PM, Gianny Damour wrote:
Hi Kevan,
concurrent is a WADI runtime dependency. The server starts fine
because wadi-clustering is not started by default and, assuming this
was the case, this dependency is only used when an invocation is
contextualized.
So, could
On Feb 3, 2008, at 5:34 PM, Gianny Damour wrote:
Hi Kevan,
concurrent is a WADI runtime dependency. The server starts fine
because wadi-clustering is not started by default and, assuming this
was the case, this dependency is only used when an invocation is
contextualized.
So, could
:
geronimo/server/trunk/configs/wadi-clustering/pom.xml
geronimo/server/trunk/configs/wadi-clustering/src/plan/plan.xml
geronimo/server/trunk/modules/geronimo-clustering-wadi/src/main/
java/org/apache/geronimo/clustering/wadi/TribesDispatcherHolder.java
geronimo/server/trunk/pom.xml
, 2007, at 3:50 AM, [EMAIL PROTECTED] wrote:
Author: gdamour
Date: Sun Jun 3 03:50:37 2007
New Revision: 543877
URL: http://svn.apache.org/viewvc?view=revrev=543877
Log:
move to WADI 2.0-M4
Modified:
geronimo/server/trunk/configs/wadi-clustering/pom.xml
geronimo/server/trunk/configs/wadi
WADI Clustering is missing dependency to org.apache.tomcat.juli
---
Key: GERONIMO-3112
URL: https://issues.apache.org/jira/browse/GERONIMO-3112
Project: Geronimo
Issue Type: Bug
/server/trunk/configs/wadi-clustering
WADI Clustering is missing dependency to org.apache.tomcat.juli
---
Key: GERONIMO-3112
URL: https://issues.apache.org/jira/browse/GERONIMO-3112
Project
[
https://issues.apache.org/jira/browse/GERONIMO-3112?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gianny Damour reassigned GERONIMO-3112:
---
Assignee: Gianny Damour
WADI Clustering is missing dependency
Hi,
Sorry for this problem; I was not aware of it. This has now been fixed.
Thanks,
Gianny
On 07/11/2006, at 8:42 AM, Dain Sundstrom wrote:
Can who ever maintains this please add an exclude to geronimo, or
even better mark it as optional in wadi?
-dain
On Nov 6, 2006, at 5:56 AM, Jeff
I was building from trunk this morning and noticed that WADI is pulling
down LGPL jars into the G build:
[INFO]
[INFO] Building Geronimo Clustering WADI
[INFO]task-segment: [install]
[INFO]
Can who ever maintains this please add an exclude to geronimo, or
even better mark it as optional in wadi?
-dain
On Nov 6, 2006, at 5:56 AM, Jeff Genender wrote:
I was building from trunk this morning and noticed that WADI is
pulling
down LGPL jars into the G build:
[INFO]
I have a successful build at revision 454340. Try running mvn
-U . This is what I ran when I ended up hitting compilation
problems most recently.
VamsiOn 10/9/06, Lasantha Ranaweera [EMAIL PROTECTED] wrote:
Hi All,It looks there is an error in Geronimo Maven build in revision 454313.It gives
Rajith Attapattu wrote:
However if we use 100% session affinity then the chance
Sorry it should be asume not use. :)
Don't think of it as a battle, it's a disscussion for me (and perhaps
for you) to understand both sides of the coin. Unless u think my
questions are stupid :)
Good - I'm
Rajith Attapattu wrote:
Ok, I am not fixed on multiple-active-sessions.
But my concern is high availability with single-active-session model
under high load conditions.
As u pointed out,
In the web world, clients commonly throw multiple concurrent requests at
clusters, however, if we could
On Thu, 19 Jan 2006, Jules Gosnell wrote:
We should avoid making those decesions before hand.
What decisions does the user need to make?
Users need to make a lot of decisions already. Are the decisions you
mention worth the time it will take for users to make them?
as far as clustering
Rajith Attapattu wrote:
More question if you don't mind.
2.) Assuming sombody wants to do session replication (All
Active) instead of (one Active and n backups) is there provision
within the WADI api to plug in this stratergy?
I'm giving this some thought in terms of SFSB support, I'm
Rajith Attapattu wrote:
More question if you don't mind.
2.) Assuming sombody wants to do session replication (All
Active) instead of (one Active and n backups) is there provision
within the WADI api to plug in this stratergy?
I'm giving this some thought in terms of SFSB support, I'm
Oh Rajith - you've got me thinking :-(
I'm not happy with the last answer - lets try again
lets agree some points :
1) since changes made to sessions are made in app-space, apps are not
written with the expectation that a change collision may occur and the
container would not be able to
Jules Gosnell wrote:
Oh Rajith - you've got me thinking :-(
I'm not happy with the last answer - lets try again
lets agree some points :
1) since changes made to sessions are made in app-space, apps are not
written with the expectation that a change collision may occur and the
Ok, I am not fixed on multiple-active-sessions.
But my concern is high availability with single-active-session model under high load conditions.
As u pointed out,
In the web world, clients commonly throw multiple concurrent requests atclusters, however, if we could assure total affinity, these
Hi,
Some of these questions came up after reading the thread on totem. However I started the new thread so that searching is easy and also want distract the intense discussions on totem with out-of-topic questions.
Jules Gosnel wrote
This is not something that is really considered a
Rajith Attapattu wrote:
Hi,
Some of these questions came up after reading the thread on totem.
However I started the new thread so that searching is easy and also
want distract the intense discussions on totem with out-of-topic
questions.
Jules Gosnel wrote
This is not something that
70 matches
Mail list logo
