RE: [JBoss-dev] Handling of ejb-ref and ejb-local-ref
Victor Langelo wrote: I agree with Scott. Having a element be optional in the DTD doesn't mean it optional for a correct deployment. The intent is that a deployment descriptor may be written by a developer without the ejb-link. The link will be specified later by the deployer or integrator. --Victor The spec makes the usage optional as well: "The Application Assembler *can* use the ejb-link element in the deployment descriptor to link an EJB reference to a target enterprise bean." [EJB2.0 pp 418] Note the use of "can" not "must" And: "*If* an EJB reference declaration includes the ejb-link element, the Deployer *should* bind the enterprise bean reference to the home of the enterprise bean specified as the link's target." [EJB2.0 pp 420] Again note "If" and "should" Finally: "The Deployer must ensure that all the declared EJB references are bound to the homes of enterprise beans that exist in the operational environment." [EJB2.0 pp 420] So if the target is not there then it is a Deployment error. That seems a little restrictive if checked at deploy time because of boot order dependencies and redeployment, but if the target is not present when used then an error must be raised. Jeremy /* * Jeremy Boynes * Partner * Core Developers Network */ --- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa0016ave/direct;at.asp_061203_01/01 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Handling of ejb-ref and ejb-local-ref
Scott Stark wrote: > > What about an approach whereby both war and ejb deployers > always try the > > jndi-name first, and if there is none specificied, or if the jndi-name > > is not bound, or if the jndi-name is bound to the wrong home class, we > > fallback to the ejb-link name? That wouldn't require any extra config > > switches and would cover the situation where beans in existing > > deployments have specified both and the jndi-name is wrong. > > > > > I would say the opposite behavior should be the default since if > there is an > ejb-link > it must be resolvable in the scope of the current deployment > while a jndi-name > cannot in general be resolved since this can refer to an external > server that > need not even be available during deployment. Therefore, use the > ejb-link first, > and if none is specified, use the jndi-name. To maintain the > current behavior > add a flag to the war deployer which treats failures to resolve > ejb-links as > deployment errors. This would be false by default in which case a > failure to > resolve an ejb-link triggers fallback to the use of the jndi-name. > I disagee with the last bit here. If ejb-link is specified and the target EJB does not exist in the current deployment, then it should definitely be a deployment error as the standard descriptor was mis-assembled. Any flag should be to turn this behaviour off and allow a mis-configured deployment to drop through to the [local-]jndi-name; this should apply to the EJB deployer as well for consistency. If no ejb-link is specified, then a [local-]jndi-name must be specified. If it is not, then it's a deployment error (as it is now for EJBs and should be for WARs) as there is no sensible default (well, maybe the ejb-ref-name less any "ejb/"). > >> > >> ejb-local-refs are only intended for ejbs in the same deployment > >> so ejb-link should suffice, but the spec is not very explicit. > >> The way jboss works, this won't be a problem. > >> It should not break any existing deployments. > > > > Sorry, but I'm not sure what you mean - do you mean that you are or > > aren't in favour of making the handling consistent, and therefore > > introducing the ejb-local-ref element? > > > > There is no need for an ejb-local-ref in the JBoss specific descriptors as > the ejb-link element handles this in the standard descriptor. > There is no reason > why the metadata needs to be expanded to allow for specifying the > local home > jndi name. > There is, because ejb-link is optional: ^ --| and if it's not there you need to be able to specify the target's local-jndi-name. Jeremy /* * Jeremy Boynes * Partner * Core Developers Network */ --- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa0016ave/direct;at.asp_061203_01/01 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Deadlock issue with SQL Server and other databases
> > Are you sure this couldn't be avoided by using Instance Per Transaction + > SERIALIZABLE + Commit C? > If you think about it, you'd realize that this just pushes the deadlock into the database resulting in rollbacks. This is the multi-instance model described in the spec, but is not the way JBoss is configured by default. I happen to think making the default configuration multi-instance would be a little more disruptive than making the single-instance config we use now work correctly. > If so, I'm worried that if you expand row-locking to happen > during finder queries, you'll break a lot of applications. That would be the same concern I expressed in the original post ;-) But again, row-locking is meant to imply locking. The bug is that we only actually do it on the queries issued by LoadEntity and LoadRelation, and not on all the queries we execute. This leads to inconsistent locking and ultimately, the deadlock. If people wish to use READ_COMMITTED, then simply don't turn on row-locking. > > We do have a mechanism to denote read-only invocations, at least on the > Entity Bean level. Do we? I thought we only had read-only flags at the entity and method level, and they do not cover the dynamic nature of the usage. For example, when I call findByPrimaryKey, I may be intending to just read from the returned EJB or to update some values; the future usage determines the type of lock to take during the query. > I would like a plan from you on what kind of metadata > needs to flow within the context of an invocation. I have done > some work on > how contextual information should flow throughout the system with the AOP > framework, but it probably needs to be expanded. A usecase from you would > help in this arena. > See above > Do not commit this change into the 3.2 branch until it has been fully > documented by you within HEAD and fully reviewed by the > community. We have > to be very careful on how we apply fundamental changes to a maintainence > release like 3.2.x. Other wise we may hinder our users from > upgrading to a > higher maintainence release because something as fundamental as > locking has > changed. > The purpose of the original post _was_ to bring this to the attention of the community. This is a bug fix, not a fundamental change or conflicting enhancement, and is entirely appropriate for a maintenance release (at least Scott and I thought so). Not fixing bugs in a timely manner is a hurdle to adoption in general and not what one expects from an open source project. Jeremy --- This SF.Net email is sponsored by: INetU Attention Web Developers & Consultants: Become An INetU Hosting Partner. Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission! INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Deadlock issue with SQL Server and other databases
This bug indicates how a deadlock can occur between two threads reading and writing the same data: http://sourceforge.net/tracker/index.php?func=detail&aid=758108&group_id=228 66&atid=376685 This is a hybrid deadlock where one thread gets blocked in the database and the other in the app server. As a result neither systems' deadlock detection works and the application hangs until the transaction times out. This can happen when: * The database uses shared-read (S) locks on read and exclusive (X) locks on writes. * The database retains S locks for the duration of the transaction; for example, if the database isolation level is raised to SERIALIZABLE * The application reads data from the database before modifying it The row-locking option in CMP is meant to avoid such issues by ensuring the rows being read are locked so that updates can be performed later. However, this option only affects the query executed for ejbLoad, and not other queries such as finders. I will be fixing this in 3.2 and HEAD by ensuring that the row-locking option affects all queries executed by the CMP engine. This will cure the deadlock scenario described in the bug, but may impact the application: * If two threads read data in different orders, then a deadlock can occur at the database level; this is currently true at the EJB level anyway. If this happens, the database's deadlock detection may cause one query to be terminated (SQL Server does this) resulting in rollback * Because all data is locked on read, concurrency will be reduced. This is the expected behaviour for applications running at a SERIALIZABLE isolation level. For those databases that support it (e.g. SQL Server), I will try and make row-locking use update locks rather than exclusive locks to allow reader threads to proceed. However, without a mechanism to denote read-only invocations, this may not have tangible benefit. I am posting this to the lists early as a heads-up of a change in behaviour as a consequence of fixing this bug. A change note will be posted when the fix is committed. Jeremy /********* * Jeremy Boynes * Partner * Core Developers Network */ --- This SF.Net email is sponsored by: INetU Attention Web Developers & Consultants: Become An INetU Hosting Partner. Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission! INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Re: [jboss-cvs] jboss/src/main/org/jboss/ejb/plugins/cmp/jdbc/bridge JDBCCMP2xFieldBridge.java
I ran the cmp2 testsuite ...
Seriously, I assume you are worried that the read-ahead tests are
getting broken due to the change to RequiresNew, but they are still
passing. If you have to eyeball the log to see if a test did the right
thing, then it is essentially useless as it is never going to catch a
regression. If that is the case then we need to re-write those tests.
The Simple test needs to do something to flush the state to disk - the
reason this issue wasn't caught without RequiresNew was that everything
always remained in cache. The previous verison of the test never
actually used values fetched from the database.
Jeremy
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On
> Behalf Of Alex Loubyansky
> Sent: Friday, May 02, 2003 1:09 AM
> To: jboss-dev
> Subject: [JBoss-dev] Re: [jboss-cvs]
> jboss/src/main/org/jboss/ejb/plugins/cmp/jdbc/bridge
> JDBCCMP2xFieldBridge.java
>
>
> Jeremy, have you tested read-ahead after this change?
>
> alex
>
> Friday, May 02, 2003, 6:14:28 AM, Jeremy Boynes wrote:
>
> JB> User: jboynes
> JB> Date: 03/05/01 20:14:27
>
> JB> Modified:src/main/org/jboss/ejb/plugins/cmp/jdbc/bridge Tag:
> JB> Branch_3_2 JDBCCMP2xFieldBridge.java
> JB> Log:
> JB> Fix for [ 730157 ] Changes to Serializable CMP fields not stored
> JB> Change CMP2.x set accessor so that the field is always
> marked as dirty.
> JB> Previously fields were only marked as dirty if they had
> changed but this fails
> JB> when the field's type is mutable.
> JB> Changed SimpleUnitTest to RequiresNew to ensure EJB is always
> JB> loaded/stored
>
> JB> Revision ChangesPath
> JB> No revision
>
>
> JB> No revision
>
>
> JB> 1.13.4.11 +4 -11
> jboss/src/main/org/jboss/ejb/plugins/cmp/jdbc/bridge/JDBCCMP2x
> FieldBridge.java
>
> JB> Index: JDBCCMP2xFieldBridge.java
> JB>
> ===
> JB> RCS file:
> /cvsroot/jboss/jboss/src/main/org/jboss/ejb/plugins/cmp/jdbc/b
> ridge/JDBCCMP2xFieldBridge.java,v
> JB> retrieving revision 1.13.4.10
> JB> retrieving revision 1.13.4.11
> JB> diff -u -r1.13.4.10 -r1.13.4.11
> JB> --- JDBCCMP2xFieldBridge.java 25 Mar 2003 16:37:21
> - 1.13.4.10
> JB> +++ JDBCCMP2xFieldBridge.java 2 May 2003 03:14:26 -
> 1.13.4.11
> JB> @@ -36,7 +36,7 @@
> JB> *
> JB> * @author mailto:[EMAIL PROTECTED]">Dain
> Sundstrom
> JB> * @author mailto:[EMAIL PROTECTED]">Alex Loubyansky
> JB> - * @version $Revision: 1.13.4.10 $
> JB> + * @version $Revision: 1.13.4.11 $
> JB> */
> JB>public class JDBCCMP2xFieldBridge extends
> JDBCAbstractCMPFieldBridge
> JB>{
> JB> @@ -220,17 +220,10 @@
> JB> {
> JB> FieldState fieldState = getFieldState(ctx);
>
> JB> - // short-circuit to avoid repetive comparisons
> JB> - // The field is considered dirty if it is
> JB> - // not loaded yet
> JB> - // OR it is already dirty
> JB> - // OR it is changed
> JB> - // The above doesn't touch version field (to
> avoid races in UPDATE sql)
> JB> - // and FK field mapped to a PK field
> JB> + // The field is considered dirty unless it is a
> version field or is a FK field mapped to a PK field
> JB> fieldState.isDirty =
> JB> - (!fieldState.isLoaded || fieldState.isDirty
> || changed(fieldState.value, value))
> JB> - &&
> (getManager().getEntityBridge().getVersionField() != this)
> JB> - && !isFKFieldMappedToCMPField();
> JB> +
> (getManager().getEntityBridge().getVersionField() != this)
> JB> +&& !isFKFieldMappedToCMPField();
>
> JB> // notify optimistic lock, but only if the bean
> is created
> JB> if(ctx.getId() != null && fieldState.isLoaded())
>
>
>
> ---
> 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] Verify primary key implements equals and hashCode
I think it is reasonable to validate that the default implementation in
java.lang.Object has been overridden, but beyond that the developer
should be left to shoot themselves in the foot. I too have used Victor's
pattern of a common abstract base class that contained the
implementation and that was then subclassed for type safety.
I also believe that any move toward support of inheritance for
implementations would also require support for inheritance of the
associated identity. EJB may not support this, but other frameworks
might.
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On
> Behalf Of Dain Sundstrom
> Sent: Wednesday, March 26, 2003 9:35 PM
> To: [EMAIL PROTECTED]
> Subject: Re: [JBoss-dev] Verify primary key implements equals
> and hashCode
>
>
> On Wednesday, March 26, 2003, at 09:29 PM, Victor Langelo wrote:
>
> > Dain Sundstrom wrote:
> >
> >> After some email with Bill, it looks like we can use
> >> Class.getDeclaredMethods to find which method the class implements
> >> (you learn something new every day). It specifically excludes
> >> inherited methods, so we can use it to verify if a primary key has
> >> actually implemented hashCode and equals.
> >
> > Class.getDeclaredMethod("equals", new Class[] {
> Object.class }) should
> > also do the trick and won't return inherited methods.
>
> I dumb; I missed that one.
>
> >>
> >> Since equals equals is not really inheritable (see
> Effective Java), I
> >> think we should throw a verifier error if a pk does not directly
> >> implement it.
> >
> > I haven't read Effective Java, but this won't work for us. We
> > intentionally create derived primary key classes for each entity.
> > These are derived from generic pk classes when the primary
> key data is
> > a simple primative type. The super class implements equals,
> compareTo
> > and hashCode. I don't see any reason these would need to be
> > reimplemented in each derived class.
> >
> > The purpose of the derived classes is primarly for type safety.
>
> I loaned my copy of Effective Java to a friend so I can't quote. The
> basic idea is that if a.equals(b) is true b.equals(a) must also be
> true. This means you must test for the exact type of the related
> compare to object. You must have code that looks something like this.
>
> public boolean equals(object o)
> {
> if(o instanceof MyType)
> {
>return value.equals((MyType).value);
> }
> return false;
> }
>
> The important part is the instance of check. I suppose you could do
> this check with reflection... something like this
>
> if(getClass() == o.getClass())
>
> So I guess you are right, but we know that if one of the
> super classes
> (other then Object) we know that the implementation is wrong.
>
> > public static boolean definesEquals(Class clazz)
> > {
> >Class[] params = new Class[] { Object.class };
> >
> >while (clazz != null && !clazz.equals(Object.class)) {
> > try {
> > Method m = clazz.getDeclaredMethod("equals", params);
> > if (m.getReturnType() == Integer.TYPE)
> > return true;
> > } catch (NoSuchMethodException) {
> > }
> > clazz = clazz.getSuperclass();
> >}
> >return false;
> > }
>
> That should work.
>
> -dain
>
>
>
> ---
> This SF.net email is sponsored by:
> The Definitive IT and Networking Event. Be There!
> NetWorld+Interop Las Vegas 2003 -- Register today!
> http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en
> ___
> Jboss-development mailing list [EMAIL PROTECTED]
> https://lists.sourceforge.net/lists/listinfo/jboss-development
>
---
This SF.net email is sponsored by:
The Definitive IT and Networking Event. Be There!
NetWorld+Interop Las Vegas 2003 -- Register today!
http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] [ jboss-Feature Requests-710007 ] WEBDAV deployment
I just posted a reply in the tracker, and bounced him to you for RussianDoll issues - tag :-) > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On > Behalf Of Sacha Labourey > Sent: Wednesday, March 26, 2003 7:02 AM > To: [EMAIL PROTECTED] > Subject: RE: [JBoss-dev] [ jboss-Feature Requests-710007 ] > WEBDAV deployment > > > I guess this is a question for Jeremy Boynes. Nevertheless, I > think to remember that being able to have this would also > mean fixing some classloading behaviour in Jasper. > > Cheers, > > > Sacha > > > -Original Message- > > From: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED] On > > Behalf Of SourceForge.net > > Sent: mercredi, 26. mars 2003 13:15 > > To: [EMAIL PROTECTED] > > Subject: [JBoss-dev] [ jboss-Feature Requests-710007 ] WEBDAV > > deployment > > > > > > Feature Requests item #710007, was opened at 2003-03-26 > 15:14 You can > > respond by visiting: > > https://sourceforge.net/tracker/?func=detail&atid=376688&aid=7 > 10007&group_id=22866 > > Category: JBossServer > Group: v3.2 > Status: Open > Resolution: None > Priority: 5 > Submitted By: Igor A. Karpov (ikar) > Assigned to: Nobody/Anonymous (nobody) > Summary: WEBDAV deployment > > Initial Comment: > currectly there's some support for WebDAV in JBoss. > Namely, packed archives (*.war, *.sar, *.ear) can be > detected on WebDAV-enabled sites and deployed. > The point is that Unpacked archives are detected but > cannot be deployed; the automatic deployment of > Unpacked archives would be the best option for me. > I would even develop this functionality, just need a > hint where to start from. > > -- > > You can respond by visiting: > https://sourceforge.net/tracker/?func=detail&atid=376688&aid=7 10007&group_id =22866 --- This SF.net email is sponsored by: The Definitive IT and Networking Event. Be There! NetWorld+Interop Las Vegas 2003 -- Register today! http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This SF.net email is sponsored by: The Definitive IT and Networking Event. Be There! NetWorld+Interop Las Vegas 2003 -- Register today! http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This SF.net email is sponsored by: The Definitive IT and Networking Event. Be There! NetWorld+Interop Las Vegas 2003 -- Register today! http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] [PROPOSAL]: clean conf/jboss-service.xml & deploy
Rather than a specialized SubDirSubDeployer, how about having the SAR report multiple watch-urls? It may also be possible to have the SAR start its own URLDeploymentScanner for its content rather than explicitly sub-deploy it. This would support automatic redeployment of unpacked sar content over the web as well; for the packed case, I think it would be easy to have a URLLister that scans a jar: URL as well as the current file: and http: ones. Yes, you would need a real jboss-service.xml to start the nested URLDeploymentScanner, but that would be mostly boilerplate if we made the default scanned URL the SAR's root. > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On > Behalf Of Sacha Labourey > Sent: Wednesday, March 19, 2003 6:27 AM > To: [EMAIL PROTECTED] > Subject: RE: [JBoss-dev] [PROPOSAL]: clean > conf/jboss-service.xml & deploy > > > > The thing I care about most is ease of configurability > > (which, for the most part, I think we already have). I like > > the idea that I can add or remove functionality by adding or > > removing "modules" from /deploy. Much of the functionality > > of the server works this way (jmx-console, for example). > > There is, however, quite a bit of information in > > /conf/service.xml. If this information could be refactored > > out to /deploy, I'd find that a much simpler situation. At > > the moment, if I want to "pare down" jboss to some small > > feature set, I need to edit /conf/service.xml. That's not a > > big deal, but the less of that I need to do, the better > > (especially for automation). > > Yes, that is the problem: we should not have to modify this file. > > > Regarding #2, I find the current state of /deploy to be > > highly intuitive, personally. Would it be possible to make > > your scheme work by giving .sar's the ability to be nested? > > That way, /deploy/JMS.sar (a directory) could contain > > jms-foo.sar and jms-bar.sar. > > That's already possible (russian dolls), but then: > - you need a fake META-INF/jboss-service.xml > - you cannot simply re-deploy one of the element in the > directory: you have to re-deploy the whole JMS thing > > Cheers, > > > sacha > > > > --- > This SF.net email is sponsored by: Does your code think in ink? > You could win a Tablet PC. Get a free Tablet PC hat just for playing. > What are you waiting for? > http://ads.sourceforge.net/cgi-> bin/redirect.pl?micr5043en > > > ___ > Jboss-development mailing list [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-development > --- This SF.net email is sponsored by: Does your code think in ink? You could win a Tablet PC. Get a free Tablet PC hat just for playing. What are you waiting for? http://ads.sourceforge.net/cgi-bin/redirect.pl?micr5043en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Jboss Boot lib jars
The jars hard-coded in Main and ServerLoader are those needed to boot
the server. These will come from the local filesystem or the netboot
server depending on where you boot from.
The WebDAV client does not come into play until SARDeployer deploys the
intial jboss-service.xml file from conf/ - then, if you are booting from
http:, SARDeployer uses it to list files for wildcarded archives in the
element.
However, the WebDAV code needs to be available to perform that scan
(chicken/egg issue) so the WebDAV libraries have to be explicitly listed
in the server classpath i.e. the lists in Main/ServerLoader. If you are
not netbooting, or are not using wildcards then they can be deleted from
${jboss.home}/lib
It is also used by URLDeploymentScanner, but that's way later.
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On
> Behalf Of Jason Dillon
> Sent: Friday, March 07, 2003 2:16 PM
> To: [EMAIL PROTECTED]
> Subject: Re: [JBoss-dev] Jboss Boot lib jars
>
>
> I have no exp. with WebDav so I can not say... but do we want
> to force
> the usage of Webdav? I personally do not like to force
> anything. Why
> the concern?
>
> --jason
>
>
> On Saturday, March 8, 2003, at 05:02 AM, Jeff Haynie wrote:
>
> > Ok, this makes sense ..
> >
> > can't we list even if remote using WebDav?
> >
> > -Original Message-
> > From: [EMAIL PROTECTED]
> > [mailto:[EMAIL PROTECTED] On Behalf Of
> > Jason Dillon
> > Sent: Friday, March 07, 2003 4:07 PM
> > To: [EMAIL PROTECTED]
> > Subject: Re: [JBoss-dev] Jboss Boot lib jars
> >
> >
> > The jars which are hardcoded in Main are references to jars
> which are
> > required to load up the server. We can not assume that
> those jars are
> > on the local file system and thus can not query a directory to
> > discover which jars need to be loaded.
> >
> > If you would rather not have them hardcoded then perhaps an
> external
> > property file would work. We certainly do not want to be
> bound to the
> > file system again.
> >
> > --jason
> >
> >
> > On Saturday, March 8, 2003, at 03:40 AM, Jeff Haynie wrote:
> >
> >> Is there any reason we need to hardcode the jars that are
> included in
> >> the lib directory? (in org.jboss.Main)
> >>
> >> Can't we just put all the *.jars under /lib into the class
> >> loader on boot?
> >>
> >>
> >> Jeff
> >>
> >>
> >>
> >>
> >> ---
> >> This SF.net email is sponsored by: Etnus, makers of TotalView, The
> >> debugger for complex code. Debugging C/C++ programs can leave you
> >> feeling lost and
> >> disoriented. TotalView can help you find your way.
> Available on major
> >> UNIX
> >> and Linux platforms. Try it free. www.etnus.com
> >> ___
> >> Jboss-development mailing list
> >> [EMAIL PROTECTED]
> >> https://lists.sourceforge.net/lists/listinfo/jboss-development
> >>
> >
> >
> >
> > ---
> > This SF.net email is sponsored by: Etnus, makers of TotalView, The
> > debugger for complex code. Debugging C/C++ programs can leave you
> > feeling lost and
> > disoriented. TotalView can help you find your way.
> Available on major
> > UNIX
> > and Linux platforms. Try it free. www.etnus.com
> > ___
> > Jboss-development mailing list
> > [EMAIL PROTECTED]
> > https://lists.sourceforge.net/lists/listinfo/jboss-development
> >
> >
> >
> >
> > ---
> > This SF.net email is sponsored by: Etnus, makers of TotalView, The
> > debugger
> > for complex code. Debugging C/C++ programs can leave you
> feeling lost
> > and
> > disoriented. TotalView can help you find your way.
> Available on major
> > UNIX
> > and Linux platforms. Try it free. www.etnus.com
> > ___
> > Jboss-development mailing list
> > [EMAIL PROTECTED]
> > https://lists.sourceforge.net/lists/listinfo/jboss-development
> >
>
>
>
> ---
> This SF.net email is sponsored by: Etnus, makers of
> TotalView, The debugger
> for complex code. Debugging C/C++ programs can leave you
> feeling lost and
> disoriented. TotalView can help you find your way. Available
> on major UNIX
> and Linux platforms. Try it free. www.etnus.com
> ___
> Jboss-development mailing list
> [EMAIL PROTECTED]
> https://lists.sourceforge.net/lists/listinfo/jboss-development
>
---
This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger
for complex code. Debugging C/C++ programs can leave you feeling lost and
disoriented. TotalView can help you find your way. Available on major UNIX
and Linux platforms. Try it free. www.etnus.com
___
Jboss-development mailing list
RE: [JBoss-dev] JBoss/Persistence module added to CVS
I am going to move the generic peristence stuff from server to persistence. I am going to leave the EJB persistence stuff in server for now as I am not sure where Bill is with the interceptor changes. It can move to ejb along with the rest (whenever whoever does that, just not me right now :-) > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On > Behalf Of Jason Dillon > Sent: Friday, March 07, 2003 9:20 AM > To: [EMAIL PROTECTED] > Subject: Re: [JBoss-dev] JBoss/Persistence module added to CVS > > > Huh? When what? SOrry for being dense I am just confused as to the > exact bits you are talking about. > > --jason > > > On Saturday, March 8, 2003, at 12:02 AM, Jeremy Boynes wrote: > > > OK. When ? Are we stable yet? > > > >> -Original Message- > >> From: [EMAIL PROTECTED] > >> [mailto:[EMAIL PROTECTED] On > Behalf Of > >> Jason Dillon > >> Sent: Friday, March 07, 2003 8:33 AM > >> To: [EMAIL PROTECTED] > >> Subject: Re: [JBoss-dev] JBoss/Persistence module added to CVS > >> > >> > >> EJB bits to ejb module ;) > >> > >> --jason > >> > >> > >> On Friday, March 7, 2003, at 11:28 PM, Jeremy Boynes wrote: > >> > >>> The EJB part yes, the generic persistence stuff no. > >>> > >>>> -Original Message- > >>>> From: [EMAIL PROTECTED] > >>>> [mailto:[EMAIL PROTECTED] On > >> Behalf Of > >>>> Bill Burke > >>>> Sent: Friday, March 07, 2003 8:16 AM > >>>> To: [EMAIL PROTECTED] > >>>> Subject: RE: [JBoss-dev] JBoss/Persistence module added to CVS > >>>> > >>>> > >>>> CMP specific stuff should remain in server/ Shouldn't it? > >>>> > >>>>> -Original Message- > >>>>> From: [EMAIL PROTECTED] > >>>>> [mailto:[EMAIL PROTECTED] > >> Behalf Of > >>>>> Jeremy Boynes > >>>>> Sent: Friday, March 07, 2003 11:03 AM > >>>>> To: [EMAIL PROTECTED] > >>>>> Subject: RE: [JBoss-dev] JBoss/Persistence module added to CVS > >>>>> > >>>>> > >>>>> Thanks - I will start moving stuff over > >>>>> > >>>>>> -Original Message- > >>>>>> From: [EMAIL PROTECTED] > >>>>>> [mailto:[EMAIL PROTECTED] On > >>>> Behalf Of > >>>>>> Jason Dillon > >>>>>> Sent: Friday, March 07, 2003 3:37 AM > >>>>>> To: [EMAIL PROTECTED] > >>>>>> Subject: [JBoss-dev] JBoss/Persistence module added to CVS > >>>>>> > >>>>>> > >>>>>> Enjoy. > >>>>>> > >>>>>> --jason > >>>>>> > >>>>>> > >>>>>> > >>>>>> --- > >>>>>> This SF.net email is sponsored by: Etnus, makers of > >>>> TotalView, The > >>>>>> debugger for complex code. Debugging C/C++ programs can > >> leave you > >>>>>> feeling lost and disoriented. TotalView can help you > >> find your way. > >>>>>> Available on major UNIX > >>>>>> and Linux platforms. Try it free. www.etnus.com > >>>>>> ___ > >>>>>> Jboss-development mailing list > >>>> [EMAIL PROTECTED] > >>>>>> https://lists.sourceforge.net/lists/listinfo/jboss-development > >>>>>> > >>>>> > >>>>> > >>>>> > >>>>> --- > >>>>> This SF.net email is sponsored by: Etnus, makers of > >> TotalView, The > >>>>> debugger for complex code. Debugging C/C++ programs can > leave you > >>>>> feeling lost and disoriented. TotalView can help you find > >> your way. > >>>>> Available on major UNIX and Linux platforms. Try it free. > >>>>> www.etnus.com ___ > >>>>> Jboss-development mailing list > >>>>> [EMAIL PROTECTED] > >>>>> https://lists.sourceforge.net/lists/listinfo/jboss-development >
RE: [JBoss-dev] JBoss/Persistence module added to CVS
OK. When ? Are we stable yet? > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On > Behalf Of Jason Dillon > Sent: Friday, March 07, 2003 8:33 AM > To: [EMAIL PROTECTED] > Subject: Re: [JBoss-dev] JBoss/Persistence module added to CVS > > > EJB bits to ejb module ;) > > --jason > > > On Friday, March 7, 2003, at 11:28 PM, Jeremy Boynes wrote: > > > The EJB part yes, the generic persistence stuff no. > > > >> -Original Message- > >> From: [EMAIL PROTECTED] > >> [mailto:[EMAIL PROTECTED] On > Behalf Of > >> Bill Burke > >> Sent: Friday, March 07, 2003 8:16 AM > >> To: [EMAIL PROTECTED] > >> Subject: RE: [JBoss-dev] JBoss/Persistence module added to CVS > >> > >> > >> CMP specific stuff should remain in server/ Shouldn't it? > >> > >>> -Original Message- > >>> From: [EMAIL PROTECTED] > >>> [mailto:[EMAIL PROTECTED] > Behalf Of > >>> Jeremy Boynes > >>> Sent: Friday, March 07, 2003 11:03 AM > >>> To: [EMAIL PROTECTED] > >>> Subject: RE: [JBoss-dev] JBoss/Persistence module added to CVS > >>> > >>> > >>> Thanks - I will start moving stuff over > >>> > >>>> -Original Message- > >>>> From: [EMAIL PROTECTED] > >>>> [mailto:[EMAIL PROTECTED] On > >> Behalf Of > >>>> Jason Dillon > >>>> Sent: Friday, March 07, 2003 3:37 AM > >>>> To: [EMAIL PROTECTED] > >>>> Subject: [JBoss-dev] JBoss/Persistence module added to CVS > >>>> > >>>> > >>>> Enjoy. > >>>> > >>>> --jason > >>>> > >>>> > >>>> > >>>> --- > >>>> This SF.net email is sponsored by: Etnus, makers of > >> TotalView, The > >>>> debugger for complex code. Debugging C/C++ programs can > leave you > >>>> feeling lost and disoriented. TotalView can help you > find your way. > >>>> Available on major UNIX > >>>> and Linux platforms. Try it free. www.etnus.com > >>>> ___ > >>>> Jboss-development mailing list > >> [EMAIL PROTECTED] > >>>> https://lists.sourceforge.net/lists/listinfo/jboss-development > >>>> > >>> > >>> > >>> > >>> --- > >>> This SF.net email is sponsored by: Etnus, makers of > TotalView, The > >>> debugger for complex code. Debugging C/C++ programs can leave you > >>> feeling lost and disoriented. TotalView can help you find > your way. > >>> Available on major UNIX and Linux platforms. Try it free. > >>> www.etnus.com ___ > >>> Jboss-development mailing list > >>> [EMAIL PROTECTED] > >>> https://lists.sourceforge.net/lists/listinfo/jboss-development > >> > >> > >> > >> --- > >> This SF.net email is sponsored by: Etnus, makers of TotalView, The > >> debugger for complex code. Debugging C/C++ programs can leave you > >> feeling lost and > >> disoriented. TotalView can help you find your way. Available > >> on major UNIX > >> and Linux platforms. Try it free. www.etnus.com > >> ___ > >> Jboss-development mailing list > [EMAIL PROTECTED] > >> https://lists.sourceforge.net/lists/listinfo/jboss-development > >> > > > > > > > > --- > > This SF.net email is sponsored by: Etnus, makers of TotalView, The > > debugger > > for complex code. Debugging C/C++ programs can leave you > feeling lost > > and > > disoriented. TotalView can help you find your way. > Available on major > > UNIX > > and Linux platforms. Try it free. www.etnus.com > > ___ > > Jboss-development mailing list > > [EMAIL PROTECTED] > > https://lists.sourceforge.net/lists/listinfo/jboss-development > > > > > > --- > This SF.net email is sponsored by: Etnus, makers of > TotalView, The debugger > for complex code. Debugging C/C++ programs can leave you > feeling lost and > disoriented. TotalView can help you find your way. Available > on major UNIX > and Linux platforms. Try it free. www.etnus.com > ___ > Jboss-development mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-development > --- This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger for complex code. Debugging C/C++ programs can leave you feeling lost and disoriented. TotalView can help you find your way. Available on major UNIX and Linux platforms. Try it free. www.etnus.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] JBoss/Persistence module added to CVS
The EJB part yes, the generic persistence stuff no. > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On > Behalf Of Bill Burke > Sent: Friday, March 07, 2003 8:16 AM > To: [EMAIL PROTECTED] > Subject: RE: [JBoss-dev] JBoss/Persistence module added to CVS > > > CMP specific stuff should remain in server/ Shouldn't it? > > > -Original Message- > > From: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED] Behalf Of > > Jeremy Boynes > > Sent: Friday, March 07, 2003 11:03 AM > > To: [EMAIL PROTECTED] > > Subject: RE: [JBoss-dev] JBoss/Persistence module added to CVS > > > > > > Thanks - I will start moving stuff over > > > > > -Original Message- > > > From: [EMAIL PROTECTED] > > > [mailto:[EMAIL PROTECTED] On > Behalf Of > > > Jason Dillon > > > Sent: Friday, March 07, 2003 3:37 AM > > > To: [EMAIL PROTECTED] > > > Subject: [JBoss-dev] JBoss/Persistence module added to CVS > > > > > > > > > Enjoy. > > > > > > --jason > > > > > > > > > > > > --- > > > This SF.net email is sponsored by: Etnus, makers of > TotalView, The > > > debugger for complex code. Debugging C/C++ programs can leave you > > > feeling lost and > > > disoriented. TotalView can help you find your way. Available > > > on major UNIX > > > and Linux platforms. Try it free. www.etnus.com > > > ___ > > > Jboss-development mailing list > [EMAIL PROTECTED] > > > https://lists.sourceforge.net/lists/listinfo/jboss-development > > > > > > > > > > > --- > > This SF.net email is sponsored by: Etnus, makers of TotalView, The > > debugger for complex code. Debugging C/C++ programs can leave you > > feeling lost and disoriented. TotalView can help you find your way. > > Available on major UNIX > > and Linux platforms. Try it free. www.etnus.com > > ___ > > Jboss-development mailing list > > [EMAIL PROTECTED] > > https://lists.sourceforge.net/lists/listinfo/jboss-development > > > > --- > This SF.net email is sponsored by: Etnus, makers of > TotalView, The debugger > for complex code. Debugging C/C++ programs can leave you > feeling lost and > disoriented. TotalView can help you find your way. Available > on major UNIX > and Linux platforms. Try it free. www.etnus.com > ___ > Jboss-development mailing list [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-development > --- This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger for complex code. Debugging C/C++ programs can leave you feeling lost and disoriented. TotalView can help you find your way. Available on major UNIX and Linux platforms. Try it free. www.etnus.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] JBoss/Persistence module added to CVS
Thanks - I will start moving stuff over > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On > Behalf Of Jason Dillon > Sent: Friday, March 07, 2003 3:37 AM > To: [EMAIL PROTECTED] > Subject: [JBoss-dev] JBoss/Persistence module added to CVS > > > Enjoy. > > --jason > > > > --- > This SF.net email is sponsored by: Etnus, makers of > TotalView, The debugger > for complex code. Debugging C/C++ programs can leave you > feeling lost and > disoriented. TotalView can help you find your way. Available > on major UNIX > and Linux platforms. Try it free. www.etnus.com > ___ > Jboss-development mailing list [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-development > --- This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger for complex code. Debugging C/C++ programs can leave you feeling lost and disoriented. TotalView can help you find your way. Available on major UNIX and Linux platforms. Try it free. www.etnus.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] NetBoot PetStore?
I made several changes to NetBoot triggered by this, see http://sourceforge.net/tracker/index.php?func=detail&aid=660839&group_id =22866&atid=381174 There is a revised netboot-demo module in the applications tree that builds a ear with the standard JBoss configs plus a petstore config, all of which can be netbooted. I tried to get it running with JWS but ran into issues with the security manager that we did not consider worth fixing. With the jboss.org website in flux, the new version never migrated there. Jeremy > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On > Behalf Of Jason Dillon > Sent: Monday, March 03, 2003 12:20 AM > To: [EMAIL PROTECTED] > Subject: [JBoss-dev] NetBoot PetStore? > > > Whatever happened to the NetBoot PetStore work? > > --jason > > > > --- > 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] New module for cmp? What about the ejb module?
I think so. Is 'cmp' OK for the new module name, or is that too strongly associated with EJBs? Maybe 'persistence'? Jeremy > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On > Behalf Of David Jencks > Sent: Sunday, March 02, 2003 10:10 AM > To: [EMAIL PROTECTED] > Subject: [JBoss-dev] New module for cmp? What about the ejb module? > > > Would it be appropriate to put the new cmp framework in its > own module since it is not particularly dependent on ejbs? > > Are we going to move the ejb support into the currently empty > ejb module? > > david jencks > > > --- > 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] (no subject)
This should be fixed now. > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]] On > Behalf Of David Jencks > Sent: Sunday, February 16, 2003 9:48 AM > To: [EMAIL PROTECTED] > Cc: [EMAIL PROTECTED] > Subject: [JBoss-dev] (no subject) > > > there appear to be problems with the InvocationResponse and > cmp2 in jb4. > Quite a few (e.g. cmp2 commerce) tests are failing apparently > due to an InvocationResponse object being supplied as a pk value: > > > 2003-02-16 11:55:52,592 DEBUG > [org.jboss.ejb.plugins.cmp.jdbc.JDBCStoreEntityCommand.OrderEJB] > Executing SQL: UPDATE ORDER_DATA SET SHIPPING_ADDRESS=? WHERE > ORDER_NUMBER=? 2003-02-16 11:55:52,593 ERROR > [org.jboss.ejb.plugins.LogInterceptor] > EJBException, causedBy: > java.sql.SQLException: Wrong data type: For input string: > "org.jboss.invocation.InvocationResponse@90f9c3" > at org.hsqldb.Trace.getError(Unknown Source) > at org.hsqldb.Trace.error(Unknown Source) > at org.hsqldb.Column.convertObject(Unknown Source) > at org.hsqldb.jdbcPreparedStatement.setObject(Unknown Source) > at > org.jboss.resource.adapter.jdbc.WrappedPreparedStatement.setOb > ject(WrappedPreparedStatement.java:607) > at > org.jboss.ejb.plugins.cmp.jdbc.JDBCUtil.setParameter(JDBCUtil. > java:278) > at > org.jboss.ejb.plugins.cmp.jdbc.bridge.JDBCAbstractCMPFieldBrid > ge.setArgumentParameters(JDBCAbstractCMPFieldBridge.java:301) > at > org.jboss.ejb.plugins.cmp.jdbc.bridge.JDBCAbstractCMPFieldBrid > ge.setPrimaryKeyParameters(JDBCAbstractCMPFieldBridge.java:289) > at > org.jboss.ejb.plugins.cmp.jdbc.bridge.JDBCEntityBridge.setPrim > aryKeyParameters(JDBCEntityBridge.java:581) > at > org.jboss.ejb.plugins.cmp.jdbc.JDBCStoreEntityCommand.execute( > JDBCStoreEntityCommand.java:117) > at > org.jboss.ejb.plugins.cmp.jdbc.JDBCStoreManager.storeEntity(JD > BCStoreManager.java:614) > at > org.jboss.ejb.entity.CMPInterceptor.storeEntity(CMPInterceptor > .java:218) > > Perhaps someone who knows how this area works better than I > could fix this. > > thanks > david jencks > > > --- > 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] Why is JDBCCommand dumping out these errors now
OK, there are two things going on here. The first is that the table names supplied in jaws.xml are lower case and do not match the all upper case ones returned by hsqldb 1.7.1. This is the cause of the error below. I will make a change so that we do a case-insensitive compare when checking if the table exists. However, if I make the table name all upper case to avoid this problem bankiiop fails for me with 'Exception in thread "main"' on the test console an nothing logged elsewhere. This leaves the bank bean deployed and then everything is messed up. Anyone have any ideas, before I dig in? Thanks Jeremy > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]]On Behalf Of > Jeremy Boynes > Sent: Saturday, February 08, 2003 8:23 PM > To: [EMAIL PROTECTED] > Subject: RE: [JBoss-dev] Why is JDBCCommand dumping out these errors now > > > This seems to be a reoccurance of the case-sensitive meta-data > problem that > happened with the upgrade to hsqldb 1.7.1 back in December. It's not all > tests that fail, the cmp2 ones seem to work fine but bankiiop is broken. > > I'll look into it. > > > -Original Message- > > From: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED]]On Behalf Of Scott > > M Stark > > Sent: Saturday, February 08, 2003 7:35 PM > > To: [EMAIL PROTECTED] > > Subject: [JBoss-dev] Why is JDBCCommand dumping out these errors now > > > > > > The JDBCCommand layer is dumping out errors due to some recent > change. Run > > any cmp test more than once that attempts to create a table and > > the following > > type of error occurs. It does not prevent the test from running > > but it should > > not be showing up as an error. > > > > 19:30:12,198 ERROR [JDBCCommand] Exception caught executing SQL > > java.sql.SQLException: Table already exists: CUSTOMER in > > statement [CREATE TABLE > > Customer (name VARCHAR(256),accounts OBJECT,id VARCHAR(256))] > > at org.hsqldb.Trace.getError(Unknown Source) > > at org.hsqldb.Result.(Unknown Source) > > at org.hsqldb.jdbcConnection.executeHSQL(Unknown Source) > > at org.hsqldb.jdbcConnection.execute(Unknown Source) > > at org.hsqldb.jdbcStatement.fetchResult(Unknown Source) > > at org.hsqldb.jdbcStatement.executeUpdate(Unknown Source) > > at > org.hsqldb.jdbcPreparedStatement.executeUpdate(Unknown Source) > > at > > org.jboss.resource.adapter.jdbc.WrappedPreparedStatement.executeUp > > date(WrappedPreparedStatement.java:308) > > at > > org.jboss.ejb.plugins.jaws.jdbc.JDBCUpdateCommand.executeStatement > > AndHandleResult(JDBCUpdateCommand.java:61) > > at > > org.jboss.ejb.plugins.jaws.jdbc.JDBCCommand.jdbcExecute(JDBCComman > > d.java:176) > > at > > org.jboss.ejb.plugins.jaws.jdbc.JDBCInitCommand.execute(JDBCInitCo > > mmand.java:149) > > at > > org.jboss.ejb.plugins.jaws.JAWSPersistenceManager.create(JAWSPersi > > stenceManager.java:131) > > at > > org.jboss.ejb.plugins.CMPPersistenceManager.create(CMPPersistenceM > > anager.java:127) > > at > > org.jboss.ejb.EntityContainer.createService(EntityContainer.java:277) > > at > > > org.jboss.system.ServiceMBeanSupport.create(ServiceMBeanSupport.java:158) > > at sun.reflect.GeneratedMethodAccessor33.invoke(Unknown Source) > > at > > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAc > > cessorImpl.java:25) > > at java.lang.reflect.Method.invoke(Method.java:324) > > at > > org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedM > > BeanDispatcher.java:284) > > at > > org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:549) > > at > > org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceCont > > roller.java:966) > > at $Proxy11.create(Unknown Source) > > at > > org.jboss.system.ServiceController.create(ServiceController.java:310) > > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > > at > > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorIm > > pl.java:39) > > at > > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAc > > cessorImpl.java:25) > > at java.lang.reflect.Method.invoke(Method.java:324) > > at > > org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedM > > BeanDispatcher.java:284) > > at > > or
RE: [JBoss-dev] Why is JDBCCommand dumping out these errors now
This seems to be a reoccurance of the case-sensitive meta-data problem that happened with the upgrade to hsqldb 1.7.1 back in December. It's not all tests that fail, the cmp2 ones seem to work fine but bankiiop is broken. I'll look into it. > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]]On Behalf Of Scott > M Stark > Sent: Saturday, February 08, 2003 7:35 PM > To: [EMAIL PROTECTED] > Subject: [JBoss-dev] Why is JDBCCommand dumping out these errors now > > > The JDBCCommand layer is dumping out errors due to some recent change. Run > any cmp test more than once that attempts to create a table and > the following > type of error occurs. It does not prevent the test from running > but it should > not be showing up as an error. > > 19:30:12,198 ERROR [JDBCCommand] Exception caught executing SQL > java.sql.SQLException: Table already exists: CUSTOMER in > statement [CREATE TABLE > Customer (name VARCHAR(256),accounts OBJECT,id VARCHAR(256))] > at org.hsqldb.Trace.getError(Unknown Source) > at org.hsqldb.Result.(Unknown Source) > at org.hsqldb.jdbcConnection.executeHSQL(Unknown Source) > at org.hsqldb.jdbcConnection.execute(Unknown Source) > at org.hsqldb.jdbcStatement.fetchResult(Unknown Source) > at org.hsqldb.jdbcStatement.executeUpdate(Unknown Source) > at org.hsqldb.jdbcPreparedStatement.executeUpdate(Unknown Source) > at > org.jboss.resource.adapter.jdbc.WrappedPreparedStatement.executeUp > date(WrappedPreparedStatement.java:308) > at > org.jboss.ejb.plugins.jaws.jdbc.JDBCUpdateCommand.executeStatement > AndHandleResult(JDBCUpdateCommand.java:61) > at > org.jboss.ejb.plugins.jaws.jdbc.JDBCCommand.jdbcExecute(JDBCComman > d.java:176) > at > org.jboss.ejb.plugins.jaws.jdbc.JDBCInitCommand.execute(JDBCInitCo > mmand.java:149) > at > org.jboss.ejb.plugins.jaws.JAWSPersistenceManager.create(JAWSPersi > stenceManager.java:131) > at > org.jboss.ejb.plugins.CMPPersistenceManager.create(CMPPersistenceM > anager.java:127) > at > org.jboss.ejb.EntityContainer.createService(EntityContainer.java:277) > at > org.jboss.system.ServiceMBeanSupport.create(ServiceMBeanSupport.java:158) > at sun.reflect.GeneratedMethodAccessor33.invoke(Unknown Source) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAc > cessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:324) > at > org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedM > BeanDispatcher.java:284) > at > org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:549) > at > org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceCont > roller.java:966) > at $Proxy11.create(Unknown Source) > at > org.jboss.system.ServiceController.create(ServiceController.java:310) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorIm > pl.java:39) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAc > cessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:324) > at > org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedM > BeanDispatcher.java:284) > at > org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:549) > at org.jboss.util.jmx.MBeanProxy.invoke(MBeanProxy.java:174) > at $Proxy32.create(Unknown Source) > at org.jboss.ejb.EjbModule.createService(EjbModule.java:347) > at > org.jboss.system.ServiceMBeanSupport.create(ServiceMBeanSupport.java:158) > at sun.reflect.GeneratedMethodAccessor33.invoke(Unknown Source) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAc > cessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:324) > at > org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedM > BeanDispatcher.java:284) > at > org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:549) > at > org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceCont > roller.java:966) > at $Proxy11.create(Unknown Source) > at > org.jboss.system.ServiceController.create(ServiceController.java:310) > at > org.jboss.system.ServiceController.create(ServiceController.java:243) > at sun.reflect.GeneratedMethodAccessor3.invoke(Unknown Source) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAc > cessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:324) > at > org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedM > BeanDispatcher.java:284) > at > org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:549) > at org.jboss.util.jmx.MBeanProxy.invoke(MBeanProxy.java:174) > at $Pr
RE: [JBoss-dev] Accessing Container from an EJB?
OK. 3.2 is fine for me. Thanks Jeremy > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]]On Behalf Of David > Jencks > Sent: Thursday, January 30, 2003 4:27 PM > To: [EMAIL PROTECTED] > Subject: Re: [JBoss-dev] Accessing Container from an EJB? > > > Someone left the "get" method out of the ModelMBeanInfo for the > registry. I'm checking for problems, then I'll add it to 3.2. I'm > less enthusiastic about 3.0. > > david jencks > --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Accessing Container from an EJB?
OK, it worked like a charm in the HEAD branch. In 3.2 I get a NoSuchMethodException when calling get(name) on the registry: Caused by: java.lang.NoSuchMethodException: Unable to locate method for: get(,javax.management.ObjectName) at org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBeanDispat cher.java:288) at org.jboss.mx.interceptor.ObjectReferenceInterceptor.invoke(ObjectReferenceIn terceptor.java:64) at org.jboss.mx.interceptor.MBeanAttributeInterceptor.invoke(MBeanAttributeInte rceptor.java:50) at org.jboss.mx.interceptor.PersistenceInterceptor.invoke(PersistenceIntercepto r.java:91) at org.jboss.mx.server.MBeanInvoker.invoke(MBeanInvoker.java:79) at javax.management.modelmbean.RequiredModelMBean.invoke(RequiredModelMBean.jav a:141) at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:549) at org.jboss.util.jmx.MBeanProxy.invoke(MBeanProxy.java:174) Any ideas? Thanks Jeremy > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]]On Behalf Of > Jeremy Boynes > Sent: Thursday, January 30, 2003 9:43 AM > To: [EMAIL PROTECTED] > Subject: RE: [JBoss-dev] Accessing Container from an EJB? > > > Thanks - I copied the code to get the registry into the test setup and it > worked like a charm. > > > -Original Message- > > From: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED]]On Behalf Of David > > Jencks > > Sent: Thursday, January 30, 2003 9:13 AM > > To: [EMAIL PROTECTED] > > Subject: Re: [JBoss-dev] Accessing Container from an EJB? > > > > > > Well, one solution in jboss 4 that doesnt add any more code is: > > > > I figure you know the object name for the ejbModule mbean you are > > writing the test. > > > > I just added a jmx method in ServiceMBeanSupport to return the actual > > object behind an mbean. You can use this (or pre-jboss 4 similar code) > > to get the actual ejbModule object and call whatever method you want on > > it. I don't know if this will work with the Container mbean since it > > is dynamic. > > > > david > > > > > > --- > This SF.NET email is sponsored by: > SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! > http://www.vasoftware.com > ___ > Jboss-development mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-development --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Accessing Container from an EJB?
Thanks - I copied the code to get the registry into the test setup and it worked like a charm. > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]]On Behalf Of David > Jencks > Sent: Thursday, January 30, 2003 9:13 AM > To: [EMAIL PROTECTED] > Subject: Re: [JBoss-dev] Accessing Container from an EJB? > > > Well, one solution in jboss 4 that doesnt add any more code is: > > I figure you know the object name for the ejbModule mbean you are > writing the test. > > I just added a jmx method in ServiceMBeanSupport to return the actual > object behind an mbean. You can use this (or pre-jboss 4 similar code) > to get the actual ejbModule object and call whatever method you want on > it. I don't know if this will work with the Container mbean since it > is dynamic. > > david > --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Accessing Container from an EJB?
David Jencks wrote
>
> I'm pretty confused about what exactly you are trying to do, since
> there is already an instance variable ejbModule and and accessors
> get/setEjbModule in the Container class.
>
I am trying to unit test changes to JDBCEJBQLCompiler by comparing the SQL
generated to known values. Its constructor takes a Catalog, which is the
metadata about the abstract schema in this deployment and is stored in the
EjbModule moduleData. Trying to construct one from scratch is a nightmare,
so my intention was to deploy the ejb-jar and get the Catalog created during
deployment.
The problem I had was getting access to the EjbModule from the test case
EJB. I know the ObjectName of the Container but the MBeanServer isolates me
from the get/setEjbModule as it is not a declared JMX attribute. I was able
to solve this by adding
if("EjbModule".equals(attribute))
{
return getEjbModule();
}
to Container.getAttribute(String attribute) to declare it but was wondering
if
a) there was a better way of getting the EjbModule, or
b) another way of getting a direct reference to the Container
so I can call getEjbModule().
And also, whether it was OK to declare this attribute.
Thanks
Jeremy
---
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Accessing Container from an EJB?
I am trying to write an EJBTestCase that needs access to information held in
the Container (Container.getEjbModule().getModuleData("CATALOG")). I can do
this if I add EjbModule as a attribute of Container but was wondering if I
should do this or if there was another way?
Thanks
Jeremy
---
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] 3.2.0 and commons-httpclient.jar
This is needed by the Slide client library webdavlib used for URL scanning over http (e.g. netboot). They are loaded during boot as deployment of the initial conf/jboss-service.xml SAR may need to scan URLs (e.g. by default it contains the wildcard ); basically, they may be used by SARDeployer to deploy the first sar. These libraries are only used during netboot - if you are not using that function they can be safely removed. > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]]On Behalf Of > Stefan Arentz > Sent: Sunday, January 26, 2003 7:35 AM > To: [EMAIL PROTECTED] > Subject: [JBoss-dev] 3.2.0 and commons-httpclient.jar > > > I noticed that 3.2.0 now includes a commons-httpclient.jar in > $JBOSS_HOME/lib. Shouldn't this be in the .sar that actually uses this > library? The problem is that I also use http-commons.jar in my own > project and because the JBoss provided one is in $JBOSS_HOME/lib, it is > always found first. Isn't that wrong? > > Stefan > > > > --- > This SF.NET email is sponsored by: > SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! > http://www.vasoftware.com > ___ > Jboss-development mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-development --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Re: how's ecperf going?
> * JAWS checks for the existence of a PK before inserting a new row in > the database. This is pretty expensive. There is a patch for skipping the PK test [636794]. --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] jboss-3.2.0RC1: farming problem
Bill This one is mine I think - this is change to requiring valid collection URLs as described here: http://sourceforge.net/tracker/index.php?func=detail&aid=660839&group_id=228 66&atid=381174 I did not update farm-service.xml. Are there any directions for running the testsuite on a cluster? Thanks Jeremy > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]]On Behalf Of Bill > Burke > Sent: Monday, January 20, 2003 1:57 PM > To: [EMAIL PROTECTED] > Subject: RE: [JBoss-dev] jboss-3.2.0RC1: farming problem > > > can you log a bug and assign it to me? > > > -Original Message- > > From: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED]]On Behalf Of David > > Klimek > > Sent: Monday, January 20, 2003 4:48 PM > > To: jboss-development > > Subject: [JBoss-dev] jboss-3.2.0RC1: farming problem > > > > > > Hello, > > > > I have little problem with jboss-3.2.0RC1 and farming. > > > > I run all configuration build from sources. All services > > started corectly. > > > > But when I copy wars into farm directory nothing happens > > and nothing is deployed. > > > > workaround for this problem is to change > > > > > > ./farm > > > > > > to > > > > > > ./farm/ > > > > > > and then farming work correctly. > > > > I noticed this problem also in HEAD. > > > > Greets, > > David > > > > -- > > http://www.sweb.cz/david.klimek > > > > > > > > --- > > 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 --- 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] Finders, Selectors and ... deleters?
I opened a topic with the title "Should we just use SQL-99 for JBoss-QL?" > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]]On Behalf Of Bill > Burke > Sent: Friday, January 17, 2003 10:24 AM > To: [EMAIL PROTECTED] > Subject: RE: [JBoss-dev] Finders, Selectors and ... deleters? > > > Please archive this on the Persistence forum. Thanks guys. > > Bill > > > -Original Message- > > From: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED]]On Behalf Of Dain > > Sundstrom > > Sent: Friday, January 17, 2003 1:14 PM > > To: [EMAIL PROTECTED] > > Subject: Re: [JBoss-dev] Finders, Selectors and ... deleters? > > > > > > On Friday, January 17, 2003, at 11:08 AM, Jeremy Boynes wrote: > > > > > This leaves the JBoss-QL part read-only (it just qualifies the > > > instances to > > > be deleted). We know we're deleting Transactions as the method would > > > be on > > > the home interface for the Transaction EJB. > > > > I think we should support a full CRUD language. Specifically, I mean > > that the user should not be restricted to just specifying the WHERE > > clause, but they should be required to specify a DELETE clause also. > > Then we just put in a restriction that a remove method on the home > > interface is only allowed to remove entities of the current type. This > > is the same restriction finders have. > > > > The reason I think we should have a full CRUD language is it allows an > > ejbSelect style method (although we may call it something else) to > > delete any set of objects with a single operation. This will be > > particularly useful to delete a subset of related objects. > > > > -dain > > > > > > > > --- > > This SF.NET email is sponsored by: Thawte.com - A 128-bit > supercerts will > > allow you to extend the highest allowed 128 bit encryption to all your > > clients even if they use browsers that are limited to 40 bit encryption. > > Get a guide > here:http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0030en > > ___ > > Jboss-development mailing list > > [EMAIL PROTECTED] > > https://lists.sourceforge.net/lists/listinfo/jboss-development > > > > --- > This SF.NET email is sponsored by: Thawte.com - A 128-bit supercerts will > allow you to extend the highest allowed 128 bit encryption to all your > clients even if they use browsers that are limited to 40 bit encryption. > Get a guide here:http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0030en > ___ > Jboss-development mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-development --- This SF.NET email is sponsored by: Thawte.com - A 128-bit supercerts will allow you to extend the highest allowed 128 bit encryption to all your clients even if they use browsers that are limited to 40 bit encryption. Get a guide here:http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0030en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Finders, Selectors and ... deleters?
> I was thinking about something while looking at my application's > database behaviour... in many cases it is very inefficient to use a > finder method together with remove() for large collections. It would be > so much more efficient to have something like > >public int deleteByCode(int code); > > > deleteByCode > > int > > > delete from Transactions t where t.code = ?1 > > > > This all of course integrated with the cache so that it invalidates > objects that are already loaded, etc. > This is the same semantic (i.e. remove a load of stuff :-) that we need to improve to make efficient. I would be fairly easy to extend that to user-defined operations. I'm against adding delete (or insert and update) semantics to JBoss-QL though - that changes the nature of the language from read-only to read-write. Instead you could define a DeleteMethod as: deleteByCode int where code = ?1 or, using values from the another entity via a subquery deleteByCode int where code in (select x.code from another x where x.flag = ?1) This leaves the JBoss-QL part read-only (it just qualifies the instances to be deleted). We know we're deleting Transactions as the method would be on the home interface for the Transaction EJB. It would be easy enough to extend this to bulk update as well - ok, easy if you limited the update to single-valued fields. Bulk create would be harder (need to pass in a lot of data), and probably unnecessary given we plan to have batch insert anyway. --- This SF.NET email is sponsored by: Thawte.com - A 128-bit supercerts will allow you to extend the highest allowed 128 bit encryption to all your clients even if they use browsers that are limited to 40 bit encryption. Get a guide here:http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0030en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: Re[6]: [JBoss-dev] URLConnection and opened files
OK - changed this in 3.2 and HEAD and I can now delete a .war archive I couldn't before. Alex, can you let me know if this worked for you. Sorry about the hassle. > > Yes, the setup of the URL handlers should be the very first thing > done in doInit. > There is nothing in that layer that can rely on ServerConfig > information as this > is just standard URL protocol handler extension stuff. > --- This SF.NET email is sponsored by: A Thawte Code Signing Certificate is essential in establishing user confidence by providing assurance of authenticity and code integrity. Download our Free Code Signing guide: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0028en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re[6]: [JBoss-dev] URLConnection and opened files
Alex The light went on and I'm now wondering if I triggered this with the changes for deployment scanning. IIRC the code used to generate new URLs from the File paths returned during the scan, basically using the URL(String) constructor with the path. It now creates URLs relative to the location being scanned using the URL(URL, String) version. The context URL is the one obtained from ServerConfig.getServerHomeURL(). If this is set before the custom handler factory is set up, then all deployed URLs would be using Sun's handler :-( I think this is happening because ServerImpl.doInit() creates the ServerConfigImpl before setting up the URLStreamHandlerFactory. Would it make sense just to move the factory set-up to the very start of doInit()? Jeremy > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]]On Behalf Of Alex > Loubyansky > Sent: Wednesday, January 15, 2003 5:21 AM > To: Scott M Stark > Subject: Re[6]: [JBoss-dev] URLConnection and opened files > > > Here are my findings. > > First, JBoss-3.0 is ok. The problem is in JBoss-3.2 and HEAD. > > Second, I found the cause. > The resources we want to load with our custom handlers > through class loaders must be added to the classpath AFTER the > (custom) URLStreamHandlerFactory is setup. > > URLClassLoaders hold their URLs. > The URLs created before the custom URLStreamHandlerFactory is set up > have Sun's handler. System class loader is a subclass of the > URLClassLoader. Thus, its URLs have Sun's handler. (It seems to me even > if java.protocol.handler.pkgs is setup. Is it a VM's bug or mine?) > > Suppose we attempt to load resource that was in the classpath before > the custom handler factory was setup. The URL for the resource is > constructed with: URL(URL context, String spec). > where the context URL comes from the class loader with Sun's handler. > Then resource's URL's handler is assigned context.handler. > So, it doesn't matter whether the custom handler factory is setup. > > alex > --- This SF.NET email is sponsored by: A Thawte Code Signing Certificate is essential in establishing user confidence by providing assurance of authenticity and code integrity. Download our Free Code Signing guide: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0028en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: Re[2]: [JBoss-dev] JNuke dev
JBossNuke ? > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]]On Behalf Of > julien viet > Sent: Tuesday, January 14, 2003 12:35 PM > To: Bill Burke > Subject: Re[2]: [JBoss-dev] JNuke dev > > > ok, do you have a name shorter though ? just nuke for instance ? > > BB> Again, > > BB> The type of developer writing content is usually a different > calaber than > BB> those writing server software. IMHO, it needs to be dumbed-down. The > BB> reason why these things like postnuke become so popular is > that they are so > BB> easy to hack for even the least experienced coder. Copy, > cut, paste. Not, > BB> write xml, compile, jar, maintain ANT files, etc... You get what I'm > BB> saying? > > BB> This is just something to think about and I'm not advocating > any specific > BB> approach. > > BB> And again, BTW, JNuke is already trademarked. You must call > in Nukes on > BB> JBoss or think of a better name. > > BB> Bill > > >> -Original Message- > >> From: [EMAIL PROTECTED] > >> [mailto:[EMAIL PROTECTED]]On Behalf Of marc > >> fleury > >> Sent: Tuesday, January 14, 2003 2:40 PM > >> To: [EMAIL PROTECTED] > >> Subject: RE: [JBoss-dev] JNuke dev > >> > >> > >> I am all for JMX if it works . Also the idea is to port the modules we > >> like bit by bit to the sar format and this is CLEARLY a > microkernel job. > >> I think julien stroke on something interesting when he noticed the > >> URL:command mapping to interfaces. What this means is that modules will > >> expose interfaces as mbeans and that is all it takes. Difficult? yeah > >> for php guys, heck they must get EJB first. But for us? we are doing > >> the port anyway... > >> > >> let's go julien, speed speed my friend, > >> > >> marcf > >> > >> > -Original Message- > >> > From: [EMAIL PROTECTED] > >> > [mailto:[EMAIL PROTECTED]] On > >> > Behalf Of Dain Sundstrom > >> > Sent: Tuesday, January 14, 2003 2:19 PM > >> > To: [EMAIL PROTECTED] > >> > Subject: Re: [JBoss-dev] JNuke dev > >> > > >> > > >> > I think you are dreaming, if you think you will every recruit php > >> > developers to any java based solution. Ben, remember the Orielly OS > >> > convention? The php guys are perl guys. > >> > > >> > -dain > >> > > >> > On Tuesday, January 14, 2003, at 01:03 PM, Ben Sabrin wrote: > >> > > >> > > Are we developing this for the PHP community or the Java > >> > community? > >> > > Or more important for the JBoss community? To me it seems that it > >> > > would depend on who you are targeting for your user base. > >> > If you want > >> > > to target the PHP users to bring them to JBoss, then Bill could be > >> > > right. If we do not care about the PHP community, we go > >> > down the JMX > >> > > way. I think the PHP community will never want to do anything with > >> > > JSP. They believe they have what they need to be > >> > successful and will > >> > > continue to innovate in their own circle. For most of the PHP > >> > > community, what they have built is scalable to their needs. > >> > > > >> > >> -Original Message- > >> > >> From: [EMAIL PROTECTED] [mailto:jboss- > >> > >> [EMAIL PROTECTED]] On Behalf Of Bill Burke > >> > >> Sent: Tuesday, January 14, 2003 1:51 PM > >> > >> To: [EMAIL PROTECTED] > >> > >> Subject: RE: [JBoss-dev] JNuke dev > >> > >> > >> > >> The only negative comment I have in using JMX is that the PHP > >> > > community > >> > >> may > >> > >> have a tough time switching over to Nukes on JBoss if you have to > >> > >> have > >> > > a > >> > >> package structure like a SAR or a WAR. I hate to say it, > >> > but does it > >> > > need > >> > >> to be "dumbed-down" for the PHP community? This type of community > >> > > needs > >> > >> to > >> > >> be able to edit a JSP and immediately see the change on the > >> > >> webserver. > >> > > Is > >> > >> it possible to be all JSP based for themes, modules and > >> > blocks? You > >> > > could > >> > >> use a URL fragement and JSP:Include to decide what theme to use. > >> > >> > >> > >> Just a thought. Maybe JMX and such is the way to go. > Just want to > >> > > give > >> > >> you > >> > >> something to think about. > >> > >> > >> > >> Bill > >> > >> > >> > >>> -Original Message- > >> > >>> From: [EMAIL PROTECTED] > >> > >>> [mailto:[EMAIL PROTECTED]]On > >> > Behalf Of > >> > >>> julien viet > >> > >>> Sent: Tuesday, January 14, 2003 11:31 AM > >> > >>> To: SourceForge.net > >> > >>> Subject: [JBoss-dev] JNuke dev > >> > >>> > >> > >>> > >> > >>> hi folks, > >> > >>> > >> > >>> JNuke adventure has started. > >> > >>> After analysis of PostNuke I've began the development, > still early > >> > >> though. > >> > >>> > >> > >>> I keep everything that's good in PostNuke and throw all the shit > >> > > away : > >> > >>> > >> > >>> modules, blocks, permissions system, url system and themes. > >> > >>> > >> > >>> JMX is used for PostNuke components : themes, > >> > >>> modules and blocks are all JMX mbeans. Here are my reasons
RE: [JBoss-dev] MBean persistence?
Title: Re: [JBoss-dev] MBean persistence? Like Matt, I have concerns about modifying the files in the deployment as well. I think his concerns about division of roles are valid - I'd go further and say this needs to be able to handle a split between 'deployer' and 'operator/sys admin' as well (where e.g. deployer defines which database to use, the sys admin defines the connection pool size). There are also circumstances where the SAR will be unmodifyable - e.g. if it is set read-only on the OS or if it is loaded from an http: URL. One possibility might be to store the local changes as a transform applied against the original file e.g. an XSLT. This also has the advantage that local changes don't get lost when a new version is received from development. Also the same file can be rolled dev->test->stage->prod without needing to modify the deployment descriptor each time (one of the biggest compaints I've had from sys admins). -Original Message-From: Matt Munz [mailto:[EMAIL PROTECTED]]On Behalf Of Matt MunzSent: Monday, January 13, 2003 8:47 AMTo: [EMAIL PROTECTED]Subject: RE: [JBoss-dev] MBean persistence? (copied from a message I sent direct to Bill) Bill, I couldn't figure out how to add a comment to the task, so I'm just emailing you. > I think we want seemless integration here I think you're integrating apples and oranges ;) What you've described does not match the current behavior of the ObjectStreamPersistenceManager. Are you saying that the jboss-service.xml files should be dynamically modified? I think that this adds unneeded complexity. Here is how I currently use MBean Persistence in my applications. --- jboss-service.xml - describes the initial (deploy-time) configuration of the bean, and the location of the corresponding XMBean descriptor xml. *-xmbean.xml - describes the signature of the metadata for the MBean. Includes the persistence configuration. Specifies the persistence type (ObjectOutputStream) and the persistence store name. /$Persistence_Dir/$Persistence_Store_Name.oos - the file where the MBean Server stores the record of the dynamically changing state of the MBean. --- Exchange XML for ObjectOutputStream and .xml for .oos in the above, and I believe we have a production-ready MBean Persistence mechanism. MBean persistence and MBean deployment are two separate mechanisms/concepts. This separation of concerns is *very* important, IMO, to preserve flexibility and ease-of-use/development. There are all sorts of things that need to go into a deployment descriptor that have little to do with the persistent state of the MBean, and vice versa. Although I see the motivation for a "Grand Unified Descriptor", I don't see a rationale for it. I think a use case would really help here. For example, I don't see an individual in the "deployment" role ever touching the deployed archive. Rather they would use the JMX Console to modify the MBean attributes, which would be recorded in the MBean Persistence Store (XML, JDBC, OOS, whatever), and that would be the extent of their configuration work. In the case of an extreme server failure (uncommon), they could hack the store directly when the server was off-line (XML files, JDBC Tables...). Although this case is relatively uncommon, I believe this is one example where the separation of concerns mentioned above is useful. If I get the server into an inconsistent state and, as a result, it fails at restart (the inconsistency is reloaded), then, I can always delete the Persistence Store. When the server restarts, it returns to a clean-slate (deploy-time) state. If, as you seem to be suggesting, the (inconsistent) state has been stored in the deployment descriptors themselves, however, this clean-slate is not possible. One must go through each descriptor until the erroneous state information is found. Then it must be manually corrected. Since the MBean persistence engine will be writing to these files automatically, it may not be apparent how to do this. Could you explain further the behaviour you would like to see in MBean Persistence? - Matt <>
RE: [JBoss-dev] New XDoclet module: I can't compile JBoss anymore
Building twice worked - thanks (if a little worrying) > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]]On Behalf Of David > Jencks > Sent: Friday, December 27, 2002 12:13 PM > To: [EMAIL PROTECTED] > Subject: Re: [JBoss-dev] New XDoclet module: I can't compile JBoss > anymore > > > This problem I know about. For me, building twice works. > > Either ant or buildmagic is messed up IMO. the xdoclet tasks seem to come > and go with no pattern I can discern. Look at > tools/etc/buildfragments/tools.ent. Redefining the tasks for each module > breaks in one place, not redefining breaks in another place. I'm waiting > for more inspiration... > > david jencks > > On 2002.12.27 13:44:41 -0500 Jeremy Boynes wrote: > > I got slightly further but a fresh checkout breaks for me as well > > (WinXP/Sun > > JDK1.4.1). The xdoclet, common and jmx modules seemed to build > but system > > failed. > > > > jar: > > [jar] Building jar: > > > D:\JBoss\jboss-head\xdoclet\checkout\xdoclet-all\xdocletgui\build\ > xdocletgui > > .jar > > [touch] Creating D:\JBoss\jboss-head\xdoclet\last.xdoclet.build > > > > compile: > > > > output: > > > > _default:most: > > > > most: > > > > == > > == > > == Finished 'most' in module 'xdoclet'. > > == > > == > > > > > > << SNIP >> > > > > most: > > > > == > > == > > == Finished 'most' in module 'jmx'. > > == > > == > > > > > > _module-jmx-most: > > [copy] Copying 1 file to > > D:\JBoss\jboss-head\build\output\jboss-4.0.0alpha\lib > > [copy] Copying 2 files to > > D:\JBoss\jboss-head\build\output\jboss-4.0.0alpha\lib > > [mkdir] Created dir: > > D:\JBoss\jboss-head\build\output\jboss-4.0.0alpha\docs\dtd > > [copy] Copying 1 file to > > D:\JBoss\jboss-head\build\output\jboss-4.0.0alpha\docs\dtd > > [mkdir] Created dir: > > D:\JBoss\jboss-head\build\output\jboss-4.0.0alpha\server\default\deploy > > [echo] Copying service descriptors to install.server: > > D:\JBoss\jboss-head\build/output/jboss-4.0.0alpha/server > > [copy] Copying 1 file to > > D:\JBoss\jboss-head\build\output\jboss-4.0.0alpha\server\default\deploy > > > > == > > == > > == Executing 'most' in module 'system'... > > == > > == > > > > _buildmagic:init: > > > > configure: > > > > configure-libraries: > > > > configure-modules: > > Overriding previous definition of reference to jboss.naming.classpath > > > > configure-defaults: > > > > configure-tools: > > > > _default:init: > > > > init: > > > > compile-mbean-sources: > > [mkdir] Created dir: D:\JBoss\jboss-head\system\output\gen\classes > > > > BUILD FAILED > > > > file:D:/JBoss/jboss-head/system/build.xml:120: Could not create task or > > type > > of type: jmxdoclet. > > > > > > > > > > --- > > 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 --- 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] New XDoclet module: I can't compile JBoss anymore
I got slightly further but a fresh checkout breaks for me as well (WinXP/Sun JDK1.4.1). The xdoclet, common and jmx modules seemed to build but system failed. jar: [jar] Building jar: D:\JBoss\jboss-head\xdoclet\checkout\xdoclet-all\xdocletgui\build\xdocletgui .jar [touch] Creating D:\JBoss\jboss-head\xdoclet\last.xdoclet.build compile: output: _default:most: most: == == == Finished 'most' in module 'xdoclet'. == == << SNIP >> most: == == == Finished 'most' in module 'jmx'. == == _module-jmx-most: [copy] Copying 1 file to D:\JBoss\jboss-head\build\output\jboss-4.0.0alpha\lib [copy] Copying 2 files to D:\JBoss\jboss-head\build\output\jboss-4.0.0alpha\lib [mkdir] Created dir: D:\JBoss\jboss-head\build\output\jboss-4.0.0alpha\docs\dtd [copy] Copying 1 file to D:\JBoss\jboss-head\build\output\jboss-4.0.0alpha\docs\dtd [mkdir] Created dir: D:\JBoss\jboss-head\build\output\jboss-4.0.0alpha\server\default\deploy [echo] Copying service descriptors to install.server: D:\JBoss\jboss-head\build/output/jboss-4.0.0alpha/server [copy] Copying 1 file to D:\JBoss\jboss-head\build\output\jboss-4.0.0alpha\server\default\deploy == == == Executing 'most' in module 'system'... == == _buildmagic:init: configure: configure-libraries: configure-modules: Overriding previous definition of reference to jboss.naming.classpath configure-defaults: configure-tools: _default:init: init: compile-mbean-sources: [mkdir] Created dir: D:\JBoss\jboss-head\system\output\gen\classes BUILD FAILED file:D:/JBoss/jboss-head/system/build.xml:120: Could not create task or type of type: jmxdoclet. --- 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] Committed support for remote deployment scanning
I put in a check so that errors getting last-modified do not trigger redeployment. > > I haven't I'm afraid, I did enough to get the rest of my team > working and left it at that :-(. I suspect it may be similar > to the WebSphere problem that I had to work around. > > I'll have a quick look at it again and see if I can get any > further, although we have just upgraded Solaris and it may > no longer happen :-). > > Thanks again, > Kev > I don't have a Solaris host to test with so any help here is appreciated. Thanks Jeremy --- 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] Committed support for remote deployment scanning
> Did you have a look at bug 598335? We logged this against > the URLDirectoryScanner for netboot deployments. There is > also a proposed fix which we would like to see incorporated > into your code if it is still applicable. > > Thanks, > Kev > Kevin I hadn't, but have now. I have not changed URLDirectoryScanner but attempted to roll its functionality into the core URLDeploymentScanner using collection URLs to discriminate - does this work for you? It seems the root cause of your bug is the lack of response to the GET request used by getLastModified(). This is basically Jetty not responding to a simple GET request which seems a bit more fundamental. The old netboot helper mapped the host server's configuration to a /files URL by adding a dedicated context handler. The new helper does not use the host server's configurations but instead stores the config in a war - so, the GET for last-modified is handled directly by the container and if this is broken, GET for any resource is broken :-( Did you ever find out why Jetty is closing the socket without responding, or log a bug for it? Jeremy --- This SF.NET email is sponsored by: The Best Geek Holiday Gifts! Time is running out! Thinkgeek.com has the coolest gifts for your favorite geek. Let your fingers do the typing. Visit Now. T H I N K G E E K . C O Mhttp://www.thinkgeek.com/sf/ ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Committed support for remote deployment scanning
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 Costin says, it is probably safest to assume all entries must be local paths as in java.class.path (see http://java.sun.com/j2se/1.4.1/docs/tooldocs/solaris/classpath.html). I'll open a bug against JBossWeb so we can track this. I think it could be tied to the DeploymentCache so that any web-based archive can be downloaded on demand and aged out when no longer required. I'd suggest requiring all non-J2SE/Servlet classes be included within the war anyway. It makes the war a standalone unit and would allow, for example, the JSPs to be pre-compiled prior to deployment. It also means the same war would work netbooted or not - the requirements are just a little stricter in general. > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]]On Behalf Of Scott > M Stark > Sent: Thursday, December 19, 2002 6:02 PM > To: [EMAIL PROTECTED] > Subject: Re: [JBoss-dev] Committed support for remote deployment > scanning > > > 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/jsp integration layer > that needs this so its > this layer that has to deal with the problem, if in fact it is a > problem. The question is > why are the non-file URLs being stripped? Based on Costin's > response it sounds > like this may no longer be valid for the version of japser being > used in main. Let's > find this out first. > > We can't have different packing requirements depending on whether > or not we > are netbooting. > > > Scott Stark > Chief Technology Officer > JBoss Group, LLC > > > - Original Message - > From: "Jeremy Boynes" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Sent: Thursday, December 19, 2002 2:38 PM > Subject: RE: [JBoss-dev] Committed support for remote deployment scanning > > > > 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.separator) delimited > String. This > > String is generated by iterating over the context classloaders and > > concatenating all their URLs together (see > > JBossWebApplicationContext.getFileClassPath() and > > JspRuntimeContext.initClassPath()). Any URLs that are not file: are > > discarded as they cannot be converted to a local canonical path. > > > > Boot libraries are not copied to the local machine first so > have URLs based > > on HOME_URL. Libraries loaded later are copied locally so have > URLs relative > > to SERVER_BASE_DIR. Basically boot libraries will have file: or > http: URLs > > depending on where the server was booted from; all others will > have file: > > URLs due to the local copy. > > > > As a result boot libraries, even though they are in the thread's > > classloader, are not passed to the JSP compiler because > non-file: URLs are > > stripped. > > > > I think the solution here is to pass everything in the > classloader chain to > > the JSP compiler to ensure that the compilation context will be > the same as > > the runtime context. I believe concatenating everything > together, stripping > > non-file: URLs in the process, and then splitting it apart > later is asking > > for trouble in the long (or maybe short) term. However, I don't > know enough > > about Jetty/Jasper to know if there are issues with this. > > > > An alternative would be for ServerLoader to copy everything local during > > boot, but that leaves the problem of non-file URLs lurking (for > example, if > > we decide at some point not to copy everything local every > time). It also > > makes netboot more 'install-on-demand' rather than > 'boot-from-network' but > > that's just me being anal :-) > > > > --- > This SF.NET email is sponsored by: G
RE: [JBoss-dev] Committed support for remote deployment scanning
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.separator) delimited String. This String is generated by iterating over the context classloaders and concatenating all their URLs together (see JBossWebApplicationContext.getFileClassPath() and JspRuntimeContext.initClassPath()). Any URLs that are not file: are discarded as they cannot be converted to a local canonical path. Boot libraries are not copied to the local machine first so have URLs based on HOME_URL. Libraries loaded later are copied locally so have URLs relative to SERVER_BASE_DIR. Basically boot libraries will have file: or http: URLs depending on where the server was booted from; all others will have file: URLs due to the local copy. As a result boot libraries, even though they are in the thread's classloader, are not passed to the JSP compiler because non-file: URLs are stripped. I think the solution here is to pass everything in the classloader chain to the JSP compiler to ensure that the compilation context will be the same as the runtime context. I believe concatenating everything together, stripping non-file: URLs in the process, and then splitting it apart later is asking for trouble in the long (or maybe short) term. However, I don't know enough about Jetty/Jasper to know if there are issues with this. An alternative would be for ServerLoader to copy everything local during boot, but that leaves the problem of non-file URLs lurking (for example, if we decide at some point not to copy everything local every time). It also makes netboot more 'install-on-demand' rather than 'boot-from-network' but that's just me being anal :-) > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]]On Behalf Of Scott > M Stark > Sent: Thursday, December 19, 2002 11:01 AM > To: [EMAIL PROTECTED] > Subject: Re: [JBoss-dev] Committed support for remote deployment > scanning > > > - 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 Jasper > > compiler needs the compilation classpath supplied as a String of > > concatenated local paths and any http: based URLs are > excluded. This means > > anything added to the classpath during boot is not available if the > > server was netbooted. This should not be an issue for normal > applications > > but was for jmx-console.war which assumed jboss-jmx.jar would > be on the > > compilation classpath. > > This is a big problem and something we have worked to avoid with > our 3.0 classloading > model. Explain why the boot classpath is not available. > > > Scott Stark > Chief Technology Officer > JBoss Group, LLC > > > > > > > --- > 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 http://www.thinkgeek.com/sf/ > ___ > Jboss-development mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-development --- 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 http://www.thinkgeek.com/sf/ ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Sar deployed before Jar?
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: [EMAIL PROTECTED] > Subject: [JBoss-dev] Sar deployed before Jar? > > > 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 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 http://www.thinkgeek.com/sf/ > ___ > Jboss-development mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-development --- 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 http://www.thinkgeek.com/sf/ ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Committed support for remote deployment scanning
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-modified value from the scan as each unit may have a different watchUrl from the the deployment url. Instead it relies on DeployedURL.isModified() which implies a network trip. So, yes, hot deployment is supported even over http but it would be possible to optimize this, especially for the remote situation where things are always packed and watchUrl == url, if you think it's necessary. There are a couple of other things that could be looked at here as well: * Should getWatchUrl() be part of the (Sub)Deployer contract? * Should we tidy up the mechanism for local copies and hook in the deployment cache? * Should we support unpacked remote (maybe with a helper to auto-jar on the server)? * Should we be smarter about re-deployment (e.g. factor in dependencies)? and generally, can deployment be simplified? It seems to have evolved and be more complex than necessary, or maybe I'm just tired :-) Jeremy PS I need to get the netboot-demo finished for Jason - this was a pre-req to simplifying that. > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]]On Behalf Of Sacha > Labourey > Sent: Thursday, December 19, 2002 9:57 AM > To: [EMAIL PROTECTED] > Subject: RE: [JBoss-dev] Committed support for remote deployment > scanning > > > 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:51 > > À : Jboss-Development > > Objet : [JBoss-dev] Committed support for remote deployment scanning > > > > > > 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 > > by seeing if the URL ends in a "/" (as it should do for a directory) > > rather than by doing an extra network trip. So "./deploy" > > became "deploy/" > > I updated the default jboss-service.xml but modified versions will be > > impacted. > > > > * All remote deployables must be packed. This seemed reasonable as you > > would want to fetch them in one operation rather than > recursing down the > > remote collection hierarchy (which would be rather inefficient). > > > > * All WARs must contain all jars needed for JSP compilation. The Jasper > > compiler needs the compilation classpath supplied as a String of > > concatenated local paths and any http: based URLs are excluded. > > This means > > anything added to the classpath during boot is not available if the > > server was netbooted. This should not be an issue for normal > > applications > > but was for jmx-console.war which assumed jboss-jmx.jar would > be on the > > compilation classpath. > > > > This change incorporates all the functionality in > URLDirectoryScanner and > > HttpDeploymentScanner - are people using these or can I delete them? > > > > Finally, I tested this on a single node but FarmServiceMember extends > > URLDeploymentScanner so cluster configs may be affected. Can > > someone give me > > guidelines on running the cluster testsuite (e.g. what > > config/hardware do I > > need), or quickly test this for me? > > > > Cheers > > Jeremy > > > > > > > > --- > > 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 http://www.thinkgeek.com/sf/ > > ___ > > Jboss-development mailing list > > [EMAIL PROTECTED] > > https://lists.sourceforge.net/lists/listinfo/jboss-development > > > > > > --- > 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 http://www.thinkgeek.com/sf/ >
[JBoss-dev] Committed support for remote deployment scanning
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 by seeing if the URL ends in a "/" (as it should do for a directory) rather than by doing an extra network trip. So "./deploy" became "deploy/" I updated the default jboss-service.xml but modified versions will be impacted. * All remote deployables must be packed. This seemed reasonable as you would want to fetch them in one operation rather than recursing down the remote collection hierarchy (which would be rather inefficient). * All WARs must contain all jars needed for JSP compilation. The Jasper compiler needs the compilation classpath supplied as a String of concatenated local paths and any http: based URLs are excluded. This means anything added to the classpath during boot is not available if the server was netbooted. This should not be an issue for normal applications but was for jmx-console.war which assumed jboss-jmx.jar would be on the compilation classpath. This change incorporates all the functionality in URLDirectoryScanner and HttpDeploymentScanner - are people using these or can I delete them? Finally, I tested this on a single node but FarmServiceMember extends URLDeploymentScanner so cluster configs may be affected. Can someone give me guidelines on running the cluster testsuite (e.g. what config/hardware do I need), or quickly test this for me? Cheers Jeremy --- 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 http://www.thinkgeek.com/sf/ ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Nested deployments in WAR
I have a war file which contains other deployable units as resources intended to be served to clients. For example, the war contains /files/server/default/deploy/petstore.ear /files/server/default/conf/jboss-service.xml When I deploy this war on JBoss, nested deployment tries to start all these units. This goes to pieces very quickly as the war contains an actual configuration (it's intended to be a netboot host). Is this the intended behaviour or is nested deployment being too aggressive? This is a simple war file, not an ear. Thanks Jeremy --- 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
RE: [JBoss-dev] [AUTOMATED] (HEAD) JBoss compilation failed
Or, from Jason
cd jboss-head/thirdparty
cvs get _thirdparty_apache_slide
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On Behalf Of
> Adrian Brock
> Sent: Friday, December 13, 2002 5:52 PM
> To: [EMAIL PROTECTED]
> Subject: Re: [JBoss-dev] [AUTOMATED] (HEAD) JBoss compilation failed
>
>
> Full CVS checkout requested.
>
> Regards,
> Adrian
>
> >From: [EMAIL PROTECTED]
> >Reply-To: [EMAIL PROTECTED]
> >To: [EMAIL PROTECTED]
> >CC: [EMAIL PROTECTED]
> >Subject: [JBoss-dev] [AUTOMATED] (HEAD) JBoss compilation failed
> >Date: Sat, 14 Dec 2002 01:35:29 GMT
> >
> >=
> >==THIS IS AN AUTOMATED EMAIL - SEE http://jboss.kimptoc.net FOR DETAILS=
> >=
> >
> >JAVA VERSION DETAILS
> >java version "1.3.1_06"
> >Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.1_06-b01)
> >Java HotSpot(TM) Server VM (build 1.3.1_06-b01, mixed mode)
> >
> >=
> >
> >HERE ARE THE LAST 50 LINES OF THE LOG FILE
> >
> >[execmodules]
> >/home/jboss/jbossci/jboss-all/common/src/main/org/jboss/net/proto
col/http/DavURLLister.java:21:
> >cannot resolve symbol
> >[execmodules] symbol : class HttpURL
> >[execmodules] location: package util
> >[execmodules] import org.apache.util.HttpURL;
> >[execmodules]^
> >[execmodules]
> >/home/jboss/jbossci/jboss-all/common/src/main/org/jboss/net/proto
col/http/DavURLLister.java:22:
> >cannot resolve symbol
> >[execmodules] symbol : class WebdavResource
> >[execmodules] location: package lib
> >[execmodules] import org.apache.webdav.lib.WebdavResource;
> >[execmodules] ^
> >[execmodules]
> >/home/jboss/jbossci/jboss-all/common/src/main/org/jboss/logging/X
Priority.java:79:
> >warning: toPriority(java.lang.String) in
> org.apache.log4j.Priority has been
> >deprecated
> >[execmodules]public static Priority toPriority(String name)
> >[execmodules] ^
> >[execmodules]
> >/home/jboss/jbossci/jboss-all/common/src/main/org/jboss/net/proto
col/http/DavURLLister.java:36:
> >cannot resolve symbol
> >[execmodules] symbol : class WebdavResource
> >[execmodules] location: class org.jboss.net.protocol.http.DavURLLister
> >[execmodules] WebdavResource resource = new
> >WebdavResource(baseUrl.toString());
> >[execmodules] ^
> >[execmodules]
> >/home/jboss/jbossci/jboss-all/common/src/main/org/jboss/net/proto
col/http/DavURLLister.java:36:
> >cannot resolve symbol
> >[execmodules] symbol : class WebdavResource
> >[execmodules] location: class org.jboss.net.protocol.http.DavURLLister
> >[execmodules] WebdavResource resource = new
> >WebdavResource(baseUrl.toString());
> >[execmodules]^
> >[execmodules]
> >/home/jboss/jbossci/jboss-all/common/src/main/org/jboss/net/proto
col/http/DavURLLister.java:37:
> >cannot resolve symbol
> >[execmodules] symbol : class WebdavResource
> >[execmodules] location: class org.jboss.net.protocol.http.DavURLLister
> >[execmodules] WebdavResource[] resources =
> >resource.listWebdavResources();
> >[execmodules] ^
> >[execmodules]
> >/home/jboss/jbossci/jboss-all/common/src/main/org/jboss/net/proto
col/http/DavURLLister.java:40:
> >cannot resolve symbol
> >[execmodules] symbol : class WebdavResource
> >[execmodules] location: class org.jboss.net.protocol.http.DavURLLister
> >[execmodules] WebdavResource member = resources[i];
> >[execmodules] ^
> >[execmodules]
> >/home/jboss/jbossci/jboss-all/common/src/main/org/jboss/net/proto
col/http/DavURLLister.java:41:
> >cannot resolve symbol
> >[execmodules] symbol : class HttpURL
> >[execmodules] location: class org.jboss.net.protocol.http.DavURLLister
> >[execmodules] HttpURL httpURL = member.getHttpURL();
> >[execmodules] ^
> >[execmodules]
> >/home/jboss/jbossci/jboss-all/common/src/main/org/jboss/net/proto
col/http/DavURLLister.java:51:
> >cannot resolve symbol
> >[execmodules] symbol : class HttpException
> >[execmodules] location: class org.jboss.net.protocol.http.DavURLLister
> >[execmodules] } catch (HttpException e) {
> >[execmodules]^
> >[execmodules] 9 errors
> >[execmodules] 1 warning
> >
> >BUILD FAILED
> >file:/home/jboss/jbossci/jboss-all/common/../tools/etc/buildfragm
ents/targets.ent:45:
>Compile failed; see the compiler error output for details.
>
>Total time: 14 seconds
>
>
>---
>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.sourc
[JBoss-dev] New thirdparty module
I have added the libraries for Apache Slide (WebDAV) to thirdparty as apache-slide (HEAD branch only) This seems to need a fresh checkout to get the new module - does anyone know another way? If not, please be aware I will adding code to jboss-common soon that will depend on it and I'd hate to see builds break due to missing libraries. --- 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
RE: [JBoss-dev] Proposal for changes to URL deployment to clean upnetboot
Sacha Labourey wrote: > > You should check this as well: > http://www.innovation.ch/java/HTTPClient/FAQ.html It is not so big and > implements tons of http stuff (I will most probably use that for HTTP > Session clustering automated test suite). Thanks, I will > > BTW, what is the "size" of all these appache libs? What is the size of > dav4j? What is the license? From Slide: webdavlib.jar 107739 commons-httpclient.jar51384 From dav4j dav4j.jar 170598 it's released under IBM's open source license I plan to go with webdavlib for now and (maybe) switch to a thinner implementation using just an http library later. Jeremy > > Cheers, > > > > sacha > > > -Message d'origine- > > De : [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED]]De la part de > > Jeremy Boynes > > Envoyé : mardi, 10 décembre 2002 19:03 > > À : [EMAIL PROTECTED] > > Objet : RE: [JBoss-dev] Proposal for changes to URL deployment to clean > > up netboot > > > > > > I have a prototype of the changes to SARDeployer ready to go. However, I > > have run into a dependency I don't like. > > > > I had originally thought of writing a trivial DAV client but > had forgotten > > that HttpURLConnection disallows non-standard request methods > > such as DAV's > > PROPFIND. As a result any DAV client needs to implement its own > > transport - > > which is no longer quite so trivial :-( > > > > I looked at three options: > > 1) write the transport > > 2) use the WebDAV client from the Apache Slide project > >(this is the basis for the Tomcat implementation) > > 3) use dav4j > >(this is the basis for the Websphere implementation) > > > > Which to use depends on if > sun.net.www.protocol.http.HttpURLConnection is > > portable across JDK's. If so, it would easy enough to subclass to > > extend the > > protocol; this is exactly what dav4j does. However, I'm > assuming it isn't > > (portable), which means writing the transport from scratch; this is what > > Slide did (in the form of commons-httpclient). > > > > So, right now the prototype uses the Slide api, making jboss-common > > dependent on webdavlib and commons-httpclient. > > > > Being new here, I wanted to ask which direction I should take: > > A) Press on with webdavlib and accept the dependency > > B) Implement our own DAV client using Sun's HttpURLConnection > (like dav4j) > > C) Implement our own DAV client with our own transport > > D) Give up on DAV as a default mechanism and revert to a GET based > >protocol (needs server side helpers) > > > > I lean toward A) as there are existing dependencies during boot (e.g. > > getopt, gnu-regexp, log4j) but I realise that adding more is > undesirable. > > > > Thanks > > Jeremy > > > > > -Original Message- > > > From: [EMAIL PROTECTED] > > > [mailto:[EMAIL PROTECTED]]On > Behalf Of Sacha > > > Labourey > > > Sent: Monday, December 09, 2002 12:18 AM > > > To: [EMAIL PROTECTED] > > > Subject: RE: [JBoss-dev] Proposal for changes to URL > deployment to clean > > > up netboot > > > > > > > > > Hello Jeremy, > > > > > > I did the recent netboot changes to allow for HTTP > hot-redeployment and > > > wildcard usage. That was a first step and the usage of WebDAV > > is a must (I > > > spoke about this to Greg in Geneva). And I agree, there is an > > > inconsistency > > > about the root used for file listing: the current "advanced" > > mode doesn't > > > allow for clients to request different configurations from the > > > same JBossWeb > > > server. I will send you a very small doco I wrote about the > > > current status. > > > > > > Cool changes.Cheers, > > > > > > > > > sacha > > > > > > > -Message d'origine- > > > > De : [EMAIL PROTECTED] > > > > [mailto:[EMAIL PROTECTED]]De la part de > > > > Jeremy Boynes > > > > Envoyé : dimanche, 8 décembre 2002 09:00 > > > > À : [EMAIL PROTECTED] > > > > Objet : RE: [JBoss-dev] Proposal for changes to URL > > deployment to clean > > > > up netboot > > > > > > > > > > > > Scott Stark wrote: > > > > > Sounds ok, but let see some more details. Show how you propose > > > > to rewrite > > > > &g
RE: [JBoss-dev] Proposal for changes to URL deployment to clean upnetboot
I have a prototype of the changes to SARDeployer ready to go. However, I
have run into a dependency I don't like.
I had originally thought of writing a trivial DAV client but had forgotten
that HttpURLConnection disallows non-standard request methods such as DAV's
PROPFIND. As a result any DAV client needs to implement its own transport -
which is no longer quite so trivial :-(
I looked at three options:
1) write the transport
2) use the WebDAV client from the Apache Slide project
(this is the basis for the Tomcat implementation)
3) use dav4j
(this is the basis for the Websphere implementation)
Which to use depends on if sun.net.www.protocol.http.HttpURLConnection is
portable across JDK's. If so, it would easy enough to subclass to extend the
protocol; this is exactly what dav4j does. However, I'm assuming it isn't
(portable), which means writing the transport from scratch; this is what
Slide did (in the form of commons-httpclient).
So, right now the prototype uses the Slide api, making jboss-common
dependent on webdavlib and commons-httpclient.
Being new here, I wanted to ask which direction I should take:
A) Press on with webdavlib and accept the dependency
B) Implement our own DAV client using Sun's HttpURLConnection (like dav4j)
C) Implement our own DAV client with our own transport
D) Give up on DAV as a default mechanism and revert to a GET based
protocol (needs server side helpers)
I lean toward A) as there are existing dependencies during boot (e.g.
getopt, gnu-regexp, log4j) but I realise that adding more is undesirable.
Thanks
Jeremy
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On Behalf Of Sacha
> Labourey
> Sent: Monday, December 09, 2002 12:18 AM
> To: [EMAIL PROTECTED]
> Subject: RE: [JBoss-dev] Proposal for changes to URL deployment to clean
> up netboot
>
>
> Hello Jeremy,
>
> I did the recent netboot changes to allow for HTTP hot-redeployment and
> wildcard usage. That was a first step and the usage of WebDAV is a must (I
> spoke about this to Greg in Geneva). And I agree, there is an
> inconsistency
> about the root used for file listing: the current "advanced" mode doesn't
> allow for clients to request different configurations from the
> same JBossWeb
> server. I will send you a very small doco I wrote about the
> current status.
>
> Cool changes.Cheers,
>
>
> sacha
>
> > -Message d'origine-
> > De : [EMAIL PROTECTED]
> > [mailto:[EMAIL PROTECTED]]De la part de
> > Jeremy Boynes
> > Envoyé : dimanche, 8 décembre 2002 09:00
> > À : [EMAIL PROTECTED]
> > Objet : RE: [JBoss-dev] Proposal for changes to URL deployment to clean
> > up netboot
> >
> >
> > Scott Stark wrote:
> > > Sounds ok, but let see some more details. Show how you propose
> > to rewrite
> > > SARDeployer.parseXMLClasspath using this helper framework.
> > >
> > > I think bbtaining a URLLister should mirror the mechanism for
> > obtain a URL
> > > protocol handler in that one can install the class that obtains a
> > > listing for a given
> > > URL via package search paths.
> > >
> >
> > I was thinking something like
> >
> > public abstract class URLLister {
> >/**
> > * Obtain a lister appropriate for the supplied URL.
> > * @param baseUrl the URL to list; should end in "/" but need not
> > */
> >public static URLLister getLister(URL baseUrl)
> > throws UnsupportedProtocolException // or something
> >{
> >}
> >
> >/**
> > * Return the URLs of members matching the pattern.
> > * The pattern may contain multiple elements separated by ","
> > * Each element may be a wildcard e.g. "*.jar"
> > * @param pattern a pattern to filter members by
> > * @return a Collection of java.net.URL's containing every matching
> > member
> > */
> >public abstract Collection listMembers(String pattern);
> > }
> >
> > but a URLListerFactory with URLLister as an interface is
> probably better.
> > Either implementation would allow handlers to be plugged in.
> >
> > Then the big block of code in SARDeployer.parseXMLClasspath beginning
> > // jason: This section needs to be rewritten to be non http & file
> > //specific. Should probably try to convert to a
> URL early.
> > through the end of the for loop (lines 359 to 501)
> >
> > would become something like:
> > // handle "." special - is this necessary?
> > URL baseUrl;
> >
RE: [JBoss-dev] Proposal for changes to URL deployment to clean upnetboot
Scott Stark wrote:
> Sounds ok, but let see some more details. Show how you propose to rewrite
> SARDeployer.parseXMLClasspath using this helper framework.
>
> I think bbtaining a URLLister should mirror the mechanism for obtain a URL
> protocol handler in that one can install the class that obtains a
> listing for a given
> URL via package search paths.
>
I was thinking something like
public abstract class URLLister {
/**
* Obtain a lister appropriate for the supplied URL.
* @param baseUrl the URL to list; should end in "/" but need not
*/
public static URLLister getLister(URL baseUrl)
throws UnsupportedProtocolException // or something
{
}
/**
* Return the URLs of members matching the pattern.
* The pattern may contain multiple elements separated by ","
* Each element may be a wildcard e.g. "*.jar"
* @param pattern a pattern to filter members by
* @return a Collection of java.net.URL's containing every matching
member
*/
public abstract Collection listMembers(String pattern);
}
but a URLListerFactory with URLLister as an interface is probably better.
Either implementation would allow handlers to be plugged in.
Then the big block of code in SARDeployer.parseXMLClasspath beginning
// jason: This section needs to be rewritten to be non http & file
//specific. Should probably try to convert to a URL early.
through the end of the for loop (lines 359 to 501)
would become something like:
// handle "." special - is this necessary?
URL baseUrl;
if (".".equals(codebase) || "".equals(codebase)) {
// use the parent of the location I am deploying
baseUrl = new URL(di.url, "..");
} else {
// resolve codebase URL relative to SERVER_HOME
baseUrl = new URL(serverHomeUrl, codebase);
}
if ("".equals(archives)) {
// no archives supplied so add the codebase itself
classpath.add(baseUrl);
} else {
// obtain a URLLister for this location
URLLister lister = URLLister.getLister(baseUrl);
classpath.addAll(lister.listMembers(archives));
}
The basic assumption here is that the baseUrl is a collection (as per
RFC2518 (WebDAV)) and hence its members can be listed. The implementation of
URLLister does this in whatever manner is appropriate for the protocol; e.g.
for file: scan the directory (as now) using a FilenameFilter to pattern
match.
For an http: based lister, the DAV implementation would issue a PROPFIND
request and filter the response using the search pattern; in the future this
could be extended to use DASL to filter server side. If the server supports
DAV natively, no additional support would be required; if it doesn't, a
servlet would be used to provide a trivial DAV implementation using either
the app context or by reading the server's configs (like the JBossWeb
helper).
The current http: approach, using a listing URL, could migrate to DAV or
could be a another implementation. However, the details are all hidden
behind URLLister.
This snippet is my thoughts for SARDeployer but the changes to
URLDeploymentScanner would be similar. It would use a different method on
URLLister to return a collection of URLs with properties (e.g.
last-modified) similar to NetBootFile.
Examples of the special cases are:
* SARDeployer treats codebase="." as meaning the directory containing
the unit being deployed; but codebase="lib" is resolved relative to
SERVER_HOME. This seems inconsistent, at least to me.
* SARDeployer makes several (6) checks for the "file:" protocol
* SARDeployer has to handle the special "URL:*" syntax used by NetBootHelper
* NetBootHelper relies on the jboss.netboot.listing.url system property
which means all netboot servers involved must use the same mechanism.
If this is not defined, it relies on the netboot location URL ending
in "/files" - see NetBootHelper.getDefaultListUrl()
* URLDeploymentScanner can't handle dynamic lists off the network -
HttpUrlDeploymentScanner must be used instead. This means
conf/jboss-service.xml must be modified for netboot (not a big deal
but it would be nice if configuring netboot was transparent)
And, in general, only file: and http: protocols are supported (not https:
even); adding others is not pluggable.
Jeremy
> - Original Message -
> From: "Jeremy Boynes" <[EMAIL PROTECTED]>
> To: "Jboss-Development" <[EMAIL PROTECTED]>
> Sent: Saturday, December 07, 2002 10:36 AM
> Subject: [JBoss-dev] Proposal for changes to URL deployment to
> clean up netboot
>
>
> > Wanted to get feedback before starting to implement...
> >
> > The current support for loading deployment units has several
> special
[JBoss-dev] Proposal for changes to URL deployment to clean up netboot
Wanted to get feedback before starting to implement... The current support for loading deployment units has several special cases to deal with loading from the network e.g. in SARDeployer.parseXMLClasspath(), NetBootHelper.getDefaultListUrl() or even HttpURLDeploymentScanner itself. I would like to make changes to simplify this and at the same time offer additional flexibility. The main change would be to factor out the URL listing functionality into helpers with a factory to create them based on the scheme. Examples would be: * file: using java.io.File as now * http(s): using DAV * http: using the current listing mechanisms (if still applicable) others could be added as needed (e.g ftp:) The DAV client would allow JBoss to be netbooted from any web server supporting DAV, either directly (e.g. Tomcat 4.1, Apache+mod_dav or even IIS) or via a helper servlet (which could read either the content of its war or config of its host). This change would isolate the SARDeployer and the URLDeploymentScanner's from the different URL schemes and remove the special cases. --- 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
[JBoss-dev] What is the status of hsqldb 1.7 in JBoss 3.2?
I'm trying to get PetStore 1.3.1 running with 3.2 but its DAO code uses ResultSet.absolute() which is not supported by hsqldb 1.6 but is by 1.7.1 Will the changes to support 1.7.1 be backported to 3.2 before its release? thanks jeremy --- This SF.net email is sponsored by: Get the new Palm Tungsten T handheld. Power & Color in a compact size! http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0002en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] TODO: NetBoot PetStore
I'll give it a shot if you can't find someone who has done the PetStore before - I'd be taking the intermediate route. I'm assuming most of the effort here is deploying it to JBoss and configuring the necessary resources. Jeremy > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]]On Behalf Of Jason > Dillon > Sent: Thursday, November 21, 2002 1:57 AM > To: [EMAIL PROTECTED] > Subject: [JBoss-dev] TODO: NetBoot PetStore > > > Anyone want to make a NetBoot configuration which runs the latest > PetStore from SUN? I have been meaning to do this for awhile, but > never seem to find the time. This is a simple task for someone who has > setup the PetStore in JBoss 3.x before, or an intermediate task for > someone who is looking to help us out. > > Let me know. I want to get this function soon, as it is a powerful > example of how NetBoot works and allows users to see how JBoss works in > a semi-real world situation. > > So, anyone want to take a shot? I can advise as needed... but please > not smart asses. If you would like to help great I do not need more > stress yo! > > Let me know, a RW could be in it for ya ;) > > --jason > > > > --- > 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] CMP on JBoss
Please, share the vision. I would like to contribute here but don't know where to start as it seems everything might be changing. Jeremy -Original Message- From: [EMAIL PROTECTED] [mailto:jboss-development-admin@;lists.sourceforge.net]On Behalf Of marc fleury Sent: Thursday, November 14, 2002 12:28 PM To: 'Dain Sundstrom' Cc: Jboss-Development@Lists. Sourceforge. Net Subject: [JBoss-dev] CMP on JBoss please dain, take the new development of the CMP on JBoss online. If there is a rewrite, put it online, share the docs for the design, let us know how you want the site to look and feel and we will do it. Explore new grounds of collaborative development marc f xx Marc Fleury, Ph.D. President, Founder JBoss Group, LLC xx --- This sf.net email is sponsored by: To learn the basics of securing your web site with SSL, click here to get a FREE TRIAL of a Thawte Server Certificate: http://www.gothawte.com/rd524.html ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This sf.net email is sponsored by: To learn the basics of securing your web site with SSL, click here to get a FREE TRIAL of a Thawte Server Certificate: http://www.gothawte.com/rd524.html ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] RE: [ jboss-Bugs-619969 ] SQL Server substring syntax is wrong -reference found
SQL Server reference on MSDN shows "SUBSTRING ( expression , start , length )" syntax: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/tsqlref/ts_ setu-sus_6btz.asp I can verify this if it would help. -Original Message- From: [EMAIL PROTECTED] [mailto:jboss-development-admin@;lists.sourceforge.net]On Behalf Of [EMAIL PROTECTED] Sent: Wednesday, October 30, 2002 11:03 PM To: [EMAIL PROTECTED] Subject: [JBoss-dev] [ jboss-Bugs-619969 ] SQL Server substring syntax is wrong Bugs item #619969, was opened at 2002-10-08 08:15 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=619969&group_id =22866 Category: JBossCMP Group: v3.0 Rabbit Hole Status: Open Resolution: None Priority: 5 Submitted By: Vinh Nguyen (softwaremasters) Assigned to: Nobody/Anonymous (nobody) Summary: SQL Server substring syntax is wrong Initial Comment: The function mapping for substring for SQL Server (both 7 and 2K) in standardjbosscmp-jdbc.xml is currently: substring(?1 FROM ?2 FOR ?3) This is incorrect. The correct syntax for the substring function is: substring(?1, ?2, ?3) -- Comment By: Stephen Coy (scoy) Date: 2002-10-31 18:02 Message: Logged In: YES user_id=463096 My reference "SQL in a Nutshell" (O'Reilly) says otherwise. Can you provide some other documentary evidence of this? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=619969&group_id =22866 --- This sf.net email is sponsored by: Influence the future of Java(TM) technology. Join the Java Community Process(SM) (JCP(SM)) program now. http://ads.sourceforge.net/cgi-bin/redirect.pl?sunm0004en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This sf.net email is sponsored by: Influence the future of Java(TM) technology. Join the Java Community Process(SM) (JCP(SM)) program now. http://ads.sourceforge.net/cgi-bin/redirect.pl?sunm0004en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Oracle, table locks and CMP2 incompatibility
danch wrote: Even ignoring the table-lock escalation issue, this is what should happen. In fact, I'm a little surprised that Oracle doesn't just create the indices: I believe PostgreSQL does. I believe it's because they want to allow a DBA to configure the index in a specific way e.g. in a specific tablespace, with additional columns for index-only joins, as part of the PK (leading to CMR problems :-( ), and so on. I don't think MS-SQL creates an index either (although it's self-tuning mechanism may add one later). --- 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
