[jira] Commented: (GERONIMO-2934) Support annotation processing for all Module/Naming builders
[ https://issues.apache.org/jira/browse/GERONIMO-2934?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12478309 ] David Jencks commented on GERONIMO-2934: Applied a simplified version of the patch in rev 515016. The jetty server starts and is able to do some things, but I believe there are bugs. For instance, I think the naming builders that need to deal with @Resource annotations are not selecting the ones they know about, so @Resource annotations are likely to be added multiple times. However this work gives us a base for further progress. Support annotation processing for all Module/Naming builders Key: GERONIMO-2934 URL: https://issues.apache.org/jira/browse/GERONIMO-2934 Project: Geronimo Issue Type: Sub-task Security Level: public(Regular issues) Reporter: Tim McConnell Assigned To: Tim McConnell Attachments: GERONIMO-2934-1.patch -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [vote] Release geronimo-servlet_2.4_spec-1.1.1
David Blevins [EMAIL PROTECTED] writes: I hereby propose we release this branch and it's binaries as final. I'm the original requester of those jars for the Jakarta Commons Transaction project. So just for the archives: +1 Jörg
Re: [vote] Release geronimo-j2ee-connector_1.5_spec-1.1.1
David Blevins [EMAIL PROTECTED] writes: I hereby propose we release this branch and it's binaries as final. I'm the original requester of those jars for the Jakarta Commons Transaction project. So just for the archives: +1 Jörg
Re: [all] jarfiles in svn
David Blevins [EMAIL PROTECTED] writes: So I don't forget, some commons projects need JDK 1.3 compiled versions of some of our J2EE 1.4 specs, so at some when I get a spare cycle I plan to build and put those up for a vote. Hi David, thanks for your efforts. I couldn't join the votes as I was on vacation for 5 weeks at that time. Now I noticed from the tags in the svn repository that the jars are actually released. Are they already or will they be available from any public repository? Regards Jörg
Re: Questions for Axis2 folks re: JAXWS
Jeff,
Sorry for a late reply due to my time stamp difference and don't know
exactly you have solved this problem right now or not. Anyway here is my
comment.
Since you haven't given me exact source code I won't be able to point
you in to the exact source code in the Axis2. May be remote debugging
... ;-) .
Thanks,
Lasantha
Jeff Genender wrote:
Ok...
I am pretty certain at this stage that the WebService annotation is not
getting processed. Can you point me to the code that handles this in Axis2?
Thanks,
Jeff
Jeff Genender wrote:
Thanks...this is very helpful.
Then by this, looking at the PortInfo, it appears as though it is not
stuffing in the WSDL file, which tells me it's a G thang ;-)
Jeff
Lasantha Ranaweera wrote:
Hi Jeff,
To my understanding if we have given a WSDL in an archive it should get
the priority than the information in the annotations.
In Axis2 integration there are two parts of implementation with one for
with WSDL which is mainly handling by G side while with annotations from
Axis2. For me it is something missing in G side.
Somebody in the list please correct me if I am wrong here .
Thanks,
Lasantha
Jeff Genender wrote:
Hi,
I have noticed when I deploy a war file (with a WSDL), I have a certain
target name specified both in the WSDL and in the code that uses a
WebService annotation.
However, when I go retrieve the WSDL, I notice the target name seems to
be munged according to the package name (backwards) of the code that
contains the WebService annotation.
Example...
I have include a WSDL called Hello.wsdl that is in the war file in the
web-inf/wsdl directory and starts with:
wsdl:definitions targetNamespace=http://example.com/hello/xsd;
...
I have a HelloWorld.java that has this:
package test.mypackage;
import javax.jws.WebMethod;
import javax.jws.WebService;
@WebService(name=HelloWorld, targetNamespace =
http://example.org/hello/xsd;)
public class HelloWorld {
@WebMethod
public String sayHello(String me){
return Hello +me;
}
}
However, when I request the wsdl...I get something like this:
wsdl:definitions targetNamespace=http://mypackage.test/xsd;
...
Notice the targetnamespace was munged and changed from it's originally
declared namespace of http://example.com/hello/xsd;. I want the one
that is both declared in the included wsdl (or the one declared in the
annotation).
Is this a facet of Axis2 or is Geronimo not passing a proper PortInfo
object with the necessary stuff filled in?
Any light on this subject would be greatly appreciated ;-)
Thanks,
Jeff
Re: [test]How to update files in .m2/repository
Congrads! I restart the install from a new trunk. And after set the MaxPermSize, it finally build succesfully. Thanks very much. 2007/3/6, Kanchana Welagedara [EMAIL PROTECTED]: If you are on Linux you can set this environment variable as permanent in export in every mvn called in command prompt.I also run with 2GB ram $vim /etc/bash.bashrc and set export MAVEN_OPTS=-XX:MaxPermSize=128m -Xms512m -Xmx1024m cheers Kanchana On Tue, 2007-03-06 at 16:32 +0800, Sean Qiu wrote: I have set $MAVEN_OPTS=-Xmx1024m, and upgrade my pc's memory to 2G, but why it still has Out of memory error? Thanks for your help. == error message == [INFO] Packaging module configuration: /home/sean/trunk/configs/webconsole-tomcat/target/plan/plan.xml [INFO] [ERROR] FATAL ERROR [INFO] [INFO] null PermGen space [INFO] [INFO] Trace java.lang.ExceptionInInitializerError 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:585) at net.sf.cglib.proxy.MethodProxy.find(MethodProxy.java:127) at org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.getSuperIndex(ProxyMethodInterceptor.java:271) at org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.createRawGBeanInvokers(ProxyMethodInterceptor.java:140) at org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.createGBeanInvokers(ProxyMethodInterceptor.java:103) at org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.init(ProxyMethodInterceptor.java:70) at org.apache.geronimo.kernel.basic.BasicProxyManager.getMethodInterceptor(BasicProxyManager.java:232) at org.apache.geronimo.kernel.basic.BasicProxyManager$ManagedProxyFactory.createProxy(BasicProxyManager.java:209) at org.apache.geronimo.kernel.basic.BasicProxyManager.createProxy(BasicProxyManager.java:103) at org.apache.geronimo.kernel.config.ConfigurationUtil.getConfigurationManager(ConfigurationUtil.java:316) at org.apache.geronimo.kernel.config.ConfigurationUtil.loadBootstrapConfiguration(ConfigurationUtil.java:202) at org.apache.geronimo.kernel.config.ConfigurationUtil.loadBootstrapConfiguration(ConfigurationUtil.java:163) at org.apache.geronimo.mavenplugins.car.PackageMojo.bootDeployerSystem(PackageMojo.java:608) at org.apache.geronimo.mavenplugins.car.PackageMojo.createKernel(PackageMojo.java:520) at org.apache.geronimo.mavenplugins.car.PackageMojo.buildPackage(PackageMojo.java:453) at org.apache.geronimo.mavenplugins.car.PackageMojo.doExecute(PackageMojo.java:299) at org.apache.geronimo.genesis.MojoSupport.execute(MojoSupport.java:122) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:420) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:539) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:480) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:459) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:311) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:278) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:143) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:330) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:123) at org.apache.maven.cli.MavenCli.main(MavenCli.java:272) 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:585) at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) at org.codehaus.classworlds.Launcher.main(Launcher.java:375) Caused by: net.sf.cglib.core.CodeGenerationException: java.lang.reflect.InvocationTargetException--null at
[jira] Commented: (GERONIMO-2891) Initial Cayenne Integration with Geronimo
[ https://issues.apache.org/jira/browse/GERONIMO-2891?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12478362 ] Lasantha Ranaweera commented on GERONIMO-2891: -- Thanks David !!!. I checked the way as you suggested and it looks 4 5 are unnecessary steps and we can use java -jar server.jar to start the server. Thanks Again, Lasantha Initial Cayenne Integration with Geronimo - Key: GERONIMO-2891 URL: https://issues.apache.org/jira/browse/GERONIMO-2891 Project: Geronimo Issue Type: New Feature Security Level: public(Regular issues) Components: persistence Reporter: Lasantha Ranaweera Attachments: GERONIMO-2891.patch, JPA.patch, sample.patch This work will integrate Cayenne as a JPA provider in the Geronimo. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (GERONIMO-2936) Complete hookup of CORBA TSS-link elements.
Complete hookup of CORBA TSS-link elements. --- Key: GERONIMO-2936 URL: https://issues.apache.org/jira/browse/GERONIMO-2936 Project: Geronimo Issue Type: Task Security Level: public (Regular issues) Components: CORBA Affects Versions: 2.0-beta1 Reporter: Rick McGuire Assigned To: Rick McGuire Fix For: 2.0-beta1 The exporting of EJBs as CORBA objects still needs to be completed with the openejb3 codebase. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-2928) PersistenceUnit located in the EAR library directory is not yet implemented
[ https://issues.apache.org/jira/browse/GERONIMO-2928?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12478394 ] Gianny Damour commented on GERONIMO-2928: - PersistenceUnitBuilders are now invoked during the processing of EAR to discover persistence units located in the EAR library directory. It seems that some wirings are missings somewhere as they do not get bond to the ENC. Looking at this problem now. PersistenceUnit located in the EAR library directory is not yet implemented --- Key: GERONIMO-2928 URL: https://issues.apache.org/jira/browse/GERONIMO-2928 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: persistence Reporter: Gianny Damour Assigned To: Gianny Damour Persistence units located in the EAR library directory are not yet processed. I am working on a fix. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Database pools
Minor (? :)) Clarification
David, I meant to write connector-deployer config not
system-database to add the GBean to. Will that change your answer? I
think having individual GBeans in the appropriate deployer config will
work well for minimal and framework servers.
Thanks
Anita
--- Anita Kulshreshtha [EMAIL PROTECTED] wrote:
--- David Jencks [EMAIL PROTECTED] wrote:
On Mar 5, 2007, at 6:31 PM, Anita Kulshreshtha wrote:
I need to add RARConfigurer GBean to system-database config to
fix
https://issues.apache.org/jira/browse/GERONIMO-2916 (see excerpts
below)
Is this the correct place to add it?
No.
Instead of adding gbeans to anything, I think you want to start all
the jsr88-*configurer modules gianny recently added. See
assemblies/
geronimo-jetty6-jee5/src/main/var/config/jsr88-configurer-config.xml
which contains
module
name=org.apache.geronimo.configs/jsr88-cli/${version}/car/
module name=org.apache.geronimo.configs/jsr88-jar-configurer/$
{version}/car/
module name=org.apache.geronimo.configs/jsr88-rar-configurer/$
{version}/car/
module name=org.apache.geronimo.configs/jsr88-war-configurer/$
{version}/car/
module name=org.apache.geronimo.configs/jsr88-ear-configurer/$
{version}/car/
I don't think you want to start the jsr88-cli in the server. If
there isn't already an appropriate gbean for the DeploymentManager
we'd need a gbean like
gbean name=ModuleConfigurerRegistry
class=org.apache.geronimo.deployment.plugin.jmx.RemoteDeploymentManager
references name=ModuleConfigurers
pattern
nameClientConfigurer/name
/pattern
pattern
nameEARConfigurer/name
/pattern
pattern
nameRARConfigurer/name
/pattern
pattern
nameWARConfigurer/name
/pattern
/references
/gbean
somewhere appropriate but I don't think it should be the
jmxRemoteDeploymentManager. (but I'm not sure) It does need to be
able to accept the *Configurers registering with it.
I found WARConfigurer GBean in tomcat6-deployer config. I did
not
find any EarConfigurer. I am still mesmerized by this stuff... The
ModuleConfigurerRegistry is a good choice. Where should this GBean
go?
Thanks
Anita
thanks
david jencks
Thanks
Anita
5:07:55,562 ERROR [DatabasePoolPortlet] Unable to save connection
pool
javax.enterprise.deploy.spi.exceptions.InvalidModuleException: No
configurer for module type: rar registered
at
org.apache.geronimo.deployment.plugin.jmx.JMXDeploymentManager.createC
onfiguration(JMXDeploymentManager.java:302)
__
__
Don't get soaked. Take a quick peak at the forecast
with the Yahoo! Search weather shortcut.
http://tools.search.yahoo.com/shortcuts/#loc_weather
Do you Yahoo!?
Everyone is raving about the all-new Yahoo! Mail beta.
http://new.mail.yahoo.com
Never miss an email again!
Yahoo! Toolbar alerts you the instant new Mail arrives.
http://tools.search.yahoo.com/toolbar/features/mail/
Re: Property substitution in config.xml implemented
On 3/5/07, David Jencks [EMAIL PROTECTED] wrote:
On Mar 5, 2007, at 1:26 PM, Ted Kirby wrote:
snip One question I have is whether it's really a good idea to use
environment variables for substitutions. I really don't know and
would appreciate more informed opinions.
Also, you can specify an alternate properties file on the command
line with
java
-Dorg.apache.geronimo.config.substitutions.file=where.ever.you.want
Should we consider a naming convention? I find
org.apache.geronimo.config.substitutions.file to be long,
but I do
like the name space qualification that org.apache.geronimo provides.
Perhaps oag. could be used for short?
I would like to see some way to have a separate name space for system
properties/variables, like your portOffset above, and those that users
might use and define. For example, we could say that ag properties
like portOffset and those you will use to parameterize the config.xml
we ship, be prefixed by _. Users would not have to worry about a
naming collision if any variable name they use does not start with _.
I like the example of using a system property to override or provide a
value. The other ag system properties are prefixed by
org.apache.geronimo. (See my earlier comment.) Doing that in
config.xml, while long-winded, does provide name space isolation.
Perhaps not using org.apache.geronimo implies the variable only
applies to config.xml substitution, and has no other
interpretation/usage inside the server java code.
Although for different reasons, I like the idea of a namespace prefix for
environment variables and system properties. I have been very worried that
someone is going to have an env var httpPort for some other purpose and be
rather surprised when it changes geronimo behavior. I'm not really worried
about the length of these property names. I don't think including the
prefix in config.xml serves any purpose.
So, I'd propose that the local attribute manager looks for system properties
and env vars starting with
org.apache.geronimo.config.value.
and when found strip off the prefix and use the remainder as the property
name.
+1. I like this for system properties.
I share your ambivalence towards environment variables. Scripts have
no system properties, so environment variables are the only choice.
For our java server code, we could consider not supporting environment
variables. If the user wants to use environment variables, s/he can
always use -D{system property}=${environment variable} to set a system
property from an environment variable. There seem to be many
environment variables, so doing this provides safety from picking up
an unintended value from the environment. On the other hand, using
long variable names as you describe above would provide some
protection from this concern. Would your parsing of environment
variable names be case sensitive? Environment variable names
generally seem to be upper case. Using lower case may give us further
name-space isolation and protection from unintended consequences.
At the moment I don't see the value in trying to distinguish kinds of
substitution variables and having a naming convention for the different
kinds. All the variables can be specified in the properties file, as an env
var, or as a system property, and I think it really depends on your use case
whether you are more likely to override httpPort or portOffset on the
command line.
I am concerned with two cases:
1. How does a user know what substitution variables are in effect so
he can choose one not already in use?
Searching for the name in config.xml will solve the problem. Further,
I recently realized that the properties file will have a list of
variables used. The caveat here is that, IIUC, JEXL will silently
handle undefined values, so a used variable need not be listed in the
properties file. I think this is unfortunate for our usage here.
2. Say in release X, the user uses a new variable A, which we did not
use, and in release X+1, we now define variable A. As part of a
careful migration strategy, the user should diff config.xml to see
what has changed. Note that here, a release may be as small as a
patch.
While these are minor concerns with pretty easy manual means of
prevention (not sure about problem detection and determination), a
naming convention allows problem avoidance, as well as eliminates some
manual intervention. It's good to discuss naming conventions at the
time of feature introduction...
Ted Kirby
A further enhancement I thought of that I think I'd rather not pursue at
this time is to allow specifying the artifactId part of the module name in
the key. I think this is too complicated for the value added.
thanks
david jencks
Ted Kirby
Many thanks to ted for coming up with the original patch and pushing
for it.
thanks
david jencks
[jira] Commented: (GERONIMO-1418) allow user to specify deployment targets by nickname
[ https://issues.apache.org/jira/browse/GERONIMO-1418?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12478408 ] Ted Kirby commented on GERONIMO-1418: - Yes, yuck to long target name typing. I've suggested using environment variables here: http://cwiki.apache.org/GMOxDOC20/multiple-repositories-and-server-instances.html. I'd like to see a short name I can type that uniquely identifies exactly one config store. In the initial example, I see name=Customer. So, Customer seems the correct name for this config store. I think regexp is better than contains. However, I prefer my short name example above to matching, so I know for sure what I am getting. Also, I don't see the rationale for deploying into more than one target. So, if you want it/need it, then explicitly list the targets you want, but I wouldn't do it automagically! allow user to specify deployment targets by nickname -- Key: GERONIMO-1418 URL: https://issues.apache.org/jira/browse/GERONIMO-1418 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: deployment Affects Versions: 1.2 Environment: fedora core 4 Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_06-b03) Reporter: toby cabot Priority: Minor Fix For: 1.2, 2.0-beta1 Attachments: geronimo-target-nickname-1_2.txt, geronimo-target-nickname.txt This is a follow-on to the patch I submitted that allows Geronimo to have 2 configuration stores. Now that I can specify the config-store on the command line with the --targets switch I'm getting sick of typing the full target name (e.g. geronimo.server:J2EEApplication=null,J2EEModule=geronimo/j2ee-system/1.0/car,J2EEServer=geronimo,j2eeType=ConfigurationStore,name=Customer). This patch allows the user to specify any part of the target name (e.g. Customer) instead of the whole target name. It's pretty crude, so if there's a more elegant way to do something like this I'm all ears. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (SM-867) Cannot add soap header in JSR181 component
Cannot add soap header in JSR181 component -- Key: SM-867 URL: https://issues.apache.org/activemq/browse/SM-867 Project: ServiceMix Issue Type: Bug Components: servicemix-jsr181 Environment: ServiceMix 3.2 under Windows XP Reporter: Phu Quyen Le I would like to add some properties in the soap header of the message in a jsr181 component. But I can't do because of the following problem: Started from the example wsdl-first of ServiceMix, I've modified the file PersonImpl.java as follow: ... InOut exchange = (InOut) JBIContext.getMessageExchange(); Normalizedmessage outMsg = exchange.createMessage(); outMsg.setProperty(JbiConstants.SOAP_HEADERS, headers); exchange.setOutMessage(outMsg); GetPersonResponse response = new GetPersonResponse(); return response; ... I received then the follwing exception message: java.lang.Exception: javax.jbi.messaging.MessagingException: Out message is already set. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Questions for Axis2 folks re: JAXWS
o.a.g.Axis2WebserviceContainer, line 99. A not-filled in PortInfo is
passed in since G is not processing a WebService annotation, and thus an
AxisService.create is called on line 104.
When Axis2WebserviceContainer.getWsdl() is ultimately called,
doService2() is called (line 212), then to processGetRequest (line 398),
leading us to line 435 where the PortInfo is checked as to whether a
wsdl file has been passed in or not. If it has, it spits out the wsdl.
If it has not, then the AxisService.printWsdl() is called and that call
spits out a generated wsdl.
The crux here is that the PortInfo object does not have all of the info
filled in such as seiClass, wsdl file, etc. That stuff would have been
gotten from examining the WebService annotation.
The question is, where does that examination or, should that
examination, take place? Geronimo or Axis2?
Jeff
Lasantha Ranaweera wrote:
Jeff,
Sorry for a late reply due to my time stamp difference and don't know
exactly you have solved this problem right now or not. Anyway here is my
comment.
Since you haven't given me exact source code I won't be able to point
you in to the exact source code in the Axis2. May be remote debugging
... ;-) .
Thanks,
Lasantha
Jeff Genender wrote:
Ok...
I am pretty certain at this stage that the WebService annotation is not
getting processed. Can you point me to the code that handles this in
Axis2?
Thanks,
Jeff
Jeff Genender wrote:
Thanks...this is very helpful.
Then by this, looking at the PortInfo, it appears as though it is not
stuffing in the WSDL file, which tells me it's a G thang ;-)
Jeff
Lasantha Ranaweera wrote:
Hi Jeff,
To my understanding if we have given a WSDL in an archive it should get
the priority than the information in the annotations.
In Axis2 integration there are two parts of implementation with one for
with WSDL which is mainly handling by G side while with annotations
from
Axis2. For me it is something missing in G side.
Somebody in the list please correct me if I am wrong here .
Thanks,
Lasantha
Jeff Genender wrote:
Hi,
I have noticed when I deploy a war file (with a WSDL), I have a
certain
target name specified both in the WSDL and in the code that uses a
WebService annotation.
However, when I go retrieve the WSDL, I notice the target name
seems to
be munged according to the package name (backwards) of the code that
contains the WebService annotation.
Example...
I have include a WSDL called Hello.wsdl that is in the war file in the
web-inf/wsdl directory and starts with:
wsdl:definitions targetNamespace=http://example.com/hello/xsd;
...
I have a HelloWorld.java that has this:
package test.mypackage;
import javax.jws.WebMethod;
import javax.jws.WebService;
@WebService(name=HelloWorld, targetNamespace =
http://example.org/hello/xsd;)
public class HelloWorld {
@WebMethod
public String sayHello(String me){
return Hello +me;
}
}
However, when I request the wsdl...I get something like this:
wsdl:definitions targetNamespace=http://mypackage.test/xsd;
...
Notice the targetnamespace was munged and changed from it's originally
declared namespace of http://example.com/hello/xsd;. I want the one
that is both declared in the included wsdl (or the one declared in the
annotation).
Is this a facet of Axis2 or is Geronimo not passing a proper PortInfo
object with the necessary stuff filled in?
Any light on this subject would be greatly appreciated ;-)
Thanks,
Jeff
Re: Database pools
Hello Anita,
I had a quick look to GERONIMO-2916 and, as per David J. comment, it
seems to me that if you simply start the pointed out modules this bug
will be fixed: DatabasePoolPortlet gets a LocalDeploymentManager
instance, which knows about all the running ModuleConfigurer GBean
implementations. If org.apache.geronimo.configs/jsr88-rar-configurer//
car is started, then you will get a RARConfigurer running within the
server. Then when DatabasePoolPortlet obtains its
LocalDeploymentManager, this latter does know about RARConfigurer.
Thanks,
Gianny
On 07/03/2007, at 12:18 AM, Anita Kulshreshtha wrote:
Minor (? :)) Clarification
David, I meant to write connector-deployer config not
system-database to add the GBean to. Will that change your answer? I
think having individual GBeans in the appropriate deployer config will
work well for minimal and framework servers.
Thanks
Anita
--- Anita Kulshreshtha [EMAIL PROTECTED] wrote:
--- David Jencks [EMAIL PROTECTED] wrote:
On Mar 5, 2007, at 6:31 PM, Anita Kulshreshtha wrote:
I need to add RARConfigurer GBean to system-database config to
fix
https://issues.apache.org/jira/browse/GERONIMO-2916 (see excerpts
below)
Is this the correct place to add it?
No.
Instead of adding gbeans to anything, I think you want to start all
the jsr88-*configurer modules gianny recently added. See
assemblies/
geronimo-jetty6-jee5/src/main/var/config/jsr88-configurer-config.xml
which contains
module
name=org.apache.geronimo.configs/jsr88-cli/${version}/car/
module name=org.apache.geronimo.configs/jsr88-jar-configurer/$
{version}/car/
module name=org.apache.geronimo.configs/jsr88-rar-configurer/$
{version}/car/
module name=org.apache.geronimo.configs/jsr88-war-configurer/$
{version}/car/
module name=org.apache.geronimo.configs/jsr88-ear-configurer/$
{version}/car/
I don't think you want to start the jsr88-cli in the server. If
there isn't already an appropriate gbean for the DeploymentManager
we'd need a gbean like
gbean name=ModuleConfigurerRegistry
class=org.apache.geronimo.deployment.plugin.jmx.RemoteDeploymentManag
er
references name=ModuleConfigurers
pattern
nameClientConfigurer/name
/pattern
pattern
nameEARConfigurer/name
/pattern
pattern
nameRARConfigurer/name
/pattern
pattern
nameWARConfigurer/name
/pattern
/references
/gbean
somewhere appropriate but I don't think it should be the
jmxRemoteDeploymentManager. (but I'm not sure) It does need to be
able to accept the *Configurers registering with it.
I found WARConfigurer GBean in tomcat6-deployer config. I did
not
find any EarConfigurer. I am still mesmerized by this stuff... The
ModuleConfigurerRegistry is a good choice. Where should this GBean
go?
Thanks
Anita
thanks
david jencks
Thanks
Anita
5:07:55,562 ERROR [DatabasePoolPortlet] Unable to save connection
pool
javax.enterprise.deploy.spi.exceptions.InvalidModuleException: No
configurer for module type: rar registered
at
org.apache.geronimo.deployment.plugin.jmx.JMXDeploymentManager.createC
onfiguration(JMXDeploymentManager.java:302)
__
__
Don't get soaked. Take a quick peak at the forecast
with the Yahoo! Search weather shortcut.
http://tools.search.yahoo.com/shortcuts/#loc_weather
__
__
Do you Yahoo!?
Everyone is raving about the all-new Yahoo! Mail beta.
http://new.mail.yahoo.com
__
__
Never miss an email again!
Yahoo! Toolbar alerts you the instant new Mail arrives.
http://tools.search.yahoo.com/toolbar/features/mail/
Re: Build Failure - Eclipse-Plugin trunk Rev513960
Isn't solving problem. Did an svn update, mvn clean and mvn. Still facing the same problem. svn update fetched in following patches: Uplugins\pom.xml Uplugins\org.apache.geronimo.st.v20.core\pom.xml Ufeatures\org.apache.geronimo.feature\feature.xml However, adding the following entry lib/xstream-1.1.3.jar, in plugins\org.apache.geronimo.runtime.common\META-INF\MANIFEST.MF solved the problem. Please check. -- Thx, Shiva On 3/5/07, Sachin Patel [EMAIL PROTECTED] wrote: fixed -sachin On Mar 5, 2007, at 9:15 AM, Sachin Patel wrote: I can reproduce this now... will investigate. -sachin On Mar 5, 2007, at 7:03 AM, Shiva Kumar H R wrote: I too am getting a Build error as below: [INFO] Building org.apache.geronimo.runtime.common [INFO]task-segment: [install] [ERROR] BUILD ERROR [INFO] [INFO] Manifest Bundle-Classpath is missing the following entries: [lib/xstream- 1.1.3.jar] [INFO] [INFO] Trace org.apache.maven.lifecycle.LifecycleExecutionException : Manifest Bundle-Classpat h is missing the following entries: [lib/xstream-1.1.3.jar] at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(Defa ultLifecycleExecutor.java:559) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLi fecycle(DefaultLifecycleExecutor.java:475) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal (Defau ltLifecycleExecutor.java :454) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHan dleFailures(DefaultLifecycleExecutor.java:306) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegmen ts(DefaultLifecycleExecutor.java:273) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute (DefaultLi fecycleExecutor.java:140) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java :322) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:115) at org.apache.maven.cli.MavenCli.main(MavenCli.java:256) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke (NativeMethodAccessorImpl. java:64) at sun.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAcces sorImpl.java:43) at java.lang.reflect.Method.invoke (Method.java:615) at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java :315) at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) at org.codehaus.classworlds.Launcher.mainWithExitCode ( Launcher.java:430) at org.codehaus.classworlds.Launcher.main(Launcher.java:375) Caused by: org.apache.maven.plugin.MojoExecutionException: Manifest Bundle-Class path is missing the following entries: [lib/xstream- 1.1.3.jar] at org.apache.geronimo.eclipse.devtools.BundleManifestMojo.execute (Bundl eManifestMojo.java:72) at org.apache.maven.plugin.DefaultPluginManager.executeMojo (DefaultPlugi nManager.java :412) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(Defa ultLifecycleExecutor.java:534) ... 16 more Caused by: org.apache.maven.plugin.MojoFailureException: Manifest Bundle-Classpa th is missing the following entries: [lib/xstream-1.1.3.jar] at org.apache.geronimo.eclipse.devtools.BundleManifestMojo.validateBundl eClasspath(BundleManifestMojo.java:97) at org.apache.geronimo.eclipse.devtools.BundleManifestMojo.execute(Bundl eManifestMojo.java:69) ... 18 more [INFO] [INFO] Total time: 2 minutes 40 seconds [INFO] Finished at: Mon Mar 05 16:32:47 IST 2007 [INFO] Final Memory: 18M/89M [INFO] -- Thx, Shiva On 3/4/07, Donald Woods [EMAIL PROTECTED] wrote: Latest Eclipse-Plugin trunk at Rev513960 fails to build with the following error on WinXP, Maven 2.0.5 and Java 1.5.0_11 - [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Failed to resolve artifact. Missing: -- 1) org.apache.geronimo.devtools:org.apache.geronimo.st.v20.core:jar:2.0.0 Try downloading the file manually from the project website. Then, install it using the command: mvn install:install-file -DgroupId=org.apache.geronimo.devtools -Dartifact Id=org.apache.geronimo.st.v20.core \ -Dversion=2.0.0 -Dpackaging=jar -Dfile=/path/to/file Path to dependency: 1) org.apache.geronimo.devtools:assembly:pom:2.0.0 2) org.apache.geronimo.devtools:org.apache.geronimo.st.v20.core:jar:2.0 . 0 -- 1 required artifact is missing. for artifact:
[jira] Resolved: (SM-866) wsn-http-binding fails to start
[ https://issues.apache.org/activemq/browse/SM-866?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guillaume Nodet resolved SM-866. Resolution: Fixed Assignee: Guillaume Nodet Author: gnodet Date: Tue Mar 6 06:19:31 2007 New Revision: 515130 URL: http://svn.apache.org/viewvc?view=revrev=515130 Log: SM-866: wsn-http-binding fails to start Modified: incubator/servicemix/trunk/distributions/apache-servicemix/src/main/release/examples/wsn-http-binding/servicemix.xml Author: gnodet Date: Tue Mar 6 06:21:54 2007 New Revision: 515131 URL: http://svn.apache.org/viewvc?view=revrev=515131 Log: SM-866: wsn-http-binding fails to start Modified: incubator/servicemix/branches/servicemix-3.1/distributions/apache-servicemix/src/main/release/examples/wsn-http-binding/servicemix.xml wsn-http-binding fails to start Key: SM-866 URL: https://issues.apache.org/activemq/browse/SM-866 Project: ServiceMix Issue Type: Bug Components: servicemix-assembly Affects Versions: 3.1 Reporter: Guillaume Nodet Assigned To: Guillaume Nodet Fix For: 3.1.1, 3.2 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Database pools
I agree that starting the existing jsr88-* configs is a better
solution than adding gbeans to the deployer configs. There might
possibly be classloading problems from duplicate copies of e.g.
geronimo-connector-builder.jar, but if that happens I think the
better solution is to move the jsr88 code into separate jars,
something I believe Aaron and I have been contemplating for years.
I'm glad to know that there is already a LocalDeploymentManager.
thanks
david jencks
On Mar 6, 2007, at 9:11 AM, Gianny Damour wrote:
Hello Anita,
I had a quick look to GERONIMO-2916 and, as per David J. comment,
it seems to me that if you simply start the pointed out modules
this bug will be fixed: DatabasePoolPortlet gets a
LocalDeploymentManager instance, which knows about all the running
ModuleConfigurer GBean implementations. If
org.apache.geronimo.configs/jsr88-rar-configurer//car is started,
then you will get a RARConfigurer running within the server. Then
when DatabasePoolPortlet obtains its LocalDeploymentManager, this
latter does know about RARConfigurer.
Thanks,
Gianny
On 07/03/2007, at 12:18 AM, Anita Kulshreshtha wrote:
Minor (? :)) Clarification
David, I meant to write connector-deployer config not
system-database to add the GBean to. Will that change your answer? I
think having individual GBeans in the appropriate deployer config
will
work well for minimal and framework servers.
Thanks
Anita
--- Anita Kulshreshtha [EMAIL PROTECTED] wrote:
--- David Jencks [EMAIL PROTECTED] wrote:
On Mar 5, 2007, at 6:31 PM, Anita Kulshreshtha wrote:
I need to add RARConfigurer GBean to system-database config to
fix
https://issues.apache.org/jira/browse/GERONIMO-2916 (see excerpts
below)
Is this the correct place to add it?
No.
Instead of adding gbeans to anything, I think you want to start all
the jsr88-*configurer modules gianny recently added. See
assemblies/
geronimo-jetty6-jee5/src/main/var/config/jsr88-configurer-config.xml
which contains
module
name=org.apache.geronimo.configs/jsr88-cli/${version}/car/
module name=org.apache.geronimo.configs/jsr88-jar-configurer/$
{version}/car/
module name=org.apache.geronimo.configs/jsr88-rar-configurer/$
{version}/car/
module name=org.apache.geronimo.configs/jsr88-war-configurer/$
{version}/car/
module name=org.apache.geronimo.configs/jsr88-ear-configurer/$
{version}/car/
I don't think you want to start the jsr88-cli in the server. If
there isn't already an appropriate gbean for the DeploymentManager
we'd need a gbean like
gbean name=ModuleConfigurerRegistry
class=org.apache.geronimo.deployment.plugin.jmx.RemoteDeploymentMana
ger
references name=ModuleConfigurers
pattern
nameClientConfigurer/name
/pattern
pattern
nameEARConfigurer/name
/pattern
pattern
nameRARConfigurer/name
/pattern
pattern
nameWARConfigurer/name
/pattern
/references
/gbean
somewhere appropriate but I don't think it should be the
jmxRemoteDeploymentManager. (but I'm not sure) It does need to be
able to accept the *Configurers registering with it.
I found WARConfigurer GBean in tomcat6-deployer config. I did
not
find any EarConfigurer. I am still mesmerized by this stuff... The
ModuleConfigurerRegistry is a good choice. Where should this GBean
go?
Thanks
Anita
thanks
david jencks
Thanks
Anita
5:07:55,562 ERROR [DatabasePoolPortlet] Unable to save connection
pool
javax.enterprise.deploy.spi.exceptions.InvalidModuleException: No
configurer for module type: rar registered
at
org.apache.geronimo.deployment.plugin.jmx.JMXDeploymentManager.create
C
onfiguration(JMXDeploymentManager.java:302)
_
_
__
Don't get soaked. Take a quick peak at the forecast
with the Yahoo! Search weather shortcut.
http://tools.search.yahoo.com/shortcuts/#loc_weather
_
___
Do you Yahoo!?
Everyone is raving about the all-new Yahoo! Mail beta.
http://new.mail.yahoo.com
_
___
Never miss an email again!
Yahoo! Toolbar alerts you the instant new Mail arrives.
http://tools.search.yahoo.com/toolbar/features/mail/
Re: Questions for Axis2 folks re: JAXWS
I have been giving some thoughts on this prob yesterday. By looking at
the java comments for AxisService.createService, it seems this method is
only for RPCMessageReceiver, but we are using JAXWSMessageReceiver here.
Maybe dims or Lasantha can comment on this.
seems there are 2 scenarios:
1) no webservices.xml, no .wsdl, just java files with annotation:
One solution I can think of is to create a temp wsdl file when
Axis2Builder is called based on the java files (seems this can be done
either using the Java2WSDLCodegenEngine from Axis2 or using Sun's
tools), and then set PortInfo properties there. When
Axis2WebServiceContainer is called, we'll treat it as wsdl file already
exists. Delete the temp wsdl file at the end.
2) no webservices.xml, just .wsdl and java files with annotation.
In this case, since there is no webservices.xml, should we scan the
module to see if .wsdl file is included in Axis2Builder? if so, set the
wsdl-file property in PortInfo.
I haven't implemented anything yet as I think we should all agree to a
solution first.
Lin
Jeff Genender wrote:
o.a.g.Axis2WebserviceContainer, line 99. A not-filled in PortInfo is
passed in since G is not processing a WebService annotation, and thus an
AxisService.create is called on line 104.
When Axis2WebserviceContainer.getWsdl() is ultimately called,
doService2() is called (line 212), then to processGetRequest (line 398),
leading us to line 435 where the PortInfo is checked as to whether a
wsdl file has been passed in or not. If it has, it spits out the wsdl.
If it has not, then the AxisService.printWsdl() is called and that call
spits out a generated wsdl.
The crux here is that the PortInfo object does not have all of the info
filled in such as seiClass, wsdl file, etc. That stuff would have been
gotten from examining the WebService annotation.
The question is, where does that examination or, should that
examination, take place? Geronimo or Axis2?
Jeff
Lasantha Ranaweera wrote:
Jeff,
Sorry for a late reply due to my time stamp difference and don't know
exactly you have solved this problem right now or not. Anyway here is my
comment.
Since you haven't given me exact source code I won't be able to point
you in to the exact source code in the Axis2. May be remote debugging
... ;-) .
Thanks,
Lasantha
Jeff Genender wrote:
Ok...
I am pretty certain at this stage that the WebService annotation is not
getting processed. Can you point me to the code that handles this in
Axis2?
Thanks,
Jeff
Jeff Genender wrote:
Thanks...this is very helpful.
Then by this, looking at the PortInfo, it appears as though it is not
stuffing in the WSDL file, which tells me it's a G thang ;-)
Jeff
Lasantha Ranaweera wrote:
Hi Jeff,
To my understanding if we have given a WSDL in an archive it should get
the priority than the information in the annotations.
In Axis2 integration there are two parts of implementation with one for
with WSDL which is mainly handling by G side while with annotations
from
Axis2. For me it is something missing in G side.
Somebody in the list please correct me if I am wrong here .
Thanks,
Lasantha
Jeff Genender wrote:
Hi,
I have noticed when I deploy a war file (with a WSDL), I have a
certain
target name specified both in the WSDL and in the code that uses a
WebService annotation.
However, when I go retrieve the WSDL, I notice the target name
seems to
be munged according to the package name (backwards) of the code that
contains the WebService annotation.
Example...
I have include a WSDL called Hello.wsdl that is in the war file in the
web-inf/wsdl directory and starts with:
wsdl:definitions targetNamespace=http://example.com/hello/xsd;
...
I have a HelloWorld.java that has this:
package test.mypackage;
import javax.jws.WebMethod;
import javax.jws.WebService;
@WebService(name=HelloWorld, targetNamespace =
http://example.org/hello/xsd;)
public class HelloWorld {
@WebMethod
public String sayHello(String me){
return Hello +me;
}
}
However, when I request the wsdl...I get something like this:
wsdl:definitions targetNamespace=http://mypackage.test/xsd;
...
Notice the targetnamespace was munged and changed from it's originally
declared namespace of http://example.com/hello/xsd;. I want the one
that is both declared in the included wsdl (or the one declared in the
annotation).
Is this a facet of Axis2 or is Geronimo not passing a proper PortInfo
object with the necessary stuff filled in?
Any light on this subject would be greatly appreciated ;-)
Thanks,
Jeff
Re: Build Failure - Eclipse-Plugin trunk Rev513960
You may not have the latest, I upgraded that library to 1.2. Please try a fresh checkout and rebuild. -sachin On Mar 6, 2007, at 9:25 AM, Shiva Kumar H R wrote: Isn't solving problem. Did an svn update, mvn clean and mvn. Still facing the same problem. svn update fetched in following patches: Uplugins\pom.xml Uplugins\org.apache.geronimo.st.v20.core\pom.xml Ufeatures\org.apache.geronimo.feature\feature.xml However, adding the following entry lib/xstream-1.1.3.jar, in plugins\org.apache.geronimo.runtime.common\META-INF\MANIFEST.MF solved the problem. Please check. -- Thx, Shiva On 3/5/07, Sachin Patel [EMAIL PROTECTED] wrote: fixed -sachin On Mar 5, 2007, at 9:15 AM, Sachin Patel wrote: I can reproduce this now... will investigate. -sachin On Mar 5, 2007, at 7:03 AM, Shiva Kumar H R wrote: I too am getting a Build error as below: [INFO] Building org.apache.geronimo.runtime.common [INFO]task-segment: [install] [ERROR] BUILD ERROR [INFO] [INFO] Manifest Bundle-Classpath is missing the following entries: [lib/xstream- 1.1.3.jar] [INFO] [INFO] Trace org.apache.maven.lifecycle.LifecycleExecutionException : Manifest Bundle-Classpat h is missing the following entries: [lib/xstream- 1.1.3.jar] at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals (Defa ultLifecycleExecutor.java:559) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithL i fecycle( DefaultLifecycleExecutor.java:475) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal (Defau ltLifecycleExecutor.java :454) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHa n dleFailures(DefaultLifecycleExecutor.java:306) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegme n ts(DefaultLifecycleExecutor.java:273) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute (DefaultLi fecycleExecutor.java:140) at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java :322) at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:115) at org.apache.maven.cli.MavenCli.main (MavenCli.java:256) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke (NativeMethodAccessorImpl. java:64) at sun.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAcces sorImpl.java:43) at java.lang.reflect.Method.invoke (Method.java:615) at org.codehaus.classworlds.Launcher.launchEnhanced (Launcher.java:315) at org.codehaus.classworlds.Launcher.launch (Launcher.java:255) at org.codehaus.classworlds.Launcher.mainWithExitCode (Launcher.java:430) at org.codehaus.classworlds.Launcher.main(Launcher.java:375) Caused by: org.apache.maven.plugin.MojoExecutionException : Manifest Bundle-Class path is missing the following entries: [lib/xstream- 1.1.3.jar] at org.apache.geronimo.eclipse.devtools.BundleManifestMojo.execute (Bundl eManifestMojo.java:72) at org.apache.maven.plugin.DefaultPluginManager.executeMojo (DefaultPlugi nManager.java :412) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals (Defa ultLifecycleExecutor.java:534) ... 16 more Caused by: org.apache.maven.plugin.MojoFailureException : Manifest Bundle-Classpa th is missing the following entries: [lib/xstream-1.1.3.jar] at org.apache.geronimo.eclipse.devtools.BundleManifestMojo.validateBund l eClasspath(BundleManifestMojo.java:97) at org.apache.geronimo.eclipse.devtools.BundleManifestMojo.execute (Bundl eManifestMojo.java:69) ... 18 more [INFO] [INFO] Total time: 2 minutes 40 seconds [INFO] Finished at: Mon Mar 05 16:32:47 IST 2007 [INFO] Final Memory: 18M/89M [INFO] -- Thx, Shiva On 3/4/07, Donald Woods [EMAIL PROTECTED] wrote: Latest Eclipse-Plugin trunk at Rev513960 fails to build with the following error on WinXP, Maven 2.0.5 and Java 1.5.0_11 - [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Failed to resolve artifact. Missing: -- 1) org.apache.geronimo.devtools:org.apache.geronimo.st.v20.core:jar: 2.0.0 Try downloading the file manually from the project website. Then, install it using the command: mvn install:install-file - DgroupId=org.apache.geronimo.devtools -Dartifact Id=org.apache.geronimo.st.v20.core \ -Dversion=2.0.0 -Dpackaging=jar
Re: Build Failure - Eclipse-Plugin trunk Rev513960
Actually, the problem is that you need to do an mvn clean, to remove the old jars in the lib directory. -sachin On Mar 6, 2007, at 10:02 AM, Sachin Patel wrote: You may not have the latest, I upgraded that library to 1.2. Please try a fresh checkout and rebuild. -sachin On Mar 6, 2007, at 9:25 AM, Shiva Kumar H R wrote: Isn't solving problem. Did an svn update, mvn clean and mvn. Still facing the same problem. svn update fetched in following patches: Uplugins\pom.xml Uplugins\org.apache.geronimo.st.v20.core\pom.xml Ufeatures\org.apache.geronimo.feature\feature.xml However, adding the following entry lib/xstream-1.1.3.jar, in plugins\org.apache.geronimo.runtime.common\META-INF\MANIFEST.MF solved the problem. Please check. -- Thx, Shiva On 3/5/07, Sachin Patel [EMAIL PROTECTED] wrote: fixed -sachin On Mar 5, 2007, at 9:15 AM, Sachin Patel wrote: I can reproduce this now... will investigate. -sachin On Mar 5, 2007, at 7:03 AM, Shiva Kumar H R wrote: I too am getting a Build error as below: [INFO] Building org.apache.geronimo.runtime.common [INFO]task-segment: [install] [ERROR] BUILD ERROR [INFO] --- - [INFO] Manifest Bundle-Classpath is missing the following entries: [lib/xstream- 1.1.3.jar] [INFO] --- - [INFO] Trace org.apache.maven.lifecycle.LifecycleExecutionException : Manifest Bundle-Classpat h is missing the following entries: [lib/xstream- 1.1.3.jar] at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals (Defa ultLifecycleExecutor.java:559) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWith Li fecycle( DefaultLifecycleExecutor.java:475) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal (Defau ltLifecycleExecutor.java :454) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndH an dleFailures(DefaultLifecycleExecutor.java:306) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegm en ts(DefaultLifecycleExecutor.java:273) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute (DefaultLi fecycleExecutor.java:140) at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java :322) at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:115) at org.apache.maven.cli.MavenCli.main (MavenCli.java:256) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke (NativeMethodAccessorImpl. java:64) at sun.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAcces sorImpl.java:43) at java.lang.reflect.Method.invoke (Method.java:615) at org.codehaus.classworlds.Launcher.launchEnhanced (Launcher.java:315) at org.codehaus.classworlds.Launcher.launch (Launcher.java:255) at org.codehaus.classworlds.Launcher.mainWithExitCode (Launcher.java:430) at org.codehaus.classworlds.Launcher.main(Launcher.java: 375) Caused by: org.apache.maven.plugin.MojoExecutionException : Manifest Bundle-Class path is missing the following entries: [lib/xstream- 1.1.3.jar] at org.apache.geronimo.eclipse.devtools.BundleManifestMojo.execute (Bundl eManifestMojo.java:72) at org.apache.maven.plugin.DefaultPluginManager.executeMojo (DefaultPlugi nManager.java :412) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals (Defa ultLifecycleExecutor.java:534) ... 16 more Caused by: org.apache.maven.plugin.MojoFailureException : Manifest Bundle-Classpa th is missing the following entries: [lib/xstream-1.1.3.jar] at org.apache.geronimo.eclipse.devtools.BundleManifestMojo.validateBun dl eClasspath(BundleManifestMojo.java:97) at org.apache.geronimo.eclipse.devtools.BundleManifestMojo.execute (Bundl eManifestMojo.java:69) ... 18 more [INFO] --- - [INFO] Total time: 2 minutes 40 seconds [INFO] Finished at: Mon Mar 05 16:32:47 IST 2007 [INFO] Final Memory: 18M/89M [INFO] --- - -- Thx, Shiva On 3/4/07, Donald Woods [EMAIL PROTECTED] wrote: Latest Eclipse-Plugin trunk at Rev513960 fails to build with the following error on WinXP, Maven 2.0.5 and Java 1.5.0_11 - [INFO] --- - [ERROR] BUILD ERROR [INFO] --- - [INFO] Failed to resolve artifact. Missing: -- 1) org.apache.geronimo.devtools:org.apache.geronimo.st.v20.core:jar: 2.0.0 Try downloading the file manually from the project website. Then, install it using the
Document servicemix-common
We need to document servicemix-common, which is our framework for building standard JBI components. But at the same time, servicemix-common does not sounds like a very good name. What about JBI Components Framework ? I'm not talking about changing the code, nor the jar, just to do a bit more advertising on the the web site about it ... -- Cheers, Guillaume Nodet
ServiceMix Console!
Hy, can someone tell which features ServiceMix Console provides? Can I also use it, if I use ServiceMix in combination with JBoss? greets Goldi -- View this message in context: http://www.nabble.com/ServiceMix-Console%21-tf3356276s12049.html#a9334434 Sent from the ServiceMix - Dev mailing list archive at Nabble.com.
Re: Document servicemix-common
JBI Component Framework (no plural) sounds fine to me. We need to document servicemix-common, which is our framework for building standard JBI components. But at the same time, servicemix-common does not sounds like a very good name. What about JBI Components Framework ? I'm not talking about changing the code, nor the jar, just to do a bit more advertising on the the web site about it ... -- Terry Cox Meta-Concepts Ltd
anyone able to run geronimo\testsuite?
Hi there, I am having trouble to run the jaxws-war testsuite. So i went to its parent directory testsuite and found I could not run any testsuite from there either. This was working yesterday PM.:-( Can someone shed some light on this? e:\geronimolatest2\testsuitemvn install [INFO] Scanning for projects... [INFO] Reactor build order: [INFO] Geronimo TestSuite [INFO] Geronimo TestSuite :: Console Testsuite [INFO] Geronimo TestSuite :: Deployment Testsuite [INFO] Geronimo TestSuite :: Enterprise Testsuite [INFO] Geronimo TestSuite :: Web-tier Testsuite [INFO] Geronimo TestSuite :: WebServices TestSuite [INFO] - --- [INFO] Building Geronimo TestSuite [INFO]task-segment: [install] [INFO] - --- [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Error building POM (may not be this project's POM). Project ID: null:testsuite-maven-plugin:maven-plugin:null Reason: Cannot find parent: org.apache.geronimo.plugins:maven-plugins for projec t: null:testsuite-maven-plugin:maven-plugin:null [INFO] [INFO] For more information, run Maven with the -e switch [INFO] [INFO] Total time: 3 seconds [INFO] Finished at: Tue Mar 06 10:44:48 EST 2007 [INFO] Final Memory: 5M/9M [INFO] Lin
Re: anyone able to run geronimo\testsuite?
Guess you have cleaned your local repo in the interim. Go to geronimo/plugins and build the plugins there. Cheers Prasad On 3/6/07, Lin Sun [EMAIL PROTECTED] wrote: Hi there, I am having trouble to run the jaxws-war testsuite. So i went to its parent directory testsuite and found I could not run any testsuite from there either. This was working yesterday PM.:-( Can someone shed some light on this? e:\geronimolatest2\testsuitemvn install [INFO] Scanning for projects... [INFO] Reactor build order: [INFO] Geronimo TestSuite [INFO] Geronimo TestSuite :: Console Testsuite [INFO] Geronimo TestSuite :: Deployment Testsuite [INFO] Geronimo TestSuite :: Enterprise Testsuite [INFO] Geronimo TestSuite :: Web-tier Testsuite [INFO] Geronimo TestSuite :: WebServices TestSuite [INFO] - --- [INFO] Building Geronimo TestSuite [INFO]task-segment: [install] [INFO] - --- [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Error building POM (may not be this project's POM). Project ID: null:testsuite-maven-plugin:maven-plugin:null Reason: Cannot find parent: org.apache.geronimo.plugins:maven-plugins for projec t: null:testsuite-maven-plugin:maven-plugin:null [INFO] [INFO] For more information, run Maven with the -e switch [INFO] [INFO] Total time: 3 seconds [INFO] Finished at: Tue Mar 06 10:44:48 EST 2007 [INFO] Final Memory: 5M/9M [INFO] Lin
Re: build a war file using maven when web.xml is not there
I believe Jarek is including a testcase in the webservices-testsuite which is testing the deployment of optional DDs. Cheers Prasad On 3/5/07, Lin Sun [EMAIL PROTECTED] wrote: FYI - I have seeing a maven failure when building a war file and web.xml is not there in the project for the purpose to test we support optional web.xml. And there is already a maven feature request for this - http://jira.codehaus.org/browse/MWAR-30 Seems this will be an important feature for us to have to test this optional web.xml feature in Java EE 5 tho. :-( Lin
Re: Build Failure - Eclipse-Plugin trunk Rev513960
Worked for me. Thanks. -Donald Sachin Patel wrote: fixed -sachin On Mar 5, 2007, at 9:15 AM, Sachin Patel wrote: I can reproduce this now... will investigate. -sachin On Mar 5, 2007, at 7:03 AM, Shiva Kumar H R wrote: I too am getting a Build error as below: [INFO] Building org.apache.geronimo.runtime.common [INFO]task-segment: [install] [ERROR] BUILD ERROR [INFO] [INFO] Manifest Bundle-Classpath is missing the following entries: [lib/xstream- 1.1.3.jar] [INFO] [INFO] Trace org.apache.maven.lifecycle.LifecycleExecutionException : Manifest Bundle-Classpat h is missing the following entries: [lib/xstream-1.1.3.jar] at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(Defa ultLifecycleExecutor.java:559) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLi fecycle(DefaultLifecycleExecutor.java:475) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(Defau ltLifecycleExecutor.java :454) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHan dleFailures(DefaultLifecycleExecutor.java:306) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegmen ts(DefaultLifecycleExecutor.java:273) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLi fecycleExecutor.java:140) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java :322) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:115) at org.apache.maven.cli.MavenCli.main(MavenCli.java:256) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl. java:64) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces sorImpl.java:43) at java.lang.reflect.Method.invoke (Method.java:615) at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) at org.codehaus.classworlds.Launcher.mainWithExitCode (Launcher.java:430) at org.codehaus.classworlds.Launcher.main(Launcher.java:375) Caused by: org.apache.maven.plugin.MojoExecutionException: Manifest Bundle-Class path is missing the following entries: [lib/xstream- 1.1.3.jar] at org.apache.geronimo.eclipse.devtools.BundleManifestMojo.execute(Bundl eManifestMojo.java:72) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPlugi nManager.java :412) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(Defa ultLifecycleExecutor.java:534) ... 16 more Caused by: org.apache.maven.plugin.MojoFailureException: Manifest Bundle-Classpa th is missing the following entries: [lib/xstream-1.1.3.jar] at org.apache.geronimo.eclipse.devtools.BundleManifestMojo.validateBundl eClasspath(BundleManifestMojo.java:97) at org.apache.geronimo.eclipse.devtools.BundleManifestMojo.execute (Bundl eManifestMojo.java:69) ... 18 more [INFO] [INFO] Total time: 2 minutes 40 seconds [INFO] Finished at: Mon Mar 05 16:32:47 IST 2007 [INFO] Final Memory: 18M/89M [INFO] -- Thx, Shiva On 3/4/07, *Donald Woods* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Latest Eclipse-Plugin trunk at Rev513960 fails to build with the following error on WinXP, Maven 2.0.5 and Java 1.5.0_11 - [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Failed to resolve artifact. Missing: -- 1) org.apache.geronimo.devtools:org.apache.geronimo.st.v20.core:jar:2.0.0 Try downloading the file manually from the project website. Then, install it using the command: mvn install:install-file -DgroupId=org.apache.geronimo.devtools -Dartifact Id=org.apache.geronimo.st.v20.core \ -Dversion=2.0.0 -Dpackaging=jar -Dfile=/path/to/file Path to dependency: 1) org.apache.geronimo.devtools:assembly:pom:2.0.0 2) org.apache.geronimo.devtools:org.apache.geronimo.st.v20.core:jar:2.0 . 0 -- 1 required artifact is missing. for artifact: org.apache.geronimo.devtools:assembly:pom:2.0.0 -Donald smime.p7s Description: S/MIME Cryptographic Signature
Re: anyone able to run geronimo\testsuite?
Did you mean asf/geronimo/server/trunk/maven-plugins? There is a asf/geronimo/plugins, but it only has a Spring plugin available right now -Donald Prasad Kashyap wrote: Guess you have cleaned your local repo in the interim. Go to geronimo/plugins and build the plugins there. Cheers Prasad On 3/6/07, Lin Sun [EMAIL PROTECTED] wrote: Hi there, I am having trouble to run the jaxws-war testsuite. So i went to its parent directory testsuite and found I could not run any testsuite from there either. This was working yesterday PM.:-( Can someone shed some light on this? e:\geronimolatest2\testsuitemvn install [INFO] Scanning for projects... [INFO] Reactor build order: [INFO] Geronimo TestSuite [INFO] Geronimo TestSuite :: Console Testsuite [INFO] Geronimo TestSuite :: Deployment Testsuite [INFO] Geronimo TestSuite :: Enterprise Testsuite [INFO] Geronimo TestSuite :: Web-tier Testsuite [INFO] Geronimo TestSuite :: WebServices TestSuite [INFO] - --- [INFO] Building Geronimo TestSuite [INFO]task-segment: [install] [INFO] - --- [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Error building POM (may not be this project's POM). Project ID: null:testsuite-maven-plugin:maven-plugin:null Reason: Cannot find parent: org.apache.geronimo.plugins:maven-plugins for projec t: null:testsuite-maven-plugin:maven-plugin:null [INFO] [INFO] For more information, run Maven with the -e switch [INFO] [INFO] Total time: 3 seconds [INFO] Finished at: Tue Mar 06 10:44:48 EST 2007 [INFO] Final Memory: 5M/9M [INFO] Lin smime.p7s Description: S/MIME Cryptographic Signature
[jira] Commented: (GERONIMO-2868) Message Driven Beans will not run under the specified run-as Subject
[ https://issues.apache.org/jira/browse/GERONIMO-2868?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12478461 ] Aman Nanner commented on GERONIMO-2868: --- Ok, I've patched my instance by adding the DefaultSubjectInterceptor into the MDB's interceptor stack; however, the MDB always receives a null default subject. I've located this issue to the fact that the constructor in MdbDeployment always passes a null principal to AbstractEjbDeployment. I'll see if I can modify this so that it passes the actual default principal similar to the way SLSBs do. Message Driven Beans will not run under the specified run-as Subject -- Key: GERONIMO-2868 URL: https://issues.apache.org/jira/browse/GERONIMO-2868 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: OpenEJB, security Affects Versions: 1.2 Reporter: Aman Nanner Assigned To: David Jencks Attachments: mdb-run-as.patch If a message driven bean is configured with a run-as element, it is being ignored and the message driven bean is not run as the specified Subject. The MDB would be configured in the ejb-jar.xml as follows: message-driven display-nameTestMDB/display-name ejb-nameTestMDB/ejb-name ejb-classcom.acme.ejb.TestMDB/ejb-class transaction-typeBean/transaction-type message-destination-typejavax.jms.Topic/message-destination-type activation-config activation-config-property activation-config-property-nameacknowledgeMode/activation-config-property-name activation-config-property-valueAuto-acknowledge/activation-config-property-value /activation-config-property activation-config-property activation-config-property-namemessageSelector/activation-config-property-name activation-config-property-valueJOB_CODE = 'FOO'/activation-config-property-value /activation-config-property activation-config-property activation-config-property-namesubscriptionDurability/activation-config-property-name activation-config-property-valueNonDurable/activation-config-property-value /activation-config-property /activation-config ejb-ref ejb-ref-nameejb/common/TestEJB/ejb-ref-name ejb-ref-typeSession/ejb-ref-type homecom.acme.ejb.TestHome/home remotecom.acme.ejb.TestRemote/remote ejb-linkTestEJB/ejb-link /ejb-ref security-identity run-as role-nameTESTROLE/role-name /run-as /security-identity /message-driven Upon inspection of the org.apache.openejb.mdb.DefaaultMdbContainer class, it is noted that the EjbRunAsInterceptor is not configured as part of the invocation step (as it is in org.apache.openejb.slsb.DefaultStatelessEjbContainer). Therefore, the run-as Subject is never being set as part of the Caller stack. I added the EjbRunAsInterceptor into the invocation stack and rebuilt Geronimo, but this didn't completely fix the problem. The EjbRunAsInterceptor is now being called, and the Subject is being set as the next caller in the ContextManager's caller stack. However, the EjbIdentityInterceptor runs next, and authorizes the invocation under the current caller, not the next caller. Thus, the run-as Subject does NOT perform the invocation. I'm not sure what the best way is to fix this without impacting everything else. If somebody with more knowledge in this area has a good idea, I can try it and submit a patch. Also note that this problem seems to imply that the run-as functionality wouldn't work with session EJBs either (I haven't tried to verify this). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: anyone able to run geronimo\testsuite?
Sorry Donald. You are right. That is what I meant. Cheers Prasad On 3/6/07, Donald Woods [EMAIL PROTECTED] wrote: Did you mean asf/geronimo/server/trunk/maven-plugins? There is a asf/geronimo/plugins, but it only has a Spring plugin available right now -Donald Prasad Kashyap wrote: Guess you have cleaned your local repo in the interim. Go to geronimo/plugins and build the plugins there. Cheers Prasad On 3/6/07, Lin Sun [EMAIL PROTECTED] wrote: Hi there, I am having trouble to run the jaxws-war testsuite. So i went to its parent directory testsuite and found I could not run any testsuite from there either. This was working yesterday PM.:-( Can someone shed some light on this? e:\geronimolatest2\testsuitemvn install [INFO] Scanning for projects... [INFO] Reactor build order: [INFO] Geronimo TestSuite [INFO] Geronimo TestSuite :: Console Testsuite [INFO] Geronimo TestSuite :: Deployment Testsuite [INFO] Geronimo TestSuite :: Enterprise Testsuite [INFO] Geronimo TestSuite :: Web-tier Testsuite [INFO] Geronimo TestSuite :: WebServices TestSuite [INFO] - --- [INFO] Building Geronimo TestSuite [INFO]task-segment: [install] [INFO] - --- [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Error building POM (may not be this project's POM). Project ID: null:testsuite-maven-plugin:maven-plugin:null Reason: Cannot find parent: org.apache.geronimo.plugins:maven-plugins for projec t: null:testsuite-maven-plugin:maven-plugin:null [INFO] [INFO] For more information, run Maven with the -e switch [INFO] [INFO] Total time: 3 seconds [INFO] Finished at: Tue Mar 06 10:44:48 EST 2007 [INFO] Final Memory: 5M/9M [INFO] Lin
Re: CORBA ported from OpenEJB 2
Ok, I think I've run into the first problem area. I'm trying to
translate what's getting done in the TSSLinkBuilder to the new paradigm,
and I've bumped up against a problem straight off. Ok, you've given me
the following with what you've implemented: an ejbName, a tssBeanName,
and a list of jndinames used to publish this bean to the naming service.
Now in the TSSLinkBuilder, we were operating on the XML for a single ejb
definition, so the ejbName came from the plan naming context, and was
then converted into an AbstractName instance to complete the GBean
wiring. The TSSLinkBuilder code in question looks like this:
public void buildNaming(XmlObject specDD, XmlObject plan,
Configuration localConfiguration, Configuration remoteConfiguration,
Module module, Map componentContext) throws DeploymentException {
if (plan == null) {
return;
}
AbstractName ejbName = getGBeanName(componentContext);
where the componentContext is used to retrieve an AbstractName for this
ejb using the simple name contained in the plan. But now things are
inverted in the ModuleBuilderExtension, so I need to map the simple name
retrieved from a tss-link element to the corresponding AbstractName for
the EJB in this module context. How do I retrieve that information?
Secondly, TSSLinkBuilder uses the module URI for the first attempt at
resolving the TSSBean information. Here's the code:
URI moduleURI = module.getModuleURI();
String moduleString = moduleURI == null ? null :
moduleURI.toString();
AbstractNameQuery tssBeanName =
ENCConfigBuilder.buildAbstractNameQuery(null, moduleString, tssLink,
NameFactory.EJB_MODULE, NameFactory.EJB_MODULE);
If this fails, than it tries again without the module name. Is this
still a correct usage, or is there something else that should be used here?
Rick
David Blevins wrote:
On Feb 28, 2007, at 3:29 AM, Rick McGuire wrote:
David Blevins wrote:
On Feb 27, 2007, at 4:39 PM, Rick McGuire wrote:
David Blevins wrote:
On Feb 27, 2007, at 5:55 AM, Rick McGuire wrote:
I'm about 99.% certain that tss was a very old element type
that was never deleted from the schema. The only one I'm aware
is still getting used is the tss-link, so that should be the only
thing that needs to be added. The tss-link element is used to
hook an ejb instance to the appropriate POA to export this as a
CORBA object. My experience with schema is pretty limited (i.e.,
approaching zero), so any assistance in that phase would be
greatly appreciated.
Ok. How about something like:
tss-link ejb-name= poa-name=/
The only piece of information required is the name of a TSSBean,
assuming all of the same bits of information are still extractable
from the either the plan or other sources. The current usage is
tss-linktss-bean-nametss-link
I'm not really sure what I'd pick for an attribute name, so keeping
the same syntax is probably easiest.
The two other pieces of information required to complete the
linkage are the EBJ name and the JNDI name(s) this EJB is
registered under. The JNDI names are using to export the EJB to
the CORBA naming service. I assume these same bits of information
are still relevant/available in openejb3.
Couple more questions. Does every ejb in corba need a tss-link and
or tssbean?
Every ejb that's exported via corba will need a tss-link.
Will some ejbs share the same tssbean (i.e. be linked to the same
tss bean)?
Sharing is quite common. The tssbean the ejbs link to determine the
characteristics of the transport and security profile used for access.
If sharing is there, how common is it to have a second tss bean (and
subsequent links).
I think this is fairly common to have more than one tssbean if there
are multiple security profiles defined. Any given EJB, however, is
only linked to one tssbean at a time.
And finally, where is the tssbean itself configured?
I'm not totally certain I understand the context of this question.
The tssbeans are typically defined in a parent configuration play for
the deployed app. A tssbean is attached to a corbabean instance.
The corbabean manages the ORB instance the tssbean is defined for
(defining, for example, the transport-level security
characteristicsi.e., does it use SSL). The TSSBean, when it's
started, creates the POAs on the hosting orb that will be used to
activate the EJBs. The tsslink GBeans handle making the connections
between the exported GBeans and the location used for the export. So
far, I don't believe that there have been any chances at all required
for either corbabean or tssbean for openejb3.
Ok, so I plumbed this in for you;
tss-link
ejb-name/ejb-name
tss-name/tss-name
jndi-name/jndi-name
jndi-name/jndi-name
jndi-name/jndi-name
/tss-link
It's all in the geronimo-openejb.xsd and data from v2 plans is getting
converted over and now available as an array directly off
[jira] Commented: (GERONIMO-2916) database creation pool wizzard fails to deploy
[ https://issues.apache.org/jira/browse/GERONIMO-2916?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12478469 ] Jay D. McHugh commented on GERONIMO-2916: - There is also a problem trying to deploy from the command line. Attempting to deploy from the command line: [EMAIL PROTECTED]:/opt/geronimo# java -jar bin/deployer.jar deploy /home/jmchugh/plc.data.xml repository/org/tranql/tranql-connector-ra/1.3/tranql-connector-ra-1.3.rar Username: system Password: *** Error: Unable to distribute tranql-connector-ra-1.3.rar: java.lang.NullPointerException null snippet - geronimo.out 10:28:09,010 ERROR [Deployer] Deployment failed due to java.lang.NullPointerException at org.apache.geronimo.persistence.builder.PersistenceUnitBuilder.build(PersistenceUnitBuilder.java:73) at org.apache.geronimo.persistence.builder.PersistenceUnitBuilder$$FastClassByCGLIB$$e8dd93fa.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:127) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:820) at org.apache.geronimo.gbean.runtime.RawInvoker.invoke(RawInvoker.java:57) at org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke(RawOperationInvoker.java:35) at org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept(ProxyMethodInterceptor.java:96) at org.apache.geronimo.deployment.NamespaceDrivenBuilder$$EnhancerByCGLIB$$1bc9ab04.build(generated) at org.apache.geronimo.deployment.NamespaceDrivenBuilderCollection.build(NamespaceDrivenBuilderCollection.java:48) at org.apache.geronimo.j2ee.deployment.EARConfigBuilder.buildConfiguration(EARConfigBuilder.java:563) 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:127) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:820) at org.apache.geronimo.gbean.runtime.RawInvoker.invoke(RawInvoker.java:57) at org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke(RawOperationInvoker.java:35) at org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept(ProxyMethodInterceptor.java:96) at org.apache.geronimo.j2ee.deployment.CorbaGBeanNameSource$$EnhancerByCGLIB$$a6ae3f78.buildConfiguration(generated) at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:302) at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:124) 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:127) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:855) at org.apache.geronimo.kernel.basic.BasicKernel.invoke(BasicKernel.java:239) at org.apache.geronimo.kernel.KernelGBean.invoke(KernelGBean.java:342) at org.apache.geronimo.kernel.KernelGBean$$FastClassByCGLIB$$1cccefc9.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:127) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:855) at org.apache.geronimo.kernel.basic.BasicKernel.invoke(BasicKernel.java:239) at org.apache.geronimo.system.jmx.MBeanGBeanBridge.invoke(MBeanGBeanBridge.java:168) at com.sun.jmx.mbeanserver.DynamicMetaDataImpl.invoke(DynamicMetaDataImpl.java:213) at com.sun.jmx.mbeanserver.MetaDataImpl.invoke(MetaDataImpl.java:220) at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:815) at com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(JmxMBeanServer.java:784) at javax.management.remote.rmi.RMIConnectionImpl.doOperation(RMIConnectionImpl.java:1408) at javax.management.remote.rmi.RMIConnectionImpl.access$100(RMIConnectionImpl.java:81) at javax.management.remote.rmi.RMIConnectionImpl$PrivilegedOperation.run(RMIConnectionImpl.java:1245) at
Re: ENC (Environment Naming Context) Question
David Jencks wrote: On Mar 5, 2007, at 4:50 AM, Christopher M. Cardona wrote: Some questions about our ENC implementation: 1. How do we add/create a subcontext for java:comp/env? Do we have an API for doing this? I get javax.naming.OperationNotSupportedException when calling createSubcontext(). Per the spec java:comp is read-only. The content is set up in the NamingBuilders during deployment: we construct a map of stuff, which is turned into a Context using EnterpriseNamingContext.createEnterpriseNamingContext. David, That explains it. Yes, I saw this called while debugging through the deployment of a webapp. Sorry I wasn't asking the right questions. What I was trying to do is bind a resource (e.g. JavaMail Session or JDBC DataSource) to the global jndi during deployment. I think I figured out where to do this during deployment but not exactly sure which context to use for binding. IIUC, we already bind something locally to the ENC so a particular module can have access to it at runtime. But if we wanted another module or even a standalone app (possibly a different jvm) to have access to those resources we need to use the global JNDI. Is my understanding correct? Am I asking the right questions here? :-) Any clarification would help. Thanks, chris
Re: CORBA ported from OpenEJB 2
On Mar 6, 2007, at 11:35 AM, Rick McGuire wrote:
Ok, I think I've run into the first problem area. I'm trying to
translate what's getting done in the TSSLinkBuilder to the new
paradigm, and I've bumped up against a problem straight off. Ok,
you've given me the following with what you've implemented: an
ejbName, a tssBeanName, and a list of jndinames used to publish
this bean to the naming service.
Now in the TSSLinkBuilder, we were operating on the XML for a
single ejb definition, so the ejbName came from the plan naming
context, and was then converted into an AbstractName instance to
complete the GBean wiring. The TSSLinkBuilder code in question
looks like this:
public void buildNaming(XmlObject specDD, XmlObject plan,
Configuration localConfiguration, Configuration
remoteConfiguration, Module module, Map componentContext) throws
DeploymentException {
if (plan == null) {
return;
}
AbstractName ejbName = getGBeanName(componentContext);
where the componentContext is used to retrieve an AbstractName for
this ejb using the simple name contained in the plan. But now
things are inverted in the ModuleBuilderExtension, so I need to map
the simple name retrieved from a tss-link element to the
corresponding AbstractName for the EJB in this module context. How
do I retrieve that information?
The easiest solution would be if the openejb builder could construct
a map of simple name to abstract name (or gbeanData) for the ejbs
it's constructing and put that in the componentContext. It that
isn't practical we can figure out enough of the name to construct an
abstract name query to find the ejb at runtime. You can figure out
all of the ejb name except the j2eeType from the module name and ejb
name and by using an interface query we can be sure we're getting
some kind of ejb. If this doesn't make sense let me know and I'll
come up with something more detailed.
Secondly, TSSLinkBuilder uses the module URI for the first attempt
at resolving the TSSBean information. Here's the code:
URI moduleURI = module.getModuleURI();
String moduleString = moduleURI == null ? null :
moduleURI.toString();
AbstractNameQuery tssBeanName =
ENCConfigBuilder.buildAbstractNameQuery(null, moduleString,
tssLink, NameFactory.EJB_MODULE, NameFactory.EJB_MODULE);
If this fails, than it tries again without the module name. Is
this still a correct usage, or is there something else that should
be used here?
I think this is still correct. First we look for a tss bean in the
same module, then we look for one in the set of ancestors.
thanks
david jencks
Rick
David Blevins wrote:
On Feb 28, 2007, at 3:29 AM, Rick McGuire wrote:
David Blevins wrote:
On Feb 27, 2007, at 4:39 PM, Rick McGuire wrote:
David Blevins wrote:
On Feb 27, 2007, at 5:55 AM, Rick McGuire wrote:
I'm about 99.% certain that tss was a very old element
type that was never deleted from the schema. The only one
I'm aware is still getting used is the tss-link, so that
should be the only thing that needs to be added. The tss-
link element is used to hook an ejb instance to the
appropriate POA to export this as a CORBA object. My
experience with schema is pretty limited (i.e., approaching
zero), so any assistance in that phase would be greatly
appreciated.
Ok. How about something like:
tss-link ejb-name= poa-name=/
The only piece of information required is the name of a
TSSBean, assuming all of the same bits of information are still
extractable from the either the plan or other sources. The
current usage is
tss-linktss-bean-nametss-link
I'm not really sure what I'd pick for an attribute name, so
keeping the same syntax is probably easiest.
The two other pieces of information required to complete the
linkage are the EBJ name and the JNDI name(s) this EJB is
registered under. The JNDI names are using to export the EJB
to the CORBA naming service. I assume these same bits of
information are still relevant/available in openejb3.
Couple more questions. Does every ejb in corba need a tss-link
and or tssbean?
Every ejb that's exported via corba will need a tss-link.
Will some ejbs share the same tssbean (i.e. be linked to the
same tss bean)?
Sharing is quite common. The tssbean the ejbs link to determine
the characteristics of the transport and security profile used
for access.
If sharing is there, how common is it to have a second tss bean
(and subsequent links).
I think this is fairly common to have more than one tssbean if
there are multiple security profiles defined. Any given EJB,
however, is only linked to one tssbean at a time.
And finally, where is the tssbean itself configured?
I'm not totally certain I understand the context of this
question. The tssbeans are typically defined in a parent
configuration play for the deployed app. A
Re: [jira] Correct way to get inputstream from message content
I am intending on providing the code to the SM project for their consideration and improvement. Hopefully, I will have it tested out and ready for uploading by the end of this week. I have successfully used servingXml inside of a jbi service unit to convert from a flat file to an xml format. Most of the issues that I have encountered is in my learning of the servingXml 'language'. Thanks, James == Please opensource it! Kind regards Juergen -- View this message in context: http://www.nabble.com/Correct-way-to-get-inputstream-from-message-content-tf3321687s12049.html#a9335669 Sent from the ServiceMix - Dev mailing list archive at Nabble.com.
[jira] Updated: (GERONIMO-2868) Message Driven Beans will not run under the specified run-as Subject
[ https://issues.apache.org/jira/browse/GERONIMO-2868?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aman Nanner updated GERONIMO-2868: -- Attachment: mdb-default-subject-interceptor.patch Ok, here's a first pass at a patch for this issue. It's causing several test failures and errors that I have not yet had a chance to look into. Message Driven Beans will not run under the specified run-as Subject -- Key: GERONIMO-2868 URL: https://issues.apache.org/jira/browse/GERONIMO-2868 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: OpenEJB, security Affects Versions: 1.2 Reporter: Aman Nanner Assigned To: David Jencks Attachments: mdb-default-subject-interceptor.patch, mdb-run-as.patch If a message driven bean is configured with a run-as element, it is being ignored and the message driven bean is not run as the specified Subject. The MDB would be configured in the ejb-jar.xml as follows: message-driven display-nameTestMDB/display-name ejb-nameTestMDB/ejb-name ejb-classcom.acme.ejb.TestMDB/ejb-class transaction-typeBean/transaction-type message-destination-typejavax.jms.Topic/message-destination-type activation-config activation-config-property activation-config-property-nameacknowledgeMode/activation-config-property-name activation-config-property-valueAuto-acknowledge/activation-config-property-value /activation-config-property activation-config-property activation-config-property-namemessageSelector/activation-config-property-name activation-config-property-valueJOB_CODE = 'FOO'/activation-config-property-value /activation-config-property activation-config-property activation-config-property-namesubscriptionDurability/activation-config-property-name activation-config-property-valueNonDurable/activation-config-property-value /activation-config-property /activation-config ejb-ref ejb-ref-nameejb/common/TestEJB/ejb-ref-name ejb-ref-typeSession/ejb-ref-type homecom.acme.ejb.TestHome/home remotecom.acme.ejb.TestRemote/remote ejb-linkTestEJB/ejb-link /ejb-ref security-identity run-as role-nameTESTROLE/role-name /run-as /security-identity /message-driven Upon inspection of the org.apache.openejb.mdb.DefaaultMdbContainer class, it is noted that the EjbRunAsInterceptor is not configured as part of the invocation step (as it is in org.apache.openejb.slsb.DefaultStatelessEjbContainer). Therefore, the run-as Subject is never being set as part of the Caller stack. I added the EjbRunAsInterceptor into the invocation stack and rebuilt Geronimo, but this didn't completely fix the problem. The EjbRunAsInterceptor is now being called, and the Subject is being set as the next caller in the ContextManager's caller stack. However, the EjbIdentityInterceptor runs next, and authorizes the invocation under the current caller, not the next caller. Thus, the run-as Subject does NOT perform the invocation. I'm not sure what the best way is to fix this without impacting everything else. If somebody with more knowledge in this area has a good idea, I can try it and submit a patch. Also note that this problem seems to imply that the run-as functionality wouldn't work with session EJBs either (I haven't tried to verify this). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: ENC (Environment Naming Context) Question
On Mar 6, 2007, at 11:42 AM, Christopher M. Cardona wrote: David Jencks wrote: On Mar 5, 2007, at 4:50 AM, Christopher M. Cardona wrote: Some questions about our ENC implementation: 1. How do we add/create a subcontext for java:comp/env? Do we have an API for doing this? I get javax.naming.OperationNotSupportedException when calling createSubcontext(). Per the spec java:comp is read-only. The content is set up in the NamingBuilders during deployment: we construct a map of stuff, which is turned into a Context using EnterpriseNamingContext.createEnterpriseNamingContext. David, That explains it. Yes, I saw this called while debugging through the deployment of a webapp. Sorry I wasn't asking the right questions. What I was trying to do is bind a resource (e.g. JavaMail Session or JDBC DataSource) to the global jndi during deployment. I think I figured out where to do this during deployment but not exactly sure which context to use for binding. IIUC, we already bind something locally to the ENC so a particular module can have access to it at runtime. But if we wanted another module or even a standalone app (possibly a different jvm) to have access to those resources we need to use the global JNDI. Is my understanding correct? Am I asking the right questions here? :-) Any clarification would help. I think you are on a better track now. Dain implemented some stuff that binds all connection factories to global jndi in the sandbox/plugins/global-jndi/src/main/java/org/apache/geronimo/gjndi/ binding/ResourceBindings.java file and there is some related code there too. There are 2 approaches I can think of for this: one is to automatically bind everything at locations determined from their gbean name, and the other is to only bind specially marked gbeans. Dain took the first approach and I think it would be reasonable to start by resurrecting it and making it work. I think there's something wrong with the current code because IIRC someone tried to use it in a 1.2 snapshot server and it didn't work. However it should be fairly easy to get it working again. At that point we'll have something working, you'll know how the pieces fit together, and we can see if we like it and if we want more flexibility. thanks david jencks Thanks, chris
Re: EJB and JAX-WS
David, 1) OpenEJB must recognize and inject @Resource WebServiceContext resource. This is like the EJBContext object I think (not looked up in JNDI and there is no DD XML for it). So somehow we must be able to pass WebServiceContext implementation from within Geronimo to the EJB container. Maybe somehow through the EjbDeployment object. Sure. What do we have in place for processing @Resource WebServiceContext for Servlets? Should be easy to figure out how to do it on the EJB side based on what's done in the Servlet side. For POJO-based web services we have a separate @Resource injector. It basically just checks the type of @Resource annotation and if it is of WebServiceContext type, an instance of that type is returned otherwise JNDI lookup is done. See JAXWSResourceAnnotationHandler class in http://svn.apache.org/viewvc/geronimo/server/trunk/modules/geronimo-jaxws/src/main/java/org/apache/geronimo/jaxws/JAXWSAnnotationProcessor.java?view=markup 2) The InvocationContext.getContextData() must return the same exact Map object as WebServiceContext.getMessageContext() returns. I think this just pretty much depends on 1). Good info. I'm not really following the new web service stuff, so if you run into more requirements like this definitely continue to post. Sure. Jarek
Re: anyone able to run geronimo\testsuite?
Thanks for the hint. Rebuild maven-plugins only didn't work, so I cleaned out my m2 repo and rebuild geronimo. I can run the testsuite now. Lin Prasad Kashyap wrote: Sorry Donald. You are right. That is what I meant. Cheers Prasad On 3/6/07, Donald Woods [EMAIL PROTECTED] wrote: Did you mean asf/geronimo/server/trunk/maven-plugins? There is a asf/geronimo/plugins, but it only has a Spring plugin available right now -Donald Prasad Kashyap wrote: Guess you have cleaned your local repo in the interim. Go to geronimo/plugins and build the plugins there. Cheers Prasad On 3/6/07, Lin Sun [EMAIL PROTECTED] wrote: Hi there, I am having trouble to run the jaxws-war testsuite. So i went to its parent directory testsuite and found I could not run any testsuite from there either. This was working yesterday PM.:-( Can someone shed some light on this? e:\geronimolatest2\testsuitemvn install [INFO] Scanning for projects... [INFO] Reactor build order: [INFO] Geronimo TestSuite [INFO] Geronimo TestSuite :: Console Testsuite [INFO] Geronimo TestSuite :: Deployment Testsuite [INFO] Geronimo TestSuite :: Enterprise Testsuite [INFO] Geronimo TestSuite :: Web-tier Testsuite [INFO] Geronimo TestSuite :: WebServices TestSuite [INFO] - --- [INFO] Building Geronimo TestSuite [INFO]task-segment: [install] [INFO] - --- [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Error building POM (may not be this project's POM). Project ID: null:testsuite-maven-plugin:maven-plugin:null Reason: Cannot find parent: org.apache.geronimo.plugins:maven-plugins for projec t: null:testsuite-maven-plugin:maven-plugin:null [INFO] [INFO] For more information, run Maven with the -e switch [INFO] [INFO] Total time: 3 seconds [INFO] Finished at: Tue Mar 06 10:44:48 EST 2007 [INFO] Final Memory: 5M/9M [INFO] Lin
[jira] Created: (GERONIMO-2937) clean up geronimo-openejb geronimo-dependency.xml
clean up geronimo-openejb geronimo-dependency.xml - Key: GERONIMO-2937 URL: https://issues.apache.org/jira/browse/GERONIMO-2937 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Affects Versions: 2.0-M3 Reporter: David Jencks Fix For: 2.0-beta1 At least the geronimo-openejb geronimo-dependency.xml needs to be drastically cleaned up. Guidelines for when to put a dependency in geronimo-dependency.xml rather than a config dependency: - If the jar is something that will ONLY be used by the jar being built or things that MUST use the jar being built and there is NO CHANCE anyone else will want to use the jar put it in geronimo-dependency.xml. Typical examples of this are when you are integrating an external project such as jetty, tomcat, or openejb. Generally it is not appropriate to put a library in geronimo-dependency.xml since someone else might want to use it but not your jar. - In all other cases but the dependency in a config.Put it in the config that you think everyone who wants to use the jar will depend on, not necessarily in the config that depends on the jar you are building. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-2868) Message Driven Beans will not run under the specified run-as Subject
[ https://issues.apache.org/jira/browse/GERONIMO-2868?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12478515 ] Aman Nanner commented on GERONIMO-2868: --- Ok, that patch actually worked! My test failures were due to a locked file, and not due to my change. I've tested this and my MDB now runs with the default subject, and thus, the EjbRunAsInterceptor works properly. Message Driven Beans will not run under the specified run-as Subject -- Key: GERONIMO-2868 URL: https://issues.apache.org/jira/browse/GERONIMO-2868 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: OpenEJB, security Affects Versions: 1.2 Reporter: Aman Nanner Assigned To: David Jencks Attachments: mdb-default-subject-interceptor.patch, mdb-run-as.patch If a message driven bean is configured with a run-as element, it is being ignored and the message driven bean is not run as the specified Subject. The MDB would be configured in the ejb-jar.xml as follows: message-driven display-nameTestMDB/display-name ejb-nameTestMDB/ejb-name ejb-classcom.acme.ejb.TestMDB/ejb-class transaction-typeBean/transaction-type message-destination-typejavax.jms.Topic/message-destination-type activation-config activation-config-property activation-config-property-nameacknowledgeMode/activation-config-property-name activation-config-property-valueAuto-acknowledge/activation-config-property-value /activation-config-property activation-config-property activation-config-property-namemessageSelector/activation-config-property-name activation-config-property-valueJOB_CODE = 'FOO'/activation-config-property-value /activation-config-property activation-config-property activation-config-property-namesubscriptionDurability/activation-config-property-name activation-config-property-valueNonDurable/activation-config-property-value /activation-config-property /activation-config ejb-ref ejb-ref-nameejb/common/TestEJB/ejb-ref-name ejb-ref-typeSession/ejb-ref-type homecom.acme.ejb.TestHome/home remotecom.acme.ejb.TestRemote/remote ejb-linkTestEJB/ejb-link /ejb-ref security-identity run-as role-nameTESTROLE/role-name /run-as /security-identity /message-driven Upon inspection of the org.apache.openejb.mdb.DefaaultMdbContainer class, it is noted that the EjbRunAsInterceptor is not configured as part of the invocation step (as it is in org.apache.openejb.slsb.DefaultStatelessEjbContainer). Therefore, the run-as Subject is never being set as part of the Caller stack. I added the EjbRunAsInterceptor into the invocation stack and rebuilt Geronimo, but this didn't completely fix the problem. The EjbRunAsInterceptor is now being called, and the Subject is being set as the next caller in the ContextManager's caller stack. However, the EjbIdentityInterceptor runs next, and authorizes the invocation under the current caller, not the next caller. Thus, the run-as Subject does NOT perform the invocation. I'm not sure what the best way is to fix this without impacting everything else. If somebody with more knowledge in this area has a good idea, I can try it and submit a patch. Also note that this problem seems to imply that the run-as functionality wouldn't work with session EJBs either (I haven't tried to verify this). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
SAAJ integration help
I started looking into SAAJ integration. And that appears to be a much more work than I initially thought. Here's the background info. In Java EE 5 we have to support both JAX-RPC and JAX-WS web services (both might be deployed in the same module). Right now JAX-RPC support is provided by Axis1 and JAX-WS support is provided by either Axis2 or CXF. Both JAX-RPC and JAX-WS endpoints must support SAAJ. Both Axis1 and Axis2 have their own implementations of the SAAJ API. Axis1 implements SAAJ 1.1/1.2 and Axis2 implements SAAJ 1.3. CXF uses Glassfish 1.3 implementation. My initial idea was to use Axis2 SAAJ for Axis2/Axis1 assembly and Glassfish SAAJ for CXF/Axis1 assembly. However, I'm not sure what would be the effects on Axis1 when Axis2 or Glassfish SAAJ implementation is used because I think Axis1 expects its own SAAJ implementation. So things might just blow up in this case. I also assume that we will need to update Axis1 code to implement the SAAJ 1.3 API (e.g. to throw OperationUnsupportedException(), etc.) Assuming things do blow up what are our options for supporting two different SAAJ implementations? Or do we need one common SAAJ implementation? I have an idea how maybe we can support two different SAAJ implementations by setting a context classloader to force a given implementation to be used but I'm not sure how reliable it will be. Jarek
Re: ServiceMix Console!
The servicemix-console provides a way to: * install / uninstall / start / stop components, service assemblies and shared libraries. * view details on SA, SU, SL, components * view JBI endpoints with their WSDL if any * start / stop the JDBC auditor if configured, view the JBI exchanges * view the flow of JBI exchanges between endpoints If can be used with any JBI container (it must be on the same computer to be able to deploy JBI artifacts). Currently, it connects to ServiceMix standalone without any configuration. If you need to connect to a ServiceMix running in JBoss, you may need to adjust the properties used to connect to the JMX connector. The apache-servicemix-web distribution provides an embedded ServiceMix instance in addition to the console, so that you can deploy both on any servlet container easily. On 3/6/07, goldi [EMAIL PROTECTED] wrote: Hy, can someone tell which features ServiceMix Console provides? Can I also use it, if I use ServiceMix in combination with JBoss? greets Goldi -- View this message in context: http://www.nabble.com/ServiceMix-Console%21-tf3356276s12049.html#a9334434 Sent from the ServiceMix - Dev mailing list archive at Nabble.com. -- Cheers, Guillaume Nodet Architect, LogicBlaze (http://www.logicblaze.com/) Blog: http://gnodet.blogspot.com/
[jira] Commented: (SM-867) Cannot add soap header in JSR181 component
[ https://issues.apache.org/activemq/browse/SM-867?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_38673 ] Guillaume Nodet commented on SM-867: Author: gnodet Date: Tue Mar 6 11:32:20 2007 New Revision: 515265 URL: http://svn.apache.org/viewvc?view=revrev=515265 Log: SM-867: Cannot add soap headers in JSR181 component Modified: incubator/servicemix/trunk/deployables/serviceengines/servicemix-jsr181/src/main/java/org/apache/servicemix/jsr181/Jsr181ExchangeProcessor.java Author: gnodet Date: Tue Mar 6 11:34:34 2007 New Revision: 515266 URL: http://svn.apache.org/viewvc?view=revrev=515266 Log: SM-867: Cannot add soap headers in JSR181 component Modified: incubator/servicemix/branches/servicemix-3.1/deployables/serviceengines/servicemix-jsr181/src/main/java/org/apache/servicemix/jsr181/Jsr181ExchangeProcessor.java Cannot add soap header in JSR181 component -- Key: SM-867 URL: https://issues.apache.org/activemq/browse/SM-867 Project: ServiceMix Issue Type: Bug Components: servicemix-jsr181 Environment: ServiceMix 3.2 under Windows XP Reporter: Phu Quyen Le I would like to add some properties in the soap header of the message in a jsr181 component. But I can't do because of the following problem: Started from the example wsdl-first of ServiceMix, I've modified the file PersonImpl.java as follow: ... InOut exchange = (InOut) JBIContext.getMessageExchange(); Normalizedmessage outMsg = exchange.createMessage(); outMsg.setProperty(JbiConstants.SOAP_HEADERS, headers); exchange.setOutMessage(outMsg); GetPersonResponse response = new GetPersonResponse(); return response; ... I received then the follwing exception message: java.lang.Exception: javax.jbi.messaging.MessagingException: Out message is already set. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SM-867) Cannot add soap header in JSR181 component
[ https://issues.apache.org/activemq/browse/SM-867?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guillaume Nodet updated SM-867: --- Fix Version/s: 3.2 3.1.1 Assignee: Guillaume Nodet Cannot add soap header in JSR181 component -- Key: SM-867 URL: https://issues.apache.org/activemq/browse/SM-867 Project: ServiceMix Issue Type: Bug Components: servicemix-jsr181 Environment: ServiceMix 3.2 under Windows XP Reporter: Phu Quyen Le Assigned To: Guillaume Nodet Fix For: 3.1.1, 3.2 I would like to add some properties in the soap header of the message in a jsr181 component. But I can't do because of the following problem: Started from the example wsdl-first of ServiceMix, I've modified the file PersonImpl.java as follow: ... InOut exchange = (InOut) JBIContext.getMessageExchange(); Normalizedmessage outMsg = exchange.createMessage(); outMsg.setProperty(JbiConstants.SOAP_HEADERS, headers); exchange.setOutMessage(outMsg); GetPersonResponse response = new GetPersonResponse(); return response; ... I received then the follwing exception message: java.lang.Exception: javax.jbi.messaging.MessagingException: Out message is already set. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-2916) database creation pool wizzard fails to deploy
[ https://issues.apache.org/jira/browse/GERONIMO-2916?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12478534 ] Anita Kulshreshtha commented on GERONIMO-2916: -- After adding the following to PersistenceUnitBuilder.build(..) if (container == null) return; I was able to deploy on jetty server from command line. Could someone familiar with this code please explain why container is null.. database creation pool wizzard fails to deploy -- Key: GERONIMO-2916 URL: https://issues.apache.org/jira/browse/GERONIMO-2916 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: console, databases Affects Versions: 2.0-M2, 2.0-M3 Environment: relates to GERONIMO-2686 Reporter: Hernan Cunico From the console, the database creation pool wizzard does not create a plan and fails to deploy it with no warnings on the Administration Console. Similar error conditions were reported in GERONIMO-2686 The terminal shows the following error: 15:07:55,562 ERROR [DatabasePoolPortlet] Unable to save connection pool javax.enterprise.deploy.spi.exceptions.InvalidModuleException: No configurer for module type: rar registered at org.apache.geronimo.deployment.plugin.jmx.JMXDeploymentManager.createConfiguration(JMXDeploymentManager.java:302) at org.apache.geronimo.console.databasemanager.wizard.DatabasePoolPortlet.save(DatabasePoolPortlet.java:880) at org.apache.geronimo.console.databasemanager.wizard.DatabasePoolPortlet.processAction(DatabasePoolPortlet.java:343) at org.apache.pluto.core.PortletServlet.dispatch(PortletServlet.java:229) at org.apache.pluto.core.PortletServlet.doPost(PortletServlet.java:163) at javax.servlet.http.HttpServlet.service(HttpServlet.java:713) at javax.servlet.http.HttpServlet.service(HttpServlet.java:806) at org.apache.pluto.core.PortletServlet.service(PortletServlet.java:153) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:687) at org.apache.catalina.core.ApplicationDispatcher.doInclude(ApplicationDispatcher.java:590) at org.apache.catalina.core.ApplicationDispatcher.include(ApplicationDispatcher.java:505) at org.apache.pluto.invoker.impl.PortletInvokerImpl.invoke(PortletInvokerImpl.java:120) at org.apache.pluto.invoker.impl.PortletInvokerImpl.action(PortletInvokerImpl.java:68) at org.apache.pluto.PortletContainerImpl.processPortletAction(PortletContainerImpl.java:164) at org.apache.pluto.portalImpl.core.PortletContainerWrapperImpl.processPortletAction(PortletContainerWrapperImpl.java:82) at org.apache.pluto.portalImpl.Servlet.doGet(Servlet.java:227) at org.apache.pluto.portalImpl.Servlet.doPost(Servlet.java:267) at javax.servlet.http.HttpServlet.service(HttpServlet.java:713) at javax.servlet.http.HttpServlet.service(HttpServlet.java:806) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:228) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175) at org.apache.geronimo.tomcat.valve.DefaultSubjectValve.invoke(DefaultSubjectValve.java:56) at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:525) at org.apache.geronimo.tomcat.GeronimoStandardContext$SystemMethodValve.invoke(GeronimoStandardContext.java:338) at org.apache.geronimo.tomcat.valve.GeronimoBeforeAfterValve.invoke(GeronimoBeforeAfterValve.java:47) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:517) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:212) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:844) at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:634) at
SPECjAppServer2004 v1.08 with research mode is released!
Hi, all, I'm happy to announce that the new version of SPECjAppServer2004 (1.08) is released, and includes changes allowing publishing results in open source. SjAS2004 1.08 includes a special research mode workload called EAStress2004 that has a different metric but allows SjAS licensees to publish results for open source products having no J2EE certification and without the results being reviewed by SPEC. This allows for projects like Geronimo to effectively use that workload for testing and discovering performance issues. Here's the press-release: http://www.spec.org/jAppServer2004/jAppServer2004v108.html Vasily Zakharov Intel ESSD
[jira] Commented: (GERONIMO-2916) database creation pool wizzard fails to deploy
[ https://issues.apache.org/jira/browse/GERONIMO-2916?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12478539 ] Anita Kulshreshtha commented on GERONIMO-2916: -- I was able to deploy on tomcat server also from command line after making the change described above. database creation pool wizzard fails to deploy -- Key: GERONIMO-2916 URL: https://issues.apache.org/jira/browse/GERONIMO-2916 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: console, databases Affects Versions: 2.0-M2, 2.0-M3 Environment: relates to GERONIMO-2686 Reporter: Hernan Cunico From the console, the database creation pool wizzard does not create a plan and fails to deploy it with no warnings on the Administration Console. Similar error conditions were reported in GERONIMO-2686 The terminal shows the following error: 15:07:55,562 ERROR [DatabasePoolPortlet] Unable to save connection pool javax.enterprise.deploy.spi.exceptions.InvalidModuleException: No configurer for module type: rar registered at org.apache.geronimo.deployment.plugin.jmx.JMXDeploymentManager.createConfiguration(JMXDeploymentManager.java:302) at org.apache.geronimo.console.databasemanager.wizard.DatabasePoolPortlet.save(DatabasePoolPortlet.java:880) at org.apache.geronimo.console.databasemanager.wizard.DatabasePoolPortlet.processAction(DatabasePoolPortlet.java:343) at org.apache.pluto.core.PortletServlet.dispatch(PortletServlet.java:229) at org.apache.pluto.core.PortletServlet.doPost(PortletServlet.java:163) at javax.servlet.http.HttpServlet.service(HttpServlet.java:713) at javax.servlet.http.HttpServlet.service(HttpServlet.java:806) at org.apache.pluto.core.PortletServlet.service(PortletServlet.java:153) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:687) at org.apache.catalina.core.ApplicationDispatcher.doInclude(ApplicationDispatcher.java:590) at org.apache.catalina.core.ApplicationDispatcher.include(ApplicationDispatcher.java:505) at org.apache.pluto.invoker.impl.PortletInvokerImpl.invoke(PortletInvokerImpl.java:120) at org.apache.pluto.invoker.impl.PortletInvokerImpl.action(PortletInvokerImpl.java:68) at org.apache.pluto.PortletContainerImpl.processPortletAction(PortletContainerImpl.java:164) at org.apache.pluto.portalImpl.core.PortletContainerWrapperImpl.processPortletAction(PortletContainerWrapperImpl.java:82) at org.apache.pluto.portalImpl.Servlet.doGet(Servlet.java:227) at org.apache.pluto.portalImpl.Servlet.doPost(Servlet.java:267) at javax.servlet.http.HttpServlet.service(HttpServlet.java:713) at javax.servlet.http.HttpServlet.service(HttpServlet.java:806) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:228) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175) at org.apache.geronimo.tomcat.valve.DefaultSubjectValve.invoke(DefaultSubjectValve.java:56) at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:525) at org.apache.geronimo.tomcat.GeronimoStandardContext$SystemMethodValve.invoke(GeronimoStandardContext.java:338) at org.apache.geronimo.tomcat.valve.GeronimoBeforeAfterValve.invoke(GeronimoBeforeAfterValve.java:47) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:517) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:212) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:844) at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:634) at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:445) at java.lang.Thread.run(Thread.java:595) 15:08:02,875 ERROR [DatabasePoolPortlet] Unable to save connection pool
Re: SAAJ integration help
Axis1 will not work with an external SAAJ implementation or API. Not sure if we can update the API in Axis1 because then it will fail the jax-rpc signature tests. thanks, dims On 3/6/07, Jarek Gawor [EMAIL PROTECTED] wrote: I started looking into SAAJ integration. And that appears to be a much more work than I initially thought. Here's the background info. In Java EE 5 we have to support both JAX-RPC and JAX-WS web services (both might be deployed in the same module). Right now JAX-RPC support is provided by Axis1 and JAX-WS support is provided by either Axis2 or CXF. Both JAX-RPC and JAX-WS endpoints must support SAAJ. Both Axis1 and Axis2 have their own implementations of the SAAJ API. Axis1 implements SAAJ 1.1/1.2 and Axis2 implements SAAJ 1.3. CXF uses Glassfish 1.3 implementation. My initial idea was to use Axis2 SAAJ for Axis2/Axis1 assembly and Glassfish SAAJ for CXF/Axis1 assembly. However, I'm not sure what would be the effects on Axis1 when Axis2 or Glassfish SAAJ implementation is used because I think Axis1 expects its own SAAJ implementation. So things might just blow up in this case. I also assume that we will need to update Axis1 code to implement the SAAJ 1.3 API (e.g. to throw OperationUnsupportedException(), etc.) Assuming things do blow up what are our options for supporting two different SAAJ implementations? Or do we need one common SAAJ implementation? I have an idea how maybe we can support two different SAAJ implementations by setting a context classloader to force a given implementation to be used but I'm not sure how reliable it will be. Jarek -- Davanum Srinivas :: http://wso2.org/ :: Oxygen for Web Services Developers
Re: SAAJ integration help
Why wouldn't Axis1 work with a newer version of SAAJ AP? That is, leave Axis1' SAAJ API as is, but update the implementation to implement the new SAAJ 1.3 methods. In Geronimo we would run with Axis2 SAAJ 1.3 API and with updated Axis1 implementation. Jarek On 3/6/07, Davanum Srinivas [EMAIL PROTECTED] wrote: Axis1 will not work with an external SAAJ implementation or API. Not sure if we can update the API in Axis1 because then it will fail the jax-rpc signature tests. thanks, dims On 3/6/07, Jarek Gawor [EMAIL PROTECTED] wrote: I started looking into SAAJ integration. And that appears to be a much more work than I initially thought. Here's the background info. In Java EE 5 we have to support both JAX-RPC and JAX-WS web services (both might be deployed in the same module). Right now JAX-RPC support is provided by Axis1 and JAX-WS support is provided by either Axis2 or CXF. Both JAX-RPC and JAX-WS endpoints must support SAAJ. Both Axis1 and Axis2 have their own implementations of the SAAJ API. Axis1 implements SAAJ 1.1/1.2 and Axis2 implements SAAJ 1.3. CXF uses Glassfish 1.3 implementation. My initial idea was to use Axis2 SAAJ for Axis2/Axis1 assembly and Glassfish SAAJ for CXF/Axis1 assembly. However, I'm not sure what would be the effects on Axis1 when Axis2 or Glassfish SAAJ implementation is used because I think Axis1 expects its own SAAJ implementation. So things might just blow up in this case. I also assume that we will need to update Axis1 code to implement the SAAJ 1.3 API (e.g. to throw OperationUnsupportedException(), etc.) Assuming things do blow up what are our options for supporting two different SAAJ implementations? Or do we need one common SAAJ implementation? I have an idea how maybe we can support two different SAAJ implementations by setting a context classloader to force a given implementation to be used but I'm not sure how reliable it will be. Jarek -- Davanum Srinivas :: http://wso2.org/ :: Oxygen for Web Services Developers
Re: SAAJ integration help
Worth a shot trying! There are new classes in SAAJ 1.3 that need to be implemented as well. -- dims On 3/6/07, Jarek Gawor [EMAIL PROTECTED] wrote: Why wouldn't Axis1 work with a newer version of SAAJ AP? That is, leave Axis1' SAAJ API as is, but update the implementation to implement the new SAAJ 1.3 methods. In Geronimo we would run with Axis2 SAAJ 1.3 API and with updated Axis1 implementation. Jarek On 3/6/07, Davanum Srinivas [EMAIL PROTECTED] wrote: Axis1 will not work with an external SAAJ implementation or API. Not sure if we can update the API in Axis1 because then it will fail the jax-rpc signature tests. thanks, dims On 3/6/07, Jarek Gawor [EMAIL PROTECTED] wrote: I started looking into SAAJ integration. And that appears to be a much more work than I initially thought. Here's the background info. In Java EE 5 we have to support both JAX-RPC and JAX-WS web services (both might be deployed in the same module). Right now JAX-RPC support is provided by Axis1 and JAX-WS support is provided by either Axis2 or CXF. Both JAX-RPC and JAX-WS endpoints must support SAAJ. Both Axis1 and Axis2 have their own implementations of the SAAJ API. Axis1 implements SAAJ 1.1/1.2 and Axis2 implements SAAJ 1.3. CXF uses Glassfish 1.3 implementation. My initial idea was to use Axis2 SAAJ for Axis2/Axis1 assembly and Glassfish SAAJ for CXF/Axis1 assembly. However, I'm not sure what would be the effects on Axis1 when Axis2 or Glassfish SAAJ implementation is used because I think Axis1 expects its own SAAJ implementation. So things might just blow up in this case. I also assume that we will need to update Axis1 code to implement the SAAJ 1.3 API (e.g. to throw OperationUnsupportedException(), etc.) Assuming things do blow up what are our options for supporting two different SAAJ implementations? Or do we need one common SAAJ implementation? I have an idea how maybe we can support two different SAAJ implementations by setting a context classloader to force a given implementation to be used but I'm not sure how reliable it will be. Jarek -- Davanum Srinivas :: http://wso2.org/ :: Oxygen for Web Services Developers -- Davanum Srinivas :: http://wso2.org/ :: Oxygen for Web Services Developers
Re: svn commit: r513066 - in /geronimo/server/trunk/modules: geronimo-kernel/src/main/java/org/apache/geronimo/kernel/log/ geronimo-system/src/main/java/org/apache/geronimo/system/logging/log4j/ geron
Ya, this should go to 1.2... will have a peek at it later today.
--jason
On Mar 5, 2007, at 10:06 PM, Kevan Miller wrote:
Jason,
Thoughts on getting this into 1.2 (or at least part)? In
particular, stop printing the environment information to STDOUT
during startup...
--kevan
On Feb 28, 2007, at 6:38 PM, [EMAIL PROTECTED] wrote:
Author: jdillon
Date: Wed Feb 28 15:38:38 2007
New Revision: 513066
URL: http://svn.apache.org/viewvc?view=revrev=513066
Log:
(GERONIMO-2741) Clean up logging output on console
Modified:
geronimo/server/trunk/modules/geronimo-kernel/src/main/java/
org/apache/geronimo/kernel/log/GeronimoLogging.java
geronimo/server/trunk/modules/geronimo-system/src/main/java/
org/apache/geronimo/system/logging/log4j/Log4jService.java
geronimo/server/trunk/modules/geronimo-system/src/main/java/
org/apache/geronimo/system/main/Daemon.java
Modified: geronimo/server/trunk/modules/geronimo-kernel/src/main/
java/org/apache/geronimo/kernel/log/GeronimoLogging.java
URL: http://svn.apache.org/viewvc/geronimo/server/trunk/modules/
geronimo-kernel/src/main/java/org/apache/geronimo/kernel/log/
GeronimoLogging.java?view=diffrev=513066r1=513065r2=513066
=
=
--- geronimo/server/trunk/modules/geronimo-kernel/src/main/java/
org/apache/geronimo/kernel/log/GeronimoLogging.java (original)
+++ geronimo/server/trunk/modules/geronimo-kernel/src/main/java/
org/apache/geronimo/kernel/log/GeronimoLogging.java Wed Feb 28
15:38:38 2007
@@ -55,7 +55,12 @@
// force the log factory to initialize
LogFactory.getLog(GeronimoLogging.class);
-
+
+//
+// FIXME: Replace the bits below with this:
+//
+// System.setProperty(mx4j.log.prototype,
mx4j.log.CommonsLogger);
+
// force mx4j to use commons logging
// Use reflection so mx4j is not required (this is
important in JDK 1.5)
// mx4j.log.Log.redirectTo(new mx4j.log.CommonsLogger
());
Modified: geronimo/server/trunk/modules/geronimo-system/src/main/
java/org/apache/geronimo/system/logging/log4j/Log4jService.java
URL: http://svn.apache.org/viewvc/geronimo/server/trunk/modules/
geronimo-system/src/main/java/org/apache/geronimo/system/logging/
log4j/Log4jService.java?view=diffrev=513066r1=513065r2=513066
=
=
--- geronimo/server/trunk/modules/geronimo-system/src/main/java/
org/apache/geronimo/system/logging/log4j/Log4jService.java (original)
+++ geronimo/server/trunk/modules/geronimo-system/src/main/java/
org/apache/geronimo/system/logging/log4j/Log4jService.java Wed Feb
28 15:38:38 2007
@@ -512,6 +512,8 @@
File file = resolveConfigurationFile();
if (file == null || !file.exists()) {
return;
+} else {
+lastChanged = file.lastModified();
}
// Record the default console log level
@@ -552,23 +554,8 @@
public void doStart() {
LogFactory logFactory = LogFactory.getFactory();
if (logFactory instanceof GeronimoLogFactory) {
-synchronized (this) {
-timer = new Timer(true);
-
-// Periodically check the configuration file
-schedule();
-
-// Make sure the root Logger has loaded
-Logger logger = LogManager.getRootLogger();
-
-reconfigure();
-
-File file = resolveConfigurationFile();
-if (file != null) {
-lastChanged = file.lastModified();
-}
-logEnvInfo(logger);
-}
+// Make sure the root Logger has loaded
+Logger logger = LogManager.getRootLogger();
// Change all of the loggers over to use log4j
GeronimoLogFactory geronimoLogFactory =
(GeronimoLogFactory) logFactory;
@@ -577,6 +564,17 @@
geronimoLogFactory.setLogFactory(new
CachingLog4jLogFactory());
}
}
+
+synchronized (this) {
+reconfigure();
+
+timer = new Timer(true);
+
+// Periodically check the configuration file
+schedule();
+}
+
+logEnvInfo();
}
synchronized (this) {
@@ -608,8 +606,9 @@
}
}
-private void logEnvInfo(Logger log) {
+private void logEnvInfo() {
try {
+ Log log = LogFactory.getLog(Log4jService.class);
log.info
(--);
log.info(Started Logging Service);
log.debug(Log4jService created with configFileName= +
this.configurationFile +
@@ -640,9 +639,7 @@
log.info( System property [sun.boot.class.path] = +
System.getProperty(sun.boot.class.path));
log.info
[jira] Commented: (GERONIMO-2916) database creation pool wizzard fails to deploy
[ https://issues.apache.org/jira/browse/GERONIMO-2916?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12478577 ] David Jencks commented on GERONIMO-2916: Container being null means that the caller has a bug. I suspect this comes from Gianny's work to deploy ear scoped persistence units. database creation pool wizzard fails to deploy -- Key: GERONIMO-2916 URL: https://issues.apache.org/jira/browse/GERONIMO-2916 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: console, databases Affects Versions: 2.0-M2, 2.0-M3 Environment: relates to GERONIMO-2686 Reporter: Hernan Cunico From the console, the database creation pool wizzard does not create a plan and fails to deploy it with no warnings on the Administration Console. Similar error conditions were reported in GERONIMO-2686 The terminal shows the following error: 15:07:55,562 ERROR [DatabasePoolPortlet] Unable to save connection pool javax.enterprise.deploy.spi.exceptions.InvalidModuleException: No configurer for module type: rar registered at org.apache.geronimo.deployment.plugin.jmx.JMXDeploymentManager.createConfiguration(JMXDeploymentManager.java:302) at org.apache.geronimo.console.databasemanager.wizard.DatabasePoolPortlet.save(DatabasePoolPortlet.java:880) at org.apache.geronimo.console.databasemanager.wizard.DatabasePoolPortlet.processAction(DatabasePoolPortlet.java:343) at org.apache.pluto.core.PortletServlet.dispatch(PortletServlet.java:229) at org.apache.pluto.core.PortletServlet.doPost(PortletServlet.java:163) at javax.servlet.http.HttpServlet.service(HttpServlet.java:713) at javax.servlet.http.HttpServlet.service(HttpServlet.java:806) at org.apache.pluto.core.PortletServlet.service(PortletServlet.java:153) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:687) at org.apache.catalina.core.ApplicationDispatcher.doInclude(ApplicationDispatcher.java:590) at org.apache.catalina.core.ApplicationDispatcher.include(ApplicationDispatcher.java:505) at org.apache.pluto.invoker.impl.PortletInvokerImpl.invoke(PortletInvokerImpl.java:120) at org.apache.pluto.invoker.impl.PortletInvokerImpl.action(PortletInvokerImpl.java:68) at org.apache.pluto.PortletContainerImpl.processPortletAction(PortletContainerImpl.java:164) at org.apache.pluto.portalImpl.core.PortletContainerWrapperImpl.processPortletAction(PortletContainerWrapperImpl.java:82) at org.apache.pluto.portalImpl.Servlet.doGet(Servlet.java:227) at org.apache.pluto.portalImpl.Servlet.doPost(Servlet.java:267) at javax.servlet.http.HttpServlet.service(HttpServlet.java:713) at javax.servlet.http.HttpServlet.service(HttpServlet.java:806) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:228) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175) at org.apache.geronimo.tomcat.valve.DefaultSubjectValve.invoke(DefaultSubjectValve.java:56) at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:525) at org.apache.geronimo.tomcat.GeronimoStandardContext$SystemMethodValve.invoke(GeronimoStandardContext.java:338) at org.apache.geronimo.tomcat.valve.GeronimoBeforeAfterValve.invoke(GeronimoBeforeAfterValve.java:47) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:517) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:212) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:844) at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:634) at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:445) at java.lang.Thread.run(Thread.java:595) 15:08:02,875 ERROR [DatabasePoolPortlet] Unable to
Re: svn commit: r515107 - in /geronimo/server/trunk: configs/j2ee-deployer/src/plan/ modules/geronimo-connector-builder/src/test/java/org/apache/geronimo/connector/deployment/ modules/geronimo-j2ee-bu
Gianny, This appears to be breaking deployment of applications for the TCK (NPEs ... see below). Once I locally reverted this change things started working again. Please see details on the tck list with subject All deployments failing on 2.0 tck). Deployer operation failed: java.lang.NullPointerException org.apache.geronimo.common.DeploymentException: java.lang.NullPointerException at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:383) at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:124) 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:127) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:855) Thanks, Joe [EMAIL PROTECTED] wrote: Author: gdamour Date: Tue Mar 6 04:48:28 2007 New Revision: 515107 URL: http://svn.apache.org/viewvc?view=revrev=515107 Log: Process persistence units located in the EAR library folder. This fixes GERONIMO-2928 - PersistenceUnit located in the EAR library directory is not yet implemented Modified: geronimo/server/trunk/configs/j2ee-deployer/src/plan/plan.xml geronimo/server/trunk/modules/geronimo-connector-builder/src/test/java/org/apache/geronimo/connector/deployment/ConnectorModuleBuilderTest.java geronimo/server/trunk/modules/geronimo-j2ee-builder/src/main/java/org/apache/geronimo/j2ee/deployment/EARConfigBuilder.java geronimo/server/trunk/modules/geronimo-j2ee-builder/src/test/java/org/apache/geronimo/j2ee/deployment/EARConfigBuilderTestSupport.java Modified: geronimo/server/trunk/configs/j2ee-deployer/src/plan/plan.xml URL: http://svn.apache.org/viewvc/geronimo/server/trunk/configs/j2ee-deployer/src/plan/plan.xml?view=diffrev=515107r1=515106r2=515107 == --- geronimo/server/trunk/configs/j2ee-deployer/src/plan/plan.xml (original) +++ geronimo/server/trunk/configs/j2ee-deployer/src/plan/plan.xml Tue Mar 6 04:48:28 2007 @@ -39,6 +39,11 @@ reference name=ServiceBuilders nameGBeanBuilder/name /reference +references name=PersistenceUnitBuilders +pattern +namePersistenceUnitBuilder/name +/pattern +/references references name=EJBConfigBuilder pattern nameEJBBuilder/name Modified: geronimo/server/trunk/modules/geronimo-connector-builder/src/test/java/org/apache/geronimo/connector/deployment/ConnectorModuleBuilderTest.java URL: http://svn.apache.org/viewvc/geronimo/server/trunk/modules/geronimo-connector-builder/src/test/java/org/apache/geronimo/connector/deployment/ConnectorModuleBuilderTest.java?view=diffrev=515107r1=515106r2=515107 == --- geronimo/server/trunk/modules/geronimo-connector-builder/src/test/java/org/apache/geronimo/connector/deployment/ConnectorModuleBuilderTest.java (original) +++ geronimo/server/trunk/modules/geronimo-connector-builder/src/test/java/org/apache/geronimo/connector/deployment/ConnectorModuleBuilderTest.java Tue Mar 6 04:48:28 2007 @@ -153,6 +153,7 @@ null, null, serviceBuilder, +null, kernel.getNaming()); ConfigurationData configData = null; DeploymentContext context = null; Modified: geronimo/server/trunk/modules/geronimo-j2ee-builder/src/main/java/org/apache/geronimo/j2ee/deployment/EARConfigBuilder.java URL: http://svn.apache.org/viewvc/geronimo/server/trunk/modules/geronimo-j2ee-builder/src/main/java/org/apache/geronimo/j2ee/deployment/EARConfigBuilder.java?view=diffrev=515107r1=515106r2=515107 == --- geronimo/server/trunk/modules/geronimo-j2ee-builder/src/main/java/org/apache/geronimo/j2ee/deployment/EARConfigBuilder.java (original) +++ geronimo/server/trunk/modules/geronimo-j2ee-builder/src/main/java/org/apache/geronimo/j2ee/deployment/EARConfigBuilder.java Tue Mar 6 04:48:28 2007 @@ -91,6 +91,7 @@ import org.apache.geronimo.xbeans.javaee.ApplicationDocument; import org.apache.geronimo.xbeans.javaee.ApplicationType; import org.apache.geronimo.xbeans.javaee.ModuleType; +import org.apache.xmlbeans.QNameSet; import org.apache.xmlbeans.XmlCursor; import org.apache.xmlbeans.XmlException; import org.apache.xmlbeans.XmlObject; @@ -114,6 +115,7 @@ private final SingleElementCollection resourceReferenceBuilder; private final NamespaceDrivenBuilderCollection securityBuilders; private final
Generic way to handle annotations for integrating projects
I've been working on annotation handling for jetty using xbean-
reflect and have come up with a design for general annotation
processing that I would like to propose we urge our integrated
projects to allow or adopt.
This is appropriate when the injection only involves stuff looked up
in jndi and when the sequence of events is
- construct instance
- inject stuff
- call postConstruct
with no intervening container lifecycle calls.
So I'd like each project to define an interface
public interface ProjectLifecycleSupport {
Object newInstance(String className); //might need a classloader too
depending on whether the project has per-module instances
void destroyInstance(Object o);
}
and provide a way we can inject such an object into the projects
framework.
We can then implement the newInstance method to construct and inject
properties using xbean-reflect and call postConstruct, and
destroyInstance to call preDestroy.
Another style has been popularized by tomcat (?) which has 3 methods
inject(Object)
postConstruct(Object)
preDestroy(Object)
We can use this style but then we wont be able to use xbean-reflect
which hides all the hard part :-) and would let us go beyond the spec
and support constructor injection if we can figure out how to get
constructor metadata to it.
It's pretty trivial to implement an adapter between my proposal and
the tomcat style, but not vice versa.
So, where would this be used? The most likely bits are MyFaces, CXF,
and Axis2. I'm already doing something very similar for jetty and
haven't looked to see if tomcat can be adapted this way.
Thoughts?
thanks
david jencks
site driver-downloads.properties
Anyone know if this is still used anywhere? If so I think we should move it into a sub-tree of the site, instead of leaving it in the root. --jason
[jira] Updated: (GERONIMO-2814) Add a second repository to Geronimo
[ https://issues.apache.org/jira/browse/GERONIMO-2814?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ted Kirby updated GERONIMO-2814: Attachment: ServerRepository-ag20-export.zip ServerRepository-ag20-plan.xml I attached a new plan with more standard names suitable for a plugin. I deployed it locally, and used the admin console to export the plugin. I have attached that file, too. I need to do more investigation to put this in some plugin repo and test it by installing it from there. Add a second repository to Geronimo --- Key: GERONIMO-2814 URL: https://issues.apache.org/jira/browse/GERONIMO-2814 Project: Geronimo Issue Type: New Feature Security Level: public(Regular issues) Components: deployment Affects Versions: 1.1.x, 2.0-M2 Reporter: Ted Kirby Priority: Minor Fix For: 1.1.x, 2.0-M2 Attachments: GERONIMO-2814-J2EEServerImpl.patch, JIRA-2814-2.0.patch, repo2-1.2-plan.xml, repo2-111-plan.xml, repo2-ag20-plan.xml, repo2-ag20-plan2.xml, ServerRepository-ag20-export.zip, ServerRepository-ag20-plan.xml It would be nice to allow for a second repository for applications separate from the default repository used by geronimo. One use case would be for multiple server instances where the geronimo repository would be read-only, and each server instance would have its own read-write repository. I have attached a 2.0 plan for a second repository, called repo2.xml. Here is how to use it: mkdir germonimo_home/repo2 deploy repo2.xml The target names are long and cumbersome: java deployer.jar list-targets Available Targets: org.example.configs/myrepo/2.0-SNAPSHOT/car?ServiceModule=org.example.configs/myrepo/2.0-SNAPSHOT/car,j2eeType=ConfigurationStore,name=Local2 org.apache.geronimo.configs/j2ee-system/2.0-SNAPSHOT/car?ServiceModule=org.apache.geronimo.configs/j2ee-system/2.0-SNAPSHOT/car,j2eeType=ConfigurationStore,name=Local Use of environment variables recommended for command-line use. To deploy to the new repo, use: deploy --targets %REPO2% sample.war deploy list-modules also gives those long target names on each module. However, deploy list-modules %REPO2% gives the accustomed short output. java deployer.jar undeploy %REPO2%|geronimo/jsp-examples/1.1.1/war -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
site schemas-{1.0|1.1}
Anyone know where these are referenced? These trees contains sun copyrighted muck... --jason
Re: site driver-downloads.properties
It's used in DatabasePoolPortlet to figure out which JDBC drivers can be dynamically added to the server using the DB pool wizard. Moving it to a subtree sounds fine, adjusting the URL reference in DatabasePoolPortlet.java accordingly. Best wishes, Paul On 3/6/07, Jason Dillon [EMAIL PROTECTED] wrote: Anyone know if this is still used anywhere? If so I think we should move it into a sub-tree of the site, instead of leaving it in the root. --jason
Re: [VOTE] Release geronimo-javamail_2.4_spec-1.3
+1 -David On Mar 5, 2007, at 5:08 AM, Rick McGuire wrote: All, the javamail 1.3 spec has been updated to fix a problem with Transport.send() that multiple 1.1.1 and 1.2 beta users have tripped over. We'd like to get this released in time for the Geronimo 1.2 final version so fewer people will be seeing this problem. I hereby propose we release this branch and it's binaries as final. Release Branch: https://svn.apache.org/repos/asf/geronimo/specs/ branches/geronimo-javamail_1.3.1_spec-1.3 Built Binaries: http://people.apache.org/~dblevins/stage-specs/org/ apache/geronimo/specs/geronimo-javamail_1.3.1_spec/1.3/ Here's my +1 Rick
why do we call the eclipse plugin devtools?
I agree its a development tool... but its seems really odd that we don't just call this eclipse-plugin... which seems to be the normal way other projects refer to their eclipse integration. For example, on the main page under sub-projects... I think the link should be Eclipse Plugin and that most users will kind of expect to see that instead of Development Tools, which happens to be a page all about the Eclipse Plugin anyways. --jason
Re: site driver-downloads.properties
Is this list going to change over time for versions of Geronimo? Its not high traffic is it? I'm wondering if it doesn't make more sense to serve these up directly from svn.apache.org/repos/asf/geronimo/** instead of holding on to them here in the site tree. --jason On Mar 6, 2007, at 2:07 PM, Paul McMahan wrote: It's used in DatabasePoolPortlet to figure out which JDBC drivers can be dynamically added to the server using the DB pool wizard. Moving it to a subtree sounds fine, adjusting the URL reference in DatabasePoolPortlet.java accordingly. Best wishes, Paul On 3/6/07, Jason Dillon [EMAIL PROTECTED] wrote: Anyone know if this is still used anywhere? If so I think we should move it into a sub-tree of the site, instead of leaving it in the root. --jason
Re: why do we call the eclipse plugin devtools?
As long as there is only the eclipse plugin in the devtools project I agree that it would be clearer to just call it eclipse plugin from the main page. The J2G tooling that was recently contributed was implemented as a collection of eclipse plugins, so I think the naming you propose will still work OK if/when it gets added to that page. Best wishes, Paul On 3/6/07, Jason Dillon [EMAIL PROTECTED] wrote: I agree its a development tool... but its seems really odd that we don't just call this eclipse-plugin... which seems to be the normal way other projects refer to their eclipse integration. For example, on the main page under sub-projects... I think the link should be Eclipse Plugin and that most users will kind of expect to see that instead of Development Tools, which happens to be a page all about the Eclipse Plugin anyways. --jason
Re: why do we call the eclipse plugin devtools?
I would just add a new link on the nav for J2G... and when/if we get an IDEA plugin, then add that as a separate link too. I'd also give each of them their own JIRA project too. I'm okay with the svn sub- tree for devtools/ just slightly annoyed that we refer to the eclipse plugin as devtools, when its really the eclipse plugin. Its minor... but I'm anal about structure and naming :-P --jason On Mar 6, 2007, at 2:18 PM, Paul McMahan wrote: As long as there is only the eclipse plugin in the devtools project I agree that it would be clearer to just call it eclipse plugin from the main page. The J2G tooling that was recently contributed was implemented as a collection of eclipse plugins, so I think the naming you propose will still work OK if/when it gets added to that page. Best wishes, Paul On 3/6/07, Jason Dillon [EMAIL PROTECTED] wrote: I agree its a development tool... but its seems really odd that we don't just call this eclipse-plugin... which seems to be the normal way other projects refer to their eclipse integration. For example, on the main page under sub-projects... I think the link should be Eclipse Plugin and that most users will kind of expect to see that instead of Development Tools, which happens to be a page all about the Eclipse Plugin anyways. --jason
Re: why do we call the eclipse plugin devtools?
On 3/6/07, Jason Dillon [EMAIL PROTECTED] wrote: I agree its a development tool... but its seems really odd that we don't just call this eclipse-plugin... which seems to be the normal way other projects refer to their eclipse integration. For example, on the main page under sub-projects... I think the link should be Eclipse Plugin and that most users will kind of expect to see that instead of Development Tools, which happens to be a page all about the Eclipse Plugin anyways. I know there're some works on a Geronimo NetBeans IDE plugin so wait a bit longer and you'll see the point of having 'Devtools' name not 'Eclipse Plugin' . Jacek -- Jacek Laskowski http://www.JacekLaskowski.pl
Re: site driver-downloads.properties
On 3/6/07, Jason Dillon [EMAIL PROTECTED] wrote: Is this list going to change over time for versions of Geronimo? The list is not currently maintained as actively as it should be. It hasn't changed in a while but we need to keep ability to change it occasionally. Its not high traffic is it? No it's only accessed when the a console user goes to a optional step in the db pool wizard that allows them to add a jdbc driver. I'm wondering if it doesn't make more sense to serve these up directly from svn.apache.org/repos/asf/geronimo/** instead of holding on to them here in the site tree That would work but I wonder how fond infra would be of that idea. --jason On Mar 6, 2007, at 2:07 PM, Paul McMahan wrote: It's used in DatabasePoolPortlet to figure out which JDBC drivers can be dynamically added to the server using the DB pool wizard. Moving it to a subtree sounds fine, adjusting the URL reference in DatabasePoolPortlet.java accordingly. Best wishes, Paul On 3/6/07, Jason Dillon [EMAIL PROTECTED] wrote: Anyone know if this is still used anywhere? If so I think we should move it into a sub-tree of the site, instead of leaving it in the root. --jason
Re: [VOTE] Release geronimo-javamail_2.4_spec-1.3
On 3/5/07, Rick McGuire [EMAIL PROTECTED] wrote: I hereby propose we release this branch and it's binaries as final. Sorry for hijacking the vote thread, but I wonder why https://svn.apache.org/repos/asf/geronimo/specs/branches/geronimo-javamail_1.3.1_spec-1.3/README.txt mentions about 'JavaMail Specification 1.4'. Shouldn't the version numbers be the same? Jacek -- Jacek Laskowski http://www.JacekLaskowski.pl
Re: why do we call the eclipse plugin devtools?
On 3/6/07, Jason Dillon [EMAIL PROTECTED] wrote: I'm okay with the svn sub- tree for devtools/ just slightly annoyed that we refer to the eclipse plugin as devtools, when its really the eclipse plugin. Its minor... but I'm anal about structure and naming :-P I love your tidiness until its me that has screwed something up! ;-)
Re: why do we call the eclipse plugin devtools?
On Mar 6, 2007, at 2:26 PM, Jacek Laskowski wrote: For example, on the main page under sub-projects... I think the link should be Eclipse Plugin and that most users will kind of expect to see that instead of Development Tools, which happens to be a page all about the Eclipse Plugin anyways. I know there're some works on a Geronimo NetBeans IDE plugin so wait a bit longer and you'll see the point of having 'Devtools' name not 'Eclipse Plugin' . No... then I would see more reason to not have things called devtools. I would expect that each of these devtools would have their own page, then own JIRA so they can be managed separately. I think its fine to have a the side-nav box titled Development Tools but I expect to have each major tool to have its own independent area for managing content/issues related to it. * * * I guess the thing I don't really like right now... is that we refer to the eclipse-plugin as devtools interchangeably. I believe that should change... and I think the way to make that change is to start renaming stuff that was previously devtools (which was solely for eclipse tooling support) to eclipse-plugin. --jason
Re: why do we call the eclipse plugin devtools?
On 3/6/07, Jason Dillon [EMAIL PROTECTED] wrote: I guess the thing I don't really like right now... is that we refer to the eclipse-plugin as devtools interchangeably. I believe that should change... and I think the way to make that change is to start renaming stuff that was previously devtools (which was solely for eclipse tooling support) to eclipse-plugin. I second that. Jacek -- Jacek Laskowski http://www.JacekLaskowski.pl
Re: site schemas-{1.0|1.1}
You mean all the links from here? http://geronimo.apache.org/schemas.html I thought we only linked to the Geronimo ones in our site and pointed to the Sun site for the Sun ones, though. Thanks, Aaron On 3/6/07, Jason Dillon [EMAIL PROTECTED] wrote: Anyone know where these are referenced? These trees contains sun copyrighted muck... --jason
Re: site schemas-{1.0|1.1}
No, the sun schemas all link to java.sun.com here... but we still have the sun schemas in our svn (like http://geronimo.apache.org/ schemas-1.1/application-client_1_2.dtd). I think the sun schemas should be dropped from our svn site tree. --jason On Mar 6, 2007, at 2:44 PM, Aaron Mulder wrote: You mean all the links from here? http://geronimo.apache.org/schemas.html I thought we only linked to the Geronimo ones in our site and pointed to the Sun site for the Sun ones, though. Thanks, Aaron On 3/6/07, Jason Dillon [EMAIL PROTECTED] wrote: Anyone know where these are referenced? These trees contains sun copyrighted muck... --jason
Site changing
I'm going to implement the first step of using the Confluence-driven website for geronimo.apache.org. This includes cleaning up site/trunk. I've made a copy of the current bits here http://svn.apache.org/repos/asf/geronimo/site/tags/ pre-confluence incase I accidentally nuke something, though I think I've identified all of the underlay/boilerplate bits which still need to get served from this svn tree. For now we are just going to sync GMOxSITE from the AutoExport content, but I think that shortly afterwards we will sync all of the spaces (except for 'geronimo', the traditional wiki) so that all non- user driven content is served up from http://geronimo.apache.org. To do this requires a little bit more content massaging which is gonna take a wee bit longer to whip up and get working for an automated push. Anyways, should be up in an hour or so... if someone notices something is missing please lemme know. --jason
Re: site schemas-{1.0|1.1}
FYI, I'm leaving all of the schema-* stuff ASIS for now, but I think that we should soon nuke the sun stuff. --jason On Mar 6, 2007, at 2:44 PM, Aaron Mulder wrote: You mean all the links from here? http://geronimo.apache.org/schemas.html I thought we only linked to the Geronimo ones in our site and pointed to the Sun site for the Sun ones, though. Thanks, Aaron On 3/6/07, Jason Dillon [EMAIL PROTECTED] wrote: Anyone know where these are referenced? These trees contains sun copyrighted muck... --jason
Re: [VOTE] Release geronimo-javamail_2.4_spec-1.3
the subject doesn't look quite right, but the artifacts do. +1 david jencks On Mar 5, 2007, at 8:08 AM, Rick McGuire wrote: All, the javamail 1.3 spec has been updated to fix a problem with Transport.send() that multiple 1.1.1 and 1.2 beta users have tripped over. We'd like to get this released in time for the Geronimo 1.2 final version so fewer people will be seeing this problem. I hereby propose we release this branch and it's binaries as final. Release Branch: https://svn.apache.org/repos/asf/geronimo/specs/ branches/geronimo-javamail_1.3.1_spec-1.3 Built Binaries: http://people.apache.org/~dblevins/stage-specs/org/ apache/geronimo/specs/geronimo-javamail_1.3.1_spec/1.3/ Here's my +1 Rick
Re: site schemas-{1.0|1.1}
On Mar 6, 2007, at 5:52 PM, Jason Dillon wrote: FYI, I'm leaving all of the schema-* stuff ASIS for now, but I think that we should soon nuke the sun stuff. I agree, ASAP david jencks --jason On Mar 6, 2007, at 2:44 PM, Aaron Mulder wrote: You mean all the links from here? http://geronimo.apache.org/schemas.html I thought we only linked to the Geronimo ones in our site and pointed to the Sun site for the Sun ones, though. Thanks, Aaron On 3/6/07, Jason Dillon [EMAIL PROTECTED] wrote: Anyone know where these are referenced? These trees contains sun copyrighted muck... --jason
WebServicesPermission
For JAX-WS services we need to check/enforce the WebServicesPermission while publishing JAX-WS endpoints. Here's what the JAX-WS 2.0 spec says (section 5.2.3): Conformance (Checking publishEndpoint Permission): When any of the publish methods defined by the Endpoint class are invoked, an implementation MUST check whether a SecurityManager is installed with the application. If it is, implementations MUST verify that the application has the WebServicePermission identified by the target name publishEndpoint before proceeding. If the permission is not granted, implementations MUST NOT publish the endpoint and they MUST throw a java.lang.SecurityException. So I think this is pretty clear how the check should be done and where. That is, using SecurityManager API and within the CXF or Axis2 Endpoint class when one of the publish method is called. Now, in JSR109 spec (section 5.3.3) says: JAX-WS provides functionality for creating and publishing Web Service endpoints dynamically using javax.xml.ws.Endpoint API. The use of this functionality is considered non-portable in a managed environment. It is required that both the Servlet and the EJB container disallow the publishing of the Endpoint dynamically, by not granting the publishEndpoint security permission. Please refer to details on this in Section 5.2 of the JAX-WS specification. So that permission needs to be enforced in G. How do I configure things so that this permission is enforced or what do I need to do to enforce it? Thanks, Jarek
Re: site schemas-{1.0|1.1}
Sounds good to me. Thanks, Aaron On 3/6/07, David Jencks [EMAIL PROTECTED] wrote: On Mar 6, 2007, at 5:52 PM, Jason Dillon wrote: FYI, I'm leaving all of the schema-* stuff ASIS for now, but I think that we should soon nuke the sun stuff. I agree, ASAP david jencks --jason On Mar 6, 2007, at 2:44 PM, Aaron Mulder wrote: You mean all the links from here? http://geronimo.apache.org/schemas.html I thought we only linked to the Geronimo ones in our site and pointed to the Sun site for the Sun ones, though. Thanks, Aaron On 3/6/07, Jason Dillon [EMAIL PROTECTED] wrote: Anyone know where these are referenced? These trees contains sun copyrighted muck... --jason
[jira] Commented: (XBEAN-79) Need some kind of Recipe for static fields and properties on classes
[ https://issues.apache.org/jira/browse/XBEAN-79?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12478628 ] David Jencks commented on XBEAN-79: --- rev 515352 actually makes static support work. I needed to add a new option STATIC_PROPERTIES and add a boolean to a couple method sigatures. I left deprecated copies of the old public methods behind. I don't know how important maintaining backward compatibility is. Need some kind of Recipe for static fields and properties on classes Key: XBEAN-79 URL: https://issues.apache.org/jira/browse/XBEAN-79 Project: XBean Issue Type: Improvement Affects Versions: 3.0 Reporter: David Jencks Fix For: 3.0 For setting up app clients we need a recipe for static fields and properties. This can be done with a slight modification of ObjectRecipe, which I'm about to commit, but it might be better to have a separate class for this purpose. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (SM-868) Null pointer exception if publisher reference not specified properly
Null pointer exception if publisher reference not specified properly
Key: SM-868
URL: https://issues.apache.org/activemq/browse/SM-868
Project: ServiceMix
Issue Type: Bug
Components: servicemix-wsn2005
Affects Versions: 3.1, 3.0
Reporter: Jeremy Clark
Priority: Minor
Using the WSN-HTTP-Binding example, and sending in a RegisterPublisher message
to ServiceMix without a valid PublisherReference results in this stack trace
(and a null pointer exception returned to the publisher):
[Fatal Error] :-1:-1: Premature end of file.
ERROR - WSNComponent - Error processing exchange InOut[
id: ID:MELBA-2288-1173131624682-2:0
status: Active
role: provider
service: {http://servicemix.org/wsnotification}NotificationBroker
endpoint: Broker
in: Unable to display: org.xml.sax.SAXParseException: Premature end of file.
]
java.lang.NullPointerException
at
org.apache.servicemix.wsn.jbi.JbiPublisher.validatePublisher(JbiPublisher.java:87)
at
org.apache.servicemix.wsn.AbstractPublisher.create(AbstractPublisher.java:90)
at
org.apache.servicemix.wsn.AbstractNotificationBroker.handleRegisterPublisher(AbstractNotificationBroker.java:253)
at
org.apache.servicemix.wsn.AbstractNotificationBroker.registerPublisher(AbstractNotificationBroker.java:234)
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:597)
at
org.apache.servicemix.wsn.component.WSNEndpoint.process(WSNEndpoint.java:137)
at
org.apache.servicemix.common.AsyncBaseLifeCycle.doProcess(AsyncBaseLifeCycle.java:489)
at
org.apache.servicemix.common.AsyncBaseLifeCycle.processExchange(AsyncBaseLifeCycle.java:441)
at
org.apache.servicemix.common.BaseLifeCycle.onMessageExchange(BaseLifeCycle.java:46)
at
org.apache.servicemix.jbi.messaging.DeliveryChannelImpl.processInBound(DeliveryChannelImpl.java:593)
at
org.apache.servicemix.jbi.nmr.flow.AbstractFlow.doRouting(AbstractFlow.java:174)
at
org.apache.servicemix.jbi.nmr.flow.seda.SedaFlow.doRouting(SedaFlow.java:176)
at
org.apache.servicemix.jbi.nmr.flow.seda.SedaQueue$1.run(SedaQueue.java:134)
at
edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:665)
at
edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:690)
at java.lang.Thread.run(Thread.java:619)
WARN - jetty - EXCEPTION
javax.servlet.ServletException: Failed to process request: java.lang.Exception:
java.lang.NullPointerException
at
org.apache.servicemix.http.HttpBridgeServlet.doPost(HttpBridgeServlet.java:79)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:617)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:690)
at
org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:445)
at
org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:356)
at
org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:627)
at
org.mortbay.jetty.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:149)
at
org.mortbay.jetty.handler.HandlerCollection.handle(HandlerCollection.java:123)
at
org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:141)
at org.mortbay.jetty.Server.handle(Server.java:269)
at
org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:430)
at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:333)
at
org.mortbay.jetty.nio.HttpChannelEndPoint.run(HttpChannelEndPoint.java:270)
at
org.mortbay.thread.BoundedThreadPool$PoolThread.run(BoundedThreadPool.java:475)
WARN - jetty - Nested in
javax.servlet.ServletException: Failed to process request: java.lang.Exception:
java.lang.NullPointerException:
java.lang.Exception: java.lang.NullPointerException
at
org.apache.servicemix.http.processors.ConsumerProcessor.process(ConsumerProcessor.java:214)
at
org.apache.servicemix.http.HttpBridgeServlet.doPost(HttpBridgeServlet.java:71)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:617)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:690)
at
org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:445)
at
org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:356)
at
org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:627)
Re: WebServicesPermission
On Mar 6, 2007, at 6:19 PM, Jarek Gawor wrote:
For JAX-WS services we need to check/enforce the WebServicesPermission
while publishing JAX-WS endpoints. Here's what the JAX-WS 2.0 spec
says (section 5.2.3):
Conformance (Checking publishEndpoint Permission): When any of the
publish methods defined by the Endpoint class are invoked, an
implementation MUST check whether a SecurityManager is installed with
the application. If it is, implementations MUST verify that the
application has the WebServicePermission identified by the target name
publishEndpoint before proceeding. If the permission is not granted,
implementations MUST NOT publish the endpoint and they MUST throw a
java.lang.SecurityException.
So I think this is pretty clear how the check should be done and
where. That is, using SecurityManager API and within the CXF or Axis2
Endpoint class when one of the publish method is called.
Now, in JSR109 spec (section 5.3.3) says:
JAX-WS provides functionality for creating and publishing Web Service
endpoints dynamically using javax.xml.ws.Endpoint API. The use of this
functionality is considered non-portable in a managed environment. It
is required that both the Servlet and the EJB container disallow the
publishing of the Endpoint dynamically, by not granting the
publishEndpoint security permission. Please refer to details on this
in Section 5.2 of the JAX-WS specification.
So that permission needs to be enforced in G. How do I configure
things so that this permission is enforced or what do I need to do to
enforce it?
According to the SecurityManager javadoc the default implementation
of securityManager.checkPermission is to call
AccessController.checkPermission(). So I'd suggest that if the cxf/
axis2 code was
SecurityManager sm = System.getSecurityManager();
if (sm != null) {
sm.checkPermission(new WebServicePermission(targetName));
} else {
AccessController.checkPermission(new WebServicePermission
(targetName));
}
then we will have fulfilled the jaxws spec (if there is a security
manager installed we ask it's permission)
and the jsr109 spec (AccessController won't grant this permission, or
we can make our jacc implementation deny it if necessary)
and we won't have to install a security manager.
thanks
david jencks
Thanks,
Jarek
[jira] Commented: (GERONIMO-2887) Hook up injections for jetty and app client
[ https://issues.apache.org/jira/browse/GERONIMO-2887?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12478639 ] David Jencks commented on GERONIMO-2887: rev 515367 makes the app client injections actually work. Note that this requires xbean-reflect 3.0-SNAPSHOT. Hook up injections for jetty and app client --- Key: GERONIMO-2887 URL: https://issues.apache.org/jira/browse/GERONIMO-2887 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Affects Versions: 2.0 Reporter: David Jencks Assigned To: David Jencks Fix For: 2.0 Attachments: GERONIMO-2887.patch Now all the annotations are getting put into the xml dd. We need to actually use this info to do the injections for jetty and the app client. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: WebServicesPermission
And the targetname is publishEndpoint according to the
WebServicePermission javadoc.
thanks,
-- dims
On 3/6/07, David Jencks [EMAIL PROTECTED] wrote:
On Mar 6, 2007, at 6:19 PM, Jarek Gawor wrote:
For JAX-WS services we need to check/enforce the WebServicesPermission
while publishing JAX-WS endpoints. Here's what the JAX-WS 2.0 spec
says (section 5.2.3):
Conformance (Checking publishEndpoint Permission): When any of the
publish methods defined by the Endpoint class are invoked, an
implementation MUST check whether a SecurityManager is installed with
the application. If it is, implementations MUST verify that the
application has the WebServicePermission identified by the target name
publishEndpoint before proceeding. If the permission is not granted,
implementations MUST NOT publish the endpoint and they MUST throw a
java.lang.SecurityException.
So I think this is pretty clear how the check should be done and
where. That is, using SecurityManager API and within the CXF or Axis2
Endpoint class when one of the publish method is called.
Now, in JSR109 spec (section 5.3.3) says:
JAX-WS provides functionality for creating and publishing Web Service
endpoints dynamically using javax.xml.ws.Endpoint API. The use of this
functionality is considered non-portable in a managed environment. It
is required that both the Servlet and the EJB container disallow the
publishing of the Endpoint dynamically, by not granting the
publishEndpoint security permission. Please refer to details on this
in Section 5.2 of the JAX-WS specification.
So that permission needs to be enforced in G. How do I configure
things so that this permission is enforced or what do I need to do to
enforce it?
According to the SecurityManager javadoc the default implementation
of securityManager.checkPermission is to call
AccessController.checkPermission(). So I'd suggest that if the cxf/
axis2 code was
SecurityManager sm = System.getSecurityManager();
if (sm != null) {
sm.checkPermission(new WebServicePermission(targetName));
} else {
AccessController.checkPermission(new WebServicePermission
(targetName));
}
then we will have fulfilled the jaxws spec (if there is a security
manager installed we ask it's permission)
and the jsr109 spec (AccessController won't grant this permission, or
we can make our jacc implementation deny it if necessary)
and we won't have to install a security manager.
thanks
david jencks
Thanks,
Jarek
--
Davanum Srinivas :: http://wso2.org/ :: Oxygen for Web Services Developers
[jira] Commented: (GERONIMO-2934) Support annotation processing for all Module/Naming builders
[ https://issues.apache.org/jira/browse/GERONIMO-2934?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12478641 ] David Jencks commented on GERONIMO-2934: rev 515371 distributes the annotation processing over the NamingBuilders that can actually deal with them, but does not correct the decision as to whether a particular annotation is relevant to the naming builder. For common cases such as jdbc, jms, cci, it will work, but in general it's wrong. Basically we can look for geronimo plan info for an annotation or look for an appropriate gbean as the target of the annotation. Support annotation processing for all Module/Naming builders Key: GERONIMO-2934 URL: https://issues.apache.org/jira/browse/GERONIMO-2934 Project: Geronimo Issue Type: Sub-task Security Level: public(Regular issues) Reporter: Tim McConnell Assigned To: Tim McConnell Attachments: GERONIMO-2934-1.patch -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: WebServicesPermission
some day I'll learn to read :-) ... that's right in jarek's quote.
thanks
david jencks
On Mar 6, 2007, at 6:45 PM, Davanum Srinivas wrote:
And the targetname is publishEndpoint according to the
WebServicePermission javadoc.
thanks,
-- dims
On 3/6/07, David Jencks [EMAIL PROTECTED] wrote:
On Mar 6, 2007, at 6:19 PM, Jarek Gawor wrote:
For JAX-WS services we need to check/enforce the
WebServicesPermission
while publishing JAX-WS endpoints. Here's what the JAX-WS 2.0 spec
says (section 5.2.3):
Conformance (Checking publishEndpoint Permission): When any of the
publish methods defined by the Endpoint class are invoked, an
implementation MUST check whether a SecurityManager is installed
with
the application. If it is, implementations MUST verify that the
application has the WebServicePermission identified by the
target name
publishEndpoint before proceeding. If the permission is not
granted,
implementations MUST NOT publish the endpoint and they MUST throw a
java.lang.SecurityException.
So I think this is pretty clear how the check should be done and
where. That is, using SecurityManager API and within the CXF or
Axis2
Endpoint class when one of the publish method is called.
Now, in JSR109 spec (section 5.3.3) says:
JAX-WS provides functionality for creating and publishing Web
Service
endpoints dynamically using javax.xml.ws.Endpoint API. The use
of this
functionality is considered non-portable in a managed
environment. It
is required that both the Servlet and the EJB container disallow
the
publishing of the Endpoint dynamically, by not granting the
publishEndpoint security permission. Please refer to details on
this
in Section 5.2 of the JAX-WS specification.
So that permission needs to be enforced in G. How do I configure
things so that this permission is enforced or what do I need to
do to
enforce it?
According to the SecurityManager javadoc the default implementation
of securityManager.checkPermission is to call
AccessController.checkPermission(). So I'd suggest that if the cxf/
axis2 code was
SecurityManager sm = System.getSecurityManager();
if (sm != null) {
sm.checkPermission(new WebServicePermission(targetName));
} else {
AccessController.checkPermission(new WebServicePermission
(targetName));
}
then we will have fulfilled the jaxws spec (if there is a security
manager installed we ask it's permission)
and the jsr109 spec (AccessController won't grant this permission, or
we can make our jacc implementation deny it if necessary)
and we won't have to install a security manager.
thanks
david jencks
Thanks,
Jarek
--
Davanum Srinivas :: http://wso2.org/ :: Oxygen for Web Services
Developers
Re: site schemas-{1.0|1.1}
On Mar 6, 2007, at 6:02 PM, David Jencks wrote: On Mar 6, 2007, at 5:52 PM, Jason Dillon wrote: FYI, I'm leaving all of the schema-* stuff ASIS for now, but I think that we should soon nuke the sun stuff. I agree, ASAP Me too... --kevan
[jira] Closed: (GERONIMO-2868) Message Driven Beans will not run under the specified run-as Subject
[ https://issues.apache.org/jira/browse/GERONIMO-2868?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Jencks closed GERONIMO-2868. -- Resolution: Fixed Committed (in openejb2) in rev 515390. Thanks for working through a fix for this! Message Driven Beans will not run under the specified run-as Subject -- Key: GERONIMO-2868 URL: https://issues.apache.org/jira/browse/GERONIMO-2868 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: OpenEJB, security Affects Versions: 1.2 Reporter: Aman Nanner Assigned To: David Jencks Attachments: mdb-default-subject-interceptor.patch, mdb-run-as.patch If a message driven bean is configured with a run-as element, it is being ignored and the message driven bean is not run as the specified Subject. The MDB would be configured in the ejb-jar.xml as follows: message-driven display-nameTestMDB/display-name ejb-nameTestMDB/ejb-name ejb-classcom.acme.ejb.TestMDB/ejb-class transaction-typeBean/transaction-type message-destination-typejavax.jms.Topic/message-destination-type activation-config activation-config-property activation-config-property-nameacknowledgeMode/activation-config-property-name activation-config-property-valueAuto-acknowledge/activation-config-property-value /activation-config-property activation-config-property activation-config-property-namemessageSelector/activation-config-property-name activation-config-property-valueJOB_CODE = 'FOO'/activation-config-property-value /activation-config-property activation-config-property activation-config-property-namesubscriptionDurability/activation-config-property-name activation-config-property-valueNonDurable/activation-config-property-value /activation-config-property /activation-config ejb-ref ejb-ref-nameejb/common/TestEJB/ejb-ref-name ejb-ref-typeSession/ejb-ref-type homecom.acme.ejb.TestHome/home remotecom.acme.ejb.TestRemote/remote ejb-linkTestEJB/ejb-link /ejb-ref security-identity run-as role-nameTESTROLE/role-name /run-as /security-identity /message-driven Upon inspection of the org.apache.openejb.mdb.DefaaultMdbContainer class, it is noted that the EjbRunAsInterceptor is not configured as part of the invocation step (as it is in org.apache.openejb.slsb.DefaultStatelessEjbContainer). Therefore, the run-as Subject is never being set as part of the Caller stack. I added the EjbRunAsInterceptor into the invocation stack and rebuilt Geronimo, but this didn't completely fix the problem. The EjbRunAsInterceptor is now being called, and the Subject is being set as the next caller in the ContextManager's caller stack. However, the EjbIdentityInterceptor runs next, and authorizes the invocation under the current caller, not the next caller. Thus, the run-as Subject does NOT perform the invocation. I'm not sure what the best way is to fix this without impacting everything else. If somebody with more knowledge in this area has a good idea, I can try it and submit a patch. Also note that this problem seems to imply that the run-as functionality wouldn't work with session EJBs either (I haven't tried to verify this). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
New Security Stuff for 2.0 - question
Given the recent discussion around BouncyCastle on incubator and other project lists. I thought I'd poke to see what new items we have and make sure we have our export / legal stuff taken care of or accounted for. Can folks who are aware of changes in the following areas reply to this note? New keystore mgmt facilities? Password encryption? New ciphers, etc? Thanks
Re: SPECjAppServer2004 v1.08 with research mode is released!
Interesting news Vasiliy. According to the press release we need to still buy the benchmark for $250? Does this mean that a one time purchase for Geronimo is possible and that the benchmark would be useable by all Geronimo committers? Thanks for the heads up. On Mar 6, 2007, at 2:44 PM, Zakharov, Vasily M wrote: Hi, all, I'm happy to announce that the new version of SPECjAppServer2004 (1.08) is released, and includes changes allowing publishing results in open source. SjAS2004 1.08 includes a special research mode workload called EAStress2004 that has a different metric but allows SjAS licensees to publish results for open source products having no J2EE certification and without the results being reviewed by SPEC. This allows for projects like Geronimo to effectively use that workload for testing and discovering performance issues. Here's the press-release: http://www.spec.org/jAppServer2004/jAppServer2004v108.html Vasily Zakharov Intel ESSD
Re: Site changing
Site is updated... using Confluence-driven content. I've implemented an automated sync, documented here ( https:// svn.apache.org/repos/asf/geronimo/site/trunk/README.txt ). This will sync content from cwiki and from SVN every hour, so no need to ssh into people anymore to update site stuff. This won't force the AE plugin to export everything though, so when something major changes on the site (like side-nav) or something using more dynamic macros, the site will need to be re-exported to get those changes picked up. When I have a few free moments (not spent in TCK build hell), I will implement a solution to this too. --jason On Mar 6, 2007, at 2:51 PM, Jason Dillon wrote: I'm going to implement the first step of using the Confluence- driven website for geronimo.apache.org. This includes cleaning up site/trunk. I've made a copy of the current bits here http://svn.apache.org/repos/asf/geronimo/site/ tags/pre-confluence incase I accidentally nuke something, though I think I've identified all of the underlay/boilerplate bits which still need to get served from this svn tree. For now we are just going to sync GMOxSITE from the AutoExport content, but I think that shortly afterwards we will sync all of the spaces (except for 'geronimo', the traditional wiki) so that all non-user driven content is served up from http:// geronimo.apache.org. To do this requires a little bit more content massaging which is gonna take a wee bit longer to whip up and get working for an automated push. Anyways, should be up in an hour or so... if someone notices something is missing please lemme know. --jason
Re: [VOTE] Release geronimo-javamail_2.4_spec-1.3
Jacek Laskowski wrote: On 3/5/07, Rick McGuire [EMAIL PROTECTED] wrote: I hereby propose we release this branch and it's binaries as final. Sorry for hijacking the vote thread, but I wonder why https://svn.apache.org/repos/asf/geronimo/specs/branches/geronimo-javamail_1.3.1_spec-1.3/README.txt mentions about 'JavaMail Specification 1.4'. Shouldn't the version numbers be the same? Only the 1.4 specifications are available on the web as html. The 1.4 additions are clearly marked in the docs as 1.4 features. The references to 1.4 as the source of the API information in the readme are correct as written. Rick Jacek
Re: site schemas-{1.0|1.1}
Looks like the schemas up there also need the new ASL headers... We should really look into getting these schemas part of the Maven site, so we always keep them up to date with Geronimo versions. --jason On Mar 6, 2007, at 4:20 PM, Kevan Miller wrote: On Mar 6, 2007, at 6:02 PM, David Jencks wrote: On Mar 6, 2007, at 5:52 PM, Jason Dillon wrote: FYI, I'm leaving all of the schema-* stuff ASIS for now, but I think that we should soon nuke the sun stuff. I agree, ASAP Me too... --kevan
Re: site schemas-{1.0|1.1}
I've nuked all of the non-geronimo schemas from there... except for the openejb bits, they remain. --jason On Mar 6, 2007, at 4:20 PM, Kevan Miller wrote: On Mar 6, 2007, at 6:02 PM, David Jencks wrote: On Mar 6, 2007, at 5:52 PM, Jason Dillon wrote: FYI, I'm leaving all of the schema-* stuff ASIS for now, but I think that we should soon nuke the sun stuff. I agree, ASAP Me too... --kevan
Re: [VOTE] Release geronimo-javamail_2.4_spec-1.3
+1 On 3/5/07, Rick McGuire [EMAIL PROTECTED] wrote: All, the javamail 1.3 spec has been updated to fix a problem with Transport.send() that multiple 1.1.1 and 1.2 beta users have tripped over. We'd like to get this released in time for the Geronimo 1.2 final version so fewer people will be seeing this problem. I hereby propose we release this branch and it's binaries as final. Release Branch: https://svn.apache.org/repos/asf/geronimo/specs/branches/geronimo-javamail_1.3.1_spec-1.3 Built Binaries: http://people.apache.org/~dblevins/stage-specs/org/apache/geronimo/specs/geronimo-javamail_1.3.1_spec/1.3/ Here's my +1 Rick
Re: [VOTE] Release geronimo-javamail_2.4_spec-1.3
On Mar 5, 2007, at 8:08 AM, Rick McGuire wrote: All, the javamail 1.3 spec has been updated to fix a problem with Transport.send() that multiple 1.1.1 and 1.2 beta users have tripped over. We'd like to get this released in time for the Geronimo 1.2 final version so fewer people will be seeing this problem. I hereby propose we release this branch and it's binaries as final. Release Branch: https://svn.apache.org/repos/asf/geronimo/specs/ branches/geronimo-javamail_1.3.1_spec-1.3 Built Binaries: http://people.apache.org/~dblevins/stage-specs/org/ apache/geronimo/specs/geronimo-javamail_1.3.1_spec/1.3/ I didn't see any problems. +1 --kevan
Re: New Security Stuff for 2.0 - question
On Mar 6, 2007, at 7:49 PM, Matt Hogstrom wrote: Given the recent discussion around BouncyCastle on incubator and other project lists. I thought I'd poke to see what new items we have and make sure we have our export / legal stuff taken care of or accounted for. Can folks who are aware of changes in the following areas reply to this note? New keystore mgmt facilities? Password encryption? New ciphers, etc? Hey Matt, Was just catching up with some reading on [EMAIL PROTECTED] Looks like Geronimo needs to be classified with an Export Control Classification Number. Have we ever done this? We're not listed in the current classification table. So, looks like we have a little work to catch up on... Here's some info -- http://www.apache.org/licenses/exports/ By my interpretation, all Geronimo releases should be classified as ECCN 5D002. --kevan
Re: svn commit: r513066 - in /geronimo/server/trunk/modules: geronimo-kernel/src/main/java/org/apache/geronimo/kernel/log/ geronimo-system/src/main/java/org/apache/geronimo/system/logging/log4j/ geron
This is done.
--jason
On Mar 5, 2007, at 10:06 PM, Kevan Miller wrote:
Jason,
Thoughts on getting this into 1.2 (or at least part)? In
particular, stop printing the environment information to STDOUT
during startup...
--kevan
On Feb 28, 2007, at 6:38 PM, [EMAIL PROTECTED] wrote:
Author: jdillon
Date: Wed Feb 28 15:38:38 2007
New Revision: 513066
URL: http://svn.apache.org/viewvc?view=revrev=513066
Log:
(GERONIMO-2741) Clean up logging output on console
Modified:
geronimo/server/trunk/modules/geronimo-kernel/src/main/java/
org/apache/geronimo/kernel/log/GeronimoLogging.java
geronimo/server/trunk/modules/geronimo-system/src/main/java/
org/apache/geronimo/system/logging/log4j/Log4jService.java
geronimo/server/trunk/modules/geronimo-system/src/main/java/
org/apache/geronimo/system/main/Daemon.java
Modified: geronimo/server/trunk/modules/geronimo-kernel/src/main/
java/org/apache/geronimo/kernel/log/GeronimoLogging.java
URL: http://svn.apache.org/viewvc/geronimo/server/trunk/modules/
geronimo-kernel/src/main/java/org/apache/geronimo/kernel/log/
GeronimoLogging.java?view=diffrev=513066r1=513065r2=513066
=
=
--- geronimo/server/trunk/modules/geronimo-kernel/src/main/java/
org/apache/geronimo/kernel/log/GeronimoLogging.java (original)
+++ geronimo/server/trunk/modules/geronimo-kernel/src/main/java/
org/apache/geronimo/kernel/log/GeronimoLogging.java Wed Feb 28
15:38:38 2007
@@ -55,7 +55,12 @@
// force the log factory to initialize
LogFactory.getLog(GeronimoLogging.class);
-
+
+//
+// FIXME: Replace the bits below with this:
+//
+// System.setProperty(mx4j.log.prototype,
mx4j.log.CommonsLogger);
+
// force mx4j to use commons logging
// Use reflection so mx4j is not required (this is
important in JDK 1.5)
// mx4j.log.Log.redirectTo(new mx4j.log.CommonsLogger
());
Modified: geronimo/server/trunk/modules/geronimo-system/src/main/
java/org/apache/geronimo/system/logging/log4j/Log4jService.java
URL: http://svn.apache.org/viewvc/geronimo/server/trunk/modules/
geronimo-system/src/main/java/org/apache/geronimo/system/logging/
log4j/Log4jService.java?view=diffrev=513066r1=513065r2=513066
=
=
--- geronimo/server/trunk/modules/geronimo-system/src/main/java/
org/apache/geronimo/system/logging/log4j/Log4jService.java (original)
+++ geronimo/server/trunk/modules/geronimo-system/src/main/java/
org/apache/geronimo/system/logging/log4j/Log4jService.java Wed Feb
28 15:38:38 2007
@@ -512,6 +512,8 @@
File file = resolveConfigurationFile();
if (file == null || !file.exists()) {
return;
+} else {
+lastChanged = file.lastModified();
}
// Record the default console log level
@@ -552,23 +554,8 @@
public void doStart() {
LogFactory logFactory = LogFactory.getFactory();
if (logFactory instanceof GeronimoLogFactory) {
-synchronized (this) {
-timer = new Timer(true);
-
-// Periodically check the configuration file
-schedule();
-
-// Make sure the root Logger has loaded
-Logger logger = LogManager.getRootLogger();
-
-reconfigure();
-
-File file = resolveConfigurationFile();
-if (file != null) {
-lastChanged = file.lastModified();
-}
-logEnvInfo(logger);
-}
+// Make sure the root Logger has loaded
+Logger logger = LogManager.getRootLogger();
// Change all of the loggers over to use log4j
GeronimoLogFactory geronimoLogFactory =
(GeronimoLogFactory) logFactory;
@@ -577,6 +564,17 @@
geronimoLogFactory.setLogFactory(new
CachingLog4jLogFactory());
}
}
+
+synchronized (this) {
+reconfigure();
+
+timer = new Timer(true);
+
+// Periodically check the configuration file
+schedule();
+}
+
+logEnvInfo();
}
synchronized (this) {
@@ -608,8 +606,9 @@
}
}
-private void logEnvInfo(Logger log) {
+private void logEnvInfo() {
try {
+ Log log = LogFactory.getLog(Log4jService.class);
log.info
(--);
log.info(Started Logging Service);
log.debug(Log4jService created with configFileName= +
this.configurationFile +
@@ -640,9 +639,7 @@
log.info( System property [sun.boot.class.path] = +
System.getProperty(sun.boot.class.path));
log.info
(--);
Re: svn commit: r513066 - in /geronimo/server/trunk/modules: geronimo-kernel/src/main/java/org/apache/geronimo/kernel/log/ geronimo-system/src/main/java/org/apache/geronimo/system/logging/log4j/ geron
On Mar 6, 2007, at 10:41 PM, Jason Dillon wrote: This is done. Thanks Jason. --kevan
STATIC_PROPERTIES in org.apache.xbean.recipe.Option?
Any one have any idea what's up with this build failure:
snip
[INFO]
[INFO] Building Geronimo :: Client
[INFO]task-segment: [install]
[INFO]
[INFO] [tools:require-java-version {execution: validate-java-version}]
[INFO] [tools:copy-legal-files {execution: install-legal-files}]
[INFO] Created dir: /home/anthill/anthill3/agent/var/jobs/projects/
Geronimo_Components/build_trunk/project/modules/geronimo-client/
target/classes/META-INF
[INFO] Copying 2 files to /home/anthill/anthill3/agent/var/jobs/
projects/Geronimo_Components/build_trunk/project/modules/geronimo-
client/target/classes/META-INF
[INFO] [resources:resources]
[INFO] Using default encoding to copy filtered resources.
[INFO] snapshot org.apache.xbean:xbean-reflect:3.0-SNAPSHOT: checking
for updates from apache-snapshots
[INFO] snapshot org.apache.xbean:xbean-reflect:3.0-SNAPSHOT: checking
for updates from axis2-m2-repo
[INFO] snapshot org.apache.xbean:xbean-reflect:3.0-SNAPSHOT: checking
for updates from codehaus-snapshots
[INFO] snapshot org.apache.xbean:xbean-reflect:3.0-SNAPSHOT: checking
for updates from apache.snapshots
Downloading: http://people.apache.org/repo/m2-snapshot-repository/org/
apache/xbean/xbean-reflect/3.0-SNAPSHOT/xbean-
reflect-3.0-20070306.132215-1.pom
660b downloaded
[INFO] snapshot org.apache.xbean:xbean:3.0-SNAPSHOT: checking for
updates from apache-snapshots
[INFO] snapshot org.apache.xbean:xbean:3.0-SNAPSHOT: checking for
updates from axis2-m2-repo
[INFO] snapshot org.apache.xbean:xbean:3.0-SNAPSHOT: checking for
updates from codehaus-snapshots
[INFO] snapshot org.apache.xbean:xbean:3.0-SNAPSHOT: checking for
updates from apache.snapshots
Downloading: http://people.apache.org/repo/m2-snapshot-repository/org/
apache/xbean/xbean/3.0-SNAPSHOT/xbean-3.0-20070306.132215-2.pom
13K downloaded
Downloading: http://people.apache.org/repo/m2-snapshot-repository/org/
apache/xbean/xbean-reflect/3.0-SNAPSHOT/xbean-
reflect-3.0-20070306.132215-1.jar
76K downloaded
[INFO] [compiler:compile]
[INFO] Compiling 5 source files to /home/anthill/anthill3/agent/var/
jobs/projects/Geronimo_Components/build_trunk/project/modules/
geronimo-client/target/classes
[INFO]
[ERROR] BUILD FAILURE
[INFO]
[INFO] Compilation failure
/home/anthill/anthill3/agent/var/jobs/projects/Geronimo_Components/
build_trunk/project/modules/geronimo-client/src/main/java/org/apache/
geronimo/client/AppClientContainer.java:[157,37] cannot find symbol
symbol : variable STATIC_PROPERTIES
location: class org.apache.xbean.recipe.Option
/home/anthill/anthill3/agent/var/jobs/projects/Geronimo_Components/
build_trunk/project/modules/geronimo-client/src/main/java/org/apache/
geronimo/client/AppClientContainer.java:[157,37] cannot find symbol
symbol : variable STATIC_PROPERTIES
location: class org.apache.xbean.recipe.Option
[INFO]
[INFO] Trace
org.apache.maven.BuildFailureException: Compilation failure
/home/anthill/anthill3/agent/var/jobs/projects/Geronimo_Components/
build_trunk/project/modules/geronimo-client/src/main/java/org/apache/
geronimo/client/AppClientContainer.java:[157,37] cannot find symbol
symbol : variable STATIC_PROPERTIES
location: class org.apache.xbean.recipe.Option
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals
(DefaultLifecycleExecutor.java:560)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifec
ycle(DefaultLifecycleExecutor.java:480)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal
(DefaultLifecycleExecutor.java:459)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandle
Failures(DefaultLifecycleExecutor.java:311)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(
DefaultLifecycleExecutor.java:278)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute
(DefaultLifecycleExecutor.java:143)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:330)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:123)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:272)
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:585)
at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
at
