Re: [JBoss-dev] passivation in finalize
Bill Burke wrote: I do call System.gc() but not in a separate thread, and not every second. That just defeats the purpose. Bill Perhaps, you already realized it, but it seems to me that using references will not let you implement a ctx pool. I've modified your test program to trigger gc in a separate thread, now you'll see all references appearing on the queue but they are all useless, they all return null in get(), so you can't revive the object. Have you thought of abandoning pooling, garbage collection has gotten a lot better these days (though it should be worse for long-lived objects that make it to the old generation)? -- - Anatoly Akkerman Computer Science Dept. Courant Institute of Mathematical Sciences, NYU 715 Broadway, #719 Tel: 212 998-3493 New York, NY 10003 Fax: 212 995-4123 - --- This SF.net email is sponsored by: VM Ware With VMware you can run multiple operating systems on a single machine. WITHOUT REBOOTING! Mix Linux / Windows / Novell virtual machines at the same time. Free trial click here: http://www.vmware.com/wl/offer/345/0 ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] passivation in finalize
For interested parties, read this thread: http://forum.java.sun.com/thread.jsp?forum=4thread=315094 There are several schemes that implement pooling via tricks with references. Anatoly. --- This SF.net email is sponsored by: VM Ware With VMware you can run multiple operating systems on a single machine. WITHOUT REBOOTING! Mix Linux / Windows / Novell virtual machines at the same time. Free trial click here: http://www.vmware.com/wl/offer/345/0 ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] passivation in finalize
Bill Burke wrote: I did. ReferenceQueue only places the Reference objects in queue. The object itself has already been garbage collected. Bill Quote from the link Julien submitted: quote Phantomly Reachable An object is phantomly reachable when the garbage collector finds no strong, soft, or weak references, but at least one path to the object with a phantom reference. Phantomly reachable objects are objects that have been finalized, but not reclaimed. When the garbage collector finds only phantom references to an object, it enqueues the phantom reference. The program polls the reference queue and upon notification that the phantom reference is enqueued, performs post-finalization cleanup processing that requires the object to be unreachable (such as the deallocation of resources outside the Java heap). At the end of the post-finalization cleanup code, the program should call the clear() method on the phantom reference object to set the reference field to null to make the referent eligible for garbage collection. ... The processing always happens in the following order, but there is no guarantee when the processing will occur: * Soft references * Weak references * Finalization * Phantom references * Reclamation /quote It seems phantom references should work. I've never tried it myself, though. -- Anatoly --- This SF.net email is sponsored by: VM Ware With VMware you can run multiple operating systems on a single machine. WITHOUT REBOOTING! Mix Linux / Windows / Novell virtual machines at the same time. Free trial click here: http://www.vmware.com/wl/offer/345/0 ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] passivation in finalize
Bill Burke wrote: I tried phantom references, but they were never enqueued. See attached. Bill Run a separate thread that calls System.gc() repeatedly every second. -- - Anatoly Akkerman Computer Science Dept. Courant Institute of Mathematical Sciences, NYU 715 Broadway, #719 Tel: 212 998-3493 New York, NY 10003 Fax: 212 995-4123 - --- This SF.net email is sponsored by: VM Ware With VMware you can run multiple operating systems on a single machine. WITHOUT REBOOTING! Mix Linux / Windows / Novell virtual machines at the same time. Free trial click here: http://www.vmware.com/wl/offer/345/0 ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Naming service startup problem...
Luke Taylor wrote: I've got a problem with my Maven build. I've pretty much build a replica of the JBoss server as it stands with the current build, but during startup, the naming service appears to be trying to use tyrex classes instead of the jnp ones and I've no idea where it's getting the idea from. The jndi.properties file is in the conf directory (I assume that's where it bootstraps from) but I get the following exception in the log during startup (and things naturally screw up from then on): log 2003-06-18 19:06:35,218 DEBUG [org.jboss.system.ServiceController] starting service jboss:service=Naming 2003-06-18 19:06:35,218 INFO [org.jboss.naming.NamingService] Starting 2003-06-18 19:06:35,265 DEBUG [org.jboss.naming.NamingService] System.setProperty, key=java.naming.factory.initial, value=tyrex.naming.MemoryContextFactory 2003-06-18 19:06:35,281 DEBUG [org.jboss.naming.NamingService] System.setProperty, key=java.naming.provider.url, value= 2003-06-18 19:06:35,281 DEBUG [org.jboss.naming.NamingService] System.setProperty, key=java.naming.factory.url.pkgs, value=tyrex.naming 2003-06-18 19:06:35,281 INFO [org.jboss.naming.NamingService] Starting jnp server 2003-06-18 19:06:35,531 DEBUG [org.jboss.naming.NamingService] NamingServer stub: org.jnp.server.NamingServer_Stub[RemoteStub [ref: [endpoint:[217.39.46.22:1978](local),objID:[0 2003-06-18 19:06:35,703 INFO [org.jboss.naming.NamingService] Started jnpPort=1099, rmiPort=0, backlog=50, bindAddress=null, Client SocketFactory=null, Server SocketFactory=null 2003-06-18 19:06:35,859 DEBUG [org.jboss.naming.NamingService] InitialContext Environment: 2003-06-18 19:06:35,859 DEBUG [org.jboss.naming.NamingService] key=java.naming.factory.initial, value=tyrex.naming.MemoryContextFactory 2003-06-18 19:06:35,859 DEBUG [org.jboss.naming.NamingService] key=java.naming.provider.url, value= 2003-06-18 19:06:35,875 DEBUG [org.jboss.naming.NamingService] key=java.naming.factory.url.pkgs, value=tyrex.naming:tyrex.naming:org.jboss.naming:org.jnp.interfaces 2003-06-18 19:06:35,875 WARN [org.jboss.naming.NamingService] Context.PROVIDER_URL in server jndi.properties, url= 2003-06-18 19:06:36,140 ERROR [org.jboss.naming.NamingService] Starting failed: javax.naming.OperationNotSupportedException: Context is read-only 2003-06-18 19:06:36,156 WARN [org.jboss.system.ServiceController] Problem starting service jboss:service=Naming javax.naming.OperationNotSupportedException: Context is read-only at tyrex.naming.EnvContext.rebind(EnvContext.java:345) at org.jboss.naming.NamingService.startService(NamingService.java:189) at org.jboss.system.ServiceMBeanSupport.start(ServiceMBeanSupport.java:233) /log Anyone any ideas why it would be picking up the wrong classes? Luke. First, check your tyrex jar for erroneous jndi.properties hidden in it, removing it from the jar might help. Perhaps the JBoss classloading infrastructure sees the jndi.properties from the tyrex jar before it sees the jboss jndi.properties? -- Anatoly --- This SF.Net email is sponsored by: INetU Attention Web Developers Consultants: Become An INetU Hosting Partner. Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission! INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] JBoss.org website unavailable?
Have you tried a different browser/computer? (I had problems with Mozilla 1.2 on Win2K but IE6 and Mozilla 1.3 did not have this issue. Perhaps it is not a browser problem but worth trying anyway). Aleksandr Shneyderman wrote: It is not only him, actually; and there is absolutely nothing wrong with our route here as can get to anywhere else; no firewalls either; There is something wrong, not sure where though. [alex] traceroute www.jboss.org traceroute to jboss.org (216.83.160.154), 30 hops max, 40 byte packets 1 law-grhl-gw.law.columbia.edu (128.59.176.1) 0.621 ms 0.460 ms 0.457 ms 2 phi-edge-1.net.columbia.edu (128.59.127.81) 0.732 ms 0.528 ms 0.357 ms 3 nyser-gw.net.columbia.edu (128.59.1.4) 1.978 ms 2.584 ms 1.075 ms 4 67.99.58.193 (67.99.58.193) 13.559 ms 15.369 ms 13.142 ms 5 P2-2.c0.nwyk.broadwing.net (216.140.10.13) 10.891 ms 14.709 ms 18.598 ms 6 p7-0.c0.wash.broadwing.net (216.140.8.101) 24.571 ms 16.581 ms 23.678 ms 7 216.140.8.162 (216.140.8.162) 14.983 ms 19.049 ms 21.077 ms 8 mae-east.sgns.net (198.32.187.194) 28.176 ms 17.583 ms 18.271 ms 9 phlpr10-ge-1-0-0-0.sgns.net (216.83.181.45) 22.061 ms 23.814 ms 24.877 ms 10 atlpr10-so-0-3-2-0.sgns.net (64.238.202.101) 38.858 ms 44.182 ms 79.377 ms 11 atlir3-so-0-0-0-0.sgns.net (208.16.212.197) 41.567 ms 43.702 ms 49.623 ms 12 208.16.208.234 (208.16.208.234) 50.781 ms 42.049 ms * 13 * * * 14 * * Alex. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Scott M Stark Sent: Wednesday, April 02, 2003 1:15 PM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] JBoss.org website unavailable? Its there as I just hit it. You will have to troubleshoot your route to the server. Scott Stark Chief Technology Officer JBoss Group, LLC - Original Message - From: Dave Neuer [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, April 02, 2003 9:56 AM Subject: [JBoss-dev] JBoss.org website unavailable? I keep getting connection refused when trying to connect to jboss.org, others in my company have similar problems. There's nothing about our firewall setup that's causing port 80 or 443 packets to be blocked. I need to access the forums. Dave --- This SF.net email is sponsored by: ValueWeb: Dedicated Hosting for just $79/mo with 500 GB of bandwidth! No other company gives more support or power for your dedicated server http://click.atdmt.com/AFF/go/sdnxxaff00300020aff/direct/01/ ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This SF.net email is sponsored by: ValueWeb: Dedicated Hosting for just $79/mo with 500 GB of bandwidth! No other company gives more support or power for your dedicated server http://click.atdmt.com/AFF/go/sdnxxaff00300020aff/direct/01/ ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development -- - Anatoly Akkerman Computer Science Dept. Courant Institute of Mathematical Sciences, NYU 715 Broadway, #719 Tel: 212 998-3493 New York, NY 10003 Fax: 212 995-4123 - --- This SF.net email is sponsored by: ValueWeb: Dedicated Hosting for just $79/mo with 500 GB of bandwidth! No other company gives more support or power for your dedicated server http://click.atdmt.com/AFF/go/sdnxxaff00300020aff/direct/01/ ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] jboss web-site issues
Hello, guys Since the website was switched to Nukes, Mozilla 1.2 on Win2K consistently pops up connection refused. IE6 works fine. Any ideas what is wrong? -- Anatoly. --- This SF.net email is sponsored by: ValueWeb: Dedicated Hosting for just $79/mo with 500 GB of bandwidth! No other company gives more support or power for your dedicated server http://click.atdmt.com/AFF/go/sdnxxaff00300020aff/direct/01/ ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] jboss web-site issues
Well, I don't know what was wrong. After upgrade to 1.3 it works fine. Sorry to bother you people. Juha-P Lindfors wrote: works with 1.2.1 + w2k too The 1.3 release of Mozilla is not showing this issue. Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.3) Gecko/20030312 Scott Stark Chief Technology Officer JBoss Group, LLC - Original Message - From: Anatoly Akkerman [EMAIL PROTECTED] To: JBoss-Dev [EMAIL PROTECTED] Sent: Monday, March 31, 2003 12:22 PM Subject: [JBoss-dev] jboss web-site issues Hello, guys Since the website was switched to Nukes, Mozilla 1.2 on Win2K consistently pops up connection refused. IE6 works fine. Any ideas what is wrong? -- Anatoly. --- This SF.net email is sponsored by: ValueWeb: Dedicated Hosting for just $79/mo with 500 GB of bandwidth! No other company gives more support or power for your dedicated server http://click.atdmt.com/AFF/go/sdnxxaff00300020aff/direct/01/ ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development -- - Anatoly Akkerman Computer Science Dept. Courant Institute of Mathematical Sciences, NYU 715 Broadway, #719 Tel: 212 998-3493 New York, NY 10003 Fax: 212 995-4123 - --- This SF.net email is sponsored by: ValueWeb: Dedicated Hosting for just $79/mo with 500 GB of bandwidth! No other company gives more support or power for your dedicated server http://click.atdmt.com/AFF/go/sdnxxaff00300020aff/direct/01/ ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] MBeanProxy with JBoss Remoting
Hi, I don't know if this is obvious and I am treading old ground or makes sense or not, but given that JMX remoting already works, if one creates a Java proxy to an MBean via MBeanProxy and that Proxy instance gets shipped through the Remoting infrastructure, wouldn't it make sense to make the JMXInvocationHandler to push invocations on this proxy to the original MBean through the Remoting pipe that it arrived through? This would be useful if an invocation on an MBean returns such a proxy object (say, this MBean is a Factory MBean for other MBeans but clients prefer typed invocation on the factory) and now you want to invoke this factory MBean remotely and still get meaningful objects back. -- Anatoly --- This SF.net email is sponsored by: SlickEdit Inc. Develop an edge. The most comprehensive and flexible code editor you can use. Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial. www.slickedit.com/sourceforge ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] jmx remoting + copyright in a jbossmx file
Hi, I've been browsing the HEAD in CVS to find out what the status of JMX remoting is. It appears that significant pieces have been implemented. I was hoping to use some of this stuff decoupled from JBoss itself, is it usable already? (I understand that classloading is a work in progress, can this work if all classes are available in both MBean servers?) And another thing I've noticed in one of the files, you might want to fix it. This is from org/jboss/mx/remote/connector/socket/SocketExecutor.java /** * @(#)$Id: SocketExecutor.java,v 1.3 2003/01/02 02:34:45 jhaynie Exp $ * * This code is PROPRIETARY AND CONFIDENTIAL to Vocalocity, Inc. * -- DO NOT RE-DISTRIBUTE THIS SOURCE CODE WITHOUT EXPRESS PERMISSION. -- * * This source code is Copyright (c) 2001-2002 by Vocalocity, Inc. * All Rights Reserved. * * The source code for this program is not published or * otherwise divested of its trade secrets, irrespective * of what has been deposited with the US Copyright Office. * */ Anatoly. --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] TxInterceptor split is really really good
David Jencks wrote: 4) invocation is routed to correct transport mechanism (such as by the HA Invoker interceptor)(AFAIK not yet written as an interceptor) 5) Invocation is received at server side. 6) The server decides if the resource registration callback is needed. And the resource registration occurs on the return of the original method invocation, or does it take an extra round trip immediately? The former incurs redundant bookkeeping requirements and the latter is inefficient. The latter is completely out of the question performance-wise, so I hope Ole is not argueing for it. It seems that sending the resource registration request on the return of the original method invocation should not be any more complex than what David does right now. In fact, there would still have to be a client side interceptor that takes the tx registration info from the InvocationResponse and perform the registration with the client side's TX manager. IMHO, David's approach is simpler to understand and cleaner than passing registration back in the InvocationResponse object. Anatoly. --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Transaction propagation change
That is easy. SPEED. Distributed transaction are pricey and difficult. By choice we did fastTM as an InVM implementation. Typical case of 90/10. Most applications actually use only invm stuff and so having an implemetnation that serializes stuff back and forth isn't worth it. Right now FastTM is REALLY FAST, so that the overhead of synchronization is NIL (dozen or so native java method calls). It is one of these things where we said you really need DTM, write it or use tyrex. Turns out Tyrex was a fake with critical methods throwing NotImplementException. But clearly we didn't BASE the design on distribution. I don't know which version of Tyrex you are referring to here, when I worked with it, all distributed 2pc was implemented. (I was using 0.9.8) And distributed transactions worked properly. The reason Tyrex no longer works with JBoss 3.x is because currently, the invoker code is not calling the TM to provide it with the TPC, just tries to serialize the transaction object itself. In order to get Tyrex to work again, I would have to wrap each Tyrex Transaction object with a special (Externalizable) wrapper that would serialize itself by extracting a TPC and sending only that down the wire. On the remote end the wrapper would be unmarshalled and during unmarshalling it would try to register the local TM as subordinate with the originating TM. This is doable but imposes a wrapper for each tx instance. I remember discussion about this and how Ole was not happy about it. Where are you Ole? It seems to me, the real issue with the inability to efficiently integrate an arbitrary JTS-compliant DTM with JBoss (like Tyrex), is lack of well-defined TM-independent transaction propagation semantics withing invoker layer. Another thing that would help tremendously is call-back to the originating server in the invokers. Not only it would simplify integration, it would enable some neat optimizations. Here is what I mean. For initial integration of Tyrex I had to start an RMI server for TM (well, actually for each distributed TX, don't ask why, I did not understand much when I wrote it, but it worked :) ), which would get called by the recipient of the invocation to register as subordinate XAResource passing to the originator it's own RMI stub through which the originator would call prepare(), commit() or rollback(). This resulted in an additional network trip for registration and each of the subsequent communication between the participating TMs. Nothing prevents a very simple optimization of doing at least the registration on the return trip from the invocation. Ideally, the invocation pipe through which the invocation arrived to the second server should supply a Callback interface to the originating (MBean?) server and implementations of this callback interface could optimize callback invocations, like bursting, etc. I guess this is somewhat similar to how XmlBlaster does asynch communication -- messages that flow in opposite directions can use completely different transports (e.g. an original subscription request came through a socket but requested updates to be returned through XML-RPC due to firewall restrictions). I've seen some of the need for this in the forums on Invokers. Am I making sense? Anatoly. --- This SF.NET email is sponsored by: Thawte.com Understand how to protect your customers personal information by implementing SSL on your Apache Web Server. Click here to get our FREE Thawte Apache Guide: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0029en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] deployment scripts + extending Configuration of JBossSXon the fly
write a small JBoss taglib that does deployment, dependency tracking and MBean invocations. Finally, since you mentioned aspects, I think you can in fact implement this kind of lifecylce helper as mbean interceptors. Such an interceptor would intercept only the lifecycle methods and provide pre and post actions from the jelly script (or other source). Yeah, perhaps. There is more than one way to do it We just need to see what makes more sense and what is easier, more compatible with current stuff and more flexible. I'm not sure if currently xmbeans can specify their interceptor or aspect stack in their xml descriptor, but if not I think it is easy to implement, needed, and coming soon. Thanks david jencks -- - Anatoly Akkerman Computer Science Dept. Courant Institute of Mathematical Sciences, NYU 715 Broadway, #719 Tel: 212 998-3493 New York, NY 10003 Fax: 212 995-4123 - --- This sf.net email is sponsored by: With Great Power, Comes Great Responsibility Learn to use your power at OSDN's High Performance Computing Channel http://hpc.devchannel.org/ ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] deployment scripts + extending Configuration of JBossSXon the fly
Scott M Stark wrote:
Well, the use case driving this is simply a problem with how JBossMQ integrates
with the security framework. Its a hardcoded property of its security manager
rather than an attribute of the service. If the latter was the case then you could
reference a unique configuration.
Wholeheartedly agree that this piece of MQ is poorly written.
The security config can be part of any deployment using the same approach
as that shown in the org.jboss.test.security.service.SecurityConfig and the
associated security unit tests. I'll be moving this out of the test package into the
general security framework in the near future.
I've taken a look at the SecurityConfig. All it does is create an
XMLLoginConfig MBean and then push it to the top of the stack of
Configurations. So, basically it does its own custom scripting. It
solves the problem but isn't it an overkill to create an MBean whose
function is only to instantiate another MBean and register it with the
third? This is pure metaprogramming.
I still have a security question, though:
If I understand correctly, the entire Configuration gets replaced by the
one that currently sits on the stack? Can I just add a particular piece,
say, only application-policy for 'jbossmq-instanceid1234' while all
other policies remain in place? Can I later remove any named application
policy w/o affecting the rest? Stack seems to be a very limited data
structure, I cannot add jbossmq-id1, jbossmq-id2 and then remove
them in the _same_ (not stack-based) order.
Is there any technical limitation for doing what I need? Am I misreading
something? Please, correct me if I am wrong.
So let's not cloud the discussion of why scripting of deployment descriptors
is needed based on an improper integration of a service. Most of what you
are talking about is similar to the binding service in the varia module:
org.jboss.services.binding.ServiceBindingManager. Investigate how this
can be extended to incorporate what you need.
I've taken a look at the ServiceBindingManager. It is somewhat similar
to what I need but not exactly. In fact, it could have been a lot
simpler (w/o requiring one to write a special delegate class that is
responsible for changing configuration) by using the scripting facility
itself. Here is how it could be done when *-service.xml is interpreted
as a script:
Deployer loads a configuration for a service (similar to ServiceConfig)
which can be simply a property sheet.
It initializes variables in the JellyContext with values from the
ServiceConfig
Let's say the ServiceConfig for this bean has the following properties,
so we simply set variables in JellyContext with the appropriate names:
FooService.Name = myDomain:service=Foo-1
FooService.ref1 = otherDomain:service=someName
FooService.jndiName = java:/Foo-1
FooService.propX = someValue
Deployer loads the foo-service.xml and executes it (it sets the taglib
to the deployTagLib).
foo-service.xml should have references to appropriate variables, like:
mbean name=${FooService.Name} class=so.and.soClass
depends optional-attribute-name=ref1${FooService.ref1}/depends
attribute name=JndiName${FooService.jndiName}/attribute
attribute name=propX${FooService.propX}/attribute
/mbean
mbean tag creates the MBean with the given name and class (expression
${FooService.Name} is evaluated in the JellyContext and value of
myDomain:service=Foo-1 gets filled in.
the mbean evaluates its body (which means that depend and
attribute tags get executed.
depends tag ensures that the dependency is present
attribute tag locates closes surrounding mbean, gets its mbean and
sets the attributed to the appropriate value.
Now, if you wanted to reset certain attributes on an already existing
mbean, you would run _the same_ foo-service.xml but using a
reconfigureTagLib which binds the mbean tag to tag implementation that
looks up the mbean instead of creating it.
Ain't it simpler?
Scott Stark
Chief Technology Officer
JBoss Group, LLC
--
-
Anatoly Akkerman
Computer Science Dept.
Courant Institute of Mathematical Sciences, NYU
715 Broadway, #719 Tel: 212 998-3493
New York, NY 10003 Fax: 212 995-4123
-
---
This sf.net email is sponsored by:
With Great Power, Comes Great Responsibility
Learn to use your power at OSDN's High Performance Computing Channel
http://hpc.devchannel.org/
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] deployment scripts + extending Configuration of JBossSX on the fly
Hello, Jbossers
It seems that for the benefit of the wider audience I'll start with the
deployment scripting idea. For those interested in what drove me to the
idea, see below in the security part (I am sure people will have their
own use-cases for this stuff, I remember discussions from before)
For my project I need to be able not only to deploy/undeploy services on
the fly but, sometimes this is insufficient, I also need to stich them
together after deploy, unstich before undeploy, say by invoking a bunch
of methods on a bunch of MBeans.
This is clearly a deployment issue, perhaps, there is a need to move
from 'Slackware'-style packaging to 'Debian'-style packaging for
components (or at least, add extensions people can use). To explain the
analogy:
Slackware used plain old tgz's for its packages which one would just
untar and that's it. This works for simple things but when the system
grows and packages become more dependent on other packages and
versioning info, etc., this does not cut it anymore.
Debian uses a sophisticated package format with a whole bunch of stuff
packed into the package, like dependency information, pre-/post-
-installation/-configuration/-removal scripts that can modify/unmodify
various config files, etc. Obviously, in the simplest form a .deb can be
do as little as a .tgz does.
The simplest scripting tool which would be suitable for quick jobs like
the one I need, would be something based on Apache Jelly.
Let's say, the *-service.xml is not really a descriptor (though it
appears as such, we don't need to change old descriptors either) but,
say the JBoss DeployerMBean, instead of treating it as plain XML
interprets it as a Jelly script. JBoss provides a standard JBoss tag
library that interprets the tags for the *-service.xml, say, mbean tag
deploys the MBean specified by the tag's attributes and configures it
appropriately. So, a simple deployment descriptor would not notice any
difference. But, say you add another attributed to the mbean tag, say,
'referenceVar' which specifies the name of the variable under which the
object name of the newly created bean will be stored in the JellyContext
in which this script is running. Then, one can simply add a scripting
section at the end of *-service.xml which manipulates the initialized
variables, e.g. through custom jelly tags locate and invoke methods on
MBeans specified by variables from the JellyContext:
mbean code=xxx name=yyy refVar=mbeanX/
jmxinvoke targetObj=${mbeanX} method=${methodDesc} args=${args} /
where jmxinvoke is a custom Jelly tag which takes a target object name,
method description object and arguments array and does the invocation.
Obviously this is very similar to the jsp tags, which is exactly the
point of Jelly. So, with properly defined tags for invocation, exception
handling, etc, one can do simple meta-programming of MBeans during
deployment.
At the end, the DeployerMBean which processes this script, checks for
exceptions coming from the script execution and deals with them
according to the convention: calls the cleanup section of the script or
whatever. (By clean-up section I mean that the *-service.xml can be made
of sections which the deployer 'executes' depending on whether previous
stages succeed/fail)
This is the end of deployment issue/proposal. Now the security question.
Here is the problem setting:
I need to be able to have deploy any JBoss service, possibly multiple
instances, simultaneously on the same server. For that I have an
infrastructure for reconfiguring JBoss descriptors of services. For
example, for JBossMQ, I make sure that all MBeans that comprise JBossMQ
have unique object IDs, all JNDI objects exported by the service are
also uniquefied, that all cross-references are correct, etc. It turns
out that this is not enough. One aspect (yeah that 'a'-word again) of
deploying JBossMQ is completely separated from jbossmq-service.xml and
cannot be folded into *-service.xml. Namely, it is configuring security
for this particular JBossMQ instance.
It turns out (as for 3.0.4) that login-conf.xml contains an application
policy for 'jbossmq' which has a reference to a particular JBossMQ
MBean, namely StateManager. Since I always change the object name of
this MBean, I need to be able to deploy the login-config on the fly. It
would seem that ideally, one should be able to deploy the JBossMQ
service together with specification of its security domain.
My thought was, well, I'll just create my custom login-conf.xml with an
entry for just JBossMQ that I am deploying and would utilize the
XMLLoginConfig MBean, which I would deploy together with MQ. As it turns
out, this is not sufficient (silly me). After looking further into
security architecture, I can only fully replace the current
Configuration with a new one. My idea was to allow changes to the
current configuration. Is this idea crazy or not?
Well if it is not crazy, then, the
Re: RES: [JBoss-dev] Tyrex 2
Márcio Emílio Cruz Vono de Azevedo wrote: Yes, you found the solution indeed!!! I've tried it and it solved my problem!!! Thank you very much! -- Márcio Emílio Cruz Vono de Azevedo System Specialist Inatel Competence Center http://www.inatel.br The solution is not actually correct in case you actually need to propagate the transaction context. (i.e. if from within methodA of the Bean A that lives on host A a call is made to methodB of Bean B that lives on host B and methodA is transactional (i.e. REQUIRES_NEW, REQUIRES) and method B just REQUIRES, then the solution will not be entirely correct, because methodA will run in its own transaction (txA)and method B will run in its own transaction (txB). According to the spec, txB should be subordinate to txA and commit/rollback when txA is committed/rolled back, while using the change suggested, txB will always commit even if txA is rolled back. Hope this is not too complicated :) I assume that Tyrex stopped working as a DTM when client interceptors were introduced into JBoss (this is what I could figure out from the way client interceptors are written, it turns out they never ask Tyrex to serialize a transaction propagation context). I don't yet have a quick fix for this and according to David Jencks, 4.0 will have JBoss native TM run distributed txs, there also will be enough support in the interceptors/invokers/transport stuff to easily replug-in Tyrex. I guess, I can write a new plugin for 4.0 when the stuff David spoke about shall hit CVS. Anatoly. --- This sf.net email is sponsored by: With Great Power, Comes Great Responsibility Learn to use your power at OSDN's High Performance Computing Channel http://hpc.devchannel.org/ ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: RES: [JBoss-dev] Tyrex 2
Márcio Emílio Cruz Vono de Azevedo wrote: I did it now, thank you for your hint, but it hasn't solved the problem of the remote access. I've tried to use Tyrex to access remotely a EJB and the following exception has occured again: 14:53:21,350 ERROR [STDERR] java.rmi.MarshalException: error marshalling arguments; nested exception is: java.io.NotSerializableException: tyrex.tm.impl.TransactionImpl It happens when I try to call a findBy method of my entity bean passing a java.lang.String parameter. By the way, I'm using JBoss 3.0.4. I would need a full stack trace to understand why JBoss is trying to serialize the wrong object. (JBoss should be using special Tx importer and exporter to extract tx information into something serializable, it should not serialize the tx object directly, like it is attempting now) Also, beware, Tyrex plugin is not production-quality, it is just to play with distributed transactions in JBoss. -- Anatoly. --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] How does client side JRMPInvokerProxy get TransactionPropagationContextFactoryset? (Tyrex issues)
I am a bit unclear on how this stuff happens (looking at 3.0.4) source Tyrex plugin has stopped working because the client proxy does not seem to be able to serialize the tyrex tx context correctly. The root cause seems to me the fact that the JRMPInvokerProxy does not know about the correct tx propagation ctx factory. The only place in code that I could locate that calls setTPCFactory() on JRMPInvokerProxy is in the constructor of ClientUserTransaction. This seems to break distributed transactions via Tyrex, because if a bean in server A holds a proxy to a bean in server B, that proxy is not picking up the right TPC factory and tries to serialize the transaction instance itself, which is not serializable. It seems the fact that the TPC importer and exporter are registered in JNDI of the server that hosts the bean that has the proxy is never utilized. Can someone explain this to me? In general, how would client side interceptors become 'aware' of the presence of a TransactionManager with its own TPCExporter when the proxy ends up in another JBoss instance, while, the same proxies can also get used in a plain java client which has no local TM and Exporter and the bean utilizes ClientUserTransactions? I saw Marks comments in the code and remember the discussions about making TXs serializable (let them handle serialization themselves). So, what is the bottomline? Perhaps, once MBean server is mandated on the client side, the interceptors will just lookup the TM in the local MBean server. But in the meantime, what would be the right approach to fix the Tyrex plugin for 3.x branch? -- - Anatoly Akkerman Computer Science Dept. Courant Institute of Mathematical Sciences, NYU 715 Broadway, #719 Tel: 212 998-3493 New York, NY 10003 Fax: 212 995-4123 - --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Tyrex 2
Tyrex has a built in JNDI, therefore it packages its own jndi.properties inside the tyrex jar. REMOVE IT !!! Then Tyrex will pick up the jndi.properties from the JBoss classpath, not from inside of its own jar. This should solve your problem. Anatoly. Márcio Emílio Cruz Vono de Azevedo wrote: Hi all, I have changed the tyrex code to solve the problem with the log4j version. The server was started with no problem but now we have problems with naming. I've tried debugging with println's and I've found that Tyrex doesn't find any JNDI name. I need to solve my problem ASAP and because of it I'm here to ask you a big favour!!! If anybody has a version of Tyrex that works well with JBoss 3.0.4, could you please send me? I'd be very grateful! Thank you very much in advance! -- Márcio Emílio Cruz Vono de Azevedo System Specialist Inatel Competence Center http://www.inatel.br --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development -- - Anatoly Akkerman Computer Science Dept. Courant Institute of Mathematical Sciences, NYU 715 Broadway, #719 Tel: 212 998-3493 New York, NY 10003 Fax: 212 995-4123 - --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Tyrex...
:10:58,923 ERROR [STDERR] at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:517) 19:10:58,939 ERROR [STDERR] at org.jboss.system.server.ServerImpl.doStart(ServerImpl.java:324) 19:10:58,939 ERROR [STDERR] at org.jboss.system.server.ServerImpl.start(ServerImpl.java:221) 19:10:58,939 ERROR [STDERR] at org.jboss.Main.boot(Main.java:148) 19:10:58,970 ERROR [STDERR] at org.jboss.Main$1.run(Main.java:381) 19:10:58,970 ERROR [STDERR] at java.lang.Thread.run(Thread.java:536) 19:10:58,970 ERROR [STDERR] Caused by: java.lang.NoSuchMethodError: org.apache.log4j.FileAppender: method init(Lorg/apache/log4j/Layout;Ljava/io/OutputStream;)V not found 19:10:58,986 ERROR [STDERR] at tyrex.util.Logger.clinit(Logger.java:93) 19:10:58,986 ERROR [STDERR] at tyrex.tm.impl.TransactionDomainImpl.init(TransactionDomainImpl.java:321) 19:10:59,001 ERROR [STDERR] at tyrex.tm.impl.DomainConfig.getDomain(DomainConfig.java:303) 19:10:59,001 ERROR [STDERR] at tyrex.tm.TransactionDomain.createDomain(TransactionDomain.java:478) 19:10:59,001 ERROR [STDERR] at tyrex.tm.TransactionDomain.createDomain(TransactionDomain.java:174) 19:10:59,001 ERROR [STDERR] at org.jboss.tm.plugins.tyrex.TransactionManagerService.startService(Transactio nManagerService.java:92) 19:10:59,001 ERROR [STDERR] at org.jboss.system.ServiceMBeanSupport.start(ServiceMBeanSupport.java:165) 19:10:59,017 ERROR [STDERR] at sun.reflect.GeneratedMethodAccessor7.invoke(Unknown Source) 19:10:59,017 ERROR [STDERR] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl .java:25) 19:10:59,033 ERROR [STDERR] at java.lang.reflect.Method.invoke(Method.java:324) 19:10:59,033 ERROR [STDERR] at org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBeanDispat cher.java:284) 19:10:59,048 ERROR [STDERR] at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:517) 19:10:59,048 ERROR [STDERR] at org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceController.jav a:978) 19:10:59,048 ERROR [STDERR] at $Proxy0.start(Unknown Source) 19:10:59,048 ERROR [STDERR] at org.jboss.system.ServiceController.start(ServiceController.java:398) 19:10:59,064 ERROR [STDERR] at sun.reflect.GeneratedMethodAccessor6.invoke(Unknown Source) 19:10:59,064 ERROR [STDERR] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl .java:25) 19:10:59,064 ERROR [STDERR] at java.lang.reflect.Method.invoke(Method.java:324) 19:10:59,080 ERROR [STDERR] at org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBeanDispat cher.java:284) 19:10:59,095 ERROR [STDERR] at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:517) 19:10:59,095 ERROR [STDERR] at org.jboss.util.jmx.MBeanProxy.invoke(MBeanProxy.java:174) 19:10:59,095 ERROR [STDERR] at $Proxy3.start(Unknown Source) 19:10:59,095 ERROR [STDERR] at org.jboss.deployment.SARDeployer.start(SARDeployer.java:249) 19:10:59,111 ERROR [STDERR] at org.jboss.deployment.MainDeployer.start(MainDeployer.java:807) 19:10:59,111 ERROR [STDERR] ... 14 more I'm using JBoss 3.0.4 + Tomcat under Windows 2000 and J2SE 1.4.1. Thanks in advance by any help. Marcio Azevedo. -- Márcio Emílio Cruz Vono de Azevedo System Specialist Inatel Competence Center http://www.inatel.br --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development -- - Anatoly Akkerman Computer Science Dept. Courant Institute of Mathematical Sciences, NYU 715 Broadway, #719 Tel: 212 998-3493 New York, NY 10003 Fax: 212 995-4123 - --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] new direction for JBoss AOP
marc fleury wrote: I just saw this QDox http://qdox.sourceforge.net/index.html It could really help us to read the data from the source files. It seems that there is even a small AOP framework built on it (Nanning). Guys it is time to really commoditize this. The funny thing is that we don't even compete with the commercial vendors on this, we run miles ahead. IT was there the whole time and we had been generalizing it the whole time. I love EJB's. Anyway, we need to kill all these little efforts and like a magnet bring all the effort and focus on our own framework for this implementation. THIS IS IT. WE ARE DONE. JB5 will be services coupled with interceptors in one easy to use and assemble framework. marcf Check out http://jac.aopsys.com/ It is LGPL They have the framework, haven't looked at it in great detail, perhaps, some of its features are different. -- - Anatoly Akkerman Computer Science Dept. Courant Institute of Mathematical Sciences, NYU 715 Broadway, #719 Tel: 212 998-3493 New York, NY 10003 Fax: 212 995-4123 - --- This SF.net email is sponsored by: Get the new Palm Tungsten T handheld. Power Color in a compact size! http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0002en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Metadata Service
Matt Munz wrote: Bill, My thinking is that a well-crafted object graph or relational db needs to be crafted and the code maintained. Most components in JBoss are configured Well, so do DTDs and XML schemas. It is an interesting argument that an XML Document object is a more flexible construct than a given arrangement of Data Objects (Hashtables, lists), and POJOs. I suppose the primary point is that an XPath query is more easily maintained than a given set of method calls. It certainly avoids the compiler, but so does the JMX bus, which does not use an XML document object as its metadata database... Actually, Jakarta JXPath can handle practically any java object graph (consisting of JavaBeans, Maps, etc. ) and traverse it via an XPATH query, so you don't have to tie yourselves to DOM objects. check out http://jakarta.apache.org/commons/jxpath/ So, actually, as long as your custom object graph is 'equivalent' to a DOM tree you can remove the DOM tree from the global configuration and replace it by your custom object graph. Don't know if it is useful to anybody, though. via XML files. Why not store this XML in memory with Xerces? XML Objects provide us with a common, simple, easy way to store config data in memory and reference it(XPath). Sure. But don't the XML Objects eventually get converted into Objects? Why not keep those Objects in memory? For the objects that end up as MBeans, perhaps an enhanced search mechanism for the MBean Registry would be another way to address the problem? - Matt -- - Anatoly Akkerman Computer Science Dept. Courant Institute of Mathematical Sciences, NYU 715 Broadway, #719 Tel: 212 998-3493 New York, NY 10003 Fax: 212 995-4123 - --- This sf.net email is sponsored by: Are you worried about your web server security? Click here for a FREE Thawte Apache SSL Guide and answer your Apache SSL security needs: http://www.gothawte.com/rd523.html ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Metadata Service
Dain Sundstrom wrote: Bill Burke wrote: XPATHs would be a perfect fit for something like this. Why recreate? Another thing that MBeans don't seem to address is the notion of layered configuration or in other words configuration domains. Each layer can inherit/modify the configuration from a top level layer. Cluster wide config. Per APp server config tailored to each machine. Overrides at the component and invocation level. Let's take a use-case. Let's say I want to change config cluster-wide for one particular attribute. Let's say DB connection pool max size. What you have to do now is go to each and every machine to do this. Bill to me this XML stuff is just an implementation detail. The important questions are: * Where does the metadata live? Is it hanging off the container, application or a toplevel domain? I would assume the container has a ref to a service that maybe shared across the domain, but the container doesn't care as it only has a simple interface. * How is the data loaded into the repository? I am thinking of specialized loader classes that in the example of ejb fill the repository with method level metadata like security and tx * How are changes propagated from the repository to the physical structure and the other way around. I have no idea on that one. -dain It seems, some of these issues Rickard tried to address by using run-time attributes (check out his weblog) http://roller.anthonyeden.com/page/rickard/20021113 -- - Anatoly Akkerman Computer Science Dept. Courant Institute of Mathematical Sciences, NYU 715 Broadway, #719 Tel: 212 998-3493 New York, NY 10003 Fax: 212 995-4123 - --- This sf.net email is sponsored by: Are you worried about your web server security? Click here for a FREE Thawte Apache SSL Guide and answer your Apache SSL security needs: http://www.gothawte.com/rd523.html ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] java aspect components (JAC)
For those interested in AOP and building JBoss around AOP, take a look at JAC (b.t.w. developed by French, hmm...) http://jac.aopsys.com/ look at their papers (from last year) http://jac.aopsys.com/JAC_07_2002.ppt this is the latest presentation The code is LGPL. Version 0.8+ Does object wrapping (no proxying, just bytecode rewriting, similar to what Prof. Yannis at Georgia Tech is doing). They do have aspects for remoting, load balancing, replication, consistency, (check the tutorials). They are also aware of the fact that this is a better model for application servers (check their presentation) Interceptors can be added per object, per method in unique stacks. There is no multiple target object aggregation like in Richard's framework, though. Their implementation may not be very fast, don't know. -- - Anatoly Akkerman Computer Science Dept. Courant Institute of Mathematical Sciences, NYU 715 Broadway, #719 Tel: 212 998-3493 New York, NY 10003 Fax: 212 995-4123 - --- This sf.net email is sponsored by: See the NEW Palm Tungsten T handheld. Power Color in a compact size! http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] -service.xml generator
Hi, Alex Jelly would give you similar ease of use but without having to write any XSL. You would initialize the JellyContext by creating in first and then setting variables in it from attributes like this: ctx.setVariable(name, value); (values can be any Java objects) you load your modified *-service.xml script from a URL into Jelly and run it as a script in the context which you just set up. The result of this operation is XML again. This is simplest usage of Jelly. You do need a library, though, and possibly, not one but a bunch from jakarta-commons. I am using Jelly in a slightly more advanced fashion. I wrote a few very simple tags that allow output of Jelly to be a jar file. Something like: j:jelly xmlns:j=jelly:core xmlns:zipper=jelly:mypackage.MyTagLib zipper:zip zipper:entry name=META-INF/ejb-jar.xml parametrized ejb-jar.xml contents go here /zipper:entry zipper:entry name=META-INF/jboss.xml parametrized jboss-xml contents go here /zipper:entry /zipper:zip /j:jelly Set up the JellyContext for running this script with appropriately configured variables (say from a DB of configurations or from attributes of an MBean). Run the script in the context. After running this script, the JellyContext contains a Jar archive (as a byte[] stored under some variable name) of reconfigured descriptors. The way I use it is to have a servlet that parses its path request and deduces from the path request which script to run and which configuration to pull from storage. The servlet outputs either XML or JAR depending on the requested module and its script. So, you can just point the JBoss deployer to deploy a URL of the kind: myservlet/componentA/configX.jar or myservlet/serviceB/configY.xml and the servlet automatically generates properly configured jar or xml which the Deployer happily deploys. Jelly has many usages this is just what I could come up with. It would be more than adequate for what you need to do, but if you are dissatisfied with JBoss library dependency growth, then, Jelly is out of the picture. Alex Loubyansky wrote: Thanks, Anatoly. I'll check it. Also I thought about Velocity which looks similar to Jelly from your description, though I am not familiar with the last one. Could you, please, look at the following idea with XML/XSL, compare it with Jelly and give your opinion? - before transformation, each MBean's attribute is set as a parameter to the Transformer with Transformer.setParameter(...) with the name equal to the corresponding parameter name used in XSL stylesheet; - transform XML template with Transformer and XSL stylesheet. As for me, XML/XSL requires two templates (XML and XSL) while Jelly/Velocity requires only one. Also, I wouldn't add any thirdparty library unless it really helps. The JBoss becomes so heavy. I think it's problem. --- This SF.net email is sponsored by: ApacheCon, November 18-21 in Las Vegas (supported by COMDEX), the only Apache event to be fully supported by the ASF. http://www.apachecon.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] -service.xml generator
Alex Loubyansky wrote:
I am thinking about writting an MBean that will generate *-service.xml
files for datasources.
I see it the following way.
- MBean attributes corresponding to values needed to construct
-service.xml (such as url, driver, user, password, etc);
- XML template with dummy/default values;
- XSL stylesheet similar to what David wrote for -ds.xml;
- managed operation 'generate' that will transform XML template,
probably, mostly substituting dummy values with managed attribute values.
Actually, I am looking for a nice way to configure datasources in
FoeDeployer but I think it could be useful behind it.
Also the same way any -service.xml file can be generated.
Any thoughts?
Thanks.
I would strongly recommend using Jelly (from Apache) (found out about it
from Rickard Oberg's weblog). You take your service-xml file and just
replace values you might will need to change with expressions like
${varname}. Then you can run the XML file as a script in Jelly in a
JellyContext in which you set up all the needed variables, say, from the
MBean's attributes. The result of running it through Jelly is XML with
the expressions properly evaluated. (Jelly is a much better replacement
to JSPs and similar things, what is good about it you can run it w/o any
container nonsense). You can also create your custom tag libraries like
in JSPs, though it is much better than JSPs. There is not much
documentation but it is pretty straight forward. Get back to me if you
are having difficulties.
(You would not need XSLT either, actually, I am using Jelly in this way
to automatically reconfigure application components, like EJBs or others
and system-level components, like MBeans. If anyone is interested, I can
share some of that stuff)
Anatoly.
--
-
Anatoly Akkerman
Computer Science Dept.
Courant Institute of Mathematical Sciences, NYU
715 Broadway, #719 Tel: 212 998-3493
New York, NY 10003 Fax: 212 995-4123
-
---
This SF.net email is sponsored by: ApacheCon, November 18-21 in
Las Vegas (supported by COMDEX), the only Apache event to be
fully supported by the ASF. http://www.apachecon.com
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] questions about CMP/Clustering
David Jencks wrote: You will probably want to use Tyrex for now. As the author of Tyrex plugin, I have to advise you not to use Tyrex plugin in production environments, it is very inefficient (for every outstanding (not committed) transaction and its distributed XAResource (or propagated tx) you get an instance of an RMI UnicastRemoteServer running). More efficient implementation is possible (I can share some design ideas and some code if someone is willing to do the complete implementation). On the other hand, distributed 2pc is slow to begin with. If you are not doing lots of it, it might still be fine. Please, avoid distributed 2pc as plaque, if you need performance. Both the jboss tm and tyrex can use XAResources from Oracle and other xa capable resource managers, and follow the xa 2pc protocol (at least as far as it is comprehensible). However, the jboss tm does not log transactions, so there is no automated recovery. The jboss tm also does not currently support distributed transactions, although this should be coming soon in jboss 4. If you have a homogeneous deployment this would not be relevant, however. david jencks -- - Anatoly Akkerman Computer Science Dept. Courant Institute of Mathematical Sciences, NYU 715 Broadway, #719 Tel: 212 998-3493 New York, NY 10003 Fax: 212 995-4123 - --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] questions about CMP/Clustering
Emerson Cargnin - SICREDI Serviços wrote: sorry for the simple question, but what's the difference if i use homogeneous or heterogeneous deployment (regarding to distributed two-phase-commit). see below. how could I implement the follow: 1- access a method from a session facade from a client (this have required transaction attribute on this method). 2- the session facade finds and changes some cmp attribute. 3- the session facade uses jdbc to change some data from legacy 4- the transaction is commited ou relled back. Does this works using jbossTM? If the session bean instance and the cmp bean live on the same JBoss server, transaction does not have to propagated, in such a case JBossTM will do just fine. The datasource to legacy will always be a local resource (since it has to be accessible by the session bean), so there will never be a need for transaction propagation there. All that the Tyrex plugin gives you is ability to propagate transaction from one JBoss server to another. Now, if I understand correctly, homogeneous deployment is when all the nodes in the cluster get identical deployments. In your case, this would mean that all the beans are on each and every node. In this scenario, a session bean instance that serves a request will always talk to its local cmp, so JBossTX will do just fine. Heterogeneous deployment is when, say your session beans are replicated across some nodes, while cmps are replicated across some other nodes. In such a case, you would have to be able to propagate transactional context across the nodes and need a Distributed TM like Tyrex. Can someone correct me if I am wrong? obs: both cmp and legacy db are Oracle. -- Anatoly --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS viewing problem from the web
Hi, guys I've been trying to look at the files in CVS through the Sourceforge CVS view but can't see any files no matter what branch option I chose. Is something screwed up with JBoss' CVS tags or Sourceforge viewer is just dumb? Any way to view the repository without downloading the whole thing? -- - Anatoly Akkerman Computer Science Dept. Courant Institute of Mathematical Sciences, NYU 715 Broadway, #719 Tel: 212 998-3493 New York, NY 10003 Fax: 212 995-4123 - --- This sf.net email is sponsored by: Jabber - The world's fastest growing real-time communications platform! Don't just IM. Build it in! http://www.jabber.com/osdn/xim ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Implementing a Resource Protection System?
marc fleury wrote: How about a PhD sub-project, Mr Akkerman, that would be a nice mbean in our system. It would have a little bit of everything, Some C, some JNI, java classes and mbean, You broadcast the information for the VM, Trust me, you will look like a king, marcf Sorry to disappoint you, Marc, but this does not scratch my itch at the moment (in fact, not pursuing PhD anymore but rather working for the research group here means I actually scratch the itches of someone else). As far as looking like a king ... well, who can look like you :) On a more serious not, if this becomes relevant to our work, me or someone else might implement this. Indeed, user-level (meaning w/o running the monitor as 'root'-equivalent) sandboxing of memory, CPU and network I/O on Win32 platform has been implemented by one of our former PhD students, so this strikes home somewhat. But we are more interested in monitoring and sandboxing invocations in component-based applications as the near-future goal (after I am done with what I am doing right now). Again, not being a good programmer, is a horrible fate in CS world, so I am slow and your guys might get to invocation flow-profiling and sandboxing before I do. Actually, have anyone done it already? (I mean writing a client-side and server-side interceptors that propagate information about the invocation itself, like which host/component the invocation is coming from?) Anatoly. --- This sf.net email is sponsored by:ThinkGeek PC Mods, Computing goodies, cases more http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Implementing a Resource Protection System?
From what I know, one can use JVMPI hooks to do fine-grained memory monitoring (http://java.sun.com/j2se/1.3/docs/guide/jvmpi/jvmpi.html). But this would involve writing some C, JNI, helper Java classes to query your custom profiling library for collected info. Depending on how well you design your library and how many profiling events you end up collecting, this may substantially slow down the JVM (just imagine the fact that you would have to call into the library every time an object is allocated or deleted, yikes). Also, once you load your library, you cannot debug this jvm remotely or profile anything in it using the standard profiling tools. - Anatoly Akkerman Computer Science Dept. Courant Institute of Mathematical Sciences, NYU 715 Broadway, #719 Tel: 212 998-3493 New York, NY 10003 Fax: 212 995-4123 - Rhett Aultman wrote: I've thought about doing this in some of the other architectures I've written from time to time. It's possible to keep an eye on memory usage and track its stats over time, so you can know when memory's becoming scarce and start telling different parts of the system Memory's tight. Can you do what you can do to lighten the load? That wasn't all that hard to do- every time this architecture deployed a job to run, it kept a handle to them and would asynchronously call a method on them that contained best effort code to lighten up the load and call the GC. That works fine when you just know that you're using more and more memory and just want to politely ask deployed code to attempt to help out. The real issue with what you're asking is, though, that I don't know that there is a way to, within a Java runtime, break down memory usage at a fine-grained level to spot a memory hog. One possible tack to take would be to make each classloader keep tabs on how many times it gets requests for object creation, but even that doesn't get you what's needed, because I'm not aware of a mechanism in place to actually chart how much memory is getting consumed by the classes instantiated out of that classloader. As far as I see, the API does not support this. The memory reporting methods are for the entire JVM, and breaking down that aggregate information by subsystem in the JVM would be tricky, if not downright impossible. -Original Message- From: Hunter Hillegas [mailto:[EMAIL PROTECTED]] Sent: Wednesday, July 10, 2002 4:12 PM To: JBoss Dev Subject: [JBoss-dev] Implementing a Resource Protection System? How hard would it be to implement some kind of resource protection system for deployed JBoss apps? I'm thinking mainly memory... Not allowing an app to continue to grab memory until the container dies, instead, shutting down that app and sending notification to an admin... Could be useful for a hosting environment... Possible? Cheers, Hunter --- This sf.net email is sponsored by:ThinkGeek Two, two, TWO treats in one. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This sf.net email is sponsored by:ThinkGeek Two, two, TWO treats in one. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This sf.net email is sponsored by:ThinkGeek Two, two, TWO treats in one. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Re: [JBoss-user] JBoss in a multi developersenvironment
mbean code=...ServiceBindingMgr name=...,service=ServiceBindingMgr ... ServerNamestarksm/ServerName /mbean while for your instance he adds: mbean code=...ServiceBindingMgr name=...,service=ServiceBindingMgr ... ServerNamedsundstrom/ServerName /mbean Now there can be a static configuration for our instances for which the client ports, address in use is invariant across instance restarts. Why not let the ServiceBindingManager autogenerate necessary config files for you (like jndi.properties or whatever else is needed)? Then use something (like a simple Java program) that talks to the ServiceBindingManager via JMXConnectors to pull the config files from the ServiceBindingManager before you start your client that uses your personal ServerName. This way, the ports can remain purely dynamic, no need for static configurations. Just my 2c. Anatoly. ___ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] JBoss JMS RA + SwiftMQ + Possible Problems
On Tue, 23 Apr 2002, Jason Dillon wrote: Looking over the last bit of this doc about Xids and JBossTX... JBossTX starts the global ID numbering from 1 each time it runs, so the global IDs are not very unique. Needless to say, this could stand some improvement. Why don't we use a org.jboss.util.id.UID or org.jboss.util.GUID here for better uniquness? Also, it refers to Tyrex, which has been integrated for a while. Does anyone know what the status of Tyrex is? Is it still being maintained? Is is a better TX manager? If so, why don't we make it the default? Tyrex works in 3.0 (at least it did about 2 months ago when I patched it up). I would not recommend Tyrex for work in distributed transactions, because it would be very slow. It should work fine as a local TM as well but, probably, it is slower than JBossTX. To get it to work you would have to tweak some build files, though, since I never had a chance to make it a SAR, the tyrex-plugin.jar does not get built, though the classes are compiled Anatoly. --jason * * * View thread online: http://jboss.org/forums/thread.jsp?forum=66thread=13848 ___ 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] JBoss JMS RA + SwiftMQ + Possible Problems
On Wed, 24 Apr 2002, Jason Dillon wrote: Tyrex works in 3.0 (at least it did about 2 months ago when I patched it up). I would not recommend Tyrex for work in distributed transactions, because it would be very slow. It should work fine as a local TM as well but, probably, it is slower than JBossTX. To get it to work you would have How much slower compaired to how much more robust? Can we fix some of its slowness? I have no idea how much slower it is. Are there any speed tests in the testsuite? I don't have lots of evidence to back this up yet... but I think our fast tx manager is not very robust and reliable... but that is just a feeling I have right now. I would rather have slower and more stable than super quick... but right now I would not trust using Tyrex, because hardly anyone uses it with JBoss. Hey, it is just a matter of trying it out. Someone has to start, the rest will follow :) Not that I'm advocating Tyrex here. It's open source (are the licenses compatible... don't know, have not cjecked what the exact license is), if it is more feature rich why don't we integrate it at the source level then work on fixing its speed issues? It is a big and complex beast. I remember digging through it when I found some bugs, shrug ... It implements all the CORBA JTA stuff for distributed TXs. I just wrote a hack to propagate the transaction context together with JBoss MethodInvocation, instead of CORBA ORB -- the way Tyrex would do it. Anatoly. ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Kindly Get Back To Me Please 24/04/02 21:22:29
Sorry to pollute the list but for those interested, check out. http://www.scamorama.com/ One guy was actually able to get $3 from one of the scammers! Amazing! - Anatoly Akkerman Computer Science Dept. Courant Institute of Mathematical Sciences, NYU 715 Broadway, #719 Tel: 212 998-3493 New York, NY 10003 Fax: 212 995-4123 - ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] JMS with JBossMQ over high latency links
Hi, guys I posted this on JMS/JBossMQ forum but it seems that posting to jboss-dev will make this issue more visible. We are trying to run an MDB that listens to a Topic on a remote JMS provider which resides across a high latency link. The behavior we encountered was that with relatively high load (about 10 or so messages/sec) the delay for all messages to reach the MDB gets to be very, very large. (We are using the 'fastest' of the IL -- OIL) I dug into the Source and realized that, perhaps, this is due to the fact that all methods that ServerIL and ClientIL interfaces expose end up being synchronized in the OIL implementation. Judging from the source, this is because in OIL you have to stuff everything down a single socket and since multiple threads have access to a JMS Connection and it has to be thread safe, synchronizing is a reasonable solution. On high latency links this is a killer, though. I am wondering how much work would it involve to write an extended OIL which can use a socket pool or something of that sort to multiplex communications better. What do you say? Anatoly Akkerman. * * * View thread online: http://main.jboss.org/thread.jsp?forum=66thread=13074 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] JSR-88 - J2EE Deployment
Has work been started on JSR-88 for jboss? View thread online: http://main.jboss.org/thread.jsp?forum=66thread=12322 I don't think so, though I am interested in contributing to it as well (it is related to my research project). I did create a toy implementation of DDBean classes but don't have a clear idea of how to proceed with the overall design. I would be very much interested in specifying an overall architecture of an implementation with people on the list. - Anatoly Akkerman Computer Science Dept. Courant Institute of Mathematical Sciences, NYU 715 Broadway, #719 Tel: 212 998-3493 New York, NY 10003 Fax: 212 995-4123 - ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Fw: [JBoss-user] Multiple JBOSS 3.0 developers andclustering
Some things have mbeans that really don't need configuration, just lifecycle services. These are good candidates for the current sar structure. TransactionManager comes to mind. Switch tm's with no code bloat just by changing jbosstm.sar to tyrextm.sar. It is important to note that several MBeans rely on presence of java:/TransactionManager in JNDI without declaring explicit dependency on the existence of TransactionManagerMBean (at the very least, it is the MQ and ContainerFactory). Also, there is another more subtle dependency where the JRMPInvokerMBean depends on TransactionPropagationContext(Importer|Factory) to be present in JNDI. This is tricky because the JBossTM registers these in TransactionManagerMBean while in my new version of Tyrex plugin (not in CVS yet, it is still being tested) these are registered in JNDI by another MBean. So given the present state of dependency tracking, there is no way of expressing this dependency to satisfy both scenarios. Ideally, there should be a way of expressing dependency on presence of objects in JNDI and the MBeans that register themselves into JNDI should state that in the service.xml (i.e. under which names they register themselves). Anatoly. ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Transaction not auto serializable
I need a few clarifications on this. DO you mean you want to have Transaction be Externalizable? So that Transaction upon externalization writes itself into the ObjectStream as a TPC? If this is what you mean, it would require wrapping any Tyrex Transaction object with a Proxy that would perform externalization? I am a bit confused here how would de-serialization happen? Anatoly On Thu, 28 Feb 2002, marc fleury wrote: Ole, I never realized this until I was working on the client interceptors yesterday late at night. Our transaction object requires an external person to serialize itself. Namely the extraction of the transaction propagation context is done outside the transaction itself. This is a problem as it means that whoever is doing the serialization (in our case the JRMPInvoker layers) MUST know about the TM and that means we need to set the transaction monitor on them somehow. It works. If however we set the static entry on the Transaction implementation then the writeObject(Stream) call could take care of it own serialization (by getting the TPC and replacing the Tx by the TPC on the stream and that would be that... I think it would be a bit more self contained from a design standpoint. This lack of containment becomes very apparent as I put an interceptor layout on top of the client layers, not a biggy just FYI 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
RE: [JBoss-dev] Transaction not auto serializable
Just the same way, we are talking about a static field for the TPC exporter and importer. The TPC importer is in the readObject and creates a local transaction object. The design for the transaction right now barfs everywhere, the transport layer has to be aware of it (ugh!) when really the transport layer should only be aware of serializable objects. in fact just have the Transaction lookup the JNDI entry for exporter and importer, that would be super sweet... neatly packaged and confined. It sort of looks bad to have an absolute unified layer and interceptors and all the modern patterns at play and then a fat if transaction Manager bla bla bla then bla bla bla in the middle of your transport layers. Does this make sense? It does make sense but here is what I don't particularly like about it, tell me if I'm wrong. I am mostly concerned about remote clients for whom the serialization actually happens. If we end up serializing this Tx Proxy with its Invoker that would actually ship only the TPC which it extracts, we would have to ship at least 1 more class on the wire (the Proxy). I don't know actually how serialization happen in terms of the class code being shipped, in which case the code for the Invoker would get shipped as well? Having a TPC and only serializing it is more lightweight (in fact, in my rewrite of Tyrex plugin I am only sending an integer, boolean and a few strings, besides other attempts to improve distributed performance). Low bandwidth connections to server is, perhaps, not on your agenda but it is something we are thinking about. Anatoly. marcf | ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Invoke returning an exception: how do you expect itto be logged?
Isn't this in a way related to making invocation results being InvocationResult objects (something similar to Invocation but on a return path). So you can stuff the resulting exception into it and let an interceptor handle display of the exception? May be I am really off here. - Anatoly Akkerman Computer Science Dept. Courant Institute of Mathematical Sciences, NYU 715 Broadway, #719 Tel: 212 998-3493 New York, NY 10003 Fax: 212 995-4123 - On Wed, 20 Feb 2002, marc fleury wrote: I think the example is well chosen, it has been annoying me for ever. Go ahead or log this as a feature request marcf |-Original Message- |From: [EMAIL PROTECTED] |[mailto:[EMAIL PROTECTED]]On Behalf Of Sacha |Labourey |Sent: Saturday, February 16, 2002 6:38 AM |To: Jboss-Dev |Subject: [JBoss-dev] Invoke returning an exception: how do you expect it |to be logged? | | |Hello, | |Currently, when a bean raised an exception, code in Container.java:invoke |catch it, log it and wrap it in an MBeanException and re-throw it. When |logging it, it uses the ERROR logging-level. | |It has some annoying consequences. For example, each time an application |perform a findByPrimaryKey for example and the bean id does not |exist, a bit |stack trace is logged (and thus displayed at the prompt). But in fact, this |is not a container issue but rather a standard bean's lifecycle issue. | |So, how do you expect exceptions to be managed by the container? | |What do you think if, in Container.java:invoke we would simply log |it at the |INFO level for example (or even DEBUG) and add more specific behaviour in |Container sub-classes (i.e. if we want to manage finder exceptions |differently for example, we should deal with this at the |EntityContainer.java level instead of the more abstract Container.java |level) | |What do you think? | |Cheers, | | | Sacha | | |___ |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] Current HEAD is missing org.jboss.util.NestedException
After Jason's commit on Feb 16, head does not compile since it is missing the class. Anatoly ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Optimizing distributed transactions and introducing InvocationResult
Hi, I've been thinking of how one could reduce network traffic in distributed transactions. This is a simple scenario of what happens in a DT: client calls Bean A which calls Bean B Bean A and Bean B live in 2 distinct servers (VMs) when client calls Bean A a transation T is started when Bean A calls Bean B, T is propagated to Bean B. According to OTS, when T is propagated to B's server, a subordinate transaction T' is started in server where Bean B lives and T' registers itself with the Coordinator for transaction T as a new Resource. This results in an additional network connection to A's server. (Since Coordinator for T lives in server A) When call to Bean B returns, T' is still present in B's server. Only when the call to Bean A returns to client and T is committed, the coordinator for transaction T does a 2pc and calls all subordinate resources (including T') to prepare() and then commit(). This is 2 additional network calls. From this example, it is aparent that T will need to know about T' only after call to Bean B returns, there is no need to know about it earlier. Unfortunately, the B's server will call the Coordinator as soon as T is propagated, when T' is created and registers itself as a subordinate. To alleviate this problem, TPC importer can fake successful registration but delay the actual registration until the return of the call to Bean B. The registration can be propagated along with the _result_ of the call to bean B, since this is a network connection to the server A anyway. This way we can cut one network connection. This raises an issue of adding payload not only to the Invocation itself but to the return from Invocation. Say we can introduce InvocationResult which can contain arbitrary payload along with the actual result of the invocation or exceptions that occured during invocation. Stripping the payload can be done by the proxy-side interceptors. In case of distributed transactions, an interceptor in the Proxy (client-side interceptors are a very smart idea :) for Bean B will perform delayed registration of subordinate transaction T' when the invocation to B returns, by extracting registration info from the payload of InvocationResult. The introduction of InvocationResult and payloads will affect performance of only unoptimized calls, since now along with the invocation result we would ship other stuff, like profiling info, etc. Supposedly, if the payloads are not excessive, this will not affect even the unoptimized calls accross the network, because latency is likely to dominate bandwidth constraints. - Anatoly Akkerman Computer Science Dept. Courant Institute of Mathematical Sciences, NYU 715 Broadway, #719 Tel: 212 998-3493 New York, NY 10003 Fax: 212 995-4123 - ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] CVS update: jboss/src/main/org/jboss/ejbEnterpriseContext.java
It appeared to me that it is only for beans that use UserTransaction,
i.e. BMT beans, the changes are made only in the UserTransactionImpl inner
class of EnterpriseContext. The tests seem to have run fine and the fix
helped removing a certain Tyrex failure (I ran testsuite with JBossTM and
then with TyrexTM, so everything should be fine).
Anatoly.
On Sun, 3 Feb 2002, marc fleury wrote:
Ok this only applies to BMT and thus Sessions right? otherwise the tx for
entity is a nightmare...
only session right?
marcf
|-Original Message-
|From: [EMAIL PROTECTED]
|[mailto:[EMAIL PROTECTED]]On Behalf Of
|Anatoly Akkerman
|Sent: Sunday, February 03, 2002 2:56 PM
|To: [EMAIL PROTECTED]
|Subject: [JBoss-dev] CVS update: jboss/src/main/org/jboss/ejb
|EnterpriseContext.java
|
|
| User: azakkerman
| Date: 02/02/03 14:55:53
|
| Modified:src/main/org/jboss/ejb EnterpriseContext.java
| Log:
| Update UserTransactionImpl to better conform to the spec
|which says that the thread has to be cleaned from the tx upon commit()
|and rollback(). In order to conform to this, we need to
|remove tx from EnterpriseContext upon commit() or rollback()
|of the UserTransaction.
|When this is done, and the BMT TxInterceptor comes to assign
|the thread that serves
|next invocation on the BMT bean to the ctx transaction, it
|gets the right 'null'
|tx.
|If this is not taken care of, some TMs (namely Tyrex)
|may fail since a committed or rolled-back tx
|from the ctx will be resumed in the BMT interceptor.
|
| Revision ChangesPath
| 1.42 +21 -3 jboss/src/main/org/jboss/ejb/EnterpriseContext.java
|
| Index: EnterpriseContext.java
| ===
| RCS file:
|/cvsroot/jboss/jboss/src/main/org/jboss/ejb/EnterpriseContext.java,v
| retrieving revision 1.41
| retrieving revision 1.42
| diff -u -r1.41 -r1.42
| --- EnterpriseContext.java 2001/12/19 05:13:37 1.41
| +++ EnterpriseContext.java 2002/02/03 22:55:53 1.42
| @@ -47,7 +47,7 @@
|* @author a
|href=mailto:[EMAIL PROTECTED];Sebastien Alborini/a
|* @author a href=mailto:[EMAIL PROTECTED];Juha Lindfors/a
|* @author a href=mailto:[EMAIL PROTECTED];Ole Husgaard/a
| - * @version $Revision: 1.41 $
| + * @version $Revision: 1.42 $
|*
|* Revisions:
|* 2001/06/29: marcf
| @@ -434,13 +434,31 @@
|java.lang.IllegalStateException,
|SystemException
| {
| - con.getTransactionManager().commit();
| + try {
| + con.getTransactionManager().commit();
| + } finally {
| + // According to the spec, after commit and rollback
|was called on
| + // UserTransaction, the thread is associated with no
|transaction.
| + // Since the BMT Tx interceptor will associate the
|thread from the context
| + // with the thread that comes in on an invocation,
|we must set the
| + // context transaction to null
| + setTransaction(null);
| + }
| }
|
| public void rollback()
|throws IllegalStateException, SecurityException,
|SystemException
| {
| - con.getTransactionManager().rollback();
| + try {
| + con.getTransactionManager().rollback();
| + } finally {
| + // According to the spec, after commit and rollback
|was called on
| + // UserTransaction, the thread is associated with no
|transaction.
| + // Since the BMT Tx interceptor will associate the
|thread from the context
| + // with the thread that comes in on an invocation,
|we must set the
| + // context transaction to null
| + setTransaction(null);
| + }
| }
|
| public void setRollbackOnly()
|
|
|
|
|___
|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: thirdparty/sun/jts/lib jts.jar
User: azakkerman Date: 02/02/03 09:53:01 Modified:sun/jts/lib jts.jar Log: Sun's distribution of jts did not have some of source files compiled. This is an updated jts jar with the appropriate files compiled. These classes were needed for Tyrex plugin compilation. Revision ChangesPath 1.2 +500 -226 thirdparty/sun/jts/lib/jts.jar Binary file ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: contrib/varia/src/main/org/jboss/tm/plugins/tyrex ResourceInvoker.java TransactionManagerService.java TransactionManagerServiceMBean.java TyrexTransactionPropagationContextManager.java TyrexTxPropagationContext.java
User: azakkerman
Date: 02/02/03 12:14:59
Modified:varia/src/main/org/jboss/tm/plugins/tyrex
ResourceInvoker.java TransactionManagerService.java
TransactionManagerServiceMBean.java
TyrexTransactionPropagationContextManager.java
TyrexTxPropagationContext.java
Log:
Update of Tyrex plugin sources for JBoss 3.0
Revision ChangesPath
1.3 +11 -8
contrib/varia/src/main/org/jboss/tm/plugins/tyrex/ResourceInvoker.java
Index: ResourceInvoker.java
===
RCS file:
/cvsroot/jboss/contrib/varia/src/main/org/jboss/tm/plugins/tyrex/ResourceInvoker.java,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- ResourceInvoker.java 2001/09/01 19:50:29 1.2
+++ ResourceInvoker.java 2002/02/03 20:14:58 1.3
@@ -18,7 +18,9 @@
import java.io.Externalizable;
import java.io.IOException;
+import org.apache.log4j.Category;
+
/**
* This is the InvocationHandler for the Proxy we hand over to the
* originator's Coordinator to control our subordinate transaction
@@ -29,7 +31,7 @@
*ResourceRemote,
*CoordinatorRemote
* @author a href=mailto:[EMAIL PROTECTED];Anatoly Akkerman/a
- * @version $Revision: 1.2 $
+ * @version $Revision: 1.3 $
*/
public class ResourceInvoker implements InvocationHandler, Externalizable {
@@ -54,6 +56,7 @@
}
}
+ private Category log = Category.getInstance(this.getClass());
private ResourceRemoteInterface remoteResource;
public ResourceInvoker() {
@@ -66,7 +69,7 @@
} catch (Exception e) {
e.printStackTrace();
remoteResource = null;
- Logger.warning(ResourceInvoker did not initialize properly! Ther will be
problems with this transaction!);
+ log.warn(ResourceInvoker did not initialize properly! Ther will be problems
with this transaction!);
}
}
@@ -83,26 +86,26 @@
// Just call the appropriate method on our RemoteCoordinator
if (method.equals(prepare)) {
- // DEBUG Logger.debug(ResourceInvoker: calling prepare());
+ // DEBUG log.debug(ResourceInvoker: calling prepare());
return remoteResource.prepare();
}
else if (method.equals(rollback)) {
- // DEBUG Logger.debug(ResourceInvoker: calling rollback());
+ // DEBUG log.debug(ResourceInvoker: calling rollback());
remoteResource.rollback();
return null;
}
else if (method.equals(commit)) {
- // DEBUG Logger.debug(ResourceInvoker: calling commit());
+ // DEBUG log.debug(ResourceInvoker: calling commit());
remoteResource.commit();
return null;
}
else if (method.equals(commit_one_phase)) {
- // DEBUG Logger.debug(ResourceInvoker: calling commit_one_phase());
+ // DEBUG log.debug(ResourceInvoker: calling commit_one_phase());
remoteResource.commit_one_phase();
return null;
}
else if (method.equals(forget)) {
- // DEBUG Logger.debug(ResourceInvoker: calling forget());
+ // DEBUG log.debug(ResourceInvoker: calling forget());
remoteResource.forget();
return null;
}
@@ -110,4 +113,4 @@
throw new Exception(ResourceInvoker: called through an unknown method!);
}
}
-}
\ No newline at end of file
+}
1.5 +16 -8
contrib/varia/src/main/org/jboss/tm/plugins/tyrex/TransactionManagerService.java
Index: TransactionManagerService.java
===
RCS file:
/cvsroot/jboss/contrib/varia/src/main/org/jboss/tm/plugins/tyrex/TransactionManagerService.java,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -r1.4 -r1.5
--- TransactionManagerService.java2001/10/20 21:01:43 1.4
+++ TransactionManagerService.java2002/02/03 20:14:58 1.5
@@ -26,8 +26,10 @@
import tyrex.tm.TransactionDomain;
import org.omg.CosTransactions.TransactionFactory;
-import org.jboss.util.ServiceMBeanSupport;
+import org.jboss.system.ServiceMBeanSupport;
+import org.apache.log4j.Category;
+
/**
* This is a JMX service which manages the Tyrex TransactionManager
(tyrex.exolab.org).
* The service creates it and binds a Reference to it into JNDI. It also
initializes
@@ -35,12 +37,14 @@
*
* @see TyrexTransactionPropagationContextManager, tyrex.tm.TransactionDomain
* @author a href=mailto:[EMAIL PROTECTED];Anatoly Akkerman/a
- * @version $Revision: 1.4 $
+ * @version $Revision: 1.5 $
*/
public class TransactionManagerService
extends ServiceMBeanSupport
implements TransactionManagerServiceMBean
[JBoss-dev] CVS update: contrib/varia build.xml
User: azakkerman
Date: 02/02/03 12:16:25
Modified:variabuild.xml
Log:
Update build file to compile Tyrex plugin.
Revision ChangesPath
1.14 +4 -2 contrib/varia/build.xml
Index: build.xml
===
RCS file: /cvsroot/jboss/contrib/varia/build.xml,v
retrieving revision 1.13
retrieving revision 1.14
diff -u -r1.13 -r1.14
--- build.xml 2001/12/06 02:16:09 1.13
+++ build.xml 2002/02/03 20:16:25 1.14
@@ -12,7 +12,7 @@
!----
!-- == --
-!-- $Id: build.xml,v 1.13 2001/12/06 02:16:09 user57 Exp $ --
+!-- $Id: build.xml,v 1.14 2002/02/03 20:16:25 azakkerman Exp $ --
project default=main name=JBoss Plugins/Varia
@@ -314,8 +314,10 @@
include name=${javac.includes}/
exclude name=${javac.excludes}/
- !-- Tyrex plugin does not compile currently. --
+ !--
+ Tyrex should compile now
exclude name=org/jboss/tm/plugins/tyrex/**/
+ --
/javac
/target
___
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 AbstractTxInterceptorBMT.java
User: azakkerman Date: 02/02/03 12:18:54 Modified:src/main/org/jboss/ejb/plugins AbstractTxInterceptorBMT.java Log: Fix a problem with resuming null transactions (Tyrex can't do this) Accidentally, this has helped somehow to fix a few errors in the testsuite. Revision ChangesPath 1.7 +4 -2 jboss/src/main/org/jboss/ejb/plugins/AbstractTxInterceptorBMT.java Index: AbstractTxInterceptorBMT.java === RCS file: /cvsroot/jboss/jboss/src/main/org/jboss/ejb/plugins/AbstractTxInterceptorBMT.java,v retrieving revision 1.6 retrieving revision 1.7 diff -u -r1.6 -r1.7 --- AbstractTxInterceptorBMT.java 2001/12/19 05:36:53 1.6 +++ AbstractTxInterceptorBMT.java 2002/02/03 20:18:53 1.7 @@ -29,7 +29,7 @@ * A common superclass for the BMT transaction interceptors. * * @author a href=mailto:[EMAIL PROTECTED];Ole Husgaard/a - * @version $Revision: 1.6 $ + * @version $Revision: 1.7 $ */ abstract class AbstractTxInterceptorBMT extends AbstractTxInterceptor @@ -131,7 +131,9 @@ Transaction beanTx = ctx.getTransaction(); // Resume the bean instance transaction - tm.resume(beanTx); + // only if it not null, some TMs can't resume(null), e.g. Tyrex + if (beanTx != null) + tm.resume(beanTx); // Let the MI know about our new transaction mi.setTransaction(beanTx); ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jboss/src/etc/conf/default jboss-service.xml
User: azakkerman Date: 02/02/03 12:22:15 Modified:src/etc/conf/default jboss-service.xml Log: Added more comments about using Tyrex TM plugin. Revision ChangesPath 1.26 +4 -1 jboss/src/etc/conf/default/jboss-service.xml Index: jboss-service.xml === RCS file: /cvsroot/jboss/jboss/src/etc/conf/default/jboss-service.xml,v retrieving revision 1.25 retrieving revision 1.26 diff -u -r1.25 -r1.26 --- jboss-service.xml 2002/01/29 21:12:23 1.25 +++ jboss-service.xml 2002/02/03 20:22:15 1.26 @@ -1,6 +1,6 @@ ?xml version=1.0 encoding=UTF-8? !DOCTYPE server -!-- $Id: jboss-service.xml,v 1.25 2002/01/29 21:12:23 d_jencks Exp $ -- +!-- $Id: jboss-service.xml,v 1.26 2002/02/03 20:22:15 azakkerman Exp $ -- !-- = -- !-- -- @@ -84,6 +84,9 @@ | Uncomment to use Tyrex (tyrex.exolab.org) transaction manager plugin | instead of the org.jboss.tm.TransactionManagerService and comment out | the TransactionManagerService above. + | Make sure you have Xerces in lib/ext. At the moment JBoss does not + | ship Xerces as part of distribution. Version 1.x seems to work fine, + | though 2.x should as well, use whichever you like. | mbean code=org.jboss.tm.plugins.tyrex.TransactionManagerService name=jboss:service=TransactionManager ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jboss/src/main/org/jboss/ejb EnterpriseContext.java
User: azakkerman
Date: 02/02/03 14:55:53
Modified:src/main/org/jboss/ejb EnterpriseContext.java
Log:
Update UserTransactionImpl to better conform to the spec
which says that the thread has to be cleaned from the tx upon commit()
and rollback(). In order to conform to this, we need to
remove tx from EnterpriseContext upon commit() or rollback() of the
UserTransaction.
When this is done, and the BMT TxInterceptor comes to assign the thread that serves
next invocation on the BMT bean to the ctx transaction, it gets the right 'null'
tx.
If this is not taken care of, some TMs (namely Tyrex)
may fail since a committed or rolled-back tx
from the ctx will be resumed in the BMT interceptor.
Revision ChangesPath
1.42 +21 -3 jboss/src/main/org/jboss/ejb/EnterpriseContext.java
Index: EnterpriseContext.java
===
RCS file: /cvsroot/jboss/jboss/src/main/org/jboss/ejb/EnterpriseContext.java,v
retrieving revision 1.41
retrieving revision 1.42
diff -u -r1.41 -r1.42
--- EnterpriseContext.java2001/12/19 05:13:37 1.41
+++ EnterpriseContext.java2002/02/03 22:55:53 1.42
@@ -47,7 +47,7 @@
* @author a href=mailto:[EMAIL PROTECTED];Sebastien Alborini/a
* @author a href=mailto:[EMAIL PROTECTED];Juha Lindfors/a
* @author a href=mailto:[EMAIL PROTECTED];Ole Husgaard/a
- * @version $Revision: 1.41 $
+ * @version $Revision: 1.42 $
*
* Revisions:
* 2001/06/29: marcf
@@ -434,13 +434,31 @@
java.lang.IllegalStateException,
SystemException
{
- con.getTransactionManager().commit();
+ try {
+ con.getTransactionManager().commit();
+ } finally {
+ // According to the spec, after commit and rollback was called on
+ // UserTransaction, the thread is associated with no transaction.
+ // Since the BMT Tx interceptor will associate the thread from the
context
+ // with the thread that comes in on an invocation, we must set the
+ // context transaction to null
+ setTransaction(null);
+ }
}
public void rollback()
throws IllegalStateException, SecurityException, SystemException
{
- con.getTransactionManager().rollback();
+ try {
+ con.getTransactionManager().rollback();
+ } finally {
+ // According to the spec, after commit and rollback was called on
+ // UserTransaction, the thread is associated with no transaction.
+ // Since the BMT Tx interceptor will associate the thread from the
context
+ // with the thread that comes in on an invocation, we must set the
+ // context transaction to null
+ setTransaction(null);
+ }
}
public void setRollbackOnly()
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jboss/src/main/org/jboss/ejb EnterpriseContext.java
User: azakkerman
Date: 02/02/03 14:59:11
Modified:src/main/org/jboss/ejb EnterpriseContext.java
Log:
Fixed some typos in the comment and made it a little more
readable, I hope :)
Revision ChangesPath
1.43 +7 -7 jboss/src/main/org/jboss/ejb/EnterpriseContext.java
Index: EnterpriseContext.java
===
RCS file: /cvsroot/jboss/jboss/src/main/org/jboss/ejb/EnterpriseContext.java,v
retrieving revision 1.42
retrieving revision 1.43
diff -u -r1.42 -r1.43
--- EnterpriseContext.java2002/02/03 22:55:53 1.42
+++ EnterpriseContext.java2002/02/03 22:59:11 1.43
@@ -47,7 +47,7 @@
* @author a href=mailto:[EMAIL PROTECTED];Sebastien Alborini/a
* @author a href=mailto:[EMAIL PROTECTED];Juha Lindfors/a
* @author a href=mailto:[EMAIL PROTECTED];Ole Husgaard/a
- * @version $Revision: 1.42 $
+ * @version $Revision: 1.43 $
*
* Revisions:
* 2001/06/29: marcf
@@ -439,9 +439,9 @@
} finally {
// According to the spec, after commit and rollback was called on
// UserTransaction, the thread is associated with no transaction.
- // Since the BMT Tx interceptor will associate the thread from the
context
- // with the thread that comes in on an invocation, we must set the
- // context transaction to null
+ // Since the BMT Tx interceptor will associate and resume the tx
+ // from the context with the thread that comes in
+ // on a subsequent invocation, we must set the context transaction to
null
setTransaction(null);
}
}
@@ -454,9 +454,9 @@
} finally {
// According to the spec, after commit and rollback was called on
// UserTransaction, the thread is associated with no transaction.
- // Since the BMT Tx interceptor will associate the thread from the
context
- // with the thread that comes in on an invocation, we must set the
- // context transaction to null
+ // Since the BMT Tx interceptor will associate and resume the tx
+ // from the context with the thread that comes in
+ // on a subsequent invocation, we must set the context transaction to
null
setTransaction(null);
}
}
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Source code editors
Try AnyJ, unless you are doing commercial development it is free. It is also free for evaluation. See their license. The IDE is quite fast (way much smaller than JBuilder) and has some very useful features. I think, I've heard about it from Marc in one of his e-mails. - Anatoly Akkerman Computer Science Dept. Courant Institute of Mathematical Sciences, NYU 715 Broadway, #719 Tel: 212 998-3493 New York, NY 10003 Fax: 212 995-4123 - ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] java.io.NotSerializableException: org.jboss.jetty.JBossUserRealm
Jules, the fix is very easy, you don't have to make JBossUserRealm serializable, instead, when you do SecurityAssociation.setPrincipal() don't pass it 'this' which is JBossUserPrincipal, rather pass along a new SimplePrincipal() which corresponds to the name stored in JBossUserPrincipal. The JBoss security infrastructure only checks the name, the Principal object does not have to be the same everytime. Doublecheck with Scott but this fix worked nicely for me. - Anatoly Akkerman Computer Science Dept. Courant Institute of Mathematical Sciences, NYU 715 Broadway, #719 Tel: 212 998-3493 New York, NY 10003 Fax: 212 995-4123 - On Sat, 12 Jan 2002, Jules Gosnell wrote: Marc, My understanding of this Exception popping up in the web testsuite was that serialisation was occuring because optimisation was not. Therefore I have not invested time in the alterations to JBossUserRealm to make it Serializable. What is the situation here? Is this still the case - or does it have to be Serialisable ? Jules 13:50:14,485 INFO [Jetty] SecureEJBServlet: init 13:50:14,628 ERROR [StatelessSessionContainer] invoke returned an exception java.io.NotSerializableException: org.jboss.jetty.JBossUserRealm at java.io.ObjectOutputStream.outputObject(ObjectOutputStream.java:1148) at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:366) at java.io.ObjectOutputStream.outputClassFields(ObjectOutputStream.java:1827) at java.io.ObjectOutputStream.defaultWriteObject(ObjectOutputStream.java:480) at java.io.ObjectOutputStream.outputObject(ObjectOutputStream.java:1214) at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:366) at java.rmi.MarshalledObject.init(MarshalledObject.java:95) at org.jboss.invocation.MarshalledInvocation.writeExternal(MarshalledInvocation.java:312) at java.io.ObjectOutputStream.outputObject(ObjectOutputStream.java:1172) at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:366) at java.rmi.MarshalledObject.init(MarshalledObject.java:95) at org.jboss.ejb.Container.invoke(Container.java:648) at com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1555) at com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1523) at org.jboss.invocation.local.LocalInvoker.invoke(LocalInvoker.java:113) at org.jboss.invocation.jrmp.interfaces.JRMPInvokerProxy.invoke(JRMPInvokerProxy.java:149) at org.jboss.proxy.ejb.GenericProxy.invoke(GenericProxy.java:182) at org.jboss.proxy.ejb.HomeProxy.invoke(HomeProxy.java:194) at $Proxy17.create(Unknown Source) at org.jboss.test.web.servlets.SecureEJBServlet.processRequest(SecureEJBServlet.java:51) at org.jboss.test.web.servlets.SecureEJBServlet.doGet(SecureEJBServlet.java:79) at javax.servlet.http.HttpServlet.service(HttpServlet.java:740) at javax.servlet.http.HttpServlet.service(HttpServlet.java:853) at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:291) at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:542) at org.mortbay.http.HttpContext.handle(HttpContext.java:1265) at org.mortbay.http.HttpContext.handle(HttpContext.java:1219) at org.mortbay.http.HttpServer.service(HttpServer.java:725) at org.mortbay.http.HttpConnection.service(HttpConnection.java:745) at org.mortbay.http.HttpConnection.handleNext(HttpConnection.java:918) at org.mortbay.http.HttpConnection.handle(HttpConnection.java:760) at org.mortbay.http.SocketListener.handleConnection(SocketListener.java:138) at org.mortbay.util.ThreadedServer.handle(ThreadedServer.java:287) at org.mortbay.util.ThreadPool$JobRunner.run(ThreadPool.java:715) at java.lang.Thread.run(Thread.java:484) 13:50:14,632 WARN [Jetty] WARNING: Servlet Exception for /jbosstest/restricted/SecureEJBAccess java.lang.reflect.UndeclaredThrowableException: java.io.NotSerializableException: org.jboss.jetty.JBossUserRealm no stack trace available 13:50:19,504 INFO [JBossUserRealm#JBossTest Servlets] JBossUserPrincipal: jduke _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.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] UserRealm, SimplePrincipal JBoss/Jetty integration....
IMHO, the JBossUserPrincipal has to be serializable. You can't always assume that the bean invocations from the web tier will be local. Be that for clustering or whatever. My current project is wide-area distribution of j2ee apps, where we take an EAR configured to run on a single node and 'stretch' it accross a bunch of nodes, so we end up with having web tier doing remote invocations on the beans. True, this is non-production feature and quite inefficient at the moment but that is the whole purpose of research, to make it better. So, stick to serializable, please. - Anatoly Akkerman Computer Science Dept. Courant Institute of Mathematical Sciences, NYU 715 Broadway, #719 Tel: 212 998-3493 New York, NY 10003 Fax: 212 995-4123 - On Wed, 2 Jan 2002, Adrian Brock wrote: Hi, Oops, should have said JRMPInvokerProxy. There might still be some bizarre case where it needs to go over a wire. But, I would have thought the servlet always wants to invoke a local bean. That's the whole point of web integration isn't it? Regards, Adrian __ View this jboss-dev thread in the online forums: http://jboss.org/forums/thread.jsp?forum=66thread=6446 ___ 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] UserRealm, SimplePrincipal JBoss/Jetty integration....
Hi, Jules, I've used the following hack, which, in fact worked. In JBossUserPrincipal, where you set SecurityAssociation, instead of setting the principal to 'this', set it to 'new SimplePrincipal(this.getName())'. JBoss security checking will not care if it is a new object every time. Another question. I am having trouble with env being not bound with the new Jetty from CVS. (Meaning, when a WAR gets deployed, it does not see ejb-ref if the JNDI name is in the comp/env space.) I used to have this problem some time before but syncing with the latest JBoss CVS fixed it. Would you happen to know why this happens? I really need to get this to work... Anatoly. On Wed, 2 Jan 2002, Jules Gosnell wrote: For the moment, I am not implementing the Security integration between Jetty and JBoss as Serializable. I understand why you feel it should be a requirement for the future, and agree with you. Unfortunately, it is not simply a case of shipping a string since the same Principal object has to be useful within Jetty, which expects it to have behaviour based on state which is not so easily serializable. Provided that the completion of the ClassLoader work will resolve the immediate issue of the testsuite failing here I shall put it on my todo list and tackle it next time I revisit the security integration. If anyone feels there is good reason for this to be prioritised more highly, please let me know. ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] More Jetty security problems
Hello all interested I've managed to get past this item as well. On every authentication I don't set JBossUserPrincipal to be the principal registered with the SecurityAssociation, rather I create a new SimplePrincipal (which is Serializable, while JBossUserPrincipal is not) and stuff works. (It seems to me that the Serialization exception was coming up when an EJB proxy would try to do an invocation and pass along the current Principal held in ThreadLocal by SecurityAssociation, but JBossUserPrincipal is not Serializable) At the moment I am just interested in getting my demo to work but would gladly commit my hack to the CVS. Though, it seems to me, the Jetty/JBoss security integration has to be cleaned up anyway. Anatoly. On Sun, 30 Dec 2001, Anatoly Akkerman wrote: Hi, I've tweaked the JBossUserRealm and its inner class JBossUserPrincipal to authenticate with JBoss on every request. It seems to check the roles properly but now it fails with the following error: 18:34:14,585 WARN [Jetty] WARNING: Servlet Exception for /d-module-3/control/signin java.lang.reflect.UndeclaredThrowableException: java.io.NotSerializableException : org.jboss.jetty.JBossUserRealm no stack trace available Now I am stuck without knowing where to look next to figure out what's going on. Any suggestions how to turn on Jetty debugging? (I could not find anything in Jetty MBean interface or in jetty.xml inside the sar) Thanks in advance. - Anatoly Akkerman Computer Science Dept. Courant Institute of Mathematical Sciences, NYU 715 Broadway, #719 Tel: 212 998-3493 New York, NY 10003 Fax: 212 995-4123 - ___ 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] More Jetty security problems
Hi, I've tweaked the JBossUserRealm and its inner class JBossUserPrincipal to authenticate with JBoss on every request. It seems to check the roles properly but now it fails with the following error: 18:34:14,585 WARN [Jetty] WARNING: Servlet Exception for /d-module-3/control/signin java.lang.reflect.UndeclaredThrowableException: java.io.NotSerializableException : org.jboss.jetty.JBossUserRealm no stack trace available Now I am stuck without knowing where to look next to figure out what's going on. Any suggestions how to turn on Jetty debugging? (I could not find anything in Jetty MBean interface or in jetty.xml inside the sar) Thanks in advance. - Anatoly Akkerman Computer Science Dept. Courant Institute of Mathematical Sciences, NYU 715 Broadway, #719 Tel: 212 998-3493 New York, NY 10003 Fax: 212 995-4123 - ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [jetty-discuss] Re: [JBoss-dev] Jetty security problem
ERROR [Default] at org.mortbay.http.SocketListener.handleConnection(SocketListener.java:138) 2001-12-27 17:47:08,996 ERROR [Default] at org.mortbay.util.ThreadedServer.handle(ThreadedServer.java:287) 2001-12-27 17:47:08,996 ERROR [Default] at org.mortbay.util.ThreadPool$JobRunner.run(ThreadPool.java:715) 2001-12-27 17:47:08,996 ERROR [Default] at java.lang.Thread.run(Unknown Source) 2001-12-27 17:47:08,996 INFO [org.jboss.security.plugins.JaasSecurityManager.other] JaasSecurityManager: checking roles for active subject: null for thread SocketListener-1|0|Socket[addr=127.0.0.1/127.0.0.1,port=3791,localport=8080] 2001-12-27 17:47:08,996 INFO [Default] JaasSecurityManager: checking role null 2001-12-27 17:47:08,996 WARN [org.jboss.jetty.JBossUserRealm#default] JBossUserPrincipal: j2ee is NOT in Role: customer 2001-12-27 17:47:08,996 INFO [org.jboss.jetty.JBossUserRealm#default] JBossUserPrincipal: getting curr subj: null 2001-12-27 17:47:08,996 INFO [org.jboss.jetty.JBossUserRealm#default] Current thread: SocketListener-1|0|Socket[addr=127.0.0.1/127.0.0.1,port=3791,localport=8080] 2001-12-27 17:47:08,996 WARN [org.jboss.jetty.Jetty] WARNING: AUTH FAILURE: role for j2ee As you can see, SocketListener 3 did authentication, while SocketListener1 is doing role checking. Does it make sense to store the user credentials is the JBossUserPrincipal and in isUserInRole() do authentication again? This will set the thread association with proper security context. I don't know, though, how to unset this once the thread is done processing the request. Well firstly I'm going to say that we have been having problems with jboss role based authentication for some time. It is not something that we want to get wrong, so I think the time has long since passed where we need a good set of regression tests for this. Now, while I can see that subsequent requests will be in different threads - I cannot see where the second thread is coming from within the same request Nowhere in the Jetty handling or the JBoss adaptor is a new thread created, let alone for a call to the authentication API? Likewise, I do not create any extra threads in the integration code. Perhaps the Servlet itself is creating it ? Is it demonstrating programmatic security rather than declarative ? If so, then this is a problem, unless security info attached to primary request threads can be transparently inherited, in user code, by it's child threads Jules As the JBoss JaasSecurityManager class appears to use ThreadLocals to store authentication results then the solution may have to be to authenticate every request rather than just relying on the contents of a session to show that it has previously been authenticated. Note this probably means that we also have to deauthenticate threads when they are returned to the thread pool.I can't see how Jetty can help much here, as ThreadLocals are beyond it's control and can't be cleared by it. I would say that adorning Threads with security priviledges does not sound too robust in any environment that uses thread pools (Ie almost any servlet container). I don't know enough about the jboss authentication mechanism to really comment more - but I'll repeat that we should make security issues top priority. regards Julian Gosnell wrote: Anatoly, Thanks for the precise description of the problem. I shall take a look at this as soon as I find the time. Probably during the first week of Jan or so. Greg, Any thoughts about this before I plunge in ? Jules Anatoly Akkerman wrote: Hi, guys I am running into problems with Jetty + JBoss 3.0alpha After some debugging here is what I have. Setup: Jetty + JBoss 3.0 Sun's Petstore 1.1.1 deployed piecewise (meaning each EJB and WAR are packaged separately and deployed in a J2eeScopedDeployer) JBossSX configured to pick up usernames, password and roles from files Here is what happens: 1) a servlet in Petstore takes username and password from a Web form and sets j_username and j_password in the session. Jetty seems to pick this stuff up and pass it to JBossUserRealm to authenticate the user. JbossUserPrincipal gets created and then proceeds to authenticate with with _securityMgr (which is JaasSecurityManager java:/jaas/other). Authentication succeeds, I see a log and I did doublecheck that JaasSecurityManager sets activeSubject to this authenticated subject. 2) Then, it seems, Jetty proceeds to check that this user has required roles. It first calls JbossUserRealm.getUser(name) to obtain the JBossUserPricipal and then calls isUserInRole(String role). This is where the stuff fails miserably. The reason being that Jetty dispatched a different thread to do role checking than the one that did authentication. Because of this, JaasSecurityManager sees a null
[JBoss-dev] Jetty security problem
Hi, guys I am running into problems with Jetty + JBoss 3.0alpha After some debugging here is what I have. Setup: Jetty + JBoss 3.0 Sun's Petstore 1.1.1 deployed piecewise (meaning each EJB and WAR are packaged separately and deployed in a J2eeScopedDeployer) JBossSX configured to pick up usernames, password and roles from files Here is what happens: 1) a servlet in Petstore takes username and password from a Web form and sets j_username and j_password in the session. Jetty seems to pick this stuff up and pass it to JBossUserRealm to authenticate the user. JbossUserPrincipal gets created and then proceeds to authenticate with with _securityMgr (which is JaasSecurityManager java:/jaas/other). Authentication succeeds, I see a log and I did doublecheck that JaasSecurityManager sets activeSubject to this authenticated subject. 2) Then, it seems, Jetty proceeds to check that this user has required roles. It first calls JbossUserRealm.getUser(name) to obtain the JBossUserPricipal and then calls isUserInRole(String role). This is where the stuff fails miserably. The reason being that Jetty dispatched a different thread to do role checking than the one that did authentication. Because of this, JaasSecurityManager sees a null activeSubject and says that the user does not have required roles. Now, this happens in a _single_ http request from a web client (just clicked 'login' button on a form). I can try hacking a workaround just for my demo to work but would like to help fixing this if it is a bug. - Anatoly Akkerman Computer Science Dept. Courant Institute of Mathematical Sciences, NYU 715 Broadway, #719 Tel: 212 998-3493 New York, NY 10003 Fax: 212 995-4123 - ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Screwed up TxInterceptor
Here is the description of the problem. tx -- javax.transactins.Transaction interface tm -- javax.transaction.TransactionManager interface First differences between Tyrex and JBossTM JBossTM |Tyrex tm.resume(null) ok |throws exception --- tx.commit() same as tm.commit() |only commits the tx i.e. drops the thread |does not drop thread association with tx |association same goes for tx.rollback() 1. When a thread comes in into TxInterceptorCMT the threadTx is suspended and then resumed [b]_only_[/b] if it is not null (in 'finally' block). (Note: we must check for it not to be null, because Tyrex throws exception, actually the current code checks for this problem in some but not all places, see the last paragraph). 2. In TX_REQUIRED, if the method invocation came w/o transaction (oldTransaction == null) we start a new transaction. Then, in 'finally' block we try to commit this transaction through Transaction.commit(). I understand why we don't use TransactionManager.commit(), because our thread may no longer be associated with the newTransaction. Problem arises with Tyrex when (This happened when a servlet in Jetty was calling 2 methods of a bean consequently) Thread T calls a bean 2 times, both methods have TX_REQUIRED. Initially thread T is not associated with a transaction (i.e. threadTx is null) invocation 1 GenericProxy gets current thread transaction (null) and invokes the bean. oldTransaction is null, thus according to (2) newTransaction (Tx1) is started and then committed through Transaction.commit(). Thread T is still associated with Tx1 if Tyrex is the TM. When we reach 'finally' block that has to reinstate the threadTx, nothing happens because threadTx is null, so T leaves the interceptor associated with Tx1 which is committed. invocation 2 GenericProxy gets the transaction associated with the current thread, i.e. Tx1 and calls the bean with this tx context. oldTransaction == Tx1, the transaction manager tries to resume the transaction --- Exception, the transaction is already committed. So, the lesson is, the thread has to leave the interceptor with exactly the same tx association it came in. Because threadTx can be null, we don't always resume threadTx, so if threadTx was null when the thread came in, it must be null when the thread leaves, so if the transaction manager does not clean tx thread association through Transaction.commit() and Transaction.rollback(), it must be cleaned by the interceptor through tm.suspend() to make threadTx null again. The changes to the interceptor are trivial (always call tm.suspend, even if committing or rolling back the new transcation). Also, in TX_SUPPORTS, there has to be if (oldTransaction != null) guard befor tm.resume(oldTransaction) is called, otherwise Tyrex is pissed off :) Hope the explanation is clear. - Anatoly Akkerman Computer Science Dept. Courant Institute of Mathematical Sciences, NYU 715 Broadway, #719 Tel: 212 998-3493 New York, NY 10003 Fax: 212 995-4123 - ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: RE: [JBoss-dev] Screwed up TxInterceptor
This is to make it more readable on Forums, the differences between JBossTM and Tyrex Sorry the table is not viewable in Forums - tm.resume(null) JBossTM -- ok Tyrex -- throws Exception - tx.commit() JBossTM same result as tm.commit(), i.e. drops thread association Tyrex only commits the tx, does not drop thread association with the transaction same goes for tx.rollback() __ View this jboss-dev thread in the online forums: http://jboss.org/forums/thread.jsp?forum=66thread=5820 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: RE: [JBoss-dev] Screwed up TxInterceptor
Thread association is an implicit system level way to carry a transaction or for
that matter any other object (think security). Its sole purpose in life is to pass
*random* information through a typed interface. e.g. the association of the tx to the
thread permits us to read that information behind the wall of the API, even if the
API doesn't explicitely declare that information.
This is a system construct, superior for example to the lame duck aka JINI that
calls for explicit coding of tx in the API doSomething(..., TX).
FINE, however we have a superior way to do it in JBoss, we can pass the transaction
information THROUGH the API in the INVOCATION. THEREFORE building anything that
relies on the system presence of the association assumes that all parties are doing
the right thing with that association, which is not the case here.
We work from the tx in the message.
The rest is TM specific quirks
This seems not precise. Indeed, once a MethodInvocation is constructed,
the tx context is passed along and the system is aware about it. There is
one place where the tx context is not taken from the MethodInvocation,
namely, when the MethodInvocation itself is created (In
GenericProxy.getTransaction() {
return (tm == null) ? null : tm.getTransaction();
}
So, after we come back to the Proxy from an invocation we better preserve
the threadTx, because the next time around it is going to get passed as
part of MI. The problem I was experiencing is with non-preservation of
null transaction.
In the early EJBoss I separated these calls into tx.commit/tx.rollback and then
suspendAssociation resumeAssociation, because that semantic is clearer than the
fuzzy if you commit with this or that we dis-associate and what not.
At this point a simple way to solve this is to explicitely dis-associate thread if
the tx is demarcated (commit/rollback)
I remember this code but to integrate any
javax.transactions.TransactionManager, we had to do away with it and be
JTA-compliant.
The Transacation manager interprets the fuzzy resume however it wants, resume
should only be an association of the tx to the thread and basta, nothing else, it
should not *think* about the status of the tx at all i have argued in the past with
OLE that THIS IS NOT A LIFECYCLE EVENT ON THE TRANSACTION, CLEARLY CLEARLY CLEARLY,
SO THE TM SHOULD NOT THINK ABOUT THE TX IT SHOULD JUST RESUME
ASSOCIATION.
Sorry to talk all in cap my keyboard got stuck.
So, the lesson is,
JTA/TM is a crappy spec interpreted left and right ?
I should be on that commitee writing the transaction spec and I would clean up this
clear mess.
Well, I am not going to try to make every TM-vendor be compliant to a
non-existent spec of MF :)
Just trying to make the interceptor more robust to various spec
interpretations
the thread has to leave the
interceptor with exactly
the same tx association it came in. Because threadTx
can be null, we don't
always resume threadTx, so if threadTx was null when
the thread came in,
it must be null when the thread leaves, so if the
transaction manager does
not clean tx thread association through
Transaction.commit() and
Transaction.rollback(), it must be cleaned by the
interceptor through
tm.suspend() to make threadTx null again.
Yes that would work, always dis-associating the thread if commited/rollback seems
like a good idea, making that call explicit as opposed to buried in the
interpretations of the spec is a good idea,
The changes to the interceptor are trivial (always
call tm.suspend, even
if committing or rolling back the new transcation).
No, be careful there cowboy do you really want to call suspend() (in
the dis-association sense) if your transaction is not commited? Could
be. In jboss it is the recommend way because we pass the information
explicitely, in integration with other parties... I don't know, if
they take our information ok if not they will rely on the system level
association and you should preserve the association.Think about the
EJB spec it actually SAYS you should resume association if the tx is
still there.
in clear ONLY suspend the system association IF you commited or
rolledback yourself (as opposed to the wrong all the time *even if*
rollback.
Do we have agreement?
I think so, this is the snippet from TX_REQUIRED
try {
return invokeNext(remoteInvocation, mi, newTransacation != null);
} finally {
if (newTransaction != null) {
if (newTransaction.getStatus() == Status.STATUS_MARKED_ROLLBACK) {
newTransaction.rollback();
} else {
newTransaction.commit();
}
mi.setTransaction(oldTransaction);
}
/*
here the old code has
else {
tm.suspend();
}
And I propose to get rid of 'else' and just:
*/
tm.suspend();
This should remove the tx association as it used to [b]_plus_[/b] just in
case, if the TM does not disassociate in tx.commit() and
[JBoss-dev] CVS update: jboss/src/main/org/jboss/ejb/plugins TxInterceptorCMT.java
User: azakkerman
Date: 01/12/18 12:16:40
Modified:src/main/org/jboss/ejb/plugins TxInterceptorCMT.java
Log:
Fix small issues causing TyrexTM integration problems
Revision ChangesPath
1.20 +25 -13jboss/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.19
retrieving revision 1.20
diff -u -r1.19 -r1.20
--- TxInterceptorCMT.java 2001/11/24 20:43:23 1.19
+++ TxInterceptorCMT.java 2001/12/18 20:16:40 1.20
@@ -30,7 +30,7 @@
* @author a href=mailto:[EMAIL PROTECTED];Sebastien Alborini/a
* @author a href=mailto:[EMAIL PROTECTED];Anatoly Akkerman/a
* @author a href=mailto:[EMAIL PROTECTED];Ole Husgaard/a
- * @version $Revision: 1.19 $
+ * @version $Revision: 1.20 $
*/
public class TxInterceptorCMT
extends AbstractTxInterceptor
@@ -118,16 +118,17 @@
// New transaction is the new transaction this might start
Transaction newTransaction = null;
-//DEBUG Logger.debug(Current transaction in MI is
+mi.getTransaction());
-//DEBUG Logger.debug(Current method +mi.getMethod());
+//DEBUG log.debug(Current transaction in MI is + oldTransaction);
+
byte transType = getTransactionMethod(mi.getMethod(), remoteInvocation);
-// printMethod(mi.getMethod(), transType);
+ //DEBUG printMethod(mi.getMethod(), transType);
// Thread arriving must be clean (jboss doesn't set the thread
// previously). However optimized calls come with associated
// thread for example. We suspend the thread association here, and
// resume in the finally block of the following try.
Transaction threadTx = tm.suspend();
+ //DEBUG log.debug(Thread came in with tx + threadTx);
try { // OSH FIXME: Indentation
switch (transType) {
@@ -142,6 +143,7 @@
// get the tx
newTransaction = tm.getTransaction();
+ //DEBUG log.debug(Starting new tx + newTransaction);
// Let the method invocation know
mi.setTransaction(newTransaction);
@@ -154,7 +156,7 @@
try {
return invokeNext(remoteInvocation, mi, newTransaction != null);
} finally {
-//DEBUGLogger.debug(TxInterceptorCMT: In finally);
+//DEBUGlog.debug(TxInterceptorCMT: In
finally);
// Only do something if we started the transaction
if (newTransaction != null) {
@@ -166,23 +168,32 @@
// This will happen if
// a) everything goes well
// b) app. exception was thrown
-//DEBUGLogger.debug(TxInterceptorCMT:before commit);
+//DEBUG log.debug(TxInterceptorCMT:before commit of
+ newTransaction);
newTransaction.commit();
-//DEBUGLogger.debug(TxInterceptorCMT:after commit);
+//DEBUG log.debug(TxInterceptorCMT:after commit of +
newTransaction);
}
// reassociate the oldTransaction with the methodInvocation
(even null)
mi.setTransaction(oldTransaction);
-} else {
-// Drop thread association
-tm.suspend();
}
+// Always drop thread association even if committing or
+// rolling back the newTransaction because not all TMs
+// will drop thread associations when commit() or rollback()
+// are called through tx itself (see JTA spec that seems to
+// indicate that thread assoc is required to be dropped only
+// when commit() and rollback() are called through
TransactionManager
+// interface)
+tm.suspend();
+
}
case MetaData.TX_SUPPORTS:
{
-// Associate old transaction (may be null) with the thread
-tm.resume(oldTransaction);
+// Associate old transaction with the thread
+// Some TMs cannot resume a null transaction and will throw
+// an exception (e.g. Tyrex), so make sure it is not null
+if (oldTransaction != null)
+tm.resume(oldTransaction
Re: [JBoss-dev] Building Tyrex plugin in RH 3.0
Ok, if I put it into a sar and drop it in deploy dir, will it get started ahead of all the other mbeans that require presence of TransactionManager in JNDI? (Which is a whole bunch of mbeans living in jboss-service.xml) - Anatoly Akkerman Computer Science Dept. Courant Institute of Mathematical Sciences, NYU 715 Broadway, #719 Tel: 212 998-3493 New York, NY 10003 Fax: 212 995-4123 - On Mon, 17 Dec 2001, David Jencks wrote: On 2001.12.16 23:36:07 -0500 Anatoly Akkerman wrote: Hey, I am the original author of the Tyrex TM plugin. As demo of my other software is approaching, I needed Tyrex back in JBoss. It turned out, the plugin is broken. I've fixed the minor issues in the source, it compiles now (I will commit the changes sometime next week). Now there are some libraries that are missing. Namely, I need the ots library. It used to be in the old (2.4) Jboss as ots-jts_1.0.jar, it is no longer in RH. Can I simply put it into thirdparty/sun/jts/lib and modify the plugin/build.xml to take care of it? Also I would need to put it into jboss-service.xml. Basically, here are external libs that Tyrex plugin depends on: tyrex v 0.9.8 jts and ots 1.0 castor xerces Any objections? (I can put these into comment of the TyrexTM MBean, if people don't want some of this stuff loaded when they use std JBossTM) I would put tyrex, jts, and ots into a sar with the plugin classes, since they are unlikely to be used by anything else (except maybe another dtm, which could be packaged the same way). I'd use a classpath element in jboss-service.xml in your sar for castor and xerces, since they will be used elsewhere. Hmmm, maybe not xerces, doesn't the xml parser need to be on the classpath at jboss startup? In more detail, the sar (a renamed jar) would have (guessing at the name of all files ;-) TyrexPlugin.class (etc) tyrex.jar jts.jar ots.jar META-INF/jboss-service.xml jboss-service.xml would have classpath archives=castor.jar, xerces.jar/ If castor needs to be initialized somehow or used through the castor plugin, you might be able to use an mbean-ref to it from your tyrex mbean. david jencks - Anatoly Akkerman Computer Science Dept. Courant Institute of Mathematical Sciences, NYU 715 Broadway, #719 Tel: 212 998-3493 New York, NY 10003 Fax: 212 995-4123 - ___ 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] Screwed up TxInterceptor
More from Tyrex integration front. The deal is like this. JBoss TxInterceptor seems to assume that Transaction.commit() and Transaction.rollback() is equivalent to TransactionManager.commit() or TransactionManager.rollback() in that it will disassociate the current thread upon completion or rollback of the transaction. Judging from JTA javadoc documentation, only the TM says it will drop the tx association. Well, this is not true, at least in the context of Tyrex. I don't really care which interpretation of the JTA spec is correct. In any case, when I did the integration of Tyrex a while back, I put necessary changes to handle this. (see Annotated version of TxInterceptorCMT v 1.10 starting with line 363. Somewhere along the way (v 1.12) this got dropped. Can I reinstate that? Actually what is the reason we call commit() on transaction rather than on TransactionManager ? - Anatoly Akkerman Computer Science Dept. Courant Institute of Mathematical Sciences, NYU 715 Broadway, #719 Tel: 212 998-3493 New York, NY 10003 Fax: 212 995-4123 - ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Broken Jetty/JBoss 3.0alpha java:comp/env JNDI integration?
Hi, guys I am experiencing strange things. I am running a 3.0 snapshot with Jetty 4.0.D1 Jbosstest-web works perfectly -- java:comp/env is bound in servlets everything works like a charm. While my application (which used to work with Tomcat on 2.4) deploys, but the servlet fails to locate java:comp/env. It is, though, capable of locating things in the global JNDI context. Where can the problem be? - Anatoly Akkerman Computer Science Dept. Courant Institute of Mathematical Sciences, NYU 715 Broadway, #719 Tel: 212 998-3493 New York, NY 10003 Fax: 212 995-4123 - ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Broken Jetty/JBoss 3.0alpha java:comp/env JNDI integration?
Sorry to waste everybody's time. Checking out latest JBoss 3.0 snapshot fixed the problem. Thanks to all. Anatoly. __ View this jboss-dev thread in the online forums: http://jboss.org/forums/thread.jsp?forum=66thread=5765 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Building Tyrex plugin in RH 3.0
Hey, I am the original author of the Tyrex TM plugin. As demo of my other software is approaching, I needed Tyrex back in JBoss. It turned out, the plugin is broken. I've fixed the minor issues in the source, it compiles now (I will commit the changes sometime next week). Now there are some libraries that are missing. Namely, I need the ots library. It used to be in the old (2.4) Jboss as ots-jts_1.0.jar, it is no longer in RH. Can I simply put it into thirdparty/sun/jts/lib and modify the plugin/build.xml to take care of it? Also I would need to put it into jboss-service.xml. Basically, here are external libs that Tyrex plugin depends on: tyrex v 0.9.8 jts and ots 1.0 castor xerces Any objections? (I can put these into comment of the TyrexTM MBean, if people don't want some of this stuff loaded when they use std JBossTM) - Anatoly Akkerman Computer Science Dept. Courant Institute of Mathematical Sciences, NYU 715 Broadway, #719 Tel: 212 998-3493 New York, NY 10003 Fax: 212 995-4123 - ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] .sar|.ear|.war, .xml a happy dance for administration
Not to offend you, Jason, but where have you been for the past couple of weeks? There has been a whole bunch of threads about deploying XMLs only, getting rid of packaging hell, glueing descriptors together, etc. Perhaps, the birds kept you away from e-mail :) And you are right, this is where this is heading to. From all you have said, there seems to be one idea that has not been mentioned before, namely, using the overrides of default configurations. Don't know if this is a good idea, if you mean that there is a default and you just put changes to it into your descriptor. It is better to be redundant in specifying full config rather than having to mess around with a 'shadow' default and 'diff' config. Anatoly. ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Runaway threads in 3.0 ?
Oops, it was my screwup -- setting session-timeout in web.xml to be 0. This still should have been flagged by Jetty and not let it busy-loop. Thanks, Greg Wilkins from jetty-discuss for quick response. Anatoly __ View this jboss-dev thread in the online forums: http://jboss.org/forums/thread.jsp?forum=66thread=5281 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Runaway threads in 3.0 ?
Hi, I've been experiencing RH 3.0 alpha consuming all the CPU while being idle. I have trouble tracking down what is causing this behaviour -- have some issues with jdb remote debugging. Anyone experiencing the same? (I am running on W2K, Sun's jdk 1.3.0) What is the best way to track this down? - Anatoly Akkerman Computer Science Dept. Courant Institute of Mathematical Sciences, NYU 715 Broadway, #719 Tel: 212 998-3493 New York, NY 10003 Fax: 212 995-4123 - ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Runaway threads in 3.0 ?
By analyzing HPROF output of an idle server with HPjmeter, it appears that org.mortbay.jetty.servlet.HashSessionManager$SessionScavenger.run is the main culprit? What is all this stuff anyway? __ View: http://jboss.org/forums/thread.jsp?forum=66thread=5281 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Will grand unification of CL solve this?
Hi, I've been seeing the following problem and have been wondering how to solve it or whether the grand unification will solve it. I am writing an EJB application that processes XML descriptors using Castor. Now, Castor is loaded by the SL and is available to the application but when an EJB invokes Castor, it has to be able to instantiate certain classes from the application. It seems in 3.0alpha this is not possible. The only way I can get rid of this problem is by removing castor from lib/ext and deploying it as an application library. This is, obviously not a good solution. In general, is there a way to deal with such issues? - Anatoly Akkerman Computer Science Dept. Courant Institute of Mathematical Sciences, NYU 715 Broadway, #719 Tel: 212 998-3493 New York, NY 10003 Fax: 212 995-4123 - ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] NPE in $Proxy ???
]at org.jboss.ejb.StatefulSessionContainer$ContainerInterceptor.invoke(StatefulSessionContainer.java:677) 18:15:09,596 ERROR [Default]at org.jboss.ejb.plugins.SecurityInterceptor.invoke(SecurityInterceptor.java:127) 18:15:09,596 ERROR [Default]at org.jboss.ejb.plugins.StatefulSessionInstanceInterceptor.invoke(StatefulSessionInstanceInterceptor.java:241) 18:15:09,596 ERROR [Default]at org.jboss.ejb.plugins.AbstractTxInterceptor.invokeNext(AbstractTxInterceptor.java:96) 18:15:09,596 ERROR [Default]at org.jboss.ejb.plugins.TxInterceptorCMT.runWithTransactions(TxInterceptorCMT.java:155) 18:15:09,596 ERROR [Default]at org.jboss.ejb.plugins.TxInterceptorCMT.invoke(TxInterceptorCMT.java:64) 18:15:09,606 ERROR [Default]at org.jboss.ejb.plugins.LogInterceptor.invoke(LogInterceptor.java:166) 18:15:09,606 ERROR [Default]at org.jboss.ejb.StatefulSessionContainer.invoke(StatefulSessionContainer.java:346) 18:15:09,606 ERROR [Default]at org.jboss.ejb.Container.invoke(Container.java:533) 18:15:09,606 ERROR [Default]at com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1555) 18:15:09,606 ERROR [Default]at com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1523) 18:15:09,606 ERROR [Default]at org.jboss.ejb.plugins.jrmp.server.JRMPContainerInvoker.invoke(JRMPContainerInvoker.java:411) 18:15:09,606 ERROR [Default]at java.lang.reflect.Method.invoke(Native Method) 18:15:09,606 ERROR [Default]at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:241) 18:15:09,606 ERROR [Default]at sun.rmi.transport.Transport$1.run(Transport.java:142) 18:15:09,606 ERROR [Default]at java.security.AccessController.doPrivileged(Native Method) 18:15:09,606 ERROR [Default]at sun.rmi.transport.Transport.serviceCall(Transport.java:139) 18:15:09,606 ERROR [Default]at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:443) 18:15:09,606 ERROR [Default]at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:643) 18:15:09,606 ERROR [Default]at java.lang.Thread.run(Thread.java:484) 18:15:09,606 DEBUG [org.jboss.tm.TxCapsule] Committing, tx=XidImpl [FormatId=257, GlobalId=lib03//9, BranchQual=], status=STATUS_ACTIVE 18:15:09,616 DEBUG [org.jboss.pool.ObjectPool.J2EESplitDB] Pool J2EESplitDB [1/1/10] gave out pooled object: org.jboss.resource.adapter.jdbc.local.JDBCManagedConnection@474e45 18:15:09,616 DEBUG [org.jboss.tm.TxCapsule] registerSynchronization(): Entered, tx=XidImpl [FormatId=257, GlobalId=lib03//9, BranchQual=] status=STATUS_ACTIVE 18:15:09,616 DEBUG [org.jboss.resource.JBossConnectionListenerImpl.J2EESplitDB] Connection handle 'org.jboss.resource.adapter.jdbc.local.ConnectionInPool@2631cc' issued by connection manager 'org.jboss.resource.connectionmanager.jboss.MinervaSharedLocalCM@4e1bea' from mcf 'org.jboss.resource.adapter.jdbc.local.JDBCManagedConnectionFactory@3c9c31' 18:15:09,616 DEBUG [org.jboss.ejb.plugins.jaws.jdbc.JDBCCommand] Store command executing: UPDATE DESCRIPTOR SET LOCKKEY=? WHERE OBJNAME=? AND DESCTYPE=? 18:15:09,616 DEBUG [org.jboss.ejb.plugins.jaws.jdbc.JDBCCommand] Set parameter: idx=1, jdbcType=INTEGER, value=-1 18:15:09,616 DEBUG [org.jboss.ejb.plugins.jaws.jdbc.JDBCCommand] Set parameter: idx=2, jdbcType=VARCHAR, value=petstore 18:15:09,616 DEBUG [org.jboss.ejb.plugins.jaws.jdbc.JDBCCommand] Set parameter: idx=3, jdbcType=VARCHAR, value= 18:15:09,616 DEBUG [org.jboss.ejb.plugins.jaws.jdbc.JDBCUpdateCommand] Rows affected = 1 18:15:09,616 DEBUG [org.jboss.resource.JBossConnectionListenerImpl.J2EESplitDB] Connection handle 'org.jboss.resource.adapter.jdbc.local.ConnectionInPool@2631cc' closed from connection manager 'org.jboss.resource.connectionmanager.jboss.MinervaSharedLocalCM@4e1bea' from mcf 'org.jboss.resource.adapter.jdbc.local.JDBCManagedConnectionFactory@3c9c31' 18:15:09,616 DEBUG [org.jboss.tm.TxCapsule] Before completion done, tx=XidImpl [FormatId=257, GlobalId=lib03//9, BranchQual=], status=STATUS_ACTIVE 18:15:09,616 DEBUG [org.jboss.tm.TxCapsule] Zero phase commit: No resources. 18:15:09,616 DEBUG [org.jboss.pool.ObjectPool.J2EESplitDB] Pool J2EESplitDB [0/1/10] returned object org.jboss.resource.adapter.jdbc.local.JDBCManagedConnection@474e45 to the pool. 18:15:09,616 DEBUG [org.jboss.tm.TxCapsule] Committed OK, tx=XidImpl [FormatId=257, GlobalId=lib03//9, BranchQual=] the two messages from INFO [Default] about locks being released, are from the SLSB and DescriptorCMP saying that the entity has been updated. What is happening? - Anatoly Akkerman Computer Science Dept. Courant Institute of Mathematical Sciences, NYU 715 Broadway, #719 Tel: 212 998-3493 New York, NY 10003 Fax: 212 995-4123 - ___ Jboss-development mailing list [EMAIL PROTECTED] https
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] (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] EAR classpath access....
Tomcat has a similar problem, though, it seems it is even worse. The invocation of javac to compile the jsps sets up the path to the WAR and standard java classes and does not use the classloader, so you would have to do something that David Jencks proposes, namely, get the URLs from the classloader. This is not ideal, imho. It would be best if javac that compiles the jsps just use the context classloader. Has anyone looked into if this is possible? Anatoly. On Sun, 25 Nov 2001, Julian Gosnell wrote: Is this available to the Jetty integration anywhere. It is not enough simply to be passed the classloader because I need to make up a classpath for the java compiler so I can compile JSPs on the fly. Currently Jetty only knows about classes/jars stored in the war module. If classes/jars are deployed in the ear above, I have no way of knowing (without navigating the filesystem) what they are. I would rather not have to repeat what someone else has already worked out. Is there anyway for me to get hold of this information ? Who should I talk to about agreeing how I might get hold of it ? Thanks, Jules _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.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] xml only deployment?
See below.
On Sat, 24 Nov 2001, David Jencks wrote:
On 2001.11.24 21:11:40 -0500 Anatoly Akkerman wrote:
Hi,
The bulk of this e-mail has been posted earlier on the topic of j2ee
packaging and nobody but Scott replied to it. It shares some of the ideas
with the author of this thread.
Thanks for reposting this, I meant to respond but got too busy and forgot.
Here is what seems to be a better design that is consistent with JBoss
philosophy. Please, don't flame, these are just ideas for discussion.
Deploying anything is just giving 1 xml file to a deployer. No more
multiple files (Richard mentioned that a few days ago, just use XML
namespaces and whatever else is needed to glue the pieces together).
From my prospective, though, it is important to separate classes from
descriptors as well, more below.
This is contrary to all the j2ee specs, right? or do I misunderstand?
Yes, this is not j2ee-spec compliant and I agree, we should also support
standard packaging as well, this is just in addition, for those who see
advantage in having flexible packaging.
I think we need to keep standard j2ee dd as at least an option. My
understanding of this part of your proposal is that you want to be able to
embed (perhaps in a different namespace) all spec-required info
(ejb-jar.xml, ra.xml, etc etc) inside one super-jboss.xml, rather than
using the spec-suggested xml references.
One file is purely a convenience, though a very useful one.
This single XML file has all the necessary information about the item
being deployed:
For services this would be whatever is now in jboss-service.xml
For j2ee modules/applications the file would contain sections with
standard j2ee metadata, jboss-specific metadata, jaws, whatever.
And, I think the crucial part for all of the above , is the
packaging/scoping information which specifies:
1) CL scoping for this deployable entity
definitely
2) any module-specific class library URLs
3) file archive URLs
I think these are supplied in *service.xml via the classpath elements?
Could very well be so, I have not looked into how *service.xml is
composed.
(This is very similar to what Dr. Jencks proposes with deploy to
scope but points 2 and 3 may be somewhat new, don't know)
Here is my look at it. CL Scoping is just a service that JBoss provides
which ought to be configurable through standard means, i.e. XML
descriptors, just like I can configure, say the interceptor stack for the
container. No more 'implied' derivations of module dependencies from
awkward MANIFEST.MF Class-Path: entries (though this can still be
supported for modules which are packaged in the old-fashioned way).
Scope:
keeps scope-wise global (for Scope) class library repository
libraries can be added to the scope/removed/updated
Modules (services, applications, etc.):
deployed in a scope
specify libraries it depends on (from the Scope)
additional libraries/ file archives needed for successful start
I was assuming all the jars/files/whatever would go to the
scope/application/virtual host classloader. Are you proposing further
subdividing the classloader space within a scope? If so, what does this
gain you?
Well, I don't know at the moment if having a tree of scopes is useful. I
have one scenario in mind where it may be useful, but don't know if this
is such a common issue. The case is like this:
Application Z uses 2 modules that introduce the following conflict:
module 1 uses a specific version of an off-the shelf package, say
org.exolab.castor v. X
module 2 uses a different version of the same
package. The apis, classes are incompatible, so they cannot be shared in
the same scope.
Using subscopes for each module would solve this issue.
Now, even forgetting about subscoping, having an ability to add libraries
at module deploy time in the module descriptor is useful in and of itself.
Presumably, the deployment script or the person who deploys the app would
deploy truly global libraries into the global scope _prior_ to deployment
of any descriptors. And then each module at descriptor deploy time can
specify any additional libraries that go into the scope. This preserves
the locality of configuration -- if a library is really local, i.e. for
this module only, I should be able to specify where it is and how to
access it through the module descriptor, not in an unrelated scope
definition file. Same thing goes for WAR files, such as jsps, htmls, jpgs,
which are packaged into a jar. This jar is really 'local' to the WAR
module, so the information about this jar's location should be in WARs
deployment descriptor.
see more below
I want to be able to just give all the jar library URLs to my personal
Scope and then deploy only the XML descriptors of j2ee modules.
So, to accomplish this, in this new architecture, one might prepare
('deploy
RE: [JBoss-dev] EAR classpath access....
Sounds like a great idea, you need to call the getResourceAsStream on it, why don't you look into it? marcf This won't work for an out-of-process compiler such as jikes. Yeap, jikes is not java -- it is C++. Also, it may very well be so that even Sun's compiler can't do this. In Tomcat they configure a command line for sun.tools.javac which has a special -classpath switch. Don't know if the jvm uses it or javac itself reads the entries in the classpath and loads classes from there bypassing CL mechanisms. This sucks big time, because if you don't precompile JSPs, you end up having to trag all the necessary .class files into the WAR. No integration... -dain ___ 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] redesigning J2EE packaging
Hi,
I've been observing some of the recent threads on the list and reflected
on my current project. Mark has mentioned something of the sort that j2ee
packaging sucks. I certainly agree.
Here is what seems to be a better design that is consistent with JBoss
philosophy. Please, don't flame, these are just ideas for discussion.
Deploying anything is just giving 1 xml file to a deployer. No more
multiple files (Richard mentioned that a few days ago, just use XML
namespaces and whatever else is needed to glue the pieces together). This
single XML file has all the necessary information about the item being
deployed:
For services this would be whatever is now in jboss-service.xml
For j2ee modules/applications the file would contain sections with
standard j2ee metadata, jboss-specific metadata, jaws, whatever.
And, I think the crucial part for all of the above , is the
packaging/scoping information which specifies;
1) CL scoping for this deployable entity
2) any module-specific class library URLs
3) file archive URLs
Here is my look at it. CL Scoping is just a service that JBoss provides
which ought to be configurable. No more 'implied' derivations of module
dependencies from awkward MANIFEST.MF Class-Path: entries (though this can
still be supported). It ought to be configured through standard XML
descriptors, like any other service.
Scope:
keeps scope-wise global class library repository
libraries can be added to the scope/removed/updated
Modules:
deployed in a scope
specify libraries it depends on (from the Scope)
additional libraries/ file archives
I want to be able to just give all the jar library URLs to my personal
Scope and then deploy only the XML descriptors of j2ee modules.
So, to accomplish this, in this new architecture, one might prepare
('deploy') a new Scope with whatever libraries he may want to use. (Say,
by creating an xml files with the scope description and library URLs that
need to be made available in this scope)
Then deploy modules in that scope by just giving xml files describing
these modules. It may also be important to include additional library /
file archive URLs at module deploy time in that same xml file. For example
when deploying a WAR, one would necessarily have to provide the WAR file
archive with jsps, taglibs, whatever else which is not obtained through
standard classloading mechanisms, so a URL of this archive can be placed
into the xml.
Nice things about this:
- no hard coded xml descriptor names (like META-INF/ejb-jar.xml,
WEB-INF/web.xml)
- unified configuration of underlying services in one file
- package libraries/classes whichever way you want just make them
available to the underlying CL through scope definition or
module description
- no more messing with MANIFEST.MF, jarring/unjarring just
to modify descriptors, yak...
My current project would benefit tremendously in trimming down
packaging/unpackaging complexity if this architecture was in place. Do
others think this may be useful?
-
Anatoly Akkerman
Computer Science Dept.
Courant Institute of Mathematical Sciences, NYU
715 Broadway, #719 Tel: 212 998-3493
New York, NY 10003 Fax: 212 995-4123
-
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] compile error in MessageDrivenTxInterceptorBMT -2.4 branch?
It seems that (I think Scott) updated the Interceptor to talk to the JTS TransactionManager instead of the jboss TM, he did not substitute the JBossTM-specific calls with the JTS-standard suspend()/resume() calls. disassociateThread() is from org.jboss.tm.TransactionManager and we should not rely on existence of this call in any of our TX interceptors, so that we can support an arbitrary TM (like Tyrex) through a plugin. On Thu, 25 Oct 2001, danch wrote: On the current CVS, I'm getting errors like the following. Method disassociateThread() not found in interface javax.transaction.TransactionManager. [javac] Transaction t1 = tm.disassociateThread(); So what am I missing? thanks all, danch ___ 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] Trying HA stuff
Hi, This message is to Sacha and Bill, primarily. Some people in my research group are starting to look into issues that tie into clustering somewhat and they want to start playing with the HA stuff. Can you, please, provide some sort of pointers on how to get your current HA implementation up and running (building it, configuring the service and starting it). Is it possible to use the HA naming service by plugging it into 2.4.x branch? How are you testing your stuff? We need a runnable environment. Thank you. Anatoly Akkerman. ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] XML config files, whitespace and CDATA... (Castorway = JAXB)
Hmmm, just looked at sun - there's something called JAXB that apparently compiles an xml schema into a custom parser that does 2 way translation between xml and an object tree. Since this is an impending standard it will presumably be the way to go.. for castor as well. I don't really like the idea of having to regenerate classes whenever the DTD/schema changes, but JAXB does look kind of cool. If you look into the expert group for JAXP (JSR 031) you'll find Intalio there. This is the company that's behind Castor and the entire exolab.org. Castor has 2 ways of providing you with marshalling/unmarshalling your Java objects into/from XML SourceGenerator: You just write an XML schema for you XML, run Castor's SourceGenerator, it builds a hierarchy of classes. Objects of these classes are used upon unmarshalling of an XML to build an object tree. You can specify a common superclass for all the generated classes, and package name. more advanced choice XML mapping You have your custom hierarchy of classes that you use to build object trees that you want eventually to marshal into/unmarshal from XML. You write a mapping.xml file which describes the mapping. Castor uses reflection API to marshal/unmarshal using a combination of your mapping.xml and default rules, if something is missing from your mapping description. In either case, you never have to mess with XML parsing yourself, Castor does the fancy footwork of setting all the fields and building the object tree for you. Here is my experience of using Castor. I've used SourceGenerator to create class hierarchies to marshal/unmarshal application.xml, ejb-jar.xml and jboss.xml I use these to automatically generate/modify deployment descriptors. As far as working, the system works well but I find using the class hierarchy generated by SourceGenerator a bit cumbersome. The reason is, probably due to poor XML design of these config files. Perhaps, I am wrong here. Just my 2 cents: ejb-jar.xml - Information that is logically coupled (ejb description, method permissions for this bean and method transaction settings) are located in different entities. The default generated classes, obvously do not have any idea of the logical coupling. When I need to gather all the information about a bean, I have to traverse the objet tree looking for objects which are related and putting them together with my own 'glue' classes. Ideally I would want logically-related items to be glued together during unmarshalling automatically. I'll probably have to look at custom mapping through XML mapping, when I have a clearer picture of things. For those interested, I can provide my XML Schemas of the standard config files that I've been using to build my class hierarchies. http://www.cs.nyu.edu/~akkerman/schemas.jar (I had to recover jboss.xsd, so it may not be exactly correct, I'll recheck it and might update it) Anatoly. Toby. ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] XML config files, whitespace and CDATA
On Wed, 8 Aug 2001, David Jencks wrote: Hi, I like it. Don't we also need a dtd for jboss.jcml (or is there one I haven't found?)? My experience with adding a dtd indicates whitespace handling may be affected-- maybe we should add the dtd and validation first? At the risk of changing the subject ;-) There seem to be two xml-configuration parsing systems in use. The older stuff like for ejb-jar uses code that partially validates the xml while setting properties, whereas the rar deployer uses a reflection based scheme that pretty completely separates the xml structure from the property setting. I like the reflection-based structure-independent way better, although I think it should only be used with a dtd and xml parser validation-- although this should be done anyway imho. Does anyone else have an opinion? I've been working lately with Castor and its SourceGenerator. My current project has to do with reconfiguring and repackaging (splitting) big EARs into pieces with different configs. SourceGenerator was the quickest way for me to get started, without having to learn anything about parsing XML. They Castor framework also has a mapping framework that allows one to map your custom object hierarchy to XML by just writing a schema. Perhaps, this is a way to go. I was also wondering if someone would rewrite JBoss dtds into XML schemas and maintain them. Schemas are much more expressive. I did hack a translation from jboss dtd to schema, there are tools to do that as well, but it would, probably be good if JBoss community had official XML Schemas for its config XMLs. david jencks On 2001.08.08 22:31:13 -0400 Jason Dillon wrote: I mentioned a while ago something about trimming all whitespace from metadata values, but that was rejected because some data might need that whitespace. I also added support to auto trim attribute values from jboss.jcml. Now I would like to suggest changing things such that all leading and trailing whitespace is truncated for all attribtes (jcml and metadata) unless the data is enclosed in a CDATA element. Initially I was not sure if this was possible, but I just check and we can detect if a node is a CDATA via the Node.getNodeType() == Node.CDATA_SECTION_NODE. Lets assume that there is no autoTrim in ConfigurationService and we have a mbean that looks like this: mbean code=org.jboss.web.WebService name=DefaultDomain:service=Webserver attribute name=Port 8083 /attribute /mbean The value of Port should resolve to 8083. mbean code=org.jboss.web.WebService name=DefaultDomain:service=Webserver attribute name=Port !CDATA[8083]] /attribute /mbean The value of Port should still resolve to 8083, since we can cast aside the first node, since it is empty and its sibling is a cdata. To make this work, some modifications will be required to look for empty nodes with siblings that are CDATA. We could also support comments inside, such that this would also work: mbean code=org.jboss.web.WebService name=DefaultDomain:service=Webserver attribute name=Port !-- use this port -- 8083 /attribute /mbean Any ways, I think that this would be very, very helpful to allow more freedom with respect to usage of XML syntax, and provide a mechanism to indicate that whitespace should not be trimmed. Any comments? --jason ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] JSR-77 the 2 and 1/2
Hi, guys I posted previously about support for JSR-77 and enabling extensive profiling/monitoring in JBoss. No one followed up on that, so I'll put in my 2 cents worth of ideas in this thread. I could not find the JSR-77 spec but have a bunch of ideas, please look at my post http://www.mail-archive.com/jboss-development@lists.sourceforge.net/msg04519.html Somebody commented that my ideas have more to do with JSR-88 but really those are related. My goal is to build a very extensive profiling infrastructure in JBoss. This is clearly very related to your goals and, perhaps, take them further. I have ideas on how to collect profiling data without doing a lot of modifications to the JBoss itself, though some support is needed (see the recent thread on METHOD INVOCATION (profiling) regarding custom contexts in JBoss MethodInvocation). I am very interested in collecting statistics about both the server and an application running on top of it. But I am even more interested in correlating server usage to the application (e.g. instead of just reporting that JBoss has committed 100 transactions, think of it as keeping track of transaction costs on specific methods of specific bean instances in a given deployed application, if we choose to) I am glad somebody is starting to work on this as well, let's work together or at least discuss our visions about this. Anatoly Akkerman On Thu, 5 Jul 2001, Andreas Schaefer wrote: Hi Ole Thanx but I think this was not the intention in the JSR-77 but just to know how your app. server is doing. For the other part you mentioned I would just add an interceptor which keeps track off that because I think you want to make this persistent etc. Have fun - Andy - Original Message - From: Ole Husgaard [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, July 05, 2001 6:51 PM Subject: Re: [JBoss-dev] JSR-77 the 2 and 1/2 Hi, Not quite sure if I am off-track here, but: If you want to avoid loosing statistics, you might want to consider combining these two methods into a single atomic call. For example, if you want to count bean invocations, and do not want to drop a single invocation from your statistics. If you get the stats, and then reset them, any invocations between the two calls will neither be in this stats, or the next one - they will be utterly lost. Not a good thing, if your customer pays per bean invocation. Best Regards, Ole Husgaard. Andreas Schaefer wrote: Hi Geeks Just to give you the opportunity to stop me before turning JBoss up side down here are my ideas to add Statistics into JBoss. The part I want to do is the EJB statistics for (at least right now) Entity Beans. The difficult part is to collect everything in a loose coupled system like JBoss. Therefore I suggest: - every statistics component must implement Monitorable - interface Monitorable contains the methods: - Statistic[] retrieve() - void reset() - in the Entity Bean case not only the Container has to implement Monitorable but also all the Interceptors. This is because some statistics asks for the method performance, Cache statistics etc. Statistic is a JSR-77 class which contains a name which would allow to map the delivered statistics to the one requested by JSR-77. Hope this is OK for all of you - Andy ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: AW: [JBoss-dev] METHOD-INVOCATION (introducing profiling support)
On Sat, 30 Jun 2001, Ole Husgaard wrote:
Hi,
I like the idea of being able to pass arbitrary contexts
with the invocation request.
I guess that it means we should agree to some context
naming convention.
Are you talking about org.jboss.ejb.MethodInvocation?
Why should that class be Serializable?
It is only used locally on the server.
It is indeed reconstructed from the transport layer representation of the
invocation. We need a generic structure that would allow both simple
serializable contexts that can be passed along regardless to the
underlying transport layer and, perhaps, a way to specify that some
contexts are transport-layer sensitive. (Like the transaction context,
which would be handled by IIOP directly). Can we have some kind of
delegation model to let context-specific handlers map it's own context
into the underlying transport layer. The default one would be
serialization.
E.g.
provider of Transaction Ctx has handlers to map a Tx into IIOP, RMI, SOAP,
etc.
provider of Profiler Ctx can rely on serialization and be transport-layer
insensitive.
I guess that a Map would be right for the contexts
of the MI, but IMHO we should only use it for optional
context information. The mandatory context information
(like the Method and argument list, and possibly tx,
principal and credentials), we should keep in seperate
variables in the MI to avoid the Map lookup.
The MI is passed forth and back in the invocation
chain, so we could use that to pass context changes
back towards the caller within the local VM.
For passing contexts across the wire: This depends on
the invocation transport used, and not all transports
may support it.
For the JRMP transport, org.jboss.ejb.plugins.jrmp.interfaces.RemoteMethodInvocation
has same role as MI over the wire.
I guess that it could be changed to support contexts.
But it is only passed in the invocation request, and
not returned with the invocation reply. If we want to
pass context changes back to the caller (and we want
that, we may want it even in case of exceptions), I
guess that we have to package all invocation replies
(return values and returned exceptions) into some
return value object over the wire.
Makes sense.
Best Regards,
Ole Husgaard.
P.S: I'll better go nuke that TPC import in the MI
now...
Jung , Dr. Christoph wrote:
-Ursprüngliche Nachricht-
Von: marc fleury [mailto:[EMAIL PROTECTED]]
Gesendet: Donnerstag, 28. Juni 2001 18:03
An: [EMAIL PROTECTED]
Betreff: RE: [JBoss-dev] METHOD-INVOCATION (introducing profiling
support)
I believe we should in fact move EVERYTHING to the map, the user the method
the tx everything
so that the MI is just a big
MI {
Map
}
and in the map we have pairs
user Object
method Object
params Object[]
myInformationThatIOnlyUseInMyOwnLittleApplication
Object[Maps[Array[OfMyStuff
would that cut it? yes we pay a price (map lookup) but it is on a small
map.
that would perfectly cut it.
The only tricky part is that it needs to be serializable, (or not actually
but we would need to write the map item by item and catch the
non-serializability).
as a first approach I would say that it is in the responsibility of the
invoker/interceptor
developers to either put only serializable instances in there or to remove
any non-serializable stuff
before returning to their predecessor in the chain
... now that I write it, there was once this idea of having
a tree of responsibility or at least of several invokers feeding the same
chain, maybe we could realise this also in RabbitHole? ...
hence we could rely on a serializable HashMap or whatever.
I´d be glad to assist you wherever possible in that respect ...
CGJ
___
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
___
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
___
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] JSR-77 and new deployment architecture
Hi, I've been rethinking lately how should the deployment architecture be redesigned in JBoss for the future clustering support and, incidentally, my personal project. The existence of JSR-77 which did not put out any kind of draft yet would, possibly, make our lives more complicated in the future. But here are some of my ideas about what we may want to develop. App repository infrastructure - keeps archives of applications with versioning information - applications are kept in a pristine EAR form (more about this later) App configuration/packaging infrastructure - can have some modules to help create a pristine EAR - can take a pristine EAR (say, from the app repository) and add or modify any module deployment XMLs to suit a particular deployment scenario - can split a pristine EAR into pieces (modules) keeping consistent class dependencies and libraries App runtime representation/profiling infrastructure - keeps runtime information of the application deployed in a particular deployment scenario: + which JBoss nodes have which modules deployed and how are the modules referencing each other + keeps profiling data (if enabled, also it should be configurable to support different profiling granularity with different overheads) about the running application App deployment/migration/undeployment infrastructure - manages deployment/internode migration (if we ever support this)/undeployment of application modules on JBoss nodes in the scope of the given application deployment (thank you Dr. Jung for scoped deployment support) We can have GUI plugins for the management application to assist in various steps of controlling this stuff. So, my vision is, we take a pristine EAR, like PetStore. Drop it into the repository. The App configuration/packaging service analyzes the EAR and keeps track of the modules, their connectivity, dependencies, offering you, perhaps, a GUI interface that brings up a graph of the application and you specify where to deploy each module and how. We can offer a default path (ala hot-deploy) of deploying the app on a single node. The conf/packager repackages and reconfigures the pristine EAR into a collection of modules (keeping track of class dependencies and providing necessary libraries for modules) which get deployed on approriate nodes by the deployment infrastructure. The runtime representation gets the current scenario and collects profiling information from each module. Just to add some spice to this, put in an Adaptation Manager into this that tries to enhance performance by analyzing the profiling data and dynamically deploying/migrating/undeploying modules. But this is really what my research is about, so that would have to wait :) I have scratched a few of the problems a little (like splitting an application into modules, dynamic deployment descriptor generation, etc.) I have very little code yet (some dependency analysis, app structure extraction) but perhaps, throwing these ideas here will get more people thinking about it, designing and implementing it. As a side note, I remember, that when Dr. Jung submitted his ScopedDeployment stuff, they had a discussion with Mark about module deployment ordering and circular class dependencies in beans (modules). I think, the conf/packaging service can obtain enough information from the pristine app to be able to inform the deployer service on the proper order and also take care of circular class dependencies. - Anatoly Akkerman Computer Science Dept. Courant Institute of Mathematical Sciences, NYU 719 Broadway, #715 Tel: 212 998-3525 New York, NY 10003 Fax: 212 995-4123 - ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] METHOD-INVOCATION (introducing profiling support)
I am not a very efficient programmer but will try to assist with this as much as I can to get forward with my project. I am available immediately :) Anatoly. On Thu, 28 Jun 2001, marc fleury wrote: |hence we could rely on a serializable HashMap or whatever. | |I´d be glad to assist you wherever possible in that respect ... my schedule is finish busy wait LW bug fixing (almost done) commit URL based rabbit hole (almost done) JMX'ify invocation chain in invoker-container, first beta rabbit hole (mid july?) 2weeks break (write JMX book chapters) then rework container invocation (doing most the real work now) clustering of new containers prepare London session with updated material and that takes me till september :( what we are talking about is in the rework container invocation. Will get there. marcf | |CGJ | |___ |Jboss-development mailing list |[EMAIL PROTECTED] |http://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] METHOD-INVOCATION (introducing profiling support)
Hello, Marc and others. This is a bit off-topic from the original thread but I've notices something in Marc's answer that had strong resonance with my thoughts. I am trying to come up with a comprehensive profiling support for J2EE applications running on top of JBoss. This is necessary for a my research project and I am pretty sure that if it is functional, it will be quite useful for the overall JBoss userbase. Here is a bag of ideas that has been collecting dust for a few days in my head (after several discussions with my advisor). A few words about my project. It has to do with adaptive distributed applications. For those familiar with Akamai and what they do to static content, start thinking how to achive the same with dynamic content. For those who picture webservices, try to think how to distribute a webservice to the edge servers (again ala Akamai). There is a whole slew of research issues that is related to this but the main goal is to build first an infrastructure to try out different ideas. The short term goal is to take an arbitrary J2EE application and dynamically deploy it on a bunch of nodes (this involves some smart deployment tricks, like decomposing the original EAR, repackaging beans, reconfiguring bean references, etc.) As a sample application we took PetStore (so this explains my initial work on getting PetStore running on JBoss and later on integration of Tyrex DTM into JBoss, to support distributed transactions which is essential when deploying an app in a distributed fashion). Now, next step is to be able to collect meaningful profiling information about a deployed application and develop an infrastructure to allow for dynamic adaptation decisions for this applications (like deploying certain beans on additional nodes to support additional clients, etc.) Think of it as having the application shrink or spread between nodes to be able to serve clients better. The first step for this, is bringing in profiling support into JBoss. And here profiling does not mean profiling in a sense of OptimizeIt and tools like that, it is more of a tool to keep track of bean invocations as well as some support to evaluate app server overheads. Now getting back to the original topic METHOD INVOCATION. Here is how it comes in. It seems to me that a method invocation carries information which can be classified either as - application invocation ctx (I tend to think it is just the method params) and - container (really app server) invocation ctx (all the necessary information to invoke the proper object with proper attributes, i.e. tx context, security principal, object id) It seems to me this is what Marc refered to when he said that we keep all the necessary stuff in the MI. Now, to introduce sophisticated profiling support (like being able to detect hot paths in the application, etc.) There has to be another app server managed invocation ctx object, namely, profiler ctx. Then, a profiler can pass along with each call sufficient information (hopefully minimal to minimize overhead, or null if profiling is disabled for an app) to be able to construct meaningful profiling data. Perhaps, my idea of where to introduce the profiler ctx support is flawed, so please, tell me if you have better ideas. But the way I see it now, the profiler ctx has to get passed along in the method invocation. (Both in optimized local and in remote calls) Introducing this context will necessarily involve changing all the inoke() calls that explicitly pass along the tx, principal and credentials, so that now the call also propagates profiler ctx. Wouldn't it be better if all the server-related invocation contexts were wrapped together and passed along as one object, so that changes like mine that introduce additional server-related contexts would be easily handled by placing another field in the ServerInvocationContext and not touching the Proxy and JRMP invoker and other code. If I am way too much off with my idea, please, tell me, I am open to suggestions on what is a better way to introduce profiling support in JBoss. Obviously, I would not submit any major changes to the invocation layer prior to approval from the lead developers but I would hate to have to maintain a forked CVS tree just to get me going with my project. Yours truly, - Anatoly Akkerman Computer Science Dept. Courant Institute of Mathematical Sciences, NYU 719 Broadway, #715 Tel: 212 998-3525 New York, NY 10003 Fax: 212 995-4123 - On Wed, 27 Jun 2001, marc fleury wrote: |When we get to support IIOP invocations, the CORBA |invocation transport layer automagically imports |incoming TPCs, and we never see a TPC that we can |import. Yes |That means that we cannot do the TPC import in the |transaction interceptors. |I guess the same argument goes
RE: [JBoss-dev] Deployable service archives new configurationsystem
Marc and others, have you thought of joining JSR 111 Java(tm) Services Framework http://jcp.org/jsr/detail/111.jsp it seems to be addressing this issue Anatoly ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] jndi.properties checkin is invalid
It was me, who changed it. I did it at the time I checked in the Tyrex integration and JBoss was not working properly together with Tyrex if this entry was commented out, I have not investigated why it happened, just changed it back. Sorry if it caused problems. I'll look more into it, I did not realize it was slowing down the system. - Anatoly Akkerman Computer Science Dept. Courant Institute of Mathematical Sciences, NYU 719 Broadway, #715 Tel: 212 998-3525 New York, NY 10003 Fax: 212 995-4123 - On Fri, 22 Jun 2001, Scott M Stark wrote: In the last check in of the conf/default/jndi.properties file by azakkerman the java.naming.provider.url=localhost value was added back in. This should not exist in the server version of this file as it causes all JNDI lookups to go through RMI and it can break the JNDI server on multi-homed hosts. Why was this added back in? ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] jndi.properties checkin is invalid
Hi, Scott, With this one, I for sure did not want to get on your ass kicking list. Perhaps, we need a more organized approach to adding modules to JBoss (maybe the new RabbitHole release should standardize the way modules get packaged into SARs or whatever, this way such problems may get minimized) We are playing with a serious issue of how externally developed modules (e.g. Tomcat, Jetty, Tyrex, etc.) get seemlessly integrated with JBoss without disrupting the fundamental JBoss operation. The fact that Tyrex comes with it's own jndi.properties in the default jar is easy to overlook when one is dealing with a project as big as Tyrex. I accept fully your blame but we need to get something constructive come out of this -- namely a way to avoid such issues in the future. - Anatoly Akkerman Computer Science Dept. Courant Institute of Mathematical Sciences, NYU 719 Broadway, #715 Tel: 212 998-3525 New York, NY 10003 Fax: 212 995-4123 - On Fri, 22 Jun 2001, Scott M Stark wrote: And there is another jndi.properties file embeded in the damn tyrex-0.9.8.5.jar You cannot bundle fundamental property files like jndi.properties in jars stuck into lib/ext as it destroys the runtime configurability of the server. Making me find two screwed up jndi.properties files is going to put you on my ass kicking list... - Original Message - From: Scott M Stark [EMAIL PROTECTED] To: JBoss Dev [EMAIL PROTECTED] Sent: Friday, June 22, 2001 8:43 AM Subject: [JBoss-dev] jndi.properties checkin is invalid In the last check in of the conf/default/jndi.properties file by azakkerman the java.naming.provider.url=localhost value was added back in. This should not exist in the server version of this file as it causes all JNDI lookups to go through RMI and it can break the JNDI server on multi-homed hosts. Why was this added back in? ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Castor in lib/ext and common classloader
I think, I've added it into the CVS tree for 2.3 to support Tyrex DTM. Perhaps, we should move all the Tyrex-related jars into a separate optional entry in class-path extensions. I was hoping to wait till the new class loading infrastructure is in place in Rabbit in the Hole (or whatever the codename is) but, if necessary, castor jar can be made optional in loading into the common classloader. Anatoly. On Fri, 1 Jun 2001, Vesco Claudio wrote: Hi alls! Why there is castor-0.9.1 in lib/ext? This jar is added in the common classloader path and so when I try to deploy and redeploy my castor RAR module I have problems to reinitialize castor (reloading the new DB mapping). Another problems... Is it possible to separate the common classloader in common classloader (jboss-j2ee.jar,...) / \ / \ jboss server cl (jaws,...) applications classloader (tomcat or jetty and so on...) / \ web cl... ejb cl... Claudio -- -- PREVINET S.p.A.[EMAIL PROTECTED] -- Via Ferretto 1 ph x39-041-5907073 -- I-31021 Mogliano V.to (TV) fax x39-041-5907087 -- ITALY ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] JBoss pool (former Minerva) transaction bug?
On Thu, 31 May 2001, Toby Allsopp wrote: On Wed, May 30, 2001 at 07:19:26PM -0400, Anatoly Akkerman wrote: Hello everybody Hello. I guess I should attempt to field this. I am running into problems with JBoss pools and Tyrex. This time it is a 2pc hueristic commit issue. Great. A wurble-munging wickety booger. I guess I was not clear enough. Tyrex is a DTM from exolab.org which I integrated with JBoss and committed into CVS a week ago. (check out org.jboss.tm.plugins.tyrex) The issue is using jboss pools in a distributed transaction (in my case, I've split the Petstore into pieces and deployed on several JBoss servers to test distributed transactions for my project) I've experienced transaction rollbacks under certain deployment scenarious and when I tracked down where they were coming from, it happened to be the minerva module. The scenario is as follows: 3 jboss servers server1: a bean initiates a transaction and in the context of this transaction calls beans on server2 and server3 server2: bean accesses a local datasource (minerva-wrapped cloudscape db) modifies some data server3: bean accesses a local datasource (minerva-wrapped cloudscape db) and modifies data server1: tries to commit the transaction, causing commit on the subtransactions in the server2 and server3 and their respective datasources (more below) When Tyrex commits a distributed transaction in 2pc, it asks all the subordinate transactions to commit which ask their local XAResources to commit. Minerva on a commit call disassociates itself from the transaction (sets current to null). Are you talking about Minerva's XADataSource implementation (org.jboss.pool.jdbc.xa.wrapper.XA*)? Yes, indeed. (more below) This implementation is just a wrapper for non-XA JDBC drivers so that they can participate in transactions managed by a JTA transaction manager. It doesn't magically give these drivers the ability to handle 2pc correctly. I'm not sure what scenario exactly you're testing, but if you're using the wrappers then you should not have more than one resource enlisted in the transaction. Tyrex upon getting successful commits from the XAResources, being in 2pc sets heuristic to COMMIT and asks the XAResources to forget() the transaction. I don't understand what JTA is talking about with heuristic this and that. It seems like a mechanism for dealing with strange situations or something. What is Tyrex trying to achieve with this heuristic stuff? What do you mean by sets heuristic to COMMIT? On a 2pc Tyrex DTM the originator transaction (sitting on server1) asks its subordinate transactions (on server2 and server3) to commit. The subordinate transactions (on server2 and server3) call commit() on their datasources and return their votes to the main coordinator. The coordinator based on the votes takes a heuristic decision on what to do about the completion of this transaction. If there were no errors reported, the TM decides to complete the commit heuristically. So, it does not throw any exceptions, but tries to tell all the subordinates to forget() the transaction. This indicated that the last request (commit()) was accepted by everybody and everybody can now forget about this transaction. So, it comes out that the XAResource should expect to see a commit() followed by forget() in such a scenario. Minerva code seems not to support this type of scenario. First, on a commit() of minerva XAResource the current is set to null. And second, even if we delay setting current to null till forget() is called, forget() calls the underlying jdbc connection saying something about transaction failing, which is not true in this particular case. Minerva throws an exception because it already disassociated itself from the transaction (i.e. current == null while id is not null). Also, minerva assumes that the forget() is always called when a commit() or rollback() have failed. Well, this is not really true, forget can get called during a heuristic commit as in the case described above. This may well be a problem with Minerva/JBossPool, but the wrappers really aren't meant to handle anything complicated. I am no JDBC/transactions guru, I've implemented the tyrex module and planning to use it for my research, so if Minerva is inherently incapable of handling these types of scenarios, I'll go ahead and get Oracle or something that can handle it. I was just wondering if minerva can be patched up to support my scenario as well. Anyone can suggest to me where I could find out what is the correct semantics of the API? I've tried the jta spec but could not see anything conclusive. Any idea how minerva should handle this properly? The JTA spec is all I have to go on. It refers to the X/Open XA spec, but that's not free. Also, as a side issue, the jta spec says that the XAResources should support sharing
Re: [JBoss-dev] JBoss pool (former Minerva) transaction bug?
WARNING this message is only for the brave :) I've looked into Tyrex source more closely First Tyrex decides if the transaction can be committed in 1 phase (i.e. optimized commit) if not, it goes into 2pc. In 2pc it does the following: It calls prepare() method which does a bunch of things 1. calls subordinate OTS resources to prepare and gets their votes, counting the commit votes and setting up a decision for the future on what to do (Tyrex calls it a heuristic). Initially the heuristic is READONLY but as OTS resources and XA resource are prepared this heuristic may change to ROLLBACK, MIXED, HAZARD, etc. 2. ends all the enlisted XA resources and calls prepare() on them and then on all the delisted XA resources as well 3. if all went well the transaction now is set to PREPARED state and it's current heuristic is evaluated the interesting case is here, even if the current heuristic is READONLY, but if you have 1 or more resource requiring a commit (remember, we've been counting those during prepare() on OTS and XA resources) the heuristic is set to COMMITTING 4. After all that, Tyrex evaluates what to do based on the current heuristic state. If it is READONLY, the transaction is really committed but if it is COMMITTING, Tyrex calls commit() on all the resources that require committing and then ____ calls forget on all of them. I have skipped a lot of error checking Tyrex does and the exceptions it throws at various points, the logic listed above is what goes on when my scenario is deployed In my scenario the originator tx has 2 subordinate transactions which are registered with the originator as OTS resources. When originator tx is asked to commit, Tyrex goes through the above sequence 1. prepares the subordinate transactions - the subordinate transactions prepare their XA resources (minerva) and return their votes, in my case: VoteCommit - the originator now has 2 resources that voted to commit 2. having no XA resources in the originator we skip the preparation of XA resources of the originator 3. now the originator makes a decision to commit because 2 of the resources voted to commit and none otherwise 4. the originator calls internalCommit() which calls commit() on all the resources that voted to commit in prepare() phase - this propagates the commit() to the subordinate transactions, those in turn call commit() on their XA resources 5. the originator calls forget() on all resources - this propagates the forget() to the subordinate transactions and their XA resources which causes an exception in Minerva because forget() is not allowed after a commit() Well, while I was going through all this stuff, I've decided to go back and look for documentation and realized I had it all along -- the ots spec, to which Tyrex conforms. It seems this is indeed another Tyrex bug.. sigh :( OTS spec says 10.2.6 HeuristicExceptions A heuristic decision is a unilateral decision made by one or more participants in a transaction to commit or rollback updates without first obtaining the consensus outcome determined by the Transaction Service. Heuristic decisions are normally made only in unusual circumstances, such as communication failures, that prevent normal processing. When a heuristic decision is taken, there is a risk that the decision will differ from the consensus outcome, resulting in a loss of data integrity. 10.5.1 Normal Transaction Completion Coordinator Role page 10-51 - The root coordinator issues forget to a resource after it receives a heuristic exception. In my scenario there are no exceptions, forget() should not get called... I'll get in touch with the Tyrex developers tomorrow. Thanks to everybody for their help in this. - Anatoly Akkerman Computer Science Dept. Courant Institute of Mathematical Sciences, NYU 719 Broadway, #715 Tel: 212 998-3525 New York, NY 10003 Fax: 212 995-4123 - On Thu, 31 May 2001, David Jencks wrote: Hi, Thanks for correcting your terminology to prepare, commit. I am not a total expert but I'm pretty sure of this. I think there is still a problem either with terminology or tyrex. Heuristics are used _only_ when the transaction manager loses contact with one of the parties to a multi-resource transaction after prepare starts and before commit finishes. I don't understand all the rules but basically if noone has committed ( all prepared or open) then you can roll back. If one party has committed you have to commit every party you can: all parties must have voted for commit. There is also a partial 1 phase optimization possible, which I think is what you are describing Tyrex as using: the tm can call prepare on all
[JBoss-dev] JBoss pool (former Minerva) transaction bug?
Hello everybody I am running into problems with JBoss pools and Tyrex. This time it is a 2pc hueristic commit issue. When Tyrex commits a distributed transaction in 2pc, it asks all the subordinate transactions to commit which ask their local XAResources to commit. Minerva on a commit call disassociates itself from the transaction (sets current to null). Tyrex upon getting successful commits from the XAResources, being in 2pc sets heuristic to COMMIT and asks the XAResources to forget() the transaction. Minerva throws an exception because it already disassociated itself from the transaction (i.e. current == null while id is not null). Also, minerva assumes that the forget() is always called when a commit() or rollback() have failed. Well, this is not really true, forget can get called during a heuristic commit as in the case described above. Anyone can suggest to me where I could find out what is the correct semantics of the API? I've tried the jta spec but could not see anything conclusive. Any idea how minerva should handle this properly? Also, as a side issue, the jta spec says that the XAResources should support sharing (3.4.6) which seems to be lacking from the minerva (JBoss pool) implementation? Am I making a mistake here? - Anatoly Akkerman Computer Science Dept. Courant Institute of Mathematical Sciences, NYU 719 Broadway, #715 Tel: 212 998-3525 New York, NY 10003 Fax: 212 995-4123 - ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Why ContainerRemote is not being sent?
While trying to deploy PetStore pieces across several JBoss instances to test my integration of Tyrex with JBoss, I ran into the fact that all bean proxies do not write the container field upon serialization if this Proxy is not local. I was wondering why was this necessary, meaning what would be wrong if we always sent it? Anatoly Akkerman. ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Bug in jnp (handling references to remote JNDI servers)
It seems to me that there is a bug in JNP NamingContext.checkRef() method Here is when I encounter BeanA is on host1, JBoss1 BeanB is on host2, JBoss2 BeanA is supposed to call BeanB, so it has an entry in jboss.xml that maps ejb-refejb/BeanB/ejb-ref to jndi-namejnp://host2:port/testapp/BeanB/jndi-name After obtaining the LinkRef and resolving it, JNP does not contact the remote server on the remote machine (checkRef() only obtains a new Naming for the server if the current one is null, which is wrong in this case of a remote reference, since we are leaving the current Naming of the local machine and have to contact the remote now). One way to fix it is to remove this if (naming == null) around checkRef() body but it would obviously hurt performace. Any better ideas? - Anatoly Akkerman Computer Science Dept. Courant Institute of Mathematical Sciences, NYU 719 Broadway, #715 Tel: 212 998-3525 New York, NY 10003 Fax: 212 995-4123 - ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Distributed Transaction Manager support (coming up)
Hi, For the past couple of weeks I've been integrating Tyrex DTM (tyrex.exolab.org) into JBoss. Things are coming along and in a few days I'll probably have a basic support for transaction propagation across 2 JBoss instances. I was wondering, how should I make my mods available (the code is really alpha) for the people who want to start working on it. The code also requires changes to the current JBoss implementation (in particular, TxInterceptorCMT and TxInterceptorBMT would rely on javax.transactions.TransactionManager interface to manage transactions, instead of using JBoss extensions to the API for thread association/disassociation. - Anatoly Akkerman Computer Science Dept. Courant Institute of Mathematical Sciences, NYU 719 Broadway, #715 Tel: 212 998-3525 New York, NY 10003 Fax: 212 995-4123 - ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
