[
http://issues.apache.org/jira/browse/GERONIMO-557?page=comments#action_58195 ]
Sandip Ghayal commented on GERONIMO-557:
Also we should allow facility where one can change the plan without need to
redeploy the Application.
EJB1 points to
I have just checked in the beginnings of a SpringDeployer (revision 128446).
This requires an updated version of Spring (1.1.3). So, if you tend to
run your builds offline, you will need to hook up and let maven sort
it all out.
A Spring deployable currently looks like this - e.g. :
foo.spr/
Can this test be rewritten using wait/notify or a phantom reference?
-dain
--
Dain Sundstrom
Chief Architect
Gluecode Software
310.536.8355, ext. 26
On Jan 27, 2005, at 9:24 AM, Sandip Ghayal wrote:
Well we are not doing anything much
Just sleeping for 3 second and then sleeping for 7
seconds.
Ok
Nope. The point is to see if the security code removes the security
context all by itself. Using wait/notify would require wiring test code
directly into the server.
The real question is why it takes 1.2s for code that should take
milliseconds.
Regards,
Alan
-Original Message-
Jules,
This is great stuff - I'm just downloading everything here at work and I
will start to look at the Spring side of things - specifically
satisfying dependencies using the beans that are deployed in Geronimo.
Regards,
Rob
Jules Gosnell wrote:
I have just checked in the beginnings of a
What is the preferred mechanism for contributing this code? Should Jules
check it all in. I'm not that familiar with SVN - can I create a patch
like with CVS?
Rob
Rob Harrop wrote:
Jules,
This is great stuff - I'm just downloading everything here at work and
I will start to look at the Spring
Well I did some debugging and its slowness of my
machine.
My machine is not able to accurately time 300ms from
the time 1 second timeout was set.
I also found during investigation that sometimes even
the timer expires at 1300-1400ms. (I think that scan
timer expired late)
I don't thing if
Rob,
You'll need to refresh your view - I have made a few changes, including
quickly hacked up support for one-level of nested packed jars:
foo.spr/
META-INF/spring.xml
foo/Foo.class
bar.jar
bar/Bar.class
...
This is useful as you can just throw any jars that your Spring app
Is there a test :)?
Jules Gosnell wrote:
Rob,
You'll need to refresh your view - I have made a few changes,
including quickly hacked up support for one-level of nested packed jars:
foo.spr/
META-INF/spring.xml
foo/Foo.class
bar.jar
bar/Bar.class
...
This is useful as you can
Rob Harrop wrote:
Is there a test :)?
errr... ehemmm...
I'll send you a really simple .spr that I have cobbled up, but as yet
there is no testsuite - I couldn't face digressing from getting a
working deployer long enough to grok how to set up and check in a test -
It is on my list.
smacked
Hello,
why is geronimo-1.0-M3-src.tar.gz incomplete? It has a size of only
about 3MB and contains only the applications folder, while
geronimo-1.0-M3-src.zip has a size of about 5.5MB and contains 9 folders
and many more files.
Kind regards
Peter Nabbefeld
What would you think of giving spring gbeans jsr-77 like names? I've
converted just about all the other gbeans to this format. I'm not sure
if spring apps can be nested like jars, but how about something like
geronimo.server:
So, Rob and I have been talking about exactly what we want out of the
Spring integration...
I've thought a little and decided to share it with the whole list as
well as Rob, so that anyone else with an interest can join in...
I think that the integration is really one of contained components,
Jules Gosnell wrote:
Rob,
You'll need to refresh your view - I have made a few changes, including
quickly hacked up support for one-level of nested packed jars:
foo.spr/
META-INF/spring.xml
foo/Foo.class
bar.jar
bar/Bar.class
...
This is useful as you can just throw any jars
I think it might be an idea to create a GBean for the Spring
ApplicationContext but not for each bean. Spring will have the ability
to register with JMX for bean management, plus some Spring beans have
weird lifecycles which are better handled internally. Spring currently
doesn't provide a
On Jan 28, 2005, at 9:51 AM, Sandip Ghayal wrote:
Just continuing our discussion from yesterday.
I am little confused.
As I understand from yesterdays discussion, I need to
deploy Resoruce first and then the EJB
yes, unless they are both in an ear
So I tried to deploy connector rar file first and
Jules,
You hit the nail on the head. At my current client, I just got done
implementing Spring ApplicationContext objects into JNDI that are
managed via JMX MBeans, so separate applications could share the POJOs
between themselves. This proved to be huge when we are getting Portlets
that
David,
we have a lot to think about :-) but how to map the deployable into the
gbean world is high on my list. I have to read code and do some
thinking. I'll get back to you for some more guidance on this and other
stuff in a little while.
Cheers,
Jules
David Jencks wrote:
What would you think
Excellent work.
One big issue here is Geronimo does not require JMX anymore. JMX is an
option for the kernel but it is not a dependency or guaranteed to even
be available, so a JMX based solution will not work. My guess is we
will need to write code similar to the existing spring JMX
Dain Sundstrom wrote:
Excellent work.
One big issue here is Geronimo does not require JMX anymore. JMX is
an option for the kernel but it is not a dependency or guaranteed to
even be available, so a JMX based solution will not work. My guess is
we will need to write code similar to the
[ http://issues.apache.org/jira/browse/GERONIMO-558?page=history ]
toby cabot updated GERONIMO-558:
Attachment: distribute-workaround-patch.txt
this patch works for me. i doubt it's a real fix, but if anyone needs a
workaround this might help.
From the source:
// I know that this should not be here (in the j2ee package) but,
// until someone who knows what they are doing has time to have a look
// at it, this seems the path of least resistance...
Move to the spring module?
--
Jeremy
[ http://issues.apache.org/jira/browse/GERONIMO-488?page=history ]
Greg Wilkins reassigned GERONIMO-488:
-
Assign To: Greg Wilkins (was: David Jencks)
jetty dispatch handling doesn't set component context, tx, or security
properly in geronimo
[ http://issues.apache.org/jira/browse/GERONIMO-510?page=history ]
Greg Wilkins reassigned GERONIMO-510:
-
Assign To: Greg Wilkins
Jetty should use Geronimo thread pools
--
Key: GERONIMO-510
[ http://issues.apache.org/jira/browse/GERONIMO-488?page=history ]
Greg Wilkins reassigned GERONIMO-488:
-
Assign To: David Jencks (was: Greg Wilkins)
oops wrong issue
jetty dispatch handling doesn't set component context, tx, or security
[ http://issues.apache.org/jira/browse/GERONIMO-558?page=history ]
David Jencks closed GERONIMO-558:
-
Resolution: Fixed
Fix Version: 1.0-M4
Fixed in revision 148935. Use the web app classloader's copy of Servlet to
test inheritance. This is
Jeremy Boynes wrote:
From the source:
// I know that this should not be here (in the j2ee package) but,
// until someone who knows what they are doing has time to have a look
// at it, this seems the path of least resistance...
Move to the spring module?
--
Jeremy
spring - or spring-builder ?
I
27 matches
Mail list logo
