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
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,
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)
{
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 ti
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
> > 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
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 o
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
Messages inlined...
> Not having yet thought about it more, I wonder if the spec-compliant jca
> autocommit behavior would help: in the absence of a explicit local tx or
> xa tx, all operations are performed in their own automatic tx.
>
> Hmm, maybe, maybe not. The local wrapper I just wrote ju
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 what I think is an
Informix Driver bug,
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
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
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 t
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
> Anyway, I think there is a real bug nearby that we
> need to fix. See
>
> http://jboss.org/forums/thread.jsp?forum=46&thread=1346&start=0&msRange=15
>
> If a jar file references a nonexistent jar file in
> the manifest classpath
> entry, something (the scanner???) goes haywire and
> keeps try
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 -
Fro
> 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 thes
> > 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 ma
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,
inste
> 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 co
> 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
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
simp
> 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: UR
> 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
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
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
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 applicatio
> 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 clas
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:0
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
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 t
anch change to see the comment.
>
>
> Scott Stark
> Chief Technology Officer
> JBoss Group, LLC
>
> - Original Message -
> From: "Larry Sanderson" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
>
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
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
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
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 Changes
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]>:
>
> > > Per
> 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 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,
>
> W
rk 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
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 Su
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/th
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
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
_
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
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
__
> There's an example in spec (EJB2.0 - 20.3.2) with
> the
> following relative
>
> ../products/product.jar#ProductEJB
>
> 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 applicati
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
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=detail&aid=542341&group_id=22866&atid=376687
Thanks
__
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
___
> 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=detail&aid=541255&group_id=22866&atid=376687
-Larry
_
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
53 matches
Mail list logo
