[Design of JBoss Web Services] - jUDDI tables dropped at server shutdown
by thomas.diesler＠jboss.com
Kurt Stam [12/Nov/07 08:54 AM]
what do you think is causing the tables to be dropped? I have never seen this. How do I reproduce it? We have no code that does that, apart from code in the unittests that is.
Kevin Conner [12/Nov/07 11:14 AM]
This seems to be an issue with the SOA platform, there is a jUDDI configuration in juddi-service.sar. This configuration sets DropOnStop as true.
I don't think this is one for us. :)
Kevin Conner [12/Nov/07 11:17 AM]
Kurt, can you take a look at the SOA platform and advise Trevor on this? Is it safe for him just to remove this sar file?
Kurt Stam [12/Nov/07 11:30 AM]
Yes it should be removed. The juddi that comes with AS is much older then the one we use in ESB.
Mark Little [12/Nov/07 11:33 AM]
JBossWS uses jUDDI, so I assume it's coming from there. Someone needs to talk to Thomas Diesler first.
Kurt Stam [12/Nov/07 11:36 AM]
I guess we (ESB) should deploy the juddi.war by default, so we bring up the juddi WSs and then run whatever tests JBossAS has for this to make sure it all still works.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4104506#4104506
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4104506
16 years, 6 months
[Design of JBoss Web Services] - Re: [Productivity] Level 1 - Start from scratch
by max.andersen＠jboss.com
anonymous wrote :
| 1) The only WS tooling we have right now in RHDS is what comes with Eclipse WTP (and that is mainly axis biased)
|
| 2) We *want* to get SoapUI back into the JBossTools build again - once when we get over the release hurdle of JBossTools/RHDS GA this will be a priority
OK, these are 2 important things, thanks for stating them clearly.
In particular I also think it will be really good to have the SoapUI plugin back in the build again; I expect this integration to give JBossTools the same functions RHDS has from the WTP Eclipse, but based on JBossWS instead of Axis.
SoapUI and the Eclipse WTP integration are not integrated afaik. They have different purposes in life.
The bad news is that soapui is not going to continue supporting the jbossws specific parts of their tooling anymore - This might not be a big issue if JBossWS are going to change some of their tool/stack....is there any status/updates on that ? (I haven't followed it closely - I just heard it was on the table of upcoming changes)
anonymous wrote :
| 3) Be aware that just because something is in JBoss Tools does not mean it will show up in RHDS
Does this simply means that things from JBossTools are not automatically coded into RHDS too, but they require additional work and this depends on strategic decisions about RHDS features, or I am missing something else?
RHDS goal is to match what is in the JBoss EAP platform and related products. That can result in things being excluded; also if something in jbosstools is deemed not mature enough for full support we will exclude it or simply disable it by default in RHDS and giving the option for theuser to enable it (with the notice it is not supported)
But the general rule is that JBossTools has all the new things and RHDS will follow that as closely as possible.
anonymous wrote :
| 5) Providing Ant or Maven kind of samples is good - neither of these exclude good JBoss Tools support as long as they are done correctly
|
| 6) We/you shouldn't just go out and create an isolated WS-way of creating sample/projects - look into how the eclipse best support it...just using Eclipse as an glorified text editor to calling ant isn't really adding value ;)
I agree with you, Ant based samples and JBoss Tools / Eclipse support do not exclude each other and I believe providing both is the right things to do. In particular on point 6, I think I get the overall idea that is, of course, let's leverage what Eclipse is beyond a powerful text editor to provide ws added value. May be we might go a bit further into details on this in future..
yup.
anonymous wrote : 7) We need someone who knows about WS to build proper WS support into tooling....preferably someone who likes to do both WS and write plugins ;)
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4104228#4104228
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4104228
16 years, 6 months
[Design of JBoss Web Services] - Re: [Productivity] Level 4 - Production
by alessio.soldano＠jboss.com
Hi Stefano,
"maeste" wrote : What I would jbossws provide at this level is a sophisticated log system, giving me the opportunity to understand who is using my service and how.
| My idea is to provide a log (and docs to explain how to enable/disable or set a dedicated file and so on) awstats compatible. I know awstats is designed for web apps, but I think you (we if I get time to contribute) can think how to provide compatible logs, because it is grat for immediate statistic and graphs.
Graphical stats have the plus of being really powerful in providing informations in a way that is both brief and effective. For this reason I like your idea of giving the ws administrator a mean of viewing stats graphically.
We have to think how this could be achieved; for example the informations we are interested in might be not all in the http header; most probably we would have to create a new log format and something able to deal with it (perhaps using awstat).
Anyway, generally speaking, I think the idea of having something like a WS log repository to query with different filters for getting informations on both pre-defined and custom (the admin decides through the jmx-console) time period is definitively interesting.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4104221#4104221
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4104221
16 years, 6 months
[Design of JBoss Web Services] - Re: [Productivity] Level 1 - Start from scratch
by alessio.soldano＠jboss.com
Hi Max,
thanks for the time spent in reading these threads.
"max.andersen(a)jboss.com" wrote : 0) I am not a big WS guy - I've found WS to be to clunky to be bothered with; mainly because even with tooling WS is an XML hell and waaay to compliated (I know the annotated way make this more managable but annotation solutions didn't exist when I had to bother with web services ;) - Just know that when I in the future ask some stupid WS beginner question or assume too much or too litle about WS. It's almost the opposite for me, never worked at plugin development before.
anonymous wrote :
| 1) The only WS tooling we have right now in RHDS is what comes with Eclipse WTP (and that is mainly axis biased)
|
| 2) We *want* to get SoapUI back into the JBossTools build again - once when we get over the release hurdle of JBossTools/RHDS GA this will be a priority
OK, these are 2 important things, thanks for stating them clearly.
In particular I also think it will be really good to have the SoapUI plugin back in the build again; I expect this integration to give JBossTools the same functions RHDS has from the WTP Eclipse, but based on JBossWS instead of Axis.
anonymous wrote :
| 3) Be aware that just because something is in JBoss Tools does not mean it will show up in RHDS
Does this simply means that things from JBossTools are not automatically coded into RHDS too, but they require additional work and this depends on strategic decisions about RHDS features, or I am missing something else?
anonymous wrote :
| 4) Looking into how you can integrate your docs/samples with Eclipse Cheatsheets would be very interesting
Thanks for the suggestion, I'll think about this too.
anonymous wrote :
| 5) Providing Ant or Maven kind of samples is good - neither of these exclude good JBoss Tools support as long as they are done correctly
|
| 6) We/you shouldn't just go out and create an isolated WS-way of creating sample/projects - look into how the eclipse best support it...just using Eclipse as an glorified text editor to calling ant isn't really adding value ;)
I agree with you, Ant based samples and JBoss Tools / Eclipse support do not exclude each other and I believe providing both is the right things to do. In particular on point 6, I think I get the overall idea that is, of course, let's leverage what Eclipse is beyond a powerful text editor to provide ws added value. May be we might go a bit further into details on this in future..
anonymous wrote : 7) We need someone who knows about WS to build proper WS support into tooling....preferably someone who likes to do both WS and write plugins ;)
I understand what you mean. After and apart having SoapUi back, further WS tooling efforts will of course require our contribution.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4104150#4104150
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4104150
16 years, 6 months
Created Tag Structure for old jbossws-wsconsume-impl
by Jason T. Greene
Awhile back it was noted that the jbossws-wsconsume-impl project did not
have a proper release tag. At the time I couldn't restructure the
project since my rights were somehow dropped. Thomas had them re-added,
but, I must have forgotten to recommit the changes (sorry). This has
finally been corrected.
--
Jason T. Greene
JBoss, a division of Red Hat
16 years, 6 months
Re: Jira issues fix version
by Thomas Diesler
Hi Allesio/Team,
when you resolve an issue in trunk you set the "fix version" to the next
release that is not in QA (i.e. we have a QA branch for it) already. In
your case this would be 2.0.3
Issues that are resolved as "won't fix", "cannot reproduce", etc should
not have a "fix version"
Please remember that we generate our release notes from the jira change
log. So everything that needs to go in there must have a jira issue
associated with it.
cheers
-thomas
On Tue, 2007-11-13 at 11:50 +0100, Alessio Soldano wrote:
> Hi Thomas,
> I'm marking as resolved the issues I fixed on my branch that has been
> merged to the trunk yesterday. I've a question concerning the "fix
> version" on JIRA: should I set them to be included in the next release
> coming from trunk (i.e. 2.0.3), or should I leave the fix version empty
> or set it to a generic 2.x version? Just to know how do we usually
> proceed with this thing.
> Thank you
> Alessio
--
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
Thomas Diesler
Web Service Lead
JBoss, a division of Red Hat
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
16 years, 6 months
[Design of JBoss Web Services] - No engine configuration file - aborting!
by dfillis
Hi All,
I
I am trying to access a web services deployed on JBoss4.0.3 SP1. When I execute the following line of code
javax.xml.rpc.Service service = factory.createService(wsdlLocation, serviceName);
I get the following error "org.jboss.axis.ConfigurationException: No engine configuration file"
The following extract explains the problem and proposes a workaround. However I am not sure how to implement the workaround, I would appreciate it if someone can give me some more detail on how to implement this solution.
The default org.jboss.axis.client.Service constructor will throw this exception. My particular case involves creating a new Service object from within an EJB, but this should occur with any client.
Tracing through the code, I discovered that org.jboss.axis.configuration.EngineConfigurationFactoryDefault defines the default filenames for the client configuration as "client-config.wsdd", while the actual file distributed with jboss-ws4ee-client.jar is "axis-client-config.xml". When the Service object is constructed, org.jboss.axis.configuration.FileProvider looks on the classpath for "client-config.wsdd", and of course can't find it.
The workaround specified in JBAS-1106 puts a file with the correct name but possibly the wrong configuration information onto the classpath, where FileProvider can find it. This will work for a standalone client, but not for client code within an EJB, since the Axis packages appear to be loaded with a different classloader than that for the EJB.
The workaround is to provide the Service constructor with a FileProvider that specifies the correct configuration file:
new Service(new FileProvider("META-INF/axis-client-config.xml"))
My source code to invoke the web service is as follows
// create service factory
javax.xml.rpc.ServiceFactory factory = javax.xml.rpc.ServiceFactory.newInstance();
// define targetNameSpace
String targetNamespace = "http://www.openkm.org/";
// + "wsdl/net.xmethods.services.stockquote.StockQuote/";
// define qname
QName serviceName =
new QName(targetNamespace,"OKMAuthService");
// define porname
QName portName =
new QName(targetNamespace,"OKMAuthPort");
// define operation name
QName operationName = new QName("http://localhost:8080/OpenKM/OKMAuth",
"login");
//Specify wsdl location
java.net.URL wsdlLocation =
new java.net.URL("http://localhost:8080/OpenKM/OKMAuth?wsdl");
// create service
javax.xml.rpc.Service service = factory.createService(wsdlLocation, serviceName);
// create call
javax.xml.rpc.Call call = service.createCall(portName, operationName);
Thanks in advance
Denzil
My source code is as follows
public String login() throws Exception {
//Method level variables
String token;
try {
// create service factory
javax.xml.rpc.ServiceFactory factory = javax.xml.rpc.ServiceFactory.newInstance();
// define targetNameSpace
String targetNamespace = "http://www.openkm.org/";
// + "wsdl/net.xmethods.services.stockquote.StockQuote/";
// define qname
QName serviceName =
new QName(targetNamespace,"OKMAuthService");
// define porname
QName portName =
new QName(targetNamespace,"OKMAuthPort");
// define operation name
QName operationName = new QName("http://localhost:8080/OpenKM/OKMAuth",
"login");
//Specify wsdl location
java.net.URL wsdlLocation =
new java.net.URL("http://localhost:8080/OpenKM/OKMAuth?wsdl");
// create service
javax.xml.rpc.Service service = factory.createService(wsdlLocation, serviceName);
// new Service(new FileProvider("META-INF/axis-client-config.xml"))
// create call
javax.xml.rpc.Call call = service.createCall(portName, operationName);
String login = "user1 " + "pass1";
// invoke the remote web service
token = (String) call.invoke(new Object[] {login});
}
org.jboss.axis.ConfigurationException: org.jboss.axis.ConfigurationException: No engine configuration file - aborting!
org.jboss.axis.ConfigurationException: No engine configuration file - aborting!
at org.jboss.axis.configuration.FileProvider.configureEngine(FileProvider.java:222)
at org.jboss.axis.AxisEngine.init(AxisEngine.java:150)
at org.jboss.axis.AxisEngine.(AxisEngine.java:132)
at org.jboss.axis.client.AxisClient.(AxisClient.java:88)
at org.jboss.axis.client.Service.getAxisClient(Service.java:370)
at org.jboss.axis.client.Service.(Service.java:180)
at org.jboss.axis.client.ServiceFactory.createService(ServiceFactory.java:246)
at com.mpilo.fourier.dms.wsmanager.subscriber.AuthModuleWSManager.login(AuthModuleWSManager.java:86)
at com.mpilo.fourier.dms.web.action.SaveOrCreateDocumentAction.execute(SaveOrCreateDocumentAction.java:66)
at org.apache.struts.action.RequestProcessor.processActionPerform(RequestProcessor.java:419)
at org.apache.struts.action.RequestProcessor.process(RequestProcessor.java:224)
at org.apache.struts.action.ActionServlet.process(ActionServlet.java:1194)
at org.apache.struts.action.ActionServlet.doPost(ActionServlet.java:432)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:810)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:81)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:178)
at org.jboss.web.tomcat.security.CustomPrincipalValve.invoke(CustomPrincipalValve.java:39)
at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:159)
2007-11-06 21:01:51,593 INFO [STDOUT] at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:482)
at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:59)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148)
at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:856)
at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.processConnection(Http11Protocol.java:744)
at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:527)
at org.apache.tomcat.util.net.MasterSlaveWorkerThread.run(MasterSlaveWorkerThread.java:112)
at java.lang.Thread.run(Thread.java:595)
org.jboss.axis.ConfigurationException: No engine configuration file - aborting!
org.jboss.axis.ConfigurationException: No engine configuration file - aborting!
at org.jboss.axis.configuration.FileProvider.configureEngine(FileProvider.java:222)
at org.jboss.axis.AxisEngine.init(AxisEngine.java:150)
at org.jboss.axis.AxisEngine.(AxisEngine.java:132)
at org.jboss.axis.client.AxisClient.(AxisClient.java:88)
at org.jboss.axis.client.Service.getAxisClient(Service.java:370)
at org.jboss.axis.client.Service.(Service.java:180)
at org.jboss.axis.client.ServiceFactory.createService(ServiceFactory.java:246)
at com.mpilo.fourier.dms.wsmanager.subscriber.AuthModuleWSManager.login(AuthModuleWSManager.java:86)
at com.mpilo.fourier.dms.web.action.SaveOrCreateDocumentAction.execute(SaveOrCreateDocumentAction.java:66)
at org.apache.struts.action.RequestProcessor.processActionPerform(RequestProcessor.java:419)
at org.apache.struts.action.RequestProcessor.process(RequestProcessor.java:224)
at org.apache.struts.action.ActionServlet.process(ActionServlet.java:1194)
at org.apache.struts.action.ActionServlet.doPost(ActionServlet.java:432)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:810)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:81)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:178)
at org.jboss.web.tomcat.security.CustomPrincipalValve.invoke(CustomPrincipalValve.java:39)
at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:159)
at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:482)
at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:59)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148)
at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:856)
at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.processConnection(Http11Protocol.java:744)
at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:527)
at org.apache.tomcat.util.net.MasterSlaveWorkerThread.run(MasterSlaveWorkerThread.java:112)
at java.lang.Thread.run(Thread.java:595)
at org.jboss.axis.configuration.FileProvider.configureEngine(FileProvider.java:222)
at org.jboss.axis.AxisEngine.init(AxisEngine.java:150)
at org.jboss.axis.AxisEngine.(AxisEngine.java:132)
at org.jboss.axis.client.AxisClient.(AxisClient.java:88)
at org.jboss.axis.client.Service.getAxisClient(Service.java:370)
at org.jboss.axis.client.Service.(Service.java:180)
at org.jboss.axis.client.ServiceFactory.createService(ServiceFactory.java:246)
at com.mpilo.fourier.dms.wsmanager.subscriber.AuthModuleWSManager.login(AuthModuleWSManager.java:86)
at com.mpilo.fourier.dms.web.action.SaveOrCreateDocumentAction.execute(SaveOrCreateDocumentAction.java:66)
at org.apache.struts.action.RequestProcessor.processActionPerform(RequestProcessor.java:419)
at org.apache.struts.action.RequestProcessor.process(RequestProcessor.java:224)
at org.apache.struts.action.ActionServlet.process(ActionServlet.java:1194)
at org.apache.struts.action.ActionServlet.doPost(ActionServlet.java:432)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:810)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:81)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:178)
at org.jboss.web.tomcat.security.CustomPrincipalValve.invoke(CustomPrincipalValve.java:39)
at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:159)
at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:482)
at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:59)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148)
at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:856)
at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.processConnection(Http11Protocol.java:744)
at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:527)
at org.apache.tomcat.util.net.MasterSlaveWorkerThread.run(MasterSlaveWorkerThread.java:112)
at java.lang.Thread.run(Thread.java:595)
at org.jboss.axis.configuration.FileProvider.configureEngine(FileProvider.java:236)
at org.jboss.axis.AxisEngine.init(AxisEngine.java:150)
at org.jboss.axis.AxisEngine.(AxisEngine.java:132)
at org.jboss.axis.client.AxisClient.(AxisClient.java:88)
at org.jboss.axis.client.Service.getAxisClient(Service.java:370)
at org.jboss.axis.client.Service.(Service.java:180)
at org.jboss.axis.client.ServiceFactory.createService(ServiceFactory.java:246)
at com.mpilo.fourier.dms.wsmanager.subscriber.AuthModuleWSManager.login(AuthModuleWSManager.java:86)
at com.mpilo.fourier.dms.web.action.SaveOrCreateDocumentAction.execute(SaveOrCreateDocumentAction.java:66)
at org.apache.struts.action.RequestProcessor.processActionPerform(RequestProcessor.java:419)
at org.apache.struts.action.RequestProcessor.process(RequestProcessor.java:224)
at org.apache.struts.action.ActionServlet.process(ActionServlet.java:1194)
at org.apache.struts.action.ActionServlet.doPost(ActionServlet.java:432)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:810)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilte
2007-11-06 21:01:51,609 INFO [STDOUT] rChain.java:252)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:81)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:178)
at org.jboss.web.tomcat.security.CustomPrincipalValve.invoke(CustomPrincipalValve.java:39)
at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:159)
at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:482)
at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:59)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148)
at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:856)
at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.processConnection(Http11Protocol.java:744)
at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:527)
at org.apache.tomcat.util.net.MasterSlaveWorkerThread.run(MasterSlaveWorkerThread.java:112)
at java.lang.Thread.run(Thread.java:595)
at org.jboss.axis.AxisEngine.init(AxisEngine.java:154)
at org.jboss.axis.AxisEngine.(AxisEngine.java:132)
at org.jboss.axis.client.AxisClient.(AxisClient.java:88)
at org.jboss.axis.client.Service.getAxisClient(Service.java:370)
at org.jboss.axis.client.Service.(Service.java:180)
at org.jboss.axis.client.ServiceFactory.createService(ServiceFactory.java:246)
at com.mpilo.fourier.dms.wsmanager.subscriber.AuthModuleWSManager.login(AuthModuleWSManager.java:86)
at com.mpilo.fourier.dms.web.action.SaveOrCreateDocumentAction.execute(SaveOrCreateDocumentAction.java:66)
at org.apache.struts.action.RequestProcessor.processActionPerform(RequestProcessor.java:419)
at org.apache.struts.action.RequestProcessor.process(RequestProcessor.java:224)
at org.apache.struts.action.ActionServlet.process(ActionServlet.java:1194)
at org.apache.struts.action.ActionServlet.doPost(ActionServlet.java:432)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:810)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:81)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:178)
at org.jboss.web.tomcat.security.CustomPrincipalValve.invoke(CustomPrincipalValve.java:39)
at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:159)
at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:482)
at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:59)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148)
at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:856)
at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.processConnection(Http11Protocol.java:744)
at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:527)
at org.apache.tomcat.util.net.MasterSlaveWorkerThread.run(MasterSlaveWorkerThread.java:112)
at java.lang.Thread.run(Thread.java:595)
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4103358#4103358
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4103358
16 years, 6 months
[Design of JBoss Web Services] - Re: Deployment.types not propagated
by adrian＠jboss.org
"thomas.diesler(a)jboss.com" wrote : With the current API it seems the attachments that I get from
|
| org.jboss.deployers.client.spi.Deployment.getPredeterminedManagedObjects()
|
| are read only.
|
| Please show me the correct usage of a client using attachments
|
They're not read-only in the implementations.
It's just that the Deployment interface assumes that they might be read only,
i.e. you could implement Deployment yourself in a way that the attachments
are immutable.
You can in fact downcast the Attachments to a MutableAttachments
in the provided implementations.
| MutableAttachments attachments = (MutableAttachments) deployment.getPredeterminedManagedObjects();
|
Or if you don't like the cast, you can create an
MutableAttachments yourself and set it on the deployment
| VFSDeploymentFactory factory = new VFSDeploymentFactory();
| VFSDeployment deployment = factory.createDeployment(virtualFile);
| MutableAttachments attachments = new AttachmentsImpl();
| attachments.addAttachment("blah", serializable);
| deployment.setPredeterminedMangedObjects(myAttachments).
|
The latter is also method where you could replace AttachmentsImpl
with some form of immutable attachments implementation that loads
them using some other method.
e.g. the profile service might load them a database.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4103256#4103256
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4103256
16 years, 6 months
[Design of JBoss Web Services] - Re: [Productivity] Level 1 - Start from scratch
by max.andersen＠jboss.com
I finally got around to read through these various threads about WS and productivity efforts.
I don't disagree with much in these threads so let me just state some points that you might or might not be aware of ;)
0) I am not a big WS guy - I've found WS to be to clunky to be bothered with; mainly because even with tooling WS is an XML hell and waaay to compliated (I know the annotated way make this more managable but annotation solutions didn't exist when I had to bother with web services ;) - Just know that when I in the future ask some stupid WS beginner question or assume too much or too litle about WS.
1) The only WS tooling we have right now in RHDS is what comes with Eclipse WTP (and that is mainly axis biased)
2) We *want* to get SoapUI back into the JBossTools build again - once when we get over the release hurdle of JBossTools/RHDS GA this will be a priority
3) Be aware that just because something is in JBoss Tools does not mean it will show up in RHDS
4) Looking into how you can integrate your docs/samples with Eclipse Cheatsheets would be very interesting
5) Providing Ant or Maven kind of samples is good - neither of these exclude good JBoss Tools support as long as they are done correctly
6) We/you shouldn't just go out and create an isolated WS-way of creating sample/projects - look into how the eclipse best support it...just using Eclipse as an glorified text editor to calling ant isn't really adding value ;)
7) We need someone who knows about WS to build proper WS support into tooling....preferably someone who likes to do both WS and write plugins ;)
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4103236#4103236
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4103236
16 years, 6 months
