[JBoss AS7 Development] - What's causing this exception: org.jboss.wsf.spi.WSFException: Failed to provide SPI:class org.jboss.wsf.spi.management.ServerConfigFactory
by Jason Milliron
Jason Milliron [http://community.jboss.org/people/jm1468] created the discussion
"What's causing this exception: org.jboss.wsf.spi.WSFException: Failed to provide SPI:class org.jboss.wsf.spi.management.ServerConfigFactory"
To view the discussion, visit: http://community.jboss.org/message/634059#634059
--------------------------------------------------------------
Hello. I'm using the a very recent nightly release of JBoss 7 and can't get my webapp up with CXF webservices. Does anyone know how I can stop this exception from happening or why it is being thrown?
Caused by: javax.xml.ws.WebServiceException: org.jboss.wsf.spi.WSFException: Failed to provide SPI:class org.jboss.wsf.spi.management.ServerConfigFactory
at org.apache.cxf.jaxws.EndpointImpl.doPublish(EndpointImpl.java:350)
at org.jboss.wsf.stack.cxf.deployment.EndpointImpl.doPublish(EndpointImpl.java:88)
at org.apache.cxf.jaxws.EndpointImpl.publish(EndpointImpl.java:239)
at org.apache.cxf.jaxws.EndpointImpl.publish(EndpointImpl.java:509)
at org.jboss.wsf.stack.cxf.configuration.NonSpringBusHolder.configure(NonSpringBusHolder.java:116)
at org.jboss.wsf.stack.cxf.deployment.aspect.BusDeploymentAspect.startDeploymentBus(BusDeploymentAspect.java:109)
at org.jboss.wsf.stack.cxf.deployment.aspect.BusDeploymentAspect.start(BusDeploymentAspect.java:132)
at org.jboss.as.webservices.deployers.AspectDeploymentProcessor.deploy(AspectDeploymentProcessor.java:75)
at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:115) [jboss-as-server-7.1.0.Alpha2-SNAPSHOT.jar:7.1.0.Alpha2-SNAPSHOT]
... 5 more
Caused by: org.jboss.wsf.spi.WSFException: Failed to provide SPI:class org.jboss.wsf.spi.management.ServerConfigFactory
at org.jboss.ws.common.spi.DefaultSPIProvider.getSPI(DefaultSPIProvider.java:102)
at org.jboss.wsf.spi.SPIProvider.getSPI(SPIProvider.java:41)
at org.jboss.wsf.stack.cxf.transport.SoapTransportFactoryExt.getServerConfig(SoapTransportFactoryExt.java:102)
at org.jboss.wsf.stack.cxf.transport.SoapTransportFactoryExt.createEndpointInfo(SoapTransportFactoryExt.java:62)
at org.apache.cxf.frontend.AbstractWSDLBasedEndpointFactory.createEndpointInfo(AbstractWSDLBasedEndpointFactory.java:282)
at org.apache.cxf.frontend.AbstractWSDLBasedEndpointFactory.createEndpoint(AbstractWSDLBasedEndpointFactory.java:147)
at org.apache.cxf.frontend.ServerFactoryBean.create(ServerFactoryBean.java:157)
at org.apache.cxf.jaxws.JaxWsServerFactoryBean.create(JaxWsServerFactoryBean.java:202)
at org.apache.cxf.jaxws.EndpointImpl.getServer(EndpointImpl.java:433)
at org.apache.cxf.jaxws.EndpointImpl.doPublish(EndpointImpl.java:322)
... 13 more
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/634059#634059]
Start a new discussion in JBoss AS7 Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
12 years, 5 months
[JBoss Web Development] - Multiple Wars Sharing a Login Page
by James C
James C [http://community.jboss.org/people/jamesc1] created the discussion
"Multiple Wars Sharing a Login Page"
To view the discussion, visit: http://community.jboss.org/message/633969#633969
--------------------------------------------------------------
Greetings all.
I am currently using JBoss 6.1.0.Final
I have several EARs each with their own WAR. I am using the standard single sign on valve and form based authentication.
The intent is for the user to go to a WAR's URL, be redirected to a login page, and then be sent back to their original page. I would like it if all the WAR's could share a login page.
Problem one occurs because I can not access a page outside of the war. For example given these three domains
/main
/sub1
The WAR associated with the /sub1 domain can not point to /main/login.jsp. If I attempt it then I simply go to the page /sub1/main/login.jsp.
I have a attempted a simple redirect page in /sub1 pointing to the login page in /main. The problem with that is that after authenticating the SSO Valve forwards you to the last page which was the redirect to the login page causing what would be a nasty loop but results in the error "Invalid direct reference to form login page"
Is there any way to pass along the actual original request url?
What are some solutions to this problem other than including the login fucntionality in every war?
I don't mind making custom valves or filters if necessary however, I have read about failed attempts to add a filter for j_security_check.
The only thing I have on the table right now is to extend the FormAuthenticator and add in the functionality to pass in an original url in a parameter but I would think that this is not an uncommon problem with a better solutions.
Any suggestions and/or advice welcome.
Let me know if I need to provide more information or elaborate on anything.
Thanks in advance.
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/633969#633969]
Start a new discussion in JBoss Web Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
12 years, 5 months
[JBoss Transactions Development] - remote tx inflow: timeouts
by Tom Jenkinson
Tom Jenkinson [http://community.jboss.org/people/tomjenkinson] created the discussion
"remote tx inflow: timeouts"
To view the discussion, visit: http://community.jboss.org/message/630241#630241
--------------------------------------------------------------
I have just been discussing this with Jonathan and the we are proposing the following approach to transaction timeout.
1. When the transport determines that the transaction is flowing to a different server, it should query TransactionTimeoutConfiguration to find out how long is left for the transaction by calling: getTimeLeftBeforeTransactionTimeout
2. It flows this value over to the remote side and calls SubordinationManager.getTransactionImporter().importTransaction(xid, timeout) with a timeout equal to this original value plus a value (for the purposes of this discussion we can call it a fudgefactor)
Why the need for the fudgefactor?
Basically we need to ensure that the subordinate transactions do not timeout before the parent transaction. If such a situation arises then the transaction when it tries to complete will get a heuristic. Why? Well basically after the subordinate transaction rollsback at time T (because of the timeout) then it will clean up after itself. Now when the parent tries to rollback the transaction (at time T+1) the subordinate will not know about the transaction. This will cascade a rollback but a heuristic one which is not great.
Ideally we would have the parent transaction manager responsible for monitoring the timeout and cascading this down, but if the root fails (or a link in the chain) then locks would be help indefinitely until that node resumed.
If we have a directly connected transport that can determine when a linked node fails then we could remove the fudgefactor and look at implementing an immediate rollback in the case of parent/child failure...
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/630241#630241]
Start a new discussion in JBoss Transactions Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
12 years, 6 months
[JBoss Transactions Development] - Re: Remote txinflow: XID changes
by Tom Jenkinson
Tom Jenkinson [http://community.jboss.org/people/tomjenkinson] created the discussion
"Re: Remote txinflow: XID changes"
To view the discussion, visit: http://community.jboss.org/message/632161#632161
--------------------------------------------------------------
Hi,
The implementation for this issue (registered as https://issues.jboss.org/browse/JBTM-916 https://issues.jboss.org/browse/JBTM-916) has been put back to svn.
The implementation I went for structures the XID as follows:
int formatId = // new sequential number
byte[] globalTransactionId = // Uid + Node name of transaction originator
byte[] branchQualifier = // Uid + Node name of subordinate + Node name of subordinates parent + EIS name
In order to fit the node names in the space available they have had to be encoded as integers (rather than strings as they used to be). I appreciate from Davids points above that this will add configuration complexity as nodes must be assigned a unique transaction manager identifier and remoting string but at the moment I can't really see any other way around this (I will elaborate further below on why the data is required).
I am happy for the node names to be changed back to Strings, but we have a space issue then which would definitely need addressing.
The space we are most constrained by is the bqual, it must contain a Uid is 28 bytes (this guarantees we have a globally unique identifier for any particular branch), it also needs two node identifiers which I opted for using integers (i.e. 2 x 4) , and an EIS name that can consume the remaining part of the bqual and is typically the JNDI name of the resource which can be up to 28 bytes. If there was someway to compress three reasonable length strings into the bqual (or put another way we can be certain that two string node names and an EIS resource name can be encoded into javax.transaction.xa.Xid.MAXBQUALSIZE - com.arjuna.ats.arjuna.common.Uid.UID_SIZE bytes [64 -28]) then it is a trivial change to revert node names back to Strings.
Now, onto the reasoning for why the data is required at each point, before this I will clarify one piece of terminology:
orphan resource = a resource that has prepared and stored an XID but where the transaction manager did not have chance to write out a record of the XAResource before it crashed
A> global transaction ID - This definitely needs a UID for uniqueness, it also needs the node name encoding in it so that orphaned (JTA) resources can be rolled back.
B> branch qualifier - Each RM needs a identifier unique within the global transaction ID, it also needs the subordinate node name to ensure the transport is able to filter out Xids returned from the XATerminator recover method so that different root transaction managers don't try to recover each others transactions. It also needs a subordinates parent node name for a similar reasoning to the node name encoded into the gtrid, i.e. to ensure that when a recovery manager for the suboridnate starts up it can detect XA resources of a subordinate transaction where the XAResource prepared and stored the Xid but the subordinate transaction itself failed to prepare.
In terms of the bqual, it is not an absolutely vital component to store the parent node name. If you look at https://svn.jboss.org/repos/labs/labs/jbosstm/branches/JBOSSTS_4_15_0_Fin... https://svn.jboss.org/repos/labs/labs/jbosstm/branches/JBOSSTS_4_15_0_Fin... -r 37583 you can see that as I have a single ProxyXAResource per Xid and not a single XAR for all Xids I am able to filter the Xids returned from XATerminator.recover on format ID and gtrid alone. This is because I know that per subordinate transaction there should only ever be one single proxy XA resource talking to it (see the design discussion I am about to create for more details on this). Providing the parent node name though allows you to create a proxy XA resource that can recover all XIDs for a subordinate in one go, rather than calling recover multiple times.
Hopefully this clarifies the motivation why the Xid has been encoded as it has and why I have had to move to integers for node names.
Tom
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/632161#632161]
Start a new discussion in JBoss Transactions Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
12 years, 6 months
[JBoss AS7 Development] - Logging Id's
by James Perkins
James Perkins [http://community.jboss.org/people/jamezp] modified the document:
"Logging Id's"
To view the document, visit: http://community.jboss.org/docs/DOC-16810
--------------------------------------------------------------
These are ranges used for JBoss AS logging ids.
|| *Range* || *Subsystem
* || *Completed
* ||
| *10100 - 10199* | *Transaction* | Y |
| *10200 - 10399
* | *Clustering**
* | Y |
| *10400 - 10499* | *Connector**
* | Y |
| *10500 - 10599* | *Controller**
* |
|
| *10600 - 10699* | *Controller Client* |
|
| *10700 - 10799* | *Deployment Repository* |
|
| *10900 - 10999* | *Deployment Scanner* |
|
| *11000 - 11099* | *EE* |
|
| *11100 - 11199* | *Embedded* |
|
| *11200 - 11299* | *JAXRS* |
|
| *11300 - 11399* | *JMX* |
|
| *11400 - 11499* | *JPA* | Y |
| *11500 - 11599* | *Logging* | Y |
| *11600 - 11699* | *Messaging* | Y |
| *11700 - 11799* | *mod_cluster* | Y |
| *11800 - 11899* | *Naming* | Y |
| *11900 - 11999* | *OSGi (as plugin 00-10; service 11-99)* | Y |
| *12000 - 12099* | *Process Controller* | Y |
| *12100 - 12199* | *Protocol* | Y |
| *13100 - 13199* | *Security* |
|
| *14100 - 14399* | *Ejb3* |
|
| *14400 - 14500* | *AppClient* |
|
--------------------------------------------------------------
Comment by going to Community
[http://community.jboss.org/docs/DOC-16810]
Create a new document in JBoss AS7 Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=102&co...]
12 years, 6 months
[JBoss AS7 Development] - @EJB(lookup) fails while context.lookup() is successfull
by Dan Sirbu
Dan Sirbu [http://community.jboss.org/people/lmcdasi] created the discussion
"@EJB(lookup) fails while context.lookup() is successfull"
To view the discussion, visit: http://community.jboss.org/message/632790#632790
--------------------------------------------------------------
I have a war file that has an EJB. @EJB(lookup="java:global/test-war/LcExample!<mypkg>.example.api.ILcExample") fails to do the injection while initialContext.lookup("java:global/test-war/LcExample!<mypkg>.example.api.ILcExample") returns the ejb object.
I am wondering what do I do wrong or how it is suppose to work by using @EJB. The war content is :
0 Thu Oct 20 10:10:48 EDT 2011 META-INF/
126 Thu Oct 20 10:10:46 EDT 2011 META-INF/MANIFEST.MF
0 Thu Oct 20 10:10:48 EDT 2011 WEB-INF/
0 Thu Oct 20 10:10:48 EDT 2011 WEB-INF/classes/
0 Thu Oct 20 10:10:48 EDT 2011 WEB-INF/classes/com/
0 Thu Oct 20 10:10:48 EDT 2011 WEB-INF/classes/com/.../
0 Thu Oct 20 10:10:48 EDT 2011 WEB-INF/lib/
0 Thu Oct 20 10:10:48 EDT 2011 css/
0 Thu Oct 20 10:10:48 EDT 2011 docs/
0 Thu Oct 20 10:10:48 EDT 2011 images/
448 Thu Oct 20 10:01:02 EDT 2011 WEB-INF/jboss-web.xml
1297 Thu Oct 20 09:44:42 EDT 2011 WEB-INF/web.xml
6756 Thu Oct 20 10:10:46 EDT 2011 WEB-INF/classes/com/.../FmHandler.class
2528 Thu Oct 20 10:10:46 EDT 2011 WEB-INF/classes/com/.../CmListener.class
5730 Thu Oct 20 10:10:46 EDT 2011 WEB-INF/classes/com/.../CmHandler.class
1152 Thu Oct 20 10:10:46 EDT 2011 WEB-INF/classes/com/.../LicHandler$SentinelLicenses.class
4534 Thu Oct 20 10:10:46 EDT 2011 WEB-INF/classes/com/.../LicHandler.class
3633 Thu Oct 20 10:10:46 EDT 2011 WEB-INF/classes/com/.../PmHandler.class
6470 Thu Oct 20 10:10:46 EDT 2011 WEB-INF/classes/com/.../Example.class <<-- If I do the @EJB on the Example class that exteds HttpServlet then here the @EJB works without no lookup need it.
12067 Thu Oct 20 10:10:44 EDT 2011 WEB-INF/lib/mgmt-ejb-P1A01.jar << -- EJB ifc
1390 Thu Oct 20 09:44:42 EDT 2011 css/test.css
3102 Thu Oct 20 09:44:42 EDT 2011 docs/cm.html
7051 Thu Oct 20 09:44:42 EDT 2011 docs/fm.html
6180 Thu Oct 20 09:44:42 EDT 2011 docs/lc.html
4034 Thu Oct 20 09:44:42 EDT 2011 docs/lm.html
3439 Thu Oct 20 09:44:42 EDT 2011 docs/pm.html
1929 Thu Oct 20 09:44:42 EDT 2011 images/logo.gif
8841 Thu Oct 20 09:44:42 EDT 2011 index.jsp
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/632790#632790]
Start a new discussion in JBoss AS7 Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
12 years, 6 months