Hmm, well ...
Problem is that we introduce a lot of additional dependencies (Axis, wsdl4j,
commons-logging, tt-bytecode, etc.) on the testsuite then. Problem is that
we would have to make jboss.net a standard-module, but honestly we are
behind the
main release cycle: If everything goes ok, we wil
On Sun, Apr 21, 2002 at 07:11:52PM -0400, David Jencks wrote:
> 3. I'd like to have an actual user ask for this over explicitly listing the
> files in the deployment scanner.
I'm an actual user, and just the thought of reording by typing a bunch of
% mv 05my-application.war 06my-application.wa
Title: Nachricht
Thanks for the
massive support of this IMPORTANT, IMPORTANT
issue ... If Sun(TM) would count the Eou section in their
TOP-Bug list, we would be IMHO already in the upper half.
But let´s be sure
about this! Don´t let them assign some freshman on this bug! Make it a prime
m
> > David, if you are reading this... and got this far down... what is the
> > plan to
> > have this issue tied down and solved once and for all. I think the
> > approche
> > that dain, you and I discussed in Tahoe is along the correct lines.
> >
> > Do you have any idea when the wrinkles wi
No, it would show up on the RFE list, not the bug list.
Sun classified it as:
State In progress, ease-of-use enhancement
Doesn't that mean it shows on the RFE list? Then it would show at position 12 at the
moment since I just gave it the 180th vote.
Yes, Sun is very slow about updati
> 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 don't want to manage
>
> David, if you are reading this... and got this far down... what is the
> plan to
> have this issue tied down and solved once and for all. I think the
> approche
> that dain, you and I discussed in Tahoe is along the correct lines.
>
> Do you have any idea when the wrinkles will be sort
Yes, agreeded, but lets put this off until some of the other problems are
fixed.
There is nothing pressing us for this feature at the moment. Lets hold off
until the deployment and dependency system is fixed.
Either that or find a way to clone yourself.
--jason
Quoting David Jencks <[EMAIL
> 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
> scanner1 looks at dir1 with jar1, jar2jar 100 in it
>
> scanner 2 looks at dir2 with jar101...jar200 in it.
>
> I haven't checked recently but I thought scanning happened in its own
> thread.
Yes each DS which extends from ADS gets its own thread.
> scanner1 starts, new thread deploys j
Also..
I think we need a way of feeding configuration change scripts into the
server. For example, config snippets showing only the changed values for
the mbeans. Furthermore eventually we should make this transactional...
all changes succeed or you get back to your original state.
david jencks
Seems kind of tricky... but perhaps not. Since when we shutdown the server we
don't really undeploy right now, we simply stop and destroy... or do we
undeploy? Seems a bit risky, I can see someone developing a deployer whjich
would undeploy its children when stopping, which might be desirable
Number of tests run: 579
Successful tests: 563
Errors:7
Failures: 9
[time of test: 22 April 2002 6:37 GMT]
[java.version: 1.3.1]
[java.vendor: Blackdown Java-Linux Tea
On 2002.04.22 01:06:14 -0400 Jason Dillon wrote:
> I am not sure what you mean. Can you explain more?
>
> --jason
scanner1 looks at dir1 with jar1, jar2jar 100 in it
scanner 2 looks at dir2 with jar101...jar200 in it.
I haven't checked recently but I thought scanning happened in its own
> Multiple scanners make it difficult at best to define deployment ordering.
> URLDeploymentScanner is already written (by you, I might add) to handle two
Thanks for reminding me of the obvious...
> forms of deployment: Directory scanning and direct URL deployment. I am
> trying very hard NOT t
Most of this is taken care of by the xmbean persistence descriptors, and we
can add more as necessary. Read Juha's book, and look at the xmbean dtd.
I think the ways to undo a stored configuration are to explicitly undeploy
the mbean, either individually through some interface or by undeploying
Just gave my 3 votes.
Out of curiousity, assuming that Sun does nothing with this, or takes their sweet time
doing something about it, what is the plan from JBoss' perspective?
(A) Distribute a patched version of the JDK classloader
(B) delay the release of 3.0
(C) modify 3.0 not to use the U
I don't think that merging two sets of config is that much trouble, if you
start out with the xml, use them as defualts, then invoke the mbean setBLAH()
an interceptor checks a attrib store for a preconfigued value, if there is one
then it is used, else the provided value is used and that value
What is the hell about jboss-auto.jcml? Is it that you never quite know what
config is used? If so, then all of these solutions will result in this hell.
Though some like it hot... and for them we can provid some abstraction to
implement a file based persistence or jdbc or whatever. Then the
> > 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 am not sure what you mean. Can you explain more?
--jason
Quoting David Jencks <[EMAIL PROTECTED]>:
> I really hope I'm not throwing more fuel on any fires...
>
> If you have one scanner whose scanned directories can be ordered
> individually, you still get to specify the startup order of
Change Notes item #546958, was opened at 2002-04-22 04:47
You can respond by visiting:
http://sourceforge.net/tracker/?func=detail&atid=381174&aid=546958&group_id=22866
Category: JBossCX
Group: v3.0 (Rabbit Hole)
Status: Open
Priority: 5
Submitted By: David Jencks (d_jencks)
Assigned to: David J
=
==THIS IS AN AUTOMATED EMAIL - SEE http://www.lubega.com FOR DETAILS=
=
JAVA VERSION DETAILS
java version "1.3.1"
Java(TM) 2 Runtime Environment, Standard Edi
Number of tests run: 559
Successful tests: 540
Errors:11
Failures: 8
[time of test: 22 April 2002 4:44 GMT]
[java.version: 1.3.1]
[java.vendor: Blackdown Java-Linux Te
1. SOAP and CORBA clients will probably not be Java based. So no client
interceptors for them
2. I think advanced users may want to define different interceptor chains
for different EJBs.
3. Entity, Stateless, and Stateful beans all have different client
interceptor stacks.
So, there needs to
The problems with auto-jcml stuff was that it tried to merge two sets of
configuation data, one set that user maintained and another that was
application maintained. Maintain both sets of data was tricky and error
prone.
So my thoughts are, we need to be able to support:
1. manual service co
Bugs item #546940, was opened at 2002-04-21 21:51
You can respond by visiting:
http://sourceforge.net/tracker/?func=detail&atid=376685&aid=546940&group_id=22866
Category: None
Group: v3.0 Rabbit Hole
Status: Open
Resolution: None
Priority: 5
Submitted By: Scott McLaughlin (mclaugs)
Assigned to:
The jmx part of this is the persistence service, which is pretty highly
configurable. I think jbossmx has an xml-based persistence service
implementation. I also think it works best with xmbeans or at least
modelmbeans, another reason to migrate soon. So I think the technical
issue of storing t
I really hope I'm not throwing more fuel on any fires...
If you have one scanner whose scanned directories can be ordered
individually, you still get to specify the startup order of the directories
by how they are listed in the single scanner.
With more than one scanner, this may be less determi
Here's an example (a SOAP message):
http://schemas.xmlsoap.org/soap/envelope/";
SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/";>
The text of the header
A
B
The body double
Note that there are
Number of tests run: 577
Successful tests: 535
Errors:24
Failures: 18
[time of test: 22 April 2002 2:26 GMT]
[java.version: 1.3.0]
[java.vendor: IBM Corporation]
[java
Lets not force every user down that path... lets make it possible then let the
user choose.
--jason
Quoting David Jencks <[EMAIL PROTECTED]>:
> On 2002.04.21 21:21:55 -0400 Jules Gosnell wrote:
> >
> > So :
> >
> > persist any SPECIFIC settings made through the JMX agent and overlay
> > th
Quick thought... if there was a pluggable interceptor in the config service
which would filter values as well as some JMX interceptor that would persist
attribute changes...
Or even a pluggable interceptor around JMX attribute changes (for get config
service, cause it will just invoke the serv
> 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 shoul
> persist any SPECIFIC settings made through the JMX agent and overlay
> them on top of the DEFAULT settings contained in
> .sar/META-INF/jboss-service.xml.
The system in 3.0 can not do this. And I am not refering to using the JMX
agent at all.
In my production usage of JBoss, I use ant to f
On 2002.04.21 21:21:55 -0400 Jules Gosnell wrote:
>
> So :
>
> persist any SPECIFIC settings made through the JMX agent and overlay
> them on top of the DEFAULT settings contained in
> .sar/META-INF/jboss-service.xml.
This might be doable if we are really careful however in the bad old
da
Jason, thanks for trying to get this discussion back to something useful.
There's another thing I've mentioned a couple of times that I think is
relevant.
What's the relationship between the initial config supplied by
*-service.xml files and the possibly modified config in the mbean server?
If
So :
persist any SPECIFIC settings made through the JMX agent and overlay
them on top of the DEFAULT settings contained in
.sar/META-INF/jboss-service.xml.
but desist from the 'it's such a pain to unpack/repack' argument,
because, as we have shown, there is no need to repack.
Jules
Jaso
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
Number of tests run: 572
Successful tests: 531
Errors:25
Failures: 16
[time of test: 22 April 2002 1:4 GMT]
[java.version: 1.3.0]
[java.vendor: IBM Corporation]
[java.
Why?
--jason
Quoting Larry Sanderson <[EMAIL PROTECTED]>:
> > 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
> A jacorb.properties in run.jar would just avoid this warning:
>
> >
> > WARNING: no properties file found! This warning can be ignored for applets.
>
> > A file file called "jacorb.properties" or ".jacorb_properties" should b
On Sun, 21 Apr 2002, Jason Dillon wrote:
> I really don't like that we have to put stuff into run.jar to solve
> IIOP/JacORB specific problems. Can we get around this? Or is this just to
> make it work in IBM?
A jacorb.properties in run.jar would just avoid this warning:
> #
> 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
I think the claims of this being requested by users are suspect. Marc
presented some alternatives in the London training, and this one won a
vote. I don't think that means anyone asked for it or would find it
useful. It means it looked good after Marc's presentation.
Anyway, I think there is a
I agree, lets get a real use case then see what the simplest solution is. In
the mean time I don't see any reason not to make this pluggable, so that users
can come up with any arbitrary complexity for deployment scanning which they
have a jones for as long as we leave the default config s
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
> > But we don't do this... Jetty is part of the release, it is not a seperate
>
> > component which users download and configure.
>
> until the next release/important-bug-fix of Jetty.
> I thought your whole point was that they DO configure it ?
My point was much larger than Jetty, with respe
1. I think marc wanted the numbers at the beginning
1myjar.jar
2mysar.sar
3myear.jar
etc.
2. I don't think mixing ordering schemes within 1 directory has any chance
of working.
3. I'd like to have an actual user ask for this over explicitly listing the
files in the deployment scanner.
david jen
> don't be an ignorant bastard on your own idea and its actual
> implementation.
Whatever dude... I am enlightened to users needs, to the needs of IT
professionsals who need ease of configuration managment... I am enlightened to
the possibilities of creating a super system around JBoss which wi
Hmmm... Sun claims that their "Top 25 bugs" page is updated daily, but our bug still
hasn't cracked the top 25 today. As a matter of fact, if they updated now we would be
up at #8...
Corby
* * *
View thread online: http://jboss.org/forums/thread.jsp?forum=66&thread=13431
> 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
Ok this is more insanity... who was it that thought that renaming files as the
simiplest solution to ordering? Right and I am a goat "moo moo".
It works as it is right now... leave it alone. There is no need for prefixed
sorting or this cryptix semi-suffix sorting blah.
If users want this ma
This is insanity... how is renumbering your deployment files
simipler/easier/faster/better than opening up a config file and listing the
order there?
How?
--jason
> I agree, so let's drop it. I want the simplest numbering available
> 'UNIX-styleee' and for more advanced (read have time) the
I've integrated the Joram JMS testsuite into our testsuite.
I've added the target 'tests-objectweb-jms' to the /testsuite/build.xml to
execuite it.
It's still not executing 100% error free, but it's close.
We have some selector problems and the other problem is that our default
secutity restri
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
I really don't like that we have to put stuff into run.jar to solve
IIOP/JacORB specific problems. Can we get around this? Or is this just to
make it work in IBM?
--jason
Quoting Francisco Reverbel <[EMAIL PROTECTED]>:
> Sorry for the trouble. Port 5000 was just a random (and poor) choice
I thought we discussed this before, where it was agreed that the simple
solution was to have users explicitly list the users in the order they wanted
rather than implement another sorting system in UDS.
We already sort using DeploymentSorter (J/E/W/S as you called it), addinf this
prefix numbe
I am thinking that it should. Perhaps some of the other stuff under server
(org.jboss.jmx) too? Some stuff will have to stay (like the EJB adapter), but I think
that we should move what we can.
--jason
* * *
View thread online: http://jboss.org/forums/thread.jsp?forum=66&thread=13586
_
Ok thanks... but why does this failure mess up the boot up sequence?
Can we change the port so that XP users don't have this problem?
--jason
Quoting Adrian Brock <[EMAIL PROTECTED]>:
> Hi Jason,
>
> There is a service on Windows XP that sits on port
> 5000 (same one used by iiop).
> It is c
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
Can you do me a favoir and explain this in more detail... and example too. It
would save me the time to hunt down the relevent specs just to understand the
concept.
--jason
Quoting Matt Humphrey <[EMAIL PROTECTED]>:
> You can do this with namespaces. The stuff outside the tag is scoped
> wi
After I have patched the loadClassInternal in the rt.jar I am still
seeing the jboss lock up on deployment. Here are the two threads that
are actually doing something . I can see why CCRAPoll is hung because
the main thread has locked that classloader. But the "main" thread is
waiting to lock a cl
As long as they don't realise we're still using 2.4... ;-)
hehehe
c
marc fleury wrote:
>>http://developer.java.sun.com/developer/bugParade/bugs/4670071.html
>>
>
>Just went there and gave my 3 votes, I liked the comment at the end "large
>financial institution needing this for the ultimate dep
I just made this 133.
Jules
marc fleury wrote:
>>http://developer.java.sun.com/developer/bugParade/bugs/4670071.html
>
>
> Just went there and gave my 3 votes, I liked the comment at the end "large
> financial institution needing this for the ultimate deployment and
> upgrade..." yep this is
> 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
> http://developer.java.sun.com/developer/bugParade/bugs/4670071.html
Just went there and gave my 3 votes, I liked the comment at the end "large
financial institution needing this for the ultimate deployment and
upgrade..." yep this is what we use it for...
come on guys please go to the JDC, ope
|Anyway I'm starting to think being able to order deployments this way is
|probably a good idea, see my other post, just don't make it the only way.
I agree, so let's drop it. I want the simplest numbering available
'UNIX-styleee' and for more advanced (read have time) then the xml based
deploy
On 2002.04.21 15:46:46 -0400 marc fleury wrote:
> | | name="jboss.deployment:type=DeploymentScanner,flavor=URL">
> |
> |
> | |optional-attribute-name="Deployer">jboss.system:service=MainDeploye
> |r
> |
> |5000
> |
> |
> |
> | ./deploy/jar1.jar,
> | ./deploy/
|
|
|
|jboss.system:service=MainDeploye
|r
|
|5000
|
|
|
| ./deploy/jar1.jar,
| ./deploy/sar2.sar,
| ./deploy/war3.war,
| ./deploy/jar4.jar,
| ./deploy
|
|
|
|Which is easier, setting it one place here or changing n names in your m
|ant bui
PLEASE VOTE!!
I haven't used Sun's bug parade before... today I went and voted. For
those who haven't looked, with BugParade you get 3 votes you can apply to
any bug or request for enhancement you wish. You do not have to make any
comments. It is really quick, simple, easy, etc.
If you can m
It´s a rt.jar problem that happens on all platforms, now, and spuriously
(because it´s a threading issue and
Depends on when which classes are loaded!).
CGJ
-Ursprüngliche Nachricht-
Von: Marius Kotsbak [mailto:[EMAIL PROTECTED]]
Gesendet: Freitag, 19. April 2002 14:13
An: Jung , Dr. Chr
Is this a Win32/1.3.1 - problem only, or is it the same for linux? Is it
something that jboss has a problem with now (how often does it happen?),
or something that isn't implemented because of this. ( 1 voted 3 votes
on this, I think :-)
Marius
On fre, 2002-04-19 at 12:41, Jung , Dr. Christoph
I don't know the ins-and-outs of creating a change request, but was
wondering if for the next rc of jboss3-tomcat4 the tomcat4-service.xml
file could be changed in this way:
From this:
To this:
Currently it assumes the old JBoss-2.4.x-Tomcat-x.x.x dir structure
where jboss and tomcat/cat
The sourceforge project page is the gateway to all requests:
http://sourceforge.net/projects/jboss/
Scott Stark
Chief Technology Officer
JBoss Group, LLC
- Original Message -
From: "David Ward" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
C
Is there a way to access properties from the tomcat config? If so it should
set the log dir in ${jboss.server.home.dir}/log
--jason
Quoting David Ward <[EMAIL PROTECTED]>:
> I don't know the ins-and-outs of creating a change request, but was
> wondering if for the next rc of jboss3-tomcat4 t
The ANY content within a DTD will only allow 'any' content that is
currently defined in that DTD - not any content at all. Extremely sucky
since it really curtails the ability of an XML application (e
vocabulary) do carry arbitrary payloads. Don't know about XSD but I hope
it's better.
c
Dav
> 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
Sorry for the trouble. Port 5000 was just a random (and poor) choice I
have made when implementing the IIOP stuff.
I will change the default config and move IIOP to the port officially
reserved for IIOP, whatever such port is (do not have the OMG docs at
hand right now).
As for the warning co
All my problems with your idea of lexical ordering of deployment would go
away if it was optional, per directory. I can see that sometimes it will
be convenient. I don't want to have to number all the more-or-less
required packages in deploy, however.
How about if the deployment scanner mbean c
On 2002.04.21 14:02:40 -0400 marc fleury wrote:
>
> |just "I haven't taken the time to find out how the deployment works or
> test
>
> I wrote the fucking deployment.
Along with me, Jason, and Larry Sanderson, to name a few.
>
> |it, and my pet idea isn't implemented, so I'm going to bitch"
>
Bill
Why is it that we need to specify a client interceptor configuration per
JRMP invoker again? I know there was a good reason when you were discussing
with Francisco but I can't remember.
aren't these stand-alone, refered to by name and a bean can say "use these?"
independently of the invoker
|just "I haven't taken the time to find out how the deployment works or test
I wrote the fucking deployment.
|it, and my pet idea isn't implemented, so I'm going to bitch"
No in fact it is the contrary my pet idea was the directory names
first/second/third this is what the class in London deci
What problem are you trying to solve marc? You haven't indicated anything
that doesn't work except your personal ordering preference. What actual
deployment problem are you seeing right now with the current code? I
haven't seen you say "this can't be done easily with the current code",
just "I h
There's no problem using a jdbc 3 driver under jdk 1.3, since java just
thinks the new methods aren't part of the jdbc interfaces. Calling them is
another question;-)-- you'd have to cast to the specific driver's class.
The problem I'm having is that I am wrapping e.g. Connection. To compile
und
yes clearly best of both worlds.
marcf
|-Original Message-
|From: [EMAIL PROTECTED]
|[mailto:[EMAIL PROTECTED]]On Behalf Of Larry
|Sanderson
|Sent: Sunday, April 21, 2002 9:13 AM
|To: [EMAIL PROTECTED]
|Subject: Re: [JBoss-dev] SAR... Sucky ARchive ?
|
|
|I currently deploy jetty-plugin.
Ok you guys just talk without end and the simplest solution is still not
done,
I will have to do it just so that we have something that works.
Just pisses me off
marcf
|-Original Message-
|From: David Jencks [mailto:[EMAIL PROTECTED]]
|Sent: Sunday, April 21, 2002 9:45 AM
|To: marc fle
Thanks, Larry,
This is exactly the approach that I was suggesting.
Jules
Larry Sanderson wrote:
> 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
Jason Dillon wrote:
>>I weighed up the pros and cons of how Jetty should be distributed and
>>decided to leave it in a sar for the time being because it makes it much
>>easier to redistribute and install updated versions of Jetty and Jetty
>>is an independant project with a seperate release cyc
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
Is JDBC 3.0 a JDK 1.4 only feature? Is there going to be an optional
pack for 1.3 users? If not, that really sucks. If you want the new
drivers, you have to upgrade to a x.0 version VM. Sounds like a M$ move.
BTW, I searched google and couldn't find any info either way.
-dain
David Jencks
We can't compile against 1.2.2 either. I tried it last week.
-dain
marc fleury wrote:
> yes
>
> marcf
>
> |-Original Message-
> |From: [EMAIL PROTECTED]
> |[mailto:[EMAIL PROTECTED]]On Behalf Of Bill
> |Burke
> |Sent: Saturday, April 20, 2002 11:54 PM
> |To: Jboss-Dev
> |Subject: [JB
> Ok I am really tired of everything/everyone DOES THE SIMPLE NUMBERING OF
> DEPLOYMENTS WORK??? I WANT A YES/NO ANSWER.
>
> If I do 01first.sar and 02second.war do I get 01 first and 02 second?
>
> YES=NO
>
> ?
umm YES != No
the answer is NO
If you want deployments in a specific order li
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
It turns out there are some problems I didn't anticipate with the new
ConnectionManagers and the non-compliant jdbc wrappers we have, so I went
ahead and wrote a new, jca-compliant, lgpl local-tx wrapper. Since I'm now
developing on jdk 1.4 mostly, I made my new jdbc class wrappers conform to
jdb
patched the class org.apache.struts.digester.Digester
to use:
Thread.currentThread().getContextClassLoader().loadClass()
instead of
Class.forName()
and this fixed the first problem, but straight away ran into more of the same. So is
Class.forName() supposed to work with the new jboss3 classloadi
don't be an ignorant bastard on your own idea and its actual implementation.
|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
yes
marcf
|-Original Message-
|From: [EMAIL PROTECTED]
|[mailto:[EMAIL PROTECTED]]On Behalf Of Bill
|Burke
|Sent: Saturday, April 20, 2002 11:54 PM
|To: Jboss-Dev
|Subject: [JBoss-dev] is 1.2.2 support dead?
|
|
|If so, I can clean up some of the dead configuration stuff in
|standardjbos
PLEASE VOTE!!
I haven't used Sun's bug parade before... today I went and voted. For
those who haven't looked, with BugParade you get 3 votes you can apply to
any bug or request for enhancement you wish. You do not have to make any
comments. It is really quick, simple, easy, etc.
If you can m
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
1 - 100 of 108 matches
Mail list logo
