[jira] Created: (GERONIMO-1682) remote deployment fails when server is running on machine with DHCP
remote deployment fails when server is running on machine with DHCP --- Key: GERONIMO-1682 URL: http://issues.apache.org/jira/browse/GERONIMO-1682 Project: Geronimo Type: Bug Components: deployment Versions: 1.0 Environment: Windows 2003 Reporter: Song ZHANG Remote deployment failed when I used IP address of a DHCP machine. C:\deploy --host 9.186.64.66 --verbose deploy hello-1.0.war .. Username: system Password: Uploading 1 file(s) to server Error: Unable to distribute hello-1.0.war: st68rts17h java.net.UnknownHostException: st68rts17h at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:182) at java.net.Socket.connect(Socket.java:478) at java.net.Socket.connect(Socket.java:428) at sun.net.NetworkClient.doConnect(NetworkClient.java:158) at sun.net.www.http.HttpClient.openServer(HttpClient.java:434) at sun.net.www.http.HttpClient.openServer(HttpClient.java:648) at sun.net.www.http.HttpClient.init(HttpClient.java:338) at sun.net.www.http.HttpClient.init(HttpClient.java:299) at sun.net.www.http.HttpClient.New(HttpClient.java:371) at sun.net.www.http.HttpClient.New(HttpClient.java:352) at sun.net.www.http.HttpClient.New(HttpClient.java:347) at sun.net.www.protocol.http.HttpURLConnection.plainConnect(HttpURLConnection.java:562) at sun.net.www.protocol.http.HttpURLConnection.connect(HttpURLConnection.java:539) at org.apache.geronimo.deployment.plugin.remote.RemoteDeployUtil.connectToServer(RemoteDeployUtil.java:117) at org.apache.geronimo.deployment.plugin.remote.RemoteDeployUtil.uploadFilesToServer(RemoteDeployUtil.java:60) at org.apache.geronimo.deployment.plugin.remote.DistributeCommand.massageFileNames(DistributeCommand.java:41) at org.apache.geronimo.deployment.plugin.local.AbstractDeployCommand.doDeploy(AbstractDeployCommand.java:105) at org.apache.geronimo.deployment.plugin.local.DistributeCommand.run(DistributeCommand.java:59) at java.lang.Thread.run(Thread.java:570) 9.186.64.66 is the DHCP ip for remote host st68rts17h. During remote deployment, following steps occur in turn: 1)Local server uses URI supplied from deployer tool (that is 9.186.64.66) to get connector for container on remote machine; 2)Remote machine replies the connectURL to itself, which is using short hostname(that is st68rts17h); 3)Local server uses URL reply from remote machine to upload application archive file. But st68rts17h is not recognized by local server, so the error happens. That's why URI specified in deployer tool, regardless long hostname or IP address, is always converted to short hostname. So the only workaround is to manually add shortname of remote host to hosts file on local machine. After I switched remote machine(running the server) to static IP and changed the machine name to be the same as hostname which is resolvable by DNS, this problem went away. I think the logic of remote deploy need to be enhanced. Simply using URI specified in the command line to connect to remote server runtime(step3 as I mentioned above) should be much more understandable and workable. -- 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: (SM-319) Ability to define several flows and choose them explicitely or based on some requested QoS
[ http://jira.activemq.org/jira//browse/SM-319?page=all ] Guillaume Nodet resolved SM-319: Resolution: Fixed Fix Version: (was: 3.0) 3.0-M1 Author: gnodet Date: Mon Feb 27 07:53:10 2006 New Revision: 381368 URL: http://svn.apache.org/viewcvs?rev=381368view=rev Log: SM-319: multiple flows step 2. Use flow capabilities and exchange QoS to choose a flow Modified: incubator/servicemix/trunk/servicemix-core/src/main/java/org/apache/servicemix/jbi/nmr/flow/AbstractFlow.java incubator/servicemix/trunk/servicemix-core/src/main/java/org/apache/servicemix/jbi/nmr/flow/DefaultFlowChooser.java incubator/servicemix/trunk/servicemix-core/src/main/java/org/apache/servicemix/jbi/nmr/flow/Flow.java incubator/servicemix/trunk/servicemix-core/src/main/java/org/apache/servicemix/jbi/nmr/flow/jca/JCAFlow.java incubator/servicemix/trunk/servicemix-core/src/main/java/org/apache/servicemix/jbi/nmr/flow/jms/JMSFlow.java incubator/servicemix/trunk/servicemix-core/src/main/java/org/apache/servicemix/jbi/nmr/flow/seda/SedaFlow.java incubator/servicemix/trunk/servicemix-core/src/main/java/org/apache/servicemix/jbi/nmr/flow/st/STFlow.java Ability to define several flows and choose them explicitely or based on some requested QoS -- Key: SM-319 URL: http://jira.activemq.org/jira//browse/SM-319 Project: ServiceMix Type: New Feature Components: servicemix-core Reporter: Guillaume Nodet Assignee: Guillaume Nodet Priority: Critical Fix For: 3.0-M1 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.activemq.org/jira//secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
dealing with slow consumers on non-durable topics
Slow consumers can cause issues for a JMS provider. There's some background here: http://docs.codehaus.org/display/ACTIVEMQ/Slow+Consumers For non-durable topics sometimes you don't want slow consumers slowing down your producer; you want to keep publishing at a high a rate as possible for the fast consumers and discard old messages for the slow consumers who can't keep up. I've recently committed a patch that allows you to configure a maximum pending message limit such that slow consumers, when they fall too far behind, will start having their old messages discarded. Its described in gory detail here... http://docs.codehaus.org/display/ACTIVEMQ/Slow+Consumer+Handling Anyone who's sending around messages on non-durable topics and is prepared to discard messages for slow consumers (e.g. for sending around stock prices in finance) should give this feature a try. James --- http://radio.weblogs.com/0112098/
[jira] Updated: (GERONIMO-1675) Add NNTP transport to the javamail package.
[ http://issues.apache.org/jira/browse/GERONIMO-1675?page=all ] Rick McGuire updated GERONIMO-1675: --- Attachment: addr.patch An additional patch needed to allow Transport.send() to function correctly. This is also applied to the javamail-transport module. Add NNTP transport to the javamail package. --- Key: GERONIMO-1675 URL: http://issues.apache.org/jira/browse/GERONIMO-1675 Project: Geronimo Type: New Feature Components: mail Versions: 1.x Reporter: Rick McGuire Attachments: GERONIMO-1675.patch, addr.patch Add the capability of posting messages to NNTP servers using the javamail API. This is a capability that the Sun version does not currently have. -- 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: Build fail
Hi, I am still experiencing this problem, even if we copy the jars into the maven repository (which one the jars should be copied to?). I have been following the *EclipseDeployment* instructions on the wiki, but I'm stuck on the 'new' maven goal. I'm using 'trunk'. Any help? Thanks, Sean Phani Madgula wrote: Hi Alan, I copied the required jars into maven repository and it worked. I find one thing about the AG build. If two persons start building AG at the same time, if both were to fail, they get different errors. If we copy required jars into respository, it works fine. Thx phani On 2/22/06, Alan D. Cabrera [EMAIL PROTECTED] wrote: I think that Jeff and I fixed this. Try updating both Geronimo and OpenEJB. Regards, Alan On 2/22/2006 3:23 AM, Phani Madgula wrote: Hi I am getting this dependency link problem while building the server. How can I resolve it? I created the folder activecluster\activecluster\jars in respository folder and put the jar file activecluster-1.2-20051115174934.jar in that, but failed. multiproject:install-callback: [echo] Running car:install for Configuration for application client deployments 16:31:05,930 ERROR [PackageBuilder] org.apache.geronimo.common.DeploymentException: org.apache.geronimo.kernel.repository.M issingDependencyException: uri activecluster/activecluster/1.2-20051115174934/jar not found in repository org.apache.geronimo.common.DeploymentException: org.apache.geronimo.kernel.repository.MissingDependencyException : uri activ ecluster/activecluster/1.2-20051115174934/jar not found in repository at org.apache.geronimo.deployment.service.ServiceConfigBuilder.getDependencyURI (ServiceConfigBuilder.java:402) at org.apache.geronimo.deployment.service.ServiceConfigBuilder.addDependencies (ServiceConfigBuilder.java:276) at org.apache.geronimo.deployment.service.ServiceConfigBuilder.addDependencies (ServiceConfigBuilder.java :303) at org.apache.geronimo.deployment.service.ServiceConfigBuilder.buildConfiguration (ServiceConfigBuilder.java:204) at org.apache.geronimo.deployment.service.ServiceConfigBuilder.buildConfiguration (ServiceConfigBuilder.java:167) at org.apache.geronimo.deployment.service.ServiceConfigBuilder$$FastClassByCGLIB$$9f173be6.invoke (generated) at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java :53) at org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke( FastMethodInvoker.java:38) at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke( GBeanOperation.java:118) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke (GBeanInstance.java:800) Thx phani
Re: Build fail
2006/3/3, Sean C. McCarthy [EMAIL PROTECTED]: Hi, I am still experiencing this problem, even if we copy the jars into the maven repository (which one the jars should be copied to?). I have been following the *EclipseDeployment* instructions on the wiki, but I'm stuck on the 'new' maven goal. The 'new' maven goal - it rings a bell of mine ;) Could you elaborate more about your build problems? What error are you getting and such. Sean Jacek -- Jacek Laskowski http://www.laskowski.org.pl
Re: JIRA and svn changes - how to tie it up?
2006/3/3, John Sisson [EMAIL PROTECTED]: In your svn commit log message just needs to include the JIRA issue identifier, but hopefully followed by a comment describing the change for those looking at svn history. For example: GERONIMO-1605 - Display PID of started process when using geronimo.sh start or startup.sh (merged from trunk) ... If everyone did this it would make things much easier seeing the progress of work for an issue. Thanks John! Will use it on a regular basis. Gotta see if there're some patches left to commit... John Jacek -- Jacek Laskowski http://www.laskowski.org.pl
[jira] Closed: (GERONIMO-1669) javamail Transport.send() is not issuing connect() on the transport before sending the message.
[ http://issues.apache.org/jira/browse/GERONIMO-1669?page=all ]
Jacek Laskowski closed GERONIMO-1669:
-
Verified by Vamsavardhana Reddy. Thanks!
javamail Transport.send() is not issuing connect() on the transport before
sending the message.
---
Key: GERONIMO-1669
URL: http://issues.apache.org/jira/browse/GERONIMO-1669
Project: Geronimo
Type: Bug
Components: mail
Versions: 1.x
Reporter: Rick McGuire
Assignee: Jacek Laskowski
Fix For: 1.1
Attachments: GERONIMO-1669.patch
This was reported on the geronimo user list (problem report attached below).
The error is occuring because the Transport.send() code is failing to
surround the sendMessage() call with connect() and close() calls on the
transport, resulting in the connection failure. Additionally, this code is
not properly merging send failures for multiple transports into a single
SendFailedException with proper reporting of which addresses the message was
not sent to.
Hi Alex,
I am trying to send mail from a servlet. Here is my geronimo-web.xml:
?xml version=1.0 encoding=UTF-8?
web-app xmlns=http://geronimo.apache.org/xml/ns/j2ee/web-1.1;
xmlns:nam=http://geronimo.apache.org/xml/ns/naming-1.1;
xmlns:sec=http://geronimo.apache.org/xml/ns/security-1.1;
xmlns:sys=http://geronimo.apache.org/xml/ns/deployment-1.1;
configId=MailWebApp/MailWebApp
dependency
urigeronimo/geronimo-mail/1.2-SNAPSHOT/uri
/dependency
dependency
urigeronimo/geronimo-javamail-transport/1.2-SNAPSHOT/uri
/dependency
context-root/MailWebApp/context-root
context-priority-classloaderfalse/context-priority-classloader
resource-ref
ref-namemail/MailSession/ref-name
target-name
geronimo.server:J2EEApplication=null,J2EEModule=MailWebApp/MailWebApp,J2EEServer=geronimo,j2eeType=JavaMailResource,name=MailSession
/target-name
/resource-ref
gbean name=MailSession class=org.apache.geronimo.mail.MailGBean
attribute name=transportProtocolsmtp/attribute
attribute name=host9.182.150.56/attribute
attribute name=useDefaultfalse/attribute
attribute name=properties
mail.debug=true
[EMAIL PROTECTED]
mail.smtp.port=25/attribute
/gbean
/web-app
Here are the imports and the doGet() method in my servlet.
import javax.mail.Session;
import javax.mail.Transport;
import javax.mail.Message.RecipientType;
import javax.mail.internet.InternetAddress;
import javax.mail.internet.MimeMessage;
protected void doGet(HttpServletRequest request, HttpServletResponse
response) throws ServletException, IOException {
response.setContentType(text/plain);
PrintWriter out = response.getWriter();
try {
InitialContext ic = new InitialContext();
Session mailSession = (Session)
ic.lookup(java:comp/env/mail/MailSession);
mailSession.setDebug(true);
mailSession.setDebugOut(System.err);
out.println(session = +mailSession);
MimeMessage msg = new MimeMessage(mailSession);
msg.setRecipients(RecipientType.TO, new InternetAddress[] {new
InternetAddress([EMAIL PROTECTED])});
msg.setSubject(Mail sent by MailerServlet);
msg.setText(Hello);
msg.setFrom(InternetAddress.getLocalAddress(mailSession));
Transport.send(msg);
} catch (Exception e) {
e.printStackTrace(out);
}
}
When I access the servlet, I am getting the following Exception.
java.lang.IllegalStateException: Not connected
at
org.apache.geronimo.javamail.transport.smtp.SMTPTransport.sendMessage(SMTPTransport.java:356)
at javax.mail.Transport.send(Transport.java:80)
at javax.mail.Transport.send
(Transport.java:46)
at mailwebapp.MailerServlet.doGet(MailerServlet.java:64)
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.geronimo.tomcat.valve.DefaultSubjectValve.invoke(DefaultSubjectValve.java:46)
at
Re: Build fail
Hi Jacek, The exception is thrown while executing the 'new' goal, but I have narrowed it to m:geronimo:configs call from new. Executing the goal gives a: 10:42:01,278 ERROR [PackageBuilder] org.apache.geronimo.common.DeploymentException: org.apache.geronimo.kernel.repository.MissingDependencyException: uri activecluster/activecluster/1.2-20051115174934/jar not found in repository org.apache.geronimo.common.DeploymentException: org.apache.geronimo.kernel.repository.MissingDependencyException: uri activecluster/activecluster/1.2-20051115174934/jar not found in repository at org.apache.geronimo.deployment.service.ServiceConfigBuilder.getDependencyURI(ServiceConfigBuilder.java:402) at org.apache.geronimo.deployment.service.ServiceConfigBuilder.addDependencies(ServiceConfigBuilder.java:276) at org.apache.geronimo.deployment.service.ServiceConfigBuilder.addDependencies(ServiceConfigBuilder.java:303) at org.apache.geronimo.deployment.service.ServiceConfigBuilder.buildConfiguration(ServiceConfigBuilder.java:204) at org.apache.geronimo.deployment.service.ServiceConfigBuilder.buildConfiguration(ServiceConfigBuilder.java:167) at org.apache.geronimo.deployment.service.ServiceConfigBuilder$$FastClassByCGLIB$$9f173be6.invoke(generated) at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53) ... ... ... Caused by: org.apache.geronimo.kernel.repository.MissingDependencyException: uri activecluster/activecluster/1.2-20051115174934/jar not found in repository ... 68 more The maven goals I made: * m:fresh-checkout * new I tried updating and copying the jars into the maven local repository, as Alan Cabrera pointed out, but I still get the exception. I have tried to build it from scratch too, but I get the same error. Thanks, Sean Jacek Laskowski wrote: 2006/3/3, Sean C. McCarthy [EMAIL PROTECTED]: Hi, I am still experiencing this problem, even if we copy the jars into the maven repository (which one the jars should be copied to?). I have been following the *EclipseDeployment* instructions on the wiki, but I'm stuck on the 'new' maven goal. The 'new' maven goal - it rings a bell of mine ;) Could you elaborate more about your build problems? What error are you getting and such. Sean Jacek -- Jacek Laskowski http://www.laskowski.org.pl .
[jira] Closed: week of 03-03-2006
Project: Apache Geronimo Status: Resolved, Closed (20 items) Updated In Last: Week (7 days) ** New Feature * [GERONIMO-1478] Donation of XBean source ** Bug * [GERONIMO-1669] javamail Transport.send() is not issuing connect() on the transport before sending the message. * [GERONIMO-1670] SMTPTransport not throwing correct exception for message send failures. * [GERONIMO-1671] InternetAddress.getLocalAddress() does not properly implement the local address resolution path. * [GERONIMO-1500] Geronimo startup fails after adding an HTTPS Connector * [GERONIMO-1661] Version class does not implement equals and hashCode * [GERONIMO-1183] Console/Tomcat: Add/Edit Jetty HTTPS Connector page does not provide key password field * [GERONIMO-1490] setjavaenv.bat is not called by deploy.bat * [GERONIMO-1612] Remove -Djava.endorsed.dirs=$JAVA_ENDORSED_DIRS from commands in geronimo.sh * [GERONIMO-1610] deploy.bat does not honour GERONIMO_BATCH_ECHO and GERONIMO_BATCH_PAUSE environment variables * [GERONIMO-1609] Fix typo in error message in geronimo.bat - cannot find ...setclasspath.bat should read cannot find ...setjavaenv.bat * [GERONIMO-1604] Output from deploy.sh/bat is inconsistent with other scripts - does not output info on environment variable settings (e.g. JAVA_HOME) * [GERONIMO-1603] shutdown.bat does not set ERRORLEVEL and does not honour GERONIMO_BATCH_ECHO and GERONIMO_BATCH_PAUSE environment variables * [GERONIMO-1649] Invalid deployment descriptor error when deploying an EJB 2.0 MDB ** Improvement * [GERONIMO-1317] Rename the new goals to more meaningful names with additional build properties * [GERONIMO-1651] Complete implementation of javamail MimeMessage and MimeUtil classes. * [GERONIMO-1608] Improve Geronimo script documentation * [GERONIMO-1607] Allow user to specify arguments to be used on the Windows START command issued by geronimo.bat * [GERONIMO-1606] Display message indicating Geronimo is being started in another window when started with geronimo.bat start or startup.bat * [GERONIMO-1605] Display PID of started process when using geronimo.sh start or startup.sh
[jira] Created: (GERONIMO-1683) Web app context-root should trim whitespace
Web app context-root should trim whitespace --- Key: GERONIMO-1683 URL: http://issues.apache.org/jira/browse/GERONIMO-1683 Project: Geronimo Type: Bug Components: web Versions: 1.0 Reporter: Aaron Mulder Fix For: 1.1, 1.0.1 If you have an element like this: context-root /something /context-root Then the whitespace is included in the context root -- it becomes return space space /something instead of just /something. We should trim the whitespace. -- 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-1678) Interceptor module added to m2
[ http://issues.apache.org/jira/browse/GERONIMO-1678?page=all ] Jacek Laskowski updated GERONIMO-1678: -- Summary: Interceptor module added to m2 (was: Interceptor module added to m1, needs same for m2) Description: Environment: Interceptor module added to m2 -- Key: GERONIMO-1678 URL: http://issues.apache.org/jira/browse/GERONIMO-1678 Project: Geronimo Type: Sub-task Reporter: Henri Yandell Attachments: GERONIMO-1678.patch -- 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-1678) Interceptor module added to m2
[ http://issues.apache.org/jira/browse/GERONIMO-1678?page=all ] Jacek Laskowski resolved GERONIMO-1678: --- Fix Version: 1.x Resolution: Fixed Assign To: Jacek Laskowski $ svn ci . Sendingmodules/interceptor/pom.xml Sendingmodules/naming/pom.xml Sendingmodules/webservices/pom.xml Sendingpom.xml Transmitting file data Committed revision 382793. Thanks Henri! Interceptor module added to m2 -- Key: GERONIMO-1678 URL: http://issues.apache.org/jira/browse/GERONIMO-1678 Project: Geronimo Type: Sub-task Reporter: Henri Yandell Assignee: Jacek Laskowski Fix For: 1.x Attachments: GERONIMO-1678.patch -- 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] Created: (GERONIMO-1684) server does not start if openejb-jar.xml activation-config had whitespace in values
server does not start if openejb-jar.xml activation-config had whitespace in values --- Key: GERONIMO-1684 URL: http://issues.apache.org/jira/browse/GERONIMO-1684 Project: Geronimo Type: Bug Components: OpenEJB Versions: 1.0 Reporter: Aaron Mulder Priority: Blocker Fix For: 1.1, 1.0.1 Deployed an EAR with an EJB JAR with a MDB. The activation-config property names had whitespace around them: activation-config-property-name SomeValue /activation-config-property-name The application deployed successfully. However, Geronimo was hosed. During startup it complained that SomeValue was an invalid GBean property, or something along those lines. There appear to be 2 bugs here: 1) Whitespace should be stripped from activation config property names (and values, I expect) 2) When generating the ActivationSpec GBean, we should validate that every property exists on the class (and if possible, confirm that the requested value can actually be set). It's critical to raise a deployment exception rather than deploy correctly and barf on every startup. -- 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-1677) geronimo-dependency-plugin deletion
[ http://issues.apache.org/jira/browse/GERONIMO-1677?page=comments#action_12368711 ] Anita Kulshreshtha commented on GERONIMO-1677: -- In M2 builds dependencies.dependency.version property is made available. Please see tomcat pom.xml (G-1645). Adding version tag to g-webservice jar seems to be sufficient. Right now g-service.xml is not added to the jar. If we run into problems at assembly time, we might have to generate it. I think we may not need it. geronimo-dependency-plugin deletion --- Key: GERONIMO-1677 URL: http://issues.apache.org/jira/browse/GERONIMO-1677 Project: Geronimo Type: Sub-task Reporter: Prasad Kashyap -- 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: Migrating to maven 2
inline... --- Henri Yandell [EMAIL PROTECTED] wrote: On 3/2/06, Prasad Kashyap [EMAIL PROTECTED] wrote: Hmm.. somewhere up in this thread, someone had mentioned that we should do this as a bottoms-up approach where we migrate the ones without any deps (call it base modules) first and then work up the chain. That will impose a sequential order on the migration effort and may also possibly hold it up. If we are to randomly attack it, then maybe we have to use the maven-install-plugin to install the required m1 dep jars in m2 local repo. But atleast now, more and more modules can be converted and the code checked in. It has worked great so far! We have most of the base modules done. If we used the latter approach, then we'll have to wait till the base modules have migrated before turning on the top down build. Currently, the maven.xml builds only the kernel module in the m2 format anyways. What do you think ? Now we are at a stage where people can pick their favorite module and convert it! And if they find a few missing jars, just copy them from .maven repo. Writing another plugin may not be worth the effort at this stage. Thanks Anita Yes :) It seems like this is what's happening anyway? It'd be hard to do it bottom down unless it was all happening in one person's head. So I've leapt into -axis, simply because Axis is a project I'm interested in so why not :) This leads me to looking at webservices which seems to be missing interceptor at the moment, so then I end up in there. Eventually I'll be sending in patches for the base level stuff, and then moving back to axis. We need to get something automated setup - the interceptor problem in webservices is because of on-going development, yet we have it marked as a Green-good on the wiki page. Anyone know if there's a way to get Maven to dump the transitive build order from the project.xmls? That would indicate the order to fix in I think. Hen __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Help! Security Module
Hi, I am migrating security module to M2 (rev 382374). Some tests are failing. These tests pass with M1 build. :--- Battery: org.apache.geronimo.security.jaas.LoginKerberosTest --- Tests run: 1, Failures: 0, Errors: 1, Time elapsed: 0.437 sec testLogin(org.apache.geronimo.security.jaas.LoginKerberosTest) Time elapsed: 0.406 sec ERROR! [ stdout ] --- [ stderr ] --- [ stacktrace ] --- java.lang.SecurityException: Unable to locate a login configuration at com.sun.security.auth.login.ConfigFile.init(ConfigFile.java:97) at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) at ... The login.config in m1 build is defined by project.properties as : maven.junit.jvmargs=-Djava.security.auth.login.config=src/test-data/data/login.config I have set this property in pom.xml (attached). What is missing here? Thanks Anita __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com --- Battery: org.apache.geronimo.security.jaas.LoginKerberosTest --- Tests run: 1, Failures: 0, Errors: 1, Time elapsed: 0.437 sec testLogin(org.apache.geronimo.security.jaas.LoginKerberosTest) Time elapsed: 0.406 sec ERROR! [ stdout ] --- [ stderr ] --- [ stacktrace ] --- java.lang.SecurityException: Unable to locate a login configuration at com.sun.security.auth.login.ConfigFile.init(ConfigFile.java:97) at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27) at java.lang.reflect.Constructor.newInstance(Constructor.java:274) at java.lang.Class.newInstance0(Class.java:308) at java.lang.Class.newInstance(Class.java:261) at javax.security.auth.login.Configuration$3.run(Configuration.java:221) at java.security.AccessController.doPrivileged(Native Method) at javax.security.auth.login.Configuration.getConfiguration(Configuration.java:215) at javax.security.auth.login.LoginContext$1.run(LoginContext.java:170) at java.security.AccessController.doPrivileged(Native Method) at javax.security.auth.login.LoginContext.init(LoginContext.java:167) at javax.security.auth.login.LoginContext.init(LoginContext.java:292) at org.apache.geronimo.security.jaas.LoginKerberosTest.testLogin(LoginKerberosTest.java:87) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at junit.framework.TestCase.runTest(TestCase.java:154) at junit.framework.TestCase.runBare(TestCase.java:127) at junit.framework.TestResult$1.protect(TestResult.java:106) at junit.framework.TestResult.runProtected(TestResult.java:124) at junit.framework.TestResult.run(TestResult.java:109) at junit.framework.TestCase.run(TestCase.java:118) at junit.framework.TestSuite.runTest(TestSuite.java:208) at junit.framework.TestSuite.run(TestSuite.java:203) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at org.apache.maven.surefire.battery.JUnitBattery.executeJUnit(JUnitBattery.java:242) at org.apache.maven.surefire.battery.JUnitBattery.execute(JUnitBattery.java:216) at org.apache.maven.surefire.Surefire.executeBattery(Surefire.java:215) at org.apache.maven.surefire.Surefire.run(Surefire.java:163) at org.apache.maven.surefire.Surefire.run(Surefire.java:87) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at
Re: Help! Security Module
Never mind... I just saw 2 delete dir lines! no mkdir :( Thanks Anita --- anita kulshreshtha [EMAIL PROTECTED] wrote: Hi, I am migrating security module to M2 (rev 382374). Some tests are failing. These tests pass with M1 build. :--- Battery: org.apache.geronimo.security.jaas.LoginKerberosTest --- Tests run: 1, Failures: 0, Errors: 1, Time elapsed: 0.437 sec testLogin(org.apache.geronimo.security.jaas.LoginKerberosTest) Time elapsed: 0.406 sec ERROR! [ stdout ] --- [ stderr ] --- [ stacktrace ] --- java.lang.SecurityException: Unable to locate a login configuration at com.sun.security.auth.login.ConfigFile.init(ConfigFile.java:97) at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) at ... The login.config in m1 build is defined by project.properties as : maven.junit.jvmargs=-Djava.security.auth.login.config=src/test-data/data/login.config I have set this property in pom.xml (attached). What is missing here? Thanks Anita __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com --- Battery: org.apache.geronimo.security.jaas.LoginKerberosTest --- Tests run: 1, Failures: 0, Errors: 1, Time elapsed: 0.437 sec testLogin(org.apache.geronimo.security.jaas.LoginKerberosTest) Time elapsed: 0.406 sec ERROR! [ stdout ] --- [ stderr ] --- [ stacktrace ] --- java.lang.SecurityException: Unable to locate a login configuration at com.sun.security.auth.login.ConfigFile.init(ConfigFile.java:97) at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27) at java.lang.reflect.Constructor.newInstance(Constructor.java:274) at java.lang.Class.newInstance0(Class.java:308) at java.lang.Class.newInstance(Class.java:261) at javax.security.auth.login.Configuration$3.run(Configuration.java:221) at java.security.AccessController.doPrivileged(Native Method) at javax.security.auth.login.Configuration.getConfiguration(Configuration.java:215) at javax.security.auth.login.LoginContext$1.run(LoginContext.java:170) at java.security.AccessController.doPrivileged(Native Method) at javax.security.auth.login.LoginContext.init(LoginContext.java:167) at javax.security.auth.login.LoginContext.init(LoginContext.java:292) at org.apache.geronimo.security.jaas.LoginKerberosTest.testLogin(LoginKerberosTest.java:87) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at junit.framework.TestCase.runTest(TestCase.java:154) at junit.framework.TestCase.runBare(TestCase.java:127) at junit.framework.TestResult$1.protect(TestResult.java:106) at junit.framework.TestResult.runProtected(TestResult.java:124) at junit.framework.TestResult.run(TestResult.java:109) at junit.framework.TestCase.run(TestCase.java:118) at junit.framework.TestSuite.runTest(TestSuite.java:208) at junit.framework.TestSuite.run(TestSuite.java:203) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at org.apache.maven.surefire.battery.JUnitBattery.executeJUnit(JUnitBattery.java:242) at org.apache.maven.surefire.battery.JUnitBattery.execute(JUnitBattery.java:216) at org.apache.maven.surefire.Surefire.executeBattery(Surefire.java:215) at org.apache.maven.surefire.Surefire.run(Surefire.java:163) at
Re: Session API, was: heads up: initial contribution of a client API to session state management for OpenEJB, ServiceMix, Lingo and Tuscany
Dain Sundstrom wrote: Object value = session.getState(web:/context- + name); Ok I get it now. Don't have a deep - hard to replicate - structure. Have a flat structure, but with a scoped name space! I think this approach solves a lot of issues and probably reduces the need for extra API. For example, perhaps we could communicate maxIdleTimes via naming conventions rather than API: session.putState(session:maxIdleTimeMs,new Integer(6)); I still don't know if this approach can help with event notification, but I defer that until I have a quasi-working session manager against the API. cheers
Re: Session Policy was: heads up: initial contribution of a client API to session state management for OpenEJB, ServiceMix, Lingo and Tuscany
gentlemen, not a committer here, but wanted to share some thoughts.
in my opinion, the Session API should not have to know about clustering
or session replication, nor should it need to worry about location.
the clustering API should take care of all of that.
the solution that we plan to implement for Tomcat is fairly straight
forward. Let me see if I can give an idea of how the API shouldn't need
to worry, its a little lengthy, but it shows that the Session and the
SessionManager need to know zero about clustering or session locations.
(this is only one solution, and other solutions should demonstrate the
same point, SessionAPI need to know nothing about clustering or session
locations)
1. Requirements to be implemented by the Session.java API
bool isDirty - (has the session changed in this request)
bool isDiffable - is the session able provide a diff
byte[] getSessionData() - returns the whole session
byte[] getSessionDiff() - optional, see isDiffable, resets the diff data
void setSessionDiff(byte[] diff) - optional, see isDiffable, apply
changes from another node
2. Requirements to be implemented by the SessionManager.java API
void setSessionMap(HashMap map) - makes the map implementation pluggable
3. And the key to this, is that we will have an implementation of a
LazyReplicatedHashMap
The key object in this map is the session Id.
The map entry object is an object that looks like this
ReplicatedEntry {
string id;//sessionid
bool isPrimary; //does this node hold the data
bool isBackup; //does this node hold backup data
Session session; //not null values for primary and backup nodes
Member primary; //information about the primary node
Member backup; //information about the backup node
}
The LazyReplicatedHashMap overrides get(key) and put(id,session)
So all the nodes will have the a sessionId,ReplicatedEntry combinations
in their session map. But only two nodes will have the actual data.
This solution is for sticky LB only, but when failover happens, the LB
can pick any node as each node knows where to get the data.
The newly selected node, will keep the backup node or select a new one,
and do a publish to the entire cluster of the locations.
As you can see, all-to-all communications only happens when a Session is
(created|destroyed|failover). Other than that it is primary-to-backup
communication only, and this can be in terms of diffs or entire sessions
using the isDirty or getDiff. This is triggered either by an interceptor
at the end of each request or by a batch process for less network jitter
but less accuracy (but adequate) for fail over.
As you can see, access time is not relevant here, nor does the Session
API even know about clustering.
In tomcat we have separated out group communication into a separate
module, we are implementing the LazyReplicatedHashMap right now just for
this purpose.
positive thoughts, criticism and bashing are all welcome :)
Filip
Re: Help! Security Module
That did not help. I am loading all the properties defined in log4j.configuration via ant property file=log4j.properties/ Do I need to set the property log4j.configuration? to file:log4j.properties? Maven/ant does not like :. Thanks Anita --- anita kulshreshtha [EMAIL PROTECTED] wrote: Never mind... I just saw 2 delete dir lines! no mkdir :( Thanks Anita --- anita kulshreshtha [EMAIL PROTECTED] wrote: Hi, I am migrating security module to M2 (rev 382374). Some tests are failing. These tests pass with M1 build. :--- Battery: org.apache.geronimo.security.jaas.LoginKerberosTest --- Tests run: 1, Failures: 0, Errors: 1, Time elapsed: 0.437 sec testLogin(org.apache.geronimo.security.jaas.LoginKerberosTest) Time elapsed: 0.406 sec ERROR! [ stdout ] --- [ stderr ] --- [ stacktrace ] --- java.lang.SecurityException: Unable to locate a login configuration at com.sun.security.auth.login.ConfigFile.init(ConfigFile.java:97) at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) at ... The login.config in m1 build is defined by project.properties as : maven.junit.jvmargs=-Djava.security.auth.login.config=src/test-data/data/login.config I have set this property in pom.xml (attached). What is missing here? Thanks Anita __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com --- Battery: org.apache.geronimo.security.jaas.LoginKerberosTest --- Tests run: 1, Failures: 0, Errors: 1, Time elapsed: 0.437 sec testLogin(org.apache.geronimo.security.jaas.LoginKerberosTest) Time elapsed: 0.406 sec ERROR! [ stdout ] --- [ stderr ] --- [ stacktrace ] --- java.lang.SecurityException: Unable to locate a login configuration at com.sun.security.auth.login.ConfigFile.init(ConfigFile.java:97) at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27) at java.lang.reflect.Constructor.newInstance(Constructor.java:274) at java.lang.Class.newInstance0(Class.java:308) at java.lang.Class.newInstance(Class.java:261) at javax.security.auth.login.Configuration$3.run(Configuration.java:221) at java.security.AccessController.doPrivileged(Native Method) at javax.security.auth.login.Configuration.getConfiguration(Configuration.java:215) at javax.security.auth.login.LoginContext$1.run(LoginContext.java:170) at java.security.AccessController.doPrivileged(Native Method) at javax.security.auth.login.LoginContext.init(LoginContext.java:167) at javax.security.auth.login.LoginContext.init(LoginContext.java:292) at org.apache.geronimo.security.jaas.LoginKerberosTest.testLogin(LoginKerberosTest.java:87) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at junit.framework.TestCase.runTest(TestCase.java:154) at junit.framework.TestCase.runBare(TestCase.java:127) at junit.framework.TestResult$1.protect(TestResult.java:106) at junit.framework.TestResult.runProtected(TestResult.java:124) at junit.framework.TestResult.run(TestResult.java:109) at junit.framework.TestCase.run(TestCase.java:118) at junit.framework.TestSuite.runTest(TestSuite.java:208) at junit.framework.TestSuite.run(TestSuite.java:203) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
Re: Class DestinationView
On 2 Mar 2006, at 21:28, Dhawan, Vikram ((LNG-DAY)) wrote: Can we make Class DestinationView as MBean. By putting it into the MBean hierarchy and creating an MBean Interface for it. Have a surf around that package - its full of MBean interfaces and implementations. We have 2 derived classes, QueueView and TopicView which are both MBeans - DestinationView is just a useful base class. And if we do that can we Manage messages in a Queue in the ActiveMQ using browse calls from the agent. See the API for QueueViewMBean :) Those methods are all implemented currently James --- http://radio.weblogs.com/0112098/
Re: Patch: C++ command generation scripts
On 2 Mar 2006, at 07:29, Mats Forslöf wrote: Oops, didn't work this time either :), uploaded to http:// jira.activemq.org/jira/browse/AMQ-603. Patch applied - many thanks Mats! Regards, Mats -Original Message- From: Mats Forslöf [mailto:[EMAIL PROTECTED] Sent: den 2 mars 2006 08:20 To: activemq-dev@geronimo.apache.org Subject: Patch: C++ command generation scripts I have tweaked the C++ command generation scripts a bit to make them generate more precise types and includes, see attached files. Regards, Mats James --- http://radio.weblogs.com/0112098/
RE: Class DestinationView
Hey James, I made another posting this morning http://forums.activemq.org/posts/list/451.page This posting is after I created a JMX client and ran into a confusing situation. My same client code also attached there. Thanks! Vik -Original Message- From: James Strachan [mailto:[EMAIL PROTECTED] Sent: Friday, March 03, 2006 11:27 AM To: activemq-dev@geronimo.apache.org Subject: Re: Class DestinationView On 2 Mar 2006, at 21:28, Dhawan, Vikram ((LNG-DAY)) wrote: Can we make Class DestinationView as MBean. By putting it into the MBean hierarchy and creating an MBean Interface for it. Have a surf around that package - its full of MBean interfaces and implementations. We have 2 derived classes, QueueView and TopicView which are both MBeans - DestinationView is just a useful base class. And if we do that can we Manage messages in a Queue in the ActiveMQ using browse calls from the agent. See the API for QueueViewMBean :) Those methods are all implemented currently James --- http://radio.weblogs.com/0112098/
[jira] Updated: (GERONIMO-1613) Eliminate unncessary dependencies to reduce assemnbly footprint size
[ http://issues.apache.org/jira/browse/GERONIMO-1613?page=all ] Joe Bohn updated GERONIMO-1613: --- Attachment: 1613_RemoveDeps3.patch This patch includes the previous patches and removes the uber-spec jar as well. This should have resulted in an additional savings of nearly 1.2 meg additional ... but unfortunately it doesn't. I had to add in several individual spec jars that were not included earlier. In addition to this there was a change (hopefully temporary) to add the corba spec as a dependency in rmi-naming which increased the image size by 640K.The net result is that we only reduce the image from 16.4 to 16.3 at the moment (but without this change it actually has grown). Eliminate unncessary dependencies to reduce assemnbly footprint size Key: GERONIMO-1613 URL: http://issues.apache.org/jira/browse/GERONIMO-1613 Project: Geronimo Type: Improvement Components: general Versions: 1.1 Environment: all Reporter: Joe Bohn Assignee: David Jencks Fix For: 1.1 Attachments: 1613_RemoveDeps3.patch, RemoveDeps.patch, RemoveDeps2.1.patch, RemoveDeps2.2.patch, RemoveDeps2.3.patch, RemoveDeps2.patch Clean up assembly project.xml and eliminate some unnecessary dependencies in various modules and configs. This will reduce the footprint size (with special attention to the minimal-tomcat-assembly. The patch contains the following: - clean up minimal-tomcat-server\project.xml to remove commented out sections - clean up web-jms-tomcat-server\project.xml to remove commented out sections - remove dependencies from config\j2ee_server on xstream, jaxr-api, and geronimo-derby - remove dependencies from config\j2ee_deployer on geronimo-client-builder - remove dependencies from module\tomcat on activecluster, wadi-core, and wadi-tomcat55 There are still more dependencies that should be removed but this is a start. These changes reduce the disk footprint of minimal-tomcat-server from 27 meg to about 21 meg. -- 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
specs and javadoc question
Hi All, I've started getting ready for JSF 1.2 and figured that a good place for the api jar to land is the uber spec project @ G for JavaEE 5. I'm most of the way there for Servlet 2.5 and JSP 2.1 but I was wondering about javadoc. Does anyone know what the rules are regarding javadoc in the spec code? I've just been doing a straight copy/typing of the api and leaving out the javadoc. But looking back at the Servlet 2.4 and JSP 2.0 spec modules all the javadoc is there. I'd like to submit the patch for Servlet 2.5 and JSP 2.1 in the next week or so. If anyone knows the definitive answer (or since we are not lawyers as close to definitive as possible:) I'd love to hear it. Thanks! TTFN, Bill Dudney MyFaces - myfaces.apache.org
littleG (minimal-tomcat-server) status
I just added an updated patch to Geronimo-1613 https://issues.apache.org/jira/browse/GERONIMO-1613 After some painstaking effort, I was finally able to remove the uber-spec dependency from rmi-naming which should have resulted in an additional savings in little-G of nearly 1.2 meg. Unfortunately, I had to add in some individual spec jars that were not previously included and which decreased the savings somewhat. The real disappointment was when I picked up the latest image yesterday to create the patch and noticed Kevan's change to include the CORBA spec in rmi-naming to work around some other problem. This adds back in about 640K. The comment indicates that this is only temporary. How long will it be needed there and is somebody working to remove it? So, after all that the latest patch only takes us from 16.4 to about 16.3 meg ... but we'll drop more when CORBA comes out of rmi-naming. Would it be possible to get this patch committed to trunk before too much more work happens on the maven2 effort? I think that it would benefit the migration and integration if these updated project.xmls were used as the starting point. Joe -- Joe Bohn joe.bohn at earthlink.net He is no fool who gives what he cannot keep, to gain what he cannot lose. -- Jim Elliot
Re: Help! Security Module
Could you the pom file you made so I can sit and stare at the errors too? :) Hen On 3/3/06, anita kulshreshtha [EMAIL PROTECTED] wrote: That did not help. I am loading all the properties defined in log4j.configuration via ant property file=log4j.properties/ Do I need to set the property log4j.configuration? to file:log4j.properties? Maven/ant does not like :. Thanks Anita --- anita kulshreshtha [EMAIL PROTECTED] wrote: Never mind... I just saw 2 delete dir lines! no mkdir :( Thanks Anita --- anita kulshreshtha [EMAIL PROTECTED] wrote: Hi, I am migrating security module to M2 (rev 382374). Some tests are failing. These tests pass with M1 build. :--- Battery: org.apache.geronimo.security.jaas.LoginKerberosTest --- Tests run: 1, Failures: 0, Errors: 1, Time elapsed: 0.437 sec testLogin(org.apache.geronimo.security.jaas.LoginKerberosTest) Time elapsed: 0.406 sec ERROR! [ stdout ] --- [ stderr ] --- [ stacktrace ] --- java.lang.SecurityException: Unable to locate a login configuration at com.sun.security.auth.login.ConfigFile.init(ConfigFile.java:97) at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) at ... The login.config in m1 build is defined by project.properties as : maven.junit.jvmargs=-Djava.security.auth.login.config=src/test-data/data/login.config I have set this property in pom.xml (attached). What is missing here? Thanks Anita __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com --- Battery: org.apache.geronimo.security.jaas.LoginKerberosTest --- Tests run: 1, Failures: 0, Errors: 1, Time elapsed: 0.437 sec testLogin(org.apache.geronimo.security.jaas.LoginKerberosTest) Time elapsed: 0.406 sec ERROR! [ stdout ] --- [ stderr ] --- [ stacktrace ] --- java.lang.SecurityException: Unable to locate a login configuration at com.sun.security.auth.login.ConfigFile.init(ConfigFile.java:97) at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27) at java.lang.reflect.Constructor.newInstance(Constructor.java:274) at java.lang.Class.newInstance0(Class.java:308) at java.lang.Class.newInstance(Class.java:261) at javax.security.auth.login.Configuration$3.run(Configuration.java:221) at java.security.AccessController.doPrivileged(Native Method) at javax.security.auth.login.Configuration.getConfiguration(Configuration.java:215) at javax.security.auth.login.LoginContext$1.run(LoginContext.java:170) at java.security.AccessController.doPrivileged(Native Method) at javax.security.auth.login.LoginContext.init(LoginContext.java:167) at javax.security.auth.login.LoginContext.init(LoginContext.java:292) at org.apache.geronimo.security.jaas.LoginKerberosTest.testLogin(LoginKerberosTest.java:87) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at junit.framework.TestCase.runTest(TestCase.java:154) at junit.framework.TestCase.runBare(TestCase.java:127) at junit.framework.TestResult$1.protect(TestResult.java:106) at junit.framework.TestResult.runProtected(TestResult.java:124) at junit.framework.TestResult.run(TestResult.java:109) at junit.framework.TestCase.run(TestCase.java:118) at
Re: Help! Security Module
*sigh* need sugar. 'mail me the pom file'. Hen On 3/3/06, Henri Yandell [EMAIL PROTECTED] wrote: Could you the pom file you made so I can sit and stare at the errors too? :) Hen On 3/3/06, anita kulshreshtha [EMAIL PROTECTED] wrote: That did not help. I am loading all the properties defined in log4j.configuration via ant property file=log4j.properties/ Do I need to set the property log4j.configuration? to file:log4j.properties? Maven/ant does not like :. Thanks Anita --- anita kulshreshtha [EMAIL PROTECTED] wrote: Never mind... I just saw 2 delete dir lines! no mkdir :( Thanks Anita --- anita kulshreshtha [EMAIL PROTECTED] wrote: Hi, I am migrating security module to M2 (rev 382374). Some tests are failing. These tests pass with M1 build. :--- Battery: org.apache.geronimo.security.jaas.LoginKerberosTest --- Tests run: 1, Failures: 0, Errors: 1, Time elapsed: 0.437 sec testLogin(org.apache.geronimo.security.jaas.LoginKerberosTest) Time elapsed: 0.406 sec ERROR! [ stdout ] --- [ stderr ] --- [ stacktrace ] --- java.lang.SecurityException: Unable to locate a login configuration at com.sun.security.auth.login.ConfigFile.init(ConfigFile.java:97) at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) at ... The login.config in m1 build is defined by project.properties as : maven.junit.jvmargs=-Djava.security.auth.login.config=src/test-data/data/login.config I have set this property in pom.xml (attached). What is missing here? Thanks Anita __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com --- Battery: org.apache.geronimo.security.jaas.LoginKerberosTest --- Tests run: 1, Failures: 0, Errors: 1, Time elapsed: 0.437 sec testLogin(org.apache.geronimo.security.jaas.LoginKerberosTest) Time elapsed: 0.406 sec ERROR! [ stdout ] --- [ stderr ] --- [ stacktrace ] --- java.lang.SecurityException: Unable to locate a login configuration at com.sun.security.auth.login.ConfigFile.init(ConfigFile.java:97) at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27) at java.lang.reflect.Constructor.newInstance(Constructor.java:274) at java.lang.Class.newInstance0(Class.java:308) at java.lang.Class.newInstance(Class.java:261) at javax.security.auth.login.Configuration$3.run(Configuration.java:221) at java.security.AccessController.doPrivileged(Native Method) at javax.security.auth.login.Configuration.getConfiguration(Configuration.java:215) at javax.security.auth.login.LoginContext$1.run(LoginContext.java:170) at java.security.AccessController.doPrivileged(Native Method) at javax.security.auth.login.LoginContext.init(LoginContext.java:167) at javax.security.auth.login.LoginContext.init(LoginContext.java:292) at org.apache.geronimo.security.jaas.LoginKerberosTest.testLogin(LoginKerberosTest.java:87) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at junit.framework.TestCase.runTest(TestCase.java:154) at junit.framework.TestCase.runBare(TestCase.java:127) at
Re: specs and javadoc question
On Mar 3, 2006, at 9:10 AM, Bill Dudney wrote: Hi All, I've started getting ready for JSF 1.2 and figured that a good place for the api jar to land is the uber spec project @ G for JavaEE 5. I'm most of the way there for Servlet 2.5 and JSP 2.1 but I was wondering about javadoc. Does anyone know what the rules are regarding javadoc in the spec code? I've just been doing a straight copy/typing of the api and leaving out the javadoc. But looking back at the Servlet 2.4 and JSP 2.0 spec modules all the javadoc is there. I'd like to submit the patch for Servlet 2.5 and JSP 2.1 in the next week or so. If anyone knows the definitive answer (or since we are not lawyers as close to definitive as possible:) I'd love to hear it. I have not been copying the javadocs into the specs I have worked on. I think that our servlet 2.4 and jsp 2.0 specs are copied from tomcat where they were IIUC donated complete with javadocs by sun. I think leaving out the javadoc is the wisest course. thanks david jencks Thanks! TTFN, Bill Dudney MyFaces - myfaces.apache.org
Re: specs and javadoc question
On Mar 3, 2006, at 9:37 AM, David Jencks wrote: On Mar 3, 2006, at 9:10 AM, Bill Dudney wrote: Hi All, I've started getting ready for JSF 1.2 and figured that a good place for the api jar to land is the uber spec project @ G for JavaEE 5. I'm most of the way there for Servlet 2.5 and JSP 2.1 but I was wondering about javadoc. Does anyone know what the rules are regarding javadoc in the spec code? I've just been doing a straight copy/typing of the api and leaving out the javadoc. But looking back at the Servlet 2.4 and JSP 2.0 spec modules all the javadoc is there. No copying only typing is allowed. I'd like to submit the patch for Servlet 2.5 and JSP 2.1 in the next week or so. If anyone knows the definitive answer (or since we are not lawyers as close to definitive as possible:) I'd love to hear it. I have not been copying the javadocs into the specs I have worked on. I think that our servlet 2.4 and jsp 2.0 specs are copied from tomcat where they were IIUC donated complete with javadocs by sun. I think leaving out the javadoc is the wisest course. Yes, the javadoc comments are owned by Sun. If you would like to write your own *original* javadoc comments, that would be cool, but not necessary. -dain
Re: heads-up: Servlet-2.5 jetty 6 branch?
+1 On Mar 2, 2006, at 2:55 AM, Greg Wilkins wrote: All, I'm tuning back into G after zoning out for a while I'd like to started work on the jetty6 integration to provide servlet 2.5 The goals of the jetty 6 integration will be: + 2.5 servlet API. + annotation support + Simplify integration using Jetty 6 interceptor friendly architecture. + Use geronimo threadpool + Use Session API ( or iteration of that (see comments posted earlier)) as basis of session manager + Experiment with WADI and clustering integration + Better JACC specific security handler (perhaps to be back ported to Jetty) + Potentially use common server socket factories and eventually SSL Engine factories For this I'm going to created a branch geronimo/sandbox/servlet-2.5 and add geronimo-spec-servlet to geronimo/spec/branches/JEE5 I'm going for a full branch: + because I actually want to see how hard it will be to use svn to maintain a parallel dev branch. + I want some stability + I think there will be some moderately global changes that may affect multiple modules. + The branch will be a good place for a 2.5 tomcat module to be developed at the same time. everybody OK with this? I'd like to start this soonish, although I'm tempted to wait for maven2 to be working. cheers
Re: Session API, was: heads up: initial contribution of a client API to session state management for OpenEJB, ServiceMix, Lingo and Tuscany
On 3 Mar 2006, at 14:41, Greg Wilkins wrote: Dain Sundstrom wrote: Object value = session.getState(web:/context- + name); Ok I get it now. Don't have a deep - hard to replicate - structure. Have a flat structure, but with a scoped name space! I think this approach solves a lot of issues and probably reduces the need for extra API. For example, perhaps we could communicate maxIdleTimes via naming conventions rather than API: session.putState(session:maxIdleTimeMs,new Integer(6)); I still don't know if this approach can help with event notification, but I defer that until I have a quasi-working session manager against the API. Agreed. Maybe the WebSession API should have a typesafe API for things that a servlet engine needs to do like the max idle times and the like; then we could use the above as one implementation if we don't like it we could change it later without having to change the Jetty Tomcat integration code. James --- http://radio.weblogs.com/0112098/
Re: Session API, was: heads up: initial contribution of a client API to session state management for OpenEJB, ServiceMix, Lingo and Tuscany
On Mar 3, 2006, at 6:41 AM, Greg Wilkins wrote:
Dain Sundstrom wrote:
Object value = session.getState(web:/context- + name);
Ok I get it now.
Don't have a deep - hard to replicate - structure.
Have a flat structure, but with a scoped name space!
I think this approach solves a lot of issues and probably
reduces the need for extra API.
Cool. We are on the same page... now we just need to determine if it
is the correct page ;)
For example, perhaps we could communicate maxIdleTimes via
naming conventions rather than API:
session.putState(session:maxIdleTimeMs,new Integer(6));
I think that if we are going to have common well understood data like
this, we should just add it directly to the Session interface. In
gernonimo used this kind of encoded string APIs, and it was a big
PITA, as it means we can use IDE tools to figure out who is setting
data.
I still don't know if this approach can help with event notification,
but I defer that until I have a quasi-working session manager against
the API.
My guess is we're going to need to add an event notification system
to the Session APIs. What do you think about just crib off of the
servlet ones. I think we could just smash the three session listener
interfaces into something like this:
public interface SessionListener extends Listener {
void valueBound(SessionEvent event);
void valueUnbound(SessionEvent event);
void attributeAdded(SessionEvent event);
void attributeRemoved(SessionEvent event);
void attributeRemoved(SessionEvent event);
void valueBound(SessionEvent event);
void valueUnbound(SessionEvent event);
void sessionCreated(SessionEvent event)
void sessionDestroyed(SessionEvent event)
}
public class SessionEvent extends Event {
Session getSession();
String getName();
String getValue();
}
We would bind a listener with a method on the Locator:
void addSessionListener(SessionListener listener);
void removeSessionListener(SessionListener listener);
What do you think?
-dain
Re: specs and javadoc question
Hi All, Thanks for the comments. Dain: Yeah its not copying out of the pdf but simply typing, hardly feels like original work though so even though I'm not copying, it sure feels like it. :-) I'll leave the comments out and post a patch after I get one more pass over it (~early next week). TTFN, Bill Dudney MyFaces - myfaces.apache.org On Mar 3, 2006, at 10:43 AM, Dain Sundstrom wrote: On Mar 3, 2006, at 9:37 AM, David Jencks wrote: On Mar 3, 2006, at 9:10 AM, Bill Dudney wrote: Hi All, I've started getting ready for JSF 1.2 and figured that a good place for the api jar to land is the uber spec project @ G for JavaEE 5. I'm most of the way there for Servlet 2.5 and JSP 2.1 but I was wondering about javadoc. Does anyone know what the rules are regarding javadoc in the spec code? I've just been doing a straight copy/typing of the api and leaving out the javadoc. But looking back at the Servlet 2.4 and JSP 2.0 spec modules all the javadoc is there. No copying only typing is allowed. I'd like to submit the patch for Servlet 2.5 and JSP 2.1 in the next week or so. If anyone knows the definitive answer (or since we are not lawyers as close to definitive as possible:) I'd love to hear it. I have not been copying the javadocs into the specs I have worked on. I think that our servlet 2.4 and jsp 2.0 specs are copied from tomcat where they were IIUC donated complete with javadocs by sun. I think leaving out the javadoc is the wisest course. Yes, the javadoc comments are owned by Sun. If you would like to write your own *original* javadoc comments, that would be cool, but not necessary. -dain
Re: heads up: initial contribution of a client API to session state management for OpenEJB, ServiceMix, Lingo and Tuscany
On 28 Feb 2006, at 11:03, Greg Wilkins wrote: Responding to this a bit late Better late than never :) Thanks for the great feedback on the Session API. BTW web based session management was not really considered too much in the design of the API. We tried to come up with the absolute, minimal API possible that was all the container developer (OpenEJB / ServiceMix / Tuscany / Lingo) needed to deal with sessions. The Web tier is much more complex from a session perspective for all the reasons you highlight - so am wondering if it'd be worth coming up with a slightly different 'WebSession' API that has all the stuff you need to wire it into Jetty (and ditto for Tomcat). Then we see what common areas we have. Anyway more on the responses to the other interesting posts in this thread... James --- http://radio.weblogs.com/0112098/
Re: Session Policy was: heads up: initial contribution of a client API to session state management for OpenEJB, ServiceMix, Lingo and Tuscany
On 2 Mar 2006, at 07:55, Greg Wilkins wrote: Dain Sundstrom wrote: Policy == So firstly we need SessionLocatoin.moveto(Server server), I'm confused. Why would we need that? There is an API to pull a session to a local node, but there is no API to push a session to a specific node. The use-case for the later if you have a load balancer that is a bit erratic and may scatter requests around a bit (think mod_jk after it has lost a node). If you have a policy where every node that receives a request pulls the session to it, then the session will expensively bounce around the cluster. Note you can proxy or redirect - you don't have to move it locally Instead you can have a policy where you proxy (or redirect) the request to the node where the session is. This work fine, but at the cost of a proxy. If all or most of the requests are being sent to a specific node, then the session itself should be able to decide to migrate to that node: I've been receiving most of my requests via node 7, so I think I'll move there. Thus we need a moveTo. I think a moveTo will also be useful for implementing shutdown policies, where you want to gently take a node out of a cluster. The policy should be able to be written independently of impl. I don't think the non-web world needs it that much as there typically isn't a crazy load balancer in the way smoking crack and doing wacky stuff. Both moveHere and moveThere could very well be valid decisions that either the container or some Policy class can choose to do - I'd just like to explore the use case a little further to check there is a need. BTW I don't think its a huge biggie as moveHere and moveThere are kinda similar. Normally when a request hits a node the session is here or its overThere. So the use case you are suggesting is, the session is locally here but the node decides to move the session overThere - then it must redirect/proxy the current request to overThere right? It probably wants to do that to give the load balancer a clue of where the session really is; in which case the redirected/proxied request will have the session locally - then it can decide if its gonna move the session or not. The complication of the node who owns a session deciding where to send it is that she doesn't know what the other nodes are doing per se; which is why its easier to do the moves from the other way around. i.e. the node thats getting hit a lot decides to grab the session. A node that rarely gets hit doesn't know which node is really getting hammered per se - so why not proxy/ redirect and let that guy decide? Like I say - no biggie either way - just wanting to clarify if we really need this. but more importantly, when we are redirecting or proxying requests, it would be good to be able to attach impl specific meta data to those requests. So the HTTP tier needs to be able to ask a SessionLocation for an opaque blob of meta data associated with a request and to be able to set that meta data when it recieves it. Huh? Redirect would be dependent on the web container so this would be a detail for the web container to deal with. The session apis, only says, the session data is on server x. How the web container gets the request to server x is it's problem. I totally agree that it is the web-servers problem to move a request from one node to the other node. But I think there will be a need for some opaque impl specific data to be sent with that request - so the impl can coordinate it's actions. At the very least, it would be good for a request arriving on node x to be able to carry the opaque message: I came from node z. It is easy for the web container to add such messages, but there is no way they can be passed to the policy impl. Yeah; when proxying/redirecting we need some way to pass in some information so that the Policy/container can make better session- movement decisions. Though I think thats a nice to have - a real simple algorithm (like the one in SVN) could well work for lots of folks http://svn.apache.org/repos/asf/geronimo/trunk/modules/session/src/ java/org/apache/geronimo/session/remote/util/ DefaultRemoteSessionStrategy.java James --- http://radio.weblogs.com/0112098/
Re: Session API, was: heads up: initial contribution of a client API to session state management for OpenEJB, ServiceMix, Lingo and Tuscany
On 3 Mar 2006, at 18:00, Dain Sundstrom wrote:
On Mar 3, 2006, at 6:41 AM, Greg Wilkins wrote:
Dain Sundstrom wrote:
I still don't know if this approach can help with event notification,
but I defer that until I have a quasi-working session manager against
the API.
My guess is we're going to need to add an event notification system
to the Session APIs. What do you think about just crib off of the
servlet ones. I think we could just smash the three session
listener interfaces into something like this:
public interface SessionListener extends Listener {
void valueBound(SessionEvent event);
void valueUnbound(SessionEvent event);
void attributeAdded(SessionEvent event);
void attributeRemoved(SessionEvent event);
void attributeRemoved(SessionEvent event);
void valueBound(SessionEvent event);
void valueUnbound(SessionEvent event);
void sessionCreated(SessionEvent event)
void sessionDestroyed(SessionEvent event)
}
public class SessionEvent extends Event {
Session getSession();
String getName();
String getValue();
}
We would bind a listener with a method on the Locator:
void addSessionListener(SessionListener listener);
void removeSessionListener(SessionListener listener);
What do you think?
Looks good. We can refactor later as needed
James
---
http://radio.weblogs.com/0112098/
Re: heads up: initial contribution of a client API to session state management for OpenEJB, ServiceMix, Lingo and Tuscany
On 1 Mar 2006, at 19:56, Dain Sundstrom wrote:
Actually, the more I think about it, you are bringing up the need
for another API for request routing. This would be something that
can make a decision about what to do with a request and could
optionally work with out session API. I'm thinking of something
that captures the concept of a request and a decision. Off the top
of my head...
public interface Request {
Object getHeader();
String getSessionId();
String getTarget();
}
public interface Router {
public RouterPolicy route(Request request);
}
RouterPolicy is an enumeration containing local, move session,
proxy, redirect.
With a simple API like this we should be able to enable smart load
balancing features contained in the clustering implementations out
there today, while keeping the caller's job simple.
Agreed - I think there's a requirement for the container (web/JBI/EJB/
SCA) to not worry at all about this stuff and just delegate to some
policy which decides whether to proxy, move, redirect. I hacked up a
little strawman
http://svn.apache.org/repos/asf/geronimo/trunk/modules/session/src/
java/org/apache/geronimo/session/remote/util/
DefaultRemoteSessionStrategy.java
but as you suggest, I think being able to pass in more metadata to
the policy would be a good idea
James
---
http://radio.weblogs.com/0112098/
Re: Session Policy was: heads up: initial contribution of a client API to session state management for OpenEJB, ServiceMix, Lingo and Tuscany
gentlemen, not a committer here, but wanted to share some thoughts.
in my opinion, the Session API should not have to know about clustering
or session replication, nor should it need to worry about location.
the clustering API should take care of all of that.
the solution that we plan to implement for Tomcat is fairly straight
forward. Let me see if I can give an idea of how the API shouldn't need
to worry, its a little lengthy, but it shows that the Session and the
SessionManager need to know zero about clustering or session locations.
(this is only one solution, and other solutions should demonstrate the
same point, SessionAPI need to know nothing about clustering or session
locations)
1. Requirements to be implemented by the Session.java API
bool isDirty - (has the session changed in this request)
bool isDiffable - is the session able provide a diff
byte[] getSessionData() - returns the whole session
byte[] getSessionDiff() - optional, see isDiffable, resets the diff data
void setSessionDiff(byte[] diff) - optional, see isDiffable, apply
changes from another node
2. Requirements to be implemented by the SessionManager.java API
void setSessionMap(HashMap map) - makes the map implementation pluggable
3. And the key to this, is that we will have an implementation of a
LazyReplicatedHashMap
The key object in this map is the session Id.
The map entry object is an object that looks like this
ReplicatedEntry {
string id;//sessionid
bool isPrimary; //does this node hold the data
bool isBackup; //does this node hold backup data
Session session; //not null values for primary and backup nodes
Member primary; //information about the primary node
Member backup; //information about the backup node
}
The LazyReplicatedHashMap overrides get(key) and put(id,session)
So all the nodes will have the a sessionId,ReplicatedEntry combinations
in their session map. But only two nodes will have the actual data.
This solution is for sticky LB only, but when failover happens, the LB
can pick any node as each node knows where to get the data.
The newly selected node, will keep the backup node or select a new one,
and do a publish to the entire cluster of the locations.
As you can see, all-to-all communications only happens when a Session is
(created|destroyed|failover). Other than that it is primary-to-backup
communication only, and this can be in terms of diffs or entire sessions
using the isDirty or getDiff. This is triggered either by an interceptor
at the end of each request or by a batch process for less network jitter
but less accuracy (but adequate) for fail over.
As you can see, access time is not relevant here, nor does the Session
API even know about clustering.
In tomcat we have separated out group communication into a separate
module, we are implementing the LazyReplicatedHashMap right now just for
this purpose.
positive thoughts, criticism and bashing are all welcome :)
Filip
Re: heads-up: Servlet-2.5 jetty 6 branch?
Cool! Regards, Alan Greg Wilkins wrote, On 3/1/2006 11:55 PM: All, I'm tuning back into G after zoning out for a while I'd like to started work on the jetty6 integration to provide servlet 2.5 The goals of the jetty 6 integration will be: + 2.5 servlet API. + annotation support + Simplify integration using Jetty 6 interceptor friendly architecture. + Use geronimo threadpool + Use Session API ( or iteration of that (see comments posted earlier)) as basis of session manager + Experiment with WADI and clustering integration + Better JACC specific security handler (perhaps to be back ported to Jetty) + Potentially use common server socket factories and eventually SSL Engine factories For this I'm going to created a branch geronimo/sandbox/servlet-2.5 and add geronimo-spec-servlet to geronimo/spec/branches/JEE5 I'm going for a full branch: + because I actually want to see how hard it will be to use svn to maintain a parallel dev branch. + I want some stability + I think there will be some moderately global changes that may affect multiple modules. + The branch will be a good place for a 2.5 tomcat module to be developed at the same time. everybody OK with this? I'd like to start this soonish, although I'm tempted to wait for maven2 to be working. cheers
Re: Help! Security Module
Thanks Anita, sorry for not noticing that your first mail had the pom attached. To me (and I'm no expert) it looks like we should be doing: (http://maven.apache.org/plugins/maven-surefire-plugin/howto.html) plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-surefire-plugin/artifactId configuration systemProperties property namejava.security.auth.login.config/name valuesrc/test-data/data/login.config/value /property property namelog4j.configuration/name valuefile:log4j.properties/value /property /systemProperties /configuration /plugin but that fails to work, I get NPEs at the sys-prop setting level. Asking the Maven guys if maybe it's changed or I'm just being an idiot. (http://www.rafb.net/paste/results/dPbO1l16.html) Hen On 3/3/06, anita kulshreshtha [EMAIL PROTECTED] wrote: I am able to build successfully (all test pass) using : mvn -o -Djava.security.auth.login.config=src/test-data/data/login.config -Dlog4j.configuration=file:log4j.properties install I need to set these properties. network.log defined in log4j.properties is not being created. Need to figure out why? Thanks Anita --- Henri Yandell [EMAIL PROTECTED] wrote: *sigh* need sugar. 'mail me the pom file'. Hen On 3/3/06, Henri Yandell [EMAIL PROTECTED] wrote: Could you the pom file you made so I can sit and stare at the errors too? :) Hen On 3/3/06, anita kulshreshtha [EMAIL PROTECTED] wrote: That did not help. I am loading all the properties defined in log4j.configuration via ant property file=log4j.properties/ Do I need to set the property log4j.configuration? to file:log4j.properties? Maven/ant does not like :. Thanks Anita --- anita kulshreshtha [EMAIL PROTECTED] wrote: Never mind... I just saw 2 delete dir lines! no mkdir :( Thanks Anita --- anita kulshreshtha [EMAIL PROTECTED] wrote: Hi, I am migrating security module to M2 (rev 382374). Some tests are failing. These tests pass with M1 build. :--- Battery: org.apache.geronimo.security.jaas.LoginKerberosTest --- Tests run: 1, Failures: 0, Errors: 1, Time elapsed: 0.437 sec testLogin(org.apache.geronimo.security.jaas.LoginKerberosTest) Time elapsed: 0.406 sec ERROR! [ stdout ] --- [ stderr ] --- [ stacktrace ] --- java.lang.SecurityException: Unable to locate a login configuration at com.sun.security.auth.login.ConfigFile.init(ConfigFile.java:97) at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) at ... The login.config in m1 build is defined by project.properties as : maven.junit.jvmargs=-Djava.security.auth.login.config=src/test-data/data/login.config I have set this property in pom.xml (attached). What is missing here? Thanks Anita __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com --- Battery: org.apache.geronimo.security.jaas.LoginKerberosTest --- Tests run: 1, Failures: 0, Errors: 1, Time elapsed: 0.437 sec testLogin(org.apache.geronimo.security.jaas.LoginKerberosTest) Time elapsed: 0.406 sec ERROR! [ stdout ] --- [ stderr ] --- [ stacktrace ] --- java.lang.SecurityException: Unable to locate a login configuration at com.sun.security.auth.login.ConfigFile.init(ConfigFile.java:97) at
Re: Session Policy was: heads up: initial contribution of a client API to session state management for OpenEJB, ServiceMix, Lingo and Tuscany
Filip,
This is good feedback; I wasn't aware of the details on what Tomcat
has done in this area.
We added concept of location to the Session APIs to address a few of
the weird and surprisingly common use cases.
1) Unreliable load balancer
In this case, the load balancer is not 100% and sometimes delivers
requests to the wrong node.
The solution to the first part is to allow the container to discover
the actual location of the session and do a client or server side
redirect to the correct node.
2) False positive on server failure
Load balancer decides that the machine has died and picks a new
random node for the request.
This requires either moving the session to the local machine or
sending a message to the load balancer informing it of the correct
location for the request.
3) Geronimo based load balancer
A Geronimo node sits in front of a group of Geronimo server, receives
all requests and directs them to the correct node.
In this case, the server needs to know the location of the session
and proxies the request to the correct node.
4) Smart Balancing
Some force behind the scenes (under the covers of the APIs) is
manipulating the load directly by migrating sessions. The clients
may not be aware of the migration and send requests to the wrong node.
This is very similar to Case 2, except in this case we need a way to
inform the client of the correct location of the session. The
pending request can simply be proxied on to the correct node with a
side-band message that the next request should go to a different
node, or we could do a client side redirect.
As you can, see all of the use cases we thought of require the
knowledge of the session location. Now, I am willing to admit that
this may be a golden hammer solution, so I'm open to any other ways
to implement these features without having to know session location.
I have some comments inline about the session api you present.
-dain
On Mar 3, 2006, at 7:00 AM, Filip Hanik - Dev Lists wrote:
gentlemen, not a committer here, but wanted to share some thoughts.
in my opinion, the Session API should not have to know about
clustering or session replication, nor should it need to worry
about location.
the clustering API should take care of all of that.
the solution that we plan to implement for Tomcat is fairly
straight forward. Let me see if I can give an idea of how the API
shouldn't need to worry, its a little lengthy, but it shows that
the Session and the SessionManager need to know zero about
clustering or session locations. (this is only one solution, and
other solutions should demonstrate the same point, SessionAPI need
to know nothing about clustering or session locations)
1. Requirements to be implemented by the Session.java API
bool isDirty - (has the session changed in this request)
bool isDiffable - is the session able provide a diff
byte[] getSessionData() - returns the whole session
byte[] getSessionDiff() - optional, see isDiffable, resets the
diff data
void setSessionDiff(byte[] diff) - optional, see isDiffable,
apply changes from another node
To throw you arguments back on you, why should my code be exposed to
this level of detail :) From my perspective, I get a session and it
is the Session API implementation's problem to figure out how to diff
it, back it up, and migrate it.
2. Requirements to be implemented by the SessionManager.java API
void setSessionMap(HashMap map) - makes the map implementation
pluggable
3. And the key to this, is that we will have an implementation of a
LazyReplicatedHashMap
The key object in this map is the session Id.
The map entry object is an object that looks like this
ReplicatedEntry {
string id;//sessionid
bool isPrimary; //does this node hold the data
bool isBackup; //does this node hold backup data
Session session; //not null values for primary and backup nodes
Member primary; //information about the primary node
Member backup; //information about the backup node
}
The LazyReplicatedHashMap overrides get(key) and put(id,session)
Why would anyone need to know this level of detail?
So all the nodes will have the a sessionId,ReplicatedEntry
combinations in their session map. But only two nodes will have the
actual data.
This solution is for sticky LB only, but when failover happens, the
LB can pick any node as each node knows where to get the data.
The newly selected node, will keep the backup node or select a new
one, and do a publish to the entire cluster of the locations.
I don't see anyway to deal with locking or the fact that servlet
sessions are multi threaded (overlaping requests). How do you know
when the session is not being used by anyone so you have a stable
state for replication.
As you can see, all-to-all communications only happens when a
Session is (created|destroyed|failover). Other than that it is
[jira] Created: (GERONIMO-1685) Need to ignore .DS_Store files in deployment dirs
Need to ignore .DS_Store files in deployment dirs - Key: GERONIMO-1685 URL: http://issues.apache.org/jira/browse/GERONIMO-1685 Project: Geronimo Type: Bug Components: deployment Versions: 1.0 Environment: Mac OS X Reporter: Matt Bishop Priority: Trivial Mac OS X creates a little file in every directory that the user views in the Finder (Think Windows Explorer) called .DS_Store. Geronimo, upon seeing such a file, tries to open it as if it were a deployable app, leading to the following stack traces: 09:03:00,995 WARN [DirectoryMonitor] Unable to calculate module ID for module /Library/Geronimo/Home/deploy/.DS_Store [/Library/Geronimo/Home/deploy/.DS_Store is neither a JAR file nor a directory!] 09:03:05,004 INFO [Hot Deployer] Deploying .DS_Store 09:03:05,299 ERROR [Hot Deployer] Unable to deploy: Cound not open module file: /Library/Geronimo/Home/var/temp/geronimo-deployer32634.tmpdir/.DS_Store org.apache.geronimo.common.DeploymentException: Cound not open module file: /Library/Geronimo/Home/var/temp/geronimo-deployer32634.tmpdir/.DS_Store at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:209) at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:102) at org.apache.geronimo.deployment.Deployer$$FastClassByCGLIB$$734a235d.invoke(generated) at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53) at org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38) at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:118) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:835) at org.apache.geronimo.kernel.basic.BasicKernel.invoke(BasicKernel.java:178) at org.apache.geronimo.deployment.plugin.local.AbstractDeployCommand.doDeploy(AbstractDeployCommand.java:106) at org.apache.geronimo.deployment.plugin.local.DistributeCommand.run(DistributeCommand.java:59) at java.lang.Thread.run(Thread.java:552) Caused by: java.util.zip.ZipException: error in opening zip file at java.util.zip.ZipFile.open(Native Method) at java.util.zip.ZipFile.init(ZipFile.java:111) at java.util.jar.JarFile.init(JarFile.java:127) at java.util.jar.JarFile.init(JarFile.java:92) at org.apache.geronimo.deployment.util.DeploymentUtil.createJarFile(DeploymentUtil.java:164) at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:207) ... 10 more It would be nice if Geronimo would ignore .DS_Store files. -- 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: Help! Security Module
That's right. surefire-plugin either needs the properties injected or set as system properties. Henri I found out from the maven guys that a maven 2.0.3-snapshot is planned to be released in a few more days. That should solve the problem. http://jira.codehaus.org/browse/MSUREFIRE-64 http://jira.codehaus.org/browse/MSUREFIRE-61 Cheers Prasad On 3/3/06, Henri Yandell [EMAIL PROTECTED] wrote: Thanks Anita, sorry for not noticing that your first mail had the pom attached. To me (and I'm no expert) it looks like we should be doing: (http://maven.apache.org/plugins/maven-surefire-plugin/howto.html) plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-surefire-plugin/artifactId configuration systemProperties property namejava.security.auth.login.config/name valuesrc/test-data/data/login.config/value /property property namelog4j.configuration/name valuefile:log4j.properties/value /property /systemProperties /configuration /plugin but that fails to work, I get NPEs at the sys-prop setting level. Asking the Maven guys if maybe it's changed or I'm just being an idiot. (http://www.rafb.net/paste/results/dPbO1l16.html) Hen On 3/3/06, anita kulshreshtha [EMAIL PROTECTED] wrote: I am able to build successfully (all test pass) using : mvn -o -Djava.security.auth.login.config=src/test-data/data/login.config -Dlog4j.configuration=file:log4j.properties install I need to set these properties. network.log defined in log4j.properties is not being created. Need to figure out why? Thanks Anita --- Henri Yandell [EMAIL PROTECTED] wrote: *sigh* need sugar. 'mail me the pom file'. Hen On 3/3/06, Henri Yandell [EMAIL PROTECTED] wrote: Could you the pom file you made so I can sit and stare at the errors too? :) Hen On 3/3/06, anita kulshreshtha [EMAIL PROTECTED] wrote: That did not help. I am loading all the properties defined in log4j.configuration via ant property file=log4j.properties/ Do I need to set the property log4j.configuration? to file:log4j.properties? Maven/ant does not like :. Thanks Anita --- anita kulshreshtha [EMAIL PROTECTED] wrote: Never mind... I just saw 2 delete dir lines! no mkdir :( Thanks Anita --- anita kulshreshtha [EMAIL PROTECTED] wrote: Hi, I am migrating security module to M2 (rev 382374). Some tests are failing. These tests pass with M1 build. :--- Battery: org.apache.geronimo.security.jaas.LoginKerberosTest --- Tests run: 1, Failures: 0, Errors: 1, Time elapsed: 0.437 sec testLogin(org.apache.geronimo.security.jaas.LoginKerberosTest) Time elapsed: 0.406 sec ERROR! [ stdout ] --- [ stderr ] --- [ stacktrace ] --- java.lang.SecurityException: Unable to locate a login configuration at com.sun.security.auth.login.ConfigFile.init(ConfigFile.java:97) at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) at ... The login.config in m1 build is defined by project.properties as : maven.junit.jvmargs=-Djava.security.auth.login.config=src/test-data/data/login.config I have set this property in pom.xml (attached). What is missing here? Thanks Anita __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com --- Battery: org.apache.geronimo.security.jaas.LoginKerberosTest --- Tests run: 1, Failures: 0, Errors: 1, Time elapsed: 0.437 sec testLogin(org.apache.geronimo.security.jaas.LoginKerberosTest) Time elapsed: 0.406 sec ERROR!
[jira] Created: (GERONIMO-1686) Servlet 2.5 and JSP 2.1 api jars for JavaEE 5 work
Servlet 2.5 and JSP 2.1 api jars for JavaEE 5 work -- Key: GERONIMO-1686 URL: http://issues.apache.org/jira/browse/GERONIMO-1686 Project: Geronimo Type: New Feature Reporter: Bill Dudney Priority: Minor I'm typing in the Servlet 2.5 and JSP 2.1 api's and will post a patch the week of 3/6/06. -- 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: heads-up: Servlet-2.5 jetty 6 branch?
Hi Greg, Seems I jumped the gun and did not write up a JIRA for this before getting started. I've got most of the Servlet 2.5 and JSP 2.1 api's typed in. I want to take one more pass over them to make sure I have all the correct exceptions on the methods and other details like that. I'll be submitting a patch early next week that has both of these api projects. Sorry for not entering a jira issue on it earlier http://issues.apache.org/jira/browse/GERONIMO-1686 TTFN, Bill Dudney MyFaces - myfaces.apache.org On Mar 2, 2006, at 12:55 AM, Greg Wilkins wrote: All, I'm tuning back into G after zoning out for a while I'd like to started work on the jetty6 integration to provide servlet 2.5 The goals of the jetty 6 integration will be: + 2.5 servlet API. + annotation support + Simplify integration using Jetty 6 interceptor friendly architecture. + Use geronimo threadpool + Use Session API ( or iteration of that (see comments posted earlier)) as basis of session manager + Experiment with WADI and clustering integration + Better JACC specific security handler (perhaps to be back ported to Jetty) + Potentially use common server socket factories and eventually SSL Engine factories For this I'm going to created a branch geronimo/sandbox/servlet-2.5 and add geronimo-spec-servlet to geronimo/spec/branches/JEE5 I'm going for a full branch: + because I actually want to see how hard it will be to use svn to maintain a parallel dev branch. + I want some stability + I think there will be some moderately global changes that may affect multiple modules. + The branch will be a good place for a 2.5 tomcat module to be developed at the same time. everybody OK with this? I'd like to start this soonish, although I'm tempted to wait for maven2 to be working. cheers
[jira] Created: (GERONIMO-1687) NPE during deployment related to EJB Ref
NPE during deployment related to EJB Ref Key: GERONIMO-1687 URL: http://issues.apache.org/jira/browse/GERONIMO-1687 Project: Geronimo Type: Bug Components: naming, OpenEJB Versions: 1.0 Environment: Geronimo 1.0 Reporter: Aaron Mulder Fix For: 1.0.1, 1.1 In my case this was caused by an EAR containing an EJB JAR and WAR but only the WAR was listed in application.xml. Clearly a user error, but obviously we should have an error message not an NPE. 15:45:22,432 ERROR [Deployer] Deployment failed due to java.lang.NullPointerException at org.apache.geronimo.j2ee.deployment.RefContext.getEJBLocalRef(RefContext.java:111) at org.apache.geronimo.naming.deployment.ENCConfigBuilder.addEJBLocalRefs(ENCConfigBuilder.java:507) at org.apache.geronimo.naming.deployment.ENCConfigBuilder.buildComponentContext(ENCConfigBuilder.java:781) at org.apache.geronimo.jetty.deployment.JettyModuleBuilder.buildComponentContext(JettyModuleBuilder.java:1291) at org.apache.geronimo.jetty.deployment.JettyModuleBuilder.addGBeans(JettyModuleBuilder.java:464) at org.apache.geronimo.jetty.deployment.JettyModuleBuilder$$FastClassByCGLIB$$b30bba8a.invoke(generated) at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53) at org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38) at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:118) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:800) at org.apache.geronimo.gbean.runtime.RawInvoker.invoke(RawInvoker.java:57) at org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke(RawOperationInvoker.java:36) at org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept(ProxyMethodInterceptor.java:96) at org.apache.geronimo.j2ee.deployment.ModuleBuilder$$EnhancerByCGLIB$$4ca9e4d7.addGBeans(generated) at org.apache.geronimo.j2ee.deployment.SwitchingModuleBuilder.addGBeans(SwitchingModuleBuilder.java:160) at org.apache.geronimo.j2ee.deployment.SwitchingModuleBuilder$$FastClassByCGLIB$$d0c31844.invoke(generated) at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53) at org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38) at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:118) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:800) at org.apache.geronimo.gbean.runtime.RawInvoker.invoke(RawInvoker.java:57) at org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke(RawOperationInvoker.java:36) at org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept(ProxyMethodInterceptor.java:96) at org.apache.geronimo.j2ee.deployment.ModuleBuilder$$EnhancerByCGLIB$$4ca9e4d7.addGBeans(generated) at org.apache.geronimo.j2ee.deployment.EARConfigBuilder.buildConfiguration(EARConfigBuilder.java:402) at org.apache.geronimo.j2ee.deployment.EARConfigBuilder$$FastClassByCGLIB$$38e56ec6.invoke(generated) at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53) at org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38) at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:118) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:800) at org.apache.geronimo.gbean.runtime.RawInvoker.invoke(RawInvoker.java:57) at org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke(RawOperationInvoker.java:36) at org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept(ProxyMethodInterceptor.java:96) at org.apache.geronimo.deployment.ConfigurationBuilder$$EnhancerByCGLIB$$5896ed49.buildConfiguration(generated) at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:269) at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:102) at org.apache.geronimo.deployment.Deployer$$FastClassByCGLIB$$734a235d.invoke(generated) at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53) at org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38) at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:118) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:835) at org.apache.geronimo.kernel.basic.BasicKernel.invoke(BasicKernel.java:178) at org.apache.geronimo.kernel.KernelGBean.invoke(KernelGBean.java:125) at org.apache.geronimo.kernel.KernelGBean$$FastClassByCGLIB$$1cccefc9.invoke(generated) at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53) at
Re: littleG (minimal-tomcat-server) status
On 3/3/06, Joe Bohn [EMAIL PROTECTED] wrote: I just added an updated patch to Geronimo-1613https://issues.apache.org/jira/browse/GERONIMO-1613After some painstaking effort, I was finally able to remove the uber-spec dependency from rmi-naming which should have resulted in anadditional savings in little-G of nearly 1.2 meg. Unfortunately, I hadto add in some individual spec jars that were not previously included and which decreased the savings somewhat.The real disappointment was when I picked up the latest image yesterdayto create the patch and noticed Kevan's change to include the CORBA specin rmi-naming to work around some other problem.This adds back in about 640K.The comment indicates that this is only temporary.Howlong will it be needed there and is somebody working to remove it? Hi Joe, If you've removed the uber-jar, then you should be able to remove the CORBA spec jar (assuming you're including the CORBA spec jar at an appropriate location...). The uber-jar currently contains bad corba spec classes. The dependency in rmi-naming put the CORBA spec jar in the classpath in front of the uber-jar. I also plan on fixing the uber-jar (getting the proper spec classes in the uber-jar). --kevan So, after all that the latest patch only takes us from 16.4 to about16.3 meg ... but we'll drop more when CORBA comes out of rmi-naming. Would it be possible to get this patch committed to trunk before toomuch more work happens on the maven2 effort?I think that it wouldbenefit the migration and integration if these updated project.xmls were used as the starting point.Joe--Joe Bohnjoe.bohn at earthlink.netHe is no fool who gives what he cannot keep, to gain what he cannotlose. -- Jim Elliot
Need some JIRA issue/version maintenance
Any volunteers to sort the JIRA issues that have no version number selected? Basically, we need to go through and assign versions to all of them, generally to either 1.1, 1.2, or both. If it's a clear user-facing bug I'd say put it to both, and if it's more general or an enhancement or something that would take more than a couple hours to fix mark it for 1.2. (I don't mind having extra stuff in 1.1 that the release manager needs to look through, but the issues with no versions bother me -- exactly because they wouldn't normally be noticed during the 1.1 release process.) Also, while you're* in there, please assign components to any issues that don't have one, and remember that you can select several. Thanks, Aaron * Whever you may be. Yes, this means you! :)
Docs on Destination Options is up.
Many of the cool new features in ActiveMQ 4.x consumers are enabled using destination options, but that had not been documented before. But that doco is now here: http://docs.codehaus.org/display/ACTIVEMQ/Destination+Options Regards, Hiram
Re: littleG (minimal-tomcat-server) status
Ah ... thanks for the clarification Kevan. In that case I don't think it is needed in rmi-naming with the uber-spec removed. I couldn't find any reason to include the corba spec in the rmi-naming config. I've created a new patch with this change and added it to GERONIMO-1613. So, with the corba spec removed our image size is back down to about 15.7 meg. Thanks, Joe Kevan Miller wrote: On 3/3/06, *Joe Bohn* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: I just added an updated patch to Geronimo-1613 https://issues.apache.org/jira/browse/GERONIMO-1613 After some painstaking effort, I was finally able to remove the uber-spec dependency from rmi-naming which should have resulted in an additional savings in little-G of nearly 1.2 meg. Unfortunately, I had to add in some individual spec jars that were not previously included and which decreased the savings somewhat. The real disappointment was when I picked up the latest image yesterday to create the patch and noticed Kevan's change to include the CORBA spec in rmi-naming to work around some other problem. This adds back in about 640K. The comment indicates that this is only temporary. How long will it be needed there and is somebody working to remove it? Hi Joe, If you've removed the uber-jar, then you should be able to remove the CORBA spec jar (assuming you're including the CORBA spec jar at an appropriate location...). The uber-jar currently contains bad corba spec classes. The dependency in rmi-naming put the CORBA spec jar in the classpath in front of the uber-jar. I also plan on fixing the uber-jar (getting the proper spec classes in the uber-jar). --kevan So, after all that the latest patch only takes us from 16.4 to about 16.3 meg ... but we'll drop more when CORBA comes out of rmi-naming. Would it be possible to get this patch committed to trunk before too much more work happens on the maven2 effort? I think that it would benefit the migration and integration if these updated project.xmls were used as the starting point. Joe -- Joe Bohn joe.bohn at earthlink.net http://earthlink.net He is no fool who gives what he cannot keep, to gain what he cannot lose. -- Jim Elliot -- Joe Bohn joe.bohn at earthlink.net He is no fool who gives what he cannot keep, to gain what he cannot lose. -- Jim Elliot
[jira] Updated: (GERONIMO-1613) Eliminate unncessary dependencies to reduce assemnbly footprint size
[ http://issues.apache.org/jira/browse/GERONIMO-1613?page=all ] Joe Bohn updated GERONIMO-1613: --- Attachment: 1613_RemoveDeps4.patch Added new patch with corba spec dependency removed from configs/rmi-naming. This gets the minimal image down to around 15.7 meg. Eliminate unncessary dependencies to reduce assemnbly footprint size Key: GERONIMO-1613 URL: http://issues.apache.org/jira/browse/GERONIMO-1613 Project: Geronimo Type: Improvement Components: general Versions: 1.2 Environment: all Reporter: Joe Bohn Assignee: David Jencks Fix For: 1.2 Attachments: 1613_RemoveDeps3.patch, 1613_RemoveDeps4.patch, RemoveDeps.patch, RemoveDeps2.1.patch, RemoveDeps2.2.patch, RemoveDeps2.3.patch, RemoveDeps2.patch Clean up assembly project.xml and eliminate some unnecessary dependencies in various modules and configs. This will reduce the footprint size (with special attention to the minimal-tomcat-assembly. The patch contains the following: - clean up minimal-tomcat-server\project.xml to remove commented out sections - clean up web-jms-tomcat-server\project.xml to remove commented out sections - remove dependencies from config\j2ee_server on xstream, jaxr-api, and geronimo-derby - remove dependencies from config\j2ee_deployer on geronimo-client-builder - remove dependencies from module\tomcat on activecluster, wadi-core, and wadi-tomcat55 There are still more dependencies that should be removed but this is a start. These changes reduce the disk footprint of minimal-tomcat-server from 27 meg to about 21 meg. -- 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: (SM-261) Cannot use a component auto deployed in service unit servicemix.xml
[ http://jira.activemq.org/jira//browse/SM-261?page=all ] Guillaume Nodet resolved SM-261: Assign To: Guillaume Nodet Resolution: Won't Fix When using JBI standard component installation, a specific classloader is created as required per the jbi spec. So there is no way to access the component classes, unless you put the jar in servicemix classpath. Cannot use a component auto deployed in service unit servicemix.xml --- Key: SM-261 URL: http://jira.activemq.org/jira//browse/SM-261 Project: ServiceMix Type: Bug Components: servicemix-core Versions: 3.0-M1 Environment: Windows XP, ServiceMix-2.1-SNAPSHOT, servicemix-lwcontainer Reporter: Kevin Bouchard Assignee: Guillaume Nodet Original Estimate: 1 day Remaining: 1 day Once a component is deployed using JBI auto deployment feature, it cannot be used in servicemix.xml artifact file of a service assembly. A ClassNotFoundException is thrown at service assembly installation. The component is visible in JMX console. However, it cannot be used in Spring servicemix.xml file. If we copy the jar file in the lib directory of servicemix, it works. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.activemq.org/jira//secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Session Policy was: heads up: initial contribution of a client API to session state management for OpenEJB, ServiceMix, Lingo and Tuscany
Hi Dain,
let me address the location, and show you how the location is completely
transparent.
The way the LazyReplicatedMap works is as follows:
1. Backup node fails - primary node chooses a new backup node
2. Primary node fails - since Tomcat doesn't know which node the user
will come to their
next http request, nothing is done.
When the user makes a request, and the session manager says
LazyMap.getSession(id) and that session is not yet on the server,
the lazymap will request the session from the backup server, load it
up, set this node as primary.
that is why it is called lazy, cause it wont load the session until
it is actually needed, and because it doesn't know what node will become
primary, this is decided by the load balancer. remember, that each node
knows where the session with Id= is located. they all carry the same
map, but only two carry the data (primary secondary).
on a false positive, the new primary node will cancel out the old one.
so you can have as many false positives as you want, but the more you
have the worse your performance will get :). that is why sticky lb is
important, but false positive is handled the same way as a crash except
that the old primary gets cancelled out.
the rest is inlined
1. Requirements to be implemented by the Session.java API
bool isDirty - (has the session changed in this request)
bool isDiffable - is the session able provide a diff
byte[] getSessionData() - returns the whole session
byte[] getSessionDiff() - optional, see isDiffable, resets the diff
data
void setSessionDiff(byte[] diff) - optional, see isDiffable, apply
changes from another node
To throw you arguments back on you, why should my code be exposed to
this level of detail :) From my perspective, I get a session and it
is the Session API implementation's problem to figure out how to diff
it, back it up, and migrate it.
exactly. the methods above is what is required from the servlet
container, not the webapp developer.
so if you are a jetty developer, you would implement the above methods.
This way, the jetty developer can optimize the serialization algorithm,
and locking (during diff creation), and your session will never be out
of date. in tomcat, we are making the getSessionDiff() a pluggable
algorithm, but it is implemented in the container, otherwise, just
serialization is too slow.
2. Requirements to be implemented by the SessionManager.java API
void setSessionMap(HashMap map) - makes the map implementation
pluggable
3. And the key to this, is that we will have an implementation of a
LazyReplicatedHashMap
The key object in this map is the session Id.
The map entry object is an object that looks like this
ReplicatedEntry {
string id;//sessionid
bool isPrimary; //does this node hold the data
bool isBackup; //does this node hold backup data
Session session; //not null values for primary and backup nodes
Member primary; //information about the primary node
Member backup; //information about the backup node
}
The LazyReplicatedHashMap overrides get(key) and put(id,session)
Why would anyone need to know this level of detail?
you don't and you will not, I just giving you some architectural insight
on how it works under the hood :)
So all the nodes will have the a sessionId,ReplicatedEntry
combinations in their session map. But only two nodes will have the
actual data.
This solution is for sticky LB only, but when failover happens, the
LB can pick any node as each node knows where to get the data.
The newly selected node, will keep the backup node or select a new
one, and do a publish to the entire cluster of the locations.
I don't see anyway to deal with locking or the fact that servlet
sessions are multi threaded (overlaping requests). How do you know
when the session is not being used by anyone so you have a stable
state for replication.
in tomcat we have an access counter, gets incremented when the request
comes in, and decremented when the request leaves. if the counter is 0,
lock the session and suck out the diff. or just lock it at the end of
each request on a periodic basis, regardless of what the counter is.
As you can see, all-to-all communications only happens when a Session
is (created|destroyed|failover). Other than that it is
primary-to-backup communication only, and this can be in terms of
diffs or entire sessions using the isDirty or getDiff. This is
triggered either by an interceptor at the end of each request or by a
batch process for less network jitter but less accuracy (but
adequate) for fail over.
As you can see, access time is not relevant here, nor does the
Session API even know about clustering.
How do you deal with access-time? I agree that your API doesn't know
about clustering, but you also can't do a client side or server side
redirect to the correct node; you must always migrate the session to
your request.
it doesn't,
Re: Session Policy was: heads up: initial contribution of a client API to session state management for OpenEJB, ServiceMix, Lingo and Tuscany
btw, for very large clusters, you use the same mechanism, except,
instead of distributing the entire session map, the backup node info is
stored in a cookie.
and by doing this, you don't need to remember the backup location
throughout the cluster. you still broadcast cancellations of primary
node to account for false positive.
the only scenario that is not accounted for is when you have a wacky lb
that sends two parallel requests to two different servers. this would
require distributed locking, and that is a path that is too much
overhead to walk down.
Filip
Filip Hanik - Dev Lists wrote:
Hi Dain,
let me address the location, and show you how the location is
completely transparent.
The way the LazyReplicatedMap works is as follows:
1. Backup node fails - primary node chooses a new backup node
2. Primary node fails - since Tomcat doesn't know which node the user
will come to their
next http request, nothing is done.
When the user makes a request, and the session manager says
LazyMap.getSession(id) and that session is not yet on the server,
the lazymap will request the session from the backup server, load it
up, set this node as primary.
that is why it is called lazy, cause it wont load the session until
it is actually needed, and because it doesn't know what node will
become primary, this is decided by the load balancer. remember, that
each node knows where the session with Id= is located. they all
carry the same map, but only two carry the data (primary secondary).
on a false positive, the new primary node will cancel out the old one.
so you can have as many false positives as you want, but the more you
have the worse your performance will get :). that is why sticky lb is
important, but false positive is handled the same way as a crash
except that the old primary gets cancelled out.
the rest is inlined
1. Requirements to be implemented by the Session.java API
bool isDirty - (has the session changed in this request)
bool isDiffable - is the session able provide a diff
byte[] getSessionData() - returns the whole session
byte[] getSessionDiff() - optional, see isDiffable, resets the
diff data
void setSessionDiff(byte[] diff) - optional, see isDiffable, apply
changes from another node
To throw you arguments back on you, why should my code be exposed to
this level of detail :) From my perspective, I get a session and it
is the Session API implementation's problem to figure out how to diff
it, back it up, and migrate it.
exactly. the methods above is what is required from the servlet
container, not the webapp developer.
so if you are a jetty developer, you would implement the above
methods. This way, the jetty developer can optimize the serialization
algorithm, and locking (during diff creation), and your session will
never be out of date. in tomcat, we are making the getSessionDiff() a
pluggable algorithm, but it is implemented in the container,
otherwise, just serialization is too slow.
2. Requirements to be implemented by the SessionManager.java API
void setSessionMap(HashMap map) - makes the map implementation
pluggable
3. And the key to this, is that we will have an implementation of a
LazyReplicatedHashMap
The key object in this map is the session Id.
The map entry object is an object that looks like this
ReplicatedEntry {
string id;//sessionid
bool isPrimary; //does this node hold the data
bool isBackup; //does this node hold backup data
Session session; //not null values for primary and backup nodes
Member primary; //information about the primary node
Member backup; //information about the backup node
}
The LazyReplicatedHashMap overrides get(key) and put(id,session)
Why would anyone need to know this level of detail?
you don't and you will not, I just giving you some architectural
insight on how it works under the hood :)
So all the nodes will have the a sessionId,ReplicatedEntry
combinations in their session map. But only two nodes will have the
actual data.
This solution is for sticky LB only, but when failover happens, the
LB can pick any node as each node knows where to get the data.
The newly selected node, will keep the backup node or select a new
one, and do a publish to the entire cluster of the locations.
I don't see anyway to deal with locking or the fact that servlet
sessions are multi threaded (overlaping requests). How do you know
when the session is not being used by anyone so you have a stable
state for replication.
in tomcat we have an access counter, gets incremented when the request
comes in, and decremented when the request leaves. if the counter is
0, lock the session and suck out the diff. or just lock it at the end
of each request on a periodic basis, regardless of what the counter is.
As you can see, all-to-all communications only happens when a
Session is (created|destroyed|failover). Other than that it is
primary-to-backup
[jira] Resolved: (SM-307) the name of the containershould not be appended to the working dir since it is configured for a given container
[ http://jira.activemq.org/jira//browse/SM-307?page=all ] Guillaume Nodet resolved SM-307: Assign To: Guillaume Nodet Resolution: Fixed Fix Version: 3.0-M1 Author: gnodet Date: Fri Mar 3 16:31:49 2006 New Revision: 382984 URL: http://svn.apache.org/viewcvs?rev=382984view=rev the name of the containershould not be appended to the working dir since it is configured for a given container --- Key: SM-307 URL: http://jira.activemq.org/jira//browse/SM-307 Project: ServiceMix Type: Bug Components: servicemix-core Reporter: Guillaume Nodet Assignee: Guillaume Nodet Fix For: 3.0-M1 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.activemq.org/jira//secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (SM-336) The AudoDeployment service should not persist state in the monitored directory
[ http://jira.activemq.org/jira//browse/SM-336?page=all ] Guillaume Nodet resolved SM-336: Assign To: Guillaume Nodet Resolution: Fixed Fix Version: (was: 3.0) 3.0-M1 Author: gnodet Date: Fri Mar 3 16:31:49 2006 New Revision: 382984 URL: http://svn.apache.org/viewcvs?rev=382984view=rev State is now persisted in the working directory. The AudoDeployment service should not persist state in the monitored directory -- Key: SM-336 URL: http://jira.activemq.org/jira//browse/SM-336 Project: ServiceMix Type: Improvement Components: servicemix-core Reporter: Guillaume Nodet Assignee: Guillaume Nodet Fix For: 3.0-M1 Persisting state inside the directory prevents using the same directory for several nodes in a cluster. The service should be able to either * rebuild the state when starting (using the list of deployed SA and components): the main problem is to detect changes * persist the state in the working directory -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.activemq.org/jira//secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (SM-295) Add support for service unit deployment descriptor as per the JBI specifications
[ http://jira.activemq.org/jira//browse/SM-295?page=comments#action_35674 ] Guillaume Nodet commented on SM-295: SAs and SUs are now parsed and informations extracted. Just need to use them now... Add support for service unit deployment descriptor as per the JBI specifications Key: SM-295 URL: http://jira.activemq.org/jira//browse/SM-295 Project: ServiceMix Type: Improvement Components: servicemix-core Versions: 2.0.2 Reporter: Hossam Karim Assignee: Guillaume Nodet Priority: Minor Fix For: 3.0-M1 Currenlty, ServiceMix does not process a service unit deployment descriptor correctly. For example, the deployment of 2 service units with the exact hard link specification succeeds. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.activemq.org/jira//secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (SM-295) Add support for service unit deployment descriptor as per the JBI specifications
[ http://jira.activemq.org/jira//browse/SM-295?page=all ] Guillaume Nodet updated SM-295: --- Assign To: Guillaume Nodet Fix Version: 3.0-M1 Add support for service unit deployment descriptor as per the JBI specifications Key: SM-295 URL: http://jira.activemq.org/jira//browse/SM-295 Project: ServiceMix Type: Improvement Components: servicemix-core Versions: 2.0.2 Reporter: Hossam Karim Assignee: Guillaume Nodet Priority: Minor Fix For: 3.0-M1 Currenlty, ServiceMix does not process a service unit deployment descriptor correctly. For example, the deployment of 2 service units with the exact hard link specification succeeds. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.activemq.org/jira//secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Work started: (SM-295) Add support for service unit deployment descriptor as per the JBI specifications
[ http://jira.activemq.org/jira//browse/SM-295?page=all ] Work on SM-295 started by Guillaume Nodet Add support for service unit deployment descriptor as per the JBI specifications Key: SM-295 URL: http://jira.activemq.org/jira//browse/SM-295 Project: ServiceMix Type: Improvement Components: servicemix-core Versions: 2.0.2 Reporter: Hossam Karim Assignee: Guillaume Nodet Priority: Minor Fix For: 3.0-M1 Currenlty, ServiceMix does not process a service unit deployment descriptor correctly. For example, the deployment of 2 service units with the exact hard link specification succeeds. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.activemq.org/jira//secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
