[JBoss JIRA] Commented: (EJBTHREE-641) entitymanager is null then using @WebService and @Stateless annotations in one class
by Jason T. Greene (JIRA)
[ http://jira.jboss.com/jira/browse/EJBTHREE-641?page=comments#action_12347015 ]
Jason T. Greene commented on EJBTHREE-641:
------------------------------------------
2006-06-29 17:24:02,815 ERROR [STDERR] at com.sun.xml.ws.api.server.InstanceResolver$1.invoke(InstanceResolver.java:127)
2006-06-29 17:24:02,815 ERROR [STDERR] at com.sun.xml.ws.server.sei.EndpointMethodHandler.invoke(EndpointMethodHandler.java:247)
2006-06-29 17:24:02,815 ERROR [STDERR] at com.sun.xml.ws.server.sei.SEIInvokerPipe.process(SEIInvokerPipe.java:97)
2006-06-29 17:24:02,815 ERROR [STDERR] at com.sun.xml.ws.protocol.soap.ServerMUPipe.process(ServerMUPipe.java:62)
2006-06-29 17:24:02,815 ERROR [STDERR] at com.sun.xml.ws.server.WSEndpointImpl$1.process(WSEndpointImpl.java:139)
2006-06-29 17:24:02,815 ERROR [STDERR] at com.sun.xml.ws.transport.http.HttpAdapter$HttpToolkit.handle(HttpAdapter.java:139)
2006-06-29 17:24:02,815 ERROR [STDERR] at com.sun.xml.ws.transport.http.HttpAdapter.handle(HttpAdapter.java:211)
2006-06-29 17:24:02,815 ERROR [STDERR] at com.sun.xml.ws.transport.http.servlet.ServletAdapter.handle(ServletAdapter.java:97)
2006-06-29 17:24:02,815 ERROR [STDERR] at com.sun.xml.ws.transport.http.servlet.WSServletDelegate.doPost(WSServletDelegate.java:161)
2006-06-29 17:24:02,815 ERROR [STDERR] at com.sun.xml.ws.transport.http.servlet.WSServlet.doPost(WSServlet.java:49)
You are using the Sun WS stack instead of ours, EJB3 integration requires container specific hooks, so the Sun stack will only integrate with EJB3 on the Sun EJB3 implementation, and our EJB3 implementation can only be used with the jbossws stack.
If you want to continue using the Sun stack, then you will need to use the servlet model instead of the EJB3 model, and then delgate to the EJB3.
Otherwise, if you want to use ours, you do not need to deploy a war, you simply annotate the bean and deploy. We however do not yet support the full JAX-WS spec, we only support JSR-181. So at the current jbossws release of 1.0.3SP1, you could not use the SOAP 1.2 binding. Full JAX-WS support is our top priority and will be included in jbossws 2.0, which will also be a part of jboss 5.
http://labs.jboss.com/portal/jbossws/user-guide/en/html/endpoints.html#js...
Also, 4.0.4 comes with jbossws 1.0.0, so I recommend upgrading it:
http://labs.jboss.com/portal/jbossws/downloads
-Jason
> entitymanager is null then using @WebService and @Stateless annotations in one class
> ------------------------------------------------------------------------------------
>
> Key: EJBTHREE-641
> URL: http://jira.jboss.com/jira/browse/EJBTHREE-641
> Project: EJB 3.0
> Issue Type: Bug
> Affects Versions: EJB 3.0 RC8 - FD
> Reporter: Ramil Israfilov
> Fix For: EJB 3.0 RC10 - FD
>
>
> I have a class with both @Stateless and @WebService annotation and injected entitymanager:
> @WebService(name = "WebServiceTest",
> targetNamespace = "http://accesspoint.jc/server" )
> @SOAPBinding(style = SOAPBinding.Style.DOCUMENT)
> @BindingType(value=javax.xml.ws.soap.SOAPBinding.SOAP12HTTP_MTOM_BINDING)
> @Remote(ServerInterface.class)
> public class Server implements ServerInterface {
> @PersistenceContext(unitName="CertiOneAccessPoint")
> EntityManager em;
> @WebMethod
> public SessionResponse createSession(SessionRequest sessionRequest) {
> log.debug("sessionRequest"+sessionRequest);
> SessionResponse resp = new SessionResponse();
> Session session = new Session();
> session=(Session) em.persist(session);
> resp.setSessionId(session.getId());
> return resp;
> }
> }
> I can successfully package and deploy EAR file.
> If I access EJB3 bean from remote application using JNDI lookup then everything works ok.
> But if I try to access webservice I got null pointer exception on line: session=(Session) em.persist(session);
> 2006-06-29 17:24:02,815 DEBUG [be.certipost.jc.accesspoint.server.impl.Server] sessionRequestbe.certipost.jc.accesspoint.server.SessionRequest@fbf04a
> 2006-06-29 17:24:02,815 ERROR [STDERR] java.lang.NullPointerException
> 2006-06-29 17:24:02,815 ERROR [STDERR] at be.certipost.jc.accesspoint.server.impl.Server.createSession(Server.java:51)
> 2006-06-29 17:24:02,815 ERROR [STDERR] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 2006-06-29 17:24:02,815 ERROR [STDERR] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> 2006-06-29 17:24:02,815 ERROR [STDERR] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 2006-06-29 17:24:02,815 ERROR [STDERR] at java.lang.reflect.Method.invoke(Method.java:585)
> 2006-06-29 17:24:02,815 ERROR [STDERR] at com.sun.xml.ws.api.server.InstanceResolver$1.invoke(InstanceResolver.java:127)
> 2006-06-29 17:24:02,815 ERROR [STDERR] at com.sun.xml.ws.server.sei.EndpointMethodHandler.invoke(EndpointMethodHandler.java:247)
> 2006-06-29 17:24:02,815 ERROR [STDERR] at com.sun.xml.ws.server.sei.SEIInvokerPipe.process(SEIInvokerPipe.java:97)
> 2006-06-29 17:24:02,815 ERROR [STDERR] at com.sun.xml.ws.protocol.soap.ServerMUPipe.process(ServerMUPipe.java:62)
> 2006-06-29 17:24:02,815 ERROR [STDERR] at com.sun.xml.ws.server.WSEndpointImpl$1.process(WSEndpointImpl.java:139)
> 2006-06-29 17:24:02,815 ERROR [STDERR] at com.sun.xml.ws.transport.http.HttpAdapter$HttpToolkit.handle(HttpAdapter.java:139)
> 2006-06-29 17:24:02,815 ERROR [STDERR] at com.sun.xml.ws.transport.http.HttpAdapter.handle(HttpAdapter.java:211)
> 2006-06-29 17:24:02,815 ERROR [STDERR] at com.sun.xml.ws.transport.http.servlet.ServletAdapter.handle(ServletAdapter.java:97)
> 2006-06-29 17:24:02,815 ERROR [STDERR] at com.sun.xml.ws.transport.http.servlet.WSServletDelegate.doPost(WSServletDelegate.java:161)
> 2006-06-29 17:24:02,815 ERROR [STDERR] at com.sun.xml.ws.transport.http.servlet.WSServlet.doPost(WSServlet.java:49)
> 2006-06-29 17:24:02,815 ERROR [STDERR] at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
> 2006-06-29 17:24:02,815 ERROR [STDERR] at javax.servlet.http.HttpServlet.service(HttpServlet.java:810)
> 2006-06-29 17:24:02,815 ERROR [STDERR] at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252)
> 2006-06-29 17:24:02,815 ERROR [STDERR] at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
> 2006-06-29 17:24:02,815 ERROR [STDERR] at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96)
> 2006-06-29 17:24:02,815 ERROR [STDERR] at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202)
> 2006-06-29 17:24:02,815 ERROR [STDERR] at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
> 2006-06-29 17:24:02,815 ERROR [STDERR] at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213)
> 2006-06-29 17:24:02,815 ERROR [STDERR] at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:178)
> 2006-06-29 17:24:02,815 ERROR [STDERR] at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:175)
> 2006-06-29 17:24:02,815 ERROR [STDERR] at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:74)
> 2006-06-29 17:24:02,815 ERROR [STDERR] at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126)
> 2006-06-29 17:24:02,815 ERROR [STDERR] at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105)
> 2006-06-29 17:24:02,815 ERROR [STDERR] at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107)
> 2006-06-29 17:24:02,815 ERROR [STDERR] at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148)
> 2006-06-29 17:24:02,815 ERROR [STDERR] at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:869)
> 2006-06-29 17:24:02,815 ERROR [STDERR] at org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection(Http11BaseProtocol.java:664)
> 2006-06-29 17:24:02,815 ERROR [STDERR] at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:527)
> 2006-06-29 17:24:02,815 ERROR [STDERR] at org.apache.tomcat.util.net.MasterSlaveWorkerThread.run(MasterSlaveWorkerThread.java:112)
> 2006-06-29 17:24:02,831 ERROR [STDERR] at java.lang.Thread.run(Thread.java:595)
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
19 years, 8 months
[JBoss JIRA] Commented: (JGRP-180) Harden stack to prevent loss of intra-stack events
by Bela Ban (JIRA)
[ http://jira.jboss.com/jira/browse/JGRP-180?page=comments#action_12347007 ]
Bela Ban commented on JGRP-180:
-------------------------------
Maybe we should merge down() and passDown() into one call: down(). To pass down an event, simply call down_prot.down().
> Harden stack to prevent loss of intra-stack events
> --------------------------------------------------
>
> Key: JGRP-180
> URL: http://jira.jboss.com/jira/browse/JGRP-180
> Project: JGroups
> Issue Type: Task
> Affects Versions: 2.2.8, 2.2.9, 2.2.9.1
> Reporter: Bela Ban
> Assigned To: Bela Ban
> Fix For: 2.5
>
>
> When an *intra-stack* event is lost, this can be serious (*inter-stack* message are simply retransmitted, so that is not critical).
> Losses are mainly caused by runtime exceptions, e.g. OutOfMemory exception (OOM), or resource problems, and to a lesser extent by program bugs.
> For example, when a user sends a message using Channel.send(), and there is an exception, then the user will simply send the message again, possibly after fixing the cause of the exception.
> However, for events such as VIEW_CHANGE that are multicast by the GMS protocol, a loss can be serious: in this case, the view would never be received !
> The same applies to the up direction: when NAKACK has successfully delivered a message, if that message is lost travelling between NAKACK and the Channel, then is serious (essentially loss of that message).
> So while these error situations don't occur very often, if they do occur, they have serious consequences.
> SOLUTION:
> - Do nothing for user messages: Channel.send() throws an exception, user has to resend message. Note that in http://jira.jboss.com/jira/browse/JGRP-179, we made retransmission handling atomic, e.g. if there is an exception, there will *not* be a gap in the seqnos for NAKACK and UNICAST
> - Provide either a pass{Up/Down}Reliably() method or an Event with a RELIABLE field, such that this event needs to be acked. The sender (e.g. GMS on a VIEW_CHANGE) sends down the message and waits until it gets an ACK, which could be sent by the NAKACK or UNICAST protocols, or as last resort by the transport (TP). If the ACK is not received within M ms, the event is resent.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
19 years, 8 months
[JBoss JIRA] Updated: (JBAS-3143) JACC isUserInRole and isCallerInRole Testcase retrofit
by Dimitris Andreadis (JIRA)
[ http://jira.jboss.com/jira/browse/JBAS-3143?page=all ]
Dimitris Andreadis updated JBAS-3143:
-------------------------------------
Fix Version/s: JBossAS-5.0.0.Beta2
(was: JBossAS-5.0.0.Beta1)
> JACC isUserInRole and isCallerInRole Testcase retrofit
> ------------------------------------------------------
>
> Key: JBAS-3143
> URL: http://jira.jboss.com/jira/browse/JBAS-3143
> Project: JBoss Application Server
> Issue Type: Task
> Security Level: Public(Everyone can see)
> Components: Security
> Affects Versions: JBossAS-4.0.4.CR2
> Reporter: Anil Saldhana
> Assigned To: Anil Saldhana
> Fix For: JBossAS-4.2.0.CR1, JBossAS-5.0.0.Beta2
>
>
> As described in the forum thread, when jacc is enabled, the behavior that is seen for programmatic security checks made for the Web and the EJB layer is dependent on whether the DD (web.xml and ejb-jar.xml) define the roles (as part of security-role and/or security-role-ref elements) completely or partially.
> The testcases (mainly the UserInRoleUnitTestCase and the CallerInRoleUnitTestCase) should be retrofitted to handle both the cases - one when the DD is partially descibed and the other when it is fully described.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
19 years, 8 months
[JBoss JIRA] Updated: (JBAS-2623) JASPISecurityManagerService based on JSR196
by Dimitris Andreadis (JIRA)
[ http://jira.jboss.com/jira/browse/JBAS-2623?page=all ]
Dimitris Andreadis updated JBAS-2623:
-------------------------------------
Fix Version/s: JBossAS-5.0.0.Beta2
(was: JBossAS-5.0.0.Beta1)
> JASPISecurityManagerService based on JSR196
> -------------------------------------------
>
> Key: JBAS-2623
> URL: http://jira.jboss.com/jira/browse/JBAS-2623
> Project: JBoss Application Server
> Issue Type: Task
> Security Level: Public(Everyone can see)
> Reporter: Anil Saldhana
> Assigned To: Anil Saldhana
> Fix For: JBossAS-5.0.0.Beta2
>
>
> Implement the following:
> a) JASPISecurityManager is a standalone implementation class that implements the interface called "GeneralizedAuthenticationManager" (which is ServerAuthContext and AuthenticationManager interfaces). The way an implementation gets access to this through the AuthContextFactory mechanism. This is MC friendly.
> b) Since the JASPISecurityManager is a POJO friendly implementation, we are going to bring in a JMX wrapper called "JASPISecurityManagerService" (Actually can really use JaasSecurityManagerService, but lets retire him). Now since the wrapper binds the JASPISecurityManager to JNDI, there is no reason to go the AuthContextFactory way, for any service that needs authentication. Just look up the JNDI to get the securitymanager. This is what the JBossSecurityMgrRealm and the security interceptors will do.
> The above two take care of the generalized authentication mechanism.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
19 years, 8 months
[JBoss JIRA] Created: (JBCACHE-702) PojoCache to specify a user-defined region option for buddy replication and eviction policy
by Ben Wang (JIRA)
PojoCache to specify a user-defined region option for buddy replication and eviction policy
-------------------------------------------------------------------------------------------
Key: JBCACHE-702
URL: http://jira.jboss.com/jira/browse/JBCACHE-702
Project: JBoss Cache
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Components: PojoCache
Reporter: Ben Wang
Assigned To: Ben Wang
Fix For: POJOCache
Currently, the design of flat space mapping in 2.0 means that the object graph doesn't reside under the same tree. When we have buddy replication, eviction or cacheloader, this can be a problem to implement. The best solution is to have an notion of region. For example, something toward this line:
cache.attach(region, id, pojo)
will ensure everything is put under /region/id, and __JBOSS_INTERNAL__/region/guid
I am thinking to put this in an Option class such as:
cache.attach(id, pojo, option)
so it is more generic.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
19 years, 8 months