Re: [jboss-user] [JBoss Tools] - WEB-INF/lib remains empty after deployment
by henk de boer
henk de boer [http://community.jboss.org/people/henk53] replied to the discussion
"WEB-INF/lib remains empty after deployment"
To view the discussion, visit: http://community.jboss.org/message/541102#541102
--------------------------------------------------------------
> This seems very very familiar to https://jira.jboss.org/jira/browse/JBIDE-6024 https://jira.jboss.org/jira/browse/JBIDE-6024
Indeed it does. However, we did just encounter exactly the same problem deploying to a Tomcat instance using the WTP supplied server adapter. We added libs to our project, outside of WEB-INF/lib. Added them to the .classpath and marked them as web library dependencies.
After a redeploy, the new libs weren't deployed, but the old ones were. The simple close, open, redeploy cycle didn't help here. Eventually, after much trial and error suddenly the following seemed to fix the problem: close, open, remove deployment, clean, add deployment.
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/541102#541102]
Start a new discussion in JBoss Tools at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
15 years, 7 months
Re: [jboss-user] [JBoss Web Services] - Need advise on defining a webservice client for Teiid
by Alessio Soldano
Alessio Soldano [http://community.jboss.org/people/alessio.soldano%40jboss.com] replied to the discussion
"Need advise on defining a webservice client for Teiid"
To view the discussion, visit: http://community.jboss.org/message/541079#541079
--------------------------------------------------------------
> Ramesh Reddy wrote:
>
> Hi,
>
> In http://teiid.org Teiid project, we provide "connectors" that consume XML based data from variety of sources including "web-services" for data integration purposes. Previously, Teiid was running in its own VM, so we provided custom web service client code using the JAX-WS "Dispatch" interface and Axis2's Call interface to invoke the web-service calls along with Teiid's own configuration.
>
> In 7.0 release of Teiid, we are working towards integrating the Teiid into JBoss AS and re-evaluating our data consumption model. In this environment, we feel it is probably verbose for us to provide yet another way to configure web-service client. We want to use any predefined methods that are in work through JBossWS project.
>
> The requirements are
> - Should be able to invoke Doclitral/wrapped service
> - Shoud be able to invoke a JAX-RPC based service
> - REST support would be great
>
> We want users to define a web-service client using some configuration in the AS, then when the user supplies the bound service name to the Teiid, Teiid should be dynamically able to invoke the call on the service and grab results. Dispatch is perfect, but all examples show them how to use in the code, not through configuration. We are willing to extend any technique to fit our needs. Any advise for us?
>
>
> Thank you.
>
> Ramesh..
JBossWS implements JAX-WS API, hence that's what you should be using. Speaking of client side, yes dispatch is probably the solution that gives you better flexibility, as you basically send the xml message you want. Besides that, there're jbossws specific configurations for advanced things like ws-security, mtom, ... you should refer to the documentation for that ( http://community.jboss.org/wiki/JBossWS http://community.jboss.org/wiki/JBossWS)
I might be missing the real point here, but if you're looking for "predefined", "smart", "different" ways for defining a client, you might want to look at what JBoss ESB does. Also JBoss Wise might be interesting to you, given its facilities for simplified jaxws client programming.
DocLit vs Wrapped is not a problem at all, supported by JBossWS implementation.
JAX-RPC is implemented by JBossWS-Native and available with CXF and Metro based stack starting from AS 6 M3.
REST is out of scope for JBossWS, you should refer to RestEasy project.
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/541079#541079]
Start a new discussion in JBoss Web Services at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
15 years, 7 months
Re: [jboss-user] [JCA Development] - JcaXAResourceRecovery
by Jesper Pedersen
Jesper Pedersen [http://community.jboss.org/people/jesper.pedersen] replied to the discussion
"JcaXAResourceRecovery"
To view the discussion, visit: http://community.jboss.org/message/541069#541069
--------------------------------------------------------------
> I may be misunderstandin ghte model, but it seems that ManagedConnectionFactoryDeployment.getXAResources() creates a new connection on each call, which is good in that if the db crashes and recovers whilst the app servers stays up, the system will effectively reconnect rather than continuing to use a stale connection. However, as far as I can tell, it's never disposing those connections. Since the recovery system will make one pass every two minutes by default, it's going to leak pretty badly. The integration SPI does not allow for explicit disposal, so the best bet is probably to keep a handle on the last connection used and on each call to getXAResources either validate it (i.e. ping the db to make sure it's still there) and reuse it, or explicitly release it and get a new one.
Fixed. Thanks.
As to the explicit close case - I need to know when recovery have been done in order to cleanup and destroy the managed connection, and the JCA API doesn't have an SPI for that (yet). Maybe we could add recoveryBegin() and recoveryEnded() to our interface ?
As to the validate case - I'll think about what we can do to best handle this case and commit something, if we aren't going with the idea above.
> The XAResourceWrapperImpl usage appears to be applied only to XAResources used for recovery, not he ones used during normal transaction usage. It would be helpful to have the same wrapping applied to the XAResource handed out to the transaction manager during normal operation, as that would allow correlation in the logs between the tx run and the recovery. I'm guessing that's a fairly minor cutnpaste type fix - any chance of squeezing it in?
Normal transaction usage is handled in the TxConnectionManager class, where the interface is used (if enabled). So we should be good in that case :)
There is room for a lot of improvements both in the JCA spec and the JCA container to make life easier for our users - I'll keep this in mind for the new implementation.
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/541069#541069]
Start a new discussion in JCA Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
15 years, 7 months
Re: [jboss-user] [JBoss Web Services Development] - CXF jms integration
by Richard Opalka
Richard Opalka [http://community.jboss.org/people/richard.opalka%40jboss.com] replied to the discussion
"CXF jms integration"
To view the discussion, visit: http://community.jboss.org/message/541050#541050
--------------------------------------------------------------
Hi Jim,
let me agree with Alessio. We really don't need to introduce
another DD (jbossws-endpoints.xml namely). There are two reasons for that:
* XML configuration duplicity (as Alessio properly said users can just provide jbossws-cxf.xml with all the configuration)
* simplicity (our current SPI facade should be enough for you to do the job).
What you're doing (providing jbossws-endpoints.xml) is just creating WS stack agnostic configuration.
But our SPI is intended exactly for that purpose.
Providing additional DD is the same thing like our SPI (just different XML-ized form of it).
If you will follow my suggestions I wrote few days before you shoudn't face "real" problems.
Another thing/issue is our SPI is not perfect (and we know that).
We will improve/rewrite our SPI once we'll be done with all the
highier priority tasks we have these days.
> Jim Ma wrote:
> I evaluated to make new SPI metadata to extend the current SPI Endpoint. But I did not find benifit from it, as our DeploymentAspects was intended to process the SPI HttpEndpoint. It can not be reused to process JMSEndpoint too.
>
Let me disagree. This is the way you had to go IMHO ;)
We need these abstractions in our SPI:
* Endpoint
- ServletEndpoint -> url address
- JMSEndpoint -> jms address
* DA
- ServletDA
- JMSDA
Our ASIL deployers will accept DA abstraction
and will be able to distinguish between HTTP and JMS.
In deployer, before specifying inputs/outputs,
you should have code like this:
// pseudocode ensuring proper deployers ordering
if (DA instanceof ServletDA) {
this.addInput(WebMetaData.class);
...
} else if (DA instanceof JMSDA) {
this.addInput(JMSMetaData.class);
...
}
Both HTTP and JMS endpoints should use the same deployers flow.
Don't create another deployer flow just for JMS endpoints.
but reuse our current architeture.
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/541050#541050]
Start a new discussion in JBoss Web Services Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
15 years, 7 months