Re: [JBoss-dev] Developing with JBoss
This makes alot of sence, would it be hard to augment the deployer in such a fashion as to make the window smaller? --jason > What I would really like, is to see that a redeploy needs to happen, and have > the new file extracted into a new directory first, THEN have the old version > undeployed, then have the new one deployed, then have the old one deleted. > > The current way things are done, there is a big window open while the > undeployment and redeployment is happening. ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jbossmq/src/main/org/jboss/mq/il/uil UILServerIL.java
User: chirino
Date: 01/11/21 23:11:12
Modified:src/main/org/jboss/mq/il/uil UILServerIL.java
Log:
fixed a bug that was showing up in the testsuite. Exception being thrown at
connection close()
Revision ChangesPath
1.5 +8 -4 jbossmq/src/main/org/jboss/mq/il/uil/UILServerIL.java
Index: UILServerIL.java
===
RCS file: /cvsroot/jboss/jbossmq/src/main/org/jboss/mq/il/uil/UILServerIL.java,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -r1.4 -r1.5
--- UILServerIL.java 2001/09/27 04:09:36 1.4
+++ UILServerIL.java 2001/11/22 07:11:12 1.5
@@ -37,7 +37,7 @@
*
* @authorHiram Chirino ([EMAIL PROTECTED])
* @authorNorbert Lataille ([EMAIL PROTECTED])
- * @version $Revision: 1.4 $
+ * @version $Revision: 1.5 $
* @created August 16, 2001
*/
public class UILServerIL implements java.io.Serializable, Cloneable,
org.jboss.mq.il.ServerIL
@@ -501,9 +501,13 @@
protected void destroyConnection()
throws Exception
{
- out.close();
- in.close();
- // The scoket is closed by the ClientIL
+ // This may fail as the other (muxed) stream may close the socket
+ // before we get to close out.
+ try {
+ in.close();
+ out.close();
+ // The socket is closed by the clientILService
+ } catch ( java.io.IOException ignore ) {}
}
/**
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Automated JBoss Testsuite Results
JBoss daily test results SUMMARY Number of tests run: 177 Successful tests: 142 Errors:23 Failures: 12 [time of test: 22 November 2001 6:21 GMT] [java.version: 1.3.1] [java.vendor: Sun Microsystems Inc.] [java.vm.version: 1.3.1-b24] [java.vm.name: Java HotSpot(TM) Server VM] [java.vm.info: mixed mode] [os.name: Linux] [os.arch: i386] [os.version: 2.4.9-12] See http://lubega.com for full details NOTE: If there are any errors shown above - this mail is only highlighting them - it is NOT indicating that they are being looked at by anyone. It is assumed that whoever makes change(s) to jboss that break the test will be fixing the test or jboss, as appropriate! DETAILS OF ERRORS [details not shown - as this makes the mail too big to reach the sf mailing list] PS BEFORE you commit, run the test suite. Its easy, just run the target 'run-basic-testsuite' from the main build.xml. PPS Come on people - there were a few days back in July 2001 when we had ZERO tests failing! Oh, and thanks - remember we love you too! ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] JMX FAQ @ jGuru.com
Hi Geeks Whenever you have a question about JMX which goes beyond JBoss you can go to: http://www.jguru.com/faq/JMX Have fun x Andreas Schaefer Senior Consultant JBoss Group, LLC x ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Automated JBoss Testsuite Results
JBoss daily test results SUMMARY Number of tests run: 162 Successful tests: 129 Errors:21 Failures: 12 [time of test: 22 November 2001 5:21 GMT] [java.version: 1.3.1] [java.vendor: Blackdown Java-Linux Team] [java.vm.version: Blackdown-1.3.1-FCS] [java.vm.name: Classic VM] [java.vm.info: green threads, nojit] [os.name: Linux] [os.arch: i386] [os.version: 2.4.9-12] See http://lubega.com for full details NOTE: If there are any errors shown above - this mail is only highlighting them - it is NOT indicating that they are being looked at by anyone. It is assumed that whoever makes change(s) to jboss that break the test will be fixing the test or jboss, as appropriate! DETAILS OF ERRORS [details not shown - as this makes the mail too big to reach the sf mailing list] PS BEFORE you commit, run the test suite. Its easy, just run the target 'run-basic-testsuite' from the main build.xml. PPS Come on people - there were a few days back in July 2001 when we had ZERO tests failing! Oh, and thanks - remember we love you too! ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: newsite/src/docs main.css
User: user57
Date: 01/11/21 21:22:28
Modified:src/docs main.css
Log:
o removed small-caps from headings
Revision ChangesPath
1.11 +1 -8 newsite/src/docs/main.css
Index: main.css
===
RCS file: /cvsroot/jboss/newsite/src/docs/main.css,v
retrieving revision 1.10
retrieving revision 1.11
diff -u -r1.10 -r1.11
--- main.css 2001/11/21 21:47:32 1.10
+++ main.css 2001/11/22 05:22:28 1.11
@@ -2,7 +2,7 @@
* CSS Style Sheet for the JBoss website.
*/
-/* $Id: main.css,v 1.10 2001/11/21 21:47:32 user57 Exp $ */
+/* $Id: main.css,v 1.11 2001/11/22 05:22:28 user57 Exp $ */
BODY {
font-family: Arial,serif;
@@ -31,8 +31,6 @@
color: #336633;
clear: both;
font-weight: bold;
- font-variant: small-caps;
- letter-spacing: 0.05em;
}
H1 {
@@ -55,15 +53,12 @@
padding-top: 5px;
font-size: 1.0em;
font-weight: normal;
- letter-spacing: normal;
}
H6 {
padding-top: 5px;
font-size: 1.0em;
- font-variant: normal;
font-weight: normal;
- letter-spacing: normal;
}
.linkhead, .linkmenu {
@@ -91,8 +86,6 @@
.slogan {
font-size: 15px;
font-weight: bold;
- font-variant: small-caps;
- letter-spacing: 0.05em;
color: #338833;
}
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [jetty-discuss] Re: [JBoss-dev] JBoss3/Jetty4, Greg/Scott - Optimised intra-container calls & ClassLoaders
|RH is the next release of JBoss ("Rabbit Hole"?) and it will include a
|classloader that supports scopes.
yes,
the scopes are already there
|I gather that scopes are a way to control class loading that is not
|directly related to the parent hierarchy of classloaders (inverted or
|otherwise).
it is a way to define a scope of visibility for classes among classloaders
related to the same scope. By default all classes are visible in the default
scope.
|Jetty/JBoss should ignore the 2.3 spec recommendation to invert the
|classloading priorities and always delegate to the JBoss classloader.
yes
|If a developer wants to replace things such as JAXP, they will be able
|to do so via the JBoss scope mechanism. This can be done simply by
yes, hence achieving the same result as what the cl stuff intends.
If you want to "not delegate" then we can use the RH classloaders in Jetty
natively.
|the Jetty JBoss module changing the compliance mode of the Jetty
|ContextLoader.
ok
|Note that standalone Jetty4 will continue to support the 2.3
|recommendation by default for now. We can review this before Jetty4
|goes stable.
ok
marcf
|
|cheers
|
|
|
|
|--
|Greg Wilkins<[EMAIL PROTECTED]> GB Phone: +44-(0)7092063462
|Mort Bay Consulting Australia and UK.Mbl Phone: +61-(0)4 17786631
|http://www.mortbay.com AU Phone: +61-(0)2 98107029
|
|
|___
|Jboss-development mailing list
|[EMAIL PROTECTED]
|https://lists.sourceforge.net/lists/listinfo/jboss-development
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Re: [jboss-docs] Is the build system too complicated?
On Wed, 21 Nov 2001, Dain Sundstrom wrote: > > java really pisses me off sometimes. why can't you get file > > perms from a > > given platform? all of this platform independence has really > > dumbed down > > the file access apis, too much in my oppinon. > > I think you can with 1.4 That would be nice. I will have to look over the changes again. > > > > it appears that there is noway with the vanilla jdk to check > > if a file is > > executable... which is really *ucking stupid if you ask me... > > but since you > > didn't well I am telling you anyways. Afterall who would > > want to execute a > > file from Java? Whatever, where do they find the people that > > design this > > crap. > > > > Doesn't ant have a chmod task. It does, but it is dependent on executing the `chmod` program. We use it to setup the perms for scripts in the output directory. Chmod in this case won't help since once we tar (or zip) up the directory those bits will be lost. --jason ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Classloader puzzle
|It sure looks like the system (Service libraries) rather than application |classloader is being used, despite your code that clearly sets the |contextClassLoader to the container's. And some people wonder why I loved having Rickard Oberg on the project back in EJBoss 0.9 attached is a ObjectinputStreamWithClassLoader that rickard and monson haefel put together one night when I ran into the same problem you did Francisco :) Rickard Oberg was a fucking genius make no mistakes about it ... Francisco to use this you want to create the ObjectInputStream with this puppy and pass the context cl as the parameter to the constructor. Then call readObject as you did. BTw don't commit this, MarshalledObject operates pretty much the same way. marcf | |Have you checked that poaCurrent doesn't change the context classloader and |the classloader is really what you expect when you call toObject? | |david jencks | | |On 2001.11.21 13:04:25 -0500 Francisco Reverbel wrote: |> Hi, |> |> I have a classloader problem in the IIOP container invoker code and would |> really appreciate some helpful hints... Classloader wizards: to |> understand |> the problem you do not have to know anything about CORBA/IIOP, so please |> read on! |> |> The problem only shows up with entity beans. When the IIOP container |> invoker creates a CORBA reference for such a bean, it embeds the bean´s |> primary key into the CORBA reference. When handling a bean invocation, |> the |> container invoker extracts the PK from the CORBA reference and passes |> this |> PK to the container as the first argument of a MethodInvocation. |> |> A ClassNotFoundException is thrown when the container invoker attempts to |> extract the PK from the CORBA reference (got the stack trace below |> running |> RMH's well-known cabin bean): |> |> java.lang.ClassNotFoundException: com.titan.cabin.CabinPK |> at |org.jboss.system.ServiceLibraries.loadClass(ServiceLibraries.java:372) |> at |org.jboss.system.URLClassLoader.loadClass(URLClassLoader.java:111) |> at java.lang.ClassLoader.loadClass(ClassLoader.java:253) |> at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:313) |> at java.lang.Class.forName0(Native Method) |> at java.lang.Class.forName(Class.java:195) |> at |java.io.ObjectInputStream.resolveClass(ObjectInputStream.java:654) |> at |java.io.ObjectInputStream.inputClassDescriptor(ObjectInputStream.java:918) |> at java.io.ObjectInputStream.readObject(ObjectInputStream.java:366) |> at java.io.ObjectInputStream.readObject(ObjectInputStream.java:236) |> at |java.io.ObjectInputStream.inputObject(ObjectInputStream.java:1186) |> at java.io.ObjectInputStream.readObject(ObjectInputStream.java:386) |> at java.io.ObjectInputStream.readObject(ObjectInputStream.java:236) |> at org.jboss.ejb.CacheKey.readExternal(CacheKey.java:118) |> at |java.io.ObjectInputStream.inputObject(ObjectInputStream.java:1212) |> at java.io.ObjectInputStream.readObject(ObjectInputStream.java:386) |> at java.io.ObjectInputStream.readObject(ObjectInputStream.java:236) |> at |org.jboss.ejb.plugins.iiop.server.IIOPContainerInvoker.toObject(IIO |PContainerInvoker.java:896) |> at |org.jboss.ejb.plugins.iiop.server.IIOPContainerInvoker._invoke(IIOP |ContainerInvoker.java:665) |> at |org.jacorb.poa.RequestProcessor.invokeOperation(RequestProcessor.java:239) |> at |org.jacorb.poa.RequestProcessor.process(RequestProcessor.java:456) |> at org.jacorb.poa.RequestProcessor.run(RequestProcessor.java:581) |> |> I've found a way of circumventing the problem, but am not satisfied with |> it. Things work if I wrap the PK into a MarshalledObject before embedding |> it into the CORBA reference, and do the opposite thing when extracting |> the |> PK from the reference. Runs fine, but is very slow... The bank test takes |> forever to run. |> |> This code is in org.jboss.ejb.plugins.iiop.server.IIOPContainerInvoker, |> under contrib/iiop. Insertion/extraction of the PK is done through the |> methods toByteArray() and toObject(). Each of these methods has two |> implementations, one of them commented out. The commented out |> implementation "solves" the problem in the way described above. |> |> Suggestions are very welcome! |> |> Cheers, |> |> Francisco |> |> |> |> |> |> |> |> |> ___ |> Jboss-development mailing list |> [EMAIL PROTECTED] |> https://lists.sourceforge.net/lists/listinfo/jboss-development |> |> | |___ |Jboss-development mailing list |[EMAIL PROTECTED] |https://lists.sourceforge.net/lists/listinfo/jboss-development ObjectInputStreamWithClassLoader.java Description: Binary data
Re: [jetty-discuss] Re: [JBoss-dev] JBoss3/Jetty4, Greg/Scott - Optimised intra-container calls & ClassLoaders
So just to clarify all this...
RH is the next release of JBoss ("Rabbit Hole"?) and it will include a
classloader that supports scopes.
I gather that scopes are a way to control class loading that is not
directly related to the parent hierarchy of classloaders (inverted or
otherwise).
Jetty/JBoss should ignore the 2.3 spec recommendation to invert the
classloading priorities and always delegate to the JBoss classloader.
If a developer wants to replace things such as JAXP, they will be able
to do so via the JBoss scope mechanism. This can be done simply by
the Jetty JBoss module changing the compliance mode of the Jetty
ContextLoader.
Note that standalone Jetty4 will continue to support the 2.3
recommendation by default for now. We can review this before Jetty4
goes stable.
cheers
--
Greg Wilkins<[EMAIL PROTECTED]> GB Phone: +44-(0)7092063462
Mort Bay Consulting Australia and UK.Mbl Phone: +61-(0)4 17786631
http://www.mortbay.com AU Phone: +61-(0)2 98107029
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Classloader puzzle
> |> This code is in org.jboss.ejb.plugins.iiop.server.IIOPContainerInvoker, |> under contrib/iiop. Insertion/extraction of the PK is done through the |> methods toByteArray() and toObject(). Each of these methods has two professor, rereading this, if you set the context classloader correctly then the MarshalledObject works from these guys hence no problem. the toByteArray() and toObject() needs to work with the context class loader. So 1- make sure the context cl is set properly (system.out its hash when you enter the method), make sure it is the hash of the cl that created the container (compare to the cl printouts) 2- make sure your code uses the context cl when deserializing, it seems that the cl that is asked for the application is the system cl and that indicates that the io deserialization is asking the cl that loaded the system class (the container invoker in this case). marcf |> implementations, one of them commented out. The commented out |> implementation "solves" the problem in the way described above. |> |> Suggestions are very welcome! |> |> Cheers, |> |> Francisco |> |> |> |> |> |> |> |> |> ___ |> Jboss-development mailing list |> [EMAIL PROTECTED] |> https://lists.sourceforge.net/lists/listinfo/jboss-development |> |> | |___ |Jboss-development mailing list |[EMAIL PROTECTED] |https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Classloader puzzle
|> This is RH CL working on Service libraries, when we integrate |the CL and SCL |> this will go away (or so we hope) | |Hope it will go away, but am not that sure... actually it won't, I was all excited and got carried away on RH Cl integrated structure will solve world hunger. btw I really recommend using the MarshalledObject, it is a simple encapsulation of the cl working properly. marcf | |This problem is around since I started doing the IIOP stuff. |It (and the MarshalledObject workaround) precedes RH. | |Regards, | |Francisco | |> |> really let me finish the proxy rewrite and then I will move onto |packaging |> |> marcf |> |at |> |org.jboss.system.URLClassLoader.loadClass(URLClassLoader.java:111) |> |at java.lang.ClassLoader.loadClass(ClassLoader.java:253) |> |at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:313) |> |at java.lang.Class.forName0(Native Method) |> |at java.lang.Class.forName(Class.java:195) |> |at |> |java.io.ObjectInputStream.resolveClass(ObjectInputStream.java:654) |> |at |> ||java.io.ObjectInputStream.inputClassDescriptor(ObjectInputStream.java:918) |> |at java.io.ObjectInputStream.readObject(ObjectInputStream.java:366) |> |at java.io.ObjectInputStream.readObject(ObjectInputStream.java:236) |> |at |> |java.io.ObjectInputStream.inputObject(ObjectInputStream.java:1186) |> |at java.io.ObjectInputStream.readObject(ObjectInputStream.java:386) |> |at java.io.ObjectInputStream.readObject(ObjectInputStream.java:236) |> |at org.jboss.ejb.CacheKey.readExternal(CacheKey.java:118) |> |at |> |java.io.ObjectInputStream.inputObject(ObjectInputStream.java:1212) |> |at java.io.ObjectInputStream.readObject(ObjectInputStream.java:386) |> |at java.io.ObjectInputStream.readObject(ObjectInputStream.java:236) |> |at |> |org.jboss.ejb.plugins.iiop.server.IIOPContainerInvoker.toObject(IIO |> |PContainerInvoker.java:896) |> |at |> |org.jboss.ejb.plugins.iiop.server.IIOPContainerInvoker._invoke(IIOP |> |ContainerInvoker.java:665) |> |at |> ||org.jacorb.poa.RequestProcessor.invokeOperation(RequestProcessor.java:239) |> |at |> |org.jacorb.poa.RequestProcessor.process(RequestProcessor.java:456) |> |at org.jacorb.poa.RequestProcessor.run(RequestProcessor.java:581) |> | |> |I've found a way of circumventing the problem, but am not satisfied with |> |it. Things work if I wrap the PK into a MarshalledObject before |embedding |> |it into the CORBA reference, and do the opposite thing when |extracting the |> |PK from the reference. Runs fine, but is very slow... The bank |test takes |> |forever to run. |> | |> |This code is in org.jboss.ejb.plugins.iiop.server.IIOPContainerInvoker, |> |under contrib/iiop. Insertion/extraction of the PK is done through the |> |methods toByteArray() and toObject(). Each of these methods has two |> |implementations, one of them commented out. The commented out |> |implementation "solves" the problem in the way described above. |> | |> |Suggestions are very welcome! |> | |> |Cheers, |> | |> |Francisco |> | |> | |> | |> | |> | |> | |> | |> | |> |___ |> |Jboss-development mailing list |> |[EMAIL PROTECTED] |> |https://lists.sourceforge.net/lists/listinfo/jboss-development |> |> |> ___ |> Jboss-development mailing list |> [EMAIL PROTECTED] |> https://lists.sourceforge.net/lists/listinfo/jboss-development |> | ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Classloader puzzle
BTW what is wrong with "MarshalledObject" it is just a ByteArray with proper CL behaviour, you are going to end up rewriting this class as I read it. marcf |-Original Message- |From: marc fleury [mailto:[EMAIL PROTECTED]] |Sent: Wednesday, November 21, 2001 11:05 PM |To: David Jencks; [EMAIL PROTECTED] |Subject: RE: [JBoss-dev] Classloader puzzle | | |> ||> This code is in org.jboss.ejb.plugins.iiop.server.IIOPContainerInvoker, ||> under contrib/iiop. Insertion/extraction of the PK is done through the ||> methods toByteArray() and toObject(). Each of these methods has two | |professor, | |rereading this, if you set the context classloader correctly then |the MarshalledObject works from these guys hence no problem. the |toByteArray() and toObject() needs to work with the context class loader. | |So |1- make sure the context cl is set properly (system.out its hash |when you enter the method), make sure it is the hash of the cl |that created the container (compare to the cl printouts) | |2- make sure your code uses the context cl when deserializing, it |seems that the cl that is asked for the application is the system |cl and that indicates that the io deserialization is asking the cl |that loaded the system class (the container invoker in this case). | |marcf | ||> implementations, one of them commented out. The commented out ||> implementation "solves" the problem in the way described above. ||> ||> Suggestions are very welcome! ||> ||> Cheers, ||> ||> Francisco ||> ||> ||> ||> ||> ||> ||> ||> ||> ___ ||> Jboss-development mailing list ||> [EMAIL PROTECTED] ||> https://lists.sourceforge.net/lists/listinfo/jboss-development ||> ||> || ||___ ||Jboss-development mailing list ||[EMAIL PROTECTED] ||https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Automated JBoss Testsuite Results
JBoss daily test results SUMMARY Number of tests run: 177 Successful tests: 142 Errors:23 Failures: 12 [time of test: 22 November 2001 3:58 GMT] [java.version: 1.3.1] [java.vendor: Blackdown Java-Linux Team] [java.vm.version: Blackdown-1.3.1-FCS] [java.vm.name: Java HotSpot(TM) Client VM] [java.vm.info: mixed mode] [os.name: Linux] [os.arch: i386] [os.version: 2.4.9-12] See http://lubega.com for full details NOTE: If there are any errors shown above - this mail is only highlighting them - it is NOT indicating that they are being looked at by anyone. It is assumed that whoever makes change(s) to jboss that break the test will be fixing the test or jboss, as appropriate! DETAILS OF ERRORS [details not shown - as this makes the mail too big to reach the sf mailing list] PS BEFORE you commit, run the test suite. Its easy, just run the target 'run-basic-testsuite' from the main build.xml. PPS Come on people - there were a few days back in July 2001 when we had ZERO tests failing! Oh, and thanks - remember we love you too! ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Automated JBoss Testsuite Results
JBoss daily test results SUMMARY Number of tests run: 177 Successful tests: 140 Errors:24 Failures: 13 [time of test: 22 November 2001 3:12 GMT] [java.version: 1.3.0] [java.vendor: IBM Corporation] [java.vm.version: 1.3.0] [java.vm.name: Classic VM] [java.vm.info: J2RE 1.3.0 IBM build cx130-20010626 (JIT enabled: jitc)] [os.name: Linux] [os.arch: x86] [os.version: 2.4.9-12] See http://lubega.com for full details NOTE: If there are any errors shown above - this mail is only highlighting them - it is NOT indicating that they are being looked at by anyone. It is assumed that whoever makes change(s) to jboss that break the test will be fixing the test or jboss, as appropriate! DETAILS OF ERRORS [details not shown - as this makes the mail too big to reach the sf mailing list] PS BEFORE you commit, run the test suite. Its easy, just run the target 'run-basic-testsuite' from the main build.xml. PPS Come on people - there were a few days back in July 2001 when we had ZERO tests failing! Oh, and thanks - remember we love you too! ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Re: [jboss-docs] Is the build system too complicated?
> java really pisses me off sometimes. why can't you get file
> perms from a
> given platform? all of this platform independence has really
> dumbed down
> the file access apis, too much in my oppinon.
I think you can with 1.4
>
> it appears that there is noway with the vanilla jdk to check
> if a file is
> executable... which is really *ucking stupid if you ask me...
> but since you
> didn't well I am telling you anyways. Afterall who would
> want to execute a
> file from Java? Whatever, where do they find the people that
> design this
> crap.
>
Doesn't ant have a chmod task.
>
> Anyways, I have HACKED the build file to make all 'build.sh' and
> 'tools/bin/ant[Run]' files executable. I don't really like
> it, but don't
> have much choice. Thanks SUN!
>
> * * *
>
> Let me know if this fixes your problem, should be ready early
> tomorrow
> morning on the website.
>
> --jason
>
>
> On Wed, 21 Nov 2001 [EMAIL PROTECTED] wrote:
>
> > Unfortunately, my firewall currently doesn't let me check
> out via cvs
> > directly unless it's over ssh, and I don't have RW access to the
> > repository (yet :) -- I've been downloading the nightly
> snapshots (ugh)
> > in .tgz form from http://www.jboss.org/snapshots/. When I
> untar that, the
> > executable bit is not set.(using gnu tar and gzip on
> linux with the
> > command 'tar -xzvf jboss-all.tgz`) Actually, from a few
> spot checks, it
> > looks as if everything comes out '-rw-r--r--', including
> build.sh itself.
> > Yes, I've tried using the -p option with tar to extract permissions
> > information -- no effect (I think that's the default
> anyway, though I'm
> > not sure)
> >
> > -jason
> >
> >
> >
> >
> >
> >
> > Jason Dillon <[EMAIL PROTECTED]>
> > 11/21/2001 02:09 PM
> >
> >
> > To: [EMAIL PROTECTED]
> > cc: [EMAIL PROTECTED]
> > Subject:Re: [JBoss-dev] Re: [jboss-docs] Is
> the build system too complicated?
> >
> >
> >
> > The executable bit is set on tools/bin/ant. Why dosen't
> your cvs client
> > set
> > it when you check it out?
> >
> > --jason
> >
> >
> > On Wed, 21 Nov 2001 [EMAIL PROTECTED] wrote:
> >
> > > I do have a slightly off-topic gripe -- as of late, (in the rh
> > snapshots),
> > > jboss-all/tools/bin/ant has not been executable on UNIX
> systems (took my
> >
> > > little mind a while to figure out what was going on). The
> > > jboss-all/build/build.sh script has been failing because
> of it. It
> > looks
> > > for an executable 'ant', but never finds it (it doesn't have the
> > > executable bit set). I can see three possible solutions:
> > >
> > > 1. Just have the executable bit set on the ant script to
> start with
> > > 2. Change the search() function in build.sh to read like this:
> > >
> > > search() {
> > > search="$*"
> > > for d in $search; do
> > > ANT_HOME="`pwd`/$d"
> > > ANT="$ANT_HOME/bin/ant"
> > > # -- Begin modifications
> > > # If the file exists at all, attempt to add the
> executable bit
> > > if [ -e "$ANT" ]; then
> > > `chmod +x $ANT`
> > > fi
> > > # -- End modifications
> > > if [ -x "$ANT" ]; then
> > > # found one
> > > echo $ANT_HOME
> > > break
> > > fi
> > > done
> > > }
> > > #(just added a -e test to see if the file exists, and
> attempt to make it
> >
> > > executable so that the next -x test works)
> > >
> > > 3. Skip looking for an executable ant script -- just make sure it
> > exists,
> > > and call it with 'sh ant'.
> > >
> > > -jason
> > >
> > >
> > >
> > >
> > >
> > > Jason Dillon <[EMAIL PROTECTED]>
> > > Sent by: [EMAIL PROTECTED]
> > > 11/20/2001 09:38 PM
> > >
> > >
> > > To: [EMAIL PROTECTED]
> > > cc: [EMAIL PROTECTED]
> > > Subject:[JBoss-dev] Re: [jboss-docs] Is
> the build system
> > too complicated?
> > >
> > >
> > >
> > > I have not found an easy way to provide this common
> setup/initialization
> >
> > > stuff as a resource. Perhaps if I could tell the JAXP
> parser to read a
> > > resource file when parsing this could be done, but that
> would require
> > the
> > > Ant entity hooks to be installed to handle that.
> > >
> > > Perhaps they have done that, perhaps I could sway them
> todo it... though
> >
> > > my
> > > previous attempts to do so has failed (too much *ucking voting).
> > >
> > > If you can think of a way please let me know.
> > >
> > > Thanks for your feedback!
> > >
> > > --jason
> > >
> > >
> > > On Tue, 20 Nov 2001, David Jencks wrote:
> > >
> > > > It has often seemed to me that there is substantial duplication
> > between
> > > the
> > > > setup parts of the module level build.xml files. I
> sure haven't
> > figured
> > > > out a clue of a way to reduce this, but if it could be
> done, it might
[JBoss-dev] figured out how to reduce build system files
had to write a system resource protocol handler (since the sun version systemresource:// is dumb as a nail). i want to see if I can restructure the build file layout to make more use of this before I commit anything. you can look forward to smaller build files soon, not all that smaller, but smaller still =) --jason ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] RH: TestSuite hangs - deadlock in ClassLoader.loadClass() ???
This is a full stack dump of a reproducible hang-up in the WebIntegration test-suite with Jetty4. Note the two threads which seem to be waiting on the same line of code at java.lang.ClassLoader.loadClass(ClassLoader.java:286) This looks like a deadlock to me - has anyone else had a similar problem ? Do any of those org.jboss.system folks have any ideas - or do I put on my debugging hat ? Jules Full thread dump: "Thread-22" daemon prio=1 tid=0x8117c90 nid=0x1712 waiting on monitor [0xbc7ff000..0xbc7ff8b0] at java.lang.Object.wait(Native Method) at java.util.TimerThread.mainLoop(Timer.java:432) at java.util.TimerThread.run(Timer.java:385) "Connection Monitor Thread" daemon prio=1 tid=0x81734e8 nid=0x1710 waiting on monitor [0xb95ff000..0xb95ff8b0] at java.lang.Object.wait(Native Method) at java.lang.Object.wait(Object.java:420) at EDU.oswego.cs.dl.util.concurrent.ClockDaemon.nextTask(ClockDaemon.java:321) at EDU.oswego.cs.dl.util.concurrent.ClockDaemon$RunLoop.run(ClockDaemon.java:362) at java.lang.Thread.run(Thread.java:484) "OIL Worker" prio=1 tid=0x8249aa8 nid=0x170e runnable [0xb99ff000..0xb99ff8b0] at java.net.PlainSocketImpl.socketAccept(Native Method) at java.net.PlainSocketImpl.accept(PlainSocketImpl.java:421) at java.net.ServerSocket.implAccept(ServerSocket.java:243) at java.net.ServerSocket.accept(ServerSocket.java:222) at org.jboss.mq.il.oil.OILServerILService.run(OILServerILService.java:149) at java.lang.Thread.run(Thread.java:484) "RMI RenewClean-[127.0.0.1:]" daemon prio=1 tid=0x842b630 nid=0x170b waiting on monitor [0xba7ff000..0xba7ff8b0] at java.lang.Object.wait(Native Method) at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:108) at sun.rmi.transport.DGCClient$EndpointEntry$RenewCleanThread.run(DGCClient.java:495) at java.lang.Thread.run(Thread.java:484) "Thread-21" daemon prio=1 tid=0x8389ec0 nid=0x1706 waiting on monitor [0xba9ff000..0xba9ff8b0] at java.lang.Object.wait(Native Method) at org.jboss.util.timeout.TimeoutFactory.doWork(TimeoutFactory.java:503) at org.jboss.util.timeout.TimeoutFactory.access$400(TimeoutFactory.java:27) at org.jboss.util.timeout.TimeoutFactory$1.run(TimeoutFactory.java:542) "SessionScavenger" daemon prio=1 tid=0x859ff90 nid=0x1701 waiting on monitor [0xbabff000..0xbabff8b0] at java.lang.Thread.sleep(Native Method) at org.mortbay.jetty.servlet.HashSessionManager$SessionScavenger.run(HashSessionManager.java:233) "Passivator Thread for BMPCallbackBean" daemon prio=1 tid=0x832bc38 nid=0x16ff waiting on monitor [0xbadff000..0xbadff8b0] at java.lang.Object.wait(Native Method) at java.lang.Object.wait(Object.java:420) at org.jboss.util.WorkerQueue.getJobImpl(WorkerQueue.java:122) at org.jboss.util.WorkerQueue.getJob(WorkerQueue.java:111) at org.jboss.util.WorkerQueue$QueueLoop.run(WorkerQueue.java:199) at java.lang.Thread.run(Thread.java:484) "Passivator Thread for StatefulSessionBean" daemon prio=1 tid=0x84cd050 nid=0x16fe waiting on monitor [0xbafff000..0xbafff8b0] at java.lang.Object.wait(Native Method) at java.lang.Object.wait(Object.java:420) at org.jboss.util.WorkerQueue.getJobImpl(WorkerQueue.java:122) at org.jboss.util.WorkerQueue.getJob(WorkerQueue.java:111) at org.jboss.util.WorkerQueue$QueueLoop.run(WorkerQueue.java:199) at java.lang.Thread.run(Thread.java:484) "Passivator Thread for BMPBean" daemon prio=1 tid=0x876aff0 nid=0x16fd waiting on monitor [0xbb1ff000..0xbb1ff8b0] at java.lang.Object.wait(Native Method) at java.lang.Object.wait(Object.java:420) at org.jboss.util.WorkerQueue.getJobImpl(WorkerQueue.java:122) at org.jboss.util.WorkerQueue.getJob(WorkerQueue.java:111) at org.jboss.util.WorkerQueue$QueueLoop.run(WorkerQueue.java:199) at java.lang.Thread.run(Thread.java:484) "Passivator Thread for CMPBean" daemon prio=1 tid=0x84cdce0 nid=0x16fc waiting on monitor [0xbb3ff000..0xbb3ff8b0] at java.lang.Object.wait(Native Method) at java.lang.Object.wait(Object.java:420) at org.jboss.util.WorkerQueue.getJobImpl(WorkerQueue.java:122) at org.jboss.util.WorkerQueue.getJob(WorkerQueue.java:111) at org.jboss.util.WorkerQueue$QueueLoop.run(WorkerQueue.java:199) at java.lang.Thread.run(Thread.java:484) "TimerTask Thread" daemon prio=1 tid=0x87b2e68 nid=0x16fb waiting on monitor [0xbb7ff000..0xbb7ff8b0] at java.lang.Object.wait(Native Method) at org.jboss.util.TimerQueue$TimerTaskLoop.run(TimerQueue.java:146) at java.lang.Thread.run(Thread.java:484) "JAWS Preload reference handler" daemon prio=1 tid=0x84cd578 nid=0x16f8 waiting on monitor [0xbb9ff000..0xbb9ff8b0] at java.lang.Object.wait(Native Method) at org.jboss.util.TimerQueue$TimerTaskLoop.run(TimerQueue.java:146) at java.lang.Thread.run(Thread.java:484) "RMI LeaseChecker" daemon prio=1 tid=0x83aed48 nid=0x16f6 waiting on monitor [0xbbbff000..0xbbbff8b0] at java.lang.Thread.sleep(Native Method) at sun.rmi.transport.DGCImpl$LeaseChecker.run(DGCImpl.java:299) at java.lang.Thread.run(Thread.java:484) "JNP Server"
Re: [JBoss-dev] JBoss 3.0.0 Alpha - Exception while loading...
Don't worry about it... I had some jar files such as xerces.jar and soap.jar files in the JDK's ext directory... Yong T. Kim - Original Message - From: Yong T. Kim To: [EMAIL PROTECTED] Sent: Wednesday, November 21, 2001 7:24 PM Subject: [JBoss-dev] JBoss 3.0.0 Alpha - Exception while loading... I get following exceptions. What's wrong? D:\jboss-3.0.0alpha\bin>run.batJBOSS_CLASSPATH=;run.jar[GPA] Microkernel ClassLoaders and Libraries initializedLibraries adding URLClassLoader -1003117907 key URL file:/D:/jboss-3.0.0alpha//conf/default/Libraries adding URLClassLoader 912512067 key URL file:/D:/jboss-3.0.0alpha//lib/ext/log4j.jarLibraries adding URLClassLoader 634821366 key URL file:/D:/jboss-3.0.0alpha//lib/ext/jboss-spine.jar[19:19:52,960,root] Started Log4jService, config=file:/D:/jboss-3.0.0alpha//conf/default/log4j.properties[19:19:52,980,GPA] General Purpose Architecture [GPA][19:19:52,980,GPA] Java version: 1.3.1_01,Sun Microsystems Inc.[19:19:52,990,GPA] Java VM: Java HotSpot(TM) Client VM 1.3.1_01,Sun Microsystems Inc.[19:19:52,990,GPA] OS-System: Windows 2000 5.0,x86[19:19:52,990,GPA] JBoss Version : 3.0.0alpha(200111202304)[19:19:53,000,GPA] JBoss start time : Wed Nov 21 19:19:51 EST 2001[19:19:53,000,GPA] localDir : D:\jboss-3.0.0alpha[19:19:53,000,GPA] installationURL : file:/D:/jboss-3.0.0alpha/\[19:19:53,010,GPA] configuration : file:/D:/jboss-3.0.0alpha/\conf\default\[19:19:53,010,GPA] libraries : file:/D:/jboss-3.0.0alpha/\lib\ext\[19:19:53,010,GPA] local patch directory:[19:19:53,010,GPA] Oh, and remember we love you[19:19:53,090,Shutdown] Shutdown hook added[19:19:53,210,ServiceController] Controller MBean online[19:19:53,380,ServiceDeployer] Starting[19:19:53,410,ServiceDeployer] Temporary deploy directory is D:\jboss-3.0.0alpha\tmp\deploy\ServiceDeployer[19:19:53,420,ServiceDeployer] Started[19:19:53,471,ServiceDeployer] deploy failedjavax.xml.parsers.FactoryConfigurationError: org.apache.crimson.jaxp.DocumentBuilderFactoryImpl at javax.xml.parsers.DocumentBuilderFactory.newInstance(DocumentBuilderFactory.java:154) at org.jboss.deployment.ServiceDeployer.getDocument(ServiceDeployer.java:633) at org.jboss.deployment.ServiceDeployer.deployLocalClasses(ServiceDeployer.java:281) at org.jboss.deployment.ServiceDeployer.deploy(ServiceDeployer.java:178) at org.jboss.deployment.DeployerMBeanSupport.deploy(DeployerMBeanSupport.java:107) at java.lang.reflect.Method.invoke(Native Method) at com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1628) at com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1523) at org.jboss.Main.(Main.java:199) at org.jboss.Main$1.run(Main.java:411) at java.security.AccessController.doPrivileged(Native Method) at org.jboss.Main.main(Main.java:406)[19:19:53,511,Default] javax.xml.parsers.FactoryConfigurationError: org.apache.crimson.jaxp.DocumentBuilderFactoryImpl[19:19:53,511,Default] at javax.xml.parsers.DocumentBuilderFactory.newInstance(DocumentBuilderFactory.java:154)[19:19:53,511,Default] at org.jboss.deployment.ServiceDeployer.getDocument(ServiceDeployer.java:633)[19:19:53,511,Default] at org.jboss.deployment.ServiceDeployer.deployLocalClasses(ServiceDeployer.java:281)[19:19:53,521,Default] at org.jboss.deployment.ServiceDeployer.deploy(ServiceDeployer.java:178)[19:19:53,521,Default] at org.jboss.deployment.DeployerMBeanSupport.deploy(DeployerMBeanSupport.java:107)[19:19:53,521,Default] at java.lang.reflect.Method.invoke(Native Method)[19:19:53,531,Default] at com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1628)[19:19:53,531,Default] at com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1523)[19:19:53,531,Default] at org.jboss.Main.(Main.java:199)[19:19:53,531,Default] at org.jboss.Main$1.run(Main.java:411)[19:19:53,541,Default] at java.security.AccessController.doPrivileged(Native Method)[19:19:53,541,Default] at org.jboss.Main.main(Main.java:406)[19:19:53,541,Default] JBoss 3.0.0alpha(200111202304) [RABBIT-HOLE] Started in 0m:1s:633ms[19:19:53,551,Shutdown] Shutting down all services[19:19:53,551,Default] Shutting down[19:19:53,561,ServiceController] Stopping 1 services[19:19:53,561,ServiceController] Stopped 0 services[19:19:53,561,Shutdown] Shutdown complete[19:19:53,571,Default] Shutdown complete Yong T. Kim (kimion.com)Software Developer[EMAIL PROTECTED]http://www.kimion.com
RE: [JBoss-dev] Re: [jboss-docs] Is the build system too complicated?
I think you can use cvs over ssh to down load the code even if you don't
have rw. All you would need is a sourceforge shell account, and I think you
get one just by signing up for a sf user account. I'm not completely sure
but I would try.
-dain
> -Original Message-
> From: Jason Dillon [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, November 21, 2001 1:44 PM
> To: [EMAIL PROTECTED]
> Cc: [EMAIL PROTECTED]
> Subject: Re: [JBoss-dev] Re: [jboss-docs] Is the build system too
> complicated?
>
>
> I see. Let me see if I can fix the snapshots, else I will
> fix build.sh.
>
> --jason
>
>
> On Wed, 21 Nov 2001 [EMAIL PROTECTED] wrote:
>
> > Unfortunately, my firewall currently doesn't let me check
> out via cvs
> > directly unless it's over ssh, and I don't have RW access to the
> > repository (yet :) -- I've been downloading the nightly
> snapshots (ugh)
> > in .tgz form from http://www.jboss.org/snapshots/. When I
> untar that, the
> > executable bit is not set.(using gnu tar and gzip on
> linux with the
> > command 'tar -xzvf jboss-all.tgz`) Actually, from a few
> spot checks, it
> > looks as if everything comes out '-rw-r--r--', including
> build.sh itself.
> > Yes, I've tried using the -p option with tar to extract permissions
> > information -- no effect (I think that's the default
> anyway, though I'm
> > not sure)
> >
> > -jason
> >
> >
> >
> >
> >
> >
> > Jason Dillon <[EMAIL PROTECTED]>
> > 11/21/2001 02:09 PM
> >
> >
> > To: [EMAIL PROTECTED]
> > cc: [EMAIL PROTECTED]
> > Subject:Re: [JBoss-dev] Re: [jboss-docs] Is
> the build system too complicated?
> >
> >
> >
> > The executable bit is set on tools/bin/ant. Why dosen't
> your cvs client
> > set
> > it when you check it out?
> >
> > --jason
> >
> >
> > On Wed, 21 Nov 2001 [EMAIL PROTECTED] wrote:
> >
> > > I do have a slightly off-topic gripe -- as of late, (in the rh
> > snapshots),
> > > jboss-all/tools/bin/ant has not been executable on UNIX
> systems (took my
> >
> > > little mind a while to figure out what was going on). The
> > > jboss-all/build/build.sh script has been failing because
> of it. It
> > looks
> > > for an executable 'ant', but never finds it (it doesn't have the
> > > executable bit set). I can see three possible solutions:
> > >
> > > 1. Just have the executable bit set on the ant script to
> start with
> > > 2. Change the search() function in build.sh to read like this:
> > >
> > > search() {
> > > search="$*"
> > > for d in $search; do
> > > ANT_HOME="`pwd`/$d"
> > > ANT="$ANT_HOME/bin/ant"
> > > # -- Begin modifications
> > > # If the file exists at all, attempt to add the
> executable bit
> > > if [ -e "$ANT" ]; then
> > > `chmod +x $ANT`
> > > fi
> > > # -- End modifications
> > > if [ -x "$ANT" ]; then
> > > # found one
> > > echo $ANT_HOME
> > > break
> > > fi
> > > done
> > > }
> > > #(just added a -e test to see if the file exists, and
> attempt to make it
> >
> > > executable so that the next -x test works)
> > >
> > > 3. Skip looking for an executable ant script -- just make sure it
> > exists,
> > > and call it with 'sh ant'.
> > >
> > > -jason
> > >
> > >
> > >
> > >
> > >
> > > Jason Dillon <[EMAIL PROTECTED]>
> > > Sent by: [EMAIL PROTECTED]
> > > 11/20/2001 09:38 PM
> > >
> > >
> > > To: [EMAIL PROTECTED]
> > > cc: [EMAIL PROTECTED]
> > > Subject:[JBoss-dev] Re: [jboss-docs] Is
> the build system
> > too complicated?
> > >
> > >
> > >
> > > I have not found an easy way to provide this common
> setup/initialization
> >
> > > stuff as a resource. Perhaps if I could tell the JAXP
> parser to read a
> > > resource file when parsing this could be done, but that
> would require
> > the
> > > Ant entity hooks to be installed to handle that.
> > >
> > > Perhaps they have done that, perhaps I could sway them
> todo it... though
> >
> > > my
> > > previous attempts to do so has failed (too much *ucking voting).
> > >
> > > If you can think of a way please let me know.
> > >
> > > Thanks for your feedback!
> > >
> > > --jason
> > >
> > >
> > > On Tue, 20 Nov 2001, David Jencks wrote:
> > >
> > > > It has often seemed to me that there is substantial duplication
> > between
> > > the
> > > > setup parts of the module level build.xml files. I
> sure haven't
> > figured
> > > > out a clue of a way to reduce this, but if it could be
> done, it might
> > > make
> > > > the files a little less intimidating. In light of the vast
> > improvement
> > > > over the preceding build "system", this is a hardly
> visible quibble.
> > > >
> > > > david jencks
> > > >
> > > > On 2001.11.20 16:43:07 -0500 Jason Dillon wrote:
> > > > > Please let me know if you think that the
Re: [JBoss-dev] Re: [jboss-docs] Is the build system too complicated?
On Wed, 21 Nov 2001 [EMAIL PROTECTED] wrote: > Unfortunately, my firewall currently doesn't let me check out via cvs > directly unless it's over ssh, and I don't have RW access to the > repository (yet :) -- I've been downloading the nightly snapshots (ugh) > in .tgz form from http://www.jboss.org/snapshots/. When I untar that, the > executable bit is not set.(using gnu tar and gzip on linux with the > command 'tar -xzvf jboss-all.tgz`) Actually, from a few spot checks, it > looks as if everything comes out '-rw-r--r--', including build.sh itself. > Yes, I've tried using the -p option with tar to extract permissions > information -- no effect (I think that's the default anyway, though I'm > not sure) http://kitenet.net/programs/sshcvs/ CVS over anonymous ssh. ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Developing with JBoss
On Wed, 21 Nov 2001, David Jencks wrote: > On 2001.11.21 14:06:58 -0500 danch wrote: > > > > > > Rickard Öberg wrote: > > > > > > > > That's much better, assuming I know where the tmp directory is. And I > > > don't, since the name keeps changing for each deployment. :-( > > > > > > Something people have been compaining about roughly forever. > > I think there are possible problems with trying to always use the same temp > dir -- for instance you might have problems removing the old copy before > you wanted to start the new one. We might be able to cook up some crazy > really hot redeploy whereby the new version is started before the old one > is stopped, allowing the requests in process in the old version to complete > while new requests go to the new version. > > What if we made the location of the temp dir visible through an mbean > representing the deployment? You could have a little ant task to ask where > the war went. What I would really like, is to see that a redeploy needs to happen, and have the new file extracted into a new directory first, THEN have the old version undeployed, then have the new one deployed, then have the old one deleted. The current way things are done, there is a big window open while the undeployment and redeployment is happening. ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] JBoss 3.0.0 Alpha - Exception while loading...
I get following exceptions. What's wrong? D:\jboss-3.0.0alpha\bin>run.batJBOSS_CLASSPATH=;run.jar[GPA] Microkernel ClassLoaders and Libraries initializedLibraries adding URLClassLoader -1003117907 key URL file:/D:/jboss-3.0.0alpha//conf/default/Libraries adding URLClassLoader 912512067 key URL file:/D:/jboss-3.0.0alpha//lib/ext/log4j.jarLibraries adding URLClassLoader 634821366 key URL file:/D:/jboss-3.0.0alpha//lib/ext/jboss-spine.jar[19:19:52,960,root] Started Log4jService, config=file:/D:/jboss-3.0.0alpha//conf/default/log4j.properties[19:19:52,980,GPA] General Purpose Architecture [GPA][19:19:52,980,GPA] Java version: 1.3.1_01,Sun Microsystems Inc.[19:19:52,990,GPA] Java VM: Java HotSpot(TM) Client VM 1.3.1_01,Sun Microsystems Inc.[19:19:52,990,GPA] OS-System: Windows 2000 5.0,x86[19:19:52,990,GPA] JBoss Version : 3.0.0alpha(200111202304)[19:19:53,000,GPA] JBoss start time : Wed Nov 21 19:19:51 EST 2001[19:19:53,000,GPA] localDir : D:\jboss-3.0.0alpha[19:19:53,000,GPA] installationURL : file:/D:/jboss-3.0.0alpha/\[19:19:53,010,GPA] configuration : file:/D:/jboss-3.0.0alpha/\conf\default\[19:19:53,010,GPA] libraries : file:/D:/jboss-3.0.0alpha/\lib\ext\[19:19:53,010,GPA] local patch directory:[19:19:53,010,GPA] Oh, and remember we love you[19:19:53,090,Shutdown] Shutdown hook added[19:19:53,210,ServiceController] Controller MBean online[19:19:53,380,ServiceDeployer] Starting[19:19:53,410,ServiceDeployer] Temporary deploy directory is D:\jboss-3.0.0alpha\tmp\deploy\ServiceDeployer[19:19:53,420,ServiceDeployer] Started[19:19:53,471,ServiceDeployer] deploy failedjavax.xml.parsers.FactoryConfigurationError: org.apache.crimson.jaxp.DocumentBuilderFactoryImpl at javax.xml.parsers.DocumentBuilderFactory.newInstance(DocumentBuilderFactory.java:154) at org.jboss.deployment.ServiceDeployer.getDocument(ServiceDeployer.java:633) at org.jboss.deployment.ServiceDeployer.deployLocalClasses(ServiceDeployer.java:281) at org.jboss.deployment.ServiceDeployer.deploy(ServiceDeployer.java:178) at org.jboss.deployment.DeployerMBeanSupport.deploy(DeployerMBeanSupport.java:107) at java.lang.reflect.Method.invoke(Native Method) at com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1628) at com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1523) at org.jboss.Main.(Main.java:199) at org.jboss.Main$1.run(Main.java:411) at java.security.AccessController.doPrivileged(Native Method) at org.jboss.Main.main(Main.java:406)[19:19:53,511,Default] javax.xml.parsers.FactoryConfigurationError: org.apache.crimson.jaxp.DocumentBuilderFactoryImpl[19:19:53,511,Default] at javax.xml.parsers.DocumentBuilderFactory.newInstance(DocumentBuilderFactory.java:154)[19:19:53,511,Default] at org.jboss.deployment.ServiceDeployer.getDocument(ServiceDeployer.java:633)[19:19:53,511,Default] at org.jboss.deployment.ServiceDeployer.deployLocalClasses(ServiceDeployer.java:281)[19:19:53,521,Default] at org.jboss.deployment.ServiceDeployer.deploy(ServiceDeployer.java:178)[19:19:53,521,Default] at org.jboss.deployment.DeployerMBeanSupport.deploy(DeployerMBeanSupport.java:107)[19:19:53,521,Default] at java.lang.reflect.Method.invoke(Native Method)[19:19:53,531,Default] at com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1628)[19:19:53,531,Default] at com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1523)[19:19:53,531,Default] at org.jboss.Main.(Main.java:199)[19:19:53,531,Default] at org.jboss.Main$1.run(Main.java:411)[19:19:53,541,Default] at java.security.AccessController.doPrivileged(Native Method)[19:19:53,541,Default] at org.jboss.Main.main(Main.java:406)[19:19:53,541,Default] JBoss 3.0.0alpha(200111202304) [RABBIT-HOLE] Started in 0m:1s:633ms[19:19:53,551,Shutdown] Shutting down all services[19:19:53,551,Default] Shutting down[19:19:53,561,ServiceController] Stopping 1 services[19:19:53,561,ServiceController] Stopped 0 services[19:19:53,561,Shutdown] Shutdown complete[19:19:53,571,Default] Shutdown complete Yong T. Kim (kimion.com)Software Developer[EMAIL PROTECTED]http://www.kimion.com
[JBoss-dev] java.sql.SQLException: Connection has been closed!
RH CVS HEAD- refreshed an hour or so ago
Running the WebIntegration testsuite:
I guess the setEntityContext("null") - may have done this !
I'll scout around, but I don't think (tentatively) this is mine.
Jules
[00:11:37,740,Jetty] UserTransactionServlet: init
[00:11:38,112,Default] setEntityContext("null") called
[00:11:38,383,OILClientIL] ConnectionReceiverOILClient is connecting to:
127.0.0.1:42107
[00:11:38,519,Default] Sending a message..
[00:11:38,583,Default] entry ejbFindAll
[00:11:38,629,Default] Initializing DATABASE tables for BMP test...
[00:11:38,649,Default] java.sql.SQLException: Connection has been
closed!
[00:11:38,670,Default] at
org.jboss.resource.adapter.jdbc.local.ConnectionInPool.close(ConnectionInPool.java:774)
[00:11:38,670,Default] at
org.jboss.test.cts.ejb.CtsBmpBean.initializeDatabaseTable(CtsBmpBean.java:531)
[00:11:38,671,Default] at
org.jboss.test.cts.ejb.CtsBmpBean.ensureTableExists(CtsBmpBean.java:496)
[00:11:38,702,Default] at
org.jboss.test.cts.ejb.CtsBmpBean.ejbFindAll(CtsBmpBean.java:190)
[00:11:38,703,Default] at java.lang.reflect.Method.invoke(Native
Method)
[00:11:38,720,Default] at
org.jboss.ejb.plugins.BMPPersistenceManager.callFinderMethod(BMPPersistenceManager.java:588)
[00:11:38,720,Default] at
org.jboss.ejb.plugins.BMPPersistenceManager.findEntities(BMPPersistenceManager.java:307)
[00:11:38,720,Default] at
org.jboss.ejb.EntityContainer.find(EntityContainer.java:606)
[00:11:38,738,Default] at java.lang.reflect.Method.invoke(Native
Method)
[00:11:38,738,Default] at
org.jboss.ejb.EntityContainer$ContainerInterceptor.invokeHome(EntityContainer.java:926)
[00:11:38,738,Default] at
org.jboss.ejb.plugins.EntitySynchronizationInterceptor.invokeHome(EntitySynchronizationInterceptor.java:234)
[00:11:38,738,Default] at
org.jboss.ejb.plugins.EntityInstanceInterceptor.invokeHome(EntityInstanceInterceptor.java:151)
[00:11:38,739,Default] at
org.jboss.ejb.plugins.EntityLockInterceptor.invokeHome(EntityLockInterceptor.java:104)
[00:11:38,739,Default] at
org.jboss.ejb.plugins.AbstractTxInterceptor.invokeNext(AbstractTxInterceptor.java:100)
[00:11:38,739,Default] at
org.jboss.ejb.plugins.TxInterceptorCMT.runWithTransactions(TxInterceptorCMT.java:156)
[00:11:38,743,Default] at
org.jboss.ejb.plugins.TxInterceptorCMT.invokeHome(TxInterceptorCMT.java:56)
[00:11:38,743,Default] at
org.jboss.ejb.plugins.SecurityInterceptor.invokeHome(SecurityInterceptor.java:106)
[00:11:38,743,Default] at
org.jboss.ejb.plugins.LogInterceptor.invokeHome(LogInterceptor.java:109)
[00:11:38,743,Default] at
org.jboss.ejb.EntityContainer.invokeHome(EntityContainer.java:441)
[00:11:38,744,Default] at
org.jboss.ejb.plugins.jrmp.server.JRMPContainerInvoker.invokeHome(JRMPContainerInvoker.java:460)
[00:11:38,744,Default] at
org.jboss.ejb.plugins.jrmp.interfaces.HomeProxy.invokeHome(HomeProxy.java:237)
[00:11:38,744,Default] at
org.jboss.ejb.plugins.jrmp.interfaces.HomeProxy.invoke(HomeProxy.java:182)
[00:11:38,744,Default] at $Proxy20.findAll(Unknown Source)
[00:11:38,744,Default] at
org.jboss.test.web.servlets.UserTransactionServlet.processRequest(UserTransactionServlet.java:66)
[00:11:38,744,Default] at
org.jboss.test.web.servlets.UserTransactionServlet.doGet(UserTransactionServlet.java:97)
[00:11:38,745,Default] at
javax.servlet.http.HttpServlet.service(HttpServlet.java:740)
[00:11:38,745,Default] at
javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
[00:11:38,745,Default] at
org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:289)
[00:11:38,745,Default] at
org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:526)
[00:11:38,745,Default] at
org.mortbay.http.HttpContext.handle(HttpContext.java:1145)
[00:11:38,745,Default] at
org.mortbay.http.HttpContext.handle(HttpContext.java:1099)
[00:11:38,746,Default] at
org.jboss.jetty.JBossWebApplicationContext.handle(JBossWebApplicationContext.java:185)
[00:11:38,746,Default] at
org.mortbay.http.HttpServer.service(HttpServer.java:725)
[00:11:38,746,Default] at
org.mortbay.http.HttpConnection.service(HttpConnection.java:745)
[00:11:38,746,Default] at
org.mortbay.http.HttpConnection.handleNext(HttpConnection.java:918)
[00:11:38,746,Default] at
org.mortbay.http.HttpConnection.handle(HttpConnection.java:760)
[00:11:38,746,Default] at
org.mortbay.http.SocketListener.handleConnection(SocketListener.java:138)
[00:11:38,747,Default] at
org.mortbay.util.ThreadedServer.handle(ThreadedServer.java:287)
[00:11:38,747,Default] at
org.mortbay.util.ThreadPool$JobRunner.run(ThreadPool.java:715)
[00:11:38,747,Default] at java.lang.Thread.run(Thread.java:484)
[00:11:38,764,Jetty] WARNING: GET /jbosstest/UserTransactionServlet
HTTP/1.1
java.rmi.ServerException: null
_
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com
___
Jboss-development mailing list
[EMA
[JBoss-dev] CVS update: jboss/src/etc/conf/default log4j.properties
User: user57
Date: 01/11/21 16:10:01
Modified:src/etc/conf/default log4j.properties
Log:
o added priority to Default and Console patterns
o added example to add full NDC and thread information to Default
(server.log)
o added example to limit org.jboss to INFO
o added example to limit org.jboss.util to DEBUG
Revision ChangesPath
1.14 +24 -9 jboss/src/etc/conf/default/log4j.properties
Index: log4j.properties
===
RCS file: /cvsroot/jboss/jboss/src/etc/conf/default/log4j.properties,v
retrieving revision 1.13
retrieving revision 1.14
diff -u -r1.13 -r1.14
--- log4j.properties 2001/10/18 08:27:42 1.13
+++ log4j.properties 2001/11/22 00:10:01 1.14
@@ -4,13 +4,14 @@
## ##
### == ###
-### $Id: log4j.properties,v 1.13 2001/10/18 08:27:42 kimptoc Exp $ ###
+### $Id: log4j.properties,v 1.14 2001/11/22 00:10:01 user57 Exp $ ###
# This creates a server.log appender and a console appender.
# Set the LoggerFactory as the default CategoryFactory
log4j.categoryFactory=org.jboss.logging.LoggerFactory
+# Setup the root category
log4j.rootCategory=DEBUG, Default, Console
### The server.log file appender
@@ -18,28 +19,42 @@
log4j.appender.Default=org.apache.log4j.FileAppender
log4j.appender.Default.File=../log/server.log
log4j.appender.Default.layout=org.apache.log4j.PatternLayout
-# A default format: [Category] msg\n
-log4j.appender.Default.layout.ConversionPattern=[%d,%c{1},%p] %m%n
-# A format useful for debugging concurrency: [Category,thread,elapased_ms] msg\n
-#log4j.appender.Default.layout.ConversionPattern=[%c{1},%t,%r] %m%n
+
# Truncate if it aleady exists.
log4j.appender.Default.Append=false
+# The default pattern: Date Priority [Category] Message\n
+log4j.appender.Default.layout.ConversionPattern=%d{ABSOLUTE} %-5p [%c] %m%n
+
+# The full pattern: Date MS Priority [Category] (Thread:NDC) Message\n
+#log4j.appender.Default.layout.ConversionPattern=%d{ABSOLUTE} %-5r %-5p [%c]
(%t:%x) %m%n
+
+# The old style pattern
+#log4j.appender.Default.layout.ConversionPattern=[%d,%c{1},%p] %m%n
+
### The console appender
log4j.appender.Console=org.jboss.logging.log4j.ConsoleAppender
log4j.appender.Console.Threshold=INFO
log4j.appender.Console.layout=org.apache.log4j.PatternLayout
-log4j.appender.Console.layout.ConversionPattern=[%d{ABSOLUTE},%c{1}] %m%n
+# The default pattern: Date Priority [Category] Message\n
+log4j.appender.Console.layout.ConversionPattern=%d{ABSOLUTE} %-5p [%c{1}] %m%n
+
+# The old style pattern
+#log4j.appender.Console.layout.ConversionPattern=[%d{ABSOLUTE},%c{1}] %m%n
+
# Example of increasing the priority threshold for the DefaultDS category
#log4j.category.DefaultDS=FATAL
-# Example of only showing INFO msgs for any categories under org.jboss.util
-#log4j.category.org.jboss.util=INFO
+# Only show INFO messages for org.jboss
+#log4j.category.org.jboss=INFO
+
+# Example of only showing DEBUG msgs for any categories under org.jboss.util
+#log4j.category.org.jboss.util=DEBUG
+
# An example of enabling the custom TRACE level priority that is used
# by the JBoss internals to diagnose low level details. This example
# turns on TRACE level msgs for the org.jboss.ejb.plugins package and its
# subpackages. This will produce A LOT of logging output.
#log4j.category.org.jboss.ejb.plugins=TRACE#org.jboss.logging.TracePriority
-
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] suggest changing log4j layout patterns
Dosen't look like the 1.1.3 xml configurator does the right thing with
custom priorities, also looks like it can not set the CategoryFactory
either.
=(
--jason
On Fri, 16 Nov 2001, Scott M Stark wrote:
>
> The priority is fine but the thread is not. As of log4j 1.1.3 the log4j.dtd
> says is supports a priority class but I have not tried it.
>
> - Original Message -
> From: "Jason Dillon" <[EMAIL PROTECTED]>
> To: "Scott M Stark" <[EMAIL PROTECTED]>
> Cc: <[EMAIL PROTECTED]>
> Sent: Friday, November 16, 2001 10:45 AM
> Subject: Re: [JBoss-dev] suggest changing log4j layout patterns
>
>
> > How about at least adding the priority. I don't think that this info that
> > will dump to console with this format is excesive, perhaps you might not
> > want the thread name there.
> >
> > Do you know if we are still forced to use log4j.properties (instead of
> > log4j.xml) due to the JBoss TRACE priority?
> >
> > --jason
> >
> >
> > On Fri, 16 Nov 2001, Scott M Stark wrote:
> >
> > > The console output should be short and simple. In any production
> > > envrionment your likely to not even be using it so its just for quick
> looks
> > > and I don't want excessive info displayed there. The default server.log
> > > format can be more verbose. Its also trival to change these settings if
> > > you know enough about log4j, so I would rather keep the defaults
> > > simpler and let you change them for your specific need.
> > >
> > >
> > > Scott Stark
> > > Chief Technology Officer
> > > JBoss Group, LLC
> > >
> > > - Original Message -
> > > From: "Jason Dillon" <[EMAIL PROTECTED]>
> > > To: <[EMAIL PROTECTED]>
> > > Sent: Thursday, November 15, 2001 4:09 PM
> > > Subject: [JBoss-dev] suggest changing log4j layout patterns
> > >
> > >
> > > > I suggest that we change the log4j layout patterns to add more useful
> > > > information to the console and server.log files:
> > > >
> > > > For console:
> > > >
> > > >"%-5p %c{1} [%t] - %m%n"
> > > >
> > > > INFO JMXAdaptorService [main] - Starting
> > > > DEBUG MailingPOEJB [Passivator Thread for MailingPO] - ejbPassivate
> > > >
> > > > For server.log:
> > > >
> > > >"%d %-5r %-5p %c [%t] (%x) - %m%n"
> > > >
> > > > 2001-11-13 11:35:32,210 2396 INFO org.jboss.util.Shutdown [main]
> () -
> > > Shutdown hook added
> > > > 2001-11-13 11:35:36,576 6762 WARN
> > > org.jboss.configuration.ConfigurationService [main] () -
> > > Monitor:name=BeanCacheMonitor does not implement any Service methods
> > > >
> > > > * * *
> > > >
> > > > I have found that the extra information is very, very useful to debug
> > > > components running inside of JBoss. The above puts the minimal amount
> of
> > > > useful information on the console in a terse format and dumps all
> usefull
> > > > information into server.log in a verbose format.
> > > >
> > > > I believe that users of JBoss would benifit from these settings by
> default
> > > > and I suggest that we update the log4j.properties (or use log4j.xml)
> with
> > > > these layout formats.
> > > >
> > > > Any objections?
> > > >
> > > > --jason
> > > >
> > > >
> > > > ___
> > > > Jboss-development mailing list
> > > > [EMAIL PROTECTED]
> > > > https://lists.sourceforge.net/lists/listinfo/jboss-development
> > > >
> > >
> > >
> > > ___
> > > Jboss-development mailing list
> > > [EMAIL PROTECTED]
> > > https://lists.sourceforge.net/lists/listinfo/jboss-development
> > >
> >
> >
> > ___
> > Jboss-development mailing list
> > [EMAIL PROTECTED]
> > https://lists.sourceforge.net/lists/listinfo/jboss-development
> >
>
>
> ___
> Jboss-development mailing list
> [EMAIL PROTECTED]
> https://lists.sourceforge.net/lists/listinfo/jboss-development
>
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jboss/src/main/org/jboss/system ServiceConfigurator.java
User: user57
Date: 01/11/21 15:31:39
Modified:src/main/org/jboss/system ServiceConfigurator.java
Log:
o using class to create Logger instance
Revision ChangesPath
1.9 +2 -2 jboss/src/main/org/jboss/system/ServiceConfigurator.java
Index: ServiceConfigurator.java
===
RCS file: /cvsroot/jboss/jboss/src/main/org/jboss/system/ServiceConfigurator.java,v
retrieving revision 1.8
retrieving revision 1.9
diff -u -r1.8 -r1.9
--- ServiceConfigurator.java 2001/11/19 06:58:57 1.8
+++ ServiceConfigurator.java 2001/11/21 23:31:39 1.9
@@ -42,7 +42,7 @@
*
* @author mailto:[EMAIL PROTECTED]";>Marc Fleury
* @author mailto:[EMAIL PROTECTED]";>Hiram Chirino
- * @version $Revision: 1.8 $
+ * @version $Revision: 1.9 $
*
* 20010830 marc fleury:
*
@@ -73,7 +73,7 @@
private MBeanServer server;
/** The instance logger. */
- private static Logger log = Logger.create("Configurator");
+ private static Logger log = Logger.create(ServiceConfigurator.class);
// Constructors --
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Security exceptions when calling a local interface
Are you guys aware that the LocalHome interface can be called from someone without enough permissions and the exception thrown should be of type EJBException, not RemoteException? I interpreted the following as the Security Interceptor throwing a RemoteException when it should throw an EJBException. From this on the exception chaining become some kind of a chaos. I assigned method permissions and everything worked fine. [2001-11-20 20:49:25,032,LogInterceptor,ERROR] TransactionRolledbackException, causedBy: java.lang.reflect.UndeclaredThrowableException at $Proxy18.findByPrimaryKey(Unknown Source) . . . Caused by: java.rmi.RemoteException: checkSecurityAssociation; nested exception is: java.lang.SecurityException: No method permissions assigned to method=findByPrimaryKey ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: contrib/jetty/src/main/org/jboss/jetty JBossWebApplicationContext.java JBossLogSink.java JBossUserRealm.java Jetty.java JettyMBean.java JettyResolver.java JettyService.java SetupHandler.java
User: jules_gosnell
Date: 01/11/21 15:13:01
Modified:jetty/src/main/org/jboss/jetty JBossLogSink.java
JBossUserRealm.java Jetty.java JettyMBean.java
JettyResolver.java JettyService.java
SetupHandler.java
Added: jetty/src/main/org/jboss/jetty
JBossWebApplicationContext.java
Log:
my first cut of the JBoss3/Jetty4 integration - enjoy !
Revision ChangesPath
1.7 +9 -8 contrib/jetty/src/main/org/jboss/jetty/JBossLogSink.java
Index: JBossLogSink.java
===
RCS file: /cvsroot/jboss/contrib/jetty/src/main/org/jboss/jetty/JBossLogSink.java,v
retrieving revision 1.6
retrieving revision 1.7
diff -u -r1.6 -r1.7
--- JBossLogSink.java 2001/10/03 22:27:02 1.6
+++ JBossLogSink.java 2001/11/21 23:13:01 1.7
@@ -5,7 +5,7 @@
* See terms of license at gnu.org.
*/
-// $Id: JBossLogSink.java,v 1.6 2001/10/03 22:27:02 jules_gosnell Exp $
+// $Id: JBossLogSink.java,v 1.7 2001/11/21 23:13:01 jules_gosnell Exp $
package org.jboss.jetty;
@@ -22,7 +22,7 @@
* This class bidges the API between Jetty and Log4J.
*
* @author mailto:";>Jules Gosnell
- * @version $Id: JBossLogSink.java,v 1.6 2001/10/03 22:27:02 jules_gosnell Exp $
+ * @version $Id: JBossLogSink.java,v 1.7 2001/11/21 23:13:01 jules_gosnell Exp $
* @since 1.0
* @see org.mortbay.util.LogSink
*/
@@ -34,7 +34,7 @@
HashMap _dispatch = new HashMap();
interface Logger {void log(String s);}
-
+
public
JBossLogSink()
{
@@ -65,6 +65,7 @@
throws InterruptedException
{
_started = false;
+//_log=null;
}
public void
@@ -101,10 +102,10 @@
{
// is it possible to translate these into JBoss logging options...?
}
-
+
public void
setOptions(String logOptions)
- {
+ {
// setOptions((logOptions.indexOf(OPT_TIMESTAMP) >= 0),
// (logOptions.indexOf(OPT_LABEL) >= 0),
// (logOptions.indexOf(OPT_TAG) >= 0),
@@ -112,7 +113,7 @@
// (logOptions.indexOf(OPT_STACKTRACE) >= 0),
// (logOptions.indexOf(OPT_ONELINE) >= 0));
}
-
+
public String
getOptions()
{
@@ -125,7 +126,7 @@
// (_logOneLine?"O":"");
return "";
}
-
+
/* */
/** Log a message.
* This method formats the log information as a string and calls
@@ -158,7 +159,7 @@
/** Log a message.
* The formatted log string is written to the log sink. The default
* implementation writes the message to a PrintWriter.
- * @param formattedLog
+ * @param formattedLog
*/
public synchronized void
log(String formattedLog)
1.8 +131 -79 contrib/jetty/src/main/org/jboss/jetty/JBossUserRealm.java
Index: JBossUserRealm.java
===
RCS file: /cvsroot/jboss/contrib/jetty/src/main/org/jboss/jetty/JBossUserRealm.java,v
retrieving revision 1.7
retrieving revision 1.8
diff -u -r1.7 -r1.8
--- JBossUserRealm.java 2001/09/17 23:07:47 1.7
+++ JBossUserRealm.java 2001/11/21 23:13:01 1.8
@@ -5,13 +5,17 @@
* See terms of license at gnu.org.
*/
-// $Id: JBossUserRealm.java,v 1.7 2001/09/17 23:07:47 jules_gosnell Exp $
+// $Id: JBossUserRealm.java,v 1.8 2001/11/21 23:13:01 jules_gosnell Exp $
package org.jboss.jetty;
-import java.util.HashSet;
+import java.util.Collections;
+import java.util.HashMap;
+import java.util.Set;
+import javax.naming.Context;
import javax.naming.InitialContext;
import javax.naming.NamingException;
+import javax.security.auth.Subject;
import org.apache.log4j.Category;
import org.jboss.security.EJBSecurityManager;
import org.jboss.security.RealmMapping;
@@ -25,106 +29,103 @@
/** An implementation of UserRealm that integrates with the JBossSX
* security manager associted with the web application.
* @author [EMAIL PROTECTED]
- * @version $Revision: 1.7 $
+ * @version $Revision: 1.8 $
*/
+
+// TODO
+
public class JBossUserRealm
implements UserRealm
{
- private String _realmName;
- private Category _log;
-
- //
-
- class User
-extends SimplePrincipal
-implements UserPrincipal
- {
-HttpRequest _request;
-
-User(String name, HttpRequest request)
+ class JBossUserPrincipal
+extends SimplePrincipal // The JBoss API
+implements UserPrincipal // The Jetty API
+ {
+JBossUserPrincipal(String name)
{
super(name);
- _request = request;
+ _log.info
[JBoss-dev] CVS update: thirdparty/mortbay/jetty3extra/lib org.mortbay.ftp.jar org.mortbay.jetty.jmx.jar org.mortbay.tools.jar
User: jules_gosnell Date: 01/11/21 15:13:00 Modified:mortbay/jetty3extra/lib org.mortbay.ftp.jar org.mortbay.jetty.jmx.jar org.mortbay.tools.jar Log: my first cut of the JBoss3/Jetty4 integration - enjoy ! Revision ChangesPath 1.2 +13 -13thirdparty/mortbay/jetty3extra/lib/org.mortbay.ftp.jar <> 1.2 +67 -82thirdparty/mortbay/jetty3extra/lib/org.mortbay.jetty.jmx.jar <> 1.2 +96 -87thirdparty/mortbay/jetty3extra/lib/org.mortbay.tools.jar <> ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: contrib/jetty build.xml
User: jules_gosnell
Date: 01/11/21 15:13:00
Modified:jettybuild.xml
Log:
my first cut of the JBoss3/Jetty4 integration - enjoy !
Revision ChangesPath
1.11 +55 -24contrib/jetty/build.xml
Index: build.xml
===
RCS file: /cvsroot/jboss/contrib/jetty/build.xml,v
retrieving revision 1.10
retrieving revision 1.11
diff -u -r1.10 -r1.11
--- build.xml 2001/11/19 15:34:04 1.10
+++ build.xml 2001/11/21 23:13:00 1.11
@@ -29,9 +29,9 @@
-
+
-
+
@@ -130,7 +130,7 @@
@@ -180,6 +180,13 @@
+
+
+
+
+
+
+
@@ -218,6 +225,7 @@
+
@@ -299,14 +307,14 @@
-
-
@@ -356,7 +364,7 @@
-
@@ -388,32 +396,55 @@
-
+
+
+Undeploying old Jetty plugin...
+
+
+
+Deploying new Jetty plugin...
+
+
+
+
+
+
+
+
+
+
+
-
-
-
@@ -445,7 +476,7 @@
private="${javadoc.private}"
encoding="${javadoc.encoding}"
use="${javadoc.use}"
- verbose="${javadoc.verbose}">
+ verbose="${javadoc.verbose}">
@@ -474,7 +505,7 @@
-
@@ -517,7 +548,7 @@
| Run all tests.
-->
-
@@ -528,9 +559,9 @@
@@ -546,8 +577,8 @@
usefile="${junit.formatter.usefile}"/>
@@ -558,7 +589,7 @@
-
@@ -631,7 +662,7 @@
-
+
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: thirdparty/mortbay/jetty/lib javax.servlet.jar org.apache.jasper.jar org.mortbay.jetty.jar
User: jules_gosnell Date: 01/11/21 15:13:00 Modified:mortbay/jetty/lib javax.servlet.jar org.apache.jasper.jar org.mortbay.jetty.jar Log: my first cut of the JBoss3/Jetty4 integration - enjoy ! Revision ChangesPath 1.2 +239 -126 thirdparty/mortbay/jetty/lib/javax.servlet.jar <> 1.5 +984 -705 thirdparty/mortbay/jetty/lib/org.apache.jasper.jar <> 1.3 +1488 -1417thirdparty/mortbay/jetty/lib/org.mortbay.jetty.jar <> ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] JBoss3/Jetty4 - checked in...(soon)
I am just checking Jetty4 and it's integration code into RH cvs.
It runs through the WebIntegration testsuite with (I think) one problem,
which I am hoping is not mine.
Some of the code is a bit ugly still, but I wanted to get it out there.
Thanks everyone for their patience with me.
I look forward to all the bug-reports.
Jules
P.S.
for JSPs put a copy of/link to $JAVA_HOME/lib/tools.jar in your
lib/ext
[22:47:52,538,Jetty] ENCServlet: init
[22:47:52,709,Default] ejb/bean0 = ENCBean0Home
[22:47:52,859,Default] ejb/bean1 = ENCBean1Home
[22:47:53,006,Default] ejb/bean2 = ENCBean1Home
[22:47:53,158,Default] ejb/UnsecuredEJB =
jbosstest/ejbs/UnsecuredEJBHome
[22:47:53,310,Default] ejb/SecuredEJB = jbosstest/ejbs/SecuredEJBHome
[22:47:53,320,Default] jdbc/DefaultDS =
org.jboss.resource.adapter.jdbc.JDBCDataSource@1ec4ed
[22:47:53,332,Default] mail/DefaultMail = javax.mail.Session@23aa2c
[22:47:53,350,Default] jms/QueFactory =
org.jboss.mq.SpyConnectionFactory@4c7e10
[22:47:53,359,Default] Ints/i0 = 0
[22:47:53,370,Default] Ints/i1 = 1
[22:47:53,383,Default] Floats/f0 = 0.0
[22:47:53,393,Default] Floats/f1 = 1.1
[22:47:53,403,Default] Strings/s0 = String0
[22:47:53,411,Default] Strings/s1 = String1
[22:47:53,420,Default] ejb/catalog/CatalogDAOClass =
com.sun.model.dao.CatalogDAOImpl
[22:47:53,439,Jetty] EJBServlet: init
[22:47:53,593,Default] StatelessSessionBean2.noop,
test.wasSerialized=false, optimized=true
[22:47:53,610,Jetty] UserTransactionServlet: init
[22:47:53,840,Default] setEntityContext("null") called
[22:47:53,922,OILClientIL] ConnectionReceiverOILClient is connecting to:
127.0.0.1:41999
[22:47:53,940,Default] Sending a message..
[22:47:53,959,Default] entry ejbFindAll
[22:47:53,974,Default] Initializing DATABASE tables for BMP test...
[22:47:53,981,Default] java.sql.SQLException: Connection has been
closed!
[22:47:53,989,Default] at
org.jboss.resource.adapter.jdbc.local.ConnectionInPool.close(ConnectionInPool.java:774)
[22:47:53,998,Default] at
org.jboss.test.cts.ejb.CtsBmpBean.initializeDatabaseTable(CtsBmpBean.java:531)
[22:47:54,007,Default] at
org.jboss.test.cts.ejb.CtsBmpBean.ensureTableExists(CtsBmpBean.java:496)
[22:47:54,016,Default] at
org.jboss.test.cts.ejb.CtsBmpBean.ejbFindAll(CtsBmpBean.java:190)
[22:47:54,026,Default] at java.lang.reflect.Method.invoke(Native
Method)
[22:47:54,035,Default] at
org.jboss.ejb.plugins.BMPPersistenceManager.callFinderMethod(BMPPersistenceManager.java:588)
[22:47:54,043,Default] at
org.jboss.ejb.plugins.BMPPersistenceManager.findEntities(BMPPersistenceManager.java:307)
[22:47:54,050,Default] at
org.jboss.ejb.EntityContainer.find(EntityContainer.java:606)
[22:47:54,058,Default] at java.lang.reflect.Method.invoke(Native
Method)
[22:47:54,059,Default] at
org.jboss.ejb.EntityContainer$ContainerInterceptor.invokeHome(EntityContainer.java:926)
[22:47:54,059,Default] at
org.jboss.ejb.plugins.EntitySynchronizationInterceptor.invokeHome(EntitySynchronizationInterceptor.java:234)
[22:47:54,077,Default] at
org.jboss.ejb.plugins.EntityInstanceInterceptor.invokeHome(EntityInstanceInterceptor.java:151)
[22:47:54,077,Default] at
org.jboss.ejb.plugins.EntityLockInterceptor.invokeHome(EntityLockInterceptor.java:104)
[22:47:54,077,Default] at
org.jboss.ejb.plugins.AbstractTxInterceptor.invokeNext(AbstractTxInterceptor.java:100)
[22:47:54,082,Default] at
org.jboss.ejb.plugins.TxInterceptorCMT.runWithTransactions(TxInterceptorCMT.java:156)
[22:47:54,082,Default] at
org.jboss.ejb.plugins.TxInterceptorCMT.invokeHome(TxInterceptorCMT.java:56)
[22:47:54,082,Default] at
org.jboss.ejb.plugins.SecurityInterceptor.invokeHome(SecurityInterceptor.java:106)
[22:47:54,082,Default] at
org.jboss.ejb.plugins.LogInterceptor.invokeHome(LogInterceptor.java:109)
[22:47:54,083,Default] at
org.jboss.ejb.EntityContainer.invokeHome(EntityContainer.java:441)
[22:47:54,083,Default] at
org.jboss.ejb.plugins.jrmp.server.JRMPContainerInvoker.invokeHome(JRMPContainerInvoker.java:460)
[22:47:54,083,Default] at
org.jboss.ejb.plugins.jrmp.interfaces.HomeProxy.invokeHome(HomeProxy.java:237)
[22:47:54,083,Default] at
org.jboss.ejb.plugins.jrmp.interfaces.HomeProxy.invoke(HomeProxy.java:182)
[22:47:54,083,Default] at $Proxy33.findAll(Unknown Source)
[22:47:54,083,Default] at
org.jboss.test.web.servlets.UserTransactionServlet.processRequest(UserTransactionServlet.java:66)
[22:47:54,083,Default] at
org.jboss.test.web.servlets.UserTransactionServlet.doGet(UserTransactionServlet.java:97)
[22:47:54,084,Default] at
javax.servlet.http.HttpServlet.service(HttpServlet.java:740)
[22:47:54,084,Default] at
javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
[22:47:54,084,Default] at
org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:289)
[22:47:54,084,Default] at
org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:526)
[22:47:54,084,Default] at
org.mortbay.http.HttpContext.handle(HttpContext.java:1145)
[22:47:54,084
Re: [JBoss-dev] Re: [jboss-docs] Is the build system too complicated?
java really pisses me off sometimes. why can't you get file perms from a
given platform? all of this platform independence has really dumbed down
the file access apis, too much in my oppinon.
it appears that there is noway with the vanilla jdk to check if a file is
executable... which is really *ucking stupid if you ask me... but since you
didn't well I am telling you anyways. Afterall who would want to execute a
file from Java? Whatever, where do they find the people that design this
crap.
Anyways, I have HACKED the build file to make all 'build.sh' and
'tools/bin/ant[Run]' files executable. I don't really like it, but don't
have much choice. Thanks SUN!
* * *
Let me know if this fixes your problem, should be ready early tomorrow
morning on the website.
--jason
On Wed, 21 Nov 2001 [EMAIL PROTECTED] wrote:
> Unfortunately, my firewall currently doesn't let me check out via cvs
> directly unless it's over ssh, and I don't have RW access to the
> repository (yet :) -- I've been downloading the nightly snapshots (ugh)
> in .tgz form from http://www.jboss.org/snapshots/. When I untar that, the
> executable bit is not set.(using gnu tar and gzip on linux with the
> command 'tar -xzvf jboss-all.tgz`) Actually, from a few spot checks, it
> looks as if everything comes out '-rw-r--r--', including build.sh itself.
> Yes, I've tried using the -p option with tar to extract permissions
> information -- no effect (I think that's the default anyway, though I'm
> not sure)
>
> -jason
>
>
>
>
>
>
> Jason Dillon <[EMAIL PROTECTED]>
> 11/21/2001 02:09 PM
>
>
> To: [EMAIL PROTECTED]
> cc: [EMAIL PROTECTED]
> Subject:Re: [JBoss-dev] Re: [jboss-docs] Is the build system too
>complicated?
>
>
>
> The executable bit is set on tools/bin/ant. Why dosen't your cvs client
> set
> it when you check it out?
>
> --jason
>
>
> On Wed, 21 Nov 2001 [EMAIL PROTECTED] wrote:
>
> > I do have a slightly off-topic gripe -- as of late, (in the rh
> snapshots),
> > jboss-all/tools/bin/ant has not been executable on UNIX systems (took my
>
> > little mind a while to figure out what was going on). The
> > jboss-all/build/build.sh script has been failing because of it. It
> looks
> > for an executable 'ant', but never finds it (it doesn't have the
> > executable bit set). I can see three possible solutions:
> >
> > 1. Just have the executable bit set on the ant script to start with
> > 2. Change the search() function in build.sh to read like this:
> >
> > search() {
> > search="$*"
> > for d in $search; do
> > ANT_HOME="`pwd`/$d"
> > ANT="$ANT_HOME/bin/ant"
> > # -- Begin modifications
> > # If the file exists at all, attempt to add the executable bit
> > if [ -e "$ANT" ]; then
> > `chmod +x $ANT`
> > fi
> > # -- End modifications
> > if [ -x "$ANT" ]; then
> > # found one
> > echo $ANT_HOME
> > break
> > fi
> > done
> > }
> > #(just added a -e test to see if the file exists, and attempt to make it
>
> > executable so that the next -x test works)
> >
> > 3. Skip looking for an executable ant script -- just make sure it
> exists,
> > and call it with 'sh ant'.
> >
> > -jason
> >
> >
> >
> >
> >
> > Jason Dillon <[EMAIL PROTECTED]>
> > Sent by: [EMAIL PROTECTED]
> > 11/20/2001 09:38 PM
> >
> >
> > To: [EMAIL PROTECTED]
> > cc: [EMAIL PROTECTED]
> > Subject:[JBoss-dev] Re: [jboss-docs] Is the build system
> too complicated?
> >
> >
> >
> > I have not found an easy way to provide this common setup/initialization
>
> > stuff as a resource. Perhaps if I could tell the JAXP parser to read a
> > resource file when parsing this could be done, but that would require
> the
> > Ant entity hooks to be installed to handle that.
> >
> > Perhaps they have done that, perhaps I could sway them todo it... though
>
> > my
> > previous attempts to do so has failed (too much *ucking voting).
> >
> > If you can think of a way please let me know.
> >
> > Thanks for your feedback!
> >
> > --jason
> >
> >
> > On Tue, 20 Nov 2001, David Jencks wrote:
> >
> > > It has often seemed to me that there is substantial duplication
> between
> > the
> > > setup parts of the module level build.xml files. I sure haven't
> figured
> > > out a clue of a way to reduce this, but if it could be done, it might
> > make
> > > the files a little less intimidating. In light of the vast
> improvement
> > > over the preceding build "system", this is a hardly visible quibble.
> > >
> > > david jencks
> > >
> > > On 2001.11.20 16:43:07 -0500 Jason Dillon wrote:
> > > > Please let me know if you think that the build system is too
> > complicated,
> > > > or
> > > > if there is some part of the system which is too complicated.
> > > >
> > >
[JBoss-dev] CVS update: website-snapshots build.xml
User: user57 Date: 01/11/21 14:42:36 Modified:.build.xml Log: o HACKED the build file to make all 'build.sh' and 'tools/bin/ant[Run]' files executable. ! I don't really like it, but don't have much choice. Thanks SUN! Revision ChangesPath 1.2 +41 -17website-snapshots/build.xml Index: build.xml === RCS file: /cvsroot/jboss/website-snapshots/build.xml,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- build.xml 2001/11/20 00:42:20 1.1 +++ build.xml 2001/11/21 22:42:35 1.2 @@ -10,7 +10,7 @@ - + @@ -264,9 +264,9 @@ Exporting CVS modules for snaphots... - + - + - + + + + + + + + + + + + @@ -309,27 +317,43 @@ - + + + + + + + + + + + + - - + + - + + + + + + + + + + + + ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Classloader puzzle
It sure looks like the system (Service libraries) rather than application classloader is being used, despite your code that clearly sets the contextClassLoader to the container's. Have you checked that poaCurrent doesn't change the context classloader and the classloader is really what you expect when you call toObject? david jencks On 2001.11.21 13:04:25 -0500 Francisco Reverbel wrote: > Hi, > > I have a classloader problem in the IIOP container invoker code and would > really appreciate some helpful hints... Classloader wizards: to > understand > the problem you do not have to know anything about CORBA/IIOP, so please > read on! > > The problem only shows up with entity beans. When the IIOP container > invoker creates a CORBA reference for such a bean, it embeds the bean´s > primary key into the CORBA reference. When handling a bean invocation, > the > container invoker extracts the PK from the CORBA reference and passes > this > PK to the container as the first argument of a MethodInvocation. > > A ClassNotFoundException is thrown when the container invoker attempts to > extract the PK from the CORBA reference (got the stack trace below > running > RMH's well-known cabin bean): > > java.lang.ClassNotFoundException: com.titan.cabin.CabinPK > at org.jboss.system.ServiceLibraries.loadClass(ServiceLibraries.java:372) > at org.jboss.system.URLClassLoader.loadClass(URLClassLoader.java:111) > at java.lang.ClassLoader.loadClass(ClassLoader.java:253) > at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:313) > at java.lang.Class.forName0(Native Method) > at java.lang.Class.forName(Class.java:195) > at java.io.ObjectInputStream.resolveClass(ObjectInputStream.java:654) > at java.io.ObjectInputStream.inputClassDescriptor(ObjectInputStream.java:918) > at java.io.ObjectInputStream.readObject(ObjectInputStream.java:366) > at java.io.ObjectInputStream.readObject(ObjectInputStream.java:236) > at java.io.ObjectInputStream.inputObject(ObjectInputStream.java:1186) > at java.io.ObjectInputStream.readObject(ObjectInputStream.java:386) > at java.io.ObjectInputStream.readObject(ObjectInputStream.java:236) > at org.jboss.ejb.CacheKey.readExternal(CacheKey.java:118) > at java.io.ObjectInputStream.inputObject(ObjectInputStream.java:1212) > at java.io.ObjectInputStream.readObject(ObjectInputStream.java:386) > at java.io.ObjectInputStream.readObject(ObjectInputStream.java:236) > at >org.jboss.ejb.plugins.iiop.server.IIOPContainerInvoker.toObject(IIOPContainerInvoker.java:896) > at >org.jboss.ejb.plugins.iiop.server.IIOPContainerInvoker._invoke(IIOPContainerInvoker.java:665) > at org.jacorb.poa.RequestProcessor.invokeOperation(RequestProcessor.java:239) > at org.jacorb.poa.RequestProcessor.process(RequestProcessor.java:456) > at org.jacorb.poa.RequestProcessor.run(RequestProcessor.java:581) > > I've found a way of circumventing the problem, but am not satisfied with > it. Things work if I wrap the PK into a MarshalledObject before embedding > it into the CORBA reference, and do the opposite thing when extracting > the > PK from the reference. Runs fine, but is very slow... The bank test takes > forever to run. > > This code is in org.jboss.ejb.plugins.iiop.server.IIOPContainerInvoker, > under contrib/iiop. Insertion/extraction of the PK is done through the > methods toByteArray() and toObject(). Each of these methods has two > implementations, one of them commented out. The commented out > implementation "solves" the problem in the way described above. > > Suggestions are very welcome! > > Cheers, > > Francisco > > > > > > > > > ___ > Jboss-development mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-development > > ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jboss/src/resources/org/jboss/metadata jbosscmp-jdbc.dtd
User: d_jencks Date: 01/11/21 14:01:30 Added: src/resources/org/jboss/metadata jbosscmp-jdbc.dtd Log: DTD for jboss cmp2 with jdbc. This seems to match what the code does pretty well, but should be considered preliminary. Revision ChangesPath 1.1 jboss/src/resources/org/jboss/metadata/jbosscmp-jdbc.dtd Index: jbosscmp-jdbc.dtd === ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: newsite/src/docs/developers/guide buildsystem-faq.jsp quickstart.jsp
User: user57 Date: 01/11/21 13:47:33 Modified:src/docs/developers/guide buildsystem-faq.jsp quickstart.jsp Log: o truncated quickstart output examples a bit more to make the page a bit more readable o changed [Printable Version] to [Print] and added [Send To Printer] on pritable page o only using on the faq section when terms are most notibly described o changed the main style sheet to use relative font sizes (except for menu and slogan) so that browsers can correctly adujst them to the users preferences (making the text bigger or smaller) * Note: The general text size is a touch larger than before, but is really close to the harded coded 13px and seems to look ok on IE and Mozilla and even in Konqueror, which never seemed to look good at all) Revision ChangesPath 1.4 +17 -8 newsite/src/docs/developers/guide/buildsystem-faq.jsp Index: buildsystem-faq.jsp === RCS file: /cvsroot/jboss/newsite/src/docs/developers/guide/buildsystem-faq.jsp,v retrieving revision 1.3 retrieving revision 1.4 diff -u -r1.3 -r1.4 --- buildsystem-faq.jsp 2001/11/21 07:16:57 1.3 +++ buildsystem-faq.jsp 2001/11/21 21:47:33 1.4 @@ -1,16 +1,23 @@ - - + -Find the answers to the most frequently asked questions about the +Find the answers to the most frequently asked questions (FAQ) about the build system here. +This is a work in progress, so you might not find the exact question or + rather answer that you were looking for. If you have a question which + you believe should be listed here, please send us some + mailto:[EMAIL PROTECTED]";>email letting us know. + +If you are looking for a more compresensive document about the build + system check out the Build System Guide. + @@ -19,7 +26,7 @@ Why can't I use ant directly? - What are hooks? + What are hooks? @@ -48,7 +55,7 @@ [Contents] -What are hooks? +What are hooks? If you have looked through a build/build.xml file, you may have noticed a section dealing with module hooks. Just what are those hooks @@ -67,7 +74,7 @@ actions when those modules were actually exectute, or rather only when they are executed. In comes module hooks. -Hooks are simply targets named in a specific fasion which will +Hooks are simply targets named in a specific fasion which will be executed before and/or after the module is executed (as specified by the module executor... the bit which executes the list modules, and the existance of the target as specified by the hook naming convention). @@ -81,6 +88,8 @@ by the user. This is used to only pull the files which were actually generated by the current module execution. + + For example, consider the difference between the all and most targets. The first should generate all of the possible files that a module has to offer, while the latter should only generate @@ -105,12 +114,12 @@ With any luck that all makes sense to you now. If now just remeber that hooks are used to pull output from modules and generated the release structure for a project. For each module that exists in a - project and generates output, hooks should be defined in the + project and generates output, hooks should be defined in the projects build/build.xml file which copy the generated files from module to project output. If you are a adding support for a new module, or changing an existing - hook, please make sure that you test all of the targets which + hook, please make sure that you test all of the targets which will trigger the hook to be called before commiting the changes. Your fellow developers will appreciate the extra time you took to test that everything works... even if they don't show it =) 1.3 +10 -10newsite/src/docs/developers/guide/quickstart.jsp Index: quickstart.jsp === RCS file: /cvsroot/jboss/newsite/src/docs/developers/guide/quickstart.jsp,v retrieving revision 1.2 retrieving revision 1.3 diff -u -r1.2 -r1.3 --- quickstart.jsp2001/11/21 03:21:09 1.2 +++ quickstart.jsp2001/11/21 21:47:33 1.3 @@ -3,7 +3,7 @@ - + @@ -287,7 +287,7 @@ _configure-modules: [echo] groups: default - [echo] modules: j2ee,naming,server,security,messaging,pool,connector,admin,cluster... + [echo] modules: j2ee,naming,server,security,messaging,pool,connector... _configure-tasks: @@ -301,9 +301,9 @@ ... install-dependencies: - [copy] Copying 3 files to /home/jason/ws/jboss-all/build/output/jbo
[JBoss-dev] CVS update: newsite/src/docs/developers cvs.jsp navigation.jsp slogan.jsp
User: user57
Date: 01/11/21 13:47:33
Modified:src/docs/developers cvs.jsp navigation.jsp slogan.jsp
Log:
o truncated quickstart output examples a bit more to make the page a bit
more readable
o changed [Printable Version] to [Print] and added [Send To Printer] on
pritable page
o only using on the faq section when terms are most notibly
described
o changed the main style sheet to use relative font sizes (except for
menu and slogan) so that browsers can correctly adujst them to the
users preferences (making the text bigger or smaller)
* Note: The general text size is a touch larger than before, but is really
close to the harded coded 13px and seems to look ok on IE and Mozilla and
even in Konqueror, which never seemed to look good at all)
Revision ChangesPath
1.14 +1 -4 newsite/src/docs/developers/cvs.jsp
Index: cvs.jsp
===
RCS file: /cvsroot/jboss/newsite/src/docs/developers/cvs.jsp,v
retrieving revision 1.13
retrieving revision 1.14
diff -u -r1.13 -r1.14
--- cvs.jsp 2001/11/21 03:21:09 1.13
+++ cvs.jsp 2001/11/21 21:47:33 1.14
@@ -1,12 +1,9 @@
-
-
-
-JBoss is Developed Publicly
+
1.13 +2 -2 newsite/src/docs/developers/navigation.jsp
Index: navigation.jsp
===
RCS file: /cvsroot/jboss/newsite/src/docs/developers/navigation.jsp,v
retrieving revision 1.12
retrieving revision 1.13
diff -u -r1.12 -r1.13
--- navigation.jsp2001/11/21 03:21:09 1.12
+++ navigation.jsp2001/11/21 21:47:33 1.13
@@ -52,7 +52,7 @@
- HOME
+ HOME
Our Vision New
For Developers
@@ -165,7 +165,7 @@
<% } else { // if printable %>
-[Normal Version]
+[Back]
[Top]
1.4 +3 -2 newsite/src/docs/developers/slogan.jsp
Index: slogan.jsp
===
RCS file: /cvsroot/jboss/newsite/src/docs/developers/slogan.jsp,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- slogan.jsp2001/11/21 03:21:09 1.3
+++ slogan.jsp2001/11/21 21:47:33 1.4
@@ -11,7 +11,7 @@
<%= request.getParameter("SLOGAN") %>
- [Printable
Version]
+ [Print]
@@ -31,7 +31,8 @@
<%= request.getParameter("SLOGAN") %>
- [Normal Version]
+ [Back]
+ [Send To Printer]
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: newsite/src/docs main.css navigation.jsp slogan.jsp
User: user57
Date: 01/11/21 13:47:32
Modified:src/docs main.css navigation.jsp slogan.jsp
Log:
o truncated quickstart output examples a bit more to make the page a bit
more readable
o changed [Printable Version] to [Print] and added [Send To Printer] on
pritable page
o only using on the faq section when terms are most notibly
described
o changed the main style sheet to use relative font sizes (except for
menu and slogan) so that browsers can correctly adujst them to the
users preferences (making the text bigger or smaller)
* Note: The general text size is a touch larger than before, but is really
close to the harded coded 13px and seems to look ok on IE and Mozilla and
even in Konqueror, which never seemed to look good at all)
Revision ChangesPath
1.10 +20 -48newsite/src/docs/main.css
Index: main.css
===
RCS file: /cvsroot/jboss/newsite/src/docs/main.css,v
retrieving revision 1.9
retrieving revision 1.10
diff -u -r1.9 -r1.10
--- main.css 2001/11/21 20:41:47 1.9
+++ main.css 2001/11/21 21:47:32 1.10
@@ -2,16 +2,15 @@
* CSS Style Sheet for the JBoss website.
*/
-/* $Id: main.css,v 1.9 2001/11/21 20:41:47 user57 Exp $ */
+/* $Id: main.css,v 1.10 2001/11/21 21:47:32 user57 Exp $ */
BODY {
font-family: Arial,serif;
- font-size: 13px;
+ font-size: 0.9em;
color: #00;
}
P, DIV, TBODY, TD, LI, DD {
- font-size: 13px;
color: #00;
}
@@ -33,49 +32,49 @@
clear: both;
font-weight: bold;
font-variant: small-caps;
- letter-spacing: 0.1em;
+ letter-spacing: 0.05em;
}
H1 {
- font-size: 15px;
+ font-size: 1.4em;
}
H2 {
- font-size: 15px;
+ font-size: 1.3em;
}
H3 {
- font-size: 14px;
+ font-size: 1.2em;
}
H4 {
- font-size: 13px;
+ font-size: 1.1em;
}
H5 {
padding-top: 5px;
- font-size: 13px;
+ font-size: 1.0em;
font-weight: normal;
letter-spacing: normal;
}
H6 {
padding-top: 5px;
- font-size: 13px;
+ font-size: 1.0em;
font-variant: normal;
font-weight: normal;
letter-spacing: normal;
}
-.linkhead {
+.linkhead, .linkmenu {
font-size: 12px;
- color: #ff;
font-weight: bold;
}
+.linkhead {
+ color: #ff;
+}
.linkmenu {
- font-size: 12px;
color: #0a0a0a;
- font-weight: bold;
text-decoration: none;
}
.linkmenu:hover {
@@ -84,34 +83,21 @@
}
.head {
- font-size: 14px;
+ font-size: 1.3em;
color: #336633;
font-weight: bold;
- padding-top: 1px;
}
.slogan {
- font-size: 15px;
- color: #338833;
- font-weight: bold;
-}
-
-.text {
- font-size: 13px;
- color: #00;
-}
-
-.link {
- font-size: 13px;
- color: #003399;
+ font-size: 15px;
font-weight: bold;
-}
-.link:hover {
- color: #336633;
+ font-variant: small-caps;
+ letter-spacing: 0.05em;
+ color: #338833;
}
.copy {
- font-size: 11px;
+ font-size: 0.7em;
color: #808080;
}
.copy:hover {
@@ -129,7 +115,7 @@
border-style: solid;
padding: 5px;
font-family: monospace;
- font-size: 12px;
+ font-size: 0.8em;
}
.code {
@@ -147,17 +133,3 @@
.red {
color: red;
}
-
-/* Old stuff we keep around for reference */
-
-a.menu { color: black; text-decoration: none }
-td.black { background-color: #00 }
-td.dark { background-color: #276561 }
-td.light { background-color: #307d77 }
-td.link { font-family: Arial,serif; font-size: 13px; color: #404040; font-weight:
bold; }
-td.newsbody { font-family: Arial,serif; font-size: 13px; color: #00}
-td.newsheader {font-family: Arial,serif; font-size: 14px; color: #336633;
font-weight: bold; }
-/*td.newsheader { color: black; background-color: #C1E0B2 }*/
-td.pageheader { color: white; font-weight: bold; font-size: 14pt; background-color:
#99 }
-td.yellow { background-color: #f4c641 }
-span.red { color: red; font-weight: bold }
1.16 +2 -2 newsite/src/docs/navigation.jsp
Index: navigation.jsp
===
RCS file: /cvsroot/jboss/newsite/src/docs/navigation.jsp,v
retrieving revision 1.15
retrieving revision 1.16
diff -u -r1.15 -r1.16
--- navigation.jsp2001/11/21 03:21:08 1.15
+++ navigation.jsp2001/11/21 21:47:32 1.16
@@ -51,7 +51,7 @@
- HOME
+ HOME
Our Vision New
For Developers
@@ -160,7 +160,7 @@
<% } else { // if printable %>
-[Normal Vers
Re: [JBoss-dev] Developing with JBoss
On 2001.11.21 14:06:58 -0500 danch wrote: > > > Rickard Öberg wrote: > > > > > That's much better, assuming I know where the tmp directory is. And I > > don't, since the name keeps changing for each deployment. :-( > > > Something people have been compaining about roughly forever. I think there are possible problems with trying to always use the same temp dir -- for instance you might have problems removing the old copy before you wanted to start the new one. We might be able to cook up some crazy really hot redeploy whereby the new version is started before the old one is stopped, allowing the requests in process in the old version to complete while new requests go to the new version. What if we made the location of the temp dir visible through an mbean representing the deployment? You could have a little ant task to ask where the war went. david jencks > > > > > ___ > Jboss-development mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-development > > ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [jetty-discuss] Re: [JBoss-dev] JBoss3/Jetty4, Greg/Scott - Optimised intra-container calls & ClassLoaders
On 2001.11.21 13:16:11 -0500 marc fleury wrote: > Sanity, > > thanks professor seems you are on shore with me for once :) > > |> Regardless, I'm going to work on the deployment layer to clean it up > |> and add support unarchived ears. > | > |I the likely case you get to this before I do, my goals for j2ee and > other > |deployment are: > | > | > |- Unify the ServiceLibraries and the Scoped Classloader and always use > the > |result. > > correct. I will do it if you don't. > > |- Separate deployment into > |--autodeploy detection. This will watch directories and on timestamp > change > |undeploy and redeploy. > | > |-Universal deployer. This will > |--determine which classloader to use (system (now ServiceLibraries) or > |application (now Scoped), but these should use the same code base). > This > |may turn into your idea of virtual host. > > Yes, good how are you going to do that? (not completely worked out yet) I think every jboss dd could include a scope (or virtual host) attribute at its top level. If something comes in as a subpackage of something with an explicit scope (ejb-jar or rar or sar in ear), it goes in the same scope. If the scope is missing, if it is a sar or rar, it goes in the system scope, otherwise it gets its own private uniquely named scope. > > how about just moving the scl to sl? scl = scoped classloader sl = service libraries? the only problem there is the > ordering > of lookups which I think differs significantly but... we can look at > using > one structure. If we always set the SL as parent to teh scl then I don't > think we need to hint anything. I wondered, I haven't had the time to try this. > > |--put all accessible classes from the packaging into the extensible > |classloader (I'd use extractPackages from DeployerMBeanSupport) > > woot? what is this? I'm not an expert on this. Looking (quickly) at the j2ee deployer, it looked to me as if there was a lot of effort expended to trace various manifest classpaths etc etc. What would happen if we just put everything in the package (ear, sar, rar, whatever) in one (jboss) URLClassloader? I don't understand what these internal dependency indications are for or the consequences of ignoring them. It might as well go in one classloader, you can't redeploy embedded pieces of a deployment unit anyway. For instance, in the jar in sar, you can now have a sar with a directory structure with classes in it, plus a bunch of jars in it. This gets unpacked into a copy of the original sar, plus copies of the jars unpacked out of the sar. One (JBoss) URLClassloader handles all of them. Would there be any problems doing this for an ear? I asked a few weeks ago and no one answered. > > |--Figure out what order to process the xml dd files, discovered in the > |previous step. > |--Feed the xml files to the appropriate deployers in the appropriate > order. > | > |-individual deployers (Service, RAR, ContainerFactory, J2ee, etc) > |--these will now only process the (xml) dd. > > yes, good > > |-A new deployer for "deployment scripts" that basically contain an > ordered > |list of other things that can be deployed. Although in principal I > think > |all dependencies should be stated explicitly, a script facility would > allow > |deployment of units in a specified order rather than relying on the > random > |order of detection by autodeployer. > | > |Any thoughts? > > Excellent, some sanity finally, excellent professor, excellent. > > |David Jencks > > marcf thanks david jencks > |> > ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: newsite/src/docs binary.jsp
User: starksm Date: 01/11/21 13:13:48 Modified:src/docs binary.jsp Log: Add a link to the 3.0 alpha. Revision ChangesPath 1.14 +10 -6 newsite/src/docs/binary.jsp Index: binary.jsp === RCS file: /cvsroot/jboss/newsite/src/docs/binary.jsp,v retrieving revision 1.13 retrieving revision 1.14 diff -u -r1.13 -r1.14 --- binary.jsp2001/11/07 19:55:36 1.13 +++ binary.jsp2001/11/21 21:13:48 1.14 @@ -1,3 +1,4 @@ + @@ -43,11 +44,17 @@ JBoss 2.4 - - + + Packages Size Date +http://prdownloads.sourceforge.net/jboss/jboss-3.0.0alpha.zip";>JBoss-3.0.0.zip alpha +9951882 +November 21, 2001 + + + http://prdownloads.sourceforge.net/jboss/JBoss-2.4.3.zip";>JBoss-2.4.3.zip 6125514 October 3, 2001 @@ -67,10 +74,7 @@ 10512966 October 30, 2001 - - - - + http://prdownloads.sourceforge.net/jboss/JBoss-2.4.1.zip";>JBoss-2.4.1.zip 8379911 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: newsite/src/docs main.css
User: user57
Date: 01/11/21 12:41:47
Modified:src/docs main.css
Log:
o changed code, command and output styles to use 12px for fonts
Revision ChangesPath
1.9 +2 -4 newsite/src/docs/main.css
Index: main.css
===
RCS file: /cvsroot/jboss/newsite/src/docs/main.css,v
retrieving revision 1.8
retrieving revision 1.9
diff -u -r1.8 -r1.9
--- main.css 2001/11/21 03:21:08 1.8
+++ main.css 2001/11/21 20:41:47 1.9
@@ -2,7 +2,7 @@
* CSS Style Sheet for the JBoss website.
*/
-/* $Id: main.css,v 1.8 2001/11/21 03:21:08 user57 Exp $ */
+/* $Id: main.css,v 1.9 2001/11/21 20:41:47 user57 Exp $ */
BODY {
font-family: Arial,serif;
@@ -129,21 +129,19 @@
border-style: solid;
padding: 5px;
font-family: monospace;
+ font-size: 12px;
}
.code {
color: #00ff55;
- font-size: 10px;
}
.command {
color: #ffee00;
- font-size: 13px;
}
.output {
color: #ee;
- font-size: 10px;
}
.red {
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Re: [JBoss-user] [ANN] JBoss 3.0 alpha is out
Are we going to release the .tgz too? --jason On Wed, 21 Nov 2001, marc fleury wrote: > This is it! > > http://prdownloads.sourceforge.net/jboss/jboss-3.0.0alpha.zip > > we will have the link on www.jboss.org shortly > > so go gentlemen, you know what is in there, clustering, EJB 2.0, sar, cl > microkernel, the future. > > Can you hear those gun shots in the distance? that is us slugging it with > the big boys, that is us beating the crap out them, we believe, we believe > in it, we believe in it more than they do. > > Come help us, we need you. > > We need you to download the stuff, we need you to buy the documentation from > Dain on EJB 2.0 CMP, we need you to test and debug, we need you to strech it > we need you to push it in your own vincinity, this is how we play the game. > Play your part, help us establish JBoss as the Open Monopoly for web-app > server infrastructure. > > we need you to code, pick up your keyboards and join our legions. > > We need you dude. > > And remember we love you too, > > PLgC > marcf > > > Marc Fleury > President > JBoss Group, LLC > > > > ___ > JBoss-user mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-user > ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Classloader puzzle
Hi, On Wed, 21 Nov 2001, marc fleury wrote: > | > |java.lang.ClassNotFoundException: com.titan.cabin.CabinPK > | at > |org.jboss.system.ServiceLibraries.loadClass(ServiceLibraries.java:372) > > This is RH CL working on Service libraries, when we integrate the CL and SCL > this will go away (or so we hope) Hope it will go away, but am not that sure... This problem is around since I started doing the IIOP stuff. It (and the MarshalledObject workaround) precedes RH. Regards, Francisco > > really let me finish the proxy rewrite and then I will move onto packaging > > marcf > | at > |org.jboss.system.URLClassLoader.loadClass(URLClassLoader.java:111) > | at java.lang.ClassLoader.loadClass(ClassLoader.java:253) > | at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:313) > | at java.lang.Class.forName0(Native Method) > | at java.lang.Class.forName(Class.java:195) > | at > |java.io.ObjectInputStream.resolveClass(ObjectInputStream.java:654) > | at > |java.io.ObjectInputStream.inputClassDescriptor(ObjectInputStream.java:918) > | at java.io.ObjectInputStream.readObject(ObjectInputStream.java:366) > | at java.io.ObjectInputStream.readObject(ObjectInputStream.java:236) > | at > |java.io.ObjectInputStream.inputObject(ObjectInputStream.java:1186) > | at java.io.ObjectInputStream.readObject(ObjectInputStream.java:386) > | at java.io.ObjectInputStream.readObject(ObjectInputStream.java:236) > | at org.jboss.ejb.CacheKey.readExternal(CacheKey.java:118) > | at > |java.io.ObjectInputStream.inputObject(ObjectInputStream.java:1212) > | at java.io.ObjectInputStream.readObject(ObjectInputStream.java:386) > | at java.io.ObjectInputStream.readObject(ObjectInputStream.java:236) > | at > |org.jboss.ejb.plugins.iiop.server.IIOPContainerInvoker.toObject(IIO > |PContainerInvoker.java:896) > | at > |org.jboss.ejb.plugins.iiop.server.IIOPContainerInvoker._invoke(IIOP > |ContainerInvoker.java:665) > | at > |org.jacorb.poa.RequestProcessor.invokeOperation(RequestProcessor.java:239) > | at > |org.jacorb.poa.RequestProcessor.process(RequestProcessor.java:456) > | at org.jacorb.poa.RequestProcessor.run(RequestProcessor.java:581) > | > |I've found a way of circumventing the problem, but am not satisfied with > |it. Things work if I wrap the PK into a MarshalledObject before embedding > |it into the CORBA reference, and do the opposite thing when extracting the > |PK from the reference. Runs fine, but is very slow... The bank test takes > |forever to run. > | > |This code is in org.jboss.ejb.plugins.iiop.server.IIOPContainerInvoker, > |under contrib/iiop. Insertion/extraction of the PK is done through the > |methods toByteArray() and toObject(). Each of these methods has two > |implementations, one of them commented out. The commented out > |implementation "solves" the problem in the way described above. > | > |Suggestions are very welcome! > | > |Cheers, > | > |Francisco > | > | > | > | > | > | > | > | > |___ > |Jboss-development mailing list > |[EMAIL PROTECTED] > |https://lists.sourceforge.net/lists/listinfo/jboss-development > > > ___ > Jboss-development mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-development > ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ANN] JBoss 3.0 alpha is out
This is it! http://prdownloads.sourceforge.net/jboss/jboss-3.0.0alpha.zip we will have the link on www.jboss.org shortly so go gentlemen, you know what is in there, clustering, EJB 2.0, sar, cl microkernel, the future. Can you hear those gun shots in the distance? that is us slugging it with the big boys, that is us beating the crap out them, we believe, we believe in it, we believe in it more than they do. Come help us, we need you. We need you to download the stuff, we need you to buy the documentation from Dain on EJB 2.0 CMP, we need you to test and debug, we need you to strech it we need you to push it in your own vincinity, this is how we play the game. Play your part, help us establish JBoss as the Open Monopoly for web-app server infrastructure. we need you to code, pick up your keyboards and join our legions. We need you dude. And remember we love you too, PLgC marcf Marc Fleury President JBoss Group, LLC ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Review the coding standards
The main branch code is getting screwed up again with a mixuture of coding styles. Review the JBoss standards and use them to avoid getting your code reformatted: http://www.jboss.org/developers/guide/codestyle.jsp Scott Stark Chief Technology Officer JBoss Group, LLC ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] CVS update: jbosscx/src/main/org/jboss/resource/connectionmanager ManagedConnectionPoolFactory.java
Standards are here:
http://www.jboss.org/developers/guide/codestyle.jsp
Scott Stark
Chief Technology Officer
JBoss Group, LLC
- Original Message -
From: "Ferguson, Doug" <[EMAIL PROTECTED]>
To: "'Scott M Stark'" <[EMAIL PROTECTED]>;
<[EMAIL PROTECTED]>
Sent: Wednesday, November 21, 2001 12:15 PM
Subject: RE: [JBoss-dev] CVS update:
jbosscx/src/main/org/jboss/resource/connectionmanager
ManagedConnectionPoolFactory.java
> Sorry,
>
> I was merging a change I made to 2.4 and didn't realize the log method had
> changed.
>
> Also, I noticed that you changed formatting. Does JBoss enforce coding
> standards in
> regards to formatting? If so, where can I find this information?
>
> Thanks,
> d.
>
> -Original Message-
> From: Scott M Stark [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, November 21, 2001 1:41 PM
> To: [EMAIL PROTECTED]
> Subject: [JBoss-dev] CVS update:
> jbosscx/src/main/org/jboss/resource/connectionmanager
> ManagedConnectionPoolFactory.java
>
>
> User: starksm
> Date: 01/11/21 11:41:16
>
> Modified:src/main/org/jboss/resource/connectionmanager
> ManagedConnectionPoolFactory.java
> Log:
> Fix the bad check-in by thedug
>
> Revision ChangesPath
> 1.4 +9 -5
>
jbosscx/src/main/org/jboss/resource/connectionmanager/ManagedConnectionPoolF
> actory.java
>
> Index: ManagedConnectionPoolFactory.java
> ===
> RCS file:
>
/cvsroot/jboss/jbosscx/src/main/org/jboss/resource/connectionmanager/Managed
> ConnectionPoolFactory.java,v
> retrieving revision 1.3
> retrieving revision 1.4
> diff -u -r1.3 -r1.4
> --- ManagedConnectionPoolFactory.java 2001/11/21 18:14:51 1.3
> +++ ManagedConnectionPoolFactory.java 2001/11/21 19:41:16 1.4
> @@ -68,14 +68,18 @@
> * object will not be returned to the pool - after this, it is
gone.
> This
> * is called when the pool shrinks, and when the pool is shut
down.
> */
> -public void deleteObject(Object pooledObject) {
> -try{
> +public void deleteObject(Object pooledObject)
> +{
> +try
> +{
>((ManagedConnection)pooledObject).destroy();
> -}catch(ResourceException e) {
> -log.println("Unable to destroy ManagedConnection: "+e);
>}
> +catch(ResourceException e)
> +{
> +log.error("Unable to destroy ManagedConnection: ", e);
> +}
>
> - }
> + }
>
>
>
>
>
>
>
> ___
> Jboss-development mailing list
> [EMAIL PROTECTED]
> https://lists.sourceforge.net/lists/listinfo/jboss-development
>
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] CVS update: jbosscx/src/main/org/jboss/resource/connectionmanager ManagedConnectionPoolFactory.java
Sorry,
I was merging a change I made to 2.4 and didn't realize the log method had
changed.
Also, I noticed that you changed formatting. Does JBoss enforce coding
standards in
regards to formatting? If so, where can I find this information?
Thanks,
d.
-Original Message-
From: Scott M Stark [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, November 21, 2001 1:41 PM
To: [EMAIL PROTECTED]
Subject: [JBoss-dev] CVS update:
jbosscx/src/main/org/jboss/resource/connectionmanager
ManagedConnectionPoolFactory.java
User: starksm
Date: 01/11/21 11:41:16
Modified:src/main/org/jboss/resource/connectionmanager
ManagedConnectionPoolFactory.java
Log:
Fix the bad check-in by thedug
Revision ChangesPath
1.4 +9 -5
jbosscx/src/main/org/jboss/resource/connectionmanager/ManagedConnectionPoolF
actory.java
Index: ManagedConnectionPoolFactory.java
===
RCS file:
/cvsroot/jboss/jbosscx/src/main/org/jboss/resource/connectionmanager/Managed
ConnectionPoolFactory.java,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- ManagedConnectionPoolFactory.java 2001/11/21 18:14:51 1.3
+++ ManagedConnectionPoolFactory.java 2001/11/21 19:41:16 1.4
@@ -68,14 +68,18 @@
* object will not be returned to the pool - after this, it is gone.
This
* is called when the pool shrinks, and when the pool is shut down.
*/
-public void deleteObject(Object pooledObject) {
-try{
+public void deleteObject(Object pooledObject)
+{
+try
+{
((ManagedConnection)pooledObject).destroy();
-}catch(ResourceException e) {
-log.println("Unable to destroy ManagedConnection: "+e);
}
+catch(ResourceException e)
+{
+log.error("Unable to destroy ManagedConnection: ", e);
+}
- }
+ }
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jbosscx/src/main/org/jboss/resource/connectionmanager ManagedConnectionPoolFactory.java
User: starksm
Date: 01/11/21 11:41:16
Modified:src/main/org/jboss/resource/connectionmanager
ManagedConnectionPoolFactory.java
Log:
Fix the bad check-in by thedug
Revision ChangesPath
1.4 +9 -5
jbosscx/src/main/org/jboss/resource/connectionmanager/ManagedConnectionPoolFactory.java
Index: ManagedConnectionPoolFactory.java
===
RCS file:
/cvsroot/jboss/jbosscx/src/main/org/jboss/resource/connectionmanager/ManagedConnectionPoolFactory.java,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- ManagedConnectionPoolFactory.java 2001/11/21 18:14:51 1.3
+++ ManagedConnectionPoolFactory.java 2001/11/21 19:41:16 1.4
@@ -68,14 +68,18 @@
* object will not be returned to the pool - after this, it is gone. This
* is called when the pool shrinks, and when the pool is shut down.
*/
-public void deleteObject(Object pooledObject) {
-try{
+public void deleteObject(Object pooledObject)
+{
+try
+{
((ManagedConnection)pooledObject).destroy();
-}catch(ResourceException e) {
-log.println("Unable to destroy ManagedConnection: "+e);
}
+catch(ResourceException e)
+{
+log.error("Unable to destroy ManagedConnection: ", e);
+}
- }
+ }
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Re: [jboss-docs] Is the build system too complicated?
I see. Let me see if I can fix the snapshots, else I will fix build.sh.
--jason
On Wed, 21 Nov 2001 [EMAIL PROTECTED] wrote:
> Unfortunately, my firewall currently doesn't let me check out via cvs
> directly unless it's over ssh, and I don't have RW access to the
> repository (yet :) -- I've been downloading the nightly snapshots (ugh)
> in .tgz form from http://www.jboss.org/snapshots/. When I untar that, the
> executable bit is not set.(using gnu tar and gzip on linux with the
> command 'tar -xzvf jboss-all.tgz`) Actually, from a few spot checks, it
> looks as if everything comes out '-rw-r--r--', including build.sh itself.
> Yes, I've tried using the -p option with tar to extract permissions
> information -- no effect (I think that's the default anyway, though I'm
> not sure)
>
> -jason
>
>
>
>
>
>
> Jason Dillon <[EMAIL PROTECTED]>
> 11/21/2001 02:09 PM
>
>
> To: [EMAIL PROTECTED]
> cc: [EMAIL PROTECTED]
> Subject:Re: [JBoss-dev] Re: [jboss-docs] Is the build system too
>complicated?
>
>
>
> The executable bit is set on tools/bin/ant. Why dosen't your cvs client
> set
> it when you check it out?
>
> --jason
>
>
> On Wed, 21 Nov 2001 [EMAIL PROTECTED] wrote:
>
> > I do have a slightly off-topic gripe -- as of late, (in the rh
> snapshots),
> > jboss-all/tools/bin/ant has not been executable on UNIX systems (took my
>
> > little mind a while to figure out what was going on). The
> > jboss-all/build/build.sh script has been failing because of it. It
> looks
> > for an executable 'ant', but never finds it (it doesn't have the
> > executable bit set). I can see three possible solutions:
> >
> > 1. Just have the executable bit set on the ant script to start with
> > 2. Change the search() function in build.sh to read like this:
> >
> > search() {
> > search="$*"
> > for d in $search; do
> > ANT_HOME="`pwd`/$d"
> > ANT="$ANT_HOME/bin/ant"
> > # -- Begin modifications
> > # If the file exists at all, attempt to add the executable bit
> > if [ -e "$ANT" ]; then
> > `chmod +x $ANT`
> > fi
> > # -- End modifications
> > if [ -x "$ANT" ]; then
> > # found one
> > echo $ANT_HOME
> > break
> > fi
> > done
> > }
> > #(just added a -e test to see if the file exists, and attempt to make it
>
> > executable so that the next -x test works)
> >
> > 3. Skip looking for an executable ant script -- just make sure it
> exists,
> > and call it with 'sh ant'.
> >
> > -jason
> >
> >
> >
> >
> >
> > Jason Dillon <[EMAIL PROTECTED]>
> > Sent by: [EMAIL PROTECTED]
> > 11/20/2001 09:38 PM
> >
> >
> > To: [EMAIL PROTECTED]
> > cc: [EMAIL PROTECTED]
> > Subject:[JBoss-dev] Re: [jboss-docs] Is the build system
> too complicated?
> >
> >
> >
> > I have not found an easy way to provide this common setup/initialization
>
> > stuff as a resource. Perhaps if I could tell the JAXP parser to read a
> > resource file when parsing this could be done, but that would require
> the
> > Ant entity hooks to be installed to handle that.
> >
> > Perhaps they have done that, perhaps I could sway them todo it... though
>
> > my
> > previous attempts to do so has failed (too much *ucking voting).
> >
> > If you can think of a way please let me know.
> >
> > Thanks for your feedback!
> >
> > --jason
> >
> >
> > On Tue, 20 Nov 2001, David Jencks wrote:
> >
> > > It has often seemed to me that there is substantial duplication
> between
> > the
> > > setup parts of the module level build.xml files. I sure haven't
> figured
> > > out a clue of a way to reduce this, but if it could be done, it might
> > make
> > > the files a little less intimidating. In light of the vast
> improvement
> > > over the preceding build "system", this is a hardly visible quibble.
> > >
> > > david jencks
> > >
> > > On 2001.11.20 16:43:07 -0500 Jason Dillon wrote:
> > > > Please let me know if you think that the build system is too
> > complicated,
> > > > or
> > > > if there is some part of the system which is too complicated.
> > > >
> > > > --jason
> > > >
> > > >
> > > >
> > > > ---
> > > > Subscribe: [EMAIL PROTECTED]
> > > > Unsubscribe:[EMAIL PROTECTED]
> > > > Archive: http://groups.yahoo.com/group/jboss-docs/
> > > >
> > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > >
> > > >
> > > >
> > > >
> > > >
> > >
> > > Yahoo! Groups Sponsor
> -~-->
> > > Universal Inkjet Refill Kit $29.95
> > > Refill any ink cartridge for less!
> > > Includes black and color ink.
> > > http://us.click.yahoo.com/Vv.L9D/MkNDAA/ySSFAA/9rHolB/TM
> > >
> ---
Re: [JBoss-dev] Re: [jboss-docs] Is the build system too complicated?
Unfortunately, my firewall currently doesn't let me check out via cvs
directly unless it's over ssh, and I don't have RW access to the
repository (yet :) -- I've been downloading the nightly snapshots (ugh)
in .tgz form from http://www.jboss.org/snapshots/. When I untar that, the
executable bit is not set.(using gnu tar and gzip on linux with the
command 'tar -xzvf jboss-all.tgz`) Actually, from a few spot checks, it
looks as if everything comes out '-rw-r--r--', including build.sh itself.
Yes, I've tried using the -p option with tar to extract permissions
information -- no effect (I think that's the default anyway, though I'm
not sure)
-jason
Jason Dillon <[EMAIL PROTECTED]>
11/21/2001 02:09 PM
To: [EMAIL PROTECTED]
cc: [EMAIL PROTECTED]
Subject:Re: [JBoss-dev] Re: [jboss-docs] Is the build system too
complicated?
The executable bit is set on tools/bin/ant. Why dosen't your cvs client
set
it when you check it out?
--jason
On Wed, 21 Nov 2001 [EMAIL PROTECTED] wrote:
> I do have a slightly off-topic gripe -- as of late, (in the rh
snapshots),
> jboss-all/tools/bin/ant has not been executable on UNIX systems (took my
> little mind a while to figure out what was going on). The
> jboss-all/build/build.sh script has been failing because of it. It
looks
> for an executable 'ant', but never finds it (it doesn't have the
> executable bit set). I can see three possible solutions:
>
> 1. Just have the executable bit set on the ant script to start with
> 2. Change the search() function in build.sh to read like this:
>
> search() {
> search="$*"
> for d in $search; do
> ANT_HOME="`pwd`/$d"
> ANT="$ANT_HOME/bin/ant"
> # -- Begin modifications
> # If the file exists at all, attempt to add the executable bit
> if [ -e "$ANT" ]; then
> `chmod +x $ANT`
> fi
> # -- End modifications
> if [ -x "$ANT" ]; then
> # found one
> echo $ANT_HOME
> break
> fi
> done
> }
> #(just added a -e test to see if the file exists, and attempt to make it
> executable so that the next -x test works)
>
> 3. Skip looking for an executable ant script -- just make sure it
exists,
> and call it with 'sh ant'.
>
> -jason
>
>
>
>
>
> Jason Dillon <[EMAIL PROTECTED]>
> Sent by: [EMAIL PROTECTED]
> 11/20/2001 09:38 PM
>
>
> To: [EMAIL PROTECTED]
> cc: [EMAIL PROTECTED]
> Subject:[JBoss-dev] Re: [jboss-docs] Is the build system
too complicated?
>
>
>
> I have not found an easy way to provide this common setup/initialization
> stuff as a resource. Perhaps if I could tell the JAXP parser to read a
> resource file when parsing this could be done, but that would require
the
> Ant entity hooks to be installed to handle that.
>
> Perhaps they have done that, perhaps I could sway them todo it... though
> my
> previous attempts to do so has failed (too much *ucking voting).
>
> If you can think of a way please let me know.
>
> Thanks for your feedback!
>
> --jason
>
>
> On Tue, 20 Nov 2001, David Jencks wrote:
>
> > It has often seemed to me that there is substantial duplication
between
> the
> > setup parts of the module level build.xml files. I sure haven't
figured
> > out a clue of a way to reduce this, but if it could be done, it might
> make
> > the files a little less intimidating. In light of the vast
improvement
> > over the preceding build "system", this is a hardly visible quibble.
> >
> > david jencks
> >
> > On 2001.11.20 16:43:07 -0500 Jason Dillon wrote:
> > > Please let me know if you think that the build system is too
> complicated,
> > > or
> > > if there is some part of the system which is too complicated.
> > >
> > > --jason
> > >
> > >
> > >
> > > ---
> > > Subscribe: [EMAIL PROTECTED]
> > > Unsubscribe:[EMAIL PROTECTED]
> > > Archive: http://groups.yahoo.com/group/jboss-docs/
> > >
> > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > >
> > >
> > >
> > >
> > >
> >
> > Yahoo! Groups Sponsor
-~-->
> > Universal Inkjet Refill Kit $29.95
> > Refill any ink cartridge for less!
> > Includes black and color ink.
> > http://us.click.yahoo.com/Vv.L9D/MkNDAA/ySSFAA/9rHolB/TM
> >
-~->
> >
> > ---
> > Subscribe: [EMAIL PROTECTED]
> > Unsubscribe:[EMAIL PROTECTED]
> > Archive: http://groups.yahoo.com/group/jboss-docs/
> >
> > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> >
> >
>
>
> ___
> Jboss-development mailing list
> [EMAIL PROTECTED]
> https://lists.sourceforge.ne
Re: [JBoss-dev] Developing with JBoss
On Wed, 21 Nov 2001, Rickard [ISO-8859-1] Öberg wrote: > What I want to avoid is the copying and packaging that goes on. Do you > have any idea of the time it takes to package 1500 JSP's into a JAR, and > then have that 3-4Mb file copied and exploded into a tmp dir, and this > for every time you make a change in a single JSP? Forever I can tell > you. It adds up to *a lot* of time each day for just redeployment. This is a problem I believe with ant. It adds/updates ALL input files to the jar, when the rule is called. It should only add/update files that are newer than the jar file. Then the building would be fast. For development, I run jboss locally, and symlink from jboss' deploy dir to my build dir. Then, you are only dealing with the rmdir and unpack stuff, when undeploying/deploying. ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Developing with JBoss
Bill Burke wrote: > In our app, we don't use wars and ears, only jars for our EJBs. Our jsps > run off of a directory exposed through Jetty. That way we can easily modify > jsps on the fly. Can't see why anybody would use WARS and EARS unless you > were shipping a product. I've worked in a lot of companies where the production environment was that separated from development - the simpler the package you can hand over the better, since the people who support production environments tend to be on a different planet. -danch ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Developing with JBoss
Rickard Öberg wrote: > > That's much better, assuming I know where the tmp directory is. And I > don't, since the name keeps changing for each deployment. :-( Something people have been compaining about roughly forever. ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Re: [jboss-docs] Is the build system too complicated?
The executable bit is set on tools/bin/ant. Why dosen't your cvs client set
it when you check it out?
--jason
On Wed, 21 Nov 2001 [EMAIL PROTECTED] wrote:
> I do have a slightly off-topic gripe -- as of late, (in the rh snapshots),
> jboss-all/tools/bin/ant has not been executable on UNIX systems (took my
> little mind a while to figure out what was going on). The
> jboss-all/build/build.sh script has been failing because of it. It looks
> for an executable 'ant', but never finds it (it doesn't have the
> executable bit set). I can see three possible solutions:
>
> 1. Just have the executable bit set on the ant script to start with
> 2. Change the search() function in build.sh to read like this:
>
> search() {
> search="$*"
> for d in $search; do
> ANT_HOME="`pwd`/$d"
> ANT="$ANT_HOME/bin/ant"
> # -- Begin modifications
> # If the file exists at all, attempt to add the executable bit
> if [ -e "$ANT" ]; then
> `chmod +x $ANT`
> fi
> # -- End modifications
> if [ -x "$ANT" ]; then
> # found one
> echo $ANT_HOME
> break
> fi
> done
> }
> #(just added a -e test to see if the file exists, and attempt to make it
> executable so that the next -x test works)
>
> 3. Skip looking for an executable ant script -- just make sure it exists,
> and call it with 'sh ant'.
>
> -jason
>
>
>
>
>
> Jason Dillon <[EMAIL PROTECTED]>
> Sent by: [EMAIL PROTECTED]
> 11/20/2001 09:38 PM
>
>
> To: [EMAIL PROTECTED]
> cc: [EMAIL PROTECTED]
> Subject:[JBoss-dev] Re: [jboss-docs] Is the build system too
>complicated?
>
>
>
> I have not found an easy way to provide this common setup/initialization
> stuff as a resource. Perhaps if I could tell the JAXP parser to read a
> resource file when parsing this could be done, but that would require the
> Ant entity hooks to be installed to handle that.
>
> Perhaps they have done that, perhaps I could sway them todo it... though
> my
> previous attempts to do so has failed (too much *ucking voting).
>
> If you can think of a way please let me know.
>
> Thanks for your feedback!
>
> --jason
>
>
> On Tue, 20 Nov 2001, David Jencks wrote:
>
> > It has often seemed to me that there is substantial duplication between
> the
> > setup parts of the module level build.xml files. I sure haven't figured
> > out a clue of a way to reduce this, but if it could be done, it might
> make
> > the files a little less intimidating. In light of the vast improvement
> > over the preceding build "system", this is a hardly visible quibble.
> >
> > david jencks
> >
> > On 2001.11.20 16:43:07 -0500 Jason Dillon wrote:
> > > Please let me know if you think that the build system is too
> complicated,
> > > or
> > > if there is some part of the system which is too complicated.
> > >
> > > --jason
> > >
> > >
> > >
> > > ---
> > > Subscribe: [EMAIL PROTECTED]
> > > Unsubscribe:[EMAIL PROTECTED]
> > > Archive: http://groups.yahoo.com/group/jboss-docs/
> > >
> > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > >
> > >
> > >
> > >
> > >
> >
> > Yahoo! Groups Sponsor -~-->
> > Universal Inkjet Refill Kit $29.95
> > Refill any ink cartridge for less!
> > Includes black and color ink.
> > http://us.click.yahoo.com/Vv.L9D/MkNDAA/ySSFAA/9rHolB/TM
> > -~->
> >
> > ---
> > Subscribe: [EMAIL PROTECTED]
> > Unsubscribe:[EMAIL PROTECTED]
> > Archive: http://groups.yahoo.com/group/jboss-docs/
> >
> > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> >
> >
>
>
> ___
> Jboss-development mailing list
> [EMAIL PROTECTED]
> https://lists.sourceforge.net/lists/listinfo/jboss-development
>
>
>
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Developing with JBoss
> -Original Message- > From: marc fleury [mailto:[EMAIL PROTECTED]] > Sent: Wednesday, November 21, 2001 1:50 PM > To: [EMAIL PROTECTED]; Luke Taylor; > [EMAIL PROTECTED] > Subject: RE: [JBoss-dev] Developing with JBoss > > > |In our app, we don't use wars and ears, only jars for our EJBs. Our jsps > |run off of a directory exposed through Jetty. That way we can > |easily modify > |jsps on the fly. Can't see why anybody would use WARS and EARS > unless you > |were shipping a product. > > this from teh "packaging" lover of 3 days ago ? > > ;=) > Doh! I did say, unless you were shipping a product :) > marcf > | > |> -Original Message- > |> From: [EMAIL PROTECTED] > |> [mailto:[EMAIL PROTECTED]]On Behalf Of Luke > |> Taylor > |> Sent: Wednesday, November 21, 2001 12:59 PM > |> To: [EMAIL PROTECTED] > |> Subject: Re: [JBoss-dev] Developing with JBoss > |> > |> > |> Andrew Scherpbier wrote: > |> > |> > Rickard Öberg wrote: > |> > > |> >> David Jencks wrote: > |> >> > |> >>> How would this help in the least? My understanding is that > |> if you use a > |> >>> directory, the dd is checked for time changes > |> >> > |> >> > |> >> For the auto-deployer, yes. I think I'd actually prefer to > |not use the > |> >> auto-deployer, and instead make an Ant task that does the deploy > |> >> command explicitly. Then there's no need to watch dd's or anything. > |> > > |> > > |> > I ran into the same problem and solved it by running Tomcat 4.0 as a > |> > separate process during development. Since tomcat works just > |fine with > |> > an already unpacked tree for my webapp, I simply modify my > |> JSPs directly > |> > (I have a symbolic link from my webapp development tree to tomcat's > |> > webapps directory.) > |> > |> > |> I remember now raising the same sort of issue during the JBoss training > |> in London. I always end up running a separate web container during > |> development because the turnaround of redeploying due to minor jsp > |> changes is just too frustrating. > |> > |> It's not just about the time for the deployment, which is minimal - if > |> you're working on frontend stuff and just essentially modifying web > |> pages, then you lose your whole session state. If you have a > complicated > |> web application with security, shopping carts etc, and you're > working on > |> the checkout pages, then you have to go through the whole use-case > |> procedure every time you redeploy. If a web container can be configured > |> to pick up the jsp's directly then you only have to reload the page to > |> see a change. > |> > |> The only solution I've found is to run a separate tomcat instance > |> against jboss, with only the web application configured. The > full ear is > |> still deployed in jboss as it would be in production. Configuring > |> security for a separate web container is a bit of a drag. > |> > |> The ideal situation would be if an integrated JBoss/Jetty or > |> JBoss/Tomcat could also be configured to use a separately > configured web > |> application context during development and have the web coantainer spot > |> modifications to JSPs as above. > |> > |> Dunno if this is feasible, pie in the sky or what ... > |> > |> Luke. > |> > |> > |> -- > |> Luke Taylor. Monkey Machine Ltd. > |> PGP Key ID: 0x57E9523Chttp://www.mkeym.com > |> > |> > |> > |> > |> ___ > |> Jboss-development mailing list > |> [EMAIL PROTECTED] > |> https://lists.sourceforge.net/lists/listinfo/jboss-development > |> > | > | > | > |___ > |Jboss-development mailing list > |[EMAIL PROTECTED] > |https://lists.sourceforge.net/lists/listinfo/jboss-development > ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] jboss build failed
=
==THIS IS AN AUTOMATED EMAIL - SEE http://www.lubega.com FOR DETAILS=
=
HERE ARE THE LAST 50 LINES OF THE LOG FILE
os.arch: x86
os.version: 2.4.9-12
compile-classes:
[mkdir] Created dir:
/disk/orig/home/lubega/jbossro/jboss-all/connector/output/classes
[javac] Compiling 48 source files to
/disk/orig/home/lubega/jbossro/jboss-all/connector/output/classes
/disk/orig/home/lubega/jbossro/jboss-all/connector/src/main/org/jboss/resource/adapter/jdbc/local/PreparedStatementInPool.java:30:
warning: setUnicodeStream(int,java.io.InputStream,int) in java.sql.PreparedStatement
has been deprecated
public class PreparedStatementInPool extends StatementInPool implements
PreparedStatement
^
/disk/orig/home/lubega/jbossro/jboss-all/connector/src/main/org/jboss/resource/adapter/jdbc/local/PreparedStatementInPool.java:449:
warning: setUnicodeStream(int,java.io.InputStream,int) in java.sql.PreparedStatement
has been deprecated
impl.setUnicodeStream(parameterIndex, x, length);
^
/disk/orig/home/lubega/jbossro/jboss-all/connector/src/main/org/jboss/resource/adapter/jdbc/local/ResultSetInPool.java:26:
warning: getUnicodeStream(java.lang.String) in java.sql.ResultSet has been deprecated
public class ResultSetInPool implements ResultSet
^
/disk/orig/home/lubega/jbossro/jboss-all/connector/src/main/org/jboss/resource/adapter/jdbc/local/ResultSetInPool.java:26:
warning: getBigDecimal(java.lang.String,int) in java.sql.ResultSet has been deprecated
public class ResultSetInPool implements ResultSet
^
/disk/orig/home/lubega/jbossro/jboss-all/connector/src/main/org/jboss/resource/adapter/jdbc/local/ResultSetInPool.java:26:
warning: getUnicodeStream(int) in java.sql.ResultSet has been deprecated
public class ResultSetInPool implements ResultSet
^
/disk/orig/home/lubega/jbossro/jboss-all/connector/src/main/org/jboss/resource/adapter/jdbc/local/ResultSetInPool.java:26:
warning: getBigDecimal(int,int) in java.sql.ResultSet has been deprecated
public class ResultSetInPool implements ResultSet
^
/disk/orig/home/lubega/jbossro/jboss-all/connector/src/main/org/jboss/resource/adapter/jdbc/local/ResultSetInPool.java:267:
warning: getBigDecimal(int,int) in java.sql.ResultSet has been deprecated
return impl.getBigDecimal(arg0, arg1);
^
/disk/orig/home/lubega/jbossro/jboss-all/connector/src/main/org/jboss/resource/adapter/jdbc/local/ResultSetInPool.java:318:
warning: getBigDecimal(java.lang.String,int) in java.sql.ResultSet has been deprecated
return impl.getBigDecimal(arg0, arg1);
^
/disk/orig/home/lubega/jbossro/jboss-all/connector/src/main/org/jboss/resource/adapter/jdbc/local/ResultSetInPool.java:1643:
warning: getUnicodeStream(int) in java.sql.ResultSet has been deprecated
return impl.getUnicodeStream(arg0);
^
/disk/orig/home/lubega/jbossro/jboss-all/connector/src/main/org/jboss/resource/adapter/jdbc/local/ResultSetInPool.java:1668:
warning: getUnicodeStream(java.lang.String) in java.sql.ResultSet has been deprecated
return impl.getUnicodeStream(arg0);
^
/disk/orig/home/lubega/jbossro/jboss-all/connector/src/main/org/jboss/resource/connectionmanager/ManagedConnectionPoolFactory.java:75:
cannot resolve symbol
symbol : method println (java.lang.String)
location: class org.jboss.logging.Logger
log.println("Unable to destroy ManagedConnection: "+e);
^
1 error
10 warnings
BUILD FAILED
/disk/orig/home/lubega/jbossro/jboss-all/connector/build.xml:320: Compile failed,
messages should have been provided.
Total time: 3 minutes 11 seconds
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Developing with JBoss
|In our app, we don't use wars and ears, only jars for our EJBs. Our jsps |run off of a directory exposed through Jetty. That way we can |easily modify |jsps on the fly. Can't see why anybody would use WARS and EARS unless you |were shipping a product. this from teh "packaging" lover of 3 days ago ? ;=) marcf | |> -Original Message- |> From: [EMAIL PROTECTED] |> [mailto:[EMAIL PROTECTED]]On Behalf Of Luke |> Taylor |> Sent: Wednesday, November 21, 2001 12:59 PM |> To: [EMAIL PROTECTED] |> Subject: Re: [JBoss-dev] Developing with JBoss |> |> |> Andrew Scherpbier wrote: |> |> > Rickard Öberg wrote: |> > |> >> David Jencks wrote: |> >> |> >>> How would this help in the least? My understanding is that |> if you use a |> >>> directory, the dd is checked for time changes |> >> |> >> |> >> For the auto-deployer, yes. I think I'd actually prefer to |not use the |> >> auto-deployer, and instead make an Ant task that does the deploy |> >> command explicitly. Then there's no need to watch dd's or anything. |> > |> > |> > I ran into the same problem and solved it by running Tomcat 4.0 as a |> > separate process during development. Since tomcat works just |fine with |> > an already unpacked tree for my webapp, I simply modify my |> JSPs directly |> > (I have a symbolic link from my webapp development tree to tomcat's |> > webapps directory.) |> |> |> I remember now raising the same sort of issue during the JBoss training |> in London. I always end up running a separate web container during |> development because the turnaround of redeploying due to minor jsp |> changes is just too frustrating. |> |> It's not just about the time for the deployment, which is minimal - if |> you're working on frontend stuff and just essentially modifying web |> pages, then you lose your whole session state. If you have a complicated |> web application with security, shopping carts etc, and you're working on |> the checkout pages, then you have to go through the whole use-case |> procedure every time you redeploy. If a web container can be configured |> to pick up the jsp's directly then you only have to reload the page to |> see a change. |> |> The only solution I've found is to run a separate tomcat instance |> against jboss, with only the web application configured. The full ear is |> still deployed in jboss as it would be in production. Configuring |> security for a separate web container is a bit of a drag. |> |> The ideal situation would be if an integrated JBoss/Jetty or |> JBoss/Tomcat could also be configured to use a separately configured web |> application context during development and have the web coantainer spot |> modifications to JSPs as above. |> |> Dunno if this is feasible, pie in the sky or what ... |> |> Luke. |> |> |> -- |> Luke Taylor. Monkey Machine Ltd. |> PGP Key ID: 0x57E9523Chttp://www.mkeym.com |> |> |> |> |> ___ |> Jboss-development mailing list |> [EMAIL PROTECTED] |> https://lists.sourceforge.net/lists/listinfo/jboss-development |> | | | |___ |Jboss-development mailing list |[EMAIL PROTECTED] |https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [jetty-discuss] Re: [JBoss-dev] JBoss3/Jetty4, Greg/Scott - Optimised intra-container calls & ClassLoaders
|When will this new CL stuff come in ? all the code is out, what is missing is SCL/SL integration that david and i are talking about. |Jetty's WAR CL will be a child of the one passed us by |the J2EEDeployer in |Thread.currentThread().getContextClassLoader(). | |What should it's behaviour be ? | |1. DELEGATE up, then look in WAR (Java2 compliant) yes this will work |2. Look in WAR, then DELEGATE up (sandboxing WebApp) if you want this for spec then go and use the RH cl natively once it is built. |3. neither of the above. use 1 for now (our alpha is out) and then move to 2 when we got the stuff done. |1. Optimisation code currently works - but containers |classes are used in preference to WAR's yes, the solution to this is scoped usage in CL |2. WAR's classes used, but optimisation code currently |fails. yes, to me this is more important. |3. ??? | |Now a bit of an ill-informed rant: | |Since using a Remote EJB interface is more restrictive |than using a Local one (everything must be |serialisable) I can guarantee that whilst a Local |interface may not work remotely, a Remote interface |will always work locally... | |Still with me ? | |Therefore, why shouldn't my choice be to always use a |Remote interface if I can, thus keeping all my options |open and why shouldn't JBoss be able to apply exactly |the same optimisations that it would to a local |LocalInterface deployment to my local RemoteInterface |deployment ? correct we will optimize for you, Local stuff really has applications in EJB CMP2.0 but apart from that you don't buy much on JBoss except portability to Weblogic but why would you ? |In fact why do I need a Local interface at all ? my point exactly. Again it enforces colocation which is important in CMP2.0 dumb in web apps. |I don't want the interface to mandate my geographical |location. I want all that done by a hot-pluggable right, you got it. |implementation which will go as fast as it can in any |given deployment scenario. yes which we do. |If anyone wants me I'm on holiday, with my EJB2.0 spec |trying to understand what the hell's going on. | |Peace and Love, yes, case closed, marcf | |Jules | |P.S. | |Be gentle - it's been a hard day... | | --- marc fleury <[EMAIL PROTECTED]> wrote: > |If |they are not optimised, RH currently throws an |> |exception and the test fails. So this needs fixing. |> |> RH is still using the old CL structure for the apps, |> when we default to the |> scope stuff, this class of problems will go away, we |> will need to integrate |> them with Jetty in teh 2 fashions explained above |> (actually the rh cl |> integration native due to teh silly spec |> requirements). |> | |> |I have heard of, but know nothing about, local |> |interfaces. I would have thought though, that they |> |must still be constrained by the basic laws of |> Class |> |"assignability" - i.e. if the way the ClassLoaders |> is |> |> that is correct, see my previous mail, orthogonal |> issues, rickard is |> sleeping this morning |> |> |Anyway, JBoss attempts to implement optimised |> |intra-container calls through the standard |> interface. |> |Are you suggesting we should throw all this code |> away |> |now? It would save me a lot of effort. |> |> are you kidding? as you know that won't simplify the |> problem and forcing |> people to use "local" stuff in EJB is still weird in |> my mind. WORA/SMCHORA |> sentimental bull. |> |> |Otherwise this brings us straight back to the same |> |problem. ClassLoader architecture which is what I |> need |> |to coordinate between JBoss and Jetty in order to |> pass |> |the testsuite. |> |> yes, correct. |> |> marcf| |> |Jules |> | |> | |> |> /Rickard |> |> |> |> -- |> |> Rickard Öberg |> |> |> | |> |__ |> |Do You Yahoo!? |> |Everything you'll ever need on one web page from |> News and Sport to |> |Email and Music Charts |> |http://uk.my.yahoo.com |> | |> | Yahoo! Groups Sponsor |> | |> |For the latest information about Jetty, please see |> http://jetty.mortbay. |> | |> |Your use of Yahoo! Groups is subject to |> http://docs.yahoo.com/info/terms/ |> | |> | |> |> |> ___ |> Jboss-development mailing list |> [EMAIL PROTECTED] |> |https://lists.sourceforge.net/lists/listinfo/jboss-development | |__ |Do You Yahoo!? |Everything you'll ever need on one web page from News and Sport to |Email and Music Charts |http://uk.my.yahoo.com | | Yahoo! Groups Sponsor -~--> |Universal Inkjet Refill Kit $29.95 |Refill any ink cartridge for less! |Includes black and color ink. |http://us.click.yahoo.com/1_Y1qC/MkNDAA/ySSFAA/CefplB/TM |-~-> | |For the latest information about Jetty, please see http://jetty.mortbay. | |Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/ |
RE: [JBoss-dev] Classloader puzzle
| |java.lang.ClassNotFoundException: com.titan.cabin.CabinPK | at |org.jboss.system.ServiceLibraries.loadClass(ServiceLibraries.java:372) This is RH CL working on Service libraries, when we integrate the CL and SCL this will go away (or so we hope) really let me finish the proxy rewrite and then I will move onto packaging marcf | at |org.jboss.system.URLClassLoader.loadClass(URLClassLoader.java:111) | at java.lang.ClassLoader.loadClass(ClassLoader.java:253) | at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:313) | at java.lang.Class.forName0(Native Method) | at java.lang.Class.forName(Class.java:195) | at |java.io.ObjectInputStream.resolveClass(ObjectInputStream.java:654) | at |java.io.ObjectInputStream.inputClassDescriptor(ObjectInputStream.java:918) | at java.io.ObjectInputStream.readObject(ObjectInputStream.java:366) | at java.io.ObjectInputStream.readObject(ObjectInputStream.java:236) | at |java.io.ObjectInputStream.inputObject(ObjectInputStream.java:1186) | at java.io.ObjectInputStream.readObject(ObjectInputStream.java:386) | at java.io.ObjectInputStream.readObject(ObjectInputStream.java:236) | at org.jboss.ejb.CacheKey.readExternal(CacheKey.java:118) | at |java.io.ObjectInputStream.inputObject(ObjectInputStream.java:1212) | at java.io.ObjectInputStream.readObject(ObjectInputStream.java:386) | at java.io.ObjectInputStream.readObject(ObjectInputStream.java:236) | at |org.jboss.ejb.plugins.iiop.server.IIOPContainerInvoker.toObject(IIO |PContainerInvoker.java:896) | at |org.jboss.ejb.plugins.iiop.server.IIOPContainerInvoker._invoke(IIOP |ContainerInvoker.java:665) | at |org.jacorb.poa.RequestProcessor.invokeOperation(RequestProcessor.java:239) | at |org.jacorb.poa.RequestProcessor.process(RequestProcessor.java:456) | at org.jacorb.poa.RequestProcessor.run(RequestProcessor.java:581) | |I've found a way of circumventing the problem, but am not satisfied with |it. Things work if I wrap the PK into a MarshalledObject before embedding |it into the CORBA reference, and do the opposite thing when extracting the |PK from the reference. Runs fine, but is very slow... The bank test takes |forever to run. | |This code is in org.jboss.ejb.plugins.iiop.server.IIOPContainerInvoker, |under contrib/iiop. Insertion/extraction of the PK is done through the |methods toByteArray() and toObject(). Each of these methods has two |implementations, one of them commented out. The commented out |implementation "solves" the problem in the way described above. | |Suggestions are very welcome! | |Cheers, | |Francisco | | | | | | | | |___ |Jboss-development mailing list |[EMAIL PROTECTED] |https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Developing with JBoss
|I remember now raising the same sort of issue during the JBoss training |in London. I always end up running a separate web container during Yes I remember, |development because the turnaround of redeploying due to minor jsp |changes is just too frustrating. | |It's not just about the time for the deployment, which is minimal - if |you're working on frontend stuff and just essentially modifying web |pages, then you lose your whole session state. If you have a complicated |web application with security, shopping carts etc, and you're working on |the checkout pages, then you have to go through the whole use-case |procedure every time you redeploy. If a web container can be configured |to pick up the jsp's directly then you only have to reload the page to |see a change. I see |The only solution I've found is to run a separate tomcat instance |against jboss, with only the web application configured. The full ear is |still deployed in jboss as it would be in production. Configuring |security for a separate web container is a bit of a drag. that is a good point |The ideal situation would be if an integrated JBoss/Jetty or |JBoss/Tomcat could also be configured to use a separately configured web |application context during development and have the web coantainer spot |modifications to JSPs as above. Hey Rickard and you both have RW, use it! don't let poor David do all the work. You know what you want, code what you want |Dunno if this is feasible, pie in the sky or what ... sure, marcf | |Luke. | | |-- | Luke Taylor. Monkey Machine Ltd. | PGP Key ID: 0x57E9523Chttp://www.mkeym.com | | | | |___ |Jboss-development mailing list |[EMAIL PROTECTED] |https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [jetty-discuss] Re: [JBoss-dev] JBoss3/Jetty4, Greg/Scott - Optimised intra-container calls & ClassLoaders
|the reason it remains is that most implementations have such |a huge problem getting the class loader scopes to work at |all, that making it configurable is just impossible. |(believe it or not!) look we are going to put it out with Jetty and when you see other vendors starting to support the same, you will know they stole it from here. marcf | |john | |> |> |Yes, the app programmer needs to know about classloading. Bug.. |> |feature.. bug... feature.. which'll it be? :-) |> |> 100% bug |> |> |On the one hand, having straight-forward classloading makes it easy to |> |develop a web-app. On the other hand, having sandboxed classloading |> |makes the web-app more self-contained and portable, since they don't |> |rely on the surrounding server to provide any of its classes. |> |> bullshit |> |> marcf |> |> |> For the latest information about Jetty, please see http://jetty.mortbay. |> |> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/ | | Yahoo! Groups Sponsor -~--> |Universal Inkjet Refill Kit $29.95 |Refill any ink cartridge for less! |Includes black and color ink. |http://us.click.yahoo.com/Vv.L9D/MkNDAA/ySSFAA/CefplB/TM |-~-> | |For the latest information about Jetty, please see http://jetty.mortbay. | |Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/ | | ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Developing with JBoss
David Jencks wrote: >>Could work, but I'd rather do something portable. Plus, it's non-trivial >>to break up our app (it's rather monolithic). Plus, several EAR's -> >>several web deployments -> several web contexts -> no session sharing -> >>no good. >> > > You're talking about a non-portable development environment anyway aren't > you? Putting pieces of your 1500 jsps in different files might not be so > hard??? Yes, I am talking about non-portable development environment. When I'm done, I package an EAR anyway. And no, again, splitting the app into multiple WAR's is Not An Option. > ??? > Are you proposing to change a copy of the source for the jsp rather than > the source?? That's what I thought *you* meant... which would be dumb.. > Cmon, you change your jsp in src, deployment of change consists of copying > changed file to temp deployment directory?? That's much better, assuming I know where the tmp directory is. And I don't, since the name keeps changing for each deployment. :-( > You rebuild from source, you > pick up the changes. Only problem I see is automatically finding the > correct tmp deploy directory again after redeployment of the whole ear. Exactly. Paaain.. /R -- Rickard Öberg ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] jboss build failed
=
==THIS IS AN AUTOMATED EMAIL - SEE http://www.lubega.com FOR DETAILS=
=
HERE ARE THE LAST 50 LINES OF THE LOG FILE
os.arch: x86
os.version: 2.4.9-12
compile-classes:
[mkdir] Created dir:
/disk/orig/home/lubega/jbossro/jboss-all/connector/output/classes
[javac] Compiling 48 source files to
/disk/orig/home/lubega/jbossro/jboss-all/connector/output/classes
/disk/orig/home/lubega/jbossro/jboss-all/connector/src/main/org/jboss/resource/adapter/jdbc/local/PreparedStatementInPool.java:30:
warning: setUnicodeStream(int,java.io.InputStream,int) in java.sql.PreparedStatement
has been deprecated
public class PreparedStatementInPool extends StatementInPool implements
PreparedStatement
^
/disk/orig/home/lubega/jbossro/jboss-all/connector/src/main/org/jboss/resource/adapter/jdbc/local/PreparedStatementInPool.java:449:
warning: setUnicodeStream(int,java.io.InputStream,int) in java.sql.PreparedStatement
has been deprecated
impl.setUnicodeStream(parameterIndex, x, length);
^
/disk/orig/home/lubega/jbossro/jboss-all/connector/src/main/org/jboss/resource/adapter/jdbc/local/ResultSetInPool.java:26:
warning: getUnicodeStream(java.lang.String) in java.sql.ResultSet has been deprecated
public class ResultSetInPool implements ResultSet
^
/disk/orig/home/lubega/jbossro/jboss-all/connector/src/main/org/jboss/resource/adapter/jdbc/local/ResultSetInPool.java:26:
warning: getBigDecimal(java.lang.String,int) in java.sql.ResultSet has been deprecated
public class ResultSetInPool implements ResultSet
^
/disk/orig/home/lubega/jbossro/jboss-all/connector/src/main/org/jboss/resource/adapter/jdbc/local/ResultSetInPool.java:26:
warning: getUnicodeStream(int) in java.sql.ResultSet has been deprecated
public class ResultSetInPool implements ResultSet
^
/disk/orig/home/lubega/jbossro/jboss-all/connector/src/main/org/jboss/resource/adapter/jdbc/local/ResultSetInPool.java:26:
warning: getBigDecimal(int,int) in java.sql.ResultSet has been deprecated
public class ResultSetInPool implements ResultSet
^
/disk/orig/home/lubega/jbossro/jboss-all/connector/src/main/org/jboss/resource/adapter/jdbc/local/ResultSetInPool.java:267:
warning: getBigDecimal(int,int) in java.sql.ResultSet has been deprecated
return impl.getBigDecimal(arg0, arg1);
^
/disk/orig/home/lubega/jbossro/jboss-all/connector/src/main/org/jboss/resource/adapter/jdbc/local/ResultSetInPool.java:318:
warning: getBigDecimal(java.lang.String,int) in java.sql.ResultSet has been deprecated
return impl.getBigDecimal(arg0, arg1);
^
/disk/orig/home/lubega/jbossro/jboss-all/connector/src/main/org/jboss/resource/adapter/jdbc/local/ResultSetInPool.java:1643:
warning: getUnicodeStream(int) in java.sql.ResultSet has been deprecated
return impl.getUnicodeStream(arg0);
^
/disk/orig/home/lubega/jbossro/jboss-all/connector/src/main/org/jboss/resource/adapter/jdbc/local/ResultSetInPool.java:1668:
warning: getUnicodeStream(java.lang.String) in java.sql.ResultSet has been deprecated
return impl.getUnicodeStream(arg0);
^
/disk/orig/home/lubega/jbossro/jboss-all/connector/src/main/org/jboss/resource/connectionmanager/ManagedConnectionPoolFactory.java:75:
cannot resolve symbol
symbol : method println (java.lang.String)
location: class org.jboss.logging.Logger
log.println("Unable to destroy ManagedConnection: "+e);
^
1 error
10 warnings
BUILD FAILED
/disk/orig/home/lubega/jbossro/jboss-all/connector/build.xml:320: Compile failed,
messages should have been provided.
Total time: 3 minutes 10 seconds
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Developing with JBoss
In our app, we don't use wars and ears, only jars for our EJBs. Our jsps run off of a directory exposed through Jetty. That way we can easily modify jsps on the fly. Can't see why anybody would use WARS and EARS unless you were shipping a product. > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]]On Behalf Of Luke > Taylor > Sent: Wednesday, November 21, 2001 12:59 PM > To: [EMAIL PROTECTED] > Subject: Re: [JBoss-dev] Developing with JBoss > > > Andrew Scherpbier wrote: > > > Rickard Öberg wrote: > > > >> David Jencks wrote: > >> > >>> How would this help in the least? My understanding is that > if you use a > >>> directory, the dd is checked for time changes > >> > >> > >> For the auto-deployer, yes. I think I'd actually prefer to not use the > >> auto-deployer, and instead make an Ant task that does the deploy > >> command explicitly. Then there's no need to watch dd's or anything. > > > > > > I ran into the same problem and solved it by running Tomcat 4.0 as a > > separate process during development. Since tomcat works just fine with > > an already unpacked tree for my webapp, I simply modify my > JSPs directly > > (I have a symbolic link from my webapp development tree to tomcat's > > webapps directory.) > > > I remember now raising the same sort of issue during the JBoss training > in London. I always end up running a separate web container during > development because the turnaround of redeploying due to minor jsp > changes is just too frustrating. > > It's not just about the time for the deployment, which is minimal - if > you're working on frontend stuff and just essentially modifying web > pages, then you lose your whole session state. If you have a complicated > web application with security, shopping carts etc, and you're working on > the checkout pages, then you have to go through the whole use-case > procedure every time you redeploy. If a web container can be configured > to pick up the jsp's directly then you only have to reload the page to > see a change. > > The only solution I've found is to run a separate tomcat instance > against jboss, with only the web application configured. The full ear is > still deployed in jboss as it would be in production. Configuring > security for a separate web container is a bit of a drag. > > The ideal situation would be if an integrated JBoss/Jetty or > JBoss/Tomcat could also be configured to use a separately configured web > application context during development and have the web coantainer spot > modifications to JSPs as above. > > Dunno if this is feasible, pie in the sky or what ... > > Luke. > > > -- > Luke Taylor. Monkey Machine Ltd. > PGP Key ID: 0x57E9523Chttp://www.mkeym.com > > > > > ___ > Jboss-development mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-development > ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Optimized Servlet->EJB calls.../ Local Interfaces
my understanding of local interfaces is portability in the optimization. Period. It is then heavily used in the 2.0 cmp to enforce collocation of dependencies. marcf |-Original Message- |From: [EMAIL PROTECTED] |[mailto:[EMAIL PROTECTED]]On Behalf Of Dain |Sundstrom |Sent: Wednesday, November 21, 2001 11:11 AM |To: 'Julian Gosnell'; [EMAIL PROTECTED] |Subject: RE: [JBoss-dev] Optimized Servlet->EJB calls.../ Local |Interfaces | | |> |> Now that I've read about Local interfaces, I can see |> that they are the natural choice for communications |> between beans in the same Container. |> |> Is it being suggested that I should use these for |> servlet/jsp->ejb communication ? | |Yep, but that is in the J2EE spec not the Servlet or ejb specs. | |> If not then we still need to support optimized calls |> between the web and ejb container. it is these that |> fail between Jetty and JBoss. |> |> If so, then something is wrong. Do I really have to |> decide the architecture of my AppServer before I write |> my App? It should be transparent. | |The trick is if you think you may want in VM optimized calls you can not |rely on the pass by value style method calls. This means don't use Object |parameters as temp variables. Later on you can switch to Local interfaces |for speed. | |Alternatively, you could start with local interfaces and then switch to |remote if you want to move the web layer to another vm. This has a similar |issue regarding by reference parameters. You can't rely on updated |parameters being reflected in the web layer. | |> If optimized calls between web-container and |> ejb-container are to be supported, then I still have |> ClassLoader issues to be resolved. | |Whey have to be in an EAR with class-path refs properly set in the |manifest.mf file. This is documented in either the J2EE spec or the EJB |spec. | |-dain | |___ |Jboss-development mailing list |[EMAIL PROTECTED] |https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [jetty-discuss] Re: [JBoss-dev] JBoss3/Jetty4, Greg/Scott - Optimised intra-container calls & ClassLoaders
OK, I'll risk one more posting... Marc, You seem to understand where I am coming from ! When will this new CL stuff come in ? Jetty's WAR CL will be a child of the one passed us by the J2EEDeployer in Thread.currentThread().getContextClassLoader(). What should it's behaviour be ? 1. DELEGATE up, then look in WAR (Java2 compliant) 2. Look in WAR, then DELEGATE up (sandboxing WebApp) 3. neither of the above. I have mentioned the problems associated with each approach already in this thread. 1. Optimisation code currently works - but containers classes are used in preference to WAR's 2. WAR's classes used, but optimisation code currently fails. 3. ??? Now a bit of an ill-informed rant: Since using a Remote EJB interface is more restrictive than using a Local one (everything must be serialisable) I can guarantee that whilst a Local interface may not work remotely, a Remote interface will always work locally... Still with me ? Therefore, why shouldn't my choice be to always use a Remote interface if I can, thus keeping all my options open and why shouldn't JBoss be able to apply exactly the same optimisations that it would to a local LocalInterface deployment to my local RemoteInterface deployment ? In fact why do I need a Local interface at all ? I don't want the interface to mandate my geographical location. I want all that done by a hot-pluggable implementation which will go as fast as it can in any given deployment scenario. It's all just a dynamic proxy anyway - isn't it ? I'm putting on my flame-proof jacket right now... If anyone wants me I'm on holiday, with my EJB2.0 spec trying to understand what the hell's going on. Peace and Love, Jules P.S. Be gentle - it's been a hard day... --- marc fleury <[EMAIL PROTECTED]> wrote: > |If they are not optimised, RH currently throws an > |exception and the test fails. So this needs fixing. > > RH is still using the old CL structure for the apps, > when we default to the > scope stuff, this class of problems will go away, we > will need to integrate > them with Jetty in teh 2 fashions explained above > (actually the rh cl > integration native due to teh silly spec > requirements). > | > |I have heard of, but know nothing about, local > |interfaces. I would have thought though, that they > |must still be constrained by the basic laws of > Class > |"assignability" - i.e. if the way the ClassLoaders > is > > that is correct, see my previous mail, orthogonal > issues, rickard is > sleeping this morning > > |Anyway, JBoss attempts to implement optimised > |intra-container calls through the standard > interface. > |Are you suggesting we should throw all this code > away > |now? It would save me a lot of effort. > > are you kidding? as you know that won't simplify the > problem and forcing > people to use "local" stuff in EJB is still weird in > my mind. WORA/SMCHORA > sentimental bull. > > |Otherwise this brings us straight back to the same > |problem. ClassLoader architecture which is what I > need > |to coordinate between JBoss and Jetty in order to > pass > |the testsuite. > > yes, correct. > > marcf| > |Jules > | > | > |> /Rickard > |> > |> -- > |> Rickard Öberg > |> > | > |__ > |Do You Yahoo!? > |Everything you'll ever need on one web page from > News and Sport to > |Email and Music Charts > |http://uk.my.yahoo.com > | > | Yahoo! Groups Sponsor > -~--> > |Universal Inkjet Refill Kit $29.95 > |Refill any ink cartridge for less! > |Includes black and color ink. > |http://us.click.yahoo.com/XwUZwC/MkNDAA/ySSFAA/CefplB/TM > |-~-> > | > |For the latest information about Jetty, please see > http://jetty.mortbay. > | > |Your use of Yahoo! Groups is subject to > http://docs.yahoo.com/info/terms/ > | > | > > > ___ > Jboss-development mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-development __ Do You Yahoo!? Everything you'll ever need on one web page from News and Sport to Email and Music Charts http://uk.my.yahoo.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Developing with JBoss
Luke Taylor wrote: > It's not just about the time for the deployment, which is minimal - if > you're working on frontend stuff and just essentially modifying web > pages, then you lose your whole session state. If you have a complicated > web application with security, shopping carts etc, and you're working on > the checkout pages, then you have to go through the whole use-case > procedure every time you redeploy. If a web container can be configured > to pick up the jsp's directly then you only have to reload the page to > see a change. One solution is to use a template engine such as Velocity instead of JSP. Then there's no problem whatsoever: just have it pick up changed templates from your /src dev directory. That is, if you have a choice in the first place. /Rickard -- Rickard Öberg ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [jetty-discuss] Re: [JBoss-dev] JBoss3/Jetty4, Greg/Scott - Optimised intra-container calls & ClassLoaders
Sanity, thanks professor seems you are on shore with me for once :) |> Regardless, I'm going to work on the deployment layer to clean it up |> and add support unarchived ears. | |I the likely case you get to this before I do, my goals for j2ee and other |deployment are: | | |- Unify the ServiceLibraries and the Scoped Classloader and always use the |result. correct. I will do it if you don't. |- Separate deployment into |--autodeploy detection. This will watch directories and on timestamp change |undeploy and redeploy. | |-Universal deployer. This will |--determine which classloader to use (system (now ServiceLibraries) or |application (now Scoped), but these should use the same code base). This |may turn into your idea of virtual host. Yes, good how are you going to do that? how about just moving the scl to sl? the only problem there is the ordering of lookups which I think differs significantly but... we can look at using one structure. If we always set the SL as parent to teh scl then I don't think we need to hint anything. |--put all accessible classes from the packaging into the extensible |classloader (I'd use extractPackages from DeployerMBeanSupport) woot? what is this? |--Figure out what order to process the xml dd files, discovered in the |previous step. |--Feed the xml files to the appropriate deployers in the appropriate order. | |-individual deployers (Service, RAR, ContainerFactory, J2ee, etc) |--these will now only process the (xml) dd. yes, good |-A new deployer for "deployment scripts" that basically contain an ordered |list of other things that can be deployed. Although in principal I think |all dependencies should be stated explicitly, a script facility would allow |deployment of units in a specified order rather than relying on the random |order of detection by autodeployer. | |Any thoughts? Excellent, some sanity finally, excellent professor, excellent. |David Jencks marcf |> |> - Original Message - |> From: "Rickard Öberg" <[EMAIL PROTECTED]> |> To: "Scott M Stark" <[EMAIL PROTECTED]> |> Cc: <[EMAIL PROTECTED]>; |> <[EMAIL PROTECTED]> |> Sent: Wednesday, November 21, 2001 3:30 AM |> Subject: Re: [jetty-discuss] Re: [JBoss-dev] JBoss3/Jetty4, Greg/Scott - |> Optimised intra-container calls & ClassLoaders |> |> |> > Scott M Stark wrote: |> > |> > > That is correct. The packaging required to run under a 2.2 servlet |> container |> > > is inconsistent with that required to run under a 2.3 container due |> to |> the |> > > change in the web container class loader behavior. I see this with |> Tomcat |> > > 3.2.3 |> > > vs Tomcat 4.0. Really, the only time this shows up is for JSP pages |> trying |> > > to access EJBs. |> > |> > |> > Well, *all* access from the web container to EJB's (i.e. servlets too) |> > need to be aware of these changes. We ran into this the other day, and |> > the fix was to bundle crimson.jar into our app too (i.e. not rely on it |> > being available). |> > |> > Now, because of all this bundling going on, the EAR quickly grows HUGE, |> > which means that for development you want hot-deploy on exploded EAR |> > files. Unfortunately JBoss does not currently support that, so the |> > cycling time becomes somewhat excessive. :-( |> > |> > /Rickard |> > |> > -- |> > Rickard Öberg |> > |> > |> > ___ |> > Jboss-development mailing list |> > [EMAIL PROTECTED] |> > https://lists.sourceforge.net/lists/listinfo/jboss-development |> > |> |> |> ___ |> Jboss-development mailing list |> [EMAIL PROTECTED] |> https://lists.sourceforge.net/lists/listinfo/jboss-development |> |> | | Yahoo! Groups Sponsor -~--> |Universal Inkjet Refill Kit $29.95 |Refill any ink cartridge for less! |Includes black and color ink. |http://us.click.yahoo.com/XwUZwC/MkNDAA/ySSFAA/CefplB/TM |-~-> | |For the latest information about Jetty, please see http://jetty.mortbay. | |Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/ | | ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jbosscx/src/main/org/jboss/resource/connectionmanager ManagedConnectionPoolFactory.java
User: thedug
Date: 01/11/21 10:14:51
Modified:src/main/org/jboss/resource/connectionmanager
ManagedConnectionPoolFactory.java
Log:
destroy() should actually close the connection so that the tcp connection isn't
left open.
Revision ChangesPath
1.3 +16 -0
jbosscx/src/main/org/jboss/resource/connectionmanager/ManagedConnectionPoolFactory.java
Index: ManagedConnectionPoolFactory.java
===
RCS file:
/cvsroot/jboss/jbosscx/src/main/org/jboss/resource/connectionmanager/ManagedConnectionPoolFactory.java,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- ManagedConnectionPoolFactory.java 2001/09/11 18:38:58 1.2
+++ ManagedConnectionPoolFactory.java 2001/11/21 18:14:51 1.3
@@ -63,6 +63,22 @@
pool = null;
}
+/**
+ * Permanently closes an object, after it is removed from the pool. The
+ * object will not be returned to the pool - after this, it is gone. This
+ * is called when the pool shrinks, and when the pool is shut down.
+ */
+public void deleteObject(Object pooledObject) {
+try{
+((ManagedConnection)pooledObject).destroy();
+}catch(ResourceException e) {
+log.println("Unable to destroy ManagedConnection: "+e);
+}
+
+ }
+
+
+
/**
* Creates a new ManagedConnection with the specified parameters.
*
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] JBoss 2.4.3 classloading problems
Ok, a perfect example of a user with UI problems in the CL behaviour. |I'm using the bundled JBoss-2.4.3_Tomcat-4.0 package, and trying to use |Castor from one of my session beans to turn an entity bean's data into an |XML string (no JDO-thang, just plain marshalling to xml). I get a Castor |exception about not finding my own beans' data, and after a few hours of |web-searching, I've found a few references mentioning this as a classloader |problem. The session beans have the MBean Cl as parent which has visibility on the castor classes. Something else is going on. marcf | |According to the web sources, Castor (laying in jboss/lib/ext) is loaded by |a different classloader, which is being used for my EJBs; therefore Castor |is unable to see/use my beans, so I'm unable to use Castor. | |Is there any workaround or solution for the problem? | |Thanks, |Christopher |-- |.Digital.Yearning.for.Networked.Assassination.and.Xenocide | |___ |Jboss-development mailing list |[EMAIL PROTECTED] |https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [jetty-discuss] Re: [JBoss-dev] JBoss3/Jetty4, Greg/Scott - Optimised intra-container calls & ClassLoaders
|Please don't call it "Jetty's non-compliant strategy"! We are just |relunctanly following the servlet spec!-) Ok tis Jetty's compliant non-compliant strategy how's that? marcf | | |> Trouble is, this fails the isAssignableFrom() check in |> JRMPContainerInvoker.invoke() and blows up. | | |What class does it fail for? Can't you remove that class/jar from |the webapplication, so that it can only be loaded from the EJB classloader? | |cheers | | |-- |Greg Wilkins<[EMAIL PROTECTED]> GB Phone: +44-(0)7092063462 |Mort Bay Consulting Australia and UK.Mbl Phone: +61-(0)4 17786631 |http://www.mortbay.com AU Phone: +61-(0)2 98107029 | | | Yahoo! Groups Sponsor -~--> |Universal Inkjet Refill Kit $29.95 |Refill any ink cartridge for less! |Includes black and color ink. |http://us.click.yahoo.com/r9F0cB/MkNDAA/ySSFAA/CefplB/TM |-~-> | |For the latest information about Jetty, please see http://jetty.mortbay. | |Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/ | | ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [jetty-discuss] Re: [JBoss-dev] JBoss3/Jetty4, Greg/Scott - Optimised intra-container calls & ClassLoaders
|OK - So I will go with Jetty's non-compliant |ClassLoader strategy. Calls will only be delegated |upwards if they cannot be satisfied locally. then use the scope cl architecture. I will help you there. |Trouble is, this fails the isAssignableFrom() check in |JRMPContainerInvoker.invoke() and blows up. won't |So, I shall check my code in (hopefully tonight) and |hope that some kind soul removes all the |optimise/serialise code soon. yeah, consider it done. |I guess that wraps it all up. | |Greg, mate, you got away this time ! as far as I am concerned, you are all talking BS on some distant isolated island. I am on shore waiving my arms going "guys ! guys! here! here ! look promised land!" but you all can't hear me and pat yourselves on the back nonetheless, I'll send magic help! marcf | |Cheers, all, | | |Jules | | |P.S. | |Still mystified about how local interfaces solve all |this "magically" - I shall have to read up on it | |> - Original Message - |> From: "Greg Wilkins" <[EMAIL PROTECTED]> |> To: <[EMAIL PROTECTED]> |> Cc: "Rickard Öberg" <[EMAIL PROTECTED]>; |> <[EMAIL PROTECTED]> |> Sent: Wednesday, November 21, 2001 2:58 AM |> Subject: Re: [jetty-discuss] Re: [JBoss-dev] |> JBoss3/Jetty4, Greg/Scott - |> Optimised intra-container calls & ClassLoaders |> |> |> > Julian Gosnell wrote: |> > |> > > Your just putting the onus on the Application |> > > programmer to work around shortcomings in the |> Server - |> > > I think. |> > |> > |> > But that is exactly the problem with the |> non-compliant |> > class loader as specified by the 2.3 servlet spec. |> > |> > Because it advocates a "application developer |> knows better" |> > approach, then the application developer get's |> total control |> > over non-system classes - so they have to set it |> up right, |> > else it does not work. |> > |> > If they want to share class instances between the |> servlet |> > container and the EJB container, then they MUST |> prevent |> > the servlet context from seeing those classes, |> else |> > it will load it's own copy of them. |> > |> > There is absolutely no programatic way to |> distinguish |> > between a webapp that has included a class on |> purpose to |> > override an "old" version in the container, or due |> to |> > an unknowing programmer being overzealous with |> their |> > classpath. |> > |> > |> > > Perhaps someone will make a pronouncement on HOW |> > > JBoss/Jetty SHOULD behave here. Then we can |> figure out |> > > how to achieve this behaviour. |> > |> > |> > Unfortunatley the default behaviour should be what |> the |> > specification says and the 2.3 servlet spec |> definitely |> > requires the non java2 compliant class loader. |> > |> > Somebody should check the full J2EE specification |> to |> > see exactly what it specifies, as there is no |> guarantee |> > that the specs are compatible in this regards. |> > |> > I'm in two minds about providing the compliant |> loader |> > options - while I think it is the simple and |> correct |> > way to go, it may just complicate things to |> propogate |> > a non standard mode. Maybe EJB developers are |> just going |> > to have to be a lot more careful with their |> classpaths |> > now??? |> > |> > And this includes the developers of the JBoss web |> integration |> > test suite. Their should not be classes in the |> webapp |> > context that are also available via the EJB |> container or |> > system class loader. |> > |> > Regards |> > |> |> |> |> Yahoo! Groups Sponsor |> |> For the latest information about Jetty, please see |> http://jetty.mortbay. |> |> Your use of Yahoo! Groups is subject to |> http://docs.yahoo.com/info/terms/ |> |> | |__ |Do You Yahoo!? |Everything you'll ever need on one web page from News and Sport to |Email and Music Charts |http://uk.my.yahoo.com | | Yahoo! Groups Sponsor -~--> |Universal Inkjet Refill Kit $29.95 |Refill any ink cartridge for less! |Includes black and color ink. |http://us.click.yahoo.com/r9F0cB/MkNDAA/ySSFAA/CefplB/TM |-~-> | |For the latest information about Jetty, please see http://jetty.mortbay. | |Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/ | | ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [jetty-discuss] Re: [JBoss-dev] JBoss3/Jetty4, Greg/Scott - Optimised intra-container calls & ClassLoaders
|> Well, I believe the real fix is to make the EJB-loader use the "non |> Java2" class-loading style as well, i.e. force people to bundle in JAR's |> that the app is going to use. That is the ultimate way to get things |> portable, and to be able to allow different running apps use different |> versions of, say, JAXP. | | |I have to say that I reluctantly agree. Now that the non-compliant |loader cat is out of the bag, we have no choice but to force users |to be disciplined about their bundling of jars. For consistency this RH Scoped classloader to the rescue. I still need to fix the jung stuff for the ordering and overwritting but we are there. |should apply the the EJB container as well as teh servlet container |(again assuming the J2EE spec does agree with the 2.3 servlet spec). | | |However, I would like to suggest a change in the language. We should |try to force the users to NOT include jars that they can reasonably |expect the container will provide. You don't force your users jack, you give them a simple and consistent behavior as we are trying with RH and then it works and when it doesnt they know why. UI design at its simplest. |JAXP is a key example, as I think it was the driver for the change |in the specification. Users wanted richer XML parsing for their |web applications than was provided by their containers. Hence they |now have the ability to write an application that is dependant on |a specific JAXP version and/or provider by bundling the jars for |them. But now almost all container provide recent versions |of JAXP with good parser implementations, so applications that |include jaxp.jar and xerces.jar are probably fixing a problem that |no longer exists! | |So our language should encourage users to NOT include their own |versions of jars unless absolutely necessary for a particular |deployment. Somewhere is should be clearly stated that the BYO |implementation approach is bad because: Relax, when teh code is out and we see how it behaves then we can put forth recommendations of usage. Right now the UI recommendations are based on monolythic cl approaches. Give me time. | + Firstly and foremost, it is just bad OO design. You should be |dependant on the interfaces not the implementations. Sure it |allows you to get around short term deployment issues, but it is |a much better approach to try to get your container to provide |the APIs and implementations that you need. | | + Including your own jars does create confusion and problems in |calling "local" interfaces that actually cross classloader boundaries. |The new priority inversion of classloader increases the chances |of cross loader calls being made. | | + There is a significant cost in terms of memory and serialization. | | + Applications that provide their own implementations of common |libraries cannot receive the benefits of updating the container. |If new versions are deployed by a container that fix bugs or |improve performance, these are not used by applications that |have included their own jars. | | + The logical extension of shipping your own jaxp.jar in order |to be portable is to ship your own swing, your own jboss and |eventually your own JVM, OS and hardware :-) | |Thus I think the documentation should not be written so that |developers think "I better include jaxp.jar xerces.jar as it is |better to be safe than sorry". | |Rather they should be encouraged to not include these jars, in |the knowledge that IF a problem does occur with a particular |container AND they can't update that container, only then should |they can fix that deployment by including specific versions of the |jars they need. | |Finally users should be given the confidence that their containers |of choice are open and being actively maintained, thus new APIs and |implementations should rapidly become available in the containers. | |regards my own eyes are rolling when I read the points. You are still carrying knowledge of the container to the user as developer. Bad UI design. Better than including CL dependencies in XML but still kind of silly. THIS IS PACKAGING KNOWLEDGE, i.e. it is worth about 0.2c marcf | | |-- |Greg Wilkins<[EMAIL PROTECTED]> GB Phone: +44-(0)7092063462 |Mort Bay Consulting Australia and UK.Mbl Phone: +61-(0)4 17786631 |http://www.mortbay.com AU Phone: +61-(0)2 98107029 | | | Yahoo! Groups Sponsor -~--> |Universal Inkjet Refill Kit $29.95 |Refill any ink cartridge for less! |Includes black and color ink. |http://us.click.yahoo.com/1_Y1qC/MkNDAA/ySSFAA/CefplB/TM |-~-> | |For the latest information about Jetty, please see http://jetty.mortbay. | |Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/ | | ___ Jboss-development mailing list [EMAI
[JBoss-dev] Classloader puzzle
Hi, I have a classloader problem in the IIOP container invoker code and would really appreciate some helpful hints... Classloader wizards: to understand the problem you do not have to know anything about CORBA/IIOP, so please read on! The problem only shows up with entity beans. When the IIOP container invoker creates a CORBA reference for such a bean, it embeds the bean´s primary key into the CORBA reference. When handling a bean invocation, the container invoker extracts the PK from the CORBA reference and passes this PK to the container as the first argument of a MethodInvocation. A ClassNotFoundException is thrown when the container invoker attempts to extract the PK from the CORBA reference (got the stack trace below running RMH's well-known cabin bean): java.lang.ClassNotFoundException: com.titan.cabin.CabinPK at org.jboss.system.ServiceLibraries.loadClass(ServiceLibraries.java:372) at org.jboss.system.URLClassLoader.loadClass(URLClassLoader.java:111) at java.lang.ClassLoader.loadClass(ClassLoader.java:253) at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:313) at java.lang.Class.forName0(Native Method) at java.lang.Class.forName(Class.java:195) at java.io.ObjectInputStream.resolveClass(ObjectInputStream.java:654) at java.io.ObjectInputStream.inputClassDescriptor(ObjectInputStream.java:918) at java.io.ObjectInputStream.readObject(ObjectInputStream.java:366) at java.io.ObjectInputStream.readObject(ObjectInputStream.java:236) at java.io.ObjectInputStream.inputObject(ObjectInputStream.java:1186) at java.io.ObjectInputStream.readObject(ObjectInputStream.java:386) at java.io.ObjectInputStream.readObject(ObjectInputStream.java:236) at org.jboss.ejb.CacheKey.readExternal(CacheKey.java:118) at java.io.ObjectInputStream.inputObject(ObjectInputStream.java:1212) at java.io.ObjectInputStream.readObject(ObjectInputStream.java:386) at java.io.ObjectInputStream.readObject(ObjectInputStream.java:236) at org.jboss.ejb.plugins.iiop.server.IIOPContainerInvoker.toObject(IIOPContainerInvoker.java:896) at org.jboss.ejb.plugins.iiop.server.IIOPContainerInvoker._invoke(IIOPContainerInvoker.java:665) at org.jacorb.poa.RequestProcessor.invokeOperation(RequestProcessor.java:239) at org.jacorb.poa.RequestProcessor.process(RequestProcessor.java:456) at org.jacorb.poa.RequestProcessor.run(RequestProcessor.java:581) I've found a way of circumventing the problem, but am not satisfied with it. Things work if I wrap the PK into a MarshalledObject before embedding it into the CORBA reference, and do the opposite thing when extracting the PK from the reference. Runs fine, but is very slow... The bank test takes forever to run. This code is in org.jboss.ejb.plugins.iiop.server.IIOPContainerInvoker, under contrib/iiop. Insertion/extraction of the PK is done through the methods toByteArray() and toObject(). Each of these methods has two implementations, one of them commented out. The commented out implementation "solves" the problem in the way described above. Suggestions are very welcome! Cheers, Francisco ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [jetty-discuss] Re: [JBoss-dev] JBoss3/Jetty4, Greg/Scott - Optimised intra-container calls & ClassLoaders
|-Original Message- |From: Scott M Stark [mailto:[EMAIL PROTECTED]] |That is correct. The packaging required to run under a 2.2 servlet |container |is inconsistent with that required to run under a 2.3 container due to the |change in the web container class loader behavior. I see this with Tomcat |3.2.3 |vs Tomcat 4.0. Really, the only time this shows up is for JSP pages trying |to access EJBs. Due to a problem/feature of the 2.2 version of jasper this |required duplicate classes to be placed into the war. This is no longer |required in the 2.3 spec version, and in fact now causes a problem. | Right ok, then let's integrate with Jetty and leave everybody else behind, buhbye! |The whole optimized call thing is going to change along with the class |loader architecture. It is also unnecessary due to the introduction of |local interfaces. that I don't agree see my previous mails marcf | |- Original Message - |From: "Greg Wilkins" <[EMAIL PROTECTED]> |To: <[EMAIL PROTECTED]> |Cc: "Rickard Öberg" <[EMAIL PROTECTED]>; |<[EMAIL PROTECTED]> |Sent: Wednesday, November 21, 2001 2:58 AM |Subject: Re: [jetty-discuss] Re: [JBoss-dev] JBoss3/Jetty4, Greg/Scott - |Optimised intra-container calls & ClassLoaders | | |> Julian Gosnell wrote: |> |> > Your just putting the onus on the Application |> > programmer to work around shortcomings in the Server - |> > I think. |> |> |> But that is exactly the problem with the non-compliant |> class loader as specified by the 2.3 servlet spec. |> |> Because it advocates a "application developer knows better" |> approach, then the application developer get's total control |> over non-system classes - so they have to set it up right, |> else it does not work. |> |> If they want to share class instances between the servlet |> container and the EJB container, then they MUST prevent |> the servlet context from seeing those classes, else |> it will load it's own copy of them. |> |> There is absolutely no programatic way to distinguish |> between a webapp that has included a class on purpose to |> override an "old" version in the container, or due to |> an unknowing programmer being overzealous with their |> classpath. |> |> |> > Perhaps someone will make a pronouncement on HOW |> > JBoss/Jetty SHOULD behave here. Then we can figure out |> > how to achieve this behaviour. |> |> |> Unfortunatley the default behaviour should be what the |> specification says and the 2.3 servlet spec definitely |> requires the non java2 compliant class loader. |> |> Somebody should check the full J2EE specification to |> see exactly what it specifies, as there is no guarantee |> that the specs are compatible in this regards. |> |> I'm in two minds about providing the compliant loader |> options - while I think it is the simple and correct |> way to go, it may just complicate things to propogate |> a non standard mode. Maybe EJB developers are just going |> to have to be a lot more careful with their classpaths |> now??? |> |> And this includes the developers of the JBoss web integration |> test suite. Their should not be classes in the webapp |> context that are also available via the EJB container or |> system class loader. |> |> Regards |> | | | | Yahoo! Groups Sponsor -~--> |Universal Inkjet Refill Kit $29.95 |Refill any ink cartridge for less! |Includes black and color ink. |http://us.click.yahoo.com/bAmslD/MkNDAA/ySSFAA/CefplB/TM |-~-> | |For the latest information about Jetty, please see http://jetty.mortbay. | |Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/ | | ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [jetty-discuss] Re: [JBoss-dev] JBoss3/Jetty4, Greg/Scott - Optimised intra-container calls & ClassLoaders
|Well, *all* access from the web container to EJB's (i.e. servlets too) |need to be aware of these changes. We ran into this the other day, and |the fix was to bundle crimson.jar into our app too (i.e. not rely on it |being available). | |Now, because of all this bundling going on, the EAR quickly grows HUGE, |which means that for development you want hot-deploy on exploded EAR |files. Unfortunately JBoss does not currently support that, so the |cycling time becomes somewhat excessive. :-( The problem is not the support of exploded dirs, the problem is the packaging. DO YOU GUYS REALIZE WE ARE TALKING ABOUT AVATARS OF THE PACKAGING AND HOW IT TIES INTO CLASSLOADING? they are artificial problems, the cl arch of RH (forthcoming) will magically make them dissapear. or so we hope. marcf | |/Rickard | |-- |Rickard Öberg | | | Yahoo! Groups Sponsor -~--> |Universal Inkjet Refill Kit $29.95 |Refill any ink cartridge for less! |Includes black and color ink. |http://us.click.yahoo.com/bAmslD/MkNDAA/ySSFAA/CefplB/TM |-~-> | |For the latest information about Jetty, please see http://jetty.mortbay. | |Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/ | | ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [jetty-discuss] Re: [JBoss-dev] JBoss3/Jetty4, Greg/Scott - Optimised intra-container calls & ClassLoaders
|Julian Gosnell wrote: | |>>What goes into 3? |>> |> |> Your site's e.g. Logging classes etc.. which every app |> uses. You figure it's cheaper to load them once into |> the apps parent CL, than many times, into every app. | | |Ok, good point. I believe Tomcat handles this by using a "common" |directory that contains libraries that should be available to webapps |and server alike. right that would be the integration of the scope of apps and the RH cl microkernel. See previous mails. |Well, if you want to use local interfaces, then yes, you have to be |careful with how you package classes. They need to be in the EAR. right same problem, it doesn't fix the packaging. Orthogonal issues. |I'm torn. The optimization was introduced because there was no standard |way to do it, but now that it does... well.. what's the point? Backward |compatibility with people who have written apps that takes advantage of |it, yes, but that should be it. All new apps should use local interfaces |if you want local behaviour. Local behaviour in EJB: 1- same problem with the classes (values etc) that NEED to be shared between stacks 2- again 1 means that we still have the same problem but if we didn't EJB is not the only stack, we need that generic so that all apps/mbean work, an EJB only solution wouldn't work. marcf | |/Rickard | |-- |Rickard Öberg | | | Yahoo! Groups Sponsor -~--> |Universal Inkjet Refill Kit $29.95 |Refill any ink cartridge for less! |Includes black and color ink. |http://us.click.yahoo.com/XwUZwC/MkNDAA/ySSFAA/CefplB/TM |-~-> | |For the latest information about Jetty, please see http://jetty.mortbay. | |Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/ | | ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Developing with JBoss
Andrew Scherpbier wrote: > Rickard Öberg wrote: > >> David Jencks wrote: >> >>> How would this help in the least? My understanding is that if you use a >>> directory, the dd is checked for time changes >> >> >> For the auto-deployer, yes. I think I'd actually prefer to not use the >> auto-deployer, and instead make an Ant task that does the deploy >> command explicitly. Then there's no need to watch dd's or anything. > > > I ran into the same problem and solved it by running Tomcat 4.0 as a > separate process during development. Since tomcat works just fine with > an already unpacked tree for my webapp, I simply modify my JSPs directly > (I have a symbolic link from my webapp development tree to tomcat's > webapps directory.) I remember now raising the same sort of issue during the JBoss training in London. I always end up running a separate web container during development because the turnaround of redeploying due to minor jsp changes is just too frustrating. It's not just about the time for the deployment, which is minimal - if you're working on frontend stuff and just essentially modifying web pages, then you lose your whole session state. If you have a complicated web application with security, shopping carts etc, and you're working on the checkout pages, then you have to go through the whole use-case procedure every time you redeploy. If a web container can be configured to pick up the jsp's directly then you only have to reload the page to see a change. The only solution I've found is to run a separate tomcat instance against jboss, with only the web application configured. The full ear is still deployed in jboss as it would be in production. Configuring security for a separate web container is a bit of a drag. The ideal situation would be if an integrated JBoss/Jetty or JBoss/Tomcat could also be configured to use a separately configured web application context during development and have the web coantainer spot modifications to JSPs as above. Dunno if this is feasible, pie in the sky or what ... Luke. -- Luke Taylor. Monkey Machine Ltd. PGP Key ID: 0x57E9523Chttp://www.mkeym.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [jetty-discuss] Re: [JBoss-dev] JBoss3/Jetty4, Greg/Scott - Optimised intra-container calls & ClassLoaders
|If they are not optimised, RH currently throws an |exception and the test fails. So this needs fixing. RH is still using the old CL structure for the apps, when we default to the scope stuff, this class of problems will go away, we will need to integrate them with Jetty in teh 2 fashions explained above (actually the rh cl integration native due to teh silly spec requirements). | |I have heard of, but know nothing about, local |interfaces. I would have thought though, that they |must still be constrained by the basic laws of Class |"assignability" - i.e. if the way the ClassLoaders is that is correct, see my previous mail, orthogonal issues, rickard is sleeping this morning |Anyway, JBoss attempts to implement optimised |intra-container calls through the standard interface. |Are you suggesting we should throw all this code away |now? It would save me a lot of effort. are you kidding? as you know that won't simplify the problem and forcing people to use "local" stuff in EJB is still weird in my mind. WORA/SMCHORA sentimental bull. |Otherwise this brings us straight back to the same |problem. ClassLoader architecture which is what I need |to coordinate between JBoss and Jetty in order to pass |the testsuite. yes, correct. marcf| |Jules | | |> /Rickard |> |> -- |> Rickard Öberg |> | |__ |Do You Yahoo!? |Everything you'll ever need on one web page from News and Sport to |Email and Music Charts |http://uk.my.yahoo.com | | Yahoo! Groups Sponsor -~--> |Universal Inkjet Refill Kit $29.95 |Refill any ink cartridge for less! |Includes black and color ink. |http://us.click.yahoo.com/XwUZwC/MkNDAA/ySSFAA/CefplB/TM |-~-> | |For the latest information about Jetty, please see http://jetty.mortbay. | |Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/ | | ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [jetty-discuss] Re: [JBoss-dev] JBoss3/Jetty4, Greg/Scott - Optimised intra-container calls & ClassLoaders
|Well, I believe the real fix is to make the EJB-loader use the "non |Java2" class-loading style as well, i.e. force people to bundle in JAR's |that the app is going to use. That is the ultimate way to get things |portable, and to be able to allow different running apps use different |versions of, say, JAXP. no see my previous mail and the proper use of scopes, Rickard READ that code :) |What goes into 3? | |1 and 2, yes. That must be available from the classloader. I am curious to know myself. |Absolutely. And that is indeed the case, or you'll get funky classcast |exceptions (we had those a couple of days ago and had muchos fun trying |to figure out what happened). the scope stuff will ELIMINATE this class of problems ALTOGETHER I GUARANTEE IT. |Well, what is the need to optimize them anymore, really? I mean, use |local interfaces and that's it. The proxies don't have to do the check, |since it will be implied from what type of proxies that are used. Hey, |it's portable too. You still need to share the interfaces used by the different classes, the use of local interfaces doesn't impact the problem at all. marcf | |-- |Rickard Öberg | | | Yahoo! Groups Sponsor -~--> |Universal Inkjet Refill Kit $29.95 |Refill any ink cartridge for less! |Includes black and color ink. |http://us.click.yahoo.com/XwUZwC/MkNDAA/ySSFAA/CefplB/TM |-~-> | |For the latest information about Jetty, please see http://jetty.mortbay. | |Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/ | | ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [jetty-discuss] Re: [JBoss-dev] JBoss3/Jetty4, Greg/Scott - Optimised intra-container calls & ClassLoaders
|But that is exactly the problem with the non-compliant |class loader as specified by the 2.3 servlet spec. agreed, |Because it advocates a "application developer knows better" |approach, then the application developer get's total control |over non-system classes - so they have to set it up right, |else it does not work. it is dumb, but then it is not Craig, it is the spec! wow, time to reset on SUN, the king is crazy, |If they want to share class instances between the servlet |container and the EJB container, then they MUST prevent |the servlet context from seeing those classes, else |it will load it's own copy of them. Depends on how you use CL. |There is absolutely no programatic way to distinguish |between a webapp that has included a class on purpose to |override an "old" version in the container, or due to |an unknowing programmer being overzealous with their |classpath. the system classpath one is always going to throw off the appserver. Overriding the class with the requirement of the scope declaration (which is then in effect used as versioning) is the way to do this. The logic behind this is really a UI one. 1-provide consistent behavior of the CL and classpath. too many developers default to adding stuff in the classpath when it doesn't work. Not good, dangerous. Used 90% of the time though. 2- provide, but hide, advanced tools such as the scope to allow developers to include several versions of the same class in one VM, USED RARELY. It is simple UI logic, UI being the ease of deployment for the developer in this case. |Unfortunatley the default behaviour should be what the |specification says and the 2.3 servlet spec definitely |requires the non java2 compliant class loader. Then it rules out the delegation (which is the simplest, and frankly it is a silly requirement) then the only solution is the native sharing of CL in RH due to integration. Interestingly enough, the spec KILLS the clone integration and forces "monolythic" stacks as the only optimized integration. DON'T LET KIDS WRITE SPECS THEY ARE GOING TO POOPOO THEIR PAMPERS. Interestingly enough it goes against their clone push, they probably don't even see the problem :) |Somebody should check the full J2EE specification to |see exactly what it specifies, as there is no guarantee |that the specs are compatible in this regards. I am saying they arent, but it is a minor point really. |I'm in two minds about providing the compliant loader |options - while I think it is the simple and correct |way to go, it may just complicate things to propogate |a non standard mode. Maybe EJB developers are just going |to have to be a lot more careful with their classpaths |now??? sure :) but the problem applies to everyone. We want to be able to integrate stacks and you need that visibility on the classes across stacks. Not just the system cl which is the dumb problem but even the packaging across ears and who sees what. Really the simplest is the RH cl that will still be compliant with scope declaration but will buy us the rest. I really think this is the bullet solution. marcf | |And this includes the developers of the JBoss web integration |test suite. Their should not be classes in the webapp |context that are also available via the EJB container or |system class loader. | |Regards | | | | |-- |Greg Wilkins<[EMAIL PROTECTED]> GB Phone: +44-(0)7092063462 |Mort Bay Consulting Australia and UK.Mbl Phone: +61-(0)4 17786631 |http://www.mortbay.com AU Phone: +61-(0)2 98107029 | | | Yahoo! Groups Sponsor -~--> |Universal Inkjet Refill Kit $29.95 |Refill any ink cartridge for less! |Includes black and color ink. |http://us.click.yahoo.com/1_Y1qC/MkNDAA/ySSFAA/CefplB/TM |-~-> | |For the latest information about Jetty, please see http://jetty.mortbay. | |Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/ | | ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [jetty-discuss] Re: [JBoss-dev] JBoss3/Jetty4, Greg/Scott - Optimised intra-container calls & ClassLoaders
|1. Serialised. intra-vm calls should cause a suitable |WARNING - not an ERROR. if we look for speed and you make a mistake on the CL, this is deep I want your face to be splattered in blood as you stared at the raw engine. Integration is the key, I give you 2 options, both will work with the RH cl. |I think, after a good 5 mins deep consideration, that |the App server should provide the following classes to |a SANDBOXED application. | |1. J2SE x.x |2. J2EE y.y |3. Common local infrastructure | |Since the app is sandboxed, it should be able to |override these with it's own version. Please explain this. |I guess if you want your own version of JAXP then you |should probably have to include your own |implementation as well. Jung's implementation of my ideas supported this. Ie we look for local classes first and then go to the repository to get the rest if not found this enables you to override with local implementations. I am against this, I would use it explicitely with a scope (I.e. if you define a scope then you have the same behaviour, it will take the one define locally) but if you don't then this is going to be a nightmare of classcasts like we have today if you are not careful with the packaging, ie it kills what we are trying to do. So we can support this but I think it should be slightly different than the way it is implemented now (could be wrong on memory here). |Should the app-server not try, even in this situation, |to optimise intra-container calls ? sure, of course, done! marcf | |Jules | | --- Rickard Öberg <[EMAIL PROTECTED]> wrote: > |Julian Gosnell wrote: |> |> > Your just putting the onus on the Application |> > programmer to work around shortcomings in the |> Server - |> > I think. |> |> |> Yes, the app programmer needs to know about |> classloading. Bug.. |> feature.. bug... feature.. which'll it be? :-) |> |> On the one hand, having straight-forward |> classloading makes it easy to |> develop a web-app. On the other hand, having |> sandboxed classloading |> makes the web-app more self-contained and portable, |> since they don't |> rely on the surrounding server to provide any of its |> classes. |> |> > If you do that with Jetty in stand-alone, |> compliant |> > mode - you will simply find you are using the JAXP |> > that Jetty loaded to parse it's own XML |> configuration |> > files. |> |> |> Yes, the straight-forward mode. |> |> |> > If you do it with Jetty in embedded, non-compliant |> > mode - you will find isAssignableFrom() fails. |> |> |> Yup, the more complex and portable case. |> |> /Rickard |> |> -- |> Rickard Öberg |> | |__ |Do You Yahoo!? |Everything you'll ever need on one web page from News and Sport to |Email and Music Charts |http://uk.my.yahoo.com | | Yahoo! Groups Sponsor -~--> |Universal Inkjet Refill Kit $29.95 |Refill any ink cartridge for less! |Includes black and color ink. |http://us.click.yahoo.com/1_Y1qC/MkNDAA/ySSFAA/CefplB/TM |-~-> | |For the latest information about Jetty, please see http://jetty.mortbay. | |Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/ | | ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [jetty-discuss] Re: [JBoss-dev] JBoss3/Jetty4, Greg/Scott - Optimised intra-container calls & ClassLoaders
|I guess if you want your own implementation of JAXP, |then you should probably have to reinclude the JAXP |api itself no problem use the scope. marcf | |> |> Should the app-server not try, even in this |> situation, |> to optimise intra-container calls ? |> |> Jules |> |> --- Rickard Öberg <[EMAIL PROTECTED]> wrote: > |> Julian Gosnell wrote: |> > |> > > Your just putting the onus on the Application |> > > programmer to work around shortcomings in the |> > Server - |> > > I think. |> > |> > |> > Yes, the app programmer needs to know about |> > classloading. Bug.. |> > feature.. bug... feature.. which'll it be? :-) |> > |> > On the one hand, having straight-forward |> > classloading makes it easy to |> > develop a web-app. On the other hand, having |> > sandboxed classloading |> > makes the web-app more self-contained and |> portable, |> > since they don't |> > rely on the surrounding server to provide any of |> its |> > classes. |> > |> > > If you do that with Jetty in stand-alone, |> > compliant |> > > mode - you will simply find you are using the |> JAXP |> > > that Jetty loaded to parse it's own XML |> > configuration |> > > files. |> > |> > |> > Yes, the straight-forward mode. |> > |> > |> > > If you do it with Jetty in embedded, |> non-compliant |> > > mode - you will find isAssignableFrom() fails. |> > |> > |> > Yup, the more complex and portable case. |> > |> > /Rickard |> > |> > -- |> > Rickard Öberg |> > |> |> __ |> Do You Yahoo!? |> Everything you'll ever need on one web page from |> News and Sport to Email and Music Charts |> http://uk.my.yahoo.com |> |> Yahoo! Groups Sponsor |> |> For the latest information about Jetty, please see |> http://jetty.mortbay. |> |> Your use of Yahoo! Groups is subject to |> http://docs.yahoo.com/info/terms/ |> |> | |__ |Do You Yahoo!? |Everything you'll ever need on one web page from News and Sport to |Email and Music Charts |http://uk.my.yahoo.com | | Yahoo! Groups Sponsor -~--> |Universal Inkjet Refill Kit $29.95 |Refill any ink cartridge for less! |Includes black and color ink. |http://us.click.yahoo.com/Vv.L9D/MkNDAA/ySSFAA/CefplB/TM |-~-> | |For the latest information about Jetty, please see http://jetty.mortbay. | |Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/ | | ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Developing with JBoss
Rickard Öberg wrote: > David Jencks wrote: > >> How would this help in the least? My understanding is that if you use a >> directory, the dd is checked for time changes > > > > For the auto-deployer, yes. I think I'd actually prefer to not use the > auto-deployer, and instead make an Ant task that does the deploy > command explicitly. Then there's no need to watch dd's or anything. I ran into the same problem and solved it by running Tomcat 4.0 as a separate process during development. Since tomcat works just fine with an already unpacked tree for my webapp, I simply modify my JSPs directly (I have a symbolic link from my webapp development tree to tomcat's webapps directory.) My ant rule to compile servlets and EJB remote/home interfaces is followed by a simple request to tomcat to reload the app: wget --http-user=foo --http-passwd=bar http://localhost:8080/manager/reload?path=/myapp I found this to be much easier than having to put the webapp in the ear for jboss. -- Andrew Scherpbier ( [EMAIL PROTECTED]) CTO, BlackBall Music ( http://www.blackballmusic.com/) ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Developing with JBoss
On 2001.11.21 11:53:03 -0500 Rickard Öberg wrote: > David Jencks wrote: > > > How would this help in the least? My understanding is that if you use a > > directory, the dd is checked for time changes > > > For the auto-deployer, yes. I think I'd actually prefer to not use the > auto-deployer, and instead make an Ant task that does the deploy command > explicitly. Then there's no need to watch dd's or anything. > > > and if it changes the whole > > app is undeployed and redeployed. Unless you can put your app in > > independently deployable chunks, you will need to undeploy and redeploy > the > > entire application anyway. > > > What I want to avoid is the copying and packaging that goes on. Do you > have any idea of the time it takes to package 1500 JSP's into a JAR, and > then have that 3-4Mb file copied and exploded into a tmp dir, and this > for every time you make a change in a single JSP? Forever I can tell > you. It adds up to *a lot* of time each day for just redeployment. Ok, I'll believe you. > > > > Why can't you use the Scoped Classloader, which puts several ears into > the > > same classloader and application? > > > Could work, but I'd rather do something portable. Plus, it's non-trivial > to break up our app (it's rather monolithic). Plus, several EAR's -> > several web deployments -> several web contexts -> no session sharing -> > no good. You're talking about a non-portable development environment anyway aren't you? Putting pieces of your 1500 jsps in different files might not be so hard??? I really don't know, just talking. > > > > Also if the problem is with jsps I thought I saw somewhere that you > could > > change the copied, deployed, unpacked jsp files while the app was > running > > and they would get picked up and recompiled. Haven't tried this > though. > > > No good. So, I change a file, and get it to work. I then change a class > and rebuild. Poof, my changed JSP file is gone. > > No, it needs to be clean, or there's just no point. ??? Are you proposing to change a copy of the source for the jsp rather than the source?? Cmon, you change your jsp in src, deployment of change consists of copying changed file to temp deployment directory?? You rebuild from source, you pick up the changes. Only problem I see is automatically finding the correct tmp deploy directory again after redeployment of the whole ear. david > > /Rickard > > -- > Rickard Öberg > > > ___ > Jboss-development mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-development > > ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [jetty-discuss] Re: [JBoss-dev] JBoss3/Jetty4, Greg/Scott - Optimised intra-container calls & ClassLoaders
|> Your just putting the onus on the Application |> programmer to work around shortcomings in the Server - |> I think. | | |Yes, the app programmer needs to know about classloading. Bug.. |feature.. bug... feature.. which'll it be? :-) | 100% bug |On the one hand, having straight-forward classloading makes it easy to |develop a web-app. On the other hand, having sandboxed classloading |makes the web-app more self-contained and portable, since they don't |rely on the surrounding server to provide any of its classes. bullshit marcf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [jetty-discuss] Re: [JBoss-dev] JBoss3/Jetty4, Greg/Scott - Optimised intra-container calls & ClassLoaders
| |Your just putting the onus on the Application |programmer to work around shortcomings in the Server - |I think. Like I said, dumb backwards thinking, I am in fact doubtful that Craig would do such a thing, Rickard you sure about this? |Perhaps someone will make a pronouncement on HOW |JBoss/Jetty SHOULD behave here. Then we can figure out |how to achieve this behaviour. Done, look I am almost done with teh rewrite of the proxies (having fun at this stage), then I want to look at deployment and packaging, we need to unify the way it works, it will be important for all functional aspect of the sub-containers, eg EJB/web services and their clustering. We are running smack into the packaging madness and how it ties to ClassLoaders. We DO HAVE THE SILVER BULLET, we have had it for a year, I just need to sit down and make it simpler. We will get there. marcf | | --- Rickard Öberg <[EMAIL PROTECTED]> wrote: > |Julian Gosnell wrote: |> |> > 2. Non-compliant - only requests for system |> classes |> > are passed upwards. |> |> |> FWIW, Tomcat4 does the same thing, which means that |> you have to bundle |> in jaxp.jar in your webapp, or you're going to get |> strange class-cast |> exceptions and class-not-found exceptions. The |> solution is to bundle all |> libraries with your app. | |If you do that with Jetty in stand-alone, compliant |mode - you will simply find you are using the JAXP |that Jetty loaded to parse it's own XML configuration |files. | |If you do it with Jetty in embedded, non-compliant |mode - you will find isAssignableFrom() fails. | |So Jetty, at the very leat, needs to know whether it |is embedded or not, and it may be more complex than |that - I thought I would bring in the big guns at this |point ! | |Jules | | Jetty |> |> > This strategy resolves the problems listed against |> (1) |> > but causes the isAssignableFrom() test mentioned |> above |> > to fail. What appears to happen is that JBoss |> passes |> > ClassLoader A to the EJB container which loads |> class X |> > then on to Jetty which creates it's WebApp |> > ClassLoader, B, as a child of A, then asks B to |> load |> > class X. B does not delegate to A, but loads class |> A |> > for a second time. |> |> |> So you need to put all classes in the EAR scope |> instead of in the webapp |> scope to make things work. Right? |> |> |> /Rickard |> |> |> |> -- |> Rickard Öberg |> | |__ |Do You Yahoo!? |Everything you'll ever need on one web page from News and Sport to |Email and Music Charts |http://uk.my.yahoo.com | | Yahoo! Groups Sponsor -~--> |Universal Inkjet Refill Kit $29.95 |Refill any ink cartridge for less! |Includes black and color ink. |http://us.click.yahoo.com/XwUZwC/MkNDAA/ySSFAA/CefplB/TM |-~-> | |For the latest information about Jetty, please see http://jetty.mortbay. | |Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/ | | ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [jetty-discuss] Re: [JBoss-dev] JBoss3/Jetty4, Greg/Scott - Optimised intra-container calls & ClassLoaders
|> 2. Non-compliant - only requests for system classes |> are passed upwards. | | |FWIW, Tomcat4 does the same thing, which means that you have to bundle |in jaxp.jar in your webapp, or you're going to get strange class-cast |exceptions and class-not-found exceptions. The solution is to bundle all |libraries with your app. That is REALLY dumb, what in the world are they thinking? are we the only ones that do smart things with CL architectures? who is in charge of this craig? Jetty guys, doing this correctly is going to blow a hole in everyone, tomcat included... why? the packaging will become a trivial thing, you will not need to package everyone together and what not, it makes the distribution and package a trivial thing. You will see, this is really a order of magnitude simpler. So if you want to take a chance and leave Tomcat in the dust, this is the one, do it! marcf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] JBoss3/Jetty4, Greg/Scott - Optimised intra-container calls & ClassLoaders
|I was getting nasty errors when trying to make |optimised calls from the web to the ejb container. | |It seems that while JBoss is aware that both client |and server objects exist within the same vm, it was |upset that the call was being serialised, instead of |just simply made natively, and wanted to tell me about |it. | |So I investigated | |Along the path that an invocation must make from web |to ejb container a test (Class.isAssignableFrom()) is |made to establish whether the call can be made between |two ClassLoaders without serialisation. I am going to remove this test but it doesn't fix the problem. |Jetty has 2 modes in which it can run the ClassLoader |used for WebApps. | |1. Java 2 compliant - all requests for classes are |delegated first to it's parent. | |Using this strategy you may get bitten if your webapp |uses e.g. different versions of the same |infrastructure than it's container - since the |container's copies will be used in preference. |Problems also occur with abstract APIs (e.g. JAXP), |loaded by the container, looking for implementations |which the webapp contains, but the container does not |ship with. Right this is afaik the only way to make integration work, unless there is physical sharing for CL. I could be wrong. The problem you describe is not a limitation of the model but really a BUG in the application code, really you should always start by looking for classes from the CL context. The way to do this is to always set the parent of the cl you build from the context. You are done. |2. Non-compliant - only requests for system classes |are passed upwards. Don't do this, you essentially shoot all possible integration by always using the Jetty CL. If you have classes that are duplicated then you are shot for sure. |This strategy resolves the problems listed against (1) |but causes the isAssignableFrom() test mentioned above |to fail. What appears to happen is that JBoss passes of course |ClassLoader A to the EJB container which loads class X |then on to Jetty which creates it's WebApp |ClassLoader, B, as a child of A, then asks B to load |class X. B does not delegate to A, but loads class A |for a second time. because you don't delegate. Again it is a bug in the client app if you don't set the parent. Also why in the world would you do away with delegation in integration? The "bug" you describe above, is it the only reason? if so then that is a bit strange. |Scott, If you could explain a little about the |architecture of ClassLoaders in JBoss3, Greg and I may |be in a better position to figure out how to get this |going. It is simple rh cls will enable you to get visibility on all apps packaged classes. If Jetty uses the contextCL and we always call jetty from JBoss then you leverage this. The fact that you won't get a ClassCast is a by-product of integration not of the scope. Then the scope buys you something more powerful. In this first case you still need to package all the classes with the application. The scope CL enables you to do away with this. We will have scope at the app level and scope at the system level. I will code that. If jetty uses the RH cl directly, as it should when we actually integrate the codebases then the problem is natively taken care of, you will see the classes directly. It will make for superior packaging (lack of) where right now you have a nightmare of "where did I put my classes". |Greg, I guess we are looking at pluggable |ContextLoader strategies - stand-alone, jboss etc... Again setting the parent to all your cls from context and not dissabling delegation is the simplest thing to try, you will use RH cl implicitely by delegation. It works standalone and jboss integration and you still use your own little cl stuff. INtegrated Jetty will need to use the RH cl. |WebSphere seems to have a highly configurable |ClassLoader system, and I think it is unlikely that |there is a one-size-fits-all solution here. bullshit, webshemere still doesn't support hot-deploy which tends to indicate a primitive usage of classloaders. I could be wrong there, I don't know webshemere. marcf |Sorry to complicate your mornings guys, | | |Jules | | |__ |Do You Yahoo!? |Everything you'll ever need on one web page from News and Sport to |Email and Music Charts |http://uk.my.yahoo.com | |___ |Jboss-development mailing list |[EMAIL PROTECTED] |https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] JBoss3/Jetty4, Greg/Scott - Optimised intra-container calls & ClassLoaders
Scott M Stark wrote: > Really, what was the package structure that caused the exception? I > thought I had tested a number of variations and hadn't seen any issues > with "normalized" ears. We had to include jaxp.jar and crimson.jar in our EAR to get XML parsing to work. With only jaxp.jar you get a LinkError (or something like that) because you'll get jaxp.jar from the app and the parser from the server, and the interfaces the parser implements is not the same as that in jaxp.jar (=classloader hell). > Regardless, I'm going to work on the deployment layer to clean it up > and add support unarchived ears. That would be sooo appreciated. It would save us so much time it aint funny... /Rickard -- Rickard Öberg ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] How would RDF help us, Rickard?
David Jencks wrote: > I tried looking into rdf a little bit since Rickard has been pushing it for > mbean configuration, but as far as I have read (not very far) I don't see > the point. Is there an example of using rdf for something remotely > resembling component configuration that might convince me quickly that this > is a good idea? AFAIK there are no good reasons to use RDF at all, apart from giving you that feel-good feeling and a voice in the back of your head saying "you're gonna be glad for this some day". RDF is not an easy sell if you're always looking at single examples. It's when you get more stuff into RDF that you can do interesting things, since a large part of it revolves around semantic deductions. Oh yeah, now I remember, Mozilla uses RDF for all of their stuff. I believe they have a couple of "this is how it went" docs as well at their site (mozilla.org). I'm gonna try and use RDF for as much as possible in my future projects. At some point critical mass is reached and you can do all sorts of funky stuff. Hey, it's only XML anyway, so no loss if nothing good comes out of it. /Rickard -- Rickard Öberg ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Developing with JBoss
David Jencks wrote: > How would this help in the least? My understanding is that if you use a > directory, the dd is checked for time changes For the auto-deployer, yes. I think I'd actually prefer to not use the auto-deployer, and instead make an Ant task that does the deploy command explicitly. Then there's no need to watch dd's or anything. > and if it changes the whole > app is undeployed and redeployed. Unless you can put your app in > independently deployable chunks, you will need to undeploy and redeploy the > entire application anyway. What I want to avoid is the copying and packaging that goes on. Do you have any idea of the time it takes to package 1500 JSP's into a JAR, and then have that 3-4Mb file copied and exploded into a tmp dir, and this for every time you make a change in a single JSP? Forever I can tell you. It adds up to *a lot* of time each day for just redeployment. > Why can't you use the Scoped Classloader, which puts several ears into the > same classloader and application? Could work, but I'd rather do something portable. Plus, it's non-trivial to break up our app (it's rather monolithic). Plus, several EAR's -> several web deployments -> several web contexts -> no session sharing -> no good. > Also if the problem is with jsps I thought I saw somewhere that you could > change the copied, deployed, unpacked jsp files while the app was running > and they would get picked up and recompiled. Haven't tried this though. No good. So, I change a file, and get it to work. I then change a class and rebuild. Poof, my changed JSP file is gone. No, it needs to be clean, or there's just no point. /Rickard -- Rickard Öberg ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [jetty-discuss] Re: [JBoss-dev] JBoss3/Jetty4, Greg/Scott - Optimised intra-container calls & ClassLoaders
Greg Wilkins wrote: > What class does it fail for? Can't you remove that class/jar from > the webapplication, so that it can only be loaded from the EJB classloader? It should be loaded by the EAR loader methinks. -- Rickard Öberg ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] How would RDF help us, Rickard?
Hey, I tried looking into rdf a little bit since Rickard has been pushing it for mbean configuration, but as far as I have read (not very far) I don't see the point. Is there an example of using rdf for something remotely resembling component configuration that might convince me quickly that this is a good idea? Thanks david jencks ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Optimized Servlet->EJB calls.../ Local Interfaces
> > Now that I've read about Local interfaces, I can see > that they are the natural choice for communications > between beans in the same Container. > > Is it being suggested that I should use these for > servlet/jsp->ejb communication ? Yep, but that is in the J2EE spec not the Servlet or ejb specs. > If not then we still need to support optimized calls > between the web and ejb container. it is these that > fail between Jetty and JBoss. > > If so, then something is wrong. Do I really have to > decide the architecture of my AppServer before I write > my App? It should be transparent. The trick is if you think you may want in VM optimized calls you can not rely on the pass by value style method calls. This means don't use Object parameters as temp variables. Later on you can switch to Local interfaces for speed. Alternatively, you could start with local interfaces and then switch to remote if you want to move the web layer to another vm. This has a similar issue regarding by reference parameters. You can't rely on updated parameters being reflected in the web layer. > If optimized calls between web-container and > ejb-container are to be supported, then I still have > ClassLoader issues to be resolved. Whey have to be in an EAR with class-path refs properly set in the manifest.mf file. This is documented in either the J2EE spec or the EJB spec. -dain ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Optimised Servlet->EJB calls.../ Local Interfaces
Julian Gosnell wrote: > Is it being suggested that I should use these for > servlet/jsp->ejb communication ? I would :-) > If so, then something is wrong. Do I really have to > decide the architecture of my AppServer before I write > my App? It should be transparent. You can write your app so that these issues are transparent, but then you need to take alays care of the worst case, which is remote behaviour. If not, then you are guilty of having believed in the Seven Fallacies of Network Computing (http://wwwtec.informatik.uni-rostock.de/IuK/gk/thm/devdef/Vortrag1/tsld008.htm) Architecture is rarely transparent, although it is often quite possible to *localize* the impact of it to some degree. /Rickard -- Rickard Öberg ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] How about a dtd for *service.xml files? (3.0)
I wrote up a dtd for *service.xml files, anyone have a problem if I check it in and modify the existing *service.xml files to use it? In particular are there problems with free-form xml being used within attribute elements? (I only tried jboss-service.xml so far.) If there are such problems can we deal with them e.g. with namespaces? Thanks david jencks ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
