[JBoss Seam] - Re: Feature request regarding nested conversations
by jacob.orshalick
wschwendt,
Thanks for the information. Yes, I understand how the Seam managed persistence context works, in theory. I suppose my question relates more to how the Seam managed persistence context maintains managed entities with respect to nested conversations...
So if I have an entity in my outer conversation, say Person as before. I loaded my Person instance in the outer conversation with a Seam managed persistence context which means my Person instance remains managed for the course of the conversation. Now I navigate to the Address details page which nests a conversation,
1. Does the snapshot of the Conversation context include a snapshot of the *managed entity*?
2. If I make changes to the Person in the nested conversation, since this is a *managed entity* does it make any difference in the semantics of the outer vs. nested conversation?
3. Will I still be able to revert back to the outer conversation snapshot of my Person object as I can with a detached entity?
I will have to create an example that tests this behavior with attached entities as I know it works with detached entities. If anyone could provide any insight, that would be great. Thanks again.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4085745#4085745
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4085745
18 years, 10 months
[JBossWS] - Re: Custom exception/fault with JBoss & JWSDP
by bernhard_pauler
I tried it - and it worked with the wstools.
BUT ...
Besides the custom exception I have to work with attachments. With the definition of attachments in place I really had a hard time with the wstools. I tried really hard - but I had to step back to the wscompile tool of the JWSDP which just worked without fiddling.
I wanted to solve the custom exception issue though so I investigated once more and compared the generated artifacts/descriptors of the two tools.
And I finally found the difference - it was in the jaxrpc-mapping.xml:
JWSDP - wscompile<root-type-qname xmlns:typeNS="http://myservice.mycompany.com/myservice">typeNS:MyServiceFault</root-type-qname>
JBoss - wstools<anonymous-type-qname xmlns:typeNS="http://myservice.mycompany.com/myservice">typeNS:>MyServiceFault</anonymous-type-qname>
I don't know who to blame. The generated "root-type-qname" tag of the wscompile tool looks fishy if you compare it to the other tags in the same mapping file - and in fact JBoss can't seem to deal with it.
Replace that line with the line the wstools generate and the warnings are gone and the custom exception mechanism is working. :)
That's the solution to my problem now. Not a beautiful solution - but it works and I can't invest more time at the moment. Hope this helps somebody ...
Bernhard
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4085744#4085744
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4085744
18 years, 10 months
[JBoss Seam] - Seam-managed persistence context
by wschwendt
"matt.drees" wrote :
| I think nested conversations need to be discussed more.
I have the same opinion.
"jacob.orshalick" wrote : Maybe an expert on the effects of nested conversations on a Seam managed persistence context could shed some light on this?
I'm anything but an expert regarding the effects of nested conversations on a Seam-managed persistence context. So far my understanding (could be wrong) is that a Seam-managed persistence context corresponds to
an instance of the org.jboss.seam.persistence.ManagedPersistenceContext component. This is a conversation-scoped component, hence it can be injected into other components using the @In annotation. Unlike "normal" conversation-scoped components, ManagedPersistenceContext is annotated with @BypassInterceptors and @Install(false) however. To define a managed persistence context with the name "entityManager", the typical idiom is that the framework user puts a component definition in config-file components.xml
| // components.xml
|
| <persistence:managed-persistence-context
| name="entityManager"
| persistence-unit-jndi-name="java:/contactlistEntityManagerFactory"/>
|
How does a Seam-managed persistence context get instantiated? It gets instantiated like any ordinary Seam component. For example, the Seam CRUD framework classes EntityHome and EntityQuery both extend
org.jboss.seam.framework.PersistenceController which creates a Seam-managed persistence context effectively via a call of Component.getInstance(name);
Now what happens if a nested conversation is in progress and there is an injection such as the following or another call of Component.getInstance("entityManager")?
| @In EntityManager entityManager; //a Seam-managed persistence context
|
I'd say the usual rules for injections apply, that means Seam tries a hierarchical context search. A nested conversation has read-only access to the context of the outer conversation. Therefore, if a Seam-managed persistence context was instantiated already in the parent conversation, the hierarchical search finds it and the nested conversation thus shares the same persistence context with the parent conversation.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4085740#4085740
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4085740
18 years, 10 months
[JBossWS] - Problem with methods returning an attachment
by bernhard_pauler
I have a nasty problem.
Some methods of my web service should return an attachment.
I start with a handwritten WSDL file and generate the necessary artifacts and descriptors using JAX-RPC tools.
There are no warning or error messages at deploy time.
An error occurs after invoking the method:
16:27:34,485 ERROR [SOAPFaultHelperJAXRPC] SOAP request exception
org.jboss.ws.WSException: Operation does not have a return value: {http://myservice.mycompany.com/myservice}getTemplate
I can't figure out why JBoss behaves that way - can somebody help me with this?
Thanks,
Bernhard
Here are of the relevant files:
MyService.wsdl:<?xml version="1.0" encoding="utf-8"?>
|
| <definitions name="MyService"
| xmlns ="http://schemas.xmlsoap.org/wsdl/"
| xmlns:soap ="http://schemas.xmlsoap.org/wsdl/soap/"
| xmlns:mime ="http://schemas.xmlsoap.org/wsdl/mime/"
| xmlns:xsd ="http://www.w3.org/2001/XMLSchema"
| xmlns:tns ="http://myservice.mycompany.com/myservice"
| targetNamespace="http://myservice.mycompany.com/myservice">
|
| <types>
| <schema xmlns="http://www.w3.org/2001/XMLSchema" targetNamespace="http://myservice.mycompany.com/myservice">
| <element name="getTemplate">
| <complexType>
| <sequence>
| <element name="templateId" type="xsd:int"/>
| </sequence>
| </complexType>
| </element>
| <element name="MyServiceFault">
| <complexType>
| <sequence>
| <element name="errorCode" type="xsd:string"/>
| <element name="errorMessage" type="xsd:string"/>
| </sequence>
| </complexType>
| </element>
| </schema>
| </types>
|
| <message name="getTemplateRequest">
| <part name="parameters" element="tns:getTemplate"/>
| </message>
| <message name="getTemplateResponse">
| <part name="template" type="xsd:hexBinary"/>
| </message>
| <message name="MyServiceFaultMessage">
| <part name="fault" element="tns:MyServiceFault"/>
| </message>
|
| <portType name="MyServiceEndpoint">
| <operation name="getTemplate">
| <input message="tns:getTemplateRequest"/>
| <output message="tns:getTemplateResponse"/>
| <fault name="MyServiceFault" message="tns:MyServiceFaultMessage"/>
| </operation>
| </portType>
|
| <binding name="MyServiceEndpointBinding" type="tns:MyServiceEndpoint">
| <soap:binding style="document" transport="http://schemas.xmlsoap.org/soap/http"/>
| <operation name="getTemplate">
| <input>
| <soap:body use="literal"/>
| </input>
| <output>
| <mime:multipartRelated>
| <mime:part>
| <soap:body use="literal"/>
| </mime:part>
| <mime:part>
| <mime:content part="template" type="application/*"/>
| </mime:part>
| </mime:multipartRelated>
| </output>
| <fault name="MyServiceFault">
| <soap:fault name="MyServiceFault" use="literal"/>
| </fault>
| </operation>
| </binding>
|
| <service name="MyService">
| <port name="MyServiceEndpointPort" binding="tns:MyServiceEndpointBinding">
| <soap:address location="REPLACE_WITH_ACTUAL_URL"/>
| </port>
| </service>
|
| </definitions>
jaxrpc-mapping.xml:<?xml version="1.0" encoding="UTF-8"?>
| <java-wsdl-mapping xmlns="http://java.sun.com/xml/ns/j2ee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" version="1.1" xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee http://www.ibm.com/webservices/xsd/j2ee_jaxrpc_mapping_1_1.xsd">
| <package-mapping>
| <package-type>com.mycompany.myservice</package-type>
| <namespaceURI>http://myservice.mycompany.com/myservice</namespaceURI>
| </package-mapping>
| <java-xml-type-mapping>
| <java-type>com.mycompany.myservice.MyServiceFault</java-type>
| <anonymous-type-qname xmlns:typeNS="http://myservice.mycompany.com/myservice">typeNS:>MyServiceFault</anonymous-type-qname>
| <qname-scope>complexType</qname-scope>
| <variable-mapping>
| <java-variable-name>errorCode</java-variable-name>
| <xml-element-name>errorCode</xml-element-name>
| </variable-mapping>
| <variable-mapping>
| <java-variable-name>errorMessage</java-variable-name>
| <xml-element-name>errorMessage</xml-element-name>
| </variable-mapping>
| </java-xml-type-mapping>
| <java-xml-type-mapping>
| <java-type>com.mycompany.myservice.GetTemplate</java-type>
| <anonymous-type-qname>http://myservice.mycompany.com/myservice:>getTemplate</anonymous-type-qname>
| <qname-scope>complexType</qname-scope>
| <variable-mapping>
| <java-variable-name>templateId</java-variable-name>
| <xml-element-name>templateId</xml-element-name>
| </variable-mapping>
| </java-xml-type-mapping>
| <exception-mapping>
| <exception-type>com.mycompany.myservice.MyServiceFault</exception-type>
| <wsdl-message xmlns:exMsgNS="http://myservice.mycompany.com/myservice">exMsgNS:MyServiceFaultMessage</wsdl-message>
| <constructor-parameter-order>
| <element-name>errorCode</element-name>
| <element-name>errorMessage</element-name>
| </constructor-parameter-order>
| </exception-mapping>
| <service-interface-mapping>
| <service-interface>com.mycompany.myservice.MyService</service-interface>
| <wsdl-service-name xmlns:serviceNS="http://myservice.mycompany.com/myservice">serviceNS:MyService</wsdl-service-name>
| <port-mapping>
| <port-name>MyServiceEndpointPort</port-name>
| <java-port-name>MyServiceEndpointPort</java-port-name>
| </port-mapping>
| </service-interface-mapping>
| <service-endpoint-interface-mapping>
| <service-endpoint-interface>com.mycompany.myservice.MyServiceEndpoint</service-endpoint-interface>
| <wsdl-port-type xmlns:portTypeNS="http://myservice.mycompany.com/myservice">portTypeNS:MyServiceEndpoint</wsdl-port-type>
| <wsdl-binding xmlns:bindingNS="http://myservice.mycompany.com/myservice">bindingNS:MyServiceEndpointBinding</wsdl-binding>
| <service-endpoint-method-mapping>
| <java-method-name>getTemplate</java-method-name>
| <wsdl-operation>getTemplate</wsdl-operation>
| <wrapped-element/>
| <method-param-parts-mapping>
| <param-position>0</param-position>
| <param-type>int</param-type>
| <wsdl-message-mapping>
| <wsdl-message xmlns:wsdlMsgNS="http://myservice.mycompany.com/myservice">wsdlMsgNS:getTemplateRequest</wsdl-message>
| <wsdl-message-part-name>templateId</wsdl-message-part-name>
| <parameter-mode>IN</parameter-mode>
| </wsdl-message-mapping>
| </method-param-parts-mapping>
| <wsdl-return-value-mapping>
| <method-return-value>javax.activation.DataHandler</method-return-value>
| <wsdl-message xmlns:wsdlMsgNS="http://myservice.mycompany.com/myservice">wsdlMsgNS:getTemplateResponse</wsdl-message>
| <wsdl-message-part-name>template</wsdl-message-part-name>
| </wsdl-return-value-mapping>
| </service-endpoint-method-mapping>
| </service-endpoint-interface-mapping>
| </java-wsdl-mapping>
MyServiceEndpoint.java:package com.mycompany.myservice;
|
| public interface MyServiceEndpoint extends java.rmi.Remote {
| public javax.activation.DataHandler getTemplate(int templateId) throws
| com.mycompany.myservice.MyServiceFault, java.rmi.RemoteException;
| }
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4085734#4085734
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4085734
18 years, 10 months
Issue with JAAS
by Claudemir Ferreira Franco
Hi guys,
I have many applications with use JAAS. When the client invoke Action
"login", I get the following error:
2007-09-13 09:19:05,510 DEBUG
[AgendaCorporativa.model.br.com.xxx.fwp.control.LoginAction] execute() -
action: LOGIN
2007-09-13 09:19:05,520 DEBUG
[AgendaCorporativa.model.br.com.xxxx.fwp.control.LoginAction] execute()
- voTela: {action=LOGIN, j_username=,
excluirMultiplos=[Ljava.lang.String;@1614ee3, page=1, j_password=}
2007-09-13 09:19:05,535 ERROR
[AgendaCorporativa.model.br.com.xxxx.fwp.control.LoginAction]
jboss.security:service=JaasSecurityManager
javax.management.InstanceNotFoundException:
jboss.security:service=JaasSecurityManager
at
com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.getMBean(DefaultMB
eanServerInterceptor.java:1010)
at
com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBea
nServerInterceptor.java:804)
at
com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(JmxMBeanServer.java:784)
at
br.com.unimed.fwp.control.LoginAction.doActionLogIn(LoginAction.java:198
)
above the partial code the my application and login-config.xml
String domain = "jmx-console";
Principal user = new FwpPrincipal(login, null);
ObjectName jaasMgr = new ObjectName(
"jboss.security:service=JaasSecurityManager");
Object[] params = { domain, user };
String[] signature = { "java.lang.String",
Principal.class.getName() };
MBeanServer server = (MBeanServer)
MBeanServerFactory.findMBeanServer(
null).get(0);
server.invoke(jaasMgr,
"flushAuthenticationCache", params, signature);
JaasSecurityManager jaas = (JaasSecurityManager)
ServiceLocator
.getInstance().getService("java:/jaas/fwp-security");
jaas.flushCache();
login-config.xml:
<?xml version='1.0'?>
<!DOCTYPE policy PUBLIC
"-//JBoss//DTD JBOSS Security Config 3.0//EN"
"http://www.jboss.org/j2ee/dtd/security_config.dtd">
<!-- The XML based JAAS login configuration read by the
org.jboss.security.auth.login.XMLLoginConfig mbean. Add
an application-policy element for each security domain.
The outline of the application-policy is:
<application-policy name="security-domain-name">
<authentication>
<login-module code="login.module1.class.name" flag="control_flag">
<module-option name = "option1-name">option1-value</module-option>
<module-option name = "option2-name">option2-value</module-option>
...
</login-module>
<login-module code="login.module2.class.name" flag="control_flag">
...
</login-module>
...
</authentication>
</application-policy>
$Revision: 1.12.2.2 $
-->
<policy>
<!-- Used by clients within the application server VM such as
mbeans and servlets that access EJBs.
-->
<application-policy name = "client-login">
<authentication>
<login-module code = "org.jboss.security.ClientLoginModule"
flag = "required">
</login-module>
</authentication>
</application-policy>
<application-policy name="fwp-security">
<authentication>
<login-module
code="org.jboss.security.ClientLoginModule" flag="required"
>
</login-module>
<login-module
code="br.com.unimed.fwp.security.loginmodule.FwpLoginModule
" flag="required">
</login-module>
</authentication>
</application-policy>
<!-- Security domain for JBossMQ -->
<application-policy name = "jbossmq">
<authentication>
<login-module code =
"org.jboss.security.auth.spi.DatabaseServerLoginModule"
flag = "required">
<module-option name =
"unauthenticatedIdentity">guest</module-option>
<module-option name =
"dsJndiName">java:/mysql-jbossdb</module-option>
<module-option name = "principalsQuery">SELECT PASSWD FROM
JMS_USERS WHERE USERID=?<
/module-option>
<module-option name = "rolesQuery">SELECT ROLEID, 'Roles'
FROM JMS_ROLES WHERE USERI
D=?</module-option>
</login-module>
</authentication>
</application-policy>
<!-- Security domain for JBossMQ when using file-state-service.xml
<application-policy name = "jbossmq">
<authentication>
<login-module code = "org.jboss.mq.sm.file.DynamicLoginModule"
flag = "required">
<module-option name =
"unauthenticatedIdentity">guest</module-option>
<module-option name =
"sm.objectname">jboss.mq:service=StateManager</module-option>
</login-module>
</authentication>
</application-policy>
-->
<!-- Security domains for testing new jca framework -->
<application-policy name = "HsqlDbRealm">
<authentication>
<login-module code =
"org.jboss.resource.security.ConfiguredIdentityLoginModule"
flag = "required">
<module-option name = "principal">sa</module-option>
<module-option name = "userName">sa</module-option>
<module-option name = "password"></module-option>
<module-option name =
"managedConnectionFactoryName">jboss.jca:service=LocalTxCM,nam
e=DefaultDS</module-option>
</login-module>
</authentication>
</application-policy>
<application-policy name = "JmsXARealm">
<authentication>
<login-module code =
"org.jboss.resource.security.ConfiguredIdentityLoginModule"
flag = "required">
<module-option name = "principal">guest</module-option>
<module-option name = "userName">guest</module-option>
<module-option name = "password">guest</module-option>
<module-option name =
"managedConnectionFactoryName">jboss.jca:service=TxCM,name=Jms
XA</module-option>
</login-module>
</authentication>
</application-policy>
<!-- A template configuration for the jmx-console web application.
This
defaults to the UsersRolesLoginModule the same as other and should
be
changed to a stronger authentication mechanism as required.
-->
<application-policy name = "jmx-console">
<authentication>
<login-module
code="org.jboss.security.auth.spi.UsersRolesLoginModule"
flag = "required">
<module-option
name="usersProperties">props/jmx-console-users.properties</module-optio
n>
<module-option
name="rolesProperties">props/jmx-console-roles.properties</module-optio
n>
</login-module>
</authentication>
</application-policy>
<!-- A template configuration for the web-console web application.
This
defaults to the UsersRolesLoginModule the same as other and should
be
changed to a stronger authentication mechanism as required.
-->
<application-policy name = "web-console">
<authentication>
<login-module
code="org.jboss.security.auth.spi.UsersRolesLoginModule"
flag = "required">
<module-option
name="usersProperties">web-console-users.properties</module-option>
<module-option
name="rolesProperties">web-console-roles.properties</module-option>
</login-module>
</authentication>
</application-policy>
<!-- A template configuration for the JBossWS web application (and
transport layer!).
This defaults to the UsersRolesLoginModule the same as other and should
be
changed to a stronger authentication mechanism as required.
-->
<application-policy name="JBossWS">
<authentication>
<login-module
code="org.jboss.security.auth.spi.UsersRolesLoginModule"
flag="required">
<module-option
name="unauthenticatedIdentity">anonymous</module-option>
</login-module>
</authentication>
</application-policy>
<!-- The default login configuration used by any security domain
that
does not have a application-policy entry with a matching name
-->
<application-policy name = "other">
<!-- A simple server login module, which can be used when the
number
of users is relatively small. It uses two properties files:
users.properties, which holds users (key) and their password
(value).
roles.properties, which holds users (key) and a comma-separated
list of
their roles (value).
The unauthenticatedIdentity property defines the name of the
principal
that will be used when a null username and password are presented
as is
the case for an unuathenticated web client or MDB. If you want to
allow such users to be authenticated add the property, e.g.,
unauthenticatedIdentity="nobody"
-->
<authentication>
<login-module code =
"org.jboss.security.auth.spi.UsersRolesLoginModule"
flag = "required" />
</authentication>
</application-policy>
<!-- Modulo de autenticacao especifico do chat -->
The unauthenticatedIdentity property defines the name of the
principal
that will be used when a null username and password are presented
as is
the case for an unuathenticated web client or MDB. If you want to
allow such users to be authenticated add the property, e.g.,
unauthenticatedIdentity="nobody"
-->
<authentication>
<login-module code =
"org.jboss.security.auth.spi.UsersRolesLoginModule"
flag = "required" />
</authentication>
</application-policy>
<!-- Modulo de autenticacao especifico do chat -->
<application-policy name="fwp_chat-security">
<authentication>
<login-module code="org.jboss.security.ClientLoginModule"
flag="required">
</login-module>
<login-module
code="br.com.unimed.chatcorporativo.security.loginmodule.ChatLoginMod
ule" flag="required">
</login-module>
</authentication>
</application-policy>
<!-- Configuracao do Lambda Probe -->
<application-policy name = "probe">
<authentication>
<login-module
code="org.jboss.security.auth.spi.UsersRolesLoginModule" flag =
"required">
<module-option
name="usersProperties">props/probe-users.properties</module-option>
<module-option
name="rolesProperties">props/probe-roles.properties</module-option>
</login-module>
</authentication>
</application-policy>
</policy>
Any idea on the issue?
Tks
- - - - - - -
Claudemir Ferreira Franco
Analista Suporte Unix
BrasilTelecom Site III - CyberDatacenter
18 years, 10 months