[JBoss JIRA] Created: (JBAS-8815) Regression in Hibernate session/sessionfactory injection
by Scott Marlow (JIRA)
Regression in Hibernate session/sessionfactory injection
--------------------------------------------------------
Key: JBAS-8815
URL: https://issues.jboss.org/browse/JBAS-8815
Project: JBoss Application Server
Issue Type: Task
Security Level: Public (Everyone can see)
Affects Versions: 6.0.1
Reporter: Scott Marlow
Assignee: Scott Marlow
Fix For: 6.0.1
Regression caused by fix for JBAS-8563. This impacts the Hibernate specific support mentioned here http://bill.burkecentral.com/2007/07/06/co-existence-with-hibernate-jpa-a....
The regression is that the following will no longer work:
@PersistenceContext(unitName="custDb") org.hibernate.Session session;
@PersistenceUnit(unitName="custDb") SessionFactory factory;
The workaround is to instead use the JPA 2.0 EntityManager.unwrap(Session.class).
org.jboss.ejb3.test.longlived.unit.EntityUnitTestCase.testHibernateLongLivedSession fails with error:
2011-01-18 08:39:08,248 ERROR [org.jboss.ejb3.proxy.impl.factory.session.stateful.StatefulSessionProxyFactoryBase] (WorkerThread#1[127.0.0.1:54163]) Could not obtain new Session ID from SFSB Container: javax.ejb.EJBException: java.lang.IllegalArgumentException: failed to set value ExtendedEntityManager: persistence.unit:unitName=longlived-test.jar#tempdb on field org.hibernate.Session org.jboss.ejb3.test.longlived.HibernateShoppingCartBean.em
at org.jboss.ejb3.cache.simple.SimpleStatefulCache.create(SimpleStatefulCache.java:438) [:1.7.19-SNAPSHOT]
at org.jboss.ejb3.stateful.StatefulContainer.createSession(StatefulContainer.java:440) [:1.7.19-SNAPSHOT]
at org.jboss.ejb3.session.SessionContainer.createSession(SessionContainer.java:677) [:1.7.19-SNAPSHOT]
at org.jboss.ejb3.proxy.impl.factory.session.stateful.StatefulSessionProxyFactoryBase.getNewSessionId(StatefulSessionProxyFactoryBase.java:227) [:1.0.11]
at org.jboss.ejb3.proxy.impl.factory.session.stateful.StatefulSessionProxyFactoryBase.createProxyBusiness(StatefulSessionProxyFactoryBase.java:140) [:1.0.11]
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [:1.6.0_23]
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) [:1.6.0_23]
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) [:1.6.0_23]
at java.lang.reflect.Method.invoke(Method.java:597) [:1.6.0_23]
at org.jboss.aop.Dispatcher.invoke(Dispatcher.java:121) [jboss-aop.jar:2.2.1.GA]
at org.jboss.aspects.remoting.AOPRemotingInvocationHandler.invoke(AOPRemotingInvocationHandler.java:82) [:1.0.1.GA]
at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:898) [:]
at org.jboss.remoting.transport.socket.ServerThread.completeInvocation(ServerThread.java:791) [:]
at org.jboss.remoting.transport.socket.ServerThread.processInvocation(ServerThread.java:744) [:]
at org.jboss.remoting.transport.socket.ServerThread.dorun(ServerThread.java:548) [:]
at org.jboss.remoting.transport.socket.ServerThread.run(ServerThread.java:234) [:]
Caused by: java.lang.IllegalArgumentException: failed to set value ExtendedEntityManager: persistence.unit:unitName=longlived-test.jar#tempdb on field org.hibernate.Session org.jboss.ejb3.test.longlived.HibernateShoppingCartBean.em
at org.jboss.injection.injector.util.FieldInjectionPoint.set(FieldInjectionPoint.java:73) [:1.0.0-alpha-6]
at org.jboss.injection.injector.EEInjector.inject(EEInjector.java:159) [:1.0.0-alpha-6]
at org.jboss.injection.injector.EEInjector.inject(EEInjector.java:134) [:1.0.0-alpha-6]
at org.jboss.injection.injector.EEInjector.inject(EEInjector.java:82) [:1.0.0-alpha-6]
at org.jboss.injection.manager.core.DefaultInjectionContext.proceed(DefaultInjectionContext.java:58) [:1.0.0-alpha-6]
at org.jboss.injection.manager.core.DefaultInjectionManager.inject(DefaultInjectionManager.java:58) [:1.0.0-alpha-6]
at org.jboss.injection.manager.core.DefaultInjectionManager.inject(DefaultInjectionManager.java:64) [:1.0.0-alpha-6]
at org.jboss.ejb3.injection.InjectionInvocation.invokeTarget(InjectionInvocation.java:140) [:1.7.19-SNAPSHOT]
at org.jboss.ejb3.injection.InjectionInvocation.invokeNext(InjectionInvocation.java:125) [:1.7.19-SNAPSHOT]
at org.jboss.ejb3.core.context.CurrentInvocationContextInterceptor.invoke(CurrentInvocationContextInterceptor.java:47) [:1.7.19-SNAPSHOT]
at org.jboss.ejb3.injection.InjectionInvocation.invokeNext(InjectionInvocation.java:116) [:1.7.19-SNAPSHOT]
at org.jboss.aspects.currentinvocation.CurrentInvocationInterceptor.invoke(CurrentInvocationInterceptor.java:67) [:1.0.1]
at org.jboss.ejb3.injection.InjectionInvocation.invokeNext(InjectionInvocation.java:116) [:1.7.19-SNAPSHOT]
at org.jboss.ejb3.EJBContainer.injectBeanContext(EJBContainer.java:1363) [:1.7.19-SNAPSHOT]
at org.jboss.ejb3.stateful.StatefulContainer.createBeanContext(StatefulContainer.java:184) [:1.7.19-SNAPSHOT]
at org.jboss.ejb3.stateful.StatefulContainer.create(StatefulContainer.java:136) [:1.7.19-SNAPSHOT]
at org.jboss.ejb3.cache.simple.SimpleStatefulCache.create(SimpleStatefulCache.java:417) [:1.7.19-SNAPSHOT]
... 15 more
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 5 months
[JBoss JIRA] Created: (JBRULES-3136) Exception when extending non-bean classes
by Davide Sottara (JIRA)
Exception when extending non-bean classes
-----------------------------------------
Key: JBRULES-3136
URL: https://issues.jboss.org/browse/JBRULES-3136
Project: Drools
Issue Type: Bug
Security Level: Public (Everyone can see)
Affects Versions: 5.2.0.Final
Reporter: Davide Sottara
Assignee: Mark Proctor
Fix For: 5.3.0.Beta1
When a declared class extends another, the compiler looks for fields in the superclass using the getter methods, which are then reused by the internal field readers/writers. When a superclass has a field with a getter only (i.e. no setter), an exception is thrown.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 5 months
[JBoss JIRA] Created: (JBRULES-2784) Use java-style annotations for metadata
by Davide Sottara (JIRA)
Use java-style annotations for metadata
----------------------------------------
Key: JBRULES-2784
URL: https://jira.jboss.org/browse/JBRULES-2784
Project: Drools
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Components: drools-compiler
Affects Versions: 5.2.0.M1
Reporter: Davide Sottara
Assignee: Mark Proctor
Priority: Trivial
Fix For: 5.2.0.M1
Drools Metadata, allowed in rules and bean declarations, are conceptually similar to java annotations, but the actual structure is different: Drools is free-form, while Java uses (optional) key - element pairs:
Drools : @attr( <free text here> )
Java : @attr( key1 = value1, key2 ... )
I suggest the use of Java-like annotations in place of free-form meta-attributes.
Compatibility with official metadata (e.g. event definition) will be guaranteed.
Could break compatibility if a user defined and used their own metadata in the code, as some constructs like @author(john doe) will no longer be accepted, even if @author("john doe"), @author(john, doe) or @author(name="john doe") will.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 5 months
[JBoss JIRA] Created: (JBRULES-3104) Use annotations on declared beans
by Davide Sottara (JIRA)
Use annotations on declared beans
---------------------------------
Key: JBRULES-3104
URL: https://issues.jboss.org/browse/JBRULES-3104
Project: Drools
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Components: drools-compiler
Affects Versions: 5.2.0.Final
Reporter: Davide Sottara
Assignee: Mark Proctor
Priority: Minor
Fix For: 5.3.0.Beta1
When declaring beans (i.e. using the "declare" feature), if metadata attached to a class or a field corresponds to an actual @Annotation, that @Annotation should be present in the generated class.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 5 months
[JBoss JIRA] Created: (JBVFS-160) FileSystemContext.getFileURI returns wrong URI for UNC paths on Windows
by James Livingston (JIRA)
FileSystemContext.getFileURI returns wrong URI for UNC paths on Windows
-----------------------------------------------------------------------
Key: JBVFS-160
URL: https://jira.jboss.org/browse/JBVFS-160
Project: JBoss VFS
Issue Type: Bug
Security Level: Public (Everyone can see)
Affects Versions: 2.1.3.SP1
Environment: Windows
Reporter: James Livingston
Assignee: John Bailey
Attachments: UncPathTest.java
When passed a File for something with a UNC path (e.g. \\127.0.0.1\shared), FileSystemContext.getFileURI() return a URI like "file://127.0.0.1/shared" (which is what Windows itself uses) rather than "file:////127.0.0.1/shared" (which Java uses, and converts for OS calls). This will cause JBoss to fail to deploy things if they are located on an unmapped UNC location.
I'm attaching a test case for this. To use it, you need to run it on a Windows system and have access to a something with a UNC path. The code as written expects there to be a SMB share called "shared" on the machine it is run on, but it can easily be change to point elsewhere.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 5 months
[JBoss JIRA] Created: (JBVFS-165) VFSInputSource should not implement getCharacterStream
by Ales Justin (JIRA)
VFSInputSource should not implement getCharacterStream
------------------------------------------------------
Key: JBVFS-165
URL: https://jira.jboss.org/browse/JBVFS-165
Project: JBoss VFS
Issue Type: Bug
Security Level: Public (Everyone can see)
Affects Versions: 3.0.0.CR5, 2.2.0.GA, 2.1.3.SP1, 2.1.3.GA
Reporter: Ales Justin
Assignee: Ales Justin
Fix For: 2.1.3.SP2, 3.0.0.CR6
It's related to the encoding with which the XML is parsed.
The encoding specified in
<?xml version="1.0" encoding="UTF-8"?>
is guaranteed to be used unless the user provides a java.io.Reader to the parser. Which is what happens in our case, the encoding specified in the XML is ignored and the system default one is used instead.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 5 months
[JBoss JIRA] Created: (JBAS-9335) Errors in windows service.bat error handling
by Stephen Parry (JIRA)
Errors in windows service.bat error handling
--------------------------------------------
Key: JBAS-9335
URL: https://issues.jboss.org/browse/JBAS-9335
Project: JBoss Application Server
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: MSC
Affects Versions: 6.0.0.Final
Environment: Windows
Reporter: Stephen Parry
Priority: Minor
service.bat
The errorlevel handling in the service.bat script is incorrect causing misleading error messages.
The syntax:
if errorlevel 1
is used meaning "if errorlevel == 1", when it actual means "if errorlevel >= 1". The syntax that should be used is:
if %errorlevel% EQU 1
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 5 months