Question about web app login, user principal, and authentication
i've been getting very confused by some behavior related to being logged in and authentication while working with jetspeed, and I hope someone can shed some light on what should be happening. Lets suppose you have a web app with some secured resources and some unsecured resources. If you start by accessing the unsecured resources, there is no doubt, you have not authenticated, getUserPrincipal() returns null, and you would get the DefaultSubject from ContextManager. Now if you access a secured resource, you log in, getUserPrincipal() returns a non-null principal, and you get the actual Subject from ContextManager during the call to the secured resource. Now if you go back and access an unsecured resource while still logged in, the servlet spec says you should still get the logged-in getUserPrincipal value, but ContextManager returns the DefaultSubject. So in particular calls to say an ejb will be based on the defaultSubject, not the logged in Subject, even though you are logged in. Is this correct? Or, should any access to a resource while logged in result in the ContextManager being set to the logged in subject? Spec references would be very welcome :-) thanks david jencks
Re: Geronimo 2.0
2006/1/6, Alan D. Cabrera [EMAIL PROTECTED]: Bruce Snyder wrote, On 1/5/2006 4:26 PM: Then we should probably consider making a decision that the HEAD should contain 2.x work only. If any fixes need to be done to the 1.x code then proper branching and tagging should occur to facilitate that work. Good point. What do others think? Hi, That's exactly what I had already proposed in my previous response. There's no need to complicate things unless some need arises. I remember when Alan stated that patches will be applied to a branch and would eventually end up as 1.0.1 or 1.1 and on. I think HEAD should always reflect the state of the main releases of Apache Geronimo, i.e. Apache Geronimo 2.0, 3.0 and on. The numbers after the dots would be in branches. Alan Jacek
[jira] Created: (GERONIMO-1423) log4j.properties's category is ignored
log4j.properties's category is ignored
--
Key: GERONIMO-1423
URL: http://issues.apache.org/jira/browse/GERONIMO-1423
Project: Geronimo
Type: Bug
Versions: 1.0
Environment: JRE 1.5.0_06, Linux
Reporter: viewhero
Priority: Critical
log4j.properties that is included war file's WEB-INF/classes.
like this.
---
log4j.rootCategory=ERROR, A1
log4j.appender.A1=org.apache.log4j.ConsoleAppender
log4j.appender.A1.layout=org.apache.log4j.PatternLayout
log4j.appender.A1.layout.ConversionPattern=%d{-MM-dd HH:mm:ss} %-5p [%t]
(%F:%L) - %m%n
log4j.category.jp.ne.xxx=ERROR
---
but, INFO message wrote to geronimo.log.
geronimo must read log4j.properties each web applications.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
Re: Geronimo 2.0
2006/1/6, John Sisson [EMAIL PROTECTED]: I agree we don't want too many branches. Hi John, Well, we should get used to them ;) Especially when Java EE 5 work takes off. I think there will be more refactorings than ever before. It's going to be lots of fun (sarcasm). Will fixes for the 1.0.1 release (hopefully we can get out in a few weeks) be committed to the 1.0 branch and then we create another tag for the 1.0.1 release? I'm not too familiar with svn branching/tagging stuff, but AFAIK they're just copies of the HEAD. If so, only the disk space limits us (which is not the case yet). So, if a need to fix something shows up, we will likely have to apply it to HEAD and branch, be it 1.0.1 or 1.1 depending on its value/importance. Do we have any guesstimates on when we would have JEE 5 development completed? I'm pretty sure we don't. Why would that be beneficial? How long it will be before we can deliver a release with some innovations in it, since we previously agreed we want to release frequently? I think we should stick with the 3-months period for small releases (like 1.0.1) and 6-months period for larger ones (like 1.1) or even the most important (like 2.0, 3.0). That could be our goal, and the time will show how we go ;) If this is going to be a while then we should discuss the work that is planned for the near future and whether there are enhancements that can be delivered in a releases before JEE 5, and if so, how that could be managed. Well, we don't have to wait till JEE 5 development is announced. You/anybody can start his/their work on a branch and merge it with the HEAD when completed. Of course, the more talk about it the better. That's my understanding of how it could (ought to?) work. Could some of the planned enhancements impact the stability of head development and therefore should be done in a branch? E.G. would we have stability problems doing JEE 5 development, re-arch of security, maven 1 to maven 2 migration, xbean support, corba impl etc. all in head? Yes, after having it completed and heavily tested on a branch. The views are indeed mine and I would appreciate any comments on it John Jacek
Re: ANNOUNCE Geronimo Version 1.0 Available for Download
2006/1/6, Matt Hogstrom [EMAIL PROTECTED]: The Apache Geronimo team is proud to announce the availability of Geronimo Version 1.0 for immediate download. Please visit http://geronimo.apache.org/downloads.html. Hi Matt, Good job and thanks for taking care of the 1.0 release! I learnt lots of good practicies of how to lead the release process. You are my most valuable contact when/if I ever decide to become a release mgr ;) I spot however several places with Geronimo or even geronimo mentioned without its FQN (=fully qualified name), which is Apache Geronimo. AFAIR, it's the only name we should use in the public press, shouldn't we? Apache Geronimo 1.0 introduces complete J2EE 1.4 certification, support for Java Business Integration (JBI) I don't understand it. How do we support JBI? Do we provide a configuration for ServiceMix (or possibly Celtix or another JBI container) ? I think it we don't, unfortunatelly. I wish I were wrong. Jacek
RE: problem with Geronimo-1.0
Hi friends,
With new release of Geronimo-1.0, my code
is working correctly.
Rakesh Ranjan
From: Ranjan, Rakesh (Cognizant)
[mailto:[EMAIL PROTECTED]
Sent: Thursday, January 05, 2006
10:01 AM
To: dev@geronimo.apache.org
Subject: Re: problem with
Geronimo-1.0
Thanks Aaron for GMail account invitation. I will setup a
gmail account.
Sorry for posting the wrong code. The correct code is
Kernel kernel=KernelRegistry.getSingleKernel();
ObjectName gbQuery =
JMXUtil.getObjectName(*:j2eeType=TransactionManager,*);
Set gbeanNames = kernel.listGBeans(gbQuery);
for (Iterator i = gbeanNames.iterator(); i.hasNext();) {
ObjectName gbeanName = (ObjectName)
i.next();
System.out.println(gbeanName);
/* The above print statement is giving
geronimo.server:J2EEApplication=null,J2EEModule=org/apache/geronimo/Server,J2EEServer=geronimo,j2eeType=TransactionManager,
name=TransactionManaer
*/
}
TransactionManager tm = (TransactionManager)
kernel.getProxyManager().createProxy(gbeanName,TransactionManager.class);
Hey I have just written web aaplication. I have put the
above code in a java class. Then calling the above class from the JSP page.
I am just getting the following Exception trace :
java.lang.IllegalArgumentException:
Could not get GBeanInfo for target object:
geronimo.server:J2EEApplication=null,J2EEModule=org/apache/geronimo/Server,J2EEServer=geronimo,j2eeType=TransactionManager,
name=TransactionManager
Re: problem with Geronimo-1.0
Reply (Restricted by the Administrator)
| Show Only this Message
Rakesh,
It would help to get the information I asked for: a more complete
chunk of your code, plus all the pertinent output and a full stack
trace. Also, please mention what you've deployed into the server (if
anything) other than this application. Again, it's impossible to
debug your problem without knowing what your code is doing.
Let me try to explain in more detail. Here's the code you posted:
Set gbeanNames = kernel.listGBeans(gbQuery);
for (Iterator i = gbeanNames.iterator(); i.hasNext();) {
ObjectName gbeanName = (ObjectName) i.next();
System.out.println(gbeanName1);
}
TransactionManager tm = (TransactionManager)
kernel.getProxyManager().createProxy(gbeanName,
TransactionManager.class);
Now, the gbeanName variable in the for loop is declared in the for
loop, so it's not the same as the gbeanName variable in the
createProxy call. Further, the println in the loop is using a
variable called gbeanName1. So in these three lines, there are three
different variables being used. Of them, we only see where gbeanName
in the loop is assigned, but it's never used. We need to know (and
you need to find out) where the values gbeanName1 and gbeanName (the
one outside of the loop) are assigned. Note that YOU ARE NOT USING
THE RESULT OF THE listGBeans CALL FOR ANYTHING (except to control the
number of times you print gbeanName1) in the code you supplied, so
when people suggest that listGBeans is broken that conclusion is not
supported by the code you posted. That's why I'm asking you to post
more, and hunt down how those variables are being assigned.
On 1/4/06, Ranjan, Rakesh
(Cognizant) [EMAIL PROTECTED] wrote:
Hi,
Sorry Aaron about confidential information footers. But i cann't do
anything because it is generated by the mail server.
Presumably your company doesn't want you sending information to the
world from your company e-mail account if they attach that to every
message. I sent you an invitation to use GMail for your personal
correspondance. :)
Thanks,
Aaron
The value contained in the variable 'gbeanName' is :
geronimo.server:J2EEApplication=null,J2EEModule=org/apache/geronimo/Server,J2EEServer=geronimo,j2eeType=TransactionManager,
name=TransactionManaer
I have tried the query using the full object name:
geronimo.server:J2EEApplication=null,J2EEModule=geronimo/j2ee-server/1.0/car,J2EEServer=geronimo,
j2eeType=TransactionManager, name=TransactionManager
Its working correctly. I am able to get the TransactionManager instance
using the full GBean name.
But i would like to know why this thing is not working with
kernel.listGBeans(). Is it a bug in Geronimo-1.0 ?
Rakesh Ranjan
Re: problem with Geronimo-1.0
Grr, more confidential information footers. Please don't do that to
public mailing lists! If your information is confidential,
don't send
it to the world, and if it's not confidential, please don't assault
us
with the legalese!
Anyway, now that that's off my chest, Geronimo cannot (well,
definitely *should* not) produce an incorrect ObjectName out of thin
air, so you need to figure out where you're getting the ObjectName
containing org/apache/geronimo/Server from. In the code
snippet you
showed, you do a lookup and print all the results, but then you try
to
Re: Geronimo 2.0
I think that doing new development on the HEAD is the way to go, i.e. 2.0 development should happen here. Then what goes on the 1.x branch (es) is maintenance and bug fixing. This will certainly serve to stabilize (and perhaps even stall) development on 1.x; but that is not a bad thing. Users will experience that 1.x releases are more compatible in many ways because all the creative big changes happen elsewhere. Kresten Krab Thorup [EMAIL PROTECTED] On Jan 6, 2006, at 1:28 AM, Alan D. Cabrera wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Bruce Snyder wrote, On 1/5/2006 4:26 PM: On 1/5/06, Alan D. Cabrera [EMAIL PROTECTED] wrote: How do we want to stage this effort in terms of SVN organization? When should we cut a 2.0 development branch? I suppose that the JEE 5 work would be best suited to a 2.0 branch. That means that there is a potential to have to do a lot of double work. What I mean to say is that any new innovations being committed to the HEAD will need to be refactored and committed to the 2.0 branch. And this work will increase more with the addition of more branches (e.g., 1.1, 1.2, etc.). You touched on the concern that I had. I'm thinking that once we cut this, there will be no further work on 1.x, because everyone will want to work on 2.x. Then we should probably consider making a decision that the HEAD should contain 2.x work only. If any fixes need to be done to the 1.x code then proper branching and tagging should occur to facilitate that work. Good point. What do others think? Regards, Alan -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDvbmY1xC6qnMLUpYRAsEZAJ4hKUKXBCTxkTQfPMXGOr3w1LswAQCbBtpt 0ThTQUdCzTdCaaapV71OgZ8= =L4zh -END PGP SIGNATURE- smime.p7s Description: S/MIME cryptographic signature PGP.sig Description: This is a digitally signed message part
[jira] Updated: (GERONIMO-1423) log4j.properties's category is ignored
[ http://issues.apache.org/jira/browse/GERONIMO-1423?page=all ]
viewhero updated GERONIMO-1423:
---
Description:
log4j.properties that is included war file's WEB-INF/classes.
like this.
---
log4j.rootCategory=ERROR, A1
log4j.appender.A1=org.apache.log4j.ConsoleAppender
log4j.appender.A1.layout=org.apache.log4j.PatternLayout
log4j.appender.A1.layout.ConversionPattern=%d{-MM-dd HH:mm:ss} %-5p [%t]
(%F:%L) - %m%n
log4j.category.jp.ne.xxx=ERROR
---
but, INFO message was written to geronimo.log.
geronimo must read log4j.properties each web applications.
was:
log4j.properties that is included war file's WEB-INF/classes.
like this.
---
log4j.rootCategory=ERROR, A1
log4j.appender.A1=org.apache.log4j.ConsoleAppender
log4j.appender.A1.layout=org.apache.log4j.PatternLayout
log4j.appender.A1.layout.ConversionPattern=%d{-MM-dd HH:mm:ss} %-5p [%t]
(%F:%L) - %m%n
log4j.category.jp.ne.xxx=ERROR
---
but, INFO message wrote to geronimo.log.
geronimo must read log4j.properties each web applications.
log4j.properties's category is ignored
--
Key: GERONIMO-1423
URL: http://issues.apache.org/jira/browse/GERONIMO-1423
Project: Geronimo
Type: Bug
Versions: 1.0
Environment: JRE 1.5.0_06, Linux
Reporter: viewhero
Priority: Critical
log4j.properties that is included war file's WEB-INF/classes.
like this.
---
log4j.rootCategory=ERROR, A1
log4j.appender.A1=org.apache.log4j.ConsoleAppender
log4j.appender.A1.layout=org.apache.log4j.PatternLayout
log4j.appender.A1.layout.ConversionPattern=%d{-MM-dd HH:mm:ss} %-5p [%t]
(%F:%L) - %m%n
log4j.category.jp.ne.xxx=ERROR
---
but, INFO message was written to geronimo.log.
geronimo must read log4j.properties each web applications.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
Re: Question about web app login, user principal, and authentication
The servlet 2.4 spec, section 12.7 states: A security identity, or principal, must always be provided for use in a call to an enterprise bean. The default mode in calls to enterprise beans from web applications is for the security identity of a web user to be propagated to the EJBTM container. In other scenarios, web containers are required to allow web users that are not known to the web container or to the EJBTM container to make calls: ...then the spec goes on, describing scenarios where the user is not known to the web container - but this is not the case here, since the scenario is that the user is logged in. That is, if you are logged in (= the user is known), the web container must use your login principal in calls to the ejb container. Whether the current request is visiting a protected or unprotected resource is irrelevant. /Jeppe David Jencks wrote: i've been getting very confused by some behavior related to being logged in and authentication while working with jetspeed, and I hope someone can shed some light on what should be happening. Lets suppose you have a web app with some secured resources and some unsecured resources. If you start by accessing the unsecured resources, there is no doubt, you have not authenticated, getUserPrincipal() returns null, and you would get the DefaultSubject from ContextManager. Now if you access a secured resource, you log in, getUserPrincipal() returns a non-null principal, and you get the actual Subject from ContextManager during the call to the secured resource. Now if you go back and access an unsecured resource while still logged in, the servlet spec says you should still get the logged-in getUserPrincipal value, but ContextManager returns the DefaultSubject. So in particular calls to say an ejb will be based on the defaultSubject, not the logged in Subject, even though you are logged in. Is this correct? Or, should any access to a resource while logged in result in the ContextManager being set to the logged in subject? Spec references would be very welcome :-) thanks david jencks
Re: ANNOUNCE Geronimo Version 1.0 Available for Download
Davanum Srinivas wrote: Really amazing! Congrats +1. Best Regards, Antonio Gallardo. -- dims On 1/5/06, Matt Hogstrom [EMAIL PROTECTED] wrote: The Apache Geronimo team is proud to announce the availability of Geronimo Version 1.0 for immediate download. Please visit http://geronimo.apache.org/downloads.html.
Re: [wadi-dev] Re: [Geronimo] Clustering
Rajith Attapattu wrote: Hmm, again we have stopped the discussion :). Lets get it started again. OK - I will pick it up. I've been a bit preoccupied with WADI for a while, so apologies for letting this one go cold. So can we all come to some agreement (with more discussion) on which direction we might be taking !! Like merging ActiveCluster and WADI or getting best of both worlds ? hmmm... not sure I follow you here... are you suggesting merging them because you view them as (a) competing or (b) complimentary technologies ? If (a), then I need to put you straight. WADI is a technology that builds on top of ActiveCluster (AC). AC provides basic clustering fn-ality (most importantly, a membership abstraction along with notifications of membership change). If (b), then, whilst WADI and AC could be merged, the current separation is along clear and modular lines and I see no advantage to collapsing the two projects into one. I think that there is far more reason to consider a merger between ActiveSpace (AS). AS is a project that also builds upon ActiveCluster to provide distributed caching fn-ality. The fundamental difference (and I stand open to correction from James here - I'm not very knowledgeable about AS) is that AS provides a host of optimistic caching strategies, whilst WADI (currently) provides a single, pessimistic strategy specifically designed for the management of state in web and ejb tiers, where the sum of the state in the tier is too great to be held by any single node. Because WADI and AC fulfil similar roles, I think that there is more to be gained by unifying their APIs and code-sharing between them. James, if you are reading, what do you think ? And also if we can define expectations/requirments for what we like for the next possible release (1.01 or whatever) in terms of clustering would give folks like me more direction as to where we should concentrate on? Well, I think that there has been plenty of discussion, but you are correct in pointing out that there is no grand unified architecture document out there. I did start on my suggestions towards one quietly a while ago, but canned them. Perhaps enough discussion has now occurred to put up a straw man ? Is this what you are looking for ? If we decide on a direction maybe a few of us can start on a few prototypes and see what works best for Geronimo. Rajith, judging from our conversations on this list, your interest seems to lie in JNDI clustering ? I think that we need to get you, Gianny Damour (working on OpenEJB/WADI integration), James Strachan (ActiveSpace) and Kresten Krab (Trifork guy involved in IIOP stuff, which needs to be worked into equation) into a thread. OpenEJB will need cluster aware client-side proxies, delivered from HA-JNDI. These proxies will need to talk to EJBs via OpenEJB's proprietary protocol and Trifork's IIOP impl (I'm not on my home ground here, so I might be off-base - but that is what the thread is for). HA-JNDI needs a clustering substrate - ActiveSpace best fits the bill (JNDI will be small amounts of data that are write-seldom and read-often). One other issue that meshes with all of this is deployment. I've given some thought to clustered deployment recently and come to the conclusion that a deployment/app/?service? is simply a piece of write(/[un]deploy)-seldom, read(/invoke)-often data. A deployment may result in a number of entries being merged into HA-JNDI, an undeployment may result in a number being removed. If a new node joins a cluster (or subset of) that is responsible for providing an HA-service/app, then that node should deploy an instance of that app as it comes up and remove it as it goes down - i.e. a copy of that app should be distributed to it and maintained by it for the lifetime of the node, just as a jndi entry might be by a distributed JNDI service. I haven't gone over these ideas with anyone else yet, particularly with regards to the relevant JSR, but I guess they need to be thrown out into the ring and discussed. Does everyone think that now is a good time to summarise the various discussions that have occurred about clustering into some sort of unified structure ? This can then be further discussed and hopefully used to carve up work and produce a roadmap ? This is probably over ambitious for a 1.0.1 release (it may just be a bug-fix release ?), but something that we need to be getting on with. Jules Regards, Rajith Attapattu. On 1/5/06, *Rajith Attapattu* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: -Original Message- From: Jules Gosnell [mailto: [EMAIL PROTECTED] mailto:[EMAIL PROTECTED]] Sent: Monday, December 19, 2005 9:55 AM To: [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] Cc: wadi-dev@incubator.apache.org mailto:wadi-dev@incubator.apache.org; dev@geronimo.apache.org mailto:dev@geronimo.apache.org Subject: Re: [wadi-dev]
Build failure in Jetty module
I am using
http://svn.apache.org/repos/asf/geronimo/tags/1.0.0. I
keep getting the following error. Is anyone else
having this problem?
Thnaks
Anita
+
| geronimo and geronimo-plugins Geronimo :: Jetty
| Memory: 27M/37M
+
Attempting to download
geronimo-kernel-1.0-SNAPSHOT.jar.
Attempting to download
geronimo-naming-1.0-SNAPSHOT.jar.
Attempting to download geronimo-j2ee-1.0-SNAPSHOT.jar.
Attempting to download
geronimo-management-1.0-SNAPSHOT.jar.
Attempting to download
geronimo-security-1.0-SNAPSHOT.jar.
Attempting to download
geronimo-security-builder-1.0-SNAPSHOT.jar.
Error retrieving artifact from
[http://cvs.apache.org/repository/geronimo/jars/geronimo-security-builder-1.0-SNAPSHOT.ja
r]: java.net.ConnectException: Connection refused:
connect
Artifact
/geronimo/jars/geronimo-security-builder-1.0-SNAPSHOT.jar
doesn't exists in remote repository, but it exists lo
cally
Attempting to download
geronimo-transaction-1.0-SNAPSHOT.jar.
Attempting to download
geronimo-connector-1.0-SNAPSHOT.jar.
Attempting to download
geronimo-common-1.0-SNAPSHOT.jar.
Attempting to download
geronimo-system-1.0-SNAPSHOT.jar.
Error retrieving artifact from
[http://cvs.apache.org/repository/geronimo/jars/geronimo-system-1.0-SNAPSHOT.jar]:
java.n
et.ConnectException: Connection refused: connect
Error retrieving artifact from
[http://people.apache.org/~jgenender/maven/geronimo/jars/geronimo-system-1.0-SNAPSHOT.jar
]: java.net.ConnectException: Connection refused:
connect
Artifact
/geronimo/jars/geronimo-system-1.0-SNAPSHOT.jar
doesn't exists in remote repository, but it exists
locally
Attempting to download
geronimo-webservices-1.0-SNAPSHOT.jar.
Error retrieving artifact from
[http://cvs.apache.org/repository/geronimo/jars/geronimo-webservices-1.0-SNAPSHOT.jar]:
j
ava.net.ConnectException: Connection refused: connect
Artifact
/geronimo/jars/geronimo-webservices-1.0-SNAPSHOT.jar
doesn't exists in remote repository, but it exists
locally
Attempting to download org.mortbay.jetty-5.1.9.jar.
660K downloaded
Attempting to download jasper-compiler-5.5.12.jar.
395K downloaded
Attempting to download jasper-compiler-jdt-5.5.12.jar.
1176K downloaded
Attempting to download jasper-runtime-5.5.12.jar.
74K downloaded
Attempting to download commons-el-1.0.jar.
109K downloaded
Attempting to download spring-1.2.5.jar.
1827K downloaded
Attempting to download
activecluster-1.2-20051115174934.jar.
31K downloaded
Attempting to download wadi-core-2.0M1.jar.
362K downloaded
Attempting to download wadi-jetty5-2.0M1.jar.
11K downloaded
jar:install:
build:end:
build:start:
multiproject:install-callback:
[echo] Running jar:install for Geronimo :: Jetty
java:prepare-filesystem:
[mkdir] Created dir:
D:\anita\geronimo\geronimo-1.0\modules\jetty\target\classes
java:compile:
[depend] Deleted 0 out of date files in 0 seconds
[echo] Compiling to
D:\anita\geronimo\geronimo-1.0\modules\jetty/target/classes
[javac] Compiling 33 source files to
D:\anita\geronimo\geronimo-1.0\modules\jetty\target\classes
D:\anita\geronimo\geronimo-1.0\modules\jetty\src\java\org\apache\geronimo\jetty\connector\AJP13Connector.java:29:
org.ap
ache.geronimo.jetty.connector.AJP13Connector is not
abstract and does not override abstract method
isEventProvider() in
org.apache.geronimo.management.J2EEManagedObject
public class AJP13Connector extends JettyConnector {
^
D:\anita\geronimo\geronimo-1.0\modules\jetty\src\java\org\apache\geronimo\jetty\connector\HTTPConnector.java:29:
org.apa
che.geronimo.jetty.connector.HTTPConnector is not
abstract and does not override abstract method
isEventProvider() in or
g.apache.geronimo.management.J2EEManagedObject
public class HTTPConnector extends JettyConnector {
^
D:\anita\geronimo\geronimo-1.0\modules\jetty\src\java\org\apache\geronimo\jetty\connector\HTTPSConnector.java:37:
org.ap
ache.geronimo.jetty.connector.HTTPSConnector is not
abstract and does not override abstract method
isEventProvider() in
org.apache.geronimo.management.J2EEManagedObject
public class HTTPSConnector extends JettyConnector
implements JettySecureConnector {
^
Note:
D:\anita\geronimo\geronimo-1.0\modules\jetty\src\java\org\apache\geronimo\jetty\JettyWebAppContext.java
uses or ov
errides a deprecated API.
Note: Recompile with -deprecation for details.
3 errors
BUILD FAILED
File.. D:\anita\geronimo\geronimo-1.0\maven.xml
Element... maven:reactor
Line.. 43
Column 154
Unable to obtain goal [multiproject:install-callback]
-- C:\Documents and
Settings\User\.maven\cache\maven-java-plugin-1
.5\plugin.jelly:63:48: ant:javac Compile failed; see
the compiler error output for details.
Total time: 5 minutes 46 seconds
Finished at: Fri Jan 06 08:19:45 EST 2006
__
Yahoo! DSL Something to write home about.
Just $16.99/mo. or less.
dsl.yahoo.com
Re: Build failure in Jetty module
Never mind.. My mistake. I made webConnector a
managed object instead of TomcatWebConnector. my
apologies...
Thanks
anita
--- anita kulshreshtha [EMAIL PROTECTED] wrote:
I am using
http://svn.apache.org/repos/asf/geronimo/tags/1.0.0.
I
keep getting the following error. Is anyone else
having this problem?
Thnaks
Anita
+
| geronimo and geronimo-plugins Geronimo :: Jetty
| Memory: 27M/37M
+
Attempting to download
geronimo-kernel-1.0-SNAPSHOT.jar.
Attempting to download
geronimo-naming-1.0-SNAPSHOT.jar.
Attempting to download
geronimo-j2ee-1.0-SNAPSHOT.jar.
Attempting to download
geronimo-management-1.0-SNAPSHOT.jar.
Attempting to download
geronimo-security-1.0-SNAPSHOT.jar.
Attempting to download
geronimo-security-builder-1.0-SNAPSHOT.jar.
Error retrieving artifact from
[http://cvs.apache.org/repository/geronimo/jars/geronimo-security-builder-1.0-SNAPSHOT.ja
r]: java.net.ConnectException: Connection refused:
connect
Artifact
/geronimo/jars/geronimo-security-builder-1.0-SNAPSHOT.jar
doesn't exists in remote repository, but it exists
lo
cally
Attempting to download
geronimo-transaction-1.0-SNAPSHOT.jar.
Attempting to download
geronimo-connector-1.0-SNAPSHOT.jar.
Attempting to download
geronimo-common-1.0-SNAPSHOT.jar.
Attempting to download
geronimo-system-1.0-SNAPSHOT.jar.
Error retrieving artifact from
[http://cvs.apache.org/repository/geronimo/jars/geronimo-system-1.0-SNAPSHOT.jar]:
java.n
et.ConnectException: Connection refused: connect
Error retrieving artifact from
[http://people.apache.org/~jgenender/maven/geronimo/jars/geronimo-system-1.0-SNAPSHOT.jar
]: java.net.ConnectException: Connection refused:
connect
Artifact
/geronimo/jars/geronimo-system-1.0-SNAPSHOT.jar
doesn't exists in remote repository, but it exists
locally
Attempting to download
geronimo-webservices-1.0-SNAPSHOT.jar.
Error retrieving artifact from
[http://cvs.apache.org/repository/geronimo/jars/geronimo-webservices-1.0-SNAPSHOT.jar]:
j
ava.net.ConnectException: Connection refused:
connect
Artifact
/geronimo/jars/geronimo-webservices-1.0-SNAPSHOT.jar
doesn't exists in remote repository, but it exists
locally
Attempting to download org.mortbay.jetty-5.1.9.jar.
660K downloaded
Attempting to download jasper-compiler-5.5.12.jar.
395K downloaded
Attempting to download
jasper-compiler-jdt-5.5.12.jar.
1176K downloaded
Attempting to download jasper-runtime-5.5.12.jar.
74K downloaded
Attempting to download commons-el-1.0.jar.
109K downloaded
Attempting to download spring-1.2.5.jar.
1827K downloaded
Attempting to download
activecluster-1.2-20051115174934.jar.
31K downloaded
Attempting to download wadi-core-2.0M1.jar.
362K downloaded
Attempting to download wadi-jetty5-2.0M1.jar.
11K downloaded
jar:install:
build:end:
build:start:
multiproject:install-callback:
[echo] Running jar:install for Geronimo :: Jetty
java:prepare-filesystem:
[mkdir] Created dir:
D:\anita\geronimo\geronimo-1.0\modules\jetty\target\classes
java:compile:
[depend] Deleted 0 out of date files in 0
seconds
[echo] Compiling to
D:\anita\geronimo\geronimo-1.0\modules\jetty/target/classes
[javac] Compiling 33 source files to
D:\anita\geronimo\geronimo-1.0\modules\jetty\target\classes
D:\anita\geronimo\geronimo-1.0\modules\jetty\src\java\org\apache\geronimo\jetty\connector\AJP13Connector.java:29:
org.ap
ache.geronimo.jetty.connector.AJP13Connector is not
abstract and does not override abstract method
isEventProvider() in
org.apache.geronimo.management.J2EEManagedObject
public class AJP13Connector extends JettyConnector {
^
D:\anita\geronimo\geronimo-1.0\modules\jetty\src\java\org\apache\geronimo\jetty\connector\HTTPConnector.java:29:
org.apa
che.geronimo.jetty.connector.HTTPConnector is not
abstract and does not override abstract method
isEventProvider() in or
g.apache.geronimo.management.J2EEManagedObject
public class HTTPConnector extends JettyConnector {
^
D:\anita\geronimo\geronimo-1.0\modules\jetty\src\java\org\apache\geronimo\jetty\connector\HTTPSConnector.java:37:
org.ap
ache.geronimo.jetty.connector.HTTPSConnector is not
abstract and does not override abstract method
isEventProvider() in
org.apache.geronimo.management.J2EEManagedObject
public class HTTPSConnector extends JettyConnector
implements JettySecureConnector {
^
Note:
D:\anita\geronimo\geronimo-1.0\modules\jetty\src\java\org\apache\geronimo\jetty\JettyWebAppContext.java
uses or ov
errides a deprecated API.
Note: Recompile with -deprecation for details.
3 errors
BUILD FAILED
File.. D:\anita\geronimo\geronimo-1.0\maven.xml
Element... maven:reactor
Line.. 43
Column 154
Unable to obtain goal
[multiproject:install-callback]
-- C:\Documents and
Settings\User\.maven\cache\maven-java-plugin-1
.5\plugin.jelly:63:48: ant:javac
Web Site update please
Could someone please update the web site? I just checked in a few changes. I'm not sure what the procedure is to update the real site with the updated SVN content. Also, the links to the signature files for the 1.0 source code downloads are broken. I'm not sure if the links are pointing to the wrong place or the files just haven't been uploaded. Thanks, Aaron
Re: Web Site update please
done - sachin On Jan 6, 2006, at 9:53 AM, Aaron Mulder wrote: Could someone please update the web site? I just checked in a few changes. I'm not sure what the procedure is to update the real site with the updated SVN content. Also, the links to the signature files for the 1.0 source code downloads are broken. I'm not sure if the links are pointing to the wrong place or the files just haven't been uploaded. Thanks, Aaron
Re: Geronimo 2.0
I'll summarize what I think I read. HEAD will be 2.0 which includes JEE 5 and other significant work (Maven 2 conversion, etc.) Branches/1.0 will be where the work for 1.0.x will take place. It would be from this code base we'd branch to a 1.1 when appropriate. I'm updating my local copy of the branches/1.0 with a version change for Geronimo to 1.0.1-SNAPSHOT as well as updating to Tomcay 5.1.15 and Jetty 5.1.10 to incoroporate the latent fixes. I'll build and test to make sure its still working (I'm not going to run TCK). and then commit these changes back when I've confirmed we're ready to go for 1.0.1. Does this sound workable? Matt Jacek Laskowski wrote: 2006/1/6, John Sisson [EMAIL PROTECTED]: I agree we don't want too many branches. Hi John, Well, we should get used to them ;) Especially when Java EE 5 work takes off. I think there will be more refactorings than ever before. It's going to be lots of fun (sarcasm). Will fixes for the 1.0.1 release (hopefully we can get out in a few weeks) be committed to the 1.0 branch and then we create another tag for the 1.0.1 release? I'm not too familiar with svn branching/tagging stuff, but AFAIK they're just copies of the HEAD. If so, only the disk space limits us (which is not the case yet). So, if a need to fix something shows up, we will likely have to apply it to HEAD and branch, be it 1.0.1 or 1.1 depending on its value/importance. Do we have any guesstimates on when we would have JEE 5 development completed? I'm pretty sure we don't. Why would that be beneficial? How long it will be before we can deliver a release with some innovations in it, since we previously agreed we want to release frequently? I think we should stick with the 3-months period for small releases (like 1.0.1) and 6-months period for larger ones (like 1.1) or even the most important (like 2.0, 3.0). That could be our goal, and the time will show how we go ;) If this is going to be a while then we should discuss the work that is planned for the near future and whether there are enhancements that can be delivered in a releases before JEE 5, and if so, how that could be managed. Well, we don't have to wait till JEE 5 development is announced. You/anybody can start his/their work on a branch and merge it with the HEAD when completed. Of course, the more talk about it the better. That's my understanding of how it could (ought to?) work. Could some of the planned enhancements impact the stability of head development and therefore should be done in a branch? E.G. would we have stability problems doing JEE 5 development, re-arch of security, maven 1 to maven 2 migration, xbean support, corba impl etc. all in head? Yes, after having it completed and heavily tested on a branch. The views are indeed mine and I would appreciate any comments on it John Jacek
Re: Geronimo Installation Document Section
I think we've now crossed teh chasm to where there are two types of users. Developers of Geronimo and Users of Geronimo. So far this thread has been talking about developers but I think we also need a User section that describes teh process of installation from a downloaded binary rather than having to worry about SVN. We can then augment that with some updated doc on the installer. Thoughts? Matt John Sisson wrote: You need to do the fresh-checkout the first time you get the source so that you get the OpenEJB code (from CVS). AFAIK, you shouldn't need to do a fresh-checkout again because an m:update will update both svn and OpenEJB CVS files. Not sure why you would need to do a fresh-checkout a second time for the second round to work. John Hernan Cunico wrote: On my machine, if I don't do a fresh-checkout the build fails. In fact it always fails the first attempt and the second round works as long as I do the fresh-checkout. Any idea why this is happening? Cheers! Hernan Sachin Patel wrote: - sachin On Jan 5, 2006, at 4:16 PM, Hernan Cunico wrote: Hi Jason, how is the installation doc coming, do you need any help on the confluence side? I saw what you started to work on the Getting the source code section, I would suggest to keep this task simple. We do not want to _scare_ the users with way too complicated commands and parameters, all at once. There are basically four steps to get the source and build Geronimo, so I would focus on those first. 1.- svn checkout https://svn.apache.org/repos/asf/geronimo/tags/ 1.0.0/ geronimo_home 2.- cd geronimo_home 3.- maven m:fresh-checkout 4.- maven new Then, the next time you want to build you just do an update 1.- cd geronimo_home 2.- maven m:update 3.- maven m:fresh-checkout Take out #3 4.- maven new add -o (BTW, all the steps should be validated and make sure they are up- to-date) Once you explained the basics then you can go more in detail with all the other options for retrieving the source code and building Geronimo. It would also be nice to include common building errors, how to identify them, probable causes and solutions. Again, this is just a suggestion. What you think about this approach? As for update preference, I think is best to update as you go so everybody can test your instructions and provide early comments that will make corrections (if any) easier. Cheers! Hernan Jason Lenhart wrote: Hi, I am starting on the Installation section of the docs - I have been running around like a maniac doing stuff (mostly holiday things) - so I am a bit slow to produce. But I am setting aside some time each day to contribute more and more to the docs. If you start to see me go off base - please feel free to call me out :-D Also - is the preference to complete a section and then update? I started and updated but it is not complete. Thanks, Jason __ Yahoo! DSL – Something to write home about. Just $16.99/mo. or less. dsl.yahoo.com
Re: Geronimo Installation Document Section
I agree with Matt. If you want to call it an Installation document, then it must be geared towards the users installing Geronimo. They care little about building it. They would be the ones downloading the binaries and wanting to get G up and running quickly. The steps being discussed in this thread should go in something like a Developers Section . Cheers PrasadOn 1/6/06, Matt Hogstrom [EMAIL PROTECTED] wrote: I think we've now crossed teh chasm to where there are two types of users.Developers of Geronimo and Users of Geronimo.So far this thread has beentalking about developers but I think we also need a User section that describes teh process of installation from a downloaded binary rather than having to worryabout SVN.We can then augment that with some updated doc on the installer.Thoughts?MattJohn Sisson wrote: You need to do the fresh-checkout the first time you get the source so that you get the OpenEJB code (from CVS).AFAIK, you shouldn't need to do a fresh-checkout again because an m:update will update both svn and OpenEJB CVS files. Not sure why you would need to do a fresh-checkout a second time for the second round to work. John Hernan Cunico wrote: On my machine, if I don't do a fresh-checkout the build fails. In fact it always fails the first attempt and the second round works as long as I do the fresh-checkout. Any idea why this is happening? Cheers! Hernan Sachin Patel wrote: - sachin On Jan 5, 2006, at 4:16 PM, Hernan Cunico wrote: Hi Jason, how is the installation doc coming, do you need any help on the confluence side? I saw what you started to work on the Getting the source code section, I would suggest to keep this task simple. We do not want to _scare_ the users with way too complicated commands and parameters, all at once. There are basically four steps to get the source and build Geronimo, so I would focus on those first. 1.- svn checkout https://svn.apache.org/repos/asf/geronimo/tags/ 1.0.0/ geronimo_home 2.- cd geronimo_home 3.- maven m:fresh-checkout 4.- maven new Then, the next time you want to build you just do an update 1.- cd geronimo_home 2.- maven m:update 3.- maven m:fresh-checkout Take out #3 4.- maven new add -o (BTW, all the steps should be validated and make sure they are up- to-date) Once you explained the basics then you can go more in detail with all the other options for retrieving the source code and building Geronimo. It would also be nice to include common building errors, how to identify them, probable causes and solutions. Again, this is just a suggestion. What you think about this approach? As for update preference, I think is best to update as you go so everybody can test your instructions and provide early comments that will make corrections (if any) easier. Cheers! Hernan Jason Lenhart wrote: Hi, I am starting on the Installation section of the docs - I have been running around like a maniac doing stuff (mostly holiday things) - so I am a bit slow to produce.But I am setting aside some time each day to contribute more and more to the docs.If you start to see me go off base - please feel free to call me out :-D Also - is the preference to complete a section and then update?I started and updated but it is not complete. Thanks, Jason__ Yahoo! DSL – Somethingto write home about. Just $16.99/mo. or less. dsl.yahoo.com
Re: Can we get the Geronimo IRC archive working again?
If this means that we can get an archive again for the IRC chat then I'm fine with it. I'm not sure of the other implications for items like open source tracking, problems, etc (sounds like some possible duplication) . I'm just interested in capturing the IRC data at the moment. Do any committers, PMC members care to comment? Joe Daniel S. Haischt wrote: If there are no objections I can register the Geronimo project with ... * http://meme.b9.com/ - That's a channel logger with a search interface. * lisppaste - that's a pastbot with a corresponding web interface. * CIA - That's an open source tracking system. which tracks the project's progress. Tho - requires to install a little shell script on the SVN server that will be executed on each commit. Daniel S. Haischt schrieb: Joe Bohn schrieb: I'd be glad to help get this working again if I can get some pointers. It's been down for nearly 2 months now and I really miss it. Joe Maybe it would be even possible to register the Geronimo project at ... * The CIA Open Source Notification System - http://cia.navi.cx/ * A lisppaste bot instance - http://common-lisp.net/project/lisppaste/ * At - http://meme.b9.com/ -- Joe Bohn [EMAIL PROTECTED] He is no fool who gives what he cannot keep, to gain what he cannot lose. -- Jim Elliot
Re: FYI, hardcoded version references
Whoa ! This doesn't look good. I have an ant script that builds G by taking a version number as a parameter/property. This will enable us to have nightly builds of G at multiple versions in the future. Having hardcoded versions like this will break that ability. Aaron, thanx for that grep output. Since I was away on a vacation last month, I missed any further offline discussion on that. What is the latest status reg the hardcoded version references. If that has not yet been fixed, would you mind if I took a crack at it ? Cheers PrasadOn 12/8/05, Aaron Mulder [EMAIL PROTECTED] wrote: Just so this list isn't lost, this is the output of a grep I did for1.0-SNAPSHOT in our current tree.Aaron
Re: Geronimo Installation Document Section
Hi all, for getting Geronimo up and running really fast, there is already the *Quick start - Apache Geronimo for the impatient* section where you get it running right from the binaries. My original idea for the *Installation* section was to have a complete set of instructions for downloading and building. Initially focused on the alternatives for downloading from svn and then, once you have the source, all the options for complete/modular building. I believe that not only developers will be interested in partial builds. What about IT guys (and I'm one of them) looking for performance improvement or resources optimization? I will reorganize the *Installation* section to make the subtopics and scope more clear. Cheers! Hernan Prasad Kashyap wrote: I agree with Matt. If you want to call it an Installation document, then it must be geared towards the users installing Geronimo. They care little about building it. They would be the ones downloading the binaries and wanting to get G up and running quickly. The steps being discussed in this thread should go in something like a Developers Section . Cheers Prasad On 1/6/06, *Matt Hogstrom* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: I think we've now crossed teh chasm to where there are two types of users. Developers of Geronimo and Users of Geronimo. So far this thread has been talking about developers but I think we also need a User section that describes teh process of installation from a downloaded binary rather than having to worry about SVN. We can then augment that with some updated doc on the installer. Thoughts? Matt John Sisson wrote: You need to do the fresh-checkout the first time you get the source so that you get the OpenEJB code (from CVS). AFAIK, you shouldn't need to do a fresh-checkout again because an m:update will update both svn and OpenEJB CVS files. Not sure why you would need to do a fresh-checkout a second time for the second round to work. John Hernan Cunico wrote: On my machine, if I don't do a fresh-checkout the build fails. In fact it always fails the first attempt and the second round works as long as I do the fresh-checkout. Any idea why this is happening? Cheers! Hernan Sachin Patel wrote: - sachin On Jan 5, 2006, at 4:16 PM, Hernan Cunico wrote: Hi Jason, how is the installation doc coming, do you need any help on the confluence side? I saw what you started to work on the Getting the source code section, I would suggest to keep this task simple. We do not want to _scare_ the users with way too complicated commands and parameters, all at once. There are basically four steps to get the source and build Geronimo, so I would focus on those first. 1.- svn checkout https://svn.apache.org/repos/asf/geronimo/tags/ 1.0.0/ geronimo_home 2.- cd geronimo_home 3.- maven m:fresh-checkout 4.- maven new Then, the next time you want to build you just do an update 1.- cd geronimo_home 2.- maven m:update 3.- maven m:fresh-checkout Take out #3 4.- maven new add -o (BTW, all the steps should be validated and make sure they are up- to-date) Once you explained the basics then you can go more in detail with all the other options for retrieving the source code and building Geronimo. It would also be nice to include common building errors, how to identify them, probable causes and solutions. Again, this is just a suggestion. What you think about this approach? As for update preference, I think is best to update as you go so everybody can test your instructions and provide early comments that will make corrections (if any) easier. Cheers! Hernan Jason Lenhart wrote: Hi, I am starting on the Installation section of the docs - I have been running around like a maniac doing stuff (mostly holiday things) - so I am a bit slow to produce. But I am setting aside some time each day to contribute more and more to the docs. If you start to see me go off base - please feel free to call me out :-D Also - is the preference to complete a section and then update? I started and updated but it is not complete. Thanks, Jason __ Yahoo! DSL – Something to write home about. Just $16.99/mo. or less. dsl.yahoo.com http://dsl.yahoo.com
Re: Geronimo Installation Document Section
I would recommend then not using the term Installation. Even with IT guys this typically implies installing some piece of software to simply use it ... not to setup for development and building. Perhaps Setup for Developers would be a better heading or if we must continue to use Installation then perhaps extend the heading to Installation for Developers. Joe Hernan Cunico wrote: Hi all, for getting Geronimo up and running really fast, there is already the *Quick start - Apache Geronimo for the impatient* section where you get it running right from the binaries. My original idea for the *Installation* section was to have a complete set of instructions for downloading and building. Initially focused on the alternatives for downloading from svn and then, once you have the source, all the options for complete/modular building. I believe that not only developers will be interested in partial builds. What about IT guys (and I'm one of them) looking for performance improvement or resources optimization? I will reorganize the *Installation* section to make the subtopics and scope more clear. Cheers! Hernan Prasad Kashyap wrote: I agree with Matt. If you want to call it an Installation document, then it must be geared towards the users installing Geronimo. They care little about building it. They would be the ones downloading the binaries and wanting to get G up and running quickly. The steps being discussed in this thread should go in something like a Developers Section . Cheers Prasad On 1/6/06, *Matt Hogstrom* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: I think we've now crossed teh chasm to where there are two types of users. Developers of Geronimo and Users of Geronimo. So far this thread has been talking about developers but I think we also need a User section that describes teh process of installation from a downloaded binary rather than having to worry about SVN. We can then augment that with some updated doc on the installer. Thoughts? Matt John Sisson wrote: You need to do the fresh-checkout the first time you get the source so that you get the OpenEJB code (from CVS). AFAIK, you shouldn't need to do a fresh-checkout again because an m:update will update both svn and OpenEJB CVS files. Not sure why you would need to do a fresh-checkout a second time for the second round to work. John Hernan Cunico wrote: On my machine, if I don't do a fresh-checkout the build fails. In fact it always fails the first attempt and the second round works as long as I do the fresh-checkout. Any idea why this is happening? Cheers! Hernan Sachin Patel wrote: - sachin On Jan 5, 2006, at 4:16 PM, Hernan Cunico wrote: Hi Jason, how is the installation doc coming, do you need any help on the confluence side? I saw what you started to work on the Getting the source code section, I would suggest to keep this task simple. We do not want to _scare_ the users with way too complicated commands and parameters, all at once. There are basically four steps to get the source and build Geronimo, so I would focus on those first. 1.- svn checkout https://svn.apache.org/repos/asf/geronimo/tags/ 1.0.0/ geronimo_home 2.- cd geronimo_home 3.- maven m:fresh-checkout 4.- maven new Then, the next time you want to build you just do an update 1.- cd geronimo_home 2.- maven m:update 3.- maven m:fresh-checkout Take out #3 4.- maven new add -o (BTW, all the steps should be validated and make sure they are up- to-date) Once you explained the basics then you can go more in detail with all the other options for retrieving the source code and building Geronimo. It would also be nice to include common building errors, how to identify them, probable causes and solutions. Again, this is just a suggestion. What you think about this approach? As for update preference, I think is best to update as you go so everybody can test your instructions and provide early comments that will make corrections (if any) easier. Cheers! Hernan Jason Lenhart wrote: Hi, I am starting on the Installation section of the docs - I have been running around like a maniac doing stuff (mostly holiday things) - so I am a bit slow to produce. But I am setting aside some time each day to contribute more and more to the docs. If you start to see me go off base - please feel free to call me out :-D
Re: Geronimo 2.0
2006/1/6, Matt Hogstrom [EMAIL PROTECTED]: HEAD will be 2.0 which includes JEE 5 and other significant work (Maven 2 conversion, etc.) Hi Matt, That's my understanding, too. Branches/1.0 will be where the work for 1.0.x will take place. It would be from this code base we'd branch to a 1.1 when appropriate. +1 I'm updating my local copy of the branches/1.0 with a version change for Geronimo to 1.0.1-SNAPSHOT as well as updating to Tomcay 5.1.15 and Jetty 5.1.10 to incoroporate the latent fixes. Excellent! Let us know when it's finished so we could give it a whirl, esp. those who don't follow scm. I'll build and test to make sure its still working (I'm not going to run TCK). and then commit these changes back when I've confirmed we're ready to go for 1.0.1. Does this sound workable? I wouldn't have said it better ;) I think we should write it down somewhere. Any hints on where it ought to be? On another note, what do others think about creating Grinder (or another tool) scripts to validate a release? It would likely be similar to TCK, but unlike TCK anybody could run it. Matt Jacek
[jira] Created: (GERONIMO-1424) Correct Additional Samples redirect url
Correct Additional Samples redirect url -- Key: GERONIMO-1424 URL: http://issues.apache.org/jira/browse/GERONIMO-1424 Project: Geronimo Type: Bug Reporter: Dave Colasurdo Priority: Minor The Geronimo Welcome page links to additional samples. This link points to the geronimo website that redirects to the actual spot. The actual spot has moved, hence the redirection needs to be updated. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (GERONIMO-1424) Correct Additional Samples redirect url
[ http://issues.apache.org/jira/browse/GERONIMO-1424?page=all ] Dave Colasurdo updated GERONIMO-1424: - Attachment: sampleRedirect.patch Correct Additional Samples redirect url - Key: GERONIMO-1424 URL: http://issues.apache.org/jira/browse/GERONIMO-1424 Project: Geronimo Type: Bug Reporter: Dave Colasurdo Priority: Minor Attachments: sampleRedirect.patch The Geronimo Welcome page links to additional samples. This link points to the geronimo website that redirects to the actual spot. The actual spot has moved, hence the redirection needs to be updated. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [VOTE] create a milestone release of ActiveMQ?
I don't think it's possible yet but we are getting closer. Regards, Hiram On Jan 1, 2006, at 7:05 PM, Guillaume Nodet wrote: +1 Would it be possible to do it with m2 ? Guillaume James Strachan wrote: Now that ActiveMQ has dotted the 'i's and crossed the 't's of most of the incubation checklist, http://wiki.apache.org/ geronimo/ ActiveMQ_Incubation, and we have gotten through most of the refactors needed, it would be very useful to cut our first Apache based milestone build using the new org.apache.activemq package structure so that other projects can develop off of it. [ ] +1 Release a milestone build [ ] -1 Veto the milestone release (provide specific comments) Here's my +1 James --- http://radio.weblogs.com/0112098/
Re: [wadi-dev] Re: [Geronimo] Clustering
Matt Hogstrom wrote: Jules, I think you are spot on with a summary at this point. At least in my conversations a person's view of clustering is influenced by which aspect of clustering they are intersted in. I think a short doc would be really helpful here. Were you planning on doing that or would you like some help? Matt, The more I look at the amount of work that needs doing the more help I think I need ! I am away this weekend, but I will try to put together a document skeleton early next week that defines the areas that we need to cover. Then we can refer back to various discussions on the list to flesh out the relevant areas. I'm not sure of the best way of making this document available so that everyone can contribute - but we can worry about that when we have one. Do you have a pet clustering area ? Have we discussed it ? Jules Jules Gosnell wrote: Rajith Attapattu wrote: Hmm, again we have stopped the discussion :). Lets get it started again. OK - I will pick it up. I've been a bit preoccupied with WADI for a while, so apologies for letting this one go cold. So can we all come to some agreement (with more discussion) on which direction we might be taking !! Like merging ActiveCluster and WADI or getting best of both worlds ? hmmm... not sure I follow you here... are you suggesting merging them because you view them as (a) competing or (b) complimentary technologies ? If (a), then I need to put you straight. WADI is a technology that builds on top of ActiveCluster (AC). AC provides basic clustering fn-ality (most importantly, a membership abstraction along with notifications of membership change). If (b), then, whilst WADI and AC could be merged, the current separation is along clear and modular lines and I see no advantage to collapsing the two projects into one. I think that there is far more reason to consider a merger between ActiveSpace (AS). AS is a project that also builds upon ActiveCluster to provide distributed caching fn-ality. The fundamental difference (and I stand open to correction from James here - I'm not very knowledgeable about AS) is that AS provides a host of optimistic caching strategies, whilst WADI (currently) provides a single, pessimistic strategy specifically designed for the management of state in web and ejb tiers, where the sum of the state in the tier is too great to be held by any single node. Because WADI and AC fulfil similar roles, I think that there is more to be gained by unifying their APIs and code-sharing between them. James, if you are reading, what do you think ? And also if we can define expectations/requirments for what we like for the next possible release (1.01 or whatever) in terms of clustering would give folks like me more direction as to where we should concentrate on? Well, I think that there has been plenty of discussion, but you are correct in pointing out that there is no grand unified architecture document out there. I did start on my suggestions towards one quietly a while ago, but canned them. Perhaps enough discussion has now occurred to put up a straw man ? Is this what you are looking for ? If we decide on a direction maybe a few of us can start on a few prototypes and see what works best for Geronimo. Rajith, judging from our conversations on this list, your interest seems to lie in JNDI clustering ? I think that we need to get you, Gianny Damour (working on OpenEJB/WADI integration), James Strachan (ActiveSpace) and Kresten Krab (Trifork guy involved in IIOP stuff, which needs to be worked into equation) into a thread. OpenEJB will need cluster aware client-side proxies, delivered from HA-JNDI. These proxies will need to talk to EJBs via OpenEJB's proprietary protocol and Trifork's IIOP impl (I'm not on my home ground here, so I might be off-base - but that is what the thread is for). HA-JNDI needs a clustering substrate - ActiveSpace best fits the bill (JNDI will be small amounts of data that are write-seldom and read-often). One other issue that meshes with all of this is deployment. I've given some thought to clustered deployment recently and come to the conclusion that a deployment/app/?service? is simply a piece of write(/[un]deploy)-seldom, read(/invoke)-often data. A deployment may result in a number of entries being merged into HA-JNDI, an undeployment may result in a number being removed. If a new node joins a cluster (or subset of) that is responsible for providing an HA-service/app, then that node should deploy an instance of that app as it comes up and remove it as it goes down - i.e. a copy of that app should be distributed to it and maintained by it for the lifetime of the node, just as a jndi entry might be by a distributed JNDI service. I haven't gone over these ideas with anyone else yet, particularly with regards to the relevant JSR, but I guess they need to be thrown out into the ring and
Re: Geronimo Installation Document Section
how about this structure Installation Supported platforms Hardware and software prerequisites Getting the software Getting the binaries Getting the source code Build from the source complete build modular build Installing the binaries _interoperability, ports conflict considerations, directory structure, configuration files, additional considerations_ Cheers! Hernan Joe Bohn wrote: I would recommend then not using the term Installation. Even with IT guys this typically implies installing some piece of software to simply use it ... not to setup for development and building. Perhaps Setup for Developers would be a better heading or if we must continue to use Installation then perhaps extend the heading to Installation for Developers. Joe Hernan Cunico wrote: Hi all, for getting Geronimo up and running really fast, there is already the *Quick start - Apache Geronimo for the impatient* section where you get it running right from the binaries. My original idea for the *Installation* section was to have a complete set of instructions for downloading and building. Initially focused on the alternatives for downloading from svn and then, once you have the source, all the options for complete/modular building. I believe that not only developers will be interested in partial builds. What about IT guys (and I'm one of them) looking for performance improvement or resources optimization? I will reorganize the *Installation* section to make the subtopics and scope more clear. Cheers! Hernan Prasad Kashyap wrote: I agree with Matt. If you want to call it an Installation document, then it must be geared towards the users installing Geronimo. They care little about building it. They would be the ones downloading the binaries and wanting to get G up and running quickly. The steps being discussed in this thread should go in something like a Developers Section . Cheers Prasad On 1/6/06, *Matt Hogstrom* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: I think we've now crossed teh chasm to where there are two types of users. Developers of Geronimo and Users of Geronimo. So far this thread has been talking about developers but I think we also need a User section that describes teh process of installation from a downloaded binary rather than having to worry about SVN. We can then augment that with some updated doc on the installer. Thoughts? Matt John Sisson wrote: You need to do the fresh-checkout the first time you get the source so that you get the OpenEJB code (from CVS). AFAIK, you shouldn't need to do a fresh-checkout again because an m:update will update both svn and OpenEJB CVS files. Not sure why you would need to do a fresh-checkout a second time for the second round to work. John Hernan Cunico wrote: On my machine, if I don't do a fresh-checkout the build fails. In fact it always fails the first attempt and the second round works as long as I do the fresh-checkout. Any idea why this is happening? Cheers! Hernan Sachin Patel wrote: - sachin On Jan 5, 2006, at 4:16 PM, Hernan Cunico wrote: Hi Jason, how is the installation doc coming, do you need any help on the confluence side? I saw what you started to work on the Getting the source code section, I would suggest to keep this task simple. We do not want to _scare_ the users with way too complicated commands and parameters, all at once. There are basically four steps to get the source and build Geronimo, so I would focus on those first. 1.- svn checkout https://svn.apache.org/repos/asf/geronimo/tags/ 1.0.0/ geronimo_home 2.- cd geronimo_home 3.- maven m:fresh-checkout 4.- maven new Then, the next time you want to build you just do an update 1.- cd geronimo_home 2.- maven m:update 3.- maven m:fresh-checkout Take out #3 4.- maven new add -o (BTW, all the steps should be validated and make sure they are up- to-date) Once you explained the basics then you can go more in detail with all the other options for retrieving the source code and building Geronimo. It would also be nice to include common building errors, how to identify them, probable causes and solutions. Again, this is just a suggestion. What you think about this approach? As for update preference, I think is best to update as you
Re: Geronimo 2.0
On Jan 6, 2006, at 10:07 AM, Matt Hogstrom wrote: I'll summarize what I think I read. HEAD will be 2.0 which includes JEE 5 and other significant work (Maven 2 conversion, etc.) Branches/1.0 will be where the work for 1.0.x will take place. It would be from this code base we'd branch to a 1.1 when appropriate. I'm updating my local copy of the branches/1.0 with a version change for Geronimo to 1.0.1-SNAPSHOT as well as updating to Tomcay 5.1.15 and Jetty 5.1.10 to incoroporate the latent fixes. I'll build and test to make sure its still working (I'm not going to run TCK). and then commit these changes back when I've confirmed we're ready to go for 1.0.1. Does this sound workable? Matt, Tomcat 5.5.15 is stll in Beta. So, I'd hold off just a bit. Preliminary tests look good. I'm running a more complete test, now. How about you update version and Jetty. I'll cutover Tomcat when appropriate... --kevan
Re: Geronimo Installation Document Section
I have been fooling around with apache jetspeed and found their installation instructions (which is linked from their download page) to be pretty useful. http://portals.apache.org/jetspeed-2/download.html#Installation_Instructions Getting Started with Jetspeed-2 InstallerGetting Started with Building from Jetspeed-2 Source Getting Started with Building from Jetspeed-2 Maven Plugin I realize the G installer isn't ready yet but perhaps we could still follow a similar format. Best wishes, Paul
Re: Geronimo 2.0
Thanks Kevan...I was going to ask about TC as 5.1.15 was not found:)...leaving at 5.1.9 for now. Other changes in and building now. Kevan Miller wrote: On Jan 6, 2006, at 10:07 AM, Matt Hogstrom wrote: I'll summarize what I think I read. HEAD will be 2.0 which includes JEE 5 and other significant work (Maven 2 conversion, etc.) Branches/1.0 will be where the work for 1.0.x will take place. It would be from this code base we'd branch to a 1.1 when appropriate. I'm updating my local copy of the branches/1.0 with a version change for Geronimo to 1.0.1-SNAPSHOT as well as updating to Tomcay 5.1.15 and Jetty 5.1.10 to incoroporate the latent fixes. I'll build and test to make sure its still working (I'm not going to run TCK). and then commit these changes back when I've confirmed we're ready to go for 1.0.1. Does this sound workable? Matt, Tomcat 5.5.15 is stll in Beta. So, I'd hold off just a bit. Preliminary tests look good. I'm running a more complete test, now. How about you update version and Jetty. I'll cutover Tomcat when appropriate... --kevan
[jira] Assigned: (GERONIMO-1424) Correct Additional Samples redirect url
[ http://issues.apache.org/jira/browse/GERONIMO-1424?page=all ] Sachin Patel reassigned GERONIMO-1424: -- Assign To: Sachin Patel Correct Additional Samples redirect url - Key: GERONIMO-1424 URL: http://issues.apache.org/jira/browse/GERONIMO-1424 Project: Geronimo Type: Bug Reporter: Dave Colasurdo Assignee: Sachin Patel Priority: Minor Fix For: 1.0 Attachments: sampleRedirect.patch The Geronimo Welcome page links to additional samples. This link points to the geronimo website that redirects to the actual spot. The actual spot has moved, hence the redirection needs to be updated. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (GERONIMO-1424) Correct Additional Samples redirect url
[ http://issues.apache.org/jira/browse/GERONIMO-1424?page=all ] Sachin Patel resolved GERONIMO-1424: Fix Version: 1.0 Resolution: Fixed patch applied Correct Additional Samples redirect url - Key: GERONIMO-1424 URL: http://issues.apache.org/jira/browse/GERONIMO-1424 Project: Geronimo Type: Bug Reporter: Dave Colasurdo Assignee: Sachin Patel Priority: Minor Fix For: 1.0 Attachments: sampleRedirect.patch The Geronimo Welcome page links to additional samples. This link points to the geronimo website that redirects to the actual spot. The actual spot has moved, hence the redirection needs to be updated. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: ANNOUNCE Geronimo Version 1.0 Available for Download
On Jan 6, 2006, at 4:20 AM, Jacek Laskowski wrote: 2006/1/6, Matt Hogstrom [EMAIL PROTECTED]: Apache Geronimo 1.0 introduces complete J2EE 1.4 certification, support for Java Business Integration (JBI) I don't understand it. How do we support JBI? Do we provide a configuration for ServiceMix (or possibly Celtix or another JBI container) ? I think it we don't, unfortunatelly. I wish I were wrong. Jacek, You're correct. It's not currently supported. There was a prototype implementation, but was removed prior to 1.0. Unfortunately, it was improperly documented in a note, last month, and has been perpetuated via copy/paste... I'm sure this will be an item in the 2.0 discussions... --kevan
Re: Geronimo 2.0
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Matt Hogstrom wrote, On 1/6/2006 7:07 AM: I'll summarize what I think I read. HEAD will be 2.0 which includes JEE 5 and other significant work (Maven 2 conversion, etc.) Branches/1.0 will be where the work for 1.0.x will take place. It would be from this code base we'd branch to a 1.1 when appropriate. So, we would eventually have 2 branches and 1 trunk: branches/1.0 branches/1_trunk tags/* trunk I'm updating my local copy of the branches/1.0 with a version change for Geronimo to 1.0.1-SNAPSHOT as well as updating to Tomcay 5.1.15 and Jetty 5.1.10 to incoroporate the latent fixes. I'll build and test to make sure its still working (I'm not going to run TCK). and then commit these changes back when I've confirmed we're ready to go for 1.0.1. Does this sound workable? Can we have jira issues assigned to 1.0.1 so that we can see what's coming down the pipeline? Regards, Alan -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDvqSa1xC6qnMLUpYRArhpAJ91d5cSrHGEsY0pG6Jf+Nb+9gNuSgCfR8gH m3qYJWEG9Zej/Sg+O5pMPQA= =goh1 -END PGP SIGNATURE-
Re: Geronimo 2.0
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Kevan Miller wrote, On 1/6/2006 8:47 AM: On Jan 6, 2006, at 10:07 AM, Matt Hogstrom wrote: I'll summarize what I think I read. HEAD will be 2.0 which includes JEE 5 and other significant work (Maven 2 conversion, etc.) Branches/1.0 will be where the work for 1.0.x will take place. It would be from this code base we'd branch to a 1.1 when appropriate. I'm updating my local copy of the branches/1.0 with a version change for Geronimo to 1.0.1-SNAPSHOT as well as updating to Tomcay 5.1.15 and Jetty 5.1.10 to incoroporate the latent fixes. I'll build and test to make sure its still working (I'm not going to run TCK). and then commit these changes back when I've confirmed we're ready to go for 1.0.1. Does this sound workable? Matt, Tomcat 5.5.15 is stll in Beta. So, I'd hold off just a bit. Preliminary tests look good. I'm running a more complete test, now. How about you update version and Jetty. I'll cutover Tomcat when appropriate... Good point Keven. Matt, I think that we should avoid version upgrades for a patch release if we can help it. Regards, Alan -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDvqTe1xC6qnMLUpYRAuwiAJ0fgGNJpSyxWKop798/EVtM3XLZCgCfQv8J QKSjMpmRG4SFbEg052RmpN0= =aRfh -END PGP SIGNATURE-
Tomcat 5.5.9 vs 5.5.12
The tomcat version used in the source at https://svn.apache.org/repos/asf/geronimo/tags/1.0.0/ is 5.5.12, whereas the tomcat version used in the released binaries is 5.5.9. The following problem does not occur in 5.5.9. Thnaks Anita --- anita kulshreshtha [EMAIL PROTECTED] wrote: Jeff, Thanks, for looking into this. Now I am seeing the request processors! The output for geronimo is attached. What changes did you make? Thanks again! Anita --- anita kulshreshtha [EMAIL PROTECTED] wrote: Jeff, In a standalone configuration tomcat configures an MBean Name: Catalina:type=RequestProcessor,worker=http-8080,name=HttpRequest0. This is not being configured in G. Do you have any ideas why? I am attaching a list of all RequestProcessors running in a standalone tomcat. The G ones can be viewed by deploying the war attached to G-1293. There are none! Each request thread has an associated RequestInfo which is used to gather stats. Thanks Anita __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com Name: Catalina:type=RequestProcessor,worker=http-8080,name=HttpRequest2 modelerType: org.apache.coyote.RequestInfo bytesSent: 10626 method: GET remoteAddr: 127.0.0.1 requestBytesSent: 0 contentLength: -1 bytesReceived: 0 requestProcessingTime: 84531 globalProcessor: [EMAIL PROTECTED] protocol: HTTP/1.0 currentQueryString: maxRequestUri: /manager/status requestBytesReceived: 0 serverPort: -1 stage: 7 requestCount: 6 maxTime: 78 processingTime: 156 currentUri: / errorCount: 3 Name: Catalina:type=RequestProcessor,worker=http-8080,name=HttpRequest0 modelerType: org.apache.coyote.RequestInfo virtualHost: localhost bytesSent: 122571 method: GET remoteAddr: 127.0.0.1 requestBytesSent: 221184 contentLength: -1 bytesReceived: 0 requestProcessingTime: 422 globalProcessor: [EMAIL PROTECTED] protocol: HTTP/1.1 currentQueryString: maxRequestUri: /manager/jmxproxy/ requestBytesReceived: 0 serverPort: 8080 stage: 3 requestCount: 9 maxTime: 328 processingTime: 875 currentUri: /manager/jmxproxy/ errorCount: 4 Name: Catalina:type=RequestProcessor,worker=http-8080,name=HttpRequest1 modelerType: org.apache.coyote.RequestInfo bytesSent: 22380 method: GET remoteAddr: 127.0.0.1 requestBytesSent: 0 contentLength: -1 bytesReceived: 0 requestProcessingTime: 1840890 globalProcessor: [EMAIL PROTECTED] protocol: HTTP/1.0 currentQueryString: maxRequestUri: /manager/images/jakarta-logo.gif requestBytesReceived: 0 serverPort: -1 stage: 7 requestCount: 5 maxTime: 63 processingTime: 140 currentUri: / errorCount: 1 __ Yahoo! for Good - Make a difference this year. http://brand.yahoo.com/cybergivingweek2005/ OK - Number of results: 4 Name: Geronimo:type=RequestProcessor,worker=http-0.0.0.0-8080,name=HttpRequest3 modelerType: org.apache.coyote.RequestInfo virtualHost: localhost bytesSent: 10399 method: GET remoteAddr: 127.0.0.1 requestBytesSent: 0 contentLength: -1 bytesReceived: 0 requestProcessingTime: 15 globalProcessor: [EMAIL PROTECTED] protocol: HTTP/1.1 currentQueryString: qry=*%3Atype%3DRequestProcessor%2C* maxRequestUri: /stats/jmxproxy/ requestBytesReceived: 0 serverPort: 8080 stage: 3 requestCount: 10 maxTime: 78 processingTime: 171 currentUri: /stats/jmxproxy/ errorCount: 7 Name: Geronimo:type=RequestProcessor,worker=http-0.0.0.0-8080,name=HttpRequest1 modelerType: org.apache.coyote.RequestInfo bytesSent: 232019 method: GET remoteAddr: 127.0.0.1 requestBytesSent: 0 contentLength: -1 bytesReceived: 0 requestProcessingTime: 78906 globalProcessor: [EMAIL PROTECTED] protocol: HTTP/1.0 currentQueryString: maxRequestUri: /console/portal/apps/apps_war requestBytesReceived: 0 serverPort: -1 stage: 7 requestCount: 21 maxTime: 4734 processingTime: 13202 currentUri: / errorCount: 7 Name: Geronimo:type=RequestProcessor,worker=http-0.0.0.0-8443,name=HttpRequest0 modelerType: org.apache.coyote.RequestInfo bytesSent: 0 method: GET requestBytesSent: 0 contentLength: -1 bytesReceived: 0 requestProcessingTime: 1135965870625 globalProcessor: [EMAIL PROTECTED] protocol: HTTP/1.0 currentQueryString: requestBytesReceived: 0 serverPort: -1 stage: 0 requestCount: 0 maxTime: 0 processingTime: 0 currentUri: / errorCount: 0 Name: Geronimo:type=RequestProcessor,worker=http-0.0.0.0-8080,name=HttpRequest2 modelerType: org.apache.coyote.RequestInfo bytesSent: 57770 method: GET remoteAddr: 127.0.0.1 requestBytesSent: 0 contentLength: -1 bytesReceived: 49 requestProcessingTime: 135860 globalProcessor: [EMAIL PROTECTED] protocol: HTTP/1.0 currentQueryString: maxRequestUri:
Re: 1.0 Build failure on WinXP
I am also seeing this on win XP: assemble:package-assembly: [echo] Preparing CRLF line endings in text based files for zip distribution BUILD FAILED File.. C:\Documents and Settings\User\.maven\cache\geronimo-assembly-plugin-1.1.2\plugin.jelly Element... ant:fixcrlf Line.. 284 Column 70 Unable to delete D:\anita\geronimo\geronimo-1.0\assemblies\j2ee-tomcat-server\target\geronimo-1.0-SNAPSHOT\config-store\ index.properties Total time: 48 seconds Finished at: Fri Jan 06 11:51:55 EST 2006 Thanks Anita --- Joe Bohn [EMAIL PROTECTED] wrote: I've been trying to build 1.0 for a while now on winXP and I always get a failure preparing the CRLF endings (actually I get this failure about 90% of the time and it works the other 10%). assemble:package-assembly: [echo] Preparing CRLF line endings in text based files for zip distribution BUILD FAILED File.. C:\geronimo1.0\maven.xml Element... maven:reactor Line.. 63 Column -1 Unable to obtain goal [multiproject:install-callback] -- C:\Documents and Settings\Administrator\.maven\cache\geronimo-assembly-plugin-1.0.2\plugin.jelly:285:-1 : ant:fixcrlf java.io.FileNotFoundException: C:\geronimo1.0\assemblies\j2ee-jetty-server\target\geronimo-1.0\config-store\21\war\index.html (Access is denied) Total time : 26 minutes 17 seconds Finished at : Thursday, January 5, 2006 12:39:55 PM EST I've been ignoring this because I typically run right off of the assemblies that are created ... but it bothers me that I can't get a clean 1.0 build on Windows as we are about to release. The configuration in 21 appears to be the demo application and it doesn't include an index.html (hence the failure). I'm not altogether sure why the CRLF code thinks there should be an index.html to convert. One other curious thing I noticed is that there are 32 configurations in config-store for the jetty image but only 31 for tomcat. Anybody know offhand what the difference is and why? Thanks, Joe -- Joe Bohn [EMAIL PROTECTED] He is no fool who gives what he cannot keep, to gain what he cannot lose. -- Jim Elliot __ Yahoo! DSL Something to write home about. Just $16.99/mo. or less. dsl.yahoo.com
Re: Tomcat 5.5.9 vs 5.5.12
On Jan 6, 2006, at 12:39 PM, anita kulshreshtha wrote: The tomcat version used in the source at https://svn.apache.org/repos/asf/geronimo/tags/1.0.0/ is 5.5.12, whereas the tomcat version used in the released binaries is 5.5.9. The following problem does not occur in 5.5.9. Hi Anita, Late in the 1.0 cycle, we ran into some issues with TC 5.5.12 and had to regress to 5.5.9 to fix them. Since there is the general hope to move to 5.5.15 in the near future, we'll still need to fix... Thanks for the additional info... --kevan --- anita kulshreshtha [EMAIL PROTECTED] wrote: Jeff, Thanks, for looking into this. Now I am seeing the request processors! The output for geronimo is attached. What changes did you make? Thanks again! Anita --- anita kulshreshtha [EMAIL PROTECTED] wrote: Jeff, In a standalone configuration tomcat configures an MBean Name: Catalina:type=RequestProcessor,worker=http-8080,name=HttpRequest0. This is not being configured in G. Do you have any ideas why? I am attaching a list of all RequestProcessors running in a standalone tomcat. The G ones can be viewed by deploying the war attached to G-1293. There are none! Each request thread has an associated RequestInfo which is used to gather stats. Thanks Anita __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com Name: Catalina:type=RequestProcessor,worker=http-8080,name=HttpRequest2 modelerType: org.apache.coyote.RequestInfo bytesSent: 10626 method: GET remoteAddr: 127.0.0.1 requestBytesSent: 0 contentLength: -1 bytesReceived: 0 requestProcessingTime: 84531 globalProcessor: [EMAIL PROTECTED] protocol: HTTP/1.0 currentQueryString: maxRequestUri: /manager/status requestBytesReceived: 0 serverPort: -1 stage: 7 requestCount: 6 maxTime: 78 processingTime: 156 currentUri: / errorCount: 3 Name: Catalina:type=RequestProcessor,worker=http-8080,name=HttpRequest0 modelerType: org.apache.coyote.RequestInfo virtualHost: localhost bytesSent: 122571 method: GET remoteAddr: 127.0.0.1 requestBytesSent: 221184 contentLength: -1 bytesReceived: 0 requestProcessingTime: 422 globalProcessor: [EMAIL PROTECTED] protocol: HTTP/1.1 currentQueryString: maxRequestUri: /manager/jmxproxy/ requestBytesReceived: 0 serverPort: 8080 stage: 3 requestCount: 9 maxTime: 328 processingTime: 875 currentUri: /manager/jmxproxy/ errorCount: 4 Name: Catalina:type=RequestProcessor,worker=http-8080,name=HttpRequest1 modelerType: org.apache.coyote.RequestInfo bytesSent: 22380 method: GET remoteAddr: 127.0.0.1 requestBytesSent: 0 contentLength: -1 bytesReceived: 0 requestProcessingTime: 1840890 globalProcessor: [EMAIL PROTECTED] protocol: HTTP/1.0 currentQueryString: maxRequestUri: /manager/images/jakarta-logo.gif requestBytesReceived: 0 serverPort: -1 stage: 7 requestCount: 5 maxTime: 63 processingTime: 140 currentUri: / errorCount: 1 __ Yahoo! for Good - Make a difference this year. http://brand.yahoo.com/cybergivingweek2005/ OK - Number of results: 4 Name: Geronimo:type=RequestProcessor,worker=http-0.0.0.0-8080,name=HttpReque st3 modelerType: org.apache.coyote.RequestInfo virtualHost: localhost bytesSent: 10399 method: GET remoteAddr: 127.0.0.1 requestBytesSent: 0 contentLength: -1 bytesReceived: 0 requestProcessingTime: 15 globalProcessor: [EMAIL PROTECTED] protocol: HTTP/1.1 currentQueryString: qry=*%3Atype%3DRequestProcessor%2C* maxRequestUri: /stats/jmxproxy/ requestBytesReceived: 0 serverPort: 8080 stage: 3 requestCount: 10 maxTime: 78 processingTime: 171 currentUri: /stats/jmxproxy/ errorCount: 7 Name: Geronimo:type=RequestProcessor,worker=http-0.0.0.0-8080,name=HttpReque st1 modelerType: org.apache.coyote.RequestInfo bytesSent: 232019 method: GET remoteAddr: 127.0.0.1 requestBytesSent: 0 contentLength: -1 bytesReceived: 0 requestProcessingTime: 78906 globalProcessor: [EMAIL PROTECTED] protocol: HTTP/1.0 currentQueryString: maxRequestUri: /console/portal/apps/apps_war requestBytesReceived: 0 serverPort: -1 stage: 7 requestCount: 21 maxTime: 4734 processingTime: 13202 currentUri: / errorCount: 7 Name: Geronimo:type=RequestProcessor,worker=http-0.0.0.0-8443,name=HttpReque st0 modelerType: org.apache.coyote.RequestInfo bytesSent: 0 method: GET requestBytesSent: 0 contentLength: -1 bytesReceived: 0 requestProcessingTime: 1135965870625 globalProcessor: [EMAIL PROTECTED] protocol: HTTP/1.0 currentQueryString: requestBytesReceived: 0 serverPort: -1 stage: 0 requestCount: 0 maxTime: 0 processingTime: 0 currentUri: / errorCount: 0 Name: Geronimo:type=RequestProcessor,worker=http-0.0.0.0-8080,name=HttpReque st2 modelerType: org.apache.coyote.RequestInfo bytesSent: 57770 method: GET remoteAddr: 127.0.0.1 requestBytesSent: 0 contentLength: -1 bytesReceived: 49 requestProcessingTime: 135860 globalProcessor: [EMAIL PROTECTED] protocol: HTTP/1.0
Re: [wadi-dev] Re: [Geronimo] Clustering
Jules, no I was thiking more of WADI and ActiveCluster as complimentry. Sorry if I wasn't clear on that. I was thinking about amerge more in terms of consolidating effort/energy into one area without been spread too thin. But there seems to be enough intrest and people and maynot be a concern. Also with the seperate mailling lists it may not be possible for people to participate in discussions that maybe benifit more than one area of clustering. But that can be avoid if General discussions are kept with the geronimo dev list. There is also an advantage of keeping them as seperate projects so people can work on there pet area by not really being slowed down by the overall administrativegoals of the merged project. (I mean like releases or when it should be taged/branched ...etc) and also they can maintain there own identity while collaborating with the overall effort. Do you have a pet clustering area ? You were right I like HA_JNDI area, but will try to participate in every aspect of clustering within Geronimo. +1 for the document. These disscussions have been a very good learning experiance and if somebody can consolidate into a document it will be very helpful. Thanks a lot for you/james/matt and all the people who have kept this discussion going. It was very helpful and u guys have answered so many concerns and questions regarding the topic. Regards, Rajith Attapattu. On 1/6/06, Jules Gosnell [EMAIL PROTECTED] wrote: Matt Hogstrom wrote: Jules, I think you are spot on with a summary at this point.At least in my conversations a person's view of clustering is influenced by which aspect of clustering they are intersted in.I think a short doc would be really helpful here.Were you planning on doing that or would you like some help?Matt,The more I look at the amount of work that needs doing the more help Ithink I need !I am away this weekend, but I will try to put together a documentskeleton early next week that defines the areas that we need to cover. Then we can refer back to various discussions on the list to flesh outthe relevant areas. I'm not sure of the best way of making this documentavailable so that everyone can contribute - but we can worry about that when we have one.Do you have a pet clustering area ? Have we discussed it ?Jules Jules Gosnell wrote: Rajith Attapattu wrote: Hmm,again we have stopped the discussion :). Lets get it started again. OK - I will pick it up. I've been a bit preoccupied with WADI for a while, so apologies for letting this one go cold. So can we all come to some agreement (with more discussion) on which direction we might be taking !! Like merging ActiveCluster and WADI or getting best of both worlds ? hmmm... not sure I follow you here... are you suggesting merging them because you view them as (a) competing or (b) complimentary technologies ? If (a), then I need to put you straight. WADI is a technology that builds on top of ActiveCluster (AC). AC provides basic clustering fn-ality (most importantly, a membership abstraction along with notifications of membership change). If (b), then, whilst WADI and AC could be merged, the current separation is along clear and modular lines and I see no advantage to collapsing the two projects into one. I think that there is far more reason to consider a merger between ActiveSpace (AS). AS is a project that also builds upon ActiveCluster to provide distributed caching fn-ality. The fundamental difference (and I stand open to correction from James here - I'm not very knowledgeable about AS) is that AS provides a host of optimistic caching strategies, whilst WADI (currently) provides a single, pessimistic strategy specifically designed for the management of state in web and ejb tiers, where the sum of the state in the tier is too great to be held by any single node. Because WADI and AC fulfil similar roles, I think that there is more to be gained by unifying their APIs and code-sharing between them. James, if you are reading, what do you think ? And also if we can define expectations/requirments for what we like for the next possible release (1.01 or whatever) in terms of clustering would give folks like me more direction as to where we should concentrate on? Well, I think that there has been plenty of discussion, but you are correct in pointing out that there is no grand unified architecture document out there. I did start on my suggestions towards one quietly a while ago, but canned them. Perhaps enough discussion has now occurred to put up a straw man ? Is this what you are looking for ? If we decide on a direction maybe a few of us can start on a few prototypes and see what works best for Geronimo. Rajith, judging from our conversations on this list, your interest seems to lie in JNDI clustering ? I think that we need to get you, Gianny Damour (working on OpenEJB/WADI integration), James Strachan (ActiveSpace) and Kresten Krab (Trifork guy involved in IIOP stuff, which needs to be worked into equation)
Re: Geronimo 2.0
Either I don't understand what is being proposed or I think it is a recipe for disaster. My past experience with open source projects leads me to believe that having more than one main development area that is leading to a release is likely to cause only confusion, not progress towards functionality. In my opinion if we call head 2.0 and start adding JEE 5 features to it, there will never be any more j2ee 1.4 releases with added functionality. We will have a couple bug fix 1.0 releases, then a year or so while we try to finish JEE 5. I don't think this is acceptable. I would like to propose a process by which disruptive new feature development occurs in separate subprojects or feature-specific branches that can be merged into trunk when feature complete and stable. I realize there are some significant problems with this as regards JEE 5, at least as far as jdk support level, in that JEE 5 requires use of jdk 1.4 incompatible code. Personally I don't have enough information about how hard it is to convert to generics to begin to guess what these problems might be. It would also be useful to know more about e.g. whether retrotranslator might actually work. I think in order to consider this realistically we need a list of features we plan to add and to decide for each one of them whether it requires jdk 1.5 support and whether it can fit into 1.0. For instance I think the proposed security improvements could fit into 1.0 written in jdk 1.4. At this point, I think we should label head 1.1-SNAPSHOT and work on any features that require 1.5 in one or more branches, labelled by feature. I also think we need to decide on and publish criteria for including bug fixes in 1.0.1, and indeed if we want to release a 1.0.1 or just go for 1.1. thanks david jencks On Jan 6, 2006, at 9:10 AM, Alan D. Cabrera wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Matt Hogstrom wrote, On 1/6/2006 7:07 AM: I'll summarize what I think I read. HEAD will be 2.0 which includes JEE 5 and other significant work (Maven 2 conversion, etc.) Branches/1.0 will be where the work for 1.0.x will take place. It would be from this code base we'd branch to a 1.1 when appropriate. So, we would eventually have 2 branches and 1 trunk: branches/1.0 branches/1_trunk tags/* trunk I'm updating my local copy of the branches/1.0 with a version change for Geronimo to 1.0.1-SNAPSHOT as well as updating to Tomcay 5.1.15 and Jetty 5.1.10 to incoroporate the latent fixes. I'll build and test to make sure its still working (I'm not going to run TCK). and then commit these changes back when I've confirmed we're ready to go for 1.0.1. Does this sound workable? Can we have jira issues assigned to 1.0.1 so that we can see what's coming down the pipeline? Regards, Alan -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDvqSa1xC6qnMLUpYRArhpAJ91d5cSrHGEsY0pG6Jf+Nb+9gNuSgCfR8gH m3qYJWEG9Zej/Sg+O5pMPQA= =goh1 -END PGP SIGNATURE-
Re: Geronimo 2.0
David Jencks wrote: Either I don't understand what is being proposed or I think it is a recipe for disaster. My past experience with open source projects leads me to believe that having more than one main development area that is leading to a release is likely to cause only confusion, not progress towards functionality. In my opinion if we call head 2.0 and start adding JEE 5 features to it, there will never be any more j2ee 1.4 releases with added functionality. We will have a couple bug fix 1.0 releases, then a year or so while we try to finish JEE 5. I don't think this is acceptable. From my experience working on the Apache HTTP Server, I agree with David. Bill
Re: Geronimo 2.0
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 David Jencks wrote, On 1/6/2006 11:10 AM: Either I don't understand what is being proposed or I think it is a recipe for disaster. My past experience with open source projects leads me to believe that having more than one main development area that is leading to a release is likely to cause only confusion, not progress towards functionality. In my opinion if we call head 2.0 and start adding JEE 5 features to it, there will never be any more j2ee 1.4 releases with added functionality. We will have a couple bug fix 1.0 releases, then a year or so while we try to finish JEE 5. I don't think this is acceptable. I would like to propose a process by which disruptive new feature development occurs in separate subprojects or feature-specific branches that can be merged into trunk when feature complete and stable. I realize there are some significant problems with this as regards JEE 5, at least as far as jdk support level, in that JEE 5 requires use of jdk 1.4 incompatible code. Personally I don't have enough information about how hard it is to convert to generics to begin to guess what these problems might be. It would also be useful to know more about e.g. whether retrotranslator might actually work. I think in order to consider this realistically we need a list of features we plan to add and to decide for each one of them whether it requires jdk 1.5 support and whether it can fit into 1.0. For instance I think the proposed security improvements could fit into 1.0 written in jdk 1.4. At this point, I think we should label head 1.1-SNAPSHOT and work on any features that require 1.5 in one or more branches, labelled by feature. Your assumption is that 1.5 features are compact concise changes. The changes that are required, though, are quite comprehensive. I think we at least need a single 1.5 branch as well as a 1.4 branch. I also think we need to decide on and publish criteria for including bug fixes in 1.0.1, and indeed if we want to release a 1.0.1 or just go for 1.1. We need to pump out 1.0.1 ASAP. Regards, Alan -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDvsmc1xC6qnMLUpYRAjisAJ4uYVFdWnt8ZR4Ib/a6hAJgMsDBDgCdGZIc kpoS00XdIBMpN8z5Qsa3Ll4= =6bQl -END PGP SIGNATURE-
[jira] Created: (GERONIMO-1425) access to unprotected web resource after login does not use correct Subject
access to unprotected web resource after login does not use correct Subject --- Key: GERONIMO-1425 URL: http://issues.apache.org/jira/browse/GERONIMO-1425 Project: Geronimo Type: Bug Components: Tomcat, web Versions: 1.1 Reporter: David Jencks Assigned to: David Jencks Fix For: 1.1 This applies to both jetty and tomcat. Currently we are installing the correct authenticated Subject in ContextManager only when you access a protected resource. For any access to unprotected resources, even after logon, we are installing the default Subject in the ContextManager. This appears to violate this from servlet spec 2.4 12.7: A security identity, or principal, must always be provided for use in a call to an enterprise bean. The default mode in calls to enterprise beans from web applications is for the security identity of a web user to be propagated to the EJBTM container. After logon, the security identity of the user is known, whether or not they are visiting a protected resource. Therefore the default is to use this identity in ejb calls, which for us requires putting the authenticated subject in the ContextManager. Alan Cabrera has some doubts that this spec language actually requires us to implement the default behavior stated here, and I agree that a strict reading does not seem to require this, but IIUC we agree that we should implement this behavior anyway. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [jira] Created: (GERONIMO-1425) access to unprotected web resource after login does not use correct Subject
I think it would be nice to behave like you're describing, but I believe that the spec does not require it. That is, if the default principal is anonymous and the current user is aaron, I think it's legit to have protected pages use the aaron subject and non-protected pages use the anonymous subject (I'm pretty sure some other servers work that way), but it would be nicer if both types of pages used the aaron subject until that session expired or the user logs out. Aaron On 1/6/06, David Jencks (JIRA) dev@geronimo.apache.org wrote: access to unprotected web resource after login does not use correct Subject --- Key: GERONIMO-1425 URL: http://issues.apache.org/jira/browse/GERONIMO-1425 Project: Geronimo Type: Bug Components: Tomcat, web Versions: 1.1 Reporter: David Jencks Assigned to: David Jencks Fix For: 1.1 This applies to both jetty and tomcat. Currently we are installing the correct authenticated Subject in ContextManager only when you access a protected resource. For any access to unprotected resources, even after logon, we are installing the default Subject in the ContextManager. This appears to violate this from servlet spec 2.4 12.7: A security identity, or principal, must always be provided for use in a call to an enterprise bean. The default mode in calls to enterprise beans from web applications is for the security identity of a web user to be propagated to the EJBTM container. After logon, the security identity of the user is known, whether or not they are visiting a protected resource. Therefore the default is to use this identity in ejb calls, which for us requires putting the authenticated subject in the ContextManager. Alan Cabrera has some doubts that this spec language actually requires us to implement the default behavior stated here, and I agree that a strict reading does not seem to require this, but IIUC we agree that we should implement this behavior anyway. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Shutdown problems encountered on 1.0 RC
On Jan 5, 2006, at 4:42 PM, John Sisson wrote: I have encountered some Geronimo shutdown issues with ActiveMQ on the 1.0 release candidate on Solaris 10 x86 under VMWare. Can you be more specific? How about a stack trace. -dain
Re: Geronimo 2.0
David has a compelling argument... I am concerned about delivering j2ee 1.4 features and release over the next year while jee5 is written. I don't want to repeat the lesson we all learned with the very very long gap between m3 and m4. With out micro kernel design, don't you think we should be able to develop most of the jee5 new features in plugin modules or subprojects? Regaurdless, I have a few features I'd like to put into 1.x to make transition to 2.x painless, so I will be working on whatever branch is to become 1.1. -dain On Jan 6, 2006, at 11:10 AM, David Jencks wrote: Either I don't understand what is being proposed or I think it is a recipe for disaster. My past experience with open source projects leads me to believe that having more than one main development area that is leading to a release is likely to cause only confusion, not progress towards functionality. In my opinion if we call head 2.0 and start adding JEE 5 features to it, there will never be any more j2ee 1.4 releases with added functionality. We will have a couple bug fix 1.0 releases, then a year or so while we try to finish JEE 5. I don't think this is acceptable. I would like to propose a process by which disruptive new feature development occurs in separate subprojects or feature-specific branches that can be merged into trunk when feature complete and stable. I realize there are some significant problems with this as regards JEE 5, at least as far as jdk support level, in that JEE 5 requires use of jdk 1.4 incompatible code. Personally I don't have enough information about how hard it is to convert to generics to begin to guess what these problems might be. It would also be useful to know more about e.g. whether retrotranslator might actually work. I think in order to consider this realistically we need a list of features we plan to add and to decide for each one of them whether it requires jdk 1.5 support and whether it can fit into 1.0. For instance I think the proposed security improvements could fit into 1.0 written in jdk 1.4. At this point, I think we should label head 1.1-SNAPSHOT and work on any features that require 1.5 in one or more branches, labelled by feature. I also think we need to decide on and publish criteria for including bug fixes in 1.0.1, and indeed if we want to release a 1.0.1 or just go for 1.1. thanks david jencks On Jan 6, 2006, at 9:10 AM, Alan D. Cabrera wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Matt Hogstrom wrote, On 1/6/2006 7:07 AM: I'll summarize what I think I read. HEAD will be 2.0 which includes JEE 5 and other significant work (Maven 2 conversion, etc.) Branches/1.0 will be where the work for 1.0.x will take place. It would be from this code base we'd branch to a 1.1 when appropriate. So, we would eventually have 2 branches and 1 trunk: branches/1.0 branches/1_trunk tags/* trunk I'm updating my local copy of the branches/1.0 with a version change for Geronimo to 1.0.1-SNAPSHOT as well as updating to Tomcay 5.1.15 and Jetty 5.1.10 to incoroporate the latent fixes. I'll build and test to make sure its still working (I'm not going to run TCK). and then commit these changes back when I've confirmed we're ready to go for 1.0.1. Does this sound workable? Can we have jira issues assigned to 1.0.1 so that we can see what's coming down the pipeline? Regards, Alan -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDvqSa1xC6qnMLUpYRArhpAJ91d5cSrHGEsY0pG6Jf+Nb+9gNuSgCfR8gH m3qYJWEG9Zej/Sg+O5pMPQA= =goh1 -END PGP SIGNATURE-
Re: Geronimo 2.0
Once I finish the suddenly-urgent mountain of book work, I have a lot more console and management stuff to work on. There's no reason that has to wait for a rewritten CORBA stack, EJB3 container, security stack, etc., much less all the new specs and JSRs. So I certainly plan to contribute to a 1.1 release. (I'm not sure whether new Jetspeed/Pluto integration would fit into 1.1 or 2.0, though 1.1 would be nice.) I'd prefer to see us draw up as much of a feature list as we can for 1.1 and 2.0, and then based on those think about where we want to put things and how we branch. That may also suggest a time frame for each. Aaron On 1/6/06, David Jencks [EMAIL PROTECTED] wrote: Either I don't understand what is being proposed or I think it is a recipe for disaster. My past experience with open source projects leads me to believe that having more than one main development area that is leading to a release is likely to cause only confusion, not progress towards functionality. In my opinion if we call head 2.0 and start adding JEE 5 features to it, there will never be any more j2ee 1.4 releases with added functionality. We will have a couple bug fix 1.0 releases, then a year or so while we try to finish JEE 5. I don't think this is acceptable. I would like to propose a process by which disruptive new feature development occurs in separate subprojects or feature-specific branches that can be merged into trunk when feature complete and stable. I realize there are some significant problems with this as regards JEE 5, at least as far as jdk support level, in that JEE 5 requires use of jdk 1.4 incompatible code. Personally I don't have enough information about how hard it is to convert to generics to begin to guess what these problems might be. It would also be useful to know more about e.g. whether retrotranslator might actually work. I think in order to consider this realistically we need a list of features we plan to add and to decide for each one of them whether it requires jdk 1.5 support and whether it can fit into 1.0. For instance I think the proposed security improvements could fit into 1.0 written in jdk 1.4. At this point, I think we should label head 1.1-SNAPSHOT and work on any features that require 1.5 in one or more branches, labelled by feature. I also think we need to decide on and publish criteria for including bug fixes in 1.0.1, and indeed if we want to release a 1.0.1 or just go for 1.1. thanks david jencks On Jan 6, 2006, at 9:10 AM, Alan D. Cabrera wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Matt Hogstrom wrote, On 1/6/2006 7:07 AM: I'll summarize what I think I read. HEAD will be 2.0 which includes JEE 5 and other significant work (Maven 2 conversion, etc.) Branches/1.0 will be where the work for 1.0.x will take place. It would be from this code base we'd branch to a 1.1 when appropriate. So, we would eventually have 2 branches and 1 trunk: branches/1.0 branches/1_trunk tags/* trunk I'm updating my local copy of the branches/1.0 with a version change for Geronimo to 1.0.1-SNAPSHOT as well as updating to Tomcay 5.1.15 and Jetty 5.1.10 to incoroporate the latent fixes. I'll build and test to make sure its still working (I'm not going to run TCK). and then commit these changes back when I've confirmed we're ready to go for 1.0.1. Does this sound workable? Can we have jira issues assigned to 1.0.1 so that we can see what's coming down the pipeline? Regards, Alan -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDvqSa1xC6qnMLUpYRArhpAJ91d5cSrHGEsY0pG6Jf+Nb+9gNuSgCfR8gH m3qYJWEG9Zej/Sg+O5pMPQA= =goh1 -END PGP SIGNATURE-
Re: Geronimo 2.0
2006/1/6, David Jencks [EMAIL PROTECTED]: Either I don't understand what is being proposed or I think it is a recipe for disaster. Hi Dave, I think there might be the third option ;) My past experience with open source projects leads me to believe that having more than one main development area that is leading to a release is likely to cause only confusion, not progress towards functionality. Well, the more branches we will have the more headaches it will cause to us. I think that's totally unavoidable when moving towards JEE 5 where Java 5 plays a crucial role. In my opinion if we call head 2.0 and start adding JEE 5 features to it, there will never be any more j2ee 1.4 releases with added functionality. We will have a couple bug fix 1.0 releases, then a year or so while we try to finish JEE 5. I don't think this is acceptable. Correct. I would like to propose a process by which disruptive new feature development occurs in separate subprojects or feature-specific branches that can be merged into trunk when feature complete and stable. That's exactly what was said. Noone suggested to work on HEAD and eventually breaks it for weeks. I think one of the reason we switched to svn was the simplicity to create and merge a branch. We can therefore easily experiment in our own branches, but that contradicts what you said above with more than one main development area. It's unavoidable in such a large project to have only one main development area. There's going to be lots of branches, imho. As far as EJB 3 is concerned it shouldn't be a big deal. It will be implemented by OpenEJB which is a separate project so appropriate interfaces should do the work nicely. The real pain will be with the other modules that will require separate branches and be merged once finished. I realize there are some significant problems with this as regards JEE 5, at least as far as jdk support level, in that JEE 5 requires use of jdk 1.4 incompatible code. Personally I don't have enough information about how hard it is to convert to generics to begin to guess what these problems might be. It would also be useful to know more about e.g. whether retrotranslator might actually work. I don't understand. Why are you scared of using Java 5? Geronimo 1.0 is on its own branch, and anybody who wants to play with the source code will download that branch. Others who want to be on the cutting edge will work with HEAD. Problems will have to be sorted out for sure, but Geronimo 1.0 is safe and so are their minor descendants (i.e. 1.x.x versions). I think in order to consider this realistically we need a list of features we plan to add and to decide for each one of them whether it requires jdk 1.5 support and whether it can fit into 1.0. For instance I think the proposed security improvements could fit into 1.0 written in jdk 1.4. But that wouldn't be 1.0 any more, but a branch called 1.0.x or 1.x. Weren't you worried about having more than one main development area? Aren't you proposing just that? At this point, I think we should label head 1.1-SNAPSHOT and work on any features that require 1.5 in one or more branches, labelled by feature. That's acceptable, but how long do you envision HEAD will survive before migrating to Java 5? Why don't you want to start using Java 5 right away? I don't remember who was it (possibly Dain) who expressed so much enthusiasm about using Java Generics and I really think it will save us a lot of time when developing with Java 5 instead of writing code that will be a nightmare to support. Ok, maybe it won't be a nightmare, but the additional code to support Java 1.4 will add unnecessary burden. I also think we need to decide on and publish criteria for including bug fixes in 1.0.1, and indeed if we want to release a 1.0.1 or just go for 1.1. That's an interesting matter. What changes make 1.x and what does 1.0.x? Anyone could comment on it. I think the security issue of Jetty asks for 1.0.x. david jencks Jacek
[jira] Created: (GERONIMO-1426) DatabasePoolPortlet gets NPE when saving
DatabasePoolPortlet gets NPE when saving Key: GERONIMO-1426 URL: http://issues.apache.org/jira/browse/GERONIMO-1426 Project: Geronimo Type: Bug Components: console Versions: 1.0 Environment: Windows XP, MySQL Connector 3.1.12, MySQL 5.0, JDK 1.4.2 Reporter: Cary Clark From a clean Geronimo 1.0 install: * Log in to console * add mysql-connector-java-3.1.12-bin.jar as a Common Library Group: mysql Artifact: mysql-connector-java-3.1.12 Version: bin Type: jar * Go to Database Pools, click Using the Geronimo database pool wizard Name of Database Pool:: CPPool Database Type: MySQL * Click Next JDBC Driver Class: JDBC Driver Class: Driver JAR: select mysql/ DB User Name: cpdb DB Password: cpdbuser Port: 3306 Host: localhost Database: cpdb * Click Next JDBC Connect URL: jdbc:mysql://localhost:3306/cpdb Driver Status: Loaded Successfully Pool Min Size: 10 Pool Max Size: 15 Blocking Timeout: NO VALUE ENTERED...assuming default * Click Test Connection, then Show Plan OR click Skip Test and Show Plan to get the following stack trace: 16:24:04,137 ERROR [DatabasePoolPortlet] Unable to save connection pool java.lang.NullPointerException at sun.misc.URLClassPath$3.run(URLClassPath.java:312) at java.security.AccessController.doPrivileged(Native Method) at sun.misc.URLClassPath.getLoader(URLClassPath.java:309) at sun.misc.URLClassPath.getLoader(URLClassPath.java:286) at sun.misc.URLClassPath.findResource(URLClassPath.java:137) at java.net.URLClassLoader$2.run(URLClassLoader.java:352) at java.security.AccessController.doPrivileged(Native Method) at java.net.URLClassLoader.findResource(URLClassLoader.java:349) at java.lang.ClassLoader.getResource(ClassLoader.java:787) at org.apache.geronimo.deployment.tools.loader.AbstractDeployable.init(AbstractDeployable.java:57) at org.apache.geronimo.deployment.tools.loader.ConnectorDeployable.init(ConnectorDeployable.java:37) at org.apache.geronimo.console.databasemanager.wizard.DatabasePoolPortlet.save(DatabasePoolPortlet.java:813) at org.apache.geronimo.console.databasemanager.wizard.DatabasePoolPortlet.processAction(DatabasePoolPortlet.java:339) at org.apache.pluto.core.PortletServlet.dispatch(PortletServlet.java:229) at org.apache.pluto.core.PortletServlet.doGet(PortletServlet.java:158) at javax.servlet.http.HttpServlet.service(HttpServlet.java:595) at javax.servlet.http.HttpServlet.service(HttpServlet.java:688) at org.apache.pluto.core.PortletServlet.service(PortletServlet.java:153) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173) at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:672) at org.apache.catalina.core.ApplicationDispatcher.doInclude(ApplicationDispatcher.java:574) at org.apache.catalina.core.ApplicationDispatcher.include(ApplicationDispatcher.java:499) at org.apache.pluto.invoker.impl.PortletInvokerImpl.invoke(PortletInvokerImpl.java:120) at org.apache.pluto.invoker.impl.PortletInvokerImpl.action(PortletInvokerImpl.java:68) at org.apache.pluto.PortletContainerImpl.processPortletAction(PortletContainerImpl.java:164) at org.apache.pluto.portalImpl.core.PortletContainerWrapperImpl.processPortletAction(PortletContainerWrapperImpl.java:82) at org.apache.pluto.portalImpl.Servlet.doGet(Servlet.java:227) at javax.servlet.http.HttpServlet.service(HttpServlet.java:595) at javax.servlet.http.HttpServlet.service(HttpServlet.java:688) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:178) at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:482) at org.apache.geronimo.tomcat.GeronimoStandardContext$SystemMethodValve.invoke(GeronimoStandardContext.java:272) at org.apache.geronimo.tomcat.valve.DefaultSubjectValve.invoke(DefaultSubjectValve.java:46) at org.apache.geronimo.tomcat.valve.PolicyContextValve.invoke(PolicyContextValve.java:50) at
[jira] Updated: (GERONIMO-1426) DatabasePoolPortlet gets NPE when saving
[ http://issues.apache.org/jira/browse/GERONIMO-1426?page=all ] Cary Clark updated GERONIMO-1426: - Description: From a clean Geronimo 1.0 install: * Log in to console * add mysql-connector-java-3.1.12-bin.jar as a Common Library Group: mysql Artifact: mysql-connector-java-3.1.12 Version: bin Type: jar * Go to Database Pools, click Using the Geronimo database pool wizard Name of Database Pool:: CPPool Database Type: MySQL * Click Next JDBC Driver Class: JDBC Driver Class: Driver JAR: select mysql/ DB User Name: cpdb DB Password: cpdbuser Port: 3306 Host: localhost Database: cpdb * Click Next JDBC Connect URL: jdbc:mysql://localhost:3306/cpdb Driver Status: Loaded Successfully Pool Min Size: 10 Pool Max Size: 15 Blocking Timeout: NO VALUE ENTERED...assuming default Idle Timeout: NO VALUE ENTERED...assuming default * Click Test Connection, then Show Plan OR click Skip Test and Show Plan to get the following stack trace: 16:24:04,137 ERROR [DatabasePoolPortlet] Unable to save connection pool java.lang.NullPointerException at sun.misc.URLClassPath$3.run(URLClassPath.java:312) at java.security.AccessController.doPrivileged(Native Method) at sun.misc.URLClassPath.getLoader(URLClassPath.java:309) at sun.misc.URLClassPath.getLoader(URLClassPath.java:286) at sun.misc.URLClassPath.findResource(URLClassPath.java:137) at java.net.URLClassLoader$2.run(URLClassLoader.java:352) at java.security.AccessController.doPrivileged(Native Method) at java.net.URLClassLoader.findResource(URLClassLoader.java:349) at java.lang.ClassLoader.getResource(ClassLoader.java:787) at org.apache.geronimo.deployment.tools.loader.AbstractDeployable.init(AbstractDeployable.java:57) at org.apache.geronimo.deployment.tools.loader.ConnectorDeployable.init(ConnectorDeployable.java:37) at org.apache.geronimo.console.databasemanager.wizard.DatabasePoolPortlet.save(DatabasePoolPortlet.java:813) at org.apache.geronimo.console.databasemanager.wizard.DatabasePoolPortlet.processAction(DatabasePoolPortlet.java:339) at org.apache.pluto.core.PortletServlet.dispatch(PortletServlet.java:229) at org.apache.pluto.core.PortletServlet.doGet(PortletServlet.java:158) at javax.servlet.http.HttpServlet.service(HttpServlet.java:595) at javax.servlet.http.HttpServlet.service(HttpServlet.java:688) at org.apache.pluto.core.PortletServlet.service(PortletServlet.java:153) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173) at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:672) at org.apache.catalina.core.ApplicationDispatcher.doInclude(ApplicationDispatcher.java:574) at org.apache.catalina.core.ApplicationDispatcher.include(ApplicationDispatcher.java:499) at org.apache.pluto.invoker.impl.PortletInvokerImpl.invoke(PortletInvokerImpl.java:120) at org.apache.pluto.invoker.impl.PortletInvokerImpl.action(PortletInvokerImpl.java:68) at org.apache.pluto.PortletContainerImpl.processPortletAction(PortletContainerImpl.java:164) at org.apache.pluto.portalImpl.core.PortletContainerWrapperImpl.processPortletAction(PortletContainerWrapperImpl.java:82) at org.apache.pluto.portalImpl.Servlet.doGet(Servlet.java:227) at javax.servlet.http.HttpServlet.service(HttpServlet.java:595) at javax.servlet.http.HttpServlet.service(HttpServlet.java:688) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:178) at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:482) at org.apache.geronimo.tomcat.GeronimoStandardContext$SystemMethodValve.invoke(GeronimoStandardContext.java:272) at org.apache.geronimo.tomcat.valve.DefaultSubjectValve.invoke(DefaultSubjectValve.java:46) at org.apache.geronimo.tomcat.valve.PolicyContextValve.invoke(PolicyContextValve.java:50) at org.apache.geronimo.tomcat.valve.TransactionContextValve.invoke(TransactionContextValve.java:53) at org.apache.geronimo.tomcat.valve.ComponentContextValve.invoke(ComponentContextValve.java:47)
[jira] Commented: (GERONIMO-1426) DatabasePoolPortlet gets NPE when saving
[ http://issues.apache.org/jira/browse/GERONIMO-1426?page=comments#action_12362012 ] Cary Clark commented on GERONIMO-1426: -- I also tested with Blocking Timeout: 12 and Idle Timeout: 3 with the same results DatabasePoolPortlet gets NPE when saving Key: GERONIMO-1426 URL: http://issues.apache.org/jira/browse/GERONIMO-1426 Project: Geronimo Type: Bug Components: console Versions: 1.0 Environment: Windows XP, MySQL Connector 3.1.12, MySQL 5.0, JDK 1.4.2 Reporter: Cary Clark From a clean Geronimo 1.0 install: * Log in to console * add mysql-connector-java-3.1.12-bin.jar as a Common Library Group: mysql Artifact: mysql-connector-java-3.1.12 Version: bin Type: jar * Go to Database Pools, click Using the Geronimo database pool wizard Name of Database Pool:: CPPool Database Type: MySQL * Click Next JDBC Driver Class: JDBC Driver Class: Driver JAR: select mysql/ DB User Name: cpdb DB Password: cpdbuser Port: 3306 Host: localhost Database: cpdb * Click Next JDBC Connect URL: jdbc:mysql://localhost:3306/cpdb Driver Status: Loaded Successfully Pool Min Size: 10 Pool Max Size: 15 Blocking Timeout: NO VALUE ENTERED...assuming default Idle Timeout: NO VALUE ENTERED...assuming default * Click Test Connection, then Show Plan OR click Skip Test and Show Plan to get the following stack trace: 16:24:04,137 ERROR [DatabasePoolPortlet] Unable to save connection pool java.lang.NullPointerException at sun.misc.URLClassPath$3.run(URLClassPath.java:312) at java.security.AccessController.doPrivileged(Native Method) at sun.misc.URLClassPath.getLoader(URLClassPath.java:309) at sun.misc.URLClassPath.getLoader(URLClassPath.java:286) at sun.misc.URLClassPath.findResource(URLClassPath.java:137) at java.net.URLClassLoader$2.run(URLClassLoader.java:352) at java.security.AccessController.doPrivileged(Native Method) at java.net.URLClassLoader.findResource(URLClassLoader.java:349) at java.lang.ClassLoader.getResource(ClassLoader.java:787) at org.apache.geronimo.deployment.tools.loader.AbstractDeployable.init(AbstractDeployable.java:57) at org.apache.geronimo.deployment.tools.loader.ConnectorDeployable.init(ConnectorDeployable.java:37) at org.apache.geronimo.console.databasemanager.wizard.DatabasePoolPortlet.save(DatabasePoolPortlet.java:813) at org.apache.geronimo.console.databasemanager.wizard.DatabasePoolPortlet.processAction(DatabasePoolPortlet.java:339) at org.apache.pluto.core.PortletServlet.dispatch(PortletServlet.java:229) at org.apache.pluto.core.PortletServlet.doGet(PortletServlet.java:158) at javax.servlet.http.HttpServlet.service(HttpServlet.java:595) at javax.servlet.http.HttpServlet.service(HttpServlet.java:688) at org.apache.pluto.core.PortletServlet.service(PortletServlet.java:153) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173) at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:672) at org.apache.catalina.core.ApplicationDispatcher.doInclude(ApplicationDispatcher.java:574) at org.apache.catalina.core.ApplicationDispatcher.include(ApplicationDispatcher.java:499) at org.apache.pluto.invoker.impl.PortletInvokerImpl.invoke(PortletInvokerImpl.java:120) at org.apache.pluto.invoker.impl.PortletInvokerImpl.action(PortletInvokerImpl.java:68) at org.apache.pluto.PortletContainerImpl.processPortletAction(PortletContainerImpl.java:164) at org.apache.pluto.portalImpl.core.PortletContainerWrapperImpl.processPortletAction(PortletContainerWrapperImpl.java:82) at org.apache.pluto.portalImpl.Servlet.doGet(Servlet.java:227) at javax.servlet.http.HttpServlet.service(HttpServlet.java:595) at javax.servlet.http.HttpServlet.service(HttpServlet.java:688) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:178) at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:482) at
Re: Geronimo 2.0
On Jan 6, 2006, at 11:10 AM, David Jencks wrote: Either I don't understand what is being proposed or I think it is a recipe for disaster. My past experience with open source projects leads me to believe that having more than one main development area that is leading to a release is likely to cause only confusion, not progress towards functionality. In my opinion if we call head 2.0 and start adding JEE 5 features to it, there will never be any more j2ee 1.4 releases with added functionality. We will have a couple bug fix 1.0 releases, then a year or so while we try to finish JEE 5. I don't think this is acceptable. Amen! We can't go from two years of development on 1.x with little to no user interaction then abandon it after the first release and go back into the development hole. We need to follow through on Geronimo 1.x for a few release cycles, get some user feedback, learn the lessons we need to learn for a while, *then* start Geronimo 2.0. Now is not the time to turn our focus to the next shinny ball, now is the time to focus on users of 1.x as they will need our dedication before they can bring it into production. There is my $0.02. -David
Re: Geronimo 2.0
I agree and do not advocate upgrading releases. However, Jetty I think is a requirements as there is a security hole. As far as Tomcat is concerned I'll defer that decision to you :) Matt Alan D. Cabrera wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Kevan Miller wrote, On 1/6/2006 8:47 AM: On Jan 6, 2006, at 10:07 AM, Matt Hogstrom wrote: I'll summarize what I think I read. HEAD will be 2.0 which includes JEE 5 and other significant work (Maven 2 conversion, etc.) Branches/1.0 will be where the work for 1.0.x will take place. It would be from this code base we'd branch to a 1.1 when appropriate. I'm updating my local copy of the branches/1.0 with a version change for Geronimo to 1.0.1-SNAPSHOT as well as updating to Tomcay 5.1.15 and Jetty 5.1.10 to incoroporate the latent fixes. I'll build and test to make sure its still working (I'm not going to run TCK). and then commit these changes back when I've confirmed we're ready to go for 1.0.1. Does this sound workable? Matt, Tomcat 5.5.15 is stll in Beta. So, I'd hold off just a bit. Preliminary tests look good. I'm running a more complete test, now. How about you update version and Jetty. I'll cutover Tomcat when appropriate... Good point Keven. Matt, I think that we should avoid version upgrades for a patch release if we can help it. Regards, Alan -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDvqTe1xC6qnMLUpYRAuwiAJ0fgGNJpSyxWKop798/EVtM3XLZCgCfQv8J QKSjMpmRG4SFbEg052RmpN0= =aRfh -END PGP SIGNATURE-
Re: Shutdown problems encountered on 1.0 RC
Dain Sundstrom wrote: On Jan 5, 2006, at 4:42 PM, John Sisson wrote: I have encountered some Geronimo shutdown issues with ActiveMQ on the 1.0 release candidate on Solaris 10 x86 under VMWare. Can you be more specific? How about a stack trace. -dain GERONIMO-1422 has an attachment with the stdout messages and a thread strack trace in it (via sending kill -QUIT ). John
Re: Regd OpenEJB
Hi Manu, You are once again correct: let's remove this read-only decorator - this was a very bad idea - at least if the field is a PK one. This read only behavior was intended to prevent developers from changing a relationship to a CMP having a coumpond PK with multiple fields. Indeed, in this case, if the CMP field is updated, this implies that the relationship is (partially, as only one field is updated) updated and I am not sure that it is safe to let such a thing to happen. Thanks for your work on this, Gianny Manu George wrote: Hi Gianny, I have a question on CMR Consider a Bean A and a bean B in a one to many CMR relationship Here A has 2 fields in the PK say a1 and a2 B has b1 fka1 and fka2 as the pk where fka1 and fka2 are the foreign keys corressponding to the a1 and a2 of A. In the ejbCreate of B when we set fka1 and fka2 won't OpenEJB throw an error saying that they are readonly fields. This will happen even after implementing the logic for the special case where the CompoundPK has 1 field. Is this scenario a valid scenario? If so can we change the check in createCMPFieldAccessors to check for primary key and allow write access to CMR fields if they are parts of Primary Keys? What should be the correct behaviour? Thanks Manu
[jira] Updated: (GERONIMO-1427) Create a stripped down assembly that includes ActiveMQ, Derby, Jetty/Tomcat and transaction
[ http://issues.apache.org/jira/browse/GERONIMO-1427?page=all ] David Jencks updated GERONIMO-1427: --- Attachment: separate-openejb-2.diff The attached patch creates 4 new configurations for openejb, axis, openejb-builder, and axis-builder, and adds them to the existing servers. There's also a completely untested UnavailableModuleBuilder. The servers start fine and daytrader runs OK. If no one objects I'll commit this in a bit. This is NOT A COMPLETE SOLUTION!! Remaining work: - separate app client stuff into 2 more modules - consider separating connector/tm into 2 more modules - FIX THE DEPENDENCIES. I basically left all the dependencies in j2ee-server and j2ee-deployer. A lot of careful work is needed to get the correct dependencies into the openejb and axis configurations and to determine the correct parent configs for them. - give the web service builder a default parentId it can add to a configuration under construction. To compensate for this lack I included the axis module in the defaultParentId in the builders for jetty, tomcat, and openejb. This will mean for instance that axis is required to run jetty. Create a stripped down assembly that includes ActiveMQ, Derby, Jetty/Tomcat and transaction --- Key: GERONIMO-1427 URL: http://issues.apache.org/jira/browse/GERONIMO-1427 Project: Geronimo Type: New Feature Components: general Versions: 1.1 Reporter: Bruce Snyder Attachments: separate-openejb-2.diff -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (GERONIMO-1342) Startup error
[ http://issues.apache.org/jira/browse/GERONIMO-1342?page=comments#action_12362041 ] wai yung commented on GERONIMO-1342: The problem is kernel related. I upgraded my kernel to 2.4 and the bug is fixed. Startup error - Key: GERONIMO-1342 URL: http://issues.apache.org/jira/browse/GERONIMO-1342 Project: Geronimo Type: Bug Versions: 1.0-M5 Environment: Debian Reporter: wai yung Fix For: 1.1 I got this error when I try to start the app server. Tried to changed some values to feed the Howl but it didn't work. What could be the causes ? Thanks, Wai Yung - Exceptions - waiyung:/usr/local/share/geronimo-1.0-M5/bin# ./startup.sh Booting Geronimo Kernel (in Java 1.5.0_05)... Starting Geronimo Application Server [*** ] 25% 5s Starting org/apache/geronimo/Server 22:49:21,449 ERROR [GBeanInstanceState] Error while starting; GBean is now in the FAILED state: objectName=geronimo.server:J2EEApplication=null,J2EEModule=org/apache/geronimo/Server,J2EEServer=geronimo,j2eeType=TransactionLog,name=HOWLTransactionLog org.objectweb.howl.log.LogConfigurationException: java.io.IOException: Value too large for defined data type at org.objectweb.howl.log.LogFile.open(LogFile.java:179) at org.objectweb.howl.log.LogFileManager.open(LogFileManager.java:735) at org.objectweb.howl.log.Logger.open(Logger.java:291) at org.objectweb.howl.log.xa.XALogger.open(XALogger.java:852) at org.apache.geronimo.transaction.log.HOWLLog.doStart(HOWLLog.java:217) at org.apache.geronimo.gbean.runtime.GBeanInstance.createInstance(GBeanInstance.java:891) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStart(GBeanInstanceState.java:325) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.start(GBeanInstanceState.java:110) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.startRecursive(GBeanInstanceState.java:132) at org.apache.geronimo.gbean.runtime.GBeanInstance.startRecursive(GBeanInstance.java:497) at org.apache.geronimo.kernel.basic.BasicKernel.startRecursiveGBean(BasicKernel.java:210) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.startRecursive(GBeanInstanceState.java:140) at org.apache.geronimo.gbean.runtime.GBeanInstance.startRecursive(GBeanInstance.java:497) at org.apache.geronimo.kernel.basic.BasicKernel.startRecursiveGBean(BasicKernel.java:210) at org.apache.geronimo.system.main.Daemon.doStartup(Daemon.java:233) at org.apache.geronimo.system.main.Daemon.init(Daemon.java:78) at org.apache.geronimo.system.main.Daemon.main(Daemon.java:316) Caused by: java.io.IOException: Value too large for defined data type at sun.nio.ch.FileChannelImpl.lock0(Native Method) at sun.nio.ch.FileChannelImpl.tryLock(FileChannelImpl.java:822) at java.nio.channels.FileChannel.tryLock(FileChannel.java:967) at org.objectweb.howl.log.LogFile.open(LogFile.java:177) ... 16 more -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (GERONIMO-1427) Create a stripped down assembly that includes ActiveMQ, Derby, Jetty/Tomcat and transaction
[ http://issues.apache.org/jira/browse/GERONIMO-1427?page=comments#action_12362042 ] David Jencks commented on GERONIMO-1427: I applied the patch, Sendingassemblies/j2ee-jetty-server/project.xml Sendingassemblies/j2ee-jetty-server/src/var/config/config.xml Sendingassemblies/j2ee-tomcat-server/project.xml Sendingassemblies/j2ee-tomcat-server/src/var/config/config.xml Adding configs/axis Adding configs/axis/LICENSE.txt Adding configs/axis/NOTICE.txt Adding configs/axis/maven.xml Adding configs/axis/project.properties Adding configs/axis/project.xml Adding configs/axis/src Sendingconfigs/axis/src/plan/plan.xml Adding configs/axis-deployer Adding configs/axis-deployer/LICENSE.txt Adding configs/axis-deployer/NOTICE.txt Adding configs/axis-deployer/maven.xml Adding configs/axis-deployer/project.properties Adding configs/axis-deployer/project.xml Adding configs/axis-deployer/src Sendingconfigs/axis-deployer/src/plan/plan.xml Sendingconfigs/console-jetty/project.properties Sendingconfigs/console-tomcat/project.properties Sendingconfigs/daytrader-jetty/project.properties Sendingconfigs/daytrader-tomcat/project.properties Sendingconfigs/j2ee-deployer/src/plan/plan.xml Sendingconfigs/j2ee-server/src/plan/plan.xml Sendingconfigs/jetty-deployer/src/plan/plan.xml Sendingconfigs/jmxdebug-jetty/project.properties Sendingconfigs/jmxdebug-tomcat/project.properties Sendingconfigs/jsp-examples-jetty/project.properties Sendingconfigs/jsp-examples-tomcat/project.properties Sendingconfigs/ldap-demo-jetty/project.properties Sendingconfigs/ldap-demo-tomcat/project.properties Adding configs/openejb Adding configs/openejb/LICENSE.txt Adding configs/openejb/NOTICE.txt Adding configs/openejb/maven.xml Adding configs/openejb/project.properties Adding configs/openejb/project.xml Adding configs/openejb/src Sendingconfigs/openejb/src/plan/plan.xml Adding configs/openejb-deployer Adding configs/openejb-deployer/LICENSE.txt Adding configs/openejb-deployer/NOTICE.txt Adding configs/openejb-deployer/maven.xml Adding configs/openejb-deployer/project.properties Adding configs/openejb-deployer/project.xml Adding configs/openejb-deployer/src Sendingconfigs/openejb-deployer/src/plan/plan.xml Sendingconfigs/remote-deploy-jetty/project.properties Sendingconfigs/remote-deploy-tomcat/project.properties Sendingconfigs/servlets-examples-jetty/project.properties Sendingconfigs/servlets-examples-tomcat/project.properties Sendingconfigs/system-database/project.properties Sendingconfigs/system-database/project.xml Sendingconfigs/tomcat-deployer/src/plan/plan.xml Sendingconfigs/welcome-jetty/project.properties Sendingconfigs/welcome-tomcat/project.properties Adding modules/j2ee-builder/src/java/org/apache/geronimo/j2ee/deployment/UnavailableModuleBuilder.java Transmitting file data ... Committed revision 366676. Create a stripped down assembly that includes ActiveMQ, Derby, Jetty/Tomcat and transaction --- Key: GERONIMO-1427 URL: http://issues.apache.org/jira/browse/GERONIMO-1427 Project: Geronimo Type: New Feature Components: general Versions: 1.1 Reporter: Bruce Snyder Attachments: separate-openejb-2.diff -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
