I would only say maybe consider closely the linking to files in SVN.
The ActiveMQ and ServiceMix sites have been plagued by pages that have
An error occured. An administrator has been notified. instead of
critical code samples (which is a lie because clearly the
administrator doesn't get a list
On Dec 12, 2007 8:27 PM, David Jencks [EMAIL PROTECTED] wrote:
I must be missing something... how does the prerequisite system work
better than dependencies here? I'm not 100% sure of what currently
happens when you try to install a plugin that has an unavailable
dependency, but it certainly
say we don't want the plugin installer to
automatically install a second web container into an assembly if the
user picks the wrong plugin.
Best wishes,
Paul
On Dec 13, 2007, at 1:21 PM, Aaron Mulder wrote:
On Dec 12, 2007 8:27 PM, David Jencks [EMAIL PROTECTED] wrote:
I must be missing
Wow! Either you're pretty sharp or you really need a faster machine! :)
I think the main issue was that the console expected to be able to
cast GBean references to some helper interface in order to start and
stop individual GBeans and get a GBean's name and things like that.
And the proxies
It was mainly for things like this plugin needs you to hook it up to
a database where we can't reasonably provide a database -- you have
to set up a DB instance and a connection pool with the right name and
then the plugin will install. Or it could be a dependency on a
proprietary driver or
Sounds fine to me.
Thanks,
Aaron
On Dec 6, 2007 9:43 AM, Rick McGuire [EMAIL PROTECTED] wrote:
The discussion thread has been out there long enough for comment, and
those who have responded appear positive about the prospect. I think
it's time to put this to a vote. The full proposal
On Nov 29, 2007, at 9:05 AM, Aaron Mulder wrote:
Is there some good way to insert a filter/interceptor into the web
container request processing chain that would work for both Tomcat and
Jetty? For example, let's say you wanted to apply some particular
request validation/auditing
To me, AOP seems like it would be better if the application were doing
it, rather than trying to do it at the server configuration level.
Thanks,
Aaron
On Nov 29, 2007 1:48 PM, Jeff Genender [EMAIL PROTECTED] wrote:
Have you considered AOP?
Jeff
Aaron Mulder wrote:
Is there some
I'm not that big a fan of trying to make the schema namespace be an
actual working URL. Should the schema's namespace end in .xsd?
That seems weird. Plus we have no control over the location for many
of the schemas we use (other projects we use, the Sun schemas, etc.)
And it might result in us
to the job. Apparently there
isn't.
I guess I'll get back to the alias work for now until we figure out a better
way to do this.
Cheers!
Hernan
Aaron Mulder wrote:
I'm not that big a fan of trying to make the schema namespace be an
actual working URL. Should the schema's namespace end
The 2.0 page isn't quite right -- the preferred J2EE schemas on the
top right should name and point to the Java EE 5 ones, I should think.
Thanks,
Aaron
On 9/17/07, Hernan Cunico [EMAIL PROTECTED] wrote:
I've updated the XML Schemas info on the web site for reflect 1.0, 1.1 and 2.0
You
Sounds nice!
Aaron
On 9/14/07, David Jencks [EMAIL PROTECTED] wrote:
Periodically users show up who want their passwords obscured in new
ways that allow their systems to break by removing the key used to
obscure them :-) (how's that for a biased view of the situation :-)
They don't like
wrote:
Aaron Mulder wrote:
I'm pretty tight for time right now, though I could certainly advise
someone if they were interested in doing the porting to 2.x. I don't
care if it's done at SF or if the code is sucked over to Apache.
Hi Aaron
Thank you for your reply. I checked out
I'm pretty tight for time right now, though I could certainly advise
someone if they were interested in doing the porting to 2.x. I don't
care if it's done at SF or if the code is sucked over to Apache.
Thanks,
Aaron
On 9/4/07, Paul McMahan [EMAIL PROTECTED] wrote:
I agree that it would
I guess we could also disable stop and undeploy for the system modules
and have an expert mode checkbox or something on the screen to
enable them again. That ought to be clue enough. :)
Thanks,
Aaron
On 8/28/07, Aaron Mulder [EMAIL PROTECTED] wrote:
It probably would still be good
It probably would still be good to have some text like WARNING: only
expert users will be able to restart the server after this is done.
Just seeing a list of components to be stopped won't necessarily clue
in the average user to the potential impact... But of course we'd
only want to display
What were the benefits of 1.2? All I remember was that the build
changed to Maven 2. If there's a known bug with more than one
connected user, and limited benefits compared to the upcoming 2.0, and
also none of the developers want to support it, I don't think a
release is in our interest. But
I don't really care about run-as; my main concern is the default
subject/principal. I think it should be as simple as possible to
create a default subject named anonymous with no roles or special
treatment whatsoever (just so if you call things like
getCurrentPrincipal().getName() you don't get
One option would be climb the classloader tree to activate the cache
during startup/deployment and flush the cache when startup finishes
and when each deployment finishes. So it would only be used during
one of those long operations and shouldn't interfere with people
dumping classes in a
On 4/19/07, Ted Kirby [EMAIL PROTECTED] wrote:
I am uncomfortable with what feels to me like an architectural deviation.
It would seem that an AG goal is portability to many platforms. This
seems implicit with java, and certainly depends on java being
supported on many platforms.
By using
Just remember that one of the main reasons that there's an awkward
display of tons of JARs now is that the DB2 driver (did? does?)
require 3 JARs to all be added in order to function, and only one of
those has any kind of driver implementation AFAIK. (I think one is a
license and not sure about
I would think we'd need to check for Java 1.5 more urgently than Java 1.5.
Thanks,
Aaron
On 4/10/07, Donald Woods [EMAIL PROTECTED] wrote:
Wanted to see what everyone's opinion was before I integrate the patch
for G2759 -
https://issues.apache.org/jira/browse/GERONIMO-2759
0: Given the attention on 2.0, I'm not optimistic about there being
another release in the 1.2.x stream, and I don't really like the
problems Hernan found (database pools and shutdown exception). I'll
change to a +1 if someone commits to fixing and releasing these in a
1.2.1 fairly quickly.
For what it's worth, Jason's proposal sounds reasonable to me*. But I
don't really fancy changing all the current names either. :)
Thanks,
Aaron
* Well, I can't say that 1.1MR3-1-SNAPSHOT made sense at first glance,
but the 1.1MR3-1 followed by 1.1MR3-2 seems clear.
On 3/29/07, Jason
On 3/9/07, Anita Kulshreshtha [EMAIL PROTECTED] wrote:
The Database Pool wizard generates console.dbpool as groupId for the
generated rar. The version is always 1.0. I think the groupId should be
o.a.g.something and the version should match geronimo's version.
Suggestions?
I disagree --
So we talked about removing the Sun schemas from our site. But I
don't get it -- now all the links to the Geronimo schemas are just
plain text instead of links?? The whole point of having that page is
so that people can click through to the actual Geronimo schemas.
On 3/7/07, Jason Dillon [EMAIL PROTECTED] wrote:
I wouldn't say they are broken... they are just plain missing. ;-)
True. They must live on the East coast, and have escaped to a warmer
climate. :)
Thanks,
Aaron
On Mar 7, 2007, at 11:14 AM, Aaron Mulder wrote:
So we talked about
? it will be a great experience with the new site!!! :-p )
Cheers!
Hernan
Aaron Mulder wrote:
So we talked about removing the Sun schemas from our site. But I
don't get it -- now all the links to the Geronimo schemas are just
plain text instead of links?? The whole point of having that page is
so
You mean all the links from here?
http://geronimo.apache.org/schemas.html
I thought we only linked to the Geronimo ones in our site and pointed
to the Sun site for the Sun ones, though.
Thanks,
Aaron
On 3/6/07, Jason Dillon [EMAIL PROTECTED] wrote:
Anyone know where these are
On Mar 6, 2007, at 2:44 PM, Aaron Mulder wrote:
You mean all the links from here?
http://geronimo.apache.org/schemas.html
I thought we only linked to the Geronimo ones in our site and pointed
to the Sun site for the Sun ones, though.
Thanks,
Aaron
On 3/6/07, Jason Dillon [EMAIL
Pluto 1.1 integration would be great, and would allow much more
reasonable dynamic additions of screens to the console. Someone just
needs to do the work. :)
I expect Jetspeed 2 would do the same, but I think Pluto would be much
more lightweight, so I would think it would be preferable for the
Also there have been reports that some console screens are broken
(JMS, maybe?) and it would be nice to fix those for the 1.2 final
release.
Thanks,
Aaron
On 2/22/07, Dain Sundstrom [EMAIL PROTECTED] wrote:
This release is finally wrapping up. We are basically waiting on
final releases
On 2/6/07, Dain Sundstrom [EMAIL PROTECTED] wrote:
...
So do you agree that Global JNDI is the defacto required
implementation for these and other similar entries?
Sounds like it to me.
Thanks,
Aaron
+1 lets bring it in, this is great
Thanks,
Aaron
On 1/31/07, Filip Hanik - Dev Lists [EMAIL PROTECTED] wrote:
This is the formal vote to accept the J2G codebase and bring it through
incubation (see
http://marc.theaimsgroup.com/?l=geronimo-devm=116906208022256w=2)
The final destination is
Welcome Chris!
Aaron
On 1/24/07, Matt Hogstrom [EMAIL PROTECTED] wrote:
In recognition of Chris' contributions to DayTrader (new UI, new
runtime modes) and his sustained set of patches and nagging he has
accepted our offer to join our merry little band of pirates.
Please join me in welcoming
I think the decision should depend to some degree on whether the
module is tightly integrated such that it needs to be re-released for
every Geronimo release. I'm not sure about the directory plugin, but
I think a lot of plugins that involve third-party software probably
don't need to be
We have seen a number of errors on the user list that turned out to be
plans with elements in the wrong order. I'd have preferred if there
wasn't a specific order I think, but I don't feel strongly enough to
want to change all the schemas.
Thanks,
Aaron
On 1/14/07, Jason Warner [EMAIL
You can install a plugin from the command line deploy tool -- just use
the install-plugin command point it to the CAR file. The down side
is that if that plugin has dependencies, they will be resolved against
a remote repository (as listed in the plugin metadata). So you'd
presently have to
[
http://issues.apache.org/jira/browse/GERONIMO-1930?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12461843
]
Aaron Mulder commented on GERONIMO-1930:
Right now you can't add new login module types to the console
I put a proposal in for Java EE 5 development and community update
or something like that. If it goes through, anyone's welcome to speak
at it.
Thanks,
Aaron
On 12/21/06, Matt Hogstrom [EMAIL PROTECTED] wrote:
Folks,
I have requested a BOF at JavaOne. It totally slipped my mind and I
leave this one open as an
Apache Geronimo community BOF.
Thanks for the quick response.
On Dec 21, 2006, at 3:48 PM, Aaron Mulder wrote:
I put a proposal in for Java EE 5 development and community update
or something like that. If it goes through, anyone's welcome to speak
at it.
Thanks
+1
On 12/14/06, Dain Sundstrom [EMAIL PROTECTED] wrote:
The 1.2-beta release and all dependencies are cut and awaiting your
vote! All the files are available in a staging area in my home dir on
people.
http://people.apache.org/~dain/stage/org/apache/geronimo/genesis
genesis-1.1-incubating
I just want to add that for Geronimo plugins, it's not very useful to
have the car-maven-plugin write the environment into the deployment
plan. More often that not, you want the source tree to contain a
fully valid and correct deployment plan, so you can easily redeploy
the module (e.g. on the
On 12/14/06, Guillaume Nodet [EMAIL PROTECTED] wrote:
Just a side note. It took me some time to understand that you *have* to
build Geronimo if you want to build a plugin against a SNAPSHOT version.
The reason is that the plugin loads cars that depend on snapshot jars (it works
against the new
So what you get back is ordinarily a proxy to the actual service. If
you get the abstract name for the returned module builder (the kernel
has a call to do that) and then get a fresh proxy to it (from the
proxy manager from the kernel), does it include your new interface?
If so, it suggests that
of the new class in the GBeanInfo in the new
class?)
Thanks,
Aaron
On 12/1/06, Sachin Patel [EMAIL PROTECTED] wrote:
Thanks Aaron.. see inline.
On Dec 1, 2006, at 4:20 PM, Aaron Mulder wrote:
So what you get back is ordinarily a proxy to the actual service. If
you get the abstract name
. If there
still is a warning, I'd expect to see it in standard output for the
build, and if not there, I have no idea.
Thanks,
Aaron
Aaron Mulder wrote:
So what you get back is ordinarily a proxy to the actual service. If
you get the abstract name for the returned module builder (the kernel
has
Unfortunately, XMLBeans is used pretty extensively by the Geronimo
deployment system, so it's not just a matter of avoiding using the web
container's class loader. More particularly, if your plugin will
include a deployer component, you're working directly with the
Geronimo deployment system
On 11/25/06, David Jencks [EMAIL PROTECTED] wrote:
If your machine is unsecured, then people deploying rogue apps in
geronimo should probably be the least of your worries.
If you are still concerned about the security of the hot deployer,
you should turn it off.
Except that if the machine is
Well, just for the record, I don't think the performance was all that
great under 1.1.x either. Even then the Jetty web console was the one
module that took a noticeably long time to start. It sounded from
Dain's message earlier like adding some caching for abstract names
might help.
Thanks,
Are we supposed to have the license on every XML, HTML, XSD, etc? I
guess so, I just had thought of the license issue as more
Java-centric.
Thanks,
Aaron
On 11/15/06, Kevan Miller [EMAIL PROTECTED] wrote:
I took a look at the binary and src distributions that Dain created last
week. I
[
https://issues.apache.org/activemq/browse/AMQ-908?page=comments#action_37459 ]
Aaron Mulder commented on AMQ-908:
--
Here are the Geronimo ones:
[GeronimoUserPrincipal|http://svn.apache.org/viewvc/geronimo/server/trunk/modules/geronimo
First, if you want to see the time taken for each module, use the
--long startup option not the progress bar.
Second, I think the best way to resolve the space issue is to show
only the artifact ID (or artifact ID and version) instead of the whole
Artifact name (group, artifact, version, type).
On 11/7/06, Paul McMahan [EMAIL PROTECTED] wrote:
OK I'll take a look and start cranking through the list. Aaron please
raise a flag if you want me to hold off.
No, be my guest -- clearly I haven't gotten around to it. :)
Thanks,
Aaron
Just be aware that any of the changes that affect config.xml or other
non-Java files (keystores or whatever) probably need to be applied to
the TCK configuration as well.
Thanks,
Aaron
On 11/7/06, Aaron Mulder [EMAIL PROTECTED] wrote:
On 11/7/06, Paul McMahan [EMAIL PROTECTED] wrote:
OK
So for the JPA plugin, we just applied the transformer in the class
loader. I'm not super-confident of the specific implementation -- but
is there a reason why this approach wouldn't work for us in Geronimo
(since we have a custom class loader already)?
straightforward approach than the GBean-ordering option
(though that feature probably has other advantages).
Thanks,
Aaron
On 11/6/06, David Jencks [EMAIL PROTECTED] wrote:
On Nov 6, 2006, at 12:47 PM, Aaron Mulder wrote:
So for the JPA plugin, we just applied the transformer in the class
loader
On 11/6/06, David Jencks [EMAIL PROTECTED] wrote:
can you go into more detail on what you are thinking of? I don't
understand. It looks to me as if you are proposing building a list
of what are now PersistenceUnitGBeans directly into the
configuration. We can't extract a Transformer from
Have you considered using the in-place deployment features to load
classes from target/classes or something like that? I know for
example IDEA can generate an exploded WAR on each build which you
could deploy as an in-place deployment...
Thanks,
Aaron
On 11/3/06, Sachin Patel [EMAIL
Instead of leaving it up to GBeans to handle, do you think we should
just put a hook into the Configuration where you can specify byte code
transformers that it will apply to the Configuration ClassLoader? Now
that the transformer API is there, I'm surmising that JPA may not be
the only area
I would say that the startup and shutdown sequences should not show
any Log4J log output or stack traces, tested under both JDK 1.4 and
JDK 1.5. Also, all current functionality in all portlets in the
console should work as expected. And the deploy tool should be able
to deploy, undeploy, and
/plugin.jelly:72:-1:
car:package null
Total time : 2 minutes 58 seconds
Finished at : Tuesday, October 31, 2006 12:51:36 PM EST
On 10/31/06, Aaron Mulder [EMAIL PROTECTED] wrote:
I tried to build 1.1 branch head and got the error below. Any ideas?
Thanks,
Aaron
[ http://issues.apache.org/jira/browse/GERONIMO-2478?page=all ]
Aaron Mulder reassigned GERONIMO-2478:
--
Assignee: Aaron Mulder
ContextForwardServlet should have a registration mechanism
I tried to build 1.1 branch head and got the error below. Any ideas?
Thanks,
Aaron
+
| configurations Daytrader using derby deployed on jetty
| Memory: 56M/67M
+
DEPRECATED: the default goal should be specified
into some similar problems earlier while building from trunk and
if I remember correctly, those problems got resolved after bootstrapping
openejb.
--vamsi
On 10/31/06, Aaron Mulder [EMAIL PROTECTED] wrote:
I also got this in the JSP Examples and Servlet Examples. I put one
of those stack traces
[ http://issues.apache.org/jira/browse/GERONIMO-2478?page=all ]
Aaron Mulder updated GERONIMO-2478:
---
Description:
Currently the ContextForwardServlet must be deployed separately for each URL
path to redirect.
This does not work well for plugins, nor
– Matt Hogstrom
* Virginia – Paul McMahan
* RTP Trangle User's Group – Kevan Miller
* Gainesville, FL – Joe Bohn
- JAOO - Jacek Laskowski, Bill Dudney and Matt Hogstrom presented on
Geronimo.
- ApacheCon - Two presentations
* Jeff Genender
* Aaron Mulder and Bruce Snyder co-presented
On 10/30/06, Jason Dillon [EMAIL PROTECTED] wrote:
Geronimo is, IMO, fundamentally flawed in how it is configured.
Because of this we can not even easily use Geronimo from a dist
archive to run components for the gbuild.org hosts. We need to be
able to easily change the configuration that it
the GBeans in
every module, it could... and plugins can specify the content they
want to add to config.xml when they are installed.
Thanks,
Aaron
On Oct 30, 2006, at 2:24 PM, Aaron Mulder wrote:
On 10/30/06, Jason Dillon [EMAIL PROTECTED] wrote:
Geronimo is, IMO, fundamentally flawed in how
Just for the record, I like having a post-processed module format.
I wouldn't mind if it had XML data instead of serialized objects, but
I am not really in favor of throwing it away and making a standard
(pre-processed) J2EE JAR+DD+deployment plan into our official module
format. So I'd rather
[
http://issues.apache.org/jira/browse/GERONIMO-2342?page=comments#action_12445426
]
Aaron Mulder commented on GERONIMO-2342:
The easiest thing would be to disable the SSL connector (add load=false to
the SSL connector GBean entry
It woudl be great to switch the plugin installer to use the Maven code
to interact with the repository (search for matching versions, do the
downloads, etc.). I don't know much about the Maven code/libraries or
I would have done it by now.
Thanks,
Aaron
On 10/27/06, Jacek Laskowski [EMAIL
I'd like to do some work on 1.1.2, but I haven't had a lot of time
lately. For my part, I guess the schedule depends on whether I get
time before 1.2 looks imminent. :)
Thanks,
Aaron
On 10/26/06, Vamsavardhana Reddy [EMAIL PROTECTED] wrote:
Is there a specific target date for 1.1.2 and
[
http://issues.apache.org/jira/browse/GERONIMO-911?page=comments#action_12443623
]
Aaron Mulder commented on GERONIMO-911:
---
Not only that, but you get a different warning if the host name of the HTTPS
server doesn't match the host name
This is a good conversation to have -- all the options we've
considered previously seem bad in some way or other.
The original goals were:
1) require that a user enter a password to view or manipulate the keystore
2) provide a way for the server to remember the password(s) needed at
runtime, but
On 10/18/06, Vamsavardhana Reddy [EMAIL PROTECTED] wrote:
David,
Myself and Guillaume had a discussion on IRC and come up with a conclusion
that all methods should require storePassword. If the null is passed as
storePassword and the keystore is not unlocked for use the methods will
throw an
I still have the problem that you can create a new keystore and add
new password-protected keys to the keystore(s) at runtime. So I don't
see how at login/startup anything will be able to populate all the
needed passwords.
If you could add passwords to the Subject at runtime and they would be
Just a note -- if you change the Derby dependency, it's best to change
it in the original deployment plan for the Geronimo module, update the
plugin metadata, and build a new plugin file (CAR). Ideally, both the
serialized CAR metadata and the XML plugin metadata will include the
same dependency
the Geronimo plans used to deploy the modules in the
first place) should update the dependency elements used in those
plans and recreate the CAR files. It's not so easy to do that if you
are only dealing with the plugin binaries.
Thanks,
Aaron
On 10/17/06, Aaron Mulder [EMAIL PROTECTED] wrote:
Just
On 10/14/06, Brian Chan [EMAIL PROTECTED] wrote:
The latest Liferay portal plugins are now available on.
http://geronimo.liferay.com/plugins
Nice!
It'd be great if we can add it to the default list of available plugin
repositories for Geronimo 1.2 and on.
We can actually add it for 1.1.1
On 10/13/06, Shiva Kumar H R [EMAIL PROTECTED] wrote:
My query now is:
1) Why is pattern element listed as a choice? Isn't it always required?
If you're positive that there's only one GBean with the appropriate
interface in the whole server, you may be able to omit the pattern and
get that one
One option would be to distribute the service as a plugin.
The initial process is the same in any case:
- Implement the GBean
- Create the plan (geronimo-service.xml) with any necessary dependencies
- Package the GBean class(es) and optionally the plan into a JAR
- Deploy the JAR to Geronimo as
I thought we had gotten rid of this but...
It looks like in Geronimo 1.1.1, the Jetty server configuration
includes Spring 1.2.5 on its class path.
Unfortunately, this means that no web application can use any other
version of Spring that it inherits from a class path parent. It can
package
Issue Type: Bug
Security Level: public (Regular issues)
Components: Jetty
Affects Versions: 1.1.1
Reporter: Aaron Mulder
Fix For: 1.1.2
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one
So I'm trying to build a console extension with the car-maven-plugin.
It doesn't work. A web app that depends on the console cannot be
processed by the car-maven-plugin, because the console cannot be
loaded, because its classpath includes JARs in the WARs in the EAR and
the mini-Geronimo in the
)
Components: console
Affects Versions: 1.1.1
Reporter: Aaron Mulder
Fix For: 1.1.2, 1.2
It's unnecessarily hard to build console extension plugins because the
car-maven-plugin can't access JARs in a WEB-INF/lib directory. The console web
apps should not package any
On 10/9/06, Jeff Genender [EMAIL PROTECTED] wrote:
Could you give a quick email to explain how to set up a plugin site,
what is needed, directory and xml layouts?
Just like a Maven 2 repo, except with a geronimo-plugins.xml in the
root directory. The only files that are actually used by the
On 10/5/06, David Jencks [EMAIL PROTECTED] wrote:
Online-deployer is empty just like the rest of the configs that are
servers. It relies on manifest classpath and the configuration it
contains. IIRC online-deployer.car is the same file as
deployer.jar. I guess you're right that a little more
Security Level: public (Regular issues)
Components: console
Affects Versions: 1.1.1
Reporter: Aaron Mulder
Fix For: 1.1.2, 1.2
Currently the ContextForwardServlet must be deployed separately for each URL
path to redirect.
This does not work well
Issue Type: Bug
Security Level: public (Regular issues)
Components: Plugins
Affects Versions: 1.1.1
Reporter: Aaron Mulder
Fix For: 1.1.2, 1.2
The plugin installer should show status Downloading X from Y during a
download, but it seems to get stuck
Well for starters, there's neither an attributes.xml nor an
attributes.xsd... :)
But the answers I think are that when we first did it it was pretty
simple and XMLBeans seemed kind of heavyweight, and there was an
ongoing debate about whether we'd actually want to stick with XMLBeans
for the
, 2006, at 3:42 PM, Aaron Mulder wrote:
Well for starters, there's neither an attributes.xml nor an
attributes.xsd... :)
But the answers I think are that when we first did it it was pretty
simple and XMLBeans seemed kind of heavyweight, and there was an
ongoing debate about whether we'd actually
The plugins should use this, since they have similar restrictions at
install time but not at runtime. It would be nice to carry that over
so any installed Java 1.5-only plugins just wouldn't start if you
started Geronimo under Java 1.4.
Still, if you try to start a module manually (with the
[
http://issues.apache.org/jira/browse/GERONIMO-2320?page=comments#action_12440162
]
Aaron Mulder commented on GERONIMO-2320:
Just had it happen on the Jetty build with a PostgreSQL pool (likewise when I
just downloaded the driver
On 10/5/06, anita kulshreshtha [EMAIL PROTECTED] wrote:
I do not see this problem on the trunk.
That's good, but I'd still like to see the issue fixed in the 1.1 line...
Thanks,
Aaron
- Original Message
From: Aaron Mulder (JIRA) dev@geronimo.apache.org
To: dev
On 10/5/06, Jason Dillon [EMAIL PROTECTED] wrote:
The idea was to get something working now... and then refactor later.
No problem -- once you check it in let's put in a Jira to link it up
for runtime start operations too.
Thanks,
Aaron
On Oct 5, 2006, at 4:33 AM, Aaron Mulder wrote
I think we need to keep enough in there that the command-line deploy
tool still works. It looks like online-deployer is empty (or else I
would have said to keep that), but I think j2ee-security is required
for the JMX remoting used by the deploy tool. Without this, I think
you'll have to mangle
:
Do you (Aaron) have a simple example of how to implement a new bit to
stuff into the webconsole and tickle it to be installed when a module/
plugin is loaded?
--jason
On Jun 24, 2006, at 4:16 AM, Aaron Mulder wrote:
So to get a GBean running in Geronimo, you need to write a deployment
plan
As a user, it is a convenience to be able to have a single version
number to track across all the spec releases. So there's only one
variable to track.
However, I still don't think this is a very good approach. Our specs
tree will continue to expand with new JSRs and J2EE releases,
especially
On 10/2/06, Dain Sundstrom [EMAIL PROTECTED] wrote:
When it comes to futzing w/ the endorsed dirs I would rather have
it in the up front and in my face via a script than have some cute
code forking and setting things behind the scenes.
I couldn't agree more. I dislike Java forking Java more
1 - 100 of 2990 matches
Mail list logo
