[JBoss JIRA] (JASSIST-187) Hibernate + inherited entity with getId overrided + Different behavior in Win and Linux
by Alexander Zinin (JIRA)
[ https://issues.jboss.org/browse/JASSIST-187?page=com.atlassian.jira.plugi... ]
Alexander Zinin updated JASSIST-187:
------------------------------------
Attachment: javassist-test.zip
sources in zip
> Hibernate + inherited entity with getId overrided + Different behavior in Win and Linux
> ---------------------------------------------------------------------------------------
>
> Key: JASSIST-187
> URL: https://issues.jboss.org/browse/JASSIST-187
> Project: Javassist
> Issue Type: Bug
> Affects Versions: 3.16.0-GA, 3.16.1-GA, 3.17.0-GA
> Environment: Windows 7 x64 Oracle JVM x86/x64 1.6.37 - no error
> Linux Ubuntu x64 Oracle JVM x64 1.6.37 - error
> Reporter: Alexander Zinin
> Assignee: Shigeru Chiba
> Attachments: javassist-test.rar, javassist-test.zip
>
>
> It will be difficult to describe what the error.
> I will attach source code that reproduce error.
> If you have hibernate entity with overrided getId() method, in hibernate session this method returns null instead of correct value.
> Running on Windows:
> 2012-12-16 17:33:19,332 INFO ru.zinin.service.SomeServiceImpl :44 - ID = 1
> Running on Linux:
> 2012-12-16 17:41:47,772 INFO ru.zinin.service.SomeServiceImpl :44 - ID = null
> 2012-12-16 17:41:47,772 ERROR ru.zinin.service.SomeServiceImpl :46 - ID IS NULL!!!
> Bug appeared in version 3.16.0.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 6 months
[JBoss JIRA] (AS7-6260) EJB 2.x Entity Bean Audit Field Deployment Issue
by Cory Dahlstrom (JIRA)
[ https://issues.jboss.org/browse/AS7-6260?page=com.atlassian.jira.plugin.s... ]
Cory Dahlstrom commented on AS7-6260:
-------------------------------------
I ended up patching 2 classes in JBoss 7.1.1 Final to get this working ( JDBCAbstractCreateCommand & JDBCAuditMetaData ).
Cory.
> EJB 2.x Entity Bean Audit Field Deployment Issue
> ------------------------------------------------
>
> Key: AS7-6260
> URL: https://issues.jboss.org/browse/AS7-6260
> Project: Application Server 7
> Issue Type: Bug
> Components: EJB
> Affects Versions: 7.1.1.Final
> Reporter: Cory Dahlstrom
> Assignee: jaikiran pai
> Labels: new_and_noteworthy
>
> Upon deployment of an EJB 2 entity bean that has <audit> tags specified in the jbosscmp-jdbc.xml file you will get this exception:
> Caused by: java.lang.RuntimeException: JBAS010732: Couldn't create entity command
> at org.jboss.as.cmp.jdbc.JDBCCommandFactory.createCreateEntityCommand(JDBCCommandFactory.java:132)
> at org.jboss.as.cmp.jdbc.JDBCStoreManager.startStoreManager(JDBCStoreManager.java:215)
> at org.jboss.as.cmp.jdbc.JdbcStoreManagerStartService.start(JdbcStoreManagerStartService.java:44)
> ... 5 more
> Caused by: java.lang.RuntimeException: JBAS010726: No security-domain configured but created-by specified
> at org.jboss.as.cmp.jdbc.JDBCAbstractCreateCommand.initGeneratedFields(JDBCAbstractCreateCommand.java:148)
> at org.jboss.as.cmp.jdbc.JDBCAbstractCreateCommand.init(JDBCAbstractCreateCommand.java:87)
> at org.jboss.as.cmp.jdbc.JDBCInsertPKCreateCommand.init(JDBCInsertPKCreateCommand.java:43)
> at org.jboss.as.cmp.jdbc.JDBCCommandFactory.createCreateEntityCommand(JDBCCommandFactory.java:130)
> ... 7 more
> In looking at the source code where the error occurs in org.jboss.as.cmp.jdbc.JDBCAbstractCreateCommand, the securityManager is not being initialized in the init() method as it is in other version of JBoss. This causes an exception to be thrown from the initGeneratedFields() method.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 6 months
[JBoss JIRA] (JASSIST-187) Hibernate + inherited entity with getId overrided + Different behavior in Win and Linux
by Alexander Zinin (JIRA)
[ https://issues.jboss.org/browse/JASSIST-187?page=com.atlassian.jira.plugi... ]
Alexander Zinin commented on JASSIST-187:
-----------------------------------------
http://yadi.sk/d/aDqhhItf1bO9U
Run with:
java -jar javassist-test.jar
Source code attached to this ticked can be build with maven: mvn package
Assembled in target directory javassist-test.jar will be same as at link above.
> Hibernate + inherited entity with getId overrided + Different behavior in Win and Linux
> ---------------------------------------------------------------------------------------
>
> Key: JASSIST-187
> URL: https://issues.jboss.org/browse/JASSIST-187
> Project: Javassist
> Issue Type: Bug
> Affects Versions: 3.16.0-GA, 3.16.1-GA, 3.17.0-GA
> Environment: Windows 7 x64 Oracle JVM x86/x64 1.6.37 - no error
> Linux Ubuntu x64 Oracle JVM x64 1.6.37 - error
> Reporter: Alexander Zinin
> Assignee: Shigeru Chiba
> Attachments: javassist-test.rar
>
>
> It will be difficult to describe what the error.
> I will attach source code that reproduce error.
> If you have hibernate entity with overrided getId() method, in hibernate session this method returns null instead of correct value.
> Running on Windows:
> 2012-12-16 17:33:19,332 INFO ru.zinin.service.SomeServiceImpl :44 - ID = 1
> Running on Linux:
> 2012-12-16 17:41:47,772 INFO ru.zinin.service.SomeServiceImpl :44 - ID = null
> 2012-12-16 17:41:47,772 ERROR ru.zinin.service.SomeServiceImpl :46 - ID IS NULL!!!
> Bug appeared in version 3.16.0.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 6 months
[JBoss JIRA] (AS7-4293) Support property expansion in redirect-port attribute of the web system's connector
by Tomaz Cerar (JIRA)
[ https://issues.jboss.org/browse/AS7-4293?page=com.atlassian.jira.plugin.s... ]
Tomaz Cerar updated AS7-4293:
-----------------------------
Parent: AS7-6120
Issue Type: Sub-task (was: Bug)
> Support property expansion in redirect-port attribute of the web system's connector
> -----------------------------------------------------------------------------------
>
> Key: AS7-4293
> URL: https://issues.jboss.org/browse/AS7-4293
> Project: Application Server 7
> Issue Type: Sub-task
> Components: Web
> Affects Versions: 7.1.1.Final
> Environment: Standalone JBoss AS 7 on RHEL Linux and Windows 7 Enterprise x64
> Reporter: Sven-Jørgen Karlsen
> Assignee: Tomaz Cerar
> Priority: Optional
> Attachments: 04_fix_as_4293.patch
>
>
> The connector element of the web subsystem doesn't support property expansion, forcing you to hardwire the port
> number. E.g., writing:
> ...
> <subsystem xmlns="urn:jboss:domain:web:1.1" default-virtual-server="default-host">
> <connector name="http" protocol="HTTP/1.1" scheme="http" socket-binding="http"
> redirect-port="${jboss.web.https.port}"/>
> ...
> causes a NumberFormatException. Runtime properties for this attribute was supported in previous versions.
> Another problem is that there is no predefined property with the above name.
> An alternative solution is to allow a reference to a socket binding groups in the attribute value, as discussed in
> http://community.jboss.org/thread/176339
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 6 months
[JBoss JIRA] (AS7-6262) Dynamically added JSF converter ignored in some cases since Mojarra 2.1.16 upgrade
by Stan Silvert (JIRA)
[ https://issues.jboss.org/browse/AS7-6262?page=com.atlassian.jira.plugin.s... ]
Stan Silvert commented on AS7-6262:
-----------------------------------
I think this may be a case where it was working incorrectly before but is now fixed.
The problem seems to be that the code was actually adding the converter at the wrong time. The first problem is that on SelectColors, the event is only processed when it is not a postback. That only happens the first time you hit the page. The second problem is that SelectColors is listening for PreRenderViewEvent. At that point in the lifecycle, add() has been called on the Basket, but the corresponding SelectColors component has not been created.
I fixed the app by changing two lines in SelectColors.java. First, I changed the processEvent method to add the converter when it IS processing a postback:
{code}
@Override
public void processEvent(SystemEvent event) throws AbortProcessingException
{
if ( FacesContext.getCurrentInstance().isPostback() ) {
addSelectionConverter();
}
}
{code}
Second, I changed the constructor to listen for PostAddToViewEvent instead of PreRenderViewEvent.
{code}
public SelectColors() {
FacesContext context = FacesContext.getCurrentInstance();
UIViewRoot root = context.getViewRoot();
root.subscribeToViewEvent( PostAddToViewEvent.class, this );
}
{code}
Again, I'm not sure why it worked before 2.1.16. Do you want me to look into it further?
> Dynamically added JSF converter ignored in some cases since Mojarra 2.1.16 upgrade
> ----------------------------------------------------------------------------------
>
> Key: AS7-6262
> URL: https://issues.jboss.org/browse/AS7-6262
> Project: Application Server 7
> Issue Type: Bug
> Components: JSF
> Affects Versions: 7.1.4.Final (EAP)
> Environment: Current 7.1.4.Final-SNAPSHOT (2013-01-02 be583f5)
> Reporter: Marek Schmidt
> Assignee: Stan Silvert
> Fix For: 7.1.4.Final (EAP)
>
> Attachments: AS7-6262.tar.gz, AS7-6262.war
>
>
> Dynamically created converters seems to be ignored in some special cases, like the following.
> Having a form like this:
> {code}
> <h:form>
> <ul>
> <ui:repeat value="#{basket.items}" var="i">
> <li>Item #{i.number}
> <h:selectOneMenu value="#{i.color}">
> <test:selectColors />
> </h:selectOneMenu>
> </li>
> </ui:repeat>
> </ul>
> <div>
> <h:commandButton value="Add" action="#{basket.add}" />
> </div>
> <h:outputText value="#{basket.string}" />
> </h:form>
> {code}
> Where SelectColors is
> {code}
> @JsfComponent(description=@Description(displayName="org.jboss.seam.test.SelectColors",value="Creates a List<SelectItem> of colors."),
> family="javax.faces.SelectItems", type="org.jboss.seam.test.SelectColors",generate="org.jboss.seam.test.html.HtmlSelectColors",
> tag = @Tag(baseClass="javax.faces.webapp.UIComponentTagBase", name="selectColors"))
> public class SelectColors extends javax.faces.component.UISelectItems implements SystemEventListener {
> public SelectColors() {
> FacesContext context = FacesContext.getCurrentInstance();
> UIViewRoot root = context.getViewRoot();
> root.subscribeToViewEvent( PreRenderViewEvent.class, this );
> }
> @Override
> public Object getValue() {
> List<SelectItem> ret = new LinkedList<SelectItem> ();
> ret.add(new SelectItem("default", "Select color... (black by default)"));
> ret.add(new SelectItem("red", "Red"));
> ret.add(new SelectItem("white", "White"));
> ret.add(new SelectItem("blue", "Blue"));
> ret.add(new SelectItem("black", "Black"));
> return ret;
> }
> private void addSelectionConverter() {
> UIComponent parentComponent = getParent();
> if (parentComponent instanceof ValueHolder) {
> ValueHolder parentValueHolder = (ValueHolder) parentComponent;
> Converter parentConverter = parentValueHolder.getConverter();
> if (parentConverter == null) {
> parentValueHolder.setConverter(new DefaultColorConverter());
> }
> }
> }
> @Override
> public void processEvent(SystemEvent event) throws AbortProcessingException
> {
> if ( !FacesContext.getCurrentInstance().isPostback() ) {
> addSelectionConverter();
> }
> }
> @Override
> public boolean isListenerForSource(Object source)
> {
> return ( source instanceof UIViewRoot );
> }
> }
> {code}
> and the DefaultColorConverter being:
> {code}
> @FacesConverter(value="org.jboss.seam.test.DefaultColorConverter")
> public class DefaultColorConverter implements Converter
> {
> public static final String DEFAULT_COLOR = "black";
> public Object getAsObject(FacesContext context, UIComponent component, String value) throws ConverterException
> {
> if ("default".equals(value)) {
> return DEFAULT_COLOR;
> }
>
> return value;
> }
> public String getAsString(FacesContext context, UIComponent component, Object value) throws ConverterException
> {
> return value.toString();
> }
> }
> {code}
> In the pre-Mojarra 2.1.16 upgrade, clicking on the add button repeatedly creates "black" items. Post mojarra 2.1.16, it sets the color to "default", which should never happen, as the converter should convert the "default" value into "black".
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 6 months
[JBoss JIRA] (AS7-6120) Expand support for System Property substitution
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/AS7-6120?page=com.atlassian.jira.plugin.s... ]
Brian Stansberry updated AS7-6120:
----------------------------------
Fix Version/s: 7.2.0.Alpha1
(was: 7.2.0.CR1)
> Expand support for System Property substitution
> -----------------------------------------------
>
> Key: AS7-6120
> URL: https://issues.jboss.org/browse/AS7-6120
> Project: Application Server 7
> Issue Type: Task
> Components: Domain Management
> Affects Versions: 7.1.3.Final (EAP)
> Reporter: Jimmy Wilson
> Assignee: Brian Stansberry
> Priority: Blocker
> Labels: eap-6.1-prd
> Fix For: 7.2.0.Alpha1
>
> Attachments: expressions.ods
>
>
> Audit the core AS and all subsystems shipped in the AS distribution for suport for expression in management resource attributes.
> The basic philosophy toward expressions in previous releases was to only push devs to add support if there was a clear important use case. Devs could choose to add support beyond that, but we wouldn't push that. This JIRA and PRODMGT-195 from which it is derived reflects a change in philosophy. Now the philosophy is to support expressions unless the dev foresees a technical or future compatibility problem arising from doing so.
> This task DOES NOT advocate adding expression support to attributes that represent references to other model elements. Such references may prove problematic in the future and should not be added. We already have some model ref attributes that support expressions; this task DOES NOT advocate removing such support, unless the support has never been provided in a Final release (i.e. it was added during 7.2 development.)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 6 months
[JBoss JIRA] (AS7-5794) JMX over remoting pollutes query results with ModelController objects
by Kabir Khan (JIRA)
[ https://issues.jboss.org/browse/AS7-5794?page=com.atlassian.jira.plugin.s... ]
Kabir Khan commented on AS7-5794:
---------------------------------
Please take a look at my latest commit here https://github.com/kabir/jboss-as/tree/AS7-5794-jmx, and let me know if you mean something else?
> JMX over remoting pollutes query results with ModelController objects
> ---------------------------------------------------------------------
>
> Key: AS7-5794
> URL: https://issues.jboss.org/browse/AS7-5794
> Project: Application Server 7
> Issue Type: Bug
> Components: Domain Management, JMX
> Affects Versions: 7.1.2.Final (EAP)
> Reporter: Tristan Tarrant
> Assignee: Kabir Khan
> Fix For: 7.3.0.Alpha1
>
>
> When issuing MBean queries over JMX remoting, the AS is returning a list of org.jboss.as.controller.ModelController objects in addition to those matching the query.
> This is a transcript of a chat we had about it on IRC:
> Oct 15 14:51:46 <ttarrant> darranl, if I issue a jmx query over jmx-remoting I get many more objects than expected
> Oct 15 14:51:55 <ttarrant> darranl, i.e. ones that do not match the query
> Oct 15 14:52:09 <ttarrant> darranl, this is with 7.1.x
> Oct 15 14:52:57 <ttarrant> darranl, this works if I use the standard JMX over RMI
> Oct 15 14:53:08 --> fnasser (~fnasser(a)CPE602ad07ab726-CM602ad07ab723.cpe.net.cable.rogers.com) has joined #jboss-as7
> Oct 15 14:53:09 <-- fnasser has quit (Changing host)
> Oct 15 14:53:09 --> fnasser (~fnasser@redhat/jboss/fnasser) has joined #jboss-as7
> Oct 15 14:53:09 --- ChanServ gives voice to fnasser
> Oct 15 14:53:16 <ttarrant> darranl, do you just pass the query the the mbeanserver ?
> Oct 15 14:53:39 <darranl> ttarrant: what kind of objects? within AS7 I think there are two things that could affec
> t this 1 - The Remoting JMX protocol, 2 - The domain management representation over JMX
> Oct 15 14:53:54 <darranl> For #1 yes we just pass it to the MBEanServer and return whatever it returns
> Oct 15 14:54:04 <darranl> if it was a Remoting JMX bug maybe we are messing up the query
> Oct 15 14:54:16 <ttarrant> darranl, the query is as follows: *:type=CacheManager,component=Interpreter,name=*
> Oct 15 14:54:16 <darranl> But not sure if #2 could be the reason more is getting added
> Oct 15 14:54:32 <ttarrant> darranl, wait a sec
> Oct 15 14:54:57 <darranl> ttarrant: I would suggest getting a Jira raised and assigned to me, I can verify if it i
> s a remoting jmx issue or pass over if it is a domain management integration issue
> Oct 15 14:55:20 <darranl> regardless of where it is happenign it sounds like you may have discovered a bug
> Oct 15 14:56:23 <ttarrant> darranl, let me get the objects it's returning
> Oct 15 14:56:39 <darranl> ttarrant: when you enable the RMI approach you bypass both Remoting JMX AND the domain m
> anagement integration
> Oct 15 14:56:42 <darranl> ok
> Oct 15 15:26:08 <ttarrant> darranl, ok, my query actually returns the object I queried for and a bunch of org.jboss.as.controller.ModelController (one for each subsystem)
> Oct 15 15:51:24 <darranl> ttarrant: ok that does then sound like it is the domain management integration that is 'poluting' the query results
> Oct 15 15:51:53 <darranl> ttarrant: going RMI was just bypassing that as well
> Oct 15 15:52:05 <ttarrant> darranl, shall I open a Jira ?
> Oct 15 15:52:34 <ttarrant> darranl, I work around the issue by manually filtering the returned objects based on class name
> Oct 15 15:53:23 <darranl> ttarrant: it would probably be one for kkhan to look into, think he is just back today so may be worth the Jira so he can have a look once he has caught back up ;-)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 6 months