[JBoss JIRA] (WFLY-3698) Could not inject persistence unit into CDI managed bean
by Oscar Calderon (JIRA)
[ https://issues.jboss.org/browse/WFLY-3698?page=com.atlassian.jira.plugin.... ]
Oscar Calderon updated WFLY-3698:
---------------------------------
Description:
I have a project running Spring 4 & JSF 2.1 using Primefaces 5 and Hibernate JPA 2.0. I use Wildfly 8.1 and configured a datasource pointing to an Oracle 10 database. The Wildfly datasource works fine (i've tested using plain JDBC) but when i try to create a LocalContainerEntityManagerFactoryBean through Spring i set the property persistenceUnitName to specify the name of my PU and then injecting in my DAOs using @PersistenceContext(unitName="myPersUnit").
Using JBoss AS 7.1.1 Final works fine and even i don't need to specify persistenceUnitName and it creates as "default" and injects it to my DAOs without specifying name, but with JBoss 8.1 Final it doesn't work. With the same configuration, it shows me the next error:
Error injecting persistence unit into CDI managed bean. Can't find a persistence unit named persUnit in deployment
But, when i remove the @PersistenceContext annotation from my property in my DAO, strangely it initializes the persistenceUnit as i can see in server log:
08:19:57,144 INFO [org.hibernate.ejb.Ejb3Configuration] (MSC service thread 1-13) HHH000204: Processing PersistenceUnitInfo [
name: persUnit
...]
But when i try to inject it, it doesn't
was:
I have a project running Spring 4 & JSF 2.1 using Primefaces 5. I use Wildfly 8.1 and configured a datasource pointing to an Oracle 10 database. The Wildfly datasource works fine (i've tested using plain JDBC) but when i try to create a LocalContainerEntityManagerFactoryBean through Spring i set the property persistenceUnitName to specify the name of my PU and then injecting in my DAOs using @PersistenceContext(unitName="myPersUnit").
Using JBoss AS 7.1.1 Final works fine and even i don't need to specify persistenceUnitName and it creates as "default" and injects it to my DAOs without specifying name, but with JBoss 8.1 Final it doesn't work. With the same configuration, it shows me the next error:
Error injecting persistence unit into CDI managed bean. Can't find a persistence unit named persUnit in deployment
But, when i remove the @PersistenceContext annotation from my property in my DAO, strangely it initializes the persistenceUnit as i can see in server log:
08:19:57,144 INFO [org.hibernate.ejb.Ejb3Configuration] (MSC service thread 1-13) HHH000204: Processing PersistenceUnitInfo [
name: persUnit
...]
But when i try to inject it, it doesn't
> Could not inject persistence unit into CDI managed bean
> -------------------------------------------------------
>
> Key: WFLY-3698
> URL: https://issues.jboss.org/browse/WFLY-3698
> Project: WildFly
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: CDI / Weld, JPA / Hibernate
> Affects Versions: 8.1.0.Final
> Environment: Windows 8.1 64 bits, Notebook Lenovo Z570 Intel Core i7 (2nd Gen) 2670QM / 2.2 GHz , 8GB RAM, using Eclipse Luna to develop
> Reporter: Oscar Calderon
> Assignee: Stuart Douglas
> Original Estimate: 1 week
> Remaining Estimate: 1 week
>
> I have a project running Spring 4 & JSF 2.1 using Primefaces 5 and Hibernate JPA 2.0. I use Wildfly 8.1 and configured a datasource pointing to an Oracle 10 database. The Wildfly datasource works fine (i've tested using plain JDBC) but when i try to create a LocalContainerEntityManagerFactoryBean through Spring i set the property persistenceUnitName to specify the name of my PU and then injecting in my DAOs using @PersistenceContext(unitName="myPersUnit").
> Using JBoss AS 7.1.1 Final works fine and even i don't need to specify persistenceUnitName and it creates as "default" and injects it to my DAOs without specifying name, but with JBoss 8.1 Final it doesn't work. With the same configuration, it shows me the next error:
> Error injecting persistence unit into CDI managed bean. Can't find a persistence unit named persUnit in deployment
> But, when i remove the @PersistenceContext annotation from my property in my DAO, strangely it initializes the persistenceUnit as i can see in server log:
> 08:19:57,144 INFO [org.hibernate.ejb.Ejb3Configuration] (MSC service thread 1-13) HHH000204: Processing PersistenceUnitInfo [
> name: persUnit
> ...]
> But when i try to inject it, it doesn't
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
9 years, 8 months
[JBoss JIRA] (WFLY-3698) Could not inject persistence unit into CDI managed bean
by Tomaz Cerar (JIRA)
[ https://issues.jboss.org/browse/WFLY-3698?page=com.atlassian.jira.plugin.... ]
Tomaz Cerar updated WFLY-3698:
------------------------------
Fix Version/s: (was: 8.1.0.Final)
(was: 8.2.0.CR1)
> Could not inject persistence unit into CDI managed bean
> -------------------------------------------------------
>
> Key: WFLY-3698
> URL: https://issues.jboss.org/browse/WFLY-3698
> Project: WildFly
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: CDI / Weld
> Affects Versions: 8.1.0.Final
> Environment: Windows 8.1 64 bits, Notebook Lenovo Z570 Intel Core i7 (2nd Gen) 2670QM / 2.2 GHz , 8GB RAM, using Eclipse Luna to develop
> Reporter: Oscar Calderon
> Assignee: Stuart Douglas
> Original Estimate: 1 week
> Remaining Estimate: 1 week
>
> I have a project running Spring 4 & JSF 2.1 using Primefaces 5. I use Wildfly 8.1 and configured a datasource pointing to an Oracle 10 database. The Wildfly datasource works fine (i've tested using plain JDBC) but when i try to create a LocalContainerEntityManagerFactoryBean through Spring i set the property persistenceUnitName to specify the name of my PU and then injecting in my DAOs using @PersistenceContext(unitName="myPersUnit").
> Using JBoss AS 7.1.1 Final works fine and even i don't need to specify persistenceUnitName and it creates as "default" and injects it to my DAOs without specifying name, but with JBoss 8.1 Final it doesn't work. With the same configuration, it shows me the next error:
> Error injecting persistence unit into CDI managed bean. Can't find a persistence unit named persUnit in deployment
> But, when i remove the @PersistenceContext annotation from my property in my DAO, strangely it initializes the persistenceUnit as i can see in server log:
> 08:19:57,144 INFO [org.hibernate.ejb.Ejb3Configuration] (MSC service thread 1-13) HHH000204: Processing PersistenceUnitInfo [
> name: persUnit
> ...]
> But when i try to inject it, it doesn't
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
9 years, 8 months
[JBoss JIRA] (WFLY-3698) Could not inject persistence unit into CDI managed bean
by Tomaz Cerar (JIRA)
[ https://issues.jboss.org/browse/WFLY-3698?page=com.atlassian.jira.plugin.... ]
Tomaz Cerar updated WFLY-3698:
------------------------------
Component/s: JPA / Hibernate
> Could not inject persistence unit into CDI managed bean
> -------------------------------------------------------
>
> Key: WFLY-3698
> URL: https://issues.jboss.org/browse/WFLY-3698
> Project: WildFly
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: CDI / Weld, JPA / Hibernate
> Affects Versions: 8.1.0.Final
> Environment: Windows 8.1 64 bits, Notebook Lenovo Z570 Intel Core i7 (2nd Gen) 2670QM / 2.2 GHz , 8GB RAM, using Eclipse Luna to develop
> Reporter: Oscar Calderon
> Assignee: Stuart Douglas
> Original Estimate: 1 week
> Remaining Estimate: 1 week
>
> I have a project running Spring 4 & JSF 2.1 using Primefaces 5. I use Wildfly 8.1 and configured a datasource pointing to an Oracle 10 database. The Wildfly datasource works fine (i've tested using plain JDBC) but when i try to create a LocalContainerEntityManagerFactoryBean through Spring i set the property persistenceUnitName to specify the name of my PU and then injecting in my DAOs using @PersistenceContext(unitName="myPersUnit").
> Using JBoss AS 7.1.1 Final works fine and even i don't need to specify persistenceUnitName and it creates as "default" and injects it to my DAOs without specifying name, but with JBoss 8.1 Final it doesn't work. With the same configuration, it shows me the next error:
> Error injecting persistence unit into CDI managed bean. Can't find a persistence unit named persUnit in deployment
> But, when i remove the @PersistenceContext annotation from my property in my DAO, strangely it initializes the persistenceUnit as i can see in server log:
> 08:19:57,144 INFO [org.hibernate.ejb.Ejb3Configuration] (MSC service thread 1-13) HHH000204: Processing PersistenceUnitInfo [
> name: persUnit
> ...]
> But when i try to inject it, it doesn't
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
9 years, 8 months
[JBoss JIRA] (WFLY-3698) Could not inject persistence unit into CDI managed bean
by Oscar Calderon (JIRA)
Oscar Calderon created WFLY-3698:
------------------------------------
Summary: Could not inject persistence unit into CDI managed bean
Key: WFLY-3698
URL: https://issues.jboss.org/browse/WFLY-3698
Project: WildFly
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Components: CDI / Weld
Affects Versions: 8.1.0.Final
Environment: Windows 8.1 64 bits, Notebook Lenovo Z570 Intel Core i7 (2nd Gen) 2670QM / 2.2 GHz , 8GB RAM, using Eclipse Luna to develop
Reporter: Oscar Calderon
Assignee: Stuart Douglas
Fix For: 8.2.0.CR1, 8.1.0.Final
I have a project running Spring 4 & JSF 2.1 using Primefaces 5. I use Wildfly 8.1 and configured a datasource pointing to an Oracle 10 database. The Wildfly datasource works fine (i've tested using plain JDBC) but when i try to create a LocalContainerEntityManagerFactoryBean through Spring i set the property persistenceUnitName to specify the name of my PU and then injecting in my DAOs using @PersistenceContext(unitName="myPersUnit").
Using JBoss AS 7.1.1 Final works fine and even i don't need to specify persistenceUnitName and it creates as "default" and injects it to my DAOs without specifying name, but with JBoss 8.1 Final it doesn't work. With the same configuration, it shows me the next error:
Error injecting persistence unit into CDI managed bean. Can't find a persistence unit named persUnit in deployment
But, when i remove the @PersistenceContext annotation from my property in my DAO, strangely it initializes the persistenceUnit as i can see in server log:
08:19:57,144 INFO [org.hibernate.ejb.Ejb3Configuration] (MSC service thread 1-13) HHH000204: Processing PersistenceUnitInfo [
name: persUnit
...]
But when i try to inject it, it doesn't
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
9 years, 8 months
[JBoss JIRA] (JGRP-1864) UDP unable to bind to ephemeral port: port out of range:65536
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1864?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-1864:
--------------------------------
Yes, this is simple: but you need to recreate this with a *JGroups* program...
> UDP unable to bind to ephemeral port: port out of range:65536
> -------------------------------------------------------------
>
> Key: JGRP-1864
> URL: https://issues.jboss.org/browse/JGRP-1864
> Project: JGroups
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Affects Versions: 3.4.4
> Reporter: Dan Berindei
> Assignee: Bela Ban
> Priority: Minor
> Fix For: 3.4.5, 3.5
>
>
> It looks like {{UDP.createEphemeralDatagramSocket()}} swallows any errors it gets while creating the socket, and throws this exception after trying to bind to all ports in the 0 - 65535 range:
> {noformat}
> java.lang.IllegalArgumentException: port out of range:65536
> at java.net.InetSocketAddress.checkPort(InetSocketAddress.java:143)
> at java.net.InetSocketAddress.<init>(InetSocketAddress.java:185)
> at java.net.DatagramSocket.<init>(DatagramSocket.java:284)
> at org.jgroups.util.DefaultSocketFactory.createDatagramSocket(DefaultSocketFactory.java:62)
> at org.jgroups.protocols.UDP.createEphemeralDatagramSocket(UDP.java:429)
> at org.jgroups.protocols.UDP.createSockets(UDP.java:311)
> at org.jgroups.protocols.UDP.start(UDP.java:216)
> at org.jgroups.stack.ProtocolStack.startStack(ProtocolStack.java:966)
> at org.jgroups.JChannel.startStack(JChannel.java:889)
> at org.jgroups.JChannel._preConnect(JChannel.java:547)
> at org.jgroups.JChannel.connect(JChannel.java:282)
> at org.jgroups.JChannel.connect(JChannel.java:273)
> at org.infinispan.remoting.transport.jgroups.JGroupsTransport.startJGroupsChannelIfNeeded(JGroupsTransport.java:200)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
9 years, 8 months
[JBoss JIRA] (SECURITY-851) Base64Utils class cuts leading zeroes from encoded bytes
by Josef Cacek (JIRA)
[ https://issues.jboss.org/browse/SECURITY-851?page=com.atlassian.jira.plug... ]
Josef Cacek updated SECURITY-851:
---------------------------------
Git Pull Request: https://github.com/picketbox/picketbox/pull/8
> Base64Utils class cuts leading zeroes from encoded bytes
> --------------------------------------------------------
>
> Key: SECURITY-851
> URL: https://issues.jboss.org/browse/SECURITY-851
> Project: PicketBox
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Affects Versions: PicketBox_4_0_21.Beta2
> Reporter: Josef Cacek
> Assignee: Josef Cacek
> Priority: Blocker
>
> Vault util is failing for some password/salt/iteration combinations because Base64Utils class strips zeroes from provided byte array.
> So if a user encodes a key with length 8 and the leading byte of the key is zero, then after decoding he only gets 7 (or less) bytes.
> For instance:
> {code}
> encode ( { 0, 81, 121, -37, 46, -64, 20, 114 } ) -> "1HUTikm1Ho"
> decode ("1HUTikm1Ho") -> { 81, 121, -37, 46, -64, 20, 114 }
> {code}
> As a result the PBEUtil will fail with javax.crypto.IllegalBlockSizeException.
> IMHO the same problem can occur on other places where the Base64Utils class is used (not only the Vault).
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
9 years, 8 months
[JBoss JIRA] (SECURITY-851) Base64Utils class cuts leading zeroes from encoded bytes
by Josef Cacek (JIRA)
[ https://issues.jboss.org/browse/SECURITY-851?page=com.atlassian.jira.plug... ]
Josef Cacek updated SECURITY-851:
---------------------------------
Summary: Base64Utils class cuts leading zeroes from encoded bytes (was: Base64Utils class is stripping leading zeroes from encoded bytes)
> Base64Utils class cuts leading zeroes from encoded bytes
> --------------------------------------------------------
>
> Key: SECURITY-851
> URL: https://issues.jboss.org/browse/SECURITY-851
> Project: PicketBox
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Affects Versions: PicketBox_4_0_21.Beta2
> Reporter: Josef Cacek
> Assignee: Josef Cacek
> Priority: Blocker
>
> Vault util is failing for some password/salt/iteration combinations because Base64Utils class strips zeroes from provided byte array.
> So if a user encodes a key with length 8 and the leading byte of the key is zero, then after decoding he only gets 7 (or less) bytes.
> For instance:
> {code}
> encode ( { 0, 81, 121, -37, 46, -64, 20, 114 } ) -> "1HUTikm1Ho"
> decode ("1HUTikm1Ho") -> { 81, 121, -37, 46, -64, 20, 114 }
> {code}
> As a result the PBEUtil will fail with javax.crypto.IllegalBlockSizeException.
> IMHO the same problem can occur on other places where the Base64Utils class is used (not only the Vault).
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
9 years, 8 months
[JBoss JIRA] (SECURITY-851) Base64Utils class is stripping leading zeroes from encoded bytes
by Josef Cacek (JIRA)
[ https://issues.jboss.org/browse/SECURITY-851?page=com.atlassian.jira.plug... ]
Josef Cacek updated SECURITY-851:
---------------------------------
Summary: Base64Utils class is stripping leading zeroes from encoded bytes (was: Base64Util class is stripping leading zeroes from encoded bytes)
> Base64Utils class is stripping leading zeroes from encoded bytes
> ----------------------------------------------------------------
>
> Key: SECURITY-851
> URL: https://issues.jboss.org/browse/SECURITY-851
> Project: PicketBox
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Affects Versions: PicketBox_4_0_21.Beta2
> Reporter: Josef Cacek
> Assignee: Josef Cacek
> Priority: Blocker
>
> Vault util is failing for some password/salt/iteration combinations because Base64Utils class strips zeroes from provided byte array.
> So if a user encodes a key with length 8 and the leading byte of the key is zero, then after decoding he only gets 7 (or less) bytes.
> For instance:
> {code}
> encode ( { 0, 81, 121, -37, 46, -64, 20, 114 } ) -> "1HUTikm1Ho"
> decode ("1HUTikm1Ho") -> { 81, 121, -37, 46, -64, 20, 114 }
> {code}
> As a result the PBEUtil will fail with javax.crypto.IllegalBlockSizeException.
> IMHO the same problem can occur on other places where the Base64Utils class is used (not only the Vault).
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
9 years, 8 months
[JBoss JIRA] (WFCORE-36) CLI NullPointerException for Ctrl+D when prompted for username.
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/WFCORE-36?page=com.atlassian.jira.plugin.... ]
Darran Lofthouse resolved WFCORE-36.
------------------------------------
Resolution: Cannot Reproduce Bug
Can no longer reproduce.
> CLI NullPointerException for Ctrl+D when prompted for username.
> ---------------------------------------------------------------
>
> Key: WFCORE-36
> URL: https://issues.jboss.org/browse/WFCORE-36
> Project: WildFly Core
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: CLI
> Reporter: Darran Lofthouse
> Assignee: Darran Lofthouse
> Fix For: 1.0.0.Alpha4
>
>
> {code}
> [standalone@localhost:9990 /] [darranl@localhost bin]$ ./jboss-cli.sh
> You are disconnected at the moment. Type 'connect' to connect to the server or 'help' for the list of supported commands.
> [disconnected /] connect
> Username: java.lang.NullPointerException
> at org.jboss.aesh.console.Console.pushToStdOut(Console.java:227)
> at org.jboss.as.cli.impl.Console$Factory$1.print(Console.java:160)
> at org.jboss.as.cli.impl.CommandContextImpl.printLine(CommandContextImpl.java:704)
> at org.jboss.as.cli.impl.CommandContextImpl.error(CommandContextImpl.java:722)
> at org.jboss.as.cli.impl.CommandContextImpl.handleSafe(CommandContextImpl.java:647)
> at org.jboss.as.cli.impl.CommandContextImpl.interact(CommandContextImpl.java:1272)
> at org.jboss.as.cli.impl.CliLauncher.main(CliLauncher.java:254)
> at org.jboss.as.cli.CommandLineMain.main(CommandLineMain.java:34)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at org.jboss.modules.Module.run(Module.java:312)
> at org.jboss.modules.Main.main(Main.java:460)
> {code}
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
9 years, 8 months
[JBoss JIRA] (SECURITY-851) Base64Util class is stripping leading zeroes from encoded bytes
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/SECURITY-851?page=com.atlassian.jira.plug... ]
RH Bugzilla Integration updated SECURITY-851:
---------------------------------------------
Bugzilla Update: Perform
Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1125004
> Base64Util class is stripping leading zeroes from encoded bytes
> ---------------------------------------------------------------
>
> Key: SECURITY-851
> URL: https://issues.jboss.org/browse/SECURITY-851
> Project: PicketBox
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Affects Versions: PicketBox_4_0_21.Beta2
> Reporter: Josef Cacek
> Assignee: Josef Cacek
> Priority: Blocker
>
> Vault util is failing for some password/salt/iteration combinations because Base64Utils class strips zeroes from provided byte array.
> So if a user encodes a key with length 8 and the leading byte of the key is zero, then after decoding he only gets 7 (or less) bytes.
> For instance:
> {code}
> encode ( { 0, 81, 121, -37, 46, -64, 20, 114 } ) -> "1HUTikm1Ho"
> decode ("1HUTikm1Ho") -> { 81, 121, -37, 46, -64, 20, 114 }
> {code}
> As a result the PBEUtil will fail with javax.crypto.IllegalBlockSizeException.
> IMHO the same problem can occur on other places where the Base64Utils class is used (not only the Vault).
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
9 years, 8 months