Hi Dain, Scott,
I wrote a servlet that accepts a request from a java.net.URLClassLoader
and returns the class. AFAIK I need only support requests of the kind
org/jboss/util/stream/Streams.class
but the exising WebServer class also supports
SomeClassName[some/object/id]/some/file/path
I
Patches item #685326, was opened at 2003-02-12 09:16
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=376687aid=685326group_id=22866
Category: JBossCX
Group: v3.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Jeff Gettle (jgettle)
Assigned to:
Bugs item #685329, was opened at 2003-02-12 15:29
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=376685aid=685329group_id=22866
Category: JBoss-IDE
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Dr. Domagoj Cosic (domic)
Assigned to:
Bugs item #575966, was opened at 2002-07-01 08:59
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=376685aid=575966group_id=22866
Category: JBossTX
Group: v3.0 Rabbit Hole
Status: Open
Resolution: None
Priority: 5
Submitted By: Paul Adams (padams)
Assigned to: David
Bugs item #575966, was opened at 2002-07-01 13:59
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=376685aid=575966group_id=22866
Category: JBossTX
Group: v3.0 Rabbit Hole
Status: Open
Resolution: None
Priority: 5
Submitted By: Paul Adams (padams)
Assigned to: David
On further testing the ExportException went away but I'd still like to
know how to plugin the servlet.
James
James Cooley wrote:
Hi Dain, Scott,
I wrote a servlet that accepts a request from a java.net.URLClassLoader
and returns the class. AFAIK I need only support requests of the kind
You won't find this in the servlet spec.
SomeClassName[some/object/id]/some/file/path is a JBoss convention
for specifying Java classes and resources dynamically downloaded by
clients. It is used by org.jboss.web.WebClassLoader and by
org.jboss.iiop.WebCL. See comments in
Bugs item #620838, was opened at 2002-10-09 15:43
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=376685aid=620838group_id=22866
Category: None
Group: None
Status: Closed
Resolution: Fixed
Priority: 5
Submitted By: Jay Petersen (s2jcpete)
Assigned to: Scott M Stark
Bugs item #684605, was opened at 2003-02-11 14:37
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=376685aid=684605group_id=22866
Category: JBossTX
Group: v3.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Marek Drejak (marekdrejak)
Assigned to: David
Bugs item #682618, was opened at 2003-02-07 22:54
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=376685aid=682618group_id=22866
Category: None
Group: v4.0
Status: Open
Resolution: None
Priority: 7
Submitted By: Matthew Munz (mattmunz)
Assigned to: David Jencks
Bugs item #682511, was opened at 2003-02-07 19:13
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=376685aid=682511group_id=22866
Category: JBossTX
Group: v3.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Bob Cotton (bcotton969)
Assigned to: David Jencks
Bugs item #680956, was opened at 2003-02-05 15:04
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=376685aid=680956group_id=22866
Category: JBossTX
Group: v3.0 Rabbit Hole
Status: Open
Resolution: None
Priority: 5
Submitted By: Jakob Spies (jspies)
Assigned to: David
Bugs item #673371, was opened at 2003-01-23 21:32
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=376685aid=673371group_id=22866
Category: JBossServer
Group: CVS HEAD
Status: Open
Resolution: None
Priority: 5
Submitted By: Frank Langelage (lafr)
Assigned to: David
Bugs item #685329, was opened at 2003-02-12 14:29
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=376685aid=685329group_id=22866
Category: JBoss-IDE
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Dr. Domagoj Cosic (domic)
Assigned to:
Bugs item #685473, was opened at 2003-02-12 14:18
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=376685aid=685473group_id=22866
Category: JBossServer
Group: v3.0 Rabbit Hole
Status: Open
Resolution: None
Priority: 5
Submitted By: John Stalker (jstalker)
Assigned
JBoss daily test results
SUMMARY
Number of tests run: 1026
Successful tests: 1023
Errors:2
Failures: 1
[time of test: 2003-02-12.12-05 GMT]
[java.version:
JBoss daily test results
SUMMARY
Number of tests run: 1074
Successful tests: 1065
Errors:7
Failures: 2
[time of test: 2003-02-12.20-40 GMT]
[java.version:
What if you don't have java on the client side? What if you're CORBA with
OTS? You're making it harder for Non-JBoss/Java clients to integrated with
us. I think this split should be undone.
BTW, why the split besides code readability? Is the DTM dependent on this
at all? Is the TM even
--- Bill Burke [EMAIL PROTECTED] wrote:
What if you don't have java on the client side?
What if you're CORBA with
OTS? You're making it harder for Non-JBoss/Java
clients to integrated with
us. I think this split should be undone.
How des OTS work? The corba guys tackled the DTM
problem
I'm currently working with a client who uses IIS/ServletExec due to
legacy issues. IIS is bound to port 80 and 443 on the PC's one IP. The
firewall is only open on port 80 and 443 for the machine's one IP. Some
requests need to be serviced by IIS/ServletExec, while others need to be
serviced by
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of Hiram
Chirino
Sent: Wednesday, February 12, 2003 5:09 PM
To: [EMAIL PROTECTED]; David Jencks
Subject: Re: [JBoss-dev] TxInterceptor split is bad
--- Bill Burke [EMAIL PROTECTED] wrote:
What if
Another thing David,
I don't see you always stuffing the Transaction into the invocation object.
A few interceptors rely on the transaction being in the invocation object.
Any objects to fixing this?
Bill
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf
Another problem I see is that the TxMethod map is required on the client
side as well. Makes proxies even more heavy and what do you do about a hot
deploy?
The hot deploy is a general issue with proxies. Whether or not this works depends
on the transport endpoint. RMI/JRMP proxies do not work
Ok, I'm looking at the code further and I'm pretty confused on how a
Transaction get propagated across the wire now. Can you explain? I don't
see any code anywhere that is doing a tm.resume from the transaction that is
past across the wire. Is this code broken?
Bill
-Original
Thomas Peuss is working on a load balancer that would encompass this. You
can see if there is code that is usable for you task.
Scott Stark
Chief Technology Officer
JBoss Group, LLC
- Original Message -
From: Nathan Phelps [EMAIL
Actually the code is much more readable. I guess my
only concern now is
non-java/jboss clients. And, do we care?
Non java code will have a seperate server-side invoker
and it should deal with the TX stuff as best it can.
In otherwords, do it the old way if it works better
for corba.
Ok, I see where the Transaction gets stuffed into the invocation object.
Still no tm.resume though for user transactions.
Bill
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of Bill
Burke
Sent: Wednesday, February 12, 2003 6:06 PM
To: [EMAIL
The transaction is not getting propagated across the
wire. A new XID is what is getting propagated.
Remember that an XID != the tx. The relationship is
that a tx will have multiple XIDs (one ore each
resource that is involved in the tx).
David is treating the remote jboss server like any
other
P T C
Resettable fuses
www.wanreihe.com
Dear maddam or sir:
(sorry for interupting
you)
When traditional fuses being used for
overcurrent
I don't see where the tm.resume happens to associate the transaction with
the current thread. The old UserTransaction stuff is still there in
JRMPInvokerProxy and JRMPInvoker (importTPC and such), but the logic to
associate the thread on the server with the transaction is not there anymore
unless
One test currently fails :
01:00:50,842 INFO [jbossweb] Error compiling file:
/tmp/Jetty_0_0_0_0_8080__jbosstest/classpath_jsp.java [javac]
Compiling 1 source file
/tmp/Jetty_0_0_0_0_8080__jbosstest/classpath_jsp.java:135: cannot
resolve symbol
symbol : class EJBStats
location: package
I just fixed it. Thanks for pointing out the issue.
Scott Stark
Chief Technology Officer
JBoss Group, LLC
- Original Message -
From: Jules Gosnell [EMAIL PROTECTED]
To: jboss-development [EMAIL PROTECTED]
Sent: Wednesday, February 12,
There are two layers of integration between web containers
and JSR77 model components I want to implement for 3.2 The
first is the JSR77 WebModule which is handled at the
AbstractWebContainer level. Subclasses of AbstractWebContainer
need to populate the DeploymentInfo.mbeans list with the
JMX
In this case the client side method to tx support map uses MethodHash
values as keys since the Methods themselves are not serializable. Seems to
me that we should put the MethodHash values in the invocation to start
with.
david
On 2003.02.12 17:57 Scott M Stark wrote:
Another problem I see
I still want to understand why there needs to be a TxSupport.clientInvoke.
Please bring your thoughts/design public.
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of David
Jencks
Sent: Wednesday, February 12, 2003 10:17 PM
To: [EMAIL PROTECTED]
Ok, that is good. Yes we need to limit the use of the most strongly typed
components to where absolutely necessary to improve the robustness of
the framework level components. A MethodHash should not change
across hot deployments unless the method signature has changed and I
believe this is the
The design goal is to produce a working dtm that does not make unnecesary
inter-vm calls. The functionality of the client side tx interceptor
appears to be unavailable with the CORBA OTS if we do not write some client
side stuff.
Here is the sequence of events for a call between vms where a
Change Notes item #685731, was opened at 2003-02-13 05:11
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=381174aid=685731group_id=22866
Category: JBossCMP
Group: v3.2
Status: Open
Priority: 5
Submitted By: Adrian Brock (ejort)
Assigned to: Nobody/Anonymous (nobody)
Hi,
Just a heads up to see whether this change is deliberate?
In 3.2, if you create a subfolder in server/[config]/deploy with
deployables in it, the JARDeployer deploys them.
e.g. server/default/deploy/dead/http-invoker.sar
It doesn't deploy xml files.
This doesn't happen in 3.0
I only
I thought 3.0 had this same behavior. In the last training someone had created
a server/all/deploy/farm directory and placed an ejb-jar into this directory and it was
deployed. I can see both behaviors being useful in different situations, but I'm
not aware of what change in 3.2 would cause the
Scott Stark wrote:
I thought 3.0 had this same behavior. In the last training someone had
created
a server/all/deploy/farm directory and placed an ejb-jar into this
directory and it was
deployed.
Ok, sorry for noise.
I probably didn't spot it had started doing it until now?
I actually delete
41 matches
Mail list logo
