Re: [JBoss-dev] Why are we using this bogus construct
If the map is seldom modified, then you can get around synchronization
with techniques like this. It is taking advantage of the fact that
assignement is an atomic operation. If the methods are like this:
public void someMethod()
{
HashMap localMap = null;
synchronized (clients)
{
localMap = new HashMap(clients);
}
// ... read/write work on local map ...
clients = localMap;
}
public void someOtherMethod()
{
HashMap localMap = clients;
// ... read-only work on local map ...
}
Now everyone can call someOtherMethod() without invoking the cost of
synchronization, and once they obtain localMap it is guaranteed not to
be modified. But someMethod() exists for those rare times when the map
does need to be modified.
I don't think this is as useful as it once was - synchronization is much
faster than it used to be.
-Larry
Scott M Stark wrote:
I have seen this usage construct in a few places in the code and it makes
no sense to me:
class X
{
HashMap clients = new HashMap();
public void someMethod()
{
synchronized(clients)
{
HashMap m = new HashMap(clients);
m.put(dc, cq);
clients=m;
}
...
}
public void someOtherMethod()
{
Iterator i = clients.keySet().iterator();
while( i.hasNext() )
{
...
}
}
}
The unsynchronized clients HashMap is synchronized and copied when
modified and accessed without synchronization in other contexts. This is
not thread safe for the accesses and makes for very expensive updates.
Why isn't the HashMap simply synchronized and used without copying?
Scott Stark
Chief Technology Officer
JBoss Group, LLC
---
This SF.NET email is sponsored by: FREE SSL Guide from Thawte
are you planning your Web Server Security? Click here to get a FREE
Thawte SSL guide and find the answers to all your SSL security issues.
http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
---
This SF.NET email is sponsored by: FREE SSL Guide from Thawte
are you planning your Web Server Security? Click here to get a FREE
Thawte SSL guide and find the answers to all your SSL security issues.
http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Why are we using this bogus construct
Isn't double checked locking something like this:
private HashMap cache = new HashMap();
public MyObject get(String cacheLookup) {
MyObject foo = (MyObject)cache.get(cacheLooku);
if (foo == null) {
synchronized (cache) {
foo = cache.get(cacheLooku);
if (foo == null) {
foo = new MyObject();
cache.put(cacheLookup, foo);
}
}
}
return foo;
}
I read an article in JavaWorld a long time ago that said this is not
required to work in a legitimate JVM, even though it does on all known
implementations. Unfortunately, I don't remember the how's or why's of it.
However, this is not what the code below is all about. In fact, you can
remove the synchronized block below and everything is still perfectly
thread safe. The whole point is that the member variable clients is
*NEVER* modified - only assigned to. In fact, it would drive the point
home even more if you did this:
private Map clients = Collections.EMPTY_MAP;
public void someMethod()
{
HashMap localMap = null;
localMap = new HashMap(clients);
// ... read/write work on local map ...
clients = Collections.unmodifiableMap(localMap);
}
public void someOtherMethod()
{
HashMap localMap = clients;
// ... read-only work on local map ...
}
Here, clients is always immutable, even though someMethod is able to
update it with a new value. No synchronization, yet perfectly thread
safe (although very expensive to modify).
-Larry
David Jencks wrote:
I think you are wrong, although I have trouble understanding all the issues
with this. I think this is a double checked locking idiom and I think it
is just as broken.
The guy who calls someOtherMethod will definitely see the correct hashmap,
but there is no guarantee that its state will match any particular state in
which it was put unless access to it is also synchronized.
Double checked locking is broken.
See Effective Java pp 193 ff and the various Double Checked Locking is
Broken websites.
As I understand it, problems with this construct are unlikely to appear
unless you are using something like a multiprocessor alpha box.
I think we should prove in some way that this construct is safe or remove
it.
david jencks
On 2003.02.13 13:00 Larry Sanderson wrote:
If the map is seldom modified, then you can get around synchronization
with techniques like this. It is taking advantage of the fact that
assignement is an atomic operation. If the methods are like this:
public void someMethod()
{
HashMap localMap = null;
synchronized (clients)
{
localMap = new HashMap(clients);
}
// ... read/write work on local map ...
clients = localMap;
}
public void someOtherMethod()
{
HashMap localMap = clients;
// ... read-only work on local map ...
}
Now everyone can call someOtherMethod() without invoking the cost of
synchronization, and once they obtain localMap it is guaranteed not to
be modified. But someMethod() exists for those rare times when the map
does need to be modified.
I don't think this is as useful as it once was - synchronization is much
faster than it used to be.
-Larry
Scott M Stark wrote:
I have seen this usage construct in a few places in the code and it
makes
no sense to me:
class X
{
HashMap clients = new HashMap();
public void someMethod()
{
synchronized(clients)
{
HashMap m = new HashMap(clients);
m.put(dc, cq);
clients=m;
}
...
}
public void someOtherMethod()
{
Iterator i = clients.keySet().iterator();
while( i.hasNext() )
{
...
}
}
}
The unsynchronized clients HashMap is synchronized and copied when
modified and accessed without synchronization in other contexts. This
is
not thread safe for the accesses and makes for very expensive updates.
Why isn't the HashMap simply synchronized and used without copying?
Scott Stark
Chief Technology Officer
JBoss Group, LLC
---
This SF.NET email is sponsored by: FREE SSL Guide from Thawte
are you planning your Web Server Security? Click here to get a FREE
Thawte SSL guide and find the answers to all your SSL security issues.
http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
---
This SF.NET email is sponsored by: FREE SSL Guide from Thawte
are you planning your Web Server Security? Click here to get a FREE
Thawte SSL guide and find the answers to all your SSL security issues.
http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en
___
Jboss-development mailing list
[EMAIL PROTECTED]
https
Re: [JBoss-dev] Why are we using this bogus construct
... do a bunch of reading on double checked locking ...
OK - I think I see where you are coming from now. Wow - I have to agree
with Joshua Bloch: wildly counterintuitive. Have you ever experienced
these things failing in the way you describe? How much performance gain
do VM's really acheive by being allowed this much leniency in their
memory management?
Last question: does the typical JBoss developer know about this?
Thanks for the info,
-Larry
David Jencks wrote:
On 2003.02.13 13:40 Larry Sanderson wrote:
Isn't double checked locking something like this:
private HashMap cache = new HashMap();
public MyObject get(String cacheLookup) {
MyObject foo = (MyObject)cache.get(cacheLooku);
if (foo == null) {
synchronized (cache) {
foo = cache.get(cacheLooku);
if (foo == null) {
foo = new MyObject();
cache.put(cacheLookup, foo);
}
}
}
return foo;
}
I read an article in JavaWorld a long time ago that said this is not
required to work in a legitimate JVM, even though it does on all known
implementations. Unfortunately, I don't remember the how's or why's of
it.
However, this is not what the code below is all about.
Your example is way too complicated. You don't need a hashmap.
The normal example is:
private static Foo foo = null;
public static Foo getFoo() {
if (foo == null) {
synchronized (Foo.class) {
if (foo == null)
foo = new Foo();
}
}
return foo;
}
anyone calling getFoo without synchronization may observe the returned foo
in a partially initialized state.
I think the jboss code has the same problem as double checked locking --
described by Joshua Bloch as wildly counterintuitive.
But in the absence of synchronization, reading a published object
reference does not guarantee that a thread will see all of the data that
were stored in memory prior to the publication of the object reference. In
particular, reading a published object reference does not guarantee that
the reading thread will see the most recent values of the data that
constitute the internals of the referenced object.
In fact, you can
remove the synchronized block below and everything is still perfectly
thread safe. The whole point is that the member variable clients is
*NEVER* modified - only assigned to. In fact, it would drive the point
home even more if you did this:
private Map clients = Collections.EMPTY_MAP;
public void someMethod()
{
HashMap localMap = null;
localMap = new HashMap(clients);
// ... read/write work on local map ...
clients = Collections.unmodifiableMap(localMap);
}
Unless Collections.unmodifiableMap is sychronized internally, the results
from this are garbage.
public void someOtherMethod()
{
HashMap localMap = clients;
// ... read-only work on local map ...
}
I don't think localMap has a accurate view of clients unless this is
synchronized. Just as with double-checked locking, it can read a partially
initialized version of clients.
david
Here, clients is always immutable, even though someMethod is able to
update it with a new value. No synchronization, yet perfectly thread
safe (although very expensive to modify).
-Larry
David Jencks wrote:
I think you are wrong, although I have trouble understanding all the
issues
with this. I think this is a double checked locking idiom and I
think it
is just as broken.
The guy who calls someOtherMethod will definitely see the correct
hashmap,
but there is no guarantee that its state will match any particular
state in
which it was put unless access to it is also synchronized.
Double checked locking is broken.
See Effective Java pp 193 ff and the various Double Checked Locking is
Broken websites.
As I understand it, problems with this construct are unlikely to appear
unless you are using something like a multiprocessor alpha box.
I think we should prove in some way that this construct is safe or
remove
it.
david jencks
On 2003.02.13 13:00 Larry Sanderson wrote:
If the map is seldom modified, then you can get around synchronization
with techniques like this. It is taking advantage of the fact that
assignement is an atomic operation. If the methods are like this:
public void someMethod()
{
HashMap localMap = null;
synchronized (clients)
{
localMap = new HashMap(clients);
}
// ... read/write work on local map ...
clients = localMap;
}
Unless setting clients is synchronized, anyone reading clients will recieve
a view of localMap in an inderminate state.
public void someOtherMethod()
{
HashMap localMap = clients;
// ... read-only work on local map ...
}
If clients is not read in a synchronized block, it is not guaranteed to be
the same as ANY version that was set. It could be a half-written copy.
Now everyone can call someOtherMethod() without invoking the cost of
synchronization, and once they obtain localMap
Re: [JBoss-dev] informix DS lock mode...
We use JBoss/Informix in production. We have searched and found no way to have the SQL: set lock mode to wait ? execute automatically on a given connection. We ended up wrapping Informix's driver to achieve this, and to work around some XA bugs in their driver. (We currently have 3 open tickets with IBM/Informix regarding their XA drivers). If you are interested, I could send you our wrapped drivers, though it is not too difficult to do. -Larry Jules Gosnell wrote: David, It will probably come down to the fact that Dynamo, another piece of infrastructure used here, allows the configuration of an SQL statement which is used to initialise each connection created by a pool. This is used for Pool-wide configuration such as this locking mode and other proprietary optimisations. Since it has not been mentioned, I assume that there is no similar mechanism in JBoss ? Cheers, Jules David Jencks wrote: On 2002.12.13 11:00:30 -0500 Jules Gosnell wrote: David Jencks wrote: On 2002.12.13 09:18:48 -0500 Jules Gosnell wrote: Is it possible to set up the lock mode for an Informix DS ? I've grepped through the src etc looking for any signs of set lock mode and others, but no joy... Not as far as I know. What does it do? How do you normally set it? Can you set it by supplying URL parameters? Is it an XADataSource attribute (in which case I think you can set it by supplying the value in XADataSourceProperties xa wrapper attribute)? As far as I can make out it determines the behaviour of a query arriving and finding the resource it requires already locked. It can return with an error, or wait for a specified amount of time. We are investigating as to whether it can be a URL parameter. I don't know about the XADataSourceProperties, but if it was there it would have showed up when I went through the code (3.0.5RC1). Well, actually not. You supply essentially a property file (name=value pairs) and the adapter wrapper tries to set them by reflection. you haven't supplying any info on _any_ working way of setting this parameter. Surely there is at least one:-) david Thanks for the response. It looks like we will have to find another way of setting it up explicitly. Jules thanks david jencks Cheers, Jules This email has been scanned for all viruses by the MessageLabs SkyScan service. For more information on a proactive anti-virus service working around the clock, around the globe, visit http://www.messagelabs.com --- 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 --- 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 This email has been scanned for all viruses by the MessageLabs SkyScan service. For more information on a proactive anti-virus service working around the clock, around the globe, visit http://www.messagelabs.com --- 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 --- 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 This email has been scanned for all viruses by the MessageLabs SkyScan service. For more information on a proactive anti-virus service working around the clock, around the globe, visit http://www.messagelabs.com
Re: [JBoss-dev] Over zealous deployers
No. I noticed this deplyment behaviour when I was working on the deployable directories, and I wanted to remove it then. As I recall, nobody else really thought it was a problem, and it was left in primarily to deply jar files nested within a sar archive. (Please, correct me if I am wrong here - it was a long time ago) However, I did modify the ear deployer to only deploy those archives mentioned in application.xml. Unless this has been modified since, ear files are not searched for deployable entities (although jar, sar, rar, ... archives are). -Larry On Sat, 2002-10-05 at 18:05, Jason Dillon wrote: I am not positive, but I think this might be part of the deployable directories support. --jason On 6 Oct 2002, Matt Goodall wrote: Hi, I'm new (about 1.5 hours altogether) to the JBoss source code so forgive me, and correct me, if I've got some of this wrong ... When I deploy an EAR the deployer deploys that EAR and *all* files contained inside if they are one of the types listed in SubDeployerSupport.isDeployable(). It actually calls isDeployable() for *every* file in the EAR including files like META-INF/MANIFEST.MF and META-INF/application.xml! I've also seen isDeployable() get called for every .class in a JAR. I found this problem on 3.0.2 but it still seems to be there in the latest CVS code. I'm pretty sure this is bug #589808; it's also been discussed in the web forums. I'm not sure why the deployer(s) work like this. Can someone explain it? Is there a good reason for it that I have not seen yet? (Another related issue is that EARDeployer behaves differently depending on whether the EAR is an archive or an unpacked directory.) My understanding is that only modules, i.e. the EAR and the modules listed in application.xml in this case, should be deployed and only dependent JARs listed in the manifest classpath should be loaded at all. I would like to fix this as it's stopping me moving up to 3.x. I think the following is necessary: 1. Look at the other deployers to see what they're doing. 2. Remove isDeployable() and any uses of it. 3. Fix any of the standard SAR/RAR/etc that haven't got a correct manifest classpath. 4. Fix the EARDeployer to deploy just the application.xml modules. I suspect that this change will improve deployment and startup time slightly (no directory scans and string comparisons) but, more importantly, it will make JBoss behave correctly. One of the big problems with fixing this is that it will break applications in 3.x that have not been packaged correctly. For that reason, it may be best to introduce the fix based on some configuration property and leave the current behaviour as default. Any comments before I start on this would be most welcome. Cheers, Matt --- 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 --- 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] [ jboss-Bugs-590816 ] XAProto Errors on closed XAResources
Only JBossMQ and Informix XA. Not SwiftMQ yet. Do you have a setup where you can test this? -Larry - Original Message - From: Jason Dillon [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, August 08, 2002 2:07 PM Subject: RE: [JBoss-dev] [ jboss-Bugs-590816 ] XAProto Errors on closed XAResources Have these patchs been used and verfified with JBossMQ and SwiftMQ? --jason -Original Message- From: [EMAIL PROTECTED] [mailto:jboss- [EMAIL PROTECTED]] On Behalf Of Larry Sandereson Sent: Thursday, August 08, 2002 2:03 PM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] [ jboss-Bugs-590816 ] XAProto Errors on closed XAResources I think I may have tracked down the SwiftMQ bug... let me know if this sounds right. SwiftMQ doesn't support start(suspend), so they return false for all calls to isSameRM(). This should cause all connections being enlisted to be given a unique xid (with different branch qualifiers). I think this is compliant with the JTA and XA specs. In enlistResource (TransactionImpl:535), a check is made to see if this RM is already enlisted (call to findResource). But, this check uses an equality test. If you are enlisting a connection that was previously closed in the same transcation scope, then this will find the old resource, and attempt to re-enlist with a TMJOIN, which on SwiftMQ yields an XAException (PROTO?). Basically, we can't assume that (resource1 == resource2) implies (resource1.isSameRM(resource2)). The problem now is that the TM must be able to enlist the same resource multiple times with different branch-ids, and then figure out which xid to use on the next call to delist. I have attached a patch (one for JBoss 3.1 one for JBoss 3.0) that I think fixes the problem. Please let me know what you think. -Larry --- 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 --- 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] [ jboss-Bugs-590816 ] XAProto Errors on closed XAResources
We already have one of these for InformixXA that I can donate. -Larry Could some of these problems be solved by using a custom driver layer which would resolve these issues at the JDBC layer? Dain was talking about doing something like this at the last SF training. Then we would have one driver, which would delegate to the db specific driver and resolve the issues before it even gets to an adapter. --jason Scott M Stark wrote: Why do we have to work around driver bugs at the transaction manager level? Why not write the TM the way we want and start introducing driver specific JCA wrappers to deal with these issues? Makes sense to me. Then, we wouldn't have to add extra code in the TM code to work around the multitude of different bugs in the different drivers. The downside is that quite a few different JCA wrappers would be needed for this. For example, just about every version of the Oracle XA drivers have different bugs. I'm not that familiar with JCA (still have to read up on that), but I wonder if it is possible to make stackable JCA wrappers that each fix one bug. If that is the case we could write: a) a JCA wrapper that fixes the res.end(suspend) followed by res.end(success) fails-bug, b) a JCA wrapper that fixes bug #585632. c) a JCA wrapper that fixes the problem some Oracle drivers have because they only accept their own Xid implementation. This wrapper would eliminate the need for the Xid factory in the TM code. Then the Oracle 8.1.7 driver could be wrapped in (a) and (b) above. Oracle 8.1.6 drivers would probably need wrappers (a) and (c). And the Sybase jConnect 5.2.1 would need wrapper (a) only. What do the JCA experts here think about this? --- 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] [ jboss-Bugs-590816 ] XAProto Errors on closed XAResources
SwiftMQ doesn't support start(suspend), so they return false for all calls to isSameRM(). This should cause all connections being enlisted to be given a unique xid (with different branch qualifiers). I think this is compliant with the JTA and XA specs. start(suspend) doesn't make sense to me. Do you mean end(suspend), start(resume) or start(join)? As you guessed, I meant start(join). So SwiftMQ doesn't support something it ought to for JTA compliance... And to get around that, it does something truly wierd. This may in some cases be heavy performance-wise, since there may be a lot of ==-equal resources enlisted with the TM. I have heard that some application servers in some cases delist before every call to another bean, and enlist again afterwards (that way the other bean can use the same connection, even if in another tx). Have you checked if this is listed as a bug in SwiftMQ? Andreas Meuller sent me this link: http://www.jguru.com/forums/view.jsp?EID=914840 Around the middle it explains that SwiftMQ returns false for all calls to isSameRM. I agree that it may well be a heavy performance hit, but I still believe it is compliant. Basically, we can't assume that (resource1 == resource2) implies (resource1.isSameRM(resource2)). Ouch. I have been assuming this, but when rereading the JTA specification, I see nowhere that we can assume this. JTA really ought to explicitly state if such an assumption can be made, or it will be a source of implementation errors. I agree. The problem now is that the TM must be able to enlist the same resource multiple times with different branch-ids, and then figure out which xid to use on the next call to delist. Agreed. I have attached a patch (one for JBoss 3.1 one for JBoss 3.0) that I think fixes the problem. Please let me know what you think. I just had a quick look at the 3.1 patch, and it looks fine to me. I have a question though: Why also check for RS_ENDED state? And a comment: In delist, probably an exception should not be thrown. False should be returned instead, and IMHO the exception at line 451 should also be changed to returning false. This is going to take a little explaining. I make the assumption that each XAConnection has an individual XAResource. If they are using some singleton concept for XAResources, then this technique will fail. (In fact, there would be no possible way to solve this problem if that was their approach.). Assume we are working with an RM that returns false always for isSameRM, and that it has not yet been enlisted in the current tx. The first enlistResource(rm) is trivial. After, one of two things can happen: delist(rm, success/fail) // rm status is RS_ENDED delist(rm, suspend) // rm status is RS_SUSPENDED (Note: it can't be enlisted yet, since the connection is not available to the free pool). In both cases, the connection is returned to the pool. Now someone can get that resource again, and enlists it in the same transaction. If it was ended with success/fail, then the original tx is ended, and a new one needs to be started. If it was suspended, then we need to resume. So we could be left with one of the follow: resourceState table (if first delist was success/fail): rm - ended rm - enlisted resourceState table (if first delist was suspend) rm - enlisted Continuing, the resourceState table would always look like: rm - ended rm - ended ... rm - ended rm - enlisted / suspended i.e. any number of ended states, possibly followed by a single state that is either enlisted or suspended. So, finally answering your question, the checks for RS_ENDED allow the search to skip over all the ended states, and get to the last one, if it exists. But still I wonder: What happens if several SwiftMQ ==-equal resources are enlisted in the same transaction. How do we ensure that it is the right resource that we call end() on? After all, we do not get the Xid supplied to the delist call, so we really have no way of knowing which Xid to end when the resources are ==-equal. Hopefully my explanation above explained it. If not, let me know and I will try again. -Larry --- 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] Why is new ObjectName() so slow?
Sorry if I'm just adding noise, but... It sounds like the biggest problem is that you keep parsing the same string into it's canonical form. Can't the jmx server cache the canonical names of the given ObjectNames? Then, for each new ObjectName(), check the cache, and if it doesn't exist, parse and cache the result. Am I missing something? -Larry - Original Message - From: Juha-P Lindfors [EMAIL PROTECTED] To: marc fleury [EMAIL PROTECTED] Cc: Jboss-Development@Lists. Sourceforge. Net [EMAIL PROTECTED] Sent: Sunday, April 28, 2002 12:36 PM Subject: RE: [JBoss-dev] Why is new ObjectName() so slow? On Sun, 28 Apr 2002, marc fleury wrote: |because an object name contains a set of properties that need to be |parsed and may also be a pattern which needs to be determined right the value=name pairs |the current implementation does this eagerly at object name creation |time can we do this lazily? can't we build equality and hash on the FULL string? no, we need a canonical presentation for equality check (because the name is a set of properties, not just an array of characters.. we need to sort the properties before we can check for equality) it strikes that the eager parsing is silly (eats up 50% of the time !!!) and only really useful in querying? Can you think of optimizations? the optimizations that we can do inside ObjectName would only include possibly optimizations to Java's string handling, maybe replacing generic collections with type specific ones, and avoiding Collections.sort() (I don't know how it is implemented or how well it performs). However, the problem with even these optimizations is that Sun plans to push JMX as part of JDK from the next 1.5 version on. They however have no plans to publish an SPI which means whatever is inside javax.management packages will from the next version on be Sun's implementation. And as you and I well know, Sun's implementation isn't exactly performing or industrial strength. The question at the moment is, why do you need to create an object name per invocation? Is it possible to cache the object names by mapping them to *real* identifies as opposed to this property nonsense? (how many MBean's do you imagine having in your server, could you create the object names for them on the server side and lookup the same instances from a cache -- I know it sounds ass backwards but given then future plans on JMX it would be best to avoid too much reliance on the JMX classes themselves. -- Juha ___ 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] XAManagedConnection and Informix Problems
I am using the org.jboss.resource.adapter.jdbc.xa.XAManagedConnection (and related Factory) to load my Informix XA JDBC connections.Unfortunately I am consistently getting XAExceptions, of the XAER_OUTSIDE variety. I have tracked the problem down to whatI think is an Informix Driver bug, but I was wondering if we should patch the JBoss transaction manager to correct for . Here's the issue: If a connection is used in local-transaction mode, the autocommit is set to false, and the user fails to call commit or rollback prior to closing the connection, then the connection is put back into the pool with the local transaction still open. Now, if that connection is used later within a global transaction, I get the XAException. I say that this is an Informix bug because I think most JDBC vendors automatically commit on closing within local transactions. The question is, should we put in a call to commit for all closes outside of a global transaction? The code is simple, but can you think of any negative repercussions if we do this? Thanks -Larry
[JBoss-dev] XA Specification
I'm trying to track down a bug with the JBoss TM and the Informix XA drivers (they keep throwing an XAException - XAER_OUTSIDE). Does anyone know where I can get a copy of the Open/XA specification? I found the following url: http://www.opengroup.org/products/publications/catalog/c193.htm, but the OpenGroup charges for their documentation (perhaps they should be called the OpenForThoseWithMoneyGroup). I don't mind paying the $25, but they want me to fax a request overseas, which is a pain. Thanks for any help, -Larry ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Build fails in Branch_3_0
It looks like the build.xml in the connector directory was not updated from head. There are some "JDK1.*" sections that need to be filtered. -Larry
Re: [JBoss-dev] Diffing entire CVS branches ?
Try something like this: cvs -q diff -r Branch_3_0 -r HEAD | grep RCS It's not the best, but it gets the job done. -Larry Someone (I think it might have been David) mentioned something about diffing the HEAD and 3.0 branches. Does anyone know if there is a good way todo this? I am a little concerned that some fixes are going into HEAD and are not making it into the 3.0 branch. If there is a nice tool that will do this then we can use it to send notices durring the final stages of a release. Anyone? --jason * * * View thread online: http://jboss.org/forums/thread.jsp?forum=66thread=13850 ___ 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] Problem deploying website content.ear in 3.1
Yeah - that was my bad - Sorry. I am removing the code that did this. (As
it happens, this is the same code that prevented classes loaded from
WEB-INF/lib from accessing those loaded from WEB-INF/classes). We really
need some test cases to expose these.
-Larry
- Original Message -
From: Jason Dillon [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Monday, April 22, 2002 12:16 AM
Subject: [JBoss-dev] Problem deploying website content.ear in 3.1
Once again I tried to start working on the new website... but I have run
into another problem. Looks like we are trying to deploy some files under
doco_files/ which are failing. Which is good to know, since those doco
files need to be updated or removed, but why is MD trying to deploy them in
the first place?
I don't recall this happening a few days ago either...
Also note at the end of this trace some componet is printing the trace to
System.err instead of logging. What is going on? I think we had removed
this usage of System.our err as well as Throwable.printStackTrace().
*sigh*
snip
2002-04-21 23:55:36,516 INFO [org.jboss.deployment.MainDeployer] Starting
deployment of package:
file:/C:/home/jason/workspace/jboss/jboss-all/build/output/jboss-3.1.0alpha/
server/default/deploy/content.ear
2002-04-21 23:55:36,516 DEBUG [org.jboss.deployment.MainDeployer] Starting
deployment (init step) of package at:
file:/C:/home/jason/workspace/jboss/jboss-all/build/output/jboss-3.1.0alpha/
server/default/deploy/content.ear
2002-04-21 23:55:36,626 DEBUG [org.jboss.deployment.MainDeployer] using
deployer org.jboss.deployment.EARDeployer@61899b
2002-04-21 23:55:36,626 INFO [org.jboss.deployment.EARDeployer] Init J2EE
application:
file:/C:/home/jason/workspace/jboss/jboss-all/build/output/jboss-3.1.0alpha/
server/default/deploy/content.ear
2002-04-21 23:55:36,656 DEBUG [org.jboss.deployment.EARDeployer]
Deployment Info: org.jboss.deployment.DeploymentInfo@40f3c71c{
url=njar:file:/C:/home/jason/workspace/jboss/jboss-all/build/output/jboss-3.
1.0alpha/server/default/tmp/deploy/C/home/jason/workspace/jboss/jboss-all/bu
ild/output/jboss-3.1.0alpha/server/default/deploy/content.ear/75.content.ear
^/content.war }, isDirectory: false
2002-04-21 23:55:36,686 DEBUG
[org.jboss.management.j2ee.J2EEDeployedObject] File:
file:/C:/home/jason/workspace/jboss/jboss-all/build/output/jboss-3.1.0alpha/
server/default/tmp/deploy/C/home/jason/workspace/jboss/jboss-all/build/outpu
t/jboss-3.1.0alpha/server/default/deploy/content.ear/75.content.ear,
descriptor: META-INF/application.xml
2002-04-21 23:55:36,686 DEBUG [org.jboss.management.j2ee.J2EEApplication]
Create J2EE Application, name: content.ear, server:
jboss.management.single:j2eeType=J2EEServer,name=Single
2002-04-21 23:55:36,686 DEBUG
[org.jboss.management.j2ee.J2EEManagedObject] getObjectName(), name:
jboss.management.single:J2EEServer=Single,j2eeType=J2EEApplication,name=cont
ent.ear
2002-04-21 23:55:36,696 DEBUG
[org.jboss.management.j2ee.J2EEManagedObject] postRegister(), parent:
jboss.management.single:j2eeType=J2EEServer,name=Single
2002-04-21 23:55:36,696 DEBUG [org.jboss.deployment.MainDeployer] found 1
subpackages of
file:/C:/home/jason/workspace/jboss/jboss-all/build/output/jboss-3.1.0alpha/
server/default/deploy/content.ear
2002-04-21 23:55:36,696 DEBUG [org.jboss.deployment.MainDeployer] Starting
deployment (init step) of package at:
njar:file:/C:/home/jason/workspace/jboss/jboss-all/build/output/jboss-3.1.0a
lpha/server/default/tmp/deploy/C/home/jason/workspace/jboss/jboss-all/build/
output/jboss-3.1.0alpha/server/default/deploy/content.ear/75.content.ear^/co
ntent.war
2002-04-21 23:55:36,696 DEBUG [org.jboss.deployment.MainDeployer] using
deployer org.jboss.jetty.JettyService@3a5c7a
2002-04-21 23:55:36,696 DEBUG [org.jboss.jetty.JettyService] Begin init
2002-04-21 23:55:36,696 DEBUG [org.jboss.jetty.JettyService] found parent
metadata:
file:/C:/home/jason/workspace/jboss/jboss-all/build/output/jboss-3.1.0alpha/
server/default/deploy/content.ear
2002-04-21 23:55:37,197 DEBUG [org.jboss.jetty.JettyService] End init
2002-04-21 23:55:37,197 DEBUG [org.jboss.deployment.MainDeployer] found 17
subpackages of
njar:file:/C:/home/jason/workspace/jboss/jboss-all/build/output/jboss-3.1.0a
lpha/server/default/tmp/deploy/C/home/jason/workspace/jboss/jboss-all/build/
output/jboss-3.1.0alpha/server/default/deploy/content.ear/75.content.ear^/co
ntent.war
2002-04-21 23:55:37,207 DEBUG [org.jboss.deployment.MainDeployer] Starting
deployment (init step) of package at:
njar:njar:file:/C:/home/jason/workspace/jboss/jboss-all/build/output/jboss-3
.1.0alpha/server/default/tmp/deploy/C/home/jason/workspace/jboss/jboss-all/b
uild/output/jboss-3.1.0alpha/server/default/deploy/content.ear/75.content.ea
r^/content.war^/doco_files/blackbox-xa.rar
2002-04-21 23:55:37,207 DEBUG [org.jboss.deployment.MainDeployer] using
deployer org.jboss.resource.RARDeployer@50988
2002-04-21 23:55:37,237 DEBUG
Re: WTF??? was RE: [JBoss-dev] SAR... Sucky ARchive ?
Anyway, I think there is a real bug nearby that we need to fix. See http://jboss.org/forums/thread.jsp?forum=46thread=1346start=0msRange=15 If a jar file references a nonexistent jar file in the manifest classpath entry, something (the scanner???) goes haywire and keeps trying to deploy the ./deploy directory as if it is a package. Presumably there is a missing existence check somewhere. I could not reproduce this bug on jdk1.4 for Windows. What VM was he using? I can try Sun's jdk1.3 - have you been able to reproduce this? -Larry * * * View thread online: http://jboss.org/forums/thread.jsp?forum=66thread=13522 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] SAR... Sucky ARchive ?
I currently deploy jetty-plugin.sar as an exploded archive. Best of both worlds: convenient organization, ability to modify jboss-service.xml on the fly, will automatically redeploy whenever the xml is touched. -Larry Well, perhaps not completly sucky, but as it is now it does suck. When I wrote that email long ago about those pesky birds, which eventually lead to .sar (and other things), I did not have this in mind. The idea was to make it *easier* to configuration components not complicate it. SAR as it is today only complicates... Take Jetty for example. I am a user and I want to change the port, or enable SSL or add a non-deployed webapp for development... how do I do that? I have to break open the jetty-plugin.sar, change jboss-service.xml, rejar it, then redeploy. What a huge pain in the ass! I think that the concept of a SAR is still useful and we should not cast it aside, but there are some limited cases where we would use one. For example, SAR is good for grouping like .jar's together. There are several jars needed for Jetty to work, and it makes sence to group them together inside of a super archive. When used in this manner it makes it easy to create an explicit classload hierachy (when we have that capability). SAR is also good if you want to distribute a set of native libraries. In this usage you would put in a version of the lib for all supported platforms. SAR is good to provide a static filesystem, or the intial structure for a dynamic filesystem which is needed. In all of these examples, SAR is used as a grouping tool, proving a wrapper around other files... but not specifing any service related configuration. Serivce config MUST be seperate from the archives. This is a huge defficeny with the EJB-JAR, EAR WAR formats from SUN. While it was a good idea to group the support files, it plain sucks ass to put the config in there too. SUN was assuming that everyone would have some fucking GUI crap to handle the details of opening the jar, finding the files, editing them and rejaring. * * * Ok that said, there are still some dependecny issues(both class MBean) in the current system which are holding us back... which I know people are working on solutions for... BUT we can work around some of those issues for the 3.0 release, pending some real hard thought and work into fixing this problem as well as other issues with the core system. Take Jetty as an example. jetty-plugin.sar is selfcontained and can be redeployed, so it is easy to develop that plugin with out having to cycle the server each time. The short-term solution to dropping this as SAR is to make a jetty-plugin.jar (in lib/) and jetty-service.xml (in deploy/). Since we don't (as far as I can remember) redeploy archives in lib/ we (or rather jules) looses some convienece when developing this. BUT... users gain the ability to simply edit the jetty-service.xml to change the config. AND we have the nice and simple answer to their questions about where do change this... instead of the alternative. * * * So, I think we need to rethink what SAR is good for and what it isn't. I think the list I mention above are really good uses for SAR and is why I think we should keep the concept around... BUT I really think we need to keep the seperation between support/code configuration. By doing this we make users lives easier and make it possible to implement some really interesting things on the configuration side, which would be a nightmare if we had to deal with these local file archives. --jason * * * View thread online: http://jboss.org/forums/thread.jsp?forum=66thread=13522 ___ 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-Bugs-544848 ] EAR Deployments don't work
Yeah, I am aware of this problem. A different classloader is now used to load classes and lib, and this is very bad. We can make them the same, but which do we use? A unified loader, or the servlet-containers loader? It is a simple fix to throw the WEB-INF/classes into the unified loader, but then there are problems if another version of those classes are needed by another archive. Alternatively, just leave it to the servlet class-loader, but they don't load entries specified in the Class-Path of the Manifest. I will back out my latest change to AbstractWebDeployer. I think the bugs it introduced are worse than the ones it fixed. I am trying to write some test cases to expose any of these failings, but I have never written JUnit TestCases before, and its taking me a while. -Larry I got worried about this thread so i tried it out myself. With a properly structured .ear file containing the stock standard struts-example.war that comes with struts, the RC1 distribution works fine, but the latest on branch_3_0 fails at servlet init time with CNFEs trying to load classes from the WEB-INF/classes directory. Stack trace indicates that it is the UnifiedClassLoader trying to load these files: ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: WTF??? was RE: [JBoss-dev] SAR... Sucky ARchive ?
No in fact it is the contrary my pet idea was the directory names first/second/third this is what the class in London decided was the simplest to use (as opposed to going and setting mbean names left and right which is the direction you are heading full speed). My 2 cents: For users who need this sort of behaviour, I think it would be nice, but I wouldn't want to force it down the throats of all users. Perhaps, deploy first any URLs whose names match the ordered deployment naming convention, then deploy everything else as it is done now. Was this what you had in mind? If this is the case, then I believe the naming scheme should be more mangled than just xxx1.jar, yyy2.ear, ... This could very easily be done on accident by unwary users (ex. myApp_ver3.jar). Perhaps force the name to be xxx_jborder_1.jar, or something else unlikely to be duplicated on accident. Also, I think that if a user does specify a particular ordering within the Scanners MBean config, then that should take precedence over anything else. -Larry ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: WTF??? was RE: [JBoss-dev] SAR... Sucky ARchive ?
As larry said (do you have rw yet?) Yup. I've already checked in at least one bug :-) let's not shove it down people's throat and let's document all of this. Case closed. Implementation needed :) Simple, and not too hacked implementation: Add MBean attribute to URLDeploymentScanner: URLComparator make default comparator point to: org.jboss.deployment.DeploymentSorter (make this a comparator that does the correct ordering) in scanDirectory, change: list = sorter.sortURLs(list); to: if (urlComparator != null) Collections.sort(list, urlComparator); This allows users unhappy with the ordering scheme to replace it with their own Comparator (or simply drop it to remove all ordering). If this sounds OK, I am mucking about in that code anyway. Would you like me to make these changes? -Larry ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: WTF??? was RE: [JBoss-dev] SAR... Sucky ARchive ?
I *really* don't like jar1.jar, sar2.sar. Let's make the naming convention a little less likely to stumbled upon by unknowing users. I suggest: jar_jb1.jar, sar_jb2.sar, etc... then the default sorting can look for indexed deployments first, and sort the remainder by type. This allows a simple, global comparator, but removes the fine-grained support you suggest. So given the following within a directory: jetty.sar my_ejb_ver4.jar jar_jb5.jar sar_jb10.sar This would order them thus: jar_jb5.jar -- all indexed deployments first sar_jb10.sar jetty.sar -- all others second, in order of sar,rar,jar,war,ear my_ejb_ver4.jar Hell, if they really need the flexibility you suggest then they can set up a second scanner, but I can't imagine any place where this is not sufficient. -Larry I'm not sure specifying the global sorter for a whole scanner is the way we want to go... on the other hand extensibility is nice... Do we want to encourage people to have lots of scanners? At the risk of making things more complicated than necessary, yet striving for simplicity, how about mbean code=org.jboss.deployment.scanner.URLDeploymentScanner name=jboss.deployment:type=DeploymentScanner,flavor=URL attribute name=ScanPeriod5000/attribute attribute name=URLs dir name=./deploy/core order=type/ dir name=./deploy/app order=lexical/ url name=.deploy/other/jar1.jar/ url name=.deploy/other/sar2.sar/ url name=.deploy/other/war3.war/ /attribute !-- Uncomment (and comment/remove version below) to enable usage of the DeploymentCache depends optional-attribute-name=Deployerjboss.deployment:type=DeploymentCache/de pends -- depends optional-attribute-name=Deployerjboss.system:service=MainDeployer/depend s /mbean mbean code=... name=jboss.deployment:type=DeploymentSorter,order=type/ mbean code=... name=jboss.deployment:type=DeploymentSorter,order=lexical/ The deployment scanner looks up the requested ordering using the naming pattern on the DeploymentSorter mbeans. I'm not sure if we really need explicit dependencies listed in the DeploymentScanner. Striving towards simplicity (believe it or not;-) david jencks On 2002.04.21 16:37:46 -0400 Larry Sanderson wrote: As larry said (do you have rw yet?) Yup. I've already checked in at least one bug :-) let's not shove it down people's throat and let's document all of this. Case closed. Implementation needed :) Simple, and not too hacked implementation: Add MBean attribute to URLDeploymentScanner: URLComparator make default comparator point to: org.jboss.deployment.DeploymentSorter (make this a comparator that does the correct ordering) in scanDirectory, change: list = sorter.sortURLs(list); to: if (urlComparator != null) Collections.sort(list, urlComparator); This allows users unhappy with the ordering scheme to replace it with their own Comparator (or simply drop it to remove all ordering). If this sounds OK, I am mucking about in that code anyway. Would you like me to make these changes? -Larry ___ 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: WTF??? was RE: [JBoss-dev] SAR... Sucky ARchive ?
This is insanity... how is renumbering your deployment files simipler/easier/faster/better than opening up a config file and listing the order there? There is already a hacked sorting in the URLDeploymentScanner... but it stops at extension comparison. This proposition extends that just a little to give the users more control and more choices (with this, configuration-phobes would not have to modify the config file). Maybe it is not useful to everyone (I'm positive that I will not need this in my current job), but Marc has mentioned that many users did express this as a need. I don't really care, but if you want it, I am willing to do it. -Larry ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: WTF??? was RE: [JBoss-dev] SAR... Sucky ARchive ?
Yes. The current UDS has a hacked sorting blah (which I was not found of, but is required for the system to work as it stands now). If you want to make the URLCompa* change to make this optional and pluggable then go for it. I would leave the default J/E/W/S comparitor in the default config though. Yes, please do... this will simplify UDS... perhaps while you are at it you can also implement some regex based filters? So we can ignore scanning dot files and such. Perhaps a pluggable URLFilter, and a RegexURLFilter impl? OK - Any objections if I implement David's proposed URL configuration format: attribute name=URLs dir name=./deploy/core/ dir name=./deploy/app / url name=.deploy/other/jar1.jar/ /attribute -Larry ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: WTF??? was RE: [JBoss-dev] SAR... Sucky ARchive ?
I want a distinction between directories to be scanned, and URLs to be deployed. This goes back to an earlier patch (that I never checked in) for URLDeploymentScanner. If you specify a URL that is the base of an exploded archive, then currently the scanner scans that directory. It should, instead, deploy the directory. The solution you presented at the time was to create an alternate scanner for this purpose. I don't like that since it violates the concept of exploded archives being treated just like their packaged counterparts. -Larry Why? --jason OK - Any objections if I implement David's proposed URL configuration format: attribute name=URLs dir name=./deploy/core/ dir name=./deploy/app / url name=.deploy/other/jar1.jar/ /attribute -Larry ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: WTF??? was RE: [JBoss-dev] SAR... Sucky ARchive ?
The solution you presented at the time was to create an alternate scanner for this purpose. I don't like that since it violates the concept of exploded archives being treated just like their packaged counterparts. What? No it does not at all. It is just the same, it is just a matter of which scanner it came from. yada-yada We do not want to get back into the monolithic component business again. Design with plugablility then make use of it when you need new functionality. If required refactor the existing components to better seperate the plugability... but don't go making simple components complicated when you could have easily created a replacment or peer to gain the same result. Multiple scanners make it difficult at best to define deployment ordering. URLDeploymentScanner is already written (by you, I might add) to handle two forms of deployment: Directory scanning and direct URL deployment. I am trying very hard NOT to complicate this issue, but we do need a solution for exploded archives. The simplest at this point is to preserve the functionality of URLDeploymentScanner, and that means make it understand exploded archives. You call it a hack, and I agree. However, we already have a hacked system that will hopefully be fixed shortly. Forcing me down the awkward path of well architect code that must function within a design that has outlived its usefulness is not the right answer. Let me hack this for now, and spend my time on a better designed rewrite. -Larry ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: WTF??? was RE: [JBoss-dev] SAR... Sucky ARchive ?
You are trying very hard to implement exploded archives... which I personally have little need for. But this thread was started by you, whose original complaint was that it is difficult to configure packaged archives. The answer is staring you in the face and you can't see it... Deploy these as exploded archives, and modify the configurations whenever you want. I thought you said you were going to make sorting pluggable... why don't you just go do that and leave this issue for later? I am about to check that in. This issue can wait, though I don't see why it should. I think it would be simpiler to subclass, thus only complicating the config for the very small percentage of users who will use this. If I am wrong, fine we will have this fixced for 3.1 and then we will all be happy. You call it a hack, and I agree. However, we already have a hacked system that will hopefully be fixed shortly. This is a rather lame answer... lets hack it up more because it is hacked already? You don't work for microsoft do you? That's crap, and you know it. If you're building a new house you can put up with a shitty apartment for a little while. Forcing me down the awkward path of well architect code that must function within a design that has outlived its usefulness is not the right answer. Ic, so because your functionality does not fit into the DS design due to a problem with the deployment dependency system the DS design is now useless? And you would rather hackup a component in this flawed design rather than work on fixing the root of the problem... Where are you coming from here? I have already expressed great interest in fixing the root of the problem. What I am presenting is a solution that will get us through until the process is complete. Fine. I give up - unless anyone else requests this and it is agreed that a hack is OK for now, I will not check this in. I'm going to bed. -Larry ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Deployment Design
Hi - This is a small list of requirements for JBoss's deployment process. Please provide as much feedback as you can and help fill in the gaps. Thanks. For the purpose of this document, the following Definitions will apply: ·user The user (usually a person) attempting to deploy an application ·application Anything that can be deployed. ·application type A particular type of application. (The currently known types are: service-archive (*.sar), service-xml (*service.xml), resource-archive (*.rar), generic-archive (*.jar,*.zip), enterprise-archive (*.ear), ejb-archive (*.jar), web-archive (*.war)) ·deployer From the users perspective, a piece of software meant to deploy a single type of application. In code, one deployer may be made up of many objects, or one object may act as multiple deployers. User Requirements: 1. All applications must be uniquely identified with a URL. 2. Deployment of all known application types must be possible. 3. Future deployment of currently unknown application types must be made possible with an available API that stresses (in order of priority) flexibility, simplicity, and performance. 4. If no existing deployer is capable of deploying an application, then that application should be put into a wait state. Once a suitable deployer is installed, the application should be deployed. 5. Each deployer must treat exploded archives exactly as it would the native archive. This allows a user to do development within a deployed archive. 6. Each deployed application should have an MBean capable of managing it. At a minimum, this MBean will allow undeploy, and redeploy operations. Typically, it will allow application-type specific monitoring and configuration. (How does this fit in with JSR-77?) 7. It must be possible for an application to be configured for deployment on startup of the application server. It must also be possible to hot deploy applications not available at the time of server startup. Both should be available for redeploy and undeploy at any time. 8. On deployment of any application, the user must be able to configure the following: · The URL of the application. · The application type / the particular deployer to use (optional - if not specified, the system should determine this automatically) · Auto-redeploy features. Each application-type should have specific semantics as to when the application should be redeployed (typically this makes use of the lastModified method on some URL). · To specify a directory that will automatically be scanned for deployable applications. The scan period should also be configurable. · An arbitrary list of Deployment-Type-Specific attributes (?? Cant think of any right now things like context-root for war-files, ... ??) 9. Deployers themselves should be Mbeans to better support monitoring and configuration. 10. Should we do any special dependency checking / handling? Perhaps just deploying in a specified order is enough? System requirements: 1. There must be some way to obtain information on existing deployers. Currently this is obtained from the listDeployers method of MainDeployer. 2. There must be some way to obtain information on currently deployed applications. This is currently available through getDeploymentInfo from MainDeployer. I believe this information should be flexible so that a particular deployer may provide additional information whenever available. At a minimum, the following information should be available: · url, localurl, watchurl · localclassloader · shortname I believe that this info should be contained within an MBean for easier monitoring. 3. The deploy system needs to be compatible with JSR-88. i.e. a third-party implementation of a deployment tool (as specified by JSR-88) should be able to generate compliant JBoss-specific deployment descriptors, deploy applications on 1 or more JBoss servers, and perform simple monitoring tasks on distributed J2ee applications - undeploy, redeploy, start, stop... (Note: there is some cross over with JSR-77) 4. Each deployment-type has different requirements with respect to Classloaders. Some need to make their classes available on a global level, some need to make them available only to other related applications (like en ejb-jar and war within the same ear), and some should hide their classes from everything except the deployed application itself. This level of flexibility needs to exist. 5. The following scenarios must be supported: · Multiple versions of the same application deployed simultaneously with different JNDI names / context-roots / ... · ... We need more examples here... * * * View thread online: http://jboss.org/forums/thread.jsp?forum=66thread=13513 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] [ jboss-Bugs-544848 ] EAR Deployments don't work
I'm also running into a problem that may be related to this. I have a .war (or the .war embedded in a .ear properly referenced in application.xml ... OK - A few questions. From where are you accessing this resource (i.e. the location of the directory or jar file where the accessing class lives). Is it in your WEB-INF/lib, WEB-INF/classes, sitting next to the war file? I'm going to assume that it is in the WEB-INF/lib directory, since the only change I made since RC1 would affect nested archives (usually located in WEB-INF/lib). Second question... Have you ever tried this scenario with 3.0 beta, prior to RC1? I am interested to know if that worked. From what I can tell from the class history, I don't think this would have worked, but I may be mistaken. A brief explanation of the classloader hierarchy: JBoss has a custom ClassLoader called the UnifiedClassLoader. ClassLoaders normally have a parent-child hierarchy, such that a child ClassLoader can see all classes loaded by the parent, but the parent cannot see those classes loaded by the child. The UnifiedClassLoader throws that concept out the window. Any class loaded by a UnifiedClassLoader can see every other class loaded by another UnifiedClassLoader, regardless of the parent child relationship. My original changes (in the RC1 release): The problem with war files is that Jetty and Tomcat use their own Classloaders to load up the war file. (This includes the lib and classes directories within WEB-INF). Since they are not using the UnifiedClassLoader, all of JBoss's normal classes can not see any of the files within the web archive. So, if struts.jar was located next to the war file, it would be loaded by JBoss and the UnifiedClassLoader, and when it came time to access your struts Actions (within your war file's lib or classes directories), it would get a ClassNotFoundException. This was the original problem on this thread. My most recent change: Since all classes need to be able to see each other, the obvious solution is to use the UnifiedClassLoader to load all classes. The fix I put in since RC1 was released was to use the UnifiedClassLoader on all nested deployable archives. This is (I think) exactly the way things were done prior to my work. The only problem is that it left out the WEB-INF/classes directory. The fix: I just need to load WEB-INF/classes with a UnifiedClassLoader and your problem should be solved. This is a fairly simple fix, and I will get it in today. I need to create some test cases to check all this, but that will have to wait for the weekend (Is it Friday already?) Sorry for the confusion. -Larry * * * View thread online: http://jboss.org/forums/thread.jsp?forum=66thread=13076 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] testsuite jdk1.4 compilation
In order to compile the org.jboss.test.util.TestConnection.java class with jdk1.4, several methods must be uncommented (the JDBC 3.0 methods). It used to be that these methods caused this class to not compile with jdk1.3 due to the missing class, Savepoint. But this class is now included in the jboss-jca.jar archive, and now jdk1.3 compiles it correctly. Will there be a problem if I check TestConnection in with the JDBC 3.0 methods uncommented? -Larry * * * View thread online: http://jboss.org/forums/thread.jsp?forum=66thread=13360 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] [ jboss-Bugs-544848 ] EAR Deployments don't work
Applications within an ear file will only get deployed if: 1) They are referenced from an application.xml module tag (rars,ejbs,wars, and client jars) 2) They are spcified in a META-INF / Class-Path entry of one of the the deployed applications from step 1. (See http://java.sun.com/j2se/1.3/docs/guide/jar/jar.html#JAR%20Manifest) Have you tried step 2 above? If so, let me know and I will try to reproduce it. -Larry It doesn't seem to be fixed. I just (18-Apr-2002 21:00 MET) compiled the latest code from Branch_3_0 and ran into the same problems again. I, too, bundled struts.jar with my EAR. I could only make it work by copying struts.jar to JBoss' lib directory. tom * * * View thread online: http://jboss.org/forums/thread.jsp?forum=66thread=13076 ___ 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] testsuite jdk1.4 compilation
It is still live on head. Is it needed anywhere? -Larry The TestConnection and TestDBDriver classes weren't being used for anything so I removed them a couple of days ago. Is your cvs up to date? Did I miss a branch? david jencks On 2002.04.18 14:01:58 -0400 Larry Sanderson wrote: In order to compile the org.jboss.test.util.TestConnection.java class with jdk1.4, several methods must be uncommented (the JDBC 3.0 methods). It used to be that these methods caused this class to not compile with jdk1.3 due to the missing class, Savepoint. But this class is now included in the jboss-jca.jar archive, and now jdk1.3 compiles it correctly. Will there be a problem if I check TestConnection in with the JDBC 3.0 methods uncommented? -Larry * * * View thread online: http://jboss.org/forums/thread.jsp?forum=66thread=13360 ___ 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: jboss/src/main/org/jboss/web AbstractWebContainer.java
User: lsanders
Date: 02/04/17 18:41:01
Modified:src/main/org/jboss/web AbstractWebContainer.java
Log:
WebContainers are now correctly populating the SubDeployments list. This
bug was introduced with the ExplodedDeployment patch. This fixes bug 544848.
Revision ChangesPath
1.45 +5 -1 jboss/src/main/org/jboss/web/AbstractWebContainer.java
Index: AbstractWebContainer.java
===
RCS file: /cvsroot/jboss/jboss/src/main/org/jboss/web/AbstractWebContainer.java,v
retrieving revision 1.44
retrieving revision 1.45
diff -u -r1.44 -r1.45
--- AbstractWebContainer.java 15 Apr 2002 02:48:53 - 1.44
+++ AbstractWebContainer.java 18 Apr 2002 01:41:01 - 1.45
@@ -159,7 +159,7 @@
@see org.jboss.security.SecurityAssociation;
@author [EMAIL PROTECTED]
-@version $Revision: 1.44 $
+@version $Revision: 1.45 $
*/
public abstract class AbstractWebContainer
extends SubDeployerSupport
@@ -258,6 +258,10 @@
{
log.error(Problem in init , e); throw new DeploymentException(e);
}
+
+ // invoke super-class initialization
+ processNestedDeployments(di);
+
log.debug(End init);
}
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jboss-system/src/main/org/jboss/deployment MainDeployer.java
User: lsanders
Date: 02/04/17 18:42:16
Modified:src/main/org/jboss/deployment MainDeployer.java
Log:
Provided propper handling for Class-Path entries in META-INF for exploded
archives.
Revision ChangesPath
1.29 +10 -5 jboss-system/src/main/org/jboss/deployment/MainDeployer.java
Index: MainDeployer.java
===
RCS file:
/cvsroot/jboss/jboss-system/src/main/org/jboss/deployment/MainDeployer.java,v
retrieving revision 1.28
retrieving revision 1.29
diff -u -r1.28 -r1.29
--- MainDeployer.java 15 Apr 2002 02:48:53 - 1.28
+++ MainDeployer.java 18 Apr 2002 01:42:16 - 1.29
@@ -58,7 +58,7 @@
* @author a href=mailto:[EMAIL PROTECTED];Marc Fleury/a
* @author a href=mailto:[EMAIL PROTECTED];Scott Stark/a
* @author a href=mailto:[EMAIL PROTECTED];David Jencks/a
- * @version $Revision: 1.28 $
+ * @version $Revision: 1.29 $
*
* @jmx:mbean name=jboss.system:service=MainDeployer
*extends=org.jboss.system.ServiceMBean,
org.jboss.deployment.DeployerMBean
@@ -729,7 +729,6 @@
classPath = mainAttributes.getValue(Attributes.Name.CLASS_PATH);
}
- URL[] libs = {};
if (classPath != null)
{
ArrayList tmp = new ArrayList();
@@ -745,14 +744,20 @@
try
{
- lib = new URL(sdi.url, tk);
+ if (sdi.isDirectory)
+ {
+ File parentDir = new File(sdi.url.getPath()).getParentFile();
+ lib = new File(parentDir, tk).toURL();
+ }
+ else
+ {
+ lib = new URL(sdi.url, tk);
+ }
if (!isDeployed(lib))
{
// Try having it as a full subdeployment
sub = new DeploymentInfo(lib, sdi);
-
- deploy(sub);
}
}
catch (Exception ignore)
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jboss-system/src/main/org/jboss/deployment MainDeployer.java
User: lsanders
Date: 02/04/17 18:55:23
Modified:src/main/org/jboss/deployment Tag: Branch_3_0
MainDeployer.java
Log:
Copying from Trunk
Revision ChangesPath
No revision
No revision
1.28.2.1 +10 -5 jboss-system/src/main/org/jboss/deployment/MainDeployer.java
Index: MainDeployer.java
===
RCS file:
/cvsroot/jboss/jboss-system/src/main/org/jboss/deployment/MainDeployer.java,v
retrieving revision 1.28
retrieving revision 1.28.2.1
diff -u -r1.28 -r1.28.2.1
--- MainDeployer.java 15 Apr 2002 02:48:53 - 1.28
+++ MainDeployer.java 18 Apr 2002 01:55:23 - 1.28.2.1
@@ -58,7 +58,7 @@
* @author a href=mailto:[EMAIL PROTECTED];Marc Fleury/a
* @author a href=mailto:[EMAIL PROTECTED];Scott Stark/a
* @author a href=mailto:[EMAIL PROTECTED];David Jencks/a
- * @version $Revision: 1.28 $
+ * @version $Revision: 1.28.2.1 $
*
* @jmx:mbean name=jboss.system:service=MainDeployer
*extends=org.jboss.system.ServiceMBean,
org.jboss.deployment.DeployerMBean
@@ -729,7 +729,6 @@
classPath = mainAttributes.getValue(Attributes.Name.CLASS_PATH);
}
- URL[] libs = {};
if (classPath != null)
{
ArrayList tmp = new ArrayList();
@@ -745,14 +744,20 @@
try
{
- lib = new URL(sdi.url, tk);
+ if (sdi.isDirectory)
+ {
+ File parentDir = new File(sdi.url.getPath()).getParentFile();
+ lib = new File(parentDir, tk).toURL();
+ }
+ else
+ {
+ lib = new URL(sdi.url, tk);
+ }
if (!isDeployed(lib))
{
// Try having it as a full subdeployment
sub = new DeploymentInfo(lib, sdi);
-
- deploy(sub);
}
}
catch (Exception ignore)
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jboss/src/main/org/jboss/web AbstractWebContainer.java
User: lsanders
Date: 02/04/17 18:55:23
Modified:src/main/org/jboss/web Tag: Branch_3_0
AbstractWebContainer.java
Log:
Copying from Trunk
Revision ChangesPath
No revision
No revision
1.44.2.1 +5 -1 jboss/src/main/org/jboss/web/AbstractWebContainer.java
Index: AbstractWebContainer.java
===
RCS file: /cvsroot/jboss/jboss/src/main/org/jboss/web/AbstractWebContainer.java,v
retrieving revision 1.44
retrieving revision 1.44.2.1
diff -u -r1.44 -r1.44.2.1
--- AbstractWebContainer.java 15 Apr 2002 02:48:53 - 1.44
+++ AbstractWebContainer.java 18 Apr 2002 01:55:23 - 1.44.2.1
@@ -159,7 +159,7 @@
@see org.jboss.security.SecurityAssociation;
@author [EMAIL PROTECTED]
-@version $Revision: 1.44 $
+@version $Revision: 1.44.2.1 $
*/
public abstract class AbstractWebContainer
extends SubDeployerSupport
@@ -258,6 +258,10 @@
{
log.error(Problem in init , e); throw new DeploymentException(e);
}
+
+ // invoke super-class initialization
+ processNestedDeployments(di);
+
log.debug(End init);
}
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] CVS update: jboss/src/main/org/jboss/web AbstractWebContainer.java
Oops - I will do that from now on.
-Larry
Include the full comment used on the alternate branch when doing
merges. If I go and look at the history of this file all I see is
Copying from Trunk with a Branch_3_0 filter and I have to go
hunt down the other branch change to see the comment.
Scott Stark
Chief Technology Officer
JBoss Group, LLC
- Original Message -
From: Larry Sanderson [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Wednesday, April 17, 2002 6:55 PM
Subject: [JBoss-dev] CVS update: jboss/src/main/org/jboss/web
AbstractWebContainer.java
User: lsanders
Date: 02/04/17 18:55:23
Modified:src/main/org/jboss/web Tag: Branch_3_0
AbstractWebContainer.java
Log:
Copying from Trunk
Revision ChangesPath
No revision
No revision
1.44.2.1 +5 -1
jboss/src/main/org/jboss/web/AbstractWebContainer.java
Index: AbstractWebContainer.java
===
RCS file:
/cvsroot/jboss/jboss/src/main/org/jboss/web/AbstractWebContainer.java,v
retrieving revision 1.44
retrieving revision 1.44.2.1
diff -u -r1.44 -r1.44.2.1
--- AbstractWebContainer.java 15 Apr 2002 02:48:53 - 1.44
+++ AbstractWebContainer.java 18 Apr 2002 01:55:23 - 1.44.2.1
@@ -159,7 +159,7 @@
@see org.jboss.security.SecurityAssociation;
@author [EMAIL PROTECTED]
-@version $Revision: 1.44 $
+@version $Revision: 1.44.2.1 $
*/
public abstract class AbstractWebContainer
extends SubDeployerSupport
@@ -258,6 +258,10 @@
{
log.error(Problem in init , e); throw new
DeploymentException(e);
}
+
+ // invoke super-class initialization
+ processNestedDeployments(di);
+
log.debug(End init);
}
___
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] jdk1.4 issue
That was quick - it worked perfectly (testsuite run: 3 failures, 34 errors). Thank you. Only one problem remains... the org.jboss.test.util.TestConnection class does not compile due to JDBC 3.0 additions. The same solution that was used in the connector module should work here. -Larry _ View thread online: http://main.jboss.org/thread.jsp?forum=66thread=12885 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] [ jboss-Patches-543611 ] Scan a deployable directory
Was the scanner ever intended to watch a single deployable file? Or just watch a directory containing deployable files? If it was just for watching a directory, then I agree... this patch does not belong here. In this case, a second scanner should be developed to just deployable units (with no watching sub directories). If this is done, should the current scanner be limited to only watching directories? Currently it does monitor both. Let me know how to procede. Thanks. -Larry First glance makes me think this functionality does not belong here... with this patch the scanner now needs to have access to subdeployer like functionality. I would prefer to keep UDS simple, and I believe that this patch (perhaps some of the other patches too, not sure) complicate this very simple component. I think that a sub-class would be better suited here, so we can keep the basic UDS functionality pure and simple. I would look into other ways to perform the same functionality... as this isDeplyable() method will become a maintenece problem... as subdeployers are added and removed this will need to change. Basicially I think this is a hack of an already hacked up deployment system. If you are set on adding this, then special case it with a subclass or help redesign the deployment system by adding this functionality to the list of requirements. --jason _ View thread online: http://main.jboss.org/thread.jsp?forum=66thread=12891 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] [ jboss-Patches-543611 ] Scan a deployable directory
That could work. We could deprecate the current URLs attribute, but preserve its current functionality for backward compatibility. (Or do we just drop it since we are still in beta?). -Larry _ View thread online: http://main.jboss.org/thread.jsp?forum=66thread=12891 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Deployer design
I have been working with the deployers for the last week or so, and I have been
thinking about some design changes that would help clean it up.
I see two major problems with the current usage: 1) MainDeployer is a bootstrapped
class, with no way to provide an alternate implementation, 2) All SubDeployers rely on
a concrete implementation of deployer: MainDeployer,
The first problem is easy to fix: provide a System-Property style configuration for an
alternate bootstrapped deployer.
The second problem is not so easy. I propose that we give more control to the
SubDeployers, and simplify the bootstrap deployer. I propose that we move all
life-cycle management of SubDeployers to the particular implementations of
SubDeployer. This eliminates the need for the bootstrapped deployer to manage each
SubDeployer's life cycle. Further, the bootstrapped deployer no longer has to manage
DeploymentInfo objects - this job has been passed down to the SubDeployer as well.
This allows each SubDeployer to create their own implementations of DeploymentInfo.
Finally, DeploymentInfo needs to be cleaned up - it has become a repository for
disparate, and often unnecessary information. Since SubDeployers are now allowed to
create their own implementations, all but the most common attributes can be removed.
Here are my thoughts for the public class structure:
[code]
public interface SubDeployer
{
boolean accepts(URL url);
boolean deploy(URL url);
boolean unDeploy(URL url);
boolean isDeployed(URL url);
DeploymentInfo getDeploymentInfo(URL url);
}
public interface Deployer extends SubDeployer
{
SubDeployer getSubDeployer(URL url);
void addDeployer(SubDeployer deployer);
void removeDeployer(SubDeployer deployer);
}
public class DeploymentInfo
{
// General cleanup
// make members private with accessors / mutators
// remove SubDeployment specific attributes
// (webContext,manifest,document metaData,etc...)
// These can be provided with subDeployment specific
// subclasses.
}
[/code]
Let me know if you have any comments. I would like to get started on this soon.
Thanks
-Larry
_
View thread online: http://main.jboss.org/thread.jsp?forum=66thread=12917
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Deployer design
I'm not entirely sure what you mean by the subdeployer's lifecycle. If
you
mbean the sequence of init, create, start calls, note that these are not
done all at once per package, but each step is run through every
subpackage
before the next is started. Keeping the functionality in MainDeployer
prevents a rogue SubDeployer from failing to deploy subpackages. Perhaps,
however, allowing this would be a good idea.
Basically, I propose that the sub-deployers should be able to process their
own nested deployments, and manage their lifecycles. In my previous
message, I implied that we replace the init/create/start with a single
deploy (and also the stop/destroy with undeploy). Sorry, I was simplifying
things for discussion - I don't really know if that is feasable or not. My
point was that the MainDeployer should not have to know about its
SubDeployer's nested deployments. Nor should the EARDeployer be concerned
if a nested war happens to have a jar file in its WEB-INF/lib directory.
This lifecycle flexibility allows, for example, the EARDeployer to do the
init / create / start methods on all ejb archives, before processing any of
the war files (just a hypothetical, I have not actually thought about this).
Of course, the SubDeployerSupport would provide a default implementation.
So is your idea that the only thing the MainDeployer is really does is
find
the deployer for each package and subpackage, and once found the deployers
themselves do all the work including calling subpackage deployers? It
would work, I don't have an opinion yet on if it is a good idea.
Yes, that is what I am proposing. I envision most of the standard
MainDeployer code being moved into SubDeployerSupport. If you take a look,
this is what my nested-archive patch has already done with some of the
logic. Basically, I have found it constraining to go through MainDeployer
for my previous development. These changes would give each SubDeployer all
the power currently held by MainDeployer, with very little extra work on the
developer.
-Larry
Thanks
david jencks
On 2002.04.14 17:16:03 -0400 Larry Sanderson wrote:
I have been working with the deployers for the last week or so, and I
have been thinking about some design changes that would help clean it
up.
I see two major problems with the current usage: 1) MainDeployer is a
bootstrapped class, with no way to provide an alternate implementation,
2) All SubDeployers rely on a concrete implementation of deployer:
MainDeployer,
The first problem is easy to fix: provide a System-Property style
configuration for an alternate bootstrapped deployer.
The second problem is not so easy. I propose that we give more control
to the SubDeployers, and simplify the bootstrap deployer. I propose
that
we move all life-cycle management of SubDeployers to the particular
implementations of SubDeployer. This eliminates the need for the
bootstrapped deployer to manage each SubDeployer's life cycle. Further,
the bootstrapped deployer no longer has to manage DeploymentInfo objects
- this job has been passed down to the SubDeployer as well. This allows
each SubDeployer to create their own implementations of DeploymentInfo.
Finally, DeploymentInfo needs to be cleaned up - it has become a
repository for disparate, and often unnecessary information. Since
SubDeployers are now allowed to create their own implementations, all
but
the most common attributes can be removed.
Here are my thoughts for the public class structure:
[code]
public interface SubDeployer
{
boolean accepts(URL url);
boolean deploy(URL url);
boolean unDeploy(URL url);
boolean isDeployed(URL url);
DeploymentInfo getDeploymentInfo(URL url);
}
public interface Deployer extends SubDeployer
{
SubDeployer getSubDeployer(URL url);
void addDeployer(SubDeployer deployer);
void removeDeployer(SubDeployer deployer);
}
public class DeploymentInfo
{
// General cleanup
// make members private with accessors / mutators
// remove SubDeployment specific attributes
// (webContext,manifest,document metaData,etc...)
// These can be provided with subDeployment specific
// subclasses.
}
[/code]
Let me know if you have any comments. I would like to get started on
this soon.
Thanks
-Larry
_
View thread online:
http://main.jboss.org/thread.jsp?forum=66thread=12917
___
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
Re: [JBoss-dev] Deployer design
YADD (Yet Another Deployer Design)... comments below. I see two major problems with the current usage: 1) MainDeployer is a bootstrapped class, with no way to provide an alternate implementation, 2) All SubDeployers rely on a concrete implementation of deployer: MainDeployer, Why do you need another impl of MainDeployer. This component serves to aggregate SubDeployers and to provide a common interface for clients into the deployment system. It might be doing a little much at the moment (I haven't looked at what the code looks like this week), but from a concept pov there is no reason to make this pluggable. I don't know... perhaps someone would like to add a custom layer of security on all deployments. Perhaps they would like to get an email when new deployments occur. Who knows? The point is I can see no down-side to making this pluggable, and it is a very easy patch. More important, though, is to prevent SubDeployers from accessing MainDeployer specific functionality. That is just bad design. Note, that this change will invalidate the Deployer usage which is needed for DeploymentScanner (including NetBoot caching components). That doesn't mean those components can not change to adapt to new designs, but it seems like your design is not taking this into account. I'm not sure what you mean here. By Deployer usage do you mean lastDeployed and lastModified? I had planned on leaving these in the DeploymentInfo object. What are NetBoot caching components? Let me know if you have any comments. I would like to get started on this soon. I think we need to think hard about the requirements of the deployment system... look at the current use cases and those we invision for the future before we start redesigning this critical subsystem again. This is definetly not going to happen for 3.0, perhaps 3.1-3.2. We really need to get this crap down right... we seem to change this every few weeks, which just causes trouble for those who rely on how it works, those who write documentation for it those who provide components around it. Let us take some time to get this done right... then leave it alone. I agree. Thanks for your feedback. -Larry ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Deployer design
Perhaps you can take an initial stab on a requirements list for the deployment systen, based on the existing proposals (specifically david's, mine yours + comments by jules and such). If you have time it would be helpful to move this work forward. I can find the time, but I think I am the least experienced JBoss user / developer on this thread. Once I have something to post, I will need a lot of feedback. I'll let you know when I have something. -Larry --jason Quoting Larry Sanderson [EMAIL PROTECTED]: YADD (Yet Another Deployer Design)... comments below. I see two major problems with the current usage: 1) MainDeployer is a bootstrapped class, with no way to provide an alternate implementation, 2) All SubDeployers rely on a concrete implementation of deployer: MainDeployer, Why do you need another impl of MainDeployer. This component serves to aggregate SubDeployers and to provide a common interface for clients into the deployment system. It might be doing a little much at the moment (I haven't looked at what the code looks like this week), but from a concept pov there is no reason to make this pluggable. I don't know... perhaps someone would like to add a custom layer of security on all deployments. Perhaps they would like to get an email when new deployments occur. Who knows? The point is I can see no down-side to making this pluggable, and it is a very easy patch. More important, though, is to prevent SubDeployers from accessing MainDeployer specific functionality. That is just bad design. Note, that this change will invalidate the Deployer usage which is needed for DeploymentScanner (including NetBoot caching components). That doesn't mean those components can not change to adapt to new designs, but it seems like your design is not taking this into account. I'm not sure what you mean here. By Deployer usage do you mean lastDeployed and lastModified? I had planned on leaving these in the DeploymentInfo object. What are NetBoot caching components? Let me know if you have any comments. I would like to get started on this soon. I think we need to think hard about the requirements of the deployment system... look at the current use cases and those we invision for the future before we start redesigning this critical subsystem again. This is definetly not going to happen for 3.0, perhaps 3.1-3.2. We really need to get this crap down right... we seem to change this every few weeks, which just causes trouble for those who rely on how it works, those who write documentation for it those who provide components around it. Let us take some time to get this done right... then leave it alone. I agree. Thanks for your feedback. -Larry ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development - This mail sent through IMP: http://horde.org/imp/ ___ 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] Deployer design
I have been planning for a long time and hope to be able to work on very soon another major change to deployment. My plan is to divide deployment up into: 1. add all the classes to the classloader 2. Transform all the dd's into mbean configuration (using xslt mostly) 3. Deploy the resulting mbean configurations. For instance in step 2, ejb-jar.xml, jboss.xml, and jbosscmp-jdbc.xml all get transformed into what are basically Container mbean configurations. Lets work together to see how these ideas fit. I would like to see what kind of ideas you have regarding the implementation of this design. It sounds very interesting. -Larry ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Deployer design
Don't underestimate yourself ;) I am just asking for a list of requirements right now, not a design... and of course we will give you feedback. I think you misunderstand me. I am as cocky and arragant as the next Java programmer, and I'm possitive I can design it better than every one else out there ;-) It's the JBoss experience I lack, so my use cases will not have the benefit of working experience. Thanks in advance for your feedback! -Larry --jason Quoting Larry Sanderson [EMAIL PROTECTED]: Perhaps you can take an initial stab on a requirements list for the deployment systen, based on the existing proposals (specifically david's, mine yours + comments by jules and such). If you have time it would be helpful to move this work forward. I can find the time, but I think I am the least experienced JBoss user / developer on this thread. Once I have something to post, I will need a lot of feedback. I'll let you know when I have something. -Larry - This mail sent through IMP: http://horde.org/imp/ ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] jdk1.4 issue
Jdk 1.4 balks when an entry in auth.conf is the empty string. This is a problem with the default set-up, because that the password for the Hypersonic DataBase. Since security setup is part of jboss-service, this failure causes JBoss to come crashing down. The simple solution is to remove the empty value from auth.conf (either comment out the password line, or give it a bogus password). If this is done, then of course no-one can log in to the DB server. I was able to work around these issues by specifying the username and password in the hsqldb-service.xml, and removing the dependency on the SecurityDomain. With this setup, the test-suite yielded 35 errors, and 3 failures. On a side note - If I build my environment from a cygwin bash shell, I get a build successful, and everything runs except for the jmx-rmi-adaptor. Apparently, rmic missed a file. -Larry _ View thread online: http://main.jboss.org/thread.jsp?forum=66thread=12885 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Exploded archive deployment
Yeah, my comments weren't the best. I suck at coming up with concise, descriptive comments. Anyway: 1. indefinitely nested deployments are useful and used. I don't see any reason to restrict the depth. The spec requires jar in rar in ear. This is of course still allowed. Here is an example of what I restricted: [code] foo.jar - deployed +- temp (directory) | +- bar.jar (used to be deployed, but no longer) +- sub.jar (still deployed) +- junk (directory) | +- stuff.jar (used to be deployed, but no longer) +- abc.jar (still deployed) ... [/code] I needed to do this to allow, for example, the ejb-jar to remain exploded within the ear. Then the sub-directory itself is deplyed. I'm sorry if this explanation is not clear - let me know if you have questions. 2. As I recall deploymentInfo had the info on what to watch. Is this otherwise inaccessible to the deployment scanner? The deploymentInfo is maintained in the deployers, and exposed via the getDeploymentInfo method of the MainDeployer. I could have used that, though I would have had to mark the method as a jmx-operation to do so. (The scanner accesses its deployer via JMX). Since the scanner was developed with no knowledge of DeploymentInfo, I thought it would be good to keep that separation, so I added a method that just returns what the scanner needs - the URL to watch. Of course, I'm happy to change this if you like. -Larry _ View thread online: http://main.jboss.org/thread.jsp?forum=66thread=12665 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Exploded archive deployment
There's an example in spec (EJB2.0 - 20.3.2) with the following relative ejb-link ejb-link../products/product.jar#ProductEJB/ejb-link Does your patch still deploy product.jar? Regards, Adrian That's a new one on me. No, my patch would not allow this to deploy. (Nor would it allow your application.xml to specify an ejb-jar, web-app, or client jar in any nested directory). It is a simple thing to change back (actually, I just delete 4 lines of code), and the rest of the submission continues to work correctly. However Vesco Claudio and David Jenks provided a much better solution... Allow each deployer to pick and choose what sub-deployments are needed. This allows you to have a valid ejb-jar (for example) within your ear, but if it is not mentioned in your application.xml, then it will not be deployed. This doesn't sound too difficult... I will give it a try and let you know. -Larry _ View thread online: http://main.jboss.org/thread.jsp?forum=66thread=12665 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Compile error on w2k
I'm using Win2k SP2 (JDK 1.4 / cygwin) with no problems. Well... almost no problems. After a clean checkout and build, I need to add a non-empty password to the DefaultDbRealm in auth.conf. Without this, the server fails and shutsdown on startup. -Larry _ View thread online: http://main.jboss.org/thread.jsp?forum=66thread=12675 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Why copy all deployed files?
Just curious - why does JBoss make a copy of everything that goes through the deployer? It makes sense for remote archives, but it seems wasteful to do this for every file on my classpath. Does this help with the auto-redeploy features? Thanks -Larry _ View thread online: http://main.jboss.org/thread.jsp?forum=66thread=12615 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Exploded archive deployment
I just submitted a bunch of patches to allow archives (sar,rar,jar,war and ear) to be deployed in their exploded form. Could someone with CVS write permissions look them over? http://sourceforge.net/tracker/index.php?func=detailaid=542341group_id=22866atid=376687 Thanks _ View thread online: http://main.jboss.org/thread.jsp?forum=66thread=12665 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] JBoss 3 users -- warning of impending configuration change
PLEASE CONTRIBUTE YOUR NEW WORKING CONFIGURATIONS! Here is one for the Informix DB. The XA portion only works if the following patch is applied: http://sourceforge.net/tracker/?func=detailaid=541255group_id=22866atid=376687 -Larry _ View thread online: http://main.jboss.org/thread.jsp?forum=66thread=12301 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development Sponsored by http://www.ThinkGeek.com/
[JBoss-dev] building with Jikes
Do any of you use Jikes to build JBoss? I tried using Jikes v.1.14 on Win 2K, and the build failed - apparently Jikes does not accept local inner-classes within static methods, so I had to tweak the org/jboss/mq/xml/XElement.java file. Then the build succeeded, but I got a java.lang.Verify error while starting the jetty-plugin MBean. After switching back to javac, these problems have disappeared. I was just wondering if anyone has had better experience. Thanks, Larry _ View thread online: http://main.jboss.org/thread.jsp?forum=66thread=11372 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
