(when) does it make sense to backport this to the 3.2 branch?
how much effort is it?
Holger
On Tue, 2002-12-17 at 07:37, Andy wrote:
> Hi Geeks
>
> I just checked in the latest update of the EJB Timer Service. I added a
> simple
> file-based persistence layer, finished the implementation of the
Ok. You can omit the provider url and the client will issue a naming discovery
request. When running in an environment with the HANamingService the
client will receive an arbitrary response from a member of the cluster with
an HA-RMI proxy back to the HAJNDI naming service.
xxx
whau, never tried
thanks a lot
bax
> Von: "Bill Burke" <[EMAIL PROTECTED]>
> Antworten an: [EMAIL PROTECTED]
> Datum: Fri, 20 Dec 2002 01:24:45 -0500
> An: <[EMAIL PROTECTED]>
> Betreff: RE: [JBoss-dev] lookup the unknown
>
> If you provide no provider url, the jnid client will do a multica
WOULD YOU LIKE TO HAVE YOUR MESSAGE SEEN BY OVER
15.1 MILLION TARGETED PROSPECTS DAILY?
Below contains all the information you will ever need to market your product or
service on the Internet.
If you have a product, service, or message that you would like to get out
to Thousands, Hundreds of
If you provide no provider url, the jnid client will do a multicast
broadcast to find jndi server.
Bill
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On Behalf Of Scott
> M Stark
> Sent: Friday, December 20, 2002 1:17 AM
> To: [EMAIL PROTECTED]
> Subject: Re:
> What do you mean by the jboss jndi tree other than enumeration of the
> InitialContext.lookup("") recursively? JavaGroups does not know anything
> about JNDI.
>
i - the 'client' - do simply not know the ip adress of the host which has to
be named in the jndi.properties
simple service discovery
What do you mean by the jboss jndi tree other than enumeration of the
InitialContext.lookup("") recursively? JavaGroups does not know anything
about JNDI.
Scott Stark
Chief Technology Officer
JBoss Group, LLC
- Original Message -
From: "H
Some deployers go beyond just the name to determine if they handle
a given type of archive. The main deployer just determines which
deployer handles a given deployment archive and hands it off.
Plain old jars referenced by other deployments are deployed first.
As long as there is a manifest classp
JBoss daily test results
SUMMARY
Number of tests run: 1039
Successful tests: 1030
Errors:8
Failures: 1
[time of test: 2002-12-20.03-55 GMT]
[java.version: 1.3.1_
hi,
is there a possibilty to lookup the jboss jndi tree via javagroups or
similar mech from the 'client'?
if -> how?
any hint, readings, pointings, regulations concerning
will be appreciated
bax
---
This SF.NET email is sponsored by: Geek
I'm dumb. I have been work with SARs to much today, and I forgot that
jars are also used for ejb-jars. Does the deployer only look at the
name for distinction of the files? What I mean is can the main
deployer, determine which files it needs to deploy, classify them into
plain old jar, sar,
JBoss daily test results
SUMMARY
Number of tests run: 991
Successful tests: 984
Errors:6
Failures: 1
[time of test: 2002-12-19.14-25 GMT]
[java.version: 1.3.1]
[
Bugs item #656613, was opened at 2002-12-19 19:29
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=376685&aid=656613&group_id=22866
Category: JBossWeb
Group: CVS HEAD
Status: Open
Resolution: None
Priority: 5
Submitted By: Jeremy Boynes (jboynes)
Assigned to: Nobody/
I did a little digging and it appears to be a limitation of Sun's compiler.
It's embedded form is invoked identically to the command line so all
arguments must be passed as strings. This essentially means the logical
classpath from the classloaders needs to be convertible to a delimited
string. As
JBoss daily test results
SUMMARY
Number of tests run: 1039
Successful tests: 1029
Errors:9
Failures: 1
[time of test: 2002-12-20.01-37 GMT]
[java.version: 1.3.1_
It looks like the testsuite module was not build cleanly in this run and the xdoclet
task
spit out a bunch of default descriptors that container no ejb info. This caused all of
the jca test failures. Another run's output is on the way.
Scott Stark
Chief Technology Officer
Well, first, JBossWebApplicationContext is Jetty specific and I thought there was
similar functionality in the in the AbstractWebContainer. This is where this logic
needs to be.
Second, this code needs to copy non-file URLs down so that they can be passed
to the jsp compiler. Its the web container
JBoss daily test results
SUMMARY
Number of tests run: 1039
Successful tests: 1006
Errors:30
Failures: 3
[time of test: 2002-12-20.00-39 GMT]
[java.version: 1.3.1
Jeremy Boynes wrote:
> The classloading model works fine - the issue is with how the classpath is
> passed to the JSP compiler.
>
> As I understand it, not being familiar with Jetty/Jasper, Jasper uses an
> Ant Javac task to compile the Java source generated from the JSP. The
> classpath supplied
This is from the ordering done in or near the main deployer, right?
I think the idea is to deploy ejb-jars after .sars. It probably doesn't
make much difference any more since you can make an ejb (container) depend
on an mbean and vice versa. Is it causing problems?
david jencks
On 2002.12.19
The classloading model works fine - the issue is with how the classpath is
passed to the JSP compiler.
As I understand it, not being familiar with Jetty/Jasper, Jasper uses an Ant
Javac task to compile the Java source generated from the JSP. The classpath
supplied to the Javac task is a ':' (path.
This allows ejb-jar's to use resources defined by the sar. Doesn't ejb
deployment fail if e.g. a datasource or queue is undefined?
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On Behalf Of Dain
> Sundstrom
> Sent: Thursday, December 19, 2002 2:26 PM
> To: [EMA
Maybe I'm on crack, but why does it look like a sar file deployed
before jar? Is this desired for some reason? Since a jar has no
deployment time executable code isn't is safe to always deploy the jar
first?
-dain
---
This SF.NET email is
jeremy
most excellent work congratulations
marcf
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]] On
> Behalf Of Jeremy Boynes
> Sent: Thursday, December 19, 2002 12:51 PM
> To: Jboss-Development
> Subject: [JBoss-dev] Committed support for remote deployment
The WebDAV scan just builds a list of what it thinks should be deployed. The
scanner then:
1) Undeploys anything previously deployed that wasn't found
2) Checks last-modified for anything currently deployed and re-deploys if
needed
3) Deploys anything new that was found
I don't use the last-modifi
- Original Message -
From: "Jeremy Boynes" <[EMAIL PROTECTED]>
To: "Jboss-Development" <[EMAIL PROTECTED]>
Sent: Thursday, December 19, 2002 9:50 AM
Subject: [JBoss-dev] Committed support for remote deployment scanning
> * All WARs must contain all jars needed for JSP compilation. The Jas
BTW, do you support hot-(deployment/re-deployment/undeployment) as well i.e.
do you read the lastModified timestamp from the remote webdav server
> -Message d'origine-
> De : [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]De la part de
> Jeremy Boynes
> Envoyé : jeudi, 19 décembre 2002 18:5
I have commited changes to URLDeploymentScanner that use WebDAV to scan
http: locations, allowing the same config to be booted locally or via
netboot.
There are a couple of changes that may impact existing configurations:
* It needs to know whether to scan or deploy a supplied URL. It does this
Guys,
you hear about that?
http://www.microjava.com/news/press?content_id=1710
---
This SF.NET email is sponsored by: Geek Gift Procrastinating?
Get the perfect geek gift now! Before the Holidays pass you by.
T H I N K G E E K . C O M
Bugs item #648344, was opened at 2002-12-04 11:52
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=376685&aid=648344&group_id=22866
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Bruce Barrow (bruce_b)
Assigned to: Nobody/Anonymous
Patches item #656231, was opened at 2002-12-19 11:00
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=376687&aid=656231&group_id=22866
Category: JBossCMP
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Raymond (rpbrandon)
Assigned to: Nobody/Anony
31 matches
Mail list logo
