The njar:file:jetty-plugin.sar^/org.mortbay.jetty.jar is going to be
a problem for the JSP classpath.
Either:
(1) jars inside sars need to be extracted by the JBoss deployer
(2) we forget sar format for Jetty and put all mortbay jars into
jboss.homelib
I assume that since JBoss is working
The njar:file:jetty-plugin.sar^/org.mortbay.jetty.jar is going to be
a problem for the JSP classpath.
Either:
(1) jars inside sars need to be extracted by the JBoss deployer
(2) we forget sar format for Jetty and put all mortbay jars into
jboss.homelib
I assume that since JBoss is working
Sorry if this is a re-post, having mail trouble ...
*However* there still seems to me to be a problem with JSPs in general:
ie, any JSP that has to be compiled that refers to a class (such as an
ejb) that is found by an njar:file:^/blah.jar URL won't be able
to be compiled?!
The
I haven't been following all that closely...
Is the problem with the njar format that either jasper or another compiler
can only deal with jar files and class files on its classpath?
(2) is easy, just requires fiddling with the build scripts a bit.
If you only need one jar or file available to
Similar issue with applications like Velocity. These apps depend
(somewhat misguidedly) on an unpacked deployment of web apps. This is
because they need to read web pages in order to parse them for tag
substitution. AFAIK, they do not delegate a class to do the reading for
them.
jim
What exactly do[es] the compiler[s] expect/accept?
david jencks
On 2002.03.10 09:24:08 -0500 Jan Bartel wrote:
The njar:file:jetty-plugin.sar^/org.mortbay.jetty.jar is going to be
a problem for the JSP classpath.
Either:
(1) jars inside sars need to be extracted by the JBoss
I've done a bit more research. I found these two links.
http://developer.java.sun.com/developer/bugParade/bugs/4420157.html
http://developer.java.sun.com/developer/bugParade/bugs/4447092.html
I like the part that says
Furthermore, such a mechanism would be unlikely to address the primary focus
Can we go back to having to the application deployers
in deploy/
That way users can specify MBean dependencies on their
datasources, web-containers and messaging.
I more fine grained approach would be better for ejbs.
Allowing delayed deployment based on resource-refs,
ejb-refs, etc. Warnings
Can you give a specific example of something that doesn't work the way you
want that doesn't involve a .war?
AFAIK you can make mbeans wait for ejbs, datasources,... anything
represented by a non-jsr77 mbean.
You can't make anything that isn't deployed from a *service.xml file wait
for
Hi,
I wanted to update Jboss DTD before release xdoclet release 1.1.2 but I
am not sure what is needed on the DTD side.
We package them in xdoclet to permit xml validation at the end of their
generation.
Do we have to maintain DTD that not have _x_y in them ?
I remember that the rule is that
Hi David,
Re: Reproducing problem for database
1) Build the server
2) Remove hsqldb-default-service.xml
3) Copy cmp2-select.jar from the testsuite into deploy
4) Rebuild the server
5) Start the server
You get a deployment exception saying it cannot find
java:/DefaultDS which is true because it
Yes, this sucks.
There are a couple of workarounds, but they should not be necessary. I
hope everyone can wait for better dependency checking based on the standard
dd's.
david jencks
On 2002.03.10 12:10:51 -0500 Adrian Brock wrote:
Hi David,
Re: Reproducing problem for database
1) Build
In order to enable dynamic loading of IIOP stub classes I have changed a
few classes in the main server directory:
- org.jboss.web.WebClassLoader gained a couple of methods designed
to be overriden by subclasses. Its constructor now requires an
UnifiedClassLoader parameter, rather than
Unless I'm missing something...
We seem to have lost the list of containers for an
application. An ejb-link to another jar in the
same application doesn't work.
Can this be fixed by holding a shared list of
(application) containers in EjbModule for ejb-ref lookups
seperate from the containers
I wrote the file: stuff before the introduction of
njar: - I shall try to find time to look at this
tonight.
The Jasper/packed problem has been around in various
guises as long as Jasper. I think, ultimately, someone
should take a proper look at Jasper and figure out a
way of LAZILY unpacking
Just to put my 2 cents in.
The JSP compilation works when you run JBoss with
JBossMX.
This has something to do with JBossMX remembering
the ContextClassLoader when an MBean is created
and using it for future invokes.
Unfortunately, I can't demonstrate this to you because
the latest changes to
On 2002.03.10 13:02:25 -0500 Adrian Brock wrote:
Just to put my 2 cents in.
The JSP compilation works when you run JBoss with
JBossMX.
This has something to do with JBossMX remembering
the ContextClassLoader when an MBean is created
and using it for future invokes.
Unfortunately, I
User: d_jencks
Date: 02/03/10 11:40:23
Modified:src/resources/org/jboss/metadata jbosscmp-jdbc_3_0.dtd
Log:
changed to work a little better with xdoclet
Revision ChangesPath
1.14 +2 -2 jboss/src/resources/org/jboss/metadata/jbosscmp-jdbc_3_0.dtd
Index:
I think xdoclet needs all the _x_y ones, I think the others are old, not
supported and for jboss 2.2.
btw I just updated jbosscmp-jdbc_3_0.dtd with a xdoclet-relevant fix... I
will check it into xdoclet also.
david jencks
On 2002.03.10 11:56:02 -0500 Vincent Harcq wrote:
Hi,
I wanted to
I was giving Jasper and all the related unpacking problems some thought
in the car on the way home this evening and reckon I have a nice, simple
solution to all our woes (and Tomcat's, if they are interested...).
Jasper supports pluggable compilers.
We simply write a
Looks like a great idea to me.
Incidently, jar already copies remote files to a local tmp copy and njar
takes this one step further. However, these still typically aren't the
.java or .class files you are apt to need, so it probably wouldn't do any
good to poke around in their local copies.
Jules,
I guess this is the ultimate solution - ie a compiler that takes URLs
in the classpath. As that has not been forthcoming from jikes, sun or
whatever - then your wrapper idea is one way of providing it.
But a couple of notes:
+ No matter what we do about unpacking, we have to remove
Actually, it is exactly the internally unpacked tmp files from njar that
is needed! What jasper wants on the class path are path references to
classes/jars rather than URL references to them.
How hard would it be to get the njar stuff to return the path to the
unpacked files?
Jan
David
Is there a way for me to check out a version of the proxy compiler from prior to the
revisions made on March 7 - and would it do me any good? I'm still not up to speed on
all the ins and outs of CVS, I'm still stuck with the error and unable to deploy, and
I'm not sure what command or tag to
Let's consider bang for buck, or effort for reward: how much effort is
it going to be for JBoss to provide a real path for items in an njar
format (ie really making their AbstractWebContainer
getCompileClasspath() method *really* return a compilable classpath
rather than a bunch of URLs) versus
MMM all is not well in the state of java.nio!
At least on linux, I'm getting lots of strange behaviour, which I suspect
are bugs in the implementation or my understanding of it.
Firstly it appears that the loadbalancer only works if debug is turned on.
With debug turned off, it runs
nevermind. figured it out.
_
View thread online: http://main.jboss.org/thread.jsp?forum=66thread=10464
___
Jboss-development mailing list
[EMAIL PROTECTED]
I see your point, Jan.
However, even if JBoss supplies us with file: urls, Jasper will still need the
WAR unpacked so it can get at the JSPs (Greg, when I said .java in my previous
mail I meant .jsp).
My solution, will sort this as well, since .jsps will also be picked up by
getResource().
I
Jules,
I figure that I can put together a very naive version fairly painlessly. Less
painfully, in fact, than having to continually explain the problem on various
lists/fora and provide a stream of half hearted attempts at a proper Jasper
integration. Furthermore, if it works, it gives
Narrow band reply, as I am not sure about this.
I think jasper already gets the jsps as URLs and/or resources.
That's why last modified does not work unless it is using jdk1.4
cheers
Jules Gosnell wrote:
I see your point, Jan.
However, even if JBoss supplies us with file: urls,
|Fix JBoss getCompileClasspath()v ResourceBasedCompilerAdaptor
| small effort:sufficient rewardvbig effort:sufficient reward
damn someone has been to my training and is applying our own principles to
XP development and we get to pay the price
you guys are smart... too smart.
|-Original Message-
|From: [EMAIL PROTECTED]
|[mailto:[EMAIL PROTECTED]]On Behalf Of Jan
|Bartel
|Sent: Sunday, March 10, 2002 1:21 PM
|To: David Jencks
|Cc: [EMAIL PROTECTED]
|Subject: Re: [JBoss-dev] Jasper problems - Eureka !
|
|
|Actually, it is exactly the internally unpacked tmp
On 2002.03.10 16:21:14 -0500 Jan Bartel wrote:
Actually, it is exactly the internally unpacked tmp files from njar that
is needed! What jasper wants on the class path are path references to
classes/jars rather than URL references to them.
How hard would it be to get the njar stuff to
On 2002.03.10 17:19:18 -0500 marc fleury wrote:
|-Original Message-
|From: [EMAIL PROTECTED]
|[mailto:[EMAIL PROTECTED]]On Behalf Of Jan
|Bartel
|Sent: Sunday, March 10, 2002 1:21 PM
|To: David Jencks
|Cc: [EMAIL PROTECTED]
|Subject: Re: [JBoss-dev] Jasper problems - Eureka !
david,
methinks we should really make move on this dependency problem and i believe
you've got the right approach.
i am even growing warmer to you skipping some steps re: service.xml unified
xml
p, there i said it...
marcf
|-Original Message-
|From: [EMAIL PROTECTED]
OK,
I'll try writing the CompilerPlugin with a trivial cache and if it works we will
try to hook it up to the njar stuff...
Jules
Jan Bartel wrote:
Jules,
I figure that I can put together a very naive version fairly painlessly. Less
painfully, in fact, than having to continually
Hhmm,
I have just written the compiler shell, and if my JBoss was working would have had
it running by now - so I could answer your question.
IF I get it running AND the classpath contains no URLs AND the sourcefile is a
simple filepath THEN I will stick in a trivial URL-FILE cache and try it
User: reverbel
Date: 02/03/10 16:33:57
Modified:src/main/org/jboss/proxy/compiler ProxyAssembler.java
Log:
Visibility of class ProxyAssembler changed to public, so this class can be
used by the iiop module.
Revision ChangesPath
1.2 +2 -2
JBoss daily test results
SUMMARY
Number of tests run: 528
Successful tests: 508
Errors:13
Failures: 7
[time of test: 11 March 2002 0:51 GMT]
[java.version:
User: reverbel
Date: 02/03/10 17:23:06
Modified:src/main/org/jboss/web WebServer.java
Log:
WebServer now handles WebClassLoader subclasses with bytecode generation
ability (by calling WebClassLoader getBytes method).
Revision ChangesPath
1.18 +23 -12
User: reverbel
Date: 02/03/10 17:20:42
Modified:src/main/org/jboss/web WebClassLoader.java
Log:
- WebClassLoader has now a single constructor, which takes a Container and
a UnifiedClassLoader.
- Added methods getKey and getBytes, meant to be overriden by subclasses.
User: reverbel
Date: 02/03/10 17:24:56
Modified:src/main/org/jboss/ejb EjbModule.java
Log:
Method initializeContainer was changed to create a WebClassLoader for the
container and to register it with the web service.
Revision ChangesPath
1.10 +40 -1
User: reverbel
Date: 02/03/10 17:26:54
Modified:src/main/org/jboss/ejb Container.java
Log:
Added methods getCodebase/setCodebase, used by the iiop module.
Revision ChangesPath
1.82 +30 -1 jboss/src/main/org/jboss/ejb/Container.java
Index: Container.java
User: reverbel
Date: 02/03/10 17:29:08
Modified:src/main/org/jboss/metadata ConfigurationMetaData.java
Log:
Added IIOP tags and a new configuration element, web-class-loader.
Revision ChangesPath
1.25 +19 -3
User: reverbel
Date: 02/03/10 17:31:40
Modified:src/etc/conf/default standardjboss.xml
Log:
Added configurations for IIOP containers.
Revision ChangesPath
1.35 +222 -1jboss/src/etc/conf/default/standardjboss.xml
Index: standardjboss.xml
User: reverbel
Date: 02/03/10 17:34:17
Modified:src/etc/conf/default jboss-service.xml
Log:
Added MBean entry (commented out by default) for RMI/IIOP with JacORB.
Revision ChangesPath
1.36 +13 -1 jboss/src/etc/conf/default/jboss-service.xml
Index:
User: reverbel
Date: 02/03/10 17:37:48
Modified:src/resources/org/jboss/metadata jboss_3_0.dtd
Log:
Added web-class-loader element. IIOP configurations included in the comment
that lists all standard container configurations.
Revision ChangesPath
1.5 +20 -5
JBoss daily test results
SUMMARY
Number of tests run: 535
Successful tests: 516
Errors:11
Failures: 8
[time of test: 11 March 2002 1:35 GMT]
[java.version:
User: reverbel
Date: 02/03/10 17:43:14
Added: iiop/src/main/org/jboss/iiop WebCL.java
Log:
Initial version of WebCL, a subclass of org.jboss.web.WebClassLoader that
dynamically generates IIOP stubs.
Revision ChangesPath
1.1
JBoss daily test results
SUMMARY
Number of tests run: 535
Successful tests: 518
Errors:11
Failures: 6
[time of test: 11 March 2002 2:18 GMT]
[java.version:
User: schaefera
Date: 02/03/10 18:50:42
jboss-management/src - New directory
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
User: schaefera
Date: 02/03/10 18:51:05
jboss-management/src/etc - New directory
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
User: schaefera
Date: 02/03/10 18:51:30
jboss-management/src/main/org - New directory
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
User: schaefera
Date: 02/03/10 18:51:51
jboss-management/src/main/javax/management - New directory
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
User: schaefera
Date: 02/03/10 18:51:05
jboss-management/src/main - New directory
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
User: schaefera
Date: 02/03/10 18:51:30
jboss-management/src/main/javax - New directory
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
User: schaefera
Date: 02/03/10 18:52:20
jboss-management/src/main/javax/management/j2ee - New directory
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
User: schaefera
Date: 02/03/10 18:53:37
jboss-management/src/main/org/jboss - New directory
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
User: schaefera
Date: 02/03/10 18:53:53
jboss-management/src/main/org/jboss/management - New directory
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
User: schaefera
Date: 02/03/10 18:54:12
jboss-management/src/main/org/jboss/management/j2ee - New directory
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
User: schaefera
Date: 02/03/10 18:54:13
jboss-management/src/main/org/jboss/management/mejb - New directory
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
User: mnf999
Date: 02/03/10 19:11:53
Modified:src/docs/common picabanner.jsp
Log:
Update: new stuff on index page, new stuff on training page
Revision ChangesPath
1.5 +3 -3 newsite/src/docs/common/picabanner.jsp
Index: picabanner.jsp
User: mnf999
Date: 02/03/10 19:11:53
Modified:src/docs/jbossgroup training.jsp
Log:
Update: new stuff on index page, new stuff on training page
Revision ChangesPath
1.19 +56 -43newsite/src/docs/jbossgroup/training.jsp
Index: training.jsp
User: mnf999
Date: 02/03/10 19:11:53
Modified:src/docs index.jsp
Log:
Update: new stuff on index page, new stuff on training page
Revision ChangesPath
1.46 +47 -35newsite/src/docs/index.jsp
Index: index.jsp
User: mnf999
Date: 02/03/10 19:13:11
Added: src/docs schedule.jsp
Log:
Update: Because you just can't get enough, the schedules page
for the JavaOne. Sorry for the multiupdates
Revision ChangesPath
1.1 newsite/src/docs/schedule.jsp
Index:
JBoss daily test results
SUMMARY
Number of tests run: 535
Successful tests: 517
Errors:11
Failures: 7
[time of test: 11 March 2002 3:25 GMT]
[java.version:
JBoss daily test results
SUMMARY
Number of tests run: 535
Successful tests: 518
Errors:11
Failures: 6
[time of test: 11 March 2002 4:23 GMT]
[java.version:
User: schaefera
Date: 02/03/10 20:31:35
Modified:src/main/org/jboss/test/management/test
JSR77SpecUnitTestCase.java
Log:
Moved the JSR-77 code to the new management module. It contains the
specification implementation for MEJB and the JBoss implementation.
User: schaefera
Date: 02/03/10 20:31:34
Modified:.build.xml
Log:
Moved the JSR-77 code to the new management module. It contains the
specification implementation for MEJB and the JBoss implementation.
It does not contain references to JBoss server.
The only
User: schaefera
Date: 02/03/10 20:31:34
Removed: src/main/org/jboss/management ContainerManagement.java
ContainerManagementMBean.java package.html
Log:
Moved the JSR-77 code to the new management module. It contains the
specification implementation for
User: schaefera
Date: 02/03/10 20:31:34
Modified:.build.xml
Log:
Moved the JSR-77 code to the new management module. It contains the
specification implementation for MEJB and the JBoss implementation.
It does not contain references to JBoss server.
The only
User: schaefera
Date: 02/03/10 20:31:33
Added: src/main/org/jboss/management/mejb
ClientNotificationListener.java
JMSClientNotificationListener.java
JMSNotificationListener.java
User: schaefera
Date: 02/03/10 20:31:35
Removed: sun/jsr77/lib jsr77.jar
Log:
Moved the JSR-77 code to the new management module. It contains the
specification implementation for MEJB and the JBoss implementation.
It does not contain references to JBoss server.
The only
User: schaefera
Date: 02/03/10 20:31:34
Removed: src/main/org/jboss/management/mejb
ClientNotificationListener.java
JMSClientNotificationListener.java
JMSNotificationListener.java
User: schaefera
Date: 02/03/10 20:31:31
Modified:.build.xml
Log:
Moved the JSR-77 code to the new management module. It contains the
specification implementation for MEJB and the JBoss implementation.
It does not contain references to JBoss server.
The only
User: schaefera
Date: 02/03/10 20:31:32
Added: src/main/javax/management/j2ee BoundaryStatistic.java
BoundedRangeStatistic.java CountStatistic.java
EJBStats.java EntityBeanStats.java
JCAConnectionPoolStats.java
User: schaefera
Date: 02/03/10 20:31:35
Modified:variabuild.xml
Log:
Moved the JSR-77 code to the new management module. It contains the
specification implementation for MEJB and the JBoss implementation.
It does not contain references to JBoss server.
The only
User: schaefera
Date: 02/03/10 20:31:34
Removed: src/main/org/jboss/management/j2ee AppClientModule.java
CountStatistic.java EJB.java EjbModule.java
EntityBean.java EventProvider.java
InvalidParentException.java
User: schaefera
Date: 02/03/10 20:31:35
Added: lib remote-mbeanserver.jar
Log:
Moved the JSR-77 code to the new management module. It contains the
specification implementation for MEJB and the JBoss implementation.
It does not contain references to JBoss server.
The
User: schaefera
Date: 02/03/10 20:31:34
Modified:src/main/org/jboss/ejb EjbModule.java
Log:
Moved the JSR-77 code to the new management module. It contains the
specification implementation for MEJB and the JBoss implementation.
It does not contain references to JBoss server.
User: schaefera
Date: 02/03/10 20:31:31
Modified:.build.xml
Log:
Moved the JSR-77 code to the new management module. It contains the
specification implementation for MEJB and the JBoss implementation.
It does not contain references to JBoss server.
The only
User: schaefera
Date: 02/03/10 20:31:31
Modified:jbossbuild.xml
Log:
Moved the JSR-77 code to the new management module. It contains the
specification implementation for MEJB and the JBoss implementation.
It does not contain references to JBoss server.
The only
User: schaefera
Date: 02/03/10 20:31:32
Added: src/main/org/jboss/management package.html
Log:
Moved the JSR-77 code to the new management module. It contains the
specification implementation for MEJB and the JBoss implementation.
It does not contain references to JBoss
The njar protocol only extracts jars out to temp files. So your *.jsp's and
such will not be extracted by using njar.
If you just intrested in getting the local path to the jar that contains
your resources, I think you should be able to do something like:
URL url = new
JBoss daily test results
SUMMARY
Number of tests run: 530
Successful tests: 510
Errors:12
Failures: 8
[time of test: 11 March 2002 5:40 GMT]
[java.version:
=
==THIS IS AN AUTOMATED EMAIL - SEE http://www.lubega.com FOR DETAILS=
=
HERE ARE THE LAST 50 LINES OF THE LOG FILE
private TimeStatistic mActivation =
User: patriot1burke
Date: 02/03/10 22:31:11
Modified:src/main/org/jboss/proxy/ejb ProxyFactory.java
Log:
load client-interceptor classes at create time, not at every proxy creation. Should
speed
up proxy creation. Also, refactored a little bit for re-use in cluster
User: patriot1burke
Date: 02/03/10 22:26:22
Modified:src/main/org/jboss/proxy/ejb ProxyFactoryHA.java
Log:
fixes after client-interceptor break
Revision ChangesPath
1.6 +17 -24jbossmx/src/main/org/jboss/proxy/ejb/ProxyFactoryHA.java
Index:
User: patriot1burke
Date: 02/03/10 22:25:45
Modified:src/main/org/jboss/invocation/jrmp/server JRMPInvokerHA.java
Log:
fixes after client-interceptor break
Revision ChangesPath
1.12 +3 -3
jbossmx/src/main/org/jboss/invocation/jrmp/server/JRMPInvokerHA.java
User: patriot1burke
Date: 02/03/10 22:26:00
Modified:src/main/org/jboss/invocation/jrmp/interfaces
JRMPInvokerProxyHA.java
Log:
fixes after client-interceptor break
Revision ChangesPath
1.4 +8 -36
User: patriot1burke
Date: 02/03/10 22:29:40
Modified:jbossbuild.xml
Log:
added cluster module back into build
Revision ChangesPath
1.108 +2 -2 build/jboss/build.xml
Index: build.xml
===
=
==THIS IS AN AUTOMATED EMAIL - SEE http://www.lubega.com FOR DETAILS=
=
HERE ARE THE LAST 50 LINES OF THE LOG FILE
private TimeStatistic mActivation =
92 matches
Mail list logo
