Bugs item #522617, was opened at 2002-02-25 12:15
You can respond by visiting:
http://sourceforge.net/tracker/?func=detail&atid=376685&aid=522617&group_id=22866
Category: JBossServer
Group: v3.0 Rabbit Hole
Status: Open
Resolution: None
Priority: 7
Submitted By: Scott M Stark (starksm)
Assigned
There is a fundamental weakness we carry in our design since 2.0 days
the jboss.jcml/service.xml files
we mix in SAR/jcml
existence of the bean
configuration of the bean
classes for the bean
If we change the configuration of the service we are requiring that we
restart the service. Only changes
David,
one wish you had is going to become true, the MCL is no longer useful in the
face of unified deployments with UCL.
for a cycling URL -> We can ask for what classloader (UCL in
MainDeployer) -> what deployment info for the UCL (we miss that map, but we
can do it at the deployment info leve
User: user57
Date: 02/02/25 23:24:52
Modified:jbossbuild.xml
Log:
o removed install-dependencies, each module hook will copy the
required thiordparty bits it requires unless a dependent module
already copied it
Revision ChangesPath
1.94 +118 -86 b
On Tue, 26 Feb 2002, marc fleury wrote:
> ok,
>
> still jet lagged... (australia!)
>
> So let's imagine that we multi-thread the MainDeployer, each deployment gets
> a thread.
>
> Each time a thread wants a class the ServiceLibraries tries and if it is a
> CNFE waits.
>
> when a class is register
Hi Jason
I saw it when I ran the testsuite but I don't know what causes the problem ?
Will look into it tomorrow.
Andy
- Original Message -
From: "Jason Dillon" <[EMAIL PROTECTED]>
To: "Andreas Schaefer" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Monday, February 25, 2002 10:23
Mai pen rai, no worries.
--jason
Hiram Chirino wrote:
> Yes, I appoligize if sounded harsh.. I just was not seeing the big
> picture. All I was hearing was the get it to boot off the network
> story which is WAY different from what you need in the embed in an
> application case.
>
> Regar
|I don't think this is a problem. The client is most likely a thread started
|by noticing a new package. Anyway, I think we need anyway a list of
|"waiting deployments" -- partly deployed stuff that is waiting. Now we
Yes, I am afraid of the verbosity of it.
|have mbeans that can be waiting fo
Hey, van you fix the managment test that is bust when you have time? I
looked it over briefly but did not see any obvious/simple way to fix it.
--jason
Andreas Schaefer wrote:
> User: schaefera
> Date: 02/02/25 22:14:46
>
> Modified:src/main/org/jboss/management/j2ee J2EEDeployedObjec
|Well, getRemote and invokeHome aren't exactly admin interfaces on a
|container, but they are there today. I think using the xmbean/modelmbean
|facilities to either supply 2 interfaces to one object or indicate which
|things are "human administratable" and which are internal will be useful.
oh..
Frustrated might be a better word...
Just keeping things in check. I don't understand all that cl magic anyways.
--jason
marc fleury wrote:
>|Seems like a hack.
>
>Hee hee, the kid's pissed off.
>
>RELAX!!! Go snowboard... with Scott... he is older, trust him...
>
>|What if the class never g
User: schaefera
Date: 02/02/25 22:14:46
Modified:src/main/org/jboss/ejb EjbModule.java
Log:
Added the creation of a default J2EEApplication when a standalone EJB
archive (JAR) is deployed because this is required by JSR-77.
Revision ChangesPath
1.4 +36 -14jbo
User: schaefera
Date: 02/02/25 22:14:46
Modified:src/main/org/jboss/management/j2ee J2EEDeployedObject.java
Log:
Added the creation of a default J2EEApplication when a standalone EJB
archive (JAR) is deployed because this is required by JSR-77.
Revision ChangesPath
1.6
ok,
you kids chill, drop E, come back high as kites and tell each other,
"you are a wonderful human being"
"no, *you* are a wonderful being"
"I love you man ""I love you too"
oka? sour pusses
etc etc
|-Original Message-
|From: [EMAIL PROTECTED]
|[mailto:[EMAIL PROTECTED]]On Behalf
Yes, I appoligize if sounded harsh.. I just was not seeing the big picture.
All I was hearing was the get it to boot off the network story which is
WAY different from what you need in the embed in an application case.
Regards,
Hiram
>From: "marc fleury" <[EMAIL PROTECTED]>
>To: "Hiram Chiri
On 2002.02.26 00:29:03 -0500 Jason Dillon wrote:
> >
> >
> >Well, my idea was that since Containers are mbeans already, why not
> >transform the dd's to mbean config. I'm still thinking about how to
> best
> >deal with subsidiary objects. I'm thinking if all the subsidiary
> objects
> >are javab
|Seems like a hack.
Hee hee, the kid's pissed off.
RELAX!!! Go snowboard... with Scott... he is older, trust him...
|What if the class never gets loaded? Does the
So there is this story, of a couple of dumb guys trying to enter the US and
get through custom, once has a bat and one has a skunk
On 2002.02.26 00:37:21 -0500 Jason Dillon wrote:
> Seems like a hack. What if the class never gets loaded? Does the
> client which wants to use it hang forever? If not how long do you wait
> for a class to load?
I don't think this is a problem. The client is most likely a thread started
by n
>
|>>I don't get it.. With the Boot class that I commit you can load all
|>>of JBoss's jar's off the network. If footprint is all you care about,
|>>you wont be able to beat the 7k boot.jar (unoptimized with debug).
|>>
|>>I just tested the Boot class out, and it can even boot JBoss 2.4.4
|>>
|>
Again for those that missed it...
--jason
Original Message
Subject: Embedable, ServerLoader, jboss-boot.jar, logging and more...
Date: Sun, 24 Feb 2002 03:37:31 -0800
From: Jason Dillon <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
With the seperation changes also come the first
I don't have it.
>From: Jason Dillon <[EMAIL PROTECTED]>
>To: Hiram Chirino <[EMAIL PROTECTED]>
>CC: [EMAIL PROTECTED], [EMAIL PROTECTED]
>Subject: Re: [JBoss-dev] 57 words... and a signature
>Date: Mon, 25 Feb 2002 21:35:24 -0800
>
>Please read the email I sent "Embedable, ServerLoader, jboss-b
Seems like a hack. What if the class never gets loaded? Does the
client which wants to use it hang forever? If not how long do you wait
for a class to load?
--jason
marc fleury wrote:
>ok,
>
>still jet lagged... (australia!)
>
>So let's imagine that we multi-thread the MainDeployer, each
Please read the email I sent "Embedable, ServerLoader, jboss-boor.jar,
logging and more...".
Or did this not make it to the list? I can't find it in the forums...
If you still don't get it then I will try to explain in different words.
--jason
Hiram Chirino wrote:
> I don't get it.. With
>
>
>Well, my idea was that since Containers are mbeans already, why not
>transform the dd's to mbean config. I'm still thinking about how to best
>deal with subsidiary objects. I'm thinking if all the subsidiary objects
>are javabeans they can be constructed easily from xml, through jaxb or
>ot
I don't get it.. With the Boot class that I commit you can load all of
JBoss's jar's off the network. If footprint is all you care about, you wont
be able to beat the 7k boot.jar (unoptimized with debug).
I just tested the Boot class out, and it can even boot JBoss 2.4.4
So I don't know why
|THERE IS ***ONE*** SEAT LEFT
Good news: we are SOLD OUT. :) I like Europe.
Good news: we will put a couple more seats as we might have some extra room
and there are always cancelations. Come it will be the last show of its
kind. Come!
|And you got 2 weeks to register.
this is still true, ge
On 2002.02.25 03:47:06 -0500 Sacha Labourey wrote:
> Hello,
>
> In the MainDeployer code, when you deploy a package containing
> sub-packages:
> - init will be called on the wrapping package first, then on the
> inside
> packages
> - create will be called on the inside packages first,
Hi Scott
Great but I did the same for the stand alone EJB
modules as well.
Please can you send me a patch as soon as possible to avoid conflicts
when code is updated in CVS.
I send this email to the developer list. Can you send them also to
the developer list as well.
Thanx - Andy
- Orig
User: d_jencks
Date: 02/02/25 21:15:02
Modified:src/main/org/jboss/deployment MainDeployer.java
MainDeployerMBean.java
Log:
Changed shutdown procedure to first undeploy all packages, then stop, destroy, and
remove all remaining registered mbeans
Revisio
User: d_jencks
Date: 02/02/25 21:15:02
Modified:src/main/org/jboss/system/server ServerImpl.java
Log:
Changed shutdown procedure to first undeploy all packages, then stop, destroy, and
remove all remaining registered mbeans
Revision ChangesPath
1.4 +47 -11jbos
ok,
still jet lagged... (australia!)
So let's imagine that we multi-thread the MainDeployer, each deployment gets
a thread.
Each time a thread wants a class the ServiceLibraries tries and if it is a
CNFE waits.
when a class is registered in the SL it notifiesAll threads waiting.
voila! auto-r
JBoss daily test results
SUMMARY
Number of tests run: 501
Successful tests: 492
Errors:4
Failures: 5
[time of test: 26 February 2002 5:11 GMT]
[java.version: 1.
JBoss daily test results
SUMMARY
Number of tests run: 501
Successful tests: 492
Errors:4
Failures: 5
[time of test: 26 February 2002 4:20 GMT]
[java.version: 1.
Probably the easiest way would be to subclass the SingleSignOn
Valve and use the session based cache to obtain the authentication
information.
Scott Stark
Chief Technology Officer
JBoss Group, LLC
- Original Message -
From: "Luke Taylor"
marc fleury wrote:
>|Changes to come will further absrtact and detach File usage, abstract
>|logging or provide
>|logging adapters, and provide an api for core system configuraton
>|(descriptors and such).
>
>This I cannot make sense of. I mean the point is weak.
>
Yes, yes the second 57 words a
Ok,
yes, it sounds like a corny song from the late 70's but really London is
coming up and is going to be one hell of a show. The last of its kind
worldwide as we are changing the formula for the next ones (next ones will
be San Fran/Montreal/Palma de Mallorca/(possibly) Hong Kong).
THERE IS **
JBoss daily test results
SUMMARY
Number of tests run: 501
Successful tests: 492
Errors:4
Failures: 5
[time of test: 26 February 2002 3:23 GMT]
[java.version: 1.
|Right now, shutdown happens by stopping, destroying, and unregistering all
|mbeans the ServiceController knows about. Since MainDeployer is not one of
|them, and since deployments are not usually mbeans themselves, this means
|the deployers don't get to do any cleanup and that in particular the
|Changes to come will further absrtact and detach File usage, abstract
|logging or provide
|logging adapters, and provide an api for core system configuraton
|(descriptors and such).
This I cannot make sense of. I mean the point is weak.
Don't complicate the codebase with nth degree bullshit FO
I ran out of words for the how. Such words (probably not limited to 57)
and more should go into a howto embed JBoss guide...
--jason
marc fleury wrote:
>Ok 57 congratulations, although you are a bit skimpy on the how
>
>|The embedding changes provides integrators with a simple API to
>|confi
Right now, shutdown happens by stopping, destroying, and unregistering all
mbeans the ServiceController knows about. Since MainDeployer is not one of
them, and since deployments are not usually mbeans themselves, this means
the deployers don't get to do any cleanup and that in particular the loca
Ok 57 congratulations, although you are a bit skimpy on the how
|The embedding changes provides integrators with a simple API to
|configure, start and stop JBoss.
|It will allow 99% of resources to be loaded off network, leaving the
|boot footprint small for
|limited devices.
this is a valid req
JBoss daily test results
SUMMARY
Number of tests run: 501
Successful tests: 491
Errors:4
Failures: 6
[time of test: 26 February 2002 2:54 GMT]
[java.version: 1.
Scott M Stark wrote:
> This is why the Catalina security integration implements both
> the Realm and Valve interfaces. The Realm callbacks establish
> the authentication and the Valve limits the scope of the information
> to the duration of the request. The thread of control returns to
> the Catal
Changes to come will further absrtact and detach File usage, abstract
logging or provide
logging adapters, and provide an api for core system configuraton
(descriptors and such).
MBeans will also be modified to return structured data instead of html
preformatted strings,
which could be rendered
The embedding changes provides integrators with a simple API to
configure, start and stop JBoss.
It will allow 99% of resources to be loaded off network, leaving the
boot footprint small for
limited devices.
This is achieved by seperating server interfaces from implemenation and
utilizing core
This has nothing todo with embedding. It simplifies usage of such
handlers which may be used inside the system. Since ServerImpl is where
the base gets initialized it seems logical that such init should be done
here.
Why the objection? I don't understand your motives here. 57 words
coming
And you explain in those 57 words why you need one in the embedding world
marcf
|-Original Message-
|From: [EMAIL PROTECTED]
|[mailto:[EMAIL PROTECTED]]On Behalf Of Jason
|Dillon
|Sent: Monday, February 25, 2002 6:10 PM
|To: marc fleury
|Cc: Jason Dillon; [EMAIL PROTECTED]
|Subject: Re:
User: user57
Date: 02/02/25 18:19:02
Modified:jbossbuild.xml
Log:
o build file clean up
Revision ChangesPath
1.93 +70 -98build/jboss/build.xml
Index: build.xml
===
RCS file: /cvsroot
User: user57
Date: 02/02/25 18:19:03
Modified:.build.xml
Log:
o build file clean up
Revision ChangesPath
1.19 +1 -17 jbosspool/build.xml
Index: build.xml
===
RCS file: /cvsroot/j
The default searching is still done by URL. When we need to search
JBoss packages then we can add that to the factory then.
--jason
Adam Heath wrote:
>On Mon, 25 Feb 2002, Jason Dillon wrote:
>
>>Looks like the default URL system doesn't work too well with our custom
>>class loading stuff...
Read this:
http://java.sun.com/j2se/1.4/docs/api/java/net/URL.html#URL(java.lang.String,
java.lang.String, int, java.lang.String)
--jason
marc fleury wrote:
>what the *fuck* is a protocol handler,
>
>please
>
>marcf
>
>|-Original Message-
>|From: Jason Dillon [mailto:[EMAIL PROTECTED
On Mon, 25 Feb 2002, Jason Dillon wrote:
> Looks like the default URL system doesn't work too well with our custom
> class loading stuff... so I implemented a factory that does the same
> thing that would happened if our classes were on the system cl and we
> set the pkgs prop. ServerImpl instal
ok here is an excercise for you
What are you trying to achieve in the embedding (LESS THAN 57 words)
I am serious about the 57 words limit, I don't want a mental diarreah email,
I want "this is what I am trying to do". It is an excercise the french go
through when they are young (and I was neve
Both setting the system property and installing a factory are both
standard methods for introducing custom protocol handlers.
I am not sure exactly why Class.forName() did not pick up the loaded
classes. If you can see why, please let me know, cause I don't get it.
As for the handler, it look
OK,
I see what they are doing and will add a call to
SecurityAssociation.setPrincipal(null)
after each request.
Scott M Stark wrote:
> This is why the Catalina security integration implements both
> the Realm and Valve interfaces. The Realm callbacks establish
> the authentication and the
what the *fuck* is a protocol handler,
please
marcf
|-Original Message-
|From: Jason Dillon [mailto:[EMAIL PROTECTED]]
|Sent: Monday, February 25, 2002 6:04 PM
|To: marc fleury
|Cc: Jason Dillon; [EMAIL PROTECTED]
|Subject: Re: [JBoss-dev] CVS update:
|jboss-common/src/main/org/jboss/ne
User: squirest
Date: 02/02/25 18:03:00
Modified:src/main/org/jboss/mx/modelmbean XMBean.java
Log:
moved and removed stuff. new items will go into capability until a better home can
be found
Revision ChangesPath
1.5 +30 -24jmx/src/main/org/jboss/mx/modelmbean/
User: squirest
Date: 02/02/25 18:02:59
Modified:src/main/org/jboss/mx/metadata MetaDataBuilder.java
StandardMetaData.java XMLMetaData.java
Added: src/main/org/jboss/mx/metadata AOResolver.java
MBeanCapability.java MBeanInfoConversi
User: squirest
Date: 02/02/25 18:02:59
Modified:src/main/org/jboss/mx/interceptor MBeanInterceptor.java
MBeanInvocation.java
Log:
moved and removed stuff. new items will go into capability until a better home can
be found
Revision ChangesPath
1.
User: squirest
Date: 02/02/25 18:03:01
Modified:src/main/org/jboss/mx/server MBeanServerImpl.java
Log:
moved and removed stuff. new items will go into capability until a better home can
be found
Revision ChangesPath
1.18 +94 -87jmx/src/main/org/jboss/mx/server
User: squirest
Date: 02/02/25 18:02:58
Modified:src/main/javax/management/relation RoleInfo.java
Log:
moved and removed stuff. new items will go into capability until a better home can
be found
Revision ChangesPath
1.5 +13 -13jmx/src/main/javax/management/rel
User: squirest
Date: 02/02/25 18:02:59
Added: src/main/org/jboss/mx/capability
AbstractInvocationDispatcher.java
DispatcherFactory.java DynamicMBeanDispatcher.java
MBeanDelegate.java ReflectedMBeanDispatcher.java
Change Notes item #522762, was opened at 2002-02-25 17:58
You can respond by visiting:
http://sourceforge.net/tracker/?func=detail&atid=381174&aid=522762&group_id=22866
Category: None
Group: v3.0 (Rabbit Hole)
Status: Open
Priority: 5
Submitted By: Jason Dillon (user57)
Assigned to: Nobody/Anony
So where we had a simple "System.setProperty(bla bla)" we now have a
factory, a stream handler that doesn't work reliably, a couple of
Class.forName() in the code (that OF COURSE don't work with the "custom
classloading") a lot of crazyness **we don't need**?
man, it makes me nervous I tell you,
User: squirest
Date: 02/02/25 17:56:55
Modified:src/main/javax/management ObjectName.java
Log:
small improvement to equals method
Revision ChangesPath
1.8 +12 -6 jmx/src/main/javax/management/ObjectName.java
Index: ObjectName.java
===
This is why the Catalina security integration implements both
the Realm and Valve interfaces. The Realm callbacks establish
the authentication and the Valve limits the scope of the information
to the duration of the request. The thread of control returns to
the Catalina pool with no thread local a
Looks like the default URL system doesn't work too well with our custom
class loading stuff... so I implemented a factory that does the same
thing that would happened if our classes were on the system cl and we
set the pkgs prop. ServerImpl installs this factory now instead of
setting the sys
User: user57
Date: 02/02/25 17:37:21
Modified:src/main/org/jboss/deployment MainDeployer.java
Log:
o remove nestedjar stuff again, should work by default now
o added warn log around njar usage to show any protocol exceptions
that are thrown
Revision ChangesPath
User: user57
Date: 02/02/25 17:37:21
Removed: src/main/org/jboss/net/protocol/nestedjar
NestedJarURLHandlerFactory.java
Log:
o remove nestedjar stuff again, should work by default now
o added warn log around njar usage to show any protocol exceptions
User: user57
Date: 02/02/25 17:36:24
Modified:src/main/org/jboss/system/server ServerImpl.java
ServerInfo.java ServerInfoMBean.java
Log:
o Added getProperty() to ServerInfo (easy acess to a sys prop w/o
having to search through showProp* output)
o
User: user57
Date: 02/02/25 17:28:37
Added: src/main/org/jboss/net/protocol URLStreamHandlerFactory.java
package.html
Log:
o Adding factory that will load handlers from org.jboss.net.protocol
as it appears that the URL version won't work with our cu
User: user57
Date: 02/02/25 17:28:37
Modified:src/main/org/jboss/net/protocol/njar Handler.java
Removed: src/main/org/jboss/net/protocol/njar
NestedJarURLHandlerFactory.java
Log:
o Adding factory that will load handlers from org.jboss.net.protocol
User: user57
Date: 02/02/25 17:28:37
Modified:src/main/org/jboss/net/protocol/nestedjar
NestedJarURLHandlerFactory.java
Log:
o Adding factory that will load handlers from org.jboss.net.protocol
as it appears that the URL version won't work with our cu
Yeah that is a serious problem, we need Session based authentication.
marcf
|-Original Message-
|From: [EMAIL PROTECTED]
|[mailto:[EMAIL PROTECTED]]On Behalf Of Greg
|Wilkins
|Sent: Monday, February 25, 2002 4:31 PM
|To: [EMAIL PROTECTED]; jules
|Subject: [JBoss-dev] Security problem in
Why did main deployer all of a sudden become super verbose? The
infromation that we need to get across to users/admins is "this is
deploying" and/or "this was deployed"... the rest is just debug noise
and makes difficult to can the logs and see what was deployed.
Can we please revert back to
There is a problem with the use of ThreadLocals to record Authentication
when the client (in this case Jetty) is using ThreadPools.
I have previously mentioned this, but now I have confirmation that it is
a problem for a Client.
He created a small thread pool for the listener (4 threads), then
I am sorry, I guess I was not being clear. I thought you were asking
> my question is, if I need to construct a JBossMQ
> QueueConnectionFactory and load it into WebLogic's
> JNDI so I can drive a WebLogic MDB off a JBossMQ
> queue, how do I create it ?
I gave you the answer. You can create a J
User: d_jencks
Date: 02/02/25 16:22:55
Modified:src/main/org/jboss/deployment DeploymentInfo.java
MainDeployer.java
Log:
changed to copy into unique jars. IMPORTANT NOTE: delete everything in
JBOSS_HOME/tmp/deploy or you will have conflicts with the previou
Anyh objection to use 'server' instead of 'servers'. The singular form
lines up better with the other directory names.
--jason
Scott M Stark wrote:
>No, he thought David's idea of moving everything to deploy
>was a bad idea. The suggestion from Hiram was:
>
>jboss/
>jboss/bin/
>jboss/lib/
>j
Does anyone else see cvs errors like this:
Received disconnect from 216.136.171.202: Command terminated on signal 1.
--jason
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
No, he thought David's idea of moving everything to deploy
was a bad idea. The suggestion from Hiram was:
jboss/
jboss/bin/
jboss/lib/
jboss/client/
jboss/servers/default
jboss/servers/default/conf
jboss/servers/default/tmp
jboss/servers/default/db
jboss/servers/default/deploy
jboss/servers/minim
Lucas;
Just for the record, WebLogic to JBossMQ is not a
specific scenario I am trying to support, but rather
it is an example of a generic scenario I am trying to
support in my framework.
I see your points, but it is common and supported
practice to serialize ConnectionFactory objects into
JNDI
I thought Marc nixed this idea
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On Behalf Of Scott
> M Stark
> Sent: Monday, February 25, 2002 6:29 PM
> To: [EMAIL PROTECTED]
> Subject: Re: [JBoss-dev] We need more configurations in the distribution
>
>
> That is
Bill Burke wrote:
> Never was much of a gaming freak. I guess you have to be under 22 years old
> to appreciate this? I haven't played a video game in 10 years.
>
Aimed at the geeks I guess, rather than the managers.
Still could've been worse - might've been from Star Wars/Trek...
Hey wait a
That is fine with me.
Scott Stark
Chief Technology Officer
JBoss Group, LLC
- Original Message -
From: "Jason Dillon" <[EMAIL PROTECTED]>
To: "Scott M Stark" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Monday, February 25, 2002 2:47
Not that I have a preference here, but I wanted to add that just because
Sun comes up with a standard... doesn't mean that it is the best API
available for the job. True it will probably get included into the
bloat of other code in the jdk and so it may make sence to use it just
because it wi
Bugs item #522617, was opened at 2002-02-25 12:15
You can respond by visiting:
http://sourceforge.net/tracker/?func=detail&atid=376685&aid=522617&group_id=22866
Category: JBossServer
Group: v3.0 Rabbit Hole
Status: Open
Resolution: None
Priority: 7
Submitted By: Scott M Stark (starksm)
Assigned
I picked up a copy early last week too, though I have not had too much
time to dig into it yet. So far it looks really good. JMX users of the
world thank you... as I might be able to understand ModelMBeans,
Notifications and relationships more.
Kudos!
--jason
Bill Burke wrote:
>Great job
It's kinda late... but what about stickers? I would put one on my car
and motorcycle... I would guess that others would too...
--jason
marc fleury wrote:
>OK
>
>we have a winner, well actually we have two.
>
>JBoss:
>All your J2EE are belong to us
>
>JBoss:
>May the source be with you
>
>Tha
Agreed. Did we ever decide on how to reorg things? I think that short
term that if we go with Hirams idea of server(s) directory and leave
lib, client and bin out on top then we can implement this soon.
I like the idea of having a per server config lib dir to keep core libs
seperated from ex
I have been using Ant in my production setup to generate the exact
config (copy, touch, link, whatever) needed to run the given JBoss node.
You might want to think about copying building an isolated jboss home
for the tests (pulled from the build jboss home). For example:
jboss-all/build/outp
G'day,
We have developed an application which is running without any problems
using the Orion Server, but we would like to offer our clients JBoss
also.
We have tried running the app with JBoss 2.4.4 (with TomCat 4.0.2) and
have encountered a problem when we try to forward from one JSP to
anothe
Bugs item #522617, was opened at 2002-02-25 12:15
You can respond by visiting:
http://sourceforge.net/tracker/?func=detail&atid=376685&aid=522617&group_id=22866
Category: JBossServer
Group: v3.0 Rabbit Hole
Status: Open
Resolution: None
Priority: 7
Submitted By: Scott M Stark (starksm)
Assigned
Never was much of a gaming freak. I guess you have to be under 22 years old
to appreciate this? I haven't played a video game in 10 years.
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On Behalf Of
> Hunter Hillegas
> Sent: Monday, February 25, 2002 4:52 PM
http://www.v-2.org/articles/ayb.html
for an explanation, or:
http://www.allyourbrand.org/
For a page that thinks(maybe rightfully so) that this phrase has been
mimicked WAY too many times.
>>> Dain Sundstrom <[EMAIL PROTECTED]> 2/25/02 2:38:50 PM >>>
> JBoss:
> All your J2EE are belong to us
It's a reference to a videogame port with really bad translation of the
words into English...
The original quote is something like "All Your Base Are Belong To Us".
http://www.allyourbase.net/
Hunter
> From: Dain Sundstrom <[EMAIL PROTECTED]>
> Date: Mon, 25 Feb 2002 15:38:50 -0600
> To: marc
On 02-02-26 0:17, "marc fleury" <[EMAIL PROTECTED]> wrote:
> OK
>
> we have a winner, well actually we have two.
>
> JBoss:
> All your J2EE are belong to us
>
> JBoss:
> May the source be with you
>
> Thanks for all the great proposals. We chose based on "we won" and went with
> classic stuff
> JBoss:
> All your J2EE are belong to us
Maybe I'm an idiot, but what the hell does this mean?
-dain
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[Hunter Hillegas]
> For those unable to attend, but that don't care about the raffle (or don't
> want to order 10), will the shirts be available any other way?
better yet, can the images be published or put on cafepress? It'd just
be zero hassle for the jboss group - if there's some money loss i
1 - 100 of 135 matches
Mail list logo
