[JBoss JIRA] (AS7-2961) Context lookup fails during WebService constructor.
by Jeremy Whiting (Created) (JIRA)
Context lookup fails during WebService constructor.
----------------------------------------------------
Key: AS7-2961
URL: https://issues.jboss.org/browse/AS7-2961
Project: Application Server 7
Issue Type: Bug
Components: Web Services
Affects Versions: 7.1.0.Beta1
Environment: OpenJDK 6 on Fedora16
Reporter: Jeremy Whiting
Assignee: Alessio Soldano
Attachments: envEntryWeb.tar.gz
During a WebService constructor call my application is making a jndi context lookup that is failing. The lookup uses java:comp/env to lookup an entry. The web service is a JEE5 spec application.
The application defines an env-entry in the web deployment descriptor.
It looks as though the context is not established in time for the WebSevice constructor being called.
A sample application is provided to demonstrate the issue. When this application is deployed I am seeing the stack trace in the second attachment.
--
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
14 years, 4 months
[JBoss JIRA] (HIBERNATE-128) Hibernate tools generate wrong sequence when using multiple table-filters
by Gonzalo Aguilar (JIRA)
Gonzalo Aguilar created HIBERNATE-128:
-----------------------------------------
Summary: Hibernate tools generate wrong sequence when using multiple table-filters
Key: HIBERNATE-128
URL: https://issues.jboss.org/browse/HIBERNATE-128
Project: Hibernate Integration
Issue Type: Bug
Environment: Linux red1 3.0.0-16-generic #28-Ubuntu SMP Fri Jan 27 17:44:39 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux
/usr/lib/jvm/java-6-openjdk/jre/bin/java
Hibernate Tools 3.4.0.CR1
Eclipse Indigo
Reporter: Gonzalo Aguilar
Assignee: Steve Ebersole
Hibernate tools (reverse engineering) is creating wrong sequence number when using different table-filters.
I also think that some interface with eclipse is doing bad things to file cache.
First:
Sequence generation is not generated correctly when using schema tag on table with some table-filters. Example
<hibernate-reverse-engineering>
...
<table-filter match-name="lead" match-schema="public" exclude="false" />
<table-filter match-name="contact_.*" match-schema="public" exclude="false" />
...
<table name="contact_record" schema="public">
<primary-key>
<generator class="sequence">
<param name="table">contact_record_id_contact_record_seq</param>
</generator>
</primary-key>
<!-- <column name="uuid" type="com.level2.enterprise.crm.hibernate.datatypes.UuidUserType" /> -->
</table>
</hibernate-reverse-engineering>
---> RESULT WRONG!!!! it performs a generator="assigned"
<hibernate-reverse-engineering>
...
<table-filter match-name="lead" match-schema="public" exclude="false" />
<table-filter match-name="contact_.*" match-schema="public" exclude="false" />
...
<table name="contact_record">
<primary-key>
<generator class="sequence">
<param name="table">contact_record_id_contact_record_seq</param>
</generator>
</primary-key>
<!-- <column name="uuid" type="com.level2.enterprise.crm.hibernate.datatypes.UuidUserType" /> -->
</table>
</hibernate-reverse-engineering>
---> RIGHT!! BUT YOU HAVE TO SEE THE SCREENSHOT... IT DOES NOT GET UPDATED IN ECLIPSE
This creates something like in eclipse. No matter what you do (refresh, close and open again, etc):
<?xml version="1.0"?>
<!DOCTYPE hibernate-mapping PUBLIC "-//Hibernate/Hibernate Mapping DTD 3.0//EN"
"http://hibernate.sourceforge.net/hibernate-mapping-3.0.dtd">
<!-- Generated 17-feb-2012 21:32:52 by Hibernate Tools 3.4.0.CR1 -->
<hibernate-mapping>
<class name="com.level2.enterprise.hibernate.generated.ContactRecord" table="contact_record">
<id name="idContactRecord" type="java.lang.Integer">
<column name="id_contact_record" />
<generator class="assigned" />
</id>
----
But in the file if you see with a less command you get:
<?xml version="1.0"?>
<!DOCTYPE hibernate-mapping PUBLIC "-//Hibernate/Hibernate Mapping DTD 3.0//EN"
"http://hibernate.sourceforge.net/hibernate-mapping-3.0.dtd">
<!-- Generated 17-feb-2012 21:49:17 by Hibernate Tools 3.4.0.CR1 -->
<hibernate-mapping>
<class name="com.level2.enterprise.hibernate.generated.ContactRecord" table="contact_record">
<id name="idContactRecord" type="java.lang.Integer">
<column name="id_contact_record" />
<generator class="sequence">
<param name="table">contact_record_id_contact_record_seq</param>
</generator>
</id>
------
That is right.
Second:
I also got a GUI problem when reversing this:
<table name="contact_record">
<primary-key>
<generator class="sequence">
<param name="table">contact_record_id_contact_record_seq</param>
</generator>
</primary-key>
<!-- <column name="uuid" type="com.level2.enterprise.crm.hibernate.datatypes.UuidUserType" /> -->
</table>
if the commented section is enabled (uncommented). That is wrong because types does not match but it should do something and tell you that's wrong. Instead it just crashes. The only way to make it work was adding schema to table:
<table name="contact_record" schema="public">
<primary-key>
<generator class="sequence">
<param name="table">contact_record_id_contact_record_seq</param>
</generator>
</primary-key>
<column name="uuid" type="com.level2.enterprise.crm.hibernate.datatypes.UuidUserType" />
</table>
But it got the sequence wrong again.
That was really weird...
Hope it helps
--
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
14 years, 4 months
[JBoss JIRA] (AS7-1338) Remote JNDI support for AS7
by Justin Bertram (JIRA)
[ https://issues.jboss.org/browse/AS7-1338?page=com.atlassian.jira.plugin.s... ]
Justin Bertram commented on AS7-1338:
-------------------------------------
@Ed, the code should be the same as you posted in your earlier comment. If your having some problems with this please open a forum thread and include any error messages you're seeing. Thanks.
> Remote JNDI support for AS7
> ---------------------------
>
> Key: AS7-1338
> URL: https://issues.jboss.org/browse/AS7-1338
> Project: Application Server 7
> Issue Type: Task
> Components: Naming
> Reporter: Richard Opalka
> Assignee: John Bailey
> Priority: Critical
> Labels: eap6_prd_req
> Fix For: 7.1.0.Final
>
>
> Add support for remote JNDI after all. It was agreed that:
> * Remote JNDI would run over Remoting
> * Remote JNDI for EJB is strictly a legacy access protocol, deprecated in favor of "ejb:"
> * The Remote JNDI service would proxy to a specific Context of the server JNDI tree - maybe "java:jboss/shared", maybe something else
> * Server-side services would opt-in to Remote JNDI; initially we'd only support:
> ** Remote EJB interfaces
> ** HornetQ connection factories
> * In the future we may support:
> ** User bindings, so long as they're serializable
> * In the future we will never support:
> ** Proxied DataSources
> ** Proxied JMS invocations
> Initial project tree is at https://github.com/dmlloyd/jboss-remote-jndi for now.
--
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
14 years, 4 months
[JBoss JIRA] (JBMESSAGING-1913) JBoss Messaging throws an java.lang.IllegalArgumentException exception
by Tom Ross (JIRA)
Tom Ross created JBMESSAGING-1913:
-------------------------------------
Summary: JBoss Messaging throws an java.lang.IllegalArgumentException exception
Key: JBMESSAGING-1913
URL: https://issues.jboss.org/browse/JBMESSAGING-1913
Project: JBoss Messaging
Issue Type: Bug
Components: JMS Client Manager
Environment: JBoss EAP 5.1.2
Reporter: Tom Ross
Assignee: Yong Hao Gao
Fix For: 1.4.8.SP5, 1.4.7.GA
The code for org.jboss.jms.client.plugin.RoundRobinLoadBalancingPolicy.getNext() method calls Random.nextInt(int n) with negative argument. This is wrong since the Java JDK 1.6 documentation states that the nextInt(int n) method must be called with a positive number.
This is method implementation as per JDK 1.6 documentation.
public int nextInt(int n) {
if (n <= 0)
throw new IllegalArgumentException("n must be positive");
if ((n & -n) == n) // i.e., n is a power of 2
return (int)((n * (long)next(31)) >> 31);
int bits, val;
do {
bits = next(31);
val = bits % n;
} while (bits - val + (n-1) < 0);
return val;
}
--
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
14 years, 4 months
[JBoss JIRA] (AS7-1338) Remote JNDI support for AS7
by Ed Keen (JIRA)
[ https://issues.jboss.org/browse/AS7-1338?page=com.atlassian.jira.plugin.s... ]
Ed Keen commented on AS7-1338:
------------------------------
@Jason, you had posted some example code on this thread, to illustrate how to connect to a remote queue. Where did that code go? I am having problems with this after downloading 7.1.0.Final, and I just want to make sure I am following the steps correctly. Can you please point me to a link where those directions are?
> Remote JNDI support for AS7
> ---------------------------
>
> Key: AS7-1338
> URL: https://issues.jboss.org/browse/AS7-1338
> Project: Application Server 7
> Issue Type: Task
> Components: Naming
> Reporter: Richard Opalka
> Assignee: John Bailey
> Priority: Critical
> Labels: eap6_prd_req
> Fix For: 7.1.0.Final
>
>
> Add support for remote JNDI after all. It was agreed that:
> * Remote JNDI would run over Remoting
> * Remote JNDI for EJB is strictly a legacy access protocol, deprecated in favor of "ejb:"
> * The Remote JNDI service would proxy to a specific Context of the server JNDI tree - maybe "java:jboss/shared", maybe something else
> * Server-side services would opt-in to Remote JNDI; initially we'd only support:
> ** Remote EJB interfaces
> ** HornetQ connection factories
> * In the future we may support:
> ** User bindings, so long as they're serializable
> * In the future we will never support:
> ** Proxied DataSources
> ** Proxied JMS invocations
> Initial project tree is at https://github.com/dmlloyd/jboss-remote-jndi for now.
--
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
14 years, 4 months
[JBoss JIRA] (AS7-3561) change validate-address operation contract
by Alexey Loubyansky (JIRA)
Alexey Loubyansky created AS7-3561:
--------------------------------------
Summary: change validate-address operation contract
Key: AS7-3561
URL: https://issues.jboss.org/browse/AS7-3561
Project: Application Server 7
Issue Type: Task
Components: Domain Management
Reporter: Alexey Loubyansky
Assignee: Alexey Loubyansky
Fix For: 7.1.0.Final
Current implementation is not safe in a sense that the operation fails if the address is not valid. There is no safe way, i.e. a boolean result, not a failure, to check whether an address is valid.
The idea is to change the current validate-address so that:
- it's only a root operation, not inherited like the current impl;
- add an address argument (the current impl has no arguments), which will be the address to check;
- the result type should be a boolean value;
- in case of failure, include a message into the response describing which part of the address is wrong.
--
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
14 years, 4 months