[JBoss JIRA] Created: (AS7-944) EJB lifecycle interceptors that are not included in the deployment are not applied
by Marius Bogoevici (JIRA)
EJB lifecycle interceptors that are not included in the deployment are not applied
----------------------------------------------------------------------------------
Key: AS7-944
URL: https://issues.jboss.org/browse/AS7-944
Project: Application Server 7
Issue Type: Bug
Components: EJB
Affects Versions: 7.0.0.Beta3
Reporter: Marius Bogoevici
Suppose that we have a class
{code}
@Startup @Singleton @Interceptors(A.class, B.class)
public class MyEJB {
}
{code}
Where A.class is included with the deployment and B.class is included in a module that is visible to the deployment.
B will be identified correctly as an interceptor for MyEJB, but LifecycleAnnotationParsingProcessor will not process it (as it apparently handles only components found within the deployment). Therefore, B will be ignored when creating the interceptor set for MyEJB, since ComponentInstallProcessor will treat it as a class that has no lifecycle methods.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 9 months
[JBoss JIRA] (AS7-5351) Need to activate some sun/security packages
by Dark Blue (JIRA)
Dark Blue created AS7-5351:
------------------------------
Summary: Need to activate some sun/security packages
Key: AS7-5351
URL: https://issues.jboss.org/browse/AS7-5351
Project: Application Server 7
Issue Type: Feature Request
Environment: JBoss A.S. 7.1.1 Final
Reporter: Dark Blue
We need some packages to activate about sun/security packages. Otherwise we get java.lang.NoClassDefFoundError. We need "sun/security/pkcs" and "sun/security/x509" modules to activate.
Is it possible to add some required packages to JBoss 7 A.S. as default like the following.
jboss-as-web-7.1.1.Final\modules\sun\jdk\main\modules.xml
....
<path name="sun/security/pkcs"/>
<path name="sun/security/x509"/>
....
Here is the exception cause:
javax.servlet.ServletException: java.lang.NoClassDefFoundError: sun/security/pkcs/PKCS7
javax.faces.webapp.FacesServlet.service(FacesServlet.java:606)
org.primefaces.webapp.filter.FileUploadFilter.doFilter(FileUploadFilter.java:79)
org.jboss.weld.servlet.ConversationPropagationFilter.doFilter(ConversationPropagationFilter.java:67)
com.ocpsoft.pretty.PrettyFilter.doFilter(PrettyFilter.java:115)
org.jboss.solder.servlet.exception.CatchExceptionFilter.doFilter(CatchExceptionFilter.java:65)
org.jboss.solder.servlet.event.ServletEventBridgeFilter.doFilter(ServletEventBridgeFilter.java:74)
tr.gov.tubitak.bte.ebelgem.util.CustomCharacterEncodingFilter.doFilter(CustomCharacterEncodingFilter.java:38)
javax.servlet.ServletException: java.lang.NoClassDefFoundError: sun/security/x509/AlgorithmId
javax.faces.webapp.FacesServlet.service(FacesServlet.java:606)
org.primefaces.webapp.filter.FileUploadFilter.doFilter(FileUploadFilter.java:79)
org.jboss.weld.servlet.ConversationPropagationFilter.doFilter(ConversationPropagationFilter.java:67)
com.ocpsoft.pretty.PrettyFilter.doFilter(PrettyFilter.java:115)
org.jboss.solder.servlet.exception.CatchExceptionFilter.doFilter(CatchExceptionFilter.java:65)
org.jboss.solder.servlet.event.ServletEventBridgeFilter.doFilter(ServletEventBridgeFilter.java:74)
tr.gov.tubitak.bte.ebelgem.util.CustomCharacterEncodingFilter.doFilter(CustomCharacterEncodingFilter.java:38)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 9 months
[JBoss JIRA] Created: (JGRP-1340) GossipRouter: view shows mix of logical address and UUID for nodes
by Bela Ban (JIRA)
GossipRouter: view shows mix of logical address and UUID for nodes
------------------------------------------------------------------
Key: JGRP-1340
URL: https://issues.jboss.org/browse/JGRP-1340
Project: JGroups
Issue Type: Bug
Reporter: Bela Ban
Assignee: Bela Ban
Fix For: 2.12.2, 3.0
[Vivek Sar]
On Sat, Jun 18, 2011 at 4:56 AM, Bela Ban <belaban(a)yahoo.com> wrote:
> > #1 When does this happen (after a restart of a node, or on starting a new
> > node) ?
[vivek]: this usually happens after a node has gone out of a group
(due to some intermittent network outage or communication issues) and
comes back to merge into the group. We have also seen this if we
restart the node without much time between stop and start (this was
the example above). So, it's kind of random - it happens both for
merge views and a new views.
> > #2 Do the UUIDs disappear after some time, and the logical names are shown ?
[vivek]: No, in my experience the UUID remain if it's the same view,
but if the view changes (if any node goes in and out of a group) then
the logical name come back, otherwise the UUID remains.
> > #3 Does this cause any issues, other than a not-so-nice view with mixed
> > logical and UUID addresses ?
[vivek]: It's both - in some cases we have seen this causes node
isolation - where we are not able to get the merges (see related
https://issues.jboss.org/browse/JGRP-1326) - even after a node come
back it's not able to merge back. In some cases, the communication is
ok and it's just not-so-nice view.
> > #4 What's you config ?
We are using Tunnel with PING with two GRs (this is with JGroups 2.12.1),
(see attached config)
Thanks,
-vivek
> >
> > On 6/17/11 10:27 PM, vivek sar wrote:
>> >>
>> >> Hi,
>> >>
>> >> We are currently using JGroups 2.12.1 with Tunnel protocol (using
>> >> PING for discovery). Once in a while we see node represented using
>> >> UUID rather than their logical address. I think this issue is not
>> >> specific to this version of JGroups as we have seen similar problem
>> >> with 2.10 as well. The problem for us is not the view logging, but
>> >> different view information on different nodes - some get the logical
>> >> name and others just the UUID for the same view id. In past this kind
>> >> of view (showing UUIDs instead of logical address) also indicated
>> >> nodes and GRs out-of-sync on the node list, which in turn was causing
>> >> merge issues.
>> >>
>> >> Questions,
>> >>
>> >> 1) When does this happen - getting both logical address and UUID in
>> >> the same view?
>> >> 2) Why different nodes with same view id get different node
>> >> information (some get UUID, while others get the right logical
>> >> address)?
>> >> 3) How to fix it?
>> >>
>> >> For ex.,
>> >>
>> >> On Coordinator (collector_192.168.50.23):
>> >>
>> >> 2011-06-17 17:25:56,233 INFO
>> >> [Incoming-4,192.168.50.22_group,collector_192.168.50.23:4576]
>> >> RpcServiceManager - viewAccepted()-> New View:
>> >> [collector_192.168.50.23:4576|51] [collector_192.168.50.23:4576,
>> >> probe_192.168.50.32:4576, probe_192.168.50.24:4576,
>> >> manager_192.168.50.22:4576, probe_192.168.50.56:4576]
>> >>
>> >> Node 1 (manager_192.168.50.22):
>> >>
>> >> 2011-06-17 17:25:56,429 INFO
>> >> [Incoming-5,192.168.50.22_group,manager_192.168.50.22:4576]
>> >> RpcServiceManager - viewAccepted()-> New View:
>> >> [collector_192.168.50.23:4576|51] [collector_192.168.50.23:4576,
>> >> 110fcd0e-6f80-7cf0-d76b-0813b913daf1,
>> >> dd068d2f-ef21-1b66-1430-e8bfc862e6f9, manager_192.168.50.22:4576,
>> >> probe_192.168.50.56:4576]
>> >>
>> >> Node 2 (probe_192.168.50.56):
>> >>
>> >> 2011-06-17 12:02:01,695 INFO
>> >> [Incoming-10,192.168.50.22_group,probe_192.168.50.56:4576]
>> >> RpcServiceManager - viewAccepted()-> New View:
>> >> [collector_192.168.50.23:4576|51] [collector_192.168.50.23:4576,
>> >> probe_192.168.50.32:4576, probe_192.168.50.24:4576,
>> >> manager_192.168.50.22:4576, probe_192.168.50.56:4576]
>> >>
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 10 months
[JBoss JIRA] (AS7-5426) Runtime attributes of txn-recovery-environment socket-binding are always undefined
by Ivo Studensky (JIRA)
Ivo Studensky created AS7-5426:
----------------------------------
Summary: Runtime attributes of txn-recovery-environment socket-binding are always undefined
Key: AS7-5426
URL: https://issues.jboss.org/browse/AS7-5426
Project: Application Server 7
Issue Type: Bug
Components: Domain Management, Transactions
Affects Versions: 7.1.3.Final (EAP), 7.2.0.Alpha1
Reporter: Ivo Studensky
Assignee: Brian Stansberry
The runtime attributes 'bound', 'bound-address' and 'bound-port' of socket-binding.txn-recovery-environment are undefined even if the recovery listener is on.
Steps to reproduce:
1. enable the recovery listener of transactions, i.e.
/subsystem=transactions:write-attribute(name=recovery-listener,value=true)
2. reload the server
3. check the runtime attributes of txn-recovery-environment
/socket-binding-group=standard-sockets/socket-binding=txn-recovery-environment:read-resource(include-runtime=true)
{noformat}
[standalone@localhost:10099 /] /socket-binding-group=standard-sockets/socket-binding=txn-recovery-environment:read-resource(include-runtime=true)
{
"outcome" => "success",
"result" => {
"bound" => false,
"bound-address" => undefined,
"bound-port" => undefined,
"client-mappings" => undefined,
"fixed-port" => false,
"interface" => undefined,
"multicast-address" => undefined,
"multicast-port" => undefined,
"name" => "txn-recovery-environment",
"port" => 4712
}
}
[standalone@localhost:10099 /] /subsystem=transactions:read-resource
{
"outcome" => "success",
"result" => {
"default-timeout" => 300,
"enable-statistics" => false,
"enable-tsm-status" => false,
"jts" => false,
"node-identifier" => "1",
"object-store-path" => "tx-object-store",
"object-store-relative-to" => "jboss.server.data.dir",
"path" => "var",
"process-id-socket-max-ports" => 10,
"process-id-uuid" => true,
"recovery-listener" => true,
"relative-to" => "jboss.server.data.dir",
"socket-binding" => "txn-recovery-environment",
"status-socket-binding" => "txn-status-manager",
"use-hornetq-store" => false,
"log-store" => {"log-store" => undefined}
}
}
{noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 10 months
[JBoss JIRA] (AS7-5419) org.hibernate.validator module is missing jtype dependency
by Marek Goldmann (JIRA)
Marek Goldmann created AS7-5419:
-----------------------------------
Summary: org.hibernate.validator module is missing jtype dependency
Key: AS7-5419
URL: https://issues.jboss.org/browse/AS7-5419
Project: Application Server 7
Issue Type: Bug
Components: JPA / Hibernate
Affects Versions: 7.1.1.Final
Reporter: Marek Goldmann
Assignee: Scott Marlow
The {{org.hibernate.validator}} module is missing the {{com.googlecode.jtype}} dependency. Without it, the code throws a {{NoClassDefFoundError: com/googlecode/jtype/TypeUtils}}:
{code}
Caused by: java.lang.NoClassDefFoundError: com/googlecode/jtype/TypeUtils
at org.hibernate.validator.engine.ConstraintTree.findSuitableValidatorTypes(ConstraintTree.java:402) [hibernate-validator.jar:4.2.0.Final]
at org.hibernate.validator.engine.ConstraintTree.findMatchingValidatorClass(ConstraintTree.java:362) [hibernate-validator.jar:4.2.0.Final]
at org.hibernate.validator.engine.ConstraintTree.getInitializedValidator(ConstraintTree.java:313) [hibernate-validator.jar:4.2.0.Final]
at org.hibernate.validator.engine.ConstraintTree.validateConstraints(ConstraintTree.java:144) [hibernate-validator.jar:4.2.0.Final]
at org.hibernate.validator.engine.ConstraintTree.validateComposingConstraints(ConstraintTree.java:233) [hibernate-validator.jar:4.2.0.Final]
at org.hibernate.validator.engine.ConstraintTree.validateConstraints(ConstraintTree.java:128) [hibernate-validator.jar:4.2.0.Final]
at org.hibernate.validator.engine.ConstraintTree.validateConstraints(ConstraintTree.java:117) [hibernate-validator.jar:4.2.0.Final]
at org.hibernate.validator.metadata.MetaConstraint.validateConstraint(MetaConstraint.java:84) [hibernate-validator.jar:4.2.0.Final]
at org.hibernate.validator.engine.ValidatorImpl.validateConstraint(ValidatorImpl.java:452) [hibernate-validator.jar:4.2.0.Final]
at org.hibernate.validator.engine.ValidatorImpl.validateConstraintsForDefaultGroup(ValidatorImpl.java:397) [hibernate-validator.jar:4.2.0.Final]
at org.hibernate.validator.engine.ValidatorImpl.validateConstraintsForCurrentGroup(ValidatorImpl.java:361) [hibernate-validator.jar:4.2.0.Final]
at org.hibernate.validator.engine.ValidatorImpl.validateInContext(ValidatorImpl.java:313) [hibernate-validator.jar:4.2.0.Final]
at org.hibernate.validator.engine.ValidatorImpl.validate(ValidatorImpl.java:139) [hibernate-validator.jar:4.2.0.Final]
at org.hibernate.cfg.beanvalidation.BeanValidationEventListener.validate(BeanValidationEventListener.java:136) [hibernate-core.jar:3.6.10.Final]
at org.hibernate.cfg.beanvalidation.BeanValidationEventListener.onPreInsert(BeanValidationEventListener.java:94) [hibernate-core.jar:3.6.10.Final]
at org.hibernate.action.EntityIdentityInsertAction.preInsert(EntityIdentityInsertAction.java:160) [hibernate-core.jar:3.6.10.Final]
at org.hibernate.action.EntityIdentityInsertAction.execute(EntityIdentityInsertAction.java:65) [hibernate-core.jar:3.6.10.Final]
at org.hibernate.engine.ActionQueue.execute(ActionQueue.java:273) [hibernate-core.jar:3.6.10.Final]
at org.hibernate.event.def.AbstractSaveEventListener.performSaveOrReplicate(AbstractSaveEventListener.java:320) [hibernate-core.jar:3.6.10.Final]
at org.hibernate.event.def.AbstractSaveEventListener.performSave(AbstractSaveEventListener.java:203) [hibernate-core.jar:3.6.10.Final]
at org.hibernate.event.def.AbstractSaveEventListener.saveWithGeneratedId(AbstractSaveEventListener.java:129) [hibernate-core.jar:3.6.10.Final]
at org.hibernate.ejb.event.EJB3PersistEventListener.saveWithGeneratedId(EJB3PersistEventListener.java:69) [hibernate-entitymanager.jar:3.6.10.Final]
at org.hibernate.event.def.DefaultPersistEventListener.entityIsTransient(DefaultPersistEventListener.java:201) [hibernate-core.jar:3.6.10.Final]
at org.hibernate.event.def.DefaultPersistEventListener.onPersist(DefaultPersistEventListener.java:147) [hibernate-core.jar:3.6.10.Final]
at org.hibernate.event.def.DefaultPersistEventListener.onPersist(DefaultPersistEventListener.java:71) [hibernate-core.jar:3.6.10.Final]
at org.hibernate.impl.SessionImpl.firePersist(SessionImpl.java:808) [hibernate-core.jar:3.6.10.Final]
at org.hibernate.impl.SessionImpl.persist(SessionImpl.java:782) [hibernate-core.jar:3.6.10.Final]
at org.hibernate.impl.SessionImpl.persist(SessionImpl.java:786) [hibernate-core.jar:3.6.10.Final]
at org.hibernate.ejb.AbstractEntityManagerImpl.persist(AbstractEntityManagerImpl.java:839) [hibernate-entitymanager.jar:3.6.10.Final]
at org.jboss.as.jpa.container.AbstractEntityManager.persist(AbstractEntityManager.java:563) [jboss-as-jpa-7.1.1.Final.jar:7.1.1.Final]
at pl.goldmann.as7.jpa.impl.AbstractDatabase.saveChair(AbstractDatabase.java:33) [classes:]
at pl.goldmann.as7.jpa.impl.Hibernate3Database$Proxy$_$$_WeldClientProxy.saveChair(Hibernate3Database$Proxy$_$$_WeldClientProxy.java) [classes:]
at pl.goldmann.as7.bean.impl.AbstractBean.saveChair(AbstractBean.java:49) [classes:]
at pl.goldmann.as7.bean.impl.Hibernate3Bean$Proxy$_$$_WeldClientProxy.saveChair(Hibernate3Bean$Proxy$_$$_WeldClientProxy.java) [classes:]
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.7.0_05-icedtea]
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) [rt.jar:1.7.0_05-icedtea]
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0_05-icedtea]
at java.lang.reflect.Method.invoke(Method.java:601) [rt.jar:1.7.0_05-icedtea]
at org.apache.el.parser.AstValue.invoke(AstValue.java:262) [jboss-web.jar:]
at org.apache.el.MethodExpressionImpl.invoke(MethodExpressionImpl.java:278) [jboss-web.jar:]
at org.jboss.weld.util.el.ForwardingMethodExpression.invoke(ForwardingMethodExpression.java:39) [weld-core.jar:2012-04-02 17:08]
at org.jboss.weld.el.WeldMethodExpression.invoke(WeldMethodExpression.java:50) [weld-core.jar:2012-04-02 17:08]
at com.sun.faces.facelets.el.TagMethodExpression.invoke(Unknown Source) [jsf-impl.jar:2.1.7-SNAPSHOT]
at javax.faces.component.MethodBindingMethodExpressionAdapter.invoke(MethodBindingMethodExpressionAdapter.java:88) [jboss-jsf-2.1-api.jar:2.0.2.Final]
... 25 more
{code}
Hibernate Validator specifies jtype as depednency here: https://github.com/hibernate/hibernate-validator/blob/4.2.0.Final/pom.xml...
Please note that I found it on Fedora's version of JBoss AS.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 10 months